Hacker News new | past | comments | ask | show | jobs | submit login
Ubuntu Unity running on Windows 10 (github.com/microsoft)
128 points by aj_jaswanth on July 10, 2016 | hide | past | favorite | 84 comments



Sounds a little bit like slashdot in here with the pointless Microsoft/Unity hate rants. This is really awesome and I can't wait for more and more integration. This is nothing but awesome


No, seriously. Unity (the ubuntu desktop interface) is an abomination. Not a joke. Very serious.

It is painful to even try to use. It forces so many unnatural behaviors, in favor of... I don't even know why. It's not elegant, it's not pretty, it's not fun to use.

It is bad. Horrendously bad. And suited to the tastes of little more than a very small handful of people, who probably open a browser and read email, and do little else, except maybe script shell commands on the rare occasion.

Their decisions arbitrarily imposed on many, who likely still use the distro, simply due to ease of installation (and probably no other reason), and then shoulder the burden of routinely overriding the default install configuration immediately.


I'm a software engineer and it's my favorite GUI available for Linux. I've used all the hip things like Xmonad, dwm (for a long time), XFCE (for a very long time), Gnome 2 and 3, KDE 4 and 5, i3 (which I still like a lot), et cetera.

I still prefer Unity nowadays. It's simple, it's fast and stable (at least for me), and it reminds me of OS X (which I also like).

Everyone who runs Linux at my job uses it. No one had to be taught how to use it. No one has had any issues with it or complains about it. It just gets the job done.

I totally get that not everyone likes it, but Canonical is targeting a general audience and I think they're doing a good job. If you don't like it, just apt-get something else. It doesn't need to be super customizable and cater to everyone. Let them focus on their core features for their primary audience.


As a software engineer it's hard to imagine you can't see the benefits of learning something in order to gain an edge in productivity. I mean that is the essence of programming? In order to master something, it takes effort.

While lowest common denominator UIs are great for simple tasks performed by novice users, so much more can be accomplished by even putting in a little effort. I mean you did take the time to learn a programming languge, correct? Or was your programming language so natural you never had any questions? Did it just work without any effort?

Or are you implying that a GUI is a distraction? That it provides no benefit and something like a tiling window manager or other system can't give you any productivity benefit? I'd find this hard to believe.


Give Cinnamon/Mint a whirl; I couldn't "do" Linux desktops until Cinnamon. It works really well out of the box. It's not quite as OSX-y as Unity but Unity had a few quirks that I couldn't stand.


After I switched to Ubuntu a couple years ago, I gave Unity a whirl (it being the default desktop environment), and I use it to this day.

Unity is simple and it doesn't try to be the be-all and end-all of my computer use. Unity seems to be designed by people who understand that the purpose of a desktop environment is to facilitate launching other programs and perhaps moving their windows across the screen a little bit, and that's it.

I am a former KDE user, and I used to spend hours and hours on end tweaking my KDE configuration. Finding that perfect equilibrium was a quest without end, but the abundant opportunities for shaping the DE to my liking didn't make me any more productive.

Switching to Unity was a liberating experience. Suddenly, I could not do any of the things that KDE allowed me to do...and I didn't suffer any ill consequence as a result of that. Rather, I discovered that all I ever needed from the desktop environment was to let me run Emacs and Firefox. Everything else was, and always has been, superfluous.


I use Xubuntu so I'm a bit of a stranger to Unity. I have tried it and it certainly didn't suit my needs. It's inelegant to say the least. Do not disagree I only meant the knee-jerk "AHHHH MS SUCKS UNITY SUCKS SYSTEMD SUCKS" lunacy that I see when these topics come up. XFCE or bust.


Also useless? As a Windows user I'm not particular troubled by the lack of user facing XFCE applications.

On the other hand I'm worried about the resources invested in this project, instead of stability or performance improvements in Windows. In the long term I'm worried about Microsoft's monopoly.


I'm not worried about it at all. To me, it all represents an investment from Microsoft in the open source developer which is long over due. If another commercial player begins to offer a viable alternative to a Mac setup, I'd be happy to make the switch.


Which project are you referring to? Note that this is a tracker item created by a third party, to share information on how to configure VcXsrv to work with LSW. It's not Microsoft official or anything.


BashOnWindows


I'm personally a fan of Ubuntu's Unity and I can see the potential in this. I've been using linux for 10+ years and I can't efficiently navigate multiple windows in Windows as easily as under Linux.

Since lot's of mobile devices don't perform as well running Linux as Windows and you want to get the maximum performance out of your device (think battery life), Windows is really you best choice.

In the past, I replaced the windows shell with a couple different BlackBox ports that were compiled for Windows but I was still missing out on all the command line tools so it didn't meet my work flows.

But now that Microsoft let's you run BASH on Windows, I think if I gave it another shot, this setup would work for me but at the moment I don't have any requirements that depend on Windows that would cause me to switch OSs.


Great, so now one can (amongst other things) finally run Wine on Windows without resorting to a VM!


Yup, it used to be possible in Colinux too.


Yes, but only on 32-bit Windows, right?


Indeed - it looks like work on 64 bit was started, but never completed, which I think is a shame.


How much effort would be required to reimplement coLinux as a pico process?

Will it be possible to implement alternative syscall handlers with a future version of the DDK?


Huh? Why would you run Wine on Windows?


To play older Windows games that for various reasons won't run on Windows 10, for example.


The conventional wisdom has always been that Microsoft is hyper-focused on backwards compatibility, but there's only limited truth in that. Even if you pick Windows XP as a starting point (just considering NT kernels), tons of stuff broke with Vista.

Compatibility Mode has never been very good, though I don't think there's anything preventing Microsoft from making a more Wine-like compatibility layer if they really wanted to.


Microsoft provides a free Windows XP SP3 virtual machine image to run on Windows 7:

https://www.microsoft.com/en-us/download/details.aspx?id=800...

I'm not sure if the same thing is still available for Windows 10.


Nope. Reserved to Win7 (and then; only Pro). Even third party VM software able to run it implements a custom check to make sure your host is Win7 otherwise they refuse to run it. This is quite concerning, from a backward compat POV, because it means that it only has deferred the incompatibilities it proposed to solve, and that deferring is completely artificial.

Honestly MS is not that good on backward compat. They are good on the story, so/so on the facts. But I prefer that to being stuck in the dark ages of poor design and the poor security which comes with.


Absurdly funny, but true.


Probably for the same reason people run dosbox on windows, to run software that no longer runs on windows 10.


We need to go deeper.

To run bash on windows on ubuntu on windows.


... I'm still waiting for the native-Linux-Docker-container announcement. I'd be shocked if MS+Docker weren't working on it.


Shouldn't that be even easier under OS X?


Probably not - it would need syscall translation and an ELF loader for OS X to make that happen.


Apple will do it after Microsoft does


I wonder how Microsoft managed to implement the Linux ABI all of sudden, while Wine has been developed for more than 20 years and yet it's still very hard to run most modern Windows software using it.

Note this isn't a rant by any way, I appreciate the work done by the Wine project a lot and use it every now and then. I'm just trying to understand if it's a matter of manpower, simpler task, or better design.


The Linux syscall ABI is pretty small and stable, and once you have that any userland program just works. Windows (NT) doesn't have a stable syscall ABI, instead having stable ABIs for libraries that wrap it in various ways (Win32, most prominently, but historically also a POSIX library).

As such, WINE has to reimplement all those libraries, whereas Windows only has to implement something comparatively tiny.

I expect someone can write a better summary of pros/cons of both approaches (and there are definitely both for both!), so I'll leave that to them!


Yup, Wine is more like implementing the syscall API, LibC, OpenGL, and a couple of GUI libraries all in one.



Besides the already mentioned reasons another reason is that the NT kernel was designed from beginning to support different subsystems as OS/2, Win32 and POSIX, though POSIX was only implemented to barely work and OS/2 support was dropped (was it ever released?). There was an independent implementation (Interix) of a POSIX-conformant Unix subsystem, which was later on bought by Microsoft and later on rebranded as "Microsoft Windows Services for UNIX".

Having this in mind: It is much simpler to implement a new subsystem for a kernel that was designed from beginning to support multiple subsystems than to retrofit a Win32 subsystem (Wine) to a kernel (Linux) that was never designed for this purpose.


Hm, this is only the theory.

In practice, lots of modern NT syscalls are directly or at least quite closely modeled after their Win32 equivalent. Even more so when they have been introduced after the end of the Windows Consumer vs NT split - but even before that, NT was already very close to Win32.

And Win32 has always been special for NT. And Posix & co has always been "special" in the other way: even when the idea of having subsystems was already decided (at first it was mainly for OS/2 vs Windows API), the question was raised whether to implement the Posix API in a subsystem or layered on top of another subsys API (like Cygwin is today). The paper advocating for the subsystem is available in the WRK, IIRC (quite a poor paper with bad arguments IMO, but it shows that the question has been raised).

Actually the traditional NT subsystems were not even able to do WSL, and the most important work to get it was not the legacy of the Posix & co. subsystems, but a project to be able to virtualise different versions of Windows userspace on a single NT kernel (indirectly, it first leads to the Android subsys attempt, which got cancelled and then morphed to the WSL we will get).

When you look at the WSL architecture (and compare with Windows NT + Win32 architecture) and hints given by the previous or existing WSL bugs, there is probably not much the WSL driver deffer to the NT kernel, only very core stuff like virtual memory, scheduling, and on some FS code (WSL adds its own layer for VolFS). Even Socket/TCP networking needs completely custom code in at least the upper layers (not surprising when you know the completely insane architecture of Winsock, with a legacy from Win16) but probably also quite a bit in underneath layers -- result: it stills works so/so when you don't stick to ultra trivial usage of the TCP sockets. And they told that Pipe are completely custom, because the semantics is too different from NT Pipes. The Fs aspects also shows that there is probably a lack of virtualization in NT, or that for now some WSL stuffs are plugged at the wrong place. Signals are not really a concept of NT, so WSL does most of the work, and like usual in this story, it shows quickly by still having some bugs: the first trick or even mainstream but non-trivial usage you try to do, it immediately fails. Especially more so when ptracing.

In the end, what permitted to have a WSL seemingly reaching a decent state (it's still very far from perfect, but quite decent already for development purposes) so quickly is that: 1) it actually started way before any publicity about it 2) it seems to be made by a small, but not too small, very competent dedicated team working full time on it 3) Posix API and Linux syscalls have a documentation at least 2 order of magnitude better than MSDN, and a reference implementation available for everybody -- probably they don't allow WSL devs who write WSL code to look at the Linux code, but they still have access to the man pages which are more useful than the code in most cases, especially given how much detailed are lots of man pages -- compared to that MSDN doc of Win32 is a complete piece of useless crap 4) the area to cover (Linux syscalls) is smaller compared to Win32 -- Wine does not tries to reimplement an NT kernel, but the whole userspace stack -- an analogy would be MS trying to reimplement Linux + Gnome + Kde + PulseAudio + X + etc... The amount of work is not comparable at all!


The original POSIX and OS/2 1.x subsystems was dropped in WinXP.


I think it is basically just complexity. I have been thinking of selling Windows to a non profit foundation for a while now.


Can access to Windows source code help?


I think many of the code could probably be directly reused.


It looks pretty cool. I think I might switch from OS X to Windows 10 on my laptop someday, maybe after Surfacebook 2 release.


Wow that's really cool. This is pretty close to native performance? This is a really great step for Linux on the desktop. Such an easy way to onboard people.


Not really except on the broadest definition of Linux, where Linux is ~= Unix. Linux is a kernel. GNU is the Unix environment which they are getting to explore, more specifically with the Ubuntu OS mgmt tools.

Now what I don't get, and I'm not trolling here, is why would you want this? Isn't a VM a better option?

I assume people using Windows want to because of the UI, not the kernel. Whereas people generally choose Linux/Gnu/Unix for the kernel and OS environment, not the UI. With Ubuntu on Windows you get part of what people have wanted, and arguable the most important part people want.

Will people really want a Windows kernel, with Ubuntu/GNU OS tools, and Unity? I suspect most would still want the Windows UI.


> Now what I don't get, and I'm not trolling here, is why would you want this? Isn't a VM a better option?

If this is indeed close to native performance, you wouldn't get anywhere close to that with a VM. I could be oblivious to some optimization techniques but Linux VM's on Windows have always performed drastically worse than native.


In my experience it's quite the opposite for some workloads: Linux FS and process spawning speeds are typically way faster than Windows one (with or without WSL), so much that even when in a VM with dozen of % of overhead, it is still faster than running on Windows for some workloads (just cold open a random man page under WSL, compared to a VM, and you will understand how much Windows lag behind Linux in some areas -- next you can try to build a big program: same result: Windows is really slow)

Now this does not render WSL useless; launch time for any random small tool is better with WSL than booting a complete VM, the memory is not partitioned, integration with the Windows Drive FS is slightly better, etc. But tons of use cases are better covered by a VM -- and with a huge margin.


> just cold open a random man page under WSL, compared to a VM, and you will understand how much Windows lag behind Linux in some areas -- next you can try to build a big program: same result: Windows is really slow)

Mate, the thing isn't even released yet and you're bashing it (excuse the pun) for taking too long to open up a man page? Give me a break.

After it's actually released and the performance gets better then it is of course going to trump running a whole VM and to suggest otherwise is just FUD, IMO.


RS1 is mostly frozen.

I think Win10 is quite good, and that WSL is quite good given its age, and will be extremely useful for a lot of things.

Still, if you try some workloads, WSL is way slower than a Linux VM. I don't expect it to change for the release. I don't even expect it to change for the 2 years to come. Sill, of course, I could be wrong.

But even so; I insist: WSL is actually quite impressive.


Unity is not particularly valuable, but X itself is.

Suppose you're developing a cross-platform GUI application (hypothetically, its name could be "Visual Studio Code" or something like that...), and your main development environment is Windows. Now you can build and test it on Linux as part of your regular workflow, without having to sync code etc.

Heck, you could even make it so that launching the project (from a Windows IDE) would do a Linux build, and launch the resulting binary.


>Isn't a VM a better option?

Please explain how it is better.

They've implemented the ABI/syscalls in the kernel allowing for direct execution of unmodified ELF64 binaries.


If you're going for a full Linux/GNU/Ubuntu/Unity stack, the only thing this cuts out is Linux, making his a Windows/GNU/Ubuntu/Unity stack. I know they've replicated the system calls, but they won't perform or always operate identically to a Linux kernel.

Which is why I asked about where people thought Unity on Windows would make sense. Because a VM will most likely generally give a better experience.

If you restrict yourself to bash and standard Unix tools, you'll end up with a similar experience to macOS and terminal (or my preference iTerm2)


> but they won't perform or always operate identically to a Linux kernel.

Why does the implementation have to be identical? How would that even be possible, unless they violate the GPL. I don't get your point.

> Because a VM will most likely generally give a better experience.

Again, please explain WHY it would give a better experience. What do you see lacking?


I am fairly certain this is a "syupid programmer trick" kind of thing. I don'tinagine anyone seruously using Unity within windows


I will ditch my Xubuntu VM the moment this seems viable and I find a way to turn off Win10's spyware.

VMware has basically abandoned Workstation, and the gfx performance is terrible. A native X server on Windows talking to the Linux subsystem seems like it might be decent.

And if this means somehow I can end up using more XMonad...


It is a good stress test of the implementation


AFAIK This is not emulation or virtualization, so as long as Microsoft's implementation of the Linux kernel APIs on top of the Windows kernel is performant, and the X11 implementation is also performant, this should have native performance.

Also considering the state of graphics drivers on GNU/Linux and on Windows, it wouldn't surprise me if for some specific hardware configurations, the “perceived interactive performance“ (responsiveness) of the UI was actually higher on Ubuntu for Windows than on it running on top of the Linux kernel.


It is syscall-level emulation. Emulation in this case doesn't mean it has to be slow. I am curious how they implemented `fork(2)`, though.


Surprisingly, the NT kernel implements a copy-on-write fork function - the Windows subsystem does not allow Windows applications to use that function, though. Bash for Windows is implemented as a separate subsystem from Windows on top of the NT kernel, allowing it to build its own abstractions on top of the kernel.


NT has support for POSIX-style forking, because it needed it in order to have a POSIX subsystem in the 1990s.


AFAIK the nt kernel already has support for forking.


I can't comment on the X performance, but I am finding performance of command line applications is a couple of % faster on windows than it is on Linux (if they do little / no I/O).


How did you test it?


Just using a CPU intensive application I work on (GAP, a computer algebra system), on my laptop.

I'm hoping we can kill our current windows build, and require people install bash for windows.


Maybe the resources required to run just one bash instance (and whatever you run within it) is lower than the resources required to run whatever DE you had on Linux (Unity is notorious) enough for it to show?

When I asked how you tested, I was looking for a more detailed answer: what were the environments, the hardwares, what does the cli app you used do (CPU, IO, allocation etc.) (this you answered), etc.

---

I normally run a KDE session, which takes up some memory and the KDE ecosystem aren't the lightest users of syscalls (I'm looking at you Konsole), but when I need sheer perf (even for benchmarks), I kill all KDE sessions and switch to an openbox session running st.


Sorry, I didn't do anything that detailed!

I compared a standard Ubuntu install to a standard windows 10 install on a T420 Think pad.


Is that application in python and uses numpy?


Nope, a python-like language written in C.


Haven't seen anyone write this yet, so: I wonder if this (I mean the whole Linux subsystem for Windows) is gonna be the downfall of Windows in the end. As at this moment, somewhat counter-intuitively, it should actually make more sense to write software purely for Linux, effectively ignoring Windows, as then you'll get Windows compatibility for free. I'm somewhat surprised they didn't actually try to contribute to Wine instead, or build something similar on their own.


The purpose of WSL is to bring back developers to Windows. It is more efficient than Wine and is more useful to Microsoft to get almost native Ubuntu containers than some way to run Windows GUI apps on Linux.


Does this offer any glimmer of hope that GPU support is one day possible, and we'll be able to run machine learning and other general purpose GPU tasks through WSL?


Personally, I'll be much more interested in Windows once it has standard UNIX tooling available without needing something like cygwin. Especially if it ends up allowing me to replace the new Windows shell with something like xmonad and dmenu.


Looks nice.Now give me a good Filesystem à la ZFS and maybe I might come back.


Not gonna happen. The last MS attempt at FS is ReFS, and it certainly won't support WSL given its by design lack of some features WSL is using. Not even talking about WSL, I don't think you can even put the system on ReFS, you sill need NTFS for that. MS approach at FS is a little bit odd, I think. There is a lot of confusion between the abstract features NTFS provides (and the rest of the systems needs), and the actual concrete NTFS filesystem.


Cool hack, but I really prefer native Win 10 window management. The only thing superior is IMHO XMonad.


I suppose there's nothing stopping one for doing that tho? I was sitting here and thinking about trying it out with i3. If that works then it is only missing a decent pkg mgmt (in my opinion ofc), at least on the technical level. I sort of enjoy the thought that my current setup (arch) is entirely OSS and hackable though (not on a hw level ofc)... It makes me smile every time I log in :)


I've just spent some time experimenting with the state of X-on-windows.

It seems that there are two main options: - Rootless mode (the default install for VcXsrv), in which your windows are managed by the Win10 WM and integrate quite nicely

- Rooted mode, in which you can use your own window manager, but the windows are restricted to living inside a native Windows window. Using this in fullscreen on a virtual desktop provides a near-linux experience, but some remapping is required so you don't conflict with Windows' alt-tab, etc. Other bits of integration like copy&paste still co-exist nicely.


I don't think any of Windows 10 window managers is swappable so anything you will run on top will mean significant friction and loss of usability.

I think Cygwin is already using Pacman so perhaps you can get it to work without root on Ubuntu and hence on Windows 10.


From the screenshot, all this seems to be doing is running an X server, so it should be trivial to switch from Unity to i3, Xmonad or whatever.

The next level of integration would be running X11 fullscreen and then launching Windows programs inside that environment. e.g. Word 2016 launched and managed from the Unity launcher.


Thought it was the Unity IoC ( might want to specify this more explicitly )


Why oh why would one want to do this terrible thing?


Great, now make it possible to also run Mac and Android.


Windows 10 with Unity: you've got two problems now.


This meant for people who _don't_ think either are "problems". I don't understand the point of your comment.


Depends: personally I like Windows 10 but despise Unity but I'm sure I have heard a lot off people actually like Unity as well.


In case your Windows experience wasn't tragic enough...


If you like Ubuntu, just install it or use live USB/CD. It looks like Microsoft lost focus(one the most important thing in the business) and plays it on all sides.




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: