With Snap, one of the major issues is that the same library could easily exist in 10-20 “Snaps”, all on the same PC / Server and also in 10-20 different versions.
Those with updated libraries, and those with insecure, older versions…
This is a nightmare for system administration!
And it’s also very inefficient.
My 2 cents
Andy
Don’t forget that Canonical introduced the search implementation for any search (local and external) that went through their servers. At the same time they partnered with Amazon (amazon lens was installed by default)
Let’s say, the Canonical track record of the last few years is a bit shady (to say the least)
Hi Dan
If I recall right, a reinstall was for SME-Server mandatory for 6 → 7 ( equal to RHEL 5 → 6 ).
I can’t recall if this was mandatory for RHEL at the same time…
SME-Server never made the switch to Centos7 base…
My 2 cents
Andy
I think it was actually SME 8-9, but now that you mention it, I think you’re right about it being CentOS 5-6. But yes, it was due to an upstream requirement. It worked well, all things considered, but it was still sub-optimal.
That’s Why My Ubuntu (Laptop), is allways talkin via sspd talking in Tcpdump?? Ubuntu use the Stupidly Simple DDoS Protocol (SSDP) that generates 100 Gbps DDoS to do it, through the 1900 port You can’t filter that.
You don’t know who to trust… Debian 11 this year (laptop compatible)
I am happy with Fedora on my laptop. Yeah, it’s like bleeding edge. It gives me the tools I need as a daily driver.
in the meanwhile:
even if useless, I could not resist…
Agree with his comments going forward at the 11:20 mark. Individual users are upset, but this is scariest for any enterprise customer, business or fork basing projects on RHEL.
Don’t forget the “certification compliance policy”.
If your system is no more certified for having “time-defined support policy”, and you have one or more certification (ISO anyone?) You’ll have to forcibly change to a subscribed version of RHEL IBMEL.
Regards…
Uwe
Hello
Just thought I’d chip in my thoughts as a subscriber. I personally think this is going to be first of many upheavals and surprises in the Linux community over the near future.
With that in mind would a *BSD based future not be a better route for Nethserver? There are benefits when it comes to stability and package availability and community resources. BSD has an age and pedigree which helps when seeking sign off from senior management types. I feel and this is my personal opinion that going the Debian/Ubuntu route will lead to a similar outcome as the one we’re in at the moment and also I personally think that if I wanted the ‘Z product’ I’d switch to the ‘Z product’.
Going the down Rocky route I think would be precisely that, although it’s still very early days but some of their decisions don’t sit with me that well. For example I understand the reasoning behind such a simple thing as the name (and it is a nice gesture) I think a lot of the aforementioned management types would have a problem with it and when it comes to server products we want something that is stable and sounds stable.
I’m not anti-ubuntu either… But how long do you think it will be before Canonical is acquired? And I think we all have thoughts on who would do the ‘acquiring’.
Kind Regards
And
@Carnyx Curious what about choosing Debian you think puts nethserver back in the Centos or even Ubuntu boat?
Hey
For the record I really like Debian too… in fact I have the Hertzog/Mas Handbook as constant companion here on my desk.
If you look at Debian and I believe they’ve just elected a new project lead it looks like they’re getting into (or back into) that whole political leanings and perceptions thing and you know that old saying… You can’t please everyone all of the time… I just hope it doesn’t lead to internal strife and division like these things can.
I must say that I firmly believe that Ubuntu will end up in a different place ownership-wise to where it is today.
I also agree with going debian
Thanks
Thank you all for this great discussion.
Among other links, I’ve read Embracing the stream posted by @dz00te: I totally agree with the article, even if I’m not a fan of containers, but this is the future.
For sure, we are not ready to take a decision about the base distribution for NethServer 8, but I think that using CentOS stream, or any other rolling release, will have no impact on the final user.
Why a rolling distro is not a problem?
First, this is how a rolling distro works: https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/.
If you’re not aware, we are already using this delivery mode on many software, and even on some part of NethServer, like packages from EPEL.
System administrators do not usually update the server every day without reviewing the changes.
And if they do, they are probably accessing a subscription service which provides a strong QA process for them, as we do for NethServe.
We will keep to do this work for the community, we can even create our mirror for CentOS fixed to a certain date to be sure that nobody hits a bad update.
In the end, using a rolling release doesn’t change anything for final NethServer users.
Should we switch to Debian?
I have nothing against Debian, but it has the same problems as any other distro (including CentOS 7): old software stack which is hard to update and maintain.
Canonical tried to answer to these limits with Ubuntu.
Debian has a great open development process, and I think that CentOS stream is going to use a similar process too: it’s a win for the Open Source ecosystem.
Ubuntu has LTS releases supported for 5 years (not bad), but Debian LTS are supported just for 2 years, which is not enough for a real LTS 
.
By the way, LTS releases will loose importance if we are going to enter the magic (and tragic) world of containers.
Are we going to face more bugs if we embrace the Stream?
I do not think so. Maybe you’re not aware, but we are facing changes on every new CentOS 7 release.
These changes often comes unexpected and we have to rush to fix consequent bugs.
If we embrace the Stream, we will be aware of such changes before they hit the release.
The current process is well explained here: https://blog.centos.org/2020/12/how-rhel-is-made/
I think we have the opportunity to get more involved on it.
My guess is that also ELREPO and EPEL will be part of the stream.
Does CentOS betrayed user expectation?
Yes, regarding CentOS 8 EOL. But you can switch to Stream with a single command, and I’m pretty sure that most of the sysadmin users will not notice the change.
Will NethServer embrace the Stream?
I do not know, time will tell!
Hi Giacomo
The very first sentance on the Debian link for LTS (https://wiki.debian.org/LTS):
“Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years.”
Where do you get the 2 years from?
True, Debian had in the past periods of very slow moving, but that seems past the last few years now…
As to this:
https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/
If this dude writes something like this: “It’s 2020. Act like it.”
Is he implying a Virus like Corona in the code (or management?).
Or was some vote stolen? An impending Lockdown?
2020 is a too ominous year to use in such a casual statement!
My 2 cents
Andy
You’re right, but table seems stating something different:
| Debian 9 “Stretch” | i386, amd64, armel, armhf and arm64 | July 6, 2020 to June 30, 2022 |
|---|---|---|
| Debian 10 “Buster” | i386, amd64, armel, armhf and arm64 | July, 2022 to June, 2024 |
I also I noticed right now that " Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. " 
By the way, as I stated, LTS is a minor problem IMO.
