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.
Explosive machine gun rounds from the cannon would cause larger holes, not smaller ones.
No they wouldn't, because it depends on where they explode, if at all and there were entry and exits. Keep digging though. This simple shrapnel assumption is rather curious given what has been found: http://www.anderweltonline.com.... The cockpit area was certainly hit by something very, very different than shrapnel.
The pictures of wreckage we've seen show the latter, not the former.
Nope, they don't. However, good luck getting pictures of evidence of cannon fire: http://www.anderweltonline.com...
Just as important, we know the rebels were operating air-to-air batteries in the area...
No, we don't. Hearsay from CNN etc. doesn't count here.
Yes, it's called "shrapnel".
Nope. These were clearly defined as clean holes, in one end out the other. Shrapnel is much more haphazard.
Because cannon fire has a minimum size of the puncture it can make, the size of the shell. The resulting marks on the aircraft will be a circle of that size, given a nice face-on strike, or elongations if the angle was more glancing. It can get much larger if the metal tears.
Now look at the image. There are many, many holes in the aircraft that are much smaller than a cannon shell. In fact, there are quite a few that are exactly the size of a piece of shrapnel.
Look at what image? I didn't quote one and you certainly haven't either even though you refer to one, although there are suspiciously not as many to look at thes edays. Claptrap.
http://www.anderweltonline.com...
So that's why "west no one seems to want to even entertain" the idea, it's clearly false.
No, our western governments are not immune to propaganda themselves, as much as that may shock you. But feel free to stop questioning, your government has your best interests at heart and keep sucking in whatever you watch on Fox, or CNN or whatever. Keep hold of the comfort blanket.
No. Systemd supporters give plenty of technical reasons for their support. In my case (for one thing) it is wanting event based processing of service management. Systemd offers that, sysV rc doesn't. Like it or not, that's a technical reason.
I don't. I'm a sys admin and I don't believe that adding that required a completely new init system that has now morphed into something altogether very, very different that I will have to pick up the pieces on. Sorry, not a valid technical argument but then these things get very tricky for people because they can't actually pin down what systemd is supposed to do.
On the other hand, you anti guys keep bringing up things like this shit, or 'not Unix philosophy'...
I don't know if you brain cells have noticed, but Linux was built by Linus from the kernel on up with a Unix philosophy in mind that has served it very, very well in the server world and the functions it performs. After many decades of that philosophy and the lessons learned from it you would think people would have learned what does and doesn't work, but apparently not.
'monolithic hairball'. Those are not technical arguments.
Given that it's an extremely core piece of software then I'm afraid people are justifiably concerned about a monolithic piece of software with poorly defined goals and requirements that they'll have to end up supporting when its maintainers tell us all a security issue isn't their problem to fix. Sorry, but that very much is a technical argument, as well as one of maintainership. systemd fails on both counts.
Do me a favour, and refrain from answering until you can actually muster a technical argument against systemd.
I find that extremely funny coming from some moron who puts 'Unix philosophy' in quotes and nonchalantly dismisses decades worth of hard, hard lessons learned and quite obviously hasn't the faintest idea about working with a Linux system. But then, that's what we've come to expect isn't it?
So you think that money is the root of all evil. Have you ever asked what is the root of money? -- Ayn Rand
