I just tried Micro OS as a desktop for ... i admit, not long, maybe an hour, because I just found it to be *unusable* as a desktop for anyone who does not know all the differences between a transactional OS and a traditional Linux OS.
To be frank and outright: While I believe that there definitely is a place for such a thing as transactional OS updates and package installations, that place is not on a desktop. At least not unless the user is actually *told about it* at first login.
I installed µOS as "Plasma Desktop" in a VM, and was greeted after login with a plain Plasma Desktop with almost no apps, and no YaST either. And after finding discover I found that every installation process after the first failed without telling me why.
Yes, I know, transactional, yadda yaddda - but the user needs to KNOW that each install needs a REBOOT (hello, windows 98) to be able to install another application - and the easiest way to be sure that the user knows that is what?
Guess?
Yep, telling them. which µOS does not, as of 20220718.
So - begone for now. I'll have another look in a while(or maybe use it for the kind of stuff where it makes sense, like kubernetes workers or something like that).
If this comes across as a bit harsh: what can I say, that was a bit disappointing after 25 years of (almost) nothing but positive experiences with SuSE and later openSUSE products.
Cheers
MH
Just gave MicroOS a try.
As a person who tried Silverblue & Kionite before, I must say the
experience with MicroOS is, wow, much better! I am a traditional Chinese
user (and know a bit Japanese) and I have struggled to get
Chinese/Japanese input installed and utilized in these two. But CJK
input in MicroOS works like a charm. Related packages are installed
already once you selected your language during installation, all I need
to do is add the input methods that I have always been using.
Multimedia also works out of the box as I went to HTML5 video test page
with Firefox and saw no problems with playing the video.
I'm always a KDE supporter when using SUSE, coz I love how polish KDE is
under SUSE. But GNOME looks gd as well. The only thing looks weird is
it lacks YaST, I only noticed that when others pointed out. It's not
SUSEish once there's no YaST, right? ;) But I guess YaST modules
wouldn't be that useful in MicroOS as everything in the system is
read-only?
Software installation is the most confusing thing for me. I figure out
there are 3 ways to install software under MicroOS:
1. transactional-update pkg install
Pretty much like traditional zypper in but needs to reboot every time,
it makes the concept of immutable OS irrelevant if you install
everything this way
2. toolbox
More like the traditional way than 1 actually. My understanding is that
it installs software in a separate container?
3. flatpak
No explanations needed I guess?
I still have to think and choose from the above 3 ways when installing
software. For example, I am a heavy user of the Telegram messenger. I
wanted to get Telegram installed, and I have to think: Method 1? No,
it's not a system software. 2? May be, let's give a try...only I've
installed bunch of dependencies I realized that Telegram is a desktop
software so Flatpak is obviously the best answer! It's a bit confusing
tbh, if MicroOS is the new stable release in future, surely users need
time to adapt.
At this time I still haven't tried system-wide update as there are no
new snapshots for TW, not sure if the GUI way works (I found on the net
that GUI update seems waiting to be finished but the QA list does
mention about the test of GUI update?)
From my short experience I think MicroOS is an interesting concept, it's
a funny project and I am looking forward to its development, but I think
it has a long way to go to replace Leap.
Jiri Slaby <jslaby(a)suse.cz> writes:
> On 05. 07. 22, 17:46, Dan Čermák wrote:
>> we have mostly focused this week's meeting on how the ALP Desktop is
>> going to look like and how we can dispel fears around flatpaks and
>> containers when it comes to the ALP desktop.
>
> I have never looked into this container stuff in more detail. But one of
> the concerns I was always afraid of was how this behaves WRT shared
> libraries and their memory footprint? IOW, containers kill the purpose
> of shlibs completely and one has to hold all of the versions (per each
> container on the top of ones from the base system) in memory, right?
> This sounds as if using static libraries.
A small follow up on this one, more in the context of flatpaks
though. The question has been raised, whether flatpaks sharing a runtime
would benefit from memory deduplication of shared libraries in the
common runtime.
The short answer is: yes. The longer and much more elaborate answer can
be found in this great reply from upstream:
https://github.com/flatpak/flatpak/issues/4997#issuecomment-1192616912
So as long as we don't stop dynamically linking, there shouldn't be any
huge memory penalties for flatpak applications.
Cheers,
Dan
--
Dan Čermák <dcermak(a)suse.com>
Software Engineer Development tools
SUSE Software Solutions Germany GmbH
Frankenstrasse 146
90461 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hi,
I'm looking forward to everyone test driving (and staying afterwards with) MicroOS, but please make sure you know what you are in for.
MicroOS Desktop is not ready for a full release to the public. Gnome is currently RC and KDE is still Alpha.
Both should be changed soon enough to a further state, but when installed today, these are the facts.
Please refer to the official documentation for MicroOS to understand MicroOS overall [1] and MicroOS Desktop in particular [2].
Happy testing!
/Syds
[1] https://en.opensuse.org/Portal:MicroOS
[2] https://en.opensuse.org/Portal:MicroOS/Desktop
Hi,
I saw the announcement about sending MicroOS reviews here so since I tried it out a month or two ago so I guess I will share my thoughts here.
I think MicroOS could benefit a lot from a toolbox tutorial in a new user welcome pop up, because when I tried out MicroOS I had only heard of the name
"toolbox", but never knew what it could do at all. Toolbox makes doing "normal" Linux distro things such as installing devel packages or something
else temporarily pretty painless, but because I had no idea it could do that, I was just restarting my computer every time I was trying to figure out what
devel packages I needed to build a C program. Also, some other tutorials such as how to use Distrobox to simulate entire other Linux distributions
could be a neat bonus. People unfamiliar with immutable distros such as myself don't know what we need, so by the time I looked up how
those tools worked, I was already back to using plain vanilla Tumbleweed.
Gordon Leung
Hi Dirk,
Dirk Müller <dmueller(a)suse.de> writes:
> On Dienstag, 12. Juli 2022 17:40:17 CEST Dan Čermák wrote:
>
>> we have identified your workgroups [1] to have a potential high impact
>> on the community of ALP and would thus like to encourage you to start
>> publishing your workgroup reports on the factory[2] and alp[3] mailinglists
>> as well as to the openSUSE wiki[4].
>
> Hi Dan,
>
> are you looking for that being published as unstructured meeting minutes or do
> you plan to setup a more targetted process like for example
>
> https://en.opensuse.org/openSUSE:OSEP_0001
We don't have a specific template in mind and I don't think that a
formal template is really in place here, because it goes against how the
openSUSE community works.
I think it would be valuable to start posting your minutes to the wiki
after a general introduction to the community so that interested
contributors can follow your progress and provide feedback.
> where we could have a more targetted proposal discussion?
>
> I think for some of the more controversial changes it would be good to
> document rationale, chosen option and alternatives to structure potential
> feedback or discussion accordingly.
I'll think of a template that can be used for communicating change
proposals and will find a way how you can ask for feedback that will be
(hopefully) useful and will not overwhelm the workgroup.
Cheers,
Dan
--
Dan Čermák <dcermak(a)suse.com>
Software Engineer Development tools
SUSE Software Solutions Germany GmbH
Frankenstrasse 146
90461 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Dear ALP workgroup leads,
we have identified your workgroups [1] to have a potential high impact
on the community of ALP and would thus like to encourage you to start
publishing your workgroup reports on the factory[2] and alp[3] mailinglists as
well as to the openSUSE wiki[4].
It would be very nice if we could start involving community feedback in
the development of ALP, so that the whole does not feel like SUSE is
throwing stuff over the wall.
If you would like help with publishing and involving the community, then
feel free to ask us for help, as this is what we are here for ;-)
Thanks,
Dan
Footnotes:
[1] https://en.opensuse.org/openSUSE:ALP/Workgroups/Community#Workgroup_impact
[2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/
[3] https://lists.opensuse.org/archives/list/alp-community-wg@lists.opensuse.or…
[4] https://en.opensuse.org/openSUSE:ALP/Workgroups
--
Dan Čermák <dcermak(a)suse.com>
Software Engineer Development tools
SUSE Software Solutions Germany GmbH
Frankenstrasse 146
90461 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Lars Vogdt <lars(a)linux-schulserver.de> writes:
> Hi
>
> On Wed, 06 Jul 2022 12:50:18 +0200 Dan Čermák wrote:
>> >>> 1) What are the advantages of flatpak/container vs RPM?
>>
>> That's what will happen. Currently we distribute software for every
>> code stream and with flatpaks we hope to reduce the burden on our
>> maintainers and allow them to distribute it only once.
>
> For me this kind of means we retire from the current way to deliver well
> tested (but maybe older) software to Leap users and deliver the latest
> and greatest stuff to Tumbleweed users.
>
> 13) How can someone decide to use an older, but known to be stable
> version of a package (say: Libreoffice 7.2.7 instead of Libreoffice
> 7.3.4) in ALP?
We haven't made any decisions in this regard (like with a lot of other
stuff), but with flatpaks we could deliver a
org.opensuse.libreoffice-stable, org.opensuse.libreoffice-beta,
org.opensuse.libreoffice-nightly, etc. co running "streams". With
containers we could go the already established tag route, i.e.
registry.opensuse.org/opensuse/libreoffice:stableregistry.opensuse.org/opensuse/libreoffice:betaregistry.opensuse.org/opensuse/libreoffice:nightly
Cheers,
Dan
--
Dan Čermák <dcermak(a)suse.com>
Software Engineer Development tools
SUSE Software Solutions Germany GmbH
Frankenstrasse 146
90461 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Jiri Slaby <jslaby(a)suse.cz> writes:
> On 05. 07. 22, 17:46, Dan Čermák wrote:
>> we have mostly focused this week's meeting on how the ALP Desktop is
>> going to look like and how we can dispel fears around flatpaks and
>> containers when it comes to the ALP desktop.
>
> I have never looked into this container stuff in more detail. But one of
> the concerns I was always afraid of was how this behaves WRT shared
> libraries and their memory footprint? IOW, containers kill the purpose
> of shlibs completely and one has to hold all of the versions (per each
> container on the top of ones from the base system) in memory, right?
> This sounds as if using static libraries.
A lot of the containerized software is written in Go and that is already
statically linked, so my guess is that no one really looked at this so
far. However with flatpaks the situation is different and it would be
theoretically possible to deduplicate shared runtimes of
flatpaks. Unfortunately I don't know whether that is actually done in
practice or even feasible.
> And what about userspace live patching? Would we provide it for SLE for
> all the containers? Or don't you expect these continaers to be available
> on SLE (which would be against the advertised purpose, it seems)?
This would be a question for Libor, who is driving the Kernel and Live
Patching WG.
Cheers,
Dan
--
Dan Čermák <dcermak(a)suse.com>
Software Engineer Development tools
SUSE Software Solutions Germany GmbH
Frankenstrasse 146
90461 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hello openSUSE!
I'm happy to see these discussions, and this is precisely why we need
to plan in an open way! I have an understanding of many concerns which
are being raised here.
Just an idea that I discussed with Dominique a few days ago.
My first-time personal experience with our current "Immutable Desktop"
was quite good, but not perfect. I definitely would have some RFEs,
which seem to be relatively low-hanging fruits that would improve my
day-to-day experience by a lot (mostly default configuration)
I can see how the entry barrier may appear too high to people meeting
such a concept for the first time.
I'm thinking of an idea to make a "workshop" where users would install
MicroOS Desktop and try to use it for a week, and then we'd meet to
talk about the user experience, both good and bad). I think people
liked our last *workshop. We've had around 50 visitors in total.
We could start putting together known issues (FAQ), try to propose some
changes, and make sure they're being tracked for ALP GA.
Thoughts?
[0]https://en.opensuse.org/openSUSE:ALP/Workgroups/Community/Workshops/LeapD…
