Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From macOS to Arch Linux

juxt.pro

Post reply on HN
Print view View original

221–230 of 256 posts

Re: From macOS to Arch Linux

#221

Post by deeblering4 »

popey wrote: post #49

"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 pro…

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

Re: From macOS to Arch Linux

#222

Post by matheusmoreira »

pxc wrote: post #198
II2II wrote: post #94

Earlier quoted context omitted.

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. W…

> 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 fa…

> 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.

Re: From macOS to Arch Linux

#223

Post by seanw444 »

pjmlp wrote: post #84
fsflover wrote: post #25

Earlier quoted context omitted.

So don't use Arch. Use Debian.

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?

Re: From macOS to Arch Linux

#224

Post by matheusmoreira »

pxc wrote: post #200
stonemetal12 wrote: post #78

Earlier quoted context omitted.

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

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 build…

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.

Re: From macOS to Arch Linux

#225

Post by matheusmoreira »

pxc wrote: post #207
matheusmoreira wrote: post #55

Earlier quoted context omitted.

> 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…

> 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…

> 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.

Re: From macOS to Arch Linux

#226

Post by SxC97 »

randomluck040 wrote: post #196
sunaurus wrote: post #10

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…

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 mi…

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!

Re: From macOS to Arch Linux

#227

Post by pxc »

matheusmoreira wrote: post #225
pxc wrote: post #207

Earlier quoted context omitted.

> 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…

> 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 do…

> 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...

Re: From macOS to Arch Linux

#228

Post by pxc »

matheusmoreira wrote: post #224
pxc wrote: post #200

Earlier quoted context omitted.

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 build…

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.

Re: From macOS to Arch Linux

#229

Post by bengalister »

vereis wrote: post #179
bengalister wrote: post #178

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…

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.

Re: From macOS to Arch Linux

#230

Post by pjmlp »

seanw444 wrote: post #223
pjmlp wrote: post #84

Earlier quoted context omitted.

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.
Post reply on HN