Hey now! I like the Tetris-playing text editor a lot. But you're right. I browse the Emacs developer's list from time to time and it's a bit stuffy there. OTOH, Stallman isn't very actively involved in Emacs development these days.

Regards,

It is kind of cool. :) Still not a fan of Stallman or his ego.

I don't think you can write off all microkernels based on the HURD disaster. Perhaps GNU was being too ambitious, but there are microkernels out there that aren't a complete disaster. MINIX 3 looks like a nice system based on a microkernel, and certainly there are advantages to microkernels that go beyond security. With Linux, you must reboot into a new kernel, and if you don't update the kernel then you are vulnerable to bugs and security vulnerabilities that may have been fixed. In order to remain secure and bug-free, you now have mandatory reboots. For a desktop, probably not an issue, but for a real server it is less than pleasant to watch your uptime fall to 0. Assuming there is no update to the bare bones microkernel, you can essentially upgrade and restart vital kernel code with security/bug fixes without rebooting the whole computer. I think this is a large advantage.

That said, I am OK with the Linux kernel for now (though it is getting more and more bloated every day...), but I certainly wouldn't knock the entire concept of a microkernel just because GNU can't get their act together with HURD.

I don't have anything against microkernels in particular. Like I said, in theory (and practice, in the case of MINIX 3) microkernels have some nice advantages.

You're right, Linux is becoming bloated... bloated with security fixes and increased hardware compatibility. The beauty of Linux is it can run on just about anything.

Arch Hurd
 

I booted Arch Hurd's latest LiveCD last night. It's only the second time that I've tried booting the Hurd. This time with Arch's LiveCD, it booted well. However, I still haven't installed the system yet, but it looks promising. I'll keep this thread updated to see if the Hurd is ready to bear the Slackware name. ;)

You conveniently overlooked the bugs. ;) There's a difference between "can" and "does" run if Linux even boots at all. (#23) ;)

Hardware compatibility issues on your end by the looks of it. Everyone else was running "unbootable" Linux at the time.

"Everyone else" running my particular VIA chipset ...

Then... switch to Windows? Linux is far from perfect and stupid crud like this is bound to happen. Otherwise I'm not sure what you want me to say.

How did HURD run on that chipset, by the way? ;)

Debian is essentially the FSF's OS, so of course they have a Hurd-powered version of the distro.

What makes you grow "tired" of monolithic kernels? Do you port the kernel into embedded devices? Do you use it in small, memory-limited situations? Because, for all of the ideological claptrap about microkernels, a microkernel will all of its accompanying daemons up, as they would be 99.9999% of the time in a server or desktop environment, is essentially the same thing that a monolithic kernel is . . . it's just flowed out differently.

Please . . . nobody post some benchmarks showing how "fast" Hurd is . . . as has already been pointed out, it supports next to nothing.

In my opinion, there is really no need for Hurd . . . it has no real "calling." The only reason for its continued existence or development is that Richard Stallman and various other FSF nomenclature extremists hate the word "Linux" and are on a never-ending quest to stamp it out . . . for no reason. (These are the same people who actually care about the vapid Linux vs GNU/Linux "controversy.")

If there was a need for Hurd, people would work on it and get it serviceable, as they have continued to do with the Linux kernel, FreeBSD, and all the other OSes out there which are actually useful, as opposed to letting it forever remain the next best thing if you can't get your hands on a copy of AmigaOS or Macintosh System 7.

I highly doubt that Pat will ever do this.

I vote against that name, even if he were to.

You have a good point. However, it's important to remember that, especially when talking about security patches, your network services will still almost certainly go down during the reload.

This advantage in a practical setting will usually, at most, amount to less downtime, and not none.

No, I'm gradually switching to a micro-kernel based operating system which actually boots ... BTW, Arch Hurd is booting just fine with the same VIA chipset. ;)

Someone at the FSF forgot to tell the folks at Arch.


Reread my posts and you should get the idea.

Actually, with the continual advancement of microprocessors there's becoming less and less reason to run monolithic or "hybrid" kernels such as Linux. ;)

HURD isn't designed to be faster than Linux...if anything it would be slower because of the client/server architecture in microkernels. A monolithic kernel will always be faster (and if memory is a concern the modularity of the Linux kernel will take care of that) -- it's just the possible crashes (a minor driver crash in a monolithic kernel will take down the whole system) and the uptime (avoiding rebooting the entire system when upgrading parts of the kernel) that are the main pulls for microkernels.
Kind of harsh, considering HURD existed before Linux. Linux was used because it worked well at the time, while HURD really didn't (despite being around for longer). If that ever becomes untrue, then GNU would obviously push for HURD (though Linux would of course survive since both the kernel and userspace are open source). Assuming GNU can ever actually get HURD working well and on diverse hardware, unless absolute peak performance is a must, HURD may very well be a better alternative, especially for long-term servers. I don't see why anyone should want HURD to fail...even if you stick to Linux on a desktop I still believe HURD would make a nice alternative for server use, while userspace remains fairly compatible with both. For now I'll stick to GNU/Linux and/or *BSD because they work well...but for the future, if it is better for my usage case, I would switch to HURD.
Fair point.

I read your posts as "I'm crying because a cheap piece of crap chip set" that Linux tried to support without any documentation doesn't work properly.

Why don't you just install Windows and call it a day?
Also if you like HURD so much, why not just start you're own distro?

Everyone's entitled to their opinion, I suppose. ;) Regardless of your opinion about a "crap chip set", computers with these chip sets (thousands) didn't boot for 6 months. I'd say that issue was pretty damn serious. ;)

Try rereading my previous posts ... much more carefully.

Personally, I think the answer is obvious. In case the answer isn't clear, I currently don't have the time to maintain a distribution nor do I think it's necessary with current offerings like Arch Hurd. Time will tell whether problems with recent kernels, not just the problem with the VIA chip sets a few years ago, will force distributors of Linux to look elsewhere as users begin looking elsewhere. As a user, I already am looking for alternatives based on a micro-kernel. Secondly, I never said that I "like HURD so much", but you're obviously prone to exaggeration and misinterpretation of my posts. Granted, I'm beginning to dislike the Linux kernel as it's increasingly buggy in my experience. Actually, the unfortunate events back around 2006 with the non-booting VIA chip sets forced me to look at alternatives, e.g. the HURD, Minix, and HelenOS.

I have a question, do you use the stock kernel? Or do you recompile you're own kernels? Because it sounds to me that you just use the stock kernel and all it a day when something breaks, and when it doesn't work you look for "alternatives". Is this correct? Personally I never use the stock kernel for anything, I find it useless and bloated because 90% of the modules or built in functions are not for my notebook/desktop/server(s) so rebuilding the kernel to me is a must for me.

I think you like the HURD kernel so much because in each of your posts you seem to try to make the HURD kernel look so great and then when a magical chip set VIA of all brands doesn't work you boycott the Linux kernel? these things happen, Linux is far from perfect, but it works, and I am talking now, not 6 years ago, not 4 years ago,not 9 months ago, but now! Because I am not sure if you are aware, hardware, nor Linux stands still, what doesn't work today may work in a week who knows, but it's going to be just like HURD, wait until the most bleeding edge hardware comes out, HURD won't support it either, no biggie.

No.

Do you have a problem with reading comprehension? Seriously. As I've said previously, I don't necessarily "like the HURD kernel so much". Actually, the Mach kernel has it's share of problems. For example, the Mach kernel must be updated to exploit x86_64 architectures. I do want reliability, however, so I've settled on a micro-kernel based operating system whether it's GNU's HURD or Minix 3, or ... As I've also previously stated, I do have a problem with increasingly buggy Linux kernels which can manifest in bizarre, hard to diagnose problems in addition to kernels which simply won't boot.

I guess these things (non-booting kernels for 6 months) happen with Linux kernels. As I've also already stated, GNU's HURD actually boots on the same VIA chip set that a 2006-2007 Linux kernel wouldn't boot for 6 months. The VIA chip set was hardly bleeding edge at the time (not old either) and you're blatantly wrong that it's "no biggie" to have a non-booting kernel for 6 months. Any computer of mine better boot not only today, but tomorrow or the operating system is history. Granted, it's important to have a generally working product and Linux has been an acceptable alternative to MS and Apple until the last few years. Even while searching for alternatives, I'll likely continue using Linux at least for the next few years. Again, time will tell whether the developers of the Linux kernel are on the right track. Personally, I think not and Tanenbaum will be proven correct eventually.

tpreitzel, maybe I missed some details you gave somewhere else in the discussion, but are you saying that you had a working kernel and suddenly it stopped booting? If it was an upgrade that broke it, you could have continued with the last working kernel, if not, it must be a strange bug -- something similar to Y2K maybe.

But the point is, in any case, the same could have happened with a microkernel, too. A bad code that rejects to run on a certain chipset will do so regardless of the kernel design, and if it is relevant to something crucial such as booting, you will end up with a useless system anyway. If it is not a vital component then you should be able to disable it in Linux, too. Use a microkernel if you like, but if it has buggy code, what is it good for? The end result is the same, your hardware won't work.

On the other hand I agree about the advantages of microkernels when it comes to downtime and security. If this is your main argument that's okay, but the problems you mentioned at the beginning don't seem to be relevant to the monolithic structure.

How is bickering about 'he said, they said' add to the topic of micro-kernels or the original topic?
Both types would be bloated with modules if lots of people would use both
Both types have advantages
Both types are viable options if they have people supporting them
Both types are reliable because modules moved into the stable branch are good enough to be used
And both types have their issues.

Is part of the reason the HURD got delayed infinitely because everybody who knows how to program a kernel in their free time works on the Linux kernel? I'm not saying either one is superior. I'm just guessing since Linux is up and running already all the brain power gravitates towards it.

I guess that is the main reason. HURD looked good on paper, but it appears that ideology/politics got in the way of progress, and wasn't even practical anyways. This is already the case since HURD is just so far behind that it is just not relevant.

Sometimes it is just best to call it quits and move on.

I would personally love to see a hybrid Hurd/Linux kernel being used, considering that a hybrid kernel is capable of having a GUI built into it, but a microkernel isn't and a monolithic kernel isn't.

Old news from last year regarding alleged comments by Linus about his own kernel, but still interesting nonetheless:

http://www.zdnet.com/blog/btl/torval...ght-poll/24643

Oh super it has a poll. I've never even looked at linux code but I'll vote on whether or not it's too bloated. My opinion counts. Sure.

Apparently Linus thinks his own kernel is bloated. Does his opinion count? ;)

Please, stop with the knee-jerk emotional responses. The latter applies to most posters in this thread, not just you.

Arch Hurd is INSTALLED!
 

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.

I didn't mean anything by it. The article was interesting I guess. I just think polls are silly.

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.

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.