zrm

Consider this (quite common) code:

  char buffer[LARGE_SIZE];
  if(maybe_fill_buffer(buffer, sizeof(buffer))) {
      use_result(buffer);
  }

The function maybe_fill_buffer() is an external library function that either fills the buffer and returns true or doesn't access it and returns false. Or maybe it unconditionally fills it, or unconditionally returns false without reading from it. The compiler can't see any of that though because it's in an external library. For all it knows that function is going to read from it instead of writing to it.

Notice that if it could actually figure it out 99% of the time then it could also emit a warning the 1% of the time that it can't and encourage you to make an explicit choice, which would have been a better option if that was actually the rate.

That's assuming you were reading it without writing to it. There are three common cases when that isn't true.

The first is that you have a fixed buffer large enough for the maximum message size even though the typical ones aren't that big. You most often write 1% of the buffer and read it back, the other 99% is never accessed.

The second is that you always write the entire contents before reading it but the compiler may not be able to see that.

And the third is that you have a code path where that variable is simply not used.

You would then have the compiler emitting instructions to write zeros that are either overwritten before being read or are never read at all.

Moreover, zero initializing the data doesn't actually remove the bugs when that isn't the case. Consider the first case when you mess up. You have a fixed buffer used to store variable length messages. For the first message the buffer is now zeros instead of uninitialized, but for every subsequent message the remainder of the buffer still contains the remainder of the previous message and subjects you to information disclosure or data modification if you're reading back a different amount than was written in the associated call.

Now consider the second or third case. You unintentionally read from a variable before assigning to it. You get zeros instead of uninitialized memory, but if you weren't expecting zeros, well, the UID field is now 0.

> the more features you add to the burner phone, the more it begins to look like the device you're leaving "safe" at home.

Wouldn't a sensible way to do this be to create an encrypted backup of your device on a VPS, then restore it to the "burner phone" once you're on the other side of the border, and wipe the device again before you come back?

The idea being that whenever you're at the border crossing, the device contains nothing, and the passphrase for the backup is in your head.

How does the customer service rep tell that a name with some Unicode gubbins is an attack rather than a customer from Juárez or 서울? Having a busy hand copy and paste the attacker-provided string into the system doesn't get you out of it.

> Any stenographic system that you have the code for can be trivially defeated.

They're giving you an oracle regardless, which is almost as good. Take LLM output, make some modification, ask the detector if it's LLM output, repeat until you learn what kind of changes you have to make to defeat it.

Or don't even bother learning what to do, just make arbitrary changes until it says it's not, so when the person they're submitting to does the same check it says the same thing.

> we're approaching a time where a single processor has hundreds of threads

Approaching? EPYC 9996 has 512 threads. EPYC 9754 had 256 threads three years ago.

It seems like what's missing here is lower cost plans, because the existing plans had been fairly affordable, but now they're basically triple.

The least expensive one seems to be CPX11, old price $6.99, new price $20.49. That's 2GB RAM, 40GB SSD. RAM and SSD are now much more expensive, fair enough, but maybe I don't need all that for my mostly-idle VM, so then where's the plan with ~0.67GB RAM and ~13GB SSD for the old price?

> I did not.

This is the exact quote:

> And at least for connected devices at home, a dedicated app can have lower friction for initial setup for the "I'm not a computer person" crowd than other alternatives do.

What good does it do you to dispute that you implied it as a justification for the status quo when your error is contained in the part you're not disputing?

You made the claim that companies require apps because it has lower friction for ordinary users. That claim is in error.

The implication that there is nothing anyone can do to improve the existing state of affairs is also incorrect.

> And at least for connected devices at home, a dedicated app can have lower friction for initial setup for the "I'm not a computer person" crowd than other alternatives do.

For a router? This is the device that you will often not have internet access with which to download an app until after it's configured. Many people have wired internet specifically because they live somewhere with poor cellular reception. Meanwhile the device can give out DHCP and use the standard captive portal mechanisms to automatically direct any client device to its configuration page.

You only need things like that for non-iterated games. A company that gets a reputation for keeping the money when it's a real bug would stop getting real bug reports.

You don't have to determine if it's an AI or not. If AI finds a real bug then it can get the bounty. If a human pays to make you read artisanal hand-crafted word salad then they don't get a refund. Real bugs get the bounty, imaginary bugs pay the fee.

Bounties already have that whenever you reject one for being nothing.

Just require people submitting a bounty to post an evaluation fee. If it's a real bug they get a refund and the bounty. If it's AI slop, you keep the evaluation fee.

It seems like what this needs is the return of video arcades.

Fill a room at the mall with Linux boxen with midrange GPUs and fiber internet and the sort of keyboards you can clean with pressurized water. Charge an entry fee and then sell pizza, cheetos, coffee, soda and beer. Open at 11AM and close at sunrise.

Then publish the public IPs used by the arcade-owned machines at each location in the chain and use different public IPs for the customer WiFi. No DRM nonsense, just a way to know you're playing with someone at the arcade where the management doesn't allow cheats on their machines.

There are two different kinds of updates.

One is security updates and bug fixes. These need to fix the problem with the smallest change to minimize the amount of possible breakage, because the code is already vulnerable/broken in production and needs to be updated right now. These are the updates stable gets.

The other is changes and additions. They're both more likely to break things and less important to move into production the same day they become public.

You don't have to wait until testing is released as stable to run it in your test environment. You can find out about the changes the next release will have immediately, in the test environment, and thereby have plenty of time to address any issues before those changes move into production.

> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time.

That's not what it's about.

What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it will break in production for anyone who is actually using it. So instead the change goes into the testing release and the user discovers that in their test environment before rolling out the new release into production.

> On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport.

They're not alternatives to each other. The stable release gets the backported patch, the next release gets the refactor.

But that's also why you want the stable release. The refactor is a larger change, so if it breaks something you want to find it in test rather than production.

They can block traffic to update servers so the computers behind the router aren't all patched up, then exploit them. They also get access to all the IoT devices on the internal network. They can also use your router as a proxy so their scraping/attack traffic comes from your IP address instead of theirs.

It's definitely bad.

They're not going to put a newer version in stable. The way stable gets newer versions of things is that you get the newer version into testing and then every two years testing becomes stable and stable becomes oldstable, at which point the newer version from testing becomes the version in stable.

The thing to complain about is if the version in testing is ancient.

For that you really only need CAP_NET_BIND_SERVICE.

The bigger issue is that if you want to install or update system-wide packages, many of those will be used by privileged processes. Suppose you want to update /bin/sh. Even if the only permission you had is to write binaries, that'll get you root.

> But if you want to participate in the writing, debugging, and maintenance, it has to be in a language that a human can read.

I think the idea is that languages like Python and JavaScript make it easier for humans to write the initial implementation, whereas the "hard" languages from the perspective of creating the minimum viable product are the ones that make it easier for humans to maintain the code, and this has historically been a major trade off.

Whereas if you have the AI write the initial implementation...

"When you thrash them" is kind of the issue. There are ten year old business desktops with a <10W idle power consumption. If your use for it is to have something to rsync files to and host your personal website and the like, even old hardware is going to average 99% idle. There is no meaningful power savings from newer hardware unless you're consistently putting it under significant load.

Some of the newer hardware is actually worse because the idle power consumption of PCs since around 2010 is determined in significant part by the low-load efficiency of the power supply. Brand new machines with the wrong power supply can use several times as much power at idle as ten year old machines with the right power supply. Annoyingly, power supply efficiency at idle is rarely documented so the only thing to do is measure it.

> You cannot utilize that type of speed with a Mac Mini.

Mostly because the base Mini has Thunderbolt 4 which maxes out at 40Gbps. Anything with a PCIe 4.0 x16 slot will take a 100Gbps NIC. 100Gbps is around 10GBps (8 bits per byte plus encapsulation overhead). Desktop CPUs can do AES-GCM at 2.5GBps+ per core and have up to 16 cores and around 50GBps of memory bandwidth (dual channel DDR4-3200), so the NIC still seems like the bottleneck.

The noise problem is pretty easy to mitigate by choosing 2U servers instead of 1U. The latter are forced by the form factor to use smaller, higher speed fans.

A bigger issue for enterprise hardware is that it's optimized for performance per watt under load, not idle power consumption. Running a mostly-idle rack server 24/7 can result in a pretty sizable electric bill. This also depends heavily on the model. Some will idle at ~50 watts, others at ~300, but both of these are significantly higher than a Raspberry Pi or an old laptop which for personal use will generally do the job.

Business class desktops are also a good alternative here. Many models have pretty reasonable idle power consumption (check this for yourself, I've seen 6W but also 60W) and then you get a couple of drive bays and PCIe slots and expandable RAM which you don't get from a Raspberry Pi.

Its performance is pretty unbalanced. If you're using it for the couple of things that it's good at, the TDP is competitive.

Which is why people run only copper because that costs less than running multiple types of cable everywhere when most drops only have one device, and then pull fibre through using the existing copper cable in the rare instances where they find a need for 40Gbps or more.

But then the copper gets used for 10Gbps connections instead of fibre because it's what's already in the building.

The original problem was that everyone runs copper instead of fibre because there are too many existing devices that only have copper. Running both everywhere would require you to buy and terminate twice as much cable as you expect to use, which leads people to running only copper again.

If you chose PCs to begin with that come with fibre ethernet or put quality cards in the ones that matter then you could make fibre the default instead of copper. Until you have a number of devices like printers or VoIP phones or Raspberry Pis that have no need for 10Gbps or even 1Gbps connectivity, they just need a way to be plugged in at all. If you need to add $100+ in conversion expense to each of those devices, you're back to using copper by default.

> If you're connecting a single device, why the hell would you use that when you could slap a copper SFP or SFP+ module in the switch's cage and run a cable?

The problem to be solved is that you want to be able to put fibre inside the walls of the building instead of copper. Running a new cable to the switch closet is the thing to be prevented.

But if the wall jacks are fibre then you need some economical way of hooking them up to every printer and single-purpose device with a network port. If you have to buy another $100+ switch just to get from fibre to copper even when there is only one device near that jack, people aren't going to go for that.

You can get copper ones for $5.99 (quality may vary):

https://www.amazon.com/1000Mbps-Network-Performance-Gigabit-...

https://www.amazon.com/SALAN-Ethernet-Portable-Internet-Conv...

But it's not competing with those, it's competing with the copper port which is already built into most devices.

Another thing that would work is something like this (also $5.99), but with one of the ports as fibre:

https://www.amazon.com/Gigabit-Ethernet-Splitter-1000Mbps-In...

The point being you need some cheap way to plug in existing copper devices if you run fibre to the endpoints.

This plus $5 for a transceiver is pretty close at $15:

https://www.amazon.com/Gigabit-Ethernet-Converter-Auto-Negot...

But +$15 and an extra wall outlet per endpoint is still an inconvenience, and if a two-port device with its own power supply can be made for $15 then where is the PCIe/USB to fibre adapter for <$10?

That doesn't solve the chicken and egg problem.

What probably would is something like having PCIe and USB to 1Gbps fiber adapters that cost $5.