Can we link to something less self-congratulatory? This is an ad for noscope and not security report.
Also, authors of related code contest this [0]:
> When packages are uploaded to Forgejo, they are uploaded to a user or organization that owns the packages. Their visibility to other users is directly tied to the visibility of their owner -- a public owner infers a public package, and a private owner infers a private package. When a package is private because of the privacy of the owner, we know of no vulnerabilities that allow access to the package contents.
> This tying together of owner visibility and package visibility isn't as flexible as some Forgejo users would like it to be. And, it can be surprising to users as they can get the impression that package visibility should follow repository visibility when packages are linked to repositories. However, these are desired functional enhancements, not security vulnerabilities.
> Creating perfect randomness is surprisingly difficult. Even modern random number generators never generate completely ideal random numbers: small systematic errors can result in some numbers appearing slightly more frequently than others.
Wait, what? There nothing complex at all in making sure there is no value bias. It's called "whitening algorithm" and every hardware generator has one. My personal favorite method is passing the data via cryptographic hashes like SHA256, and also mix in previous state. This generates perfect distribution with no detectable patterns. (The only trick is to health-check your HWRNG _before_ whitening. Don't want your hardware to degrade to 01010101... and end up with a repeat of debian ssh key incident)
The article is very confusing. IIUC they want two quantum random sources that are far enough to avoid slower than light communication, and then combine them and then do something that is probably the "whitening algorithm" but it has been lost somewhere in the translation from research article to PR to press article.
Anyway, I'm guessing a lot of the details because the report is annoyingly confusing.
When I first learned about ternary machines like SETUN [0] I was so excited! Forger bits, there are "trits", and instead of boring boolean logic you have +/0/- trits. As alien as it gets!
But then I read much more about the design, and it turns out that the reason machine was ternary is the designers had to minimize number of transistors, and leaned heavily into transformer-based logic - which naturally favors ternary values.
But for transistor/IC circuitry, there are no advantages in ternary - they key to reliability is margins, and margins require only two states. Any transistor-based ternary implementation would be forced to using a pair of bits and declare one of the four states invalid - a clear efficiency loss.
History confirmed it - even in MSU, once transistors became more available, they abandoned SETUN and started using those. Turns out at least that ternary branch was just a evolutionary dead end.
No, not in general. Explaining stuff is a skill, and if you have it, the IQ gap is not a problem. And if you don't have it, then you'll have problems explaining to someone even with the same IQ but in the different industry.
If you had a conversation, and both parties went away frustrated, and you think it's because their IQ it too low.. think again. Surely as a person with high IQ you can find the right level of explanation?
There are plenty of examples: professors explaining to students, researchers talking to journalists, and even parents teaching their children.
It is a commercial hardware, and author wants to get some money back from it. Nothing wrong or shameful about this, as long as this is clearly stated from day 1 (and it is).
At least they provide full schematics here, which is better than many other products do.
Sure. Issue is particularly with the name, "PD-64", which suggests Public Domain (it's far from!). It may well be unintended.
C64 PSUs are C64 killers, which is why I feel strongly there should be as little as possible in terms of barriers to getting a replacement.
Yes, it is far better than the alternative (no schematics), as at least we can learn how it works without reverse-engineering, as well as build our own legally (just not sell).
The title actually mentions "USB PD" - that's USB Power Delivery, the electrical magic which can increase voltage over USB lines to 12V, and increase power correspondingly.
Without USB-PD (or similar technologies), the max power over USB is limited to 10W (- wire loss), so it would not be enough to power C64 reliably. So it was included in the name.
So I am pretty sure that "PD" in the title has nothing to do with public domain.
.. and the answer is "It's *our* cloud! Unlike others' clouds, ours can do sync/offline operation, so you can pretend you are an edge, while still paying us"
(oh, and it is called "SQLite AI" despite for that extra edge)
It is not even TUI, it is just library/API. It cannot print the text on the screen, it returns python's internal data structures.
I guess if one really wanted to show off the libraries, they could create some sample programs that'd render some sample messages to plain text, TUI or even a web page, but that seems pretty out-of-scope for the simple blog post like that one.
> With git, I'd routinely go and delete old branches to declutter. With jj, there's simply no need to. The same with stashes. It's really nice not having to do that labor, and simultaneously not dealing with long lists.
wait what? how does this work?
Many of my stashes are tiny changes that need checked later - effectively, each stash entry is a quick TODO list. At some moment, for example once a major feature is done, I'll go a check every stash'ed entry and decide - maybe it's no longer relevant, maybe I should make a PR out of it, or maybe I should convert them to the branch if it's useful but needs more work. The branches are similar, but on longer scale.
The idea that you don't need to declutter your old stashes/branches seems absurd to me - it's like getting a huge box labeled "misc", and throwing every single thing in there. Sure, it's quick, but that's how you lose the important things you need to do, and find the useless junk instead of the actual thing you were looking for.
Remember early internet? The time when it actually cost non-trivial amount of money to post stuff on the web, and there was no expectation that webpage authors would get any money back?
This worked pretty well. Websites were hobby - one might spend their money buying comic books, and someone else might spend the money making and hosting their website.
Also, authors of related code contest this [0]:
> When packages are uploaded to Forgejo, they are uploaded to a user or organization that owns the packages. Their visibility to other users is directly tied to the visibility of their owner -- a public owner infers a public package, and a private owner infers a private package. When a package is private because of the privacy of the owner, we know of no vulnerabilities that allow access to the package contents.
> This tying together of owner visibility and package visibility isn't as flexible as some Forgejo users would like it to be. And, it can be surprising to users as they can get the impression that package visibility should follow repository visibility when packages are linked to repositories. However, these are desired functional enhancements, not security vulnerabilities.
[0] https://codeberg.org/forgejo/website/issues/839#issuecomment...
reply