My preferred fix: don't develop in Docker.
the m2 chip :)
Mac has the best balance between coding, utility tools and "other work stuff".
Windows probably on par if not more for "work stuff" but falls badly in the coding & tooling department.
Linux is OK ish for coding and utility but falls behind for "other work stuff" and certainly a pain to just keep it updated.
So in our company, everyone in the development & support team uses Mac (except this one guy who insisted in Linux), most in the sales & marketing team use Windows.
> certainly a pain to just keep it updated.
> Linux and it's a lot of pain to setup.
If you're not using Linux, how are you justifying these claims?
> certainly a pain to just keep it updated.
Excluding the boot time for both, MacOS takes between 15 and 45min to update. Linux is a few seconds. I suspect that the only OS that has a more ridiculous update process than MacOS is Gentoo.
This is a thread on Hacker News, not an academic article. You aren’t owed a massive amount of “justification” for these “claims”.
I was using Mac for development due to company policy (compliance). It is by far the worst development experience I have ever had. Brew is terrible. Updates are agonizing. The user interface is awful. Containers are a shitshow.
Apple's completely vertical stack means that their machines never have issues sleeping. The huge variety of machines that Linux (and Windows) is expected to run on can cause problems entering S-states reliably. This issue is pretty uncommon (excluding the Windows modern sleep disaster), but that doesn't prevent comments like the GP throwaway.
There's a litany of bugs in Apple's software. This often gets hidden because developers use workarounds of various sorts, but if you know, you know. It's honestly embarrassing how buggy Apple software is given the vertical integration you describe.
The worst part is that almost all of it is closed source so it's harder to debug, and the bits that are open source (and have bugs in plain sight) you can't just submit a patch to. You have to file an rdar and hope it gets prioritized, which for one of the bugs I'm aware of hasn't been in many years. And so the workarounds keep getting written.
Personally, the only problems I've only ever had getting macos to sleep properly has been when I've been running VMs. (Hello docker!)
When doing purely OS-local development (which is all I ever do these days, because I value my sanity) macos works great. (So long as you have a recent mac. New macos + old laptop is awful.)
But as nice as macos is, XCode is an absolute mess. Earlier today I was trying to import a swift package into xcode. The package looked fine, but XCode for some reason was only importing it as a "Folder Reference". Stackoverflow suggested quitting xcode and running "xcodebuild -resolvePackageDependencies", then relaunching xcode. And that fixed it! Why was that necessary? Why couldn't xcode figure that out on its own? What did that even do?? I have no idea. And I hate it.
These days developing in apple's ecosystem feels less like developing in a walled garden and more like developing in a swamp. They're truly lovely developer machines - just so long as you can stay away from xcode.
Linux's bugs are things like the fact that every program has a slightly different set of keyboard shortcuts. Is copy Ctrl+C? Or Shift+Ctrl+C? Can I make it Meta+C (like on macos)? Not everywhere! Only some linux applications let you treat the meta- key as a modifier. (Eg intellij doesn't let you do that.)
Smooth scrolling (if you have hardware to support it) works in all native GTK applications. But not Firefox or IntelliJ. Normal mouse scrolling works everywhere, but scroll distance is wildly inconsistent between applications.
On macos I have homebrew. On linux I have apt. And snaps. And flatpak. But I think we're at war with snaps? I'm lost.
My bluetooth keyboard and mouse are both broken on linux. I'm not sure if the problem is my bluetooth chipset driver, or if the devices both have terrible implementations of bluetooth and they didn't bother testing on linux. Either way, I bet they both work fine on macos.
> Linux has its own issues but it overall is at a completely different quality level from macOS.
Its different alright. But its certainly not uniformly better.
The actual worst part is that it is impossible to draw a meaningful conclusion from a problem report like this one:
> Mine also shines from the holes when closed. M1 Air. Noticed happens when browser is open and i closed the lid.
Yeah, it shines from the holes. Also develops a halo. Sometimes two. Maybe three, dunno. Sometimes the laptop can see stars.
Yes, it can be indeed an OS related problem as it is not bug free. Or, it could be a faulty laptop specimen, or – most likely – the user has installed something on their laptop that meddles with the sleep routine activation. For instance, OS X has a power nap feature that allows the OS to wake up briefly from the slumber, quickly do something (e.g. check mail, syncronise messages etc) and go back into slumbering again. Any application can register with the operating system to be awaken during a power nap.
And this is where the problem occurs. Users install tons of jackshite on their laptops, and that stuff tends to run a myriad of pre- and postinstallation scripts that crap all over the file system, the launch service database, and install user and system wide agents and all sorts of other unthinkable things. Including adding themselves into the power nap wakeup list without having a real need for it. At best, the app can drain the battery, and it usually does. At worst, the app bundles an system level extension that is buggy and crashes the system when invoked. But oftentimes, such nonsense does not yield its slot in the power nap run queue easily, which meddles with the laptop going back into the sleep and results in all sorts of bizarre problems.
Enterprise software is the worst offender. Nearly every. single. one. enterprise app installs (or runs) untold amounts of crap all over the file system, and nearly each app comes nowadays with its own software update daemon that is forcibly installed into the launchd database and runs 24x7, including at the power nap time. Is there a need to run a update daemon 24x7 to check for updates multiple times a day instead adding a crontab entry to wake it up once a day? No. Is there a need to install a «helper» daemon that does nothing but phones home non-stop sending undisclosed, non-consentual telemetry (likely PII too and more)? Absolutely no.
Microsoft Office is a prime example of such an invasive pest with Citrix Workspace being one of the worst offenders I have encountered in a while. Pick apart installation bundles for either and take a look at their respective pre- and postinstall scripts. Faeces that both slap onto a working OS install have to be thoroughly scrubbed off after, and they can only be scrubbed off with a hardened spatula. I really wish all downloadable app installs could be sandboxed by default and contained to their sandboxes without being able to ever break out of them. APFS supports COW snapshots, so perhaps the installer could create a sandbox and give each a private copy of system configuration files and databases that only the app could crap into into an oblivion without having an effect on a wider system installation.*
What is a «vanilla system»? A brand new laptop? Then the hardware is likely faulty, and Apple will replace the faulty computing contraption or refund the purchase. A brand new install on an existing laptop? Likely a hardware fault, a compatibility problem (less likely) or, indeed, a specific or unspecified defect in the software.
I reboot my laptop approximately once a quarter – when a new update or upgrade is released. The average uptime is 3 months. I run a uninterrupted succession of OS X updates and upgrades dating back into 2009 – when I begrudgingly switched away from my Sony Vaio Z17 business laptop running Linux due to the X server randomly crashing on and bricking Vaio Z series laptops in-flight or upon an awake with no available recourse. I have not had to reinstall OS X from scratch even once and still occasionally come across non-OS files on the file system being intact since the original 2009 install. Different kernel versions in between 2009 and now have crashed on me less than ten times. The laptop goes to sleep and then wakes up daily. Zero maintenance. I used to have to reboot it once a year to disable the CSR mode, but not anymore – the stuff just works (except when I need to run dtrace / dtruss which is a less once in two years activity now). Clearly your vague definition «many bugs» does not apply to me.
I can't say the same about the said Vaio laptop that I still happen to have around, and that is in a perfect working condition (sans the obsolete 32-bit CPU and maxed out 4Gb of RAM). It runs a version of Ubuntu but every upgrade is still a gamble. A upgrade to Ubuntu 20 has bricked the laptop in the umpteenth time, and it now requires an autopsy and a full reinstall via booting it from an external eSATA drive via a PCI Express card attached to it.
Describing them in more detail will deanonymize me so I'm not going to do that.
This is a real issue with Linux. If you want the latest hardware, expect basic features like suspend resume not to work.
You can generally spot this immediately, even without reading the code, by the way it's described as a "workaround".
That being said, it happened on my m1 MacBook a few weeks ago - so seems like Apple is no better ;)
Assuming this is a real question and not just an excellent ruse; the answer, in terms of simplest setup would be
1) Install a vanilla default, such as Ubuntu 2) If that fails, buy a vanilla default laptop
To be fair a reason why this is easier on MacOS is they have like 3 laptop options rather than 3000. If your problem still persists, then there is a step 3
3) Become an expert in cli foo
After that fix, you're welcome to either pretend the cli foo was incredibly easy all along, or weep and dream of a gui with two glowing buttons [Cancel] [OK], providing all the configurability you might ever need
Sleep is one of those things that have always just worked for me, at least on Linux; in Windows, I've had to deal with random wakeups after some kind of Windows update. That said, with less than 30 seconds from off to IDE I don't tend to use sleep all that often.
There was one developer in our team using Mac. Everyone (>20 people) else were using Linux. Mac was a lot of pain to setup.
Linux is the best balance between coding, utility tools and "other work stuff".
Windows is not even considered for development, it falls badly in the coding & tooling department.
So in our company almost every dev uses Linux (except this one hipster using Mac) & marketing team use Windows
This is absolutely false. Windows is a perfectly fine development environment and has perfectly fine tooling. You just need to embrace powershell, windows tooling, and use cross platform tools. Too many devs put themselves in a corner by relying on posix shell or posix only tooling.
If you do user space programming your host OS should never matter. In my 10 years of programming the only time the host OS mattered was when I was writing Linux drivers.
That's more perception than reality, often from people who simply don't know how to use Windows.
Visual Studio, Visual Studio Code, and IntelliJ IDEA blow any Linux text editor out of the water for developer productivity.
For Linux workloads there is the Windows Subsystem for Linux (WSL 2), which now even supports GUIs with GPU acceleration!
Visual Studio Code can even operate in "remote" mode where it tunnels into a Docker container or Linux server and acts as-if the remote target was the local machine.
On Windows, x86 and x64 Linux Docker containers run in process isolation at full speed, unlike on Macs where there is CPU emulation required.
But those tools themselves work on Linux.
I’ve since migrated to Mac because I was spending too much time making linux work properly, but I do miss the control I had. I have Windows on parallels and I can’t believe how much of a disaster it’s become. I wouldn’t encourage anyone to it.
For most people migrating off of Windows, I’d recommend Kubuntu. It is KDE Ubuntu, and it feels like Windows used to during its golden age. Also, it’s free. All major IDEs work on Linux so the shift is pretty painless. Really recommend migrating.
By the way, for iOS I single step shaders using Metal tooling on XCode and Instruments, no need for Windows.
NVIDIA also has a multiplatform GPU debugging sdk. I’m sure if you look at extensions for whatever IDE you’re using, you’d find what you are looking for in under 5 minutes.
You’d be surprised how good all the tooling is now days. It also isn’t my tooling, it’s everyones. That is the key difference. With Linux, you aren’t the product. People work and maintain it for the betterment of mankind and for personal satisfaction / freedom. So people care, and they are passionate, and there is a very involved worldwide community. It is more than a paycheck to them.
We’re all in this together, and there are always new things to discover for our finite selves interfacing with an infinite pool of knowledge.
on linux, we spent no more than one hour.
those editors you mentioned are also available on linux nowadays.
if someone needs to test something on windows, there's "windows on aws" (i used it once)
If you're coding in Windows and deploying on Linux, it's not ideal. Sure there's WSL2 which kinda sorta helps for a lot of day-to-day stuff. But often weird errors creep in, my favorite being the MS-DOS EOL instead of the Unix EOL, which breaks Bash scripts, leading to developers saying: "But it worked fine in MSYS!"
https://github.com/VSCodium/vscodium/blob/master/DOCS.md#pro...
Typical Microsoft. Pretending to be FOSS but there's always some sneaky strings and telemetry attached.
Of all things in this comment this one is the funniest, because Emacs was able to do it for years (decades?).
The inability to get something akin to VT220 terminal access and shell scripts on a POSIX-based system without resorting to a virtual machine (a la WSL2) is a deal-breaker for me. The steps for using scripting languages (e.g. Node, Python, Ruby) is typically entirely different on Windows than it is from all other server and desktop platforms.
For those who can spend their time nearly 100% inside an Electron-based or Java-based IDE however, it matters a lot less whether that IDE is running Windows, MacOS or Linux.
> On Windows, x86 and x64 Linux Docker containers run in process isolation at full speed, unlike on Macs where there is CPU emulation required.
You do realize they didn't require us to all burn our old Intel-based Macintosh computers, right? Apple even still sells Intel-based Macs.
Windows requires emulation to run aarch64-based containers. Except on Windows for ARM of course, where presumably they run full speed but those x86/x64 containers above require CPU emulation.
You can run all of your favourite languages nearly identically to Linux on Windows either via Docker or WSL2.
> Windows requires emulation to run aarch64-based containers. Except on Windows for ARM
Making Windows and Linux the only platforms with ongoing support for both ARM and Intel CPUs, unlike MacOS where Intel support will eventually expire.
"WSL 2 ... uses the latest and greatest in virtualization technology run a Linux kernel inside of a lightweight utility virtual machine (VM)."
https://learn.microsoft.com/en-us/windows/wsl/compare-versio...
WSL1 is not a VM design, but that design reached its limits.
A VM doesn't make it bad - I don't do a lot with WSL but I like it a lot. It's not slow or limited.
I used to love Visual Studio but Jetbrains has caught up to it and then surpassed it years ago. I generally run IDEA and VSCode for code editing and going back to Visual Studio is a real shock, especially with the pleasant memories I've had of using it.
VSCode and IDEA run great on Linux, though, perhaps even better because Windows isn't great with tons of tiny files.
WSL2 is great if you prefer the Windows GUI. It fixed almost every issue I've had developing on Windows outside of Microsoft's data hunger and terrible UI design. Whatever Linux centric tool you can think of, it just runs on Windows now.
If I could use the comfortable and stable Windows 7 UI with the Windows 11 kernel, I'd actually consider going back to Windows. In terms of usability, Windows just lacks polish these days. That said, my attempts to try macOS didn't fare much better, I just couldn't get over the primitive window management and the bad integration with my home/end/page up/page down keys.
GPU debugging, DDK support, ETW debugging, SQL Server integration, GUI designers for Forms, WPF, UWP, MFC, mixed mode debugging across .NET languages and C++, COM/WinRT IDE tooling,IIS integration,...
Quite curious, I guess if we focus on US market, while disregarding game consoles and 80% of the desktop market.
But overall it's actually worked out surprisingly well because there's something for everyone - developers get *Nix On The Desktop but with an actual support story, and the non-technical users get a happy bubble OS that holds their hand.
Linux code churn and distro fragmentation makes it fundamentally unsupportable in the vast majority of workplaces (outside very controlled server environments/etc - talking desktop use here) and for the vast majority of users. The code churn makes the support story (polish and documentation) impossible and the distro fragmentation means that there's 50 different solutions to the same problem. The Bazaar and the Cathedral doesn't mean the bazaar is better in all situations, a random non-technical business analyst is never going to learn how to build Arch or install Gentoo and a really good streamlined, polished Cathedral Experience is much more suitable to the business environment. That's the fundamental lesson from Linux and Windows and OSX now takes its place in that too. You can keep the good things about Unix-y environments and opt out of the terrible parts of the Linux ecosystem.
Unfortunately, like BSDs, that's not what Docker is built around. Docker assumes a Linux kernel, and Linux kernel ABI is not the same as Unix kernel ABI. That's the biggest problem. Same as FreeBSD Jails or Solaris Zones... they're a decade ahead of docker in terms of capability, security, performance, and polish, but Docker is where the mindshare is. I can't install a jail from a registry with a single command and that's not where the support/development time is going even for the people who have engineered those alternative docker-registry solutions for jails.
The only "fast" option for non-linux kernels besides full virtualization is to thunk the calls to your own kernel to patch around the differences. Obviously that didn't work out with the Windows kernel, it's just too different, but FreeBSD/Solaris have implemented this functionality for a long time as part of "Branded Zones". But everyone is enthusiastically rebuilding the wheel around ubuntu (specifically - not even linux generally) so that's not going to happen.
https://wiki.freebsd.org/LinuxJails
https://docs.freebsd.org/en/books/handbook/jails/
(the freebsd handbook is a great example of the kinds of documentation that rarely gets written for linux distros - other than commercial ones - because of the overwhelming code churn and the inevitable bit-rot that entails in the rest of the user experience. It's way more fun to write a new audio pipeline or init system than to document it fully, everyone knows it.)
https://www.oracle.com/technical-resources/articles/it-infra...
https://docs.oracle.com/cd/E19455-01/817-1592/gchhy/index.ht...
https://en.wikipedia.org/wiki/Solaris_Containers#Branded_zon...
(and note the Solaris stuff almost entirely applies to OpenSolaris/Illumos as well, you don't have to use commercial solaris to get Branded Zones.)
Anyway, apropos of nothing, but with the newfound attention on OS X from developers and power-users, it'd be really nice if Apple released a M1/M2-based "toughbook". Completely against their design aesthetic but I think a lot of people don't really like the idea of wafer-thin apple laptops and would like something that can take some bumps without shattering. Power users are becoming a more core demographic for macbooks and it'd be nice to see them cater a little more.
Linux is not a pain to setup.
WSL 2 is a game changer because it makes all the Linux centric dev tools available to Windows without setting up virtual machines or other such nonsense, even running graphical applications these days. The only major pain point I've run into (that isn't "I prefer Linux") is the lack of IPv6 support within WSL 2.
If you avoid buying Nvidia hardware, Linux generally "just works", unless you use Windows-only software (which macOS also suffers from) or choose to make your life harder by installing Arch or Gentoo. Ubuntu's snap is a pain for power users who want to hack on their Linux system but if all you want to do is develop or do work stuff, it just works out of the box.
Given the option, I rather spend my day on VS than XCode, and C#/F#/C++ than Swift/Objective-C, but to each their own I guess.
And then there is the whole thing about where macOS Server end up.
That maybe used to be true. But today, Windows is that OS. In one OS, I can freely develop in Windows, Docker, WSL2, including near seamless integration of apps, browsers, and even GUIs. And with VS Code, I basically have any OS except macOS (but who cares?) at my fingertips in a single interface. The dev experience is by far the lowest friction between Windows and macOS.
And Windows has superior support for external hardware. macOS refuses to work well with anything that doesn't have Apple on the box.
I am a .net developer and run Debian linux on my work laptop since ages. Keeping the OS and most of the software up-to-date is just "apt-get update; apt-get dist-upgrade". Microsoft has Debian packages for teams, skype, powershell-core, .net (core), azure-cli. Google has Debian packages for chrome. I use a lot of JetBrains' tools and keep those up-to-date using the JetBrains ToolBox. Where I work, we use Google workspace and Slack and I use those through chrome.
Just to be clear, most of my development is currently done on Linux using Rider, but I do have a Windows VM (on KVM) for older projects that run on .NET full.
The issues I come across, are related to our customers. For example when I am on location and need to connect to external hardware. One example is to connect wirelessly to a WiFi Direct display: this does not work for me and I did not investigate if there are drivers available or not. Another example is DisplayLink to use an external display through a dock: this I checked and there are drivers available and I did have it working at some point, but it broke after a kernel upgrade and it's too much bother to fix it again. Also for some customers we can connect remotely to their systems over VPN, but not all VPN solutions are available (or work out of the box) on Linux.
In any case, for my day-to-day work, I don't have any issues at all on Linux and I believe it's very very capable for coding, tooling and other work stuff. I definitely prefer it above Windows and Mac.
- backend (docker) - needs linux based machine - client app (iOS) - needs xcode on macOS
both are in one repository.
I do miss my thinkpad and Fedora.
Maybe I wasn't doing it right, but switching to Docker to sequester my projects and their dependencies has saved me so much time and hassle, especially with the amount of repos I work on throughout the year.
My biggest weakness today is that I still don't reach for Docker right away when starting work on a new project or when evaluating a new tool. Old habits…
but it has really hit me recently how so many “indispensable” projects are just something that’s existed for decades re-written at a higher abstraction-level with a nicer UX.
I wish I had more classic Unix sysadmin experience. But unfortunately the gains are real, and I can’t justify investing time into learning the older tech (let’s say, using chroot instead of docker), when the newer is so much faster to learn, and has (comparative to modern hardware) such small overhead (if you’re not on MacOS :P)
I am excited about the rust-rewrite movement for shell though - precisely because it’s a chance to bring all the ux lessons we’ve learned in the last decades to cli-tools.
Stuff like charm.sh is super exciting.
The only headache I get sometimes is because I have the GNU utils first in the path which makes compilation scripts mad sometimes.
I do often find myself wondering whether Docker saved developers or system administrators any time. Is Docker really better than building an AMI and provisioning EC2 instances on-demand?
With a docker compose file in place, all I need to do is run "docker-compose" and everything is up and running.
It's such an upgrade over what we had before.