[renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

lseubert · 2009-09-01 13:26:57

DonVla wrote:

come on, guys!
1) "Enhancing Arch Linux Stability -> Consider Using yaourt to Simplify SysAdmin Tasks ????"
if you want to _enhance_ stability, don´t use yaourt _at all_.
and last but not least: trust only tools you´ve written yourself.:D

DonVla - you'll pardon me if I take your trashing of yaourt with a grain of salt, yes? You are the author of pkgman, which provides some of the same functions as yaourt. So, from your perspective, yaourt is a sort of competitor with your pkgman, is it not?

Also, if I should only trust the tools I wrote myself, and since I didn't write pkgman, I guess this means that I can not trust it? (And I guess by that logic, I now have to go write my own kernel and complete userland. Excuse me fellas, I'll be back - but I'm gonna be busy for the next ten years. )

DonVla wrote:

2) if you want to have a "rock-solid" arch system, i´d suggest to setup and use your own repository for critical packages rather then having two or more lines of "IgnorePkg" entries.
if you want to have a stable system set up an own repo with _working and stable_ versions of packages. that´s how i handle this. sure, you have ti keep track of dependencies, but you have to do this anyway.
i use metapackages to downgrade critical packages and their dependencies. i describe this on this thread:
http://bbs.archlinux.org/viewtopic.php? … 64#p588564

That's a good idea. For some people, the IgonorePkg option is good, but for others, setting up a separate repository is a better way to go. Would you please consider writing this up for the wikipage?

DonVla wrote:

3) "Use Recommended Configurations" + "Select the Core and Extra Software Repositories" = start using debian...

Heh. Well, I don't know about that. I followed recommended configurations in my set up, but I do have some bits from Community and AUR. I think the defaults make good sense, and my system is much better now that what I was running before, which was sidux - a stabilized version of Debian unstable. Arch is far more up to date, and significantly more stable.

DonVla wrote:

4) " Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible." what does this have to do with stability? qt apps do not crash, because gtk is installed... at least here on my machine.

Very well. That bit is removed.

zodmaner · 2009-09-01 13:29:00

lseubert wrote:

But sand_man, you seem to make the case here that yaourt alone has the power to run the malicious code in a bad PKGBUILD. Is this really the case? Can not makepkg or any of the many AUR Helpers also run the malicious code found in a bad PKGBUILD?

Makepkg or any other AUR helpers program can run malicious code in a bad PKGBUILD during build. That is way it is advisable to read PKGBUILD from AUR before you build them. This is also why yaourt show you the package's PKGBUILD before it build and install them for you.

Last edited by zodmaner (2009-09-01 13:30:06)

shining · 2009-09-01 13:30:00

lseubert wrote:

DonVla wrote:
come on, guys!
1) "Enhancing Arch Linux Stability -> Consider Using yaourt to Simplify SysAdmin Tasks ????"
if you want to _enhance_ stability, don´t use yaourt _at all_.
and last but not least: trust only tools you´ve written yourself.:D
DonVla - you'll pardon me if I take your trashing of yaourt with a grain of salt, yes? You are the author of pkgman, which provides some of the same functions as yaourt. So, from your perspective, yaourt is a sort of competitor with your pkgman, is it not?

what about the simple and general rule :
don't use unofficial tools

lseubert · 2009-09-01 13:50:15

zodmaner wrote:

Don't you think this suggestion is a bit too excessive?
I mean, sure there are a lot of poor quality PKGBUILD in AUR, but stll there are a number of PKGBUILD that are very well made and work great.
Also, from my personal experience, packages in community isn't really that "not well tested" or "not mainstream" compare to those in core or extra. Aside from patching issue that dolby mentioned, quality of packages in community repository isn't that different than those in core and extra. Hell, a lot of current packages in community used to be in core or extra.
In short, you can't "judge" quality of a package by which repositories it's in. You have to look at the package's PKGBUILD itself to do that.

I agree that there are some very good PKGBUILDs in AUR. However, out of the 15,000 PKGBUILDs that are in AUR these days, how does one readily distinguish between the good ones, and the bad ones. Aside from reading all those PKGBUILD files, that is?

In the end, overall, the AUR does not have the quality of core and extra. One can make a good case for the idea that greater package quality = greater stability. Therefore, the wikipage advocates using the most stable repositories, and avoiding the less stable ones.

You are right - community is a sort of middle ground, with a fair number of very good packages. But again, how is one to quickly and easily suss out the really good ones from the not so good? From what others have posted in this thread, there are a fair number of packages in community that break Arch Packaging Guidelines. As such, the quality of community overall is suspect by comparison with core and extra.

zodmaner wrote:

I also agreed with DonVla about the article's comment on GTK and QT:
Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.
Are these comment about having a lean system or stable system? Because I think you're confusing the two issues here.
Install GTK and QT together doesn't make system more unstable,
I'm sorry guys, I know you put a lot of effort into this, but this part about GTK/QT and "don't install software with duplicate functionalities" is simply just a bad, nonsensical, advise.

Point taken. I have removed that material.

May I make a point? Ask yourself how much time it took you to quote DonVla and then write the comments above, versus how long it would have taken you to edit out one sentence from that wikipage section? I appreciate your taking the time to discuss this in a collaborative manner, but this is a wiki, and people can just edit it. Other folks have edited the page without there being any problems.

zodmaner wrote:

I mean, since when is having a buggy software installed also make your other software more buggy? It is very _very_ rare to find a buggy program that, when crash, will take the entire OS down with you (this isn't Windows, mind you). Just ask around the forum (or IRC) and you will see that there are tons of people install multiple DE/WM and have very little or no problem at all.
In fact, I will even go so far as to say that having a multiple DE/WM should be semi-encourage, since if your current DE/WM (or whatever) have a fatal bug/crash that can't be recover from, you can switch to your other DE/WM and continue your work.

You raise a good point about having a backup DE/WM, although I find it best to resort to the CLI and one of the six terminals if something goes kerflooey.

However, I think my point about lean and spare = more stable has some validity. The smaller and simpler a system is, the less there is that can go wrong and cause problems. The more parts; the more parts that interact in myriad ways; the more complex and interlinked - the more that can go wrong.

Feel free to rewrite the bits about multiple DE/WM's - I can see your pont there. But consider the very real advantages of minimalism in enhancing stability. There is a reason why SysAdmins don't install KDE/Gnome onto web servers.

lseubert · 2009-09-01 13:58:48

shining wrote:

what about the simple and general rule :
don't use unofficial tools

Does Arch provide an official tool that easily handles PKGBUILDs from AUR? No.

Is it sometimes absolutely necessary for some people to install software from AUR? Yes.

In the absence of an official tool, but the occasional need to install software from an unofficial repository, a thorough and complete "Enhancing Arch Linux Stability" wiki should provide some sort of answer.

One answer is to download PKGBUILDs from AUR one by one, and install them with makepkg. That is great for people with lots of spare time and SysAdmins who get paid by the hour. (But then - those sorts of people should be running LFS and Gentoo, not Arch )

The other answer is to recommend the most widely used and featureful AUR helper tool, and provide lots of warnings about its potential misuse, and how to avoid such problems. That is what this page does.

lseubert · 2009-09-01 14:55:04

Responding to Critiques About Use of AUR and Yaourt

I have strengthened the language warning against the use of AUR, including explaining why it is hazardous. People reading this wiki will now understand why stable system users should avoid AUR, as well as testing and 3rd party repositories. This material is reproduced below.

Additionally, Ranguvar has significanyly upgraded the material on using yaourt. He provides warnings about what it does with respect to AUR, including enough detail that people reading the wiki should clearly understand the why's and wherefore's of AUR PKGBUILD hazards. Ranguvar also explains how Yaourt actually helps users to avoid these problems, by making it bog easy to read the PKGBUILD and .install files before running the scripts. The wiki strongly advises doing so. This material is also reproduced below.

If folks still have problems with these warnings and recommended uses, please edit the wikipage to improve the language, clarifying it and making it more accurate. But please accept that some people who need to run a stable system also need to use AUR, and so this knowledge does belong in the "Enhancing Arch Linux Stability" wikipage.

Select the Core and Extra Software Repositories
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. Information on how to do this is found in the Repositories section of the Pacman Arch wikipage.
If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra.
Only use AUR and 3rd party repositories if absolutely necessary. The AUR and various 3rd party repositories are not official Arch packages. Such packages may be buggy, or they may contain malicious code. Only use such packages on a stable system if absolutely necessary, and only after following precautions. See the section below on using Using Yaourt to Simplify SysAdmin Tasks for more details.
Avoid any use of the testing repository, or individual packages from testing. These experimental packages are for development and testing, and are not suitable for a stable system.

Consider Using yaourt to Simplify SysAdmin Tasks
Yaourt, which stands for Yet AnOther User Repository Tool, is a wrapper for pacman. Yaourt provides a variety of useful package management services, in addition to those provided by pacman. It uses the same command syntax as pacman, and invokes pacman to perform many functions.
Yaourt also simplifies several important SysAdmin tasks. After removing a package, yaourt immediately identifies orphan dependencies and offers to quickly remove them as well. Yaourt provides an easy way to make timestamped snapshot backups of the pacman database. Finally, yaourt provides the pacdiffviewer tool, which greatly simplifies finding and dealing with .pacnew and .pacsave files.
Information about installing yaourt is found on the yaourt Arch wikipage. Detailed usage instructions are available through the command:
yaourt -h
Be aware that one of the functions of yaourt is to easily install packages from the AUR. AUR PKGBUILD files have not undergone the thorough vetting of the packages found in core and extra, and might not be as stable. Furthermore, AUR packages present potentially serious security risks. Yaourt executes user-submitted Bash scripts which may delete, by malicious design or by accident, any file to which the user has write permissions. Anything you can do in your user's Bash shell, the AUR package installation can do. However, Yaourt provides a means of reading through the PKGBUILD and *.install files of AUR packages prior to build and install. Doing so is highly recommended. Finally, it is extremely unwise to ever run yaourt or the manual tool makepkg as the root user.

zodmaner · 2009-09-01 15:05:33

lseubert wrote:

May I make a point? Ask yourself how much time it took you to quote DonVla and then write the comments above, versus how long it would have taken you to edit out one sentence from that wikipage section? I appreciate your taking the time to discuss this in a collaborative manner, but this is a wiki, and people can just edit it. Other folks have edited the page without there being any problems.

Point taken. I will use my energy to edit the article next time that I found an error/mistake.

lseubert · 2009-09-01 15:39:30

bangkok_manouel wrote:

Avoid_Certain_Pacman_Commands
this will sound obvious but I think it is be a bit misleading in the article. it is absolutely safe to run pacman -S <pkg> (only -Sy /edit: or -Syy/ <pkg> is evil), you don't _have_ to -Syu first. the only problem you may encounter is that the pkg is not found because it has been replaced by a newer version and therefore is not available on the mirror anymore.

You're right - it is slightly misleading, but it is also near absolutely bulletproof, is it not?

I refer here to the following command:

pacman -Syu && pacman -S Package-Name

Still, the advice you suggest, 'pacman -S Package-Name', is more conventional, and will work perfectly well 99.99% of the time.

Which do you think is better? Conventional simplicity or nearly absolute bulletproof-ness?

shining · 2009-09-01 15:42:29

lseubert wrote:

Which do you think is better? Conventional simplicity or nearly absolute bulletproof-ness?

I want simplicity and absolute bulletproof-ness :
never run pacman -Sy or pacman -Sy pkg if you don't know what you are doing.
only run pacman -Syu to sysupgrade and pacman -S pkg to install a package

bangkok_manouel · 2009-09-01 15:54:45

lseubert wrote:

bangkok_manouel wrote:
Avoid_Certain_Pacman_Commands
this will sound obvious but I think it is be a bit misleading in the article. it is absolutely safe to run pacman -S <pkg> (only -Sy /edit: or -Syy/ <pkg> is evil), you don't _have_ to -Syu first. the only problem you may encounter is that the pkg is not found because it has been replaced by a newer version and therefore is not available on the mirror anymore.
You're right - it is slightly misleading, but it is also near absolutely bulletproof, is it not?
I refer here to the following command:
pacman -Syu && pacman -S Package-Name
Still, the advice you suggest, 'pacman -S Package-Name', is more conventional, and will work perfectly well 99.99% of the time.
Which do you think is better? Conventional simplicity or nearly absolute bulletproof-ness?

point is you don't necessary want to update your whole system each time you want to install a package.

lseubert · 2009-09-01 16:32:57

shining wrote:

I want simplicity and absolute bulletproof-ness :
never run pacman -Sy or pacman -Sy pkg if you don't know what you are doing.

Agreed.

shining wrote:

only run pacman -Syu to sysupgrade and pacman -S pkg to install a package

bangkok_manouel wrote:

point is you don't necessary want to update your whole system each time you want to install a package.

OK, I would prefer the commands that shining listed too - for the sake of simplicity. But a problem can occur when you run pacman -S Package-Name but haven't run pacman -Syu for a fair amount of time. And I quote....

bangkok_manouel wrote:

the only problem you may encounter is that the pkg is not found because it has been replaced by a newer version and therefore is not available on the mirror anymore.

Keeping pacman -Syu and pacman -S Package-Name separate is simpler, and more "correct", and certainly more conventional. And pacman -S Package-Name will work the vast majority of the time. But what about those times that bangkok_manouel mentioned? What then?

Yes, the command 'pacman -Syu && pacman -S Package-Name' is awkward, but it does correctly synchronize the online and local pacman databases, ensuring that pacman -S Package-Name always works correctly.

What is the preference here? Simplicity and conventionality, or near absolute bulletproof-ness?

I am cool with either proposed alternative, or perhaps a more elegant version of 'pacman -Syu && pacman -S Package-Name', since 'pacman -Sy Package-Name' is unacceptable for synchronizing the two database versions and then installing a package.

I just want to make sure that we all understand what is gained and lost with the various choices. Bangkok_Manouel has raised a concern that is not addressed with separate commands.

bangkok_manouel · 2009-09-01 16:49:21

if you really do not want to update your machine and the package is not on the mirrors anymore then you can use ABS to build the package against your current system. if the version of the PKGBUILD provided by ABS enables new features that require a system upgrade then use SVN to get the same PKGBUILD version as the one in your db.

edit: BTW, there are some mirrors that keep all the former versions of packages IIRC.

Last edited by bangkok_manouel (2009-09-01 16:52:05)

zodmaner · 2009-09-01 16:51:29

Sorry, I re-read your reply and this part still bugged me:

lseubert wrote:

However, I think my point about lean and spare = more stable has some validity. The smaller and simpler a system is, the less there is that can go wrong and cause problems. The more parts; the more parts that interact in myriad ways; the more complex and interlinked - the more that can go wrong.
Feel free to rewrite the bits about multiple DE/WM's - I can see your pont there. But consider the very real advantages of minimalism in enhancing stability. There is a reason why SysAdmins don't install KDE/Gnome onto web servers.

I still insisted that lean system does not equal stable system.

The point here is not how many softwares (or packages) you have installed on your system, but which one do you choose to use. If you only use rock-solid software, such as CLI web browser like w3m, then that buggy Chromium 64 bit sitting in your /opt directory with it's buggy code won't "interact" with it and causes it, or other part of your system, to go unstable. On the other hand, if you use unstable software/package, such as for example chromium-64bit-latest-git-alpha, then your system will be quite unstable even if you install only 4 packages on your system.

Simply put, using simple/stable softwares lead to stable system. The number of packages installed have nothing to do with system's stability.

Your comment: "The more parts; the more parts that interact in myriad ways; the more complex and interlinked - the more that can go wrong." is only true when we talk about a specific piece of software, and not the entire system.

Case in point: CLI is more stable than X.org, Gnome, KDE because it has fewer pieces of dependencies and libraries and thus fewer chances of something goes wrong. This is true. But a system which have Gnome, KDE, Xfce, e17 and tons of other packages installed isn't more unstable than a system which only have one DE or none of DE/WM installed.

Why? Because at least on a Linux system, softwares doesn't interact with each other just because they are installed on the same system, they interact only when they are a dependency of each other. This is the same argument as to why install GTK and QT at the same time does not cause problem. I use Openbox as my main WM of choice, I also have KDE 4.x installed on the same system (for testing and trying out stuffs). As I mainly use GTK applications that have next to no dependency/link to KDE or QT, my "main" DE/WM, the Openbox, is very stable and have been for the last 2 years, while when I'm using KDE I run into quite a lot of problems, from minor application crashing to system freezes. Your system can be both stable and unstable, depend on what stack of softwares you choose to use at the time.

In short, the reason I'm so serious about this issue is because you're advocating a wrong practice. Install fewer packages or don't install package that you don't need isn't a way to have a stable system. Software that doesn't link to each other won't effect each other! The only thing you will achieve by install few stuffs or the things you need is that you'll save your hard disk space.

If you want a stable system, then install and use a simple software. Small software that does one thing. Software that have few dependencies. The fewer dependencies, the better, as they have fewer parts to go wrong. Thus this is why many here prefers Openbox or WM to DE, such as Gnome or KDE. With WM such as Openbox and other small applications, you get a very stable system thanks to the fact that these programs are small, simple and mostly self-contain. Complex (meaning, for example, having tons of dependencies) software can also be use if you're certain it's stable enough.

IMHO, the greatest strength of Linux is that you can install and try out many different type of programs at the same time without having to worry about your system stability because Linux is such a compartmentalized system that you don't have to worry about buggy/bad/unstable software affecting a good software (well, not too much anyway ). What to try out KDE? Install it! It freezes your system? Uninstall it! Or better yet, keep it and switch to your other DE/WM and wait for it to stable before try it out again. With pacman, this is even easier, since pacman can install/delete packages with such efficiency that you don't have to worry about any leftover file that might clutter or cause your system to misbehave.

Yes, I realize that I just cooked up another post with time best spent on improving the wiki, someone please shoot me...

Edit: After thinking about it some more, I think I know where your misconception comes from. A system which mainly consisted of simple softwares will likely to be more stable. These system, as a result of using simple softwares, will tend to have fewer packages than most system, since simple software have fewer dependencies. Thus it can be (falsely) concluded that fewer packages leads to stable system. Which is _not_ true, as I have illustrated above.

Edit2: With all that said and done, I really appreciated the time and care you took in creating the article and answer all questions/discussions in this thread, lseubert. I wish I have 1/10th of your energy and effort that you've shown.

Last edited by zodmaner (2009-09-01 17:38:48)

shining · 2009-09-01 17:50:31

lseubert wrote:

I just want to make sure that we all understand what is gained and lost with the various choices. Bangkok_Manouel has raised a concern that is not addressed with separate commands.

This concern is addressed by updating the system regularly, as I wrote here :
http://wiki.archlinux.org/index.php?tit … ldid=74942

otherwise, if the new package in the mirror is a rebuild, and you don't want to do a system upgrade, your only option is to backport this package, by compiling it manually against your system libraries.

shining · 2009-09-01 17:52:20

zodmaner wrote:

The point here is not how many softwares (or packages) you have installed on your system, but which one do you choose to use.

long post is long

Anyway, I completely agree with this sentence, so I removed the corresponding section in the wiki.
http://wiki.archlinux.org/index.php?tit … ldid=74932

DonVla · 2009-09-01 18:26:54

imo the whole discussion moves in the wrong direction.
are we talking about a "stable" _arch_ or a stable _linux_ system.
if one wants to have stability in the sense of running a stable server with an uptime of months even years, then arch is definitely the wrong distro - that does not mean that one could not try it, but there are distros out there designed for this kind of usage.
however, if one wants to have a stable arch system, he/she should simply stick with the upstream, should not use external (untrusted) repos, not use other applications but the official ones and simply use common sense.
why not use community or even AUR? when you just read the PKGBUILD and see that everything is fine, why not compile and install a package yourself?
further the choice of software has nothing to do with the stability of the system. sure it does not make sense to use eclipse to edit a simple text file, but on the other hand eclipse might come in handy someday... on my system i have about 6.5gb of software and have uptimes of 10 days or more. i use suspend.
http://wiki.archlinux.org/index.php?tit … urge_Cruft
i also would not recommend to use "pacman -Rs $(pacman -Qtdq)". most of the packages shown by pacman -Qtdq are packages installed as makedepends (at least here on my system), one might want to delete them, but then has to reinstall them everytime a package is built. has also nothing to do with stability.

Last edited by DonVla (2009-09-01 18:44:38)

shining · 2009-09-01 18:54:49

DonVla wrote:

however, if one wants to have a stable arch system, he/she should simply stick with the upstream, should not use external (untrusted) repos, not use other applications but the official ones and simply use common sense.
why not use community or even AUR? when you just read the PKGBUILD and see that everything is fine, why not compile and install a package yourself?

As far as I can see, this is the kind of advices that appear on that wiki page.

i also would not recommend to use "pacman -Rs $(pacman -Qtdq)". most of the packages shown by pacman -Qtdq are packages installed as makedepends (at least here on my system), one might want to delete them, but then has to reinstall them everytime a package is built. has also nothing to do with stability.

It indeed has nothing to do with stability, so I removed that section too :
http://wiki.archlinux.org/index.php?tit … ldid=74933

Ranguvar · 2009-09-01 20:03:06

Actually, I think that command _does_ have to do with stability. You keep the number of packages on your machine to an absoule minimum, and software that isn't there cannot be exploited. Not a big concern, but still. If you don't want certain makedepends removed, make them explicitly installed packages.

lseubert · 2009-09-01 20:45:21

shining wrote:

It indeed has nothing to do with stability, so I removed that section too :

Shining, I notice that you are purging various bits associated with rapid system recovery. You did forget to remove a sentence from the Introduction though:

Furthermore, advice is included that will ease system repair in the event of a major malfunction.

Now, if you think it best to purge all the little system recovery bits, fine. Doing so requires careful and thorough reading and re-reading of the whole document - a lot of work, yes?

Do you think there is significant harm in having system recovery information in a wiki about system stability? It seems to me that setting your system up for rapid recovery after a major meltdown enhances overall system stability.

If you disagree, I can strip out all the other system recovery bits and put them in another wiki which deals specifically with system recovery. Would you care to help with such an endeavor?

Garns · 2009-09-01 20:56:22

Ranguvar wrote:

Actually, I think that command _does_ have to do with stability. You keep the number of packages on your machine to an absoule minimum, and software that isn't there cannot be exploited. Not a big concern, but still. If you don't want certain makedepends removed, make them explicitly installed packages.

Hm, imho stability and security are two pretty different things, a stable system is not necessarily secure. Maybe you could argue that secure systems tend to be more stable, but that is somewhat the other way round.

Now you could argue that lacking security leads to instability, because you have to deal with break ins or whatever. But that totally depends on your system: Let's say you have a Desktop PC (secured behind a decent firewall, with you as the only one in the local network and with physical access), you need that machine for your job, so you want stability, but one app, or a combination of apps on your harddrive, which you assume could perhaps eventually be exploited to gain root access does not seem too worrying. On the other hand, if you are running a webserver, you probably want secure and stable.

zodmaner · 2009-09-02 03:12:27

lseubert wrote:

Shining, I notice that you are purging various bits associated with rapid system recovery.

Could you please clarify on this? Which bits that he removed are you referring to? I've read through most of the recent changes by Shining and I didn't see anything that have to do with rapid system recovery.

Last edited by zodmaner (2009-09-02 03:14:58)

sand_man · 2009-09-02 04:38:29

lseubert wrote:

sand_man wrote:
If you are worried about stability then you should avoid AUR. If there is something in AUR that you need, by all means install it but there is no need to use yaourt. yaourt is great for ease of use but as Ranguvar said, it has the potential to run malicious code if the user is not careful.
Hmm, maybe I don't understand something here.
I understand that installing a PKGBUILD from AUR can result in malicious code being run on my system. And thanks to Ranguvar's editing of the wikipage, exactly how this is done is made very clear. A clear warning of the dangers of AUR and its PKGBUILDS is now on the Enhancing Arch Linux Stability wikipage.
But sand_man, you seem to make the case here that yaourt alone has the power to run the malicious code in a bad PKGBUILD. Is this really the case? Can not makepkg or any of the many AUR Helpers also run the malicious code found in a bad PKGBUILD?
My point here is that while yaourt can be misused, so can any other tool used to access AUR. And if you read the Consider Using yaourt to Simplify SysAdmin Tasks section all the way through, I think you will find that these dangers are thoroughly explained, along with information on how to avoid them.
If you do not find this material sufficient, please edit it so that it is.

I quite like slurpy but I still use yaourt because I'm lazy << that is the kind of attitude that I'm referring to.
"Do as I say not as I do"

shining · 2009-09-02 06:19:35

zodmaner wrote:

lseubert wrote:
Shining, I notice that you are purging various bits associated with rapid system recovery.
Could you please clarify on this? Which bits that he removed are you referring to? I've read through most of the recent changes by Shining and I didn't see anything that have to do with rapid system recovery.

I only removed 2 small sections : Regularly Purge Cruft and Minimize the Number of Installed Packages
and I don't see what this has to do with rapid system recovery either (nor with enhancing stability).

Both changes were backed up by arguments that zodmaner and Donvla developed verbosely in this thread.

I actually completely support several advices given for rapid system recovery, like keeping old packages in pacman cache while the new ones are being tested, and regularly backing up pacman database (and all the other important parts). And all these advices definitely have a place on this page.

broch · 2009-09-03 18:23:20

very interesting litany, not that it has any practical value

kernel26-lts:
broken idea: backporting incompatible (introduced later stuff) often causes problems. Instead apply pacman option:
last good kernel (this would be equivalent of keeping previous version of kernel installed and apropriate entry in GRUB)
Option not existing though.

Being super conservative (why not go for 2.4), does not help and with newer hardware always will be problematic.

pacman stuff
I have laptop with smalish disk 60GB, most taken by really big pictures, I don't have space to keep older versions of specific software. Often, one new app requires another dependency being upgraded too.

in short what you suggest is to keep older version of running system. This is really impractical. Does not matter how big is HD.
Besides, pacman does not have an option to keep last version and purge older, in other words, in short time disk is going to be filled up only because system has several versions of kernel, openoffice (God forbid kde, 4.3, 4.3.01, 4.3.1)

Create Arch backup system:
something like LiveCD with real backup software and options:
restore from incremental
restore from differential
restore full

pacman commands:
don't list all commands, better make pacman to ask question if user issues
pacman -Syy && pacman -S package
prompt
"this operation will set pacman db out of sync. it is considered dangerous. Do you want to proceed? y/n"
then pacman do what user wants

listing commands will not help, people will forget, reminding then about issue i may be better (with option -q quiet for savvy arch users)

malicious code in AUR
this is distinguished already in AUR repository:
is developer trusted or not. If this does not work, then warnings will not help: one can get crap with downloaded sources. For this one does not really need AUR.

This forum has users keeping Arch that was installed only once long time ago. Ask them how they perform maintenance.

If someone would really follow all the advice here, then most of the time user would spend on maintaining, not using computer. Forget about tool that requires more time for mantaining than for real, proper use.

shining · 2009-09-03 22:15:48

broch wrote:

very interesting litany, not that it has any practical value

what is litany ?

anyway, congratulations for the most unhelpful and fullest of FUD post yet in this thread

kernel26-lts:
broken idea: backporting incompatible (introduced later stuff) often causes problems. Instead apply pacman option:
last good kernel (this would be equivalent of keeping previous version of kernel installed and apropriate entry in GRUB)
Option not existing though.

this is BS. pacman is a PACKAGE manager, not a kernel manager

Being super conservative (why not go for 2.4), does not help and with newer hardware always will be problematic.

do you even know what fallback mean ?

Comparing 2.6.27 to 2.4 is also quite funny

pacman stuff
I have laptop with smalish disk 60GB, most taken by really big pictures, I don't have space to keep older versions of specific software. Often, one new app requires another dependency being upgraded too.

Then don't, no one is forcing you to follow ALL the advices in that page. Or just buy a bigger disk.

in short what you suggest is to keep older version of running system. This is really impractical. Does not matter how big is HD.
Besides, pacman does not have an option to keep last version and purge older, in other words, in short time disk is going to be filled up only because system has several versions of kernel, openoffice (God forbid kde, 4.3, 4.3.01, 4.3.1)

Then what does -Sc do ?

pacman commands:
don't list all commands, better make pacman to ask question if user issues
pacman -Syy && pacman -S package
prompt
"this operation will set pacman db out of sync. it is considered dangerous. Do you want to proceed? y/n"
then pacman do what user wants
listing commands will not help, people will forget, reminding then about issue i may be better (with option -q quiet for savvy arch users)

You have no idea what && is, do you ?
In the example you gave, pacman is called twice, with absolutely no link between the two runs from pacman point of view.

It would be possible however to prevent pacman -Sy package, but there are two good reasons for not doing that :
1) pacman is not Arch-specific, and there might be distributions using pacman where pacman -Sy package is not dangerous at all
2) pacman does not prevent stupid users from shooting themselves in the foot , because this would also prevent advanced users from doing what they want (a bit like the C language )

malicious code in AUR
this is distinguished already in AUR repository:
is developer trusted or not. If this does not work, then warnings will not help: one can get crap with downloaded sources. For this one does not really need AUR.

I did not even understand what you are saying here, but seeing the quality of the rest, I have no doubt it is as stupid.
There is no distinction at all for the AUR/unsupported repo.

This forum has users keeping Arch that was installed only once long time ago. Ask them how they perform maintenance.

And guess what, some of these users have been editing that wiki page !

If someone would really follow all the advice here, then most of the time user would spend on maintaining, not using computer. Forget about tool that requires more time for mantaining than for real, proper use.

another FUD. most of the advices there are just best practices and common sense, and require very little time

Arch Linux

#51 2009-09-01 13:26:57

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#52 2009-09-01 13:29:00

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#53 2009-09-01 13:30:00

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#54 2009-09-01 13:50:15

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#55 2009-09-01 13:58:48

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#56 2009-09-01 14:55:04

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#57 2009-09-01 15:05:33

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#58 2009-09-01 15:39:30

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#59 2009-09-01 15:42:29

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#60 2009-09-01 15:54:45

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#61 2009-09-01 16:32:57

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#62 2009-09-01 16:49:21

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#63 2009-09-01 16:51:29

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#64 2009-09-01 17:50:31

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#65 2009-09-01 17:52:20

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#66 2009-09-01 18:26:54

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#67 2009-09-01 18:54:49

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#68 2009-09-01 20:03:06

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#69 2009-09-01 20:45:21

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#70 2009-09-01 20:56:22

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#71 2009-09-02 03:12:27

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#72 2009-09-02 04:38:29

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#73 2009-09-02 06:19:35

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#74 2009-09-03 18:23:20

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#75 2009-09-03 22:15:48

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

Board footer