One of the most notable characteristics of Arch is its rolling release model, which assures users that they will always have the latest and newest version of a program available. Has this model brought any noticeable disadvantages (for example: programs that depend on older libraries who aren’t on the system anymore because of an update)?
Thomas Bächler:
There are two huge disadvantages:
- Library updates break ABI and API compatibility. In the former case, we have
to do mass rebuilds in our testing repositories so everything is compatible
again in the end. In the latter case, the same is necessary, but we also have to
find or write patches for many applications. This is not a big problem, but has
to be done right. - Hardware incompatibility: There are 2 candidates that keep breaking people’s
computers: Linux and Xorg. As a current example, many ATI cards are barely
usable on Arch right now – that will hopefully improve with the release of
2.6.32, but I am sure something else will break.
Allan McRae:
Rebuilds for library, so namebumps are the biggest issue, but the rebuild process
for Arch is quite streamlined. Because we try to have the latest versions of
packages, we often run into issues that have not been encountered before, which
requires working with upstream to find and patch the problem code.
Aaron Griffin:
The biggest problem with the rolling release model is laziness – from upstream
developers and Arch users. We try to stay up to date wherever possible, but some
upstream developers are slow at adopting new changes. This means we need to do
extra work to make their software compatible with new library versions and
things of that nature. On the user end, you get people who don’t regularly
update their system (something we indicate as very important), and you end up
with newer software and older libraries on the same system, causing breakages.
Giovanni Scafora:
Arch Linux is a rolling release. That’s good, and I noticed no disadvantage.
Ionut Biru:
Let’s clarify something first. We have the latest and newest stable version of
a program.
Having that from time to time, we have to rebuild a lot of applications and
sometimes we have to patch and collaborate with upstream developers. Because we
are early adopters of all, new users have to suffer sometimes. xorg and drivers
rewrite is one example.
Tobias Kieslich:
It’s a two-side sword. It sure is a pain in the neck to recompile half of the
distro for an ABI incompatible ssl update. On the other hand, it reveals bugs
and keeps the packages up to date. For what Arch is and for what most people use
it, I think the rolling release is surely benficial.
Ronald van Haren:
It requires a lot of rebuilding for some particular updates and sometimes a not-so-widely used package is missed, but I think we are on average very quick in
fixing these things. As we require signoffs from other developers before we
move important stuff to core, it is highly unlikely that this happens to one of
the system’s core packages.
Pierre Schmitz:
The most notable disadvantage of running the latest software is seeing bugs and
problems no one else has discovered before. But fortunately new versions of
software generally fix more bugs than they introduce.
But serious regressions are really rare as we test important packages before
they are moved to our [core] repository.
But as an Arch user, one should be able to debug simple problems and shouldn’t
be scared of the command line.
Dan McGee:
We encounter quite a few first adopter hurdles when rebuilding packages. This
is especially true when building a core library that involves rebuilds of
several packages that often require some patching to be compatible with a newer
version of the library.
Arch uses the PKGBUILD system to make and compile packages. What does the future hold in store for the PKGBUILD system? Are there any new features or modifications that are planned?
Dieter Plaetinck:
Do we need any?
Allan McRae:
Yes. Improved support for running test suites. Splitting debug symbols into
separate packages. The way VCS packages are handled needs an overhaul.
Aaron Griffin:
I’ll defer to Allan here. Suffice to say that things are always in flux and
always improving. That’s the way we do things. Short answer: Yes. 🙂
Ionut Biru:
The overall format of PKGBUILD is good as it is now, but improvements are always
welcomed.
Tobias Kieslich:
I think that we can roll separate packages from a single build now is a big
plus. It allows for smaller packages, lesser dependencies.
Arch Linux has steadily grown in user-base while still holding true to the simple DIY design. Without holding people’s hands, Arch is growing and growing. What do you attribute this to?
Thomas Bächler:
Arch works. It’s that simple. One reason is its simple design, the other is that
its users are required to know and understand their system – and we make it easy
for everyone to understand it.
The Arch Linux community is very strong and friendly and communicates a lot. We
have a very active BBS and probably the most active IRC channel I have ever
seen. And this community isn’t just a bunch of dumb idiots, but our average
community member is smart and knows his/her way around Linux and Arch.
Another reason might be that our users want to get their share when we finally
succeed in our evil and secret world domination plans.
Allan McRae:
The developers being awesome.
Aaron Griffin:
I think that people are getting tired of Linux distros trying to be more
Windows-like. People see all this automation with 100 links in the chain, only
to see one link fail and bring the whole thing crashing down around them. With
Arch, they gain awareness of the whole chain, not just the tail end that they
see.
Ionut Biru:
I think because we have a rolling release model, because we have the latest
stable version of application and because it is simple to use. The community has a
big role because it is friendly and helpful with all new comers.
Tobias Kieslich:
A nice and helpful community. I think people take pride in explaining things
and not throwing a RTFM on new user just because they can. On the other end of
that, stick people become more curious about the abilities of Linux and are
willing to try and learn.
Pierre Schmitz:
At first, I am quite sure that Arch’s growth is limited. Most people don’t care
what goes on behind the scene of their operating system or even want to control
every single bit of it. And don’t get me wrong, that is perfectly fine.
One of our strengths is that, while evolving on all levels, we still try hard to
keep it simple. This makes it easy for new users to build their own packages
and understand the way how are things done in Arch.
Hugo Doria:
We look sexy.
What does the future of pacman hold? Where is development currently going?
Allan McRae:
http://wiki.archlinux.org/index.php/Pacman_Roadmap
Dan McGee:
Signed packages are super important and are targeted for the next major pacman
release. Besides that, alternative compression methods, deltas, and an improved
database interface are large features that may find their way into the code in
the next year.
I haven’t read the whole interview yet, I will get to that a little later, but I have to say this distro does give new life into dependency hell. I enjoy using the distro, but the x64 build has less than the optimal amount of applications in it, so they point you to AUR which are user made applications for arch. Only problem sometimes is that one application could require 10+ dependencies or more, with many times those dependencies branching out. For example I will use wine since it is the most recent example I can think of.
http://aur.archlinux.org/packages.php?ID=7915
So you start installing the package using pacman and aur and you hit a snag saying you need a dependency, first thing you do is there are a list of dependencies on that webpage it says you need, so you download the one missing and it will then tell you that you need a dependency for that dependency(or 3, which these can branch out further). This can go on for a while 10+ once, and one time there wasn’t even an end(meaning no one made the package).
This seems to be mostly an X64 problem though, so it might not be a big problem for most. Also I only really ran into it while trying to get wine going initially. So if someone that is knowledgeable in using Linux wants to give this Distro a try it is a very good and well made distribution, except for that slight annoyance that I ran into. The only problem I can think of is that everyone now only makes packages and designs everything for Ubuntu, so you get less packages that are easy to install and are mostly at the mercy of other users or your own time. Which is to say business as usual.
The example you said is kinda, well, annoying, as seems the WinE project doesn’t have a real x64 support yet, and it depends on many other packages, that need their 32-bit version to work properly with wine.
The problem here isn’t Arch, but the third party development, which is incomplete or has any other issue.
that is what AUR and abs are for: edit PKGBUILD for your own liking.
I do this all the time when I want to cut down on dependencies or want to add/modify something
To be fair, AUR is completely community driven. You will often find many versions of the same software, some of which doesn’t even have an owner anymore. The biggest problem is finding what version everyone else is using. I realize that there is a tool called yaourt that makes AUR seamlessly integrate with pacman, but from the comments I’ve read it breaks more than it fixes.
I consider Arch’s package management system (pacman) to be the best of any Linux distribution. Part of the reason is that it is flexible enough to allow you to decide which sub-packages you want to install. With KDEmod, for example, you can decide whether or not to install Konqueror (I don’t), or whether you want Xine, Mplayer, Gstreamer, etc as a phonon backend. It’s hard to explain in context to those who haven’t used pacman, but the elegance of Arch’s package management system dawned on me a few weeks ago when I was using FreeBSD ports (which until Arch, I had always considered the gold-standard). I was installing KDE (make config-recursive), and it was pulling in all sorts of dependencies (Samba, Gnome-vfs, Mozilla Firefox) that I had no clue what they were being used for. While other package management systems have may have gotten lazy with their dependencies, Pacman still emphasizes minimalism.
It’s called yaourt.
“So you start installing the package using pacman and aur (…)”
That’s the first problem. You start using yaourt.
http://wiki.archlinux.org/index.php/Yaourt
Dependencies sometimes don’t work, but you only have to go get them, getting into dependency Hell, when the package in question is very broken.
You can always automatically build all those packages with yaourt.
Also, you can find bin32-wine and all its dependencies here: http://arch.twilightlair.net/games/x86_64/
The problem with your example above is that wine is a 32-bit app. and it requires a couple of 32-bit dependency packages. Since Arch 64-bit implementation is very lean, there are few (if any) 32-bit packages on it.
But like all of Arch, if you read the forums, you will get easy instructions, complete with community repos that allow you to install it in no time.
Wine32 dependencies are the same no matter the distribution (package name may differ, but same deps). Check on a Ubuntu, or Fedora and compare. But more important, why you want a 64-bit OS, to run a 32-bit wine, whith the extra 32-bit libraries, running side by side, taking double the memory?
Do you have more than 4 GB? Otherwise is a waste. Maybe a 32-bit OS is better for you.
Edit: typo
Edited 2010-01-12 15:41 UTC
0. bin32-wine is 64-bit; wine is 32-bit.
1. 64-bit WINE will not run 32-bit Windows apps.
2. If you have more than 3.5GB, or more than 2.5GB, with a good video card, 64-bit is very handy, even before its other performance benefits come in.
3. Why should anyone be dictated what OS they should run, to use multiple layers of 3rd-party unsupported software?
Wrong. Bin32-wine is NOT 64 bit of course (why would it be called bin32 then?) – it’s 32 bit with a wrapper for x86_64 Arch. As to your second point, I have bin32-wine installed:
[molinari@Helios ~]$ pacman -Q | grep wine
bin32-wine 1.1.36-1
and I’m happily playing Morrowind on it
The wrapping is the important part. Wine will generally not run, installed from the wine package (which you can make happen…).
All of the bin32 packages were 64-bit, last I knew. In a 32-bit system, there is no need.
Edited 2010-01-12 22:08 UTC
It may or may not be an Arch x64 bit problem. But what Arch really tells you (and other hide from you) is that when you install wine under a 64-bit Linux box, you end up installing a lot of 32-bit dependencies, most of them Xorg libraries.
While x86_64 processors can run 32-bit code side by side without penalties, when you launch wine, you are loading a bloat of 32-bit Xorg libs with it, which makes it less efficient than runing wine on a pure 32-bit system.
The link bellow compares the same ubuntu edition with 32-bit and 64-bit. You will notice that games do not gain much of a performance, but server and encoding software do benefict from the change.
http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&nu…
Like in my previous post, if you have more than 4 GB, or use some software that “really” use the 64-bit architecture, stay with a 64-bit Linux, otherwise a 32-bit edition is better for you.
And I’m not dictating, just telling some facts.
Edited 2010-01-12 18:15 UTC
There are tools like yaourt that will resolve the dependencies in the aur. HTH
This is perhaps the best description of Arch Linux. It brings awareness and transparency to its users. Whereas many other distro’s attempt to create an environment that is best suited for one or more particular purposes, Arch Linux provides you with the tools to design and build your own environment.
I am archer myself and I have a question, how do i ensure that latest updates are well tested and won’t break my system ? With a rolling-release, before you could fix something the next release/update is out and it could still be broken.. the point is, arch is not meant for someone who cannot fix issues for themselves. How different is arch from say debian testing/sid in terms of what to expect when one upgrades his/her system??
Simple answer: Don’t use the [testing] repo.
That said, it doesn’t completely avoid problems. But I’m highly impresses at the relatively small amount of breakage, and relatively minor nature of it, in a rolling release system that Arch has. It is orders of magnitude better than when I tried Gentoo a couple years back (Gentoo may have improved since then).
On the flip side, using [testing] and providing feedback helps get packages better tested.
Simple answer: Don’t use the [testing] repo.
That said, it doesn’t completely avoid problems. But I’m highly impressed at the relatively small amount of breakage, and relatively minor nature thereof, that Arch has in a rolling release system. It is orders of magnitude better than when I tried Gentoo a couple years back (Gentoo may have improved since then).
On the flip side, using [testing] and providing feedback helps get packages better tested.
Well, on the one hand, you just can’t ensure that packages are well tested if you want the latest stable release. As the arch devs say in the interview, arch catches lots of gotchas because the distro is an early adopter.
On the other hand, important packages ARE tested in the testing repo. And if something slips by, arch devs are very very fast in providing fixes. If you see an upgrade to a major component (X, kernel, etc.) you can wait a few days and monitor the forum for posts describing issues with the update.
And lastly, the best way is to join the testing team – which basically means enabling the testing repos, and writing useful bug reports.
That said, I’m in no way an expert. I look at a PKGBuild, and I have no clue about what I’m looking at. I’m not a programmer, my dayjob and my education has nothing to do with computers. I just got curious about linux some 7-8 years ago, and I just got stuck with linux. It suits my needs. And of all the distroes I have tried, including the major “well tested” ones, Arch still seems to be the most stable of all. Well, Mandriva was fairly stable, but Kubuntu has been a nightmare since Gutsy (you can’t get more UNTESTED than that), and the rest fluctuated in quality greatly.
So there are no insurances, but my experience tells me that these guys know what they are doing. And because of the simplicity, transparency, and clarity (staying as close to vanilla as possible) of the system, overall you get a very stable distro.
On 2 computers, I have installed Arch with KDEmod as a secondary. Arch is one of the distros to use if you like KDE4. Their KDE packages are clean, stable, and up to date.
On both computers, my primary OS is Windows. I still like that best for desktop computing – its graphical layer is just better than xorg with less advanced drivers. I like Arch as a secondary desktop OS because it allows you to experiment with Linux, and it boots up very fast.
For servers, I recommend Ubuntu server. Easy to install and administer. Arch just needs too much care if you are depending on a server, although if you have enough time, an Arch server could be quite interesting.
I wouldn’t unless you don’t mind having your system borked from an update.
My advice is to use FreeBSD or Cent. I’d trust either team over Canonical anyday. I’m still not sure of what Canonical’s 300 employees do most of the time. Foosball perhaps?
I’ve run an Arch Server for a few years now and find it needs very little care because once you set it up how you want it (which should be done at install time) all you need is the updates from the rolling release.
Furthermore, contrary to your reasoning, I’ve always ranked “easy to administrate” quite low on my list of requirements when choosing a server OS:
I’d sooner spend longer configuring a system, but have it streamlined for my specific requirements and understand the system from the ground up than have a server that took 10 mins to set up but leaves me scratching my head if/when things act abnormally.
Besides, as I’ve already stated above, a good administrator should only really need to spend the initial set up time and then use (custom) scripts to automate any lengthy or regular jobs to make future administration relatively easy (even on the trickier of systems).
Do you mean Ubuntu server LTS? Because regular Ubuntu, like other fast release based distros (yes, I mean Fedora) have a very short lifespan. In a work environment you don’t want an OS that you need to reinstall every year and a half because its support is over. In that escenario, the need to have the last version of everything is not important , but having securitiy fixes it is. So that either a long supported distro or a rolling one is a must.
So, for servers, are better suited:
Ubuntu LTS
Red Had Enterprise $$$
Cent OS
Debian
Gentoo (even better with hardened profile)
Arch (as a developer said, if you know what you are doing)
I personally used Gentoo hardened for over 6 years without having to reinstalled it. Can your Ubuntu do that?
Actually, I have used a Ubuntu server for some years, without reinstalling or package conflicts. And yes, always running the latest version of Ubunto. A release upgrade is not that hard.
I’m glad it has worked for you but I don’t trust Canonical after they have broken Dell Ubuntu desktops and notebooks repeatedly with updates.
If they can’t be bothered to make sure their updates won’t break their top partner’s hardware, then why would you trust your own hardware to them?
Edited 2010-01-13 04:36 UTC
Well, I guess I have more trust in the server edition of Ubuntu than in the desktop edition. It might have something to do with the fact that Ubuntu is largely based on Debian. The server edition is more stable, and less complex, and less modifief, compared to the desktop edition.
That’s why I like Arch on my desktop.
Gladly it worked for you. The problem with dist-upgrade is that there are so many big changes between the distribution editions that may bring all sort of issues, like configuration changes, packages that do not exist anymore, dependency changes, etc. By using a rolling system and updating frequently you will be able to isolate those problem on a one by one basis, thus making it easier to fix, and having shorter downtime.
Edited 2010-01-13 16:32 UTC
After trying many distribution, Archlinux was the distribution that finally made me give up completely on windows. I haven’t had windows installed on my machine since I started using ArchLinux. I haven’t touched or used windows ever since!
Arch is by far the best Linux distro IMO, but in terms of quality it still doesn’t match OpenBSD … once you use OpenBSD and it ports and package system which IMO is superior (in terms of consistency) than any of Linux or BSD release, you won’t want to come back.
I happily run Windows 7 and OpenBSD 4.6 … great combination … Windows for .NET development/Outlook (work), openbsd for other dev stuff (python, perl, ruby etc).
Horses for courses.
I too use OpenBSD and find its quality and simplicity refreshing. The tradeoff one makes (for “general” desktop use) is that the ports aren’t updated for a release (or, as of late, -stable) due to the fact that the devs there prefer to focus their time updating the ports for -current. In addition, the OpenBSD approach to security, openness of all code, etc. puts some apps out of reach (wine, high-performance VMMs, some drivers,…). If you need those things, OpenBSD is not really an option.
For what Arch does (rolling release) its quality is exceptional. I’ve been running it as a general-purpose desktop for a couple years with little (and typically minor), if any, breakage. The quality difference between Arch and Gentoo circa 2+ years ago (which I left in frustration before finding Arch) is a chasm measured in parsecs.
Another interesting (and spot-on, IMO) comment Aaron Griffith made in the interview is that he was worried about Linux getting more interdependent and intertwined. This worries me as well, as I don’t want Linux to become the wipe-and-reload-once-a-year-to-clean-out-the-mystery-problems mess that Windows is. I’m keeping an eye on NetBSD and DragonflyBSD in case that happens
Edited 2010-01-12 05:37 UTC
True enough. Performance has always been an eternal issue with OpenBSD as well. But that was not really the question here.
Well, while the quality of this “rolling release” methodology may be good, there are still breakages, as admitted by the team. I left Arch behind exactly for this reason. If there only would be a binary distribution that would be “rolling releases” but not bleeding edge.
Yeah, this was an insightful comment. And personally I think Linux already is largely that. By borrowing your cheerful expression, you already have to wipe-and-reload-once-a-year-to-clean-out-the-mystery-problems with things like Ubuntu and Fedora. Except that you have to actually do it twice a year
.
As the team also discussed, there is generally a great danger for distributions like Slackware and Arch Linux when more and more Windows registry-like *Kits and HALs are emerged as more or less necessary dependencies. Perhaps the big-name distributions have too much power on certain “upstreams”.
The complexity will bite. Mainstream Linux is more and more like Windows with all of its flaws, each passing day.
Edited 2010-01-12 06:04 UTC
Maybe because it’s development model is more server oriented than desktop. Want to run a BSD desktop, go FreeBSD.
What’s the biggest challenge facing the overall Linux movement today? What’s your prescription for addressing it?
Aaron Griffin: Attitude. People have crazy attitudes about Linux and free software in general. Some people act like it’s some sort of holy grail that’s going to save us from global warming, swine flu, and World War III. It’s just software. Get off the high horse.
This is one of the most intelligent statements I have read in a long time.
I would like to add that his opinion is valid for software industry in general (Other operating systems, web browsers, word processors, etc).. It’s just software.
Edit: typo
Edited 2010-01-11 20:24 UTC
This is what I don’t like about Linux:
What part of the Arch Linux development is the most active?
Thomas Bächler: Definitely the package update monkeys.
Allan McRae: Packaging.
Aaron Griffin: Packaging is by far the most active part, followed closely by Pacman development.
A total waste of man-hours. Windows and OSX are much more efficient in that the developer builds a single package and it’s ready for use.
They seem like a competent team but good lord why do all these people want to work on building packages for yet another general purpose distro? My god so boring.
Edited 2010-01-12 06:05 UTC
I don’t know what you do with your time but it’s likely a lot of people would consider it a total waste of man-hours. Similarly you might consider whatever I do with my time a total waste of man-hours as well.
The important question here is whether Arch provides something other distros don’t. IMO unlike a lot of distros it does.
As the devs say in the interview, wheels do get reinvented from time to time. So be it. On the plus side we end up with a huge choice of distros to play with til we finally find one that fits us perfectly.
Unlike the Windows and Mac OS worlds Linux users have choices. This is a good thing.
I’m not an Arch user but I’ve nothing but admiration for this distro and the people who make it.
It’s not a question of one’s hobbies, it’s a question of whether or not it makes sense to have distro teams spending most of their time preparing packages when there is a common goal of greater improvement.
There’s a surplus of general purpose distros that don’t do anything to distinguish themselves over the others. Most of them might as well be theme packs. You said you liked arch linux because of quality but that is what everyone says about their favorite general purpose distro.
That’s very true, especially true of the plague of *buntu-with-a-different-wallpaper distros. I’d say Arch does distinguish itself very well with its KISS philosophy, rolling updates and relatively vanilla packages.
While someone who’s purely an end user might not notice the difference between Arch and another distro (they might not even notice the difference between KDE/Gnome/XFCE/etc) your average OSnews reader should appreciate the differences under the hood.
Actually, for FOSS this methodology makes perfect sense:
* nobody knows the distro better than the developers behind the distro. So it makes sense that nobody is better qualified to build distro targeted packages than the distro maintainers
* You can’t expect application developers to build dozens of packages for every single distro out there. They simply don’t have the time nor the motivation. So instead they should be concentrating on making the application itself as complete as possible
* If you expect application developers to build the packages, then you’d find some distros would lack basic applications because the application developers happen to dislike some distros thus give said distros lower priority in packaging.
* FOSS software doesn’t just run on Linux. There’s *BSDs, OpenSolaris and even a few non-*nix OSs out there that also run FOSS software. Are you seriously going to expect application developers to port to every open source platform including ones that they’ve never even run, let alone have development experience of?
The difference between Windows and Linux is windows does not provide any kind of package downstream – so MS are effectively washing their hands of any responsibility and expecting:
* the developers to build their own deployment packages (thankfully there’s numerous tools out there to assist)
* and the users to have enough knowledge to differentiate between safe packages and malware.
Sometimes the Windows model works – sometimes it doesn’t. eg:
* the icon mess on the desktop, start menu and quick launch,
* the way how standards (like where application profile settings are stored) change from one application to another)
* the fact that I have to spend as much time googling applications to find download links as I do actually installing the application.
So as much a waste of man-hours as you might perceive it – I’d always prefer the OS maintainers to control the package deployment any day (and just so long as I have the option to override their catalogue should the rare occasion occur that I need to)
Edited 2010-01-12 13:52 UTC
Well of course I am not suggesting that application developers build for every distro. There should be a move away from the shared library system or at least a standard library base that distros follow.
It also runs on Windows and OSX and yet in those cases only needs to be built once and the binary will work for the life of the OS.
This isn’t even a legitimate complaint given how easy the deployment wizards have become.
That is a problem that doesn’t require the shared library system to solve. You can have a safe repository of any type.
It’s also the model that OSX uses and it has far fewer headaches than ye old shared library system. Applications still break in Linux from library updates which typically requires command line meandering to fix . That’s unacceptable for the general public.
The benefits from the shared library system such as a safe repository and application index can easily be added to an independent library system along with significant productivity gains.
But don’t worry most people in Linux land are like you and defend ye old shared system that was designed to save hard drive space in an era when gigabyte drives didn’t exist.
Arch linux isn’t really just a general purpose linux. It’s base install is very compact and runs pretty well as an embedded system. Shared libraries allow different people in different locations to develop the software. This is mandatory for small developers without an army of programmers. Many of us don’t even consider large gigabyte drives useable and only use little flash drives for the system.
I could say the same thing about Slackware.
The shared library system isn’t needed to allow that.
Oh give me a break, even 8 gig flash drives are cheap these days which is plenty of space.
And a good number of Arch users are ex-Slackware users.
However there are also a number of key differences between Slack and Arch (which is why some people like myself switched).
Edited 2010-01-12 20:46 UTC
When was thew last time you tried running Win7 or Vista on 8GB? Not really sure about that for MacOS, but there really aren’t any embedded mac’s aside from ipods and iphones
That’s an irrelevant question. The fact that you can install Linux on an 8GB drive is not due to the shared library system. It comes from being able to strip the system down to the components that you want.
You can also install PC-BSD on an 8GB drive and use the pbi system which doesn’t use shared libraries.
But then you lose the whole point of different distros.
Different developers and users prefer a different model of package deployment. Hense the reason ArchLinux exists in the first place (I trust you read the interview?)
You can distribute Linux binaries too – so in that respect, Linux isn’t much different to Windows.
It’s just there’s usually little point in distributing stand alone binaries as package repositories do all the leg work for you.
That makes little sense. A repository /IS/ a shared library system.
Plus I thought you were arguing that you don’t need safe repositories….
Now your talking about a completely different topics.
(plus repositories / package managers SOLVE dependancies issues which often break systems rather than causing them as you suggest).
The command line dependancy has nothing to do software repositries what-so-ever!! (and more importantly, 99% of the time you don’t need to touch the command line – it’s just many experts advice users to dip into it as it’s quicker and easier to list a number of commands to run than take screenshots of the GUIs that need to be used.
Most linux distros give you the CHOICE of using a command line or a GUI. You DONT have to use the command line, but sometimes it’s just easier to explain on a forum than trying to navigate someone around various windows and menus.
So what you’re suggesting is to replace one software repository with another!?
Plus you’re still missing the point that sometimes packages need to be tailored specifically to that distro.
Software repositories have nothing to do with disk space savings!
Do you even know how they work? Have you actually ever used a package manager?
They exist to centralise applications, automate deployment and ease system administration.
ArchLinux could use as much diskspace as Windows if you wanted it to. It’s just many ArchLinux users don’t see the point in installing surplus applications that they’re never going to use.
I don’t want to get into a platform war (you like what you like and I like what I do) – but please at least understand how a system works before attempting to draw comparisons.
I said at least provide a standard base that distros follow. Anyways most of the distros are completely pointless. It makes more sense to have an OS that is modular in design that can modified for a variety of purposes while maintaining binary compatibility.
You’re being disingenuous. Linux is much different to Windows AND OSX in that regard since you can’t build a single GUI executable and expect it to to work across all distros for a reasonable amount of time. The Linux ecosystem is designed with the assumption that user software is open source. If the goal is adoption by the public then it doesn’t make sense to design the system completely around open source.
The binary compatibility across Linux distros that exists is for small command line programs, and even then it is limited since the distros can’t even agree on basics like where user programs and settings should be stored.
In the Linux sense of the word. By general definition a repository is storage system. You can store safe executables for the user to download. There is no reason why this must be a feature exclusive to shared library systems.
No I’m not, it’s all a part of the same problematic software distribution system. Package managers attempt to resolve dependencies but applications still get broken by updates.
Here’s the genius shared library system at work:
Skype broken after KDE update:
http://fedoraforum.org/forum/showthread.php?t=233354
I said that going to the command line is typically needed to fix dependency breaks.
Here’s an example:
http://itechlog.com/linux/2008/12/18/fix-broken-package-ubuntu/
Explain how the last example problem could have been fixed with the GUI.
One that makes more sense.
I’m missing the point even though I already went over this? How long did you spend reading my response? 10 seconds?
The tailoring wouldn’t be needed if the distros had a common library base and directory structure.
There are other options including a standard common language interface, binary compatibility layer or even a VM solution. But shutting your brain off and defending the status quo is probably the worst option.
The shared library system was designed in a completely different era when saving hard drive space was a priority. That is no longer an issue and now the remaining benefits can be adopted within an independent system where applications can have their own libraries that can’t be broken by a system update.
Trying reading my response more carefully next time instead of just skimming it and providing a knee-jerk response. It isn’t a Windows vs Linux issue. It’s a software engineering issue. Apple’s engineers decided to ditch the shared library system so maybe you should at least question as to why.
Edited 2010-01-12 19:00 UTC
Err, Linux IS modular in design and can be modified for a variety of purposes while maintaining binary compatibility.
You can. I’ve already stated that. Stop trying to spread BS.
The problem with Linux (if you can call it that) is that it’s a rolling release – so where as in Windows, you have a major release every 3 to 5 years (on average), you have lots of minor releases in Linux.
Sometimes these minor releases will break things. But then I’ve had service packs break Windows too – let alone whole OS upgrades break apps.
So yes, Linux binaries won’t work indefinitly – but then neither will Windows binaries.
Again that’s absolute BS. It makes no difference whether the source is open or not.
Plus ArchLinux and all the big user-centric distros push binaries out via their repositories. So the users never need know the source code was optionally downloadable.
Again that’s completely rubbish.
You do realise that there’s plenty of large closed source apps available for Linux? VirtualBox (not the OSE but the more feature-rich edition) is closed AND has a GUI. And given the complexity of virtualisation, I’d hardly define that as a small command line program.
Right, I get you.
You still don’t get it. The package managers /DO/ resolve the issue. Sure, there’s occations when things still go tits up. But then that’s the case with EVERY OS.
Operating systems are infinity complex – so sh*t happens.
However, try and manually resolve dependancies in Linux (rather than using the “problematic software distribution”) and I bet you’d instantly run into troubles.
So trust me when I say that package managers have made life a HELL OF A LOT easier on Linux.
That link has nothing to do with your arguement (it’s details on how to fix a package that corrupted on install and nothing to do with dependancies).
But for the most part they DO (and those that don’t, don’t because of very specific reasons and usually the same reasons why they forked to start with)
Personally I like the fact that there’s lots of different distros. Sure it complicates things, but at least I get to run the system I want without compromise.
While I get what you’re driving at – this is never an issue for the home users as package managers are bloody good these days. So I still think you’re massively overstating the problem.
Sure, the devs at ArchLinux (and other distro devs) might get fed up from time to time.
However they’re the ones in the position to make the change (as bad as it sounds – it’s not my problem, it’s theres. So I’ll invest my spare time developing solutions to problems I encounter)
Your initial post used Windows as a comparison and it’s just continued from there.
That’s why I said OS, as in a full operating system, not a kernel. The problem is that there isn’t binary compatibility across distros that use the Linux kernel.
No one expects Windows binaries to work indefinitely. However you can expect them to work for the life of the operating system. Both Windows and OSX see the value in offering developers a stable platform. With Linux you can’t even expect them to work between minor updates.
I was talking about user software. The software distribution systems are all designed around open source. You run into massive headaches when you work outside that system. Not just through distribution but because the distro clusterfu*ck is dealt with by releasing the source and having the package managers downstream account for the differences.
There are closed source apps available for Linux but the companies that produce them still have to account for all the differences. Companies that release a single tar file are hiding all the “poke in the dark” scripts that have to be built to deal with all the distros. Even if you release for a couple distros you still end up building multiple binaries.
Opera’s Linux section shows what supporting multiple distros really looks like. Note that some distros have multiple packages for differing versions.
http://www.opera.com/download/index.dml?platform=linux
As for VirtualBox it is open source while VMWare is closed source. VMWare has in fact been broken multiple times by updates.
http://www.netritious.com/virtualization/fix-vmware-after-ubuntu-up…
I think, for the most part, we’re going to just have to agree to disagree on this one.
However one item I can categorically prove is VBox.
Past discussion:
Response:
See the following link and scroll down:
http://www.virtualbox.org/wiki/Downloads
^ as I clearly stated, there is an OSE (open source edition) and a closed binary.
The closed binary has more features than the OSE and is the version people typically use when downloading outside of package managers (which leads to incorrect assumptions – like yourself – that they’re using “open source”).
Furthermore, I think you’ll find that many of VMWare’s products are open source as well:
http://www.vmware.com/download/open_source.html
(though I’d wager the licence isn’t as “open” as GPL/BSD – but that’s just a guess based on their previous business model)
Edited 2010-01-13 07:57 UTC
??? The same thing gets done for those platforms. Have you never used a ports system on OS X, or various native FOSS ports? They get OS-specific packages, just the same.
It’s no more efficient. It’s just less work due to using more popular platforms.
No I haven’t used a ports system on OSX because it isn’t the main method of software distribution. I’ve found everything I needed at Softpedia.
Apple wisely ditched the shared library system in favor of application independence. The MacPorts project is a community effort to make compiling open source Unix utilities easier for users.
There *could* be greater compatibility across distros just as there is compatibility across different versions of Windows. Even if the distros followed a very basic common library that would cut down the repackaging time immensely. It’s an inefficient system from a software engineering perspective. Even if Windows and OSX didn’t exist it would still be inefficient since there is so much redundant work.
While Arch is a little more difficult to install than other distributions, its simplicity and lean design can make wounders.
For example, by using a Gnome LiveCD (fedora, ubuntu) , the installed system ends up with a lot of packages, dependecies that some users may not need (or want). Sometimes, those packages can be uninstalled, but sometimes they can’t without breaking dependencies. Many of those non wanted apps consumes both hard disk and ram space. For example those 2 distros end up with a desktop with a normal RAM usage of 300MB or more.
I installed a Gnome desktop on my laptop. I limited myself to either C/C++ or Phyton apps. I had no Banshe, Tomboy, F-Spot mono apps. I had no search backend because I can track my files on my mind fairly well. What I do was replace the Arch network script with NetworkManager (for the laptop wired and wireless adapters), And my ram usage end up slightly over 100MB.
I used to be an exclusive Debian user, until I got sick of some of Debian’s flaws and decided to try Arch. I’ve been using it ever since on my home pc (which is actually an Alienware m17x notebook), on my Asus Eee PC, and on all my VPSs (four).
I disagree with the guy who wrote Arch gives dependency hell a new meaning. First of all, dependencies were one of the most annoying things that made me move off Debian. Arch’s package management system (pacman) is way, way better, and the AUR is a fantastic platform.
Not only does Arch have many, many binary packages, you can find most linux applications in the AUR and easily install them from source. True, at times you’d find some packages in the AUR with an outdated or even broken build script, but these are mostly not the massively used apps out there. Wine is kind of an annoying exception, I tried to install it once on my x64 machine with bad results, but I really don’t need it.
Plus, I’ve always tried to build packages in Debian and found it almost an impossible process. Building packages in Arch by yourself is easy.
Besides the great package system, I also really like how Arch made configuration easy. Not only the system’s configuration, but also package configurations. Just installing a simple. lightweight web server like lighttpd on Debian can have you trying to find out what the hell all those configuration files are for. Arch, on the other hand, usually comes with one easy to understand and modify conf file for every app, with great default values.
Performance is also great, and I love that fact that I am not forced to install an outrages list of applications the come with every desktop environment, or even entirely create my own setup (on my Eee, for example, I have a very lightweight setup).
Anyway, the thing about linux distributions is that every user can find the distribution that is most comfortable for them. I hate Ubuntu. I really do. I tried it a few times, had no idea how they managed to take Debian’s already flawed package system and make it even worse. At least in my opinion. I do appreciate, though, the extensive documentation the project has written for various applications, problems, scenarios, etc. They did a great job there.
I know the basic differences:
bash vs python
precompiled vs source
But what are some other reasons why someone might choose arch over gentoo?
Personally, I enjoy seing the code compile, makes me feel like my computer is actually doing something useful.
Depends on choice. Both are light, and fast. And each one has it’s advantages over the other.
For me personally, got tired of compiling Xorg and KDE everytime an update shows on Gentoo’s portage. But still recommend Gentoo with hardened profile for server (no gui btw).
Edited 2010-01-13 16:47 UTC
Dan McGee: “Signed packages are super important and are targeted for the next major pacman release.”
This is great news. I’ve always been attracted to Arch Linux, but there have been some buts related to it still being a relatively small hobby distro lacking the security and reliability of some bigger distros. A major concern has been that there have been no way to guarantee that the Arch repositories are really safe and not hacked and maybe having malicious software. I’m glad that Arch developers are now finally ready to do something about this too:
http://wiki.archlinux.org/index.php/Pacman_package_signing
http://bugs.archlinux.org/task/5331
“Instead, advanced users will appreciate a simple build system based on GNU Bash: A language they are most likely familiar with contrary to other systems using custom languages like RPM spec or python-based portage.”
The fact that portage is written in python has as little to do with an accessible build system as the fact that pacman is written in C. The public facing parts, the eclasses and ebuild-helpers as well as the ebuilds themselves, are written in bash.
Yes, Gentoo’s ebuild format does have a somewhat higher learning curve than Arch’s pkgbuild. But that is because there is more abstraction into custom functions. But this is very convenient once you have picked up on the conventions and available functionality. The kind of users who would start hacking ebuilds should have no problems to do so. You don’t need to be a programmer, I’m just a hobbyist myself.
Some of the guys in the interview, especially Thomas Bächler, sounded pretty damn snarky. Which is one of the reasons I never cared for an otherwise interesting distro. Arch sounds good, but damn, don’t ask them any questions–you’ll just get “read the docs first” or “read them better”. And then there’s some guys who clearly believe that it does everything 100% perfectly. 😐
I’m interested in Arch, but it’s their attitudes that keep me away from their distro. Plus, the fact that I usually have some kind of problem, but I don’t dare ask at their own forums at risk of being told the equivalent of “RTFA again and f*** off.”
Edited 2010-01-14 01:07 UTC
UZ64: Read the beginners guide: http://wiki.archlinux.org/index.php/Beginners%27_Guide
Edgarama: You think I didn’t already? Come on, seriously, you’re just confirming the Arch mindset of “STFU and RTFM” I’m complaining about. 😐
Arch isn’t trying to be the distro for everyone. It is not a hand holding distro. It allows you to make a basic installation, then you build it up from there.
The wiki is great, especially the beginners guide. Check forums for solutions to any problems the wiki might not have helped you with. Then post on forums if you couldn’t find any solutions. You however need to demonstrate that you have tried to solve your problems first, list what you have tried, then ask nicely with petinent info regarding your problem.
I am a recent convert from Ubuntu, installed first onto my Aspire one, then on my main desktop system. All from reading the beginners guide. YMMV.
Again, Arch may not be for you.
Edited 2010-01-14 18:44 UTC
nice questions/answers