MurphyA/hacker-news huggingface dataset:
by xoa | 2025-11-02 19:09:42+00:00
>but why have different punishments based on what technology someone used?

So first as foundation, I see no reason to pretend that the law is always perfectly thought through and logical particularly when it comes to crime. And even when laws have been done for the time, that also doesn't mean circumstances haven't changed over the decades while the law remained static.

That said, in principle punishment embodies multiple components and a major aspect is deterrence. The deterrence value in turn interplays with components like barrier to entry, scaling of the potential harm and the likelihood of getting caught. Usage of technology can have a significant impact on all of this. It's significantly more challenging and expensive to prosecute crimes that stretch across many jurisdictions, technology can also have a multiplier effect allowing criminal actors to go after far more people, both in terms of raw numbers and in terms of finding the small percentage of the vulnerable, and perceived anonymity/impunity can further increase number of actors and their activity levels. It also has often implied a higher degree of sophistication.

All of that weighs towards a higher level of punishment even as pure game theory. That doesn't mean the present levels are correct or shouldn't be only a part of other aspects of fighting fraud that depressingly frequently get neglected, but it's not irrational to punish more when criminals are generating more damage and working hard to decrease the chance of facing any penalties at all.
by bigbadfeline | 2025-11-02 19:10:07+00:00
> And then supply goes up. In theory.

Supply goes up for a price and it's called capex, that cost wouldn't be there without new datacenters.

> Americans have coasted too long on other people's infrastructure investment. It's basically run out.

That's such an egregious inversion of the truth. It would be true if the companies building data-centers were building power plants and transmission lines which the population was allowed to use for the cost of operating expanses - after all capex and loans were payed off by these companies.

The reality is the exact opposite of that - the public is shouldering all of the capex and the new AI overloads want to pay for the opex only.

> Time to pay the piper or watch our quality of life decline.

They are even ready to issue threatening ultimatums if you disagree... as if agreeing would lead to a different outcome.
by jbstack | 2025-11-02 19:10:21+00:00
I completely agree with your first statement and I try to hand-generate my cards as much as possible.

On the other hand, hand-generation is very time intensive. Having some kind of Anki card for a topic you need to memorise is better than having nothing at all. If LLMs help you write cards that you wouldn't otherwise get around to writing then it can be worth it.

As an example, I've always found Anki really effective for my language learning. But the bottleneck was always finding the time to find good quality sentences from sources like grammar books and then creating the cards. Now I ask ChatGPT to generate me a whole bunch of example sentences for a particular topic or grammar point that I want to master, and I bulk import them into Anki in one go then use AwesomeTTS to create the audio. These cards feel less personal to me because I've lost the benefit of having put in the hard work of creating them myself from source materials. But that's more than made up for by the fact that I'm now progressing through the topics I need to learn at a much faster speed. I'd rather know 1000 words reasonably well than 200 words very well.

After a few repetitions I don't think there's much difference anyway between a card you generated yourself and one you didn't - the SRS algorithm sorts it out for you in the end. The AI generated one might just need a few more reviews/fails/hards to get to the same level of memorisation.

EDIT: I should add that I don't blindly trust ChatGPT's output. My wife is a native speaker for one of the languages, so I always have her check the cards. For my other language, I run the sentences past several other LLM models and I only keep those that all of them agree are correct and idiomatic.
by hamburglar | 2025-11-02 19:10:22+00:00
If I have a feature branch, and as part of that feature change, I did a simple refactor of something, I definitely want that committed as two separate commits in the PR, because you can look at the changes in isolation and it makes them a LOT easier to follow. And if you prefer, you can look at the diff of the entire PR in one single view. I don’t see the downside.

And please do not come back with “you shouldn’t do a refactor as part of a feature change.” We don’t need to add bureaucracy to avoid a problem caused by failure to understand the power of good version control.
by utopiah | 2025-11-02 19:10:30+00:00
I agree with the post.

I also think that typically if you have to resort to bisect you are probably in a wrong place. You should have found the bug earlier so if do not even know when the bug came from

- your test coverage isn't good sufficient

- your tests are probably not actually testing what you believe they do

- your architecture is complex, too complex for you

To be clear though I do include myself in this abstract "you".
by zdragnar | 2025-11-02 19:10:33+00:00
> What's insane about all these discussions is that NOBODY IS HACKING X SERVERS

I knew someone who worked for a small loan type company. Passwords were stored in plain text, but even worse, the login form didn't actually check the password at all, it created valid sessions as long as you provided a valid user name.

When he informed his boss that was very bad, his boss simply said that nobody has abused it, and nobody would, don't waste time changing it.

The point, of course, is why would you wait until people are getting hacked to address a known vulnerability?

Sure, there are others, and they should be closed too, and they are when they are found. It makes no sense whatsoever to leave one open just because.
by thelastgallon | 2025-11-02 19:11:38+00:00
New homes should be built with

1) EV chargers or 240V outlets in the garage

2) Heat pump water heater

3) Heat pump for HVAC

4) Induction stove

5) Solar panels, better yet, solar roofs

6) Main panel that supports V2X (vehicle to home, to grid)

7) Ethernet cabling throughout, we can make most devices PoE, also enable smart home

This can eliminate $ 1,000+ energy bills, which are now split between gas bills for two cars, natural gas for the water heater, heating, and cooking.
by nothrabannosir | 2025-11-02 19:12:25+00:00
This entire thread, including your original comment, isn’t really about your efforts though. It was about Haskell.

As I said : I read your comments, formed an idea based on that, dug deeper to see for myself, and got a completely different picture.

Whether that is because of how you write or because of how I read I’ll leave for you to decide.
by Rusky | 2025-11-02 19:12:35+00:00
You don't need any of that, and you can keep cancellation too.

The core of an eager cooperative multitasking system does not even need the concept of an executor. You can spawn a new task by giving it some stack space and running its body to its first suspension point, right there on the current thread. When it suspends, the leaf API (e.g. `lock`) grabs the current top of the stack and stashes it somewhere, and when it's time to resume it again just runs the next part of the task right there on the current thread.

You can build different kinds of schedulers on top of this first-class ability to resume a particular leaf call in a task. For example, a `lock` integrated with a particular scheduler might queue up the resume somewhere instead of invoking it immediately. Or, a generic `lock` might be wrapped with an adapter that re-suspends and queues that up. None of this requires that the language know anything about the scheduler at all.

This is all typical of how higher level languages implement both stackful and stackless coroutines. The difference is that we want control over the "give it some stack space" part- we want the compiler to compute a maximum size and have us specify where to store it, whether that's on the heap (e.g. tokio::spawn) or nested in some other task's stack (e.g. join, select) or some statically-allocated storage (e.g. on a microcontroller).

(Of course the question then becomes, how do you ensure `lock` can't resume the task after it's been freed, either due to normal resumption or cancellation? Rust answers this with `Waker`, but this conflates the unit of stack ownership with the unit of scheduling, and in the process enables intermediate futures to route a given wakeup incorrectly. These must be decoupled so that `lock` can hold onto both the overall stack and the exact leaf suspension point it will eventually resume.)

Cancellation doesn't change much here. Given a task held from the "caller end" (as opposed to the leaf callee resume handles above), the language needs to provide a way to destruct the stack and let the decoupled `Waker` mechanism respond. This still propagates naturally to nested tasks like join/select arms, though there is now an additional wrinkle that a nested task may be actively running (and may even be the thing that indirectly provoked the cancellation).
by bdangubic | 2025-11-02 19:13:13+00:00
it is not “engineering” - calling software development “engineering” is the craziest thing we’ve been able to squeeze through as an industry.

trade school won’t help here and 4 (even 8) year degree won’t help. at 4 years by the time you finish sh*t you learned the first year are obsolete. and everyone needs to spare us “the fundamentals” as that doesn’t exist - in my 3 decades in the industry the absolute worst colleagues were once with solid fundamentals (knows all of theory, can’t get any work done…)
by gpupromain | 2025-11-02 19:13:24+00:00
Hey everyone!

I've been running GPU servers for ML workloads and got tired of SSH-ing into boxes just to check if my GPUs are actually working. So I built *GPU Pro* - a monitoring tool that's actually enjoyable to use.

### What makes it different?

*It just works.* Seriously. - Single binary, no Docker containers, no Python dependencies, no npm nightmares - Works over SSH/tunnels (because your GPU server probably doesn't have a GUI) - Both Web UI and TUI - pick your poison - Real-time monitoring without eating your CPU
by richard_todd | 2025-11-02 19:13:32+00:00
ipchains is a perfect representation of what I want to see. They introduced it as an option alongside ipfirewall in 2.1, made it the default but allowed fallback to ipfirewall in 2.2, and removed ipfirewall in 2.4. That is a sane way to introduce a large breaking change. Not to mention they provided compatibility scripts to try to smooth over the user-side differences.

They certainly did NOT say "I'm replacing ipfirewall with ipchains in six months, and if your distro can't handle it you should sunset your distro."

It shouldn't be controversial to request a measured approach when making major changes to software lots of people depend on. That's part of the burden of working on important software. Note I'm not against apt or anything moving to rust.

edit: spelling
by Panino | 2025-11-02 19:13:36+00:00
> Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve

This is not correct. There isn't a cdb subdomain because cdb.cr.yp.to doesn't have NS records, which is where DNSCurve fits in. If you have a DNSCurve resolver, then your queries for cdb.cr.yp.to will use DNSCurve and will be sent to the yp.to nameservers.

From there, if you have pqconnect, your http(s) connection to cdb.cr.yp.to will happen over pqconnect.

Maybe the confusion is because both DNSCurve and pqconnect encode pubkeys in DNS, but they do different things.

Here is DNSCurve:

$ dig +short ns yp.to uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.

Here is pqconnect:

$ dig +short cdb.cr.yp.to pq1htvv9k4wkfcmpx6rufjlt1qrr4mnv0dzygx5mlrjdfsxczbnzun055g15fg1.yp.to. 131.193.32.108

Like CurveCP, pqconnect puts the pubkey into a CNAME.
by boshomi | 2025-11-02 19:14:02+00:00
no, this are real world prices

https://www.infolink-group.com/spot-price/ https://wind.in-en.com/html/wind-2462559.shtml (chinese example)

BESS 5MWh 52 USD/kWh: https://www.metal.com/Battery-Cell-And-Module/202407100001

Yes, electricity is becoming very cheap in China, and it will be difficult for the West to keep up here. Exorbitant US tariffs are also counterproductive, as they only serve to secure monopoly profits for old utilities.
by jborean93 | 2025-11-02 19:15:39+00:00
The problem I have with using a gMSA outside of Windows is you need a Kerberos principal and credential for that principal in the first place to allow retrieving the gMSA details. Why not just use that principal and avoid adding this next step.

It would be great if Linux had a mechanism where the host itself could act as the principal to retrieve the gMSA like on Windows but the GSSAPI worker model just works differently there and runs in process. A similar problem exists for using Kerberos FAST/armouring where Windows uses the hosts' ticket to wrap the client request but on Linux there is no privileged worker process that protects this ticket so the client needs to have full access to it.

The closest thing I've seen is gssproxy [1] which tries to solve the problem where you want to protect host secrets from a client actually seeing the secrets but can still use them but I've not seen anything from there to support gMSAs for armouring for client TGT requests.

[1] https://github.com/gssapi/gssproxy
by andai | 2025-11-02 19:16:58+00:00
>But why aren’t LLM inference engines deterministic? One common hypothesis is that some combination of floating-point non-associativity and concurrent execution leads to nondeterminism based on which concurrent core finishes first. We will call this the “concurrency + floating point” hypothesis for LLM inference nondeterminism.

Dang, so we don't even know why it's not deterministic, or how to make it so? That's quite surprising! So if I'm reading this right, it doesn't just have to do with LLM providers cutting costs or making changes or whatever. You can't even get determinism locally. That's wild.

But I did read something just the other day about LLMs being invertible. It goes over my head but it sounds like they got a pretty reliable mapping from inputs to outputs, at least?

https://news.ycombinator.com/item?id=45758093

> Transformer components such as non-linear activations and normalization are inherently non-injective, suggesting that different inputs could map to the same output and prevent exact recovery of the input from a model's representations. In this paper, we challenge this view. First, we prove mathematically that transformer language models mapping discrete input sequences to their corresponding sequence of continuous representations are injective and therefore lossless, a property established at initialization and preserved during training. Second, we confirm this result empirically through billions of collision tests on six state-of-the-art language models, and observe no collisions.

The distinction here appears to be between the output tokens versus some sort of internal state?
by cannonpalms | 2025-11-02 19:17:04+00:00
I've found the latency of /compact makes it unusable. Perhaps this is just the result of my waiting until I have 0% context remaining.

Fun fact, a large chunk of context is reserved for compaction. When you are shown that you have "0% context remaining," it's actually like 30% remaining that's reserved for compaction.

And yet, for some reason I feel like 50% of the time, compaction fails because it runs out of context or hits (non-rate) API limits.
by terminalshort | 2025-11-02 19:17:20+00:00
The governing bureaucrats of the post WWII period have decided that the limited government of the previous era does not give them the level of control over citizens lives that they want. They know that rolling back existing protections is difficult politically since those pesky citizens don't know what's good for them. So our ruling betters need to be a bit more clever. They stoke fear over criminals being out of control because they are using scary new technology that the police just can't handle. Therefore we need to pass harsh new laws to control it. Of course over time that "scary new technology" becomes the routine way everybody communicates, but now without the legal protections that the old system had.
by ziml77 | 2025-11-02 19:17:27+00:00
Squash is just something you do at the point of merging. It's a single option during the merge and doesn't have you doing any more work than a merge that you don't squash. I don't know about github, but I know in gitlab it's a simple checkbox in the merge request (and it can be set to be checked by default by the admin if they want).
by jborean93 | 2025-11-02 19:17:42+00:00
That's the realm side which should be upper case. The comment reference was for hostname themselves which I've always just done as lower case and have never seen a reason to make it upper case. The krb5.conf has a [domain_realm] section which can map a DNS name/suffix to the actual realm

[domain_realm] .domain.com = DOMAIN.COM domain.com = DOMAIN.COM
by array_key_first | 2025-11-02 19:18:31+00:00
Wayland doesn't say "this is impossible", it says "this is out of scope of the core display protocol, implement this somewhere else".

Which, well, we do. Practically all the X usecases are covered on Wayland systems now. Screen sharing, screen clipping, global hotkeys, file pickers, getting the window title like you said... I can do all of that on KDE, right now, under Wayland.
by Volundr | 2025-11-02 19:19:18+00:00
If all you care about it fixing the bug, this is probably often true. Certainly bisect is not part of my daily workflow. Sometimes though you also need to know how long a bug has been in place e.x. to track down which records may have been incorrectly processed.

Edit: tracking down where something was introduced can also be extremely helpful for "is this a bug or a feature" type investigations, of which I have done many. Blame is generally the first tool for this, but over the course of years the blame and get obscured.
by tptacek | 2025-11-02 19:19:41+00:00
So, (1) this is a dead letter because UN cybercrime isn't going to happen here, and (2) it's not a good treaty and I wouldn't support it anyways, but the UN cybercrime convention doesn't have any of the problematic terms discussed in this CJR article. It seeks to criminalize:

(7) Unlawful access to systems

(8) Interception and wiretapping

(9) Interfering with data (presumably: encrypting and ransoming databases)

(10) DOS attacks

(11) Knowlingly selling hacking tools to criminals

(12) Forging online documents

(13) Online wire fraud

(14) CSAM

(15) Solicitation and grooming

(16) Revenge porn

Articles 14-16 are the closest you get to something not "according to Hoyle" cybercrime. I wouldn't want them in my cybercrime treaty, but I'd be pretty chill about them being standalone domestic laws.

A reminder: no matter what a UN convention says, treaties don't preempt the US Constitution. We could not enforce a treaty that includes Nigeria's misinformation terms --- it would violate the First Amendment. (Also useful to know, contrary to widespread belief online, that a self-executing treaty is itself preempted by statutes passed after it).
by redwall_hp | 2025-11-02 19:20:11+00:00
Whole countries of comparable size to the US happily put similar mascots all over their products, and pay other companies big money to use their characters. They're all over busses and billboards. The Korean ramen brand I buy has Kpop Demon Hunters on it now. (And Buldak usually has their little chicken dude.) Casio and Fender have expensive products with Hatsune Miku on them...which has been used in ad campaigns by petroleum and rail companies in Japan.

American corporate culture is dehumanizing and dystopian, not a standard for professionalism.
by Forgeties79 | 2025-11-02 19:20:38+00:00
> I don't mind things like huge cooling towers or massive dams.

^That’s not “cherry picking.“ They are saying the two things that they would not mind seeing in the distance. It is reasonable to assume that it was not an omission to avoid hurting their point, but rather that coal power smoke stacks are not on list.

It strikes me as the much more obvious reading. “Of the things you listed, these two don’t really bother me.”
by travisjungroth | 2025-11-02 19:20:47+00:00
Maybe if the mantra was “Cattle or pets?” that would help people. Neither is wrong, it’s just a mindset that a lot of decisions flow from.

I think what happened was people working on lots of servers realized they were taking care of them in a way that was labor intensive per unit (pets). They needed to work at a distance, in a way that worked on the whole group at once (cattle).

Then, you get the “cattle not pets” mantra, as if it’s inherently bad. But it’s not! If you have two units, take care of them like you have two units, whether it’s servers or cows.

“We’re taking care of these 100 servers like we have two! This is dumb!”

“I’m taking care of these two servers like I have 100! This is dumb!”

And back and forth.
by terminalshort | 2025-11-02 19:21:17+00:00
> Across the world, well-meaning laws intended to reduce online fraud and other scourges of the internet are being put to a very different use.

If only someone, anyone, could have foreseen this /s. I read so many HN comments about the "slippery slope fallacy," back when the powers that be were censoring the people that they didn't like. I bet they'll be right back where they were next time the government is going after the "misinformation" they don't like.
by nonethewiser | 2025-11-02 19:21:39+00:00
>If you need to base64-encode a massive JSON object, the URL probably isn’t the right place for that state.

Why?

I get it if we're talking about a size that flirts with browser limitations. But other than that I see absolutely no problem with this. In fact it makes me think the author is actually underrating the use-case of URL's as state containers.
by gpm | 2025-11-02 19:22:09+00:00
The entire rust coreutils package, as installed, is 12 MB https://packages.ubuntu.com/questing/rust-coreutils Which is nearly double the gnu coreutils package but still a complete nothing burger: https://packages.ubuntu.com/questing/gnu-coreutils

I think what's happening here is that they've all been compiled into one binary, and then that one binary hardlinked to a variety of names like /usr/bin/ls. Since they all show as having the same inode and the same size.

The other 1.5G of your 1.5G /usr/bin is unrelated to rust coreutils.
by tptacek | 2025-11-02 19:22:27+00:00
The big problem with CFAA isn't particular to CFAA at all; it's that it shares the 2B1.1 loss table with all the other federal criminal statutes, and computers are very good and very fast at running the number on that table up. It's a real problem and I'm not pushing back on the idea that something should change about it, but I wouldn't characterize the problem the way you do, as the law singling out crimes involving computers.

Part of the history of CFAA was that it was passed because the state of the law preceding it didn't comfortably criminalize things like malicious hacking and denial of service; you can do those things without tripping over wire fraud.
by eastbound | 2025-11-02 19:22:37+00:00
Squashed PR allow you to see a single commit, while rebased PRs show up as multiple. The squash has the defect that you can’t rebase PRs that were on top.

But a MERGE… is a single commit on Master, while keeping the detailed history!

- We just don’t use the merge because they are ugly,

- And they’re only ugly because the visualizers make them ugly.

It’s a tooling problem. The merge is the correct implementation. (and yet I use the rebase-fast-forward).