Windows 10 with Ubuntu now in public preview Microsoft's latest "Insider" Windows 10 preview Build 14316, includes the Windows Subsystem for Linux along with a flurry of other new features. The addition of a Linux command-line to Windows was announced at Microsoft's Build conference last week. The feature is aimed at developers, allowing them to use Linux utilities …
The kind of scenario Microsoft envisages is when you want to develop and test an application that will be deployed on Linux without leaving the Windows desktop
Should that not be...
The kind of scenario Microsoft envisages is when you want to develop and try out an application that will be deployed on Ubuntu Linux without leaving the Windows desktop.
IMHO, any serious application testing will have to be done within a VM or on a system with the Target Linux OS installed on bare metal/hypervisor.
There are two classes of things here:
1. basic shell tools like bash, grep, awk etc, which do little other than read and write to stdio. Fair enough - making them work is easy enough.
2. full blown applications like mysql which depend on proper POSIX semantics. The chances of Microsoft emulating (say) POSIX threads correctly seems pretty remote. It even took Linux itself years to get that right.
Perhaps what Microsoft is hoping for is:
* User installs a LAMP stack
* User finds it is unreliable, locks up and crashes randomly etc
* User tells boss to install SQL Server and IIS instead
... hoping that they don't realise it's the crusty emulation layer which is breaking things.
* User tells boss to install SQL Server and IIS instead
Or equally likely, user realises that LAMP seems to work fine in its native habitat, so tells boss to install Ubuntu/Debian/Red Hat instead.
For now, we can forgive its flakiness as it is in beta. WINE was terrible too years ago.
However, going forward, this is going to test Microsoft's commitment. If they can't make it work right, it'll likely reflect worse on them than it will the open-source community as there's plenty of anecdotal evidence to suggest these software packages are stable and reliable on their native platform.
basic shell tools like bash, grep, awk etc, which do little other than read and write to stdio
You clearly have no idea what goes into a Unix shell, if you think it does "little other than read and write to stdio". And that's doubly true for bash, a kitchen-sink shell if ever there were one.
I understand the skepticism, but no, our goal is not to annoy you into using MS tech instead.
We absolutely intend to build a sufficiently Linux-compatible environment that you can run the majority of Linux command-line tools.
We don't currently have any plans to make this a service hosting platform for production workloads, but we do aim to allow you to run most command-line apps that developers use frequently in order to build their projects.
Actually, the Windows NT 3.x kernel was originally designed to support POSIX so it may not be that far-fetched for that support to still be in the code today, albeit embedded deeply within the OS. Even if that capability has been removed it would not be beyond the realms of possibility to resurrect it.
Actually, we run many things rather well. We have several things that are having issues right now (including MySQL, node/npm), but we're actively working on fixes to solve these and many other scenarios.
Our intent is that you should absolutely be able to run Linux-native Redis, MySQL, Postgres, Mongo, etc., locally for dev/test.
we have to have Cygwin or NX installed at the moment, if the bash shell can save us having to install that
It doesn't look to me like this is much less effort than installing Cygwin. Particularly not if you're already using Cygwin, and so already have things configured more or less to your liking.
I'm not hostile to the idea of Win10 with Ubuntu, but while I understand the implementation differences, I don't see the user experience, for most users, as being all that terribly different from that of Cygwin or any of the other UNIX-on-Windows solutions (MinGW, MSYS, SFU, Interix, MKS, U/WIN, ...) that have existed since the early NT days.
[PM for Windows Console and Bash on Ubuntu on Windows here]
@Steve: "IMHO, any serious application testing will have to be done within a VM or on a system with the Target Linux OS installed on bare metal/hypervisor."
Yes! We agree with you!
Bash on Ubuntu on Windows is a developer convenience, enabling you to develop and, perhaps, locally test, your bash scripts and/or code that has dependencies on Linux features and/or behaviors.
Bash on Ubuntu on Windows is NOT a replacement for full Linux: If you plan to deploy your resulting system to Linux, we still encourage you to test your code on a Linux VM/machine prior to deploying into production (you ARE using a CI/CD workflow, right?). But we hope that Bash on Windows is a sufficiently Linux-compatible environment that it makes you more productive when working on code on Windows 10.
Being Windows 10 - free, I'll never make use of it, but from the technical point of view, I'm impressed.
It obviously needed collaboration between Cannonical and Microsoft, which makes me wonder about the converse : will we soon see an announcement of Windows 10 Apps and the App Store coming to Ubuntu (running on a Wine-like Ubuntu subsystem, maybe)?
I certainly wouldn't expect Microsoft to deliver any more than they're committed to, but I would expect it to satisfy Canonical's needs - else why get so deep into collaboration?
On the info given, it isn't clear what both parties really expect to get out of this collaboration. But given that the bottom line for both companies is profit there must be a revenue stream in it somewhere.
Which is why I wouldn't be surprised to see Windows Store Apps running on Ubuntu someday - there's money in that for both parties.
Unless MS ditches the registry and goes to a config-file-based environment, I can't see a true integration occurring between the two. The way permissions are handled are utterly different too, of course. However, it will be interesting to see what develops from this...
I suppose it's only fair. We have WINE on Linux, why not Linux on Windows natively? Mix n' match. Perhaps some time when I've lost my last marble I will make an unholy conglomeration of Linux hosting a VM running Windows running Linux running WINE just to see what happens... It couldn't be much less problematic than SharePoint and Office 365 is right now :)
OS2/Warp/Zoroastrianism anyone?
Unless MS ditches the registry and goes back to a config-file-based environment, I can't see a true integration occurring between the two.
FTFY. Once upon a time, that's how Microsoft rolled. Now, not so much. I would be much happier if all apps were self contained instead of being tied in to the registry, but that wish is based on sheer laziness on my part. This new ability, if it amounts to anything, would actually feed into that too as I recently have been given scripts to write in both Windows and Linux environments. Being able to do at least the initial draft of both on a single system would speed things up a bit for me.
Indeed, today they are releasing "LINE" (LINE Is Not an Emulator), which I found quite funny. But we all know, having used WINE, that it is a last resort solution. THE solution would be to run a proper Linux kernel.
And then I had a nightmare. I was dreaming M$ ditches it's own kernel, starts using a real Linux Kernel, and just turns it's desktop onto one of the myriad of desktops existing out there on top of Linux. Of course, they would open source and help WINE guys to make much more legacy Windows programs run on Linux through WINE.
After all, 99% of users see only the desktop environment, they couldn't care less which kernel it is running (and they are right not to care as long as it runs fine).
And then... tadaaa...
Meet Winux, the first Linux distribution officially approved by Redmond!
As enterprises like "big company names" (who knows Ubuntu or Canonical amongst the Top 100 CIOs?), people dislike fragmentation (and the Linux Desktop is very fragmented since Unity), it would for sure make big big scores and probably kill all other distros... hence extinguish!
So, I hope Satya is not reading TheReg to steal this bad idea. ;-)
This post has been deleted by its author
Thanks! As your twenty upvotes shows, no one else thought to resurrect this particular cliché for this story. I'm glad to see that the Reg commentariat's dedication to original thinking has not softened.
I look forward to the comment threads about the Microsoft antitrust actions, illegal bundling, "Linux is a virus", and other topics that people feel compelled to post about in the comments to every single fucking story about Microsoft. Never forget!
Think I'll stick to cygwin for those odd times I need linux tools in Windows - can interact directly with Windows (and 'top' works). For anything more extreme I'll just boot Linux or use a VM. Bit of a strange frankensteined beast more about keeping you in Windows than doing useful stuff.
Seconded on Cygwin. I've been using Cygwin for well over a decade and it works well enough. It has even become my go-to SSH client over the years. Cygwin's repository has also grown into rather ludicrous proportions with the entire offline download weighing well over 13GB... compressed.
So you'd be quite hard pressed to not be able to find a package and even if you don't compiling something on Cygwin is always an option.
My only annoyance is that manually selecting packages can take a while.
This post has been deleted by its author
" And in 1971 the problem was still to make computers tolerably easy to design, program and pay for. Internationalisation was in the unforeseeable future."
Balderdash and piffle. Multi-lingual communications have been very much a thing long before computers came along. That some ignorant beard-strokers failed to realise this is entirely down to ignorance on their part. They don't get to rewrite over a century of telecommunications history to excuse their lack of knowledge.
Contrary to popular belief, international telecoms and data transmission was not an invention of the computer industry. Many bankers and financiers were routinely getting their news and share prices via telegraph ticker-tape systems as far back as the 19th century. Character encoding is therefore a concept that predates the invention of viable electronic computers by some decades, and UNIX itself by almost a century.
This post has been deleted by its author
Using an Italian keyboard, Windows slashes are much more comfortable because they don't need to press Shift.
I was a very, very happy young Italian developer when I finally managed to get my hands on a PS2 US keyboard in Italy… and with the US-International layout, I could even type the accents which _should've_ been in the Italian keyboard, but haven't ever been there. How else is one supposed to start a sentence with "È" with? An Office suite?
So you get used to a keyboard layout the other 99.9% machines you encounter don't have, and makes very hard to buy a laptop and the like? And why.we should be forced to use a foreign layout just to easy access basic characters? Sure, the lack of accented uppercase letter is an issue - but still better than en ex colleague of mine that decided to write in ASCII7 only with an US keyboard and never used proper accented characters... but it felt a "real man".
> Whoever coded Unix should have understood the World doesn't speak (and type) English only.
Don't make the mistake of thinking that Windows uses the other slash because they were trying to be kind to you - it is purely the result of MS using / for command-line options in MS-DOS (borrowed from CP/M via ...) before they even got around to needing a directory separator.
"Whoever coded Unix should have understood the World doesn't speak (and type) English only. Same is true for C...."
Unix and C are the way they are because there were designed for two finger typists ie. tech's, by tech's and specifically those who wished to spend the time to undergo the requisite initiations and so join the elite/priesthood...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
