Looking Forward: Support for Secure Shell
blogs.msdn.com
blogs.msdn.com
That has completely changed in the last eighteen months. Each time I think "wouldn't it be cool if" I'm finding a few weeks later that someone at Microsoft is well ahead of me. How much easier it will be to ship my sucky roguelikes to Windows users in this new world!
Hmm. They can now have a path to obsolete cmd. As long as they ship a decent ssh client with the system, users will become accustomed to ssh-ing to their own box instead of using cmd.
Wishlist: tmux, emacs, vi, netcat, shell option for vi-mode, rc-file with preferences, ncurses library, something simpler than curses, zip and unzip. 256 colour is fine, although 24-bit would be impressive. /proc would be cool, but also a big ask I assume. They already have a strong compiler. Make it really easy to find the hex fingerprint required to log on to the sshd-server. Something like inetd could be useful, too.
mobaxterm - http://mobaxterm.mobatek.net/
I ran cygwin-with-ssh heavily for a while in 2003. It was a hell of a thing to get it going. Then I had trouble getting it to work on a new computer and gave up. Shouldn't be surprised that it got good again.
Wait, isn't that nearly everything you ever install on Windows? Not complicated per se, but everything is third party and not signed by people maintaining Windows (as with most GNU/Linux distributions).
<http://www.reddit.com/r/sysadmin/comments/38ba26/professiona...
No thankyou. I can certainly understand including SSH support, but I don't want what is pretty much the only remaining viable non-Unix platform to start bundling horribly dated and clunky Unix-like commands and bloated GNU tools.
As a die hard Unix guy and ex Slashdot-esque zealot (colloquially a bit of a twat). Yet I'm knocking out PowerShell all the time now and dread having to log into the pile of CentOS kit I have lying around. It is arcane. Even after 15 years I spend most of my time in the manpages or working out another damn config format.
Literally did a two liner to scrape a web page, parse it and call a REST endpoint with the parsed data as JSON in PowerShell. I cant even use python now. I've been broken.
It makes me cringe saying all this as well kind of like a racist making amends with his past.
The only thing I still hate is windows update.
I understand that lots of people are familiar with Unix-like tools and their many idiosyncrasies and like to be able to transfer that knowledge across platforms. But that doesn't mean there isn't merit to a platform not conforming to that and trying to improve on it.
Or I guess another way to say it is that "bloated" is only a measurement of the speaker's disdain for the software under question. It has little relationship with any actual quality measurement, generally. Bizarre on its face, to me.
Bloat seems like dirt that accumulates overtime. A little bit of cleanup and optimization can sometimes do magic.
Microsoft chose one answer to that, Apple another.
I think Windows Phone is a clear example that Microsoft has technical chops when starting clean, it just lacks business willpower to make decisions that favor performance over support.
all those "2 liners" don't mean much if you have to reboot your box every 2 days to apply more emergency 0-day security patches.
Only ones that affect the network surface footprint, so none here as it's on a private VLAN.
I assume that "private VLAN" means it isn't exposed to potential external attack.
Patching servers is just good practice. As is designing a system that can handle rebooting individual servers without user-facing downtime.
b) They won't download anything wrong. There's no route to the internet for this machine.
c) They won't visit any web sites. There's no browser on the machine. This is a core profile windows server installation.
Don't assume that we don't know what we're doing. We have 500ish Windows Server machines floating around.
It's good that you've managed to perfect the hiring process to the point you have zero risk of internal fraud or malice.
Nowhere!
What does that have to do with security updates and reboots?
Nothing!
This is a Hyper-V hypervisor host on a private VLAN three layers behind the internet and two layers behind the users locked in a room with no console access other than via an ILO card on yet another VLAN.
There has only been one KB which infers a security problem and that has had alternative mitigation put in place.
Not rebooting your server doesn't imply incompetence or disregard to security.
This sounds cool. Can you recommend terse resources for getting to know PowerShell? Is MSDN the best place to look for docs or are there better places to go?
http://social.technet.microsoft.com/wiki/contents/articles/1...
Scrape a page:
$flight = " LH3396"
$url = "http://bing.com?q=flight status for $flight"
$result = Invoke-WebRequest $url
$elements = $result.AllElements | Where Class -eq "ans" | Select -First 1 -ExpandProperty innerText
$body = @{
Name = "So long and thanks for all the fish"
}
Invoke-RestMethod -Method Post -Uri "$resource\new" -Body (ConvertTo-Json $body) -Header @{"X-ApiKey"=$apiKey}
[1] http://stackoverflow.com/questions/9053573/powershell-html-p...
[2] http://www.lavinski.me/calling-a-rest-json-api-with-powershe...
This lets everything implicitly understand how to access named properties without everyone having to do string parsing.
Sure, you can solve the same problems with bash/grep/awk/sed/etc - but sometimes it's a bunch simpler to solve in Powershell.
PowerShell handles objects like Unix utilities handle text. You get a lot more orthogonality in commands, e.g. there's just a few commands dealing with JSON, CSV, XML, etc.¹ – they mostly do just the conversion of a specific text-based format to an object list or tree representation and back. Everything else after that can be done with just the same set of core commands which deal with objects. Filtering, projecting, and iterating over object sequences is probably the most common part of PowerShell scripts and one-liners and it's a part that's useful everywhere you need the language. Note that we have a bit of that in the samples here, too. ConvertTo-JSON is used to convert a hashmap to a JSON string to use in a request, and Invoke-WebRequest already handles parsing HTML for us so the following line can just filter elements by certain attributes.
Where the ideal format for the core Unix tools you use most frequently, is free-form text, you often have special commands that work on other formats by replicating a few core tools' features on that format, e.g. a grep for JSON, a grep for XML, etc. There are others, of course, that do the conversion in a way that's friendly to text-based tools, but the representation still lacks fidelity. Finding XML elements with certain attributes quickly becomes an exercise in how to write robust regexes. Cutting up CSV by column numbers is a frequent occurrence – and since the tools do not understand the format it makes for not a pretty read in the script's code. Personal opinion here, based on lots of PowerShell written, some shell scripts written, lots of horrible things read in either (sure, awful PowerShell scripts do exist, but I'd argue that discovering a nice way is much easier where you can cut most of the ad-hoc parsers written in regex or string manipulation in pipelines).
(One last point about orthogonality of commands: ls has a few options on how to sort or output the results, for example. Sorting a list of things? That's Sort-Object's domain. Formatting a list of things? Format-Table, Format-Wide, Format-List. That's quite a bit less each individual command has to do and it's all just for nicety to the user. For working with the output programmatically you don't (well, and can't) need them at all.)
I have a few posts on SO where I tried to steer people into actually learning how the language works and that you should use the pipeline as much as possible, e.g. http://stackoverflow.com/a/7394766/73070 or http://stackoverflow.com/a/3104721/73070. That's not to say you can't write un-understandable things: http://stackoverflow.com/q/1018873/73070.
And finally, let's not forget that PowerShell exists on Windows where text-based tools are mostly useless. Want to query the event log? The registry? WMI? Good luck. Windows has a long history of having non-text formats everywhere in the system and for administration it's a bit hard to pretend they don't exist. Jeffrey Snover elaborates a bit on that here: http://stackoverflow.com/a/573861/73070.
There may be a lot of developers getting by with Unix tools on Windows, but they're not the target audience for PowerShell³. And the previous approach to scripting things on Windows servers and domains was either batch files or VBScript/JScript.
This ... uhm, got longer than anticipated and probably a lot less coherent than planned. Apologies for anything that makes no sense. I didn't have caffeine yet.
______
¹ ConvertFrom-JSON and ConvertTo-JSON for JSON for example. For CSV there are also convenience commands that directly work on files as well, so there's four of them. XML processing is built-in since .NET can do that easily already.
² I probably don't get to live the rest of the day now, I guess.
³ I am a developer, though, who uses PowerShell daily for scripting, as a shell, and a .NET playground. The PowerShell team at MS was a bit surprised once when I told them that my background was not server administration (the Scripting Games were quite focused on that part and often involved doing things with WMI or AD – stuff I rarely, if ever, do.)
Just incited me to have a little look at powershell (read through [0], useful intro). It looks nice, I can definitely see the utility in have a simple object model for transferring information between processes. In nix land you get pretty good at extracting data from simple text forms, though sometimes it's harder than it should be.
One thing that jumped out at me there is the overhead of the commands.
430ms: ls | where {$_.Name -like "*.exe"}
140ms: ls *.exe
27ms : ls -Filter "*.exe".
What happens when you add another command to the pipeline? Do they buffer the streams like in linux?
I guess the situation will improve over time but how complete is the eco-system at the moment? One area nixes will always shine is the total ubiquity. Everything can be done over commands and everything works with text.
[0] https://developer.rackspace.com/blog/powershell-101-from-a-l...
It's not uncommon for the most flexible option to be the slowest, though. In my own tests my results were 18 ms, 115 ms and 140 ms for doing those commands in $Env:Windir\system32, so the difference wasn't as big as in your case. For a quick command on the command line I feel performance is adequate in either case, unless you're doing things with very large directories. If you handle a large volume of data, regardless of whether it's files, lines, or other objects, you probably want to filter as much as you can as close to the source as you can – generally speaking.
As for buffering ... I'm not aware of, unless the cmdlet needs to have complete output of the previous one to do its work. Every result from a pipeline is passed individually from one cmdlet to the next by default. Some cmdlets do* buffer, though, e.g. Get-Content has a -ReadCount parameter that controls buffering in the cmdlet (man gc -param readcount). Sort-Object and Group-Object are the most common (for me at least) that always need complete output of the stage before to return anything, for quite obvious reasons.
However, even though I did some work on Pash, the open-source reimplementation of PowerShell, I'm not terribly well-versed in its internal workings, so take the buffering part with a grain of salt.
As for completeness, well, the Unix ecosystem has an enormous edge here, simply by having been there for decades and amassing tools and utilities. Since PowerShell was intended for system administrators you can expect nearly everything needed there to have PowerShell-native support. This includes files, processes, services, event logs, active directory, and various other things I know little to nothing about. Get-Command -Verb Get gives you a list of things that are supported directly that way. It seems like even configuration things like network, disks and other such things are supported by now. At Microsoft there's a rule, I think, that every new configuration GUI in Windows Server has to be built on PowerShell. Which means, everything you can do in the GUI, you can do in PowerShell, and I think you can in some cases even access the script to do the changes you just made in the GUI – e.g. for doing the same change on a few hundred machines at once, or whatever.
Of course, you can just work with any collection of .NET objects by virtue of the common cmdlets working with objects (gcm -noun object). For me, whenever there is no native support, .NET is often a good escape hatch, that in many cases isn't terribly inconvenient to use. You also have more control over what exactly happens at that level, because you're one abstraction level lower. As a last resort, it's still a shell. It can run any program and get its output. Output from native programs is returned as string[], line by line, and in many cases that's not worse than with cmd or any Unix shell.
_____
¹ Keep in mind, the file system is just one provider and there are others, e.g. registry, cert store, functions, variables, aliases, environment variables that work with exactly the same commands. That's why ls is an alias for Get-ChildItem and there is no Get-File, because those commands are agnostic of the underlying provider.
² So much for do one thing – but understandable, because ls' output is not rich enough to filter for certain things further down in the pipeline.
Was just a bit surprised at the overhead of adding a command to the pipeline. A similar setup on linux would be like the following I guess (on a folder with 4600 files, 170 matching files).
20ms time ls *.pdf
35ms time find -maxdepth 1 -iname '*.pdf'
60ms time ls | egrep '.pdf$'
$ sudo apt-get install html-xml-utils jq
$ curl 'https://duckduckgo.com/html/?q=cake' | hxclean \
| hxselect .web-result:first-child .snippet
$ curl apy.projectjj.com/listPairs | jq .responseData[0]
Don't know if it's any good --- never tried it; it says it's about half complete, but I don't know if it's a useful half.
After looking at the docs, you could do a lot of what Powershell does with Unix shells; you'd need a different set of conventions, where instead of using unformatted text as an intermediate format you used a streamable table format with support for metadata. Then you could have commands like 'where', which would be awesome.
$ xps | xwhere user -eq dg | xsort -desc rss | xtop 10 | xecho "rss=@.rss cmdline=@.command"
...or something. sh syntax is a bit lacking; PowerShell's got lots of useful builtins, including having native support for the format so it knows how to present it to the user. An sh version would conversion routines back and forth from text.
The tricky part would be bootstrapping; getting enough functionality quickly enough that enough people would start using it to make it sustainable.
I'd still rather use this than faff around with awk, though. I've done way too much of that. And if I never have to parse the output of ls -l using cut again, I will be a happy person.
The whole point of the GNU system was working around the usual "I can see it here, need this bit, and want to put it there". If you need to do something really specific a lot, you write a tool which does that.
When we want a text oriented API we use shell scripts. When we want an object oriented API we pick our favourite scripting language - which may very well for many of us be different for different problem domains.
The point of the exercise is that the traditional Unix pipelinable commands have standardised on unstructured textual data. Powershell has standardised on structured tabular data, which is what lets you do the cool things.
find "$@" -printf "%TY %Tm %Td %TT %1y %4m %3n %4U:%-3G %8s %p\t%l\n"
But I've never tried it; just came across it recently as a homebrew update.
There are at least two parties working on it who have interest in certain features to be working: It's the NuGet shell within MonoDevelop, so custom PowerShell hosts need to work as well as a bunch of things needed by NuGet. Then one of the more prolific developers actually gets paid to work on Pash to support features related to PowerShell add-ins and a few others. (My own efforts so far were mostly bits and pieces, missing cmdlets (there are still a lot of those), test cases, and weird parser behaviour, mostly due to my history of golfing in PowerShell – golfed code makes for some fun tests of edge cases.)
Try stat instead, e.g.
$ stat -c 'NAME: %n; OWNER: %U, SIZE: %s' *
Can you post this 2 liner? Sounds interesting.
This isn't stocks, shares, futures etc for ref either.
I don't want to say any more nor post any code as it's unique and a good earner at the moment.
Now that's teasing ;)
Let me guess: arbitrage applied to sports gambling. Wink my way if I'm on the right track.
Update-Help
Then you can type "Get-Help About_" and hit tab to see the master topic lists.
Ah also POSIX compliance could simplify the life of those who develop on Windows. I tryed to develop on Windows for many years, I tryed hard but you are always missing some feature that on Unix is basic.
I tend to use PowerShell ISE that is built into windows rather than cmd, which you're right, sucks.
If you were coming from the Unix/BSD world, I could understand this, but how is using a GUI for everything considered elegant, while GNU tools are considered "bloated?" Doesn't the GUI necessarily "bloat" the program more than a few extra command-line options would?
Embedded Windows, on the other hand, is forever the poor relation.
Windows could do a lot better than curses by providing easy means to pop MFC dialogs from the shell to prompt the user.
Zip and unzip are already available, in https://pscx.codeplex.com/
> Who uses vi-mode in the shell?
> Windows could do a lot better than curses by
> providing easy means to pop MFC dialogs from
> the shell to prompt the user.
With deliberate effort, you can build automation to Windows platforms. But in unix, one guy with a clue can create vast value working with the defaults. Even on an ancient Solaris box with no compiler or extra tools installed. If you're desperate you'll be able to find a shell that can open a socket server or staple some awk together to get a result.
Windows powershell is a vision of what a shell can be that has grown up separate to the unix world. In a fair world it would be considered heavy-lifting-equipment, like bash or emacs lisp. It would be thriving. But it has lived in a straight-jacket because until now Microsoft has forced operators to to interact with it via the windows GUI.
MFC popups would undermine the benefits of SSH. If you're worried about your shell hanging at a background window event, you'll avoid using it in anger.
Same issue with editors. Existing editors require the GUI layer. A strength of ssh is how well it suits you when you want to dive on to a host and make a fast change.
This was common on the Amiga. E.g. tab completion in the shell can bring up a pre-filtered file requester.
One line is enough for everyone.
Why do you think that is? As in, why is everyone else on unix (like toolchains)? Why do you think pretty much the entire tech-stack of mobile and web companies has moved to Linux or BSD as the default choice.
The reason is clear. The unix "small tools connected by text based pipes" philosophy has won. Whether disaffected powershell users find it clunky or not is not the point. Unix tools are the lingua-franca of developers everywhere.
There are many reasons for this but the most important is that the commandline toolset for managing a machine from a remote terminal has always been the most important UI for unix over the last forty years. You can call it "dated". The industry calls it "the standard".
The irony here is that Microsoft itself has come to the realization that they have to follow where the developer ecosystem is inexorably marching en mass. There will of course be a certain percent of holdouts clinging to their powershells. But now they'll be fighting against not only the linux'er and BSD'rs. But Microsoft management itself.
I'm not sure I understand what you mean here ...
My OS X desktop/laptop (for instance) have ssh on them, but I almost never ssh to them ... I just open up a local terminal window.
Genuinely curious as to why one would ssh to their windows system rather than just run cmd.exe ...
Not all of us who manage (partial) Windows environments run Windows or care to click around a whole bunch of times if we can just use the terminal we've already got open & focused.
Baby steps! SSH is a transport protocol, not a shell. If you SSH to your own box, you're just going to get PowerShell.
Will happily run a cmd window, or other command you supply (e.g. I run a cygwin zsh)
One of the big missing features in Windows is lack of SSH transport. Sure, its terminal emulator is adequate at best, but it does have one. The major news here is that it will finally be possible to remote into a Windows host the same way we remote to everything else.
Which never rang really true, but NT had promise.
http://www.uniforum.org/publications/ufm/aug96/unix-nt.html
https://books.google.fi/books?id=g0CPF6MEFcUC&pg=PA1&lpg=PA1...
Interix release 6.1 is available for Windows Server 2008 R2 and Windows 7 for the Enterprise and Ultimate editions.
I'd say Microsoft has been been more pro-developer than most and I'm super glad that I chose to live primarily in their ecosystem because they make my life easy compared to the mess I have to put up with in Unix-land.
There are two worlds in desktop software development – the "open-source-unix-y" world, and the "Microsoft" world. The former has typically meant having a broad range of excellent tooling; it's certainly been a bit messy, but that's mostly because of the ease with which things have been able to change and develop. Even development in the Apple sphere has always involved the same basic tools.
On the other hand, development using the Microsoft platform has traditionally been an entirely different process and toolset. It's cleaner, in the sense that there's less diversity and a greater focus on compatibility (to some extent). But the tradeoff there is that it's often been slow to keep up with developments in the rest of the industry, and did not allow users access to open, standard tooling that other developers had.
That is changing now, and we'll start to see the best of the traditionally locked-away Microsoft platform make its way into open-source platforms, and vice versa. That's not a bad thing, but I think it's pretty foolish to consider their past stance as 'developer-friendly', especially considering the number of frameworks and toolkits they've pushed and abandoned over the past decade. Hopefully, that is changing.
Not at all - go ask any devops/IT group running in small, medium and large businesses to replace their Microsoft tools with a competitor's (if you can find one) or FOSS tools and they'll laugh in your face because of how easy Microsoft makes things for them.
> But the tradeoff there is that it's often been slow to keep up with developments in the rest of the industry...
Considering that Microsoft kicked off Web 2.0 with the invention of XMLHTTPRequest and the iframe, I'd have to disagree.
Your whole argument is closed == bad and that's simply not true.
IT is a bit of an outlier. But I must admit, I've never encountered any self-described 'DevOps' who uses anything but Unix. Different spheres, perhaps.
Considering that Microsoft kicked off Web 2.0 with the invention of XMLHTTPRequest and the iframe, I'd have to disagree.
That's a bit shallow – every technology company has developed some tools and techniques that were ahead of the curve. It doesn't mean that their entire platform is.
Your whole argument is closed == bad and that's simply not true.
No, my argument is that closed has a very large downside, and that if you don't bear that in mind it's going to harm you later.
The argument about Ajax coming from Microsoft is a bit shallow. (Sorry that's all the effort I felt like putting into it at the moment.) Here are a couple other thoughts along the same vein:
1. Microsoft has done extensive research into many areas of tech that are just now blooming, such as mobile and tablet computing. They had a general purpose mobile OS with multiple third party app-stores before any of the modern industry players. They had tablets. I think the industry caught up to Microsoft while they were busy making money elsewhere.
2. Look how quickly Microsoft can pivot into doing the kinds of things that Amazon AWS, Google and Apple are doing. I think it's a testament to how "there" their platform is already.
> ...closed has a very large downside...
It can be a huge upside too. Developers have been making lots of money off of tightly controlled, closed software platforms like iOS and Windows for a long time.
The web is the only completely free open source "platform" that I can think of that is a huge hit with programmers and that people generally use. However, in my opinion - programming it sucks compared to the closed, native systems.
That hasn't been my experience. Microsoft has always been supportive of my compiler company, even providing Microsoft tools to be bundled with it. In fact, a huge reason MSDOS was so enormously successful was the ease with which anyone could (and did) write and ship software for it. Microsoft was well aware of this and supported it.
I am a linux guy who did his intern in Microsoft. That was the first time I appreciated Powershell and from then I am in love with it. Its object oriented nature makes thing easy, fluid, understandable. I can never run linux command line with Google but with Powershell, its possible with the way it manages help pages.
First, let's have a copy tool with delta-sync support. I can't believe I have to use a cygwin-based rsync to quickly update my backups throughout the day (currently: shut down Virtualbox dev VM, rsync changes, start VM).
I understand the MS way to do it is DSFR, but for a single developer workstation that's overkill.
I would love to be wrong.
I am a big supporter of Powershell, and while Powershell has supported remoting since almost day one, it will never enjoy quite as much support as SSH already receives (e.g. third party tools, firewall support, etc). It is also nice that they're looking into using something fairly "proven" secure, OpenSSH is exposed to the internet a lot (even if, yes, that is not best practice) so we can reasonably expect it to withstand day to day attacks.
In general people really are starting to run out of reasons to "hate" Microsoft. It will be interesting to see what they come up with in the future...
PS - I really hope later they expand this to SFTP support. SFTP is significantly better than either FTP or FTPS, and something Windows has lacked since forever.
Please elaborate.
And as others have mentioned, either way it's still good practice to disable password auth, so that you can only connect to SSH using a public/private keypair.
If you're whitelisting IPs, you may as well run it on port 22.
Color me skeptical. I shall decline to "trust you."
Sterling work establishing your own competence there.
So now, since any attack has to be through the bastion, and all bastion errors are looked at by a human (because there should be only a few of them), then you're more likely to notice a breach more quickly because it won't become caught up in your general logs.
It should be noted that it's as easily possible to have the bastion server run an SSH server, and allow SSH access to other servers on your network.
Also, sshd + fwknop (port knocking) is a very secure combo, IMO.
openssh always responds (unless I've missed a recent feature) thus exposing which port its listening on and that you sent a bad key.
The silent failure is preferable for this application.
Port knocking gives you a roughly equivalent layer.
Not to mention: nobody's going to be brute-forcing properly generated keys remotely. And if they're not properly generated, you have much bigger problems.
Like the GP said - you're trading VPN bugs for SSH bugs - and experience shows that betting on SSH is generally wiser.
If you only need TCP/DNS and not a full-blown VPN, a program called sshuttle uses ssh+python to provide excellent seamless poor man's VPN. It's not perfect - e.g., you lose the ip src address on the forwarded connections - but it works amazingly well, much better than e.g. openvpn and most other vpn products I've used.
And you're also manually creating SSH tunnels to do anything else inside that network, so you've got that going for you, too.
It's 2015. A VPN is the settled method for accessing sensitive services inside a private network. Doing otherwise may create great nerd cred but doesn't make you do your job better.
I agree with you overall, MS has made GREAT strides in the last year towards moving my needle from "Wouldn't touch if my life depended on it" to "Huh, that's actually pretty interesting". The old MS still shows through with things like how they are handling Win 10 (Both in versions and cost) but overall they are looking up. That said MS still has a long ways to go and I still wouldn't use Windows for anything (other than gaming) but some other stuff MS has done does interest me.
I'm a bit confused by this. It's free for any genuine Windows 7 or 8 user, and $99 to $199 for anyone else. There are two SKUs (Home and Pro), rather than the multitude with XP or Vista. How is this not a reasonable approach? Especially since Windows 10 is supposed to be the last Windows release of this kind.
I'm echoing speculation I read elsewhere: the reason for the numerous versions is Federal Money. The US government demands that it pays the lowest price the vendors offers an item for. Since Microsoft likes to offer discounts to universities, the government would be entitled to the lowest discounted price on the SKU. Their solution is to make Education & Enterprise versions and maintain the price disparity. Money trumps simplicity.
https://blogs.windows.com/bloggingwindows/2015/05/13/introdu...
(edited for clarity)
Its only two consumer-facing desktop SKUs, but that's the same as Win 8.1. Its still down from Win 7, though.
It's free ONLY if you get it in their window (1 year I think) it just seems unnecessarily complicated when they should just make it free. Also they have 3-4 more SKUs than just Home and Pro (which really should only be 1).
> Windows 10 is supposed to be the last Windows release of this kind
I'll believe that when I see it also there is nothing I've seen so far to imply all further updates would be free.
Apple can make their OS free cause they make money on the hardware, which 99% of people buy from them to run the OS on.
And of course linux and other open source is another story.
Never once have I met a person buying a standalone windows upgrade/windows OS. Either they end up buying a new computer, they stick with whatever was installed on their computer (hello, XP/Vista users), or they illegally download the upgrades.
For example, a good amount of the people that have Macs also need to run Windows virtual machines (or Bootcamp), and the primary way to do that is to buy a retail copy of Windows. I can't imagine that's a very high percentage of revenue, but I wouldn't say that nobody buys Windows directly.
Do people not care about this?
I'm not a big Windows fan (I've run Linux as my primary OS for years), but I've bought several Windows OS packages over the years for work (testing software).
Two SKUs, and then a bunch more; whole list currently is: Home, Mobile, Pro, Enterprise, Education, Mobile Enterprise, IoT core. There are also upcoming still unnamed "industrial" SKUs. Oh, and of course MS is going to offer 32 bit versions too.
Also of course there will also be full suite of Windows Server SKUs, because obviously those are completely different from the client OS...
Is for an entirely different class of devices than the others.
> IoT core
Ditto
All the others are price discrimination for organizations. The typical end-user does not have to contend with the list you put forth.
And if we want to install a syslog forwarder on their domain controllers... no one ever trusts software installed on their domain controllers. Everyone trusts a single line in syslog.conf.
I heard this kind of thing from a vendor the other day. It's like people don't even try to learn how it works.
Why are they different? The event log has some transactional guarantees that were required for a specific kind of security evaluation...C2? I can't remember the rest.
The thing is...you don't have to install a client on the domain controllers. You can setup forwarding to some log hosts and collect them there.
It's much harder to know how it works, for some reason. Information like this doesn't make its way into the community and circulate. On a UNIX system you can poke around /etc and get an idea of the scope of what is configurable. The same is very much not true of the registry and only slightly true of WMI.
To get into it in any depth you have to approach windows programmatically. The most power is through C\C++...to be a good windows admin you need to read the docs about how you interact with different subsystems, even if you aren't going to code against them.
That's an interesting way of putting it. I strongly prefer the Unix way then,(just avoid turing complete config languages).
I'm not saying that I think that the UNIX WAY is ever going to go away...but I do think that extreme scale makes the programmatic approach to configuration make more sense. Instead of treating every system as a "system" you treat it as a simple programmable node among thousands of others. You are already starting to see Linux go this way with systemD. The stuff that the CoreOS people are doing with etcD, fleet, and flannel are really the future of *NIX.
Please cut me some slack...I'm NOT TRYING TO ARGUE ABOUT SYSTEMD. I'm just saying that it's oriented towards developers using API's. That's one of the reasons why admins who are used to the "one true way" dislike it so much. And they should have options if they don't want to use it. I'm just saying that cloud scale deployments are driving changes to infrastructure to make it more "programmable". I'm not even saying it's "right"...Its just a observation.
I suspect there's a scaling issue in here as well. Tools optimised for large numbers of systems are always going to look clunky and overdesigned when used on a single system.
With regard to APIs, I think this is one area where the availability of source is quite critical. "Control Panel" is clearly a tool that manipulates some API, as are all the snap-ins, but because I can't see the source
(I recently had to fix a WinCE issue by trawling the source to find the right registry key. While Windows has a power user community, WinCE really doesn't, and is subtly different in enough places to cause problems. Google sometimes makes me feel like I'm the only person using CE 7)
I get what you are saying. I don't think that the programmatic model of administration works for running something like PeopleSoft, right? You use large hosts that are very special and benefit from the traditional admin model. It's very much a "pet"...where the CoreOS model is more "cattle".
I'm more ambivalent about access to source as long as there is good documentation and debugging tools. I'm not going to fix a kernel bug at this point in my development. Maybe one day...
For sysadmins the nix way of text in and text out allow systems to be as simple or complex as they need to be, because parts can be swapped, added or removed as needed.
The kernel don't care what your initial process is (you can for instance point the Linux kernel straight at the sh binary and be presented with a root shell the moment the kernel is done getting the hardware up and running), and the programs you want to run don't care either.
Thus you can run nix on anything from a dinky single core SoC to a warehouse sized compute cluster.
But systemd is pandering the latter while giving the former the middle finger. This by ignoring the text in text out loose bindings that has been the core of *nix.
Maybe systemD and it's author's are whatever...I think that the CoreOS people are demonstrating that programmatic administration is the best model for massive scale. That's my only point.
As such the server end started out being a beast all its own...
Still more flexible than systemd though, as i can run a X server on, say, Windows to get the UI of a program running any kind of nix out there.
I've worked in security with several different SIEMs for half a decade and those are the only options I've ever seen. So if there's something else besides this that is easier, it's not just me who is missing it. HP, Dell, Intel and a dozen other companies are missing it as well.
Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller.
Its not just RPC. That's the thing I've noticed about a lot of security people... they don't even really pretend to take windows seriously despite its insanely large footprint and exposure at an organization. For what its worth... most IT people are just as bad. I'm trying to turn that around at my organization. I don't blame people...I get it. It just takes time to disseminate info.
Its called event collector. Spread the word.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb4...
You'd be surprised at how many organizations will have the management spend $1.5m on a SIEM but the engineers refuse to use another Windows license.
There are ways to collect Windows logs. It's just not as easy as collecting syslog. And syslog doesn't need a user account to collect logs.
The first reason for which I have historically hated Microsoft is because of how they fought open standards. I can't believe that Microsoft changed in any meaningful way when I can't get a Lumia phone or Outlook to work with CalDAV / CardDAV. And that's just one current annoyance, as we can always talk about ODF, OpenGL and others.
The second reason for why I hated Microsoft is for their funding of SCO's lawsuit for the ownership of Unix. That was a long time ago, they must have changed right? Except that currently they are behaving like a patent troll, extracting profit out of Android through what can be described as racketeering, more profit than they do from Windows Phone.
The third reason for why I now hate Microsoft is for how they are (again) pushing for Trusted Computing. It's basically what happens when the OS provider becomes the gatekeeper of what you can install and do with your own computer. I never took this as a threat to personal computing, except that now Apple has made it acceptable. Things like insisting on logging in with Microsoft accounts, or only being able to install "modern apps" through their store (while taking a revenue cut of course) would have been unthinkable only 10 years ago. So thanks Apple for shifting the overton window, thanks Microsoft for delivering it to PCs.
Of course, "hate" is a strong word. I don't really hate them, I just speak against them. But given how people fill the forums lately with messages of the second coming, I'm wondering what the heck are these people smoking, because I want some.
My dislike of MS is quite simple. I simply don't like their products. That doesn't mean I automatically love OSX or Linux. IMO OSX is a mediocre product with a polished user experience and Linux as a desktop is just broken. Unfortunately, I can't say there is a single OS that I like at the moment.
This is a popular position, yes. But Microsoft in particular have tried to make Linux impossible on a number of occasions over a period of decades, so it'll take a while for the guerillas to come out of the jungle and stop fighting them.
But now they're in competition with the platform that want to annex all your personal data and the platform that want a veto over all applications, so they're not necessarily the most hated party in the room any more.
Linux could have survived in peaceful co-existence without the corporate billion. It would have been smaller and more hobbyist. It could not have survived if all the judgements had gone the wrong way.
I like how whenever we bring up this popularity argument, we are in essence talking only about 2 or 3 companies, the big ones. Here's another picture: http://www.openinventionnetwork.com/about-us/members/
I have to express strong disagreement with this entire sentence. OpenGL on Windows desktop continues to suffer greatly from Microsoft's lack of support. OpenGL is more relevant now than ever before due to the dominance of OpenGL ES on mobile and web. Microsoft is starting to support it themselves with WebGL in IE11 and the announced iOS/Android app support for Windows 10. They even joined Khronos Group, but they're still clinging to proprietary DirectX for the Windows desktop, to nobody's benefit but their own. And finally, Vulkan is more interesting than either Metal or DX12 due to being cross-platform, and if Microsoft continues to ignore it in favor of DX12 and we have a repeat of the OpenGL vs DirectX situation it will be a huge shame.
In what way? I write graphics code for a living and from what I've seen opengl is basically fine on windows. They could do more, sure, but I never felt like they were getting in the way.
I have mixed feelings on the directx thing. In principle I'm not a fan of directx, but in terms of API quality it's vastly better than opengl. Admittedly that's not saying much: opengl's design kind of sucks. State management when almost every state you set is global is a nightmare.
If you would try to ship OpenGL game you'll find out that Windows 8+ shipped with crippled AMD Legacy driver (HD2XXX-4XXX) that don't have OpenGL support in it and can't be really replaced using AMD Catalyst installer until user manually install new driver via Device Manager using extremely tricky way.
There was also crippled Intel drivers without GL support, but as far as I aware new drivers are shipped with GL already.
Other issue is that Windows 8+ had default behavior to replace manually installed drivers with GL by newer "Microsoft version" without GL, like that: http://answers.microsoft.com/en-us/windows/forum/windows8_1-...
In the end it's only Intel and AMD fault that they don't care enough to put pressure on Microsoft or at least release proper installers. BTW Intel's "The driver being installed is not validated for this computer" bullshit only prove how little they care about GL on Windows.
So comment above stated "opengl is basically fine on windows". No, it's not. Any person that tried to ship or support OpenGL-powered software know that.
Yes, but it only works with Gmail (and iCloud) accounts, not arbitrary CalDAV/CardDav servers. Some people have had success with adding a fake iCloud account then modifying the server address, but it's not officially supported and really shouldn't be relied on to work properly.
I really hope that Windows 10 Mobile includes official support for CalDAV and CardDAV.
And the "grandma" argument falls flat on its face when you've got an app store filled with scams, mallware and trademark violations. It's also a funny argument given that platforms other than Windows haven't suffered from viruses as much. One could say that if Windows wouldn't exist, we wouldn't have this argument in the first place.
Are you talking about firewall easy-to-setup?
FTPS being FTP-based, and FTP being a terrible protocol, SFTP > FTPS definitely. You get all the advantages and security of SSH with SFTP.
I have tried to look it up, but the answers seem to revolve around firewall being hard to setup and FTP being not secure (which is resolved by encapsuling it in SSL).
Also my search suggests than ssh provides an additional overhead compared to using ssl for file transfer (i.e. http://serverfault.com/questions/131240/ftp-v-s-sftp-v-s-ftp...)
Is that code for Ballmer's regime vs Nadella's regime?
To give a concrete example of the changes (heard from a former Microsoft employee): Under Ballmer they were not allowed to touch anything open-source. Pretty soon after he left that was changed to a policy that a BSD/MIT open-source solution must be used if it is available unless there's a damned good reason.
Still, Steve Jobs was not an easy guy either. I don't know if he would mock an employee for having an Android phone? Not unlikely given how anti-Android he was.
As far as cost of macs I think it's still worth it even if you want to run Ubuntu as your OS b/c they hold their value better than any other laptop I've seen on the market. They also resell FAST which is very nice.
I also found it to be a huge pain to install Linux on it, which is why all my Linux computers are Thinkpads (with the exception of the old HP workstation I'm typing this from).
With all the announcements around stuff like Docker for Windows Server Containers and cross platform .NET, this was nearly inevitable. Now the server management also steers in the right direction.
Disclaimer: ms employee doing tons of open source.
If I am forced to use Windows in an Enterprise setting, then I just go to Control Panel and enable the POSIX layer ("SUA"), then download the SDK and install. With some minor changes to the %Path, it just works.
SUA has older versions of tcsh, ksh, vi and many other utilities, including an older Perl and an old GCC toolchain that does work. It is 4.2BSD based. If you are at home on BSD, it is like going back in time.
netcat, tmux, emacs, etc. you would have compile yourself. Maybe OpenSSH would compile and run. I have not tried.
Perhaps an alternative to Cygwin, etc. Not "better" but different. It generally "seems" faster and I find it's more difficult to "break" than Cygwin which in my experience can be very "delicate". The SUA White Paper says SUA comes to within 10% of the speed of native Windows.
The main advantage though, for me, is that this is not "unauthorized third party software" to the extent it comes with Windows and the SDK download comes from Microsoft's Akamai account.
I am almost tempted to congratulate Microsoft and welcome them to 1995, although I am quite sure Cygwin didn't have ssh back then.
I hate using Windows and I have never been one to follow MS "recomendations". Are you kidding? I do not work in an IT department.
I used MSYS and Cygwin for many years. Now I use SUA.
The less I have to use Windows the better. It dulls the mind.
The "experiments" in Windows 10 are undeniably improvements for when we still use things like cmd, but Powershell needs a modern terminal window and there needs to be a native answer to Putty for both SSH and Powershell remoting.
I'd say after SSH this should be a priority for the Powershell team. Conhost is holding them back. A lot.
A shell host should open and do its absolute utmost to get out of my way. ISE does not do this. It's just...it's what I expect 2008 Microsoft to think a terminal should be, lacking empathy for me as a user. And maybe that's intentional--maybe I'm not the target audience. Maybe it's for mouse drivers who are forced to the CLI in extremity. But it's tasteless and it's hindering where it really must not be.
I still do not see where the lack of empathy and tastelessness is apparent in ISE.
But anyway, your "nice to haves" are my "it's 2015, I'm not wasting my time with less." Microsoft's got more money than God, they can do something worth the time of day.
And I'm not saying ISE is the best thing ever or anything, but it is a significant step up from conhost, and honestly not really lot worse than xterm in many ways.
https://technet.microsoft.com/en-us/library/dd315244.aspx?f=...
http://powershell.com/cs/blogs/tips/archive/2012/12/12/block...
It's really too bad the limitation on the nicer ISE though. It does make a bad first impression coming from Linux, when trying to compile and run a simple interactive console app, trying to use ISE as a cmd.exe replacement.
Given that a lot of new development in the Windows world is focused on the console, I expect that we will see more enhancements in the future.
I've been stressing over finding a Windows SSH client that supports ed25519 and even thought SecureCRT recently just announced support for ECDSA, they do not have a timeframe for ed25519.
Off to try out how well this works.
Assuming the project succeeds this time around, it's going to be way easier to incorporate Windows servers into Unix-centric management systems. That's a huge benefit to DevOps and Microsoft. Thanks!
That said, I wonder how well it'd run under Cygwin. I've never even attempted this experiment so I don't have the foggiest.
What's left? Perhaps a real terminal?
To bad this won't make it into Win 10, unless I misunderstood something. Looks like my days of sneering at Windows as a toy are numbered... end of an era, and it makes me a bit sad, sniff.
"Last version of Windows" is nothing but marketing, just like the overhyped "one Windows" idea. There isn't actually just "one" Windows 10, is there?
Most versions of Windows 10 are not even within 10% of each other in terms of differences. There's a much larger gap between them. Windows 10 IoT Core isn't actually Windows 10, just like Brillo isn't actually Android.
Resizing and mouse select & copy works now like terminals in OS X and Linux. It can now be mouse drag-resized horizontally and vertically. Mouse text selection and copy works as it should, it now handles multiple (long) lines correctly and smoothly.
Basically, bit by bit it seems Microsoft are realising there is a ton of stuff they need to take from the unix environment.
The comments here about how awesome PowerShell and the other tools within all are seem to focus on everything being an object rather than being text.
So, we could fix that by basically providing a "Ruby shell" in one sweep. You go through the standard utilities you have on unix systems, provide them as Ruby methods on various objects (the Ruby stdlib has a great many) and provide a means to navigate a file system easily, and basically you have the beginnings of an object-orientated shell with the support of the traditional 30+ year old command line utilities.
What is it I am missing? This feels all a little reminiscent of when Microsoft got all giddy about providing symbolic links... well... yeah... I mean... what?
This will definitely make my job easier! Or at least more convenient.
I don't think the PS team is bad (or PS itself for that matter), I just think there was a lot of re-inventing of the wheel for no reason, and that started way upstream of remoting.
More here: https://news.ycombinator.com/item?id=9598015
I'm still not sure I really like PowerShell, but whether one likes it or not, it has become too useful to ignore. And even on days when I really dislike it, it is still a huge improvement on cmd and vbs. I still do a lot of my Windows scripting in Perl, mostly because I am familiar with it, CPAN still rules, and I am not sure I want to learn the .Net framework just so I can do some admin-type scripting. But it's good to have options.
PowerShell was designed for a Windows/.NET environment, which is undeniably different, and they also took the opportunity to create an object oriented shell instead of a text oriented one.
I also like C# but I do feel it makes a pretty poor scripting/shell language.
I do think SSH is long overdue, but based on the post it looks like the developers have always been on the right track - management just wouldn't let them do it. Really glad this is changing.
PowerShell had good reasons to exist in 2006, when it was released to the public. LINQ didn't exist yet, most of the "Windows scripting" took place via VBScript files and WMI, and dinosaurs roamed the earth.
So PowerShell was created to be a "scripting language for Windows".
PowerShell has a lot of great features specifically created for use in the shell, and some ok features (like easy COM integration) that were great in 2006. If you don't know what those are, I guess you could draw the conclusion that it's just another .NET language.
PS remoting and PS security restrictions on script files are the wheels that have been reinvented square.
The other big one for me that's been added to the console host is "line wrapping selection". You can actually highlight text now correctly as opposed to copying a rectangular block of text (though the latter is sometimes useful, just hold Alt when you're highlighting).
http://www.hanselman.com/blog/Windows10GetsAFreshCommandProm...
Come on Microsoft, go all the way!
It's like installing all those GNU tools on Windows to make it more like Linux, and putting Homebrew etc. on OSX to make it more like Linux. Why not just use Linux or BSD? I never understand it.
Also, the lack of proper Quartz windowing support from X11 apps makes using them painful.
I haven't used Windows in a very long time, but whenever I sit by a friend's computer, I find it astonishing how badly designed Windows apps are. Certainly Apple's fixation with design created a culture of beautiful apps. But having more developers would also probably improve the situation
I'm definitely paying attention.
It is interesting regarding the state of app design as most of the BSD or Linux software looks odd to me! I agree that Windows has some odd looking software but they do typically offer more features - you don't get MDI under OSX.
But don't get lazy! We still need state of the art terminal!
Back when I interned at MS in 2013, people were alarmed when I spoke to users on some forums about their complaints because I was designing a related feature. We had to check with legal whether I would have to delete all my posts!
"I’m pleased to announce that the PowerShell team will support and contribute to the OpenSSH community."I know we all like to think and strangely wish that we could replace Windows server with Linux boxes and Windows desktops with Linux desktops but the sad truth is that there is no good replacement for Exchange or Active Directory (and the myriad of extensions that you can install into it; even writing one isn't that hard), including all the mobile OS support for mail on it (and calendars), nor is there a Linux desktop that would be instantly comfortable and navigable to 90% of Windows users. My mum would be lost, for certain. I would be lost under Unity or GNOME3 (only with blind rage I feel).
It's a bit of a pipe dream, or very unrealistic. And I say this as a fan and user of all the major systems (and having been Linux and Windows sysadmin in the past).
But apart from that, I tend to agree. I still want to believe it is possible to get Windows users comfortable on a Unix desktop, it works with OS X, after all. But practically speaking, you are right.
The clever thing with OSX is that it is Unix but 95% of the OSX users don't know it is, nor do they care, nor do they know what UNIX is. OSX is Stealth Unix. Clever.
Do you mean mmc.exe snapins? I have to admit, I never tried.
> OSX is Stealth Unix. Clever.
The integration of X11 into the desktop is pretty poor, and I miss a decent package manager like apt-get or yum. Apart from that, I completely agree. Apple has managed something quite impressive by building an operating system that is a Unix to techies and a comfy, user-friendly desktop to the rest (and to the Unix people).
Specifically it is annoying that the compiler does not find headers and libraries installed through MacPorts by default. Yes, you can tell the compiler to look for those headers and libraries easily enough. But compared to the experience on, say, Debian, it is slightly annoying.
Having said that, let me point out that I have owned a Mac for ~19 months now, and while my initial plan was to give OS X a quick try, then install Debian, I have not done so.
Also, if somebody has experience with both homebrew and MacPorts, I would appreciate if that someone could tell me about the differences and the respective pros and cons of both.
In truth, the lack of cmd-tabbing support to X11 apps is irritating, as is the menus on the windows being in the wrong place. I can see why they didn't fully support it though - X11 just doesn't fit in with their Quartz system. If you turn on Quartz Debugging and do things like "show tracking rectangles" X11 windows are a complete unknown to Quartz.
Hell's not only freezing over, but freezing everything else with it. What a time to be alive.
Weirdly, everyone wants the opposite.
> Have you ever wanted to put Apple's runtime on your Linux box?
Not in that sense, but a Linux + BSD userland would be neat. Apple's runtime is basically that minus Linux plus Mach/XNU plus Cocoa.
> Or MSVC runtimes on your Linux machine?
Good God no.
> Weirdly, everyone wants the opposite.
Not universally true if you count Wine as "MSVC runtimes on your Linux machine".
Doesn't Wine basically implement MSVC runtimes?
Wine is a stopgap for software that's still reliant on Windows. The preferred approach would be for that software to instead be properly ported, which would include using a proper libc and executable package format (like ELF).
That said, my opinions aren't representative of everyone in the world. There are projects like Wine and (more interestingly) winelib that implement the MSVC, and those are popular projects (the former more popular, though the latter closer to being solely MSVC on Linux).
Software bloat has nothing to do with the runtimes. It's how people use the runtimes that's the problem. Saying that the runtimes cause software bloat is a massive generalisation.
When I use the MSVC runtimes my software isn't bloated. I compile the same code under OSX and Linux and it also isn't bloated there. In fact, under OSX it uses far more RAM, and I have to bundle along dylibs with the executable inside the .app itself in order for it to be usable. This makes my OSX app far far larger than my Windows binary, which just relies on the MSVC runtimes.
Interestingly, my software doesn't crash either. If the MSVC runtimes were "bloated and buggy" then I would be crashing all the time, but my programs don't....
The executable format under Windows was originally designed to be portable - hence PE (portable executable). Just because they abandoned the other platforms (outside Intel land) does not make the binary unportable.
(don't get me wrong, I love my ssh and am glad to see msft supporting it for real)
Now, can we please get a proper terminal? :)
I jest, somewhat.
You oddly never get BASH users complaining about the lack of Batch file support, but it is always vocal the other way around.
This completely changes the windows admin game.
So yeah, most tools would need to be adapted to manage Windows. A first-party Cygwin equivalent would be a good next step to ease that particular pain point, but said pain point is much easier than, say, having to install an SSH server yourself.
It's nice to see that they are offering an official way to do this.
Turns out it is a 1st party command line tool and scripting engine. From a glance it looks to use similar syntax to CMD.exe, but sits side-by-side with it, not built on top.
I keep meaning to find a good book or online reference and spend some time properly learning how to use the thing... For some things it'll replace my need to have cygwin installed everywhere, and it might allow me to do some stuff "better".
(https://noncombatant.org/2014/03/03/downloading-software-saf...)
(Pretty please?)
Powershell's piping of .NET objects is so brilliant compared to Bash piping and parsing of text.
You could use ipython if you wanted object handling. Now i wonder what would have happened if they didn't have gates or ballmer upstairs and they wanted to implement a new shell.
There are many thousands of people who have done the same thing, and this gives us a "web of trust". And if you don't want to trust anyone, you can always compile it yourself.
That's the difference: I have the freedom to learn and study anything and everything. It might not be likely, and it might not be convenient, but it is possible.
https://wiki.debian.org/ReproducibleBuilds
(I gave a talk about this at CCC. The status quo is a reason why free software doesn't have some of the transparency benefits over proprietary software we might expect, if you fear some developer is attacking you or someone is attacking some developers' infrastructure.)
Of course, this doesn't do anything against a malicious install environment or a backdoored compiler, but it's a start.
Generally the code quality is considered good.
Oh wait, you were just trying to score cheap snark points, weren't you?
[1] - https://www.nsa.gov/ia/mitigation_guidance/security_configur...
It is technically doable, but I'm not sure the Windows NT kernel is worth discarding entirely. It has some fancy tech in there and if need be it can emulate POSIX through "personalities" aka subsystems (http://en.m.wikipedia.org/wiki/Windows_Services_for_UNIX). Subsystems actually make it more flexible than Linux.
But in general the NT Kernel is pretty good and Windows Server is already moving to be more "Linux-like" (e.g. Core mode, all the GUIs now generate Powershell commands, etc). So it might be a while before Microsoft actually dropped NT and moved to Linux, least of all because it would require a lot of code changes in other products.
Let's not get into an OS war between us here, but looking at the changes over the last 15 years, it's clear that MS is warming up to Linux. This is something that was absolutely unthinkable during the Gates and Ballmer eras.
The linux community must be doing something right when developer demand and excitement is so high for ssh.
And no, epoll isn't enough.
I think kqueue is the best (well I guess I'm a BSD fan :D) but in general: app developers generally don't care about this, they just use libuv or libevent or something like that.
Does Windows really have "good stuff" for developers? .NET is excellent, but the lower level APIs look horrible. (And the CP/M / DOS era files stuff – drive letters, file extensions that actually matter – makes me very unhappy.)
Jails, ZFS, DTrace, FUSE, netmap, PAM, pf – that's good stuff!
It is, more or less, what it is. lower level APIs cannot change without breaking backwards compatiblity. Microsoft as an organization is all about backwards compatibility. So this is just not going away, like you say there is stuff in there from DOS that will just not ever go away.
If all a developer knows is Windows, it seems awesome.
https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...
I also really like kqueue (and unsurprisingly FreeBSD is also my OS of choice) and it's better in general than epoll, but it has its limitations. For instance, directory and file change notifications are less than awesome as kqueue needs file handles. inotify on Linux works better for this stuff, IOCPs just work for this stuff.
My point was that dismissing everything in Windows like jadeddrag did is shortsighted and dumb. It's not as if Unix-like OSs don't have plenty of misfeatures: nobody in their right mind is going to say that sockets couldn't have been designed much better (see how Plan 9 implements them for a better designed API), or that audio on Linux isn't a godawful mess, or that X isn't a monstrosity.
You're right, all that stuff is great, but as they saying goes, "why worry about a speck in the other guy's eye when you've a log in your own?"
Your comments is naive, I feel?