HALtheWise

An 8k monitor is typically 33 million pixels, and the sensor here is 48MP, so the resulting image is going to show at least strong moire patterns, and possibly individual pixels. Note that Apple does have a secret neural classifier on their servers looking for that kind of pattern. I also suspect that getting enough dynamic range out of a screen is tricky.

None of this is impossible, but it could make it really expensive to produce an image that passes forensic analysis.

We're talking about a 48MP camera here, so finding a sufficiently "high-resolution monitor" to pull this off is probably more difficult than you expect. Especially because without at least a few times as many pixels as the camera, it's likely that there will be detectable moire patterns in the image. My guess is that a physical print is more fruitful, but it's still a pretty tricky task to get high enough dynamic range and such to truly fool the sensor.

This sort of concern is presumably why Apple says "Using a neural network with hidden weights, PCC computes a confidence score for the photograph." I'm assuming that things like moire-patterns from pointing the camera at a screen would be caught by that check.

It's of course physically possible to fool the sensor, but at some point it becomes cheaper to just build a UFO and fly it over the actual Golden Gate Bridge.

Average life expectancy is the wrong thing to use here, since life expectancy _assuming you're still alive at 74_ is actually 13.1 yr in the US.

Say hypothetically that they were concerned that GPT models would see widespread abuse, for example by students cheating on homework assignments, in a way that could cause likely-irreversible societal changes some of which are harmful. Can we confidently say they were wrong?

Sorta, but it's important for the calling convention that the compiler is consistent on what is done at compiletime vs runtime. Because methods are "normal functions" for the calling convention (and can be assigned to function-typed variables), there would be a lot of gymnastics required for the compiler to make runtime-generated variants of methods work.

I wonder if npm could run a program where package uploads are automatically delayed for ~10min while they get distributed to an ecosystem of third-party code auditing companies for automatic checks. You could have a public leaderboard of which auditors detect problems fastest and most reliably, or even monetary compensation.

This is exactly what the Starlark language was developed to solve, initially for Bazel but also used other places. It's a "full scripting language" but intentionally doesn't (in default configuration) support recursion or unbounded loops, so is deterministic and bounded execution time. I really wish more projects would reach for it as a configuration language.

https://github.com/bazelbuild/starlark

> Not to mention that trains are far safer than automobiles too.

This claim is situationally true, but not universally so like many people seem to believe. For example, Brightline rail service in Florida has been operating since 2017 and averages (by my math) 29.8 deaths / 100M passenger-miles, while the road system in Florida averages 0.89 deaths / 100M passenger-miles. Those deaths are mostly not suicides, and imo we should treat pedestrian deaths from trains as substantially more morally weighty than passenger deaths, since it's a victim that didn't opt-in to the risk.

For what it's worth, the unusual spike in Spain train crashes this year seems to have pushed them barely over the fatality numbers of Spanish cars (0.91 deaths/100M pax-mi vs 0.73 for cars) but that's pretty clearly an outlier.

If you measure per vehicle-mile rather than per passenger-mile I'm pretty sure trains are always way more dangerous, although that's a less fair comparison.

In the context of this thread, it's worth pointing out that "trying to deceive regulators" is quite normal behavior for individual human drivers involved in car incidents, and iirc the Cruise collision itself also involved a human driver performing a hit-and-run who didn't afaict ever get prosecuted or come forward to police.

Tangentially related, but there's a bunch of extremely high-resolution panorama images from the Apollo landings available at this site, for anyone who enjoys this sort of thing. https://www.lpi.usra.edu/resources/apollopanoramas/

They successfully built local privilege escalation exploits (from several bugs each), and found other remotely-accessible bugs, but were not able chain their remote bugs to make remotely-accessible exploits.

Not even mentioned in the article, my favorite capability is the new `//go:fix inline` directive, which can be applied to a one-line function to make go fix inline it's contents into the caller.

That ends up being a really powerful primitive for library authors to get users off of deprecated functions, as long as the old semantics are concisely expressible with the new features. It can even be used (and I'm hoping someone makes tooling to encourage this) to auto-migrate users to new semver-incompatible versions of widely used libraries by releasing a 1.x version that's implemented entirely in terms of thin wrappers around 2.x functions and go fix will automatically upgrade users when they run it.

Do we even know that the child was injured? All I've seen anyone officially claim is that the Waymo made contact, the kid fell over, then stood up and walked to the side of the road. Assuming the Waymo was still braking hard, 6mph means it was about 1/4s and about 30cm from reaching a full stop, so it could be a very minor incident we're talking about here.

I'm not aware of any statistics for how often children come into contact with human-driven cars.

Your expectation is wrong in this case for almost all languages. The design of Pylance (as is sorta forced by Python itself) chooses to execute Python to discover things like the Python version, and the Python startup process can run arbitrary code through mechanisms like sitecustomize.py or having a Python interpreter checked into the repo itself. To my knowledge, Go is one of the few ecosystems that treats it as a security failure to execute user-supplied code during analysis tasks, many languages have macros or dynamic features that basically require executing some amount of the code being analyzed.

I did a pretty deep dive into this recently, although haven't yet started any implementation work. As far as I can tell, the best strategy that preserves Linux's open-source and user-empowering ideals as much as possible:

- The game obviously needs to run as root, at least until large amounts of this stuff gets upstreamed into the kernel.

- We're going to be leaving the kernel and boot as untrusted, but injecting a hypervisor underneath the running kernel that is responsible for protecting most pages of game memory. This allows users to still run whatever kernel they want.

- The hypervisor sets up two sets of page tables, one that's only active when the game's thread is running and in userspace, one that hides protected pages and is active when the kernel or other threads are running. Note that game code itself needs to get decrypted into protected ram.

- The TPM of the system gets involved when we jump into the hypervisor to attest that the hypervisor is actually running, and the hypervisor then provides attestations to userspace that certain memory regions are protected from kernel or other thread access.

- Any syscalls will fail if they require the kernel to read or write pages that are protected. The game needs to allocate data that should be shared with the kernel into non-protected pages.

- When the game is closed, we can remove the hypervisor and Linux will be back to bare metal operation. This should be unobservable to the rest of the system.

This architecture preserves the ability of users to run arbitrary kernel modules, but does mean a hypothetical attacker can observe data that passes through the kernel (like draw calls/pixels). It's likely that a more complete implementation would also want some way for the hypervisor to attest to the accuracy of keyboard/mouse input and interface with iommu configuration like Windows KAC does.

Doing some quick math, if your bike is using 3kw to climb a reasonably steep (15% grade) hill at 8mph, we can calculate the weight it must be carrying, which ends up being about 1,200lbs

To answer your question, the limit on motor power exists as a proxy for limiting the weight, speed, and acceleration of ebikes within safe limits, since having an ebike charging uphill at 20mph with 500lbs of payload would present actual safety risks. Trying to regulate payload/speed/slope combinations directly has practical problems (police officers don't really want to stop delivery drivers to weight their cargo), while regulating motor power is much simpler.

A friend of mine created something similar using a numerical optimization based approach to minimize distortion. He also made the artistic choice to split the water between Australia and Asia to get even lower distortion. See Elastic II here:

https://kunimune.blog/2023/12/29/introducing-the-elastic-pro...

There's a lengthy, and quite good, deep-dive into Alpha School by a current parent here, for anyone interested. Spoiler, "AI" isn't that big a portion of what they're doing, but some of their insights and systems around student motivation are actually interesting and very effective.

https://www.astralcodexten.com/p/your-review-alpha-school

Feeding random inputs to a crypto function is not guaranteed to exercise all the weird paths that an attacker providing intentionally malicious input could access. For example, a loop comparing against secret data in 32 bit chunks will take constant time 99.99999999% of the time, but is still a security hole because an attacker learns a lot from the one case where it returns faster. Crypto vulnerabilities often take the form of very specifically crafted inputs that exploit some mathematical property that's very unlikely from random data.

The original groupcache is basically unmaintained, but there's at least two forks that have carried on active development and support additional nice features (like eviction), and should probably be preferred for most projects.

https://github.com/groupcache/groupcache-go

I highly recommend revup, it allows managing and uploading stacked (or arbitrary trees of) PRs to Github, including adding a comment that shows approximate revision-to-revision diffs if you want it to. I don't actually think that per-commit reviewing obviates the desire for stacked PRs, for example I often have some PRs in my stack that are not yet ready for review or merging.

https://github.com/Skydio/revup

I believe it's a 360deg planar lidar mounted on a vertical plane, with a motor to rotate it around and slowly cover a full 4pi sphere. There's also a fisheye camera integrated in. This is a pretty common setup for scanning stationary spaces (usually tripod mounted)

Do you have other sensors in the same price range that you'd recommend instead for most uses? How much accuracy improvement would you expect?

AutoPallet Robotics (YC S24) | ONSITE | San Francisco | Full-Time and Intern | Robotics Software (Rust), Mechatronics Engineer, ML Intern, ??

We’re building novel robots for case picking in warehouses, a huge unsolved automation opportunity for a very labor-intensive, critically important and sh*tty human job in the thin-margin industry of logistics. Our software is all Rust/Pytorch, embedded dev through research-frontier applied algorithms and an integrated development iteration time measured on a watch, not a calendar.

There’s more than enough fun problems to go around, and we’re looking to grow the team with a couple more great-to-work-with folks, including generalists or job descriptions we haven’t realized we should be hiring for. We’re also specifically looking for a summer applied ML intern for robotic perception and controls. There’s a lot more cool stuff we can’t share publicly just yet. To apply, email a resume to <the-two-letters-of-this-site>@autopallet.bot, and include the role you’re looking for in the subject line, and we’ll take it from there. Bonus points if you include a link or photo of something cool you’ve made.

It seems like a 24hr delay for auto upgrades would mitigate a lot of this, maybe with some way that a trusted third-party could skip the delay for big-ticket zero day patches?

Not an expert here, but afaik a turbine section consists of alternating spinning blades attached to the shaft and stationary vanes attached to the duct, which de-spin the air coming off the blades and prepare it for the next set. I'm not sure why the vanes are often hidden in cutaway views.

If you had a spinning duct, you'd presumably need a stationary shaft in the middle for mounting the vanes, and would have similar tolerance issues between the tips of the stationary vanes and the rotating duct. There's reasons that it might be easier to solve (the duct can be lower temperature) and reasons it's harder (bearings for a giant spinning duct). Not sure if anyone has tried such a design.

What's your perspective on variable-width SIMD instruction sets (like ARM SVE or the RISC-V V extension)? How does developer ergonomics and code performance compare to traditional SIMD? Are we approaching a world with fewer different SIMD instruction sets to program for?

It looks like the TID is stored directly in the pthread struct pointed to by %fs itself, at a fixed offset which you can somewhat-hackily compile into your code. [0]

In the process of investigating this, I also realized that there's a ton of other unique-per-thread pointers accessible from that structure, most notably including the value of %fs itself (which is unfortunately unobservable afaict), the address of the TCB or TLS structures, the stack guard value, etc. Since the goal is just to have a quickly-readable unique-per-thread value, any of those should work.

Windows looks similar, but I haven't investigated as deeply.

[0] https://github.com/andikleen/glibc/blob/b0399147730d478ae451...

[1] https://github.com/andikleen/glibc/blob/b0399147730d478ae451...

Presumably you could store the TID in every event, or otherwise check whether the TID has changed since the last time it was logged and push a (timestamp, TID) pair if so. Reading TID should be cheap.

In addition to the other good answers, if the amount of state that's explicitly managed by software gets too large then it gets really expensive to save or restore that state. This happens, for example, when a syscall transfers control to the operating system. If the (many-MB) cache were software-managed, the OS would need to decide between flushing it all to main memory (expensive for quick syscalls) or leaving it in place and having OS code and data be uncached. Function calls between libraries have similar problems, how is a called function supposed to know which cache space is available for it to use? If you call the same function multiple times who's responsible for keeping its working data cached? For a 32MB L3 cache, flushing the entire cache to memory (as would be required when switching between processes) could take over a millisecond, let alone trying to manage caches shared by multiple cores.