[pjmlp]

> The more I learned about these things plus issues with other basic functions like wait() ot strcpy() or in general the lack of protections around C, the more I entertained the idea of looking for alternative operating systems.

Dig into the worlds of Burroughs B5500 (now Unisys ClearPath), IBM OS/360 (now IBM z), IBM OS/400 (now IBM i), and the now gone Mesa/Cedar, Oberon, Active Oberon, SPIN OS, Topaz OS, Mac OS/Lisa, Singularity, Midori, Inferno, ...

[stdcli]

and yet you are still alive and not starving to death. But the banter I see on here is android video game developers complaining that a move away from android will be the end of them.

Google is not stupid, they are not going to deprecate android overnight and replace it with Fuschia, this operating system has been in the works open source, you can see the commits on github for atleast two years I think more, and there will clearly be many iterations of its development to come with increasing adoption each time as people make money on the platform, just like with Android which took years before it reached the threshold of 50% use compared to iphones and no iphone video games developers that I know of starved to death trying to adapt to this change. The drama on this thread about api changes are significant for sure and I understand Google redacts API's or suddenly starts charging for them in a way that makes small companies close up shop overnight (like google maps for example) but it is not a justification to pretend that objective limitations around Moore's Law and the need for competition in computer hardware is forcing companies who have experience in both spaces to reconsider kernel development at a more fundamental scale.

[pjmlp]

Android is being ported to run on top of Fuchsia.

[stdcli]

which is why I'm confused about all of the top ranking comments complaining that android will change their API for this. Will this require a change for android app developers if this is the case? Regardless, this seems like a more fundamental layer of improvement.

[pjmlp]

They are mostly by folks that never did Android development and think they are free to use Linux code as is on the NDK.

Still, it will be a scenario similar to ChromeOS. How many people are buying ChromeOS devices to run Android apps?

[bogomipz]

Wow that's an interesting list. Might you be able to add some specific points of interest on some of these OS's to start with? Cheers.

[pjmlp]

Sure,

Burroughs B5500, first OS written in an high level systems language (ESPOL, later NEWP) in 1961, 8 years before C came into existence. Already used compiler instrics instead of Assembly, and the concept of unsafe code blocks.

IBM OS/360, famously introduced the concept of containers, alongside IBM OS/400, also has language environments, think common VM for multiple languages.

IBM OS/400, originally written in a mix of Assembly and PL/S, uses the concept of managed runtime with a kernel JIT called at installation time, and uses a database as filesystem.

Mesa/Cedar, system language developed at Xerox PARC, using the same IDE like experience similar to their Smalltalk and Interlisp-D workstations. Uses reference counting with a cycle collector.

Oberon and its descendants, Niklaus Wirth and his team approach to systems programming at ETHZ, after his 2nd sabaticall year at Xerox PARC.

Mac OS/Lisa, these first versions of Apple OSes were written in Object Pascal, designed in collaboration with Niklaus Wirth, whose extensions were later adopted by Borland for Turbo Pascal 5.5.

Singularity/Midori, the research OSes designed at MSR, largely based on .NET technologies.

Inferno, the actual end of Plan 9, using a managed language for userspace, Limbo.

SPIN OS/Topaz OS - Graphical workstation OSes for distributed computing developed in Modula-3

[bogomipz]

Thanks this is great! I'm looking forward to digging into the specifics of some these. Cheers.