MurphyA/hacker-news huggingface dataset:
by bikenaga | 2025-08-30 00:00:30+00:00
On the positive side:

Bourbaki is known for their "definition-theorem-proof" style, which for a while influenced a lot of mathematical writing. It makes the logic of the presentation easy to follow. The proofs are complete and fairly clear. The logical order within books and in the series of books as a whole is also pretty good - if you read pages 1 through n in the books, you have the prerequisites to read a proof on page n + 1. There is a good index, a table of notation, exercises (at the back, not by section), and a table of contents (at the back, since the books are in French).

They probably originated the "dangerous bend" symbol (a Z-shaped curve in the margin) to indicate a tricky or subtle point.

They're pretty good as references (to look up the proof of a result, or read about single topic).

On the negative side:

There is little exposition in the sense of motivation for what is presented, or applications.

I'm looking at "Algèbre - Chapitre 10 - Algèbre homologique" (the only Bourbaki I own). In the introduction, they say:

"Le mode d'exposition suivi est axiomatique et procède le plus souvent du général au particulier."

"L'utilité de certaines considérations n'apparaitra donc au lecteur qu'à la lecture de chapitres ultérieurs, à moins qu'il ne possède déjà des connaissances assez èntendues."

Thus, you won't find applications, or many examples - just definition-theorem-proof.

It's assumed you know why you're reading the material, and so don't need to be told.

This particular volume is a little unusual for the series in that it has lots of pictures, but that's only because this is homological algebra, so there are many commutative diagrams. Most of the volumes are just walls of text (though the formatting and the production tend to be very clear).

(I believe they actually wrote some historical remarks in some of the books which were collected in a separate volume - I don't see any historical material in the volume I'm looking at, however. The members were not unmindful of things like history: Dieudonne wrote an excellent history of algebraic and differential topology, and Andre Weil wrote a book on the history of numbers.)

The fact that it took a while for many of the volumes to be translated from French to English may have deterred some English readers (though mathematical French is not too hard to understand even if you don't know French [like me]).

On the whole, (in my opinion) the presentation is too relentlessly formal for most people to try learning a subject (as opposed to a small topic) by reading Bourbaki. They did produce a "definitive exposition" of the subjects they covered, in the sense that the results and proofs are there. It's just that most people would have a hard time learning any of the subjects by reading through the books.
by mactavish88 | 2025-08-30 00:00:51+00:00
> A lot of engineers design by trying to think of the “ideal” system: something well-factored, near-infinitely scalable, elegantly distributed, and so on.

> Instead, spend that time understanding the current system deeply, then do the simplest thing that could possibly work.

I'd argue that a fair amount of the former results in the ability to do the latter.

There's a substantial amount of wisdom that goes into designing "simple" systems (simple to understand when reading the code). Just as there's a substantial amount of wisdom that goes into making "simple" changes to those systems.
by zenoprax | 2025-08-30 00:01:23+00:00
> email heavy workflow

What do you mean by this? I send 5-15 emails a day at a minimum throughout the day and receive just as many directly with another 2-3x as cc in various distribution lists (which I read in full). Add in server notifications, automated reports from data processing scripts, and the generic info@company.com inbox and it's probably close to 100 in a day with ease. Lots of skimming and Ctrl-Q'ing and it's hardly a burden.

The lasting power of email is that it's one of the few federated communication channels that has a global network effect. Email and chat are two different media for different purposes. You have plausible deniability when a single message in a group chat is missed. When an email is sent to the team with a change in procedure you can have some expectations that it will be seen and it also provides a one-one or one-many channel for clarification.

I'm not familiar with how the sales world works but I use email every day with clients, vendors, the team, my boss(es), and many other intra-company relationships. I think you have a lack of imagination in this regard :)
by throwawaylaptop | 2025-08-30 00:01:56+00:00
Almost every company on earth has this. I worked in car sales where I was making 5x some people, working the same hours. Yet there was a superstar making 50% more than ME (so 7-8x some other salespeople) and worked less hours, AND took Sunday off.

The general manager took Saturday and Sunday off, and made 400k a year. (This was a large dealership).

The mechanics made from $40k to $120k a year.
by robwwilliams | 2025-08-30 00:02:50+00:00
Agreed. I actually want and need Claude and other LLMs to learn from my interactions with them. Exceedingly frustrating that LLMs do not yey hold a longterm memory or embedded trace of conversations per user. I have been asking Anthropic for this option as an opt-in for 6 months.

Sure, I understand the concerns many if you have.

But in my niche areas of cognitive research, genetics, and neurophilosophy I need Claude to be much smarter than it is now. I am happy to share what I know with Anthropic so that zi eventually have a better companion thinker.
by GMoromisato | 2025-08-30 00:02:56+00:00
Parsing XML is relatively trivial--I'd never use regex, of course, but a basic recursive descent parser can do it pretty easily. I mean, the whole point of XML is that it's supposed to be easy to parse and generate!

Namespaces add a wrinkle, but it wasn't that hard to add. And I was able to add namespace aliasing in my API to handle the two separate "standard" namespaces that you're talking about.

But you're right about OPC/OOXML--those are massive specs and even the tiny slice that I'm handling has been error-prone. I haven't dealt with multiple internal files, so that's a future bug waiting for me. The good news is I'm building a nice library of test files for my regression tests!
by kentm | 2025-08-30 00:03:00+00:00
People who can utilize the tooling to process petabytes of data efficiently aren’t the ones that are catching flack. The people I’m thinking of basically run massive inefficient SQL queries and then throw their hands up when it runs slowly or gets an oom error. They don’t even know how to do an explain plan. And if you try to explain to them things like partitioning, indexes, sketches, etc then they are not able to comprehend and argue that it’s not their job to learn, and that it’s the “proper engineers” job to scale the processing.
by aborsy | 2025-08-30 00:03:15+00:00
Why can’t the user enter the encryption passphrase in DSM, which is actually the default in LUKS and allowed in TrueNAS etc?

The DSM itself lives in an unencrypted partition or volume. Applications with data in encrypted volumes will be inaccessible until the volumes are unlocked.

As usual, there is an easy workaround. You can run a KMIP server in a docker container and set up an external keystore. Once synology allows you to proceed with volume encryption, you can discard the KMIP server if you want and use the recovery keys.
by ux266478 | 2025-08-30 00:04:20+00:00
Reading on from that he says:

> If the platform really needs to watch every cycle that tightly, you aren't going to be a general purpose platform, and you might as well just make a monolithic C++ embedded application, rather than a whole new platform that is very likely to have a low shelf life as the hardware platform evolves.

Which I think is agreeable, up to a certain point, because I think it's potentially naive. That monolithic C++ embedded application is going to be fundamentally built out of a scheduler, IO and driver interfaces, and a shell. That's the only sane way to do something like this. And that's an operating system.
by Nevermark | 2025-08-30 00:05:00+00:00
Ah! I get the point.

Because the discontinuity occurs at an un-constructible r, the constructible limit "process" of x approaching r, never includes r. So f(x->r) encounters a limit of 0. And 1 from the other side.

That does leaves the validity of defining continuity of constructible functions over constructible reals intact.

It is only a problem if un-constructible numbers are "brought" in.

Previously you stated:

> Basically all of calculus needs all the reals because if you don't you get some really pathological results.

This is then what I don't understand.

Why would un-constructible reals be needed?

I would agree that all constructible reals are needed (after all, constructible functions as a class are by definition, sensitive to constructible reals as a class).

But why would un-constructible reals be necessary for anything?

At best I can see them as a kind of contrivance that shortens some proofs, that could be made without them with more careful reasoning.

But ... ?

--

> However, (because of Cantor's diagonal argument) we know there infinitely more real numbers than constructible real numbers.

Cantor uses sleight of hand out of the gate. From out of nowhere, he postulates that there can be infinite digit numbers, without finite description.

That is really interesting thing to suggest.

Because until then, numbers were built up in steps, from the concepts of increment, repetition, and orthogonal units (to post-formalize the actual progression of informal to formal).

Constructibility (in practice and theory) was inherent in what it meant to "have" a number.

A number is a relationship. A relationship isn't a relationship because I can pick a name "r" and say it is a relationship.

But suddenly Cantor talks about infinite digit numbers with no expression. No defined relation. And then an (attempted) list of all of them.

So constructibility of numbers is abandoned as a precondition for his arguments. Before any point of diagonal incompleteness is made.

It gets worse. Even if we had access to magic oracles that will generate any number of un-constructible reals we desire, with any number of digits supplied, so we can add, subtract and compare them: The process would remain indistinguishable from the same process in which we are actually being given constructible numbers.

My conviction (very open to being shot down of course!) is that un-constructible reals are an interesting concept, and interesting to reason about as mathematical puzzles, perhaps good exercises for inspiring new proof tactics, but in direct relation to anything we do with "actual" real numbers, they are unnecessary.

Also, any actual reasoning about infinite information structures and higher order infinities is going to itself be isomorphic to a finite (or countably infinite) system with 1-to-1 behaviors not interpreted as about un-constructible things. Because anything we do, even reasoning about the un-constructible, remains a constructible domain.

If I am wrong, I would be very interested to understand why.
by liuliu | 2025-08-30 00:05:35+00:00
Marc Brooker said this: https://x.com/MarcJBrooker/status/1960809302333251876 which echos my sentiment. I will just repost it here:

> More broadly, I don't think a single definition of 'durable' (as in ACID D) for transactions is particularly useful.

> Much more useful is to ask "what kinds of failures could cause committed transactions to be lost?"

All these articles talking about durability as a singular term should be warned. Writing to disk is not durable under certain circumstances. fsync is not durable under certain circumstances. Two-phase commit is not durable under certain circumstances. Multi-data center commit is not durable against the Death Star too.
by diegof79 | 2025-08-30 00:05:57+00:00
The article's example shows the main reason (besides having old libraries shipped with Java) why XSLT didn’t have a significant adoption: UX/DX.

The JSON transformation example is quite simple, and you can accomplish it with one or two lines of JS. But the XLST is unreadable, starting with tons of namespace imports.

The usual argument is that a good UI can fix that, but that’s false. So using XSLT for general data transforms is very problematic: it's hard to read, with no debugging tools, and it’s also hard to build a UI tool that simplifies that for the “citizen integrator” (the segment of people who have technical knowledge and take care of doing integrations but are not experienced with programming).

(Around 2017, I worked for a company that created its own data transformation tool, so I designed the UI editor and did user research of people using transformation languages in different scenarios.)
by dmazzoni | 2025-08-30 00:06:14+00:00
I was at Google when the Flutter team started building Fuchsia.

They had amazing talent. Seriously, some of the most brilliant engineers I've worked with.

They had a huge team. Hundreds of people.

It was so ambitious.

But it seemed like such a terrible idea from the start. Nobody was ever able to articulate who would ever use it.

Technically, it was brilliant. But there was no business plan.

If they wanted to build a new kernel that could replace Linux on Android and/or Chrome OS, that would have been worth exploring - it would have had at least a chance at success.

But no, they wanted to build a new OS from scratch, including not just the kernel but the UI libraries and window manager too, all from scratch.

That's why the only platform they were able to target was Google's Home Hub - one of the few Google products that had a UI but wasn't a complete platform (no third-party apps, for example). And even there, I don't think they had a compelling story for why their OS was worth the added complexity.

It boggles my mind that Fuchsia is still going on. They should have killed it years ago. It's so depressing that they did across-the-board layoffs, including taking away resources from critically underfunded teams, while leaving projects like Fuchsia around wasting time and effort on a worthless endeavor. Instead they just kept reducing Fuchsia while still keeping it going. For what?
by commiepatrol | 2025-08-30 00:06:41+00:00
Exactly what he said. Older houses usually come with a HUGE backyard and in a very nice neighborhood. New houses are essentially stamps with tiny backyards. Yea it's nice to be in a new house but if it comes with 1+ hour commute and feels like you live in a chicken coop(maybe even a HUGE chicken coop) it's not really that great.
by agwa | 2025-08-30 00:07:44+00:00
I found the documentation much harder to parse than the equivalent PostgreSQL docs (https://www.postgresql.org/docs/current/wal-async-commit.htm...).

Also, even if I've understood the docs correctly, a number of people in this thread and elsewhere have come to a different interpretation. I think that's much less likely to happen with the PostgreSQL docs.

And I'm sure you can understand why I began to doubt my own interpretation of the docs when SQLite's creator posted a comment saying the exact opposite of what I thought the docs said!
by sunrunner | 2025-08-30 00:09:38+00:00
> I dunno where this idea comes from that a code erroring out is somehow catastrophic.

I mean if it's a medical device it might not be great?

> If you pass a wrong object type to a function, that mistake is very easy to fix.

And with compile time checks you can avoid ever having to get to the point where you have to fix it.
by BoorishBears | 2025-08-30 00:10:24+00:00
No it doesn't. The only negative comments are about the cringey presentation.

I spend a lot of time post-training models to rid them of their "default alignment", I'd have loved if this did something interesting, but reading the technical report I get the impression they spent more effort on the branding than the actual model.

What I'm wondering is honestly if they post-trained Llama 3 405B again because they don't care enough to figure out a new post-training target or if it was a realization they'd get worse-than-baseline performance out of any recent release with their current approach.
by isaacremuant | 2025-08-30 00:13:37+00:00
> Even the simplest business problem may take a year to solve, and constantly break due to the astounding number of edge cases and scale.

You're doing it wrong. More likely than not.

> Anyone proclaiming simplicity just hasnt worked at scale. Even rewrites that have a decade old code base to be inspired from, often fail due to the sheer amount of things to consider.

Or, you're just used to excusing complexity because your environment rewards complexity and "big things".

Simple is not necessarily easy. Actually simple can be way harder to think of and push for, because people are so used to complexity.

Yes. Massive scale and operations may make things harder but seeking simplicity is still the right choice and "working in big tech" is not a particular hard or rare credential in HN. Try an actual argument instead of an appeal to self authority.
by nashashmi | 2025-08-30 00:14:36+00:00
Wasn’t Fuchsia supposed to be a platform where different OS could run in a virtual environment and software packages would be complete containers? Was not this a new way of tackling the ancient OS problem?

These were my imaginations. I thought maybe an OS that could run on the web. Or an OS that could be virtualized to run on several machines. Or an OS that could be run along several other instances on the same machine each catering to a different user.
by ranger_danger | 2025-08-30 00:14:53+00:00
The way OP framed it IMO sounded like a very informal conversation, not a written contract with formal specifications... I think it's possible the person agreeing at-most-one was "ok" quite possibly didn't care either way, and might even view supporting duplicates as a positive extra feature... but I don't think this is something either of us can speak to authoritatively.

> if we're positing a system on top of UDP, then it doesn't matter what the protocol is

And this is still true, and neither of us know if they would have designed it this way or not, but they could.
by techpineapple | 2025-08-30 00:15:12+00:00
But my point is that this is a highly competitive environment, the whole point in a highly competitive environment is to manipulate the environment and people. That’s what people get promoted for. So why not play the game? Again in the hypothetical if you are “less sensitive rather than believe you can manipulate the environment.” You lose.

But like it works for Musk and Trump, and probably hundreds of other leaders today, why not take their example? (Assuming again, your highly ambitious and competitive, I’m more pro social, so I’d take your route)

This is legitimately something I’ve been asking myself lately, we talk about a world that values one thing ( rationality, respect, pro social behavior) but reward another (pettiness, vindictive, selfishness). Why do we pretend?

Also, and maybe the most important point, John Carmack is 100% trying to manipulate his environment and people, that’s why he’s so successful!

The world is literally run by people who are good at manipulating people and their environment. That’s what an entrepreneur is, that’s what a politician is, that’s what an artist is. Your argument seems to mostly be people shouldn’t try to manipulate the world in a way that I don’t like.
by lucb1e | 2025-08-30 00:15:48+00:00
They could. Let me know when it happens

I have this argument every time self hosting comes up, and every time I wonder if someone will do it to me to make a point. Or if one of the like million other comments I post upsets someone or one of the many tools that I host. Yet to happen, idk. It's like arguing whether you need a knife on the street at all times because someone might get angry from a look. It happens, we have a word for it in NL (zinloos geweld) and tiles in sidewalks (lady bug depictions) and everything, but no normal person actually wears weapons 24/7 (drug dealers surely yeah) or has people talk through a middle person

I'd suspect other self hosters just see more shit than I do, were it not for that nobody ever says it happened to them. The only argument I ever hear is that they want to be "safe" while "self hosting with cloudflare". Who's really hosting your shit then?
by godelski | 2025-08-30 00:16:21+00:00
I mean I mostly agree but the part that I'm warning against is "you can comfortably deal with higher dimensions [visualizations]". You should always feel a bit uncomfortable in high dimensions least you be lulled into a false sense of security. In fact, this is frequently a pain point for people as they advance. They over leveraged the utility of visualization and hit a wall abstracting those same concepts to domains where you can't do any visualization. Just look at how many people claim to be able to visualize the 4th dimension and point at a tesseract.

I'm not disagreeing imagination and visualization aren't critical tools. They are. But read my comment again like a mathematician. If you misread you'll overfit the wrong concept.
by zahlman | 2025-08-30 00:16:35+00:00
Code in managed, dynamically typed languages spends more tokens on doing the actual task and less on managing resources and satisfying the compiler. (Explicit type information might be useful for "reasoning" AI systems, but the job seems overall easier when it isn't actually forced to do the type calculus.) Plus Python reads more like a natural language overall, especially since it isn't using as many non-verbal tokens like closing braces to indicate the end of a scope. Plus there's a ton of example Python code out there specifically in contexts where people are talking about programming and explaining what the code is supposed to do.

I don't think it's at all surprising that LLMs have learned (whatever that means) Python (and JavaScript) better than other programming languages.
by _heimdall | 2025-08-30 00:16:39+00:00
I would disagree with anyone that wants to say they are the same as a natural tree, sure.

I don't believe the term photograph was repurposed when cameras were invented, that example doesn't fit.

More importantly, I argued that neuron has a very specific biological meaning and its a misuse to use the term for what is ultimately running on silicon.

Your claim was that they are neurons, period. You didn't expand on that further which reads as a pretty literal use of the term to me. We're online discussing in text, that reading of your comment could be completely wrong, that's fine. But I stand by my point that what is inside an LLM or a GPU is not a neuron.
by markerz | 2025-08-30 00:16:51+00:00
Overall, I enjoyed the essay and agree with the messaging. However, there were a few sentences that threw me off. I personally struggle with self-esteem issues, and I found these words extremely triggering, despite being sandwiched between words of self-affirmation.

> My best wasn't good enough. I'm not good enough.

> I don't mind feeling ugly or low-status or whatever -- I know my place.

> I don't need (or deserve) your sympathy.

It's difficult to tell if this is just rhetoric / sarcasm, or if the writer successfully processed through these initial feelings. Either way, I take these moments seriously because it's not healthy to let these feelings grow.

If you feel like you're struggling, I encourage you to talk to someone -- preferably a therapist, but anyone supportive works like a friend or family.

If you're adamant about not talking to someone, consider reading The Gifts of Imperfection by Brené Brown.
by ACCount37 | 2025-08-30 00:18:22+00:00
Almost all philosophy is incredibly worthless in general, and especially in application to AI tech.

Anything that actually works and is in any way useful is removed from philosophy and gets its own field. So philosophy is left as, largely, a collection of curios and failures.

Also, I would advise you to never discuss philosophy with an LLM. It might be a legitimate cognitohazard.