Originally posted by gens
View Post
Announcement
Collapse
No announcement yet.
Systemd Works On PPPoE Support
Collapse
X
-
Last edited by psychoticmeow; 11 November 2014, 10:07 AM.
-
Declarative syntax
One of the greatest things systemd has done and may even survive its own demise is the declarative syntax.
Instead of each daemon writing a long script or program to start/stop it, it just declares its requirements and another program (currently only systemd) deals with the rest in a reliable repeatable manner.
In a post-systemd world, it should be easier for another program to use this declarative syntax than to emulate or run the older potentially hundreds of lines long shell scripts.
an interpreter for the systemd-style declarative syntax could be added to other init systems like openrc or other alternatives (maybe even sysv init, or upstart if someone decides to continue feature development on them) allowing this new syntax to be more portable than shell scripts.
(Whether someone will do this is another question)
Comment
-
Originally posted by You- View PostOne of the greatest things systemd has done and may even survive its own demise is the declarative syntax.
Instead of each daemon writing a long script or program to start/stop it, it just declares its requirements and another program (currently only systemd) deals with the rest in a reliable repeatable manner.
In a post-systemd world, it should be easier for another program to use this declarative syntax than to emulate or run the older potentially hundreds of lines long shell scripts.
an interpreter for the systemd-style declarative syntax could be added to other init systems like openrc or other alternatives (maybe even sysv init, or upstart if someone decides to continue feature development on them) allowing this new syntax to be more portable than shell scripts.
(Whether someone will do this is another question)
not that process tracking even needs to be a part of the init program itself (like in openrc, i think)
but still, if a program misbehaves it is the programs fault and it should be fixed
Comment
-
*whoosh*
you have more or less decided to ignore everything from my post.
dependency based init systems can track dependencies. but having a declarative syntax that is not linked to internal implementation allows for greater portability than sysv init style shell scripts.
This can be useful even if you dislike systemd and never want to use it. Its a step forward.
You can dislike or not use the rest of systemd, but if there is a declarative syntax that other inits can adopt without affecting internal implementation, that is a good thing.
(whether a bug is a problem for the program or for the monitoring process does not matter - it still needs to be dealt with and bugs do occur.)
Comment
-
Originally posted by You- View Postyou have more or less decided to ignore everything from my post.
dependency based init systems can track dependencies. but having a declarative syntax that is not linked to internal implementation allows for greater portability than sysv init style shell scripts.
This can be useful even if you dislike systemd and never want to use it. Its a step forward.
You can dislike or not use the rest of systemd, but if there is a declarative syntax that other inits can adopt without affecting internal implementation, that is a good thing.
(whether a bug is a problem for the program or for the monitoring process does not matter - it still needs to be dealt with and bugs do occur.)
the good thing about .service files is that they are set up as FSA
"exec upon entry" -> "exec the thing itself" -> "exec on exit"
so the abstraction is there
problem is that they are not just for starting programs, but also for mounting disks, bringing the network up and much more
and those things are not as simple as one might think (and should have nothing to do with starting programs)
look at .unit files for this part,
the part that belongs in modprobe.d and udev rules.d as it has nothing to do with init dependencies (as it is device configuration)
just to say, and don't drag me on this: init scripts are portable, if written correctlyLast edited by gens; 11 November 2014, 10:52 AM.
Comment
-
Originally posted by gens View Postand if they weren't, it would be easy to make a tool that configures them
How about this: You create a prototype that incorporates all this supposedly trivial stuff into a complete whole and build a distro on top of it. As it's just a prototype, you don't have to package much - something that prepares a few consoles, starts a ssh server and a light web server. Of course, everything managed and upgradeable by a package manager. To match systemd's feature set at least a little bit, it should be possible with an easy statement to limit the resource usage of the web server _and all its subprocesses_. And there should be a simple option to have the ssh server start on-demand instead of immediately at boot. As this will be just a prototype, stuff that DE devs want (notably logind) can be ignored for now, bug going beyond a prototype, logind would need to be taken care of too.
There's one thing that should be mentioned here: If you plan to use runit as the service supervisor, note than neither Ignite (a framework of scripts to use runit on Arch) nor Void Linux (that distro that recently switched to runit) use runit so supervise udevd. They start udevd is the stage1 script. The only reason for that I can come up with is that runit can't handle udev properly. For example, systemd doesn't need "udevadm settle" (something that's run in the stage1 scripts I mentioned), systemd can take udev events as the come and properly react to them, no matter when these events appear. Runit can't, and so a critical component of today's Linux systems is running *outside the supervisor's supervision*. You should also take care of this little problem.
Originally posted by gens View Postbut still, if a program misbehaves it is the programs fault and it should be fixed
Jeez. And then you complain that after months of pulling this kind of stuff, being dismissive and arrogant and such, someone calls you a bad word? There's not much else one can do, as it doesn't seem you're capable of proper communication.
Comment
-
Originally posted by gens View Post"Regarding that the init systemd isn't primitive and crude like SysVinit"
"All in all, systemd is just status quo for Linux regarding Unix/Posix compliance; if the principle is sound and can solve real world problems, then fine, if not, dump it. "
sysvinit bad, systemd good
And yeah, systemd is _really_ good stuff. A huge improvement over even Upstart.
Originally posted by gens View Post"Linux isn't Unix and will never be. It is a OS' on its own, and if Linus Torvalds has a mission statement for Linux, then it is that Linux should solve real world problems and never just be a show case for philosophical or technological dogmas. Linux is made for end users, not OS designers."
despite this and the fact that UNIX was made to solve real world problems
this quoted message is just saying "desktop users know better then system designers"
Linus is perfectly fine with using the Linux kernel in non-Posix, non-Unix environments like Android.
Originally posted by gens View Post"Booting a system while essential disks are missing is just a stupid idea that can lead to silent data loss and corruption. The "Rule of Repair" is just the right thing to apply to such critical disks. That SysVinit doesn't follow Unix philosophy in this regards is probably because it is so primitive and with no real design plan behind it. "
this is just wrong (and sysvinit bad, systemd good)
"Booting a system while essential disks are missing" is not even possible
Originally posted by gens View Post"That SysVinit doesn't follow Unix philosophy in this regards is probably because it is so primitive and with no real design plan behind it."
there are years of real design planing behind using the shell for init
the biggest reasons behind it are that it is easy to debug and easy to fix if something goes bonkers (and easy to extend to any use scenario)
In short, SysVinit remains "simple" by moving complexity over in daemons. It is much better to have a single implementation of the complexity in a single, centralised init system and then have simple daemons, than having a simple init system at the cost of many complex daemons.
See also: http://www.freedesktop.org/software/...an/daemon.html
Comment
-
Originally posted by Gusar View PostAh yes, and by saying that, everything is fine, right? So why is there even a need for service supervisors? All programs run peachy all the time and never misbehave! And if they do, you just fix them. Just like that, trivially! A perfect world with rainbows and unicorns!
if its problem is fixed by systemd killing every spawned process, then apache should not be fixed ?
ofc it should be fixed
problem -> quick patch -> proper fix
stopping at "quick patch" and calling it good is a bad thing
edit: now there is 3 of you
i can't reply to all of you, so... good bye
what to say.. idk... i suggest making a simple init yourself to get better acquainted with how they work (i did, before you start picking on words again)
PS init's are simple, don't believe when somebody tells you that they are complicatedLast edited by gens; 11 November 2014, 11:06 AM.
Comment
-
Originally posted by gens View Postif its problem is fixed by systemd killing every spawned process, then apache should not be fixed ?
Originally posted by gens View Posti did, before you start picking on words again
Originally posted by gens View Posti can't reply to all of you, so... good bye
Comment
-
Originally posted by gens View Postwas it you that made apache spawning things an example ?
if its problem is fixed by systemd killing every spawned process, then apache should not be fixed ?
ofc it should be fixed
problem -> quick patch -> proper fix
stopping at "quick patch" and calling it good is a bad thing
edit: now there is 3 of you
i can't reply to all of you, so... good bye
what to say.. idk... i suggest making a simple init yourself to get better acquainted with how they work (i did, before you start picking on words again)
PS init's are simple, don't believe when somebody tells you that they are complicated
Comment
Comment