> If you use Caddy that's even the default behavior - it tries ZeroSSL first and automatically falls back to Let's Encrypt if that fails for whatever reason.
Which makes sense, since the ACME access to ZeroSSL must go through an account created by a manual registration step. Unless the landscape changed very recently, LE is still the only free ACME that does not require registration. Source: https://poshac.me/docs/v4/Guides/ACME-CA-Comparison/#acme-ca...
My bad, I misremembered the order. You're right that ZeroSSL requires credentials to get free certificates, but Caddy has special-case support for generating those credentials automatically provided you specify an email address in the config, so it's almost transparent to the user.
1. Die Wand (1963, Germany). The Wall. Marlen Haushofer.
An excellent novel, simple, yet moving. Why do we live and what is our connection to nature?
2. Fifth Business (1970, Canada). Robertson Davies.
I've read thousands of novels, so I'm always glad to read something new and unpredictable, but still based on the best premise: interesting characters.
3. Sostiene Pereira (1994, Italy). Pereira Maintains. Antonio Tabucchi.
My favorite book this year. A deep and smart and tense plunge into the Portuguese life of a few decades ago. Italian literature has so many gems.
I've read at least two articles authored by historians that thought this book was full of factual errors and misunderstandings. One of them had studied Eichmann's life and correspondance, and found that he was far from the character that Hannah Arendt depicted. IIRC, the other article tried to explain her bias; I remember she hated Jerusalem and despised most people she met in Israel.
It may be good read, but don't expect the book to be fair or truthful.
>I've read at least two articles authored by historians that thought this book was full of factual errors and misunderstandings.
Feel free to provide these citations if you dislike the book
>It may be good read, but don't expect the book to be fair or truthful.
It's creative nonfiction -- a literary telling of a factual event. And no one is required to be "fair" to anyone, especially Nazis. Some things don't have "both sides".
Your mileage may vary, because the workflow you described does not suit me. I rarely want to put on hold my commit, work on a new one, then go back later to the former commit.
Most of the time, when working on a new commit I have a few changes related to recent commits. So _when I'm done with all that_, I commit selectively the new work, then dispatch the rest among the other commits:
git add -p ; git commit
git add -u ; git absorb
Sometimes, I use `commit --fixup` instead of the automatic `absorb`. Anyway, I tried Jujutsu for a few weeks, some was good and some was bad; it didn't "shine" enough and I went back to pure Git.
So they suggest to write scripts in Python rather than shell because Python is stable, probably installed on the target machine, has a big standard library, and is more readable. Many people do so.
That's the bright side of Python. They should mention the dark side, or Why _not_ to use Python for scripting.
First of all, the promise of easy portability breaks as soon as the script has dependencies. Try to install some Python program on a server where you're not root and a minimal python3 is installed.
The stability isn't very good in my experience either. I've often seen programs not compatible with recent releases of Python, either explicitly in the README or implicitly at runtime. Unmaintained Python code breaks.
Unfortunately, there is no silver bullet. Posix shell or bash may be better for simple scripts; Perl or Python if you know you won't require dependencies or if you have a good control on where to install the script; languages that compile to static executables are not really "scripting", but may be a better choice for long(term usage. These past years, I tend to keep away from Python as much as I can.
> First of all, the promise of easy portability breaks as soon as the script has dependencies.
And bash has a good dependency story? At least with python you can bundle your script with a requirements.txt file and it is doable for the target machine to get up and running.
What was unclear in that article is that the XML is usually embedded in the invoice. For instance, Factur-X is the mandatory format in Germany, and it's a PDF which contains a metadata block with a XML EN16931 content.
This XML will usually not be read by the companies that pay the invoice. For instance, in France by the end of 2027, every business will have to send e-invoices, but never directly to the real recipient. The business sends the invoice to a registered go-between, which will ask a national platform for the address of the recipient's go-between, etc. So, only those official go-between companies will have to securely parse the XML.
BTW, in 2022 when the French government decided to make e-invoicing mandatory, it announced that it would develop a national unique go-between platform. Two years later, it dropped that part of the project and announced that there would be an official list of private platforms. So, by the end of 2026 or 2027, every French business will have to select one of the 112 platforms and buy a subscription. It give the State more control, but for small businesses it means higher costs and complexity.
Your statements about Germany are not correct: Factur-X is not common in Germany at all, the German version of this standard (albeit very closely related to Factur-X) is called Zugferd and it is by no means mandatory in Germany.
Actually, most governmental agencies (which have required e-invoices for many years), only accept the pure XML files. Zugferd is a bit of an interim solution until everybody is familiar with an e-invoice visualizer. There are already many free (as in beer and source) solutions available for that. Zugferd (X-Factur) is a problematic standard, because there can be discrepancies between the PDF and the embedded file and its unclear, which is authorative. Concerning the platforms: I don't know about France, but in Germany, sending e-invoices by e-mail is explicitly permitted by the government.
So, a handful of persons "believe that OpenStreetMap is a creation of Chinese communists" and are removing specific data from OpenStreetMap, and the OP explains why this is stupid but innocuous.
But that's not the first time that a community is tagged "Chinese communists" and attacked as such. Now imagine if some maga/alt-right/whatever leaders asked their followers to attack the "communist" OpenStreetMap by injecting a bit of false data everyday. Could OSM defend itself as easily?
> Codeberg is a fork of Gitea, itself a fork of Gogs.
Codeberg is a website powered by Forgejo which is a fork of Gitea.
> Both forks originated for "philosophical" reasons, not technical ones
Gitea forked because one developer was the only owner of Gogs' repository and refused to share maintaining rights. The fork was more "practical" than "philosophical".
Forgejo forked when a leading developer secretly created a company with the trademark of Gitea and its logo. The fork was to gain back control over the assets of the project (name/trademark, logo, etc.).
Seems like a 'you either die a hero or you live long enough to become the villain' type of behaviour, which is not uncommon to see in projects like these. Let's hope Codeberg doesn't end up in the same bucket.
That's the reason I don't want to jump on the Codeberg bandwagon just yet, although I'm very interested into self-hosting Forgejo.
I'd love to see something else though, a way to have repositories discoverable across all possible centralized or self-hosted services out there. What I actually do love about GitHub is that from time to time it manages to find for me some quite interesting projects and people to check out.
To note, Codeberg is set up as an _eingetragener Verein_ and has the charitable status, so it's a non profit and the leadership must be elected by the members.
KDE has a similar structure with KDE e.V.
Adding new functions and alternative syntax has a long-term cost for PHP and the projects that use the language. I don't see much value in the new features of PHP5 announced on https://www.php.net/releases/8.5/en.php
- URI extension: there was already the internal `parse_url()` which was imperfect, and alternative libraries that were RFC 3986 compliant. An official extension will bring speed, but now there will be 2 official ways to parse URLs.
- The pipe operator is a matter of taste. In the release notes, the new code is more verbose, because it defines anonymous functions. This alternative syntax means keeping a consistent code style will be harder.
- The update of "clone" replaces 2 lines of code in some cases. Unless I misunderstood, it's a very minor change.
- The #Discard/void will replace the similar feature from static analyzers.
- Closures in constants is one of the 2 features that bring more than an alternative syntax. It's one more little step toward a preprocessor. But I'm not thrilled about the future #attributes assigned with complex closures.
- cURL persistent handles are a real performance feature, because curl_init() is costly.
- array_first() is a minor syntax-sugar. In a project of 100k+ lines of PHP, I probably could use it twice or thrice. Was it worth a global function?
The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.
> The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.
I'm glad it's not just me who finds the syntax of some of the new PHP features confusing and complicated. And it's not just this version either, they keep adding weird "sugar" in each new release.
No, that's false. It's the other way around.
“If Caddy cannot get a certificate from Let's Encrypt, it will try with ZeroSSL”. Source: https://caddyserver.com/docs/automatic-https#issuer-fallback
Which makes sense, since the ACME access to ZeroSSL must go through an account created by a manual registration step. Unless the landscape changed very recently, LE is still the only free ACME that does not require registration. Source: https://poshac.me/docs/v4/Guides/ACME-CA-Comparison/#acme-ca...
reply