Denvercoder9

> you'll encounter a box running a distro version from before /etc/os-release became the standard

Do those boxes really still exist? Debian, which isn't really known to be the pinacle of bleeding edge, has had /etc/os-release since Debian 7, released in May 2013. RHEL 7, the oldest Red Hat still in extended support, also has it.

This misses the point. The reason not to use UUIDv4 is that having an index on random values is slow(er), because sequential inserts into the underlying B-tree are faster than random inserts. You're hitting the same problem with your `public_id` column, that it's not the primary key doesn't change that.

> you have /dev/kmem access so could just edit the kernel data structures.

Not anymore: since kernel 2.6.26 /dev/kmem only exists if CONFIG_DEVKMEM is enabled, and it was removed completely in 5.13.

[1] https://lwn.net/Articles/851531/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Yes, so that's why the compiler can't and doesn't emit the optimized version if you write the short circuited version - because it behaves differently for short strings.

> It did not turn all of this into a SIMD mask or something like that.

Did you try using bitwise and (&), or a local for the struct? The short-circuiting behaviour of the logical means that if `s->a != a`, `s->b` must not be dereferenced, so the compiler cannot turn this into a SIMD mask operation, because it behaves differently.

Generally compilers are pretty smart these days, and I find that more often than not if they miss an "obvious" optimization it's because there's a cornercase where it behaves differently from the code I wrote.

It won't work, the feature set offered by different payment processors differs too much to capture in one consistent API. Even Stripe itself already offers 3 or 4 different ways to integrate with them.

What you want already exists though, and it's called a payment orchestrator. They integrate with different payment providers and provide you one API. You pay for that by getting a much smaller feature set.

That's fine, but it does mean that your current submission title is factually incorrect. You didn't build a payment processor, you build a payment gateway.

Swapping B and 8 in both cases, which is typically something that happens with OCR. Weird.

> Using Vec for arrays is also annoying, repeating the mistake from C++.

Neither Rust nor C++ uses vectors as array, they're distinct things.

An array is a fixed-size object, which never allocates and its elements thus always retain their memory address. In Rust they're `[T; N]`, in C++ `T[N]` or more recently `std::array<T, N>`.

A vector on the other hand is dynamically sized object, that may (re)allocate to accomodate new elements, and the address of their elements can change. In Rust they're `Vec<T>`; in C++ `std::vector<T>`.

> But hasn't all that foundational code been stable and wrung out already over the last 30+ years?

No: a little less than 5 years ago there was CVE-2020-27350, a memory safety bug in the tar/ar implementations.

Apt has just 3 listed maintainers, and judging by the git history this guy does 90% of the work. Him making the decision _is_ it happening organically.

Open source fundamentally is a do-ocracy (it's in literally all of the licenses). Those who do, decide; and more and more often those who do are just one or two people for a tool used by millions.

Perl has been a hard dependency of the base system since forever and it doesn't have a specification nor more than one interpreter.

> Furthermore, if these architectures are removed from further debian updates now, is there any indication that, once there's a rust toolchain supporting them, getting them back into modern debian wouldn't be a bureaucratic nightmare?

These architectures aren't being removed from Debian proper now, they already were removed more than a decade ago. This does not change anything about their status nor their ability to get back into Debian proper, which had already practically vanished.

Even if technically possible, it's unlikely this will be used to support any of the variants you mentioned in Debian. Both i386 and armel are effectively dead: i386 is reduced to a partial architecture only for backwards compatibility reasons, and armel has been removed entirely from development of the next release.

It also has the ability to style mutated variables differently.

> The timing is weird, just after Trump's latest escalation with China.

The news is coming out now, but it actually happened September 30th.

> I assume this is an entirely independent Chinese company without some Dutch sponsor or something.

It's not, it's a Dutch company, formed according to Dutch law, with headquarters in the Netherlands, that was bought by another Chinese company a few years ago.

Dutch law sets rules on how any company, but especially public companies (so-called naamloze vennootschappen) must be governed. Even if you own all the shares, by law you don't have unlimited and unchecked power in the company, you have to abide by governance rules.

Seemingly simultaneously with the government order, a suit was brought to the court enforcing these laws (the Ondernemingskamer) alledging that the CEO and owner were not abiding by them. The court documents are a bit weird to me as a non-lawyer, with Nexperia named as both plaintiff and defendant, so I'm not sure who brought it, but it might've been the government, who are named as a party.

The court agreed that the suit could have merit, and as an interim measure while the legal proceedings play out, has suspended the CEO and named a temporary director. It also suspended the authority of the owners over their shares (except for one), and assigned a trustee to manage them temporarily. The court did not actually rule on the contents of the suit yet, it only issued interim conservatory measures. We'll likely hear more about how the suit plays out over the next few months.

An interesting matter of contention in the suit is that the CEO/owner want the CLO to be suspended, while the other side asks the court to prohibit firing of the CLO. I presume there has been a conflict in the board, either leading to or caused by the government order.

The court documents are public by the way (in Dutch, obviously): https://uitspraken.rechtspraak.nl/resultaat?zoekterm=nexperi...

> when you work in gardening half the time is cleaning (leaf blowing, hedging and mowing)

How much of this is just to make things look nice, as opposed to actually functional?

> In AT, data is tied to identity (DID), not handles or hosting.

But there's exactly two types of identity, one of which requires you to have a domain (did:web:), and the other relies on a centralized registry owned by a third party (did:plc:). Still the exact same problem.

That only works if you make the airplane enough bigger so that you can fit more seats and thus paying passengers. The parent comment was arguing to make the plane only a little bigger so that each passenger has more space, but not enough so that extra seats can be fitted.

There's no incentive. Passengers rarely know what type they'll be flying on when they book, and prioritize it over price even less. For airlines, a bigger airplane is a distinct disadvantage though, as it's operationally more expensive (increased cross section equals increased drag equals increased fuel burn).

bcachefs in the upstream kernel was explicitly marked as being experimental, you can't consider it a stable release.

> Both should be supported.

At least in KDE they are, and you can pick whether you want natural or alphabetical sorting (which has a case sensitive and insensitive variant).

Only to obtain the token, the actual connection itself uses HTTP authentication (Bearer scheme).

> Do you open your browser, log in, and then somehow transfer the session into your ssh client in a terminal?

You start the ssh client in the terminal, it opens a browser to authenticate, and once you're logged in you go back to the terminal. The usual trick to exfiltrate the authentication token from the browser is that the ssh client runs an HTTP server on localhost to which you get redirected after authenticating.

To be clear, this is about the internal implementation in the kernel, the mmap() system call is not going anywhere.

If you want a POSIX OS, nommu Linux already isn't it: it doesn't have fork().

The common answer here is that they should destroy them instead.

> What is the cap of throughput is due to these speed limitations is an exercise left for the author of the article.

They already did that exercise:

> 3-car trains running at 30-40 trains per hour (a normal peak frequency for automated or even some human-driven metro lines) reach a capacity of about 18,000 passengers per hour per direction, well above the expected demand of any American line that doesn’t go through Manhattan.

Shipping separate debs is usually the easiest, but not the only solution. It's totally possible to build something that's compatible with both ABIs.