Why would anyone encourage building such a tool, I can't fathom.
Why would anyone encourage building such a tool, I can't fathom.
Is that what developers at your company cost?
Just curious. In Sweden the average devops salary is around 60k.
> you are dedicating 2 resources 3 times a month and this is already costing you ~38k/year on salaries
Ok. So we're currently saving more than 400k/year on our migration. That would be worth 38k/year in salaries to us. But note that our actual salary costs are significantly lower.
> that's assuming your engineers have somehow mastered_both_ devops and software (very unlikely)
Both me and my colleague are proficient at operations as well as programming. I personally believe the skillsets are complimentary and that web developers need to get into operations / scaling to fully understand their craft. But I've deployed web sites since the 90s. Maybe I'm a of a different breed.
We achieved 4 nines of up time in our first year on this platform which is more than we ever achieved using Heroku + other managed cloud services. We won't reach 4 nines in our second year due to a network failure on Hetzner, but so far we have not had downtime due to software issues.
> This also assumes your infra doesn't grow and requires more maintenance
In general the more our infra grows the more we save (and we're still in the process of cutting additional costs as we slowly migrate more stuff over). Since our stack is automated we don't see any significant overhead in maintenance time for adding additional servers.
Potentially some crazy new software could come along that would turn out to be hard to deploy. But if it would be cheaper to use a managed option for that crazy software we could still just use a managed service. It's not like we're making it impossible to use external services by self-hosting.
Note that I wouldn't recommend Reclaim the Stack to early stage startups with minor hosting requirements. As mentioned on our site I think it becomes interesting around $5,000/month in spending (but this will of course vary on a number of factors).
> Focusing on building features and generating revenue is much valuable than wasting precious engineering time maintain stacks.
That's a fair take. But the trade-offs will look different for every company.
What was amazing for us was that the developer experience of our platform ended up being significantly better than Heroku's. So we are now shipping faster. Reducing costs by an order of magnitude also allowed us to take on data intensive additions to our product which we would have never considered in the previous deployment paradigm since costs would have been prohibitively high.
Well there's salary, and total employee cost. Now sure how it works in Sweden, but here in Belgium it's a good rule of thumb that an employer pays +- 2,5 times what an employee nets at the end after taxes etc. So say you get a net wage of €3300/month or about €40k/year ends up costing the employer about €100k.
I'm a freelance devops/sre/platform engineer, and all I can tell you is that even for long-term projects, my yearly invoice is considerably higher than that.
I've found Multipass https://multipass.run/ by Canonical and I wonder if anyone recommends it.
Time Warner has recently moved towards "unifying all their streaming platforms" which meant that a lot of adjacent services will close/migrate to Discovery+ directly.
I am someone that suffers the fallout of them shutting GCN+ down, which gives me about two weeks to watch around 100 cycling documentaries that the GCN people have put out in the past 3-4 years. Granted I haven't paid for them individually, so it's not as painful as for the Sony customers, but they will be shutting down access to all of them without any backup plan and without a look back.
The people at GCN seem to be as baffled as everyone else about this move. Luckily they still have a good presence on their Youtube channel where they have more accessible content.
Sorry but if you allow your platform to sell 3rd party content, you better have some consumer protections built-in in your contract with that 3rd party in case of such a scenario.
You won't get the chance to refuse this feature. There'll be too much money at stake for manufacturers to not retool for it. It'll be the only thing they make to sell, so take it or leave it chump.
I also see a lot of FUD from the Prusa community regarding that particular brand, where you can't claim it's a 1:1 Prusa clone. Even the remarks from Josef Prusa about speed or noise are targeted to the X1C or P1P printers while if you want to talk about clones and copying there are brands out there that fits the bill better e.g. Sovol 06.
The part where you can only sell "consumables" that must be verified by Prusa also has zero to do with open source or freedom.
On top of that, people still building an i3-design printer from scratch is rare, the hobbyist design community has moved on to the Vorons, which means pretty much all printers with this design are from companies with zero community interaction, profiting from the Prusa investments. So I get why they're not happy.
The only real comparison you have with Prusa is the much less popular RatRig - which is still an opensource design afaik, but I'm not aware of any clones of those.
Binary compatibility solutions mostly target cases where rebuilding isn't possible, typically closed source software. Freezing and bundling software dependencies ultimately creates dependency hell rather than avoiding it.
Look at the hoops you sometimes have to jump through or hacks you have to apply to make something work on Nix, just because there is no standardization or build processes assume library locations etc. And if you then raise an issue with the software maintainer - the response is often "but we don't support Nix". And if they're not Nix/Nixos users, can you blame them?
If you've ever had to compile a modern/recent software package for an old distro (I've had to do this for old RH distro's on servers which due to regulations could not be upgraded) - you're in a world of pain. And both distro and software maintainers will say "not my problem, we don't support this" - and I fully understand their stance on that, because it is far from straight forward, and only serves a limited audience.