> C / C++ are not secure for real-world use cases.
Is the kernel Linux not a real-world use case?
Is the kernel Linux not a real-world use case?
Now show us the list of replacement kernels written in Rust, Ada, Lisp, or whatever that are:
1) free software (or open source as a second best)
2) as widely distributed and as portable as Linux
3) supports as much hardware as Linux
4) supports the wide range of applications that Linux does
5) free of memory safety related CVE's as well
There is always a series of tradeoffs - Linux has adopted a classic but unsafe programming language as its basis which has in turn allowed it to cover an enormous amount of ground in a (relatively) short time frame, support massive amounts of new employment and accelerate the development of the web.
It is not clear that an alternative design or implementation in another (safer) language would have moved the world as far forward as Linux has in the same time frame, or whether its even possible, as nobody has demonstrated this.
Apparently they are still stuck at the starting line, discussing endlessly how perfect their system will be when they finally choose the right language to implement it in.
As a result, anyone working on Redox, Fuschia, or whatever popular contender now have a massive library of driver source code to refer to when working in their languages of choice. This is not a resource that the Linux and 386BSD communities had when starting out.
Rust isn't as standardized or at critical mass yet, as C was when Linux was launched. The language still lacks comparative mindshare, no matter how popular it is here on HN. That's why there aren't enough developers.
I never said "Linux is bad and insecure" either, and when making blanket assertions like that, it's helpful to have a point of reference.
So I ask again, which free software, widely deployed, battle tested and highly secure operating system are you comparing Linux to? That was the very obvious point of my comment, which you have apparently missed (ignored?) twice now.
I think this is a good question, and I was wondering if someone would ask that. To be more specific, I think points (1), (3) and (4) are of primary importance, so I would address those specifically:
1) commercial, proprietary and expensive systems were very fragmented and incompatible with each other, especially UNIX, and VMS, Windows etc. Nobody seems to want to go back to that. I think this is the biggest hurdle for any new commercial system to overcome, otherwise Linux (or other, better free systems) will continue to dominate until a better replacement comes along. Look what happened to Solaris. Better than Linux in some respects, worse in some, but it failed to retain its market share. Windows is not hugely used as a server platform either like it was in the early 2000's outside the infrastructure required to support Active Directory, Exchange and Sharepoint.
3) obviously popular server hardware needs to be supported by the system, eg. HP, Cisco UCS, DELL etc. This should be evident by the amount of effort that vendors like Redhat put into patching their kernel to ensure compatibility with hardware from major server vendors. If the proposed alternatives don't support these hardware platforms then they are going to find it hard to gain traction.
4) you aren't going to migrate people away en-masse from a C-based system like Linux without being able to support the major languages and ecosystems that rely on C and/or C++ for their runtimes. People will still need to run their Tomcat applications, Ruby on Rails, Python, NodeJS etc. all of which currently depend on C or C++ to some extent. I think at least Redox is addressing this somewhat with their "relibc" implementation, which would allow "legacy" C codebases to be hosted there in the future, but let's be pragmatic and admit that it's probably a long way off.
As somebody who builds/manages emergency services communications platform based on Linux that supports over 70,000 front line emergency services workers, who in turn provide criticial services to over 6 million people, those are the reasons why I see no currently viable platform worth migrating to in the short to medium term _for our particular application_. In addition to self-hosted environments like ours, Linux currently also has a very particular grip within cloud hosted environments as well (which aren't particularly relevant to me at this point in time).
In order for non-C based platforms to take off, you either need to support the C runtimes, or be prepared to wait a long time as other languages that don't depend on a C runtime become popular and the ecosystem grows enough.
There were no free software memory-safe languages suitable for implementing an operating system in during the 90s when a lot of the initial Linux development happened.
> In order for non-C based platforms to take off, you either need to support the C runtimes, or be prepared to wait a long time as other languages that don't depend on a C runtime become popular and the ecosystem grows enough.
C runtimes are everywhere at least partly because C runtimes are easy to implement. Most of the Lisp machines in the 80s had full support for C. And those were non-memory protected systems! Running a C program in a separate a process would let you use any existing C runtime; the C runtime doesn't care what language the system-calls are implemented in.
Do you honestly believe that there is a widely-deployed battle-tested free software operating system implemented in a memory safe language?
I assumed the answer was "no" from your original comment, but all of your replies can only be interpreted as if the answer is "yes"
It is already starting with MIT/BSD/Apache OSes for IoT.
Even if I indulge your fantasy for a moment - Linux (amongst other systems) has provided myself and many others with a solid career for the better part of the last 25 years, daily security patches from vendors and all, and I don't see any solid evidence of that changing before I retire.
Further I suggest most Linux people would be able to adapt if the world were to move on to an improved competitor with enough momentum to be adopted en masse - which hasn't happened.