On 5 January 2017 at 19:29, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Thu, Jan 5, 2017 at 4:40 PM, Japheth Cleaver <cleaver@xxxxxxxxxxxxxx> wrote: >> On 1/5/2017 9:12 AM, Jonathan Wakely wrote: >>> >>> On 05/01/17 09:56 -0700, Chris Murphy wrote: >>>> >>>> Teamviewer comes in an i686 only package for Fedora. So is there going >>>> to be this interim approach, and then yet another change when they're >>>> expected to use FlatPak? That's a lot of changes... And are these two >>>> approaches compatible with the other platforms they target, or are >>>> they just likely to drop the one it stops working on? >>>> >>>> I can hardly imagine Teamviewer is the only 32-bit only GUI program. >>> >>> >>> There are all sorts of proprietary programs like Skype that are only >>> provided as 32-bit packages (there's a "skypeforlinux" package which >>> is 64-bit but it's an "alpha" release). >>> >>> Maybe it would work fine from inside a 32-bit container, I have no >>> idea, but we should be careful not to make it harder for normal users >>> to install and use software distributed outside Fedora. And not make >>> it harder for ISVs to provide RPMs that work on Fedora with minimal >>> effort. >> >> >> I feel like if this happens it will hasten the day when those of us >> primarily working in EL-variant land have to consider a need for a new, >> EL-forward, RPM-based open source "community" OS. > > Can you elaborate why you think that? Particularly the "EL-forward" > part. I don't understand how Stephen's line of thinking is not > EL-forward. > I think it is because EL-forward means different things to different people. 1. Developer definition. EL-Forward is looking towards how something will work in EL-next. 2. Enterprise operations. EL-Forward is looking towards how to take something in current Fedora and move it forward to the version of Enterprise you have deployed. [From a developer point of view it is moving it backwards but it is because we are driving in two different directions.] A large amount of Enterprise ops people have to work in environments with 30% of the systems being EL-5, 50% of the systems being EL-6 and 20% being EL-7. They have to both make corporate apps work with ancient code bases but also get apps that need later items to make things work. The work flow for this is 1. Find it in an 'approved' repo. [This was in the past EPEL but less so due to aging items.] 2. Take the latest Fedora rpm and recompile/mangle the bits until it works on EL5/EL6. 3. Get a bunch of tar-balls and make them work... but pay for the upgrade problems later. If they have problems in 2 or 1 they feed that back as bug reports and considered that how they pushed Fedora forward. At some point they would get to be able to install EL-8 and would have packages they knew worked in Fedora from say Fedora-30 that would work for what they needed. Why does this not look forward to them? 1) They are still primarily having to deal with 32 bit applications. 2) They are only getting to virtualize their main environments. Yes they have some systems somewhere in the giant bank IT that are containered and that admin gets trotted out at docker con as the forward way the world is working but 99% of the operations staff is having to deal with an OS which is going to be EOL in 3 months and is only now getting a budget which says they can move it to EL6. [They can't move it to EL7 because the vendor still hasn't produced a version of XYZ that 'works with systemd' (eg it relys on some initd hack that they don't know how to fix to start up).] 3) Containers don't look baked yet. People are still arguing about how to upgrade/update them.. the ones they google to see how it works of them say they are read only but have instructions of 'install an ssh and then log in and make these changes to really get it to work' etc etc. Maybe Fedora will deliver all the packages in Fedora 27 with docker formatting.. and maybe Fedora 28 will use a completely new one.. 4) The oracles they rely on to say this is how things are done in Linux haven't agreed yet. The usual rule from previous technology changes is don't bet on what the markets are using.. see what one Linus uses for N months and if he doesn't like it see what he replaces it with as that will be the way things go. [This is usually from people who were burned deploying enterprise CVS, SVN, HG, BZR solutions to have them all replaced with git in the last 5 years.. older admins have other Linus did it this way and everyone went that way too.. the fact that Linus didn't have a tantrum and replace systemd was pretty much the "ok it looks like this is the way things are going"] So if the OS they rely on to grab/build packages no longer offers a way they can consume them (it has to be in a container which you will need to run in your EL5/6 environment somehow..) then it can look like the OS is no longer wanting EL to use it. And it doesn't matter how much Red Hat says it is banking on containers.. that is something that most of these Enterprise op people aren't going to see for a decade. -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
