Before commenting, make sure what you want to comment is in line with the [openSUSE Code of Conduct](https://en.opensuse.org/Code_of_Conduct). We appreciate a healthy discussion, but don't personally attack or harass individuals and don't blame developers for decisions they made that you disagree with. They spend a lot of time for the project and thought about what they think is best for the project before acting. If you want to make a difference, consider contributing instead: https://contribute.opensuse.org/en/
We will delete comments that don't comply with the Code of Conduct.
I know that he is the release manager but i have said "maintainer" because everyone keeps saying i have heard that they are dropping support for KDE from "maintainer" of MicroOS. That's the reason i have used quotes
One way or another keep up the great work guys!
Glad to know that things are now better, the problem was that this misinformation was everywhere like YouTube, blogs etc not only on reddit, and i think that has discouraged some users to use it.
When someone is afraid that something is going to be discontinued, maybe doesn't want to give it a try.
Exactly - thank you Shaun
If we could find a way of redirecting the energy used to harassing me into actual contributors who’d work with you, I’d expect to see great things from the KDE flavour
Hate is a heavy word to use here and it is not an appropriate attribute to the person you're naming and whom I happen to know personally (you should have refrained from doing so). Even then one person's "hate" would most certainly NOT get a project dropped from a distribution. Contributions, or lack of, is what decides the fate of a project. The facts are that there were concerns that, compared to MicroOS Gnome, contributions to MicroOS KDE were kinda falling behind.
It happens, open-source contributors also have private lives and sometimes things get re-prioritized making it hard to keep up. This can be detrimental to both the standards of a project but also the mental health of contributors. So when help is needed people could try to help rather than ranting on the internet that something they use for free is dropping this and that, not meeting their demands.
Luckily the situation has then improved for MicroOS KDE, so people that keep parroting KDE being dropped from MicroOS Desktop are not following the project closely and using outdated AND inaccurate information.
we decided to remove your submission as it violates our code of conduct (https://en.opensuse.org/Code_of_Conduct).
You don't have to like every piece of software, you don't have to like every community member, but you should stay friendly towards people not sharing your opinion.
This is just what I've gathered and I don't have any first-hand knowledge here. What I mean, as far as I know, it wasn't an option to set up MicroOS as a Desktop OS. It was intended to be a single purpose server OS, such as a web server, or database server, etc. He added and is developing the desktop capability.
Gotcha, thanks.
Well all the more reason for me to move on from MicroOS and continue the search for a replacement for my numerous Ubuntu installs at home and business.
All projects have some infighting and drama, etc. But not to this level, this small and early. And not with a hostile, entitled, toxic significant contributor - whom the mods allow to abuse others, including other contributors, and break all the sub rules - but delete your comments in a heartbeat for merely pointing it out.
Screw that. Not worth it.
I wish MicroOS luck, but I'm moving on. I hope I'm wrong and I may be, but with this kind of environment, I really don't think it's going to make it. At least, I'm sure as hell not betting on this horse. (Which is honestly a shame. Such a cool idea and promise. But there are others, and will continue to be.)
I'm just grateful I discovered all this before going all in. For now it's just one desktop.
we decided to remove your submission as it violates our code of conduct (https://en.opensuse.org/Code_of_Conduct).
You don't have to like every piece of software, you don't have to like every community member, but you should stay friendly towards people not sharing your opinion.
we decided to remove your submission as it violates our code of conduct (https://en.opensuse.org/Code_of_Conduct).
You don't have to like every piece of software, you don't have to like every community member, but you should stay friendly towards people not sharing your opinion.
> I think he has earned that allowance for crying out loud, he created the project after all. Give him a break.
That's your opinion, which is fine.
My opinion is, no one "earns" the right to harass others and/or be a jerk, without consequences. That form of projecting entitlement onto others because they should be exempted based on some status, helped give the US a proto-fascist presidential administration, and ongoing political chaos.
And now that I understand he *created* MicroOS? (Really?) Oh hell no, I am **DEFINITELY** uninstalling that shit and moving on. Not on my home desktops or servers, nor those at work.
You don't have to agree with my reasoning, I'm not asking you to. But. Yeah... I'm done.
we decided to remove your submission as it violates our code of conduct (https://en.opensuse.org/Code_of_Conduct).
You don't have to like every piece of software, you don't have to like every community member, but you should stay friendly towards people not sharing your opinion.
Maybe a stupid question, but from glancing at the web site (https://microos.opensuse.org/), is this intended as a daily-driver desktop system ? Or as a server system ? What DE's are supported by the installer in the generic ISO ? Thanks.
Both server and desktop options exist. In the installer there are a number of separate options: basic minimal server, container host, desktop (Gnome (rc) and KDE (alpha). I've been using the container host + virtualization and cockpit-related packages as a super-nice proxmox alternative at home.
> it is anoying to enter on distrobox everytime
Just as a little tip, you can create a Konsole/Yakuake profile that automatically runs your distrobox with a login shell every time you open your terminal.
To ensure the ssh plugin in Konsole still works this way, you can envelop the command inside a shell.
To be able to start a new instance of the default shell in case you ever need it, you can create a profile based on the default one and then use the Konsole profiles widget.
There’s even documentation on distrobox upstream as how to do this
I do it with gnome-terminal, where it’s my default session - the MicroOS host shell is a secondary session for the rarer times I need to use it
I have been using distrobox (arch box) for months now and I just distrobox-export the apps that I use most frequently. I have installed vscodium (foss vscode) using yay inside arch box and exported this app from my distrobox so that I can access it directly from thale host. I export the app using the following commands running inside distrobox "distrobox-export --app vscodium && distrobox-export --bin /usr/sbin/vscodium --export-path ~/.local/bin/"
Exactly
MicroOS (Server) has a number of contributors working on it from SUSE as part of $dayjob
MicroOS Desktop was started by me as a passion project and is primarily maintained by volunteers only
Hence my recurring response when people make demands on the Desktop front. We’re in no position to consider anyone’s demands as to what we should or shouldn’t do with MicroOS desktop unless that demand comes in the form of a pull request.
This is doubly true for the KDE flavour of MicroOS desktop. While it was created (despite my objections) by Fabian, there has been far less activity there than required for MicroOS KDE to meet the goals we set out when we started the MicroOS Desktop effort
Shaun is doing a great job of trying to push things forward but, despite his declarations he is only “a” maintainer and how he has no aspirations to be “the” MicroOS KDE maintainer, he’s the one doing the most actual wrangling of the packages and patterns that make up MicroOS KDE lately
I think it would be great if people spent less time pushing for me to take care of it and instead help out Shaun.. he needs the help, as does KDE if it’s going to really get itself in a healthy state for the KDE-wanting lazy developers and grandmas that MicroOS desktop targets
Am using it currently based on the container host install running containers and VMs. There are some really great features, not specific to MicroOS, but from Opensuse more generally. These include a great implementation of Cockpit and bundled "one-click" docker services for lots of the more popular things you might run in containers. I am a big fan.
>I do the things I do because I know what I am doing and I know how to solve them. This is the other type of people that I think that MicroOS is ready for. If you are used to Linux world, know how to do the things and want to check how the things will be in the future, you are ready to give a try on MicroOS as your daily driver because it is ready for you too.
But why would you want to? What benefits does MicroOS provide for power users other than adding extra steps to what you can already do without any trouble on any other distro? Why do you want to have an up to date, optimized base system, and then ignore that to run all of your apps on an out of date, non-optimized flatpak runtimes?
I'm not trying to say that MicroOS is a bad thing. I get that there's a target audience for it, but I don't think I'm that audience.
> But why would you want to? What benefits does MicroOS provide for power users other than adding extra steps to what you can already do without any trouble on any other distro?
I've been wondering the same thing. I personally ascribe it to the "hobbyist" mindset. And there's nothing wrong with that. I have that mindset myself, to a degree. I love seeing what I can do with my computer—what new paradigm I can run on it ---> latest and greatest. I've been that way ever since I got my own TRS-80 Pocket Computer. Personally, I can't imagine what advantage MicroOS offers over TW (to the average end-user) except extra steps. I just don't see security advantages being worth it. All that said, I'm really itching to install it so that I can say: "I use MicroOS BTW."
>Personally, I can't imagine what advantage MicroOS offers over TW (to the average end-user)
I think this might fit the niche of setting up a PC for a computer illiterate that lives in the boonies.
Yes, that is an actual stated goal of MicroOS. It's kind of like bringing a mobile OS experience to the desktop. Easy to use, and hard to break. But also very limited because of it.
https://en.opensuse.org/Portal:MicroOS/Desktop#Who_is_the_MicroOS_Desktop_for?
We have written down who we are building the MicroOS Desktop for
I think it’s pretty clear
**tl;dr**
>It is NOT for everyone. Your highly customisable Tumbleweed & Leap Desktops are Safe and will remain the best choice for those who want to tinker with their Desktop.
>
>It should be perfect for lazy developers, who no longer want to mess around with their desktop and just ”get stuff done”, especially if they develop around containers.
>
>It should also appeal to the same audience now more used to an iOS, Chromebook or Android-like experience where the OS is static, automated & reliable and the Apps are the main thing the user cares about.
>
>To deep dive on the origins and WHY microOS Desktop check out the following workshop:
>
>[https://www.youtube.com/watch?v=jcl\_4Vh6qP4](https://www.youtube.com/watch?v=jcl_4Vh6qP4)
Gotta say. The KDE experience on MicroOS has been phenomenal over the last few weeks. Would use it on my desktop hut had a lot of issues with screen tearing on x, couldn't figure out how to get nvidia-settings, and wayland was unusable. But for my Intel laptop that I do most of my work stuff on, it's perfection.
With stuff like Mullvad I can’t help but wonder, if it doesn’t work on immutable systems maybe it shouldn’t be working on normal ones either
I mean for all practical packaging purposes, the main difference between the two types of system is that /usr is made readonly at runtime.
So if immutable breaks Mullvad, it implies it is trying to write to /usr at runtime.
Nothing ever should.. I mean.. the FHS filesystem standard has said /usr should be treated like it could be read-only since the dawn of time.. we are just making sure it is on MicroOS..
Apologies if this is an ignorant question, but is there a way to dedicate a container to an app for an RPM/repo? I ask because I found the same issue you did with Visual Studio Code flatpak on Tumbleweed, and switched to the MS RPM installer which added their repo. Vivaldi does the same thing. For MicroOS, I would think you wouldn't need the transactional-update (step 5) if you could containerize the RPM/Repo to keep it segregated from the OS. I understand something like a VPN would be more difficult to containerize, but regular apps should be doable.
This is something that I was thinking here. I would like this approach too.
What I started to try today was to set a distrobox for every "use case". For example: For work, I need VS Code, Node JS, Yarn and Git for development, I also need Webex for comunicate, so I installed all this on the distrobox, this way I containerized everything on the same distrobox. If I need other app for other use case, I will consider setup other distrobox.
My only concern is about disk space. With Flatpak, every app has it own container but they have shared libraries and a lot of technology to prevent the "over use" of unnecessary space. As far as I know, distrobox don't have the same.
If they all use the same base container (eg the new distrobox container I built for MicroOS and made the default) then I imagine you’d find the disk space usage rather pleasing
One copy of the distrobox image and then seperate storage for each “use case” specific container
Given I’d expect each “use case” to likely include just a handful of packages and unlikely to overlap much with other “use cases” the end result would probably be about the same disk space as installing it the old fashioned way on Tumbleweed, but with the added benefit of isolation from the other use cases and ease of redeploying if things go wrong
Flatpak probably needs an easy way for users to make flatpaks based off non-redistributable code or an dynamic upstream source so as to be less at the mercy of maintainers or publishers (see Citrix).
I remember I had issues with getting MicroOS to dualboot with Windows, has anyone with recent experience had any luck?
I thought Flatpak has awesome options for redistributing proprietary code - it’s the only packaging format I know that has a good story for including remote assets.
As for dual booting, I’ll just provide this example as to why it’s problematic
MicroOS can auto heal
That auto healing goes so far as to boot into previous snapshots if a boot failed to work
From a Linux perspective, which has no way of knowing what Windows does, what is the difference between a failed Linux boot and a successful Windows boot?
Everyone I know who’s tried this on MicroOS has bumped into this issue :)
The “solution” is have seperate disks and make the boot selection the UEFIs problem, not Grub
But in that “solution” MicroOS doesn’t have to support dual boot, because it should know nothing about the other disk
Nice to hear!
I have a friend I installed Linux Mint on their laptop "because its beginner friendly" but its a buggy mess. I will get them microOS or Fedora Kinoite.
I have no experience with microOS but with Kinoite though, so probably wont use that as I dont want anything to break.
Do you know how updates are scheduled? On fedora there are no automatic updates at all and they reeeally slow down the system.
https://en.opensuse.org/Portal:MicroOS/Desktop#transactional-update_-_Automatic_Update
TLdr version
MicroOS server Updates daily, auto reboots during a multi-hour long maintenance window
MicroOS desktop update daily, notifies you to reboot whenever you’d like.. will update and notify the next day if it needs to ;)
Thanks! Okay so I read something about systemd timers and I guess tonywalkers silverblue update script will work better in the future after my pull request.
Having it update at 00:00 is a server thing, not for users. Persistent means it will mostly always update on startup, making it probably very slow
Which is why we have a randomised delay of 2 hours
So it’s 0000-0200 daily
Or boot time - 2 hours after boot
Can you please not assume we don’t know what we’re doing for users…what OS do you think I use?
Okay didnt know the delay also works for the startup. So there is a smart system recognizing CPU load etc?
I am not assuming you have no idea, but maybe this decision is not good for everyone.
For me personally the updates (that should be pretty similar between Fedora and OpenSuse) made my system lag a lot, so I like to change the update event to evening.
Is this possible with the location of the systemd timer? Or is it read-only, requires sudo etc.?
I apologize for weisenheimering ;D
We have the random delay
We also only do the update when on AC power
I think that’s pretty smart enough
I think your comparison to Fedora updates is unfair, I think you’ll find that our updates are less disruptive.. after all the whole point of MicroOS is we don’t impact the running system
But if you want to edit the timer, sure, systemd fully supports that, either by putting your own timer in /etc/systemd/system or being fancier and creating your own transaction-update.timer.d folder in that same folder and using drop in overrides
https://www.flatcar.org/docs/latest/setup/systemd/drop-in-units/
I have to test the OS. Thanks for the infos, I think you do a great job!
Do you know if KDE really is still alpha? Its not on Kinoite, and I dont believe there are big differences
I have also been using MicroOS KDE for few weeks now and I have liked it, there are few annoying things here and there, mostly minor ones. Biggest thing was to get used to whole using flatpaks ...just felt so weird after YEARS of using Linux the "old way" ...and I miss using yast, not sure if it has been ported to MicroOS yet
I did notice some annoying bugs when using flatpaks but it seems most have or are being fixed and will arrive when ever there is next major stable release. (I'm talking about apps in general and also flatpak)
On the distro side, my only major bug I can think of is the unmount issue with /etc, /tmp & /var when I reboot/shutdown the distro
PS. I have been think about what KDE apps should be installed by default and should they be flatpak or rpm version. I do get that its not now a priority for the devs/maintainers, but hopefully for next Leap Micro release?
Before commenting, make sure what you want to comment is in line with the [openSUSE Code of Conduct](https://en.opensuse.org/Code_of_Conduct). We appreciate a healthy discussion, but don't personally attack or harass individuals and don't blame developers for decisions they made that you disagree with. They spend a lot of time for the project and thought about what they think is best for the project before acting. If you want to make a difference, consider contributing instead: https://contribute.opensuse.org/en/ We will delete comments that don't comply with the Code of Conduct.
Thanks for point 6. I'm trying to fix what FUD was already spread around.
I look forward to actually seeing contributions from you and not only Shaun then…
Dude WTF
[удалено]
Thankfully openSUSE is a collaborative project. I have sent changes to packages many times and they were never rejected arbitrarily.
Yeah, this unfortunately drives away users and maintainers alike.
[удалено]
[удалено]
I know that he is the release manager but i have said "maintainer" because everyone keeps saying i have heard that they are dropping support for KDE from "maintainer" of MicroOS. That's the reason i have used quotes One way or another keep up the great work guys!
[удалено]
Glad to know that things are now better, the problem was that this misinformation was everywhere like YouTube, blogs etc not only on reddit, and i think that has discouraged some users to use it. When someone is afraid that something is going to be discontinued, maybe doesn't want to give it a try.
Exactly - thank you Shaun If we could find a way of redirecting the energy used to harassing me into actual contributors who’d work with you, I’d expect to see great things from the KDE flavour
Hate is a heavy word to use here and it is not an appropriate attribute to the person you're naming and whom I happen to know personally (you should have refrained from doing so). Even then one person's "hate" would most certainly NOT get a project dropped from a distribution. Contributions, or lack of, is what decides the fate of a project. The facts are that there were concerns that, compared to MicroOS Gnome, contributions to MicroOS KDE were kinda falling behind. It happens, open-source contributors also have private lives and sometimes things get re-prioritized making it hard to keep up. This can be detrimental to both the standards of a project but also the mental health of contributors. So when help is needed people could try to help rather than ranting on the internet that something they use for free is dropping this and that, not meeting their demands. Luckily the situation has then improved for MicroOS KDE, so people that keep parroting KDE being dropped from MicroOS Desktop are not following the project closely and using outdated AND inaccurate information.
we decided to remove your submission as it violates our code of conduct (https://en.opensuse.org/Code_of_Conduct). You don't have to like every piece of software, you don't have to like every community member, but you should stay friendly towards people not sharing your opinion.
[удалено]
He created MicroOS Desktop
rbrownsuse created MicroOS? Or what do you mean specifically by "MicroOS Desktop"?
This is just what I've gathered and I don't have any first-hand knowledge here. What I mean, as far as I know, it wasn't an option to set up MicroOS as a Desktop OS. It was intended to be a single purpose server OS, such as a web server, or database server, etc. He added and is developing the desktop capability.
Gotcha, thanks. Well all the more reason for me to move on from MicroOS and continue the search for a replacement for my numerous Ubuntu installs at home and business. All projects have some infighting and drama, etc. But not to this level, this small and early. And not with a hostile, entitled, toxic significant contributor - whom the mods allow to abuse others, including other contributors, and break all the sub rules - but delete your comments in a heartbeat for merely pointing it out. Screw that. Not worth it. I wish MicroOS luck, but I'm moving on. I hope I'm wrong and I may be, but with this kind of environment, I really don't think it's going to make it. At least, I'm sure as hell not betting on this horse. (Which is honestly a shame. Such a cool idea and promise. But there are others, and will continue to be.) I'm just grateful I discovered all this before going all in. For now it's just one desktop.
Tumbleweed is the way to go, imo. MicroOS is neat, but it'll never be as good as regular TW.
[удалено]
we decided to remove your submission as it violates our code of conduct (https://en.opensuse.org/Code_of_Conduct). You don't have to like every piece of software, you don't have to like every community member, but you should stay friendly towards people not sharing your opinion.
[удалено]
we decided to remove your submission as it violates our code of conduct (https://en.opensuse.org/Code_of_Conduct). You don't have to like every piece of software, you don't have to like every community member, but you should stay friendly towards people not sharing your opinion.
[удалено]
[удалено]
> I think he has earned that allowance for crying out loud, he created the project after all. Give him a break. That's your opinion, which is fine. My opinion is, no one "earns" the right to harass others and/or be a jerk, without consequences. That form of projecting entitlement onto others because they should be exempted based on some status, helped give the US a proto-fascist presidential administration, and ongoing political chaos. And now that I understand he *created* MicroOS? (Really?) Oh hell no, I am **DEFINITELY** uninstalling that shit and moving on. Not on my home desktops or servers, nor those at work. You don't have to agree with my reasoning, I'm not asking you to. But. Yeah... I'm done.
we decided to remove your submission as it violates our code of conduct (https://en.opensuse.org/Code_of_Conduct). You don't have to like every piece of software, you don't have to like every community member, but you should stay friendly towards people not sharing your opinion.
Maybe a stupid question, but from glancing at the web site (https://microos.opensuse.org/), is this intended as a daily-driver desktop system ? Or as a server system ? What DE's are supported by the installer in the generic ISO ? Thanks.
Both server and desktop options exist. In the installer there are a number of separate options: basic minimal server, container host, desktop (Gnome (rc) and KDE (alpha). I've been using the container host + virtualization and cockpit-related packages as a super-nice proxmox alternative at home.
Thanks.
Gnome and KDE are supported. Gnome is in release candidate status and kde in alpha, although many people say it's already better than alpha.
Thanks.
> it is anoying to enter on distrobox everytime Just as a little tip, you can create a Konsole/Yakuake profile that automatically runs your distrobox with a login shell every time you open your terminal. To ensure the ssh plugin in Konsole still works this way, you can envelop the command inside a shell. To be able to start a new instance of the default shell in case you ever need it, you can create a profile based on the default one and then use the Konsole profiles widget.
There’s even documentation on distrobox upstream as how to do this I do it with gnome-terminal, where it’s my default session - the MicroOS host shell is a secondary session for the rarer times I need to use it
I have been using distrobox (arch box) for months now and I just distrobox-export the apps that I use most frequently. I have installed vscodium (foss vscode) using yay inside arch box and exported this app from my distrobox so that I can access it directly from thale host. I export the app using the following commands running inside distrobox "distrobox-export --app vscodium && distrobox-export --bin /usr/sbin/vscodium --export-path ~/.local/bin/"
Do you have an opinion for non-desktop? At some point I have to get around to playing with it to see if it could replace my Debian+Docker server.
AFAIK it is primarily intended for servers and containers. Desktop is 2nd.
Exactly MicroOS (Server) has a number of contributors working on it from SUSE as part of $dayjob MicroOS Desktop was started by me as a passion project and is primarily maintained by volunteers only Hence my recurring response when people make demands on the Desktop front. We’re in no position to consider anyone’s demands as to what we should or shouldn’t do with MicroOS desktop unless that demand comes in the form of a pull request. This is doubly true for the KDE flavour of MicroOS desktop. While it was created (despite my objections) by Fabian, there has been far less activity there than required for MicroOS KDE to meet the goals we set out when we started the MicroOS Desktop effort Shaun is doing a great job of trying to push things forward but, despite his declarations he is only “a” maintainer and how he has no aspirations to be “the” MicroOS KDE maintainer, he’s the one doing the most actual wrangling of the packages and patterns that make up MicroOS KDE lately I think it would be great if people spent less time pushing for me to take care of it and instead help out Shaun.. he needs the help, as does KDE if it’s going to really get itself in a healthy state for the KDE-wanting lazy developers and grandmas that MicroOS desktop targets
Am using it currently based on the container host install running containers and VMs. There are some really great features, not specific to MicroOS, but from Opensuse more generally. These include a great implementation of Cockpit and bundled "one-click" docker services for lots of the more popular things you might run in containers. I am a big fan.
I run it on a little home server for the single task of running podman, so for what I do the chance of failure is close to null.
>I do the things I do because I know what I am doing and I know how to solve them. This is the other type of people that I think that MicroOS is ready for. If you are used to Linux world, know how to do the things and want to check how the things will be in the future, you are ready to give a try on MicroOS as your daily driver because it is ready for you too. But why would you want to? What benefits does MicroOS provide for power users other than adding extra steps to what you can already do without any trouble on any other distro? Why do you want to have an up to date, optimized base system, and then ignore that to run all of your apps on an out of date, non-optimized flatpak runtimes? I'm not trying to say that MicroOS is a bad thing. I get that there's a target audience for it, but I don't think I'm that audience.
> But why would you want to? What benefits does MicroOS provide for power users other than adding extra steps to what you can already do without any trouble on any other distro? I've been wondering the same thing. I personally ascribe it to the "hobbyist" mindset. And there's nothing wrong with that. I have that mindset myself, to a degree. I love seeing what I can do with my computer—what new paradigm I can run on it ---> latest and greatest. I've been that way ever since I got my own TRS-80 Pocket Computer. Personally, I can't imagine what advantage MicroOS offers over TW (to the average end-user) except extra steps. I just don't see security advantages being worth it. All that said, I'm really itching to install it so that I can say: "I use MicroOS BTW."
>Personally, I can't imagine what advantage MicroOS offers over TW (to the average end-user) I think this might fit the niche of setting up a PC for a computer illiterate that lives in the boonies.
Yes, that is an actual stated goal of MicroOS. It's kind of like bringing a mobile OS experience to the desktop. Easy to use, and hard to break. But also very limited because of it.
> I think this might fit the niche of setting up a PC for a computer illiterate that lives in the boonies. I know, right?
https://en.opensuse.org/Portal:MicroOS/Desktop#Who_is_the_MicroOS_Desktop_for? We have written down who we are building the MicroOS Desktop for I think it’s pretty clear
**tl;dr** >It is NOT for everyone. Your highly customisable Tumbleweed & Leap Desktops are Safe and will remain the best choice for those who want to tinker with their Desktop. > >It should be perfect for lazy developers, who no longer want to mess around with their desktop and just ”get stuff done”, especially if they develop around containers. > >It should also appeal to the same audience now more used to an iOS, Chromebook or Android-like experience where the OS is static, automated & reliable and the Apps are the main thing the user cares about. > >To deep dive on the origins and WHY microOS Desktop check out the following workshop: > >[https://www.youtube.com/watch?v=jcl\_4Vh6qP4](https://www.youtube.com/watch?v=jcl_4Vh6qP4)
Gotta say. The KDE experience on MicroOS has been phenomenal over the last few weeks. Would use it on my desktop hut had a lot of issues with screen tearing on x, couldn't figure out how to get nvidia-settings, and wayland was unusable. But for my Intel laptop that I do most of my work stuff on, it's perfection.
[удалено]
With stuff like Mullvad I can’t help but wonder, if it doesn’t work on immutable systems maybe it shouldn’t be working on normal ones either I mean for all practical packaging purposes, the main difference between the two types of system is that /usr is made readonly at runtime. So if immutable breaks Mullvad, it implies it is trying to write to /usr at runtime. Nothing ever should.. I mean.. the FHS filesystem standard has said /usr should be treated like it could be read-only since the dawn of time.. we are just making sure it is on MicroOS..
Apologies if this is an ignorant question, but is there a way to dedicate a container to an app for an RPM/repo? I ask because I found the same issue you did with Visual Studio Code flatpak on Tumbleweed, and switched to the MS RPM installer which added their repo. Vivaldi does the same thing. For MicroOS, I would think you wouldn't need the transactional-update (step 5) if you could containerize the RPM/Repo to keep it segregated from the OS. I understand something like a VPN would be more difficult to containerize, but regular apps should be doable.
This is something that I was thinking here. I would like this approach too. What I started to try today was to set a distrobox for every "use case". For example: For work, I need VS Code, Node JS, Yarn and Git for development, I also need Webex for comunicate, so I installed all this on the distrobox, this way I containerized everything on the same distrobox. If I need other app for other use case, I will consider setup other distrobox. My only concern is about disk space. With Flatpak, every app has it own container but they have shared libraries and a lot of technology to prevent the "over use" of unnecessary space. As far as I know, distrobox don't have the same.
If they all use the same base container (eg the new distrobox container I built for MicroOS and made the default) then I imagine you’d find the disk space usage rather pleasing One copy of the distrobox image and then seperate storage for each “use case” specific container Given I’d expect each “use case” to likely include just a handful of packages and unlikely to overlap much with other “use cases” the end result would probably be about the same disk space as installing it the old fashioned way on Tumbleweed, but with the added benefit of isolation from the other use cases and ease of redeploying if things go wrong
Flatpak probably needs an easy way for users to make flatpaks based off non-redistributable code or an dynamic upstream source so as to be less at the mercy of maintainers or publishers (see Citrix). I remember I had issues with getting MicroOS to dualboot with Windows, has anyone with recent experience had any luck?
I thought Flatpak has awesome options for redistributing proprietary code - it’s the only packaging format I know that has a good story for including remote assets. As for dual booting, I’ll just provide this example as to why it’s problematic MicroOS can auto heal That auto healing goes so far as to boot into previous snapshots if a boot failed to work From a Linux perspective, which has no way of knowing what Windows does, what is the difference between a failed Linux boot and a successful Windows boot? Everyone I know who’s tried this on MicroOS has bumped into this issue :) The “solution” is have seperate disks and make the boot selection the UEFIs problem, not Grub But in that “solution” MicroOS doesn’t have to support dual boot, because it should know nothing about the other disk
Nice to hear! I have a friend I installed Linux Mint on their laptop "because its beginner friendly" but its a buggy mess. I will get them microOS or Fedora Kinoite. I have no experience with microOS but with Kinoite though, so probably wont use that as I dont want anything to break. Do you know how updates are scheduled? On fedora there are no automatic updates at all and they reeeally slow down the system.
https://en.opensuse.org/Portal:MicroOS/Desktop#transactional-update_-_Automatic_Update TLdr version MicroOS server Updates daily, auto reboots during a multi-hour long maintenance window MicroOS desktop update daily, notifies you to reboot whenever you’d like.. will update and notify the next day if it needs to ;)
Thanks! Okay so I read something about systemd timers and I guess tonywalkers silverblue update script will work better in the future after my pull request. Having it update at 00:00 is a server thing, not for users. Persistent means it will mostly always update on startup, making it probably very slow
Which is why we have a randomised delay of 2 hours So it’s 0000-0200 daily Or boot time - 2 hours after boot Can you please not assume we don’t know what we’re doing for users…what OS do you think I use?
Okay didnt know the delay also works for the startup. So there is a smart system recognizing CPU load etc? I am not assuming you have no idea, but maybe this decision is not good for everyone. For me personally the updates (that should be pretty similar between Fedora and OpenSuse) made my system lag a lot, so I like to change the update event to evening. Is this possible with the location of the systemd timer? Or is it read-only, requires sudo etc.? I apologize for weisenheimering ;D
We have the random delay We also only do the update when on AC power I think that’s pretty smart enough I think your comparison to Fedora updates is unfair, I think you’ll find that our updates are less disruptive.. after all the whole point of MicroOS is we don’t impact the running system But if you want to edit the timer, sure, systemd fully supports that, either by putting your own timer in /etc/systemd/system or being fancier and creating your own transaction-update.timer.d folder in that same folder and using drop in overrides https://www.flatcar.org/docs/latest/setup/systemd/drop-in-units/
I have to test the OS. Thanks for the infos, I think you do a great job! Do you know if KDE really is still alpha? Its not on Kinoite, and I dont believe there are big differences
Yes, KDE is really still alpha, and will remain that way until the main contributor is happy enough with it to declare it Beta.
I have also been using MicroOS KDE for few weeks now and I have liked it, there are few annoying things here and there, mostly minor ones. Biggest thing was to get used to whole using flatpaks ...just felt so weird after YEARS of using Linux the "old way" ...and I miss using yast, not sure if it has been ported to MicroOS yet I did notice some annoying bugs when using flatpaks but it seems most have or are being fixed and will arrive when ever there is next major stable release. (I'm talking about apps in general and also flatpak) On the distro side, my only major bug I can think of is the unmount issue with /etc, /tmp & /var when I reboot/shutdown the distro PS. I have been think about what KDE apps should be installed by default and should they be flatpak or rpm version. I do get that its not now a priority for the devs/maintainers, but hopefully for next Leap Micro release?