JATth

permanently attached USB SSDs are supposed to be mounted

Just mount them somewhere under / device, so if a disk/mount fails the mounts depended on the path can´t also fail.

I keep my permanent mounts at /media/ and I have a udev rule, that all auto mounted media goes there, so /mnt stays empty. A funny case is that my projects BTRFS sub-volume also is mounted this way, although it is technically on the same device.

For example, the new .config directory in the home directory.

I hope slowly but surely no program will ever dump its config(s) as ~/.xyz.conf (or even worse in a program specific ~/.thisapp/; The ~/.config/ scheme works as long as the programs don’t repeat the bad way of dumping files as ~/.config/thisconfig.txt. (I’m looking at you kde folks…) A unique dir in .config directory should be mandatory.

If I ever need to shed some cruft accumulated over the years in ~/.config/ this would make it a lot easier.

They could be very well using the earth’s orbit around the sun to get better resolution - two data points from opposite sides of the orbit. What I know is that the largest “virtual” radiotelescope is literally the size of earth. The data points are synced with atomic clocks (or better), and a container of harddrives gets shipped into a datacenter to be ingested. Thats hundreds of streams (one per antenna) of data to be just synced up, before the actual analysis even can begin. (I’m just guessing after this) At this point, you have those hundreds (basically .wav files) lined up at timepoints they were sampled (one sample, one timepoint column). So row by row, so you can begin to sort out signal phase differences between the source rows.

I.e to put it shortly: an image is not taken, it is inferred and computed. Not that you even could in the first place, it’s a blackhole after all.

The default systemd target to boot into can be overriden from the kernel command line.

If the GUI ever gets broken, having a such fallback boot entry just for the (VT) console mode is invaluable. (The boot-entry can reuse the same kernel and initrd images from the regular boot.)

More like defending TSMC… large majority of all high-tech silicon is made in Taiwan. If that foundry burns, the consequences would be astronomical. The possible consequences are already at a point they could make threats via self-sabotage.

I tried Luks and BTRFS more than 6 times leading to a script error each and every time.

This was actually my experience also, so I went back to a manual install to just get it done. I think the archinstall script won’t get any configuration of device-mapper/LVM right (including disk encryption with cryptsetup). The disk encrypt setup had even more hoops to go through than just LVM.

Why would learning be gatekeeping? I wish I could just teach my secrets… The manuals are only a shallow guide to knowledge. E.g. ls, has condensed for me to ls -laR mostly, and that ls<tab> usually gives tools that list something. ch<tab> gives tools to “change something”, like chmod. mk<tab> to “create something” mkdir etc.

I may navigate in the terminal, but putting me at front of Blender etc. and I’m back to crawling speed of RTFM, and all I would see is a zoo of buttons.

The time you took to answer the archinstall questions and what would take to do them manually is (nearly) the same. The manual way is that you are forced learn the system (which does take time), and it’s thus more exact of what you want. Once you successfully boot a manual install on a bare hardware, you’ll get all the swag. ;)

(I was lazy last time I had to do a full install, and I prepared the system almost entirely in a VM, for which I used the physical disk I would finally boot it from. The final step was to chroot’d into the nearly complete system and make it boot outside of the VM…)

I actually don’t get the fuzz/meme about Arch Linux. Yes, the installer drops you into a shell where you need to fix the keyboard layout for starters and the next thing is preparing enough disk resources for the OS which is somehow ungodly hard. My point is that if you can’t then you are not qualified to maintain the installation, or actually RTFM and start to fr think what you do.

deleted by creator

There are no “safe levels of lead”, it’s toxic as-is and bio-accumulates in the body, which is the main problem. It also doesn’t matter in what chemical-compound or what route the lead comes in, it’s still toxic as a heavy element.

Why is everything laced with lead then? Well, it’s fantastically useful and cheap element, with wide applications… Paint, pipes, bullets, leaded petrol (the absolute worst incident), batteries, radiation-shielding, it was/is on everything. It’s entirely a man-made problem.

Except modern day reality is that if we keep using it we’ll all die or at least become dummer. This cost is obviously greater than banning/avoiding all uses of lead in the first place. In the science circles they are betting if a some new magic material contains lead, it’ll never (or is allowed to) exit the lab.

I have learnt coffee oxidizes quite fast giving that horrible burnt taste, which even milk won’t hide. The longer it has been in a open-to-air-pot, the worse the taste gets. Storing in an air-tight container (thermos) it stays “ok” for days. So actually, I think all such servings from the coffee shops are thus inherently worse than brewing your own coffee.

(There are no starbucks in my country, but I think McDonald’s coffee really is somehow heated past 100*C and it’s the first sip away to burn your mouth, so you wouldn’t taste it anyway.)

René Rebe, I’ll watch him blast about bad code occasionally.

You can’t exceed lightspeed. Current tech is already at 99%

Even the newest “64-bit” cpus are really just 48-bit (or 36-bit on low end) or if bleeding edge 56-bit physical adressing processors. This is the maximum amount of virtual memory a process can have access to. You could memory map all your hard disks an still have room to map more physical memory to VMA.

nohz_full confusingly also helps with power usage… if the cpu doesn’t have anything to run, no point waking it up with a scheduler-tick IPI… but also no point trying to run the scheduler if a core is peaking with a single task… With nohz the kernel overheard basically ceases to exist for a task while the it is running. (Thought the overhead just moves to non-nohz cpu cores)

To be fair, there should be some heuristics to boost priority of anything that has received input from the hardware. (a button click e.g.) The no-care-latency jobs can be delayed indefinitely.

Why can Windows do it when Linux can’t?

Windows lies to you. The only way they don’t get this problem is that they are reserving some CPU bandwidth for the UI beforehand. Which explains the 1-2% y-cruncher worse results on windows.

I agree that UI should always take priority. I shouldn’t have to do anything to guarantee this.

I have HZ_1000, tickless kernel with nohz_full set up. This all has a throughput/bandwidth cost (about 2%) in exchange for better responsiveness by default.

But this is not enough, because the short burst UI tasks need near-zero wake-up latency… By the time the task scheduler has done its re-balancing the UI task is already sleeping/halted again, and this cycle repeats. So the nice/priorities don’t work very well for UI tasks. Only way a UI task can run immediately is if it can preempt something or if the system has a somewhat idle CPU to put it on.

The kernel doesn’t know any better which tasks are like this. The on-going EEVDF, sched_ext scheduler projects attempt to improve the situation. (EEVDF should allow specifying the desired latency, while sched_ext will likely allow tuning the latency automatically)

No, I definitely want it to use as many resources it can get.

taskset -c 0 nice -n+5 bash -c 'while :; do :; done' &
taskset -c 0 nice -n+0 bash -c 'while :; do :; done'

Observe the cpu usage of nice +5 job: it’s ~1/10 of the nice +0 job. End one of the tasks and the remaining jumps back to 100%.

Nice’ing doesn’t limit the max allowed cpu bandwidth of a task; it only matters when there is contention for that bandwidth, like running two tasks on the same CPU thread. To me, this sounds exactly what you want: run at full tilt when there is no contention.