Project Description
A lot of people are using mechanical keyboard. Having a custom SUSE-branded keycap would be cool. The idea is to create a set of 3D models for such keycaps in various profiles for everyone to print.
Goal for this Hackweek
- List the required profiles
- Create STL files for each of them
- 3D print and test if possible
Resources
- 3D printer, I don't have one
Looking for hackers with the skills:
This project is part of:
Hack Week 21
Activity
Comments
-
-
over 3 years ago by bmwiedemann | Reply
For the instructions for the previous mini batch of black-chameleon-on-green keycaps see https://mailman.suse.de/mlarch/SuSE/maxtorhof/2018/maxtorhof.2018.02/msg00022.html
-
over 3 years ago by bmwiedemann | Reply
Would also be cool if we could get the Geeko as a standard keycap into https://www.wasdkeyboards.com/products/keycaps.html?p=2 next to Arch, Debian and Mint
-
over 3 years ago by rainerkoenig | Reply
The question is: 3D print the keycap or do it in a more professional way? In my previous job I worked at Fujitsu and when we were producing keyboards they were taking raw keyboads and then engraving them with a laser. You can see lots of videos on keyboard laser engraving on YouTube. Maybe there are services around that do custom keyboards with laser engraving.
On the other hand there are laser cutters for 3D printers on the market, so you could also try to engrave them at home with a 3D printer plus laser unit. I have no idea how precise this is.
3D printing could be possible as well, but don't expect very high quality (shiny surface) from a 3D printed keycap, at least with PLA. Maybe ABS and then finishing it wir Aceton works better. But keep in mind the usually the nozzle of a 3D printer has a diameter of 0.4 mm, so the question is how good the logo will come out with this limitations.
-
over 3 years ago by rainerkoenig | Reply
There are STLs for Cherry Keycaps on Thingiverse. I just setup my 3D printer to try out...
-
over 3 years ago by rainerkoenig | Reply
Half an hour later:
Printed with 0.1mm resolution. The side surfaces are great, the top is a bit rough because its round and not flat.
-
over 3 years ago by rainerkoenig | Reply
Took the SVG scaled and extruded it in openSCAD. Then export to STL. Then then merging this with the STL of the key cap in FreeCAD. STL-Export again. Result: FDM printer is at its limits when using a 0.4 mm nozzle). Maybe better results with resin printers that have a higher resolution.
-
over 3 years ago by cbosdonnat | Reply
Could it help using some filler and sanding to get a better surface before drawing on it?
-
-
-
over 3 years ago by MattK | Reply
I have a modified CR-10 and have tried to make keycaps before with varying levels of success. I've also tried printing molds in TPU and then using them to make resin keycaps. My smallest nozzle right now is 0.4mm though. Maybe this is my excuse to finally buy a resin printer.
-
over 3 years ago by cbosdonnat | Reply
Not really 3D printable models, but still instructions to build brandable keycaps: https://www.instructables.com/Wooden-Keycaps-Using-Hand-Tools/
-
Reply to rainerkoenig
Half an hour later:
Printed with 0.1mm resolution. The side surfaces are great, the top is a bit rough because its round and not flat.
# 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
Reply to rainerkoenig
Took the SVG scaled and extruded it in openSCAD. Then export to STL. Then then merging this with the STL of the key cap in FreeCAD. STL-Export again. Result: FDM printer is at its limits when using a 0.4 mm nozzle). Maybe better results with resin printers that have a higher resolution.
# 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
Reply to ecandino
Hi all, I would like to join the project! I'm new to 3D printing and such, but I was curious to try and learn.
A friend of mine is also available to borrow me his Prusa Mini (with the 0.25 nozzle) 
# 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
Reply to ecandino
This is the video of the bicolor keycap: https://www.youtube.com/watch?v=HjOd9OIDABY
I've uploaded the STL on Thingiverse: https://www.thingiverse.com/thing:5423109 but it's not visible yet because I am a new user.. :/
# 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
RMT.rs: High-Performance Registration Path for RMT using Rust by gbasso
Description
The SUSE Repository Mirroring Tool (RMT) is a critical component for managing software updates and subscriptions, especially for our Public Cloud Team (PCT). In a cloud environment, hundreds or even thousands of new SUSE instances (VPS/EC2) can be provisioned simultaneously. Each new instance attempts to register against an RMT server, creating a "thundering herd" scenario.
We have observed that the current RMT server, written in Ruby, faces performance issues under this high-concurrency registration load. This can lead to request overhead, slow registration times, and outright registration failures, delaying the readiness of new cloud instances.
This Hackweek project aims to explore a solution by re-implementing the performance-critical registration path in Rust. The goal is to leverage Rust's high performance, memory safety, and first-class concurrency handling to create an alternative registration endpoint that is fast, reliable, and can gracefully manage massive, simultaneous request spikes.
The new Rust module will be integrated into the existing RMT Ruby application, allowing us to directly compare the performance of both implementations.
Goals
The primary objective is to build and benchmark a high-performance Rust-based alternative for the RMT server registration endpoint.
Key goals for the week:
- Analyze & Identify: Dive into the
SUSE/rmtRuby codebase to identify and map out the exact critical path for server registration (e.g., controllers, services, database interactions). - Develop in Rust: Implement a functionally equivalent version of this registration logic in Rust.
- Integrate: Explore and implement a method for Ruby/Rust integration to "hot-wire" the new Rust module into the RMT application. This may involve using FFI, or libraries like
rb-sysormagnus. - Benchmark: Create a benchmarking script (e.g., using
k6,ab, or a custom tool) that simulates the high-concurrency registration load from thousands of clients. - Compare & Present: Conduct a comparative performance analysis (requests per second, latency, success/error rates, CPU/memory usage) between the original Ruby path and the new Rust path. The deliverable will be this data and a summary of the findings.
Resources
- RMT Source Code (Ruby):
https://github.com/SUSE/rmt
- RMT Documentation:
https://documentation.suse.com/sles/15-SP7/html/SLES-all/book-rmt.html
- Tooling & Stacks:
- RMT/Ruby development environment (for running the base RMT)
- Rust development environment (
rustup,cargo)
- Potential Integration Libraries:
- rb-sys:
https://github.com/oxidize-rb/rb-sys - Magnus:
https://github.com/matsadler/magnus
- rb-sys:
- Benchmarking Tools:
k6(https://k6.io/)ab(ApacheBench)