News for hackers. Stuff that matters.

unexpectedtrap

Re:Updates to Full Disk Access in macOS on Saturday October 03, 2026 @08:28AM (#49943695)
Ironically enough, the UNIX fathers themselves realized that the hidden files idea was terrible and in the 90s kicked them off completely out of Plan 9 and moved user configs to the $home/lib. And yet we still have our home directories being insanely cluttered with dot files.
Re:Show HN: What if the speed of light was 5 km/h? on Thursday September 10, 2026 @08:55AM (#49642966)
That’s just the aberration, no? I.e., you can simply smash A and observe some rotation. Since there are no non-collinear accelerations in this case, it’s certainly not the required effect (which is called Wigner rotation).

In the sources I see that the acceleration is applied simply by utilizing a velocity‐addition formula (see https://github.com/dbrant/relativity/blob/fcc20fb18381959ac2...), so no Wigner rotation appears. I guess all the fancy stuff related to how time passes in an accelerating frame (like https://en.wikipedia.org/wiki/Twin_paradox#Difference_in_ela...) is also wrong in this simulation because of that.

You can however observe a mathematically equivalent effect in hyperbolic games, e.g., in Hyperbolica. Hyperbolica even has a quest about rotating a chest by moving it along the axes. On the hyperbolic plane it’s of course not about acceleration but about a winding number you’re doing around some point, but it’s still fun.

Re:Stop Making TUIs on Saturday August 22, 2026 @09:29AM (#49399574)
Plan 9 is essentially exactly that, which clearly was inspired by the Oberon’s GUI. By the way, does then Emacs count as such? Or maybe you should take a look at Genera, however, I’ve never really tried it.

Also the original Metro design as in WP 7/8/8.1 or Windows 8/8.1 relied heavily on the pure text, and the only place populated with a lot of icons was that iconic tiled start screen, although this is probably not what you mean.

Using LLMs to generate piles of code and/or proofs of dubious quality is very questionable thing, and I understand these non-stop debates about it.

But in this case, as using plain brute force is already quite a common thing in searching for counterexamples, using LLMs as a sort of more advanced brute force seems to be just the right thing to do, so I struggle to understand so much hostility to this approach.

Re:A Perfectable Programming Language on Monday April 13, 2026 @12:48PM (#47754738)
>I would expect it to require a proof that 1 - 2 is non-negative. That's kind of the raison d'etre of Lean isn't it?

The reason is to be able to write mathematical proofs, including proofs about your code, but not to attach proofs to every single function. This definition of subtraction does not prevent you from reasoning about it and requiring `a ≥ b` in the proofs/code for which this is really important.

>Requiring explicit proofs for every subtraction was presumably seen as too onerous.

Lean can deduce proofs implicitly as well. It’s just not a very reliable mechanism. That is, imagine your code breaking after an update, because Lean suddenly can’t deduce `a ≥ b` automatically for you anymore.

>Which is fine... BUT they then should have said "so we're going to define a more convenient operator which is LIKE subtraction but isn't actually standard subtraction, and therefore we won't use the standard subtraction notation for it".

What is a standard subtraction over natural numbers at all? As you know, under a standard addition natural numbers form a monoid but not a group.

Re:A Perfectable Programming Language on Monday April 13, 2026 @10:19AM (#47752367)
>It definitely is a bad convention because it's highly surprising.

You know that `Nat` represents non-negative numbers, and you see that `1 - 2` does not produce a compile error. What value do you expect then? What’s so surprising about choosing zero as a default value here? Do you expect it to panic or what?

Re:A Perfectable Programming Language on Monday April 13, 2026 @08:35AM (#47751090)
No, it’s still linked dynamically and its kernel is still in C++ (see https://github.com/leanprover/lean4/tree/master/src/kernel, this part of a codebase has hardly changed since Lean 3). Almost all the space in the package (more than 2.5 GiB) is taken up by .olean/.ilean/.ir files, approximately 1 GiB of which is generated from the code of Lean’s frontend itself (i.e., parser, elaborator, core tactics, and so on) and the other 1 GiB from a standard library. As you might guess, these files are IR and essentially a compiled Lean’s environment (something like a Lisp image), so that Lean can load them straight up without recompiling and rechecking everything.

There were some proposals like compressing all the .olean files, but (as far as I know) none of them were implemented. Well, even if some proposals were implemented, their contribution was effectively negated anyway.

Re:A Perfectable Programming Language on Monday April 13, 2026 @04:39AM (#47749389)
Who said that it should be a compile time error? That’s just a convention, and this is definitely not a bad one. No one is going to like the need to pass each time a proof that `a ≥ b` for every `a - b` invocation. Taking into account that this proof will most likely be an implicit argument, that would be a really annoying thing to use.

On the other hand, array indices by default do require such a proof, i.e., this code produces a compile time error:

  def x := #[1, 2, 3, 4]
  #check x[7]
Kevin Buzzard even wrote a blog post about a similar question about division by zero: https://xenaproject.wordpress.com/2020/07/05/division-by-zer...
Re:A Perfectable Programming Language on Sunday April 12, 2026 @10:40PM (#47746948)
Unfortunately Lean’s distribution went from somewhat about 15 MiB in times of Lean 3 to more than 2,5 GiB when unpacked nowadays for no good reason. This is too much. Even v4.0.0-m1 was a 90 MB archive. Looks like that Lean’s authors do not care about this anymore.

Lean 3 was the least bloated theorem prover among Lean, Coq and Agda, and Lean 4 is the most bloated among this Big Three. This is very sad.

Personally, I stopped using Lean after the last update broke unification in a strange way again.

Re:Woxi: Wolfram Mathematica Reimplementation in Rust on Sunday March 01, 2026 @12:58AM (#47204114)
Glad to see Rust project under AGPL-3.0. I wish to see more Rust projects under (A)GPL, because (A)GPL is rare in the Rust community for some reason.
Re:om on Thursday February 26, 2026 @02:23AM (#47162961)
So instead of using programming languages designed specifically to effectively express algorithms and data structures, we are going to use natural language like English that is clearly not expressive enough for this? It’s like rewriting a paper about sheaf cohomology in plain English without any mathematical notation and expecting it to be accessible to everyone.
Re:The Influentists: AI hype without proof on Thursday January 15, 2026 @03:11AM (#46629596)
I saw this DSL on HN yesterday, and this syntax is total garbage. It’s some stupid mixture of different PLs. Are you seriously OK with this so that you keep posting it here? I don’t even want to look through source code knowing what garbage it is at the surface level.
Re:Windows 8 Desktop Environment for Linux on Tuesday January 13, 2026 @02:48AM (#46598296)
It’s funny to see that even nowadays just a few people understand Windows 8’s UI, while the majority in these comments just blindly shits at it. Not surprising, though, since there are so many happy users of crap UI’s like KDE around.

Sadly, this clone looks very‐very bad, just like millions of WP8‐like launchers compared to the actual WP8.

Re:A Love Letter to FreeBSD on Monday December 01, 2025 @08:28AM (#46107142)
They now provide at least somehow working x86_64 images. It’s of course funny for a project started in the 90s to get x86_64 support only in the 2020s, but it’s still progress in relative terms.
Re:A Love Letter to FreeBSD on Monday December 01, 2025 @08:18AM (#46107046)
No, it’s just you having some strange prejudices about these words (probably driven by blind faith in some overhyped technologies), so go better overregulate your preferred echo chamber.
Re:A Love Letter to FreeBSD on Sunday November 30, 2025 @09:34PM (#46102879)
I feel the same, because it seems that the only desktop-ready OS under GPL today is GNU/Linux, and it feels too bloated nowadays (not to mention that Linux is effectively stuck under GPLv2). Something like FreeBSD feels much lighter and better still being desktop‐ready. Looks like that guys from Hyperbola think the same and that’s why they are doing HyperbolaBSD. Btw there’s some progress in GNU Hurd, but they are still far from being desktop-ready.
Re:A Love Letter to FreeBSD on Sunday November 30, 2025 @09:22PM (#46102772)
IANAL, but you can’t actually just relicense code, even if it’s under BSD‐like license. What you can do is to release this code in the binary form without providing the source code.
Re:Lean proof of Fermat's Last Theorem [pdf] on Thursday August 21, 2025 @02:06AM (#44969540)
Correctness of the kernel and consistency of the theory implemented in it are different things. Gödel’s theorems prevent you from proving the latter, but not the former.
Re:Lean proof of Fermat's Last Theorem [pdf] on Thursday August 21, 2025 @01:35AM (#44969349)
Euclid’s Elements “rigorous proof” is not the same thing as the modern rigorous proof at all.

>But the infinitesimal methods used before epsilon-delta have been redeemed by the work on nonstandard analysis.

This doesn’t mean that these infinitesimal methods were used in a rigorous way.

Re:The math is haunted on Saturday August 02, 2025 @01:41AM (#44765135)
“Paraconsistent logic” or “paraconsistent set theory” is what you are searching for.