The Linux Kernel and Linux Distributions
 by Jeff Garzik, in Editorials - Sat, Feb 3rd 2001 17:00 UTC

Whenever a new kernel comes out, there's a lag time between when it's adopted by those who don't mind compiling it themselves and by those who are waiting to get it bundled in an already-tested package from the maintainers of their distributions. In part, the delay is just the result of the difference between those who live on the edge and those who stick with the tried-and-true, but could it be shortened by reducing the work that the distributions have to do to adopt the new kernel? In today's editorial, Jeff Garzik of MandrakeSoft describes the process of fitting the two together.

Update: Developers from Conectiva have written to share their thoughts on the subject.

Readying a distribution for a new release of the kernel at MandrakeSoft is, like other open projects, a constant process of refinement, testing, and interaction with non-MandrakeSoft Open Source developers.

Mandrake's bleeding-edge development distribution, "cooker", is always available to outside testers on the Internet. When a new kernel appears on the horizon, the first step is to package the new development kernel in a special RPM called "hackkernel". (Mandrake uses the "hack" prefix to indicate a development/unstable version of a package.) Once hackkernel is packaged, we can begin testing the distribution with the newer kernel. Testing involves hardware testing at MandrakeSoft's labs, but, even more importantly, it involves the cooker users out on the Internet. They are our biggest resource; no amount of internal testing can replace beta testing on the Internet at large.

Once the feedback starts arriving from cooker users and internal Q/A, the process of refining the distribution for the new kernel begins. This process involves the evaluation of each and every package to determine how each can best take advantage of the new kernel while still retaining full compatibility with the older kernels. The package changes which make the distribution better suited to the new kernel can come from many sources: internal developers, Open Source developers out on the Internet, and other distributions. These changes are all integrated, in patch form, into each RPM package. These updates are posted on cooker, and the process of refinement begins again.

The final step in readying a distribution for a new kernel is to update the installer. Since each distribution has its own installer (for the most part), this is typically a MandrakeSoft-only affair. (However, all our updates, including installer updates, are GPLed and available freely to all.) Eventually, based on cooker user and internal Q/A feedback and schedules, the cooker distribution will be frozen into a stable form and given a release code name like "oxygen" or "odyssey." After this freeze occurs, no more new additions occur, including kernel changes. Any final incompatibilities between the new kernel and other packages are smoothed out at this point. Finally, the CDs are pressed, and ISOs are uploaded to the Internet for all to enjoy.

The dialogue between MandrakeSoft and Open Source developers and users is constant. New changes to the kernel that appear on the linux-kernel mailing list and elsewhere on various project Web sites must be evaluated and tested. Bugfixes and features from MandrakeSoft must be fed back to the maintainers of the Open Source projects on the Internet. In the case of the kernel itself, this usually involves sending patches to Linus and/or the linux-kernel mailing list.

Linux-Mandrake is not unlike many established Open Source projects. The process of development, integration of new kernels, and testing is a constant cycle of refinement.

Editor's note:

I'd like to hear any of your thoughts about the relationship between the kernel and the distributions built around it. If you're a user, does the wait for a new version of your distribution with the new kernel and features you need frustrate you, or do you just compile a new kernel on your own and hope the distribution is ready to handle it? If you're a distribution maintainer, what work do you have to do to accommodate a new version of the kernel? Are the communication channels between you and the kernel developers good enough that you get all the information you need in a timely manner? Is there anything that could be done to make the job easier for you? Do you find yourself spending much time talking to third parties who haven't made the necessary changes to their software to work with the new kernel, and convincing them to do it? Is there anything else the community could do to shorten the time between a kernel release and its inclusion in the distributions? Do you have any thoughts on distributions that use patches that haven't made it into the official kernel yet (journaling filesystem foo or USB support bar)? What about proprietary binary-only modules (video card drivers, etc.)?

Thoughts from Conectiva Developers

Claudio Matsuoka (claudio@conectiva.com) and Marcelo Tosatti (marcelo@conectiva.com) of Conectiva share their thoughts on the subject:

The perfect integration of a new kernel in the distribution is, of course, one of the major concerns of every Linux distributor, and it involves expertise in kernel hackery as well as user feedback to find any problems not detected in internal testing. Internal testing just ensures that minimal quality standards are met; only the feedback of a larger circle of users can provide the real measurement of the distribution's quality.

Conectiva's kernel hackery expertise is supplied by a number of kernel developers including MM guy Rik Van Riel, Marcelo Tosatti (who actually builds the kernel packages), Arnaldo Melo, Aristeu Rozanski, and others. To extend its testing circles beyond Latin America, Conectiva is currently working to mirror its daily updated snapshot distribution in as many places as possible (and get as much community feedback as possible) through the bug tracking system and mailing lists.

The kernel bundled in the distribution in heavily patched. How many patches it carries is a compromise between features and maintenance costs. Keeping our tree close to the official tree avoids effort replication within the community and also it makes maintenance easier. However, there are some features which are interesting for us but not acceptable in the stable kernel tree for a variety of reasons. If these features are interesting enough for us to spend time testing and maintaining, they will be adopted. Examples are the USB backport, raw I/O, bigmem, ReiserFS, and others. This is basically the way all commercial distribution vendors work.

The drawback is that once you provide USB backports, LVM, ReiserFS, or any other extra functionality, you can't remove them and say to the users that it's not supported anymore. If something happens to the main development team, it's up to the distributor to keep maintaining this functionality. As for the latest stable release, Conectiva included all these patches as well as many others such as lm_sensors, I2C, DRDB, iBCS, IPVS, VM patches, supermount, raw I/O, fair scheduling, and dxr2. Locally developed patches are always sent upstream to the official maintainers.

Some of these addons require a set of userspace tools to work properly, and these tools also need maintenance. LVM, for example, has different, incompatible I/O protocol versions in different kernel releases, and the userspace tools must allow the user to boot the system using kernels with different IOP versions. In the snapshot release, Conectiva supports IOP6 (used in later 2.2 and early 2.4.0-test kernels) as well as IOP10 (used in the current 2.4). The use of wrappers and lvm-iop packages has been adopted by Conectiva and TurboLinux.

Additionally, the system should still work with plain, non-patched kernels. An administrator must be able to compile her own stock kernel and still have the system working.

Binary modules are not included in the kernel package. To be able to support the kernel code which is in the official distribution, we cannot accept unfixable and unmaintainable code. There may be binary modules on the additional CDs that are shipped with the distribution for user convenience, but they are not supported and the documentation is clear about that.

Author's bio: Jeff Garzik can be reached at jgarzik@mandrakesoft.com. He claims to be a "not a very exciting person"^[1] that MandrakeSoft pays to hack on the kernel.

[1] We actually know better and have the photos from Linuxworld Expo to prove it, but will not post them if Jeff makes the suggested deposits into our bank accounts.

T-Shirts and Fame!

We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories Topic :: System :: Operating System Kernels :: Linux

Referenced projects Linux - The Linux Kernel. Mandriva - A graphically-oriented popular Linux distribution.

 Comments

[»] DIY kernel upgrades
by Roland Smith - Feb 11th 2001 12:55:59

I'm used to installing a new kernel if it contains a bugfix or feature that I'm looking for. If you use LILO _and RTFM_, it's not that difficult. Having said that, I think that the packaging systems of some distributions make it very difficult to install anything that's not in the distribution's preferred packaging format. One self-installed piece of software can invalidate your whole packaging system database. I don't think I need to elaborate on that. That's why I favor distributions that do not have a packaging system that functions like a straightjacket. (such as slackware or linuxfromscratch) So my take on it is that DIY upgrades will be limited to people with at least an understanding of of what constitutes a Linux system, and which pieces depend on each other. Those that do not have that understanding have the option of learning that, or waiting for the distribution vendor to help them out.

[reply] [top]

[»] the problem is the utilities
by Tim - Feb 8th 2001 11:05:25

If one is using Debian with 2.2.10 and switches to 2.2.18 there isn't much of a problem. However, switching to 2.4 is very painful, none of the modules will work (I have had to load them all manually), and there are a lot of utilities you will have to download and install by hand (iptables, reiserfs utilities, etc.) It seems to me that it would not be THAT difficult for the distributions to package a major kernel release like 2.4 with all the neccessary utilities peripheral to it. Waiting for the next stable Debian release is quite a wait, and no way I'm running unstable (besides which 2.4 isn't even in unstable). For Red Hat and friends it is really inexcuseable. I've built more kernels than you can shake a stick at, but switching major kernel revisions is a little more than I can deal with (though it depends on the machine and what it needs).

[reply] [top]

[»] Packaged doesn't mean good
by Bruce Ferrell - Feb 4th 2001 00:02:34

I've been a Linux user since Yggdrasil... Which caused me to quickly move to Slackware :) I've been compiling kernels a long time. At home I use both Slackware and RedHat. At work, RedHat exclusivly... It's just simpler in general, but... One of my home systems uses a mulitiude of odds and ends, and the Pre-packaged RedHat kernel just hangs on my system. At work, I have a system that needs some special options in the SCSI sub-system (multi-lun support); Again, the pre-packaged kernel binaries are just not up to it and building from the kernel source RPM somehow doesn't build the module to do it. So I end up building the kernel from generic source. I don't wait for RedHat or Slackware to package up a kernel upgrade if it has something I need. I do wait for other people to run it for a while before I install the latest/greatest. The downside is some of the stuff, I'd like to play with is rather insistant about kernel version designation (redhat and 2.2.16-30) and "unsupported"... Not fun for me :( And while I'm on the topic of pre-packaged open-source software. How many of us have been bitten by badly built RPMS? My most recent foray was NIS a crucial part of the ypserver package wasn't compiled correctly, and from my experiements, CAN'T be build correctly from the source RPM! Back to the generic source! That was good for a wasted day.

[reply] [top]

[»] Re: Packaged doesn't mean good
by cuBe - Feb 4th 2001 15:31:37


> I've been a Linux user since
> Yggdrasil... Which caused me to quickly
> move to Slackware :) I've been compiling
> kernels a long time. At home I use both
> Slackware and RedHat.
>
> At work, RedHat exclusivly... It's
> just simpler in general, but... Ever tried looking at RH config files? Heh, the only simple thing about RH is linuxconf :)
> One of my home systems uses a
> mulitiude of odds and ends, and the
> Pre-packaged RedHat kernel just hangs on
> my system. At work, I have a system that
> needs some special
> options in the SCSI sub-system
> (multi-lun support); Again, the
> pre-packaged kernel binaries are just
> not up to it and building from the
> kernel source RPM somehow doesn't build
> the module to do it. So I end up
> building the kernel from generic source.
> I don't wait for RedHat or Slackware to
> package up a kernel upgrade if it has
> something I need. I do wait for other
> people to run it for a while before I
> install the latest/greatest. Some people need to compile their own kernel's, for reasons like yours. Some people don't, and never do. I don't think anyone is better than the other, both ahve their flaws. Novices find it difficult to compile. Precompiled restricts you. There's not really much anybody can do about it, unless you wish to be facist (not that anyone is being here, I'm talking in general here) and force your views on others. As the Perl guys say, TMTOWTDI, pick your own, that's what makes Linux cool.

--
"Ubi non accusator, ibi no judex."

[reply] [top]

---

[»] Re: Packaged doesn't mean good
by Claudio Matsuoka - Feb 4th 2001 15:36:50


> One of my home systems uses a
> mulitiude of odds and ends, and the
> Pre-packaged RedHat kernel just hangs on
> my system. It's the vendor's task to ensure that its binary packages will work. If a pre-built kernel hangs, that's a very serious bug that should be fixed as soon as possible.
> And while I'm on the topic of
> pre-packaged open-source software. How
> many of us have been bitten by badly
> built RPMS? My most recent foray was NIS
> a crucial part of the ypserver package wasn't
> compiled correctly, and from my experiements,
> CAN'T be build correctly from the source
> RPM! Back to the generic source! Again, that's a vendor's fault. However, bugs like these must be reported to the distributor otherwise it will be assumed that everything is fine. As discussed before in the apt-get editorials, packages are just a convenient medium to deploy software, and by no means it can be an obstacle for software installation. When it happens, it's a serious bug that defeats the purpose of having a distribution in the first place.

[reply] [top]

---

[»] I used to
by GoRN (Kevin Barry) - Feb 3rd 2001 22:29:50

i used to adapt the new kernel, that day. but now i leave my box on all the time as a server and rarely reboot. so i haven't upgraded to 2.4.1 i'm still using 2.4 though. imho /most/ people aren't going to upgrade the kernel till a new release of their distro comes out. as for hoping the distro works with the new kernel, i built my own install :) distroless! -out-

--
Dunt Dunt Duh... GoRN ToTheRescue, Yet Again! -out-

[reply] [top]

[»] Lack of kernel updates for released Linux distributions
by Stefan Schneider - Feb 3rd 2001 21:04:29

I'd try out a new kernel version more often if there were kernel update packages for non-beta releases of my current Linux distribution. Means, I don't like to fetch packages from a beta or development version of my Linux distribution and mix these with my non-beta distribution. Actually I'd prefer ``hack''-prefixed kernel update packages which I could run with my current distribution without having to put my hands on packages from any beta distribution.

[reply] [top]

[»] Re: Lack of kernel updates for released Linux distributions
by Tim Jones - Feb 5th 2001 12:15:50


> I'd try out a new kernel version more
> often if there were kernel update
> packages for non-beta releases of my
> current Linux distribution. Remember - you CAN have multiple kernels (and associated modules) on one machine. This way, you can test a new kernel but fall back on a stable kernel with a simple reboot. If the new kernel works, a simple edit to lilo.conf makes the new kernel your default.

--
Tim Jones Linux Since SLS 0.9.0 and Yggdrasil LGX Winter '93

[reply] [top]

---

[»] Re: Lack of kernel updates for released Linux distributions
by Stefan Schneider - Feb 6th 2001 17:26:57


>
> Remember - you CAN have multiple
> kernels (and associated modules) on one
> machine. This way, you can test a new
> kernel but fall back on a stable kernel
> with a simple reboot. I DO have multiple kernels on my machines. My point is, I don't like to maintain my own tiny set of extra package updates that each new kernel requires. Hence I'd prefer if my Linux distributor made available "test" kernel update sets also for the current release and not just for a complete new work-in-progress distribution.

[reply] [top]

---

[»] Re: Lack of kernel updates for released Linux distributions
by Claudio Matsuoka - Feb 9th 2001 16:30:26


> I'd try out a new kernel version more
> often if there were kernel update
> packages for non-beta releases of my
> current Linux distribution. Means, I
> don't like to fetch packages from a beta
> or development version of my Linux
> distribution and mix these with my
> non-beta distribution. Actually I'd
> prefer ``hack''-prefixed kernel update
> packages which I could run with my
> current distribution without having to
> put my hands on packages from any beta
> distribution. The main problem in doing such releases comes from the updates in the userspace utilities such as ReiserFS tools or LVM utilities. When you prepare a recent kernel and tools to work in an old distribution, you'll also need an extended test period to ensure that no (potentially harmful) bugs will be introduced. That's especially true for heavily patched kernels; for distributions shipping stock kernels it shouldn't be so problematic (problems in stock kernels can be readily detected by stock kernel users, which largely outnumber distro-specific kernel users).

In such situation, experimental recent kernel packages for an old distribution are as risky as using beta packages. If they get sufficient testing, they won't be recent anymore. If you don't want to build your own recent stock kernel and want new features from kernels shipped in recent distros It's usually simplier just to apt-get dist-upgrade to a newer distribution version.

[reply] [top]

---

[»] Re: Lack of kernel updates for released Linux distributions
by Stefan Schneider - Feb 9th 2001 23:15:56


> The main problem in doing such
> releases comes from the updates in the
> userspace utilities such as ReiserFS
> tools or LVM utilities. In other words, what you're writing here means what I've written earlier. I would need to maintain my own distribution of required update packages just to try a new kernel. I'd better stick to a stable distribution. Not an old one like you say, but the latest release.
> When you prepare
> a recent kernel and tools to
> work in an old distribution, you'll
> also need an extended test period to
> ensure that no (potentially harmful)
> bugs will be introduced. I wouldn't mind if there were any bugs in a `hack''-prefixed kernel update series. I would try such packages at -my own risc-. But by trying them, I would be able to find and report bugs. Of course, if I need a complete beta distribution to support a new kernel series, this is an unacceptable condition. With a new distribution like Rawhide usually come a high number of package upgrades which change the entire system and which often introduce new and annoying bugs.

[reply] [top]

---

[»] most users don't care about the latest kernel.
by captain larry - Feb 3rd 2001 20:07:14

look, i've been compiling my own kernels for about 6 years now, and i barely ever do it any more. why? because modules mean that the standard kernel (debian in my case) is capable of being dynamically configured to do most anything i'm gonna want. there are pretty much only two cases where i recompile my kernel these days: - because i prefer using laptops, sometimes i need a patch or a bleeding edge kernel for driver support. - on my server for security reasons. i like to compile in openwall, frees/wan, sub-domain etc for security reasons and these aren't included in any bundled kernel that i'm aware of. these reasons are specific to me and my needs. most users have hardware that is much better supported then my laptops, and few will run servers let alone servers with fairly strenuous security measures. if something can be done to make the process of implementing a new kernel easier for distributions then great. however i hardly see this as a pressing issue. after all isn't the sort of integration the reason that distributions appeared?

[reply] [top]

[»] Re: most users don't care about the latest kernel.
by Steve Lhomme - Feb 3rd 2001 20:52:50

Well, I hope all Linux users won't think the same that they don't need to have user friendly interfaces and programs ! Otherwise it will remain a software for programmers, people who like to speak with machines. Saying that people need to learn how their computer work and how to talk to it is like if scientists wouldn't give out their knowledges... Or a company building a new technology but without saying how it's like. Information retention ! Otherwise, I tested kernel 2.4.0-ac10 which was instable on my computer (freezing sometimes) so I had to go back to the previous one. I'll wait for it to be stable (and integrated in the next release of Mandrake (or any other distro)).

[reply] [top]

---

[»] Linux Kernel Database Proposed to Make this Easier
by Michael D. Crawford - Feb 3rd 2001 18:46:31

One thing that can speed both the development of new kernels, and their adoption when they are released is more widespread and more effective quality assurance of the kernels during development and immediately after released.

The distros often maintain full-time staff to do QA, their resources are necessarily limited. There is no way any company can maintain staff and enough different machines to reproduce all the configurations a new kernel will be used on in production once released.

To encourage more regular users to participate in Linux kernel testing, and to make the process of getting their feedback easier on them, I have proposed the Linux Quality Database that will provide a web form backed by a powerful database for capturing configuration information and making bugs easily searchable by kernel developers.

It is a big project, and I need help before I can start, particularly from a database architect who can advise me on the schema for the database.

In the meantime, there are articles being placed on the site to guide you in the process of testing the kernel and writing better free software in general.

--
Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ crawford@goingware.com Tilting at Windmills for a Better Tomorrow.

[reply] [top]

[»] Where are the warriors today?
by matthew - Feb 3rd 2001 17:29:56

If you're a user, does the wait for a new version of your distribution with the new kernel and features you need frustrate you, or do you just compile a new kernel on your own and hope the distribution is ready to handle it? Compile and let it fly, after screwing up your distribution with an incompatible kernel you can always run windows when you want to be productive again. :) In all seriousness, the GNU/Linux OS is NOT ready for people who would get frustrated and unwilling to download a newer stable kernel with the features they need. So if you are waiting around for your distro to include the kernel, just run windows to get the features you need.

[reply] [top]

[»] Re: Where are the warriors today?
by Steve Killen - Feb 3rd 2001 17:38:49


>
> In all seriousness, the GNU/Linux OS
> is NOT ready for people who would get
> frustrated and unwilling to download a
> newer stable kernel with the features
> they need. So if you are waiting around
> for your distro to include the kernel,
> just run windows to get the features you
> need.
> I'm tempted to agree with you, mostly on the point that some users deserve Windows. Although coming from LWCE, I was looking at EasyLinux--it has a GUI kernel compiler! Anyway, I digress. I just think that if you have no clue of your computer's abilities or potential, and don't really want to bother yourself to find out, then yes. You belong in Windows-using land, blissfully ignorant of the alternatives.

--
Defending innocent grammar from harm since 1979.

[reply] [top]

---

[»] Re: Where are the warriors today?
by Janne - Feb 3rd 2001 20:42:19


>
> %
> % In all seriousness, the GNU/Linux OS
> % is NOT ready for people who would get
> % frustrated and unwilling to download a
> % newer stable kernel with the features
> % they need. So if you are waiting around
> % for your distro to include the kernel,
> % just run windows to get the features you
> % need.
> %
>
>
> I'm tempted to agree with you, mostly
> on the point that some users deserve
> Windows. Although coming from LWCE, I
> was looking at EasyLinux--it has a GUI
> kernel compiler! Anyway, I digress. I
> just think that if you have no clue of
> your computer's abilities or potential,
> and don't really want to bother yourself
> to find out, then yes. You belong in
> Windows-using land, blissfully ignorant
> of the alternatives. I don't agree with you; one of the reasons people turn to Linux is precisely because it is very stable and very dependable. I enjoy the bleeding edge as much as anybody, but _not_ on machines that are critical for my work. I don't want to set up an experiment, only to find out two days before deadline that critical drivers or other software don't work correctly on the new kernelm and I don't want _any_ surprises on the machine on which I'm writing my thesis. So, yes, do try out new kernels or new distros, but don't expect anybody to do it on critical systems.

--
This mission will be easy and fun for all. /Janne

[reply] [top]

---

[»] Re: Where are the warriors today?
by Steve Killen - Feb 4th 2001 01:31:39


> % I'm tempted to agree with you,
> mostly
> % on the point that some users
> deserve
> % Windows. Although coming from LWCE,
> I
> % was looking at EasyLinux--it has a
> GUI
> % kernel compiler! Anyway, I digress.
> I
> % just think that if you have no clue
> of
> % your computer's abilities or
> potential,
> % and don't really want to bother
> yourself
> % to find out, then yes. You belong
> in
> % Windows-using land, blissfully
> ignorant
> % of the alternatives.
>
>
> I don't agree with you; one of the
> reasons people turn to Linux is
> precisely because it is very stable and
> very dependable. I enjoy the bleeding
> edge as much as anybody, but _not_ on
> machines that are critical for my work.
> I don't want to set up an experiment,
> only to find out two days before
> deadline that critical drivers or other
> software don't work correctly on the new
> kernelm and I don't want _any_ surprises
> on the machine on which I'm writing my
> thesis.
>
> So, yes, do try out new kernels or new
> distros, but don't expect anybody to do
> it on critical systems.
> If it's critical systems you're talking about, there's no guarantee that even the stable kernel or some driver subsystem thereof isn't buggy in some untested way. I'm of the opinion that unless you roll your own and know exactly what's going into it, there is margin for error. Some people consider that margin worth working around; a lot of times I'm one of them :)
No one ever said to try new features on critical systems--that's insane. But the fact that anyone can do it, albeit on a non-production machine, is why I say that some people deserve Windows. If there are alternatives, and you refuse to acknowledge them, then you earn the limitations you take upon yourself.

--
Defending innocent grammar from harm since 1979.

[reply] [top]

---

[»] Re: Where are the warriors today?
by glennmason - Feb 8th 2001 16:40:54


> If it's critical systems you're
> talking about, there's no guarantee that
> even the stable kernel or some driver
> subsystem thereof isn't buggy in some
> untested way. So, you're saying that there is a guarantee that Micros~1 software isn't buggy in some untested way?? Unfortunately, we take a risk in running any software: the risk that there will be bugs that escaped testing, no matter how rigorous. The difference is that open source software gets some of the most rigorous testing available. So okay, don't use the latest kernel if you're worried about uncaught bugs. Wait for 2.4.something, because it will include the latest patches found by others who aren't worried about high reliability, or those who need the latest features and are willing to make the tradeoff.

[reply] [top]

---

[»] Re: Where are the warriors today?
by MonMotha - Feb 4th 2001 16:57:11


>
> %
> % In all seriousness, the GNU/Linux
> OS
> % is NOT ready for people who would
> get
> % frustrated and unwilling to download
> a
> % newer stable kernel with the
> features
> % they need. So if you are waiting
> around
> % for your distro to include the
> kernel,
> % just run windows to get the features
> you
> % need.
> %
>
>
> I'm tempted to agree with you, mostly
> on the point that some users deserve
> Windows. Although coming from LWCE, I
> was looking at EasyLinux--it has a GUI
> kernel compiler! Anyway, I digress. I
> just think that if you have no clue of
> your computer's abilities or potential
> and don't really want to bother yourself
> to find out, then yes. You belong in
> Windows-using land, blissfully ignorant
> of the alternatives. I wholly agree with you on that one. GNU/Linux is not ready for newbies to the computer field. Even those who are very comfortable with MS Windows often have trouble understanding Linux because it is based of an entirely different structure (*NIX). Linux is currently targeted mainly at people who know computers well, are tired of BSODs, and want to learn. It also works well on servers as long as you make sure you don't install a distribution tweaked more for desktops.

[reply] [top]

---

[»] Small trees! Bonsaaaai! ...or something like that...
by Leon Brooks - Feb 4th 2001 09:27:35


> If you're a user, does the wait for a
> new version of your distribution
> with the new kernel and features you
> need frustrate you, or do you just
> compile a new kernel on your own and
> hope the distribution is ready to handle
> it? No, I close my eyes, put a hand over my nostrils to avoid amoebic meningitis, and leap into Cooker feet first! (-: ``Every install an adventure'' :-) With Mandrake's cooker program, the wait for a new kernel version is reduced to as little as a few hours: I've even seen a new kernel RPM announced on the Cooker list before LinuxToday or Freshmeat post an announcement of the source kernel...

[reply] [top]

---

[»] Re: Where are the warriors today?
by dazk - Feb 9th 2001 15:12:01


> If you're a user, does the wait for a
> new version of your distribution
> with the new kernel and features you
> need frustrate you, or do you just
> compile a new kernel on your own and
> hope the distribution is ready to handle
> it?
>
> Compile and let it fly, after screwing
> up your distribution with an
> incompatible kernel
> you can always run windows when you
> want to be productive again. :)
>
> In all seriousness, the GNU/Linux OS
> is NOT ready for people who would get
> frustrated and unwilling to download a
> newer stable kernel with the features
> they need. So if you are waiting around
> for your distro to include the kernel,
> just run windows to get the features you
> need.
> Yeah right, and all the hell with it. Ever tried upgrading drivers? On Linux the worst thing that can happen is a kernel that doesn't do it. Make sure you include your old Kernel in lilo.conf as every kernel compile howto tells you to and you can boot your old kernel. Windows is not even capable of removing drivers completely. If you uninstall a driver very often windows finds and installs it again after reboot without you having a chance to stop it. The driver just has to be low level enough. Is that really better? Is it actually easier for someone to remove a driver by hand, deleting the appropriate inf and driver files maybe even clean the stuff that corrupts your system out of the registry mess? I just realize you have not the slightest idea what you are talking about. I agree with you in one point. If you are not interested in getting to know what's going on on your computer, windows might be the better choice because you couldn't find out anyways. But if you spend a little bit of your brain power and time on reading and understanding howtos and if you are prepared to accept the hints experienced people give you, it's not all that bad. As I said, you even have the fallback option. I agree, upgrading to a new kernel major version often is more difficult, since it often involves library and tools upgrades as well. Then again, you can compare this procedure more to an install or upgrade of a new windows version. This is something that doesn't work most of the time with windows either. So where is your point? It would be really nice, if people that start flaming about Linux would at least know what they were talking about. Thanks. Cheers, Richard

[reply] [top]

---

[»] Re: Where are the warriors today?
by albert fuller - Feb 23rd 2001 19:02:36

off the bat, let me say that I am learning Linux and computing. A friend helped me put in RH 5.x some time ago and I kept it as a second OS for a long time. I remember my first year of Linux. I spent most of my modest computer time configuring and checking things out. I discovered MDK and wow! I came on board. Now I run Linux as my OS-of-choice at home. I am still learning; but often I put off the tinker gloves and decide to USE my computer to surf, write, etc. Nothing is a culture of one (except maybe insanity). For the expert, and the character with way too much time on his/her hands, for those virtual individuals, I am sure spending the next 36 hrs finding out why some item did not fly is the first choice in a worthwhile life--and that's great. But the world is always more diverse than some people are willing to admit. (The existence of Mandrake itself speaks against a 1 class society of warriors.) I need you guys who are the warriors of Linux, but please don't dispise the rest of the tribe: after all you are defending the village from that evil invader who, at this moment, is about to lay seige to to this village/(ok town): get ready folks! the rape and pillaging of Linux has yet to begin... what! you think evilB will just donate his money to charity and lose disappear in an infinite smile.

[reply] [top]

---