Hacker Newsnew | past | comments | ask | show | jobs | submit | arijun's commentslogin

> moved a lot of stuff "inside" the engine

The level that they managed to fit everything inside of a simple-looking package was so high that the CEO of ULA (the Boeing/Lockheed Martin rocket company) thought they were lying when they first showed pictures [1].

[1] https://www.benzinga.com/news/24/08/40279896/spacex-presiden...


The reason he was so skeptical is that for other engine manufacturers, there are generally different teams working on different parts of the engine, and because Convay's law the final artifact generally ends up looking like the organizational boundaries of the company that made it, with cleanly separated parts for every sub-organization that you can see in the final assembly. One of the things that SpaceX is good at is optimization across these kinds of boundaries, integrating hardware in ways that would be difficult for a more traditional organization.

The way it was explained to me early on was that the newest Raptor engines had simply eliminated many of the different types of test sensors, specifically because sufficient testing had been performed that they weren't getting useful data out of them any more.

I'm not some kind of insider, though.


It honestly makes sense now that I'm looking at a progression down the line - https://i.redd.it/f7prq0x08qgd1.jpeg

Just continual tweaks and refinement to keep slimming down the packaging.


Hey, where did you get that image from?

First time I see it!


That photo is thrown around a lot in the Spacex fan community. At least it was. I think the photo is at least two years old.

I suspect that many of those pipes are for testing instrumentation of the early models. And those that remain necessary, might be built into channels in the engine body now, like how a carburettor is built. That's much simpler and cheaper to manufacture and maintain, not to mention more reliable.


I still don't see TVC there. I think Shotwell was exaggerating.

Here it is, already mounted on Starship - https://i.redd.it/q5dea3tsf60h1.jpeg

The TVC is clearly visible on one of the center engines in that photo, thank you. It's just about the only thing on there other than the thrust chamber, turbopumps, and bell!

Tory Bruno was talking about different configuration.

It seems like running with sandbox-exec should remove pretty much all the potential for an app to cause harm… is there a reason why it’s not the default, especially for these certificate-less apps?

I believe that at least app-store apps are already ran in some sort of sandbox.

I don’t think steam needs Rosetta anymore.

Just checked. Still needs it. I don't have Rosetta installed and I don't want to install Rosetta just to be able to use a game controller with DuckStation or Aethersx2. When I can also connect a PS4 controller and not need any of that.

You have an old Steam.app stub, download the latest one and rosetta will not be necessary.

If you had rosetta it would be able to self-update to the new universal binary, without it you have to do this one update manually.


I downloaded from here and I instantly get a pop-up about requiring Rosetta.

https://store.steampowered.com/about/


Odd if true. It's clearly a universal binary, not sure what's going wrong for you.

$ file steam_osx

steam_osx: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]

steam_osx (for architecture x86_64): Mach-O 64-bit executable x86_64

steam_osx (for architecture arm64): Mach-O 64-bit executable arm64


This appears to only be in the Steam beta - the version available for download still requires Rosetta. There doesn't seem to be a direct download for the beta - you have to opt into it after installing Steam.

Not the OP, but I just downloaded the latest stub from an M2 MacBook Air using Safari and it appears to be an x86_64-only binary:

  % file /Volumes/Steam/Steam.app/Contents/MacOS/steam_osx 
  /Volumes/Steam/Steam.app/Contents/MacOS/steam_osx: Mach-O universal binary with 1 architecture: [x86_64:Mach-O 64-bit executable x86_64]
  /Volumes/Steam/Steam.app/Contents/MacOS/steam_osx (for architecture x86_64): Mach-O 64-bit executable x86_64

CMD+I on Steam.app says: "Application (Intel)".

% file steam_osx

steam_osx: Mach-O universal binary with 1 architecture: [x86_64:Mach-O 64-bit executable x86_64]

steam_osx (for architecture x86_64): Mach-O 64-bit executable x86_64


Mobileye still sells to a large fraction of manufacturers (I think a plurality if not majority). You will still get variation in implementation, as Mobileye only does the sensing side, and the integration is done by the OEM.

Tons of consultants are missing expertise in their clients' wheelhouses. The client and consultant each have domain knowledge, and when those domains overlap, there might be conflicts.

If you hire an architect to redo your house, it's fine to say "I see where you're going with this thing for my kids, but I know them and they will never go for it."


I think the issue comes with unknown unknowns. Before Fukushima someone might have said the same thing you just have, but a new disaster still came along and caused a lot of issues. I am still bullish on nuclear, but I think waving away concerns might do more harm than good.


Fukushima was a known risk though, they just never bothered to fix the problem. Plus just being planned in the 60s meant the initial design was born only about 15 years after nuclear power was invented. Fukishima was like driving around in a Model T, being told original brakes and tires and lack of seatbelts were unsafe, but still being regularly driven down busy roads without bothering to upgrade those features.


You reckon during the 44 years Fukushima Daiitchi operated there were no systems control and data acquisition upgrades?

And you reckon that the site operated for 44 years on a Gen II design without melting down is somehow an insisted or how unsafe those reactors were.

If that earthquake and tsunami had been only a bit different in either magnitude or location, those reactors could be operating still now.

Or if the plant operated had hardened those backup generators and water pumps a bit more.

There are 70 AP1000 reactors in operation, construction or planned.

Look at this:

Because of its simplified design compared to a Westinghouse generation II PWR, the AP1000 has:

50% fewer safety-related valves 35% fewer pumps 80% less safety-related piping 85% less control cable 45% less seismic building volume

Isn’t this the kind of thing hackers and tech advocates should be getting a raging hardon over.

This reactor does nearly twice as much as its predecessor using half the materials to build, at least for some systems.


Fukushima failed because of the aftermath of a 9.1 earthquake.


Huh! News to me. I thought it was a CIA false flag Mossad MKUltra LSD Lizard people remote viewing black ops program.

And your telling me it just a regular commercial off the shelf run if the mill garden variety earthquake.

Man to I need to touch grass.


Unknown design flaws in old nuclear power plants wouldn't be fixed in new nuclear power plants, unless if by chance.


I may agree with your conclusion that old plants are safe enough (or at least take a deep dive study to see if their expected externality is worse than whatever would replace them). However:

> the worst disaster to ever happen without any external factors

The problem is external factors happen. You can’t just raise your hands up and say “wasn’t my fault,” when they do. A tsunami washing over a solar farm would be a lot safer than what happened at Fukushima.


The Fukushima quake was a truly extraordinary outlier though!

4th biggest quake ever recorded in history hit at the exact spot where the tsunami could overpower the protective wall at the reactor. Yet nobody died from the radiation.

Meanwhile the 20k people who died in the tsunami are forgotten. No one demands we stop building cities by the ocean.


    > Meanwhile the 20k people who died in the tsunami are forgotten.
You are wrong. They are not forgotten.


TreeSitter is an amazing tool but is (purposefully) quite limited compared to an IDE--it doesn't even cross file boundaries, so go to definition is a non-starter. Zed uses LSPs like Rust Analyzer to fill that role.


What is Ghostty's advantage over Alacritty?


I think Mitchell outlined his vision for libghostty pretty well here: https://mitchellh.com/writing/libghostty-is-coming

Alacritty is already pretty performant (relative to a lot of the other terminal emulators), but my read is Ghostty has been going hard over performance/standards/protocols (like Kitty).


The maintainer doesn’t have bad temper.


I did consider that. I remember nope-ing out of alacritty in the early days after seeing the developers response to people requesting a scrollback buffer. It amounted to something like "I use tmux, and if you don't, you use the terminal wrong." It left a bad taste in my mouth.


One would be support for ligatures


Ligatures are a renderer issue, so using alacritty as a lib wouldn't have this issue (it does demonstrate their hardline stance). Another example that would translate is how long it took them to support disambiguation of key combinations: https://github.com/alacritty/alacritty/issues/6378 (2019-2023). Of course, the maintainers are free to do whatever they want with the project - but such things do make alacritty-as-a-lib an exceptionally bad choice for situations where you want things to just work.


The Zed terminal already supports ligatures.


I suspect you may be operating in "Restricted mode," aka it doesn't know if it can trust the directory. In that mode, the main tools like Rust analyzer are quite restricted. All of your complaints should be resolved once Rust Analyzer/basedpyrite are up and running.

I do think they should have a more obvious warning that the current directory is untrusted, right now the little green warning in the corner is way too unobtrusive and will result in many people having the same issue as you.


Nailed it! I will do some more experiments and report back.


You should edit your original comment since it was user-error not the app being inferior.


Is it really user error if the default for an application is to behave poorly?


Done; ty.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: