Rust Bootcamp
Project Description
Join an instructor-led bootcamp to explore the Rust programming language in two-hour sessions each day throughout Hackweek. Sessions will be between 7-10am Pacific, 3-6pm Central Europe (exact time will be determined as we get closer)
Goal for this Hackweek
We want to raise awareness of Rust and give hands-on experience over HackWeek. If the attendees want to hack together on a Rust project, I'm fully in support of that.
Resources
Why Rust? https://confluence.suse.com/x/GYJiKQ
Update
*Our instructor will be Anatol Ulrich of Ferrous systems.
*We will be recording these sessions and posting them in the HackWeek Stream
*We have a rocketchat room #RustBootcampHackWeek20
*More about the company running the training https://ferrous-systems.com/
*More about Rust: https://www.rust-lang.org/
Looking for hackers with the skills:
This project is part of:
Hack Week 20
Activity
Comments
-
-
over 3 years ago by csalmond | Reply
Does anyone know if SUSE has plans to use/include Rust in distros?
Reply to agraul
Rust is already part of SLE 15 (see SMELT), openSUSE Leap 15 and, of course, openSUSE Tumbleweed
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
-
-
-
-
-
over 3 years ago by jguilhermevanz | Reply
I think is a good idea to have the environment ready for the sessions. Which version of Rust and tools do we need?
-
-
over 3 years ago by SMorlan | Reply
I will be sending out invites to the sessions tonight or tomorrow (US time). We can have 15 people in the session, so some latecomers will not be included. I have already started talking to Olli about just planning for another session for this during next Hack Week. With earlier planning we may be able to get separate sessions in geo locations and maybe full-day sessions.
-
-
-
Reply to ikapelyukhin
"We're gonna need a bigger boat"
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Similar Projects
SMB3 Server written entirely in Rust by dmulder
Description
Given the number of bugs frequently discovered in the Samba code caused by memory issues, it makes sense to re-write the smbd service purely in Rust code. Meanwhile, it would be wise to abandon backwards compatibility here with insecure protocol versions, and simply implement the SMB3 spec.
Goals
Get a simple server up and running and get it merged into upstream Samba (which now has Rust build support).
Resources
Agama installer on-line demo by lslezak
Description
The Agama installer provides a quite complex user interface. We have some screenshots on the web page but as it is basically a web application it would be nice to have some on-line demo where users could click and check it live.
The problem is that the Agama server directly accesses the hardware (storage probing) and loads installation repositories. We cannot easily mock this in the on-line demo so the easiest way is to have just a read-only demo. You could explore the configuration options but you could not change anything, all changes would be ignored.
The read-only demo would be a bit limited but I still think it would be useful for potential users get the feeling of the new Agama installer and get familiar with it before using in a real installation.
As a proof of concept I already created this on-line demo.
The implementation basically builds Agama in two modes - recording mode where it saves all REST API responses and replay mode where it for the REST API requests returns the previously recorded responses. Recording in the browser is inconvenient and error prone, there should be some scripting instead (see below).
Goals
- Create an Agama on-line demo which can be easily tested by users
- The Agama installer is still in alpha phase and in active development, the online demo needs to be easily rebuilt with the latest Agama version
- Ideally there should be some automation so the demo page is rebuilt automatically without any developer interactions (once a day or week?)
TODO
- Use OpenAPI to get all Agama REST API endpoints, write a script which queries all the endpoints automatically and saves the collected data to a file (see this related PR).
- Write a script for starting an Agama VM (use libvirt/qemu?), the script should ensure we always use the same virtual HW so if we need to dump the latest REST API state we get the same (or very similar data). This should ensure the demo page does not change much regarding the storage proposal etc...
- Fix changing the product, currently it gets stuck after clicking the "Select" button.
- Move the mocking data (the recorded REST API responses) outside the Agama sources, it's too big and will be probably often updated. To avoid messing the history keep it in a separate GitHub repository
- Allow changing the UI language
- Display some note (watermark) in the page so it is clear it is a read-only demo (probably with some version or build date to know how old it is)
- Automation for building new demo page from the latest sources. There should be some check which ensures the recorded data still matches the OpenAPI specification.
Changing the UI language
This will be quite tricky because selecting the proper translation file is done on the server side. We would probably need to completely re-implement the logic in the browser side and adapt the server for that.
Also some REST API responses contain translated texts (storage proposal, pattern names in software). We would need to query the respective endpoints in all supported languages and return the correct response in runtime according to the currently selected language.
Resources
- Agama sources
- Experimental proof of concept demo
- The respective source code change
Implement a CLI tool for Trento - trentoctl by nkopliku
Description
Implement a trentoctl CLI for interacting with a trento installation
Goals
- learn rust
- implement an initial
trentoctltool to enhance trento automation - have fun
Resources
trento rust. TUIs listed on this other hackweek project Hack on rich terminal user interfaces
Grapesss: a physical Shamir's Secret Sharing application [ESP32-C3 + Mobile] by ecandino
Description
A couple of years ago I created StegoSecretS, a small cli used to encrypt and split a secret into multiple keys, using the Shamir's Secret Sharing algorithm.
The idea is to re-implement the project using physical devices. One device alone will be useless, but when close together they can be used to decrypt the secret.
On a practical side the user encrypts the secret with a mobile application. The same application is used to split the secret, and load the partial keys into different micro-controllers. Another user will be able to decrypt the secret only having at least N devices close together (using the application).
I'm planning to use a couple of ESP32-C3 I bought, and build a very simple Android mobile application.
Goals
- Learn about Rust and micro-controllers (ESP32-C3)
- Learn about mobile applications (Android and Kotlin)
Resources
Hacking on sched_ext by flonnegren
Description
Sched_ext upstream has some interesting issues open for grabs:
Goals
Send patches to sched_ext upstream
Also set up perfetto to trace some of the example schedulers.
Resources
https://github.com/sched-ext/scx
SUSE Prague claw machine by anstalker
Project Description
The idea is to build a claw machine similar to e.g. this one:
Why? Well, it could be a lot of fun!
But also it's a great way to dispense SUSE and openSUSE merch like little Geekos at events like conferences, career fairs and open house events.
Goal for this Hackweek
Build an arcade claw machine.
Resources
In French, an article about why you always lose in claw machine games:
We're looking for handy/crafty people in the Prague office:
- woodworking XP or equipment
- arduino/raspi embedded programming knowledge
- Anthony can find a budget for going to GM and buying servos and such ;)
Explore simple and distro indipendent declarative Linux starting on Tumbleweed or Arch Linux by janvhs
Description
Inspired by mkosi the idea is to experiment with a declarative approach of defining Linux systems. A lot of tools already make it possible to manage the systems infrastructure by using description files, rather than manual invocation. An example for this are systemd presets for managing enabled services or the /etc/fstab file for describing how partitions should be mounted.
If we would take inspiration from openSUSE MicroOS and their handling of the /etc/ directory, we could theoretically use systemd-sysupdate to swap out the /usr/ partition and create an A/B boot scheme, where the /usr/ partition is always freshly built according to a central system description. In the best case it would be possible to still utilise snapshots, but an A/B root scheme would be sufficient for the beginning. This way you could get the benefit of NixOS's declarative system definition, but still use the distros package repositories and don't have to deal with the overhead of Flakes or the Nix language.
Goals
- A simple and understandable system
- Check fitness of
mkosior write a simple extensible image builder tool for it - Create a declarative system specification
- Create a system with swappable
/usr/partition - Create an A/B root scheme
- Swap to the new system without reboot (kexec?)
Resources
- Ideas that have been floating around in my head for a while
- https://0pointer.net/blog/fitting-everything-together.html
- GNOME OS
- MicroOS
- systemd mkosi
- Vanilla OS