MurphyA/hacker-news huggingface dataset:
by jopsen | 2025-11-25 06:22:57+00:00
Lots of opinions that are less than idea in gnome. But the only one that really breaks me is lack of typeahead in Nautilus.

I just want to type D, enter and open Documents/, how hard can it be. It's been almost a decade since they removed it, and I still can't use vanilla Nautilus.

I always end up with Nemo or a patched Nautilus.

rant aside, the rest of gnome seems fine. Don't love it, but also don't hate it. I can add my own shortcuts with rofi/dmenu.
by spankibalt | 2025-11-25 06:23:40+00:00
> "I don’t want to spoils anyone’s fun but that’s not really what most screens looked like back then."

I don't really see the problem with what's written on the tin here; it's called retro-term and not vintage- or classic-term, after all (I didn't read the project's webpage). In other words: It's correctly advertised as something new that's just fashioned on something from yesteryear. So you can really go overboard with technically inaccurate, kitschy glitchshit that's so popular with crowd. Of course, historically challenged people will fall into the trappings of a romantically distorted past they never were a part of. As they always did and always will. But that's just life.
by SomewhatLikely | 2025-11-25 06:23:49+00:00
I've seen it so this too. I had it keeping a running tally over many turns and occasionally it would say something like: "... bringing the total to 304.. 306, no 303. Haha, just kidding I know it's really 310." With the last number being the right one. I'm curious if it's an organic behavior or a taught one. It could be self learned through reinforcement learning, a way to correct itself since it doesn't have access to a backspace key.
by Tanoc | 2025-11-25 06:24:11+00:00
Cinnamon is probably the best to use right now followed by XFCE because it uses XWayland by default. It provides nearly full use in both directions while still allowing both the new plugins and old widgets systems. It's also surprisingly stable. The only bug I've ever encountered in my now ten years of using it is on an N100 powered laptop, where if I let the computer go to sleep instead of turning it off eventually Cinnamon's process keeps requesting CPU time until it uses an entire core to itself.
by cobertos | 2025-11-25 06:24:29+00:00
Tried it on a 9.9MB json file I have. Seemed to handle the size fine, but the output was nothing like what I would want. I made a smaller version of what I uploaded in the below pastebin and the output.

The data is TLD data so it should have at least given me the "com", "net", "..." part

Input

https://pastebin.com/QAWeu8Xt

Output

category,addedToListPrice,appliesToCustomers,amountRateType,amountRate,type fee_tax,false,eu,percent-varies-by-location,~,vat fee_tax,false,in,percent,15,gst fee_tax,false,au,percent,10,gst fee_tax,false,eu,percent-varies-by-location,~,vat

An explanation of _how_ it does the conversion would be nice when choosing a tool like this. As the "just works" didn't seem to work.
by delaguardo | 2025-11-25 06:26:12+00:00
I think you can use metadata to model html attributes but in clojure people are using plain vector for that. https://github.com/weavejester/hiccup

tl;dr first element of the vector is a tag, second is a map of attributes test are children nodes:

[:h1 {:font-size "2em" :font-weight bold} "General Kenobi, you are a bold one"]
by ckosidows | 2025-11-25 06:26:41+00:00
I'm curious why it seems so many on this site still have Facebook accounts. I'd deleted mine before and it didn't stick, but I deleted it again earlier this year and haven't one single time considered creating another. I see no reason I would need a Facebook account again. I don't care to follow the activity of acquaintances.

Unless you're talking about Instagram? Even then IG has always struck me as the cooler Facebook, but now it's just a doom scrolling machine from what I can tell.

I presume I'm in the minority. But I don't really understand it. I see no need for these services anymore; they seem mostly like Trojan horses to inject advertisements into our lives.
by altairprime | 2025-11-25 06:27:38+00:00
Because you’re not a source of recurring revenue and therefore have no useful value to their annual growth target for revenue growth per year.

If they ship an AI operating system they can lay off a ton of costly interface engineers in favor of a Cortana search box and the cost offset of your freely-donated training data to their bottom line.

If AI succeeds, any corporation that has adopted it will drastically outpace those who have not in growth of revenue growth per year by already having dumped the deadweight ballast of human workers. Windows 11 is positioned to deliver on that promise, if only they can stick the landing, and they don’t understand why we all hate on AI because their largest paying customers are desperate for them to provide it, to unlock the exponential growth factor from the shackles of Still All Humans.

They assume most people don’t realize how much profit there is to be had from AI if they succeed, and so of course they think we’re confused — and in large part they’re right to think that. People do not understand AI is necessary to prevent the U.S. GDP bubble from popping — not the AI bubble, that’s just a sideshow. If AI succeeds, growth of wealth per capita continues (while us all working-class folks stay poor, but that’s not anything Microsoft would know or care about); if AI fails, much of the corporate economy shatters into dust, including Microsoft. Don’t we all want Windows to continue existing, etc.

This all isn’t certain to come to pass, but it’s a well-understood and significant threat in certain groups. No one will say it to anyone outside those groups — and so Microsoft is confused that we don’t like it, without explaining the existential threat to the future of Microsoft if it fails.
by adityaathalye | 2025-11-25 06:27:43+00:00
They reference Works in Progress in their "pitch us" page: https://altermag.com/pitch-us

Though I wouldn't say "India's answer to..." that's just lazy hyperbole. Give the magazine's makers credit, not some arbitrary national identity.

Works In Progress is a Stripe production. Alter Magazine is a production by a parent company "Alt Carbon". That's the similarity.
by intended | 2025-11-25 06:28:00+00:00
Well, here’s an example of the blind spots we posses. You, and most people, by default privilege “information”. However, in our current reality, everything is “content”. Information is simply content with a flag.

The commodification is towards the production of content, not information.

Mostly, producers of Information, are producing expensive “luxury goods”, but selling them in a market for disposable, commodified goods. This is why you need to subsidize fact checkers, and news papers.

I believe this is a legacy of our history, where content production was hard and the ratio of information to content was higher.

Consumers of content are solving for not just informational and cognitive needs, they are also solving for emotional needs, with emotional needs being the more fundamental.

Consumers will struggle with so many sources of content, and will eventually look towards bundling or focus only on certain nodes.

Do note - the universe does not need to favor anything for this situation to occur. Deception is a fundamental part of our universe, because it’s part of the predator prey dynamic. This in turn arises out of the inability of any system to perfectly process all signals available to them.

There is always place for predators or prey to hide.
by c0balt | 2025-11-25 06:29:44+00:00
> Why should users have a problem with this? They use Google --- which does pretty much the same ... or worse.

Not to excessively defend Google, who have their own problems, but they don't appear to do anything of that sort on chromeos or android.

They might monetize your data but their methods differ a lot here. For example, using Android without a Google account is supported. (ChromeOS doesn't support it tbf)
by Springtime | 2025-11-25 06:30:08+00:00
In the longer JEDEC overview document[1] it explains that in the ideal 'direct' testing method retention testing is only performed after the endurance testing. Which is only after the drive has had its max spec'd TBW written to it.

While if the endurance testing would exceed 1000 hours an extrapolated approach can be used to stress below the TBW but using accelerated techniques (including capping the max writable blocks to increase wear on the same areas).

Which is less dramatic than the retention values seem at first and than what gets communicated in articles I've seen. Even in the OP's linked article it takes a comment to also highlight this, while the article itself only cites its own articles that contain no outside links or citations.

[1] https://www.jedec.org/sites/default/files/Alvin_Cox%20%5BCom...
by randcraw | 2025-11-25 06:30:42+00:00
It's not that hard to prove that you did the work and not an AI. Show your work. Explain to the teacher why you wrote what you did, why that particular approach to the narrative appealed to you and you chose that as the basis for your work. Show an outline on which the paper was based. Show rough drafts. Explain how you revised the work, where you found your references, and why you retained some sources in the paper and not others.

To wit, show the teacher that YOU did the work and not someone else. If the teacher is not willing to do this with every student they accuse of malfeasance, they need to find another job. They're lazy as hell and suck at teaching.
by TheDong | 2025-11-25 06:32:31+00:00
The mutex case is one where they're using a mutex to guard read/writes to a map.

Please show us how to write that cleanly with channels, since clearly you understand channels better than the author.

I think the golang stdlib authors could use some help too, since they prefer mutexes for basically everything (look at sync.Map, it doesn't spin off a goroutine to handle read/write requests on channels, it uses a mutex).

In fact, almost every major go project seems to end up tending towards mutexes because channels are both incredibly slow, and worse for modeling some types of problems.

... I'll also point out that channels don't save you from data-races necessarily. In rust, passing a value over a channel moves ownership, so the writer can no longer access it. In go, it's incredibly easy to write data-races still, like for example the following is likely to be a data-race:

handleItemChannel <- item slog.Debug("wrote item", "item", item) // <-- probably races because 'item' ownership should have been passed along.
by jorams | 2025-11-25 06:33:48+00:00
> Maybe I missed something but I don’t know what you’re quoting or paraphrasing.

They're quoting the image's title text. Every xkcd comic has one. On desktop you can see it by hovering over the image. On mobile you generally can't see it. You can go to the mobile subdomain (https://m.xkcd.com/3172// and tap on the image, then it pops up underneath.
by unscaled | 2025-11-25 06:35:16+00:00
You can argue about how likely is code like that is, but both of these examples would result in a hard compiler error in Rust.

A lot of developers without much (or any) Rust experience get the impression that the Rust Borrow checker is there to prevent memory leaks without requiring garbage collection, but that's only 10% of what it does. Most the actual pain dealing with borrow checker errors comes from it's other job: preventing data races.

And it's not only Rust. The first two examples are far less likely even in modern Java or Kotlin for instance. Modern Java HTTP clients (including the standard library one) are immutable, so you cannot run into the (admittedly obvious) issue you see in the second example. And the error-prone workgroup (where a single typo can get you caught in a data race) is highly unlikely if you're using structured concurrency instead.

These languages are obviously not safe against data races like Rust is, but my main gripe about Go is that it's often touted as THE language that "Gets concurrency right", while parts of its concurrency story (essentially things related to synchronization, structured concurrency and data races) are well behind other languages. It has some amazing features (like a highly optimized preemptive scheduler), but it's not the perfect language for concurrent applications it claims to be.
by beeflet | 2025-11-25 06:35:44+00:00
I agree, it isn't hard! Watch:

Computer, show "my" work and explain to the teacher why "I" wrote what "I" did, describe why that particular approach to the narrative appealed to "me" and "I" chose that as the basis of "my" work. Produce an outline on which the paper could have been based and possible rough drafts, then explain how I could have revised the work to produce the final result.
by nmfisher | 2025-11-25 06:36:26+00:00
That was how I took most of my school and university exams. I hated it then and I'd hate it now. For humanities, at least, it felt like a test of who could write the fastest (one which I fared well at, too, so it's not case of sour grapes).

I'd be much more in favour of oral examinations. Yes, they're more resource-intensive than grading written booklets, but it's not infeasible. Separately, I also hope it might go some way to lessening the attitude of "teaching to the test".
by noodletheworld | 2025-11-25 06:37:23+00:00
> I never really understood why you have to stuff all the tools in the context.

You probably don't for... like, trivial cases?

...but, tool use is the most fine grained point, usually, in an agent's step-by-step implementation plan; So when planning, if you don't know what tool definitions exist, an agent might end up solving a problem naively step-by-step using primitive operations, when a single tool already exists that does that, or does part of it.

Like, it's not quite as simple as "Hey, do X"

It's more like: "Hey, make a plan to do X. When you're planning, first fetch a big list of the tools that seem vaguely related to the task and make a step-by-step plan keeping in mind the tools available to you"

...and then, for each step in the plan, you can do a tool search to find the best tool for x, then invoke it.

Without a top level context of the tools, or tool categories, I think you'll end up in some dead-ends with agents trying to use very low level tools to do high level tasks and just spinning.

The higher level your tool definitions are, the worse the problem is.

I've found this is the case even now with MCP, where sometimes you have to explicitly tell an agent to use particular tools, not to try to re-invent stuff or use bash commands.
by realusername | 2025-11-25 06:37:56+00:00
Depends what you mean by security, if by security you mean sanboxing of apps sure, if by security you mean that you trust what's in your OS and you can control it, it's worse than desktop Linux.

Security isn't just about technical features but also about trust, while I trust my Linux desktop, I don't trust my Android phone with the Play Store running as high privilege, advertising id in the OS and unknown manufacturer additions.
by adityaathalye | 2025-11-25 06:38:10+00:00
Ditto... several titles they listed were alien to me! And I had no idea about Rokeya.

Alas, these will have to wait a bit until my next book-funding cycle... I accidentally overdid some Diwali discount book shopping and have a slushpile of about forty scifi titles to work through, and a fiscal deficit to repair :sweat-smile: :D

That said, my extant slushpile has Sci-Fi by contemporary Indian / Indian-origin authors...

Lavanya Lakshminarayan's Interstellar Megachef (next up in the reading Q, along with the Strugatsky brothers).

And SB Divya's books:

Read and enjoyed and will recommend: - Meru (very cool embodiment of beings, mythologically-inspired) To-read: - Loka - Machinehood - Contingency plans for the apocalypse
by bullen | 2025-11-25 06:39:49+00:00
Yes, but that tradeoff comes with a hidden cost: complexity!

I much rather have 64GB of SLC at 100K WpB than 4TB of MLC at less than 10K WpB.

The spread functions that move bits around to even the writes or caches will also fail.

The best compromise is of course to use both kinds for different purposes: SLC for small main OS (that will inevitably have logs and other writes) and MLC for slowly changing large data like a user database or files.

The problem is now you cannot choose because the factories/machines that make SLC are all gone.
by Animats | 2025-11-25 06:40:17+00:00
> So much of it is focused upon memorization and regurgitation of information, which AI is unmatched at doing.

This applies both to education, and to what people need to know to do work. Knowing all the written stuff is less valuable. Automated tools can been able to look it up since the Google era. Now they can work with what they look up.

There was a time when programmers poured over Fundamental Algorithms. No one does that today. When needed, you find existing code that does that stuff. Probably better than you could write. Who codes a hash table today?
by datvo | 2025-11-25 06:40:56+00:00
Hey HN,

I recently built react-obj-view because I kept running into performance bottlenecks with existing object viewers (like react-json-view) when debugging large nested objects or heavy API responses.

Most existing libraries render recursively, which floods the DOM and causes frame drops when the node count gets high.

I built this alternative using windowing/virtualization. It only renders the nodes currently in the viewport, meaning it stays 60fps smooth whether you are viewing 100 lines or 100,000 lines of JSON.

Key features:

Virtualized: Handles massive datasets without UI blocking.

Written in TypeScript: Fully typed.

DX focused: Supports "sticky" keys (so you know where you are in a deep object), dark mode, and distinct data types.

It's still early days, so I’d love to hear your feedback on the API or any edge cases I might have missed.

Repo: https://github.com/vothanhdat/react-obj-view Demo: https://vothanhdat.github.io/react-obj-view
by gucci-on-fleek | 2025-11-25 06:41:55+00:00
> just here to observe single photons weren't reliably emitted until the modern era.

A dim light bulb from a few feet away emits on the order of 1k photons/sec, which is low enough that you can count individual emissions using fairly simple analog equipment [0] [1].

> The double slit experiment pre-dates this. it's from 1801. The one which confirms "self interaction" was 1974.

There's an experiment from 1909 that demonstrated the double-slit experiment with single(ish) photons [2].

> I only observe it's mostly for young students (like almost all received wisdom) grounded in experiments which don't actually do what people think they do. The ones you run in the school lab are illustrative not probative.

> What people do in places like the BIPM in Paris, or CERN, isn't the same as that experiment you did with a ticker-tape and a weighted trolleycar down a ramp. "it's been confirmed" is the unfortunate reality of received wisdom, and inherently depends on trust in science. I do trust science.

The double-slit experiment is actually fairly easy and cheap to run [3]. Certainly more complicated than ticker tape, but not by much.

[0]: https://en.wikipedia.org/wiki/Scintillation_counter

[1]: https://en.wikipedia.org/wiki/Photomultiplier_tube

[2]: https://www.biodiversitylibrary.org/page/31034247

[3]: https://www.teachspin.com/two-slit
by opello | 2025-11-25 06:42:00+00:00
It seems neatly organized to say "that we can explain all brain activity" and yet not necessarily bound exactly what is "brain activity." I think prior to recent research [1] people would have concluded that memory was solely the domain of the brain. But that sense/setting/environment would allow Clive Wearing to circumvent amnesia to access skills otherwise unavailable to his conscious mind [2] should raise questions of that understanding.

[1] https://www.nyu.edu/about/news-publications/news/2024/novemb...

[2] https://en.wikipedia.org/wiki/Clive_Wearing
by bullen | 2025-11-25 06:43:15+00:00
I concur; in my experience ALL my 24/7 drives from 2009-2013 still work today and ALL my 2014+ are dead, started dying after 5 years, last one died 9 years later. Around 10 drives in each group. All older drives are below 100GB (SLC) all never are above 200GB (MLC). I reverted back to older drives for all my machines in 2021 after scoring 30x unused X25-E on ebay.

The only MLC I use today are Samsungs best industrial drives and they work sort of... but no promises. And SanDisc SD cards that if you buy the cheapest ones last a surprising amount of time. 32GB lasted 11-12 years for me. Now I mostly install 500GB-1TB ones (recently = only been running for 2-3 years) after installing some 200-400GB ones that work still after 7 years.
by TheDong | 2025-11-25 06:45:16+00:00
"best in class"?

I feel like Java's IDE support is best in class. I feel like go is firmly below average.

Like, Java has great tooling for attaching a debugger, including to running processes, and stepping through code, adding conditional breakpoints, poking through the stack at any given moment.

Most Go developers seem to still be stuck in println debugging land, akin to what you get in C.

The gopls language server generally takes noticeably more memory and cpu than my IDE requires for a similarly sized java project, and Go has various IDE features that work way slower (like "find implementations of this interface").

The JVM has all sorts of great knobs and features to help you understand memory usage and tune performance, while Go doesn't even have a "go build -debug" vs "go build -release" to turn on and off optimizations, so even in your fast iteration loop, go is making production builds (since that's the only option), and they also can't add any slow optimizations because that would slow down everyone's default build times. All the other sane compilers I know let you do a slower release build to get more performance.

The Go compiler doesn't emit warnings, insisting that you instead run a separate tool (govet), but since it's a separate tool you now have to effectively compile the code twice just to get your compiler warnings, making it slower than if the compiler just emit warnings.

Go's cgo tooling is also far from best in class, with even nodejs and ruby having better support for linking to C libraries in my opinion.

Like, it's incredibly impressive that Go managed to re-invent so many wheels so well, but they managed to reach the point where things are bearable, not "best in class".

I think the only two languages that achieved actually good IDE tooling are elisp and smalltalk, kinda a shame that they're both unserious languages.
by codebje | 2025-11-25 06:45:45+00:00
I'm sorry, but I'm not sure if you're implying you dislike Apple's approach to what the user is allowed to do, or suggesting we should only talk about general purpose computing devices. If it's the latter, sure, the iPhone's not an innovation in that space, discard it from my list of examples. If it's the former, I'll give you that too, but it was still the first of its kind, by a large margin.

(I remember the huge window in which phone companies desperately put out feature phones with sub-par touch screens, completely missing the value to consumers. The iPod Touch should've been warning enough... and should've been (one of) my signal(s) to buy Apple stock, I guess :-)
by zorgmonkey | 2025-11-25 06:46:04+00:00
Pebble watches run on Cortex-M microcontrollers which have less than 1MB of flash storage and RAM, I like Kotlin multiplatform but getting it to run on them is extremely unlikely. I assume that for the foreseeable future Pebble apps will be only written in languages which are traditionally used for MCUs like Rust and C\C++
by Culonavirus | 2025-11-25 06:46:16+00:00
> less tools, better skills to apply those tools

All models have peaked (the velocity of progress is basically zero compared to previous years) -there are not going to be "better skills" (any time soon).

All these bubbled up corps(es) have to try to sell what they can, agent this, tool that, buzzword soup to keep the investors clueless one more year.