Devuan Is Still Moving Along As A Debian Fork Without Systemd

[AJSB]

Besides removing systemd, Devuan could improve the NetwrokMannager or whatever is reponsible to make Net connections using USB 3G4G pens.

Debian was always ubber c**p in that aspect, and i had to use Sakis3g on it (same goes with slackware to be honest and majority of distros).

Only distros that have a decent dialer out-of-thebox for that type of pens is UBUNTU and derivates (and onlt them, only recently) w7o need for Sakis3g.

OTOH, to use sakis3g is not a big deal...but if its to use it , it could/should be integrated in Devuan (like it is in Salix) in the ISO.

However sakis3g is not a full solution...i.e. in SteamOS (and up to now only in SteamOS) , SteamOS dialer can't handle these pens and when using sakis3g, it works for everything like Firefox, but not for Steam itself (witch is completely weird because Sakis3G works perfectly even with Steam client in all other distros like Debian itself, slackware,slaix,etc,etc.)

So, maybe Devuan could use the "Magic Sauce" used by UBUNTU to allow dial with 3G/4G USB pens ?

[Nille]

i'm start to think about payed systemd lovers?

Ofc, everyone that is on the opposite is a payed lover. Special if your opinion as lost. Where do i get my check?

[DeepDayze]

Maybe it's a good time for good ol' SysVinit to get a sensible makeover, and for the life of me why can't Debian give users a choice and have packages that are not dependent on any particular init or login session managment system (Consolekit vs. Logind).

[Nille]

Maybe it's a good time for good ol' SysVinit to get a sensible makeover, and for the life of me why can't Debian give users a choice and have packages that are not dependent on any particular init or login session managment system (Consolekit vs. Logind).

You has the choice. You can do whatever you want but the default is now systemd. You can use any init system what you like or dislike. If you use another init system, every software that need systemd runs then with systemd-shim

[GreatEmerald]

Maybe it's a good time for good ol' SysVinit to get a sensible makeover, and for the life of me why can't Debian give users a choice and have packages that are not dependent on any particular init or login session managment system (Consolekit vs. Logind).

The answer to this question, and many others related to it, can be found in an interactive form here: http://www.phoronix.com/forums/showt...-Wright-format
(Of which I just released part 5! Which touches directly on the ConsoleKit situation, too!)

[CTown]

They just want to own the alternative stack, since nobody else was. It's fine that way, since it gives them a central place to develop their alternative stack and allow developers to continue making their applications portable. This is probably for the best, since it makes everybody happy.

Yeah, I guess you're right. Perhaps they could even solve the problem where init scripts weren't always cross-distribution since they own the entire stack.

Maybe it's a good time for good ol' SysVinit to get a sensible makeover, and for the life of me why can't Debian give users a choice and have packages that are not dependent on any particular init or login session managment system (Consolekit vs. Logind).

The choice was never lost. It's just not all packagers will bother adding the respective init script for that package. One of the final systemd arguments in Debian was whether or not packagers have to include init scripts - the ruling was they don't have to. Even if that init script is included, testing priority goes to the systemd unit since systemd is default.

[SebastianB]

Maybe it's a good time for good ol' SysVinit to get a sensible makeover, and for the life of me why can't Debian give users a choice and have packages that are not dependent on any particular init or login session managment system (Consolekit vs. Logind).

Maybe because its a community distro and no reputable group of guys stepped up and declared themselves willing to shoulder the extra work?

And i don't just mean the whipping together of the various systemd-replacement parts, but also the "im willing to code bug/security fixes for jessies lifetime even if upstream ditches the project half a year from now"-part. Instead of whining a good first step would be forking and reviving consolekit, fixing its issues and give a vote of confidence that it will be a project being around for years so distros can depend on it. Having unmaintained software in your base system is just monumentally stupid.

Sheesh, people talk about this as if it was just about making a decision. You can't just decide to ignore systemd. You can only decide to ignore it AND shoulder all the extra work such a decision implies(your going to end up as upstream for a helluva number of otherwise deprecated packages). I think the devuan guys get that and they have my greatest respect if they pull it off. I hope they get lots of support from the BSD camp aswell, alot of the issues they will need to solve will be common i think.

[mpppp]

pens

I have used 3 usb broadband modems with systemd-less debian and wvdial + USB modeswitch, one needed a newer kernel and modeswitch conf, but it did so with ubuntu too. The init should be irrelevant, but udev config is not.

[mpppp]

Wow, it seems someone who hates systemd is actually putting in the time to make the whole stack to avoid systemd. Alternatives are always great in the long run if something doesn't pan out. However, that still means they will be dependent on one specific stack anyways. Sure, that stack wouldn't be under one "umbrella" project name like systemd but it seems this one project will be upstream for all of these "separate" tools that are necessary to avoid the separate systemd binaries. Was the problem with systemd: (1) it's different or (2) the idea that each binary was going to depend on each other? If they are successful, they will "own" the "non-systemd" stack and it will be the same problem wouldn't?

I think your POV, which I also found with Lennart's replies ("You don't like systemd? write a replacement") kind of forgets the pre-systemd era. Linux became the first server OS and a feasible alternative desktop OS by relying on distro maintainers to adjust packages so they could work together. Systemd pros and cons aside, offering unification and simplification is an option, not the inescapable way forward. We have been duped by the word "progress" and innovation into a worse situation a lot of times already, hell, the whole Free Software movement was aimed to RESTORE software freedom, so it was ultimately reactionary, not revolutionary. Down with change, back to Eden!

[CTown]

I think your POV, which I also found with Lennart's replies ("You don't like systemd? write a replacement") kind of forgets the pre-systemd era. Linux became the first server OS and a feasible alternative desktop OS by relying on distro maintainers to adjust packages so they could work together. Systemd pros and cons aside, offering unification and simplification is an option, not the inescapable way forward. We have been duped by the word "progress" and innovation into a worse situation a lot of times already, hell, the whole Free Software movement was aimed to RESTORE software freedom, so it was ultimately reactionary, not revolutionary. Down with change, back to Eden!

To me Devuan is about progress but not innovation. As discussed earlier in this thread, this project has the potential to integrate the old stack enough to make SOME of the reasons why people went to systemd in the first place less understandable. Hopefully in the future people on Devuan, Slackware, and Gentoo (just using theses distros as examples) can milk the benefits of one single non-systemd Linux boot stack such as cross-distro bug fixes (versus each distro having to maintining forks). That's progress. It may not have the cool new features that are in store for systemd based systemd but as long as people make sure the old stuff is compatible with the software people actually came for (Gnome, Plasma) it wilk survive but without the interest of most people. Since time is money, people who write the higher level software we care about will not cater to every alternative init system. That's where having"the same POV as Lennart" comes from: compatibility with every init stack by a few people is impossible. People who care about the old stack (which most people don't either care about the init and just use whatever is popular or just dislike the old stack) will have to do the work since upstream either didn't have time or doesn't see the point).

tldr: Time is a precious resource and every developer can't worry about being compatible with multiple boot systems. Others who care have to step up and do some of the heavy lifting if they honestly care. That's where these "Unix Vetren Admins" come in.