From macOS to Arch Linux | Hacker News Reader

From macOS to Arch Linux

juxt.pro

147 pointsjoelittlejohn246 comments

"There are still many things I need to set up on the new laptop, for example: suspension/hibernation on closing the lid doesn’t always work"

For me, this is one of those things that should work out of the box. I appreciate Arch is one of those distros you configure manually, and can thus choose whether to implement this or not. But I'd rather not have my laptop burn out in my bag because the system didn't suspend properly.

I'm sure everyone has experience of this happening on any distro, and probably even on Windows and MacOS. But it should at least try out of the box in my mind.

FWIW I've had this work out of the box for several years. Could be a case-by-case thing, but I've only ever had to configure it to my preferences rather than surprise-discover that it didn't work.

I tried Manjaro the other day and had to try 3 kernel versions before I found one that woke from sleep without crashing, the display wouldn't hold its resolution through display sleep, bluetooth wouldn't connect without writing a custom config file, and CUPS auto-detected the wrong drivers.

I went back to Ubuntu and it all Just Worked.

My conclusion: yeah, the Debian stale package problem sucks, but it doesn't suck as badly as the rolling release instability problem.

I had several issues with waking from sleep on Ubuntu based distros as well, and had to wait ages for updates that would fix it. It’s not all green on the other side!

Me too, but that was 15 years ago. Manjaro was a trip back to the Bad Old Days.

I'm sure we're deep in YMMV territory, but I gave Manjaro a spin based on the recent hype wave so whenever I see an echo of that wave I feel obliged to share my experience. Shrug.

Even with a fresh install of Windows 10 or 11, a recent laptop has chances to burn out in your bag because of the "modern suspend" feature, a.k.a. S0ix state.

True fact: proper sleep/wake on lid close is probably 40% of why I switched from Windows to Mac in about 1999 -- and that was when the Mac was on OS 9, not the BSD-based OSX.

I can't imagine going to a system where it wouldn't work. That's baseline, out of the box functionality for me.

I thought this was a dealbreaker until I installed an SSD in my laptop in the mid to late 00s. When my machine is fully graphical in less than 5 seconds, I just didn't care. My browser restored tabs, my editor restored everything, my desktop restored windows. It was a complete non-issue as long as the machine could cold-boot quickly. As an upside, my machine also no longer overheated if I forgot to long press the power off prior to putting it in my backpack.

I configured my current laptop to screen off on lid close and to shutdown after 5 minutes. I'm probably just weird.

Maybe weird, but not alone - I have a couple of Ubuntu laptops (with SSDs) and I generally just shut them all the way down and boot back up if I am taking them anywhere / not using them for a while.

Have also had a cooked laptop in the past (in my case it was a Mac). A few years later when using a Linux laptop I decided to disabled sleep entirely but left hibernation available instead [1]. This means that desktop environments will not show the sleep option at all, instead they will just show the hibernation option. Also I have the laptop set to automatically hibernate if it is running on battery power and the lid gets closed. Have also configured it to ignore any lid open events therefore it will only wake when the power button gets pressed. Waking from hibernation isn't quite as quick as from sleep but its not that bad and I've never had a cooked laptop again!

[1] https://www.tecmint.com/disable-suspend-and-hibernation-in-l...

The "proper" lid close gave us the image of engineers walking around the office with the screen slightly propped open to keep their Macs from going to sleep.

Yeah I know that there are ways around it but apparently it was too much to figure out for most.

I press the resume/suspensd button on my laptop. I explicitly disabled the suspend and resume on lid close. Maybe I suspend and don't close the lid (hot machine after something CPU intensive) or maybe I fail to fully close it? A button is safer.

Your comment made me realize that I've unintentionally adapted my behaviour to do the same thing.

I press the power button, and wait for the power LED to turn off before I close the lid.

Had a laptop stay on twice in a bag... never again.

I learned this the hard way.

When i was around 16, i was gifted a laptop. Mind you, this was my first pc ever. Before that i was going to internet cafes.

So being the good "hacker" i was at the time, i installed Ubuntu to be like the cool kids. Few days later the motherboard got fried in my backpack. Apparently, the laptop didn't go to sleep when i closed the lid and overheated.

Still hurts.

To be fair this happens with my work macbook every now and then. It hasn't died though.

My Windows work laptop has done this a couple times. Hasn't managed to actually kill itself yet, though. A pity.

And every time this comes up I need to clarify that if it worked out of the box I'd need to switch it off because I hate that behaviour, I only want it to sleep when I give an explicit command. And I've heard that from more people, but I guess we are the minority.

I have been running Arch since about 2008. This used to be a problem with laptops, but I have had great experiences with this exact problem since about 2012. Or maybe I got better at buying laptops with largely compatible hardware.

So far I rarely have issues with suspend/resume on Linux with laptops. My current laptops are a Thinkpad T14s Gen 1 and a Thinkpad P51, and they sleep and resume properly every time. Desktops as well: I’ve got a Ryzen 5950X+RX590 setup, works exactly as intended. Previous desktop too, and the one before that.

Granted… it could just be luck. I accept that. But, for me, I’ve never specifically sought out linux compatible parts and sleep/resume has not been an issue for a long time for me.

I tend to just run the later stable kernels, which might help a bit. Though Arch should give you basically this by default, so, I dunno.

The default config of systemd on Arch suspends to RAM when the lid switch of a laptop is triggered. Unfortunately many modern laptops no longer implement the S3 sleep state in favor of Microsoft's proprietary "Connected Standby" (i.e. the mode that tends to cook laptops in their bags). My new Thinkpad has a toggle in the EFI to re-enable S3, after which suspend to RAM works on Arch with no further configuration necessary.

Do you have any further information about the issue with Connected Standby? It’s one of my favorite features on my Surface.

This was discussed on hn a while ago: https://news.ycombinator.com/item?id=28639952

My old surface also never stayed in suspend reliably.

Thanks!

That's because of the garbage S0 sleep state enforced by the UEFI/BIOS of the laptop

tl;dr: There's a way to disable Windows 10's "Cook your Laptop" facility, Microsoft calls it "Modern Sleep" for some reason I can't understand, via a simple BIOS change which disables S0 and re-enables S3. No more coming back to a laptop that's so hot you can burn your hands on it. To do this, go into the BIOS config and change the sleep option from "Windows 10" to "Linux".

More info: https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Fix-f...

Thanks! I'll try this!

I'm trying to get #boilinbaglaptop trending but will happily also use the term "Cook your Laptop" :-)

Edit: I've been looking through the BIOS three times now and still can't find it :-/

S3 is actually totally gone on Tiger Lake and newer, so with a new laptop you are hosed. This is a really gross move by MS and Intel.

If you want to make s0ix (which is what you'll need to now research if you're in this boat) suck somewhat less, start here [0] then follow the troubleshooting steps [1] (since it surely won't work the first time).

It used to be I'd roll my eyes at the people on HN complaining about Linux suspend, assuming they just had outdated information (from personal experience I'd not had any issues with S3 for many years), but now with the removal of S3 I have to start agreeing with the neighsayers.

[0] https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-li...

[1] https://01.org/blogs/qwang59/2020/linux-s0ix-troubleshooting

I've also seen a thread claiming that CPU C-states are screwed up after wake from S3. So it seems CPU sleep is buggy all around.

the option for linux sleep mode exists on my thinkpad with an 11th gen intel CPU

Where did you find it? I looked through all BIOS settings K could find three times but was not able to locate it.

config -> power -> sleep state -> select "linux" instead of "windows 10"

on a thinkpad e14

I'm about to install KDE Neon or Pop!_OS on my Lenovo ThinkPad p1 Gen2 which currently runs Windows exactly because I have found it running in my bag to many times.

My older Lenovo Yoga with KDE Neon rarely do that. Also there is still a noticeable difference (30% last I measured on the same hardware) in compile times and when it comes to cli tools like git the experience is in a completely different league.

I recently moved a Dell XPS to Manjaro and it’s the first time power management has ever just worked out of the box for me on Linux, including proper hibernate (which tbh is my default choice for most sleep states).

Yeah if you want any semblance of anything working 'out of the box', arch is just not for you.

There is no default install on arch. There is not even an installer. There's just the command line on a live system and then you create the partitions and put all the files in place automatically.

It's really great that arch exists but it's just not for everyone.

Arch has an installer. It's had one for years. It was completely broken for a long time but they released a new working version back in April. Unfortunately most people thought it was a joke since it was released on the first of April.

https://github.com/archlinux/archinstall

Also looking forward to the future post outlining the laundry list of issues and regressions caused by the first major distro upgrade.

I just completed my migration in the opposite direction after using Arch Linux as my daily driver for ~10 years.

I think Arch Linux is by far the better OS for pretty much all power users, but when using multiple devices, the benefits of the "Apple Ecosystem" outweigh the benefits of an amazing desktop OS for me, which is why I ended up switching to Mac OS.

Some key points which I believe are much worse on Mac:

* No great package managers. Nothing is super-integrated with the core system like pacman is in Arch, and even when heavily using some package manager, there will always be a bunch of software that can only be updated using their own auto-update mechanism instead of a central package manager.

* Docker in general is just much slower compared to running directly on Linux.

* Setting up ergonomic custom keyboard shortcuts is painful and requires (multiple?) third-party applications to do well.

Im going to switch from arch to mac in one month. What I should consider installing on it beside homebrew?

Bartender, Karabiner-Elements, MacUpdater, NightOwl, iStat Menus, Keyboard Maestro, Rectangle, Amphetamine are some of the most important "OS Enhancement" apps I use.

TripMode, Tripsy, 1Password, Raindrop.io, iTerm, Tower, IINA, Soulver, Spark, Carbon Copy Cloner, Find Any File, Flux, Pacifist, are some my most used "non-common" apps (excluding things like Firefox and VS Code).

Macs Just Work.

Sorry, just found it funny with the big list of applications you're recommending to install to do basic thing in OSX when the usual argument against Linux on HN is "Macs just work".

They do for regular users who use typical end user apps it doesn't just work for devs.

Apple is not designing OS for devs their vast majority of users are not devs or even professionals these days, while macs can be used for development with some wrangling to get a POSIX like environment without too much performance loss, it is not linux. Docker will run in a VM and be slower and some basic stuff like procfs would be completely missing , most of their gnu utils are from late 80s GPL being the reason.

I am also moving back to apple largely because of the m1x performance and battery. Hope Asahi becomes very stable soon on M1

> Apple is not designing OS for devs their vast majority of users are not devs or even professionals these days

yeah. So why are so many devs more or less forced to use MacBooks? someone tell their CTOs

I am a CTO and I use a system76[1] I would rather my devs used Linux systems, for a long time I did only deploy only Linux ThinkPads, but devs want MacBooks- even more so after M1 launched. A few have turned down offers because we didn't offer macs. Now we basically allow them to choose, but in the recent past not a single one has not chosen Apple .

I don't think it is all just CTOs either, there is lot of aspirational value partly driven by design of the system (light weight/looks) partly because expensive it becomes more exclusive.

Without M1 there was nothing else to go for technically they were not that much better, now atleast post m1 there is value to maybe justify the costs.

TCO for ThinkPads are way cheaper than macs upgrades are possible when it is not on macs or easier you don't need to send it apple service for ages, the in-house IT has no shortage of spare parts . No sensible CTO is going to choose apple over anything else if he had choice .

[1] ThinkPad X1 carbon before that both were much better devices just in terms of build quality than my last mac the 2016 pro .

Having linux just work is worth investing in frame.work or system76 or dell developer edition I rather do actual work than fiddle with drivers .

> Now we basically allow them to choose, but in the recent past not a single one has not chosen Apple .

I think that's awesome, and I would feel great about starting at a place that gave devs a choice between System76 and Apple.

> Having linux just work is worth investing in frame.work or system76 or dell developer edition I rather do actual work than fiddle with drivers .

Agreed! There are fun and sometimes productive forms of tinkering with Linux. Fighting incompatible hardware is not among them

The choice is usually Linux ThinkPads and Apple. System76 is great and I love it, however parts and availability of support globally is definitely limited to consider wide scale deployment. There is also reuse flexibility for returned thinkpads that can be given to for windows users .

Having said that if a employee requested system76 or frame.work I would happily get it. Sadly like I said everyone wants Macs.

Not OP but it depends entirely on how Linux-y you want your experience to be. I regularly hop between pop, manjaro, and macOS.

Brew is a given, but I also run karabiner elements for key remapping, Yabai+skhd+limelight for windows management, sketchybar as a panel, and Alfred as the run launcher since d-menu for Mac is still in early development.

This gives me some nice consistency between OSs since I use BSPWM+Polybar+Rofi on Linux.

There are several other neat little utilities that could come in handy like bettertouchtool and keyboard maestro for system wide automation with a gui and hammerspoon if you want a lua based automation program.

I personally use hammerspoon to bring up a list of Yabai shortcuts for windows management since I have too many keybindings.

As for dev tools, I use nvim, doom emacs, or VSC so it’s pretty easy to carry my config between OSs.

Not OP, but give MacPorts a try to see if you prefer it to Homebrew. It tends to push more of the configuration onto the user, but if you’re coming from Arch you might well prefer that. It’s also much faster than Homebrew in my experience.

I try to keep it pretty simple. I use Karabiner for two specific keyboard alterations (swapping : and ;, and mapping cmd+esc to cmd+` for my keyboard without a dedicated ` key). I also use iTerm instead of the built-in terminal. That's about it, at least recently. I do have Rectangle installed but I don't really use it.

Well, I also use Camo so that I can use my iPhone as a webcam, but I'll probably buy a decent webcam soon because I don't want to keep paying the ongoing subscription. (Why is everything a freaking subscription these days ...)

In the past I used the tiling window manager Yabai, but I've gotten away from that recently. It didn't work properly 100% of the time, unfortunately.

Camo has a one-time "lifetime" $79 license fee, if you want to go that route, you just have to go to their website.

Seeing a lot of recommendations for yabai- but I personally prefer amethyst for window management. Yabai had too much configuration for me- amethyst is easier

Hammerspoon is fantastic

If you use a big monitor, Rectangle (https://rectangleapp.com/) is must-have. It’s minimal and works really well. Without it, using multiple windows side-by-side is really painful.

only use Homebrew for ‘Casks’ (GUI .apps)— `brew cask` subcommand

Nix or pkgsrc for reliable management of CLI tools (both, if you want to try Nix but want an escape hatch)

don't forget to install GNU coreutils, grep, find, and bash. (BSD coreutils are weird and anemic if you're used to GNU. macOS bash is ancient, etc.)

disable cursor acceleration (barely works, but it's the only thing that works): https://plentycom.jp/en/cursorsense/index.html

the only mature terminal emulator on the platform that performs okay (provided you enable GPU acceleration): https://iterm2.com/

recover basic key remapping functionality: https://karabiner-elements.pqrs.org/

recover basic audio controls like per-app volume mixing: https://github.com/kyleneideck/BackgroundMusic

recover FUSE support: https://osxfuse.github.io/

recover configurability for a whole host of missing functionality, like global keyboard shortcuts, through automation (Lua scripting): https://www.hammerspoon.org/

recover clipboard management: https://hluk.github.io/CopyQ/

if you don't use some hack to get window tiling, you might also want to...

recover basic window management functionality: https://github.com/rxhanson/Rectangle

recover modifier key window drag: https://github.com/dmarcotte/easy-move-resize

good luck.

Whoa now, don't leave me hanging. What are the benefits of the "Apple ecosystem"? I'm using a Macbook right now because it's tiny and light and has amazing hardware, but once I need to get things done, it's closed and charging. If you have multiple devices, why do they all need to be identical?

I have a macbook and and Iphone, so one handy thing I use is the clipboard is shared between devices on the same LAN that are signed into the same icloud accont. so I can select some text with my mouse, hit "paste" in my phone, and it works instantaneously. definitely one of those "wow we live in the future" moments.

This feature is available for the linux/android combination using kdeconnect. Unfortunately I don't think there's an iOS app for that.

the ios app just came out recently didn't it? I think i saw that mentioned.I don't use iOS, but i saw articles about it. YMMV.

Having my phonecalls automatically forwarded to my laptop is a huge benefit. Being able to use my iPad pro as a secondary monitor for when I have to go into the office is very useful as well. Painless copy-paste between devices is also a huge bonus.

I‘m sure there are ways to get all of that running on linux but I‘d rather spend the time that it would take setting all that up working and let my company pay a bit more on my equipment.

Is all that really a "huge" benefit? I never get phone calls that aren't spam, or have the need to copy paste from a phone. And an 11-inch second monitor doesn't sound like a huge benefit. Especially when I could just have my company "pay a bit more" on a real second monitor.

But, not gonna discount your perspective. Everyone has different priorities, and it's why different products exist for different folks.

I guess it always depends on the person. I get probably on average 8-10 work related phone calls a day and spend 2-3 hours a day on the phone, and have been on call 24/7 for the last 6 months, any little convenience that I can get I will take. I imagine with better work/life balance these things become much less of a big deal but for now I am really glad to have an environment that causes me relatively little hassle.

Yeah, that makes sense.

"All that" seems to just be one app, which requires no setup beyond clicking "pair" on the phone once.

Well, there’s not any one simple answer to the question - there’s no one killer feature, it’s more about a bunch of different tiny QoL features that work really seamlessly without any setup. Apple apps and devices all integrate really nicely with eachother in small but noticable ways.

You can probably get close with Linux using a bunch of different apps, services and tinkering, but with Apple, it’s all quite effortless.

Your last point is interesting. When I switched from macOS to Linux, the tool is missed most was definitely Karabiner-Elements. I got nightmares from xkb & related tools.

What remappings do you use?

The Alt-Tab behavior on MacOS across multiple screens is really annoying. Also window resizing behaviors. If there was a way to override those it would be an unmatched system/environment.

I haven’t tried it so I can’t vouch for it, but AltTab[0] may meet your window switching needs.

What specifically would you prefer to be different for window resizing behaviors? If it’s something akin to Aero Snap on Windows there’s a multitude of options, including Moom[1], Rectangle[2], and Magnet[3] among others.

[0]: https://alt-tab-macos.netlify.app/ [1]: https://manytricks.com/moom/ [2]: https://rectangleapp.com/ [3]: https://magnet.crowdcafe.com/

I've said this many times on this forum, but the fact that macOS doesn't natively allow users to snap windows to the edge is incredibly annoying, and is one of those indications of the wrong and stubborn choices made in the design of the OS.

Most Linux distros don't assume they know how users want their windows arranged. macOS says, "We, in fact, do know better than users how large windows should be and where they should be placed."

> Setting up ergonomic custom keyboard shortcuts is painful and requires (multiple?) third-party applications to do well.

Take a look at Hammerspoon[0] for this if you haven't already. It requires some work to get it working the way want (you'll be writing some basic Lua code) but it's by far the best, all-in-one solution I've found for this problem on macOS. It has a ton of built-in modules for automating things including being to setup hotkeys globally as well as modal/on per-app basis

[0] https://github.com/Hammerspoon/hammerspoon

Hammerspoon is what makes macOS usable for me (plus karabiner for caps lock twiddling). The randomly rearranging layout of mission control has to be the most user hostile annoyance I have ever experienced in an OS to date.

Ironically, there isn't anything equivalent to it in linux land, and once I had gotten some really nice customizations, going back makes me a little sad.

If you’re talking about spaces automatically swapping around, you can disable that functionality in System Preferences-Mission Control, just fyi.

If Lua scripting doesn't float your boat and you don't mind commercial software, Keyboard Maestro[0] is brilliant. I use it for:

* Expanding text macros (like TextExpander but not with a subscription)

* Automating web forms I have to fill out frequently (find the "Last Name" button; send "Smith"; hit "tab"; send "Joe"; find the "Submit this form" button and press it).

* Opening apps with hotkeys.

* Scripting stuff that isn't scriptable, like "find the Music app; right click on the ... menu; click Share; click Copy Link" to get the currently playing song's URL. (PS: If you know how to reliably get this another way, please let me know.)

* Doing really nifty things with OCR on the screen, like "send this set of keypresses, then look for the text that says 'I accept this', put the mouse over it, and click it" for apps that don't use native widgets.

Hammerspoon is super cool too, but I don't have the time to really tweak it as much as I can Keyboard Maestro.

[0] https://www.keyboardmaestro.com/main/

I’m actually in the same boat. My approach to save a few bucks was to buy a lower end laptop I knew was somewhat compatible with Arch. But now I want something that just works without me configuring everything (and some better hardware too). I still have a box I built at home that I can tinker with Linux if I want too.

I only use macOS for work now because they have become too expensive to keep one just for personal use. The new M1 Air is not that expensive though, but it's still 3 times the price of a decent AMD based laptop.

Yeah - I used Arch and other distributions for years and always ended up back on macOS. There are tradeoffs, but on net it's hard to beat macOS especially if you use other Apple devices (plus the hardware has been getting better and better).

It's nice to have things work out of the box and never having to worry about things like hibernate, suspend, battery life etc. Trackpads, display resolution, fonts, random config failures - plus any macOS issue is usually easier to find a real solution for online imo.

Even in this article a ton of stuff seems like a pain in the ass:

- Hacking to connect bluetooth headphones

- Config required to reconnect to wifi

- Config required to get the monitor working

- No good native calendar

And of course at the end suspend/hibernate is still not working (naturally, probably never will work 100%). I'd also guess battery life is pretty bad and the UI of the tiling wm may be missing nice to have things (like accurate battery remaining).

I just got my first Mac ever: a MacBook Air M1. Coming from Arch I thought I would handle it easy. How bad can it be? It just works, right?… right?

So I wanted a laptop instead of a desktop computer and Framework isn’t available where I’m from so I went for the MacBook. In terms of performance, all is fine. Some OS based decisions make me want to put everything back into the packaging and send the thing back.

1) I might be alone with this but how is there no forward delete (del) button? I’ve never noticed but apparently I use it quite a lot. cmd + Backspace solves that.

2) The entire OS feels more trackpad-centric than other OS‘s I’ve used which confuses me. The gestures and the trackpad are top notch though.

3) I don’t understand the Option key. Overall the Command, Option and CTRL keys do weird things in my opinion and growing up with Windows and Linux, I don’t understand what command does either. Which leads me to…

4) The keyboard shortcuts feel complicated for the sake of complicatedness.

5) Why can I not click an app on the dock to minimise it into the dock?

6) The delete key, man.

This sounds negative but there’s a lot of positive stuff with that thing (I’m good with the display and keyboard, the battery life is crazy compared to laptops I’ve had before, …). I’m not sure yet if I want to learn a whole new OS though so I’m undecided if I want to keep it yet. The main downside of using Linux for me is Adobe (effing) Photoshop and Lightroom not working.

> The keyboard shortcuts feel complicated for the sake of complicatedness.

Mac's shortcut paradigms developed independently of IBM's CUA so they're definitely not complicated for the sake of complexity. I actually think for use with a unix-based operating system, they're much more sensible. There's no overlap with terminal commands that are mostly based on control, thus you don't need to remap basic things like pasting in the terminal to ctrl+shift+v.

> The delete key, man.

It doesn't exist as a physical key but it does work with an external keyboard. Alternatively, you might find something like Karabiner Elements [1] useful. You can make all sorts of arbitrary changes to the keyboard's behavior, including the built in one. This is sort of similar to setxkbmap, xcape, and interception-tools in linux land.

[1] https://karabiner-elements.pqrs.org/

I've discussed the shortcut thing with a friend who prefers the shortcuts on Mac, too. At the end it comes down to what you're used to and what you've learned and used for the past years I guess.

I'll definitely take a look at karabiner elements - I've seen it being mentioned in some kind of Apple subreddit as well alongside software for window snapping or at least "dividing" the screen as in Linux and Windows. Thanks for the answer!

Fn+Backspace operates as forward delete and can be combined with shift, command, and option for text editing.

I’m pretty sure Option + Clicking on a dock icon will minimize it.

If you are confused with how the keyboard shortcuts work, here’s a quick guide.

The command key is the main operator for system wide shortcuts and major application shortcuts.

Command + shift is for secondary app shortcuts

Command + option is for rarely used app shortcuts

Option is for hidden options in applications and across the system. Try opening the application menu in the top bar and holding down option to see how many new shortcuts are available up there. Try option clicking or dragging things in the system to see how they react.

The control key is never used in applications and is rarely used in the system. It’s main function is in terminal applications.

Hope this helped!

Thanks for the "option + dock icon", that helps a lot!

I knew about the forward delete shortcut but it's just another shortcut I have to remember each time I want to use it. The only reason I don't get the design decision is because I've learned it in a different manner I guess.

Outside of that, thanks for the reply. I think I got the option key better. It just gives you alternative stuff you can do in the same menu/with the same shortcut. I don't even remember why I had to use control but the positioning is also very awkward in my opinion.

Thank you!

Can an Arch person explain to me why their approach is worth it over something with a more comprehensive package manager like apt or dnf? I don’t mind compiling programs myself when needed, but for most things I’m happy to not have to hand-hold my OS when it comes to updates.

From the wiki:

> Before upgrading, users are expected to visit the Arch Linux home page to check the latest news, or alternatively subscribe to the RSS feed or the arch-announce mailing list

Like… why?

Sometimes there are some manual interventions that you may have to perform.

Yeah, exactly. Why?

Because many of the changes are large enough that it will break, and that's expected.

The KISS principle applies here.

If a config file format changes in a service between version 3 and version 4, should the package manager be responsible for it? Or the admin?

Sometimes it's not just merging changes in.

In a non-rolling release distribution, you only need to worry about those changes during major upgrades. In a rolling release distro, they can change at any time. It's no different than a user reading the release notes for Debian 11 while upgrading from 10, except the upgrades are constant.

It's the philosophy of Arch to stick to vanilla as much as possible and keep things simple. It's a rolling distro too with no fixed release cycles. When you upgrade fedora, ubuntu, etc. they perform various scripts to migrate existing configuration. In Arch, it just simply installs the vanilla packages whenever you tell pacman to update. Very rarely there is some breaking change, maybe once or twice a year, that requires manual intervention. Yeah they could automate it all but such stuff takes effort and breaks in other ways.

For one, not putting every single edge case into the package manager makes the behaviour of the package manager easier to understand.

Upstream breaks your stuff, you roll into the incompatible release, getting to fix it yourself.

There's no fixed release schedule that promises total compatibility at the cost of running years old releases.

Well, manual interventions are rare [0] and almost all of them nowadays are due to the odd package restructuring. Usually the package manager will notify you about a conflict between two packages and won't proceed (so nothing will break). At this point you can check the website if there is a need to force install a package or two.

Although definitely more technical than most distributions the perceived difficulty of Arch is mostly a meme at this point. The last large possibly-system-breaking change was almost 10 years ago [1]. And even then, the solution was quite trivial. Now if you are forcing updates that conflict without reading the news then you're in for a bad time, but that's true for all distributions. In general pacman is very conservative and won't leave your system partially updated. Now there is a chance upstream updates break things, but that's the nature of the rolling release model.

Manual compilations are not necessary if you stick to the official repositories. If you need a package in the AUR then a ports-like setup is required. I have packaged stuff for both RPM and DEB-based distributions, nothing really beats the simplicity and flexiblity of the Archlinux packaging tools.

[0]: https://archlinux.org/news/

[1]: https://archlinux.org/news/the-lib-directory-becomes-a-symli...

Looking through the latest advisories of upgrades requiring manual intervention, those mostly seem to be files that were mishandled. I guess they want to avoid "being smart" and trying to second guess the system setup.

Other distributions attempt to migrate the config / tools which mostly works, except when it doesn't. Earlier today I upgraded an Ubuntu 21.04 to 21.10. The computer is a glorified Spotify Connect player, so I don't configure anything on it. But for some reason, after the reboot, there's some issue with gvfsd-something-or-other. I never configured anything related to that. Is this normal / expected? No idea. A quick search on the release notes [0] yields nothing.

So I guess there are always tradeoffs. Arch seems to adopt more of a hands-off approach, where you only get a basic system and then you build your own environment. As such, there's many possible variations. In contrast to Ubuntu / Fedora / etc, where the devs can reasonably expect that a system is in a roughly known state.

[0] https://discourse.ubuntu.com/t/impish-indri-release-notes/21...

You can see the announcements at https://archlinux.org/. The most recent is from June:

> Starting with libxcrypt 4.4.21, weak password hashes (such as MD5 and SHA1) are no longer accepted for new passwords. Users that still have their passwords stored with a weak hash will be asked to update their password on their next login.If the login just fails (for example from display manager) switch to a virtual terminal (Ctrl-Alt-F2) and log in there once.

I wasn't affected. The next one before that was February, and also didn't affect me.

I think I could count the number of such planned manual interventions that have affected me in the 6 years I've been running Arch on my laptop on the fingers of one hand. It's approximately the number of times I would have had to reinstall my OS from scratch in that time on most other distros, based on extensive prior experience of whole distro version upgrades messing things up in mysterious ways. I put this down to the rolling release and the arch devs not being lulled onto assuming everyone's running a fresh, pristine installation.

I have a 6 year old, heavily used (including for work), heavily customised development laptop I have installed the OS on exactly once, and I have absolutely no reason to contemplate starting again from scratch. It's bang up to date and rock solid. You'd have to pry Arch from my cold, dead fingers.

Pacman now tells you when there is an announcement in the website. Most of this announcements are due some issue introduced in a package. I haven't faced all of them as usually they resolved quickly and when I update the system the new packages solves the issue. Rarely there has been a breaking change in a package that needed some easy manual intervention. I have maybe done this line 5 or 6 times in 15 years. Compared to Ubuntu, I find it upgrading process more tedious (I haven't tried it in the last year's so maybe now is better). Said that, probably i won't use arch for a production environment and stick to Ubuntu, but for home/work system, I love it

They announce (known) breaking changes that may require manual intervention. Meanwhile, when my ubuntu upgrade breaks something there is never any release notes or documentation to help me fix it. After my previous ubuntu upgrade at work, the screen locker is segfaulting instead of locking my screen, and clicking links inside the Slack crashes slack...

You can either deal with it once in while or you could let it pile up for years and then when a new major release comes up, you could spend days troubleshooting or reinstalling from scratch.

I think either method is fine, depending on the circumstances. Your choice.

I think you're confusing Arch with Gentoo or something - the Arch package manager is not from-source, it ships binaries just like apt. Perhaps you're thinking of the AUR, which does usually just host the PKGBUILD which you run makepkg on directly to compile, but that's analogous to something like an Ubuntu PPA, not the core package manager.

The main thing that people like about it is the rolling release model; new packages for virtually everything are updated within hours or days of an upstream release, with incredible practical stability.

> > Before upgrading, users are expected to visit the Arch Linux home page to check the latest news, or alternatively subscribe to the RSS feed or the arch-announce mailing list > Like... why?

That's very much a "cover-your-ass" type disclaimer, like a ToS that says you have no right to expect anything to work. In practice, 99.99% of upgrades work completely unattended, and in the .01%, you see a failure, you go to the News site and it says "sorry, we made a backwards-incompatible push, please delete this path before upgrading" or something like that, you do it, and then everything is fine again for another 18 months.

Arch still has the vestiges of this reputation as a wild-west distribution for reckless code cowboys, but in practice it is the de-facto "set it and forget it" distro. I spend literally 10x less time worrying about my distribution and package manager when I'm on Arch then on any other computing system I've ever encountered.

>That's very much a "cover-your-ass" type disclaimer,

This is not true for all hardware configurations or true for all packages combination(including weird AUR ones) in the world. For sure if we Google if this really happens in the real world you will see that indeed update break things.

Also keeping up with upstream does not mean you only get the new features but also the new bugs, especially if you were using GNOME3 a fee years back at each new GNOME release the forums and reddit was filled with new memory leaks issue, new plugin/extension breakage issues and even GNOME not starting up.

Usually when gnome doesn't start up in arch it is due extensions which are not supported either gnome or arch. But you usually find them in AUR, which fix your issues quite quickly. I haven't had any issues with gnome 3 in arch since they move to it, apart from extensions and a couple of things not well integrated in Wayland+gnome. Said that, it has been much more a nightmare for me to install packages in docker images of Ubuntu.

My point is that in Arch you can't start your work day by updating your system, you might have to fix shit instead of working.

With an LTS distro I know when teh notification for updates appears that is a security thing and it is safe to update.

>Said that, it has been much more a nightmare for me to install packages in docker images of Ubuntu.

I am assuming you are trying to install something outside the official repos, like you want to get the latest node/python or some other latest stuff using a PPA. Those PPA might not be that good quality so you could get issues like conflicts. I am not a sysadmin or dev-ops guy to tell you what is the correct way to install newer version of stuff.

My point is that will lose more time installed unsupported packages than losing some time when arch breaks, because it rarely breaks (less than once a year). And fixes usually take 5 minutes

I think it depends on the user and hardware. Many years ago I had a laptop with an AMD GPU and CPU, it was new like 1 year old when AMD drop support for the driver. If I wanted decent compositing on Linux I had to stay with an older kernel and Xorg version so I used old Ubuntu LTSes and debian at that time. And i decided to never use AMD, I got an Intel+NVIDIA PC, but now it seems NVIDIA is the one with shit drivers, and I don't change my hardware often so I will continue using my GTX-970 as many years it will hold.

Many years ago is not the same in Linux in general. Try it now. I didn't have those issues in more than a decade. Everything worked out of the box

I have used Arch Linux for the past 8 years. I've had 3 installations on four different laptops (I migrated one installation to a second laptop).

Your comment would be a really great description of my experience.

I've used Arch for the better part of the last decade and agree with this assessment as well.

Same here. I really don't understand why it has a reputation for instability. I use it on my home server.

With Arch, I've had several times on separate machines when after updating I have had to mess around with recovery stuff, manually boot and reinstall grub or whatever.

I really don't need cutting edge packages, so I don't use it any more, but I understand why people would want a lean system by default.

It is probably a reference to the AUR, but its use is not as common as some people seem to think and is somewhat discouraged (since, like PPA, the packagers are not necessarily trusted). I would also have a hard time claiming that programs from the AUR are compiled yourself. Yes, the software is usually compiled on your own hardware. On the other hand, the compilation process is handled by makepkg or an AUR helper. With an AUR helper, the process is remarkably like installing a program with pacman since it will handle dependencies.

> It is probably a reference to the AUR, but its use is not as common as some people seem to think and is somewhat discouraged

Arch proper has like 60% the package count of openSUSE, fewer than 1/2 as many packages as Fedora, fewer than 1/3 as many packages as Debian, and fewer than 1/6 as many packages as NixOS.[1]

Maybe some of this is Arch having larger packages (splitting fewer of them out), but whatever fudge factor you wanna add in, the Arch repos are extraordinarily small. You have to get into really niche shit like Solus or Exherbo to find a distro with a smaller software selection than the Arch repositories.

The idea that Arch is as usable as most Linux distros without leveraging the AUR is ridiculous.

—

1: https://repology.org/repositories/statistics/total

What matters is the relevance of the packages in the main repositories, not the quantity. While the quantity will affect some people, it will primarily affect those who use obscure packages.

As for the fudge factor, it would be difficult to even agree upon criteria. For example: should python or rust libraries be included, given they have their own package managers?

> What matters is the relevance of the packages in the main repositories, not the quantity.

This is a good point. It would be awesome if we had the metrics to look at this. I would not be surprised if Arch had a good focus on popular packages.

And yeah, what's relevant will vary between users.

> As for the fudge factor, it would be difficult to even agree upon criteria. For example: should python or rust libraries be included, given they have their own package managers?

I don't think this particular case would be too tricky. We can probably exclude them, or just count them separately. Libraries packaged in the distro package manager are useful, but they're mostly useful for simplifying the process of creating new packages for the distro.

> The idea that Arch is as usable as most Linux distros without leveraging the AUR is ridiculous.

Not really. I don't have a single AUR package installed. The paperkey software used to be the only AUR package I had installed. It eventually became part of the official repositories.

> I think you're confusing Arch with Gentoo or something - the Arch package manager is not from-source, it ships binaries just like apt. Perhaps you're thinking of the AUR

Sorry, what I meant was: when I need to manage the version of something carefully, I just compile it from source and that's OK with me. My understanding is that people use the AUR for this on Arch, and the pains don't seem worth it.

> The main thing that people like about it is the rolling release model

Fair enough, though I've been pretty happy with the pace of update from, for example, Fedora.

> That's very much a "cover-your-ass" type disclaimer, like a ToS that says you have no right to expect anything to work.

Fair enough

> Sorry, what I meant was: when I need to manage the version of something carefully, I just compile it from source and that's OK with me. My understanding is that people use the AUR for this on Arch, and the pains don't seem worth it.

Nobody's making you use the AUR! If you want to 'make && sudo make install' you can do that all day long.

The AUR value add is that other people have already figured out recipes for how to take the equivalent of 'make && sudo make install' and generate a package you can mange with the package manager.

There exist plenty of tools to automate all AUR interactions, but none of these will ever be included in Arch's main repos, since they are not a core part of Arch itself. This is to maintain a sharp delineation between properly supported Arch packages and the more wild west AUR recipes. That said, once you download a PKGBUILD from the AUR, you can use the same official tools to build and install the package that are used for the distro proper.

When I want to build from source, and something isn't in the AUR, I just spend the 5 minutes to make a proper PKGBUILD for myself. It is very easy and it simplifies management of things.

> The main thing that people like about it is the rolling release model; new packages for virtually everything are updated within hours or days of an upstream release, with incredible practical stability.

Fedora Rawhide and openSUSE Tumbleweed are both nearly as up-to-date[1] as the Arch repos but they have package managers with correct dependency solvers and continuous integration pipelines with tests produce their repos. NixOS Unstable is more up-to-date than Arch Linux[1], and its package manager never breaks your system on upgrades and features automatic rollbacks no matter what filesystem you use.

‘I want a rolling release’ doesn't really explain the choice to use Arch in particular, imo, and it's weird that this extremely common answer to ‘why Arch’ talks about a feature that isn't really specific to Arch

—

1: https://repology.org/repositories/statistics/pnewest

I had really bad experience with Fedora and Arch Linux just didn't give me any problems. Maybe it's better now, I don't know.

I don't recommend using Rawhide, but standard Fedora is pretty up to date anyway, so it's not necessary.

Sometimes when visiting arch forums the undertone is a little gatekeep-ey and people asking for more beginner friendly ways to install software like GUIs or AUR helpers are responded to with answers like 'You don't. You compile it yourself from the command line'.

For a more beginner-friendly approach to Arch, try Manjaro. The user experience is much better: you can choose one out of several desktop environments and get sane defaults, has its own system that can easily swap between different drivers and kernels, and generally very robust overall. Also the forums are more friendly towards beginners, so I view it as Arch without the elitism. The package updates are usually several weeks behind from Arch (since it uses a curated snapshot of Arch), but I view this as a plus (in reality you don’t need that much bleeding-edge updates).

i say this as a windows user for my workplace, but that's not being gatekeepers, it's upholding the ethos of the distribution. i've used arch quite a bit as a hobby linux and the reality is that i've learned more about linux via arch documentations and by being curious about how to resolve things instead of demanding an easy path. the knowledge gained produces the easy path.

The the ethos of the distribution is gatekeeping :)

Arch is the first system I have been able to support, fully. As in, 100% of the issues I run across with my distro, I can resolve. I used to run Ubuntu as my gnome desktop distribution, and when it worked (99% of the time), it was a superior experience to Arch. However when running Ubuntu I would inevitably run across some issue that seemed to require a level of sysadmin chops that I never have possessed. For the past year I've been running an Arch desktop, I have resolved every issue by using the Arch wiki and Google/ stack overflow. I suspect that partly, the Arch approach is appealing to those of us who prefer a simpler system, because those are easier to grapple with in a support context.

This has been exactly my experience as well. Ubuntu would have fewer issues initially, and almost no setup, but after setup it would break more often and always find ways to break in new and interesting ways that were very difficult to resolve, and I never could understand what was wrong.

With Arch, I was able to fix every issue that came up, full stop. But it required much more setup. It also breaks way less often. Prior to Arch, I never really felt that "full-empowered linux-user" feeling. It was always voodoo. Now I DO get that feeling and I really feel in charge and in control of my system. Interestingly, I still run ubuntu server for a couple servers, (I generally prefer debian for servers, but that's a separate discussion.) and I still find the occasional issues that come up to be difficult-to-resolve voodoo, despite having a much greater level of understanding of how linux works and does things.

Would you recommend Arch to someone without a lot of Linux experience? Ubuntu has me thinking of switching to a different OS.

You can give it a try but be prepared to spend a lot of time reading the wiki

If you're interested, I'd recommend checking out the Arch wiki - imo it's one of the most comprehensive repositories of Linux info out there and pretty easy to follow. Even other distros use and link to it since it's very general and has a huge scope. Great reference for power users and starting point for beginners.

I’d recommend going for it, and as others have said, be prepared to read the Arch Wiki, a lot. I think what’s most important would be to simply have the guts and the inspiration to keep going, even if you think you’ve lost all hope. Personally, I started out my Linux journey with Ubuntu, then distro hopped and tried PopOS, and Ubuntu-based distro with extra things here and there. Then, I took a Linux course online (for free) and gave me general fundamentals, it advertises as the “The Start from scratch Linux course”. After that and spending tons of time on Reddit and seeing post after post and the memes about ‘I use arch btw’ I decided to try it out. It was definitely fun and a tad time consuming at first, but after that I’ve learned a ton more about Linux and how things work. I’ve only had a broken system a couple times. Again, the ArchWiki is your friend.

I had a similar experience when I was a kid, with Gentoo rather than Arch.

It doesn't stay hard for very long. And when it gets easier, it stays easier basically forever, no matter what distro you use.

Manually configuring everything with Arch is a pretty good way to learn a lot about what goes into a working GNU/Linux system, and not as painful as some people make it out to be.

I recommend checking out EndeavourOS. It's an Arch based OS that sets you up with a friendly installer and a desktop environment out of the box, then gets out of your way. You don't get the fun experience of installing arch from scratch but it's a gentler introduction to the ecosystem.

I switched from ubuntu to Endeavour as my first dive into Arch recently and have been happy with it.

Arch recently introduced a general prompt-style installer script that should be able to help you setup and install a working Arch on any system.

https://python-archinstall.readthedocs.io/en/latest/installi...

My personal experience with Linux has been Ubuntu ~1 week -> Debian 2 days -> Arch 11 years now.

It will require some time learning and reading through the wiki. I would definitely recommend trying it in a vm first.

Unpopular opinion: the only people I'd recommend Arch to are people without a lot of Linux experience (who are interested in learning).

Once you learn the basics of what goes into a distro and you know how to set things up and troubleshoot, there's no reason to use a distro with a package management story as backwards as Arch's.

After you're done with Arch, learn to write packages for a couple distros (practice building them on something like OBS[1], which lets you build and distribute packages for almost any distro). Then choose your distro based on the quality of the tooling it is built on and package whatever you need that isn't already in it.

—

1: https://build.opensuse.org/

What's so backwards about Arch's package management? I've written PKGBUILDs for my own software and used that to make packages I could install on my system. Works pretty well in my experience.

Lots of cosmetic warts, like combining nothing but CLI flags instead of a subcommand interface or the necessity to use subshells and pipelines to achieve functionality that's native and obvious in other package managers. Some of my favorites kinda suck that way too, though.

Poor support for managing multiple repositories: no facilities for it built into pacman, no notion of vendor (which is useful for managing packages that may be duplicated across repositories, but with different versions or build options), the main repos are small so a huge number of packages you might want to use have an unofficial status that is much more markedly second-class than on other distros (must be compiled from source/no binary caching, installation process is either very manual or requires unpackaged tools).

No support for treatment of past transactions in the CLI for ‘undo’-like behavior or rollbacks.

No tools for managing the behavior of the dependency resolver, like to make upgrades less destructive or to automatically retry solving with more aggressive solutions that involve more downgrades and removals.

No plugin architecture, so additional functionality like integration with CoW filesystems for snapshotting requires wrappers, which is clunky and may not be composable.

No support for declaring a version for pinned packages (just the stateful IgnorePkgs, which says ‘keep whatever I have’) or restricting upgrades based on constraints or classes (e.g., in Gentoo Portage).

And it doesn't really support any of the more interesting recent innovations, like installation/upgrade atomicity, installing multiple versions of things side-by-side, installing packages on a per-user basis, running multiple package management operations at the same time.

But the single most backwards thing is the whole situation with the AUR being in eternal limbo but also a de facto standard due to the small size of the official repositories.

Pacman does have some outstanding strengths relative to most package managers: speed (by a wide margin vs. most distros) and ease of writing packages. Another thing is that if you're unbothered by the awkward status of the AUR (and having to build its packages from source), Arch users don't typically do much repo management.

This is the best reason I've heard stated for preferring Arch. Thanks for sharing!

> Can an Arch person explain to me why their approach is worth it over something with a more comprehensive package manager like apt or dnf?

Can you explain to me how dnf or apt is more comprehensive than pacman? I use all three: arch on my laptop, fedora on my desktop, ubuntu on my work laptop. I do not see the difference in comprehensiveness.

There are some house cleaning tasks pacman won't automatically do for you because doing so could break things you rely on. The same is true on fedora. It'll leave configs untouched, unless you run rpmconf which might then just break your stuff:

> If you use rpmconf to upgrade the system configuration files supplied with the upgraded packages then some configuration files may change. After the upgrade you should verify /etc/ssh/sshd_config, /etc/nsswitch.conf, /etc/ntp.conf and others are expected. For example, if OpenSSH is upgraded then sshd_config reverts to the default package configuration. The default package configuration does not enable public key authentication, and allows password authentication.

(From https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-u...)

The problem is ultimately one of churn, and how the system deals with it. Anecdotally Ubuntu tries to deal with it harder than the others, and my experience is that Ubuntu breaks (or suddenly stops behaving the way you had it configured) the most during updates. The others break less but require some attention from you.

Some of the churn is caused by distros, some of it is caused by the upstream projects. Churn is big in the Linux world.

I'm honestly not sure what you mean by apt or dnf being more comprehensive. The feature set of all Linux package managers are pretty similar. The major difference with Arch is you're heavily recommended not to do partial upgrades, but pacman will do it if you really want to. That's a difference in update philosophy between batched releases and rolling releases, not a difference in the package managers.

If you mean comprehensive in terms of available software, corporate and commercial software seems to often offer debs and rpms but not tarballs installable by pacman. On the other hand, for anything open source, the Arch official repository plus AUR has way more packages available than the Debian/Ubuntu and Redhat official repos, and having everything in one AUR for third-party packages is much more convenient than the apt/dnf way of adding a repo per vendor.

As for checking the home page every time you upgrade, you really don't need to. I think that's to stave off complaints if something breaks, because it might since you have full freedom to set things up however you want and Arch can't guarantee the standard packages with standard settings are going to work for the combinatorial explosion of possible individual setups everyone might have. But in five years of daily Arch use (I have it as the OS on 8 devices in my house right now), I've auto-upgraded daily and experienced one breakage I can think of, two days ago when certain graphical apps stopped showing a visible window. It was annoying and I still don't know why it happened (guessing something about the Wayland/NVIDIA combo is still creating issues), but it fixed itself on the next ugprade 7h hours later or so.

> package managers are pretty similar. The major difference with Arch is you're heavily recommended not to do partial upgrades, but pacman will do it if you really want to. That's a difference in update philosophy between batched releases and rolling releases, not a difference in the package managers.

No it’s a difference in package managers. Pacman doesn’t take into account library versions when resolving dependencies, it’s why partial upgrades aren’t supported because the only way to ensure every package you have installed is linked against the version of its dependencies you have installed is to have every package on your system come from a snapshot in time of the whole repo package tree.

Better package managers don’t have this problem and understand how to not break your system with partial upgrades. This matters as soon as a new version of a package has a bug and you want to downgrade it, or you build and install a package from the AUR which, when you later update your system, could need rebuilding to continue working, but pacman has no way to tell you when this is the case.

> > package managers are pretty similar. The major difference with Arch is you're heavily recommended not to do partial upgrades, but pacman will do it if you really want to. That's a difference in update philosophy between batched releases and rolling releases, not a difference in the package managers.

> No it’s a difference in package managers. Pacman doesn’t take into account library versions when resolving dependencies, it’s why partial upgrades aren’t supported because the only way to ensure every package you have installed is linked against the version of its dependencies you have installed is to have every package on your system come from a snapshot in time of the whole repo package tree.

Ding, ding, ding! This is the same dumb behavior that Homebrew has for the same dumb reason that the lead maintainer discussed here on HN just a few days ago.[1]

Pacman is extraordinarily naive as a package manager. And that's just talking about the absolute bare minimum, main job of a package manager, never mind the more peripheral features (like repo management) that are commonly incorporated into modern package managers like dnf and zypper nowadays, the lack of useful abstractions and metadata (like the representation of vendor and vendor change), or the comparatively obtuse CLI vs. modern subcommand interfaces.

If Arch Linux is for users who want to understand their systems, both because having them set it up themselves is supposed to ensure they understand it better and because its tooling is supposed to be kept simple so as to make it easier to understand, one would think these differences would be more transparent to Arch users. But perhaps in many cases it's been a while since they used other tools, and they never dug that deep into them.

—

1: https://news.ycombinator.com/item?id=29081756

In the last two years I’ve been on the arch-announce mailing list I think I have only needed to respond to breaking updates twice.

I choose arch for three reasons. 1. The official repos and the AUR have nearly every package I have ever needed. And usually packages are updated soon after a release. 2. Being rolling release, I never need to reinstall arch, just run updates periodically. 3. I love learning, and I have learned more about Linux and system maintenance from arch than anything else. While there might be a slightly larger cost of time spent setting up (and maintaining when I break something) arch, I have decided that the tradeoffs are worth it to me.

> Can an Arch person explain to me why their approach is worth it over something with a more comprehensive package manager like apt or dnf? I don’t mind compiling programs myself when needed, but for most things I’m happy to not have to hand-hold my OS when it comes to updates.

It sounds like you may be confusing Arch with some other distro. You rarely if ever need to compile anything yourself. Pacman works just like apt or dnf, i.e. resolves dependencies, downloads and installs packages for you, unless you have something specific in mind.

> a more comprehensive package manager like apt or dnf

I don't see how apt or dnf are any more comprehensive than pacman. What do you mean by that?

Before Arch, I used Fedora. It used yum as its package manager. That thing managed to corrupt its own databases at least twice during normal usage. Distribution major version upgrades always caused problems.

I never had problems like these after switching to Arch.

> I don’t mind compiling programs myself when needed

You only need to compile user packages. Official Arch Linux repositories host binary packages. You can download the PKGBUILD if you want.

> for most things I’m happy to not have to hand-hold my OS when it comes to updates.

99% of the time updates just work for me. Sometimes they introduce a few .pacnew files, I diff and merge them with my local files and that's it.

> Like… why?

Sometimes manual intervention is necessary. Usually it's not a big deal. The news tell you what to do and most importantly why you must do it.

The most complicated maintenance I ever experienced with Arch was when it switched /bin to /usr/bin.

Not PP, but to me it means much less manual intervention/more hooks etc. .

For instance, for debian I can just turn on automatic updates and basically never need manual intervention.

For arch I am not supposed to use automatic updates and have to (!) read the news.

Why? Why does arch need more manual intervention? Sure, I can do that but it just seems like a pointless waste of time.

I don't think Debian's automatic updates do major release upgrades automatically, do they? Those IIRC do require manual intervention - if nothing else you need to run the installer & possibly respond to prompts, but possibly more depending on your system.

> I don't think Debian's automatic updates do major release upgrades automatically, do they? Those IIRC do require manual intervention

For major release upgrades, the official upgrade procedure is to follow instructions like these: https://www.debian.org/releases/stable/amd64/release-notes/c...

So yeah, you have a somewhat manual upgrade process once every two years, if you're not on one of the rolling release (‘testing’ or ‘unstable’).

On the other hand, you do get to choose when you make those updates. You don't get caught by surprise with them because you forgot to read the news.

Debian's documentation on Testing and Unstable[1] contains some snippets that may feel familiar to Arch users, including this very relevant bit:

> Consider (especially when using unstable) if you need to disable or remove unattended-upgrades in order to control when package updates take place.

—

https://wiki.debian.org/DebianUnstable#What_are_some_best_pr...

> For instance, for debian I can just turn on automatic updates and basically never need manual intervention.

I question what sort of updates you're actually getting. Debian is known for being extremely outdated. This is a major reason for its stability.

Sometimes things change way too much. Sometimes they change in incompatible ways. Sometimes changes come from upstream and there's nothing the distribution can do about it. In these cases, our attention is required. Things break and we need to fix them. We need to adapt.

In order to avoid this, Debian must be outdated. It must avoid updates that break things and this necessarily means you end up using software that's years old. That's fine, it's a perfectly valid trade-off. I'm sure there are a lot of users out there whose wants and needs are perfectly filled by Debian.

If someone's interested in Arch, it's likely because of its huge repository of up-to-date unpatched software. The Arch user must be able to deal with change. Sometimes it's unavoidable and Arch culture makes it clear that users are expected to put such effort into their systems.

> years old.

where years<=2. Not a big deal, but yes can be annoying. That said upgrades between major versions are also usually automated and well tested (since they have lots of time to prepare and test that).

> users are expected...

The difference is what is considered "unavoidable". In particular, on other distros packagers are supposed to ... and only if that is not possible users are supposed to ...

> I don't see how apt or dnf are any more comprehensive than pacman. What do you mean by that?

In terms of the core functionality of package managers, they both have more robust dependency resolvers (and dnf's is actually complete[1]).

In the case of dnf, it's also more ‘comprehensive’ in the sense that the singular CLI tool handles more package management functionality (e.g., it includes repo management), and in the sense that it supports plugins.

They're also both more comprehensive in the sense that you don't need to resort to one of a dozen third-party ‘wrappers’ in order to use the bulk of packages available in those distros' ecosystems.

—

1: See the discussion of completeness here: https://arxiv.org/pdf/2011.07851.pdf

> they both have more robust dependency resolvers (and dnf's is actually complete[1])

> 1: See the discussion of completeness here: https://arxiv.org/pdf/2011.07851.pdf

That's interesting. In what ways are these resolvers superior to pacman? I never had dependency resolution issues. Can you help me understand with concrete examples? Pacman is not cited anywhere on that paper.

> you don't need to resort to one of a dozen third-party ‘wrappers’ in order to use the bulk of packages available in those distros' ecosystems

Are you referring to the AUR? I believe that's more of a man power issue. Arch is a smaller project compared to the other major distributions. There aren't enough maintainers for all packages.

> That's interesting. In what ways are these resolvers superior to pacman?

One good example is that even though PKGBUILDs can contain version constraints (see an example here[1]), that metadata is not always present and so it is underutilized. Pacman doesn't support ‘partial upgrades’[2] (once you refresh your package lists, installing anything is ‘unsupported’ until you upgrade everything), and this is why.

(I also think that paper's notion of ‘completeness’ could probably be enriched somehow, because I've seen situations where `apt-get` will crap out but `aptitude` will offer a ‘compromise’ solution which involves downgrading some packages or removing some, and generally package managers based on libsolv do even better IME. Here Arch likely falls flatter.)

Another depsolver related issue in Pacman (related to the lack of partial upgrades) is the lack of distinction between upgrades and dist-upgrades. In apt and dnf, upgrades are non-destructive by default, meaning that they don't offer solutions that involve removing or downgrading user-selected packages. Pacman has no such distinction.

> I never had dependency resolution issues. Can you help me understand with concrete examples?

One fairly common case is that Arch just ignores the dependencies of AUR-installed packages at install time, freely upgrading packages without respect to reverse-dependencies that aren't declared in a repo.[4] Hence, ‘if packages in the official repositories are updated, you will need to rebuild any AUR packages that depend on those libraries’... every single time you upgrade, if you've installed anything from the AUR, it can leave your system with broken packages. Apt and dnf, in contrast, treat every package you install the same way. Additionally, Arch packages don't always declare version constraints for their library dependencies, and there's no CI that tests for ABI changes (there is some in Debian, although such tools can't work perfectly). So you have to use another tool (apparently one popular choice is some script from the Arch forums in 2005, lol[5]) to scan for such breakages, or else just discover them when packages don't work.

On the other hand, when Arch does consider the version constraints of installed packages, the lack of partial upgrades can be problematic for downstream distros. Any version constraints placed by downstream repos on dependencies shared with upstream can just leave you totally unable to upgrade anything at all for a while.[6]

—

1: https://github.com/archlinux/svntogit-packages/blob/master/d...

2: https://wiki.archlinux.org/title/System_maintenance#Partial_...

3: https://wiki.archlinux.org/title/Pacman/Rosetta#Basic_operat...

4: https://wiki.archlinux.org/title/Arch_User_Repository#Instal...

5: https://bbs.archlinux.org/viewtopic.php?id=13882

6: https://superuser.com/questions/1497098/pacman-unable-to-upd...

> Pacman doesn't support ‘partial upgrades’[2] (once you refresh your package lists, installing anything is ‘unsupported’ until you upgrade everything), and this is why.

> Another depsolver related issue in Pacman (related to the lack of partial upgrades) is the lack of distinction between upgrades and dist-upgrades.

Yes. Personally, I believe that these are features rather than issues. I don't ever want my system to be in a partially upgraded state. I treat inability to fully upgrade as a maintenance problem that I have to solve.

I'm sure there's a lot of people out there who get a lot of use out of these partial upgrades. I'm not one of them. Stuff like apt updates vs upgrades only confused me when I used those systems. I suspect other Arch users have similar opinions.

> every single time you upgrade, if you've installed anything from the AUR, it can leave your system with broken packages

> there's no CI that tests for ABI changes

Yes, those are fair points. I suppose I don't feel this pain because I don't actually use the AUR very often. When ABIs are broken, Arch maintainers will recompile and update all affected packages. Naturally, AUR packages will not be included...

> Yes. Personally, I believe that these are features rather than issues. I don't ever want my system to be in a partially upgraded state. I treat inability to fully upgrade as a maintenance problem that I have to solve.

You don't ever have to install without upgrading on any other package manager or distro, either, though. And the way Pacman refuses to run `pacman -Syu` if some packages can't be upgraded doesn't doesn't really save you from partial upgrades, because nothing actually stops you from running `pacman -Sy <package name>`, and that is a thing people do.

> Yes, those are fair points. I suppose I don't feel this pain because I don't actually use the AUR very often. When ABIs are broken, Arch maintainers will recompile and update all affected packages. Naturally, AUR packages will not be included...

For some years (longer than I ever continuously ran Arch) I used to run Sabayon Linux. It had its own package manager, Entropy, which was hugely impressive to me at the time. It supported all of Portage's masking facilities for managing and constraining version, but it was centered on binary packages, and it was really, really fast.

At the same time, it was sort of compatible with Portage, so you could install software with `emerge` and then reconcile the Entropy package database with the newly-installed outside packages, I think with `equo spmsync`, or something like that. Of course, working this way was totally unsupported, but it was also perfectly reliable, if you knew what you were doing. Just make sure to run `revdep-rebuild && equo spmsync` after every `equo upgrade`, or whatever.

In a way, it was very similar to Arch, except instead of the AUR, you had all of Gentoo, and, if you wanted, the overlay system (its third-party repos). The integration was a little tighter, and Portage was/is a full-fledged package manager that sees use as a core tool for other distros, not one of a dozen competing wrappers around an unofficial source control repo and Entropy, so that side of things was much more powerful as well.

It was pretty cool. But the whole bifurcation between the worlds of binary packages and the source-based package management system was a persistent annoyance. There was always some hope and desire that in the future, they could be better integrated.

Arch seems content to have this kind of eternal twilight, with a package manager that's sort of source-based and sort of binary, and to get a whole package manager out of the source-based side you need some third-party wrapper tools. Then the AUR is this de facto source-based community repo with extraordinarily low packaging standards, and it never gets binary caching. It just feels half finished, and the roadmap for Arch seems to be to leave it that way forever. (I'm sure many packages graduate into the community repos all the time, which is great.)

But there are full-fledged source-based package managers now (Nix, Guix, Homebrew) where binary caching is totally transparent. There's no two kinds of repos, one source-based and one binary, and if you modify a package that's part of the main repos, the package manager just chugs along and builds it from source like nothing happened. And when it's done, it's a first-class citizen of your system no matter where it came from.

You can basically learn not to use things from the AUR because they're second-class, especially if you maintain your own local repository or you contribute to the Arch repos. It seems lots of people do. But the way many, many people use the distro is still fundamentally split between two worlds, just like the way I used Sabayon more than 10 years ago.

As another plus, the Arch wiki itself is absolutely fantastic. People will point to the Arch wiki even when running other distributions. For example, it is the place to go when doing something like GPU passthrough to another OS running on qemu/KVM.

Which, honestly, is grating.

It's great that the Arch wiki is as good as the Gentoo wiki was in 2002, but it would be even better if the Arch wiki actually acknowledged the people doing the work. For GPU passthrough, for example, the initial author/current maintainer of VFIO published a development blog which has a [multi-part series explaining VFIO and passthrough from the bottom up](http://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part...) six years ago.

This is not referenced anywhere in the Arch wiki, despite the fact that it's the literal author, most of the steps in their wiki haven't changed in the intervening years, and it's almost certain that whatever place the authors of that wiki page eventually cribbed it from probably came from the original blog.

The Arch wiki contributors, in this sense, aren't great netizens. Worse, the Arch wiki (and various subreddits) are almost as bad as the Arch/Ubuntu forums were in 2005. They often lead to a bunch of "shotgun debugging" where users are copy and pasting things they don't understand at all in the hopes that it will fix whatever problem they're encountering for reasons they won't understand.

Arch is fine, and it has its place. There are some brilliant people using Arch. The community in general is full of people who intentionally shoot themselves in the foot and are then proud that they find superglue for the wound on the Arch wiki instead of using a distro with better engineering practices where they never would have had these problems at all. The mistaken belief that doing any of this somehow "teaches" you meaningful things about Linux as opposed to solving real problems (since 99% of the "problems" Arch users encountered will never be seen on other distros, due to the fact that the maintainers carefully ensure there are limited footguns out of the) is terrible.

> Worse, the Arch wiki (and various subreddits) are almost as bad as the Arch/Ubuntu forums were in 2005. They often lead to a bunch of "shotgun debugging" where users are copy and pasting things they don't understand at all in the hopes that it will fix whatever problem they're encountering for reasons they won't understand.

This drives me absolutely fucking nuts.

> The community in general is full of people who intentionally shoot themselves in the foot and are then proud that they find superglue for the wound on the Arch wiki instead of using a distro with better engineering practices where they never would have had these problems at all.

This. A thousand times, this.

> The mistaken belief that doing any of this somehow "teaches" you meaningful things about Linux as opposed to solving real problems (since 99% of the "problems" Arch users encountered will never be seen on other distros, due to the fact that the maintainers carefully ensure there are limited footguns out of the[m]) is terrible.

Idk. There are definitely some Arch-specific footguns (like the lack of distinction between upgrade and dist-upgrade, so that ordinary pacman updates can do things like uninstall literally all of your kernels (lmfao)). But I don't think the basic approach is necessarily fatally flawed. When I installed Gentoo for the first time as a kid, getting everything working taught me:

  - how to identify hardware using using common utilities (like `lsusb`, `lspci`, and `lshw`
  - how to set up a chroot environment, how to use a chroot to manage or repair another system
  - how to install and configure a bootloader, what configuration a bootloader needed
  - how to use basic CLI networking tools to get online
  - how to manage kernel modules (blacklisting them or adding them to initrd), although admittedly a good distro will *usually* be able to anticipate those needs for you
  - how to think about package version constraints and manage packages from different sources
  - fundamentals of building and managing software (i.e., what compile-time options are, how to think about dependencies and reverse dependencies)

Probably the first two are the most valuable, and I guess nowadays the Arch installation tools basically hide what is going on in the chroot environment from you (and actually make it tricky to customize, like if you want to add extra mountpoints to it). But I don't think the whole ‘set everything up yourself once’ approach is worthless.

That's sort of my point. I'm also an old fogey in Linux hipster-land, who started off with RH5, then moved to Mandrake, then Gentoo somewhere around the kernel 2.2->2.4 transition.

It was really important then to know how to identify hardware so you could actually have it supported in your kernel (I don't remember if `genkernel` didn't exist yet or whether I was just trying to squeeze out as much performance as I could -- probably the latter). But it was also the era of winmodems, winprinters, risk of actual damage to your monitor if you screwed up the modes in X11R5/6.conf, we had to use `lilo` and remember to update it every time, etc, etc.

A lot of the people I talk to know who end up in the same positions as me still use those skills -- but we use them at distro vendors to make sure that 'normal' users never need to worry about it. Honestly, with the way Linux has been adopted, my expectation would be that by the time I exit the industry, people with the skillsets you and I have will be rare, and mostly unnecessary. Linux "just works" on the vast majority of hardware these days, and we old fogeys put a lot of blood, sweat, and tears into making that so.

It's not that I think that it's useless, it's that it's not _required_ knowledge anymore, and anyone who is convincing themselves that it's giving them deeper knowledge considering the vast increase in complexity is kidding themselves. In a pre-EFI world where all you needed was a binary (any binary) located at `/init` which "knew" how to handle everything else, it was great.

At this point, if I were starting from scratch, I'd tell people try to really understand how EFI works (https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how...), get a handle on IOMMU groups+SRIOV/nvme namespacing/whatever, and learn as much as possible about network namespacing and how SDN/CNI work, so "how does a packet get from the outside all the way to a pod || EC2/openstack instance || whatever" is reasonable, and that's not even touching "how does `dracut`/`mkinitcpio` come up and hand off to systemd+cgroups", because those are the areas where things are likely to blow up, rather than "whoops, you forgot to build the driver for your HBA into your kernel and now you can't boot", or "X11R6 completely shit the bed after a driver update broke your Xinerama config".

Different years, different problems, different things are important. What was crucial for us to learn in 2000 hardly matters in 2022 when an Arch live USB will more or less boot on any system anywhere and get you a working framebuffer, with a couple of commands to bring up your system.

You don't have to run arch if you are happy with your Ubuntu or whatever other distro. I run arch because I like trying out new software when its released, not when maintainers of ubuntu decide to include it in the next release cycle. You are pretty much always on the latest kernel, for good or bad. aur also is a gem compared to apt when it comes to modifying in-tree packages and maintaining those with the system package manager.

But well, if you are happy with your distro you don't have to use anything else.

People who like Arch because they think the AUR is actually good hate doing repo management. What they like about the AUR is that it's One Big Repo, and it (unlike the barren Arch repos themselves) is pretty comprehensive.

> > Before upgrading, users are expected to visit the Arch Linux home page to check the latest news, or alternatively subscribe to the RSS feed or the arch-announce mailing list > Like… why?

Because Arch's interpretation of ‘keep it simple, stupid’ means they are allergic to engineering in their distro tools. As a result, their package manager has deficient dependency resolution behavior. This is exacerbated by the fact that the devs make relatively little use of things like transitional packages, for some reason. But Pacman is fast, because by choosing not to have a complete dependency solver, it avoids tackling a problem with high computational complexity. For some people, that part of the user experience is good enough that it allows them to forgive Pacman for doing insane things like pointlessly breaking installed software every now and again.

Not Arch, but macOS to Linux related.

As a developer, used macOS for 13 years. Switched to Ubuntu after Apple went to M1.

It's been pretty much flawless and required no more tweaks during setup than a typical macOS install would. Developing on the same environment as our servers is a massive plus.

The key is choosing the right hardware from the start. For my desktop, I chose an Asus TUF gaming motherboard that had everything Intel. For my laptop, I chose a laptop that is supported by the manufacturer, in this case a Dell XPS 13.

(Selecting the correct hardware is no different to creating a Hackintosh setup, but the hardware support is infinitely better)

Not only is the hardware support better, but even with good hardware support, you have to do more on Hackintoshes (manually download and copy tens of kexts, edit a very, very long plist file for OpenCore, screw with the serial number if you want iMesasge, etc., etc.). Linux usually "just works."

True. For a Hack as with Linux, using compatible hardware is the key. However once that configuration process is done (and done right) from then on its typically a rock solid experience until the next major Mac OS version upgrade. In some ways it is superior to an actual Mac since you have the ability to inject kexts without having to stuff around with reboot to recovery mode, disabling SIP to install and so on. OpenCore is an impressive piece of software.

> OpenCore is an impressive piece of software.

100% agree with this in every way possible.

Cannot detract from how many features it (Audio support for boot chimes? Full graphics support? How many Linux bootloaders have that?). Tons and tons of configuration options and settings that you'll need to get a working Hackintosh.

Yes, OpenCore is an extremely impressive piece of software. It would be nice if Linux bootloaders even approached the featureset and level of polish that OpenCore has.

I went Mac->linux too. I took the notebook route when apple wasn't making anything compelling 3 years ago. I did the pay to solve compatibility problem (I bought a system76). It really has been pretty flawless in terms of upgrades and install. A fan broke after a couple years, but I replaced.. It even runs Steam very well.

Its not great with power unless I switch to "intel graphics" from Nvidia. (The intel graphics don't drive external monitors though..).

Very happy with it.

Just curious, how’s the trackpad compared to a recent MacBook Pro?

I’ve been using my Thinkpad T490 with Debian for 3 years and it’s fine. But then I tried the new MacBook Pro and that trackpad is very nice indeed. Feels a lot more precise. And the attention to smaller details and a consistent UI is nice to see too.

I’ve also been kind of peeved about several small things in Linux lately. Installing apps is not simple anymore. It started as apt-get and deb files. Now there’s flatpak and app images and electron which all have different install flows. Sometimes my Ethernet connection would, after resuming from sleep, drop to 100 Mbps until I reboot. Suspend doesn’t really work consistently. Tried installing Alfred (spotlight-like search / app launcher) and that seems to be flakey too. Mapped it to alt+ space but that doesn’t always enable it to come up.

I’m pretty picky about trackpads and the XPS 13 is as good as my Late 2013 Macbook Pro, or even better. (The MacBook trackpad was only good in macOS, the windows/linux drivers were never as good)

Its large enough, no accidental registrations due to palm and the right click is actually physical (which I find better than the Macbook’s double finger right-click tap).

You can avoid snaps and flatpack with Linux Mint or Debian. They still support them but their repos have had everything I need without using snaps or flatpack.

Getting your custom stack tuned feels great, but maintaining that entire stack across updates is daunting. You can't join meetings because your headphone/ mic/ video drivers aren't working? yikes. i trust apple to handle hardware and os for me.

I've switched to: macOS > brew (basic cli utils & gui apps) > some basic zshrc (not ohmyzsh) > docker (not environment managers) > done.

^ but i've lost trust for them to handle dev tools for me.

> You can't join meetings because your headphone/ mic drivers aren't working? yikes.

I really don't know where you're getting this from. This isn't 2004 and you don't have to screw with ALSA drivers to get basic audio functionality on Linux.

On both PulseAudio and Pipewire, I've never had this problem and I know many others who haven't had issues either, and I really just don't think audio input/output is a gigantic issue on Linux (other than, obviously, if you have niche hardware, but I still haven't had audio issues other than when I tried to install Linux on a Chromebook using the MrChromebox coreboot UEFI firmware). Audio drivers failing is something that people like to throw out there even though it's not very common. I've literally never had my audio drivers suddenly fail on me. The only mic issues I've had are the ones I'd have on any other system, like choosing the wrong input device and wondering why no one can hear me.

> maintaining that entire stack across updates is daunting

I've had Arch installs for long, long times. IME and in many other people's experiences, Arch doesn't really break that much (read: at all for me) through updates compared to other distros (eg. Ubuntu). It's a good example of a distro that you'd want to use on a desktop for this exact reason.

Thanks for sharing your experience

It’s way better than it was before (though not 2004, I used Linux for a long time and even ~ 2012 BT audio was finicky), but it’s not as plug and play an experience as on windows and macOS. For example, see this issue where BT headphones drop to extremely bad audio when you want to also use the inbuilt mic: https://unix.stackexchange.com/questions/616973/use-high-qua...

The solution to this is basically to remove pulse and install pipe wire, which is definitely not the default on most distros and not something you can do without technical skills and the time to manage the setup.

I've been a Linux user since before PulseAudio came onto the scene, and it's starting to get better. But, applications still have issues with new audio devices being connected or disconnected, and not detecting the change. Teams for Linux is a big offender here, but also OBS Studio.

Bluetooth headphones work too (which, with my previous experiences, I never expected to work beyond a tech demo), but they sometimes get stuck in HSF/HFP mode and have to be switched manually. But, at least there's a good GUI for it.

i agree. the mental overhead is too much for me to justify, personally, for my own machine

So don't use Arch. Use Debian.

That's a great advice! On the other hand, what is it that Arch offers and Debian does not? (Asking this as a long time Slackware fan.)

Newer packages? A rolling release?

What offer debian that arch doesn't offer? Arch it is really stable and with latest packages. I see debian as a pain in the ass when you want a new packages or you have to upgrade to a new version. I don't have those issues in arch.

Better package management. More stability.

I think pacman is one of the best package managers. And as I said, arch it is quite stable, a little less than debian, which stops me from using it in production, but good enough to use it daily.

or Fedora

In 30 years the "you are using the wrong distribution" never gets old it seems.

Because it's still relevant, and there will never be a one-size-fits-all distro that satisfies everyone?

It works for the desktop OSes that actually matter and are worth selling software to, the fact that it is still relevant is the issue.

Or if you really don't want to have to deal with the overhead, choose macOS or Windows.

I've been on Arch a couple years now; before that MacOS. I'd say things break about as often as they did on MacOS. Maybe once a year. It's not like MacOS with Homebrew and a few dozen developer tools is bulletproof. But at least on Arch you are able to understand your own system and have half a chance of fixing things.

You're totally right about the real joy being in "getting your custom stack". On Arch, for one example, installing Docker is just "sudo pacman -S docker". On Mac you get a web page, "Docker Desktop" and a tray icon to look at for the rest of your life. On Arch everything is just so much easier.

> You can't join meetings because your headphone/ mic/ video drivers aren't working?

Funnily the "oh wait my mic is not working, let me reboot" seems to happen all the time when my Mac-using coworkers join meetings.

That's probably more due to marketing for the Mac advertising "It just works", which attracts people with low technical aptitude.

Meanwhile, macOS, Homebrew, and Docker are all chock full of phone-home spyware, which is why I switched away.

It's a bit more work but at least I'm not fighting my computer the whole way to not spy on me.

After almost 2 years running Arch I switched back to Windows last summer on my home laptop (Dell XPS 13 9380).

The pipewire update needed by pulseaudio effects broke the sound output to my bluetooth headset. Also at the same time a Gnome update made my desktop environment unstable. I did not want to spend time on freezing dependencies, reverting some of them etc. Got tired at the time of these occasional maintenance operations, and not optimal hardware support. To be honest most of the update issues were related to Gnome major updates. I think an update only broke once my system, I could not login (pam configuration upgrade issue). I was running the LTS kernel.

I think I had better battery life on Linux thought. It must have improved with Firefox/Chromium hardware acceleration.

Arch is still my preferred distro for a dev machine thought.

Back to Windows, I just updated to W11 today, I very much like the changes in the UI. Also the ability to run some Linux GUI apps without starting a X server, exporting the DISPLAY, etc directly from the a WLS2 vm is nice.

Even thought I think I'll keep my development environment in a VM (arch) mainly because of docker. I found docker for desktop on Windows really too slow. Security wise I also prefer that, I install too many tools that I don't trust. The drawback of using a VM is of course performance but that is not that an issue for the kind of dev/work I do (NodeJs/Typescript/Vue/Python/Cloudformation/Terraform). Also sometimes I have an idea or something I'd like to test quickly and I don't want to start the VM and I just give up.

I'll probably stick to that 1 or 2 years, when I'll think about replacing my laptop. If I had to today, I'll probably go for a Macbook air m1.

I just forego docker desktop and run docker on the command line in wsl2 instead.

Have you considered trying that?

You mean install docker in the WSL2 installed distribution directly ?

I run a Ubuntu 20.04 WSL2 vm. It does not seem very easy to install it directly in the vm, for instance there is no systemd. There is the reddit post about it and most recommend to install docker desktop.

Arch is like the IKEA version of Linux. Thanks to their WIKI, i feel that i can troubleshoot most issues by myself despite not having huge linux experience.

Arch Wiki is useful even if you're using a different distro.

In many cases I think the Arch wiki is superior even to the official documentation. Which I think says a lot about the state of most documentation.

If I may suggest, take a look at autorandr [1], it saves your monitor configuration and automatically enables it when a set of monitor is detected. It's a small thing, but it improves the experience and will replace your home alias.

[1] https://github.com/phillipberndt/autorandr

I currently run a dual boot with Arch and Windows 11 on an XPS 13. There are positives to each:

* Windows has much better support for handling the Hi/Multi DPI setup that is my laptop + 2 4K screens. Wayland gets there, but unfortunately the font rendering is annoying bad, and the fractional scaling doesn't quite look right. And of course it's a very "just works" experience if you stay on the happy path. The Windows OneDrive + Office integration is great, and I have some photo software I run that is Windows-only.

* Arch gives a much better "pure laptop" experience. Hotkeys make everything easy, tiling WMs are just infinitely superior if you're working off one small screen. Also I get BETTER battery life on Arch, the laptop runs totally cool (and fans never spin up), and closing the lid puts it into true S3 sleep. It's very snappy and I use less RAM.

Also, I think people have this idea that if you use Arch the only "right" way to do it is to spend a million hours setting up a whole universe of CLI apps and becoming a wizard with hotkeys. I only use the CLI if it's truly easier than a GUI or something I don't use often. I basically just install the regular google-chrome-stable binary from AUR and then do everything on the web. Email? I set up a desktop link to fastmail. Spotify? Don't bother with native linux app, just set up a desktop link to the web player. Need to use Excel and don't feel like switching to windows? Just go use the web version, etc...Seriously, the move to webapps is doing more for the linux desktop experience than anything else.

Just gonna plug my bspwm-esque tiling windows manager for Windows 10 and 11 here since I know how hard life on Windows is without one: https://github.com/LGUG2Z/komorebi/

Small world! I use this and submitted issue #22 about the Electron/Chromium frozen window problem. Despite that issue, really fantastic software, by far the best linux-like tiling WM solution for Windows at the moment (and I've tried them all). Fantastic work!

I'm super pleased with my Linux desktop. I'm now full time Linux on the desktop, having run Windows, dual booting Windows/Hackintosh, and then Windows/Linux for quite some time. I still have a Windows partition, but I haven't been in it in half a year at this point. The experience on my desktop hasn't been flawless, but it has been pretty nice on the whole. I can't say the same for my laptop, which has been a 2 year experiment at this point. When I was using it predominantly to do light work in the office, it worked out well, but I find it more and more difficult to use from a non-coding productivity standpoint.

When I do work, I generally remote into my desktop via VSCode anyway at this point (and I really like this workflow tbh), but because I don't daily drive the laptop, there's less time spent to improve the tooling, and the ratio of time spent working to time spent fixing a weird issue is much lower than on my desktop. With some of my work potentially benefiting from the new Apple SoCs, the reversal in direction back to good sane defaults in hardware layout, and the far greater likelihood that my ratio of work to fix ratio would significantly increase, I'm pretty sure that an Apple Silicon laptop is in my near future.

For my personal desktop, I use Arch linux, and I'm perfectly happy. However, for a work laptop, I am pretty sure I'd take a new M1 Macbook Pro over a Thinkpad/XPS w/ Arch Linux.

A MBP can get 15+ hours of battery life, supports suspend/resume, and in the case of the Intel models, smooth GPU switching between dedicated and onboard.

Linux does none of that well. On a desktop, none of that matters, but I wouldn't take those tradeoffs on a work laptop.

Yeah, I'm sad we're still seeing comments like this in 2021: "I normally work using an external monitor, so I started looking at my options to configure the external display including the external keyboard and mouse."

Trying to use linux on a laptop is how I ended buying my first Macbook a decade ago.

People are having lots of issues too with external monitors and Mac laptops. xrandr on Linux ain't complicated and it works well.

I've got a M1 running on OS X and it's a sweet machine. I've got a beefy LG Gram laptop (24 GB of RAM, wider screen, much lighter than the M1) running Linux and it's a very sweet setup too.

The LG Gram running Linux is for the serious stuff, the M1 running OS X is to watch YouTube vids and overall surf from the couch.

Now of course the real work is done on my desktop/workstation (running Linux too but whatever).

What battery life does the LG get? I'm guessing less than half your Mac

That is a sweet LG laptop you have. I daily a 2018 i9/32GB Intel MBP for work, with an eGPU and three 27" monitors. "Setup" was just plugging them in.

I've got an M1 Max 64Gb for myself, and at 4.7lbs it's just light enough given its raw power (cpu and graphics). It also handles that many monitors without resorting to the eGPU (which is a good job, since it can't use one!) Had an M1 Air before that and mostly used it with old Thunderbolt 27" display and external keyboard/mouse. But I could (and did) play factorio on it for several hours on the couch on battery.

I've always wanted to try a System76 laptop, on the basis that they'd have all that laptop-linux stuff sorted out, but Apple started making nice laptops again...

It's easy for me now to drop $4k on a laptop. A decade ago, when I switched to a MacBook I was working for myself, and "it just works" was worth it so I could concentrate on making money rather than knob twiddling. It was a stressful time, so maybe I'm still carrying that experience with me.

I’m on a Thinkpad T14s for work, running Arch. Sleep/resume isn’t a problem, battery life is fine (haven’t measured but it’s probably around 8 hours) and the GPU is acceptable for the work I am doing.

Funny enough, what actually hit me in the face was an audio driver regression, but after a minor kernel update it’s seemingly back in business. A lot of stuff changes, but man, Linux audio really never changes.

If you really need GPU switching, that one definitely would be a bummer, but I’d really prefer a single GPU that can just handle light and heavy workloads reasonably. I think that’s probably going to be the norm soon.

Another thing oft overlooked is Thunderbolt support: it’s definitely not as good on Linux. I’m currently just using a non-Thunderbolt USB-C dock because my needs are not crazy enough to need more.

Is that true for preinstalled distros as well? You can buy thinkpads/XPS with fedora/ubuntu preinstalled and I expect that the manufacturer took care that everything works well.

On the flipside, if I install MacOS on a thinkpad (somewhat popular), I would expect problems with battery life, suspend/resume and gpu switching. Same with installing windows on chromebooks.

Idk my Thinkpad works pretty good with Mac. The main pain point is getting the correct wifi card. 35 bucks later and I have an airport card in it that works perfectly. Handoff, airdrop, the whole thing.

Trackpad works as good as in windows, but a Mac one is still better. The touch screen works, and track point works too. Battery life is the same or better than windows because I’m not burning CPU time on background updates unless I chose to.

I haven’t tried a dock, but HDMI out works fine.

I used Fedora/Ubuntu at works and Arch Linux at home exclusively to 2012 when I started to get into Ios dev.

Nowadays I used Mac exclusively for all of my work + personal setup(except Server of course).

And I'm convince that the only reason for me to use it is due to iOS dev. If I can get away with it I will go back to Linux. Some points:

- No more dealing with homebrew and its bizarre upgrade policies. You don't know when a package will be break. You run `brew install python` and every thing broken.

- No more dealing with the weirdo of its disk image and the locked of system volume

- No more dealing with junks stuff in a few place such as `/Library` or `/System/Library` and `~/Library`

- No longer has to run docker in a VM

- Fuse just works

- No more buggy file watchers. For some reasons the file watcher (fsnotify package I belive) on Mac sometime works, sometime not and sometime just had CPU up to 100%

- No more custom syntax to work with fslimit

- No more plist file that also gzip and encrypt

- No more installing software by going to a website and download a stupid xip file.

- No more reverse engineering how a certain thing works and script it out.

But due to iOS works, not just iOS development I also help with CI/CD for mobile app and having access to a mac locally is handy, I have to keep using it.

I made a similar jump over the past few years out of frustration with stagnating apple hardware (pre-m1). I spent a year with a hackintosh, which worked pretty well, but became disenchanted by the continued locking-down of the OS.

For the most part, daily driving Linux as my desktop has been great - no small thanks to Electron. Slack, Spotify, VSCode, etc. all just mostly work.

Going the arch-route took extra upfront work since you're effectively building a desktop environment from scratch, but the benefit is knowing exactly how -everything- works. If I press my "volume up" shortcut and the overlay volume bar isn't displayed, I know exactly which sway config and executable to look at. It's refreshingly simple.

The downsides are that upgrading is a bit anxiety producing (will I break anything?). HiDPI on Linux is still (in my experience) a bit of a mess. If you run wayland, you need to patch xwayland/sway/wlroots if you don't want blurry x11 apps. And there are some quirks- like, I can't drag files into Slack. Maybe it's fixable, but at some point you become satisfied with "good enough".

>The downsides are that upgrading is a bit anxiety producing (will I break anything?).

I don't understand why Arch users put up with this. There are plenty of distros that you can build your DE on your own with, but that have regular releases, and are extremely stable.

arch users don't really "put up" with this. every computer i run (besides my work windows machine) is arch and they have broken exactly 0 times. i update once a week, 0 problems.

For what it's worth, when one of my Macs upgrades, and starts rebooting 8 times over the course of an hour, I get pretty damn anxious too. At least with Arch it's just a bunch of packages being replaced and then a reboot. Plus, if you run a snapshotting filesystem like btrfs, you can always just roll your whole system back a few hours if things are really borked; though I've never personally had to do that. No option like that on Macs. If you upgrade and something important stops working, you're shit outta luck.

Because it gives me more chances to learn how something works than a stable OS.

I tried for years to switch away from Mac OS to Linux. I tried Ubuntu a few times as I am familiar with it from a server perspective.

It finally clicked when I tried Manjaro. The killer app for me is i3 Window manager (which you can of course use on other distributions). In general though I just like there being 'less'. I use Thinkpads and yes - have had issues with audio, and with sleep etc, but all solvable.

With Thinkpads I rather have Bluetooth working than onboard audio. The speakers are so bad I don’t even want to hear them beep.

This really doesn't sound like an article written as a "Linux newbie" ~ but props to them for finding solutions to their various workflow needs and learning. That's a big part of what Linux is all about :)

Arch is great, although I think fedora does a much better job at providing a no-nonsense Linux workstation and would make for a smoother transition from macOS.

I am personally facing up to make the opposite switch. 2 days of battery life is very attractive for me. I am thinking of keeping my current laptop as my "desktop" and carrying a Mac around.

Since most of my tools are cross platform, (jetbrains ides), my work can just continue Grimm one place to another using GitHub for synchronisation.

Was interested in the idea of Arch in a commercial environment.

Presumably this only works in a certain kind of place: one with motivated individuals and without the "oh my God people might do what they think is sensible" types from an overactive Compliance group.

Personally this would be a very satisfying kind of place to work because the single biggest challenge I face in my company is the endless fiddling that the desktop team do breaking things, as it's is often done wrongly or should be left well alone. I don't begrudge the people in the team as they're actually decent but they're stuck having to juggle various demands and roll out a steady stream of MS changes faster than they appear to have capacity for.

This is what my org does. Devs are allowed to pick their own OS as long as they can support it when IT doesn't know about the particulars. We've even contemplated running it on production servers instead of Ubuntu so that we don't have to wait 18 months for Canonical to publish the next version of a package.

> There are still many things I need to set up on the new laptop, for example: suspension/hibernation on closing the lid doesn’t always work

Sounds like a problem of hardware not designed for Linux. Everything has been working out of the box for me on a Librem laptop.

Ditto on most non Nvidia equipped ThinkPads. Typically Dell also does a good job at Linux compatibility but sometimes things take time to be worked out on newer hardware.

My strategy when picking hardware to run Linux on with 100% success so far:

1. Wait about 6 months before purchasing newly released hardware (new generation of GPU, network adapter...) to let drivers trickle down from the manufacturer to the kernel and then to the distribution.

2. If it has an Nvidia logo on it, leave it on the shelf.

Alternatively, simply buy preinstalled Linux. Worked for me.

Exactly - I have had great success with this strategy for many years now. Sometimes I take chances with #1 by running rolling release distros like Arch or Tumbleweed.

To be fair, I've had those with all Dell laptops on Windows too. In fact I've never had a Windows laptop that could reliably wake up from sleep every time.

When I had a MacBook it also wouldn't reliably wake up from sleep every time either.

Haha... I've used Ubuntu and then Arch prior to switching mac. If you have enough time and nerves to do OS/desktop env stuff yourself, then go ahead... In the end I decided to use my time for more effective things and stop geeking around.

This is HackerNews, not PracticalUserNews! :-)

Yeah. Sounds like geeking around. 20 years ago we had this cult of "living in the console" and ignoring X servers at all. It was fun for some time - even watching some video stuff using mplayer's aalib, playing mud.... But then again - this is not about productivity - it is just fun, while if you need to do work, family, etc... There's rarely time for that.

If using Ubuntu is "living in the console" for you, then something is seriously wrong with how you use it.

I mean, you sure _can_ do it. But that's not what you are supposed to do.

"supposed" is a strong word here. I don't know that you're supposed to do anything except get done what you want to get done.

He installed ubuntu server and had no clue how to install gnome ;)

Mac can never come close to xmonad + any linux distro.

I also use Iosevka on my Linux desktop since a couple of days. Subjectively a very aesthetically pleasing monospaced font.

My aesthetics skills are 2/10, and I usually don't care about UI feel much, but for some reason I really dislike "not nice" (R) fonts. But recently I switched to the combination of the default Windows 11 font (Segoe) for desktop, and Iosevka for consoles, and this feels good.

I know it's not Arch Linux but PopOS is a great pragmatic alternative. Everything worked out of the box on the old laptops I installed it.

Its not just the initial setup that's painful with Arch, the whole rolling update model means things break often and I no longer have the patience to patch them. But I do agree that linux provides a better env for development compared to macOS. On Ubuntu atm and works like charm with flexibility to extend it as I like.

"...means things break often..."

Citation needed. I can provide some anecdotal evidence to the contrary; I've been running Arch both privately and professionally now for about 15 years and sure there were some issues initially but the last decade or so I've been updating my systems fearlessly on a regular basis.

I've only been running arch on my laptop for a year, and it hasn't broken once, unlike Ubuntu which I constantly had issues with.

rolling updates isn't actually a problem in practice. the maintainers do test the applications before releasing the updates.

i encounter usually 2-3 bugs (and almost always they are minor) per year due to rolling updates and usually its in the software I'm developing relying on old behaviors. and a simple package downgrade fixes it almost every time.

Reading the netstat source... yeah, there's freedom.

Just wait until he finds out his battery life has been slashed in half after he installs Nvidia drivers. Spoiler: No Optimus :)

“Look at how easy it is to do half of the setup in those 35 steps”. Meanwhile in macOs world everything is already setup.

So … why?

Interesting, but no discussion about the touchpad? I imagine one downgrade from moving away from Mac is the touchpad experience.

I guess it comes down to personal preferences but for me the touchpad on the X1 Carbon is so much better than the Mac ones. It's just the right size (why does the Mac ones need to be so huge?), lovely physical buttons and the trackpoint is nice to have. Works perfectly on Linux.

If they are using an XPS everything should already be working on linux.

I don't get why people go from osx to arch.

Why not something that just works, and updating is not Russian roulette?

People like to parrot this but I've literally never had a breaking change from an upgrade in ~5-6 years of Arch usage. At least, if I did, it didn't take more than a couple minutes to fix, because I honestly don't remember having issues.

On the other hand doing a dist-upgrade on Ubuntu has burned me more than once. I fear having to do it on one of my home servers, and should really get off of it.

I'd argue that updating more often is more safe, since anything that goes wrong will be incremental and likely easier to deal with if it does. (Not appropriate for a production server though, you don't want things to change on that unless it's deliberate and likely infrequent)

Same experience here with 15 years of Arch usage, a few major issues before systemd, none since, except having to migrate the boot loader, network manager and so on to systemd and from time to time having to use a workaround from the latest news at archlinux.org. I have also migrated to pipewire a month ago with a single command and no issues.

It's quite stress free, because the whole operating system is basically the kernel, systemd, x11 or wayland, pulseaudio or pipewire, the nvidia driver and pacman. Not much can go wrong.

Actually, I tried arch again last month after unfa's video on pipewire support.

Couldn't even revert back to PA when PW failed, the entire system had to be reinstalled.

Can you make it work? Absolutely. Can it fail catastrophically if you make one little mistake? Absolutely.

PipeWire is basically the files pacman installed, and systemd user services.

This command would have been able to remove it:

  pacman -Rsn pipewire pipewire-pulse pipewire-alsa

And this disable it:

  systemctl disable --user pipewire pipewire-media-session pipewire-pulse

A common mistake when installing it is forgetting to install pipewire-pulse and pipewire-alsa.

https://wiki.archlinux.org/title/PipeWire

Reply on news.ycombinator.com