From macOS to Windows and WSL
blog.questionable.services
blog.questionable.services
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.
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 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)
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
Unless you count BBC BASIC?
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.
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.
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.
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
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.
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.
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12
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...
> 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...
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 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)
UNIX derived OSes tend to be relegated to the server room, accessed remotely and live on their own network.
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.
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.
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.
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.
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)
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.
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.
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.
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.
Linux: not much better.
Everything sucks, they just suck in a variety of different flavors.
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.
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.
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've found scoop to be a lot better (https://scoop.sh) for package management on Windows 10 than Chocolatey.
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.
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).
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
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 is hard to emphasize more than it is - doing C++ dev on WSL is complete garbage, lots of small write on compile, SLLLOOOOOOWWWWWWWW...
I can't imagine what he means by that. All my Macs and Linux boxes (from a dozen of RPi-like ARM boxes, to laptops, to big Xeon server) and even the OpenIndiana and FreeBSD machines all work without much effort. A `yum update` here, a `pkg update` there and nothing ever breaks. It's actually boring compared to 2004 or so, but we end up getting used to actually working.
Also, I have found it easier to make reproducible environments everywhere in Unices. Nowadays, I just check out a git repo, run home-manager switch and all my software and configuration is there.
Personally, though, I've always preferred Firefox's (and old Opera's) about:config instead. It's far more flexible than Chrome's flags.
I think Windows frowned upon lots of small files for performance and locking reasons - if some app decides to hold the file hostage, you'll end up needing to restart the system to be able to save a new version.
https://books.google.com/books/about/Introducing_Microsoft_W...
I just remembered it after posting about digging for the network dialog and sure enough, network settings are right there, easily accessible.
Create a new folder and call it:
GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
The GUID is the important bit, you can replace 'GodMode' with anything, but it can't be blank.
shell:::{ED7BA470-8E54-465E-825C-99712043E01C}
in the run dialog or address bar of an explorer window.
GodMode is just a nickname it got from some power users it seems.
ncpa.cpl is the old network view, still very useful if i'm not in the cli :)
I've always had to live in both worlds, and they each have their fair share of pros and cons.
Mac isn't better in that department, though (when talking to Windows, at least).
Docker with ffmpeg has solved most of those issues now since you can basically have a custom toolchain totally isolated from your core operating system. So, it would likely work knowing what I know now (or with modern tools).
With an AMD or something else, maybe it's more powerful, and works fine to most appearances. But the colors start to be a little funny when the uptime gets in to the months. Or a kernel update changes whether it thinks the unused S-video port is live. Or other weird <1% issues.
That's true. For desktop work, just about any GPU is overkill. Even the kind of scientific visualization we used expensive SGI boxes for not so long ago can easily be done with the cheapest Chromebook. I'd love to be able to play with OpenCL (where a beefier GPU would be useful) and see how far my boxes can actually go, but I never get around to find a good excuse.
Here's a bug I've found in Intel GPU drivers on Windows 10: https://stackoverflow.com/q/43399487/126995
AFAIK not fixed to this day.
Your distro's fault. Never had such a problem with Arch but I remember I had it with Ubuntu, albeit so long ago I can't say it's still a problem.
I’m not just talking about the CLI experience, since WSL doesn’t bring you anything new there. It’s Ubuntu (by default), or whichever other distro you choose.
When it comes to desktop applications (both in breadth & quality), video/GPU drivers, and (if it wasn’t clear already!) my preferences for a desktop experience, Ubuntu 18.04, Debian with XFCE, Fedora + KDE, etc - just don’t do it for me.
And that’s OK, because what I prefer probably doesn’t do it for you.
My setup for the past year and a half has only been:
* xorg server * i3 tiling wm * rofi application launcher
that's all one really needs.
I gave up on having my desktop looking like a futuristic sci-fi movie UI and that brought me a lot of peace (and free time). ;-)
It’s absurd to remove these things, and have the community re-implement core desktop feature as Javascript plugins without even a stable API between major versions.
To do that, I need to scale to 2x in the Gnome settings, then scale down using xrandr, and I have to manually position the X offset the second monitor.
I can't remember the last time I had a video card driver or other real hardware issue.
Come to think of it I can't really remember the last time i've really had to do any kind of system manangment other than package updates.
Oh...wait...I had to fuck around in grub a couple months ago when I lost power during a kernel update. That was about a half hour fix though....
I've lost power while windows was in the middle of updating before and it nearly killed my windows system. It was a few hours of booting into safe mode, figuring out what wasn't installed properly, fucking with the registry and windows update, manually comparing and replacing.dll and system files before finally getting it back up and running properly.
I have actually also, unfortunately, spent a lot of time working with Windows Installer and Wix and that's a fine example if you ever get the experience to see eye gouging pain of the highest order.
Given the circuitous series of hoops the author goes through to get their WSL/Windows environment in something of a working configuration the above passage is kind of laughable.
I too depend on Lightroom, but I've had to break that hold and just this week have gone the other way to a full Linux desktop. Windows breaks so often it's not workable for me. And LR classic has been nothing but a buggy, slow, bloated mess for me. Even just little things like opening the app paints the window over all other UI elements and you can't click to bring another app to the front before clicking/focusing into LR. Let alone the slow loading, painfully slow image viewing and stupid stuff like hiding the mouse pointer after creating a new folder.
I intend to split RAW development and Digital Asset Management, which is what I should always have done, now that Lightroom is out of the way. RAWtherapee and Darktable to a great job (and I say that as a former pro photographer) for RAW development and easily enough for most pro work I did/do. The options for DAM are varied but even Digikam is pretty excellent for most things.
Having just spent a year with Windows (having run Linux previously) Linux is, amazingly, progressing towards 'just working' for me. Especially with Flatpaks/Snaps (though developers need to get a grip of understanding 'filesystem=home' vs 'filesystem=host' and how this effects usability vs sandboxing) as well as appimage. When they become available on Debian natively it'll be kind of awesome to run a stable desktop with latest selection of certain apps you might need.
It's true Nvidia support is bad. I did switch from Nvidia to AMD to make the move. Is that unreasonable to expect the user to do? Possibly. But doing that I get a hassle free 4k desktop, excellent stability (so far) and all the apps I need (so far).
Being back in a terminal 'proper' again on the desktop is just fantastic. Not having things update on their own with my say is even more fantastic. And the fact it's not eating 12GB of RAM running LR and a browser is the icing on the cake.
Meanwhile Darktable is a pathological mess. I really want to like it. They even offer a Mac binary on their download page. Unfortunately, it turns out that the only first class platform is Linux. None of the core devs actually use a Mac so bug reports languish and users are told to simply compile DT and fix the bugs themselves. I'm working up to compiling DT, but the instructions are all built around MacPorts which I ran away from years ago. Yes, I'm aware that DT is an open source project maintained by volunteers but sometimes I want higher level packages to just work without a fight.
If I want to import metadata from Lightroom I'm expected to export individual sidecar files and hack up a script to do the import (hint: this doesn't scale). The real deal breaker for me was that the latest version available on the DT site simply crashes for me while trying to import photos. But not every photo. I'm not particularly inclined to file a bug report because most Mac issues get put in the circular file.
Once I got past that I found the interface to be… interesting. Despite the superficial similarities to Lightroom, DT is wildly different in practice and not all that intuitive to me (e.g. applying presets from the lighttable vs darkroom modules — also seriously those names: darktable, lighttable, darkroom are all far too similar regardless of whether or not they're based on photography terms).
It's been a few years since I've tried RawTherapee but obviously that didn't stick either.
Thanks, I hadn't seen that before. Two things put me off though:
1.) Lightroom really has motivated me to find an open source replacement. I don't think I want to get locked into another proprietary solution.
2.) The landing page for Luminar 3 that I found was so full of marketing hyperbole that I choked. There was a ton of fluff IDGAF about (e.g. export to 500px, "foliage enhancer" filter, Apple photos extensions, soft glow, artificial intelligence filter) and some that just felt like easily misinterpreted stuff (e.g. details enhancer filter, workspaces, polarizing filter).
If there's a trial I may check it out, but I'd want to know more about the tech details. Adobe got a few things right that I doubt other proprietary solutions will. Making LR so extensible with Lua is huge (is the core written in Lua?), storing its catalog in a relatively easy to parse SQLite db as well makes it easy enough to interoperate. As much as I kvetch about migrating from LR to DT, I think writing a module to import the LR metadata seems like an ideal first attempt at hacking on DT project.
> I’ll keep this short: I still depend on Lightroom, writing tools (Notion, Evernote prior), a solid default desktop environment, first-party hardware support (be it a MacBook or Surface) & battery life, and most of all, my time. I respect those who’ve invested the time into maintaining & automating a full Linux environment they can use daily, but I just don’t have the time for that investment nor am I ready to make the trade-offs required for it. To each their own.
- Software support, no problem, I can understand. I still have a Windows partition for audio production.
- The "solid default desktop environment" is pretty much crap - both Gnome and KDE Plasma are far more solid DEs than Windows'.
- First-party support I can't figure out what he means by that...
- As for battery life, I have 10+ hours on my ZenBook running Arch. The battery life is actually better on Linux than on Windows on this laptop.
- Windows has been a much higher time-sink than Linux or macOS for me. Sure, an Arch or Gentoo desktop would be higher maintenance than your average distro, but come on, Fedora and Ubuntu are _super_ easy to install these days, and the overwhelming majority of the time just work out of the box. It's 0 maintenance. My maintenance/automation scripts were like 80% ported straight from my old macOS scripts.
I'm forced to use Windows on my work computer and it's IMHO terrible. Its virtual desktop feature are useless (really, switching desktops changes _all_ screens at once?), the shell is crap, WSL basically feels the same as running a VM and SSHing in, the DE is horrible.
You are not telling us anything better than the author, one way or another.
The WSL environment is very fast and reliable to the point where for the last year I've been 100% at peace with my dev environment. I would say in 20+ years of computing, this has been my favorite overall set up because you get a great dev set up, you can assemble your own computer part by part and you have excellent gaming support all without having to dual boot or run a Linux VM (which I did previously for ~5 years). I finally feel like I have 1 machine that does everything very well.
A typical dev day for me involves running Dockerized web apps (mostly Flask, Rails and Phoenix apps with Webpack, etc.), tons of terminal usage, Ansible, VMs, etc.. Everything you would expect to run as a developer.
If anyone is looking for a more step by step guide on how to get everything running, here's 2 posts I whipped up on getting everything you need installed on Windows[0] as well as getting Docker working flawlessly with WSL[1].
[0]: https://nickjanetakis.com/blog/using-wsl-and-mobaxterm-to-cr...
[1]: https://nickjanetakis.com/blog/setting-up-docker-for-windows...
Apart from the annoyance of the keyboard on the MBP and my personal preference for physical Fn keys over a touchbar, it is simply amazing to me how bad the Macbook Pro is with playing with simple external peripherals like Docks and external monitors. I've tried using a USB3 based dock, as well as a thunderbolt dock to connect 2 external displays to a Macbook Pro and it's just been horrible. The former didn't even work, the latter only supported one monitor for whatever reason. I then tried using 2 simply USB-C to HDMI adapters to connect to the two monitors (hello dongle land!) and while both monitors are seen, OSX refuses to support 1920x1200 on my new Dell 2415 Monitor and ends up stretching a lower resolution across the monitor, making everything look like garbage.
Occasionally, on reboots, it will work fine again, but it needs to be your lucky day. Why Apple won't make their own fucking dock so that I can pay them some extra Apple tax just for some sanity and peace of mind is beyond me. Meanwhile, my 2 year old Dell XPS (which I don't really love at all) has never had an issue with external monitors via any of these docks ever.
So here I am using WSL on Windows 10, and you know what, it keeps getting better and better, and I might just end up sticking around with Windows.
MacBook? Piss-poor keyboards and external device support.
XPS? Poor support.
ThinkPad? Windows 10.
<Laptop> with Linux? X software is not available.
It'd still be great if there was a solid windows-native alternative.
I love how seamlessly wsl works and gives you a real Linux environment. Writing on my screen (surface pro) is great too.
However, I'm mad that I'm getting ads (preinstalled Candy crush) on a Windows pro machine. Also, os x is much more privacy oriented overall, and it's the de facto developer machine.
The only reason I'm hesitating is that although osx is Unix, I'm scared I may miss a full Linux installation which you have with wsl.
However most of the built in packages and stuff that comes from brew is exactly the same as on Linux. Perhaps 99.999% of stuff is totally portable.
For me the BIG problem with macOS is actually the hardware. When Apple gets it right it's awesome, but this hasn't been the case for the last 5 or so years (with some exceptions).
The fact that there is no competition for macOS hardware ends up in very surreal situations such as overpriced broken products or design decisions that make absolutely no sense.
If I had to buy a new laptop now I'm not sure I'd buy an Apple product.
I was welcomed by candy crush tiles and other questionable stuff. It is totally incomprehensible to me how a machine that costs almost $2k has candy crush as the first tile the user ever sees. I don't think Microsoft cares anymore.
Even with their pitiful current hardware offerings that almost seem like a direct insult to long-term dedicated fans, I'm still locked into their excellent software.
I qualified my “yes” with the primary uses for my computer, which doesn’t include any macOS specific software (Sketch was the most recent).
If I was using FCPX, Logic or doing iOS development I wouldn’t have opened my editor to write the article ;)
It has it quirks and bugs, its performance is terrible on my 2013 MBP, but I just cannot find any other DAW that lets makes me feel as productive as Logic. Not just productive, it brought fun back to music production for me. Using FL Studio felt like a chore, even when I was quite experienced with it.
I've commented on the declining quality of Apple hardware and software, and switching to Windows 10 + WSL, several times on other posts.
Like OP, this isn't a perfect experience. It felt like it was a very balanced treatment of the issues.
There are still issues, for sure... but it's definitely passable, and improving. (At least for me.)
As far as the slow I/O performance, I believe the heart of this is Windows Defender live scanning the FS where each WSL environment resides. If you exclude those in Defender, you see a significant increase in I/O performance.
Side note: I wonder if Apple is observing this trend at all, and/or if they even care? They give lip service to the idea that they care about the Mac still... but the experience is still lackluster.
Until then... I think I'll just stick with Mac.
By comparison Wsltty is much simpler, but works like a charm, and t-mux with mouse support is so liberating to use.
Edit - Found the resources on ConEmu's site that mention the technical limitations
If it worked well and line output didn’t break under tmux I would absolutely use it [until Alacritty improves].
Docker on windows needs to not require Hyper-V but to run as a kernel process like WSL does. Also the volume mounting straight up doesn't work on windows and if they can resolve those issues then suddenly a lot of things open up.
I seem to recall trying it with Linux containers and immediately hitting permissions issues due to incompatibilities between Windows and Linux.
I am at least able to bind individual files using Docker Compose's 'secrets' and 'configs'.
Completely agree. If you're on Windows and still using ConEmu give Terminus a try.
I opened an issue for this 2 months ago[0] and the team hasn't responded yet.
I'm about ready to call it quits with Hyper (ConEmu has its own set of even worse bugs).
The problem with Terminus is it currently has no support for splitting windows, so if you want that behavior you would have to use tmux. Although now with Windows 18.03+ being out, tmux sessions persist after closing your terminal so maybe that's the best way to handle splitting windows.
Along with a bunch of other network socket stuff, such as many of the tools in Kali Linux, which they have published in the Windows Store. Nevermind that a significant chunk of Kali's tools do not work in WSL, at present.
Yes. It's a little bit slower but for development local environments it really does not matter.
I actually set this up for the Windows devs at work but I still use a 2014 MBP.
Our ionic app though is a huge pain in the ass that requires Visual Studio to setup a decent dev environment in native windows.