Adaptable Linux Platform v0.01 shows that the future of SLE is containerized
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 -- David C. Rankin, J.D.,P.E.
On 2022-10-07 03:10, David C. Rankin wrote:
Seems our worst fears are valid:
:-/ What other distribution is out there we can easily migrate to? -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Am 07.10.22 um 11:47 schrieb Carlos E. R.:
On 2022-10-07 03:10, David C. Rankin wrote:
Seems our worst fears are valid:
:-/
What other distribution is out there we can easily migrate to?
From the link: " The argument for this move is that, as the launch material for systemd on Windows Subsystem for Linux showed, many younger 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. Peter
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 2022-10-07 12:56, Peter McD wrote:
Am 07.10.22 um 11:47 schrieb Carlos E. R.:
On 2022-10-07 03:10, David C. Rankin wrote:
Seems our worst fears are valid:
:-/
What other distribution is out there we can easily migrate to?
From the link: " The argument for this move is that, as the launch material for systemd on Windows Subsystem for Linux showed, many younger 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.
I'm a home/small business user. I don't run clouds. I don't need any of that. It also impacts my freedom: it forces me to run a particular partitioning and system. I'll no longer be able to configure my systems completely. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
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:
:-/
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 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:
:-/
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. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
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:
:-/
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
On 2022-10-07 13:46, Robert Schweikert wrote:
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:
:-/
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
Not for me. I want a stable or long life distro.
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.
The article says that a minimal image is created, read only, done in btrfs. Which means that I lose the freedom to install in ext4, for example. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
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
8. října 2022 10:54:33 SELČ, Nicolas Kovacs <info@microlinux.fr> napsal:
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
And will it exist also together with ALP? Or...? -- Vojtěch Zeisek http://trapa.cz/cs
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:
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.
Am 07.10.22 um 11:47 schrieb Carlos E. R.:
On 2022-10-07 03:10, David C. Rankin wrote:
Seems our worst fears are valid:
:-/
What other distribution is out there we can easily migrate to?
Windows. One of the great advantages of Linux is (was?) that it did what the user wants, while on Windows the user must do what the OS wants. 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. -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer https://www.daniel-bauer.com
On Fri, 7 Oct 2022 14:53:00 +0200 Daniel Bauer <linux@daniel-bauer.com> 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 2022-10-07 10:19, bent fender wrote:
On Fri, 7 Oct 2022 14:53:00 +0200 Daniel Bauer <linux@daniel-bauer.com> 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. 😉
On Fri, 7 Oct 2022 12:21:13 -0400 James Knott <james.knott@jknott.net> wrote:
On 2022-10-07 10:19, bent fender wrote:
On Fri, 7 Oct 2022 14:53:00 +0200 Daniel Bauer <linux@daniel-bauer.com> 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 Fri, 7 Oct 2022 at 18:21, James Knott <james.knott@jknott.net> 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. -- 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 08/10/2022 05:51, Liam Proven wrote:
On Fri, 7 Oct 2022 at 18:21, James Knott <james.knott@jknott.net> 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
On 2022-10-07 12:51, Liam Proven wrote:
But the_previous_ spinoff of OS/2 was called eComStation. There is a free-to-download copy on the Internet Archive:
No need for that. I have the original, in box, IBM official CD for Warp 4. BTW, in the late 90s, I worked for IBM Canada, doing 3rd level OS/2 support. I had plenty of software available there. I was on the distribution lists for OS/2, DOS, Windows and other software, along with Linux. I'd frequently find packs of 6 or so CDs in my mail slot. I really got started with Linux, at my desk in IBM, on company time. I had a few ThinkPad models and several disk drives (back then, ThinkPads had easily replaceable drives) at my desk, some of which I had Linux on. On one occasion, I and some of my co-workers went to the Corel Linux presentation. Back then, I favoured Mandrake and recall having to edit a file, to get it to work on a token ring network. A co-worker wasn't having much luck getting micro channel server to run Debian. When I left that job, I walked out with a large box of IBM software CDs.
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 Sun, 9 Oct 2022 at 03:54, James Knott <james.knott@jknott.net> wrote:
On 2022-10-07 12:51, Liam Proven wrote:
But the_previous_ spinoff of OS/2 was called eComStation. There is a free-to-download copy on the Internet Archive:
No need for that. I have the original, in box, IBM official CD for Warp 4.
I think you miss my point here. I have boxed copies of OS/2 2.0, 2.1, 3.0, 4.0 and 4.5 eServer. But eComStation is a *later* product, incorporating the kernel of eServer 4.52 and all its fixpaks, plus 3rd party drivers and additions. It comes after Warp Server 4.52 for eBusiness and all fixes, plus some more on top. It is the last finalised version of OS/2 before Arca Noae's Blue Lion. There is a beta of eCS 2.2 but no finished version was ever released.
BTW, in the late 90s, I worked for IBM Canada, doing 3rd level OS/2 support. I had plenty of software available there.
Oh I see! Good stuff. It was always very hard to get information or eval versions out of IBM, of OS/2 or Lotus products or anything else.
On one occasion, I and some of my co-workers went to the Corel Linux presentation.
One of the best of the early all-GUI distros. The first ever graphical installer, I think, and the first ever graphical X11 configuration tool.
When I left that job, I walked out with a large box of IBM software CDs.
:-) -- 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 Friday, October 7, 2022, 07:20:25 AM PDT, bent fender <ksusup@trixtar.org> 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 Fri, 7 Oct 2022 11:47:03 +0200 "Carlos E. R." <carlos.e.r@opensuse.org> wrote:
On 2022-10-07 03:10, David C. Rankin wrote:
Seems our worst fears are valid:
:-/
What other distribution is out there we can easily migrate to?
I migrated to 7 of them, well 5 after I dump Suse, maybe only 3 after I dump anything that smells like microcancer. Safety in numbers! We seem to be living in an era where every app wants to be an OS and every OS a kingdom. -- My answer to EEE: Mondays I boot and update mostly Artix, on Tuesdays Devuan, on Wednesdays Slackware, on Thursdays Leap, on Fridays Tumbleweed, on Saturdays AvLinux and on Sundays Ubuntu-Studio.
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:
:-/
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 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:
:-/
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. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
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:
:-/
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
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:
:-/
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. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
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 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. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Sat, 8 Oct 2022 at 20:32, Carlos E. R. <robin.listas@telefonica.net> 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
Le 09/10/2022 à 10:32, Liam Proven a écrit :
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.
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'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. Cheers, Niki -- 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 Sun, 9 Oct 2022 at 14:37, Nicolas Kovacs <info@microlinux.fr> 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
Le 10/10/2022 à 18:12, Liam Proven a écrit :
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?
EPEL's implementation of KDE is one of the cleanest out there. Way better than most of the "official" versions.
If you just want an RPM-based distro with KDE, why not Fedora?
Fedora's a moving target. Not my thing.
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.
These two distributions have a great future behind them. Cheers, Niki -- 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 Tue, 11 Oct 2022 at 00:17, Nicolas Kovacs <info@microlinux.fr> 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
* Liam Proven <lproven@gmail.com> [10-11-22 07:41]:
On Tue, 11 Oct 2022 at 00:17, Nicolas Kovacs <info@microlinux.fr> 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?
I believe that if you would bother to check more closely, KDE is quite prudent in it's memory usage, re: "bloated".
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
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On Tue, 11 Oct 2022 at 15:05, Patrick Shanahan <paka@opensuse.org> 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 Proven <lproven@gmail.com> [10-12-22 06:50]:
On Tue, 11 Oct 2022 at 15:05, Patrick Shanahan <paka@opensuse.org> 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.
but it is available to span a single frame across two displays and I have.
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.
that there are many options available does not really constitute bloat, but you call it what you will. convenienct and availability. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Liam, et al -- ...and then Liam Proven said... % On Sat, 8 Oct 2022 at 20:32, Carlos E. R. <robin.listas@telefonica.net> 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
Hi, 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? Of course you are free to let your imagination run free as you see fit. However the fear mongering is getting a bit out of hand. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
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 Mon, Oct 10, 2022 at 1:44 PM Carlos E. R. <robin.listas@telefonica.net> 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. -- Roger Oberholtzer
On 2022-10-10 13:50, Roger Oberholtzer wrote:
On Mon, Oct 10, 2022 at 1:44 PM Carlos E. R. <robin.listas@telefonica.net> 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 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. <robin.listas@telefonica.net> 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.
Clearly you have created a world in your head where what is ultimately build is equivalent to the _first_ _prototype_ of an artifact that is build upon what is labeled a _platform_ . Fair enough, you get to do what you want. But please stop selling what you made up as the one and only incarnation. Yes things will be different, many of us working on the _platform_ don't know for certain what it will look like as such it is rather annoying to see "prophets", like you, stamp things as "this is the way it is" when those working on it do not even know yet. How much have you contributed to the direction, other than spreading fear? 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. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
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)
On 10/10/22 08:27, Carlos E. R. wrote:
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?
Apparently there is also an issue with the understanding of the meaning of "true". The information that is being presented is "true", nobody that is participating in this thread and has presented information about he state of the affairs has lied.
So far, you are spreading uncertainty.
Incomplete information may create uncertainty, that is the way it is. But, at least from what I can tell, what all the incarnations will be of the things that will be offered from ALP is not known at this time. As such you can accuse me of having only incomplete information, but you cannot accuse me of spreading uncertainty. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
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
Hi, On 10/11/22 23:37, David T-G wrote:
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,
I do not know, but I like that you are optimistic about the documentation part :D
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?
Nothing that I am aware of, that does not mean it does not exist. I have written a few things internally to SUSE. I am not part of the product team that ultimately builds the offers that are going to be produced from ALP. Others have done similar things inside of SUSE and we are trying to coalesce the opinions, solution suggestions and inputs from a large number of people that cover how do we get stuff into the cloud (mostly what I am focused on), how do we get stuff to the edge and what is needed there, how do we get stuff into cars, into the data center.... there are a lot of work groups trying to figure out what we should be doing, what we can do and how we get from point A (where we are today) to point B (where we might want to be). Work groups cover everything from how does stuff get arranged in the build service, to networking, to package management, to update distribution, really pretty much everything is on the table. Given the breadth and the spread of what we want to cover edge to cloud and everything in between, what is ultimately offered is not going to be one thing and one thing only. I would say, tat is fairly obvious to everyone. That too many people got hung up on the first prototype from the platform being a container host is somewhat unfortunate. But so be it. There will always be those that blow things out of proportion and then get other people riled up for no reason.
What are those pain points?
One of the pain points I already mentioned, is the synchronization of dependencies for various code streams. Upstream projects that we consume have different dependencies. Given the large amount of packages we have it is difficult to contribute "the upstream project needs to switch to a newer version of Y" upstream on a continuous basis. Then there are also upstream projects that are extremely slow at reviewing and accepting contributions. Just this triggers a number of questions, is it better to start decoupling these dependencies, such that code stream A can use version M of a dependency and code stream B can use version O vs what we are trying to do today, which is forced integration. If we decouple this stuff how do we build it? How do we ship it in parallel? Should we consider bundling as an option? rust and go based code forces us to bundle, should we consider this for other languages? How do we handle security stuff in a bundled setup? For go and rust this is not necessarily going all that well, can we approve on that tracking mechanism? If yes does it translate to other languages? These are just some examples. One could probably fill a small book with questions alone.
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.
Yep. The problem is, as the group gets larger the process of weeding through things gets untenable. 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/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:
:-/
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 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. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
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 Sat, 8 Oct 2022 12:05:22 -0700 Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
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.
"Walk softly and carry a big stick" Murphy goes bunkers around people who are prepared; get several alternatives up and running, multiboot! That way if and when push comes to shove all you have to do is wipe a partition and replace what was on it with another 'distro-in-waiting'. 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. -- My answer to EEE: Mondays I boot and update mostly Artix, on Tuesdays Devuan, on Wednesdays Slackware, on Thursdays Leap, on Fridays Tumbleweed, on Saturdays AvLinux and on Sundays Ubuntu-Studio.
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. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 x86_64
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 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:
:-/
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. Any other distro giving you an ~18 month road map? Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
On Mon, Oct 10, 2022 at 1:22 PM Robert Schweikert <rjschwei@suse.com> 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 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?
Any other distro giving you an ~18 month road map?
No, but a revolution is coming. Any other planing a revolution? -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
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 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. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
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
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. :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
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
On 10/10/22 08:47, Nicolas Kovacs wrote:
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.
Well comparing an enterprise distribution to openSUSE is a bit skewed IMHO, but you are of course free to draw such comparisons. SLES has a 156 month road map [1] it started July 2018 and has a documented EOL date of July 2031. And for those that want to have longer support options are available. Of course there is a time problem with SLES 15 eventually, and then things have to end. Later, Robert [1] https://www.suse.com/lifecycle/ -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
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 à 14:40, Nicolas Kovacs a écrit :
all. Reliable is boring. Stable is boring. We want the excitement."
I want to come back to my eprom based system, fast, reliable, virus free... just a bit complex to update :-) (by the way, microos can probably be written on eprom (remember ultraviolet burning?) 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 à 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
On Sat, 8 Oct 2022 18:21:51 +0200 "jdd@dodin.org" <jdd@dodin.org> wrote:
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...
Hmm, perhaps not the best choice of examples: - 'system' I presume you mean 'systemd' - seems an inevitable complication of my life. Haven't decided whether it's overall good or bad yet - btrfs - I accepted it and now getting away from it is one of my strongest motivations for trying something different - ip - what? yes this predates linux by some years and is a most excellent invention but what's the relevance? - kde4 - I've never used kde at all and I've no idea what kde4 is I view it and gnome as sometime useful places to grab stuff from
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
On Sat, 8 Oct 2022 20:28:40 +0100 Dave Howorth <dave@howorth.org.uk> wrote:
On Sat, 8 Oct 2022 18:21:51 +0200 "jdd@dodin.org" <jdd@dodin.org> wrote:
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...
Hmm, perhaps not the best choice of examples:
- 'system' I presume you mean 'systemd' - seems an inevitable complication of my life. Haven't decided whether it's overall good or bad yet
I have, it aims at a monopoly, ergo, death list. Linux is about choices. Artix gives you many init CHOICES.
- btrfs - I accepted it and now getting away from it is one of my strongest motivations for trying something different
Never touched it, it's dd unfriendly (microcancer land)
- ip - what? yes this predates linux by some years and is a most excellent invention but what's the relevance?
- kde4 - I've never used kde at all and I've no idea what kde4 is I view it and gnome as sometime useful places to grab stuff from
seconded
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 10/8/22 05:49, Carlos E. R. wrote:
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?
AUR (Arch User Repository - a structured and administered user repository) There you will simply download the source package (which comes with its PKGBUILD -- a pacman .spec for lack of better words) and all patches, etc.. needed to build the package. Then you type: $ makepkg -s done. With the -s option (sync) it will download all required source and build the package on your system. I actually like this system better than packman. If there is another compiler flag or define I want, not already set, just tweak the PKGBUILD and your done. You are not stuck with what packman built. You can do the same with all distro packages as well. No longer svn, you use asp. All that is needed is: $ asp export pkgname Which downloads the source package, and then the same makepkg -s. -- David C. Rankin, J.D.,P.E.
On Fri, Oct 7, 2022 at 11:47 AM Carlos E. R. <carlos.e.r@opensuse.org> wrote:
On 2022-10-07 03:10, David C. Rankin wrote:
Seems our worst fears are valid:
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 02:39, Roger Oberholtzer wrote:
On Fri, Oct 7, 2022 at 11:47 AM Carlos E. R. <carlos.e.r@opensuse.org> 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? 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. 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. 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." 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. ] I have no need of cloud computing. I just want a system that works, when, where and how, I want it to work. That means if I want software to write a paper I want it on my computer not on some mass of condensed water vapor high in the atmosphere.* [ Side Bar: Do you realize that even the smallest cloud can contain many tons of water floating up there over your head. ] * YES, I know that is not what "cloud computing" really is. [ Hmm, I wonder if the static electrical charge up there could be made to .................................... ] -- "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 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. <carlos.e.r@opensuse.org> wrote:
On 2022-10-07 03:10, David C. Rankin wrote:
Seems our worst fears are valid:
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
Dne pondělí 10. října 2022 18:20:15 CEST, Robert Schweikert napsal(a):
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:
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.
Robert, this is so far probably the best description of directions where ALP is aiming, thank You. So, generally, bit better communication from SUSE's side wouldn't hurt... :-/ -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
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. <carlos.e.r@opensuse.org> wrote:
On 2022-10-07 03:10, David C. Rankin wrote:
Seems our worst fears are valid:
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."
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 -- "There are four boxes to be used in the defense of liberty: soap, ballot, jury, and cartridge. Please use in that order." =========================================
I also read the article and am also disturbed by SUSE opting to go all in re: it's bias toward the enterprise to the exclusion of its user base. This is not unexpected or surprising but it is regrettable. I, too have been in the opensuse camp for many years but have decided that my best move is to well, move. Recently in my search for a distro for my g'kid's laptop that Windows was clogging up, I ran across Netrunner. It certainly isn't fancy, it is not for everyone but as the reviewer said, "It just works". It checks off all the boxes for her and she loves it. I put the same system on my wife's HP and she loves it. I am still using Leap 15.0 until such time as I get around to swapping it out and at that time I will see what there is out there that works best for me. I am quite sure that SUSE will not be it. Like others, I want a desktop OS that doesn't have much "cloudiness", as I do not trust any entity with my work other than me. I lost over 2 years of company emails due to a glitch in a cloud-based system once with the "mea culpa" from that company about not being able to recover any of the data and that I just had to get over it. Never again. When it works, it works but if it doesn't, you're screwed with no recourse. I also want the ability to use whatever FS I want and not be locked into one of the distro's choosing. Etc. I am still looking.
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. <carlos.e.r@opensuse.org> 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
On Sun, 23 Oct 2022 16:30:31 +0200, (Taucher) dowswtz-Ht956@yahoo.de wrote:
[...] 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. [...]
QDirStat solves the KDE issue with kdirstat. From: https://software.opensuse.org/package/qdirstat "This is a Qt-only port of the old Qt3/KDE3-based KDirStat, now based on the latest Qt 5. It does not need any KDE libs or infrastructure." -- Robert Webb
David, et al -- ...and then David C. Rankin said... % 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 *sigh* Without defending the move, 'cuz I don't like it either, I must say that it also doesn't surprise me. Containers / docking / VM-ing are all the rage, and I can even see how that makes sense when you have huge machines that clearly don't need to just run one task (Oh to return to the days of friendly multi-user timesharing). So, yeah, you need a good way to slice and dice that hardware into tiny jails^Wunits, and here we are. Personally, I think it's going to take looking to a micro OS and adding lots of packages onto it or just a desktop/laptop OS. Since that puts us back in the realm of small machines that aren't overkill and which serve a pretty specific single purpose (ie Joe User's personal UI and gateway to The Rest Of The World), just maybe we can avoid the overhead of containerizing that whole mess as well. Soooooo ... Will SuSE, which is obviously enterprise-grade and staying that way, abandon the small machine? Or will MicroOS work out and we just get patterns that let us go on our merry way? % % -- % David C. Rankin, J.D.,P.E. HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
participants (27)
-
bent fender -
Bill Walsh -
Carlos E. R. -
Carlos E. R. -
Daniel Bauer -
Darryl Gregorash -
Dave Howorth -
David C. Rankin -
David T-G -
dowswtz-Ht956＠yahoo.de -
Fred -
J Leslie Turriff -
James Knott -
jdd＠dodin.org -
Lew Wolfgang -
Liam Proven -
Marcus Meissner -
Mathias Homann -
Nicolas Kovacs -
Patrick Shanahan -
Peter McD -
Robert Schweikert -
Robert Webb -
Robin Klitscher -
Roger Oberholtzer -
Vojtěch Zeisek -
Volker Apelt