bash in windows shellon bahWindows
bash in windows shellon bahWindows
Posted Apr 1, 2016 22:23 UTC (Fri) by h2 (guest, #27965)In reply to: Ubuntu on Windows by khim
Parent article: Ubuntu on Windows
I view this far more as a tacit admission on microsoft's part that they actually cannot be as good as bash or rsync or ssh.
If you couple this with microsoft's recent decision to use openbsd's openssh, coupled with a very large donation to the openbsd project to help fund this work and support the source of openssh, this could actually be microsoft throwing in the towel on shell tools. their powershell commands are so awkward and clunky compared to the mature shell tools of *nix that you really can't even compare the two.
I also was wondering at first about how they could possibly run any x driven tool, and the answer is, of course they can't, but they can run bash in a windows window.
The notion above in this thread that this would lose any linux desktop users is odd to put it mildly, this is just a shell, of great use to any dev environment with a lot of people running windows but interfacing with non windows systems via ssh, a good friend of mine works at one such large scale place, and I know they can use this directly as is, and probably will, because running all these emulators and putty's and other stuff just isn't as good as running native tools that hook right into the NT kernel.
So what this will simply do is let development environments where users already run windows for whatever reason now use better shell tools directly.
I don't believe the support will be anywhere near complete, for example, I doubt this will have the linux kernel core interfaces like /sys and maybe or maybe not /proc (though that's been emulated before on other platforms), so I just see this as getting the basics running so you can work in a real shell without indirect logic. bummer for stuff like cygwin and their project, but as with wine, I'm personally not a fan of emulators, I generally will just skip it, or run a vm if I need the feature. Apt on windows, lol, that's really funny though. Risky, because apt is so radically superior to any other package management system, particularly in the non existent version in the windows world, if anything, exposure to apt is very likely to push people to gnu/linux systems running apt.
Every time I run windows, I always wonder where apt is, then remember I have to do the download package, install, pray, thing, make sure to avoid 3rd party sources, all types of stuff, and I think if you show windows developers/admins these tools, after a while, you just get used to apt-get install, apt-cache search, etc, to install something you need, a little risky on Microsoft's part actually. I'm surprised the commenters in this thread haven't caught how significant apt on windows bash is, huge package pool by default.
Interesting development, for sure. I wonder if they have decided to forego internal openssh in powershell, or if they are going to go both ways, hard to say, powershell has a real userbase too, so maybe they are going for both, it's smart on their end.
Posted Apr 1, 2016 22:48 UTC (Fri)
by h2 (guest, #27965)
[Link] (1 responses)
Posted Apr 1, 2016 23:09 UTC (Fri)
by khim (subscriber, #9252)
[Link] (22 responses)
It's not that. PowerShell is pretty good - but you couldn't use it to drive Linux servers. You still would need PowerShell BTW: bash would have no access to Windows services. At all. Microsoft admits that it have lost the battle for server thus now it's time to make sure developers would at least stay with Windows. They have killed Xamarin Studio, for example - because otherwise people would try to use it and apt instead of Visual Studio and NuGet. As long as developers stay on Windows Microsoft could stage a comeback and/or counter-attack. And I'm not sure how well it'll work in the end but this approach has potential: today a lot of developers are forced to stay with Linux to develop stuff for Linux - on servers. Microsoft just made sure that they would be able to go back to Visual Studio - and many would do that, I'm sure. Sure, I don't think people who have chosen Linux voluntarily would drop it. But bet you would be surprised to find out how many have chosen Mac because it has real bash and now they could even develop stuff for Linux without leaving cosy Windows world! Remember that for each user who have picked Linux there are 99 who haven't. It's for them, not for you.
Posted Apr 1, 2016 23:23 UTC (Fri)
by h2 (guest, #27965)
[Link] (20 responses)
And it's an excellent point re OSX and bash and devs. Not to be pedantic, but I believe the real current number is about 1.8 gnu/linux users out of 100 desktop users, heh. Never gotten much above 2%, and then only for a short while, for very good reason (upgrades, reinstall, no stable api/abi's). It's much more likely that MS is targetting os x here, not gnu/linux, which is so fragmented on its own that MS doesn't even have to contemplate engaging in divide and conquer strategies since we do that so well ourselves already. But OSX, that's a real target, and worth aiming for.
I can see why this though, because my friend was just biting the bullet to try to learn enough powershell so he could write some small utilities for putty connections, but this type of thing would cover that completely and let you run all native stuff.
As long as Linux/Gnu insists on never maintaining stable abi's / apis on the kernel/desktop toolkit front, there's no danger at all of Linux desktop marketshare ever breaking much beyond the slightly tech oriented types who tend to use it now, ie, 1-2% of total desktop user base.
By the way, I was really happy to see windows get the credit they deserve for their api stability here in this thread, it's something they've always had as a very high priority, primarily I think for their corporate desktop users, which is a huge chunk of their market. Every OS does something better than the others, it's fair to give credit where credit is due. I just wish linux kernel devs would learn what stable means, and that toolkits wouldn't fundamentally break everything at every release, but the days of my thinking this is actually going to ever change are now behind me so it's nice to see realistic moves made wherever you may find them.
Posted Apr 2, 2016 16:01 UTC (Sat)
by khim (subscriber, #9252)
[Link] (8 responses)
What do you mean? Kernel devs know that very well and follow the mantra religiously. Linus just reasserted that if it does break anything, it needs to be turned off by default. That's a hard rule. Pehaps you mean that thing? This part is not a problem - and, surprisingly enough, Microsoft and Windows help to highlight that very well, indeed. Old applications work quite well on Windows. Old drivers? Not so much. It was common to lose support for WinModems and WinPrinters, scanners and other random hardware with Windows upgrades. I have quite a collection of old hardware - and I'm forced to keep Windows XP and Windows 98 (sic! Winows98) around to use it. Stable API just does not work for the hardware. The same is true for MacOS, Solaris and all other OSes (including Linux). Linux developers explicitly don't care, others do care, but the end result is the same: obsolete, unsupported driver are lottery with all of them. It's just simple as that. Sometimes they work. Sometimes they don't work. Sometimes they could be easily upgraded. Sometimes it's impossible to do.
We may discuss the question “why?” for a long time (I have some ideas but have no way to verify them), but in the end it does not matter: stable API works in userspace, but it does not work for drivers. It's just a fact. Kernel developers are not to blame. This particular sin is not a problem for Linux.
Posted Apr 4, 2016 21:15 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (7 responses)
Actually, linux RARELY loses support for old hardware. If Win98 WinModems and WinPrinters were supported by Linux of that era, then they are still supported by the latest linux 4 unless nobody bothered to complain when they were accidentally broken (which is quite likely :-). Linux support stays around for as long as users complain (and help debug) when it gets accidentally broken.
Cheers,
Posted Apr 5, 2016 8:48 UTC (Tue)
by NAR (subscriber, #1313)
[Link] (6 responses)
On the other hand I do remember that I had to use a 3rd party bttv driver on WinXP in order to use my AverMedia98 TV capture card. So this is definitely a problem, only mitigated by the relative infreqency of releases (5 releases in 15 years, compared to 23 Ubuntu versions in shorter time).
Posted Apr 6, 2016 7:33 UTC (Wed)
by johannbg (guest, #65743)
[Link] (5 responses)
By all means explain to the wider audience how the linux kernel lost support for a lots of hardware when pulseaudio got introduced.
I'm looking forward to hear that explanation.
Posted Apr 6, 2016 7:46 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (4 responses)
Posted Apr 6, 2016 8:18 UTC (Wed)
by seyman (subscriber, #1172)
[Link] (3 responses)
Pulseaudio's introduction didn't make any of the existing audio systems disappear or stop working so this is obviously false.
Posted Apr 6, 2016 8:54 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (2 responses)
Posted Apr 6, 2016 11:16 UTC (Wed)
by nye (subscriber, #51576)
[Link] (1 responses)
I do feel your pain though - the nightmare year of 2008 was when I started my transition to using Windows on the desktop. PA still wasn't production-ready by the time I'd switched full-time.
Posted Apr 6, 2016 12:07 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
These days, I keep an instance of mpv streaming music whenever I'm at work and if I need to start using the webcam, start to watch another video, listen to other audio files, I just mute the stream and start the other program. No audio device locking problems, I can reroute audio while programs are running, and none of the problems people complain about today from their experiences 5+ years ago.
Posted Apr 2, 2016 17:04 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (1 responses)
It seems that Microsoft's offering is very much a server-side thing (given that, for example, it doesn't come with a GUI). How that is really supposed to be an attack on OS X, which is approximately as popular on servers as Linux is on desktops, in other words not all that much, is something you would need to explain in more detail.
Posted Apr 2, 2016 18:58 UTC (Sat)
by khim (subscriber, #9252)
[Link]
It's not an attack on MacOS. It's "attack on" developers which are stuck on MacOS. I know a lot of guys who are using MacOS instead of Windows because MacOS is "real Unix" (albeit a poor one) and Windows is not.
They don't comprise a huge percentage of population, thus this "attack" wouldn't directly bring number of MacOS users down. But they represent guys who are influencing others thus effect could be significant down the road. But as someone on the other forum (don't remember which one) have pointed out that all these ideas fail Hanlon's razor (the infamous: never attribute to malice that which is adequately explained by stupidity). It looks that Microsoft finally realized that it's ambitious project to save Windows Phone could instead bring down the whole house of card (OS/2 style) and cancelled it then was faced with a question: "could we salvage anything usable from the wreckage?" - and this is the result. No deep plans, no well-thought attacks, just sheer bestial fear of an Android and the desire to at least use result of hundred man-years of work somehow...
Posted Apr 3, 2016 7:41 UTC (Sun)
by jem (subscriber, #24231)
[Link] (2 responses)
ABI stability on Windows is no better. Only recently (with Windows 10) the C and C++ standard libraries (what Microsoft calls "C Runtime library") got promoted to a system component called the Universal C Runtime. Before that, the libraries were distributed with Visual Studio and were not compatible with each other.
This is why third party libraries for Windows are offered in a large number of variants depending on which vesion of Visual Studio they are intended to be linked with: VS 2005, 2008, 2010, 2012, 2013, etc...
Posted Apr 3, 2016 19:12 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
They were compatible where that counted: all versions were included and maintained as part of the OS. Sure, but that only affects developers. For a long time developers have faced a dilemma: develop for Linux (easy peasy lemon squeezy) then find out that you have no way to distribute your stuff to users (no way to produce binaries and deliver them to users and minuscule distributions are trying to impose insane demands on you) or develop for Windows (really hard, you need to pay $$ to get good instruments and many things are just plain out painful to do) then distribute result easily. Developers have endured great pains because stability of target platform is more important than stability and usability of development platform. Now with MacOS/iOS and Android situation is changing. No longer Windows is the only game in town! Development tools for these new platforms are not as great yet but they are going there - and in both cases billions of users are there too. What's not to like? Microsoft feels the heat, apparently.
Posted Apr 4, 2016 14:20 UTC (Mon)
by rghetta (subscriber, #39444)
[Link]
This is not correct.
Posted Apr 4, 2016 21:10 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (5 responses)
Sorry, I call bullshit here ... "Dos ain't done til Lotus won't run". Windows stability matters (a) for Microsoft Office et al, which uses (or at least, used) undocumented APIs, and (b) for all those silly little apps that were important to users but meant nothing to Microsoft.
You could pretty much GUARANTEE that EVERY rev of Windows would contain API breaks that were very damaging to apps that MS considered competitors. As a WordPerfect fan, the list of API breaks from WFWG onwards that caused *serious* problems is long long long ... (Oh - and that's pretty much every version of Windows from then right through to XP - maybe beyond.)
Cheers,
Posted Apr 4, 2016 21:25 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> You could pretty much GUARANTEE that EVERY rev of Windows would contain API breaks that were very damaging to apps that MS considered competitors.
Posted Apr 10, 2016 14:25 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (3 responses)
WFWG. Office95. Win98. XP.
I've left out NT4/NT2000 - I don't remember problems with them. But the number of upgrades and/or emergency bug-fixes you needed to keep WordPerfect going as Windows changed underneath was awful.
Cheers,
Posted Apr 10, 2016 14:50 UTC (Sun)
by reedstrm (guest, #8467)
[Link] (2 responses)
Posted Apr 10, 2016 15:14 UTC (Sun)
by reedstrm (guest, #8467)
[Link] (1 responses)
Posted Apr 10, 2016 16:11 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
Also ISTR that the Microsoft applications used to use special undocumented APIs that could do convenient and powerful things and were (a) unavailable to third-party applications, (b) not part of any stability or support guarantees because they weren't part of the documented interface, so even if a third-party developer figured out one of them for Windows version N they had no guarantee that their code would keep working on Windows version N+1.
Posted Apr 4, 2016 11:29 UTC (Mon)
by nye (subscriber, #51576)
[Link]
There's more than that though - it's not limited to building stuff *for Linux*. A lot of cross platform FOSS is mostly developed under the assumption that you're cross-compiling[0]. For example, Clementine is already hard enough to build on Linux, but building it on Windows would be like traversing several circles of hell - if it's even *possible*. It's actually *very* common that cross-compiling the Windows version from Linux is enormously easier than building natively.
[0] Hell, even when I was using Linux full time on my desktop I would sometime cross-compile for Windows when working on personal projects, because Wine is a more reliable platform than native libs and I knew that if the Windows build would work in Wine then it would continue working if I launched it in a year, unlike native binaries.
bash in winlinksdows shellon bahWindows
bash in windows shellon bahWindows
their powershell commands are so awkward and clunky compared to the mature shell tools of *nix that you really can't even compare the two.
good points
good points
I just wish linux kernel devs would learn what stable means
good points
Wol
good points
good points
good points
good points
good points
good points
good points
good points
It's much more likely that MS is targetting os x here, not gnu/linux
good points
good points
good points
Before that, the libraries were distributed with Visual Studio and were not compatible with each other.
This is why third party libraries for Windows are offered in a large number of variants depending on which vesion of Visual Studio they are intended to be linked with: VS 2005, 2008, 2010, 2012, 2013, etc...
good points
If your application is linked to a Visual C++ runtime DLL, you need to bundle the dll with your executable (by including the MSVC Redistributable Runtime installer), the SO itself doesn't include it.
good points
Wol
good points
This is bullshit.
Nope. MS went to great pains to keep applications running. ALL of them, up to including custom workarounds for some apps.
good points
Wol
good points
good points
good points
bash in windows shellon bahWindows
