Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday March 15 2020, @03:28AM   Printer-friendly
from the EEE? dept.

Microsoft's Windows Subsystem for Linux is coming to all Windows 10 users (archive):

You won't have to be a tester to try Windows 10's new, built-in Linux kernel in the near future. Microsoft has confirmed that Windows Subsystem for Linux 2 will be widely available when Windows 10 version 2004 arrives. You'll have to install it manually for a "few months" until an update adds automatic installs and updates, but that's a small price to pay if you want Linux and Windows to coexist in peace and harmony. It'll be easier to set up, at least -- the kernel will now be delivered through Windows Update instead of forcing you to install an entire Windows image.

Embrace, Extend... Excite!

Windows blog post.

Previously: Windows 10 Will Soon Ship with a Full, Open Source, GPLed Linux Kernel


Original Submission

Related Stories

Windows 10 Will Soon Ship with a Full, Open Source, GPLed Linux Kernel 73 comments

Has no one seen this yet? Don't cross the streams!

Ars Technica:

Earlier today, we wrote that Microsoft was going to add some big new features to the Windows Subsystem for Linux, including native support for Docker containers. It turns out that that ain't the half of it.

Not even half.

All is changing with Windows Subsystem for Linux 2. Instead of emulating the Linux kernel APIs on the NT kernel, WSL 2 is going to run a full Linux kernel in a lightweight virtual machine. This kernel will be trimmed down and tailored to this particular use case, with stripped-down hardware support (since it will defer to the host Windows OS for that) and faster booting.

The Linux kernel is GPLed open source; the GPL license requires that any modifications made to the code must be published and made available under the GPL license. Microsoft will duly comply with this, publishing the patches and modifications it makes to the kernel. WSL 2 will also use a similar split as the current WSL does: the kernel component will be shipped with Windows while "personalities" as provided by the various Linux distributions can be installed from the Microsoft Store.

To quote Han Solo, "I've got a bad feeling about this."


Original Submission

Open Source's Eric Raymond: Windows 10 Will Soon be Just an Emulation Layer on Linux Kernel 41 comments

Open source's Eric Raymond: Windows 10 will soon be just an emulation layer on Linux kernel

Will Windows lose the last phase of the desktop wars to Linux? Noted open-source advocate Eric Raymond thinks so.

Celebrated open-source software advocate and author Eric Raymond, who's long argued Linux will rule the desktop, reckons it won't be long before Windows 10 becomes an emulation layer over a Linux kernel.

[...] Looking further into the future, Raymond sees Microsoft killing off Windows emulation altogether after it reaches the point where everything under the Windows user interface has already moved to Linux.

"Third-party software providers stop shipping Windows binaries in favor of ELF binaries with a pure Linux API... and Linux finally wins the desktop wars, not by displacing Windows but by co-opting it. Perhaps this is always how it had to be," Raymond projects.

Is It Time for Windows and Linux to Converge?

Last phase of the desktop wars?

The two most intriguing developments in the recent evolution of the Microsoft Windows operating system are Windows System for Linux (WSL) and the porting of their Microsoft Edge browser to Ubuntu.

For those of you not keeping up, WSL allows unmodified Linux binaries to run under Windows 10. No emulation, no shim layer, they just load and go.

[...] Proton is the emulation layer that allows Windows games distributed on Steam to run over Linux. It's not perfect yet, but it's getting close. I myself use it to play World of Warships on the Great Beast.

The thing about games is that they are the most demanding possible stress test for a Windows emulation layer, much more so than business software. We may already be at the point where Proton-like technology is entirely good enough to run Windows business software over Linux. If not, we will be soon.

So, you're a Microsoft corporate strategist. What's the profit-maximizing path forward given all these factors?

It's this: Microsoft Windows becomes a Proton-like emulation layer over a Linux kernel, with the layer getting thinner over time as more of the support lands in the mainline kernel sources. The economic motive is that Microsoft sheds an ever-larger fraction of its development costs as less and less has to be done in-house.

If you think this is fantasy, think again. The best evidence that it's already the plan is that Microsoft has already ported Edge to run under Linux. There is only one way that makes any sense, and that is as a trial run for freeing the rest of the Windows utility suite from depending on any emulation layer.

So, the end state this all points at is: New Windows is mostly a Linux kernel, there's an old-Windows emulation over it, but Edge and the rest of the Windows user-land utilities don't use the emulation. The emulation layer is there for games and other legacy third-party software.

Also at The Register.

Previously: Windows 10 Will Soon Ship with a Full, Open Source, GPLed Linux Kernel
Call Me Crazy, but Windows 11 Could Run On Linux
Microsoft Windows Linux for Everybody


Original Submission #1Original Submission #2Original Submission #3

What is Microsoft Doing with Linux? Everything You Need to Know about its Plans for Open Source 30 comments

With an article that covers "From Cancer to Cloud" and beyond, Techrepublic asks: What is Microsoft Doing With Linux? Everything You Need to Know About its Plans for Open Source

'Microsoft and Linux' should be a phrase we're used to hearing by now. Microsoft is a member of not only the Linux Foundation but also the Linux kernel security mailing list... Microsoft is submitting patches to the Linux kernel... And when Microsoft wanted to add container support to Windows, it picked an open-source specification designed originally for [Linux].

Now Azure customers get the same hybrid benefits for Linux support contracts as they do for Windows Server licences; Windows runs Linux binaries; some key Microsoft applications are available on Linux; and new services might be built with Linux.

[...] At the recent Azure Open Day, Kubernetes co-founder and Microsoft corporate vice-president Brendan Burns talked about Microsoft having a deep understanding of Linux and contributing to existing open-source projects based on Linux as well as founding new ones like Dapr (Distributed Application Runtime).

[...] In short, Microsoft 'hearts' Linux.

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.
(1)
  • (Score: 0, Offtopic) by Anonymous Coward on Sunday March 15 2020, @03:49AM (9 children)

    by Anonymous Coward on Sunday March 15 2020, @03:49AM (#971474)

    To roll out a cloud Kubernetes cluster using Terraform and writing deployment scripts.

    WSL2 has been amazing so far compared to 1.

    I don't even regret having to upgrade to BETA windows to get it. (but will be going back ASAP)

    I know people will rag on it reflexively, but so far....

    • (Score: 5, Insightful) by The Mighty Buzzard on Sunday March 15 2020, @03:56AM (5 children)

      Well, probably. But most of us also know that we don't always get to pick which OS we're working on. Familiar, non-shitty tools at least make Windows slightly less painful to use. Now if they'd just get rid of the Windows parts, they'd have a pretty good OS.

      --
      My rights don't end where your fear begins.
      • (Score: 0, Flamebait) by Anonymous Coward on Sunday March 15 2020, @01:57PM (4 children)

        by Anonymous Coward on Sunday March 15 2020, @01:57PM (#971558)

        Linux has shitty parts too where Windows beats it.
        I shouldn't have to explain this, but this IS Soylent News...

        • (Score: 2) by maxwell demon on Sunday March 15 2020, @03:20PM (3 children)

          by maxwell demon (1608) Subscriber Badge on Sunday March 15 2020, @03:20PM (#971572) Journal

          Where exactly (other than support by hardware and software vendors, which isn't an OS issue but a market issue) does Windows beat Linux?

          --
          The Tao of math: The numbers you can count are not the real numbers.
          • (Score: 0) by Anonymous Coward on Sunday March 15 2020, @04:37PM (1 child)

            by Anonymous Coward on Sunday March 15 2020, @04:37PM (#971605)

            Not him, but the most commonly mentioned (legitimate) downside vs. Windows is lack of in-kernel API stability.
            There's perfectly good reasons [kernel.org] for this, to be sure, but that doesn't mean it's not a downside if you're unwilling or unable to get your driver in the kernel.

            • (Score: 4, Informative) by Anonymous Coward on Sunday March 15 2020, @05:09PM

              by Anonymous Coward on Sunday March 15 2020, @05:09PM (#971618)

              This is a feature, not a bug. If the driver for your hardware has a proper GPL2 driver that reached the quality threshold to be included in-tree with the Linux kernel, then, whenever a change is made to the kernel that impacts your driver, the folks making that change are responsible to fix your driver to work with the new interface. The original driver author need not be involved, at all.

              This works very well. Some shitty companies that are trying to bypass releasing the source for their drivers at all, let alone under a license that respects the freedom of the user, or folks like Microsoft who had to try several times to get their hyperV paravirtualized drivers accepted because the [lack of] code quality will complain.

          • (Score: 0) by Anonymous Coward on Sunday March 15 2020, @07:50PM

            by Anonymous Coward on Sunday March 15 2020, @07:50PM (#971665)

            The most obvious is probably the graphics stack and kernel/driver interfaces for graphics.

    • (Score: -1, Redundant) by Anonymous Coward on Sunday March 15 2020, @04:56PM

      by Anonymous Coward on Sunday March 15 2020, @04:56PM (#971612)

      Just love how some dickhead marked this off topic...

    • (Score: 2) by edIII on Monday March 16 2020, @01:57AM (1 child)

      by edIII (791) on Monday March 16 2020, @01:57AM (#971750)

      Well, of course we are going to rag on it. It sounds rather pointless to be using Microsoft in any capacity whatsoever. However, that extends to Apple too.

      Apple has its BSD, walled gardens, lack of privacy, lack of full ownership.

      Microsoft wants to have Linux, virtual walled gardens where the Win10/Linux is a glorified thin-client, lack of privacy, hardware lock-in so it comes with the equipment (MicrosoftProfitsSecuredBoot), and are trying to take way full ownership as we speak.

      So at this point in time, I wouldn't rag on Microsoft for the failures of its operating system, as much as I would rag on its future trajectory wrt consumer privacy, peaceful enjoyment of property, and ownership of hardware/software at the root of the security chain.

      I've absolutely no doubt what you're doing is pretty damn cool, and I'm sure Microsoft is coming a long way to supporting Linux devops on Microsoft devices. Maybe, if Microsoft weren't fucking forcing telemetry down my throat, Cortana in my household, and an all-or-nothing approach to Windows updates, and MicrosoftProfitsSecured hardware bullshit, I would still be using Microsoft.

      They were always a pretty damn nice interface. That's not enough anymore, and not enough to counter my loss of freedoms and ownership.

      --
      Technically, lunchtime is at any moment. It's just a wave function.
      • (Score: 1, Insightful) by Anonymous Coward on Monday March 16 2020, @03:44AM

        by Anonymous Coward on Monday March 16 2020, @03:44AM (#971781)

        I'm still too leery of "embrace, extend, extinguish".

        That company has made a reputation that is not easy for me to forget.

        It's good enough for business, where it's really not all that important if it works or it can be trusted, but it's not something I would choose as a long time partner.

        I see it more like a one night paid stand.

  • (Score: 4, Insightful) by The Mighty Buzzard on Sunday March 15 2020, @03:52AM (2 children)

    I don't blame them at all. They put all that money, time, and effort into powershell to make something that sucks complete ass compared to bash, much less bash with sed/awk/grep/perl. Why keep throwing good money after bad?

    --
    My rights don't end where your fear begins.
  • (Score: 5, Informative) by bzipitidoo on Sunday March 15 2020, @04:11AM (4 children)

    by bzipitidoo (4388) on Sunday March 15 2020, @04:11AM (#971482) Journal

    I learned of a new way that Windows sucks. Get a low end tablet that's so cheap, the manufacturer won't support it after 2 or just 1 year. No more driver downloads. They don't even offer the existing drivers for download. No drivers for it in Windows 10 either, so if Windows can be upgraded at all, it is a huge hassle. Bascially, you have to save the existing drivers to some offline storage. There's a Windows utility that can do this. Then upgrade Windows, and have it use the drivers you saved earlier. If you didn't know about that, and you wiped the storage, thus losing your copy of the existing drivers, you're S.O.L. until you can find a copy of the drivers online somewhere. Another item you have to deal with in this messy upgrade process is the damned license. Pretty easy for that to go missing when you get extreme and wipe disks, accounts, and so on.

    Windows Update of course cannot handle this situation. It will attempt to upgrade, fail to find working drivers, roll back, and repeat. It will also badger you about the extremely limited storage space, if the tablet is one of those that has only 30G of storage. There's a reason so many Windows tablets with such low storage are so cheap. It's because M$ allows manufacturers to license Windows for far less $ if the device has less than sonething like 32G storage.

    Oh, and the cheap bastards will have given you a 32bit version of Windows 10. Why not? Takes about 2G less space on that 30G of storage. Even though the hardware can do 64bit, you can't upgrade, because 32bit drivers do not work in 64bit Windows, and there aren't any 64bit drivers. Suck city.

    • (Score: 2) by takyon on Sunday March 15 2020, @04:27AM (1 child)

      by takyon (881) <{takyon} {at} {soylentnews.org}> on Sunday March 15 2020, @04:27AM (#971485) Journal

      AnandTech recently interviewed a cheapo Chinese brand:

      How Good (or Bad) is a $100 Laptop? The Coda Spirit Review [anandtech.com]

      Q: I noticed that the model I purchased came with Windows 10 Home version 1803, which is old. I could update to 1903 fine, but in order to successfully update to 1909, I had to install an M.2 SATA drive. I tried with a microSD card but during the update process the microSD controller is not initialized early enough in order to complete the update. Will future batches be sold with Windows 10 Home 1909 installed?

      A: You must have an early device; we update the Windows image with each batch produced. Devices that come preinstalled with 1903 have Reserved Storage enabled (updating to 1903 doesn’t enable this) from what I have seen Reserved Storage fixes all the issue that Windows 10 had when trying to update on low storage devices. Yes, future devices will have a more up to date Windows build.

      So if you have the right version, I guess you can use a microSD card to facilitate an update. Still pretty stupid and all of these Windows devices should come with 64 GB minimum. ChromeOS on the other hand can deal with 16 GB just fine.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 3, Informative) by RamiK on Sunday March 15 2020, @09:53AM

        by RamiK (1813) on Sunday March 15 2020, @09:53AM (#971523)

        So if you have the right version, I guess you can use a microSD card to facilitate an update.

        He probably can't. Many cheap Atoms have platform drivers that weren't packaged in Windows that supply the SD card driver so the upgrade boot environment can't reach the extra storage.

        In one particular Bay Trail device I couldn't even work the keyboard, touch screen, ethernet or bluetooth so I ended up doing the USB installation from the media creation tool on the one available USB port and a powered usb hub connected through a USB OTG on the power port chaining a keyboard, mouse, and a usb-ethernet adapter. I also weren't supplied drivers from the manufacturer and had to collect bits and pieces from similar lenovo, intel nuc and dell when the installation was done to get everything working...

        --
        compiling...
    • (Score: 3, Interesting) by JoeMerchant on Sunday March 15 2020, @12:42PM

      by JoeMerchant (3937) on Sunday March 15 2020, @12:42PM (#971545)

      I'm thinking of three levels of frustration:

      1) The iPad-One, beyond impractical to upgrade or continue working with the App Store - abandon all hope, your shiny is dead.

      2) The Windows ecosystem, sure - it updates... somehow, sometimes - your shiny isn't completely dead after 2 years, but the work required to limp it along does grow considerably with age.

      3) The *nix ecosystem, your shiny takes an excessive amount of care and labor to get working in the first place, plus a fairly steady stream of effort as it ages, but it ages more gracefully than the alternatives.

      --
      Україна досі не є частиною Росії. https://www.newsweek.com/russian-state-tv-ukraine-war-dirty-bomb-putin-1754428
    • (Score: 2) by DannyB on Monday March 16 2020, @02:59PM

      by DannyB (5839) Subscriber Badge on Monday March 16 2020, @02:59PM (#971893) Journal

      Okay, I get it. Old Windoze tablet . . . useless. Old Apple tablet . . . it would be heresy to say useless, so I won't say it.

      Old Android tablet . . .

      Just make sure it runs a version of Android that supports SDR apps, and use it for SDR. Use an OTG adapter and cheapo RTL receiver.

      --
      I get constant rejection even though the compiler is supposed to accept constants.
  • (Score: -1, Troll) by Anonymous Coward on Sunday March 15 2020, @04:40AM (2 children)

    by Anonymous Coward on Sunday March 15 2020, @04:40AM (#971489)

    And commie-pinko freaks. On second thought, I hate everything. Did I mention I hate Microsoft's new RagHead OS?

    • (Score: 1, Funny) by Anonymous Coward on Sunday March 15 2020, @05:50AM (1 child)

      by Anonymous Coward on Sunday March 15 2020, @05:50AM (#971502)

      Darling, I know it's coronavirus season but it sounds like you've been self-isolating too long.

      Go get some vitamin D.

      • (Score: 2) by DannyB on Monday March 16 2020, @03:00PM

        by DannyB (5839) Subscriber Badge on Monday March 16 2020, @03:00PM (#971895) Journal

        Gamers / Millennials . . . but Mooooooooooooom! I've already been self isolating in the basement for years!

        --
        I get constant rejection even though the compiler is supposed to accept constants.
  • (Score: 0) by Anonymous Coward on Sunday March 15 2020, @05:37AM

    by Anonymous Coward on Sunday March 15 2020, @05:37AM (#971500)

    Everyone knows windows is a deadend, but nobody steps up because windows market, the desktop market is shrinking.

    I personally think "desktop" market still have much potential, but I'm no Billy boy.

    It's interesting to see how MS would linger on. IBM, the fucking dino, somehow managed to remain a major tech player. Would MS pull the same?

  • (Score: 1, Insightful) by Anonymous Coward on Sunday March 15 2020, @07:49AM (7 children)

    by Anonymous Coward on Sunday March 15 2020, @07:49AM (#971513)

    I am totally confused by this. Linux don't need to ship with anything. You download a distro, put it on an optical disk or more often now a USB device, and boot. So what is this "shitting" with Windows? What is "Windows", anyway? I haven't used it for two and a half decades. Is it still functional? Amazing the CP/M could last this long, given the inherent flaws and security holes.

    • (Score: 2) by sgleysti on Sunday March 15 2020, @01:23PM

      by sgleysti (56) on Sunday March 15 2020, @01:23PM (#971550)

      So what is this "shitting" with Windows?

      A Freudian slip, by the look of things.

    • (Score: 5, Funny) by maxwell demon on Sunday March 15 2020, @03:38PM

      by maxwell demon (1608) Subscriber Badge on Sunday March 15 2020, @03:38PM (#971574) Journal

      What is "Windows", anyway?

      Just ask Linux:

      $ whatis Windows
      Windows: nothing appropriate.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 2) by fido_dogstoyevsky on Sunday March 15 2020, @11:02PM (1 child)

      by fido_dogstoyevsky (131) <{axehandle} {at} {gmail.com}> on Sunday March 15 2020, @11:02PM (#971699)

      ...What is "Windows", anyway?...

      Something found in walls. Just like Gates*. If you knock down the walls you don't need either**.
       
       
       

      *One down, one to go.
      **I wish I could claim this as mine, but I can't.

      --
      It's NOT a conspiracy... it's a plot.
      • (Score: 2) by DannyB on Monday March 16 2020, @03:08PM

        by DannyB (5839) Subscriber Badge on Monday March 16 2020, @03:08PM (#971898) Journal

        ...What is "Windows", anyway?...

        Something found in walls.

        The older the building, the less I want to look inside the walls. Ewwwww!

        --
        I get constant rejection even though the compiler is supposed to accept constants.
    • (Score: 0) by Anonymous Coward on Monday March 16 2020, @04:35AM (1 child)

      by Anonymous Coward on Monday March 16 2020, @04:35AM (#971790)

      Navel Operations?

      +

      Embrace, Extend... Excite!

      I'm cumming already.

      • (Score: 2) by DannyB on Monday March 16 2020, @03:10PM

        by DannyB (5839) Subscriber Badge on Monday March 16 2020, @03:10PM (#971900) Journal

        All the creepiness of your friend who works at the funeral home telling you how much sex he is having.

        --
        I get constant rejection even though the compiler is supposed to accept constants.
    • (Score: 2) by LVDOVICVS on Monday March 16 2020, @07:20AM

      by LVDOVICVS (6131) on Monday March 16 2020, @07:20AM (#971813)

      This is Windows trying to defeat Linux by swallowing it.

  • (Score: 5, Informative) by dltaylor on Sunday March 15 2020, @07:53AM (12 children)

    by dltaylor (4693) on Sunday March 15 2020, @07:53AM (#971514)

    I've been using that for more that 20 years. Initially, one of the big draws was a working, free X server, which let me run Bourne shells not only on my desktop Windows, but to ssh into Suns and other *NIX boxes at various employment. I have even run the X displays from HP logic analyzers back to it.

    What does the new kernel shim give me, other than I can run binaries (non-X, I suspect) from some distribution other than Cygwin?

    What do I lose, compared to Cygwin?

    • (Score: 0) by Anonymous Coward on Sunday March 15 2020, @12:26PM (1 child)

      by Anonymous Coward on Sunday March 15 2020, @12:26PM (#971541)

      What does the new kernel shim give me

      Choice ?

      Choice is good, right ? Isn't that what you geeks keep repeating day in and day out ?

      • (Score: 2) by DannyB on Monday March 16 2020, @03:11PM

        by DannyB (5839) Subscriber Badge on Monday March 16 2020, @03:11PM (#971901) Journal

        I CHOOSE NOT to run Windows. (Except at work, where someone else is responsible for maintaining it.)

        --
        I get constant rejection even though the compiler is supposed to accept constants.
    • (Score: 5, Interesting) by JoeMerchant on Sunday March 15 2020, @12:53PM (5 children)

      by JoeMerchant (3937) on Sunday March 15 2020, @12:53PM (#971547)

      I did some fairly serious Cygwin work in the 2003 timeframe, and I was really impressed with how "close to the metal" it was, I'd get 98%+ performance out of a Cygwin application as compared to the same code running on a dedicated Linux shell, and I suspect that last 1.x% of performance was just the Windows background tasks popping in to phone the mothership, etc.

      Still, the whole exercise felt... dirty, somehow. It didn't work at all when I migrated to 64bit in 2005, for that I had to go to Gentoo. Many years later 64 bit Cygwin became possible, but, remarkably, it was a bigger PITA even than installing Gentoo on the bare metal.

      For the things that work in Cygwin, it's a perfectly valid option. When things get funky, I still prefer to be working in something like Ubuntu where you can lean on the experiences of many other people who have tried (and succeeded) to do the same thing you're trying to do.

      Lately, when presented with a "must provide a Windows environment" mandate, our preferred architecture is Ubuntu with Windows running in a Virtual Box - this way we can be sure that we've got Windows under control, and if Windows packs it in - at least the Ubuntu system is still up and running. One application plays real-time audio - in the Ubuntu layer, because Windows never did reach 100% smooth playback capability and we hate explaining to our customers "yeah, it just does that sometimes, nothing we can do about it."

      --
      Україна досі не є частиною Росії. https://www.newsweek.com/russian-state-tv-ukraine-war-dirty-bomb-putin-1754428
      • (Score: 1, Informative) by Anonymous Coward on Sunday March 15 2020, @05:22PM (4 children)

        by Anonymous Coward on Sunday March 15 2020, @05:22PM (#971624)

        > I did some fairly serious Cygwin work in the 2003 timeframe, and I was really impressed with how "close to the metal" it was, I'd get 98%+ performance out of a Cygwin application as compared to the same code running on a dedicated Linux shell

        I'm going to assert that your work load did not involve forking. We had an application stack that ran on Solaris and Linux. A decision came down that there should be a windows port, and to get this done with minimal fuss, some stuff would be properly ported, but some of the supporting scripts and less run-time critical bits would run under cygwin. Our experience was cygwin was at least 100 times slower when forking processes (and this had a lot to do with windows being slower than shit to fork processes-- this was microsoft's motivation for the shit ton of git patches they dropped that allow a bunch of operations to be performed without a zillion forks (forks on linux are as fast as threads on windows-- forks on windows are as slow as swapping floppy disks [almost]).

        • (Score: 0) by Anonymous Coward on Sunday March 15 2020, @11:02PM

          by Anonymous Coward on Sunday March 15 2020, @11:02PM (#971698)

          Windows doesn't support fork() or exec() natively. In order to emulate the behavior of fork(), cygwin has to jump through all sorts of hoops. It is a surprisingly complex operation. The context switches, mutexes, etc. produces a lot of overhead. Then if you call exec(), you end up causing another massive behavior emulation routine.

        • (Score: 3, Interesting) by JoeMerchant on Monday March 16 2020, @12:20AM (2 children)

          by JoeMerchant (3937) on Monday March 16 2020, @12:20AM (#971723)

          Yep, no forks in my little Cygwin toys.

          I did a similar exercise just last month - ported a C++/Qt app to Python/PyQt - the first part of the port went swimmingly, 96% performance. Then I got to the "core" of what the C++ was doing: image pixel value manipulations, and Python tied itself in a knot: something like a 700x slowdown.

          --
          Україна досі не є частиною Росії. https://www.newsweek.com/russian-state-tv-ukraine-war-dirty-bomb-putin-1754428
          • (Score: 2) by Pino P on Tuesday March 17 2020, @12:45AM (1 child)

            by Pino P (4721) on Tuesday March 17 2020, @12:45AM (#972058) Journal

            Then I got to the "core" of what the C++ was doing: image pixel value manipulations, and Python tied itself in a knot: something like a 700x slowdown.

            Did you try having Pillow, NumPy, or another image or signal processing library do the inner loops?

            Or was the nature of the problem such that it would require so many calls in and out of the library that the overhead of marshaling arguments between the Python and C environments would dominate runtime? Because I ran into a Python-to-C call rate bottleneck a few years ago when I was trying to get Pillow and PyPy to work together. I wanted to take the sum of each 16x16-pixel area in a difference image, and in Pillow, that requires making a cropped copy of each 16x16-pixel image. In PyPy, calls to extensions that use the traditional Python C extension API [blogspot.com] or ctypes are slow, whereas calls to extensions that use CFFI [readthedocs.io] (the Python port of LuaJIT FFI) are fast. Guess what Pillow wasn't using.

            • (Score: 2) by JoeMerchant on Tuesday March 17 2020, @02:39AM

              by JoeMerchant (3937) on Tuesday March 17 2020, @02:39AM (#972081)

              The real trick is learning time. I have a half-dozen rather straightforward problem statements to implement, and they're all obvious (to me) how to implement in Qt/C++, but constitute a pretty steep learning curve for me in Pillow/NumPy/OpenCV/what-have-you. Convert RGB to HSV or HSL, run statistics on the color channel values at each pixel location (things like mean, median, mode), make a transform which maps one set of images to have an identical color channel histograms as another set of images at each pixel location, copy-paste arbitrary ellipses from one image into another with alpha-blend margins, etc. etc. When the library has a function pre-built (like RGB to HSL transform) then, brilliant, say the magic words and it just happens.

              My greatest frustration is when a library doesn't do something, because then the documentation tends to be silent on that point (hard to confirm a negative....), and when a library/language can't be made to do something in a practical manner, the documentation tends to be doubly silent on that point.

              --
              Україна досі не є частиною Росії. https://www.newsweek.com/russian-state-tv-ukraine-war-dirty-bomb-putin-1754428
    • (Score: 0) by Anonymous Coward on Sunday March 15 2020, @04:44PM

      by Anonymous Coward on Sunday March 15 2020, @04:44PM (#971607)

      I used Cygwin for quite a bit. It's really nice, except when things don't build/break in some inexplicable way (a lot of it was because no one tested it under anything but Linux and OS X, and often not even that latter).
      WSL sidesteps that problem by just providing a Linux environment.

    • (Score: 5, Informative) by TheRaven on Sunday March 15 2020, @05:00PM (2 children)

      by TheRaven (270) on Sunday March 15 2020, @05:00PM (#971613) Journal

      There are three things to compare here:

      Cygwin is a Windows DLL that provides a more-or-less complete set of POSIX APIs, with some Linux-compatibility things. It also provides a package manager and a few other things, but it's basically a way of compiling a *NIX program so that it will run on Windows. Because Cygwin programs are native Windows programs, they can load Windows DLLs, including the ones required for talking to the windowing system, and interop natively.

      WSL was a compat layer akin to the Linux system call layer found in *BSD, Solaris, and so on. It is a bit more complex on Windows because Windows doesn't have quite such a strictly defined kernel interface. For Win32 (and UWP) apps, there are a lot of DLLs that are injected automatically, where some kernel component can directly manipulate the kernel-owned data structures within the process. WSL uses the picoprocess abstraction defined for Drawbridge (the Windows-based library OS). A picoprocess is even more cut down than a *NIX process: it's basically like a Mach task, with nothing inside and just a control handle. Current Windows kernels only provide one picoprocess handler (though it wouldn't be very difficult to fix this). This is used by WSL, so when a picoprocess is created it is then initialised to look like a Linux process on start up and has a Linux-compatible system call handler installed. As a side effect of WSL, Windows got a full pseudoterminal layer and some other reusable components. WSL processes are not normal Windows processes, but the layering is such that they sit on top of the same low-level services as Windows processes (unlike the old POSIX and OS/2 subsystems in Windows NT, which had completely different implementations for things that you'd quite like to be shared, such as most IPC). In particular, the filesystem is shared. This is the main performance pain point for WSL: there's a filter driver that sits on top of the NTFS driver and provides NT or POSIX semantics to the filesystem depending on how it's being accessed.

      WSL2 is much simpler. It's a Hyper-V VM set up to use the WSL terminal layer as its system console (I believe that this is done by forwarding the serial interface through the Windows pseudoconsole, but I'm not sure, it my just be using SSH), with a root filesystem that's attached as a block device containing a Linux-native filesystem (so no translation via filter drivers), and with shared folders implemented as 9P over VMBus (hopefully FUSE over VMBus soon, but I don't know if that's actually on the Hyper-V team's roadmap). This has a native Linux kernel, so has a full network stack, IPC layer, and so on. This can communicate with the host kernel only via network IPC. In theory, that's a big limitation, but in practice that's pretty much all WSL1 programs ever do.

      On the X11 side, there are several builds of X.org for Windows. I believe VcXsrv [chocolatey.org] is the best choice. There are also a load of expensive alternatives, though I've not seen any evidence that they're better. These all (as with any X server) communicate with network-transparent IPC, and so work fine with Cygwin applications, WSL applications, and anything that runs in a Hyper-V VM. I run a FreeBSD VM on Hyper-V on my work desktop and can quite happily display graphical apps forwarded over SSH.

      One of the nice things about WSL1 is that you can run an X11 terminal, but still then run cmd.exe or powershell.exe to get a Windows command prompt (the new Windows terminal is coming along well, but I still don't like it quite as much as some more mature *NIX ones. Sorry Dustin!). I use this to run Konsole, edit code in vim, and then run the .bat file that Visual Studio installs to set up command-line paths correctly and then build with cmake + Ninja, all from within a terminal.

      WSL and WSL2 both natively support fork, so process creation costs are low (the hoops Cygwin jumps through to make fork work are slightly terrifying and incredibly slow: if you've ever run a configure script in Cygwin then you'll have seen this). Cygwin is a POSIX compatibility layer, WSL is a Linux compatibility layer, so software written by muppets who don't think about portability (also known as 'Linux programmers') is more likely to work. WSL2 gives faster disk I/O and better Linux compatibility (it *is* Linux), so things like Docker that abuse weird corner cases of very Linux-specific APIs work. The main thing you lose relative to Cygwin is the ability to mix Win32 / UWP and POSIX code in the same process (which, it turns out, few people actually want to do). If you just want an X server, you don't need any of them.

      I haven't tried WSL2 yet. I'm hopeful that the tight integration work on the Windows side will make it possible to have a FreeBSD version (some folks on the Hyper-V team tell me it should be relatively easy, but they don't have engineer time to devote to it). I miss control-t when I have to use Linux...

      --
      sudo mod me up
      • (Score: 2) by dltaylor on Monday March 16 2020, @01:23AM (1 child)

        by dltaylor (4693) on Monday March 16 2020, @01:23AM (#971746)

        Those are the kind of trade-offs I was concerned about. The "shim" I mentioned was reallt WSL, but the WSL 2 is a different beast.

        Although it was initially the X server, shell (and associated tools), and ssh, I usually use Cygwin now to do things Windows makes either more trouble than necessary or impossible, or just to use the same tool there as on other *NIX. Raw device access, for example checksumming an entire CD, is still easy on a Cygwin/bash command line.

        I thought FreeBSD already ran in VMs. Is it "just" a matter of integrating with the new "free" setup or something else?

        • (Score: 2) by TheRaven on Monday March 16 2020, @09:38AM

          by TheRaven (270) on Monday March 16 2020, @09:38AM (#971827) Journal

          I thought FreeBSD already ran in VMs. Is it "just" a matter of integrating with the new "free" setup or something else?

          It runs very well in Hyper-V (locally and in Azure), but WSL2 has a bunch of integration hooks. I believe FreeBSD has a 9p-over-VirtIO driver under review, but it's not landed yet. Once this is in, 9p-over-VMBus is a relatively simple change (same messages, different link-layer protocol, but FreeBSD already has VMBus support). That's needed for the transparent file sharing thing (the Windows filesystem is exposed in WSL as /mnt/c, /mnt/d, and so on. In WSL2 these are 9p-over-VMBus filesystems). I think there are a few other glue things that may be needed. I haven't tried it with WSL2, but I believe Linux supports the Hyper-V virtual sound interface, which means that command-line WSL2 applications should be able to open /dev/dsp and make sounds, whereas FreeBSD is missing that driver (I don't care too much about this one, but it would be nice to have).

          Last time I spoke to anyone on the Hyper-V team working on this, they were interested in supporting other operating systems, but Linux is the thing customers care about so it's the highest priority.

          --
          sudo mod me up
  • (Score: -1, Flamebait) by Anonymous Coward on Sunday March 15 2020, @07:54AM (3 children)

    by Anonymous Coward on Sunday March 15 2020, @07:54AM (#971515)

    Really! This much Microfuck propaganda in this short of time on SoylentNews? Eds, are we trying to prove we are still "in the Game" with the "big players" but running articles on failing architectures that no sane person used anymore? I mean, "Micro$erf" is no longer a saucy assault on a mega- corporation, it is just a pathetic admission of the state of affairs regarding operating systems.

    • (Score: 3, Informative) by janrinok on Sunday March 15 2020, @01:46PM (2 children)

      by janrinok (52) Subscriber Badge on Sunday March 15 2020, @01:46PM (#971553) Journal

      What's is your problem? We also mention BSD from time to time. This isn't a linux site, it is just that many people in the profession use linux by choice. As Buzzard pointed out professionals don't always have a choice which OS they have to use.

      Windows still exists whether you like it or not, and many people still use it. It isn't a taboo subject.

      At SN we choose good user submissions over bot collected subs whenever we can, so start submitting stuff about your own particular interests. But poor quality submissions (which includes many of those providing just a URL and then requiring the Eds to do all the work to make it usable) will not automatically take priority over bot collected material. We have to use bots because there is insufficient quality material to fill the front page. But a well written submission that is on-topic stands a good chance of being accepted, even from those in our community who complain about how many of their subs are rejected.

      • (Score: 2) by takyon on Sunday March 15 2020, @04:25PM (1 child)

        by takyon (881) <{takyon} {at} {soylentnews.org}> on Sunday March 15 2020, @04:25PM (#971599) Journal

        This isn't a linux site

        This is a Linux story.

        In fact, I dare say that Microsoft Windows is the one true Linux distribution. ;)

        --
        [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
        • (Score: 0) by Anonymous Coward on Monday March 16 2020, @04:39AM

          by Anonymous Coward on Monday March 16 2020, @04:39AM (#971791)

          This is a Linux story.

          The "Linux on the desktop" story, right?

  • (Score: 1) by shrewdsheep on Sunday March 15 2020, @10:43AM (9 children)

    by shrewdsheep (5215) Subscriber Badge on Sunday March 15 2020, @10:43AM (#971534)

    M$ makes a big strategic mistake (from their perspective). Once a smooth X/wayland layer is addded, this will make Linux the prime citizen in desktop and M$ will have to become a Linux distribution (maybe that is the plan).

    • (Score: 3, Touché) by EEMac on Sunday March 15 2020, @11:37AM (4 children)

      by EEMac (6423) on Sunday March 15 2020, @11:37AM (#971538)

      Why is that a bad thing?

      • (Score: 3, Insightful) by janrinok on Sunday March 15 2020, @01:49PM

        by janrinok (52) Subscriber Badge on Sunday March 15 2020, @01:49PM (#971554) Journal
        I don't think he did say it _was_ a bad thing - but it might still be a strategic error for MS as a company. If they become a linux distro why would people bother? Every other distro is free!
      • (Score: 4, Insightful) by Anonymous Coward on Sunday March 15 2020, @02:08PM (2 children)

        by Anonymous Coward on Sunday March 15 2020, @02:08PM (#971560)

        SYSTEMD.DLL would be a whole new dimension of pain

        • (Score: 1) by khallow on Sunday March 15 2020, @03:53PM

          by khallow (3766) Subscriber Badge on Sunday March 15 2020, @03:53PM (#971581) Journal
          Not at all. A few quick edits of Windows registryd's binary files will fix up any minor problems you might have.
        • (Score: 2) by DannyB on Monday March 16 2020, @03:14PM

          by DannyB (5839) Subscriber Badge on Monday March 16 2020, @03:14PM (#971903) Journal

          Maybe Microsoft will ban systemd from WSL ?

          --
          I get constant rejection even though the compiler is supposed to accept constants.
    • (Score: 0) by Anonymous Coward on Sunday March 15 2020, @02:15PM (1 child)

      by Anonymous Coward on Sunday March 15 2020, @02:15PM (#971562)

      Why would Microsoft do that? Graphically, the Windows desktop services are much better than Linux'. It's the command line where Microsoft is lacking.

      • (Score: 0) by Anonymous Coward on Sunday March 15 2020, @05:04PM

        by Anonymous Coward on Sunday March 15 2020, @05:04PM (#971617)

        m$ is ALWAYS out for money. the first and formost consideration is always to make more money.
        this, ofc, doesn't always jive with what the user deserves.
        m$ "putting in" linux isn't about anything but tying a thin thread at their previously "star windows users" like a clingy gf or bf because they accidentally installed linux, liked it and are jumping ship. ofc m$ will never learn: money ruleZ the world in their book ... let go already!

    • (Score: 3, Insightful) by toddestan on Monday March 16 2020, @03:16AM (1 child)

      by toddestan (4982) on Monday March 16 2020, @03:16AM (#971776)

      I'm pretty sure that Microsoft would prefer you to use Windows, but if you're going to use Linux then they want you to use their Microsoft Linux on Windows instead of installing Linux on the bare metal. Kind of a variation on the old days when Microsoft would prefer you buy Windows, but if you aren't paying for your operating system then they'd rather you pirate Windows than install Linux.

      • (Score: 3, Funny) by DannyB on Monday March 16 2020, @03:15PM

        by DannyB (5839) Subscriber Badge on Monday March 16 2020, @03:15PM (#971904) Journal

        In the early Groklaw days, I used to joke about this exact scenario. Never taking my joke seriously. Now here it is upon us. Just like the one time joke that you couldn't get infected with malware by merely receiving an email into your inbox.

        --
        I get constant rejection even though the compiler is supposed to accept constants.
  • (Score: 2) by turgid on Sunday March 15 2020, @01:52PM

    by turgid (4318) Subscriber Badge on Sunday March 15 2020, @01:52PM (#971556) Journal

    Those were the days. But without multi user and networking. Or a proper shell.

  • (Score: 3, Interesting) by Anonymous Coward on Sunday March 15 2020, @02:06PM (5 children)

    by Anonymous Coward on Sunday March 15 2020, @02:06PM (#971559)

    What they are going to do is hire a bunch of "volunteers" to start tweaking Linux base libs so they only compile in Visual Studio. The goal will be to break applications except those that run on blows-nix.

    Maintainers of cross compilable code need to be on the lookout for new "help". The trojan horse is coming.

    • (Score: 4, Funny) by turgid on Sunday March 15 2020, @02:16PM

      by turgid (4318) Subscriber Badge on Sunday March 15 2020, @02:16PM (#971563) Journal

      With systemd coming in from the other side, this is what Hannibal would have called a pincer movement. I used to watch the A-Team. Maybe BA will build us an armoured vehicle to help us escape?

    • (Score: 2) by TheRaven on Sunday March 15 2020, @05:02PM (3 children)

      by TheRaven (270) on Sunday March 15 2020, @05:02PM (#971614) Journal

      What they are going to do is hire a bunch of "volunteers" to start tweaking Linux base libs so they only compile in Visual Studio

      Uh, what? Visual Studio can't build ELF binaries, so this would break all of the compilers that can actually build a working binary. What insane upstream projects do you think would accept those patches, even if this were Microsoft's goal?

      --
      sudo mod me up
      • (Score: 2) by dry on Sunday March 15 2020, @10:34PM (2 children)

        by dry (223) on Sunday March 15 2020, @10:34PM (#971690) Journal

        How hard would it be to add ELF to the VS linker? I believe that wlink, the OpenWatcom linker can do it both ways, linking ELF objects to build a Win32 or in the case of the fork, win64 binaries or OBJ (OMF) object files to make a ELF binary.

        • (Score: 2) by TheRaven on Monday March 16 2020, @09:40AM (1 child)

          by TheRaven (270) on Monday March 16 2020, @09:40AM (#971829) Journal
          It's not just the linker. The compiler doesn't know about ELF, doesn't know about SysV ABIs, doesn't know about ELF visibility (which is not the same as dllimport / dllexport). It would be a fairly large engineering effort for absolutely no gain. What would Microsoft gain from making people use Visual Studio's compiler for Linux? Linux devs can already use VSCode with Clang or GCC, and that doesn't cost compiler engineer time.
          --
          sudo mod me up
          • (Score: 2) by dry on Monday March 16 2020, @02:42PM

            by dry (223) on Monday March 16 2020, @02:42PM (#971887) Journal

            I still wouldn't be surprised if MS started to add ELF support at some point. They seem to like people using their toolchain, though you may well be right about them not wasting the resources.

  • (Score: 2) by takyon on Sunday March 15 2020, @04:27PM

    by takyon (881) <{takyon} {at} {soylentnews.org}> on Sunday March 15 2020, @04:27PM (#971600) Journal

    I could have skipped submitting this story, but I couldn't resist a follow-up to ari's WSL2 coverage [soylentnews.org].

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
  • (Score: 1, Funny) by Anonymous Coward on Sunday March 15 2020, @04:47PM

    by Anonymous Coward on Sunday March 15 2020, @04:47PM (#971609)

    2020: The Year of Linux on the Desktop

  • (Score: 2) by DannyB on Monday March 16 2020, @03:18PM

    by DannyB (5839) Subscriber Badge on Monday March 16 2020, @03:18PM (#971906) Journal

    Currently: WSL2 runs Linux kernel in a VM under Windows kernel.

    Coming sometime: Windows kernel runs in a VM under Linux kernel. Still same Windows desktop. Stability of Linux. Continue the embrace, extend, extinguish. Have patience.

    --
    I get constant rejection even though the compiler is supposed to accept constants.
(1)