Newsflash: systemd is popular among people with the technical background to be in charge of choosing a daemon and interface manager.
Newsflash, none of the passive aggressive people behind systemd have the technical background to be building such a system and you only need to look at the kernel developers' opinion on that one. It's not like ill-advised software hasn't been pushed before and then hastily retracted in the open source world.
and if the text logs are corrupted (or silently deleted) and assuming your computer can boot properly, how easy is it to read them?
An awful lot easier to get and put back together than binary logs. They will get corrupted under a lot more circumstances.
PSA: Code clarity doesn't have anything to do with making a compiler that outputs slow binaries.
It actually does once you realise the implications of creating a higher level language in the quest for said code clarity and more to the point, developer productivity. That's a trend that should be pretty obvious to anyone who feels qualified to comment on this topic.
LOL, try again. We are talking about server-side JavaScript here!
The worst possible use. JavaScript used for sever software is a perfect example of idiotic web programmers meddling in things they shouldn't be going anywhere near.
No normal person wants to deal with smug, "opinionated", Zed Shaw-inspired hipsters who swear all the time...
It's funny that those are exactly the people who Zed Shaw railed against.
Of course it does. RedHat leads on a lot of products that are upsteam for many of the distributions, in particular Debian. Suse also supports this shift with their products. So yes it is relevant.
PaaS concerns have no relevance to the vast majority of system administrators out there. We require an init system amongst other things that work and where things can be pieced together when things do go wrong. 'Process management' is not a reason for a poorly defined piece of software such as systemd attempting to replace long used and very well tested pieces of software in areas where it has no business being
Do you really believe that RedHat doesn't know what they are doing?
No.
Do you really find that plausible?
Yes. The maintainers of systemd have demonstrated consistently how unresponsive they are in this and other projects.
RedHat is going to be all over security issues.
Past history of the maintainers says otherwise.
Check out he prices for EC2 reserved instances, if you know you'll need that server for 3 years.
If I was committing myself to a server for three years then I'd buy one where all the resources were guaranteed to be mine...... The whole point of the 'cloud' is to get yourself away from long-term commitments, move around your infrastructure and upgrade as necessary. The fact that Amazon, and others, have started doing this to look better against dedicated hardware tells me that things are not sustainable in that castle up in the sky.
Prices are similar per core to buying entry-level Dell rackmount servers with 3-year support contracts. Of course, the physical Dell has more memory and disk than the VM with the same core count, so you come out ahead there if you needs lots of memory, or local disk, but not by a lot.
I don't think comparing and equating dedicated hardware to a transient Amazon instance in a data centre you will never see is a terribly good idea. The whole point of the cloud is to remove yourself from such long-term commitments. I also have a chuckle at any salesperson who starts using doublespeak like telling me how less expensive something is 'per core' or 'per watt'. It's usually a whole load of nonsensical corner cases they've dreamed up.
Once again, missing the point. In my (small) shop, by using azure (which has worked well for us), we avoid having to use money to hire admins to maintain any sort of in house servers we might have.
Who maintains your Azure infrastructure (I hope you built in all that lovely redundancy for these problems) and how often do you really need to maintain internal servers? If these are on 24x7 you're going to be paying through the nose and if you miss a monthly fee, off you go. Not to mention that cloud servers are horrifically under resourced compared to hardware you can buy, so you generally need many more of them, and none of the bandwidth, I/O or CPU resources are guaranteed to be yours no matter what your meaningless agreement says.
We can then put that money towards more developers (or better salaries for us current devs), as well as paying for training, nicer dev machines, etc.
Ahhh, yes. Developers who believe deployment can be bypassed as a cost and running applications in production (which is kind of important to any company running web applications and who relies on them for income) simply doesn't matter.
At the same time, if we do have a problem with any sort of hosted service through azure, support is literally a phone call away, and I can't remember the last time a resolution didn't happen within a couple hours.
You've been exceptionally lucky, or you're being economical with the truth
Sure, cloud computing has its short-comings. But it has also allowed a litany of small companies who simply can't afford to own their own infrastructure to do business.
I've also seen a litany of small companies go out of business with cashflow issues who thought like that. Funny that. Yes, the infrastructure is cheaper if you don't run it all the time. I think I once calculated that if you have a server on for more than eight hours a day then you're simply being milked for a monthly fee.
This file will self-destruct in five minutes.
