Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police)

In BeOS what _everybody_ actually did was divide their app into essentially two parts. One half, often made of dozens or even hundreds of threads is just UI processing. It does very, very simple things, and all the actual work is handed off to the other part. The extraneous threads used make it looks like you've really done a great job dividing up the app, but actually they offer negligible advantage over having a single thread. Just BeOS baked in the inheritance (literally in C++) of the Thread class into the Window class, and this weird choice was spun as a marvellous new way to write apps.

All the actual work is done in the other half, often one remaining thread, it looks like everybody else's apps do on every platform, a big message loop and then blocking operations like disk accesses, network requests, it takes locks, it fires timers, very conventional. It processes one message from the UI layer at a time.

And on the surface this seems to work really well, very responsive. But just below the surface you realise that your app is stalled just the same as the equivalent app on Windows or any other OS, except that the UI is "responsive" in the sense that you can still click on buttons and there's no busy cursor. There's never a busy cursor, the OS doesn't have one. It _is_ in fact busy under the same circumstances of course, the buttons won't DO anything when you click them, and you won't get your result any sooner.

In the past few weeks a lot of people have been experiencing what this feels like inadvertently. Pokemon Go is an app you run on a phone AND of course it's a huge distributed system behind the scenes. The app is responsive, you can grab your map view and spin it around, press things, very responsive, nice. BUT, what happens when you press things needs the huge distributed system to figure stuff out. That (due to a mixture of bugs and system load) was not very responsive. So beneath the thin veneer of "responsive UI" is a slow, clunky system still. That's what the BeOS does. Why bother?

The "worst possible" stuff you mentioned isn't how anybody ended up doing anything in BeOS either by the way. It's all finger in the air estimates. 100ms here, 250ms there, round numbers all over the place. There was no calculation, not even on the back of an envelope.

Travis said it himself, writing operating systems is something he enjoys doing. Sometimes an employer actually pays him to do it, and in this case it's Google. Is it a _good idea_ to keep writing new ones? Not his department.

No - at least in my text books "hard real time" is needed if the failure to match a deadline endangers life or causes great physical/economical damage.

Let's try to not to redefine words - otherwise there is no sensible discussion if "real time" just means "very fast, consumes only very few resources, basically flawless". In computer science you have to accept trade-offs. A free lunch is a very rare thing.

But RTOS makes running multiple things at the same time slower and less responsive then if you are using something like Linux.

> It is responding to its user and the input to response loop should be under 20 ms.

Right. If you want things to be done ASAP you shouldn't be using RTOS. ASAP is not RT.

If the UI doesn't redraw every 20 ms do you want it to simply give it a blank image to the user? If that is what you want then using a RTOS makes sense.

If you want a redraw to go as fast as possible and try to keep it under 20ms, but if it can't then 25 ms is better then nothing... then you want a OS that is optimized for that type of performance and RTOS is not that.

> If Google wants to be smart about their new OS they might consider requiring applications to be more like BeOS and implement a dedicated user event thread which would get special handling.

BeOS did it wrong by forcing every application to have a 'rendering thread'.

Apple did it right with OS X.. which I mean they use composition in the display. Applications render into a buffer and that buffer is used as a texture in a rendered display. That way the UI you are interacting with is not tied to the rendering performance of each and every application you happen to have open and some part is visible.

You end up with a responsive display that is very efficient because applications now only have to render if something in their window changes. It looks nicer, too, because the UI is rendered as one big image rather then a bunch of little sections.

Composition gets a bad rap in Linux-land, however. Not because it is slow or it sucks, but because X is incapable of doing it efficiently. It's not up to the task.