Disadvantage of using Arch Linux?

sand_man · 2010-09-03 04:09:15

anonymous_user wrote:

Arch Linux also spoils you because it makes other distros and their repos feel old.
"Damn the repo only has Program version 3.1. Wheres 3.4?"

For this reason Arch Linux makes me hate my job.

hatten · 2010-09-03 04:27:09

The only thing I would say is drivers, something that is plug'n'play in ubuntu may be hard, if not almost impossible to do in arch.
Second, it does not run on pre-686 computers.

cesura · 2010-09-03 04:46:05

hatten wrote:

The only thing I would say is drivers, something that is plug'n'play in ubuntu may be hard, if not almost impossible to do in arch.
Second, it does not run on pre-686 computers.

If you mean Arch Linux itself, the amazing, spectacular distribution, designed for the i686 and x86-64 architectures, then you are correct. There are a few Arch projects out there that focus on pre-686 as well as some other architectures.

Last edited by cesura (2010-09-03 04:46:25)

Labello · 2010-09-03 10:47:28

sand_man wrote:

anonymous_user wrote:
Arch Linux also spoils you because it makes other distros and their repos feel old.
"Damn the repo only has Program version 3.1. Wheres 3.4?"
For this reason Arch Linux makes me hate my job.

why is that?

hatten · 2010-09-03 13:35:28

itsbrad212 wrote:

hatten wrote:
The only thing I would say is drivers, something that is plug'n'play in ubuntu may be hard, if not almost impossible to do in arch.
Second, it does not run on pre-686 computers.
If you mean Arch Linux itself, the amazing, spectacular distribution, designed for the i686 and x86-64 architectures, then you are correct. There are a few Arch projects out there that focus on pre-686 as well as some other architectures.

well yeah, what would I else mean? The drivers?

cesura · 2010-09-03 20:07:46

hatten wrote:

itsbrad212 wrote:
hatten wrote:
The only thing I would say is drivers, something that is plug'n'play in ubuntu may be hard, if not almost impossible to do in arch.
Second, it does not run on pre-686 computers.
If you mean Arch Linux itself, the amazing, spectacular distribution, designed for the i686 and x86-64 architectures, then you are correct. There are a few Arch projects out there that focus on pre-686 as well as some other architectures.
well yeah, what would I else mean? The drivers?

You said it doesn't run on pre-686 computers. I replied and said that that holds true for "mainline" Arch, but there are projects that make Arch work with processors that are pre-686. Depends on how you meant to say that.

skanky · 2010-09-03 20:29:49

brisbin33 wrote:

heh, was that post in scheme or lisp?
on-topic: Arch requires thought and time. Some lack one, others both. I find value in the required expense.

That'd make a good t-shirt.
Or maybe it should be a checkbox that has to be clicked before downloading an install image.

Last edited by skanky (2010-09-03 20:30:44)

nomilieu · 2010-09-04 01:32:38

skanky wrote:

brisbin33 wrote:
heh, was that post in scheme or lisp?
on-topic: Arch requires thought and time. Some lack one, others both. I find value in the required expense.
That'd make a good t-shirt.
Or maybe it should be a checkbox that has to be clicked before downloading an install image.

I don't know that it's true enough to warrant a T-shirt. Arch takes thought (to know how you want to set things up) and time (to actually do it), but after that it's painless. You just "pacman -Syu" here and there and Arch does its thing.

anonymous_user · 2010-09-04 01:39:36

Well if an update breaks something, it takes time to troubleshoot it.

This is not to say other distros don't have breakage, its just Arch Linux is bleeding edge and rolling release.

hatten · 2010-09-04 06:06:25

itsbrad212 wrote:

hatten wrote:
itsbrad212 wrote:
If you mean Arch Linux itself, the amazing, spectacular distribution, designed for the i686 and x86-64 architectures, then you are correct. There are a few Arch projects out there that focus on pre-686 as well as some other architectures.
well yeah, what would I else mean? The drivers?
You said it doesn't run on pre-686 computers. I replied and said that that holds true for "mainline" Arch, but there are projects that make Arch work with processors that are pre-686. Depends on how you meant to say that.

Oh yeah, but eg the i586 project is pretty inacti, and I failed at installing that anyway. I'm so spoiled after having everything work on my other computers, with arch.

grmac · 2010-09-04 07:05:06

Personally I do not believe that there are any disadvantages to Arch Linux. Since I started using Arch again last year, I've moved it onto all my systems and have made Arch the OS of choice on all development workstations in my company.

Install and basic config is incredibly easy, package management is a dream, not just ones in the repositories, but your own that you create using pkgbuild. Has made all my day to day activities highly efficient.

arinlares · 2010-09-04 11:27:55

I've thought about it, and there are no disadvantages that aren't the user's fault aside from the fact Arch ISOs have yet to play nice with Unetbootin (at least in my experience).

Last edited by arinlares (2010-09-04 11:28:07)

Labello · 2010-09-04 13:21:50

arinlares wrote:

I've thought about it, and there are no disadvantages that aren't the user's fault aside from the fact Arch ISOs have yet to play nice with Unetbootin (at least in my experience).

they worked very nice for me :-) all my arch installs were done from usb-key

bernarcher · 2010-09-04 14:09:37

There is only one real disadvantage of Arch. You should not use it if you don't want to learn and try to fix all those minor problems yourself.

I run into some minor problem usually once a week (at least). It is unavoidable if you keep experimenting (that's Arch live, isn't it). But using other distros (SuSE, Debian, Ubuntu) there usually were major problems with every new release.

KISS, that is, advantage and (minor) disadvantages alltogether.

nomilieu · 2010-09-04 20:19:57

anonymous_user wrote:

Well if an update breaks something, it takes time to troubleshoot it.
This is not to say other distros don't have breakage, its just Arch Linux is bleeding edge and rolling release.

This only happened to me twice.

Once, a kernel update broke my wireless functionality (whoops!). No big deal; I just got the next one from [testing].
Another time recently uzbl gave me some grief regarding insert mode after an update. A visit to the uzbl homepage gave a swift answer. (But this doesn't even count since browsers are replaceable.)

The only real disadvantages of Arch are those of GNU/Linux itself.

Xehoz · 2010-09-06 07:58:52

anonymous_user wrote:

Well if an update breaks something, it takes time to troubleshoot it.
This is not to say other distros don't have breakage, its just Arch Linux is bleeding edge and rolling release.

[about being a rolling release] Still, it's way worse when an upgrade (Ubuntu, I'm talking to you) just screws your whole installation and pratically forces you to reinstall every 6 months. I don't recall ever having make an upgrade that I could actually call... smooth. Anyway, to be fair to Ubuntu, that upgrade borkification happens in other distros as well.
[about being bleeding edge] True. But, often enough, being bleeding edge doesn't bring you only new features faster with a risk of breakage. That may also grant you easy, faster access to bug fixes. And you can always revert to a previous particular package, or stop it from upgrading.

stefanwilkens · 2010-09-06 13:59:42

hatten wrote:

The only thing I would say is drivers, something that is plug'n'play in ubuntu may be hard, if not almost impossible to do in arch.
Second, it does not run on pre-686 computers.

Isn't this mainly because the "other" distros out there hack shiet to hell and back to maintain functionality without effort put in the hands of the end user, often leading to outdated software (for instance, the whole intel drivers situation), whereas arch remains bleeding edge?

The result of this being, on arch:
Everybody has up to date software and can downgrade / patch where required.

on other distros:
Everybody has out of date software and must wait for the new release for feature x

It seems to me that our approach provides the least inconvenience in terms of amount of people affected when a hardware driver goes through a period much like the intel graphics driver did.

Of course, this will only remain an advantage if the community remains high quality and knowledgeable (able to deal with the difficulties of bleeding edge). But I feel that the nature of arch and the quality of the community go hand in hand

Watermel0n · 2010-09-06 15:14:06

arinlares wrote:

I've thought about it, and there are no disadvantages that aren't the user's fault aside from the fact Arch ISOs have yet to play nice with Unetbootin (at least in my experience).

Why would you need unetbootin? You can just dd a archlinux install image to the usb drive.

marfig · 2010-09-06 17:33:40

Xehoz wrote:

True. But, often enough, being bleeding edge doesn't bring you only new features faster with a risk of breakage. That may also grant you easy, faster access to bug fixes. And you can always revert to a previous particular package, or stop it from upgrading.

Regarding other mainstream distributions with well known packagers, often upstream will already provide packaged binaries. Under most circumstances this means the latest bug fixes are available also to users of those distributions on a package basis, and sometimes faster than they are on Arch. And usually compiled against stable versions of its dependencies. So access to the latest bug fixes is rather easy and, from what I know, very common among users of other distributions who go about it on an opt-in and per package basis. You can say they stay "bleeding-edge" on their selected packages.

Arch, on the other hand doesn't really offer an opt-out mechanism. Interdependencies in a rolling-realease mechanism mean eventually a package will have to be upgraded wether the user wants to do it or not, or risk not being able to continue with its other updates. Because new versions are always (or should be?) built against bleeding-edge dependencies, the task of maintaining a rolling-release system on a package-basis can become difficult, or even impossible.

That's the disadvantage I see of "bleeding-edge" on a rolling-release distribution; no real opt-out. Not that there should be one, or that there could be one. But I think that should account as a disadvantage. In other words, the other side of the two-sided blade Arch is.

Naturally we can expect a sizeable number of packages to not have dependencies, or having long release cycle dependencies, or having dependencies that take great care with backwards compatibility and whatnot. But from a bird's eye view, Arch requires users to either stay bleeding-edge or stop using pacman. This lack of control is a disadvantage under most types of system setups. That should be accounted for.

Last edited by marfig (2010-09-06 17:39:00)

anonymous_user · 2010-09-06 17:39:47

marfig wrote:

Regarding other mainstream distributions with well known packagers, often upstream will already provide packaged binaries.

Not always though. Sometimes upstream will just provide instructions for installing the version included in the distro's repo.

Xehoz · 2010-09-07 08:07:25

marfig wrote:

That's the disadvantage I see of "bleeding-edge" on a rolling-release distribution; no real opt-out. Not that there should be one, or that there could be one. But I think that should account as a disadvantage. In other words, the other side of the two-sided blade Arch is.
Naturally we can expect a sizeable number of packages to not have dependencies, or having long release cycle dependencies, or having dependencies that take great care with backwards compatibility and whatnot. But from a bird's eye view, Arch requires users to either stay bleeding-edge or stop using pacman. This lack of control is a disadvantage under most types of system setups. That should be accounted for.

In line with kernel-lts, maybe some day we'll see lts packages option for pretty much everything. Nothing that could be done in a heartbeat though.

craig_nz · 2010-09-08 05:08:06

I really love Arch Linux for exactly what it is and is not ( http://wiki.archlinux.org/index.php/The_Arch_Way ). Its a great lightweight Linux distro that makes no assumptions about how I want to setup my system.

Still like to use different distributions for different and specific setups - really depends on what my requirements and resources are like at the time. In my personal computing I run Debian, Ubuntu and Arch, while at work I have to deal more with Cent OS and Red Hat which I'm not fond of to say the least.

Only thing that really bugs me about Arch is the lack of package signing with pgp keys - https://bugs.archlinux.org/task/5331 and http://wiki.archlinux.org/index.php/Pac … ge_signing
I don't like having to place all my trust with mirror servers.

essence-of-foo · 2010-09-08 11:06:08

The only Arch-specific matter I don't like is packages without documentation in /usr/share/doc
It's not a big issue because you can still get the same information on the web but sometimes it's not that accessible on the project's homepage and sometimes you are completely without an internet connection.

Last edited by essence-of-foo (2010-09-08 11:06:33)

yejun · 2010-09-08 11:14:17

craig_nz wrote:

I don't like having to place all my trust with mirror servers.

Network administrators do not lose their server password vs developers do not lose their gpg keys. The probability are probably on the same level.

essence-of-foo wrote:

The only Arch-specific matter I don't like is packages without documentation in /usr/share/doc

I have it.

Last edited by yejun (2010-09-08 11:14:58)

simon · 2010-09-14 11:54:18

Hmmm. None of that really puts me off the Arch install I'm contemplating, but two things bother me slightly: the "no USE flags" comparison with Gentoo (the distro I'm running at present) and the "things break often" comment.

My first and still in many ways favourite distro was Slackware. Arch has always interested me because its "simplicity" policy seems similar to the UNIX-ish approach of Slackware (minimal patching, minimal unnecessary automation and complexity, etc.). I switched to Gentoo because I can't spare the time to muck around manually keeping everything up-to-date with security patches and so on. This wouldn't have been a problem if I'd been running a bare-bones Slackware install, but of course I had dozens of built-from-source packages as well, and keeping everything up-to-date and bug-free without automatic dependency resolution was taking up too much time. Gentoo unfortunately layers on some unnecessary complexity, but I have yet to find another distro that makes it so easy to customize everything to taste and then just keep it maintained endlessly with rolling updates. My current system was installed several years ago and is still configured similarly (i.e. just how I want it) but with recent package versions.

Not as recent as those in Arch, however (one more reason I've been contemplating a switch) and it annoys me that I'm dealing with all this automated package management and yet I can't just relax and update things the way I could with e.g. Debian. With Gentoo I find that updates will break things maybe once every month or so. Of course I understand that this is inevitable due to (a) USE flags and so on meaning that very few users have identical systems, and (b) rolling release meaning that there is no long testing period for a single frozen package set. However...it's still annoying, and whenever something breaks and I have to fix it, I wonder if perhaps I should try the other popular "rolling release" distro...Arch.

The comment about no USE flags doesn't bother me for the reason of the USE flags themselves, because I assume your PKGBUILD scripts contain "configure" statements that do the same thing on a per-package basis, and frankly (being a former Slacker and permanent control freak) I would rather read the individual package documentation and choose the configure options myself than trust make.conf's USE settings to get it right. But it bothers me because it makes me realise that I have basically been assuming the Arch build system makes Arch something of a cross between Slackware and Gentoo, whereas in fact I have no idea whether the ABS actually offers anything significant over good old-fashioned Slackware-style building from source (with, of course, SlackBuild scripts so it's relatively easy to rebuild with new tarball versions). I see from the wiki that "makepkg" can handle dependency resolution, so that seems like a significant advantage: does it build the dependencies from source or pull in binaries from the repositories? Can it be configured to do either? Most importantly, if I build a package from source (using the ABS) and then do a system upgrade that includes a newer version, how does pacman resolve this? Does it pull in a new source tarball and attempt to rebuild the package with my customizations, or does it simply wipe over my custom package with a new binary?

My other concern is the comment about breakage: I do NOT want to be mucking around with breakage every few weeks as I am at present with Gentoo. I was more or less assuming that the "foundation" of official binary Arch packages would make breakage much rarer with Arch updates, even when using custom and user contributed packages too, in comparison with Gentoo's situation of every-single-package-built-with-custom-settings. But is this assumption false? Do you find that Arch breaks just as often as Gentoo does?

I guess what I'm asking is, have any of you spent enough time using Slackware, Gentoo and Debian (which represent my three ideals of "simple enough to actually know what it's doing", "set it up once then update it forever", and "trust it to actually work when you're depending on it") to know whether Arch is worth switching to, over all of these? I'm interested in giving Arch a go, but don't want to waste several days learning the Arch ways of setting things up to my liking, only to find that the end result is disappointing. I want a simple, fast, up-to-date and easily customized system that's reasonably reliable (not Debian or RHEL reliable of course, but at least more reliable than Gentoo). Based on the concerns I've mentioned, can Arch deliver?

Arch Linux

#76 2010-09-03 04:09:15

Re: Disadvantage of using Arch Linux?

#77 2010-09-03 04:27:09

Re: Disadvantage of using Arch Linux?

#78 2010-09-03 04:46:05

Re: Disadvantage of using Arch Linux?

#79 2010-09-03 10:47:28

Re: Disadvantage of using Arch Linux?

#80 2010-09-03 13:35:28

Re: Disadvantage of using Arch Linux?

#81 2010-09-03 20:07:46

Re: Disadvantage of using Arch Linux?

#82 2010-09-03 20:29:49

Re: Disadvantage of using Arch Linux?

#83 2010-09-04 01:32:38

Re: Disadvantage of using Arch Linux?

#84 2010-09-04 01:39:36

Re: Disadvantage of using Arch Linux?

#85 2010-09-04 06:06:25

Re: Disadvantage of using Arch Linux?

#86 2010-09-04 07:05:06

Re: Disadvantage of using Arch Linux?

#87 2010-09-04 11:27:55

Re: Disadvantage of using Arch Linux?

#88 2010-09-04 13:21:50

Re: Disadvantage of using Arch Linux?

#89 2010-09-04 14:09:37

Re: Disadvantage of using Arch Linux?

#90 2010-09-04 20:19:57

Re: Disadvantage of using Arch Linux?

#91 2010-09-06 07:58:52

Re: Disadvantage of using Arch Linux?

#92 2010-09-06 13:59:42

Re: Disadvantage of using Arch Linux?

#93 2010-09-06 15:14:06

Re: Disadvantage of using Arch Linux?

#94 2010-09-06 17:33:40

Re: Disadvantage of using Arch Linux?

#95 2010-09-06 17:39:47

Re: Disadvantage of using Arch Linux?

#96 2010-09-07 08:07:25

Re: Disadvantage of using Arch Linux?

#97 2010-09-08 05:08:06

Re: Disadvantage of using Arch Linux?

#98 2010-09-08 11:06:08

Re: Disadvantage of using Arch Linux?

#99 2010-09-08 11:14:17

Re: Disadvantage of using Arch Linux?

#100 2010-09-14 11:54:18

Re: Disadvantage of using Arch Linux?

Board footer