Posts by fg_swe 1502 publicly visible posts • joined 20 Nov 2021
More solid engineering approach is:
1.) Do NOT include a macro processor into the language
2.) Use a separate macro processor such as m4 to perform specialization of generic code.
3.) Expand the macros to disk. This makes crystal-clear what the macros do and debuggers can show what is REALLY going on.
What you describe is the standard approach in any safety critical industry such as Automotive, Aerospace, Medical and Rail. Dynamic memory is impossible to make hard realtime or even "available at all times".
BUT - even with statically allocated memory you can and WILL have index errors, using C or C++. You can also have bad pointers, which were meant to be pointing to the static memory sections.
With Rust or Sappeur you allocate whatever memory you need in a startup phase and after that you can be sure there will be no memory errors any more.
C++ still has essentially the same Memory Bug Potential as C had.
http://sappeur.di-fg.de/WhyCandCppCannotBeMemorySafe.html
In real-world, large scale C++ based projects they usually run test cases with valgrind. A very slow way of detecting memory bugs in test code with test input. Still does not defend against other, well-crafted hostile program input.
A well designed program written in a memory safe language can indeed perform safe multithreading. It just requires the language to MODEL multithreading in the type system. As opposed to C and C++, which simply bolted on multi-threading to a single threaded memory model.
E.g.http://sappeur.di-fg.de/manual.pdf Section 9.2
Of course there must be a small part of the code which is unsafe. Your embedded periphery meddling (A/D converter, PWM, clock setup etc) cannot be covered by Memory Safety. But that does not mean the 99% of OTHER code should not be memory safe. Locking down 99% of code is definitely a very serious gain of safety and security. For example, you will discover dangerous memory errors during extensive Unit, Software and HIL testing.
Just because you THINK it does not have memory bugs, does not mean this is true. When "well tested" Unix Userland tools were first run with valgrind, tons of bugs were discovered. More bugs might be in them, just not discovered by the input data constellation.
Also see
http://sappeur.di-fg.de/Sappeur_Cyber_Security.pdf
1.) Rust(and other proper memory safe languages) DOES protect against the 70% of CVE exploits which are memory insafety bugs.
http://sappeur.di-fg.de/Sappeur_Cyber_Security.pdf
2.) An MMU can never be as fine-grained a protection as a proper memory safe language such as Rust, Sappeur or Java. Rather, MMUs operate on large chunks of memory, typically 4kByte or more.
3.) Memory safety should be enforced on the Type System level by the compiler. Very powerful things can be done there.
Entire operating systems have been written in Algol, C#, Java and Rust. They do need a certain amount of unsafe code for certain operations such as setting up a new process image. But all the things you mention can be done in a memory safe language. There is ZERO reason to parse data incoming from the network in C, except maybe "execution speed".
https://en.wikipedia.org/wiki/Burroughs_Large_Systems
https://en.wikipedia.org/wiki/ICL_2900_Series
https://en.wikipedia.org/wiki/Singularity_%28operating_system%29
https://en.wikipedia.org/wiki/JavaOS
For example, there exist lots of Java based web servers and the seem to be doing quite well. No need to use C for that.
There exists the possibility of a nicely written C program without any insane aspects. This program still contains exploitable memory bugs. A clean translation to a memory safe language will then defend the program against exploits that use memory errors. So your sweeping assertions are not right.
Depending on the C code style, it could be that it can be nicely translated into Rust. Rust then adds the runtime checking code that sometimes is required to ensure Memory Safety.
In other cases, the C code will use crazy pointer arithmetics and the like and manual translation into a sane and secure style will be required.
I hasten to add that the Russkies are even greater air cowboys. They die early and often.
"Lets ignore the stoopid electronic ground approach warning. We are roooskies!"
Voice of the Sukhoi test pilot before he killed himself and quite a few more passengers in a SuperJet demo flight in Indonesia.
Their supa dupa F22 fighter had the following takeoff S.O.P:
1.) Accelerate to 120knots
2.) Rotate 10 degrees and get airborne
3.) Ignore Temperature
4.) Ignore Air Pressure
That "worked" until one "seasoned" pilot decided to also retract landing gear asap and made a belly landing.
They were told that their supermighty engines could essentially push them into the air in ground effect.
One belly landing later they discovered 60% of F22 pilots did this malpractice.
Then they figured out that rotation speed must be calculated for each airfield and weather individually. As is standard practice for all other aircraft.
Boeing, Lockheed Martin and the rest of the porkbarrel industry employed more engineers and scientists than Musk. They achieved very little compared to investor-entrepreneur-engineer Musk.
He made lots of great things happen, for example he rejuvenated the U.S. sat launcher industry, to great dismay of AIRBUS of Germany and France. Meanwhile Boeing bought Russian rocket engines and had no real intention to improve them. Porkbarrelers to the core.
Of course Marxists hate real entrepreneurs.
Elon Musk has the Right Stuff. He cut down cost of spaceflight, made it highly reliable and made economic rocket reuse possible.
And with the other hand he launched thousands of gamechanger sats.
He is brave enough to hold the woke dollarmen to the fire, much needed !
If Mr Ortberg cant fix Boeing, merge it with SpaceX !
+Move HQ back to the main factory
+Management by Wandering Around instead of bullshitters meetings
+Training Programs for all technical employees. Both theoretical and applied.
+Strict Drug Testing. Help those who are addicts off the stuff. Those who cant do that, let them go.
+Get rid of DEI Marxism and their social science vodoo priests
Can the new guy do this ?
1.) I guess that at least 50% of large businesses (more than 1 billion revenue) run some type of Java Software. From Eclipse to SAP to Oracle apps.
2.) SUN could easily have transformed herself into a Software Business IF they had demanded, from 2003 onwards, moderate license fees for the Java Compiler, the VM, the JRE and so on. Think of 30 Euros per core per year.
3.) SUN would be a sustainable business and ideally a good steward of Java.
It's a shame they went under after making such a nice contribution to applied computer science.
A very poor/starving country because she is run by corrupt ideologoues. They cannot even be as pragmatic as the Chicoms and let SOME entrepreneurship happen.
Cuba was once a major exporter of coffee, now they are an IMPORTER. Same thing with sugar.
Now the Commie-Mafia tells Cubans to eat the banana PEEL, too, as it apparently contains some more calories.
Cuba can easily ship everywhere outside the US and do very nice business. No, they are ruled by a tiny elite of euro-style salloon communists, who all think they should live like a CORRUPT king: no work and live in luxury.
They dumped Batista and instead got Andropov. With Andropov came the inflexible ideology, laziness and inefficiency.
They designed, developed and maintained an efficient and memory-safe language and never found a way to monetize it.
They bought OpenOffice and gave it away for free, even for commercial use.
They bough MySQL and also gave it away for free.
Eventually they were a software company with a dying hardware business providing the declining revenue and soon negative profits.
Lunacy.
Oracle is under the full control of the U.S. and other governments. Unlike the Mafia they do not take law into their own hands. They do not threaten your or your family's life.
If you do not like to do business with Oracle, just remove all of their products from your computers and they won't bother you.
Then go to IBM for DB/2 and you will prolly have an unpleasant surprise. Harder to install (you need an IBM engineer for that) and most likely not cheaper.
If you do not like the Linux/Java combo, give AS/400+RPG a try. Definitely more expensive and surely locked in as much as locking can go.
This massive corporation now had a run of more than 40 years, which went very well. From 2 guys to 170 000 well-paid employees. Their products are used in lots of large corporations. Some of these installations can be replaced by Postgresql and Python. By a massive Rust rewrite.
But guess what ? Larry and his lieutenants will decrease prices IF+WHEN customers really start dropping Oracle. So far it seems customers are overall happy with the arrangement. The rantings of engineers and technicians on the internet matter very little. What matters is that Oracle wins in the comparison ORA|DB2|MSSQL|PSQL or JAVA|RUST|VWST|DELPHI|C#, done by engineering and business managers. So far they seem to do quite well.
You can always quit Oracle and go to IBM and deal with their sharks. I predict it will not be cheaper or easier.
Or go with Microsoft and discover their pecularities.
If your application is not too big, use PostgreSQL.
Nobody forces you into a relationship with Oracle, but many corporations have one, because they need a high performance database engine with commercial support.
Be a real man and rewrite all Java apps in Rust. Don't complain when they do not have the same support quality.
Each and every investment of a company is intended to support her on the long run. It would have been only fair and square to demand a "reasonable" license fee for commercial Java use. Then SUN could have transformed herself from a hardware into a software company.
You are saying the hardware business was no longer good enough to subsidize a complex software system. Subsidies are in the most cases a bad thing, which will distort markets and businesses.
Sun prolly spend several billion dollars on Java over the years. What they got in "return" was much less than that. They got "goodwill", but their employees needed hard dollars to pay the rent, the health insurance, the food, the car, the family, the vacation.
In the end it is a simple cashflow issue. If you have a massive staff of expensive engineers, you also need a source of revenue to pay for your staff.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
