The definition of insanity is doing the same thing and expecting a different result. Microsoft has been trying to extinguish their competition for decades now; what makes you think they're going to be different this time?
And what makes you think they will do the same? Fact is you have no idea, and all signs point to a more open MS that has learned that simply throwing their weight around won't work anymore.
Sure I do. They've acted this way for decades, under various different management. To think they're suddenly going to become some nice, ethical company is sheer lunacy.
>and all signs point to a more open MS that has learned that simply throwing their weight around won't work anymore.
What signs? I haven't seen any. They've done stuff just like this before, and it always turned out badly.
You clearly don't work with Microsoft on a daily basis in a enterprise setup...
I'll fill you in. The new lock-in is Office 365 with Intune/SCCM and Azure. We are in the extinct phase of having better management options in Intune for Office and surrounding technologies and enterprise IT will see this as an advantage over choosing another MDM/MAM vendor. Step one done for still controlling productivity apps and device management. Now it's getting developer mindshare and focus back on the Windows ecosystem. Pretty easy in enterprise as we just did a lock-in with Office 365/Intune. They still throw their weight around and their key/technical account managers must have missed the memo saying to be more open for other vendors/partners. So they may look nice but don't make the mistake of thinking there isn't a plan behind.
Because they changed their position and direction. This was a necessary, rational and defendable choice and not some hollow marketing gag.
The company would be worse off if they do not stick to this direction and start backstabbing. It is bad enough that companies are legal persons, let's not anthropomorphize them even more into irrational evil villains that hold grudges.
There is no "New Kinder Gentler Microsoft". Corporations just do what they see as more profitable. They do not make decisions based on morality per se, but they try to maintain a certain public image when it helps profits.
"Linux geeks can think of it sort of the inverse of "wine" -- Ubuntu binaries running natively in Windows. Microsoft calls it their "Windows Subsystem for Linux"."
I find it amazing that you can have such a functional Ubuntu environment by translating system calls. Microsoft does have the advantage of Linux being open-source I suppose, while the Wine project had to reverse engineer DLLs. Or have you supply them on your own.
Indeed. Perhaps it will increasingly make sense to design software for Linux and then run it on windows via this method. Over time the Windows system calls that are not needed by the linux overlay can be phased out.
Windows NT had a POSIX subsystem awhile ago, not sure what happened to it. The NT Kernel was designed to have different personalities like Win32, OS/2, POSIX, etc
Its ironic (old)microsoft exerted so much effort to put the personalities in place (OS/2, posix etc), then (mid)microsoft systematically destroyed that work under Balmer, and now (new)microsoft are reimplementing the same thing under a (seemingly) completely different system.
To be fair, this new implementation is very completely different. If we had the same kind of experience with virtualization and hardware with VT-i/x/d or AMD-V when Microsoft was developing personalities, the chips would have landed very differently.
>Windows NT had a POSIX subsystem awhile ago, not sure what happened to it.
I was interested in that too, since I write Unix utilities and it is sometimes useful to have them work on Windows as well. I've done that (checked that it worked on Windows) with a few utilities in the past (written in C), that did not use any very Unix specific features that were not present on Windows. And remember reading around that time that Windows (I think it was from NT onwards) had a POSIX subsystem.
Then more recently, as in, a few months ago, I wanted to check that out again, and did. IIRC I read (maybe on a Wikipedia page) that the POSIX subsystem is not present in Windows any more.
"Windows NT was designed from the start to have modular subsystems. It was most infamously used to provide a POSIX subsystem which really only checked boxes on government acquisition forms. :-)"
That makes it seem that the POSIX subsystem only ever did that, which is not true at all. A better explanation is at https://news.ycombinator.com/item?id=11392369 , which gives a version number and a time frame for context. The POSIX subsystem was different in later years.
I would rather have the opposite. I would even pay for an official "Windows on Linux". There is a handful of games I would like to play, but other than that I have no interest in windows.
Totally doable. Use KVM to virtualize Windows and (the important part) make sure your CPU and motherboard support VT-d. Then you can pass a graphics card (separate from the one you run Linux with, naturally) to the VM and get >95% of native performance. There's lots of videos of folks doing this.
And the performance hit is almost certainly less than the relative performance of a "native" reimplementation of a foreign OS's syscalls that doesn't benefit from the decades of engineering work that went into making that foreign OS perform well.
As another posted pointed out, if you just want to bring up a VM for gaming, who cares?
Also, you can share directories between the native filesystem and the VM quite easily. And if you're using something like VirtualBox or VMWare there are "unity" windowing modes available.
> Also, you can share directories between the native filesystem and the VM quite easily. And if you're using something like VirtualBox or VMWare there are "unity" windowing modes available.
I tried them – they don’t work at all in KDE.
Arch linux host, KDE as DE, Windows 10 Guest, just leads to a big black box in unified mode, and windows don’t properly occur in the KDE taskbar.
What I expect is integration equal to WINE – automatically putting stored data into the correct folders, easily accessible and mounted, integrating windows with the taskbar, etc.
And yes, this is "just for games" – but try gaming on a multiscreen setup when the game doesn’t show up in your taskbar and you can’t minimize it.
Maybe it's a KDE problem? Other people certainly have been successful. But I guess that's par for the course in Linux -- lots of incompatibilities depending on how your environment is set up. Something like WINE is never gonna get there for running games as well as a VM can. So the options realistically are using a VM or reboot. The VM option is really pretty good all things considered.
That's a distinction without a difference if you're using a modern processor with special virtualization silicon like Intel VT-i/x/d or AMD-V. With these features, IO and memory management is completely isolated between different virtual machines at the hardware level so there is almost zero overhead. With VT-d, which allows you to dedicate DMA channels to a guest VM, you can completely bypass the the host for all types of hardware including PCI/e, USB, etc.
The "Native" OS is also under the hypervisor. So effectively you have real CPU, real RAM, real GPU, and you can give it a real hard drive too. At that point does it really matter that the USB controller and network card are virtualized?
I've heard that this works wonderfully for graphics, but the sound emulation is pretty terrible. At least, I've heard about clicks and pops when the game puts much load on the system. This was on a friend's machine; maybe he had it configured badly.
Well if you're giving some hypervisor-managed sound interface to the VM then I wouldn't be surprised to hear that. The answer is to get a cheap dedicated soundcard and pass it through to the VM, just like you would with the graphics card.
I also would've expected more demand for the opposite. I don't see myself ever switching back to Windows, but I'd pay $$$ to have Microsoft Project fully supported on Linux. I have more than a few colleagues who would be interested in the rest of the Office suite too, but who make do with LibreOffice because other things on Linux are more important.
>Microsoft does have the advantage of Linux being open-source
More correctly would be to say that Microsoft has advantage of user space libraries used in GNU/Linux distributions being open-source. Linux kernel itself being GPL2 is probably a problem for Microsoft's developers because of possibility to be accidentally exposed to it while researching documentation.
What does "clean room" style mean, exactly? I've heard the term, but only in connection with semiconductor factories, I think. You're talking about software here.
means a group check the source and documents. Another group never sees the code, only the documentation, and proceed to implement whatever they need being able to say that they have not used the original code.
*BSD and Solaris have done have run linux binaries for years. Doing it on Windows is a bit more impressive, but given that there is a POSIX subsystem, its not all that surprising.
I didn't see any information about whether they do it using direct system call translation, or if they do it using shared library inter-positioning. In either case, its pretty cool!
Windows NT was designed from the start to have modular subsystems. It was most infamously used to provide a POSIX subsystem which really only checked boxes on government acquisition forms. :-)
The reason WINE went with the library emulation route is because: (a) the Windows kernel doesn't have a stable system call layer, and (b) the Win32 API is massive anyway.
Windows has an easier time emulating Linux at the very lowest levels because Linux has an ABI stable system call layer. If you emulate those, you can run ANY Linux binary.
It also means Microsoft doesn't have to ship or support hundreds of Open Source projects. They ship the syscall layer, and distributions ship the user layer.
Also (c) Windows isn't open source so there are licensing issues with Wine shipping actual Windows DLLs. Some of them do work under Wine but the project aims to replace as many of them as possible with emulated versions.
It's a Linux syscall translator for Windows. It works well enough to run a Debian userland, although it's got so many holes and rough edges that I would never, ever, ever suggest using it for anything other than a stunt.
It uses Interix to do most of the heavy lifting, so all LBW does is to translate from Linux syscalls to Interix syscalls; so we get a Unix filesystem and user permissions and sockets and fork etc for free. (Interix was great. I'm glad they're bringing it back from the dead.) Unfortunately not all the system calls directly map onto each other; so Interix has a native fork(), but Linux emulates with clone(). I couldn't make threads work.
A few of the biggest problems were:
- the Windows page size is 64kB; the Linux page size is 4kB. The ld.so loader will try to map two bits of executable within the same 64kB boundary, and, of course, this doesn't work on Windows. I crudely hack around it by allocating pages of RAM and copying things. Write-back mapping only works at all if the application lets mmap() pick the address.
- very very very different register usage. glibc on Linux uses gs as a 'pointer' to the current thread's private data area, via a special syscall. Windows resets gs to 0 on every interrupt! I crudely hack around this by intercepting null pointer dereferences, looking at the instruction to see if it was gs, and then reloading it with the right value.
- even then, that syscall sets gs to point at a GTD segment with a size of 2^32; this wraps round the entire address space, which allows very large offsets in gs to be treated as negative numbers. Windows doesn't let you create GTD segments. It only allows LTD segments, and it caps the segment limit to the end of the user address space, so this trick won't work. I crudely hack around this by intercepting segmentation violations, looking at the instruction to see it it's a [gs+negative number] dereference, and then binary patching the executable to use a different instruction.
- glibc is horrible and undocumented. There's a big pile of key-value strings pushed onto the stack above the environment when the process is initialised, containing various magic numbers. ld.so will just crash if you get this wrong. I spent a lot of time reverse engineering the ld.so source code to figure out what these were and how to set them up.
It was all vile and horrible, but it worked surprisingly well (i.e., it worked, which was surprising).
Using the NT kernel's personality system to implement Linux syscalls natively is totally the right thing to do; that's obviously what they're doing here.
I would love to know about the internal Microsoft politics which made releasing this possible. I wonder how long it's been brewing? I did LBW in about a month of evenings; the core logic wasn't hard. I wouldn't be at all surprised if this hasn't been floating about inside Microsoft for years.
I used to use your program on my XP box a while back... I told an MS exec about it and he seemed really impressed. It would be funny if they got some of the core ideas for this from LBW.
That "big pile of key-value strings pushed onto the stack above the environment" is auxv. You can see it in the binary /proc/*/auxv files. It's generated by the kernel's ELF loader.
1) Linux has won the server (web) market. Developers would like to use a Unix box to work on their server code so they typically move to OS X. This could prevent that switch because they can still use Windows to developer their Linux server software.
2) Many projects start out as Linux and stay Linux and are only ported after much time and effort to Windows. Enterprises when faced with a tool that they want to use will also look to switch off Windows. Now rather than the cost of switching they only have to pay to upgrade their windows boxes to use the tool.
3) There is now a major incentive for developers to only build Linux binaries because it will work more places. This might cause a faster drain of developers as they eventually remove all windows specific code and can more easily migrate elsewhere. This feels eerily similar to the OS2 story and no doubt in the next week I expect to see more than a few articles discussing this very thing.
4) It will be much easier for Microsoft to bring much loved Linux tools to Windows so you can expect to see a more rapid increase of tools announced that now work for Windows.
> This feels eerily similar to the OS2 story and no doubt in the next week I expect to see more than a few articles discussing this very thing.
Although, as others have already pointed out, it differs in some very significant ways.
OS/2 2.x providing Win16 binary compatibility was an after-market system providing binary compatibility with applications made for the operating system that shipped "out of the box". Whereas this is the operating system that ships "out of the box" providing binary compatibility with applications made for an after-market operating system.
(Yes, yes. One could buy OS/2 pre-installed, and one can buy Ubuntu Linux pre-installed. The scale of that, in both cases, is nowhere near significant enough to change the basic fact that overall the two situations are the reverse of each other.)
Also: There was not the extent of existing tools available natively on both platforms, in the OS/2 case. The examples being waved around in the news now are things like Apache, Ruby, Node, and so forth. There wasn't the OS/2-and-Win16 analogue of (say) the Ruby developers deciding in the months to come that a Win32 port is too hard to maintain, and dropping it in favour of just running the Linux Ruby on the Windows NT Linux subsystem. Today's analogue of the OS/2 case would be a universe where there was no Win32 Ruby at all, and the Ruby developers deciding not to start making a Win32 version because the Linux one "is good enough for the few Windows users".
I suspect that drawing parallels based upon what happened with OS/2 2.x and Win16 is a mistake, and those thinking that this will mean an outflux of Windows development "because it happened with OS/2 2.x" (which was more like an influx of development that failed to happen) are indulging in wishful thinking.
There's also the minor matter that, during the OS/2 2.x and Win16 time, there was this little thing called Windows NT lying around, promising a route for OS/2 1.x, where the existing tools were, with its OS/2 subsystem. (It is ironic that we are once again looking at a Windows NT subsystem.) That has no equivalent this time around at all; unless one mis-casts UbuntuBSD (https://news.ycombinator.com/item?id=11326457) in that rôle. It doesn't really fit, though. "Look, all you people with Ubuntu Linux application softwares. Forget that minority Windows thing that you ported to a couple of years ago. Come bring your applications to this new FreeBSD instead." (-:
Right... Bash is a shell, but your interaction with it is controlled by a terminal program. Unless there are some real changes to cmd.exe t̶h̶e̶n̶ ̶i̶t̶'̶s̶ ̶n̶o̶t̶ ̶t̶h̶a̶t̶ ̶i̶m̶p̶r̶e̶s̶s̶i̶v̶e̶ . You can compile a native bash and other utils now yourself, it's not that hard.
EDIT: It's more like a Linuxulator from BSD, which is certainly cool.
> "Hum, well it's like cygwin perhaps?" Nope! Cygwin includes open source utilities are recompiled from source to run natively in Windows. Here, we're talking about bit-for-bit, checksum-for-checksum Ubuntu ELF binaries running directly in Windows.
You seem to completely miss the point of what they did. It is not a simple Bash recompilation for Windows. It is a way to run Linux (Ubuntu) binaries on Windows.
conhost (the black box that typically runs cmd.exe) is a terribly shitty terminal emulator. My biggest gripe with Windows has been the lack of a decent pseudoconsome system that would allow an ecosystem of terminal emulators to developer, as one has for POSIX-ish systems.
ConEmu looks nice; it came out after I switched from Windows to Linux, so I've never tried it. I like the idea of hooking the console API functions; before I stopped using Windows, I was working independently on a similar API-hooking system that talked to the Cygwin pty layer instead of to a custom terminal.
With a real pty, you'd be able to use any Windows console program with mintty, sshd, Emacs term-mode, or whatever else you wanted, transparently. I regret not having a chance to finish that work.
> My biggest gripe with Windows has been the lack of a decent pseudoconsome system that would allow an ecosystem of terminal emulators to developer, as one has for POSIX-ish systems.
The demonstrators in the Microsoft video do warn that they will be avoiding some of the holes of the system in their demonstration. One is very briefly visible at 08'13", before the demonstrator rapidly clears the screen (again), when they run apt-get to install git:
E: Can not write log (Is /dev/pts mounted?) - openpty (2: No such file or directory)
The new Windows NT Linux subsystem apparently doesn't have pseudo-terminals.
The old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one) has pseudo-terminals with both BSD and System 5 access semantics, in comparison.
Moreover, a Windows console window that is the controlling TTY of a POSIX program in that subsystem has the POSIX cooked input mode with local echo, and generates escape sequences for extended keys.
Well I, for one, think he has a point. Part of what makes the shell so useful on Linux is, say, highlight-to-select. When the CMD.EXE doesn't understand line breaks in copied text, it's substantially crippled. You need a proper terminal to take advantage of a proper shell. They go hand-in-hand.
Selection, copying, wrapping etc. has been fixed in the Win10 version of the console host.
In pervious versions you could always use another console like Console2, but now it's built in (although the third party options still have more features than the new built in one).
"cmd.exe console" means (presumably...) a standard Windows console subsystem window. This is independent of cmd.exe, but it's common to conflate the two. Unix users often get this mixed up, presumably because they don't believe Windows has any kind of layering or modularity ;)
Whatever it prints on Ubuntu I expect. Obviously it's not going to return "Windows", or "UbuntuInWindows" else anything that makes that call that would break.
As WinLS is very much like branded Solaris Zones, here's what it looks like when you run `uname -a` in an (old, copypasta from the web) Linux branded zone:
Linux centos 2.4.21 BrandZ fake linux i686 i686 i386 GNU/Linux
So if I install Node as a Linux binary. Can I access it in Windows "environment" too?
Does that mean I can do "apt-get install nginx" from their new "bash" terminal app? Does that then run under port 80 in Windows? Since no VM is involved.
I don't want or need a Linux ABI, I just want to run a Linux container on Windows (if I have to use windows, which I would prefer not to do).
If node running on windows needs access to a database running on the Linux layer then what happens when things aren't working? They can't possibly make all programs interact in a seamless way.
I'm imagining frankenstein programs that are hacked together with code that only works on this frankenstein OS.
Microsoft probably hard-codes a response of "Linux" (or whatever would be normal for Ubuntu) for that call to prevent Ubuntu binaries from freaking out.
You recall incorrectly. Windows NT kernels have been able to unlink open files right from the get-go, at the start of the 1990s. They had to be, in order to support the POSIX subsystem.
When files are manipulated through the Win32 subsystem they are (normally) opened in "deny delete" mode (i.e. without passing FILE_SHARE_DELETE to CreateFile and thence to NtCreateFile). But that's Win32 programs and language runtime libraries explicitly setting the sharing mode flags that they like, not an inability of the Windows NT kernel that is below the Win32 subsystem, nor even an inability of the Win32 subsystem itself.
It looks like alternize was almost right, at 4:39 you can see that within the Ubuntu (not /mnt) part, default permissions are used. e.g.: `ls -l proc` reveals that much of it is read only.
If the Ubuntu on Windows personality/subsystem gave Linux processes full permissions to /mnt/c, I'd expect that would be a security vulnerability, and I'd assume they are doing some mapping. Unfortunately, in the video they posted I never see them do `ls -l` on `/mnt/c`, only a subdirectory they created.
Correction: filesystem permissions are not fully emulated, but they aren't disobeyed either. Looks like everything obeys the user's permissions, which is good, but everything under /mnt shows up as 777 root/root.
I used to use them (directory junction points) quite a bit back when 64GB SSDs were still expensive and I wanted to redirect a few folders without changing my folder structure.
Nowadays, the most common use I've seen is as the Windows implementation of 'npm link' for Node.js developers.
You can't use lx-branded zones in Solaris anymore, but SmartOS has revived and continued the project, and OmniOS has started porting the bits into their distribution, too.
After Oracle bought Sun. It was never a part of Solaris 11. I don't know if it's still part of Solaris 10 or not, but even if it is, it's only barely usable.
But it's alive and well (and awesome) in SmartOS, with active work going on to merge it into OmniOS, and eventually will be upstreamed to illumos-gate.
I think this was a smart balance between getting it out there and seeing if it will stick. Someone said POSIX went by the wayside some time back so they may be a little hesitant in jumping all in. If this gets adoption, they can improve upon it in a future release.
"FreeBSD has had 32-bit ABI compatibility for at least a decade"
Longer. I was using linux binary compat, in FreeBSD, to run the linux version of vmware workstation back in 2001.
It has always been very well done, and as you can see, not just running 'cat' or 'echo' linux binaries ... but full blown commercial software packages.
I had Windows XP running, as a dev environment, within the Linux version of vmware workstation, on my freebsd laptop. Worked great.
There was an oft-repeated claim in those days (the days of FreeBSD 4.x) that linux binary compat in FreeBSD would run linux binaries faster than linux would.
What? This is sick!? I can't wait for this to happen! Maybe I am gonna get one of those Surface Books after all... though I am gonna miss my i3 setup... I wonder if X (or wayland! or wayland...) can run as well... Native Emacs FTW :)
Strictly speaking: none of those commands were "included in the distribution" when it came to OS/2. There were of course ports of those commands to OS/2, which one could install. But none of those came in the box.
I believe that that was also true for AmigaDOS, even the post-Commodore versions, but I don't have the firsthand knowledge to state it unequivocally.
Ubuntu ate Linux (or GNU/Linux), as it seems, for the mainstream world.
I hate it. I bet Stallman, Ken Thomson, the GNU Project, Bell Labs and many others are crying and laughing at the same time.
We live in a world built upon the previous one, as the previous was already was. Some things we forget, others become lore, folklore, myths, and others are lost...
It is similar to Facebook providing Internet. Or Dropbox providing 'rsync'. Maybe one day the common man will rediscover plaintext and the command line interface. And the then hipsters will use it.
- AWK was created at Bell Labs in the 1970s, and its name is derived from the family names of its authors – Alfred Aho, Peter Weinberger, and Brian Kernighan. ~ https://en.wikipedia.org/wiki/AWK
I wonder if they implemented a copy-on-write fork syscall in NT. Otherwise it will be slower (and use a lot more memory) in some scenarios.
Edit: And cow fork only makes sense if there is memory over-commit. So to be fully featured it would need a separate memory subsystem with memory over-commit.
No, you don't need overcommit for COW fork. You can fully commit the writable pages of the new process. Yes, that uses a bit of pagefile space, but disk space is cheap, and this approach works fine. You can (and should, if you care about robustness) turn off overcommit on Linux too.
microsoft is leveraging FOSS Linux to get Mac users. I think it's a real smart move.
The author points to using grep and Xargs and some other tools to quickly update a package. That's the key here. These bash/Linux utilities are productivy boosters for all the Linux and Mac/bsd people out there. I can't imagine living without them and they're necessary for any system I develop on (which is currently a Mac).
I've been "stuck" with a 2010 Macbook since Apple isn't refreshing it's laptop hardware soon enough. Plus I'm sick of soldered in RAM and other BS.
For devs that do heavy Linux work (but have stuck with a Mac OS for GUI/app reasons), is it time to move (back) to Windows? If so, what would be a good laptop to get at the moment?
Dell's Inspiron line is my go-to for portable workstations. Run Linux straight on them, or if GNOME/KDE aren't your cup of tea just run Windows and put your distro of choice in a VM (I just run Fedora on everything but my gaming PC, personally).
I'm personally using a Dell XPS 13 (2014), soldered in RAM, but I did buy an ultraportable and 8GB is more than sufficient to do my all my personal work on. Work supplied me with a Lenovo W540 that is substantially more flexible, but it weighs as much as a couple bricks and I usually just leave it at home on the dock.
I don't have hands on experience, but Dell XPS 15 looks like an interesting option for thoaw looking for Windows laptop that is close to 15" Macbook Pro (quad core, sleek etc).
I have the XPS 15. It is almost identical to a Macbook Pro. Build quality is really awesome. Super super happy with it. The new one with the infinity edge screen is super friggin' sexy, and will absolutely be my next computer. I know a bunch of other devs on the XPS 15 as well, also very happy (we run Ubuntu, but I'm sure it's even better in Windows).
I have one that is now 2.5 years old. Specs-wise, it was basically top of the line. Quad Core i7, 16GB RAM, 500GB SSD, 3200x1800 touchscreen, GeForce 750m GPU (which was one of the best mobile GPUs back then). It has a lot of nice touches that lower end models don't have, like 2 or 3 USB3 ports, with 2 or 3 USB ports that have power even when the laptop is off (super handy for charging a phone on an airplane while your laptop is still in your bag, for example). Wireless N networking, HDMI and MiniDP connections, able to drive two external monitors at once along with the laptop screen (up to 1920x1200 over HDMI and 4k over miniDP). The touchpad is pretty decent. backlit chicklet keyboard with variable brightness. SD card slot, 1/4" headset port... the only thing it's missing is an ethernet port, but that's just because it's too thin for the port. A USB3 gigabit ethernet adapter is cheap and works great.
And it's pretty damn light for a 15" laptop. Easily one-handable (I think it's like 2 pounds IIRC).
And what's great is that you can crack it open and replace stuff - I swapped out the hard drive and replaced a malfunctioning battery myself with just a torx screw driver (super tiny torx, but still, no glue or special tools or anything).
It was pretty expensive - like $1900 IIRC. You're paying for the high res screen, better build quality, and thinness/lightness. But it's still like $500+ less than an equivalent macbook.
Just out of curiosity, what does a Linux desktop offer that's not also natively offered in Mac and also highly polished?
Every year I try a switch to Linux desktop. This year I made it as far as trying to get multiple monitors working well. I also dabbed in gaming. In the end I went back to my work=Mac game=Windows duopoly.
Some tools (docker etc) are typically borne on linux and later (not always) ported to OsX. Nothing you cannot get around with a bit of emulation, of course, but it can be painful at times.
The whole python ecosystem is also better on Linux overall.
Anything strictly desktop-oriented is better on OSX of course.
> Just out of curiosity, what does a Linux desktop offer that's not also natively offered in Mac and also highly polished?
A GNU userland. A plethora of tiling window managers. A selection of clean terminals. Every single thing Debian's or Arch's repos offer which one must turn to brew for.
And of course there's freedom too, which is nice.
> Every year I try a switch to Linux desktop. This year I made it as far as trying to get multiple monitors working well.
I've got multiple monitors running on Linux, over HDMI, at home & at work, at differing resolutions & orientations. I use arandr-configured xrandr scripts which set my desired orientation with a quick keystroke in my window manager. What more does one need?
I've got monitors daisy chained using displayport on Debian, in mixed portrait and landscape modes. This is using an NVIDIA card and GNOME. It was plug-and-play.
That's great that it works for you. But for Skylake hardware, Displayport MST is completely broken and Intel have no plans to fix. The major players simply are not heavily investing in desktop linux, leaving the community to try and fill the gaps.
In my own experience Linux has the following Advantages over OS X these are of course subjective:
Better Desktop environment
Better Package Management
More Up to date packages
Some of my knowledge of OS X is likely outdated I haven't used it since 2011
I started using Linux when I was at University late 90's early 00's (Mandrake was my first distro). I switched to OS X around 2005 and used it as my primary operating system for about 5 years.
I used OS X because I'd purchased a MacBook Pro (mostly for the hardware) I still think Macbooks are the nicest laptops I've used to this day I went through 3 iterations of Macbooks before I stopped using OS X. I used OS X because it was good enough but I never fell in love with it.
I absolutely hated the desktop environment, silly things like no ability to customise anything, lack of workspaces, having to hit command q to kill application (because the 'x' button wouldn't close them properly) stuff like that. Workspaces came in a later OS X update which addressed some of my gripes.
It was never easy to install third party packages and libraries in OS X. I think this has improved now, when I used OS X it it was a mess (especially compared to the ease of something like apt). The native system packages were always really ancient - old version of GCC, old version of emacs, python etc. Trying to install newer version of these 'default' packages was not straightforward at all I remember having huge issues getting python 3 working.
Nowadays I run Fedora very happy with it. Not compelled at all to switch back. Linux support for modern laptops is a lot better than it was when I first started using Macs.
My current job is in an 'enterprisey' environment I'm forced to use a locked down version of windows here. Almost anything would be better.
> Just out of curiosity, what does a Linux desktop offer that's not also natively offered in Mac and also highly polished?
Freedom, a full GNU userland, proper package management of the entire system, plethora of CLI programs which can fulfil your every need and only really work on GNU/Linux, configurable, etc.
> Every year I try a switch to Linux desktop. This year I made it as far as trying to get multiple monitors working well. I also dabbed in gaming. In the end I went back to my work=Mac game=Windows duopoly.
I use multiple monitors every day for my work under OpenSUSE and Arch. They both worked with either minimal (Arch) or no (SUSE) configuration. I use DisplayPort which works pretty well.
I am a person, therefore a subset of people. I am interested. QED. Not to mention that that wasn't the only thing I mentioned, it was just the first because it's the most important.
>Just out of curiosity, what does a Linux desktop offer that's not also natively offered in Mac and also highly polished?
I use Mac OS X and this is what I miss about Linux:
- Clean package/software management and updates.
- Basic customizability without having to install 3rd party binaries from untrusted sources
- Multiple filesystem support (NTFS write not supported out of the box... needing 3rd party software... ext support has to be compiled, breaks with updates... generally PITA)
- Easy installation of software/libraries from source (generally PITA to set up toolchain to compile general cross platform open source software)
- Proper desktop environment (the one that OS X has is shit compared to Gnome)
- Proper file manager (the one that OS X has is shit compared to Nautilus)
- Up to date and standard command-line tools (The ones in OS X are old... for example check the version of unzip... they can't unpack zip files created by new zip tool)
- Better command line system wide file search (I love mlocate, the one in OS X is shit)
I prefer a great deal plastic to environmental foe aluminium. To me their use of aluminium is a very good reason not to buy Apple hardware. I have a Dell M3800 right now, and the build quality is very good. Thin, light, excellent 4K touch screen, good battery life, I easily added a second HDD to it. Not to mention that every thing works perfectly well under Linux.
I'm pretty sure that the answer comes down to one word: Superfish.
Although, in my opinion, I wouldn't trust any laptop hardware company out there enough to use the system that came pre-installed with it, but that's for another discussion.
There has been a string of things, including Superfish.
There was also the Lenovo Solution Center problem. And the Lenovo BIOS shenanigans (or was it the Lenovo Service Engine?).
There have just been too many lapses in judgement at Lenovo. Either their competence is slipping or their ethics are. Either way, I'm done with them for now.
Right! This whole thread has me scratching my head.
Not long ago Microsoft schemed to stomp out Linux and now they've had a change of heart? Fuck Microsoft! To this day even they engage in anti-competitive bundling with OEMs, not to mention their seedy history in relation to open source.
I would LOVE to ditch OS X and run Linux on it, only problem is NO DISTRO supports latest hardware. There are always things that don't work and it gets tiring.
I tried to run Ubuntu on my old Dell Laptop... there would always be some issues related to graphics card, wifi or some shit, overheating, battery drain... or something not working. At the end, had to go for Windows with Ubuntu on vagrant boxes and Desktop Ubuntu in Virtualbox.
Then on my new Macbook Pro, I wanted to run Ubuntu 14.04... but of course, so many things don't work... like right clicking on the touch pad, WiFi or such simplest of features you'd expect to be supported in such widely available and pretty standard hardware... but NOPE. So, it's vagrant and Virtualbox running mostly Ubuntu on OS X again. I am actually considering installing Windows and running Linux on a VM inside it.
Go to a brick and mortar electronics store, pick out a laptop that meets your desired specs, and do something realistic with it for a while. There are lots of little things I took for granted about Apple MacBooks that no Windows laptops could match. Touch pad, high dpi display, and cooling were never quite done right, but they are crucial for every day operations.
I'm with you on the touch pad, three-finger touch-drag in particular is something I've not found a PC do well; my PCs' scroll simulated scroll momentum is also buggy (scroll, stop scrolling, Ctrl+click to open new tab, messes up the font size instead because it's still stimulating mouse wheel movement)
I'm surprised to hear someone preferring macbooks cooling though, my macbook always gets so hot relative to other laptops
I would suggest not trying to source quality hardware from an electronics store. For software development, Thinkpads more then compete with MacBooks, the keyboard is considerably better too.
I know of no language runtime and ecosystem that has better cross-platform support than Node (hm ok maybe Java also). I develop solely on Windows (I just like it better) and virtually all of NPM just works on my box. Even stuff people never tested elsewhere than on their Macs, it just works. Express, webpack, mocha, phantomjs, it's really quite impressive if you ask me.
99% of the painful Node stuff on Windows comes down to native packages. To even compile, you have to install Visual Studio. Then you have to hope the module developer has a build definition that even works for Windows.
Correct! The last time I wanted to npm-install a CLI but it needs gyp, I'm not familiar with the node thingy and I gave up after several failed attemps including installing the VC++ runtime, Python, etc....
node-gyp, though. In my experience, it's the native packages that cause problems, which is honestly to be expected because building a native library for Node to bind to in a cross-platform way is always going to be somewhat painful.
I agree. I'm (mostly) a Windows user, and the one reason I'm constantly thinking of moving to OSX as my primary OS is the amount of command-line tooling that is available in the system. Everything new is always there first. I've started feeling that I was holding back by staying on Windows, even if using Mingw daily.
This might be the thing that saves Windows as a dev machine for me. I'm a heavy cmd/powershell user but I'd migrate to bash in an instant.
> I'm constantly thinking of moving to OSX as my primary OS is the amount of command-line tooling that is available in the system. Everything new is always there first.
Having had OS X, Windows, and various Linux distributions as my primary operating systems I would consider having an Arch Linux VM kicking around if you want all the packages in the world, maintained fairly well.
I've done so in the past, but it becomes cumbersome to manage shared folders. The ability to have everything shared and your driver naturally working under /mnt/ - essentially replacing cmd with bash and its tools - is a big deal for me. Using editing/managing/design tools in Windows build with a build/deploy system in bash, and no middle man... that'd be the day.
Me too - but why not a Linux VM or a VPS? Its mostly for textual usage, no?
(My own answer is that cheap VPSes are 150ms away from me, and with Virtualbox I had a few problems, always related to Windows file permissions yada yada yada...)
Same. At some point managing permissions and sharing and VMs just becomes a pain. If I can just drop to bash and access my file system... that's all I need/want.
this, so many people that develop OSS do so on mac laptops because it's so easy to get the toolchain working, with real linux binaries in windows it's making the value proposition of the surface book a lot stronger for developers.
Its actually kind of interesting that we dont have a literal "standard base" of tools that any OS should supply.
(unless I am missing something)
But it would make sense that certain things should be doable on literally any computer. grep, find, vi, edit, etc... etc... I cant come up with a complete list - but it would be great to start that direction.
We have exactly what you're talking about. It's called POSIX.
"The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems." (https://en.wikipedia.org/wiki/POSIX)
microsoft is leveraging FOSS Linux to get Mac users. I think it's a real smart move.
Apple leveraged a form of BSD -nix to get developer mindshare. Now Microsoft is leveraging FOSS Linux to leapfrog Apple. It is a smart move. While OS X isn't bad for -nix-like development, it still involves jumping through hoops and compromises. (Homebrew/Macports)
The thing I'm wondering is how it will handle launching daemons. It doesn't look like there's systemd or upstart integration, and without something like screen it quickly becomes a hot mess.
I strongly suspect that you will never see systemd working on the Windows NT kernel. Getting systemd to work doesn't just involve supporting the Linux kernel system calls, but also involves getting what those system calls do to work as well. It's all very well supporting open(2), but if one cannot open (say) /proc/self/mountinfo or all of the stuff under /sys or many other things (some listed at http://0pointer.de/blog/projects/the-biggest-myths.html), then systemd might load but it won't run and work.
The same goes for upstart. For example: upstart uses pseudo-terminals for logging. The Windows NT Linux subsystem, according to the Microsoft demo video, doesn't implement pseudo-terminals and returns ENOENT when a program attempts to obtain one.
Then there's the fact that the Windows NT Linux subsystem doesn't run Linux programs as the first process in the entire system. That honour goes, of course, to Windows NT's own Session Manager. Both systemd and upstart have "Am I process #1?" checks, and operate in a non-system mode if they aren't process #1.
Which brings us on to the fact that Windows NT already has a mechanism for launching daemons. It already has a Service Control Manager that supervises daemons and that talks LPC to control utilities. It already has a Session Manager that handles initialization, shutdown, and sessions. Ironically, it has had some of the things that are "new" in systemd for roughly a quarter of a century. (But some of those "new" things aren't even new in the Linux and Unix worlds, really.)
It's worth observing that the approach taken by the old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one) is to run daemons under Windows NT's own Service Control Manager. There is a small shim (psxrun.exe) for ensuring that the Service Manager could run and control the POSIX program, doco on what environment a POSIX program should expect when run under the Service Manager, and an Interix version of the service(1) command that understands Windows NT service management and how to speak to it.
It would be interesting to see how some of the daemontools family of service management toolsets -- such as nosh, runit, perp, daemontools-encore, and s6 -- fared on the Windows NT Linux subsystem. I suspect that one would trip over unexpected holes in the Windows NT Linux subsystem (like setuidgid not working because the underlying system calls return EPERM, perhaps). But I also suspect for several reasons that quite a lot would work. The daemontools family uses FIFOs and ordinary files as ...
- The hardest part of running bash and other posix things under windows is filesystem access. Windows uses drive letters and backslashes, unix has a root filesystem with forward slashes. It seems they are taking the same route as cygwin by "mounting" windows drives in /mnt/c (or /cygdrive/c).
- If you just wanted bash and some posix tools, the harder but nicer way would be to patch them to understand windows paths. It is not clear to me that it is even possible, for example many tools assume a path that does not start with a slash is a relative path - while "C:\" is absolute. You would also want to make more windows apps understand forward slashes like "C:/Windows". To make things even more complicated, there are NT native paths "\Device\HarddiskVolume4\Users\Bill", UNC paths "\\Server\share", and the crazy syntax "\\?\C:\MyReallyLongPath\File.txt".
- I am really surprised this works in an appx container. From my little dabbling with modern apps in Visual Studio, I've found that they are incredibly sandboxed - no filesystem access unless you go through a file picker, no network connections to localhost (!?), no control of top-level windows, no loading of external DLLs. You can get around most restrictions for sideloaded apps, but not for windows store apps. That they can now package such a complex application as a modern app (with maybe only the linux subsystem DLLs delivered externally) means that they are slowly moving the modern/universal apps and traditional Win32 apps together with regards to their powers.
- Running a Linux kernel in windows, and then ELF executables on top (without virtualization) is nothing new, see CoLinux or andLinux. If I understand correctly, this new work uses a new Linux NT subsystem. It remains to be seen if this is better (more performant) or worse (if the Linux kernel is just another process, and it crashes, it doesn't take down the system).
- If they actually wrote a NT subsystem for Linux, this opens a whole can of GPL licensing worms, as you'll need to include internal NT headers. However, they say it is closed source, so I wonder how they did it.
- This really stands and falls with how well it is integrated in the rest of the system. I want to install tools in "Ubuntu" via apt and use them from cmd.exe, and vice versa. And long term, a X11/Wayland bridge would be nice too.
I expect they implemented a subsystem for Linux at the syscall level - i.e. they implemented the Linux kernel's interface at the ABI level. No headers would need to intermingle with open source; compile on Linux, run on Windows.
Not only did NT have a POSIX subsystem, but once upon a time I used it (when it was packaged as SFU, Services for Unix). It wasn't a pleasant experience.
This will have been quite a bit more work than just a POSIX layer, IMO; POSIX defines a bunch of low-level functions that lie just under the C runtime library, but Linux defines a bunch more that expect a certain view of the world - things like clone(2), which lets you selectively choose what the forked process gets to inherit. POSIX only specifies fork(2). Linux implements fork(2) in terms of clone(2). And POSIX defines the API at the level of C; this will have had to implement the Linux ABI, where it differs from Win64. A minor detail of a bunch of assembly stubs, but work nonetheless.
I still use SUA every day when I'm forced to use Windows. (I also run Linux binaries on BSD.)
SUA is based on an old version of BSD, not GNU. tcsh, csh and sh. The compiler works. There is an old version of lex. For some of the userland, Windows binaries are provided, such as vi. It's better than nothing.
Why did MS remove SUA from Windows 10? What harm would it do to remain an optional add-in as it was in Windows 7?
Why do users have to upgrade to Windows 10 to use Linux binaries? Seems like Microsoft will do _anything_ to get users to upgrade. What are the privacy implications of Windows 10? Microsoft is very untrustworthy.
Will users be able to run their own Linux binaries on Windows?
Windows has never been a "pleasant experience". It's the unpleasantness of it that makes the alternative, UNIX, so appealing.
... but is too outdated to be capable of bootstrapping clang. There's very probably a long chain of bootstraps that would achieve it, but there's not a direct route.
> Will users be able to run their own Linux binaries on Windows?
The answer to that is easily determined from the demo video that Microsoft published. In it, Russ Alexander compiles a program with (Ubuntu binary) GCC and and runs it.
Its implicit int in the declaration of main() was jarring. (-:
In my experience the differing perception of pleasure, certainly with the Interix-derived Windows NT POSIX subsystem rather than the original one, is usually a result of the toolset being BSD rather than GNU. I don't have much trouble with the BSD toolset, myself, especially when switching between Windows and an actual BSD. (-:
In addition to the fact that a number of the "Does this new subsystem ...?" questions are answerable as "No; but the old POSIX subsystem did." (https://news.ycombinator.com/item?id=11416392) the POSIX subsystem has some stuff that we're simply not going to get with a Linux subsystem that has vanilla Linux binaries including libraries right down to the system call level. There are things that only come by adjusting libraries and binaries, because they are above the raw system call level. The POSIX subsystem integrates the user account database access library routines with the Windows SAM, for example. So "ls -l" shows the actual Windows usernames. The POSIX subsystem also comes with a "service" command that understands and can work with the SCM, for another example.
I'd like to see the POSIX subsystem reintroduced. It's a major reason not to use Windows 10.
NT shipped w/ a POSIX subsystem. Later, Microsoft acquired Interix (https://en.wikipedia.org/wiki/Interix), a more fully-featured POSIX subsystem. I have fond memories, in the late 1990's, of running GNU tools on NT under Interix.
> It's like everyone forgot there was such a thing as SFU/SUA
Well, it's not like Microsoft made much of an effort to remind people. It was discontinued as a separate project after about Windows XP. It continued to be part of Windows Server[1], but AFAIK, it was no longer present in the client versions.
[1] at least until 2008 or 2008 R2, I didn't check later versions.
Microsoft implemented a minimal POSIX subsystem in Windows NT 3.1 as a checklist feature because at the time some government procurement rules required POSIX compatibility. They didn't expect anyone to actually use it and it was so limited that you couldn't really use it for much in practice.
They actually do syscall translation on the fly from Linux to Windows. I suppose they had to add some calls to Windows for things in Linux that did not exist on Windows (various console ioctls for e.g.) but it is still a one to one translation.
From the screenshots, it seems there is a full kernel in there - e.g. you have /proc/cpuinfo, and it identifies as Linux 3.4.0.
If they just implemented all Linux syscalls on top of NT, that would replace a Linux kernel. There would be no Linux kernel running on top. But in that case they would also need to emulate stuff like /proc. (This is the "reverse Wine" scenario.)
So I personally think it is either:
- There is no new subsystem, this is just a linux.exe running the Linux kernel as a process, like CoLinux does
or
- There is a new subsystem. One way to do this is to port Linux to a new "architecture", namely the NT HAL. You'd call into the NT native API from the linux kernel, which would mean you'd have to put the headers with the native APIs you use under the GPL.
Speaking from experience working on the LX brand (the Linux emulation layer for Joyent SmartOS), we would not have gotten very far with our emulation layer if we did not also faithfully emulate quite a lot of /proc. For example:
$ grep DESC /etc/lsb-release
DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"
$ uname -a
Linux kappa 3.13.0 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux
$ wc -l /proc/cpuinfo
608 /proc/cpuinfo
$ /native/usr/bin/uname -a
SunOS kappa 5.11 joyent_20160204T173314Z i86pc i386 i86pc
There is no need to use actual Linux code to implement its interface, so no GPL'ing of NT, and implementing /proc is not a big deal compared to other things.
And this seems to be implemented as an NT subsystem, which makes tons of sense.
There is a link to a full demo someone posted here [1].
They don't run the linux kernel at all. That /proc/cpuinfo is a part of a limited subset from what procfs usually offers. They enter their linux compatible "subsystem" via a bash binary, which could probably be any linux elf binary, since they run them unmodified. So, it looks like they actually implemented most of the syscalls with some of them emulating necessary parts of linux environment, like procfs.
FreeBSD's linux compatibility layer does exactly this; it reports as "Linux", there's a linprocfs implementation that provides a Linux /proc, etc.
It's a lot easier to emulate syscalls than it is to do something like CoLinux. Additionally, I can't imagine Microsoft would EVER let GPL'd Linux code into their kernel.
> It seems they are taking the same route as cygwin by "mounting" windows drives in /mnt/c (or /cygdrive/c).
I wonder if this Unix filesystem layer will be able to break the Windows legacy path length limit. If so, the Linux version of Node.js will suddenly become much more useful than the Windows version.
> It remains to be seen if this is better (more performant) or worse
Sounds like performance, at least, will be better. TFA says "it's totally shit hot! The sysbench utility is showing nearly equivalent cpu, memory, and io performance." I'll reserve judgment until I see the fork() benchmarks. :)
The "maximally flat" package structure in npm 3 solves the problem in most common cases, so I suppose "much more useful" was an exaggeration - if you keep your code in a relatively short base directory such as C:\src\nodeprojects\left-pad-ng\, you'll probably be fine.
Depending on what version ranges dependencies are locked to, you could still end up with a pathological situation which breaks the path length limit, but I've only had that happen once since switching to npm 3, and it was easy to resolve.
The problem is that the Win32 user mode system will fight you every step of the way: CSRSS will not understand what you just did, for example. It's not generally worth it.
I'm pretty sure I saw something in one of the articles that mentions they explicitly use the extended \\?\ form of paths, which gets around the 255 character path limit.
Just to verify, watched a video that explicitly said that it does get around the path limit (though if you then go look at those files in explorer, explorer "has problems" whatever that means).... but that's just because explorer still uses the legacy APIs that do have a path limit.
Well the very first thing I'd do is symlink/junction point that to something like C:\Users\<User>\Linux or even C:\Linux if I feel particularly single-user.
1) Linux has won the server (web) market. Developers would like to use a Unix box to work on their server code so they typically move to OS X. This could prevent that switch because they can still use Windows to developer their Linux server software.
2) Many projects start out as Linux and stay Linux and are only ported after much time and effort to Windows. Enterprises when faced with a tool that they want to use will also look to switch off Windows. Now rather than the cost of switching they only have to pay to upgrade their windows boxes to use the tool.
3) There is now a major incentive for developers to only build Linux binaries because it will work more places. This might cause a faster drain of developers as they eventually remove all windows specific code and can more easily migrate elsewhere. This feels eerily similar to the OS2 story and no doubt in the next week I expect to see more than a few articles discussing this very thing.
4) It will be much easier for Microsoft to bring much loved Linux tools to Windows so you can expect to see a more rapid increase of tools announced that now work for Windows.
5) Games: What about the graphical layer? Can I write the majority of my game as a Linux binary and only have the rendering bit left over to separately implement for Linux/Windows? Will this spur an increase of cross platform games?
Your first point describes me exactly (and many other developers I know). I grew up a Windows user, and switched to OS X because of the unix-like command line environment that more closely matched the servers I was working with in my job environments.
I would most likely switch back to Windows as my primary/only machine (because I also like to play video games sometimes) if I had the same kind of unix-like command line environment that I get in OS X.
Right now I basically need 2 computers at home to meet all my needs, but this would allow me to reduce it to one, so I could get a much better one (instead of the 2 mid-range ones I have now).
> I grew up a Windows user, and switched to OS X because of the unix-like command line environment that more closely matched the servers I was working with in my job environments.
Out of curiosity, why would you not just go with a Linux desktop for that?
I'm not that guy but I followed a similar path. For me, there is no laptop that truly competes with the MBP and runs Linux with no issues (I've never liked Thinkpads). The recent Dell XPS Dev model is the only product that has come close, but before that there was basically nothing.
I always use Linux for desktops., I see no reason not to.
Not the OP, but for me at least I did. And it was unstable and didn't work very well. My OSX laptop "just works", that isn't to say it doesn't have issues but the amount of time I spend futzing about because of driver issues, sound issues or wifi issues is drastically reduced.
I'm not who you asked, but because I like to spend my day debugging my terrible code, not my desktop.
Before you ask, yes I do have a Linux laptop (Acer C720P ChromeBook, unlocked with Debian + Gnome), and with all the sudden issues that pop out of seemingly nowhere (my latest dragon is a recurrent kernel module crash that can fill my disk up with .core files in 10 minutes), I've switched back to a 13" rMBP. Though, I have heard that 2016 is going to be the year of the Linux Desktop...
Measuring Linux maturity by chromebooks is silly though. It's a hack. Linux on bare metal works really well these days. Especially if you use a machine that has linux in mind (ie dell xps).
I briefly tried switching to Ubuntu on my desktop a few months ago after being unable to compile some CUDA project on Windows. Gave up after spending several hours trying to figure out why it refused to set one of my monitors to anything other than 1024x768. Linux is easily the best operating system for productivity, but there are still too many issues to make it as comfortable as OSX or Windows for everyday use.
I'm also not him, but I switched to OS X for a while, too. I couldn't afford a MacBook, so I actually ran a Hackintosh.
The reasons were 1) it ran the unixy stuff I needed for university AND modern games at the same time, and 2) it was boring and conservative. In a time where Linux and Windows were changing and breaking (Windows 8, Gnome 3, ...) it was nice to use something stable, well-tested, and polished.
Because OS X has historically been vastly better than Linux at all the non-server stuff, and comes pre-installed on the good laptops. The gap is a lot smaller than it used to be, but Apple is still the easiest choice for desktop/laptop Unix.
Same history here. I did actually use Linux for quite a while but ultimately gave up because Linux just isn't good at the one job only an operating system can do, which is to make the hardware available in a reliable and efficient manner.
I just got tired of fixing sound issues, trying to make a scanner work or investigating CPU states to fix heat and battery draining issues on yet another laptop. Ultimately, I think, all of this is a result of the unresolved issue of who should write and test device drivers.
It doesn't help that I disagree profoundly with the prevailing package management philosophy of Linux distributions, but that is a comparably superficial problem that can be worked around.
> Linux just isn't good at the one job only an operating system can do, which is to make the hardware available in a reliable and efficient manner.
It's not the best desktop environment out there, but apart from desktop, linux is the most popular system at every step from small embedded systems to the most powerful supercomputers. That wouldn't be the case if it couldn't make hardware available in a reliable and efficient manner.
It's not the most popular system on phones, unless you are using "Linux" in the correct sense to mean the kernel. But I believe GP was using it in the colloquial sense to mean GNU/Linux, since this thread isn't really about the Linux kernel, but the ""Linux"" userland.
Android certainly doesn't have the userland that is typically (incorrectly) called Linux.
The parent was specifically talking about making hardware available for use. That's kernel stuff, not GNU userland.
But if you want to talk about userland, then you need to buy supported equipment. OSX doesn't work with a ton of equipment out there - as that equipment does not come with OSX drivers. Windows also works like shit when it doesn't have the drivers - anyone who has had to install XP regularly will quite happily attest to just how terrible it is at supporting network cards before you install drivers.
Then, of course, there's the bonus of the AMD Catalyst driver installer program for windows: at least as recently as win7, if you didn't have drivers for video, it fell back to VGA graphics. The Catalyst driver installer was too large to be seen on VGA - you couldn't see the bottom of the installer window to see what was going on, and couldn't drag the window high enough without a hard-to-discover key chord. :)
The argument to "buy stuff your operating system supports" sounds like a cop-out, but it really isn't. OSX, for example, is difficult to make run on things other than Apple-designed computers, but if you complained about it, people would write you off as an idiot.
I was speaking in the context of the question I was replying to, which was "why would you not just go with a Linux desktop for that?"
More specifically, it's the state of Linux device drivers and integration testing for laptops and consumer peripherals I'm complaining about. That's not a result of any inherent deficiency of the Linux kernel or its design. It's ultimately an economics issue.
That's anecdata. Of course it can work the other way too. I've got a printer/scanner which "just works" with Linux. On Windows however they need crazy, proprietary driver/application which always lives in the traybar and tries hard to take over native windows settings.
Sure, that's what this whole thread is about. But I'm afraid that there is causality involved that we know about without collecting any sample data at all.
Developers of Linux device drivers for consumer devices quite often do not have access to all the hardware and information they need. And hardware makers quite often do not make high quality Linux device drivers for their consumer devices. For most consumer laptops, the vendor will not do integration testing to make sure everything works well together on Linux.
I don't think the right response to that is to deny that the average laptop or peripheral will work better with Windows. The right response is to make it clear that you have to make very deliberate hardware choices if you plan to use Linux and accept that much of the hardware you can use is always going to be slightly dated. And that is in fact what many Linux advocates are saying.
Choosing a Mac also restricts your hardware choices quite dramatically after all, so if a broad selection of hardware is your goal, Windows is the only game in town.
In the same boat: I bought an MacBookPro bacause I wanted a nice (new) machine with a decent keyboard/touchpad that didn't force me to purchase Windows. And the keyboard and touchpad on these things are phenomenal.
Or maybe they don't need a bunch of proprietary software? I've been running Linux on all of my desktops for the past few years, and I don't find myself wanting anything more. When doing research, working on free software, etc. I don't need anything I can't get on Linux. I don't play games anymore, so that basically removes most of the "Linux on the desktop" issues that people have.
It depends on what you do. It's terrible for media things, but it's the best OS for programmers and I don't have to go along with every UI trend Microsoft/Apple are implementing this week.
That being the opposite of my experience. While we're making bland sweeping gestures, I have been having it easy developing on Linux (specifically Bodhi with Moksha DE) while fixing my partner's Windows PC every week because it fails constantly. Hell, Windows can't seem to go from location A to B and change networks without a meltdown. It's an awful OS with awful usability, a file explorer that is awful to use and a file system that makes development feel like physical pain.
There, now we're even. Let's get back to EEE, and the real porblems and advantages with this news.
For my desktop.. it does non worky things. For example I Zwift and I Game. Neither work well enough in Linux.
For my laptops... always had linux laptop problems. Sometimes have gotten really close to all the way working.. but then maybe I will find out my battery drains in 2 hours because some power saving feature is broke in my kernel and I cannot be arsed to go fix it, rather just buy a macbook.
Now for this vs macbook.. it depends how next macbook line looks. I need a 32GB ram laptop. If Apple skips that ship again, this will start to look pretty dang appealing.
Because when i switched to OS X - over 10 years ago - I still needed access to Photoshop, MS Office and other modern business tools, most of which are still not available on Linux to this day.
And also because the user experience of OS X (and the "just works" aspects of the OS in general) is far above that of any Linux desktop.
This absolutely represents my case. I bought a MBP just because unix-like command line. IF Windows would provide a this feature at that moment (and giving the case this thing work as intended) I mostly probably would bought an XPS laptop.
On a practical level, this doesn't change anything for games. Anyone writing games for Linux is already using cross-platform tech like SDL or OpenGL or Allegro, or one of the many increasingly popular high-level engines.
Well, I guess it'll be easier to port roguelikes which use ncurses.
I'm really hoping this allows me to compile LibreOffice on Windows. Perhaps if I worked out how to incorporate the WINE libraries it might make my life easier...
It means I need to install Visual Studio. Right now I'm only developing on Mac OS X and Linux. On top of this, every time Microsoft updates Visual Studio, things like firebird tend to break :(
I'd rather use a toolchain I know better. In fact, I'd love to use clang on Windows.
I mean, sure, but (unless things have changed dramatically in the many years since I was a Windows dev) you don't have to do anything more than install VS. The compilers and nmake can be used without opening the GUI. IIRC, you can feed a VS project file (or -I'm pretty sure- a solution file) to nmake and get the same result you'd get from loading the GUI and pressing build.
Ah, shit. I couldn't remember if the damn thing was called msbuild or nmake. [0] I guess one should replace all instances of nmake in my comment with msbuild.
[0] I do know that they are both parts of the VS build tooling. ;)
Non-trivial audio is still difficult to do cross-platform. You can load songs in SDL, but it's not suitable for writing something like a tracker. There's a library coming through libsoundio that looks promising for cross-platform, but it's still early days - I haven't been able to get it to compile yet.
I wouldn't expect (commercial) games to use this, even indies. Gamers (on Windows) are extremely harsh if you ship a buggy product, and this tends to be what happens for most linux ports. Gamers on linux are more forgiving since it's very hard to guarantee quality on linux, so they're more used to it. I'd be surprised if anybody wants to give that up on windows.
> - If you just wanted bash and some posix tools, the harder but nicer way would be to patch them to understand windows paths. It is not clear to me that it is even possible, for example many tools assume a path that does not start with a slash is a relative path - while "C:\" is absolute. You would also want to make more windows apps understand forward slashes like "C:/Windows". To make things even more complicated, there are NT native paths "\Device\HarddiskVolume4\Users\Bill", UNC paths "\\Server\share", and the crazy syntax "\\?\C:\MyReallyLongPath\File.txt".
One of the good things about using "newer" languages than C for building cross-platform utilities[0] is that things like that come baked in[1].
> Windows uses drive letters and backslashes, unix has a root filesystem with forward slashes.
Windows also has mountpoints. When I use a Windows system, I pretend that C: is the only drive, and mount external volumes under the root, Unix-style. I then install Cygwin in the C:\ root, creating the illusion of a fairly Unix-ish filesystem layout.
The forward slash (/) as a directory separator has always been acceptable to NT. One source says that it's been acceptable to DOS since DOS 2.0, although I don't have a lot of backing on that.
The only place that / as a directory separator doesn't work is when interpreted by cmd, as it's then ambiguous with DOS-style switches. And even then, modern cmd tries to understand / properly when possible. Most of the time it works as long as it is not the first character of a path (which you would not frequently see in Windows anyway), as there's then no way to tell it apart from a switch with a long name.
The canonical representation of paths in Windows uses a backslash, but 95% of the time the slashes are interchangeable.
IIRC (it's been a while), the native NT API does _not_ accept backslashes; win32 converts forward slashes to backslashes when passing along filenames to NT. The distinction doesn't matter very much, though, since very few people use the NT native API.
Regarding the AppX thing... Actually AppX packaged apps (even from the Store in AppContainer) have always had direct filesystem access, but only from their install directory and to/from their AppData directories. It's only access outside those areas which requires use of the picker and/or library capabilities (which both go through a broker process).
They can also of course load DLLs, and there are APIs for moving your app Windows around (with some limitations).
That said, I do not know exactly what they're doing here, and it may be using some new capabilities being added to the system in the rs1 release.
"The hardest part of running bash and other posix things under windows is filesystem access. Windows uses drive letters and backslashes, unix has a root filesystem with forward slashes. It seems they are taking the same route as cygwin by "mounting" windows drives in /mnt/c (or /cygdrive/c)."
How do these ubuntu tools interact with the rest of the windows system that they are running on ?
Can I 'kill -9 explorer.exe' ?
Can I touch a file in /mnt/c/(whatever)/Desktop ... and have that file actually show up on my windows desktop ?
PIDs from Windows are not exposed when looking at /proc, so I am guessing you will not be able to `kill -9 explorer.exe` unless there is some real voodoo going on (and then it would not be POSIX compatible, anyways).
I think the command that you meant to say was killall :) `kill` will only kill pids, not process names.
This was one of the selling points of the old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one) over its predecessor. Programs such as "ps" and "kill" can "see" Win32 processes, with POSIX process IDs.
From the Scott Hanselman link posted elsewhere in this comment thread:
> Note that this isn't about Linux Servers or Server workloads. This is a developer-focused release that removes a major barrier for developers who want or need to use Linux tools as part of their workflow.
It helps Canonical deploy Linux on the server in places that refuse to run Linux on the desktop, since Microsoft has said they're not interested in replacing Linux on the server with lxss on the server. This is absolutely good for certain subsets of the "Linux community" with certain motivations and ideologies. (And awful for others, of course.)
How is it a bad idea? It's a step to making Linux a more viable platform for software to target and makes life easier for a subset of application developers who already target Linux. I'm sure there will be a few people who would otherwise switch to Linux entirely and may not now, but I would expect this to do more good than harm to Linux.
Basically, Ubuntu steam rolls the other distributions in terms of reach. My guess, looking at previous Visual C++ posts about a gdb extension [0], and them asking about CMake projects [1], is that Visual C++ will support seamless building, and debugging of Linux programs. This then makes it super easy for developers to develop an Ubuntu binary.
Having a large number of people developing on Ubuntu, may increase the demand for Ubuntu Server (with support where the real money is). I really only see an upside for Canonical.
I hear you
they think its a good thing everyone i know says now no need to stay on linux i'm switching to windows 10 at least my colleages are doing so now
Well we are close. But I thought the 1st of April idea was to make the joke on 1st and reveal it after that date. Not to make a joke in March and tell people it was a joke on 1st of April...
A performant fork - the single biggest problem with Cygwin - sounds awesome. As does the ability to run Linux binaries directly, opening up the direct use of binary package repos.
I wonder if I can use it via mintty instead of conhost.exe; at the very least, I could ssh into it from Cygwin.
As always, the devil is in the details; the rough edges where support peters out, or syscall inconsistencies creep in.
I'm reading between the lines, but it looks like the linux subsystem is using a separate file system. So you'll have the usual problems when using files from /mnt/c, but other files are mounted in a unixy file system of some sort. The Ubuntu file system is mounted onto your Windows subsystem at C:\Users\<user>\AppData\Local\Lxss\rootfs\, according to the article.
I'm guessing you are right. The usual problems with /mnt/c. I was wondering about rootfs being per user as well. On a server that may be a problem, but perhaps not on a laptop. It sounds like this is not meant to be the basis for production level deployments, but useful for development.
By default, but you can tell Cygwin to use /c/ though. Really handy when you switch between the two, and actually makes more sense (what else would be /c/ ?)
If nothing else, based on the capabilities demonstrated so far, you should (theoretically) be able to run local Linux X client apps to a Windows X server over localhost TCP. You'll miss out on a few optimisations available when using shared memory, but not much.
I'm with you. Interesting novelty, but I would absolutely not bank on doing anything missions critical with this. Wait 5 years for the excitement to die down and lets see if the team stuck maintaining this is even going to be around anymore. Are they committing to keeping the syscall translation layer up to date with changes in later kernels, etc? Or is this going to turn into another 'You can run Android apps on Windows!' announcement that fizzles out after they realize how much work they've gotten into...
932 comments
[ 3.0 ms ] story [ 484 ms ] thread2. Extend can be good if done openly and collaboratively, as opposed to closed and hidden.
3. Extinguish - Here be dragons.
I'm hopeful the New Kinder Gentler Microsoft stays on steps 1. and 2. (done collaboratively).
Decades of history, and their own self-interest.
>Fact is you have no idea
Sure I do. They've acted this way for decades, under various different management. To think they're suddenly going to become some nice, ethical company is sheer lunacy.
>and all signs point to a more open MS that has learned that simply throwing their weight around won't work anymore.
What signs? I haven't seen any. They've done stuff just like this before, and it always turned out badly.
The company would be worse off if they do not stick to this direction and start backstabbing. It is bad enough that companies are legal persons, let's not anthropomorphize them even more into irrational evil villains that hold grudges.
I find it amazing that you can have such a functional Ubuntu environment by translating system calls. Microsoft does have the advantage of Linux being open-source I suppose, while the Wine project had to reverse engineer DLLs. Or have you supply them on your own.
It could be an updated version.
Its ironic (old)microsoft exerted so much effort to put the personalities in place (OS/2, posix etc), then (mid)microsoft systematically destroyed that work under Balmer, and now (new)microsoft are reimplementing the same thing under a (seemingly) completely different system.
I was interested in that too, since I write Unix utilities and it is sometimes useful to have them work on Windows as well. I've done that (checked that it worked on Windows) with a few utilities in the past (written in C), that did not use any very Unix specific features that were not present on Windows. And remember reading around that time that Windows (I think it was from NT onwards) had a POSIX subsystem.
Then more recently, as in, a few months ago, I wanted to check that out again, and did. IIRC I read (maybe on a Wikipedia page) that the POSIX subsystem is not present in Windows any more.
"Windows NT was designed from the start to have modular subsystems. It was most infamously used to provide a POSIX subsystem which really only checked boxes on government acquisition forms. :-)"
https://news.ycombinator.com/item?id=11391290
Thanks. :)
Here's the famous Linus Tech Tips 7-in-1 video: https://www.youtube.com/watch?v=LXOaCkbt4lI
You aren't running them "side by side"... you are running them "One inside the other".
Not exactly an apple-to-apple comparison.
Not having a unified filesystem, not having a unified window manager, etc are quite some issues.
Source: I use my VM only for gaming, and it’s a horrible experience.
Also, you can share directories between the native filesystem and the VM quite easily. And if you're using something like VirtualBox or VMWare there are "unity" windowing modes available.
I tried them – they don’t work at all in KDE.
Arch linux host, KDE as DE, Windows 10 Guest, just leads to a big black box in unified mode, and windows don’t properly occur in the KDE taskbar.
What I expect is integration equal to WINE – automatically putting stored data into the correct folders, easily accessible and mounted, integrating windows with the taskbar, etc.
And yes, this is "just for games" – but try gaming on a multiscreen setup when the game doesn’t show up in your taskbar and you can’t minimize it.
With WINE, everything works fine – but not with UPlay.
So I can run the game, via UPlay in the VM (but not unified mode), or I can pirate it and run it in WINE.
But unified mode, or paid in WINE, doesn’t work.
Apple needs to do a utility that supports this as smoothly as Bootcamp supports multiple boot.
And you can also buy $5 USB sound card and have no issues at all. Or spend few bucks more and connect PCI sound card.
While it seems like it is worth Microsoft's time to keep people on Windows.
I for one look forward to having all my vulnerabilities in one place... Linux, windows, server, desktop...
Crossover is probably the best you'll get: https://www.codeweavers.com/products/crossover-linux
Otherwise, if you only need Windows to game, I'd highly suggested PCI Passthrough so that you can use your GPU in a Windows VM: https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...
Are there any Windows only server applications that would be useful in a non windows shop? I'm not trying to be snarky, I really can't think of any.
I would expect the most likely users to convert would be those using job specific desktop software.
More correctly would be to say that Microsoft has advantage of user space libraries used in GNU/Linux distributions being open-source. Linux kernel itself being GPL2 is probably a problem for Microsoft's developers because of possibility to be accidentally exposed to it while researching documentation.
One team to document, one team to implement based on that document.
https://en.wikipedia.org/wiki/Clean_room_design
[1] https://en.wikipedia.org/wiki/Chinese_wall
This is common in reverse engineering stuff.
I didn't see any information about whether they do it using direct system call translation, or if they do it using shared library inter-positioning. In either case, its pretty cool!
FreeBSD has been able to do this (with some limitations!) for years:
https://www.freebsd.org/doc/handbook/linuxemu.html
The reason WINE went with the library emulation route is because: (a) the Windows kernel doesn't have a stable system call layer, and (b) the Win32 API is massive anyway.
Windows has an easier time emulating Linux at the very lowest levels because Linux has an ABI stable system call layer. If you emulate those, you can run ANY Linux binary.
It also means Microsoft doesn't have to ship or support hundreds of Open Source projects. They ship the syscall layer, and distributions ship the user layer.
Ah, so that was the rationale. I always found that subsystem curious.
http://cowlark.com/lbw/
It's a Linux syscall translator for Windows. It works well enough to run a Debian userland, although it's got so many holes and rough edges that I would never, ever, ever suggest using it for anything other than a stunt.
It uses Interix to do most of the heavy lifting, so all LBW does is to translate from Linux syscalls to Interix syscalls; so we get a Unix filesystem and user permissions and sockets and fork etc for free. (Interix was great. I'm glad they're bringing it back from the dead.) Unfortunately not all the system calls directly map onto each other; so Interix has a native fork(), but Linux emulates with clone(). I couldn't make threads work.
A few of the biggest problems were:
- the Windows page size is 64kB; the Linux page size is 4kB. The ld.so loader will try to map two bits of executable within the same 64kB boundary, and, of course, this doesn't work on Windows. I crudely hack around it by allocating pages of RAM and copying things. Write-back mapping only works at all if the application lets mmap() pick the address.
- very very very different register usage. glibc on Linux uses gs as a 'pointer' to the current thread's private data area, via a special syscall. Windows resets gs to 0 on every interrupt! I crudely hack around this by intercepting null pointer dereferences, looking at the instruction to see if it was gs, and then reloading it with the right value.
- even then, that syscall sets gs to point at a GTD segment with a size of 2^32; this wraps round the entire address space, which allows very large offsets in gs to be treated as negative numbers. Windows doesn't let you create GTD segments. It only allows LTD segments, and it caps the segment limit to the end of the user address space, so this trick won't work. I crudely hack around this by intercepting segmentation violations, looking at the instruction to see it it's a [gs+negative number] dereference, and then binary patching the executable to use a different instruction.
- glibc is horrible and undocumented. There's a big pile of key-value strings pushed onto the stack above the environment when the process is initialised, containing various magic numbers. ld.so will just crash if you get this wrong. I spent a lot of time reverse engineering the ld.so source code to figure out what these were and how to set them up.
It was all vile and horrible, but it worked surprisingly well (i.e., it worked, which was surprising).
Using the NT kernel's personality system to implement Linux syscalls natively is totally the right thing to do; that's obviously what they're doing here.
I would love to know about the internal Microsoft politics which made releasing this possible. I wonder how long it's been brewing? I did LBW in about a month of evenings; the core logic wasn't hard. I wouldn't be at all surprised if this hasn't been floating about inside Microsoft for years.
* https://news.ycombinator.com/item?id=11391841
... would you agree with a call for it to be?
1) Linux has won the server (web) market. Developers would like to use a Unix box to work on their server code so they typically move to OS X. This could prevent that switch because they can still use Windows to developer their Linux server software.
2) Many projects start out as Linux and stay Linux and are only ported after much time and effort to Windows. Enterprises when faced with a tool that they want to use will also look to switch off Windows. Now rather than the cost of switching they only have to pay to upgrade their windows boxes to use the tool.
3) There is now a major incentive for developers to only build Linux binaries because it will work more places. This might cause a faster drain of developers as they eventually remove all windows specific code and can more easily migrate elsewhere. This feels eerily similar to the OS2 story and no doubt in the next week I expect to see more than a few articles discussing this very thing.
4) It will be much easier for Microsoft to bring much loved Linux tools to Windows so you can expect to see a more rapid increase of tools announced that now work for Windows.
Although, as others have already pointed out, it differs in some very significant ways.
OS/2 2.x providing Win16 binary compatibility was an after-market system providing binary compatibility with applications made for the operating system that shipped "out of the box". Whereas this is the operating system that ships "out of the box" providing binary compatibility with applications made for an after-market operating system.
(Yes, yes. One could buy OS/2 pre-installed, and one can buy Ubuntu Linux pre-installed. The scale of that, in both cases, is nowhere near significant enough to change the basic fact that overall the two situations are the reverse of each other.)
Also: There was not the extent of existing tools available natively on both platforms, in the OS/2 case. The examples being waved around in the news now are things like Apache, Ruby, Node, and so forth. There wasn't the OS/2-and-Win16 analogue of (say) the Ruby developers deciding in the months to come that a Win32 port is too hard to maintain, and dropping it in favour of just running the Linux Ruby on the Windows NT Linux subsystem. Today's analogue of the OS/2 case would be a universe where there was no Win32 Ruby at all, and the Ruby developers deciding not to start making a Win32 version because the Linux one "is good enough for the few Windows users".
I suspect that drawing parallels based upon what happened with OS/2 2.x and Win16 is a mistake, and those thinking that this will mean an outflux of Windows development "because it happened with OS/2 2.x" (which was more like an influx of development that failed to happen) are indulging in wishful thinking.
There's also the minor matter that, during the OS/2 2.x and Win16 time, there was this little thing called Windows NT lying around, promising a route for OS/2 1.x, where the existing tools were, with its OS/2 subsystem. (It is ironic that we are once again looking at a Windows NT subsystem.) That has no equivalent this time around at all; unless one mis-casts UbuntuBSD (https://news.ycombinator.com/item?id=11326457) in that rôle. It doesn't really fit, though. "Look, all you people with Ubuntu Linux application softwares. Forget that minority Windows thing that you ported to a couple of years ago. Come bring your applications to this new FreeBSD instead." (-:
> Can open the Windows Start menu
> And type "bash" [enter]
> Which opens a cmd.exe console
Right... Bash is a shell, but your interaction with it is controlled by a terminal program. Unless there are some real changes to cmd.exe t̶h̶e̶n̶ ̶i̶t̶'̶s̶ ̶n̶o̶t̶ ̶t̶h̶a̶t̶ ̶i̶m̶p̶r̶e̶s̶s̶i̶v̶e̶ . You can compile a native bash and other utils now yourself, it's not that hard.
EDIT: It's more like a Linuxulator from BSD, which is certainly cool.
If a fully-compatible terminal emulator doesn't exist yet (I have no idea) I bet there will be one within a year.
https://github.com/Maximus5/ConEmu
With a real pty, you'd be able to use any Windows console program with mintty, sshd, Emacs term-mode, or whatever else you wanted, transparently. I regret not having a chance to finish that work.
This has been up since the turn of the century:
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/ca...
The demonstrators in the Microsoft video do warn that they will be avoiding some of the holes of the system in their demonstration. One is very briefly visible at 08'13", before the demonstrator rapidly clears the screen (again), when they run apt-get to install git:
The new Windows NT Linux subsystem apparently doesn't have pseudo-terminals.The old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one) has pseudo-terminals with both BSD and System 5 access semantics, in comparison.
* https://technet.microsoft.com/en-gb/library/bb497016.aspx
* https://technet.microsoft.com/en-gb/library/bb463219.aspx
Moreover, a Windows console window that is the controlling TTY of a POSIX program in that subsystem has the POSIX cooked input mode with local echo, and generates escape sequences for extended keys.
Also cmd.exe on Windows 10 does support line breaks in copied text from what my minor test just showed.
In pervious versions you could always use another console like Console2, but now it's built in (although the third party options still have more features than the new built in one).
There actually have been [1], and I imagine MS has continued to flesh out those improvements.
[1]: https://news.ycombinator.com/item?id=11046433
Does that mean I can do "apt-get install nginx" from their new "bash" terminal app? Does that then run under port 80 in Windows? Since no VM is involved.
I'm still a bit confused.
Yes, they demonstrated that localhost is the same localhost under both environments.
% uname -srm FreeBSD 10.3-RELEASE amd64 % /compat/linux/bin/bash bash-4.1$ /bin/uname -srm Linux 2.6.32 i686 bash-4.1$ /bin/uname -a Linux viserion 2.6.32 FreeBSD 10.3-RELEASE #0 4b75b72(releng/10.3): Fri Mar 25 19:14:5 i686 i686 i386 GNU/Linux bash-4.1$ cat /proc/cpuinfo | grep 'model name' | head -1 model name : Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
I don't want or need a Linux ABI, I just want to run a Linux container on Windows (if I have to use windows, which I would prefer not to do).
If node running on windows needs access to a database running on the Linux layer then what happens when things aren't working? They can't possibly make all programs interact in a seamless way.
I'm imagining frankenstein programs that are hacked together with code that only works on this frankenstein OS.
https://github.com/nodejs/node/blob/master/src/node_os.cc#L5...
Microsoft probably hard-codes a response of "Linux" (or whatever would be normal for Ubuntu) for that call to prevent Ubuntu binaries from freaking out.
When files are manipulated through the Win32 subsystem they are (normally) opened in "deny delete" mode (i.e. without passing FILE_SHARE_DELETE to CreateFile and thence to NtCreateFile). But that's Win32 programs and language runtime libraries explicitly setting the sharing mode flags that they like, not an inability of the Windows NT kernel that is below the Win32 subsystem, nor even an inability of the Win32 subsystem itself.
* https://msdn.microsoft.com/en-gb/library/windows/desktop/aa3...
If the Ubuntu on Windows personality/subsystem gave Linux processes full permissions to /mnt/c, I'd expect that would be a security vulnerability, and I'd assume they are doing some mapping. Unfortunately, in the video they posted I never see them do `ls -l` on `/mnt/c`, only a subdirectory they created.
Nowadays, the most common use I've seen is as the Windows implementation of 'npm link' for Node.js developers.
This has been done before with other x86 OSes: FreeBSD has had 32-bit ABI compatibility for at least a decade (https://www.freebsd.org/doc/handbook/linuxemu.html), and the "lx branded zone" for Solaris has it as well (https://docs.oracle.com/cd/E19455-01/817-1592/gchhy/index.ht...).
But it's alive and well (and awesome) in SmartOS, with active work going on to merge it into OmniOS, and eventually will be upstreamed to illumos-gate.
Longer. I was using linux binary compat, in FreeBSD, to run the linux version of vmware workstation back in 2001.
It has always been very well done, and as you can see, not just running 'cat' or 'echo' linux binaries ... but full blown commercial software packages.
I had Windows XP running, as a dev environment, within the Linux version of vmware workstation, on my freebsd laptop. Worked great.
There was an oft-repeated claim in those days (the days of FreeBSD 4.x) that linux binary compat in FreeBSD would run linux binaries faster than linux would.
I ordered a surface pro 4 and planning to run i3 in a VM with my existing nixOS configuration. I wonder how this news will affect my workflow.
I have emacs running as a systemd service and client emacs connecting to it, so it's quite a killer combo for development.
apt, ssh, rsync, find, grep, awk, sed, sort, xargs, md5sum, gpg, curl, wget, apache, mysql, python, perl, ruby, php, gcc, tar, vim, emacs, diff, patch...
to do with Ubuntu?
I believe that that was also true for AmigaDOS, even the post-Commodore versions, but I don't have the firsthand knowledge to state it unequivocally.
I hate it. I bet Stallman, Ken Thomson, the GNU Project, Bell Labs and many others are crying and laughing at the same time.
We live in a world built upon the previous one, as the previous was already was. Some things we forget, others become lore, folklore, myths, and others are lost... It is similar to Facebook providing Internet. Or Dropbox providing 'rsync'. Maybe one day the common man will rediscover plaintext and the command line interface. And the then hipsters will use it.
Some links:
- find http://doc.cat-v.org/unix/find-history
- grep https://medium.com/@rualthanzauva/grep-was-a-private-command...
- cp https://news.ycombinator.com/item?id=8305283
- wget https://en.wikipedia.org/wiki/Wget#cite_note-13
- AWK was created at Bell Labs in the 1970s, and its name is derived from the family names of its authors – Alfred Aho, Peter Weinberger, and Brian Kernighan. ~ https://en.wikipedia.org/wiki/AWK
- http://www.cryptonomicon.com/beginning.html
BONUS:
- https://wiki.ubuntu.com/DashAsBinSh
Google Cache: https://webcache.googleusercontent.com/search?q=cache:http:/...
What if you read the welcome screen, Mr. Scott ;) ?
Edit: And cow fork only makes sense if there is memory over-commit. So to be fully featured it would need a separate memory subsystem with memory over-commit.
Solaris doesn't have VM over-commit either, and few people would claim it's not a fully featured UNIX.
The author points to using grep and Xargs and some other tools to quickly update a package. That's the key here. These bash/Linux utilities are productivy boosters for all the Linux and Mac/bsd people out there. I can't imagine living without them and they're necessary for any system I develop on (which is currently a Mac).
For devs that do heavy Linux work (but have stuck with a Mac OS for GUI/app reasons), is it time to move (back) to Windows? If so, what would be a good laptop to get at the moment?
I'm personally using a Dell XPS 13 (2014), soldered in RAM, but I did buy an ultraportable and 8GB is more than sufficient to do my all my personal work on. Work supplied me with a Lenovo W540 that is substantially more flexible, but it weighs as much as a couple bricks and I usually just leave it at home on the dock.
And it's pretty damn light for a 15" laptop. Easily one-handable (I think it's like 2 pounds IIRC).
And what's great is that you can crack it open and replace stuff - I swapped out the hard drive and replaced a malfunctioning battery myself with just a torx screw driver (super tiny torx, but still, no glue or special tools or anything).
It was pretty expensive - like $1900 IIRC. You're paying for the high res screen, better build quality, and thinness/lightness. But it's still like $500+ less than an equivalent macbook.
Every year I try a switch to Linux desktop. This year I made it as far as trying to get multiple monitors working well. I also dabbed in gaming. In the end I went back to my work=Mac game=Windows duopoly.
The whole python ecosystem is also better on Linux overall.
Anything strictly desktop-oriented is better on OSX of course.
A GNU userland. A plethora of tiling window managers. A selection of clean terminals. Every single thing Debian's or Arch's repos offer which one must turn to brew for.
And of course there's freedom too, which is nice.
> Every year I try a switch to Linux desktop. This year I made it as far as trying to get multiple monitors working well.
I've got multiple monitors running on Linux, over HDMI, at home & at work, at differing resolutions & orientations. I use arandr-configured xrandr scripts which set my desired orientation with a quick keystroke in my window manager. What more does one need?
Better Desktop environment Better Package Management More Up to date packages
Some of my knowledge of OS X is likely outdated I haven't used it since 2011
I started using Linux when I was at University late 90's early 00's (Mandrake was my first distro). I switched to OS X around 2005 and used it as my primary operating system for about 5 years.
I used OS X because I'd purchased a MacBook Pro (mostly for the hardware) I still think Macbooks are the nicest laptops I've used to this day I went through 3 iterations of Macbooks before I stopped using OS X. I used OS X because it was good enough but I never fell in love with it.
I absolutely hated the desktop environment, silly things like no ability to customise anything, lack of workspaces, having to hit command q to kill application (because the 'x' button wouldn't close them properly) stuff like that. Workspaces came in a later OS X update which addressed some of my gripes.
It was never easy to install third party packages and libraries in OS X. I think this has improved now, when I used OS X it it was a mess (especially compared to the ease of something like apt). The native system packages were always really ancient - old version of GCC, old version of emacs, python etc. Trying to install newer version of these 'default' packages was not straightforward at all I remember having huge issues getting python 3 working.
Nowadays I run Fedora very happy with it. Not compelled at all to switch back. Linux support for modern laptops is a lot better than it was when I first started using Macs.
My current job is in an 'enterprisey' environment I'm forced to use a locked down version of windows here. Almost anything would be better.
Freedom, a full GNU userland, proper package management of the entire system, plethora of CLI programs which can fulfil your every need and only really work on GNU/Linux, configurable, etc.
> Every year I try a switch to Linux desktop. This year I made it as far as trying to get multiple monitors working well. I also dabbed in gaming. In the end I went back to my work=Mac game=Windows duopoly.
I use multiple monitors every day for my work under OpenSUSE and Arch. They both worked with either minimal (Arch) or no (SUSE) configuration. I use DisplayPort which works pretty well.
I use Mac OS X and this is what I miss about Linux:
- Clean package/software management and updates.
- Basic customizability without having to install 3rd party binaries from untrusted sources
- Multiple filesystem support (NTFS write not supported out of the box... needing 3rd party software... ext support has to be compiled, breaks with updates... generally PITA)
- Easy installation of software/libraries from source (generally PITA to set up toolchain to compile general cross platform open source software)
- Proper desktop environment (the one that OS X has is shit compared to Gnome)
- Proper file manager (the one that OS X has is shit compared to Nautilus)
- Up to date and standard command-line tools (The ones in OS X are old... for example check the version of unzip... they can't unpack zip files created by new zip tool)
- Better command line system wide file search (I love mlocate, the one in OS X is shit)
- Ability to run docker natively
If I were buying a Windows machine, the only one I would consider is the Microsoft Surface Book.
What? The M3800 had terrible battery life under Windows and it was even worse under Linux.
Although, in my opinion, I wouldn't trust any laptop hardware company out there enough to use the system that came pre-installed with it, but that's for another discussion.
There was also the Lenovo Solution Center problem. And the Lenovo BIOS shenanigans (or was it the Lenovo Service Engine?).
There have just been too many lapses in judgement at Lenovo. Either their competence is slipping or their ethics are. Either way, I'm done with them for now.
Why not just use Linux? It has a GUI. It has apps. It does everything a modern desktop or laptop needs to do. It really is great.
Not long ago Microsoft schemed to stomp out Linux and now they've had a change of heart? Fuck Microsoft! To this day even they engage in anti-competitive bundling with OEMs, not to mention their seedy history in relation to open source.
I would LOVE to ditch OS X and run Linux on it, only problem is NO DISTRO supports latest hardware. There are always things that don't work and it gets tiring.
I tried to run Ubuntu on my old Dell Laptop... there would always be some issues related to graphics card, wifi or some shit, overheating, battery drain... or something not working. At the end, had to go for Windows with Ubuntu on vagrant boxes and Desktop Ubuntu in Virtualbox.
Then on my new Macbook Pro, I wanted to run Ubuntu 14.04... but of course, so many things don't work... like right clicking on the touch pad, WiFi or such simplest of features you'd expect to be supported in such widely available and pretty standard hardware... but NOPE. So, it's vagrant and Virtualbox running mostly Ubuntu on OS X again. I am actually considering installing Windows and running Linux on a VM inside it.
I'm surprised to hear someone preferring macbooks cooling though, my macbook always gets so hot relative to other laptops
I know of no language runtime and ecosystem that has better cross-platform support than Node (hm ok maybe Java also). I develop solely on Windows (I just like it better) and virtually all of NPM just works on my box. Even stuff people never tested elsewhere than on their Macs, it just works. Express, webpack, mocha, phantomjs, it's really quite impressive if you ask me.
This might be the thing that saves Windows as a dev machine for me. I'm a heavy cmd/powershell user but I'd migrate to bash in an instant.
Having had OS X, Windows, and various Linux distributions as my primary operating systems I would consider having an Arch Linux VM kicking around if you want all the packages in the world, maintained fairly well.
(My own answer is that cheap VPSes are 150ms away from me, and with Virtualbox I had a few problems, always related to Windows file permissions yada yada yada...)
Nothing beats running and developing on localhost.
(unless I am missing something)
But it would make sense that certain things should be doable on literally any computer. grep, find, vi, edit, etc... etc... I cant come up with a complete list - but it would be great to start that direction.
Also, why gnu and not bsd? OS X's find, grep, sed, and so on work fine for me and are not gnu.
"The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems." (https://en.wikipedia.org/wiki/POSIX)
Apple leveraged a form of BSD -nix to get developer mindshare. Now Microsoft is leveraging FOSS Linux to leapfrog Apple. It is a smart move. While OS X isn't bad for -nix-like development, it still involves jumping through hoops and compromises. (Homebrew/Macports)
* https://news.ycombinator.com/item?id=11391961
* https://blogs.windows.com/buildingapps/2016/03/30/run-bash-o...
I strongly suspect that you will never see systemd working on the Windows NT kernel. Getting systemd to work doesn't just involve supporting the Linux kernel system calls, but also involves getting what those system calls do to work as well. It's all very well supporting open(2), but if one cannot open (say) /proc/self/mountinfo or all of the stuff under /sys or many other things (some listed at http://0pointer.de/blog/projects/the-biggest-myths.html), then systemd might load but it won't run and work.
The same goes for upstart. For example: upstart uses pseudo-terminals for logging. The Windows NT Linux subsystem, according to the Microsoft demo video, doesn't implement pseudo-terminals and returns ENOENT when a program attempts to obtain one.
* http://upstart.ubuntu.com/cookbook/#console
* https://news.ycombinator.com/item?id=11415843
Then there's the fact that the Windows NT Linux subsystem doesn't run Linux programs as the first process in the entire system. That honour goes, of course, to Windows NT's own Session Manager. Both systemd and upstart have "Am I process #1?" checks, and operate in a non-system mode if they aren't process #1.
Which brings us on to the fact that Windows NT already has a mechanism for launching daemons. It already has a Service Control Manager that supervises daemons and that talks LPC to control utilities. It already has a Session Manager that handles initialization, shutdown, and sessions. Ironically, it has had some of the things that are "new" in systemd for roughly a quarter of a century. (But some of those "new" things aren't even new in the Linux and Unix worlds, really.)
It's worth observing that the approach taken by the old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one) is to run daemons under Windows NT's own Service Control Manager. There is a small shim (psxrun.exe) for ensuring that the Service Manager could run and control the POSIX program, doco on what environment a POSIX program should expect when run under the Service Manager, and an Interix version of the service(1) command that understands Windows NT service management and how to speak to it.
* https://technet.microsoft.com/en-us/library/bb463219.aspx#EH...
* http://systemmanager.ru/svcsunix.en/extfile/portapps/service...
It would be interesting to see how some of the daemontools family of service management toolsets -- such as nosh, runit, perp, daemontools-encore, and s6 -- fared on the Windows NT Linux subsystem. I suspect that one would trip over unexpected holes in the Windows NT Linux subsystem (like setuidgid not working because the underlying system calls return EPERM, perhaps). But I also suspect for several reasons that quite a lot would work. The daemontools family uses FIFOs and ordinary files as ...
- Wow, hell is really freezing over!
- The hardest part of running bash and other posix things under windows is filesystem access. Windows uses drive letters and backslashes, unix has a root filesystem with forward slashes. It seems they are taking the same route as cygwin by "mounting" windows drives in /mnt/c (or /cygdrive/c).
- If you just wanted bash and some posix tools, the harder but nicer way would be to patch them to understand windows paths. It is not clear to me that it is even possible, for example many tools assume a path that does not start with a slash is a relative path - while "C:\" is absolute. You would also want to make more windows apps understand forward slashes like "C:/Windows". To make things even more complicated, there are NT native paths "\Device\HarddiskVolume4\Users\Bill", UNC paths "\\Server\share", and the crazy syntax "\\?\C:\MyReallyLongPath\File.txt".
- I am really surprised this works in an appx container. From my little dabbling with modern apps in Visual Studio, I've found that they are incredibly sandboxed - no filesystem access unless you go through a file picker, no network connections to localhost (!?), no control of top-level windows, no loading of external DLLs. You can get around most restrictions for sideloaded apps, but not for windows store apps. That they can now package such a complex application as a modern app (with maybe only the linux subsystem DLLs delivered externally) means that they are slowly moving the modern/universal apps and traditional Win32 apps together with regards to their powers.
- Running a Linux kernel in windows, and then ELF executables on top (without virtualization) is nothing new, see CoLinux or andLinux. If I understand correctly, this new work uses a new Linux NT subsystem. It remains to be seen if this is better (more performant) or worse (if the Linux kernel is just another process, and it crashes, it doesn't take down the system).
- If they actually wrote a NT subsystem for Linux, this opens a whole can of GPL licensing worms, as you'll need to include internal NT headers. However, they say it is closed source, so I wonder how they did it.
- This really stands and falls with how well it is integrated in the rest of the system. I want to install tools in "Ubuntu" via apt and use them from cmd.exe, and vice versa. And long term, a X11/Wayland bridge would be nice too.
Can't find any substantial writings on this, but it seems likely.
This will have been quite a bit more work than just a POSIX layer, IMO; POSIX defines a bunch of low-level functions that lie just under the C runtime library, but Linux defines a bunch more that expect a certain view of the world - things like clone(2), which lets you selectively choose what the forked process gets to inherit. POSIX only specifies fork(2). Linux implements fork(2) in terms of clone(2). And POSIX defines the API at the level of C; this will have had to implement the Linux ABI, where it differs from Win64. A minor detail of a bunch of assembly stubs, but work nonetheless.
SUA is based on an old version of BSD, not GNU. tcsh, csh and sh. The compiler works. There is an old version of lex. For some of the userland, Windows binaries are provided, such as vi. It's better than nothing.
Why did MS remove SUA from Windows 10? What harm would it do to remain an optional add-in as it was in Windows 7?
Why do users have to upgrade to Windows 10 to use Linux binaries? Seems like Microsoft will do _anything_ to get users to upgrade. What are the privacy implications of Windows 10? Microsoft is very untrustworthy.
Will users be able to run their own Linux binaries on Windows?
Windows has never been a "pleasant experience". It's the unpleasantness of it that makes the alternative, UNIX, so appealing.
... but is too outdated to be capable of bootstrapping clang. There's very probably a long chain of bootstraps that would achieve it, but there's not a direct route.
> Will users be able to run their own Linux binaries on Windows?
The answer to that is easily determined from the demo video that Microsoft published. In it, Russ Alexander compiles a program with (Ubuntu binary) GCC and and runs it.
Its implicit int in the declaration of main() was jarring. (-:
In my experience the differing perception of pleasure, certainly with the Interix-derived Windows NT POSIX subsystem rather than the original one, is usually a result of the toolset being BSD rather than GNU. I don't have much trouble with the BSD toolset, myself, especially when switching between Windows and an actual BSD. (-:
In addition to the fact that a number of the "Does this new subsystem ...?" questions are answerable as "No; but the old POSIX subsystem did." (https://news.ycombinator.com/item?id=11416392) the POSIX subsystem has some stuff that we're simply not going to get with a Linux subsystem that has vanilla Linux binaries including libraries right down to the system call level. There are things that only come by adjusting libraries and binaries, because they are above the raw system call level. The POSIX subsystem integrates the user account database access library routines with the Windows SAM, for example. So "ls -l" shows the actual Windows usernames. The POSIX subsystem also comes with a "service" command that understands and can work with the SCM, for another example.
I'd like to see the POSIX subsystem reintroduced. It's a major reason not to use Windows 10.
Well, it's not like Microsoft made much of an effort to remind people. It was discontinued as a separate project after about Windows XP. It continued to be part of Windows Server[1], but AFAIK, it was no longer present in the client versions.
[1] at least until 2008 or 2008 R2, I didn't check later versions.
Thanks for the info!
If they just implemented all Linux syscalls on top of NT, that would replace a Linux kernel. There would be no Linux kernel running on top. But in that case they would also need to emulate stuff like /proc. (This is the "reverse Wine" scenario.)
So I personally think it is either: - There is no new subsystem, this is just a linux.exe running the Linux kernel as a process, like CoLinux does or - There is a new subsystem. One way to do this is to port Linux to a new "architecture", namely the NT HAL. You'd call into the NT native API from the linux kernel, which would mean you'd have to put the headers with the native APIs you use under the GPL.
Armchair kernel development is fun :-)
And this seems to be implemented as an NT subsystem, which makes tons of sense.
They don't run the linux kernel at all. That /proc/cpuinfo is a part of a limited subset from what procfs usually offers. They enter their linux compatible "subsystem" via a bash binary, which could probably be any linux elf binary, since they run them unmodified. So, it looks like they actually implemented most of the syscalls with some of them emulating necessary parts of linux environment, like procfs.
[1] https://sec.ch9.ms/ch9/5db6/8ee786b7-9fc5-45bf-94d0-16ea9176...
It's a lot easier to emulate syscalls than it is to do something like CoLinux. Additionally, I can't imagine Microsoft would EVER let GPL'd Linux code into their kernel.
I wonder if this Unix filesystem layer will be able to break the Windows legacy path length limit. If so, the Linux version of Node.js will suddenly become much more useful than the Windows version.
> It remains to be seen if this is better (more performant) or worse
Sounds like performance, at least, will be better. TFA says "it's totally shit hot! The sysbench utility is showing nearly equivalent cpu, memory, and io performance." I'll reserve judgment until I see the fork() benchmarks. :)
Depending on what version ranges dependencies are locked to, you could still end up with a pathological situation which breaks the path length limit, but I've only had that happen once since switching to npm 3, and it was easy to resolve.
The problem is that the Win32 user mode system will fight you every step of the way: CSRSS will not understand what you just did, for example. It's not generally worth it.
MAX_PATH in Windows = 260
Path to Linux file system root from Windows user space:
"C:\Users\<user>\AppData\Local\Lxss\rootfs\" - about 45 chars
Max depth reachable from Windows user space = 260 - 45 = 215
1) Linux has won the server (web) market. Developers would like to use a Unix box to work on their server code so they typically move to OS X. This could prevent that switch because they can still use Windows to developer their Linux server software.
2) Many projects start out as Linux and stay Linux and are only ported after much time and effort to Windows. Enterprises when faced with a tool that they want to use will also look to switch off Windows. Now rather than the cost of switching they only have to pay to upgrade their windows boxes to use the tool.
3) There is now a major incentive for developers to only build Linux binaries because it will work more places. This might cause a faster drain of developers as they eventually remove all windows specific code and can more easily migrate elsewhere. This feels eerily similar to the OS2 story and no doubt in the next week I expect to see more than a few articles discussing this very thing.
4) It will be much easier for Microsoft to bring much loved Linux tools to Windows so you can expect to see a more rapid increase of tools announced that now work for Windows.
5) Games: What about the graphical layer? Can I write the majority of my game as a Linux binary and only have the rendering bit left over to separately implement for Linux/Windows? Will this spur an increase of cross platform games?
I would most likely switch back to Windows as my primary/only machine (because I also like to play video games sometimes) if I had the same kind of unix-like command line environment that I get in OS X.
Right now I basically need 2 computers at home to meet all my needs, but this would allow me to reduce it to one, so I could get a much better one (instead of the 2 mid-range ones I have now).
Out of curiosity, why would you not just go with a Linux desktop for that?
I always use Linux for desktops., I see no reason not to.
I would never go back to windows but would happily move back to linux if I had to
EDIT: I should note I didn't expect to like my Macbook air so much (fantastic machine)
Before you ask, yes I do have a Linux laptop (Acer C720P ChromeBook, unlocked with Debian + Gnome), and with all the sudden issues that pop out of seemingly nowhere (my latest dragon is a recurrent kernel module crash that can fill my disk up with .core files in 10 minutes), I've switched back to a 13" rMBP. Though, I have heard that 2016 is going to be the year of the Linux Desktop...
The reasons were 1) it ran the unixy stuff I needed for university AND modern games at the same time, and 2) it was boring and conservative. In a time where Linux and Windows were changing and breaking (Windows 8, Gnome 3, ...) it was nice to use something stable, well-tested, and polished.
https://news.ycombinator.com/newsguidelines.html
I just got tired of fixing sound issues, trying to make a scanner work or investigating CPU states to fix heat and battery draining issues on yet another laptop. Ultimately, I think, all of this is a result of the unresolved issue of who should write and test device drivers.
It doesn't help that I disagree profoundly with the prevailing package management philosophy of Linux distributions, but that is a comparably superficial problem that can be worked around.
It's not the best desktop environment out there, but apart from desktop, linux is the most popular system at every step from small embedded systems to the most powerful supercomputers. That wouldn't be the case if it couldn't make hardware available in a reliable and efficient manner.
Android certainly doesn't have the userland that is typically (incorrectly) called Linux.
But if you want to talk about userland, then you need to buy supported equipment. OSX doesn't work with a ton of equipment out there - as that equipment does not come with OSX drivers. Windows also works like shit when it doesn't have the drivers - anyone who has had to install XP regularly will quite happily attest to just how terrible it is at supporting network cards before you install drivers.
Then, of course, there's the bonus of the AMD Catalyst driver installer program for windows: at least as recently as win7, if you didn't have drivers for video, it fell back to VGA graphics. The Catalyst driver installer was too large to be seen on VGA - you couldn't see the bottom of the installer window to see what was going on, and couldn't drag the window high enough without a hard-to-discover key chord. :)
The argument to "buy stuff your operating system supports" sounds like a cop-out, but it really isn't. OSX, for example, is difficult to make run on things other than Apple-designed computers, but if you complained about it, people would write you off as an idiot.
More specifically, it's the state of Linux device drivers and integration testing for laptops and consumer peripherals I'm complaining about. That's not a result of any inherent deficiency of the Linux kernel or its design. It's ultimately an economics issue.
Sure, that's what this whole thread is about. But I'm afraid that there is causality involved that we know about without collecting any sample data at all.
Developers of Linux device drivers for consumer devices quite often do not have access to all the hardware and information they need. And hardware makers quite often do not make high quality Linux device drivers for their consumer devices. For most consumer laptops, the vendor will not do integration testing to make sure everything works well together on Linux.
I don't think the right response to that is to deny that the average laptop or peripheral will work better with Windows. The right response is to make it clear that you have to make very deliberate hardware choices if you plan to use Linux and accept that much of the hardware you can use is always going to be slightly dated. And that is in fact what many Linux advocates are saying.
Choosing a Mac also restricts your hardware choices quite dramatically after all, so if a broad selection of hardware is your goal, Windows is the only game in town.
There, now we're even. Let's get back to EEE, and the real porblems and advantages with this news.
For my laptops... always had linux laptop problems. Sometimes have gotten really close to all the way working.. but then maybe I will find out my battery drains in 2 hours because some power saving feature is broke in my kernel and I cannot be arsed to go fix it, rather just buy a macbook.
Now for this vs macbook.. it depends how next macbook line looks. I need a 32GB ram laptop. If Apple skips that ship again, this will start to look pretty dang appealing.
And also because the user experience of OS X (and the "just works" aspects of the OS in general) is far above that of any Linux desktop.
Well, I guess it'll be easier to port roguelikes which use ncurses.
Is this not helpful?
https://wiki.documentfoundation.org/Development/BuildingOnWi...
LibreOffice has official Windows builds, so I would expect that they can already build the software on Windows.
I'd rather use a toolchain I know better. In fact, I'd love to use clang on Windows.
I mean, sure, but (unless things have changed dramatically in the many years since I was a Windows dev) you don't have to do anything more than install VS. The compilers and nmake can be used without opening the GUI. IIRC, you can feed a VS project file (or -I'm pretty sure- a solution file) to nmake and get the same result you'd get from loading the GUI and pressing build.
[0] I do know that they are both parts of the VS build tooling. ;)
One of the good things about using "newer" languages than C for building cross-platform utilities[0] is that things like that come baked in[1].
[0] - https://github.com/EricLagergren/go-coreutils [1] - https://golang.org/pkg/path/filepath/#IsAbs
Windows also has mountpoints. When I use a Windows system, I pretend that C: is the only drive, and mount external volumes under the root, Unix-style. I then install Cygwin in the C:\ root, creating the illusion of a fairly Unix-ish filesystem layout.
The only place that / as a directory separator doesn't work is when interpreted by cmd, as it's then ambiguous with DOS-style switches. And even then, modern cmd tries to understand / properly when possible. Most of the time it works as long as it is not the first character of a path (which you would not frequently see in Windows anyway), as there's then no way to tell it apart from a switch with a long name.
The canonical representation of paths in Windows uses a backslash, but 95% of the time the slashes are interchangeable.
I can confirm that from personal memory.
At the time, the biggest vendor of UNIX-like systems was Microsoft (Xenix), so compatibility was a benefit. They soon sold that product off, though.
They can also of course load DLLs, and there are APIs for moving your app Windows around (with some limitations).
That said, I do not know exactly what they're doing here, and it may be using some new capabilities being added to the system in the rs1 release.
How do these ubuntu tools interact with the rest of the windows system that they are running on ?
Can I 'kill -9 explorer.exe' ?
Can I touch a file in /mnt/c/(whatever)/Desktop ... and have that file actually show up on my windows desktop ?
I think the command that you meant to say was killall :) `kill` will only kill pids, not process names.
* https://technet.microsoft.com/en-gb/library/bb463219.aspx#EH...
* https://technet.microsoft.com/en-gb/magazine/2005.05.interop...
-It facilitates app cross comparability
-For Canonical, it reinforces the idea that Ubuntu == Linux, which is really good for their bottom line
-I wouldn't be surprised if Microsoft forked over a solid amount of cash
And Microsoft manages to undermine RedHat at the same time. Win-Win for them, why the Linux community should be excited about it, I don't know.
> Note that this isn't about Linux Servers or Server workloads. This is a developer-focused release that removes a major barrier for developers who want or need to use Linux tools as part of their workflow.
It helps Canonical deploy Linux on the server in places that refuse to run Linux on the desktop, since Microsoft has said they're not interested in replacing Linux on the server with lxss on the server. This is absolutely good for certain subsets of the "Linux community" with certain motivations and ideologies. (And awful for others, of course.)
Having a large number of people developing on Ubuntu, may increase the demand for Ubuntu Server (with support where the real money is). I really only see an upside for Canonical.
0. https://blogs.msdn.microsoft.com/vcblog/2015/11/18/announcin...
1. https://blogs.msdn.microsoft.com/vcblog/2016/02/29/developin...
Coming next: Windows 11 will use Linux kernel.
I wonder if I can use it via mintty instead of conhost.exe; at the very least, I could ssh into it from Cygwin.
As always, the devil is in the details; the rough edges where support peters out, or syscall inconsistencies creep in.
Incidentally, I've found the Windows 2012R2 to be my favorite OS for the desktop from the Windows family.
Its the real deal lads, congratulation Microsoft.
* within the probably surprisingly broad limits of the WinLS syscall emulation, though it wouldn't support niche OS config stuff, SELinux calls, etc.
Remember the holy edict of Linux kernel development: you don't break userspace.