munch117

no profile record

コメント

2 か月前議論

The fatal flaw in PG's argument is that is doesn't mention spending at all.

If you're spending your entire income on things like food and rent, then a 1% wealth tax corresponds to 0% income tax.

If you're spending your entire income on investment, then there's a calculation like PG's to be made to compute an equivalent income tax rate. But then we're talking about someone who doesn't need the money. This isn't even about rich vs. poor - you can have a high income and spend it all as you make it, like if you throw a huge party every week, or make a yearly trip into space. But if not, then it's just an ever growing number on your bank statement, and the only reason you care about it being 20% higher is because you're comparing it to other people's bank statements.

2 か月前議論

I didn't suggest that implementations should entirely eliminate every form of UB. There is plenty of middle ground. For example, you could easily limit the consequences of integer overflow by specifying or partially specifying overflow behaviour, with very little runtime cost.

I'm not suggesting you change how you write code, but with a better implementation the code that you do write - that lives in the real world where mistakes are made - might work better. How is that being pedantic?

An interesting case where compiler writers did something like that is casting via union members, but I'm running out of time, so we can talk about that another day.

2 か月前議論

Both are wrong. It means "this standard does not constrain the behaviour of code that does this".

It's entirely legal for implementations to have predictable behaviour, documented or not, for code that is undefined by the standard. In their quest for maxxing benchmark performance they generally choose not to, but there's really nothing in any standard that stops you from making an implementation that prioritises safety.

4 か月前議論

Making a plan that works for the general case, but is also efficient, is rather trivial. Here's pseudocode from spending two minutes on the problem:

    # INPUT: lookfor: unicode
    var lower, upper: ascii
    lower = ascii_lower_bound(lookfor)
    upper = ascii_upper_bound(lookfor)
    for candidate:ascii in index_lookup(lower .. upper):
        if expensive_correct_compare_equal(candidate.field, lookfor):
            yield candidate

The magic is to have functions ascii_lower_bound and ascii_upper_bound, that compute an ASCII string such that all ASCII strings that compare smaller (greater) cannot be equal to the input. Those functions are not hard to write. Although you might have to implement versions for each supported locale-dependent text comparison algorithm, but still, not a big deal.

Worst case, 'lower' and 'upper' span the whole table - could happen if you have some really gnarly string comparison rules to deal with. But then you're no worse off than before. And most of the time you'll have lower==upper and excellent performance.

5 か月前議論

> Just clearly state your requirements.

Nothing new here. Getting users to clearly state their requirements has always been like pulling teeth. Incomplete sentences and all.

If the people you are teaching are developers, they should know better. But I'm not all that surprised if many of them don't. People will be people.

5 か月前議論

TNG, by a country mile. B5 has "writer identifies too much with the main character" written all over it. It's the story of how Our Great Leader does the right thing and saves the world, over and over again.

5 か月前議論

I was reading https://www.offsec.com/blog/cve-2026-24061/, which implies that precisely that single long string passes through getenv("USER") in the attack. The mystery is how that single long string in telnetd becomes two separate arguments for login. execv or posix_spawn certainly won't do that. So either there's a version of /usr/bin/login that parses arguments in some very sus way, or there's a shell involved somehow.

5 か月前議論

I'm slightly taken aback by the telnetd fix: The solution to the username "-f root" being interpreted as two arguments to /usr/bin/login is to add a "sanitize" function, really? I'm not seeing the sense in that. Surely in any case where the sanitize functions changes something, the login will fail. Better to error out early than to sanitize and try to hobble along.

What I'd like to know is how the arguments get interpreted like that in the first place. If I try giving that kind of argument /usr/bin/login directly, its argument parser chides me:

  $ login '-f root'
  login: illegal option --

What's telnetd doing differently? Is it invoking login via a shell?

7 か月前議論

> Also worth noting that the author never actually stated that they did not use generative AI for this article.

I expect that they did in some small way, especially considering the source.

But not to an extent where it was anywhere near as relevant as the actual points being made. "Please don't complain about tangential annoyances,", the guidelines say.

I don't mind at all that it's pointed out when an article is nothing more than AI ponderings. Sure, call out AI fluff, and in particular, call out an article that might contain incorrect confabulated information. This just wasn't that.

7 か月前議論

I struggled a bit with what to point to as signs that it's not an LLM conception. Someone else had commented on the headlines as something that was AI-like, and since I could easily imagine a writing process that would lead to headlines like that, that's what I chose. A little too confidently perhaps, sorry.

But actually, I think I shouldn't have needed to identify any signs. It's the people claiming something's the work of an LLM based on little more than gut feelings, that should be asked to provide more substance. The length of sentences? Number of bullet points? That's really thin.

7 か月前議論

This article is just about as un-AI written as anything I've ever read. The headings are clearly just the outline that he started with. An outline with a clear concept for the story that he's trying to tell.

I'm beginning to wonder how many of the "This was written by AI!" comments are AI-generated.

8 か月前議論

A __del__ that does any kind of real work is asking for trouble. Use it to print a diagnostic reminding you to call .close() or .join() or use a with statement, and nothing else. For example:

    def close(self):
        self._closed = True
        self.do_interesting_finalisation_stuff()
    def __del__(self):
        if not self._closed:
            print("Programming error! Forgot to .close()", self)

If you do anything the slightest bit more interesting than that in your __del__, then you are likely to regret it.

Every time I've written a __del__ that did more, it has been trouble and I've ended up whittling it down to a simple diagnostic. With one notable exception: A __del__ that put a termination notification into a queue.Queue which a different thread was listening to. That one worked great: If the other thread was still alive and listening, then it would get the message. If not, then the message would just get garbage-collected with the Queue, but message would be redundant anyway, so that would be fine.

9 か月前議論

> If you think you disagree with him (as I once did), please consider the possibility that you've only been exposed to an ersatz characterization of his argument.

My first exposure was a video of Searle himself explaining the Chinese room argument.

It came across as a claim that a whole can never be more than its parts. It made as much sense as claiming that a car cannot possibly drive, as it consists of parts that separately cannot drive.

10 か月前議論

Ah, I missed that 9.a-c were alternatives. And that, in the absence of custom tables or functions, they are merely defense in depth for something that is already secure, barring bugs. I withdraw my concern.

10 か月前議論

I'm not that concerned with bugs in sqlite. sqlite is high quality software, and the application that uses it is a more likely source of vulnerabilities.

But I do see a problem if you really need to use a sqlite that's compiled with particular non-default options.

Say I design a file format and implement it, and my implementation uses an sqlite library that's compiled with all the right options. Then I evangelize my file format, telling everyone that it's really just an sqlite database and sooo easy to work with.

First thing that happens is that someone writes a neat little utility for working with the files, written in language X, which comes with a handy sqlite3 library. But that library is not compiled with the right options, and boom, you have a vulnerable utility.

2 年前議論

Just to be even clearer.

In the time of the original use, there were only static types. Languages had very little in terms of UDT's. Even a struct in C was barely a type of its own. I don't recall the details, but there was something about struct member names not being local to the struct. Interpreted languages didn't have records or classes at all(*), and certainly not types as first class objects.

We cannot really talk about how dynamically typed languages with rich type systems were originally labelled, back when they didn't exist at all.

(*) I'm looking forward to someone pointing out an interesting counterexample.

2 年前議論

There's lots of programming languages still around with untyped elements to them. Javascript is one of them, with its string/number conversions and the way arrays are defined. Then there's all the stringly typed stuff. Make, CMake, Excel, TCL, bash. You're probably right that the original use of the term came from assembly vs. high level, but that objection is meaningless, because nobody is using "untyped" that way anymore....

What makes changing the meaning of "untyped" extra confusing is that dynamically typed programming languages often have types as 1st class objects, and they get used all the time for practical everyday programming. Calling these languages "untyped" is just wrong on the face of it -- they're full of types.

3 年前議論

The thing with git is that learning the general idea of the internals is not enough. You can learn enough about git to visualize a DAG of nodes identified by hashes, but what does that get you? You still have a thousand higher-level commands that build on top of it, and for each of those you have to learn how what it does translates into nodes and hashes.

The higher level commands are not individually leaky abstractions. But you can't connect them at a higher level of abstraction. In order to understand how "git foo" relates to "git bar", you go through the lower layer.

So git has you learn:

  1. The fundamentals.
  2. A thousand higher-level commands.
  3. How each of the higher level commands translate into the fundamentals.

Version control is supposed to be a tool to help me, to take away chores so that I can focus on other, more interesting, things. This is not something I want to invest a lot of time on. Even as software developer, most of time when I use software I'm just a user, and I want the tool to do its job and get out of the way.

Car analogy: I drive cars and leave the rest to the mechanics.

4 年前議論

"Always in Daylight savings time" is just a different time zone. Doesn't need a setting of its own.

4 年前議論

> What about all the embedded systems out there, which do very important things with timekeeping?

I've written a few of those. Supporting not-DST basically comes down to unchecking the bit in the configuration where it says:

   [ ] Confuse the hell out of the users twice a year.

Even if the customer themselves specified precisely how to handle the changeover once upon a time, they still get confused when it happens and the daily report has 23/25 hour entries, or the daily totaliser takes a mysterious 4% dip, or the date changes an hour earlier/later than expected etc.

I've never seen an embedded device with automatic changeover that didn't have some kind of configuration option to switch it off.