Readit NewsMost libraries that use dirs-rs are doing so because they don't want to have to think about those things. So if there were a library that did it right, you'd probably have decent adoption if it's a simple crate replacement.
Features aren't pokemon you don't have to catch them all.
Back when stackoverflow was cool and they talked about their infrastructure, they were running the whole site at 5 9s on 10-20 boxes. For a setup like that k8s would have A) required more hardware B) a complete rewrite of their system to k8sify it C) delivered no additional value.
k8s does good things if you have multiple datacenters worth of hardware to manage, for everyone else it adds overhead for features you don't really need.
B) Why on earth would you need to do that? K8s is, at its core, just a thing that runs containers. Take your existing app, stick it in a container and write a little yaml explaining which other containers it connects to. It can do many other things, but just...don't use them?
C) The value is in not having to develop orchestration in house. They already had it so yea, I wouldn't say "throw it out and go to k8s", but if you're starting from scratch and considering between "write and maintain a bunch of bespoke deployment scripts" and "just spin up Talos, write a few yaml files and call it a day" I think the latter is quite compelling.
I know SaaS businesses that don't as they operate in a single country, within a single timezone and the availability needs to be during business days and business hours.
> easy rollbacks
Yea, I haven't seen exceptions at all on this. So yea.
> server fault tolerance
That really depends. Many B2B or internal apps are fine with a few hours, or even a day, of downtime.
> service isolation
Many companies just have one app and if it's a monolith, then perhaps not.
> Hand-rolling even one of those things
Wow, I see what you're trying to say and I agree. But it really comes across as "if you don't use something like Kubernetes you need to handroll these things yourself." And that's definitely not true. But yea, I don't think that's what you meant to say.
Again, it depends
For context, I work in exactly that kind of "everyone in one time zone" situation and none of our customers would be losing thousands by the minute if something went down for a few hours or even a day. But I still like all the benefits of a "modern devops" approach because they don't really cost much at all and it means if I screw something up, I don't have to spend too much time unscrewing it. It took a bit more time to set up compared to a basic debian server, but then again, I was only learning it at the time and I've seen friends spin up fully production-grade Kubernetes clusters in minutes. The compute costs are also negligible in the grand scheme of things.
What costs are you talking about? Packaging your app in a container is already quite common so if you already do that all you need to do is replace your existing yaml with a slightly different yaml.
If you don't do that already, it's not really that difficult. Just copy-paste your your install script or rewrite your Ansible playbooks into a Dockerfile. Enjoy the free security boost as well.
What are the other costs? Maintaining something like Talos is actually less work than a normal Linux distro. You already hopefully have a git repo and CI for testing and QA, so adding a "build and push a container" step is a simple one-time change. What am I missing here?
All the stuff Erlang does.
Static linking and chroot.
The problems and the concepts and solutions have been around for a long time.
Piles and piles of untold complexity, missing injectivity on data in the name of (leaky) abstractions and cargo-culting have been with us on the human side if things for even longer.
And as always: technical and social problems may not always benefit from the same solutions.
Congrats, you've just rewritten half of kubernetes in bash. This isn't reducing complexity, it's NIH syndrome. You've recreated it, but in a way that nobody else can understand or maintain.
Need AWS, Azure or GCP deployment? Ever thought about putting it on bare metal yourself? If not, why not? Because it's not best practice? Nonsense. The answer with these things is: it depends, and if your app has not that many users, you can get away with it, especially if it's a B2B or internal app.
It's also too US centric. The idea of scalability applies less to most other countries.
I wonder if it changes with time for people who use dictation often.
Similarly, I've used dictation when working on something physical, like reverse engineering some hardware, where my table is full of disassembled electronics, I might be carefully holding a probe or something like that, and having to put everything down just to write "X volts on probe Y" would slow me down.
If they simply wanted age verification, the dumb and lazy way is to SSO through a government managed portal with OAUTH2 and you only share your age with the third party. You do a one time account setup (you already have to do this in the US for many government services at the federal level) with age verification, that's your gov portal login. This means the government will now which naughty sites you visit of course, but like I said, it is the lazy approach, and if you think about it, if they respect the laws then a law can be passed to prevent them from storing or using that association, if they didn't, they could still sniff your traffic and wiretap you.
A slightly smarter approach would be to directly auth against a government portal and be given a 24h expiring code for age verification, and the government will publish an updated list of codes to trusted businesses. Those codes could be leaked, but making it a felony should deter most cases, because who wants to go to prison to let some kids watch porn?
Smarter people than me can come up with smarter solution, that is really my point. Involving third-parties and requiring you to upload documents is done either out of extreme incompetence or opportunistic malice by elected officials (bribery).
The "24 hour code" one you suggest is something the EU is prototyping. Since there's nothing stopping an adult from sharing their code with a minor, or even code-sharing (or selling) websites to pop up, they want it to be bound to a particular device. So what they've done is added integrity checks to the app, so you can only run it on a locked down phone.
Want to run GrapheneOS for privacy and security? Or use an unofficial ROM to get updates on a phone the manufacturer stopped supporting? Just want to uninstall the bloatware and spyware the manufacturer installs? Want to use Linux? Have an old computer without a TPM? All of that and more - congrats, no "adult content" for you.
And no, it's not "porn", it's "adult content", which is a much broader and blurrier category. Is discussion of sexual orientation or gender issues adult content? Sex education? Medical information about "private parts"? News articles mentioning scary things like rape?
This is bad technology and it should never be developed. Do Not Create The Torment Nexus.
When writing the files, check the old location first, fall back to the new one. When reading, check check the new location first, fall back to the old one.
The app does not need to migrate anything. Using the algorithm described above, new installations will automatically use the new paths, old installations will continue using the old paths, but can optionally be migrated at the user’s convenience.