yt-dlp executes code from the website to get the exact download URLs and header values. The websites obfuscate these to prevent downloading. Running arbitrary 3rd party code in Node or Bun might work, but is risky, especially when that code could potentially come from one of the many ads on that video website.

They both depend on Russia, one for liquid gas the other for nuclear fuel [1]. They are quite similar on energy security.

[1]: https://en.wikipedia.org/wiki/Nuclear_fuel_cycle_in_France#U...

They mitigate the obvious security thread with mandatory 2fa (actually mandated by regulation). Some use this as an opportunity to push their apps: no separate 2fa method, but only integrated in their bloated app, that checks for rooted devices and only supports the newest OS.

It’s quite hard to find out in advance, what 2fa methods with which fees each bank actually requires. I remember that some of them had funny ideas, what a customer should be billed for 2fa SMS. I think it was 50 cents per SMS.

1) wiring critical software in a language that protects better against such exploits. Might be Rust, Go, perhaps also C# and Nim.

2) Making reproducible builds the norm, that start from the original source code repositories (e.g., based on a Git hash)

3) making maintainers more resilient against social attacks. This means more appreciation, less demands, and zero tolerance against abuse. If the maintainer can be pressured, I am at risk.

The last one is probably the most difficult.

Basically I can imagine the attackers being a well organized group, using work sharing and pipelining. Some members of the group would be preparing exploits, some would infiltrate projects and some would make sure not to get caught. And since infiltrating takes time, they would make sure to have multiple projects in the pipeline, seine in the early contributor stage, some in the social pressure stage, and some in the exploiting stage.

On the other hand, you can already buy software, where the vendor takes some kind of liability: just buy Windows, AIX, or one of the commercial Linux offerings. Same for software libraries: there are commercial offerings that come with (limited) liability from the vendor. It’s even possible to create software to stronger standards. But outside of some very specific industries (aerospace, automotive, nuclear, defense, …) there doesn’t seem to be a market for that.

If you use a jump host, consider a different OS (e.g., BSD vs Linux). Remember this analogy with slices of Swiss cheese used during the pandemics? If one slice has a hole, the next slice hopefully won’t have a hole on the same position. The more slices you have, the better for you.

Although for remote management, you don’t want to have too many “slices” you have to manage and that can fail.

The attacker would then be stuck inside the jump host and would have to probe where to connect next. This hopefully would then trigger an alert, causing some suspicion.

A shared instance would allow the attacker to just wait for another connection and then follow its traces, without risking triggering an alert by probing.

The ideal jump host would allow to freeze the running ssh process on an alert, either with a snapshot (VM based) or checkpointing (container based), so it can be analyzed later.

In general, I’m not convinced that systemd makes things less secure. I have the suspicion that the attacker would just have used a different vector, if there was no systemd integration. After all it looks like the attacker was also trying to integrate exploits in owner libraries, like zstd.

Still I would appreciate it, if systemd developers would find a better protection against supply chain attacks.

Things become more complicated when multi-threading and / or asynchronous IO gets involved. If the producer on the left side of the pipe has multiple threads, e.g., one writer thread and multiple worker threads, producing data for the writer thread. Then it has to invent its own signaling between the different threads, to avoid throwing away data, when its internal buffers fill up. This is effectively a kind of back pressure.

In your example with the lever and the parser: if the lexer is multi threaded, you either need unlimited buffer for the tokens or some signaling for the threads, to slow down when the parser cannot keep up. This example is a bit artificial, since most languages don’t allow parallel lexers. But with parallel compilers and one (incremental) linker, this becomes more realistic.

“Video off” is often necessary, because your laptop runs low on battery, or has run too hot. Sometimes your Wi-Fi might just be bad, forcing you to audio only. A colleague of mine could not turn on video while the Anti virus was running, or the PC would get overloaded (hint: it was running all the time, as mandated by the security guidelines).

You might also not feel well with being watched because of personal reasons. And since it’s personal, it would not be the other person’s business.

If you are at home, video might interfere with other people’s privacy. Just think about the neighbor sunbathing while visible from your window. Don’t want to risk streaming things to work that are not safe for work.

The system did just fine, but was plundered by politics. During the German reunification, the people from the former Eastern Germany were added to the public pension fund without ever having anything payed in. This drastically increased the amount of recipients without bringing in additional money.

Politics decided that. They also decided to not put any tax money in the pension pool to re-balance it.

No matter how you design a pension fund: If you bring in an additional country as recipients without any additional capital, that pension fund won't survive.

[1]: https://www.bpb.de/politik/innenpolitik/rentenpolitik/290963...

The original article handles the first argument: Postgres doesn't need polling. Instead it provides a notify mechanism, that informs the application when the table changed (something was added or removed from the queue) via the SQL NOTIFY statement.

For the second point it also provides a solution: since optimization for reading is not needed anymore with the NOTIFY statement, the trade-off like different: we now need an efficient way to write. For this the article provides an efficient update statement with special lock behavior. This helps to make writes efficient, too.

It looks like both points from the blog post you linked are handled in the original article.