Some call it ngHurd, some call it HurdNG, and neither is official. Maybe it will get some completely different name.
Regarding the Hurd acronym, some seem actually to like it, but personally I don't. I usually just point out the wordplay (GNU Hurd pronounced as GNU Herd); at most a single recursive acronym (Hurd of UNIX Replacing Daemons). The double recursive acronym is really silly.
> What would it take to get that project kick started into wider acceptance and development? Or is it a steaming pile and not worth it, or what? I don't know much of anything about kernel innards at all, but if someone who does could run a quick synopsis over what is right or wrong (politics aside) with the Hurd I would appreciate it.
There are a number of technical problems -- most notably the choice of Mach for microkernel turned out to be a bad one -- but I won't go into this. Personally, I believe the main reasons for Hurd's missing success are organisational.
For one, as our favourite flamer ESR has pointed out, the project was badly managed from the beginning. While the situation changed quite a lot over the years, it was never a good one. Recently we got a new de-facto maintainer though, and things seem to get on track a litte. Let's see what will come of it.
The second problem is focus. While a number of people are working on improving various parts of the system, work almost exclusively focuses on catching up with established systems in performance, stability, compatibility etc. -- which, with the little manpower the project has, is hopeless. There is hardly any work on making better use of the possibilities the Hurd architecture provides, which would be necessary to show that the Hurd actually can offer vast practical advantages, not only a theoretically superior design.
Maybe you should look at Plan9: It does provide a very modular application infrastructure.
However, Plan9 does *not* have a modular kernel. Also, it is not UNIX-compatible.
With the Hurd on the other hand, while having the necessary foundations for a very modular archtecture both in the Kernel *and* in applications, the latter possibility is completely unused so far:-(
Hurd/L4 was an experimental port, developed in parallel to the existing implementation on Mach.
It turned out not to be feasible to build a system like the Hurd on top of the existing L4. (In fact, other projects realized that before, but sadly we learned about that only after the fact:-( )
While upcoming new L4 variants (L4ng and L4.sec) are meant to address the issues, during reexamination of possible microkernels, the original Hurd/L4 designers decided to build quite a different architecture instead. It probably will be called ngHurd, will use many concepts from Jonathan Shapiro's EROS/Coyotos systems, and most likely build on the Coyotos kernel.
Note that ngHurd will be even more experimental than Hurd/L4 was; and being quite a different system, it can't really be considered a direct successor of the existing Hurd implementation.
> Even computer programming is becoming more and more accessable to people as the higher level languages become more user-friendly.
That's a pipe dream. Sure, programming basic automation stuff becomes more accessible; and this is a very good thing, as it empowers users. But serious programming still needs very skilled people, and always will, to produce anything of acceptable quality. (Actually to produce anything once complexity gets up.)
If you have a CS degree and have to do help desk work, you better change your profession sooner than later. But that doesn't mean people talented in that subject should not study computer science. No doubt there are enough medicore programmers around -- but there is a considerable lack of really skilled ones.
Looking at how very very far we still are from GUIs that could really be consoderd user friendly and efficient, from OS designs that could be remotely considered powerful and accessible, software that would even remotely make good use of resources etc., I seriously wonder how you can make such a statement. And that doesn't even cover the problems with using upcoming new hardware technologies.
Aside from that, good programming really requires getting the theory right. Only because it's called computer science, it doesn't mean you should only study it if you want to become a researcher. Like in any other profession, you need a sound theoretical education to get a high-profile job. And this is a good thing. Considering how much terrible code we see out there, I deeply wish we had more well-educated people working in the field.
Sure, there are reasons it's more popular in Europe right now...
But luckily, the WWW is quite global thing. Europe is obviously serving as the early adopter here; but after it's happening in one place, surely others will follow.
Sure, the disk is the limiting factor, but boot doesn't speed up because it's really device initialization that makes it slow... Very consistent argument. I won't even bother to answer the rest.
Sorry, but this just doesn't make sense. The point is that if the disk was a major limiting factor, then tripling the disk speed would mean a *huge* increase in speed. However, as trippling the disk speed made very little difference, I know for sure that further increasing the disk speed would change even less. The disk is just not a major limiting factor anymore in my setup. (I can even tell that by listening to the noises it makes on boot...)
Again, there are setups (like my old one for example), where the disk *is* a major limit; however, this can not be generalized. Period.
Would you claim I can increase the speed of a journey to Australia indefinitely by increasing my speed walking to the next bus stop, on the ground that walking is my slowest means of conveyance?...
I have a vague recollection of Windows doing more disk trashing on startup than GNU/Linux; but I do not remember it being that bad as to make disk performance the only relevant factor.
Note that this is really a weakest-link situation: If trippling the disk speed halfed the boot time, it means the disk was actually the major stopper in the *original* setup; however, once you have a very fast disk, further disk speed improvements won't change much. Other factors will become more important now.
When I upgraded my old 1.7 GB disk to a 13 GB one, bootup got *lots* faster. However, now the CPU was the major stopper, and upgrading from Pentium 166 to Celeron 400 again resulted in a considerable speedup. Upgrading to a 40 GB afterwards disk didn't change that much -- the processor is still the slowest part in the system. After another CPU upgrade it would be different again, of course...
> OS boot times are usually disk and network bound.
While disk plays *some* role in OS startup, it's usually far from being the decisive factor. In a typical setup, a much larger amount of time is consumed on CPU use; and quite a large amount on various kinds of timeouts, related to networking, but not only -- various kinds of hardware probing etc. are the main reason why OS bootup doesn't even remotely scale with CPU and disk speed improvements.
CPU *does* make a considerable difference, but not an enormous one -- the other hardware in the box (which is also different for Intel Macs) might be quite relevant, too.
The whole point of the EPIC approach is to avoid dynamic optimizations like out-of-order processing... And actually avoid the need for it as far as possible, using some tricks.
The register set has some features (I agree that I am confusing them somewhat, as I don't remember the details), which actually help avoiding the need for register renaming in an EPIC environment.
BTW, there was some important difference between the SPARC and the Itanium stacked register file IIRC; so I don't think the comparison is valid.
Obviously, larger caches will always increase performance more or less, under otherwise unchanged conditions. My point is that due to various reasons, you can't just expect the same performance gain when boosting a P4 from 1 MiB cache to 9 as you get with Itanium. Actually, there is even prove for that: The MP Xeons with lots of cache offer quite medicore performance in single CPU setups compared to P4, and only the higher cache demand in a UMA SMP system justify them at all.
Nothing like an Itanium killer from a P4 with boosted caches, unlike the post I was replying to suggested...
> The good performance of Itanium comes a lot from its shitload of caches; nothing's preventing Intel from loading the P4 with caches though.
Actually, it's the other way round: Itanium needs larger caches to achieve good performance, because of the sparse machine code, and the fairly slow (compared to current x86 CPUs) FSB. P4 wouldn't profit nearly as much from larger caches.
With multicore chips, the Itanium will probably get a considerable boost on this front, as the instruction cache doesn't need to be scaled to the number of cores. OTOH, the cores themselfs are quite simple, so it's possible to integrate a large number of cores without considerably increasing the transistor count and power consumption.
> Intel figured it was big enough to set the trend by making a radical change. It was wrong and paid the price when the market didn't follow. IBM thought it was big enough to set the trend by making a radical change with Micro Channel Architecture (replacement for the ISA Bus). It went nowhere and helped kill IBM's dominance of the X86 PC world it created.
Such comparisions are silly. When IBM tried with PS/2, there market share on PCs was already down to 15 % or something. Intel is still at 80 % or so. There are many other reasons why the situations are quite different, including the fact Intel never believed or intended IA64 to replace x86 in a short run.
> Most of the improvements to IA-64 chips will probably benefit regular CPUs as well
I doubt it. Most of the improvements of IA64 are actually inherently bound to the ISA. They either do not work or do not make any sense on something like x86.
> for an interesting parallel, consider Linus's comments re: Monolithic vs. Micro kernels
I'm not sure this is a good parallel. While in theory every optimization introduced in a microkernel system could be also done in a monolithic one, only the reduced complexity and higher flexibility of microkernel system make many optimizations feasible in practice. I've no idea how you want to transfer this finding to processor architectures...:-)
> You do realize that Intel already solved the scheduling, prediction, and speculation problem in hardware. Doing it in software was just a matter of learning different mechanisms for accomplishing the same ends
That's not quite true. The big difference is that the hardware implementation can do *dynamic* reordering, i.e. look at what's actually happening and cater to that. The software implementation needs to guess *beforehand*. This is quite a different problem. (And a much harder one at that.)
> Itanic's real problem is power consumption. The x86 instruction set encoding essentially serves as a form of data compression, as does running counters on the fly for branch prediction. Itanic expands those data paths to the full width using dedicated hardware, all of which runs in parallel all the time. The performance is incredible, but at a high cost in power consumption.
True. I wonder if Intel plans to introduce some kind of code compression, and how this could be done without forsaking the advantages of EPIC...
> I figure that IF IBM gets it's act together and is able to supply both the quantity and quality (read: chips faster than 2.5gHz ) of PPC chips that Apple wants Apple will use them in their high-end line like the XServe, PowerBook and PowerMac. The Intel chips would be used on the low-end such as the iBook, iMac and MacMini.
Already forgot that the the major reason for the move is the enormous power consumption of G5, making it unsuitable for PowerBooks? I do not see how they would use the so much better Pentium M chips only for their low level stuff...
Slashdot Mirror
Some call it ngHurd, some call it HurdNG, and neither is official. Maybe it will get some completely different name.
Regarding the Hurd acronym, some seem actually to like it, but personally I don't. I usually just point out the wordplay (GNU Hurd pronounced as GNU Herd); at most a single recursive acronym (Hurd of UNIX Replacing Daemons). The double recursive acronym is really silly.
> What would it take to get that project kick started into wider acceptance and development? Or is it a steaming pile and not worth it, or what? I don't know much of anything about kernel innards at all, but if someone who does could run a quick synopsis over what is right or wrong (politics aside) with the Hurd I would appreciate it.
There are a number of technical problems -- most notably the choice of Mach for microkernel turned out to be a bad one -- but I won't go into this. Personally, I believe the main reasons for Hurd's missing success are organisational.
For one, as our favourite flamer ESR has pointed out, the project was badly managed from the beginning. While the situation changed quite a lot over the years, it was never a good one. Recently we got a new de-facto maintainer though, and things seem to get on track a litte. Let's see what will come of it.
The second problem is focus. While a number of people are working on improving various parts of the system, work almost exclusively focuses on catching up with established systems in performance, stability, compatibility etc. -- which, with the little manpower the project has, is hopeless. There is hardly any work on making better use of the possibilities the Hurd architecture provides, which would be necessary to show that the Hurd actually can offer vast practical advantages, not only a theoretically superior design.
Maybe you should look at Plan9: It does provide a very modular application infrastructure.
:-(
However, Plan9 does *not* have a modular kernel. Also, it is not UNIX-compatible.
With the Hurd on the other hand, while having the necessary foundations for a very modular archtecture both in the Kernel *and* in applications, the latter possibility is completely unused so far
Hurd/L4 was an experimental port, developed in parallel to the existing implementation on Mach.
:-( )
It turned out not to be feasible to build a system like the Hurd on top of the existing L4. (In fact, other projects realized that before, but sadly we learned about that only after the fact
While upcoming new L4 variants (L4ng and L4.sec) are meant to address the issues, during reexamination of possible microkernels, the original Hurd/L4 designers decided to build quite a different architecture instead. It probably will be called ngHurd, will use many concepts from Jonathan Shapiro's EROS/Coyotos systems, and most likely build on the Coyotos kernel.
Note that ngHurd will be even more experimental than Hurd/L4 was; and being quite a different system, it can't really be considered a direct successor of the existing Hurd implementation.
> Even computer programming is becoming more and more accessable to people as the higher level languages become more user-friendly.
That's a pipe dream. Sure, programming basic automation stuff becomes more accessible; and this is a very good thing, as it empowers users. But serious programming still needs very skilled people, and always will, to produce anything of acceptable quality. (Actually to produce anything once complexity gets up.)
If you have a CS degree and have to do help desk work, you better change your profession sooner than later. But that doesn't mean people talented in that subject should not study computer science. No doubt there are enough medicore programmers around -- but there is a considerable lack of really skilled ones.
Looking at how very very far we still are from GUIs that could really be consoderd user friendly and efficient, from OS designs that could be remotely considered powerful and accessible, software that would even remotely make good use of resources etc., I seriously wonder how you can make such a statement. And that doesn't even cover the problems with using upcoming new hardware technologies.
Aside from that, good programming really requires getting the theory right. Only because it's called computer science, it doesn't mean you should only study it if you want to become a researcher. Like in any other profession, you need a sound theoretical education to get a high-profile job. And this is a good thing. Considering how much terrible code we see out there, I deeply wish we had more well-educated people working in the field.
"Computer science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra
> Apple came out with the mac mini, Intel slapped together a x86 look-alike
Actually, Intel was creating various "studies" of stuff like this for years.
Sure, there are reasons it's more popular in Europe right now...
But luckily, the WWW is quite global thing. Europe is obviously serving as the early adopter here; but after it's happening in one place, surely others will follow.
Considering that it has passed this "barrier" long ago in many european countries, I do not see a big problem here.
Sure, the disk is the limiting factor, but boot doesn't speed up because it's really device initialization that makes it slow... Very consistent argument. I won't even bother to answer the rest.
Sorry, but this just doesn't make sense. The point is that if the disk was a major limiting factor, then tripling the disk speed would mean a *huge* increase in speed. However, as trippling the disk speed made very little difference, I know for sure that further increasing the disk speed would change even less. The disk is just not a major limiting factor anymore in my setup. (I can even tell that by listening to the noises it makes on boot...)
Again, there are setups (like my old one for example), where the disk *is* a major limit; however, this can not be generalized. Period.
Would you claim I can increase the speed of a journey to Australia indefinitely by increasing my speed walking to the next bus stop, on the ground that walking is my slowest means of conveyance?...
I have a vague recollection of Windows doing more disk trashing on startup than GNU/Linux; but I do not remember it being that bad as to make disk performance the only relevant factor.
Note that this is really a weakest-link situation: If trippling the disk speed halfed the boot time, it means the disk was actually the major stopper in the *original* setup; however, once you have a very fast disk, further disk speed improvements won't change much. Other factors will become more important now.
When I upgraded my old 1.7 GB disk to a 13 GB one, bootup got *lots* faster. However, now the CPU was the major stopper, and upgrading from Pentium 166 to Celeron 400 again resulted in a considerable speedup. Upgrading to a 40 GB afterwards disk didn't change that much -- the processor is still the slowest part in the system. After another CPU upgrade it would be different again, of course...
P4-m also exists, though barely in use nowadays. (Pentium M is just so much better...)
> OS boot times are usually disk and network bound.
While disk plays *some* role in OS startup, it's usually far from being the decisive factor. In a typical setup, a much larger amount of time is consumed on CPU use; and quite a large amount on various kinds of timeouts, related to networking, but not only -- various kinds of hardware probing etc. are the main reason why OS bootup doesn't even remotely scale with CPU and disk speed improvements.
CPU *does* make a considerable difference, but not an enormous one -- the other hardware in the box (which is also different for Intel Macs) might be quite relevant, too.
The whole point of the EPIC approach is to avoid dynamic optimizations like out-of-order processing... And actually avoid the need for it as far as possible, using some tricks.
The register set has some features (I agree that I am confusing them somewhat, as I don't remember the details), which actually help avoiding the need for register renaming in an EPIC environment.
BTW, there was some important difference between the SPARC and the Itanium stacked register file IIRC; so I don't think the comparison is valid.
Obviously, larger caches will always increase performance more or less, under otherwise unchanged conditions. My point is that due to various reasons, you can't just expect the same performance gain when boosting a P4 from 1 MiB cache to 9 as you get with Itanium. Actually, there is even prove for that: The MP Xeons with lots of cache offer quite medicore performance in single CPU setups compared to P4, and only the higher cache demand in a UMA SMP system justify them at all.
Nothing like an Itanium killer from a P4 with boosted caches, unlike the post I was replying to suggested...
Oh, another thing:
> x86 is bad/ugly/dirty/whatever, however Itanium is not exactly clean either. The stacked register file is a good example of that.
What's wrong with the register file? It's actually a very smart (and clean) solution to the problem of explicitely parallelizing register usage.
> The good performance of Itanium comes a lot from its shitload of caches; nothing's preventing Intel from loading the P4 with caches though.
Actually, it's the other way round: Itanium needs larger caches to achieve good performance, because of the sparse machine code, and the fairly slow (compared to current x86 CPUs) FSB. P4 wouldn't profit nearly as much from larger caches.
With multicore chips, the Itanium will probably get a considerable boost on this front, as the instruction cache doesn't need to be scaled to the number of cores. OTOH, the cores themselfs are quite simple, so it's possible to integrate a large number of cores without considerably increasing the transistor count and power consumption.
> Intel figured it was big enough to set the trend by making a radical change. It was wrong and paid the price when the market didn't follow. IBM thought it was big enough to set the trend by making a radical change with Micro Channel Architecture (replacement for the ISA Bus). It went nowhere and helped kill IBM's dominance of the X86 PC world it created.
Such comparisions are silly. When IBM tried with PS/2, there market share on PCs was already down to 15 % or something. Intel is still at 80 % or so. There are many other reasons why the situations are quite different, including the fact Intel never believed or intended IA64 to replace x86 in a short run.
> Most of the improvements to IA-64 chips will probably benefit regular CPUs as well
:-)
I doubt it. Most of the improvements of IA64 are actually inherently bound to the ISA. They either do not work or do not make any sense on something like x86.
> for an interesting parallel, consider Linus's comments re: Monolithic vs. Micro kernels
I'm not sure this is a good parallel. While in theory every optimization introduced in a microkernel system could be also done in a monolithic one, only the reduced complexity and higher flexibility of microkernel system make many optimizations feasible in practice. I've no idea how you want to transfer this finding to processor architectures...
> Oh with out a doubt, Intel hoped that the Itanium would be The Next Big Thing(tm) and that all computers would go IA-64.
I remember Intel announcing somewhere around 1998 that IA64 won't be for the mass market at least until somewhere around 2008 or so.
Sure they hoped some day all computers will go IA64, and most likely they still do. But they never expected it to happen very soon.
> You do realize that Intel already solved the scheduling, prediction, and speculation problem in hardware. Doing it in software was just a matter of learning different mechanisms for accomplishing the same ends
That's not quite true. The big difference is that the hardware implementation can do *dynamic* reordering, i.e. look at what's actually happening and cater to that. The software implementation needs to guess *beforehand*. This is quite a different problem. (And a much harder one at that.)
> Itanic's real problem is power consumption. The x86 instruction set encoding essentially serves as a form of data compression, as does running counters on the fly for branch prediction. Itanic expands those data paths to the full width using dedicated hardware, all of which runs in parallel all the time. The performance is incredible, but at a high cost in power consumption.
True. I wonder if Intel plans to introduce some kind of code compression, and how this could be done without forsaking the advantages of EPIC...
> I figure that IF IBM gets it's act together and is able to supply both the quantity and quality (read: chips faster than 2.5gHz ) of PPC chips that Apple wants Apple will use them in their high-end line like the XServe, PowerBook and PowerMac. The Intel chips would be used on the low-end such as the iBook, iMac and MacMini.
Already forgot that the the major reason for the move is the enormous power consumption of G5, making it unsuitable for PowerBooks? I do not see how they would use the so much better Pentium M chips only for their low level stuff...