Electric is far more efficient too, thus cheaper. Electricity you can transit over distance over wire and generate however you like. We’ve done it a long time, far and wide.
Turning electricity into hydrogen, distributing it, and then turning it back into electricity to move a vehicle, is so wasteful/expensive.
Just use a big battery.
So teens learn about Tor & VPNs. This stuff doesn’t work. The higher you put the skills to get access, the more they will learn. Nothing motivates teens more than access to adult stuff. Maybe this is really a tech literacy policy.
Someone got to say it…
There is no Debian if everything was a pile of Snaps/Flatpack/Docker/etc. Debian is the packaging and process that packaging is put through. Plus their FOSS guidelines.
So sure, if it’s something new and dev’y, it should isolate the dependencies mess. But when it’s mature, sort out the dependencies and get it into Debian, and thus all downstream of it.
I don’t want to go back to app-folders. They end up with a missmash of duplicate old or whacky lib. It’s bloaty, insecure and messy. Gift wrapping the mess in containers and VM, mitigates some of security issues, but brings more bloat and other issues.
I love FOSS package management. All the dependencies, in a database, with source and build dependencies. All building so there is one copy of a lib. All updating together. It’s like an OS ecosystem utopia. It doesn’t get the appreciation it should.
I can see a lot of comments against copyright here, but has anyone considered the implications of changes to copyright on copyleft?
I argue copyleft is demonstrably socially useful in locking things open. I do wonder if we’ll end up the two being different legally…
Can it run problem bank apps? I need a bank auth app for work as the bank stopped fobs and it just would not run on LineageOS. It refused to run because “the phone is insecure”. I tried Magisk hiding stuff and MicroG, and a number of way of tricking methods. That’s why I ended up on GrapheneOS, as a compromise without feeling too compromised. Everything seams to think it’s on a normal Android phone, but I’ve sandboxed the Google tentacles. But it would be better if mandating OS wasn’t allowed. If I want to run a “insecure” phone, that’s my “problem”.
I can only speak of on Linux. If you know the disk is bad, clone it, with ddrescue, and fix the clone. But in future RAID and backup remotely. Also, next gen filesystems like ZFS and Btrfs for check sums and self healing and subvolumes with send/receive deltas between them.
I’m glad that had a happy ending and sorry that happen. Autolock is so dangerous.
As I said, “if this no other option”. And to be honest, that was once, for a few weeks before the new KiCad hit Debian repos. And only because hardware team wouldn’t wait to switch, so to open stuff, I needed it too.
I’ve been on Debian Testing for my own desktops for about 15 years now. Sometimes as a Frankendebian mixing in SID/unstable. Sometimes mainly unstable, but mostly just Testing.
It rarely breaks, but when it does, it’s a learning opportunity. Stable for servers and other people’s desktops. Maybe with backports. Flatpacks if this no other option.
You don’t get 100% solid and 100% new. Ever. With anything.
Busybox is used in the initramfs normally. It’s the shell used by any scripts in that early stage, as well as the fallback shell environment.
Google is not really much better than MS. It still leaves you under the yoke of big tech. “Meet the new boss, the same as the old boss”.
You spelt monopoly wrong.
You can pay to have less ad, but you’re still also paying with your data. Bet pretty soon it will be pay and have ads, or pay more again. They have a captive market. They can extract and extract.
I feel bad buying things DRM’ed, so I very rarely do, and not for myself. I don’t want to fund that. Feels much better funding DRM free work.
You can of course write drivers for them, but then it’s you own abstraction not the standard Linux abstraction. (You can hack something up with IIO for that stuff, but it’s not pretty). There is CUSE (part of FUSE) you can do some character devices with.
Existing drivers in Python are messy to use if you our not developer in Python.
The nice thing about in kernel is:
The Linux kernel does hardware abstraction. It’s not a microkernel. There is limited support for proper userspace drivers.
If you doing some application specific app, that will only work with those chips, use do it in userspace. But to make a normal system for normal use, you want things in kernel like normal.
Only a fraction of it is RTCs. What is in the Pi overlays folder is from everything. Not even all the DT I2C RTCs. There is loads of ADCs, DACs, IO extenders, all sorts.
It’s really annoying you can’t do DT on x86 Linux. It’s a bit of a gap in the platform. It would make Linux ARM based developer’s lives easier.
GPIOs are the easy bit. You can get those no issue on x86. It’s I2C and SPI that are the issue with x86. You can get the buses sure, but all the device drivers are Device Tree based. You can’t just throw in Device Tree overlays on x86.
Regulations can work. Latest is EU’s USB-C phone/laptop/tablet standardization. It’s great! No more crazy range of different laptop power supplies.
Some stuff is pretty much as I want already. Henry vacuum cleaners for example. Tough as nails and easy to get parts and help for. Framework laptop and fair phone aim to be good for repair and upgradablity.
France repairablity index can be rolled out further field.
Things used to be more repairable and last longer. We can reverse the trend down. No need to despair.
I think the EU will be first to role it out at and scale. Like USB-C device power standardization.
Certainly not the way we lunch right now. The energy used, that focused, in that short a time, is insane.