Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Where will you go after systemd?
Re: Where will you go after systemd?
dasein aka Curmudgeon . . . You have always had the ability to cut right to the core of the matter and "Combatting revisionist history" is no exception. Absolutely brilliant!
May the FORK be with you!
Re: Where will you go after systemd?
I haven't noticed better boot times. Then again, I haven't actually timed and I'm running off an SSD.Moonshine wrote:dasein wrote: (That goes double for anyone who thinks systemd is an "init system" or "better" without a specific set of measurable criteria for determining quality.)Shorter points:Moonshine wrote:But in my view, systemd brings nothing but improvements over sysvinit scripts (of which I never was a big fan) - from hugely reduced boot time to much easier and more cogent way to monitor the processes that have started/failed to start during the boot, to more unified and versatile concept of units that allows you to handle startup dependencies in a sane and non-overcomplicated manner. And it even has sysvinit compatibility!
1. Boot time (objectively twice as fast on my computer, about 7s vs 14s)
2. systemctl and journald are very intuitive and easy to use. (subjective)
3. systemd units and their dependencies are a blessing. (subjective)
4. sysvinit I always found a little messed up and struggled to deal with it. BSD-init is fine. (subjective)
@dasein- thank you. Not unbiased but you do have some good points there.
Laptop: Debian GNU/Linux 9 'Stretch' 64bit
Read: https://wiki.debian.org/DontBreakDebian/
We are the Universal OS. Be patient, give help, teach the Debian way.
Read: https://wiki.debian.org/DontBreakDebian/
We are the Universal OS. Be patient, give help, teach the Debian way.
- Curmudgeon
- Posts: 10
- Joined: 2015-01-27 18:29
Re: Where will you go after systemd?
Moonshine wrote:1. Boot time (objectively twice as fast on my computer, about 7s vs 14s)dasein wrote: (That goes double for anyone who thinks systemd is an "init system" or "better" without a specific set of measurable criteria for determining quality.)
2. systemctl and journald are very intuitive and easy to use. (subjective)
3. systemd units and their dependencies are a blessing. (subjective)
4. sysvinit I always found a little messed up and struggled to deal with it. BSD-init is fine. (subjective)
(Emphasis added)
Get off my lawn.
Re: Where will you go after systemd?
Decisions based in emotion are almost always bad ones. Just observe the consequences of three year olds in a sandbox or hormonal teenagers doing just that.Moonshine wrote:And that's why I've involuntarily become systemd-sympathetic.
May the FORK be with you!
Re: Where will you go after systemd?
systremd is Windows svchost, not FreeBSD init.
It does not boot faster. In fact on HDD it's slower.
Managing processes via cgroups as done by systemd does not work, just look at the code.
...
It does not boot faster. In fact on HDD it's slower.
Managing processes via cgroups as done by systemd does not work, just look at the code.
...
Ok, I think I'm done here. Helped a few newbies, met a few seemingly adequate and nice people, but this is really too much.
I do wish the fork is completed soon and everyone who want to use systemd-free Debian just goes on and uses it. I highly doubt anything good can be built on prejudice, arrogance and stupid resistance to change, but that's just me. Until then, I'll try to stay away from English-speaking Debian community.
I do wish the fork is completed soon and everyone who want to use systemd-free Debian just goes on and uses it. I highly doubt anything good can be built on prejudice, arrogance and stupid resistance to change, but that's just me. Until then, I'll try to stay away from English-speaking Debian community.
Re: Where will you go after systemd?
I think you should take less notice of the crap coming your way and just do your own thing. Forums in general have a big asshole population. These are users with time on their hands to pick on other users for no good reason and try to look clever but without posting anything technical.
Just a minor correction: Slackware does not use "BSD init" because there is no such thing. Slackware uses sysvinit with BSD style (rc) scripts. It still uses the sysv init daemon (not any kind of ported *BSD init daemon) and it still uses /etc/inittab and run levels. So with that in mind I'm unsure as to why you prefer it over Debian's sysvinit implementation?
Just a minor correction: Slackware does not use "BSD init" because there is no such thing. Slackware uses sysvinit with BSD style (rc) scripts. It still uses the sysv init daemon (not any kind of ported *BSD init daemon) and it still uses /etc/inittab and run levels. So with that in mind I'm unsure as to why you prefer it over Debian's sysvinit implementation?
Re: Where will you go after systemd?
1of12 wrote:I think you should take less notice of the crap coming your way and just do your own thing. Forums in general have a big asshole population. These are users with time on their hands to pick on other users for no good reason and try to look clever but without posting anything technical.
Just a minor correction: Slackware does not use "BSD init" because there is no such thing. Slackware uses sysvinit with BSD style (rc) scripts. It still uses the sysv init daemon (not any kind of ported *BSD init daemon) and it still uses /etc/inittab and run levels. So with that in mind I'm unsure as to why you prefer it over Debian's sysvinit implementation?
No, Slackware doesn't use sysvinit. Slackware has sysvinit compatibility since version 7.0. http://www.slackware.com/config/init.php
From the Slack /etc/rc.d/rc.sysvinit
The SystemV style init system places
# start/stop scripts for each runlevel into directories such as
# /etc/rc.d/rc3.d/ (for runlevel 3) instead of starting them
# from /etc/rc.d/rc.M. This makes for a lot more init scripts,
# and a more complicated execution path to follow through if
# something goes wrong. For this reason, Slackware has always
# used the traditional BSD style init script layout.
#
# However, many binary packages exist that install SystemV
# init scripts. With rc.sysvinit in place, most well-written
# startup scripts will work. This is primarily intended to
# support commercial software, though, and probably shouldn't
# be considered bug free.
Re: Where will you go after systemd?
Your research/knowledge is lacking.Moonshine wrote:No, Slackware doesn't use sysvinit. Slackware has sysvinit compatibility since version 7.0. http://www.slackware.com/config/init.php
Slackware uses the sysvinit daemon, but uses BSD style rc scripts instead of the usual sysvinit scripts.
Or did you think that a *BSD's init uses run levels?
Re: Where will you go after systemd?
Slackware uses init daemon. There's. as you said, "no such thing" as sysvinit daemon. Do you think sysv owns init or what?1of12 wrote: Slackware uses the sysvinit daemon
http://en.wikipedia.org/wiki/Init
Sysvinit is init + sysv scripts.
BSD-init is init + bsd scripts.
BSD scripts are much easier way to boot up your computer. That's not only my opinion.
Re: Where will you go after systemd?
Your source is wikipedia...?
My first source is the source:
https://savannah.nongnu.org/projects/sysvinit
http://download.savannah.gnu.org/releases/sysvinit/
My second source is the Slackware source:
http://mirrors.slackware.com/slackware/ ... /sysvinit/
Finally Debian:
https://packages.debian.org/source/wheezy/sysvinit
Note the version numbers being identical between Slackware and Debian (sysvinit hasn't seen much development for years) and project being called "sysvinit"...
As I said: "Your research/knowledge is lacking."
My first source is the source:
https://savannah.nongnu.org/projects/sysvinit
http://download.savannah.gnu.org/releases/sysvinit/
My second source is the Slackware source:
http://mirrors.slackware.com/slackware/ ... /sysvinit/
Finally Debian:
https://packages.debian.org/source/wheezy/sysvinit
Note the version numbers being identical between Slackware and Debian (sysvinit hasn't seen much development for years) and project being called "sysvinit"...
As I said: "Your research/knowledge is lacking."
Re: Where will you go after systemd?
My main source is Slackware website, which has a rather conclusive disclaimer on this topic.
http://www.slackware.com/config/init.php
It is interesting that the actual init that is used by Slackware is actually the same that's in sysvinit. I didn't know that.
If we go up a directory, there's also sysvinit-scripts directory, but in contains this:
http://mirrors.slackware.com/slackware/ ... s/scripts/
These are not sysvinit-scripts. Why they are called sysvinit-scripts - I don't know. Do you?
Still, it's not the daemon that makes up for init system. It's daemon+scripts. So what I said in previous post.
http://www.slackware.com/config/init.php
It is interesting that the actual init that is used by Slackware is actually the same that's in sysvinit. I didn't know that.
If we go up a directory, there's also sysvinit-scripts directory, but in contains this:
http://mirrors.slackware.com/slackware/ ... s/scripts/
These are not sysvinit-scripts. Why they are called sysvinit-scripts - I don't know. Do you?
Still, it's not the daemon that makes up for init system. It's daemon+scripts. So what I said in previous post.
Sysvinit is init + sysv scripts.
BSD-init is init + bsd scripts.
BSD scripts are much easier way to boot up your computer. That's not only my opinion.
Re: Where will you go after systemd?
The Slackware website is correct, your interpretation of it is wrong. It says nothing about not using sysvinit.Moonshine wrote:My main source is Slackware website, which has a rather conclusive disclaimer on this topic.
http://www.slackware.com/config/init.php
The often used word "style" should give it away.Slackware Linux uses the BSD-style file layout for its system initialization files
If you can invoke init from the terminal as root to change run levels, then you are running sysvinit - simple as that.
sysvinit is the init system used in Slackware. It uses sysvinit + BSD style rc scripts.Moonshine wrote:It is interesting that the actual init that is used by Slackware is actually the same that's in sysvinit. I didn't know that.
They're sysvinit scripts because they're used with sysvinit. The fact that they're 'BSD style' does not make them BSD init scripts or the init system they're running on some kind of *BSD init. You also won't find inittab and those run level scripts on any *BSD operating system. The *BSDs do not use sysvinit at all, for various reasons - though just for starts, the licence is a show stopper. Each *BSD has it's own init system derived/forked from the original 386BSD/4.2BSD/4.4BSD-lite code bases.Moonshine wrote:If we go up a directory, there's also sysvinit-scripts directory, but in contains this:
http://mirrors.slackware.com/slackware/ ... s/scripts/
These are not sysvinit-scripts. Why they are called sysvinit-scripts - I don't know. Do you?
On the contrary, what you said in the previous post is still completely false.Moonshine wrote:Still, it's not the daemon that makes up for init system. It's daemon+scripts. So what I said in previous post.
Sysvinit is init + sysv scripts.
BSD-init is init + bsd scripts.
BSD scripts are much easier way to boot up your computer. That's not only my opinion.
Re: Where will you go after systemd?
1of12 wrote: The Slackware website is correct, your interpretation of it is wrong. It says nothing about not using sysvinit.
How and why do you include compatibility with something you're supposedly already using?System V Compatibility
Since version 7.0, Slackware includes System V init compatibility. Many other Linux distributions make use of this style instead of the BSD style. Basically each runlevel is given a subdirectory for init scripts, whereas BSD style gives one init script to each runlevel.
Before 7.0 Slackware didn't understand the directory-based runlevel approach of sysvinit. After rc.sysvinit was included, it does.
1of12 wrote:If you can invoke init from the terminal as root to change run levels, then you are running sysvinit
I'm talking about init system, not init file. OpenRC is an init-system that uses init file too. OpenRC isn't sysvinit even if it uses init file provided by sysvinit.1of12 wrote:sysvinit is the init system used in Slackware. It uses sysvinit + BSD style rc scripts.
We seem to have major terminology differences. And BSD-init isn't something I came up with, it's how it is referred to all over the place1of12 wrote:They're sysvinit scripts because they're used with sysvinit. The fact that they're 'BSD style' does not make them BSD init scripts or the init system they're running on some kind of *BSD init.
http://wiki.gentoo.org/wiki/Comparison_of_init_systems
http://www.linuxfromscratch.org/hints/d ... d-init.txt
I will say "BSD style init", if it suits you better. It still means the same thing.
Re: Where will you go after systemd?
This discussion is off topic. Please open a new thread if you like to discuss philosophical aspects of calling names to different parts init systems.
Re: Where will you go after systemd?
Slackware uses BSD style rc scripts, it was not compatible with sysv style scripts as set up.Moonshine wrote:How and why do you include compatibility with something you're supposedly already using?
Before 7.0 Slackware didn't understand the directory-based runlevel approach of sysvinit. After rc.sysvinit was included, it does.
OpenRC is just based on sysvinit. They can use whatever wording they like. The file they refer to as /sbin/init is sysvinit, it's not the /sbin/init from e.g. OpenBSD or NetBSD. When they refer to /sbin/init as it's Linux, there is the automatic assumption that it's sysvinit.Moonshine wrote:I'm talking about init system, not init file. OpenRC is an init-system that uses init file too. OpenRC isn't sysvinit even if it uses init file provided by sysvinit.
Terminology is not the issue, that would be a small matter, you don't seem to understand that "BSD init" does not really exist in the way you think it does. I argued for a start that Slackware used the sysvinit daemon, you responded to that in the negative, without actually knowing that it does use the same /sbin/init.Moonshine wrote:We seem to have major terminology differences. And BSD-init isn't something I came up with, it's how it is referred to all over the place
I would suggest asking on the LQ Slackware forum if you require further clarification.
Re: Where will you go after systemd?
Extract from linux kernel source /Documentation/sysfs-rules.txtgolinux wrote:Because it's about more than init. It is the entanglement of depends that is the glue that binds systemd to places where is unnecessary except to tie it to the systemd monolith.JLloyd13 wrote:If its that easy why are people still forking Debian over it?
The kernel-exported sysfs exports internal kernel implementation details
and depends on internal kernel structures and layout. It is agreed upon
by the kernel developers that the Linux kernel does not provide a stable
internal API. Therefore, there are aspects of the sysfs interface that
may not be stable across kernel releases.
To minimize the risk of breaking users of sysfs, which are in most cases
low-level userspace applications, with a new kernel release, the users
of sysfs must follow some rules to use an as-abstract-as-possible way to
access this filesystem. The current udev and HAL programs already
implement this and users are encouraged to plug, if possible, into the
abstractions these programs provide instead of accessing sysfs directly.
So systemd apparently combines udev (abstraction to an unstable kernel interface) with a boot manager. I'll probably give it a try though when I switch to the next stable version of Debian as it will be useful to know how it works if it is popular elsewhere. With Red Hat software in general though, given their free / premium model then the free software is unlikely to be as good as the premium version I would guess, and lack a certain amount of functionality in comparison.
Edit:
Reading the link referenced here:
http://forums.debian.net/viewtopic.php? ... &start=225
Later versions of systemd will also replace Grub / Lilo and the computer BIOS as they incorporate the "gummiboot" UEFI boot manager - these exist now but earlier versions are apparently being used in Debian at present.
From gummiboot source code: (the name gummiboot is a joke in German, as it means inflatable rubber boat)
This file is part of systemd.
Copyright 2013 Lennart Poettering
Copyright 2013 Kay Sievers
systemd also includes readahead, previously a separate package. Installing the readahead-fedora package reduced my boot time by ~20 seconds, the first boot is slow as it sets itself up, later boots are faster. readahead-fedora can be optimised in various ways.
Further edit:
Red Hat intend to replace the X11 graphical interface with Wayland. Ubuntu are working on Mir as an alternative but it hasn't been so widely accepted as Wayland so far.
Credit should go to Ubuntu for providing alternatives from the "Debian based" community.
Last edited by Hralgmir on 2015-04-15 21:34, edited 2 times in total.
Re: Where will you go after systemd?
Dasein:dasein wrote:Some may find it informative: http://forums.debian.net/viewtopic.php?f=20&t=120652
I don't know how could this happen, but somehow I've mislooked Your post. I've never supposed that I'll say this, but I want to apologise You. This post is just briliant, and summarises everything that could be said about systemd.
Regards.
Odi profanum vulgus
Re: Where will you go after systemd?
@tomazzi: I'm flattered by your kind words, thank you. No apology necessary.
However, as long as I have your attention in a calm moment, I do want to mention that you mistook our last exchange as an attack when it was exactly the opposite: a show of moral support. What I was trying to say is this: your concerns, while insightful, incisive, and exactly correct, simply weren't something most folks here were going to be able to appreciate. (No offense intended to FDNLand, just stating a fact.) That's all.
However, as long as I have your attention in a calm moment, I do want to mention that you mistook our last exchange as an attack when it was exactly the opposite: a show of moral support. What I was trying to say is this: your concerns, while insightful, incisive, and exactly correct, simply weren't something most folks here were going to be able to appreciate. (No offense intended to FDNLand, just stating a fact.) That's all.