VGHN7XDuOXPAzol

(ironically) OP is from the UK, so would be geoblocked by imgur

Well, I'm somewhat minded to agree with you, but they are fast enough, cheap enough and don't get bored of tedious work, which makes them passable at many things. Maybe.

I feel caught between two worlds, I know people both very 'for' and very 'against'. The business is very keen for people to use them to go faster.

For non-trivial changes, output so far does not meet my quality standard and I tend to spend a lot of time cleaning up after them, probably more than I would have spent doing the work myself. This being much more boring, I hasten to add.

Their comments suck so I feel like I have to go in and rewrite them all.

Maybe I should just let go of the quality standard and accept that in exchange for steaming ahead at full speed, but I'm reluctant (and not just for me, there are also coworkers who I feel like I would be letting down).

Thanks for your perspective

I think one thing that troubles me is that I so far have gotten quite far by 'caring about the little things'.

Now we live in a world where this feels, for the most part, unsustainable to keep up with. When directing LLMs to code something up, it's still occasional useful to have the knowledge and experience of those little things earned over years, but at the same time 1) it seems like I run into fewer opportunities to add to that experience and 2) it seems like you can often just prompt LLMs to 'grill' a design a few times, it will probably surface some of the most important tradeoffs

This, plus since you can't realistically run these LLMs at home, the motivation to get invested in them is not really there (for me at least)

I mean, yes I do find the mathematical background of LLMs fascinating, but it's not going to be something that I can put to practical use (much), if that makes sense?

This phrasing from the article feels so Claudish to me. Is it just me?

I used to find joy in knowing how things worked inside-out. Whether it was Postgres, or browser engines, or some detail about compilers... I used to find joy in developing the little techniques that made programming NOT building on quicksand. There was satisfation in what you had done being robust.

Pardon my lack of creativity but I'm not even sure what mastery with the new tools (LLMs) would look like. When you are so abstracted from the details and don't have to know anything, what _is_ mastery? (I am not asking rhetorically and if people have overcome this thought I would be interested in hearing from them.)

Knowing how to ask a machine questions in the right way? Playing as a manager in control of non-human developers? It all sounds really silly and something that is difficult to aspire to (and I can't imagine explaining my job to others with a straight face). I think I find it even more egregious because it's all built on paying rent to the LLM operators.

It's not that I don't enjoy results in their own right sometimes but I think I am definitely in the 'this is giving me an identity crisis' camp.

(tongue-in-cheek) In that long time you've been online, have you not come across the concept of a search engine?

To help others disambiguate choices a bit:

Kopia does not let you pipe into it without intermediate files, or at least not in a friendly way I could figure out.

Kopia seems quite designed around the backup server being the place where the config is set. IMO it's harder to configure if you have your own declarative config tooling (like Ansible, NixOS, etc)

The nicest way I found to ignore files declaratively is to configure a ignore-file pattern in the repository policy and then declaratively create `.kopiaignore` files.

The Kopia server is convenient if you have a server at home and want to back up laptops to it, with them being in a shared deduplicated repository without having to trust the clients not to get pwned and wipe out the backups. However I'm not aware of a nice way to then transfer those backups to aggregate them into a bigger repository. (So I just rsync them off-site and don't worry about getting deduplication with other backups) Also learnt the hard way that you can't set a bandwidth limit when backing up to the kopia server, which can tank wifi performance on laptops during the backup.

I am thinking of switching to Restic as it seems like it is more suitable for people who want a tool at the complexity level of tar/git CLI with declarative config, rather than something imperatively configured.

Sure, I'll try my best to put some concrete numbers on it:

On a file of ~1M lines (350 MB), ripgrep returns a query matching 22k lines in 1.9s.

(Separately: We have gzip log rotation for old logs. A log with 1.9M lines (106 MB gzipped) on disk can be searched from cold in 1.3s by ripgrep, whilst still being ergonomic. Maybe a different compressor is better?)

On a service unit filter over ~218k lines, `journalctl -u service --since <...> -g query` returns 4.8k matching lines in 4.127s (and this is after having warmed the cache by returning the unfiltered query cold, in 11.9s. I don't have root to clear the disk cache

I should have ran the filtered query first but ah well, since the difference is already so large it doesn't matter that the filtered journalctl query gets an unfair advantage)

Comparing input rates:

    ripgrep (plain): 576k line/sec
    ripgrep (gz): 1.4M line/sec
    journalctl (-u, --since, -g): 53k line/sec

I don't have a great deal of understanding of journald's internals, so perhaps there is some variable here that is unreasonably unfavourable to journald.

Transcript

    user@machine:~/log$ time rg query aservice.log | wc -l
    22628

    real    0m1.859s
    user    0m0.109s
    sys     0m0.909s
    user@machine:~/log$ wc -l aservice.log
    1071606 aservice4.log


    user@machine:~$ time journalctl --since '2026-08-16' -u [email protected] | wc -l
    218661

    real    0m11.914s
    user    0m10.729s
    sys     0m0.798s

    user@machine:~$ time journalctl --since '2026-08-16' -u [email protected] -g query | wc -l
    4804

    real    0m4.127s
    user    0m3.727s
    sys     0m0.186s

Probably more painful on the day to day is how `journalctl -fu myservice` seems to stall for on the order of 5 to 10s, sometimes. I can't reproduce at the moment and maybe it only happens on some machines, but if you were interested in 'real-world anecdata' it's something to maybe note.

I really want to love journald (it sounds like it's aiming for a good system) but I share the other commenter(s)' frustration here about journald being slower than just pulling out ripgrep on regular files.

We have some services at work that log to text files and some to journald.

The log volume to file is >> the log volume to journald. Yet `rg query myservice.2026-08-01.log` seems to always wind up being faster and better than something like `journalctl -u myservice.service --since '2026-08-01' --until '2026-08-02' -g 'query'`. (The tab completion and discoverability is also better, I guess)

Monzo in UK is fine with rooted and no Google Play. No idea how it would fare inside Waydroid though.

Just a pure guess, but if you do a global find, you get a list of 3-line-ish chunks of context around search matches.

If you then Ctrl+A to select all and press backspace, I wonder if that would delete all those 3-line chunks...