Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Sunday November 23 2014, @01:39AM   Printer-friendly
from the first-do-no-harm dept.

I am the maintainer of the Epoch Init System, a single threaded Linux init system with non-intrusiveness in mind, and I'm preparing to release 2.0. It's mostly a code cleanup release, but while I'm at it, I thought I'd ask the Soylent community what features they'd like to see. I'm open to all good ideas, but I'm wary of feature creep, so as a result, I won't consider the following:

* multithreaded/parallel services, because that goes against design goals of simplicity and harms customizability
* mounting support or networking support; it's an init system, use busybox if you need a mount command.

So what do soylentils want to see in the next release of the Epoch Init System?

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by cafebabe on Sunday November 23 2014, @01:58AM

    by cafebabe (894) on Sunday November 23 2014, @01:58AM (#118997) Journal

    The feature I'd like in an init system is that it should boot a system in a deterministic manner and do very little else. If it could run daemon-tools somewhere along the boot process, that would be very much appreciated.

    --
    1702845791×2
    • (Score: 4, Insightful) by davester666 on Sunday November 23 2014, @07:25AM

      by davester666 (155) on Sunday November 23 2014, @07:25AM (#119050)

      Totally. And would you mind adding the API for systemd to it, just for compatibility with other systems.

      • (Score: 1) by dlb on Sunday November 23 2014, @03:03PM

        by dlb (4790) on Sunday November 23 2014, @03:03PM (#119118)

        would you mind adding the API for systemd

        The systemd mass temper tantrum has generated so many snarky posts that on first read I couldn't tell if you were trolling or not. (In fact, I'm still not 100% certain. But that's probably due to my lack of understanding of init systems.)

        • (Score: 2) by davester666 on Tuesday November 25 2014, @09:12AM

          by davester666 (155) on Tuesday November 25 2014, @09:12AM (#119730)

          trolling/whooshing....adding the systemd interface would go 100% against the whole k.i.s.s. thing...

  • (Score: 0, Interesting) by Anonymous Coward on Sunday November 23 2014, @02:07AM

    by Anonymous Coward on Sunday November 23 2014, @02:07AM (#118999)

    Looks like a nice system for embedded stuff.
    Anyone tried this yet with LFS?

    They are going systemd way and it has me really pissed.

    And thanks for a web page that doesn't burn my retinas or require add ons to view.

    • (Score: 2) by Subsentient on Sunday November 23 2014, @04:42AM

      by Subsentient (1111) on Sunday November 23 2014, @04:42AM (#119035) Homepage Journal

      Well not EXACTLY LFS, but I run a source-built i586+ XFCE distro I call SubLinux. It uses Epoch 1.1.1 "Sirius". That's actually why I started writing Epoch, I wanted an init system that I didn't hate for my new personal distro.

      --
      "It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
  • (Score: 3, Interesting) by Wrong Turn Ahead on Sunday November 23 2014, @02:36AM

    by Wrong Turn Ahead (3650) on Sunday November 23 2014, @02:36AM (#119008)

    It seems that you are already doing so, however please continue to develop in a sensible manner that reflects the needs of the people who actually use your software. There has been a pattern of 'doacracy thinking' -- those who write the code know better than those who do not -- that has infected and divided some rather large communities.

    Unfortunately, systemd has some heavy resources behind it and a strategy that includes getting core applications to build dependencies on it. Currently these minimal dependencies are things that can be worked around (sort of) but that will change with time. The issue isn't a lack of viable init systems to chose from, it's that systemd is the one with the most corporate muscle behind it. It matters not that it's the wrong init system for the users or that it flies in the face of the 'Linux way', so long as it benefits and furthers the agendas of a few key benefactors.

    By the way, thank you for your contributions. They are appreciated...

  • (Score: 3, Insightful) by Arik on Sunday November 23 2014, @02:40AM

    by Arik (4543) on Sunday November 23 2014, @02:40AM (#119010) Journal
    If I were designing an init system here's the basic idea I would try to implement. It's often said to 'do one thing' but I think that oversimplifies; I prefer 'make it as simple as possible but no simpler.' Often that means 'do two things, no more, no less.'

    The first process launched must be PID1 (correct me if I am wrong.) So PID1 must be involved in the init system, but does not have to *be* the init system by itself. So we would start with an incredibly simple initial module, to occupy PID1. It would do nothing but 1) launch the actual init system and 2) re-parent orphans.

    The next process, PID2, would be the actual init system. It would start handle the rest of startup until you get to your root prompt (or a display manager if you prefer,) register an orphan handler with PID1, and then exit until the machine reboots.

    Daemon supervision, if needed, should be done with a separate program, ideally one which will also take the role of orphan handler.

    Well just some ideas, I am no kernel hacker, feel free to tear them apart.

    --
    If laughter is the best medicine, who are the best doctors?
    • (Score: 2) by kaszz on Sunday November 23 2014, @03:16AM

      by kaszz (4211) on Sunday November 23 2014, @03:16AM (#119016) Journal

      Then you are paying the price of two processes and IPC between them instead of one doing it the traditional way. Though it may have benefits, but they seem unclear at the moment.

      • (Score: 2, Interesting) by khallow on Sunday November 23 2014, @03:35AM

        by khallow (3766) Subscriber Badge on Sunday November 23 2014, @03:35AM (#119022) Journal
        I've seen this proposal before. The justification is that the dirt-simple process that runs as PID 1 doesn't have anything in it to fail. And the PID 2 process can be restarted without incident. This means, so I've been told, that you can upgrade the init program without rebooting the machine, which apparently is a problem with systemd.
        • (Score: 3) by Subsentient on Sunday November 23 2014, @04:46AM

          by Subsentient (1111) on Sunday November 23 2014, @04:46AM (#119036) Homepage Journal

          You can still do that. Epoch uses IPC to transfer its process state information to the updated copy. 'epoch reexec' is all that's needed to upgrade all the way from 1.0 to the current master. And it's a *full* update.

          --
          "It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
          • (Score: 2) by sjames on Sunday November 23 2014, @02:16PM

            by sjames (2882) on Sunday November 23 2014, @02:16PM (#119103) Journal

            Surely the state should be serialized to disk in case the new instance crashes.

      • (Score: 2) by maxwell demon on Sunday November 23 2014, @11:59AM

        by maxwell demon (1608) on Sunday November 23 2014, @11:59AM (#119074) Journal

        Given that the only thing that PID1 in that proposal does, other than starting PID2, is to re-parent orphans, I don't see a lot of IPC taking place. From my understanding the main problem is that PID1 is handled specially by the Linux kernel, and thus any problem with PID1 will cause the system as a whole to fail. Which means that you would want to put as little as possible there.

        --
        The Tao of math: The numbers you can count are not the real numbers.
  • (Score: 4, Interesting) by kaszz on Sunday November 23 2014, @03:22AM

    by kaszz (4211) on Sunday November 23 2014, @03:22AM (#119019) Journal

    Keep API intact and consistent. Pay attention to the use case of users. But don't let clueless demands wreck the architecture unless it's really.

    It's right when it's right not because it works.

  • (Score: 2) by Gravis on Sunday November 23 2014, @03:33AM

    by Gravis (4596) on Sunday November 23 2014, @03:33AM (#119021)

    1) packages! one reason i choose debian is that compiling/installing/uninstalling programs manually is a pain. i would like a .deb and i'm sure other people may like a .rpm archive.
    2) configuration/validation tools (separate of course). a GUI would be nice.

  • (Score: 2) by bzipitidoo on Sunday November 23 2014, @03:50AM

    by bzipitidoo (4388) on Sunday November 23 2014, @03:50AM (#119024) Journal

    So many people are so scared of parallel programming that they avoid all parallelism. You don't have to dig up work-optimal parallel algorithms to get good and easy use from it. Race conditions and deadlocks actually can be fairly easy to avoid. For instance, the classic Dining Philosophers problem is easily solved, and even rather contrived. One solution is to have at least one philosopher obtain resources in a different order than the others.

    To get a computer up and running quickly, it's hard to see how it can be done without parallelism. Lot of people, including me, want fast boot times. I sure don't want something like the system refusing to bring up the UI because it's waiting for a DHCP server to get around to assigning an IP address.

    • (Score: 2) by tynin on Sunday November 23 2014, @03:54AM

      by tynin (2013) on Sunday November 23 2014, @03:54AM (#119025) Journal

      Equally, you don't want the system to be done mounting a filesystem when the filesystem is remote and the network hasn't finished coming up. Parallelism in an init has its use cases, but it doesn't fit all cases.

      • (Score: 3, Insightful) by tibman on Sunday November 23 2014, @06:41AM

        by tibman (134) Subscriber Badge on Sunday November 23 2014, @06:41AM (#119047)

        Init systems usually have a dependency chain to resolve that issue.

        --
        SN won't survive on lurkers alone. Write comments.
      • (Score: 2) by sjames on Sunday November 23 2014, @02:24PM

        by sjames (2882) on Sunday November 23 2014, @02:24PM (#119107) Journal

        A simple solution is to have a barrier at each priority transition. It isn't perfect, but may be a good compromise between slow serialized init and complex dependency driven start.

    • (Score: 2) by Arik on Sunday November 23 2014, @03:58AM

      by Arik (4543) on Sunday November 23 2014, @03:58AM (#119027) Journal
      "To get a computer up and running quickly, it's hard to see how it can be done without parallelism. Lot of people, including me, want fast boot times."

      I am honestly mystified by your sentiment. How often do you reboot? Why?

      "I sure don't want something like the system refusing to bring up the UI because it's waiting for a DHCP server to get around to assigning an IP address."

      That sounds like some stupid software, have you tracked down exactly which upstream needs a cluebat?
      --
      If laughter is the best medicine, who are the best doctors?
      • (Score: 2, Redundant) by bzipitidoo on Sunday November 23 2014, @04:38AM

        by bzipitidoo (4388) on Sunday November 23 2014, @04:38AM (#119034) Journal

        Frequent reboots are needed in many scenarios. Your laptop battery died. You power up and down frequently to conserve battery power. I like to shut down systems for the night, to save on my energy bill. Power outages may occur, and most people don't use a UPS. Your system can lock up. A buggy hardware driver or device can do that, thanks in part to the monolithic design of the Linux kernel. Or you could have flaky hardware that's going bad. Sometimes I work on the system, and need to reboot to check that some initialization scripts I created are working as I intended. Or I've installed a custom kernel. Or the system has done an update that requires a reboot.

        While we don't have problems with the networking scenario I gave, I wish the CUPS people had gotten a few clues sooner. Try printing when you've forgotten to turn the printer on. Frequently, I've had CUPS get stuck. Turn the printer on after trying to print, and nothing happens. No printing, no feedback to the user. The print job sits in the queue, and CUPS won't detect that the printer is now on and ready. If the user tries printing again, it only makes it worse. Rebooting the computer at that point can result in some surprising and unwanted behavior. When CUPS comes back up, it detects the printer, and that there are now several jobs in the print queue, and sends them all out. A partial solution is to configure CUPS to discard jobs when it can't print them, rather than let them sit in the queue forever, and I think discard is now the default configuration. As for detecting the printer, what is the user to do? A user that doesn't have the knowledge or privileges needed to restart CUPS has little choice but to try a reboot.

        USB is still messy, and potentially another reason to reboot. The weirdest part is the way the Linux system may increment the IDs it assigns. Plug in and remove the same flash drive repeatedly, and it may be /dev/sdb the 1st time, /dev/sdc the 2nd time, /dev/sdd the 3rd time, and so on. The system doesn't always do that, but I've seen that behavior on numerous occasions. /dev/sdb is somehow not available ever to be used again, until the system is rebooted.

        • (Score: 2) by CRCulver on Sunday November 23 2014, @08:33AM

          by CRCulver (4390) on Sunday November 23 2014, @08:33AM (#119055) Homepage

          USB is still messy, and potentially another reason to reboot. The weirdest part is the way the Linux system may increment the IDs it assigns. Plug in and remove the same flash drive repeatedly, and it may be /dev/sdb the 1st time, /dev/sdc the 2nd time, /dev/sdd the 3rd time, and so on. The system doesn't always do that, but I've seen that behavior on numerous occasions. /dev/sdb is somehow not available ever to be used again, until the system is rebooted.

          Even if the /dev/sdX number is changing, the UUID of the USB device remains the same every time it is plugged in. For years now, fstab has allowed one to specify devices by UUID, not the /dev/ device, e.g. UUID=41c22818-fbad-4da6-8196-c816df0b7aa8 /disk2p2 ext3 defaults,errors=remount-ro 0 And in your shell scripts, it's easy to grab the UUIDs of the devices attached to your computer and do something with the corresponding device.

          • (Score: 0) by Anonymous Coward on Sunday November 23 2014, @09:05AM

            by Anonymous Coward on Sunday November 23 2014, @09:05AM (#119057)

            It is a bit boring to hunt for the partition's UUID, and too hard for most users.. but funnily you can use "gnome disk utility" to deal with that crap for you (even if you're not running Gnome 3).

        • (Score: 2) by Arik on Sunday November 23 2014, @01:48PM

          by Arik (4543) on Sunday November 23 2014, @01:48PM (#119097) Journal
          "Frequent reboots are needed in many scenarios. "

          Let us list them.

          "Your laptop battery died. "

          Suspend to disk.

          "You power up and down frequently to conserve battery power. "

          Suspend to disk.

          "I like to shut down systems for the night, to save on my energy bill. "

          Suspend to disk.

          "Power outages may occur, and most people don't use a UPS. "

          Ok, here's the first one that belongs on the list. Power outages with no UPS. And that's really not good for your hardware no matter how fast you reboot. It's not that I hate people that have bad power - fact is, my power fails way more often than I would like too. But I can spare a few extra seconds in that case to make sure things are actually working after the reboot, and feel it's more appropriate to address this by eventually getting a UPS when I can afford it, rather than re-architecting the entire OS to make it slightly less annoying.

          "Your system can lock up. "

          Been using linux since 1991 and never yet seen it 'just lock up.'

          "A buggy hardware driver or device can do that, thanks in part to the monolithic design of the Linux kernel. Or you could have flaky hardware that's going bad."

          Sure, failing hardware can cause it to lock. That's a clue. You need to replace some hardware, not reboot faster. Curious as to when a proper driver has done that - it's possible but rare. And again you want to fix the problem, shaving a few seconds off the boot time doesnt do a whole lot for the underlying problem here.

          "Sometimes I work on the system, and need to reboot to check that some initialization scripts I created are working as I intended. "

          Alright, reason to reboot number two - I am testing my init system.

          I can see why someone who develops an init system would always want it to be faster, right there. But I still dont think for me personally, or for most users, it matters much.

          "Or I've installed a custom kernel. Or the system has done an update that requires a reboot."

          Right. "System has done an update" is Windows speak with no clear meaning to me in this context, but installing a new kernel does require a reboot.

          So there, we have 3 reasons that stood up to cursory scrutiny. How common are they?

          Legitimate reasons to reboot your linux box;

          1. Power went out and I havent got a UPS yet.
          2. Testing changes to init system, need to see it run.
          3. Testing changes to kernel/installing new kernel.
          --
          If laughter is the best medicine, who are the best doctors?
          • (Score: 2) by Foobar Bazbot on Sunday November 23 2014, @06:40PM

            by Foobar Bazbot (37) on Sunday November 23 2014, @06:40PM (#119163) Journal

            Look, suspend to disk is a good answer for most cases, but not all cases. My example may not be typical, but it is real:

            I have an Eee 900A with a 4GB non-upgradeable SSD, and 2GB of RAM. The 4GB SSD is over half full. A 32GB SD card is more-or-less permanently present, and is mounted under my $HOME for storing large files/trees, but I don't want swap on that; as a removable device, it's restricted to uses that won't crash the system if it's suddenly ejected.

            So what disk shall I suspend to?

            This system also has truly pathetic battery life, so saving power is important -- it's not practical to leave it on or suspended to RAM when on battery.

            Most of my computers are nothing like that, but one is -- and I bet a lot of other people have one or two systems with similar constraints that make suspend to disk impractical. Those systems do need to reboot more often than most systems, so they do present a legitimate reason to optimize boot time. Fortunately, not every system needs to run the same init, much less have it configured the same way, so there's a good argument for having parallelized boot as an option.

            • (Score: 2) by Arik on Sunday November 23 2014, @07:03PM

              by Arik (4543) on Sunday November 23 2014, @07:03PM (#119167) Journal
              I have the same model. I formatted 1gb of the internal SSD as a swap partition straight off, and it works beautifully. I'm not trying to be critical but it sounds like your mistake was not setting aside the space from the start, and then using too much disk afterwards. So delete or move things until you have enough space for your swap partition and fix it, rather than trying to re-architect the entire system around a poor decision made in the past?

              BTW it's a great piece of hardware but the bundled linux distro was so bad it looked like MS set it up. 
              --
              If laughter is the best medicine, who are the best doctors?
              • (Score: 2) by Foobar Bazbot on Monday November 24 2014, @01:32AM

                by Foobar Bazbot (37) on Monday November 24 2014, @01:32AM (#119274) Journal

                Note that I upgraded the RAM to 2GB (AFAIK it was never sold with more than 1GB), and AIUI suspend to disk in linux requires swap space equal to physical RAM*. And while I could probably have scrounged up the self-discipline to live with a 2GB root, 2GB swap scheme, I actually had a dual-boot with both Slackware and Arch. (Eventually, I replaced Slackware with Haiku, then finally blew away that partition for more space on Arch, so at this point scaling back to 2+2 is technically feasible, but it's a lot easier to keep a system small than to shrink it once I've got a ton of stuff installed...)

                *If you are actually suspending 2GB of RAM to 1GB of swap (using compression, I guess?), I'd really appreciate more info.

                • (Score: 2) by Arik on Monday November 24 2014, @01:48AM

                  by Arik (4543) on Monday November 24 2014, @01:48AM (#119278) Journal
                  I made do with 1gb RAM. IIRC it should still let you suspend to swap space less than your physical ram as long as your current free ram is greater than the difference between the two, but I never tried it and could be wrong.

                  Other than that all I can say is you are pushing hard to do more than the hardware is really equipped to do. That's not always a bad thing, but I dont think the OS should be radically redesigned just for that use case. If you want it to work well, I'd heartily recommend the 2/2 partition though, because suspend to disk is really THE killer OS feature on that machine for me. It's very quick to suspend and to restart, and the battery loves it.
                  --
                  If laughter is the best medicine, who are the best doctors?
              • (Score: 0) by Anonymous Coward on Monday November 24 2014, @03:36AM

                by Anonymous Coward on Monday November 24 2014, @03:36AM (#119303)

                So you can see that adding storage requirements isn't always good? Especially when it is tied to RAM size. What if you have a device with a lot of RAM and little/no writable storage. What if the RAM is cheap and adding extra storage devices would screw up cost scaling. What if it is an embedded device that by design starts and stops and is not connected to power in between? Why would it be better to have a crippled system that is actually worse at the normal case, and precludes some use cases entirely, just so the programmers don't have to understand basic things like ordered requirements trees and concurrency? Your excuse that it doesn't normally hurt is weak, because a full-featured system doesn't normally hurt, either.

                We've got users on this site who don't even do anything that interacts with the init system except run a config tool that turns software on/off, and yet they've been convinced that they're being oppressed by a bloated init.

                It is perfectly reasonable to want to choose a slow init system for subjective reasons. It doesn't mean others are somehow wrong for wanting a full-featured one, however. It is just different choices.

                I edit config files with vim, and source files with emacs. The benefits in each scenario are entirely subjective.

                • (Score: 2) by cafebabe on Tuesday November 25 2014, @01:43AM

                  by cafebabe (894) on Tuesday November 25 2014, @01:43AM (#119637) Journal

                  It is perfectly reasonable to want to choose a slow init system for subjective reasons.

                  Some people want a sequential init system for reliability and security. These are objective reasons.

                  I edit config files with vim, and source files with emacs.

                  Heretic!

                  --
                  1702845791×2
          • (Score: 0) by Anonymous Coward on Monday November 24 2014, @09:12AM

            by Anonymous Coward on Monday November 24 2014, @09:12AM (#119358)

            Suspend to disk used to work for me - but then I installed latest version of linux mint and now it doesn't. And I can't mount cifs anymore. And I get mysterious crashes on the graphics driver. :/

      • (Score: 2) by Anonymous Coward on Sunday November 23 2014, @04:47AM

        by Anonymous Coward on Sunday November 23 2014, @04:47AM (#119037)

        I regularly shut my system down, when I go to bed, because the computer drains power while doing nothing. I'm not very well paid, and even if I was I'd still shut down at night. The extra couple of dollars I save every month can go on my mortgages, or student loan.

        The power company CEO gets paid more than enough as it is.

      • (Score: 0) by Anonymous Coward on Sunday November 23 2014, @05:43AM

        by Anonymous Coward on Sunday November 23 2014, @05:43AM (#119042)

        "I am honestly mystified by your sentiment. How often do you reboot? Why?"

        - You are running a virtual server that, for whatever reason, gets Slashdotted all of a sudden. The hypervisor's monitoring program sees 100% capacity for a few moments and decides to clone the server on a cluster somewhere else, and then load balance the demand. Of course you want this new server to stand up as quickly as possible.

        - As part of your company's reciprocal goodwill, you are forced to run services in a shithole country to keep the locals gainfully employed. The infrastructure sucks, and brownouts are common. The power goes out, and your UPS gives you about 5 minutes of power because of the extremely high power drain. Two things happen: 1) Your server is being stood quickly up on another physical cluster elsewhere, and 2) when power is finally restored, local services need to be restored as fast as possible.

        Maybe not the best scenarios, but these are just off the top of my head.

        Desktop Linux has no money. RedHat figured that out years ago and became the first billion dollar open-source company. Linux has two $$$ generating applications: the enterprise (almost all of your Windows AD servers have been hosted virtually on a Linux cluster for the past half-decade or so), and Android. SystemD is being written to address the former, and parallel loading of services can ultimately save millions of dollars when shit hits the fan. Android, on the other hand, is busy re-learning the lessons from the Windows 3.1 days. As a desktop user, you are somewhere in the middle, but the fact that you have no money means that you don't get a say in its direction. If arguing over init scripts is really important to you, go to OpenBSD where you will actually be heard.

      • (Score: 2) by epitaxial on Sunday November 23 2014, @05:56AM

        by epitaxial (3165) on Sunday November 23 2014, @05:56AM (#119043)

        I usually power down every night unless something is downloading or the computer is being used. My aging ABIT motherboard has gone flaky and sleep mode only wakes up about 2/3 of the time.

        The argument about servers rebooting faster is made by people who have never touched one. Some take a few minutes to even get past the POST. Does shaving 10 seconds off that really matter?

        • (Score: 2) by Arik on Sunday November 23 2014, @02:23PM

          by Arik (4543) on Sunday November 23 2014, @02:23PM (#119106) Journal
          "I usually power down every night unless something is downloading or the computer is being used. My aging ABIT motherboard has gone flaky and sleep mode only wakes up about 2/3 of the time."

          Suspend to disk.
          --
          If laughter is the best medicine, who are the best doctors?
        • (Score: 2) by Hairyfeet on Sunday November 23 2014, @11:10PM

          by Hairyfeet (75) <{bassbeast1968} {at} {gmail.com}> on Sunday November 23 2014, @11:10PM (#119233) Journal

          Go talk to your local mom & pop computer shop, we usually have tons of older boards that work well (we're all packrats in this biz and hate throwing working gear away) and most of us will sell you one pretty cheap, especially if you bullshit with us awhile as its nice to be able to talk to someone that knows the lingo instead of the clueless consumers we get all day. Had a guy a couple weeks back come in needing a replacement board because his was getting flaky, after BSing awhile I sold him a C2D board with a 1.86Ghz C2D for $25 since his had the Celery. I bet if you go to your local shop they'll have plenty of boards in the back that will take your hardware and who knows, you may end up with something better than what you had before.

          As far as rebooting? Really depends on the use case i suppose. I have some in the field that are slower than Xmas when it comes to booting but that is a side effect of being in a harsh environment where lower heat and lack of fans is more important that speed. Warehouses, construction trailers, these places get seriously nasty and I've found its better to use 5400 RPM drives and slower CPUs with passive heatsinks than to risk it overheating because the grime has blocked up the cooling. You can tell 'em all day long to clean the things but they'll always forget so I can see some situations where shaving some time off boot would be of the good, especially when the physical hardware is slow.

          --
          ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
          • (Score: 2) by cafebabe on Tuesday November 25 2014, @01:58AM

            by cafebabe (894) on Tuesday November 25 2014, @01:58AM (#119642) Journal

            Go talk to your local mom & pop computer shop, we usually have tons of older boards that work well (we're all packrats in this biz and hate throwing working gear away) and most of us will sell you one pretty cheap

            A friend wanted to experiment with clustering about 14 years ago. We went to a local computer shop and asked for the four slowest computers in the shop. What graphics did we want? None. What sound did we want? None. At this point, the shop owner was gleeful to sell four identical desktops stored out the back of the shop.

            I've also had shop assistants jostling to sell me the smallest memory sticks in the shop.

            When someone asks for the lowest specification, there's a fleeting opportunity to make a good margin on stuff which may have been hanging around for years.

            --
            1702845791×2
            • (Score: 2) by Hairyfeet on Tuesday November 25 2014, @04:44AM

              by Hairyfeet (75) <{bassbeast1968} {at} {gmail.com}> on Tuesday November 25 2014, @04:44AM (#119692) Journal

              You will find assholes in every field, luckily there are plenty of shops to go around so if one is filled with assholes go to the next.

              --
              ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
    • (Score: 2) by LoRdTAW on Sunday November 23 2014, @07:11AM

      by LoRdTAW (3755) on Sunday November 23 2014, @07:11AM (#119048) Journal

      I don't think people are scared of it. I just think that is is very clumsy to implement so people just avoid it altogether. But I only think of threading as a problem when using C/C++ as there is a lot of code to be added to create, manage and terminate threads. If you want to know difficulty, just try writing a simple fork() program that uses IPC to move a variable from one process to the other. That is enough to send anyone running. pthreads are a bit easier and they share the same global memory space. But they are still a pain to implement.

      But hopefully that will change with the new generation of programming languages that feature concurrency (even though Ada has had it for god knows how long.) I have been playing with Rust and man, that language is kicking some serious ass.

      • (Score: 2) by hendrikboom on Sunday November 23 2014, @08:02PM

        by hendrikboom (1125) Subscriber Badge on Sunday November 23 2014, @08:02PM (#119187) Homepage Journal

        As far as I know, you don't need systemd to have a parallel init. For some time not, the scripts in init.d have prerequisites listed at the start so that the init system can read them and act accordingly. Or wait a minute, did that start with systemd?

        In any case the information on what needs to be started before what is there, and you may as well use it and start independent things in parallel.,

        -- hendrik

        • (Score: 1) by rleigh on Monday November 24 2014, @10:49AM

          by rleigh (4887) on Monday November 24 2014, @10:49AM (#119374) Homepage

          This is correct, we did have parallel boot with sysvinit for years before systemd. SuSE developed insserv and startpar which were later adopted by Debian and formalised in the LSB. insserv reads the dependency information from the init script headers and computes a dependency graph to start and stop scripts in parallel in the correct order (similar to make). At boot startpar can read the graph and start up services in parallel.

          This isn't quite as clever as systemd units, but it works well. And if you can to debug it, the graph is saved in /etc/init.d/.depend.* so you can read them, and insserv itself can do various diagnostics as well. When originally converting to dependency-based boot this was run on all init scripts distribution-wide to make sure a complete graph of everything was correct.

          Regards,
          Roger

  • (Score: 2) by crutchy on Sunday November 23 2014, @07:38AM

    by crutchy (179) on Sunday November 23 2014, @07:38AM (#119051) Homepage Journal

    listen to users, but above all enjoy what you do.

    only suggestion i would add that might make thing easier for yourself is maybe some automated regression testing. doesn't need to be big and fancy, or even complete.

    i find that some simple tests can take some of the stress of making changes, and when you run them and you get a nice "all tests passed!" message it's very uplifting.

  • (Score: 2, Insightful) by jmorris on Sunday November 23 2014, @08:26AM

    by jmorris (4844) on Sunday November 23 2014, @08:26AM (#119054)

    Most people agree innovation in the init process is worth putting some effort into. Just remember you are working on the init to a UNIX like system and you have a good chance of creating something people want.

    Don't try to reimplement svchost and eventlogger. Don't try to create an entire new OS in userspace. If you find yourself wanting to build in a vast virtualization/sandboxing/access management subsystem, stop because systemd already exists. And avoid adding a systemwide IPC mechanism, replacing most of gnu-utils, networking, etc.

    Mixed on the no parallel start. I know admins fear it because it will almost always end up slightly non-deterministic but on the other hand there is a fair amount of performance gain to reap for everyone else. Probably best to add it but keep a clearly documented and assured to be well supported option to disable it. If there is any hope of stopping the juggernaut a common front with as many dissidents as possible is needed, splitting between an alternate for servers and another for desktops/laptops/embedded is therefore a bad idea.

  • (Score: 1) by ThG on Sunday November 23 2014, @10:29AM

    by ThG (4568) on Sunday November 23 2014, @10:29AM (#119066)

    so we can fire up that coffee (or tea, it's been updated this year!) maker during the boot process!

    Obligatory RFC:http://tools.ietf.org/html/rfc7168/

    Wait, this isn't a systemd feature request submission and you explicitly mention no networking? Damn, you're too sane for this world.. I'll write Lennart a mail, then.

  • (Score: 1, Insightful) by Anonymous Coward on Sunday November 23 2014, @02:23PM

    by Anonymous Coward on Sunday November 23 2014, @02:23PM (#119105)

    The common problem I have with systemd is that when I mess something up, there is nothing to do to fix it. It just hangs forever waiting for the service to magically start working. It the old system, it logged a failure and tried to continue. Thus when an nfs share in the fstab doesn't mount, it still boots. With systemd, because sshd requires that fstab be done, it never loads sshd. Can't get in to fix it. Nope, you're done.

    • (Score: 2) by urza9814 on Tuesday November 25 2014, @06:21PM

      by urza9814 (3954) on Tuesday November 25 2014, @06:21PM (#119875) Journal

      Hah, that reminds me of a minor gripe of my own with Systemd....the way it ends up handling encrypted disks *sucks so hard*. Took me a few boots to realize it was actually sitting there waiting for my password and hadn't just hung -- because it never displayed a password prompt! Or more accurately: it did, for about half a second, before it was overwritten by a message from a different process. I've got ten line shell scripts that handle I/O with parallel processes better than that!

      No readable logs, no prompt or error message printed, it just sits there and hangs and you've gotta *guess* why...

  • (Score: 1) by rleigh on Sunday November 23 2014, @03:01PM

    by rleigh (4887) on Sunday November 23 2014, @03:01PM (#119116) Homepage

    If you haven't already taken a look, I'd certainly highly recommend taking a look at s6 http://skarnet.org/software/s6/ [skarnet.org] for inspiration. This takes "do one thing, and do it well" to its conclusion and the result is about as small and robust as you can get for the basic init functionality. The concepts used in s6 are good, and could be reused in other init systems.

  • (Score: 2) by Pav on Monday November 24 2014, @02:53AM

    by Pav (114) on Monday November 24 2014, @02:53AM (#119290)

    I honestly don't think ANYONE knows what makes a good forward-looking init system should look like. That's not to say the information isn't out there, but noone has collected it. Developers seem to have just solved the parts of the problem they understand and are motivated by. Perhaps one day someone will do the hard yards and query all the different init developer subcultures from Linux, BSD et. al. (openrc, upstart, daemontools, launchd etc...), sysadmin communities, developer communities, users etc... and actually join the dots somehow to develop a wholeistic understanding of the problem space. Perhaps one solution really is required everywhere, or multiple solutions for irreconcilable goals. Perhaps no good idea will come, and new thinking will need to happen from a position of better understanding. Perhaps it would be down existing solutions understanding their shortcomings better, then competing some more. I can't help feeling that a compilation of current knowledge would see elegant and simple connections of ideas fall out. IMHO noone right now knows what a good init system should look like.

    • (Score: 2) by cafebabe on Tuesday November 25 2014, @02:17AM

      by cafebabe (894) on Tuesday November 25 2014, @02:17AM (#119648) Journal

      At a guess, a good init system should be like a make system. This is especially true when parallelism is considered. One of the modern requirements is multiple chroot jails or even nested chroot jails. This could be implemented easily with a make system.

      --
      1702845791×2