SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I finally got around to installing the latest LiveCD of Arch Hurd. Although, I'm still having problems installing the bootloader (not familiar with GRUB), I bypassed that portion by using my copy of Super Grub Disk (CD), gzipped the gnumach kernel (gnumach.gz instead of gnumach), and edited menu.lst to boot from /boot/gnumach.gz which the Super Grub Disk (CD) recognizes. *
As expected, Arch Hurd boots quickly from the hard drive and runs quickly from the console. I now have networking configured (eth0). After editing /etc/pacman.conf and /etc/pacman.d/mirrorlist, run pacman -Syu to update your local system to the necessary repositories. The update process actually works! Also, I bypassed repartitioning in Arch Hurd's setup in favor of manually executing the command, fdisk. Repartitioning can ruin your day (hard drive) quickly. Now, I have Arch Hurd ready to be upgraded with Xorg (extra repository) so the real fun begins. We'll see if GNU's HURD can actually be useful to potential users of Linux. Again, so far, nice.
* If using the Super Grub Disk (CD) to boot the HURD, once Arch Hurd's LiveCD has booted, one must gzip the gnumach kernel located in /mnt/boot (NOT the kernel in /boot) and edit menu.lst located in /mnt/boot/grub to boot /boot/gnumach.gz instead of /boot/gnumach.
Bloated perhaps, but that comes with the territory when you have to support a lot of hardware/etc. That is why you can recompile the kernel only to what your system needs, then it is not so bloated.
In it's raw form the kernel is huge because of all of the things it supports, so yes over the years it has gotten bloated, but all that can be easily trimmed down significantly. It is only bloated when you download a new version or use the all-encompassing huge kernel in Slackware.
True, but the bloat in question here is perhaps not the compiled-in modules but the design itself. Obviously any kernel with n features should have n pieces of code dedicated to these features, so you can't avoid bloat in that sense. But for example, when Linus first wrote his kernel it probably only had the BKL. The trend has been to break it down into a finer grained system under this monolithic structure. The end result is an enormously more complex system.
Yes by design and one must also consider that the kernel supports multi architectures and older processors and such. A very small percentage(?) is running m68k/ppc and such, of course then there is IA-64, but I guess if you were to combine all those it still would be a small number. The only non-x86 users that have perhaps a sizable usage is SPARC.
This is just my opinion, and certainly should only be taken with a grain of very fine salt but perhaps in the coming future Linus perhaps should consider no longer officially supporting certain architectures, such as m68k, but I definitely don't see SPARC going away anytime soon. Only other arch I see that perhaps nobody would even notice if it were gone from the kernel is IA-64 (Itanium).
That would trim the kernel significantly (raw size I mean), but yes I am aware that some would perhaps cross-compile their kernels for a different arch.
Like I said this is just something to consider, and I am well aware that none of what I just typed will probably happen at all. (99.9% sure of it), but I still at least stand by my opinion about at least dropping IA-64 from the kernel.
Does multi-architecture support add a lot to design complexity? It certainly adds code, you need to have several if (or rather #ifdef) statements for the preprocessor, but the general design and algorithms should still be the same. For instance the lock mechanisms don't get simplified if you drop support for other architectures. I'd count architecture support as a feature really, or "pseudo-bloat" if you will .
Yes by removing some support for some archs it would reduce the kernel in size only. I never meant to say that it would by any way reduce complexity, just it's size.
I think a Slackware(Hurd) would be a neat version to start since micro kernels are gaining some measureable progress/momentum. It's probably a good time to start it but as with everything -- not sure where one gets the human resouces to do so. I can only speculate that P.V. and team are keeping plenty busy maintaining Slackware (Linux).
I would assume an effort like this would have to be similar to ARMedslack, where an independent person would have to start it (because it would represent quite a low priority for the Slackware team). Then, if it is good enough, it could be adopted as official, or at least be a starting point -- or it would remain unofficial. If SlackHurd is what you really want, your best bet is to take matters into your own hands.
I think a Slackware(Hurd) would be a neat version to start since micro kernels are gaining some measureable progress/momentum. It's probably a good time to start it but as with everything -- not sure where one gets the human resouces to do so. I can only speculate that P.V. and team are keeping plenty busy maintaining Slackware (Linux).
Now that I've managed to use the mouse in Xorg in Arch's version of the HURD, I'm flat ECSTATIC with the potential. Now, I need more time to use the HURD to more accurately assess it's current state (still somewhat problematic from my limited use), but seemingly workable as a daily OS for many uses. We'll see if it's close enough to be associated with Slackware as a 3rd party initiative.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.