BIOS nowadays is basically a bootloader shim in EEPROM. The majority of the ARM ecosystem wanted flexible and cheap devices. This promoted the use of a small ROM loader burned into the device and a removal of basically all EEPROM from the SoC.
The flexibility came back through the use of a secondary bootloader layer normally stored in the devices primary storage. Most manufacturers use u-boot or coreboot on an SD card or eMMC. Android standardized this as part of their partitioning scheme. All devices have a dedicated bootloader partition housing the secondary bootloader and any additional boot artifacts.
Then phones became wildly expensive and invalidated most of this.
Also, do you think it's possible that this way of doing things will come to the computer, with ARM hoping to gain a good share of the market and all?
It already has. Most of what ARM is doing to be cheap was already pioneered by PowerPC.
ARM EBBR specifications attempt to standardize this boot flow somewhat, introducing a standard EFI shell in u-boot. This does not solve the dependency on the secondary bootloader, and it doesn't prevent people from shooting themselves in the foot. It just makes distro interactions with the secondary bootloader more standardized.
This is a short term loss for a potential long term improvement. By eliminating dependency on translation APIs they can force the use of more open solutions like oneAPI which is even getting buy-in from companies like Imagination.
I made it through college without using windows on any of my personal machines, but I did need to access a library or computer lab to take 1 test that needed a specialized web browser for some reason. Other than that, I was actually pleasantly surprised by how easy it was to slip by with a good PDF viewer, libreoffice, and Inkscape.
My degree was in computer engineering, most groups I worked in outside of the engineering department just preferred collaboration through office online or google docs.
Arch on every box in the house, including the primary router. Mixed Intel and AMD. Openwrt on every AP (unfortunately Mellanox and MediaTek firmware blobs for the radios). GrapheneOS on my daily and LineageOS on my legacy phone.
Aside from occasional games, I don't install anything I don't have the source to. My phone is the only exception, for apps required to interface with the rest of the world.
Something like this can kind of be achieved programmatically by unraveling bash completion arguments and loosely parsing terminal help strings.
They aren't all formatted uniformly though, so you'll need to come up with a filtering mechanism to prevent returning garbage. You'll also always be a little out of date...
Everything loops back to steam in the end. Solid state thermoelectric devices have been around forever, and before that we had the idea of using thermal energy to augment magnetic fields and jump to kinetic energy without any intermediary conversion. All very low yield results, but we've tried it anyway.
Keep thinking about it, we need all the brains we can get, but don't write it off as a novel idea that the other egg heads just haven't gotten around to solving yet.
Data centers will probably be the only practical application. Consumer electronics will probably barely produce enough energy to power the regulator and tie-in circuit just to feed back into the pwm driver for fans nowadays.
I agree that you're not really leveraging any features of PNG like you would using JPEG or RAW here, but saying it's not meant for this use is an odd way to phrase it. There's nothing inherently wrong with wanting lossless compression on an image...
Lol, changing the country of origin doesn't constitute innovation from a consumer standpoint...
Now if this was using 5nm or chiplit or any of the other buzzwords of the day it could be marketed as innovative in the modern sense of the word.
Realistically there is no innovation left for ARM platforms. They all use the same core schematics. They only control data flow and peripheral IP as a manufacturer, unless they feel like building their own core from the spec (nobody really does that anymore as ARM has been desperately trying to standardize everything). The most "innovation" I've seen has come from stubbornness around keeping legacy bus architecture around instead of adopting AXI (even when all the IP they are trying to use already uses AXI and they keep having to make translation hardware).
You would first need to define malicious code within the context of that repo. To some people, telemetry is malicious.