$ gdb -ex 'file /bin/gdb'
run
corrupted double-linked list
Thread 1 "gdb" received signal SIGABRT, Aborted.
Yeah, try debug that.
I mean no harm.
$ gdb -ex 'file /bin/gdb'
run
corrupted double-linked list
Thread 1 "gdb" received signal SIGABRT, Aborted.
Yeah, try debug that.
Well I meant two weeks is the longest period i can leave the system without updating and have no problems. And i have yet to break it with 300 pkgs updating at once.
Arch maintenance: 0. Install it once. (The proper way)
pacman -Syu
I don’t get what is with this so hard? Yes, configs can be undecipherable but 90% time the merge involves just deleting the .pacnew versions.
A kernel was released that changed how the hash value got computed for casefolded filenames. (used for better windows compatibility) That kernel then went into production. This unfortunately split some file-systems that supported this into two incompatible versions, breaking the kernel rule 1.
There might now exist file-systems were created/modified with this bug present that the old/fixed kernels can’t understand.
I was reluctant to take this project, knowing well I would end up deleting nearly all existing code I would have to touch, all while having just mediocre skill writing its successor, if it ever becomes one.
I can no longer escape from this project, nor do have I will to.
deleted by creator
The point when the AI hallucinations become useful is the point where I raise my eye brows. This not one of those.
I do this exact same expression when I’m forced to gain knowledge of something potentially personally catastrophic…
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.
Jokes on merge… when a rebase editing goes wrong after +15 commits and six hours, and git hits you with a leadpipe: “do it. Do it again, or reassemble your branch from the reflog.” I.e. you commited a change very early, went over bunch of commits resolving/fixing/improving them and at middle way forget if you should commit --amend
or rebase --continue
to move forward. Choose wrong, and two large change-sets get irreversilbly squashed together (that absolutely shouldn’t), with no way to undo. Cheers. 👍
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.)
I never finished reading my CMake book that weights about two kilos. It’s now outdated, except for the core concepts.
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
usually gives tools that list something. ch
gives tools to “change something”, like chmod
. mk
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
René Rebe, I’ll watch him blast about bad code occasionally.
what the actual fuck. 🤮