Linked by Thom Holwerda on Wed 9th Nov 2011 21:26 UTC, submitted by edwin
General Unix Way back in 2002, MIT decided it needed to start teaching a course in operating system engineering. As part of this course, students would write an exokernel on x86, using Sixth Edition Unix (V6) and John Lions' commentary as course material. This, however, posed problems.
Thread beginning with comment 496945
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: binary for windows....
by christian on Fri 11th Nov 2011 10:07 UTC in reply to "RE: binary for windows.... "
christian
Member since:
2005-07-06

"I guess all that is missing is a functional libc, and shared memory, shared libraries...

What makes you so sure shared libraries is important or even desirable?

http://9fans.net/archive/2008/11/142
"

All well and good until you find a critical bug in that DNS client library that every network capable program you have installed uses, and you now have to recompile (or relink at least) every single one of them.

Shared libraries may give memory usage benefits or not, may cause DLL hell in some cases, but from a modularity and management point of view, they're a god send.

Performance poor? That's an implementation detail of using lookup tables. There's nothing stopping the system implementing a full run time direct link, at the expense of memory and start up performance.

Reply Parent Score: 2

bogomipz Member since:
2005-07-11

The argument that updating a library will fix the bug in all programs that dynamically link said library goes both ways; breaking the library also beaks all programs at the same time.

And if security is a high priority, you should be aware that dynamic linking has some potential risks on its own. LD_LIBRARY_PATH is a rather dangerous thing, especially when combined with a suid root binary.

Reply Parent Score: 2

jabjoe Member since:
2009-05-06

I'll take being able to easily fix everything with easily being able to break everything every time over not able to fix anything.

The LD_LIBRARY_PATH suid root binary security hole is one that if you know about you can avoid. It's not something that means throw the whole system out.

Update: Looks it's protected against anyway.
http://en.wikipedia.org/wiki/Setuid

"The invoking user will be prohibited by the system from altering the new process in any way, such as by using ptrace, LD_LIBRARY_PATH or sending signals to it"

Edited 2011-11-11 11:43 UTC

Reply Parent Score: 2

Alfman Member since:
2011-01-28

christian,

"All well and good until you find a critical bug in that DNS client library that every network capable program you have installed uses, and you now have to recompile (or relink at least) every single one of them."

Your point is well received.

However this person has a slightly different suggestion:

http://www.geek-central.gen.nz/peeves/shared_libs_harmful.html

He thinks applications shouldn't use shared libraries for anything which isn't part of the OS. This would largely mitigate DLL hell for unmanaged programs.

I realize this answer is gray and therefor unsatisfactory.


A better solution would be to have a standardized RPC mechanism to provide functionality for things like DNS. The glue code would be small, and could always be linked statically. This RPC would be kernel/user space agnostic, and could be repaired while remaining compatible. I think the shift from shared libraries to more explicit RPC interfaces would be beneficial, but it'd basically need a new OS designed to use it from the ground up - now that linux hosts tons of stable code, it's unlikely to happen.

Reply Parent Score: 2