Announcement

Collapse
No announcement yet.

Devuan 1.0 Makes It To A Release Candidate: Debian Without Systemd

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

  • #81
    Originally posted by groharpon42 View Post
    Why not runit ? I know very little about init systems but I use void linux every day and I'm very happy with it.
    I don't know it so I can't recommend it. I've used OpenRC.

    Comment


    • #82
      Originally posted by profoundWHALE View Post
      FreeBSD uses rc
      Which looks very similar to sysvinit and imho inferior to OpenRC.

      I don't think it would be "What Upstart was supposed to become" but OpenRC did come out a year after Upstart.
      Well, it's not a secret that both Upstart and OpenRC are both next-gen inits supposed to fix sysvinit's retardedness.
      Main difference is that OpenRC works reliably and it's overall easier to understand/use while Upstart often failed to do basic stuff like multithreaded startup and was ultimately axed by anyone other than Canonical because of its failures.

      Comment


      • #83
        Originally posted by bnolsen View Post
        My 2 main dev systems (athlon2 x4 for term and dual xeon e5 ivy bridge) are archlinux. Their boot times have also degraded with the systemd switchover and I have some problems with the term wireless and occasionally with the dual xeon's crossover cable network now occasionally stalling the whole boot process. I used to run an nfs server which wasn't much fun with systemd either...
        You tried troubleshooting with systemd analyze-blame?

        Also, what is a crossover cable network? Gigabit NICs don't need crossover cables.

        Comment


        • #84
          Originally posted by oiaohm View Post
          https://www.freebsd.org/cgi/man.cgi?...&sektion=8
          Read run_rc_command then compared to what sysvinit run command does and you will find bsd rc is doing a lot more. Even the freebsd man page does fail to mention its used a login per service so services doing bad things are in fact traceable when they are not under sysvinit.

          Yes rc and sysvinit look the same because both have /etc/rc.d directories but they function vastly differently. BSD rc is designed to work with the BSD kernel and function correctly. Sysvinit needs to be replaced. If you like something like sysvinit work on openrc.

          runit still has the issue of being designed only to use posix functions to be cross platform so does not behave 100 percent correctly on Linux or BSD kernels. Its the event when a parent process dies and the child end up connected to pid1 just like sysvinit runit has nothing on the processes run to tell you what service has done that. Openrc, Systemd and bsd rc all have ways of getting what started the process that is now connected to pid1.

          Yes it possible to make a init system fully in scripts that functions properly BSD proves this. Sysvinit does not function properly no amount of demand sysvinit has changed that fact. I have not seen any new version that attempt to address the faults other than openrc. Yes we don't like systemd is one thing. Not fixing the faults in sysvinit and saying stay with sysvinit is stupid behaviour.

          Complain that systemd is broken and suggesting change to another broken with no roadmap to fix it faults like sysvinit is going to be rejected by a lot of people.

          If you don't like systemd make a init system that functions better in call cases. Don't ignore the corner case of defects. At least gentoo is attempting to-do that with openrc.

          Why the distributions have gone systemd is they can seen a roadmap that over time should lead them away from the existing problems they had with sysvinit and possible to submit fixes up stream to fix systemd so the short term pain is worth it. No amount of blame Redhat, Microsoft or anyone else is going to change the reason Distributions changed away from sysvinit. Distributions attempted to go to upstart before systemd but a key part of it design was broken as well.

          Yes lest ignore that most of the distributions that are running systemd now were running upstart to get away from sysvinit defects.

          People need to stop blaming and take a serous look at the problem and be realistic.

          Please stop the claim systemd is religious. Systemd users are not religious some of the anti-systemd people are with the religion of the Unix way. Systemd distribution and users like systemd because it addresses the problems they suffer from. Yes people hate systemd because it causes some problems for them as well. Those wanting to return to sysvinit are attempt to throw the baby out with the bath water. They have not bothered to learn what systemd is in fact doing better than sysvinit and then bringing something sysvinit like up to that level.

          Reality is the Debian vote on systemd clearly left it open that the debate about what init system debian uses could be reopened if a init system that behaved properly is presented because systemd is not cross platform enough. The door is open to change de
          It's also a practical matter based on the lack of commitment of parallel projects (such as udev) to maintain a project agnostic of init system. One of the considerations of the Debian technical committee was the difficulty of maintaining forked (or sanitized) core utilities already overtaken by the Poettering junta.

          Comment


          • #85
            Originally posted by GDJacobs View Post
            It's also a practical matter based on the lack of commitment of parallel projects (such as udev) to maintain a project agnostic of init system. One of the considerations of the Debian technical committee was the difficulty of maintaining forked (or sanitized) core utilities already overtaken by the Poettering junta.
            Lol, what "core utilities" were overtaken?

            Comment


            • #86
              devuan LOL

              Comment


              • #87
                Originally posted by GDJacobs View Post

                It's also a practical matter based on the lack of commitment of parallel projects (such as udev) to maintain a project agnostic of init system. One of the considerations of the Debian technical committee was the difficulty of maintaining forked (or sanitized) core utilities already overtaken by the Poettering junta.
                There is a practical matter before systemd core parts like udev were not getting the developers. Can you build udev in systemd without building anything else systemd the answer is yes it still stand alone. Debian runs multi init systems using the systemd udev.

                So some of devuan problem is a total point of view that they must not use anything systemd. Instead coming a maintainer on systemd to make and maintain those parts building independent is an option.

                Before systemd what was happing with udev and many other core parts with people writing init systems is that it was someone else problem. When everyone thinks something is someone else problem no one works on it. Now that udev is part of systemd and you want to keep it working with you init system you need to send a developer/maintainer or write your own.

                There are a long list of attempts to write own udev done by those who have a anti-systemd bent.

                If you list them all there is no one of them with enough people to maintain them. In the maintained udev alternatives you have mdev that is from busybox it is also maintained bundled with the busybox init system that is part of the busybox core.

                The only stand alone fork of systemd udev that is maintained is eudev

                The most maintained of the udev forks is the gentoo one. Please note how many personal maintaining that is gentoo. Is there a devuan person helping maintain eudev no they are not. So if gentoo ever decides to give up on the project it is dead.

                devuan suffers badly from NIH. You have seen devuan guys start like 8 different forks to udev that all basically die 12 months due to lack of personal.

                You have the consideration by Debian wrong. Debian was sick of maintain non up-streamed patches to udev that they could not upstream due to lack of maintainership of the udev upsteam.


                https://talk.devuan.org/t/eudev-a-re...e-for-udev/589 if you want to see stupid is this. devuan guy forking the eudev. Lets provide eudev with no more maintainers.

                Repository for eudev development. Contribute to eudev-project/eudev development by creating an account on GitHub.


                Maybe they did not want to point to the real eudev site that clearly states that eudev is directly based on the systemd udev source.

                Systemd absorbed under maintained project after under maintained projects. Its now that broad that is most likely impossible to have fully functional system without at least something either directly from systemd project or based off of systemd project.

                Does all this unified maintainer-ship of systemd parts stop init systems from being developed using systemd parts the answer is no it does not. Keeping and making systemd properly modular so it comes like gnu core utilities is where a lot of work need to go.

                Also create a 2 deep forking like the devuan guy suggested is stupid. Remember each layer of forking slows down the propagation of security fixes.

                Systemd would not have merged as many projects if those project had been properly maintained.

                Devuan guys are so slow getting anywhere due to being way too far anti-systemd to be practical so creating themselves a stack of problems that really don't exist anywhere else other than their mind.

                Comment


                • #88
                  Works fine enough for me, this Devuan 1.0 RC installer - that is all what matters in this thread

                  Comment


                  • #89
                    What does this mean in practice?
                    Does it still come with Systemd but we can opt out?
                    Or does it comes preconfigured with some other init system?

                    Comment


                    • #90
                      Originally posted by TheBlackCat View Post
                      That is a pretty ironic thing to say since Apple is also a *nix (in fact it is a Unix, unlike Linux). Maybe you should learn "about what *nix is" before telling other people to.
                      Apple isn't just *Nix, unlike GNU, Linux, or FreeBSD, Apple is actually POSIX certified, so OS X is real UNIX. Few modern operating systems can make this claim. Linux and GNU implement most of the POSIX API calls, while FreeBSD maintains the spirit of the UNIX Community from the golden age, and is a direct port of the Berkeley Software Distribution by its original authors.

                      That said, there is a lot of ignorance and fearmongering from the devaun sysv-init side, and I really think they don't understand computers. Before they run their mouths at people "just being users", they should learn their history. Systemd is not written for Linux, its written for GNU. It will not run on non-GNU systems. GNU never, ever ever ever, followed the UNIX methodology. FreeBSD does, GNU does not. The famous Torvalds Tannenbaum debate, Linux himself favored complete, roubust solutions instead of lots of minimalist flexible tools.

                      GNU has always been about very heavyweight feature complete solutions. Linus has always stated Linux was about showcasing the best Free software and the best functionality. He never liked "software choice".

                      Systemd is an extension of both GNU and Linux philosophy as stated by the founders of both projects.

                      Then lets get to the technical operation of systemd. It works, it works well, and traditional sysvinit and scripts where a giant fucking mess. There is not a greater weak point than relying on shell scripts for your start up. its a convoluted mess, and makes process tracking nigh impossible. Stuff like pid tracking is done automatically, and doesn't rely on depending on someone to write a shell script to do it. Systemd units are far easier to read than shell scripts, and there is far less room for fucking one up. Systemd is very modular and doesn't need all modules to run, but it provides enough modules that alone it can boot a working system, hence replacing the role of init scripts in their entirity(yes, init scripts did previously set up the network).

                      The worst part of previous init scripts is that every distribution had completely different ways of managing init, which means doing something simple like changing the network configuration was different on every distro. So if you write daemon software, you will need to re-write and test units for every distro, or let them write their own which often leads to failure of sub optimal scenarios. Before systemd, a unified cross distro init system was needed. of the lot, systemd is the best, most roboust, for carrying GNU and Linux into the 21st century and offer the best competition to windows and osx.

                      Devaun is going absolutely nowhere. Despite the outcry over systemd, most users, most administrators, and most developers either don't care or actually like systemd. I'd say I'd wish them the best on devaun, but watching them fail when they realize they don't have enough talented people to maintain it, and it, and the industry just ignores them is going to be funny. To anyone who jumped ship over systemd butthurt, don't let the door hit you on the way out. The linux community will be better without your baseless conspiracy theories.
                      Last edited by GI_Jack; 24 April 2017, 11:24 AM.

                      Comment

                      Working...
                      X