Why I stuck with Windows for 6 years while developing Discourse
samsaffron.com
samsaffron.com
Also you are a hero because you catch and fix production problems nobody else sees or understands because production is running linux.
If you have a problem on OSX you just get 500 people telling you to reset your pram, and really you just need to wait for the next osx update. You certainly can't rollback an osx update. Nobody knows whats wrong because nobody has access to the code. Even if you did - each update is millions of lines of code. It is crazy town.
Same for windows except there is not pram to reset. You just reboot until the next update I guess.
Nice April fools.
To be fair it could be due to the general buggy-ness of the TB16 Thunderbolt dock.
There are notable fit and finish issues with other distros, but from what I've seen the Debian package maintainers consistently make decisions to protect the package archive from breakage, whether that be holding back a FreeCiv point release over a buggy UI element, or stripping out non-free parts of Chromium that upstream bundles.
Yes, there's still the 1-2% of roughness around the edges, but as OP pointed out, on linux you can actually fix stuff. It is definitely not an "april fools" worthy statement. Linux is really stable these days.
I swear, every problem I've Googled, then subsequently ended up on SO or a github issues thread, someone has suggested "raise the open file count limit"; its like the the default "try this and then come back" answer.
This is definitely true, and even Apple support can't really help you. It seems like they're only trained to troubleshoot the most basic stuff, and won't even do that if you have any "third party software" installed that they can blame.
However, if you try really hard and are lucky, you can sometimes downgrade. I recently had an awful freezing issue with a 2018 MBP that shipped with Sierra and persisted past a logic board replacement. I was eventually able to solve the issue by downgrading to High Sierra, but wasted a huge amount of time blindly troubleshooting and trying to figure out a downgrade procedure that worked.
Apple really needs to invest more in rigorous QA if it wants to continue down the path it's seems to want to follow.
Say what you will about Microsoft--the MSDN forums and technical articles have some meat on the bone. People who actually understand, and are paid to understand at a deep level, DCOM, the registry, or whatever, they are out there. You've got the MVP program, super built-out partner channels, etc.
With Apple, my distinct impression is that there do exist people who understand MacOS deeply, but they have zero interest in participating in the support communities, due to the way those communities appear to be built and (not) prioritized by Apple Inc. If there's anything even a little bit like the MS partner network, well, I'll be... really surprised. So all you get is duffers and superstitious folk, and the feedback loop intensifies the problem.
Problems with your mouse not working? No doubt somebody will suggest adding a random PPA, purging your kernel, and installing one from two years ago.
Your webserver can't write to htdocs/temp? No problem "chmod -R 777" will fix that.
It doesn't help that if you post any kind of technical instruction or information to the Apple site that doesn't involve a "Go to system preferences and uncheck this box", Apple will delete under the reason "this coiuld amage another users Mac"
Those usually have useful information, even if that information is simply that it's a hardware issue that cannot be resolved by you.
It's a simple checkbox if that checkbox exists. But that's true on Linux as well.
If it doesn't exist, with macOS at best there is an obscure plist file you can edit and at worst it's hard-coded in some binary you don't have the source for. With Windows it will almost always have some registry setting controlling it, but you can't plausibly claim that to be the user-friendly option.
Moreover, "install a different desktop environment" sounds like a big deal until you realize that is just a checkbox in the package manager.
Now, random, "Why did my mac start/stop doing x", I'll give you that. Especially on a site like Macrumors forums or Apple's useless support site.
So much this. I used windows for a lot longer than i've used linux. Maybe 10 years using linux exclusively now and 15 years or so with windows before that.
Even now when I fix problems on windows I feel like a wizard tinkering with vaguely mysterious arcane things i'm only mostly sure of the purpose behind.
When I fix things on linux I feel like a mechanic working with a detailed manual and diagram of my system isolating known things and fixing that one a few things I know for sure could be the problem.
For me though, it was when windows corrupted the master boot record on my hard drive. I ended up running linux partitioned across 4 16GB USB sticks I had lying around my house until I bought a new hard drive(I tried for a while to fix my hard drive, nothing I did worked. I'm not actually too sure what was wrong with it in the end.). The fact that not only could I do that, but it was easy and I could see and access everything on my hard drive still. It also ran faster than my windows install had. It was a revelation.
Ever since then i've kind of pictured windows as a massive parasite feeding off your computer, controlling it from within, while you're kinda there from the outside.
The article says that you pay a "VM tax" by running in a Linux VM in Windows or by using WSL, but by using Linux directly you end up "paying" in other areas, for example in terms of less-than-perfect drivers (which leads to problems such as worse battery life, worse graphical performance etc). In an ideal world, laptop and GPU makers would put as much effort developing Linux drivers as they do when they create Windows drivers, but unfortunately this is not the case.
Another point is that, even if you are running Linux on your dev machine, it is often challenging to have a local environment that is as close as possible to your production one; for example where I work we have Ubuntu 16.04, Ubuntu 18.04 and CentOS (and with various combinations of installed packages), even if I was using a Linux laptop, I would still need containers to get all the different environments right. The only case where you could use no containers at all is if you had all of your servers running the exactly the same environment.
Finally there is the issue of some pieces of software not being available for Linux, 95% of the times you can find a Linux equivalent that works for you but, in my experience, there were still rare cases where I had to resort to Wine or some Win VM just to run some specific tool that was needed to do my job.
PS My job, at the time I was using Linux as my main desktop OS, and during the couple of years after I switched back to Windows, was about PHP, Python and Java web apps deployed on Linux servers, so my comments above should be taken in this context. Maybe in other fields of software development there are different factors to take into account.
PPS I have also tried MacOS, on the one hand it's great that Mac is UNIX, but on the other hand it's not Linux so, if you want to closely replicate your production Linux environment, you will still need VMs or containers.
With web development its so trivial to do everything you need on linux and almost all of the time its easier to set up on linux or mac than on windows.
Panic Transmit on MacOS, or just use openssh.
You'll know it is worthwhile when you're able to comfortably debug production problems by hopping on the server and looking at all layers of the stack, or when you make quality of life improvements for your team with a quick shell script.
This is not the case on Windows and MacOS where there is a significant cost.
That 8 minute spec run, also takes 8 minutes in docker.
https://meta.discourse.org/t/beginners-guide-to-install-disc...
1. is the VM 2. is handling filesystem mounts across operating systems
(2) can be debilitating in dev environments on Mac for example where you want to edit files outside the container but have the container have access to them. Docker have done a lot to improve this over the years but it is still very painful.
Just use overlayfs and your performance issues are history. Works perfectly on Ubuntu 16.04 and I hope nobody needs to use significantly older systems.
Hah, good one.
Most things are running basically the same when using containers, but not everything. Take networking as an example: That's usually not working as it would on bare metal and usually result in a significant performance loss.
I've run 100,000+ line Rails apps in WSL (well technically through Docker, which I connect to through WSL) and I never noticed a slowdown that was bad enough to make me think "this sucks". It's always been pretty good. I run all sorts of Rails, Flask, Phoenix and Webpack driven apps and all of them run fast enough where I don't think twice about it.
Personally, I find the WSL set up somewhat close to native Linux in terms of the user experience. I'm not talking about I/O performance, but I mean how it feels to use the OS in general.
For example:
I spend 99% of my time in a WSL terminal using tmux + terminal Vim + ranger. So that takes care of coding and managing files.
Then I use a browser and other graphical apps (image / video editors) that run directly in Windows.
Dexpot sets up virtual screens with key binds that are comparable to how i3wm lets you switch and move windows to another screen.
Keypirinha lets you launch apps with a fuzzy finder (like dmenu but better IMO)
AutoHotkey lets you easily manage global hotkeys (just like i3 does) and more
When you put all of that together, you get a really really good development experience that also doubles for gaming and running programs that don't have a good alternative on Linux (such as Camtasia on Windows).
Then for the icing on the cake, since you're running Ubuntu 18.04 in WSL, you can provision WSL itself with the same exact configuration management scripts you would use to provision a production box. For me specifically I run all of the same Ansible roles against WSL that I do in production. I can set the whole thing up with 1 Ansible command. Plus my dotfiles also happen to work exactly how they do on my native Linux laptop so it's easy to keep things in sync and feeling the same.
This all runs from a i5 3.2ghz / 16GB of RAM / SSD / etc. $750 desktop built 5 years ago.
Even if Apple tax didn't exist I would still use this Windows / WSL set up if I weren't in a position where I could run Linux natively.
AKA, VMs are slower than bare metal. News at 10.
Sure there are things windows tends to be slower at, but similarly there are things linux tends to be slower at. For general desktop usage I think you will find two things, windows does quite well, and desktop level virtualization tends to be slower than server virtualization because most desktop users will be using a virtio/emulation IO access method vs servers which tend to be punching PCIe adapters into the VMs. Either way, the overhead of additional translation layers and VM exits for various things is always going to be worse than just running on bare metal. Wether that works out to barely noticeable for compute heavy benchmarks that are TLB friendly, 2x for small packet edge case IO's, or somewhere in between is completely application dependent.
The news is not the it is slower, it is how much slower it is. I found the number surprising given the prevailing wisdom out there was ... sure its slower, about 5-10% slower.
The other news is that mac is slower and it does not do any virtualising.
Much less to something like KVM with paravirtualization drivers, or even Hyper-V likewise.
The other interesting part of the benchmark is the i7-8559U (Coffee Lake, 4C8T, 2.7GHz) macOS vs i7-8750H (Coffee Lake, 6C12T, 2.2GHz) Ubuntu, on a single-threaded benchmark ("We are going to adopt parallel testing for our dev environments this year").
MacOS took 1.6x as long as Ubuntu, despite a 1.2x GHz advantage, for an overall 1.9x slowdown core-per-core on the same microarchitecture.
Would you like 2x performance? Just replace macOS with Ubuntu.
"There is no other operating system out there that competes against us at this time" - Greg Kroah-Hartman, 2018
I wrote about this in the context of Lenovo X1C laptop here:
http://amontalenti.com/2017/09/01/lenovo-linux
I also recently built a Linux desktop from ~$950 of commodity parts (including a pair of free GPUs a crypto friend donated to me after his startup died). I use it as a devserver and a GPU rig for playing with CUDA, PyTorch, and TensorFlow.
Aside from the requirement of proprietary Nvidia drivers, this whole box works perfectly in Linux too, is blazing fast, and operates silently and with low power consumption. (The case itself is bulky, but it’s stationary.) I think an equivalent Mac would cost a 2-3x multiple and run less well for developer workloads.
https://pcpartpicker.com/user/amontalenti/saved/r4rLJx
Say what you will about Linux, but if you choose your hardware carefully, it truly does “just work” these days. And you can’t beat having access to scriptable everything and source code everywhere. That said, I keep a Mac Mini around because there is some proprietary stuff you can’t avoid in the Apple ecosystem (e.g. XCode for iOS, Safari Debugger, Keynote/Pages, ...)
In my experience any multi-minute operation invites a context switch or coffee break, and end up being roughly equivalent in practice.
We use a tool called `rake autospec` at Discourse which is a smart test runner. I personally like the vim integration we built.
The way it works...
1. Run `bin/rake autospec` in a terminal 2. I head to the code I want to change, I change the code 3. The spec runner figures out what the right test is run and runs that. 4. While it is busy running specs at any time it can be interrupted by saving a "*.spec" file in which case the spec runner will run the spec at the cursor
This has worked wonderfully well for us.
1. just
2. like
3. this
There's too much fiddling around to get it working right as a desktop. Audio has always been a ghetto. Wifi drivers are still binary blobs. Fonts, hidpi, multi monitor support, wayland, systemd are all still issues today. I really don't want my development machine to match production. Production is a stripped down image for a reason. I spend far more time writing code than running it, so the VM performance hit is a moot point.
To be fair, Windows 10 has plenty of issues of its own that need tweaking, like having the only way to disable cortana is through group policy edits. And then they reenable it on the next update, and give me some candy crush ads in my start menu. It's pretty infuriating, but still less so than manually fixing wifi drivers through USB boot drives.
The best part is the performance and a realistic bare metal environment. You can profile code and actually trust the results. You can't say the same for virtualizarion, containers or other platforms.
"I was paying a pretty high tax for deciding to stick with Windows” was likely "I was paying a pretty high tax for deciding to use a VM”.
I have little love for Windows, but I would prefer to see numbers that place the blame correctly.
But I also use an Ubuntu guest VM for development so that I can shove the guest onto a different machine easily (yeah, I know I should use continuous integration, but I haven't yet).
Using a VM definitely has a big performance cost... Even though I value the benefits I accept the costs.
But I know that in X years time I can move a copy of my development VM to run as a guest on any OS I might happen to use.
I haven't yet spent any time learning how to use containers, or what their compromises are, so for the moment I am still ignorant of that solution.
The tax is due to lack of the converse in Windows just yet.
I think this is the point, given you can get an inexpensive desktop CPU with 6 cores and 12 threads, it wouldn't matter so much if you had a 20% perf tax with WSL when you have approx 12x the throughput.
You could always offload full test suites to an external CI box upon check-in and work with a subset of unit tests locally, once the suite becomes prohibitive for a single machine.
It's much better than it was in the PowerPC days, when (IMO) OS X was almost too slow to be usable. We have it good these days with faster graphics and 12-core CPU's and super fast SSD's...
But you give these same advantages to Windows/Linux and OS X is just handily beaten in just about every benchmark you can think of.
Also, I get it that some kinds of testing “feel better” when done locally, but... why not have those run on a cloud VM?
Still, AFAIK VirtualBox has a problem with supporting multiple cores. Single core VM is heavily handicapped even for Ruby. Parallel testing was not in Rails but it's definitely a thing.
Sounds alot simpler than letting everyone use their own environment..
You can use Windows, but none of the rest of us do so you're on your own.
You can have a MBP, iMac, or ThinkPad with Linux when you start. Your choice.
We had two developers actually say they were wary of learning Mac/Linux and didn't take the job for that reason.
Surely someone, somewhere has explained that Windows runs faster in a VM than on bare metal, because Linux is better at file systems and buffer management? Or that relying on drivers from all over makes your system less reliable than the fixed set used in the VM?
Me, I cannot imagine running MSWindows on bare metal. It just feels wrong.
When I started running the spec suite in WSL, defender went way up (so I gave it a break), pretty sure stuff would have been way worse with defender on.
The prevailing recommendation though from the WSL team is to leave defender on for now. So I kind of cheated by disabling it.
No need to wait for Rails 6 to get this boost
Edit: It helps that I use vim as my editor.
It does kind of suck in some ways though. I can’t develop without internet, and debugging is worse than debugging locally. The debugging issue could probably be alleviated with some more investment in developer tooling/editor integrations.
Since linux became the OS of the internet, people have been able to run the same software on their own computer. It's more convenient to just run the "server software" on your own machine and you have full control over it.
You shouldn't shoot yourself in the foot because you can - it doesn't seem particularly convenient to wait > 10 minutes for tests because the laptop CPU is overheating when a proper development server would be twice as fast even with (clumsy) single-core tests.
Getting stuff right is not easy, very few forum software platforms out there for example have a bug bounty like (https://hackerone.com/discourse ), last thing you want to do is deploy an XSS hive out there to the public.
As far as I know there is no small-medium well supported Discourse alternative written in Go. There is a Slack alternative though written in Go called mattermost which I can recommend.
(Disclosure: I did a few small contributions to Discourse a few months ago, but never got more deeply involved than that.)
I'm not a web developer (I develop mostly firmware) so I'm not into all this kind of stuff, but I know it is written in Ruby and runs in a Docker container.
It requires at least 10GB just to be able to install and 20GB just to update once in a while. It takes ages to compile. It's a PITA to update. Plus docker gets stuck with old images (not sure it's the right term) and you'll have to manually clear them.
20GB!! It's a freakin' forum software!!! Some triple A games are around 8GB.
I'm glad someone is asking for alternatives. I think all this overhead is because maybe redistributing a Ruby website it's a PITA and requires a full environment installation. And hell yeah I believe a simple test suite can take 10 minutes to run in that poorly conceived environment.
May be something could be done to the base image.
Or just try running ./launcher cleanup
I've found that I'm not alone: https://meta.discourse.org/search?q=disk%20space
There are entire pages of users complaining about the same or related problems.
At the end of the day, it's (almost) free... so what are we complaining for?
The haters he’s replying to are literally splitting hairs.
Wow, they shave off 3 mins to run an interpreted language test suite. This is the ABSOLUTE state of the industry right now.
Docker isn't a VM; it runs with the same kernel and directly on the host processor like any application.
In the case of Ruby maybe you should mount also the language manager directory with all the gems and the interpreter.