Please take a look at
http://www.itworld.com/article/3211046/linux/red-hats-boltron-snaps-together...
and
https://fedoramagazine.org/announcing-boltron/
which has a walkthrough questionnaire at the bottom. Your feedback very appreciated.
Matthew Miller wrote:
Please take a look at
http://www.itworld.com/article/3211046/linux/red-hats-boltron-snaps-together...
and
https://fedoramagazine.org/announcing-boltron/
which has a walkthrough questionnaire at the bottom. Your feedback very appreciated.
What�s the point of doing this with Fedora? It�s not like bugs were fixed before Fedora is EOL and all reports are forgotten.
Now Fedora goes Gentoo, which I moved away from because of exactly what Fedora finally goes for.
On Fri, Jul 28, 2017 at 06:13:42PM +0200, hw wrote:
What?s the point of doing this with Fedora? It?s not like bugs were fixed before Fedora is EOL and all reports are forgotten.
Many bugs are fixed in Fedora. Many more bugs are fixed in the upstreams. Please remember that Fedora is primarily an *integration* project, and the best way to get bugs fixed is for the developers of the code in question to be involved. Many Fedora maintainers help facilitate this for users, which is awesome, but the sheer number of bugs exceeds what even our large contributor community can address.
I know it sucks when an issue that affects you doesn't get fixed in a timely manner, but we really do appreciate reports and it's helpful if you can retest and reopen EOL bugs if they do indeed still happen in the newer version.
Of course, if you _really_ need something fixed and want someone on the hook to do it for you, I suggest Red Hat's commercial offering.
Now Fedora goes Gentoo, which I moved away from because of exactly what Fedora finally goes for.
This is nothing like Gentoo.
Matthew Miller wrote:
On Fri, Jul 28, 2017 at 06:13:42PM +0200, hw wrote:
What?s the point of doing this with Fedora? It?s not like bugs were fixed before Fedora is EOL and all reports are forgotten.
Many bugs are fixed in Fedora. Many more bugs are fixed in the upstreams. Please remember that Fedora is primarily an *integration* project, and the best way to get bugs fixed is for the developers of the code in question to be involved. Many Fedora maintainers help facilitate this for users, which is awesome, but the sheer number of bugs exceeds what even our large contributor community can address.
Contributions are usually not wanted, despite what all projects tell you. I have given up trying to make any and keep things to myself instead.
I know it sucks when an issue that affects you doesn't get fixed in a timely manner, but we really do appreciate reports and it's helpful if you can retest and reopen EOL bugs if they do indeed still happen in the newer version.
It is discouraging to see bugs closed all the time not because the bugs are fixed but because Fedora has gone EOL again. When the policy is to have bugs fixed upstream, it might be a good idea to have them reported upstream and to restrict Fedoras bugzilla to bugs actually introduced by Fedora. In any case, I have given up reporting bugs a long time ago, especially with Fedora.
However, I�m seeing the same bugs from years ago still unfixed in Centos. That refers to libreoffice being unusably slow. This still doesn�t seem to be fixed for Fedora, either, because it went EOL --- but I don�t know.
What is the fix for Centos? There used to be a package you could install which made libreoffice work at normal speed, and that package seems to have disappeared.
Of course, if you _really_ need something fixed and want someone on the hook to do it for you, I suggest Red Hat's commercial offering.
I usually end up finding another solution, perhaps fixing the problem myself, or not having a solution at all. And for example, I doubt that RH would be inclined to come up with a CUPS filter that allows to print files created with lyx directly because it�s not possible to use lyx to convert them without running a GUI.
Now Fedora goes Gentoo, which I moved away from because of exactly what Fedora finally goes for.
This is nothing like Gentoo.
Sure is: You get to manage your distribution yourself by picking the versions of packages you figure might work together, which you are supposed and required to do with Gentoo, especially when you run into yet another dependency conflict. Only --- I guess --- you don�t get the same level of control over the packages as you get with Gentoo because there aren�t any USE flags.
I understand that the idea is probably to make it so that you don�t have problems like you can have with Gentoo because the packages are isolated in such a way that there are no dependency conflicts. So you end up trying to figure out for every package which version you want and which version brings about the minimum overhead you can get away with. That is not substantially different from what you do with Gentoo in that you are faced with having to find answers for questions you know you shouldn�t need to ask in the first place.
In case I really need a particular version of some software, nothing really prevents me from installing it myself. It�s rare enough that this happens. In my case, that�s once in 30 years --- twice if you count the perl version in Centos being too old, but that can be worked around.
Are you sure that all the added complexity and implicitly giving up a stable platform by providing a mess of package versions is worth it? How are the plans about dealing with bug reports, say, for squid 2.7, for those who need that version for a feature which hasn�t been included in current versions yet? Just wait a bit until the distribution goes EOL? Is RH going to fix them once someone has bought their support?
On 28/07/17 18:56, hw wrote:
Matthew Miller wrote:
On Fri, Jul 28, 2017 at 06:13:42PM +0200, hw wrote:
What?s the point of doing this with Fedora? It?s not like bugs were fixed before Fedora is EOL and all reports are forgotten.
Many bugs are fixed in Fedora. Many more bugs are fixed in the upstreams. Please remember that Fedora is primarily an *integration* project, and the best way to get bugs fixed is for the developers of the code in question to be involved. Many Fedora maintainers help facilitate this for users, which is awesome, but the sheer number of bugs exceeds what even our large contributor community can address.
Contributions are usually not wanted, despite what all projects tell you. I have given up trying to make any and keep things to myself instead.
The issue I have here is even if I did file a bug, and the issue were fixed, no sooner than it's fixed fedora updates to the next version and introduces a whole bunch of new bugs, and so the cycle continues. I played that game for a while with fedora core when Red Hat Linux died before settling on Enterprise Linux and have never looked back.
I have just recently upgraded my main system from el5 to el7. I originally built and installed that el5 system back in 2007. It ran for 10 years without a hitch. I can count the number of bugs I had to file in 10 years on one hand. Once they were fixed the system just worked for 10 years. If RH continued to support it, I'd still be using it now, and probably for a lot longer, because it still worked as well for me now as it did in 2007. I've updated to el7 not because I wanted to or needed to, but because I was forced to, and given the pain I want another 10 years of payback to make it worth the effort.
I know it sucks when an issue that affects you doesn't get fixed in a timely manner, but we really do appreciate reports and it's helpful if you can retest and reopen EOL bugs if they do indeed still happen in the newer version.
It is discouraging to see bugs closed all the time not because the bugs are fixed but because Fedora has gone EOL again. When the policy is to have bugs fixed upstream, it might be a good idea to have them reported upstream and to restrict Fedoras bugzilla to bugs actually introduced by Fedora. In any case, I have given up reporting bugs a long time ago, especially with Fedora.
However, I´m seeing the same bugs from years ago still unfixed in Centos. That refers to libreoffice being unusably slow. This still doesn´t seem to be fixed for Fedora, either, because it went EOL --- but I don´t know.
Agree on that. My previous 10 year old el5 install ran OpenOffice perfectly on 10 year old hardware. My new el7 install on brand new hardware which is vastly superior in terms of processing power, GPU power, disk IO, can't even scroll a simple 3 column spreadsheet on the screen. How is that improvement or advancement?
But if the issue does ever get fixed, you can bet your life I'll be sticking with that fixed product for the next 10 years, not upgrading to some other broken version in 6 or 12 months time.
What is the fix for Centos? There used to be a package you could install which made libreoffice work at normal speed, and that package seems to have disappeared.
On Fri, Jul 28, 2017 at 10:11:53PM +0100, Phil Perry wrote:
The issue I have here is even if I did file a bug, and the issue were fixed, no sooner than it's fixed fedora updates to the next version and introduces a whole bunch of new bugs, and so the cycle continues. I played that game for a while with fedora core when Red Hat Linux died before settling on Enterprise Linux and have never looked back.
Sure; that's the tradeoff of getting new stuff.
But, I'm not asking anyone here to switch to Fedora. I'm asking (especially those of you who are professional sysadmins) to please look at the Modularity prototype.
On 07/28/2017 04:22 PM, Matthew Miller wrote:
On Fri, Jul 28, 2017 at 10:11:53PM +0100, Phil Perry wrote:
The issue I have here is even if I did file a bug, and the issue were fixed, no sooner than it's fixed fedora updates to the next version and introduces a whole bunch of new bugs, and so the cycle continues. I played that game for a while with fedora core when Red Hat Linux died before settling on Enterprise Linux and have never looked back.
Sure; that's the tradeoff of getting new stuff.
But, I'm not asking anyone here to switch to Fedora. I'm asking (especially those of you who are professional sysadmins) to please look at the Modularity prototype.
I would like to point out that the next RHEL releases start as a Fedora release which is branched off at some point in time, has some packages removed (which the RHEL team deems not needed or unsupportable, etc.) and then undergoes a process of testing, bug fixing, etc.
Testing and using Fedora is extremely helpful to the RHEL engineering process, and since CentOS is a rebuild of the RHEL source code, the CentOS engineering process.
I personally have a Fedora machine that I keep updated and do some work on all the time learning/testing. I just seamlessly upgraded it from Fedora 25 to Fedora 26 using a couple of dnf commands .. awesome experience actually.
We don't have to pick sides here. There is no reason not to run Fedora alongside CentOS, it certainly allows you to understand where the next CentOS releases will look like well before they are released.
Obviously looking at Fedora 26 and the new Modularity components will be helpful for anyone who will be upgrading to newer RHEL or CentOS releases in the future.
A big thank you to both Matthew and the entire Fedora team on another quality release. Not to mention the help that many Fedora team members are providing in producing EPEL and also as members of the CentOS SIG process. All 3 of the distributions (Fedora, RHEL, CentOS) are better because of this effort.
Thanks, Johnny Hughes
On 30.07.2017 14:29, Johnny Hughes wrote:
I personally have a Fedora machine that I keep updated and do some work on all the time learning/testing. I just seamlessly upgraded it from Fedora 25 to Fedora 26 using a couple of dnf commands .. awesome experience actually.
because of this feature to upgrade from one release to the next, I thought to test this on my old computer; fedora itself works fine, but this upgrade from 25 to 26 broke the vmware workstaion completely ... it doesn't work any more, any hints in net which could be found don't work ... and this was the goal to have a linux running with vmware workstation instead of my old windows ...
but as it seems there is no way of achiving this ...
Obviously looking at Fedora 26 and the new Modularity components will be helpful for anyone who will be upgrading to newer RHEL or CentOS releases in the future.
in case it is just a server this is already supported by RHEL (from 6 to 7)
Walter
On 07/30/2017 09:41 AM, Walter H. wrote:
On 30.07.2017 14:29, Johnny Hughes wrote:
I personally have a Fedora machine that I keep updated and do some work on all the time learning/testing. I just seamlessly upgraded it from Fedora 25 to Fedora 26 using a couple of dnf commands .. awesome experience actually.
because of this feature to upgrade from one release to the next, I thought to test this on my old computer; fedora itself works fine, but this upgrade from 25 to 26 broke the vmware workstaion completely ... it doesn't work any more, any hints in net which could be found don't work ... and this was the goal to have a linux running with vmware workstation instead of my old windows ...
but as it seems there is no way of achiving this ...
Looking at VMWare Workstation, it does not seem to run on Fedora at all. It seems to run on :
Ubuntu 16.04 Red Hat Enterprise Linux 7.1 CentOS 7.1 Oracle Linux 7 openSUSE 13.2 SUSE Linux Enterprise Server 12
So, I'm not sure how it was running on Fedora 25 to get messed up by an upgrade to Fedora 26.
Obviously looking at Fedora 26 and the new Modularity components will be helpful for anyone who will be upgrading to newer RHEL or CentOS releases in the future.
in case it is just a server this is already supported by RHEL (from 6 to 7)
On 30.07.2017 20:22, Johnny Hughes wrote:
On 07/30/2017 09:41 AM, Walter H. wrote:
On 30.07.2017 14:29, Johnny Hughes wrote:
I personally have a Fedora machine that I keep updated and do some work on all the time learning/testing. I just seamlessly upgraded it from Fedora 25 to Fedora 26 using a couple of dnf commands .. awesome experience actually.
because of this feature to upgrade from one release to the next, I thought to test this on my old computer; fedora itself works fine, but this upgrade from 25 to 26 broke the vmware workstaion completely ... it doesn't work any more, any hints in net which could be found don't work ... and this was the goal to have a linux running with vmware workstation instead of my old windows ...
but as it seems there is no way of achiving this ...
Looking at VMWare Workstation, it does not seem to run on Fedora at all. It seems to run on :
Ubuntu 16.04 Red Hat Enterprise Linux 7.1 CentOS 7.1 Oracle Linux 7 openSUSE 13.2 SUSE Linux Enterprise Server 12So, I'm not sure how it was running on Fedora 25 to get messed up by an upgrade to Fedora 26.
with Fedora 25 everything worked fine, even the upgrade from VMware Wkst 12.5.6 to 12.5.7 with automatic recompilation of neccessary kernel modules without my intervention ... and the same when a kernel upgrade among other updates occured on Fedora 25, everything worked fine ...
but the upgrade from F25 to F26 killed my VMware Workstation :-( even the updates which occured after this upgrade didn't help ...
On 07/30/2017 02:07 PM, Walter H. wrote:
On 30.07.2017 20:22, Johnny Hughes wrote:
On 07/30/2017 09:41 AM, Walter H. wrote:
On 30.07.2017 14:29, Johnny Hughes wrote:
I personally have a Fedora machine that I keep updated and do some work on all the time learning/testing. I just seamlessly upgraded it from Fedora 25 to Fedora 26 using a couple of dnf commands .. awesome experience actually.
because of this feature to upgrade from one release to the next, I thought to test this on my old computer; fedora itself works fine, but this upgrade from 25 to 26 broke the vmware workstaion completely ... it doesn't work any more, any hints in net which could be found don't work ... and this was the goal to have a linux running with vmware workstation instead of my old windows ...
but as it seems there is no way of achiving this ...
Looking at VMWare Workstation, it does not seem to run on Fedora at all. It seems to run on :
Ubuntu 16.04 Red Hat Enterprise Linux 7.1 CentOS 7.1 Oracle Linux 7 openSUSE 13.2 SUSE Linux Enterprise Server 12So, I'm not sure how it was running on Fedora 25 to get messed up by an upgrade to Fedora 26.
with Fedora 25 everything worked fine, even the upgrade from VMware Wkst 12.5.6 to 12.5.7 with automatic recompilation of neccessary kernel modules without my intervention ... and the same when a kernel upgrade among other updates occured on Fedora 25, everything worked fine ...
but the upgrade from F25 to F26 killed my VMware Workstation :-( even the updates which occured after this upgrade didn't help ...
Running external things like VMWare Workstation (or other 3rd party custom compiled apps) is exactly what enterprise distros like RHEL, CentOS, Ubuntu LTS, SUSE SLES are designed for .. running things already compiled for a long period of time while providing security updates.
It is not just kernel modules that need to be compiled to run on a give linux distribution, but everything that uses any specific shared libraries linked against has to be compatible as well as the main shared libraries (glibc).
Looking at F25 and f26, GCC (the compiler) 6.2.5 in f25 and 7.1.1 in f26 and the glibc versions are 2.24 (f25) and 2.25 (f26), I am not sure how compatible those are to one another .. I am also not sure what other libraries that VMWare Worstation might link against. VMWare Workstation will likely need to be recompiled to be compatible with F26. Again, running 3rd party apps is one area where cutting edge Linux distros (like fedora, ubuntu, opensuse, etc.) are at a disadvantage until the 3rd party makes a compatible compile of their program. If the 3rd party app is open source, you can try recompiling it yourself .. I doubt VMWare Workstation provides an easily compilable version of their source code for this purpose.
If Windows is what you are trying to run, doing that on KVM works fine and the VMs are (usually :D) able to run as is when upgrading. to other versions.
On 07/31/2017 07:15 AM, Johnny Hughes wrote:
On 07/30/2017 02:07 PM, Walter H. wrote:
On 30.07.2017 20:22, Johnny Hughes wrote:
On 07/30/2017 09:41 AM, Walter H. wrote:
On 30.07.2017 14:29, Johnny Hughes wrote:
I personally have a Fedora machine that I keep updated and do some work on all the time learning/testing. I just seamlessly upgraded it from Fedora 25 to Fedora 26 using a couple of dnf commands .. awesome experience actually.
because of this feature to upgrade from one release to the next, I thought to test this on my old computer; fedora itself works fine, but this upgrade from 25 to 26 broke the vmware workstaion completely ... it doesn't work any more, any hints in net which could be found don't work ... and this was the goal to have a linux running with vmware workstation instead of my old windows ...
but as it seems there is no way of achiving this ...
Looking at VMWare Workstation, it does not seem to run on Fedora at all. It seems to run on :
Ubuntu 16.04 Red Hat Enterprise Linux 7.1 CentOS 7.1 Oracle Linux 7 openSUSE 13.2 SUSE Linux Enterprise Server 12So, I'm not sure how it was running on Fedora 25 to get messed up by an upgrade to Fedora 26.
with Fedora 25 everything worked fine, even the upgrade from VMware Wkst 12.5.6 to 12.5.7 with automatic recompilation of neccessary kernel modules without my intervention ... and the same when a kernel upgrade among other updates occured on Fedora 25, everything worked fine ...
but the upgrade from F25 to F26 killed my VMware Workstation :-( even the updates which occured after this upgrade didn't help ...
Running external things like VMWare Workstation (or other 3rd party custom compiled apps) is exactly what enterprise distros like RHEL, CentOS, Ubuntu LTS, SUSE SLES are designed for .. running things already compiled for a long period of time while providing security updates.
It is not just kernel modules that need to be compiled to run on a give linux distribution, but everything that uses any specific shared libraries linked against has to be compatible as well as the main shared libraries (glibc).
Uh, I run VMWare workstation just fine on my F26 upgraded machine. No, it didn't work when I upgraded, but it's trivial to fix.
http://rglinuxtech.com/?p=1939
This link gets you a running workstation in about 5 minutes. No, this wasn't really a Fedora issue, it's a VMWare issue. You have to remember, Fedora /is/ bleeding edge packages and sometimes crap breaks. If you looked on the internet for a fix to this, you didn't look hard enough, this link is one of the first to pop up. In fact, anytime a new kernel is installed, I check this site to see how much of a PITA it'll be to reboot the kernel and install the modules.
Personally, I would rather deal with these headaches on my Fedora box than I would on a CentOS box. Primarily because I like the latest packages (in some cases I need them) and, I'm not freaked out about little things like VMWare Workstation needing some massaging to get nice with the OS.
On 31.07.2017 13:23, Mark Haney wrote:
Uh, I run VMWare workstation just fine on my F26 upgraded machine. No, it didn't work when I upgraded, but it's trivial to fix.
http://rglinuxtech.com/?p=1939
This link gets you a running workstation in about 5 minutes.
not really, with this I only get the additional network interfaces listed with 'ifconfig', nothing more ..., I removed it, and wait for a VMware Wkst. Update ... (as this is just a test box, I can do this; if it were my essential box, I would have kicked Fedora from the harddisk and used Windows again, as I do on my essential box)
No, this wasn't really a Fedora issue, it's a VMWare issue.
doesn't really help me, the upgrade killed my VMware Workstation
On Mon, Jul 31, 2017 at 05:59:24PM +0200, Walter H. wrote:
No, this wasn't really a Fedora issue, it's a VMWare issue.
doesn't really help me, the upgrade killed my VMware Workstation
It still doesn't stop it from being a VMWare issue. VMware has kernel modules that need to be compiled against the running kernel. If you ran VMWare on an enterprise distro, you might be able to use the previous kernel's modules through the weak-modules feature, but upgrading from one Fedora release to the next is likely to introduce a large kernel jump, and Fedora makes no attempts to be ABI-compatible between releases.
This is extremely common for 3rd-party kernel modules. I know first-hand, since I maintain OpenAFS kernel module packages for Fedora and quite often they break mid-release of fedora because they track the new kernels. It happens. And if you really wanted to provide feedback about kernel updates, Fedora has a feedback mechanism here: https://bodhi.fedoraproject.org/updates/?packages=kernel
On 07/31/2017 11:59 AM, Walter H. wrote:
On 31.07.2017 13:23, Mark Haney wrote:
Uh, I run VMWare workstation just fine on my F26 upgraded machine. No, it didn't work when I upgraded, but it's trivial to fix.
http://rglinuxtech.com/?p=1939
This link gets you a running workstation in about 5 minutes.
not really, with this I only get the additional network interfaces listed with 'ifconfig', nothing more ..., I removed it, and wait for a VMware Wkst. Update ... (as this is just a test box, I can do this; if it were my essential box, I would have kicked Fedora from the harddisk and used Windows again, as I do on my essential box)
No, this wasn't really a Fedora issue, it's a VMWare issue.
doesn't really help me, the upgrade killed my VMware Workstation
Did you try restarting the vmware service? systemctl restart vmware? I had to do that, or reboot, in order to get the loaded modules actually seen by Workstation.
I have to be completely honest here. It sounds a lot like you're not the kind of person who wants to dig into the guts of things when they break. At least with computing/operating systems. If that's the case, then Fedora probably isn't for you, and I'm sure most on the list would agree. It's 'bleeding edge' packages that, even with a 'stable' release will possibly have some issues than need working out. That's been the case since the Fedora Core days.
In that vein, I would recommend Ubuntu, but the Unity desktop implodes spectacularly with VMWare workstation, or I should say it /did/ with 16.04. That may have been fixed with later versions, but I changed jobs from an all Ubuntu shop to an all RH/CentOS shop, so I'm not certain. The thing is, this is NOT a Fedora issue. It's a VMWare issue. This is true as evidenced by the fact that those modules /can/ be compiled by GCC7, just not by vmware-modconfig script. It happens, and with Workstation, relatively often as of late.
Seriously, if you're not happy with the issues with VMWare Workstation and Fedora, find another OS, like Ubuntu, that will provide you with more stable packages. It probably won't stop the Workstation shenanigans, but they should be fewer and farther between.
On 31.07.2017 13:15, Johnny Hughes wrote:
Running external things like VMWare Workstation (or other 3rd party custom compiled apps) is exactly what enterprise distros like RHEL, CentOS, Ubuntu LTS, SUSE SLES are designed for .. running things already compiled for a long period of time while providing security updates.
yes, but impossible to stay up-to-date forever, as the upgrade e.g. from CentOS 6 to CentOS 7 is not supported ...
If Windows is what you are trying to run, doing that on KVM works fine and the VMs are (usually :D) able to run as is when upgrading. to other versions.
the goal would have been, to have a Linux as my desktop instead of Windows one day ... my virtual machines are not just Windows, also some ancient things ...
Johnny Hughes wrote:
I personally have a Fedora machine that I keep updated and do some work on all the time learning/testing. I just seamlessly upgraded it from Fedora 25 to Fedora 26 using a couple of dnf commands .. awesome experience actually.
Don´t get me started on Fedora updates. One of the reasons to deprecate Fedora was that upgrading had turned out to be unreliable and mostly failing. Not being able to reliably upgrade disqualifies any distribution.
On 08/02/2017 07:36 AM, hw wrote:
Don´t get me started on Fedora updates. One of the reasons to deprecate Fedora was that upgrading had turned out to be unreliable and mostly failing. Not being able to reliably upgrade disqualifies any distribution.
I hate to break it to you, but since they began using fedup and dnf upgrade, it's never been an issue for me at all. Again, alot depends on what packages you have installed and _from what repos_ that determines a lot about your upgrade experience. Even Ubuntu LTS blows up when using non-standard repos.
I'll say to you what I said to someone else on this list on Monday. If you're not willing to deal with the warts in Fedora, then you need to go elsewhere. It's really not that complicated. Continuing to spam the list with psuedo-flamebait is just silly. We're here to help with problems not listen to disgruntled people complain all the time.
I, personally, get far too much email as it is for people like you to just add more junk to it.
Mark Haney wrote:
On 08/02/2017 07:36 AM, hw wrote:
Don´t get me started on Fedora updates. One of the reasons to deprecate Fedora was that upgrading had turned out to be unreliable and mostly failing. Not being able to reliably upgrade disqualifies any distribution.
I hate to break it to you, but since they began using fedup and dnf upgrade, it's never been an issue for me at all. Again, alot depends on what packages you have installed and _from what repos_ that determines a lot about your upgrade experience. Even Ubuntu LTS blows up when using non-standard repos.
The last update that failed was a machine with standard packages and fedup. Sometimes you´re lucky that an upgrade works, mott it doesn´t.
I'll say to you what I said to someone else on this list on Monday. If you're not willing to deal with the warts in Fedora, then you need to go elsewhere. It's really not that complicated. Continuing to spam the list with psuedo-flamebait is just silly. We're here to help with problems not listen to disgruntled people complain all the time.
I, personally, get far too much email as it is for people like you to just add more junk to it.
I didn´t bring the upgrade issue up, that was someone else. If you don´t want to see my posts, feel free to put me into your filter.
Matthew Miller wrote:
On Fri, Jul 28, 2017 at 10:11:53PM +0100, Phil Perry wrote:
The issue I have here is even if I did file a bug, and the issue were fixed, no sooner than it's fixed fedora updates to the next version and introduces a whole bunch of new bugs, and so the cycle continues. I played that game for a while with fedora core when Red Hat Linux died before settling on Enterprise Linux and have never looked back.
Sure; that's the tradeoff of getting new stuff.
But, I'm not asking anyone here to switch to Fedora. I'm asking (especially those of you who are professional sysadmins) to please look at the Modularity prototype.
Well, it might have some merits if it does work and makes its way into Centos because with Centos, I�m finding myself unusually often needing a more recent version of a package --- or something that isn�t packaged at all --- than is installed by default.
That leaves to ask whether making it easier to require users to have a mess of different versions of packages installed all at the same time or providing more recent packages by default is the better solution. Considering that not providing sufficiently recent packages apparently comes from a fear of breaking things, you need to explain how it is better to provide a mess of different versions of packages by default because doing that appears to make it easier to have things broken (by default), while making it much more difficult for everyone to maintain the distribution and their machines.
So in the end, how does it NOT make things worse? And that doesn�t even mention the necessity to fix bugs found in outdated versions of software. People might use them because they suddenly have become easy to install.
It COULD make things better when more recent packages could be installed AND made the default, already because it is unwieldy having to take care of using the right version of gcc and other things to compile software that isn�t packaged, which is unwieldy to begin with because you also need to keep it up to date. So instead of providing more different versions of the same packages, it might be better to package more different software.
Guess what, even nasm in Centos is outdated, and you have to enable yet another repo to get the current version, or install it yourself. That doesn�t go along well with the overrated fear of breaking things, not one way, nor the other.
You could even say this multiversion thing is about providing a way of breaking things, much like brokenarch was with Debian.
Phil Perry wrote:
However, I´m seeing the same bugs from years ago still unfixed in Centos. That refers to libreoffice being unusably slow. This still doesn´t seem to be fixed for Fedora, either, because it went EOL --- but I don´t know.
Agree on that. My previous 10 year old el5 install ran OpenOffice perfectly on 10 year old hardware. My new el7 install on brand new hardware which is vastly superior in terms of processing power, GPU power, disk IO, can't even scroll a simple 3 column spreadsheet on the screen. How is that improvement or advancement?
But if the issue does ever get fixed, you can bet your life I'll be sticking with that fixed product for the next 10 years, not upgrading to some other broken version in 6 or 12 months time.
Let me say just this:
I installed Libreoffice on one machine running Centos, and it was too slow to be useable. So I downloaded the rpm package from the Libreoffice website and installed that version, and it works fine.
I installed Libreoffice on another machine with almost identical hardware, running the same version of Centos, and it works fine.
So I can only speculate that there might some package installed on one machine which isn´t installed on the other, and that package makes Libreoffice useable. But wich package is that?
On Jul 28, 2017, at 1:56 PM, hw hw@gc-24.de wrote:
Many bugs are fixed in Fedora. Many more bugs are fixed in the upstreams. Please remember that Fedora is primarily an *integration* project, and the best way to get bugs fixed is for the developers of the code in question to be involved. Many Fedora maintainers help facilitate this for users, which is awesome, but the sheer number of bugs exceeds what even our large contributor community can address.
Contributions are usually not wanted, despite what all projects tell you. I have given up trying to make any and keep things to myself instead.
With that attitude, nothing would ever be fixed. I understand you are frustrated, but feedback and bug reports are one of the best way to help open source projects.
-- Jonathan Billings billings@negate.org
Jonathan Billings wrote:
On Jul 28, 2017, at 1:56 PM, hw hw@gc-24.de wrote:
Many bugs are fixed in Fedora. Many more bugs are fixed in the upstreams. Please remember that Fedora is primarily an *integration* project, and the best way to get bugs fixed is for the developers of the code in question to be involved. Many Fedora maintainers help facilitate this for users, which is awesome, but the sheer number of bugs exceeds what even our large contributor community can address.
Contributions are usually not wanted, despite what all projects tell you. I have given up trying to make any and keep things to myself instead.
With that attitude, nothing would ever be fixed. I understand you are frustrated, but feedback and bug reports are one of the best way to help open source projects.
That�s what I thought, and it may still be true. Unfortunately, feedback, bug reports and even fixes and improvements experience so much unkindness or ignorance in their reception that I�m better off finding a different solution or fixing the bug myself, with very few exceptions.
IIRC, Matthew who started this thread gave an overly perfect example of, mildly said, unkindness, on the Fedora mailing list. All the more it is surprising to see him asking for feedback yet again after he made clear that feedback is genuinely not wanted, and even employed fashist methods to supress it when he received feedback he didn�t like.
Just wait and see how he will like the feedback he�s getting here ...
On Wed, 2 Aug 2017, hw wrote:
That?s what I thought, and it may still be true. Unfortunately, feedback, bug reports and even fixes and improvements experience so much unkindness or ignorance in their reception that I?m better off finding a different solution or fixing the bug myself, with very few exceptions.
IIRC, Matthew who started this thread gave an overly perfect example of, mildly said, unkindness, on the Fedora mailing list. All the more it is surprising to see him asking for feedback yet again after he made clear that feedback is genuinely not wanted, and even employed fashist methods to supress it when he received feedback he didn?t like.
Just wait and see how he will like the feedback he?s getting here ...
I've fed a mixture of rambling bug reports, relatively good bug reports, and badly written patches to the SSSD developers.
One of them was to scratch an itch that was perculiar to me, but I made a patch, a flimsy case, and had it accepted. A short while later somebody submitted another patch to resolve an issue with the patch I'd submitted, which always makes you feel good about your handiwork.
Their general response to my queries and confusion has been to support me and encourage me to test their latest code, ultimately to work with them by doing testing and providing thorough logs to help them make their code better. I've not got one negative word to say about them.
I'm not pretending every project is like that, but it's not just monsters out there.
jh
On Wed, Aug 02, 2017 at 01:18:39PM +0100, John Hodrien wrote:
On Wed, 2 Aug 2017, hw wrote:
That?s what I thought, and it may still be true. Unfortunately, feedback, bug reports and even fixes and improvements experience so much unkindness or ignorance in their reception that I?m better off finding a different solution or fixing the bug myself, with very few exceptions.
I have to say that hasn't been my experience. I've found that while some requests do get overlooked, most get a response, and even if they disagree with my logic (for example, the infamous packagekit allowing any user to upgrade an installed package), I usually get a civil explanation.
On Wed, Aug 02, 2017 at 02:04:54PM +0200, hw wrote:
Just wait and see how he will like the feedback he?s getting here ...
Trolling aside (fascist? really?), I've gotten valuable feedback from several people which I really appreciate. I intend to continue to engage with the CentOS community, because when we work on big changes in Fedora which may come to our downstream distributions, it's really useful to have constructive feedback from serious users of those distributions.
Matthew Miller wrote:
On Wed, Aug 02, 2017 at 02:04:54PM +0200, hw wrote:
Just wait and see how he will like the feedback he?s getting here ...
Trolling aside (fascist? really?), I've gotten valuable feedback from several people which I really appreciate. I intend to continue to engage with the CentOS community, because when we work on big changes in Fedora which may come to our downstream distributions, it's really useful to have constructive feedback from serious users of those distributions.
Yes, really, and it was my main reason to deprecate Fedora. I�m not surprised that you like to get the feedback you want to hear.
On Thu, Aug 03, 2017 at 02:36:33PM +0200, hw wrote:
Trolling aside (fascist? really?), I've gotten valuable feedback from several people which I really appreciate. I intend to continue to engage with the CentOS community, because when we work on big changes in Fedora which may come to our downstream distributions, it's really useful to have constructive feedback from serious users of those distributions.
Yes, really, and it was my main reason to deprecate Fedora. I?m not surprised that you like to get the feedback you want to hear.
I wanted feedback *on the thing I was asking for feedback about*.
I don't mind other feedback in general, whether negative or positive, but it is off-topic for *this* list.
On Jul 28, 2017, at 1:56 PM, hw hw@gc-24.de wrote:
Are you sure that all the added complexity and implicitly giving up a stable platform by providing a mess of package versions is worth it? How are the plans about dealing with bug reports, say, for squid 2.7, for those who need that version for a feature which hasnīt been included in current versions yet? Just wait a bit until the distribution goes EOL? Is RH going to fix them once someone has bought their support?
I’m confused, are you talking about Gentoo, Fedora, CentOS or RHEL?
-- Jonathan Billings billings@negate.org
Jonathan Billings wrote:
On Jul 28, 2017, at 1:56 PM, hw hw@gc-24.de wrote:
Are you sure that all the added complexity and implicitly giving up a stable platform by providing a mess of package versions is worth it? How are the plans about dealing with bug reports, say, for squid 2.7, for those who need that version for a feature which hasnīt been included in current versions yet? Just wait a bit until the distribution goes EOL? Is RH going to fix them once someone has bought their support?
I’m confused, are you talking about Gentoo, Fedora, CentOS or RHEL?
I´m talking about Centos here and am referring to experiences with other distributions at the same time.
Like Gentoo is great but horrible to keep up to date, and in doing so, you are expected to become a package manager yourself. Things introduced into Fedora might make their way into RHEL/Centos, and introducing multiversion-packages into Fedora might lead to introducing them into Centos.
Once they have been introduced, we need to become package managers much as with Gentoo in order to figure out which versions of which packages work together. And that´s just the tip of the iceberg.
What will happen when you report a bug in version N of package foo, perhaps a bug that was fixed in version N+2? Are they going to fix it, or will they wait until the distribution goes EOL and/or tell you to use version N+2 --- which you can´t use because feature X is missing in that version, which is why you are using version N.
Being able to use that very version N is the point of multiversion-packages. Not maintaining all provided versions of such packages accordingly would defeat the whole purpose.
Perhaps issues like this haven´t been considered yet, that´s why I´m providing feedback as was asked for, after finding out that the form they have prepared to get feedback doesn´t allow to do so. I´m aware that this is feedback they don´t want to hear and will either ignore or encounter with unkindness.
Perhaps I´m entirely wrong and misunderstanding what they´re trying to do, yet so far nobody has said so.
On 08/02/2017 08:27 AM, hw wrote:
Jonathan Billings wrote:
I’m confused, are you talking about Gentoo, Fedora, CentOS or RHEL?
I´m talking about Centos here and am referring to experiences with other distributions at the same time.
Like Gentoo is great but horrible to keep up to date, and in doing so, you are expected to become a package manager yourself. Things introduced into Fedora might make their way into RHEL/Centos, and introducing multiversion-packages into Fedora might lead to introducing them into Centos.
I ran very early Gentoo versions (2005 to 2010) on my work laptop (a Compaq of all things) without any trouble. I had very few issues with failed updates, since they are compiled on my system with my switches. The biggest PITA was to get the right switches added to get what you really wanted on the system. I tinkered with KDE options for a couple of weeks (and the long compile times), but there weren't any issues usually.
Once they have been introduced, we need to become package managers much as with Gentoo in order to figure out which versions of which packages work together. And that´s just the tip of the iceberg.
I don't this is as making us (the end user) package maintainers as much as package /controllers/. I would fail to see much need to maintain multiple package versions on a system except for debugging/testing. However, as a former developer, I think this would make debugging much quicker and that's not a bad thing. On the DevOps/Systems Engineering side (my focus over the last decade), this could possibly be a PITA if devs were allowed to run multiple package versions in production systems. That's still not package maintainers, but a measure of control over them.
What will happen when you report a bug in version N of package foo, perhaps a bug that was fixed in version N+2? Are they going to fix it, or will they wait until the distribution goes EOL and/or tell you to use version N+2 --- which you can´t use because feature X is missing in that version, which is why you are using version N.
They do that sort of thing all the time, it's called backporting. And lots of patches are backported. Most of that is a function of how /far back/ to be backported, etc. If they don't backport, you have a couple of options, backport it yourself, or find a comparable package with the features you need.
Being able to use that very version N is the point of multiversion-packages. Not maintaining all provided versions of such packages accordingly would defeat the whole purpose.
That's insane. Who in their right mind want to continue to maintain version 1.0 of a package when the current one is version 10.0 and there are 30 stable versions in between? No one. What are the odds the version 1.0 package would still be used in that situation? (even given short release times)
Perhaps issues like this haven´t been considered yet, that´s why I´m providing feedback as was asked for, after finding out that the form they have prepared to get feedback doesn´t allow to do so. I´m aware that this is feedback they don´t want to hear and will either ignore or encounter with unkindness.
Perhaps I´m entirely wrong and misunderstanding what they´re trying to do, yet so far nobody has said so.
I don't think you're wrong, and I don't think you're misunderstanding either. It's kind of a bit of both, however contradictory that sounds. To me, Boltron seems to be a start on an idea whose time has come. Maybe it's too early for it, but I'm really looking to put it through it's paces to see how well it does work in real life situations.
Mark Haney wrote:
On 08/02/2017 08:27 AM, hw wrote:
Jonathan Billings wrote:
I’m confused, are you talking about Gentoo, Fedora, CentOS or RHEL?
I´m talking about Centos here and am referring to experiences with other distributions at the same time.
Like Gentoo is great but horrible to keep up to date, and in doing so, you are expected to become a package manager yourself. Things introduced into Fedora might make their way into RHEL/Centos, and introducing multiversion-packages into Fedora might lead to introducing them into Centos.
I ran very early Gentoo versions (2005 to 2010) on my work laptop (a Compaq of all things) without any trouble. I had very few issues with failed updates, since they are compiled on my system with my switches. The biggest PITA was to get the right switches added to get what you really wanted on the system. I tinkered with KDE options for a couple of weeks (and the long compile times), but there weren't any issues usually.
It works better when you have the time to update every day or at least every week. Still you´re in a circle because you know that an update may not work and have to expect them to be time consuming, so, unless you have huge amounts of time at your disposal, you need to defer the updates to when you have time, which makes the problem worse. They even go so far to make changes after which it suddenly becomes impossible to update. The problem might still be solvable, but it requires too much effort.
Once they have been introduced, we need to become package managers much as with Gentoo in order to figure out which versions of which packages work together. And that´s just the tip of the iceberg.
I don't this is as making us (the end user) package maintainers as much as package /controllers/. I would fail to see much need to maintain multiple package versions on a system except for debugging/testing. However, as a former developer, I think this would make debugging much quicker and that's not a bad thing. On the DevOps/Systems Engineering side (my focus over the last decade), this could possibly be a PITA if devs were allowed to run multiple package versions in production systems. That's still not package maintainers, but a measure of control over them.
Ok, since they run within containers, they can be tested without affecting the versions that are currently in use, so that can be a nice advantage.
What will happen when you report a bug in version N of package foo, perhaps a bug that was fixed in version N+2? Are they going to fix it, or will they wait until the distribution goes EOL and/or tell you to use version N+2 --- which you can´t use because feature X is missing in that version, which is why you are using version N.
They do that sort of thing all the time, it's called backporting. And lots of patches are backported. Most of that is a function of how /far back/ to be backported, etc. If they don't backport, you have a couple of options, backport it yourself, or find a comparable package with the features you need.
I wonder where the resources to do that for multiple versions of packages are suddenly coming from.
Being able to use that very version N is the point of multiversion-packages. Not maintaining all provided versions of such packages accordingly would defeat the whole purpose.
That's insane. Who in their right mind want to continue to maintain version 1.0 of a package when the current one is version 10.0 and there are 30 stable versions in between? No one. What are the odds the version 1.0 package would still be used in that situation? (even given short release times)
Why would you package version 1.0 when you don´t want to maintain it?
Perhaps issues like this haven´t been considered yet, that´s why I´m providing feedback as was asked for, after finding out that the form they have prepared to get feedback doesn´t allow to do so. I´m aware that this is feedback they don´t want to hear and will either ignore or encounter with unkindness.
Perhaps I´m entirely wrong and misunderstanding what they´re trying to do, yet so far nobody has said so.
I don't think you're wrong, and I don't think you're misunderstanding either. It's kind of a bit of both, however contradictory that sounds. To me, Boltron seems to be a start on an idea whose time has come. Maybe it's too early for it, but I'm really looking to put it through it's paces to see how well it does work in real life situations.
Well, I think I understand the idea a bit better now, and I guess it´s something some people are going to like a lot.
On 08/02/2017 07:27 AM, hw wrote:
Jonathan Billings wrote:
On Jul 28, 2017, at 1:56 PM, hw hw@gc-24.de wrote:
Are you sure that all the added complexity and implicitly giving up a stable platform by providing a mess of package versions is worth it? How are the plans about dealing with bug reports, say, for squid 2.7, for those who need that version for a feature which hasnīt been included in current versions yet? Just wait a bit until the distribution goes EOL? Is RH going to fix them once someone has bought their support?
I’m confused, are you talking about Gentoo, Fedora, CentOS or RHEL?
I´m talking about Centos here and am referring to experiences with other distributions at the same time.
Like Gentoo is great but horrible to keep up to date, and in doing so, you are expected to become a package manager yourself. Things introduced into Fedora might make their way into RHEL/Centos, and introducing multiversion-packages into Fedora might lead to introducing them into Centos.
Once they have been introduced, we need to become package managers much as with Gentoo in order to figure out which versions of which packages work together. And that´s just the tip of the iceberg.
What will happen when you report a bug in version N of package foo, perhaps a bug that was fixed in version N+2? Are they going to fix it, or will they wait until the distribution goes EOL and/or tell you to use version N+2 --- which you can´t use because feature X is missing in that version, which is why you are using version N.
Being able to use that very version N is the point of multiversion-packages. Not maintaining all provided versions of such packages accordingly would defeat the whole purpose.
Perhaps issues like this haven´t been considered yet, that´s why I´m providing feedback as was asked for, after finding out that the form they have prepared to get feedback doesn´t allow to do so. I´m aware that this is feedback they don´t want to hear and will either ignore or encounter with unkindness.
Perhaps I´m entirely wrong and misunderstanding what they´re trying to do, yet so far nobody has said so.
In CentOS for the Base OS, our package management / versioning is quite simple. If it is in RHEL source code for RHEL, we build it as is .. whatever the version. If it works the same in CentOS as in RHEL (even if that is broken), we release it. Our goal is fully functional compatibility with exactly the same versions as the RHEL source code and the same behavior that RHEL exhibits. So, we really don't make versioning decisions or do techincal fixes, we change a bare minimum to make sure people know they are using CentOS Linux (and to meet the Red Hat branding requirements for RHEL).
Getting things fixed in CentOS Linux means informing the Red Hat team that the source code contains bugs (either through Fedora or RHEL sections of the Red Hat bugzilla) and getting them fixed upstream, when the fix is released in RHEL, we will incorporate it in CentOS Linux.
For the Special Interest Groups (SIGs) things are much different. They are doing real development .. making versioning decisions, etc. Some of the things in SIGs have an upstream at Red Hat, some do not (for example, there is a Xen4CentOS in the Virt SIG that maintains Xen on CentOS Linux 6 and 7 .. that does not exist at all for RHEL). We maintain Xen dom0 kernel is unique in that SIG.
User feedback is important, but one has to make it to the proper place. For SIGs, that is bugs.centos.org. For base CentOS Linux .. unless we introduced a bug in building (not usually the case), those are better addressed with the upstream package maintainer (usually RHEL or Fedora bugs).
On Fri, Jul 28, 2017 at 07:56:41PM +0200, hw wrote:
Sure is: You get to manage your distribution yourself by picking the versions of packages you figure might work together, which you are supposed and required to do with Gentoo, especially when you run into yet another dependency conflict. Only --- I guess --- you don?t get the same level of control over the packages as you get with Gentoo because there aren?t any USE flags.
No, this isn't it it all. Modules are sets of packages which the distribution creators have selected to work together; you don't compose modules as an end-user.
Are you sure that all the added complexity and implicitly giving up a stable platform by providing a mess of package versions is worth it?
This is a false dichotomy. We will be providing a stable platform as the Base Runtime module.
How are the plans about dealing with bug reports, say, for squid 2.7, for those who need that version for a feature which hasn?t been included in current versions yet? Just wait a bit until the distribution goes EOL? Is RH going to fix them once someone has bought their support?
I can't speak to Red Hat plans or Red Hat fixes. In Fedora, we might have, say, squid 3.5, squid 4.0, and squid 5 streams (stable, beta, and devel) all maintained at the same time.
Matthew Miller wrote:
On Fri, Jul 28, 2017 at 07:56:41PM +0200, hw wrote:
Sure is: You get to manage your distribution yourself by picking the versions of packages you figure might work together, which you are supposed and required to do with Gentoo, especially when you run into yet another dependency conflict. Only --- I guess --- you don?t get the same level of control over the packages as you get with Gentoo because there aren?t any USE flags.
No, this isn't it it all. Modules are sets of packages which the distribution creators have selected to work together; you don't compose modules as an end-user.
Then maybe my understanding of packages and/or modules is wrong. What is considered a module? What if I replace, for example, apache N with apache N+2: Will that also replace the installed version of php with another one if the installed version doesn�t work with apache N+2?
Are you sure that all the added complexity and implicitly giving up a stable platform by providing a mess of package versions is worth it?
This is a false dichotomy. We will be providing a stable platform as the Base Runtime module.
What if apache N+2 doesn�t work with stdlibc++ N? Will the library and all that depends on it be replaced when I install apache N+2? Wouldn�t that change the platform?
How are the plans about dealing with bug reports, say, for squid 2.7, for those who need that version for a feature which hasn?t been included in current versions yet? Just wait a bit until the distribution goes EOL? Is RH going to fix them once someone has bought their support?
I can't speak to Red Hat plans or Red Hat fixes. In Fedora, we might have, say, squid 3.5, squid 4.0, and squid 5 streams (stable, beta, and devel) all maintained at the same time.
That reminds me of Debian stable, testing and unstable. I guess you could say they are different platforms, and though you can install squid unstable from unstable on stable, you can not have squid stable from stable installed at the same time.
IIUC, you want to make it so that you can have both (all) versions installed at the same time. Doesn�t that require some sort of multiplatform rather than a stable platform because different versions of something might require a different platform to run on?
For example, I don�t understand how I was able to compile ffmpeg, which required at least gcc 4.9, with gcc 6 and have it working despite there was a major change concerning libraries. IIUC, changing gcc versions requires a lot of rebuilds because of that, i. e. basically a different platform. Centos 7 is still gcc 4.8, yet there don�t seem to be any incompatibilities. However, that may not work in all cases.
So what is a platform, or what remains of it when all the software you�re using is of so recent versions that the platform itself should be more recent? Wouldn�t it make sense to also have different versions of the platform?
On Wed, Aug 02, 2017 at 03:40:42PM +0200, hw wrote:
No, this isn't it it all. Modules are sets of packages which the distribution creators have selected to work together; you don't compose modules as an end-user.
Then maybe my understanding of packages and/or modules is wrong. What is considered a module? What if I replace, for example, apache N with apache N+2: Will that also replace the installed version of php with another one if the installed version doesn?t work with apache N+2?
The current design doesn't prioritize parallel installation of different streams of the same module. We expect to use containers to address that problem. Whether we explicitly block parallel install or only do so when there is an active conflict is an open question. (See the walkthrough.)
In your example, if PHP is part of a "LAMP Stack" module, it's likely that it will be replaced with the matching version. But, modules can include other modules, so it may be that "LAMP Stack" is actually a _module stack_, including separate PHP and Apache modules. In that case, we could have different LAMP Stack streams with different combinations of PHP and Apache. I think this situation is in fact particularly likely.
So, in your scenario, you'd start with a LAMP Stack stream which might include Apache HTTPD 2.4, PHP 5.6, and MariaDB 5.5 as a bundle. If you decide to switch to a newer HTTPD, you could choose either one with Apache HTTPD 2.6, PHP 5.6, and MariaDB 5.5 *or* one with Apache HTTPD 2.6, PHP 7.1, and MariaDB 10.3.
This seems like it could become a combinatorial maintenance nightmare, but the idea is that the developers will just concentrate on their individual packages and module definitions, and automated testing will validate which combinations work (and then we can decide which combinations are supported, because working and supported are not necessarily the same thing).
Are you sure that all the added complexity and implicitly giving up a stable platform by providing a mess of package versions is worth it?
This is a false dichotomy. We will be providing a stable platform as the Base Runtime module.
What if apache N+2 doesn?t work with stdlibc++ N? Will the library and all that depends on it be replaced when I install apache N+2? Wouldn?t that change the platform?
We'd have several options:
* Include a compat lib in the Apache module * Add a compat lib to the base next to the existing one (as a fully-backwards-compatible update to the base) * Or, simply say that the Apache N+2 stream requires a certain minimum base.
I can't speak to Red Hat plans or Red Hat fixes. In Fedora, we might have, say, squid 3.5, squid 4.0, and squid 5 streams (stable, beta, and devel) all maintained at the same time.
That reminds me of Debian stable, testing and unstable. I guess you could say they are different platforms, and though you can install squid unstable from unstable on stable, you can not have squid stable from stable installed at the same time.
Yes. :)
IIUC, you want to make it so that you can have both (all) versions installed at the same time. Doesn?t that require some sort of multiplatform rather than a stable platform because different versions of something might require a different platform to run on?
No; this is currently out of scope. It'd be awesome if we could, but we think it's less important in an increasingly containerized world. But, feedback on how important this is to users will help us prioritize. (We know not everyone is ready for containers yet.)
[...]
So what is a platform, or what remains of it when all the software you?re using is of so recent versions that the platform itself should be more recent? Wouldn?t it make sense to also have different versions of the platform?
The platform is hardware (or virt/cloud) enablement, as well as basic shared infrastructure. Newer versions might make it easier to work on newer hardware or new environments, but change is also increased risk for existing situations which work.
And yes, it might in some cases make sense to have different versions of that. In Fedora, I expect we will have something similar to the current state: two currently supported base platform releases with an overlapping 13-month lifecycle. If this project is successful, how that will translate to RHEL (and hence CentOS) is a Red Hat business decision out of my scope. I assume, though, something longer-lived. :)
It probably makes sense under the assumption that you do pretty much everything in one container or another and that it doesn�t bother you having to switch between all the containers to do something. That would require something like a window manager turned into a container manager, and it goes towards turning away from an operating system to some kind of BIOS to run containers and the container-window manager on. You could strip down the BIOS to no more than the functionality needed for that, resulting in having less need for different software versions of the platform (BIOS).
Why hasn�t a BIOS like that already been invented? Or has it?
Since copyright issues were mentioned, please keep in mind that I am now the inventor of a container manager that is like a window manager, potentially showing programs running in whatever container as windows on your screen, bringing them together seamlessly with no further ado, as if they were running on the same OS: A common window manager would show an emacs frame besides an xterm; a container-window manager would basically do the same, but emacs and xterm would be running in different containers.
OS/2 already had something like that, but it didn�t have containers.
Why hasn�t a container manager like that already been invented? Or has it?
Wouldn�t it be much better being able to do this without needing containers?
Matthew Miller wrote:
On Wed, Aug 02, 2017 at 03:40:42PM +0200, hw wrote:
No, this isn't it it all. Modules are sets of packages which the distribution creators have selected to work together; you don't compose modules as an end-user.
Then maybe my understanding of packages and/or modules is wrong. What is considered a module? What if I replace, for example, apache N with apache N+2: Will that also replace the installed version of php with another one if the installed version doesn?t work with apache N+2?
The current design doesn't prioritize parallel installation of different streams of the same module. We expect to use containers to address that problem. Whether we explicitly block parallel install or only do so when there is an active conflict is an open question. (See the walkthrough.)
In your example, if PHP is part of a "LAMP Stack" module, it's likely that it will be replaced with the matching version. But, modules can include other modules, so it may be that "LAMP Stack" is actually a _module stack_, including separate PHP and Apache modules. In that case, we could have different LAMP Stack streams with different combinations of PHP and Apache. I think this situation is in fact particularly likely.
So, in your scenario, you'd start with a LAMP Stack stream which might include Apache HTTPD 2.4, PHP 5.6, and MariaDB 5.5 as a bundle. If you decide to switch to a newer HTTPD, you could choose either one with Apache HTTPD 2.6, PHP 5.6, and MariaDB 5.5 *or* one with Apache HTTPD 2.6, PHP 7.1, and MariaDB 10.3.
This seems like it could become a combinatorial maintenance nightmare, but the idea is that the developers will just concentrate on their individual packages and module definitions, and automated testing will validate which combinations work (and then we can decide which combinations are supported, because working and supported are not necessarily the same thing).
Are you sure that all the added complexity and implicitly giving up a stable platform by providing a mess of package versions is worth it?
This is a false dichotomy. We will be providing a stable platform as the Base Runtime module.
What if apache N+2 doesn?t work with stdlibc++ N? Will the library and all that depends on it be replaced when I install apache N+2? Wouldn?t that change the platform?
We'd have several options:
- Include a compat lib in the Apache module
- Add a compat lib to the base next to the existing one (as a fully-backwards-compatible update to the base)
- Or, simply say that the Apache N+2 stream requires a certain minimum base.
I can't speak to Red Hat plans or Red Hat fixes. In Fedora, we might have, say, squid 3.5, squid 4.0, and squid 5 streams (stable, beta, and devel) all maintained at the same time.
That reminds me of Debian stable, testing and unstable. I guess you could say they are different platforms, and though you can install squid unstable from unstable on stable, you can not have squid stable from stable installed at the same time.
Yes. :)
IIUC, you want to make it so that you can have both (all) versions installed at the same time. Doesn?t that require some sort of multiplatform rather than a stable platform because different versions of something might require a different platform to run on?
No; this is currently out of scope. It'd be awesome if we could, but we think it's less important in an increasingly containerized world. But, feedback on how important this is to users will help us prioritize. (We know not everyone is ready for containers yet.)
[...]
So what is a platform, or what remains of it when all the software you?re using is of so recent versions that the platform itself should be more recent? Wouldn?t it make sense to also have different versions of the platform?
The platform is hardware (or virt/cloud) enablement, as well as basic shared infrastructure. Newer versions might make it easier to work on newer hardware or new environments, but change is also increased risk for existing situations which work.
And yes, it might in some cases make sense to have different versions of that. In Fedora, I expect we will have something similar to the current state: two currently supported base platform releases with an overlapping 13-month lifecycle. If this project is successful, how that will translate to RHEL (and hence CentOS) is a Red Hat business decision out of my scope. I assume, though, something longer-lived. :)
On 08/02/2017 10:57 AM, hw wrote:
It probably makes sense under the assumption that you do pretty much everything in one container or another and that it doesn´t bother you having to switch between all the containers to do something. That would require something like a window manager turned into a container manager, and it goes towards turning away from an operating system to some kind of BIOS to run containers and the container-window manager on. You could strip down the BIOS to no more than the functionality needed for that, resulting in having less need for different software versions of the platform (BIOS).
Why hasn´t a BIOS like that already been invented? Or has it?
Since copyright issues were mentioned, please keep in mind that I am now the inventor of a container manager that is like a window manager, potentially showing programs running in whatever container as windows on your screen, bringing them together seamlessly with no further ado, as if they were running on the same OS: A common window manager would show an emacs frame besides an xterm; a container-window manager would basically do the same, but emacs and xterm would be running in different containers.
OS/2 already had something like that, but it didn´t have containers.
Why hasn´t a container manager like that already been invented? Or has it?
Wouldn´t it be much better being able to do this without needing containers?
Sure there is such a thing. It's a tiled console package (tilix is what I use). In all honesty, I wouldn't want Libreoffice running in a container and I can't imagine why you'd want an xterm in its own container. Most containers I've built have been RESTful API containers, NGINX proxies/web servers, etc. I spend more time on the container host making changes, than in the containers themselves. If an API change has been made, I throw a new container up with that change and test, rarely, if ever, do I need access the container directly. And that's the idea behind containers if you ask me.
On Wed, 2 Aug 2017, Mark Haney wrote:
Sure there is such a thing. It's a tiled console package (tilix is what I use). In all honesty, I wouldn't want Libreoffice running in a container and I can't imagine why you'd want an xterm in its own container. Most containers I've built have been RESTful API containers, NGINX proxies/web servers, etc. I spend more time on the container host making changes, than in the containers themselves. If an API change has been made, I throw a new container up with that change and test, rarely, if ever, do I need access the container directly. And that's the idea behind containers if you ask me.
Lots of people think of containers being for servers, as you say. It's what Docker lives off, and really does feel like the focus of Docker.
Singularity lets you think somewhat differently, and has proved very useful in areas like HPC, where you want to let a user bring a software environment to a machine. You get people like OpenFOAM releasing their software as a Docker container:
https://openfoam.org/download/4-1-linux/
I've also used it to run Ubuntu packaged software on CentOS without having to jump through hoops trying to repackage it or otherwise rebuild a million dependencies in just the right way.
jh
On 08/02/2017 11:13 AM, John Hodrien wrote:
On Wed, 2 Aug 2017, Mark Haney wrote:
Sure there is such a thing. It's a tiled console package (tilix is what I use). In all honesty, I wouldn't want Libreoffice running in a container and I can't imagine why you'd want an xterm in its own container. Most containers I've built have been RESTful API containers, NGINX proxies/web servers, etc. I spend more time on the container host making changes, than in the containers themselves. If an API change has been made, I throw a new container up with that change and test, rarely, if ever, do I need access the container directly. And that's the idea behind containers if you ask me.
Lots of people think of containers being for servers, as you say. It's what Docker lives off, and really does feel like the focus of Docker.
Singularity lets you think somewhat differently, and has proved very useful in areas like HPC, where you want to let a user bring a software environment to a machine. You get people like OpenFOAM releasing their software as a Docker container:
https://openfoam.org/download/4-1-linux/
I've also used it to run Ubuntu packaged software on CentOS without having to jump through hoops trying to repackage it or otherwise rebuild a million dependencies in just the right way.
I honestly had forgotten about Singularity. Mainly because it's been a couple of years since I managed any HPC equipment. But seriously, I think of containers the same way I do linux tools. Unlike MS, a linux does does one thing, and that thing very well, whereas MS has tried to be everything to everyone and is so-so at all of them. Perhaps that was the original intention of container and it's morphed into something else over time, which, if true, means I need to adjust how I define it rather than trying to beat that square peg into the round hole in my head.
On a side note, as I write this, Pandora decided to toss 'Misunderstading' by Phil Collins into my playlist. It's playing as I type. Go figure.
Mark Haney wrote:
On 08/02/2017 10:57 AM, hw wrote:
It probably makes sense under the assumption that you do pretty much everything in one container or another and that it doesn´t bother you having to switch between all the containers to do something. That would require something like a window manager turned into a container manager, and it goes towards turning away from an operating system to some kind of BIOS to run containers and the container-window manager on. You could strip down the BIOS to no more than the functionality needed for that, resulting in having less need for different software versions of the platform (BIOS).
Why hasn´t a BIOS like that already been invented? Or has it?
Since copyright issues were mentioned, please keep in mind that I am now the inventor of a container manager that is like a window manager, potentially showing programs running in whatever container as windows on your screen, bringing them together seamlessly with no further ado, as if they were running on the same OS: A common window manager would show an emacs frame besides an xterm; a container-window manager would basically do the same, but emacs and xterm would be running in different containers.
OS/2 already had something like that, but it didn´t have containers.
Why hasn´t a container manager like that already been invented? Or has it?
Wouldn´t it be much better being able to do this without needing containers?
Sure there is such a thing. It's a tiled console package (tilix is what I use).
I think I´ll check that out.
In all honesty, I wouldn't want Libreoffice running in a container and I can't imagine why you'd want an xterm in its own container.
It was only an example. The point of doing that is to use different versions of xterm and of emacs as come by default. How else would I do that when non-default versions of packages require their own container each?
Most containers I've built have been RESTful API containers, NGINX proxies/web servers, etc. I spend more time on the container host making changes, than in the containers themselves. If an API change has been made, I throw a new container up with that change and test, rarely, if ever, do I need access the container directly. And that's the idea behind containers if you ask me.
Really? It´s a lot of work to set up a container.
When you run things like emacs or Libreoffice in a container, how do you use them without accessing the container? How do you change the applications you´re programming that are residing in your webserver container without accessing the container?
Why wouldn´t you run Libreoffice in a container? You might want to use the latest version rather than the default one. So you´d install the version you want, and since it runs in a container, it´s what you get.
On Thu, Aug 03, 2017 at 03:25:36PM +0200, hw wrote:
In all honesty, I wouldn't want Libreoffice running in a container and I can't imagine why you'd want an xterm in its own container.
It was only an example. The point of doing that is to use different versions of xterm and of emacs as come by default. How else would I do that when non-default versions of packages require their own container each?
I think what you're looking for here is Flatpak.
Am 03.08.2017 um 15:55 schrieb Matthew Miller mattdm@mattdm.org:
On Thu, Aug 03, 2017 at 03:25:36PM +0200, hw wrote:
In all honesty, I wouldn't want Libreoffice running in a container and I can't imagine why you'd want an xterm in its own container.
It was only an example. The point of doing that is to use different versions of xterm and of emacs as come by default. How else would I do that when non-default versions of packages require their own container each?
I think what you're looking for here is Flatpak.
Just a off-topic question (maybe in the future of EL less off-topic); Does the concept of flatpak make updates in general more complicated (e.g. security issues in libraries)? The centralized concept of "shared libraries" does support by design the elimination of issues with "one" update. The flatpak approach implies that "every" flatpak packaged software must be updated individually, right? I hope that i got it right?
Thanks, LF
On Fri, Aug 04, 2017 at 02:10:31PM +0200, Leon Fauster wrote:
I think what you're looking for here is Flatpak.
Just a off-topic question (maybe in the future of EL less off-topic); Does the concept of flatpak make updates in general more complicated (e.g. security issues in libraries)? The centralized concept of "shared libraries" does support by design the elimination of issues with "one" update. The flatpak approach implies that "every" flatpak packaged software must be updated individually, right? I hope that i got it right?
Partly. Flatpak supports the concept of runtimes, which are shared, so updates to those will be shared. Additionally, since it uses os-tree, updates can be small and fast and are de-duplicated on disk.
If you're installing Flatpaks from arbitrary sources, of course, you need to make sure that you trust each provider. In Fedora, our plan is to automatically generate Flatpaks from RPMs, and when those RPMs are updated they will automatically cascade through the build and update system.
Am 04.08.2017 um 15:20 schrieb Matthew Miller mattdm@mattdm.org:
On Fri, Aug 04, 2017 at 02:10:31PM +0200, Leon Fauster wrote:
I think what you're looking for here is Flatpak.
Just a off-topic question (maybe in the future of EL less off-topic); Does the concept of flatpak make updates in general more complicated (e.g. security issues in libraries)? The centralized concept of "shared libraries" does support by design the elimination of issues with "one" update. The flatpak approach implies that "every" flatpak packaged software must be updated individually, right? I hope that i got it right?
Partly. Flatpak supports the concept of runtimes, which are shared, so updates to those will be shared. Additionally, since it uses os-tree, updates can be small and fast and are de-duplicated on disk.
If you're installing Flatpaks from arbitrary sources, of course, you need to make sure that you trust each provider. In Fedora, our plan is to automatically generate Flatpaks from RPMs, and when those RPMs are updated they will automatically cascade through the build and update system.
Ok, thanks to clarify this. Its sounds to be quite similar to OpenSTEP/Darwin/OSX's .app-bundle/directory approach.
-- LF
On Jul 28, 2017, at 11:56 AM, hw hw@gc-24.de wrote:
Matthew Miller wrote:
On Fri, Jul 28, 2017 at 06:13:42PM +0200, hw wrote:
What?s the point of doing this with Fedora? It?s not like bugs were fixed before Fedora is EOL and all reports are forgotten.
Many bugs are fixed in Fedora. Many more bugs are fixed in the upstreams.
Contributions are usually not wanted, despite what all projects tell you.
The main reason contributions are rejected at the level of this mailing list is that they’re being offered at the wrong level.
CentOS is really hard to fix directly, because virtually none of the work product of the CentOS maintainers goes into writing or patching the software that is distributed. Fixes need to happen at the upstream levels: RHEL, Fedora, or the individual software project.
This list is mainly about using CentOS as we find it today, not about driving its future, because its future is largely driven by the upstreams.
If you’ve been trying to get fixes into the upstream software projects, then I can tell you as the lead maintainer of a few open source software projects and contributor to many others, there are many good reasons not to accept random drive-by patches:
1. No license given. This may mean no contributor agreement was signed for projects that require it, or simply no explicit license on the contributed files. The default in the civilized world is full copyright, all rights reserved, so you can’t just put a set of changes online and expect others to merge them into the official source base.
2. ABI breakage. Many projects restrict any change that would break an ABI to major version transitions.
3. API breakage. If the project is a library, you generally can only add new interfaces, not remove or change existing ones, except at major version transitions.
4. Does not build on all target systems, no tests, patch doesn’t apply cleanly to the development branch, bad code formatting, poor variable naming, etc. Some projects will take a half-assed patch and do the finishing work on it for you, but not all will.
5. Philosophy mismatch. If your patch changes how something behaves and that behavior change doesn’t match how the project maintainer wants things to work, you’re probably stuffed. Quite frankly, your opinion doesn’t matter as much as that of the person who designed the system and has been maintaining it for the last N years. As long as that person holds well-regarded opinions, his project is likely to remain unforked, and your contribution will remain disregarded.
I can summarize all of the above with, “It’s difficult to work with other people,” but that’s no particular failing of open source software. That’s just people.
Warren Young wrote:
On Jul 28, 2017, at 11:56 AM, hw hw@gc-24.de wrote:
Matthew Miller wrote:
On Fri, Jul 28, 2017 at 06:13:42PM +0200, hw wrote:
What?s the point of doing this with Fedora? It?s not like bugs were fixed before Fedora is EOL and all reports are forgotten.
Many bugs are fixed in Fedora. Many more bugs are fixed in the upstreams.
Contributions are usually not wanted, despite what all projects tell you.
The main reason contributions are rejected at the level of this mailing list is that they’re being offered at the wrong level.
Sometimes a mailing list is just the right place. It´s not like you could stuff everything into bug reports or feature requests.
CentOS is really hard to fix directly, because virtually none of the work product of the CentOS maintainers goes into writing or patching the software that is distributed. Fixes need to happen at the upstream levels: RHEL, Fedora, or the individual software project.
This list is mainly about using CentOS as we find it today, not about driving its future, because its future is largely driven by the upstreams.
If you’ve been trying to get fixes into the upstream software projects, then I can tell you as the lead maintainer of a few open source software projects and contributor to many others, there are many good reasons not to accept random drive-by patches:
No license given. This may mean no contributor agreement was signed for projects that require it, or simply no explicit license on the contributed files. The default in the civilized world is full copyright, all rights reserved, so you can’t just put a set of changes online and expect others to merge them into the official source base.
ABI breakage. Many projects restrict any change that would break an ABI to major version transitions.
API breakage. If the project is a library, you generally can only add new interfaces, not remove or change existing ones, except at major version transitions.
Does not build on all target systems, no tests, patch doesn’t apply cleanly to the development branch, bad code formatting, poor variable naming, etc. Some projects will take a half-assed patch and do the finishing work on it for you, but not all will.
Philosophy mismatch. If your patch changes how something behaves and that behavior change doesn’t match how the project maintainer wants things to work, you’re probably stuffed. Quite frankly, your opinion doesn’t matter as much as that of the person who designed the system and has been maintaining it for the last N years. As long as that person holds well-regarded opinions, his project is likely to remain unforked, and your contribution will remain disregarded.
I can summarize all of the above with, “It’s difficult to work with other people,” but that’s no particular failing of open source software. That’s just people.
Another reason is that nobody cares about fixing something. It doesn´t matter what the reasons are.
All the projects asking for help on the one hand and experiencing that attempts to contribute are encountered with unkindness on the other is a contradiction. So why bother, and knowing that the asking for help is nothing but a fake brought up for unknown reasons makes me even less inclinded to do anything because it is dishonest.
They´d better just say they don´t want help. They are doing what they are doing for their own reasons, and they will do whatever they see fit. Why should I bother anyone with contributions.
BTW, the default of full copyright may exist somewhere on paper, like so many other things. Since it´s impossible to claim it, the default is of course not to give out anything I don´t want others to use.
The projects you´re involved with, are any of them asking for help? If so, why do they ask, and how do they take it?
-
hw -
John Hodrien -
Johnny Hughes -
Jonathan Billings -
Leon Fauster -
Mark Haney -
Matthew Miller -
Phil Perry -
Scott Robbins -
Walter H. -
Warren Young