31–40 of 100 posts
Took this class at MIT. 20/10 would recommend, especially for people who don't come from a systems background. The textbook is quite easy to understand and the labs are a very good check of your comprehension. Just maybe skip the network driver on the first go around :P
Earlier quoted context omitted.
a lot of people agree with you, which is why minix exists (though their source control system just fell offline this year), but none of windows nt, linux, os/360, and even really macos/ios are microkernel designs. sel4 and the other l4 variants are, and so is qnx, and linuxcnc runs linux under a microkernel, and xen is kind of a microkernel if you look at it funny, so we're definitely seeing significant mainstream us…
Actually, z/OS (descendant of System/370) is more microkernel than Linux is. But the problem with microkernels is similar to the problem with microservices - you have to make the executive decisions somewhere, and that unfortunately ends up being the bulk of "business logic" that the OS does. In theory, I like the concept of functional core, imperative shell - the imperative shell provides various functions as a kind…
btw, when you say 'z/OS (descendant of System/370)', i think you are confusing hardware and software; system/370 was the hardware (obsolete), os/360 the software (sadly, not obsolete; later renamed os/370, mvs, and z/os in a series of increasingly desperate attempts to escape its reputation)
generally the functional/imperative contrast centers on mutability: imperative style uses mutability, and functional style doesn't. is that what you mean? i'm not sure a functional core in the sense of 'mutation-free core' is a reasonable way to build a computer operating system, because limiting resource consumption and handling failures reliably are two central concerns for operating systems, and typically immutability makes them much more difficult. immutability does have a lot of uses in modern operating systems, but at least on current hardware, it makes more sense to me to build it as an functional shell around a mutable core than the other way around
(the other aspect of the functional/imperative axis has to do with constructing new functions at runtime, passing them as arguments to subroutines, and returning them from subroutines: you do these things in functional programming, but not in imperative programming. i am at a loss how this could relate to what you're talking about at all.)
it's not clear to me what https://web.archive.org/web/20070403130947/http://alistair.c... has to do with functional-core/imperative-shell or for that matter with operating system kernels. can you elaborate?
for the most part operating systems design is an exercise in delegating as much as possible of those 'executive decisions' to userspace. 'mechanism, not policy' is the mantra for kernels and for system software in general, including things like device drivers and window servers. that way, you can use different policies in different parts of the system and change them over time without destabilizing the system. i feel like microkernels are generally better at this than monolithic kernels, and sel4 in particular takes this to the extreme
Earlier quoted context omitted.
Ultibo is pretty cool… https://ultibo.org/ It’s a bare metal Free Pascal environment for Raspberry Pi.
Disclaimer: I've made LEDs blink with an Arduino and I think microcontrollers are cool, but I'm an embedded systems noob for sure :) I poked around the FAQ a bit and I'm kinda confused about this. Do you write bare-metal Pascal programs in this? I.e., do you write a Pascal program that uses Ultibo libraries to run without a separate operating system? How is the resulting program different from a unikernel? I think I'…
Yes, that's exactly how it works.
> How is the resulting program different from a unikernel?
I think that's essentially what Ultibo is.
> I think I'm mostly confused about why the IDE is bare-metal (why not write your Pascal programs in a normal environment and then run it bare metal on your RPi)D
You do run the IDE in a normal environment and then run it on your RPi. See below for a better description of how it works...
I heard the first version is close to VMS. Is it true? Is there any material on VMS? OpenVMS is open sourced but the version is too high.
The first lab: https://pdos.csail.mit.edu/6.1810/2023/labs/util.html
I do plan to work through the whole thing myself again at some point soon.
Why Unix v6? Why teach with a 50 years old design? I feel to teach the fundamentals of an operating system, i.e. scheduling, IPC, address space management, a microkernel design would be better.
I'm guessing many professors don't choose Xv6 for their operating systems class because it's a great design. Some probably pick it because it's good enough, simple and easier to teach in a single semester where students are also taking other classes. Are you saying the microkernel design is not only better but also easier to teach?
Basically a rather simple Makefile, gcc, qemu, xorriso...
I see lots of open source hobbyist OS projects require you to build your own GCC, which is not fun. Xv6 works with the standard gcc (provided by distro package manager). On macOS: just install homebrew-i386-elf-toolchain, and tweak some lines on the Makefile. Done. You are ready to build Xv6, which should take about a minute or less.
Why Unix v6? Why teach with a 50 years old design? I feel to teach the fundamentals of an operating system, i.e. scheduling, IPC, address space management, a microkernel design would be better.
I have ways wanted to understand the Windows NT kernel -- maybe the earlier versions as they are simpler. I heard the first version is close to VMS. Is it true? Is there any material on VMS? OpenVMS is open sourced but the version is too high.
Earlier quoted context omitted.
The Vonn Neumann architecture does not expose the same structural flaws monolithic kernels do—namely, their (of course tendency in modern computing to be) massive size and their failure scenarios in the event of a problem. Old is not always a problem, but monolithic kernels face the same problems they did in the 80s. It's not surprising Apple is moving away from kernel drivers and into userspace functionality.
apple started with mach, which was a microkernel, and linked basically all of the freebsd kernel into it, morphing it from a microkernel operating system into a monolithic operating system i agree that monolithic kernels are unpleasant and brittle, but unfortunately they don't actually seem to be obsolete
Additionally, Apple has a long term roadmap to fix that design decision, hence why they are killing one kernel subsystem at a time, moving them into userspace, with one year given for the developers to adopt each of them, after being made available as the new way.
Finally, it is kind of ironic that systems that have doubled down on monolithic kernels, are now used to run an endless pile of containers and Kubernetes clusters.