Slash Boxes

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
posted by martyb on Wednesday September 18 2019, @02:51PM   Printer-friendly
from the you're-crazy dept.

Arthur T Knackerbracket has found the following story:

With Microsoft embracing Linux ever more tightly, might it do the heretofore unthinkable and dump the NT kernel in favor of the Linux kernel? No, I’m not ready for the funny farm. As it prepares Windows 11, Microsoft has been laying the groundwork for such a radical release.

I’ve long toyed with the idea that Microsoft could release a desktop Linux. Now I’ve started taking that idea more seriously — with a twist. Microsoft could replace Windows’ innards, the NT kernel, with a Linux kernel.

It would still look like Windows. For most users, it would still work like Windows. But the engine running it all would be Linux.

Why would Microsoft do this? Well, have you been paying attention to Windows lately? It has been one foul-up after another. Just in the last few months there was the registry backup fail and numerous and regular machine-hobbling Windows updates. In fact, updates have grown so sloppy you have to seriously wonder whether it’s safer to stay open to attacks or “upgrade” your system with a dodgy patch.

Remember when letting your Windows system get automatic patches every month was nothing to worry about? I do. Good times.

Why is this happening? The root cause of all these problems is that, for Microsoft, Windows desktop software is now a back-burner product. It wants your company to move you to Windows Virtual Desktop and replace your existing PC-based software, like Office 2019, with software-as-a-service (SaaS) programs like Office 365. It’s obvious, right? Nobody in Redmond cares anymore, so quality assurance for Windows the desktop is being flushed down the toilet.

Many of the problems afflicting Windows do not reside in the operating system’s upper levels. Instead, their roots are deep down in the NT kernel. What, then, if we could replace that rotten kernel with a fresh, healthy kernel? Maybe one that is being kept up to date by a worldwide group of passionate developers. Yes, my bias is showing, but that’s Linux, and it’s a solution that makes a lot of sense.

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: 4, Insightful) by Runaway1956 on Wednesday September 18 2019, @03:44PM (6 children)

    by Runaway1956 (2926) Subscriber Badge on Wednesday September 18 2019, @03:44PM (#895695) Journal

    Linus ultimately maintains and controls the kernel. Or, he did until some snowflakes whined and cried about his abusive language. Linus could have just said, "No.". At which point, Puttering could have forked the kernel, and put his system thingy into his own version of the kernel. Yep, you're free to do almost anything you want with the kernel, but you can't force Linus to adopt your stuff.

    Starting Score:    1  point
    Moderation   +2  
       Insightful=2, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 4, Insightful) by meustrus on Wednesday September 18 2019, @04:53PM (4 children)

    by meustrus (4961) on Wednesday September 18 2019, @04:53PM (#895725)

    That's true, anything that needs to be in the kernel could have been rejected and forced onto a fork. Forking Linux would sure be an interesting mess, but not unheard of in FOSS. So why weren't the changes rejected?

    I was going to make a point about corporate consensus and astroturfing, ultimately comparing Red Hat to bigoted review bombing campaigns. But I actually don't know. Honestly I'm still amazed at how much people care about SystemD, and I'm not sure if my disinterest is due to what kind of software I deal with (not system-level or embedded) or because I was never particularly fond of init anyway. Practically speaking, how is the explicit SystemD circle of dependencies any different from the de facto ecosystem around init?

    If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
    • (Score: 0, Disagree) by Anonymous Coward on Thursday September 19 2019, @02:47AM (3 children)

      by Anonymous Coward on Thursday September 19 2019, @02:47AM (#895969)

      That circle of dependencies is why it is hated. The Unix philosophy was to have small programs do one thing well, wih defined interfaces, and chain them together to do big things well. You could modify, extend, or limit any component and as long as you didn't break the interface it would still work. It was easier for programmers to understand and improve small programs in their free time (the Bazaar). Where possible (and it was almost always possible) configuration and log files should be human readable text. There was a clear separation between system and user components.

      systemD explicitly and deliberately broke as much of that as it could. It crosses boundaries demanding user-space programs depend on it being there. If one component is imported for a specific user program, the circle of dependencies eventually pull in the whole systemD. Once a program has been assimilated to run on systemD it takes significant extra work to also make run if systemD is not there. The ultimate design goal was to remove the ability to modify components from the masses and return control to the priesthood who could afford to work full-time on understanding the byzantine Cathedral.

      • (Score: 2) by meustrus on Thursday September 19 2019, @09:05PM (2 children)

        by meustrus (4961) on Thursday September 19 2019, @09:05PM (#896257)

        So it's annoying for free software developers, not necessary linux users as a whole? That makes sense. Except, well, I write plenty of software that runs on Linux and have never had any reason to import systemD. Not because I was using an alternative toolchain, but because I was not concerned with integrating with the operating system.

        Is it a C thing? Because the JVM and the NodeJS interpreter, which are ultimately where my code ends up being executed, seem to do everything they need to just fine without touching the OS. But then, my code also tends to be the kind of thing you can stick in a Docker image and not worry about keeping it stable.

        Operating systems are about abstractions. I'm happy to have sockets completely abstracted away from me, because due to the difficulties in making new protocols work with existing infrastructure, everything is an HTTP API anyway. Now, if we could be trusted to open up port 96, or 401, or whatever else in that unused but universally protected port space that firewalls tend to block, maybe us newbies would learn the OSI model and build new protocols instead of rebuilding everything from abstractions over HTTP. But that's besides the point.

        The point is that something like daemon scheduling is like socket handling. I'd be happy to have it completely abstracted away from me. I've seen what it takes to appropriately handle all of the failure conditions for Windows services, at least, and I don't think I could ever trust myself to remember all the byzantine rules that result from the pattern of IO errors possible from a particular kernel design.

        It sounds like systemD kind of sucks as a library. Why not push back? Rewrite parts of it to make it more modular and fall in line with the Unix philosophy? If that's not possible, maybe the problem is really that no one part of the dependency circle does at least one complete thing at all.

        From what I've seen, though, most Linux software ends up with most of its functionality split into a "lib~~" package. Is it so bad if the supported frontend to that lib uses systemD? You can always make a different frontend. It's quite likely that people that prefer the features in systemD would also like to avoid having two similar systems running side by side.

        Of course, I could still be completely misunderstanding things. I also fully expect someone to tell me to Get Off Their Lawn for admitting that none of my code touches bare metal.

        If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
        • (Score: 0) by Anonymous Coward on Friday September 20 2019, @04:37AM

          by Anonymous Coward on Friday September 20 2019, @04:37AM (#896392)

          Yeah, you're programming on a different level. If you want to interact with hardware or the OS then systemD can be a pain.
          I can see why some people hate it and why others are all "WTF is the problem, it works well."

          I expect the poettering group to strongly resist any code pulls that attempt to make components more separable or individually replacable. The whole thing is deliberately tied into a ball of string.

        • (Score: 0) by Anonymous Coward on Friday September 20 2019, @11:11AM

          by Anonymous Coward on Friday September 20 2019, @11:11AM (#896454)

          There are plenty of alternative init systems and service managers, people gripe because most of the major distros unilaterally switched to systemd. It's not hard to live with or without systemd as a home user, but where is a non-systemd distro with enterprise-class technical support?

  • (Score: 1, Insightful) by Anonymous Coward on Wednesday September 18 2019, @06:56PM

    by Anonymous Coward on Wednesday September 18 2019, @06:56PM (#895776)

    But how would that prevent systemd? Other than the kernel containing some sort of magic that prevents that process from running, you can put whatever on top of the kernel you want. In fact, Linus has repeatedly pushed back against systemd's fingers in the kernel, with the most obvious example being the repeated rejection of kdbus.