Exactly. It makes no sense. The author of the article states the idea came from his article on systemd. Eh? I'm not sure he is saying that systemd is for desktops or servers. He never says if systemd is useful at all. Things like geard (RedHat/OpenShift) and fleetd (CoreOS) specifically use systemd to orchestrate container deployments. Cool stuff.

RedHat 7 ships with systemd. But, but, but, we all know that RedHat totally and completely abandoned the desktop years ago.

So we have two options. Either systemd is not just for desktops or RedHat never completely abandoned the desktop. Either way, there is no need to split distros. RedHat does provide a nice tool called 'tuned' that helps tweak kernel and system parms for desired load.

Then I guess I'm not in my right mind.

I like Fedora a lot. I like the desktop environment (Gnome3 has really grown on me). Fedora moves at a decent clip to track with the latest and greatest without a lot of hassle. I have always liked RedHat/Fedora's PXE/kickstart installer. I like the big projects RedHat/Fedora is working on like FreeIPA, OpenStack packaging, GFS2, KVM, OpenLMI, CloudForms, and oVirt. RedHat has spent a lot of money buying some of the companies that created some of that software and the turn around and open source all of it. FreeIPA is a big one. A seriously great project that took old code from Sun/Netscape and made it usable.

I know the big gripe is systemd, but so far I like it. It makes writing start/stop/status configuration easy and reliable.

Did you know that systemd will run standard sysV scripts? You could have done that. If you were making your own script. I don't know why you would want to make your own script since the package includes one.

Did you notice the line above ExecStart? EnvironmentFile= points to a possible place that IRQBALANCE_ARGS is located. This is a normal place for things like that in a RedHat/CentOS/Fedora system. Nothing new here.

Since you wanted apache to start up at boot, did you try '/sbin/chkconfig httpd on'? This is the normal RHEL/Fedora way. It will *tell* you the systemd way when you run it on a systemd system (Note: Forwarding request to 'systemctl enable httpd.service'.)

Maybe you aren't familiar with the RHEL tools and filesystem layout?

RedHat has options for you. There is Software Collections that package multiple versions of python and ruby. The versions can be pivoted at will. Then there is Docker in RHEL7 which allows shipping of containers as apps. Not to mention Fedora is heavily supported by RedHat and offers very recent packaging of almost everything.

PPA's are similar to adding a -release package to Fedora/RedHat/CentOS. So for example, I was to add EPEL to my repos. I just click on the epel-release rpm and it installs it. I'm not so hip on the Software Center. I like to stick to core debian tools when using a .deb-base system.

Unfriendly package manager? I thought this argument is over. Yum (moving to dnf) operates in a similar way to apt-get.

We are an agile shop. We have pair programming, continuous integration, and continuous delivery to AWS. The pipeline runs RedHat. We have also have some CentOS.

Fedora is not a bone, it is a great way to know what is coming in RHEL. CentOS (which RedHat supports) is a great server distro for everyone.

CentOS is great! They have done a great service to the Linux world. Even more awesome is that RedHat now supports the project!

The tension is stability versus the latest tech. RedHat purposely moves very, very slowly. The same can be said about Debian stable. As an admin I like slow moving targets. The problem is that developers want to use the latest stuff. So what does RedHat do about this? I think they are trying to solve it in two ways. First is their Software Collections. These are packages that site outside the base OS and are easy to pivot to the newer version. This allows for multiple versions of things like Python to be installed in parallel. Very handy!

Another thing that is helping quite a bit is Docker. RedHat is big on Docker. By packaging containers as apps, this allows a developer to easily control the dependencies outside of the OS that the app is running on. This makes everyone happy! Fedora is tracking some interesting tooling with Docker (geard, os-tree).

I like that RedHat tries to solve bigger problems than just packing and releasing a distro. They are trying to make things manageable (see FreeIPA, OpenLMI, RDO, CloudForms, oVirt)

Personally, I like RedHat. I like Debian. I run Fedora on my desktop and notebook. I maintain a CI/CD pipeline on RedHat at work. I never jumped on the Ubuntu bandwagon. It seems to me that Ubuntu has made quite a few more mis-steps in their short existence than RedHat has over the years. I get the feeling that a lot of people are just dropping back to Debian, which is just fine with me!

Thanks for this! Both you and the previous poster explaining BGP. So many people have misconceptions on how the Internet works. Then there is the added complexity of business.

I really proves nothing that Netflix over a VPN is faster than without a VPN. We already know Verizon-Level3 peering is saturated. Both sides have admitted it. It comes down to how to solve the problem. It is not a technical problem. It is a business problem

So what if Level3 offers to pay for the upgraded link. If the existing agreement is settlement-free upgrading the link will likely push the traffic exchange outside the agreement. So if Level3 starts sending more traffic than it received from Verizon, then they should pay Verizon for transit of that traffic. Verizon has probably told them that. Level3 comes back and says, "But we'll pay for the upgraded equipment." Verizon says, "So what? If the traffic isn't equal, then you pay." And on and on it goes. So, as stated above, the best thing to do is for Netflix to create peering connections with Verizon that have no expectation of equal traffic. They will have to pay Verizon for these connections.

This is NOTHING new people. This is how the Internet has always worked.

That is exactly why I don't think complaining to the FCC will solve the problem. Just the opposite, it could make it much worse. It is much better to work at the local level. Push for more competition at the local level. Not city owned fiber, but companies like Google that can come in a put in their own fiber. This is where the real action is.

Actually... successful farmers do need to keep up with the latest and greatest and evaluate cost/benefit of those advances. I really hate that people think that farmers are idiots. The ones that are, went out of business years ago.

Maybe you should have read to the end of the article. Just saying. To quote: "If Comcast’s last-mile of cable connection was available to all competitors under the same terms that gave dial-up service providers access to all copper telephone networks back in the 1990s, we would have more ISPs in more geographical areas. "

Fast lanes allow the little guy to have more bandwidth! Less congestion on large backbones is good for everyone. I think the article is exactly right. People have an idea in their head on how the Internet works, but it is not practical or real. Even the little guy can select a colo for a reasonable cost based on the peering of the colo. The is no reason for every little startup to have peering because they just don't have the demand yet. Their transit bandwidth and costs are fine for the time. When they get larger, they could use 3rd party CDN's, then their own CDN, etc, etc.