81–90 of 154 posts
It's true that the guidelines call for original sources (https://news.ycombinator.com/newsguidelines.html) but we sometimes make an exception for corporate press releases, which tend to use obscure language, omit relevant information, and so on.
Earlier quoted context omitted.
They're still quite popular in Europe and especially in Germany whereas Redhat has utterly dominated North America.
Afaik one big reason for this is that SAP supports only Suse with on-prem installations.
https://wiki.scn.sap.com/wiki/display/ATopics/Supported+Plat...
Earlier quoted context omitted.
We're in the same camp with a cluster ~2x as large for Squawk[1] and it would cost us many multiples in the cloud (excluding our TURN relays which aren't k8s). However, the one killer feature that the cloud still has over self hosted is the state layer. There is nothing that comes close to the turn key, highly available, point in time recoverable database offerings from the cloud providers. We're running Spilo/Patron…
Why did you keep your TURN relays out of k8s?
But all of our APIs sit in one k8s cluster across two datacenters (Hetzner, with whom we couldn't be happier).
This is a good acquisition. I was thinking that AWS would acquire Rancher to make inroads into multi-cloud and hybrid kubernetes.
AWS has a case of not-invented-here syndrome that is so severe that it doesn't technically qualify as NIHS. For one thing, NIHS requires you to accept that there is such a place as "not here".
Well congrats to the team for the exit. But I am really hoping that this will continue the great momentum that Rancher has. I've come to quite enjoy Rancher products. I think the work they are doing is fantastic and lowering the bar for entry into Kubernetes, especially for on-prem/bare metal. Just deployed 4 production RKE clusters on bare metal and also using K3S.
One more good experience. I created an cluster of dedicated servers ( 64 cores, 6TB of SSD storage and 256 GB of RAM, 1 GPU) using Rancher, for about 250 Euros/Month. This would cost at least 2k in a cloud such as AWS. There is a post about how I did with persistent storage here ( https://medium.com/@bratao/state-of-persistent-storage-in-k8... ) It really transformed my company DevOps. I´m VERY happy. If you can, use…
At first look the numbers in the colourful table near the end, Piraeus/Linstor/DRBD seems 10x faster than Longhorn 0.8. The article goes into great depth of the (a)synchronous replication options of Piraeus, but doesn't mention that Longhorn always does synchronous replication. I wonder why?
SUSE being full into btrfs and CEPH, I wonder if they will allow Yasker https://github.com/longhorn/longhorn/graphs/contributors to continue developing. At Kubecon EU & US 2019 https://youtu.be/hvVnfZf9V6o?t=1659 Sheng Yang explains how he tried to make Longhorn first class citizen Kubernetes Storage.
Earlier quoted context omitted.
You can buy an "inferior competitor" and integrate their feature set into your own products, and end up with a much better integrated solution for your customers, which will strengthen your business. But switch "inferior" to "superior" and your question makes sense. Red Hat's products mostly suck balls. I can't think of a single one which has been an enjoyable experience to use. People paid for them because they were…
Or people just trust Red Hat for being always "heart, mind and soul" of the community of contributors that makes open source great. And keep doing the same thing, that inspired many others such as SUSE, Rancher, etc.. and IBM :)
Heart, Mind and Soul of the Open Source community is possibly a bit of hyperbole.
and - SUSE is (slightly) older than RedHat, so I am not sure you can say RedHat inspired them :)
IBM was inspired by RedHat's earnings (pre acquisition, open source in IBM was .... interesting ... ) and their ability to have a relevant product in the cloud space.
Another great product acquired by a mediocre behemoth. Here's hoping they can maintain enough independence to continue innovating.
The engineering team inside SUSE are exceptional - they do amazing things, and build really interesting features. The product planning / joined up thinking / visionary direction is where they fall down. As a sibling pointed out they have worked on some really interesting stuff, but (when I was there in any case) failed to pull it together into something that could have been outstanding.
Earlier quoted context omitted.
It takes away privileges which arguably is a good thing but some things that require root containers wont't run. They pass the Kubernetes conformance suite only by removing those constraints.
And you can do the same for your environment. You can run root containers on OpenShift, it's a settings, not a baked-in compiled choice or something similar.
Earlier quoted context omitted.
> If you want to use standard tools it’d be nice to have a managed standard Kubernetes option What standard tool doesn't work on OpenShift? It's certified to have 100% compatibility with Kubernetes, it just adds stuff, doesn't it?
It takes away privileges which arguably is a good thing but some things that require root containers wont't run. They pass the Kubernetes conformance suite only by removing those constraints.
I really liked the idea or RancherOS, but somehow it never quite lived up to its promise. In particular, the need to distinguish between root and non-root containers was surprisingly confusing in practice. It effectively broke the promise of “just worry about docker”. Has anyone here adopted it over the long term? What made it stick? Any ideas why SUSE would need/want this?