I have two pi’s with hdd’s attached, one in my house runs a few extra services like nextcloud, minidlna and some odd and ends. Then I have syncthing syncing files from local computers to my local pi, and the local one to remote which is in another city.

    I used to run additional machines at home, when I had a stable connection and a static IP but am now rural so websites/git and some bits (like the reverse ssh so I can login to the remote pi) run on an OpenBSD vps with Vultr.

    I’ve been meaning to migrate email to the OpenBSD vps for ages. Seeing so many people doing just that means it is now my weekend project. Does anyone run a seconday mx?


      When I visited Munich and hopped on th S-bahn Dachau was just a stop. Perhaps my hyperbole is was too much.

      Naming after a prison notorious for holding political prisoners seems like a poor naming decision.


        Oh awesome, this is quite a bit more readable than the paper. Thanks for sharing!


          Interesting replies from everyone. I am looking forward to selfhost my stuff very soon


            Great, accessible explanation. There was also a similar concept in formal methods.


              What do you think of the QMK firmware? Did you use a ready made solution before this?


                I use a split ergonomic keyboard both at work and at home: https://github.com/omkbd/ErgoDash The repo contains all the files one needs to have the PCB and case plates fabricated (not my work).

                I had the PCBs made at jlc pcb and soldered it all together at home, see: https://images.yourfate.org/#15521316686517 It runs QMK firmware: https://qmk.fm/

                While it has more keys than a 40% I still use a lot of layered keys. My favorite layer feature is having a “numpad” on the righ thalf of the board, with 456 being on jkl when I press a mod key on the other half. Makes entering many numbers very fast.

                AMA I guess…


                  The only correct language for the Red Planet is Rust.


                    In particular, there is, right this moment, working CPU rolling over Martian terrain in the form of RAD750 (PowerPC ISA) inside Curiosity rover. It has worked on Mars for more than 7 years since 2012.


                      I don’t think windows devs use cygwin. I think that non-windows devs use cygwin (or mingw or one of the ten other unix-toolchain-for-windows environments) so that they don’t need to go through the hoops to become windows devs.

                      In other words, I’m not really sure who the audience is for OP’s argument re: building on windows.

                      If you’re building on windows & you are a windows dev, why care about make at all? If you’re building on windows & you are not a windows dev, why care about the first group at all? In my (dated & limited) experience these two ecosystems hardly interact & the tooling to make such interaction easier is mostly done by unix-first developers who want to check windows builds off the list with a minimum of effort.


                        “ Second, some organizations unfortunately are unwilling to use software licensed under any variant of the GPL. Since we want to provide a clear license and to promote the use of Racket everywhere, a new, more-permissive license is the right choice for Racket.”

                        In my opinion, this is the heart of why GPL is valuable. While I can’t fault racket for buckling under pressure, especially considering some of the other aspects of licensing challenges, if businesses shouldn’t use GPL I think it stands to reason that individuals shouldn’t use MIT. After all the business is just seeking their own interest, keeping code they run on your machine secret, and we should seek to know what code is run on our machines, as is the original intent of the GPL. The fact that they fear it is good enough sign that it works, and that we should use it as much as reasonably possible.


                          I should rephrase:

                          Who builds cross-platform applications not originally developed on windows outside of an environment like cygwin?

                          Windows developers don’t, as a rule, care about the portability concerns that windows-first development creates, & happily use tools that make windows development easier even when it makes portability harder. And cross-platform frameworks tend to do at least some work targeting these developers.

                          But, although no doubt one could, I don’t think (say) GIMP and Audacity builds are done through VS. For something intended to be built with autotools+make, it’s a lot easier to cross-compile with winecc or build on windows with cygwin than to bring up an IDE with its own distinct build system – you can even integrate it with your normal build automation.


                            I believe that’s your experience, but you and I have radically different experiences as Windows users.

                            First, to be very blunt: Cygwin is truly awful. It needs to die. Cygwin is not a port of *nix tools to Windows; that’s MSYS. Cygwin is a really weird hacky port of a *nix to Windows. It’s basically WSL 0.0. It does not play well with native Windows tooling. It honestly doesn’t play well with Windows in general. And it’s comically slow, even compared to vaguely similar solutions such as WSL1. If I see a project that claims Windows support, and see Cygwin involved, I don’t even bother. And while I don’t know if a majority of devs feel similarly, a substantial enough group of Windows devs agree that I know my opinion’s not rare, either.

                            You’re right that Visual Studio is the go-to IDE on Windows, in the same way that Xcode is on Mac. But just as Mac users don’t necessarily bust out Xcode for everything, Windows devs don’t necessarily bust out Visual Studio. Using nmake from the command line is old as dirt and still common (it’s how we build Factor on Windows, for instance), and I’ve seen mingw-based Windows projects that happily use cross-platform gnumake Makefiles. CMake is also common, and has the benefit that you can generate Visual Studio projects/solution when you want, and drive everything easily from the command line when you want. These and similar tools designed to be used without Visual Studio are heavily used enough and common enough that Microsoft continues to release the command-line-only Windows SDK for the most recent Windows 10–and they do that because plenty of devs really do only want that, not all of Visual Studio.

                            For reasons you point out elsewhere, there’s a lot that goes into supporting Windows beyond the Makefile, to the point that concerns about cross-platform make may be moot, but “Windows devs will use Cygwin” seems reductionist.


                              I keep telling you! Like the Phoenix, FORTH will rise from the ashes, and take us into the skies!


                                  This seems like a non-issue – who builds on Windows outside of an environment like cygwin?

                                  Most Windows developers and cross-platform frameworks that I can tell.


                                    I don’t know why the author is writing in hypotheticals, rad-hard ICs have been in production for decades now. A quick search yields an ARM core that offers reasonable performance for a thousand bucks.


                                      Yeah, but you can solve that with a make file. ;)


                                        I am compelled to mention Henry Baker’s article on linear logic in Forth, and this earlier one about Linear Lisp. Amusingly, I found these articles a few years ago, thought “shouldn’t these ideas be more mainstream?”, and then discovered Rust.

                                        Chicken Scheme fans may also recognise Henry’s work on garbage collection.


                                          You have to remember to mount an overlay if the build system doesn’t support it automatically. In case you forget just once, then it’s probably rm -rf && git clone again,

                                          Probably just git clean -xfd. You can execute it as the first dependency for all targets. Also, I propose to autoload it in Makefiles, which can remove all such problems.

                                          Your OS has to support such overlays (does Windows support it?),

                                          Windows filesystem proxy.

                                          You have to have a very complete .gitignore file that lists all autogenerated file groups, so that git status output will be clean,

                                          What I am suggesting is a build directory that has the checked out tree as the lower directory, and actual build directory as the upper directory. So one can simply do git status on the tree directly.

                                          You have to actually learn how to use overlayfs,

                                          It is much more simpler than learning to use cmake. Also, it might be possible to make it automatic – see first point.

                                          You can only have 1 configuration of the project active at the same time. I.e. switching Debug/Release/ReleaseWithLogs builds require recompilation of the whole project (at least for some languages like C++).

                                          Not really. You can have multiple overlays for different phases of compilation.