It's always possible to break a perfect system by moving an additional layer of abstraction outward, and attacking one of the assumptions upon which it's built. Some of our era's highest security systems - game consoles - have been broken by undervolting them until the logic failed.
It's often possible. But not all systems are vulnerable to undervoltage attacks. For example, I don't think the iphone secure enclave is vulnerable to this.
And good security uses "defence in depth". Multiple layers which each individually need to be compromised to break the whole thing. To hack chrome, you need a vulnerability in the renderer or VM. Then you also need a sandbox escape, and a way to use that to attack the browser's parent process. This is much harder to do.
I'd stick with always. Defense vs offense in anything reasonably complex suffers from one issue that simply cannot be overcome. To defend, you need to defend against every single possible imaginable attack, from now until forever. To attack, you need to find a single attack that works. And on a practical level all systems need to be accessible by somebody, yet that somebody is himself also now a part of your security structure and is never going to be 100% reliable, both in terms of corruption and incompetence.
> not all systems are vulnerable to undervoltage attacks. For example, I don't think the iphone secure enclave is vulnerable to this.
Then there's decapping / depotting, a world of different types of microscopy - some destructive some not, directed EM attacks, etc.
> And good security uses "defence in depth"
And automation has enabled "offense in depth"
> To hack chrome, you need a vulnerability in the renderer or VM. Then you also need a sandbox escape, and a way to use that to attack the browser's parent process.
Or you just phish the user into installing your exploit. There's always another layer. Always a potential exploit. Because ultimately the same properties of the universe which permit computation within a closed system allow for predictably observing and influencing it. The expense and hassle of doing so are widely variable, of course.
> There's always another layer. Always a potential exploit.
So what? Most attackers aren't nation state adversaries. They're some kid in Wyoming messing around with deepseek. We live in a world where most exploits happen because someone was running an unpatched, 8 year old copy of wordpress. Because they put their insecure mongodb instance on the open internet. Because they used admin / "12345" as the username and password. We don't need to make hacks physically impossible for a nation state adversary. Just really, really difficult and expensive to pull off.
Honestly. If people talked about physical security like they talk about computer security, you'd have people telling you that, because walls can be physically smashed through, they don't bother locking the front door to their house.
> Honestly. If people talked about physical security like they talk about computer security, you'd have people telling you that, because walls can be physically smashed through, they don't bother locking the front door to their house.
Sure, but also if there are a dozen bikes locked to the rack all costing $1000 and a $500 bike just sitting there completely unlocked, the average thief is probably gonna take the cheaper unlocked one and ride away.
It’s not hard to get into a garage but it’s really easy to steal a lawnmower if you leave the door open all night. I wouldn’t call that thief honest but even the minor deterrent of closing the garage was enough to make you not the target.
How many locked doors have easily breakable glass windows right next to them, nevermind breakable walls? What we need is a red-team waiver, and an AI model, and a budget, and say something like: your site has to be unhacked by the HackerAI3000 bot after 2 days on a 5090 Nvidia GPU.
> Floating point is deterministic, what are you talking about?
Order of operations can change a result, for example. I suspect you mean that the algorithm never changes. While op means that mathematical operations which most folks would expect to be reliable are not.
There are enough problems for a 44 page paper titled "What Every Computer Scientist Should Know About Floating-Point Arithmetic"[1] I don't quibble on the language because I know what people mean.
Most folks won't encounter most of the issues, generally. But expose your code to a large enough dataset, or be like me and write a CAD/CAM system with motion control and experience most of them.
That (no doubt excellent, but) technical PDF is overselling the problem somewhat, when what every dev needs to know is better represented by a friendlier summary like https://floating-point-gui.de/
That's a great resource as well. Targeted at developers, rather than computer scientists. Same observations, different target audiences and expectations. You're probably right that the more practical reference targeted at developers is more useful here. My references are full of the academic papers because of my CAD work.
No. It's been quite some time since I realized that all language is a pidgin used to translate between individuals' unique lived experiences and points of reference. And find communication much more fluid and less confrontational when the focus is on shared meaning rather than perfect word choice. Especially when working with non-native speakers, but also just people in general. Stephen Fry captures the feeling: https://www.youtube.com/watch?v=Ovi7uQbtKas
When TZubiri made their original comment, I understood they were speaking about some or all of the issues outlined in the paper I linked. If you didn't, that's ok. If you think the referenced paper missed something, it's OK to add that.
These kinds of comments tend to happen when you are assuming a shared meaning that isn't so shared. Especially in this context, it's a good idea to be precise in your terminology when there is a commonly used vocabulary for talking about it. Especially when it comes to misconceptions about floating point, which is often treated as 'random' when it generally isn't.
Sometimes specificity matters. Usually when looking directly at some specific piece of code. In this conversation, the intended meaning was clear. Folks just love being the pedant and the brinksmanship which comes with it. There's a propensity to derail otherwise useful conversations into discussions like this rather than dig deeper into what people meant, and were trying to communicate.
> In this conversation, the intended meaning was clear
Apparently it wasn't, as the commenter who originally used the term has now clarified that they did indeed mean non-deterministic. You misunderstood them.
So maybe being specific about terminology here isn't just pointless pedantry?
Regardless of his choice of words, he's specified that he's speaking about IEEE754 and the sort of issues which arise systemically from the compromises inherent in it's design.
He can't attest to them being the same ones in the paper I linked, but I can. Everything he's said is in line with the situation detailed within.
He and I seem to understand each other. I get what he's saying. How the issues with IEEE754 give rise to the nondeterminism he's talking about. I should, I wrote a whole system of libraries to deal with them. Do you understand the conversation? Because it seems like you think we're talking about two unrelated things and you're still arguing over terminology.
Thanks for following the thread. I'll clarify on my intended meaning was indeed a strict actual definition of determinism, but a broader definition of floating point, to include its actual usage. But fwiw, it was indeed possible that I was someone who confuses determinism for precision, but no.
When I said that floating points are not deterministic, I wasn't very precise, but I do think that broadly speaking, floating point arithmetic, as used today, foregoes determinism, and this results from the very ethos of the foundational IEEE754 data type, the goal is to have a data type for approximate answers, turns out that when exact answers are sacrificed in the name of speed, so is determinism. And this has huge effects on modern day, Floating Point is used on separate hardware with parallel operations, and there's race conditions that make most Machine Learning and AI computing irreproducible, and that indeed seems to be a consequence, as you mention, of the lack of associativity of FP.
So, that said, I would make two clarifications:
>-- Floating Points
>++ Floating Point computing
where by Floating Point computing would mean the actual application computing that we build, as opposed to "Floating points" referring to the ideal ancient standardized hardware layer abstractions.
And if necessary:
> -- is
> ++ tends to be
In order to be perfectly correct, which after all, is what we are going after.
So if pressed, I wouldn't say "Floating points are not deterministic" but "Floating Point computing tends to be non-deterministic", but I would feel very comfortable shorthanding it to "Floating Points are non-deterministic" anyways.
The paper cited is a bit hard for me, so I can't verify if it matches what I'm saying. But I imagine by the date, it wouldn't be able to address the issues that we can empirically from the advent of ML systems, but maybe it did foresee from a theoretical standpoint some of their limitations.
There's a between-the-lines thesis here that there's two main schools of computing nowadays, one that seeks perfection, and another that seeks approximations, the CPU/GPU dichotomy is roughly analogous to the Mathematics/Physics vs Engineering/Industrial dichotomy.rroot@t14:/mnt/c/Users/TomZubiri/Desktop# cat fixed.txt
Thanks for following the thread. I'll clarify on my intended meaning was indeed a strict actual definition of determinism, but a broader definition of floating point, to include its actual usage. But fwiw, it was indeed possible that I was someone who confuses determinism for precision, but no.
When I said that floating points are not deterministic, I wasn't very precise, but I do think that broadly speaking, floating point arithmetic, as used today, foregoes determinism, and this results from the very ethos of the foundational IEEE754 data type, the goal is to have a data type for approximate answers, turns out that when exact answers are sacrificed in the name of speed, so is determinism. And this has huge effects on modern day, Floating Point is used on separate hardware with parallel operations, and there's race conditions that make most Machine Learning and AI computing irreproducible, and that indeed seems to be a consequence, as you mention, of the lack of associativity of FP.
So, that said, I would make two clarifications:
>-- Floating Points
>++ Floating Point computing
where by Floating Point computing would mean the actual application computing that we build, as opposed to "Floating points" referring to the ideal ancient standardized hardware layer abstractions.
And if necessary:
> -- is
> ++ tends to be
In order to be perfectly correct, which after all, is what we are going after.
So if pressed, I wouldn't say "Floating points are not deterministic" but "Floating Point computing tends to be non-deterministic", but I would feel very comfortable shorthanding it to "Floating Points are non-deterministic" anyways.
The paper cited is a bit hard for me, so I can't verify if it matches what I'm saying. But I imagine by the date, it wouldn't be able to address the issues that we can empirically from the advent of ML systems, but maybe it did foresee from a theoretical standpoint some of their limitations.
There's a between-the-lines thesis here that there's two main schools of computing nowadays, one that seeks perfection, and another that seeks approximations, the CPU/GPU dichotomy is roughly analogous to the Mathematics/Physics vs Engineering/Industrial dichotomy.
> when exact answers are sacrificed in the name of speed
I have found in https://github.com/timschmidt/hyperreal and the geometry layers built atop it, that exactness and speed are not fundamentally opposed. Hyperreal retains exact mathematical structure at the scalar level, and at each level higher up through vertices, vectors, matrices, triangles, curves, etc. And uses it to choose optimal datatypes, dispatch against the fastest algorithms, and eliminate large chunks of needless calculation where simpler proofs are sufficient.
The downside is a bit of additional code and API complexity. But the slightly more complex API accurately represents issues like uncertainty in decidable equality of arbitrary computables in bounded time, which is a limitation of math itself, so representing it accurately in the API permits the algorithms to be more robust.
> Floating Point is used on separate hardware with parallel operations, and there's race conditions that make most Machine Learning and AI computing irreproducible
Deterministic reproducibility is, I think, one of the most awesome superpowers of a system like hyperreal. It makes simulation much more interesting and useful. As well as cross-platform use.
floating point arithmetic, as used today, foregoes determinism, and this results from the very ethos of the foundational IEEE754 data type
This was somewhat true in the past, but the situation has been improving dramatically in recent years to the point where FP determinism is completely feasible. The remaining hurdles are primarily on the toolchains/kernel side. I have a library called rfloat that you can drop into most C/C++ code for practical determinism without thought (subject to documented caveats), for example. You can do the same thing manually with some more careful attention.
I'm in a very remote corner of the world on bad Wi-Fi though, so you'll have to forgive omitted links.
>in recent years to the point where FP determinism is completely feasible.
Ok, sure, it is feasible, but is that how it's actually used? Or is it used in GPUs with thousands of processors running in parallel, and batching different operations, (and with temperature settings that add even more pseudo-indeterminism purposefully).
It's funny that the customs actually go in the opposite direction of fabricating even more indeterminism, whether it is for being an accountability sink, or for fudging data to claim IP over the new mungled data, the FP/GPU/ML folk want magic, not determinism.
It's an infinite precision exact constructive real with excellent performance characteristics and approximation only at explicitly named lossy export functions.
... checks math ... Starship should have enough cargo capacity for this. One launch. We could put the whole senate up there. The house might take a couple launches unless we really pack 'em in. /s
We just need to setup a fake corporate sponsor meet and greet. We camouflage Ship to look like a hotel ball room, with a door for "private meetings" that leads to the cargo bay.
Not just mass optimization either. Intense effort and cost are expended through verification because a single payload simply must work. But using commodity hardware with reduced verification effort, launching many, and tolerating some amount of attrition has resulted in reduced costs for Starlink.
I think if they had a big f-ing rocket at their disposal and could bundle a couple dozen of them MIRV style there would be no political downside if a bunch went splat so long as a bunch didn't
"look guys 9/24 of the rovers are transmitting back, great success"
Testing of using commodity parts was part of the Mars helicopter and it worked well enough that making many of them seems plausible. I'd love to see multiple drones flying faster/further than rovers. Just not really sure what instruments would make them useful.
That's another great example. And ridesharing on the mission allowed them to prove it very inexpensively and with much lower risk than a dedicated mission.
I think the question of technical possibility answers differently from the question of organizational feasibility. Starlink is optimizing costs because they have a financial incentive to do so. The less each satellite costs, and costs to maintain, the more income they make. I fear incentives are not so direct in governmental orgs. Outside contractors performing most of the work have outsized influence, and incentive to inflate costs. Budgetary decision makers all want to see investment in their own districts.
I think Starlink and cubesats have definitely proven the approach can reduce costs.
The engineering does not seem as challenging to me as figuring out how to get such a policy approved and pushed through all the administrative and decision making layers without watering down and budgetary inflation.
Maybe if we launched 30 Starships carrying 30 rovers each. With only 30 units, the prices would likely be similar to current commercial satellites, which are already built on standardized platforms.
I'd go even more radically low cost, and kit the first lander out with wifi, and a half dozen each of every commercially available robot dog, humanoid, and wheeled or tracked robot of any interest. Rumble in the Mars Robodome. Bit of publicity for the existing manufacturers who may be willing to pay for the privilege, and who will undoubtedly learn valuable things about how their designs fail and can be improved. And you figure out in one stroke if there's a COTS platform you can buy for $30k that gets you 80% of what you need. If any of them function for any period of time, you use them to prepare the space for future landings. Rinse, repeat. After a few iterations, you have a half dozen manufacturers with commercially produced platforms with a few strategic modifications to which you can bolt your science instruments.
All I can think about now is a bunch of e-waste littering Mars. At some point, other visitors will show up to investigate Mars and come to the conclusion that the Earthlings are just so trashy their trash even started filling another planet.
The surface of mars is roughly the size of Earth's dry landmass. They'd have to spend quite a lot of effort looking for it to find it. And at that point it'd probably look more like a treasure trove of useful thermoplastics, refined metals, magnets, and other useful things otherwise difficult or expensive to source on Mars directly.
I'm not BoingBoomTschak who you're replying to, but he's right. My experience comes mostly from decades of reading xiph.org and ffmpeg mailing lists where such things are discussed, rather than implementing them myself. But there is constant discussion of encoder performance / quality trade-offs in software and hardware encoders. Hardware encoders, especially ones attempting to meet strict performance targets, simply cannot take advantage of some of the most complex quality improvements as they depend on information only present in past/future frames. Sometimes as many as 30 frames away.
It seems like you are interpreting this as a slight against the quality of Apple's hardware encoders, which may legitimately be very good. As are Nvidia's, Intel's and AMD's. But all of them will produce larger file sizes and lower quality than equivalently optimized non-realtime software encoders, which simply have more information and more time, memory, and flexibility to compute over it.
We're talking about fundamental properties of compression and computational time/space trade-offs. Even Apple can't design around them.
That doesn't mean Apple's hardware encoder is in any way bad or unusable. All lossy compression will be imperfect, yet much of it is useful. And most modern codecs and encoders seem to be capable of high quality results. The implications of the differences under discussion are percentages of a bitrate or tiny nearly imperceptible artifacts or breadth of available resolutions, refresh rates, and color modes or codec choice. Software encoders are always at the bleeding edge of what's possible. Hardware encoders are necessarily a snapshot frozen in silicon with limitations imposed by the implementation. The middle ground is largely already occupied by SIMD and other transform-specific ISA extensions already present in most CPUs.
> I've never enjoyed languages that plant a flag on one mechanism and force users to adapt.
Well, the hardware designers have chosen one (or at most a small number of) mechanism[s] and implemented in silicon. The farther you diverge from their implementations, in terms of abstractions, language features, and the like, the more you will pay in performance. Your choice.
Not op, but that's a very interesting proposition. While the law and legal code are technically property of the people, I'm not aware of any single point of download for it all.
There’s no single point of download for it all because there’s thousands of autonomous entities that issue law and adjudicate cases, at least 51 of them distinct sovereign entities.
We could enforce (suggest?) a common format / api at the federal level. Especially if it’s incentivized with funding that more than justifies the cost of maintenance. Similar to how federal interstate funding is only available to states with a 21+ drinking age.
Yeah, going to the courts and municipal code seems like it's going to be a heavy lift. Many of them seem to hang off of municode, though, so maybe it's not a huge number of unique crawlers.
There is none, not for statutes and definitely not for case law; even at the appellate level where you have multiple federal circuits, then 50 states, then territories, military, tribal and a whole host of other niche courts. And the appellate court systems can be split into districts, and by lower and higher levels.
Then if you want to really get into it, The People should also be able to access trial court level, and at that point you have over 3000 distinct court systems with their own access systems, usually requiring logins and CAPTCHAs, and half of them not even having anything accessible online at all, and the other half only having recent stuff online and the rest rotting in a flooded basement.
That’s awesome! I especially like RECAP as a method for freeing things from PACER.
Seems like you all are already doing a lot of what I’ve been aiming for with mine. Are there useful ways to contribute, or have you all gotten it to a pretty good place technically, and it’s mostly a matter of spreading it at this point?
No no the invisible hand of the market will fix it, you see. Car manufactures will become so big and pay so many taxes that we could pave every road with rail.
reply