openSUSE MicroOS Desktop
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 40 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54417 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Distribution (mathematics)Different (Kate Ryan album)Slide ruleTemplate (C++)BitPresentation of a groupPlanningMultiplication signOpen setComputer animation
00:45
Hacker (term)Projective planeMultiplication signBitIntegrated development environmentScripting languagePresentation of a groupConstructor (object-oriented programming)Goodness of fitComputer animation
02:07
Single-precision floating-point formatQuicksortHybrid computerWindowProcess (computing)Perfect groupGame theoryService (economics)Distribution (mathematics)Device driverMereologyKernel (computing)Axiom of choiceBootingIntegrated development environmentOperating systemMultiplication signLaptopWord1 (number)Cartesian coordinate systemComputing platformComputer configurationPhysical systemAndroid (robot)Operator (mathematics)Computer animation
06:11
Link (knot theory)Run time (program lifecycle phase)Perpetual motionSource codeMultiplication signSoftware testingOperating systemBlogMobile appFile systemConfiguration spacePattern languageEndliche ModelltheorieBootingSoftware developerRootInstallation artGroup actionCartesian coordinate systemMereologyWebsiteQuicksortCore dumpDevice driverCurvaturePhysical systemLibrary (computing)Single-precision floating-point formatMedical imagingProcess (computing)CausalityRadical (chemistry)Point (geometry)BuildingDifferent (Kate Ryan album)Computer fileBitOperator (mathematics)Read-only memoryComputer animation
11:53
Cartesian coordinate systemHacker (term)Sinc functionMultiplication signMeta elementGraphical user interfaceRight angleEndliche ModelltheorieLevel (video gaming)outputSelectivity (electronic)Mobile appPoint (geometry)CurvatureQuicksortMereologyAndroid (robot)Integrated development environmentData storage deviceService (economics)SubsetPerspective (visual)Default (computer science)CASE <Informatik>BuildingFunctional (mathematics)Core dumpTablet computerBootingPerfect groupComputer animation
17:17
Structural loadRun time (program lifecycle phase)Front and back endsRoundness (object)Operating systemMultiplication signCartesian coordinate systemUsabilityPoint (geometry)View (database)Information securityCore dumpRevision controlQuicksortMereologyMathematical analysisPhysical systemEndliche ModelltheorieOffice suiteMappingBuildingAreaBootingMobile appMedical imagingMiniDiscComputer configurationMobile WebLibrary (computing)Fitness functionAndroid (robot)CurvatureNeuroinformatikBitMoving averageProcess (computing)Lipschitz-StetigkeitDifferent (Kate Ryan album)RoutingDebuggerOperator (mathematics)RandomizationComputer animation
22:43
Web portalQuicksortGateway (telecommunications)Computer fileDisk read-and-write headAreaCartesian coordinate systemPoint (geometry)Service (economics)Java appletComputer programmingSpacetimeEndliche ModelltheorieHecke operatorSoftware developerINTEGRALRadical (chemistry)Mobile appRun time (program lifecycle phase)Computing platformMiniDiscVideoconferencingDistribution (mathematics)Mixed realityTerm (mathematics)Open setSoftware testingBinary codeLevel (video gaming)Projective planeEmailMultiplication signElectronic mailing listDirectory serviceRoutingEscape characterView (database)1 (number)Drop (liquid)Overhead (computing)BitWikiWeb browserProduct (business)Bus (computing)CurvatureRight angleSinc functionComa BerenicesComputer animation
28:09
Lattice (order)BitOnline helpControl flowPhysical systemSoftware developerWeb applicationGoodness of fitExpected valueLink (knot theory)TheoryInformation securityStability theorySoftware bugComputing platformNetwork topologyCore dumpCurvatureData storage deviceSoftware repositoryPoint (geometry)MetadataView (database)SoftwareDistribution (mathematics)Mobile appEmailGraphical user interfaceRun time (program lifecycle phase)Cartesian coordinate systemSet (mathematics)Virtual machineCASE <Informatik>Address spaceCuboidDesign by contractMathematicsOffice suiteInterface (computing)SineMereologyBuildingMultiplication signFamilyLevel (video gaming)Open setRandomizationProjective planeHeegaard splittingCausalityElectronic mailing listComputer virusoutputWeb 2.0Internet service providerBus (computing)Computer animation
35:04
Lattice (order)Computer configurationMobile appMultiplication signEndliche ModelltheorieCausalityProjective planeVideo gameSoftware bugRadical (chemistry)Cartesian coordinate systemService (economics)Arithmetic meanOpen setSoftware developerBootingComputer fileDistribution (mathematics)CASE <Informatik>MereologyInternet forumRootDifferent (Kate Ryan album)Point (geometry)Computing platformFeedbackFile systemPhysical systemIntegrated development environmentDigitizingRevision controlPoint cloudAdditionFreewareRun time (program lifecycle phase)Database transactionLatent heatWindowFactory (trading post)Stability theoryEmailSolid geometryElectronic mailing listGraphical user interfaceEntire functionFiber bundleCurvatureOnlinecommunityRead-only memoryInternational Date LineComputer animation
41:36
Lattice (order)VideoconferencingComputer animation
Transcript: English(auto-generated)
00:06
Okay. Me again. Different slide template this time. And actually a bit of a different presentation. Even though I'm talking about microOS, this isn't Richard, the future technology team
00:20
member where we work on microOS at SUSE. This isn't Richard, the open SUSE chairman talking about this. This is Richard, the crazy contributor who still just sometimes does weird stuff. In fact, it's not official. This isn't like some future open SUSE plan unless we turn this into some future open SUSE plan. In fact, when I originally put this
00:48
proposal in, the idea I had was I'm going to work on this crazy thing and hack week will have happened at SUSE, where SUSE give all of R&D a week to play on whatever they
01:01
want. My assumption was hack week would have happened by now, and I could talk about my hack week project at OSC. Hack week is in three weeks' time, so I haven't done anything. But the session is still here. So I decided to kind of turn this into a bit more of a roundtable, a discussion session, so, anything I say as I ramble on for the next
01:26
half hour or so, feel free to interrupt. Martin has a microphone. There's a microphone at the back. You know, there's no script. This is just like this idea is a construction site. You know, this presentation is a construction site. Let's, yeah, see where we end up
01:43
afterwards. Yeah, were all of you in my talk an hour ago? Most of you? Okay, good. I need that because I don't have to kind of repeat half of that then. The basic thing I've
02:03
been asking myself lately is what the hell to do about the Linux desktop. You know, I want to believe that this is possible some day. You know, because this is one of the reasons why I got into Linux, to use a Linux desktop, to have that be the thing that I'm doing my work on, that I'm playing around on, that I do my gaming on. But
02:27
the, you know, it hasn't happened yet, and even when it does happen, you know, there are, being frank, you know, desktop Linuxes out there that are more popular than Google and SUSE. There shouldn't be, but they are. So I've been kind of thinking
02:43
of what are the problems that are really holding the desktop Linux world back? And this is kind of the obvious easy ones to blame, you know, the fact that there are multiple distributions, you know, is part of the issue, you know, but there's lots of choices out there. That means some people are going to pick Ubuntu, some are
03:02
going to pick Fedora, some are going to pick us, and that makes it kind of hard to kind of coalesce behind this sort of single desktop idea. But then that idea doesn't really fly anymore either, because we're not in this single Microsoft Windows world anymore. You know, people are gaming on Macs, they're
03:20
gaming on Android, they're playing around and doing stuff on Windows. Hey, they're running Linux on Windows these days. It's, you know, the kind of diversity of options aren't what is, I can't believe that is what's holding desktop Linux back. So, you know, what is? And the thing that kind of
03:45
really hits me is the lack, well, the fact that I think we as communities typically target ourselves and use stuff that we want to use, and use it
04:05
the way we want to use it. So, you know, we end up geeking around in tumbleweed because we like playing with operating systems, and we do all this deep and dirty stuff in the operating system, so we don't want a polished sanitized environment, let's say, for example, like OSX, where you
04:23
can't do any of that fun stuff, but then it's really easy to get that one application, dump it on OSX, and run. You know, it's almost like we're living in totally different worlds. And those worlds are, you know, diverging in some respects. You know, we're still doing all this weird, geeky, fast-moving stuff,
04:41
and, you know, you're seeing these platforms like Windows and like OSX getting, in some respects, more and more locked down and limited, you know, or in other words, you know, they're doing it wrong. And I think there's lessons to be learnt from that. Maybe it's because I'm getting older as well, but I don't
05:06
want to be spending all of my time messing around with my laptop to make it work the way I want it to. It's nice that I can, it's nice that I can get under there, and I can play around with the drivers and the kernel and stuff, but I just want to have a desktop which boots up and gives me a
05:22
desktop environment, and then I can, you know, dump the applications on top. So, yeah, I've been kind of thinking of what's the the perfect sort of hybrid of that approach. And in my day job lately, I've been working more and more
05:44
micro-s. So, yeah, like I talked about earlier, you know, micro-s now being best described as a single service operating system. So, you know, you know, micro-s is just a desktop. And what if that desktop was a traditional
06:04
OpenSUSE desktop? So something like, for example, GNOME. So I actually messed around with this two hack weeks ago, so 2017, where we weren't talking about micro-s as much, I called it cubic desktop, but played with the idea there, and basically what I took there was the cubic installer we had at
06:23
the time, ripped out the container part, because I wasn't going to do this with containers, and installed GNOME using transactional updates. So you install the system, you install transaction, you install GNOME with, yeah, I think it was PKG in GNOME patterns, reboot, and I had a fully working GNOME desktop, even
06:48
though it was a read-only root file system. So I couldn't mess around in anything in USR, I couldn't mess around with much in VAR, because that was broken at the time, but the basic operating system worked
07:01
perfectly fine, and it reminded me a lot of what you see on like a Chromebook now, where you didn't have to bother about messing around with the packages of the file system, messing around with too much of the configuration, it's just there, it just works, and then I messed around with
07:21
the at the time, flat pack, like flat hub had just launched, so I was using flat pack to install my various different applications on top, and the the idea was really cool. Basically the operating system part worked fine, it booted perfectly fine, it patched perfectly fine, I went to about three or four weeks of tumbleweed snapshots, and at no point did
07:44
anything ever go wrong, it always booted perfectly fine, it always got to desktop but fine, and besides the core GNOME applications, so things like the control panel and the terminal, there was not a single
08:01
application on the system, because I was using the basic GNOME pattern for tumbleweed, so I had to install apps from flat back, and about 35% of them worked, and the rest of them didn't, because at the time, you know, flat pack was was rather broken, but the the general idea of flat pack is a
08:25
relatively good one. Not the the best in the world, but basically taking this idea of a container, or a container like a raiment of its own, you know, a sandboxed application, having that sandbox application run, but unlike app
08:44
image or sort of other arrangements, you don't necessarily have the application and all of its dependencies bundled together in one single big blob, because then you'd end up with like all these applications being like three or four gig in size, because it's like basically have a mini operating system for every single app. With GNOME, with
09:03
flat pack, you basically have these runtimes, which are, yeah, sandboxed containers full of the libraries that you're going to need for these various ecosystems that we have already in the Linux world. So like with KDE, there's a KDE runtime, there's a GNOME runtime, there's an
09:21
Nvidia driver runtime, so you know, basically remodeling what we currently do in our PMs into these sort of more lobby groups, but these groups are the groups that people care about when it comes to desktop applications, you know, flat pack is very desktop application orientated, which is one of the
09:40
reasons why I'm still liking it more than let's say Snap with Ubuntu, where they've basically just reinvented packaging and created all of the problems we have with RPM and solved none of the problems we have with RPM and made some more issues, because it's Ubuntu, whereas your flat pack really from a desktop side does solve, or does at least model the problem
10:02
the way a desktop user thinks of the problem, or way a desktop developer thinks of the problem. So basically you're developing an app on Linux now If you're using a gnome stack, I can totally see flat pack being the first thing they're going to expect, because the runtimes are there, it's being handled by upstream gnome, build it, test it, ship it, all in GitLab because
10:24
they've already pipelined all of that, and we're still doing our RPMs, but should we? Does it really make sense for OpenSUSE to take upstream gnomes source and build it again, test it again, ship it again, just so we can say we've
10:43
given you the desktop app? Our desktop app's really our core competency, we're really good at doing operating systems, but the desktop app, we typically just ship it, test it, check it in OpenQA and do it. The open question I have for this is basically can we
11:00
make a whole bunch of problems we have with OpenSUSE just disappear by offloading it to what's already happening upstream with flat pack and gnome, for example, and then if it doesn't work out as well as it should actually contributing. So after this all went horribly wrong and I wrote this blog post and I said how horribly bad flat pack was, I did feel a
11:23
little bit guilty, so I went to GUADEC and I started talking with them basically, kind of, we worked through most of the issues that were the root cause of these like massive breakages. Haven't solved all of them, but the team there really have changed their build processes, they're testing things an awful lot more, I don't think they're using OpenQA despite my
11:43
best efforts, but they're at least, yeah, the quality of flat pack has been improving. So yeah, I'm starting to get more comfortable with the idea of using flat pack as the main way of delivering applications for my desktop. I
12:04
don't know if it's gonna be perfect, this is why this is a hack week idea, I'm gonna, you know, I want to try this and see how far it goes, see where it goes wrong, and with that I kind of realized that I don't really know what I'm doing with a lot of this stuff. It's been a really long time since I've
12:23
actually contributed directly to Gnome, because I used to be in the Gnome team, I still am in the Gnome team technique at OpenSUSE, I used to package it all there, but you know, it's moved on since 3.2, which is the last time I packaged it, you know, heavily, and so with this idea I
12:41
want to kind of see where the world currently is, and if anybody is really interested in this idea, what needs to be fixed where, you know, is this something where we need to fix OpenSUSE to be more accommodating for flat pack, is this something where flat pack just really do not know what they are doing and they need to learn how to build stuff properly, at
13:04
least from an OpenSUSE perspective, in which case, you know, can we, you know, do we need to look at OBS, for example, building flat packs better or, you know, being part of that ecosystem there or making things more complicated by, you know, doing things alongside it or the like, and nobody's interrupted me
13:23
yet. Does anybody have any questions at this point? Will? Looking confused? No? Okay, go on. No, my question would be, how would you solve the kind of,
13:58
the meta-packaging, you organize things into the right levels of
14:04
granularity and how do you choose things to actually want, people actually want to have together, is it your selection, is it, you provide a lot of fine-grained selections, then how do you find things, you know, it's the same problem you have with a bunch of RPMs, but it's one level up. Yeah, well,
14:21
I mean, it may be my naive approach, but I mean, when thinking like a modern basic user, like with, you know, a phone or a tablet or a Chromebook, you know, what do you get when you boot that thing up for the first time? You know, you basically get the desktop or, you know, the UI and a
14:45
handful of basic applications and the thing's pretty useless. Besides those basic applications, that kind of core functionality, you know, you're on your own after that point and then you're going to the app store or whatever and downloading everything individually that you want.
15:01
So the meta, the idea I'd explore with this is, would it make sense for the MicroOS desktop, for example, to have nothing but MicroOS, Gnome, maybe a subset of the Gnome applications to kind of give you that
15:20
basic environment, so those would still be RPMs and those would still be the traditional, you know, the traditional open-souza stuff and then from that point we just say you're on your own and, you know, using their flat pack snaps or whatever, putting everything on top of that. Yeah, kind of go the sort of long tail approach. That's where I, yeah, which, yeah, what does
15:46
anybody else think of that? There we go. Yeah, so I'm trying to compare this with the Mac OS world or the iOS world or
16:03
Android, Chrome, whatever. In general, I think the basic model, take the OS, make the OS basically one big blob that is updated atomically, works really well and Tumbleweed gives me a very similar experience to what I see on an iOS where, you know, I can trust the update and sometimes if it breaks, okay,
16:23
next day there's a new one and it will fix that one breakage, that's all fine and then everything else is an App Store and you can get things from there. I don't think you necessarily have to make that core OS so small if you, let's say the Gnome, why not ship all the default apps as part of that, like
16:42
Apple does it, you know, you get a shitload of applications as part of the OS update because, I mean, we are doing it well, I mean, those packages work in Tumbleweed, but yeah, everything that, you know, where you want to grow a community, want to have other people contribute, I think such an App Store
17:00
approach or, you know, a centralised build service where you can just put this stuff up and maybe it's untrusted but, you know, they'll take care of distributing it, makes perfect sense. The thought I have with that, well, it kind of, one of the reasons I want to, well, there's two reasons why I
17:21
want to make it as small as possible. One is like the thing I was talking about with Micro S earlier, is the, with Micro S being transactionally updated, you know, you, you know, any update on that OS layer, you know, is going to be the reboot, which is a bit inconvenient, plus that's
17:40
your scope of risk, you know, that's the part where if that goes wrong, your system's not booting, things are broken, etc, so with Micro S we have lots of nice features for like automatically rolling back if stuff goes wrong, so like with this I would see a model where you, you know, have it set up to automatically check is GNOME booting, you know, has XDM started
18:02
properly, blah blah blah. If it doesn't, it would be better than Tumblewood currently is, because it would auto roll back and you would be on the previous snapshot, but that means if we put way too much stuff in there like LibreOffice, for example, even though our LibreOffice package is really, really good, you know, you're increasing that risk of introducing something that's going to break in that OS update, so there's, you know, I want
18:23
to minimize that risk of breakage, at the same time, the question I kind of mentioned earlier of, you know, are we creating, is OpenSUSE creating more work for itself than it, you know, it needs, do we really need to package LibreOffice, and I know that's a controversial question, and I don't,
18:42
I'm not saying the answer is no, but I want to kind of use this as an excuse to kind of see if there is a yes to that question, you know, maybe we don't need to package LibreOffice and all these desktop apps, maybe it's better to leave it in sort of the flat pack world, and we just focus
19:01
on the OS plumbing parts that, yeah, where people can't, we can't trust what random upstream stuff they're giving us, maybe. Yes, sorry. Yeah, no problem. Um, what I really like about this idea is if you do a cost benefit
19:21
analysis of the amount of time that goes into integrating desktop packages correctly, uh, and the amount of little glitches and stuff you have to fix every time upstream comes with a new version, that's an incredible amount of time that's not being spent on hardening the core operating system, we're making that more reliable, and from a security
19:41
point of view, I am incredibly in favor of sandboxing any user facing application anyway, um, SUSE has done brilliantly with AppArmor in the past, it's been one of the more usable hardening tools so far, uh, from my point of view, if you just focus on stabling the core
20:02
operating system instead of, well, in my opinion, um, misaligning time, uh, seeing glitches in the front end that will exist regardless of you patching it this round, uh, I'd be much happier, uh, especially also if you enable users to install their own apps, like from
20:23
flat pack, um, I think most here in your audience will recognize the pain in the let's say backside that is, um, handling your mother-in-law's computer, um, if you could give her at least a bit of freedom herself that saves you all those Sunday afternoon
20:41
trips backwards and forwards, uh, which is also quite nice, although I even like my mother-in-law, but still, uh, so yes, from my point of view, uh, please carry on this route. This is basically whatever made Android, uh, the go-to platform, uh, on mobile, uh, and even though they're doing a bit more job at it, so please do it right.
21:02
And, um, yeah, kudos for trying this. Um, maybe betray betraying my in my ignorance about flat back here, but won't this end up with a lot of duplication of all
21:22
your, um, lib gnome, whatever that is then in distributed multiple times in each packs, both on disk and in Ram, or is there now some kind of de duplication? So the one reason I like flat pack more than some of the other options. So for example, there are other options for the, the
21:41
application provider, like for example, app image, which you can actually build in OBS, which is, you know, some, well can be sandboxed or snap, um, is flat pack has this model of the application and its runtimes. And the idea being is there's a one to many mapping between that. So if you're building a gnome application, it's going to
22:02
require the gnome runtime and that gnome runtime should be the only place where there is, for example, lip gnome. Um, so, you know, a runtime might require a couple of different, an application might require a couple of different runtimes. I think that they also have runtimes requiring runtimes now just to make things fun. Um, so it, there should be less of that duplication than
22:24
you could potentially have with a containerized approach. It's still less efficient than what we're used to in the RPM world, because you're going to have, for example, um, as happens with like every major gnome release, you know, there's, there's gnome 320, there's gnome 330, 332.
22:42
You can, um, if you're using the flat pack apps, you'll be likely to have a mix of gnome 330 based apps and gnome 332 based apps. So you have both runtimes and that's, you know, compared to a typical gnome OpenSUSE installation in Tumbleweed right now, that's like twice as much disk space. I mean, it's not lightweight, but disk space isn't that bad.
23:05
You know, isn't that, you know, isn't that expensive these days and maybe that's a better model at least. I mean, heck it's what our phones are all doing already. And a second question, do you have an idea how to handle, um, integration where say, for example, an
23:23
application depends on some services provided by gnome, like, I don't know, folks or other things that are on the bus that it expects the platform to provide. Flat pack has a, uh, an API for that. Let's name my conveniently just shot straight out of my head. Portals. That was it. Yeah. Portals.
23:40
So there's effectively portals plugged into gnome, which provide sort of the API gateway for that kind of thing. So there's like the, the one that was the first, that was the, the file browser portal, because otherwise you'd have all of these sandbox applications and you click on the, you know, like file open and it will load up the file view of the contained application, which of course doesn't have any
24:02
files in it and you can't see your home directory and that's kind of useless. So the file portal kind of gives you that, that route of looking through them and being able to kind of escape the container of the contained area for that purpose. Um, it's, when I looked at it two years ago, it was really limiting, it was really lousy, but in those times since then, you
24:24
know, more and more upstream developers are patching their stuff already to the, so the upstream binaries include support for those portals. And they're already doing this stuff. So they're already shipping the flat packs. And that includes things like, um, like D bus services that are, okay, cool.
24:42
That's, Hey, imagine staging project without LibreOffice and Firefox. How much faster they would build. It would be beneficial to open QA developers, well, to testers to have that, that stuff, that, that, that's actually a point I hadn't thought of.
25:05
Yeah. I mean, if, if, if this idea really has legs and we really find that this is a good way of doing an open SUSE desktop, so it's, so we get to the point where dropping Firefox out of tumbleweed or dropping LibreOffice out of tumbleweed is a sensible idea.
25:22
Yeah. The amount of speed we will get in tumbleweed in, in terms of, yeah, development staging is astronomical. Um, yeah, that, yeah, that could be fun.
25:51
I'm not so big use of open SUSE, but I mean, I have kind of radical idea. I mean, as a Java programmer, I'm always working with the Java programs
26:03
and the end user, users area area where user applications running. I mean, maybe at some point it makes sense to collaborate with other distros in producing Java based graphical user applications where it's make a
26:21
sense and otherwise maybe it makes sense, as you say, to drop some packages where your production will be increased. I mean, in building, so you don't want to have the overhead, but still, I mean, how many packages currently you packaging, maybe more than thousands?
26:45
Yeah. So, you know, for the SUSE right now, I think we're about 12,000 or maybe a bit higher packet packages in staging though, do we have a little winky here? No. How many packages, does anyone know how many packages we're in staging?
27:02
I've forgotten so many, it's a couple of hundred, but it's a couple of hundred of like really big nasty ones. Like LibreOffice takes longer to build than like most of the rest of the distribution put together. So, you know, it, yeah, that's where kind of killing some, like killing, dropping some of those other packages might help.
27:21
So I think this probably would make a sense, but, and I don't know when the, some com middle-sized companies kind of depending that you include some packages, maybe it's better just to ask around of your, like from community,
27:40
make a poll to make sure that you don't drop package, which kind of have critical dependency on the other side. So that's my point. That's why I'm repeating all this stuff. People can watch the video. I am expecting the flame was to start on the mailing list. It's all good. You know, it's yeah, let's, let's have that discussion. Let's see where we go with this.
28:01
Like nothing's yeah. I mean, you know, none of, none of this is set in stone. I totally admit I have no idea what I'm doing. Um, so yeah, that's fine. So first of all, a bit of a radical idea on the business side, I think we may want to just ask ourselves is building those packages really what
28:21
customers would want to see from us, but, or would the customer just be fine if he said, okay, it's built upstream, but we'll still help you if it breaks and we'll help you through the upstream build systems and the upstream distribution. Uh, so, you know, in the end we provide the same service, be a happy camper with your liberal office or whatever the contract is.
28:43
Uh, the, the other thing, um, we've mentioned it, um, like when the D bus interfaces and so on, the critical, um, thing to get right really is what is the contract between the OS and the application stack? Um, because that's, I mean, if you look at the phone systems, for example,
29:01
there's a huge API that those applications can use, so they don't have to take care of any of the sensors, the, uh, some of the magic going on, like the AI for, you know, voice detection and so on. That's all basically a huge set of APIs that the OS provides. Um, and that makes the applications relatively small. I mean, they're still huge because they bundle in a lot of stuff.
29:23
So that's really, if, if, if the gnome ecosystem or whatever gets that right, uh, there's a fair chance that, uh, a Linux desktop could be a nice platform, just like iOS or, or whatever. And it could be in many cases, just, you know, HTML five web apps with some,
29:40
you know, local storage and all you need is basically a Chrome runtime. So rough show of hands, how many of you here would be interested in trying to use this if it existed? Cool. And how many of you are willing to help make it happen?
30:01
Cool. Okay. That's fine. Cool. Okay then. Um, does anybody have any more questions? Thoughts? If not, cause I'll, I'll guess I'll have to start a mailing list for, for at least you kept your hands up. Oh, there's one. Sorry. Hello. Okay. Um,
30:21
what I'd like to say is from a user point of view, um, what about stability and security of these, uh, flat pack packages? That'll be something which we will have to look at. So the, the, the assumption that I'm going into with this is this is being
30:43
handled by upstreams mostly the flat, the way the flat hub ecosystem has kind of evolved. They're encouraging upstream developers to contribute directly to flat up. So it's not like the relationship we have right now where we, you know, we package, you know, it doesn't matter. It should be upstreams doing most of that in there right away.
31:01
So in theory it should be more responsive to security updates. Should be, you know, at a relatively good standard and ready to take good quality. Um, you also, if something isn't good enough, you get to moan directly to the developer. So, you know, that might be a good thing. I'm not saying it's going to be better than the coven, you know, that,
31:20
that's, that's something this we'll have to find out. And, and that's actually something I worry about too, will be users expectations with that. You know, right now you download open SUSE, you know who to blame when it doesn't work. It's open SUSE as far as long as you're not putting stuff from a random OBS project. But you know, if you're putting stuff from, I mean, Pat would be both, it's our fault with this split.
31:43
How do we make sure users know who to turn to when it doesn't work? How do we stop our bug silly getting full of stuff about someone else's application? There is no, there's also another point and it's, uh, I see right now I see, uh,
32:00
inexperienced users as a target because you just have an OS. You just need to install one or two applications and experienced users. Also we have their 10th or 20th device and don't want to set it up again. And this is something, but I, but I do not see yet,
32:24
the way open SUSE is set up right now, disappearing with RPMs and, and, uh, having the ability to install any package you want or uninstall it again, like it's right now. I'm not suggesting we change the world overnight, you know?
32:44
Yeah. So, you know, I, I can see the, I can see the possible future where we start dropping packages cause they don't make sense anymore. I can also see perhaps more soon than that, a possible future where we, we could end up segmenting that kind of stuff away. Like, you know,
33:01
let's imagine four or five years from now, you know, we've all come together and produce this thing and it, you know, it becomes more popular as a desktop than tumbleweed or leap as a desktop. So there would still be tumbleweed and leap and maybe there would still be tumbleweed and leap as a desktop, but the micro desktop is, you know, the big one of the family. When we reached that point,
33:21
I could see as potentially doing some fancy stuff like moving those legacy desktop packages, building them differently, not having them as part of staging, you know, cause they wouldn't be a core part of the distro anymore. So, you know, therefore they wouldn't be slowing staging down. Therefore we'd start getting some of those build time benefits and stuff.
33:42
So yeah, see where the road goes. But yeah, I'm not expecting this to change everything. Yeah. Okay. No way. I like, I like even tumbleweed too much. I, you know,
34:01
how would you address bugs for flat plex? Sorry. How would you address bugs for flat plex for basically for the, for desktop? How would you address bugs? Yeah. Because it's not a open SUSE. Yeah. Now, like I, like I said,
34:21
that's kind of an open question. I don't have a great answer to, this is one of the things I would look at while we're doing this. Like, you know, it's, um, I mean, if I remember correctly, I'm a little bit rusty with gnome software cause I uninstalled it from this machine. Yeah. Um, but if I remember right, when you have gnome software configured with flap hub, um,
34:44
it does have a bug reporting link in there cause gnome software is basically looking like an app store. You know, it even has kind of the whole search and stuff. Um, and when you're pulling it from our repos, you're getting all the RPM metadata and it's showing the bug reporting link being our bugzilla. And when you're getting it from flat hub,
35:01
I think the bug reporting link shoves it to some, I probably, probably the get up project for something somewhere. But so, you know, maybe it's just as simple as teaching users. That's where you go to file bugs about applications. Um, maybe it's more complicated than that. Uh, yeah, I don't know. But yeah, or maybe we end up doing that as a service in the sense of open SUSE
35:24
bugzilla models and that stuff. And we just have our bugzilla sending stuff to everybody else cause we know where they are. So maybe, maybe that's something the community, the project still does because we want to make our life easier for our users. Yeah. So the letter was really what I was thinking about, you know,
35:42
basically giving the customer the same guarantee or in the community user, but not necessarily having to do it in everything at SUSE with our own built resources. Uh, the, the other thing I think we should kind of think about is why can't we turn the layers around and say, okay,
36:01
there is a very stable lockdown runtime, but just like now, even on a windows 10 desktop, you can have a full Linux subsystem. There's still an RPM subsystem that you can use if you want to. And then that's a cool thing. You could have a leap 15 one subsystem or you could have a stable subsystem
36:24
on, I don't know, less 12 that you have to pay for. Yeah. But it's, it's not necessarily bringing all those RPMs back to your platform. The platform is rock solid lockdown and yeah, transaction update and all those things. That's an interesting idea.
36:41
Most of the runtimes are kind of orientated to a specific desktop stack, like the QT one and the no one. They do have some runtimes for, which do get some use for like more ornate applications, which are kind of stupid, like the free desktop runtime, which is basically like an entire distribution bundled as a runtime. Um,
37:03
if, if we, if we go down this road, which I think from the look of things, some of us are, um, and we really start getting kind of looped into this whole clap back stuff. I can see our way of thinking, meaning instead of, well, instead of an addition to like stuff like the free desktop one time, yeah.
37:20
A leap one time and a tumbleweed one time might make perfect sense to kind of slip in there for those non gnome, non Katie, like uniquey weird stuff. So yeah, I can, I could see that kind of thing falling out from, from this. Yeah.
37:41
Any more questions? Yeah. Panos. I don't see that I will be a user of that. There are many points even pointed here, even from heart is supported the way or even, I don't see any point, uh, having this. I mean,
38:03
if I want to use a container version of something, I don't need to open Suzanne supported way of doing this. What I'm thinking as a use case is speaking of myself, there were some times that I would like to have my development environment easy
38:21
and I'm thinking if you could have, for example, a micro S, however you can call it, something that I can have in a VM somewhere in a cloud that is small enough so I don't pay much, but I can have, for example, my VSCode running there as a desktop because you're talking about my Chris desktop so I can have a remote desktop containerized in that case,
38:45
which is small. So again, I don't pay much to digital lotion or something like that, but in the same way it gives me a very specific thing. So do one thing and do it well. In my case, let me develop Golang apps.
39:01
So something lightweight, something like that. So like a micro S desktop with like podman. Some use cases like collect feedback from the com, from the community in that case. So yeah, something that I can run on my raspberry.
39:21
I don't want to have petabytes of different like gnome applications. I don't see any point in the anchor part from just doing it once and then just going to the forums and saying, Hey, look, I run the latest and greatest of stuff that,
39:43
okay, that's it. So I don't see the containerizing a desktop is a use case. We're not talking about containerized in the desktop though. The desktop wouldn't be containerized. You know it's going to be a traditional installation on bare metal or in a VM
40:01
running normally it'll be micro S a read only root file system and locked down, but that's not containerized. The only containerized part potentially would be the user facing applications. So in your case where you want to just a development environment, well,
40:22
those don't install any apps, then you're not going to have any junk there. You know, you're going to get basically nothing more than, you know, a fast booting system cause micro S boots quickly going straight into gnome and giving you a terminal and then you can do all your stuff in your terminal. So if you are containerizing on the apps,
40:41
meaning that they can run everywhere, then why you need the open SUSE desktop to run them. Because if we do it this way, it's the best option out there cause we, all of our users can be really lazy. You know, they just deploy Mike, the micro S desktop. They never have to worry about patching it. They never have to worry about maintaining it. They just pick their apps and it keeps on rebooting all the damn time cause
41:02
that's, you know, basically the Linux desktop for people who don't want to have to mess around with the desktop anymore. That's the problem. It's a desk for non desktop users. So cool. Uh, two minutes left and last question.
41:23
Anybody? Nope. Cool. Thank you. I'll post on factory where the mailing list is going to be for this crazy idea then. Thanks.