raddan
raddan on Hacker News
Maybe smoking trends come in waves.
Then really shouldn't it be "everything is about money"? After all, it's clear that the actual lie is convincing a big group of people that they don't share a common cause. Racism has many causes, but using it as a divide and conquer tactic has to be one of the most disgusting ones.
Rare in the northeast US. In fact, I saw two students smoking on a college campus just last week and did a double take. I had not seen a single student smoking in at least a decade. Then I laughed remembering how when I was in college in the 90s, almost everybody smoked at least a little (often at parties), and seeing students smoking at the entrance to the dorm was pretty normal. I am an asthmatic so I've never smoked, and I remember my friends being stunned by this one night when we were out at a bar. Things have changed a lot around here.
Sure, but what do you propose governments do to stop it?
You should do it. But I recommend a book or two on compiler design. There are useful techniques (like SSA) that simplify program analysis if you decide you want to dip your toes into adding optimizer passes. Building stuff yourself, the hard way, is definitely the best way to learn. I wish I had unbounded time to do it…
Edit: I like the Appel compiler book. One of my students enjoyed “Writing a C compiler” by Nora Sandler. There are also a number of classic compiler books that feel more relevant once you are deep in the weeds.
Modern computers are exquisitely sensitive to spatial and temporal locality because many of the hardware features that speed your code up (for free!) take advantage of data or instructions that are “next to each other.” This can be a challenge in a functional program, because not only do you often have little control about where things go, the abstractions that make cool things possible (eg, closures, or lazy evaluation) naturally introduce indirection that hurts locality.
Whether code review is inportant or not probably depends on whether the problem someone is solving is important or not. But when it is important, I think we should be putting the onus on the person who filed the PR instead of burning our own neurons trying to understand volumes of stuff. Tell me what you asked the AI to do. Why is that a good idea? Once I hear that answer (because many junior programmer ideas don’t even get past that point), let’s look at the code together. Tell me why you think the code you submitted does what you say. Did you look at the code? Did you write tests? Did you check for test coverage? Maybe you’re a little smarter than that. Did you think through pre- and post-conditions? Corner cases? Are certain undesirable behaviors impossible? How do you enforce that? Types? State machines?
Even before slop coding good code review was hard, because verification is a hard problem. But we have many tools at our disposal to increase confidence without having to go full-on mathematical proof. Human understanding has always been the bottleneck, and as long as the thing you are doing is for humans, humans will have good reasons to want to understand it, so they will remain the bottleneck. This is ok. It’s ok for humans to be the rate-limiter. But don’t go it alone and fry your own brain.
Codex is interactive. This appears to be batch.
OpenBSD's errata list has recently started growing rapidly, and the scale is a real departure from the past. I have taken to running syspatch much more regularly than in the past. Anyway, it's clear that the project's stance on AI is "as long as reports are detailed and high-quality (and probably from a person with a record of such work) the project will act on it." See slide 17 here:
https://events.eurobsdcon.org/media/2026/submissions/ZGDXQR/...
This literally makes no sense.
You don’t need 2 and 3. You can express them just with with T. For example, you could use an Either type for “good, here’s your value/bad, here’s your error.” If you want to get more sophisticated, you can add a type with extra error cases. In my own combinator libraries, I also include extra failure information to make diagnosing failed parses easy (and to generate pretty output). This does not change the fact that T is sufficient.
> T is not any type, T is a type defined at compile time,
This is a distinction without a difference. In a static, type-safe language, T always has to be instantiated with a type. But that does not change the fact that, from the perspective of the function definition, T is any type. T must be a specific type for the function call.
Yeah, the academic presentation of parsing complexity is not very useful for real-world parsing tasks. It is useful to know that regular expressions are limited (NFAs “can’t count”, so they’re not good for trying to match an unbounded number of balanced parentheses, for example). But beyond that, we largely choose capable algorithms either for ease of use or speed. Combinators, PEGs, parser generators (like lex/yacc, ANTLR) are mostly easy. For speed, almost everyone rolls a parser by hand.
I like combinator style parsers because
1) it’s really easy to think of a discrete parsing task as a function
2) tokenizing is mostly irrelevant
3) for pedagogical reasons, they make it easier for students to grasp the point of curried functions and partial application.
I even maintain a (mostly mature) parser combinator library for TypeScript for students in my research group to use.
https://github.com/williams-cs/parsecco
Combinators are functional—they always return something. But if you want to return nothing, fine; T is any type. Just return something like unit (ie, the singleton type that has nothing as a value).
It’s not no-win. It’s not sufficient to be a human! Be a better writer! There are plenty of good writers. The main difference between the bad ones and the good ones is that the good ones TRY to write better.
I’d like to see some evidence of this. Not to mention—experiments that show a phenomenon is more complicated than originally thought is not evidence of shoddy work. It’s just science. We all stand on the shoulders of giants.
A good example is Kahneman and Tversky’s work on the conjunction fallacy. We now know that “stereotype threat” is not the only reason somebody might make a mistake of the kind they were studying. And over the decades, better experiments introduced better controls and more nuanced analysis. That said, people still make conjunction fallacies, but the effects are not as pronounced as originally believed. Is this bad science? Absolutely not! The finding is, in fact, pretty robust; we just know that there’s more at work.
So how do you count that? Is that a “failure to replicate”? Technically speaking, yes. But it is not bad science, and more importantly, it’s not a standard that we hold even “hard” scientists to. Nobody is saying that Newton has been discredited because of general relativity.
Well, the key thing is that I don't want slop, period. I think a human should take the time and write it up. Honestly, my impression was the opposite-- it seemed like classic AI overly-jargony bullet point stuff.
I'm glad that people are using whatever tools are effective to find bugs, but if you expect a human audience to read about your findings, then is it not unreasonable to ask a human to write it? Most of the time a bug reveals a flaw in logic, and in operating systems, sometimes those logical flaws are informative, and lead to new and better designs, not just bug fixes. So there are potentially missed opportunities here.
Yes, but with the exception of sshd (which you get asked about during install), none of these things (NONE!!!) is enabled by default.
I am probably misremembering, but the OpenBSD documentation used to even explain how to disable inetd if you were too paranoid to use that. It is now disabled by default, and--I just checked one of my running systems--my machine does not even have an /etc/inetd.conf file. Most of the things running on a default install are init, cron, slaacd, a handful of gettys, ntpd, syslogd, and sndoid. Arguably sndiod is the only thing you could really remove from that list.
If it is, it's not very good. They provide the source for the exploit, great, but the explanation of the exploit is terrible: just seven pithy bullet points. It's not really clear what's going on without a lot more digging. The discussion of mitigations is better, though.
Context: I teach a college-level security class where undergrads do stack-smashing-like attacks (and every year a handful of talented students manage to pull off things like ROP attacks, analysis of entropy for a layout randomizers, or side-channel attacks). All of their writeups are much better than this one.
This is also why I stopped using Gentoo. I used it regularly from 2004-2005 (which I admit was a very long time ago now) on my graphite G4, because support was very good for PowerPC. But then one day emerge suggested I update glibc. I don’t know if I botched the update or if it really was suggested in error, but I was just starting my studies in CS so I did not know what that particular “library” did and said yes. The update must have included an ABI change. Not surprisingly, the machine did not come back up after a reboot.
Gentoo was fun while it lasted (fluxbox user here!). I decided that MacOS X wasn’t so bad after all after that.
I know you’re using a throwaway account but in case you come back to read this: we’re all tired of being scammed. Virtually every hot tech company now routinely overpromises and underdelivers. Some products are scams; some products kind of work but at great personal risk to oneself and others. The future we are excited about is one where technology SOLVES ACTUAL PROBLEMS.
I am highly skeptical. In my younger years, I brushed regularly but did not floss at all. After dealing with a surprising number of cavities over a short period of time, I decided to just start flossing, morning and night.
Not only does flossing remove quite a bit of, er... stuff... that toothbrushing does not seem to get, I have not had a single new cavity in 25 years. The only issues I've had were old fillings falling out, including one that cracked my tooth which required a crown. Not a lot of work considering the time span.
Obviously one person is not "data" but seeing as I am that one person, I'm going to keep flossing.
> Being polite to a model isn't like saying please and thank you to my dog when he does his business, it's like saying please and thank you to my furnace when it turns on and off.
True, but if saying “please” has a measurable functional effect then this is an important characteristic of the system. I also observed that saying please and thank you produced notably different responses. For me, there’s no real danger of anthropomorphism—I recognize that it’s a machine. But I also want it to do what I ask, so in my mind it’s really no different than having to use semicolons in Java but not in Python.
What do streaming implementations do when a bigger context reveals a different interpretation/parse? When I use Whisper in the terminal, I can see it going back and correcting itself. Are corrections off the table for a true streaming transcription?
It's odd that the matching algorithm does not simply prioritize the music already in your library, but I see something similar in other domains where machine learning/information retrieval is used. E.g., in Apple Maps, I might have the map centered over my location and type in a restaurant nearby. Often, Apple Maps will find a restaurant with the same name on the other side of the country. This strikes me as an easy thing to fix (and Apple Maps has had this bug from the beginning), but if somebody knows something abou this, I'd love to know. Maybe it's harder than I imagine.
> Aren’t high-level programming languages very refined encodings of “logic, interfaces, and data models?”
I feel like I would be hard pressed to explain what I want in English more concisely than just writing a SQL query.
You are right about high entropy short-ish passwords but almost nobody does that. Virtually everybody chooses something not just low entropy but often easily crackable with good search heuristics. Why not give people another way to produce passwords that are harder to crack? With luck, at least a few people will choose a correct-horse-battery-staple.
> I don't think anyone would care about "hand made software", arguably no one ever did. You need a tool to do X.
I absolutely do. Perhaps this is a product of my first exposure to computers, but I vividly remember the early Macintosh computers coming on the scene. The care and attention to detail on every level of the machine was special. They were so different than everything before. And it inspired many developers to produce beautiful, weird, awesome software. Does anybody remember the Talking Moose? After Dark? Spaceward Ho! HyperCard? RoboWars? Heck, even MSWord 5.1a was an amazing piece of software whose grammar checker literally taught me grammar.
Now we have “software that does X”, but that X is so bland and enshittified nearly all the joy of computing has been erased. I love writing software. I love writing good and clever software. Perhaps the world no longer cares, but I do.