it should probably stay in docker containers
it should probably stay in docker containers
What are you even talking about? systemd is currently under an opensource license, they cant retroactively change that. Any changes would be for it going forward if it is even possible for them to buy the rights to it (which I’m not convinced it is as Lennart Poettering is not the sole contributor and Red Hat / IBM and many others also have a significant stake in it). Sun patented Java on it upon its creation and when oracle bought sun, they bought the rights to those patents. They aren’t comparable situations. Java was never open source, it was source available, but still proprietary.
Its certainly easier to read than most old init scripts and I can see why some distros and openbsd would pick it over systemd for more control. I’m not likely to pick a distro that uses it anytime soon, but i can see why some do.
That is my point, they have tried and failed completely before when their main product was windows licenses. Now, linux is incredibly important to their azure business, they wouldn’t want to potentially cause detriment to that and is far more important to them than windows licenses.
Also why would we have to rip out systemd, even if they tried to claim ownership of it and make it proprietary, it could be forked from before the license change and we would keep on going like nothing happened.
people keep saying this, but what is their extinguish plan? how could they realistically extinguish linux? it’s not a company they can buy, or even a single thing they can ruin.
can you give examples of some? Not trying to bd sarcastic, i do just want to see what alternatives are doing.
depends on how many services you plan on running, i think the i3 would be sufficient for what you listed, the i5 would give you room to grow.
the i7’s usually aren’t worth it for servers since they are just a clock speed increase.
AWS has multiple teirs of storage options in s3, some replicate and some dont. by default those that do replicate do so in multiple availability zones, but not across regions. unless you turn on cross-region replication (CRR) which is an additional charge.
So, for example without CRR if your bucket is in us-east-1 and 1 availability zone goes down you can still access the data, but if all of us-east-1 is down, you cannot.