Multiple? A Main Battle Tank such as the German Leopard 2 weighs 62,300 kg (137, 347 lb). Even a puny WW2 Sherman medium tank weighed in the neighborhood of 70,000 lb.
The term "hybrid" is not a particularly useful concept, since the whole idea of a microkernel is to achieve stability and extensibility by placing only a minimal kernel in kernel space, and have everything else (drivers, file system, etc.) live in userland.
XNU is built on Mach (initially 2.x back when it was NeXTStep/OpenStep, later 3.0 for OS X), but everything runs in a single address space. Mach ports are retained throughout the OS as a communication mechanism, including userland, but all the core stuff is in the kernel, and Apple has transitioned many Mach port IPC responsibilites to more traditional syscalls to work around the fact that ports are comparatively slow. For example, all POSIX operations such as read and write are BSD syscalls that correspond to entrypoints in the kernel; they're not IPC messages.
That‘s true, but it‘s also important to note that most of the BSD subsystem is actually a shim over Mach. So once your BSD syscall has made it to the kernel, chances are you‘ll get a mach IPC call from the BSD shim.
The term "hybrid kernel" means it elegantly combines the disadvantage of a Mach microkernel (slow IPC based interfaces) with the disadvantage of a monolithic kernel (no fault tolerance due to single address space).
It does not have HDMI. Displays would typically be done with SPI breakout boards like from Sparkfun and Adafruit. You could also do a display via USB to VGA/HDMI.
I'd guess pin-count and driver availability. SPI has pretty well-established kernel drivers with usermode access. Using the parallel busses is either going to involve driving a ton of GPIOs or trying to map some kind of parallel peripheral into driving each screen.
I guess that's a good point; I've been looking into some small TFTs with hand-solderable MCUs that fall short of application processors like this, but still run at ~50-200MHz. Not quite the same ballpark.
Still, on those, it's still only 13 pins for an 8-bit parallel bus (which I think can still do 16-bit color,) rd/wr/dat-cmd/chip_en/reset, and the chip_en/reset pins are probably optional. And while they do tend to have a few hardware SPI peripherals, some of them also have flexible memory controllers which can rapidly pipeline data over a customizable interface designed for use with a variety of RAM/storage/etc banks. But I think it will probably work since TFT interfaces are essentially writing to a framebuffer. And BGA packages usually have like twice as many 'pins,' but to be fair 'real computers' do also require a lot more I/O than microcontrollers.
Yeah, when I said that I was thinking of the WEIM in the iMX6 chips, which I'm pretty sure could be persuaded to talk to a little TFT. The tricky part, once you've got the electrical bits figured out, is getting the memory peripheral (WEIM or FSMC or whatever) talking to the screen, and then putting together whatever glue of a driver to get from userland to the hardware. And then hoping that it generalizes to another screen, or putting in whatever effort is necessary to port it to another screen.
It's a pain in the butt compared to just opening /dev/spi0 or whatever and writing a few bytes to it. Don't get me wrong, I'd love to have a great library of cheap OLED screens that could talk to an RPI/BBB in a high refresh rate way, but for the majority of my own projects I'll just take whatever cheap SPI screen I can find and use that.
The beaglebone black or green would be a more practical portable computer. It has usb ports, hmdi out and supports debian and ubuntu. This looks like a shrunk down version of the black but missing the convenience of hdmi out and usb ports
Physical? You could jam a lot more storage in a 3.5" drive than you're ever going to see, but it would not be economically practical, and the MTBF and reliability would be very poor.
You completely missed the drawn of HDDs with the ST506 5MB, and the big breakthrough when the much faster 10MB ST512 replaced it? Those were the exciting days.
I think in most of the USA, "bot", "lot", "cot", "not", and "father" all share the same vowel, while "bought", "lost", "caught", "nought", and "fought" all share a different vowel.
The following wikipedia article discusses the two phonemes and how they are merged in many dialects of english, and contains audio samples of the same guy pronouncing both words.
Reminds me of the ludicrous idea of medical savings accounts. Hardly anyone below the top 0.1% could ever hope to "save" enough money and put it away to cover a medical or legal disaster or a really bad accident involving personal injury or destruction of extremely valuable property.
It just isn't a realistic proposition. Insurance with all its flaws exists for good reason.
Sharing (immutable) data between threads is fine, you just don't want to share (mutable) state or else you run the risk of threads stomping on each other. The ideal scenario is map/reduce: you take some large chunk of data, divide it up into smaller chunks, spin up a thread to process each smaller chunk and produce a result. Once the threads have all completed and the results are no longer changing, the main thread can pick them up and combine them to a single result.
It's possible to do that with fork-and-exec, but without a shared address space, marshalling costs make it expensive.
