1. 1

    Depending on your comfort level with admin stuff (and laziness ;) you can always host it yourself (https://www.c0ffee.net/blog/mail-server-guide - seems to be a good guide). Multiple virtual domains and many mail boxes for about $5-$10 month on a VPS.

    Edit: But I tend to use sendgrid for transactional emails.

    1. 4

      The nice thing about make (vs some to other arguably better tool that needs to be installed) is that it comes installed just about everywhere.

      I’ve been using Makefiles for my Go projects. They are simple, just wrapping gb as well as some build dependencies (ie golang and gb). so I don’t need to worry too much about portability and since make comes installed my projects are eas(y:ier) to bootstrap.

      I’ll have to checkout some of the options mentioned here, especially ninja and cmake… But typing make is very hardwired into my muscle memory ;)

      1. 1

        installed just about everywhere

        Except for the OS used by almost 50% of developers.

        1. 1

          Sure, but it doesn’t have visual studio installed by default either. I would prefer something like cmake however that can create either a make file or visual studio project (And more)

      1. 7

        I ran BeOS as my primary os in the late 90’s for about 15 months (on a low end mac clone!), but had to drop it as a daily driver because of the lack of Java tooling (which is what I was doing at the time).

        That and I only had access to the built in C compiler that was limited to the size of executable it would produce left me little opportunity for software development. I do remember porting the plan9 rc shell using it as well as the galaxies X11 screenblanker.

        I played with the x86 release for a bitI checkout Haiku every one in while (along with Aros and ReactOS) but was back to running Linux as my primary by then.

        1. 2

          That’s neat you got to use it. I heard the compile times were slow possibly due to microkernel-style but maybe speculation. Another person said the filesystem was too clever. Did you have problems with these? And just how awesome (or not) was the responsiveness under load? They claimed it was great with gradual degradation as it got overloaded with it maybe going back to normal afterward. I still don’t have that on this backup laptop for Linux haha. Browsers especially can cause slowdowns at a distance.

          1. 2

            I didn’t notice slow compiles, but it was only a 140Mhz 603 ;) The file system was cool but I never really took advantage of it.

            The Internet was also much different from today (HTML 3.2 was still a thing) so the browser was not the resource pig it seems to have become (300-400 MB per TAB?!?!).

            And lastly I never manage to tax any of my systems all that much.

            1. 2

              Appreciate the detailed reply. Esp frequency as I was curious what they ran. When secure hardware gets bootstrapped, it will be on the same nodes as original Pentium or maybe P2. So, I try to track what people could do with the older chips in case it becomes handy for a minimalist, secure workstation later. On top of it just being fun to learn about stuff.

        1. 4

          Is this just a mirror or are OpenBSD taking contributions via pull request?

          1. [Comment removed by author]

            1. 5

              Are there specific reasons for this? ruby/ruby allows posting pull requests as long as there’s a tracking issue on the bug tracker for larger things and takes the time and effort to point people to it if necessary. It’s not much, that can be solved by having a block of standard text or even just putting it in the pull request template github provides.

              1. 11

                OpenBSD just doesn’t do github pull requests. That’s not how we work. The project mostly only relies on its own infrastructure; github is not part of that.

                Another reason why pull request won’t be looked at is that you need a browser to use them. When doing reboots all the time during kernel development starting a browser, or even having a browser installed during a libc ABI bump is just a hassle.

                1. 4

                  You can easily extract the patch by appending .patch: https://patch-diff.githubusercontent.com/raw/skade/lazers/pull/15.patch . You can respond to PR notifications through email, even send them to your mailing list if you are so inclined.

                  Assuming you have some way to do HTTP (which I assume if you have some way to read email), you can extract the patch there.

                  My point was more: why put a sign up that says “if you land here, we will ignore you, because you are not us”, when you could put up a sing “hey, hello, you are welcome, but for many reasons this is not the way we work, but we will happily teach you (and maybe accept small fixes with a grumble)”.

                  Ruby has also not switched over to Github for many good reasons (one of them being a lot of specialised tooling built around their infrastructure), but they appreciate that this is an angle of approach to the project and will help people coming from there.

                  Don’t get me wrong, I do understand and support the reasons for doing your own flow. But why actively working against fresh people that know another flow?

                  1. 4

                    It’s a little ironic that the solution to “github is unfamiliar” is “hack the URL to add a secret extension”.

                    1. 3

                      The URL is not obscure nor secret, it’s in the email notification you get for a pull request, right next to the link to the diff.

                      1. 1

                        Ok, that’s fair, but it’s not obvious how one would discover that without already switching to GitHub.

                  2. 2

                    It’s not quite true that you need the web to use them (though commenting on them probably does - which is a big part of reviewing):

                    https://gist.github.com/piscisaureus/3342247

                    But kudos on using your own infrastructure (I’m on a bit of an anti-SaaS kick right now)

                    1. 2

                      There is also the GitHub CLI for those that prefer doing most work outside a browser.

                      I’m on a bit of an anti-SaaS kick right now

                      Ditto. I do wish Gitlab was a bit easier to manage - I’d love to install it but the number of dependencies along with the frequent security updates make me a bit leery. Gogs looks good but I need to investigate further.

                  3. 5

                    Pull requests don’t encourage the same kind of code review as email-based workflows:

                    https://lobste.rs/s/rkux7i/why_kernel_development_still_uses_email/comments/vodxjs#c_vodxjs

                    1. 2

                      I’m not saying you should move discussions over, but you can still extract the patch and move the people over to your infrastructure. Would you prefer to leave potential commiters there?

                      1. 5

                        The quality of the patch itself is also affected by the medium. People just don’t write “patches” when they use PRs. They write a big pile of commits where whitespace changes are mixed with bugfixes are mixed with new features, all at once, with fuzzy boundaries across commits. There’s also the whole rewriting of the commit/patch stack that seldom happens with a PR, because that involves “scary” push-forces that partially lose the history of the code review, whereas with email it’s just a resend.

                        I don’t know about OpenBSD, but for the projects in which I have seen, yes, I much prefer the quality of the patches sent to email than what I’ve seen in PR. I am grouchy and would not miss leaving behind PR-based commits, because their quality tends to be lower.

                        1. 3

                          I don’t know about OpenBSD, but for the projects in which I have seen, yes, I much prefer the quality of the patches sent to email than what I’ve seen in PR. I am grouchy and would not miss leaving behind PR-based commits, because their quality tends to be lower.

                          Would you feel comfortable leaving behind the potential committer that could learn your way of writing patches?

                          1. 3

                            Some might argue that any potential committer should be keen enough to learn the way a project works. But I can see the value in your approach (and it’s one I’d favour personally - help people to swim rather than throwing them in the deep end, where only the strong survive). Wow, what a selection of mixed metaphors there!

                            1. 2

                              Some might argue that any potential committer should be keen enough to learn the way a project works.

                              Sure, I wouldn’t work with people that absolutely refuse the projects flow. But any approach should me met with the benefit of doubt and is an opportunity to start a conversation, ask people to clean up their patch etc.

                              E.g. when I first submitted to freedesktop, I had to set up git send-mail. It’s horrible. It was hard to find out I even had to do this and then which the exact mailing list to send it to was, as the one I though was correct was slighly abandoned and full of spam. Took me around 5 hours for a tiny patch.

                              The review experience with the freedesktop people was stellar, then. But the patch nearly got lost on the approach, and I have been doing things like that for nearly a decade.

                              On the other hand, people complain about lack of committers.

                              1. 10

                                5h for a first patch submission is really not that much. Excepting to spend as little time as possible on submitting a patch makes it sound like the submitted contribution is a “fire and forget” one. Those can of course be nice, but no project can survive on them. Which is why contributors who avoid learning the tooling used by a project are really not that interesting.

                                In OpenBSD’s case, consider that all developers are already volunteering a significant chunk of their time following the mailing lists and reviewing patches by fellow developers and new contributors. When your goal is security, every change can be dangerous. So code review applies to everyone, and the project relies on everyone to be involved in the canonical code review process to keep the code base stable and secure. .Email is where the real action is in this project. If a non-trivial change made it into the central repository but was not shown on a mailing list, or at least to other developers involved in the area, this would be regarded as a major problem..

                                With a well established (since 1995) process like that, moving the attention span of even just a few developers to a different platform than email can be a huge distraction. Yes, it serves outsiders who don’t feel like learning the tooling. But suddenly everyone has to watch two spaces for upcoming changes to review, because it’s not all in the one usual place, and who knows what kind of breaking changes the other subgroup over on github is up to.

                                Your best bet for contributing by pull requests it to ask an existing developer to accept pull requests from you and then channel them to the mailing list on your behalf. But why would any existing developer want to do that?

                                1. 6

                                  I am inclined to agree when submitting a patch requires jumping through extra hoops. In this case, we’re asking people to do less work, not more. All one need do is send the output of git diff to the list. I’m pretty sure that’s actually less work than creating a pull request.

                                  1. 2

                                    Email? What is that? Some obsolete version of slack?

                                    I agree with everything that has been said here by OpenBSD developers. The proportion of quality patches received over email is light years ahead of the proportion of good GitHub pull requests. And this doesn’t even address the fact that GitHub pull requests force you to use a particular kind of workflow, while email allows actual developers (the people who do 99% of the work) to use what workflow they prefer. Sure, they don’t allow the casual contributor to chose arbitrary workflows, but that is a feature (not a bug) of the release engineering process.

                                    The process is stable and works very well.

                  4. 2

                    I believe it’s just a mirror and I doubt contributions are being taken via pull request (although @jcs can confirm).

                    BTW, the mirror has been there for quite a while if I’m not mistaken…

                    1. 4

                      It’s hitting news because of the official link on the openbsd.org website. See the commit.

                      1. 5

                        Or maybe this one ;)

                        1. 5

                          I prefer this one ;)

                          1. 1

                            Yes! That’s the good one! :D

                  1. 3

                    I like lab notebooks because they fold open flat. Unfortunately the one I use is 11.75" x 9.5". Lab notebooks are designed for researchers who need to staple pages into it, so it’s certainly too large for you, but maybe it’s a useful keyword for your searches.

                    1. 2

                      Thank you, if I can find a smaller version of this it may be what I need, since I am left-handed and notebooks that don’t fold flat can be annoying.

                      1. 2

                        http://www.bookfactory.com/ has smaller sizes

                        1. 2

                          Thanks! That’s exactly what I was looking for :)

                      1. 2

                        I am working on the documentation for my personal finance analytics and reporting toolkit (for banks and credit unions primarily) http://cashbooktoolkit.com/