Re: Why you might want packages not containers for Ceph deployments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



GCC, the whole toolchain, myriad dependencies, the ways that Python has patterend itself after Java.  Add in the way that the major Linux distributions are moving targets and building / running on just one of them is a huge task, not to mention multiple versions of each.  And the way that systems running the same nominal release rarely are completely identical, due to midstream package updates.  Heck I’ve seen a mostly-well-run operation that nonetheless had 80 different kernels running due to this.  

Re the community, remember that “they” *are* the community.

Ceph is a big complex hunka burning love that many of us get for FREE.  It by and large works beautifully and helps us feed our addictions to food and shelter.  Stability and performance continually improve, and we’re largely free of the baggage of proprietary solutions.  Ceph is simultaneously sliced bread and a cosmic love pulse matrix.

So long as packages can be built, those who want to manage the traditional way still can.

The things we quibble about are usually minor, which is a testament to just how much we take for granted.

So let’s discuss things that can be made *even better*, and try to respect the those who do the heavy lifting.

— aad

> But I think what Sage meant was e.g. different versions of GCC on the
> distributions and not being able to use all the latest features needed
> for compiling Ceph.
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux