[1]: https://www.youtube.com/playlist?list=PLbtzT1TYeoMhTPzyTZboW...
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.
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.
So no, NT is nothing at all like VMS from a featureset or likeness perspective, nothing at all from an implementation perspective (VMS had beautiful clean C standard library and compiler suite), but very much was the race to the bottom by the mini crowd to play games in the micro world.
check dave plumbers interview with cutler on youtube for more color.
I took him as an inspiration. His “What I really wanted to do was work on computers, not apply them to problems.” rings so true with me, and he as a natural leader also makes me look up to him.
To actually learn how to use the thing I ended up diving deep into textfiles.com archives for references to VMS and got the hang of the basics enough to start learning via the online (built in) documentation.
I would also point you towards usenet archives if you want to learn more about the development history of VMS, what what i have been able to piece together it was really rock solid and loved and quite a shame that "open"VMS is mostly just a legacy compatibility licensing agreement and the technology is in a bit of a glacial deep freeze.
The fact that every file on the entire OS had version control - by default - before 1990... that blows me away and I feel like there's so many beautiful secrets to learn from this codebase. I always imagined it would be written in some abstract arcane language, when I learned it was in C i got a bit scared knowing what microsoft calls C has very little resemblance to how C is typically used on unix likes, and with the knowledge that many VAX admins dumped VMS for BSD I was quite afraid I may be out of my element.
I was surprised to find the C library is essentially just posix, I felt pretty much completely at home on VMS compared to any version of windows I have had to write C for. Pleasant experience, shame what happened to it, wish there was more about its story told in an authoritative context like a book.
If you stumble across anything nifty please feel free to share I may come back and read this read again someday.
Cheers
> I heard the first version is close to VMS.
No.
> Is it true?
No.
> Is there any material on VMS?
Tons. It came with metres of docs. It is still on sale. You can get a freebie hobbyist VM image.
> OpenVMS is open sourced
No, it isn't.
> but the version is too high.
Not true.
Always, always check your assumptions before asking a question. If you want to ask "because (a) can I (b)" then check A is true before asking. ALWAYS.
As someone who missed this part of history, I would love to have learned about it in college.
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.
The main difference between Microkernels and Monolithic is how address space get to be shared between userland and kernel. I don't see how microkernel design would be "better". Why teach a design that isn't widely used?
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.
System Design is about trade offs. You conveniently say "expose the same structural flaws monolithic kernels do" and not mention anything about microkernels. System arch discussions are not about who "wins", but about trade offs.
> but monolithic kernels face the same problems they did in the 80s
Putting your lack of balance aside, what problems are you talking about specifically? Are you aware of how many new instructions have been added since the 80s that were designed specifically to address the shortcomings of monolithic kernels? Microkernels, even when resources were much scarcer back in the 1980s, still did not become popular.
Both designs have their use cases. Micro and mono kernels have pros and cons but for learning purposes it makes more sense to teach about monolothic kernels since all popular operating systems follow this design.
i agree that monolithic kernels are unpleasant and brittle, but unfortunately they don't actually seem to be obsolete
That's largely a political decision because of Apple's totalitarianism.
Linux evolved numerous features over the years responding to server room challenges. Some of them look monolithic, others are decomposable, in any case linux became the default dev target platform for everything.
Minix might be nice, but linux has won, and it was NEVER about os architecture.
In theory, I like the concept of functional core, imperative shell - the imperative shell provides various functions as a kind of APIs, and the functional core handles all the business logic that involves the connections between the APIs. (It's also sometimes called hexagonal architecture.)
However, it is questionable whether it actually reduces complexity; I daresay it doesn't. Every interaction of different shell APIs (or even every interaction that serves a certain purpose) needs a controller in the core that makes decisions and mediates this interaction.
So when you split it up, you end up with more bureaucracy (something needs to call these APIs in between all the services) which brings additional overhead, but it's not clear whether the system as a whole has actually become easier to understand. There might also be some benefit in terms of testability, but it's also unclear if it is all that helpful because most of the bugs will then move to the functional core making wrong decisions.
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
https://git.minix3.org/index.cgi seems online?
: ~; git clone git://git.minix3.org/minix.git
Cloning into 'minix'...
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.Also mostly because as it happens in most hobby projects, people keep wanting to replicate GNU due to the existing software, thus keeping the UNIX cycle alive.
In the meanwhile, Project Oberon from the late Niklaus Wirth (http://www.projectoberon.net/) is a good example of a pedagogical operating system (and programming language) that isn’t Unix. Project Oberon was heavily influenced by the Cedar and Mesa projects at Xerox PARC.
https://en.wikipedia.org/wiki/A_Commentary_on_the_UNIX_Opera...
> a microkernel design would be better.
why re-hash a 30 year old debate? [0]
0: https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
It’s a bare metal Free Pascal environment for Raspberry Pi.
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'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