SoylentNews is people
SoylentNews
Earlier this month we covered a story where we quoted the following:
Due to Debian developers having differing opinions on handling non-systemd bugs in 2019 and the interest/commitment to supporting systemd alternatives in the scope of Debian packaging and various related friction points, they've taken to a new general resolution over weighing init system diversity.
The results of the ballot to discover how the Debian devs feel about their earlier decision with the benefit of hindsight is now in:
Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus.
The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.
Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.
(Score: 2, Interesting) by messymerry on Monday December 30 2019, @04:43PM (3 children)
Aren't there blobs in systemd that can't be read? I was led to understand that systemd is not fully "open source".
Is this true?
Thanks bunches and an early Happy New Year!
Only fools equate a PhD with a Swiss Army Knife...
(Score: 2, Funny) by Anonymous Coward on Monday December 30 2019, @06:13PM
Some of those blobs have been deciphered. It's clear now that playing them backwards at 45 rpm reveals satanic worship chanting. Avoid systemd if you value your soul!
(Score: 2) by Bot on Monday December 30 2019, @07:07PM (1 child)
> Aren't there blobs in systemd that can't be read.
Try the documentation. I mean, you can technically read it
--system, --user
For --system, tell systemd to run a system instance, even if the
process ID is not 1, i.e. systemd is not run as init process.
--user does the opposite, running a user instance even if the
process ID is 1. Normally, it should not be necessary to pass
these options, as systemd automatically detects the mode it is
started in. These options are hence of little use except for
debugging. Note that it is not supported booting and maintaining
a full system with systemd running in --system mode, but PID not
1. In practice, passing --system explicitly is only useful in
conjunction with --test.
so, why not make them a debug and test suboptions? --test-as-system? we will never know. We also will never know how many sysadmins started crying and hitting the keyboard with their forehead when reading this, at 3am and with an unbootable server to diagnose.
Account abandoned.
(Score: 3, Informative) by barbara hudson on Monday December 30 2019, @07:13PM
Translation: It will not crash, and if it does it's not my fault, even if it is. - LP
Systemd doesn't leave a system unbootable forever. Just install another distro, one that doesn't have it. Problem permanently solved.
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.