> Sure, but a reasonable user would expect that condition to be implicit in using a commercial model.
In fact, adding it might make things worse as it shows at least some awareness of the risks.
7,791 karma · joined October 29, 2018
Don't try to contact me on other social media, I'm not active and will usually not read it.
Always open to connect: meet.hn/city/de-Nuremberg
In fact, adding it might make things worse as it shows at least some awareness of the risks.
The obvious use-case is if the result depends on a state and the state has changed since the job has started. Examples would be updating the landing page when a new article has come in (you don't need the outdated landing page w/o the new article) or if you did a code change while compiling (assuming it's not a commit).
AI 2040: Plan A - https://news.ycombinator.com/item?id=48848425
AI 2040 and the cult of intelligence - https://news.ycombinator.com/item?id=48874200
What would this bet be? Training is expensive and open weights mean that for hosting you compete on price with people that don't have this item on their bill.
Security. Imagine commit #1 introduces a security vulnerability (backdoor) and the features. Then #2 introduces a non-obvious, harmless bug and closes the vulnerability introduced in #1 [0]. At some point, the bug will surface and rolling back commit #2 will be an easy fix, re-introducing your bug.
Alternatively, one of the earlier commits might, for example, contain credential dumping code. Once that commit is mainlined, CI might either automatically run on it or will be able to be run on it since it's no longer marked as unsafe PR.
[0] Think something like #1 introduces array access and #2 adds a bounds-check in a function a layer above - a reviewer with the whole context will see the bounds check and (possibly) consider it fine, but to someone rolling back a commit the necessity will not be obvious.
In a perfect world, we could send all traffic completely unencrypted and never scan for a malicious payload, saving all that energy and hardware. But we do not live in that world and drawing the line with this minor, mostly unintrusive security feature seems strange.
Fun fact, for single exhaust cars, the exhaust will usually be on the driver side, in order to route around the fuel tank :-)
This, and also startups are quite heterogeneous. If you have an engineer on your team with experience in hosting their own servers (or at least a homelab-person), setting up that service with sufficient resiliency for your average startup will be done within one relaxed afternoon. If your team consists of designers and engineers who hardly ever used a command line, setting up a shaky version of the same thing will cost you days - and so will any issue that comes up.
That being said, the cloud does have a lot of advantages:
- You're getting a lot of services readily available. Need offsite backups? A few clicks. Managed database? A few clicks. Multiple AZs? Available in seconds.
- You're not paying up-front costs (vs. investing hundreds of dollars for buying server hardware) and everything is available right now [0]
- Peak-heavy loads can be a lot cheaper. Mostly irrelevant for you average compute load, but things are quite different if you need to train an LLM
- Many services are already certified according to all kinds of standards, which can be very useful depending on your customers
Also, engineering time and time in general can be expensive. If you are a solo entrepreneur or a slow growth company, you have a lot of engineering time for basically free. But in a quick growth or prototyping phase, not to speak of venture funding, things can be quite different. Buying engineering time for >150€/hour can quickly offset a lot of saving [1].
Does this apply to most companies? No. Obviously not. But the cloud is not too expensive - you're paying for stuff you don't need. That's an entirely different kind of error.
[0] Compared to the rack hosting setup described in the post. Hetzner, Linode, etc. do provide multiple AZs with dedicated servers.
[1] Just to be fair, debugging cloud errors can be time consuming, too, and experienced AWS engineers will not be cheaper. But an RDS instance with solid backups-equivalent will usually not amortize quickly, if you need to pay someone to set it up.
If you still want to avoid the comfort of typing in stuff manually or navigating the webinterface, logging in on a new tab and then clicking on the link is also an option.
There is, just read TFA.
> Financial transactions happen all the time and are plenty cheap, they just don't do any with sanctioned entities.
And that's exactly the point. They are cheap because people are protected by the corporate veil (as long as they don't explicitly do something highly illegal). Anything where people are suddenly personally liable, they stay far away from. If we apply the same harsh punishments to all financial crime as we do for interacting with sanctioned countries, people will stay far away from interacting with that and those that don't will either demand truck loads of money or also be shady in other ways (most likely both).
> Nobody would claim such BS in good faith.
Someone reading my comment in good faith would have been able to see the point that I was making, which actually is pretty distinct from what you appear to be arguing against.
The problem is that it works too well. As you can clearly see, the solution basically everyone individually applies is to stay clear of anything that might be an issue by several miles.
If you apply the same reasoning to things like private data handling, little things like just shipping stuff will be prohibitively expensive, as no one will want to handle private data like addresses and instead go to a provider, which will need excessive amounts of cash and red tape to do anything for taking on that liability. Building stuff will become impossible, as all of the current red tape will be exponentially expanded with liability checks against any possible pollution. Founding a company will basically never happen, because no one wants to risk 20+ years in jail - and if they do, they'll simply turn to crime, because if your risk profile is that off anyway, not paying taxes will just be a minuscule risk increase.
I'm not saying that there's no political incentive to ignore those issues and keep fines low, but piercing the corporate veil is the nuclear option and there is a reason it's used so little.
Plus, we're most likely talking about Gigabit networking here, so unless your workload consists of very parallel random access, this is going to be the limiting factor anyway.
I'm not sure that's much of an achievement, to be honest. If you tried it and it turned out to be not useful for you, fine, I'm on your side. But refusing to try for the sake of it seems backwards. I mean, then why use CI, version control and those fancy IDEs anyway? Notepad is a perfectly cromulent text editor (and what is code, if not text, anyway?) and my local build.bat and deploy.bat do their job nicely and quickly.
> - Redistribution of wealth
We can talk about excessively wealthy individuals all day, but I'm pretty sure that most knowledge workers are not going to be on the receiving side of wealth redistribution. This is even more likely to be true for the programmers affected by these tech layoffs.
This is really just a cheap rhetorical trick. Linux [0] can run just as much software, if you include VMs, but you can't legally virtualize MacOS, therefore buying a Mac is the only way to legally run their software, in addition to everything else. Now, you are technically correct, but the casual interpretation of
> Eh, macOS is still the UNIX with the most commercial software available.
isn't really that you can simply run everything unavailable on MacOS in a VM (or several layers of VMs). It's the same as arguing that Powerpoint is all you ever need, as it is Turing complete.
[0] And so can Windows, if you run said VMs in a Linux VM.
It might, but in this case it is preceded by "This is why", which makes the sentence as a whole simply wrong.
This is quite dependent on the games you play. Modern games are becoming larger, which makes the project overall more serious and makes it harder to hide easter eggs. That being said, Indie games with small teams still contain a lot of fun and even AAAs can still contain some goodies.
I don't think this applies in most situations. If you have been part of the original core team and are rewriting the app in the same way, this might be true - basically a lost code situation, like the author was in.
However, if you are doing so because you lack understanding of the original code or you are switching the stack, you will inevitably find new obstacles and repeat mistakes that were fixed in the original prototype. Also, in a real world situation, you probably also have to handle fun things like data import/migration, upgrading production instances and serving customers (and possibly fixing bugs) while having your rewrite as a side project. I'm not saying that a rewrite is never the answer, but the authors situation was pretty unique.
Is there any reason to use operator% instead of a normal method call? Except possibly looking cool, which doesn't seem useful given that the call is hidden away in a macro anyway.
The only effect will probably be increased EV adoption, but that's something we generally want and need to prepare for anyway.
"There might be an option in the future if there are sufficient users" is a quite different milestone compared to fully switching away from US-based services.