I interpreted it more like "I have these 500 different cronjobs all spread out across $unit_of_time. If the system is down for longer than $unit_of_time and then comes back, does all 500 jobs start running instantly (since they missed their previous deadline)?"

Just to be clear, this isn't default systemd timer behaviour, you need to opt in by setting Persistent=true. If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool because at that scale you'd surely need better observability

You could implement this with a gitlab instance in a separate system, like two VMs in proxmox or two physical machines, and a shell executor running in them. Gitlab CI has a nice feature to limit concurrency by using resource groups. Say you have 500 jobs spread through the day and the system stays offline for a while, when it comes online it'll start processing the jobs, but will only run a single one at a time. You get visibility, logs, queue monitoring and an API to query data.

> If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool

Eh sometimes, but you can get pretty far with one of two approaches:

1. Careful use of Requires= and Wants= to group your scripts into chains of jobs, which achieves fixed parallel (though at 100s of jobs, I hope you're generating those unit files with a tool like Puppet or https://github.com/karlicoss/dron or something and not doing this by hand).

2. Even better, just use a lockfile. `ExecStart="flock -F $TMPDIR/mylock <command>"` is pretty hard to beat. Use -F so as not to confuse KillMode and resource accounting and you're golden. Just don't use flock(1) timeouts; let systemd handle that. Heck, if you have that many cron jobs, you should be doing this even if you don't use systemd; otherwise job latency changes can cause reboot-style thundering herds out of the blue.

If you need semaphore behavior and still don't want a real job queue, waitlock (https://github.com/bigattichouse/waitlock) and many other CLIs have you covered.

1. This is spread across 500 files, maintainability goes out the window

2. If this for some reason fails, misconfiguration or unexpected shutdown, you could have a failure that's hard to track or debug

These are fine with a few services chained together, but this requires a shallow depth of dendencies. To have these theoretical hundreds of jobs chained together like this isn't practical or safe.

I think that might be the thing. Parents whose children are more challenging might more often "be at wits end" and turn to online communities for guidance, help, or other insights, whereas parents whose children are not as challenging just breezes through, and thus do not end up as a data point online on how difficult parenthood is.

Also, even though I don't know you, I am certain that you are a good parent, and that you are doing your very best, and that your child is lucky to have you as their parent. :) Stay strong.

Happy families are all alike; every unhappy family is unhappy in its own way.

No one remembers when their friends or family tells “we are doing well everything is nice”.

Everyone passes on or remembers horror stories.

This is true of many communities. The internet is full of complaints because people rarely take the time to say just “my car works just fine”. There’s no value in that info. People go out to talk about it when they have a problem, that’s a real conversation starter.

Discussion groups aren’t a balanced slice of how the overall situation looks like. They tend to sway towards the negative side because discussing about everything being fine gets old fast.

Aren't they actually readline keystrokes, and emacs is "readline-aware"?

I'm pretty sure the navigation shortcuts date back to when Emacs was literally just a set of TECO macros, and GNU Readline adopted them

Yep. Readline’s modeled after what Emacs was already doing.

Strangely enough I tried using vi mode for readline and hated it even though I use them constantly in vim. I just hated having to switch modes on my terminal

This could be an argument for investing in more reliable/higher capacity public transit systems though. Which would also likely result in a fair increase in public health from moving a bit more and possibly less polluted air going in an out of the lungs of the populace.

> This could be an argument for investing in more reliable/higher capacity public transit systems though.

Public transit is impractical outside of big urban centers. And even there, it's nearly always a nasty experience. This is why people who can afford it still drive or use taxis in cities.

I take it you haven't lived in a country that invests significantly in its public transportation infrastructure, like Switzerland or Japan?

I don't know whether or not it is our instance at $dayjob that has a wonky setup, or if it is the elements client, or what (probably the client, as the problems all but disappear in the webb-ui version), but oh how many synchronization issues we are facing. threaded conversations not showing up, or randomly disappearing, clients getting stuck in message fetching loops, not actually fetching anything, notifications of new messages either not appearing, or not disappearing upon reading them, and ON TOP OF THAT no custom stickers/emojis/gifs...

but those synchronization issues... if I want to be sure something reaches the rest of the team in a timely manner, I have reverted back to email

Matrix should categorically not have any sync issues; this is not normal. Something bad must be happening on the server; what server are you using and how are you running it?

> Matrix should categorically not have any sync issues

Will you please let every single instance of any piece of Matrix infrastructure know? Nothing appears to be respecting this rule.

I don't have such issues, seems like we're living in different worlds

Lol, messages showing up randomly days later is par for the course for our tiny group chat, most of whom are on matrix.org. Sometimes element won't download messages for some rooms (or even all rooms) for days/hours. Matrix has gotten far less reliable over the years (and I used to run a few homeservers).

I was like "oh common, that can't be a real comment, it's obvious to everyone how unstable this still is", then I saw that the comment was from Arathorn.

You know, for half of the time you spend commenting over here to save face (or something), you could work with your users and see their firsthand experience for yourself.

this is me working with my users and trying to understand their firsthand experience for myself :)

Literally no better audience to do this work on than places like here.

The carriers can provide almost as good location data through just doing fairly simple calculations on timings and signal strengths received by the cell towers, and their implicit knowledge about where those cell towers are located. Good keywords for further reading are (("4G" or "LTE") and "GMLC") or ("5G" and "LMF") and/or OTDOA.

While Google and Apple may be hesitant, what are your thoughts about AT&T or Verizon?

an evolution of the gpg web of trust could possibly be part of it

`uniq -c` introduces a "count" at the beginning of the line, so what we are then sorting is on frequency of the unique terms in the output, not sorting the unique terms again (which indeed would be kindof nonsensical)

There was also Anna Lindh, Sweden, 2003

Aha! I too have seen thumbnails of videos with context clues (product brands in the thumbnail which doesn't exist under that brand in my country) yet with a video title in my native tongue, which a clear "machine translation"-feel to it.

Until I read this thread I assumed that it was the content creator doing shenanigans (low quality AI slop video mass-produced in many languages and targeting my locale with videos for my locale), but it does make so much more "sense" that it would be YT doing this.

And my reaction to those thumbnails, thinking it was the creator doing low quality AI slop, was to "reward" them with "Don't recommend this channel".

So I have been punishing innocent channels for crap that YT is doing...