frontpage.
newsnewestaskshowjobs

Open Source @Github

fp.

OpenAI's claimed disproof of Connes' Rigidity Conjecture is invalid [pdf]

https://philarchive.org/archive/NIEWTCv17
26•muglug•1h ago•5 comments

Go 1.27 Interactive Tour

https://victoriametrics.com/blog/go-1-27/index.html
95•Hixon10•3h ago•25 comments

MkLinux and the pimped-out Apple Workgroup Server 9150

http://oldvcr.blogspot.com/2026/08/mklinux-and-pimped-out-apple-workgroup.html
22•goldenskye•1h ago•1 comments

Seedance 2.5

https://seed.bytedance.com/en/blog/one-take-creation-flexible-referencing-introducing-seedance-2-5
231•njaremko•8h ago•116 comments

Plug-in solar is coming. Plug-in batteries should follow

https://www.regen.co.uk/insights/plug-in-solar-is-coming-plug-in-batteries-should-follow
67•thelastgallon•1h ago•53 comments

Diátaxis

https://diataxis.fr/
252•ryanseys•8h ago•34 comments

ASRock BC-250: Building the Budget Steam Machine

https://plug-world.com/posts/2026/asrock-bc250-the-budget-steam-machine/
34•plug_world•3h ago•11 comments

Show HN: I'm a 15 Year Old Wannabe Engineer, This Is a Cycloidal Gearbox I Built

https://github.com/tom-ilan/cycloidal_gearbox
54•tomilan•2h ago•15 comments

Deep-sea vehicles spot 'alien' sharks deep beneath the waves in the Pacific

https://www.science.org/content/article/deep-sea-vehicles-spot-alien-sharks-deep-beneath-waves-pa...
18•pkaeding•1h ago•6 comments

RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2

https://www.rfc-editor.org/rfc/rfc10015.html
45•Jimmc414•5h ago•6 comments

Unraveling the mysteries of habit formation

https://www.kyoto-u.ac.jp/en/research-news/2026-07-28
55•hhs•5h ago•20 comments

AI financial advice is surprisingly good, especially if you ask right questions

https://mitsloan.mit.edu/ideas-made-to-matter/ai-financial-advice-surprisingly-good-especially-if...
227•foxtrot8672•6h ago•205 comments

Postmortem for Kernel Soundness Bug #14576

https://leodemoura.github.io/blog/2026-8-1-postmortem-for-kernel-soundness-bug-14576/
133•juhopitk•10h ago•45 comments

The Cipher Behind QSYRUPWD: Reconstructing IBM i Password Hashes

https://blog.silentsignal.eu/2026/07/28/the-cipher-behind-qsyrupwd-reconstructing-ibm-i-password-...
4•kencausey•4d ago•1 comments

When random.bytes() runs but doesn't work

https://insider.btcpp.dev/p/when-randombytes-runs-but-doesnt
12•Funes-•2h ago•1 comments

But can your calculator run Linux?

https://raymii.org/s/articles/But_can_your_calculator_run_Linux.html
79•jandeboevrie•9h ago•6 comments

Morph (YC S23) Is Hiring Member of Technical Staff

https://www.ycombinator.com/companies/morph/jobs/0Z8vI3K-member-of-technical-staff
1•bhaktatejas922•5h ago

Linux desktop market share has hit over 10% in North America

https://old.reddit.com/r/linux/comments/1vcpk8i/linux_desktop_market_share_has_hit_over_10_in/
24•dviola•1h ago•7 comments

Show HN: CostPerPrompt – Live AI API pricing and real-workload cost calculators

https://costperprompt.com/
9•ahmed_hassan7•2h ago•3 comments

The Art of 64-bit Assembly

https://nostarch.com/art-64-bit-assembly-v2
212•0x54MUR41•14h ago•95 comments

Four Time Scales for Technology Development and Deployment

https://rodneybrooks.com/four-time-scales-for-technology-development-and-deployment/
16•jeffreyrogers•2h ago•2 comments

China begins producing advanced chipmaking deep-ultraviolet lithography machines

https://www.reuters.com/world/china/china-starts-production-home-grown-immersion-duv-chipmaking-t...
63•ck2•2d ago•44 comments

How Google helped destroy adoption of RSS feeds (2023)

https://openrss.org/blog/how-google-helped-destroy-adoption-of-rss-feeds
459•pudgywalsh•10h ago•160 comments

We accidentally built an LLVM compiler for Jax

https://iza.ac/posts/2026/07/accidental-llvm-compiler-for-jax/
25•infinitewalk•2d ago•8 comments

Nyctography: A substituton cypher by Lewis Carroll

https://en.wikipedia.org/wiki/Nyctography
62•nanna•4d ago•9 comments

Atom is better than RSS, in ways that matter

https://chrismorgan.info/atom%3Erss
30•frizlab•6h ago•4 comments

Kenji/Serious Eats – 30-Min Pressure Cooker Pho Ga

https://www.seriouseats.com/30-minute-pressure-cooker-pho-ga-recipe
122•stasomatic•13h ago•66 comments

CISA Alert: Water Sector PLC Targeting

https://censys.com/blog/cisa-alert-water-tower-plc-targeting/
86•speckx•10h ago•60 comments

NetBSD 11.0

https://blog.netbsd.org/tnf/entry/netbsd_11_0_released
240•jaypatelani•10h ago•110 comments

Explorative modeling: Train on the best of K guesses

https://alexiglad.github.io/blog/2026/explorative_modeling/
88•DSemba•13h ago•24 comments
Open in hackernews

How ZGC allocates memory for the Java heap

https://joelsiks.com/posts/zgc-heap-memory-allocation/
86•lichtenberger•1y ago

Comments

gopalv•1y ago
The 32x virtual memory to physical memory ratio plays into relocation and colored pointers (i.e pointers where some bits serve as flag bits).

Putting the actual data layouts in 44 bits out of 64 is a neat trick which relies on the allocator being aware of the mappings between physical and virtual addresses.

twoodfin•1y ago
When your comment and the article refer to “physical” addresses, those are physical in the context of the JVM, right? To the OS they’re virtual addresses in the JVM process space?
acchow•1y ago
Correct. ZGC has no way to escape from the virtualization by the kernel (assuming your hardware and kernel uses an MMU)
MBCook•1y ago
Thank you for the answer, I was wondering that as well.
hinkley•1y ago
In the beginning of the 32 bit revolution, when the future was here but unevenly distributed, there was a lot of talk about how 32 bit pointers would fundamentally change how people wrote code. Among other things it got rid of a bunch of odd bookkeeping, and if you don’t have to do the bookkeeping you don’t have to write the code in a way that supports it, so you can do other things.

Not too long after someone asked what sort of interesting changes 64 bit will bring. And I’ve been keeping that question in the back of my mind ever since.

Aliasing memory multiple times in order to do read or write barriers and make GC much cheaper is a pretty good one. But another one I know of is that one of the secrets of the L4 microkernel is that its IPC speed comes substantially from reducing the amount of TLB work that needs to be done to switch to another process running in a different address space. They use the same address space and only swap out the access rights which cuts the call overhead in half. It’s pretty easy to put a bunch of processes into a 64 bit address space and just throw each one a randomly located 4GB slice of RAM.

twoodfin•1y ago
Yeah, would love to see the CPU vendors invent some primitives to let user code pull those kinds of privilege isolation tricks within a single process and address space.

Something like: “From now on, code on these pages can only access data on these pages, and only return to/call into other code through these gates…”

hinkley•1y ago
Thread based seems like it at least should be possible.
ahartmetz•1y ago
I've had some ideas about avoiding format validation in IPC receivers if the data is encoded by trusted code, which is also the only code that has rights to send the IPC data / to connect to the receiver. I can't really think of an important problem that it would solve, though. DBus always validates received data, but it's not really meant or very suitable for large amounts of data anyway.
pron•1y ago
For relevant upcoming changes see Automatic Heap Sizing for ZGC: https://openjdk.org/jeps/8329758
twoodfin•1y ago
What I’m looking for is a way for a process to de/re-escalate its privileges to access memory, without an expensive context switch being required at the transition. The CPU would simply enforce different rules based on (say) the high-order bits of the instruction pointer.

Imagine a server process that wants to run some elaborate third-party content parser. It’d be great to be sure that no matter how buggy or malicious that code, it can’t leak the TLS keys.

Today, high-security architectures must use process isolation to achieve this kind of architectural guarantee, but even finely tuned IPC like L4’s is an order of magnitude slower than a predictable jump.

gpderetta•1y ago
For a brief moment Intel supported MPX which did something similar.

You can also play tricks with the virtualization hardware, bit it need kernel support.

Eventually we will get segments back again.

MarkSweep•1y ago
That would be pretty cool. Something like the Win32 function GetWriteWatch, but implemented in hardware instead of the page fault handler (I assume).

https://learn.microsoft.com/en-us/windows/win32/api/memoryap...

Or some sort of special write barrier store op-code, idk.

mike_hearn•1y ago
It exists, that's called MPKs.
twoodfin•1y ago
I don’t think MPK’s will fit the need I have. Simply: Run some arbitrary, untrusted, non-sandboxed code in the same thread with assurance it can’t read page X. When that code completes and I’m back in code I trust, X is readable again.

Is that something MPK makes possible? The doc I’ve read suggests either your process can flip permission bits or it can’t. Great for avoiding out-of-sandbox reads. But if there’s arbitrary execution happening, why can’t that code flip the access to secrets back on?

mike_hearn•1y ago
Oracle Labs has tech that does that:

https://youtu.be/T05FI93MBI8?si=EieFgujaGiW2gbO8&t=958

The trick is to do a cascading disassembly of all untrusted code you'll execute to prove it can't change the MPK register.

twoodfin•1y ago
Wow. Neat trick and exactly the kind of thing I was looking for.

Thanks!

EDIT: Looks like this is the relevant paper from the Graal team: https://www.graalvm.org/resources/articles/binsweep.pdf

jdougan•1y ago
Is that something like the memory protection scheme on the Newton OS?
nyanpasu64•1y ago
Isn't not swapping page tables during a call precisely what the KPTI mitigations had to turn off for Meltdown mitigations?