Posts by fg_swe 1530 publicly visible posts • joined 20 Nov 2021
1.) Nobody forces you to use Rust.
2.) Cyber Security (more precisely: a lack of) is a very real problem. Memory safe languages are an important security measure. See presentation
3.) As stated in the presentation above "Other measures such as proper scanners, parsers and strict input validation are still required"
There exist valid reasons for using small parts of unsafe code in a larger memory safe system. For example, the Sappeur standard library will eventually call the POSIX API using the inline_cpp[[ ]] mechanism.
By doing so, the error-prone amount of unsafe code will still be a small percentage of total code and we can assume we will (statistically speaking) have very few memory bugs. inline_cpp[[ ]] should only be used by experienced C++ developers and it should be reviewed by another seasoned C++ engineer. Unit Tests should be created. Valgrind should be used with the unit tests.
So, it is not an all-or-nothing proposition, but rather an attempt to squeeze out the exploitable bugs related to memory safety.
1.) Sappeur and Rust will force the software engineer to think about thread-shared data at compile time. Go does nothing of the like.
2.) Go assures the integrity of the heap, just like Sappeur and Rust do. C++ does not.
3.) You can have nasty data races in Go at a low level. For example, you can create a global counter and attempt to update it from many threads. Result will be undefined. With Sappeur, you will get the accurate value, because the compiler forces you to create a "multithreaded" class* for the counter.
4.) Go will typically consume 2x the RAM of an equivalent C++, Sappeur or Rust program, assuming something now trivial which performs heap allocations in a loop.
*each method of such a calls is protected by mutexes
It must be noted that there are industries and application fields which operate under somewhat stricter regulations. A serous bug in an ABS brake system software will kill someone sooner or later. Same for bugs in railway, aerospace and medical systems. These industries use extensive documentation and testing to weed out these bugs. Standardized in DO178, ISO26262, and other norms.
An emerging thing is cybernetic threats, which can have very severe consequences (losing a war, for example) for the nation, bank, company or person who uses a certain system. These users will in some cases have a very dim view of commercial software such as Windows or Linux.
But I agree that every developer is at some point under commercial pressure to deliver "something working". If the compiler can help the developer to find as many bugs as possible(mostly due to the type system), this will be a powerful aid.
Why should these numbers multiply ?
Assume a C program has a user space runtime of 5000ms, and an system call runtime of 1000ms. The equivalent system based on Sappeur would have 20% overhead: 6000ms in user space and 1200ms in the kernel.
That is a total runtime of 6000ms vs 7200ms. A total overhead of 20%.
We always assume competent Java and competent Rust developers. Identical algorithms. Using standard libraries of each environment. Then the Java mark+sweep GC does generate a 2x RAM overhead, for very systematic reasons.
I have done this myself for an application that processes CSV files.
The RAM overhead could be pushed down by aggressive GC settings, but that meant Java runtime would no longer be competitive with Sappeur.
The energy consumption differential is very real. If you were an engineer, it would be of interest to you.
Intel never cared about energy consumption, so they missed out the mobile market. Mobile devices are very much constrained by battery.
So in fact it is an engineering-economic thing. Very much like cyber security, which is also a very real problem.
Imagine all Java developers switching to Rust. We can assume memory consumption would go down by 50%, based on experimental results so far.
That would definitely be a reduction in energy consumed for manufacturing RAM and for operating RAM.
All the application-level performance data we have so far suggests kernels and database servers could be written in a memory safe language with only moderate runtime penalties(in the order of 20% or less).
Even before Unix became popular, there were successful lines of Algol mainframes, which used at least partial memory safety inside the kernel (ICL, Unisys, Moscow). According to Sir Tony Hoare, this worked rather efficiently.
In the world of high security computing (government+mil) they already use memory safe languages.
Did it ever occur to you that the rules and structure of a language limits its runtime efficiency ?
For example, Java needs 2x the RAM of an equivalent Sappeur program. No compiler can change that fact, because this follows from the mark+sweep GC approach.
Compilers are not the same as unicorn horses.
Even expert software engineers will create severe bugs then and now. The evidence in the CVE database is very clear. The cost and security threats from these bugs can no longer be ignored. Memory Safe languages are a very important safety/security approach along with firewalls, MMUs, sandboxing, strict input parsers and so on.
The latest novel C exploit reports are about medical devices running VxWorks. They had an exploitable bug in the TCP stack, which means the device could be commandeered by simply sending "bad" IP packets to the device.
Non-trivial multi-threaded C or C++ programs need plenty of Mutexes to protect shared memory. If you share a variable by accident without mutex protection, chances are you get heap cancer. Best of luck finding the root cause of this cancer.
The Rust and Sappeur compilers will force you to have proper Mutex protection.
For systemic reasons, Java cannot use memory as efficient as C++, Rust or Sappeur. For example, you cannot allocate programmer-defined objects on the stack. Stack allocation is the most efficient allocation approach you can think of, because it is essentially just incrementing the stack pointer and calling the constructor. The memory most likely is already in the cache, which is also critical.
Your idea of "allocating once and forever in Java" can be done for hard-realtime systems (I guess it was done for the Barracuda drone), but it totally defeats the idea of using the Java Standard Library and many popular programming patterns.
There are many use cases where energy consumption matters. Think of aerospace applications that have a tight space and cooling budget. Think of mini satellites with small solar panels. IoT sensors. In memory databases.
Just because energy is still cheap and your accounting code can be done in Python means little.
If we use your terms for one second, the engineers building the Linux, Windows and HPUX kernels were "f-wits".
In the next second we should realize that humans are not robots and we DO make mistakes then and now. Small mistakes should not mean an attacker can take over the process or the entire system(kernel exploit).
See this http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf
Well, it could very well be that the age of insane energy consumption comes to an end. Apparently there are fuel shortages here and there, plus exploding cost for methane. Methane is what drives the electricity grid on cloudy days with little wind.
As soon as energy is not longer near-free, economics might force us to use more efficient approaches.
Could you be a little less cynical ?
Even though these benchmark games have their flaws, the general observations are correct:
1.) Compiled Languages are more energy-efficient
2.) mark+sweep GC creates at least 2x more RAM demand than refcounted objects. (it is actually easy to understand why - you cannot run GC all the time, so you must accumulate garbage)
3.) C and C++ are indeed highly efficient in runtime and RAM consumption
4.) Rust and similar languages such as Sappeur aim to provide similar time+space efficiencies as C and C++. They come close.
5.) Strong typing means efficiency. Dynamic typing comes at very serious cost.
(I do think the TypeScript benchmark is somehow using an inefficient algorithm)
Rust and Sappeur do provide wholly new capabilities to safely execute multithreaded code without risking nasty memory bugs. C, C++ and most other languages were never designed to robustly handle multithreaded heap access.
Sappeur uses a simple approach, details of which fit a page
http://sappeur.ddnss.de/manual.pdf
(Section 9.2)
AppArmor can only help you defend other sections of you system, but not the exploited process itself. For example, imagine a multi threaded web server written in C. An attacker will use a memory access bug to inject his malware. Then the attacker has access to all user sessions processed via this Linux process. He might even gain access to cryptographic keys, if you do not use an HSM.
See this presentation for details: http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf
As with the bike and the telephone, many countries claim to be first.
Zuse's great idea was to use binary numbers instead of decimals.
According to
https://de.wikipedia.org/wiki/Zuse_Z4
it already had a conditional jump instruction.
Zuse also had floating point numbers, which is impressive.
As the article is about "commercial computers", it could be argued that Zuse's work was initially military and then scientific. Not "commercial".
1.) By default, Rust and Sappeur assure memory safety. They do not prevent other types of errors, such as SQL injection due to insufficient input parameter checking.
2.) By default, it is very easy to create a memory safety bug in C and in C++. As it apparently happened here.
2.2) It is practically impossible to ensure memory safety for multithreaded C++ programs, as approaches such as RAII and index checked arrays do not protect against accidental MT-sharing of unprotected variables.
1.) Indeed Sappeur is similar to TypeScript. But with enough effort, you could create a compiler that directly compiles Sappeur source into assembly code. For many reasons (both economic and engineering), this would not be wise at this point. For example, I could not create code for the Russian Elbrus CPU, as MCST keeps the instruction set secret (because Elbrus CPUs are part of sensitive government/military systems).
1.2) Some Eiffel compilers compile into C. That also works nicely.
1.3) Sappeur is definitely a language of its own. In grammar, syntax and semantics. It is *related* to C++, though.
1.4) ANY environment can be targeted from the Sappeur 3.4 compiler. From Atmel 16 bit Micrcontroller to 64 bit Mainframe processors. All you need is a halfway decent C++ compiler/code generator.
2.) The Sappeur 3.4 compiler is indeed closed source and requires a paid license of 300 Euro/developer for commercial use. It is free for non commercial use or evaluation.
2.2) SUN gave away Java for free, the entire world's corporations use it. They also gave away other great software such as StarOffice. Now they are bankrupt. Free by itself is not sustainable, check Mr Torvalds (see my other posts here) for details.
Now, why does Linus Torvalds not need a formal moderator ?
What was the benefit of "moderating" Mr Galileo ?
Most people will be shamed into "normality" if they say truly horrible things.
CoCs definitely smack of censorship. Powerful actors want to control speech and thoughts, as they did then. We should submit ?
Sappeur programs can be almost as tiny as efficient C programs are. They can also start in a few milliseconds, do their work and be done in another few milliseconds. Like the C based Unix userland tools. Unlike most Java VMs.
That is because a Sappeur program is in fact a C++ program with little overhead for refcounting, stack overflow and array index checks. Multithreaded programs have some Mutex checking effort. All the system libraries are thin wrappers around the POSIX or Windows APIs.
The resulting memory safe C++ code is compiled using g++ or any other moderately modern C++ compiler such as xlCr (or whatever the name is on AIX), SUN CC, VC++, Elbrus tcc,... All tested with success, not just theory.
https://en.wikipedia.org/wiki/Linux_Foundation#Corporate_members
Linus earns about 700k/year from these corporations, which is O.K. with me. He is a businessman-engineer who operates in a kind of cooperative setup. Like the Raiffeisen-thing in Germany or coop banks in other countries.
Just don't assume he has no overlords. Linus is an employee of all those megacorps who have pooled their efforts in the OS sector.
http://techrights.org/2020/08/16/the-linux-racket/
Java is memory safe, even (kind-of) with multithreading. C++ is not.
C++ is very efficient and semi-realtime capable even with using heap memory.
Java is not semi-realtime-capable if you allocate dynamic memory during usual processing steps.
C++ has RAII, Java has not. RAII is the most efficient way of acquiring and releasing expensive resources such as database connections, sockets and file handles.
C++ has synchronous destructors, Java has not.
Sappeur aims to merge the good things of both.
Sappeur is arguably superior to Java in ensuring multithreading synchronization of shared data access.
Java is superior in its ability to collect cycles of garbage objects, over (traditional) C++ and Sappeur. The latter two can only reclaim memory if cycles are broken by explicit code.
Mr Torvalds certainly must answer to the corporations (such as Google, HP, IBM, Amazon) who are heavily invested in Linux.
These corporations would probably fork Linux in a whim, if they had unfixable trouble with him.
Also, FreeBSD, OpenBSD and quite a few more wait in the wings.
