Recent submissions

Comment · 11 hours ago
Or more probably, it's imputable to biology and the natural replacement of the "old guard" by adults who didn't grow up during nukes schizophrenia. Or in other words, I doubt that those folks reasoned themselves out of the irrational fear for nuclear energy that they did not reason themselves into.
Comment · 3 days ago
Same stuff, is a Markov chain too much (Gen) AI already?
Comment · 3 days ago
I haven't read TFA yet, but having studied academically and then spent years implementing ML techniques for industrial applications (in the areas of machine vision and signals processing), I think that the premise of "AI exemption" is just nonsensical, by nature of being ill-defined. AI isn't a singular product or technology, it's an abstract family of computational techniques, some more complex or mathematically involved than others. Finding function parameters to fit data points using a least squares method is ML, therefore AI, and you would find that in every thermostat, ABS system or electric bike. Too simple? Here is a gradient of increasingly sophisticated ML techniques, with LLMs not even being on the top of the list. Where do you place the cursors of "what's too much AI"?
Comment · 4 days ago
My pixel lets me pick between 60 or 120Hz refresh rate, the bump in perceived smoothness is substantial, to the point that 60Hz does appear choppy in comparison.
Comment · 7 days ago
What about OP's comment rings communistic, or even political to you? Or is it the link between information control and wealth consolidation that you find controversial?
Comment · 7 days ago
There's no paradox, there never were agents to begin with. Those are programs. It's same old software. If you sell me a software to do X and you fail to deliver, it's on you.
Comment · 8 days ago
Even less likely to work in 2026. The only reason why the west-aligned world does the bidding of Walt Disney & friends, and doesn't instead shrug at DMCA and other extraterritorial IP laws, is to stay in good trading terms with the US. Now consider how much of that incentive remains when you are on the receiving end of illegal and arbitrary tariffs.
Comment · 8 days ago
Comment · 8 days ago
Isn't that a project where they must implement under white room conditions (or risk copyright infringement claims), and are careful about not taking contributions from people having been exposed to windows' source code? IIRC that's the case of wine
Comment · 8 days ago
Can't disagree more, but heh :-)
Comment · 9 days ago
Thanks for the link. I did go through it despite the annoying style.

It postulates that semantic models delivered in areas where SQL couldn't, that what hinders their broader adoption is the user-interface/querying layer (i.e. too few people adopting SPARQL), and suggests that a new dialect of SQL could solve that, especially because LLMs are so good at producing SQL.

> Knowledge graphs and semantic models promised something enterprises desperately needed: governed meaning, reusable business logic, and explicit relationships across complex data landscapes. And technically, they delivered.

For me that's the main argument: what is the value proposition for knowledge graphs and semantic models when you already have an established relational datamodel? Some argue that the graph's fluid schema brings flexibility benefits, but looking at the problem in its entirety (considering the effort to define and formalise the model, the effort to store content, the effort to retrieve it, deliberately keeping the dev/sysops and tooling out of the way), what you spare at formalisation/insertion stages, you pay back at retrieval (or, if you don't validate or constrain your inputs, expect surprises as an output).

That's where I stand right now:

- convince me that relational models can't express as powerful constructs and concepts as semantic ones

- convince me that "fluidity" in the model don't come with more troubles down the road than benefits

> Knowledge graphs exist. […] And almost nobody queries them directly. Not because the models are wrong. Not because the semantics aren’t useful. But because accessing them requires SPARQL

Or, guess what, a similar outcome can be explained differently: perhaps it's not SPARQL that's too difficult to grasp. Perhaps the alleged benefits of semantic models just do not materialise in practice, and there is no point to engage with SPARQL to begin with because there's no payoff at the end of it. I think the data processing ecosystem is sufficiently vivid and diverse to demonstrate that users have no problem embracing new technologies and languages as the need arise (sed/grep/…, hadoop/spark, pandas/polars/duckdb, decades of ETLs in graphical/textual forms, …)

Then the article is full of weird takes, especially within the "Hidden Cost" section, that I don't feel like commenting. Nor why their "SQL with semantic ontologies" is just syntactic sugar to save your editor from writing joins on your behalf?

Comment · 10 days ago
Almost like, mercurial had it figured out and got completely ignored because of the dominance of git's monoculture... The unit of work to be captured is the series (of commits), there's no issue having a linear history as long as series' boundaries can be identified. Merges can fit that bill, but doing it right and consistently with git is real work and consequently nobody does it.
Comment · 11 days ago
Comment · 11 days ago
Strikingly similar story here. Ontologies and knowledge graphs seemingly make a comeback because it is argued (with little evidence, from what I can tell) that it helps LLMs make sense of the dataset. I see no practical difference or benefit vs. providing the date model as DDL or via other means to represent the ER graph. I'd like very much to be convinced otherwise or at least read a rationale about the alleged differences.
Comment · 14 days ago
you and me are enthusiasts, we love to know about codecs, formats, and we spontaneously seek novelty in this field and engage with it (I have similar stories of amazement about opus, I even went quite deep the rabbit hole of writing a java decoder implementation for it just to study it). But most people won't get nearly that excited, unless a new format magically enables something like twice the compression performance (so people start spreading the word that they can e.g. buy their next smartphone with 128GB storage and not the 256GB version and enjoy the same capabilities). Anything less than that will be a rounding error and barely perceptible, not worthy of the attention, and definitely not of the time to re-process and massively convert prior content.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton