MurphyA/hacker-news huggingface dataset:
by jeroenhd | 2025-12-10 12:13:50+00:00
On Android, macOS/iOS, and Windows, this is a solved problem. Only on the extremely fragmented Linux/Posix runtimes do these problems surface.

Rust's solution is "it depends". You can use OpenSSL (system or statically compiled) or rustls (statically compiled with your own CA roots, system CA roots, or WebPKI CA roots).

I'm afraid that until the *ix operating systems come out with a new POSIX-like definition that stabilises a TLS API, regardless of whether that's the OpenSSL API, the WolfSSL API, or GnuTLS, we'll have to keep hacking around in APIs that need to be compatible with arbitrary TLS configurations. Alternatively, running applications through Waydroid/Wine will work just fine if Linux runtimes can't get their shit together.
by sqbic | 2025-12-10 12:15:06+00:00
What changed my mind to be in favor of TLS inspection at work environments was seeing what kind of highly confidential stuff employees might be copy-pasting to random websites, LLM assistants, cloud-based "desktop applications" and such against the approved use policies of each of these tools without giving it a second thought.

TLS inspection products can intercept the paste transaction before the data leaves the company network, hitting the user with a "No you didn't! Shame on you!"-banner and notify the admins how a user just tried to paste hundreds of customers' personal information and credit card details into some snooping website, or into otherwise allowed LLM chat which still is not allowed to be used with confidential information.

There can even be automations to lock the user/device out immediately if something like this is going on, be it the user or some undetected malware in the user's device attempting the intercepted action. Being able to do these kinds of very specifically targeted interceptions can prevent potentially huge disasters from happening while still allowing users more freedom in taking advantage of the huge variety of productivity tools available these days. No need to choose between completely blocking all previously unseen tools or living in fear of disastrous leaks when there are fine-grained possibilities to control what kind of information can be fed to the tools and from where.

There are plenty of organizations out there where it is completely justified to enforce such limitations and monitoring in company devices. Policies can forbid personal use entirely where it is deemed necessary and legal to do so. Of course the policies and the associated enforced monitoring needs to be clearly communicated and there needs to be carefully curated configurations to control where and how TLS is or isn't intercepted so employee privacy laws and regulations aren't breached either.
by Nextgrid | 2025-12-10 12:15:16+00:00
You and I both know the answers to those questions; my point is that the average non-technical user does not and this presents significant extra friction that Instagram doesn't have.

(this kind of attitude of asserting technical superiority and blaming non-tech users for not understanding it and not willing to bother figuring it out is exactly why the free/libre software movement achieved zero impact with non-technical users; you have to meet your users where they are... or a competitor will happily do so.)

If you're not being contrarian for the sake of being contrarian, you are welcome to search my username and "mastodon"/"fediverse" to see my thoughts on it in more detail and why it will never be a serious competitor to mainstream social media platforms. Happy to engage with serious arguments.
by exasperaited | 2025-12-10 12:15:20+00:00
Yeah — quite a lot of "let's get the gang back together to fight the old enemy which is reorganising with the new enemy" films borrow quite heavily from it, I think. Especially because there's almost always a newbie who has heard all the stories (some of them untrue, some of them edited) — someone's recently disclosed lovechild, some kid who was kept safe in prison by one of their dead friends, etc.
by notarobot123 | 2025-12-10 12:15:54+00:00
Political freedom is usually prized by "brainy immigrants" - especially those who were likely to travel to the USA.

The problem isn't just the $100,000 fee (not insignificant) but the risks associated with being an immigrant with restricted political freedom in an increasingly authoritarian nation[1].

[1] - https://www.reuters.com/world/us/trump-administration-orders...
by segfault0x23 | 2025-12-10 12:15:57+00:00
I'm the original developer and maintainer of power-options (a GUI for managing settings related to power saving and performance on linux laptops and desktops). One of the issues I had when releasing it was the absurd difficulty of handling all package managers and all the different quirks in god knows how many different linux distros. For the most part of the program I simply built a GitHub actions workflow that used python scripts to generate PKGBUILDS and commit them with git to the AUR. Since the AUR didn't require any other manual processes it was the only one I could easily automate. The remaining users used shell scripts,

I also tried Open Build Service from OpenSuse and it was so hard to implement with so few documentation that I basically gave up halfway.

Then I decided to build distropack. Now you basically create a package, press enable on all distros, indicate which files your package has and use the specialized GitHub action to simply upload the binaries you already built in the CI and it will build for all major package manager formats.

Instead of god knows how many instructions in the readme I now just show my users this link: https://distropack.dev/Install/Project/TheAlexDev23/power-op...

it's that easy. I just wanted to share this with fellow open source maintainers. afaik it's basically OBS but way easier. one quirk though, just like in OBS your users will have a separate repository for your project only so use carefully I guess.
by estearum | 2025-12-10 12:17:28+00:00
Again: you haven't actually provided any evidence of what the 2016/2024 strategy was, why 2020 was different, etc.

You're doing the far lazier, "ascribe all failures to the thing I do not like, and all successes to the thing I do like." Evidence should be trivial to produce but you cannot.

And yes, a major faction electing a demagogue is a real spot of trouble. It has been known as such literally since the invention of democracy.

It wouldn't be considered a known vulnerability because it's solved by "well just talk about a pragmatic, positive vision for the future!" lmao
by ojr | 2025-12-10 12:17:42+00:00
> So in essence some concepts strictly exist to protect against malicious actors, while others protect against random conditions or good faith actors.

Guess what both fall under umbrella of cybersecurity. Please consult with your favorite LLM to break it down to you.

I can't continue having a conversation with a beginner posturing as a security veteran, who thinks rate limiting and having atomic operations in things that involve money is not cybersecurity.

blockchain smart contracts I wrote 8 years ago: https://github.com/Slidebits/ethereum-smart-contracts

iOS app, that "good faith" hackers try to constantly abuse through what you call "random conditions": https://apps.apple.com/us/app/slidebits-ai-playground/id1138...

Maybe you can share some of things that form your opinion?
by SideburnsOfDoom | 2025-12-10 12:17:59+00:00
> I hope this doesn't begin a string of hype-creep that causes their actual goal to fail.

IDK, the first sign to me that Boom weren't likely to succeed was when Rolls Royce parted ways on engine development (1). Were the engines not technically feasible? Not economically feasible? Didn't believe in Boom's business model? We don't know Rolls Royce's thinking, but it's a vote of no confidence.

Taking it in house seemed like a last resort - designing "a new engine in a new airframe" is a known risk. A homebrew engine can't be benefit.

They don't even have the engine: Re-purposing the hypothetical jet engines as hypothetical LLM power plants seems like a nosedive, really.

https://www.space.com/boom-supersonic-rolls-royce-engine-spl...
by DiogenesKynikos | 2025-12-10 12:18:16+00:00
Thanks for the interesting article.

Even though most of the casualties were caused by musket and artillery fire, the bayonet was tactically very important in Napoleonic warfare. A bayonet charge is absolutely terrifying, and the reason why there were relatively few casualties from them is likely because soldiers would break rank and flee in the face of one. If soldiers had stood their ground and fought, casualties would have been much higher, and with their low rate of fire, muskets would have been of little use in hand-to-hand combat.

They key change that happened in the mid-1800s is that firearms finally achieved ranges and rates of fire that made closing with a massed enemy nearly impossible.
by josephg | 2025-12-10 12:18:26+00:00
Yeah they’re all just tools. From a technical perspective, rust, C and C++ work together pretty well. Swift too. LLVM LTO can even do cross language inlining.

I don’t think C++ is going anywhere any time soon. Not with it powering all the large game engines, llvm, 30 million lines of google chrome and so on. It’s an absolute workhorse.
by slippyvex | 2025-12-10 12:19:21+00:00
Author here. The YM2149/AY-3-8910 was the sound chip in the Atari ST, ZX Spectrum 128, Amstrad CPC, and MSX. I spent the past year building a complete Rust ecosystem for it.

The interesting technical bits:

- Cycle-accurate emulation at clk/8 (~250kHz). This matters because demoscene musicians abused timing-dependent tricks like "SID voice" (rapid volume register toggling for pulse waves) and "Sync Buzzer" (envelope restarts synchronized to tone periods).

- SNDH files contain native 68000 machine code ripped from Atari ST demos. Playing them required emulating not just the sound chip, but the CPU and MFP timer chip too.

- AY files have Z80 code from ZX Spectrum games. Another CPU emulator, another memory map.

- The WASM build is ~150KB and includes both CPU emulators.

- Bevy plugin with playlists, crossfading, and per-channel muting for game devs who want authentic retro audio.

Blog post with implementation details: https://medium.com/@mvelten773/ym2149-in-rust-part-1-buildin...

Browser demo (select from examples or load your own): https://ym2149-rs.org/demo/

Happy to answer questions about emulation accuracy, the demoscene formats, or Rust/WASM audio.
by liripe | 2025-12-10 12:19:24+00:00
OP here. I spent the last 2 years building a risk management framework to fix the fragility of Naive Kelly betting.

The core issue is that standard Kelly assumes p_hat = p_star (perfect estimation). But due to Cramér-Rao bounds, there's always irreducible epistemic uncertainty. My solution uses Wasserstein-2 ambiguity balls to define a radius of uncertainty around the prediction, and then solves a convex dual problem to find the allocation that maximizes log-growth for the worst-case distribution inside that ball.

The Stack: - Python 3.9+ - Optimization: Exact Convex Formulation using `cvxpy` + `SCS` splitting conic solver. - Stochastic Model: Dynamic Bivariate Poisson (captures covariance μ between teams). - Validation: Walk-Forward with strict temporal purging.

I released the stable version (v1.0) as a commercial Asset Kit for deployment. The repository linked above serves as the *public documentation*, detailing the mathematical proofs and the architectural overview for those who want to study the logic.

Let me know if you have questions on why I chose SCS over ECOS for this specific problem.
by justinclift | 2025-12-10 12:19:31+00:00
Interesting. It sounds like using local LLMs (via vllm, ollama, etc) with decent agentic capability might be starting to become a reality.

Next step, just need a shitload of vram. ;)

Maybe those Intel Battlematrix 48GB cards might be useful after all... :)

https://www.storagereview.com/review/intel-arc-pro-b60-battl...
by locknitpicker | 2025-12-10 12:19:43+00:00
> This reads like a document that's meant to convince AWS management to invest in the new chip, focusing on how it's maximally flexible for sale, not a document to convince customers to use it ...

AWS management is the customer.

Higher compute density, lower infrastructure costs, and higher performance. Those are data center selling points.

The truth of the matter is that your average external customer doesn't really care about CPU architectures if all they are doing is using serverless offerings, specially AWS Lambdas handling events. They care about what it costs them to run the services. AWS management decide if the returns on their investment is paying off and helps them lower costs and improve margins.
by zozbot234 | 2025-12-10 12:20:38+00:00
> technically Rust is still safer than C in its unsafe blocks

This is quite dubious in a practical sense, since Rust unsafe blocks must manually uphold the safety invariants that idiomatic Safe Rust relies on at all times, which includes, e.g. references pointing to valid and properly aligned data, as well as requirements on mutable references comparable to what the `restrict` qualifier (which is rarely used) involves in C. In practice, this is hard to do consistently, and may trigger unexpected UB.

Some of these safety invariants can be relaxed in simple ways (e.g. &Cell<T> being aliasable where &mut T isn't) but this isn't always idiomatic or free of boilerplate in Safe Rust.
by iamcalledrob | 2025-12-10 12:21:04+00:00
This kind of TLS "man in the middle" tech is so frustrating to deal with, because it ends up breaking things.

For example, I've encountered zscaler setups in the wild which close TLS connections if non-HTTP traffic is encountered. Presumably the traffic inspection fails since there is no HTTP request, and this failure path closes the socket.

It's hard to say whether it's due to the customer's IT dept's config, or zscaler itself -- but as far as the customer is concerned, it's my problem.
Ask HNIs early-stage fundraising broken,or founders just pitching the wrong way?
by paulwilsonn | 2025-12-10 12:21:06+00:00
Talking to founders lately feels surreal - some with barely an MVP are raising fast, while others with actual revenue get ignored. The inconsistency is huge.

It makes me wonder: Is the fundraising system actually broken right now, or are founders misreading how VCs evaluate deals in 2025?

Some observations I keep hearing: • “Warm intros” matter more than traction • VCs want optionality, not conviction • Storytelling beats metrics until Series A • AI hype is crowding out everything else • Half the “no’s” have nothing to do with the startup

So I’m curious: For anyone raising, investing, or recently closed, what’s actually happening behind the scenes? Are founders blaming the system, or is the system just evolving faster than founders expect?

Genuinely interested in unfiltered perspectives.
by xmcqdpt2 | 2025-12-10 12:21:09+00:00
The complexity of actual biological neural networks became clear to me when I learned about the different types of neurons.

https://en.wikipedia.org/wiki/Neural_oscillation

There are clock neurons, ADC neurons that transform analog intensity of signal into counts of digital spikes, there are neurons that integrate signals over time, that synchronizes together etc etc. Transformer models have none of this.
by embedding-shape | 2025-12-10 12:21:34+00:00
> both NixOS and Arch enable the QR code kernel panic screen

Interesting, I use both (NixOS on servers, Arch for desktop) and never seen that. Seems you're referring to this: https://rust-for-linux.com/drm-panic-qr-code-generator (which looks like this: https://github.com/kdj0c/panic_report/issues/1)

Too bad NixOS and Arch is so stable I can't remember the last time any full system straight up panicked.
by _fe | 2025-12-10 12:21:52+00:00
In-general it seems that Rust proponents want ease and modernity to replace the ability to do the same in C better, with more control and intent, and with better results.

Rust is less tight. That’s fine for an application, but the kernel is used by everyone who uses Linux.

Rustians disparage C because it doesn’t have Rust behavior.

Why must the kernel have Rust behavior?
by throwaway290 | 2025-12-10 12:22:16+00:00
> 1960s and 1970s are the end to you

USSR ended around 1989-90

> I actually am.

Citation needed

> By pure chance, I do have such contacts, they laugh at this decolonization crap.

What is "decolonization"? Tell us more.

Also I said discrimination against non white Russians. Actually I literally talked about this with Russian citizen who doesn't look fully Russian the other week, she was called черножопая a couple years ago interviewing for a job and for that reason didn't get it (this is not america so good luck complaining about it). So go ask your fellow yakuts, great you know multiple so you have a sample size more than 1, about racial unfairness they encountered living in the west of Russia? and come back here to tell us.

> Also by chance, I knew Russians who lived in Yakutia in 1990s, and they did tell me stories of discrimination from the locals.

I guess you should learn what Russians did there way before 1990s.

Keep pushing your agenda I am amused)
by locknitpicker | 2025-12-10 12:24:55+00:00
> So a project that's still using Java 1.6 and has perfect test coverage and some poor developer is paid to maintain it (but NOT upgrade it!) is not "legacy" in your book?

If a project is perfectly maintainable and developer teams are confident they can roll out any change they see fit with total confidence without having to risk nasty regressions or work around any pain points, then obviously it is not a legacy project as per definition.

If instead you have services running on Java25 that you can't touch a code path without breaking it or knowing it broke, that is a legacy project.

It is not about the age of a framework. It's about the ability to maintain it. Legacy is synonym with being unmaintained and unmaintainable. Not age.
by jll29 | 2025-12-10 12:24:58+00:00
AI professor here. I know this page is a joke, but in the interest of accuracy, a terminological comment: we don't call it a "hallucination" if a model complies exactly with what a prompt asked for and produces a prediction, exactly as requested.

Rater, "hallucinations" are spurious replacements of factual knowledge with fictional material caused by the use of statistical process (the pseudo random number generator used with the "temperature" parameter of neural transformers): token prediction without meaning representation.

[typo fixed]
by implabinash | 2025-12-10 12:25:00+00:00
Hi everyone,

I am Abinash. I am a developer from India and recently started streaming on Twitch (https://www.twitch.tv/implabinash), Kick (https://kick.com/implabinash) and YouTube (https://www.youtube.com/@implabinash). I share my daily work and things I am exploring.

As a non-native English speaker and a first-time camera moment, I got so nervous on my first couple of streams.

Luckily, I got a helpful chatter on my first day of streaming, and we talked for half an hour, which boosted my confidence to show up the next day.

But, unfortunately, I never got that viewer back or another person to chat with; still, I regularly try to show up and stream at least 2 hours every single day.

For the first week, I learned a lot. Things like:

- Greet every single one who joins your chat. - Always ask open-ended questions to keep your chat engaging. - Ask for help from viewers because people love to help others.

These are a few things I learned this week and am actively experimenting and learning new things to make my stream more engaging and value-packed.

Twitch Numbers: - 1 follower - 0.7 avg viewer - 18+ hour stream - 39 unique views - 7 unique chatters

Kick Numbers: - 6 Followers - 0 Subs - 18+ hours stream - 1.04 avg viewers - 15 unique chatters

YouTube Numbers: - 1 subscriber - 130 views - 1 hour watch time

I know these are not so impressive numbers, but I am very happy with the results because I am starting to enjoy streaming. (Yesterday, I had only 1 view throughout the stream,i.e. me opening the tab to check stream stats, still I streamed for 1.41 hours.)

I know it is going to be tough because streaming is tough, and the niche I am in has lesser audience.

I am not trying to fast-forward; rather, I am trying to remove my camera fear, improve my speaking skills, while learning new tech skills. And if I made some money on the go, is a plus for me.

So, if you are an experienced streamer, please drop some helpful insights I must know.

Thank you.
by pansa2 | 2025-12-10 12:25:22+00:00
> Jack Crenshaw's tutorial takes the syntax-directed translation approach, where code is emitted while parsing, without having to divide the compiler into explicit phases with IRs.

Is "syntax-directed translation" just another term for a single-pass compiler, e.g. as used by Lua (albeit to generate bytecode instead of assembly / machine code)? Or is it something more specific?

> in the latter parts of the tutorial it starts showing its limitations. Especially once we get to types [...] it's easy to generate working code; it's just not easy to generate optimal code

So, using a single-pass compiler for a statically-typed language makes it difficult to apply type-based optimizations. (Of course, Lua sidesteps this problem because the language is dynamically typed.)

Are there any other downsides? Does single-pass compilation also restrict the level of type checking that can be performed?
by muvlon | 2025-12-10 12:25:35+00:00
In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html, cleaned them up so they can be compared like for like and then put them into this python script:

linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips", "mips64", "nios2", "openrisc", "parisc", "powerpc", "powerpc64", "riscv", "s390", "s390x", "sh", "sparc", "sparc64", "x86", "x86_64", "xtensa" } rust = { "arm", "aarch64", "amdcgn", "avr", "bpfeb", "bpfel", "csky", "hexagon", "x86", "x86_64", "loongarch", "m68k", "mips", "mips64", "msp430", "nvptx", "powerpc", "powerpc64", "riscv", "s390x", "sparc", "sparc64", "wasm32", "wasm64", "xtensa" } print(f"Both: {linux.intersection(rust)}") print(f"Linux, but not Rust: {linux.difference(rust)}") print(f"Rust, but not Linux: {rust.difference(linux)}")

Which yields:

Both: {'aarch64', 'xtensa', 'sparc', 'm68k', 'mips64', 'sparc64', 'csky', 'riscv', 'powerpc64', 's390x', 'x86', 'powerpc', 'loongarch', 'mips', 'hexagon', 'arm', 'x86_64'}

Linux, but not Rust: {'nios2', 'microblaze', 'arc', 'openrisc', 'parisc', 's390', 'alpha', 'sh'}

Rust, but not Linux: {'avr', 'bpfel', 'amdcgn', 'wasm32', 'msp430', 'bpfeb', 'nvptx', 'wasm64'}

Personally, I've never used a computer from the "Linux, but not Rust" list, although I have gotten close to a DEC Alpha that was on display somewhere, and I know somebody who had a Sega Dreamcast (`sh`) at some point.
by poulpy123 | 2025-12-10 12:25:42+00:00
> You can see this in retirement, actually. There's real data showing mortality spikes in the years after people stop working. The structure of striving, even when it felt like a burden, was providing something that leisure alone can't replace.

Sorry but that's hilariously wrong. If it was true life expectancy would have decreased with the lowering of age of retirement, but we saw the reverse over the last century.

Mortality spikes after retirement because we are reaching our end of life after retirement,

As for the main thesis, I actually changed my mind over the years. While I wanted (and sometimes felt !) to be immortal when I was young, now that I'm old, sick and tired and that a lot of family and some friends are already dead, I'm much less eager to live eternally.