1. 1

    As someone that used to build emacs a lot I loved this! Can’t help but think that the M1 Mac running Linux would be faster still (unless I’ve missed some benchmark that show apfs performance has improved)

    1. 2

      Sad news indeed. I met David years ago when I but a pup (he would come to meetings of a Toronto UNIX user group). He left me with an enduring interest in portability, build systems and is the reason I talk about “software hygiene” amongst my peers.

        1. 11

          On Plan 9, these things are just mapped into the filesystem, so rather than calling socket you just open a ‘file’. FreeBSD had a pseudo FS that did the same thing but it was never moved to fine-grained locking and was eventually removed.

          Putting it in the shell seems odd though. You now have some magic files that work when you open them in the shell but don’t work when you pass these paths to other commands. This seems to do less than nc, so I don’t really see why I’d use it in preference to nc.

          1. 6

            The feature first appeared (I think) in Korn Shell in around 1989. And yeah, was always weird, probably a mis-feature.

          1. 5

            Some additional definitions to help younger readers:

            • “put back” is like “git push”
            • “bringover” is like “git pull”
            • “gate” == the canonical source repository, that from which the product is actually built
            • “on495” refers a specific release, decoder ring: “on” is short of OS/Net which is the Solaris kernel, commands and libraries, 495 is the month year targeted for delivery. Obv. these were internal names
            1. 2

              Oh, didn’t realise the “on” numbering convention was the the date. Thanks :)

            1. 1

              I think there is a buried over-simplification of the term efficient. From the perspective of a bare metal coder, the entire tech-stack of the modern SaaS world is itself massively inefficient. Big-O efficiency might be lost in the noise.

              Of course, if you accept my premise, then O(n^2) in a massively inefficient environment might be a multiplier on the moral wrong. 🤷

              1. 3

                Somebody might correct me but my recollection is that Linus was not using any SCM prior to his adopting of BitKeeper. The story at the time was that Linus simply maintained the canonical kernel tree himself, accepting patches from “lieutenants”. Us lowly users of kernel source would simply download a .tar.gz of the whole thing.

                1. 3

                  So does anybody have favourite formatters for C/C++? I’ve been trying clang-format but it, for various reasons, is imperfect. Those reasons are, briefly:

                  • version skew across the dev team (not everybody has the latest installed and older versions simply choke on new things in the config file)
                  • formatting “surprises” (unless you’re willing to accept giant corp’s style, have fun making a config file that does what you want across all the weird things your team will throw at it)

                  My ideal tool would accept a giant hypothetical C/C++ file(s) as “correct” then learn and generate a config file from it. Yes, I realize I’m asking for a unicorn.

                  1. 1

                    I once had to do some unnatural things with ELF files. I would have used libelf like everybody before me but I needed my program to work on Windows and Linux. I stumbled upon http://elfio.sourceforge.net

                    What a joy to work with.

                    1. 23

                      Lol. I’ve spent weeks hunting bugs where the fix ended up literally being a single bit change. To be clear, that’s not intended to be a flex but rather an underlining of the original author’s point that a line of code is not really a metric of anything at all.

                      1. 26

                        I came to say something similar. I recently found a bug in the Linux kernel in an obscure code path that no one except us and paravirtualised MIPS use (which, realistically, means no one except us). Debugging took several days. The fix was changing a 0 to a 1. Even in ASCII in the source code, this was a change of 0x30 to 0x31, so a one-bit fix in both the source and the compiled binary.

                        There’s the old (and possibly apocryphal) story of an engineer coming to service something, tapping the machine with a hammer, fixing it and charging $5,000. The customer objected and demanded an itemised bill. They got this:

                        • Hitting the machine with a hammer: $1
                        • Knowing where to hit it: $4,999

                        Fixing a bug is often trivial. Figuring out the correct fix and where to put it is the hard bit. My favourite bug fixes are the ones that involve just deleting code.

                        1. 4

                          There’s the old (and possibly apocryphal) story of an engineer coming to service something

                          Here you are

                          1. 1

                            This is one of those cases where the 1 byte change should be accompanied by a multi-paragraph explanation ;-)

                          2. 7

                            It’s not one line of code, it’s which line of code in the millions of them.

                          1. 6

                            This is nice.

                            Being old skool, I would routinely start my bash scripts with a usage() function (containing a bunch of echo statements amounting to the same thing) that would be called by any failure in the getopts processing but this a simple alternative that is useful both for the user and for a casual reader of the script.

                            1. 2

                              Yeah, this is a really clever way to make your code more readable and make it easier to get help.

                            1. 3

                              Refusing to learn with elaborate and sometimes not so elaborate rationalizations is hardly unique to the practice of programming. Musicians refusing to learn about music theory is just one easy example.

                              1. 2

                                Oh, please let this project be successful. The worst thing about writing a man page is the troff syntax that mandoc uses. On *BSD, there’s now a custom renderer for only the mandoc syntax, rather than a full troff implementation (such as groff), which is a lot smaller and faster. That helps with the rendering path, but not the authoring bit.

                                To give a concrete example, this is a man page that I’ve written, without any rendering. It is not human readable, for any reasonable definition of ‘human’. I would love to have something that would either render Markdown pages natively in man, or would translate Markdown to mdoc so humans never have to write mdoc again.

                                1. 2

                                  See ddevault’s scdoc.

                                  1. 1

                                    Amen. When I was a younger man, I thought troff was cool because I could make cool looking documentation while retaining some interesting (to me) properties:

                                    1. still using a programmer like work flow
                                    2. my documentation source files were a ton smaller than any of the binary formats offered by MS Word et al (important because disk space was limited and expensive) and
                                    3. it was diff-able.

                                    Much time passed…

                                    1. retains some residual appeal – but nobody cares
                                    2. disk space? nobody care
                                    3. a useful property but if you have tried merging conflicting man page edits in *roff you are painfully aware of the additional friction created by *roff itself

                                    markdown, IMHO, is a legit contender to replace *roff in the context of man pages (which I still refer to all the time)

                                    So yes. Chapeau. I hope to see more of this kind of work.