Announcement

Collapse
No announcement yet.

Ubuntu 18.04 LTS Final Beta Released

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

  • #31
    Originally posted by makam View Post
    On the other hand on Openrc an application misbehaves, Openrc catches it, writes and logs the error, but it still boots. It does not matter if it boots in a broken state, but damn it it needs to boot.
    If something marked as important is broken there is no point in booting, it might work enough to allow recovery, or cause more damage. The safest action is blocking boot. The init can't guess and should not guess.

    Either an operator has to take over and take the decision and responsibility on what to do next, or the maintainer of the system and services (distro maintainers for most distros) should have forseen these possible issues and wrote down a better configuration so the services start up properly, or marked the secondary stuff as not important so that systemd will not block boot even if that fails.

    But it's not like systemd can't boot at all if there are issues. It just does not do so automatically.

    With systemd you can boot to a rescue shell if you append to kernel command line systemd.unit=recovery.target or even systemd.unit=emergency.target (and the system isn't so trashed that even basic stuff does not work), or if the issue is in the graphical desktop you can boot to your distro's shell with systemd.unit=multi-user.target.

    Can you do the same if init scripts fuck up? Yeah, yeah you can (you can specify the init script runlevel in the kernel command line, write the number of the runlevel as the last thing in the kernel command line), although I don't know if OpenRC has this feature (it worked in Debian, before the switch to systemd).

    But the problem is like how you said at the end of your post, systemd is BULLISH and it created more than a couple of problems for me and many many others. I don't need nor want a nanny init.
    The main point here is that you stated that systemd is better than openRC, if you personally prefer something because you like simpler stuff it's fine.

    It took me 0 months to get on friendly terms with openrc.
    This does not make openRC better. Even keeping the older sysvinit would have needed 0 months to get on friendly terms with it (as you already knew how to use it).

    Well if he cares so much about the purity of his projects perhaps he should reconsider on how people are adding ridicualous modules that should not be in an init system. I would be fine with systemd if it limited its scope more. Limiting your scope is also a form of purity.
    There are no "modules" as it isn't a monolithic system.

    All programs in systemd repo are standalone daemons and run independently of the init system itself (or they are tools), on clearly defined and stable interfaces.

    This follows Unix philosophy about modularity and inter-operatibility from the mantra "do one thing and do it well". Each daemon is focused on a specific task, and the whole system can work with or without. They are just kept in the same source repo and where it makes sense they share code (through shared libraries).
    Last edited by starshipeleven; 09 April 2018, 11:12 AM.

    Comment


    • #32
      Originally posted by makam View Post

      Then why are are we using systemd and not openrc?
      Because as he said, the better technology has won.

      Comment


      • #33
        Originally posted by starshipeleven View Post
        not yet.
        Ubuntu Core is a Snap distro.

        Comment


        • #34
          Originally posted by jo-erlend View Post

          Ubuntu Core is a Snap distro.
          I am pretty sure that the kernel and basic GNU tools are in debs not in snaps. Everything else however is in snaps.

          Comment


          • #35
            Originally posted by Flaburgan View Post

            That doesn't tell me why there is no flavor.
            No-one has bothered to make an official proposal to canonical? Or maybe they are unable to meet their requirements for official flavours, who knows.
            Btw. Kubuntu still exists in some form.

            Comment


            • #36
              Originally posted by makam View Post
              I am pretty sure that the kernel and basic GNU tools are in debs not in snaps. Everything else however is in snaps.
              Wrong. It's all in snaps, even the kernel. https://uappexplorer.com/snaps?type=kernel

              Of course the snap containing the kernel can have all sandboxing and isolation security features enabled if they want, but the kernel still has full power over anything, being it the kernel. It's just a plain re-package for the sake of going 100% snap.

              Comment


              • #37
                Oh well, I stand corrected.

                Comment


                • #38
                  Okay but why does the new serverserver ins not support mdadm or encryption?? Puzzled, rolling back to 16.04.
                  do like that with regular shell could at least manage encryption etc in another terminal during installer.

                  Comment


                  • #39
                    Server installer.....
                    mobile fun.

                    Comment


                    • #40
                      Originally posted by makam View Post

                      I am pretty sure that the kernel and basic GNU tools are in debs not in snaps. Everything else however is in snaps.
                      False. The kernel, userland and everything else is snapped. There are no debs.

                      Comment

                      Working...
                      X