That's interesting... The PC equivalent is thumbs.db, which can be disabled through a simple OS option. One of those rare occasions where a PC is actually more user-friendly than a Mac. Oh wait, did I just open Pandora's box?
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 POSIX.
Linux (new-school) - trying to be like OSX with the "sane defaults; just works in most cases" but also tweak-able as much or as little as you like. Fedora 16 is my current weapon of choice for work/dev.
Windows - the "bloated swiss army knife". It's trying to have the "sane defaults" of OSX with the configurability of Linux, but the architecture is all stupid and you get error codes in hexidecimal that say "an unknown error has occurred!". Going back to Windows after OSX or Linux is pretty awful, honestly. Really the only thing it has going for it would be "it's popular", so it's likely that someone else also had error 0x8BADF00D and knew how to fix it. Hating aside, Windows being not open-source really hurts when you're trying to fix/debug something -- you can tail the error logs until the cows come home, but unless you're a Microsoft developer, it'll probably be pretty opaque (OSX is sometimes bad about this too -- ever have fun with KEXT bingo?)
The solution, obviously, is to just have a damn cache of these somewhere ELSE on the system (but not the registry, because the registry was one of the worst software ideas OF ALL TIME. What other critical system database lets anything write to anywhere at any time? Smart, guys, smart...)
You must be thinking of the Linux fantasists registry, not the real one, as the real registry has Windows ACLs and users can only write to HKCU by default, admin rights are needed to write to HKLM or HKCR.
And "one of the worst ideas of all time" provided a system-wide centralised, standardised configuration database accessible from vbscript and command line, as well as app code, with user specific settings migratable between computers, values configurable by group policy from a central company wide location with MS supplied or customisable templates. 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).
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 user, and the config files in my home folder only apply to me. (Incidentally, since most Windows users at home run as administrator, they have access to the system configurations).
Personally, I don't like the registry because it is a binary blob (and having .ini files spread everywhere is much worse). I like human editable configuration files spread out in a folder hierarchy. I can use the same tools to modify configurations as everything else, as (nearly) everything is a file. I modify configurations with a text editor, I copy the configurations as files etc. It also allows me to get a better understanding of the configurations, since I can easily have comments and can literally copy and paste between text editors to migrate partial configurations.
In terms of a networking environment, applying configurations from a central user server is probably easier with windows due to the nature of the registry. However, due to the separation of system and user configuration on Linux, this is not an issue. You have /etc configuration as part of a 'system image', and can update this using tools like puppet. Then you have your user configuration migrate with a users network filesystem.
> (Incidentally, since most Windows users at home run as administrator, they have access to the system configurations).
Most UNIX users at home have sudo permissions - unless someone else is using you're computer there's no difference in typing a password compared to confirming a UAC prompt.
As part of the registry clutter backlash there has been a tendency for Windows applications to store settings in user or system-wide app data directories. I'm still not convinced by the move, but obviously it's the only way to achieve portable installs without using two different storage backends to support it.
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?
Not unusual for third party software to have configuration files elsewhere though. You see this a lot with "Enterprise" java stuff, typically config files in XML scattered around the installation directory.
You hit the nail on the head. As an Arch user, I find pleasure in configuring a clean system, and indeed I've been continually doing it for years. Since it's natural behavior for me, I find it all too easy to forget that most people, including the technically inclined, consider such constant tweaking to be undesirable. So as much as I want to say, "Folks, stop using Apple products -- for their SOPA support, for .DS_Store, for being un-Unixy, for an endless list of other reasons", I have to recognize that my values as a computer user are completely out-of-line with the people who find Apple's selling points to be attractive. The OP, however, sounds like he may be ready for a Linux or BSD.
>
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've been trained to think that install and uninstall are specific procedures, but since apps are bundles on the Mac, the procedure could in theory be just a copy and delete.
Too bad practice is always more complicated than theory.
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.
It's not opening up a Pandora's box to say that Windows is more user-friendly than a Mac in some aspects, and anyway you're using the phrase "rare occasion".
Having said that, your example is bad because:
- your "simple os option" is hidden in an advanced administrative tool called "Local Group Policy Tool" (or previously Registry)
- OS X has the same disable .DS_Store option hidden in a similar administrative interface (Terminal + defaults write ...)
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.
I found Krusader to be superior to Dolphin, but that's perhaps I'm used to old two-pane way of file management (Midnight Commander, Norton/Volkov Commander, Windows Commander)
