zrm

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.

The problem with fibre isn't the sensitivity. It's that most endpoints have a 1Gbps copper port on them and then Cat6A ports can be used with the common devices but also allow you to add or relocate 10Gbps devices without rewiring the building again.

There is almost certainly no way that writing a "magic" byte sequence to a file will cause the storage device to misinterpret it as control data and change the mapping of logical to physical blocks.

Which is also what happens if you use parameterized SQL queries. Or not what happens when one of the lower layers has a bug, like Heartbleed.

There also have been several disk firmware bugs over the years in various models where writing a specific data pattern results in corruption because the drive interprets it as an internal sequence.

The header and length of the payload are control data. It's still being concatenated even if it's binary. A common way to screw that one up is to measure the "length of payload" in two different ways, for example by using the return value of strlen or strnlen when setting the length of the payload but the return value of read(2) or std::string size() when sending/writing it or vice versa. If the data unexpectedly contains an interior NULL, or was expected to be NULL terminated and isn't, strnlen will return a different value than the amount of data read into the send buffer. Then the receiver may interpret user data after the interior NULL as the next header or, when they're reversed, interpret the next header as user data from the first message and user data from the next message as the next header.

Another fun one there is that if you copy data containing an interior NULL to a buffer using snprintf and only check the return value for errors but not an unexpectedly short length, it may have copied less data into the buffer than you expect. At which point sending the entire buffer will be sending uninitialized memory.

Likewise if the user data in a specific context is required to be a specific length, so you hard-code the "length of payload" for those messages without checking that the user data is actually the required length.

This is why it needs to be programmatic. You don't declare a struct with header fields and a payload length and then leave it for the user to fill them in, you make the same function copy N bytes of data into the payload buffer and increment the payload length field by N, and then make the payload buffer and length field both modifiable only via that function, and have the send/write function use the payload length from the header instead of taking it as an argument. Or take the length argument but then error out without writing the data if it doesn't match the one in the header.

If we can get that to raise a red flag with people (and agents), people won’t be trying to put control instructions alongside user content (without considering safeguards) as much.

At a basic level there is no avoiding this. There is only one network interface in most machines and both the in-band and out-of-band data are getting serialized into it one way or another. See also WiFi preamble injection.

These things are inherently recursive. You can't even really have a single place where all the serialization happens. It's user data in JSON in an HTTP stream in a TLS record in a TCP stream in an IP packet in an ethernet frame. Then it goes into a SQL query which goes into a B-tree node which goes into a filesystem extent which goes into a RAID stripe which goes into a logical block mapped to a physical block etc. All of those have control data in the same stream under the hood.

The actual mistake is leaving people to construct the combined data stream manually rather than programmatically. Manually is concatenating the user data directly into the SQL query, programmatically is parameterized queries.

You expect the files to still be accessible using relative paths. What do you expect to happen if your cloud storage file path is 50 characters long and is mounted in a folder which is 4050 characters long when PATH_MAX is 4096?

The sync application itself can handle this using openat(2) or similar and should probably be using that regardless to avoid races.

If you create the file with 'mkswap --file' it allocates the blocks. Trying to use 'swapon' with an existing sparse file won't remove the holes for you but does notice them and then refuse to use it.