Announcement

Collapse
No announcement yet.

Ubuntu Cloud Switches Over To Using Systemd By Default

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

  • pal666
    replied
    Originally posted by cocklover View Post
    I
    your nickname sums up your posts nicely

    Leave a comment:


  • MoonMoon
    replied
    Originally posted by gens View Post
    systemd-resolved ?
    it's coming, don't worry

    PS it's good that it isn't default as it isn't no where near being complete enough
    i still mention it as it lives in the repo
    Systemd-resolved is a service that is not part of the init system, just like systemd-networkd, systemd-timedated and so on. You know that, I am pretty sure, but still you are twisting it as if it would be part of the init system. This counts as intentionally lying and costs you your credibility.

    Leave a comment:


  • SystemCrasher
    replied
    Originally posted by gens View Post
    ye... i mean an init system that does not do DNS caching... so 1990's
    While I do not care about much about DNS caching,
    1) I do care about logging. I do care about making logs hard to tamper with, in ways which are hard to detect. I do care about loss of log records before logging daemon is operational. Systemd takes care of it. Others chosen to ignore it. So they have to face the result of their ignorance. Nothing more, nothing less.
    2) I also care about sane boot sequence failures logging. It is very nice when I can get idea what goes wrong in simple and civilized way. Systemd seems to be best here. Upstart takes some care but overall seems to be worse on this. Not to mention in realistic cases it also half-upstart and half-sysv system. And in sysv init ... nobody gives it a fuck. It is completely up to me to code all logging if something goes wrong. Most init scripts would totally ignore return codes and do not care about failures either. Hmmph.
    3) I also care about more or less sane enable/disable of services. And I would not call what sysv init does "sane". This is real insanity. Not to mention this "runleves" idiocy maps very poorly on upstart. Let kill it with fire. Hopefully no traces of this shit will remain in most Linux systems I would like to deal with.
    4) I do care about proper boot sequencing and dependencies. I may want to start "this fancy program" right before or after "something". And one more time, systemd wins - just couple of lines in config file and I get what I want. Upstart? Okay, it can handle it. Most of time. Yet, some approaches used in upstart could make dependency expression quite hard in some cases. Sysv init? Oh, let it burn in hell.
    5) I also care to set proper UID, GID and priority. Sure, some programs can do it on their own. But not all of them. Upstart and systemd take care of this and this is really convenient. Systemd haves more features of this kind and therefore declared winner for me. Basically it is much easier to issue few syscalls from C program rather than mess with all this crap via scripts. Systemd and upstart can do it for me. Nice.
    6) In some cases I also care if particular program will restart on crash without human intervention. In systemd and upstart it is matter of couple config lines. As well as limiting intensity of restarts, should service runtime data became broken to degree service fails to start at all. In sysv init I'm basically on my own.
    7) I do care about containers. Even lame and insecure chroot is a challenge to set up if I use sysv init. Not to mention containers. OTOH systemd is the only thing around which is aware of the fact Linux got cgroups and namespaces and these are far more fun than just sucking chroot. Sure, I can code my own launcher in C to put my process to separate namespaces and so on. Yet it will be great if I do not have to reinvent the wheel. Systemd takes care of it. That's what I warmly welcome! . It is not yet does all I want, but it was the ONLY solution which recognized mentioned problems and bothered self to relieve admins from hardcore system-level coding. Its really wrong Linux had such nice features but lacked proper tooling to use them except doing all syscalls directly on my own.
    8) I also care about VMs and somesuch. Poettering seems to share this idea and also cares about deployment from templates, accounting running VMs/containers and managing these. Granted KVM is a part of Linux kernel, I warmly welcome tools to use modern Linux features with minimal efforts. Not like if I want to write my own VM registration facility or tools to deploy VM or container from template.
    9) I also care about snapshots, "reset system to defaults" and somesuch. On VM I usually can revert snapshot in a matter of seconds and voila: clean, working system is here, ready to serve. Somehow, I think it is a time for bare metal to be "blessed" with snaphot magic as well. And obviously I do not want to reinvent the wheel myself.

    10) Last but not least, I also care about simplicity and sanity. Patching shell code from (probably drunken) coders who embed configuration data right into 500th line of code is not a fun at all. Its just fucking wrong to mix code and configuration data in same place and almost nobody of shell script kiddies bothered self to learn how to do it right. Not to mention each and every distro does it their own way, usually incompatible with others. So it is pain in the ass to fix or port such scripts. I think scripts should be exception for "difficult cases" when there was no way to avoid program logic rather than norm instead of configuration data, when even simple, very usual program comes with some hundreds of lines of unobvious code just to launch it.

    Leave a comment:


  • gens
    replied
    Originally posted by MoonMoon View Post
    That is funny, I am running systemd and my PID1 (the actual init) does not do DNS caching. Maybe you try to inform yourself better before spreading lies. At this point, with all the expertise you claim to have, I can't believe that this is just a misunderstanding, it is pretty obvious that you spread this lies on purpose, degrading yourself to a troll and seriously damaging your image and the argument you try to make. Why should anyone believe something that a person has to say that is so obviously trying to spread misinformation?

    Good work, making you look bad by yourself, dude.
    systemd-resolved ?
    it's coming, don't worry

    PS it's good that it isn't default as it isn't no where near being complete enough
    i still mention it as it lives in the repo
    Last edited by gens; 05 March 2015, 09:32 PM.

    Leave a comment:


  • MoonMoon
    replied
    Originally posted by gens View Post
    ye... i mean an init system that does not do DNS caching... so 1990's
    That is funny, I am running systemd and my PID1 (the actual init) does not do DNS caching. Maybe you try to inform yourself better before spreading lies. At this point, with all the expertise you claim to have, I can't believe that this is just a misunderstanding, it is pretty obvious that you spread this lies on purpose, degrading yourself to a troll and seriously damaging your image and the argument you try to make. Why should anyone believe something that a person has to say that is so obviously trying to spread misinformation?

    Good work, making you look bad by yourself, dude.

    Leave a comment:


  • MoonMoon
    replied
    Originally posted by cocklover View Post
    I don't believe neither of those features, first of all there was never fragmentation, at least at the beggining, then Cannonical developed his own service manager and we have 2, but upstart was a ubuntu thing only, but sure it was available on Centos 6( I Believe).
    Go ahead, try to enable a service only for runlevel 4 on Debian, RHEL/CentOS, openSuse, Gentoo and Slackware (of course, where necessary in pre-systemd versions). Then come back and tell us how there was no fragmentation.

    Leave a comment:


  • MoonMoon
    replied
    Originally posted by Pawlerson View Post
    Finally! No more stupid upstart behavior. When I install something it doesn't mean I want to have it started automatically.
    That behavior is caused by your package manager, not Upstream.
    When I want to disable some service I don't want to mess with stupid configuration files and put strange things in there. I want to be able to disable it via a simple command. Welcome, systemd. You're saving my time!
    Code:
    man update-rc.d
    Once again someone blaming his own incompetence on a piece of software.

    Leave a comment:


  • gens
    replied
    Originally posted by SystemCrasher View Post
    And upstart ... while it is not that bad, it definitely losing to systemd in terms of features I would like to see.
    ye... i mean an init system that does not do DNS caching... so 1990's

    Leave a comment:


  • Karl Napf
    replied
    Originally posted by cocklover View Post
    I don't believe neither of those features, first of all there was never fragmentation, at least at the beggining, then Cannonical developed his own service manager and we have 2, but upstart was a ubuntu thing only, but sure it was available on Centos 6( I Believe). Then it arrive systemd to and the real fragmentation started. Gentoo with his own, other guys developing another service manager, forking systemd and removing bloatware. So there is framentation right know cause of systemd. And there will be more and more. Cause not all people like systemd.
    You seem to remember this different from how I do. First sysv-init was not the first init system: That honor goes to bsd-style inits (basically just a script). When sysv-init was introduced we had huge discussions about replacing the simple elegance of one script with a mess of symlinks. Sysv-init was called a over-complicated aberration and a clear departure of Linux from the unix philosophy. History does repeat itself;-)

    Then Sysv-init was never one system in any sense of the word. Each and every distribution had its own set of helper functions and scripts and whatnot, that heavily differed from any other. At the same time there were lots of other init systems around. There was makefile based on, several that got rid of the symlinks by managing runlevels in a text file and lots of others.

    Upstart then came along and got the ball rolling. That is the biggest contribution from canonical to the Linux ecosystem: They kicked off a huge spurt of innovation with upstart. Systemd is one reaction to upstart by some guy that thought he could do better. I guess he was right:-)

    There still are a bunch of other init systems out there, like there always were, but systemd is the one that won for now and that will most likely be the default for the next couple of years.

    Leave a comment:


  • SystemCrasher
    replied
    Originally posted by cocklover View Post
    I don't believe neither of those features, first of all there was never fragmentation, at least at the beggining,
    Blatant bullshit! Init scripts were never compatible across distros. Say, good luck to use init scripts from Centos in Ubuntu or vice versa. They tend have different paths here and there and you have to heavily patch scripts. And code of most scripts is just horrible to say the least. Most of scripters just insert parameters into code. So after scrolling three pages you can find offending path you should change. And if you fail to do it right ... er, good luck in debugging. There was even no standard means of logging startup problems. UTTER CRAP.

    Sysv init does not gives it a fuck to bunch of long-standing system administration challenges. Standard approach was to ignore all hardships and let admins face all problems on their own, being annoyance rather than admin's help. So everyone had to reinvent the wheel, eventually facing some corner cases which aren't anyhow pleasant to deal with through shell scripts and somesuch.

    That's not a way I want to manage services startup in my system for sure. Systemd can do it better than that. Because it is really hard to make it worse .
    Last edited by SystemCrasher; 04 March 2015, 11:58 PM.

    Leave a comment:

Working...
X