> Any alternative is better than the current state of things.
I don't know, the incentives for creators are already low enough. Any book one writes lands immediately in Anna's Archive and is digested into LLM slop for the profit of Altman & Co. Any piece of investigative journalism, when shared here or on Reddit, sees a link to some paywall-bypass site as one of the most upvoted comments. So we are already in a Bastiat's window situation where people are disincentivized to produce creative work. I'd rather not put the work of software creators even more at risk of being cheaply copied and copyright laundered: any state vault would be an easy target for trillion-dollar corporations.
Aside, as someone doing retro reverse engineering I greatly appreciate the author's words about the tension between software preservation and the need to reward creators for their work.
> Any piece of investigative journalism, when shared here or on Reddit, sees a link to some paywall-bypass site as one of the most upvoted comments.
That is generally because they're on random sites that want you to subscribe for a year to read the one piece that was mentioned on the sites you read... not going to happen, sorry.
How this worked for printed news back in the dark ages was:
A friend told you about an article, or a headline piqued your interest.
You could anonymously hand a negligible payment (few cents or dollars in cash) to an intermediary (the newspaper seller at the street corner) to get access to all the content published for a certain time period (daily/weekly/monthly issue of the publication).
Now a "friend" (for example a HN post) still tells you about an article.
Unfortunately you can't get an issue, they want an ongoing commitment. It's not anonymous, you have to create an account. The intermediaries are gone though, is that a good thing?
I might be a contrarian in that I actually like using unsigned integers for sizes and indexes. In my experience, most of their trappings can be prevented by treating any subtraction involving them as a `reinterpret_cast`: i.e.
* Do your utmost to rewrite the code in order to avoid doing that (e.g. reordering disequations to transform subtractions into additions).
* If not possible, think very hard about any possible edge case: you most certainly need an additional `if` to deal with those.
* When analyzing other people's code during troubleshooting merge reviews, assume any formula involving an unsigned integer and a minus sign is wrong.
> An alternative view is that any C "unsigned" is both positive and negative. For example the unsigned short "1" is the same number as "65537" and as "-65535".
This can be disproven by the fact that dividing by `unsigned e = 1U` is well defined and always yields the starting number. If the unsigned numbers were really modular numbers as you suggest, division could not be defined.
This does not demonstrate anything. It is just additional evidence that the C standard contains contradictory rules about "unsigned" integers.
The oldest parts of the C language are all consistent with "unsigned" numbers being non-negative integers. The implicit conversions between different sizes of "unsigned", the sizeof operator, the relational operators and division are consistent with non-negative integers.
However the first C standard, instead of defining the correct behavior has left undefined many corner cases of the arithmetic operations, allowing the implementation of "unsigned" as either non-negative integers or integer residues.
Eventually, the undefined behaviors for addition, subtraction and multiplication have been defined to be those of integer residues, not those of non-negative integers.
These contradictory properties are the cause of many confusions and bugs.
In extensible languages, like C++, it is possible to define proper non-negative integers and integer residues and bit strings and to always use those types instead of the built-in "unsigned".
In C, it is better to always use signed numbers and avoid unsigned, by casting unsigned to bigger sizes of signed before using such a value.
I used Qwen CLI's undescribed “coder_agent” (I guess Qwen 3.5 with size auto-selection) and it was powerful enough to complete 95% of a small hobby project involving coding, reverse engineering and debugging. Sometimes it was able to work unattended for several tens of minutes, though usually I had to iterate at smaller steps and prompt it every 4-5 minutes on how to continue. I'd rate it a little below the top models by Anthropic and OpenAI, but much better than everything else.
I opened “view source” in Firefox and it showed the html in a different font than usual. Maybe it's just a fallback because the page contains Chinese characters, but I was quite surprised. A small page with a lot of mysteries.
Really great writing and interesting experiment! I love the small details like the “clueless user”-style crash report in the `about:telemetry` section (“it just crashed out of nowhere”)
One thing I find life-changing is to remap the up arrow so that it does not iterates through all commands, but only those starting with the characters I have already written. So e.g. I can type `tar -`, then the up arrow, and get the tar parameters that worked last time.
In zsh this is configured with
bindkey "^[OA" up-line-or-beginning-search # Up
bindkey "^[OB" down-line-or-beginning-search # Down
What I love about the default Bash Crtl-C behaviour is that once a command has been located, the bash history is moved to the history of that command, until Enter is pressed.
$ a
bash: a: command not found
$ b
bash: b: command not found
$ c
bash: c: command not found
$ d
bash: d: command not found
$ <CTRL-R> b <UP>
$ a
That's great if I don't remember which command I was experimenting with, but I do know other commands that I did around that time (usually a file that I edited with VIM).
That feature is entirely optional and disabled by default. Atuin stores your shell history locally in a sqlite db regardless of whether you choose to sync it. I thought fzf was fast, but atuin makes it look slow by comparison.
However what I do find useful is eternal history. It's doable with some .bashrc hacks, and slow because it's file based on every command, but:
- never delete history
- associate history with a session token
- set separate tokens in each screen, tmux, whatever session
- sort such that backward search (ctrl-R) hits current session history first, and the rest second
Like half my corporate brain is in a 11M history file at this point, going back years.
What I would love is to integrate this into the shell better so it's using sqlite or similar so it doesn't feel "sluggish." But even now the pain is worth the prize.
I just want to give a perspective of someone that uses the 'eternal history' in bash per Eli Bandersky [1] and reluctance to use something like atuin (without/ignoring shared history).
First, as for speed and responsiveness, if there is a degradation, it is imperceptible to me. I wouldn't have a clue that my interactive shell is slowing down because it is logging a command to ~/.persistent_history.
My persistent_history is 4MB and has been migrated from machine to machine as I've upgraded, it's never felt slow to edit with (neo)vim or search with system supplied grep.
Eli's way of doing it also includes the timestamps for all commands, so it's easy to trace back when I had run the command, and duplicates are suppressed. In fact my longest persistent_history goes back to 2019-07-04, so I've been using it for quite some time now.
But the larger point I wanted to make is that I wouldn't feel comfortable switching this, in my opinion, quite efficient setup to displace it with an sqlite database. That would require a special tool to drill through the history and search rendering simple unix utilities useless. As Eli suggested, if your history gets too big, simply rotate the file and carry on. I have the alias phgrep to grep ~/.persistent_history, but I can easily have another alias to grep ~/.persistent_history*.
You don't have to setup shared history with Atuin if you don't want to and that's what's holding you back. Otherwise it hits the rest of your requirements. Just don't hesitate to change from the default config.
1. work on a project on host_foo in /home/user/src/myproject
2. clone it on host_bar in /home/user/src/myproject
If you set filter_mode = "directory", you can recall project specific commands from host_foo for use on host_bar even though you're working on different machines and the search space won't be cluttered with project specific commands for other projects.
If you use multiple terminals it kinda sucks unless you do export PROMPT_COMMAND='history -a' in your.bashrc or something cause only the last closed terminal saves to history
export EDITOR=vi and then hitting Esc puts you into vi mode; k, j to move up/down through history or pressing / to search etc including using regex is all available.
This is the default `fish` shell behavior. Type anything, up/down keys to iterate through full commands that containing the term; alt + up/down to iterate through args containing the term.
One thing I do is configure my keyboard so that "modifier+{ijkl}" mimicks the inverted T arrows key cluster. So there's never a need for me to reach for the arrow keys. And {ijk} makes more sense than vi's {hjkl} and is faster/more logical/less key fingers travel. The nice thing is: as I do this at the keyboard level, this works in every single map. "modifier" in my case is "an easily reachable key in a natural hand position on which my left thumb is always resting" but YMMV.
I set that up years ago and it works in every app: it's gorgeous. Heck, I'm using it while editing this very message for example.
And of course it composes with SHIFT too: it's basically arrow keys, except at the fingers' natural positions.
I did the same, starting with Ergo Mode in Emacs many years ago, and ending up today with a programmable split keyboard with those keys as arrows on a layer. For when I'm on a laptop without the keyboard, I have a mishmash of solutions that bind to Alt+{ijkl}
I'd try this, but I often find that I want to repeat a cycle of two or more commands. Yes, I probably should edit and put them on one line with semicolons (or even make a function), but.
Or put && between them - I had "compile;run" and when compile failed, it still ran (but the old build). Took me a while to figure out. && ensures the first command succeeds.
Anyway, so worth it to combine commands into one line for easy re-run.
For further life-changing experience... add aliases to .bash_aliases
alias gph='history | grep --colour -i '
alias gpc='grep --colour -Hin '
#if gnu time is installed
alias timef='/usr/bin/time -f "tm %E , cpu %P , mem %M" '
reply