And, yeah, the Unix syscalls are very prone to mistakes like this. For example, Unix's `rename` syscall takes two paths as arguments; you can't rename a file by handle; and so Rust has a `rename` function that takes two paths rather than an associated function on a `File`. Rust exposes path-based APIs where Unix exposes path-based APIs, and file-handle-based APIs where Unix exposes file-handle-based APIs.

So I agree that Rust's stdilb is somewhat mistake prone; not so much because it's being opinionated and "nudg[ing] the developer towards using neat APIs", but because it's so low-level that it's not offering much "safety" in filesystem access over raw syscalls beyond ensuring that you didn't write a buffer overflow.

[0]: https://doc.rust-lang.org/std/fs/index.html

In Oregon, TriMet is funded by a payroll tax: https://www.oregon.gov/dor/programs/businesses/pages/trimet-...

> The Oregon Department of Revenue administers tax programs for the Tri-County Metropolitan Trans­portation District (TriMet). Nearly every employer who pays wages for services performed in this district must pay transit payroll tax.

> The transit tax is imposed directly on the employer. The tax is figured only on the amount of gross payroll for services performed within the TriMet Transit District. This includes traveling sales repre­sentatives and employees working from home.

This sounds like they were most likely bit banging square waves into a speaker directly via a GPIO on a microcontroller (or maybe using a PWM output if they were fancy about it). In that case, the audio frequency will be derived directly from the microcontroller's clock speed, and the tolerance of an internal oscillator on a microcontroller can be as bad as 10%.

/usr/lib/dracut/modules.d/46cryptssh:

    #!/bin/bash
    
    check() {
        require_binaries sshd || return 1
        return 0
    }
    
    depends() {
        return 0
    }
    
    install() {
        if [ ! -e /etc/ssh/dracut ]; then
            mkdir /etc/ssh/dracut &&
            tmp=$(mktemp -d) &&
            head -c128 /dev/random > $tmp/passphrase &&
            ssh-keygen -t ed25519 -f /etc/ssh/dracut/ssh_host_ed25519_key -N"$(base64 < $tmp/passphrase)" &&
            tpm2_createprimary -C o -c $tmp/primary.ctx &&
            tpm2_pcrread -o $tmp/pcr.bin sha256:0,7
            tpm2_createpolicy --policy-pcr -l sha256:0,7 -f $tmp/pcr.bin -L $tmp/pcr.policy
            tpm2_create -C $tmp/primary.ctx -L $tmp/pcr.policy -i $tmp/passphrase -c $tmp/seal.ctx &&
            tpm2_evictcontrol -C o -c $tmp/seal.ctx -o /etc/ssh/dracut/seal || {
                rm -r $tmp /etc/ssh/dracut
                exit 1
            }
            rm -r $tmp
        fi
        for file in /etc/ssh/dracut/*; do
            inst_simple "$file" "/etc/ssh/${file#/etc/ssh/dracut/}"
        done
    
        mkdir -p -m 0700 "$initdir"/root/.ssh
        /usr/bin/install -m 600 /etc/ssh/dracut_authorized_keys "$initdir"/root/.ssh/authorized_keys
    
        inst_binary /usr/sbin/sshd
        inst_binary /usr/sbin/ssh-keygen
        inst_binary /usr/bin/tpm2_unseal
        inst_binary /usr/bin/base64
        inst_simple /usr/lib/libtss2-tcti-device.so
        
        inst_simple "$moddir"/cryptsshd.service "$systemdsystemunitdir"/cryptsshd.service
        inst_simple "$moddir"/sshd_config /etc/ssh/sshd_config
    
        inst_binary /usr/lib/ssh/sshd-session
        inst_binary /usr/lib/ssh/sshd-auth
    
        mkdir -p -m 0755 "$initdir"/var/empty/sshd
        mkdir -p -m 0755 "$initdir"/usr/share/empty.sshd
        mkdir -p  -m 0755 "$initdir"/var/log
        touch "$initdir"/var/log/lastlog
    
        systemctl -q --root "$initdir" enable cryptsshd
    }

    [Unit]
    Description=OpenSSH Daemon for Disk Encryption Passphrase
    DefaultDependencies=no
    Before=cryptsetup.target
    After=network-online.target
    
    [Service]
    Type=notify-reload
    ExecStartPre=/bin/sh -c '/usr/bin/ssh-keygen -p -f /etc/ssh/ssh_host_ed25519_key \
        -N "" -P "$(/usr/bin/tpm2_unseal -c /etc/ssh/seal -p pcr:sha256:0,7 | base64)"'
    ExecStart=/usr/bin/sshd -D
    KillMode=process
    Restart=always
    
    [Install]
    WantedBy=sysinit.target

It's still probably vulnerable to a cold boot attack, since the key is decrypted CPU-side. It would be interesting to perform the actual key operations on the TPM itself to prevent this.

This, here, is the root of the issue: "I'm not interested in using an AI agent for my own problems, I want to unleash it on other people's problems."

The author is trying to paint this as somehow providing altruistic contributions to the projects, but you don't even have to ask to know these contributions will be unwelcome. If maintainers wanted AI agent contributions, they would have just deployed the AI agents themselves. Setting up a bot on behalf of someone else without their consent or even knowledge is an outlandishly rude thing to do -- you wouldn't set up a code coverage bot or a linter to run on a stranger's GitHub project; why would anyone ever think this is okay?

This is the same kind of person who, when asked a question, responds with a copypasted ChatGPT reply. If I wanted the GPT answer, I would have just asked it directly! Being an unsolicited middleman between another person and an AI brings absolutely no value to anybody.

They also mention in the next sentence that they adopted the "correct" workaround (by providing a multiplication library function for the compiler to call).

There's a sign near my house for a school zone with a reduced speed limit, that used to have conditions similar to the GP's example (though not quite as bad) But they recently attached a yellow light to the top of the sign and changed the condition to "when flashing." That's a much more effective solution.

I also appreciate you giving me an updated copy of the "Microsoft is a corporation" meme, as the one I have downloaded seems to become outdated each time a new Windows update comes out.

In this case, both AWS and Cloudflare had high-profile outages within the past few months. So a bunch of people tried to check their Twitter, got an error, and said "huh, I wonder if AWS is down again". Or during yesterday's Verizon outage, DownDetector also showed spikes on AT&T and T-Mobile, presumably from people who forgot what cellular provider they had, were roaming, or maybe were trying to call someone on another network.

It also doesn't help that they normalize the scale of their graphs on the front page. If you click them, you can see that 75k people googled "is X down", while only 200 people googled "is AWS down".

One of the bigger problems with the site's moderation systems was that 1) this system was incredibly opaque and unintuitive to new users, 2) the reopen queue was almost useless, leading to a very small percentage of closed questions ever getting reopened, and 3) even if a question did get reopened, it would be buried thousands of posts down the front page and answerers would likely never see it.

There were many plans and proposals to overhaul this system -- better "on hold" UI that would walk users through the process of revising their question, and a revamp of the review queues aimed at making them effective at pushing content towards reopening. These efforts got as far as the "triage" queue, which did little to help new users without the several other review queues that were planned to be downstream of it but scrapped as SE abruptly stopped working on improvements to the site.

Management should have been aggressively chasing metrics like "percentage of closed questions that get reopened" and "number of new users whose first question is well-received and answered". But it wasn't a priority for them, and the outcome is unsurprising.

Unfortunately, the company abruptly stopped investing in the Q&A platform in ~2015 or so and shifted their development effort into monetization attempts like Jobs, Teams, Docs, Teams (again), etc. -- right around the time the moderation system started to run into serious scaling problems. There were plans, created by Shog and the rest of the community team, for sweeping overhauls to the moderation systems attempting to fix the problems, but they got shelved as the Q&A site was put in maintenance mode.

It's definitely true that staff is to blame for the site's problems, but not Shog or any of the employees whose usernames you'd recognize as people who actually spent time in the community. Blame the managers who weren't users of the site, decided it wasn't important to the business, and ignored the problems.

But note:

> Does it run at the full speed of an original 6502 chip?

> No; it's relatively slow. The MOnSter 6502 runs at about 1/20th the speed of the original, thanks to the much larger capacitance of the design. The maximum reliable clock rate is around 50 kHz. The primary limit to the clock speed is the gate capacitance of the MOSFETs that we are using, which is much larger than the capacitance of the MOSFETs on an original 6502 die.

So if you built a SID using the same techniques and components, you couldn't run it in real-time without the pitch being way too low or without modifying the design. I'm not sure how hard this would be to avoid with better-spec'd components, but intuitively it makes sense for a much larger circuit to run much slower.

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

Points: 2

# Comments: 0

    is_divisible_by_6(int):
        test    dil, 1
        jne     .LBB0_1
        imul    eax, edi, -1431655765
        add     eax, 715827882
        cmp     eax, 1431655765
        setb    al
        ret
    .LBB0_1:
        xor     eax, eax
        ret

    is_divisible_by_6_optimal(int):
        imul    eax, edi, -1431655765
        add     eax, 715827882
        ror     eax
        cmp     eax, 715827883
        setb    al
        ret

But note the branch in the first function! The original code uses the && operator, which is short-circuiting -- so from the compiler's perspective, perhaps the programmer expects that x % 2 will usually be false, and so we can skip the expensive 3 most of the time. The "suboptimal" version is potentially quite a bit faster in the best case, but also potentially quite a bit slower in the worst case (since that branch could be mispredicted). There's not really a way for the compiler to know which version is "better" without more context, so deferring to "what the programmer wrote" makes sense.

That being said, I don't know that this is really a case of "the compiler knows best" rather than just not having that kind of optimization implemented. If we write 'x % 6 && x % 3', the compiler pointlessly generates both operations. And GCC generates branchless code for 'is_divisible_by_6', which is just worse than 'is_divisible_by_6_optimal' in all cases.