Live data from Hacker News

Death to .DS_Store

aorensoftware.com

91–100 of 127 posts

Re: Death to .DS_Store

#91
post #89

Earlier quoted context omitted.

Windows has always had more configuration than OSX. OSX - supposed to be simple to use and the defaults are supposed to "just work" and make sense to most people (drag an "icon" to the "trash" to "uninstall" it made no sense to me) Linux (old-school) - made for users who care about the details and will take days or weeks to set up their system. Arch is still like this. Stuff adheres to philosophical standards and POS…

> OSX - supposed to be simple to use and the defaults are supposed to "just work" and make sense to most people (drag an "icon" to the "trash" to "uninstall" it made no sense to me) Application installation is the confusing part (stupid DMGs), but what's wrong with moving something to the trash to delete it? That's what you do with files, why should applications be different? You are confused by it just because you'v…

I can go on for days on how the Windows installation process is broken (icons in the start menu, desktop, AND quick launch bar), but it can be a pleasant experience. The msi installer has the flexibility to have 0 UI screens. Just install and then exit. But the defaults are about 5 screens the user doesn't care about or want.

Mac has problems too. Ive been bit by the uninstall process more than once. What does a normal user do when they drag an app to the trash and it doesn't uninstall?

Actually I don't think any OS has solved installation completely. Android leaves configuration files cluttering up your sd card.

Re: Death to .DS_Store

#92
post #28

Junk files like this being littered across filesystems just wreak of extremely poor software engineering. I would love to see Apple stop writing software and operating systems and just stick to hardware.

And what, be yet another Windows OEM? Lots of people have had that bright idea in the last 15 years. No thanks, there are enough of those already. This aspect of OS X sucks but it doesn't mean they should stop making software altogether. That is ludicrous. Lazy, lazy thinking.

I don't think it's the lone anti-feature that causes this "ludicrous, lazy" thinking. Apple software is absolutely full of inflexible, careless and/or poorly conceived anti-features.

Not to worry though, it only took them 20 years to decide that multiple-button mice, omni-sided window sizing and full-screen apps were at all useful. I'm sure that the removal of .DS_Store will be celebrated as a great new feature of Pious Puma in a decade or so.

Re: Death to .DS_Store

#93

Earlier quoted context omitted.

It is a bit stupid... Surely just loading that small article WP must be thrashing their database. This works (for now): http://viewtext.org/article?url=http%3A%2F%2Fwww.aorensoftwa...

This'll work forever: http://cache.historious.net/cached/1628132/

That's what they said about Yucca Mountain and time_t!

Re: Death to .DS_Store

#94
post #90

Earlier quoted context omitted.

A huge improvement on the previous .ini files and something still unmatched in the Mac or Linux worlds with config in arbitrary locations and formats (which, incidentally, let anyone write anything anywhere in a similar fashion). You are a little wrong there about Linux. Nearly all configuration files are in one of two places, /etc or dot folders in the root of my home folder. I can't write to the files in /etc as a…

"Nearly all configuration files are in one of two places" That's entirely incorrect. There are many, many programs out there that do not follow the convention.

I can think of no system services that don't use /etc. As for user programs, the only real things that I can think of breaking this convention are small projects that store their configuration files with the binary; usually small programs that run from their own directory. Would you care to elaborate on where these other programs choose to store their configuration?

Re: Death to .DS_Store

#95
post #53

Earlier quoted context omitted.

In Mac OS X you can (or could at one time) attach extra meaningful data to a file, classically known as the "Resource Fork". In the pre-OS X days applications were often bundled by placing images, audio, etc. in the application file's resource fork. I remember in the 90's finding an application that had a huge (for its day) multi-megabyte resource fork, but only a few kilobytes of program data in the data fork. That…

It doesn't matter if modern programs can read _macosx, the problem is modern applications creating them. Since they store useless metadata these days, there is no reason not to stop default creation of them.

My point is that they sometimes do store critical file data.

Re: Death to .DS_Store

#96
Path Finder is a fantastic Finder replacement, far more powerful, and does not create .DS_Store files. Highly recommended.

Re: Death to .DS_Store

#99

Junk files like this being littered across filesystems just wreak of extremely poor software engineering. I would love to see Apple stop writing software and operating systems and just stick to hardware.

Oh, please. This is a two way street. Ever tried backing up a bunch of Windows-based Office files to a Mac? Umpteen million temp files for each real file is a real win for users. See for yourself what kind of fun people are having with that: http://duckduckgo.com/?q=office+temp+files

Re: Death to .DS_Store

#100
post #6

Earlier quoted context omitted.

Since Linux has no such construct by default. Does that make it the most user-friendly?

Many programs do something similar, for example vim creates file~ as backups. Using a graphical file manager, these used to annoy me. After switching to a terminal for file management, I can easily ignore them as if they weren't there.

What I ended up doing was having vim save backups and temp files to ~/.vim/backup and ~/.vim/tmp by adding this to my .vimrc:

    set backupdir=~/.vim/backup
    set directory=~/.vim/tmp
Of course these can also be relative paths so you can have a project save these to a local .backup directory too if you want to keep them near the files they relate to.
Post reply on HN