Kernel.org People

A while ago I saw Linux kernel people[0] using Writefreely[1] so I tried it and I've been using it ever since. It's a bit clunky, initial Docker based deployment is not straightforward, but I like it. It's using Markdown, supports ActivityPub out of the box, and has static blog feeling even though it's not. [0] https://people.kernel.org/ [1] https://writefreely.org/

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-… 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?

Pixelfed is evolving quite fast. I am using it since soon one year. The community just needs more users and more instances. ActivityPub is really on the raise. I saw recently that https://people.kernel.org is using WriteFreely.

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 think you're overstating this. The "handshake" is purely 2 simple resistors correctly installed. The problem is a lot of folks do it wrong for various reasons, most likely never testing with anything more than type a to type c cables. https://people.kernel.org/bleung/how-to-design-a-proper-usb-c-power-si…

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

There are tools to import mails into whichever email client you prefer, especially if the list is archived on a public-inbox instance, which is the best mailing list archiving system so far. https://lwn.net/Articles/875239/ https://blog.gnoack.org/post/lei/ https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started https://b4.docs.kernel.org/ https://github.com/mikwielgus/forum-dl

Unfortunately this makes a mistake by using a short commit ID: "(e.g. a5b3abf)" That's not a full commit ID, so it can still result in a mutable reference if either someone can find a clash[1] or if they can push a tag with that name and it takes priority in the context it is used (this is somewhat complex, e.g. GitHub prohibits pushes of branches and tags which are exactly 40 hex characters long, but other services may not). [1]: https://people.kernel.org/kees/colliding-with-the-sha-prefix-of-linuxs…

https://people.kernel.org/kees/colliding-with-the-sha-prefix-of-linuxs… is the actual link; the lwn article is just a link to it with a one sentence summary and a short quote.

I looked into this a bit further and it seems to be a range from [0,50]. [1] explains that if there is a pre-existing timer interrupt at 0, then the queue will be resumed at 0. But yes - given no other timers it will resume at 50. 1. https://people.kernel.org/joelfernandes/on-workings-of-hrtimers-slack-…

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-s…

This could have been as well been a prediction 8 years ago, because in the mean time all of this happened. regarding 1) look at this post from 2019: https://people.kernel.org/bleung/now-how-many-usb-c-to-usb-c-cables-ar… I imagine it only got worse in the mean time. regarding 2) I have seen various posts in the past of devices that only work if the cables are connected in a specific orientation. Technical background is discussed here: https://acroname.com/blog/why-usb-c-connections-sometimes-dont-work

That exists. It's called an e-marker and you can buy testers for about $60 that will read it for you. If a cable doesn't have one of those markers then odds are it can't handle over 5 amps or USB 2.0 speeds. It is kind of annoying that that functionality isn't built into phones and PCs though. There was some talk about building support into the Linux kernel[1] but it doesn't seem like that went anywhere. [1]: https://people.kernel.org/bleung/now-how-many-usb-c-to-usb-c-cables-ar…

Last time I checked it was only for maintainers convenience but the idea of using it by some tooling was already being discussed: https://people.kernel.org/monsieuricon/all-patches-must-include-base-c…

Well, the article is from 2008. Nowadays, Smart NICs can handle encryption and IOMMU provides (some) security isolation. The sendfile() syscall uses these if available. (https://people.kernel.org/kuba/tls-1-3-rx-improvements-in-linux-5-20) I never used Kafka. I'd expect that using Cloud HSM for TLS/SSL offloads in any cloud should get you zero copy with encryption.

Why should I trust the Arch wiki? People like Christian Brauner think the value of not running as UID 0 outweighs the increased attack surface from the user namespace. https://people.kernel.org/brauner/runtimes-and-the-curse-of-the-privil…

Part 2 is at [1] [1] https://people.kernel.org/linusw/setting-up-the-arm32-architecture-par…

Did some more research. I don't have a linux system with usb-c rn, but one can maybe query the emarker VDO in sysfs: https://people.kernel.org/bleung/ On windows there are the MUTT tools, but looks cumbersome: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/ucsi

More detail on the mess https://people.kernel.org/bleung/now-how-many-usb-c-to-usb-c-cables-ar…

So, the 'linusw' in the link[1] means it's an article of Linus, or some people else also named Linus? [1] https://people.kernel.org/linusw/how-the-arm32-kernel-starts

I don't think they have a rigid system, but this post indicates that they try to make it the last release of the year: https://people.kernel.org/gregkh/next-long-term-supported-kernel-relea…

To be honest even PGP signing has some issues: it's not clear what does it mean to sign a commit and there is plenty of misuse of that (see [0], `git push --signed` solves some of these issues). Git patch workflow doesn't support signed commits and some kernel devs explore alternative ways of signing [1]. [0]: https://mikegerwitz.com/2012/05/a-git-horror-story-repository-integrit… [1]: https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attest… By "keybase providing alternative" do you mean that they have hosted, encrypted git repos?

If we end up with a project like [1] actually taking off, then with Secure Scuttlebutt you wouldn't need to care about server hosting and the pub servers could be distributed globally. [1]: https://people.kernel.org/monsieuricon/patches-carved-into-developer-s…

> with so many possible variations full feature cable can have problem listing all the features There are only six variants: https://people.kernel.org/bleung/how-many-kinds-of-usb-c-to-usb-c-cabl… And it's actually the product of three variants (2.0 only, 5 Gb/s, 10 Gb/s) by two maximum current ratings (3A, 5A), so a pair of logos would be enough.

Looks like rss feeds are per blog, so just append /feed/ to any author's blog root. I can't find a mechanism to get a feed with all authors content however. Ex: https://people.kernel.org/monsieuricon/feed/

That works, thanks. As does: https://people.kernel.org/read which seems to have more articles.

Perhaps https://people.kernel.org/read/feed/ Searching github repo for "feed" helped. https://github.com/writeas/writefreely/blob/ac7d72743515fdd7ccbe172d01…

> 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…

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…

It should eb at https://people.kernel.org/monsieuricon/feed