spartanatreyu

> I am not entirely convinced. Was not Hubble damaged and got an upgrade lateron?

It was made wrong (the mirror was shaped incorrectly).

Luckily the HST was designed to be serviced (it had components within it that would degrade over time, and some components could realistically be upgraded as technology became better), so they swapped out the optics so that it worked with the incorrectly shaped mirror.

---

> I don't think the USA could keep mega-super-duper technology hidden from others in the long run.

The only things being hidden are basically trade secret stuff, e.g. better materials, better software, better sensors, etc...

The US had a geopolitical advantage keeping their sensor tech secret. Other nations didn't know how good they were and only hid their actions to the degree they thought shielded themselves. When the knowledge eventually came out, other nations knew if they wanted their sercets kept, they would have to invest in better obfuscation.

---

> And NASA often wants more money - just take the whole search for life on planets. This is so pointless - life exists already here. What is the addiction to want to find life outside of the planet? Other than, of course, getting more money, which is understandable, but it doesn't answer the question.

Since you're not behind the rationale of curiosity, I'll present you with a utilitarian justification:

Ancient Rome had steam power (see: Aeolipile). But it was basically seen as a useless toy. It took almost 2 millennia until the Industrial Revolution happened and steam power took its rightful place in our history. Humanity got there, but it took a lot longer than it needed to.

Imagine what would have happened instead if Ancient Rome could have looked across an ocean and seen a civilisation harnessing steam power to its fullest. It would not have taken almost 2 millennia for them to catch up. They just needed a hint as to where to focus their attention.

History is littered with missed paths that could have accelerated our progress.

Newton was playing around with shaped glass and investigating optics. What if he heard of someone else seeing weird lines when they left their prism in the sun? He had everything he needed to stumble upon the ultraviolet catastrophe himself and we would have ended up with quantum mechanics centuries earlier.

Going back further, what if the Antikythera Mechanism's gearwork technology became widespread? What if the ancients had their own Babbage and created programming millennia before?

Penicillin could have been discovered even earlier.

All that's needed is a little observation of "Huh, that's weird" and everything spills out of that.

Investigating a line of inquiry doesn't guarantee that we're going to end up with something. So we have to investigate wide, rather than deep.

But imagine if we find an alien civilisation and make another "Huh, that's weird" observation. All of a sudden we have a higher confidence that an investigation down a specific path does lead to something new.

- An exoplanet not moving elliptically or hyperbolically? That'd focus a large amount of attention into overcoming previous assumptions about inertia.

- Lot of lensing effects and bursts of shifted light? That'd focus a large amount of attention into bending space.

- Seeing spectral lines that don't match known matter? That'd focus a large amount of attention into the strong nuclear force, exotic matter, magmatter, etc...

- An impossible star? That'd focus a large amount of attention into the processes powering that star.

- etc...

TL;DR: Finding another civilisation doing something basically changes the rate of return calculation for research.

> Basic counting isn't really math.

Counting most certainly is math.

Can you define or explain counting without also referencing/defining/explaining a mathematics concept?

> And it can count fine. It doesn't know how to spell.

It's the other way around, it could spell, it couldn't count the letters.

We shouldn't be surprised when this sort of thing happens in the age of LLMs.

All LLMs do is select the next word based on their training data then repeat.

When people rely on vibecoding, a non-zero fraction of users will inevitably end up with the same results.

Counting is literally a part of Mathematics.

Counterexample from only 2 months ago:

https://www.youtube.com/watch?v=iTyLHDRhwJg

I always did it as:

/**/

    Debug code to toggle on and off

/**/

    Other debug code to toggle on and off

/**/

And toggled by removing the last slash on one of the comment lines.

Having two `*` characters worked better for syntax highlighting at the time.

Then I learned about Ctrl/Cmd + / to toggle a line or region on and off.

But I still use the old technique when code editors can't handle where comments are supposed to start and stop and commenting out too much or breaking the indentation, typically breaking around modern CSS's newer features or languages embedded within other languages.

Yes, which is why you don't stop at rust.

You would choose rust (from a security standpoint) because it massively reduces memory safety issues (which from a Microsoft study was responsible for around 70% of bugs).

Then you look at things like linting, fuzzing, design by contract, proofing, deterministic test runs, etc...

As I said above: use better tools and processes.

LLMs don't fit that criteria.

Humans did do it before.

------------------------

It's also worth pointing out that the developers at Mozilla literally decided to make a brand new programming language (Rust) that eliminated an entire categories of bugs and started working on a new browser (Servo) where its components could be switched into firefox.

Then Mozilla fired the team working on it.

Lesson 1: Better tools and processes eliminate bugs.

Lesson 2: If you don't have the tools, make them.

Lesson 3: Mismanagement leads to security vulnerabilities.

> I'm looking forward to trying out Safaris new ability to vibe code extensions that will modify websites to remove annoyances.

Sounds like a great way for people to get hacked.

> AI is helping patch previously unrealized holes.

AI is also making plenty of holes.

I have not seen a single case of anything that an AI has found that could not have been automatically found without AI.

Well duh, this is how codepen works!

Try this:

1. Open one of your codepens

2. Now open the same codepen in a different window so you have two open at the same time

3. Now type in one window

4. Watch it s̶e̶n̶d̶ ̶y̶o̶u̶r̶ ̶c̶h̶a̶n̶g̶e̶ ̶t̶o̶ ̶t̶h̶e̶ ̶s̶e̶r̶v̶e̶r̶ ̶t̶o̶ magically update all other clients

---

Also, notice how your browser never had to download typescript, sass, babel, tailwind, etc...?

That's because what you type gets sent to the server to transform it into compiled html.

> Triple fold just seems awkward as heck, plus you have to design the UI for it around the fold section.

You don't have to design UI around the fold, it's seamless in regular use.

It's just a tablet.

Movement is solved by tracking the camera's position and projecting the background from there.

Proof of captured image with hardware-based-attestation can be increased by adding extra information besides the RGB channels, like depth mapping (which a projected screen wouldn't be able to fake), and eventually light field recording (plenoptic imaging, e.g. Lytro).

> What's up with all the negativity?

It's the horrible form factor.

I listed the 3 ways to make a folding phone (with examples) in my comment here: https://news.ycombinator.com/item?id=49636355

If they had chose either of the other two folding formats, and reduced the amount of screen they cut off in the corners, they probably would have had gold on their hands and shifted the market towards foldables.

Instead, they chose the bad one.

> I think the Duo looks great.

I could not disagree more.

There are 3 ways to fold a phone:

1) The trifold: A phone that folds out into a tablet. (e.g. https://consumer.huawei.com/my/phones/mate-xt-ultimate-desig...)

2) The clam shell: a phone that folds down into a more compact form. (e.g. https://www.jbhifi.com.au/products/samsung-galaxy-z-flip8-5g...)

3) The book: an awkwardly squashed phone that folds out into two awkwardly squashed phones taped together. (e.g. https://news.microsoft.com/surfaceduo/)

The trifold fits in your pocket.

The clamshell fits in small pockets (making it popular for women).

The book in a pocket is just uncomfortable (assuming it fits in at all).

They looked at all the folding phone formats and went with the worst possible one: the one that you can't fit in your pocket comfortably.

Further more, they looked at the worst book fold and decided to associate themselves with it by stealing its name, The S̶u̶r̶f̶a̶c̶e̶ Apple Duo: https://news.microsoft.com/surfaceduo/

--------------------

Apple releasing this is exactly what it looks like when there's no one helming the wheel.

> JXL was dead. Apple is who brought it back to life

No, it was actually the PDF Association.

They added JXL to the PDF standard.

If google wanted to maintain support for displaying PDFs, they would need to add support for JXL.

Remember all those times you needed to make a change to something a few minutes before it was submitted/presented?

Imagine if you couldn't, because you needed to charge your mouse first.

Not true.

MacOS releases a new version each year, the current MacOS landscape looks like:

- MacOS Sequoia (previous version, everything works as expected)

- MacOS Tahoe (current version, broken experience, basically Apple's "Windows Vista/8 moment")

- MacOS Golden Gate (next version, fixes what was broken in Tahoe, comes out in a month)

I'm on MacOS Sequoia because I have things that can't be broken by updating to Tahoe.

I also cannot test how my websites/webapps will work in a month, because Safari's beta (called Safari Technology Preview) only works on Tahoe and Golden Gate.

I cannot wait a month to update to Golden Gate because Golden Gate drops support for my iMac.

And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them.

I can test the Webkit browser, but that doesn't include the Safari specific changes that apple makes which I need to be able to test.

---

So, I can't test Safari until I wait a month and purchase a new apple machine.

(Oh by the way, apple keeps cancelling orders for new machines)

You wouldn't want to hide scrollbars though.

You'd want to make it so either:

a) There is nothing to scroll in the first place, so you don't need a scrollbar

b) Capture the pointer so all interaction only occurs within the game's area.

> Browsers seem to release a major new version like every 2 weeks now. So this statement does no longer hold true. You'll have a lot of users with broken results, if you follow that advise (everyone who uses a ESR or is otherwise limited with updates and behind a month)

Nope.

Safari only releases a major version once a year, so by only using features that are available in the last two major versions of each major browser, you're already waiting at least 2 years.

> I'd say for safety one should target the browsers of the last 4 years at least.

No.

Supporting browsers that old incentivises users not to update, which causes them to be insecure.

Better they know that something is broken so they have a greater incentive to update.

Baseline is already shown on both caniuse and mdn, which is why I suggested them.

> I always tell myself that I should use backwards-compatible CSS only. > > I vividly remember IE and many hacks to have css elements properly working in it…

The common advice now is to only use CSS that is supported in the last two major versions of each major browser. You can check any css property's support here: https://caniuse.com/

> Imho this is a reason why markdown and other rich-textual formats appeared.

Markdown is a superset of html and through it contains css through the style element

> Btw is there a some “w3schools” for recent CSS?

CSS is constantly changing, I'd recommend the following for how to apply new CSS features:

- https://www.youtube.com/@KevinPowell

- https://ishadeed.com

- https://www.joshwcomeau.com

MDN is the best technical reference: https://developer.mozilla.org/en-US/

- You can search any css property in there and it will return all the rulesets for that property.

To see how people are using CSS, I'd recommend:

- https://codepen.io/

- Mastodon/fediverse

  - Reason: All other social networks only have webdevs who sip the coolaid of whatever trend is happening at the moment, they're not actually interested in learning what CSS can do. However, the web devs in the fediverse are actually interested in what CSS can do.

To see future CSS:

- You can see the proposals here: https://github.com/w3c/csswg-drafts/issues

- Proposals often require experiments which you can find on mastodon/fediverse. For example: https://front-end.social/@kizu

There's also the yearly State of CSS survey to get an overall sense of it: https://2026.stateofcss.com/en-US/

This is the first time I've ever heard Xcode be called clever.

Side note: This feature is in vscode: https://code.visualstudio.com/docs/editing/userinterface#_mi...

> It's an invention that can invent things on its own

No. It can't invent things on its own, it repeats what it's already seen.

People keep seeing LLM outputs without seeing the original source first, then exclaim: The LLM invented it.

This reminds me a lot of the articles at: https://ciechanow.ski/archives/

Not just in terms of presentation, but also quality.

Amazing!

You can, the file just has to be named "index.html".

> this TS migration started long before AI was able to help

Yes, but that doesn't mean it wasn't also "helped" along by AI.

See:

1. https://github.com/microsoft/typescript-go/pull/1387

2. https://github.com/microsoft/typescript-go/pull/2978

3. https://github.com/microsoft/typescript-go/pull/1138

4. etc...

Copilot is the "user" with the 2nd most commits (and the 15th and 19th too), and that's just what's been tracked in git.

---

The initial port was automated, then devs got in there, then LLMs got in there.

Deno's permissions are closed by default.

Node's permissions are open by default.

---

Let's suppose that node and deno both have the same 20 permissions.

If we have a project that needs read access to one specific folder and write access to another specific folder, that means:

For deno: I need to turn on 2 permissions to those folders. For node: I need to go through all 18 other permissions to turn them off, and also turn 2 permissions to access only those folders.

So from the get go, node is more work.

---

We're all lazy creatures.

We might forget to turn off the permissions, or worse: think we're safe because we only turned off what we thought were the relevant permissions.

Example:

My project reads this folder and writes to this other folder, I'll turn off the network permission so my data can't be exfiltrated, and commands can't come in down the wire if a dependency becomes part of an attack. And because I'm smart, I'll also turn off the FFI permission so a dependency can't communicate with a program outside of node.

Safe right?

No. The hacker took over a dependency and called cURL through a new process.

There's a million ways to go around things with an open-by-default security model.

Open-by-default is a broken design from the start.

It's a lesson that's been learned over and over again.

A closed-by-default security model is the only way.

---

Deno uses a closed-by-default security model, and implements it in a way that isn't annoying. It just runs your program immediately then when it tries to call a function that requires a permission that it doesn't have, it doesn't crash, instead it pauses execution and asks if it can have that permission. If you say yes, it remembers and doesn't bother you again, if you say no, then the function throws an error to be caught by your code or to bubble up uncaught and crash the program to prevent anything not permitted by you taking place.

The other great thing about it, is that you can run something on deno instead of node, and see which permissions it asks you for.

You'd be surprised how not safe some things are. Once you try it on a few example projects, you'll instantly see why npm has so many hacking incidents. It's an eye-opening anxiety raising experience.

On the other hand, when you run a project and see basically no requests for permissions, you can feel a sense of relief that it can only do what it says on the tin.

We already have alternative and superior proposals, it's called Deno.

It's node + npm compatible and its permission system locks everything down by default.

If you know ahead of time, you can turn on which permissions something is supposed to have in the config file.

Or you can just not use a config file at all. Anytime it needs a permission: it asks you what it wants. You can say yes or no, and those are saved in the config file for next time. If you say no, the script throws an error where it tried to access something it didn't have permission for.

---

Example:

- My linter wants access to my file system?

  - You can have read access to ./src/ts/

- My bundler wants read and write access to my file system?

  - You can have read access to ./src/ts and write access to ./build-output

  - Huh, what's that? The bundler was trying to both read and write a file in ./src/ts?

  - We don't want input files getting overwritten, that's a recipe for hard-to-diagnose race conditions. Looks like the permission system did more than just keep things secure, it's like a type system for IO.

  - Oh, look at that, there was a very subtle bundler misconfig, let me fix that now. How long would that have existed if we didn't use deno...

- Oh what's this? An updated dependency I've been using for 6 months suddenly asking for access to my .env file, and asking to run curl in a separate process? How about "no". Why would a simple DOM utility dependency be asking for those permissions? Ah, looks like it was part of a credential stealing supply chain attack. Glad I wasn't using node.

---

Addendum: Node now has a permission system, but it's broken by design so it's useless.

It's not just the terrible charging that makes it a bad product.

It's also the terrible ergonomics.

It's the epitome of putting form before function. It's a desk ornament that leads to frequent injuries with use. See: https://www.google.com/search?q=magic+mouse+injury