Removed by mod

Removed by mod

It’s been years since I took a look at this but I vaguely remember a handy kioskrc config file under xfce4…

found it…

That sounds like the non-techies would be able to fix it themselves on Windows without you being around, which in my experince isn’t the case.

It might be different for you with a lot of tech-affine people in your family. But for those of us being forced to be the tech support anyway, it can really make a difference if you have to fix a Linux issue once in a while or have to reinstall Windows for the 5th time this year…

I do know it’s not completely literal

Are you trying to kink shame?

Batteries losing more than 20-25% of their capacity in 150.000km had a defect in production already. You can find similiar numbers in any OEM’s warranty. So a non-defective battery will provide at least 80% of its capacity at 150.000km. The average car manages about 250.000km over their life-time of about 15 years (reference numbers from the US, so the most pessimistic view as barely anyone else in the world is matching those distances).

You are not completely wrong. Used batteries will be a problem… somewhere far down the road because electric vehicles are expected to easily manage 800.000km or more (less moving/wear parts).

But we are not there yet. The whole EV market isn’t old enough to have produced these long-lived vehicles and we are back at my original point. Today it’s not about battery degradation but about EVs not getting old fast enough to already have established a robust used market. In fact the first big batch of EVs on the used market is often not expected for another 2 years (see here for example, and that’s again rather new vehicles because of a loophole for leased cars in the EU).

In short: There isn’t a huge used EV market yet and (more importantly) the demand is stifled by battery degradation fairy tales not relevant (EVs old enough for this basically don’t exist yet) and political mismanagement subsidising new EVs.

It’s obvious for everyone with basic logic skills.

But that doesn’t mean we can’t try and twist the fact for anti-EV propaganda. Because it’s really, really, really important we keep burning oil… if you are someone selling oil and have the money to spread bullshit for personal gains that is.

What do you think the average 10 year old car has done to that point? Battery degradation is hugely overrated and stories are based on tech already left behind.

The actual problem for the used car market is the opposite: EVs live much longer than traditional cars and thus don’t lose their worth that rapidly, while on the other hand new cars still see a fast development cycle while also getting cheaper.

So no, it’s not a problem of used EVs per se and that their expensive batteries are allegedly dying. It’s the fact that a new EV just a couple of years later is ahead 1-2 generations and also cheaper.

You could…

But then one is an open system where you can disable the UI put on top and have a working linux system, while the other is a closed blob destroying compatibility and trying hard to lock you out from accessing the underlying linux system.

ARM is shit at hardware discovery in general. So no, chromebooks don’t need a special distro. They however need a kernel adapted to the specific hardware, often down to the model (that’s also the reason Android updates take so long on phones and there is very time limited support… there’s always someone needed to adapt new updates to the specific hardware for each device, so they don’t bother for anything but their latest products).

So what humans have done for millenia in the form of furs, leather and bone?

Decryption isn’t a problem if you use the systemd hooks when creating your initrams. They try to decrypt every given luks volume with the first key provided and only ask for additional keys if that fails.

I have 3 disks in a btrfs raid setup, 4 partitions (1 for the raid setup on each, plus a swap partition on the biggest disk), all encrypted with the same password.

No script needed, just add rd.luks.name=<UUID1>=cryptroot1 rd.luks.name=<UUID2>=cryptroot2 rd.luks.name=<UUID3>=cryptroot3 rd.luks.name=<UUID4>=cryptswap to your kernel parameters and unlock all 4 with one password at boot.

Actual wolf packs are a family. One pair of adults plus their children. Until those are old enough, then they leave and search for a partner and own territory.

All the stuff you read about pack alphas, all the sociological pseudo-science about alpha behavior derived from it… that’s all based on a one bullshit study about a large group of wolves artificially intoduced to a new area, that in no way behaved like wolves naturally do.

Basically the equivalent of putting a few dozen teen-age boys on an isolated island then studying their behavior to understand human society.

Linux is Linux.

We should send all those people, pages and guides suggesting distros to hell.

And then instead we suggest update-schemes (fixed, rolling, slow-roll), package managers and Desktop environments. People with enough brain cells to start a computer are then absolutely able to chose a distro fitting them based on that. Everything else coming with a distro is just themeing/branding anyway…

(and just for the use statistic: Archlinux, Opensuse (Leap and Kalpa), Debian here…)

I’ve been using Arch and Manjaro for couple years each and in my experience they both break regularly. But, for some weird reason, Arch Linux is praised, when Manjaro is shamed upon.

No, there is not some weird reason but actual very good ones.

Things can break on a bleeding edge update scheme. That’s to be expected from time to time. But the questions are “why did it break” and “what is done to fix it”.

If something breaks on Archlinux it’s because of some new package with a issue that escaped testing. Then the fix come out as fast as possible (often within minutes even, but let’s assume hours as those things need to move through mirrors first…).

If something breaks on Manjaro it’s either because of the exact same reason as above, but 2 weeks later. Because Manjaro keeps back updates for two weeks “for stability reasons”, yet doesn’t do anything in those 2 weeks. So they just add the same problem later, completely defeating the argumant about stability. Oh, and fixes are of course kept back for 2 weeks, too, because… reasons.

Or it breaks because they fucked up their internal QA. For example by letting their certificates expire again and again and again and again… of by screwing up their very own pacman-wrapper and then ddos’ing the AUR for all users, not only Manjaro ones.

Or -speaking about the AUR- it breaks because they give their users full access to the Arch User Repository (without any warnings about user content being less reliable and used at your own risk) pre-installed. Also they do it on a system generally out-of-date because it lags 2 weeks behind. Which is not what AUR packages are build for (they assume up-to-date systems) and is a straight path to dependency hell and breakings… not because something went wrong but because the whole concept of an out-of-date system not running their own also 2-weeks behind version onf the AUR is idiotic. On the “plus” side they have an easy fix: blame the user, because he should obviously know that an pre-installed part of Manjaro is conceptionally flawed and shouldn’t be trusted.

Right decision but for the wrong reason.

Let me google that for you: Quark

Car-brains don’t do standard logic, only car-logic…

Hydrogen or battery?

The answer is battery. If battery is an option then the answer is battery. Always.

This will only change if either there is an unlimited amount of free energy available or the laws of thermodynamics stop being valid.

Stick to a specific distro and train your staff

Linux is Linux. Train your staff to properly use one and they can use them all. “Distro” is just a fancy word for “which package manager and update cycle to we chose and what logo do we put on our pre-installed wallpaper”.