Because it's end-to-end encrypted for just the people in the chat. Slack and Hipchat store the logs in the clear for themselves and the contents could be revealed if they were ever hacked. Since they're also centralized this poses an issue because they're an easier target than say a member of the chat's device.
Since keybase is all encrypted, signed, and authenticated the fact it's centralized only matters as far as the service going down, but the content is all secure.
What is so great about RH? When i had opportunity to use it, it look so bad mostly because lack of current/decent software in repo. Maybe their support is amazing?
Yes, support and peace of mind. Packages that make it into their repository are fully tested and supported by RH. Almost all of them are old but they are pretty much guaranteed stable and Red Hat will support the software until the EOL of whichever RH version you are running, even if the developers of the package do not support a version of the package anymore.
Sometimes being old is a double edged sword. For instance, RHEL7 has a lot of problems on AWS because the kernel is too old to properly support many of the virtualisation features AWS provides. On bare metal RHEL7 is great, though.
Hey sure, I should have been more specific. The enhanced networking in AWS requires ixgbevf at least version 2.14.2. In addition we had random hardlocks with ext4 under the centos7 kernel. Also we had a lot of difficulties running docker on EBS disks with the device manager driver - hard lock ups randomly. That's all I recall off the top of my head. All these issues disappeared upon moving to Ubuntu 16.04 on a later kernel. Centos7 was great for us otherwise, it just didn't seem to work out so well with Docker + AWS.
Red Hat is pretty good about back-porting features like this into the kernel and rest of the platform. It would surprise me if the issues you describe aren't on the roadmap to address.
I work for a company that sells software which runs on top of Red Hat/CentOS servers. As a result, sometimes we have to tell our clients that the issue is on the server level and that they need RH to take a look at it, assuming they're paying for Red Hat support.
FWIW, I've never heard any of them complain about Red Hat. I've had plenty of them complain to me that I'm sending them to RH instead of fixing their server for them (because that's what software engineers should do, right?), but they've never once complained to me about RH once they reached out.
I think this is a myth, or at best relative, not all enterprises accept old for stability
Many enterprises want up to date and stable software, and since you are paying for stability, why shouldn't you get fairly recent and stable software
Most companies for example don't consider MS SQL 2016 as less stable than MS SQL 2008 or 2012, most users expect the same level of stability from the latest SQL Server than from earlier version, if not more because it's newer and more advanced, might as well be more stable
I didnt use RedHat in a while, so I dont know how bad the situation is , I hope it is not too bad
Nobody running a thousand of anything uses the first release of $X, whether $X is a database or window manager or kernel or router firmware
SQL Server 2016 may be better than SQL Server 2008, but enterprises aren't deploying it until it has baked a few months, and maybe sp1/sp2/some major rollup ships for all the bugs the suckers find at rollout
I have software that I need to run for about 5 years. It is certified on Red Hat Linux 6 not 7. I'm not unique. Heck, we had to keep copies of IE 6 running up until a year ago for one testing vendor[1]. I, like a lot of others, need stability and paperwork not new.
Frankly, having a lot of new companies adopting a mantra of "move fast, break things" makes me want to 'upgrade' less and less. I need stuff working at Monday at 1PM for the weekly test offering not some oops.
1) deep freeze or virtual machines are your friend.
With things like Software Collections and IUS you get to run the latest stuff on a rock-solid base. I don't want to upgrade my kernel to get a newer Python or NodeJS release!
Software Collections are honking great, I'm actually looking at moving one of my Python 3 apps from Fedora to CentOS purely because it requires a version of Firefox that supports the Java plugin (selenium script that has to use a page with a java applet...) - since RHEL/CentOS stick with ESR releases I'll at least have 18 months to hope the applet goes away.
Ditto this. We run the power grid on RHEL and the latest and greatest features are far down our list of wants. Stability, security, and support; yeah, we'll take those. ;)
I support both Ubuntu LTS and RHEL in production (multiple releases each) and RHEL has been rock-solid for years while there's constant trouble with Ubuntu.
