Using docker as a development platform for nontrivial development environments sounds interesting.
This project is about learning basic docker handling, about exploring how to use it for simplifying development, and maybe (but just maybe) about providing ready-made docker containers for new team members.
DAPS, the "DocBook Authoring and Publishing Suite" provides a tool set for easy creation and publication of DocBook sources on Linux. DAPS lets you create HTML (incl. webhelp), PDF, EPUB, man pages, and other formats with a single command. DAPS is used and developed by the SUSE documentation team and hosted on https://opensuse.github.io/daps/ .
Currently DAPS supports building documentation from DocBook 4 and 5 sources. The goal of this project is to add support for ASCIIDOC to DAPS. This will allow to easily create all output formats mentioned above with the official SUSE brand from ASCIIDOC without having to take care about templates and other stuff.
Few months ago I switched my home workstation and media center to Micro OS desktop and I cannot imagine switching back to normal distribution.
After some consideration I realized it should work fine (even better) on the notebook I am using for work.
In order to aid loading openSUSE installation and Live images on USB sticks we have a little GUI program called imagewriter. It's a bit dated so Fabian started a newer one with better UI suitable for touch screen that offers the available images on demand, store images offline for conferences and fairs etc: https://github.com/openSUSE/imagewriter2
It's written in C++ with Qt and still needs some work to be production ready:
6 hacker ♥️.
Has no hacker:
Currently, when Rancher tries to provision a Kubernetes cluster on vSphere, it needs to initiate API calls to the vSphere endpoint. In a hybrid cloud environment this often means that the Rancher server is not in the same network as the vSphere endpoint. Therefore inbound access is required to be added to a firewall so Rancher can reach the vSphere system. This naturally poses a security concern and creates administrative burden on our users who have to go through a security review to get this approved.
If instead of requiring direct API access, an agent could exist inside the network where the vSphere API lived, then this agent could broker the communication between the Rancher server and the downstream API. The agent would simply initiate an outbound API connection to the Rancher server (much like any node agent or cluster agent currently) and simultaneously proxy any API calls that Rancher needs to make to vSphere. This would also have the benefit of being able to be run through a HTTP proxy, which many security teams will appreciate as a less risky connectivity model.