* Mount flash drives automatically when I plug them in.
* Let users configure the wireless network connection, and set it to automatically reconnect with the same settings to different APs on the same network, and let users override certificate settings for the same, and remember the overridden settings.
* Let users configure printer settings.
Sure, dwm is great if you spend all of your time in xterm and emacs/vim. But I spend at least 0.02% of my time doing the above tasks, and I don't want to inflate that number.
Some people believe that the fewer lines of code they write, the more elegant their software becomes. Bull. Just like writing more lines doesn't make your code better, writing fewer lines doesn't make it better.
Shouldn't the OS handle most of those things, or perhaps some app?
I read the argument as "Gnome versus dwm", not as "Metacity versus dwm".
Every moment of my life that I spend editing fstab, running mount commands, or scripting my system is a moment that I could spend doing anything else. If I install Gnome, it will automount USB drives with no intervention on my part. Call this "low interface complexity." The same thing happens on OS X and Windows.
Now remember that it's not just about automounting. It's about monitor calibration, input devices, keyboard layouts, text conversion software, assistive technologies, wireless network configuration, printer configuration, etc. "Myriad" is a good word here.
If I uninstall Gnome, all of those tasks get shoved into the "unsolved" category, except for one — window management. For each task I have to find an application for it, compare different applications that solve the same task, and configure it. If it's something that has to always run in the background, like automounting, then I have to figure out a way to make it start when I log in. Call this "high interface complexity."
What I'd like to get across is this: optimizing for the number of lines of code is the wrong thing to optimize for. It's wrong (incorrect) to optimize for a large number of lines of code, and it's wrong (incorrect) to optimize for a small number of lines of code. Lines of code is a poor metric for almost everything, with the exception of bug count.
You should always be optimizing for "quality of life". If your idea of a higher quality of life is using a more minimalistic window manager, then what we have is a disagreement of a spiritual nature.
To me, Gnome sucks less than dwm by a mile.
And yes, I still know that Gnome is a desktop environment and dwm is a window manager.
And you know what? We're both correct and have good arguments.
The point is: _your_ use case, habits, needs...
So now let us compare and discuss whether bricks or helium are better for doing the dessert topping...or was that a floor wax?
Citation needed.
Can't imagine one. People like that don't do open source.
Now, if you still want a citation here's one... http://upload.wikimedia.org/wikipedia/commons/5/5b/Cessna_ci...
[0]: http://programmers.stackexchange.com/questions/154733/my-bos...
Anyway, you seem to have some anger management issues and this is not the place to sort it out. You should look for help.
"Write beautifully clean and minimal C code" seems to me just as detached from "just ship the damn thing!" as doing massively multi-inheritanced templated C++ architecture, albeit in the opposite direction.
C is great, but it does make foot amputation rather easy for some people.
If I have a choice of two pieces of software: (1) having a lot of features, not-too-bad start-up time, usable UI, and good compatibility with other software I need to use. (2) missing some important feature, fast start up, pretty UI, poor compatibility. Then I (and nearly everyone else) is going to choose option 1. Best example of this is, obviously, Microsoft Windows.
Comes down to something simple: the only people who care about the quality of the code are those who have to look at the code. Everyone else is only interested in the surface layer, and sometimes even bad code doesn't show up on the surface if it's been battle-hardened with enough bug fixes.
In the end, good UI, proper testing and responsive customer support play a bigger role in customer satisfaction than the quality of code.
No, but a lot of people (especially managers trying to get promoted via over-ambitious IT projects) set out to write Big Code, which goes that way almost always.
In the end, good UI, proper testing and responsive customer support play a bigger role in customer satisfaction than the quality of code.
If you've been in the enterprise long enough, you've learned that some systems are so far gone in code quality that keeping the UI and customer support up to date becomes impossible. Fixing one bug creates two more.
