Systemd Works On PPPoE Support

[psychoticmeow]

they are easily accessible and configurable
and if they weren't, it would be easy to make a tool that configures them

test suite ?
systemd devs have proven that they don't debug

and i said scripts are easy, but they are not the only other way to boot a system
upstart, openrc, s6, runit, etc.

and again you are insulting for no reason so i won't reply to anything else you say
have a nice day kid

As I said, you ignore what we say when we point out why you're wrong, and I'm the "kid" in this scenario? As midly offensive as "idiot" and "moron" are, the really disgusting insult is you posting willfully ignorant bullshit time and time again.

[You-]

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)

[gens]

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)

any dependency resolving and process tracking init brings that
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

[You-]

*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.)

[gens]

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.)

yes, i understand where you are going with that

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 correctly

[Gusar]

and if they weren't, it would be easy to make a tool that configures them

Why isn't there such a tool then? You're so big on the talk how everything systemd does can be trivially done without it. But why hasn't it been done yet then? You have nothing to show for your big talk.

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.

but still, if a program misbehaves it is the programs fault and it should be fixed

Ah 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!

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.

[interested]

"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

I am hardly alone in thinking SysVinit is crude, primitive and obsolete. Most major Linux distros where moving away from SysVinit before systemd even existed. And when the Debian CTTE had to decide for a new init system, SysVinit was seen by every CTTE member as the least desirable init-system of all contenders.

And yeah, systemd is _really_ good stuff. A huge improvement over even Upstart.

"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"

Everyone who have followed the LKML over the decades knows that the above is Linus' driving opinion; if he thinks a particular Posix detail is wrong and stupid, he ignores it in favour of a sane and working solution. He also ignores current CS fads and all the "right opinions" about OS design if it goes again user needs. This is why the Linux kernel is monolithic, despite the then current trend of microkernels. It is not that Linus didn't know and accept the many advantages of a microkernel design (he has a CS Phd), but he just cared more about end users than making a "perfect design", and end users wanted speed, and that meant a monolithic kernel.
Linus is perfectly fine with using the Linux kernel in non-Posix, non-Unix environments like Android.

"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

Yes it is under SysVinit. I am not talking about / or /usr, /etc, etc, but about other mount points that may contain important data generated by eg. a daemon. SysVinit just ignores problematic fstab entries and trundles on. Perhaps it is easy to make SysVinit distros have the proper Unix behaviour in this regard, perhaps not.

"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)

There is no plan, road map or design documentation behind SysVinit. SysVinit is simple/crude because it doesn't accept its natural responsibility as init system; eg. it is up to each and every SysVinit daemon requiring e.g. a low port number to develop its own privilege dropping code. Dropping privileges is a low level thing that easily goes wrong leading to security issues. Having hundreds of different low privilege dropping implementations in each and every daemon, instead of just one centralised one is just plain bad design.

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

[gens]

Ah 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!

was 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

[Gusar]

if its problem is fixed by systemd killing every spawned process, then apache should not be fixed ?

strawman much?

i did, before you start picking on words again

I can only repeat - where is it then? And does it provide the stuff I said your prototype should provide?

i can't reply to all of you, so... good bye

Can't provide proper responses so you bail with a "they're ganging up on me"?

[psychoticmeow]

was 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

All these words just to say "nuh uh". That's right, just stick your fingers in your ears and "lalalalalala I can't hear you"...