Slashdot Mirror


Ask Slashdot: Should We Worry Microsoft Will 'Embrace, Extend, and Extinguish' Linux? (betanews.com)

BrianFagioli writes: While there is no proof that anything nefarious is afoot, it does feel like maybe the Windows-maker is hijacking the Linux movement a bit by serving distros in its store. I hope there is no "embrace, extend, and extinguish" shenanigans going on.

Just yesterday, we reported that Kali Linux was in the Microsoft Store for Windows 10. That was big news, but it was not particularly significant in the grand scheme, as Kali is not very well known. Today, there is some undeniably huge news -- Debian is joining SUSE, Ubuntu, and Kali in the Microsoft Store. Should the Linux community be worried?

My concern lately is that Microsoft could eventually try to make the concept of running a Linux distro natively a thing of the past. Whether or not that is the company's intention is unknown. The Windows maker gives no reason to suspect evil plans, other than past negative comments about Linux and open source. For instance, former Microsoft CEO Steve Ballmer once called Linux "cancer" -- seriously.

3 of 431 comments (clear)

  1. No, absolutely not by jawtheshark · · Score: 3, Informative
    Linux will do just fine destroying itself without any help from Microsoft. I know Ubuntu is not Linux, but I just made the mistake of trying the 18.04LTS developers release (we're like one month of release, so it should give a reasonable idea of what to expect). That interface is complete and utter garbage. I have no idea why anyone would even want to use that. Holy, eff... I mean, I can't even graphically ask for the current IP address. It's a phone interface, at best. I never used Gnome-Shell before, but damned, is that a pile of pure shite. Pretty shit, but shit nevertheless.

    On the server side, we have systemd happily destroying the usability of server management with binary logs, opaque configuration and horrible documentation.

    No, no worries: Microsoft can happily do whatever it wants. With the state of Linux, it will get no where.

    ... and, yes, I am a full time Linux user and have been so for about 10 years. (Before that I dual booted and occasionally had stretches of full Linux usage.) I hoped going FreeBSD, but with politics is polluting FreeBSD that sounds like a no-go.

    If this continues, I just give up and go back to Windows, as horrible as I think Windows 10 is.

    --
    Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
  2. No you shouldn't: (GNU/)Linux is not centralised. by Anonymous Coward · · Score: 2, Informative

    Had "Linux" being one product, developed by one "ent" (be it person or company), then the embrace/extend/extinguish approach could have been a valid concern. The thing is, they are mostly community driven. Linus (and others) would happily tell Microsoft to f*ck off and keep developing. And so will people from GTK/Gt ecosystems.

    Microsoft could well end up with its own distribution (Intel has one), but I very much doubt something like Debian, or Arch could be "embraced" and extinguished by a 3rd party. And if they do, there are other distros.

  3. Performance by DrYak · · Score: 4, Informative

    The major performance issues that remain are with I/O.

    Because even if there's no translation happenning, you're still bound to the sucky NT Kernel filesystem drivers.

    Otherwise it's actually pretty good, in some cases equal to or even slightly better than bare-metal Ubuntu performance.

    Keep in mind that this has mostly to do with the way multi-processing is handled :
    - Windows suck at multiple processes, because creating a new context ( fork() ) is a horribly inefficient process. (Whereas on Linux, it's almost a free action thanks to CoW facilities in the virtual-memory subsystem).
    - As such when running a unix software using a software translation layer (like Cygwin), multi processing will suck.
    - That's why multi-threading is popular in Windows world : there's no context separation, everything is done in the came context.

    - The NT kernel introduced a new concept called pico-thread which are much more light-weight than regular Windows process to setup. These aren't available in Windows, but gives a way to the NT kernel to provide extremely light-weight multi-processing to Linux ELFs.
    - Multi-processing works decently well on WSL (unlike Windows native apps, or Unix apps via Cygwin).

    - But if you read the technical blogs at microsoft, you'll release that the managed to achieve pico-threads by throwing away some of the context isolation of actual multiple process.
    (There's a reason while picothreads aren't available for production Windows software)

    - So basically in purely multiprocessing/multithreading benchmarks (e.g.: thinks running on OpenMP) WSL can even slightly beat actual real linux, because Microsoft threw a lot of safety and security out of the window. (It's great for testing software, but do not ever contemplate using WSL in production. It's only to test software before deploying on real Linux).
    - When benchmarks are mostly CPU oriented (e.g.: most of the media compression tests) - most of the CPU cycles are spent running the instruction to process the data, and they are the same no matter what OS they run on (i.e.: a cygwin compiled software would run just as fast, provided it was compiled with a similar version of GCC the optimize code the same way).
      - Whenever a benchmark hits any other part of the NT kernel (example: file IO) the performance just completely collapses. It doesn't matter that there's no translation going on and that the NT kernel is directly service IO request it self, when that IO code just plain sucks. A deep overhaul of the NTFS code would be the only hope for WSL to suck a tiny bit less.

    (3D API in theory could be an area where performance degradation won't be as significant : some manufacturer like Intel produce better Windows drivers than Linux, and other like Nvidia re-use basically the same drivers.
    But OpenGL is among the long list of Linux APIs that WSL is not supporting in its (very limited) subset).

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]