timschmidt

Palm's Pre[1] supported multi-tasking, having multiple emails open at the same time to read and compose, unified instant messaging, copy/paste and myriad other features iPhone didn't have at the time.

1: https://en.wikipedia.org/wiki/Palm_Pre

> Considering practically every smartphone to this day is derivative of the 2007 glass slab hardware design (and software UX), I'd say they were on to something

Lowest cost of production is what that formfactor provides.

Palm's devices, by contrast, felt like a polished river stone in the pocket. I know which I prefer.

> Let me know when your local OS does ...

Sounds like Plan 9. Which would put that around 30ish years ago. Mainframe OSes can probably make similar claims even earlier.

> Ah, the Voight-Kampff test. Should I be worried about where this is going?

It’s a shame she won’t live – but then again, who does?

I've rolled the stack into a monorepo under https://github.com/timschmidt/csgrs which should make it much easier to work with.

This feels uncannily like the ancestor of the Voight-Kampff test[0]

0: https://www.youtube.com/watch?v=Umc9ezAyJv0

> AutoCAD, and Solidworks too

You may want those in new high-performance infinite precision: https://github.com/timschmidt/hyperreal

Exact curves: https://github.com/timschmidt/hypercurve

Meshes: https://github.com/timschmidt/hypermesh

and more in the ~22 crate stack.

> They easily could build near heating system or cooling the water down in another probably big facility close by and send it to the city

Nope. While it's technically possible via natural gas fuel cells which are near 100% efficient in combined cycle electric / heat recovery use as compared to our city's existing ~35% efficient combined cycle natural gas fired steam turbine. And one such installation was proposed for this city in the 24MW range. Our beloved local citizens believed it, without reason and in open opposition to openly shared information to the contrary, to be a water guzzling/polluting, pollutant belching, energy consuming, mass surveillance enabling dystopian thing.

Flushed $120M in local investment down the toilet and signed up for worse air quality from ageing inefficient infrastructure because a datacenter is a big faceless thing that's safe to hate.

Same as everyone else's: bad when they do it to us, good when we do it to them.

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