On Fri, 24 Apr 2020 at 18:40, Dario Faggioli
I guess we should probably add these to the desktop pattern?
I think we should, indeed. SR submitted. My first for this project, so if I've done some stupid mistake, point them to me, and I'll try again.
gcr-ssh-askpass, for having the ssh-agent properly working in presence of gnome-keyring is also pretty important, IMO. If the SR for the calendaring stuff goes well, I'll send another for it.
The SR looked perfect to me, it's on the way to Factory where OBS and openQA will confirm if we were right or not ;)
About the other packages I manually installed for doing these tests, I don't know. I guess, for instance, CUPS, it's reasonable to assume that it should be there in a Desktop setup. Perhaps not with all the possible PPDs packages we have in the repositories, though... not sure.
Manual pages and bash-completion are other things that I personally find quite indispensable. But should they just always be there? If not, should they really depend on the GNOME Desktop pattern or on some other one?
The general philosophy with MicroOS is that a deployed MicroOS installation is designed to do 'just one job' and that the installed packages provide everything needed by the user to do that 'just one job'. Ideally, a MicroOS installation shouldn't _need_ tinkering with `transactional-update pkg` after install to add or remove things (the fact that users can is cool..but I don't think we should design our installations with that in mind). And so, if we as a group feel that printers, PPDs, man pages and bash-completion are mandatory features for a user-interactive desktop based on MicroOS, I have no problem adding them to the Desktop pattern. They absolutely might not make sense in the base MicroOS pattern (IIRC we removed some of them from there even) but that's a very different usecase, with user-interactivity being far less likely.
Too Many Passowrds ------------------
I checked "Make this user the administrator" during install.
I have configured passwordless sudo (via group wheel).
Still asked for password a lot of times, e.g.: * at login ("refreshing system software database") * at reboot / shutdown ("authentication is required to reboot the system")
Yeah, the excessive passwords (due to missing/incomplete/invalid polkit config I believe) is the #1 reason why I threw the word 'ALPHA' on the system role. I haven't had the time to look at it yet but I really would love if it someone did :)
Indeed. I'll see about that, but I also know next to nothing about how polkit is configured and works.
I've got little idea either, I appreciate you having a look :)
Disk Partitioning -----------------
I went pretty much with default partitioning.
Two installs: * 40 GB, 15G root, 25G var - 1,4G free on root, 25G free on var !!! * 60 GB, 37G root, 24G var - 15G free on root, 22G free on var
So, beware of provisioning enouch space for /home, as a lot of stuff goes there.
Hmm, we could add a seperate partition for /home or change the ratios required for /root - what would you prefer?
I personally don't like setups with separate /home partitions. Even less so when we have and can use BTRFS subvolumes. Separate partitions force me to think "how much space will I need for these on this system?" which is something I hate doing, because I always get it wrong.
So I'd go for the ratio changing approach. I probably don't have enough data for being super sure, but my gut feel is that on a typical single user Desktop install, the "stress" on the /var partition would be pretty low.
Depends, /var is where containers live, and as I discovered this week if you don't remember to tidy up all your container images, it sure comes back to bite you after a while ;) (That's why container image cleanup will now be enabled by default on the MicroOS Container host role...)
BTW, just curious, how big of a nonsense would it be to use a subvolume for /var too?
The problem is primarily with containers. For performance and stability, we use the btrfs driver in podman & docker. This makes subvolumes for each containers storage. For the space aware cleanup of snapper we use qgroups on the btrfs root filesystem. qgroups plus all the subvolumes made by containers ends up being a massive performance drain. So having a separate partition to /var with qgroups disabled keeps the system running smooth, plus gives us the luxury of also being able to disable CoW on /var for even more performance for the workloads expected in /var. Neither optimisations make sense to me for /home, so keeping that as a subvolume makes sense to me. as the one who's setup all the ratios for every openSUSE distro I'll put my thinking cap on for a sensible new ratio for MicroOS Desktop but any suggestions are welcome - given how YaST maths work sometimes is nice to have a real world 'goal' rather than playing with the numbers till something 'feels' right ;) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org