Project Description
A few months ago, the YaST team released cockpit-wicked. Compared to YaST, this module contains a pretty simple data model, but there is still some duplication with YaST logic.
The idea of this project is to write some simple logic and try to reuse the same code from a YaST-like application and a web-based one (like Cockpit). Here is the (over-simplified) plan:
- Write a simple model that represents the network configuration (most probably, in Rust).
- Compile the model to WASM and try to use it from cockpit-wicked.
- Build a desktop/console UI that relies on this model too.
Goal for this Hackweek
To be honest, we do not plan to finish this project in a single week. However, we would like to achieve these goals:
- Find out how realistic is the overall approach (reusing logic in WASM and desktop apps). Try to identify threats and missing pieces.
- Learn the basics about WASM.
- Explore a GUI/TUI toolkit different from libyui that allows us to write some async code. We are not limited to Rust for this part.
Resources
Runtimes
Review
You can find the outcome of this project in the y3network repository.
Looking for hackers with the skills:
This project is part of:
Hack Week 20
Activity
Comments
-
almost 4 years ago by bmwiedemann | Reply
On the topic of WASM and shared code: https://webperl.zero-g.net/
-
-
over 3 years ago by ancorgs | Reply
I have focused my experiments in two areas:
1) Developing a really interactive GUI with Ruby (intentionally avoiding libyui).
In that regard, I found the Observer and data-binding implementations of Glimmer to be really convenient and straightforward to use. See my experiments at ancorgs/y3network-ruby-ui.
2) Interfacing WASM with Ruby and/or Python (no browser involved)
The results in this area were discouraging. In theory WASM should be able to communicate back and forward with Javascript when running in a browser and with any "host" language (let's call it that way) when running out of the browser, inside a "native" WASM runtime. But that communication is limited to passing integers and floats. Anything more advanced (like a string or any structured data) needs extra mechanisms on top that are understood by both the code running in WASM (Rust in our case) and its caller (Ruby/Python/Javascript).
For the browser, we used
wasm-bindgento interface the WASM code written in Rust with Javascript. That works pretty well, but is useless (even counterproductive) to connect the resulting WASM to any other "host" language. See below.In Ruby I tried to use both Wasmer and Wasmtime as runtimes. But
wasmer-rubyis in the middle of a major rewrite and is basically unusable with recent versions of Wasmer and/or Ruby. On the other hand,wasmtime-rubyis very basic, lacking basically all features that would be useful for a good integration.Integration of Python with both Wasmer and Wastime is much better and more mature. But still the current limits of WASM regarding interfacing with the outer world are a huge limiting factor. These are the three solutions I explored:
2.1) Using WASM Interface Types, which is expected to become the standard multi-language mechanism to do what we wanted. But it's currently far from being a real option. In the Rust=>WASM side,
wasm-bindgencould be used to generate the corresponding specification... but it only worked with an old version. Even that was useless because we couldn't use the Interface Types from the Python or Ruby side. Wasmer has never supported it. Wasmtime supported it for some time but now they dropped the support.2.2) Reusing what
wasm-bingengenerated for the communication with Javascript by writing some connectors in Python that are equivalent to the Javascript ones auto-generated by wasm-bingen. It's not trivial and there is absolutely no guarantee it will keep working.wasm-bingenis a pure Rust<-WASM->Javascript solution with no interest in making it easy (or even possible) to reuse their mechanisms for/from other languages.2.3) Handcrafting a mechanism to pass a string in which we could even serialize more complex data. That would be similar to this example that uses C++ in the WASM side and Javascript outside. Valid as a proof of concept, but definitely not a real solution in the mid-term.
-
Similar Projects
WebUI for your data by avicenzi
A single place to view every bit of data you have.
Problem
You have too much data and you are a data hoarder.
- Family photos and videos.
- Lots of eBooks, TV Shows, Movies, and else.
- Boxes full of papers (taxes, invoices, IDs, certificates, exams, and else).
- Bank account statements (multiple currencies, countries, and people).
Maybe you have some data on S3, some on your NAS, and some on your local PC.
- How do you get it all together?
- How do you link a bank transaction to a product invoice?
- How to tag any object type and create a collection out of it (mix videos, photos, PDFs, transactions)?
- How to store this? file/folder structure does not work, everything is linked together
Project Description
The idea is a place where you can throw all your data, photos, videos, documents, binaries, and else.
Create photo albums, document collections, add tags across multiple file-formats, link content, and else.
The UI should be easy to use, where the data is not important for now (could be all S3 or local drive).
Similar proposals
The closest I found so far is https://perkeep.org/, but this is not what I'm looking for.
Goal for this Hackweek
Create a web UI, in Svelte ideally, perhaps React.
It should be able to show photos and videos at least.
Resources
None so far, this is just an idea.
Remote control for Adam Audio active monitor speakers by dmach
Description
I own a pair of Adam Audio A7V active studio monitor speakers. They have ethernet connectors that allow changing their settings remotely using the A Control software. From Windows :-( I couldn't find any open source alternative for Linux besides AES70.js library.
Goals
- Create a command-line tool for controlling the speakers.
- Python is the language of choice.
- Implement only a simple tool with the desired functionality rather than a full coverage of AES70 standard.
TODO
- ✅ discover the device
- ❌ get device manufacturer and model
- ✅ get serial number
- ✅ get description
- ✅ set description
- ✅ set mute
- ✅ set sleep
- ✅ set input (XRL (balanced), RCA (unbalanced))
- ✅ set room adaptation
- bass (1, 0, -1, -2)
- desk (0, -1, -2)
- presence (1, 0, -1)
- treble (1, 0, -1)
- ✅ set voicing (Pure, UNR, Ext)
- ❌ the Ext voicing enables the following extended functionality:
- gain
- equalizer bands
- on/off
- type
- freq
- q
- gain
- ❌ udev rules to sleep/wakeup the speakers together with the sound card
Resources
- https://www.adam-audio.com/en/a-series/a7v/
- https://www.adam-audio.com/en/technology/a-control-remote-software/
- https://github.com/DeutscheSoft/AES70.js
- https://www.aes.org/publications/standards/search.cfm?docID=101 - paid
- https://www.aes.org/standards/webinars/AESStandardsWebinarSC0212L20220531.pdf
- https://ocaalliance.github.io/downloads/AES143%20Network%20track%20NA10%20-%20AES70%20Controller.pdf
Result
- The code is available on GitHub: https://github.com/dmach/pacontrol
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
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
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
Hack on isotest-ng - a rust port of isotovideo (os-autoinst aka testrunner of openQA) by szarate
Description
Some time ago, I managed to convince ByteOtter to hack something that resembles isotovideo but in Rust, not because I believe that Perl is dead, but more because there are certain limitations in the perl code (how it was written), and its always hard to add new functionalities when they are about implementing a new backend, or fixing bugs (Along with people complaining that Perl is dead, and that they don't like it)
In reality, I wanted to see if this could be done, and ByteOtter proved that it could be, while doing an amazing job at hacking a vnc console, and helping me understand better what RuPerl needs to work.
I plan to keep working on this for the next few years, and while I don't aim for feature completion or replacing isotovideo tih isotest-ng (name in progress), I do plan to be able to use it on a daily basis, using specialized tooling with interfaces, instead of reimplementing everything in the backend
Todo
- Add
maketargets for testability, e.g "spawn qemu and type" - Add image search matching algorithm
- Add a Null test distribution provider
- Add a Perl Test Distribution Provider
- Fix unittests https://github.com/os-autoinst/isotest-ng/issues/5
- Research OpenTofu how to add new hypervisors/baremetal to OpenTofu
- Add an interface to openQA cli
Goals
- Implement at least one of the above, prepare proposals for GSoC
- Boot a system via it's BMC
Resources
See https://github.com/os-autoinst/isotest-ng
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