I mean no harm.
Sugar is half bad, half good: the glucose part causes no harm and whole body can use it. The fructose part on otherhand is bad and has to/can only be processed by the liver first.
Yeah, it feels like I blinked and it’s now October already…
(2024 was and still is a heck of an year for me. I have almost climbed out of the ditch on this year. Yay!)
The billions that got pumped into vaxine research… The mRNA method has received a nobel prize. Before this we had no good way (or as safe) to pre-train the immune system to “if you see this (virus, etc.) again, raise the alarms”. Now we do.
Edit: updated the wording a bit.
Python is just a pile of dicts/hashtables under the hood. Even the basic int
type is actually a dict of method names:
x = 1
print(dir(x))
['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', ... ]
PS: I will never get away from the fact that user-space memory addresses are also basically keys into the page table, so it is hashtables all the way down - you cannot escape them.
This “news” looks pure FUD + confusion of what actually happened, and I think is best to be ignored until it can be read coherently from the next weeks news paper… I’m only commenting because of my local news began to propel this shit…
This was truly a wtf moment of the month.
Last time I spent time watching him was when he freaking fixed the kexec syscall for IBM PowerPCs. for free
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.
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 never finished reading my CMake book that weights about two kilos. It’s now outdated, except for the core concepts.
The short version:
This means that you reset your password with a 32-character long generated password, which is saved in your vault, PlayStation saves a 30-long password and then you use the 32-long password to log in, which fails because it isn’t the same.
That password prompt should be scorched to earth.
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.
When I heard the news, my first though was a mix of “Oh. oh no…”, “yay! no vendor-lock-in”, and “OH, NO.”
My expectation for the future is that a crowd fundraiser like on Wikipedia (does anyone remember those?) will be on the way for Mozilla… there is no way they can survive a 80% drop in the budget gracefully.
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.
H̢̱̀e͖ͧ͘r͈̔́e̖̅̀ͅ ḩ͒͏̩̲ẹ̽ͯ̀ c̔͑͠҉̬o̢̢̠̜̓̚m̷̻̳ͧͪ͘ę̢̥̋̀s̢͈̲ͧ̀͜ͅ,̧̔͞ͅ f͖͗̿̕͝ȅ̴̶̩̂͟a̸̡̯͈̼͋͡s̗̋̀̀̀̀͟t̒̾͏̯ y̸̛̟̽̇o̢̟̜͂͆ͯ͘͜u̧̧̜͔͇ͭͫ́̚͞r̀̃͑̓͒͏̮ e̍̒̇ͯ҉̴̲̭y̷̰̖ͨ̑͜e̓ͭͭ͂̕҉̸̛̦̱̤̫͢s̡̛̫͋̕ o̢͉̘͚̤̅ͫͤ̓ͭ̕͡n͊͘҉̲̟̖͔͝͞ t̷̟͊̽h̨̦͎̅̄ͪ́̚͘͠i̶̢̛̬̞̦͊̅̏̀́s̶̸̢̹̹͕̩̜̣̎ͫͤ͐̈̀.̛̰̼̗̺̼͗ͣ̏́̚͟͠.̵̪ͥ̈̚̚͞ͅ.̷̶͎̞̳̘̈͋ͬ̈͂͒͠ z̸̛̫̓͜͟͡ḁ̧ͨ͊͗ͫͫ̅́͢͠͠l̵̴͒͏͚̥̻g̩͎̲̼̠̿̅ͩ͌̇͟o̢̝͍͔͍̼̼ͤͦ̎́͘͝ i̷ͧ̅̂͟͡͠͞҉̸̙̱͍͈̝̠̺̀ͅs̗̮͇̪̯̋͋́̕ t̵̶̛̰̘̰̫̬͖̜͗̒͗̉̿͌̀̀͢ẖ̴̴̡̭̪̉̌̈́͗͘e̵ͬ̃ͬ͌͆̍͏̧̡̧̦̘͇͕͙̳̹͜ ạ̳̺͎̤̺̖̠̔̈ͮ̉̌̓̀́͟͢͞͞n̊͏̰̖̘̖̭̰̖̕͢ş̴̽͘҉̮̞̼̱w̨̢̠̻͐̐͑̊͢͞e̢̡̛͖̙̟̣͋͆͘̕ͅŗ̧̯ͪ͘͘͜͡.̭̘͇͓̹̻̖̖͉͊ͪ́
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
deleted by creator