codys

nixos is an example of a distro that is source based and can do the atomic rebuild here because it has a way to build packages against other packages that aren't "installed". In nixos, this is because there are very few things that get "installed" as the global, only thing to use. But one could imagine that Gentoo could build something that would allow them to at least build up one set of new packages without installing them and then install the files all at once.

Yep, agreed. Though it does expose an option here which would be "have glibc provide a mechanism for other libraries (likely more core/widely used libs) to support both ABIs simultaneously.

Presumably if that had been done in glibc when 64-bit time_t support was added, we could have had multi-size-time ABI support in things like zlib by now. Seems like a mistake on glibc's part not to create that initially (years ago).

Though if other distros have already switched, I'd posit that perhaps Gentoo needs to rethink its design a bit so it doesn't run into this issue instead.

Nixos has it easier here because they don't require packages to be "installed" before building code against them. For Gentoo, none of their build scripts (ebuilds) are written to support that. It's plausible that they might change the embuild machinery so that this kind of build (against non-installed packages) could work, but it would need investigation and might be a difficult lift to get it working for all packages.

"treat it as a cross compilation scenario" is essentially what the post discusses when they mention "use a different CHOST". A CHOST is a unique name identifying a system configuration, like "x86_64-unknown-linux-gnu" (etc). Gentoo treats building for different CHOSTs as cross compiling.

There are a few options for Gentoo not discussed in the post, possibly because for Gentoo they would be a larger amount of work due to the design of their system:

1. Allow building against packages without installing them. The core issue here is that Gentoo package build and install happen as a single step: one can't "build a bunch of things that depend on one another" and then "atomically install all the build items into place". This means that Gentoo can easily be partially broken when one is doing updates when an ABI change occurs (modulo so versioning, see next option). This issue with 64-bit time_t is an example of an ABI change that folks are very aware of and is very widespread. It's also an example of something that causes an ABI change that isn't handled by the normal `.so` versioning scheme (see next option).

2. Extend the normal `.so` versioning to capture changes to the ABI of packages caused by packages they depend on. Normally, every `.so` (shared object/library) embeds a version number within it, and is also installed with that version number in the file name (`libfoo.so.1.0.0`, for example, would be the real `.so` file, and would have a symlink from `libfoo.so` to tell the linker which `.so` to use). This shared object version is normally managed by the package itself internally (iow: every package decides on their ABI version number to enable them to track their own internal ABI breakages). This allows Gentoo to upgrade without breaking everything while an update is going on as long as every package manages their `.so` version perfectly correctly (not a given, but does help in many cases). There is a process in Gentoo to remove old `.so.x.y.z` files that are no longer used after an install completes. What we'd need to do to support 64-bit time_t is add another component to this version that can be controlled by the inherited ABI of dependencies of each `.so`. This is very similar in result to the "use a different libdir" option from the post, but while it has the potential to set things up to enable the same kinds of ABI changes to be made in the future, it's likely that fixing this would be more invasive than using a different libdir.

> there would be inconveniences like libc.so has 64-bit off_t

glibc specifically has support for the 32-bit and 64-bit time_t abi simultaneously.

From the post:

> What’s important here is that a single glibc build remains compatible with all three variants. However, libraries that use these types in their API are not.

iOS has limited extra settings for notifications that are "time sensitive" and "direct messages", mostly to allow excluding them from notifications summaries and sending them immediately. It doesn't have the same rich/extensive notifications channel support android has.

In practice, apps also abuse the channels and tag things as (at least) direct messages when they are not.

Android is much better in notification config flexibility vs iOS.

One thing to be cautious about with cake/fq_codel is that many consumer routers aren't fast enough to run it at line rate for current "fast" networks, so that enabling it those routers effectively caps the throughput lower than any limit you set and likely has unexpected effects elsewhere (potentially increasing latency issues instead of reducing them).

> But I recall reading elsewhere a discussion about some userspace program which did depend on holes being present in the filesystem as actual holes (visible to SEEK_HOLE and so on) and not as runs of zeros.

"treatment of on-disk segments as "what was written by programs" can cause areas of 0 to not be written by bmaptool copy":

https://github.com/intel/bmap-tools/issues/75

IMO, the issue here isn't filesystem or zfs behavior, it's that bmap-tool wants an extra "don't care bit" per block, which filesystems (traditionally) don't track, and programs interacting with filesystem don't expect to exist.

Some of the comments I've made in this issue describe options to make things better.

(FWIW: the original hn link discusses a different issue around seek hole/data, and the bmap-tool issue is backwards from the issue the parent posits: bmap-tool relies on explicit runs of zeros written not being holes, and particular behavior from programs writing data)

The things you've described are either not required or often considered bad style in C even though they are valid C.

Casting to/from `void *` isn't needed in C, and is commonly against coding conventions, like those used by the Linux kernel.

One would generally return `NULL` instead of `0` as `void *`.

But yes, it is possible to write some funky C code that could be technically correct but still not be considered good.

Sure, you're right, it's just not really relevant here.

Nothing stops that. You'll end up getting a message full of 0 bytes (messages are fixed size) if it closes between the `closed()` check and the `receive()` operation. Common designs in this space instead indicate if the receive call has obtained data (return values typically indicate this). This is a kind of time-of-check/time-of-use bug.

Go, for its part, has its receive operation, `<-`, return a status indicating if the channel is still open, as in `v, ok := <-ch`

When folks talk about namespaces, structs, & typedefs in C, it's to call out that `struct X` and `typedef int X;` can both exist at the same time. In other words, nothing prevents one from doing a `typedef struct X { int f; } X;` or similar, using `X` as the name in both places.

It is true that it's more correct to say "struct names have their own namespace", though I think we can infer what's actually meant here fairly easily.

To add a bit more context here, the "12 US State Attorney Generals" here are 14 Republican US State Attorneys general.

their letter: https://content.govdelivery.com/attachments/IACIO/2023/12/04...

edit: actually not RefCell. That's more Mutex like. Which is another place rust solves: the tooling for eliminating data races at compile time is mature and pretty complete. The race elimination in Ada appears to rely on using SPARK (as noted elsewhere: not universally used from others experiences), but I'm not too familiar, possible I'm wrong there.

For the case of "smart pointers", and the larger point of "safety": rust has that included out of the box: Box, Rc, Arc, RefCell are all smart pointers included in the standard library. On safety of the language: the borrow checker exists, move semantics are the default (ie: included in the language) and copy is explicit, and real programs that isolate unsafety effectively (ie: so it doesn't need to be known outside of the module it exists in) are common.

Severance pay is not last-paycheck pay. Paycheck pay is for work already performed. Severance is (in the US) generally down to agreement between an employer and employee (and the employer normally dictates the terms because the employee in most cases lacks a bargaining position) or as a way to comply with laws mandating notice periods for layoffs.

McCauley's linkedin: https://www.linkedin.com/in/tasha-m-25475a54/ . From some digging, full name appears to be Aimee Nastassia 'Tasha' McCauley, and is married to Joseph Gordon-Levitt (the actor).

I'm not sure how one would define "adaptation" (presumably meaning "adoption", ie: how widely used something is) in a way that could have debian have a higher adoption than rust: rust ships in programs within many linux distributions and other operating systems (mac os and windows). rust is used in widely used programs/kernels (Firefox, Chrome, Linux itself, Windows) that span further than debian itself.

All this is to say: a large amount of debian users likely are using rust, and an even larger amount of non-debian users is likely to be using rust.

The answer here is almost certainly one of these:

1. Fix rhai::Engine so it is Send (if !Send is unintentional)

2. Use tokio::spawn_blocking or normal threads to run the rhai::Engine bits

3. Don't hold the rhai::Engine across an await point.

Which one depends on rhai Engine details and what you want to accomplish.

Doing a block on inside a new thread seems unlikely to do anything useful (unless there's some undisclosed detail that makes it reasonable).

I encourage you to ask about this in the rhai repo in a discussion or issue.

On Purple vs Pink: it seems that might explain Lego's official name for pieces one might call "pink" use "purple" (with various modifiers) instead.

https://www.thebrickfan.com/wp-content/uploads/2016/05/LEGO-...

I don't know what the percent of existing machines are chromebooks.

But that wasn't the question posed, it was:

> For, what, a handful of old laptops?

And the answer there is "no".

Every single modern x86 chromebook has coreboot support.

That said: most if not all of them require some proprietary bits to initialize ram timings and to run the security coprocessors (Amd PSP, Intel ME).

Older intel based systems (like the Lenovo x200) have coreboot support that can work without the ME firmware (but still requiring the EC firmware).

A list of many of the google devices with coreboot support (note: they're all codenames, not marketing names): https://doc.coreboot.org/security/vboot/list_vboot.html#goog...

`getpwents()` is not defined to only read `/etc/passwd`. There is only a requirement that there is some abstract "user database" or "password database" (depending on if you're reading the linux man pages or the Single Unix Specification man pages).

In practice, `getpwent` on linux uses the nsswitch mechanism to provide return values from `getpwent`. One can probably disable using `/etc/passwd` entirely when using glibc if: all users do use `getpwent`, and you remove `files` from the `passwd` entry in `/etc/nsswitch.conf`.

It appears to be a pyinstaller generated executable, presumably we'd expect it to contain https://github.com/Fadi002/unshackle/blob/main/src/unshackle..., but I haven't confirmed that.

In light of hiQ Labs v. LinkedIn [1], I'm not sure that Elon has a cause of action that he's likely to succeed on with respect to sueing scrapers.

1: https://en.m.wikipedia.org/wiki/HiQ_Labs_v._LinkedIn,

Please don't use posix message queues (`mq_*`, `mq_overview`, etc) when you're writing a program with a single address space (like something that uses threads in a single process).

Posix message queues (the `mq_*` functions) are much slower than optimized shared memory queues using typical atomics and have semantics that are unexpected to most (they persist like files after process termination, because of what they are designed to be used for, they have system level limits on size and size of items, etc).

A simple benchmark vs rust's `std::sync::mpsc` queue shows `std::sync::mpsc` is 28.6 times faster when using 1 producer and 1 consumer, and is 37.32 times faster with 2 producers and 1 consumer.

Are sellers of used products (second hand, etc) to the EU required to provide a warranty? If so, is it the same warranty as if the item was new?

There is not (normally) context added automatically. One can use `map_err(|e| ...)` to add context like this:

    let result = call().map_err(|e| SomeError::MoreData(e))?;

Or if using one of the common error libraries to have non-specific error kinds:

    let result = call().context("some data")?;

or

    let result = call().with_context(format!("something happened: {}", other_thing))?;

For something that more directly matches the behavior of the go code, this (using the `anyhow` crate) is a possible match:

    let result = call().map_err(|e| anyhow::Error::msg(format!("Error while trying to call: {:?}", e)?;

Though one would normally avoid this when using anyhow (or in rust in general) as it means we're flattening the error instead of generating a list of causes.

The comment does not indicate the drones actually flew over Area 51 (or a military base) : "drones flown over places _around_ Area 51" (emphasis added)

There is this on IPSEC: https://www.mail-archive.com/cryptography@metzdowd.com/msg12...