That is really something, before as a dev coming from linux when I first was about to login on a Windows Server I didn't understand how to do it since it were no SSH.
Administrating the server via a GUI always felt backwards somehow. Why waste CPU cycles on rendering a UI when the CLI is so great (on linux)?
Microsoft's GUI management tools were really good and generally very discoverable. IMO they were a much better way to manage an OS than cryptically named CLI programs and text files. And most of them worked remotely. And by comparison to modern software they can not even remotely be considered bloated. Every electron application ever made is larger than all of RSAT.
Now of course they suck ass because MS has no idea what it's doing anymore.
On that note, these administration issues are why Walmart & Kroger are on SUSE, much of the IT work you see smaller chains employing people to do has been automated away, or reduced to having any available employee follow a (very simple) guide on how to netboot the machine for re-imaging.
A very simple FAI or Kickstart server with small tools to enable provisioning can automate a lot of things in a non-IT oriented workspace.
A simple HTML form to "arm" the installation server, a simple reboot and PXE booting can be much more effective than all the painkillers combined for remedying the headaches of IT people and managers alike.
If you don't roll changes that often, you can distribute emergency USBs to install servers and workstations. Even a single USB can detect and install the system accordingly.
Hell yeah we're going to fight over it. Whenever something that works is turned into something that sucks, we gotta point it out until it's no longer sucky.
Yes, it's technically possible. However, it's not always implemented like that. Also, in reality we don't have both, at least in my realm.
Being able to tune a system from top to bottom solely with text files is just amazing. Also, some people hate "everything is a file" philosophy, but it's the enabler of this configurability.
When I started programming Linux and saw that everything was accessible via normal file system, it was a big relief compared to W32's iceberg environment, where you cannot see everything and sometimes water is too cold to dive that deep.
> GUI management tools were really good and generally very discoverable
The snap-ins?
A main criticism of all this is that the usual tools didn't work remotely - you need a different, undiscoverable, possibly differently licensed, set of tools from what you use to change settings on your local computer. And of course you can't easily set up Computer A and then clone its settings to Computer B; you can only do this globally through things like Group Policy.
> A main criticism of all this is that the usual tools didn't work remotely
I can't think of any that I use regularly that don't work remotely. Which snap-ins are you referring to? Most of them you just right-click on the top level object and select "connect to another computer".
Most of Control Panel, such as the network configuration (I realise this isn't a snapin, sorry)
A quick check shows the availability of "connect to another computer" is a bit random; I can do it in services.msc and taskschd.msc but not in diskmgmt.msc . Maybe that's why I've never found it before.
GUI is something you can't easily copy and paste which is s real killer. And with options spread all over with 3 level depth of more "options" is getting old quick.
Microsoft has come a really long way recently towards moving to CLI-based management. Starting with Server 2016, the default installation method of Windows Server no longer includes most of the GUI (called the Desktop Experience), leaving you with a command prompt window in the middle of the screen instead. An even thinner version of Windows Server, Nano Server, is also available, and includes even less GUI, being much more like a Linux terminal UI, though it is a bit less intuitive to get started with as you can't even install it, you have to image it to deploy.
Most Windows admins still prefer a lot of GUI management (I've gotten some groans in response to my statement new servers would tend not to have it), but remote desktop to the server is no longer the preferred way to do that: Remote Server Administration Tools effectively installs all of the server GUI on your desktop PC.
Due to the number of legacy applications Windows Server folks tend to support, it's unlikely server GUIs are going away entirely anytime soon, but for a lot of basic server functions supported directly by Microsoft, it's doable. And in addition to not wasting processor and memory pushing pixels, Windows Servers without the GUI are susceptible to less attacks, require less changes during Windows updates, and reboot faster, all on account of just having "less" onboard.
They started on this in the late 2000s when I was an intern there. But there was a lot to untangle. It’s the biggest refactoring job you can imagine. A decade long effort.
Back then they didn’t really understand the point of ssh though. They had a vision of remote management via .net RPC and powershell.
I dont know if that means they didnt understand it. It reads like they were trying to solve the underlying problems with a different approach.
SSH is an awesome tool & capability as a relatively high level network channel. The defacto “shell” approach leads to a lot of problems when used as a management device. It encourages adhoc, unstructured, and opaque changes. Managing your hosts via Secure Shell simply leads to bespoke, unrepeatable, outcomes and crushing debt.
Moving to a well structered, repeatable, management paradigm is the only way to survive large or long term deployments. I see “systems configuration” and “orchestration” as the most common ways to achieve that. Personally Ive been trying to move linux/bsd host management off of SSH for 10 years now. I will be very very happy when SSH shell instantiations approach zero per day.
> Managing your hosts via Secure Shell simply leads to bespoke, unrepeatable, outcomes and crushing debt.
SSH is not for management. SSH is for remote access. What people do with their remote access is not SSH's concern. Ad-hoc management is just as possible and easy via RSAT and PowerShell. Hell, I've seen management via ansible devolve into a mess of unmaintainable, unrepeatable script heap.
> Moving to a well structered, repeatable, management paradigm is the only way to survive large or long term deployments.
And how would such a paradigm remotely access the machines? The tool I use uses SSH for:
1. Running commands on remote machines, interactively & non-interactively;
2. Synchronising files on remote machines, via SFTP and Rsync;
3. Forwarding network ports to provide secure access to remote services, e.g. Redis.
Personally, I've been trying to move app deployment and debugging onto SSH in every team I've worked with, and I will be very happy when developers are able to treat a remote machine (development or production) as little more than just a well-managed local machine.
I tried to distinguish between SSH the multiplexed secure network channel provider and Secure Shell, the default and overwhelmingly popular use case of SSH. Theyre different, but generally conflated. I have no real problem with the transport mechanism.
To answer your questions you probably have a dedicated on host agent. See MCollective or AWS SSM for examples Im familiar with. It doesnt really matter that the transport or message model is. Its more important that your actions are discrete, well modeled, with defined & structured inputs and outputs. Its also inportant that theres an intermediary so you can get the scope of control away relying on client and end hosts.
For #1 interactive is almost orthoganal. For #1 & #2 Its that you have structure, repeatability, validation, auditing, testability, etc. #3 again a transport problem, or similar.
For your last point my issue is if you treat dev and prod as similar change and access problems. The environment can certainly look or feel the same. But the output of dev should be discrete managed artifacts. If you need to do adhoc exploratory stuff on prod thats a good sign you lack control or valid synoptic model of your systems.
That said, we may be trying to solve different problems. I have lots of teams, more ICs, and many hosts. Getting from artifice to industry is important at some point.
Edit: go check out the mcollective demos to get an idea of how you can change the access/use model.
They already had group policy for structured administration. What Windows was missing specifically was a non-GUI way for that unstructured "get in there and fix the problem" work flow. Structured workflows may well be better for you, but quick and dirty has a lot of appeal.
Sometimes you just have to give people the candy they want - even if its not good for them.
Group Policy can't manage Exchange, Active Directory, etc - prior to the introduction of Powershell you were at the mercy of what was provided with the RSAT and RDP for anything else.
Windows had this problem much earlier with every employee getting a PC on their desk. They solved it with Group Policy and domains. That still works well.
SSH and Remote Desktop solve a different problem. It may not be the one you have - but some of us just need to log into the machine because we have needs that don’t fit into some predefined workflow. Or we have so few boxes it’s not worth it.
Consider SSHing into a large build machine for compiling as an example.
Cloud is irrelevant. Its scope and repeatable results. A decade ago I had these problems with owned facilities, owned hardware, and dedicated internal teams. But it was thousands of hosts, multiple datacenters, and thousands of internal users. My personal break point is/was “a few hundred” hosts. Below that bespoke management can scale at a reasonable human:resource ratio. Above that you need too many people, and then you cant control or inspect the rate of change or variance.
Where does your opinion on Ansible lie then? It's a systems configuration and orchestration tool that by default, uses SSH as the transport.
For Ansible users, Windows getting OpenSSH is a huge win, since we (presumably) will no longer have to jump through all the hoops WinRM throws you in order to configure Windows machines remotely.
See sibling. I dont have a problem witb using ssh as transport per se. Its using adhoc/bespoke Shell for introducing change. Its a bit unrelated but I, personally, lean more towards declarative than procedural and highly value intermediated access. Which doesnt quite match ansible afaik.
Right, so your issue is with shell access and using it for arbitrary systems changes then, and not SSH per se. You'd be just as annoyed if someone logged into a shell on the server via the console and started making unmanaged changes.
SSH was originally intended to replace the aging unencrypted protocols that were used for remote access (telnet, rsh etc). It comes from a time when configuration management tools like ansible, puppet et all didn't exist, and most system management was ad-hoc, or done by home grown scripting. So it makes a sense that it behaves the same way as rsh for the most part.
WinRM (which this Microsoft implementation of OpenSSH will replace for most Ansible/UNIX users that are managing Windows systems) also allowed arbitrary command execution as well, so it was really no better.
> Back then they didn’t really understand the point of ssh though.
As an outside observer, it really looked to me like Microsoft had their head in the clouds up until about 2011. It's like the whole decade between 2005-2015 for MS was about recognizing and coming to terms with the multiple "whole worlds out there" and getting past NIH syndrome.
They understood the GUI couldn’t be everything but NIH was definitely in full swing at that time. It was enforced from the top: If you wanted to use an external product and MSFT had a competitor you needed VP approval. Same went for Open Source. Only the most senior people would even attempt it, and it was understood they were spending political capital.
The one place this didn’t apply was your choice of code editor. You could use whatever you wanted and that had long been tradition. I spent a lot of effort getting VIM to work only to realize it didn’t scale well to multi-million LOC code bases.
The speed of navigating the code base. Ctags existed but people using SlickEdit or Source Insight were able to navigate the code base dramatically faster. As a new hire I wasn't going to get code annotations emitted as part of the build, so an editor with a proper parser was key.
Really had nothing to do with the size of the file.
To be fair to Kodak, it is very hard to invent digital photography but fail greatly to use it. Or Xerox, ... or IBM who is the largest PC seller exactly the time when it was overwhelmed by Microsoft.
An organisation large enough would have middle management and people who promote from within. And they are successful in one culture and it worked even for customers.
This makes you seem like you don't understand the point of PowerShell remoting.
Passing serialised scriptblocks to the remote host, executing them, and getting serialized objects back. Meaning you can pass serialisable objects around, handle errors, the multiple output streams, etc. over the remoting connection.
Because it's integrated into the language, you can pull PowerShell modules over from the remote host to the local host automatically generating proxy stubs for them ("implicit remoting"). E.g. to manage and Exchange server you can remote to it, and bring the Exchange cmdlets back, and then import them locally as if they were a local module.
It's also able to do that and edit the proxies as it builds them for you, to allow and restrict what commands you get - based on your permissions and perhaps which tier of service you're paying for. And not just allow or restrict commands, but allow or restrict individual parameters on those commands, if desired.
you can pass serialisable objects around, handle errors, the multiple output streams, etc. over the remoting connection.
That's fine in theory, except that some very common Windows Objects can't be serialized in any meaningful way (most painful one for me being the Windows Update Client), which means that certain "remote" operations are actually affecting the client machine, or are failing because the client lacks support for certain operations.
I've been using Powershell since v2, but to me, it's essentially a walled garden automation environment. Just one more way for Microsoft not to give you the tools to efficiently manage your fleet.
How is that different from SSH? You can't serialise open sockets and pull them back over an SSH connection either.
a) I think the normal use is something like SCCM or InTune to automate Windows Updates, not manually connecting to a machine and trying to script the Windows Update Client.
b) Microsoft built Azure Stack with PowerShell automation. Are you saying Microsoft refused to give themselves the tools to efficiently manage their own fleet? What tools even are these?
The mental overhead of this is much higher than the concept of “I’m logged in to this remote machine - all actions happen there”.
That’s why I can guarantee Remote Desktop has more usage than these remote rpc calls for ad-hoc work. Powershell is quite powerful but it’s features are more for programmers than users.
Because of its complexity RPC is not a replacement for ssh where you are typing commands directly to the remote machine.
If I had to define one underlying architectural difference between UNIX and Windows, it's that Windows uses RPC (and some other kinds of structured communication) where UNIX uses pipes. This has advantages if you're Microsoft and developing both ends, but in most other cases it's a huge disadvantage to discoverability and transparency.
This is partly why nobody developed proper open source Exchange clients: the Exchange protocol is MAPI over DCE/RPC, and you need to build a lot of infrastructure before it will even talk to you.
OpenChange tried to build an exchange server, and it worked to a certain extent, but it's now dead I believe. Keeping up with the recent protocol changes in Exchange was too much, though ironically with the REST and MAPI over HTTP (not RPC over HTTP), it should be a lot easier to create an exchange replacement.
Samba still does amazing stuff on the directory RPC front.
The point of ssh is that I can easily manage some Windows boxes from a Linux server.
A customer of mine fires up servers to run tasks on them. A few of those tasks are programs that unfortunately run only on Windows (the pain of updating those boxes!) I install ssh to be able to perform some basic operations on them and move files over sftp. Hopefully an integrated ssh server works better (issues with terminal, etc.)
I understand that this is not a scenario Microsoft would advocate in the past, but eventually Microsoft lost the war for servers so it's giving us interoperability tools now.
I’ve been developing on and for Windows for 20 years and just started doing anything with Linux earlier this year.
If you told me I had to do anything advanced with Windows using only a CLI, I wouldn’t know where to start. On the other hand, I could maneuver my way around a bash shell. I haven’t thought about that before now.....
I think it's time for MS to develop a new ANSI/VT-compliant, text-oriented shell (to complement PowerShell, which is largely object- and API-oriented). There ought to be a default shell worth using on the other end when you ssh into a Windows server :)
cmd.exe and DOS were both text-oriented but extremely buggy and inconsistent. Perhaps MS could just focus on providing a very bash-like language (perhaps even include gnu utilities) while supporting the major interactive use cases for cmd.
Why would they do that when Powershell is literally that, but refined beyond what's commonly available on Linux?
I'm not great with it yet, but it feels intuitively like a step forward to be able to pass objects around instead of spending so much of my time using awk-ward 40 year old tools to tease text out of various fields.
PowerShell is great for when you want to interact with Windows APIs (local and remote) and/or work with objects. I have no problem with using it for those purposes.
But terminals and the tooling around them have always revolved around text. My point is that since Microsoft is (a) including OpenSSH, (b) upgrading their terminal infrastructure to support VT100 and ANSI codes, and (c) investing in WSL, it would make make a lot of sense to add a Windows-native shell that is more text-oriented. Not because I hate working with objects and APIs, but because plain text ought to be the primary, first-class supported data format when working on a terminal.
PowerShell is great, but it's an object-oriented (not text-oriented) shell.
> But terminals and the tooling around them have always revolved around text
That's because they're from the 70s, when literal terminals with no real computing power were connected to a centralized system that did all the work. They're archaic and silly.
They may seem that way to some, but they still provide a surprisingly versatile and useful user interface. Terminal programs and scripts are easy and fast to write, easy to interact with, easy to change, and trivially portable across POSIX platforms; hence, when writing a tool for oneself or another developer, most developers will usually opt for a CLI-based UI. Terminal program UIs are also very stable (in addition to being text-based), making them arbitrarily composable into scripts and workflows without fear of them breaking in the future.
Modern graphical UIs are usually easy to use, but they are far-removed from the code and tools that are used to write them or interact with their APIs programmatically. Terminal program UIs, however, are very close to the environment they're built in -- so the line between using a terminal program and interacting with it programmatically is delightfully blurred.
I use a multi-paned iTerm2/zsh window every day as a front-end developer (I'm on a Mac running macOS Mojave). I can't imagine working without it. There are a lot of good reasons npm, git, and other popular mainstays in modern development workflows are terminal-based.
Terminal is not the same thing as CLI or TUI. I don't have a problem with either of the latter interfaces, I have a problem with archaic emulation of long obsolete hardware with in-band signaling.
A modern console would use out of band signaling for things like cursor position, colors, size changes, etc. Windows consoles work like that using API calls, which is perhaps not ideal for quickly hacking things together but at least doesn't wig out on you if something throws arbitrary bytes into the stream.
I doubt you'd see Microsoft reinvent the wheel here. They'd more likely work to give WSL more ability to interact with Windows, and then let you just use that shell if you want to.
How likely is it that MS will include and enable WSL by default on Windows Server just to provide a better default shell for terminal and ssh users?
If I were a server admin, I’d probably turn all of that off because it’s more attack surface area. And cripple myself in the process. For that reason alone, I think a new shell is probably more likely to be helpful.
Shameless plug: There's also remote GUI support through Windows Admin Center. You can manage your headless server through the browser on your workstation. It's also a good way to learn CLI-based management (the implementation is almost all powershell scripts, and there is a "show script" feature) https://docs.microsoft.com/en-us/windows-server/manage/windo...
I think it's more a compatibility thing than an original desire for more CLI. All that deployment tooling built on top of scp, protocols like git over ssh. Without ssh, Microsoft would forever be out of that game. Those things are definitely not "not CLI", but the CLI question is not in focus.
I am not aware that windows is rendering any pixel while no active desktop session is launched. You have less binaries and probably a smaller memory footprint without desktop but I would be surprised if the performance difference was material.
The Windows Admin Center currently doesn't cover everything that the RSAT does, notable omissions include anything related to Active Directory.
Personally, the Windows Admin Center is a nice-to-have tool for quick tasks by inexperienced or occasional admins - but you really should just learn Powershell.
So, I am not a big fan of windows- so do not take this for defence of windows.
But my understanding is that windows fleets are just administered drastically differently than Linux fleets.
On Linux we have a lot of config management tools and commandline remote administration kits.
In windows they have SCCM and remote access GUIs which do not get rendered on the target server. It’s very common to see a GUI program which does something pretty basic but over 500+ windows machines in windows heavy shops. In fact when I explained that I do all my scripting with a local target (because I use salt stack which is essentially a remote execution framework before it is a config management system) I was told in no uncertain terms that I was doing things the “old way”.
Yes and no. Having used DSC and powershell remoting extensively, these create as many problems as they solve. Nothing works smoothly. Not a thing.
The saving grace here will be SSH because then at least we can drive all our kit across both platforms from Ansible and be done with the entire MSFT management stack.
At the moment we use Ansible but it runs over WinRM which is completely unreliable due to some architectural problems with how WinRM works.
Really, automation on Windows is extremely costly compared to Linux. I've got to the point I never want to run Windows infrastructure again.
Before anyone says "it's getting better". That has been the case from 10 years and it only got different.
> Really, automation on Windows is extremely costly compared to Linux
I'd disagree. I've been managing fleets of Windows machines since NT 3.51 (and fleets of Linux servers since 2003). It's all about knowing the tools well.
Whilst I've been using Linux since around 1995 (Slackware!), and prior to that various Unix and Xenix(!) boxes had popped in and out of my IT life, I'd never managed more than one or two machines. That was until 2003'ish when I went to work for a shared hoster. It took me a while to become as proficient at managing all these new Linux boxes that entered into my life as I was with Windows. I had the learn the tools.
I'm not suggesting you weren't properly trained, but most of the complaints I hear about Windows being a devil to manage is usually because admins haven't learned how to use the tools and generally haven't a clue what they're doing.
I've been in this since Netware for MSDOS. Your last point is valid in most circumstances but the issues are technical and not with staffing or skill level. I'll outline some of the technical issues I have, with my skill set which covers large scale deployments:
1. Remote management is totally unreliable. If I point DSC at 20 nodes via WinRM, 25% of the time it will fail on one of the nodes.
2. Everything takes glacial amounts of time to happen, from deployment and provisioning to simple cases like restarting processes. This is because Windows is simply so damn large.
3. There are so many edge cases and bits of tribal knowledge dotted all over stackoverflow which is sometimes the only way of finding out what the hell is going on, it's impossible to cover all of them through automation and nigh on impossible to document the rationale behind them.
4. Literally everything is stateful and state is difficult to synchronise and reload.
5. The disparity between major platform releases makes it extremely difficult to develop automation that isn't brittle and can span major windows versions. And because everything has all of the other concerns from coupling to bugs it's impossible to chop big chunks of your infrastructure over to new windows server versions. So you end up in permanent migration mode.
6. The sheer amount of bugs in some of the larger products like SCCM and SCVMM are just unbearable. SCVMM client for linux is a pile of shit and I'm being polite there.
All of these cost immense amount of wall clock time and staff attention which far outweighs the cost benefit of using the platform to start with at least from an application server business.
On the desktop, things are slightly better as it's the least bad desktop platform for corporates but that's changing. Even Microsoft know that which is why they are forcing people down the cloud route and selling subscriptions.
For managing desktops and not servers, Group Policy is still unbeaten. I have yet to see a unified strategy on Linux of being able to say, mount these drives on logon, show these applications, don't allow them to do x, change the background to y etc.
Sure, managing linux servers is a doddle, but desktop environments are miles harder to get right.
Having managed desktop windows deployments, I sort of agree. They work pretty well up to a point and that point stops when you have to introduce change control. Eventually all the little hacks, GPO scripts and stuff piles up and up and up and then there's a task like "migrate one AD node to 2016" and this turns into a 2 month project unpicking all the hell.
That is what every single Windows environment I've seen turns into, including the SCCM powered and Microsoft direct consultancy managed ones.
>I've got to the point I never want to run Windows infrastructure again. Before anyone says "it's getting better". That has been the case from 10 years and it only got different.
i know what you mean. It's part of the reason I'm on the cusp of discarding my 20ish years of MS SQL Server experience and going full Postie for the rest of my life. Windows IT infrastructure in most enterprises is a pile of lies. It's particularly galling in academia and non-profit because they can't afford to keep up with all the Microsoftia and yet still the management dreams of using Microsoft StudlyWare which would require 10x the IT cost they could ever dream of, let alone get.
It is lies. Exactly that. The thing that gets me is that a lot of it blatantly just doesn't work. You walk in, are sold an ideal, walk out, get to work and find out you're suddenly wading in shit.
But people are totally 100% happy with that in some circumstances. They are happy with lower mediocrity because simply the vendor in question has got away with it for so many years that it is now the status quo.
If I bought a Tesla and it behaved like the average windows machine I'd drive it back through the fucking dealer's window.
Simply I demand better and I demand what I paid for.
Desired State Configuration is not supported by PowerShell Core v6, even on Windows. DSC is only supported by PowerShell v5 and earlier. This suggests to me that DSC has been abandoned
In contrast, .NET Core supports various old Windows-only features, such as COM and soon WinForms.
Most of these alternatives are not installed on windows server for security/maintenance overhead reasons by IT administrators and developers are forced to live with slow and cumbersome RDP(not to mention zero capability for scripting) for accessing machines.
Now that Microsoft has finally realized the importance of remote shell access for servers and has included it in OS by default, it will become convenient alternative to RDP.
For just one thing, I find it a lot nicer being able to edit config files in Notepad++ or something instead of vim or nano. In my case I mount the remote Linux server as a drive on Windows.
That's misleading at best (GUI windows apps that technically can be emulated from the commandline often practically cannot be--CLI tools or the registry/config-file interactions required to perform actions that are clearly exposed and well-documented in the GUI often have nonexistent or terrible documentation. In even marginally complex apps, this puts the effort required to script the functionality of the GUI on par with the effort of reverse engineering it--and that's Microsoft-authored tools and Windows functionality, which is worlds ahead of most third-party software in scriptability) and just plain false at worst (huge swaths of stuff just don't have APIs that are accessible without writing and compiling code--PowerShell and very aggressive pushes by Microsoft for WMI/CMI and WinRM more recently have only just begun to erode that).
AFAIK, the only way that you can even set a system wide environment variable without using the GUI is by using Powershell to modify the system registry.
I think we have differing terminology. I would consider this a GUI. After all, the command prompts are running in windows. You can move them with your mouse. Other utilities (like regedit) are available, and are not command line / text-only applications.
It's interesting that their ssh-agent runs as a service under an Administrator account. I'd guess this is an attempt to better protect the private key against theft during a local compromise (i.e. unlocked computer left running on your desk).
I haven't seen this done on Linux. Has this trick been implemented on other systems?
They also got notepad to not blow everything up when opening a file with normal line endings. It still fucks everything up when creating new files though.
Not the defacto standard, but plain POSIX. Carriage return + line feed to enter a new line starting at the left margin makes perfect sense mechanically, though, and a lot of systems with ASCII/ASCII-like encodings use some variation of this sequence (e.g. <cr><lf> or <lf><cr>) for "newlines". Of course, in the interest of compatibility I'd prefer if it was one way or another, but I don't think it's fair to say that POSIX is the defacto standard. Lines in network protocols, for example, typically use <cr><lf> as well.
OpenSSH with powershell is such a great combo. I was very skeptical about powershell, but after writing many scripts I’m a convert. Powershell does so many things nicer than bash. It feels like a real programming language but still not loosing its scripting roots.
For running tests for a GUI application which requires us to spin thousands of Machines in parallel, manage job queues, interact with Windows UI automation, do some html result dumping, shell buffer streaming, and a whole bunch of crazy things, powershell interfaces with things really nicely.
I absolutely love that powershell pipes streams of objects rather than just streams of bytes. So much more expressive.
Yep. I've been using bash since the 90s, and really got into Powershell a couple of years ago (I now run it on macOS too).
The amount of people who try and explain bash basics to me when I say I use Powershell is staggering. I'm quite good at regexs thanks, I just like my scripts picking keys 'select' and 'where' rather than scraping with grep / awk etc. The amount of (poor) pwsh clones on Linux is a good testament to the solidness of this approach.
This is almost undeniable. Seems like everyone and their mother are using vscode, typescript is huge, .NET Core is FOSS, PowerShell is now open source, etc etc.
The Language Server Protocol has revolutionized IDEs in general.
And now that they own GitHub (and their projects like Atom), it seems like the entire FOSS developer workflow is likely to be from MS-derived projects. Which I'm sure they are hoping will translate into more cloud service revenue and online software subscriptions.
If you are starting a new company, BizSpark is a really attractive offering. Could run a whole business on it, and yet none of your devs need to be running windows on their machines.
Bizspark doesn't exist anymore, it's a single program called Microsoft for Startups now, and it does allow you to apply directly: https://startups.microsoft.com/en-us/faq/
But it's only for those developing an "innovative, technical solution unique in the market with a B2B focus that will benefit from access to enterprise customers," according to that link. IIRC the old BizSpark didn't have as strict of a B2B focus.
Only if they try to open source visual studio (not the code) which is choking themselves by putting a barrier to entry for their own platform with not so cheap pricing model.
The old Bizspark (and Bizspark Plus) programs have changed into a single Startups program which is more selective. Still great value if you can get it.
If you are wondering what's the Auto DevOps - GitLab Auto DevOps eliminates the complexities of getting going with automated software delivery by automatically setting up the pipeline and necessary integrations. You can find out more info at the landing page [1] and the documentation [2].
I’m the farthest thing in the world from an open source zealot. But, I can’t think of a single company that lives or dies by its source code being a secret.
If I had all of the source code from any of the FAANG companies what would I do with it? The only one that may be valuable is Google and I could make a killing from knowing how to do SEO. But even then it would take an army of very smart developers to figure it out.
It's a funny notion that by dropping some BSD-licensed code into their OS that every other major operating system has been using for 20 years, Microsoft is somehow becoming the leader in open source.
Maybe that's just my interpretation, but without explaining what being a "leader in open source" means and by what merits Microsoft (a business dealing mainly in proprietary software) is becoming it, that's all I have to go by.
Buying OSS related, and incorporating/wrapping existing OSS projects, is not leading. Is taking a hike on the backs of others successful work.
Microsoft only releases the source on products they create when they clearly can't compete, and they have no other option. In terms of open source leading and inovation ms is worth 0.
Although they have a good R&D. There isn't anything new they contributed to OSS community.
Clearly not true. Microsoft had a position of industry dominance in the mid to late 1990s, money was never in short supply. They couldn't be the leader of open source back then because of their culture and attitude toward open source. The open source industry knew it and the dislike was mutual. Even if they had wanted to, they couldn't have purchased loyalty from open source users & developers, while simultaneously behaving as they were.
If talking about heart and greed is all that's left to burn Microsoft with at this point, then they must really be knocking it out of the park.
As someone who just started working as a developer and is using windows for the first time in 4.5 years, I can't believe how much I miss ssh and command line tools for everything...
ssh keys would solve so much trouble with scripting and credentials...
Sure with a half dozen fixes you get an approximation of a modern terminal. GP is talking about the console, not the shell however. The console is a character grid designed around VGA hardware, not built on streams as a proper terminal is.
CMD is another horribly-designed feeble tool compatible with COMMAND.COM, acceptable back in the eighties. Yes, its fine for running a program or two here and there if you've got low expectations. You can get work done on 640x480 too, but we don't suffer that today. ;-)
I recommend this series of posts that will explain how poor the situation has been on Windows, and how it is improving:
Looks like it was forked from some predecessors ( https://en.wikipedia.org/wiki/Secure_Shell#OSSH) but doesn't go into the history much more than that. I remember telnet, where there any encrypted predecessors before the ssh family?
If it's similar to SSH in Windows 10 (developer feature) it behaves quite strangely with user account privileges. I tried to `vagrant up` a project configured to use VirtualBox but it was not successful and caused a whole load of file system permission errors in thr project directory mixed between SYSTEM and Andrew (my user account). Additionally, VirtualBox had trouble deleting the VM until a reboot.
I am running this on AWS. It was a 30 minute exercise and it's only available on the 'core' AMI. This means there is no GUI even if you wanted one. I do like the ability to run regular CMD or PowerShell. I am experimenting with using SSH to automate deployments to Windows Server.
TIL there's an AWS Windows AMI that comes without a GUI. Another user in the thread was talking about the "default install" of Windows not containing a GUI; wonder if this is what they meant.
If you install Windows 2016 RTM without changing a single option, you will end up without GUI. You have to choose "desktop experience" during install to get the traditional desktop installed.
Back when I was a sysadmin at Microsoft, we installed F-Secure's SSH server on every server we built (Messenger/Hotmail). The Windows team thought we were nuts. Well, what do you expect if you ask a bunch of Solaris admins to run Windows?
There were no real alternatives. I remember when they got all excited about showing off remote Powershell to us circa 2004, and we collectively rolled our eyes.
Hotmail was FreeBSD on the front end until it switched to Windows IIS in an ISAPI filter. The back end was Sun E4500 with T3 purple storage. Then they switched to HP with some terrible RAID crap.
Messenger was borne from the Net Meeting team in an informal weekend hackathon (before that was a thing). Backend stored the buddy lists and was 3 Hotmail ustores (Sun E4500 with EMC clariion storage). Front ends started out as Sun 420R then switched to Windows bit by bit (DP, SB, and then CS and PS). The Messenger HTTP gateway always ran in IIS.
Hotmail and Messenger used a lot of rdist in the early days. Until one of the managers rdisted /dev/null to /etc/passwd. Just one of many lolz in the day.
I really like the idea, but if you're going to administer production Windows servers, it seems like you may as well learn PowerShell which already has a nice remoting framework.
This is pretty awesome news.. for the last few months, we've been working on porting the Userify shim (but not currently the server) to Windows.
This will work exactly as it does on Linux (and the shim will continue to be open source): local admin (or user) accounts will be created and keys deployed, and the user will be able to choose PowerShell as their shell of choice.
(FWIW, Userify is both a cloud/SaaS and on-premise/self-hosted SSH key management solution designed for modern clouds like AWS and Azure that creates local accounts, deploys keys, and then keeps everything in sync using just outbound HTTPS connections.)
Does anyone know — sorry if I forget the correct terms — whether you can SSH with pub key auth and perform operations that require elevated permissions, such as disk resizing?
I have some vague memory of limitations in earlier versions, with distinct differences between password auth and key auth.
If logging in as one of the adminstrators, you will be in an elevated session - so yes, you can do things like disk resizing.
The difference between password auth and key auth is that using password auth you can access network shares that need authentication from within the remote session. With key auth, you wont be able to.
From what I understand NT already abstracts Win 32/64 APIs roughly the same way it abstracts the POSIX ones -- if they switched to Linux kernel + an abstraction layer for Win 64 (Official Microsoft Wine, basically) that's one less kernel and one less abstraction to maintain (WSL replaced by the kernel's native interface). I would happily pay for and operate such a product -- especially if I could install such a "Windows" as a subsystem upon some otherwise unmodified Linux distribution.
> Primary issue with this would be driver support.
Perhaps hardware vendors would just start dedicating more effort to Linux drivers development then. Nevertheless the way drivers work in Windows (separate programs instead of kernel modules) is still better itself.
Read Windows Internals. It's a very different design from Linux. Worth learning about another approach to operating systems if you're at all interested.
WNT evolved (spiritually) from VMS and has a lot of unique things in its structure.
Note also that Windows already kind of is a perfectly serviceable Linux kernel through WSL. That's one of the unique things about NT - it was designed for binary compatibility for programs written for several distinct systems.
This compatibility layer approach is quite common. Solaris Linux Branded Zones and FreeBSD Linux Emulation Layer (now defunct?) also did the same thing.
WSL doesn't actually run a Linux kernel - it's a linux api mapping, just like csrss is a Win32 mapping, to the windows kernel calls. So they're already only running one kernel, but it's NT.
"One less kernel" here didn't refer to them having a linux kernel and not needing it, it referred to them having and maintaining NT but not needing it (instead, utilizing an external Linux kernel).
Not sure if a joke, but I'd absolutely love this. I, as a consumer, would gladly pay good money to be able to use Outlook and the MS Office suite. Regardless of what anyone claims, the linux alternatives are useable but not nearly as good. I used to use Windows with Cygwin, but found I spent way more time doing linux-y things than Windows-y things...so switched away.
I would have said the same thing a year ago. Today not so much because Apple hardware prices have skyrocketed. It used to be that a Mac cost 2x the PC equivalent, but now the cost is reaching 3x. For many, especially considering engineering salaries, that's justified. To me, having the familiar GNU toolchain and Linux configuration available at any moment without having to use a VM or Homebrew is worth the downgrade in eye candy.
> Today not so much because Apple hardware prices have skyrocketed.
Have they? Or have PC prices fallen fast and far? It’s hard to compare due to the product continually changing (insert some sort of apples with apples joke), but it looks to me like Mac prices have fallen.
Personal preference. I don't dislike Apple, I just don't like being so tied to hardware. I've got this little custom NUC I do all my dev work on and have come to really enjoy it. Also, I've come to prefer many things about linux, especially its interface(yes, really).
This makes absolutely no sense. Linux is a kernel. If Linux 'switched its kernel to NT', it would not be Linux. Perhaps you meant the userspace, which is not dependent upon the kernel?
WSL is an implementation of the Linux kernel ABI on top of the NT kernel.
Typical Linux user space does depend on the kernel ABI – most significantly via glibc, systemd and friends, but also to various degrees up through the stack.
> Typical Linux user space does depend on the kernel ABI
Not really. There are some exceptions (systemd), but there are libc implementations for other kernels, and the GNU userland definitely runs on other kernels without a hard dependency on any Linux kernel ABI.
At a macro level, there are plenty of syscalls not wrapped by glibc that are used regularly in userspace. Then there's the micro level assumptions of behaviour. Look at the list of "doesn't work on WSL" software and all the bug fixes to get boring, every day stuff to run on it (or LX zones, or BSD personalities, or…)
You also know that 'Linux' is more commonly used as a description of the userspace and other common software. You are starting an unnecessary argument.
I agree that software isn't Linux specific. That doesn't prove your point or make your original post less obviously looking to start an argument where none exists.
for those you who don't remember Xenix was Microsoft's UNIX that it marketted prior to releasing DOS. Originally the idea was Xenix was the multi-user OS, DOS was the single user.
Whilst I prefer Linux Distros as OSs to Windows, I genuinely believe the NT kernel has a lot of good stuff, and is definitely better on a lot of stuff (e.g. security)
Interesting comment actually. A lot of people already install ssh on windows, and it has been like this forever. And spying the user is more on their business agenda.
Also people claiming that it does not spy because it open source should read [1]. Source availability does not mean the binary was built from it.
Well, if you're going to trot out quotes from the 80s (more precisely, 1987, Henry Spencer), you should be aware that Microsoft made and sold one of the first commercial Unixes: Xenix. And they made it in 1980, long before your quote.
"In the mid-to-late 1980s, Xenix was the most common Unix variant, measured according to the number of machines on which it was installed.[1][2] Microsoft chairman Bill Gates said in 1996 that for a long time that company had the highest-volume AT&T Unix license"
Microsoft definitely understood Unix and figured out there was no market for it for close to 2 decades.
Apple successfully leveraged UNIX to develop macOS (officially UNIX) from which they developed iOS. Google successfully managed to leverage the Linux kernel (Unix-like) and Java to develop Android. Windows Phone, on the other hand, flopped.
My original comment said: "there was no market for Unix for close to 2 decades". That was hyperbole, but:
1. 1980 to 1998 for Google, 18 years -> that's awfully close to 2 decades.
2.1980 to 2001 for Apple, 21 years -> that's more than 2 decades.
So your counter examples confirm what I said.
3. Windows Phone and family failed because of marketing blunders, not because of tech. MS-DOS and Windows succeeded because of marketing prowess, not because of tech.
4. The mainstream market just wasn't ready for Unix for a long time. The biggest Unix success was Sun, for a long time, and Microsoft absolutely dwarfed Sun for most of their existence. Further proof that my statement was right.
This type of attitude isn’t terribly helpful either. Sorry if that came off as snarky but this one is near and dear to my heart.
The reason you get twelve replies is because PowerShell is the answer to wanting a good shell and decent command line tools. Not perfect but it runs circles around typical ‘nix shells.
It would be a bit like having a decent Ruby or Python-based shell on Linux and bemoaning the lack of a Windows cmd port.
That said there’s a great case to be made for familiarity and experience and any bourne-like is going to do just fine without PowerShell’s bells and whistles. Powershell is also far from perfect and has warts and limitations like anything else.
> The reason you get twelve replies is because PowerShell is the answer
...to a question not asked. No, really, I want Linux tools, and don't want PowerShell. When I want more than a shell, I want a real programming language, not a more powerful shell.
I appreciate that some people like PowerShell. But the answer to "no, not PowerShell" is not "let me tell you about why you want PowerShell anyway, you just don't understand".
> That said there’s a great case to be made for familiarity and experience
And simplicity.
Here's a closely related example. Back when there was more than one competing distributed version control system, there was "tla" (a predecessor to baz, which was a predecessor to bzr). tla had commands like "init-tree" (not "init"), "file-diffs" (not "diff"), "apply-changeset" (not "apply"), "make-branch" (not "branch"), a dozen commands for logs (not "log"), and so on. Perforce has similar problems.
And PowerShell has "Expand-Archive" (not "unzip" or "tar"), "Invoke-WebRequest" (not "wget" or "curl"), "Get-Unique" (aliased as "gu" but not "uniq" or "unique"), and so on. Brevity is a virtue in a tool used so frequently, and brevity is not lack of clarity. Unnecessary verbosity is often an obfuscation.
Agree. Sorry for flame fueled post. Still, old but vivid MS memories. The key point (for me) ie. 8 years ago was really hard to efficiently and error-prone to do most of the task on MS platform. Hope the UNIX tools will ported soon too.
Now all they have to do is switch their kernel to linux, their gui to kde and get their office suite to LibreOffice, and Windows will be the perfect computer.
My biggest complaints with Windows are the spying on users, the forced updates on users, the registry still existing, and the NTFS file system still being the primary file system.
The kernel is actually likable but would benefit from being open source and the GUI is a horrible blend of touch screen and legacy input hybridness that I wish never existed.
Really? It does not seem so. Yesterday I wanted to filter some chkdsk logs on the Event Viewer [1] and I could not do so because the dropdown does not appear if the display DPI was set in 150%
I'd love to be able to submit this bug on the issue tracker, if you could tell me where to find it.
And we are talking here about an OS and GUI made by the same vendor. Hugely different from the Linux+GUI situation.
[1] which is another example of a awful legacy interface where by default you can only peek at the first 2 unrelated lines of every log mesage (and even worse: without a standardized format)
Genuinely wondering which Linux distros/desktop environments you've tried. I think Elementary and Gnome 3 Ubuntu are both incredibly well-polished, so much more so than Windows. And all the Windows fans I work with complain that Office 2016 crippled their workflow in some way and hid features.
Windows 10 has a ton of neat shortcuts for pro users that Windows 7 users miss out on (besides all the security and performance improvements). The right-click menu on the Start button alone is life-changing. (It was introduced in Windows 8.) Over the last few years, Windows 10 has seen much overdue updates to Command Prompt, Notepad, etc. The default Calculator app is now pretty awesome even.
Let's see, other Windows 8/10 UI blessings I'd point out is revamped Wi-Fi connection management in the system tray, the quick notification tray access to switching secondary monitors between extend and duplicate modes, easy access to airplane mode, proper official UI for Bluetooth devices and cellular cards. Don't forget having a proper notification tray to begin with, so that fifty dozen system tray icons aren't each presenting their own popup bubbles.
While the start screen and charms bar were definitely missteps in Windows 8, I would cautiously be willing to almost entertain the claim that Windows 8 had a better UI than 7, just due to all the handy shortcuts they added. But 10 definitely brought back some of the strengths of the 7 UI, while keeping all of the improvements that 8 launched.
I strongly suggest you compare the two. It's not even remotely the same thing. On Windows 7, right-click on start offers two options: "Properties" and "Open Windows Explorer". On the current version of Windows 10, it has eighteen options, including handy options to launch PowerShell with or without admin rights, access admin tools like Event Viewer and Device Manager, etc.
Meh, I suppose that's somewhat convenient. Those have been available on the Start Menu however if you clicked a radio button in its preferences and enabled Admin tools. You can also right click the MyComputer and pick manage.
I don't use those so often that I need a dozen shortcuts.
While the UI isn't bad, I'd argue that the UX is absolutely awful out of the box.
- Notifications are non-stop until you turn them off. And, even when you turn everything off, there's system notifications that you can never turn off.
- The start menu is god awful. Why they decided to replace the easy-to-use Windows start menu with this animated abomination is beyond my understanding. Our office puts classic menu on all new pc's because of past complaints.
- The settings are all needlessly verbose. This isn't exactly new to this version of Windows, but they could really take a page out of Apple's book when it comes to changing system settings.
- And, they've went the extra step to make sure you don't change Edge as the default browser. Not exactly user friendly.
True, windows is more polished. However with a dozen of devs and Microsoft's q&a facilities, it would not take more than 2 years for linux to get the same level of polish on the GUI side of things.
It has come such a long way in 15 years.
> Windows ux is better out of the box than on any Linux so far, it's really polished.
Windows UX might look more polished, but I find GNOME 3 to be the most usable one. Because I feel completely in control of the entire system with just a keyboard.
It has a lot more UI options, so you can remove the Ribbon and other controversial UI elements. It’s also scriptable in JavaScript and Python [0], which is an improvement over VBA for the HN crowd.
Administrating the server via a GUI always felt backwards somehow. Why waste CPU cycles on rendering a UI when the CLI is so great (on linux)?