Arch Linux – Do it yourself
dolftax.com
dolftax.com
Also, if you want to use Arch in a dependable way, subscribing to arch-announce is important[1]. It's a low traffic mailing list that notifies you of any manual steps you may need to take during a package upgrade.
(I've been using Arch for years, both at home and at work. I love it.)
That's often true, but I was disappointed that this was little more than a rephrased version of what's on the Arch Wiki.
I love the Arch documentation on the Wiki. It's perfect for me– laid out well, easy to follow, arranged in a logical wiki order, and stuffed with insanely useful tips. The pages on stuff like tmux are fantastic.
That said, I've just moved back to mint after about a year with arch. At the end of the day, arch required a little too much of my time and attention. Still a great distro, though.
That said, some distros like nix and guix are addressing a much needed problem now---how to be able to get reproducible builds. Sadly, they haven't learnt many lessons Arch taught us. Last time I tried nix, installing mutt eventually pulled in python as a dependency!
I completely agree. I tried switching to Linux a few times in high school (early-mid '00s), and always had false starts with Fedora or Ubuntu. Usually the package manager would break and everything would fall to pieces. I ended up installing Arch as a Subversion server for some personal projects, and that's what finally made it click.
I use Arch exclusively at work and at home. I do Linux development, which means I have to test out our product on other distros, usually Ubuntu. Eight-plus years later, and Ubuntu's package manager still falls over nine times out of ten. Fedora falls over. Mint falls over. I don't know what I'm doing wrong.
Arch Just Works. It's dead simple, requires very little maintenance, and when something does go wrong (maybe once a year), it's easy to fix or roll back. Arch is just files on a hard drive, not some nebulous set of five different package sources and databases and "releases" and blech.
Although many years ago I had problems when updating, in the recent years everything just works and I don't need to worry about upgrading the whole distro every 6 months.
Unavailable dependencies from mirrors.
Girlfriends OpenSUSE for example ran fine for a few months and now its stuck in an infinite update/upgrade loop or whatever it is trying to do - I really dont have the time to look into it. But the problem is, zypper cant update but really wants to update. Most likely it is conflicts between different repositories, or unavailable shit from some repository. But how useful would OpenSUSE be without the ability to play mp3 files?
So all her programs are now outdated, getting older and older.
Ive seen the same on most .deb based distros Ive tried - failure to update/upgrade a package or collection of packages - breaks the entire system.
Oh you ran apt-get install something previously? Well now that failed, and I will not let you continue until you resolve the issue, the other package will be REMOVED, and the current package cannot be installed, but for an update is who the fuck cares stfu ragequit* * (installs archlinux).
Which means you didn't try Debian stable. deb based or not doesn't matter, all that matters is distribution policies on packaging, migrations and releases.
What is the nginx version for Debian stable, is it even in the repositories yet?
> What is the nginx version for Debian stable, is it even in the repositories yet?
It's none of my business to stop you from hating Debian. Just don't blame ".deb based distros" as if them being deb based was the reason of your suffering.
ha. ha ha ha. so many things in effing all distros that are complete and utter ux fuster clucks.
Further, it might seem arcane to have to type "apt-get install -f" to install dependencies for an autonomous .deb package, but I'm not sure how different that is from having to learn, for example, the myriad switches for pacman.
Pacman doesnt leave me with a broken package-manager when a package fails to install. For example
pacman -S thatprogram
and if it fails, then next time I do pacman -S otherpgoram or pacman -Syu
it goes fine, there is nothing from thatprogram which complains or bugs me. Unlike Ubuntu/Debian where
apt-get install fail
and thus everything I try to do now will fail unless I resolve the fail.
pacman also has far less switches, at least I know only of -Q -Qs -S -Ss -Sy -U and -Ql | grep for something Im looking for. Thats all I need to know really. Like 4 or 5 switches/commands.
But look at apt,
apt-get {things here but not search!} {ugh so many switchs here} apt-{what its not really called search!?} dpkg-{jesus-christ-so-many-options}
This is exactly why I detest apt.
Our products at my last company ran Ubuntu and Mint. I detested dealing with the package manager.
I wrote so much stuff to get around apt when dealing with software packages. I wrote a Maven-based update system (with user-friendly wrappers) for pulling down updates on customer units, and my boss wrote an SVN-based solution for internal dev work. I wrote our own validation system to determine if a package can be safely installed, and if it passed, it'd get shoved in with dpkg -i --force-all, because I didn't trust dpkg to do it itself. I wrote a meta-package system (basically a tarball of debs + a manifest file) so I could guarantee atomic installation (read the manifest, verify every deb in the metapackage, and abort before installing anything if even a single package fails verification).
> pacman also has far less switches, at least I know only of -Q -Qs -S -Ss -Sy -U and -Ql | grep for something Im looking for. Thats all I need to know really. Like 4 or 5 switches/commands.
-Qo is pretty useful, too.
I figure it must be something I'm doing, but I don't know what it could be, as updating is literally the first thing I do.
Glad you've had a good experience with Arch. I've been using Debian and derivatives for years. I've occasionally seen hiccups with apt but I can almost always trace them to network trouble rather than the distro itself. In the other cases, reading the manpages or googling a bit helped unbork the system. It sounds like you didn't exercise your sysadmin/debugging skills.
But really, installing a system and using the system-provided package manager to perform a system update should "Just Work." And my experience is that this almost always ends in failure, and usually in a broken system. I dunno.
Maybe something like that already exists? I can't be the only person who has this "wants custom X but generic Y" problem.
Such an approach is usually looked down upon in the Arch community. I hate that it is. I love Arch. I love the package system, I love the wiki, I love everything about it. What I don't love is redoing everything each time I have a fresh install. Yeah, it probably takes 10 minutes to get a working system up and a day to get everything as I want it, but I hate just knowing I have to do it all again.
I really want a distro based on Arch which gets over those fears. Again, Antergos probably fits and papyros.io looks really interesting, too.
That's really too bad, because I think a method for sharing curated sets would be great. Maybe the problem isn't so much that sets would be bad, but that it might cause people's expectations of arch to change. Like, if you do everything yourself and it breaks, it's your fault, but if the system does it for you and it breaks, now it's arch's/the maintainer's fault. I don't know if that would happen, but it seems like there might be some danger of a cultural shift.
Anyway, Antergos... It looks like it uses Ubiquity to install, so I'm not sure it seems any better than anything else I've tried, but I'm only just starting to check it out so maybe there's more to it.
[edit] oh, duh, I see now that Antergos is arch-based. It looks nice. I'll have to see what the text-based installer is like.
A couple others that I believe use Arch repos and rolling-release updates directly: ArchBang (Open Box wm): http://www.wiki.archbang.org/index.php?title=Main_Page
Bridge Linux (Gnome, KDE, XFCE) http://sourceforge.net/projects/bridgelinux/
There's list of all the Arch-based distros here: http://distrowatch.com/search.php?basedon=Arch
Once you're past that initial stage, there's really no downside any more.
Surprisingly, Linus is actually quite critical of the more technical Linux distributions. Here's another quote from him:
> And when it comes to distributions, ease of installation has actually been one of my main issues - I'm a technical person, but I have a very specific area of interest, and I don't want to fight the rest. So the only distributions I have actively avoided are the ones that are known to be "overly technical" - like the ones that encourage you to compile your own programs etc.
> Yeah, I can do it, but it kind of defeats the whole point of a distribution for me. So I like the ones that have a name of being easy to use. I've never used plain Debian, for example, but I like Ubuntu.
https://www.simple-talk.com/opinion/geek-of-the-week/linus-t...
Not that I think it takes anything away from Arch, but I thought it was an interesting piece of trivia.
I also found Gentoo, let alone Linux from Scratch, very complicated and time consuming. The nice thing about Arch is that it hits the sweet spot between simplicity, technicality and easiness. In my opinion having vanilla binary up-to-date packages is the way to go.
For example:
1) despite the many criticisms levelled at a rolling release model, I've found it to be more reliable and generally less painful than upgrading between Debian / Ubuntu (for example) releases.
2) pacman is, in my personal opinion, a nicer command line tool than apt-get / apt-cache / aptitude / etc. I do quite like some of the RPM-based tools though (yum, zypper, etc).
3) Adding 3rd party repos in Arch is probably on a par with PPAs, however yaourt (AUR) almost makes it completely unnecessary to ever look for another 3rd party repo again.
That's not to say everything is perfect though: Occasionally updates need to be applied manually; being bleeding edge can be a double edged sword sometimes; and I really did prefer the old BSD-inspired rc.conf over the new system of various files scattered around /etc and the much debated systemd. But each to their own on that one.
I was once a little too slack (no pun intended) and had several hundred packages that needed upgrading and there was simply no easy way of making it work. It was around the time of the systemd introduction, so that may have been a significant complicating factor.
Note, I use pacmatic, which pulls the news feeds, but it took me getting bitten a few times before I learned to do this.
Very often, I've run into issues with Ubuntu packages solely because they have their own strange versioning, and roll certain patches into weird versions.
I think it boils down to the management philosophy: Ubuntu tries to make it 'as easy as possible', whereas Arch says, 'if you have a bug or problem, take it up with that program's developer'.
Arch says 'as vanilla as possible'.
[] Do you enjoy building everything to the minutest specification, regardless of bins being available?
[] Do you like the idea of building/rebuilding the entire system into your hardware instead of performing a quick fresh installation?
[] Let's say you've been lazy with updates -- would you mind emerge ragging the CPU for 15+ hours?
(Disclosure: I love Arch but (believe it or not) I've been die-hard Gentoo for a couple of years, even got two versions of the same T-Shirt -- which I feel is appropriate)
The worst part was there were multiple dependencies that just wouldn't compile. I fixed the first couple, but when you have a 3hr+ OpenOffice compile fail on you inexplicably... I just want my computer to work without worrying about all that! It used to be that people would say "Then why are you using Linux? go back to Win/Mac", but nowadays a perfectly stable, maintainable and fast Linux is easily achievable. I think this is the major reason behind Gentoo's declining popularity recently.
Having said that, I learnt a huge amount about Linux just by unbreaking all the bizarre things that risky Gentoo emerges did to my system :)
Ultimately, it all comes down to how I'd rather spend my time. Hours and hours every month running a big emerge on Gentoo, or a few seconds in pacman on Arch? I have work to do on my computer and eventually the process of just running the Gentoo updates was occupying too much time that I could be spending on actual work.
Forget to update for a while? Good luck getting your system into a sane state ever again. Better yet, if you go a while without updating, you'll wind up with package conflicts in your dependency graph (the worst is the dreaded "package X and package Y both insist on different versions of the same dependency"), and it'll take you forever to manually untangle them.
I've been using Gentoo as my main since 2004 or 2005, though I had some Arch experience from my work desktop at my last job (I installed Arch on it because I wanted something Gentoo-like but wasn't about to risk Compile Hell when I had deadlines to pay attention to). The decision to switch wasn't an easy one, but it's been very rewarding. I'm still of the opinion that portage is the best package management system I've used (it's not just for compiling stuff from source: there's no reason someone can't build a binary distro using portage), but pacman is a pretty damn close second, and I'll take pacman's lack of flexibility over Compile Hell any day.
I still have conflicting thoughts about systemd. I actually ripped it out on my old work computer and replaced it with OpenRC (to fulfil my goal of "something Gentoo-like but without all the compiling"), but on this machine I decided I'd keep systemd around for at least a few weeks because I wanted to get out of my comfort zone and learn something new. Now, I'm not sure what to do. I've discovered there's a bunch of stuff to really like about systemd (in particular, "systemctl status" is amazing), but on the other hand, I really miss OpenRC, and I happen to prefer its idioms over systemd's (I'm sorry, but you will never convince me that INI-style syntax isn't the ugliest thing ever).
I originally came to learn, but I've stayed for the USE flags. The number of times I have needed or wanted some feature on a package in arch (which I use for my linux vms) and have had to dig through the documentation and set up a compile environment for a package for an hour is absurd when I realize that all this is solved in 30 seconds by setting the right USE flag on gentoo.
Gentoo also has the best/most up to date python support of any distro I have found.
I'll keep that in mind about the update frequency.
Make sure to check the AUR first, I've found that 90% of the time, someone else also needed that feature, and built a package for it in the AUR. For example nginx: https://aur.archlinux.org/packages/?O=0&C=0&SeB=nd&K=nginx&o...
Also I've found PKGBUILDs very simple to tweak if you need something extra. If you do start using the AUR, I recommend getting yaourt and letting it take care of that for you. I rarely use pacman directly, as yaourt takes the same flags and works for the arch repos as well as the AUR, plus it allows you to search for packages by omitting -S.
Personally I'm not a huge fan of Gentoo, I used it on my desktop years ago and ended up breaking things weekly when portage got cranky. Currently I manage a few thousand gentoo servers, and find it tedious and frustrating at the best of times. Clients refuse to upgrade for too long, so upgrades generally mean a reinstall. And as customizable as it is, if you wanna do something outside portage, everything will inevitably break.
http://www.linuxfromscratch.org/lfs/view/6.6/chapter01/how.h...
I guess you're right about it being educational, though.
While I prefer the way Gentoo does certain things (slotting is wonderful, eselect is the best alternatives system I've seen, eselect news beats checking Arch's website for breakage warnings, and Portage overlays beat the pants off of Arch's pacman repos vs. AUR dichotomy), I'm sick to death of compiling everything. I actually got my Arch system up and running in a single night. Gentoo would've taken the whole weekend.
Also, if you forget to update for a while, it's much easier to drag an Arch system into the present day than it is to do the same with a Gentoo system.
As a sys admin, I appreciate the effort to tune everything to your needs, and Arch has its place there for sure. As a user, I just want things to work. So I usually stay away from tweak-everything-you-can distros. So now on one hand you have the distros that do pretty much everything for you (ubuntu style), and on the other you have to do the tweaking for yourself(arch, gentoo, slackware, etc). I, for one, would prefer some middle ground - eg, a system being able to predict the most optimal setup for my box, but also allow me to tweak it should I prefer something different. RHEL/CentOS seems to be slowly getting this, and I enjoy its tools quite a lot (tuned daemon for kernel params optimization, kickstart for package customizations, etc.)
And that's it, everything else is right there.
[0] https://wiki.archlinux.org/index.php/Infinality#Custom_repos...
Installing Arch Linux is pretty difficult task when you atempt to do it for your
first time if you are not familiar with command line and basics of linux.
But I would suggest you to install Arch Linux as you will gain a very good
insight on how linux works.
then If you got no idea what dd is, arch ain't for you friend!
... do not followGentoo offers even more freedom of customization than Arch. Choose your init system, your udev variant, your main Python version, set around 100 build time options for ffmpeg and so on.
LFS is great for learning and looking under the hood, but for a system that you actually use daily, Gentoo has no rival.
So they created eudev because it was becoming more and more of a hassle to dig udev out of systemd for use with non-systemd installs.
And i think LFS has also adopted eudev for their "traditional" book now, because they ran into the same issue.
Something like this should really give pause for thought in the "init" debates, as it is a stark reminder that systemd has gone far beyond being just about init. And thus all those videos demoing systemd vs "random init of the day" boot times end up being a distraction rather than enlightening.
Arch Linux = Apple
Arch "Learn more about Linux" is a indirect effect of running Arch and well LFS whole purpose.
Arch = Great Linux Distro (My second favorite to my distro home OpenSUSE)
LFS = Learning tool that is not necessarily for production machines.
I'm following a distro, Gobolinux, that used that to bootstrap their latest release. And supposedly it took more time to get the Consolekit+polkit+whatever rigamarole working so it could offer a desktop.
Now, I'm no believer in "Linux on the Desktop" any time soon (will it finally be 2015? :P), but I'm a firm believer in Linux as a multi-purpose tool that any hacker worth his/her salt should not only have in their toolbox, but also be proficient on. And not just for server usage, which is a bit more common, but on the desktop. I learned a LOT about computers from running distros like Gentoo and Arch, where you have to make decisions and learn the process and components that make things tick.
I highly recommend Arch. It's a super flexible and clean distro, that requires a bit more upfront investment to get installed, but I find it easier to maintain, with the biggest and friendliest support community, and very customizable.
What is the point of separating / from /home? I know the /boot thing is due to max size stuff on certain modes of boot, but shouldn't be required for UEFI?
And I really don't understand why you'd want to run swap. On a modern machine with huge amounts of RAM, if a process is using enough RAM that you need to start swapping it to disk, I'd rather just invoke the OOM killer and kill the badly behaved process, instead of slowing my system to a crawl while it tries to access memory at disk speeds.
And swap is required if you want to use suspend to disk which is the reasoning the article has.
I personally rarely make a second partition for home, but I always make a separate partition for /boot. GRUB requires an separate EFI partition to install (which is kind of dumb), and if you decide to encrypt your disk, the boot directory cannot be encrypted.
I think the reason they put swap in these tutorials is that many times people install linux on low-powered machines that require the swap because of limited memory. It's not a requirement to install linux, though. I never run it on installation.
The classic reason is preventing space / inode exhaustion of / by user accounts and preventing time of check, time of use vulns. Tough the latter have since been addressed in other ways [1]. There's also a certain amount of convenience and cleanliness to separating system and data that way.
1: https://wiki.archlinux.org/index.php/Security#Preventing_lin...
AUR aside (even though, as an expert, it's a fantastic resource), the repositories need keys trusted before they can be used, but nowhere in the documentation is this mentioned. When browsing the forums, you are often encouraged to not use keys, and just do everything unsecured.
I no longer trust Debian or Canonical, so I'm trying to migrate to a distribution not registered in (or under the control of) a Nation State involved in Five Eyes agreements, which is pretty much limiting me to Manjaro, Arch and Gentoo.
I'd recommend figuring out the steps in the FIFO section yourself, as it is largely dependent on how you partition your system, and one would benefit from learning about things like mkinitcpio.
If anyone interested; http://www.distrogeeks.com/arch-linux-2014-install/
"The SliM project has been abandoned (the project homepage is down, leaving a github mirror), and is not fully compatible to systemd, including logind sessions. Consider using a different Display manager or Xinitrc."
Lightdm [1] seems to be a better alternative.
[0] https://wiki.archlinux.org/index.php/SLiM [1] https://wiki.archlinux.org/index.php/LightDM
I guess I'll give LightDM a look, just in case. Thanks for the heads up!
I would also like to say that I've been using Arch Linux since 2011 and it works for my development needs. I'm using it with 3-monitors on two separate "GeForce GT 610" video cards. I've tried many other distros including Ubuntu and Fedora both GNOME/KDE. I prefer Arch + XFCE + LightDM my self :-)
An installer for Arch Linux is something I've been wondering for quite a while and didn't know it already exists :-)
But... During the past 5+ years, I rarely ever had a problem with Arch Linux that is not 100% my fault. Manjaro... it had some problem every few days; updates DB would become corrupt, random freezes, login GUI would stop functioning...
I suppose my main complaint was that Manjaro could be great it it simply eased the installation and setup of Arch Linux. I do not understand why they use a completely separate repository. Hopefully they continue to improve!
Manjaro is by far the most stable and problem free. It required a bit of tweaking to set up, and there have been a couple of times when I needed to run a command to reset the package manager to a usable state though.
(To be fair I push the Mint box hardest in terms of installing stuff and tweaking things. Its only been good since I went to XFCE as Cinnamon tended to hog the CPU randomly).
If you're going to try it on hardware, Intel graphics and networking will probably work best.
Also, the arch wiki is a great resource, in general: https://wiki.archlinux.org/
- keep using the distribution you know
- dig inside its components to understand what they do
- once you understand what they do, try using an alternative...
- ... until you ultimately realize you don't need it that much, or just want to see what it's like without this component, remove it
- once you get deep down in the customization of your distro you start to realize that the top-down approach is interesting but there'll always be something you didn't know. At that point, it makes sense to try the bottom-up approach: start from nothing, and install the components one by one. The point is that since you've already dug inside your previous distro you know what those components are, whether they are needed or not, and what the alternatives are. You won't spend time understanding these and spend more time on the actual building of a distro. This is where Arch comes in.