timschmidt

> Cute but it's quite obvious I'm referring to

Comfortable with your own loose wording, but lawyering over others. I see.

> And no, the payload continues to fall and is now not even remotely close to being able to achieve the program goals

Payload was also much lower on early Falcon 9's. Virtually every rocket family is a family and not one model because they get stretched, engines get added and tweaked, etc. Reduced payload capacity is a boring, normal, and expected situation for early production design. Same goes for planes. What you see as failure is an initial qualified engineering milestone. It seems to me that you must understand the concept of iteration. It also seems like you think 50T to LEO is not incredible in and of itself.

Perhaps you are the sort of person who is unhappy at weddings?

This mindset that because something which is under development is not finished yet, it has failed or is failing, can only come from someone who has never made anything themselves. The misunderstanding is so complete. I suppose it's a mindset some folks have to unlearn to help themselves.

> "Starship is a successful program because Starlink makes it economically sustainable" to "I don't care or know what Starship is trying to do, I don't care or know how successfully they're doing it, but rocket go up is a fun ride already."

These are your constructions and do not accurately reflect anything I've said. It seems like you're just looking for arguments and not genuine understanding. I won't give you any more argument. Good evening.

> Starship's goals

Rockets don't have goals. People do. Rockets have features like payload capacity, thrust, cost/ton to orbit, reusability, etc. On which Starship seems to be doing excellently compared to... everyone else.

> SpaceX investors are not investing in a marginally more efficient Starlink deployment system.

IDK what any given investor's rationale is without asking them, and neither do you. Groups, like rockets, are not possessed of singular will.

> You seem to be suggesting that it's a foregone conclusion that ... Starship will achieve its much grander ambitions.

You seem to be the only one who's said such a thing. However, since you bring it up, I will point out that engineering is a process, akin to science, and success merely takes enough determination and resources to keep trying. SpaceX seem to repeatedly demonstrate the determination, and successfully launching Starlink with Starship provides the resources.

I see what they've achieved already, and expect them to continue applying the same process. I'm not sure how far they'll go. But it's a fun ride already. I trust the process. I'm a fan of the process. You and I get to have this conversation because science and engineering work, rockets fly because science and engineering work. I'm not sure how one would even attempt to argue otherwise.

Yes, that's the sentence that doesn't make much sense. Would you mind re-stating your question?

Frankly that sentence doesn't make much sense. Would you mind rephrasing your question?

And it's amazing how much easier it is to test and iterate when you're making regular flights.

Putting Starlink sats in orbit is the economic engine that pays for Starship development and infrastructure build-out. You really think you get to skip straight to the end goal without establishing a way to fund it?

Saturn V was the culmination of a loooooong development history which included many rockets in the same family (hence the V), and some spectacular RUDs.

> Now the goalposts

Milestones. Engineers deal in milestones. Goalposts are for sportsball.

For something impossible to complete, it sure seems to be deploying a lot of Starlink satellites.

They've reached orbit, and at the time of this comment are preparing to deploy Starlink sats. Which means they've successfully closed the economic development loop for the Starship program. Falcon 9 can't launch Starlink v3, only Starship can. They've already demonstrated successful booster catch. Even if they discard Ship in the ocean after every launch they're no worse off than with Falcon 9 (which also discards it's upper stage).

They'll ramp falcon flights down quickly. Ramp up Starship launches just as quickly. And in a couple years time we'll have a blooper reel like this one but larger by 10x: https://www.youtube.com/watch?v=bvim4rsNHkQ

Edit: Starlink deployed.

> I’m saying it shouldn’t be defended as good.

Thankfully, that's not a thing I ever did.

> I also suspect that few people actually believe it’s ok and these legalistic defenses are more about circling the wagons.

For me it's more about healthy boundaries and expectations. If I'm somehow paying for a project's development, I have higher expectations. If I'm not, I understand that I've chosen the dev/test track and there will be bugs and issues. The developer may choose to run off in an odd direction coughGnome3cough and my only recourse is to fork or hope someone else does. Disagreements as to how things should work happen pretty often.

I'm not defending anything or anyone. Just describing the system as it exists.

I actually think you framed it really well. No parties involved have any particular obligations to each other. Nor should there be expectations otherwise without support. It sucks to lose data, everyone knows that, and no one wants it. And identifying things which can be improved is important. I stop at expecting someone else to do something because I want them to. I might hope they would, and try to convince them.

> It's hard to imagine that any sane person who is just looking to use a popular editor would read some broad limitation of liability language like the above, and interpret it to mean, "By the way, we intend to quietly delete certain files created by a competing fork of this project whenever we find them."

Forks of projects trodding all over each others files is one of the more common problems that has happened, historically. Prior to the major efforts around freedesktop.org around configuration standardization, it was quite common. It'd be one of the first things I looked for when switching to a fork.

Equally mindblowing that folks feel someone hacking on open source software has an obligation to do anything the way they feel it needs to be done when the whole point is that anyone gets to do more or less what they want with the code.

You can't have both.

Most open source software is written by individuals who aren't paid for the effort, and are solving their own problems. Presuming that they feel an obligation to the folks who download and use their work for free seems... bold.

If my neighbor mows my lawn for free, I'm not going to complain about his workmanship. If I want the job done a particular way, the solution is to do it myself, or pay someone to do it the way I like.

Is some part of:

"Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE."

Unclear? The fact that it's part of a license does not make it a legal-system-only warning.

The software might eat your dog, and feed your homework. Run it at your own risk, and be prepared to submit patches or fork it to make it behave the way one prefers.

This gift comes with the following clauses listed plainly in the license file:

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

> every system is technically quantum mechanical but those effects are never explored afaik

Photosynthesis depends on quantum behavior: https://www.youtube.com/watch?v=rvFMBRnR3ms

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.

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

The saying is that locks only keep honest people honest. Plenty of evidence of that: https://www.youtube.com/@lockpickinglawyer

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

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

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.

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.

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.

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.

> You make it really hard to take you seriously.

Same, bud.

I find that pessimism holds most of it's practitioners back from their full potential.

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.

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's why I wrote hyperreal[2]

1: https://www.cs.tufts.edu/cs/40/docs/WhatEveryComputerScienti...

2: https://github.com/timschmidt/hyperreal

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