LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 08-19-2019, 09:22 AM   #31
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 819

Original Poster
Blog Entries: 7

Rep: Reputation: 201Reputation: 201Reputation: 201

Quote:
Originally Posted by jsbjsb001 View Post
Again, just "thinking about it" doesn't make it happen. Many people "think about" world peace... has it happened yet? No, it hasn't.

And for the last time, there already ARE other init systems available. So again, what's yet another "alternative" going to solve? If it were going to solve anything, then we likely wouldn't even be talking about system bloody d. Again, if you're interested in doing something about it, then either learn programming or use something else. Otherwise "just talking about it" is just as pointless as just whingeing about systemd...

Any in case, I've wasted enough time with this pointless discussion...
If you want to discuss the discussion and tell people what they can and cannot discuss I suggest you stay away and keep it to yourself. Otherwise, please stay on topic.
 
Old 08-19-2019, 09:55 AM   #32
cynwulf
Senior Member
 
Registered: Apr 2005
Location: /dev/planet2
Distribution: OpenBSD
Posts: 2,331
Blog Entries: 6

Rep: Reputation: 1631Reputation: 1631Reputation: 1631Reputation: 1631Reputation: 1631Reputation: 1631Reputation: 1631Reputation: 1631Reputation: 1631Reputation: 1631Reputation: 1631
Quote:
Originally Posted by zeebra View Post
Yet we could easily choose between Xfree86 and Xorg back in the days.
One also had to configure the X server entirely from scratch back in those days - whether it was Xfree86 or X.org. Only X.org really survived, so while there was a choice of sorts, one of the two options declined into irrelevance. But the point being there was a choice - but it involved some work on the part of the end user.
 
Old 08-19-2019, 03:20 PM   #33
ChuangTzu
Senior Member
 
Registered: May 2015
Location: Where ever needed
Distribution: Slackware/Salix while testing others
Posts: 1,441

Rep: Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386
Quote:
Originally Posted by zeebra View Post
That's quite on the point and very useful. What I gather from this post:

- SystemFree is only an init system
- SystemFree can run some modules for various task
- One module of SystemFree is a daemon launcher (+ i/o?) or is this "module" part of the init system itself?
- One module of SystemFree is a "shim" or interactive interface (SystemD emulation module)
- Udev definetely needs a fork

Regarding the journal, we have rsyslog and even syslog-ng and other alternatives, there is absolutely no need for journald. Perhaps adding some logging tools to rsyslog instead.

I don't know about Udev as I said earlier. Does it need a fork or a replacement? Is there anyway to easily make Udev independent again? Perhaps roll it back to version x.y and fork that?

So, what do we actually need aside from just the Init (SystemFree) from the SystemD blob? Clearly Udev seems high up the list. But what about security modules? I think the current situation is a bit problematic. PAM, polkit, dbus, consolkit and even things like security modules (SELinux), what do we do about those? Ofcourse they need to be optional, but don't they need a more elegant solution or replacement? I mean, they can live alone, but eventually they will probably be swallowed into the SystemD blob as well. These kind of solutions are attractive, there is a demand for these kind of services, and a SystemFree init system needs to be able to on demand provide some of these same solutions.

From the Kernel side, this is all clear and working with the security module, but I think from the software side (coreutils/GNU etc) we're sorely missing updated system wide security parameters, and in one way or another, these have been attempted patched with various solutions like ACL. Just adding one or two permission parameters to the default GNU DAC could almost make it MAC, and together with a polkit/PAM/dbus/cgroups singular replacement solution, we would have a good security core to offer people to move away from SystemD (and pam, sudo, dbus, polkit, cgroups) without any concerns. Ofcourse, it's unrealistic to believe anyone would touch the old DAC and update it, but if not, the security service could do that in a more simple and elegant way, without having to implement something like SeLinux.

There is a demand for these things above, and if they all become baked into the SystemD blob, we also need solutions for them. Not in SystemFree itself, but in some of the forked packages to go along with it.
As mentioned by someone a few posts earlier, what does your SystemFree offer that openRC does not? Wouldn't your efforts be more focused helping an already established and viable alternative, rather then starting from scratch?
benefits of openRC:
https://wiki.gentoo.org/wiki/OpenRC
https://www.freebsdnews.com/2017/02/...trueos-openrc/
https://www.reddit.com/r/Gentoo/comm...e_openrc_over/
 
Old 08-19-2019, 03:22 PM   #34
ChuangTzu
Senior Member
 
Registered: May 2015
Location: Where ever needed
Distribution: Slackware/Salix while testing others
Posts: 1,441

Rep: Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386Reputation: 1386
Quote:
Originally Posted by zeebra View Post
I don't care how it is written really. And there aren't any alternatives to systemD aside from SysV OR independent init systems like found in Slackware or OpenRC. I don't know about OpenRC to be honest, but clearly it is not an alternative to SystemD since almost nobody is using it.
This statement has me question your ability and intent. Thank you, this thread is over for me now.
 
1 members found this post helpful.
Old 08-19-2019, 04:12 PM   #35
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 819

Original Poster
Blog Entries: 7

Rep: Reputation: 201Reputation: 201Reputation: 201
Quote:
Originally Posted by ChuangTzu View Post
As mentioned by someone a few posts earlier, what does your SystemFree offer that openRC does not? Wouldn't your efforts be more focused helping an already established and viable alternative, rather then starting from scratch?
benefits of openRC:
https://wiki.gentoo.org/wiki/OpenRC
https://www.freebsdnews.com/2017/02/...trueos-openrc/
https://www.reddit.com/r/Gentoo/comm...e_openrc_over/
What it offers that openrc don't?
A replacement for SystemD? I don't know if SystemFree would be much different than OpenRc, but one of the main points of SystemFree would be to fork the necessary parts of SystemD into independent projects again, ie deblob the blob.

I would think it's not possible to run any type of SystemD distro, remove SystemD and replace it with OpenRC and expect to have a running system, or am I wrong?
 
Old 08-20-2019, 01:53 AM   #36
Christopher Wylie
LQ Newbie
 
Registered: Mar 2018
Posts: 13

Rep: Reputation: 2
Hello zeebra and others,
I would like to test this SystemFree.
How can I install it?
 
Old 08-20-2019, 02:15 AM   #37
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 819

Original Poster
Blog Entries: 7

Rep: Reputation: 201Reputation: 201Reputation: 201
Quote:
Originally Posted by Christopher Wylie View Post
Hello zeebra and others,
I would like to test this SystemFree.
How can I install it?
It's not ready yet, but that is a good question. I'd think "make" and "make install" would be a good way.

But for those with package managers it should become available there.

Perhaps the final name would be SysF or sysfree.

Last edited by zeebra; 08-20-2019 at 02:17 AM.
 
Old 08-20-2019, 02:39 AM   #38
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 819

Original Poster
Blog Entries: 7

Rep: Reputation: 201Reputation: 201Reputation: 201
What have we found out thus far:

- Systemfree is ONLY an init (it does one thing and does it well)
- It's written in C (what else?)
- It has no dependencies (taken from SysV)
- It has some clever input/output built into (which can among other handle daemons and modules)
- It has a close relationship with other forked projects
- Together with the forked projects and a "SystemD emulation module" it can replace SystemD with install & remove
- The project supplies a "remove SystemD" script
- Make and make install && pre-packaged for the biggest distroes (sysf+remove script+forks)
 
Old 08-20-2019, 04:37 AM   #39
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 819

Original Poster
Blog Entries: 7

Rep: Reputation: 201Reputation: 201Reputation: 201
I think one good way to separate useful and non-useful forks is to separate those who are implemented in the kernel vs those who are not.

So say, cgroups, it needs a fork, udev needs a fork as they both have something to do with the kernel or are implemented in the kernel. they don't HAVE to be started by SystemFree, but they should be forked into independent projects.
 
Old 08-20-2019, 05:20 AM   #40
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 10,569

Rep: Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172
Sounds very promising. Does it reduce boot times over sysvinit? You can't help noticing that this much was achieved by initNG, and development there seems to have slowed/stopped. I'm not aware of what walls it ran into, but you may want to learn from their experience.
Also how you configure this will be important. With sysvinit, you can use config files or Distros are inclined to add great bloat to what was a simple system trying to handle every conceivable system, & setup.
Quote:
Originally Posted by zeebra
So say, cgroups, it needs a fork, udev needs a fork as they both have something to do with the kernel or are implemented in the kernel. they don't HAVE to be started by SystemFree, but they should be forked into independent projects
Frankly, I don't know the area, but I don't understand. This may be an ignorant question, but why fork what the kernel starts? Is there configuring to be done?
And if that's the split, could the kernel-booted apps be forked together?

I wish you success.
 
Old 08-20-2019, 05:37 AM   #41
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 819

Original Poster
Blog Entries: 7

Rep: Reputation: 201Reputation: 201Reputation: 201
Some relevant services that exist or need to be forked (or not, just considered), or has something to do with systemd, worth mentioning:
- inetd
- readahead
- consolekit
- syslog
- watchdog
- acpid
- autofs
- pm-utils
- udev
- cryptsetup
- tmpfiles
- auditd
- networkd
- d-bus
- pam
- namespace

Ps. list is taken from https://www.youtube.com/watch?v=_2aa34Uzr3c


SystemFree needs and relies on good daemons and some of these could be merged, but would not be part of SystemFree. Some of them need some improvement to live independent and useful lives, some of them already exist and do their thing well, and some do not exist anymore but has been swallowed up by SystemD and needs to be forked.

Last edited by zeebra; 08-20-2019 at 06:04 AM.
 
Old 08-20-2019, 05:56 AM   #42
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 819

Original Poster
Blog Entries: 7

Rep: Reputation: 201Reputation: 201Reputation: 201
Quote:
Originally Posted by business_kid View Post
Sounds very promising. Does it reduce boot times over sysvinit? You can't help noticing that this much was achieved by initNG, and development there seems to have slowed/stopped. I'm not aware of what walls it ran into, but you may want to learn from their experience.
Also how you configure this will be important. With sysvinit, you can use config files or Distros are inclined to add great bloat to what was a simple system trying to handle every conceivable system, & setup.


Frankly, I don't know the area, but I don't understand. This may be an ignorant question, but why fork what the kernel starts? Is there configuring to be done?
And if that's the split, could the kernel-booted apps be forked together?

I wish you success.
SystemFree would not be procedural, structural or concurrent, but an ideal mix. The aim is to boot whatever environment as fast as possible, but in a structured way with some procedural waiting time to make sure once you're in the system, everything is booted fast, in the right order and complete. The boot priority as far as possible in the init system itself and details about it should be user configurable as well, unless it breaks something, but ofcourse even then if the user insist (experts).

Every boot item should be configurable in scripts alike to sysvinit, and SystemFree should look as much as possible like SysV in /etc with very similar functions, configurations etc. But it should not really be only script based, in essence.

SystemFree will be a lightweight but modular init system with a good structure. So alot of needs should be covered without distroes having to come up with their own solutions. But at it's core it's only an advanced but simple init. As many init functions as possible should be built into it to make it as efficient and complex as it can be as an INIT ONLY piece of software.

I think it makes sense to be able to split system critical things and non-system critical things and group these in two or 3 different init procedures. That way you can boot real fast without starting daemons and software that the system does not need to boot, but rather continue to start these after boot or possibly in between. The user should be able to structure these things as they see fit. If they want make the boot dependent on the network manager and wait for boot to start network manager, then they can do that, or they can structure is to start after boot or at the very end of the boot to see how much extra time that adds to the boot.

SystemFree would not decide how that should look, but would make some suggestions as to how everything is structured, but all except the critical things should be configurable by the user or distro. SystemFree could provide different standard configuration options for different types of system which users could accept or change.


Regarding the Kernel. I meant that software IN systemd which just offers services to Kernel functions. Cgroups is a Kernel function, systemd implements that with software. I think it makes sense to at least likely fork software for SystemFree (as independent projects) from SystemD which has Kernel functions or references (udev). Or better said is Kernel relevant.

Last edited by zeebra; 08-20-2019 at 06:00 AM.
 
Old 08-20-2019, 06:17 AM   #43
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 819

Original Poster
Blog Entries: 7

Rep: Reputation: 201Reputation: 201Reputation: 201
Things like cgroupsd need to be able to interface with SystemFree init in some way. This is where the input/output part of SystemFree becomes relevant. That way cgroups is not part of the init, but it's own independent software (daemon) and is something a user can choose to start/install or not.

Last edited by zeebra; 08-20-2019 at 06:18 AM.
 
Old 08-20-2019, 06:36 AM   #44
hazel
Senior Member
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 3,383
Blog Entries: 9

Rep: Reputation: 1891Reputation: 1891Reputation: 1891Reputation: 1891Reputation: 1891Reputation: 1891Reputation: 1891Reputation: 1891Reputation: 1891Reputation: 1891Reputation: 1891
Isn't it easy to design systems when you don't actually need to program them!
 
1 members found this post helpful.
Old 08-20-2019, 07:31 AM   #45
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 819

Original Poster
Blog Entries: 7

Rep: Reputation: 201Reputation: 201Reputation: 201
Who said that? Perhaps I do have to program it all alone
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
init.d script to systemd with systemd-sysv-generator tankzeu Linux - Newbie 1 09-17-2018 04:41 AM
LXer: The Story Behind ‘init’ and ‘systemd’: Why ‘init’ Needed to be Replaced with ‘systemd’ in Linu LXer Syndicated Linux News 1 04-07-2017 11:33 PM
[SOLVED] Valgrind takes into consideration of freed memory? MichelleL Linux - General 1 11-01-2012 10:27 PM
Taking brands into consideration when buying a graphics card Michael_aust Linux - Hardware 1 12-28-2005 08:21 AM
The fastest reaction in auto-updates taking into consideration network security bugs? immer Linux - Distributions 1 10-23-2004 03:21 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 09:25 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration