Fwd: ACTION NEEDED: Understanding the current mood and trends among our contributors
This might be interesting to all. The survey is mostly intended for contributors, but the first line in it mentions users: «This is an informative survey to understand current mood and trends among our contributors and users..» So I have my doubts. -------- Forwarded Message -------- Subject: ACTION NEEDED: Understanding the current mood and trends among our contributors Date: Thu, 10 Aug 2023 12:53:21 +0000 From: Lubos Kocman via openSUSE Factory <factory@lists.opensuse.org> Reply-To: Lubos Kocman <lubos.kocman@suse.com> To: factory@lists.opensuse.org <factory@lists.opensuse.org> Hello openSUSE! In the past few weeks, a couple of different ideas have been proposed to define the future direction of the openSUSE Leap "successor" distribution. We've put together at the openSUSE ALP Leap Replacement Architecture meetings an informative survey to better understand the current mood and trends among our contributors and users. https://survey.opensuse.org/index.php?r=survey/index&sid=277484 We'd appreciate if get feedback from as many contributors as possible. ps. If you feel that you're both project as well as distribution contributor simply pick what you currently focus most at. Thank you very much in advance Best regards Lubos Kocman openSUSE Leap Release Manager
On 8/12/23 07:29, Carlos E. R. wrote:
This might be interesting to all.
The survey is mostly intended for contributors, but the first line in it mentions users:
«This is an informative survey to understand current mood and trends among our contributors and users..»
So I have my doubts.
Sad state of affairs, I suspect when Leap ends, this list will become even more desolate. SUSE, the openSUSE and then Leap have always offered an annual or semi-annual release and support of any one release for roughly twice the release cycle without forced upgrades. This has provided unmatched stability in a Llinux distro and provided the user a choice of whether to upgrade with each new release, or if time didn't permit, to wait for the next release while being confident in support of the current release. A rolling release, while good, can never provide the same assurance against surprises when the next 'zypper up' is done. Add the need for a proprietary video driver and the risk increases. SUSE/openSUSE has always been a traditional loosely FHS compliant distro that provided opportunity for users to configure and tweak their install to their liking. Provide their own kernel or kernel modules as needed. The misguided approach to ALP and/or MircoOS destroys that ability regulating the distro to basically a VM with containers hanging off it. This is further compromised by the coming default lockdown of the kernel. (yes it can be disabled) While this may serve the enterprise side of SUSE well, it alienates the openSUSE user. (or power-user if you will) Good luck modifying the VM or building your own container or adding your own kernel module for work with an embedded device. We have had an incredible 20 year run with a good group of devs and users. It's unfortunate that shifting priorities prize monetization over a traditional Linux offering. To contribute now, VM and container expertise will be a minimum. (just try to get your favorite web-application and database configured to run in a container and talk to the rest of the world, doable, but with *substantial* education and learning-curve required) I mean, if you want a locked down OS that is difficult to tweak to your liking there is always Windows, MacOS or Android. Linux, and SUSE/openSUSE in particular, has always stood in sharp contrast to that crowd (notwithstanding the 2005 deal). A containerized VM distro eliminates that distinction. There is no reason there can't be a Leap 15.7 ... 16.0 ... and on. And here is to hope that saner minds prevail and the traditional Linux offering continues. -- David C. Rankin, J.D.,P.E.
On Sat, 12 Aug 2023 17:31:53 -0500, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
Sad state of affairs, [...]
SUSE/openSUSE has always been a traditional loosely FHS compliant distro that provided opportunity for users to configure and tweak their install to their liking. Provide their own kernel or kernel modules as needed. The misguided approach to ALP and/or MircoOS destroys that ability regulating the distro to basically a VM with containers hanging off it. This is further compromised by the coming default lockdown of the kernel. (yes it can be disabled)
Of the three options for a successor to Leap presented in [1], none is containerized. Separately, openSUSE will also have a distribution that is a copy of the SUSE containerized distro, right? [1] https://survey.opensuse.org/index.php?r=survey/index&sid=277484 -- Robert Webb
On 2023-08-13 02:32, Robert Webb via openSUSE Users wrote:
On Sat, 12 Aug 2023 17:31:53 -0500, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
Sad state of affairs, [...]
SUSE/openSUSE has always been a traditional loosely FHS compliant distro that provided opportunity for users to configure and tweak their install to their liking. Provide their own kernel or kernel modules as needed. The misguided approach to ALP and/or MircoOS destroys that ability regulating the distro to basically a VM with containers hanging off it. This is further compromised by the coming default lockdown of the kernel. (yes it can be disabled)
Of the three options for a successor to Leap presented in [1], none is containerized. Separately, openSUSE will also have a distribution that is a copy of the SUSE containerized distro, right?
What about "Linarite"?
[1] https://survey.opensuse.org/index.php?r=survey/index&sid=277484
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Sun, 13 Aug 2023 12:09:56 +0200, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2023-08-13 02:32, Robert Webb via openSUSE Users wrote:
Of the three options for a successor to Leap presented in [1], none is containerized. Separately, openSUSE will also have a distribution that is a copy of the SUSE containerized distro, right?
What about "Linarite"?
The survey page [1] has a link to the Linarite description [2]. Two of its features are: - Won't use transactional updates - Won't use containers in the core of the OS, but will support running containerized workloads from ALP I interpret that as not requiring the use of containers, but maybe I'm wrong, and some desktop apps will only be available containerized. If most of the apps are just the containerized stuff pulled from SUSE, then I don't see the point in making the OS core different.
[1] https://survey.opensuse.org/index.php?r=survey/index&sid=277484 [2] https://hackweek.opensuse.org/22/projects/create-an-alp-based-leap-replaceme...
-- Robert Webb
Sun, 13 Aug 2023 11:25:13 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Sun, 13 Aug 2023 12:09:56 +0200, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2023-08-13 02:32, Robert Webb via openSUSE Users wrote:
Of the three options for a successor to Leap presented in [1], none is containerized. Separately, openSUSE will also have a distribution that is a copy of the SUSE containerized distro, right?
What about "Linarite"?
The survey page [1] has a link to the Linarite description [2]. Two of its features are: - Won't use transactional updates - Won't use containers in the core of the OS, but will support running containerized workloads from ALP
I interpret that as not requiring the use of containers, but maybe I'm wrong, and some desktop apps will only be available containerized. If most of the apps are just the containerized stuff pulled from SUSE, then I don't see the point in making the OS core different.
I don't even know what containerised really means, voted for slowroll. If it has anything to do with snap then it's bye-bye anyway; snap has limitations that I'm not prepared to accept (like home cannot be a link, it has this microsuck odor).
On Sun, 13 Aug 2023 07:59:06 -0400, bent fender <ksusup@trixtar.org> wrote:
Sun, 13 Aug 2023 11:25:13 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
The survey page [1] has a link to the Linarite description [2]. Two of its features are: - Won't use transactional updates - Won't use containers in the core of the OS, but will support running containerized workloads from ALP
I interpret that as not requiring the use of containers, but maybe I'm wrong, and some desktop apps will only be available containerized. If most of the apps are just the containerized stuff pulled from SUSE, then I don't see the point in making the OS core different.
I don't even know what containerised really means, voted for slowroll. If it has anything to do with snap then it's bye-bye anyway; snap has limitations that I'm not prepared to accept (like home cannot be a link, it has this microsuck odor).
From the Linarite (ex Grassy Knoll) page discussion: Unanswered Questions: * Desktop apps - SUSE's ALP will likely use Flatpaks, if these are built on OBS, it may be possible to build rpm versions from the same source. It is also likely that some openSUSE contributors will prefer to ship their applications as rpms. So Ideally we want to support both. -- Robert Webb
On 2023-08-13 07:59, bent fender wrote:
Sun, 13 Aug 2023 11:25:13 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Sun, 13 Aug 2023 12:09:56 +0200, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2023-08-13 02:32, Robert Webb via openSUSE Users wrote:
Of the three options for a successor to Leap presented in [1], none is containerized. Separately, openSUSE will also have a distribution that is a copy of the SUSE containerized distro, right?
What about "Linarite"?
The survey page [1] has a link to the Linarite description [2]. Two of its features are: - Won't use transactional updates - Won't use containers in the core of the OS, but will support running containerized workloads from ALP
I interpret that as not requiring the use of containers, but maybe I'm wrong, and some desktop apps will only be available containerized. If most of the apps are just the containerized stuff pulled from SUSE, then I don't see the point in making the OS core different.
I don't even know what containerised really means, voted for slowroll. If it has anything to do with snap then it's bye-bye anyway; snap has limitations that I'm not prepared to accept (like home cannot be a link, it has this microsuck odor).
I finally completed watching the video "There's a mountain to climb: openSUSE's response to SUSE ALP", and I did not see an explanation of Linarite or Slowroll. I may have missed it, I prefer written content. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
Sat, 26 Aug 2023 08:56:54 -0400 "Carlos E. R." <robin.listas@gmx.es> :
On 2023-08-13 07:59, bent fender wrote:
Sun, 13 Aug 2023 11:25:13 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Sun, 13 Aug 2023 12:09:56 +0200, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2023-08-13 02:32, Robert Webb via openSUSE Users wrote:
Of the three options for a successor to Leap presented in [1], none is containerized. Separately, openSUSE will also have a distribution that is a copy of the SUSE containerized distro, right?
What about "Linarite"?
The survey page [1] has a link to the Linarite description [2]. Two of its features are: - Won't use transactional updates - Won't use containers in the core of the OS, but will support running containerized workloads from ALP
I interpret that as not requiring the use of containers, but maybe I'm wrong, and some desktop apps will only be available containerized. If most of the apps are just the containerized stuff pulled from SUSE, then I don't see the point in making the OS core different.
I don't even know what containerised really means, voted for slowroll. If it has anything to do with snap then it's bye-bye anyway; snap has limitations that I'm not prepared to accept (like home cannot be a link, it has this microsuck odor).
I finally completed watching the video "There's a mountain to climb: openSUSE's response to SUSE ALP", and I did not see an explanation of Linarite or Slowroll. I may have missed it, I prefer written content.
But that WAS in a Suse writen guide about the topic, I shudda quoted it, too late now. I think it meant a roller like TW but not updated every minute like. After all except for devs a roller never meant instant updates but *a lack of release versions* as such and if the cart is not to go in front of the horse then this latter definition being closer to users rulez.
On 8/13/23 20:55, Robert Webb via openSUSE Users wrote:
On Sun, 13 Aug 2023 12:09:56 +0200, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2023-08-13 02:32, Robert Webb via openSUSE Users wrote:
Of the three options for a successor to Leap presented in [1], none is containerized. Separately, openSUSE will also have a distribution that is a copy of the SUSE containerized distro, right?
What about "Linarite"?
The survey page [1] has a link to the Linarite description [2]. Two of its features are: - Won't use transactional updates - Won't use containers in the core of the OS, but will support running containerized workloads from ALP
I interpret that as not requiring the use of containers, but maybe I'm wrong, and some desktop apps will only be available containerized. If most of the apps are just the containerized stuff pulled from SUSE, then I don't see the point in making the OS core different.
As the person who wrote that part, you interpret it correctly. The aim is not to use containerised packages / apps / flatpaks unless there are certain apps that no one in the community steps up to maintain. Especially in the desktop area its not clear how much of what was in SLED will continue to be offered in the "Traditional" SUSE ALP Based distro so its one area where the openSUSE Community might need more help. If you have more questions i'll try and pay attention to this thread. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 8/12/23 15:31, David C. Rankin wrote:
I mean, if you want a locked down OS that is difficult to tweak to your liking there is always Windows, MacOS or Android. Linux, and SUSE/openSUSE in particular, has always stood in sharp contrast to that crowd (notwithstanding the 2005 deal). A containerized VM distro eliminates that distinction.
Rhetorical question: Was SystemD the camel's nose under the Linux tent flap? Regards, Lew
On 2023-08-13 15:03, Lew Wolfgang wrote:
On 8/12/23 15:31, David C. Rankin wrote:
I mean, if you want a locked down OS that is difficult to tweak to your liking there is always Windows, MacOS or Android. Linux, and SUSE/openSUSE in particular, has always stood in sharp contrast to that crowd (notwithstanding the 2005 deal). A containerized VM distro eliminates that distinction.
Rhetorical question: Was SystemD the camel's nose under the Linux tent flap?
Not quite so rhetorical: Name all the distros that do not use systemd.
On Sun, 13 Aug 2023 at 22:21, Darryl Gregorash <raven@accesscomm.ca> wrote:
Not quite so rhetorical: Name all the distros that do not use systemd.
Quite a few. Alpine, antiX, ChromeOS Flex, Crux, Gentoo, GoboLinux, MX Linux, PCLinuxOS, Slackware, TinyCore, Void... I am sure I've missed some I've never looked at, but I've tried all of those. I have reviewed half a dozen of them professionally. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
Tue, 15 Aug 2023 15:11:58 +0100 Liam Proven <lproven@gmail.com> :
On Sun, 13 Aug 2023 at 22:21, Darryl Gregorash <raven@accesscomm.ca> wrote:
Not quite so rhetorical: Name all the distros that do not use systemd.
Quite a few.
Alpine, antiX, ChromeOS Flex, Crux, Gentoo, GoboLinux, MX Linux, PCLinuxOS, Slackware, TinyCore, Void... I am sure I've missed some I've never looked at, but I've tried all of those. I have reviewed half a dozen of them professionally.
Artix & Devuan, both very good here
On 2023-08-15 08:16, bent fender wrote:
Tue, 15 Aug 2023 15:11:58 +0100 Liam Proven <lproven@gmail.com> :
On Sun, 13 Aug 2023 at 22:21, Darryl Gregorash <raven@accesscomm.ca> wrote:
Not quite so rhetorical: Name all the distros that do not use systemd.
Quite a few.
Alpine, antiX, ChromeOS Flex, Crux, Gentoo, GoboLinux, MX Linux, PCLinuxOS, Slackware, TinyCore, Void... I am sure I've missed some I've never looked at, but I've tried all of those. I have reviewed half a dozen of them professionally.
Artix & Devuan, both very good here And of all of these, how many have any significance in the Linux world?
Tue, 15 Aug 2023 13:17:18 -0600 Darryl Gregorash <raven@accesscomm.ca> :
On 2023-08-15 08:16, bent fender wrote:
Tue, 15 Aug 2023 15:11:58 +0100 Liam Proven <lproven@gmail.com> :
On Sun, 13 Aug 2023 at 22:21, Darryl Gregorash <raven@accesscomm.ca> wrote:
Not quite so rhetorical: Name all the distros that do not use systemd.
Quite a few.
Alpine, antiX, ChromeOS Flex, Crux, Gentoo, GoboLinux, MX Linux, PCLinuxOS, Slackware, TinyCore, Void... I am sure I've missed some I've never looked at, but I've tried all of those. I have reviewed half a dozen of them professionally.
Artix & Devuan, both very good here And of all of these, how many have any significance in the Linux world?
That was never one of my criteriae in choice of OS
On 2023-08-15 17:58, bent fender wrote:
Tue, 15 Aug 2023 13:17:18 -0600 Darryl Gregorash <raven@accesscomm.ca> :
On 2023-08-15 08:16, bent fender wrote:
Tue, 15 Aug 2023 15:11:58 +0100 Liam Proven <lproven@gmail.com> :
On Sun, 13 Aug 2023 at 22:21, Darryl Gregorash <raven@accesscomm.ca> wrote:
Not quite so rhetorical: Name all the distros that do not use systemd.
Quite a few.
Alpine, antiX, ChromeOS Flex, Crux, Gentoo, GoboLinux, MX Linux, PCLinuxOS, Slackware, TinyCore, Void... I am sure I've missed some I've never looked at, but I've tried all of those. I have reviewed half a dozen of them professionally.
Artix & Devuan, both very good here And of all of these, how many have any significance in the Linux world?
That was never one of my criteriae in choice of OS
Nor did I try to imply in what I said that it should be. However, the size of any distro's userbase will have significant impact on whether or not one will be able to find support for any obscure issues that always seem to arise in any Linux distro. And finally, how long will any given distro last, if it has a very small list of developers? How long before they grow tired, and move on to something else?
Tue, 15 Aug 2023 18:18:32 -0600 Darryl Gregorash <raven@accesscomm.ca> :
On 2023-08-15 17:58, bent fender wrote:
Tue, 15 Aug 2023 13:17:18 -0600 Darryl Gregorash <raven@accesscomm.ca> :
On 2023-08-15 08:16, bent fender wrote:
Tue, 15 Aug 2023 15:11:58 +0100 Liam Proven <lproven@gmail.com> :
On Sun, 13 Aug 2023 at 22:21, Darryl Gregorash <raven@accesscomm.ca> wrote:
Not quite so rhetorical: Name all the distros that do not use systemd.
Quite a few.
Alpine, antiX, ChromeOS Flex, Crux, Gentoo, GoboLinux, MX Linux, PCLinuxOS, Slackware, TinyCore, Void... I am sure I've missed some I've never looked at, but I've tried all of those. I have reviewed half a dozen of them professionally.
Artix & Devuan, both very good here And of all of these, how many have any significance in the Linux world?
That was never one of my criteriae in choice of OS
Nor did I try to imply in what I said that it should be. However, the size of any distro's userbase will have significant impact on whether or not one will be able to find support for any obscure issues that always seem to arise in any Linux distro. And finally, how long will any given distro last, if it has a very small list of developers? How long before they grow tired, and move on to something else?
Seeing systemd as a distinct threat to the kernel itself I'll stick with those who are for a choice, but I'm not that interested in convincing anyone of anything. -- We live in the epoch of total credibility meltdown; everyone is lying about everything all the time
On 8/15/23 20:17, Darryl Gregorash wrote:
On 2023-08-15 19:17, bent fender wrote:
Seeing systemd as a distinct threat to the kernel itself I'll stick with those who are for a choice, but I'm not that interested in convincing anyone of anything.How is systemd a threat to the kernel?
Of course I can't speak for Mr Fender, but I think I know what he was referring to. It's perceived by many that systemd is in violation of the UNIX Philosophy, where programs should do only one thing, but do that one thing very well. Wikipedia has an extensive description: https://en.wikipedia.org/wiki/Unix_philosophy systemd strives to incorporate many functions into one binary blob. I'm not saying this is necessarily bad, but it's not UNIX. The concern then arises that with an expanding systemd it will encroach farther into kernel territory, that carried to its logical extreme will completely push out the kernel. systemd then becomes the operating system, the thought of which concerns many. I'm not saying I agree with all this, I don't know enough one way or the other. But listening to the complaints over the years has given me this impression. Regards, Lew
On 8/15/23 20:17, Darryl Gregorash wrote:
On 2023-08-15 19:17, bent fender wrote:
Seeing systemd as a distinct threat to the kernel itself I'll stick with those who are for a choice, but I'm not that interested in convincing anyone of anything.How is systemd a threat to the kernel?
Of course I can't speak for Mr Fender, but I think I know what he was referring to.
It's perceived by many that systemd is in violation of the UNIX Philosophy, where programs should do only one thing, but do that one thing very well. Wikipedia has an extensive description:
https://en.wikipedia.org/wiki/Unix_philosophy Such people must have felt greatly threatened when such packages as LibreOffice started showing up on the scene. There is absolutely no relationship between a word processor and a DBMS, yet LO and all others
On 2023-08-15 23:22, Lew Wolfgang wrote: like it can do both, and plenty more besides.
systemd strives to incorporate many functions into one binary blob. I'm
not saying this is necessarily bad, but it's not UNIX. The concern then arises that with an expanding systemd it will encroach farther into kernel territory, that carried to its logical extreme will completely push out the kernel. systemd then becomes the operating system, the thought of which concerns many. More nonsense. Again, a cursory inspection of the systemd control files shows nothing to suggest there is any encroachment whatsoever into kernel territory. The oS developers here are certainly in a far better
Nonsense, which even the most cursory inspection of any systemd control file will show (the systemd control files are all stored in /usr/lib/systemd and sub-folders). All systemd does is to ensure that everything is started in an orderly fashion, that no service gets started until all of its requirements have been met. For example, if a service must not be started before the network is fully configured, it will contain a "requires" or "after" statement to that effect. The service itself is started by the appropriate script or executable included in the software package. For example, here is the control file for D-Bus: [Unit] Description=D-Bus System Message Bus Documentation=man:dbus-daemon(1) Requires=dbus.socket RefuseManualStart=true RefuseManualStop=true [Service] ExecStart=/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only ExecReload=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 The D-Bus service requires a listening socket, so the daemon cannot be started until that socket is present. Only then does systemd load the daemon that actually does all the work. position than I am to address such issues, but IMO, any suggestion that systemd is somehow "out to replace" the kernel is nothing but FUD.
Tue, 15 Aug 2023 22:22:49 -0700 Lew Wolfgang <wolfgang@sweet-haven.com> :
On 8/15/23 20:17, Darryl Gregorash wrote:
On 2023-08-15 19:17, bent fender wrote:
Seeing systemd as a distinct threat to the kernel itself I'll stick with those who are for a choice, but I'm not that interested in convincing anyone of anything.How is systemd a threat to the kernel?
Of course I can't speak for Mr Fender, but I think I know what he was referring to.
It's perceived by many that systemd is in violation of the UNIX Philosophy, where programs should do only one thing, but do that one thing very well. Wikipedia has an extensive description:
I'm yet to be convinced that any part of UNIX philosophy would be of any interest the the dev(s) of systemd. As far as I'm concerned it's cutting far too wide a swath and if that keeps up then sooner than later the systemd people will be telling the kernel people what time it is and how to do it all. Too, I find it susepect that some groups or layers in the community offer a choice (see Artix) from three or four inits while others offer only one, now THAT is definitely against everything Linux that ever was (except for the kernel itself). -- War is the school of peace.
From: bent fender <ksusup@trixtar.org> Date: Wed, 16 Aug 2023 07:07:53 -0400 Tue, 15 Aug 2023 22:22:49 -0700 Lew Wolfgang <wolfgang@sweet-haven.com> :
It's perceived by many that systemd is in violation of the UNIX Philosophy, where programs should do only one thing, but do that one thing very well. Wikipedia has an extensive description:
I'm yet to be convinced that any part of UNIX philosophy would be of any interest the the dev(s) of systemd. As far as I'm concerned it's cutting far too wide a swath and if that keeps up then sooner than later the systemd people will be telling the kernel people what time it is and how to do it all. That sounds like an objection over the project rather than the software. I remember the bad old days when you had to edit a file to get something to start/restart on boot, which was not at all package- friendly. SysV init files were better, but the handling of dependencies and failures was ad hoc at best, so systemd is a definite improvement over both. I still get lost when trying to figure out what's going on inside systemd, but that may be a symptom of the fact that it works better; I need to figure things out less often, so I keep forgetting how things work. Too, I find it susepect that some groups or layers in the community offer a choice (see Artix) from three or four inits while others offer only one, now THAT is definitely against everything Linux that ever was (except for the kernel itself). That may have to do with ease of support (just a guess, since I don't know what the alternatives are). A corollary of the Unix maxim of "do one thing and do it well" is that those things need to be orthogonal, and orthogonality also suits package-based distros. systemd seems to play really well with packaged services. -- Bob Rogers http://www.rgrjr.com/
On Sat, Aug 12, Carlos E. R. wrote:
This might be interesting to all.
The survey is mostly intended for contributors, but the first line in it mentions users:
«This is an informative survey to understand current mood and trends among our contributors and users..»
So I have my doubts.
Nice to see them _asking questions_. However, has anyone spelled out exactly _why_ Leap, as we've known it for several years now is "untenable", but Tumbleweed is just fine? And for those of us that pretty much update...never? Unless some vuln which actually threatens my _actual_ setup is pertinent? What is the "best choice" then? Michael -- Michael Fischer michael@visv.net
Out of curiosity, have you watched the "There's a mountain to climb: openSUSE's response to SUSE ALP" talk from a couple months ago? https://www.youtube.com/watch?v=-y2ewBG62J4 My possibly wrong, definitely oversimplified interpretation: 1. openSUSE Tumbleweed is upstream of SUSE enterprise products 2. SUSE produces enterprise products 3. openSUSE Leap is downstream of SUSE enterprise products So if SUSE is changing the enterprise products they produce, then something different needs to be done by openSUSE to continue producing the "same" / analogous products as they had historically done.
On Thu, Aug 17, 2023 at 3:49 PM John Kizer via openSUSE Users < users@lists.opensuse.org> wrote:
Out of curiosity, have you watched the "There's a mountain to climb: openSUSE's response to SUSE ALP" talk from a couple months ago?
To add one more context to the discussion, have others seen the news today that SUSE is going Private? https://opensourcewatch.beehiiv.com/p/suse-go-private I was catching up with this discussion and wondering what it means for openSUSE. I enjoyed the video hint from John, as Richard talks about where openSUSE can go at the end. Then the news of the company being taken private came out at the same time (for me) and it seemed like a strange coincidence. I don't have a good feeling about it, but I hope my concerns are exaggerated. -- Carlos F Lange Gaúcho nas Pradarias https://sites.google.com/site/carlosflange/
On Fri, Aug 18, 2023 at 12:24 AM Carlos F. Lange <carlosflange@gmail.com> wrote:
To add one more context to the discussion, have others seen the news today that SUSE is going Private? https://opensourcewatch.beehiiv.com/p/suse-go-private
I was catching up with this discussion and wondering what it means for openSUSE.
Gerald Pfeifer answered my question in the other mailing-list
(opensuse-project). Copying his answer here for completion: Hello fellow Geekos, by now you have likely seen the news that openSUSE's main sponsor, SUSE, is expected to delist from the Frankfurt Stock Exchange and once again become a private company: https://www.suse.com/news/EQT-announces-voluntary-public-purchase-offer-and-... <https://www.suse.com/news/EQT-announces-voluntary-public-purchase-offer-and-intention-to-delist-SUSE/> I have been personally assured this will have no negative impacts on openSUSE. SUSE's sponsorship of community projects like openSUSE is not changing. SUSE remains committed to supporting the openSUSE community. Any questions, feel free to reach out. Have a wonderful day, thank you for your involvement with the openSUSE project, and have a lot of fun! Gerald Dr. Gerald Pfeifer gp@suse.com, CTO @SUSE + chair @openSUSE -- Carlos F Lange Gaúcho nas Pradarias https://sites.google.com/site/carlosflange/
IIRC it has something to do with the workload involved in packaging and a dearth of people with packaging experience and availability? Not sure why the new paradigm solves this, unless it involves just dropping in e.g. flatpaks? Leslie On 2023-08-17 15:55:44 Michael Fischer wrote:
Nice to see them _asking questions_.
However, has anyone spelled out exactly _why_ Leap, as we've known it for several years now is "untenable", but Tumbleweed is just fine?
And for those of us that pretty much update...never? Unless some vuln which actually threatens my _actual_ setup is pertinent? What is the "best choice" then?
Michael
-- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
Hi, On 8/17/23 16:55, Michael Fischer wrote:
On Sat, Aug 12, Carlos E. R. wrote:
This might be interesting to all.
The survey is mostly intended for contributors, but the first line in it mentions users:
«This is an informative survey to understand current mood and trends among our contributors and users..»
So I have my doubts.
Nice to see them _asking questions_.
However, has anyone spelled out exactly _why_ Leap, as we've known it for several years now is "untenable",
Well from my perspective it is all a bunch of premature hoopla. When the topic was started there was even less direction to ALP than there is today. While the direction of ALP is maturing, see the announcements at SUSECon there is still much uncertainty about how the puzzle pieces fit together. With the decision made that there will be a General purpose Enterprise distribution there's nothing really in the way to have Leap as it is known today. Well the internals of the distro will probably be different than today, but again what that looks like for the Enterprise distro is still a topic of conversation. And how this may be applied to Leap is of course up to the community. Bottom line is, more patience is required.
but Tumbleweed is just fine?
And for those of us that pretty much update...never? Unless some vuln which actually threatens my _actual_ setup is pertinent? What is the "best choice" then?
That can only be answered when we get closer to knowing what Granite, the general Enterprise distribution will lok like and how many people are interested to build a community distribution from/with/on-top-of it. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX rjschwei@suse.com IRC: robjo
participants (15)
-
bent fender -
Bob Rogers -
Carlos E. R. -
Carlos E. R. -
Carlos F. Lange -
Darryl Gregorash -
David C. Rankin -
J Leslie Turriff -
John Kizer -
Lew Wolfgang -
Liam Proven -
Michael Fischer -
Robert Schweikert -
Robert Webb -
Simon Lees