Also, Nginx's maintainers are weird about standards. e.g., last time I checked, tabs in header field line whitespace were rejected by the Nginx parser, even though the RFC says to allow it. The maintainers at the time didn't care and wouldn't fix, reasoning that Nginx had been behaving this way for so long that anything sending tabs in header field lines would have stopped by now. I don't love that attitude.

Apache is way better in this regard. (Though I think Nginx may have cleaned up its act recently?)

I agree.

> This is mostly describing a kind of obsolete allocator

I disagree. glibc malloc is still extremely relevant and sees a lot of development, and uses exactly this strategy (unless an allocation request is too big, in which case it mmaps, just like the allocator described in the article).

[1] https://lore.kernel.org/all/20210518191303.4135296-5-hpa@zyt...

There are many. Two big ones are Alpha and PA-RISC. NetBSD and Linux continue to support both. Linux distro choices are pretty much limited to Gentoo though.

I was going to return it at the MIT swapfest in a week, but I think he can't make it anymore. Sorry Greg!

We're currently designing a new intro systems curriculum, and we're thinking of it as an adversarial problem. That is, we're designing the course to ensure that a student optimizing for the best grade per unit work still meets our learning objectives. That means, as everyone else is saying, paper exams, but also 1-on-1 interviews to check that students understand each assignment they turn in. These interviews feature both factual questions ("You're using this macro from that library. What does it do?", "Please describe what this function does and how it works.") and conceptual questions ("Why is this code structured this way instead of $whatever?", "How else did you try solving this?", etc.) This doesn't stop students from generating code, but at least they have to understand that code in detail.

This is not as good as writing the code yourself, but how much worse is it? For math classes, this gap is gigantic. Obviously, understanding someone else's proof is much easier than writing your own. For programming classes, I think (without evidence) that the gap is somewhat smaller.

My experience from the past is that when this kind of evaluation is made clear up front, the students know what to expect and either do fine or drop the class in the first week. If you start with take-home exams and then spring paper exams on them halfway through the course, then half the class is cheating and won't be able to recover, as we read in the article.

In general, our students are somewhat motivated by an abstract desire to learn, but are much more motivated by grades. If there exists a straightforward path through your course that leads to a good grade without doing much work, most students will take it. (Our undergrads' course review website is literally called "Layup List." They are actually this shameless.) It's our job as instructors to ensure that all paths leading to a good grade either require learning the material or are more difficult to pull off than just learning the material.

It's best not to blame the students. They are good at optimizing metrics; that's how they ended up here in the first place. We just need to better align the evaluation metrics with the outcomes that we're looking for.

Comments URL: https://news.ycombinator.com/item?id=48464595

Points: 2

# Comments: 0

Part of the reason for all the UB in OpenBSD is that UBSan doesn't run on that platform. When I ported OpenBSD's httpd to Linux, I found that UBSan tripped before the server even came up because the config flag parsing shifts into the MSB of a signed integer.

I tried to contribute back a patch (just make the flag bitfield unsigned), but it was ignored. I think if UBSan ran natively on OpenBSD, then there would be a lot more of these patches, and the maintainers would have to take an official stance on whether they think these bugs matter.

Comments URL: https://news.ycombinator.com/item?id=47479898

Points: 3

# Comments: 0

It's a custom assembler built on top of the LLVM assembler (llvm-mc) that emits instrumentation code to catch ABI violations at runtime. Stuff like clobbering nonvolatile registers, misaligning the stack pointer, misusing the redzone, assuming volatile registers don't change across a function call, etc.

Hoping to finish up basic x86_64 support within the next few days. I can now reliably assemble and run unoptimized gcc output without hitting false positives, but I still have to iron out some false positives triggered by OpenSSL's handwritten assembly routines.

TODO items for the near future include porting the runtime support library into a kernel module so I can instrument Linux, and beginning ports other architectures (ideally something semi-obscure like POWER or RISC-V). I also need to figure out how to support dynamic linking, because the tool currently needs static linking to access its thread-local variables.

https://github.com/kenballus/llvm-project/tree/abisan/llvm/t...

Comments URL: https://news.ycombinator.com/item?id=45095134

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=45094562

Points: 3

# Comments: 0

See https://youtu.be/aKPAX00ft5s?feature=shared&t=8730 for a relevant demo.

You can also (in principle) steal responses intended for other clients, and control responses that get delivered to other clients.

https://github.com/narfindustries/http-garden

The only requirement is that the code needs to run on our server, which they can easily check before submission.