Hacker News: DblPlusUngood

New comment by DblPlusUngood in "Racket v8.3"

DblPlusUngood — Sat, 06 Nov 2021 23:17:42 +0000

Yes.

New comment by DblPlusUngood in "Intel and AMD Contemplate Different Replacements for x86 Interrupt Handling"

DblPlusUngood — Fri, 04 Jun 2021 21:08:59 +0000

In some cases, yes (if there are other runnable threads on this CPU's queue).

New comment by DblPlusUngood in "Intel and AMD Contemplate Different Replacements for x86 Interrupt Handling"

DblPlusUngood — Fri, 04 Jun 2021 19:02:01 +0000

A better example: a page fault for a non-present page.

New comment by DblPlusUngood in "BZFlag"

DblPlusUngood — Thu, 31 Oct 2019 23:05:10 +0000

Don't forget gltron!

New comment by DblPlusUngood in "Four Years of Rust"

DblPlusUngood — Wed, 15 May 2019 20:55:43 +0000

You are absolutely right. They are used everywhere in the Linux, OpenBSD, and FreeBSD kernels, and likely many other kernels.

Replacing large linked lists with arrays is rarely an actual win. With an array, insertion and deletion become far more expensive, virtual memory is more likely to become fragmented or grow monotonically, and the cache misses avoided are almost certainly irrelevant to total performance.

New comment by DblPlusUngood in "OpenBSD 6.5"

DblPlusUngood — Thu, 25 Apr 2019 16:44:05 +0000

> I don't see how it could. Kernel data structures don't go on pagecache pages.

Kernel data structures could end up on a pagecache page: all it takes is a reference counting bug and the page could be reallocated in the kernel heap, which is directly mapped by user space. Keeping user-mapped pages and pagecache pages distinct makes this less likely.

I am otherwise not convinced that there is an actual problem with OpenBSD's coherency plan.

New comment by DblPlusUngood in "OpenBSD 6.5"

DblPlusUngood — Thu, 25 Apr 2019 12:05:50 +0000

OpenBSD's choice is arguably reasonable, given their prioritization of security, since it reduces opportunities for user programs to corrupt kernel memory.

What is the problem with OpenBSD's plan for coherency? Why is the burden of explicitly calling msync(2) too much?

New comment by DblPlusUngood in "OpenBSD 6.5"

DblPlusUngood — Wed, 24 Apr 2019 16:30:39 +0000

What coherence is lacking? OpenBSD supports msync(2), which is the only POSIX mechanism I know of for ensuring coherency between read(2) and shared file mappings. Otherwise relying on unspecified behavior sounds dangerous.

New comment by DblPlusUngood in "Matrix.org hacked"

DblPlusUngood — Fri, 12 Apr 2019 10:15:52 +0000

OpenSSH does have confirmation: use the '-c' switch to ssh-add.

https://man.openbsd.org/ssh-add

New comment by DblPlusUngood in "A fork() in the road"

DblPlusUngood — Wed, 10 Apr 2019 11:44:01 +0000

Is recovery of a shared memory queue after one of the workers crashes even possible, in general? (what if the worker crashed before releasing a lock?)

New comment by DblPlusUngood in "Fuchsia OS Introduction"

DblPlusUngood — Tue, 26 Mar 2019 10:28:42 +0000

Sounds like a fun project!

Isn't seL4's multicore support either unverified or limited (i.e. shared memory is forbidden)? Is your platform single-threaded then?

New comment by DblPlusUngood in "A generalised solution to distributed consensus"

DblPlusUngood — Sat, 09 Mar 2019 19:03:03 +0000

Yes. In theory, maybe it's useful to have more flexibility to trade-off durability for performance (smaller quorum size hopefully reduces deciding latency [unless your small quorum contains the straggler!]) for specific kinds of data in the same replica group.

In practice though, it seems easier just to run separate instances of Paxos.

New comment by DblPlusUngood in "Go 1.12 Release Candidate 1 is released"

DblPlusUngood — Tue, 12 Feb 2019 13:55:27 +0000

Instead of an ad hominem, please clearly explain the main way that the example Go code is less safe than the C example code.

New comment by DblPlusUngood in "Ask HN: How do you get over the initial fear of learning something hard or new?"

DblPlusUngood — Fri, 08 Feb 2019 15:51:57 +0000

This is a great point. Jargon can be really intimidating and make the simplest statements impossible to understand for the unfamiliar. But is often trivial to learn with a little study.

New comment by DblPlusUngood in "Makefiles – Best Practices"

DblPlusUngood — Fri, 01 Feb 2019 16:50:16 +0000

A particularly tricky task with GNU make is automatically adding target dependencies on header files and handling updates to them (gcc's -M and -MMD switches). It would be great if the article explained those best practices, too.

New comment by DblPlusUngood in "Using D to Create the World’s Fastest File System"

DblPlusUngood — Wed, 05 Dec 2018 21:40:12 +0000

How are GCs not compatible with bounded memory use? Though many GCs size allocation arenas proportionally to the live data, there is no fundamental reason why the allocation arenas couldn't be fixed-size (of course, they must be large enough for good performance, etc.).

New comment by DblPlusUngood in "Using Zig to Provide Stack Traces on Kernel Panic for a Bare Bones OS"

DblPlusUngood — Wed, 05 Dec 2018 13:07:10 +0000

Well, for one thing, zig apparently has no built-in memory allocator?

New comment by DblPlusUngood in "Systemd is bad parsing"

DblPlusUngood — Sat, 27 Oct 2018 16:33:05 +0000

Turns out the x86 already has some bounds checking support; see chapter 17 in volume 1 of Intel's developer manuals and the BOUND and BND* instructions.

New comment by DblPlusUngood in "OpenBSD 6.4 released"

DblPlusUngood — Thu, 18 Oct 2018 21:50:27 +0000

> I love the BSDs and especially OpenBSD for their attention to manpages. It's the main reason why I don't use Linux anymore unless I have to.

I completely agree. The difference in the quality of manpages between OpenBSD and Linux alone is enough for me to prefer OpenBSD.

New comment by DblPlusUngood in "The benefits and costs of writing a POSIX kernel in a high-level language"

DblPlusUngood — Tue, 09 Oct 2018 07:03:00 +0000

1. I wouldn't say we are skeptical of Rust, I'm sure it could be made to work well and we would love to see such a Rust kernel! I do wonder whether it would be harder to implement highly-concurrent data structures in Rust though, such as the directory cache.

2. GC performance would be basically unaffected by paging, since kernels don't page their own heaps out to disk and thus a kernel heap access would never have to wait for a disk IO. Or maybe you had something else in mind?