$ 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)

1. Every 2 weeks minimum pacman -Syu
2. Every 3 months merge/update configs in /etc.

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.

Bookmarking doesn’t work for me, too limited, and starts a horrible trend of duplicating them. So they are useless for tab history managment. Also, the linear tab history is not very useful… same problem, the entries get duped eventually. I often don’t want to restore the tabs from the last day whatever, but restore an specific set of tabs. Some times even multiple sets, and switch between these.

I really would like an Firefox feature, where the tabs would be part of a “tab history tree”. Opening a link in a tab would add it as a “sub-tab” of the parent tab. In history.

So when a doing a search or refining one many times, this would end-up linking all the opened tabs to the originating tab. A new tree of tabs could be started by just opening an empty tab, and a “tab organizer UI” should allow to move/group that into an existing tab tree if needed. (The tab-bar UI doesn’t need to visualize the tree-of-tabs. The tabs would be just auto-organized this way in the history)

I think this would allow to clear all of the currently open tabs in any window, but the tabs could still be neatly restored from the history on per-tree basis in any window. Restoring a tab-tree would allow to continue making refinements to it, or clone it. Currently multi-window tab restoring in FF is kinda borked, and only the last window’s open tabs are restored automatically.

/end-of-wordsoup-for-today.