RetroBSD is a port of 2.11BSD Unix intended for embedded systems with fixed memory mapping. The current target is Microchip PIC32 microcontroller with 128 kbytes of RAM and 512 kbytes of Flash. PIC32 processor has MIPS M4K architecture, executable data memory and flexible RAM partitioning between user and kernel modes.
Isn’t this a rerun of the story I submitted back in 2014?
http://www.osnews.com/story/27901/RetroBSD_Run_old_BSD_Unix_on_a_mi…
This memory…
Yeah but any interest generated in RetroBSD and LiteBSD is good I think.
I wish nuttx were a bit easier to build on PIC32… with the chipkit toolchain as it is probably a good bit more powerful and compact than RetroBSD.
It popped up on Hacker News a couple of days ago. I’ve noticed that a lot of articles here follow an appearance on that site lately.
https://news.ycombinator.com/item?id=17318998
And Ars Technica!
And Slashdot!
Maybe there’s a conspiracy between these tech news websites to report on the same things at the same time!
RetroBSD has never appeared on Ars or Slashdot.
I’ve simply noticed that a lot of the more obscure articles here follow articles on the front page of HN from a few hours before, enough that it’s a definite pattern. Yes, other news sites pick up on the bigger tech articles, but outside of OSAlert one doesn’t casually hear about things like RetroBSD.
Why the hostility? I’m sorry if I offended you personally with an observation about where a lot of this site’s news stories are sourced.
Hostility? It’s called sarcasm. It’s poking fun at making an observation that is obvious.
I don’t understand people’s obsession with imagining the other person taking offense. Does it make them feel better?
You also ignored an important word from me: Lately. As in, I^aEURTMve been reading the same tech sites we^aEURTMve both discussed for many years (going on 20 years for me as far as Slashdot, Ars, and OSAlert (n~A(c)e BeNews)), and HN for about 9 years now, and it^aEURTMs only in the past several months I^aEURTMve noticed an obscure article hit HN^aEURTMs front page, and then here a few hours later, sometimes several days in a row. Articles that never make it to Ars, Slashdot, Vice, AnandTech, or any of the other ^aEURoebig^aEUR sites.
I^aEURTMm sure it^aEURTMs just a quirk of Thom reading HN, seeing something interesting that might be welcome on OSAlert, and posting it. I never said there was anything wrong with it, I wasn^aEURTMt calling anyone out, I was just voicing a realization.
I^aEURTMll be sure to run my future posts by you before daring to speak up; you never know when I might be too obvious again and ruin the whole thread. >.>
I think you’re overreacting to my initial sarcasm. I was just being sarcastic.
As was I. No harm no foul, mate.
Still works just nicely on the 11/73 and 11/83.
More memory though which is good for TCPIP stack and ethernet on the qe0.
I like that 2.11BSD still gets patches from time to time.
It’s nice we have these things, but I’m more interested in OSs for CPUs that don’t have hardware support.
The hoops they have to jump through to get things to work.
Honestly, popularly, we only have a couple of real examples: Very early editions of Windows, Early Mac OS, Pro DOS for the IIgx.
I’m not familiar enough with GEM and what underlies it on the Atari ST, that could be an interesting example.
I appreciate that without hardware support it’s easy to corrupt the kernel, etc. But it’s also the problems they have with dealing with the code loader (since you don’t have a VM that makes every process look the same).
I thought the mechanism done with Mac OS and Pro DOS (very similar internally) were clever.
But isn’t this story about the kind of historical OS that you mention. Because it is running on a modern microcontroller and getting the occasional patch, wouldn’t that make this the OS equivalent of a living fossil?
Eh, not really. Fundamentally it’s not really different from the modern OS’s. The lack of virtual memory has a dramatic affect on the design of the OS.
Not only does the VM system allow process protection, but it also offers address space normalization.
In CP/M, and early MS-DOS, code was simply “loaded” in to address 00:0100, and then executed. That works just fine until someone wants to try and run two different processes simultaneously. You can’t have two processes sharing the same address space. With virtual memory, that’s not longer a problem. Everyone can run at “00:0100”, and the memory manager handles the translations.
In early OS/9, code was required to be coded as Position Independent Code, allowing, making it easy to share two different processes. UCSD Pascal was implicitly location independent, so it leveraged that for it’s ability to load dynamic segments (as well as multi tasking).
The IIgs had a relocating loader, rather than just raw images for its code segments. On the Mac and Windows, you had to jump through a lot of hoops to properly manage memory.
So, the basics of an OS with a hardware MMU, you can take a lot for granted, and the base implementation don’t need to be particularly clever. But the more limited systems, running multiple processes on, say, a Z80, or even early 68000. It was a different world with a lot of variety.