Video Recording of openSUSE Conference session which discussed this project already

Core Project

MicroOS (and it's Kubernetes focused sister, Kubic) is an exciting distribution that takes much of the cool stuff we're doing in Tumbleweed, adds solutions to the problems of updating a running system, and is becoming the perfect base system for running containers.

But in openSUSE, running server stuff is only half the fun.

Why should servers be the only platform enjoying automatic, atomic, "auto-rollbackable" system updates?

Surely desktop users want to be lazy like server admins also?

Can the tools and approaches implemented in MicroOS help create the desktop distribution of the future?

Let's find out!

This Project will try to build, test, and introduce to the world the 'openSUSE MicroOS Desktop', a desktop focused variant of MicroOS based on Tumbleweed.

Sub Projects

BPF powered Tor networking for flatpaks

A BPF program which can we attached to flatpaks (via CGROUP_BPF, "cgroup/skb" section) which will redirect all the egress traffic from the given flatpak to Tor network. Such a program should be trivial to write, but it will be a good alternative for running whole virtualized systems like Tails or Whonix.

openSUSE Flatpaks

in the similar way Fedora is doing that - flatpaks based on OCI images. Those OCI images could be build with kiwi. That approach gives us benefits from flatpak, but at the same time we avoid bundling libraries in each flatpak image, instead we reuse our packaging and good model of handling dependencies globally for all the software.

Looking for hackers with the skills:

opensuse tumbleweed gnome flatpak kiwi obs distribution

This project is part of:

Hack Week 18 Hack Week 19

Activity

  • 6 days ago: vinzv liked MicroOS Desktop
  • 6 days ago: vinzv joined MicroOS Desktop
  • 12 days ago: Cbran joined MicroOS Desktop
  • 15 days ago: cdywan joined MicroOS Desktop
  • 18 days ago: emendonca left MicroOS Desktop
  • 18 days ago: emendonca joined MicroOS Desktop
  • 18 days ago: dfaggioli joined MicroOS Desktop
  • 18 days ago: cdywan liked MicroOS Desktop
  • 18 days ago: SLindoMansilla liked MicroOS Desktop
  • 19 days ago: aplanas liked MicroOS Desktop
  • All Activity

    Comments

    • mrostecki
      21 days ago by mrostecki | Reply

      I would like to join that project and propose two "subprojects" I would like to work on:

      • A BPF program which can we attached to flatpaks (via CGROUP_BPF, "cgroup/skb" section) which will redirect all the egress traffic from the given flatpak to Tor network. Such a program should be trivial to write, but it will be a good alternative for running whole virtualized systems like Tails or Whonix.
      • openSUSE flatpaks - in the similar way Fedora is doing that - flatpaks based on OCI images. Those OCI images could be build with kiwi. That approach gives us benefits from flatpak, but at the same time we avoid bundling libraries in each flatpak image, instead we reuse our packaging and good model of handling dependencies globally for all the software.

      • RBrownSUSE
        20 days ago by RBrownSUSE | Reply

        +1 to both to me..lets do this! :)

      • mrostecki
        18 days ago by mrostecki | Reply

        The main job here will be catching egress packets from the given cgroup and redirecting them to localhost:9050 or to whatever port the SOCKS proxy of Tor is listening to.

    • dfaggioli
      18 days ago by dfaggioli | Reply

      I was wondering, how does one do development, in an environment like this. I mean, the classic dev cycle of a good old (say, for instance) C project where even just to build test it (perhaps with your changes), you'd need to install a bunch of libfoo-devel, libbar-devel, libfoo-bar-devel, etc., which I don't think one wants to install on the "main OS" and, e.g., have to reboot each time that building with a new dependency is necessary. Libvirt, QEMU, Xen could be examples, arbitrarily chosen just because they're the ones I deal with sort of on a daily basis, but I think there may well be others.

      My wild guess would be that a "toolbox like" [1] approach could work? That is, having a simple way to spin up a container inside which one can build his project? Dependencies, one would install them inside the container manually, or we can allow for stashing a (or more) "dockerfile(s)" somewhere, that can then be fine-tuned and reused...

      If this makes any sort of sense, I would like to join the project with the aim of testing such a workflow, give feedback about it and, hopefully, improve it.

      I feel like adding that I have very few experience with MicroOS/Kubic, as well as with containers in general. And although learning new things is indeed the purpose of Hackweek, I'm not sure how far I'll be able to get.

      Anyway, let me know what you think. :-)

      • fcrozat
        18 days ago by fcrozat | Reply

        you mean https://kubic.opensuse.org/blog/2019-10-22-toolbox/ ? ;)

        • dfaggioli
          18 days ago by dfaggioli | Reply

          I definitely do mean that! I actually meant to put that very link in my comment... see the "[1]" I have there?

          But then I guess I forgot :-) Thanks

      • mrostecki
        18 days ago by mrostecki | Reply

        That's an interesting problem to solve and I was also thinking about it, but didn't come up with any solution.

        But yes, working on something "toolbox like" based on podman and container images sounds like a good approach to me.

        • fcrozat
          18 days ago by fcrozat | Reply

          This would have also the good approach of developers being able to use either MicroOS Desktop or Fedora Silverblue in the same way, without the need to learn something new for our solution.

          • dfaggioli
            18 days ago by dfaggioli | Reply

            Yep, indeed. Basically, this: "Toolbox: using Silverblue for development - Debarshi Ray - Flock 2019" ( https://www.youtube.com/watch?v=BGXs0W6NRBM )

        • dfaggioli
          18 days ago by dfaggioli | Reply

          Ok. So I guess I'm actually joining, I will look into how toolbox actually works and see if I can come up with something similar (but different! :-D)

          • mrostecki
            18 days ago by mrostecki | Reply

            Can't we actually use toolbox and contribute to it if you are not going to find any big disadvantages of that project? It's under "containers" organization on Github - https://github.com/containers/toolbox, so IMO we shouldn't consider it to be a "Red Hat project" - SUSE contributes to various github.com/containers projects too. It seems to use podman and it doesn't seem to depend on (rpm-)ostree, so it should work on openSUSE just fine.

            • dfaggioli
              18 days ago by dfaggioli | Reply

              Sure, I'm fine trying that and see if I can make it work for us. Definitely

          • mrostecki
            18 days ago by mrostecki | Reply

            Maybe we could start contribution with having the openSUSE image in images/ directory ;)

          • mrostecki
            18 days ago by mrostecki | Reply

            On the other hand, seems like there is a huge rewrite in Go pending https://github.com/containers/toolbox/pull/318

            • RBrownSUSE
              15 days ago by RBrownSUSE | Reply

              Our toolbox we already have is already better than most other distros toolboxes..it does everything I'd ever want (except one thing..which I will fix one day) but hey if others want to look at it I dont object :)

    • RBrownSUSE
      15 days ago by RBrownSUSE | Reply

      Hi all - anyone working on this project, I'm hanging out in #microos-desktop on irc.freenode.org now - we should use that to coordinate/chat :)

    • RBrownSUSE
      13 days ago by RBrownSUSE | Reply

      Current Steps In Progress at Time of Writing:

      • Submit new skelcd-control-MicroOS to YaST>Factory
      • Submit new microos-patterns to Factory
      • Ensure product builds media with new patterns-microos-[gnome|kde]-desktop patterns

      At this point MicroOS ISO's should have both a KDE and GNOME system role in 'Alpha' status

      Steps that must be accomplished to reach 'Beta'

      • Some openQA testing
      • Basic working functionality like logging in, application installation, etc

      Steps to remove the ugly 'Alpha' or 'Beta' flag from the installation

      • openQA testing for boot, login, application installation and some apps running
      • No unexpected reboots/sensible rebootmgr configuration
      • Notification to the user when a reboot is required

      • RBrownSUSE
        13 days ago by RBrownSUSE | Reply

        Steps to remove the ugly 'Alpha' or 'Beta' flag from the installation

        • Both KDE and GNOME should have an optimised package list from the hacked together examples right now

      • RBrownSUSE
        13 days ago by RBrownSUSE | Reply

        Current Steps In Progress at Time of Writing:

        • Submit new skelcd-control-MicroOS to YaST>Factory
        • Submit new microos-patterns to Factory
        • Ensure product builds media with new patterns-microos-[gnome|kde]-desktop patterns

        https://build.opensuse.org/request/show/773663 https://build.opensuse.org/request/show/773664 https://build.opensuse.org/request/show/773665

        Above is all otw to Factory, to be staged and adjusted there

    • Cbran
      12 days ago by Cbran | Reply

      Could someone show me around this?

    • dfaggioli
      11 days ago by dfaggioli | Reply

      Update from me: - we're discussing (in opensuse-kubic@opensuse.org) whether/how to change our toolbox image in order for it to fulfill the requirements of https://github.com/containers/toolbox - Thorsted has pushed some of those changes to devel:kubic:containers (see: https://build.opensuse.org/package/rdiff/devel:kubic:containers/opensuse-toolbox-image?linkrev=base&rev=7 ) - I've worked on making our toolbox a little bit more comfortable to use for development: https://github.com/dfaggioli/microos-toolbox/tree/user-mode https://github.com/kubic-project/microos-toolbox/pull/2

    • dfaggioli
      11 days ago by dfaggioli | Reply

      [Sorry for posting this twice, but the previous comment I wrote is barely readable! :-/]

      Update from me:

    Similar Projects

    Improve openSUSE infrastructure by lrupp

    There is always something to do if you run the ...


    openSUSE Leap release process improvements by lkocman

    Goal:

    I'd like to have the release proce...


    grab this: openSUSE beta test program and web application by lnussel

    openSUSE Leap 42.3 goes for a rolling release m...


    Small Livecd with mutltimedia capabilities by aginies

    Play with kiwi and liveCd capabilities to creat...


    Modernize Mash deployment by seanmarlow

    Mash is a Python based CI/CD pipeline for aut...


    Migrate more OBS service scripts to pure systemd by enavarro_suse

    Following the work started in the last hackweek...


    distributed build for Ceph in containers by denisok

    Investigate possibilities for the distributed b...


    OBS Project Monitor page redesign by vpereirabr

    Exactly what problem will this solve?

    Th...


    Test functional package manager for delivering packages by jevrard

    During the week, I install guix and analyse how...


    Testing GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the rocket chat channel! [https://chat.su...