themulticaster

Apparently they've only been included in early October https://www.mail-archive.com/dev-security-policy@mozilla.org...

> [...] but the real reason is their uni can't afford a PET scanner for them to use.

This is incorrect, TUM has a PET scanner (site in German): https://nuklearmedizin.mri.tum.de/de/Patienten-Zuweiser/Pet-... Can't comment regarding the other observations.

There's both: GTFS is a standard for the regular schedule, and GTFS-RT is a standard for realtime information.

Link: https://gtfs.org/documentation/realtime/reference/

no-panic uses link-time shenanigans to prevent panics in the compiled binary, but this isn't 100% reliable (as explained in the README, just pointing this out)

The user you replied to likely means something different: The priority of the event often depends on the exact contents on the event and not the hardware event source. For example, say you receive a "read request completed" interrupt from a storage device. The kernel now needs to pass on the data to the process which originally requested it. In order to know how urgent the original request and thus the handling of the interrupt is, the kernel needs to check which sector was read and associate it with a process. Merely knowing that it came from a specific storage device is not sufficient.

By the way, NMI still exist on x86 to this day, but AFAIK they're only used for serious machine-level issues and watchdog timeouts.

When it comes to exchangeable lens cameras (DSLRs/DSLMs), as you increase the number of pixels you very quickly reach a point where you're limited by the optical performance of the lens instead of the sensor. Lots of systems offer a choice between a 24MP and a high pixel count camera (e.g. Nikon Z6/Z7), and you'll find that the high pixel count sibling requires very good lenses to actually achieve a meaningful improvement over 24MP. For these cameras, common wisdom says to stay with 24MP apart from certain niche use cases.

In other words, I wouldn't expect a improvement in capturing actual 48MP pictures in phone cameras, apart perhaps from pixel binning to a smaller size and similar techniques.

Disclaimer: I haven't followed camera tech very closely recently, and I'm not an expert. Take my opinion with a grain of salt.

Isabelle/HOL has Quickcheck, which is precisely what you think it is. Although it only works if the free variables in the thesis you'd like to prove are sufficiently simple AFAIK (think integers or lists). The more powerful alternative to Quickcheck is Nitpick, which is a purpose-built counterexample finder.

The workflow you'd like already exists one to one in Isabelle: You can simply type "nitpick" halfway through a proof and it will try to generate a counterexample in that exact context.

Of all the BSDs, I'm only a little familiar with OpenBSD through its OpenSSH fame, so I'm a little surprised to hear that a (probably) somewhat related project would use XML in a system call. In other words, if an OpenSSH release introduced XML as a wire format I'd assume it to be an April fools's joke. [1] But I guess OpenBSD and NetBSD are less related than I thought.

When choosing a bowl for your potato salad, you need to keep some important properties of potato salad bowls in mind. Different bowls have different designs that make some better suited to storing potato salad than others. For example, a higher quality bowl might have been manufactured to a higher standard than a subpar bowl. You might also want to choose different bowls depending on the amount of potato salad you want to prepare. There are bigger bowls and smaller bowls, differing in size and thus in the amount of potato salad they can accommodate. A smaller bowl is great when you're aiming to cook for just a few people, while a larger bowl is ideal for bigger groups. Brand name bowls like the classic SALADBOWL(tm) are preferred by some potato salad fans, while others appreciate the great price offered by newer, less established brands. Keep in mind that while a cheaper bowl is more affordable, it can also break more easily, so it's not a bad idea to compare the warranty period offered by different manufacturers.

Disclaimer: Not a native speaker, I hope I got the annoying structure of those "what to look for when buying X" blog articles right...

Based on its name I think it's used in Arch Linux packages (at least makepkg says it is generating an mtree file at some point during the build process IIRC). However it appears mtree (the tool) isn't packages, so perhaps it's only using the mtree specification format?

Yeah, I think coming up with definitions of "understanding" or "reasoning" that GPT-4 and friends supposedly don't fulfill is moving goalposts.

To continue your line of thinking, when we add salt and pepper to a dish we've cooked, are we really doing it because we have a developed a thorough understanding of the human olfactory and gustatory systems [1] system, or because it tasted good previously when applied to similar recipes?

And when it comes to understanding basic math, perhaps the patterns are still a tad to complicated for LLMs. Maybe there are too many surprising rules that appear out of nowhere and break the learnt patterns. But children struggle with those rules as well when they first come across them. Think about division through zero - when coming across the rule for the first time, you might wonder why it exists, instead of e.g. defining the result to be infinity. The answer to that question (not just "because that's the way things work!") is not obvious at all, to be honest I wouldn't be confident enough to attempt giving an explanation here.

[1] I have to admit I had to look gustatory system up: it's the biological term for the system behind the sense of taste.

The anti-pattern described as Deref Polymorphism is not the same as using Deref with the newtype pattern, in order to allow using the wrapped type transparently. In the latter case, the Target type of the Deref trait is always going to be perfectly clear. In case of the antipattern described on the linked page, it is not perfectly clear what the Target type is going to be.

In short, a Deref impl for some type T signals that T represents some level of indirection, and following/dereferencing that indirection can always be done in an unsurprising and trivial manner.

Yes, it should just work for all projects if you put in in ~/.cargo/config.toml, or as a per-project setting.

Git life pro tip (that you didn't know you needed until now): You can use .git/info/exclude (present in every Git repository) as a local, private version of .gitignore. It has the same syntax as .gitignore, but isn't tracked by Git. So you could add .cargo/config.toml to .git/info/exclude, changing the linker locally without Git considering it as an untracked file. I generally use this feature to ignore files that are specific to my development setup which I don't want to list in .gitignore.

As far as I know, non stick surfaces are mostly (always?) made out of PTFE (brand name Teflon), which is a little unusual in that it starts releasing toxic gases when it's heated way before it shows any signs of structural damage or deformation. This gets dangerous to humans from about 240C, but even at 220C PTFE will release trace amounts that can be toxic to birds.

With this in mind, I'm baffled about how many products with non-stick surfaces are marketed as safe up to 240C, considering that household ovens are often bad at controlling temperatures and can swing 20-30C above and below the set temperature.

Is the Neural Engine/CoreML used in "normal" desktop apps on macOS, or is it limited to specialized ML centered apps? In other words, where should I expect performance improvements if there was a hypothetical Mesa for compute accelerators? Spontaneously, I can only think of image editors like Photoshop offering AI-based tools.

I'd see that as a benefit of llama.cpp - it's specifically designed to be usable on consumer hardware such as laptops, without professional GPUs.

I'd like to add some context as to why lockless algorithms are popular in the Linux kernel. Roughly speaking, there are two possible scenarios in which kernel code is executed: Either in context of a process (e.g. while handling a syscall) or while handling an interrupt [1]. Now, a mutex usually sets the current thread to sleep if it tries to lock a currently locked mutex. Even in kernel land, this is perfectly fine as long as the kernel is in process context. However, while handling an interrupt there is no current thread that can be put to sleep. Therefore you can't use a mutex for kernel data structures that will be accessed during interrupts, and that applies to a lot of data structures.

This is why some common locking advice does not really apply to kernel code. Another example would be "avoid using spinlocks, prefer a mutex" - spinlocks are widely used in the kernel since they're the most straightforward alternative to mutexes.

Not disagreeing with the parent post, just wanted to add some context why LWN likes to talk about lockless algorithms.

[1] Actually, the kernel differentiates between hardirqs and softirqs, but that's not important here.

This is the way. In theory, you're only supposed to downvote comments that don't contribute to the discussion. For me, that mostly amounts to very rude/unhelpful comments or extremely flawed arguments (flat earth level, not just arguments I strongly disagree with).

On the other hand, I find it's easy to be downvoted into oblivion for no apparent reason. I find it hard to just ignore and forget about those threads, even though I know I should. Example (sorry, I have to get this off my chest): a redditor with a history of substance abuse started with winemaking (as a hobby) and asked how many glasses of wine they could safely consume. A physician (verified in that subreddit) responded that two glasses every day would be fine. I commented (as a medical layperson) that suggesting OP that it's safe to drink two glasses of wine every day (not just every now and then) might not be a good idea considering their history, at least to my knowledge. Suffice to say, that day I learned that some people seem to be easily offended when commenting about reasonable alcohol consumption considering past addictions. Or perhaps I'm vastly overestimating the risks of substance abuse disorders...

Well, using the identity function as a hash does not provide any avalanche effect at all. And as parent comments point out, certain hash map implementations require a strong hash function. I'm guessing that the identity function probably isn't a "good" hash function as required by abseil's swiss tables and similar hash maps, but to be honest I haven't looked into this any further. Put another way, I'd have expected std::hash to be at least a very basic hash function (like FNV-1 for example).

I was genuinely surprised when I stumbled upon this Stack Overflow question [1] where someone asked why std::hash is the identity function for int, and some commenters argue that it is a perfectly sensible choice for a hash function.

[1] https://stackoverflow.com/questions/38304877/why-stdhashint-...

I'm not familiar with how it compares to ARM/Intel's profiling tools, but I found the Linux perf suite to be very capable (though limited to Linux obviously). And Hotspot [1] allows effortless profile visualization using flame graphs, including some very interesting features such as off-CPU time profiling [2]. "perf record" coupled with Hotspot forms a very smooth edit-compile-profile cycle.

[1] https://github.com/KDAB/hotspot

[2] https://github.com/KDAB/hotspot#off-cpu-profiling

Indeed. I'm currently stuck with 8GB RAM on my laptop and it feels like the OOM killer [1] is playing whack-a-mole with Firefox and any Electron apps. Start Firefox, then VS Code gets killed by the OOM killer. Start VS Code, then Slack gets killed by the OOM killer. Start Discord, then Firefox gets killed by the OOM killer. It doesn't help that I'm firmly in the way-too-many-open-tabs camp. Even zswap doesn't really help.

[1] Actually systemd-oomd to be precise, but let's not start the userspace OOM killer debate again in here

Mesa (the Linux OpenGL driver) supports caching shaders on any GPU. And Vulkan essentially has shader caching built in at the specification level. I know that Steam ships precompiled Vulkan shaders, and while there's no equivalent for Mesa's shader cache yet, it shouldn't be a huge issue since it would only cause a short delay the first time the shader is loaded.

That looks like an nice idea in principle, however (I hope this doesn't come across too negative) I don't think using similar colors for lines if they're going to similar destinations is quite the optimal solution. In my experience, it's very important that lines which together with other lines on certain sections use visually distinct colors.

I'd say that the color primarily serves as a visual aid that does not depend on passengers understanding the local language or remembering the name/number of the line. And color serves an important role in interchange stations, where it aids navigation by providing visual cues where you should go.

A nice example of this is the London Underground, where visual cues using the line color are used extensively. In Green Park, there is a mosaic on the walls between the grey Jubilee line and the blue Piccadilly line. The tile pattern smoothly changes between grey on the Jubilee side and blue on the Piccadilly side. If you look at a Tube map, the line colors are all sufficiently distinct so that you're never confused which line is which in busy parts of the map.

On the other hand, IMO a negative example of line colors would be the Berlin S-Bahn. Have a look at the map [1] and tell me whether you have an easy time differentiating S41/S41/S45/S47 as well as S3/S5/S7/S9 (as well as U2/U7/U8). They all use extremely similar colors. If you're new to the system, you can't just remember to use the "blue line", as there Alexanderplatz, Friedrichstraße and Charlottenburg each have three "blue lines".

[1] PDF can be downloaded at https://www.vbb.de/en/driving-information/maps/ - select "S+U-Bahn in Berlin - suburban trains and underground"

Interestingly, your example renders incorrectly for me (Firefox/W10). The overline is placed between 1 and ).

> (My apologies to non-native speakers of English; if someone did that to me in German I'd have no clue what was meant).

At least for me it's perfectly understandable (except the "Mrs" part). This reminds of those "did you know you can flip characters randomly and our brain can still understand the text" copypastas that can be found everywhere. I think it's probably quite similar for word order: As long as your sentence structure is not extremely complicated, you can probably get away with changing it any way you like. Just like nobody has issues understanding Yoda in Star Wars.

Although I think there are some limits to changing word order - I can imagine complicated legal documents might get impossible to decipher if you start randomizing word order.

When I opened HN today I really did not expect to find a comment mentioning the Bayerischer Landesverein für Heimatpflege e.V.

Hey Raph, hoping you might see this: Almost all (Rust) game engines seem to focus entirely on sprites (or more generally, texture-based primitives) for rendering. I've been experimenting with a toy game project based heavily around more complex 2D primitives [1], such as splines or Bézier curves that might benefit from some vertex-based shader shenanigans [2]. But apparently this is something 2D game engines just don't support. Since you have a lot of experience with curves, Rust and GPUs I was wondering if you can think of specific reasons this path seems to be unsupported?

[1] My goal is to implement realistic train track geometries, including transition curves, using Euler spirals or perhaps a simpler curve.

[2] For example, I'd like to try tessellating curves via shaders as required, based on zoom level etc.

Do you suggest there is any security benefit of a short canary? Or is it just about keeping a canary simple and comprehensible even for non-technical users?

I think your question is a little too broad to answer precisely, as it depends on your definition of "making sense" - however, CPU cycles are still relevant in many aspects.

Generally speaking, just because modern x86 CPUs use numerous abstractions for high-level instruction set features does not mean they don't use cycles. (Clock) cycles are an inherent feature of synchronous logic, and all CPUs (modern as well as ancient) use synchronous logic. Yes, there might be some esoteric outliers, but 99.9% is synchronous.

The difference to ancient CPUs is that modern CPUs don't necessarily retire (essentially, "execute") an instruction in every clock cycle. In any given clock cycle, a CPU might retire none, just one or even multiple instructions.

A typical application (where clock cycles are important) is looking at the number of retired instructions per cycle (IPC), which can give a rough overview of whether a program is frontend-bound or backend-bound. You can try this yourself using "perf stat" (part of the Linux perf tools): Try running different applications using perf stat and look for "insn per cycle" in the report. You will generally find that interpreted programs (Python, Node etc.) will have a mediocre IPC of well below 1 (due to poor cache utilization and branch mispredictions) while compiled, optimized programs might reach an IPC of 2. A high IPC value is not necessarily better though, it's complicated^TM.