Hacker News Reader

I won't comment on the eBPF or WSL or even the Windows as linux debate, but I used to do some Windows admin.

Some clarifications are in order.

MSIs CAN be installed on servers with no gui required. Or much more commonly via powershell automation. Completely remotely and I'm not referring to remote desktop either.

I know its fun to complain about Windows, but really, if you're not using powershell and the right tools such as a Windows Domain, you're kind of like some kind of debian linux admin that refuses to use bash scripts / debian apt / ssh etc plus chef or similar management. It really is that kind of comparison you're making. What would you say about a linux admin that refused to use SSH or any scripting? You'd wonder why they are complaining.

Most of Windows Server comes alive when you join the machine to a domain and it gets access to actual infrastructure rather than some lone isolated server. This is to the point where you don't even need to log into the machine via remote desktop or ssh at all. In fact you manage the server from a completely different Windows machine with an admin account within the domain. You can then run the powershell script on your management computer and things happen on the target computer(s). I haven't even mentioned the multiple other tools you get as part of the machines being joined to a domain. Or you can deploy the script to the machine and execute it there. Still no remote desktop required.

I can't imagine how anybody manages any number of Windows machines w/o a domain. Even just an NT 4.0-style "downlevel" domain (hosted with Samba, if need be) made life so much easier "back in the day". Once Active Directory came out I never looked back. Group Policy makes so many Windows administration tasks reproducible and automated.

I keep meaning, year after year, to take at Samba and see how its Active Directory emulation functionality has progressed. I never end up getting around to it. Presumably, since so much of Active Directory is really just leveraging LDAP and a funky proprietary schema, it has progressed significantly.

I've had a hard time figuring out how to position Desired State Configuration. It feels like an appeal to Linux sysadmins used to Puppet, Chef, et al. I can already do everything it can do with Group Policy, and I'd want an Active Directory domain for single-sign-on anyway. I have a hard time coming up with a use case for learning all new tooling when I've already got AD and Group Policy.

Group policy "automation" is painful and inconsistent. Parts are only applied on user login. Parts only on reboot. Parts instantly. Hard to impossible to know which is which. And no way to log off users or reboot machines via group policy, so you need remote logins anyways.

I'd argue it's just being familiar with the tools. I'm biased, no doubt. Windows sysadmin work has paid the lion's share of my bills since the late 90s.

I've been using Group Policy heavily since 1999 (during the Windows 2000 beta), so I'm used to knowing what applies when. Being familiar with which client-side extensions (CSEs) do which processing helps. The documentation for Microsoft's own functionality is reasonably good. Third-party software is a mixed bag.

Remotely rebooting machines is easy. There has been a remote shutdown API in Windows NT since the at least Windows NT 4.0 (and probably going all the way back to the beginning). Since Windows 2003 there has been a command line tool included to actually use the API. Likewise, there are command line methods to remotely logoff users, refresh Group Policy, etc.

Re: rebooting is easy

Full agreement. We were remotely powering on/off hundreds of machines with a single command line. Then just a web page because we needed non-IT people doing it on regular basis.

We used to change wallpapers of certain groups of machines on a daily or even hourly basis due to special events. Do people really think we remotely logged into each one? Or manually remoted each one? Hmmm.

Next someone will be saying its impossible to get the event logs from each machine... truly bizarre. (Yes you can, and we did, even from client machines if a machine had developed "quirks")

Again, these complaints are just strange. Its as if they weren't using their infrastructure.

None of this is any kind of wizardry. I'd expect any linux or windows admin to know the tools required.

Depends, event forwarding is quite weird and broken. Default settings delay and buffer events for quite some time so that an attacker can easily suppress unsent event buffers. Crashes are also usually missed because buffered events have not been sent in time. That can be configured down, but all the provided defaults are useless.

Also, encryption and authentication for log forwaring is bound to AD Kerberos credentials that frequently expire, leaving you without logs again.

Any old syslog client and server is far superior in all the aspects mentioned.

Reading your comments it seems like you have had a bad time. I hope you moved over to linux or similar instead. Otherwise there's a lot of optimisation required in your AD with clean up of multiple areas required. Likely issues with network infrastructure as well.

Also, event forwarding isn’t the only way.

I didn't claim that rebooting a Windows box is impossible or hard. It is just that group policies are no complete solution for anything, they are just a small and imho weird part.

Also, for a lot of things there is just no group policy you can set somewhere, so you are still in need of some "execute me that script that does the needful" in a lot of cases.

We have different experiences. Group Policy is a tool that I'm confident, in virtually any engagement, I can use to automate nearly all the goings-on of a Windows Server environment. Third-party software may not play well, but between the GPP CSEs and scripting, as necessary, I can get the job done. That's been my experience.

I'm not sure what to say re: "execute me that script that does the needful". That's going to hold true in any environment, Windows or Linux or whatever. If you've got third-party software that uses unique configuration persistence mechanisms, or doesn't work-and-play with the OS-provided management interfaces (Service Control Manager on Windows, systemd on Linux, etc) then you're going to have to script one-offs. Most real sysadmin work, in my opinion, involves leveraging or creating code and infrastructure to handle automating assemblages of software. Scripting is often how that's done. Configuration management tools add some formalism to the process, but it's still "glue and tape"-- albeit fancy.

I think Group Policies are a very incomplete, partial solution. As you said, you usually have to combine it with a few more things to get the job done, and that is how any sysadmin job works. But: You need not only a one-off-script to make things really work.

You need a script that is idempotent, so you can execute it on all your machines and maybe do a retry or two if some are unreachable or an error happens. So the script should not only change things it is supposed to change (e.g. append a configuration line somewhere) but also check if that action is necessary or already done (e.g. that line has already been appended). Then you maybe need to restart the respective service to reread it's configuration. But of course you wouldn't want to unnecessarily restart it, since that might be disruptive or expensive, so you have to check if that configuration has been changed or not before restarting. Then handle automatic application for machines that are currently offline, have just been installed or need a refresh. Add in a some templateing and parameters, different groups, logging success/failure and you are at quite a complex script.

Or rather, a script that no-one should write, because it is exactly what configuration management is supposed to do. If you are writing all that by hand for each one-off, you are doing it wrong because you are reinventing the wheel, and usually badly. If you aren't doing all that, you are missing important parts. So imho configuration management like puppet, salt, chef, … is table stakes for any kind of sysadmin work. I'm not familiar with Windows DSC, but I find it strange that you dismiss it as pandering to the Linux crowd.

I like Windows Server more than Linux. I administer both of them, although I am more familiar with Windows Server which definitely plays a big part in my preference. But I think that's going to be the biggest part of anyone's preference.

Everything you complain about Windows Server not supporting is actually supported, but it was your unfamiliarity that was ultimately the issue. "Linux guy who is unfamiliar with Windows Server prefers Linux" isn't particularly shocking news.

"When in Rome, do as the Romans do."

I don't complain that Linux is hard to administer with PowerShell. I learned SSH and Bash.

The reverse does not seem to be true, Linux admins generally expect everything to work exactly the same in Windows as in Linux.

A negative effect of this is that Windows has many recent hires working on some of their teams with mostly Linux experience, and they're copying Linuxisms into Windows bug-for-bug. Even if it makes no sense in Windows.

A recent example that boiled my blood is that the new Windows Terminal emulates the incorrect "Clear-Host" behaviour of ancient Linux terminals. It doesn't clear the virtual terminal any more, just the current viewport. Before, it was a convenient way to reset the terminal's display state without resetting variables. NOW, it just deletes some of the display state, so if you scroll back you get scrambled garbage.

This is not a small thing: it's significantly impacting my workflow. I've seen garbage output, overwritten output, scrolling back accidentally corrupts the output completely, you name it. This is not a coding error, this is correctly copying a limitation of some terrible terminal from the 1960s nobody should give a shit about in 2021.

Worse: If you look back at the history of the debate around fixing this, as far back as the early 1990s there were Linux people advocating for fixing this! It's obviously broken.

Then: When the same debate came up in the Windows Terminal issue tracker, people making the same rational, logical arguments were shot down with: "We have to copy the standard."

Hint: There is no "standard". This is not an RFC. It's just what Linux does! Linux does this just because this is what some random MIT or Berkley student wrote in a hurry in the 1960s! If you make the argument that the majority of systems work some way or another, and that's a defacto standard... then Windows should win because it was used for the the vast majority of computing for many decades. Linux has taken over only recently, and only in some areas (Android and web servers).

> A recent example that boiled my blood is that the new Windows Terminal emulates the incorrect "Clear-Host" behaviour of ancient Linux terminals.

Hi! I run the team who made this decision, and I flatly reject the characterization that these changes were made by "recent hires" who are "copying Linuxisms into Windows bug-for-bug."

The discussion you're referring to spans multiple threads, so I'm not certain the exact one you're referring to. I can, however, give some of my input:

1. We worked pretty hard to make sure that PowerShell's Clear-Host and CMD's "CLS", which operate on the entire scrollback buffer in the traditional console, are properly translated into a full buffer clear over SSH/in Terminal/etc.

2. Terminal fully supports CSI 3 J, a non-standard extension to the Erase in Display control sequence that clears the scrollback buffer. The handful of tools I am using that support "clear" actually seem to emit both "clear viewport" and "clear buffer." If you're using a version of clear that has been configured to NOT emit ED 3 (clear scrollback history) by default, that's simply not my team's fault. I've heard that you can use "clear -x" to affect your desired behavior.

It turns out that there being no true standard here plays to our advantage: we can support requests for all manner of clear, and trust that an application can be made to do the right thing. If you're using an application that can't be made to do the right thing per at least thirty other terminal emulators' designs--spanning more than just Windows and Linux, mind you--I apologize.

If you'd like to reopen that discussion here instead of on GitHub, you are more than welcome to.

> Hi! I run the team who made this decision, and I flatly reject the characterization that these changes were made by "recent hires" who are "copying Linuxisms into Windows bug-for-bug."

Hi! I see Microsoft people on "docs.microsoft.com" use forward slashes now in examples that only work on Windows. So, there's that.

If I open the latest version of Windows Terminal, running PowerShell Core (not some Bash thing with some VTY codes or whatever) and I run "Clear-Host", I can scroll back and see content that wasn't cleared.

THIS BREAKS MY WORKFLOW. I used Clear-Host so I can run a command with pages out of output, and then I know that scrolling back will go back to that output only, not something that happened three hours ago but superficially looks identical.

If I do this with PowerShell 5.1 with the old Terminal, it works as expected. It works like it has for the last 40 years of DOS and Windows history.

PS: It's broken even worse in Visual Studio Code.

You guys outright abandoned your user base to pander to Linux users. On Windows. Linux users on Windows. That enormous, huge majority of your paying user base that is apparently more important that the hundreds of millions of people like me.

So yeah, you should reopen the issue and rethink your priorities...

>You guys outright abandoned you user base to pander to Linux users. On Windows. Linux users on Windows.

IMO they're going after developers using Macs. Linux (and Docker) runs better on Windows than it does on Mac OS. They're doing _something_ right.

So you're saying that Linux developers on Macs are now Microsoft's target market?

Not Windows developers on Windows?

Basically it feels like going after the SV crowd coding with macs on starbucks.

It feels like that Blizzard developer Wyatt Cheng that got on stage and asked the PC gamer crowd: "Do you guys not have phones?" https://www.youtube.com/watch?v=n5QRgpjfarY

The Windows Terminal guys are similar. "Do you have any plans at all to make this work for users of Windows?" "No."

I feel your pain, what used to be Visual Studio wizards are now CLI tools.

With luck you need to install VSCode and there is an extension to call said CLI.

Who needs VS designers or Blend for Windows UI development? Just recompile and run WinUI applications.

I really don't get it.

Those recent hires are also affecting how Visual Studio gets developed.

It is starting to become tiresome to get some CLI stuff instead of proper VS wizards.

Microsoft is getting really lazy with their new "PowerShell for everything" mantra. Many examples with Windows Server and even the Azure Portal. It's great to have the ability to do things with both a GUI and CLI, but then arbitrarily limiting things to one or the other (usually the CLI) gets incredibly annoying.

Lets limit GUI then :)

Ha, that's actually what I'm complaining about. So many things that can only be done via CLI and there's no way to even know they're possible without crawling through documentation or (more often) finding somebody's blog post or a StackOverflow answer.

PowerShell CLI is totally discoverable tho.

I'm probably pretty similar in experience to you. I "grew up" with Linux (and Xenix) in the early 90s, not being able to afford to buy Windows Server. I transitioned over to Windows Server around NT 3.51 and now handle both.

All the tooling for headless / remotely-manageable Windows is "in there" in 2008 and later. Prior versions required more jumping thru hoops to manage via command line, but Resource Kit tools helped.

My server administration journey actually began with a pirated copy of Windows 2000 Advanced Server. And I don't feel bad for it, because having started very young with Windows Server has directly led to many tens/hundreds of thousands of dollars in licensing fees paid to Microsoft at my direction :)

You missed a lot of tedious reboots by starting your experience with the Windows NT family w/ Windows 2000. Windows NT 4.0 was a breath of fresh air, as far as the UI went, compared to NT 3.51, but Windows NT didn't really come into its own, in my opinion, until Windows 2000.

The tedious "re-apply the service pack and reboot" or "you thought about changing a setting, so therefore reboot" scenarios were nearly removed with Windows 2000. Having plug 'n play and hot-plug hardware work well was great, too.

I do mostly Windows, and given the option would rather keep doing so, however you just reminded me of the "fun" of writing ISAPI extensions on Windows 2000.

For those unaware of it, IIS used to execute fully on kernel level, so ISAPI extensions were comparable to device drivers, which meant any programming error would just kill the kernel, thus requiring a reboot.

So tracking down memory corruption issues on ISAPI extensions was bound to have a countless amount of reboots during the work day.

Goodness, who decided that was a good idea?!

Thr ISAPI modules don't run in kernel mode, but they're in-process with IIS (back in W2K) and it's a bit fraught.

I assumed that kernel-mode HTTP service was an answer by Microsoft to the "Tux" web server: https://en.m.wikipedia.org/wiki/TUX_web_server

> Everything you complain about Windows Server not supporting is actually supported, but it was your unfamiliarity that was ultimately the issue.

Funny, I've seen people saying exactly that when newbies bounce off some aspect of Linux, and in both cases it's a usability failure.

Discoverability of this stuff on Windows is terrible. Things like powershell remoting exist but getting them working between two random machines is opaque. Yes, some of it gets easier in a domain, and that's one of the big Windows wins (since the NIS/YP era), but domains are an extremely premium feature.

As if UNIX was any better with its archaic configuration files and cryptic commands to avoid typing one extra character.

Most of the stuff I learned about UNIX required actually buying books, not much different from Windows.

Drop someone on a proper UNIX just with man to see how far they go joining a NFS server or logging in via yellow pages.

Its trivial without domain TBH.

If on workgroup, you just have to have the same user name on different machine and it works like in domain.

> Discoverability of this stuff on Windows is terrible

Meh... matter of taste and adequate Windows social skills, not a fact.

"If on workgroup, you just have to have the same user name on different machine and it works like in domain"

... and password. ... and no it doesn't really because an AD has a few other extras, such as Kerberos and an LDAP database with some odd ideas to chat to. You can of course spin up a Samba AD DC or two for a cheaper alternative.

I don't think comparing discoverability of features in Desktop Linux to Windows Server is fair at all.

And really, if you want to talk about discoverability between Linux in a server role and a Windows Server... Windows Server wins by an absolute landslide. But I don't think discoverability is all that important when you're talking about server administration.

This. RTFM

Windows OS is a thing of the past, when people were supposed to do most of their work from a desktop. As soon as computing become based on remote services, Windows lost its main reason to exist. It is Windows that needs to adapts to the new times, not people working on other OSs.

It is the OS from the past and still most people use it on their computers. Because they are still doing things from the desktop. And I suppose they're happy not having to adapt to technology du jour again and again.

MSIs, if put together well, easily install silently from the command line.

msiexec /qn /i msi-name.msi

Edit (now that I have more time):

All the tooling to make Windows command-line manageable is there "out of the box".

In a former "life" I staged a Windows Server 2008 R2 install that was remotely manageable with SSH (using a third-party SSH server) "out of the box". Similar to a "kickstart" w/ the Anaconda installer, you're talking about chaining scripts to run after the installation to enable desired functionality. It wasn't much different than automating a Linux install.

If you enable the serial console you can do some nice command-line management of Windows VMs through your hypervisor's virtual serial port functionality too. I enjoy having the serial console open because I've been able to diagnose "hung" Windows machines (that is, not responding to GUI logon attempts) thru the console. It's very handy.

and /norestart too

Its about 5 lines of powershell to install and start OpenSSH. Maybe a few more if you want to automatically inject public keys. Well within possibilities of a user_data script that runs on the first boot of an AWS instance.

My main pain with OpenSSH on Windows was that its an older 7.7 Windows port that gets installed. However 8.1 is finally bundled as part of the recent KB5001391 and fixes some annoying bugs.

I seem to recall authorized_keys works as expected; it goes into %HOME%\.ssh\authorized_keys (I'm not sure/can't recall if there are some similar permission requirements). Anyway, that's eg: c:\users\mcgyver\.ssh\authorized_keys

And ssh needs a restart.

That said, windows remote management is traditionally via WMI, not powershell. But PS has come a long way, and ssh is a sane transport. And it can function as a tunnel for WMI, RDP and PS (ssh is easier to use for key based auth, disabling password auth).

If you're a member of the administrators group, by default it uses something out of C:\ProgramData instead.

https://docs.microsoft.com/en-us/windows-server/administrati...

But of course, you're not running as Administrator, right? That's why we have runas... :)

In my experience, even MSIs can be run from the command line, but the amount of effort required to look this up and write a clean script is definitely way more than the equivalent Linux sysadmin task because Windows is just not expecting users to work this way at all.

My gripe with installing things on Linux is that every project assumes install means “build from source”, and it’s often annoyingly hard to find the exact yum/apt-get name for something (do I need a PPA? is the name thing, libthing, libthing-dev, libthing2, or something else?) But this is a much smaller issue than anything I run into with Windows Server.

> Powershell is apparently pretty modern and well designed, but it's quite confusing if you're used to Unix.

bash is pretty confusing eve if you're used to unix

-- Greg's

Bash is simply outdated. It grown organically and thats what you got. Now you have zillion scripts and situation is even worst then with cobol.

PowerShell was made by Unix people after 2+ decades of bash experience. It solved hundreds of things.

Yet people complain it didn't solve few or it takes a bit more to load (no, verbosity = RTFM). You can't ever please I guess.

Writing powershell scripts on vscode with the ps plugin is quite pleasant. Would recommend everyone to try it.

were powershell designers from the unix world ? I didn't know that

I don't mind bash warts, history is what it is, I don't sell powershell .. but someone saying powershell is confusing has serious jaws. powershell is really nice and only if you fancy sed/grep everything then you'll consider bash* superior

> Sure, although, you know, my team – we all have deep UNIX backgrounds, before getting into NT, I was a UNIX development manager at Digital [Equipment Corporation], … worked on Ultrix, System 5.

https://www.networkworld.com/article/3110744/linuxcon-qa-wit...

oh wow, I had no idea

thanks for the link

I don't think I want to compare them - I dislike them both! One is too basic and cryptic, the other one is overly complex for a shell, and in the end, I want to use neither.

I'm not sure what the ideal shell would look like though. Maybe an actual (simple and expressive) programming language with a way to 'lift' statements ?

oh my bad then, and the quest for an ideal shell / text user interface is a nice one. between lispy repls, to notebooks .. I guess there's a better solution that is both concise and fun yet not brittle.

The situation gets worse every year with multitude new commanline utilities and scripts being created as part of new frameworks, languages and tools. And then everything gets mixed together to form some unstable, ever changing, inconsistent programming language.

sed/grep/awk have nothing to do with bash tho and you can run them equally easy on Windows (cinst sed grep awk) if you like outdated reg ex.

yes they're not bash but they're an integral part of bash scripts pipe processing

They are "integral" only because shell is lacking those functions.

On some places tools are not there (docker image for example).

Some people complain about size of the dotNet runtime, but if you install all those tools bash "needs" for comfy usage, you can equally easy install dotNet.

I don't think that's right. unix users care a lot about streams of bytes as exchange format, powershell tried the object stream way, to avoid parsing manually stuff every time and also share some common bits (table formatting for free, map/filter for free too)

unix give you partial stuff for that like comm but it's just brittle

I don't use it in production but yea, I've read that automation for windows servers is mainly geared toward management with powershell. It's been a while since I've used it and it's definitely a lot different than bash, but it seemed petty elegant when I used it last. I like objected oriented programming, so having an object oriented shell was pretty neat.

But PowerShell feels so clunky and slow to me (disclosure: I'm used to Linux). If you want object-oriented automation tools, Python works much better on Linux. Granted, it's not a shell, but if we're talking automation, then it doesn't really matter.

I think the big issue for Windows is that most "admins" aren't in the habit of automating things, or at most they'll write a basic bat file. They still expect to click around their GUIs, so they'll be fairly reticent to install the Windows Server Core version [0]. "To be able to intervene in case something happens". The main issue with this is that they often aren't aware of possibilities offered only via PowerShell[1]. There's also the issue that when they look things over in the GUI, they won't see the configuration that's only visible through PowerShell.

---

[0] Windows Server Core comes without a GUI, but it can be managed remotely with the usual tools. However, not all server roles work on it. Remote Desktop Gateway is one such example, even though it doesn't have any "desktop" functionality.

[1] For example setting up split-view DNS. This is possible since Windows 2016, but only via PowerShell, and it's impossible to know from the GUI that it's activated. Also, this configuration doesn't replicate through ActiveDirectory.

I don't have much experience with Linux. All our customers (health care, mostly US) have Windows servers. Some of them have some Linux also, but that seems to be a minority. We need to be able to ship software they can run. Most of our development is windows-based.

I think mostly they're forced to use Windows server because of their proprietary software like outlook, active directory, iis etc.

It was maybe easier to find people to support Windows servers... Just click here here and here to install.

All of the modern GUI is just a skin over powershell. Most server functionality/configuration isn't exposed through the GUI.

I kinda like Windows server, mostly for the stability - both of the runtime and of functionality. Compared to Linux it requires less attention, i can concentrate more on software and less on the system: after two years of not touching i can still find configuration options in more or less same places. With Linux i have to re-learn quite a lot after not paying attention for a while. Missing good ssh/command line but not badly, I don't really need advanced shell scripting.