These are "service" networks.

The transactions travel financial paths and go through financial institutions. Some times, they could be traveling the Internet on VPNs, and other times they could be using private physical networks.

In fact, these networks predate the Internet by years

When you check your credit card, you will notice a VISA, Mastercard or similar logo together with your Bank's one. This means that the card can be used in any device from that particular "service network" to pay something. And when you see a sticker when you pay with these brands logos, they are part of the service network.

I was thinking the same ...

... when you find a method, you also find the anti-method. And computers can simulate whatever if we have enough knowledge and time to figure how to do that.

I have been looking for this type of stuff ...

... not because I want my voice to be duplicated, but because I am looking for mechanisms to create professional videos about technology that appeal to people. And my voice is not exactly the best in town for this type of things.

So, I can share the things I know in a best way.

And ... if I can ask Mr. Jones to help me, and I can earn something of that, why not to share earnings with his family?

In a flashlight not, but that is not a current problem.

And boiling water temperature is lower than a combustion car one so ... could be a very interesting alternative for transportation; anyway, we are using radiators to control temperature in our petrol based machines and this is seldom a problem for the most of the people.

What I think is that we are just grasping the surface for many other not so well studied options for future batteries. The future looks nice.

My comments, as a full stack developer with experience using many different types of databases.

What I see is a design problem not related with what type of database is used

SqLite is a very fast embedded relational database that can work for many different use cases; it is not a toy and have a really big capacity. BUT, it blocks the entire database when a change is made on it.

The network databases as PostgreSQL or MySQL have record level blocking and a better mechanism to deal with concurrency, but they are slower because they depend on the network capacity while SqLite is used directly as a library.

Just that when you use SqLite as if it were a network database, you have an usage problem, as it lacks many components and it is not so easy (as not impossible) to add the extra functionality.

A different problem is to use python. These tests didn't take into consideration how slow could be the scripting used or even the servers involved. Database is just a key component, but only one. It is possible that the product can't deal easily with excess loading.

An embedded databases can be used in many different ways. For example, I wanted to have parallel level access to some data with SqLite; what was my solution? ... just to copy the data file several times and to offer it as an exclusive database for each connection. This works in many cases, in particular when the data is not shared (for example, when it is related to only one use case or user).

Or, it is possible to use all the database in memory, or to replicate two SqLite instances, one in memory and the other in disk.

To avoid memory leaks, I define a static memory area as the database heap, and I could define that area to lay in non paged memory, speeding the database.

For not to enter in many details... ANY database can deliver when used correctly. When we use then without investing time to know them, our results can't be the best ones.

I understand when you must create replacement parts.

But I don't understand why they create NEW products using parts that have been surpassed by other types of technologies. They are clearly out of synch between the different industries.

And this is not because the previous parts were better, as these parts were new when they were created many years ago.

Another problem is standars. The automotive industry just lack of them, as they are attached to the particular electronic elements instead of specifications and interfaces. If what they do is to work on top of some sort of API (the broad concept), then no matter what type of electronics is there. If the parts are API certified, then it is possible to use any implementation methodology from any provider. And, what is the proof of this? .... try to replace a car's ECU with another one from a different brand. It won't work, because these ECUs are extremely specific devices. And, a lot of luck if you try to improve something there.

In this case, the computing area it is very advanced compared with the car's one. Any computer from the same type of technology will run the compatible software no matter what brand are we talking about. Even the CPU could be made by different providers. Why we can't have the same level of flexibility in the car industry?

I agree ... the question is wrong in this respect.

Ransomware is not about making a backup. It is about how to avoid it, how to detect it and how to store what is healthy. Because a backup from a "dirty" source is as useless as not having a backup.

The real answer is storage technology agnostic. The right practices, the right physical network partitioning, the right access controls, together with carefully verified backups in ... whatever.

If, as an user, you are capable to introduce malware producing ransomware in your infrastructure, then you are done and all your methods to protect your data are wrong. The solution is to implement a different working methodology that avoid the ransomware to enter, to reproduce and to achieve its goals.

After reading the article, I understand Mr. Becker point of view. That generalizations are wrong.

However, Mr. Becker is also making a generalization when he question the "hard" concept, leading us to this discussion.

What I think is that the right way to say it is that we can't neglect the programming activities.

It is not that to program is an impossible, it is just that to program correctly we need a lot of knowledge, and a lot of careful work. If that need to know and to use hours of work is what is behind the "hard" concept, then yes, "programming is hard". And the proof is in almost every corner in the universe, from our tablet to the Space Station. How many thousands or millions of hours were necessary to have what we think is easy today?

But, certainly, any person can make a program (as concept). But not all these programs deserver the opportunity to be used in the mainstream because they could be dangerous to use.

I can work exactly the same contract in a Raspberry Pi than in a Dell Precission. Just some basic numbers as examples (if somebody could provide better data, please help us).

• Raspberry Pi 4 - around 4W
• Dell Precission - around 350W
• Apple Mini M1 - between 7 and 39W
• Surface 4 Laptop - 4.55W (idle) .... more using it

In my experience, both MacOS and Windows eat a lot of power with their useless beauty. A simple practical Linux in a low profile machine, as the Raspberry Pi, is enough for doing a big quantity of things.

Also, the RPi is enough for a big quantity of server level things, even for transactional processing. These huge servers are not necessary, in particular when working edge designs (processing near the source). And Java, C# and al lthese platforms with huge quantity of grease as innecesary software layers, contribute to require more and more hardware to do the most simple things.

The answer is simple: SIMPLIFY ... Just Enough Software .... that's all. If the ancient 8088 processor was enough, what marvels can you do with current magical CPUs?

I agree ...

A bunch of black holes is "a void"

All the black holes together is "the void"

...

at least, until we discover what is behind them.

First error.

C with Classes was a C pre-processor in the 1980s ... but that was even before having the C++ name.

C++ is a C descendant but it is not a superset. There are things that you do in C and are invalid in C++ and things that you do with C++ that are invalid with C.

If you create C software using a C++ compiler, you are in a mistake. Compile your C as a C file and you will notice many errors. And when you create C++ software believing that you are using C, then you are not using the C++ special functionality and you are not really working with C++.

Crap is when you can't do what is needed with the tools you have at hand.

For Linus, C++ is crap. But I suppose that also Lisp and Fortran, Perl or even Prolog, because he won't be able to work Linux with those languages.

But for me, C++ is far fron being Crap. It is really an extraordinary language, incredible useful if you know how to use it correctly. Just that I am not making Linux, I am doing different things.

My point here is that there is no universal language that be able to do whatever, but that characteristic is not enough to offer the Crap qualitifcations to any language.

For me, Python is Crap, because it is not enough for what I do and could be dangerous in some circumstances. But, although I am not a Python fan, I really have no rights to tell everyone else that Python is Crap as an universal truth. I won't continue being happy with Python, and Linus neither with C++ ... and that's as life is.

Just ... use what makes you happier.

I have a Mac Mini 2012 (yep ... one of the abandon machines with Big Sur). It has an i7 and now it runs with Catalina and 10GB RAM (because one of its 8GB memory sticks failed and I had a 2GB around). And generally speaking it runs well.

However, my work is on Linux, so I have Linux virtual machines on that Mac, and a bunch of ARM based devices with a lot of different fruit logos printed on them.

What I think is that there is not unique working landscape that could define every possible usage. The M1 machines look interesting, although they are the bottom part on the Apple's Mac line, and that's fine. Also, take into consideration that they made the CPU, the Operating System and the Machine, so everything must be hyper optimized for that working configuration. If the software was made for MacOS and not for MacOS running on an x86 platform, then it will benefit from that synergy.

About the ARM, I have a Samsung Chromebook Plus machine with an OP1 CPU ... and that machine outperforms my Mac Mini in the browsing experience, with 4GB memory and a 6 core CPU. I also can run some Linux applications without problems. And as a small portable device the machine is wonderful. Then, for me, ARM is a capable technology for many different usages. Maybe it is not the most powerful device over the planet surface, but if I really have the need for such type of power, I will find it. And Apple made a bold move trying to control its environment, one that after the PowerPC attempt, was based on their real life experience with mobile devices.

About benchmarks ... about configurations ... I prefer people to use the machine before making empty assumptions. And I don't think that Apple will replace a product line with a lower one because this could hurt their name. And that's it ... they need to protect their fruits.

Who said that the world needed to be attached to x86, x86-64 (AMD64) or ARM?

Who said that Windows or Linux or MacOS were the end of our computing story?

Computing must evolve, and the best way is to have alternatives. No matter if they can't compete with flagship "current" machines or if they don't run Windows or if they don't have Fedora or whatever specific distribution ready to go.

I think that we still have some hundreds of years in front of us to invent new things. Who knows if Risc-V is the "flagship" platform in 2030 or 2040? And people make jokes about HURD 1.0 ... but that thing is still there ... or maybe with quantum computing our current computer offerings will lag in capacity.

Also, each day we are more and more far from the 1980-1990 desktop idea. Although Apple is making new desktop and notebook machines, they are more focused in their mobile platform as the centric component. And Microsoft is migrating a big bunch of things to the cloud. We have very small computers in our watches, and our appliances are distributing the responsibility to deliver, so to think that we really need the latest many-core CPUs eating our electricity bill each month as the main future path is just silly.

Yeah, we can't forget the polarization on main CPUs to United States with NVIDIA move on ARM. But there is this Risc-V that already became more attractive to many as a real alternative that it is not attached to political managements. This is a really important thing to consider. .... also, when people becomes concerned about something, changes are accelerated. This is just human nature.