It doesnt happen in exactly the same way with proprietary software. Instead of the developers going off to chase whatever they think is new and exciting, they get sent off every so often to chase what marketing thinks is new and exciting, but either way projects are never finished. Programs which become generally mature, in danger of reaching bug free and feature complete, are always phased out in favor of new and shiny one way or another.

What's the KDE base system? 500 megs or more these days? I havent looked at it in years. But tell me, why would I download and install all that for a window manager when I can get one that works better in less than a meg? Really?

Dont get me wrong, KDE is ok. A lot better than GNOME. But I think it's absolutely ludicrous to talk about installing KDE just to get a WM. Which is what we are talking about. ICEWM, it's even in the name.

"So what exactly does he want?"

What he wants, and your analysis practically fell across it without you ever noticing, is simply someone to do maintenance work so he can keep using the window manager he knows and loves. What's so wrong with that?

The hardest thing would be getting a coder that's mature enough to do the job properly. It would take very little time to simply maintain the mature code and occasionally stomp a bug. Unfortunately if you give this job to a younger coder, regardless of what country he's from, you stand a very high chance of seeing him go crazy wanting to add new features and just screw it all up.

Not that I agree with his original point, but...

"Linux and BSD are a bit different when you get to the console."

Actually they arent. Dont let the default shells fool you. You can get bash on BSD and Zsh on linux. Or you could install ksh on either one for that matter.

If you install and use bash and other gnu tools in preference to the BSD tools, you would wind up with GNU/BSD.

"Right now, in this post, what I am against is bogus arguments either way."

And you did that quite well.

(And if there was a big meta-package I could install on Windows to add all the GNU tools, ported and compiled for Windows, THEN I might talk about GNU/Windows. I keep waiting for someone to package up ReactOS like that to support netbooks, but I digress.)

And btw, I think a big part of why Stallman draws a red line on his terminology here is out of fear of exactly the sort of deliberate confusion that was used above us in this thread. 'Android is linux' is technically true, but since so many people hear 'linux' and think of a fully functioning GNU OS that happens to use linux as the kernel, it's very (deliberately) misleading. Android is really little if any more open than OSX. Both exploit a free kernel by hooking it into unfree userland and incorporating unfree drivers without which it is no longer functional.

First off it's not a DE it's a WM. A Window Manager, not some Detestedesktop Environment.

And while it's not my WM of choice, there is a lot to be said for a WM rather than a DE. It has a lot lower requirements in terms of memory or storage or dependencies, and it also has a lot less junk to get in the way of its core functionality. And since the codebase is smaller it's much less difficult to audit as well.

There are several great old WMs out there that are mature, feature-complete, and nearly bug-free at this point. Companies arent interested (companies make profits selling latest and greatest and herding customers on the upgrade treadmill) and unfortunately in many cases neither are coders (maintaining a project that releases two updates to stomp minor bugs over 3 years does sound slightly boring, and isnt likely to help much in a job interview either I guess.

A lot of people will roll their eyes and talk about how this would supposedly weigh the system down. But it would not have to do so at all. Gnu systems can do this, if you care to set up all the requisite emulators/not-emulators, and dont mind some lack of polish. A modern PC can run all this old software in an emulator without bloating the (by todays standards, extremely modest) requirements of the old software by enough to really notice in most cases. You know why they dont do it?

Because they make money from selling new software. And for decades now they have driven demand for new software by deliberately breaking old software. Just like everyone else in the industry.

"Facebook got rid of something that took away their control over how the users interacted with FB's pages."

The web was specifically designed to prevent that from happening.

And then intentionally gimped to allow it.

Turn off javascript and take back the web.

And in this case the appropriate response would have been to offer him immunity from prosecution to back and testify at the trial for all the other criminals whose actions he exposed. We do that routinely in cases with real bad guys who have no extenuating circumstances or qualities other than their testimony. In Snowdens case, his lawbreaking appears to have been motivated by the highest and most admirable of motivations - a will to obey the oath he took to the Constitution.

Of course the fact is the last thing the powers that be want is to prosecute the other criminals he exposed, which is why they dont want him to come back and will do all they can do discourage rather than encourage his return.

"I was consistently talking about the developers perspective, not the user! "

OK.

"If you think editing configure.ac and Makefile.am files is easy to learn, I bow to your brilliance, but myself and many others don't share this experience."

I dont think it's any harder than lots of other things that developers have to do routinely. Certainly in my experience it is much easier than trying to grapple with e.g. RPM packaging.

"Binary tarballs, as you say, are limited/useless"

I didnt say that at all. They are great! But not all distros are compatible. And it's not the developers job to fix the broken distribution.

" (dependency hell, different architectures)"

Different architectures require recompilation, obviously. Make is the best tool for that. Dependency hell? If I understand you correctly that is a package manager problem. It used to drive me nuts years ago trying to get RedHat to work, but I have used Slackware for decades without seeing anything like it.

"Sorry, but it *is* difficult to get from a compilable program to a distributable program that Linux users can try out easily."

A bare assertion with no logic or evidence behind it that directly contradicts experience.

"You suggest tarballs, meaning configure && make && make install. That means you need to deal with automake and friends which are insanely obscure and hard to learn."

What 'deal with?' What on earth do you mean. You type a command and press enter, a command simple enough you embedded it in your first sentence. If that is 'difficult' for you to 'deal with' I suggest you try something a little simpler than a general purpose computer.

And anyway I said only tarballs I didnt say anything about source tarballs. Binary tarballs are another very easy way to install a program, even easier than source tarballs, although compatibility may be more limited.

"The alternative is to make packages and get them into the offical repos. You have to do that for a couple of distributions, and probably test the installation on them as well. That is a large effort for a developer."

No, as a developer, you should not be making packages (except possibly for the distro you personally use.) Many distributions these days are crufty with proprietary junk and keeping up with all the little peculiarities of each distribution IS actually a lot more effort than typing 'make'. That job is best left in the hands of people who are intimately familiar with their distribution and have the motivation to tolerate its insanities.

That's bad advice. Publish a proper tarball and let Debian customise it for Debian, Ubuntu for Ubuntu, etc. Do one job well, dont try to do everything.

If it's in any way difficult for you to install from a proper tarball then there is something wrong. Perhaps you should try a sane distribution?

Even though I dont agree with you I will commend you for focusing on the key issue instead of chasing down side-alleys. But in fact your analysis, while commonly held, is fundamentally incorrect. These are not biological divisions but simple *statistical differences* - and much, much smaller than the differences between individuals of the same 'race.' You can redraw your *race* lines in a hundred different pseudo-random ways and get several hundred different groups that will all be somewhat mushily distinguishable on the basis of tiny statistical differences but that doesnt mean there is any real biological division there. The difference between two individuals is typically orders of magnitude larger than the differences between these supposed races.

Which indicates clearly they dont really exist. They are socially constructed categories given added and undeserved credibility by the assumption that they reflect a biological reality to which, in fact, they bear little to no resemblance.