336 karma · joined March 13, 2010
I used to work at dotCloud (which pivoted to Docker in 2013), before working at Uber until May 2018.
[1] https://www.sfcommunityhousingact.com/press/landmark-housing...
What do you mean by underpowered buildbot steps? Are you implementing your own step classes?
[1] https://docs.buildbot.net/current/manual/configuration/worke...
Right now I just run the whole thing out of a Mercurial repo (it's easy to use the MoinMoin codebase as a sub-repo [1]), but I'm planning to do a setup with a container so that the data can directly live in any (Dropbox) folder or repo.
[1] https://moinmo.in/HowTo/Run%20Moin%20from%20a%20Mercurial%20...
I didn't know about Suse's OBS until this thread, I guess I need to look into it. I have been building my own CI/CD pipeline on top of Buildbot so far. It's a PITA, but leaves a lot of room for creativity, hopefully it will be rewarding down the road.
I don't know about the -git thing for PKGBUILD, what's the syntax/documentation?
I'm working on a project (licensed under the GPLv3) and I have decided to be my own maintainer, i.e: building and distributing packaged versions of my project all by myself:
1. my project is young and unknown, I have no choice but to package it myself (I really like AUR by the way);
2. it lets me write and maintain step-by-step documentation;
3. it allows me to enforce a consistent interface for my project across operating systems, I know my project can be used the exact same way on any operating system I have packaged it for;
4. I have had bad experiences with maintainers having no idea what they are doing and completely breaking my software;
5. It allows me to build a full release pipeline including both source and binary releases.
The first point is sort of a big deal, having packages is important to drive adoption, therefore I need to invest my time in that. I'm not gonna wait for some random folks to package it a few years down the road (if that ever happens).
My work is not incompatible with downstream packaging, but I do intend to work closely with (or directly maintain) any downstream package.
I really feel like this is sort of a catch-22.
Yes, in the end images are an entire filesystem and can be large if you installed a lot of packages (or very small, e.g: busybox). Yes, you can freeze it: you can commit a container as a new image. Yes, you can push it to a server (https://index.docker.io/). Yes, you can use the same image for development, staging and production; you'll launch different container from the same image that's it.
For that, I find the hierarchy macros of Latex much simpler to apprehend as well as lot of goodies: footnotes, references, hyperref, mathematic mode, bibliography management…
Also, and it's blocker for lot of my use cases, Latex is version control friendly. The WYSIWYG editors are not.
Changing fonts may become a PITA and I recommend to use the koma-script classes for that (btw, the whole system of packages and the build system are a mess), but at least people can't use Comic Sans.
Pick your favorite distro, just install a tiny window manager, avoid running background applications and that's it.
If you don't have a favorite distro, then all depends on your Linux skill and/or the time you have. Good distros have already been given in this thread.
http://caca.zoy.org/wiki/libcaca
One of my favorite application of the libcaca is neercs: