Re: Clarkson's Farm
You go first and we have at least one problem less.
25 posts • joined 6 Jul 2021
Well, it seems most IT clients have figured they can go directly to Tata, EPAM, IBA, Wipro and Infosys. They dont need to splice IBM or HP in between them and the low cost engineers.
Or they go to Google, Amazon, 1&1, Hetzner and MSFT for cloudy stuff.
And if something is mission critical, there are specialist development consultancies around, with much better engineers than you can ever get from the "computer" companies.
IBM can by now only attract expensive sales reps and cheap engineers.
There are some companies around who value "old age", highly skilled engineers. I know of one search engine behemoth who does.
IBM shoots itself in both of their feet by laying off their highly experienced talent.
It seems they want to go to die and a fully young staff will facilitate corporate death.
I always compile with
g++ -Wall ...
And I will fix any warning before I proceed to perform developer tests.
But this does not mean g++ will tell me all the memory safety issues that rustc would tell me in equivalent code. It simply is impossible for a C++ compiler to detect the same types of bugs as a Rust compiler can find. This follows from the language specifications.
Maybe by 2025 the C++ folks have added the same memory safety mechanisms as Rust in their language spec, then you might have a point then.
There have been quite a few non-C based operating systems, some of which are arguably safer than Unixoids/Windows, because they use bounds checking inside the kernel.
Here is a small list of them:
Finally, a Rust-based OS, which already works in a prototypical fashion:
In my experience with memory safe languages, bounds checks cost about 10% more CPU Runtime. Modern CPUs seem to perform the bounds check and the access "virtually" in parallel (speculative execution).
It is time to admit humans are NOT perfect "code generators". If we can mitigate the effects of our imperfect work, that is very good in my opinion.
So if Google wants to do something against the obvious security risks of the Linux kernel, you come here shouting and changing the subject to ChromeOS.
Maybe you just learn something new and better than what you already know ?
Or maybe you listen to Sir Tony Hoare and what he has to say about memory safety.
C++ has exactly the same problems as C, if used naively. For example, std::vector::operator is not bounds checked. If you dont use RAII, heap errors are almost preprogrammed.
Most importantly, C++ has no multithread-safe memory concept whatsoever. Best of luck debugging multithreaded memory errors.
You make it look as if the only problems of C are related to strings. This is just a subset of all memory safety errors which occur in practice. All C arrays potentially suffer from index errors. All C heap memory suffers from use after free, double frees and unitialized pointers. Have a look at the CVE database to get real world data.
The people who wrote the HPUX ping of death bug were most likely seasoned developers, not rookies.
Same goes for the many bugs in Windows, in Adobe flash and PDF, in TrueType, Unix utilities and hundreds of thousands of other places. The first time Unix userland utils were run using valgrind, there were loads of memory errors detected.
Your cute "small" language C has created an enormous amount of exploitable bugs. The Linux guys seem to attempt a gradual conversion to Rust.
It definitely makes sense given the history of bugs in the Linux (and many other C-programmed) kernels.
Will it work out ? We will see.
There are some highly interesting kernels such as seL4 around and they also use Rust for their higher level/application parts.
Using C and C++ is like not using an ABS brake, "because I know how to properly brake".
Biting the hand that feeds IT © 1998–2021