Is there a generic (non-brand) name for these boiling-water faucets? (That’s not a mouthful like “boiling-water faucets”). I think we call them quookers here, which is also a brand name, and I slightly dislike that practice. I mean, “brand name for generic thing” is very common, but the brands and things differ per country, so it’s like a layer of jargon to decipher.

Put that thing back where it came from, or so help me…

Extrapolated from the relevant information in the post (a single data point), that is a solid hypothesis.

I do my time tracking in org-mode, and export it to JIRA once a day or so. It is quite a specific/tailored setup, written in a mix of elisp and, well, org-mode (specific names and tags are used to configure some settings), but I’d love to look at this tool to see if I can extend my workflow by using it for the “massaging into a nicer shape” part. I might end up writing some extensions for either side (org-mode input format and JIRA REST calls output format).

My current tooling quantizes everything by rounding start and end times to the nearest full 15 minutes, and starting a new task at the end time of the previous one when clocking in, so that my team lead does not have to report so many fractions of hours to higher layers.

I hear the GOAT is even better.

No need. Only the average Dutchman. And he’s only average, so…

That fills me with determination.

Probably understood that in the wrong direction. Ze (eng. phon.) would be spelled more like “sie” (ger. phon.) and would sound like “the” with a German accent. They would become either dey (eng. phon.) or zey (eng. phon.), spelled like “deej” or “seej” (ger. phon.), or even without the y (or j) at the end.

I think. I’m neither native German or English.

I think there might be a bit too much complexity in the bot.

That is an interesting source. Thanks for the link!

That’s why you feed that flame once in a while.

This is still salvageable by pronouncing it as “an earl”.

I agree, and I love how it has these younger words with a vivid etymology, how it shares so many common roots with English, German, the Scandinavian languages, and a serving of French, but also sprinkles of many other languages from its seafaring and otherwise trading history. And I love the grammar rules that allow one to be precise and concise in many things (but there we must definitely bow to German).

Water bearer makes much more sense, thanks! I did notice the images where a guy carries a jug, but as a kid, I always imagined the water man to be some kind of elemental, and I never consciously challenged that idea. Haha.

In Dutch we don’t use the Latin names for zodiac signs (and we call them “sterrenbeelden”, which means “star images” or maybe “star statues”). Aquarius is “waterman”, which I guess would translate to (surprise) “water man”.

Why? Not sure, but it might be because of Simon Stevin who insisted we use Dutch words for mathematical concepts, and thought up some words like “evenwijdig” (“same distancey”) for “parallel” and “wiskunde” (“certainty knowledge”) for mathematics.

Yet.

I would guess this would link to https://github.com/CyberRoute/scanme maybe. Or a comparison document with nmap?

👏👏👏👏

I like that I can hear that omitted space there.

git was designed to be decentralized. Everyone can (technically, but it is not too hard to set up if you have some affinity with servers) fork/clone another git repository and serve it up. It has built-in ways to synchronize with any other server. In fact, that synchronizing is what most developers do when they use git.

Of course, that would make it harder to know which repository has the “official” version, but in a way, that is maybe also a benefit of decentralisation. Knowing what code is authentic can be done by signing the commits.

The hubs that we see, are usually a combination of git and a way to serve the code, along with documentation, roadmap, bug tracking, automatic testing and building and the resulting binaries in a visually pleasing way. That does not need to be a part of decentralizing the code, and it is not the only way to do it.

Some of that can also be done with git built-in tracking of files, and the building and testing can probably also done in other locations, as long as there are files describing how to do that bundled with the code (which practically all projects already do).

Sourcehut (https://sr.ht) is one hub that helps developers use simpler tools for those workflows, and I think that’s a good place to find some inspiration.