MurphyA/hacker-news huggingface dataset:
by kragen | 2025-08-06 17:50:23+00:00
Konrad Hinsen calls this "software collapse": when the platform has been eroded out from underneath your software and it collapses. https://hal.science/hal-02117588/document

There's no reason such a "bedrock platform"♢ needs to be a shitty pain in the ass like the IBM PC or NES (the examples on https://permacomputing.net/bedrock_platform/). Those platforms were pragmatic tradeoffs for the existing hardware and fabrication technology in the market at the time, based on then-current knowledge. We know how to do much better tradeoffs now. The 8088 in the IBM PC was 29000 transistors, but the ARM 2 was only 27000 transistors†. Both could run at 8 MHz (the 8088 in its later 8088-2 and 80C88 incarnations), but the ARM 2 was a 32-bit processor that delivered about 4 VAX MIPS at that speed (assuming about ½DMIPS/MHz like the ARM3‡) while the 8088 would only deliver about 0.3 VAX MIPS (it was 0.04DMIPS/MHz). And programming for the 8088's segmented memory model was a huge pain in the ass, and it was crippled by only having 20 address lines. 8088 assembly is full of special-purpose registers that certain instructions have to use; ARM assembly is orthogonal and almost as high-level as C.

Same transistor count, same clock speed, dramatically better performance, dramatically better programming experience.

Similarly, Unix and Smalltalk came out about the same time as Nova RDOS and RT-11, and for literally the same machines, but the power Unix and Smalltalk put in the hands of users far outstripped that of those worse-designed systems.

So, let's put together a bedrock platform that we could actually use for our daily computing in practice. Unlike the NES.

______

♢ Stanislav Datskovskiy's term: http://www.loper-os.org/?p=55

† https://en.wikipedia.org/wiki/Transistor_count

‡ https://netlib.org/performance/html/dhrystone.data.col0.html but note that the ARM3 had a cache, so this depends on having RAM that can keep up with 8MHz. Both the ARM2 and ARM3 were mostly-1-instruction-per-clock pipelined RISCs with almost exactly the same instruction set. https://en.wikipedia.org/wiki/Acorn_Archimedes, https://www.onirom.fr/wiki/blog/21-04-2022_Acorn-Archimedes/, and its twin https://wardrome.com/acorn-archimedes-the-worlds-first-risc-... confirm the 8MHz and 4MIPS.
by wkat4242 | 2025-08-06 17:50:25+00:00
Oh thanks I didn't know that :O

I do also need an API server though. The one built into OpenWebUI is no good because it always reloads the model if you use it first from the web console and then run an API call using the same model (like literally the same model from the workspace). Very weird but I avoid it for that reason.
by rglover | 2025-08-06 17:50:31+00:00
Federal debt before the great depression hovered around ~16%-17% of GDP and even in the throws of it got up to ~40% of GDP. Now it's at 120%.

If my claim of this all leading to a greater depression is extraordinary (to the point of being easily dismissed), then someone will have to walk me through the math.

I think that, just like in the 1920's, we've gorged ourselves on debt, speculation, and hubristic thinking and the humbling is coming at us like a freight train. Instead of producing value, we produced inordinate amounts of bullshit and now the bill is coming due.
by avar | 2025-08-06 17:51:02+00:00
> It's only a trend because people are not using them like bikes.

Who's using E-Bikes "like bikes"?

The grandmother maintaining an easy 20 km/h against strong headwinds on her Sunday cruise? The petite mother bringing her kids to school at a comfortable 20 km/h in a 50 kg cargo bike, something she'd probably struggle to do at 5 km/h unassisted by an electric motor, if at all?

The fact is that E-Bikes have have opened up all sorts of use cases that wouldn't be practical without motor assistance.

I don't think "Fat bikes" are a particular outlier here. The basic design (or something similar) has been around since the 60's[1] as lowrider bikes. Fat Bikes provide basically the same riding geometry, only with an extra wide tire.

> actual bicycles which use normal bike parts.

I can assure you they use "normal bike parts", e.g. Shimano shifters, brake discs, or similar. Despite the rhetoric around them, they're not actually in the performance envelope (even when speed unlocked) of requiring actual motorcycle parts.

Yes, the frame and seat are custom/unusual for a bicycle, but the same is true (at least for the frame) for a lot of modern bicycle designs, e.g. VanMoof and Cowboy bicycles (both of which you'd presumably consider "like bikes").

1. https://en.wikipedia.org/wiki/Lowrider_bicycle
by andrepd | 2025-08-06 17:51:25+00:00
Option trading is notoriously difficult. HFTs simply don't take a position at all: they build portfolios that are as neutral as possible in every measure (not only delta, but in vol, its higher order terms, higher order delta terms, etc). This is very difficult to do unless you have substantial capital to absorb short term fluctuations, but if you do you can capture a consistent and very low risk profit.
by superfrank | 2025-08-06 17:51:28+00:00
> In June, Google warned that a threat actor they classify as 'UNC6040' is targeting companies' employees in voice phishing (vishing) social engineering attacks to breach Salesforce instances and download customer data

> [...]

> In June, one of Google's corporate Salesforce instances was impacted by similar UNC6040 activity described in this post

Nope. Good old fashion social engineering.
by jonah-archive | 2025-08-06 17:51:57+00:00
I cook in a Gozney as well and the things that have made the biggest difference for me are a slow-rise dough (I've found that the really high-hydration recipes didn't make a huge difference for me and made the dough way more difficult to handle, so I haven't been doing that) and putting the sauce on hot (I keep it at a low simmer on the stove and dress directly from there). Shaving some parm over the whole thing with a microplane and adding a quick drizzle of olive oil right before popping it in also makes a big difference (I crank the oven to around 900F and my pizzas usually cook in ~75 seconds).

Ken Forkish's _The Elements of Pizza_ is a great resource though it's more focused on standard home oven cooking. His slow-rise recipe is roughly: 350g water (at ~95F), 13g salt, 1.5g instant dry yeast, 500g white flour (I use Caputo 00), mix the first three and let the yeast hydrate, then mix in the flour, rest 20 minutes, knead briefly until smooth, two hour room-temp rise in an oiled tub, shape into balls, then fridge rise (until either the next day or the day after, but best the next day). I do it with 310g of water to get a 60% hydration dough which is my preference.
by cthalupa | 2025-08-06 17:52:05+00:00
A huge chunk of Novo losing it's valuation is the fact that Eli Lilly is absolutely destroying them on the next generations of these. Tirzepatide is better than Semaglutide, and Retatrutide is better than Tirzepatide. Mazdutide looks to be a particularly good fit for Asia for a variety of reasons. And from Novo, Cagrilintide/CagriSema look to be a bust. Rybelsus is a bust.

Other "newcomers" in the GLP-1 space are also showing more promise than what Novo has in the pipeline. Boehringer Ingelheim has Survodutide in the pipeline as well, along with plenty of others.

They're the least interesting game in town when it comes to the incretin mimetics at this point.
by johnisgood | 2025-08-06 17:52:13+00:00
Somewhat related, it is something I have been trying to figure out, and I did, successfully! This information might help others.

You can create a standalone binary from .tcl files by using KitCreator and sdx (Starkit Developer eXtension). You need to wrap your Tcl script into a .kit file (a virtual filesystem), then combine it with a Tcl runtime to produce a native ELF (or Windows) binary. Optionally, you can encrypt your Tcl code with AES (e.g., using openssl enc) before embedding it, and decrypt it at runtime via a custom loader. The result is a self-contained executable that runs anywhere Tcl is supported. :)

I have a script for it!

Standalone encrypted application created: -> /tmp/tcl/app.run -> AES KEY (hex): 95a8a95e8322344b808ebd3fd3986b5b -> AES IV (hex): 69eac67341d2657a0b00d3006addb131 -> To run it: ./app.run $ ./app.run Hello world from binary! $ file app.run app.run: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=f3fabb748cc7e61c2fafc7c288f282db2f6de0c7, for GNU/Linux 3.2.0, stripped

The generated app.run is 10 MB and ldd shows it only needs "linux-vdso", "libm", "libc", and "ld-linux-*".

Useful links (taken from my script):

TCL_VERSION="9.0.1" TCL_SRC_URL="https://sourceforge.net/projects/tcl/files/Tcl/${TCL_VERSION}/tcl${TCL_VERSION}-src.tar.gz" SDX_KIT_URL="https://chiselapp.com/user/aspect/repository/sdx/uv/sdx-20110317.kit" TCLLIB_URL="https://github.com/tcltk/tcllib/archive/refs/heads/main.zip"

I wonder if there is a more recent sdx, although it still works.

FWIW, the steps are:

1. Download and build Tcl 2. Clone KitCreator and build Tclkit 3. Download SDX 4. Create the loader ($VFS_DIR/main.tcl) 5. Download and extract Tcllib (optional) 6. Copy any modules you want from Tcllib (optional) 7. Add dummy assets to $VFS_DIR/assets/data.json (has a specific format) (probably optional) 8. Wrap and generate .kit and final .run ELF (you need 2 Tclkit binaries, just duplicate it)

If you have any questions, let me know!

---

I have used critcl before, but can't find my code anymore. :( It is good stuff though.
by wkat4242 | 2025-08-06 17:52:24+00:00
> This isn't for you, then. You should evaluate quality here based on the fact you don't need a GPU.

I know but it was more of a general comment. A really good TTS just isn't around yes in the OSS sphere. I looked at some of the other suggestions here but they have too many quirks. Dia sounds great but messages must have certain lengths etc and it picks a random voice every time. I'd love to have something self hosted that's as good as openai.
by cmrdporcupine | 2025-08-06 17:52:30+00:00
Emacs is an IDE construction kit.

(Among other things)

By which I mean you can make your IDE with it, but it's not an out of the box thing, and it'll be bespoke and unique for you.

With LSP and treemacs and company mode, it's a pretty decent IDE. It just requires you to get all the pieces set up the way you want.
by uberman | 2025-08-06 17:52:31+00:00
People here are different from others, so why not monetize that?

How? With ads?

The current system is set up so that no one gets paid and only the winner takes all.

Well for the first part, no one likes ads, so no one gets paid and that is how the system is set up. For the second part, who do you see as this "winner" who takes all and what are they getting?

Alternatively, are you suggesting that Y Combinator create a meme coin and give people coin to participate rather than internet points? Do you feel that there are not enough quality posts at the moment? What would be their incentive to seed these coins with value and how would someone buy and sell their rep? Why would allowing someone to simply purchase rep add any real value to the quality of the discourse here?
by 0cf8612b2e1e | 2025-08-06 17:53:01+00:00
I used to work in proteomics and I agree. The article is written at such a high level, the actual innovation is not that clear.

Barcodes that can 9 plex samples? Thermo TMT is up to 32 plex. Multiple injections with time offset? Also not a new idea.

What is unstated is that there is no free lunch. You can go fast or you can go “deep” (high resolution/separation). Running a MS at breakneck speed does work, but you are sacrificing quantitative accuracy and the depth of proteome coverage. Which is entirely valid way run, depending on your use case. Work in a hospital and need to do 1000 samples a day? Fast and targeted makes sense. Trying to discover some novel Alzheimer’s biomarker? You want to go slowly and measure everything you can.

Ultimately this is going to be just another tool available for researchers who have to weigh the pros and cons for the particulars of their samples.

The mention of PTMs was also a bit of a distraction. Measuring PTMs is an entirely different level of sophistication for which fast MS is rarely appropriate.

Edit: I should add that Alzheimer’s was probably just used as marketing copy, but is a terrible example for ludicrous-speed-go. Human Alzheimer’s samples are incredibly hard to procure. You either need brain or spinal fluid (apparently very painful to extract from the living). For precious samples you are usually willing to operate more slowly to ensure you do a better job.
by mvieira38 | 2025-08-06 17:53:41+00:00
Good to see competition for Codex. I think cloud-based async agents like Codex and Jules are superior to the Claude Code/Aider/Cursor style of local integration. It's much safer to have them completely isolated from your own machine, and the loop of sending them commands, doing your own thing on your PC and then checking back whenever is way better than having to set up git worktrees or any other type of sandbox yourself
by 1970-01-01 | 2025-08-06 17:53:42+00:00
IMHO, you need to address how everyone is dating its superficially attractive cousin - free open source software - before you tackle the issue of it rotting away. When your entire castle rests upon the following language, perhaps it's somewhat your fault when it stops working tomorrow.

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
by fellowniusmonk | 2025-08-06 17:53:48+00:00
I've never seen something so egregious before, it made it impossible to read without covering it with my hand.

But I realized something by attempting to read this article several times first.

If I ever want to write an article and reduce peoples ability to critically engage with the argument in it I should add a focus pulling animation that thwarts concerted focus.

It's like the blog equivalent of public speakers who ramble their audience into a coma.
by vidarh | 2025-08-06 17:53:54+00:00
That's an assertion there is to my knowledge no evidence for.

There's no evidence to suggest that reading comprehension or scientific aptitude has any link whatsoever to ability to maintain the willpower to stick to a diet. It seems distinctly non-obvious to think it would matter.

And all the evidence is that diets works soo poorly that the effect would need to be astronomical for it to counter-act just how unlikely they are to effect lasting change.
by IshKebab | 2025-08-06 17:54:09+00:00
And it's not just inefficiency. Even with fancy FFI generators like PyO3 or SWIG, adding FFI adds a ton of work, complexity, makes debugging harder, distribution harder, etc.

In my opinion in most cases where you might want to write a project in two languages with FFI, it's usually better not to and just use one language even if that language isn't optimal. In this case, just write the whole thing in C++ (or Rust).

There are some exceptions but generally FFI is a huge cost and Python doesn't bring enough to the table to justify its use if you are already using C++.
by kragen | 2025-08-06 17:54:36+00:00
Hey, didn't you write kjbuckets and Gadfly? Or was that Aaron Watters? I was thinking about that the other day: that was one of the coolest pieces of software for Python 2 (though I think it predated Python 2): an embedded SQL database without needing SQLite's C API. I suppose it's succumbed to "software rot" now.

I think "boring software" is a useful term.

Exciting things are unpredictable. Predictable things aren't exciting. They're boring.

Stock car racing is interesting because it's unpredictable, and, as I understand it, it's okay for a race car to behave unpredictably, as long as it isn't the welds in the roll bars that are behaving unpredictably. But if your excitement is coming from some other source—a beautiful person has invited you to go on a ski trip with them, or your wife needs to get to the hospital within the next half hour—it's better to use a boring car that you know won't overheat halfway there.

Similarly, if a piece of software is a means to some other end, and that end is what's exciting you, it's better to use boring software to reach that end instead of exciting software.
by nextos | 2025-08-06 17:54:40+00:00
Just to clarify, I think fabricated data in top biology and medicine journals is relatively rare because it's typically high-throughput data, and you must archive it. It's just too much trouble to fake that.

However, another equally damaging form of fraud, cherry-picking data and manipulating statistical inference is common. I think the reason is that it's much simpler to get the results you want this way, and you are much less likely to get caught.

Previously, fake data was common, e.g. in the form of fabricated Western blots, as it has been proven by large-scale image analyses conducted by sleuths. I imagine similar forms of fraud are still frequent in other disciplines or in domains that generate low-throughput data, such as some clinical trials.
by q2dg | 2025-08-06 17:55:08+00:00
Well, you can block everything using a wildcard blocking rule (for that, go to "Filters → DNS blocklists" and add this custom rule: ||*^ ) and then you can allow the domain (and subdomains, if needed, for instance "everything.ycombinator.com"; for that, go to "Filters → Allowlist" and add this: @@||ycombinator.com^ )
by kragen | 2025-08-06 17:55:27+00:00
> In other words, if you need your software to live in the dirty world we live in, and not just in a pristine bubble, things are gonna rot.

Well, that's why I called BubbleOS BubbleOS: https://gitlab.com/kragen/bubbleos/

Not there yet, though...

I share your painful experience of losing my work to proprietary platforms.
by petsfed | 2025-08-06 17:55:36+00:00
Is Logitech not a major company, backed by decades of experience building these things? Its not MadCatz, that's for sure. I mean, logitech is the undisputed king of low-to-mid-range joysticks, and has held that title more or less since microsoft stopped making joysticks and gamepads in 2002. Microsoft didn't make a PC-friendly controller again until 2005. They basically ceded the market during that period of time. Of course, logitech hasn't sold as many units. But they know what they're doing.

Granted, a Logitech controller not the first party controllers, and I'm prepared to believe that the Xbox people made a generally better controller, but I'm not convinced it was so much better as to be an actively bad idea to use the Logitech device. Like, once you get to the "pretty good, people won't return it" phase of controller development, its just fine tuning for gameplay performance, and there's absolutely nothing about controlling a tourist submarine that makes e.g. controller latency or even signal integrity above and beyond the baseline the bottleneck. I'd wager that the real reason they picked it likely devolved down to "what driver is our embedded controls engineer most comfortable integrating into our system?", which has a much larger impact on system safety.

I agree with a sibling that there's an argument for using a wired controller. But that's pretty much as far as that criticism goes for me, speaking as someone who writes firmware that does need to be reliably low-latency and responsive, game controllers barely even register on my radar, except that I wouldn't do it myself if I didn't have a specific use case for it.
by andrepd | 2025-08-06 17:55:39+00:00
It is the best strategy for someone who does not do this full-time (and for many people who do!). That is the point.

A trader with experience, working in a firm with deep pockets and terabytes of historical data and FPGAs that can execute his/her strategy and a legal team and an engineering team... can outperform you yes x)
by shadowgovt | 2025-08-06 17:55:46+00:00
This author's approach would probably work "fine" (1) for something like npm, where individual dependencies also have a subtree of their dependencies (and, by extension, "any situation where dependencies are statically linked").

It doesn't work at all for something like Python. In Python, libpupa 1.2.3 depends on liblupa 0.7.8. But libsupa 4.5.6 depends on liblupa 0.7.9. Since the Python environment can only have one version of each module at a time, I need to decide on a universe in which libpupa and libsupa can both have their dependencies satisfied simultaneously. Version ranges give me multiple possible universes, and then for reproducibility (2) I use a lockfile to define one.

(1) npm's dependencies-of-dependencies design introduces its own risks and sharp edges. liblupa has a LupaStuff object in it. It changed very subtly between v0.7.8 and v0.7.9, so subtly that the author didn't think to bump the minor version. And that's okay, because both libpupa and libsupa should be wrapping their dependent objects in an opaque interface anyway; they shouldn't be just barfing liblupa-generated objects directly-accessible into their client code. Oh, you think people actually encapsulate like that? You're hilarious. So eventually, a LupaStuff generated by libpupa is going to get passed to libsupa, which is actually expecting a subtly different object. Will it work? Hahah, who knows! Python actually avoids this failure mode by forcing one coherent environment; since 'pupa and 'supa have to be depending on the same 'lupa (without very fancy module shenanigans), you can have some expectation that their LupaStuff objects will be compatible.

(2) I think the author is hitting on something real though, which is that semantic versioning is a convention, not a guarantee; nobody really knows if your code working with 0.7.8 implies it will work with 0.7.9. It should. Will it? "Cut yourself and find out." In an ideal world, every dependency-of-a-dependency pairing has been hand-tested by someone before it gets to you; in practice, individual software authors are responsible for one web of dependencies, and the Lockfile is a candle in the darkness: "Well, it worked on my machine in this configuration."