Re: [gentoo-dev] Re: where goes Gentoo?
On 04/08/05 14:37 -0500, Brian D. Harring wrote: snip Hell, I have yet to see what I would define as a proper solution for config manamagent for N gentoo boxes. NFS solution possibly, but that seems a bit hackish to me. http://www.infrastructures.org/ is a good place to start. Devdas Bhagat -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: where goes Gentoo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | eg. If I want to change the subnet mask or default router on 50 machines | on my network, I should be able to do so via a simple interface and have | the work done automatically. That's why we added c3 and clusterssh to the tree. =) Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC8yhRXVaO67S1rtsRAlW4AKCEGoFMs6HqJCTv/wqqcp/xmaEH2QCfUjMB yqD8ydpUcTkSTJ89NdZ3Pxk= =38rv -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: where goes Gentoo?
On Friday 05 August 2005 03:40, Brian D. Harring wrote: On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote: It's not an overnight thing, glep19 (stable portage tree) addresses a chunk of concerns when/if it's implemented, but I'm a bit more interested in the the other tools people desire alongside. Offhand, responding to my own snippet, I'd love to know what's going on with glep19... Not much lately I'm afraid:-/ If anyone is willing to help out I guess a mail to [EMAIL PROTECTED] might get it all (re)started. -- Sune Kloppenborg Jeppesen Gentoo Linux Security Team -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: where goes Gentoo?
On Fri, Aug 05, 2005 at 10:59:23AM +0200, Sune Kloppenborg Jeppesen wrote: On Friday 05 August 2005 03:40, Brian D. Harring wrote: On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote: It's not an overnight thing, glep19 (stable portage tree) addresses a chunk of concerns when/if it's implemented, but I'm a bit more interested in the the other tools people desire alongside. Offhand, responding to my own snippet, I'd love to know what's going on with glep19... Not much lately I'm afraid:-/ If anyone is willing to help out I guess a mail to [EMAIL PROTECTED] might get it all (re)started. Might be better stating what's needed... A) people know what they're inadvertantly getting themselves into B) something might be bloody simple to somebody, and they pick it off when they may not have been willing to take the time and poke and find out what's up C) alternatives might be proposed... So... spill the beans. :P ~harring pgpCjv1R0qwnv.pgp Description: PGP signature
Re: [gentoo-dev] Re: where goes Gentoo?
Sune Kloppenborg Jeppesen wrote: On Friday 05 August 2005 11:07, Brian Harring wrote: Might be better stating what's needed... A) people know what they're inadvertantly getting themselves into http://dev.gentoo.org/~jaervosz/glep19.html B) something might be bloody simple to somebody, and they pick it off when they may not have been willing to take the time and poke and find out what's up C) alternatives might be proposed... Of course, but lets see if we can implement something first, otherwise we'll continue arguing alternatives every ~6 months and never really do anything. Last time around we at least got a bit going, though admittedly not much. Yeah, we started to get somewhere with it, but then some of us got caught up in being busier in real life or other things popped up. But I agree here that we just have to start with something and see where it goes. Too many times have things been debated and nothing ever done/tried. I also tend to agree with Chris that to do it completely right would require a small fork that would work together with Gentoo on archiving its goals. It would be nice to come up with a solution without forking, but I just don't see how it'd be possible and keep things as they should in an enterprise realm. Things are starting to settle down for me again and I would like to jumpstart this project again. -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
RE: [gentoo-dev] Re: where goes Gentoo?
Interesting thread. I have used Gentoo in enterprise situations very successfully, and I think the whole QA/live-tree argument is moot. In an enterprise environment, you might have a backup/testing machine to run your updates on first before they went live. You also wouldn't run new packages unless they passed your own QA tests first. Given the incredible flexibility of portage to support local mirrors, binary package preparation, and localized versions of packages (portdir_overlay), I would say that Gentoo is quite a contender in the enterprise environment. Perhaps we need some enterprise documentation to help people realize the full potential of portage? -Eric -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] Re: where goes Gentoo?
On Thu, 2005-08-04 at 09:04 -0400, Eric Brown wrote: Interesting thread. I have used Gentoo in enterprise situations very successfully, and I think the whole QA/live-tree argument is moot. In an enterprise environment, you might have a backup/testing machine to run your updates on first before they went live. You also wouldn't run new packages unless they passed your own QA tests first. Given the incredible flexibility of portage to support local mirrors, binary package preparation, and localized versions of packages (portdir_overlay), I would say that Gentoo is quite a contender in the enterprise environment. Perhaps we need some enterprise documentation to help people realize the full potential of portage? I think you've missed some of the idea of enterprise support. See, for starters, every person shouldn't have to create their own implementation of everything. Perhaps a better solution would be a package that when installed, builds up a local mirror, a binary package repository (with revision control), an automated update system, a system for updating rolled out machines without forcing the use of etc-update on each machine, a slower moving stable tree capable of being certified with applications, and most likely a phone number of someone to call when the shit hits the fan. While I will completely agree that Gentoo *can* be used in the enterprise successfully, that does not make it enterprise-ready, in any sense. Many people also seem to misunderstand the concept of enterprise when we are referring to it in this manner. We don't mean I'm running it on 10 servers in production or anything like that. We mean I'm running this as our production platform for Linux services across our entire enterprise, that could be hundreds or even thousands of servers instead. While it might be possible to maintain a handful of Gentoo servers, it is next to impossible to maintain an army of them, without spending significant up-front manpower to design, test, and implement your own set of management tools. Gentoo has no real management tools. There are a few here and there that do specific tasks, but there isn't anything designed to really take control over your network of systems. To be fair, Red Hat doesn't have anything like this, either. Their Satellite Server product is good for initial builds and for updates, but falls short on the management aspects. Novell's offerings are probably the best examples of what we really need. Of course, most people would be happy with even rudimentary management capabilities, as currently, we have none. We don't have any form of update server. You have to build one yourself. We don't have any form of jump-start or kickstart for rapid automated deployments. You have to build one yourself. Now, we do have the Gentoo Linux Installer project, which has this as one of its goals, so we will have this component at some point in the future. Last, there's the Our servers just went belly up, and I want to call up someone on the phone and give them a piece of my mind issue which gives managers a warm, fuzzy feeling, that we cannot provide. If something goes wrong with RHEL or SLES, you call up Red Hat or Novell and get them to work on the problem. If something goes wrong with Gentoo, you hop on IRC, or file a bug, and hope that somebody can help you in the time you need it done in, and not in 3 weeks when the maintaining developer gets back from his tour of the African Dung Beetle in it's own environment. Liability is a big selling point for the enterprise. I work for a telecommunications company, and we run Linux and Solaris. For our Linux, we run Red Hat, even though they have, on staff, one of the people that understands Gentoo's deployment capabilities better than most, via catalyst and the GLI. Why do we run Red Hat? When something breaks with one of their packages, we call them, and expect them to fix it. It is also a name that gives upper management the warm fuzzies. Gentoo has neither the brand recognition, nor the support capabilities to be a good sale to management. I'm not denying that Gentoo is very powerful, flexible, and gives the power back to the administrator, but that doesn't make it enterprise ready or friendly. A few success stories from a few people isn't much to support the position, when we are lacking in so many simple and obvious ways. Remember, if a manager can think of multiple ways to knock down the use of Gentoo, like the ones I've given above, what are you going to do to refute his claims? I want to see Gentoo as an enterprise-capable distribution myself, but I also understand that it is a long, hard road ahead of us, and there will still be some things we simply cannot provide as a community distribution, which was my reasoning behind the fork. There would need to be an entity that is responsible, liable, if you will, when something goes wrong, and that has the manpower and resources to fix it. -- Chris Gianelloni
RE: [gentoo-dev] Re: where goes Gentoo?
On Thu, 2005-08-04 at 09:04 -0400, Eric Brown wrote: Interesting thread. I have used Gentoo in enterprise situations very successfully, and I think the whole QA/live-tree argument is moot. In an enterprise environment, you might have a backup/testing machine to run your updates on first before they went live. You also wouldn't run new packages unless they passed your own QA tests first. Given the incredible flexibility of portage to support local mirrors, binary package preparation, and localized versions of packages (portdir_overlay), I would say that Gentoo is quite a contender in the enterprise environment. Perhaps we need some enterprise documentation to help people realize the full potential of portage? I think you've missed some of the idea of enterprise support. See, for starters, every person shouldn't have to create their own implementation of everything. Perhaps a better solution would be a package that when installed, builds up a local mirror, a binary package repository (with revision control), an automated update system, a system for updating rolled out machines without forcing the use of etc-update on each machine, a slower moving stable tree capable of being certified with applications, and most likely a phone number of someone to call when the shit hits the fan. Every business application of Gentoo I've done has been different. I don't think I could generalize my needs into a single ebuild. Although generally I have used rsyncd and apache, I never use them in the same way. What's so hard about using the default rsyncd config, and adding distfiles to your apache document root? (what 90% of people would use). About automating updates and etc-update: you can rsync your config file sometimes and just bypass all of the portage stuff. You could mount some config dirs over nfs even. You could even remove config_protect on some dirs and roll your own custom packages. About a slower moving portage tree for enterprise users: Great idea, I think there's a GLEP about that. I think it's best handled by third parties who can spend the money/man power on that kind of QA. This brings me to your last point about calling someone when there are problems: There are companies that provide Linux services, even Gentoo specific services. Some of these companies might even provide enterprise-grade portage mirrors with support for the packages they maintain there. While I will completely agree that Gentoo *can* be used in the enterprise successfully, that does not make it enterprise-ready, in any sense. Many people also seem to misunderstand the concept of enterprise when we are referring to it in this manner. We don't mean I'm running it on 10 servers in production or anything like that. We mean I'm running this as our production platform for Linux services across our entire enterprise, that could be hundreds or even thousands of servers instead. While it might be possible to maintain a handful of Gentoo servers, it is next to impossible to maintain an army of them, without spending significant up-front manpower to design, test, and implement your own set of management tools. Gentoo has no real management tools. There are a few here and there that do specific tasks, but there isn't anything designed to really take control over your network of systems. To be fair, Red Hat doesn't have anything like this, either. Their Satellite Server product is good for initial builds and for updates, but falls short on the management aspects. Novell's offerings are probably the best examples of what we really need. Of course, most people would be happy with even rudimentary management capabilities, as currently, we have none. We don't have any form of update server. You have to build one yourself. We don't have any form of jump-start or kickstart for rapid automated deployments. You have to build one yourself. Now, we do have the Gentoo Linux Installer project, which has this as one of its goals, so we will have this component at some point in the future. I'm sorry, I never ran 1000 Gentoo machines in production like that, I thought enterprise meant this (answers.com): en·ter·prise (ĕn'tər-prīz') pronunciation n. 1. An undertaking, especially one of some scope, complication, and risk. 2. A business organization. 3. Industrious, systematic activity, especially when directed toward profit: Private enterprise is basic to capitalism. 4. Willingness to undertake new ventures; initiative: “Through want of enterprise and faith men are where they are, buying and selling, and spending their lives like serfs” (Henry David Thoreau). Doesn't this just go to show that in business, everyone wants something different from Gentoo? What does Novell offer to manage large numbers of linux boxen? Are you sure projects like OpenMosix don't have tools you could use to manage such a large number of machines? Maybe we can't rely on portage so much in scenarios
Re: [gentoo-dev] Re: where goes Gentoo?
050804 Chris Gianelloni wrote: -- long interesting account of life in the enterprise snipped -- I want to see Gentoo as an enterprise-capable distribution myself, but I also understand that it is a long, hard road ahead of us and there will still be things we cannot provide as a community distro. There would need to be an entity responsible when something goes wrong and that has the manpower and resources to fix it. There's no way a volunteer organisation like Gentoo could undertake that. What would be essential is a company with capital invested probably an insurance policy somewhere in the background, which employs Gentoo-knowledgeable staff to build fix systems. It would probably have its own mirror with a selection of Gentoo packages, which it is prepared to guarantee as reliable safe to use, would develop all the enterprise-level management tools you describe. Hopefully, it would give something back to the underlying volunteer Gentoo by way of free staff time some tools all of us might benefit from. The first step is a visit to your friendly neighbourhood bank manager (smile). -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: where goes Gentoo?
Long one kiddies... responses inlined, bit more interested in discussion of what's required/desired then your definition of enterprise sucks... (throws on the flamesuit)... On Thu, Aug 04, 2005 at 02:35:08PM -0400, Chris Gianelloni wrote: On Thu, 2005-08-04 at 11:48 -0400, Eric Brown wrote: Every business application of Gentoo I've done has been different. I don't think I could generalize my needs into a single ebuild. Although generally I have used rsyncd and apache, I never use them in the same way. What's so hard about using the default rsyncd config, and adding distfiles to your apache document root? (what 90% of people would use). You completely missed the management aspect here. I'm talking about some form of actual enterprise-ready management framework for controlling a set of Gentoo servers centrally from deployment to maintenance and upgrades. Elaborate on what you explicitly want out of portage please- the domain concept (aside from being useful design wise) *should* allow groupping of boxes (groupping of domains really) behind it, so you can effectively have a set of boxes, pushing changes to each. Mind you no code written, but current design is intended to allow remote chunks to be swapped in/out of portagelib on the fly (including the actual portage configuration). About automating updates and etc-update: you can rsync your config file sometimes and just bypass all of the portage stuff. You could mount some config dirs over nfs even. You could even remove config_protect on some dirs and roll your own custom packages. You can... You can... You can... All I heard here was a bunch of excuses about how a person can take the time to implement something that's been implemented by countless other people, because Gentoo does not provide a framework for doing this. The whole idea of being enterprise-ready is having a drop-in solution that works right off the bat, with minimal to no configuration for basic services. All of your solutions requires manpower to accomplish that not every enterprise can afford to spend. Once again, this is why Gentoo is currently not used in these situations. Better angle of discussion rather then we aren't there yet is the specifics of what is needed to *get* there in peoples opinion. It's not an overnight thing, glep19 (stable portage tree) addresses a chunk of concerns when/if it's implemented, but I'm a bit more interested in the the other tools people desire alongside. Re: a drop-in solution, considering that gentoo is effectively all over the map (seriously, look at the tree), define the profile for the drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc. Specifics... Hell, I have yet to see what I would define as a proper solution for config manamagent for N gentoo boxes. NFS solution possibly, but that seems a bit hackish to me. This brings me to your last point about calling someone when there are problems: There are companies that provide Linux services, even Gentoo specific services. Some of these companies might even provide enterprise-grade portage mirrors with support for the packages they maintain there. I don't think I would stake my company's infrastructure on the reliance on Bob and Joe's Gentoo Support Hotline, sorry. Not to mention you haven't actually given a single example of someone who can provide this level of enterprise support. There's a reason why you haven't given an example. None exists. Moot point frankly, considering we're all volunteers; someone *could* get off their butts and start up an attempt to provide hand holding (effectively what you're coloring the management arg as) services, but even if they did, the followup arg would be that you can't yet trust this new support company, because they're new. Etc. Basically, we don't have control over that portion, so... what can be mangled that we *do* have control over, and has an effect? [snip] In the computer industry, an enterprise is an organization that uses computers. In practice, the term is applied much more often to larger organizations than smaller ones. We are using this in practice. Therefore, we are speaking of large organizations, and not just *any* organization. That's a really crappy description, rather nebulous. :) And... nobody probably cares about loose definitions, 'cause loose definitions are moving targets. Again, specific suggestions/requests would rock. Mentioned management tools, well, get into specifics; pxe network installs/imaging? Single tree/cache for N servers? Ability to push updates out to a specific box, or set of servers? Integration of portage contents db with IDS tools? Novell has several tools, that when used in combination, form a cohesive framework for deploying, managing, and upgrading systems. What's even better, is it isn't just limited to Linux, but I'll leave that as an exercise for the
Re: [gentoo-dev] Re: where goes Gentoo?
On Thu, 2005-08-04 at 14:37 -0500, Brian D. Harring wrote: Elaborate on what you explicitly want out of portage please- the domain concept (aside from being useful design wise) *should* allow groupping of boxes (groupping of domains really) behind it, so you can effectively have a set of boxes, pushing changes to each. Mind you no code written, but current design is intended to allow remote chunks to be swapped in/out of portagelib on the fly (including the actual portage configuration). The only things I could see being needed out of portage itself is the ability to control emerge commands remotely, such as forcing an update of apache to $version to resolve a vulnerability. Besides the back-end portage pieces, there would need to be a front-end interface for performing these tasks. Better angle of discussion rather then we aren't there yet is the specifics of what is needed to *get* there in peoples opinion. Agreed completely. Some things I could see as needed: 1. applying updates on any file that is under CONFIG_PROTECT where the md5/file-size matches that in /var/db for the file without user interaction 2. automatic removal of files under CONFIG_PROTECT where the md5/file-size matches that in /var/db during unmerge It's not an overnight thing, glep19 (stable portage tree) addresses a chunk of concerns when/if it's implemented, but I'm a bit more interested in the the other tools people desire alongside. As am I. The Installer is one such project. We do not have any project that I am aware of that is designed to resolve the problem of remotely managing a server. There is nothing for pushing config changes/package updates/new packages. There would need to be some interface for doing these things. Stop by any trade show, such as LWE, and you'll see guys pushing their wares on remotely managing Linux. We should provide something like this ourselves. eg. If I want to change the subnet mask or default router on 50 machines on my network, I should be able to do so via a simple interface and have the work done automatically. Re: a drop-in solution, considering that gentoo is effectively all over the map (seriously, look at the tree), define the profile for the drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc. I meant a drop-in management solution, not a specific set of server profiles, though those could be created with the Installer. In fact, I see the Installer as one of the first pieces of the framework necessary for deployment and management of a large number of servers. Once the netfe interface is completed with the Installer, you will be able to PXE boot your server and have it load a specific installer profile, and it will install Gentoo to those specifications. Beyond that, we lose control of the server and must manually perform all other actions. Specifics... Hell, I have yet to see what I would define as a proper solution for config manamagent for N gentoo boxes. NFS solution possibly, but that seems a bit hackish to me. There isn't a proper solution yet. Honestly, something like a repository holding configuration information with revision control would probably be best, so you can revert changes. There are quite a few systems like this out for Red Hat and others, but nothing that is Gentoo-specific, or even Gentoo-capable, as far as I know. We should beat people to the punch and design one ourselves. The main things we need to provide are: Provisioning - building a server from bare metal to some pre-determined state Management - being able to make changes to existing servers without manually logging into each to make the changes Updates - this somewhat goes with management, but a facility for disseminating patches or updated packages to servers Moot point frankly, considering we're all volunteers; someone *could* get off their butts and start up an attempt to provide hand holding (effectively what you're coloring the management arg as) services, but even if they did, the followup arg would be that you can't yet trust this new support company, because they're new. Etc. Not entirely moot, as a company could be formed in cooperation with the Foundation, as I stated earlier in the thread. This symbiotic relationship would give the new company a bit more credit, as it will be supported by the Foundation. This could be a Foundation-owned company, or a completely separate entity. Anyway, this isn't so much my point, as many people *are* willing to forgo having a human voice on the end of a phone. Basically, we don't have control over that portion, so... what can be mangled that we *do* have control over, and has an effect? Our tools. Currently, we have very few Gentoo tools used for managing a system. We would need to define the requirements for these tools, and then work on ways of getting them built. It's like I said, I think the primary weakness in Gentoo's enterprise adoption is the need for each
Re: [gentoo-dev] Re: where goes Gentoo?
On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote: The only things I could see being needed out of portage itself is the ability to control emerge commands remotely, such as forcing an update of apache to $version to resolve a vulnerability. The requirements of portage, or whatever component supplies (essentially) pkg management of remote boxes is going to be a bit more complex then just pushing emerge commands out; aside from config data, it'll probably centralize the vdb type contents somewhere, let alone avoiding N copies of the ebuild tree on each server. Basically, whatever daemon is running clientside for all of this will have to support a good bit of handing off commands to portage, hence the interest (since from my point of view, it's a starting point). Some things I could see as needed: 1. applying updates on any file that is under CONFIG_PROTECT where the md5/file-size matches that in /var/db for the file without user interactio That would have to be determined prior to starting the update push. I'd think basically a CONFIG_PROTECT limited scan of boxes to be updated, verifying things are in order according to the vdb (whether remote or local to that box) probably would fly. 2. automatic removal of files under CONFIG_PROTECT where the md5/file-size matches that in /var/db during unmerge current vdb implementation relies on md5/file-size, future should rely on refcount, and be a good bit more configurable. It's not an overnight thing, glep19 (stable portage tree) addresses a chunk of concerns when/if it's implemented, but I'm a bit more interested in the the other tools people desire alongside. Offhand, responding to my own snippet, I'd love to know what's going on with glep19... As am I. The Installer is one such project. We do not have any project that I am aware of that is designed to resolve the problem of remotely managing a server. There is nothing for pushing config changes/package updates/new packages. There would need to be some interface for doing these things. Stop by any trade show, such as LWE, and you'll see guys pushing their wares on remotely managing Linux. We should provide something like this ourselves. eg. If I want to change the subnet mask or default router on 50 machines on my network, I should be able to do so via a simple interface and have the work done automatically. Approach I've been thinking about (that fits semi-neatly exempting collision-protect) is essentially config pkgs, binding them on the fly to pkgs being pushed out. Essentially, base apache pkg (that out of an ebuild tree), with it's depend tweaked automatically to pull in a matching configuration pkg. Pushing out config updates wouldn't be too hard if handled in this manner, although generation of the config pkgs themselves would be a bit tricky. Re: a drop-in solution, considering that gentoo is effectively all over the map (seriously, look at the tree), define the profile for the drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc. I meant a drop-in management solution, not a specific set of server profiles, though those could be created with the Installer. In fact, I see the Installer as one of the first pieces of the framework necessary for deployment and management of a large number of servers. Once the netfe interface is completed with the Installer, you will be able to PXE boot your server and have it load a specific installer profile, and it will install Gentoo to those specifications. Beyond that, we lose control of the server and must manually perform all other actions. Niete. Specifics... Hell, I have yet to see what I would define as a proper solution for config manamagent for N gentoo boxes. NFS solution possibly, but that seems a bit hackish to me. There isn't a proper solution yet. Honestly, something like a repository holding configuration information with revision control would probably be best, so you can revert changes. There are quite a few systems like this out for Red Hat and others, but nothing that is Gentoo-specific, or even Gentoo-capable, as far as I know. We should beat people to the punch and design one ourselves. The main things we need to provide are: Provisioning - building a server from bare metal to some pre-determined state Installer... Management - being able to make changes to existing servers without manually logging into each to make the changes Domain class should provide for it Updates - this somewhat goes with management, but a facility for disseminating patches or updated packages to servers Same as above Our tools. Currently, we have very few Gentoo tools used for managing a system. We would need to define the requirements for these tools, and then work on ways of getting them built. It's like I said, I think the primary weakness in Gentoo's enterprise adoption is the need for each company to
Re: [gentoo-dev] Re: where goes Gentoo?
On Wed, 2005-08-03 at 13:55 +0200, Sven Köhler wrote: In my humble opinion, Gentoo is missing too many points to be an enterprise Linux. We commit to a live tree. We don't have true QA, testing or tinderbox. We don't have paid staff, alpha/beta/rc cycles. We don't really have product lifecycles, since we don't generally backport fixes to older versions, requiring instead for people to update to a more recent release. We don't have, and probably will never be able to offer, support contracts. We support as wide a range of hardware as the upstream kernel, plus hardware that requires external drivers; we don't have access to a great deal of the hardware for which we provide drivers. We understand when real life gets in the way of bug-fixing, because all our developers are volunteers. QA is a problem. Bugs get fixed, but often they are only fixed in ~x86 versions, not in the stable x86 series. For example baselayout: there are lot of ~x86 - miles ahead of that is marked x86. Maintainers think, it's sufficient to only fix the most recent version. How do they legitimate that? This one is easy. A stable package's ebuild should not change. Period. To fix the stable version, means that a new revision of the latest stable version would need to be made, and that revision would need to be tested, before it would go to stable. The only real exception to this is security bugs. Also, in many cases, the bug in question requires changes that are simply not feasible easily in the current stable version, but quite easy in the latest version. It really boils down to this: If you're having an issue with a package in Gentoo and it is fixed in the latest ~arch version, then you should *use* the ~arch version (remember, it doesn't mean unstable it means testing) and you should report back to the maintainers that this is working for you so that they can get it moved into stable quicker. We don't have the staff or the time to backport every fix to every stable version. Remember that in many cases the latest stable version varies between architectures. And yes, Gentoo does not backport patches to older version. But is it Gentoo's responsibility? If there's a bug in Postgresql 7.x and 8.x, and the PostgreSQL people only fix it 8.x-series - well: Debian and Redhat will backport the patches propably. They is a big reason why all the distrubutions with precompiled packages do that: - the updates has to be binary compatible with the old one I don't feel that this is our responsibility. While we sometimes do backport patches, we just don't have the manpower to make it policy. Gentoo doesn't suffer from that limitation. Gentoo offers ways to migrate a system from openssl 0.9.6 to openssl 0.9.7 for example. Other distributions doesn't offer that - although they could with better package managers. Right. Administrating a Gentoo system takes time - much time, but ... This is something that I think most people forget. Running Gentoo makes you a Linux Systems Administrator. Sure, you're only being the administrator for your machine, which might only have one user, but you're the admin. With some of the other distributions, *they* are the admin, and you're just a user. They make assumptions for you and limit what you can and cannot do (without an enormous amount of work to bypass their limits). This is especially apparent in the many cases where users expect Gentoo to do everything for them, when it doesn't. ... writing my own packages for - let's say Redhat - takes more time than writing an ebuild for Gentoo. If you have to maintain a system with very special software, i would recomm Gentoo. I would agree with you. Professionally, I work on Red Hat. I have to build custom RPMs on a daily basis, and I can say that the simple syntax of ebuilds is a tremendous advantage. Just some days ago, someone reinstalled a Server where we had PostGreSQL 8.0 running. He chose to install Debian - which offers PostGreSQL 7.4 - so what did he do? He compiled PostGreSQL 8.0 himself, to be abled to use our existing database. This will become hell the more packages you have to compile on you own. Any configure-make-install-like package, Perl-Module, etc... can be easy installed by using an ebuild. You aren't supposed to compile packages on your own on Debian. You're supposed to make your own DEB package and install that. Otherwise, you are working outside the package manager. This is no different than on Gentoo, just for many people, an ebuild is easier to write than creating a DEB/RPM. In addition Gentoo is the only distribution i know, that supports installing multiple Java-version etc... A must-have for every real java-developer. Agreed. This is also very true for proprietary applications that rely on java. So i'd say: use Debian, if you have a relativly normal system to maintain, use Gentoo if you have the time - and never ever use Redhat or SuSE. Gentoo tends to be
[gentoo-dev] Re: where goes Gentoo?
Chris Gianelloni posted [EMAIL PROTECTED], excerpted below, on Wed, 03 Aug 2005 09:39:07 -0400: Administrating a Gentoo system takes time - much time, but ... This is something that I think most people forget. Running Gentoo makes you a Linux Systems Administrator. Sure, you're only being the administrator for your machine, which might only have one user, but you're the admin. With some of the other distributions, *they* are the admin, and you're just a user. They make assumptions for you and limit what you can and cannot do (without an enormous amount of work to bypass their limits). This is especially apparent in the many cases where users expect Gentoo to do everything for them, when it doesn't. I've found myself emphasizing this same point a number of times. There are general system users that don't care /what/ they are on. Those are /just/ users. However, by definition, /Gentoo/ user == sysadmin, full-stop (period, for those USians not familiar with international English, full-stop seems to me to convey the idea better). You mention the lack of limits, and Sven mentioned the time it takes, but my emphasis tends to be on the responsibilities of the job. A good sysadmin invests the time and energy necessary to keep a healthy system, known vuln and exploit free, but more than that, clean and simple, because (s)he realizes the consequences of a failure to do so. A good sysadmin knows a fair amount about how their system works, in ordered to do that. A good sysadmin enjoys the job, or finds other work. Gentoo makes being a good sysadmin easy. However, by the same token, because it assumes that admin is in place, it tends to make being an ordinary user on an admin-less Gentoo system very difficult. Those that don't like being sysadmins, really should be looking at a distribution that, as you said, really takes on much of the sysadmin duties as part of the services provided by the distribution. The best Gentoo user, then, because being a Gentoo user by definition means being a sysadmin, truly enjoys both the responsibilities and privileges of system administration. Again, if that's /not/ the case, one really should be reexamining their choice of Gentoo, as it's really not the best fit distribution available for those who'd really rather be doing something other than system administration. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: where goes Gentoo?
I think it's value is that gentoo is for the developers. : )-- Riverfor [A chinese, a gentoo user, a programmer]
[gentoo-dev] Re: where goes Gentoo?
In my humble opinion, Gentoo is missing too many points to be an enterprise Linux. We commit to a live tree. We don't have true QA, testing or tinderbox. We don't have paid staff, alpha/beta/rc cycles. We don't really have product lifecycles, since we don't generally backport fixes to older versions, requiring instead for people to update to a more recent release. We don't have, and probably will never be able to offer, support contracts. We support as wide a range of hardware as the upstream kernel, plus hardware that requires external drivers; we don't have access to a great deal of the hardware for which we provide drivers. We understand when real life gets in the way of bug-fixing, because all our developers are volunteers. QA is a problem. Bugs get fixed, but often they are only fixed in ~x86 versions, not in the stable x86 series. For example baselayout: there are lot of ~x86 - miles ahead of that is marked x86. Maintainers think, it's sufficient to only fix the most recent version. How do they legitimate that? This one is easy. A stable package's ebuild should not change. Period. I agree with you there - though sometimes, stable ebuilds are changed - even without changing the version-number. To fix the stable version, means that a new revision of the latest stable version would need to be made, and that revision would need to be tested, before it would go to stable. The only real exception to this is security bugs. Also, in many cases, the bug in question requires changes that are simply not feasible easily in the current stable version, but quite easy in the latest version. It really boils down to this: If you're having an issue with a package in Gentoo and it is fixed in the latest ~arch version, then you should *use* the ~arch version (remember, it doesn't mean unstable it means testing) and you should report back to the maintainers that this is working for you so that they can get it moved into stable quicker. We don't have the staff or the time to backport every fix to every stable version. Remember that in many cases the latest stable version varies between architectures. I chose baselayout for a particular reason. There is baselayout 1.9, 1.11 and 1.12. (i think there was 1.10 too - some time ago - perhaps) I i reported bugs - as usual - but the bug was fixed for 1.11 or 1.12 (i can't remeber, it was about a year ago). The problem: the fix was not backported to 1.9 (which was stable at that time). Since baselayout is a very important part of Gentoo, i didn't think that it would be a good idea, to upgrade my x86-version 1.9 to a ~x86-version 1.11. So i would have expected that such changes would go into a new 1.9-version which could have become stable after some testing - but they didn't. So patches the scripts manually - well, and easy task, although i had to pay attention so they my changes weren't overwritten. signature.asc Description: OpenPGP digital signature
