Congrats for following through on Devuan. I'm guessing it took a lot of resolve to make this happen.
Should we be worried about the fact that it took over two years to untangle systemd from Debian with respect to Linux in general?
In case someone from the Devuan project is around,
what alternate init system should maintainers be targetting now for Devuan? OpenRC, classic SysV init, or something else?
> Should we be worried about the fact that it took over two years to untangle systemd from Debian with respect to Linux in general?
The time it took says nothing about the difficulty of the task. It could be very hard with the best hackers working on it full time. It could be the time it takes committees to reach a consensus.
Even if it was that hard, is it because systemd is so entangled with the system? Or because it makes maintaining a distro so much easier ?
> Or because it makes maintaining a distro so much easier ?
In my experience, such a general statement is not true of any init system. I had to maintain a systemd-based system (albeit not a general-purpose one) and I was moderately happy. The profiling tools are great and units are easy to write even by people with no Linux development experience (hint: easy to outsource to cheap consultancy firms). On the other hand, it's extremely complex; if you get into trouble with systemd itself, you've got a lot of code reading to do. systemd upstream itself is a pretty volatile target, so you regularly end up with things that used to work three versions ago but now bork.
Maybe for a general-purpose distribution like Debian, or for a special-purpose, but server-/cloud-oriented distribution, it makes life easier, but at the other end of the spectrum I wouldn't say it made my life any easier than other init system (albeit not much harder, either).
you're point is well-taken, but I think it says something. It just doesn't necessarily mean that it's a messy, entagled system which is deeply integrated and hard to isolate.
but it does point, circumstantially, in that direction.
It might also point into the direction that the people behind Devuan have never worked on a distribution before and needed quite a bit of time to figure out how stuff works.
Good question. The proof will be in how rapidly they track their upstream going forward. If it was a mostly one-time transitional task, then future releases should come more quickly. They may also have taken extra time to polish because the quality of the 1.0 release will have a huge impact on how many people decide to dive in and support future development. If there are major problems, they could sour a bunch of fence-sitters. But if it works great, they may gain momentum.
From https://devuan.org/os/ it seems they use sysvinit by default, but they 'offer' runit, openrc and sinit. Dunno what the latter means for maintainers...
I never understood why the Devuan developers could not just contribute their work to Debian directly. Yes, systemd had become the default init system, but the idea that other developers would oppose contributions that would do nothing but improve interoperability is just absurd.
To me, this whole "we're forking Debian" thing just feels like a strongly emotional opposition to systemd, not rational solution to the init system problem.
They were told to by debian. They argued for as long as they could while debian was still 'their' distribution to change the direction systemd would take it. It was clean that wasn't going to happen. Final response; "If you don't like it you can always fork. But you'll never release anything."
So now they have forked and they have released. So now their splitters. Cake and eat it types, what can you do?
I don't follow. Are you saying that representatives of the Debian project refused to collaborate with the Devuan developers with regards to improving init system interoperability?
Where does that support the claim that
Debian would oppose people working on
sysvinit support?
In the body of the other[2] email where 'Option 2 "Support for other init systems is recommended, but not mandatory"' was selected by the Debian community. Once this path was chosen, while it theoretically isn't opposition, in practice it was only a matter of time before non-systemd init systems would become increasingly difficult to use in a systemd-leaning distribution (sysvinit or otherwise).
As Manfred Eigen said:
In theory, there is no difference
between theory and practice. But,
in practice, there is.
For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian. That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.
As far as i know, systemd is creeping in as a dependency of a lot of unrelated packages - even UI packages. So you can have a Debian that doesn't run systemd, perhaps, but not a Debian that doesn't depend on bits of pieces of the systemd OS any more.
You have a tiny systemd library which does little more than checking if systemd is running. It's a helper library for doing that check. Within Devuan they didn't want this dependency, but that's unrelated from being able to use software under another init system.
There's a huge difference between not accepting any dependency with systemd in the name vs being able to use another init system.
That some software has a dependency does NOT mean that the software is restricted to only run under systemd.
the entire point of devuan (iiuc) is to have a clean separation of function. if systemd is a wide dependency, then the separation of the init system is a bit superficial and isn't what the distro cares about.
But these are hard deps not just recommends so will pull in systemd dependencies regardless of it using them or not. If it were a recomends type dep, again no one would have a problem. It used to be considered bad packaging to hard dep when recommends or suggests would suffice.
7.2 states: "When selecting which level of dependency to use you should consider how important the depended-on package is to the functionality of the one declaring the dependency"
You say "being able to use software under another init system." Looks like the level of dependency should be adjusted to fit your point.
You might want to learn how shared libraries work under Linux. Then you might be able to understand why packages have a Depends: libsystemd0 (which btw. doesn't depend on systemd itself).
My point is more that systemd makes less sense if you think of it as just init. "Why does init need to manage -foo-?" is a valid question. But "Why does a general 'system daemon' need to manage -foo-?" tends to be self-answering.
It's great that they have released and it's important there are options so users are not locked-in to a single init.
We need to do more to ensure projects do not create lock-ins especially gratuitous ones from single companies that make it difficult for people to use for instance Gnome without systemd.
This kind of lock-in can only lead to bad outcomes and make developing future alternatives and improvements more difficult.
Also its time Systemd defines a scope and decouple and brand any additional functionality beyond an init differently so it makes it easier to inter-operate and pick and choose both for users or distributions. Or you have distributions like Debian for instance voting for an init system but getting all the externalities that were not voted for ending up becoming defacto choices.
I am not Linux admin, but I've been using Linux managed by others on servers for many, many years and I have a question: Is that 'systemd' thing is so crucial and important to devote so much effort to create brand new Linux distribution.
I have only vague picture what systemd is doing, I can imagine that there could be something better (as always in IT), but is this really that important?
For most users, it wouldn't matter anyway, and I'd argue that that's true even for a lot of the sysadmins. But the argument had a few layers more. Quite a few people agreed that the current init system wasn't exactly the bee's knees, but disagreed on what to use to replace it (systemd, upstart, heck, even Apple's launchd).
There was a rather vocal group that didn't actually care that much about the specific implementation either, but but wanted something in the "Unix spirit", i.e. consisting of a more modular base of small components. Systemd pretty much fails that test as much as humanly possible without being J2EE.
And it all ended with a bad debate on the Debian mailing list. Can't remember all the details, but the Grand Poobahs were accused of acting a bit too grand.
So it wasn't just about the technical merits themselves, but also about philosophy and policy.
As a dev/sysadmin, systemd is barely noticeable when you think if it as an init system. When you look at the cool tricks it can do, it's more like its part of the OS than something living on top of it, providing services you'd expect a kernel to provide (albeit not a very Unix-like one, which is what makes people so mad about it).
It's a large and complex beast, doing a lot of different things that make sense in a modern server environment.
Systemd is very Windows-like.... big central kernel-like thing that provides services, logging, authentication... but what I don't understand is why they anyone would rather have init.d
That is a false dichotomy that gets paraded out again and again. It is not about preserving sysv directly, but that sysv puts the decision to use something else in the hands of the sysadmin, not the distro devs, never mind the systemd devs.
This because the sysv binary itself is small, and a stepping of point for something more elaborate.
OpenRC for example use sysv as the init binary, but builds a services management structure akin to what systemd offers.
So do like fifty thousand other linux apps, because nobody seemed to get service management right. The whole reason you are dealing with those problems is because sysv et al were never sufficiently adequate to achieve dominance. I am so glad that there is a future with just one or two service managers to know, because I am sick and fucking tired of having to relearn tech for every stupid linux project...
- The logo. Logos are very affordable. I would consider revisiting this logo, buying a new one or organizing a contest. Believe it or not, many people use t-shirts with the Debian logo and I assume that's some source of revenue stream. I do not see myself wearing a Devuan t-shirt with this logo. Right not it looks like a logo for a UFO cult or some cheap Internet cafe.
- The information on the landing page should be organized to emphasize what is important for each type of experience. e.g: dividing it into info for users, info for prospect contributors, info for existing contributors, and donation (what and how to donate, and what is done with donations). Try to interleave these roles less and summarize more.
Then, I would like to understand what the key differences are with Debian, also what specifically does "control over your system" mean?
A friend commissioned a logo through a website where you get proposals from multiple artists. He had the chance to buy a fantastic logo for a very affordable price. I don't know the name of this website but my HN family here surely knows. Someone?
> Devuan is about choice. We think people should be able to choose whether to use a GNU+Linux system with or without systemd.
> Devuan decided to fork not only the base distribution, but also its governance, because Debian has made it difficult to avoid systemd as init, entangling the system with unnecessary dependencies and did so despite widespread community concern. We encourage potential Devuan users who wish to install systemd to use Debian’s installer, Debian’s packages and Debian’s mailing lists, all available directly from Debian’s mirrors.
Great to see they are making headway. Wonder about the long term sustainability though, as more and more software such as GNOME3 DE lists it as a dependency
This doesn't address the point raised. He mentioned that more and more software relies on systemd giving just one example.
IMO not much has changed in the last 2 years. Not too much additional software really relies on systemd. Nor that systemd integrated any other software like it did in the beginning (e.g. merging udev into it). There haven't been too many feature additions as well. What did happen is that way more software ships a systemd conf file, but that's about it.
If you have ever used TWM, then you would know that the 'T' stands for Terrible. Fortunately, there are lots of lightweight WMs that are far better.
Personally, I use tiling WMs (namely XMonad at the moment), so I could really care less what GNOME, KDE, et al are up to. However, I realize most people are accustomed to stacking WMs and expect something similar to what is provided by proprietary OSes with a similar amount of eye candy as well.
Hey now, no need to resort to name-calling. In fact, the “T” originally stood for “Tom”, but the name was later changed so the “T” stood for “Tab” (referring to its then-default look of window titles as little tabs on top of windows).
Furthermore, it is not terrible. I’ve used TWM for more than 20 years. It worked perfectly fine for me when I started to use it, and it still does so today, so I have not seen a need to switch.
Under Debian you can run GNOME under other init systems thanks to Debian+Canonical creating systemd-shim (alternative to logind). Under Devuan you cannot use GNOME (they don't offer it). This as Devuan claims that it is impossible (despite being possible within Debian) (!)
This task package is used to install the Devuan desktop,
featuring the GNOME desktop environment, and with other
packages that Devuan users expect to have available on the
desktop.
It's a mystery to me that people still associate linux desktop with gnome. The gnome project has a long history of not caring about users or developers and prioritizing their view and their brand.
Are you advocating that software such as Qt version 1 as of 1998 that is neither available under a license that meets the FSF's Free Software criteria nor the OSI's Open Source criteria nor Debian's DFSG should be a core part of the GNU/Linux desktop?
It's likely that I missed it, but I can't find anywhere that talks about how many packages deviate from Debian. I love what they are offering but I also want to make sure that the ease of use I get with Debian continues with Devuan.
Can we assume that any packages that are not Gnome related from the Debian repos are in the Devuan repos?
This video[0] (dated Nov 29, 2016) says 381 forked packages. That's not nearly as bad as it sounds because many individual software projects are divided up into multiple packages.
For example, libvirt[1] produces 9 packages consisting of: libvirt-bin, libvirt-clients, libvirt-daemon, libvirt-daemon-system, libvirt0, libvirt0-dbg, libvirt-doc, libvirt-dev, libvirt-sanlock.
The video is rather interesting for learning about how the project came about and how it works in general.
Devuan Jessie with Wicd on a Thinkpad X220. All just works. Enables the non-free repository (iwlwifi drivers installed out of box) if that matters to you.
The major contributors are listed here: https://devuan.org/os/team/. Either they don't mention packagers specifically or they don't have a lot of them.
They didn't fork too many packages, so security handling should be fairly easy. They plan to offer support for a longer period than Debian. I don't think they'll be able to based on my experience contributing to a slightly bigger distribution (e.g. maybe 30-40 packagers) whom are lagging behind on security updates.
The website needs some work. I could gather they were a fork of Debian, but I couldn't find the benefits. I had to come to the HN comments to learn about the systemd controversy. Less important, the mobile experience was not good on Android Chrome. When scrolling, the logo visibility toggles and the page content jumps.
> Devuan is about choice. We think people should be able
> to choose whether to use a GNU+Linux system with or
> without systemd.
> Devuan decided to fork not only the base distribution,
> but also its governance, because Debian has made it
> difficult to avoid systemd as init, entangling the system
> with unnecessary dependencies and did so despite...
but you're right that it makes sense to put it in a more obvious location, given that it seems to be the reason the project exists.
Nobody wants to hear this, but I have strong suspicions NSA worked with Red Hat to make systemd their backdoor of choice for Linux systems, and I highly praise efforts to offer diversity in in it land regardless if I'm right or not.
Should we be worried about the fact that it took over two years to untangle systemd from Debian with respect to Linux in general?
In case someone from the Devuan project is around, what alternate init system should maintainers be targetting now for Devuan? OpenRC, classic SysV init, or something else?