Amazon, for example, charges us for cloud resources and then charges us again (handsomely) for the privilege of submitting bug reports to them. And then sometimes, even with a clear, deterministic repro for a bug with no plausible workaround (besides "stop using the feature"), where the fix is probably as simple as "pull a fix from upstream open source repo" or "sic Claude on it for 10 minutes", the bug remains open for literally years.
This is very different from "I didn't read the instructions on the screen and now I'm calling support". Both scenarios exist. I have some sympathy for businesses facing the latter, and much less for businesses facing the former.
Claude will answer all of those questions. The restriction Anthropic has is letting Claude pull the trigger and vibe-murder with no humans in the loop.
Or in case some folks find the addition of a computer confusing here, if someone sends you a physical letter and they've used correction tape or a black marker to obscure some parts of the letter, and you scratch away the correction tape or hold the letter up to a light source to read what's underneath, have you committed a crime?
I'm not a lawyer, so I don't know what the law has to say about this. But I do have at least a small handful of brain cells to rub together, so I know what the law _should_ say about this.
Precisely. If someone wants me to sign a contract on acceptable use of resources (like an agreement not to reverse engineer their software) they send me then that's another thing.
Absent that excluding other default protections like copyright, what I do with it should fall under the assumption of "basically anything".
If this were prior to 2021, I would say the CFAA could be violated so long as the property owner's _intentions_ were for that information to only be accessible to certain users. But I think the CFAA has been sufficiently reduced in scope after Van Buren v United States [0]
RDS, Route53, and Elasticache are decent, too. But yes, I've also been bitten badly in the distant past by attempting to rely on their higher-level services. I guess some things don't change.
I wonder if the difference is stuff they dogfood versus stuff they don't?
I once used one of their services (I forget which, but I think it was there serverless product) that “supported” Java.
… but the official command line tools had show-stopper bugs if you were deploying Java to this service, that’d been known for months, and some features couldn’t be used in Java, and the docs were only like 20% complete.
But this work-in-progress alpha (not even beta quality because it couldn’t plausibly be considered feature complete) counted as “supported” alongside other languages that were actually supported.
(This was a few years ago and this particular thing might be a lot better now, but it shows how little you can trust their marketing pages and GUI AWS dashboards)
I'm assuming you're talking about Lambda. I don't mess with their default images. Write a Dockerfile and use containerized Lambdas. Saves so many headaches. Still have to deal with RIE though, which is annoying.
Additionally, what has been the correct choice five years in a row might be catastrophically wrong in the sixth year. We need some randomness injected into our behaviour so that some people are always making "suboptimal" choices, to stop everyone from crowding into one local maximum and then getting swept away when the rare but inevitable flood comes along.
And with a little work you can even use them to map ranges of keys to values in a way that's reminiscent of interval trees — e.g. https://crates.io/crates/rangemap. (Disclosure: that's my crate.)
Nice! I was only suggesting considering BTrees because they also play nice with caches, instead of the more conventional binary tree balancing mechanisms.
This email is from a Debian maintainer, about Debian introducing a new hard dependency on Rust. It's not some random Rust advocate telling Debian folks that they should use Rust against their will.
Yes there are absolutely some obnoxious "you should rewrite this in Rust" folks out there, but this is not a case of that.
There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to".
And regardless, my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.
You seem to think of "rust enthusiasts" as some organized group with a goal of writing Rust for the sake of it. Rust is long past such extremely early adopter phase.
What you're seeing now is developers who are interested in writing a better version of whatever they're already working on, and they're choosing Rust to do it. It's not a group "Rust enthusiasts" ninjas infiltrating projects. It's more and more developers everywhere adopting Rust as a tool to get their job done, not to play language wars.
Nah, I called out redox and another commenter pointed out ripgrep as an even better example of what I’d prefer to see, and those are also by what I would call rust enthusiasts. I don’t think of them as a monolithic group.
Where we disagree is I would not call injecting rust into an established project “writing a better version”. I would love it if they did write a better version, so we could witness its advantages before switching to it.
They are referring to adopting the Sequoia PGP library, which is written in Rust. There are plenty of benefits to using Sequoia which you can investigate now, no need to theoretically wait for the integration to happen. Not coincidentally, the RPM package manager also adopted Sequoia PGP.
First off, the mail references far more rust adoption than just Sequoia, but since you bring it up: here is how RPM adopted Sequoia in Fedora-land. There was a proposal, a discussion with developers about the ramifications (including discussion about making sure the RPMs built on all architectures), and there were votes and approvals. Costs and benefits and alternatives were analyzed. Here's a page that has links to the various votes and discussion: https://fedoraproject.org/wiki/Changes/RpmSequoia
Can't you see how much more thought and care went into this, than is on display in this Debian email (the "if your architecture is not supported in 6 months then your port is dead" email)?
> my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.
That's not how open source software development works.
I wasn't asked by Linus whether ipchains should become the default over ipfirewall nor whether iptables should become over ipchains.
I wasn't asked whether GCC should use C++ instead of C as the language to build GCC itself.
I can go on with lots of examples.
Why should APT be different and require the maintainers to fork their own project do introduce changes? Why should an undefined "community" (who is that? apparently not the APT developers...) decide? Does this have to be done for every code change in APT?
ipchains is a perfect representation of what I want to see. They introduced it as an option alongside ipfirewall in 2.1, made it the default but allowed fallback to ipfirewall in 2.2, and removed ipfirewall in 2.4. That is a sane way to introduce a large breaking change. Not to mention they provided compatibility scripts to try to smooth over the user-side differences.
They certainly did NOT say "I'm replacing ipfirewall with ipchains in six months, and if your distro can't handle it you should sunset your distro."
It shouldn't be controversial to request a measured approach when making major changes to software lots of people depend on. That's part of the burden of working on important software. Note I'm not against apt or anything moving to rust.
If you think a situation where everyone had access to ipchains for 3 years to figure out how to migrate is similar to a situation where some architectures will be killed in six months without ever having had access to the new product then I don't know how to help you. What can affected ports do? Implementing a toolchain backend is a tall order.
We didn't talk about your gcc-to-c++ example, but if you read up on it you will know they took the pulse of affected developers, started experimental branches, made presentations, and made sure no architectures were left behind. All of which this Debian developer is failing to do.
Look I don't even disagree with the ultimate result... I don't think Debian needs to indefinitely support every strange port it has built up over the years. The way it's being done, though, doesn't sit right. There are far more mature ways to steer a big ship. Your own examples are showing the way.
There is no reason for a company like Discord to ever see the ID. The owner of each relevant form of ID — usually a government agency/department — should provide an attestation service, such that users prove their identity to the agency and the agency tells the company "yes, this user is who they say they are".
It's not that hard. Legislators around the world are consistently dropping the ball on this.
Doesn't seem like they did. From the original article I referenced earlier:
One of Discord’s third-party customer service providers was compromised by an “unauthorized party,” the company says. [...] The unauthorized party “did not gain access to Discord directly.”
When governments do things the wrong way around, like mandating age control before they have a method for doing that in a secure manner, what's a company to do?
Good question. I'm not primarily blaming Discord or the other company for this (even though they both obviously share some responsibility, too) — I'm blaming government/legislators. I'm arguing that the government agencies/departments that own the relevant forms of ID should have been required to develop the capability to facilitate this sort of secure ID verification _years_ ago. Instead policy makers ignored reality and rushed through this legislative hatchet job... and here we are yet again. As anybody who's been awake during the last few decades could have predicted.
Tangent: I've regularly been required to provide copies of my ID to all kinds of businesses simply to function in society — i.e. in practice there is no realistic option to opt out. Want to rent a house? X points of ID. Want a phone? X points of ID. Pretty much every real estate agency in town has copies of at least my driver licence. And they in turn share my details with tenant database companies, credit reporting agencies and so on. Do you think many of these businesses have good data handling practices? Of course they don't. And so all my details are available for purchase in bulk data sets on the dark web, and get refreshed by new data breaches every few years. And yet government still treats it as somehow unexpected each time this happens, or wags its finger and bemoans those naughty criminals, instead of developing any kind of policy that would start to address the underlying issue... which is that our personal details are spread so far and wide in the first place.
They can only make a profit if people are willing to buy what they're selling
> Their business is selling hard drives.
Then either they or you are confused. They make the NAS, not the drives. The drives are interchangeable and upgradable, that's the whole point of a hot-swap NAS system.
> I bet a large portion of profits come from that
I think they wanted a large portion of profits to come from that, but most NAS purchasers know that hard drives are a commodity/standardized and won't pay a premium for ... no benefit.
> Then either they or you are confused. They make the NAS, not the drives.
No you are. You don't have to make something in order to sell it. Composing materials is a business. Selling packages is a business.
You may choose to make your own bundles at home, some don't have the time and/or skill to do so.
You're acting like this isn't normal business administration: companies push products, companies adjust offerings depending on demand. Ask Oracle how they're still in business and raking in billions.
> You may choose to make your own bundles at home, some don't have the time and/or skill to do so.
Well clearly enough of Synologys customers decided they did have the time to buy commodity HDDs and slap them into a competitors product, otherwise we wouldn’t be having this discussion.
As GP said, Synology may want to believe they’re in the business of selling premium priced HDDs, with a side salad of NASs. But it turns out that isn’t a very sustainable business, otherwise there would be no reason for them change their policies.
Correct. I never said that it was the right choice, I just said that it was a valid choice for them to make. Lots of companies substantially raise prices and still come up winning.
Netflix doubled their subscription cost since 2008, but market cap did 100x and subscribers are 30x. They even offer fewer good movies than they used to. You may still hate them, but their wallets don't care about your feelings.
> most NAS purchasers know that hard drives are a commodity/standardized and won't pay a premium for ... no benefit.
Also, some will deliberately mix drives from various manufacturers to reduce exposure to potential “bad batch” problems where multiple drives fail in a short space of time (possibly extra failures while rebuilding an array after the first failure, rendering the whole array untrustworthy or entirely broken). This is not possible if you can only purchase from one manufacturer.
I don’t think that’s true. They apparently thought that was their business, but it’s not what their customers think it is. And having that much of a mismatch between what you think you’re selling and what everyone else thinks you’re selling often ends very badly.
For example, Kodak thought they were in the business of selling film. Their customers thought they were a company that sold ways to take photos. Kodak ignored what their customers wanted, the ability to take photos easily, in favor of their desire to sell more film. That cost them dearly when digital cameras took over.
Their business is selling NASes. They don't make special hard drives that no one else makes. Anyone can sell hard drives. Their value in their business is the NAS, not the drives. If they can't survive on their NAS without scamming their customers with marked up hard drives, then they're not really a viable business.
Companies should create value, and capture a fraction of that value.
What Synology did was trying to significantly increase the fraction of value they captured, at the cost of their customers, who would have to pay that, and without providing extra value for their customers.
This is not only a a bad deal for customers, it also triggers our sense of injustice.
The best companies create value, and capture only a part of it, and leave other parts of the value for both customers and partners/suppliers.
This is very different from "I didn't read the instructions on the screen and now I'm calling support". Both scenarios exist. I have some sympathy for businesses facing the latter, and much less for businesses facing the former.
reply