I remember Obnam being retired in 2017[0]. I was evaluating backup systems back then, and went to borg (and later to restic). But turns out, it came back 2020. I like the motivation [1]:

> Borg and Restic are both fine backup programs. I've been using Borg for a while. The point here for me is that I find implementing backup systems to be a fascinating hobby. Thus, I want to write my own. The act of developing being the point more than having something I can use myself. Everyone else should use something battle-tested, unless they want to help me build something they'd like to use themselves.

[0] https://blog.liw.fi/posts/2017/08/13/retiring_obnam/

[1] https://blog.liw.fi/posts/2020/11/10/why_write_obnam/

(sadly I have not found nice website with newer version photos yet)

I never did this myself (except while learning how to drive). And I don't think I've heard about my friends doing this either. Turn around because the road was impassable? Sure. Pass the wheel to someone else? nope.

That means a lot (most?) human drivers are "level 5 autonomous".

This is amazingly naive. C has significant amount of problems, and while OOB array accesses cause a lot of bugs, there are plenty of other C parts which cause bugs too (like use-after-free and concurrency). And even if we just focus on the OOB array accesses, there are a lot of places which cannot be covered by simple counted_by()

Wasn't the whole point of smart contracts that the "code is law", that people can audit the code they put their money into, and no one can change it?

If you are going to put the backdoors in, might as well do the regular finance. Much cheaper, no gas fee, more functionality and so on.

Something of the note: despite the scary name, this is a "parsing mismatch" vulnerability. The discovery what was that one could make a tar file which would safe in the "tar" tool, but when extracted by an affected rust crate, it would find more files, possibly malicious. By itself, it's fine - if you are extracting untrusted tar files without the filter, you are going to have a bad time, vulnerability or not. The vulnerability would only occur if you have a combination of files: like a security scanner which uses one library, followed by the real app which uses a different library. Then the bad code could escape security scanner's attention.

[0] https://news.ycombinator.com/item?id=45665513

So the role of school is to make sure that the kids have everything they need to reach their potential.

This ordering requires defining the scope, and the narrower the scope, the easier it is to compare people. If you only look at "maintain the rented city apartment" and "live in rural house" in isolation, it's pretty easy to rank people by independence. But if you say that _either_ of those counts as "independence", the things get much harder to qualify. But either way, there will be people who can't do anything, people who can do everything, and a large mass of "uncomparable" people in the middle.

I think you misunderstood the article - it's great to try new things, and it's not a problem to promise things you are not 100% sure about. What's important is the honesty - "I've tried, I've failed, here is what I learned". OP said the the best:

> "Failure" does not have to be a failure, and V itself does not have to be the sole product of V's development. Alex has time and time again promised to write blog articles on various aspects of V's development. Had he done that, instead of silently backpedalling on claims about V, we could have had very interesting reads reflecting on the challenges of creating a new programming language.

instead, we have disappearing claims that require internet archive to find out, denial of any problems, and blaming of every problem on "misinformation from haters".

You don't need to be corporate or in in academia for basic integrity.

To the author: project maintenance is hard work. Your PR might work for you just fine on your machine, but what about other setups? Will your code still work after the next library upgrade? If not, who will fix it? That's why the maintainers can reject any changes they want - they are ultimately on the hook for all that so they are the ones with final words.

SPAM is officially described as UCE, "Unsolicited Commercial Emails". Your emails are both unsolicited and commercial, so people rightfully block it. I know I always click "report spam" when I see an unsolicited commercial email, not just to clean my inbox ("report spam" and "delete" are right next to each other), but to make sure sender's reputation takes a hit and fewer other people get spam email.

this is insane! Why on earth would one to replace a short, simple, highly debugable program with this crazy combination. Why would you trade a simple socket(2) call which shows up in ss, netstat, strace etc.. with something that opaque? Especially given the bandwidth is minuscule and the destination is already localhost.

If you have sub-projects which cross-depend on each other (no total ordering), then recursive make will have a bad time. I agree.

Author thinks the best way is to stop doing recursive make. I disagree.

IMHO, the best way to solve this is to arrange your sub-projects properly, so the are no circular dependencies and thus there is one correct order. Not only your build should be a DAG on file level, it should also be a DAG on the sub-project/directory level. Then a single recursive "make" pass builds everything properly, no need for ugly tricks like running make twice, or intentionally omitting some dependencies.

(Even better option is to stop using make for such large projects - it's great for smaller ones, but for the huge ones, there are much better runners available. But I assume there is some reason to use make)

(sorry if they in the video - I generally don't watch the videos before reading the text first)

- For ingress, you use special "file transfer" software. Run the receiver on secure side, run the sender on insecure side. It blasts the file "blind" - it has has no way to know if anyone ever received it. Make sure the receiver is fast enough, and the error-correcting codes are a great idea too, as they don't need feedback. It's up to user to want to secure side computer and check that the file was received without problems. Yeah, this is similar to sneakernet, but more secure, as you can't accidentally carry a virus on seemingly-empty drive.

- For status egress, you have secure side broadcast status periodically, say every minute. Insecure side receives the status, updates the database, and runs the regular web server to share the status. Again, secure side has no way to know if someone is listening on the other end, it just blasts out the messages and it's done.

And you are correct, if the secure system has both egress and ingress diodes, it is no longer isolated, and devious enough malware can establish two-way communications. But even if it won't save you from Stuxnet, the simple fact that it is no longer possible to have direct network connection to the outside raises security bar quite a bit - all the ideas about "let's just open this one port on firewall, it'll fine I swear" are completely stopped.

(Which reminds me of something in GP's (mikewaro) message: _why_ would a data diode need a promiscuous mode? Given every single data diode I have seen needs a special software on both sides, you should not need anything beoynd a basic TCP session)

> The technology to eradicate mosquito-borne disease already exists.

One approach is eliminate one specific kind of mosquitoes, another is to change them so they don't carry diseases. Either way, we'd still get mosquito bites.

Many servers I've owned had multiple years of uptime, and the only reason they'd go down is because they will get decommissioned or because of power outage.

The article says:

> disk drives, power supplies and some other components have been replaced but Hogan estimates that close to 80% of the system is original.

so I am guessing there was no reboots, nor CPU replacements.

> The algorithm only works if a raw signing oracle is available. Most RSA usage in practice (that is, RSA signatures using PKCS#1v1.5 or RSA-PSS padding) do not expose such an oracle, and thus this attack does not pose a practical risk. Examples of RSA use that do expose such a signing oracle would include blind RSA signatures (e.g. Privacy Pass) or HSM APIs.

> Are people actually still using RSA?

> Yes, particularly for digital signatures (e.g. certificates, TLS handshakes, tokens, OAuth). Key exchange for protocols like TLS uses ECDH or has transitioned to ML-KEM, and the attack does not apply to these algorithms.

This is breaking only some rare kinds of RSA usage... And if you are considering new system that uses RSA signatures, please don't. Use elliptic curves - the operations are faster, the signatures and keys are smaller, and there are fewer attacks.

Even PrivacyPass stopped using RSA signatures for that reason [0], which means that the only example of applicable technology is no longer correct.

[0] https://blog.cloudflare.com/privacy-pass-the-math/#previousl...