Well I will move most of my stuff to Rocky, I have it running there for almost 
a year and love it. 

Remo 

> On Jan 20, 2022, at 09:21, Diego Piñon Conde <[email protected]> wrote:
> 
> It's sad (hey! I love Centos too), but let me transcript an Eric's email from 
> Dec 10 2020 to answer "why move away from centos"
> 
> Diego
> 
> -------- Mensaje reenviado --------
> 
> Asunto:       Re: [qmailtoaster] Future of qmailtoaster on CentOS?
> Fecha:        Thu, 10 Dec 2020 08:35:01 -0700
> De:   Eric Broch <[email protected]> <mailto:[email protected]>
> Responder a:  [email protected] 
> <mailto:[email protected]>
> Para: [email protected] 
> <mailto:[email protected]>
> 
> Fellow QMT enthusiasts:
> 
> I became concerned about the future of CentOS a week or so ago (not a 
> premonition just my natural paranoia) prior to their announcement two         
>     days back and visited centos.org to relieve my fears. I was confident at 
> that point that having gotten QMT/CentOS 8 ready I was good to go for ~10 
> years. My confidence MAY have been hasty. I'm still not sure what drawbacks 
> 'stream' is going to bring, if any, and like Angus am apprehensive. It's 
> supposed to be an intermediate environment between Fedora and RHEL. In my 
> opinion, to release CentOS 8 and then move it from downstream to upstream 
> after people have already migrated is short-sighted at the very least, and 
> its name Community Enterprise OS (8) is now a misnomer. Living in somewhat of 
> a cocoon, I was completely unaware that RH "joined" CentOS. I've heard some 
> say that we've been freeloading off CentOS for years and now it's time to pay 
> up. Never mind that a free kernel is used and we actually test the software 
> and report bugs. That said, I have REALLY enjoyed using CentOS since the 
> beginning. 
> 
> That said, having a look at the old spec files from *-toaster designation 
> days when we built the QMT for specific platforms, Fedora, was among them 
> along with Suse, Mandrake, so, at the beginning QMT was used in a 
> non-Enterprise environment. Anyway...
> 
> Personally, I'm interested in both Debian and FreeBSD and would like to go 
> back halfway to multi-platform builds while keeping the current QMT/CentOS 8 
> offering. This would mitigate the problems, if there are any, we are seeing 
> now (hopefully). I guess it just depends on when (or if) the mega-corps buy 
> up all of the Linux distributions and hang us all out to dry. Given the 
> Felliniesque nature of the world today nothing would surprise me anymore.
> 
> One advantage of having a ports like mail server is the ability, if one is 
> inclined to dig a little beyond binary installs, to make changes on the fly 
> without having to wait for packages from the repo.
> 
> I've tried to install FreeBSD, although somewhat half-heartedly, on Proxmox 
> serveral times with no success. If anyone has any hints I'm all ears...just 
> my 2 cents.
> 
> So, if anyone is working on installing QMT on another platform please keep us 
> apprised of your successes. If you feel like writing it up, I'll post it to 
> the web site.
> 
> I'll be looking into converting to *.deb packages (like rpm's, binary ease of 
> install) in some way (I tried using alien...on the website) which can be used 
> on Ubuntu and Debian Linux. Back to work for me...
> 
> Eric B.
> 
> 
> El 20/1/2022 a las 13:57, Janno Sannik escribió:
>> it's probably discussed before, but why it moved away from centos to 
>> Springdale or Rocky? 
>> 
>> I also need to make a fresh install. So that is why I'm curious. 
>> 
>> 
>> For server stuff - always would go for ECC if you can and it's reasonably 
>> busy machine. It doesn't have to cost arm and a leg since there is 
>> aftermarket hw to snatch with reasonable prices. It's really complicated to 
>> debug a server with memory problems because it might not crash the whole OS, 
>> just crashing processes at random. 
>> 
>> As Linus Torvalds has said  - we never know how many bad kernel dumps have 
>> been submitted  and there is nothing wrong with the code, just bad memory in 
>> the system. 
>> 
>> Also if failure occures, you will know where and what dimm is broken. And if 
>> you are lucky it get's corrected by ECC on the fly. 
>> 
>> 
>> Janno 
>> 
>> On 20.01.2022 18:36, Angus McIntyre wrote: 
>>> My impression is that Rocky is more widely supported than Springdale by 
>>> VM providers like Digital Ocean and Linode. But I think they also allow 
>>> you to provide your own images for initializing VMs, so maybe that's not 
>>> an obstacle so much as an extra step. 
>>> 
>>> Angus 
>>> 
>>> 
>>> 
>>> Remo wrote on 1/20/22 10:46 AM: 
>>>> I like rocky Linux. 
>>>> 
>>>> Remo 
>>>>> Il giorno 20 gen 2022, alle ore 03:06, Andreas Galatis <[email protected]> 
>>>>> <mailto:[email protected]> ha scritto: 
>>>>> 
>>>>> Hi all, 
>>>>> 
>>>>> I use the qmail-toaster since many years and are very glad with it. The 
>>>>> system is very stable, secure and configurable with the features we need. 
>>>>> 
>>>>> I need to install a new Server for qmail and migrate the installation 
>>>>> from CentOS7. 
>>>>> 
>>>>> What is the preferred OS, (Rocky or Springdale) 
>>>>> 
>>>>> Is there a big advantage of ECC-Ram (with XEON) over Standard Ram (with 
>>>>> Core7)? 
>>>>> 
>>>>> Thanks in advance 
>>>>> 
>>>>> Iodok 
>>>>> 
>>>> 
>>>> --------------------------------------------------------------------- 
>>>> To unsubscribe, e-mail: [email protected] 
>>>> <mailto:[email protected]> 
>>>> For additional commands, e-mail: [email protected] 
>>>> <mailto:[email protected]> 
>>>> 
>>> --------------------------------------------------------------------- 
>>> To unsubscribe, e-mail: [email protected] 
>>> <mailto:[email protected]> 
>>> For additional commands, e-mail: [email protected] 
>>> <mailto:[email protected]> 
>>> 
>> 
>> --------------------------------------------------------------------- 
>> To unsubscribe, e-mail: [email protected] 
>> <mailto:[email protected]> 
>> For additional commands, e-mail: [email protected] 
>> <mailto:[email protected]> 
>> 
> --------------------------------------------------------------------- To 
> unsubscribe, e-mail: [email protected] For 
> additional commands, e-mail: [email protected]

Reply via email to