Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
posted by martyb on Tuesday March 22 2016, @08:09AM   Printer-friendly
from the we're-gonna-create-our-own-mistakez! dept.

There's a new operating system that wants to do away with the old mistakes and cruft in other operating systems. It's called Redox OS and is available on GitHub. It's aimed at creating an alternative OS that is able to run almost all Linux executables with only minimal modifications. It features a pure ecosystem using the Rust programming language which they hope will improve correctness and security over other OSes. They are not afraid to prioritize correctness over compatibility. The philosophy being that "Redox isn't afraid of dropping the bad parts of POSIX while preserving modest Linux API compatibility."

Redox levels harsh criticisms at other OSes, saying "...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on. We all make mistakes, that's no secret, but there is no reason to repeat others' mistakes." Not stopping there, the Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.

Redox OS seems to be supported on the i386 and x86_64 platforms. The aims are microkernel design, implementation in Rust language, optional GUI — Orbital, newlib for C programs, MIT license, drivers in userspace, common Unix commands included, and plans for ZFS.

They want to do away with syscalls that stay around forever and drivers for hardware that, for a long time, simply isn't possible to buy any more. They also provide a codebase that doesn't require you to navigate around 25 million lines of code like Linux.

Perhaps the mathematically proven L4 microkernel is something to consider over the monolithic kernel approach where any single driver can wreck the system? One aspect to look out for is if they map the graphic cards into user space.


Original Submission

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: 5, Insightful) by Anonymous Coward on Tuesday March 22 2016, @08:37AM

    by Anonymous Coward on Tuesday March 22 2016, @08:37AM (#321471)

    > ...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on.

    As if anyone ever set out to replicate the mistakes of the past.
    They sound like they are about 15 years old and know everything.

    • (Score: 1, Insightful) by Anonymous Coward on Tuesday March 22 2016, @10:52AM

      by Anonymous Coward on Tuesday March 22 2016, @10:52AM (#321526)

      My thoughts exactly. Already I don't want to associate myself with a project that has a community with that sort of attitude.

      By doing so, they are making mistakes the other operating systems developers did not.

    • (Score: 3, Touché) by RedBear on Tuesday March 22 2016, @11:32AM

      by RedBear (1734) Subscriber Badge on Tuesday March 22 2016, @11:32AM (#321537)

      > ...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on.
      As if anyone ever set out to replicate the mistakes of the past.
      They sound like they are about 15 years old and know everything.

      Heh. I can see the press release from about 25 years from now: "FyutrOS will not replicate the mistakes and bad choices made by Linux, Unix, BSD, HURD, Redox OS and so on..."

      --
      ¯\_ʕ◔.◔ʔ_/¯ LOL. I dunno. I'm just a bear.
      ... Peace out. Got bear stuff to do. 彡ʕ⌐■.■ʔ
    • (Score: -1, Redundant) by Anonymous Coward on Tuesday March 22 2016, @12:20PM

      by Anonymous Coward on Tuesday March 22 2016, @12:20PM (#321556)
      Its a painful choice when you have to choose between compatible and a better product.
      If you follow the standard you have external limits on quality. If you dont follow the standard you might be failing to learn the lessons of the past.

      They sound like they are about 15 years old and know everything.

      So do you.

    • (Score: 1, Redundant) by DannyB on Tuesday March 22 2016, @02:08PM

      by DannyB (5839) on Tuesday March 22 2016, @02:08PM (#321609)

      Maybe they sound more adult than you think.

      They merely state, quite correctly, that there ARE design mistakes of the past. (And no past system, no matter how elegant, that I have ever seen since the 1970's is free of design mistakes that couldn't have been done better in hindsight.)

      They do not intend to repeat those mistakes. I read 'repeat' to mean 're-implement' those mistakes.

      While unstated, they probably will also invent some new design mistakes. Hopefully few. And hopefully not serious. Even better if they are easily corrected.

      • (Score: 1, Interesting) by Anonymous Coward on Tuesday March 22 2016, @05:04PM

        by Anonymous Coward on Tuesday March 22 2016, @05:04PM (#321722)

        Compatibility means deliberately repeating other people's mistakes.
        — David Wheeler

        [...] able to run almost all Linux executables [...]

      • (Score: 3, Insightful) by Nuke on Tuesday March 22 2016, @10:48PM

        by Nuke (3162) on Tuesday March 22 2016, @10:48PM (#321866)
        FTFA :_

        They want to do away with .... drivers for hardware that, for a long time, simply isn't possible to buy any more.

        There's a design mistake for a start.

        Just because some hardware cannot be bought any more does not mean that it is not still in widespread use. My IBM Model M keyboard with its PS/2 connector for example? No thanks, I'll pass on Redox.

    • (Score: 2) by darkfeline on Wednesday March 23 2016, @01:38AM

      by darkfeline (1030) on Wednesday March 23 2016, @01:38AM (#321917) Homepage

      They're replicating the mistakes of, e.g., Minix, for one.

      Either you can make something perfect, or you can ship a product. Choose one.

  • (Score: 5, Insightful) by multixrulz on Tuesday March 22 2016, @08:42AM

    by multixrulz (5608) on Tuesday March 22 2016, @08:42AM (#321474)

    ... they don't know the first thing. They're using a github SSL certificate on redox-os.org.

    But more to the point, get back to me when it's as functional as ReactOS.

    • (Score: 1) by Cornwallis on Tuesday March 22 2016, @09:20AM

      by Cornwallis (359) on Tuesday March 22 2016, @09:20AM (#321486)

      You beat me to it. Way to inspire trust right out the gate.

    • (Score: 2) by tangomargarine on Tuesday March 22 2016, @01:58PM

      by tangomargarine (667) on Tuesday March 22 2016, @01:58PM (#321599)

      Wow, a *red* untrusted connection page. I can't even remember the last time I've seen one of those.

      --
      "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
      • (Score: 2) by Nuke on Thursday March 24 2016, @11:29AM

        by Nuke (3162) on Thursday March 24 2016, @11:29AM (#322489)

        Wow, a *red* untrusted connection page [www.redox-os.org]

        Indeed. And they are complaining about "design mistakes"!

  • (Score: 2, Funny) by Anonymous Coward on Tuesday March 22 2016, @09:10AM

    by Anonymous Coward on Tuesday March 22 2016, @09:10AM (#321481)

    i see their first fuck up; using github

    they should be using bitbucket!

    grab pitchforks!

  • (Score: 3, Insightful) by ThePhilips on Tuesday March 22 2016, @09:11AM

    by ThePhilips (5677) on Tuesday March 22 2016, @09:11AM (#321483)

    Perhaps the mathematically proven L4 microkernel is something to consider over the monolithic kernel approach where any single driver can wreck the system?

    But this is just perspective of developers, who are ridiculous minority compared to users of the kernels.

    From perspective of users, it makes no sense to make more checks/etc during run-time, since the code doesn't change during run-time. After the systems has been tested, the checks/etc are pure and useless overhead. (Microkernel's isolation features are also sort of checks for invalid memory accesses.)

    Or as a direct example: Would you as a gamer play a game which never crashes at 25fps, or rather a game which might/might not crash once per week at 50fps? And that's pretty much sums up why the "better" microkernels never took off: it's not developers with their unsafe languages/etc, it is the users.

    One aspect to look out for is if they map the graphic cards into user space.

    As soon as you allow unfettered access to IO registers from user-space, all the security promises fly out of windows. And you can't have a driver in user-space without unfettered access to IO registers.

    • (Score: 3, Informative) by mth on Tuesday March 22 2016, @09:47AM

      by mth (2848) on Tuesday March 22 2016, @09:47AM (#321496) Homepage

      In modern Linux, graphics drivers have a large user space part that builds command buffers and a small kernel driver that verifies command buffers and sends them to the hardware. I think that's about as good as it's going to get with current PC hardware. If a system has an IOMMU, perhaps more could be moved to user space. I read something about AMD putting IOMMUs in their APUs, but I don't know if that's already present or something on their roadmap.

    • (Score: 3, Insightful) by VLM on Tuesday March 22 2016, @11:46AM

      by VLM (445) Subscriber Badge on Tuesday March 22 2016, @11:46AM (#321542)

      since the code doesn't change during run-time

      Um, that would be nice. Usually true, other than when someone is breaking in.

      • (Score: 2) by ThePhilips on Tuesday March 22 2016, @12:09PM

        by ThePhilips (5677) on Tuesday March 22 2016, @12:09PM (#321552)

        The NX bit [wikipedia.org] takes care of that for some time now. It allows to make the memory either writable or executable, but not both.

        But past all the HW and SW protection mechanisms come the logical errors. And the logical errors are independent of the language. If hacker can convince application to delete all data, or overwrite it with junk, no amount of abstract safety features would help.

        Otherwise, as a system developer, I do not mind - in fact, I welcome - such experiments. An advent of another system programming language beside C could only be a positive news. But I do not have much expectations toward the OS rewrite. If they were really serious about Rust as system language, as first step they should have tried integrate the support with BSD or Linux kernels, to allow writing drivers completely in Rust. But since they have started from the wrong end - rewrite of an OS - I really do not have any kind of hopes of them succeeding.

        • (Score: 2) by Pino P on Tuesday March 22 2016, @03:16PM

          by Pino P (4721) on Tuesday March 22 2016, @03:16PM (#321666) Journal

          The NX bit does not defend against return-oriented programming.

          • (Score: 0) by Anonymous Coward on Tuesday March 22 2016, @05:55PM

            by Anonymous Coward on Tuesday March 22 2016, @05:55PM (#321753)

            I haven't been keeping up lately and hadn't heard about that technique [wikipedia.org]. That's quite a fancy way to smash the stack!

    • (Score: 3, Informative) by TheRaven on Tuesday March 22 2016, @01:45PM

      by TheRaven (270) on Tuesday March 22 2016, @01:45PM (#321592) Journal

      Perhaps the mathematically proven L4 microkernel is something to consider over the monolithic kernel approach where any single driver can wreck the system?

      Whoever wrote this has no credibility. There is no mathematically proven L4 kernel. There is seL4, which is a formally verified microkernel that is inspired by L4 (but not an L4 implementation). It was a whole 8 hours between the public release of seL4 and the first security hole being identified, because it was something that wasn't part of their formal specification (which also makes a number of assumptions about the MMU behaviour that are not always true given known hardware bugs).

      The authors of seL4 put the cost at around 30 times that of developing with state-of-the-art informal software development methodology (i.e. detailed design, comprehensive test suites, and so on).

      As soon as you allow unfettered access to IO registers from user-space, all the security promises fly out of windows. And you can't have a driver in user-space without unfettered access to IO registers.

      What you say is true, assuming that you want to run on old hardware. If you are running on anything even vaguely modern, then as long as you correctly set up the IOMMU then this is not a problem. It's worth noting (to give a concrete example) that nVidia drivers have had direct access to I/O registers from userspace for several generations of hardware - all that the kernel part of the driver does is set up the initial mapping of the control registers and map and unmap memory segments. Nothing on the fast path for typical operation involves the kernel at all.

      --
      sudo mod me up
      • (Score: 2) by ThePhilips on Tuesday March 22 2016, @02:02PM

        by ThePhilips (5677) on Tuesday March 22 2016, @02:02PM (#321602)

        What you say is true, assuming that you want to run on old hardware.

        Any DMA-capable piece of hardware (today it is pretty much every piece of hardware) can be used to bypass completely any security mechanism, because it, duh, allows to access RAM directly without involvement of the CPU.

        I had already experience of (inadvertently) sending my stack over the network. And receiving the network packets into the stack.

        nVidia drivers have had direct access to I/O registers from userspace for several generations of hardware

        Not really. All "dangerous" commands are still has to be done via kernel part. They have access only to the IO-mmaped registers relevant to the graphical pipeline. User-space can fill the pipe-line of the GPU with data and commands, without calling the kernel, but flushing/syncing/etc (as well as configuration) is still done via kernel. IIRC, at least once per frame they have to call the kernel.

        • (Score: 5, Informative) by TheRaven on Tuesday March 22 2016, @02:22PM

          by TheRaven (270) on Tuesday March 22 2016, @02:22PM (#321620) Journal

          Any DMA-capable piece of hardware (today it is pretty much every piece of hardware) can be used to bypass completely any security mechanism, because it, duh, allows to access RAM directly without involvement of the CPU.

          No, it accesses RAM via the IOMMU (if one exists, which it does on all modern hardware - even without a full IOMMU [which does translation as well as protection], AMD CPUs have had a device exclusion vector for a decade, which allows the host CPU to restrict the physical pages that a device may access). The device can only access memory if there are valid mappings from the device virtual address space to the physical address space[1].

          The IOMMU does the same thing for the device that the CPU's MMU does for unprivileged code: it performs translation and permission checks on each virtual address and prevents unauthorised reads and writes.

          Note that many modern operating systems either misconfigure or don't bother to configure the IOMMU. Ubuntu is particularly fun, as it will advertise that the IOMMU is configured, even when it isn't.

          Not really. All "dangerous" commands are still has to be done via kernel part. They have access only to the IO-mmaped registers relevant to the graphical pipeline. User-space can fill the pipe-line of the GPU with data and commands, without calling the kernel, but flushing/syncing/etc (as well as configuration) is still done via kernel. IIRC, at least once per frame they have to call the kernel.

          This is simply not true (and please, go and read the driver code if you don't believe me - I'm speaking from first-hand experience here). Flushing the command buffer is done by writing to the producer (memory mapped device I/O) register from userspace. Userspace can poll for space in the ring buffer by reading another memory-mapped register.

          Graphics cards aren't the only devices to prefer this mode of operation. Infiniband devices have supported it forever and recent(ish) high-end NICs all support a kernel-bypass mode, where the device provides a virtual instance via SR-IOV that can all be mapped directly to userspace processes (or guest VMs). This is needed if you want to move the device driver entirely into the userspace process that's using it (increasingly common these days), but for a microkernel to grant direct access to a single driver process you just need an IOMMU. This isn't even a topic of research - several microkernels do this already.

          [1] Note that PCIe has some odd modes, such as permitting a device to indicate that it has a pre-translated physical address. This can be disabled, but the host OS must remember to do so.

          --
          sudo mod me up
          • (Score: 2) by ThePhilips on Tuesday March 22 2016, @02:42PM

            by ThePhilips (5677) on Tuesday March 22 2016, @02:42PM (#321636)

            The IOMMU does the same thing for the device that the CPU's MMU does for unprivileged code: it performs translation and permission checks on each virtual address and prevents unauthorised reads and writes.

            That's interesting.

            But "virtual address" you are talking about? The DMA works *always* on physical RAM. Or is it different kind of "virtual" memory?

            All the CPU memory protections I have seen work in concert with and rely on virtual memory. The "virtual memory address space" is process-specific - external hardware doesn't know anything about it.

            And how is this IOMMU is going to protect anything, when
            (1) the mapping virtual-to-physical is 1:1, while the same physical memory can have multiple virtual addresses (for different processes; consequently with different permissions) and
            (2) a very basic system can have rather huge number of virtual mappings, and no hardware ever is going to be as flexible as to allow unlimited number of the configuration entities (or it would have to go to the RAM for the configuration, and suffer the same performance penalty as the virtual memory machinery).

            In the Linux kernel, in the API for the DMA memory I've seen in the traces that it can potentially do something special for the memory, but so far I haven't worked with a single arch which implements there something (I worked only with PPC, ARM and Intel). Out of interest I have looked deeper, but only found handling for architectures which have limitations that not all memory is DAM-able. But nothing anywhere close to the protection against a malicious DMA access. (The same limitation was applicable to the older ISA hardware on Intel architectures, which could only access with DMA the first megabyte of the RAM.)

            • (Score: 3, Informative) by TheRaven on Tuesday March 22 2016, @05:00PM

              by TheRaven (270) on Tuesday March 22 2016, @05:00PM (#321719) Journal

              But "virtual address" you are talking about? The DMA works *always* on physical RAM

              No it doesn't. It only works on physical memory in the absence of an IOMMU. With an IOMMU, it works on a device virtual address.

              And how is this IOMMU is going to protect anything, when (1) the mapping virtual-to-physical is 1:1, while the same physical memory can have multiple virtual addresses (for different processes; consequently with different permissions) and

              Virtual to physical mapping isn't 1:1, it's N:1. That's how shared memory works - multiple virtual page corresponding to the same physical page.

              In the Linux kernel, in the API for the DMA memory I've seen in the traces that it can potentially do something special for the memory, but so far I haven't worked with a single arch which implements there something (I worked only with PPC, ARM and Intel).

              Most of the Linux APIs were introduced for PowerPC (contributed by IBM over a decade ago), so if you've worked on PowerPC then I'm quite surprised that you haven't come across them. They're used to prevent device driver errors affecting other parts of the system on IBM hardware. They're also used for device pass-through in virtualisation environments.

              Just looked for Intel/AMD IOMMU specs and they are all files under "Virtualization" and "I/O Virtualization"

              Of course they are, just as memory protection is under 'virtual memory'. What do you think virtualisation means?

              IOW, the tech is not intended to be used by the host - but rather to implement IO for the guest OS. In that case, the "virtual address" makes sense: it is the physical address of the guest OS, but the virtual memory address of the VM software.

              You're confusing marketing with functionality. You're also completely missing the common uses. Kernel bypass is most commonly used in graphics cards and high-end network cards, without a hypervisor (though hypervisors do use the same mechanisms for device pass through). As I said, nVidia cards for the last few generations have all supported kernel bypass. The kernel sets up memory maps, but all commands are submitted directly from userspace to the card without the kernel being involved. The kernel simply sets up mappings for memory that both the process and the device can access. High-end network cards work in the same way (Infiniband has worked like this for 20+ years), with the kernel setting up memory maps and the userspace drive initiating DMA to and from the rings that are in memory shared between the device and the userspace process.

              If you don't want to believe me, then go and read the driver code. Or read the reverse-engineered docs for the nVidia cards from the Nouveau project.

              --
              sudo mod me up
              • (Score: 2) by RamiK on Wednesday March 23 2016, @01:04AM

                by RamiK (1813) on Wednesday March 23 2016, @01:04AM (#321907)

                Most of the Linux APIs were introduced for PowerPC

                He might have worked on Macs or PowerQUICC. Not all PPCs were\are at feature parity. Especially when it comes to virtualization* which, similarly to ECC memory, was sometimes offered as a server "premium" feature.

                As for seL4, many production L4 family kernels fork off the proven seL4 code base and add patches to address hardware bugs. It's not a "security hole" to have a proven and correct core serve as a main branch that you occasionally fork production branches off and patch for hardware specific issues. It's simply a different development model.

                As for RedoxOS, while I personally believe it's a waste of time seriously developing anything new targeting the x86's metal, Rust still needs to prove itself by at least developing it's own toy research operating system. It's the price you pay for calling yourself a systems programming language. D is in the same boat. Go had the sense to avoid it.

                *virtualization is the modern term for general memory\device protections, like you said.

                --
                compiling...
          • (Score: 2) by ThePhilips on Tuesday March 22 2016, @02:47PM

            by ThePhilips (5677) on Tuesday March 22 2016, @02:47PM (#321639)

            Just looked for Intel/AMD IOMMU specs and they are all files under "Virtualization" and "I/O Virtualization". IOW, the tech is not intended to be used by the host - but rather to implement IO for the guest OS. In that case, the "virtual address" makes sense: it is the physical address of the guest OS, but the virtual memory address of the VM software.

  • (Score: 0) by Anonymous Coward on Tuesday March 22 2016, @10:10AM

    by Anonymous Coward on Tuesday March 22 2016, @10:10AM (#321505)

    do away with the old mistakes and cruft in other operating systems [...] able to run almost all Linux executables

    Good luck with that pipe dream.

    Not stopping there, the Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.

    More like it contains a placeholder for a blunt critique of Plan 9 and the GPL.

    Everything is a URL? [redox-os.org] What a joke.

    I'll stick with Urbit for all my meme operating system needs, thank you very much.

  • (Score: -1, Redundant) by Anonymous Coward on Tuesday March 22 2016, @12:11PM

    by Anonymous Coward on Tuesday March 22 2016, @12:11PM (#321554)

    We don't want another Win10 though.

  • (Score: 5, Insightful) by tangomargarine on Tuesday March 22 2016, @01:44PM

    by tangomargarine (667) on Tuesday March 22 2016, @01:44PM (#321591)

    There's a new operating system that wants to do away with the old mistakes and cruft in other operating systems.

    "Those who do not learn from UNIX are doomed to reimplement it, poorly."

    The philosophy being that "Redox isn't afraid of dropping the bad parts of POSIX while preserving modest Linux API compatibility."

    obligatory xkcd Standards [xkcd.com]

    In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on. We all make mistakes, that's no secret, but there is no reason to repeat others' mistakes." Not stopping there, the Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.

    "We know better than all these knuckleheads with their system that's actually been working for the last few decades."

    The aims are microkernel design, implementation in Rust language,

    Hey look, hipsters using Rust.

    drivers in userspace

    These guys have heard of HURD, right? Although I suppose that's kind of the platonic ideal of project failure and that doesn't necessarily mean these guys will, too.

    They also provide a codebase that doesn't require you to navigate around 25 million lines of code like Linux.

    Fast-forward 10 years. Hey, look! Now they're 25 million lines of code, too! Oops.

    I know I'm still a wet-behind-the-ears software dev, especially concerning OSes, but I still know enough not to throw everything out the window and think I can rewrite it all myself, better.

    Somebody needs to set up a cage match between these guys and Lennart Poettering :)

    --
    "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
  • (Score: 5, Insightful) by LoRdTAW on Tuesday March 22 2016, @01:53PM

    by LoRdTAW (3755) Subscriber Badge on Tuesday March 22 2016, @01:53PM (#321594) Journal

    You want to be taken seriously? Remove the endless bitching and critique. Most people interested in new OS designs are well aware of the existing crap designs (hint: they all suck save for Plan9/inferno). Their manifesto reads like the pipe dream of a bunch of know-it-all kids.

    This is more akin to a bunch of guys in a bar, drunk, and boasting of plans to climb mt. Everest. They all agree that they want to do it, but once they realize the scale of the journey, they abandon it. I don't exactly have high hopes. Writing a completely new OS takes an enormous amount of passion and drive.

    • (Score: 0) by Anonymous Coward on Tuesday March 22 2016, @04:57PM

      by Anonymous Coward on Tuesday March 22 2016, @04:57PM (#321716)

      (hint: they all suck)

      ftfy

      plan 9 is better than most operating systems, but like all software, it sucks

      also rob pike can't into user interfaces

      seriously rob what the hell are you doing, stop it

      • (Score: 2) by LoRdTAW on Tuesday March 22 2016, @05:23PM

        by LoRdTAW (3755) Subscriber Badge on Tuesday March 22 2016, @05:23PM (#321738) Journal

        plan 9 is better than most operating systems, but like all software, it sucks

        A cat-v reader I see. But in all seriousness, it does suck from a user standpoint as well. However, the underlying architecture is clean and lightweight while 9p and the VFS enable an amazing level of distribution of resources. It doesn't get better than that.

        also rob pike can't into user interfaces

        So you're saying he accidentally the user interface then.

  • (Score: 2) by Pino P on Tuesday March 22 2016, @03:18PM

    by Pino P (4721) on Tuesday March 22 2016, @03:18PM (#321669) Journal

    The certificate presented by the web server that handles https://www.redox-os.org/ [redox-os.org] works only for www.github.com, *.github.com, github.com, *.github.io, github.io, *.githubusercontent.com, and githubusercontent.com, not www.redox-os.org.

  • (Score: 2) by Subsentient on Tuesday March 22 2016, @07:49PM

    Looks like Hipster OS (tm).

    Let me guess, they'll implement the GUI in pure Javascript and take design ideas from systemd.
    Rust? Really? I mean, it's not a bad language as far as I can tell, but it's not particularly portable yet, at least not to the extent of C/C++.

    --
    Instead of getting bogged down in the infuriating details, focus on the unquestionably terrible big picture. -The Onion