Been playing with it,
and it's decent. but the fact you can't push jobs into the background is a deal breaker and I still need to use a fedora virtual machine for some serious dev work.
Microsoft has announced that Windows Subsystem for Linux (WSL) is coming to Windows Server. Microsoft's adding it to Windows Server for the same reasons it added it to Windows: it wants developers to have whatever tools they prefer at their disposal. Sysadmins are also on Redmond's mind, it says. “If you’re a server engineer …
Ingredients
1 packet trifle sponges, broken into 5cm/2in pieces
½ packet of amaretti biscuits or 150g/5oz macaroons or ratafias
150ml/5fl oz sweet sherry
1 tbsp cognac
4 tbsp blackberry or raspberry jam
450g/1 lb fresh blackberries
450g/1 lb fresh raspberries
85g/3oz toasted flaked almonds
600ml/1 pint ready-made custard
plus one fresh 6"x1", sharply tapered
This post has been deleted by its author
Or even, have they heard of MSYS2, which seems to be the favourite of all the cygwin derivatives at the moment.
If MS finish WSL, ie they completely emulate the entire Linux kernel system interface, it will be far superior to any cygwin style thing. Word has it that it's already quite good.
Should they complete it, there's no technical reason why we couldn't have a frankenOS, a Windows kernel + drivers + WSL, and an Ubuntu user land on top instead of a Windows user land.
MS might just do that for the laugh, may even give away the kernel+drivers+WSL for free.
"If MS finish WSL, ie they completely emulate the entire Linux kernel system interface"
I would imagine they already have as Ubuntu seem to run just fine. Finally Linux under a modern fully modular hybrid-microkernel architecture!
I just wish they could port some of the many security, audit and ACL advantages of Windows into Linux. See the rather good commentary from h4rm0ny here: https://forums.theregister.co.uk/forum/4/2014/04/11/openssl_heartbleed_robin_seggelmann/#c_2166427
under "ACLs & OS willy-waving" ...
"Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux"
This line describes everything wrong with Powershell.
1) It doesn't work in cmd. I know that sounds petty but are you telling me that you couldn't have merged the two? I mean, do you really think that first bit couldn't just be a command name in cmd?
2) It's overly-verbose for no real reason.
3) It has random hyphens in different places for the first command.
4) Is it "Enable-WindowsOptionalFeature" or "Enable-OptionalWindowsFeature" or "OptionalWindowsFeature-Enable"? Stupid naming, no consistency between tasks.
5) Sigh:
Enable-WindowsOptionalFeature .... big red error message, four lines long waffling about parameters.
Enable-WindowsOptionalFeature /? .... big red error message, four lines long waffling about parameters.
Enable-WindowsOptionalFeature help .... big red error message, four lines long waffling about parameters.
Enable-WindowsOptionalFeature -help .... big red error message, four lines long waffling about parameters.
Enable-WindowsOptionalFeature --help .... big red error message, four lines long waffling about parameters.
Enable-WindowsOptionalFeature -WHAT_THE_HELL_DO_I_HAVE_TO_DO_HERE .... big red error message, four lines long waffling about parameters.
6) Why do I need to specify Online? (Apparently it's not what you think: "Use the Online parameter to specify the running operating system on your local computer", i.e. nothing to do with "being online" at all).
7) This only works if you know about the command anyway, unless Microsoft tell you what the command is, there's almost no way to find it out from the machine itself (At least "Add Program/Features" was quite obvious, and even "Add Roles" isn't too far off).
I can't imagine their implementation of bash would be any better, to be honest, and I spend my life installing UnixUtls on Windows machines to do a simple text-search / replace in files on an automated basic with sed/grep.
Have you ever programmed in C? It's not exactly obvious syntax unless you've studied it, no noobie is ever going to look at code in C and pick up what it's doing, so perhaps we could be more forgiving of PowerShell attempting to make things a bit more obvious?
Meanwhile I should confess I have a total boner for PowerShell, yesterday I wrote a script to uninstall old versions of Java, and it took a whopping seven lines. I got a script to find empty security groups in AD down to one line.
The CMD vs PowerShell thing, PowerShell is the new default command line in the creators update is PowerShell,... I find myself using PS as a default now, and I'm an old fart.
The online thing makes sense to me, as we are dealing with the current, loaded system image. We're not prepping an offline image for distribution. But being an old fart 'online' used to have other meanings, pre Internet, something being 'online' just meant it was running and accessible.
If you want help for a PS command, use get-help, and start typing the command you want help with, there will be a pop up with all the commands that match the text you have entered, and it narrows down the candidates as you type. It's a bit easier than wading through 'man -k' results.
*COUGH*
---
Get-Help cannot find the Help files for this cmdlet on this computer. It is displaying only partial help.
-- To download and install Help files for the module that includes this cmdlet, use Update-Help.
-- To view the Help topic for this cmdlet online, type: "Get-Help Enable-WindowsOptionalFeature -Online" or go to http://go.microsoft.com/fwlink/?LinkId=289353.
---
So now I have to update the help files (glad I'm not, you know, trying to solve a connectivity problem or anything, because obviously the helpfiles are NOT installed by default) AND... in this instance does "-Online" mean update the local computer this time or does it mean to go online to get them?
CONSISTENCY, PEOPLE.
P.S. Update-help takes 5-10 minutes to install.
P.P.S Where's the list of optional features you could enable? Not present apparently (only example given is Hearts....)
Let me add:
8) Tab completion is useless because things like get-* match a hundred commands.
The verb-noun convention in PowerShell is perfectly backwards because the least significant part of the command name is always the prefix. (ie: It is a little-endian shell.)
"This line describes everything wrong with Powershell."
It has numerous advantage over Bash and pretty much no disadvantages. Not to mention being way way easier to understand and use? For instance:
DIR -Recurse | Get-Acl | Select-Object Owner | Select -Unique (Powershell)
vs
find . -printf "%u\n" | awk '!match(str," "$1){str=str" "$1;print $1 }' (Bash)
And here are a few of the other advantages:
1) Object oriented pipes so that I don't have to format and reparse and be concerned about language settings.
2) Command metadata. PowerShell commands, functions and even *script files* expose metadata about the names, positions, types and validation rules for parameters, allowing the *shell* to perform type coercion, allowing the *shell* to explain the parameters/syntax, allowing the *shell* to support both tab completion and auto-suggestions with no need for external and cumbersome completion definitions.
3) Robust risk management. Look up common parameters -WhatIf, -Confirm, -Force and consider how they are supported by ambient values in scripts you author yourself.
4) Multiple location types and -providers. Even a SQL Server appears as a navigable file system. Want to work with a certain database? Just switch to the sqlserver: drive and navigate to the server/database and start selecting, creating tables etc.
5) Fan-out remoting. Execute the same script transparently and *robustly* on multiple servers and consolidate the results back on the controlling console. Try icm host1,host2,host3 {ps} and watch how you get consolidated, object-oriented process descriptions from multiple servers.
6) Workflow scripting. PowerShell scripts can (since v3) be defined as workflows which are suspendable, resumable and which can pick up and continue even across system restarts.
7) Parallel scripting. No, not just starting multiple processes, but having the actual *script* branch out and run massively parallel.
8) True remote sessions where you don't step into and out of remote sessions but actually controls any number of remote sessions from the outside.
9) PowerShell web access. You can now set up a IIS with PWA as a gateway. This gives you a firewall-friendly remote command line in any standards compliant browser.
10) Superior security features, e.g. script signing, memory encryption, proper multi-mode credentials allowing script to be agnostic about authentication schemes which may go way beyond stupid username+password and use smart cards, tokens, OTPs etc.
11) Transaction support right in the shell. Script actions can join any resource manager such as SQL server, registry, message queues in a single atomic transaction. Do that in bash?
12) Strongly typed stripting, extensive data types, e.g first class xml support and regex support right in the shell. Optional static/explicit typing. Real lambdas (script blocks) instead of stupidly relying on dangerous and error prone "eval" functions.
13) Real *structured* exception handling as an alternative to outdated traps (which PowerShell also has). try-catch-finally blocks.
14) Instrumentation, extensive tracing, transcript and *source level* debugging of scripts.
15) Consistent naming conventions covering verb-noun command names, common verbs, common parameter names.
"Is it 'Enable-WindowsOptionalFeature' or 'Enable-OptionalWindowsFeature' or 'OptionalWindowsFeature-Enable? Stupid naming, no consistency between tasks."
One of the things I really liked about ICL VME SCL was the consistency in command naming; you didn't have to remember the precise name of all the commands because if there was already a built-in command to do what you wanted you could work out what it would be called. Neither did you need to remember all of the parameters for every command because you could call up a form-like template that displayed all the parameters and their default values, and tab back and forth between them to supply or change parameter values before executing.
>It could be loose language or it could be a clue to future developments. <
It's absolutely typical MS product announcement. "Windows 10 includes a Graphical User Interface". "Windows 10 does not currently include Nuclear Fusion".
MS never admits features existed in past products, and since the vapourware scandals of the 1980s with the possible anti-trust implications, MS has been very careful about anouncing only actual products.
But I've always suspected that it's because the people writing the PR/press/documentation have no idea at all other than what they are told.
Microsoft's long-term plan for dealing with competition hasn't changed in 30 years. I see no reason to celebrate their embracing of something I currently use.
Then again, their position isn't as strong as it once was. Linux completely owns the OS market. The year of the Linux desktop is probably never coming, true, but the year of the Linux everything else just keeps repeating itself and getting bigger every time. Everything else is a MUCH bigger market.
Then again, their position isn't as strong as it once was. Linux completely owns the OS market. The year of the Linux desktop is probably never coming, true, but the year of the Linux everything else just keeps repeating itself and getting bigger every time. Everything else is a MUCH bigger market.
What keeps MS in position is all the established software vendors who only produce Windows versions of their products. If they produced Linux versions too then a lot of people would shift. Not all, if you've got a thousand PCs to manage, MS have put a lot of effort into making central administration easy to do, and Linux would have to make significant advances in that direction. It probably has most of the hooks required but I'm not aware of anything that ties it all together.
When I unfortunately had to do occasionally do shit on a Windows box and dearly wished I could just scp over my bash scripts that did exactly what I needed?
Oh well, by forcing the customer to create a Linux VM as a scripthost maybe I did my small part in making Windows less palatable to them as a server in the long run...
The WSL "experience" is much more like working in a Linux container that having a Linux userland integrated with the host system (along with its own dedicated /home separate and apart from Windows C:\Users). That works well for some requirements, like developing scripts or apps to run on Linux. But as the article reveals, it doesn't allow you to run Linux services or (easily) use Linux tools on Windows. Cygwin and Msys allow that because they're actually running on, rather than in, Windows (Msys-based Git for Windows does a good job of living in both worlds simultaneously, although its too minimal to do services). Still cumbersome, but more useful overall to many of us. Having WSL on the server without that capability is pretty much a waste. Better to have a full Linux server VM for most purposes.