Damn slashdot - I wrote a lengthy reply and it seems it just disappeared. Oh well, I'll try again a bit more briefly. These are only my opinions, and you are surely aware of the relation between opinions and assholes...
I can't comment on multilib support, as I've yet to find a compelling need to use a 64-bit system, but I'll take your word for it. Perhaps my needs are very generic, but most of the programs I need are in core/extra/community (or the custom repos for LinHES/Chakra), on the occasion that I need to use AUR I just download the tarball, check/modify the files and build the package. Of the packages I do build from AUR, I very seldom run into those that extract RPMs/DEBs; I do agree it's very much band-aid and should be avoided, but is understandable at least when it comes to commercial/closed-source programs, as they usually only support those formats.
As for pacman, even without caching I find it to be faster than APT, but as it uses a flat-files-in-directories -approach, this depends very much on the file system. Although I don't like ReiserFSv3 that much, it's great with lots of small files, so when using Arch having at least/var/lib/pacman in ReiserFSv3 is recommendable. There are occasional conflicts, especially if you haven't updated for a while, but "-f" is your friend.
I also think ABS is great, I don't rebuild the stock packages often, but when I need to for example apply a certain patch the process is very straightforward. Making PKGBUILDs is very easy, and for the impatient, if a new version of $APP has been released, and one can't wait for it to exist in the repos updating is usually as simple as getting the PKGBUILD from ABS, changing the version number, and building the package.
Generally what I like about Arch is the fact that the number of configuration files is quite minimal, it's much easier to figure what affects what, contrast to more desktop-oriented distributions. Naturally this is also a matter of getting used to, but in this aspect I find Arch much more approachable than many other distributions, it's very easy to find out what makes it "tick" (I'm also very much aware that this is of little interest to many users). And the rolling release system - yes, there is some breakage every now and then, but surprisingly little in my opinion, given how bleeding edge Arch is.
I agree that placing programs in/opt was annoying (although historically it was the "correct" thing to do for large packages, years ago), but very few, if any, packages install themselves in/opt anymore. I don't think I've ever seen an official package install anything in/usr/local, except perhaps some badly made AUR package, generally using/usr/local is bad practice according to the official guidelines.
I also like the community, the wiki is very helpful, and although the forums certainly don't have as much users as the *buntu ones, I find the s/n-ratio to be much higher in Arch ones. But as stated, these are my personal opinions/preferences, if (K)Ubuntu works for you, more power to you. And sorry for the general lack of spelling, grammar and coherence, English is not my first language and work is killing me at the moment so I'm unable to form very valid sentences.
Damn slashdot - I wrote a lengthy reply and it seems it just disappeared. Oh well, I'll try again a bit more briefly. These are only my opinions, and you are surely aware of the relation between opinions and assholes...
I can't comment on multilib support, as I've yet to find a compelling need to use a 64-bit system, but I'll take your word for it. Perhaps my needs are very generic, but most of the programs I need are in core/extra/community (or the custom repos for LinHES/Chakra), on the occasion that I need to use AUR I just download the tarball, check/modify the files and build the package. Of the packages I do build from AUR, I very seldom run into those that extract RPMs/DEBs; I do agree it's very much band-aid and should be avoided, but is understandable at least when it comes to commercial/closed-source programs, as they usually only support those formats.
As for pacman, even without caching I find it to be faster than APT, but as it uses a flat-files-in-directories -approach, this depends very much on the file system. Although I don't like ReiserFSv3 that much, it's great with lots of small files, so when using Arch having at least/var/lib/pacman in ReiserFSv3 is recommendable. There are occasional conflicts, especially if you haven't updated for a while, but "-f" is your friend.
I also think ABS is great, I don't rebuild the stock packages often, but when I need to for example apply a certain patch the process is very straightforward. Making PKGBUILDs is very easy, and for the impatient, if a new version of $APP has been released, and one can't wait for it to exist in the repos updating is usually as simple as getting the PKGBUILD from ABS, changing the version number, and building the package.
Generally what I like about Arch is the fact that the number of configuration files is quite minimal, it's much easier to figure what affects what, contrast to more desktop-oriented distributions. Naturally this is also a matter of getting used to, but in this aspect I find Arch much more approachable than many other distributions, it's very easy to find out what makes it "tick" (I'm also very much aware that this is of little interest to many users). And the rolling release system - yes, there is some breakage every now and then, but surprisingly little in my opinion, given how bleeding edge Arch is.
I agree that placing programs in/opt was annoying (although historically it was the "correct" thing to do for large packages, years ago), but very few, if any, packages install themselves in/opt anymore. I don't think I've ever seen an official package install anything in/usr/local, except perhaps some badly make AUR package, generally using/usr/local is bad practice in the official guidelines.
I also like the community, the wiki is very helpful, and although the forums certainly don't have as much users as the *buntu ones, I find the s/n-ratio to be much higher in Arch ones. But as stated, these are my personal opinions/preferences, if (K)Ubuntu works for you, more power to you. And sorry for the general lack of spelling, grammar and coherence, English is not my first language and it's still very early here.
Damn slashdot - I wrote a lengthy reply and it seems it just disappeared. Oh well, I'll try again a bit more briefly. These are only my opinions, and you are surely aware of the relation between opinions and assholes...
I can't comment on multilib support, as I've yet to find a compelling need to use a 64-bit system, but I'll take your word for it. Perhaps my needs are very generic, but most of the programs I need are in core/extra/community (or the custom repos for LinHES/Chakra), on the occasion that I need to use AUR I just download the tarball, check/modify the files and build the package. Of the packages I do build from AUR, I very seldom run into those that extract RPMs/DEBs; I do agree it's very much band-aid and should be avoided, but is understandable at least when it comes to commercial/closed-source programs, as they usually only support those formats.
As for pacman, even without caching I find it to be faster than APT, but as it uses a flat-files-in-directories -approach, this depends very much on the file system. Although I don't like ReiserFSv3 that much, it's great with lots of small files, so when using Arch having at least/var/lib/pacman in ReiserFSv3 is recommendable. There are occasional conflicts, especially if you haven't updated for a while, but "-f" is your friend.
I also think ABS is great, I don't rebuild the stock packages often, but when I need to for example apply a certain patch the process is very straightforward. Making PKGBUILDs is very easy, and for the impatient, if a new version of $APP has been released, and one can't wait for it to exist in the repos, updating is usually as simple as getting the PKGBUILD from ABS, changing the version number, and building the package.
Generally what I like about Arch is the fact that the number of configuration files is quite minimal, it's much easier to figure what affects what, contrast to more desktop-oriented distributions. Naturally this is also a matter of getting used to, but in this aspect I find Arch much more approachable than many other distributions, it's very easy to find out what makes it "tick" (I'm also very much aware that this is of little interest to many users). And the rolling release system - yes, there is some breakage every now and then, but surprisingly little in my opinion, given how bleeding edge Arch is.
I agree that placing programs in/opt was annoying (although historically it was the "correct" thing to do for large packages, years ago), but very few, if any, packages install themselves in/opt anymore. I don't think I've ever seen an official package install anything in/usr/local, except perhaps some badly make AUR package, generally using/usr/local is bad practice in the official guidelines.
I also like the community, the wiki is very helpful, and although the forums certainly don't have as much users as the *buntu ones, I find the s/n-ratio to be much higher in Arch ones. But as stated, these are my personal opinions/preferences, if (K)Ubuntu works for you, more power to you. And sorry for the general lack of spelling, grammar and coherence, English is not my first language and it's still very early here.
Sure, I'll explain, my point of view - surely you are aware of the relation between opinions and assholes:) so these are just my personal opinions.
I personally like that the package names also include the category, as the amount of applications included with KDE can be quite overwhelming, and the names are not always very descriptive - the fact that the package names are longer is a non-issue with bash autocompletion. Anyway, that whole thing is a matter of preference and really doesn't matter at all. Some Arch devs are also KDE devs (see here for example), but it's very rare for derivatives of Arch to modify the packages, they are pretty much plain vanilla.
But as for why I prefer Arch over Ubuntu (in non-KDE issues), I'll first comment on your post you referred to. I have no comment on multilib support, as I've yet to see any compelling reason to move to 64bit, but I'll take your word for it (I'm by no means suggesting Arch is perfect). As for AUR, perhaps my needs are very generic, but I find pretty much all of the packages I need are either in core, extra or community (and the custom repos for LinHES/Chakra) - when I need a package from AUR, I just download the tarball and check/modify the files and then build the package. I don't find it that much more complicated, and as stated, I really don't end up doing it often. I'll certainly grant Ubuntu offers many more packages, but for me, the default Arch selection seems sufficient. On the occasion that I do use AUR, I very seldom run into packages that extract a DEB/RPM and relink them, but partially this is understandable, at least when it comes to commercial programs, as they tend to release packages only for those formats. I agree that such methods are very much bandaid, and should be avoided.
Without caching, I still find pacman to be much faster than apt, but as it uses a flat-files-in-directories -approach, the performance depends greatly on the underlying filesystem. Although I generally don't like ReiserFSv3 that much, it's great with lots of small files, so when running Arch it's wise to have at least/var/lib/pacman in ReiserFSv3. Personally I also like the fact that all of the operations are done with a single program, but this is simply a matter of preference. When it comes to conflicts, -f is your friend, if you are sure the change is safe. If you haven't updated in a while it's not uncommon for some files to conflict, personally I find it amusing to tell pacman to "-Sfu" (if only you there were a -t option as well).
ABS is another aspect I really appreciate, I don't rebuild standard packages often, but when I do it's very handy should I want to for example apply a certain patch. And generally, I really like the rolling release approach, as well as the rc.conf and other minimalistic config files. When using a more desktop oriented distribution I find it harder to figure out which configuration file affects which, although certainly this is a matter of getting accustomed as well. It's a tinkerers distribution, and I like to tinker - would I run it on my work computer, probably not (and unfortunately as of now I'm forced to use Windows at work), but it's a hobby. Specifically, regarding KDE/Chakra, I appreciate that it's pretty much plain vanilla, so I can customize it from there.
But as stated these are my personal opinions/preferences, if you like (K)Ubuntu more, more power to you. And sorry for the typos, grammar and general lack of coherence, English is not my first language and I've just woken up/haven't had enough coffee yet.
To each his own - I guess I've just been traumatized by people who complain about defects in KDE, and turns out they've only tried Kubuntu. If it works for you, good for you. The delay in releasing a new KDE version is understandable with Chakra, as they modularize the packages (so that for example you can just install KGet instead of the whole kdenetwork package). There are also meaningful technical reasons why I prefer Arch-based distros (my Myth backend/file server runs stock Arch, Myth frontend LinHES and laptop Chakra) - and I guess my reasons differ from yours:) So my apologies for being too harsh. Although this thread has been amusing for me, that apk guy is just something else.
Wow, I mean, just, WOW. It seems you can't get your head around the fact that there can be personal opinions? And that those opinions are neither right or wrong? Let's see how all this your raving got started. Initially I was modded down, then up (ever so slightly - and you know, I really don't care either way), from which you deduce that I must have multiple accounts. But did it ever occur to you that someone with mod points might have first disagreed with me, then a couple have agreed with me? Not everybody loves *buntu.
FWIW, yes, I am a "multiple registered account utilizing troll" - I registered around 2000 when I was living in.de, but forgot what my password was (and after I stopped working there, lost saved credentials on my work computer/the work e-mail address I used for registering), didn't bother to re-register for a while.
Figures, & I was right on that too: Most guys who are worth their salt KNOW little trolls & weasels like you, & honestly? It's WHY we pity little fucks like you.
And here's where it gets surreal. Seriously, if I have a _single_ previous account, that I can't log in to, how on earth does that change anything? It's highly ironic that you are calling me a troll, as it seems from a quick google that you've been trolling slashdot with your incoherent drivel (anonymously - well, at least you're not using multiple accounts - or wait, there could be many of you!) at least since 2005.
I would try it, but the slowest computer I have is about 2 GHz:P. The point I was trying to make is such anecdotes are useless. Even the clock speed is a useless metric. Yes, my ancient desktop (now retired to a file server/MythTV backend) is a "2600+" Athlon XP, and incidentally has a GF 6600 and 1GB of RAM - it's unable to play 720p under either. I have a laptop that has a C2D processor, clocked under 2 GHz, with integrated Intel graphics, and it's able to play 720p just fine despite the DE. And what does this tell us? Nothing.
If you are not very familiar with Linux / have some experience with Mandriva, I see no reason why not use it. Some people keep complaining it's too much "for newbies", but there's nothing wrong with that IMHO. The company has faced some financial difficulties, but is not going away anytime soon, nor is the community. The integrated admin tools are among the best. Personally I'm running Chakra, but as it is based on Arch it might be a bit too power-user initially; the community is wonderful though. Just make a separate/home partition, and you'll be able to change distributions easily. As for widescreen support, I've had no issues with it, but as always with Linux (or computers in general), YMMV.
Seriously, loosen the tinfoil, I think it's affecting the circulation to your brain. Could it be that the slashdot hive mind can have dissenting opinions? No surely there must be a global conspiracy. FWIW, yes, I am a "multiple registered account utilizing troll" - I registered around 2000 when I was living in.de, but forgot what my password was (and after I stopped working there, lost saved credentials on my work computer/the work e-mail address I used for registering), didn't bother to re-register for a while.
And as I replied too hastily, I'll continue - OK, you didn't imply that Adobe uses x264 in Flash Player (although you fail to point out how Adobe makes any money from x264). But when it comes to YouTube et al - first of all, I'm pretty certain that at least YouTube can afford the encoders, Google is certainly a big enough to be targeted with lawsuits if they didn't comply. Hell, they even provide a built-in decoder to be used with the tag in Chrome. Furthermore "MPEG LA announced today that its AVC Patent Portfolio License will continue not to charge royalties for Internet Video that is free to end users". So there's that.
I don't know why I even bother, but x264 is licensed under the GPL. If Flash were infringing on GPL (and yes, such things are relatively easy to figure out even without source code), you can bet all free software advocates would raise hell over it. But very apparently it is not. Any more incoherent arguments?
For the love of $DEITY, stop recommending Kubuntu, it's an half-assed effort that keeps giving KDE a bad name. Yes, the 4.0 release was a PR disaster, whether it was the fault of the developers or distros is debatable but irrelevant now. If you want to run KDE, do yourself a favor and use a distro that puts some effort to it, like Mandriva, OpenSUSE or Chakra.
Then how do Adobe and the like make money from people who are "hardly interested in complying with IP laws"?
You either have serious issues with reading comprehension, or I'm unaware how Adobe is making money off x264. Yes, companies (at least those doing business in the US) pay to use H.264, but AFAIK no one pays to use x264. Yes, the users might be breaking the law, but the law is retarded.
Uhh, seriously, wut? You are aware what x264 is (the most popular open-source H.264 encoder), right? And surely you are aware that even though it has legitimate uses, 99% of the time (as with most statistics, I just pulled that out of my ass, but I'm willing to wager it's true) it's used for encoding pirated content. So to summarize, a) the developers are not making any money off it, so they're hardly concerned in losing any business, b) the users are hardly interested in complying with IP laws.
That makes x.264 (in it's current form and distribution method) illegal, and the MPEGLA could shut it down whenever they like. As it happens to be on of few decent encoders out there they seem to be tolerating the project, and only targeting people with business interests.
Or perhaps the developers live outside of the US, and thus are not subject to your retarded patent laws.
But this really depends on the file system - XFS or JFS are very good with quick deletions, I've never had to enable that feature when using XFS. Just make sure you mount the drive with a reasonably large allocsize, say 512m. (That is, provided that you have a drive dedicated for MythTV recordings. Such allocsize would obviously be wrong for a general file system. And when using XFS it doesn't hurt to defrag every now and then, it can be done while the drive is mounted and in use)
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.
No, back in the day it was inline Javascript with onmouseover/onmouseout events (even with image preloading if you were "fancy") - now that IE6 is finally starting to fade away (IE6 only supports the:hover pseudo selector on anchor tags) there's no reason not to use CSS sprites, which means no more superficial attributes or Javascript for rollovers.
Slashdot Mirror
or... a time cube!
You are certain that it is Skype placing this restriction and not Apple? My N900 can make Skype (and GTalk) video calls just fine.
You know, I've heard of this magical invention called decimals. Probably just a myth though.
...and it seems slashdot's comment system is borked, expect a flood of similar responses soon :)
Damn slashdot - I wrote a lengthy reply and it seems it just disappeared. Oh well, I'll try again a bit more briefly. These are only my opinions, and you are surely aware of the relation between opinions and assholes...
I can't comment on multilib support, as I've yet to find a compelling need to use a 64-bit system, but I'll take your word for it. Perhaps my needs are very generic, but most of the programs I need are in core/extra/community (or the custom repos for LinHES/Chakra), on the occasion that I need to use AUR I just download the tarball, check/modify the files and build the package. Of the packages I do build from AUR, I very seldom run into those that extract RPMs/DEBs; I do agree it's very much band-aid and should be avoided, but is understandable at least when it comes to commercial/closed-source programs, as they usually only support those formats.
As for pacman, even without caching I find it to be faster than APT, but as it uses a flat-files-in-directories -approach, this depends very much on the file system. Although I don't like ReiserFSv3 that much, it's great with lots of small files, so when using Arch having at least /var/lib/pacman in ReiserFSv3 is recommendable. There are occasional conflicts, especially if you haven't updated for a while, but "-f" is your friend.
I also think ABS is great, I don't rebuild the stock packages often, but when I need to for example apply a certain patch the process is very straightforward. Making PKGBUILDs is very easy, and for the impatient, if a new version of $APP has been released, and one can't wait for it to exist in the repos updating is usually as simple as getting the PKGBUILD from ABS, changing the version number, and building the package.
Generally what I like about Arch is the fact that the number of configuration files is quite minimal, it's much easier to figure what affects what, contrast to more desktop-oriented distributions. Naturally this is also a matter of getting used to, but in this aspect I find Arch much more approachable than many other distributions, it's very easy to find out what makes it "tick" (I'm also very much aware that this is of little interest to many users). And the rolling release system - yes, there is some breakage every now and then, but surprisingly little in my opinion, given how bleeding edge Arch is.
I agree that placing programs in /opt was annoying (although historically it was the "correct" thing to do for large packages, years ago), but very few, if any, packages install themselves in /opt anymore. I don't think I've ever seen an official package install anything in /usr/local, except perhaps some badly made AUR package, generally using /usr/local is bad practice according to the official guidelines.
I also like the community, the wiki is very helpful, and although the forums certainly don't have as much users as the *buntu ones, I find the s/n-ratio to be much higher in Arch ones. But as stated, these are my personal opinions/preferences, if (K)Ubuntu works for you, more power to you. And sorry for the general lack of spelling, grammar and coherence, English is not my first language and work is killing me at the moment so I'm unable to form very valid sentences.
Damn slashdot - I wrote a lengthy reply and it seems it just disappeared. Oh well, I'll try again a bit more briefly. These are only my opinions, and you are surely aware of the relation between opinions and assholes...
I can't comment on multilib support, as I've yet to find a compelling need to use a 64-bit system, but I'll take your word for it. Perhaps my needs are very generic, but most of the programs I need are in core/extra/community (or the custom repos for LinHES/Chakra), on the occasion that I need to use AUR I just download the tarball, check/modify the files and build the package. Of the packages I do build from AUR, I very seldom run into those that extract RPMs/DEBs; I do agree it's very much band-aid and should be avoided, but is understandable at least when it comes to commercial/closed-source programs, as they usually only support those formats.
As for pacman, even without caching I find it to be faster than APT, but as it uses a flat-files-in-directories -approach, this depends very much on the file system. Although I don't like ReiserFSv3 that much, it's great with lots of small files, so when using Arch having at least /var/lib/pacman in ReiserFSv3 is recommendable. There are occasional conflicts, especially if you haven't updated for a while, but "-f" is your friend.
I also think ABS is great, I don't rebuild the stock packages often, but when I need to for example apply a certain patch the process is very straightforward. Making PKGBUILDs is very easy, and for the impatient, if a new version of $APP has been released, and one can't wait for it to exist in the repos updating is usually as simple as getting the PKGBUILD from ABS, changing the version number, and building the package.
Generally what I like about Arch is the fact that the number of configuration files is quite minimal, it's much easier to figure what affects what, contrast to more desktop-oriented distributions. Naturally this is also a matter of getting used to, but in this aspect I find Arch much more approachable than many other distributions, it's very easy to find out what makes it "tick" (I'm also very much aware that this is of little interest to many users). And the rolling release system - yes, there is some breakage every now and then, but surprisingly little in my opinion, given how bleeding edge Arch is.
I agree that placing programs in /opt was annoying (although historically it was the "correct" thing to do for large packages, years ago), but very few, if any, packages install themselves in /opt anymore. I don't think I've ever seen an official package install anything in /usr/local, except perhaps some badly make AUR package, generally using /usr/local is bad practice in the official guidelines.
I also like the community, the wiki is very helpful, and although the forums certainly don't have as much users as the *buntu ones, I find the s/n-ratio to be much higher in Arch ones. But as stated, these are my personal opinions/preferences, if (K)Ubuntu works for you, more power to you. And sorry for the general lack of spelling, grammar and coherence, English is not my first language and it's still very early here.
Damn slashdot - I wrote a lengthy reply and it seems it just disappeared. Oh well, I'll try again a bit more briefly. These are only my opinions, and you are surely aware of the relation between opinions and assholes...
I can't comment on multilib support, as I've yet to find a compelling need to use a 64-bit system, but I'll take your word for it. Perhaps my needs are very generic, but most of the programs I need are in core/extra/community (or the custom repos for LinHES/Chakra), on the occasion that I need to use AUR I just download the tarball, check/modify the files and build the package. Of the packages I do build from AUR, I very seldom run into those that extract RPMs/DEBs; I do agree it's very much band-aid and should be avoided, but is understandable at least when it comes to commercial/closed-source programs, as they usually only support those formats.
As for pacman, even without caching I find it to be faster than APT, but as it uses a flat-files-in-directories -approach, this depends very much on the file system. Although I don't like ReiserFSv3 that much, it's great with lots of small files, so when using Arch having at least /var/lib/pacman in ReiserFSv3 is recommendable. There are occasional conflicts, especially if you haven't updated for a while, but "-f" is your friend.
I also think ABS is great, I don't rebuild the stock packages often, but when I need to for example apply a certain patch the process is very straightforward. Making PKGBUILDs is very easy, and for the impatient, if a new version of $APP has been released, and one can't wait for it to exist in the repos, updating is usually as simple as getting the PKGBUILD from ABS, changing the version number, and building the package.
Generally what I like about Arch is the fact that the number of configuration files is quite minimal, it's much easier to figure what affects what, contrast to more desktop-oriented distributions. Naturally this is also a matter of getting used to, but in this aspect I find Arch much more approachable than many other distributions, it's very easy to find out what makes it "tick" (I'm also very much aware that this is of little interest to many users). And the rolling release system - yes, there is some breakage every now and then, but surprisingly little in my opinion, given how bleeding edge Arch is.
I agree that placing programs in /opt was annoying (although historically it was the "correct" thing to do for large packages, years ago), but very few, if any, packages install themselves in /opt anymore. I don't think I've ever seen an official package install anything in /usr/local, except perhaps some badly make AUR package, generally using /usr/local is bad practice in the official guidelines.
I also like the community, the wiki is very helpful, and although the forums certainly don't have as much users as the *buntu ones, I find the s/n-ratio to be much higher in Arch ones. But as stated, these are my personal opinions/preferences, if (K)Ubuntu works for you, more power to you. And sorry for the general lack of spelling, grammar and coherence, English is not my first language and it's still very early here.
Sure, I'll explain, my point of view - surely you are aware of the relation between opinions and assholes :) so these are just my personal opinions.
I personally like that the package names also include the category, as the amount of applications included with KDE can be quite overwhelming, and the names are not always very descriptive - the fact that the package names are longer is a non-issue with bash autocompletion. Anyway, that whole thing is a matter of preference and really doesn't matter at all. Some Arch devs are also KDE devs (see here for example), but it's very rare for derivatives of Arch to modify the packages, they are pretty much plain vanilla.
But as for why I prefer Arch over Ubuntu (in non-KDE issues), I'll first comment on your post you referred to. I have no comment on multilib support, as I've yet to see any compelling reason to move to 64bit, but I'll take your word for it (I'm by no means suggesting Arch is perfect). As for AUR, perhaps my needs are very generic, but I find pretty much all of the packages I need are either in core, extra or community (and the custom repos for LinHES/Chakra) - when I need a package from AUR, I just download the tarball and check/modify the files and then build the package. I don't find it that much more complicated, and as stated, I really don't end up doing it often. I'll certainly grant Ubuntu offers many more packages, but for me, the default Arch selection seems sufficient. On the occasion that I do use AUR, I very seldom run into packages that extract a DEB/RPM and relink them, but partially this is understandable, at least when it comes to commercial programs, as they tend to release packages only for those formats. I agree that such methods are very much bandaid, and should be avoided.
Without caching, I still find pacman to be much faster than apt, but as it uses a flat-files-in-directories -approach, the performance depends greatly on the underlying filesystem. Although I generally don't like ReiserFSv3 that much, it's great with lots of small files, so when running Arch it's wise to have at least /var/lib/pacman in ReiserFSv3. Personally I also like the fact that all of the operations are done with a single program, but this is simply a matter of preference. When it comes to conflicts, -f is your friend, if you are sure the change is safe. If you haven't updated in a while it's not uncommon for some files to conflict, personally I find it amusing to tell pacman to "-Sfu" (if only you there were a -t option as well).
ABS is another aspect I really appreciate, I don't rebuild standard packages often, but when I do it's very handy should I want to for example apply a certain patch. And generally, I really like the rolling release approach, as well as the rc.conf and other minimalistic config files. When using a more desktop oriented distribution I find it harder to figure out which configuration file affects which, although certainly this is a matter of getting accustomed as well. It's a tinkerers distribution, and I like to tinker - would I run it on my work computer, probably not (and unfortunately as of now I'm forced to use Windows at work), but it's a hobby. Specifically, regarding KDE/Chakra, I appreciate that it's pretty much plain vanilla, so I can customize it from there.
But as stated these are my personal opinions/preferences, if you like (K)Ubuntu more, more power to you. And sorry for the typos, grammar and general lack of coherence, English is not my first language and I've just woken up/haven't had enough coffee yet.
To each his own - I guess I've just been traumatized by people who complain about defects in KDE, and turns out they've only tried Kubuntu. If it works for you, good for you. The delay in releasing a new KDE version is understandable with Chakra, as they modularize the packages (so that for example you can just install KGet instead of the whole kdenetwork package). There are also meaningful technical reasons why I prefer Arch-based distros (my Myth backend/file server runs stock Arch, Myth frontend LinHES and laptop Chakra) - and I guess my reasons differ from yours :) So my apologies for being too harsh. Although this thread has been amusing for me, that apk guy is just something else.
FWIW, yes, I am a "multiple registered account utilizing troll" - I registered around 2000 when I was living in .de, but forgot what my password was (and after I stopped working there, lost saved credentials on my work computer/the work e-mail address I used for registering), didn't bother to re-register for a while.
Figures, & I was right on that too: Most guys who are worth their salt KNOW little trolls & weasels like you, & honestly? It's WHY we pity little fucks like you.
And here's where it gets surreal. Seriously, if I have a _single_ previous account, that I can't log in to, how on earth does that change anything? It's highly ironic that you are calling me a troll, as it seems from a quick google that you've been trolling slashdot with your incoherent drivel (anonymously - well, at least you're not using multiple accounts - or wait, there could be many of you!) at least since 2005.
I would try it, but the slowest computer I have is about 2 GHz :P. The point I was trying to make is such anecdotes are useless. Even the clock speed is a useless metric. Yes, my ancient desktop (now retired to a file server/MythTV backend) is a "2600+" Athlon XP, and incidentally has a GF 6600 and 1GB of RAM - it's unable to play 720p under either. I have a laptop that has a C2D processor, clocked under 2 GHz, with integrated Intel graphics, and it's able to play 720p just fine despite the DE. And what does this tell us? Nothing.
If you are not very familiar with Linux / have some experience with Mandriva, I see no reason why not use it. Some people keep complaining it's too much "for newbies", but there's nothing wrong with that IMHO. The company has faced some financial difficulties, but is not going away anytime soon, nor is the community. The integrated admin tools are among the best. Personally I'm running Chakra, but as it is based on Arch it might be a bit too power-user initially; the community is wonderful though. Just make a separate /home partition, and you'll be able to change distributions easily. As for widescreen support, I've had no issues with it, but as always with Linux (or computers in general), YMMV.
I'm running Arch/KDE as well, and 720p video plays back with no issues. Isn't anecdotal evidence wonderful?
Seriously, loosen the tinfoil, I think it's affecting the circulation to your brain. Could it be that the slashdot hive mind can have dissenting opinions? No surely there must be a global conspiracy. FWIW, yes, I am a "multiple registered account utilizing troll" - I registered around 2000 when I was living in .de, but forgot what my password was (and after I stopped working there, lost saved credentials on my work computer/the work e-mail address I used for registering), didn't bother to re-register for a while.
And as I replied too hastily, I'll continue - OK, you didn't imply that Adobe uses x264 in Flash Player (although you fail to point out how Adobe makes any money from x264). But when it comes to YouTube et al - first of all, I'm pretty certain that at least YouTube can afford the encoders, Google is certainly a big enough to be targeted with lawsuits if they didn't comply. Hell, they even provide a built-in decoder to be used with the tag in Chrome. Furthermore "MPEG LA announced today that its AVC Patent Portfolio License will continue not to charge royalties for Internet Video that is free to end users". So there's that.
I don't know why I even bother, but x264 is licensed under the GPL. If Flash were infringing on GPL (and yes, such things are relatively easy to figure out even without source code), you can bet all free software advocates would raise hell over it. But very apparently it is not. Any more incoherent arguments?
For the love of $DEITY, stop recommending Kubuntu, it's an half-assed effort that keeps giving KDE a bad name. Yes, the 4.0 release was a PR disaster, whether it was the fault of the developers or distros is debatable but irrelevant now. If you want to run KDE, do yourself a favor and use a distro that puts some effort to it, like Mandriva, OpenSUSE or Chakra.
Then how do Adobe and the like make money from people who are "hardly interested in complying with IP laws"?
You either have serious issues with reading comprehension, or I'm unaware how Adobe is making money off x264. Yes, companies (at least those doing business in the US) pay to use H.264, but AFAIK no one pays to use x264. Yes, the users might be breaking the law, but the law is retarded.
Uhh, seriously, wut? You are aware what x264 is (the most popular open-source H.264 encoder), right? And surely you are aware that even though it has legitimate uses, 99% of the time (as with most statistics, I just pulled that out of my ass, but I'm willing to wager it's true) it's used for encoding pirated content. So to summarize, a) the developers are not making any money off it, so they're hardly concerned in losing any business, b) the users are hardly interested in complying with IP laws.
That makes x.264 (in it's current form and distribution method) illegal, and the MPEGLA could shut it down whenever they like. As it happens to be on of few decent encoders out there they seem to be tolerating the project, and only targeting people with business interests.
Or perhaps the developers live outside of the US, and thus are not subject to your retarded patent laws.
But this really depends on the file system - XFS or JFS are very good with quick deletions, I've never had to enable that feature when using XFS. Just make sure you mount the drive with a reasonably large allocsize, say 512m. (That is, provided that you have a drive dedicated for MythTV recordings. Such allocsize would obviously be wrong for a general file system. And when using XFS it doesn't hurt to defrag every now and then, it can be done while the drive is mounted and in use)
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.
Keep plucking that chicken...
Isn't image rollover part of the HTML standard?
No, back in the day it was inline Javascript with onmouseover/onmouseout events (even with image preloading if you were "fancy") - now that IE6 is finally starting to fade away (IE6 only supports the :hover pseudo selector on anchor tags) there's no reason not to use CSS sprites, which means no more superficial attributes or Javascript for rollovers.
I don't like the carrier having control of software
So you prefer Apple having control of software?