codys

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...

Other CMSIS-DAP compatible probes:

- https://makerdiary.com/products/pitaya-link

- https://www.l-tek.com/web-shop/cmsis-dap-debug-probe/

All of the jobs I've worked have not had any technical restrictions on what software engineers could install on their work laptops.

Most (but not all) had some sort of asset management tool and/or antivirus as standard on computers, but nearly all provided exceptions to having that functional/installed.

I, and I expect many developers, likely select companies with IT policies that avoid potentially harming individual productivity.

They use a custom plug system that doesn't use the standard brick shape as contacts.

https://www.lego.com/en-us/themes/powered-up shows some examples of the connector and socket.

There's also the discontinued "Powered Functions" connection scheme, which can be seen on this model: https://www.lego.com/en-us/product/power-functions-motor-set... . It appears to be post-brick contacts and pre-"powered up" connectors.

There have been many electrical connection schemes over the course of lego's history.

That's a great point, and shows up in annoying ways in Sony's camera line up in whether "high frame rate" support exists. For Sony cameras, HFR implies "can capture a limited length (seconds, typically) of footage at a higher frame rate (240fps, 480fps, 960fps, etc) and reduced resolution as frame rate increases (this is not the same as normal video modes and S&Q video modes, which don't have time limits like these).

Sony includes this feature on cameras without interchangeable lenses (ie: "point and shoots"), and on their high end cinema cameras, but not on their mirrorless (interchangeable lens, but not considered cinema cameras) line.

Seems pretty clear this is designed to avoid their mirrorless lineup have a feature that might make it competitive with their cinema line. But they're ok including it on the point and shoot line because that already is well differentiated from the cinema camera line.

Camera software is an area that is frustratingly closed off, and where manufacturers regularly differentiate new/more expensive cameras with firmware differences: subject detection, auto focus, drive modes (pre-capture, higher frame rates, etc), file format support (HEIC, compressed raw, colorspaces), ui features (how custom modes work, menu systems, etc).

Competition in this space driven by a provider that doesn't have a motive to convince users to buy the next new camera (ie: open source software) would be very useful to users.

Sony and Panasonic cameras (and perhaps other manufacturers) are running Linux (and release some of the third party source code they include in their products, but the amount of reverse engineering that has been done on those camera's software.

Canon uses a custom RTOS (DryOS), and lots of work has been done to extend the existing Canon firmware to enhance its capabilities (Magic Lantern[1] and CHDK[2]), but as far as I know fully open software for these devices doesn't exist.

Camera capabilities these days are highly software dependent, and the functionality of dedicated cameras is held back by subpar software development practices and a lack of pressure to make things better.

1: https://magiclantern.fm/ 2: https://chdk.fandom.com/wiki/CHDK