summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/benefits_of_a_native_hurd_implementation.mdwn
diff options
context:
space:
mode:
authorSamuel Thibault <samuel.thibault@ens-lyon.org>2015-02-18 00:58:35 +0100
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2015-02-18 00:58:35 +0100
commit49a086299e047b18280457b654790ef4a2e5abfa (patch)
treec2b29e0734d560ce4f58c6945390650b5cac8a1b /service_solahart_jakarta_selatan__082122541663/benefits_of_a_native_hurd_implementation.mdwn
parente2b3602ea241cd0f6bc3db88bf055bee459028b6 (diff)
Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"
This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/benefits_of_a_native_hurd_implementation.mdwn')
-rw-r--r--service_solahart_jakarta_selatan__082122541663/benefits_of_a_native_hurd_implementation.mdwn139
1 files changed, 0 insertions, 139 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/benefits_of_a_native_hurd_implementation.mdwn b/service_solahart_jakarta_selatan__082122541663/benefits_of_a_native_hurd_implementation.mdwn
deleted file mode 100644
index dfd41837..00000000
--- a/service_solahart_jakarta_selatan__082122541663/benefits_of_a_native_hurd_implementation.mdwn
+++ /dev/null
@@ -1,139 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_documentation]]
-
-What are the benefits of a native GNU/Hurd system, now that Linux et al. can do
-so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux
-and other virtualization techiques, and so on.
-
-It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but...
-
-IRC, #hurd, August / September 2010
-
- <marcusb> ArneBab: but Neal and I were not happy with that alone. We were
- looking for deeper improvements to the system, for, I think, sound
- reasons. That is what brought us to the L4/Coyotos technologies
- <marcusb> ArneBab: as you are writing a kernel in user space, you can still
- do kernel improvements there
- <marcusb> ArneBab: if you take it very far, you end up with a kernel that
- runs Linux in user space (just flip the two) for the drivers
- <marcusb> ArneBab: that is what the L4 people did with the DDE
-
-[[/DDE]].
-
- <marcusb> ArneBab: so, with these different cuts, there are different
- opportunities. on the one end, you can run Linux as normal and get some
- of the Hurd features such as translators in some programs. At the other
- end, you can do whatever you want and run some linux code for the drivers
- or none at all.
- <marcusb> ArneBab: one of the big questions then becomes: at which point
- can the advantages offered by the Hurd be realized?
- <marcusb> ArneBab: and that's not entirely clear to me
- <marcusb> when I worked on this with Neal, we pushed further and further
- into need-to-change-everything land
- <marcusb> while the current efforts on the Hurd seem to be more equivalent
- to the could-run-it-in-userspace-on-top-of-Linux camp
- <ArneBab> marcusb: for that I think we need a way to move towards them step
- by step. Would it be possible to get the advantages of better resource
- allocation with a Viengoos in userspace, too?
- <ArneBab> and when that is stable, just switch over?
- <marcusb> ArneBab: I don't know. I suspect these people will know before
- us: http://lxc.sourceforge.net/
- <ArneBab> something like implementing flip points: flip Linux with Hurd to
- Hund with Linux. Flip Mach with L4 to L4 with Mach.
- <ArneBab> lxc sounds interesting.
- <marcusb> note that these efforts address security concerns more than other
- concerns
- <marcusb> so they will get isolation long before sharing is even considered
- <marcusb> but some of the issues are the same
- <marcusb> once you allow malware to do what it wants, it's a small step to
- also allow the user to what he wants :)
- <ArneBab> it kinda looks like hacking it where it doesn’t really fit again…
- <ArneBab> there I ask myself when the point comes that doing a cleaner
- design offsets the popularity
- <ArneBab> they are pushing more and more stuff into userspace
- <ArneBab> which is a good thing (to me)
- <ArneBab> it’s hard to clearly describe how, but even though I like having
- more stuff in userspace, the way it is bolted onto Linux doesn’t feel
- good for me.
- <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to
- a non-fuse user
- <ArneBab> while in the Hurd, these additional options are on eqal footing.
- <marcusb> ArneBab: are they pushing more and more into user space? I don't
- think so. I see more of the reverse, actually
- <marcusb> or maybe both
- <ArneBab> FUSE, lxd and scheduling in userspace move to userspace
- <ArneBab> well, KMS moved to the kernel
- <ArneBab> to avoid flickering when switching between X and the console?
- <ArneBab> marcusb: Do you experience FUSE lxc and such being secondclass in
- Linux, too, or is that just a strange feeling of me?
- <ArneBab> marcusb: and that splits the users into those who can get stuff
- into the kernel and those who can only work in userspace – which I don’t
- really like.
- <ArneBab> That’s one more advantage of the Hurd: eqal footing for all
- (except the Mach hackers, but they have a very limited terrain)
- <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have
- a principled objection to it (but just wanted a more general solution)
- <marcusb> ArneBab: as a side note, although people keep complaining, the
- linux kernel seems to be growing steadily, so getting stuff into the
- kernel doesn't seem too hard. 8-O
-
----
-
-IRC, #hurd, 2010-12-28
-
- <tim> but is monolithic so bad?
- <sartakov> yep
- <braunr> no it's not
- <braunr> proof: it works very well for most people
- [...]
- <braunr> the real problem is extensibility and interfaces
- <tim> :/ whats the huge advantage of micro-k
- <braunr> extensibility
- <tim> over?
- <braunr> you can add a whole lot of new services for new purposes with new
- interfaces without changing the kernel
- <tim> oright
- <braunr> it basically boils down to the original Unix idea: everything does
- one thing well
- [...]
- <kilobug> well, I would say extensibility and fault-tolerance are the two
- key advantages
- <braunr> taht's a side effect
- <braunr> there are fault taulerant monolithic kernels
- [...]
- <braunr> tolerant*
- <braunr> and the hurd is for now a non fault-tolerant microkernel based OS
- :/
- [...]
- <kilobug> braunr: not really; you can't ensure fault tolerance for code
- running in kernel space, code running in kernel space can do everything,
- including reboot, crash, ...
- [...]
- <braunr> kilobug: right, a monolithick kernel is less folt-tolerant than a
- well designed/implemented microkernel based os
-
-It turns out that it is perfectly possible to isolate services running in the
-same address space, as it was done in projects such as Singularity, the idea
-being that the code is verified through static analysis when installed (but
-this requires a language other than C).
-
- <kilobug> braunr: well, the Hurd is buggy nowadays, but things like an
- ext2fs translator doing a segfault and being restarted is a
- fault-tolerance that would be almost impossible to have in Linux
- <kilobug> braunr: sure, you can have fault-tolerance with FUSE, but FUSE is
- applying micro-kernel paradigm to Linux
- [...]
- <braunr> the reason i don't care that much about fault tolerance is that
- Linux obviously shows a monolithic kernel can run almost flawlessly if
- well written
- <braunr> but extensibility is really another matter