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/