Page 5 of 5 FirstFirst ... 345
Results 41 to 49 of 49

Thread: GNU Hurd 0.5, GNU Mach 1.4 Released

  1. #41
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    316

    Default

    Not true. It's needed because I really DON'T want any random code to corrupt my network hardware ! (http://lwn.net/Articles/304105/) And because I don't want to take the risk of crashing everything when I try out a new kernel module.
    Also further to this, Genode appears to be superior to the HURD architecturally in almost every way.

  2. #42
    Join Date
    Jul 2011
    Posts
    73

    Default

    Quote Originally Posted by jayrulez View Post
    So I am a troll because I have a preference? I expected better from you Richard Braun.

    You may need to work on your reading comprehension skills sir.

    Now I'll head back to the hills to herd some goats or something. You can go back to being a dick.
    Now you are a troll.

  3. #43
    Join Date
    Oct 2013
    Posts
    4

    Default

    Quote Originally Posted by mrugiero View Post
    Can it enforce any given subsystem (not implemented INSIDE the kernel, I mean) to expose things as files?
    Simple way: just don't allow users to create servers and make privileged system servers not expose things as files. That obviously wouldn't be a Hurd-like system.

    Quote Originally Posted by mrugiero View Post
    My statement wasn't that one shouldn't focus on performance, but rather that I don't think that's the right design if performance is the top priority.
    Obviously, the microkernel approach trades some performance for features. But still, the "ideal" approach for performance would be all in the kernel. Even monolithic systems are just a compromise trying to balance performance and features. Actually, if we define a microkernel as "the near-minimum amount of software that can provide the mechanisms needed to implement an operating system (OS)", monolithic kernel advocates would say monolithic kernels are microkernels, something we obviously do not agree on. The difference simply lies in the threshold between what we want in the kernel and what we want outside, keeping in mind that each time we move something out, it should be motivated by the introduction of a useful indirection layer such as virtual address spaces and capabilities.

    Quote Originally Posted by mrugiero View Post
    It relates to reliability simply because you can take down and restart faulty features without going completely down. At least, that's what I think.
    No, it really has nothing to do with the concept of modularity. What you're describing is resilience. By the way, resilience was never a goal for the Hurd, just a nice side-effect for non-critical servers such as the network stack and non-root file systems.

    Quote Originally Posted by mrugiero View Post
    He stated what he likes, not the reasons, so I don't see how showing its flaws can refute the statement.
    Like I said, it was a troll. Let's feed a bit more by linking the statement with "Why is this alternative needed and who needs it ?". Since FreeBSD has practically the same goals as Linux, and their design is also the same, I thought it would be obvious why the Hurd is a nice alternative to have in comparison... But I understand people have their preferences and like to publically defend them. After all, I use the Hurd.

    Quote Originally Posted by jayrulez View Post
    I never said you said that.
    OK, let's be completely pedantic. You said I *think* that. I understand there is no way you can say I said it, since I've never said it, but tell me how you know I think it, I'm very much interested. I don't care much about apologies, just get your facts right.

    Quote Originally Posted by jayrulez View Post
    So I am a troll because I have a preference? I expected better from you Richard Braun.
    The word "troll" referred to what I said, not you.
    Quote Originally Posted by jayrulez View Post
    You may need to work on your reading comprehension skills sir.
    Quote Originally Posted by jayrulez View Post
    I did not state that. Also, going by the most popular definitions of a microkernel, those kernels do not fall under that category. You should know well that there are varying definitions for the term "microkernel".
    I know you didn't, but what you say next is wrong nonetheless. XNU is a microkernel based system. The fact that it runs a big BSD on top of it doesn't change that. It's still a monolithic system, with a microkernel, hence the importance of introducing the concept of "multiserver". The word "microkernel" itself can refer to both hybrids and nanokernels (or what some people call "true microkernels"). So yes, I know that well.

    Quote Originally Posted by jayrulez View Post
    Also further to this, Genode appears to be superior to the HURD architecturally in almost every way.
    Except in two important areas :

    1/ POSIX compatibility is only achieved by running a legacy system on top of it, restricting communication with the rest of the system, whereas the Hurd provides amazing conformance with little efforts.

    2/ It's noticeably slow, something that was mentioned during FOSDEM this year, probably because of the massive decoupling of objects. While the Hurd is obviously slow, this comes from implementation defects, mainly scalability issues that prevent it from dealing well with the amount of memory modern machines have. By being a little more coarse-grained, the design potentially reduces the amount of communication compared to L4 based systems. IMO, it's a more viable compromise of features/performance, but we'll only know when those issues are fixed in the Hurd.

    Quote Originally Posted by jayrulez View Post
    Now I'll head back to the hills to herd some goats or something.
    Yes, you do that, thanks.

  4. #44
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

    Quote Originally Posted by rbraun View Post
    "Hurd is actually more hybrid-kernel. It doesn't run drivers in separate processes, which is most important for stability.
    If you really want micro-kernel, QNX is your best choice (sadly it is proprietary and is dying)."
    Partially true. GNU Mach (not the Hurd) is a hybrid because it implements capabilities, high level virtual memory (memory allocation, copy on write, anonymous memory), resource containers (tasks), complex thread scheduling, and most device drivers. That is still too much to consider it a true microkernel like L4. On the other hand, a hybrid has its advantages since it allows reducing the amount of communication for things we may not want to replace by a userspace implementation (just look at how many operations and servers are involved for a mere malloc on an L4 based system). I agree QNX is a good implementation to consider, although it's still not a true microkernel by modern standards, since it also implements capabilities (channels and connections) in the kernel, unless I'm mistaken.
    I think moving drivers out of kernel would make it quite microkernel.

    I really hope we will get some decent microkernel unix-like OS some day.

  5. #45
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    316

    Default

    Quote Originally Posted by ArneBab View Post
    Now you are a troll.
    No, you're a troll.

  6. #46
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    316

    Default

    Quote Originally Posted by LightBit View Post
    I think moving drivers out of kernel would make it quite microkernel.

    I really hope we will get some decent microkernel unix-like OS some day.
    Microkernels are not about the size of the kernel. E.g.: You could move all the drivers from the Linux kernel to userspace and it would still be monolithic.

  7. #47
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

    Quote Originally Posted by jayrulez View Post
    Microkernels are not about the size of the kernel.
    Indeed, otherwise Plan 9 would be microkernel.

    Quote Originally Posted by jayrulez View Post
    E.g.: You could move all the drivers from the Linux kernel to userspace and it would still be monolithic.
    No, it would be some weird "hybrid" and I was talking about Mach.

  8. #48
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    316

    Default

    OK, let's be completely pedantic. You said I *think* that. I understand there is no way you can say I said it, since I've never said it, but tell me how you know I think it, I'm very much interested. I don't care much about apologies, just get your facts right.
    <gnu_srs> And you will address the design flaws or implementation faults
    with x15?
    <braunr> no
    <braunr> i'll address the implementation details
    <braunr> and some design issues like cpu and memory resource accounting
    <braunr> but i won't implement generic resource containers
    <braunr> assuming it's completed, my work should provide a hurd system on
    par with modern monolithic systems
    <braunr> (less performant of course, but performant, scalable, and with
    about the same kinds of problems)
    <braunr> for example, thread migration should be mandatory
    <braunr> which would make client calls behave exactly like a userspace task
    asking a service from the kernel
    <braunr> you have to realize that, on a monolithic kernel, applications are
    clients, and the kernel is a server
    <braunr> and when performing a system call, the calling thread actually
    services itself by running kernel code
    <braunr> which is exactly what thread migration is for a multiserver system
    <braunr> thread migration also implies sync IPC
    <braunr> and sync IPC is inherently more performant because it only
    requires one copy, no in kernel buffering
    <braunr> sync ipc also avoids message floods, since client threads must run
    server code
    <gnu_srs> and this is not achievable with evolved gnumach and/or hurd?
    <braunr> well that's not entirely true, because there is still a form of
    async ipc, but it's a lot less likely
    <braunr> it probably is
    <braunr> but there are so many things to change i prefer starting from
    scratch
    <braunr> scalability itself probably requires a revamp of the hurd core
    libraries
    <braunr> and these libraries are like more than half of the hurd code
    <braunr> mach ipc and vm are also very complicated
    <braunr> it's better to get something new and simpler from the start
    <gnu_srs> a major task nevertheless:-D
    <braunr> at least with the vm, netbsd showed it's easier to achieve good
    results from new code, as other mach vm based systems like freebsd
    struggled to get as good
    <braunr> well yes
    <braunr> but at least it's not experimental
    <braunr> everything i want to implement already exists, and is tested on
    production systems
    <braunr> it's just time to assemble those ideas and components together
    into something that works
    <braunr> you could see it as a qnx-like system with thread migration, the
    global architecture of the hurd, and some improvements from linux like
    rcu
    I know you didn't, but what you say next is wrong nonetheless. XNU is a microkernel based system. The fact that it runs a big BSD on top of it doesn't change that. It's still a monolithic system, with a microkernel, hence the importance of introducing the concept of "multiserver". The word "microkernel" itself can refer to both hybrids and nanokernels (or what some people call "true microkernels"). So yes, I know that well.
    Did you say pedantic earlier?

    1/ POSIX compatibility is only achieved by running a legacy system on top of it, restricting communication with the rest of the system, whereas the Hurd provides amazing conformance with little efforts.
    Obviously, POSIX compatibility is not a goal of Genode. POSIX compatibility is added on a as needed basis. For example: to allow Qt and other ported libraries.

    2/ It's noticeably slow, something that was mentioned during FOSDEM this year, probably because of the massive decoupling of objects. While the Hurd is obviously slow, this comes from implementation defects, mainly scalability issues that prevent it from dealing well with the amount of memory modern machines have. By being a little more coarse-grained, the design potentially reduces the amount of communication compared to L4 based systems. IMO, it's a more viable compromise of features/performance, but we'll only know when those issues are fixed in the Hurd.
    The slowness in Genode also come from implementation defects, however, without the scalability issues present in HURD.
    For example: about 3 weeks ago, a commit was made which resulted in more than 2.5x speed increase when running the toolchain(that is compiling genode on genode) for the core on the NOVA kernel.

  9. #49
    Join Date
    Oct 2013
    Posts
    4

    Default

    Quote Originally Posted by jayrulez View Post
    Did you say pedantic earlier?
    Good job for such a big post without pointing out what you actually wanted to say.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •