MurphyA/hacker-news huggingface dataset:
by dragonwriter | 2025-11-01 16:19:43+00:00
Most of Federal law enforcement except for those that patrol certain, usually sharply defined (but see border patrol for a big exception) areas historically has been in one of two modes interacting: either gathering information (this includes serving a search warrant), or arresting based on an existing arrest warrant, usually from a felony indictment. In the former case, something really out of ordinary has to happen to turn it into an arrest in that interaction (though that doesn't mean you wont be indicted and arrested based on it) and in the latter nothing is likely to deter arrest.

Border patrol specifically is wildly different, looking for people who are suspected of being subject to their jurisdiction without a specific indictment, detaining with in practice, if not in law, a much lower standard of suspicion than applies usually, and then generally having those detained subject to process that is almost entirely within executive branch “courts” with consequences as severe as criminal process but much lower protections than criminal process (where literal toddlers defend themselves in “court" against government lawyers.)

The current “immigration” crackdown, while ICE (which historically has worked more like a regular federal law enforcement agency despite its detainees often flowing into the executive immigration system and not the criminal justice system) has been the public face of it is effectively applying the Border Patrol culture/approach far more broadly (which is also why, in frustration with the “inadequate” results so far ICE middle leadership is being purged and replaced with Border Patrol personnel.)
by aurintex | 2025-11-01 16:20:01+00:00
Just to clarify, the “reminder” example was just one possible use case. The idea isn’t to capture everything or pretend to read thoughts, but to offer flexible support based on context you control.

Curious though: if there were a way for an AI to understand your thoughts, would that even be something you’d want? Or is the whole concept off-limits for you?
by efitz | 2025-11-01 16:20:20+00:00
There is a general problem with rewarding people for the volume of stuff they create, rather than the quality.

If you incentivize researchers to publish papers, individuals will find ways to game the system, meeting the minimum quality bar, while taking the least effort to create the most papers and thereby receive the greatest reward.

Similarly, if you reward content creators based on views, you will get view maximization behaviors. If you reward ad placement based on impressions, you will see gaming for impressions.

Bad metrics or bad rewards cause bad behavior.

We see this over and over because the reward issuers are designing systems to optimize for their upstream metrics.

Put differently, the online world is optimized for algorithms, not humans.
by 9rx | 2025-11-01 16:20:34+00:00
> What you are calling fundamental is actually configurable convention.

Not within the topic's layer of abstraction. I can see you put a lot of thought into this, and if you were writing in a vacuum it might even be interesting, but discussion relies on context...

> If that ever happens in production, it is a bug.

Right. A bug, not an exception. Overloading the use of exception data structures and associated control flows does not imply that there is an exception in concept, just like using an error data structure to represent an email address[1] does not imply that you are dealing with an error in concept. It's just an email address.

> If it throws, the incident is a bug.

Right. A bug, not an exception. Again, just because you overloaded the use of a feature intended for dealing with exceptions for other purposes does not mean that you have an exception in concept. Just as an email address does not become a conceptual error just because you put it in an error data structure[1].

> If the runtime raises an exception and the loop dies, that exception is the manifestation of a bug.

Right. A bug, not an exception. I sense a recurring theme here. It is clear now that you've undeniably confused exceptions (data structure) with exceptions (concept). You obviously missed a lot of context so this may come as a surprise, but we were talking about the concept of programmer error. Data structures used in an implementation find no relevance here.

> In practice many exceptions are how bugs announce themselves.

As bugs and exceptions are different categories within the broader concept of programmer error, you could equally say "In practice many bugs are how bugs announce themselves". How, exactly, am I to grok that? I honestly have no idea what to make of that statement.

[1] let email = Error("foo@example.com")
by closeparen | 2025-11-01 16:20:46+00:00
I do not think it is righteous or enlightened when the American government flexes control over the tech sector. I can see how Europeans might have thought this about the EU when it was just GDPR, but subsequent developments have recast all of this as being about government control and keeping the tech industry “in its place” rather than a commitment to privacy and freedom in and of themselves. I think that ought to temper the righteousness.
by tmtvl | 2025-11-01 16:21:45+00:00
> Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety.

I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under <https://github.com/pop-os/cosmic-applets>), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreutils, for example: <https://savannah.gnu.org/projects/coreutils/>).
by woodruffw | 2025-11-01 16:21:59+00:00
> Memory safety is mostly an issue of the past.

Can you provide some evidence to support this? There’s a large body of evidence to the contrary, e.g. from Chrome[1].

> But we have tools to prevent that. The new security issues are supply chain attacks.

Speaking as a “supply chain security” person, this doesn’t really hold water. Supply chain attacks include the risk of memory unsafety lurking in complex dependency trees; it’s not an either-or.

[1]: https://www.chromium.org/Home/chromium-security/memory-safet...
by shermantanktop | 2025-11-01 16:22:35+00:00
Agree with a lot of this. But on the last point, that’s the “blame middle management” theory. And I have seen outrageous, florid displays of exactly that behavior in those ranks.

But the CEOs have been there all along, doing the math on ZIRP and getting caught up in FOMO. They could have tightened their belts at any time, or demanded better justifications for investments. Why didn’t they?
by testdelacc1 | 2025-11-01 16:23:12+00:00
At least investing in companies that will buy Nvidia makes sense somewhat, even if it feels dodgy. What possible sense does it make for Nvidia to invest in a maker of telecom equipment (Nokia) with no public plan, and the value of the investment jumps 30% as soon as it’s announced? It’s not like call routing needs to be “AI enabled” or they’re putting Nvidia GPUs in their custom silicon.

Feels like Nvidia has too much money and they know whatever they invest in will appreciate thanks to the “AI premium” that investors bestow.
by throwaway894345 | 2025-11-01 16:24:42+00:00
As a user of Jellyfin, I’m very sad that it doesn’t just use Postgres. I basically have to run an NFS system just for Jellyfin so that its data can be available to it no matter which node it gets scheduled on and also that there are never multiple instances running at the same time, even during deployments (e.g., I need to take care that deployments completely stop the first Jellyfin instance before starting the subsequent instance). There are so many unnecessary single points of failure, and Postgres would make a pretty big one go away (never mind addressing the parallelism problems that plague the developers).

Jellyfin is by far the least reliable application I run, but it also seems to be best in class.
by chrismorgan | 2025-11-01 16:25:26+00:00
A lot of people here are clearly not reading the article.

It’s not about the <table> element itself—we hope everyone knows about tables—but rather about the table-specific DOM interface, including things like HTMLTableElement.prototype.insertRow() and HTMLTableRowElement.prototype.insertCell() as alternatives to the generic DOM techniques like Document.prototype.createElement() and Node.prototype.appendChild().

These are handy if you’re hand-writing your DOM interactions, but libraries that construct and maintain DOM trees (e.g. React, Svelte, Vue) will never use them, and that’s the direction everything has headed, so in practice they’ve fallen into near-complete disuse.

They match HTML syntax in another important way: HTML tables have thead/tbody/tfoot section elements, but you can mostly skip writing them in HTML syntax because it’ll imply <tbody> open and close tags. Likewise in this interface, if you have a thead/tbody/tfoot element you can call .insertRow() on it, but you can also call .insertRow() on the table, and it’ll put it in the last tbody, creating one if necessary. Meanwhile, I presume in React/Svelte/Vue/whatever you must write out your tbody manually.

I’ve definitely used at least .insertRow, .insertCell, .createTHead, .rows and .cells in the last five years in no-library throwaway/demo scripts where I was generating tables.

—⁂—

Concerning the specific example given, here’s what I find a clearer code style, using for instead of forEach, using better variable names, and omitting the index argument to insertRow/insertCell which was quite unnecessary and only confused matters (the author doesn’t seem to have realised it’s optional):

let data = [ ['one','two','three'], ['four','five','six'] ]; let table = document.createElement('table'); for (const row of data) { let tr = table.insertRow(); for (const value of row) { tr.insertCell().innerText = value; } } document.body.append(table);
by dragonwriter | 2025-11-01 16:25:29+00:00
> A matchbox-sized general purpose computer and life log, infrared connections to peripherals as needed, with a mesh network to other jiminies and the internet-at-large. Jeff didn't use the term "AI", but that would.

Notwithstanding that most of the mobile OS’s are locked down more than some would prefer for a “general purpose computer” (but less than is likely for a porta-Grok), and that most devices are bigger than a matchbook to support UI that wouldn't be available in that form factor (though devices are available in matchbook size with more limited UI), and that it mostly uses RF like Bluetooth instead of IR for peripherals because IR works poorly in most circumstances, isn’t that what a smartphone is?
by noodlesUK | 2025-11-01 16:25:56+00:00
This argument rings especially true in the U.S. where there is already a primary key in use every day. The SSN serves as a universal enumerator but without canonical data.

If the U.S. wanted to have a national ID system with rules, a defined scope, and redress procedures when things went wrong, and established it in the open, following a democratic process, I would be much happier.

The system we are getting instead has all the downsides of centralisation, with none of the upsides.
by ojosilva | 2025-11-01 16:25:56+00:00
The problem with Node is that the async decision is in the hand of the leaf node, which bubbles up to the parent where my code sits. Async/await is nice and a goal in most modern Node, but there are codebases (old and new) where async/await is just not an option for many reasons.

Node dictates that when faced with an async function the result is that I must either implement async myself so I can do await or go into callback rabbit holes by doing .then(). If the function author is nice, they will give me both async and sync versions: readFile() and readFileSync(). But that sucks.

The alternative would be that 1) the decision to go async were mine; 2) the language supports my decision with syntax/semantics.

Ie. if I call the one and only fs.readFile() and want to block I would then do

sync fs.readFile()

Node would take care of performing a nice synchronous call that is beneficial to its event-loop logic and callback pyramid. End of the story. And not some JS an implementation such as deasync [1] but in core Node.

1. https://www.npmjs.com/package/deasync
by jayd16 | 2025-11-01 16:25:58+00:00
Knowing when execution will yield is useful when you want to hold onto a thread. If you run your GUI related async tasks on the GUI thread you don't have to worry about locks or multi threaded data structures. Only a single GUI operation will happen at a time.

If yields are implicit, you don't have enough control to really pull that off.

Maybe it's possible but I haven't seen a popular green threaded UI framework that let's you run tasks in background threads implicitly. If I need to call a bunch of code to explicitly parcel background work, that just ends up being async/await with less sugar.
by Itoldmyselfso | 2025-11-01 16:26:03+00:00
Or, far more playsibly, they added to the table features GrapheneOS has, but others don't.

Here's the up-to-date comparison: https://eylenburg.github.io/android_comparison.htm

As far as I know, there is no significant features other distros have that increase their privacy or security over what GOS has. I'm not entirely sure about the SafetyNet thing, but GOS is by far the most up-to-date to the AOSP out of these distros.
by yorwba | 2025-11-01 16:26:03+00:00
Sybil attacks are a problem when you care about global properties of permissionless networks. If you only care about local properties in a subnetwork where you hand-pick the nodes, the problem goes away. I.e. you can't use such a scheme to find the best paper in the whole world, but you can use it to rank papers in a small subdiscipline where you personally recognize most of the important authors.
by jcalvinowens | 2025-11-01 16:26:19+00:00
So my understanding was correct, it requires the programmer to deal with scheduling explicitly in userspace.

If I'm writing bare metal code for e.g. a little cortex M0, I can very much see the utility of this abstraction.

But it seems like an absolutely absurd exercise for code running in userspace on a "real" OS like Linux. There should be some simpler intermediate abstraction... this seems like a case of forcing a too-complex interface on users who don't really require it.
by immibis | 2025-11-01 16:26:29+00:00
You can, but it's a tax on real wealth, which incentivizes a reduction in real wealth. More concretely it incentivizes fewer buildings because people want to pay less tax. If you want fewer buildings then fine.

The amount of land is fixed. Taxation on land does not decrease land, but rather incentivizes efficient land use and decreasing land values (which improves efficiency of land use).
by nananana9 | 2025-11-01 16:27:25+00:00
Async/await feels very misguided to me. It's an extremely complex language feature for something that can be done way better, completely in userspace.

You can implement stackful coroutines yourself in C/C++, you need like 30 lines of assembly (as you can't switch stack pointers and save registers onto the stack from most languages). This is WAY better than what you could do for example with the way more convoluted C++ co_async/co_await for two reasons:

1. Your coroutine has an actual stack - you don't have to allocate a new "stack frame" on the heap for every "stack frame", e.g. every time you call a function and await it.

2. You don't need special syntax for awaiting - any function can just call your Yield() function, which just saves the registers onto the stack and jumps out of the coroutine.

Minicoro [1] is a single-file library that implement this in C. I have yet to dig into the Zig implementation - maybe it's better than the C++/Rust ones, but the fact they call it "async/await" doesn't bring me much hope.
by 0xDEAFBEAD | 2025-11-01 16:27:26+00:00
I think this is a pretty good approach actually. Give people the freedom to gamble, but discourage it through taxes. It's best to tax things you want to discourage. So it's preferable to tax gambling rather than productive economic activity.

Related concept: https://en.wikipedia.org/wiki/Pigouvian_tax
by troupo | 2025-11-01 16:27:37+00:00
I didn't have to answer :) Thank you for looking it up.

Erlang also enjoys quite a lot of optimizations on the VM level. E.g. a task is parked/hybernated if there's no work for it to perform (e.g. it's waiting for a message), the switch between tasks is extremely lightweight, VM internals are re-entrant, employ CPU-cache-friendly data structures, garbage collection is both lightweight and per-thread/task etc.
by 0_____0 | 2025-11-01 16:28:17+00:00
I think their comment is rightly pointing out that if a TLA or other state intelligence actor takes an interest in you specifically, they can do quite a bit of classic spycraft that is considerably more expensive i.e. direct surveillance. No alternative handset OS will protect you from an agent who bugs your house, or someone firing a polonium pellet into your leg from a modified umbrella.
by dvtkrlbs | 2025-11-01 16:28:56+00:00
The point of unsafe is you have small bubbles of unsafe which you can verify rigorously or use tools like Miri to make sure they upheld and you build safe abstraction on top of that unergonomic part. Looking at embedded-hal and even to extreme embassy you can see the value of it. If you don't do any abstraction I definitely agree Rust is not fun to write at all.
by chasil | 2025-11-01 16:28:57+00:00
That is hardly the only problem.

The browser is astonishingly bad at dark mode.

The launcher forces almost all icons to greyscale black and white and does not accept icon packs.

I feel like I'm downgrading by my compulsion for Brave and Lawnchair, but some attention is lacking in aesthetics. (e/os has this problem to a lesser degree with the Bliss launcher.)

There is no rooted ADB. Even if a giant OS TAINTED notification appears every five minutes if I ever turn it on, I want it.

There are a few other annoyances that regulate Graphene to one of my experimental spares.
by kstrauser | 2025-11-01 16:29:14+00:00
I think the Rust example’s biggest readability sin is using the full names of things like foo::bar::Baz instead of just Baz, but I get why they did that. When you import a lot of things into a file the latter way, it’s easy to get lost in “was that a foo Baz or a wiz Baz?” Sometimes it’s easier just to use the long names everywhere to be explicit.

If I wanted to tweak the Rust project, I’d feel pretty confident I was calling the right things with the right params.
by Atreiden | 2025-11-01 16:29:57+00:00
Nokia had some of the best mobile hardware (and software!) in the game until they were bought by Microsoft and promptly killed.

I've been patiently waiting for their resurgence. Building embedded/mobile devices is their forte, which is also coincidentally the hardware space where AI is most poised to shine. Nvidia made a move in the same direction when they tried to acquire ARM. That got antitrusted (fairly so) but investing in a now-decimated telecom company isn't likely to ruffle any feathers this way.
by devjab | 2025-11-01 16:30:24+00:00
Microsoft did some research on it 15-20 years ago for .NET which showed that sync doesn't scale for I/O workloads. The rest of the world sort of "knew" at this point, and all the callback and statemachine hell which came before was also leading the world toward async/await but the Microsoft research kind of formed the foundation for "universal" acceptance. It's not just for single threaded JS programs, you almost never want to tie up your threads even when you can have several of them because it's expensive in memory. As you'll likely see in this thread, some lower level programmers will mention that they prefer to build stackful coroutines themselves. Obviously that is not something Microsoft wanted people to have to do with C#, but it's a thing people do in c/c++ and similar (probably not with C#), and if you're lucky, you can even work in a place that doesn't turn it into the "hell" part.

I can't say why Diesel.rs doesn't need async, and I would like to point out that I know very little about Diesel.rs beyond the fact that it has to do with databases. It would seem strange that, anything, working with databases which an I/O heavy workload would not massively benefit from async though.
by mickeyp | 2025-11-01 16:31:21+00:00
You are talking about low level stuff like syncing to the filesystem; that data is journalled and ensuring atomicity is maintained and I am in actual fact not.

Dislocating DML from the code that triggers it creates many problems around ensuring proper data integrity and it divorces consistent reads of uncommitted data that you may want to tightly control before committing. By punting it to a dedicated writer you're removing the ability to ensure serialised modification of your data and the ability to cleanly react to integrity errors that may arise. If you don't need that? Go ahead. But it's not fud. We build relational acid compliant databases this way for a reason
by thaumasiotes | 2025-11-01 16:31:32+00:00
I sometimes think about a related issue: suppose you have a function whose n parameters have n different types. Should the programmer be required to provide those parameters in a specific order? There's no ambiguity.

There appears to be some tension between different conveniences you might afford yourself. If you have read(offset: offsetTypeForRead, address: addressTypeForRead), you can catch when someone accidentally passes an address where the offset should be and an offset where the address should be.

Or, you can say "hey, I'm always adding the offset to the address; it doesn't matter which one gets passed first" and relieve the programmer of needing to know the order in which two semantically distinct variables get passed to `read`.

But if you do provide that convenience -- and it's not unintuitive at all; there really is only one valid interpretation of a combination of an address and an offset, regardless of the order you mention them in -- you lose some of the safety that you wanted from the types. If your variables are declared correctly, everything is fine. If there's a mistake in declaring them, you'll wave through incorrect calls to `read` that would have been caught before.
by troupo | 2025-11-01 16:31:43+00:00
I think it depends on the language?

Javascript's async/await probably started as a sugar for callbacks (since JS is single-threaded). Many others definitely have that as sugar for whatever threading implementation they have. In C# it's sugar on top of the whole mechanism of structured concurrency.

But I'm mostly talking out of my ass here, since I don't know much about this topic, so everything above is hardly a step above speculation.
by jaybrendansmith | 2025-11-01 16:32:05+00:00
The point is they should not have to. The funds were already appropriated by congress. This is a political maneuver by the Republicans to avoid bringing congress back into session, because they want to give the justice department time to redact the Epstein files and remove all evidence of Trump. We all know he's a pedophile and a rapist already, but the Trump base doesn't want to believe it. You simply cannot make this stuff up, it reads like a ridiculous Hollywood script. This article lays it all out plainly in black and white, for all the good that it will do.
by ajross | 2025-11-01 16:32:11+00:00
> And the alternative without async-await is ? blocking the event loop or the callback pyramid.

No, just callbacks and event handlers (and an interface like select/poll/epoll/kqueue for the OS primitives on which you need to wait). People were writing threadless non-blocking code back in the 80's, and while no one loved the paradigm it was IMHO less bad than the mess we've created trying to avoid it.

One of the problems I'm trying to point out is that we're so far down the rabbit hole in this madness that we've forgotten the problems we're actually trying to solve. And in particular we've forgotten that they weren't that hard to begin with.