1. 20

    Sad :-( I still think Mercurial far better meets the needs of most people, and that the chief reasons for git’s popularity are that Linus Torvalds wrote it, GitHub, and that Linus Torvalds wrote it.

    That said, I did end up switching from BitBucket/mercurial to GitHub/git a few years ago, simply because it’s the more pragmatical thing to do and I was tired of paying the “mercurial penalty” in missed patches and the like. I wrote a thing about it a few ago: https://arp242.net/git-hg.html

    1. 6

      Why do you think hg is better for most people? I honestly find it vastly more complex to use.

      1. 15

        The hg cli is light years ahead of git in terms of intuitiveness.

        1. 6

          I’d say it’s years behind ;)

          1. 10

            How long have you been using Mercurial? I find most people who dislike Mercurial’s UI, are mainly coming from years of experience with Git. I disliked Mercurial at first as well, but after a few years of forced usage it clicked. Now I appreciate how simple and well composed it is and get frustrated whenever I need to look up some arcane Git flag on StackOverflow.

            In general, I’d say you need several years experience with both Git and Mercurial before you can draw a fair comparison.

            1. 3

              I used mercurial for about 2 years before using git.

              1. 3

                Sorry if my post came across a bit accusatory (not my intent). In that case I guess to each their own :).

              2. 3

                but after a few years of forced usage it clicked.

                I’m pretty sure that git clicked for me in a much shorter timeframe.

                1. 1

                  Me too, but I know many (otherwise perfectly competent engineers) 5-10 years in who still don’t get it and aren’t likely to.

              3. 9

                I’m going to strongly disagree. I’ve used git intensively and I find Mercurial to be a well-designed delight. I’ve run across features that Mercurial supports flawlessly, with a nice UI, and Git requires a hacky filter-branch that takes hours to run and doesn’t even behave correctly.

                IMO, a lot of the badness in projects is down to Git badness. it doesn’t scale and people feel compelled to break things down into tiny sub-projects.

                The only reason Git is winning anything is GitHub’s support of it.

                1. 3

                  The only reason Git is winning anything is GitHub’s support of it.

                  Why then was github ever used in the first place? Kind of a strange proposition.

                  1. 1

                    Network effect of the social network is pretty important.

                    1. 1

                      Why would there ever be a network effect in the first place if git was so bad that github was the only reason to use it. I get that the argument technically holds but it seems very unlikely.

            2. 8

              You find mercurial more complex to use than git? That’s an… unusual view, to say the least. The usual recitation of benefits goes something like this

              • Orthogonal functionality in hg mostly has orthogonal commands (compare git commit, which does a half-dozen essentially unrelated different things).
              • hg has a somewhat more uniform CLI (compare git branch -a, git remote -v, git stash list).
              • hg either lacks or hides a bunch of purportedly-inessential and potentially confusing git functionality (off the top of my head, partial commits aren’t baked into the flow a la git’s index/staging area; and rebasing and history rewriting are hidden behind an extension).

              I personally prefer git, but not because I think it’s easier or simpler; I’m more familiar with it, and I find many of those purportedly-inessential functions to be merely purportedly, not actually, inessential.

              1. 5

                One more thing I like about mercurial that the default set of commands is enough for >90% of people, and that everything else is “hidden” in extensions. This is a very different approach than git’s “kitchen-sink” approach, which gives people 170 commands (vs. Mercurial’s 50, most of which also have much fewer options/switches than git).

                Git very much feels like “bloatware” compared to Mercurial.

                1. 3

                  I used git for many years, and then mercurial (at FB) ever since we switched over. The cli interface for mercurial is definitely more sensible, crecord is delightful, and overall it was fine. But I was never able to build a mental model of how mercurial actually worked. git has a terrible interface, but it’s actually really simple underneath.

                  1. 1

                    I didn’t think that underneath they were different enough to matter much. What differences do you mean? I guess there’s git’s remote tracking stuff. Generally, it seems like they differ in how to refer to and track commits and topological branches, locally and remotely. (IMHO, neither has great mechanisms for all the things I want to do.) Mercurial is slightly more complex with the manifest, git is more complex with the staging area that feels absolutely critical until you don’t have it (by using hg), at which time you wonder why anyone bothers with it. I’m a heavier hg user than git user, but that’s about all I can come up with.

                  2. 2

                    You find mercurial more complex to use than git?

                    I actually found – in a professional shop – mercurial far more complex to use. Now, the fact is that mercurials core – vanilla hg is IMHO absolutely without doubt vastly superior to git. Git keeps trying to make the porcelain less painful (including a release just a bit ago) – but I still think it is ages behind.

                    The problem is – I never used vanilla mercurial in a professional environment. Not once. It was always mercurial++ (we used $X extension and $Y extension and do it like $Z) which meant even if I knew hg, I felt painfully inexperienced because I didn’t know mq, share, attic, collapse, evolve, and more… not to mention both the bigger shops I worked with using mercurial has completely custom workflow extensions. I suspect part of this was just the ease of writing mercurial extensions, and part of it was wanting to fall into a flow they knew (mq, collapse). But, regardless of how we got there, at each place I effectively felt like I had to relearn how to use the version control system entirely.

                    As opposed to git, wherein I can just drop in and work from day one. It might be less clean, it might be more finicky and enable things like history rewriting by default. But at the end of the day, the day I start, I know how to generally function.

                    I am curious how Mercurial would have faired if instead of shipping default extensions you had to turn on – if they had just baked a little more functionality, to try to cover the 80% of what most shops wanted (not needed, I think most could have gotten by with what vanilla mercurial had) – if the shop to shop transition would have been easier.

                    1. 2

                      mq, I think, is responsible for many of the “mercurial is too complicated” complaints people have. Evolve, if it ever stabilized and ships with core hg would really enable some killer capabilities. Sadly for social and technical reasons it’s perpetually in beta.

                    2. 1

                      whoa, no index? Admittedly I didnt really use index as intended for several years, but now its an important part of my workflow.

                      1. 1

                        In Mercurial, commits are so much easier to make and manipulate (split, fold, move), that you don’t miss the index. The index in git is just a limited special cased “commit”.

                        1. 3

                          The index in git is just a limited special cased “commit”.

                          I disagree.

                          The index is a useful way to say “these lines of code are ready to go”. If you are making a big commit, it can be helpful to add changes in logical blocks to the index as you go. Then the diff is not polluted with stuff you know is already fine to commit.

                          You might say, “why not just make those changes their own commits, instead of trying to do one big commit?” That’s a valid question if you are talking about a 200 line commit or similar, but sometimes the “big” commit is only 50 lines. Instead of making a bunch of one line or few line commits, its helpful to “git add” small chunks, then commit at the end.

                          1. 0

                            You can as well amend to a commit instead of adding to the index.

                            1. 3

                              True, but all thats doing is bastardizing the commit process. If you are committing a one line change, just to rebase minutes or hours later, thats not a commit.

                              Rebase to me is for commits that were intended to be commits, but later I decided it would be better to squash or change the history. The index is for changes that are never meant to be a full commit on their own.

                              1. 1

                                Having a distinction between draft and published phases in mercurial I think makes it easier to rewrite WIP work. There’s also a number of UI affordances for it. I don’t miss the index using mercurial. There’s also academic user interface research that shows the index is a big conceptual barrier for new users.

                                1. 1

                                  There’s also academic user interface research that shows the index is a big conceptual barrier for new users.

                                  this isnt really a valid point in my opinion. some concepts are just difficult. if some goal can be achieved in a simpler way i am on board, but I am not a fan of removing useful features because they are hard to understand.

                                  1. 1

                                    But the point is the index is hard to understand and unnecessary.

                                    There’s no need to have a “commit process”. Just commit whatever you want and rewrite/amend it for as long as you want. As long as your commits are drafts, this is fine.

                                    Is the problem the word “commit”? Does it sound too much like commitment?

                                    There’s no need to have two separate ways to record changes, an index, and a commit, each with different degrees of commitments. This is multiplying entities beyond necessity.

                                    1. 1

                                      That’s your opinion. The index is quite useful to me. I’d rather make a proper commit once it’s ready, not hack together a bunch of one line commits after the fact.

                                      1. 2

                                        The index is a commit. Why have two separate ways of storing the same sort of thing?

                                        Also, it’s not my opinion that it’s hard to understand and unnecessary; it’s the result of usability studies:

                                        https://spderosso.github.io/oopsla16.pdf

                                        You’re also not “hacking together” anything after the fact. There’s no more hacking together after the fact whether you use git amend (hypothetically) or git add. Both of those mean, “record additional changes”.

                                        1. 0

                                          It seems you have a fundamental misunderstanding of the difference between add and commit. Commit requires a commit message.

                                          1. 1

                                            This isn’t a useful distinction. You can also create commits with empty commit messages in both git and Mercurial.

                                            With both git and Mercurial you can also amend commit messages after the fact. The index in git could well be implemented as a commit with an empty commit message that you keep amending and you wouldn’t notice the difference at all.

                                            1. 1

                                              you keep amending and you wouldn’t notice the difference at all.

                                              yeah, you would. again it seems that you either dont know git, or havent used it in some time. when you amend a commit, you are prompted to amend the message as well. another facet that doesnt exist with git add, because add doesnt involve a message.

                                              if you wish to contort git internals to suit your agenda thats fine, but git add has perfectly valid use cases.

                                              1. 0

                                                you are prompted to amend the message as well.

                                                This is UI clutter unrelated to the underlying concepts. You can get around that with wrappers and aliases. I spoke of a hypothetical git amend above that could be an alias that avoids prompting for a commit message.

                                                Don’t git users like to say how the UI is incidental? That once you understand the data structures, everything else is easy? The UI seems to have locked you into believing the index is a fundamentally necessary concept, but it’s not. It’s an artifact of the UI.

                                                1. 1

                                                  The UI seems to have locked you into believing the index is a fundamentally necessary concept, but it’s not.

                                                  Nothing has locked me into believing its a necessary concept. Its not necessary. In fact, for about 7 years I didnt use the index in any meaningful way.

                                                  I think what you are missing is that Im not compelled to use it because its the default workflow, I am compelled to use it because its useful. It helps me accomplish work more smoothly than I did previously, when I would just make a bunch of tiny commits because I didnt understand the point of the index, as you still dont.

                                                  The argument could be made to move the index into an option, like somehow make commit only the default workflow. Im not sure what that would look like with Git, but I dont think its a good idea. It would just encourage people to make a bunch of smaller commits with meaningless commit messages.

                                            2. 1

                                              You have a set of things you want to accomplish. With git, you have N+1 concepts/features/tools to work with. With hg, you have N (because you drop the index). That means you have to expand your usage of the remaining N.

                                              Specifically, since you no longer have this extra index concept, you now expand commits to cover the scenarios you need. Normally, you’d make an initial commit and then amend a piece at a time (probably with the interactive curses hunk selector, which is awesome.) If you’re unsure about some pieces, or you have multiple things going on that you’d like to end up in separate commits, you can always make a series of microcommits and then selectively collapse them later. (In practice, it’s even easier than this, because of the absorb extension. But never mind that.)

                                              Yes, those microcommits need commit messages. They don’t need to be good ones, because they’re temporary until you squash them out of existence. I usually use a one word tag to specify which of the separate final commits they belong to. (If you don’t have separate final commits, you may as well amend, in which case no messages are needed.)

                                              …or on the other hand, maybe mercurial ends up with N+1 concepts too, because phases really help in keeping things separate. As I understand it, one reason git users love the index is because it keeps rapidly changing, work in progress stuff separate from mostly set in stone commits. Phases perform the same purpose, but more flexibly, and the concepts are more orthogonal so they compose better. In my opinion.

                    3. 6

                      I never particularly liked git and find it unintuitive, too.

                      I wouldn’t consider myself a git poweruser. But whenever I had to work with alternatives I got the feeling that they’re just inferior versions of git. Yeah, maybe the usage was a bit more intuitive, but all of them seemed to lack things that I’d consider really basic (bisecting - hg has that, but e.g. svn has not - and shallow copying - not avaible in hg - are examples what I often miss).

                      1. 3

                        Mercurial was actually my first DVCS, and like you I ended up switching to git not out of a sense that it was technically better, just more pragmatic. For me, the change is more of a mixed bag, though. It is definitely the case that Mercurial’s UI is worlds better, and revsets in particular are an amazing feature that I sorely miss, but when I made the switch I found that the way git handles branches was much more intuitive to me than Mercurial’s branch/bookmark system, and that the affordances around selectively editing commit histories were very much worth the risk in terms of being able to manage the narrative of a project’s history in a way that makes it more legible to others. Ultimately, I found that git’s advantages outweighed its downsides for my use case, since learning its UI idiosyncrasies was a one-time cost and since managing branches is a much more common occurrence for me than using revsets. That said, I think this is a really unfortunate development.

                        1. 2

                          I occasionally convert people’s git repos to hg for my use. Stubborn like that.

                        1. 9

                          I’ve given this a try, and it looks pretty nice, and is fast. However, it doesn’t (yet?) have support for extensions like the regular mobile Firefox, and its built-in ad blocking is deeply inadequate for my needs. Regular Firefox on Android supports uBlock Origin.

                          1. 5

                            Extension support is coming, though I’m not aware of any official ETA.

                          1. 24

                            In other words, “Let’s all use Chromium but somehow Google isn’t in charge”. Controlling the web platform is power, and Google isn’t going to just hand over the keys to its biggest rivals. Heck, Blink was forked from Webkit in the first place because Google and Apple couldn’t see eye to eye.

                            The assumption that if enough non-Google developers start working on Chromium that somehow they can outvote Google is also flawed since having everyone on Chromium gives Google more power, not less. At least now there is an alternative that browsers like Brave/Vivaldi could theoretically switch to (given that Mozilla is finally starting to prioritize Gecko embedding). If this proposal comes to pass the last check on Google’s power will be gone, and if they say “get bent” there will be nothing anyone can do about it.

                            While it might be tempting to think that Microsoft will be able to wrest some control of Chromium away, the reality is that they made the switch out of desperation not desire. They have lost all their chips at the table and from now on will only be able to push the web in directions that Google agrees with.

                            1. 10

                              Yeah, if you needed any more reasons about how this is a terrible idea you have no further to look than Google’s lockdown of their DRM components to prevent competition from another OSS browser: https://boingboing.net/2019/05/29/hoarding-software-freedom.html

                              1. 1

                                How do you feel about, say, https://iridiumbrowser.de/ ?

                                1. 7

                                  It’s still fundamentally chromium though, isn’t it? They may have “stripped out the functionality which exposes data to others in a way [they] don‘t like”, but in all likelihood the project will continue to merge changes from chromium that are interesting, useful, and or necessary. Iriduimbrowser isn’t going to, for example and the sake of this discussion, write their own http3/quic implementation, right? By building on the chromium project they are still going in whatever direction that Google mandates only they’re stripping out privacy-oriented bits that they’ve deemed naughty. It looks like an interesting project, I like the transparency, and it looks like something I’d personally choose over chrome/chromium. However, the project as a whole, being a chromium derivative, remains entirely dependent on Google now and going forward.

                              1. 9

                                I wouldn’t be so quick to write off static websites. The use cases you listed are entirely do-able with a static site, and modern generators (hugo, jekyll, pelican) are miles ahead of where static site generation was even a few short years ago.

                                I serve my blog with Github Pages, so deploying is git push (wrapped in a script that does some other stuff like re-generating the static files). Things like comments (or photo galleries) can be embedded if you really want to go that route. Though there are often clever ways to accomplish stuff like this anyway (e.g staticman for comments).

                                1. 8

                                  modern generators (hugo, jekyll, pelican) are miles ahead of where static site generation was even a few short years ago.

                                  I’m curious what innovations you’ve seen in static site generators in the past few years? I haven’t seen anything fundamentally different, but I’m curious if there’s something I’m missing!

                                  1. 1

                                    Me too.

                                    I used to use and love Pelican for my blog, and I still have the utmost respect for that project and its maintainers (The code is solid and very approachable - something I really value.)

                                    But I have zero web design talent and couldn’t get it looking the way I wanted, and also posting from a mobile device is pretty painful, so I turned back to the dark side and now use wordpress.com.

                                1. 16

                                  Excellent read! A huge part of transitioning into more senior roles is just letting things go. Style doesn’t have to be perfect, code coverage doesn’t have to be 100%, the system doesn’t have to be designed to your exact liking. It’s ok to hold yourself to a high standard, just don’t try to push that standard on others. Being senior (and beyond) means being able to work alongside people who have different values and priorities than you.

                                  1. 6

                                    Firefox Monitor uses haveibeenpwned.com as it’s source and seems to provide exactly the same functionality. It’s not clear to me what the value-add is?

                                    1. 15

                                      There are a couple value adds:

                                      1. Trust via brand recognition. I’ve asked my parents to check haveibeenpwned.com before and it took me 10 minutes to convince them it was safe to visit. I love the service, but the domain name alone makes it unsuitable for the vast majority of internet users.

                                      2. Discoverability. Only a tiny minority has ever heard of haveibeenpwned and word of mouth won’t reach nearly as many people as a Firefox can.

                                      Edit:

                                      There’s also the possibility of future integrations with e.g Firefox Lockwise.

                                      1. 8

                                        Haveibeenpwned is English only. Monitor is available in dozens of languages.

                                        The audience is non-technical. Being affected by a breach causes a lot of uncertainty and fear in a people. Monitor helps them understand what they need to do (basic password hygiene) in their own language. Tldr: localization, simplification, emails for new breaches.

                                        1. 5

                                          I guess the only difference is that Mozilla gets to collect your email address and (per their privacy policy) basically send you things and share it with salesforce and amazon:

                                          If you sign up, we (and our email providers SalesForce and Amazon) receive your email address to contact you in connection with the Firefox Monitor Service, which includes Full Reports, Breach Alerts, and Safety Tips. You can unsubscribe at any time.

                                          1. 2

                                            @ahal put it very well.

                                            Aaaand people use their emails to sign up for really shady services, which outsource their email to one of these Amazon/Sendgrid/Mailchimp companies anyway. The GDPR (allegedly, at least) helps a bit, but I think the bigger damage has been done a priori.

                                            Mozilla’s business is not in mail delivery, though in this case it sounds like they could, and maybe should, take care of it themselves.

                                            I’m taking this as a sign of them seeing outsourcing as a lesser evil and risk than hiring someone to maintain Postfix and in-house tooling.

                                          2. 1

                                            In Troy Hunt’s announcement from last year, he mentions that only 0.06% of pwned email addresses are signed up to the notification service.

                                          1. 13

                                            I really need to make the effort and transition to FF.

                                            1. 21

                                              It’s really not an effort. Firefox is just a better browser at this point.

                                              1. 14

                                                Yet Firefox gets a LOT of hate for…. Just about everything.

                                                Given that it’s the only 100% open source browser with any market share to speak of, I struggle to understand people’s stance on this.

                                                1. 6

                                                  Higher expectations, I suppose

                                                  1. 4

                                                    Yeah I think that’s a big part of it. Most people who like to throw shade at Firefox prefer some niche browser or other, because that meets their particular preferences, priorities and needs better.

                                                  2. 2

                                                    Lack of vertical tabs.

                                                    :-P

                                                    1. 1

                                                      Can you articulate why lack of vertical tabs is such a deal breaker for you? Just aesthetics or is there a functional reason?

                                                      1. 3
                                                        • Vertical tabs conserve horizontal screen space; important as displays lose more and more height and gain more width with each year.
                                                        • Switching tabs using the mouse requires a large (> 100px) and non-predictable (due to varying tab widths) amount of hand movement; vertical tabs always take the same, small movement.
                                                        • Horizontal tabs start to get compressed and increasingly harder to read with >8 tabs; vertical tabs always keep the same width.

                                                        These are the functional reasons, but this doesn’t mean that vertical tabs should allowed to be aesthetically repulsive, just as long as they provide these features.

                                                        Compare this dog’s breakfast Firefox devs force upon people with this design for instance.

                                                        1. 1

                                                          I’m an unusual edge case where UX is concerned so I’ll appreciate your radically different perspective and thank you for taking the time to elucidate it!

                                                          For me, the mouse is a productivity vampire. I avoid it like the plague. I use keyboard based random access to get to tabs and never have more than 9 open at once so it’s never a problem.

                                                          I have fine and gross motor difficulties so getting the mouse to move where I want and to actually hit the accursed tiny clicky thing is torture :)

                                                  3. 11

                                                    Yeah, I don’t really understand this conception. I have the hardest time trying to convince my friends to switch, they always state it’s too much of a hassle. What hassle? Bookmarks, history, passwords and even settings all automatically imported on first run. Thanks to web extensions, most extensions are a simple re-install away (or worst case alternatives are easily found with a quick search).

                                                    1. 1

                                                      That´s all true both, and yet there is something freaking sticky about Chrome. But you are completely right.

                                                    2. 7

                                                      do they have user-friendly multiprofile? That’s always been the blocker for me

                                                      1. 1

                                                        Same here. Containers are nice but I use profiles a lot in Chrome. Having the separation of history is useful. Firefox still doesn’t have a good way of managing profiles.

                                                        1. 1

                                                          I’m using different profiles, a personal one, and a work one, and it works great. I’ve never used multiple profiles on chrome though, so I don’t know how it would compare.

                                                          1. 3

                                                            Chrome profiles are a first-class feature available by clicking on your profile picture on the menu bar: https://imgur.com/a/j6vIeG2

                                                            While Firefox has profiles, they seem a bit tedious to set up and manage https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles. It looks like the only way of controlling them is through about:profiles - do you use them this way or some other way?

                                                            1. 1

                                                              I’m afraid I do use them through about:profiles. Chrome’s do look better, I must say, but Firefox’s work well enough for me :)

                                                        2. 4

                                                          Chromium’s UI is better than Firefox, IMO.

                                                          On the same machine (2011 27” iMac, Debian, 16 Gb RAM, 3.6 Ghz i5) Chromium is noticeably snappier, smoother, and less glitchy.

                                                          Right now, even as I’m typing this, I’m experiencing a glitch where popup menus (from right click or clicking the >> button, for example) show up for a fraction of a second and disappear.

                                                          1. 3

                                                            It is an effort. I switched a few months ago and it took me a few solid weeks to get comfy. I had to sink lots of time into configuring tridactyl.

                                                            Just depends of workflows really.

                                                            Other things that require a similar level of effort (or more): changing your email client, changing your shell, changing your window manager.

                                                            1. 3

                                                              I suppose I am a rather vanilla browser user - I hadn’t considered more niche use cases.

                                                              Sidebar: thank you for making ripgrep! I use it daily and love it.

                                                              1. 1

                                                                FWIW I find vim-vixen much easier to get going with than tridactyl.

                                                                1. 3

                                                                  A brief look suggests that vim-vixen has far fewer features. Tridactyl wasn’t necessarily hard to use. It just took awhile to perfect my setup. One really nice feature it has is that I can configure it via a vim-style config file on disk that keeps everything consistent and under my control through all my workstations.

                                                                  1. 1

                                                                    I admit, I basically only use j, k, f, and / for the most part. Perhaps I don’t know what I’m missing.

                                                                    1. 1

                                                                      I don’t use too much more, but this is my config: https://gist.github.com/BurntSushi/393546a65db38d57cedcfd72c6d89bf3

                                                                      1. 2

                                                                        We fixed set findcase smart a few days ago by the way. No-one else had mentioned it. It isn’t quite in a stable release yet but will be soon.

                                                                        1. 1

                                                                          Thanks! :)

                                                            2. 11

                                                              Enable WebRender (set gfx.webrender.enabled and gfx.webrender.all to true in about:config), restart FF and it’ll be almost as fast as Chromium in most tasks, faster in some.

                                                              1. 3

                                                                I switched over this morning after going back and forth between it and Chromium a few times in the past. Chromium’s UI is better, but I haven’t had any problems with rendering yet.

                                                                I’d love to use https://github.com/atlas-engineer/next, but it doesn’t have uMatrix or an adblocker yet, so I’m not going to use it full time.

                                                              1. 11

                                                                Long time vim user here. If you enjoy vim golf, weird flex, but okay, more power to you. If you’re a new user, ignore the gatekeeping.

                                                                1. 7

                                                                  Also came here to chime in about the gatekeeping. I’m not thrilled with “real Vim ninjas”.

                                                                  1. 4

                                                                    This is a weird take to me. I very much enjoyed VimGolf when I was a beginner Vim user. I love that you don’t see the best solutions straight away. You post your [terrible] solution, and then you’re shown a better solution. Little by little, you’re shown new ways to approach editing text. There were many times when I’d see an improved solution and think “Wow! I didn’t know Vim could do that!

                                                                    Probably the three things that had the most impact on my Vim ability — in no particular order — were:

                                                                    • Forcing myself to do everything in Vim
                                                                    • Drew Neil’s book Practical Vim
                                                                    • VimGolf
                                                                    1. 10

                                                                      I agree, I find VimGolf an excellent way to learn new tips and tricks. However there is more than a kernel of truth to /u/barakmich ’s comment.

                                                                      They make you register with your Twitter and count the number of attempts you made. So your failures are public and tied to your online identity. There is a definite culture of elitism amongst many VimGolf practitioners. I wish there were a “learning” mode where your scores don’t count on the scoreboard and you didn’t need to register with Twitter. Would make the thing a lot less intimidating.

                                                                      1. 3

                                                                        It would also be really nice if a lot of the challenges weren’t competitive. Instead of “get the lowest score”, it would be “get a score below this value”. That’d be better at making it teach common useful tricks instead of pushing people to use every obscure thing they can think of.

                                                                        1. 2

                                                                          That’s a good idea. It’s open source, someone should create a fork more oriented towards beginners and learning than to showing off your leet skills.

                                                                        2. 1

                                                                          Ok, I think that’s a very fair criticism, and I have to agree with you.

                                                                    1. 4

                                                                      I tried this while it was in alpha, and at the time it was too crashy for me to evaluate.

                                                                      It looks a bit nicer than the current Firefox for Android, but I’m concerned mainly about whether it will support add-ons. I don’t have a ton of Firefox add-ons installed on Android, but having real uBlock Origin in the mobile browser is a game-changer compared to the weaker built-in adblocking in Firefox Focus.

                                                                      1. 3

                                                                        I find it nicer than the current Firefox too. The bar at the bottom is a bit weird on the first time but it feels more ergonomic.

                                                                        As for the add-ons, it would be a total deal breaker if WebExtensions such as uBlock Origin are no longer supported. Add-ons are the main reason I use Firefox on Android and I guess I am not the only one.

                                                                        1. 3

                                                                          Add-on support is planned (and possibly already being worked on?).

                                                                          1. 2

                                                                            Did Mozilla mention this somewhere? I would like to believe you, but they already have one fairly popular mobile browser (Focus) with no add-on support..

                                                                            1. 2

                                                                              Nothing official, but see: https://github.com/mozilla-mobile/fenix/issues/574#issuecomment-466980564

                                                                              In other words, Fenix won’t support add-ons initially (for the MVP), but there will be a transition period before Fennec is retired. All signs are pointing to add-on support in Fenix before Fennec is retired (though again, nothing official beyond chatter in issues).

                                                                        1. 4

                                                                          Does anyone know if this is intended to be a separate product, or if it a test ground and would eventually replace Firefox on Android, and carry the Firefox name instead of Fenix.

                                                                          Fenix, if I remember correctly, was the original name of Mozilla’s Android browser.

                                                                          1. 4

                                                                            It will replace the old Firefox for Android browser. Fenix is the internal code name (just like the old browser’s code name is Fennec), and won’t be branded that way to the public.

                                                                            1. 1

                                                                              Fennec

                                                                              ah.. that’s what I remember. The little fox with the huge ears.

                                                                            2. 1

                                                                              I believe that it is expected that Fenix eventually becomes the “regular” Firefox for Android.

                                                                            1. 13

                                                                              Interesting post on the blue site

                                                                              Quoted here:

                                                                              I maintain the IRC server software that Mozilla IRC uses. I used to be in contact with the person who managed the Mozilla IRC server but they passed responsibility onto someone else and in the years since the new person has not bothered even once to reach out to us about solving their issues with IRC.

                                                                              We have plenty of solutions available to deal with the kind of problems they claim to be having. If they want they can make it so people need to be logged into accounts to interact with channels/other users to solve abuse/spam they can do that. If they want a fancy modern client UI then there is several modern interfaces which are very accessible (IRCCloud, The Lounge, Kiwi IRC, etc).

                                                                              Ultimately it seems to me that they are just making a knee jerk reaction and deciding to jump to some other platform without knowing what they want to move to and without actually looking into seeing if any of their problems are solvable. ¯_(ツ)_/¯

                                                                              1. 8

                                                                                That post has been pretty thoroughly debunked (the author posted the same comment to multiple threads). Mozilla does have the spam mitigations they mention enabled. Mozilla does have a corporate IRCCloud license. This is not some ill-considered knee-jerk reaction borne out of incompetence. It has been considered at great lengths and been a very long time coming

                                                                                While I’ll personally be sad to see irc.mozilla.org go, I understand why it is necessary and am on-board with the decision.

                                                                                1. 14

                                                                                  Perhaps it would be useful to explain why they’re insufficient, rather than just saying that you have them.

                                                                                  1. 8

                                                                                    I just fear that a closed platform such as discord is not a good fit for open source projects in the long run. You are not permitted to use your own clients and are ultimately in a vendor lock in. Of course they can just switch again when their core team became dissatisfied at any time

                                                                                    1. 8

                                                                                      I’m not an IRC admin, so I don’t have anything to say about the moderation aspect beyond what the article says. But guessing that the fact you can’t delete hateful messages is a big part of it.

                                                                                      But for me, and I say this as someone who loves IRC, the bigger reason is that IRC excludes people who aren’t as technically savvy. Yes I’ve used IRCCloud and no, it isn’t good enough. The only way to get persistent messages is to either pay for a service (not fair to ask contributors to do this, especially those from developing countries), or set up a bouncer/relay (this might be easy if you are an old Unix hand, but not so much for most people). And besides, hosting your own bouncer costs money too.

                                                                                      Even the passage you quoted says “logged in accounts”. Making an account on IRC is hard. I remember the first time I connected to IRC to play a game of Star Fury, and it was enormously intimidating. That’s not a barrier that I want a young contributor who doesn’t have the greatest handle on English to need to surpass.

                                                                                      It’s been linked elsewhere in this thread, but the author of this article’s other post is a pretty great read: http://exple.tive.org/blarg/2018/11/09/the-evolution-of-open/

                                                                                      This is bittersweet for me, irc.mozilla.org has been a huge part of my life for almost ten years now. But it’s the right call.

                                                                                      1. 4

                                                                                        But guessing that the fact you can’t delete hateful messages is a big part of it.

                                                                                        You can’t not delete them: every message is immediately thrown away by the server. This is one of my main complaints with IRC.

                                                                                        Also, I find it somewhat fascinating that the complexity (or even impossibly) of understanding the software stack that you use is swept under the rug in that whole article.

                                                                                        It talks about controlling your own destiny, but how can you do that if you can’t even implement the basic protocols?

                                                                                        Making an account on IRC is hard. I remember the first time I connected to IRC to play a game of Star Fury, and it was enormously intimidating.

                                                                                        Seems like it would be easy to improve. Anything from an out of band sign up page to a /msg from a bot on joining.

                                                                                        (Also, the implicit assumption here about the ability of these people’s ability to use a chat program is a bit… uncharitable, don’t you think? I know I would be insulted if you told me IRC was too hard for me to use.)

                                                                                        None of the reasons listed for shutting IRC down make sense, and all of them sound to me like someone higher up just liked slack and wanted an excuse to switch to it.

                                                                                        In spite of weaker moderation tools.

                                                                                        1. 4

                                                                                          Seems like it would be easy to improve. Anything from an out of band sign up page to a /msg from a bot on joining.

                                                                                          Maybe. IRC was “easy to improve” for years, I have yet to see those improvements happen.

                                                                                          And no, I don’t want to improve it, because I have a project to run and not write web interfaces for my chat tool.

                                                                                          None of the reasons listed for shutting IRC down make sense, and all of them sound to me like someone higher up just liked slack and wanted an excuse to switch to it.

                                                                                          Mozilla already uses Slack for internal discussion, but it will probably not be the replacement for community discussion, precisely because of bad moderation.

                                                                                          I don’t agree that the reasons don’t make sense, irc.mozilla.org is a constant target of abuse and just the cost of abuse handling is very high.

                                                                                        2. 4

                                                                                          I’m kind of glad that the IRC server can’t reach into my client and delete messages from its memory. I can do that myself if I want to. While it tends not to really happen in professional settings, it makes me annoyed and confused when I see messages disappear from the history of e.g. Twitch chats. It’s as if I’m being punished for another user’s transgression. Why don’t I get to know what happened?

                                                                                          1. 6

                                                                                            The point here is that we can delete harassment targeted at specific users or groups before it reaches them. There’s no use in receiving abuse and just deleting it yourself.

                                                                                            Spreading lies and attacks is pretty common and I see a case for deleting them before they are pushed towards other clients.

                                                                                            Also, no, I don’t believe you have the right to receive a full log of all message that were sent to our network.

                                                                                            All of the things above happen frequently on irc.mozilla.org, so they bring a big load.

                                                                                            1. 2

                                                                                              I’m not saying I should receive a full log of all messages that were sent to your network. I’m saying I should be allowed to keep a full log of all messages that were relayed to me. I respect that some other people might not want that, but I think a feature that deletes stuff from my personal copy of the history should at least have an opt-out.

                                                                                              I think I’m fine with actually deleting messages before they’re sent to people, or rejecting them at the time of the receipt.

                                                                                              I’ve certainly lamented the ability to retroactively make people’s clients unsee drive-by spam and harassment, but I think there’s plenty of room to get better at dealing with it (both technically and socially) without resorting to rewriting history.

                                                                                              1. 4

                                                                                                I’ve certainly lamented the ability to retroactively make people’s clients unsee drive-by spam and harassment, but I think there’s plenty of room to get better at dealing with it (both technically and socially) without resorting to rewriting history.

                                                                                                This is not even in spite, I’m sure a lot of protocol designers would like to speak to you. I like your optimism to improve socially, but I have to keep my communities safe, now. Targeted harassment is real and behavioural education won’t make it go away soon.

                                                                                                And the fact is that the Rust project deals with people joining our venues, spreading misinformation (and we’re very conservative flagging as such) and attacking people on a regular basis. IRC is by far the leader. We need a solution for that and clients that heed “delete” updates is currently what we have. You can use a client that ignores them, but yeah, that’s what we have.

                                                                                                1. 1

                                                                                                  How can you delete messages before they end up in other clients? Does Discord support this? How scalable is that?

                                                                                                  I know there is auditorium mode on Undernet IRC, where only channel managers receive all messages from unidentified users, and have to acknowledge them manually before they will be posted for everyone else to see

                                                                                                  1. 2

                                                                                                    There’s a ton to consider here. I’ll only talk about the case where clients read all messages. (In IRC, that needs a bouncer or similar)

                                                                                                    • The model of the server: If the client is only connected while the user is active, you can obviously delete messages for all clients who have not read the messages.

                                                                                                    • If a message has reached the client (in IRC in all cases), you can send a message asking them to ignore and delete a previous message. This is a best effort, but most clients heed that.

                                                                                                    • In federated systems, there’s obviously the problem that not only clients, but also all federated servers need to cooperate.

                                                                                                    • As you describe, pre-screening is a good option in networks that expect a lot of abuse. I do that for YouTube comments and I have to delete ~50%.

                                                                                                    TL;DR: you need the clients to cooperate.

                                                                                                    Deletions always get the reputation of censorship, but indeed, there’s good reasons for having and heeding those in a cooperative fashion.

                                                                                                    • They are an effective tool for abuse handling. Abuse is often aimed at emotional pressure towards a victim. A standard strategy is deferring a trusted party to filter your messages. Abuse victims let other people pre-read their email or twitter DM. Deletion messages support this workflow on a server-wide scale.

                                                                                                    • Chat networks are used to spread illegal info/pictures/content. Informing clients of this to take appropriate action is good practice. Even in a federated network, allowing the origin server to inform other federated servers that a message probably shouldn’t be kept is a good thing to have.

                                                                                                    • Spam is real, keeping peoples clients clean without their interactions is improving their lives.

                                                                                                    I trust the chat operators of my networks, which is why I would never run a client that ignores deletions. I’m not alone in this.

                                                                                                    In the end, it’s a best effort and is highly dependent on the exact model of your network, but cooperation makes a lot of sense.

                                                                                  1. 13

                                                                                    Classic Mozilla-style decisionmaking:

                                                                                    Hey everybody, we’re going to be deprecating our thing in a few months. Not only are we not at the point where we can begin proofing the thing we’re going to replace it with—and then going to spend the intervening time doing exactly that—but we actually have no idea what the replacement is even going to be.

                                                                                    (FWIW: I hate IRC.)

                                                                                    1. -1

                                                                                      inb4 slack

                                                                                      1. 9

                                                                                        Worse - Discord.

                                                                                        1. 2

                                                                                          Please note that the Rust project was not involved in any decisions and is also not part of any evaluations. (We also didn’t want to)

                                                                                          We were just pre-informed and still have 2 active community channels and a working group there.

                                                                                        2. 4

                                                                                          Half the company already uses slack. The other half still uses irc. It’s maddening. Any given solution will be better than the current situation.

                                                                                      1. 2

                                                                                        Great list, thanks! I’m going to share this around at my company.

                                                                                        1. 7

                                                                                          I have to say, pipenv was a little disappointing. I have the feeling that it was too often recommended as the solution for everything, before it had a chance to stabilise. I’ve switched back to using pip-tools.

                                                                                          1. 8

                                                                                            You might give Poetry a shot. I realized how frustrating Python’s tooling was after a recent year-long stint at a Rails shop, was equally disenchanted with Pipenv, then found Poetry, and have been very happy since.

                                                                                            1. 1

                                                                                              Thanks, yeah I’m trying out poetry now and am happy so far. It doesn’t seem to support C-extensions so I can’t move all my projects over. But baby steps, I guess.

                                                                                            2. 4

                                                                                              As another formerly disappointed pipenv user, poetry is great!

                                                                                            1. 1

                                                                                              I can’t speak for my co-workers who compete and win pwn2own, but this seems like some seriously odd posturing… If the vuln is something like an overflow or a use after free it literally might be as easy as changing one character or line. Without context it’s relatively meaningless and honestly makes them seem more petty in my eyes.

                                                                                              1. 9

                                                                                                Pretty sure they mean fixed, built, validated and shipped across all channels and platforms.

                                                                                                1. 6

                                                                                                  Nothing on the actual page linked has the “fixed in less than 24h” language; I think that may have been editorializing by the OP. The linked page is just a regular old security advisory.

                                                                                                  1. 1

                                                                                                    I agree, I guess this thread may need a title change.

                                                                                                1. 3

                                                                                                  Respectfully, is that something an org can brag about?

                                                                                                  The time-to-patch metric heavily depends on the nature of the bug to patch.

                                                                                                  I don’t know the complexity of fixing these two vulns, surely fixing things fast is something to be proud of, but if they don’t want people pointing fingers at Mozilla when a bug stays more than one week in the backlog, don’t brag about it when it doesn’t in the first place.

                                                                                                  1. 18

                                                                                                    Assuming that the title refers to fixing and successfully releasing a bugfix, a turnaround of less than 24 hours is a huge accomplishment for something like a browser. Don’t forget that a single CI run can take several hours, careful release management/canarying is required, and it takes time to measure crash rates to make sure you haven’t broken anything. The 24 hours is more a measure of the Firefox release pipeline than the developer fix time; it’s also a measure of its availability and reliability.

                                                                                                    1. 10

                                                                                                      This. I remember a time when getting a release like this out took longer than a week. I think we’ve been able to do it this fast for a few years now, so still not that impressive.

                                                                                                    2. 6

                                                                                                      As far as I can tell, the org isn’t bragging; the “less than 24h” boast is not present on the security advisory.

                                                                                                      1. 1

                                                                                                        To be fair, you’re right.

                                                                                                      2. 2

                                                                                                        also the bugs are not viewable - even if logging in

                                                                                                        so its hard to get any context on this

                                                                                                        1. 2

                                                                                                          Is it possible to check the revisions between both versions, and they do not seem so trivial.

                                                                                                          These are the revisions (without the one that blocks some extensions):
                                                                                                          https://hg.mozilla.org/mozilla-unified/rev/e8e770918af7
                                                                                                          https://hg.mozilla.org/mozilla-unified/rev/eebf74de1376
                                                                                                          https://hg.mozilla.org/mozilla-unified/rev/662e97c69103

                                                                                                          1. 1

                                                                                                            Well, sorta-the-same but with the context is them fixing pwn2own security vulnerabilties with less than 24 hours 12 months ago

                                                                                                            https://hacks.mozilla.org/2018/03/shipping-a-security-update-of-firefox-in-less-than-a-day/

                                                                                                          2. 2

                                                                                                            Respectfully, is that something an org can brag about?

                                                                                                            I always assume it’s P.R. stunt. Double true if the product is in a memory-unsafe language without lots of automated tooling to catch vulnerabilities before they ship. Stepping back from that default, Mozilla is also branding themselves on privacy. This fits into that, too.

                                                                                                            EDIT: Other comments indicate the 24 hrs part might be editorializing. If so, I stand by the claim as a general case for “we patched fast after unsafe practices = good for PR.” The efforts that led to it might have been sincere.

                                                                                                          1. 2

                                                                                                            I mostly build stuff for my own consumption, often to play with new web technology. I mostly run Chrome and derivatives so that’s what I test and develop on.

                                                                                                            I wish there were more choices but everything else has some showstopper problems for me. IE and Safari don’t run on most of my computers. Non-Safari WebKit seems to be struggling, and in general WebKit is lagging in features. My negative experiences with Mozilla as a company and Firefox as an open source project make me disinterested in investing in their ecosystem.

                                                                                                            1. 18

                                                                                                              My negative experiences with Mozilla as a company and Firefox as an open source project make me disinterested in investing in their ecosystem.

                                                                                                              This statement perfectly captures the problem outlined by the article. There is no Mozilla ecosystem, only a web ecosystem. An ecosystem which is at risk of becoming one with the Chrome ecosystem.

                                                                                                              A rich and diverse web ecosystem is a benefit to you and everyone else, no matter your opinion on Mozilla or any other browser vendors.

                                                                                                              1. 16

                                                                                                                That’s funny, my negative experiences with Google as a company and Chrome as an EEE project make me disinterested in investing in their ecosystem.

                                                                                                                1. 1

                                                                                                                  I forgot what EEE stood for and had to look it up. With that in mind: well put!

                                                                                                                2. 1

                                                                                                                  My negative experiences with Mozilla as a company and Firefox as an open source project make me disinterested in investing in their ecosystem.

                                                                                                                  In the context of what we’re discussing, that’s like saying that a well-run autocracy is preferable to a work-in-progress democracy. If you want to see why most people aren’t on the same page with you on this, just change a few words to shift the perspective:

                                                                                                                  My negative experiences with Google as a company and Chrome as a closed source project make me disinterested in investing in their ecosystem.

                                                                                                                  Firefox being inconvenient is all the excuse you need for your personal projects. I’m not sure what your negative personal experiences with Mozilla/Firefox are, but when you put these experiences so vaguely, you’re not really arguing anything.

                                                                                                                  1. 2

                                                                                                                    I’ve worked on several Gecko based open source browsers and Mozilla were hostile and seemed to see us as a threat to the Firefox product. Bugfixes to address issues Firefox users were seeing were rejected. I’ve wasted enough of my life trying to treat them as a well intentioned part of the open source / open web community.

                                                                                                                1. 2

                                                                                                                  To solve the first problem Mozilla uses mercurial and a home grown ci system called taskcluster. We have heuristics to determine which tasks should run for a given push.

                                                                                                                  For the second, we use phabricator with some custom tooling to allow submitting a series of commits, provide automated review comments (e.g for linting), and automated landing from the web UI. It’s the best review experience I’ve ever used and I can’t stand going back to GitHub anymore.

                                                                                                                  1. 0

                                                                                                                    Each commit should be a self-contained change

                                                                                                                    Couldn’t agree more! For anyone curious to learn about this in more detail, this practice is often called ‘microcommitting’ and there are many articles on the topic.

                                                                                                                    1. 5

                                                                                                                      Microcommitting is basically the polar opposite of what I’m advocating for in this article.

                                                                                                                      1. 1

                                                                                                                        I think I have a different (and possibly erroneous) understanding of what microcommitting is then, because my definition is pretty much exactly what you said in that paragraph. I also don’t understand how even the most extreme definition of “microcommitting” can be the polar opposite.

                                                                                                                        To me microcommitting is making self-contained commits that are as small as possible but no smaller, with heavy emphasis on that last part.

                                                                                                                        1. 1

                                                                                                                          Microcommitting in the view of the broader internet seems to be going so far as to set up a cronjob that does git add -A && git commit -mbullshit every 5 minutes, which is pretty much the opposite of committing with discipline.

                                                                                                                          Note that my approach doesn’t always mean small commits - sometimes commits written with this approach are relatively large due to the difficulty of splitting it into smaller pieces.

                                                                                                                          1. 3

                                                                                                                            Microcommitting in the view of the broader internet seems to be going so far as to set up a cronjob that does git add -A && git commit -mbullshit every 5 minutes, which is pretty much the opposite of committing with discipline.

                                                                                                                            This is a practice that doesn’t even deserve a label to describe it, but if I had to choose, would use “folly”. I honestly had no idea the term was sometimes used to describe this type of workflow (maybe it’s more popular in webdev circles? If so might explain why I haven’t come across this usage).

                                                                                                                            As an aside, it’s fascinating to me how people can interpret terms differently. If microcommit really means what you said above, I wonder what the best word for this approach is. Disciplined committing seems like it could also be interpreted a myriad of ways.

                                                                                                                            Note that my approach doesn’t always mean small commits - sometimes commits written with this approach are relatively large due to the difficulty of splitting it into smaller pieces.

                                                                                                                            Yes, this is my understanding as well. Your commits shouldn’t be small just for the sake of it, and should make sense on their own first and foremost. Reading down the thread here, I tend to side with @JordiGH in preferring changes to be split out for reviewability (as long as the split out changes are still sensible in their own right). I’ll admit that determining “sensible” is as much art as science.

                                                                                                                            1. 1

                                                                                                                              I find it difficult to find commits that are too large yet impossible to split up. I can usually find a way to split them up. Exceptions are stuff like running a linter on the entire codebase, although I have seen people prefer to split that up into one commit per file linted, which I’m not sure I agree with.

                                                                                                                              The boundary I try to find is, how much of this change is it possible to reject while still accepting the rest? One of the big (historical?) advantages of atomic commits was to allow partial rejection of a change while still allowing the rest to progress, without breaking anything.

                                                                                                                              I find it’s easier to get stuff through code review if it’s possible to concede points on some rejected portions while getting the important stuff approved.

                                                                                                                              1. 1

                                                                                                                                Consider “Add support for XYZ”. You could split this up into:

                                                                                                                                • Prepare module A for XYZ support
                                                                                                                                • Refactor module B for X support
                                                                                                                                • Add YZ types to data structure C
                                                                                                                                • Update module D to consider XYZ

                                                                                                                                But honestly I’d rather just see “Add support for XYZ”.

                                                                                                                                1. 2

                                                                                                                                  And yeah, I’d prefer to see those four commits, because I find that easier to review.

                                                                                                                                  Is this correctly preparing the module? Yep. Easy, approve. Go on.

                                                                                                                                  Do I like the refactored module? Wait, no, that should be done differently. Let’s do this later.

                                                                                                                                  Add types? Sure, that seems fine. Let it through.

                                                                                                                                  Update the other module? Sure, this one is fine, the change is easier than a refactor.

                                                                                                                                  If a commit makes sense on its own and it’s better than not having the commit, however small that improvement may be, it’s helpful to have it on its own.

                                                                                                                                  1. 1

                                                                                                                                    Some degree of discretion is of course necessary here for bigger changes, but I suppose we’ll have to agree to disagree on where to draw the line.

                                                                                                                                    1. 1

                                                                                                                                      FWIW, I agree with JordiGH - I’d prefer to see these as separate commits too.

                                                                                                                        2. 2

                                                                                                                          The handful of articles I just read about ‘microcommitting’ seem to indicate that it’s just ‘saving whatever you have at very frequent intervals’ and less about ‘committing self-contained changes’. I highly doubt that anyone could crank out self-contained changes at intervals of 1-5min (or even less) for prolonged periods that ‘microcommitting’ preaches.

                                                                                                                          1. 1

                                                                                                                            It’s possible I’ve been misusing the term microcommitting then. My definition is making self contained changes that are as small as possible but no smaller. Each commit needs to be self-contained, pass tests, etc, but should tell a larger story alongside the other commits in the series.

                                                                                                                        1. 7

                                                                                                                          The development iteration cycle for Firefox is pretty shameful. Since you were only touching XUL, you really didn’t need to do those multiple, hour+ long builds. You could have popped open those files in Emacs—because they’re just text and remain text, even after being converted into build artifacts—then edited and saved them and tested your changes.

                                                                                                                          As one longtime contributor once said, and I’m paraphrasing, touching the Mozilla codebase sucks and testing your changes is too slow, “that’s why [he] decided to do as much as [he] can in XUL and JS [instead of C++ which does require doing a proper rebuild]”.

                                                                                                                          The reality is that it doesn’t have to be this way, that all the plaintext declaration, configuration, and logic could be as easily editable as your elisp customizations, but to even get to the point where your plaintext changes are picked up means you have to (a) already have some familiarity and insight to mozilla internals to figure out how to make that happen; and (b) still have to spend, the first time during your setup, maybe a quarter of the length that a single build would have taken, and where you instead are having to poke at configuration options, setting up symlinks, and writing swapout scripts.

                                                                                                                          This is a more general problem—more projects than just Mozilla are afflicted and not necessarily in regard to the specifics I’m describing here—but there is a commonality among them. I wrote a little bit about this problem before in a brief post titled Nobody wants to work on infrastructure. I make the case that if you have a project, especially one with funding, then not directing your paid help towards building the necessary infrastructure to ease the lives of your unpaid help is “like finding a genie and not checking to see if your first wish could be for more wishes”. The Oil Shell maintainer last year pointed out that this is given a little bit of coverage in a chapter of CATB, and Andy Chu from oilshell.org refers to it as “parallelizing” the project’s development. (You’ll be interested, maybe, in how one of ESR’s examples is in the MATLAB community, to the extent that any openness exists there.)

                                                                                                                          This is something I’ve spent a lot of time thinking about over the last year, and maybe a tenth of that time writing code and experiments. triplescripts.org is going to launch towards these purposes and will exist as one part tool “vendor” (as a FOSS project), and two parts advocacy group meant to organize and promote the ideals of the group, even if you aren’t using the tooling. With regard to the specifics of the suggestions coming out of the group, I expect there will be intense pushback, but it’s plain as day to me that this is how things will evolve—because they have to, because nobody has enough time to waste away on the setup involved in the “implicit step zero” for every project they want to dive into—and because those projects that do evolve in that direction will be able to outpace those that don’t, and will end up thriving at a great advantage, just like natural selection’s role in real world biological evolution.

                                                                                                                          1. 8

                                                                                                                            The development iteration cycle for Firefox is pretty shameful. Since you were only touching XUL, you really didn’t need to do those multiple, hour+ long builds.

                                                                                                                            That’s not really fair as OP was using apt build-dep rather than set up Firefox’s development environment. From the article:

                                                                                                                            I didn’t want to figure out how to clone its repo, how to setup a development environment, how to configure the build, what kinds of builds there are, and how to integrate all of this with my operating system. Luckily, someone else has already done all of this work for me: the Debian packagers.

                                                                                                                            I’m not saying OP made the wrong decision for his use case or anything, but we do put a lot of energy into improving Firefox’s development experience (this is coincidentally what I work on, though not so much build related). It sounds like people on IRC were suggesting the appropriate build type (artifact builds) for this use case. Fwiw, my build times are typically ~1-2min.

                                                                                                                            1. 4

                                                                                                                              I still think it is shameful, although it’s mostly not Mozilla’s fault. It’s just that Firefox is written in C++ and C++ ecosystem lacks uniform build system and therefore C++ projects are uniquely hostile to casual contributors.

                                                                                                                            2. 5

                                                                                                                              Firefox incremental builds usually take about three minutes for me. Mach still does a little bit more crap than just rebuild changed files and relink, but it’s not like building from scratch. It’s still not instant, linking libxul (especially with debug info) even with lld takes a minute or two (or more on a slower CPU), but it’s not hours.

                                                                                                                              OS package build systems are designed for correctness and reproducibility, not for development. They want you to always just nuke the whole build directory and start over. There are sometimes ways around that. In FreeBSD Ports, you can rm work/.build_done* and make restage reinstall :)

                                                                                                                              BTW, the web inspector works on XUL, but I’m not sure if keybindings could be changed from there.

                                                                                                                              1. 1

                                                                                                                                I figured there was some processing to be done on the XUL files after the build. When I look at the list of files in the Debian package, I don’t see anything obvious in there that corresponds to the files I modified. It was easier to wait a total of six hours for the build and do something else in the meantime (I watched some TV) than to try to figure out how to reduce the build times, or avoid building altogether, as you say.

                                                                                                                                Man, it would be so cool if Firefox’s config could be as versatile as elisp, but I thought they were explicitly moving away from that by locking out extension authors out of XUL?

                                                                                                                                And yeah, making the code more easily hackable seems like a huge wish to ask of the genie. I think in general, nobody wants to know how anyone else’s code works. That’s why we build interfaces, abstractions, wrappers: so we can avoid having to figure each other out. It felt to me like Firefox was thriving the most when extension authors could do just that, and I hope the direction they’re taking it is worth it in the end.

                                                                                                                                Oh, and I know what you mean about Matlab. The situation there is kind of weird because it’s kind of pseudo-open source in a limited way. Most of Matlab’s source is visible, and your license lets you change it and share it but only with other Matlab license holders. The Matlab language was always intended to be simple enough to allow modification by “non-programmers”, as Matlab users often call themselves.

                                                                                                                                It’s a good example. Maybe Julia one day will achieve something similar.

                                                                                                                                1. 4

                                                                                                                                  I figured there was some processing to be done on the XUL files after the build.

                                                                                                                                  I don’t contribute to Mozilla anymore, and I’m not going to dive deep into this case, but from a quick glance at the file paths alone, the .xul and .dtd files will be fully intact, while the .inc files will be preprocessed, but in some trivial way that could be done by hand (e.g., “let’s copy and paste this file’s contents as a block into the file that includes it”). Not frictionless or fun, but still less exasperating (provided that you’ve already got step 0 behind you) than a test-and-debug cycle with latency measured not just in minutes, but on the order of hours.

                                                                                                                                  When I look at the list of files in the Debian package, I don’t see anything obvious in there that corresponds to the files I modified.

                                                                                                                                  They’re usually ZIPped during the build and end up living in one or more JARs, so you won’t be able to spot them with find(1), but they’re there and accessible to anyone wielding unzip or file-roller.

                                                                                                                                  Man, it would be so cool if Firefox’s config could be as versatile as elisp

                                                                                                                                  I’m mostly referring to the straightforward, no-build workflow of editing plain text with fast turnaround, rather than any kind of inherent lispiness. In the case of fx, it’d be JSON and JS, not elisp.

                                                                                                                                  but I thought they were explicitly moving away from that by locking out extension authors out of XUL? ¶ And yeah, making the code more easily hackable seems like a huge wish to ask of the genie.

                                                                                                                                  Right. Like I said, it doesn’t have to be this way. But it really isn’t that big of an ask. Things have moved in the direction of getting worse, not better (hence why I don’t fritter my time away on Mozilla anymore). And Firefox Corp is something like 5–10 times as well-funded now as they were when Firefox was actually effective at being a force for good and demonstrating that it might take over the world, instead of, you know, doing ads and corporate partnerships and then lying about not getting any money.

                                                                                                                                  (Caveat: maybe in fact things have changed so much that doing a rebuild really is the only feasible way even for JS and XUL changes. On the other hand, I made a passing comment recently-ish that building Firefox took around 2 hours and some naysayer showed up to say that wasn’t even close to true. I then went off and tested by doing a fresh build, which I hadn’t done in years at that point and even without any particular itch to scratch. Turns out: nope: not wrong. It still took 2 hours.)

                                                                                                                                  Even if it were the case that things have really changed so much (and I don’t know whether it’s true, but I’m not going to waste my time again just to find out), that would really only underscore my central claim—we know it doesn’t have to be this way, because it’s a fact that it used to not be; it getting more broken is a recent development, relatively speaking (cf “code from the 90s”).

                                                                                                                                  1. 2

                                                                                                                                    (hacker of Mozilla codebases)

                                                                                                                                    Yes, there is some postprocessing that occurs. Unfortunately mach (the build system) is mostly oriented to developers that are creating the entire enchilada, not focused front end changes without building an entire test browser, so this kind of usage is not well catered to. Good on you for sticking with it.

                                                                                                                                    I should add that building Chromium is no picnic, either.

                                                                                                                                    1. 13

                                                                                                                                      Fixing this kind of problem in Chromium has always been a nightmare; fixing it in Firefox has only been bad since 57.

                                                                                                                                      The main difference to me is that when I talk to Mozilla people about it, they reply something like “oh, that’s annoying. it’s too bad it doesn’t work better.” but when I asked Chromium devs about it they said “of course you can’t change the key bindings; can you imagine what kind of crazy bug reports we’d get from users if we let them rebind keys? never going to happen.”

                                                                                                                                      1. 3

                                                                                                                                        mach (the build system)

                                                                                                                                        One thing I liked about my approach is that I didn’t have to learn anything about this. Of course it’s a tradeoff. If I ever really get involved in Firefox development, I’ll need to learn about it. For a one-off thing, though, I was able to remain ignorant.

                                                                                                                                        1. 1

                                                                                                                                          I wouldn’t say that Mozilla is much better than Chrome in general, maybe in a few limited circumstances.

                                                                                                                                          This whole tale reminds me of the time I didn’t exercise software freedom on Firefox, but just switched to a proprietary browser (Vivaldi), because I just couldn’t take Mozilla’s **** anymore. :-/

                                                                                                                                          Breaking the world with 57 was bad enough, but when they re-did the navigation bar and changed the navigation bar UI editor to not let you remove elements from the navigation bar? Sorry, that’s just a cruel joke.

                                                                                                                                          That’s when I realized that I’m probably not Mozilla’s target audience anymore and moved on after more than 15 years of Phoenix/Firebird/Firefox.