1. 1

    I’m not sure, but isn’t one supposed to use -display sdl instead of -sdl?

    1. 1

      Either works, I don’t think -sdl is going away any time soon.

    1. 1

      It’s not JavaScript that bloats an application, not even using frameworks. Vue is 20kb minified and gzipped, if that is ‘too much’ than you are writing for a very specialized audience. Using js won’t magically make ads, trackers or popups appear on your web page. Having an ad and impression based financing model will.

      1. 6

        Size is just one metric. Ads, trackers, and popups all generally require JavaScript, and if you restrain yourself from using it you will naturally also not be using these things. Not using JavaScript also makes you exercise restraint in your design, letting the browser do what it’s best at (rendering pages) without straining your end-user’s resources.

        1. 3

          sure, if you never touch a knife you won’t commit a knife crime, but encouraging everyone to stop using knifes isn’t a good idea. Implementing ads and trackers without javascript is trivial as well.

          Either way, I agree with you on the point that you shouldn’t use JS when it’s just as easy and nicer for everyone involved when you can skip it. But some web sites really are ‘web apps’, they have interactivity that makes it very inconvenient to not use js.

          1. 2

            Knives have useful purposes outside of knife crime. Javascript does not have many genuinely useful purposes outside of tracking, ads and other such crap.

            Implementing ads and trackers without javascript is trivial as well.

            I would have no problem with ads if they were <img src="/ads/91241.jpg" />. And implementing trackers without Javascript is not at all easy. The best you can do is record the IP address of visitors to your website. You’ve always been able to do that, and it’s nowhere near the same thing as tracking.

            But some web sites really are ‘web apps’, they have interactivity that makes it very inconvenient to not use js.

            I’d rather just use a proper, open source programme running on my computer.

            1. 2

              Javascript does not have many genuinely useful purposes outside of tracking, ads and other such crap.

              Ehh, Javascript has a history too, and while the situation is a lot better nowadays, there were many things that could only be done using javascript. Very popular google services like Gmail or Maps only were that popular because they worked the way people wanted it to (ie. dynamically), and just dismissing this as infantile or ignorant really doesn’t do anything.

              Ads would be done using metadata fingerprinting and backend ad-generation, to still generate personalized data. My feeling is that if it were necessary, this would even be done, despite meaning more work for servers.

              I’d rather just use a proper, open source programme running on my computer.

              Sadly, that’s not the case for most people. On the one hand, most people, if they have to wouldn’t necessary write cross platform software, and on the other hand, “less experienced” users are always weary of installing stuff on their devices. Who knows what it could do? Having a portable, seemingly universal sandbox seems like a great alternative in their eyes.

              The question if this should be the case is a justified, but an entirely different one.

              1. 1

                Use a map program. Use a mail client. The web is for documents.

                I’m not opposed to having a universal secure portable virtual machine. I am opposed to it being the browser, because the browser is a terrible VM, it’s designed for documents. HTML/CSS/JS is a terribly designed and awfully inefficient rendering engine for programmes. It is designed for documents, and HTML/CSS work great for that, but for apps? Yuck.

                The only reason the web is as it is is because things like the JVM were such complete failures at sandboxing programmes correctly.

                1. 1

                  Use a map program. Use a mail client. The web is for documents.

                  Again, people don’t want to install stuff. This isn’t them being stupid it’s just a fact. And if people want to make stuff that will be used, the web is simply the best target. (Sadly)

                  And we web was made for hypertext, but to deny that it’s been extended over time to do more is just wrong. Ever since HTML5 this should have been obvious. Not in a great way, and many weird particularities came into being due to historical contingencies, but it is capable, and it’s being increasingly optimized. What do end users care if the original intention was to serve text.

                  I am opposed to it being the browser, because the browser is a terrible VM, it’s designed for documents.

                  From a technical perspective, sure. I totally agree. The “problem” is that as always there are more perspectives that influence the decisions. Design is arguably more flexible that with standard OS toolkits, prototyping is faster, the developer market is larger, etc. I just wrote a WatchTogether clone a few weeks back, and it took me two days to get something usable, and I’m really not a web developer. I just know that it would have been a lot more work to re-create something similar with a “proper” application.

                  1. 1

                    Yes, people do want to install stuff. They install stuff all the time, and have installed stuff for years. They have no problem installing things. People hate web apps. End users don’t make the decision to move towards software as a disservice, developers do.

                    The web works for hypertext. You can embed content in that hypertext quite well. HTML5 does not change that, it’s still about hypertext.

                    It’s pretty circular to use things like the quality and polish of development tools, or the size of the developer market, in an argument for using some particular technology. Those things just follow wherever the crowd goes. Big super popular technologies get polish.

                    ‘WatchTogether’ is something for synchronising two people consuming web content, right? I’m not surprised that’s easier on the web, because it’s web content. Try synchronising two peoples’ MPV or VLC videos using Javascript instead of e.g. a bash script and a socket.

                    1. 1

                      Yes, people do want to install stuff.

                      I guess there’s not much more to say about this, except that we seem to have different experiences. Convincing my peers to install something has never been easy, while “web apps” are much more readily accepted.

                      HTML5 does not change that, it’s still about hypertext.

                      Maybe officially, but I really can’t look at all the new features behind HTML5, CSS3, newer Javascript versions and say “oh, this is exactly the same as in 1992”. HTTP and HTML might still have the same name, but as a fact are just not used for the same things as they were intended to.

                      It’s pretty circular to use things like the quality and polish of development tools

                      Of course it’s circular, of course it’s wierd and of course I’d also rather not have it that way. All I want to say is that to steer against these developments, once can’t satisfy oneself with making small websites and telling other developers, which probably even already agree with you, about it. There has to be a more definite break, the limitations of the web ecosystem, arise from what people want to use it for, and these aren’t only developers, and the flexibility that HTML ended up offering. As long as “minimalist web developers” just use subsets of HTML and maybe some CSS, they don’t challenge anything. Even if it were miraculously reverted over night, it would still develop back into what was created.

      1. 11

        On a related note, sr.ht looks great!

        1. 7

          Thanks!

        1. 3

          Argh, I want to upvote ‘The Commons Clause will destroy open source’ without upvoting Redis Labs’s action.

          1. 6

            Upvote for the discussion. “Company Makes Business Decision” is rarely on-topic for Lobsters and often goes off the Rails; I’ve upvoted because I appreciate that we’re not rehashing well-worn licensing arguments here, though this announcement was poorly written.

            1. 4

              This is the second time Lobsters has censored my articles by merging them into tangentally related discussions.

              1. 6

                Nobody is censoring you. If anything, your visibility has been boosted by being on front page with another high-visibility thread. I didn’t even know about your article until I saw it here. To avoid clutter, the admins sometimes combine posts talking about same event or topic into a group. I can see someone not liking that decision. I’m not for or against it right now.

                You weren’t censored, though. A mechanism bringing your writing to my attention is opposite of censorship.

                1. 6

                  I don’t think you have this exactly right. What happens is someone submits it as an independent post, which is freely ranked on its own merits. Then a moderator merges it with a post which is already growing stale, as a significant fraction of the site has already looked at it and has little reason to return, except to consider replies to their comments - and even then they have to notice more articles have been added. It also removes a dedicated space for discussing that particular article, which in this case is important because the second article is more about Commons than it is about Redis, making the discussions difficult to live in parallel.

                  The original, independent post was censored by merging it into here. On the previous occasion the new post was merged into a post which was then several days old, where I presume approximately zero people saw it. This is censorship, and a clear cut case of it too. I don’t consider myself entitled to exposure but it’s censorship all the same, and part of the reason I distanced myself from Lobsters except to participate where others have posted my content.

                  1. 1

                    The original, independent post was censored by merging it into here. On the previous occasion the new post was merged into a post which was then several days old, where I presume approximately zero people saw it.

                    If your story disappeared, that scenario would be censorship since it was manipulated in a way that would nearly guarantee nobody would see it. The new one isn’t censorship because censorship is about people not seeing your stuff. The combined submission is 20+ votes on front page of a site with more readers than most blogs. Your views going up instead of down is opposite of censorship at least in general definition and effect it has.

                    1. 3

                      The new one isn’t censorship because censorship is about people not seeing your stuff

                      “Taking measures which prevent others from seeing your stuff” is literally censorship. I don’t want to argue semantics with you any longer. All of the information is on the table in the comments here, let people read them and settle on an opinion themselves.

                      1. 2

                        “Taking measures which prevent others from seeing your stuff” is literally censorship”

                        I saw your stuff through Lobsters’ measures. So, it’s not censorship by your definition.

                        “let people read them and settle on an opinion themselves”

                        By all means.

                      2. 3

                        I really appreciate your point of view normally, but in this case I think you’re incorrect: it would be nice to have the community’s take on @SirCmpwn’s article itself (which is well worth reading) rather than have the comments blended in with those on Redis Labs.

                2. 2

                  Upvoting doesn’t necessarily have to be approval of the content of the post. (though it usually should be)

                1. 1

                  The user has to manually verify the checksum, and figure out how to do it on a phone, no less. A checksum isn’t a signature, by the way - if your government- or workplace- or abusive-spouse-installed certificate authority gets in the way they can replace the APK and its checksum with whatever they want. The app has to update itself, using a similarly insecure mechanism.

                  I don’t think that’s how app updates work on Android??

                  I’m pretty sure it’s TOFU. CAs are not involved. You install an APK from somewhere, Android remembers the key that signed it. You get an APK that updates an app you already have, Android checks if it’s signed by the same key.

                  1. 3

                    Author here. I was referring to the process of downloading the APK from Moxie’s website. He provides an APK download and a SHA over HTTPs. Once you have the APK there’s no signatures involved afaik.

                    1. 5

                      Oh, CA for the initial HTTPS download. Well, if you go to that level of paranoia, the same could be used to modify your initial download of the F-Droid client :)

                      Once you have the APK there’s no signatures involved

                      If the APK was signed, a signature from the same key will be required for an update.

                      You can easily see this when switching between F-Droid and PlayStore||site-download versions of the same app. (The official F-Droid repo signs APKs with the F-Droid key, while the app developer signs with their own key.) Trying to e.g. update a Play Store app from F-Droid will result in an error message.

                      1. 2

                        Thanks for the clarification, much appreciated.

                  1. 11

                    Git via mail can be nice but it’s very hard to get used to. It took me ages to set up git send-email correctly, and my problem in the end was that our local router blocked SMTP connections to non-whitelisted servers. This is just one way it can go wrong. I can inagine there are many more.

                    And just another minor comment: Everyone knows that Git is decentralized (not federated, btw.), the issue is GitHub, ie the service that adds a certain something to version control, like profiles, stars, commit-stats, fork-counts, followers,etc. A one-sided, technical perspective ignores all of these things as useless and unnecessary – falsely. Centralized platforms have a unfair benefit in this perspective, since there’s only one voice, one claim and no way to question it. One has to assume they make sure that the accounts are all real, and not spam-bots, otherwise nothing makes sense.

                    To overcome this issue, is the big task. And Email, which is notoriously bad at any identity validation, might not be the best thing. To be fair, ActivityPub, currently isn’t either, but the though that different services and platforms could interoperate (and some of these might even support a email-interface) seems at the very least interesting to me.

                    1. 12

                      Article author here. As begriffs said, I propose email as the underlying means of federating web forges, as opposed to ActivityPub. The user experience is very similar and users who don’t know how to or don’t want to use git send-email don’t have to.

                      Everyone knows that Git is decentralized (not federated, btw.)

                      The point of this article is to show that git is federated. There are built in commands which federate git using email (a federated system) as the transport.

                      GitHub, ie the service that adds a certain something to version control, like profiles, stars, commit-stats, fork-counts, followers,etc. A one-sided, technical perspective ignores all of these things as useless and unnecessary – falsely

                      Profiles can live on sr.ht, but on any sr.ht instance, or any instance of any other forge software which federates with email. A person would probably still have a single canonical place they live on, and a profile there which lists their forks of software from around the net. Commit stats are easily generated on such a platform as well. Fork counts and followers (stars?) I find much less interesting, they’re just ego stroking and should be discarded if technical constraints require.

                      1. 4

                        I don’t think that’s a strong argument in favor of git being federated. I don’t think it matters either.

                        Git in of itself does not care about the transport. It does not care whether you use HTTP, git:// or email to bring your repo up to date. You can even use an USB stick.

                        I’d say git is communication format agnostic, federation is all about standardizing communication. Using email with git is merely another way to pipe git I/O, git itself does not care.

                        1. 2

                          git send-email literally logs into SMTP and sends a patch with it.

                          git am and git format-patch explicitly refer to mailboxes.

                          Email is central to the development of Linux and git itself, the two projects git is designed for. Many git features are designed with email in mind.

                          1. 4

                            Yes but ultimately both do not require nor care about federation itself.

                            send-email is IMO more of a utility function, git am or format-patch, which as you mention go to mailboxes, have nothing to do with email’s federated nature. Neither is SMTP tbh, atleast on the Client-Server side.

                            They’re convenience scripts that do the hard part of writing patches in mails for you, you can also just have your mailbox on a usb stick and transport it that way. And the SMTP doesn’t need to go elsewhere either.

                            I guess the best comparison is that this script is no more than a frontend for Mastodon. The Frontend of Mastodon isn’t federated either, Mastodon itself is. Federation is the server-to-server part. That’s the part we care about. But git doesn’t care about that.

                            1. 9

                              I see what you’re getting at. I have to concede that you are correct in a pedantic sense, but in a practical sense none of what you’re getting at matters. In a practical sense, git is federated via email.

                            2. 3

                              That various email utilities are included seems more like a consequence of email being the preferred workflow of git developers. I don’t see how that makes it the canonical workflow compared to pulling from remotes via http or ssh, git has native support for both after all.

                          2. 1

                            I belive that @tscs37 already showed that Git is distributed, since all nodes are equal (no distinction between clinets and servers), while a git networks can be structured in a federated fashion, ir even in a centralized one. What the transport medium has to do with this is still unclear in my view.

                            Fork counts and followers (stars?) I find much less interesting, they’re just ego stroking and should be discarded if technical constraints require

                            That’s exactly my point. GitHub offers a unit-standard, and easily recognisable and readable (simply because everyone is used to it). This has a value and ultimately a relevance, that can’t just be ignored, even if this reason is nonsense. It would just be another example of technical naïve.

                            I’ve shown my sympathy for ideas like these before, ad I most certainly don’t want to make the impression of a GitHub apologist. All I want to remind people is that the Social aspect beyond necessity (builds, issue trackers, …) are all things one has to seriously consider and tackle when one is interested in offering an alternative to GitHub, with any serious ambitions.

                            1. 1

                              I don’t think sr.ht has to please everyone. People who want these meaningless social features will probably be happier on some other platform, while the veterans are getting work done.

                              1. 1

                                I’m fine with people using mailing-list oriented solutions (the elitism might be a bit off-putting, but never mind). I just don’t think that it’s that much better than the GitPub idea.

                                People who want these meaningless social features will probably be happier on some other platform, while the veterans are getting work done.

                                If having these so-called “meaningless social features” helps a project thrive, attract contributers and new users, I wouldn’t conciser these meaningless. But if that’s not what you are interested in, that’s just ok.

                          3. 2

                            our local router blocked SMTP connections to non-whitelisted servers

                            The article says that sr.ht can optionally send the emails for you, no git send-mail required: “They’ll enter an email address (or addresses) to send the patch(es) to, and we’ll send it along on their behalf.”

                            Also what mail transfer agent were you pointing git send-mail at? You can have it send through gmail/fastmail/etc servers – would your router block that?

                            GitHub […] adds a certain something to version control, like profiles, stars, commit-stats, fork-counts, followers

                            How about mirroring code on github to collect stars? Make it a read-only mirror by disabling issues and activating the pull request rejection bot. Git, Linux, and Postgres do this, and probably other projects do too.

                            Email […] is notoriously bad at any identity validation

                            Do SPF, DKIM and DMARC make this no longer true, or are there still ways to impersonate people?

                            1. 1

                              Also what mail transfer agent were you pointing git send-mail at?

                              Fastmail. Was too esoteric for the default settings of my router. And if it weren’t for support, I would have never guessed that that was the issue, since the whole interface is so alien to most people (just like the questions: did I send the right commits, is my message formatted correctly, etc.)

                              How about mirroring code on github to collect stars? Make it a read-only mirror by disabling issues and activating the pull request rejection bot. Git, Linux, and Postgres do this, and probably other projects do too.

                              I’m not saying it’s perfect (again, I’m no GitHub apologist) – my point is that it isn’t irrelevant!

                              Do SPF, DKIM and DMARC make this no longer true, or are there still ways to impersonate people?

                              Yes, if someone doesn’t use these things. And claiming “oh, but they just should” is again raising the entry barrier, which is just too high the way it already would be.

                              1. 1

                                Yes, if someone doesn’t use these things. And claiming “oh, but they just should” is again raising the entry barrier, which is just too high the way it already would be.

                                This doesn’t damn the whole idea, it just shows us where open areas of development are.

                          1. 5

                            Git via email sounds like hell to me. I’ve tried to find some articles that evangelize the practice of doing software development tasks through email, but to no avail. What is the allure of approaches like this? What does it add to just using git by itself?

                            1. 6

                              I tried to collect the pros and cons in this article: https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html

                              1. 3

                                I also spoke about this at length in a previous article:

                                https://drewdevault.com/2018/07/02/Email-driven-git.html

                                1. 3

                                  While my general experience with git email is bad (it’s annoying to set up, especially in older versions and I don’t like it’s interface too much), my experience of interaction with projects that do this was generally good. You send a patch, you get review, you send a new, self-contained patch, attached to the same thread… etc, in parallel to the rest of the project discussion. It’s a different flavour, but with a project that is used to the flow, it can really be quite pleasing.

                                  1. 2

                                    What does it add to just using git by itself?

                                    I think the selling point is precisely that it doesn’t add anything else. Creating a PR involves more steps and context changes than git-format-patch git-send-mail.

                                    I have little experience using the mailing list flow, but when I had to do so (because the project required it) I found it very easy to use and better for code reviews.

                                    1. 1

                                      Creating a PR involves more steps and context changes than git-format-patch git-send-mail.

                                      I’m not sure I understand. What steps are removed that would otherwise be required?

                                      1. 4

                                        Simply, it’s “create a fork and push your changes to it”. But also consider that it’s…

                                        1. Open a web browser
                                        2. Register for a GitHub account
                                        3. Confirm your email address
                                        4. Fork the repository
                                        5. Push your changes to the fork
                                        6. Open a pull request

                                        In this workflow, you switched between your terminal, browser, mail client, browser, terminal, and browser before the pull request was sent.

                                        With git send-email, it’s literally just git send-email HEAD^ to send the last commit, then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README. You can skip the second step next time by doing git config sendemail.to someone@example.org. Bonus: no proprietary software involved in the send-email workflow.

                                        1. 3

                                          Also github pull requests involve more git machinery than is necessary. Most people, when they open a PR, choose to make a feature branch in their fork from which to send the PR, rather than sending from master. The PR exposes the sender’s local branching choices unnecessarily. Then, for each PR, github creates more refs on the remote, so you end up having lots stuff laying around (try running git ls-remote | grep pull).

                                          Compare that with the idea that if you want to send a code change, just mail the project a description (diff) of the change. We all must be slightly brainwashed when that doesn’t seem like the most obvious thing to do.

                                          In fact the sender wouldn’t even have to use git at all, they could download a recent code tarball (no need to clone the whole project history), make changes and run the diff command… Might not be a great way to do things for ongoing contributions, but works for a quick fix.

                                          Of course opening the PR is just the start of the future stymied github interactions.

                                          1. 3

                                            In my case I tend to also perform steps:

                                            • 3.1 Clone project
                                            • 3.2 Use project for a while
                                            • 3.3 Make some local changes
                                            • 3.4 Commit those changes to local clone
                                            • 3.5 Try to open pull request
                                            • 3.6 Realise GitHub requires me to make a fork of the original repo
                                            • 4.1 Read man git-remote to see how to point my local clone (with the changes) to my GitHub fork
                                            • 4.2 Run relevant git remote commands
                                            • 4.3 Read man git-push to see how to send my changes to the fork rather than the original repo
                                            1. 2

                                              To send email, you also have to have an email address. If we are doing a fair comparison, that should be noted as well. Granted, it is much more likely that someone has an email address than a GitHub account, but the wonderful thing about both is that you only have to set them up once. So for this reason, it would be a bit more fair if the list above started from step four.

                                              Now, if I have GitHub integration in my IDE (which is not an unreasonable thing to assume), then I do not need to leave the IDE at all, and I can fork, push, and open a PR (case in point, Emacs and Magithub can do this). I can also do all of this on GitHub, never leaving my browser. I don’t have to figure out where to send an email, because it automatically sends the PR to the repo I forked from. I don’t even need to open a shell and deal with the commandline. I can do everything with shortcuts and a little bit of mousing around, in both the IDE and the browser case.

                                              Even as someone who is familiar with the commandline, and is sufficiently savvy with e-mail (at one point I was subscribed to debian-bugs-dist AND LKML, among other things, and had no problem filtering out the few bits I needed), I’d rather work without having to send patches, using Magit + magithub instead. It’s better integrated, hides uninteresting details from me, so I can get done with my work faster. It works out of the box. git send-email does not, it requires a whole lot of set up per repo.

                                              Furthermore, with e-mail, you have to handle replies, have a firm grip on your inbox. That’s an art on its own. No such issue with GitHub.

                                              With this in mind, the remaining benefit of git send-email is that it does not involve a proprietary platform. For a whole lot of people, that’s not an interesting property.

                                              1. 2

                                                To send email, you also have to have an email address. If we are doing a fair comparison, that should be noted as well.

                                                I did note this:

                                                then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README

                                                Magit + magithub […] works out of the box

                                                Only if you have a GitHub account and authorize it. Which is a similar amount of setup, if not more, compared to setting up git send-email with your SMTP info.

                                                git send-email does not, it requires a whole lot of set up per repo

                                                You only have to put your SMTP creds in once. Then all you have to do per-repo is decide where to send the email to. How is this more work than making a GitHub fork? All of this works without installing extra software to boot.

                                                1. 3

                                                  then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README

                                                  With GitHub, I do not need to obtain any email address, or dig it out of a README. It sets things up automatically for me so I can just open a PR, and have everything filled out.

                                                  Only if you have a GitHub account and authorize it. Which is a similar amount of setup, if not more, compared to setting up git send-email with your SMTP info.

                                                  Lets compare:

                                                  e-mail:

                                                  1. Clone repository
                                                  2. Do my business
                                                  3. Figure out where to send e-mail to.
                                                  4. git config so I won’t have to figure it out ever again.
                                                  5. git send-email

                                                  magithub:

                                                  1. clone repo
                                                  2. do my business
                                                  3. fork the repo
                                                  4. push changes
                                                  5. open PR

                                                  The first two steps are pretty much the same, both are easily assisted by my IDE. The difference starts from step 3, because my IDE can’t figure out for me where to send the email. That’s a manual step. I can create a helper that makes it easier for me to do step 4 once I have the address, but that’s about it. For the magithub case, step 3 is SPC g h f; step 4 SPC g s p u RET; step 5 SPC g h p, then edit the cover letter, and , c (or C-c) to finish it up and send it. You can use whatever shortcuts you set up, these are mine. Nothing to figure out manually, all automated. All I have to do is invoke a shortcut, edit the cover letter (the PR’s body), and I’m done.

                                                  I can even automate the clone + fork part, and combine push changes + open PR, so it becomes:

                                                  1. fork & clone repo (or clone if already forked)
                                                  2. do my business
                                                  3. push changes & open PR

                                                  Can’t do such automation with e-mailed patches.

                                                  I’m not counting GitHub account authorization, because that’s about the same complexity as configuring auth for my SMTP, and both have to be done only once. I’m also not counting registering a GitHub account, because that only needs to be done once, and you can use it forever, for any GitHub-hosted repo, and takes about a minute, a miniscule amount compared to doing actual development.

                                                  Again, the main difference is that for the e-mail workflow, I have to figure out the e-mail address, a process that’s longer than forking the repo and pushing my changes, and a process that can’t be automated to the point of requiring a single shortcut.

                                                  Then all you have to do per-repo is decide where to send the email to. How is this more work than making a GitHub fork?

                                                  Creating a GitHub fork is literally one shortcut, or one click in the browser. If you can’t see how that is considerably easier than digging out email addresses from free-form text, then I have nothing more to say.

                                                  And we haven’t talked about receiving comments on the email yet, or accepting patches. Oh boy.

                                                  1. 2

                                                    With GitHub, I do not need to obtain any email address, or dig it out of a README. It sets things up automatically for me so I can just open a PR, and have everything filled out.

                                                    You already had to read the README to figure out how to compile it, and check if there was a style guide, and review guidelines for contribution…

                                                    Lets compare

                                                    Note that your magithub process is the same number of steps but none of them have “so I won’t have to figure it out ever again”, which on the email process actually eliminates two of your steps.

                                                    Your magithub workflow looks much more complicated, and you could use keybindings to plug into send-email as well.

                                                    Can’t do such automation with e-mailed patches

                                                    You can do this and even more!

                                                    1. 2

                                                      You already had to read the README to figure out how to compile it, and check if there was a style guide, and review guidelines for contribution…

                                                      I might have read the README, or skimmed it. But not to figure out how to compile - most languages have a reasonably standardised way of doing things. If a particular project does not follow that, I will most likely just stop caring unless I really, really need to compile it for one reason or another. For style, I hope they have tooling to enforce it, or at least check it, so I don’t have to read long documents and keep it in my head. I have more important things to store there than things that should be automated.

                                                      I would likely read the contributing guidelines, but I won’t memorize it, and I certainly won’t try to remember an e-mail address. I might remember where to find it, but it will still be a manual process. Not a terribly long process, but noticeably longer than not having to do it at all.

                                                      Note that your magithub process is the same number of steps but none of them have “so I won’t have to figure it out ever again”, which on the email process actually eliminates two of your steps.

                                                      Because there’s nothing for me to figure out at all, ever (apart from what repo to clone & fork, but that’s a common step between the two workflows).

                                                      Your magithub workflow looks much more complicated

                                                      How is it more complicated? Clone, work, fork, push, open PR (or clone+fork, work, push+PR), of which all but “work” is heavily assisted. None of it requires me to look anything up, anywhere.

                                                      and you could use keybindings to plug into send-email as well.

                                                      And I do, when I’m dealing with projects that use an e-mail workflow. It’s not about shortcuts, but what can be automated, what the IDE can do instead of requiring me to do it.

                                                      You can do this and even more!

                                                      You can, if you can extract the address to send patches to automatically. You can build something that does that, but then the automation is tied to that platform, just like the PRs are tied to GitHub/GitLab/whatever.

                                                      And again, this is just about sending a patch/opening a PR. There’s so much more PRs provide than that. Some of that, you can do with e-mail. Most of it, you can build on top of e-mail. But once you build something on top of e-mail, you no longer have an e-mail workflow, you have a different platform with which you can interact via e-mail. Think issues, labels for them, reviews (with approvals, rejection, etc - all of which must be discoverable by programs reliably), new commits, rebases and whatnot… yeah, you can build all of this on top of e-mail, and provide a web UI or an API or tools or whatever to present the current state (or any prior state). But then you built a platform which requires special tooling to use to its full potential, and you’re not much better than GitHub. You might build free software, but then there’s GitLab, Gitea, Gogs and a whole lot of others which do many of these things already, and are almost as easy to use as GitHub.

                                                      I’ve worked with patches sent via e-mail quite a bit in the past. One can make it work, but it requires a lot of careful thought and setup to make it convenient. I’ll give a few examples!

                                                      With GitHub and the like, it is reasonably easy to have an overview of open pull requests, without subscribing to a mailing list, or browsing archives. An open PR list is much easier to glance at and have a rough idea than a mailing list. PRs can have labels to help in figuring out what part of the repo they touch, or what state they are in. They can have CI states attached. At a glance, you get a whole lot of information. With a mailing list, you don’t have that. You can build something on top of e-mail that gives you a similar overview, but then you are not using e-mail only, and will need special tooling to process the information further (eg, to limit open PRs to those that need a review, for example).

                                                      With GitHub and the like, you can subscribe to issues and pull requests, and you’ll get notifcations about those and those alone. With a mailing list, you rarely have that option, and must do filtering on your own, and hope that there’s a reasonable convention that allows you to do so reliably.

                                                      There’s a whole lot of other things that these tools provide over plain patches over email. Like I said before, most - if not all - of that can be built on top of e-mail, but to achieve the same level of convenience, you will end up with an API that isn’t e-mail. And then you have Yet Another Platform.

                                                      1. 2

                                                        How is it more complicated? Clone, work, fork, push, open PR (or clone+fork, work, push+PR)

                                                        Because the work for the send-email approach is: clone, work, git send-email. This is fewer steps and is therefore less complicated. Not to mention that as projects become more decentralized as they move away from GItHub, the registration process doesn’t go away and starts recurring for every new forge or instance of a forge you work with.

                                                        But once you build something on top of e-mail, you no longer have an e-mail workflow, you have a different platform with which you can interact via e-mail. Think issues, labels for them, reviews (with approvals, rejection, etc - all of which must be discoverable by programs reliably), new commits, rebases and whatnot…

                                                        Yes, that’s what I’m advocating for.

                                                        But then you built a platform which requires special tooling to use to its full potential, and you’re not much better than GitHub

                                                        No, I’m proposing all of this can be done with a very similar UX on the web and be driven by email underneath.

                                                        PRs can have labels to help in figuring out what part of the repo they touch, or what state they are in. They can have CI states attached.

                                                        So let’s add that to mailing list software. I explicitly acknoweldge the shortcomings of mail today and posit that we should invest in these areas rather than rebuilding from scratch without an email-based foundation. But none of the problems you bring up are problems that can’t be solved with email. They’re just problems which haven’t been solved with emails. Problems I am solving with emails. Read my article!

                                                        but then you are not using e-mail only, and will need special tooling to process the information further (eg, to limit open PRs to those that need a review, for example).

                                                        So what? Why is this even a little bit of a problem? What the hell?

                                                        With GitHub and the like, you can subscribe to issues and pull requests, and you’ll get notifcations about those and those alone.

                                                        You can’t subscribe to issues or pull requests, you have to subscribe to both, plus new releases. Mailing lists are more flexible in this respect. There are often separate thing-announce, thing-discuss (or thing-users), and thing-dev mailing lists which you can subscribe to separately depending on what you want to hear about.

                                                        Like I said before, most - if not all - of that can be built on top of e-mail, but to achieve the same level of convenience, you will end up with an API that isn’t e-mail.

                                                        No, you won’t. That’s simply not how this works.

                                                        Look, we’re just not on the same wavelength here. I’m not going to continue diving into this ditch of meaningless argument. You keep using whatever you’re comfortable with.

                                                      2. 2

                                                        Your magithub workflow looks much more complicated, and you could use keybindings to plug into send-email as well.

                                                        I just remembered a good illustration that might explain my stance a bit better. My wife, a garden engineer, was able to contribute to a few projects during Hacktoberfest (three years in a row now), with only a browser and GitHub for Windows at hand. She couldn’t have done it via e-mail, because the only way she can use her email is via her smart phone, or GMail’s web interface. She knows nothing else, and is not interested in learning anything else either, because these perfectly suit her needs. Yet, she was able to discover projects (by looking at what I contributed to, or have starred), search for TODOs or look at existing issues, fork a repo, write some documentation, and submit a PR. She could have done it all from a web browser, but I set up GitHub for Windows for her - in hindsight, I should have let her just use the browser. We’ll do that this year.

                                                        She doesn’t know how to use the command-line, has no desire, and no need to learn it. Her email handling is… something that makes me want to scream (no filters, no labels, no folders - one big, unorganized inbox), but it suits her, and as such, she has no desire to change it in any way.

                                                        She doesn’t know Emacs, or any IDE for that matter, and has no real need for them, either.

                                                        Yet, her contributions were well received, they were useful, and some are still in place today, unchanged. Why? Because GitHub made it easy for newcomers to contribute. They made it so that contributing does not require them to use anything else but GitHub. This is a pretty strong selling point for many people, that using GitHub (and similar solutions) does not affect any other tool or service they use. It’s distinct, and separate.

                                                        1. 2

                                                          Not all projects have work for unskilled contributors. Why should we cater to them (who on the whole do <1% of the work) at the expense of the skilled contributors? Particularly the most senior contributors, who in practice do 90% of the work. We don’t build houses with toy hammers so that your grandma can contribute.

                                                          I’m not saying we shouldn’t make tools which accomodate everyone. I’m saying we should make tools that accomodate skilled engineers and build simpler tools on top of that. Thus, the skilled engineers are not slowed down and the greener contributors can still get work done. Then, there’s a path for newer users to become more exposed to more powerful tools and more smoothly become senior contributors themselves.

                                                          You need to get this point down if you want me to keep entertaining a discussion with you: you can build the same easy-to-use UX and drive it with email.

                                                          1. 3

                                                            I’m not saying we shouldn’t make tools which accomodate everyone. I’m saying we should make tools that accomodate skilled engineers and build simpler tools on top of that.

                                                            I was under the impression that git + GitHub are exactly these. Git and git send-email for those who prefer those style, GitHub for those who prefer that. The skilled engineers can use the powerful tools they have, while those with a different skillset can use GitHub. All you need is willingness to work with both.

                                                            you can build the same easy-to-use UX and drive it with email.

                                                            I’m not questioning you can build something very similar, but as long as e-mail is the only driving power behind it, there will be plenty of people who will turn to some other tool. Because filtering email is something you and I can easily do, but many can’t, or aren’t willing to. Not when there are alternatives that don’t require them to do extra work.

                                                            Mind you, I consider myself a skilled engineer, and I mainly use GitHub/GitLab APIs, because I don’t have to filter e-mail, nor parse the info in them, the API serves me data I can use in an easier manner. From an integrator point of view, this is golden. If, say, an Emacs integration starts with “Set up your email so mail with these properties are routed here”, that’s not a good user experience. And no, I don’t want to use my MUA to work with git, because magit is a much better, much more powerful tool for that, and I value my productivity.

                                                            1. 1

                                                              I’m not questioning you can build something very similar, but as long as e-mail is the only driving power behind it, there will be plenty of people who will turn to some other tool.

                                                              I’m pretty sure the whole point would be that the “shiny UI” tool would not expose email to the user at all – so the “plenty of people” wouldn’t leave because they wouldn’t know the difference.

                                                              1. 0

                                                                So…. pretty much GitHub/GitLab/Gitea 2.0, but with the added ability to open PRs by email (to cater to that workflow), and a much less reliable foundation?

                                                                Sure. What could possibly go wrong.

                                                2. 1

                                                  I don’t think you can count signing up for GitHub if you’re not counting signing up for email.

                                                  If you’re using hub, it’s just hub pull-request. No context switching

                                                  1. 2

                                                    If you’re counting signing up for email you have to count that for GitHub, too, since they require an email address to sign up with.

                                                3. 1

                                                  Using GitHub requires pushing to different repository and then opening the PR on the GitHub Interface, which is a context change. The git-send-mail would be equivalent to sending the PR.

                                                  git-send-email is only one step, akin to opening the PR, no need to push to a remote repository. And from the comfort of your development environment. (Emacs in my case)

                                            1. 3

                                              @SirCpmwn, how did you land on the name/domain sr.ht for this?

                                              1. 3

                                                I saw it was available years ago and bought it before I knew what I would do with it.

                                              1. 5

                                                Just git?

                                                I was kind of hoping that if we’re going to break the github hegemony, we might also start to reconsider git at least a little. Mercurial has so many good ideas worth spreading, like templates (DSL for formatting the output of every command), revsets (DSL for querying commits), filesets (DSL for querying files and path) and changeset evolution (meta-graph of commit rewriting).

                                                1. 10

                                                  Don’t forget pijul!

                                                  Seriously, though, I don’t think there is any “github plus something” that is going to break the github hegemony. Github won because it offered easy forking while Sourceforge was locked in a centralized model. Sourceforge won because it was so much easier than hosting your own repo + mailing list.

                                                  The thing that will get people away from github has to have a new idea, a new use case that isn’t being met by github right now, and which hasn’t been proposed before. That means that adding hg won’t do it – not because hg is worse than git (honestly, git’s terrible, and hg is fine), but because hg’s already been an option and people aren’t using it.

                                                  Adding email commits won’t do it, because that use case has been available for a long time (as pointed out elsewhere in these comments) and people aren’t using it.

                                                  Until something new is brought to the table, it’s all “let’s enter a dominated market with a slight improvement over the dominant tech”, and that’s just not going to be enough.

                                                  1. 8

                                                    So, one thing that I would use a new contender for is being able to put my work under my own domain.

                                                    The “new thing” here is “have your personal branding on your site” (which is clearly fairly popular given how common personal domain/sites are among developers).

                                                    If I could CNAME code.daniel.heath.cc to your host to get my own github, I’d do it today (as long as any issues/wiki/PR state/etc remained usefully portable).

                                                    1. 8

                                                      That’s a really neat idea. I don’t think I can prioritize it right now but it’s definitely something I would consider implementing.

                                                      1. 3

                                                        I actually think that GitHub’s lack of branding and customization is a big reason for its success. When I go take a look at a new project on GitHub, I don’t have to figure out how to navigate a new site’s design, and this makes the GitHub ecosystem as a whole easier to use.

                                                        1. 3

                                                          I don’t mean corporate/design branding.

                                                          I want to use my own name (and be able to move providers without breaking links).

                                                          1. 1

                                                            I want to use my own name (and be able to move providers without breaking links).

                                                            But that will happen anyway, unless your new provider uses the same software as the old one.

                                                            1. 1

                                                              Yep - so it has to be oss too.

                                                              1. 1

                                                                That makes sense actually. sr.ht supporting the ability to use your own domain name (presumably a subdomain of your personal domain name for personal projects?) would make it really easy to migrate away from sr.ht in the future if you felt it was more cost-effective to host your own. Although I don’t know what the pricing model is intended to be.

                                                        2. 2

                                                          You can do that with Gitlab (or Gitea if you prefer something lightweight). Only thing is you need to take care of the hosting yourself. But I’m sure there are companies offering a one-click setup, to which you can later point your own domain.

                                                          1. 2

                                                            If you host your own gitlab instance, can you fork and submit patches to a project that’s hosted on gitlab,com, as easily/seamlessly as if you were hosted there?

                                                            Centralization has benefits that self-hosting can’t always provide. If there were some federation which allowed self-hosting to integrate with central and other self-hosting sites, that seems like a new and interesting feature.

                                                            1. 5

                                                              Git is already federated with email - it’s specific services like GitHub which are incompatible with git’s federation model (awfully conveniently, I might add). sr.ht is going to be designed to accomodate git’s email features, both for incoming and outgoing communication, so you’ll be able to communicate easily between sr.ht instances (or sr.ht and other services like patchworks or LKML).

                                                              1. 2

                                                                As I mention earlier, though, federation by email has been available for a long time and hasn’t been used (by enough people to replace github). The (vast) majority of developers (and other repo watchers) prefer a web UI to an email UI.

                                                                1. 4

                                                                  I intend to build a web UI which is driven by email underneath.

                                                              2. 4

                                                                The gitlab, gitea, and gogs developers are working on this but it’s still very much in the discussion stage at this point. https://github.com/git-federation/gitpub/

                                                                1. 1

                                                                  Oh, definitely no federation. Didn’t know that federation was what he was looking for.

                                                                  1. 2

                                                                    I don’t know exactly what he was looking for, but It seemed like one of:

                                                                    • hosted, centralized, but with my domain plus some branding, or
                                                                    • self-hosted but with the features of centralization, including community, etc

                                                                    The latter sounds to me like it would need federation.

                                                                2. 1

                                                                  It’s currently awkward to run multiple domains on most OSS servers which might otherwise be suitable.

                                                              3. 3

                                                                hg isn’t really an option right now, though. There’s nowhere to host it. There’s bitbucket, and it’s kind of terrible, and they keep making it worse.

                                                                If you can’t even host it, people won’t even try it.

                                                              4. 14

                                                                I’m afraid you’re not going to find a sympathetic ear in sr.ht. I am deeply fond of git and deeply critical of hg.

                                                                The GitHug hegemony has nothing to do with its basis on git. If git were the product of GitHub, I might agree, but it’s not. If you really want to break the GitHub hegemony you should know well enough to throw your lot in with the winning tool rather than try to disrupt two things at once.

                                                                1. 3

                                                                  Do you mind expanding on why you are deeply critical of mercurial?

                                                                  1. 8

                                                                    Perhaps some day I’ll write a blog post going into detail. The short of it is that git is more Unixy, Mercurial does extensibility the wrong way, and C is a better choice than Python (or Rust, I hear they’re working on that).

                                                                    1. 4

                                                                      Git IS more unixy! Using hg feels suspiciously like using a GUI and I can’t figure out why.

                                                                      1. 4

                                                                        because hg‘s command-line interface was “designed”, whereas git’s command-line interface “evolved” from how it was being used.

                                                                  2. 2

                                                                    The GitHug hegemony has nothing to do with its basis on git.

                                                                    Exactly; it’s the other way around. Git got popular because of github.

                                                                    Git was much worse before github made it popular. It’s bad now and difficult to use now, but it was much worse before 2008. So if you just want to get away from Github, there’s no need to stay particulary enamoured with git either.

                                                                    And whatever criticisms you may have about hg, you have to also consider that it has good ideas (those DSLs above are great). Those ideas are worth spreading, and git for a long time has tried to absorb some of them and hasn’t succeeded.

                                                                1. 3

                                                                  feature request ideas that might be nice (though may also be bad ideas):

                                                                  • Man page or documentation page system side by side with the code, an easy way to get some basic docs that would look something like https://ziglang.org/documentation/master/. A pain point seems to be getting docs hosted for multiple released versions of software.

                                                                  • A nice system for uploading and hosting signed release binaries.

                                                                  • Some sort of triggered checklists for various events. i.e. when a tag is done, a checklist might appear reminding people to upload tarballs and update a demo server.

                                                                  1. 3

                                                                    Hey, thanks for sharing your ideas! Can you direct them to ~sircmpwn/sr.ht-discuss@lists.sr.ht for posterity’s sake? I’ll copy my reply there when you do:

                                                                    Man page or documentation page system side by side with the code, an easy way to get some basic docs that would look something like https://ziglang.org/documentation/master/. A pain point seems to be getting docs hosted for multiple released versions of software.

                                                                    I intend to support this through a combination of continuous integration and static website hosting. At the moment, I compile my Jekyll blog on builds.sr.ht with a job like this: https://builds.sr.ht/job/4713. This rsyncs it to private hosting, but in the future I want to offer a service to sr.ht for hosting static content like this. You could run some offline documentation generator in your build and send up the artifacts. I think this is similar to how Zig’s docs are done today.

                                                                    A nice system for uploading and hosting signed release binaries.

                                                                    Noted, may end up tying this into the stuff I mentioned for doc hosting.

                                                                    Some sort of triggered checklists for various events. i.e. when a tag is done, a checklist might appear reminding people to upload tarballs and update a demo server.

                                                                    This is very WIP, but I’m working on dispatch.sr.ht for this sort of thing. Basically its job is going to be to ingest events like git pushes, emails on mailing lists, etc, and kick off a CI job. From there you can do whatever you want, really. I’m also going to make a simple package that runs in the guest you can use to conveniently script authenticated tasks like sending emails to the mailing list or using the API. Today various projects use the very-early service to tie GitHub projects to builds.sr.ht Travis-style.

                                                                  1. 17

                                                                    Thanks for posting this, eta! sr.ht is still a work in progress, but things are definitely starting to fall into place. The whole thing is self hosted (it even deploys itself on the in-house CI) and it’s being used seriously for a few projects - we run all builds for the sway and wlroots projects through it, for example: https://builds.sr.ht/job/4878.

                                                                    Check out https://lists.sr.ht/~sircmpwn/sr.ht-announce for news, or shoot an email to ~sircmpwn/sr.ht-announce+subscribe@lists.sr.ht. If anyone from Lobsters wants an alpha account, shoot me an email - sir@cmpwn.com - would be happy to hook you up.

                                                                    1. 8

                                                                      I’m impressed that you not only develop end-user software (sway) and its libraries (wlroots), but you also build out the whole project lifecycle tools as well. How do you find the time to do everything? Do you have any productivity advice for others on managing and delivering so many different projects?

                                                                      1. 20

                                                                        Thank you for your kind words! It might be prudent to point out that neither sway, wlroots, nor sr.ht has seen a stable release to date, though. I’m not afraid to start a lot of ambitious projects, even if they’ll take years to complete, because the years will eventually pass and I’ll thank myself for not spending them worried I wouldn’t have had time to complete anything. At least how I hope it works, we’ll see if any of this shit ever gets done!

                                                                    1. 7

                                                                      I still don’t get why sending patches via email is preferable over creating git remotes and pulling changes from them, the latter seems to fit better into git’s decentralized model. Even if you have scripts to create emails out of patches and apply them, it still seems clunky to try to recreate git’s state over text.

                                                                      1. 8

                                                                        The main advantage of email is that you can do code review over email, too - you can chop up the patch and reply to specific lines of code inline and carry on the discussion same way you would any other email thread.

                                                                        For bigger changes, though, it doesn’t scale. For that, we have git request-pull:

                                                                        https://www.git-scm.com/docs/git-request-pull

                                                                        I intend to facilitate both approaches on sr.ht.

                                                                        1. 3

                                                                          Email simplifies things.

                                                                          You don’t need to know git ;)

                                                                        2. 4

                                                                          Even if you have scripts to create emails out of patches and apply them, it still seems clunky to try to recreate git’s state over text.

                                                                          Git was made with email workflows in mind from the start. To send email, git helps with git format-patch and git am can receive patches via email. The patch format, for that matter, was also made with email in mind.

                                                                        1. 14

                                                                          This blog post: a case study in being a jerk to someone who is being a jerk, only since Linus is a “jerk” you get off scott-free. Unsurprisingly, this is written by someone who has never contributed to the Linux kernel and who was uninvolved in the discussion he’s picking apart.

                                                                          The revised email at the end does lose information. Contrary to what hipsters write blog posts complaining about, 99% of Linus’s emails are cordial. The information that’s lost is the conveyance that this is more important to Linus than most subjects.

                                                                          1. 20

                                                                            This comment: a case study in being a jerk to someone who is being a jerk to a jerk.

                                                                            In all seriousness, I don’t believe that Gary Bernhardt is being a jerk at all. There’s a line between being critical of a piece of work and calling someone brain damaged, and hopefully, we all can see the difference.

                                                                            Aside: I love when people use the word “hipster” to invalidate other viewpoints. Apparently, there are two modes of being: Being Right and Being A Hipster.

                                                                            1. 2

                                                                              To the unserious comment, I don’t think I was being a jerk. I called him a jerk, which I guess you could argue is a jerk move under any circumstances, but if I’m being a jerk then so is Gary.

                                                                              To the serious comment, I just want to note that “brain damaged” is a meme among old school hackers which isn’t as strong of a word as you think.

                                                                              To the aside, I don’t use hipster as an insult or to imply wrongness, but I do use it to invalidate his point. Gary is a Ruby developer. Linus is a kernel developer. The worlds are far removed from each other.

                                                                              1. 50

                                                                                I’ve put tens of thousands of lines of C into production, including multiple Linux kernel drivers. In one case, those kernel drivers were critical-path code on a device used in strain testing the wings of an airplane that you might’ve flown in by now.

                                                                                I’m not a stranger to the kernel; I just left that world. Behavior like Linus’ in that email was part of the reason, though far from the only reason.

                                                                                With all of that said: having written a bunch of systems software shouldn’t be a prerequisite for suggesting that we avoid attacking people personally when they make programming mistakes, or what we suspect are programming mistakes.

                                                                                1. 10

                                                                                  Exactly. I’ve also met many people that do high-performance, embedded, and/or safety-critical code in C that are more polite in these situations. Linus’ attitude is a separate issue from what’s necessary to evaluate and constructively criticize code.

                                                                                2. 17

                                                                                  “brain damaged” is a meme among old school hackers which isn’t as strong of a word as you think.

                                                                                  Yikes. That “meme” is a whole other thing I don’t even care to unpack right now.

                                                                                  I don’t use hipster as an insult or to imply wrongness, but I do use it to invalidate his point. Gary is a Ruby developer. Linus is a kernel developer. The worlds are far removed from each other.

                                                                                  Gotcha. Kernal developer == real old-school hacker. Ruby developer == script kiddie hipster. Are we really still having this argument in 2018?

                                                                                  1. 2

                                                                                    Yikes. That “meme” is a whole other thing I don’t even care to unpack right now.

                                                                                    “Brain damaged” is a term from back in the Multics days, Linus didn’t make that one up for the occasion. If you’re unfamiliar with the “jargon file” aka hacker dictionary, you can see the history of this particular term here: http://www.catb.org/jargon/html/B/brain-damaged.html

                                                                                    1. 1

                                                                                      Yikes. That “meme” is a whole other thing I don’t even care to unpack right now.

                                                                                      Listen, cultures are different and culture shock is a thing. I’m in a thread full of foreigners shocked that customs are different elsewhere. You better just take my word for it on “brain damaged” because you clearly aren’t a member of this culture and don’t know what you’re talking about.

                                                                                      Gotcha. Kernal developer == real old-school hacker. Ruby developer == script kiddie hipster. Are we really still having this argument in 2018?

                                                                                      How about you quit putting words in my mouth? Do you really need me to explain the world of difference between Ruby development and kernel hacking? In 2018? It’s not a matter of skill. Gary is great at what he does, but it has almost nothing to do with what Linus does. The people who surround Gary and the people who surround Linus are mutually exclusive groups with different cultural norms.

                                                                                      1. 21

                                                                                        You can’t use “it’s our culture” as a panacea; calling someone an idiot, moron etc. is a deliberate attempt to hurt them. I guess if what you’re saying is, “it’s our culture to intentionally hurt the feelings of people who have bad ideas,” well, then we might be at an impasse.

                                                                                        1. 22

                                                                                          The kind of toxic exclusivity and “old school hacker culture” elitism that you’re spouting in this thread is not what I expect to see on Lobsters. It makes me genuinely sad to see somebody saying these things and it also makes me apprehensive of ever being involved in the same project or community as you. Software development today is not what it was 20 –or even 5– years ago. Today it is far more about people than it is about software or technology. You may not like this, but it is the reality.

                                                                                          1. 7

                                                                                            Lobste.rs always had a few vocal people like this in threads. But note that they’re in the minority and generally are not upvoted as much as the people who aren’t elitist, racist, or just generally being a jerk.

                                                                                            1. 5

                                                                                              “old school hacker culture” elitism

                                                                                              Near 40, I can agree to be called old. But not elitist.
                                                                                              And I cannot accept to be associated with racist.

                                                                                              Not all software developers are hackers. Not all hackers are software developers.

                                                                                              Is stating this “elitism”? Is it “racism”? Is it being “jerk”?
                                                                                              Or is just using terms properly?

                                                                                  2. 5

                                                                                    The information that’s lost is the conveyance that this is more important to Linus than most subjects.

                                                                                    So add “I want to stress that this issue is really important to me” at the end of the revised email.

                                                                                    I think that making an issue out of this particular information being lost is missing the point - that it would be possible to say the same thing as Linus did without being abusive.

                                                                                    Contrary to what hipsters write blog posts complaining about

                                                                                    You’re falling into the same trap that the post discusses. This derision isn’t necessary to make your point, and doesn’t make it any stronger - it just adds an unnecessary insult.

                                                                                    1. 9

                                                                                      Contrary to what hipsters write blog posts complaining about, 99% of Linus’s emails are cordial.

                                                                                      That may well be true, but do we need that last 1% in a professional setting?

                                                                                      1. 9

                                                                                        (I am not defending Linus’ behaviour here, please don’t put those words in my mouth.)

                                                                                        I strongly take issue with American ideas of “professionalism”, and an even more so with the idea that we get to decide whether this project is “a professional setting” or not. What exactly makes this a “professional setting”? What is a “professional setting”? Why do we hold some interactions to higher standards than others?

                                                                                        I suspect “money changing hands” is the thing that makes this “a professional setting”, and that grinds my gears even further. Why are we supposed to hold ourselves to different standards just because some people are getting paid for doing it?

                                                                                        1. 3

                                                                                          Right, “professionalism” implies that you only need to be nice to somebody when you want them to something for you or want their money. This should actually be about “respect”, whether or not you want a Linux contributor to do something for you or want their money.

                                                                                        2. 12

                                                                                          The Linux kernel is not a professional setting. Besides, I argue that the 1% is useful, even in a professional setting - sometimes strong words are called for. I’ll be That Guy and say that people should grow a thicker skin, especially people who weren’t even the subject of the email and have never been involved in kernel development.

                                                                                          1. 14

                                                                                            If I look at who the contributors to the Linux kernel are, it would certainly appear to be a professional endeavor.

                                                                                            A large chunk of contributions to the kernel are made by people who are getting paid by the companies they work for to contribute. Sounds like a professional setting to me.

                                                                                            1. 4

                                                                                              Linux development is only “a professional endeavour” (which is a phrase I have strong issues with, see above) because some people decided to build their businesses in Linus’ craft room. We can like or dislike Linus’ behaviour, but we don’t get to ascribe “professionalism” or lack thereof (if there even is such a thing) to Linus’ work or behaviour, or that of any of the contributors.

                                                                                              Even if “professionalism” is an actual thing (it’s not; it’s just a tool used by people in power to keep others down) it’s between the people doing the paying, and the people getting the pay, and has nothing to do with any of us.

                                                                                              This idea that people should behave differently when there’s money involved is completely offensive to me.

                                                                                              1. 7

                                                                                                But it’s not. It’s a collaboration between everyone, including professionals and hobbyists. The largest group of kernel contributors are volunteers. On top of that, Linus doesn’t have to answer to anyone.

                                                                                                1. 8

                                                                                                  So, having a hobbyist involved means that you can be dickhead? Is that the conclusion that should be drawn from your statements?

                                                                                                  1. 3

                                                                                                    No. I’m saying that Linus is not a dickhead, Linux is not a professional endeavour, and neither should be held to contrived professional standards.

                                                                                                    1. 2

                                                                                                      “I’m saying that Linus is not a dickhead”

                                                                                                      His comments are proving otherwise given the main article shows the same information could’ve been conveyed without all the profanity, personal insults, and so on. He must be adding that fluff because he enjoys it or has self-control issues. He’s intentionally or accidentally a dick. I say that as a satirist whose a dick to people that give me headaches in real life. Although it doesn’t take one to know one, being someone whose always countering dicks and assholes with some dickish habits of his own makes what Linus is doing more evident. If no mental illness, there’s little excuse past him not giving a shit.

                                                                                                      1. 5

                                                                                                        “doesn’t behave according to my cultural norms” == “mental illness”

                                                                                                        Seriously?

                                                                                                        I would really appreciate it if you could stop expecting that your cultural norms have to apply to everyone on the planet.

                                                                                                        1. 1

                                                                                                          Im identifying the cultural norm of being an asshole, saying it applies to him at times, and saying the project would benefit if he knocked if off. Im not forcing my norms on anyone.

                                                                                                          Your comment is more amusing giving someone with Linus’s norns might just reply with profanity and personsl insults. Then, you might be complaining about that. ;)

                                                                                                          1. 1

                                                                                                            Then, you might be complaining about that. ;)

                                                                                                            No, I’d just accept that people from different cultures behave differently.

                                                                                                            Let’s face it, most people hate getting told they are wrong, regardless of the tone. That’s just how we are as humans.

                                                                                                            Taking offense about the tone just seems very US-specific, as they are accustomed to receiving some special superpowers in a discussion by uttering “I’m offended”.

                                                                                                            Some of the best feedback I received in my life wouldn’t be considered acceptable by US standards and I simply don’t care – I just appreciate the fact that someone took his time to spell out the technical problems.

                                                                                                            Here is a recent example: https://github.com/rust-lang/cargo/pull/5183#issuecomment-381449546

                                                                                                            1. 1

                                                                                                              Here is a recent example: https://github.com/rust-lang/cargo/pull/5183#issuecomment-381449546

                                                                                                              I’m not familiar with Rust, so maybe I’m missing crucial context, but I read this feedback as firm but unproblematic overall. Compared to Linus’ email:

                                                                                                              • Comment admits that there are multiple points of view, gives case for their take on it.
                                                                                                              • Focuses on the problems at hand rather than speculating on characteristics of any individuals involved, beyond acknowledging other viewpoints.
                                                                                                              • Doesn’t include any personal insults.
                                                                                                              • Doesn’t include any profanity that I noticed, certainly not gratuituous profanity.

                                                                                                              It could be nicer, sure. But it seemed respectful, in the “you can do what you’re doing but consider these things:” kind of way…? The author event went out of their way to acknowledge being unconstructive.

                                                                                                              To my reading it seemed closer to Gary’s email than Linus’.

                                                                                                              To put it another way: if Linus wrote emails like this (only shorter, probably) then I don’t think Gary would have written a blog post about it.

                                                                                                              (For the record: I’m not American, but I do fall on the gee-it’d-be-great-if-Linus-stopped-abusing-his-colleagues side of this debate.)

                                                                                                              1. 1

                                                                                                                I didn’t intend to imply that this was comparable to Linus’ mail, but that people who would be offended by Linus’ writing would also be offended by that comment.

                                                                                                                It’s a slippery slide where every honest-to-go comment that expresses real feelings starts getting replaced by “this is an interesting idea, but did you consider …” corporate lingo, even if the code is horribly wrong.

                                                                                                                1. 2

                                                                                                                  I didn’t intend to imply that this was comparable to Linus’ mail, but that people who would be offended by Linus’ writing would also be offended by that comment.

                                                                                                                  I understand this is your point, but I think there is no evidence for this. The people complaining about Linus’ conduct are complaining about specific things, and these things are not present in the comment you linked.

                                                                                                                  Did anyone in the Rust community (generally considered a “nicer” community than kernel development) raise concerns about this comment?

                                                                                                                  There is a difference between “not overtly nice” and “openly abusive”, even accounting for cultural context.

                                                                                                              2. 1

                                                                                                                Then you and I arent that different in how we look at stuff. Ive just layered on top of it a push for project owners to do what’s most effective on social side.

                                                                                                          2. 2

                                                                                                            I believe it’s intentional. He does not want to be bothered by nurturing the newbs, so he deters them from going to him directly and forces them to do their learning elsewhere.

                                                                                                          3. 2

                                                                                                            These numbers suggest it is a professional endeavor:

                                                                                                            https://thenewstack.io/contributes-linux-kernel/

                                                                                                            1. 2

                                                                                                              Those numbers just break down the professionals involved, and don’t consider the volunteers. If you sum the percentages in that article you get around 40%. Even accomodating for smaller companies that didn’t make the top N companies, that’s a pretty big discrepancy.

                                                                                                    2. 6

                                                                                                      Linus himself is working in a professional capacity. He’s employed by the Linux Foundation to work on Linux. The fact he is employed to work on an open source project that he founded doesn’t make that situation non-professional.

                                                                                                1. 5

                                                                                                  I did this in Python recently, maybe someone will find it interesting:

                                                                                                  https://git.sr.ht/~sircmpwn/srht/tree/srht/markdown.py#n55

                                                                                                  1. 4

                                                                                                    The global menu bar issue is something I deeply care about. Linux has a very good global menu bar, but people either are moving away from it or do not know that it is available. Just use Ubuntu 16.04 and see in action.

                                                                                                    Since 2014 Ubuntu modified GTK and Qt so that all desktop applications made use of a global menu bar. Everything works now perfectly. Ubuntu 16.04 with the default Unity desktop is a very usable desktop. All my non-techy acquaintances like it. These modifications have, however been refused upstream, because they do not fit the GNOME 3 paradigm (most of which I like).

                                                                                                    I really do not understand why people are against global menus. They are better, scientifically proven better. And they save a lot of vertical space, that in modern super-wide monitors is a precious resource.

                                                                                                    Why doesn’t the global menu bar receive the love it deserves?

                                                                                                    1. 2

                                                                                                      They are better, scientifically proven better

                                                                                                      Citation needed

                                                                                                      1. 3

                                                                                                        From Fitt’s law [1] and Steering Law [2] comes that global menu bars are much easier to access.

                                                                                                        Fitt’s law tells you that global menu bars are better because they can be reached by moving the cursor to an infinitely big target [3]. In other words, you can throw your mouse pointer somewhere up and it will surely and easily reach global menu bar.

                                                                                                        Steering Law tells you navigating along/inside a vertical or horizontal tunnel is hard if the tunnel is thin (hello badly implemented JS menus that disappear when you move to a submenu). In the case of a global menu bar navigating it is easy because it is infinitely tall, just push your cursor slightly up.

                                                                                                        Global menu bars are easier to access, but are they faster to access? This a good question, because, on average, the global menu bar is farther away than the local menus. It turns out that, on average, they are equally fast to access. [4] Windows requires more aiming precision (slower) but less travel distance (faster). MacOS requires less aiming precision (faster) but more travel distance (slower).

                                                                                                        All things being equal, simplicity should always preferred, because it means that more people can fruitfully use a system, for example people with disabilities.

                                                                                                        1. P.M. Fitts: The information capacity of the human motor system in controlling the amplitude of movement. J. Exp. Psychol. 47, 381–391 (1954)
                                                                                                        2. J. Accot, S. Zhai: Beyond Fitts’ law: Models for trajectory-based HCI tasks. In: CHI 1997: Proceedings of the SIGCHI conference on Human factors in computing systems, pp. 295–302. ACM, New York (1997)
                                                                                                        3. A. Cockburn, C. Gutwin, S. Greenberg: A predictive model of menu performance. In: CHI 2007: Proceedings of the SIGCHI conference on Human factors in computing systems, pp. 627–636. ACM, New York (2007)
                                                                                                        4. E. McCary, J. Zhang. GUI Efficiency Comparison Between Windows and Mac. In: HIMI 2013: Human Interface and the Management of Information. Information and Interaction Design pp 97-106, Springer (2013)
                                                                                                        1. 1

                                                                                                          This makes sense, thank you for the detailed response.

                                                                                                      2. 2

                                                                                                        how does it play with focus modes other than click-to-focus? e.g. in focus-follows-mouse, if you have to move your cursor through another window en route to the global bar, it would rebind to the new application.

                                                                                                        1. 2

                                                                                                          Focus-follows-mouse has a delay before switching applications. Move across fast, no app switching. Or go around (fairly easy with non-overlapping windows).

                                                                                                          1. 1

                                                                                                            I haven’t tried these global menus in Linux, as an Enlightenment user, but how long ia the delay and is it configurable?

                                                                                                            I’d tie it to motion, because I appreciate my desktop being fast and all kinds of stalls annoy me. I’d imagine this to be very true if I have to touch a pointer device.

                                                                                                            1. 1

                                                                                                              It appears to be a hard-coded 25ms delay, at least in GNOME shell. Others may implement it differently.

                                                                                                      1. 6

                                                                                                        Much simpler solution that often might be enough is xxd -i.

                                                                                                        1. 4

                                                                                                          Author of koio here.

                                                                                                          objcopy is another simpler, good choice. I need koio to provide a stdio-like API and a consistent external baseline for how embedding files is done in chopsui so that it can be consistent between chopsui, third-party chopsui libraries, chopsui applications, and end-user extensibility. To that end I found it more appropriate to write a tool like this.

                                                                                                        1. 4

                                                                                                          I’d like to spend one single day watching @SirCmpwn working. I don’t understand how someone with a regular job can get so much done in their free time.

                                                                                                          Keep up the work the great work! I’ll definitely migrate to sway as soon as the porting to wlroots is finished.

                                                                                                          1. 4

                                                                                                            I don’t understand how someone with a regular job can get so much done in their free time.

                                                                                                            With lots of help!

                                                                                                          1. 3

                                                                                                            It takes an awful lot of reading to work out what wlc even is. Even then I’m still not sure what it (or it’s replacement) does!

                                                                                                            1. 5

                                                                                                              Author here. There are links in the article to each project that describe what they are, but…

                                                                                                              Wayland is a replacement for X11, which are two protocols used for graphical sessions on Linux and other Unicies. wlc and wlroots are both libraries that implement some of the functionality a Wayland server needs.

                                                                                                            1. 7

                                                                                                              Why not just directly write man(7), which is all this tool produces? Or use the existing perlpod, pandoc, docbook, lowdown, rst2man, or any other tool doing exactly the same thing from diverse formats?

                                                                                                              Because I’m sure the world needs more opaque, un-indexable manpages.

                                                                                                              (Edit: to clarify, use mdoc(7).)

                                                                                                              1. 5

                                                                                                                Author here. Did you even read the blog post? I answered all of these questions.

                                                                                                                perlpod is built on a mountain of perl, and pandoc on a mountain of haskell. lowdown is a Markdown implementation, and Markdown and roff are mutually exclusive. RST and roff are mutually exclusive. I spoke about docbook directly in my article (via asciidoc, which is a docbook frontend). I also directly addressed mdoc.

                                                                                                                Man pages are already being indexed. If you search the web for “man [anything]” you’ll find numerous websites which scrape packages and convert the roff into HTML.

                                                                                                                1. 1

                                                                                                                  Thanks for your hack. It’s a good candidate for a port in my little os.

                                                                                                                  A couple of question:

                                                                                                                  • have you considered to avoid the bold markers around man page refs as you already have the parentheses to identify the reference?
                                                                                                                  • also section titles have conventional names: what about omitting the starting sharp to mark them as titles?
                                                                                                                  • what about definition lists? (I know they are an HTML thing, but they can be useful to describe options for example)
                                                                                                                  • I know tables are the most difficult format to express in a readable source form, but what alternatives did you considered and why you discarded them?

                                                                                                                  And btw… Thanks again!

                                                                                                                  1. 2

                                                                                                                    Glad you like it!

                                                                                                                    have you considered to avoid the bold markers around man page refs as you already have the parentheses to identify the reference?

                                                                                                                    This is an interesting thought. https://todo.sr.ht/~sircmpwn/scdoc/12

                                                                                                                    also section titles have conventional names: what about omitting the starting sharp to mark them as titles?

                                                                                                                    I’m not fond of this idea. Given that lots of man pages will need to have section titles which fall outside of the conventinoal names, and that I want all headers to look the same, this isn’t the best design imo.

                                                                                                                    what about definition lists? (I know they are an HTML thing, but they can be useful to describe options for example)

                                                                                                                    man pages do “definition lists” with borderless tables, which are possible to write with scdoc like this

                                                                                                                    |[ *topic*
                                                                                                                    :[ definition
                                                                                                                    |  *topic
                                                                                                                    :  definition
                                                                                                                    # etc
                                                                                                                    

                                                                                                                    I know tables are the most difficult format to express in a readable source form, but what alternatives did you considered and why you discarded them?

                                                                                                                    The main approach I’ve seen elsewhere is trying to use something resembling ascii art to make tables look like tables in the source document. I’ve never been fond of this because you then have to do annoying edits when updating the table to keep all of the artsy shit intact, which in addition to being just plain annoying can also bloat your diffs, lead to more frequent merge conflicts, etc.

                                                                                                                    An alternative some formats have used is to make aligning your columns optional, but still using an artsy-fartsy kind of style. I figure that if you’re going to make aligning the columns optional you no longer have any reason to require a verbose format like that. So I invented something more concise.

                                                                                                                    Also, the troff preprocessor used for tables supports column alignment specifiers and various border styles, which I wanted to expose to the user in a concise way. Other plaintext table formats often have this feature but never concise.

                                                                                                                    1. 1

                                                                                                                      man pages do “definition lists” with borderless tables

                                                                                                                      Do you think you could render something like this with scdoc in a source-readable way http://man7.org/linux/man-pages/man8/parted.8.html (see section OPTIONS and COMMAND)?

                                                                                                                      The main approach I’ve seen elsewhere is trying to use something resembling ascii art to make tables look like tables in the source document.

                                                                                                                      Actually it was what I was thinking about. You propose a good point, but my counter argument is that manual pages are (hopefully) read more often then they are written. But I admit that my goal is people using cat to read manual pages by default, so I can see how in a more conventional system using Troff the people most often read a rendered page, thus the annoyance is pointless. OTOH, it should be relatively easy to write a tool that take scdoc document as input and output another scdoc document where tables are automatically aligned, removing the annoyance to align the cells while writing.

                                                                                                                      Having said that, I find your table syntax nice.
                                                                                                                      I wonder if one could nest tables (I mean put a table in a cell). Also, you organize the table by rows, but given the format, some table might benefit from being organized by column.

                                                                                                                      1. 2

                                                                                                                        Do you think you could render something like this with scdoc in a source-readable way http://man7.org/linux/man-pages/man8/parted.8.html (see section OPTIONS and COMMAND)?

                                                                                                                        You don’t actually even need tables for this. scdoc preserves your indent. https://sr.ht/I0g7.txt

                                                                                                                        I wonder if one could nest tables (I mean put a table in a cell). Also, you organize the table by rows, but given the format, some table might benefit from being organized by column.

                                                                                                                        I think nested tables is a WONTFIX. Also not sold on column-oriented tables. IMO man pages should be careful to keep their tables fairly narrow to stay within 80 characters.

                                                                                                                        1. 1

                                                                                                                          Wow, that’s really readable!

                                                                                                                          Fine for nested tables. Just to be sure I explained what I meant by column-oriented (that just like nested tables might or might not be a good idea): suppose you want to create something like

                                                                                                                          English    Italian    Swahili
                                                                                                                          Hello!     Ciao!      Habari?
                                                                                                                          Tour       Viaggio    Safari
                                                                                                                          Lion       Leone      Simba
                                                                                                                          

                                                                                                                          You might prefer a syntax like

                                                                                                                          |[ English
                                                                                                                          :[ Hello!
                                                                                                                          :[ Tour
                                                                                                                          :[ Lion
                                                                                                                          |[ Italian
                                                                                                                          :[ Ciao!
                                                                                                                          :[ Viaggio
                                                                                                                          :[ Leone
                                                                                                                          |[ Swahili
                                                                                                                          :[ Habari?
                                                                                                                          :[ Safari
                                                                                                                          :[ Simba
                                                                                                                          

                                                                                                                          Or even, for such a simple table (that I don’t know if actually exists in a man page, so…), you could put each column (or row) in the same line:

                                                                                                                          |[ English :[ Hello! :[ Tour :[ Lion
                                                                                                                          |[ Italian :[ Ciao! :[ Viaggio :[ Leone
                                                                                                                          |[ Swahili :[ Habari? :[ Safari :[ Simba
                                                                                                                          

                                                                                                                          (that a tool could easily turn into:

                                                                                                                          |[ English :[ Hello!  :[ Tour    :[ Lion
                                                                                                                          |[ Italian :[ Ciao!   :[ Viaggio :[ Leone
                                                                                                                          |[ Swahili :[ Habari? :[ Safari  :[ Simba
                                                                                                                          

                                                                                                                          )

                                                                                                                          Ok… now I’ve really annoyed you enough for a single night… good work!

                                                                                                                2. 5

                                                                                                                  Because you cannot have progress without research.

                                                                                                                  Now troff is not readable in source form.
                                                                                                                  This is better in this regard. You are right about indexing, but the project have a very short log. I guess we can talk about it with the author, and see what he think about that.

                                                                                                                  Maybe he like the idea, and add it. Or he doesn’t, and will not add it.
                                                                                                                  You will always be able to fork it and fine tune to you need.

                                                                                                                  I’m grateful to hackers who challenge the status quo.

                                                                                                                  1. 4

                                                                                                                    While mdoc(7) is great (thanks for that!) , I think your questions are answered on the page. I think lowdown is probably the closest to what u/SirCmpwn was aiming for (no dependencies, man output), maybe they hadn’t seen it?

                                                                                                                    Man formatting is inscrutable to the un-trained eye (most people), and we need to acknowledge the popularity of markdown is related to its ease of reading/writing.

                                                                                                                    1. 4

                                                                                                                      I think your questions are answered on the page. I think lowdown is probably the closest to what u/SirCmpwn was aiming for (no dependencies, man output), maybe they hadn’t seen it?

                                                                                                                      groff (as installed on every Linux distribution that uses groff for man pages, which is basically all of them, and macOS) has had native support for mdoc for at least a decade. If you install an mdoc man page and then man $thepage, you get exactly what you expect.

                                                                                                                  1. 5

                                                                                                                    This is neat! I’ve been looking for a man page generator. I also use asciidoc and have had toolchain issues with it, particularly on macOS.

                                                                                                                    I perused the source code a bit since I was curious about the combination of “no dependencies” and “UTF-8 support.” What, exactly, do you mean by UTF-8 support?

                                                                                                                    I see you hand rolled your own UTF-8 handling, but what I don’t quite understand is why you did it in the first place. What I mean is that your parser only seems to care about ASCII, and you never actually take advantage of UTF-8 itself with one obvious exception: if the data you read isn’t valid UTF-8, then your parser sensibly gives up. Is there some other aspect of UTF-8 you’re using? Perhaps I’ve skimmed your code too quickly and missed it.

                                                                                                                    I do see that you’re using the various POSIX char functions such as isdigit and isalnum, but those operate based on POSIX locale support, and aren’t, as far as I know, aware of the various Unicode definitions of those functions. Moreover, the documentation for those functions states that it is UB to pass a value that cannot be represented in an unsigned char.

                                                                                                                    I’m not a C expert, so I could be missing something pretty basic!

                                                                                                                    1. 3

                                                                                                                      Hey, thanks for your feedback!

                                                                                                                      I perused the source code a bit since I was curious about the combination of “no dependencies” and “UTF-8 support.” What, exactly, do you mean by UTF-8 support?

                                                                                                                      Yeah, supporting it wasn’t too hard. I probably don’t have to explicitly handle it, but I prefer to enforce all input files must be UTF-8 and all output files must be UTF-8 rather than leave wiggle room. One intentional design decision of scdoc is that it is very strict - it will error out if you try to write #header instead of # header, for example. Enforcing UTF-8 is another form of strictness that ensures all scdoc files have a baseline of sanity.

                                                                                                                      I do see that you’re using the various POSIX char functions such as isdigit and isalnum, but those operate based on POSIX locale support, and aren’t, as far as I know, aware of the various Unicode definitions of those functions. Moreover, the documentation for those functions states that it is UB to pass a value that cannot be represented in an unsigned char.

                                                                                                                      I should probably enforce that characters I feed into this are <0x80. Good catch, filed a bug:https://todo.sr.ht/~sircmpwn/scdoc/13

                                                                                                                      1. 2

                                                                                                                        Ah, yeah, that makes sense. Starting with strict validation on UTF-8 is smart. :-)