Live data from Hacker News

On switching to Arch Linux

mikethecoder.com

161–170 of 174 posts

Re: On switching to Arch Linux

#161
post #151

Earlier quoted context omitted.

Of course... every distro becomes the same once you remove their defaults. You can run RPM on debian and APT on fedora. You can compile everything from source on ubuntu and copy binary packages to your gentoo install. You can use ubuntu repositories on debian and vice versa. Amazingly enough, i have the freedom to kill explorer on windows and use an alternative shell+panel there too. The fact remains that Canonical a…

> every distro becomes the same once you remove their defaults You can remove some of the defaults and not all of them. For example, I still use the default Ubuntu package repos. I'm still getting value out of the default Ubuntu system without needing to run every single default.

Yes.

There's a finite distance you can run this train of thought, but i'll continue: At what point does your system stop being Ubuntu, and start being identical to someone's WindowMaker distro, customised to use ubuntu repos? (Lots of desktop debian users add ubuntu repos for the occasional package.)

Re: On switching to Arch Linux

#162

Earlier quoted context omitted.

> I'd count Ubuntu's Me menu as integrating "the social web" into the desktop. I don't see that on my Window Maker desktop. (People either forget or have never been told that Ubuntu is still actually Linux, and can run all the same software Arch and Slackware and CentOS can run. That's the charitable explanation, anyway.)

I find that it makes more sense to get the minimal and add what I want, rather than get the huge Ubuntu (and it's not the only one) bundle and try to remove everything that is unnecessary as I discover it. On a complex system I don't know what is installed and how it's installed. It's just too big to apprehend, I will never hold all this in memory. For instance I used Ubuntu for years before discovering that I do not…

Unless you set /bin/dash or /bin/sh as your shell you weren't using dash(interactivly). /bin/sh is just a symlink to /bin/dash so dash is only used for scripts with #!/bin/sh at the top.

Even root has /bin/bash as its log in shell.

/bin/dash is more like the original bourne shell which helps people write more portable shell scripts and it's faster(especially for startup).

Dash is also /bin/sh in Debian.

I'm pretty sure even unix V6 had > 11 binaries, http://man.cat-v.org/unix-6th/1/

maybe some systems using busbyox may have < 11 binaries.

Re: On switching to Arch Linux

#163

Earlier quoted context omitted.

I find that it makes more sense to get the minimal and add what I want, rather than get the huge Ubuntu (and it's not the only one) bundle and try to remove everything that is unnecessary as I discover it. On a complex system I don't know what is installed and how it's installed. It's just too big to apprehend, I will never hold all this in memory. For instance I used Ubuntu for years before discovering that I do not…

> I do not use 'GNU bash' at all, it was a fork called 'dash'. If I'm reading this right, you must be one of the very few people on Earth to use dash when you have the option to use bash. Anyway, I don't use bash, either, but that's because I moved to zsh before Ubuntu even existed. I think I was using Slackware then.

If I'm reading this right, you must be one of the very few people on Earth to use dash when you have the option to use bash.

I think you misread that. It sounds to me that he didn't realise he was using dash because it was bundled with Ubuntu and Ubuntu being a large distro with lots of defaults, it took him a long time to find this out. Your comment just validates his point because he didn't want to use dash at all, he just didn't know he was using it until a lot later (possibly after the differences already wasted his time).

Re: On switching to Arch Linux

#164

Earlier quoted context omitted.

Mac has major package management issues. Homebrew is fine (not as good as the linux counterparts, but fine), but if you make the mistake of installing Ruby with RVM Homebrew won't work, and you will spend a lot of time fixing it. With Arch you just have to get your basics set up and any development related item you need, there are precompiled packages you will install in seconds.

Ruby / RVM hasn't broken homebrew for me (thank god!)

Homebrew expects ruby to be installed at /usr/bin. RVM installs it in ~/.rvm/bin/ruby-$VERSION. Even if you symlink there are compatibility problems. I'm sure it's fixable, but non-trivially so.

Re: On switching to Arch Linux

#165

Earlier quoted context omitted.

Mac has major package management issues. Homebrew is fine (not as good as the linux counterparts, but fine), but if you make the mistake of installing Ruby with RVM Homebrew won't work, and you will spend a lot of time fixing it. With Arch you just have to get your basics set up and any development related item you need, there are precompiled packages you will install in seconds.

I've found RVM in general to be pretty temperamental; regardless of OS. rbenv[1] seems much saner. [1] https://github.com/sstephenson/rbenv

Perhaps, my point was that if you screw up your Ruby installation on Mac it is a pain to get things right again. RVM is the recommended way to install Ruby according to ruby-lang.org.

Re: On switching to Arch Linux

#166

I've been using Arch for about three years now and can't imagine using another distro. The install phase is a pain if you want to get a full-blown plug-and-play ready-to-go desktop experience that rivals Ubuntu, OS X, or Windows. It's actually really easy if you just want a bare-bones system that boots into a shell and doesn't install any packages other than what it needs to do just that. Switch to Arch if you're a m…

I appreciate the minimalist philosophy, and Arch is on my todo list (it's even got a vm allocated). However, I seemed to have evolved into a more dual-pronged strategy - Full featured Ubuntu desktop, with relatively stripped down Ubuntu/Cent/OpenSUSE servers running in VMs. For my desktop, I still value 'just works' over minimalism. Things like Spotify just work out of the box. And any software I may want to play wit…

I have switched from OS X, to Arch (2 months now full time?), so I'm not exactly coming from your angles, but I will say that every single piece of software I've ever needed has been in the main repos, and if it wasn't there, it was in the AUR.

What's fascinating is that AUR packages get voted up. Packages past a certain threshold get the choice to become a main repository package. Creating and maintaining community packages is a snap with their build system (though I've never done it personally, but understand the mechanism).

On top of that, re-building your kernel, should you ever need to (I did), is dead simple.

So to your main argument of more compromise, I believe it to be false. It's less compromise to me. I feel I have to compromise with an Ubuntu distro that has made all the choices for me (and for a client-services company at least, you'll come to the day where you need to know what those choices were). Now I have the power and ability to make the decisions I want to make, especially following the extensive wiki and super helpful forums (I feel like you could compare the helpful responses there with the type of intelligence that this community possesses).

To your final point, of the "just because I value things that help me learn Linux", this will absolutely help you learn Linux. And once you know it the Arch way, most of the other ways seem completely opaque. The standards of packages in Arch allow you to find all the important bits of all the software you installed. My company uses Arch for our servers as well because we know we can count on the standards and have up to date software that, for us, "just works".

Re: On switching to Arch Linux

#167

Earlier quoted context omitted.

I appreciate the minimalist philosophy, and Arch is on my todo list (it's even got a vm allocated). However, I seemed to have evolved into a more dual-pronged strategy - Full featured Ubuntu desktop, with relatively stripped down Ubuntu/Cent/OpenSUSE servers running in VMs. For my desktop, I still value 'just works' over minimalism. Things like Spotify just work out of the box. And any software I may want to play wit…

Yeah, that's kind of what I do. I run Mint or Ubunutu, then run lightweight distros via VirtualBox(Lubuntu, Crunchbang, etc.)

I'm curious how you enjoy working with virtual machines instead of all native?

This is admittedly my first day of not being just a lurker here, so forgive me if I shouldn't ask this here, but what is your setup and environment like?

I've considered running VMs for each client I work on, but am unsure if it'd just be a hassle or not.

Re: On switching to Arch Linux

#168

Earlier quoted context omitted.

Arch is incredibly stable - you just have to rethink your idea of what stability means in an Arch context. In Ubuntu, 'stability' means that you can run apt-get upgrade all (I think that's the command), press 'y' a few times (or, better yet, just pipe 'yes' to it) and then forget about it, knowing that your system may not have the latest version of every package, but the latest version in the Ubuntu repos, which is p…

> Arch is incredibly stable - you just have to rethink your idea of what stability means in an Arch context. I don't understand what your definition of stable is. Obviously anyone can not upgrade any distribution or software. If I want to upgrade I have to check the mailing lists to see if there are any major issues. That sounds like a source of instability. How can I update Arch, on a semi-regular basis (at least ye…

> How can I update Arch, on a semi-regular basis (at least yearly)

You can - in fact, it's best to do it more often than yearly.

> without having to worry about upgrade issues?

Compared to someone who's coming from Ubuntu, Arch isn't a distro that you can just upgrade all in one go, without thinking twice, and then forget about it. Or, to quote the Arch Wiki, pacman is not a 'fire and forget' package manager.

If your definition of 'stability' is 'I can run a full system upgrade as often as I want, without thinking about what I'm doing', then no, Arch isn't 'stable'.

If your definition of 'stability' is 'My system will run with minimal errors and above-average security as long as I carefully consider each package before I update it', then Arch is incredibly stable.

The concept of stability, in the context of a personal user, comes with an implicit assumption of how much choice will be presented to the user, which affects how much mental effort the user will have to provide. Ubuntu will make a set of choices on behalf of the user, which can result in bloated software packages, serious security concerns and bugs that persist for the six-month release cycle or longer. Arch will require the user to make some of those choices for himself or herself, which ends up by providing the user with a more modular set of packages, a much faster upgrade cycle, and a more (easily) configurable system.

For example, there was a bug in X that affected pretty much every distro a few weeks ago, allowing the screen lock to be bypassed trivially. If I remember correctly, Arch had that fixed within a few hours (the advantages of rolling-release). I'm not sure when (or even if) Ubuntu fixed that bug, but it ends up taking much longer, because they have to provide official support for those packages, and something as widespread as X needs to be tested against a variety of configurations before releasing a patch. With Arch, I can decide if the patch is important enough to update now, or if I should wait, and I can make a reasonable judgement as to whether it s compatible with my system -- something Ubuntu users will have a harder time doing, because they didn't go through the process of building their operating system from scratch when they installed it, so they may not understand it under the surface as well.

To put it another way, using a rolling-release system like Arch is no less stable than a fixed-release cycle, because nobody is forcing you to upgrade a package when it comes out.

(The other difference is that Arch provides community support, whereas Ubuntu provides corporate support, but at that point you're starting to compare apples and oranges).

Re: On switching to Arch Linux

#169

Earlier quoted context omitted.

Yeah, that's kind of what I do. I run Mint or Ubunutu, then run lightweight distros via VirtualBox(Lubuntu, Crunchbang, etc.)

I'm curious how you enjoy working with virtual machines instead of all native? This is admittedly my first day of not being just a lurker here, so forgive me if I shouldn't ask this here, but what is your setup and environment like? I've considered running VMs for each client I work on, but am unsure if it'd just be a hassle or not.

As long as your hardware can handle it, it's more than worth it. A few points:

1. I have a rule - never install server software on my base machine. Servers and server frameworks (like Rails, Jetty, PostgreSQL, etc.) are only allowed on server OS's (Ubuntu Server) running in a virtual machine. That keeps a lot of cruft and extraneous processes out of my base install, while also quarantining them into easily clonable virtual machines, should I want to recreate the vm for something. I only break that rule with one thing - I run Nginx on my host OS, and just point it at different vm appservers.

2. It helps separate your work for multiple clients. So you could setup three vm's for client 1 and three for client 2 like so - client1-webserver.vdi, client1-appserver.vdi, client1-dbserver.vdi; client2-webserver.vdi, client2-appserver.vdi, client2-dbserver.vdi.

3. It lets you more accurately simulate the production environment of an n-tier application locally, so your dev environment will be closer to prod than if you ran all these server apps directly on your base machine.

Only caveat is you need the hardware to support this. Enough disk space for multiple ~10GB vm's, enough RAM to hold them in memory, and a CPU with VT-x (and VT-d if possible) and lots of cores. I particularly like Intel's Sandy Bridge chips for this, since every core is hyperthreaded, making it appear to the OS to have twice as many cores as it actually does. Each vm can be assigned one more more core.

That's about it. Try it with Virtual Box and see what you think.

Re: On switching to Arch Linux

#170

Earlier quoted context omitted.

Yeah, that's kind of what I do. I run Mint or Ubunutu, then run lightweight distros via VirtualBox(Lubuntu, Crunchbang, etc.)

I'm curious how you enjoy working with virtual machines instead of all native? This is admittedly my first day of not being just a lurker here, so forgive me if I shouldn't ask this here, but what is your setup and environment like? I've considered running VMs for each client I work on, but am unsure if it'd just be a hassle or not.

I run Ubuntu as my main OS. Then I have VirtualBox running with couple Windows virtual installs and a couple Linux virtual installs. I give about 5G-10G disk space to each, and about 500M to 800M RAM to each (my work laptop only has 2GB, so I have to be careful). The windows virtual installs are for running different versions of IE and programs like Photoshop. The Linux versions are for running things I don't want to conflict with my main Ubuntu system. For example, I use rvm for Ruby programming, and wanted to try rbenv. However, I heard they don't play well together, so I installed rbenv on one of my virtual Linux installs and was able to experiment right away without worrying about messing up my rvm configuration. Another time, I was learning about certificates and keys, and did not want to screw up my current configuration on Ubuntu, so I was able to experiment on on of my Linux virtual installs instead, with no harm done to my main Ubuntu system. It's very liberating to be able to experiment with these without worrying about affecting your primary system.
Post reply on HN