Peter, et al -- ...and then Peter McD said... % Am 07.10.22 um 11:47 schrieb Carlos E. R.: % > % > What other distribution is out there we can easily migrate to? % ... % techies deploying Linux servers expect to use containers managed by % systemd – it's how modern cloudy workloads are run. " % % It might not be the question of whether one migrates but when one adapts. Agreed. But <footstomp> I don't want to have to waste that kind of overhead on my puny budget-constrained machine and <whine> I don't have the time to be a Real SysAdmin any more! I just want a simple Linux that's easy to use for my limited needs. <sulk> % % Peter HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

On Fri, Oct 07, 2022 at 11:47:03AM +0200, Carlos E. R. wrote:

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article

:-/

What other distribution is out there we can easily migrate to?

Please understand this is the first of many prototypes of the platform. This use-case shows the part of a Micro Operating systems mostly, not the other use-case like full distribution or containers and similar. Ciao, Marcus

On 10/7/22 07:35, Carlos E. R. wrote:

On 2022-10-07 13:23, Marcus Meissner wrote:

...

On Fri, Oct 07, 2022 at 11:47:03AM +0200, Carlos E. R. wrote:

...

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article

:-/

What other distribution is out there we can easily migrate to?

Please understand this is the first of many prototypes of the platform.

This use-case shows the part of a Micro Operating systems mostly, not the other use-case like full distribution or containers and similar.

Anything "container" or similar, and I have to migrate to some other distro that does traditional packaging.

It's called Tumbleweed Also the containers, at least along the current trajectory, will be build from packages, i.e. RPM packages as we know them are not going extinct. That means there is nothing in the way of the community to build a distribution that looks like Leap today. And as a side note, nobody has to migrate because of containers, but certainly people will choose to migrate because of personal preference. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo

Le 07/10/2022 à 13:46, Robert Schweikert a écrit :

That means there is nothing in the way of the community to build a distribution that looks like Leap today.

Such a distribution actually exists. It's called OpenSUSE Leap. #duh :o) -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

On 07.10.22 13:23, Marcus Meissner wrote:

On Fri, Oct 07, 2022 at 11:47:03AM +0200, Carlos E. R. wrote:

...

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article

...

What other distribution is out there we can easily migrate to?

Please understand this is the first of many prototypes of the platform.

Hello Marcus, it is nice that SuSE is planning to have a good understanding and support of containerized services, ... but, there are two ways to use a Linux system. * The provider of services (aka server) where containerized can be useful. SuSE is addressing that now to show they are first class for cloud environments. * The workstation where containerized is questionable and makes life harder. If you develop on the local machine you want the full Linux system and not just some box for you. Containers might be usable for some additional services (docker,..) when testing, but the main system incl Desktop must be the main system. And the root partition cannot be read-only and with an enforced filesystem type. The filesystem is a matter of earned trust and I for example still do not trust btrfs because it failed for me multiple times. Maybe this is a lack of communication from SuSE, but what is the idea or model of work for developers of eg. kernel parts or others who need a classic Unix like environment? How is Desktop use fitting into the picture? How do multi-boot systems fit into that? (multiple linux instances + windows + shared filesystems across the installations) How about uprooting KDE/Gnome as far as possible and running a different desktop like XFCE because it is slim and fast? You now have a White Paper for ALPs with a server install + containerized services. Could SuSE please compile a similar document for the workstation use case? Thank you.

On Fri, 7 Oct 2022 14:53:00 +0200 Daniel Bauer wrote:

When Linux forces me to use filesystems I don't want, beneath other things, then one can as well downgrade to Windows. It might even be more stable.

Let's archive everything Linux going back decades, never know when we may have to backlevel (as IBM used to call it). Which makes me wonder, maybe Warp again (worst case scenario)?

On Fri, 7 Oct 2022 12:21:13 -0400 James Knott wrote:

On 2022-10-07 10:19, bent fender wrote:

...

On Fri, 7 Oct 2022 14:53:00 +0200 Daniel Bauer wrote:

...

When Linux forces me to use filesystems I don't want, beneath other things, then one can as well downgrade to Windows. It might even be more stable. Let's archive everything Linux going back decades, never know when we may have to backlevel (as IBM used to call it). Which makes me wonder, maybe Warp again (worst case scenario)?

I have boxes of both Warp 4 and Warp Server here.  I also have a Warp 4 VM on my ThinkPad.  😉

Survivalists also pack AK-47's :-) I think I went form C64 to Apple-II, to Amiga and then briefly windows and warp before Linux. But I didn't keep anything other then windows 95, 96, 7. Soon after moving to Suse around 5.3 there was a huge crew-change, the writing was already on the wall.

On 08/10/2022 05:51, Liam Proven wrote:

On Fri, 7 Oct 2022 at 18:21, James Knott wrote:

...

I have boxes of both Warp 4 and Warp Server here. I also have a Warp 4 VM on my ThinkPad. 😉

Funny you should say that. Aside from the Linux stuff for the Reg, at the top of this thread, I also have a tech blog, and my last post was about OS/2 because I've been playing with it again this week.

There is a modern version of OS/2 called ArcaOS from Arca Noae. Their website is down right now because HackerNews just discovered it.

But the _previous_ spinoff of OS/2 was called eComStation. There is a free-to-download copy on the Internet Archive:

https://archive.org/details/ecomstation2.1

I installed it on an old Thinkpad X61 this week and have been playing around with it. I can confirm the download works fine, and as far as I know, the parent company has gone out of business.

Ha! I have eComStation running in a VM as a guest on Leap. It has a few lumps, but is OK for historical (nostalgic) purposes. -- Robin K Wellington "Harbour City" New Zealand

Am Sonntag, 9. Oktober 2022, 03:54:30 CEST schrieb James Knott:

No need for that. I have the original, in box, IBM official CD for Warp 4.

say no more - i gotta find mine. cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

On Friday, October 7, 2022, 07:20:25 AM PDT, bent fender wrote:

Let's archive everything Linux going back decades, never know when we may have to backlevel (as IBM used to call it). Which makes me wonder, maybe Warp again (worst case scenario)?

Yeah, just containerize that stuff.  ;-) -- Robert Webb

On 10/7/22 04:47, Carlos E. R. wrote:

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article

:-/

What other distribution is out there we can easily migrate to?

I'm just switching over to my Arch boxes, or Debian Pis. All distros have there pluses or minuses. Arch is a phenomenal, rock solid, KISS philosophy Linux distribution. pacman package manager is absolutely simple and easy to use (note: no 'k'). Much like zypper from the command line. Debian is also a good choice. Like it. apt and dpkg from the command line are also workable, though take a bit more learning than pacman. But Debian does have non-free for codecs (like our packman). I'm not a fan of creating debian packages, but that is also doable. There are a lot of newer distros out in the last 6-7 years I haven't even tried yet, but after being whip-sawed by my distro of choice, I'm sticking to the distros least likely to change. My hope is we can do 15.5 as a LTS or Evergreen release so I can stay with openSUSE for a couple more years. SUSE Devs -- you listening? 15.5 LTS or Evergreen. Keep it going for a while for those of us who have contributed two decades to testing and improving your product. That will allow us all to part on good terms. -- David C. Rankin, J.D.,P.E.

On Sat, Oct 08, 2022 at 12:49:39PM +0200, Carlos E. R. wrote:

On 2022-10-08 03:13, David C. Rankin wrote:

...

On 10/7/22 04:47, Carlos E. R. wrote:

...

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article

:-/

What other distribution is out there we can easily migrate to?

I'm just switching over to my Arch boxes, or Debian Pis. All distros have there pluses or minuses. Arch is a phenomenal, rock solid, KISS philosophy Linux distribution. pacman package manager is absolutely simple and easy to use (note: no 'k'). Much like zypper from the command line.

Debian is also a good choice. Like it. apt and dpkg from the command line are also workable, though take a bit more learning than pacman. But Debian does have non-free for codecs (like our packman). I'm not a fan of creating debian packages, but that is also doable.

How does Arch do codecs stuff?

...

There are a lot of newer distros out in the last 6-7 years I haven't even tried yet, but after being whip-sawed by my distro of choice, I'm sticking to the distros least likely to change.

Of course.

...

My hope is we can do 15.5 as a LTS or Evergreen release so I can stay with openSUSE for a couple more years.

SUSE Devs -- you listening? 15.5 LTS or Evergreen. Keep it going for a while for those of us who have contributed two decades to testing and improving your product. That will allow us all to part on good terms.

I will have to install whatever as a double boot while I learn the ropes on another distro.

Please understand that ALP is a platform, which is under design and development. We will very likely again build a regular Leap like distribution on top of this platform. No need for FUD. Ciao, Marcus

Le 08/10/2022 à 13:46, Carlos E. R. a écrit :

If I have to containerize my computer, then I have to seek another distro.

why? why refuse a system nobody knows for sure? let things happen. I'm pretty sure SUSE wont cut out they clients :-) by the way if the system works really well, all distros will use it jdd -- mon serveur usenet: dodin.fr.nf c'est quoi, usenet? http://www.dodin.org/wiki/pmwiki.php?n=Usenet.Usenet

On Sat, 8 Oct 2022 at 20:32, Carlos E. R. wrote:

With the little information that we have, I know that I do not want to make my system a container.

It means, for instance, that I no longer can choose the filesystem of root. This is clear in the posted article.

I wrote the article, based entirely on info made publicly available by SUSE. I left SUSE to go work for the Register in October, before this process started. So I can assure you that I have no special inside information or insight here. But, personally, I share your concern. I ran SUSE myself in the late 1990s and early noughties, and it was a pleasure to return to using it while I worked for the company. It's a good, solid distro, Leap especially. I will say, though, looking at multiple distros every day for a living now, that changes are happening in many distros that are making users unhappy. A lot of Ubuntu users are abandoning it. People do not like Snap and snap packaging and many Ubuntu derivatives are replacing or even removing Snap support. Red Hat fans are unhappy with CentOS Linux being discontinued, and some are unhappy with the focus on Wayland. Before that they were unhappy with YUM being replaced with DNF. Debian fans remain unhappy about systemd. *Everyone's* unhappy about systemd. The only openSUSE spinoff I know is GeckoLinux, which is very good and which I really like... and the GeckoLinux creator has launched a Debian spinoff now. That could be a bad sign...? I am concerned about SUSE's dependence on Btrfs, because I don't like or trust Btrfs myself. I feel the company should invest much more effort in ensuring that Snapper works with other COW-capable filesystems as well, such as ZFS, bcachefs and so on. The point of Linux is modularity and replaceable components. YaST needs some more love, too. It is a unique strength of SUSE and it's neglected. The ability to just disable containers etc. in MicroOS and install an ordinary monolithic userland on it would be very good and reassure people who like the older-style OS. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

On Sun, 9 Oct 2022 at 14:37, Nicolas Kovacs wrote:

Free software being what is is, CentOS' original founder has launched Rocky Linux the same day CentOS announced what they called a "shift in paradigm".

I know. I interviewed them.

I'm currently working on a custom version of Rocky Linux with KDE pulled in from EPEL and quite some other stuff. It's starting to look good, and it might well be my replacement for OpenSUSE Leap. It's only missing about half a dozen more exotic packages, but I can build that stuff easily from Fedora SRPMS.

That seems like a very hard way to do it. Why pick a distro that doesn't include KDE and then go to extra work to add it? If you just want an RPM-based distro with KDE, why not Fedora? If you want a more stable, non-Red Hat bleeding-edge distro that has KDE, then any of the Mandriva remixes will give you that: OpenMandriva or Mageia. PC Linux OS is pretty good and also systemd-free, I believe. ROSA Linux looks OK but it's Russian, which these days you might want to avoid. If you do not require RPM-based, then there is Kubuntu. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

On Tue, 11 Oct 2022 at 00:17, Nicolas Kovacs wrote:

EPEL's implementation of KDE is one of the cleanest out there. Way better than most of the "official" versions.

I stopped using KDE after version 2.0, which for me was way too bloated and over-complex. So I do not know how you mean; could you explain?

Fedora's a moving target. Not my thing.

OK, I can see that.

These two distributions have a great future behind them.

:-D Harsh. Not completely unfair, though. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

On Tue, 11 Oct 2022 at 15:05, Patrick Shanahan wrote:

I believe that if you would bother to check more closely, KDE is quite prudent in it's memory usage, re: "bloated".

I mildly point out that I am, as far as I know, the only person to have conducted memory comparisons of different desktops on top of the same Linux distro and published the results. Here is the first time I did it: https://www.theregister.com/Print/2013/04/26/xbuntu_round_up/ As the URL indicates, this was in 2013, and if you look at the table, KDE is by a considerable margin the most inefficient desktop on offer, using both more RAM *and* more disk space. That was KDE 4.10. I stand by my words and my assessment. However, saying that, this year, I conducted the tests again, and again, I have published the results. https://www.theregister.com/2022/08/18/ubuntu_remixes/ KDE 5 is a lot more efficient and now it's one of the better choices. However, I was not in fact talking about resource usage in my email, but features, configuration options and UI bloat. There, once again, I stand by my assessment. I think KDE is a fairly poor desktop from this perspective. In recent versions, useful functionality such as the ability to span a single panel across >1 monitor have been removed, whereas there are now multiple web browsers, multiple file manager, some apps have menu bars and some do not, and generally the UI is inconsistent and messy, and the situation is not improving. I have published criticism of this, as well. https://www.theregister.com/2022/02/09/plasma_524/ However, I appreciate that these things are subjective judgements and I know that many people like KDE. I merely point out that I have attempted to _measure_ some of this and published the results. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

Liam, et al -- ...and then Liam Proven said... % On Sat, 8 Oct 2022 at 20:32, Carlos E. R. wrote: % ... % > It means, for instance, that I no longer can choose the filesystem of % > root. This is clear in the posted article. % ... % % I will say, though, looking at multiple distros every day for a living % now, that changes are happening in many distros that are making users % unhappy. Wow. wtf?!? OK, so there's a lot I don't understand any more after being out of the trenches, and disruption is fun, but ... wow. % ... % % *Everyone's* unhappy about systemd. +1 :-) ... % % The ability to just disable containers etc. in MicroOS and install an % ordinary monolithic userland on it would be very good and reassure % people who like the older-style OS. Personally, I think this is probably a good approach. I could perhaps even tolerate allowing the OS to have its btrfs root (and /usr and basically other OS-only immutable stuff) and back up with rsync and then just reinstall when something blows up, while everything else is on a sane filesystem (O how I weep for reiserfs!). But I know I won't have time to configure and build and maintain it. I need it all tied up with a bow for me :-/ So I'm watching the fleeing closely to see by majority consensus where I'll end up *sigh* % % -- % Liam Proven ~ Profile: https://about.me/liamproven % Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com % Twitter/LinkedIn: lproven ~ Skype: liamproven % UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 HANW :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

On 2022-10-10 13:28, Robert Schweikert wrote:

On 10/8/22 14:32, Carlos E. R. wrote:

...

On 2022-10-08 18:27, jdd@dodin.org wrote:

...

Le 08/10/2022 à 13:46, Carlos E. R. a écrit :

...

If I have to containerize my computer, then I have to seek another distro.

why? why refuse a system nobody knows for sure?

let things happen. I'm pretty sure SUSE wont cut out they clients :-)

by the way if the system works really well, all distros will use it

With the little information that we have, I know that I do not want to make my system a container.

It means, for instance, that I no longer can choose the filesystem of root. This is clear in the posted article.

And another attempt, but I guess fear has taken over and as such rational arguments no longer arrive.

One should be able the difference between "Platform" in the context of AL-PLATFORM a way to build stuff that allows the flexible composition of other "Offers", i.e. things that others consume.

So the first build has BTRFS and BTRFS is linked to transactional updates. Did it say anywhere that support for your beloved ext4 filesystem will be removed, did it say that a package manager will be removed?

Yes. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

On 2022-10-10 13:50, Roger Oberholtzer wrote:

On Mon, Oct 10, 2022 at 1:44 PM Carlos E. R. wrote:

...

...

So the first build has BTRFS and BTRFS is linked to transactional updates. Did it say anywhere that support for your beloved ext4 filesystem will be removed, did it say that a package manager will be removed?

Yes.

Surely the ext4 thing is only for / and related OS related partitions? Some other data disk must surely be able to be ext4. AFAIK, the basic system that is installed "the ALP way" is an image somehow cloned to the hard disk. It is a RO filesystem done in btrfs, so "/" is btrfs, no way out of this. Updates and additions/modifications go as snapshots to this initial image.

You can surely add other partitions, but root will remain btrfs. No idea how other packages can be added, or updates. -- -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

On 2022-10-10 14:11, Robert Schweikert wrote:

On 10/10/22 07:56, Carlos E. R. wrote:

...

On 2022-10-10 13:50, Roger Oberholtzer wrote:

...

On Mon, Oct 10, 2022 at 1:44 PM Carlos E. R. <> wrote:

How much have you contributed to the direction, other than spreading fear?

Can you spread true information? So far, you are spreading uncertainty. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

Robert, et al -- First, I've read the entire thread, including your more detailed explanation of what's going on (and, in particular, what isn't yet decided). Thanks for all of your effort, 'cuz I was kinda where Carlos has been but have been too busy to even keep up. ...and then Robert Schweikert said... % ... % Yes there is uncertainty simply because we are not sure yet what comes of it % all. What is know is that the current way has many pain points and ALP is an % attempt to address a number of those pain points. I'm sure this is documented somewhere, but I'm also not connected and involved enough to chase it like I shold. Are there blogs and posts and wikis, oh my, that talk a bit about the problems being solved as well as the ideas for solving them? What are those pain points? I'm of the opinion that there are no bad ideas in brainstorming and also that you should try some things to see how they feel. I'm very bad at agile development but nonetheless a fan of the approach :-) So let's see where this goes and I look forward to watching more competent and engaged folks test prototypes. % % Later, % Robert Thanks again & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

On 10/8/22 04:46, Carlos E. R. wrote:

On 2022-10-08 13:03, Marcus Meissner wrote:

...

On Sat, Oct 08, 2022 at 12:49:39PM +0200, Carlos E. R. wrote:

...

On 2022-10-08 03:13, David C. Rankin wrote:

...

On 10/7/22 04:47, Carlos E. R. wrote:

...

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article

:-/

What other distribution is out there we can easily migrate to?

I'm just switching over to my Arch boxes, or Debian Pis. All distros have there pluses or minuses. Arch is a phenomenal, rock solid, KISS philosophy Linux distribution. pacman package manager is absolutely simple and easy to use (note: no 'k'). Much like zypper from the command line.

Debian is also a good choice. Like it. apt and dpkg from the command line are also workable, though take a bit more learning than pacman. But Debian does have non-free for codecs (like our packman). I'm not a fan of creating debian packages, but that is also doable.

How does Arch do codecs stuff?

...

There are a lot of newer distros out in the last 6-7 years I haven't even tried yet, but after being whip-sawed by my distro of choice, I'm sticking to the distros least likely to change.

Of course.

...

My hope is we can do 15.5 as a LTS or Evergreen release so I can stay with openSUSE for a couple more years.

SUSE Devs -- you listening? 15.5 LTS or Evergreen. Keep it going for a while for those of us who have contributed two decades to testing and improving your product. That will allow us all to part on good terms.

I will have to install whatever as a double boot while I learn the ropes on another distro.

Please understand that ALP is a platform, which is under design and development.

We will very likely again build a regular Leap like distribution on top of this platform.

No need for FUD.

Then you have to be clear and explain what is going to happen to us, now. I very much have fear.

If I have to containerize my computer, then I have to seek another distro.

But if it's done well, you might not even notice the containerization. Who knows, we might even like it!  In any case, there's still plenty of time to see what happens, it should be interesting.  This will be either a massive stroke of genius for SuSE, or a horrible failure. Regards, Lew

On 10/8/22 11:33, Carlos E. R. wrote:

On 2022-10-08 18:43, Lew Wolfgang wrote:

...

On 10/8/22 04:46, Carlos E. R. wrote:

...

On 2022-10-08 13:03, Marcus Meissner wrote:

...

On Sat, Oct 08, 2022 at 12:49:39PM +0200, Carlos E. R. wrote:

...

On 2022-10-08 03:13, David C. Rankin wrote:

...

On 10/7/22 04:47, Carlos E. R. wrote: > On 2022-10-07 03:10, David C. Rankin wrote:

...

...

...

...

No need for FUD.

Then you have to be clear and explain what is going to happen to us, now. I very much have fear.

If I have to containerize my computer, then I have to seek another distro.

But if it's done well, you might not even notice the containerization. Who knows, we might even like it!  In any case, there's still plenty of time to see what happens, it should be interesting.  This will be either a massive stroke of genius for SuSE, or a horrible failure.

I will for certain notice that I can no longer choose the root filesystem.

Freedom gone.

I certainly understand.  But we should still wait to see what happens and what the alternatives will be. Regards, Lew

On 2022-10-08 18:06, bent fender wrote:

Linux is about choices and freedom, think of a no-fly zone: when I see Linux being steered away from freedom I don't need to ask who's behind it.

So just who is behind it?

On 10/9/22 21:48, J Leslie Turriff wrote:

On 2022-10-08 14:05:22 Lew Wolfgang wrote:

...

|I certainly understand.  But we should still wait to see what happens and |what the alternatives will be. | |Regards, |Lew If we just wait to see what happens it will be too late when we find out.

I think we'll have plenty of advance warning if things aren't going well with ALP.  I support about 40 desktops and servers and I'm not worried as long as I have about 6-months to transition. I'm willing to wait and see what happens and to take notes about what others are thinking and doing about alternatives. Regards, Lew

On Mon, Oct 10, 2022 at 1:22 PM Robert Schweikert wrote:

On 10/8/22 07:46, Carlos E. R. wrote:

...

On 2022-10-08 13:03, Marcus Meissner wrote:

...

On Sat, Oct 08, 2022 at 12:49:39PM +0200, Carlos E. R. wrote:

...

On 2022-10-08 03:13, David C. Rankin wrote:

...

On 10/7/22 04:47, Carlos E. R. wrote:

...

On 2022-10-07 03:10, David C. Rankin wrote: > Seems our worst fears are valid: > > https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article > >

:-/

What other distribution is out there we can easily migrate to?

I'm just switching over to my Arch boxes, or Debian Pis. All distros have there pluses or minuses. Arch is a phenomenal, rock solid, KISS philosophy Linux distribution. pacman package manager is absolutely simple and easy to use (note: no 'k'). Much like zypper from the command line.

Debian is also a good choice. Like it. apt and dpkg from the command line are also workable, though take a bit more learning than pacman. But Debian does have non-free for codecs (like our packman). I'm not a fan of creating debian packages, but that is also doable.

How does Arch do codecs stuff?

...

There are a lot of newer distros out in the last 6-7 years I haven't even tried yet, but after being whip-sawed by my distro of choice, I'm sticking to the distros least likely to change.

Of course.

...

My hope is we can do 15.5 as a LTS or Evergreen release so I can stay with openSUSE for a couple more years.

SUSE Devs -- you listening? 15.5 LTS or Evergreen. Keep it going for a while for those of us who have contributed two decades to testing and improving your product. That will allow us all to part on good terms.

I will have to install whatever as a double boot while I learn the ropes on another distro.

Please understand that ALP is a platform, which is under design and development.

We will very likely again build a regular Leap like distribution on top of this platform.

No need for FUD.

Then you have to be clear and explain what is going to happen to us, now. I very much have fear.

I guess the "under design and development" part is difficult to understand. As I stated previously in another thread, there is a

The concept is perfectly clear. I would imagine that is also the best time to point out use cases that might be effected by the change. Better to discuss that earlier in the process than later. I'm not at all against improvements. I just need to monitor how they might adversely effect things. Given how we prefer to develop on Tumbleweed, but provide binary installers for Leap for use in production, a container-type packaging might be useful to us. Our current method is a KIWI generated build environment that we chroot to build for various Leap versions. It works. But a better solution would not be bad. I'm curious if SUSE's proposed development has any benefits in our use environment that improve on the chroot build method. -- Roger Oberholtzer

On 10/10/22 07:51, Carlos E. R. wrote:

On 2022-10-10 13:22, Robert Schweikert wrote:

...

On 10/8/22 07:46, Carlos E. R. wrote:

...

On 2022-10-08 13:03, Marcus Meissner wrote:

...

On Sat, Oct 08, 2022 at 12:49:39PM +0200, Carlos E. R. wrote:

...

On 2022-10-08 03:13, David C. Rankin wrote:

...

On 10/7/22 04:47, Carlos E. R. wrote: > On 2022-10-07 03:10, David C. Rankin wrote: >> Seems our worst fears are valid: >> >> https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article >> >> > > :-/ > > What other distribution is out there we can easily migrate to?

I'm just switching over to my Arch boxes, or Debian Pis. All distros have there pluses or minuses. Arch is a phenomenal, rock solid, KISS philosophy Linux distribution. pacman package manager is absolutely simple and easy to use (note: no 'k'). Much like zypper from the command line.

Debian is also a good choice. Like it. apt and dpkg from the command line are also workable, though take a bit more learning than pacman. But Debian does have non-free for codecs (like our packman). I'm not a fan of creating debian packages, but that is also doable.

How does Arch do codecs stuff?

...

There are a lot of newer distros out in the last 6-7 years I haven't even tried yet, but after being whip-sawed by my distro of choice, I'm sticking to the distros least likely to change.

Of course.

...

My hope is we can do 15.5 as a LTS or Evergreen release so I can stay with openSUSE for a couple more years.

SUSE Devs -- you listening? 15.5 LTS or Evergreen. Keep it going for a while for those of us who have contributed two decades to testing and improving your product. That will allow us all to part on good terms.

I will have to install whatever as a double boot while I learn the ropes on another distro.

Please understand that ALP is a platform, which is under design and development.

We will very likely again build a regular Leap like distribution on top of this platform.

No need for FUD.

Then you have to be clear and explain what is going to happen to us, now. I very much have fear.

I guess the "under design and development" part is difficult to understand. As I stated previously in another thread, there is a commitment for openSUSE Leap 15.5 to look the same as what we are used to. That means no changes, other than the usual package churn until mid 2024.

And after 15.5, what?

We do not know yet but we have ~18 months to figure it out. And what do we (the rest of the world) do if Putin decides to bomb Zaporizhzhia?

...

Any other distro giving you an ~18 month road map?

No, but a revolution is coming.

According to how you interpret what you read.

Any other planing a revolution?

I do not know, I do not follow what other distros do. For the bits and pieces that I am just a user off I will let those that actively contribute to the development determine the path forward. Then when there is something tangible I'll decide whether I like it or not. When the GNOME team decided to dictate how I should work with the release of GNOME 3 and I didn't like it I switched to XFCE. However, since I did not contribute to GNOME in any way, neither upstream nor in the distribution packaging I also did not go out of my way to spread fear about how and why what may or may not be coming would bring the universe to a halt. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo

On 10/10/22 08:33, Carlos E. R. wrote:

On 2022-10-10 14:21, Robert Schweikert wrote:

...

On 10/10/22 07:51, Carlos E. R. wrote:

...

On 2022-10-10 13:22, Robert Schweikert wrote:

...

On 10/8/22 07:46, Carlos E. R. wrote:

...

On 2022-10-08 13:03, Marcus Meissner wrote:

...

On Sat, Oct 08, 2022 at 12:49:39PM +0200, Carlos E. R. wrote: > On 2022-10-08 03:13, David C. Rankin wrote: >> On 10/7/22 04:47, Carlos E. R. wrote: >>> On 2022-10-07 03:10, David C. Rankin wrote: >>>> Seems our worst fears are valid: >>>> >>>> https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article >>>> >>>> >>> >>> :-/ >>> >>> What other distribution is out there we can easily migrate to? >> >> I'm just switching over to my Arch boxes, or Debian Pis. All >> distros >> have there pluses or minuses. Arch is a phenomenal, rock solid, >> KISS >> philosophy Linux distribution. pacman package manager is absolutely >> simple and easy to use (note: no 'k'). Much like zypper from the >> command >> line. >> >> Debian is also a good choice. Like it. apt and dpkg from the >> command >> line are also workable, though take a bit more learning than >> pacman. But >> Debian does have non-free for codecs (like our packman). I'm not >> a fan >> of creating debian packages, but that is also doable. > > How does Arch do codecs stuff? > >> >> There are a lot of newer distros out in the last 6-7 years I >> haven't >> even tried yet, but after being whip-sawed by my distro of >> choice, I'm >> sticking to the distros least likely to change. > > Of course. > >> >> My hope is we can do 15.5 as a LTS or Evergreen release so I can >> stay >> with openSUSE for a couple more years. >> >> SUSE Devs -- you listening? 15.5 LTS or Evergreen. Keep it going >> for a >> while for those of us who have contributed two decades to >> testing and >> improving your product. That will allow us all to part on good >> terms. > > I will have to install whatever as a double boot while I learn > the ropes on > another distro.

Please understand that ALP is a platform, which is under design and development.

We will very likely again build a regular Leap like distribution on top of this platform.

No need for FUD.

Then you have to be clear and explain what is going to happen to us, now. I very much have fear.

I guess the "under design and development" part is difficult to understand. As I stated previously in another thread, there is a commitment for openSUSE Leap 15.5 to look the same as what we are used to. That means no changes, other than the usual package churn until mid 2024.

And after 15.5, what?

We do not know yet but we have ~18 months to figure it out.

And what do we (the rest of the world) do if Putin decides to bomb Zaporizhzhia?

...

...

Any other distro giving you an ~18 month road map?

No, but a revolution is coming.

According to how you interpret what you read.

...

Any other planing a revolution?

I do not know, I do not follow what other distros do. For the bits and pieces that I am just a user off I will let those that actively contribute to the development determine the path forward. Then when there is something tangible I'll decide whether I like it or not. When the GNOME team decided to dictate how I should work with the release of GNOME 3 and I didn't like it I switched to XFCE. However, since I did not contribute to GNOME in any way, neither upstream nor in the distribution packaging I also did not go out of my way to spread fear about how and why what may or may not be coming would bring the universe to a halt.

I am not spreading fear: but SUSE is.

I am already afraid, so I'm seeking solutions and true information, and not getting it.

You are getting true information. The implication that people are lying to you is simply factually incorrect. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo

Am Montag, 10. Oktober 2022, 14:47:34 CEST schrieb Nicolas Kovacs:

Le 10/10/2022 à 13:22, Robert Schweikert a écrit :

...

Any other distro giving you an ~18 month road map?

RHEL and clones: 120 month road map.

if you want to compare with that family of linux, compare leap with fedora and SLES with RHEL, but not mixed. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on liberachat and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

Le 08/10/2022 à 13:03, Marcus Meissner a écrit :

We will very likely again build a regular Leap like distribution on top of this platform.

Some Linux distributions stick to the KISS principle. Keep It Simple Stupid. Other distributions seem to prefer the KICK principle. Keep It Complicated Kevin. As in: "Let's just tear down our proven and reliable system and rebuild it from scratch. Only this time let's add a few layers of abstraction underneath it all. Reliable is boring. Stable is boring. We want the excitement."

No need for FUD.

The "U" in FUD stands for Uncertainty. Which pretty much sums up OpenSUSE's communication about the future of Leap. Cheers, Niki (busy checking out Rocky Linux and Debian as alternatives to Leap) -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

Le 08/10/2022 à 13:03, Marcus Meissner a écrit :

No need for FUD.

new things are difficult to, accept. Remember system, btrfs, ip, kde4... I thank openSUSE/SUSE to warn us a long time before it come into production. At that time I suspect most distros will do the same jdd -- mon serveur usenet: dodin.fr.nf c'est quoi, usenet? http://www.dodin.org/wiki/pmwiki.php?n=Usenet.Usenet

Le 08/10/2022 à 21:28, Dave Howorth a écrit :

- ip - what? yes this predates linux by some years and is a most excellent invention but what's the relevance?

not IP as in address, but the command ip in place of ifconfig jdd -- mon serveur usenet: dodin.fr.nf c'est quoi, usenet? http://www.dodin.org/wiki/pmwiki.php?n=Usenet.Usenet

Please understand that ALP is a platform, which is under design and development.

We will very likely again build a regular Leap like distribution on top of this

On 2022-10-08 06:03:32 Marcus Meissner wrote: platform.

No need for FUD.

Ciao, Marcus

As long as we hear, "We will _very likely_ again..." there is certainly need for FUD. When we hear "We will _definitely_..." maybe the need will diminish. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 x86_64

On Fri, Oct 7, 2022 at 11:47 AM Carlos E. R. wrote:

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article

What other distribution is out there we can easily migrate to?

Hmmm.. I use Linux to a large amount because of it's responsiveness. Moving things to containers pretty much makes that an obsolete reason. Would this mean that we would need to package our applications in a container? Or just that SUSE itself is packaged that way, and once installed and running it's business as usual? I'm still a little unclear how this translates in the user experience. Is SUSE (not openSUSE) mainly being deployed in the cloud? That's the biggest customer? The desktop (a human in front of a display doing things) is officially dead? -- Roger Oberholtzer

On 10/10/22 10:17, Bill Walsh wrote:

On 10/10/22 02:39, Roger Oberholtzer wrote:

...

On Fri, Oct 7, 2022 at 11:47 AM Carlos E. R. wrote:

...

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article

What other distribution is out there we can easily migrate to? Hmmm.. I use Linux to a large amount because of it's responsiveness. Moving things to containers pretty much makes that an obsolete reason.

Would this mean that we would need to package our applications in a container? Or just that SUSE itself is packaged that way, and once installed and running it's business as usual? I'm still a little unclear how this translates in the user experience.

Is SUSE (not openSUSE) mainly being deployed in the cloud? That's the biggest customer? The desktop (a human in front of a display doing things) is officially dead?

Roger has asked the questions [ kind of ] that were bouncing around in my head.

Let me ask it plainly: Is SUSE going the way of Windows with everything in the cloud?

No. And currently an argument could be made that the prototype is not necessarily suitable for the cloud unless people are interested in running their own k8s control plane or want to use containers without an orchestration layer. Both valid use cases of course. But the prototype as is will not integrate with EKS and neither Google nor Azure offer integration into their managed k8s services. The read-only root, of the prototype, presents another set of interesting points that need to be addressed from an integration point of view. Or in short No, far from it. One of the ideas of ALP is that what is being built makes it easier to target different environments by creating different offers without creating a giant drag as it does today. What we do today was generally referred to as the common-code-base. This enabled SUSE to efficiently create SLES, SLES For SAP, SLE HPC and other derivatives of the SLE family. However this model also creates drag. Let me provide and example. When the azure-sdk packages need updating because new APIs become available we need to usually update on the order of 10 or 20 Python packages that are dependencies and considered part of the Python stack. Pretty easy in TW since those dependencies are generally kept up to date in the rolling release, but a big problem for a "stable" release such as SLES or Leap. As such in this case having those dependencies in a separate bucket in a project that is part of ALP would allow us to move the azure-sdk at a higher velocity without impacting other applications that are part of the system if we choose to deliver the azure-sdk and/or azure-cli in a container. But this is not decided yet either. However, this is a reasonably straight forward example as to why containers are attractive for certain things. Note that containers themselves are not dependent on a read-only setup on btrfs. What is dependent on btrfs are transactional-updates. Adding this here as there appears to be commingling of things in the thread.

I can see where going that route with stuff is great for large systems. Instead of having to update every computer in the system individually the update is done in the cloud and every computer uses the same.

This is not just a feature of cloud systems, systems at the "edge" have the same/similar needs. Think of a retailer with many locations and all are supposed to be the same. And in a store there is generally physical hardware, but no IT team.

Simple and clean. A real boon to the IT department. That's how it is at work.

BUT, then you have the other side of computer use, ME. A simple home user that can barely program my TV, and that is automated inside the TV.

Yes, and wouldn't it be nice if we have 3 or 4 desktop environments and if one needs an updated library that others also depend upon for this one DE not to be blocked because others are slower and moving forward? Or asked a different way, why should KDE users, for example, have to wait until GNOME or some other desktop environment gets fixed up to use a newer version of library XYZ? These are the kinds of problems we are trying to solve with ALP.

Things like Chromebooks made a huge splash a few years ago. Small, light weight and easy to use. Not to mention cheap. That is until, for whatever reason, it has no internet connection and OOOPS half the stuff doesn't work anymore. "I'm sitting on a mountain top in outer Whatsitstan and wanted to work on a paper I was writing while I was inspired by the scenery and the software to do that isn't available. WOW, I love my new paper weight."

The advantage ChromeOS has that it only serves one UI. As was pointed out in this thread, choice is an integral part of the Linux ecosystem, KDE, GNOME, XFCE, ..... and that makes things much more complicated.

YES, I know. I'm a typical Windows user EXCEPT I'm not. I much prefer Linux. At least up until recently Linux hasn't gone the "Nanny Route" and allows us to BORK our systems as we see fit. I am starting to see things like, "You can't do that [ like running something as Admin ] because you might do something stupid." [ and, Yes, over the years I have done some stupid things and borked my system but it's MY system. If I want to bork it that's my choice. ]

Correct, the issue is how do we solve this in a generic way while at the same time being efficient. The facts are that SUSE is not in a position to hire 1000 people to package everything and maintain it and put it together in a way such that it fits every use case. And the community is not large enough to do that either. So the questions are what and how can we build that satisfies as many use cases as possible and is flexible enough to put together in various ways without creating a giant effort to address as many use cases as possible. ALP is supposed to present that PLATFORM that makes this possible. The first prototype happens to focus on what many these days consider very important, containerized work loads. If we do it "right", at least theoretically, what Carlos is after should not be that hard to put together. But we are not there yet and we don't know. That said it is a use case that is not forgotten. Whether or not Carlos believes this is a different conversation. And as you said, everyone gets to make their own choices. But of course it also depends on the community. If something that looks exactly like Leap today is desired but SUSE has no equivalent product that generates income why is the onus on SUSE to pay people to build that artifact? Ultimately we should have a setup that allows anyone to compose a system as they see fit in a reasonably straight forward way. We'll see how close we get to that ideal.

I have no need of cloud computing. I just want a system that works, when, where and how, I want it to work.

And you are not alone. That said "just works" also depends on how it is defined and along the way tradeoffs will have to be made to get there. What we do know is that what is most convenient for building things may not turn out to provide the best user experience and these types of situations arise and get discussed and then trade offs need to be decided upon. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo

On 10/10/22 11:20, Robert Schweikert wrote:

On 10/10/22 10:17, Bill Walsh wrote:

...

On 10/10/22 02:39, Roger Oberholtzer wrote:

...

On Fri, Oct 7, 2022 at 11:47 AM Carlos E. R. wrote:

...

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

https://www.theregister.com/2022/10/05/suse_alp_v001/?utm_source=daily&utm_medium=newsletter&utm_content=article

What other distribution is out there we can easily migrate to? Hmmm.. I use Linux to a large amount because of it's responsiveness. Moving things to containers pretty much makes that an obsolete reason.

Would this mean that we would need to package our applications in a container? Or just that SUSE itself is packaged that way, and once installed and running it's business as usual? I'm still a little unclear how this translates in the user experience.

Is SUSE (not openSUSE) mainly being deployed in the cloud? That's the biggest customer? The desktop (a human in front of a display doing things) is officially dead?

Roger has asked the questions [ kind of ] that were bouncing around in my head.

Let me ask it plainly: Is SUSE going the way of Windows with everything in the cloud?

No.

And currently an argument could be made that the prototype is not necessarily suitable for the cloud unless people are interested in running their own k8s control plane or want to use containers without an orchestration layer. Both valid use cases of course. But the prototype as is will not integrate with EKS and neither Google nor Azure offer integration into their managed k8s services. The read-only root, of the prototype, presents another set of interesting points that need to be addressed from an integration point of view.

Or in short No, far from it.

One of the ideas of ALP is that what is being built makes it easier to target different environments by creating different offers without creating a giant drag as it does today.

What we do today was generally referred to as the common-code-base. This enabled SUSE to efficiently create SLES, SLES For SAP, SLE HPC and other derivatives of the SLE family. However this model also creates drag.

Let me provide and example. When the azure-sdk packages need updating because new APIs become available we need to usually update on the order of 10 or 20 Python packages that are dependencies and considered part of the Python stack. Pretty easy in TW since those dependencies are generally kept up to date in the rolling release, but a big problem for a "stable" release such as SLES or Leap.

As such in this case having those dependencies in a separate bucket in a project that is part of ALP would allow us to move the azure-sdk at a higher velocity without impacting other applications that are part of the system if we choose to deliver the azure-sdk and/or azure-cli in a container. But this is not decided yet either. However, this is a reasonably straight forward example as to why containers are attractive for certain things.

Note that containers themselves are not dependent on a read-only setup on btrfs. What is dependent on btrfs are transactional-updates. Adding this here as there appears to be commingling of things in the thread.

...

I can see where going that route with stuff is great for large systems. Instead of having to update every computer in the system individually the update is done in the cloud and every computer uses the same.

This is not just a feature of cloud systems, systems at the "edge" have the same/similar needs. Think of a retailer with many locations and all are supposed to be the same. And in a store there is generally physical hardware, but no IT team.

...

Simple and clean. A real boon to the IT department. That's how it is at work.

BUT, then you have the other side of computer use, ME. A simple home user that can barely program my TV, and that is automated inside the TV.

Yes, and wouldn't it be nice if we have 3 or 4 desktop environments and if one needs an updated library that others also depend upon for this one DE not to be blocked because others are slower and moving forward?

Or asked a different way, why should KDE users, for example, have to wait until GNOME or some other desktop environment gets fixed up to use a newer version of library XYZ?

These are the kinds of problems we are trying to solve with ALP.

...

Things like Chromebooks made a huge splash a few years ago. Small, light weight and easy to use. Not to mention cheap. That is until, for whatever reason, it has no internet connection and OOOPS half the stuff doesn't work anymore. "I'm sitting on a mountain top in outer Whatsitstan and wanted to work on a paper I was writing while I was inspired by the scenery and the software to do that isn't available. WOW, I love my new paper weight."

The advantage ChromeOS has that it only serves one UI. As was pointed out in this thread, choice is an integral part of the Linux ecosystem, KDE, GNOME, XFCE, ..... and that makes things much more complicated.

...

YES, I know. I'm a typical Windows user EXCEPT I'm not. I much prefer Linux. At least up until recently Linux hasn't gone the "Nanny Route" and allows us to BORK our systems as we see fit. I am starting to see things like, "You can't do that [ like running something as Admin ] because you might do something stupid." [ and, Yes, over the years I have done some stupid things and borked my system but it's MY system. If I want to bork it that's my choice. ]

Correct, the issue is how do we solve this in a generic way while at the same time being efficient. The facts are that SUSE is not in a position to hire 1000 people to package everything and maintain it and put it together in a way such that it fits every use case. And the community is not large enough to do that either. So the questions are what and how can we build that satisfies as many use cases as possible and is flexible enough to put together in various ways without creating a giant effort to address as many use cases as possible. ALP is supposed to present that PLATFORM that makes this possible. The first prototype happens to focus on what many these days consider very important, containerized work loads.

If we do it "right", at least theoretically, what Carlos is after should not be that hard to put together. But we are not there yet and we don't know. That said it is a use case that is not forgotten. Whether or not Carlos believes this is a different conversation.

And as you said, everyone gets to make their own choices.

But of course it also depends on the community. If something that looks exactly like Leap today is desired but SUSE has no equivalent product that generates income why is the onus on SUSE to pay people to build that artifact? Ultimately we should have a setup that allows anyone to compose a system as they see fit in a reasonably straight forward way.

We'll see how close we get to that ideal.

...

I have no need of cloud computing. I just want a system that works, when, where and how, I want it to work.

And you are not alone. That said "just works" also depends on how it is defined and along the way tradeoffs will have to be made to get there.

What we do know is that what is most convenient for building things may not turn out to provide the best user experience and these types of situations arise and get discussed and then trade offs need to be decided upon.

Later, Robert

Thank you. -- "There are four boxes to be used in the defense of liberty: soap, ballot, jury, and cartridge. Please use in that order."

On 10.10.22 18:20, Robert Schweikert wrote:

On 10/10/22 10:17, Bill Walsh wrote:

...

On 10/10/22 02:39, Roger Oberholtzer wrote:

...

On Fri, Oct 7, 2022 at 11:47 AM Carlos E. R. wrote:

...

On 2022-10-07 03:10, David C. Rankin wrote:

...

Seems our worst fears are valid:

...

Let me ask it plainly: Is SUSE going the way of Windows with everything in the cloud?

No.

Thank you, for clarifying that.

One of the ideas of ALP is that what is being built makes it easier to target different environments by creating different offers without creating a giant drag as it does today.

What we do today was generally referred to as the common-code-base. This enabled SUSE to efficiently create SLES, SLES For SAP, SLE HPC and other derivatives of the SLE family. However this model also creates drag.

Let me provide and example. When the azure-sdk packages need updating because new APIs become available we need to usually update on the order of 10 or 20 Python packages that are dependencies and considered part of the Python stack.

... Yes, the python installation is a real mess. The python community has really missed to provide a working way to use different versions separately and keep them apart. The 2.7.x vs 3.6 vs 3.9 vs 3.10 versions suck. You never know what should be the version in the OS. I have the impression it was not such a mess when it changed from v1 to v2. There is a certain software I'd like to use, but it requires python 3 as /usr/bin/python (no version behind it) .... and of course it is not the v3 that is installed and it expects a certain sub version and does not accept a higher sub version ... and it comes with an installer which believes it owns the system. No tar.gz or rpm avail, but there is a Snap ... which is incompatible. This mindlessness and arrogance upsets me.

As such in this case having those dependencies in a separate bucket ...> Yes, and wouldn't it be nice if we have 3 or 4 desktop environments and if one needs an updated library that others also depend upon for this one DE not to be blocked because others are slower and moving forward?

Or asked a different way, why should KDE users, for example, have to wait until GNOME or some other desktop environment gets fixed up to use a newer version of library XYZ?

These are the kinds of problems we are trying to solve with ALP.

As an example, I use XFCE as the desktop to get rid of the KDE/Gnome obesity, but still have to keep the KDE and Gnome libs installed, because some programs exist only for one of the other desktops. There is probably no way to get rid of that. I use kdirstat (k4dirstat) and kdiff3 on XFCE to find directories wasting space and to compare versions of files and to merge them. These tools use different versions of KDE and must see the same filesystem and must see the real filesystem instead of the section visible in a container. And there are other tools from Gnome which are used too. How will the layout of the filesystem and the containers be for this scenario?

But of course it also depends on the community. If something that looks exactly like Leap today is desired but SUSE has no equivalent product that generates income why is the onus on SUSE to pay people to build that artifact? Ultimately we should have a setup that allows anyone to compose a system as they see fit in a reasonably straight forward way.

We'll see how close we get to that ideal.

:-)

...

I have no need of cloud computing. I just want a system that works, when, where and how, I want it to work.

And you are not alone. That said "just works" also depends on how it is defined and along the way tradeoffs will have to be made to get there.

Maybe it is just a question of communication? Tell the community what kind of work scenarios you have in mind. The use cases out there are not just Cloud. Greetings, Taucher