* Posts by fg_swe

1500 publicly visible posts • joined 20 Nov 2021

IBM staff grumble redeployment orders are stealth layoffs

fg_swe Silver badge

Re: Stop Being An Idealist

Having said that, there are plenty of opportunities and strong companies out there. Apple is doing great both technology-wise and economically. Unlike IBM, they understand that mechanical design, GUI appearance and usability matters. Then there are hundreds of small companies who need seasoned IT experts.

Pump out dozens of applications and while you wait for the response, learn something new. A new language, HTML, a new framework, a new type of database. Learn about the V Model, there will be enormous work in auto, aerospace, rail and medical - as soon as they actually do the work according to the book. Learn effective presentation, if you haven't yet. Write a blog about something technologically relevant...

fg_swe Silver badge

Stop Being An Idealist

1.) Forget the BS they told you about "lifelong job security". No commercial company can do that. Not even Google. It's a br4inf4ck to stop you from looking for an external career move.

2.) "creative destruction" is a very real thing, like it or not. Microsoft, Google, and Amazon ate the business of HP, IBM, DEC, Unisys, Fujitsu. These "old" IT companies have a calcified brain and cannot quickly adapt to new challenges. Even worse, they cannot use their own great ideas, because they would threaten existing business. For example, HP's BIRNBAUM was thinking about Cloud Computing back in the 90s. Amazon made it happen in the 2000s and HP is now on crutches.

2.2) Because the business of the old companies evaporates, their employees can no longer be paid at a proper rate. Macro-economically speaking, they must transfer from the old companies to the new ones.

3.) Never stay too long at one company, so that you know how to sell yourself and get interviews. Not applying for 20 years will deteriorate your self-selling skills.

Rust projects open to denial of service thanks to Hyper mistakes

fg_swe Silver badge

Resource Limit Management != Memory Safety

The management of RAM allocation, database connection numbers, file handles, number of threads etc must be managed by the application programmer. There is no sensible way an automatic runtime mechanism can do this for the app programmer. Except, of course, stopping the thread or program upon resource exhaustion.

So - the application programmer must think about all the resources he allocates in his program. For example, an http server must reject too many parallel requests(Code 429 Resource Exhausted). An application using database handles must limit the number of database connections by some sort of pooling and semaphores. No automatic mechanism on the runtime/language level can replace programmer reasoning here(except maybe some sort of database pool which blocks until a connection becomes free).

Memory Safety is not the paradise of programming, it "just" eliminates an ugly kind of cancer.

Software Engineering is a highly complex craft+science with lots of aspects. If it were simple, we would not earn good money on it.

fg_swe Silver badge

Out Of Memory in C, C++, Java, Rust

In all the above languages, you will get a deterministic crash if heap allocation fails. You either get a NULL pointer from malloc() or new or some sort of OutOfMemoryException. Accessing a NULL pointer typically creates (some sort of) SIGSEV and stops the program. OutOfMemoryException typcially stops the thread.

This is exactly what you want. A deterministic, debuggable crash from a programming error/cybernetic attack. Much better than Silent Subversion from e.g. a buffer overflow.

How else could an out of memory condition be handled ?

(this applies to Windows, Linux, BSD, HPUX, Solaris, AIX, but maybe not to embedded systems)

fg_swe Silver badge

Thanks

Your reasoning is the proper one. A deterministic crash is much better than Silent Subversion. See http://sappeur.ddnss.de/discussion.html section D9

fg_swe Silver badge

Rust Not Different Here From C, C++ or Java

See http://sappeur.ddnss.de/discussion.html, section D9

fg_swe Silver badge

FALSE

Please look at http://sappeur.ddnss.de/discussion.html , section D9 for why you are wrong.

C: Everyone's favourite programming language isn't a programming language

fg_swe Silver badge

Generic Programming Using the m4 Processor

http://gauss.ddnss.de/GenericProgrammingWithM4.html

fg_swe Silver badge

FALSE

The macro processor of C is just one aspect of the language. There exists a modicum of type safety from a very basic type system in the C language. It just is not as comprehensive as it should be. Too many "undefined behaviour" cases.

Note that in C++ you can use a powerful macro processor to replace the convoluted STL system. And its crazy error messages.

E.g. use m4 to generate/instantiate container classes on the harddrive. If you have a bug, then you will get concise error messages inside the generated code. Much better to understand for mankind. If you are a masochist, you can even use cfront macro processor to perform this.

One could even perform generic programming in C using this approach (e.g. a typesafe generic_sort() instead of the void* abomination).

fg_swe Silver badge

NOT

According to your assertion NOBODY should generate C code, as we are all "fallible". The best software engineers write a bug then and now. The most advanced static checker tools, unit testing, module testing, HIL testing and valgrind runs cannot find all of the bugs. We have seen them in the Linux Kernel, in VxWorks, in Windows kernel and user mode, in loads of application level programs developed by seasoned experts.

The first time Unix userland tools were run under valgrind checking were a revelation. Hundreds of bugs, which existed for decades in millions of actively used systems.

Here is a list of the memory safety issues of C http://sappeur.ddnss.de/SappeurCompared.html

I would argue that you are mostly correct, the amount of C code men generate should be very limited. There are NO perfect software engineers. There are only Code Generators (such as the Sappeur compiler) which are very close to memory safety perfection.

University students recruit AI to write essays for them. Now what?

fg_swe Silver badge

80s Guys Software In Action

https://www.youtube.com/watch?v=NJeAjnADHD0

Extremely reliable, no loss of airframe due to software !

fg_swe Silver badge

Wrong

Writing is first and foremost about CORRECT CONTENT, not about lyrical bullshit.

ChatGPT is good on lyrics and faulty on content. See my other post.

fg_swe Silver badge

Re: AI is the new pocket calculator

We have created extremely reliable software systems you can entrust your life. ABS, ESP, Airbus flight control, software based railway switchyards, aerodynamically unstable aircraft which become stable due to software.

fg_swe Silver badge

Re: Big Time Bullshit

They either updated the model, or the exact wording of the queries is super important. I would NOW grade

"tell me the difference between the Osprey V22 and the Dornier 31" - 4. One faulty sentence "The Do 31, on the other hand, used jet engines for VTOL capabilities and did not have the ability to fly like a fixed-wing aircraft."

"write the c++ code for Enigma" - 5. Text is kind of OK, but the code is completely wrong.

#include <iostream>

#include <string>

const int NUM_WHEELS = 3; // Number of wheels in the Enigma machine

const int ALPHABET_SIZE = 26; // Size of the alphabet

// The mapping of each letter of the alphabet to another letter

// For example, mapping[0] is the mapping for 'A', mapping[1] is the mapping for 'B', etc.

int mapping[ALPHABET_SIZE];

// The current positions of each wheel

int wheel_positions[NUM_WHEELS];

// Initialize the mapping and wheel positions

void initialize() {

// Set up the mapping of each letter to another letter

// In this example, we just use a simple rotation of the alphabet by 3 letters

for (int i = 0; i < ALPHABET_SIZE; i++) {

mapping[i] = (i + 3) % ALPHABET_SIZE;

}

// Set the initial positions of the wheels

for (int i = 0; i < NUM_WHEELS; i++) {

wheel_positions[i] = 0;

}

}

// Encrypt a single character using the Enigma machine

char encrypt(char c) {

// Rotate the wheels

for (int i = NUM_WHEELS - 1; i >= 0; i--) {

wheel_positions[i] = (wheel_positions[i] + 1) % ALPHABET_SIZE;

if (wheel_positions[i] > 0) {

break; // Only rotate the next wheel if the current one has "carried over"

}

}

// Get the index of the character in the alphabet (e.g. 0 for 'A', 1 for 'B', etc.)

int index = c - 'A';

// Use the mapping and the wheel positions to encrypt the character

int encrypted_index = (index + mapping[index] + wheel_positions[0]) % ALPHABET_SIZE;

// Convert the encrypted index back to a character and return it

return 'A' + encrypted_index;

}

// Decrypt a single character using the Enigma machine

char decrypt(char c) {

// Get the index of the character in the alphabet (e.g. 0 for 'A', 1 for 'B', etc.)

int index = c - 'A';

// Reverse the encryption process to decrypt the character

int decrypted_index = (index - mapping[index] - wheel_positions[0] + ALPHABET_SIZE) % ALPHABET_SIZE;

// Convert the decrypted index back to a character and return it

return 'A' + decrypted_index;

}

int main() {

initialize();

std::string message = "HELLO WORLD";

std::cout << "Original message: "

fg_swe Silver badge

Big Time Bullshit

I have to concede I was impressed for the first few times of using ChatGPT. But then I grew demanding and tested

A) "tell me the difference between the Osprey V22 and the Dornier 31". The result was catastrophically wrong, as it declared the Do 31 being a HTOL aircraft. That would be a 6 in German grading.

B) "write the c++ code for Enigma". The result looked promising at first, until I discovered that the most important ideas were completely lacking. Grade 5.

Given the low complexity of AI systems as compared to "100 billion neurons connected to 10000 other neurons each", I should have known it from the beginning. The human brain is still one of the most powerful information processing systems we know* of. Silicon is on the level of worms at the moment.

In other words, smart teachers will use chatGPT to set up dangerous traps for lazy students.

*Elephant brains can compete on numbers, but I maybe not on structure.

PS: Now the response to the Do31-V22 query seems to be correct. Did they update their model ? Or did I use different wording then ?

Google's Dart language soon won't take null for an answer

fg_swe Silver badge

Re: Functional Safety

There are cases where a NULL simply cannot be handled. Certain pointers MUST be non NULL, or the algorithm will fail. But it MUST be active at a very high availability rate (one instance in 1 million years or similar). Because it is a flight control system and cannot simply be turned off or restarted. If the compiler can guarantee that for the software, the organization can put more effort on the hardware side (which has physics- and chemistry-related failure rates).

Some high performance aircraft are unstable By Design and you cannot "use direct law" in case the software "has issues".

fg_swe Silver badge

Functional Safety

In the IT sphere, you are more or less right. A NULL pointer causes a deterministic, debuggable stop of program. Service will be stopped for an hour or so. Customer uses cash to buy a cup of coffee and comes again later to run the service again.

In other spheres such as auto, rail, aerospace and medical, you cannot just "stop the process and debug it". Imagine getting a NULL pointer inside an ABS brake algorithm, while the driver hits the brake pedal. How would you handle this as a software engineer ? Restart the process and maybe get another NULL pointer a few milliseconds later ? No, you must prove there will never be a NULL. One proper way to do this is to have the type system+compiler assuring this.

fg_swe Silver badge

Economics

I do not believe in communism. And, if you cannot spend €300 on your tools, you should review your economic setup.

fg_swe Silver badge

Re: Go Multithreading Issues

Do you have a Napoleon Complex ?

fg_swe Silver badge

Go Multithreading Issues

http://sappeur.ddnss.de/discussion.html / D7

Java and Go don't represent multithreading in the type system, which enables Race Condition Faults. They are still "memory safe", though, as they ensure integrity of memory. And Locality of Errors, unlike C and C++.

fg_swe Silver badge

Null Pointers Not A Big Issue

All popular operating systems will stop a program that tries to access a NULL pointer. Completely deterministic, debuggable and secure behavior (an attacker can't subvert a stopped program.

Much more dangerous are random values inside an invalid pointer(because the pointer itself is on the stack), as they cannot be detected (efficiently in time and space) and open the castle to all sorts of attack opportunities. Same is true for a pointer which points to freed/deleted memory.

So, a memory safe language should ensure (smart) pointers are either valid or null. Just like Java, Go, Swift, Sappeur already do.

Memory Safety needs several other properties, such as

+ Array Index Check

+ Stack Overflow Check

+ Multithreading Safety of heap, (arc or GC) pointers

+ Strict type conversion rules (e.g. pointer to car can never be converted to pointer to aircraft)

C++ zooms past Java in programming popularity contest

fg_swe Silver badge

Compatibility ?

My understanding is that this libc will support the large corpus of existing C programs, until Rust replacements have been developed.

fg_swe Silver badge

FALSE

Rust has already been used to create the Redox operating system. Surely it will contain some unsafe section, but in general it is a great improvement on the C based kernels.

Likewise, the Algol Mainframes of ICL, Unisys and Moscow had some Memory Safety features inside the kernel.

Instead of mysterious behaviour, memory safe languages will provoke a Debuggable Crash.

fg_swe Silver badge

Java RAM Consumption

2x of the equivalent ARC program in Rust or Sappeur.

TSMC founder says 'globalization is almost dead' as Asian foundry giant expands in US

fg_swe Silver badge

Errata

Block 50 F16s can be fitted with the gear necessary for the Wild Weasel Role. Due to Automation and precision sensors, no EWO is required.

So the USAF does still operate a powerful emitter suppression capability.

fg_swe Silver badge

Re: Oh IT Man

Here is a great video on Wild Weasel https://www.youtube.com/watch?v=fHpsaasL5gM

It truly was an epic fight between soviet and american electronics engineers. A fight between Russian missile soldiers and American airmen/flying sailors. Not just the SAMs, also the radar controlled Flak and the ground-radar guided Mig19s, Mig21s.

America lost that one, because they were complacent.

After that, won over Iraq and Lybia almost with ease. They did not have the latest Russian electronics and not the Russian electronic soldiers.

fg_swe Silver badge

Re: Oh IT Man

The modern Wild Weasel is the ECR Tornado and the EF18 GROWLER.

Apparently the USAF and RAF currently dont do this role, but this can change in a blink of an eye.

fg_swe Silver badge

Oh IT Man

You think you know all when you know nothing.

In Viet Nam, russian made and operated SAMs were masterpieces of control and radio electronics then.

They blew something lin the order of 50% of US fighters and bombers out of the sky.

Read up on Wild Weasel if you want to know why they did not shoot 100% of US planes.

Google says Android runs better when covered in Rust

fg_swe Silver badge

Re: I'm sorry that you don't understand pointers.

Issue C is still as bad in C++ as in C.

fg_swe Silver badge

Automotive MISRA Experience

I was part of auto software engineering projects up to ASIL-D. I say this:

1.) MISRA C subset is definitely useful and makes sense for other domains, including datacenter, phone, PC.

2.) MISRA C will do little to prevent integer under/overflows or index errors. Static checkers (PC Lint, PolySpace) do help here. They are now mandated in most projects. Static checkers have limited power, though. Sometimes runtime checks are required to be memory safe. C cannot do that. MISRA or not. SPARK Ada, Rust, Sappeur, do dynamic index checks.

3.) Using C in safety-critical domains (auto, rail, aerospace, medical) is a second-rate decision. SPARK Ada is still superior in many ways. Engineers who can write C can be made to write Ada, but C can never be made as safe as Ada, even with static checkers tacked on.

fg_swe Silver badge

Re: Singularity OS

All of the WNT kernel had serious memory error exploits, including the TruType font subsystem they dragged into the kernel. Visit a "bad" website with poisoned fonts, have a kernel exploit !

fg_swe Silver badge

Re: Unisys MCP Algol Heap Memory

Unisys implemented lots of software in Algol, including compilers. I fail to see how they could have done that without heap memory.

And I can imagine that they built heap memory management into the OS. Essentially you declare a pointer, dereference it and MCP will allocate the object/array "on the fly". MCP experts please correct me if I am wrong.

They can then run mark+sweep in the MCP system, just like the JVM does.

https://www.informit.com/articles/article.aspx?p=1671636&seqNum=3

Unisys is not bound to limit themselves to the official Algol standard.

fg_swe Silver badge

Automotive and Aerospace Software Safety

I hasten to add that modern software engineering processes (ASPICE, V-Modell etc) have several lines of defense against software engineering errors. Auto drivers do not have to worry too much, neither do AIRBUS passengers or pilots.

First, there is thorough documentation, secondly thorough design steps. Thirdly, upwards the V, there is a cascade of Unit, Software and HIL Test batteries. Even if we did not use static checkers, these comprehensive test efforts would most likely find dangerous bugs.

AIRBUS likewise has a an almost perfect record in both JÄGER90 and commercial airplanes since A310 and later. Not a single loss of aircraft due to flight control software and hardware !

They have even more measures in place, including the use of SPARK Ada. Much better than C.

fg_swe Silver badge

Re: Android runs better when covered in Rust

As long as the p........ improve practical computer science, we should applaud them ;-)

fg_swe Silver badge

Yeah, Rambling

I currently write code for automotive software, some of which is ASIL-B. I worked on electric/electronic power steerings, which are up to ASIL-D. All in C plus static checkers such as PC Lint and PolySpace. Both tools typically find plenty of issues(index errors, integer under/overflows,...) in the code of experienced engineers. Maybe your car contains this code and your life depends on it.

Apple Swift was inspired by my language

http://sappeur.ddnss.de

Even though Apple made serious shortcuts on efficient Reference Counting (all Swift ARC is MT safe, which is both inefficient and enabling one type of error).

If you want to see some of my source code, please feel free to look here

http://gauss.ddnss.de

fg_swe Silver badge

Re: But

A) In many cases (e.g. for loops), the index checking of a Rust, Java or Sappeur program could be turned into an O(1) operation.

B) I was referring to: obtaining a pointer into the middle of an array, then incrementing or decrementing w/o any sanity check of the runtime system or the compiler.

B2) I have seen plenty of that cr4p, because some people did not know STL and abused an MFC integer array to store pointers. Oh yeah, and void* pointers and lots of other obscenities.

C) Multicore CPUs are now standard, even in laptops of the $1000 range. In the datacenter, we have multithreading since 1998 or so. Even the world of auto now uses multicore MCUs for demanding things like video processing.

fg_swe Silver badge

Unisys MCP Algol Heap Memory

From

https://en.wikipedia.org/wiki/Burroughs_large_systems_descriptors

"Also, low-level memory allocation system calls such as the malloc class of calls of C and Unix are not needed – arrays are automatically allocated as used. This saves the programmer the great burden of filling programs with the error-prone activity of memory management, which is crucial in mainframe applications."

They do not need "new" or "malloc", as the CPU+OS will handle dynamic memory allocation and freeing !

In other words, the whole idea of explicit memory allocation is not the only viable one.

fg_swe Silver badge

Yeah

When you don't write totally memory-error free C++ code, you do Perfect Braking, correct ?

Also when two wheels are on ice and the other two on concrete, you operate each wheel's brake independently using four finger switches ?

fg_swe Silver badge

Re: Static C++ Checkers

There are very few languages which model multithreading in the type system. Sappeur is one of the first to do so.

fg_swe Silver badge

Re: Real World

The quick+dirty Huawei stuff is especially dangerous, because it is coded in C and C++.

I was responding to your claim that telephone software would be somehow more robust. Maybe that was a feature of the past.

fg_swe Silver badge

From the Trenches

https://groups.google.com/g/comp.sys.unisys/c/5apvpaA2fZs

fg_swe Silver badge

Burroughs Algol Mainframes

https://www.digm.com/UNITE/2019/2019-Origins-Burroughs-Algol.pdf

Definitely a much better concept than C+Unix and the IBM/360 world of untyped memory. But alas, cheaper often wins over better. At least initially.

fg_swe Silver badge

Really ?

Please have a look at the Algol mainframes. They definitely have very interesting memory safety features.

https://www.theregister.com/2020/05/15/algol_60_at_60/

https://en.wikipedia.org/wiki/Burroughs_large_systems_descriptors

fg_swe Silver badge

Real World

In the real world, engineering managers are in most cases not the best+brightest engineers. Rather, they know how to "herd cats". Social skills.

If "all other engineering managers" use C, they will do that too. Regardless of the consequences.

In other words, improvements of software security and safety will come from engineers+scientists, not managers.

Modern day telephone software apparently is quick+dirty stuff, which is why the phone network now has one-day-crashes per three years or so. A long time ago, they aimed for "5 minutes in 30 years". The days of ISDN.

https://www.softwaretestingnews.co.uk/21345-2-gchq-director-huaweis-engineering-very-shoddy/

fg_swe Silver badge

But

Both have very similar memory safety issues:

A) unchecked array access

B) funny raw pointer stuff

B2) super funny pointer casting (e.g. int to pointer)

C) lots of problems from a lack of proper multithreading safety model in the type system

fg_swe Silver badge

Algol "heap" keyword

Look it up. It is comparable to Java's new. Implementations would use a mark+sweep collector to reclaim the memory after use.

fg_swe Silver badge

Dornier 31

I never said it was cheap. But it still has the best performance of all planes in its class. And also the best safety record. Only slavery is cheap.

fg_swe Silver badge

FALSE

You bring up the "good software engineers don't produce memory errors" argument once more. In reality, even the most seasoned engineers then and now have Covid 3333(a.k.a. "flu"), a fight with their wife, trouble with a teenage kid or the like. Bang, memory error.

It has happened in ALL major systems from HP/UX kernel to VxWorks TCP/IP stack. In between, WNT, Linux kernel, Unix user land, Solaris make, g++, YOU NAME IT.