1. 2

    Fantastic work.

    I’m always pleased to see new Emacs packages being released, even if their goals are modest - like removing the clutter of defuns scattered throughout my own func.el!

    1. 1

      Thanks! That was exactly my intention with this package! ;)

    1. 4

      I love many of the technologies listed in this article, but of the ones listed, GNOME is probably the only one a non programmer could use. I’d grant a few more if the target audience is tech savvy sysadmins that don’t “code.” But even most sysadmins would be capable of hacking up a shell or python script to get the job done, which is still programming…

      1. 1

        In this day and age it becomes increasingly relevant to know bits and pieces of programming, even for non-programmer jobs. Many highschools have already started teaching basic programming. It’s a skill that is generally useful enough. I believe it’s not too far fetched as a non-programming computer user to batch process some data for instance. What we deemed an exclusive skill of professional programmers some years ago may slowly enter the mainstream ;)

        Regarding the tools other than GNOME: It seems that most comments in this thread agree that Tor Browser is somehow too hard to use. I think this is something that’s worth debunking. There is very little education required behing using Tor and it is a very precious tool for everyone’s privacy.

        1. 2

          In this day and age it becomes increasingly relevant to know bits and pieces of programming, even for non-programmer jobs.

          I believe it’s not too far fetched as a non-programming computer user to batch process some data for instance.

          Oh, I agree – and I think non-programmers would (eventually) find these tools useful, particularly if they silently worked in the background with minimum setup (e.g. filesystems). My qualm is that, even if they were capable of installing/configuring most of these tools, most non-programmers wouldn’t be able to utilize the power-user features without putting in some serious effort. For example, Guix is largely useful because of reproducible builds/environments, but to set those up, you need to be able to read/write Scheme.

          Two of the key skills that programmers have (that non-programmers will have a hard time picking up) is the ability to recognize what can be automated, and the ability to debug problems. And you really need those to skills to be able to effectively use most of the tools listed.

          […] Tor Browser is somehow too hard to use. I think this is something that’s worth debunking.

          Yeah, I don’t think Tor Browser is that hard to use, but I don’t think most people will bother trying to understand how it works. They’ll just think there’s magic “anonymization” happening and will proceed to log into their Facebook account, invalidating the usefulness of Tor and tying the traffic back to their identity. Even Tor requires a basic understand of how the web fits together.

          Another disagreement I have is with the choice in introductory programming language. Python is far more popular and broadly supported than Racket, has more “useful” packages, and more documentation [1].

          Now, I say all this as someone who’s thinking about pragmatic users who want to put in minimal effort. They want the computer to work without much friction. They absolutely do not want to have to learn new things to get the same job done. This is a broad portion of the population, but may be a different audience than what you are considering.

          These tools are great to introduce to people if they’re legitimately interested in learning them (i.e. things that would be useful to include in an introduction to programming curriculum). Scheme is a much better language to teach if you want to give someone a “classical” foundation in computer science (students can read books such as SICP and the Little Schemer which give a strong foundation in programming concepts. Much better than the plethora of garbage CS101 college textbooks floating around). Git is an absolute necessity for basic SDLC (it’s amazing they still don’t really teach it in college). Emacs and Vim are better text editors than VSCode or Notepad++. But most people, especially those who’ve been using bad tools for years, will consider these things “too hard” and will just go back to their Excel sheets and VB scripts…

          On an unrelated note, I read through the rest of your site, and thought your Guix posts were awesome. I’m now inspired to give Guix another shot so I can have my setup ready to go as a profile :)

          [1] I do actually prefer Racket docs to Python (I feel they provide better descriptions/examples), but they are much sparser. Racket code quality is also generally better than Python, so I’m usually less frustrated when I have to jump into source code to understand a package’s functionality. I still end up using Python over Racket for most projects, though.

          1. 1

            Thanks for the praise, very much appreciated! Give Guix a go, it’s a must today and it’s only getting better ;)

            You made a very good point: I’m not targetting the broadest audience, only those with genuine technical interest. As pointed out in the comments here, it’s not clear enough in the introduction :p

            Guix: Actually, no, you don’t need scheme for its most important features:

            • Roll backs (a.k.a. unbreakable system).
            • Guarantees and privacy protection (that you get from libre software + reproducibility + bootstrappability).

            I know it might come off as a surprise considering how advanced Guix is, and that’s the magic about it: most of the magic happens in the background! I can install Guix with GNOME on a techie’s computer and show them how rollbacks work: they love it!

            Tor: Actually the Tor Browser makes a genuinely good effort at “educating the user on the go”. For instance, if you go fullscreen, it warns you that your screen resolution might be used to track you. Many things can be done to educate users online.

            Racket: I’m the kind of people who like to defend quality against popularity. I know Python is more popular, and popularity alone brings its load of benefits, but Python has done enough damage already to the industry (to the world?). Recommending Python seems to me like adding oil to the fire. I want to make the world a better place and it must start from somewhere ;)

            Thanks again for your excellent feedback!

      1. 5

        What a weird article. I wonder what is left for the actual programmers’ tech list if ZFS and Git are merely layperson’s tools.

        1. 1

          Programmers are also users ;) What defines programmers is that they program the software while users simply use them. There is no fundamental reason why ZFS should be “programmers only”, it’s about storage and backups after all, most computer users deal with data storage :)

          1. 7

            I’d really like it if more people knew how to use file system file ZFS, because they’re amazing. They are magic. However. I don’t even know where to begin that conversation with any of the non-programming people I know.

            "You know the file system you use?"
            "Say what now?"
            "Don't you sometimes wish there was a better way?"
            "No? Also, again, what's a file system?"
            "What if I told you your file system could be like Git?"
            "Git out of my house?"
            
            1. 1

              I think we’ve got to consider roughly 2 groups: the tech-minded and the beginners. The tech-minded often have a rough idea of what a file system is (e.g. when they tried to exchange flash drives between macOS ans Windows). Beginners have often no clue.

              In both bases, we’ve got to start with the practical benefits:

              • Access your data in the past.
              • Automate the backup of your data.

              Then the question, usually by the tech-minded: “But won’t this use extra space on my drives / require extra performance, etc.?” Answer: “No, that’s why you need a special file system (the logic behind it) that’s smart enough.”

              Question: “Doesn’t it require a lot of work on my side?” Answer: “That’s the magic: you’ve got mostly nothing to do but schedule the backups!”

              Then a couple of demos with interfaces like snapper (or possibly better) can be shown.

              Git can be demoed in similar ways with anyone who had to write more than a paragraph of text, and GitKraken is a good example of an easy-to-use, appealing interface.

            2. 1

              Maybe a more fitting title for the post could’ve been “Hacker tools useful for everyone” or something along those lines? It would’ve avoided the artificial distinction between programmers and other users.

              1. 1

                There is a good idea there. Sadly as everyone points out in this posts, those tools are not yet for everyone. Mostly for tech-minded people.

                So maybe “Hacker tools for tech-minded users”?

          1. 8

            I find the order of the technologies a bit strange. Why start with Git and what filesystem(!) to use?

            I refuse to believe that Emacs is a good editor to introduce someone who is used to anything else… (and I love Emacs).

            1. 4

              The order appears to be based on how bold the claim the author thinks it is. This list is by someone who I believe has only ever talked to programmers.

              1. 1

                Not so much of a claim, it’s rather a discussion and I’m very open to suggestions! ;)

                I came up with this article after seeing a couple of non-programmer friends implement those ideas. This led me to the question: what if we tried to raise the bar a little and stop dumbing down / limiting non-programmers?

                Obviosly, those tools are not for everyone. It can only reach to an audience of curious and dedicated computer users.

                1. 3

                  The general idea of challenging non-programmers to develop tool literacy is a good one. However I think you forget that most non-programmers can’t even use a terminal. In my experience the hurdle to get people to use a terminal is primarily fear, but until they overcome that a lot of these tools are not that accessible (except maybe emacs ,gnome, jitsi, tor). Gnome is assuming they run linux. Jitsi and Tor is assuming they know networking basics.

                  1. 4

                    To clarify: I chose the word “non-programmers” carefully (as opposed to “beginners”) to include tech-minded people who don’t know how to program. I believe it’s a significant and growing portion of computer users.

                    “non-geeky” or “non-techie” seems to exclude those users and to target complete beginners. My article does not target complete beginners.

                    1. 1

                      I agree, but note that my article does not address all non-programmers: I target a subgroup, the one that is prone to already be using GNU/Linux, like many people in academia. I also target the tech-minded macOS users.

                      I’ve tried to emphasize this in the introduction, without being too intimidating. Maybe it’s not that clear though. What do you think?

                      1. 3

                        I applaud your attempts to explain how technology can help people who may not be aware of its benefits.

                        However, I have re-read your introduction, and your target audience is very implicit.

                        At least you should add the pre-requisite that your reader already uses Linux or other non-mainstream OS.

                        You mention image and video processing, but none of that is addressed in the further text.

                        1. 1

                          Good point, I’ll update the intro.

                          Sorry, I’m not sure I understand your point about image and video processing. What do you suggest?

                          1. 2

                            You can mention ImageMagick for batch-processing of images, and Shotwell as a DAM (digital asset manager).

                            1. 1

                              Good idea!

                  2. 1

                    *nix programmers, at that…

                    1. 1

                      I intentionally stuck to free software in this article.

                  3. 3

                    I started with Git for a few reasons:

                    • Everyone working with computers (and other people) needs some form of version control at some point.
                    • The concept of version control is refered to in multiple places in the article.

                    Why file systems in second place? No strong opinion here, but I thought that “backing up your pictures / music / video” one of the most common things to do.

                    Regarding Emacs… I know :D But I can’t think of an editor that fits the bill. Plus I need to introduce Emacs in this article to present M-x shell, which is one of the few sane ways to introduce command line to non-programmers. Indeed, one of the first reflexes of most users is to search the output, which most terminals can’t do.

                    1. 2

                      I actually don’t think Git is a bad place to start…. if you have a GUI overlay to use it with. GitKraken etc are a great way to get someone using Git without needing to overcome the terminal terror.

                      1. 1

                        Absolutely, I’ve had great feedback from non-programmers using GitKraken. A shame it’s non-free :/

                  1. 3

                    Something I forgot: the Xref buffer can be replaced by a Helm buffer, which I find very convenient to “go to definition” and for all the sly-who-* commands.

                    Still about SLY, I’ve updated Evil Collection bindings for SLY.

                    1. 3

                      What’s the engine?

                      1. 5

                        I was curious as well from the README.org in git: “Next supports GNU/Linux, macOS, and Guix with engine support for WebKit and WebEngine/Blink.”

                        1. 8

                          I would be tempted to try this, but I really don’t want to contribute to making the WebKit monoculture even worse.

                          1. 10

                            Look I am very vocal about browser monoculture and am a volunteer for Mozilla but I think you should reconsider here. Next browser has a lot going for it and the engine is not where its interesting parts are. The fact that it supports more than one engine makes it easier in the future to port to a non webkit-derived engine. A web with more user agents is always good, specially new browsers like this which are trying something different UX wise.

                            Also, remember that Mozilla doesn’t make it easy for people to build on top of their engine. It is very hard to start a browser today and not go in the webkit/blink path. For example, I wanted a Web View for Racket because I couldn’t find one, I ended up with a mvp of a webkit wrapper. I’d prefer to go with Gecko but couldn’t find how. It is not as if the developer of Next browser is actively supporting a browser monoculture, they are doing what they can and shipping a nice product with the engines that are available today. I think that is great.

                            1. 2

                              Qutebrowser supports more than one engine, and is arguably much more mature than this project.

                              1. 6

                                It is not a competition. You can support Qutebrowser, or this one, or both. The more the merrier. If instead of supporting small independent vendors, we keep pointing fingers shouting $ALTERNATIVE is better then we just end with less browsers.

                                I like Qutebrowser too, and Dillo. We need to support a diverse ecosystem, even if in terms of engines things are looking rather grim.

                                1. 5

                                  then we just end with less browsers

                                  Except we don’t actually get “more browsers” in a meaningful way; we just have the same browser over and over again with different trimmings.

                                  1. 2

                                    Yes you do. Most of the differences are happening outside the engine with different browsers packing different UX, ad-blocking and other features.

                                    I too want more engines but we don’t have more engines to embed. At the moment all the embedable engines are webkit/blink derived. MacOS WKWebView, Windows 10 is getting blink, Linux is mostly around WebKitGTK and QtWebEngine.

                                    Yes, I agree we need more web engines but the web got so complicated that no one can build them from scratch anymore. Unless devs start contributing massively to Mozilla to make Gecko embedable (checkout GeckoView which is an embedable Gecko but as far as the repo goes, there are only samples for Android), we won’t have alternatives.

                                  2. 3

                                    This is far from a ‘diverse’ ecosystem. All of these browsers use webengine or webkit.

                                    1. 1

                                      Diversity is not an absolute, it is a spectrum. It is more diverse to have more user agents even if they use similar engines but are exploring different approaches to the rest of the app than it is to have just three browsers, two of which are webkit/blink. Opera, Brave, are all blink based and some of their innovations are being adopted by other browsers. I’m sure everyone would like more engines but we don’t have them.

                                      Mozilla should throw more weight into making GeckoView work well on the Desktop so that people could build browsers with it, but even without that, more user agents is better.

                                  3. 2

                                    Indeed, and as a former Qutebrowser user myself I can say that it inspired me for many features of Next. Note that Next takes a radically different approach though: it exposes 100% of its (Lisp) code base to the user, open for configuration. The goal is to have something extremely extensible / hackable.

                                    The minibuffer UX of Next is mostly inspired by Emacs Helm / Ivy and that differs quite a lot from Qutebrowser approach.

                                  4. 2

                                    Isn’t servo easier to embed? Why not go with that?

                                    1. 3

                                      Servo is very incomplete.

                                  5. 2

                                    What do you mean? We support 2 engines (and possibly more in the future), there is no monoculture here :p

                                    1. 8

                                      Like the old joke goes: “We play both kinds of music here: country and western.”

                                      1. 3

                                        I don’t get the joke, there are two browser engines, and the chrome here is agnostic of the engine.

                                        1. 8

                                          They’re both just different variants of one Google-backed codebase; it’s still a Google monoculture.

                                          1. 4

                                            Are Google contributions being backported into WebKit? Otherwise, Google hasn’t exerted influence over WebKit since they forked off six years ago, right?

                                            1. 2

                                              I’d say it’s the other way around: Google forked WebKit. WebKitGTK is developed independently. If I understand it right, WebKit has a long history (KHTML) that predates the work of Google.

                                            2. 2

                                              The “chrome”? Did you mean the “core”?

                                              1. 9

                                                Browser chrome usually means browser ui

                                      2. 2

                                        Indeed. For now the PyQtWebengine port needs a bit of finishing but we are working on it. Soon both renderers will be equally usable!

                                    1. 3

                                      Very nice project, I admire it is done in common lisp too although that will probably prevent some devs jumping in.

                                      History tree is something new for me in the browser world (only had that in vim so far) and is awesome feature. Other things are not really new as Vimium plugin does many cool things. Other interesting thing, jumping to headers fuzzy way is also new for me, but I wonder its practicallity.

                                      I suggest adding another great vim/Vimium feature - marking position on page (m) and jumping to it latter (`). Its fantastic way to navigate over big tehcnical documents.

                                      1. 3

                                        This is a good suggestion, I’ll note it down! :)

                                        1. 2

                                          With capital letter marks for bookmarks! I imagine the power….

                                          1. 1

                                            See what I wrote down: https://github.com/atlas-engineer/next/issues/392:

                                            we could even name the marks, persist them, fuzzy-search them, etc.

                                        2. 1

                                          I think that netsurf also has a history tree.

                                        1. 3

                                          Do you have any plans for WebExtensions support? Would be the best browser.

                                          1. 1

                                            This is a very good question. To be honest, I personally don’t know enough about WebExtensions. My gut feeling is that they are way too limited compared to what Next offers. But that would not stop us from supporting them, for the sake of compatibility.

                                            What would be interesting to collect is the most popular non-trivial WebExtensions out there.

                                            1. 2

                                              There are lots of situational/not popular webexensions people use, its impossible to move them all to next as lisp extensions (or whatever exension it supports) unless it will become a mainstream browser.

                                          1. 7

                                            Self-promotion for fundraising, flagged. Cool project though!

                                            1. 4

                                              Why is this any different then people self promoting their blog articles (which they do all the time here). In 99% of cases It ultimateivelly is about end effect, which is money.

                                              1. 4

                                                I highly dispute the 99% numbers. How do you even get this idea? There are so many blogs that don’t have ads, are not trying to promote their authors, etc.pp.

                                                1. 1

                                                  Self promotion, not ads - its about better prospects on future jobs by building and influencing community around the stuff you do.

                                                  So 99% is from head, but I am sure its even higher. Or you tell me you know bunch of people, who write great technical blogs just for the sake of researching particular topic, are stuffed for life (rich family) or despise materialism and live in a barrel like 1 dude ever, and do it anonymously because they dont need any attention …

                                                  1. 12

                                                    Or you tell me you know bunch of people, who write great technical blogs just for the sake of researching particular topic, are stuffed for life (rich family) or despise materialism and live in a barrel like 1 dude ever, and do it anonymously because they dont need any attention …

                                                    This seems to be an overly cynical perspective. I write blog posts because I want to share my knowledge or some other information with the world, and I’m sure I’m not alone.

                                              2. 3

                                                Thanks!

                                                1. 4

                                                  Something on the tagging: note that tags on lobsters are block-if-any.

                                                  So, if you have a diehard emacs user that is filtering vim, they won’t see this, nor will a vim user filtering emacs, or anybody filtering web (which is usually kind of a broad tag). So, a smaller supporting set of tags is usually going to help you.

                                                  1. 6

                                                    That actually defeats the purpose of tags and looks more like categories.

                                                    The said problem is internal software thing.

                                                    In any case, about that dude filtering out emacs - I could totally live with that :)

                                                    1. 2

                                                      Thanks, didn’t know that!

                                                1. 3

                                                  If you’re wondering what browser engine this is running (as I did), it appears to be using WebKit: https://next.atlas.engineer/article/technical-design.org

                                                  More importantly, they have gone to some effort to isolate the browser engine from the UI so that it is possible to swap out browser engines without rewriting the whole browser. Interesting project!

                                                  1. 5

                                                    Next also supports Webengine (a Blink fork, the Chrome engine) through the PyQt port.

                                                    Edit: Note that the “technical-design” article is somewhat outdated. For instance, XML-RPC has been replaced by D-Bus.

                                                    1. 2

                                                      Could somebody write a gui wrapper for next browser fairly easy? Like if I wanted to add a gnome header with a menu listing buffers is there an api for hooking into that functionality from an external program?

                                                      1. 2

                                                        To clarify:

                                                        • Do you want to extend the GUI of next by adding menus, etc.?
                                                        • Or do you want to write a separate GUI that interacts with Next?

                                                        For the former, this is just about extending Next. We have plans to add a status bar, possbly buttons, a configuration page, etc.

                                                        For the latter, for now you can use the Swank protocol to send arbitrary Common Lisp to Next (and thus query anything). I’m soon planning to add a commnad line --eval option so that anyone can do it, even if they don’t speak Swank.

                                                        1. 1

                                                          I may have misread the design document. I was under the idea that Next was embeddable. So one could embed the browser in a gui (like neovim) and interact with it through rpc or dbus calls. This way somebody could write a ui that conforms to gnome or kde HIG.

                                                          With regards to the clarification, will there be a gui extension api or will the extensions have to go upstream and get merged?

                                                          1. 1

                                                            The thing is that the browser and the GUI are the same thing here. What communicates over D-Bus is just the web renderer (e.g. WebKit). Common Lisp does everything else, including manipulating the minibuffer, creating buttons, etc. The UI elements are actually web elements (HTML / Javascript).

                                                    1. 1

                                                      It turns out that the static typing example works with ECL, CCL and SBCL, as far as I’ve tested. Does this mean that “Common Lisp is not statically typed” is a common misconception, and that it would be more accurate to say “Common Lisp has optional static typing”?

                                                      1. 1

                                                        Common Lisp is strongly, dynamically typed.

                                                        1. 1

                                                          Indeed, but the linked article explains how to do static typing as well.

                                                      1. 3

                                                        In particular, I really like the examples of static typing and algebraic data type definitions.