MurphyA/hacker-news huggingface dataset:
by paul_h | 2025-05-28 09:38:32+00:00
An edu piece on Google style monorepos - https://github.com/paul-hammant/google-monorepo-sim and video https://www.youtube.com/watch?v=L67ri_xe2oQ - showing how their Piper would work for slimming checkouts (git sparse checkout for the sim).

I go into the DAG-centric nature of Google's in my video, and that was one of the reasons for making it and the sim repo.

I did at the outset think that the Google way lead to faster builds. It could could be with parallel step execution and a build cache is setup, but I don't think it is significantly different in a vanilla serial mode.

Perhaps there's another benefit - slimming a monorepo to feed to a coding AI, in order to bring down tokens needed for a task.

I've WIP for a C# module, but I'm stuck on some fine-grained setup for 'vstest'. I also asked Google's Jules agent to migrate one of the depended-on modules to Kotlin, and it has been 24 hours now, with it assuring me that it hasn't stalled.
by spiffyk | 2025-05-28 09:39:26+00:00
> I'm a bit confused. Is anyone's website currently being DDOS'd by scrapers for LLMs or is this a hypothetical?

It is very real and the reason why Anubis has been created in the first place. It is not plain hostility towards LLMs, it is *first and foremost* a DDoS protection against their scrapers.

https://drewdevault.com/2025/03/17/2025-03-17-Stop-externali...

https://social.kernel.org/notice/AsgziNL6zgmdbta3lY

https://xeiaso.net/notes/2025/amazon-crawler/
by jiggawatts | 2025-05-28 09:39:49+00:00
It reads like an astroturf advertisement for a product, but Erlang is open source and free.

It's a worthless article anyway for the simple reason that there are no graphs, numbers, or reproducible experiments. The code snippets aren't the whole programs and the test harness setup isn't spelled out. The programs themselves look different in what they're doing, so they're not even equivalent! It's hard to tell because, for example, in some snippets the outermost loop is shown, but for C++ only the per-request "workload", but not all of it.

Even just the how of the testing can make a huge difference in my experience, especially when running synthetic workloads against garbage-collected languages. Most of them will never crash under normal workloads, but if you go out of your way to generate stupid amounts of memory allocations, practically none will be able to keep up.

The whole article is just nonsense, end-to-end, starting from the first content paragraph:

"Our test environment consisted of a cluster of 16 high-performance servers..."

Why a "cluster"? None of the workloads appear to be distributed or clustered applications! They're not testing Akka or Microsoft Orleans here, so why bother having more than one box?

What operating system was used?

What were the client systems? How many?

Were some of the languages "doing better" simply because they were slower at handling the test loads and hence failing slower?

Were the test clients correctly sending requests as fast as possible, or waiting sequentially for previous requests to complete before sending the next request?

Etc...
by gommm | 2025-05-28 09:40:26+00:00
This looks like LLM blog spam. To be taken seriously, they'd need to publish the implementation in each language of each benchmark which they didn't.

Instead they show pseudocode with very vague descriptions of failure mode that do not really make sense: "Under our error cascade simulation, some low-level failures in unsafe code regions propagated in ways that eventually caused deadlocks in resource management." That doesn't give any details nor does it sound like a realistic failure case to have "failures in unsafe code regions".
by gchamonlive | 2025-05-28 09:40:44+00:00
Rather than new tunings, they are more like tune mapping, from one possible set of fitness functions to our set of fitness functions.

And I'd argue that it's all signal. Noise is something very human -- maybe even for carbon-based lifeforms, but I'd be careful to make such broad assertion --, that which is unnecessary or harmful for the needs of the body.
Ask HN: Data.olllo new version – New demo videos and faster data previews
by olllo | 2025-05-28 09:40:54+00:00
Hi HN!

I’m the maker of Data.olllo – a no-code AI-powered tool for exploring and analyzing large datasets, now updated with new features and a smoother UX.

⸻

What’s new: • Live demo videos: See how to open and analyze large files quickly. • Works offline, with full local privacy – no data sent to the cloud. • Supports massive files – Excel, CSV, JSON, Parquet.

⸻

See how it works (https://olllo.top)

I built Data.olllo because I got tired of waiting for Excel or VS Code to open big files, and not everyone on my team codes in Python. Would love feedback, ideas, or criticism!

Thanks!
by berkes | 2025-05-28 09:41:21+00:00
I doubt any "anti-scraper" system will actually work.

But if one is found, it will pave the way for a very dangerous counter-attack: Browser vendors with need for data (i.e. Google) simply using the vast fleet of installed browsers to do this scraping for them. Chrome, Safari, Edge, sending the pages you visit to their data-centers.
by keiferski | 2025-05-28 09:41:22+00:00
I don't even think it goes as deep as right vs. left. It's more of a "hacker culture" (whatever that means in 2025) obsession with being subversive and fighting anyone that suggests metaphorically putting on suit and tie could actually solve the problem.

...as evidenced by the responses to my comment – the sheer hostility to the idea that maybe it's not a great idea to use the word shit in an activist project that aims at political change.

And so you're really not going to get any real change here, because it's easier to complain online and do nothing, while simultaneously shouting away anyone that suggests some minor changes would be more productive. The exact same conversation happens in the open source / free source movement.
by cormacrelf | 2025-05-28 09:41:44+00:00
> Meta has a sophisticated implementation of a target determinator on top of buck2, but I don’t believe it is open-source.

It is: https://github.com/facebookincubator/buck2-change-detector

> Some tools such as bazel and buck2 discourage you from checking in generated code and instead run the code generator as part of the build. A downside of this approach is that IDE tools will be unable to resolve any code references to these generated files, since you have to perform a build for them to be generated at all in the first place

Not an issue I have experienced. It's pretty difficult to get into a situation where your IDE is looking in buck-out/v2/gen/781c3091ee3/... for something but not finding it, because the only way it knows about those paths is by the build system building them. Seeing this issue would have to involve stale caches in still-running IDE after cleaning the output folder, which is a problem any size repo can have. In general, if an IDE can index generated code with the language's own build system, then it's not a stretch to have it index generated code from another one.

The problem is more hooking up IDEs to use your build system in the first place. It's a real slog to support many IDEs.

Buck recently introduced an MSBuild project generator where all build commands shell out to buck2. I have seen references to an Xcode one as well, I think there's something there for Android as well. The rust-analyzer support works pretty well but I do run a fork of it. This is just a few. There is a need (somewhat like LSP, but not quite) for a degree of standardization. There is a cambrian explosion of different build systems and each company that maintains one of them only uses one or two IDEs and integrates with those. If you want to use a build system for an IDE they don't support, you are going to have a tough time. Last I checked the best effort by a Language Server implementation at being build-system agnostic is gopls with its "gopackagesdriver" protocol, but even then I don't think anyone but Bazel has integrated with it: https://github.com/bazel-contrib/rules_go/wiki/Editor-and-to...
by anon7000 | 2025-05-28 09:42:02+00:00
When you have N repos, you also have N ways of managing dependencies, N ways of doing local bin scripts and dev environment setups, N projects with various out of date & deprecated setups, N places to look when you need to upgrade a vulnerable dependency, N services which may or may not configure telemetry in a consistent way, N different CI & deployment workflows…

It just gets very difficult to manage, especially if people frequently need to work across many repos. Plus, onboarding is a pain in the ass.

Monorepo example: if I want to add a new Typescript package/library for internal NodeJS use, we have a boot strapping script that sets it up. And it basically:

1. Inherits a tsconfig that just works in the context of the repo

2. Jest is configured with our default config for node projects and works with TS out of the box.

3. Listing / formatting etc are all working out of the box.

4. Can essentially use existing dependencies the monorepo uses

5. Imports in existing code work immediately since it’s not an external dependency

6. CI picks up on the new typescript & jest configs and adds jobs for them automatically

7. Code review & collaboration is happening in the same spot

8. This also makes it easier to have devs managing the repo — for example, routine work like updating NodeJS is a lot easier when you know everything is using a nearly identical setup & is automatically verified in CI.

One challenge I had to help solve in a previous job was that onboarding was difficult because we had a small number of large repos everyone worked in. The standards were slightly different across them. Npm, pnpm, and yarn were all in use. Deployment worked pretty differently among them. CI setups were unique, and each of the large projects had, if not a team, some number of people spending a lot of time just managing the project’s workflows.

So many coordination things just get easier when there isn’t an opportunity to get out of sync. If you do separate repos, you can totally share config… but now it costs a dependency update PR to pull in that tiny update to the shared unit test config and now everything. It’s just guaranteed to get out of sync, and it’s hard to catch issues when you can’t validate a config change with all projects using it at the same time.

So because it becomes trickier (and takes work) just to do the action of syncing multiple repo’s setups… inevitably, you end up with some “standards” that are loosely followed and a lot of slightly different setups that get hard to untangle the longer they grow. If you can accept the cost of context switching between repos, or if people don’t need to switch, maybe it’s ok… until something like a foundational dependency update (NodeJS, Typescript, React, something like that) needed for security becomes extremely difficult because you have a million different ways of configuring things and the JS ecosystem sucks
by jrvarela56 | 2025-05-28 09:42:06+00:00
> Basically the reason ignorance is so danger is that it aliases between harmless stupidity and extreme evil, but it fails to trigger our collective species evil detection pattern coding which results in an unbelievable cascade evil failure mode.

Great summary. The problem with ignorance is that you are more likely to forgive the perpetrator whereas a malicious actor would have been cutoff once detected. You then stick with the ignorant for way longer and suffer loses beyond what a malicious actor would've likely caused. This is my impression from relationships at work.
by zoobab | 2025-05-28 09:43:05+00:00
"a ridiculous expansion of IP rights - as if patents weren't enough"

Expanding patents to software, in Europe they replaced the 2005 software patent directive by the Unified Patent Court, which will ignore the exclusion of 'computer programs', like the EPO did, with no way for the question to be escalated to the CJEU:

https://ffii.org/unified-patent-court-has-an-eu-treaty-legal...

Multinational corporations also became part time judges, because rubberstamping software patents is easier when you can also corrupt the judicial system:

https://ffii.org/nokia-and-airbus-elected-as-judges-at-the-k...
by Dowwie | 2025-05-28 09:43:15+00:00
Hopefully this clarifies the value proposition for others:

Existing Lakehouse systems like Iceberg store crucial table information (like schema and file lists) as many small "metadata files" in cloud object storage (like S3). Accessing these files requires numerous network calls, making operations like query planning and updating tables inefficient and prone to conflicts. DuckLake solves this by putting all that metadata into a fast, transactional SQL database, using a single query to get what's needed, which is much quicker and more reliable.
by freetonik | 2025-05-28 09:45:29+00:00
Many people complained when VW "dared" to use drum brakes in the rear of ID.3, but it's a good idea, I think. Drum brakes do not pollute (as much), are cheaper, and easier to maintain. In the front, there are still regular disk brakes, and together with regen (recuperation), the overall use of polluting disk brakes is minimized. I'd be curious to see how much brake dust pollution is produced on average in this setup, compared to a regular ICE car with 4 disk brakes and no regen.
by yladiz | 2025-05-28 09:46:03+00:00
> I understand people have valid cases why they don't want their content scraped. Maybe they want to sell it - I can understand that, although I don't like it.

To be frank: it’s not your content, it’s theirs, and it doesn’t matter if you like it or not, they can decide what they want to do with it, you’re not entitled to it. Yes there are some cases that you personally have permission to scrape, or the license explicitly permits it, but this isn’t the norm.

The bigger issue isn’t that people don’t want their content to be read it’s that they want it to be read and consumed by a human in most cases, and they want their server resources (network bandwidth, CPU, etc) to be used in a manageable way. If these bots were written to be respectful, then maybe we wouldn’t be in this situation. These bots poisoned the well, and they affect respectful bots because of their actions.
by lynx97 | 2025-05-28 09:48:56+00:00
Great, this works here. I wonder, with extra-openai-models.yaml I was able to set the api_base and vision/audio: true. How do I do this with the llama-server-tools plugin? vision works, but llm refuses to attach audio because it thinks the model does not support audio /which it does).

EDIT: I think I just found what I want. There is no need for the plugin, extra-openai-models.yaml just needs "supports_tools: true" and "can_stream: false".
by econ | 2025-05-28 09:49:17+00:00
It would seem that way but per person, I pay 5 euro for the European parlement, 5 for our king, 3 euro for weapon research in genocidal Israël and 20 euro for some pointless meat grinder in Ukraine.

Our king (Netherlands) has 65% approval rating. In political leadership only Modi scores higher. King of Denmark has 94%. Norway 80-90%

Are you suggesting we get rid of kings day and work in stead? It would be worse than canceling easter. Imagine in 2025 we celebrate resurrection? Pretty funny if you think about it.
by kohlerm | 2025-05-28 09:49:19+00:00
Following dependencies is the way to go IMHO. Saying "Code Doesn't Think in Chunks", is IMHO not correct. Developers do thing in chunks of codes. E.g. this function calls that function uses that type and is used here and there. It is not really a file based model like Cline uses. The file based model is "just" simpler to implement :-) . We use a more sophisticated code chunking approach in https://help.sap.com/docs/build_code/d0d8f5bfc3d640478854e6f... Let's see, maybe we should open source that ...
by eviks | 2025-05-28 09:49:41+00:00
For some specific issues like clipping sure there are objective methods, and encoders use objective quality levels (so you don't target bitrate), and if it's not a tricky "subjective human experience can't be objective" question - the method to test is do A/B testing and see that humans can't detect a difference. That's audio transparent encoding. And since you don't care about other people for your personal phone use case, you can do this test yourself to detect the encoding quality level that's transparent to you.

And your examle doesn't make sense. You compare reencoded to the original, not to some 3rd sample. The issue here is whether to store large flacs or their smaller reencoded lossy variants. If you get a better quality flac, then you'll need to do another encoding to get a better lossy version
by tanelpoder | 2025-05-28 09:49:44+00:00
With SSDs that support namespaces you can use commands like "nvme create-ns" to create logical "partitioning" of the underlying device, so you'll end up with device names like this (also in my blog above):

/dev/nvme0n1 /dev/nvme0n2 /dev/nvme0n3 ...

Consumer disks support only a single namespace, as far as I've seen. Different namespaces give you extra flexibility, I think some even support different sector sizes for different namespaces).

So under the hood you'd still be using the same NAND storage, but the controller can now process incoming I/Os with awareness of which "logical device" they came from. So, even if your data volume has managed to submit a burst of 1000 in-flight I/O requests via its namespace, the controller can still pick some latest I/Os from other (redo volume) namespaces to be served as well (without having to serve the other burst of I/Os first).

So, you can create a high-priority queue by using multiple namespaces on the same device. It's like logical partitioning of the SSD device I/O handling capability, not physical partitioning of disk space like the OS "fdisk" level partitioning would be. The OS "fdisk" partitioning or LVM mapping is not related to NVMe namespaces at all.

Also, I'm not a NVMe SSD expert, but this is my understanding and my test results agree so far.
by chneu | 2025-05-28 09:50:01+00:00
You forgot cost of fuel(this alone likely offsets your imaginary rental cost), higher insurance rates for trucks(they kill people in routine accidents), cost of extra tires(trucks eat through tires), and higher cost of ownership in general. If you're using a truck as a work truck it'll also need to be replaced much quicker, adding to the overall cost.

Trucks are expensive for the owner and society.

Also, the majority of trucks in the US never do truck things. Like 75% are urban grocery getters. Americans have a serious consumption/ego/entitlement problem. Trucks are a great example of that problem. Instead of just saying, "I like truck. I want truck. I don't care it bad", people make up imaginary math that doesn't make sense instead of just admitting it's an ego thing.

The sad part of all this is the world laughs at the US over this stuff. We're a laughing stock and the people embarrassing us are proud of it. It's so shameful.

"I'm not that kind of American" has become a routine thing to say while traveling abroad.
by Peroni | 2025-05-28 09:50:46+00:00
Create a stock response for candidates that are coming to you via their platform that explains they do not represent your company and that you will not review any applications that come via their platform. Include a link to your own careers page and encourage candidates to reapply there if they are genuinely interested in working for your company.

Have you tried contacting the company directly and asking them to remove your company details from their platform?
by rwieruch | 2025-05-28 09:51:04+00:00
Over the past four years, I’ve set up three monorepos for different companies as contract work. The experience was positive, but it’s essential to know your tools.

Since our monorepos were used exclusively for frontend applications, we could rely entirely on the JavaScript/TypeScript ecosystem, which kept things manageable.

What I learned is that a good monorepo often behaves like a “polyrepo in disguise.” Each project within it can be developed, hosted, and even deployed independently, yet they all coexist in the same codebase. The key benefit: all projects can share code (like UI components) to ensure a consistent look and feel across the entire product suite.

If you're looking for a more practical guide, check out [0].

[0] https://www.robinwieruch.de/javascript-monorepos/
by gsf_emergency | 2025-05-28 09:51:27+00:00
(This is not to say that ultrafast optical switching isn't far more exciting than desktop EUV sources-- in fact, I personally applaud the pivot, if indeed there was one )

I believe I recently saw on goog schol other attempts at vuv lasing/light emission using very similar setup of laser pumping in si-gr (Can't remember the exact search terms I used at the time, or how unsuccessful they were)

E: here's one (2019 dissertation; ndyag ns-pulsed laser probe) which openly states the underlying motivations. You can also check the phd thesis when it comes out, usually they won't hold back on their informal motivations at defence-time :)

https://tesidottorato.depositolegale.it/bitstream/20.500.142...

If I hadn't read your doubts about the stability above, which reminded me of the limited lifetime of sn vapor sources (there due to contamination of optics), I wouldn't have imputed those motivations to TFA

E2: one from 2019 on VdW vuv detectors (ns response time)

https://pubs.acs.org/doi/full/10.1021/acsphotonics.9b00729

E3: I also thought that the mention of "ambient conditions" in the uni PR was slightly out of place outside the context of light sources.
by Dowwie | 2025-05-28 09:52:01+00:00
Time series data is naturally difficult to work with, but avoidable. One solution is to not query raw time series data files. Instead, segment your time series data before you store it, normalizing the timestamps as part of event processing. Sliding window observations will help you find where the event begins and then you adjust the offset until you find where the time series returns to its zero-like position. That's your event.
by rwmj | 2025-05-28 09:52:19+00:00
Pretty sure the original Minix filesystem name length was also limited to 14 bytes.

Edit: Yes:

https://github.com/gdevic/minix1/blob/3475e7ed91a3ff3f8862b2...

https://github.com/gdevic/minix1/blob/master/fs/type.h
by sph | 2025-05-28 09:52:29+00:00
Don’t try to transform a paper notebook into a database. All those organizational tools are elaborate forms of procrastination.

What I do is write notes in the best format for paper: an append-only log with a date on top. Whether digitally or on paper, I rarely if at all need to consult notes from a long time ago, so the log is good enough for most use cases. In fact, as I mentioned elsewhere, writing by hand is not to store data, it’s a way to effectively digest information and incorporate it into your brain. You’ll get a lot of benefit of writing something and immediately throwing it away, so who cares about indexing it for later.
by octo888 | 2025-05-28 09:52:30+00:00
The same could come to Europe (lowballing broke people), because you can just make employees give their consent by baking it into all employment contracts. Just like the working time directive opt-out (HR say "take it or leave it" to 99.9% of people).

It probably already happens where it's already acceptable to request financial checks such as the finance industry.
by flir | 2025-05-28 09:52:38+00:00
Value engineering. When you can't grow by selling more widgets, your only real choice is to make (almost) the same thing, but cheaper.

But Cory's a polemicist. He'd absolutely prefer the memorable word he coined himself to the acceptable, drab one that already exists.

(Plus value engineering is only one way to enshittify a product. There's also subscription models, selling data, jamming ads in everywhere... the advantage of Cory's word is that it captures everything).