Just clear up the impression of the personal dig, I don't hate Gentoo. It's interesting and amusing, and true to it's "ricer" image it's great fun to tinker with and tweak, to solve those little puzzles it's always throwing at you. Sometimes I'm in the mood for that, and I enjoy it.
At other times, though, I require my computer to be a tool I use for work, and I don't want to be interrupted and to have to spend two days tracking down why sound failed _this_ time, just so I can have tunes while I work. (Or worse yet, why X won't run when I need something that's in an X-based app.)
I think gentoo's advantages are mostly imagined and/or exaggerated. I notice this is frequently from people who like to spread FUD about RedHat, or binary distros in general. While I don't like where the RedHat distros are right now, I think they're a very valid, useful, valuable way to do things if you just need a system that does it's job.
Unlike a majority of the LUG members, I don't write code, for a living or for fun. I know six mostly obsolete programming languages, and I can make scripts do some pretty amazing things, but I don't code. That means that some things that are important to coders aren't as important to me.
I mainly mean to advocate the good qualities of binary distributions in general, and RPM based systems in particular. I mean to correct some of the exaggerated claims so that people who haven't tried gentoo or an RPM distro aren't misled.
Just clear up the impression of the personal dig, I don't hate Gentoo. It's interesting and amusing, and true to it's "ricer" image it's great fun to tinker with and tweak, to solve those little puzzles it's always throwing at you. Sometimes I'm in the mood for that, and I enjoy it.
Well, most Non-Linux users think all who use Linux are a kind of "ricer" or uber geek. I don't think there exists a Linux user out there that doesn't like to tinker or solve puzzles.
At other times, though, I require my computer to be a tool I use for work, and I don't want to be interrupted and to have to spend two days tracking down why sound failed _this_ time, just so I can have tunes while I work. (Or worse yet, why X won't run when I need something that's in an X-based app.)
Ok, still don't see why that's a Gentoo problem. I guess I'm lucky, but I've never had these issues.
I think gentoo's advantages are mostly imagined and/or exaggerated. I notice this is frequently from people who like to spread FUD about RedHat, or binary distros in general. While I don't like where the RedHat distros are right now, I think they're a very valid, useful, valuable way to do things if you just need a system that does it's job.
I have nothing against RPM distros. I just choose to use Gentoo. I however, am not spreading FUD about them, unlike some vocal Gentoo haters out there. I think maybe your frustrations come from your lack of understanding Gentoo and your unwillingness or lack of patience to learn.
I mainly mean to advocate the good qualities of binary distributions in general, and RPM based systems in particular. I mean to correct some of the exaggerated claims so that people who haven't tried gentoo or an RPM distro aren't misled.
Advocating quality of one distro by spreading fud about another does not help anyone. I for one hope that your comments haven't scared anyone away from trying Gentoo. I only ask that people try it for themselves and form their own opinions. Don't listen to overly negative and biased vocal critics. Gentoo has wonderful install guides and wikis out there. Always take the time to read them thru its entirely before starting.
This has raised a query. It seems the main points of divergence in Gentoo from other Distros are obtuse rules to install/maintain and a tendency to "break" on updates in ways needing research to fix.
From those 2 points I ask 2 questions.
Is there any automation of the install/maintain operations that "just plain works" ?
is there any method of directing an update to"roll back" to the last stable pre-update state if an update breaks?
On Sunday 07 January 2007 18:48, Oren Beck wrote:
Is there any automation of the install/maintain operations that "just plain works" ?
In general, most stuff does just plain work. The only manual operation required in regular use is merging configuration files when they change. There is a tool to assist in this by diffing the current and new configurations.
is there any method of directing an update to"roll back" to the last stable pre-update state if an update breaks?
If an update won't build, it will never be installed. There is a relatively new function in ebuilds for including tests that can be enabled. In this case, the new version will be tested before it is ever installed. If there are no tests available, or you have them disabled (default, as many tests are very time consuming and may add dependencies), your computer has no automated way to determine if the new version works or not. You can usually downgrade back to an old version manually, and I recommend using Subversion on /etc to rollback configuration changes. I always enable the "buildpkg" feature by default-- this tells Portage to make binary packages of everything you install. This way, you can use the -k switch with emerge to avoid a recompile time should you need to downgrade something.
On Sunday 07 January 2007 13:34, Luke-Jr wrote:
is there any method of directing an update to"roll back" to the last stable pre-update state if an update breaks?
If an update won't build, it will never be installed.
The problem is if you're doing a broad installation, as in update world which installs all updated packages, and you upgrade yourself into version-incompatibility, where some essential system will not run because one or more packages that DID install is incompatible with one that could not.
On Sunday 07 January 2007 19:56, Jonathan Hutchins wrote:
On Sunday 07 January 2007 13:34, Luke-Jr wrote:
is there any method of directing an update to"roll back" to the last stable pre-update state if an update breaks?
If an update won't build, it will never be installed.
The problem is if you're doing a broad installation, as in update world which installs all updated packages, and you upgrade yourself into version-incompatibility, where some essential system will not run because one or more packages that DID install is incompatible with one that could not.
True, except that no essential system package depends on anything with this problem generally.
On 1/7/07, Luke-Jr luke@dashjr.org wrote:
On Sunday 07 January 2007 19:56, Jonathan Hutchins wrote:
On Sunday 07 January 2007 13:34, Luke-Jr wrote:
The problem is if you're doing a broad installation, as in update world which installs all updated packages, and you upgrade yourself into version-incompatibility, where some essential system will not run because one or more packages that DID install is incompatible with one that could not.
True, except that no essential system package depends on anything with this problem generally.
of course, "essential" is highly subjective. With the current vast expanse of hard drive space, it can make sense to keep not just /etc/ but your whole damn system in a subversion respository. svn as backup software!
On Monday 08 January 2007 05:14, you wrote:
On 1/7/07, Luke-Jr luke@dashjr.org wrote:
On Sunday 07 January 2007 19:56, Jonathan Hutchins wrote:
On Sunday 07 January 2007 13:34, Luke-Jr wrote:
The problem is if you're doing a broad installation, as in update world which installs all updated packages, and you upgrade yourself into version-incompatibility, where some essential system will not run because one or more packages that DID install is incompatible with one that could not.
True, except that no essential system package depends on anything with this problem generally.
of course, "essential" is highly subjective. With the current vast expanse of hard drive space, it can make sense to keep not just /etc/ but your whole damn system in a subversion respository. svn as backup software!
Haha, maybe-- but I'd prefer that be done on the filesystem level when you do that.
The problem with Subversion for this, and why it won't work too great outside of configs, is that it doesn't store owner/group or permissions at all.
On 1/8/07, Luke-Jr luke@dashjr.org wrote:
The problem with Subversion for [complete system backup], and why it won't work too great outside of configs, is that it doesn't store owner/group or permissions at all.
shouldn't be too hard to add. As well as some repo-repo rsync scripting such as available (for sale? not sure) from wandisco. Or an 'svn ignore' primitive that adds file names to the ignore property :)
the problem with svn patches is that everyone who uses svn is too busy working on whatever they're using it for to be motivated to add incremental improvements :)
On Monday 08 January 2007 06:12, you wrote:
On 1/8/07, Luke-Jr luke@dashjr.org wrote:
The problem with Subversion for [complete system backup], and why it won't work too great outside of configs, is that it doesn't store owner/group or permissions at all.
shouldn't be too hard to add. As well as some repo-repo rsync scripting such as available (for sale? not sure) from wandisco. Or an 'svn ignore' primitive that adds file names to the ignore property :)
Subversion is based on the concept of a single repository. If you want multiple repositories, I'd suggest patching Darcs up to support history.
the problem with svn patches is that everyone who uses svn is too busy working on whatever they're using it for to be motivated to add incremental improvements :)
Svn works "good enough" for what a lot of people need. People who need more usually need a lot more, and move to Darcs, Git, or something more powerful.
On Mon, 8 Jan 2007, Luke-Jr wrote:
of course, "essential" is highly subjective. With the current vast expanse of hard drive space, it can make sense to keep not just /etc/ but your whole damn system in a subversion respository. svn as backup software!
Haha, maybe-- but I'd prefer that be done on the filesystem level when you do that.
The problem with Subversion for this, and why it won't work too great outside of configs, is that it doesn't store owner/group or permissions at all.
It may not do it automatically, but it can do it in a very unobtrusive manner by setting a property on the file. I see a 6 or so line shell script that will get subversion to do what is desired.
On Sunday 07 January 2007 23:14, David Nicol wrote:
With the current vast expanse of hard drive space, it can make sense to keep not just /etc/ but your whole damn system in a subversion respository. svn as backup software!
True - if you're running on a nice new box.
Subversion (svn) for local version control isn't exactly kid's play to set up, not the sort of thing a new user would want to venture into. Maybe a brief guide on what you have in mind would be a good howto for the LUG site.
One of the nice things about DEC VMS was that it's filesystem included configurable levels of version, with the ability for users to configure it for their own folders iirc. Do you suppose the reason that Linux has never seriously worked with a versioning filesystem is that Microsoft has never considered it important?
I suppose running an rsync snapshot of a system just before an update would give you a quick-and-easy rollback option.
On Monday 08 January 2007 09:29, Jonathan Hutchins wrote:
Maybe a brief guide on what you have in mind would be a good howto for the LUG site.
What I have in mind is moving the "undo buffer" to the file itself, and allowing people to "tag" their files with versions instead of saving.
I suppose running an rsync snapshot of a system just before an update would give you a quick-and-easy rollback option.
I don't think rsync handles permissions/ownership either.
On Monday 08 January 2007 10:36, Luke -Jr wrote:
What I have in mind is moving the "undo buffer" to the file itself, and allowing people to "tag" their files with versions instead of saving.
That's what a versioning filesystem does. I believe IBM may have a Linux-compatible system.
On 1/8/07, Luke -Jr luke@dashjr.org wrote:
I suppose running an rsync snapshot of a system just before an update would give you a quick-and-easy rollback option.
I don't think rsync handles permissions/ownership either.
in general, ownerships are more hassle than their worth when putting something up for public rsync, or even local rsync unless you've actually got synchonized UIDs over your whole network (which is not that high of a bar, but no place I've ever worked has actually implemented it, what with the unices being somewhat of a redheaded stepchild in a Redmond-dominated world)
(note to tactical syntax committee: work "Redmonded stepchild" into common parlance)
<voice tone="obiwan">Read the man page, Luke</voice>
rsync(1) claims: Some of the additional features of rsync are: * support for copying links, devices, owners, groups, and permissions
On 1/8/07, Luke -Jr luke@dashjr.org wrote:
I don't think rsync handles permissions/ownership either.
It has the option to preserve them. I usually just use the "archvie" flag, which combines several including perserve owner/permission.
I've got a good friend that was given just that job as his first task when he started as a contractor at DST. He had to come up with a system that would scan all files on each system and create a report to tell the sysadmins what to change on the hundreds/thousands of systems they have to consolidate and unify UIDs. It was then up the the admins to make changes as needed so that it wouldn't break anything during the process.
Jon.
On 1/8/07, David Nicol davidnicol@gmail.com wrote:
in general, ownerships are more hassle than their worth when putting something up for public rsync, or even local rsync unless you've actually got synchonized UIDs over your whole network (which is not that high of a bar, but no place I've ever worked has actually implemented it, what with the unices being somewhat of a redheaded stepchild in a Redmond-dominated world)
On 1/9/07, Jon Pruente jdpruente@gmail.com wrote:
tell the sysadmins what to change on the hundreds/thousands of systems they have to consolidate and unify UIDs. It was then up the the admins to make changes as needed so that it wouldn't break anything during the process.
Jon.
The argument against unifying UIDs accross your enterprise is that it allows for security holes to become larger. Hopefully DST has some continuing intrusion monitoring in place before (or at least contemporaneously with) their unification effort.
As I understand it they've got some big iron off 435 and 63rd for a main data center. They've got a second, fail over, site in St. Louis that they physically test once a month (as in kill connections here and see if STL picks up) and a whole bunch of smaller setups all over. They've got some machines that have been *on* for about 30 years. I really do hope they've got good security too, but with their history in the industry, I think they do. I'm fairly sure that's why my friends project only made the suggestion of what to change, and would allow the local admin for each machine to have the final decision of what to change.
Jon.
The argument against unifying UIDs accross your enterprise is that it allows for security holes to become larger. Hopefully DST has some continuing intrusion monitoring in place before (or at least contemporaneously with) their unification effort.
On Sunday 07 January 2007 23:02, Luke-Jr wrote:
True, except that no essential system package depends on anything with this problem generally.
You know, I wouldn't have mentioned the problem if I hadn't had it. I'm not making this stuff up. I'm not sure what kind of response you expect here. "Oh, no, that never really happened"? Except it did.
I could give you more examples of specific problems I've had with gentoo, largely due to bad packaging, but as you've pointed out that ends up being a very negative rant, and I don't mean it.
So rather than beat it into the ground, I'll just let what I've said stand.
-
D. Hageman -
David Nicol -
Jeremy Fowler -
Jon Pruente -
Jonathan Hutchins -
Luke -Jr -
Luke-Jr
-
Oren Beck