codys

Others have previously responded to you reposting this link with this commentary, noting that the numbers included there are the result of a tabulating error.

Continuing to attempt to use it to push misinformation after being informed is not acceptable.

As others have noted, the statistics you listed are recklessly inaccurate.

That said: even if they were accurate, we'd still need to examine how may signature match failures result in detecting actual fraudulent voting, and how many signature match failures don't (ie they are false positives that serve to disenfranchise voters).

It turns out that the vast majority (97%) of ballots rejected due to signature match issues are likely valid. IOW: we'd disenfranchise 32 people for every case of fraud occurring. I have personal doubts that the rate for fraud was even that high (3% of the % of ballots rejected for sig mismatch), as you'd expect some type of criminal charges resulting from it.

Even assuming the 3% of sig rejects number, because that's already a % of sig rejects, it comes out to 3% of 0.2% (the actual number of sig mismatch rejections). This is 0.006% of the total vote.

Additionally, signature match checking disproportionately rejects votes from specific groups, while accepting votes from other groups. In other words, having a signature check (or making it "stricter") allows tuning which demographics you accept votes from. Allowing this type of targeted disenfranchisement is not good

It's also unclear how one could know it wasn't an authorized user who sent the message. ie: could be any of folks who are authorized who sent it.

Of course, they may have just asked all the authorized users, and had each of them deny it.

Ya, I was using snapper but didn't restrict the number of snapshots so I probably had more than 20

I use zfs now and have many, many, more than 20 snapshots without issue.

I wasn't using a nvme drive with btrfs, it was a sata ssd. So perhaps the higher io ops or lower latency also helps.

Are you using snapshots? qgroups (which you have to enable to see snapshot space utilization)?. I've had bad experiences with them on btrfs.

There are limits on GHA to the number of minutes for private repos when not using self-hosted runners (currently 2_000 minutes per month allocated per org/user when using "Github Free")

Can you talk a bit about the "moving pieces" and/or the process here? Interested in the process of doing this type of migration.

macos already has capabilities for compressing memory used by applications before finally giving up and paging it out. It seems plausible they could extend the code that supports that feature to push memory to external (or allocate it there in the first place if utilization isn't expected to be hot), and only pull it back after utilization indicates there is a benefit.

What POSIX and the linux kernel calls "capabilities" unfortunately result in quite a bit of confusion, which I believe is the cause of your post. POSIX capabilities bear little resemblance to actual capability based security (where a capability is a send/recv-able token that references an object and a set of rights for interacting with that object).

On the same subject matter: https://news.ycombinator.com/item?id=24948072

On the same subject matter: https://news.ycombinator.com/item?id=24947247

That's a HDMI capture device. The one you've linked takes a HDMI signal, compresses it, and provides it over USB2.0.

When digitalizing VHS tapes, generally one doesn't have a HDMI signal to use. They either have Composite (typical) or S-Video (better, but rarer). Typically, one should get a Composite/S-Video to USB device rather than trying to add a Composite/S-Video to HDMI device into the link here. Adding more pieces that you don't have control over tends to result in more issues and/or worse capture quality (due to extra filtering/compression steps applied).

Devices like the "Hauppauge 610 USB-Live 2" and "Elgato Video Capture" (I'd use the Hauppage device personally) provide a Composite/S-Video to USB 2.0 adapter that can provide uncompressed video.

Yes, it's clear that using a broken capture device or a system that doesn't properly sync the timestamps between video and audio captures (ie: driver issue) is the core issue.

Just choosing a different capture device or finding one with less broken driver support would have been workable.

S-Video output on SVHC players is active for both VHS and S-VHS tapes. VHS (normal) signal is not exactly the same as composite, the Y and C signals are encoded differently, meaning there _can_ be a benefit from only decoding VHS and not re-encoding into composite.

The "dome" portion is cast metal under the white plastic (iow: there is a case metal dome that all the electronics sit inside), which serves as a heat sink for the chips (cpu has a rather long heat pipe to one of the 4 screw posts that hold the bottom to the dome part) and ballast to keep the monitor upright

Along similar lines, Port knocking (https://en.wikipedia.org/wiki/Port_knocking) is something out-of-band used to allow access to a host (bypassing a firewall).

I think I'd sooner implement port knocking rather than port-hopping

They also disclose immediately after the summary at the start (bullet points).

One piece of this is probably that compilers competing to generate the best code have increasingly incorporated understanding of undefined behavior into their optimizers, leading to things that were previously undefined but happened to behave in some particular way to instead behave in ways that break programs using undefined behavior.

Compilers incorporate inferences that can be made by assuming UB doesn't occur into their optimization because it improves code generation of correct programs.

This argument is continuing to ignore the solution that's already used to handle new APIs that are unstable and might not be ready: allowing developers to opt-in to deployment on that platform via standard metadata included in apps/extensions. If there was a concern with things being unstable, that would be the first thing to go to! There's already support for similar things. Creating special whitelisting is something extra that had to be done. Given the "we have too much work" angle here, I find it hard to understand why the existing mechanisms weren't extended instead of creating a new one.

It seems very funny to say "we had to give up and release a broken browser" and in the same breath take on extra responsibility for API correctness prior to letting any one who can't convince Mozilla to whitelist them to use the APIs. And take on responsibility of maintenance of a whitelist

The argument being presented would just as well support Microsoft releasing an automatic update to windows (automatically deployed to all their users) that only supported some tiny fraction of white listed applications. They then don't clearly make any promises about removing the white listing, or any timelines, but only vague statements about "ensuring a positive user experience" and "working with their application development partners".

Most people would probably see this as a Very Bad Thing, for a few reasons. First of all, if we were to take the claim that it's "to ensure stability of APIs" at face value, it would indicate a staggering lack of maturity in their decision making process around releases. Next, we shouldn't take the "API" argument as being anything representative of reality: applications people develop (or browser extensions) have always been the responsibility of the developers developing them. If there were bugs in a browser, they'd discover and work around them, or they'd have a broken extension/application. There isn't a way around that. Perfect APIs don't fix it: people write bugs into their applications/extensions/platforms all the time. Things are broken all the time. Testing has never been Mozilla's responsibility. It's always been on extension authors. There are already ways to "declare" in an extension that support of a specific version exists.

There is no competent technical reason to end up in this situation. We're only left with incompetence and malice. And it's _very_ difficult to think that the people running a popular mobile browser could be so incompetent. Though I'm sure we've all said that before about other Mozilla decisions.

The legislation is, honestly, difficult enough to parse that linking it with a non-specific comment ("sounds well thought out") just turns into a tar pit. I can't tell if you have specific agreements or disagreements, and the only approach available to discuss is to basically summarize it or link to it again.

On the ACCC response: it implies google made statements they did not, and seems to willfully ignore the reality of supporting the cost of a free service.

Do you have specific things you think this does or doesn't do? In the future it helps to start with those.

Are you using snapshots in btrfs? Perhaps trying to use this feature was what caused it to be needed for my use case.

> openSUSE has automatic snapshots with a fairly extensive retention policy.

Ah, so Fedora is limiting it's use of snapshots to avoid the need to have balances occur? Do you have some info on what level snapshot usage has to rise to before balances are needed on a regular basis? Is Fedora using snapshots at all?

There are whole repos[1] dedicated to scripts to perform the delicate work of running `btrfs balance` in various ways to ensure space is recovered.

openSuse (a distro which notably defaults to btrfs) packages these btrfsmaintenance scripts [2], and it appears they may have included it in their default install (I can't find a list of packages). Their wiki page on disabling btrfsmaintenance [5] implies that if disabled, manual maintenance (presumably via running, among other commands, some form of balance) is needed.

There's also an entry in the btrfs wiki [3] that indicates running `btrfs balance` will recover unused space in some cases. It helpfully notes that prior to "at least 3.14", balance was "sometimes" needed to recover free space in a file-system full state. (The lack of precision here doesn't inspire confidence)

Another btrfs wiki page [4] indicates that running balance may be needed to recover space "after removing lots of files or deleting snapshots".

1: https://github.com/kdave/btrfsmaintenance 2: https://software.opensuse.org/package/btrfsmaintenance 3: https://btrfs.wiki.kernel.org/index.php/FAQ#What_does_.22bal... 4: https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-balanc... 5: https://en.opensuse.org/SDB:Disable_btrfsmaintenance

To be clear: I was running a non-raid (single disk) setup where I found `btrfs balance` to be needed.

My experience with btrfs is from a few years ago, so it's possible they've changed the semantics here since then, but this might be applicable:

Btrfs requires a regularly run administrative task via "btrfs balance". Balancing consolidates data between partially filled block groups, which will restore consumed space even if a block group is not entirely empty. Typically, one runs balance with a set of gradually increasing parameters to control the records affected (ie: bash script that starts with block groups that are more empty and proceeds towards ones with a higher percentage utilization).

In my experience with btrfs a few years ago, running a balance in some situations would result is incredibly high system wide latency.

The man page [1] does not appear to reference the free space issue directly, so I'm not sure if they've removed this need.

1: https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-balanc...

The fact that go eventually fixed things doesn't really speak to the top-level comment on this thread that "The best thing about Go is how things are designed thinking ahead in the future and avoiding hypes."

That the things needed fixing (and especially in cases where there were previous ways of doing things that had to be entirely discarded) seems to go against the idea that there was thinking ahead in those areas.

The one issue I've seen with using `-p` here is that `git log -p` has worse performance when compared to plain `git log` because it needs to calculate diffs, and when searching in less ends up searching the diff contents (even when this is not desired)

No more than the alternates here:

- go tooling (ides, etc) have to be taught about the _specific_ embedding in the same way one could teach rust tooling about specifically `include_bytes()` (or any other specific macro in the same way one teaches go tooling to handle specific pragmas)

In the world of rust build scripts, there is tooling that exposes information about which files are used if dependency info is all that is required (I don't know to what extent imperative macros are able to expose similar info).

The core of how I see the comparison here: if we restrict ourselves to the capabilities of go pragmas in rust, the same level of support is possible, but even without that restriction there are ways to obtain (though with more work) the same info.

While I agree that browsers generally currently appear to exercise poor control over resources like cpu time and memory amount, I'm not sure that aiming to cripple all sites equally is the right tactic here. It seems like better "scheduling" and other resource management would be something that needs work regardless of whether we expose tools to improve web application performance to websites.