New Group Calls For Boycotting Systemd

[ihatemichael]

[interested]

No. I have already explained where the problems come from, but since you have already admitted you are not good at these things do I not expect you to understand them, but to take my word for it. Debian still uses much of the sysv init process to boot up and systemd is also doing far more than just replacing the init process. You cannot use your half-knowledge to declare everybody else's software as "spaghetti" code. You believe systemd is all right and conclude everything else must therefore be wrong. This however does not give you competence, nor does looking towards others give you this. You need to start looking into it to see what it does.

Debian "Jessie", the first Debian with systemd as primary init-system, hasn't been released yet. I am sure that several SysVinit scripts will still hang around for this release, not a problem because systemd is backwards compatible (Fedora did the same). But sooner or later all services will be converted and the SysVinit scripts will wither away. There will never again be a Debian Linux release using SysVinit. This pattern is repeated all over the Linux world with CentOS, Ubuntu, SuSE etc. SysVinit is being killed of everywhere and usually replaced with systemd.

Regarding that some SysVinit scripts are horrible spaghetti code, and that SysVinit is a bad concept that deserves to die, and that SysVinit scripts are hard and error prone to maintain, then please remember, that these aren't my observations, but what Debian developers and Members of the Debian Technical Committee, and many other distro maintainers and developers have said. Again, SysVinit is being killed off everywhere at the moment for the very same reasons.

Trying to defend SysVinit as the future for Linux is a rather futile cause with very few takers. I totally welcome people/distros that wants to use other init systems than systemd, I just don't see any of the necessary development taking place for doing that at the moment.

[sdack]

Debian "Jessie", the first Debian with systemd as primary init-system, hasn't been released yet. I am sure that several SysVinit scripts will still hang around for this release, not a problem because systemd is backwards compatible (Fedora did the same). But sooner or later all services will be converted and the SysVinit scripts will wither away. There will never again be a Debian Linux release using SysVinit. This pattern is repeated all over the Linux world with CentOS, Ubuntu, SuSE etc. SysVinit is being killed of everywhere and usually replaced with systemd.

Regarding that some SysVinit scripts are horrible spaghetti code, and that SysVinit is a bad concept that deserves to die, and that SysVinit scripts are hard and error prone to maintain, then please remember, that these aren't my observations, but what Debian developers and Members of the Debian Technical Committee, and many other distro maintainers and developers have said. Again, SysVinit is being killed off everywhere at the moment for the very same reasons.

Trying to defend SysVinit as the future for Linux is a rather futile cause with very few takers. I totally welcome people/distros that wants to use other init systems than systemd, I just don't see any of the necessary development taking place for doing that at the moment.

Now you come across like some crazy, mad man. Your foes will wither away, they deserve to die, but they are welcome to challenge you, The Great Muhahahaha ...

One can only teach those who want to learn.

[interested]

Now you come across like some crazy, mad man. Your foes will wither away, they deserve to die, but they are welcome to challenge you, The Great Muhahahaha ...

One can only teach those who want to learn.

I am only stating the present known facts about what is going on. Yes, I used a verbal hammer trying to get my message across about the fact that SysVinit hasn't got a future with Linux.

I am genuinely interested in hearing what you think is the future of SysVinit, what distributions do you know who are dedicated to supporting SysVinit in new releases in the future? And what do think developers will do to help upstream projects like KDE or LXQT to support SysVinit systems in the future (like developing an alternative to ConsoleKit/logind).

As I see it, the SysVinit proponents are utterly split and disorganised, with no coordinated effort to even analyse situation, or to develop the necessary infrastructure to keep SysVinit going on. Do you even have an inter distro mailing list or similar?

[gens]

As I see it, the SysVinit proponents are utterly split and disorganised, with no coordinated effort to even analyse situation, or to develop the necessary infrastructure to keep SysVinit going on. Do you even have an inter distro mailing list or similar?

that's the point
it is called "modular programming"
for example i seen someone doing an logind replacement, and they don't have to talk to anybody to make it work good on any system

like if i have a plan for a udev kind of thing, i don't have to ask no overlord if i can
nor would i write it to be rejected because "it is not in line with our vision" or "we have not got around to that part" (or just simple ignoring)

init is an init
nothing more, nothing less
and if you want to see it used properly check out slackware's BSD style init scripts, and you will find that an init is actually something really simple
(ugliest part is compatibility with fedoras sysvinit style; and yes, you could have used rpm's from fedora on slackware)


linux was always a loosely coupled amalgamation of hackers from around the world
it was (and still is for a part) always about freedom (of programming) and everything worked with everything
so if one hacker from, idk, Peru made some ingenious program, the program would work on anybody's computer

[sdack]

I am only stating the present known facts about what is going on. Yes, I used a verbal hammer trying to get my message across about the fact that SysVinit hasn't got a future with Linux.

I am genuinely interested in hearing what you think is the future of SysVinit, what distributions do you know who are dedicated to supporting SysVinit in new releases in the future? And what do think developers will do to help upstream projects like KDE or LXQT to support SysVinit systems in the future (like developing an alternative to ConsoleKit/logind).

As I see it, the SysVinit proponents are utterly split and disorganised, with no coordinated effort to even analyse situation, or to develop the necessary infrastructure to keep SysVinit going on. Do you even have an inter distro mailing list or similar?

It is not about the future. It is about the mistakes we have made in the past and that sysvinit is a solution to much older problems, which you only do not know about. systemd works at present, because it inherits from it, but it allows older problems to come back again, too. This is what people have been saying here over and over again. You just did not want to know about it. Do you really want to know what will happen?

[erendorn]

linux was always a loosely coupled amalgamation of hackers from around the world
it was (and still is for a part) always about freedom (of programming) and everything worked with everything
so if one hacker from, idk, Peru made some ingenious program, the program would work on anybody's computer

I don't really think linux as a kernel is very modular. At least not more modular than the systemd project.

[gens]

I don't really think linux as a kernel is very modular. At least not more modular than the systemd project.

that is the kernel, and it is in its own way
it's kinda like shared libraries, but treated as processes
example http://stackoverflow.com/questions/1...-with-a-module

the kernel has to be that way for performance reasons
fully modular kernels like the gnu hurd/mach have their own micro-kernel specific problems

anyway i was talking about the user space (init is in user space, so are other daemons)
"low" level user-space... things usually just set up the kernel then go for.. idk a wank

example daemon that sets up the network
it asks the kernel for interface information, asks the kernel to set them up and idk report changes back
although by that point it can even just exit and the network would work
it has no reason to care what is on what PID
it only cares about the orders from configuration files/interfaces and the kernel API

as for notifying when the set up is done, it can (and some do) daemonize itself only after it set it up
and all dem inits get faster boots from that, simple

[prodigy_]

Okay, Lennart haters! What did you use when Ulrich Drepper was the maintainer of glibc? You could not use glibc, because maintainer was a dick.

You got it all backwards, bro. We don't hate Lennart for being a dick. We hate him for being a Red Hat guy who cares only about Red Hat (and his own) interests and spits on the community three times before breakfast.

Back when he was ruining low priority subsystems like audio and writing annoying crap like avahi, his presence was frustrating but tolerable. But now he's a system daemon maintainer. If you don't see a conflict of interests here, you need new glasses.

[Zetbo]

You got it all backwards, bro. We don't hate Lennart for being a dick. We hate him for being a Red Hat guy who cares only about Red Hat (and his own) interests and spits on the community three times before breakfast.

Back when he was ruining low priority subsystems like audio and writing annoying crap like avahi, his presence was frustrating but tolerable. But now he's a system daemon maintainer. If you don't see a conflict of interests here, you need new glasses.

I've been following these systemd threads long enough to know that you are a troll, but I'm gonna answer you anyway. So Lennart unified linux userspace audio with Pulseaudio and that's a bad thing? Before we had aRts and esd, which were quite crap compared to Pulseaudio. You should probably stop using Linux, if you think that Red Hat is a problem here. They maintain lot of low level linux pluming. Systemd is not even a Red Hat project and has contributers all over the community.