On Tuesday 28 March 2017, Richard Brown wrote:
On 28 March 2017 at 17:23, Fabian Wein
wrote: Rüdiger Meier wrote:
The key here is that you and your colleagues update your machines whenever YOU want. If another guy (your admin) would do this with your machines a few times per year overnight then you would probably know what I'm talking about.
We are happy to have control on our desktops and servers by ourselves, simply as our group has no admin and the central adminstration is not flexible enough for our needs.
I'd say _especially_ in science where you sometimes have to reproduce results from old papers, etc. it has a lot value for users that they maintain their most heavily used software by themselves (gnu-modules/virtualenv/anaconda/whatever). Much better than using randomly whatever comes with your distro. But to make such local installations usable/possible you have to give them an LTS distro. Otherwise their local installation will break on every distro upgrade.
I have the impression you don't understand. For our desktops we *don't want* an LTS with most of the time outdated versions. This is different from servers and clusters but we sit 40h/week in front of our desktops.
So if you are unhappy with your current mixed LTS/TW/colleagues machines, I'm sure you all could have it a lot easier if you all would use the same LTS distro, plus modules/virtualenv as described.
You missed the desktops: We have desktop distros (just me with TW) and LTS on servers/clusters. Currently we are happy. But I feel you want to remove a modern desktop distro without replacement.
like "why this is working for you but not for me" should be more seldom. Just ask your cluster admin for help or providing such modules.
The reason is currently that either they have to use non-standard repos or build manually to have the cmake/python/gdb/... stuff that works for me on TW or I have to fight my TW because I cannot run the commercial Intel vTunes performance analyzer due to kernel incompatibilities.
Once again, we *don't want* LTS desktop systems, simply for the reason that for our use cases it is good to have newest software. We prefer "newer" instead of "stable and old" for our desktops.
My understanding is that having only TW and LTS Leap would mean that there is no modern desktop available most of the time.
Isn't TW up-to-date enough?
It is, but in my eyes not necessarily robust enough for general broad productive desktop use.
Fabian
I would like to take this point in the thread to conduct a theoretical, thought experiment.
I want to make something absolutely clear, I'm asking the below as 'Richard the contributor', not 'Richard the SUSE employee', and what I am about to suggest should not be taken as an indication that SUSE are even considering the below.
Would the users and contributors on this list be interested in a 100% matching SLE-like LTS distribution?
Yes. Though I would say just all _common_ packages should be the same. (Maybe a few exceptions for branding stuff or other things I don't know about yet.)
The main difference from Leap would be - absolutely no divergence from SLE, period - no additional community packages in the distribution
This "no additional" point is something I don't like as strict, but see below.
(ie. pretty much 1 tool for 1 task. One DE, One web server)
Isn't IceWM also in SLE?
- Release schedule that lags SLE (would only be able to release *AFTER* SLE, whereas Leap we can develop it WITH SLE because we're working together)
There would be no guarantee of a release-lifecycle any different from Leap, because such an idea could rely entirely on the sources made available to openSUSE via SUSE's contributions to Leap.
If the answer to the above is Yes the follow up questions are
Would you like this in addition to Leap, or instead of?
Leap (or whatever name) could just like an addon repo containing all the missing 7500 packages which are not in SLE. It should be still carefully maintained, fixed versions at the first release, updates only for very good reasons. Moreover if we could agree about 100% SLE base. Then it could be even easy to provide more than one such addon repo, like Leap-very-stable, Leap-fairly-stable. In other words "very-stable" would still look more like 42.1 while "fairly-stable" goes direction 42.3. These addon repos could be even valuable for regular SLE subscribers as I guess the actual SLE backport repos have only a small community and do not provide as many packages as Leap.) Note I do not think that all SLE packages are always better than Leap. I just think that the SLE package selection is big enough and fixed enough to cool down the Leap updaters for more stability if we restrict ourselves to not break that base.
What use cases would you use it for which Leap couldn't do?
I want a distro where self-built binaries don't break because of maintanance upgrades. This point is my most important point speaking as sysadmin. I don't want that my (mostly very advanced) users hate me. Also I want "source-compatibility", I mean that a software which builds fine on 42.1 should still build on 42.3. The best test for this is the OBS repo aleady. It should not be allowed that one packager breaks the package of another packager. Think about developers using Leap as CI build host.
Would this mean reducing the scope of Leap?
IMHO this would be exactly what I thought Leap is supposed to be. Moreover I would say this would make the scope bigger. Regarding the unhappy people who want more the newest stuff. IMO we should keep an eye of making more packages able to be installed in several versions in parallel, so that pulling from 3rd party repos is less painful.
Would you be willing to contribute to/release manage/help maintain/support such a distribution?
Yes, of course. On the other hand I will not provide any build fix anymore for current Leap, for example my sbcl package. This is waste of time IMHO. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org