tkfu

If you're the sole copyright owner, you can offer as many different licenses as you want, and no copyleft license can interfere with that.

Yikes.

I'm having trouble imagining who would want to use this. What's the environment where you would have curl and a need for generating UUIDs, but wouldn't have access to uuidgen or similar?

Is there any concept of a distinction between the size of the line of credit you're willing to extend to a person directly, and the credit you're willing to extend to that person's friends (and friends-of-friends, etc.)?

Most of the time, if a friend asks for a loan (unless it's a really trivial amount), my response will be along the lines of "Sure, what do you need it for?" If my sister asks me to lend her 500 euros because she's short on rent, I'd say "Yes, of course!" But if she asked me to lend her 50 euros because her smack-addict downstairs neighbour really needs it to fix their sink (my sister's a soft touch who likes to help people and always gives folks the benefit of the doubt), I'd say hell no.

David Graeber went into a lot of the issues around this in his book "Debt: The First 5000 Years". The element of debt that's monetary and recorded in ledgers is only half of the story. Most of the truth of how we relate to debt is much more socially intertwined.

Good for them! When it was first pointed out to me that these terms feel harmful for many, I rolled my eyes a little bit. But after thinking about it for a while, a few things became clear:

(1) There's no particular reason to start using the terms in a new project

(2) Leader/follower is much more accurate and clear than master/slave in basically every way

(3) It's a lot less difficult than I originally thought to fix legacy docs and code with nicer language

(4) The fact that master/slave has never bothered me personally has absolutely zero bearing on whether I should support their continued use.

You've got a pretty simplistic view of freedom there, bud. Regulations often increase freedom for some while decreasing it for others. Constitutions are just regulations for government--does preventing the government from infringing on the right to free speech, for example, increase or decrease freedom?

Employers have immense power over their workers, and regulation is one of the tools societies can use to make sure that power isn't abused.

Slightly off-topic here, but you might like the tdlr project[1]! It's community-maintained, example-focused documentation for common command-line tools. Currently, there are over 1700 pages, and it's very easy to contribute new pages or improve existing ones, because it's all in simple markdown on github. (For example, [2] is the source for the tar page.)

[1] https://tldr.sh/

[2] https://raw.githubusercontent.com/tldr-pages/tldr/master/pag...

That's a really bad proofreading regex, though, because it will be wrong more than a third of the time--which is much, much higher than the expected real spelling error rate. The "i before e except after c" rule only has a high success rate when you add the caveat that it only applies to words where the ie or ei makes the sound [i:] (like in "believe", for example), and that caveat isn't expressible via regex.

Antora's cross-reference feature[1] might be what you're looking for. It also has the very, very useful concept of content catalogs; it's an SSG for documentation sites.

[1] https://docs.antora.org/antora/2.2/asciidoc/page-to-page-xre...

Bit of a bad look that I can't search the docs using typesense.

Also, I find his case that notation option A is best to be extremely unconvincing. He just lists 2 properties that he thinks are good:

0. Subtracting the lower bound from the upper yields the length of the sequence.

1. For adjacent sub-sequences, the upper bound of the lower sequence will equal the upper bound of the lower sequence.

One could just as easily argue for option C (a ≤ i ≤ b) by pointing out that

0. It's much closer to natural language ("all the numbers from a to b"), and thus less likely to be casually misunderstood.

1. It uses the same inequality symbol twice, making it quicker and easier to understand.

2. If either of the bounds of one sub-sequence is inside the bounds of another sub-sequence, those two sub-sequences overlap.

> %90 of this "malware library" problem too would have been avoided if package repositories just required all packages to be signed with keys on hardware dongles.

I'm with you about requiring signatures, and you can get around the FUD about packages getting abandoned because of developers losing keys by implementing something like TUF[1] (because of delegations in the targets role), but I don't really see how you can enforce dongle usage. That is, how can the repository administrators tell the difference between a signature from a key on a hardware dongle and a signature from a key on somebody's windows laptop? You'd need an IRL auditing process, which just isn't feasible for most open source packages.

[1] https://theupdateframework.github.io/

It's not used directly in a lot of places. However, it's still used in a lot of publishing toolchains as an intermediate format, usually compiled from asciidoc via asciidoctor[1]. O'Reilly books, for example, are all written in asciidoc and then run through a publishing toolchain that goes through asciidoctor to docbook, to eventually get rendered into printable formats as well as PDFs.

[1] https://asciidoctor.org/

There's a line in there that I find a bit jarring and difficult to parse. I understand that this was written in 1975 (Not long before I was born, but nonetheless an era that I can't really say I understand), but when the author mentions this:

> The waitress told us he drew sketches of the faculty he did not care to eat with. She said they all had long noses.

...it sets off strange alarm bells, but I don't quite have the cultural context to figure out how I should interpret it. Of course, everyone knows that long noses are a Jewish stereotype, and that in the 70s when this article was written, anti-semitism was far enough out of fashion that it would have been impolite to express it in more than an oblique way. Can someone explain to me what MacLean was trying to say here? I know Michelson himself was of Jewish descent, which makes the comment all the more confusing.

I'm a bit confused, here. (I went and looked at the original paper.) They estimated information density for each of the subject languages as a whole, on average:

> In parallel, from independently available written corpora in these languages, we estimated each language’s information density (ID) as the syllable conditional entropy to take word-internal syllable-bigram dependencies into account.

But the experiment uses the same text translated into each language! Why introduce this extra variable (and source of error) of estimated language-wide information density, if you are controlling your experiment such that you have the exact same information encoded in each language? That is to say, why use an _estimated_ information density when you could measure it exactly for the texts that are being spoken? Or, conversely, why go to all the trouble of having the speakers read the same text translated into each language, if you aren't going to make use of that symmetry?

> The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters.

There's a really fascinating project by the authors of TUF called in-toto[1] that addresses exactly this problem.

[1] https://in-toto.github.io/

In the 80s and early 90s, when the vast majority of people with access to the internet were university students, there would be an influx of new users every September to usenet discussion groups--users who didn't understand the rules and conventions of the space. September was the time when every newsgroup would go to shit for a while, and we'd have to educate the newbies. "Eternal September" was a term coined when internet access started arriving for everybody in the mid 90s; there was a constant influx of new users.

It would seem that the commenter above thinks that HN is not that well-known, and getting linked from boingboing is going to lead to an influx of newbies. I think that's pretty silly, personally; these days HN probably has a significantly wider readership than boingboing.

That's not a spec, and it doesn't claim to be one. It's the syntax description that I referred to above. A spec needs to unambiguously <em>spec</em>ify the grammar.

Markdown doesn't have a spec. There's a "syntax description", which leaves a lot of ambiguities, and the original Perl script, which you could consider a reference implementation. But there certainly isn't a spec.

(Or, alternatively, there are several competing specs, like CommonMark, Standard Markdown, and GitHub-flavoured Markdown. But your comment seems to be suggesting that there's one authoritative spec, which there definitely isn't.)

> While it is possible to encrypt certain emails in Gmail with GPG, Google can still read all email meta-data such as email addresses and subject lines. Better use a Gmail alternative that encrypts your entire mailbox and contacts automatically.

This is nonsense. Any email service will be able to see the recipients (and senders) of your messages, because that's how email works. Subject lines too, again, because that's how email works.

E2E encryption of email is a good thing, GPG is hard. These things have be true forever.

Interesting; I have basically the exact opposite experience. I had a T460P (running Linux) that I loved as my work computer, and then my company got acquired and I had to choose between a gigantic brick of a Dell or a Macbook, so I decided to try a mac for a while. I absolutely hate it: the keyboard needs to be blown out with compressed air all the damn time, plugging in external monitors is a total crapshoot, the touch bar thing just sucks, having only USB-C ports is a pain, and every fuse filesystem is insanely slow.

Just a quick tip, if you are interested in Yocto, and especially Yocto on the Raspberry Pi: there's a layer called meta-updater[1], originally developed for Automotive Grade Linux, that lets you add over-the-air updates to your Yocto-built systems, and it supports Raspberry Pi. It uses OSTree[2] to give you atomic updates and nice, small update sizes. (The whole filesystem is a content-addressed object store that's hard-linked into the actual directory structure at boot time.)

There's also a guide[3] for doing this using HERE's servers for delivering your updates. It's free to use, but if you prefer a free-as-in-speech solution, you can either ignore the update client and run the updates yourself from a bare OSTree repo, or run the open-source community edition[4] of HERE's server software.

(Full disclosure: I work for HERE, and wrote the quickstart guide[3] I'm linking.)

[1] https://github.com/advancedtelematic/meta-updater/

[2] https://ostree.readthedocs.io/en/latest/

[3] https://docs.atsgarage.com/quickstarts/raspberry-pi.html

[4] https://github.com/advancedtelematic/ota-community-edition/

I'd argue that (1) manpages are for humans to read, and (2) there is effectively only one presentation style for the conveying the semantic contents. So as long as the author of the manpage follows the standard conventions for manpage presentation style, they are in fact expressing the semantics. And it's a lot easier to learn the conventions (flags in bold, arguments in italics, etc.) and write them in lightweight markup than it is to learn roff.

roff is quite horrible to read and write. There's a much better solution than banging your head against an archaic and unforgiving file format: AsciiDoctor's manpage backend [1]. You write in asciidoc, with some required structure that's quite easy to follow, and it spits out a proper roff document for you. Asciidoctor's own manpage [2] is, of course, generated in this way, and it's a pretty good example of the form.

[1] http://asciidoctor.org/docs/user-manual/#man-pages

[2] https://raw.githubusercontent.com/asciidoctor/asciidoctor/ma...

"Biggest foreign creditor" and "biggest creditor" are worlds apart; it's not just about being more precise. More than two thirds of US debt is held domestically.

That's kind of the heart of what's wrong with it. People generally agree, for example, that it was a good thing when we banned the practice of selling ones' self into indentured servitude. It is almost certainly true that indentured servitude was "worth the cost/risk" for some of the people who signed up, but we make it illegal anyway because it sets up a situation where people are likely to be exploited. Same goes for, for example, selling kidneys.

But it's impossible to prove that a smart contract (or any contract, for that matter) is in compliance with the law until it goes in front of a judge and all possible appeals have been exhausted, and that's what matters here.

There's a lot wrong with this argument. First of all, a primary concern when buying insurance is proof of the solvency of the insurer. That means the insurer has to hold the capital covering their outstanding risks. So any insurer that can prove solvency also has to sit on a ton of capital instead of using it productively, which means the minimal insurance cost of a contract is going to be value * (risk + r * time), where r is the expected rate of return on capital.

Adding on N redundant insurance contracts increases the total cost of insurance by N * value * r * time, assuming that the risk of insuring another insurance contract is extremely low. That number explodes extremely fast, and there's no obvious way to solve the problem apart from buying insurance without blockchain-based proof of solvency. But if you're doing that, why do it on the blockchain at all?

I'm not sure I buy the embedded/IoT use case; OSTree is a really good model there and is more featureful. The "well, if your filesystem image delta happens to be in the form of a lot of very small files it's not so great for CDNs" doesn't strike me as a terribly good reason to give up everything OSTree gives you (especially with stuff like the meta-updater [1] Yocto integration).

[1] https://github.com/advancedtelematic/meta-updater

(Full disclosure: I work for Advanced Telematic, the creators and maintainers of the meta-updater Yocto layer.)

Asciidoc is wonderful, especially with Asciidoctor, which has now become the de-facto standard renderer. (It's what github uses, for example.)

It's as easy as Markdown (and the syntax is so similar it's not hard to switch), but just has much better design, along with supporting the features you need once you start having enough documentation that you need an actual tech writer. Plus, it's still just plain text, so it plays nice with Git and is thoroughly readable without being rendered.