Next, please provide a Windows kernel for Linux or other open source operating systems. There are many of us whose biggest frustration running an open source OS is working around Windows executables, Windows only drivers, and Microsoft proprietary file formats.
It's obviously not mounting the NTFS filesystem directly, since it's already in use by Windows, so this is irrelevant to how NTFS is normally mounted in linux.
I can't help but think that this is 10 years too late. I gave up on Windows a long time ago, as did many people I know. I know there are folks who find this valuable, but I think Microsoft is chasing a pool of power users that has been consistently shrinking year-over-year. With that said, perhaps the pool will get bigger as it exposes users to the power of command line :-)
I feel it's actually a bid to lure back developers that code on linux-based open source tools (pretty much everything) but use MacOS because desktop linux never was a thing.
So this starts to potentially make windows an alternative to macOS for developers. I moved to macOS because it was like having a linux/unix distribution that wasn't ugly, and just worked really well.
But I'm more than happy at the _idea_ that there's a viable alternative that allows me to still have high res displays and decent graphics and support, while allowing me to develop on a system that's a first-class citizen for most open source tools (which is Linux).
Unfortunately you will be disappointed by Windows 10's user interface. They have made it ugly and harder to use; mostly partially implemented changes. So Windows 10 UI is still in Alpha it seems. I suggest that you keep your macOS for now. Hopefully they will get the GUI in order soon.
I can't help but think that this is better late than never. Every few years over the last 15, I attempt a move to *nix and every time I am disappointed for various reasons (drivers, package versioning, documentation and support, users experience when not using a command line, etc). However, I am always jealous of the tools available and if MS can bring those to the Windows world, I honestly don't know that I will ever bother looking elsewhere again.
With that said, perhaps the pool will get bigger as it exposes users to the power of command line :-)
Not sure what you mean. Windows has been using PowerShell for almost a decade now as the Bash equivalent "everything at your fingertips" command line tool.
Personal opinion, in many ways PowerShell is more powerful than Bash. It's more verbose, but it's also easier to script.
It's not free of warts (the verbosity is annoying), but I personally find it much more readable than Bash scripts. The support for script modules also helps a lot if you are managing a lot of scripts.
While Powershell is pretty great and I use it all the time, I still think it falls short of Bash in terms of how integrated it is with the rest of the system. The shell is the default way to get things done in Linux but it feels more like a second-class citizen in Windows. This is a shame because there is clearly a lot of good engineering in PoSH.
Nah, integrations to the system are orders of magnitude better then bash. Powreshell is automation standard for basically all MS tools and tools of many other big companies. You can host powershell in your app with 5 lines of code (not something you can easily do with bash).
Its designed to be integrated into everything. When my sysadmin GUI clicks vmWare I open PowerCLI. When my db admin uses networker for backup I use Sql Server Powershell Module. When my web dude clicks in IIS management studio and forgets the click I give him unmistakable ps1 script that crates IIS site and sets it up in 5 lines of code. Its like that forever.
Poweshell is no typical shell - u do business stuff in it, not text parsing all the time like in bash with 0.1% of what you actually want to do.
The thing that i personally miss is exporting config of Windows (control panel and friends) as powershell script(s). Something like DSC (or better, BoxStarter) but for grannies - press Start -> export everything to powershell script -> reinstall -> run ps1 -> run chocolatey -> show FTW sign.
But it isn't. Try managing AD servers using powershell. You have two options. Either the powershell AD module, which is incomplete and doesn't cover the entirety of Active Directory, or you resort to the native .Net API which is ugly and unintuitive when used from a command line.
"When my db admin uses networker for backup I use Sql Server Powershell Module."
Wut? Don't do this. I've used that module and it's fragile as hell. You have to check the arity of your select statements for it to work correctly. I built a data importation integration using it once and once I got tired of it breaking I just caved and rewrote the tool in C# and never had any more trouble.
But none of that's what I'm talking about when I say that it feels like a second class citizen. If you're on a Unixy machine, every tool implicitly runs from within a shell. That means the shell is always available, even from an application. Not so with Windows. In Windows, the .NET API is your world ( or if you're unlucky, the Win32 API) on Linux, it's the shell.
It's kind of in this sense that Powershell isn't really a shell in the sense that Bash is the primary interface to the operating system whereas Powershell is just an interface layered onto other interfaces. I've done enough sysadmin type work in either environment to feel the difference. Powershell is less a primary interface with the system and more a scripting language. As a scripting language, it's pretty fine, I have no complaints about the design. I'd like to think it's pretty close to what I would have come up with had I been tasked to design a CLI for Windows in the mid 2000s, but it doesn't underly the system as deeply as the Unix shells do.
Edit:
For an great concrete example, compare Cron with the Windows Task Scheduler. With Cron, the command language is whatever your shell happens to be. You have a string which specifies the schedule, followed by some shell command which does your task. The shell command can launch a program, start another script, or you might be able to contain it all in the single line. On Windows, you provide the exact path to the program you want to launch and any arguments. That's it. Powershell isn't available. If you want to launch a PoSH script, you have to reference the PoSH executable and provide your script as an argument. It's relatively ugly.
One nice thing about the Cron approach, is that you can provide input redirection for ad-hoc logging or even output suppression, without having to modify your executable. It's a lot more steps to do the same thing on Windows.
I know that Sql Server module sux (MS guys I worked with told me that Sql team didn't quite get it), especially when it automatically changes drive to virtual one upon loading.
But it works, once you know the quirks, or you can find alternative (number of them).
> If you're on a Unixy machine, every tool implicitly runs from within a shell.
Run Windows Core or Nano server and you have the same thing.
Run X Windows and you have th same thing on Linux as on Windows.
> Either the powershell AD module, which is incomplete and doesn't cover the entirety of Active Directory, or you resort to the native .Net API which is ugly and unintuitive when used from a command line.
Many cmdlets are incomplete. Why do you think Linux CLI tools are complete ? Anyway, without any IDE and with just Notepad knowing a bit of .NET you could create yoru own functions where it isn't enough. I do it all the time, here is one link: https://github.com/majkinetor/posh
About ugliness, my God bash is ugly. The code is so ugly that it hurts. I don't even have to translate the C# code in Powershell if I don't want, I can just compile it and execute it from the string from Powershell. Dropping to .NET was never ment to be used on command line - wrap it into nice sugarry function/module.
> For an great concrete example, compare Cron with the Windows Task Scheduler.
Great example, because I like Cron and I hate WTS. The problem is the syntax - cron syntax is easy to learn and remember. WTS can't be specified that easyly, in any case you need to click, use XML, use ughly CLI tools, or incomplete Task Scheduler cmdlets. Also, WTS is full of quirks.
Yeah, typical way is 'here is exe, run it, thats it' or 'powershell -Command/-File' or 'cmd.exe -C ...' (as is with many other linux tools, cron excluded).
Its easy enough to create scripts, for instance this is my replacement for Startup folder:
But there is something more in line with your desires - PowerShell Scheduled Jobs (not Tasks, Jobs) which work as you want it - Powershell itslef manages scheduling.
"Run X Windows and you have the same thing on Linux as on Windows."
No you don't. X Windows is still run from a shell. The Windows GUI, by contrast, is not. Any application run in Linux or Solaris or whatever can drop down to the shell. And if I run an application from a terminal, I can take advantage of that. Not so with Windows.
"Anyway, without any IDE and with just Notepad knowing a bit of .NET you could create yoru own functions where it isn't enough."
I've written PoSH modules before. I'm pretty familiar with the process. I don't know what point you're trying to make.
"Why do you think Linux CLI tools are complete ?"
Because in the Unix environment, the CLI tools have been the primary admin interface for the past 40+ years. In Linux, the CLI comes first and the GUI is an afterthought. In Windows, it's the other way around. If you think that's changing, great. But I work on Windows in my day to day work, and regularly write Powershell so I've got a good feel for the difference.
Powershell has fantastic integration with the system. In additional to be able to interact with .net and com directly, it is now the primary interface for administering server versions of windows.
> gave up on Windows a long time ago, as did many people I know
My impression is just as anecdotal as yours, but it's exactly the opposite. Windows seems to me to be gaining amongst developers, due to a combination of push and pull factors (respectively: Apple's declining hardware and Microsoft's improving software).
I'm a case in point: a few years ago I wouldn't have considered running Windows, but I was driven to trying it in 2018 by Apple no longer making any notebook hardware I was willing to use. Admittedly I'm now largely on Linux, but it's a close call between the two and I could be tempted back.
Yes. The world's most valuable company (market cap) is having an ever-shrinking userbase. I mean, they'll probably be out of business in a year because none of your friends use anything but Linux!
Is this legal? It obviously is, but how? I thought the GPL would require Microsoft to ship the Windows source code? I suppose it counts as a separate component.
> The kernel provided for WSL2 will be fully open source! When WSL2 is released in Windows Insider builds, instructions for creating your own WSL kernel will be made available on Github.
The kernel part will be fully open source, which should be sufficient enough to comply with GPL
> which should be sufficient enough to comply with GPL
this is an age-old debate. Some people say that it is e.g. legal to make (redistribute to precise) a GPL device driver for windows, and some argue that it is not, because the whole kernel should then be GPL.
But in Windows drivers are binary files which talk to the kernel through an API. Not much different than a binary user mode application. If binary user mode applications written in GPL are ok, then so should this.
But the actual syscall is made by a Windows user mode library - kernel32.dll/... So your GPL user mode app calls directly into proprietary Windows library.
Longer guess: I suspect they are doing some fancy virtualization tricks here to service calls directly like they would a VM but in a VERY lightweight manner similar to containers. This fits with other announcements concerning containers that were also made today.
Again this is all supposition without any actual knowledge.
Yes, it is perfectly okay to dynamically link with a GPL component from a proprietary component, as long as that component is remains handled as per GPL.
(You kind of need to be able to use GPL code dynamically to be able to run it from a proprietary OS of any kind in any way.)
> I thought the GPL would require Microsoft to ship the Windows source code?
I'm inclined to think Windows is not a derivative work of the Linux kernel by any remotely tenable legal theory, but anyone with code in the kernel they are shipping willing to take the other side of that bet against Microsoft’s legal team has the option to try.
It hinges on the definition of "derived work" (anything outside derived work is outside copyright's effects, and the GPLv2 uses only copyright to give it effect). Their WSL2 Linux kernel will clearly be a derived work of the Linux kernel, so they obviously will provide full source code of that; the rest of Windows most probably won't.
I use WSL at work and use windows docker as a server... I use docker client form wsl ubuntu and make it connect to the Docker server running on windows. I do the same thing with databases. I’ve grown fond of this approach, as it integrates well with the Services app in windows.
That is not the most secure way to run Docker in WSL - IIRC exposing the Docker socket on localhost lets websites start Docker containers. If you use something like npiperelay [0], you can access Docker from WSL without exposing the Docker socket to everything.
What do you mean by a white list? The connections are coming from local host (from your browser). The fact that they were initiated by code which was downloaded from malware.com is not knowable to docker.
oh wait, you mean from client side javascript? I didn't know you could do that. FWIK, only WebSockets are supported within browsers - let me know if you know of a way otherwise.
I'm pretty sure you can make http POST and GET requests from client side JS, and again IIRC you can start a container in Docker with a single POST - no return info required
CORS applies only to JS code - sites can still issue cross-origin GETs and POSTs via HTML, using Forms for example. Not sure whether there is enough control on the format to actually issue a valid Docker request.
Still, it's generally a pretty bad idea to have an unauthenticated service running on localhost which can perform arbitrary operations on the system - you're depending on all other software running on the system not to transform that into a vulnerability.
It would be nice if they improved their own file system performance. Sidestepping the gap by running a VM gives them less incentive to fix these issues, which are also visible in native Windows applications.
I agree Windows file access is noticeably slower than on other platforms. But it seems like the issue has quite fundamental roots: https://github.com/Microsoft/WSL/issues/873#issuecomment-425.... Add to that Windows Defender scanning, and you have death by a thousand cuts rather than something that could be fixed by a single measure like adopting a faster filesystem.
I used to work at Microsoft doing work that touched filesystem stuff a lot, and every single one of those points was known to me already. But at a certain point they ought to be able to say: the OS is not competitive with the state of the art in this area. It shouldn't matter what organizational or component boundaries create this situation, they should do more to fix it. Blaming the layering is a start I guess, but shouldn't be the end.
Not sure how they could improve filesystem performance, since they have previously explained that the slowness is from going through the Windows FS stack that has hooks at like five different levels. So do they now somehow sidestep the Windows' FS? How would that work?
As they're using a linux kernel, I wonder if they're using an ext4 filesystem for the wsl stuff, hosted in a file image on NTFS? Windows apps could still get access to the wsl files via the 9P file server.
For me it seems that they just abandoned their efforts to implement Linux syscalls and decided to build a GUI for Linux VM. Very similar to their new Edge approach: abandon complex task of building browser engine and just build a GUI for Chromium. That's very different from their original goal to have both Windows and Linux processes work together. I don't think that their WSL 2 will allow Linux process to exec into Windows binary.
For me, personally, it seems like another failure. I don't see any reason not to use Linux in VirtualBox. It's simpler and it works. Their original approach was something new and interesting. Microsoft started to make very questionable decisions lately.
Based on the fact that this seems like a complete change in implementation, I would have to assume that there just wasn't much to write about because people would be focused on 2.
I hope it will be possible to run docker seamlessly without a virtual machine and lots of extra setup once this ships. That will be a big advantage over MacOS where you need to run a fat VM that gobbles your memory and takes time to start-up.
> WSL 2 uses the latest and greatest in virtualization technology to run its Linux kernel inside of a lightweight utility virtual machine (VM). However, WSL 2 will NOT be a traditional VM experience.
If WSL v2 is running VM under the hood, no wonder it will be Hyper-V. We already have such lightweight VM for "Credential Guard/Device Guard" and it already conflicts will any other hypervisor: VMWare workstation [1], VirtualBox. Resolution is to disable Hyper-V, for instance, with command line
bcdedit /set hypervisorlaunchtype off
So most probably WSL v2 will do the same, which means one cannot run WSL v2 and non Hyper-V VMs at the same time, because two different hypervisors can't coexist.
> I guess there is no hope that one will be able to continue to use WSL v1?
Looks like that guess is wrong:
“WSL 2 is a new version of the architecture that powers the Windows Subsystem for Linux to run ELF64 Linux binaries on Windows. This new architecture changes how these Linux binaries interact with Windows and your computer’s hardware, but still provides the same user experience as in WSL 1 (the current widely available version). Individual Linux distros can be run either as a WSL 1 distro, or as a WSL 2 distro, can be upgraded or downgraded at any time, and you can run WSL 1 and WSL 2 distros side by side. WSL 2 uses an entirely new architecture that uses a real Linux kernel.”
AFAIK that does not like VirtualBox 6 works with Hyper-V but it's like running Hyper-V instead of VirtualBox. Therefore there is a lot of compatibility issue.
Eh, I was in this same boat as a VMWare Workstation user -- I haven't upgraded my license recently, and v14 has a number of bugs that are very annoying -- but at this point with tools like Windows Sandbox in 1903, various Hyper-V/Manager improvements, I went ahead and caved and went and enabled HyperV and removed Workstation. The fact HyperV manager can now do easy one-click installs of Ubuntu, etc, is nice.
At this rate -- for my uses, anyway -- I expect Microsoft to update and expand Hyper-V (and Sandbox, and WSL v2) in a much more timely fashion than Workstation, especially considering it's a core technology of theirs (across desktop and also server). On top of that, VirtualBox and QEMU now support the new Hypervisor APIs[1], so Workstation is the odd one out in my mind.
In the end between updating my license and sticking with this, I haven't gone back yet, but we'll see once I put Hyper-V in 1903 through the motions...
[1] I actually recently installed QEMU for Windows, followed some of those Rust OS tutorials, and booted my own disk image in QEMU's graphical mode, using the WHXP mode in QEMU (-accel whxp on Windows, instead of -accel kvm on Linux) and it all worked like a charm. Amazing how well QEMU seems to work these days on Windows.
I'm not sure if it will be Hyper-V? Currently to use Hyper-V you have to have a non-home license for Windows, though maybe they will change that for this.
I hope you don't have to have a non-home license for Windows to run WSL 2, that would be really annoying.
Yes this is quite concerning for users of WSL on non-Azure clouds or on systems like Qubes. Hopefully WSLv1 will continue to be supported in the medium-term - Microsoft have put quite a bit of engineering time behind it.
One reason I've turned off Hyper-V is that I've noticed my CPU either doesn't downclock like normal when Hyper-V is enabled, or the OS doesn't report it as doing so if it actually does. Anyone noticed this? Does Hyper-V affect battery etc. in ways like this?
Translation: "Linux is eating our lunch. If you can't beat 'em, join 'em."
Linux has already thoroughly trounced Windows in mobile (Android). It's done so in the web space. MS still has a strong foothold in enterprise, but it doesn't take a genius to see Linux continuing to expand on at least the backend in enterprise as well.
With more apps being delivered over the web, and web browsers being cross-platform, the desktop choice becomes less OS-centric for rote workers.
I can see this as Microsoft looking into a future where they lose relevance because of ChromeOS eating up the low end and MacOS eating up the high end, and they're left with institutional traction. Which they can coast on for many years, but not forever.
Been using WSL since I switched to a Windows shop and it's a good lightweight alternative. I don't run a lot of the big tasks that I used to but, it's nice to have.
Installing certain apps do tend to be on the slow side so if WSLv2 can resolve this, that would be great news. As for the implementation is concerned, I have no idea what they are talking about.
I’m debating the possibility of moving out of MacOS and just get a Windows 10 Surface device. I don’t mind the Windows UI but feel like WSL may not be adequate for me.
With this rate of change inside MS OS team, I won’t be surprised when one day, Windows would embrace the Linux kernel and just build the UI on top of it. Look at what the IE team does with Chromium. Somehow, I think MS needs to cannibalize its own business (OS or browser) to set itself for a comeback in the near future.
Exactly. Windows 10 is a much better operating system than Linux for a broad range of applications, and the desktop. I develop on Windows 10, and am quite happy using a VM (not WSL) for my Centos development.
Are you talking about desktop applications? Windows 10 like every version of Windows going back to NT is built around a Hardware Abstraction Layer and separates userland from the kernel while providing a platform agnostic API. There isn't anything the Windows kernel can do that the Linux or a BSD kernel can't which is my point. Why spend billions on R&D for something you can get for free? Case in point, MacOS/OSX. Apple figured that out a long time ago and it obviously worked for them.
> There isn't anything the Windows kernel can do that the Linux or a BSD kernel can't
There is, for laptop/desktop: almost all of those run a Windows kernel thus most money for laptop/desktop device driver support is going towards supporting the Windows kernel. Technically... it's a difficult discussion but it's irrelevant. Noone is running a bare kernel.
The Linux Kernel is a 60s era monolithic architecture. Windows 10 is a modern microkernel. So, of course, the Linux "kernel" has more stuff in it. But that means that every driver and feature has to be carefully compiled in. It's no wonder there are far more audio, video, and specialized drivers on Windows 10.
> XNU is not a MicroKernel, it is a kernel obtained by merging the Mach MicroKernel with parts of the BSD kernel and parts specific to Darwin, all running in kernel space.
OKL4 is the most widely deployed pure microkernel in Qualcomm phone modems and Apple's Secure Enclave coprocessor. It is possible OKL4 is the most widespread OS, in fact.
> There isn't anything the Windows kernel can do that the Linux or a BSD kernel can't which is my point.
Oh there is. Like pervasive ACLs on all kernel objects, e.g., processes. User-ids (SIDs) based on a distributed authority model rather than a simple int. Then there's asynchronous IO that's still not usable in Linux. Etc, etc...
What? Why would that be a factor? It's a kernel. Why would it make a difference if the Windows desktop ran on a different kernel? MS has rolled out several different kernels over the history of Windows, why would it be any different? Just like OP mentioned look at MS switching Edge to the Chromium backend. To the user there's isn't a real difference. It's still Edge.
Except most of the unique features of Edge are gone. Maybe not all, but plenty of users will notice a difference in Edge when the Chromium version rolls out.
Plus, word on the street is Microsoft's motivation to move to Chromium was totally different to that: it was a performance decision. Too many apps were using Electron, and the only way to improve their performance was to intregrate it into the OS.
Come on, don't just start spewing a bunch of weasel words. It's fine if you disagree me and I won't downvote you if you do (I never downvote people for that reason) but at least put some effort into it.
> Too many apps were using Electron, and the only way to improve their performance was to intregrate it into the OS.
Well why wouldn't they just build out the Edge backend to be compatible with node.js to natively support the Electron API? Because it a waste of time and R&D money when Chromium does all that already and more with minimal cost. Why reinvent the wheel when you can get a run-flat radial tire for free?
Microsoft sell Windows partly on the promise of backwards compatibility. A Linux kernel would destroy any real backwards compatibility possibilities, with prejudice.
There are 1,000 privately developed and privately run Windows apps for every publicly available application, and those private applications are the backbone of businesses around the world. A Linux kernel would render a VERY large portion of those inoperable, even with WINE.
A Windows with a Linux kernel will never replace traditional Windows. Some Microsoft OS may live alongside traditional Windows, at some point however, and it is unlikely to be Linux at all.
There are lots of kernel architectures out there besides the ones that Linux and Windows use.
The Windows kernel isn't backwards compatible, just the API's which use compatibility libraries and the HAL to interface with the newer kernel. APIs and kernels are 2 different things. Think about the Linux kernel. How to we "talk" to it? Through libraries like glibc which provides an interface for C to make calls to the kernel. Something like WINE wouldn't be necessary. WINE is an open implementation of the Windows API. The WINE project is essentially reverse engineering the Windows API and mapping to the equivalent Linux syscalls. This wouldn't be an issue for MS. All they would have to do is implement a Windows API compatible equivalent of glibc and obviously wouldn't have licensing issues like the WINE project.
> Think about the Linux kernel. How to we "talk" to it? Through libraries like glibc which provides an interface for C to make calls to the kernel.
No. We "talk" to the kernel through an ABI, not an API. Maintaining ABI compatibility is important because you can move a binary from one kernel version to another without recompiling and relinking your app.
Did you see a different Edge developer preview than I did? The Chromium-based Edge that I have looks basically like Chromium. Firefox has a more native look than Dev Edge. But Windows is a bit of a hodge-podge, so maybe the user doesn't care.
I just can't find this happening. Windows primary selling point to the masses is application support. Whether it's games, office software, meidcal software, etc, many people use Windows for this reason. If Windows became just a UI, it would have to compete with Ubuntu/Fedora/etc, which are usable and more importantly to consumers, free.
What if they also forked Wine and replaced its COM server and libraries with their own from Windows?
Whatever approach they choose, I'm confident they have the ability to ship a Linux distro that runs Windows apps well. It would certainly be a lot easier than going the other direction (Linux compatibility in Windows).
Microsoft made the switch from DOS-based with Windows as a layer to full Windows-based ("NT") operating systems by having both for several years. They could probably offer a Linux kernel with whatever Windows OS services mattered most for the future in parallel with regular Windows for a decade or so.
Doing so might give them a more attractive offering for the future while retaining most of the Windows legacy business. It would also let them leave lots of legacy problems behind, and pick up a lot of the "real desktop computer for real work" business that Apple is pushing away in its own gradual transition to the "controlled purchasing portal" OS they love.
can't speak for the OP, but there are several apps I wanted to run that would have been cumbersome with that approach (although I looked at it). Main apps in question were Excel, and Ableton Live.
I run Windows for Office, CAD software etc. and then have Virtualbox with Linux that I run fullscreen for coding work. Works nicely, haven't noticed any major performance hit.
I meant in general, not specifically for CAD. But even then... You can do gfx card passthrough to the VM these days if standard 3d acceleration is not enough. CADs should work just fine.
gfx passthrough is always a crapshoot. It normally doesn't work, and even if it does it simply adds a lot of complexity to something that doesn't need it.
Wine nowdays can run most apps flawlessly, same thing for wsl, so the end user decision depends on os specific apps ratio and how bad is the windows ui for him
PS and also maybe antivirus tolerances, since there is no need for antivirus on windows.
Quite frankly, the difference here is that WSL is supported by Microsoft and it ensures compatibility with open source tools, while Wine is all about reverse engineering, it's not complete and every time an application gets updated it could completely break.
Furthermore, performance and direct HW access are way more important in my DAW (where I make music and want to eliminate every ms of latency) than in my dev environment (at least to a certain degree).
Running a complex, resource-hungry DAW that needs direct and fast access access to audio hardware and features a demanding plug-in ecosystem on an emulation layer isn't a good idea.
The parent mentioned specifically wanting a Surface device, on which surely Windows would work better?
As another osx refugee, I've spent time on both Windows and Linux. There's no "just" Linux, it has plenty of its own annoyances - to be honest it's a bit of a wash between it and Windows for me. WSL 2 could push me back.
I can't find hardware that I both like and works well with it. The XPS 13 came close, but it had a coil whine you could hear from another room, and I didn't like the track pad.
I tried the XPS and more recently the G3. The G3 is very nice, I dual boot Windows and Linux and haven't found any big problems yet. Wasnt a fan of the XPS either, the high DPI wasnt well supported on either OS (Java apps needed workarounds). The G3 seems perfect so far, 32g ram, good connectivity and ports, NVidia support has been fine on multiple monitors etc
The last time I found a Dell laptop that didn't work with Linux out of the box was in 2010 or so.
You may have some odd hardware issues with discrete GPUs and some other devices (I'm looking at you, Lenovo, and your gorgeous e-ink keyboard I want so much), but if you stay within the basics, there's no reason to assume Linux won't work with it.
I tire of these threads. Half of them are issues people had with Linux more than 15 years ago and the rest are based either on hearsay and just damn preference. I'm so tired of the same flames I'm making this comment now and before it turns into a shitfest.
for me: trash fonts rendering. Some people don't see the difference (I don't blame them), I can't work with Linux-rendered fonts more than 1 hour. Tried Ubuntu and Debian.
Coming from years on Mac OS X and Linux (which I find has as good font rendering as OS X, if not slightly better), the thing that most annoys me about Windows right now are the skinny, badly-rendered fonts. It's close to unbearable, and I'm considering going back to OS X just because of the font rendering.
ClearType is shockingly bad. However, I remember that when I was a teenager I absolutely adored ClearType. But then I hadn't been exposed to other font rendering systems.
Weird, I still love ClearType more than any others... I find it actually sharper and crisper than the others, yet still smooth. Microsoft botched font rendering when they started migrating everything and its mother to GPU (Direct2D? or similar) rendering and decided to replace ClearType with grayscale smoothing just to spite users (e.g. taskbar, Office ribbon), but in other places where we still have ClearType I find it fantastic.
I understand how someone can appreciate ClearType on a normal DPI screen, but the techniques that ClearType uses to maintain sharpness are completely useless on hiDPI. On hiDPI you can have your cake and eat it too: accurately rendered glyphs with no sharpness compromises.
Windows may change to accomodate hiDPI displays, but it make take a decade or more given how Microsoft prioritizes backward compatibility, and most computers in the wild have low resolution screens.
MacOS had always optimized for typeface fidelity, and the results were blurry on low resolution screens, although you got used to it pretty quickly. But now with Retina screens that problem has been solved. Whereas Windows used a hack (ClearType) to make type more readable at the expense of fidelity, and now it can't use high resolution screens to the fullest because now applications assume certain things about font rendering. There's a lesson to be learned here about sticking to your values and software design, but I don't know what it is exactly.
I can’t remember how many times I have given Linux (Ubuntu, mint, etc) a try on a laptop since 2008.
I am just tired of random regressions after an upgrade and spent a few hours every months to fix (frantically google if I would call).
I did exactly this last summer, and have been quite happy with the decision. (context: my dev work is all about elixir/erlang, some python, and some haskell). So far I've had very little trouble with WSL, but its performance is certainly worse than running on windows directly, or on macOs, but for dev purposes it's adequate, and it sounds like that part is about to be solved for me anyway.
My thinking is mainly that while windows is still a little behind MacOS for some things, it's headed in the right direction, and MacOS is heading the other way. The hardware is superior in almost every way to what I was looking at in a MBP (my windows machine is a SB2), only complaints are about the location of the headphone jack, and the fact that the rubber "feet" on the bottom of the laptop have come unglued, which does kinda suck.
All I want is a surface laptop with a thunderbolt port, that's it.
It is very likely that the Surface Laptop 3 will be the best Windows thin-&-light laptop of 2019.
Dell, Razer and Lenovo's laptops have stagnated over the last few years. Huawei + Microsoft seem to be the ones with the freshest new offerings, but I am not buying a Huawei product.
MacOS X -> Windows 10 convert here. Also Linux user for 15+ years. My experiences:
Windows 10 support for things is fantastic. It's faster than Mac OS X and Linux for me. It multitasks better. The HDPI support is very mature compared to Windows 7/8. Multi-monitors just work. I love snapping windows (via corners and hot keys). Also Windows Key + Shift + S to click+drag screenshots to clipboard.
Everything just works. Or the driver is a Google away. Wireless printers and scanners. Bluetooth headphones. Apps like slack, trello, spotify.
On the other hand, Windows 10 "just works" on a lot of hardware. I recommend Lenovo X and T series. Dell XPS series are getting good reviews.
WSL: I'm running webpack via npm, postgres, django and flask. I keep the project files in the windows layer and symlink it into WSL. I turn off Defender because it's the only way to work. WSL is far too slow for me to use Defender on.
Despite that, I turn a lot of call home stuff off. There's tons of telemetry stuff that adds no value. I tried W10Privacy and OOSU10 for it. I wish Microsoft would just add a button to turn all the cloud cruft/call home stuff off.
There is a nasty issue where running rm -rf node_modules that can cause the system to freeze. So go into explorer to remove that with shift+delete. Sometimes I still have to restart.
Microsoft has won a lot of confidence from me with Windows 10, VSCode, and WSL.
> One of the great things about Linux is its stable and backwards compatible system call interface. This will enable us to ship the latest stable branch of the Linux kernel to all versions of WSL2.
This is a very interesting phrase. Linus often appeared to be yelling at developers not respecting the rule #1 of the kernel. However the kernel being strictly backward compatible is a boon for Linux users, most of the industry should be inspired by this strict policy.
Interestingly, Microsoft (compared to Google, Apple...) is the company providing the best long term support for its products.
Also interestingly, the NT kernel is not backward compatible at syscall level. MS even had to invent quite convoluted stuff to run kind of other versions of Windows (but not really...) in their containers, and part of the tech (picoprocesses) was also recycled for WSL1, if I understand correctly.
So I'm really fond of that they wrote: "One of the great things about Linux is its stable and backwards compatible system call interface." I immediately added a big fat: "in contrast with the NT kernel" in my head :D
Neither Darwin or the BSD's (though I'm no BSD expert, I could be mistaken) have a stable system call ABI either.
Linux seems to be pretty unique in this regard.
I don't know about the others but NetBSD has had an even stronger focus on compatability, with some people still running an old binary from NetBSD 0.9 (released in 1993). The one major exception was that the first threading implementation was based on scheduler activations and was completely removed.
Any system that supports static binaries needs a stable system call interface if it wants binary compatibility. IIUC, Windows never supported static binaries.
> Any system that supports static binaries needs a stable system call interface if it wants binary compatibility. IIUC, Windows never supported static binaries.
I feel like you're just playing semantics here. Windows refers to syscalls by name rather than number (which IMO is better), so the numbers aren't the static entities; the static entities are the names. That's static to me. I don't see a single thing that referencing by numbers vs. names would gain you.
I'm not saying Windows is wrong (other systems later changed to dynmaic linking but some still have support for static linking) it just means that you can't replace only the kernel with a new major version and expect it to work (another issue there is kmem grovelers which I think Linux is entirely rid of but NetBSD isn't quite).
IIUC, most of the major issues with Windows compatability are due to developers not following the documented system interface and directly calling the explicitly unstable and undocumented system calls directly. Stuff that uses the documented interface continues to work indefinitely.
The origin of the stable syscall tradition in unixy systems is not fixing the same issues that Windows has but is due to the historic use of static binaries.
> the NT kernel is not backward compatible at syscall level
I don't think they officially guarantee it, but would you mind elaborating on this? They change the syscall numbers frequently, which you never ever use on Windows (you reference them by name instead), but any syscall that I've ever used (NtCreateFile, NtQuerySystemInformation, etc.) has been rock solid/stable. What syscalls have you seen broken in the past that users were actually relying on?
So 2019 is going to be the year if the Linux desktop, and it's going to be brought to the world by Microsoft? Just when I thought this timeline couldn't get any weirder.
I personally think that this is a good thing in the short-term for both Linux users and Windows users in that it gives both platforms a sort of kick in the pants each to deal with one platform's deficiency by incorporating the other's strength. I could speculate about where this all could go wrong long-term, but that is basically a future resurgence of embrace-extend-extinguish, which anyone here can look up. What is important now is that people voted with their time, their wallets, and their voices to give Microsoft a strong enough signal to invest their future product development around. These people include Linux users, Linux developers (kernel and userspace), Windows users, and Microsoft itself and all of them deserve some amount of gratitude for getting us here today so thank you.
To be completely honest, the only way this news could be any better in my eyes was that if Microsoft also committed to being 100% privacy-focused and removed any and all telemetry from Windows, but I guess the four groups of people I laid out previously did not want that level of privacy just as badly.
> To be completely honest, the only way this news could be any better in my eyes was that if Microsoft also committed to being 100% privacy-focused and removed any and all telemetry from Windows.
As much as I'm also privacy minded, I do support telemetry in software (not the kind that touches my data) but if the developers can get traces of how people actually interact with their product and what happened when their product did crash - it helps a LOT, not only technically but also to shift management's focus onto an issue.
What do you have against telemetry in software? (again, not the kind that saps your data for gains).
I don't have anything against the good kind of telemetry in software provided that you can demonstrate to both non-technical and technical users that it is not the bad kind of telemetry with extremely high confidence.
I wonder how they are handling resource allocation (memory, cpu cores, etc?)
One thing that is nice about WSL is that you don't worry about any of that. Am I going to see a 1gb block of memory reserved every time I start up an linux terminal?
Hyper-V supports dynamic memory allocation. As far as the rest it can all be shared i.e. your VM having 4 cores assigned does not mean those 4 cores are inaccessible to everything else.
Alternatively just have Windows and Linux run side by side on a generic hypervisor. Then allow them to each render other virtual machines as an "application."
You can already do 90% of this. Only thing missing is allowing virtual machines to call up to the hypervisor to get a hook/render into sister machines.
It basically allows you to create a D3D device that delegates it's rendering to another D3D device in the system, and then the output surface can be either dealt with in software (CPU acts as protocol encoder), in hardware (ie. videnc/dec block + PHY hooked over USB/PCIe) or just memory mapped to host OS.
So this sound like the CPU usage will be quite a bit higher than with wsl1, since it's actually running a VM. Kind of like Docker on Mac. It's not a huge issue, but it still takes some battery life away.
VM does not mean extra CPU usage. Since there is no emulation involved (assuming VT-x is supported) you should be getting native or mostly native performance.... not to say that WSL2 will be better on CPU usage, however I don't think one should assume that it will be worse.
This is opposed to WSL1 which is emulation and has extra layers to go through.
Unless they completely stripped all background tasks, there's still a few wakeup calls from the VM. I didn't mean the execution overhead from emulation.
For example hyperkit.docker not running any container does ~90 wakeups/s on my machine. This comes mainly from just keeping the VM alive. This also prevents deeper sleep for CPUs.
The new wsl, along with VS Code's new remote development extension, could make Windows an interesting beast with two identities: a primary host for regular business and consumer software, and a linux client for development.
I did use Windows & wsl for development for much of 2018, and (coming from a mac) found it surprisingly usable. The separate filesystem hierarchies was a bit of a pest, and I reverted to Linux for the first time in some years. But that has plenty of its own annoyances, and I'll be interested to check out wsl 2.
Yep, I had been using WSL for most of my programming last year too, and I found it to be pretty decent. I switched to my dual boot Linux recently because I couldn't use the GPU via WSL. But if this lets me use the GPU, then I won't need to have a separate Linux install anymore, which would be pretty convenient.
You weren't (and maybe still are? haven't kept up) supposed to touch files belonging to the Linux from Windows (which afaik live somewhere in the Windows folder), but you can access Windows files through /mnt/<driveletter> just fine.
It was always fine to work with your Windows files via /mnt/$driveletter/…
Recent releases of WSL now let you access Linux files that are inside the distro from Windows using a special filesystem driver and magic path (\\wsl$\…)
Does this mean that we'll be able to mount EXT4 devices and use storage as block devices? I'd love to be able to use `ddrescue` without having to boot into Linux.
204 comments
[ 3.0 ms ] story [ 209 ms ] threadThe real issue is being able to read the WSL disk from Windows which you have to access as a network share from localhost
So this starts to potentially make windows an alternative to macOS for developers. I moved to macOS because it was like having a linux/unix distribution that wasn't ugly, and just worked really well.
But I'm more than happy at the _idea_ that there's a viable alternative that allows me to still have high res displays and decent graphics and support, while allowing me to develop on a system that's a first-class citizen for most open source tools (which is Linux).
Not sure what you mean. Windows has been using PowerShell for almost a decade now as the Bash equivalent "everything at your fingertips" command line tool.
Personal opinion, in many ways PowerShell is more powerful than Bash. It's more verbose, but it's also easier to script.
It's not free of warts (the verbosity is annoying), but I personally find it much more readable than Bash scripts. The support for script modules also helps a lot if you are managing a lot of scripts.
Its designed to be integrated into everything. When my sysadmin GUI clicks vmWare I open PowerCLI. When my db admin uses networker for backup I use Sql Server Powershell Module. When my web dude clicks in IIS management studio and forgets the click I give him unmistakable ps1 script that crates IIS site and sets it up in 5 lines of code. Its like that forever.
Poweshell is no typical shell - u do business stuff in it, not text parsing all the time like in bash with 0.1% of what you actually want to do.
The thing that i personally miss is exporting config of Windows (control panel and friends) as powershell script(s). Something like DSC (or better, BoxStarter) but for grannies - press Start -> export everything to powershell script -> reinstall -> run ps1 -> run chocolatey -> show FTW sign.
But it isn't. Try managing AD servers using powershell. You have two options. Either the powershell AD module, which is incomplete and doesn't cover the entirety of Active Directory, or you resort to the native .Net API which is ugly and unintuitive when used from a command line.
"When my db admin uses networker for backup I use Sql Server Powershell Module."
Wut? Don't do this. I've used that module and it's fragile as hell. You have to check the arity of your select statements for it to work correctly. I built a data importation integration using it once and once I got tired of it breaking I just caved and rewrote the tool in C# and never had any more trouble.
But none of that's what I'm talking about when I say that it feels like a second class citizen. If you're on a Unixy machine, every tool implicitly runs from within a shell. That means the shell is always available, even from an application. Not so with Windows. In Windows, the .NET API is your world ( or if you're unlucky, the Win32 API) on Linux, it's the shell.
It's kind of in this sense that Powershell isn't really a shell in the sense that Bash is the primary interface to the operating system whereas Powershell is just an interface layered onto other interfaces. I've done enough sysadmin type work in either environment to feel the difference. Powershell is less a primary interface with the system and more a scripting language. As a scripting language, it's pretty fine, I have no complaints about the design. I'd like to think it's pretty close to what I would have come up with had I been tasked to design a CLI for Windows in the mid 2000s, but it doesn't underly the system as deeply as the Unix shells do.
Edit:
For an great concrete example, compare Cron with the Windows Task Scheduler. With Cron, the command language is whatever your shell happens to be. You have a string which specifies the schedule, followed by some shell command which does your task. The shell command can launch a program, start another script, or you might be able to contain it all in the single line. On Windows, you provide the exact path to the program you want to launch and any arguments. That's it. Powershell isn't available. If you want to launch a PoSH script, you have to reference the PoSH executable and provide your script as an argument. It's relatively ugly.
One nice thing about the Cron approach, is that you can provide input redirection for ad-hoc logging or even output suppression, without having to modify your executable. It's a lot more steps to do the same thing on Windows.
I know that Sql Server module sux (MS guys I worked with told me that Sql team didn't quite get it), especially when it automatically changes drive to virtual one upon loading.
But it works, once you know the quirks, or you can find alternative (number of them).
> If you're on a Unixy machine, every tool implicitly runs from within a shell.
Run Windows Core or Nano server and you have the same thing. Run X Windows and you have th same thing on Linux as on Windows.
> Either the powershell AD module, which is incomplete and doesn't cover the entirety of Active Directory, or you resort to the native .Net API which is ugly and unintuitive when used from a command line.
Many cmdlets are incomplete. Why do you think Linux CLI tools are complete ? Anyway, without any IDE and with just Notepad knowing a bit of .NET you could create yoru own functions where it isn't enough. I do it all the time, here is one link: https://github.com/majkinetor/posh
About ugliness, my God bash is ugly. The code is so ugly that it hurts. I don't even have to translate the C# code in Powershell if I don't want, I can just compile it and execute it from the string from Powershell. Dropping to .NET was never ment to be used on command line - wrap it into nice sugarry function/module.
> For an great concrete example, compare Cron with the Windows Task Scheduler.
Great example, because I like Cron and I hate WTS. The problem is the syntax - cron syntax is easy to learn and remember. WTS can't be specified that easyly, in any case you need to click, use XML, use ughly CLI tools, or incomplete Task Scheduler cmdlets. Also, WTS is full of quirks.
Yeah, typical way is 'here is exe, run it, thats it' or 'powershell -Command/-File' or 'cmd.exe -C ...' (as is with many other linux tools, cron excluded).
Its easy enough to create scripts, for instance this is my replacement for Startup folder:
https://github.com/majkinetor/posh/blob/master/MM_Admin/Regi...
But there is something more in line with your desires - PowerShell Scheduled Jobs (not Tasks, Jobs) which work as you want it - Powershell itslef manages scheduling.
No you don't. X Windows is still run from a shell. The Windows GUI, by contrast, is not. Any application run in Linux or Solaris or whatever can drop down to the shell. And if I run an application from a terminal, I can take advantage of that. Not so with Windows.
"Anyway, without any IDE and with just Notepad knowing a bit of .NET you could create yoru own functions where it isn't enough."
I've written PoSH modules before. I'm pretty familiar with the process. I don't know what point you're trying to make.
"Why do you think Linux CLI tools are complete ?"
Because in the Unix environment, the CLI tools have been the primary admin interface for the past 40+ years. In Linux, the CLI comes first and the GUI is an afterthought. In Windows, it's the other way around. If you think that's changing, great. But I work on Windows in my day to day work, and regularly write Powershell so I've got a good feel for the difference.
https://docs.microsoft.com/en-us/powershell/scripting/instal...
My impression is just as anecdotal as yours, but it's exactly the opposite. Windows seems to me to be gaining amongst developers, due to a combination of push and pull factors (respectively: Apple's declining hardware and Microsoft's improving software).
I'm a case in point: a few years ago I wouldn't have considered running Windows, but I was driven to trying it in 2018 by Apple no longer making any notebook hardware I was willing to use. Admittedly I'm now largely on Linux, but it's a close call between the two and I could be tempted back.
The kernel part will be fully open source, which should be sufficient enough to comply with GPL
(IANAL)
this is an age-old debate. Some people say that it is e.g. legal to make (redistribute to precise) a GPL device driver for windows, and some argue that it is not, because the whole kernel should then be GPL.
> https://linux.slashdot.org/story/02/11/05/0051225/gpl-issues...
well, user-mode applications do syscalls to the kernel, not direct function calls.
Longer guess: I suspect they are doing some fancy virtualization tricks here to service calls directly like they would a VM but in a VERY lightweight manner similar to containers. This fits with other announcements concerning containers that were also made today.
Again this is all supposition without any actual knowledge.
http://linuxdevices.org/using-a-hypervisor-to-reconcile-gpl-...
Such tricks are one of the reasons I support stronger copyleft like License Zero's Parity. Otherwise, they just loophole their way out of stuff.
(You kind of need to be able to use GPL code dynamically to be able to run it from a proprietary OS of any kind in any way.)
I'm inclined to think Windows is not a derivative work of the Linux kernel by any remotely tenable legal theory, but anyone with code in the kernel they are shipping willing to take the other side of that bet against Microsoft’s legal team has the option to try.
Edit: more info here: https://devblogs.microsoft.com/commandline/announcing-wsl-2/
"dramatic file system performance increases, and full system call compatibility, meaning you can run more Linux apps in WSL 2 such as Docker."
That will be welcome. I use WSL, but it's currently very slow for anything that touches lots of files, like a git clone, rsync, etc.
https://nickjanetakis.com/blog/setting-up-docker-for-windows...
https://nickjanetakis.com/blog/setting-up-docker-for-windows...
0: https://github.com/jstarks/npiperelay
I'm pretty sure, otherwise, that is a gaping hole in many security setups right now - if any website could poke local sockets using client JS.
Still, it's generally a pretty bad idea to have an unauthenticated service running on localhost which can perform arbitrary operations on the system - you're depending on all other software running on the system not to transform that into a vulnerability.
For me, personally, it seems like another failure. I don't see any reason not to use Linux in VirtualBox. It's simpler and it works. Their original approach was something new and interesting. Microsoft started to make very questionable decisions lately.
https://devblogs.microsoft.com/commandline/announcing-wsl-2/
> WSL 2 uses the latest and greatest in virtualization technology to run its Linux kernel inside of a lightweight utility virtual machine (VM). However, WSL 2 will NOT be a traditional VM experience.
If WSL v2 is running VM under the hood, no wonder it will be Hyper-V. We already have such lightweight VM for "Credential Guard/Device Guard" and it already conflicts will any other hypervisor: VMWare workstation [1], VirtualBox. Resolution is to disable Hyper-V, for instance, with command line
So most probably WSL v2 will do the same, which means one cannot run WSL v2 and non Hyper-V VMs at the same time, because two different hypervisors can't coexist.[1] https://kb.vmware.com/s/article/2146361
I guess there is no hope that one will be able to continue to use WSL v1?
Looks like that guess is wrong:
“WSL 2 is a new version of the architecture that powers the Windows Subsystem for Linux to run ELF64 Linux binaries on Windows. This new architecture changes how these Linux binaries interact with Windows and your computer’s hardware, but still provides the same user experience as in WSL 1 (the current widely available version). Individual Linux distros can be run either as a WSL 1 distro, or as a WSL 2 distro, can be upgraded or downgraded at any time, and you can run WSL 1 and WSL 2 distros side by side. WSL 2 uses an entirely new architecture that uses a real Linux kernel.”
https://devblogs.microsoft.com/commandline/announcing-wsl-2/
[1] https://forums.virtualbox.org/viewtopic.php?f=6&t=90853 [2] https://docs.microsoft.com/en-us/virtualization/api/
At this rate -- for my uses, anyway -- I expect Microsoft to update and expand Hyper-V (and Sandbox, and WSL v2) in a much more timely fashion than Workstation, especially considering it's a core technology of theirs (across desktop and also server). On top of that, VirtualBox and QEMU now support the new Hypervisor APIs[1], so Workstation is the odd one out in my mind.
In the end between updating my license and sticking with this, I haven't gone back yet, but we'll see once I put Hyper-V in 1903 through the motions...
[1] I actually recently installed QEMU for Windows, followed some of those Rust OS tutorials, and booted my own disk image in QEMU's graphical mode, using the WHXP mode in QEMU (-accel whxp on Windows, instead of -accel kvm on Linux) and it all worked like a charm. Amazing how well QEMU seems to work these days on Windows.
I hope you don't have to have a non-home license for Windows to run WSL 2, that would be really annoying.
It's not running in a Hyper-V virtual machine, just like the Java virtual machine isn't a Hyper-V virtual machine.
It's more like how 16-bit Windows executables ran on 32-bit Windows - in a very thin "virtual machine" long before hypervisors were a thing.
Good. I hope this trend continues.
Linux has already thoroughly trounced Windows in mobile (Android). It's done so in the web space. MS still has a strong foothold in enterprise, but it doesn't take a genius to see Linux continuing to expand on at least the backend in enterprise as well.
With more apps being delivered over the web, and web browsers being cross-platform, the desktop choice becomes less OS-centric for rote workers.
I can see this as Microsoft looking into a future where they lose relevance because of ChromeOS eating up the low end and MacOS eating up the high end, and they're left with institutional traction. Which they can coast on for many years, but not forever.
Installing certain apps do tend to be on the slow side so if WSLv2 can resolve this, that would be great news. As for the implementation is concerned, I have no idea what they are talking about.
There is, for laptop/desktop: almost all of those run a Windows kernel thus most money for laptop/desktop device driver support is going towards supporting the Windows kernel. Technically... it's a difficult discussion but it's irrelevant. Noone is running a bare kernel.
Microsoft itself called the NT 3.1 kernel a "macrokernel". https://docs.microsoft.com/en-us/previous-versions//cc750820...
If you look at the Other Wiki, you will find even Mac OS is not a microkernel. http://wiki.c2.com/?MicroKernel
> XNU is not a MicroKernel, it is a kernel obtained by merging the Mach MicroKernel with parts of the BSD kernel and parts specific to Darwin, all running in kernel space.
OKL4 is the most widely deployed pure microkernel in Qualcomm phone modems and Apple's Secure Enclave coprocessor. It is possible OKL4 is the most widespread OS, in fact.
Oh there is. Like pervasive ACLs on all kernel objects, e.g., processes. User-ids (SIDs) based on a distributed authority model rather than a simple int. Then there's asynchronous IO that's still not usable in Linux. Etc, etc...
Plus, word on the street is Microsoft's motivation to move to Chromium was totally different to that: it was a performance decision. Too many apps were using Electron, and the only way to improve their performance was to intregrate it into the OS.
>Plus, word on the street is
Come on, don't just start spewing a bunch of weasel words. It's fine if you disagree me and I won't downvote you if you do (I never downvote people for that reason) but at least put some effort into it.
> Too many apps were using Electron, and the only way to improve their performance was to intregrate it into the OS.
Well why wouldn't they just build out the Edge backend to be compatible with node.js to natively support the Electron API? Because it a waste of time and R&D money when Chromium does all that already and more with minimal cost. Why reinvent the wheel when you can get a run-flat radial tire for free?
There are 1,000 privately developed and privately run Windows apps for every publicly available application, and those private applications are the backbone of businesses around the world. A Linux kernel would render a VERY large portion of those inoperable, even with WINE.
A Windows with a Linux kernel will never replace traditional Windows. Some Microsoft OS may live alongside traditional Windows, at some point however, and it is unlikely to be Linux at all.
There are lots of kernel architectures out there besides the ones that Linux and Windows use.
No. We "talk" to the kernel through an ABI, not an API. Maintaining ABI compatibility is important because you can move a binary from one kernel version to another without recompiling and relinking your app.
Whatever approach they choose, I'm confident they have the ability to ship a Linux distro that runs Windows apps well. It would certainly be a lot easier than going the other direction (Linux compatibility in Windows).
Doing so might give them a more attractive offering for the future while retaining most of the Windows legacy business. It would also let them leave lots of legacy problems behind, and pick up a lot of the "real desktop computer for real work" business that Apple is pushing away in its own gradual transition to the "controlled purchasing portal" OS they love.
As another osx refugee, I've spent time on both Windows and Linux. There's no "just" Linux, it has plenty of its own annoyances - to be honest it's a bit of a wash between it and Windows for me. WSL 2 could push me back.
You may have some odd hardware issues with discrete GPUs and some other devices (I'm looking at you, Lenovo, and your gorgeous e-ink keyboard I want so much), but if you stay within the basics, there's no reason to assume Linux won't work with it.
Things take longer, and don't work out of the box.
I LOVE Ubuntu Server though, fav of all time.
Specifics here would be valuable input.
I'm a linux user, so terminal isnt a big deal, but Ubuntu is no windows.
ClearType is shockingly bad. However, I remember that when I was a teenager I absolutely adored ClearType. But then I hadn't been exposed to other font rendering systems.
Windows may change to accomodate hiDPI displays, but it make take a decade or more given how Microsoft prioritizes backward compatibility, and most computers in the wild have low resolution screens.
MacOS had always optimized for typeface fidelity, and the results were blurry on low resolution screens, although you got used to it pretty quickly. But now with Retina screens that problem has been solved. Whereas Windows used a hack (ClearType) to make type more readable at the expense of fidelity, and now it can't use high resolution screens to the fullest because now applications assume certain things about font rendering. There's a lesson to be learned here about sticking to your values and software design, but I don't know what it is exactly.
My thinking is mainly that while windows is still a little behind MacOS for some things, it's headed in the right direction, and MacOS is heading the other way. The hardware is superior in almost every way to what I was looking at in a MBP (my windows machine is a SB2), only complaints are about the location of the headphone jack, and the fact that the rubber "feet" on the bottom of the laptop have come unglued, which does kinda suck.
Mine has handled every programming, design, and editing I've ever needed.
Btw, I just Virtual Machine or SSH my linux boxes.
A BSD or Mach kernel, perhaps -- that's been done successfully already on the desktop. Linux? No chance.
Dell, Razer and Lenovo's laptops have stagnated over the last few years. Huawei + Microsoft seem to be the ones with the freshest new offerings, but I am not buying a Huawei product.
So, I am hoping Microsoft delivers.
Windows 10 support for things is fantastic. It's faster than Mac OS X and Linux for me. It multitasks better. The HDPI support is very mature compared to Windows 7/8. Multi-monitors just work. I love snapping windows (via corners and hot keys). Also Windows Key + Shift + S to click+drag screenshots to clipboard.
Everything just works. Or the driver is a Google away. Wireless printers and scanners. Bluetooth headphones. Apps like slack, trello, spotify.
While I haven't used the Surface, I was considering one for development, but the repairability on the Surface Book 2 (if that's what you mean) is worse than the Macbook Pro: https://www.ifixit.com/Teardown/Microsoft+Surface+Book+2+Tea...
On the other hand, Windows 10 "just works" on a lot of hardware. I recommend Lenovo X and T series. Dell XPS series are getting good reviews.
WSL: I'm running webpack via npm, postgres, django and flask. I keep the project files in the windows layer and symlink it into WSL. I turn off Defender because it's the only way to work. WSL is far too slow for me to use Defender on.
Despite that, I turn a lot of call home stuff off. There's tons of telemetry stuff that adds no value. I tried W10Privacy and OOSU10 for it. I wish Microsoft would just add a button to turn all the cloud cruft/call home stuff off.
There is a nasty issue where running rm -rf node_modules that can cause the system to freeze. So go into explorer to remove that with shift+delete. Sometimes I still have to restart.
Microsoft has won a lot of confidence from me with Windows 10, VSCode, and WSL.
This is a very interesting phrase. Linus often appeared to be yelling at developers not respecting the rule #1 of the kernel. However the kernel being strictly backward compatible is a boon for Linux users, most of the industry should be inspired by this strict policy.
Interestingly, Microsoft (compared to Google, Apple...) is the company providing the best long term support for its products.
So I'm really fond of that they wrote: "One of the great things about Linux is its stable and backwards compatible system call interface." I immediately added a big fat: "in contrast with the NT kernel" in my head :D
Oh... And zOS/zVM. "Mature" no longer describe those two. "Timeless"/"Ageless"/"Eternal" would probably be better words.
Any system that supports static binaries needs a stable system call interface if it wants binary compatibility. IIUC, Windows never supported static binaries.
I feel like you're just playing semantics here. Windows refers to syscalls by name rather than number (which IMO is better), so the numbers aren't the static entities; the static entities are the names. That's static to me. I don't see a single thing that referencing by numbers vs. names would gain you.
https://en.wikipedia.org/wiki/Static_library
I'm not saying Windows is wrong (other systems later changed to dynmaic linking but some still have support for static linking) it just means that you can't replace only the kernel with a new major version and expect it to work (another issue there is kmem grovelers which I think Linux is entirely rid of but NetBSD isn't quite).
IIUC, most of the major issues with Windows compatability are due to developers not following the documented system interface and directly calling the explicitly unstable and undocumented system calls directly. Stuff that uses the documented interface continues to work indefinitely.
The origin of the stable syscall tradition in unixy systems is not fixing the same issues that Windows has but is due to the historic use of static binaries.
I don't think they officially guarantee it, but would you mind elaborating on this? They change the syscall numbers frequently, which you never ever use on Windows (you reference them by name instead), but any syscall that I've ever used (NtCreateFile, NtQuerySystemInformation, etc.) has been rock solid/stable. What syscalls have you seen broken in the past that users were actually relying on?
Unfortunately the rest of the echo system like glibc people have not learned this rule. So practically it's not as beneficial as one would hope.
I personally think that this is a good thing in the short-term for both Linux users and Windows users in that it gives both platforms a sort of kick in the pants each to deal with one platform's deficiency by incorporating the other's strength. I could speculate about where this all could go wrong long-term, but that is basically a future resurgence of embrace-extend-extinguish, which anyone here can look up. What is important now is that people voted with their time, their wallets, and their voices to give Microsoft a strong enough signal to invest their future product development around. These people include Linux users, Linux developers (kernel and userspace), Windows users, and Microsoft itself and all of them deserve some amount of gratitude for getting us here today so thank you.
To be completely honest, the only way this news could be any better in my eyes was that if Microsoft also committed to being 100% privacy-focused and removed any and all telemetry from Windows, but I guess the four groups of people I laid out previously did not want that level of privacy just as badly.
As much as I'm also privacy minded, I do support telemetry in software (not the kind that touches my data) but if the developers can get traces of how people actually interact with their product and what happened when their product did crash - it helps a LOT, not only technically but also to shift management's focus onto an issue.
What do you have against telemetry in software? (again, not the kind that saps your data for gains).
[1] https://en.wikipedia.org/wiki/Linspire
One thing that is nice about WSL is that you don't worry about any of that. Am I going to see a 1gb block of memory reserved every time I start up an linux terminal?
Emulating the Linux ABI is difficult (because it's full of crap).
At some point you get tired of emulating the garbage -- it's a large, underdocumented, and fairly fast moving target.
Next step: reverse this and make Windows run on Linux.
You can already do 90% of this. Only thing missing is allowing virtual machines to call up to the hypervisor to get a hook/render into sister machines.
https://github.com/kfroe/IndirectDisplay
It basically allows you to create a D3D device that delegates it's rendering to another D3D device in the system, and then the output surface can be either dealt with in software (CPU acts as protocol encoder), in hardware (ie. videnc/dec block + PHY hooked over USB/PCIe) or just memory mapped to host OS.
This is opposed to WSL1 which is emulation and has extra layers to go through.
For example hyperkit.docker not running any container does ~90 wakeups/s on my machine. This comes mainly from just keeping the VM alive. This also prevents deeper sleep for CPUs.
I did use Windows & wsl for development for much of 2018, and (coming from a mac) found it surprisingly usable. The separate filesystem hierarchies was a bit of a pest, and I reverted to Linux for the first time in some years. But that has plenty of its own annoyances, and I'll be interested to check out wsl 2.
I wonder if they will be able to bridge that gap? I think I could be a happy windows user if I never had to touch PowerShell again.
Recent releases of WSL now let you access Linux files that are inside the distro from Windows using a special filesystem driver and magic path (\\wsl$\…)