Slashdot Mirror

You've never seen the Arch Wiki, have you? I swear, it's the most helpful documentation I've ever read, and some of it's tips can be used for other distros as well.

"If I would have asked my customers what they wanted, they would have said 'a faster horse'." -Henry Ford

I agree that Unity isn't exactly a step forward, more like a side-step, but you can't blame them for trying to innovate. If "The Year of the Linux Desktop" is ever going to come around, it won't come around by imitating the competition, but trying to be better than the competition. It might take a while to get there, but every competing effort helps.

Also, Arch Linux is a distribution full of tweakers and minimalists; the type of people you'd expect to dislike GNOME 3. Well, here's a forum thread on the Arch BBS asking for first impressions of GNOME 3, and the average opinion is very positive. Of course some users have complaints and gripes, but that's to be expected. Quite a few of the people that don't like GNOME 3 are either trolls (as evidenced in the thread) or have very, very precise workflows and can't fit them into GNOME 3. Seriously, try it for a week with an open mind, read the documentation and tip guides, etc. and you might like it! I know I do :)

I run my recently upgraded desktop (Core i5-2500K) through a power meter and it is very easy to notice - Ubuntu 10.10 (kernel 2.6.35) idles at about 30W, while 11.04 (2.6.38) goes up to 35W. That's about 20% more.

I believe 2.6.36 introduced a problem with DRI on intel and some other video chipsets which led to a shitload of kworker wake ups. One of my laptops running Arch benefitted from a kernel parameters suggestion over here but by that stage I had a menu.lst as long as your arm full of attempts at a functional system (e.g. kernel ... nohz=off highres=off pcie_ports=compat...) each with small, incremental improvements.

You can't catch every regression without owning all hardware and infinite time :)

He's trollin'. If you're using a reasonably usability-oriented distro (e.g. Fedora, Ubuntu, Mint), you'll have virtually no issues. I've got a Toshiba Satellite lappy from 2010 dual-booting Win 7 (since I've already paid for the license) and a Linux partition I've tried a few distros on (Ubuntu, Fedora, Arch and Debian in that order for at least 6 months each). The only one that was even a little bit difficult to get up and running with was Arch, but that's really by design.

Windows 7 on the other hand (while certainly a step up from Vista) has given me some real grief the few times I was had to use it for work. Now admittedly, this has not been a matter of hardware drivers (on both Linux and windows my video and wireless drivers had no problems). Rather, its a matter of going back to Windows after experiencing Linux and realising how much it sucked. Software you install can just stop working on you one day, every other program seems to want to gobble up resources with its own updater application, and I'm really genuinely irritated by the lack of any good terminal emulator. I want to encode some video with mencoder? The program runs fine, but using CMD to get at it is a royal pain.

Yeah, I found the "twinview" issue on a lot of Linux games - indie or not.

Does anyone know of a way to lie to the games as to what the desktop dimensions are? I've used google before without much luck on the matter, but hopefully this crowd can point us in the right direction.

Yet again, the Arch Wiki saves!

Only an hour left here of the 1st. One article appears to be new news the rest make it look good.

Though The Canterbury distro is just terrible
http://www.opensuse.org/
https://www.archlinux.org/
http://www.debian.org/

Can you imagine the holy wars at least 3 different packing systems 4 different kenels and everything from stable to sid all in one distro.

Didn't you hear that debian, openSuSE, Arch, Grml and Gentoo are merging?

http://www.debian.org/
http://www.opensuse.org/
http://www.archlinux.org/
http://www.gentoo.org/
http://www.grml.org/

Here is the cry for help I issued on the Arch forums. I didn't really expect any help, since the Catalyst drivers were exiled to AUR. For good reason it seems.

Anyways, if you see any clues I missed, or if you know of a better place to ask for help, please let me know.

When using the Arch build system, source is downloaded directly from upstream, any alterations (patches, build flags, et cetera) are made according to the PKGBUILD file (here's an example I was just looking at in another tab: unetbootin's PKGBUILD.

This wiki page provides a good overview of the process.

When using the Arch build system, source is downloaded directly from upstream, any alterations (patches, build flags, et cetera) are made according to the PKGBUILD file (here's an example I was just looking at in another tab: unetbootin's PKGBUILD.

This wiki page provides a good overview of the process.

SPI is the official sponsor of the Debian Foundation and Arch takes donations. Canonical makes some money off of FLOSS, but is not making a profit yet.

I'm not a huge fan of Canonical, but this argument over modifying an open-source application is silly. (In addition, Canonical contributes a good amount to FLOSS given its size, though not necessarily to the kernel itself -- Launchpad, U1 client, app indicators, and Unity are just recent examples.)

If by "platform specific binaries" you mean the 32-bit packages are optimized/compiled for i686, that is certainly true - but really, who runs anything older than a Pentium Pro these days? And now I'll probably get a reply from someone still on a 486; but my point is, the vast majority of PCs still in use are at least i686-compatible, as such it doesn't make sense to have 386-optimized packages.

Not to mention that if you really wanted to, you can use the AUR to get a different kernel if you want. Example: Fedora's kernel. I'm actually surprised there's not a kernel26-386 package, but I guess even Arch users aren't that crazy ;)

If by "platform specific binaries" you mean the 32-bit packages are optimized/compiled for i686, that is certainly true - but really, who runs anything older than a Pentium Pro these days? And now I'll probably get a reply from someone still on a 486; but my point is, the vast majority of PCs still in use are at least i686-compatible, as such it doesn't make sense to have 386-optimized packages.

Not to mention that if you really wanted to, you can use the AUR to get a different kernel if you want. Example: Fedora's kernel. I'm actually surprised there's not a kernel26-386 package, but I guess even Arch users aren't that crazy ;)

Fixed that for you. Many distros, such as Gentoo and Arch, follow a BSD-like philosophy of "make the best distro we can".

Come on, Arch developers don't give a damn about it's users. They just like to tinker - that's all. Here I quote Allan McRae, leading developer of Arch package manager:

‘I think I know every distribution using pacman as a package manager and (unless there is an enterprise level distro I am missing) if peoples lives depend on one of these distros, then I am sorry to say it but in my opinion they are stupid and deserve to die.’

“I am responsible for nothing. I only choose to pull together the package signing patches in my spare time Contracting my services would actually motivate me to implement this. My standard consultancy rate is USD1000 per day or part thereof Minor performance issues interest me a hell of a lot more than package signing.”

I would recommend Arch Linux ( http://www.archlinux.org/ ) if you are comfortable with installing from a text interface and partitioning your HD yourself. I have found Kubuntu to be a bit rough around the edges when it comes to the KDE implementation where as Arch has been rock solid for me. Arch also is bleeding edge so you can enjoy 4.6 right now without PPA. Just a suggestion. Perhaps Arch will provide the best KDE experience since you are trying it again after being away for a while.

Not to be posted toward anyone in particular, but being as this /. is about a change to Ubuntu, I'm sure there will be a plethora of posts regarding how inept they are at dealing with the changes or questioning why the change or etc. The real question is why bother ever complaining about something that was free. If you don't like it, you can always get your money back (credit +$0). If you really don't like the way a distribution is going or have a problem of stability or security of one thing verses another, then by all means do it yourself. If you want something the way you want it, then do so: LFS, Gentoo, or ArchLinux

Similarly, I run Arch Linux, and have found its rolling release to be at least as bombproof as Ubuntu's cadenced release. The difference is simply that your upgrade cycle happens at a time when you and the individual program developers are ready for it, and you can be as selective as you like.

If the parent wants a server, he could do worse than install Slackware. For many years I used this as my desktop distro (now I use Arch), but for servers Slack kicks ass. It is so simple to set up and maintain, you don't need to pay for support unless you are lazy or clueless.

One thing I'm curious about is the kernel configuration these guys used - I couldn't find it. Unless they built the kitchen sink into the kernel in the first place, I find it difficult to see how they could have used the same .config for that many builds.

Until a year or two ago, I used to be an inveterate kernel stripper; any driver or service that wasn't used or supported by my hardware got ruthlessly taken out. This did leave me with more responsive machines at the minor cost of my time. More recently I have become lazy, and I have adopted the default kernels that come with my preferred distro; now that I am no longer at university, I'm not pushing my machines as hard with molecular modelling as I used to.

Really, the ease of compiling packages from the Arch User Repository is what makes Arch Linux so nice. Download the tar.gz, extract, and run makepkg.
In fact the new 2.6.36-ck kernel is already in the AUR/

I'm not sure what the GP is referring to - I use Arch as well, and the process is quite simple. Actually I find that rebuilding packages with Arch is about as easy as it can be, the ABS/makepkg-combo works very well. And although Arch is very much bleeding edge, if one is very impatient and a new version of $APP has been just released, upgrading can be as simple as changing the version number in the PKGBUILD and running makepkg.

Getting Linux into users hands with convenient, easy-to-use installers, providing support, etc. = Not Valuable

I can see how this might be a perception, but it's not reasonable. Lots of good C programmers are quite poor at systems administration. Maintaining a distro can be a horrible task, since you are essentially being sysadmin for a completely unknown system. The situation is made worse when programmers who write the source code you're implementing capriciously change things around (or break them) for no beter reason than to fit some trendy philosophical notion of how it should work.

I once went down the path of Linux From Scratch, and the experience was a worthwhile learning for a single-purpose system. But doing that for a desktop box is just stupid, since it's just too much work to keep all its components up to date. Now, Ubuntu is emphatically NOT my distribution of choice (that is currently Arch), but anyone who is prepared to undertake the task of maintaining any comprehensive distro long-term deserves a round of applause.

It's also called "GRUB with blocklists"

You can find more here,
and in my other post

http://www.archlinux.org/packages/core/i686/kernel26/

Patched on 8/13, new kernel package on 8/14. I'm not concerned. And slower-updating distros generally have a security team to patch these kinds of things into their current kernel release.

I really, really wish people would stop comparing Apt and RPM, the actual comparison would be dpkg vs RPM. And just as pretty much nobody uses dpkg directly, the same applies to RPM. People use one of the various frontends (yum, urpmi, what have you). While at one time automatically resolving dependencies was godsend, it's nothing special now.

(I'm quite impartial to the debate, pacman is where it's at. It would be nice to see an actual apples to apples comparison for a change though)

There is also KDEmod, which I'm told is an even nicer way of enjoy KDE on Arch. I haven't used it myself.

Debian patches are usually kept to a miniumum, as long as upstream is still active. (Debian has become the de facto upstream for some packages, including a few GNU packages.)

The most common changes include adding a manpage if one does not exist, and tweaking the install paths so the system conforms to the FHS. Now sometimes larger changes do occur, but usually that is because upstream has not yet accepted the patch, or is sometimes a cherry picked back-ported patch from the development branch, but we try to keep these to a minimum.

Let us look at Debian's apache2 patches for an example.

[long list of patches that are neither manpage additions nor tweaks to install paths]

Things like "[preventing] a buffer overflow attack on the htdigest executable" clearly should be dealt with upstream, imo. Granted, I'm an Arch user, and thus used to getting "report it upstream" as a response on every bugreport (OT: Arch has 9 patches for apache on my count, which is still more than I'd like).

I went for straight arch since I had an internet connection. I read that chakra will not be compatible with arch when their final release is out and did not want to be stuck on a smaller distro.

It is definitely a different experience and chakra's live cd worked so well I was surprised at how difficult arch was to get going.

I have to read up on abs or ports to get the latest kde beta since there does not seem to be a repo for it.

http://bbs.archlinux.org/viewtopic.php?id=97899

I finally got network manually up and am trying to get networkmanager working so I can go back to having a secure wireless connection (I turned off wireless security and have my router only excepting specific mac addressed.)

You can either install Amarok 1.4 directly (I use Arch, and there's a pkgbuild for it), or use one of the forks that are around. I am aware of Pana and Clementine.

True, but I always did do a lot of hand-compiling on my Slackware boxes. The thing is, Slackware offers a great platform for tearing stuff down and tinkering with it, while leaving enough of a world to stand on while you do so. I used Slack on my desktop systems for many years (from 1995) until I discovered Arch, which is similar in everything I like about Slack, but with a more powerful package system.

But Slackware is still my preference for any kind of server. It's so simple, I can set it up from bare discs in less than 30 minutes.

Sorry, but if you use Arch Linux and you don't know about AUR, you are missing a very good tool. There's a PKGBUILD for resynthetizer right here: http://aur.archlinux.org/packages.php?ID=6823

It's in the AUR as a package for Arch. I don't even use Arch and it took me thirty seconds to find this. It's the very first page when you Google for "arch linux resynthesizer." You want to be 1337 "cause I use Arch?" Learn to Google.

I don't like my desktop at much higher resolution than that, it becomes uncomfortable. I know gamers and drafters really want giant screens at massive resolutions, but besides them who else really wants it? 2560x2048 resolution doesn't exactly help me see my web pages or documents any better - in fact it can make them downright hard to see, so why do I need it?

If switching to a higher resolution makes things harder to see then you're probably doing it wrong. The main benefit of using a higher resolution is reduced aliasing (aka "jaggies").

Font sizes measured in points should display the same size regardless of what resolution you use. Make sure your OS is taking the physical size of your monitor into account. If you use X, try adding a "DisplaySize" to xorg.conf.

An interesting aspect of the submission is the claim that Fedora has double the number of installations. I find that a bit hard to believe, given what I've read in so many forum posts over the last few years. Just to be clear, I am not self-selecting here: my preferred distro is Arch Linux, but by far the majority of posts I have seen come from users claiming to be using *buntu.

The problem of ISPs distributing broken routers which manage to advertise a prefix which they aren't ever issued with? Perhaps you aren't sure yourself, since you haven't been able to name one router which exhibits the problem, but you're not making it clear what actually goes wrong and why the solution isn't to fix the problem (of distributing broken routers) rather than one huge bureaucratic bandaid.

Because the whitelist is feasible? The alternative is to break connectivity for (according to these folks) .8% of users while those broken routers are fixed/replaced.

Besides which, without v6 content, there is no reason to fix broken hardware. And if the broke hardware isn't fixed, content providers won't roll out v6. It's the same chicken-and-egg problem v6 has been stalled over for years. The difference is, this whitelist solution actually has a chance of fixing it.

If you regard negotiating with every ISP as "voila... problem solved", you are more engineer than the real world will allow for.

If the guys running the whitelist are willing to go through that effort, who cares? Does it solve the problem? Yes. Is it complicated? Certainly. But at least it has a chance of succeeding.

I've already heard many people whine about IPv6 slowing down their machine. It's usually to do with a small amount of time wasted by failing at looking up an AAAA record before moving onto the A record, and nothing to do with finding an AAAA record and trying to access it. The AAAA lookup, as far as I can recally, happens when the system supports IPv6 rather than only when the system has a routable IPv6 address, which is daft.

Yeah, agreed, that's definitely an issue. In fact, glibc used to do that for a long time (fortunately that issue is fixed... I believe now it only attempts AAAA resolution if the host has a routable v6 address).

And I certainly agree with you that there are likely *many* reasons why advertising AAAA records has caused headaches for end hosts, not the least of which is broken v6 stacks (as previously alluded to). But broken routing is, at least as far as I can tell, a well known issue with v6, and I really can't blame the content providers for attempting to search for a solution to this issue.

I suggested that the ISPs aren't being honest about why they want the whitelist.

So what do you think the real reason is? Either it's to fix v6 connectivity issues, or there's some other reason. Why do you propose that reason is?

If I'm Joe provider, I can return AAAA records if you're using my DNS server via IPv6, or A records if you're using it via IPv4. And, if I'm an ISP, I'll send the customer appropriate A-sending or AAAA-sending server addresses depending on how you're connecting, without you having to worry. Why will this not happen, unless you don't want it to? I need more information.

Probably because there's *still* some OSes that don't support DNS resolution over IPv6? Heck, even glibc is known to have issues with this configuration.

I don't think Google or NetFlix are stupid - I think they're top performing businesses. Why would I therefore assume that their solution to a problem is the best solution for anyone but Google or NetFlix?

Well, if you have a better idea, let's hear it.

Ubuntu, Fedora, particular LSB release might be a platform, but still, it's too vague for games.

Wait, what? Ubuntu is "too vague for games"?

WTF do you call "XP or newer" then?

And frankly, there seem to be plenty of games which work well across many platforms, even without relying on things like LSB. Games from years ago still work. Just what is it that's so different about desktop Linux distros?

Well, making something "work" and making something "work out-of-the box for dumb user" are pretty different things.

You can do compatibility testing with XP SP3, Vista SP1, Win7 to make sure that game runs on each of those (sometimes you need hacks, too). With Ubuntu, you may make much less assumptions.
Realistic option is to stick to particular Ubuntu release (perhaps an LTS one) and only declare support for things installed from Canonical-supported repositories. The other option is just not to support anything at all and let user figure out things himself/herself.

What's so different about Linux distros? Well, weaker backward compatibility between releases (some distros have no well-defined release at all). You will have to link statically as much as possible (to minimize damage of incompatible or just newer libraries) and you are still facing problems like significant driver changes that break sound or video for you.

Those games that work between distros... well, good for them. But do they work right after unpacking/installing or do you need to find things like older libstdc++ yourself?

with binary NVIDIA drivers - there're no other options currently

The binary ATI drivers don't work?

May be, I haven't really tested (haven't used ATI with Linux for ages). I was making comparison mostly to that new "nouveau" thing which is gaining popularity.

set "realtime" priority for our process

Do you actually need that? Or would it work to simply give you a non-bloated system with an intelligent scheduler? I run plenty of games without realtime that seem to work well, and it's nice to know that if they freeze, my system won't.

Well, this was just an example. Actually, setting realtime priority is discouraged by Microsoft as well, but I wanted to show that developers need much more control over the system than traditional Linux/Unix program is allowed to have.

Not only because of copy protection (though this is also a strong reason), but because of games trying to provide smooth, "console"-like experience on the PC. We want sustainable FPS rate and go to great lengths to fight occasional FPS hitches which usually happen because of resource streaming. Sure, if one just wants to get the game working under Linux, one may lower his/her quality standards, and most Linux games I have tried actually do exactly that...

So, I'm only getting to reading this some days late, but...
flightgear was updated to 2.0 in the archlinux repositories on the same day you made this comment:
http://www.archlinux.org/packages/?q=flightgear

Personally I don't mind that linux doesn't "move forward" quite the same way windows and mac does. On linux, I can get whatever I want right now, or if I don't care that much I can wait a while and get it automatically. On windows and mac, I can't really get exactly what I want either way. Well I guess I could, but hacking closed-source and non-configurable binaries is way more work than I want to get into (with props to vlite / nlite / osx86 project).

Well they have a working proprietary driver.

For varying definitions of "working". As an ATI user I must say, the propietary driver is the single worst piece of software I've ever had the displeasure to run on my Linux system, and the only thing besides faulty RAM and a dying HDD to ever cause Linux (yes, the kernel, not just X) lock up on me. It sucks so badly that ArchLinux even removed it from their repositories, prefering to not give it as even an option rather than deal with the support nightmares it causes.

The Open Source driver on the other hand is excellent, stable and completely hassle-free (something I can't quite say of NVidia's propietary driver, though it wasn't nearly as bad as ATI's), and even supports 3D acceleration on older chipsets. My guess is that it won't be long until 3D is also supported on the HD5x00 series as well, development is quite fast on it.

If you really want to learn how to use Linux, then (my personal opinion is that) the currently most popular distro, Ubuntu, isn't the best way to go about it. There's quite a lot of machinery under the bonnet (or hood in the US), and scraping a few lines out of a cookbook or forum post without taking a bit of time to understand what you're doing can lead to the kind of frustration you describe. It does sound like you bit off a tough chew.

If you've got lots of time to spare (and an otherwise unused machine), you could try Linux From Scratch, but a gentler approach might be to try Slackware which will give you a world to stand on while you get your shit together. My current preference is Arch Linux, which has lots of similarities to Slackware, with a number of improvements, but assumes that you have some experience with editing things like init scripts.

B.S.

I've been expecting something like that from the beginning. MS is quite strong in Russia, has numerous R&D centers, etc.

Maybe, just maybe... Linux is an awful desktop environment to work in and the community that surrounds it doesn't want to accept any responsibility or settle on standards.

You apparently have no clue what you are talking about. The Russian Linux/BSD community would strongly disagree. And they are setting standards perfectly fine as Arch Linux can be easily called national Russian distro. And it it quite close to the top on list of best desktop Linux distros. (Many Russians ISPs were BSD/Linux based from day one - amount of *NIX expertise in Russia is not to be underestimated.)

Especially considering that we are talking about educational sector, all the "Linux is hard" excuses are inapplicable, as thanks to LTSP it is much much more manageable and easier (compared to Windows) to use, monitor and deploy in environments such as school is. And there are literally piles of the educational software for Linux.

Though as I said above, it was obvious that MS would do something about it. It was more question of price, as highly corrupt Russian politicians probably weren't satisfied with initial size of bribes offered by MS. Or probably they were not pro-Putin enough but now amended their ways.

Nowadays (having emigrated to OS X) my taste in Linux lies with Ubuntu, for the sole reason that it's easy and fast to use in a VM. Gentoo requires too much upkeep for that.

You might be interested to try Arch Linux then. Just like Slackware in its simplicity, but with a more comprehensive package system.

OR, my major point, just try to work out minor perpetual upgrading instead of all at once? Install once, that's it, no need to reinstall the whole thing ever, ever, ever again.

Losing the mod points I already used in this discussion, but this is important, so listen. Cancel whatever you had planned for this weekend, because you need to switch to Arch.

Drivers are in the kernel or as modules aren't they? We already get regular kernel updates for kernels, about the only time you have to reboot, and video kernel modules just need to restart X. You can jump around and do that now if you want. But those don't require an entire new distro version. And none of the apps require a new distro version. Near as I can see (again, I am in no way an expert), only a new file system change should absolutely require an entire new upgrade (like happened here with those who chose it, extension 3 to 4). But that certainly isn't all the time, not every six months it isn't.

Really, I am looking for more of a technical reason why the whole thing needs to be done at once, necessitating a ton of things to all be upgraded at the same time, leading to a lot of things that are close but no cigar, the subject of the whole article. It looks more just..dunno..politically driven or market-thinking driven than necessity driven. Whereas if it was incremental by design, only those apps/drivers/ whatever that really are ready get upgraded. Maybe it is all the shared libraries and linking, I just don't know...just mused on this over the years and never read an explanation for it.

And if it was incremental by design, you would only have to wait for your new hardware to be fully supported as long as it took the devs to do it and test it, 12 months is just another artificial time limit. I would prefer, "exactly when they are ready", whatever that time period happens to be. And if the design had an automatic revert to last good working state, then you'd have a relatively painless way to fix any accidental whoopsies that occur. Give you a chance to really tryout this or that new incremental upgrade "thing", to see if it works for you or not, before a full committment and it wipes/replaces the old stuff fully then.

I also noticed in the article thread that Arch linux http://www.archlinux.org/about/ does in fact use a "rolling release" incremental upgrade system, install once and that's it. So, technically it IS possible like I thought, so now I am wondering why they do it but no one else (?) does it that way?

A question for anyone here, which if any of those PDF readers works properly with PDF forms?

I was going to complain that none of the free Linux programs did this, but apparently both Evince and Okular support this now. Arch forum link.

If Asus had used a decent distro it would maybe have still been installed on some of those netbooks.

I bought two EEE 4Gs, 701, just to support them in this endeavour.
As someone who uses Linux exclusively (Gentoo/Arch/openSUSE) I have to say that Xandros is crap. I believe that the choice of Xandros for those netbooks did Linux in general no favours at all.

For those who don't know, there's a BSD style linux distro that kills Gentoo in both, setup, design, and ease. It's virtually BSD with a linux kernel, and an apt-get killer.

"
Arch Linux is an independently developed, i686/x86-64 general purpose GNU/Linux distribution versatile enough to suit any role. Development focuses on simplicity, minimalism, and code elegance. Arch is installed as a minimal base system, configured by the user upon which their own ideal environment is assembled by installing only what is required or desired for their unique purposes. GUI configuration utilities are not officially provided, and most system configuration is performed from the shell by editing simple text files. Arch strives to stay bleeding edge, and typically offers the latest stable versions of most software.

Arch Linux uses its own Pacman package manager, which couples simple binary packages with an easy-to-use package build system. This allows users to easily manage and customize packages ranging from official Arch software to the user's own personal packages to packages from 3rd party sources. The repository system also allows users to easily build and maintain their own custom build scripts, packages, and repositories, encouraging community growth and contribution.

The minimal Arch base package set resides in the streamlined [core] repository. In addition, the official [extra], [community], and [testing] repositories provide several thousand high-quality, packages to meet your software demands. Arch also offers an [unsupported] section in the Arch Linux User Repository (AUR), which contains over 9,000 build scripts, for compiling installable packages from source using the Arch Linux makepkg application.

Arch Linux uses a "rolling release" system which allows one-time installation and perpetual software upgrades. It is not generally necessary to reinstall or upgrade your Arch Linux system from one "version" to the next. By issuing one command, an Arch system is kept up-to-date and on the bleeding edge.

Arch strives to keep its packages as close to the original upstream software as possible. Patches are applied only when necessary to ensure an application compiles and runs correctly with the other packages installed on an up-to-date Arch system.

To summarize: Arch Linux is a versatile, and simple distribution designed to fit the needs of the competent Linux® user. It is both powerful and easy to manage, making it an ideal distro for servers and workstations. Take it in any direction you like. If you share this vision of what a GNU/Linux distribution should be, then you are welcomed and encouraged to use it freely, get involved, and contribute to the community. Welcome to Arch!
" - http://www.archlinux.org/about/

Well, Arch has a very active developer/user group of exactly the type of people who would use this browser. I think they have a majority of a very solid niche market.

I use this version and don't experience any problems with flash. Although I miss some plugins from firefox, chromium is much faster and I use it as my primary browser.

Me, too, but now that Arch is splitting the [extra] repo packages, I'm wondering if I should switch to vanilla kde, since the only reason I used the KdeMod packages was because I liked my packages split. The KdeMod forums seem to suggest that the packages won't be in [kdemod-core] until the end of the week.

Well, there's a great discussion of it on the Arch forums (great before it got bogged down with bickering, although I didn't see Godwin's law being invoked).

Frankly, I think I'll move to offical [extra]/KDE tonight. KDEmod has served me great, but I think I can handle to live without all the extra patching and branding they do if it means I get 4.3 goodness a week early.

I'd recommend checking out Arch, it is a bleeding edge distro that also makes recompilation quite easy. There are a lot of smart people working on it and the documentation is quite good. Arch follows the KISS principle and keeps their repositories fairly light while letting the community handle the masses of programs.

Anyway, I recommend checking it out here: http://www.archlinux.org/