Kernel.org People

Some of this wrong, some of this is way too wordy.

>
USB-C cables that support Power Delivery 2.0 and 3.0 can carry a minimum of 7.5 watts (1.5 amps at 5 volts) or 15W (3A at 5V), depending on the device, cable, and purpose.

Nope, all USB C cables are 60W minimum. The connector might support less, but the cables do support 60W minimum.

> USB-C Charge Cable—designed in the early days of USB-C

Nope, nothing wrong with a USB C cable which doesn't have the high speed lanes connected. That's a perfectly specification conformant cable. High speed lanes is the phrase I miss from this too long article.

Here's a much shorter explanation of it all.

A USB C cable always have separate wires for 1) power , either 60W or 100W capable. The latter needs an eMarker IC in the connector 2) a separate pair for 0.48Mbit/s speed USB data (aka USB 2.0) 3) it can have and most do have four high speed lanes (each lane is formed from two wires as differential pairs). These lanes can carry various data , by default it will use two lanes to carry USB data -- at at least 5gbps, if the cable is short enough then 10gbps. (While 20gbps mode over four lanes is defined so few hosts support this we don't need to care.) There are alternative modes besides USB, namely DisplayPort and Thunderbolt. In DisplayPort alternate mode it can use 2 or 4 lanes for DisplayPort. If two then the other two can be used for USB data as above. DisplayPort has its own versions: DisplayPort 1.2 can deliver 8.64 Gbit/s video…

> Yeah but typing related bugs which is what static type checkers catch only account for 3% of bugs.

You're stating this as if it's fact and also universal, but I strongly doubt it. Even defining "type-related bug" is hard, because there's a ton of bugs that are not type-related but are much easier to avoid if you're using a good static type checker. For example, stringly-typed values, or switch statement exhaustiveness bugs. Some type checkers, including TypeScript, can eliminate almost all null reference errors when used with strict settings. Then to top it off, types add a bunch of static analysis capabilities you could not otherwise have: for example, you can find accidental dead code because you have an impossible condition that can be proven impossible by types, or more exactly find incorrect usages of library functions, and so forth. There's quite a range of problems and almost none of them are explicitly related to strong typing.

And let's say somehow, this is a universally correct number. That doesn't mean it's the reality faced in front of you. What if you already know the majority of your bugs, as logged today, could be prevented by a type checker?

> You are always going to get more bang for buck by simply writing more unit tests.

Good test coverage is a huge, non-trivial investment for any reasonably large, reasonably complicated codebase. Making all of your code testable in fact impacts how you write code, sometimes in ways that are actually similar to the…

You have some points, for some I do think it isn't as bad as you write. FWIW, some comments inline.

> - You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.

You can use tools like public-inbox or lei, the former is hosted for bigger projects on https://lore.kernel.org/

If you're interested, see also https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started

And sure subscribing for a drive by submission is rather overkill, but if one contributes more than a few patches, setting up a filter is to easy with mailing lists that I don't think one can just hand wave that away as an "unreasonable" solution. List have a dedicated List-Id header, so one can easily filter them in a targeted way.

What I want to convey actually is, that yes, there can be improvements made here, but doing so isn't impossible just because the message medium is decentralized mail vs. a centralized HTTP API.

- Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email.

Hard disagree on that being the general case. Even getting Thunderbird to send…

I'm casually learning about this stuff, so please forgive my noob questions. My end-goal is to enable laypersons like me to verify the authenticity and provenance of digital communication.

I see that Ryabitsev also announced a git transparency log for the kernel:

https://people.kernel.org/monsieuricon/introducing-the-kernel-org-git-transparency-log

This is very cool.

You wrote:

> ...it is valid at most until the key is valid

I don't follow. Do you mean while the key is valid?

I think the scenario you're describing is:

a) I'm issued a cert.
b) I create (and register) my PGP key.
c) I sign a commit with my key.
d) My cert is revoked.
e) Somehow my key is expired.
f) Somehow my commits are now flagged.

Would your concern be addressed by having transparency logs for both the certs and keys?

Sorry, my laptop where I had evolution got a new OS installed and I haven't configured it yet and just started mutt, but my original setup had a local archive folder, with sub-folders per year (I think, I even had a higher level grouping of 5 or 10 years). Unfortunately, I don't have setup right now to check, but I think it was semi-manual, like Evolution was archiving to a local folder automatically, then every new year I just moved the mails from the previous year into a folder).

Re offlineimap, just looked into isync/mbsync suggested here by others, it seems better from the description, I'm probably going to try it when I have some time: https://people.kernel.org/mcgrof/replacing-offlineimap-with-mbsync

I found Ryabitsev's 2019 meditation [0] about maybe using git with secure scuttlebutt interesting (though not terribly compelling). Ryabitsev's fantasy scenario involves a developer exchanging git patches for a particular project via phones, to a laptop. Because that person uses secure scuttlebutt, the bug tracking thread is part of the enabling software, rather than out of band. I am of the impression that Ryabitsev's history as mailing list manager and software patch attestation more likely informed this dalliance than typical web3 inroads.

[0] https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains