-- Hávamál

Relax. If it comes to that, it will be because we'll be much worse off without it. Remember: In Patrick we trust.

You really *should* try that, I can tell you would be shocked and amazed at the results.

If you could manage to do it without conveying your disdain to the pupils, that is.

For many less technical users (as well as, obviously, those on the other end of the spectrum) simplicity is valuable.

4. Own a company where you have plentiful workers that have a disdain for stable system software. Invent a project to embrace, extend, extinguish said software. This is easy since, the stable software maintainers (random independent OSS devs) don't get paid for stable software (i.e. there is nothing to do, therefore no income anyway), and are easily demoralized. The prior maintainers are more than willing to hand over (or don't have a PR budget to make their existence known.) Your workers are more than eager to program replacements. Destabilize more software, and create a bunch more projects to keep the momentum going.

I have asked before why any linux user who doesn't want systemd has to be doing something to replace systemd (the choices 1-3 you give focuses on us, the users). Strangely enough, any proposal in 1-3 has to be doing something just like systemd does, to justify 1-3 when it comes to this discussion. This only helps justify systemd! The reason why #4 works, as bad as it sounds, is that there is leadership there--someone in the position to bring about change. It's also one that doesn't give a crap, nor pretend to be their competitor.

I do not think that our response to systemd/RedHat is a technical one. I think that we first need someone in the position of leadership to tackle the software management problem causing the runaway change-for-a-sake-of-change going on by Red Hat. This is not something any discussion here has managed to produce so far, nor do I think this is the proper forum. In fact, once we solve that, then all technical discussions are moot.

Ah, you have the "OpenBSD" in your sidebar there, so your post is driven home with a sledgehammer. I installed OpenBSD to my eldest PC last week and thought, "Sheesh, this is minimal! I'll need my FreeBSD 6.x skills to adapt to this one...and then some!" You may be correct, and Slackware might become the nonsense-free server distribution, a great reputation to have, indeed.

To answer your question directly, you never know who your next customer will be. I choose a combination Fluxbox and Xfce at work, Xfce and Windowmaker at home. But that's my own choice, and personally, I think that Xfce is slightly underpowered and wonder why there hasn't been a new release lately. It's certainly not perfect yet. Somebody out there is going to want the kinds of things that KDE provides. I used to use KDE 1.x up to KDE 3.x and really liked them. It's KDE 4 that drove me downwards.

Now you are just bein obtuse
 

Different people have different needs. The work I do requires lots of technical report writing. Could I do it all in joe or nano + TEX; sure. I am pretty darn sure my Abiword + Gnumeric + Dia on XFCE cocktail lets me work more effectively and get the results I want faster. I frequently need to script stuff out and develop POCs but rarely need to build large complex applications or collaborate with other developers these days so I do must of my work with joe writing in ruby or Codeblocks writing C. If I were still doing Java work or even larger C/C++ projects I am sure I'd use a bigger badder IDE like IDEA or Eclipse and even consider Visual Studio in a VM.

Sometimes less is more, I don't use OO because the software I mentioned has the feature set I need and stays out of the way, similarly joe gives me my syntax highlighting and lets me script with little fuss. That does not make the other tools bad or useless though, I would use them if my needs were different. A more integrated Desktop Environment than a WindowManger alone can provide is very useful to lots of people. It isn't about being "spoiled." Slackware can't be all things to all people but it has always been a flexible platform that can be tuned to *many* peoples needs. Having to drop the DEs would make it a poorer distro for a large portion of its user base.

Now I like Init, I don't see systemd offering me anything useful but coming with plenty that will potentially get in my way. That said if avoiding systemd will mean having to drop a bunch of other software that lots of people do like, some of which I like than I'd say bring on the systemd. Hopefully it won't be the case that systemd becomes a hard dependency so many places good alternatives that work with contemporary projects can't be found. Just as has been the case with PAM for the most part; we will see. This FUD thread won't change a thing either way though.

Your argument though is essentially everything that we have now but did not have 18 years ago is worthless. That is silly. I know how to use sftp just fine, I like being able to drag and drop files between ssh hosts in Thunar. I have been on Slackware for over 15 years. It was cool and slick as anything to play with back in the day. I am not so foolish as to think I'd be happy still running Slackware 4.0 with security updates; I am sure you would find that you miss things too.

Change for the sake of instituting change can be a mixed bag. On one hand it can be good, while equally it can be destructive to projects and ecosystems. However, Red Hat should not be allowed to simply swallow up projects or replace projects with their own code, just because they feel they can. We don't need GNU/Linux to end up being 100% developed by Red Hat who then could change their stance with FOSS and suddenly turn a Microsoft on us.

I don't think Red Hat is the primary factor. Just a major factor, since they have the resource to take on a large portion of the unmaintained ecosystem. I've seen projects created in the corporate world that simply take a life of its own. They are destructive because ambitions expand the size and complexity. We are a receiver of it in this instance since the software is freely available, but also the constant deprecation tactics coming down. I think leadership change would help calm the warring factions. Not a leadership change at Red Hat, but at multiple levels. There isn't much we can do here, as users, or at the distribution level, since systemd ignores the distribution level. The technical argument has clearly not helped. I'll just again reaffirm my call for leadership at a high enough level.

If you could suggest that all systemd bugs are related to social justice, you'll get Lennart's attention...

https://bugs.freedesktop.org/show_bug.cgi?id=85401

I think I can see start to why people like Linus Torvalds and Theo de Raadt go on hell bending rages at times against fly-by-night developers trying to make a name for themselves as well as companies who think they're too important to have limits.

Good on them for a) being aware of that and b) fixing it so quickly.

And doing that makes you any better how?

:facedesk:

That's just horrible. Not only do they attack Linux, but English itself does not escape their assault.

I'm helping him to see the hypocrisy of his statement.

In this thread please argue over facts (not unfounded opinions, hearsay or any "information" you can't back up) and please keep this thread on topic from now on. No exceptions.

If you want to prevent users from leaving Slackware due to a switch to systemd (which at this point still is fictional) you will have to keep Slackware in a state where upstream projects are able to run on it without having to switch to systemd. That is the whole point and it is indeed a technical one. Upstream developers use systemd because it makes their work easier and at least some of them remove existing alternative codepaths because the software those codepaths rely on is unmaintained.

So for Slackware (and other distros that don't use systemd) it is necessary to either maintain those codepaths and the underlying software themselves, or provide an alternative that is viable for Slackware and appealing to the users that possibly want to switch and at the same time provides the functionality upstream wants, or a replacement that is interface compatible with systemd has to be provided (for example systembsd+afor now not existing kdbus userspace). It is not systemd's leadership that makes other projects use it, it is the provided functionality, so if you want to prevent Slackers from leaving due to a (again, still fictional) switch to systemd you will have to provide functionality, in a way acceptable for both, Slackware and its users and upstream developers.