Slashdot Mirror

There really is a sort of sublime irony in a poster blatantly ripping off a blog post which defends the idea that certain companies are ripping off Apple.

http://macjournals.com/blog/2012/01/10/dan-lyons-showing-self-awareness-what-self-awareness/

Unless, of course, bonch really is Matt Deatherage of MacJournals, in which case, congratulations on quoting yourself.

While I fully agree that this particular AC made up the story, it does have some basis in fact.

http://friends.macjournals.com/mattd/discuss/msgReader$1855

If you google around a bit, you can find more examples, including the actual text on Apple's service contract. Was a little while ago though, not sure if the policy is still the same.

But don't worry, he wouldn't be lying this time...

What bugs me is the lack of documentation. Where is the data coming from? Is it offline or online (e.g. every URL submitted), how is the data secured?

It comes from Google. It is their "Safe Browsing" technology. Safari gets a list of hashes of known bad URLs. The list is continuously updated by Google, and Safari periodically fetches an update. By Google's rules the browser can only put up the warning if its list has been updated in the last 30 minutes. Presumably that means that if Safari finds a suspect it does a special refresh.

Safari stores the hashes in a SQLite database in its cache folder. You can browse it if you want to, though it's only hashes.
The warning itself is located at /Applications/Safari.app/Contents/Resources/PhishingAlert.html, so you can change it if you want to. All of this info is courtesy of MDJ.

Here's a little writeup that tries to explain how Apple books revenue from iPhones/iPods and why some software upgrades cost money while others don't. It basically boils down to "the correct way" vs "the accepted way which can lead to investor lawsuits in the right jurisdiction especially if people have been scrutinizing your option accounting methods in the past."

http://macjournals.com/news/iPhonerevenues.html

MAcfixit.com broke the FAKE story, a FUD of "APE responsible for this". I have even risked my VT Pro, $50 year account and called the editor openly to resign.

This thing turned out to be a password hash issue related to accounts created back in 10.2 and never changed. Documented here: http://docs.info.apple.com/article.html?artnum=306840

APE has nothing to do with it. In fact, Unsanity recommends latest APE to be on OS while upgrading to Leopard since believe or not, APE is not just couple of themes or pointers, there are many companies using that functionality and their software may break when linked library is not there.

It doesn't change the fact that APE will be ignored by Leopard btw.

Macfixit has even surpassed itself and was openly called "Depictable" http://www.macjournals.com/news/despicable.html because of their horrible FUD mongering, calling people to ERASE and INSTALL and after CNET buyout, some people think they do it on purpose to make people afraid to use OS X or Mac.

If there is apple.slashdot.org, it should have better hand picked stories, no fanboy idiotic stuff, no "maccies are idiots" stuff, just "news for Mac nerds".

This story was sitting on Digg.com for hours and even couldn't make to being popular (like slashdot accepted) because people simply didn't buy it, especially APE reason.

We rarely get new non-ipod etc. stuff on Apple.slashdot.org and I wished the second one after Leopard shipment wasn't FUD with false information.

no, Mac Journals did make that claim, just in a different article (emphisis mine): "Sun is fond of saying that snapshots take up no disk space, but that's only true when they're created, just like an empty file." -- http://www.macjournals.com/news/2007/10/07#a80

I am not presently seeing ZFS snapshots "eating diskspace like crazy." MacJournals' claim is that it does "eat diskspace like crazy." Their wording is absolute; it will always happen. While I will acknowledge that there might be access patterns that cause it to happen, I would hardly call these common (let alone "EVERY" pattern).

I am using ZFS now, I do not see what is claimed on my system. I wouldn't be calling it a lie if it weren't for the adamant nature of their claim, but they don't say "under some access patterns", what they say is "it does this." If someone makes a absolute claim that tests show to be factually untrue (in a not insignificant percentage of cases), is that not a lie? I suppose it IS after 1984, so maybe its "truth."

Professional editing of full-length video is NOT a normal access pattern. Not even close. The majority of people who are doing digital media work have a level of technical expertise which would allow them to change filesystems, or to adjust the settings appropriately to what they do (this is not uncommon of users of Adobe products now). MOST usage does not follow the pattern of "massive changes to massive files," small changes are far more common then massive ones.

I do not claim that it is perfect for all conditions, but to claim that it is completely inappropriate for normal desktop usage because of how it preforms under a professional grade digital media creation workload is silly.

Oninoshiko

NTFS allows for something similar. Take the snapshot, run the backup against the snapshot (I believe windows calls this a "shaow copy"). So while the concept is not intrinsic to the concept of a snapshot, it is also not a ZFS specific implimentation (and giving credit where it's due, is a good idea, and AFAIK was first in NTFS). Getting at different versions isn't that difficult, although it would require some footwork to make it practical for the lay-person via the GUI (if i can script it, a GUI can be made for it).

Using a snapshot freezes that data in a state quickly (close enough to instantly that any difference is irrelevant). It can then continue to be written while backups are occurring. This is probably not an issue so much on a workstation as a loaded server (although if your taking them hourly, it might become one).

The only thing written is the differences between the states. Maybe I'm missing something, but thats the most-efficient way to store both. Now that I'm really thinking about it, it is probably block-granular. I know it cannot be file-granular because the zfs has no understanding of how the data within a zvol is structured (ergo, if it were file-granular it would have to treat the entire volume as a single file). If you were to store two full copies of your multi gig files, THAT would be huge.

No one, including SUN (despite what the wonderful and highly knowledgeable folks at MacJournals seem to think http://www.macjournals.com/news/2007/10/07#a80 ), is claiming is that they take up no disk space ( http://docs.sun.com/app/docs/doc/819-5461/6n7ht6qs9?a=view : "Snapshots can be created almost instantly, and initially consume no additional disk space within the pool. However, as data within the active dataset changes, the snapshot consumes disk space by continuing to reference the old data and so prevents the space from being freed."). What I am claiming (I cannot speak for SUN) is that they do not, under normal usage patterns "eat disk space like crazy" (both of these lies MacJournals has claimed at least twice now (once verbatim on the latter)). Further MacJournals' article in response to their statement goes on to completely mischaracterize an comment from Drew Thaler (the thought that 20GB was huge 10 years ago now 200GBs are in things we don't even normally think of as computers, so it is likely that 20TB will be commonplace in the not-to-distant future). While they occasionally have a point (yes,it does increase processor usage, so if your machine is processor starved (or not 64 bit (has OSX gone fully 64 bit yet?)) it might introduce battery issues), most of MacJournals' comments are so ill-informed they do not even qualify as FUD. This source is less reputable then the AppleInsider (and that is saying alot, there were numerous errors in the AppleInsider piece, but common these guys can't even grasp how "standard RAID" (and, as before, 2 is far from standard) works.

Oninoshiko

Macjournals.com clarifies its earlier post.

The AppleInsider article is largely vacuous...

Please do not bother with this debunking (via Macjournals) unless you are truly interested. Thanks.

http://www.macjournals.com/news/2007/10/04.html#a79

Thanks about that publication link,I think it is bad news for my idling colour laser printer ;)

Don't worry, there's a plain text version :-D

Seriously, though, MDJ and MWJ are by far the best, most in-depth publications on Apple and the Mac. Check out the trial subscriptions.

One note: There's been a problem with the ventilation system in the macjournal's publisher's headquarters, so they're pretty taking an unscheduled vacation right now.

If there is a single "neutral" IT publication about Macs, I will pay for it. No kidding...

There is. Now pay :-)

Daringfireball even tried to "Challenge" with Secureworks about this issue. The "language" of URL may give you a clue.

Meh. That was a publicity stunt. Doesn't make the articles any less interesting (or any less true :-)

Or, as in the infamous McDonalds hot coffee case to which you are perhaps alluding, the company may have known about the problem for years and refused to do anything about it. The details of this case are documented all over the web, and they are quite striking.

See, for example,

http://www.fortunecity.com/westwood/vivienne/438/r ants139.html
http://en.wikipedia.org/wiki/Stella_Liebeck
http://friends.macjournals.com/mattd/hotcoffeemyth

In "High Pay, Rotten Returns" (April 28 issue), you peg Apple Computer's Steve Jobs' 2002 compensation at $78.1 million, saying "This amount reflects the value of five million restricted shares Jobs got this year in exchange for 27.5 million underwater options." First, of course, this grant was awarded in 2003, so adding it to Jobs' 2002 compensation is inaccurate. Secondly, according to Apple's press release the grant vests in three years, so assigning it any value today is premature -- no one knows what the stock price will be in three years, and in any case Jobs doesn't have the stock today.

Apparently you wanted to get Jobs at the top of the list of "piggy CEOs". Fine. But how many other CEOs on the list draw an annual salary of $1? (Well, apparently Tom Siebel of Siebel Systems -- but he "sold lots of old options," and turned in others, like Jobs did.)

Fortune sent me a reply saying they're going to print this in the next issue.

It would be a bit of a leap for a UI to go from "pick a song from the list and play it" to "select a song from the list and transfer it to X device" of which there might be more than 2 on the bus. File names, duplicates, permissions, disk-space checks. Plus, people would then want a UI for changing tags and filenames, perhaps.

A can of worms they might open when version 2 of the iPod firmware comes out.

And of course there's pressure on Apple not to make copyright violations super-easy. :)

- Peter