Really ?
Boeing is charging tge Feds much more than Oracle can ever do.
A bigger Problem is the lack of multithreading support in the type system. Java simply is outdated in some ways.
1329 publicly visible posts • joined 20 Nov 2021
Almost all Cpus have no concept of memory safety in a fine granular way. No concept of multithreading race condition avoidance.
No concept of automatic pointer initialisation.
The only exception might be the Algol mainframes, some Lisp machines and the iApx423. Only the algol machines are currently in production and sale.
Memory safety these days come from strong typing of a HLL and from compiler generated runtime checks.
Both C and C++:have no strict mechanism to stop accidental sharing of a variable/object between threads. Identical Problem.
Also, no way to force use of safe Arrays in eiher language.
No way to detect and stop a stack overflow. Both.
No way to stop use of raw pointers. Both.
Etc.
The vast majority of template use cases are simple things such as std::vector or shared_ptr. To instantiate them, simple search-replace is sufficient.
I have seen large (dozens millions loc) C++ based systems using the good old C macro processor for These generics. It Was the leading CAD system then, used to design cars and large aircraft.
The Algol mainframes are(on a high level) similar to Java virtual machines. Bounds Checking for each array is done by the CPU, for example. Pointers are guatanteed to be good or NULL etc. Numbers are Typed, too. You cannot add a pointer to a flott, for example.
This is also mostly true for Kernel/System Code
These Algol computrs look much more secure to me than the Unix "one lange array of untyped octets" approach. I do not have statistics, though.
Also Listen to Tony https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
From my own language I can say that Compiler Bugs do exist but they are rarely the source of real-world defects.
Memory Safety is not the holy grail of Software engineering and it does not kill all Bugs and defects.
What it will do quite reliably is to detect the 70% of exploitable Bugs related to memory access.
A powerful aid to the Software engineer. Comparable to ABS for drivers.
...maybe because it makes economic sense to reuse basic libraries such as buffered TCPIP, buffered Files, http requests, PDF Parser?
Real World C++ programs will use dozens of foss libraries, too. They are just managed via yum or apt-get, instead of npm or rust crates.
Of course they all have Bugs of their own, more or less capable maintainers etc. They must be correctly used, which can be a challenge.
Still no difference between C, C++, Rust, Java, TypeScript or Sappeur.
Libraries exist for fundamental reuse economics.
99% of template use cases can be realized by an equivalent, simple m4 macro, which expands each instantiation to disk.
Then you get sane error messages from those files.
For all other useful cases of compile-time code Generation, please create small C, Perl,C++ program and include them into the make file.
Avoid templates, they are an insane way of generics and compile time calculation. Similar to BRAINFUCK.
Do you seriously believe other providers are immune, by means of magic ?
Just a few days ago one of the megaCloud providers had their "master key" stolen, which meant ALL servers could be read and changed.
A few years ago a smaller, but non-trivial cloud provider had their "management console" hacked and essentially ALL servers in the open.
The entire "cloud" idea looks questionable.
Because Putin brought a much more efficient Mafia than what they already had then. The modern Mafia knows how to feed and clothe the populace, all while building superyachts and consuming Italian cheese. The previous Mafia had them starving.
He essentially jump-started the seemingly broken soviet system and had some success in wheat production, minerals and coasting on great soviet weapons such as the Mig31.
Then he made a big mistake and believed his own Propaganda, which says that Russia is on par with NATO. From that followed the Ukraine war.
I never said this is a paradise. I just described reality. Painting NK as an isolated entity is simply wrong. They are part of PowerBlock #2.
Lots of people seem to suffer from Alzheimers when it comes to such things. Or they never bothered to read up anything on the Korean War.
Imagine your company "A" runs an accounting system on a Cloud Computer "CC". Everything very secure, properly patched, good security practices. Then there are companies "B" and "C" which have similar good security. Finally, there is Joe "J", who uses CC for throw-away computing experiments.
J runs an outdated version of Apache, which has exploitable bugs. He does not care, because for him it is an experimental system.
Then comes along "I", who is a criminal hacker who runs scripts to probe all IPv4 adresses for exploitable Apache instances. He finds Js Apache on CC. I can now insert an exploit which contains ZenBleed in order to undermine all of CC, including the VMs of A,B,C. I can read out ssh keys and get access to the processes of A,B,C. GAME OVER !
In other words, if you run a cloud system for anything business-critical, you should be very worried now.
Sysadmins should operate a separate, small RPI computer to log into valuable datacenter computers via ssh. This RPI must have JavaScript completely disabled. Cost is less than $300 for an RPI+Display and looks like a worthy investment.
Or maybe deinstall all browsers, PDF viewers, email clients and office packages from the Command Computer. Will definitely increase security.
The idea of time-sharing a large CPU with lots of state(from register to caches) might be inherently insecure.
As Gernot Heiser states
https://www.youtube.com/watch?v=wJ96s3pNtI0
somewhere in his lectures(can't definitely find it), CPU state must be completely flushed(zero out caches and all types of registers !) if you want to have a secure time-shared CPU. There is no other way to be really sure if you want to provably deny side-channel attacks.
So maybe computers should evolve to the transputer concept of loosely coupled CPU cores ? One process, one CPU, one register set, one cache, no time sharing ?
Definitely, if you have an ssh key for a bank data center on your computer, the same computer should never run a JavaScript-enabled Browser !
Data Center and Cloud Computing based on the Time Sharing idea looks very questionable. The short term fix would be a move to many small machines, which can be easily rented out individually. There should be very fast interconnects between them.
Real-world data always has REDUNDANCY. This will allow heuristic algorithms to "fish out" secret information such as you Bank Account Number, your Banking PIN etc.
PLUS - if it is a crypto key, the attacker can simply brute-force with the collected "key candidates". Testing 1000000 potential keys is done in a few seconds.
In other words, your notion is badly wrong.
As I wrote above, a very low power CPU/MCU (1W or even less) can do the required cipher(similar to MST). Using Davies-Myer, AES can also double as a Secure Hash code(as done in MST). So less than 2k Lines of C can provide a Secure Command Channel. The CPU can be powered down using a timer, or when battery is low and must first be recharged from solar cells. In power down mode, an IoT CPU will draw only a microWatt or so for the timer counter. There are plenty of IoT chips around, including those from STM and NXP.
No need for power-hungry and quantum-threatened Public Key ciphering. Program the key into the satellite when it is on the ground and from then on use this symmetric key via MST or similar.
Not encrypting at all is like letting your wallet lie on the pavement and going to sleep inside the house.
Of course, for HAM and other amateur satellites, Command Messages and Replies can be transmitted in clear, with only a secure HMAC. SHA256 will do the trick:
COMMAND_OR_REPLY ::= PLAINTEXT_COMMAND AES256(PRESHARED_KEY,SHA256(PLAINTEXT_COMMAND))
This is also "quantum secure", as AES256 has 256 bits of symmetric key, which is considered as hard as 128bit non-quant.
The key problem of many industries is that they believe cipher and communications security can be done by each and every half-and-self trained guy.
A major car company had this trouble with their SMS-based door opener. Other car companies were/are in love with "keyless go", which is very hard to do securely(needs high resolution timers). Replay and Relay attack opportunities all around.
The banking industry had confidentiality, replay-safety and integrity solved at the year 2000. It took others until 2015 to achieve the same, because they were too cheap to hire experts.
TLS in practical implementations is a hell of insecurity too, but often sold as "industry standard". TLS saves people from thinking themselves. The entire idea of hybrid ciphers is not necessary nor useful for most applications.
1.) Secure Command Links can be realized in about 1500 LOC, including AES Locs. Been there, done that: https://github.com/DiplIngFrankGerlach/MST. It needs an ESP8266 or even less muscle do the job. MST has the same assurances as TLS/SSL, but without the Public Key cr4p.
2.) The "researcher" apparently surveyed amateur satellite projects. Not the $500 000 000 commercial or mil satellite.
3.) Of course "hackers" lack of a high gain directional antenna plus the other RF equipement is a "protection" of some sorts. Just never expect the Russians, the Norks or the Iranians to respect this "protection". I would venture to say that HAM radio guys could build this for much less than $10000. A bit of balsa wood, flexible metal grid (1mm opening), a bunch of RF transistors and some HAM RF instruments will do the trick. That antenna might last only a few weeks until the next storm, but it is good enough to send and receive to/from the sat. After the pwn, the antenna can be blown away...
CINCOM does not clearly say how much they want for internally developed apps. The want to "discuss" this with you. And apparently they also use number of users or number of employees to calculate license fees for company-internal applications.
I would not be surprised to learn that they are more expensive than Oracle is.
(No, I am not financially related to Oracle !)
Cincom is the main developer-provider of serious Smalltalk IDEs and VMs. They demand $500 per dev per year and 6% of your product revenue.
Other pricing models of their products are in the $5000 to $10000 range one-time per developer.
https://comp.lang.smalltalk.narkive.com/jgCbTiWI/is-cincom-smalltalk-prohibitively-expensive-for-a-single-developer
So, Java is not expensive at all, compared to Smalltalk and DELPHI from Embarcadero. Depending on the situation, of course. A few ST devs in a large corporation *might* come cheaper than Java.
$3000 000 for a 45 000 employee-company is $66 per employee. How much is the average labour cost of an employee per year ? Surely 100x to 5000x more, wherever it matters. North Korea and Nigeria does not count.
Also, compared to a tool machine worker, $66 is a pittance. He stands in front of a $500 000 CNC tool machine, which is depreciated over 10 years.
We computer folks should really get a grip on economics.
The SUN freetard model has destroyed this company. It also destroyed BORLAND, who had a Pascal/Delphi business before the freetard Java model came along. Great job, SUN, you destroyed Borland and yourself by your stupid idealism.
Oracle provides tens of thousands of nicely paid, health insured jobs for software engineers. Where do we expect the money for that to come from ???
US debt must always be seen in comparison with Gross Domestic Product.
https://worldpopulationreview.com/country-rankings/countries-by-national-debt
Japan, Greece, Italy and most other nations are worse off on this quotient. Arguably, Japans meteoric rise 1960..1990 was due to massive credit expansion. The cost of this expansion is that many young Japanese men and women consider it financially impossible to have children. Credit was the bonfire where Japan burned its future.
Regarding children, Europe is not much better than Japan. Same with Russia. They build missiles and superyachts instead of raising children.