Hi Ernie, > Lol at the WoW binge.
Yeah, I was laughing out loud when I read that. > The change from rpm to .deb is major, but mostly at the package management > level, once unpacked BX would be fine. That's true. OTOH I could directly consolidate the package building process. At the moment our "make rpm" spits out several individual RPMs for every BlueOnyx module. Like this: base-vsite-am-1.0.0-0BX03.el6.x86_64 base-vsite-capstone-4.0-0BX48.el6.noarch base-vsite-glue-4.0-0BX48.el6.noarch base-vsite-locale-da_DK-4.0-0BX48.el6.noarch base-vsite-locale-de_DE-4.0-0BX48.el6.noarch base-vsite-locale-en_US-4.0-0BX48.el6.noarch base-vsite-locale-es_ES-4.0-0BX48.el6.noarch base-vsite-locale-fr_FR-4.0-0BX48.el6.noarch base-vsite-locale-it_IT-4.0-0BX48.el6.noarch base-vsite-locale-ja_JP-4.0-0BX48.el6.noarch base-vsite-locale-nl_NL-4.0-0BX48.el6.noarch base-vsite-locale-pt_PT-4.0-0BX48.el6.noarch base-vsite-ui-4.0-0BX48.el6.noarch When I publish an update I always publish *all* RPMs from that latest build (even if the "locale" files didn't change). When I address the building of *.deb files I'll therefore do the "lazy" thing and let it spit out just a single *.deb that contains everything. There may be exceptions here and there where I might let it build multiple *.deb's, but that would already greatly simplify the process. > From a credibility perspective, Ubuntu 18.04 LTS would be an obvious choice, > a major > upgrade every 2 years with 5 years support, that would be the closest thing > to RHEL in the debian > world, but Debian itself runs some heavy duty stuff eg. Proxmox which is > pretty stable and can take a hammering in data centers. The LTS support of Ubuntu is indeed very nice and I've been on it since 12.04 for my desktops and the laptops. For 16.04 -> 18.04 I also did an in-situ upgrade (fully prepared to have to do a full reinstall), but it also went surprisingly well without any hitches. But I'm not convinced Ubuntu is really good enough for data centers or that they take security or enterprise levels of uptime seriously enough. There has been a period not too long ago where they released a new kernel every day or two. That prompted me to look at what they actually were changing and the changelogs read like amateur-hour on a grand scale. Fix X, fix for fix X, rollback to Y, backport Z to cover problem X and Z, then fixing the things that the backport broke. Design wise I'm also shaking my head about a few decisions they made which go beyond a matter of taste and preference. Like the perverse and pervasive usage of Snapd containers for applications that should have been rolled out as a normal package instead. Example from my workstation: mstau...@beast.smd.net:~/$ mount|grep snaps|cut -d \ -f1|sort /var/lib/snapd/snaps/canonical-livepatch_81.snap /var/lib/snapd/snaps/chromium_849.snap /var/lib/snapd/snaps/chromium_853.snap /var/lib/snapd/snaps/core18_1098.snap /var/lib/snapd/snaps/core18_1144.snap /var/lib/snapd/snaps/core_7396.snap /var/lib/snapd/snaps/core_7713.snap /var/lib/snapd/snaps/discord_91.snap /var/lib/snapd/snaps/discord_92.snap /var/lib/snapd/snaps/discord_93.snap /var/lib/snapd/snaps/gnome-3-26-1604_90.snap /var/lib/snapd/snaps/gnome-3-26-1604_92.snap /var/lib/snapd/snaps/gnome-3-28-1804_67.snap /var/lib/snapd/snaps/gnome-3-28-1804_71.snap /var/lib/snapd/snaps/gnome-calculator_406.snap /var/lib/snapd/snaps/gnome-calculator_501.snap /var/lib/snapd/snaps/gnome-characters_296.snap /var/lib/snapd/snaps/gnome-characters_317.snap /var/lib/snapd/snaps/gnome-logs_61.snap /var/lib/snapd/snaps/gnome-logs_73.snap /var/lib/snapd/snaps/gnome-system-monitor_100.snap /var/lib/snapd/snaps/gnome-system-monitor_95.snap /var/lib/snapd/snaps/gtk-common-themes_1198.snap /var/lib/snapd/snaps/gtk-common-themes_1313.snap /var/lib/snapd/snaps/lxd_11727.snap /var/lib/snapd/snaps/lxd_11824.snap /var/lib/snapd/snaps/lxd-demo-server_87.snap /var/lib/snapd/snaps/lxd-demo-server_92.snap /var/lib/snapd/snaps/ncdu-kz6fittycent_18.snap /var/lib/snapd/snaps/nutty_10.snap /var/lib/snapd/snaps/tor-mkg20001_13.snap /var/lib/snapd/snaps/tor-mkg20001_5.snap Why are Discord or Chromium Snaps? The bloody desktop Calculator as well! And why did the update procedure not remove the outdated Snaps? That's wasteful and looks disorderly. In fact it's outright lazy and makes security audits a pain in the butt. Installs from RPMs and DEBs can easily be verified for integrity, but with Snaps you're buying the cats in the bag. > I too have been thinking about how to decouple the base layer of BX and use > containers to deliver the services. I think it's totally viable, it > partially addresses HA with things like swarm, and containerization seems to > be the direction > enterprises want to go, rather than the monolithic setups we are use to. Indeed. There are some interesting possibilities around. As for either Kubernetes or Docker Swarm? They both have their advantages and disadvantages: https://thenewstack.io/kubernetes-vs-docker-swarm-whats-the-difference/ But like you said: That's a whole new world that needs to be mastered and custom tailoring BlueOnyx for that would be a major undertaking. I'm not ruling it out, but it's something for later. In the meantime I'll invest some time into adapting the build architecture for Debian 10. If need be the rest of the BlueOnyx 5210R code base could be adapted for a Debian version as well if we ever want to or need to pursue that road. -- With best regards Michael Stauber _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx