1. 2

    I would find it a little unsettling to have such a powerful MCU in my keyboard. It’s part of what’s kept me out of the custom mechanical keyboard scene so far. I’d like my input devices to be as dumb as possible, at least to the point of being incapable of being used as a keylogger.

    1. 6

      Most keyboards likely have absurdly overkill microcontrollers on them anyway; I’d rather control it rather than someone else.

      1. 2

        Bluetooth is another can of worms altogether, but there’s no economic incentive to put such a costly part on a cheap USB keyboard that’s not programmable in the first place. So, I doubt it.

        On the other hand, it’s much easier to develop flexible firmware for a variety of physical configurations with an overpowered general-purpose MCU and its toolchain. And the economics of open source make DIY experimentation and low-volume manufacture much easier. So I understand why QMK exists… but if I ever make my own keyboard, it won’t have fancy LEDs or USB-C, and it damn sure won’t have RAM. (shaking fist at cloud)

        1. 5

          if I ever make my own keyboard, it won’t have fancy LEDs or USB-C, and it damn sure won’t have RAM

          Out of curiosity, have you ever tried to code something in two and a half kilobytes of memory? Because that’s what the ATmega32u4 has, which is the most popular chip QMK is used on. QMK also works with the ATtiny85, which has five hundred and twelve bytes of RAM. (Fun fact: that’s less than the number of bytes in this comment.)

          I wrote a Forth implementation for the atmega32u4 chip, because I heard that Forth is famous for working well in low-resource situations: https://github.com/technomancy/orestes Once the Forth booted, I got it loading my program in, and it got about twenty lines of code loaded before it exhausted the RAM.

          I’m not saying it’s impossible to do anything nefarious, but at that point there are much easier ways to inject a keylogger. If I were you I’d draw the line at networking instead of RAM.

          1. 3

            Yeah, the no-RAM thing is kind of an unreasonable restriction for a programmable device. I regret my little outburst. As I say elsewhere, all I really want is for the programming interface to be physically separated from the keycode interface.

            It’s quite impressive that QMK would work with such a modest 8-bit MCU. The ATtiny looks like a pretty good candidate for my low-end aesthetic. Thanks for the tip!

            EDIT: Wait, can you give me a link to QMK on ATtiny85? It’s looking less plausible since the docs say STM32 and ARM exclusively, and then Reddit says No. Bit-banging USB doesn’t seem like a great idea anyway.

            Now I’m genuinely curious what is the lowest-spec MCU that can both speak USB HID (seems like the harder part) and scan a key matrix (which looks pretty easy, given enough pins). I don’t need any of the fancy QMK features, and I’d enjoy the size-coding challenge. No need for a Forth runtime, ASM would be fine for an application like this.

            1. 3

              Wait, can you give me a link to QMK on ATtiny85?

              https://github.com/qmk/qmk_firmware/pull/9371

          2. 1

            Bluetooth is another can of worms altogether

            Bluetooth implies latency, so I wouldn’t go anywhere near it. Even ignoring it’s wireless and I don’t trust it to be secure.

            it’s much easier to develop flexible firmware for a variety of physical configurations with an overpowered general-purpose MCU and its toolchain.

            Microcontrollers that are common today are, even at the low end, of course going to be overpowered for the purpose.

            1. 2

              Even the something like the MSP430 is overpowered… but that’s probably what I’d use, because it’s cheap, very low power, with a reasonable open source toolchain. I’m sure it’s possible to go lower than that, but USB HID isn’t something I would want to do from scratch. I suppose a PS/2 keyboard would be simpler.

              Really all my paranoia requires is that the device isn’t programmable over the same physical interface that it sends keycodes. Beyond that it’s just aesthetics… and of course latency.

              1. 1

                msp430 overpowered

                Indeed it’d be. msp430 is a nice 16bit µarch with very power efficient implementations, but avr8 is 8bit (!) and sufficient. I imagine older keyboards have z80, 8085 and the like in them.

                Really all my paranoia requires is that the device isn’t programmable over the same physical interface that it sends keycodes.

                There’s indeed a USB firmware update standard, which would be nice to support, as long as flashing needed some switch turned on, or some special handshake like holding some keys while plugging keyboard in, to force it into some flashing mode in the bootloader.

        2. 4

          Pretty much any keyboard that can connect via USB has enough capacity to have a keylogger in the firmware. For some values of keylogger, at least… a tiny thing that sends the pressed keys over on rawhid needs very little resources, and the host-side of it can appear pretty harmless too. If your keyboard supports being configured via a GUI on the fly, then whatever protocol is used for communication, can be used for keylogging as well.

          The best way to avoid a keylogger, is to run open source firmware, and lock your MCU down so that flashing new firmware will require an action from you (ie, you must not be able to jump to the bootloader from within the firmware).

        1. 5

          My daily driver is a Keyboardio Model01, the best keyboard I ever owned. The camera mount is amazing for tenting, and the palm keys are incredible. The custom keycaps - while they do limit your options - are a joy to type on.

          I also have a number of other keyboards for different purposes. For gaming, I use a Dygma Raise and an Azeron Classic. I usually use the Azeron (though I still need to port my firmware of choice to it, it’s default one is meh), but when I need more keys, I fall back to the Raise.

          (I also have a few ErgoDox EZs, an original Atreus, a Keyboardio Atreus, a Planck EZ, Splitography, Ginni, and a KBD4x, off the top of my head. The Planck EZ is my wife’s, Splitography is for Steno, the rest are currently unused.)

          1. 2

            Thank you, Algernon, for all the work you’ve put in on the software for the Model01 and Dygma Raise.

            As for OPs question, on my own keyboard journey, after years of using stock keyboards, then an entry level keyboard with cherry mx browns (to try mechanical switches), then a Mistel Barocco (to experience split layout — which I now can’t live without). I was given a Keyboardio Model01, but had a hard time with the ortholinear key layout and I didn’t have the time to relearn. I was going to get a Kinesis Edge Gaming, but preordered the Dygma Raise instead because of its full programmability.

            The Dygma Raise checks all the boxes for me:

            • mechanical switches
            • split
            • fully programmable (Sticky Keys!)
            • normal key layout (nothing to relearn)

            Plus it has:

            • thumb buttons
            • built in wrist rests
            • so many LEDs (useful to know which later you’re on)
            • can be used with only one side plugged in (for gaming mostly)
            • a WIP tenting solution

            I recommend checking out the Dygma Raise (even if you don’t play games, I bought it primarily for programming).

            And if not the Raise, in general, I very strongly recommend a split keyboard… your wrists and shoulders will thank you.

          1. 2

            Now I need to find someone who can build one of these for me… so I can port Kaleidoscope to it. For science!

            1. 2
              • A bunch of static sites
              • Two writefreely instances
              • One NodeBB forum
              • One single-user Wordpress
              • Nextcloud (for file sharing and bookmarks, primarily, but trying to make better use of it still)
              • Bitwarden
              • Gitea
              • Drone for my CI needs
              • My own email (postfix, rspamd, dovecot, roundcube to top it off)
              • DNS for some of my domains
              • XMPP for the family (Prosody)
              • Mastodon for myself & a few friends
              • ZNC
              1. 3

                A language is viable for production as soon as someone is crazy enough to put it there, and commit to keeping it there.

                A lot depends on where “production” is. Is it something you put on your home server? An important piece of infrastructure at home, but if anything breaks or goes down, nothing really serious happens. It’s still “production”, though. Putting something on thousands of on-premise devices that are never going to be updated is another end of the production spectrum, with very different requirements.

                Mind you, I’ve put immature languages onto both, with great success.

                1. 3

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

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

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

                  AMA I guess…

                  1. 3

                    I feel like it would be difficult to type on this if the two parts weren’t always the same distance apart and at the same angle of rotation. Do you find that you’re constantly making micro-adjustments to get the two parts into your preferred position?

                    1. 3

                      No, I actually sometimes move them apart to have stuff like documents, a notepad, or food between them. I can use them In lots of distances, as long as the angles of my wrists are right, which you can adjust on the fly.

                    2. 2

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

                      1. 3

                        I like that in QMK I can easily remap keys and create new functions on layers. They have an online configurator where you can edit the layout to your liking and get a new firmware binary: https://config.qmk.fm/#/ergodash/rev1/LAYOUT

                        You can also edit the layout locally and compile it yourself, some advanced functions are not available in the configurator.

                        I have used many ready made keyboards before, but liked the idea of the ergodash. I’m very happy with these keyboards so far.

                      2. 2

                        Can you report on how painful it is to have the {/} and [/] keys split between the left half and the right half?

                        I experimented with similar designs here, but I was always concerned about this issue.

                        1. 2

                          I have them somewhere else. I have them on a layer on P and the button to the right of it. I press the layer button on the left half, then P and the button to the right of it are [].

                          This works nicely for me. In general I have my layout set up so that it’s always the opposite hand pressing the layer button (i.e. left hand switching layers for the right hand and vice versa).

                          If you’re interested, my config.json is here: https://gitlab.com/youRFate/keymaps/blob/master/ergodash/layers.json

                          You can dl it and plug it into https://config.qmk.fm/ to see the layers etc.

                          1. 2

                            I have ([{/}]) on separate hands, it needs a little getting used to, but once that happens, it’s very, very nice to have them that way.

                            It’s only a problem when one of your hands is mousing, but for that, I have a trackball between the halves, so very little hand movement is required between keyboard and ball, and thus, no real issue with hitting either part of the pair.

                        1. 2

                          I’ve had very nice discussions on the Fediverse, about all kinds of things (unlike on twitter). I’m also on a tiny, personal instance, so the local timeline is nigh useless, because its me, my bots, and a friend of mine.

                          Nevertheless, I’m @algernon@trunk.mad-scientist.club, and I post about mechanical keyboards, their firmware, parenting, self-hosting things, and whatever else I feel like. There’s no real theme or purpose, it’s a loudspeaker I shout random things into, and sometimes people shout back and we have a great time.

                          1. 1

                            I think that’s how I discovered the Dygma Raise project, which you’re kinda involved with. Hopefully they’ll manage to ship keyboards this quarter… 😁

                            Mastodon’s nice for that. Of course, it could happen as well on Twitter, or Facebook, but I feel that I’ve discovered more things than on big advertisement silos, where the platform aims at maximizing buzz rather than serendipity.

                            I’m oz@mastodon.social BTW.

                          1. 1

                            Some thoughts:

                            Git is also incredibly opinionated about how you should work with e-mail: one mail per commit, nicely threaded, patches inline.

                            This is because it was made for the kernel project. You can easily modify this behavior with scripting.

                            Collaboration includes receiving feedback, incorporating it, change, iteration

                            With e-mail this is well, via e-mail, who anyone can set up as they want (and likely already have)

                            I wasn’t subscribed at the time, and the mailing list software silently dropped every mail

                            This is incredibly bad. I really think mailing list software and mail servers are to blame: if you aren’t subscribed, you should get a confirmation of success or failure. If you are classified as spam, the mail should not be delivered and thus get a notice back.

                            Having to subscribe to a list to meaningfully contribute is also a big barrier: not everyone’s versed in efficiently handling higher volumes of e-mail (nor do people need to be).

                            Again I think this is the mailing list software’s fault. Most are ancient and are not designed with this workflow in mind. Ideally you should have subscription options (only get updates to your threads, or threads you are active in, etc) with sane defaults.

                            In all of these cases, I had no control. I didn’t set the mailing lists up, I didn’t configure their SMTP servers. I did everything by the book, and yet…

                            Not that you are wrong at all, but I feel the need to add that it is also true about forges!

                            Patches never arrive out of order and with delays

                            If patches are prefixed with [PATCH v1 0/7] the mailing list should queue them up to guarantee in order and without delays between them delivery.

                            have easy access to all discussions, all the commits, all the trees, from the comfort of your IDE

                            I agree this is better than looking through your list archives or online ones. But there could be a tooling solution for that.

                            No need to care about SMTP, formatting patches, switching between applications and all that nonsense.

                            Forges make the boring, tedious things invisible.

                            Tooling can be distributed within the repository if the project chooses this workflow.

                            I think all in all the problems you saliently describe are the fault of (1) lack of appropriate software to assist the workflow (2) lack of effort to support the workflow from the maintainer’s side. Ideally I would like a forge-mailing list that supports both workflows with the features I suggested above because not everyone is a power user but most people eventually turn into one.

                            1. 4

                              This is because it was made for the kernel project. You can easily modify this behavior with scripting.

                              Tell that to a newbie, and see them run away never to be seen again.

                              If you are classified as spam, the mail should not be delivered and thus get a notice back.

                              Alas, that’s now how many systems work in practice. It would be nice if they did, but they don’t, and I have zero control over that.

                              Not that you are wrong at all, but I feel the need to add that it is also true about forges!

                              The difference is that I have not come across a forge yet that let me submit invalid PRs or issues, sat on it for hours, and (at best) mailed me a response much later. I have had e-mail issues countless times on the other hand.

                              If patches are prefixed with [PATCH v1 0/7] the mailing list should queue them up to guarantee in order and without delays between them delivery.

                              No list does that currently, as far as I’m aware. Probably because it would be so very easy to abuse it: make sure some of the series is spammy, so it gets held up, or even rejected, and never send a good replacement. The mailing list keeps the rest queued, wasting resources. You can, of course, combat this by expiring stuff after a while, or building various abuse prevention methods into the mailing list software, but then we’re building workarounds again, instead of using purpose-built tools which don’t even have this problem.

                              Sending patches attached would solve 90% of the problems listed in the blog post, yet, core git doesn’t support that.

                              But there could be a tooling solution for that.

                              Could be, but there isn’t, even though e-mail and the desire to use it for All Kinds Of Stuff has existed for far longer than the Forges. Yet, noone built anything like the forges over e-mail, until Sourcehut, very recently.

                              Tooling can be distributed within the repository if the project chooses this workflow.

                              Uhm, yeah, no. You’ll never be able to support IDE integration at the level magit/forge (and many other integrations do) that way. You may be able to support an IDE or two. With a Forge that has an API, IDEs can support the Forge, and have it work for all projects using that forge. Resources far better spent.

                              1. 1

                                Uhm, yeah, no. You’ll never be able to support IDE integration at the level magit/forge (and many other integrations do) that way.

                                Yes I know, I was talking about e-mail. :)

                                Your other points can be summed up as “no software that does this exist” and this was exactly my point: it’s basically lack of appropriate & user-friendly tooling that makes e-mail version management so difficult for unaccustomed users. This is a problem the community should solve. I’m not sure if the git maintainers would accept such patches, but it’s worth trying.

                              2. 3

                                What you are describing is not a bad thing, but you’re not really doing email at that point. You’re designing a Code Forge Peering Protocol, and you just happen to have built it on top of SMTP.

                                I’ve been horribly tempted to do just that, by taking git-am/sr.ht’s email behavior and designing a forge that speaks the same protocol but bridges it with a pull request based web UI. You could fork a repository from any git:// URL, submit a “pull request” by sending email to whichever email list the project uses, and we would provide an email address for you that’s only used for code review (and, thus, only accepts replies, not unsolicited messages, because we don’t want to do anti-spam heuristics if we can avoid it). All of this could be done entirely through your browser, though you could clone your fork and do local work exactly like GitHub does. The only part where I’d have to do even remotely novel work would be in providing a good UI for git rebase -i, so that you could appropriately convert your in-progress commits into a good patchset that the ever-picky project owner would accept, again without forcing you to touch the git CLI.

                                And since we directly know that all incoming unsolicited emails must be patchsets, we could both do the queueing work that you describe to ensure that patchset submission is atomic, and we could reject 99% of incoming spam instantly.

                                Alas, not nearly enough hours in the day to build everything that I’m horribly tempted to build.

                                1. 1

                                  providing a good UI for git rebase -i, so that you could appropriately convert your in-progress commits into a good patchset that the ever-picky project owner would accept, again without forcing you to touch the git CLI.

                                  Wait, do existing web-based git management things (git{lab,hub}, sr.ht, etc?) provide a way to interactively rebase? I think having everything else you proposed would be amazing.

                                  1. 1

                                    Hm I don’t think that’s possible on the web, since you have no way to resolve conflicts unless you startup a web editor. However you can do it with git “clients”, ie wrappers around the command line.

                                    1. 1

                                      Yea I didn’t think so, which is why I was a bit confused to see GP basically say “I could implement everything but I cannot implement this one thing that no one else has so I won’t implement any of it” (my rough paraphrasing)

                                  2. 1

                                    You’re designing a Code Forge Peering Protocol

                                    Yeah, just like mailing lists are a discussion forum on top of SMTP.

                                    If you ever want to start this thing together send me a message :).

                                    (By the way, I’ve a tool like your ammonia project. I use it as a filter for html view in a cli MUA i’m working on.)

                                1. 8

                                  Find the message ID to reply to. [switch to a browser, navigate to the archives page, find the thread in question, expand the details section, select the ID, copy it, and paste it into your terminal]

                                  It seems like the whole point of sourcehut is to allow for a collaborative flow with git which lets you stick with your comfortable tools instead of having everything center around a web application. This section (apart from being very tedious) seems to imply the opposite.

                                  Meanwhile:

                                  Some people think that they can get away with sending patches through some means other than git send-email, but you can’t.

                                  You know what mail clients are really good at? Saving you the hassle of having to track down message IDs manually like some kind of cave-person! Instead of stating that it’s completely impossible to use a real mail client to send a patch (which is obviously not true) why not explain why most mail clients are bad at it?

                                  1. 8

                                    The web interface is my comfortable tool. I had a patch for Sourcehut and I literally just gave up on submitting it because of how big a PITA it was to submit. Email is terrible, I really don’t want a workflow based on email.

                                    1. 8

                                      I literally just gave up on submitting it because of how big a PITA it was to submit

                                      That’s probably why SirCmpwn made a tutorial. ;P

                                      I personally agree with you about GUIs. I think terminals are garbage for any kind of low cardinality discovery-based workflow. If I know where I’m going and what I’m doing, terminal. If I’m looking through a few different things, or I’m not quite sure what I’m looking for, GUI. If I’m looking for / operating on a gajillion things, back to the terminal.

                                      By most metrics I’m a terminal power user, but “fear of mice” is not one of them. If you’re fast and accurate with a mouse, no reason not to use one.

                                      1. 5

                                        That’s probably why SirCmpwn made a tutorial. ;P

                                        A tutorial is nice, but what I really dislike is that I’ll do the configuration once then not touch it for months (and forget how it works) until one day it breaks as I’m trying to use it. It’s the same reason I don’t run my own web or email server: I really, really don’t want to increase my “sysadmin” burden.

                                        That being said, kudos to him for making it easier for people who were more “on the fence” than myself. But personally I’ll wait for the web interface :-)

                                        1. 4

                                          “By most metrics I’m a terminal power user, but “fear of mice” is not one of them. If you’re fast and accurate with a mouse, no reason not to use one.”

                                          Now that’s a great philosophy for UI’s. :)

                                      2. 1

                                        This section (apart from being very tedious) seems to imply the opposite.

                                        It doesn’t imply the opposite, it’s basic awareness by the author. Those instructions are universal and easy, all kinds of readers will follow along just fine. If you care deeply about avoiding a web interface, you probably know how to find the Message-ID header in your mail client on your own. If you don’t, figure it out on your own. It’s not important to this tutorial.

                                        You know what mail clients are really good at? Saving you the hassle of having to track down message IDs manually like some kind of cave-person!

                                        What’s your point? Does your mail client automatically populate replies to threads with your updated commits? No. So why complain about git send-email not automatically populating Message-ID? You’re copying something somewhere either way. Between the two, copying Message-ID is a lot less error prone.

                                        Instead of stating that it’s completely impossible to use a real mail client to send a patch (which is obviously not true) why not explain why most mail clients are bad at it?

                                        Okay again, this is a tutorial. And the implication here is obvious too. If you are reading a beginner tutorial about mailing patches, you clearly don’t know anything so just use the damn tool that stops you from mailing malformed garbage to a ton of people. It’s way out of scope and anyone that cares can easily go read more elsewhere.

                                        For anyone who actually does want to know, instead of just bitch: a mailed git patch isn’t just a diff, it’s an entire commit serialized into an email. That serialization is extremely fragile since leading whitespace and single newlines have meaning for patches, but for email they don’t.

                                        When you say “most” mail clients are bad at it, you’re probably thinking of Gmail, Apple Mail, Outlook, and so on. And yes, it is literally impossible to make the Gmail web interface handle patches correctly. But you probably didn’t guess that neither Alpine nor Mutt handle patch emails correctly without multiple configuration changes. All mail clients screw it up.

                                        All. Of. Them.

                                        Use git send-email.

                                        1. 1

                                          All mail clients screw it up.

                                          All. Of. Them.

                                          Had no problems generating a patch with git am, copying it with xclip and pasting it into Thunderbird. As long as you make sure word-wrap is off everything is fine.

                                          1. 5

                                            I don’t think this is actually true; I imagine that even tho it worked in some cases it doesn’t guarantee it will work in others, and that further configuration is required for it to work consistently. (For instance, for some patches it’s important that the MUA preserve trailing whitespace.)

                                            But that just illustrates my point: if you tell people something that’s obviously false like “you cannot send patches with a MUA” without giving any details, they’re going to ignore you.

                                            I’m a big kid. I can configure my MUA.

                                            1. 1

                                              Exactly, it’s about the edge cases.

                                              I’m a big kid. I can configure my MUA.

                                              The point is you shouldn’t until you have a meaningful understanding of the issues, and some actual experience with emailed patches. Because big kid or no, there’s still a nontrivial chance you’ll screw it up. There’s no edit button on an email blasted out to everyone on a mailing list, it’s a hassle for everyone else.

                                              1. 3

                                                I think that’s a reasonable stance; what I disagree with is the wording on the site and on sr.ht proper.

                                                It’s like the author has never interacted with children. If you tell a kid “don’t touch the stove” they’re going to touch it. You tell the kid “if you touch the stove, you will get burned because it’s hot” and then they’ll actually listen. Hackers are a lot like children in that way.

                                                1. 4

                                                  I apologize for being so harsh in my earlier comments. My frustration stems from experience with people who don’t actually listen. People who insist on using their favorite workflow at the expense of everyone else, and have the entitled audacity to complain when other people won’t go out of their way to support them. When you replied in that way, it reminded me of that kind of person. But I’m happy to explain things to people who ask nicely.

                                                  I’m extremely biased in favor of people who generously give up their time to write documentation and tutorials. I don’t think they deserve criticism for deciding something is out of scope, it’s much better than writing nothing at all. They already deal with so much crap from selfish needy people, they’ve earned some slack in my book.

                                                2. 0

                                                  I use Thunderbird for all my email accounts and to keep track of my RSS feeds. I have filters set up to automatically categorize mailing lists. I can send and view mail in plain-text, or properly signed and/or encrypted with pgp. Assuming the world of mail clients consists solely of gmail/apple mail/outlook and telling people never to send mail outside of git send-email is bogus. I will continue to use my fully-featured, properly-configured MUA to send patches, tyvm.

                                                  1. 2

                                                    Cool. I recommend that you continue to use Thunderbird for all your email accounts, RSS feeds, filters, and categorization, exactly as you are now. And copy the Message-ID into git send-email. It breaks literally nothing in your workflow.

                                                    When you copied git format-patch output into Thunderbird, did you copy the entire git format-patch output into the message body? If you did, you did it wrong. Or did you correctly delete the first line, part of the mbox format, and copy the subsequent header lines out of the message body and into Thunderbird? If you sent multiple commits, did you ensure each commit was sent as its own email, each email subject properly used [PATCH n/m] format, and patches n>0 were all In-Reply-To patch 0?

                                                    Did you perform all of these manual steps perfectly without fail, and will you perform them perfectly without fail every time in the future? Did you find all of that easier than copying the Message-ID to git send-email?

                                                    And when you verified your patch sent properly, did you test by sending the patch to a different email address via a forwarding address a la mailing lists, copy the entire raw message source received into a file (not the message body), git am that file to a different repo clone with different name and email configured, and verify the authorship, timestamps, and all other commit metadata was perfectly preserved?

                                                    If not, your test was worthless. And if you did, can you prove it works for all variety of edge case patches, like patches with extremely long lines, non-ASCII characters, patches received from someone else and modified by you, and so on and so forth?

                                                    Assuming the world of mail clients consists solely of gmail/apple mail/outlook

                                                    Yes, that was clearly my assumption when I also specifically addressed Alpine and Mutt in the same paragraph. Good catch.

                                              2. 1

                                                Since git am doesn’t generate patches, I’m skeptical.

                                                1. 1

                                                  Sorry, I meant git format-patch

                                              3. 0

                                                If you are reading a beginner tutorial about mailing patches, you clearly don’t know anything so just use the damn tool that stops you from mailing malformed garbage to a ton of people.

                                                Or you’re used to sending patches via PRs or whatever other method, and come across a project that wants patches via email. You might be a git wizard otherwise, but if you haven’t used git send-email, a beginner tutorial can be helpful.

                                                Does your mail client automatically populate replies to threads with your updated commits?

                                                Yes. It did need a bit of configuration, but then, git send-email requires a tutorial. Thus, if an email client requires configuration to do things correctly, I’d still consider that a viable thing to do.

                                                And yes, it is literally impossible to make the Gmail web interface handle patches correctly.

                                                You can attach patches, and it won’t mungle them. It won’t be inline, but any reasonable e-mail client will be able to show you the patches in a reasonable manner whether attached or inlined. It’s only impossible if you aim at the lowest common denominator: terrible email clients. (Not saying anyone should use Gmail’s web interface for sending patches, but it is possible to do that.)

                                                1. 0

                                                  You can attach patches

                                                  No you can’t, those emails aren’t valid patch emails.

                                                  but any reasonable e-mail client

                                                  Literally irrelevant. Does not matter at all. This is about tooling and conventions.

                                                  The tutorial literally says “some people think that they can get away with sending patches through some means other than git send-email,” that’s you.

                                                  But you can’t. You’re flat out wrong and that’s exactly why the tutorial tells you you’re flat out wrong.

                                                  1. 1

                                                    No you can’t, those emails aren’t valid patch emails.

                                                    But they are. That you don’t like them, or can’t work with them, that’s your and your tooling’s problem. There’s tooling that works just fine with attached patches. They may not be acceptable for git am, but git am is not the only tool. It is if you stick to core git, but if you do that, you’re limiting yourself unnecessarily. Mind you, you can always filter the mails through a filter from your MUA first, and pass the attachment as inline patches to git aim, it’s not even hard.

                                                    Besides, like I mentioned in my previous comment, you literally can send valid, inline patch emails, with correct threading without git send-email. Your e-mail client may need a bit of configuration, but so does git send-email.

                                                    This is about tooling and conventions.

                                                    You may be surprised, but there are communities where the convention is sending patches attached, because those are far harder to mungle, and you don’t need to send a gazillion mails for a longer branch, just one larger mail. This makes it easier to review and reply to multiple commits at the same time, which can be very useful when they’re closely related (but still separate enough to warrant being separate commits).

                                                    Inline patches are not the only way to email patches around. It’s the only way stock git supports, and as we can see from this discussion, also the most fragile one.

                                                    1. 1

                                                      They may not be acceptable for git am

                                                      This tutorial and discussion is about using the core git email workflow.

                                                      It’s the only way stock git supports

                                                      This tutorial and discussion is about using the core git email workflow.

                                                      you can always filter the mails through a filter from your MUA first, and pass the attachment as inline patches to git aim, it’s not even hard

                                                      Alright, send a patch to the LKML, and when they reject it be sure to tell them “it’s not even hard,” I’m sure that will clear everything up!

                                                      You may be surprised

                                                      Shocker, I’m not.

                                                      there are communities where the convention is sending patches attached

                                                      Communities irrelevant to this tutorial and discussion about the core git email workflow.

                                                      To be clear, this tutorial and discussion are about the core git email workflow. See the very first sentence of the post, a website called git-send-email.io:

                                                      Git ships with built-in tools for collaborating over email.

                                                      1. 1

                                                        This tutorial and discussion is about using the core git email workflow.

                                                        git does not include a MUA, or any other tool to fetch email, which you will still need for the workflow, and the tutorial hints at this too, with “Check your email”. It already goes beyond core git email workflow. I wasn’t criticising the tutorial either, I was criticising your comments related to it, namely to give up on one’s usual MUA in favour of git send-email, just because without configuration they screw things up.

                                                        Alright, send a patch to the LKML, and when they reject it be sure to tell them “it’s not even hard,” I’m sure that will clear everything up!

                                                        I did, way back when, it was accepted.I sent plenty of patches by email over the years, none of them were rejected on the grounds of bad formatting/threading/whatever. None of them were sent using git send-email.

                                                        Git ships with built-in tools for collaborating over email.

                                                        No, it does not. It ships with tools to send email, that’s only one part of collaboration. Besides, what I was replying to is this assertion:

                                                        All mail clients screw it up. All. Of. Them.

                                                        Which is incorrect.

                                                        1. 1

                                                          Fine. All mail clients in popular or semi-popular use, in default configuration, or configured by those who don’t know what they’re doing, will not get it right 100% of the time. Happy?

                                                          1. 1

                                                            Yes, thank you.

                                            1. 15

                                              After the recent announcement of the F5 purchase of NGINX we decided to move back to Lighttpd.

                                              Would be interesting to know why instead of just a blog post which is basically an annotated lighthttpd configuration.

                                              1. 6

                                                If history has taught us anything, the timeline will go a little something like this. New cool features will only be available in the commercial version, because $$. The license will change, because $$. Dead project.

                                                And it’s indeed an annotated lighttpd configuration as this roughly a replication of the nginx config we were using and… the documentation of lighttpd isn’t that great. :/

                                                1. 9

                                                  The lighttpd documentation sucks. Or at least it did three years ago when https://raymii.org ran on it. Nginx is better, but still missing comprehensive examples. Apache is best, on the documentation font.

                                                  I wouldn’t move my entire site to another webserver anytime soon (it runs nginx) but for new deployments I regularly just use Apache. With 2.4 being much much faster and just doing everything you want, it being open source and not bound to a corporation helps.

                                                  1. 1

                                                    Whatever works for you. We used to run our all websites on lighttpd, before the project stalled. So seemed a good idea to move back, before nginx frustration kicked in. :)

                                                    1. 3

                                                      Im a bit confused. You’re worried about Nginx development stalling or going dead in the future. So, you switched to one that’s already stalled in the past? Seems like the same problem.

                                                      Also, I thought Nginx was open source. If it is, people wanting to improve it can contribute to and/or fork it. If not, the problem wouldn’t be the company.

                                                      1. 2

                                                        The project is no longer stalled and if it stalls again going to move, again. Which open source project did well after the parent company got acquired?

                                                        1. 3

                                                          I agree with you that there’s some risk after a big acquisition. I didnt know lighttpd was active again. That’s cool.

                                                          1. 2

                                                            If it was still as dead as it was a couple of years ago I would have continued my search. :)

                                                            1. 1

                                                              Well, thanks for the tip. I was collecting lightweight servers and services in C language to use for tests on analysis and testing tools later. Lwan was main one for web. Lighttpd seems like a decent one for higher-feature server. I read Nginx was a C++ app. That means I have less tooling to use on it unless I build a C++ to C compiler. That’s… not happening… ;)

                                                              1. 3

                                                                nginx is 97% C with no C++ so you’re good.

                                                                1. 1

                                                                  Thanks for correction. What’s other 3%?

                                                                  1. 2

                                                                    Mostly vim script with a tiny bit of ‘other’ (according to github so who knows how accurate that is).

                                                                    1. 1

                                                                      Alright. I’ll probably run tools on both then.

                                                                      1. 2

                                                                        Nginx was “heavily influenced” by apache 1.x; a lot of the same arch, like memory pools etc. fyil

                                                          2. 2

                                                            SuSE has been going strong, and has been acquired a few times.

                                                            1. 1

                                                              SuSE is not really an open-source project though, but a distributor.

                                                              1. 3

                                                                They do have plenty of open-source projects on their own, though. Like OBS, used by plenty outside of SuSE too.

                                                    2. 5

                                                      It’s a web proxy with a few other features, in at least 99% of all cases.

                                                      What cool new features are people using?

                                                      Like, reading a few books on the topic suggested to me that despite the neat things Nginx can do we only use a couple workhorses in our daily lives as webshits:

                                                      • Virtual hosts
                                                      • Static asset hosting
                                                      • Caching
                                                      • SSL/Let’s Encrypt
                                                      • Load balancing for upstream servers
                                                      • Route rewriting and redirecting
                                                      • Throttling/blacklisting/whitelisting
                                                      • Websocket stuff

                                                      Like, sure you can do streaming media, weird auth integration, mail, direct database access, and other stuff, but the vast majority of devs are using a default install or some Docker image. But the bread and butter features? Those aren’t going away.

                                                      If the concern is that new goofy features like QUIC or HTTP3 or whatever will only be available under a commercial license…maaaaaybe we should stop encouraging churn in protocols that work well enough?

                                                      It just seems like much ado about nothing to me.

                                                      1. 6

                                                        maaaaaybe we should stop encouraging churn in protocols that work well enough?

                                                        They don’t work well enough on mobile networks. In particular, QUIC’s main advantage over TCP is it directly addresses the issues caused by TCP’s congestion-avoidance algorithm on links with rapidly fluctuating capacities. I share your concern that things seem like they’re changing faster than they were before, but it’s not because engineers are bored and have nothing better to do.

                                                      2. 4

                                                        New cool features will only be available in the commercial version, because $$.

                                                        Isn’t that already the case with nginx?

                                                    1. 11

                                                      This may be incomplete or wrong: My understanding is that you send a search query to a searX instance, which then sends the query to various conventional search engines (google, bing, etc.), receives the results and passes them on to you.

                                                      It seems to me that hosting your own searX instance offers very little benefit in terms of privacy. If there are only a few searX instances, each with many users, then it acts a bit like a VPN. Google still gets all the search queries, but it can’t identify individual users of the instance. However, if you have your own searX instance which only you use, then google can still build up a picture of an individual (you), because the searX instance is just a simple proxy between you and google.

                                                      Is this correct, or does searX do something more complex under the hood (such as caching or federation with other instances)?

                                                      1. 2

                                                        I don’t know about SearX, but there’s YaCy, which does federate. It’s effectively a distributed search index. As with all approaches not relying on getting results finally from Google or Bing, the search results aren’t of high quality, though.

                                                        1. 2

                                                          It seems to me that hosting your own searX instance offers very little benefit in terms of privacy.

                                                          But it does. It strips, or at least normalizes, any identifying information in the request.

                                                          From the searx faq:

                                                          Searx protects the privacy of its users in multiple ways regardless of the type of the instance (private, public). Removal of private data from search requests comes in three forms:

                                                          • removal of private data from requests going to search services
                                                          • not forwarding anything from a third party services through search services (e.g. advertisement)
                                                          • removal of private data from requests going to the result pages

                                                          Removing private data means not sending cookies to external search engines and generating a random browser profile for every request. Thus, it does not matter if a public or private instance handles the request, because it is anonymized in both cases. IP addresses will be the IP of the instance. But searx can be configured to use proxy or Tor. Result proxy is supported, too.

                                                          1. 2

                                                            The “generating a random browser profile for every request” part of it is what makes SearX interesting to self-host, because a random browser profile for every request makes it that much harder for the asked engines to track me.

                                                            1. 2

                                                              Exactly, and the fact that it comes from a single IP means that they may attempt to build a ‘user profile’ for that IP address but any number of users could be hidden behind it, so it would definitely be an exercise in futility for google, etc.

                                                        1. 3

                                                          This just inspired me to create my own minimal, VTE-based terminal emulator, to get rid of some of the minor things that I found annoying with my previous terminal (gnome-terminal). The major benefit is that there are no menus now, neither app menus nor context menus, and no window decorations, which makes the thing get out of my way even better.

                                                          The last time I was unhappy with my terminal of choice (ROXTerm at the time), I went hunting for a good one, didn’t find any, and settled on gnome-terminal because that was the closest. Seeing how easy it is to build something on top of VTE, I no longer need to settle. Thank you!

                                                          1. 0

                                                            A sane versioning scheme […] That was easy.

                                                            No, semver is probably not the final solution.

                                                            From what I understood one problem is when you want to order versions. For example, you specify a dependency as “>=2.7”. Now is that condition fulfilled for “2.7-beta”? Is “2.7-beta” earlier or later than “2.7-rc3”?

                                                            Also, there is CalVer which uses dates. Example: Ubuntu 18.04 (meaning April 2018). Also ComVer a simplified SemVer.

                                                            1. 3

                                                              Semver uses 3 .-separated decimal numbers. -rc3 isn’t semver.

                                                              1. 2

                                                                Exactly. If you want to use a beta or rc release, you should vendor it or select a git commit, as in Cargo.

                                                                1. 2

                                                                  -rc3 isn’t semver, because it should be -rc.3, see SemVer#9. SemVer has rules governing pre-releases.

                                                                2. 2

                                                                  There’s also ConVer (content versioning) which uses git commit hashes, although the fact that I can no longer find a link to the site/article probably speaks to how popular that idea is.

                                                                  1. 2

                                                                    In practice, the answer to those questions is no, and earlier respectively.

                                                                    And there is work on making those things official: https://words.steveklabnik.com/what-s-next-for-semver

                                                                    1. 2

                                                                      SemVer#11 lists the ordering. >= 2.7 is not satisfied by either of your examples. As for their ordering, 2.7-rc.3 > 2.7-beta.1, as specified by SemVer.

                                                                    1. 16

                                                                      Advertising, with no prior engagement. :(

                                                                      1. 17

                                                                        Hi, my apologies, I might have been not used to the rules/culture of this place… Let me apologize if this link submission made you see some unwanted ad spam. I was thinking that the story we posted might have some value as a technical reading, but ultimately you’re right, it serves as an advertisement as well. From now on I’ll be more careful when posting links here and try to separate technical content. Again, I’m sorry for disturbing your pleasant afternoon (although you might be in a different timezone…).

                                                                        1. 10

                                                                          No worries, and congrats on a product launch. The problem is just that this site would quickly drown in marketing and advertising if people’s first few interactions here were posting their products or services. :(

                                                                          1. 6

                                                                            I like the video you have demonstrating the board: https://www.youtube.com/watch?v=th7KZzGz17s -

                                                                            1. 8

                                                                              Thank you… I’m pretty sure that, if I manage to survive another decade, my friends will then share that video to embarrass me… But that was the best I could come up with with the limited budget (The video took $15 to buy a tripod to stabilize the filming). I’m glad that at least one person liked it… 😂

                                                                              1. 7

                                                                                All those friends should envy you since you actually did something instead of being an armchair critic 😉

                                                                          2. 11

                                                                            Agreed, but there is interesting technical content as well: https://moonrim.io/compare - although you could call that advertisement as well, but a 10 page advertisement then.

                                                                            Maybe I just like keyboards too much to be annoyed by advertisement that appeals to me. (So ads about cool ergo boards).

                                                                            This should have a buyer beware title, because it’s a crowdfunding and you might not get a product (or three years later like the UHK) and lost your money.

                                                                            1. 4

                                                                              I want to upvote but the thing seems super suspicious. Just at the crowdfunding stage.

                                                                              Are there other, similar keyboards on the market?

                                                                              1. 10

                                                                                Hi. Maker here. I hope the following helps remove some of the suspicion:

                                                                                • Some design ideas of this has already been tried and produced. If it helps, you might want to take a look at ErgoDox, Keyboardio, and DataHand.
                                                                                • We’ve built a prototype and, admittedly, the technological barrier is not high to make this thing if you have some knowledge in electronics and programming. The issue is more of how to gather enough people to make mass production feasible; To make plastic injection molding financially viable, we need at least about one thousand people willing to buy it, hence the fixed funding goal. Speaking of which… The goal is fixed (instead of flexible funding goal) so if it doesn’t reach $200k before the end of the campaign, the funding will be canceled automatically and your payment will be refunded in its entirety.
                                                                                • If you doubt whether I’m a fraud or not, you are totally rightfully so. It seems there are so many crowdfunding scams these days… So, if, by any chance, you are interested in my track record: I’ve worked as a software engineer in South Korea for a while. I’ve been an organizer of Haskell-KR for a while, so my name is not entirely unknown to the Korean programming community. (If you look at the backers list, you’ll see the early backers are mostly Koreans with typical Korean names). My previous workplace was LINE, where I held a programming language boot camp that was featured officially on LINE’s engineering blog. And… If there’s anything else I can do for you to trust us, please never hesitate to tell us.
                                                                                1. 4

                                                                                  I love me some split keyboards. I just wrote this article on my five year adventure in split keyboards: https://raymii.org/s/articles/Split_keyboards_a_five_year_review_including_the_ErgoDox_EZ_Matias_Ergo_Pro_and_Kinesis_Freestyle_2.html

                                                                                  The fixed goal is nice, that gives people a bit more trust to join in with the funding. I’ve sadly got bad experiences with Indigogo’s where money just vanished without a product. That is, you are not buying a product but supporting a project and maybe getting a perk.

                                                                                  I’m absolutely not saying you’re a fraud and I love the project, will probably back it since I do love me a good keyboard.

                                                                                  1. 2

                                                                                    Ditto wrt indigogo and vanished money. I’d be more inclined to contribute to crowdsuppy, kickstarter, or, alternatively, massdrop, all of which I’ve had great experiences with, but indigogo is a red flag as I see it.

                                                                                    1. 2

                                                                                      Indeed if you compare Kickstarter and Indiegogo, the former has a higher reputation. We did want to use Kickstarter, but opening a project on Kickstarter demanded permanent residency of one of 26 countries (1). We’re Koreans living in South Korea, so we sadly couldn’t. :(

                                                                                      (1)

                                                                                      Project creation is currently available to individuals in the US, UK, Canada, Australia, New Zealand, the Netherlands, Denmark, Ireland, Norway, Sweden, Germany, France, Spain, Italy, Austria, Belgium, Switzerland, Luxembourg, Hong Kong, Singapore, Mexico, and Japan who meet the requirements below.

                                                                                      https://help.kickstarter.com/hc/en-us/articles/115005128594-Who-can-use-Kickstarter-

                                                                                      1. 2

                                                                                        I was sold the second I saw this keyboard. I’m not thrilled about indigogo, but I see what you’re saying regarding kickstarter and you have my support. I hope to see moonrim II get fully backed. Good luck!

                                                                                      2. 1

                                                                                        FWIW, there have been some pretty successful projects on IGG, like the ErgoDox EZ. Of the 5 projects I backed there, three already delivered, a the fourth is on track to deliver too. The only project that vanished with my money on IGG was the Jolla Tablet.

                                                                                        1. 1

                                                                                          I completely forgot about the Ergodox Ez - as a long time user of the classic ergodox (massdrop kit) I backed the EZ on indigogo well and have never regretted it.

                                                                                    2. 3

                                                                                      We’ve built a prototype and, admittedly, the technological barrier is not high to make this thing if you have some knowledge in electronics and programming. The issue is more of how to gather enough people to make mass production feasible.

                                                                                      I appreciate your candor on this point, and overall in the campaign description and demonstration video.

                                                                                      I’ve been considering alternative keyboards for a couple of years now, and thought about using my 3D printer to build a Dactyl keyboard, which is also a concave columnar layout, but did not find the time. One thing I missed was an integrated pointing device: I thought about adding one, then contemplated all the changes I would have to do for it, and decided to leave it for later.

                                                                                      Having you deal with all that is well worth the crowdfunding price for me, and I just backed it.

                                                                                      1. 2

                                                                                        Thank you very much 😂 We really want to deliver a quality product to you. As this is a fixed funding goal and it gets canceled if it doesn’t reach the goal, we desperately need to spread the word to gather about 1,000 people. If there’s any chance anyone around you might also be interested, please tell them. Again, thank you so much for backing Moonrim II.

                                                                                      2. 1

                                                                                        The only thing that sticks out is the price. It is oddly low. :)

                                                                                        In any case: good luck on this mission! I love the idea, and yes, I’ve heard of those keyboards. Yours doesn’t look anything like those, but like a kinesis advantage pro that is domed.

                                                                                      3. 1

                                                                                        You could buy an ergodox and glue / Velcro it to a bookshelf stand (bookend)? or two planks at an angle (reverse T)

                                                                                    1. 10

                                                                                      I dunno. This looks like feature creep.

                                                                                      Want to start a conversation but no code has been written: Open an issue. You’re PR is going to fix a bug or add a feature. This starts as a issue that is discussed, voted upon and milestoned

                                                                                      Your PR is not ready for merging yet: Keep it in your branch/fork and keep working on it. It’s not ready for a PR. Have questions, ask it on the issue. Want a code review, request one on the issue. Or do a regular PR and request comments, because you can keep adding commits to the PR.

                                                                                      1. 10

                                                                                        Keep it in your branch/fork and keep working on it.

                                                                                        I suspect this doesn’t work for most people because you can’t (easily) see and comment on a diff between your branch and the base one without opening a PR. Which is exactly what they should have done instead of creating another redundant first-class entity in the already over-complicated UI.

                                                                                        1. 6

                                                                                          t’s not ready for a PR. Have questions, ask it on the issue. Want a code review, request one on the issue.

                                                                                          Send the patch to a mailing list and discuss it there inline within the comfort of your favorite mail client of choice.

                                                                                          1. 3

                                                                                            Hard to deny that these days most people find a Web UI more comfortable than any of the (stagnating) mail clients. Minus the hassle of subscribing to a mailing list.

                                                                                            I mean, I’m totally with you that all of that is just as easy, but most people seem to have a different perception.

                                                                                            1. 4

                                                                                              Minus the hassle of subscribing to a mailing list.

                                                                                              This is a common misconception; there is no need to subscribe to the mailing list if it’s set up correctly. If you send your patch there, people will include you in the reply list regardless.

                                                                                              I agree it’s distressing how much GMail’s near-monopoly has hurt the ecosystem and caused people to forget that better clients exist.

                                                                                              1. 1

                                                                                                In some cases, like work, you’re forced into GMail to avoid someone exfiltrating your IMAP synced mailbox via malware. So…

                                                                                                1. 2

                                                                                                  Yeesh; hopefully work policies don’t prevent you from making OSS contributions with your personal mail account tho.

                                                                                                  1. 2

                                                                                                    In some cases, yes. For the types of stuff I’d do in my spare time, most likely not.

                                                                                                    But my guess is that this restrictive email thing will become more popular, not less, meaning that important projects, like those you get paid to work on during work hours, won’t be able to successfully support contributions that way.

                                                                                                    I dunno though. I could certainly be completely offbase here and we will see a resurgence of plain text email, and a new generation of mail tools. Fastmail is betting on JMAP, which uses JSON, so the barrier to entry might get much much lower in years to come…

                                                                                            2. 1

                                                                                              A mailing list you say? So I have to fight through all the spam, and everything else that comes with it? Should I set up a list for every single repo? Should I write my own automation for code review and assignment?

                                                                                              I mean, on GitHub, I can clearly see who I requested code review from (and whether they reviewed it, and what their review is), who’s assigned to the PR/issue, what milestone it belongs to and so on. Can I do that with a mailing list? Yes, I could search, use labels, bookmarks, whathaveyou in my client of choice, but there’s no built-in thing that provides me with this information. One can build it on top of mailing lists, but then I’d use the API of that, and the mailing list would be reduced to transport only.

                                                                                              As it happens, I can reply to GitHub notifications by email, from the comfort of my favourite mail client. And I get to enjoy the benefits of the API too. So no, a mailing list is not a substitute. For tiny things, or if you’ve established an email-based workflow already, it can work. For a lot of projects, it doesn’t.

                                                                                              1. 2

                                                                                                So I have to fight through all the spam, and everything else that comes with it?

                                                                                                The last time spam got thru on any of my mailing lists was over a decade ago. (Basically never happened since I moved off Google.)

                                                                                                Should I set up a list for every single repo?

                                                                                                Another advantage of this setup is that you aren’t locked in to a 1:1 mapping between issue tracking and repos. You can easily set up a single mailing list to discuss patches for a group of related repositories under a single project, or a separate mailing list for a subset of development on a single large repository.

                                                                                                1. 4

                                                                                                  The last time spam got thru on any of my mailing lists was over a decade ago. (Basically never happened since I moved off Google.)

                                                                                                  Lucky you. Plenty of my non-google addresses get quite a bit of spam, can’t imagine it being any different for mailing lists. The single list I run gets plenty of spam. Most are caught, but only because I spend non-negligible time making sure they are. I’d happily let go of this task.

                                                                                                  Another advantage of this setup is that you aren’t locked in to a 1:1 mapping between issue tracking and repos. You can easily set up a single mailing list to discuss patches for a group of related repositories under a single project, or a separate mailing list for a subset of development on a single large repository.

                                                                                                  I can do the same on GitHub with GitHub projects. I get e-mail notification, I can reply via e-mail, but I also have an API to access all of that information - and more - whenever I want, from wherever I may be, without having to carry my email archive around, or host my email on a server I can access on the go. I can also selectively subscribe to issues (via the API, so I don’t ever need to fire up a web browser), and get e-mail notifications. The API lets me query on labels, milestones, etc. Doing the same on a mailing list is very far from being trivial, or convenient, especially when I want to search backwards to times I weren’t subscribed yet.

                                                                                                  If you don’t need the labels, don’t use milestones and various other features GitHub provides, a mailing list might be a suitable alternative, and a convenient workflow. The moment you start to use these, a mailing list will stop being adequate. No, Subject: [project:subsystem bug#N]: blah is not a solution, and doesn’t work. Client-side labeling/filtering doesn’t either, because the point of labels & milestones is that they’re centralised. N+1 mailing lists for subsystems is a pain to maintain, and even bigger a pain to work with (been there, tried it, no thanks).

                                                                                                  In my experience, working with Magit & Forge is much more convenient than mailing patches and whatnot around.

                                                                                            3. 5

                                                                                              You say feature creep, I say the end of a long period of feature stagnation.

                                                                                              Enough companies use Github as part of their development infrastructure – not just process – that it makes sense to have a programmatic way of flagging a PR as “not ready yet”. The rest of us will just type “[WIP]” less often. Is it that bothersome?

                                                                                              1. 4

                                                                                                Do you all not use a WIP label?

                                                                                                1. 6

                                                                                                  I do, and include that same title. No one looks at labels, even if they are blinking and bright red.

                                                                                                  1. 2

                                                                                                    Reminds me of how many PRs we’ve merged that have a “Do Not Merge” label on them.

                                                                                                    1. 1

                                                                                                      We have a policy of only allowing PRs to be merged by a reviewer, never by the assignee. You may self assign as a reviewer but normally a PR will be created by one person and merged by another. If nobody has been assigned it sits until someone is.

                                                                                                2. 2

                                                                                                  I’d prefer to open a PR to start a discussion, but I’ve worked with people who prefer to see PRs as ‘ready to go’ and get shirty when you open a PR that’s not merge-ready.

                                                                                                  Making it explicit is handy for dealing with people who aren’t interested in learning how to use patches-by-mail but you want a place to discuss work in progress.

                                                                                                1. 13

                                                                                                  but Electron is without question a scourge

                                                                                                  Well, how about a big F* you?

                                                                                                  Sorry for the swear words, but while I agree that in general Electron is not great, calling it a scourge is incredibly offensive towards those who chose to develop with Electron, and have good reasons for it. Sometimes writing native apps is cost-prohibitive, and you’re better off with an Electron app that looks a bit out of place, than have no app at all. It’s cool for you to be smug and elitist and complain about stuff not following the HIG on every single platform the app is developed for, but have you ever thought about the cost of doing so? Yeah, big companies may be able to shell out enough money and pay developers to create native apps and follow the platform’s HIG, but not everyone’s a big business. I dare say the vast majority of app developers aren’t. By hating on Electron and anyone who doesn’t polish their app perfectly, you’re alienating a whole lot of developers.

                                                                                                  Learn to see the other side of the coin already.

                                                                                                  (I ranted about this on my blog recently, also explaining why Electron was chosen over developing native apps.)

                                                                                                  1. 37

                                                                                                    complain about stuff not following the HIG on every single platform the app is developed for

                                                                                                    Do you know why human interface guidelines exist? They exist because humanity is imperfect and accessibility is really important.

                                                                                                    Electron apps are not accessible. They’re often completely opaque to a screen reader, they’re often completely opaque to assistive speech recognition software, they often don’t respond properly to keyboard navigation and if they do, they don’t behave as expected. They don’t often respond properly to text scaling, they don’t understand system-wide options like increased contrast or reduce motion.

                                                                                                    To whole classes of users, your Electron app is worthless and unusable. What are we supposed to do? Congratulate you on your accomplishment? You need to shrink your ego and take some time to understand real world users, rather than throwing words around like “smug” and “elitist”.

                                                                                                    Also your blog post doesn’t even mention the word “accessibility” once. How disappointing.

                                                                                                    By hating on Electron and anyone who doesn’t polish their app perfectly, you’re alienating a whole lot of developers.

                                                                                                    At the risk of sounding controversial, what does it matter if we alienate some developers? Developers should do better. They need to do better. I’m fine with alienating developers for good reasons.

                                                                                                    Electron is not the answer. It’s a shortcut at best and a bandaid at worst. This isn’t a secret, so there’s really no point in acting surprised that people don’t agree with your choices.

                                                                                                    1. 10

                                                                                                      I think that we who care about accessibility need to avoid taking a condemning, vitriolic tone, and meet developers where they are. That way, we’ll be more likely to get results, rather than just alienating a large and growing group of people. It’s true that Electron apps often have accessibility problems. But I believe we can improve that situation without calling for people to throw out Electron entirely. Frankly, we need access to these apps more than these developers need us. So we have to work with what we’ve got.

                                                                                                      No, I haven’t always lived up to this ideal when communicating with mainstream developers, and I’m sorry about that.

                                                                                                      1. 14

                                                                                                        I think that we who care about accessibility need to avoid taking a condemning, vitriolic tone, and meet developers where they are.

                                                                                                        The problem is that these developers don’t want to meet anywhere else - that’s how we arrived at Electron apps in the first place. It’s the easy way out.

                                                                                                        1. 4

                                                                                                          Most trends in IT are driven by herd mentality, familiarity, leveraging ecosystems, and marketing by companies. All of these seem to contribute to Electron use just like they contributed to Java and .NET getting big. They sucked, too, compared to some prior languages. So, it’s best to identify what they’re using within what ecosystems to find an alternative that’s better while still being familiar.

                                                                                                          Then, see how many move to it or don’t for whatever reasons. Iterate from there.

                                                                                                          1. 1

                                                                                                            Developers don’t want to listen because by the time they start publishing something (based on Electron, for a number of reasons), what they meet with is pure, unconditional hate towards the technology (and not just the tech! towards developers using said tech, too!) that enabled them. It is not surprising they don’t want to listen to the haters anymore.

                                                                                                            You’re alienating new developers with this kind of mentality too, who would be willing to listen to your concerns. You’re alienating them, because of the sins of their fathers, so to say. I’m not surprised noone cares about accessibility, to be honest. When we’re told the world would be better off without developers like us, we’re not going to be interested in working towards better accessibility.

                                                                                                        2. 5

                                                                                                          Do you know why human interface guidelines exist? They exist because humanity is imperfect and accessibility is really important.

                                                                                                          I’m aware, thank you. I’m very much aware that Electron is not… great, for many reasons. That’s still not a reason to unconditionally call it a scourge.

                                                                                                          To whole classes of users, your Electron app is worthless and unusable. What are we supposed to do? Congratulate you on your accomplishment? You need to shrink your ego and take some time to understand real world users, rather than throwing words around like “smug” and “elitist”.

                                                                                                          You, like the article author, ignore circumstances, and generalize. Yes, my electron app is going to be useless for anyone using a screen reader. It will be useless for a whole lot of people. However, it will exist, and hundreds of people will be able to use it. Without Electron, it wouldn’t exist. So ask yourself this, which is better: an application that is not usable by some people, but makes the life of the vast majority of its intended audience easier; or an application that does not exist?

                                                                                                          Here’s the situation: there’s a keyboard with open source firmware. Right now, to change the layout, you need to edit the firmware source, compile a new one, and upload it to your keyboard. While we tried to make the process easy, it’s… not very friendly, and never going to be. So I’m building an application that lets you do this from a GUI, with no need for a compiler or anything else but the app itself. I develop on Linux, because that’s what I have most experience with. Our customers are usually on Windows or Mac, though. With Electron, I was able to create a useful application, that helps users. Without it, if I had to go native, I wouldn’t even start, because I lack the time and resources to go that route. For people that can’t use the Electron app, there are other ways to tweak their keyboard. The protocol the GUI talks can be implemented by any other app too (I have an Emacs package that talks to it, too). So people who can’t use the Electron app, have other choices.

                                                                                                          So, thank you, I do understand real world users. That is why I chose Electron. Because I made my due diligence, and concluded that despite all its shortcomings, Electron is still my best bet. Stop smugly throwing around Electron hate when you haven’t considered the circumstances.

                                                                                                          At the risk of sounding controversial, what does it matter if we alienate some developers? Developers should do better. They need to do better. I’m fine with alienating developers for good reasons.

                                                                                                          Well, for one, a lot of our customers would be deeply disappointed if they weren’t able to use the GUI configurator I built on Electron. “Developers should do better”. Well, come here and do my job then. Get the same functionality into the hands of customers without using Electron. I’ll wait (they won’t).

                                                                                                          Electron is not the answer. It’s a shortcut at best and a bandaid at worst. This isn’t a secret, so there’s really no point in acting surprised that people don’t agree with your choices.

                                                                                                          I agree it is not the best, and I’m not surprised people disagree with my use of it. I can even respect that, and have no problems with it. What I have problems with, is people calling Electron a scourge, and asserting that native is always best, and that anyone who doesn’t follow the HIG of a given platform “should do better”. I have a problem with people ignoring any and all circumstances, the reason why Electron was chosen for a particular product, and unconditionally proclaiming that the developers “should do better”. I have a problem with people who assert that alienating developers because they don’t (or can’t) write apps that match their idealistic desires is acceptable.

                                                                                                          Before writing off something completely, consider the circumstances, the whys. You may be surprised. You see, life is full of compromises, and so is software development. Sometimes you have to sacrifice accessibility, or native feel, or what have you, in order to ship something to the majority of your customers. I’d love to be able to support everyone, and write lighter, better apps, but I do not have the resources. People calling the technology that enables what I do a scourge, hurts. People asserting that I should do better, hurts.

                                                                                                          Until people stop ignoring these, I will call them elitist and smug. Because they assume others that chose Electron have the privilege of being able to chose something else, the resources to “do better”. Most often, they do not.

                                                                                                          1. 1

                                                                                                            Electron apps are not accessible. They’re often completely opaque to a screen reader, they’re often completely opaque to assistive speech recognition software, they often don’t respond properly to keyboard navigation and if they do, they don’t behave as expected.

                                                                                                            I haven’t written an electron app, but I’ve done a fair share of web UI programming with accessibility in mind. You communicate with platform accessibility APIs through web APIs. It’s not technically complicated, but it does require some domain expertise.

                                                                                                            Does it work the same way on electron?

                                                                                                            1. 8

                                                                                                              Electron embeds chromium, which doesn’t connect to the native a11y APIs (MS are working to fix this on windows).

                                                                                                              As a result electron apps are as inaccessible as chrome (screenreader users tend to use IE, safari or firefox).

                                                                                                              1. 3

                                                                                                                Huh, this is a real surprise if true.. i tested our web UI with screen readers across macOS and windows in chrome, FF, and IE, and the only problems that occurred were due to bad markup or the occasional platform bug. Reaching the accessibility API was not a problem i ran into with chrome

                                                                                                                1. 2

                                                                                                                  Chrome is definitely accessible to screen readers. I’ve spent more time that I’d like getting JAWS to read consistently across IE, FF and Chrome. From memory, Chrome was generally the most well behaved.

                                                                                                            2. 7

                                                                                                              When Apple was first developing the Mac, they did a lot of research into human/computer interaction and one of the results was to apply a consistent interface on the system as a whole. This lead to every app having the same menu structure (for the most part, the system menu (the Apple logo) was first, “File” next, then “Edit”) and under these standard menus, the actions were largly the same and in the same order. This would lower training costs and if a user found themselves in a new app, they could at least expect some consistency in actions.

                                                                                                              I’ve been using Linux as a desktop since the mid-90s (and Unix in general since 1989) and to say there’s a lack of consistency in UI is an understatement. Some apps have a menu bar at the top of the window (Macs menu bars are always at the top of the screen per Fitt’s Law), some you have to hold Ctrl down and press the mouse button, some the right mouse button will cause a pop-up menu. I’ve been able to navigate these inconsistencies, but I’m still annoyed by them.

                                                                                                              Further more, I’m used to the CLI, and yet even there, the general UI (the command set, the options to each command) still surprises me. I wrote about the consistency of GUIs and the inconsistencies I found on the Unix CLI over the years and while I still prefer the CLI over the GUI [1], I can see where the consistency of the Mac GUI makes for a much better experience for many.

                                                                                                              As I’ve stated, I think it’s wonderful that PHP has enabled people to create the dynamic websites they envision, but I wouldn’t want to use the resulting code personally.

                                                                                                              [1] One can program the CLI to do repetitive tasks much easier than one can do the same for any of today’s GUIs. There have been some attempts over the years to script the GUI (Rexx, AppleTalk) but it still takes more deliberate action than just writing a for loop at the command prompt for a one-off type of job.

                                                                                                              1. 5

                                                                                                                I think the case where it makes sense to go Electron is not the point of Gruber’s rant. The point was that many, many developers today are easier with writing Electron app and using it on all platforms instead of putting time and effort into polished Cocoa apps.

                                                                                                                The core of this blog post is how Mac really was different in terms of UI/UX. During the time I started using Mac (10.5) it was really differentiating itself by having “different”, “better looking and feeling” apps. Electron definitely made Mac feel less unique. Critics were pointed towards macOS app developers. Don’t get so offended by simple blogpost. Your reasons are fine, but that simply isn’t the case most of the time. Most people decide to go with electron because of plethora of mediocre JS devs, that can chunk out a lot of code that does something, and then you get slow junk like UX. In minds of 2000s Apple fans that is a big no.

                                                                                                                Have a nice day, and move on.

                                                                                                                1. 7

                                                                                                                  I think the case where it makes sense to go Electron is not the point of Gruber’s rant.

                                                                                                                  Correct.

                                                                                                                  The point was that many, many developers today are easier with writing Electron app

                                                                                                                  Incorrect.

                                                                                                                  Please just read the article.

                                                                                                                  His point is what he says: it is bad news for the Mac platform that un-Mac-like apps far worse than those that were roundly rejected 15 years ago are now tolerated by today’s Mac users.

                                                                                                                  It happens to be the case that Electron is the technology of choice for multiple prominent sub-par apps; that’s a simple statement of fact. (It also isn’t purely coincidental, which is why I agree with his characterisation of Electron as a scourge. If someone like @algernon who builds apps for Electron is bent on interpreting those statements as a judgement of their own personal merit, well… be my guest?) But Electron is not singled out: Marzipan gets a mention in the same vein. On top of that, Gruber also points out the new Mac App Store app, which uses neither. The particular technologies or their individual merits are not his point.

                                                                                                                  His point is, again, that a Mac userbase which doesn’t care about consistency spells trouble for the Mac platform.

                                                                                                                  1. 2

                                                                                                                    Marzipan gets a mention in the same vein.

                                                                                                                    Electron is the only one that gets called a scourge, and is singled out in the very beginning. It’s even in the title. It’s even the first sentence, which then continues: “because the Mac is the platform that attracts people who care”

                                                                                                                    If that’s not an elitist smug, I haven’t seen any.

                                                                                                                    1. 6

                                                                                                                      Once upon a time, Mac users were a ridiculed minority. In those days, Microsoft-powered PCs were better in just about every way. They were much faster, they had a more technically advanced OS (even crappy Win95 was far ahead of MacOS Classic), they had more applications, they had boatloads of games… just about every reason to pick one computer over another pointed in the direction of a Microsoft PC. You had to be special kind of kook to want a Mac regardless. It was inferior to a PC in basically every dimension. The one reason to pick a Mac over the PC was the depth of consistency and care in the UI design of its software. Only users who cared about that enough to accept the mile-long list of tradeoffs went for the Mac.

                                                                                                                      1. 1

                                                                                                                        Elitism is often a good thing. It’s how we get from the mundane to the truly excellent.

                                                                                                                    2. 3

                                                                                                                      The point was that many, many developers today are easier with writing Electron app and using it on all platforms instead of putting time and effort into polished Cocoa apps.

                                                                                                                      My beef is not with the author wishing for apps that would look more native - I share the same wish. My beef is with him calling Electron “without a question a scourge”. How about I said MacOS is without a question a scourge, for it jails you in its walled garden? You’d be rightly upset.

                                                                                                                      There’s a big difference between wishing apps would be more polished on a particular platform, and between calling a technology (and by extension, developers who chose to use it) a scourge. It reeks from privileged elitism, and failure to understand why people go with Electron.

                                                                                                                      Most people decide to go with electron because of plethora of mediocre JS devs, that can chunk out a lot of code that does something

                                                                                                                      No. Most people decide to go with Electron because it provides a much better cross-platform environment than anything else. Please don’t call a whole bunch of people “mediocre JS devs”, unless you have solid data to back that up. Just because it is JS and “web stuff” doesn’t mean the people who develop it are any less smarter than native app developers. Can we stop this “only mediocre people write JS/PHP/whatever” bullshit?

                                                                                                                      1. 13

                                                                                                                        There are more bad developers writing webshit because there are more devs writing webshit period.

                                                                                                                        Native apps tend to outperform Electron apps and use less memory, because to do the same things that don’t bring in a browser and language runtime.

                                                                                                                        Elitism is, in this case, warranted. The only really performant app (usually) in Electron I’ve seen is VSCode, because MS really does have sharp people working in a domain they’ve been leaders in for decades.

                                                                                                                        1. 7

                                                                                                                          There seems to be a shift towards less attention paid, and value given, to the experience of the user. This makes me very sad.

                                                                                                                          When people talk about why they use Electron, they always phrase it in terms of “developer productivity”, and that’s where I find the most elitist bullshit to be. Developers talk about using Electron so they didn’t have to learn a new platform, or so they only had to test it in one place, or it was faster. They talk about lower development costs (which they wildly overstate, in my experience).

                                                                                                                          But the questions I’d like use to start asking: what are the costs of the shit user experience? What are the costs of people having to learn new tools that don’t behave quite like the others? When we save money and time on development that money and time is saved once, but when we save time for our users, it’s saved repeatedly.

                                                                                                                          Maybe calling Electron shit is elitist bullshit. But I’ll take that over having contempt for one’s users.

                                                                                                                          1. 3

                                                                                                                            Contempt is a strong word. Would all these people be users in the first place if the app doesn’t exist for their platform? Go ahead and write a native Cocoa app for OSX, but that sure feels like contempt for Windows or Linux users. “Buy a new machine to use my stuff” vs. “deal with menus in the wrong order”?

                                                                                                                            1. 1

                                                                                                                              I never said “buy a new machine to use my stuff.”

                                                                                                                              From extensive experience: for most small applications, I can develop them natively on Mac, Windows, and Linux* faster than someone can develop the same thing with similar quality using a cross platform thing.

                                                                                                                              (*) “native” on Linux is less of a sticky thing that on Mac and Windows.

                                                                                                                              1. 3

                                                                                                                                Here’s a challenge for you: https://github.com/keyboardio/chrysalis-bundle-keyboardio (demo here).

                                                                                                                                Go do something like that natively for Mac and Windows. It’s a small app, some 3700 lines of JS code with comments. You do that, and I promise I’ll never write an Electron app ever again. You can make the world a better place!

                                                                                                                                1. 1

                                                                                                                                  Thank you for your interest in my consulting services.

                                                                                                                                  1. 4

                                                                                                                                    Thought so.

                                                                                                                                    FWIW, the app, like many Electron apps, were originally built in my unpaid free time. Complain about Electron apps once you built the same stuff under the same conditions.

                                                                                                                        2. 9

                                                                                                                          How about I said MacOS is without a question a scourge, for it jails you in its walled garden? You’d be rightly upset.

                                                                                                                          I wouldn’t. I might point out that you absolutely can bypass their walled garden, on MacOS, but those objections for iOS are not only valid, but are honestly concerning.

                                                                                                                          Electron is a scourge. iOS is a scourge. Facebook is a scourge. The feature creep within the browser is absolutely a scourge. There are loads of scourges. This is not an exhaustive list. I pray daily for a solar flare which delivers enough of an EMP that it utterly destroys the entire technology landscape, and gives us an opportunity to rebuild it from the invention of fire onwards, because we’ve fucked up, and our technology is bad.

                                                                                                                          And I say this because I want technology to be better. The Web is an awfully complicated way to render a UI. Our systems are overly dependent on a few corporations who don’t have our best interests at heart. Our computers are slower to do less work than they did two decades ago. Pretty much the only way anybody makes money in tech anymore is by abusing their users (see: Google, Facebook, etc). Or their employees (see: Uber). Or both (see: Amazon).

                                                                                                                          1. 1

                                                                                                                            In the EMP scenario we’d be too busy trying to get essentials back up to care about doing it right

                                                                                                                          2. 7

                                                                                                                            You’d be rightly upset.

                                                                                                                            No, I wouldn’t be rightly upset. I am not the technologies I use, and neither is that true for you.

                                                                                                                            Electron is the technology used in multiple highly prominent applications that are written with little or no regard to platform conventions. Their success is bad for the native platforms. Those are statements of fact. If you have good reasons to use Electron, then there is no need for you to relate those facts to yourself and take them as a statement of your merits as an individual.

                                                                                                                            1. 7

                                                                                                                              Agree. The notion that your identity is somehow linked with the tools you use is toxic. It is fine to like your tools, but once you get comfy with them you should be pushing beyond them to expand your taste.

                                                                                                                              1. 5

                                                                                                                                your identity is somehow linked with the tools you use

                                                                                                                                I used QBasic, Visual Basic 6, and later FreeBASIC. If my tools define me, I feel like such a shallow person with no depth or skill. Such a sinking feeling. I think I’m going to re-install SPARK Ada and buy Matlab to feel like a mathematician. Yeah, that will be better… ;)

                                                                                                                        3. 4

                                                                                                                          Thanks for sharing the blog post.

                                                                                                                          I think your case is quite different from, say, Slack. I have worked on major cross-platform apps at a company, and it’s not a huge deal, when you have a few people working on it, whose collective knowledge covers those platforms. All apps used the same core libraries for the non-UI parts, and each app added native UI on top. A company with tens, or even hundreds of well-paid developers should be able to do that, if they care at all about accessibility, performance (which is a different kind of accessibility issue,) resource usage, and all those things.

                                                                                                                          1. 2

                                                                                                                            It is still a big deal, even for a larger company, because there’s a huge difference between employing N developers to develop a single cross-platform application (with some of them specializing in one platform or the other), and between employing a set of developers to create native applications, and a set for the core libraries. There may be overlap between them, but chances are that someone who’s good at developing for Windows or OSX would not be happy with developing for Linux. So you end up employing more people, paying more, diverging UIs, for what? Paying customers will use the Electron app just as well, so what’s the point of going native and increasing costs?

                                                                                                                            Yeah, they should be able to do that, yes, it would improve the user experience, yes, it would be better in almost every possible way. Yet, the benefits for the company are miniscule, most of the time. In the case of Slack, for example, or twitter, a uniform experience across devices is much more important than native feel. It’s easier to document, easier to troubleshoot, and easier for people who hop between devices: it’s the same everywhere. That’s quite a big benefit, but goes very much against making the apps feel native. And if you forego native feel, but still develop a native application that looks and behaves like on any other platform (good luck with that, by the way), then the benefits of native boil down to being less resource hungry. In the vast majority of cases, that is simply not worth the cost of the development and maintenance burden.

                                                                                                                            In the age of mobile devices, I do not feel that apps looking “native” is any benefit at all, but that’s a different topic.

                                                                                                                            1. 5

                                                                                                                              I built them in the past myself. I’ve read write-ups about what it takes for others. If designing program right, most of the code is shared between the different platforms. The things that are different are mostly in the front-end that calls the common code. A lot of that can be automated to a degree, too, after design is laid out. For main three platforms, it basically took a max of three people two of whom only worked on UI stuff here and there mostly focused on shared code. That isn’t the minimum either: it can be lower if you have 1-2 developers that are experts in more than one platform. In mobile, many people probably know both iOS and Android.

                                                                                                                              The cross-platform part will be a small part of the app’s overall cost in most cases. It will mostly be in design/UI, too. That’s worth investing in anyway, though. :)

                                                                                                                              1. 5

                                                                                                                                Our experience clearly differ then. I worked for companies that made native apps for the major platforms (mobile included), and each team was 10+ people at a minimum, with little code shared (the common code was behind an API, so there’s that, but the apps itself had virtually no code in common). Not to mention that the UIs differed a lot, because they were made to feel native. Different UIs, different designs, different bugs, different things to document and support. A whole lot of time was wasted on bridging the gaps.

                                                                                                                                If they made the apps feel less native, and have a common look across platforms, then indeed, it could have been done with fewer people. You’d have to fight the native widgets then, though. Or use a cross-platform widget library. Or write your own. And the writer of the article would then complain loudly, and proclaim that multi-platform apps are the worst that could happen to the Mac (paraphrasing), because they don’t follow the HIG, and developers nowadays just don’t care.

                                                                                                                                1. 3

                                                                                                                                  each team was 10+ people at a minimum, with little code shared (the common code was behind an API, so there’s that, but the apps itself had virtually no code in common).

                                                                                                                                  “If they made the apps feel less native, and have a common look across platforms, then indeed, it could have been done with fewer people. “

                                                                                                                                  I said native look on multiple platforms minimizing cost. You example sounds like something about the company rather than an inherent property of cross-platform. You usually need at least one person per platform, esp UI and style experts, but most of the code can be reused. The UI’s just call into it. They’ll have some of their own code, too, for functions specific to that platform. Mostly portable. Just sounds like the company didn’t want to do it that way, didn’t know how, or maybe couldn’t due to constraints from legacy decisions.

                                                                                                                                  1. 1

                                                                                                                                    My experience mirrors yours almost exactly.

                                                                                                                            2. 3

                                                                                                                              What about sciter? Companies doing stuff like anti-virus have been using it for a long time with way, way, less, resource use. It’s licensing scheme looks like something other vendors should copy. Here’s a comparison claiming a simple editor is 2MB in sciter vs 100+ in Electron just because it brings in less baggage.

                                                                                                                              How many people using Electron could use the free, binary version of sciter? And how many companies using Electron could afford $310 per year? I mean, that’s within reach of startups and micro-businesses, yeah? I’m asking because you said it’s use Electron or not cross-platform at all cuz too costly/difficult. I’m making it easy by using a comparable offering rather than, say, Lazarus w/ Free Pascal or otherwise non-mainstream languages. :)

                                                                                                                              Note: I also have a feeling lots of people just don’t know about this product, too.

                                                                                                                              1. 4

                                                                                                                                I actually evaluated sciter when I got frustrated with developing in JS, and wanted to go native. For my use, it wasn’t an option, because the app I write is free software, and therefore so much be its dependencies. For closed-source use, it’s probably fine. Though, you’d still have to write plenty of platform-specific code. AV companies already do that, but companies that start off with a web-based service, and develop an application later do not have that platform-specific code already built. What they have, is plenty of JavaScript and web stuff. Putting that into Electron is considerably easier, and you end up with very similar UX, with little effort, because you’re targeting a browser still.

                                                                                                                                Oh, and:

                                                                                                                                With Sciter, changing the front end of your application involves just altering the styles (CSS), and probably a couple of scripts that do animations.

                                                                                                                                Yeaah… no. That’s not how changing the UX works. It’s a tad more involved than that. Not sure I’d be willing to trust my UI on an offering that basically tells me that changing between, say, Metro and Material UI is a matter of CSS and animations. (Hint: it’s much more involved than that.)

                                                                                                                                Since we’ve already decided we’re not going to follow any platform HIGs (and thus, have the article author proclaim we’re a scurge), what’s the point of going native? Less resource use? Why is that worth it for the company? People use the app as it is, otherwise they wouldn’t be writing an app. Writing native, and making it look and behave the same has non-negligible cost, but little to no benefits. Faster and lighter is in many cases not a goal worth pursuing, because customers buy the thing anyway. (I’d love if that wouldn’t be the case, but in many cases, it is.)

                                                                                                                                1. 1

                                                                                                                                  I appreciate the balanced review of sciter. That makes sense.

                                                                                                                            1. 7

                                                                                                                              Question for the group. If you use Stylus (or used to use Stylish), what do you use it for?

                                                                                                                              I headed over the the userstyles.org site and most of the styles seem to be “dark themes” or other cosmetic changes like changing the background of a site. Are there more practical uses of the extension? Can it modify HTML or Javascript (where the real power would be), or is it CSS only?

                                                                                                                              1. 27

                                                                                                                                other cosmetic changes like changing the background of a site

                                                                                                                                You call it cosmetic changes, other people call it accessibility.

                                                                                                                                1. 7

                                                                                                                                  I use it to tweak the layout of some of the sites I use, like moving a fixed top navbar to the side, and making it smaller. Or making narrow columns wider. Small stuff like that, which make the browsing experience much more bearable. I rarely use the social or sharing aspects of it. I haven’t found anything useful there, and I’m not sharing my tweaks either, because they’re very personal anyway.

                                                                                                                                  I rarely use it to hide things, my adblocker can do that more conveniently indeed.

                                                                                                                                  1. 6

                                                                                                                                    I apply a style of body { max-width: 800px; } on a few blogs that weren’t designed with wide browser windows in mind—they spill text across the entire width of the screen, which makes them really hard to read. (You could use your browser’s “reading mode” to fix this, too, but this CSS change usually does the job without breaking any layouts.)

                                                                                                                                    1. 4

                                                                                                                                      Now that I’ve started using Dark Reader, I use Stylus for well-made, site-specific dark themes. Previously I was using the Gruvbox Dark Everywhere userstyle, but its shotgun approach leaves much to be desired. Beware: Dark Reader has some major performance issues on Firefox.

                                                                                                                                      Edit: My installed themes (which I enable along with Dark Reader after sunset): https://ptpb.pw/nUrG.png

                                                                                                                                      Edit 2: Also I enable the Firefox and Tree Style Tabs dark themes. This really needs to get more streamlined.

                                                                                                                                      Edit 3: And then I get to enable dark/night mode on sites that support it natively, one-by-one as I visit them. Sigh.

                                                                                                                                      1. 2

                                                                                                                                        Man, Dark Reader is great. Thanks for bringing my attention to that.

                                                                                                                                        1. 1

                                                                                                                                          Funny that you mention this. I don’t often long for the days when I had a CSS styling addon installed, but exactly this Dark Reader page made me bob my head back 20cm. That page seems to be made for a mobile phone or tablet screen, not a 27” monitor. Wow.

                                                                                                                                        2. 3

                                                                                                                                          Fixing fonts on the most obnoxious websites.

                                                                                                                                          1. 3

                                                                                                                                            I like to use it to remove ads in core apps I use. I’d like to share the styles I create with others who use those apps. I use the free version of toggl, and they have a persistent, animated thing in the bottom-right corner that tells me the benefits of “going pro”. I just made a stylish thing to display: none the element which matches that rule. It’s great.

                                                                                                                                            1. 1

                                                                                                                                              Is there an advantage to that over the “block element” feature that exist in most ad blockers?

                                                                                                                                              1. 1

                                                                                                                                                I use brave and Firefox which have some built in blocking. I haven’t thought of that, but I’ll take a look!

                                                                                                                                            2. 3

                                                                                                                                              I used to use Stylish - and a predecessor the name of which has slipped my mind - to reduce the size of the UI in Firefox - smaller tabs, less wasted space -> more space for page content.

                                                                                                                                              1. 2

                                                                                                                                                i’m considering using it to shrink the gmail sidebar label font - they recently increased it from the same size as email body text to a size bigger, and it’s very annoying.

                                                                                                                                                1. 1

                                                                                                                                                  I sometimes use it to tweak interfaces, like get rid of annoying panels or adding bold to certain elements

                                                                                                                                                  1. 1

                                                                                                                                                    I just started using this again after forgetting that it existed. Another forum I visit regularly now is ad free and doesn’t waste a bunch of whitespace where these were removed. I created an ironic one for hiding the ads for stylish for android on userstyles.org… :D Also, my day job involves using a console that has a lot of useless (to me) menu items - bye bye.

                                                                                                                                                    1. 1

                                                                                                                                                      Can it modify HTML or Javascript (where the real power would be), or is it CSS only?

                                                                                                                                                      Is it possible for extensions to request access only to modify CSS?

                                                                                                                                                      1. 4

                                                                                                                                                        CSS can still exfiltrate sensitive page content (albeit attacks are harder to write).

                                                                                                                                                        1. 1

                                                                                                                                                          If you write your own CSS this is no longer a problem :P.

                                                                                                                                                          1. 1

                                                                                                                                                            That’s good to know. I’m going to do some reading on this, but do you have anything you recommend?

                                                                                                                                                        2. 1

                                                                                                                                                          There are two sites I frequent that have awful stylesheets that I can’t stand so I have custom stylesheets that make them look better.

                                                                                                                                                        1. 3

                                                                                                                                                          @algernon@trunk.mad-scientist.club, posting about mechanical keyboards (mostly about their firmware side), parenting, daily life stuff, and whatever else I feel like.

                                                                                                                                                          1. 4

                                                                                                                                                            I… don’t think engagement is a reasonable ranking metric. There are incredibly useful repositories out there that see little to no engagement, because there’s no need to. They do their thing, and that’s it. They may not have many stars, or even many forks, let alone pull requests. Yet, they may be at the root of your dependency chain, making all of it possible (or at least easier).

                                                                                                                                                            What I’m trying to say, trying to reduce repositories to numbers, to determine some kind of “rank” that signals whether one’s worth more than the other is ultimately a mistake. It’s never going to be fair. It’s never going to be accurate (far from it). Instead, both of these metrics should be hidden, to discourage such abuse.

                                                                                                                                                            I’ll show an example: the Model01 Firmware has - as of this writing - 101 stars, 207 forks, 47 PRs opened total, and 21 issues. In comparison, the Kaleidoscope repo has 330 stars, 91 forks, 285 PRs, 199 issues in total.

                                                                                                                                                            The first is meant to be a starting point upon which you build your own layout. Forking is encouraged, but most forks are for personal changes, there’s no reason any of those should be contributed back. A very small percentage of forks were made to contribute something back. Based on your algorithm, it would have a rank of 4.

                                                                                                                                                            The second is the firmware itself, where local changes make much less sense, so sending them back upstream is encouraged. Your ranking system ranks it at 3.48.

                                                                                                                                                            The repository that has seen much less engagement is ranked higher, pretty much defeating your algorithm.

                                                                                                                                                            However, from a user point of view, this makes sense, because the Model1-Firmware repo is much more useful for an end user. Not quite so from a developer point of view (which your ranking systems seem to want to support). Which just strengthens my point that ranking repos is a mistake: you need to take intent into account as well. And once you do, you can no longer reduce a repo’s worth to a single number. And that’s good. We shouldn’t rank repos this way anyway. It’s not healthy, and does not foster a healthy ecosystem either.

                                                                                                                                                            1. 1

                                                                                                                                                              I’m not sure I agree with most of this, but I do thank you for your feedback.

                                                                                                                                                              I think that much of your argument boils down to this statement: “No matter what, the Rank Algorithm won’t be perfect.” But this is inherently true of life. We don’t discourage GitHub’s Trending page’s because their algorithm isn’t perfect (its based almost entirely on stars and is thus very limited). The Rank Algorithm I proposed is no different. Whereas GitHub’s Trending page rewards the most “popular” repositories, the Rank Algorithm rewards the most “useful” repositories. Both efforts are destined to fail if we demand perfection.

                                                                                                                                                              As far as your example goes, I would say that the Model01_Firmware repository is the one that tricks the system, whereas the other repository’s rank is more or less accurate (or as accurate as can be expected when using my admittedly juvenile algorithm).

                                                                                                                                                              As far as the morals of it all and whether or not a ranking system foster’s a “healthy ecosystem”, I think the argument will quickly devolve into the likes of whether or not our children should all get trophies or not. I’m going to side-step that one because I don’t see us resolving that century-old debate today. I will note, however, that it is nearly impossible to improve upon a skill without first having some way of measuring that skill. A ranking algorithm is just one more attempt at measuring progress, and I don’t see anything wrong with it.

                                                                                                                                                              1. 2

                                                                                                                                                                My main issue is not with ranking per-se, but with attaching “worthiness” to rank. You can rank them whatever way you want, and that can be useful, but it’s best done with the ranking being in the hands of the one who’s looking for something. If I’m looking for an active project, I’d use a different ranking than when I’m looking for something tried and true (and usually considerably less active). There’s no single ranking algorithm that would yield the desired results in both cases. Therefore, attaching worthiness to any ranking system is flawed, and that practice should be discouraged.

                                                                                                                                                                argument will quickly devolve into the likes of whether or not our children should all get trophies or not

                                                                                                                                                                Except you usually give trophies at the end of a competition. Open source development is not a competition. Ideally, it would be cooperation.

                                                                                                                                                                I will note, however, that it is near impossible to improve upon a skill without first having some way of measuring that skill.

                                                                                                                                                                Measuring skill is one thing. Reducing one’s worth to a set of skills is another. I have problem with the latter.

                                                                                                                                                                1. 2

                                                                                                                                                                  Okay. I understand where you’re coming from now. It seems like it was just an issue of semantics. I struggled to find the right words for this article; “worth” is one I probably should have left out.