Announcement

Collapse
No announcement yet.

Systemd Works On PPPoE Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mlauritsen
    replied
    Originally posted by gens View Post
    i still have not found a post that explains how systemd brought anything new to linux
    most of them come down to "sysvinit is bad", ignoring a plethora of other init systems (and there are many)
    this one is no exception
    The computers that System V init and BSD init were designed for didn't look like the computers that Linux runs on today.

    Things like hot pluggable hardware, networked storage, virtualization and containers, suspend/resume, mobile devices and the modern Linux kernel with its features for process management etc. basically didn't exist, so it's only natural that they were not supported by the init systems.

    Today, for an init to be usable in general all of these things must be properly supported, and we also need features like proper logging (indexed, tamper proof etc.).

    The people behind systemd set out to do better. They evaluated the existing solutions, upstart and launchd included, and reached the conclusion that the best end result would be achieved by starting from scratch with a new design instead of trying to make more or less hackish extensions to the old code. Yes, with this being software the latter is clearly doable, but in some cases starting with a clean slate is better - see item (3) in RFC1925.

    So what you get from systemd is among other things a well structured, high performance, accessible, reliable, tested and documented init that matches the requirements made by modern Linux installations. You won't get that from any of the alternatives.

    Leave a comment:


  • psychoticmeow
    replied
    Originally posted by gens View Post
    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"...

    Leave a comment:


  • Gusar
    replied
    Originally posted by gens View Post
    if its problem is fixed by systemd killing every spawned process, then apache should not be fixed ?
    strawman much?

    Originally posted by gens View Post
    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?

    Originally posted by gens View Post
    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"?

    Leave a comment:


  • gens
    replied
    Originally posted by Gusar View Post
    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
    Last edited by gens; 11 November 2014, 11:06 AM.

    Leave a comment:


  • interested
    replied
    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
    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.

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


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


    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)
    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
    Last edited by interested; 11 November 2014, 11:04 AM. Reason: Typo

    Leave a comment:


  • Gusar
    replied
    Originally posted by gens View Post
    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.


    Originally posted by gens View Post
    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.

    Leave a comment:


  • gens
    replied
    Originally posted by You- View Post
    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
    Last edited by gens; 11 November 2014, 10:52 AM.

    Leave a comment:


  • You-
    replied
    *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.)

    Leave a comment:


  • gens
    replied
    Originally posted by You- View Post
    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

    Leave a comment:


  • You-
    replied
    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)

    Leave a comment:

Working...
X