Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Industry Watch » The Technological

Of Assholes Gadflies Graybeards & Trolls

There sure are a lot of bleating idiots in the Mac community. Time to meet a real frontrunner.


Get It

Try It

One thing's for sure: you don't have to pull a 'John Dvorak' to get the Maccies in a fluster - all you have to do is speak the truth.

Following the article at this site entitled .DS_Store Redux Cro Magnon at the Ars forums starts things off.

The villain who came up with these damn things has now been unmasked - or has unmasked himself. Now OS X users know who to blame for those extra files that turn up in emailed archives and make them look a tit in front of their friends on *nix or Windows machines.

Undoubtedly Cro Magnon is none too happy with .DS_Store. Few people are. Calling Gourdol the 'the villain' might be stretching it a bit as he's only the one who came up with the idea and let the 'bug' stay in there. But Arno Gourdol's long gone to Adobe - it's the others maintaining the code for the past eight years that are going to have to share the blame.

But describing the feeling as 'looking a tit' is spot on. Cro Magnon evidently knows what it means to be a 'good netizen'.

Not so for the flurry of ostriches that follow. And in retrospect it's both unfathomable and totally expected that these community geniuses get everything, literally everything wrong. Some even show evidence of not being able to read (much less to write).

Throughout this typically hysterical Maccie fanboy reaction to the TRUTH Rixstep are called assholes, gadflies, graybeards, and finally trolls.

There are no assholes at Rixstep. No gadflies. No graybeards or trolls.

But there sure are a lot of bleating idiots in the Mac community. At the sign of the least threat they put their heads in the ground and start flapping their wings. Talk about stupid.


Arno Gourdol, instigator of .DS_Store, dressed up for the holiday season. He uses the same kit from 31 October to 31 December each year.

'That article was horrendous', writes dhaveconfig, a uni sysadmin in New South Wales. 'Just because an OS X install may have 20,000 folders, doesn't mean that you're going to be creating that many .DS_Store files.'

No it doesn't, Einstein. But it means you have to dimension your system for that possibility. The article, Herr von Planck, was to give you an idea of the variables involved - not to give you a clue about how much waste there is in your own precious disk space.

'Due to the proliferation of bundles on OS X, there are gazillions of folders no user will ever open, even if they do fulfil [sic] condition a) above.'

Mr Explanatory obviously needs to dig into some of his bundles. [But watch out for if you do you'll drop more .DS_Store doo-doo all over the place - and you won't see it in your file dialogs or in your wretched Finder.]

Perhaps dig down into this monster - it has 175 .DS_Store files for a total of 1,474,560 bytes in GZIP tar files. And that 1,474,560 bytes is just 10 KB shy of the size of the total download.

Any good explanatory for how that happened?

175 .DS_Store files. For 1,474,560 bytes. In GZIP files. Talk about stupid.

dhaveconfig continues to put his foot in his mouth.

he also completely ignores the fact that Apple have given us the ability to turn off .DS_Store creation on network volumes

And it takes not one but TWO reminders from other posters that there is in fact mention of this in the article. Not that it matters: having files like this in the first place is batshit insane as is concocting such a scheme in the first place.

After dhaveconfig's blooper a number of idiots follow in quick succession all claiming 'OMG THE DISK SPACE' - and again totally missing the point.

Or point-S- actually. S. Plural. As they can just about understand what 'disk free space' means they stay there. Getting into multiuser scenarios and a need to redesign the whole thing if it's to work in a LAN or WAN with multiple users logging into the same local machine is beyond their pointy little heads.

Time for NickM to enter the fracas. [Data available at other forums puts NickM at 17 years of age.]

Rixstep is [sic] the rambings [sic] of NeXTStep greybeards, who are even more insufferable than their Classic Mac OS counterparts in their belief that Apple has destroyed their precious operating system.

It isn't a belief, young one.

Intlharvester who fancies himself a 'situationist international' contributes the only worthwhile post in the entire thread.

I just wish they were called .mac_meta or something more descriptive.

Which is an absolutely great idea inasmuch as these files are never to be seen and according to most fanboys never are seen. But the name - the name doesn't have a good ring to it. Something else is needed.

.john_deere

NickM is back.

Agreed, gadflies have their purpose. But I always cringe when I read articles there because they are so full of insults and armchair quarterbacking. The insults of Gruber and Siracusa are extremely petty; I respect their writing, and thus their critiques, much much more.

Cringing fanboys. Cringe! But speaking of the Siracusa...

The linked article is incorrect when it insists that my vision for the Finder is limited to one, and only one set of spatial state for items.

As for implementation, my ideal is to use file system metadata with scoping. Each piece of arbitrarily extensible metadata would be addressed using three pieces of information: the file system object to which it's attached, the user id, and the name of the attribute itself. The APIs that support these attributes should implement 'translucency', allowing a fall-back to system-wide ('null user id') settings if user-specific ones are not present. (Support for groups could also be implemented by including another (again, possibly null) argument.)

As it stands, extended attributes on Mac OS X are addressed only by two arguments: the file system object and the attribute name. But the API described above could be simulated using 'invisible' namespacing on the attribute name itself (much like how ACLs in Mac OS X are implemented using xattrs that are not visible to end-user xattr API calls).

In order for my ideal implementation to be feasible, arbitrarily extensible file system metadata has to be fast and efficient. The implementation of extended attributes in HFS+ is not quite up to the task. (Reading a single .DS_Store file is a lot faster than reading individual extended attributes for each file in HFS+.)

A more conservative implementation would write state information to a database in ~/Library, and possibly write the equivalent of the .DS_Store contents into a single 'big' xattr value on each local directory that user owns.


Now that post is almost intelligent so it deserves an almost intelligent consideration. Admittedly it's difficult to know what Dear John is going on about because he does go on about but basically we're still back to square one: if this is such a great idea, let's see it designed - let's see the actual sketch for how this is going to work.

Let's see users REALLY understand what's at stake and let's see users get the opportunity to test drive it themselves and report back that YES, it was a VAST improvement over the way things have been done up to now and NO, it doesn't mean diddley that Steve Jobs himself hates the idea and NO, there are no factors of scale involved and YES, this architecture will in fact hold for unlimited users on unlimited drives in unlimited network scenarios.

And that they'll still be able to find a way to benefit by it.

'Oh yeah! Of course! That's my blah-blah folder! It always comes up at an X offset of 142 and a Y offset of 268! I recognised it immediately! And I know it's not the NONSENSE folder because that one comes up at an X offset of 145 and a Y offset of 286!'

And then let's go ahead and design it. And lest we forget, we'll have to rip that FileInfo and FolderInfo out of HFS and put it somewheres else too - either that or we'll have to rip the entire HFS (RIP all right) and come up with an entirely new file system. And we can't just use someone else's file system either for no one else would ever think of putting such crapola in a file system.

Poor Ken Thompson. Here he was designing a system that was deliberately simple and therefore elegant and robust - and now we have the besserwisser wannabes coming along who are going to set poor Ken right.

Well we're waiting. Ken probably is too. He might even like the idea of metadata. To a certain extent.

But he probably loves farce even more.

But that's all conjecture anyway, innit? Because there's no way these ponces are ever going to be able to do anything of the sort.

In order for my ideal implementation to be feasible, arbitrarily extensible file system metadata has to be fast and efficient.

Notice that he hasn't designed SHIT. He's actually stating a truism and no more. But it's up to him to design it - and later we can certainly remind him it has to be 'fast and efficient'.

In the meantime we can just kick back and cringe a little for ourselves.

  • Over how John Siracusa roused the rabble against Avie Tevanian, Steve Jobs, and Apple over their admonition to OS X developers and users to be good netizens.
  • Over how that madman started an online protest against the above individuals and entities.
  • Over how the Goober attacks Dan Gillmor, Brian Krebs, Kieren McCarthy, George Ou, Andrew Stone, and Avie Tevanian - all highly respected industry players as opposed to the Goob Boob - on several occasions.
  • Over how the GOOB dared venture into a high brow forum for REAL techies and almost literally got his daring head chewed off - to the extent he's today known in the security industry as 'Daring Phucball'.

Assholes, gadflies, graybeards, and trolls? They've got all that - and all the cringing they need - at home.

Their cringing little 2% demographic gayPod fanboy home.

Talk about pathetic. Talk about stupid.

Ah but that's enough about them. One could go on forever. About the 'Brian Krebs Watch' blog which was dedicated to getting Brian fired from the Washington Post because he claimed he'd seen an exploit against an Apple computer. Or about the way the Goober grayshirts bombed Brian's mailbox and defaced his blog. Or about the way the grayshirts harass the employers of others who dare criticise Apple in any way - and in at least two cases have got their targets sacked. For saying something about Apple.

But at the end of the day, unless you're doing PhD research in abnormal psychology, they're not worth it - they're just not that important.

They're just something you scrape off the bottom of your shoe.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.