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.
Not sure there is another solution though. OAuth and various cloud logins etc isn't, yet.
Uh, yeah, that's kinda my point. Outside of SV, pretty much every client is, and for this reason.
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.
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.
UNIX derived OSes tend to be relegated to the server room, accessed remotely and live on their own network.
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.
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)
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.
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.
The "good old" control panel doesn't even look categorized well.
Plus why do they have to have a microscopic return key on laptops?
(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.
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.
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.
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.
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)
Linux: not much better.
Everything sucks, they just suck in a variety of different flavors.
And don’t get me started on the upgrade process. Quicker and easier to drive to the store and buy a new machine.
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.
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.
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.
This is the bash I wrote to check their results were sorted properly on Linux:
diff <(cat output.txt) <(cat input.txt | sort -n)
cat input.txt | foreach-object { [Int] $_ } | sort-object | out-file -encoding ascii sorted.txt
diff (cat output.txt) (cat sorted.txt)
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.
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.
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.
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...
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
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.
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.
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.
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.
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 :)
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...
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.
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.
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
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.
UNIX shells are a poor imitation of it.
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)
the interactive REPL was introduced by Lisp around 1962 way before Lisp Machines, Smalltalk...
You surely could not display inline structured data and interact with it graphically on an IBM 704 teletype.
Unless you count BBC BASIC?
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 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...
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.
...and? Why is that a problem? It is an advantage that PowerShell can call on the CLR directly (including its C FFI).
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.
Consistency, trust over everything.
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.
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.
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.
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)
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12
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.
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.
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.
That telemetry should not be expected to improve the product 9/10 times.
> 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.
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.
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.
curl | jq | grep/awk | jq | curl
Also:
ls -l
ip -o
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.
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.
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...
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.
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.
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.
I've found scoop to be a lot better (https://scoop.sh) for package management on Windows 10 than Chocolatey.
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.
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.
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.)
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).
that is hard to emphasize more than it is - doing C++ dev on WSL is complete garbage, lots of small write on compile, SLLLOOOOOOWWWWWWWW...
Add in zsh auto completion and then it all went to shit with the latency. Some commands could take MINUTES to complete.
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
This is covered in my original point.
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-...
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.
Your colleagues have ensured it will be for the next decade, though, I'm afraid.
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
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.