Windows Subsystem for Linux to debut in Windows 10 Fall Creators Update Microsoft's head-turning Windows Subsystem for Linux will emerge from beta to become a fully-fledged-and-supported feature of the Windows 10 Fall Creators Update. Redmond's Rich Turner revealed the status change late last week, noting that the beta has already ended for users of Windows 10 Insider build 16251. In past looks …
"For many years I looked for a fully featured Linux Subsystem for Windows. But on reflection even that isn't need these days."
The Microsoft integration solution was handy for various things - especially NFS file shares - and often outperformed Linux as an NFS server! Access permission translations were fiddly to get right though.
Many people don't realise that the NFS client AND NFS server parts of SUA / SFU still exist - even in Server 2016:
See https://protechgurus.com/install-configure-nfs-windows-server-2016
The NFS client only is also part of Windows 10.
Rather like those DOS boxes on OS/2
Hmmm....I suppose in the sense that DOS was at that point on the way out you're correct. However I'd posit that once they made use of 386 and higher virtualisation the OS/2 VDMs were at least ebony constructed coffins, with solid gold fastenings and lined with the very best top quality silk and and plush padding :)
Those of us still forced to develop DOS applications very much appreciated the crash protection and also the ability to multitask. I spent two or three years developing data recovery software in a VDM because that kind of work is rife with crashes due to the amount of corrupt data you have to process.
The only thing I found that the VDM didn't support was the Task File registers (later to become ATA) access to hard disks. I think there was some kind of bug there because the machine used to spin up the floppy drive when I made a request. BIOS access to disks did work however and that was what we mostly used.
So yeah - DOS was a turd by that time. But the DOS boxes - they were a technical marvel worthy of much praise.
"still won't let you read Linux files from Windows"
This is meant to run Linux under Windows on top of an NTFS or ReFS filesystem - Why would you then need another Linux install on the local system ? If it's not local you just use a network share... So an EXT4 driver is not really something I would expect Microsoft to provide. If it was a multi-access file system that made sense for the cloud then maybe, but it isn't.
If you really need to access Linux local EXT file systems then there are several third party driver solutions for Windows.
"still won't let you read Linux files from Windows"
Actually you can, if you can find the correct hidden folder. As of recently, they were accessible from \rootfs and \home folders in the C:\Users\USERNAME\AppData\Local\Lxss directory.
I haven't played with it for awhile, don't know if that location has moved around at all.
"has moved around"
If M$ is anything to go by historically, it would have been moved several times. Let's just say if M$ were ever to make cars, you would find the steering wheel in the boot one day and the seatbelts in the engine another day.
M$ just love to make pointless changes, because reasons
This post has been deleted by its author
Oddly on DOS 2.x SWITCHAR=- let commands use - instead of /
DOS 2.0 was first version to have paths and used \ because / was the option character. I used CP/M mostly till DOS 2.11 (when I started using UNIX too), then used DOS 3.3.
I can't remember if the path separator changed from \ to /
MS never seems to think ahead. The very first instant I saw Autorun, I knew they were headed on a path of destruction. Later I was appalled to discover it wasn't just CD drives, but USB sticks, and EVEN network shares! Idiots.
Edit:
A forwards slash is a frequent component of both written English and mathematical notation. A backslash is used almost solely for paths and escape characters. Putting the latter on the almost never used backslash rather than on the frequently used forward slash made good, logical sense.
UNIX popularised the wrong thing.
Come off it. Unix had been using / as a directory path delimiter for years before DOS discovered subdirectories. Personally I can't recall any situation I've ever been in where it causes problems or ambiguities with written English or maths.
Backslash was used to maintain compatibility with the 1.x option delimiter. It has caused grief in things like scripts and makefiles ever since due to doubling up as an escape character. It is just about bearable if you work in an entirely windows environment but if you have, for example, a central unix-based build machine you can end up with nightmarish \\\\\\ sequences because you have to escape the backslash enough times that the next stage will still have escaped backslashes.
Also, from an ergonomic point of view putting the separator on a shifted key is irritating in an otherwise case-agnostic filesystem. I believe in some keyboards it actually is on an AltGr key, which is even worse.
On my keyboard the backlash is a single key, the slash is a shifted key above 7, which is one of the key "farer away". Like C, Unix was too much developed around US-only standards (my keyboard doesn't even show curly braces, which requires to press three/four keys to type them...). And whatever Unix did, forty years later it may just be an outdated standard today, no matter how necessary back in those old days. After all, telephones used to have rotary dials, we got rid of them....
Also, from an ergonomic point of view putting the separator on a shifted key is irritating in an otherwise case-agnostic filesystem. I believe in some keyboards it actually is on an AltGr key, which is even worse.
On a proper PC keyboard, the backslash is on an unshifted key.
> Backslash was used to maintain compatibility with the 1.x option delimiter.
And the MS-DOS 1.x option indicator ('/') came from CP/M which MS-DOS is a clone of, and that came from CP/M's origins, being written on DEC machines with RT-11 or similar.
When MS tried to make a 'family' of operating systems with Xenix and MS-DOS 2.0 they had to cope with the conflicts between DEC originated systems (CP/M, MS-DOS) and Unix, and did that poorly.
Also, from an ergonomic point of view putting the separator on a shifted key is irritating in an otherwise case-agnostic filesystem. I believe in some keyboards it actually is on an AltGr key, which is even worse.
For us using non-US keyboard yes. Annoying. Of course in murika that was not such an issue.
For similar reasons I used to opt for UNIX-layout on Sun keyboards even here in the old world. It was easy enough to get the odd characters required on this side of the pond using Compose key anyway.
I'm nearly sure computers simply used the teletype terminals to start with as keyboard + printer combo. Those didn't have the \, so they used /, (1950s to 1970s, note while TTY33ASR is 1963, electric keyboards produced Morse tape at least in early 1930s and the TTY and Telex non-morse Telegraph type services started in 1932, with even RTTY before 1945. Originally Teleprinters used the ordinary phone lines!
The TTY33ASR was used on computers, like a typewriter, it had / but not \ (Zoom in on the image, you can read all the keys).
I don't know how | (pipe, was ¦ only an IBM thing?) was typed.
(also interesting, https://en.wikipedia.org/wiki/Bit-paired_keyboard )
Well, they DID have a backslash, you needed to look for it. Most of the time it was unlabeled.
If you have a model 33 teletype (or 35 for that matter), just press your friendly shift key and strike the 'L' key and it will magically appear. Other glyphs available are:
Shift 'K' - '['
Shift 'L' - '\'
Shift 'M' - ']'
Shift 'N' - '^' (usually an 'Up arrow').
Shift 'O' - '_' (usually a 'back arrow').
Shift 'P' - '@' (this one was usually on the key).
If you got stuck with a non-parity keyboard that had 'alt mode' and not a true escape key, the proper incantation was: Control/Shift/K.
We now return from the 60's/70's to your regularly scheduled program.
UWIN with its limitations. However it could share files as it wrote into the Windows file system. Pity it's vanished. Was nice to have a decent shell immediately availble when I wanted to code some data munging without transferring to a nearby RealOS box nearby. BTW, what happened to the MKS toolkit M$ borged a decade or two ago ?
MobaXterm will get you a UNIX-style shell environment running on the Windows file system and it's up and working faster than Cygwin. It can even run xeyes which Windows 10 won't be able to according to MS' release notes.
To be honest there doesn't seem much to recommend Windows 10 over MobaXterm or Cygwin given all the limitations listed.
There is one enormous difference: when you run 'apt-get' in MobaXterm it looks to the set of packages that have been specially written to work with MobaXterm; when you run 'apt-get' in WSL, it looks to Canonical's Ubuntu repos (but you can add any other by editing your sources file).
Basically, if a tool run in a Linux terminal, that same binary will probably run on WSL(*). To me, that's worth losing X11. (Besides, X11 is reported as working in the current WSL, it's just that Microsoft is not prioritising the fixing of any bugs people report with it)
* some sysfs/proc stuff notwithstanding, but the "unsupported" list keeps getting smaller.
> Basically, if a tool run in a Linux terminal, that same binary will probably run on WSL
Except that they don't have (and didn't have any plans to when I last checked) any support for i386 (32bit) binaries. So some workloads just aren't possible (for example I can't do a build of the Android system I build on my Linux machine since the build system has some 32bit dependencies).
The best use I can find for it is to use it as an ssh client to a real linux box - I find ssh from within bash preferable to puTTY.
for example I can't do a build of the Android system I build on my Linux machine since the build system has some 32bit dependencies
Yes, i've been bitten by that before.. Not Android, but a product we had to build for both 64 and 32-bit systems. Our build system was x64, and while it's theoretically possible to build both target architectures on either platform, it's also theoretically possible to wrap a rope around the moon. We ended up creating a chroot filled with an i386-native toolchain for the 32-bit builds rather than try to fix all the cross-compile bugs in all the packages we used: lots of packages are still in the "building these sources, for this machine only" mindset, and like everyone else, we only had so much time to ship our product.
But I don't see WSL as a replacement for a real Linux system - instead, it's a way of getting some very useful Linux-based server tools running on a Windows machine, to help me develop the front end. It's the same thing as the Mac's BSD underpinnings: the existence of that not-quite-Linux shell in macOS is the reason why so many developers now use Macs (even after excluding the iOS people who have no choice).
The big selling point of Macs for me and other developers was always that Macs had all the "Unix-y tools" built in, while still having all the "working in an office" stuff that one also needed, plus working hardware drivers; WSL gives Windows the same thing, only much better, and it's honestly something that Microsoft should have done back in 2005 or so...
Anyone remember this? A bare minimum POSIX.1 subsystem included in the original NT releases - allowing MS to undercut big-iron UNIX vendors for US Gov contracts for a "POSIX compliant" OS (but not defining how POSIX it should be). Dropped shortly afterwards once they'd secured the market. Many unhappy end-users left with either a massive porting exercise, or legacy/unsupported systems.
And then there was Windows Services for UNIX (SFU) (discontinued). Not sure who that was for.
Meanwhile the first thing we do with a Windows desktop is install Cygwin and fire up bash...
SFU became SUA because they didn't like the acronym maybe?
the command line utilities were missing things like 'tar' (but it had 'pax' instead, go fig)
It had libs for X11R5 <-- yes, 5
it had an ANCIENT version of gcc on it
it didn't work very well with autotools
I couldn't compile certain gnu libraries, even after trying really really hard
there were numerous header incompatibilities and missing features
in short, it was already ~10 years out of date when I finally realized it existed, and installed on XP, then later on 7, to discover that it was being discontinued and would NOT install on any later version of winders.
ABANDONWARE, to say the least.
How about Cygwin, instead?
So worse than the MS Services For Unix, (if you added a 3rd party X Server, many Linux applications did work). I think like MS SQL, Visio etc, that was bought in.
I'll stick to combo of WINE and a VM with XP (for trickier stuff) on my Linux Mint.
Hello:
---
The announcement post does, however, hint at better two-way interaction between Windows and Linux with the reminder that while “Linux files are NOT accessible from Windows” Microsoft is “working to improve this scenario over time”.
---
Hmmm ...
Looks bad, sounds bad, smells bad ...
What could it possibly be?
My Linux rig boots MS (XPSP3) just a handful of times a year only to run specific software not available in Linux and in a VM without any external connections.
IMO, " ... better two-way interaction between Windows and Linux ... " is as needed as an outbreak of avian flu in the Metro.
And ... “working to improve this scenario over time” ... should be treated as a threat, no less.
I cannot believe that some Reg readers could actually consider using this a viable option.
I would not let this crap near my Linux install.
As always, YMMV.
Cheers.
I'm using it EVERY DAY!!!!
Work polices force me to install Windows 10.
Until last year I had a Ubuntu VM running the whole time for development.
Now I have a Bash terminal open, where I have access to all the Ubuntu tools.
The limitation is accessing from Windows the directories under WSL control. Getting around that is as simple as working the whole time in a directory under Window's control (/mnt/c)
Worth a watch is the Windows Weekly episode 514 Bash on Windows.
https://twit.tv/shows/windows-weekly/episodes/514
I'm absolutely not a Microsoftie one bit. Make up your own mind regards Rich Turner, but he comes across as someone enthusiastic, doing good at Microsoft (and I really don't say that often, regards Microsoft). Whether Myerson has the same intentions, is another matter regards Linux. Not a fan of the latter.
Is Microsoft endorsing Linux such a bad thing? The endorsement certainly gives it "worthy contender" credibility, as a credible rival to Windows, Microsoft are taking the threat seriously, because Linux "is" a real threat to Windows, especially the Windows as a (seamless) Service , which is proving anything but seamless. Windows Update is still a bloated clunky bag of nails, it's really no better under Windows 10. Updating Linux is much easier and more consistent. It rarely fails.
I like Turner, he seems genuine and I'm normally pretty good on people. Still it's so easy to host Windows as a VM on Linux, is there any point to this?
Problem too, Bash on Windows can easily be dropped, like Windows Phone, if it needs be.
https://twit.tv/shows/windows-weekly/episodes/514
Meant to say watch it from 1hr02mins in. (and check out the blank faces either side, as talk WSL (Windows Subsystem for Linux) goes above their heads-quite funny (esp. Mary Jo Foley, she looks like she might drop off), but it's actually a really interesting (and fairly open) insight by Turner into Microsoft.
The business case for it is to better support their Azure "cloud" efforts. It's intended for user by software developers working in a corporate environment on Windows PCs and deploying on Azure Linux cloud instances. Developers deploying to Linux servers in house could use it as well, but that use case doesn't seem to have provided enough motivation in the past to shift Microsoft into motion.
Developers would use this to build and test software on their own PCs using Linux build tools while having to deal with fewer cross platform headaches. The major issues here are probably more to do with meeting the build requirements of third party C libraries than with code the individual developer is writing. You could theoretically do this with Cygwin, but this method provides a more seamless and supported solution.
Microsoft is also putting a good deal of effort into supporting developing software for Linux by putting support for the languages and tools used in that environment into their own products such as for example adding Python support for Visual Studio (yes Python runs fine on Windows, but a lot of important third party libraries don't). Microsoft's own languages such as C#, F#, VB, etc. are stirring little to no interest in the Linux world, so they need to follow their customers if they want to stay relevant.
It's very doubtful that anyone will switch from a Linux desktop to Windows with WSUL, but quite a few pundits seem to think that Microsoft will steal some desktop market share from Apple. A lot of developers who use Apple Macs use them simply because they are a supported hardware configuration with a unixy OS, and so somewhat compatible with Linux. A Windows PC that can make the same claim and offers better library and developer tool access (via Ubuntus repos) undermines the case for buying Apple.
Taking market share from Apple would simply be a minor bonus however. The main reason is simply to provide better end to end support for developing for the "cloud" to try to keep people within the Microsoft environment so they can sell them other things which integrate with Azure and promote Azure in general.
'It eliminates most requirements (commonly from developers) for native Linux on the desktop in a corporate environment. No need to worry about a desktop Linux build / security settings / patching / device lockdown, etc. etc."
Sadly there are a lot of orgs where the devs are fully cross-platform versed, but the corporate IT drones have never seen anything outside of the MS bubble.
On the flip side I'd say there will be many other others that, like us, provide Linux (Ubuntu) desktop builds anyway. They are walk in the park to patch and manage compared to watching the hoops the Windows team has to jump through. Linux desktops are much easier to tune for insane VDI performance too, so many of the non-tech users prefer them - two seconds to login to a complete working desktop versus half a minute for Windows.
As more corporate apps move to web UIs, there's almost nothing left that the Ubuntu desktops can't do.
Stop loosing developers.
Right now, most developers choose Mac because all those Linux tools that are fundamental in any bleeding each development are available.
The other option would be a full Linux Desktop, but without any big marketing muscle behind that option, it is a niche option at most.
With that solution you keep your cheaper and familiar Windows Laptop and have all those tools available.
Have you tried Linux with WINE and also safer Windows in a VM on Linux?
Have you tried MS SFU on NT4.0?
Have you compared the increasing stupidity of ME, Vista, Win8.1, Win 10 with
1) WFW 3.11(with all 32bit extensions and TCP/IP), Win95x, Win98, Win98SE Versus Win ME
and
2) NT3.5, NT3.51, NT4.0, Win2k, XP (aka NT 5.1), Win7 Versus Win10 (or Win8)
I've also looked at Win2.x, Win286, Win3.0 (all rubbish, Win3.1 was first workable version).
I've used CP/M (on S100, Apple II Z80 card and Amstrad PCW) , CP/M86, PCDOS original, MSDOS 2.11 to 6.22, OS/2, VMS, Cromix, MS Xenix, Minix, DRMultiDos, DRDOS, Gem, Mac OS9, earlier Mac OS X versions, Linux since 1999. I've used MS SFU, Cygwin.
Win10 is pointless garbage, so why would I bother with a less functional MS Linux subsystem than OS/2 text mode on NT4.0 or MS SFU?
I used to support, sell and install MS products. No longer.
"Have you tried Linux with WINE"Yes, with no great deal of success. Even if I manage to get Adobe InDesign running (the subscription version works apparently) I won't be able to create PDF files to hand off to be printed.
"I've also looked at Win2.x, Win286, Win3.0 (all rubbish, Win3.1 was first workable version)."Not true. Pagemaker ran fine on Windows 286. Indeed, it was the reason I ran Win286.
"Win10 is pointless garbage"On that we are in agreement...
Yes I use it quite frequently. It's great for when I am on my Windows laptop and want to use openssl for creating a .csr file for a certificate or quickly ssh into another box for example. I consider it a neat little tool that makes my day slightly more productive, but judging by some of the comments on here maybe I am missing the wider religious significance of this particular heresy.
Just having CLI access to grep and awk, and input/output redirection, on a Windows 10 machine makes a lot of tasks so much easier. Yes, there are other ways to do it, but having it neatly packaged up with a shell I'm used to working with them in is the way to go, as far as I'm concerned.
Yes, 'grep' and 'awk' and redirection. I get that with Cygwin on winders. Why do I need Micro-shaft's LAME ATTEMPT at copying Linux? Or rather, embracing, extending, and EXTINGUISHING Linux?
grep in SFU/SUA didn't work quite the same, nor did awk from what I remember (and there were other irritations and limitations as well). As such, I couldn't get a proper grep search to work the same way with THAT thing. So now round 2.
why not just install LINUX instead, if you need Linux?
/me been living in the FreeBSD desktop, day to day, for YEARS now. Since some time before 2005, in fact.
This is linux, it is installed from Ubuntu
It is merely running alongside Windows.
Modern operating systems allow you to run binaries for different subsystems at the same time. It's what happens when you have an OS descended from the proper OS created by the experts at DEC rather than one descended from a bodge cooked up by a couple of guys on their own DEC.
>I get that with Cygwin on winders
What was my option before as well,but the big difference was that you needed that the program you are looking for, was recompiled and included in Cygwin.
Now, you just add the relevant PPA from launchpad.net :-)
>Why do I need Micro-shaft's LAME ATTEMPT at copying Linux?
You are missing the point.
MS is not coping Linux.
You are installing the "real Ubuntu" from Canonical servers
The bit that MS did was a "translation layer" that convert the Kernel calls from all that binary identically software, to the Window's relevant kernel call.
I've actually used the "Windows Subsystem for Linux", in insider builds, for a while. And it's much more useful than this article implies. You can run pretty much any Linux software you want, provided it doesn't need hardware-accelerated X. You install a Windows X server and your application windows just show up like normal in your Windows session, and the terminal works exactly like it does on a Linux machine.
It's great for software devs, although I can't really see why anyone else would need it because you can do most things you'd want to on a server with native windows apps and scripting (PowerShell is a totally usable solution now) and Windows beats Linux handily for productivity apps and gaming.
To tell you the truth, I'd prefer a "Windows Subsystem for Linux" (Wine is not compatible enough, WSL is amazingly compatible), but at least this lets me use both OSs at the same time without the virtualization overhead.
And as for files not being available across systems, that's really not important at all. You can just set up network shares and then magically everything is shared. Wow, so hard.
Just like we had in 1999.
Meanwhile Windows has moved backwards and Linux forwards.
You've be also able to dual boot NT & Linux since those days. A 64bit EFI is well supported, Debian does work with 32 bit EFI (some 64bit Atom Win 10 tablets only have 32 bit EFI and 32 bit Win10 as the CPUs are crippled to only support 2G of real RAM). If you copy the 32 EFI files to Linux Mint installer, it works too).
Most decent Windows machines use 64bit EFI.
The only advantage I see for this is weird corporate places not allowed to install Linux. If WINE can't run the handful of wiindows programs, a VM can. This might have made sense for XP or Win 7 to replace MS SFU, but it's over TEN years too late. MS has missed the bus on this.
"Meanwhile Windows has moved backwards and Linux forwards."
"MS has missed the bus"
For that I upvoted, but with a caveat about EFI: EFI just plain *SUCKS*. It's another MICRO-SHAFT SCAM to try and ELIMINATE LINUX and BSD, to "require" that for a windows-capable sticker on the hardware or something. (fortunately, many operating system distros have adapted, but they should NOT have had to do so in the FIRST place)
Let's not forget that the very existence of EFI is due to Micro-shaft's EVIL PLANS to DESTROY COMPETITION. They behave according to their nature, after all...
EFI was developed by Intel to do away with the limitations of BIOS for its Itanium CPUs; they found that they could not do the preboot things they wanted to do within BIOS. BIOS is limited to 16-bit processor mode, with a maximum addressable space of 1MB. There are a lot of things it cannot do, which isn't surprising when we're using 286-level technology. BIOS' MBR partition system is unnecessarily fragile, is limited to maximum 2TB partitions, and the extended partition containing logical partitions schema is a kludge at best. GPT does away with these, and it's a part of the EFI standard. There are hacks to get GPT bootable disks with MBR, but they're just that. UEFI was designed with them as part of the standard. BIOS is simply obsolete-- it works, but it is far more restricted than makes sense with modern hardware.
Intel still owns the rights to EFI, but its successor, UEFI, is in the public domain. It is not owned by Microsoft, and Microsoft can't unilaterally dictate changes for UEFI. What MS is able to do is to demand that OEMs who wish to receive Windows to sell with their new PCs configure that PC in a certain way, but that's not an indictment of the technology itself, but in a monopolist behaving as such (with governments that have made quite a hobby out of looking the other way at each and every opportunity). This configuration is, of course, "secure boot."
UEFI is not the same as secure boot. The PC I am using now uses UEFI, and it doesn't have the ability to perform a secure boot. The concept of letting Microsoft have the keys that decide if a PC may boot with a given bootloader is, of course, insane, but that's a deal between the BIOS makers/motherboard OEMs and Microsoft, not a predefined part of UEFI. UEFI contains the tools for secure boot, but there's no inherent requirement that MS have any say in the matter.
For most PCs, if you don't like secure boot, you can turn it off. It does have a legitimate security use, though... rootkits do exist, they do overwrite the bootloader with their own code, and secure boot would prevent this from working. That's not a scam to let MS decide what OS gets to run-- that's a real security issue with real benefits to the user. Some Linux distros do have secure-boot functionality; I don't know about the other Unix-like OSes. Still, if you want to use a bootloader that isn't MS-approved, turn it off and be done with it.
On some devices, secure boot can't be turned off. You'll have to talk to the makers of those devices and ask them what kind of deal with Microsoft they made to block off a whole category of potential customers (those who wish to use another OS beside or instead of Windows). You can vote with your feet on these... just don't buy anything that has mandatory secure boot. It does mean more research before purchasing, but that's necessary anyway if you don't want to be unpleasantly surprised.
(Wine is not compatible enough, WSL is amazingly compatible).
Now I wonder why that is.
Could it be that one is open and the other closed? So that MS can see what Linux is doing but not the other way round?
Looks to me like that old Pirates of the Caribbean saying. "Take all you can, give nothing back."
Personally I'm glad windows 10 can't read my linux files which makes it harder for shitty windows based viruses to get their paws on my data. Or for that matter their spyware windows 10. If they try to 'fix this' I sincerely hope the open source community breaks its functionality as soon as possible ! Its no more than Redmond deserves.
There's obviously some corporate dinosaur inside Microsoft that can't contemplate interaction between non-Microsoft filesystems and Windows, one that insists on the PR line that its really difficult and they're working on it. Total BS, of course. I can interact with NTFS from BASH without a problem. So why would I bother with their DiY shell? (Yes, I tried it, and was amazed at what it wouldn't do -- the most obvious problem for me is that I couldn't run Windows applications from a shell script.)
I suppose that the big problem is that all the "kernel work" is done by the "Windows Kernel" that there isn't a ext4 driver for the Windows Kernel yet.
About running windows programs from WLS, look a the post:
>Invoke Windows processes from Linux, e.g.
> ~$ cd /mnt/c/temp/ && echo "Hello" > hello.txt && notepad.exe hello.txt
>Invoke Linux processes from Windows command-line, e.g.:
> C:\> bash -c "fortune | cowsay"
Use it or don't use it, but don't bitch about how it's too terrible for you to use.
Long time cygwin user here. Yes, cygwin is a better UNIX environment on Windows. Yes, a VM is trivially easy to run, if you want the real deal. But this is Microsoft. Their whole model is to release something a bit feeble and then get better over time. Windows Server, I'm looking at you. It's pretty good now, innit? and used to be pretty feeble, yes?
So instead of bitching about it and making Nadella think that he should just give up trying to please the beards, how about you install it, use it and suggest improvements. And if that's not your bag, then don't use it. Anything else is just being an ass.
Or just refusing to kiss MS a$$. After all, it's not like we actually need to tell them, this linux stuff has been around quite awhile, there's source code, and I hear they've even hired linux "experts" to help them.
Am I being an ass to refuse to be a negatively paid beta tester and bug reporter?
I can guess the color of the sky on your planet...and which outfit you work for.
Now, if they were giving away their stuff for free and asking for help, like some other systems do...it might be that they're worthy of a different attitude. But wait...they're not.
sky = blue. employer != MSFT.
The point is not that everyone should be a free beta tester. My point is that those people who chose not to be should not complain endlessly about why they don't want to be one. It's no insult if you don't want o do it. Go and enjoy your (genuinely) superior environments. What depresses me is the tearing down of someone else's efforts.
if Windows didn't morph into a window manager, desktop apps and API running on Linux.
Microsoft has to decide where its future lies.
It's lost the home desktop to smart phones.
It's lost the smartphones to apple and android.
It's lost the servers to Linux.
What is left apart from legacy? The corporate workstation and its apps.
If those apps would run on a linux chassis, who cares about windows, per se?
I.e. a Microsoft supported version of WINE plus a Microsoft branded suite of desktop apps and window manager...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
