41–50 of 55 posts
Earlier quoted context omitted.
Exciting! "processes running under multiple uids" Why?
I remember seeing a demo of a very early version of HURD in 2002, and I thought this was the most interesting thing about it. I think in the demo, Marcus Brinkmann showed how in the midst of editing a file in vi in user mode, you could open another file in superuser mode, do an edit there and then go back to the old file in user mode.
Earlier quoted context omitted.
I don't get all this hate on Linux: it basically sustained GNU project for almost 25 years...
Diversity is a good thing. Systems-level research is at a woeful state right now because the status quo is Good Enough for a lot of people. Thus, the number of interesting ideas to try, to fail, to succeed is a trickle to what it should be. Database-based and object-based filesystems are little more than research projects because of the hard to shake belief of what stored items should look like and what their propert…
Earlier quoted context omitted.
I remember seeing a demo of a very early version of HURD in 2002, and I thought this was the most interesting thing about it. I think in the demo, Marcus Brinkmann showed how in the midst of editing a file in vi in user mode, you could open another file in superuser mode, do an edit there and then go back to the old file in user mode.
the editor of the beast. Now with root.
The preliminary rump kernel support that arrived just a bit more than a week ago is quite promising, if still quite rudimentary. That said, a patched MPlayer linking to rump libraries has been able to play OGG files on a Hurd system: https://lists.gnu.org/archive/html/bug-hurd/2015-08/msg00027... Though obviously in the very initial stages, the implications of this development taken to its end could be enormous. Have…
While Hurd improves its userspace support, the should also revisit the idea of rebasing the OS on L4 (where you can also load a Linux instance in userspace for compatibility) or Minix3 which has been working on its own kernel features.
The preliminary rump kernel support that arrived just a bit more than a week ago is quite promising, if still quite rudimentary. That said, a patched MPlayer linking to rump libraries has been able to play OGG files on a Hurd system: https://lists.gnu.org/archive/html/bug-hurd/2015-08/msg00027... Though obviously in the very initial stages, the implications of this development taken to its end could be enormous. Have…
Guix is becoming increasingly ready for prime time. There's one big HPC install in Germany already running it. I think it's past the toy stage. I guess Guix + Hurd is a great setup, with innovative features in the kernel and userland. Both very pure in their respective ways, with Guix having functional package management, and Hurd keeping the kernel minimal so that crashes or security breaches are not catastrophic.
Earlier quoted context omitted.
I don't get all this hate on Linux: it basically sustained GNU project for almost 25 years...
No one is hating Linux. But Linux isn't exactly of much help towards advancing the status quo of OSes, either.
But their reasons seems mainly because of NIH syndrome: those who like to create a new OS also to tinker with "their own kernel" instead of reusing something already existing.
The preliminary rump kernel support that arrived just a bit more than a week ago is quite promising, if still quite rudimentary. That said, a patched MPlayer linking to rump libraries has been able to play OGG files on a Hurd system: https://lists.gnu.org/archive/html/bug-hurd/2015-08/msg00027... Though obviously in the very initial stages, the implications of this development taken to its end could be enormous. Have…
The biggest limiting factor at the moment with Hurd is their choice for the base microkernel, currently Mach which hasn't had substantial updates for years. While Hurd improves its userspace support, the should also revisit the idea of rebasing the OS on L4 (where you can also load a Linux instance in userspace for compatibility) or Minix3 which has been working on its own kernel features.
Not true. GNU Mach has been undergoing lots of refactoring recently with regards to locking, protected payloads for threefold lowering of RPC lookups, the VM subsystem and so forth.
Earlier quoted context omitted.
No one is hating Linux. But Linux isn't exactly of much help towards advancing the status quo of OSes, either.
That's highly debatable: for example BeOS recreators/Haiku devs CHOSE to use a new exotic kernel instead of Linux or FreeBSD kernel. But their reasons seems mainly because of NIH syndrome: those who like to create a new OS also to tinker with "their own kernel" instead of reusing something already existing.
It's far more effort to try and learn the ins-and-outs of a large kernel like FreeBSD or Linux, then try to shoehorn completely different OS semantics onto Unix, than to just roll your own.
Also, Haiku's kernel was forked from NewOS, which was back in 2001, and written by a former Be engineer.
Besides, how is their choice signifying a hatred for Linux?
Earlier quoted context omitted.
That's highly debatable: for example BeOS recreators/Haiku devs CHOSE to use a new exotic kernel instead of Linux or FreeBSD kernel. But their reasons seems mainly because of NIH syndrome: those who like to create a new OS also to tinker with "their own kernel" instead of reusing something already existing.
Why the hell would you recreate BeOS on a Unix-like kernel? Are you even listening to yourself? That's not NIH, that's common sense. It's far more effort to try and learn the ins-and-outs of a large kernel like FreeBSD or Linux, then try to shoehorn completely different OS semantics onto Unix, than to just roll your own. Also, Haiku's kernel was forked from NewOS, which was back in 2001, and written by a former Be en…
Because you wouldn't have to code all these drivers to make the result an useful OS?
> Are you even listening to yourself? That's not NIH, that's common sense.
1) You're being rude. 2) 'common sense' is not an argument.
> It's far more effort to try and learn the ins-and-outs of a large kernel like FreeBSD or Linux, then try to shoehorn completely different OS semantics onto Unix, than to just roll your own.
Well its depends whether your goal is to have an OS running in very few configurations or if your goal is to have an OS which is able to be run by many.
> Besides, how is their choice signifying a hatred for Linux?
It doesn't, I was replying to the sentence "But Linux isn't exactly of much help towards advancing the status quo of OSes, either." an OS isn't a kernel and there WERE discussions about whether using Linux or FreeBSD kernel or NewOS in Haiku..
Earlier quoted context omitted.
Why the hell would you recreate BeOS on a Unix-like kernel? Are you even listening to yourself? That's not NIH, that's common sense. It's far more effort to try and learn the ins-and-outs of a large kernel like FreeBSD or Linux, then try to shoehorn completely different OS semantics onto Unix, than to just roll your own. Also, Haiku's kernel was forked from NewOS, which was back in 2001, and written by a former Be en…
> Why the hell would you recreate BeOS on a Unix-like kernel? Because you wouldn't have to code all these drivers to make the result an useful OS? > Are you even listening to yourself? That's not NIH, that's common sense. 1) You're being rude. 2) 'common sense' is not an argument. > It's far more effort to try and learn the ins-and-outs of a large kernel like FreeBSD or Linux, then try to shoehorn completely differen…
Writing a driver framework compatibility layer is quite a separate and doable activity from adopting an entire kernel. Haiku actually does have some FreeBSD driver compatibility, and then efforts like DDE have been around for running Linux 2.6 drivers on other systems. More recently rump kernels.
You're being rude.
You're being ignorant.
Well its depends whether your goal is to have an OS running in very few configurations or if your goal is to have an OS which is able to be run by many.
Absolute nonsense, as elaborated above.