Hacker News Reader

Comment by setquk | Hacker News Reader

I genuinely don't get this. WSL's backing filesystem (NTFS) completely runs like ass. It's dire. 10x the latency on everything at least compared to Linux running natively on the same hardware. This is because all small writes end up in MFT contention and the entire of Unixy type things are based on lots of small writes.

Plus on top of that, everything is rammed with telemetry on windows now, the QA has gone down the toilet leading to a hosed machine at least three times in the last two years for me and there is no clear direction they are going in other than "throw poo on everything and see where it sticks". Any bets you make are risky.

And honestly when I read about powershell and chocolatey used there I laugh because a huge amount of friction for me came from that direction. powershell's principle is based on the principle of most surprise. Like when I tell it to download something, I don't expect to have to futz with IE browser settings (WTF?!?!). And chocolatey sucks - the repository it pulls from is full of abandoned and broken crap and missing packages (.net SDKs are my favourite pain point here) where people have thought "hey it'll be good to port this" and then leave it to rot.

That's the status quo for me and I'm not happy.

I'm going the other way to OSX. It mostly just works and that's all I want and there's a local support network for the hardware which is decent and doesn't involve me shipping it off to some third party and losing it for 2 weeks.

View on HN

I feel the same way. I used to use my Windows machine for everything and didn't even own a Mac but working on a Mac has been a real joy comparatively, especially for dev work. Now, my Windows machine is relegated to just being a gaming rig and I'm 100% happy with that. When I heard that WSL was a thing, I went back to try and get that setup and, between trying to turn off Cortana, navigating the god-awful new Control Panel/Settings, and the terrible overall performance, I don't know how someone could subject themselves to that in a professional capacity. Windows to me is infuriating and I'm pretty technically proficient. I feel bad for the droves of users that end up on it and don't have a choice, especially those that aren't technically skilled. It's just bad now.

> I don't know how someone could subject themselves to that in a professional capacity.

Active Directory. Well, AD and a bunch of applications that are critical to the business only operating and supported on Windows. But the other OSs don't have anything as good for management of the environment as AD is.

AD only works if all your clients are windows. In 2018, not all of them are. We're out of a monoculture now. Doing AD SSO on other platforms is a proper pain in the butt. For example when Microsoft deprecated some of the old protocols a few years back they broke RHEL entirely for 2 years.

Not sure there is another solution though. OAuth and various cloud logins etc isn't, yet.

> AD only works if all your clients are windows.

Uh, yeah, that's kinda my point. Outside of SV, pretty much every client is, and for this reason.

This is increasingly not the case though.

Not every country people can enjoy a quality level to afford Apple computers, even with IT salaries.

Fair. But I was commenting more on the environments that historically were served well by AD (offices) are growing in use of Apple computers.

[Citation Needed]

I can believe that this is a true statement inside the reality distortion bubble around SV, but here in the real world I'll need to see some evidence.

MICROSOFT went heterogeneous client for their AD. I'm sure others can.

The problem is that you're assuming I'm in SV, I'm in a small Swedish city and I'm seeing our _very_ windows heavy company starting to adopt Apple computers.

And when I think of the companies I worked for in London they were also increasing the Apple quotient of desktop/laptop machines.

Yes, this is anecdatum but I really can't tell you how strongly integrated Windows is at my company and we're still seeing adoption of Apple computers.

Regardless of that, Sysadmins and Developers tend to get to choose their OS at most sensible companies. (Every company I've worked for, barring the current, has allowed Linux; most even encouraged it)

Why do you immediately jump to the conclusion that the parent was referring to just Macs?

Because I have seldom worked in environments that allowed anything else as desktop.

UNIX derived OSes tend to be relegated to the server room, accessed remotely and live on their own network.

Are you saying that outside of Silicon Valley pretty much every client is Windows? Where do you live?

I work for a Fortune 100 company (not in SV, or even California) with 70,000 employees. At least 50% (it's probably higher) of computers here are Macs. When I go to a meeting, the table is a sea of Mac laptops with the occasional Windows laptop here and there. And these aren't meetings with developers, I'm talking about sales, business, training, etc. people.

That’s still extremely rare. Personal laptops are always up to personal preferences, but most organizations run on windows. At my employer, a university enrolling 50,000, everything is windows. If you wanted to request a new computer through the school to have access to shared directories, you can pick a dell desktop or one of two HP laptops. Macs are rare, and they are bought and forgot by IT. I’ve seen iMacs running leopard still; and they are all off of the intranet.

For my friends who do get macs from their workplace, it’s because they are 1 of just 20 employees and they don’t have anyone in IT, let alone a department or any policies.

One difference might be that almost nobody has a desktop computer. The vast majority of people use a laptop. But they are free to select from a menu of about 20 different laptops including Mac Book Airs and Mac Book Pros. Almost everyone also has a company supplied phone. Again, they have the a selection of about 20 phones to select from, including Android and iPhones. So the environment here is very heterogeneous.

>AD only works if all your clients are windows. In 2018, not all of them are. We're out of a monoculture now. Doing AD SSO on other platforms is a proper pain in the butt.

That's simply untrue. Every large org I work with has unified auth with ad and a secondary package like centrify. It's trivial to get working.

And that's ignoring all the linux appliances and embeded Linux flavors (think lights out management) that support AD out of the box.

While I think that's a good point, there are alternatives to AD at this point in time. Anyone using that as a crutch is just giving excuses for not wanting to update their infrastructure.

And those alternatives would be...?

MS is very slowly moving away from AD themselves to a "MDM" cloud-provisioning model more or less copied wholesale from what Apple did with iOS. They claim that binding machines and users to AD is optional these days, but the alternative workflow leaves a whooooole lotta gaps. Maybe in 5 years it will be a real alternative.

Plug: I work out JumpCloud, a directory as a service company.

I use windows on my dev machine for one reason - visual studio.

I recently tried setting up an alternative dev environment on Linux and it takes some work but I think Visual Studio can be matched on Linux now for C++ development.

The combination of VSCode, cquery, and clangd can provide code completion and navigation that I think is finally on par with IntelliSense, and it scales to large projects. VSCode's GDB integration is tolerable for debugging.

Linux has some definite advantages too. For one thing the filesystem is just blazing fast, which really helps with git. Various other things are faster too, like I'm writing an OpenGL app and creating a GL context is much faster on Linux. Also I've been trying out https://zapcc.com which made my builds five times faster, no joke. I'd almost move to Linux for that alone.

Just want to second this. Cquery can be finicky to get working, especially if your project involves precompiled headers (I've found that building cquery from source myself and ensuring that it's linked against the same version of libclang as the clang I'm using for compilation helps).

But once it's working, cquery is an absolute game changer for C++ development. It feels like a completely different activity than it did before.

VS is so much more than just code completion and navigation, even for C++.

Code completion, navigation, and debugging are the only VS features I miss on other platforms. What C++ features are you thinking of?

Architecture modelling, unit testing, C++/CLI, C++/CX (now C++/WinRT), MFC/UWP, multi-threading/GPGPU debugging, secure STL, SDL annotations, code maps.

I use the refactoring features quite a bit. The dialog editor is pretty easy to use as well.

I'd love to see a blog post that gets a fully-featured C++ dev env working in VSCode.

Oh boy, if they somehow made the control panel even worse than it was in Win7, I'll have to take a look at it myself.

I've counted the different kinds of windows in Win7 control panel: there are ten of them. Ten distinct methods of organizing stuff in a window, all in the settings section of the OS, and that's not including third-party additions. There are navigational widgets that don't occur anywhere else in the OS (sidebars with links, iirc).

Also, all the hours lost in wandering through the control panel due to its awful localization…

These days, I'm pretty sure control panels can be used as a litmus test as to whether the GUI authors have a grip on UI design.

Windows 10 added a separate settings menu which doesn't support CPL applets so they kept the old one too. So now all of your settings are in two different places, but phrased slightly differently and in two menu trees and with fewer or more options for each setting. Oh, and now all the windows are WPF in a SPA, so they look different too.

It feels the settings are in dozen different places on Windows to begin with when it could go down 5 levels or deeper to get to the option you're looking for.

The "good old" control panel doesn't even look categorized well.

ha! you’ll love windows 10 let me tell you...

Apple wanting me to know all special keys by heart and not having ergonomic keyboards is one of the reasons that puts me off.

Plus why do they have to have a microscopic return key on laptops?

One of my most favorite things on MacOS is that cod+? Opens the help search menu which you can use to type the name of a command you want to run but don’t know where to find or what combo it uses. It’s especially useful for menu items that don’t have a key map assigned.

I use a MicroSoft ergonomic keyboard with my Mac Pro. It works just fine. I also have all of my keys mapped to the same as what I was used to when I used to use Windows (ironically the last time I used Windows was about 15 years ago, old habits die hard).

I'm using MS Natural 4000 with a Macbook. Alt and Win keys are remapped through the standard settings, the context menu key is remapped with Karabiner. Some extra keys can be mapped, only alas the numbered ones aren't seen even by USB Overdrive.

(Of course, the Natural/Sculpt series barely scrapes the ‘ergonomics,’ what with the slanted key layout inherited from typewriters, the flat board made for extendable fingers instead of jointed ones, the too-low wrist pad.)

As for the special keys, I'm not sure what that's about, since I'm using pretty much the same number of hotkeys as I did in Linux and a bit more than in Windows. I'm also using Alfred for many commands, which are made in English instead of obscure semi-random keys.

What? They don't want you to know them by heart that's why they're all listed in the menu next to every command that has them and they update live as you hold down the keys so you can see what modifiers are available.

Also, you can use whatever keyboard you want. I don't see how this is an issue at all... And what microscopic return key are you referring to? The return key on my MacBook is nearly the same size (maybe a half-centimeter shorter) than my full-size desktop keyboard.

I started doing web dev before 2000. Only Windows worked as a dev machine then and OS X came around but obviously lack of third party tools made it a no go. Now I can't think of going back to Windows because third party tools that I take as granted aren't even avaialable with same level of quality on Windows.

3 or so years ago, I tried to set up a dev environment on Windows just see how good it can be then but gave up in 1 hour knowing it'll just slow me down bad.

I have no idea why most of people I know around still use Windows (and funnily 1 guy uses Linux)

I was nodding along, until you said that "on OSX things mostly just work". Oh boy. I have fought homebrew, I have fought Apple destroying permissions on each update, and the OS having embarassing mistakes.

Linux: not much better.

Everything sucks, they just suck in a variety of different flavors.

Yes you’re right there I suppose. The point is I pick the sandwich with the least amount of shit in it if I can.

It depends on domain. I hate working with MacOS APIs far more than either Windows or Linux. They don't give a damn about backwards compatibility, force you to use programming languages nobody uses on any other platform (no, I don't care how "nice" it is), and change without a moment's notice. They actively shun and deprecate open source solutions, and seem to go out of their way to be that special snowflake. You could say certain things perform better on Mac, but other things (like graphics) are utter garbage due to the lack of first party driver support. You can install bootcamp on a Mac and get better games and graphics editing performance immediately for example. That plus the overexpensive hardware and lack of a real keyboard and I'm just done.

I've had a pretty good experience running MacPorts instead of homebrew. It's easily been the best package management experience I've on a non-Linux OS.

Interesting, had the opposite experience. Homebrew does almost everything very nicely for me. Macports not as much, although to be fair this was years ago.

My last experience with homebrew was a while ago, but it was a jankfest. The repo was littered with arbitrary major/minor versions of the same packages and the bottling metaphors (bottles, casks, tap, pour -- a cellar even?) are IMO contrived and do nothing to make things understandable. At one point I had to go create a Github API token and set it in my environment just to make the thing work again. And lastly, I just couldn't take seriously the idea that piping the output of curl into sudo is the install method for something that wants to spread itself across your filesystem.

Maybe I'm old, but it struck me like they're reinventing the wheel without even trying to understand what works with existing package management.

macports forces you to install 15GB application that lots of users don't need(xcode). Homebrew just requires the cli tools.

Not true. You can use the Xcode command line tools now, without actually installing the full Xcode. I do this on my home machine and it's fine.

At least the updates work. I’ve lost count of the number of times Windows update has failed. Reboot loops, half-installed updates, updates conflicting with each other, and updates that killed my internet connection. At least I haven’t had an update brick my machine. Yet.

And don’t get me started on the upgrade process. Quicker and easier to drive to the store and buy a new machine.

> At least the updates work.

Ehhh, I had a whale of a time upgrading a machine (standard Core i7 desktop) from Ubuntu 16.04 LTS to 18.04. Read: I lost the entire machine and had to reinstall from scratch.

Also, Linux support for new hardware isn't amazing. So when I upgraded to a Ryzen APU, it basically wasn't possible to get Linux running on it without resorting to a beta kernel and lots of manual futzing around. WSL has been a godsend for me.

The plan was always for Linux to become the best operating system for everybody. The plan was not to become the best by everybody else deciding to suck. Still, a victory is a victory...

> powershell's principle is based on the principle of most surprise.

I don't think that's true at all. Compare powershell command names to UNIX command names for example. You can rest assured that Get-X will not change things and that there is almost certainly a Set-X that will, for example. You can tab complete variable names, cmdlet names, cmdlet switches, etc. Additionally, by piping objects instead of text, you aren't caught off guard by things like spaces in a path name.

> Like when I tell it to download something, I don't expect to have to futz with IE browser settings (WTF?!?!).

It definitely does have some flaws though, I'll give you that.

As an aside, you can use Invoke-WebRequest with the `-UseBasicParsing` switch to leave IE out of it. They definitely should have done that the other way around.

The last point is the point really.

The entire objectivity of it is ruined by weird edge cases and knowledge. The car only goes straight if both rear windows are open. You have to say "beetlejuice" three times before putting it in reverse etc etc.

You sure you aren't describing an average UNIX command?

No because you don't have to google for an hour to find the "don't punch me in the dick" flag.

Instead you just have to google how to use `tar` properly. Again.

You can tab complete powershell cmdlet switches. And MSDN has extensive and good documentation. Here's the page for Invoke-WebRequest. Notice the very first switch listed. Further note that Microsoft realized they screwed this up and deprecated the switch in PS 6.0 since it is now the default.

https://docs.microsoft.com/en-us/powershell/module/microsoft...

No googling because it hasn't changed in the last 20 years.

How do you unzip a 20 gig file in powershell?

1. You can use the windows shell via complicated series of calls. This runs like ass as the windows built in decompression is terrible. Also it only works properly if there's a desktop session running so over WinRM it does with a COM error.

2. Find out which version of powershell you have, hope it's 5.0 or later or install the right WMF version and then run expand-archive. And it still runs like ass. But oh no we can't because now we have to push WMF 5.0 to 150 servers which is going to take DAYS with SCCM. Some kit is on Windows 2012, some on 2012 R2 and some on 2016 because it's so damn hard migrating stuff as it has to be done by hand so you have a mix of stuff leading to a nightmare from hell.

3. Import System.IO.Compression and call .Net to do it then wrap it in a cmdlet called Expand-Archive, then wonder why it breaks when someone pushes out WMF 5.0+

4. Push 7za.exe out with ansible and run that.

This is the problem. No good outcome for really simple tasks. Friction for all of them.

Edit: I'm being 100% honest here and say I hate it with such a passion because I've lived in the same building as it for several years, not because I'm not aware of how it works.

> Import System.IO.Compression and call .Net to do it.

...and? Why is that a problem? It is an advantage that PowerShell can call on the CLR directly (including its C FFI).

Because half the time it slings

Exception calling "ExtractToDirectory" with "2" argument(s): "End of Central Directory record could not be found."

7zip works fine!

(copied straight from my MASSIVE OneNote book of weird powershell and .Net errors and workarounds). Also they just deprecated OneNote desktop other than the turdy UWP app. Another thing to be angry about.

But you're completely willing to forgive UNIX's toolset's problems because you're used to them after working with them for decades. I get it, but that does not make them better.

Working properly == better in my mind.

Consistency, trust over everything.

"properly" in this context meaning "the way I am used to, warts and all", right? Because otherwise I can't see why you'd be so upset about Invoke-WebRequest doing exactly what it was designed and documented to do.

Consistency? In UNIX tools? No. What you have is familiarity. Don't get me wrong, there's a lot to be said for working with tools you're familiar with, but again that doesn't mean they are actually objectively better tools.

Properly as in it does the intended job.

Consistently as in it stays doing the intended job in as an idempotent manor as possible.

Whether or not it’s ugly or elegant don’t matter if it doesn’t work or stay working.

You can argue semantics but this is a turd that can’t be glittered.

Another way to look at powershell is that the idea is good but the implementation isn’t. Unix style shells the implementation is excellent but the idea is mediocre. All productivity and therefore business value is really tied to the implementation quality.

> Another way to look at powershell is that the idea is good but the implementation isn’t.

I wouldn't entirely disagree with that statement.

> Unix style shells the implementation is excellent but the idea is mediocre.

This I would. The idea was a really good one... in the 70s. It has utterly failed to evolve since then. The implementation is actually pretty horrible. If you don't have a lot of familiarity with it it is undiscoverable, full of footguns, and consistency is an afterthought.

You learn to really appreciate POSIX implementations when you do things like grep and pipe results over 100GB+ text files. and no, these text files were not created due to unix philosophy, I’m talking about xml generated in Java as an example. grep&co are a godsend trying to tackle these without ripping out every hair on your body.

Specially when one is adventurous to write them in a portable way across multiple POSIX implementations.

forget about it *nix has won. No matter hiw bad some of it's design might have been. The was some nix fanatics act makes me worry about open source in general

The only two tar commands most people will ever need:

Equivalent of "zip": `tar cjf OutputFile.tar.bz2 InputFileOne InputFileTwo InputFileThree`

Equivalent of "unzip": `tar xf InputFile.whatever.extension`

(This works whether `InputFile.whatever.extension` is bzipped, gzipped, or not compressed at all)

I would strongly suggest that you use the `a` flag rather than `j`, to automatically select file type.

```tar --help | grep <thing I am trying to do>```

What can be simpler than tar? ‘tar eXtractZipFileVerbose $file’, done!

> You can tab complete variable names, cmdlet names, cmdlet switches, etc.

UNIX shells can do all that too.

> Additionally, by piping objects instead of text, you aren't caught off guard by things like spaces in a path name.

Not just spaces, to be fair. Files that begin with a hyphen can cause major issues too.

There’s definitely a lot of weird edge cases with UNIX shells but on the whole I still find them easier to work with than Powershell. But that’s just me

Which one did you learn to use first? Wondering if that has much of an impact. I've only used Powershell for a bit while I work with *nix shells daily so I'm definitely biased towards them but wonder if I'd cut my teeth on Powershell if I'd think the same way.

Neither. I leaned the CLI from DOS (or it might have been CP/M?).

Unless you count BBC BASIC?

What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands?

Or interact with running applications using the OS APIs like Powershell allows with WMI, COM, OLE Automation and .NET?

Yes, there is DBUS, but isn't really integrated across the whole stack.

If I want that level of control I wouldn’t want to be writing a shell script in the first place.

That’s the problem with Powershell for me, it’s taken the REPL concept but made it too feature rich and too verbose so you lose the speed of writing the code and simplicity of piping predictable streams of data.

The thing with Linux / UNIX is it’s very command line driven from the outset. So if you wanted to do the function calls from shared libraries et al you could write a wrapper in C, Python, Perl, whatever and still use Bash etc to interface with it. You’re not tied to using Bash to solve all of your problems. Bash just provides a convenient interface for chaining all those tools in other languages together. Now I know the same can be said for command prompts on Windows but for whatever reason that seems to be less common than it is on POSIX.

That is where you get it wrong, because the REPL concept as introduced by Smalltalk and Interlisp-D/Lisp Machines it is exactly what Powershell tries to achieve.

UNIX shells are a poor imitation of it.

I never said UNIX invented the REPL concept (though I’d have thought time sharing systems predated LISP machines) and this a conversation about personal preference so there is not right or wrong answers (aside arrogant comments from techies who feel they should belittle others for having differing preferences).

I don’t happen to like Powershell. That doesn’t make me wrong. That literally just means I don’t happen to like Powershell. Period.

(and voting me down for personal preference is really just pathetic)

I am not the one downvoting you, I rather have discussions, even when I might not be right.

> REPL concept

the interactive REPL was introduced by Lisp around 1962 way before Lisp Machines, Smalltalk...

Yes, but not with the capabilities that their graphical sucessors brought into the computing world.

You surely could not display inline structured data and interact with it graphically on an IBM 704 teletype.

Well, you had Lisp structure editors already in the 60s. Doing it graphically doesn't really add too much to it. If you read the manual for BBN Lisp, you can see that it did end 60s / early 70s more than many current systems do - like managing source code, working with images, structure editors for code and data, sophisticated user-level error handling, etc..

> What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands?

dlcall

> Or interact with running applications using the OS APIs like Powershell allows with WMI, COM, OLE Automation and .NET?

Depends what you need. You can use nc -U /var/run/socket or pipes with expect. If you have root permissions you can use gdb scripting/ebpf to communicate with user-space/kernel-space data of your application.

> Yes, there is DBUS, but isn't really integrated across the whole stack.

DBUS is a bus for desktops/mobile. I never saw that someone use it for server applications. The main idea(after KISS) of the Linux shell is that if you can't write something in awk it will be better to use python. Actually, in the Linux world, GRPC/REST is more common than OS-level API.

So a couple of Linuxisms not portable across UNIX, which was my point.

Nope. Your point was to argue personal preference as fact rather than simply accepting that some people like apples and others prefer oranges.

I get so utterly sick of stupid arguments where people compare their tools and then proceed to makes claims that one is objectively better than another when it’s clearly just a matter of personal taste

Unix sockets and pipes are portable across all Unix(POSIX, because Linux is not Unix, but OS X is). Furthermore Unix sockets and pipes backwards compatible to 4.4BSD Unix or older OS.

Actually, this comparison is not correct. Windows and Unix have a different philosophy of kernel<->user level interaction. While Windows tries to add all functionality to the kernel, Unix does this on user level. Remember the KISS principle. So If you comfortable with Windows OS level API it's good for you, but for Unix world, it's not necessary to do something because we already have a different inter-process communication approach.

Which is why UNIX shells are a poor man's REPL quite far from what a Xerox inspired user/developer interaction aspired to achieve.

Pipe based interactions work properly only across CLI based applications, and even then the applications need to be explicitly written to accept and parse the data.

PowerShell or other Xerox inspired shells don't need kernel support to achieve their workflows.

> Which is why UNIX shells are a poor man's REPL quite far from what a Xerox inspired user/developer interaction aspired to achieve.

Unix shells are quite good for their purpose. It's not a full-featured programming language. Can you explain what is "poor man's REPL"?

> Pipe based interactions work properly only across CLI based applications

Yes. If you want to find something in logs or looking at any other text data pipes is a good solution. In any other case(like binary data) it will be better to choose GRPC(or any other RPC). I never have seen GUI apps on servers, sorry.

> PowerShell or other Xerox inspired shells don't need kernel support to achieve their workflows.

Good for them :)

A poor man's REPL is a shell that fails short of everything that was possible to do across the OS infrastructure with what Lisp/Smalltalk/Oberon/XDE/Cedar REPLs allowed to do.

An approximation of it would be to have a shell that is a Jupyter netbook with access to the whole set of OS APIs, shared libraries and applications, with the ability to jump into the debugger at any given step of the pipeline, and redo the current step.

I bet you saw GUI apps on UNIX workstations, though.

Then again, maybe Steve Jobs was right after all.

https://www.usenix.org/blog/vault-steve-jobs-keynotes-1987-u...

https://www.cake.co/conversations/rZXhqtP/that-time-i-had-st...

> A poor man's REPL is a shell that fails short of everything that was possible to do across the OS infrastructure with what Lisp/Smalltalk/Oberon/XDE/Cedar REPLs allowed to do.

Shell is a command-line interpreter with additional functionality like scripting. Why it should have fully functional REPL? Lisp/ST/etc are programming languages, they are uncomfortable for copying files, moving directories, calling curl or using tar.

> An approximation of it would be to have a shell that is a Jupyter netbook with access to the whole set of OS APIs, shared libraries and applications, with the ability to jump into the debugger at any given step of the pipeline, and redo the current step.

You can use python for this purpose. I don't understand why Unix shell should have all this functionality.

> I bet you saw GUI apps on UNIX workstations, though.

Yes, of course, I have GUI apps on my MacBook, but they don't use piping for inter-process communication because bi-directional pipes are not quite useful like an ordinary RPC.

I guess we'll have to agree to disagree.

> Shell is a command-line interpreter with additional functionality like scripting. Why it should have fully functional REPL? Lisp/ST/etc are programming languages, they are uncomfortable for copying files, moving directories, calling curl or using tar.

Lisp is an interactive programming language. On can run functions like COPY-FILE, RENAME-FILE, ...

The Listener of the Symbolics Lisp Machine has commands which allow prompting of arguments, input menus, completion, object reuse, etc. It's also integrated in Lisp. For example you can list a directory using a command and then use the pathname objects in calls to Lisp functions. One can also use the output of Lisp functions as input to commands. It's an interesting mix of a command interpreter and a Lisp REPL.

> As an aside, you can use Invoke-WebRequest with the `-UseBasicParsing` switch to leave IE out of it. They definitely should have done that the other way around.

They have made that change:

> This parameter has been deprecated. Beginning with PowerShell 6.0.0, all Web requests use basic parsing only. This parameter is included for backwards compatibility only and any use of it will have no effect on the operation of the cmdlet.

6.0.0 was released on 10 January 2018.

Fun thing about Invoke-WebRequest is that it uses TLS1.0 by default and doesn't understand anything newer unless you enter an incantation beforehand:

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12

It’s even worse thatn that as the behaviour is defined by a weird combination of the OS, the .net framework, powershell version and local policy settings.

Yes, I imagine a lot of .NET devs don't realize their apps are TLSv1.0 only. I've worked with one vendor who was surprised when I told them.

Exactly that. Some vendors have only just got rid of SSLv3 in financial services as well. It’s slightly scary.

I was teaching a class on algorithms to some engineering students. They needed to sort a file of random integers using a few different algorithms.

This is the bash I wrote to check their results were sorted properly on Linux:

    diff <(cat output.txt) <(cat input.txt | sort -n)

This is the PowerShell I wrote to check their results were sorted properly on Windows:

    cat input.txt | foreach-object { [Int] $_ } | sort-object | out-file -encoding ascii sorted.txt
    diff (cat output.txt) (cat sorted.txt)

The casting felt a little painful, but it seemed straightforward. The sorted result was generated correctly.

Unfortunately, I was surprised to discover that PowerShell's diff found no differences between a sorted file of numbers and the unsorted file of numbers.

That's because `diff` is an alias of `Compare-Object`, which works radically differently than UNIX `diff` because of the defaults. In some circumstances you could see how this behavior would be more useful, though obviously not this one.

For reference, `Compare-Object -SyncWindow 0` would give the behavior you wanted. The default is [Int32]::MaxValue.

Aliasing UNIX command names is another one of PowerShell's mistakes in my opinion, because it creates the expectation that they work the same way when they often very much don't. Ultimately rather than help UNIX users, as was probably intended, this just confuses and annoys them.

> rather than help UNIX users, as was probably intended, this just confuses and annoys them.

Compatibility layers are great, when they're actually compatible. Almost-compatible layers are a nightmare.

> Compatibility layers are great, when they're actually compatible. Almost-compatible layers are a nightmare.

That's why you should not use them. You decided to use them.

Well, perhaps some hypothetical "you" uses them:) To be clear, I run 100% genuine Bourne-family shells on unix-like systems, and merely visit MS-land for sightseeing;)

I wasn't just blindly assuming the alias worked the same. I actually read the Compare-Object documentation [1], which contains that exact command as an example of how to compare files. I just didn't understand the sort of comparison it did.

If you search "PowerShell compare two files", it becomes pretty clear this is a common confusion even among people using the name Compare-Object. For example, the top serverfault question has an incorrect top-voted, accepted answer [2].

[1]: https://docs.microsoft.com/en-us/powershell/module/microsoft...

[2]: https://serverfault.com/a/5604

> IE browser settings

Those are the OS web settings. As used by all OS services, e.g. BITS (https://docs.microsoft.com/en-us/windows/desktop/bits/backgr...) and the Live Tile updater; and any app that doesn't embed its own network stack (e.g. Steam, most Mail apps, etc.)

People just think of this control panel as "the IE browser settings" because people use Firefox and Chrome, which do embed most of a network stack (for portability), and therefore ignore most of the OS network settings in favor of their own embedded configuration-points.

I use a mix of mac and windows machines, and all of my dev work is on windows. I mostly agree with the points you mention but they also don't matter that much to me day-to-day.

Windows upgrades have lately had a poor quality track record. I've had a bunch of cheap windows laptops break, all consumer-class machines running windows 10 home. My work thinkpad has been absolutely reliable though, partly because it's a thinkpad (better driver situation), and partly because it's windows pro. I only get feature updates after they've rolled out to everyone else, so by that time all the bugs are sorted out. Everyone knows not to upgrade a mac to a new major release when it's .0, you wait until .1 or .2. Windows home doesn't give you that option, windows pro does.

WSL performance is indeed not great, but getting better with every release. I side-step it by doing the heavy stuff natively. I only use WSL for typical shell scripting, and as soon as I need to run something more I'll figure out a way to solve it natively. There's almost always a way (couldn't figure out hadoop development, had to run a linux VM to do that). Did java, scala, node, php, python all without seeing a bash shell. I see WSL as an escape hatch, not as a daily driver.

I don't use chocolatey. I don't expect windows to do package management well, so I don't even try. I only set up a windows machine at most once a year, and it's not that much work. I do use ninite to get the basics on it faster.

As for the telemetry ... I don't see the harm. There hasn't been a single person reporting real harm (that I'm aware of, someone will now prove me wrong) and they've been doing this telemetry for years. I just wish they used their telemetry instead of shipping bugs that their insider program reported and they subsequently ignored.

They're making their money other places.

That telemetry should not be expected to improve the product 9/10 times.

I switched to Powershell/Windows after 20 years of bash/Linux and MacOS (see https://github.com/mikemaccana/powershell-profile/)

> WSL's backing filesystem (NTFS) completely runs like ass.

Yep you're right, and I've asked Microsoft about this and they're working on it: https://twitter.com/mikemaccana/status/1047941737719762946

> powershell's principle is based on the principle of most surprise.

Really? I find it quite consistent. Here's a bash to powershell conversion:

https://github.com/mikemaccana/powershell-profile/#how-does-...

The general syntax is very much designed rather than grown, you can predict most commands, and using 'select' and 'where' to pick the keys you care about in your output is way better than scraping with regexs.

> Like when I tell it to download something, I don't expect to have to futz with IE browser settings (WTF?!?!).

That sucks. I haven't ever had to do that. I'm not sure why.

WRT NTFS I don't think they can fix it without releasing another major version of it and that comes with some insane level of risk based on the early churn in NTFS. I don't have an appetite for that. They tried to fork it with ReFS but that went pretty much nowhere.

Powershell is amazingly consistent for sure but each little bit of consistency has numerous inconsistencies in it which aren't exactly stable, hence the whole web request nightmare. Also things like different methods of getting the date return timezone and non timezone aware things. They nearly had it but rushed it out of the door. Also things like WinRM are totally unreliable and don't scale well due to the runtime performance being dire (try arguing with ansible/WinRM failures on a daily basis).

I think a lot of people using object pipelines miss the major point of designing test pipelines which is the first step is to make your pipeline easily parseable. So for example dates as unix dates, colon separated etc. Then you don't need to use regex and stuff. For that little bit of compromise first you end up with something which is several orders of magnitude faster than the UTF-16 and serialisation backed powershell pipelines. Try grepping a few gig of data with it :)

On your last point, you're lucky. This comes up a lot in corporate networks and proxies and occasionally randomly out of the blue.

> I think a lot of people using object pipelines miss the major point of designing test pipelines which is the first step is to make your pipeline easily parseable.

And if developers of UNIX tools actually did that then maybe object pipelines wouldn't be nearly as appealing as they are, but we don't live in that timeline.

I use jq a lot in bash. That's a good part of an object pipeline.

curl | jq | grep/awk | jq | curl

Yeah but ip, and ls, and cat /etc/somefile.conf, and pretty much anything asides from curl don't output structured data so you can't use jq on it.

That was just an example of a pipeline. jq can parse plain text easily with split/map as well.

Also:

ls -l

ip -o

I know about `ls -l` (and have for about 25 years now, thanks). You're still scraping.

Have you seen this comment from a Microsoft employee explaining why NTFS performance is so bad? It's pretty interesting and informative, but doesn't leave me with much hope that things will ever improve.

https://github.com/Microsoft/WSL/issues/873#issuecomment-425...

I use Windows for development at work (semi-voluntarily - our Windows support was getting neglected because most developers choose to use run macOS or Linux), and I've been getting pretty fed up with how slow it is. And it's not just filesystem performance; process creation and terminal output are horrendously slow as well.

The only redeeming thing about development on Windows is that Linux doesn't have any debuggers that are as good/usable as Visual Studio.

I’ve seen that and it misses the mark by a mile because the main performance constraint is MFT contention.

You can see this because the tools suck just as bad on native windows as on WSL without that in between.

Check out 10,000 small files on (1) NT native SVN, (2) WSL on Windows, (3) Linux on ext4.

1 and 2 are within 10% of the time delta. 3 is 10x faster at average.

At this point I reckon they won’t fix NT but close the gap on NT and forget to mention the MFT problem.

I’ve dealt with this issue going back 20 years since NT4 for ref.

Very interesting post - thanks for sharing it.

Filter drivers and IRPs really are the worst architectural blunder MS made in Windows. They took what really should be a corner-case (driver interposition) and put it on the development path of every hardware driver programmer to trip over. We got KMDF eventually, but that took years...

> 10x the latency on everything at least compared to Linux running natively on the same hardware.

The vast majority of my real world experience has not been that at all. Then I looked up the benchmarks

https://www.phoronix.com/scan.php?page=article&item=wsl-febr...

Also I use older Desktops and I have very quick experience running my scripts and Ranger. Having Ranger alone is HUGE for my workflow. Then I have awk, sed and grep at my finger tips?

Personally I would take Windows 10 WSL over any of my AppleOS experience. I really think the machines know I don't like Apple because for the past 25 years they always lockup, crash or over write what i do with them.

The file IO / compile benchmarks are realistic workloads. Look at: https://www.phoronix.com/scan.php?page=article&item=wsl-febr...

Also you can't interact with the WSL directory outside in a graphical text editor or File Explorer. There's going to be someone who responds to this saying it works for him, and I'm very happy for you. Every time I create a folder in the WSL directory in File Explorer it's permanently un-cd-able in WSL, and vice versa. Editing text files outside corrupts them. Yes, I've tried reinstalling.

WSL is just a shitty implemention on a shitty OS. Linux and OS X work perfectly and they have package managers and I can control updates.

Yeah - I generally touch files or create dirs in WSL first to get around it. Otherwise it is a cluster. If i could just use Linux @ work I'd be much happier.

The trick here is to not use any windows program to modify anything on the WSL file system (because of the unix permission system). But it works vice-versa ... so you can use any unix program to modify a file on the windows file system.

So my hack there is to simply make a symlink in my unix dir (`~/dev`, usually) that points to a folder on the windows file system ... that way I just do all my work in ~/dev and it's all good.

What’s the point then? Cygwin works better than this.

WSL works with unmodified Linux binaries, while you need to port/recompile everything for Cygwin.

I was simply communicating how to avoid this issue ... judgments of worth and value are a separate discussion.

Yes, you should have heeded the warnings against that. The article also mentions this in passing. You can get at Windows files from WSL, but don't do it the other way round.

you can get package managers on Windows as well, such as chocolatey or https://scoop.sh/

You hit the nail on the head with your description of Chocolatey.

I've found scoop to be a lot better (https://scoop.sh) for package management on Windows 10 than Chocolatey.

> WSL's backing filesystem (NTFS) completely runs like ass. It's dire. 10x the latency on everything at least compared to Linux running natively on the same hardware. This is because all small writes end up in MFT contention and the entire of Unixy type things are based on lots of small writes.

Does this matter? It seems good enough to me to use as a development environment to the extent that GNU/Linux and GNU/Windows are equal/or for development purposes.

10 years ago, on the exact same hardware, running a Rails application test suite in a Linux VM through VirtualBox was nearly 2x faster than running natively on the Windows side of things. This must be a combination of things, namely Ruby on Windows was super slow back then, but the filesystem impacted things as well.

10 years ago WSL didn't even exist.

Also, Ruby on Windows has always been an afterthought with a lot of dumb bugs, incomprehensible setup requirements, and terrible performance. Ruby is the biggest reason I use WSL today.

We have GitHub repositories with 10’s of thousands of files in so yes.

Nix runs way slower on Windows, since it caches by hashing all source code on each compile.

For me the main problem with NTFS is the file locking.

With Unix you can pretty much delete any file at any time (sudo ftw!) but not with WSL. Opening a file in an editor on the Windows side is often enough to lock things up.

(The case sensitivity is another sore point, but that can be averted by using only lowercase.)

That’s a very good point. The file locking semantics are different and totally incompatible.

Maybe it depends on other things besides WSL. I wonder if your system is mis-configured or has a weird combination of hardware.

For example I use WSL and it doesn't run like ass. All I did was disable the Windows Firewall and HD monitoring tools. Everything else is stock Windows 10 Pro (stable channel).

Here's some numbers.

NOTE: All of this is running in WSL, and to make matters "worse", it also includes running these things through Docker for Windows with WSL configured to communicate with Docker for Windows.

- A large Rails app (15k+ lines, 50+ gems, etc.) takes less than 100ms to pick up a code change with a Docker volume. I can see code changes before I'm able to even move my eyes to a browser to reload the page. It's awesome.

- Flask, Phoenix and Node apps also pick up code changes nearly instantly and the overall development experience is awesome. This is all through Docker as well.

- 100kb+ of SCSS running through a bunch of Webpack loaders compiles in less than 3 seconds in "watch" mode, without any type of caching. Slower than native Linux? Yes, probably, but it's not slow enough where it's an issue. There's a lot of low hanging fruit to optimize too. I didn't even try to make it faster because it doesn't have a negative effect on my daily development.

Long story short, combine WSL with a good terminal and Docker, and you have yourself a great development box. This is with ~$700 worth of computer parts on a 5 year old workstation, with an early generation SSD and I don't even keep my source code on the SSD (it's volume mounted into Docker with a spinning disk 1TB drive).

I can understand all of that. I'd also rather use OSX, but the new Macbook Pro's have such a garbage of a keyboard that I'd even rather use Windows and the slow WSL (though I use native linux myself).

I just bought a 2018 MacBook Air. The keyboard is different and could do with a little more travel but I don't have a problem with it really. It's better than the wobbly piece of crap on my 2013 MBP.

It's fine if you can live with it. I can only compare it to typing on an absolute hard surface and my hands get worn out fast from that. I hate it, I wish I didn't so I could use the otherwise ok hardware :)

Want to buy my MacBook Pro? ;)

You could consider one of the BSDs, if you want to go to the path of MacOS. I practically found them to be objectively pleasing once the machine is set up.

I've used FreeBSD since 2.0.5. It's what led me to MacOS X :)

Hasn't getting a compatible machine set up been one of the most difficult parts? I've never tried BSD outside of a FreeBSD VM for tinkering (though I'd like to) – has general HW compatibility improved?

I’ve never had a problem with it myself even on mid range kit (DL580 sized)

It seems to run best if you have all Intel for the CPU, networking and graphics, and your machine is at least a year or two old. I would assume Thinkpads are the best supported hardware.

It works great on Thinkpad X1 Carbon gen6.

that is hard to emphasize more than it is - doing C++ dev on WSL is complete garbage, lots of small write on compile, SLLLOOOOOOWWWWWWWW...

Oh hell that must be horrible. It’s bad enough compiling small things.

yeah. I tried switching to using my gaming desktop with WSL. I used an X server to run a terminal emulator that isn't terrible so I could get the best of Linux and Windows without having to reboot.

Add in zsh auto completion and then it all went to shit with the latency. Some commands could take MINUTES to complete.

> Like when I tell it to download something, I don't expect to have to futz with IE browser settings (WTF?!?!)

You Can use Power Shell Core. Which is way bettet, Cross Plat and does not need ie settings fiddling. I use it to script on cross Platform Tools mostly

Powershell core has telemetry. I won't entertain that risk.

This is covered in my original point.

Full disclaimer: I'm the PM for PowerShell Core.

I'm a huge privacy advocate, but telemetry doesn't have to be a dirty word. With PowerShell Core, we went through an RFC process to define our telemetry goals and implementation[1], we publish our data to a public dashboard[2], and all of the telemetry source code is out there in the open[3]. Our telemetry enables to help drive prioritization and decisions around platform/OS usage, and disabling it as simple as setting an environment variable[4].

If there are any other ways we could make our telemetry implementation more palatable without seriously reducing its usefulness, we're absolutely open to suggestions.

[1]: https://github.com/PowerShell/PowerShell-RFC/issues/50

[2]: https://aka.ms/psgithubbi

[3]: https://github.com/PowerShell/PowerShell/blob/master/src/Mic...

[4]: https://docs.microsoft.com/en-us/powershell/scripting/whats-...

"without seriously reducing its usefulness" -- can you describe more clearly what the usefulness is that you are attempting to retain, and why that is important to your customers?

Thanks for replying. If your remove it, it is palatable. Stop carrying the flag for something detrimental to the end user.

Firstly anything that ships data out of a secure environment is a risk regardless of your intentions. You don’t always get the code right (this has already happened in .net core), the surface area of your software is multiplied (everything that sends telemetry talks to different hosts) and finally it adds a huge amount of noise to logs and IDS systems which make them less effective.

To stop this it requires a large effort and costs a lot of money. This adds a lot of noise to audits, requires administrative effort to silence, means we may not be within compliance of various data protection directives.

For this we get no observable product improvements. Look at windows 10 for all the telemetry. It’s a pile of crap.

Telemetry is literally a guessing mechanism so you don’t have to listen to your users concerns. A cost cutting exercise. You closed connect and didn’t listen to your users then. You cut off partner support pretty heavily. Now you collect data and make a finger in the air guess.

Just no. Fix MSFT not us.

You're right. Telemetry doesn't have to be a dirty word.

Your colleagues have ensured it will be for the next decade, though, I'm afraid.

They're working on it: https://github.com/Microsoft/WSL/issues/1932

> here's a local support network for the hardware which is decent and doesn't involve me shipping it off to some third party and losing it for 2 weeks.

Small heads up, every serious hardware issue I've had with MacBook Pros involved them being shipped to a third party for a couple weeks. Sure, they might try a thing or two in the Apple Stores, but then it's shipped off. YMMV

They replaced the screen on mine in store. I think it depends on what tier of shop you’re in as some of them don’t have full service ability.

In my case they were massive flagship stores that Chat support suggested I go to with an appointment. Pretty sure it had to do with the complexity of the repair both times.

I had to exclude my Ubuntu WSL setup from Windows Defender. Processes like ‘apt’ we’re really slow because of it

Reply on news.ycombinator.com