Posts by fg_swe 1329 publicly visible posts • joined 20 Nov 2021
"high value media" means it is financed and corrupted by oligarchs. Soros, Gates and the like. They peddle their half baked medical products and their marxist ideas by these channels.
Facts such as CDC VAERS are getting suppressed, because these financiers demand that.
So you claim he is responsible for "evil" information/ideas being published on the WWW?
Like Guttenberg being the cause of the 30 years war ?
It would be so much better if the old information monopolies/empires(newspapers, TV, Radio, book publishers) kept their power ?
If there were only the catholic church ?
Let me propose this: on the WWW you can show your best or your worst side. You can parrot nonsense. You can be tricked by hostile actors. But you can also act in good faith to help others. You can find very good advice in a heap of rubbish, just like there are good books amomg a mountain of others.
Connect your RPI to the DSL router, get a DynDNS (e.g ddnss.de) name, install a web server and publish your ideas.
You can also store your files via ssh/scp.
Run a personal email server, encrypted with DeltaChat.
The local Linux User Group are your best friends in this.
All while the sheeple will focus on golden cages such as FB, X, youtube and so on.
There were plenty of officers, great engineers, scientists, technicians in Germany between 1933 and 1945. They invented many things that we use to the current day, including the computer using binary signals and fully programmability. Most of them had no connection to the Nazi ideology.
https://de.wikipedia.org/wiki/Konrad_Zuse
https://de.wikipedia.org/wiki/Erich_Fellgiebel
In addition to modern computers, Fellgiebel also made large-scale carrier frequency telephony happen.
If Kyndryl salesfolks cannot sell Kyndryl services, it has little to nothing to do with the skills of Kyndryl employees. Rather, leaders+sales folks are incompetent and/or the economy is not going well.
Polish your CV and venture out of the calcified corporation !
IT IS NOT YOUR FAULT. Never let them drag you down in their excusive talk !
Of course IBM/Kyndryl/$CalcifiedCorp want to make you feel bad, so that you can be terminated as easy as possible. They want you to think you are at fault. Basic business bullshitting. Never let that close to you !
I can remember Joel Birnbaum (then VP of R+D) writing about the future "utility computing", as soon as the cheap fiber based networks would enable fast+cheap access to servers in very remote data centers. HP was then a leader in CPUs, multiprocessor servers of several flavors but also some of the most advanced optical fiber engineering devices such as OTDRs, tunable laser sources etc. Birnbaum essentiall predicted the coming of what we now call Cloud Computing already in 1995 or so.
Guess what ? HP failed to execute on Mr Birnbaum's observations, and the upstart Amazon made the killing cloud business happen. Cloud ate lots of HP, IBM, Unisys, Fujitsu business and they resisted the model for a very long time, despite "consulting" their customers about the virtues of "change management".
So the moral of the story is - do not stick to these calcified behemoths. They are run by aging beancounters without any useful business and technology fantasy (unlike Amazon in this case).
Almost the same story can be told about Smart Phones. HP labs(corporate Research )also knew they were coming in 1995 already, but the MBA beancounters fired all the engineers who could make them happen for HP in the early 2000s.
Too many folks have a false sense of loyalty to IBM and its offsprings. Their business models are low-value, which means they are easy to outsource to the Third World.
High-value business models entail consulting with the customer, writing requirements documents, designing, testing systems from that. And then continue that circle with enhancements...
The idea that this is no longer needed because of "cloud" is nonsense, too. Low level sysadmin work might be redundant now, but extremely advanced sysadmin work has been created inside AWS, Azure etc. IBM, HP too sleepy to get into the cloud business just displays how calcified their leaders are.
Why spend time with losers ?
I once developed embedded software for a nice MCU with 4K Ram and 64K Flash. There was "plenty" of space left in the end. I created C++ Objects that consume 1 byte/octet.
So - you can indeed use a high level language and still create very small executables with a small Ram consumption.
The MCU was an AT90CAN64. Very powerful device, actually.
If MSFT had actual competence, they would essentially copy the Android Sandbox system over to Windows. Each application can only access a certain part of the mass storage and can only read+write certain types of file extensions. Why does Excel need to access *.cpp files ?
Why is there no sandboxing and crypto signing of Excel VBA Macros ?
Why is there no scheme for Administrators to tailor such Sandboxing policies to user company needs ?
They have the power of forcing developers into a secure sandboxing scheme, but they chose to do nothing.
Then make it "the maximum number of people agency can collect on is 1% of population". That will make them prioritise who is actually a baddy and who is not. Whenever they add a new target, they must wipe an entire "old" target of their choosing. They can use Least Recently Investigated as a quick algorithm.
Well, the EU is a bunch of weakling-pacifists who will run to U.S.G. whenever a REAL threat(such as Vladimir or the Neo-Caliph) crops up. They can regulate to death(e.g. the USB connector regulation), but they are almost unable to develop an industry of our own.
India - highly corrupt and still kinda third world.
China - all depending on a single man ?
Brasil - bunch of lefties with bad friends.
So in the end U.S.G. must take the lead in this subject.
Engineering Managers, Engineering VPs must be held legally responsible for sub-standard development techniques. Up to and including jail time for things like hard-coded credentials and obvious violations of regulations. Corporations must be made financially liable for violations of regulations.
Of course, now the question is "what are proper software/system regulations ?". A lot of damage can be done by stupid regulation, as always with laws+regulations. Doing nothing is not an option either, as U.S.G. has now found out.
Also, there must be a "ramp up" phase, from the current Wild West approach to Proper Regulation.
As a first step, force corporations to use PC Lint for the C code and fix or justify any PC Lint complaints. On the long run, make them prove memory safety of internet-facing code(first layer of SW) OR use Rust/Java/C#.
Yes, we need a good conversation about this. Civilized, enlightened, rational.
I have seen absolutely shitty code from a major database software vendor and it was right in the "front door".
You could bring down said database system with elite hacker tools such as telnet+random typing.
This company was also said to be founded with capital from U.S.G. !
Corporations must be forced to have much better standards, much better processes. The Wild West Phase of software development must be ended.
Proper Regulation and Laws must be written and enacted to achieve this.
NSLs cannot force a vendor to implant a backdoor. It can force a vendor to provide the data he already has collected.
But yeah, there must be an enlightened discussion about Lawful Intercept and about backdoors.
About Data Collections. In my opinion it is a Stasi-like technique to collect on proven harmless and unpolitical people. Security agencies must delete collected records if the target proves to be fully harmless and non political, non military.
Corporations who provide essential services OR have more than 10% market share should be required by law to:
+ document all known weaknesses such as out-of-date/out-of-patch software and hardware, report to government
+ document all known weak scanners, parsers in use, report to government
+ lock down these insecure systems into enclaves with minimal external connections
+ similar sane measures to mitigate the effects of outdated and/or weak systems
Top notch corporations already do this at moderate cost and with great success. Now force the sloppier ones to do the same !
Except that there are non-Chinese companies with very much similar problems. There should he criminal investigations and FINES for leaving hard coded access credentials inside routers and other IT gear. And yes, major vendors that essentially run the internet traffic !
Also, there is the nagging suspicion these backdoors had been created at behest of "security" agencies.
Good to hear Mrs Easterly now wants to clean this up. Does she have the backing of her "former" employers ?
There could be regulation that the software vendor has to create an Exploit Award Pool (EAP) of (say) 1% of revenue. Whoever can present a working exploit would be awared e.g. 1/30th of the yearly EAP. Whatever has not been consumed of the EAP would go back to vendor at end of year.
Of course details must be hashed out. E.g. employees of the vendor would only qualify for reward, if they did not work on the code related to the exploit.
It looks like Mrs Easterly knows what about what she says
https://en.wikipedia.org/wiki/Jen_Easterly
BUT - how do we make companies actually use state of the art techniques such as
+ proper, strict input scanners
+ proper, input parsers with a well-defined, strict grammar
+ memory safety in scanner+parser and other external facing code ? (Memory safe STL would already be a gread improvement in C++)
+ mathematical proof of memory safety if C is used. See seL4
+ extensive fuzz testing. Documented fuzzing concept.
There should be regulations along the lines of
A) "Must comply until 2026, if software is to be used inside U.S.G."
B) "Non compliant banking/insurance/mission critical software is taxed at double VAT"
As a software engineer myself I recognize that we need proper and intelligent regulation. Just going on with the Wild West of the last 50 years does not cut it, though.
We need a conversation about useful measures, which are then written in law and regulation.
IF you use inheritance, then a proper understanding of destructors and virtual functions is of course necessary.
BUT - only use inheritance if you REALLY need it.
Even without inheritance, there are great C++ features such as "simple" destructors, that clean up(e.g. release memory, release file handles, close DB connections, RAII, ...) after the use of an object.
Unlike Java's finalize() , these destructors are synchronous, which is what you want in most cases.
As always in engineering: only use approaches you fully understand, if safety and security are concerns. Don't be a poser and use things just because they have become popular. Rather, learn new things, fully understand them and then apply only if useful for the problem at hand.
Of course you can corrupt any great idea. But that does not invalidate the great idea, in this case the V-Model. There are companies and organizations who have used it with great success. Train signal systems, ABS brakes, flight control, electric steering and many more.
And surely I have seen more than one cr4ptastic LastenHeft in my career. Writing a good requirements document is one of the most demanding engineering tasks. Bad management can mess it up by late time changing, by ambiguous language, by contradictions and so on. Good leaders and senior engineers will fight to avoid this and to polish imperfect requirements documents. Weak leaders will bend over and accept crazy changes and other bad stuff.
Of course proper documentation+testing is a very serious effort. Something which is often omitted in non safety critical software.
But we know at least in theory, how to do things properly. No more quick+dirty, informally tested cr4apware. Requirements properly documented in a req. mgmt system (DOORS, Jama, ...) as opposed to Email chains. Honest, large scale testing from unit to system as opposed to faux testing.
This is clearly the way forward, even if it will not be fully or not correctly used in many projects of the near future.
What you describe is a "popular" way of gaming the V-Model. Only junior or rotten engineers do that. And box-ticking "leaders" who are either midgets or corrupt folks.
Have seen that, I must admit.
Proper Unit Testing must always be traced to Unit Requirements(which in turn come from the top left side of the V Model) and it must check expected output (defined by requirements). Branch and MCDC coverage rates should merely be an indicator whether the team has forgotten a test case.
Given identical software engineer competence, memory safety will neuter 70% of bugs(or at least detect them early and stop program execution).
Another few percent you can get from Ada-style Number Domains, which will catch over- and underflows of numeric variables.
Just never forget to execute the V-Model properly, because only a proper Test Battery will generate the requried testing input to your program to trigger the numeric faults.
Writing and maintaining well-defined System Requirements ("LastenHeft") is a tough challenge for most engineers. Requires multi-year experience in the trenches of systems engineering, proper domain knowledge(physics, chemistry, finance, insurance,...) and the ability to think rigorously.
In the end it boils down to hiring highly experienced and self-confident engineers. People who can see through the bullshit of the MBA types (see Boeing MCAS) and who are not confused by the Regulatory Paper Mountains of ASPICE, DO-178 and so on.
MCAS was a true clusterfuck, a rookie mistake. That happens when engineers cannot cut through the BS. I assume they(FAA, Boeing, SW Contractor) worshipped the DO-178 church, but never had a mental model of the Complete Signal Chain(sensor to control surface) in their brains.
A properly executed V-Model would have simulated a Sensor Fault on system level(aka HIL testing) and immediately seen the horizontal stabilizer run-off. Simulator Tests should have revealed the same. But all of that means zero to an MBA type and his box-checking.
The simplistic world of moneyman tyranny: rookie mistake killing upwards of 250 passengers.
Both from a safety and a security point of view, memory safety will detect software faults which would go undetected for a long time with C, C++ and assembly.
That is true for both development and for operational phase of software execution.
What you want are well-defined crashes/stop of execution instead of Silent Corruption and Mysterious Behaviour. Also, you do not want Silent Subversion by a cybernetic attacker and you will greatly prefer a well defined program stop as opposed to attacker's code injection.
It is very naive to assume your program will see all possible inputs during validation phase. There is no time and no money to achieve this in most settings. Also, "equivalence classes" of input are very hard to successfully define, as they require knowledge of program internals, which defeats the idea of independant test case creation.
I forgot: no loss of airframe due to core software engineering faults. There was a loss of an A400M, due to a software parameter installation fault by the manufacturing line, though. Four airmen killed in the first factory flight.
https://en.wikipedia.org/wiki/2015_Seville_Airbus_A400M_crash
Of course you can write faulty programs in any language. BUT, if you have proper processes(e.g. V-Model), proper algorithms and data structures in place - then chances are you will have much less hard-to-find defects with a memory safe language.
Cynicism should not be your driving force.
There exists high quality software you can entrust your life. E.g. AIRBUS flight control software in various types from A310 to Jäger90. Afaik they use Ada and of course use a proper V-Model development process. They know what they do.
Similar things could be said about GNAT, yet it is used to compile control systems that have the life of airmen in its hands.
They have drastic quality control measures in place to make sure GNAT/gcc is doing what it is supposed to do.
MCAS was a System Design Bug of Rookie Nature and would have happened with ANY language.
The well-specified "undefined behaviour" of C and C++ is a much bigger problem than less-than-perfect specification of new languages. That's my experience. Even the best software engineers create bugs then and now and in many cases it would be great to have a safety net catching these bugs. There is no such man as the Perfect Software Engineer.
I have seen that in teams I was part of and I see it in the CVE database. Even the most prestigious systems from the most prestigious companies had horrible bugs. Before we had the V-Model, the most experienced aerospace companies wasted hardware on "small" software problems(e.g. Ariance V first flight, a $500 000 000 "small" software problem). So - ever human activity has faults. The question is how to best mitigate this.
All serious, multi-man, modern-style C++ projects use valgrind or purify to look for memory bugs. That indicates Memory Bugs are still a thing.
From my experience, memory safety helps even the most experienced engineers. Because even they have bad days, a sick child+woken night, a deadline, an overly aggressive project plan etc.
That's Vodoo for first world people, eh ?
I can tell you what really matters: honesty in engineering. If your best engineers confirm that the Test Battery(of the V Model) is sufficient, then chances are your system will be robust and high quality. That costs serious money and time, two things in short supply in many companies.
There do exist some companies who can do this, though. Airbus and the ABS brake designers come to mind.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
