1. 15

    Haskell is awesome, but like most languages there is cruft and legacy to be avoided. Haskell has a standard library known as base which unfortunately has a fair amount of unsafe or unperformant functions included. As such I went with an alternative standard library relude that builds on and improves base. On top of this, there are many core libraries that are not part of the standard library I wanted to use and have nice patterns around.

    Maybe I’m spoiled working in the .NET ecosystem, but large amounts of the standard library being unusable shouldn’t be considered par for the course when working with a language. This reminds me of PHP.

    Parsing Libraries […] Why is this nice in Haskell? The ‘monad’ abstraction is excellent for dealing with code with a lot of failure conditions (ie. parsing) and avoids ‘pyramid of doom’ type code. Haskell worked out really well in this key area.

    The author doesn’t really explain how monads help with parsing, but I’ve written parsing logic in C# that didn’t result in a “pyramid of doom”. I don’t think the pyramid of doom is a language issue, but an architecture issue.

    Compile Times.. Were Fine

    I thought I’d call this out as it is a common complaint I see around Haskell. […] Compile dependencies from scratch Time: 17m44s

    A 17 minute compile time is considered fine? Even the 1 minute development build time seems slow for such a small project.

    Between the compile time, the library issues, and the issues with the official standard library, I don’t understand how the author can claim that Haskell and it’s ecosystem is production-ready. Production-ready isn’t a term that means someone, somewhere, has used it in production. Also it’s important to understand that not only the language and runtime need to be ready for production use, but also the ecosystem. Without all three being stable, other languages become the wiser and more logical choice.

    I like Haskell. I’ve built several hobby projects in it. I think it’s a great language to learn to extend your development skills and think about problems in different ways. But never would I consider pushing it to be used in most production applications as it stands right now. For most companies, using it right now would be a mistake.

    Five years ago, when I first started working in it, I had hoped the language and ecosystem would mature to a point where it could be recommended for most serious projects, but seeing the lack of progress since then I’ve since set my sights on other functional languages like F#.

    1. 11

      Maybe I’m spoiled working in the .NET ecosystem, but large amounts of the standard library being unusable shouldn’t be considered par for the course when working with a language.

      The .NET standard library also has the same kind of unsafe and unperformant functions the author is talking about, the type of runtime safety he’s talking about just isn’t really a focus when working with .NET. He’s referring to functions like head which throw an exception if passed an empty list instead of returning a Maybe a, and I think we can agree that there are plenty of .NET functions that throw exceptions on invalid input.

      The author doesn’t really explain how monads help with parsing, but I’ve written parsing logic in C# that didn’t result in a “pyramid of doom”. I don’t think the pyramid of doom is a language issue, but an architecture issue.

      I agree that the author greatly exaggerated how parsing code in non-functional languages usually turns out, but if you haven’t written a parser in Haskell or using something like FParsec in F#, it really is worth it to see how nice a more functional parser library is to work with. Definitely one of the places Haskell shines.

      A 17 minute compile time is considered fine? Even the 1 minute development build time seems slow for such a small project.

      Agreed, Haskell build times are bad. Hopefully they’ll get there someday.

      1. 3

        The .NET standard library also has the same kind of unsafe and unperformant functions the author is talking about, the type of runtime safety he’s talking about just isn’t really a focus when working with .NET. He’s referring to functions like head which throw an exception if passed an empty list instead of returning a Maybe a, and I think we can agree that there are plenty of .NET functions that throw exceptions on invalid input.

        Right, but even the community explicitly mentions not using base in Haskell. With .NET that is not the case. It’s an important distinction; the community expects the .NET stdlib to be “first class” in .NET development, the Haskell community does not have the same expectation with base.

        1. 3

          Right, but even the community explicitly mentions not using base in Haskell.

          Maybe? Basically all Haskell code is still written targeting base. People have feelings about things like head and maximum and foldl, but in practise it’s at most a “maybe avoid those” tip from people with those feelings.

          1. 3

            Right but that adds a barrier to entry for new folks. There are good reasons not to use Prelude (and OP’s article brings up some of these good reasons imo), but if I were a new programmer learning Haskell, it would be get another thing I need to learn and understand. Why should I use an alternate Prelude? When? Which Prelude is better than others? Haskell has long prioritized progress and innovation over production stability which I think is a very reasonable for a language like Haskell but isn’t always the best fit for being productive.

            Edit: FWIW I think developing in Haskell is great (oh and thanks so much for working on JMP @singpolyma!). I’m just trying to say I’d love to see these barbs in the ecosystem fixed a bit. Good on the Haskell Foundation for pushing this forward, and I’d love to see more production-oriented advice (and reports, like the OPs) with Haskell.

      2. 5

        The author doesn’t really explain how monads help with parsing,

        That’s true,

        but I’ve written parsing logic in C# that didn’t result in a “pyramid of doom”

        But it’s worth reading up on the monadic parsing approach before declaring an opinion on the matter. The search term you want is “parser combinators”. It really is a fantastic approach.

        1. 2

          For what it’s worth I wasn’t really declaring an opinion, I was just saying that if they only thing you’re attempting to avoid is a pyramid of doom, there are ways to do that in other languages. I haven’t looked at Haskell parsing logic but it sounds like there are some interesting advantages it offers.

          1. 1

            There a various ways in other languages to avoid the ‘pyramid of doom’, but they are much more situational. For example, ruby has &. for null safe access ie. person&.pet&.num_legs which avoids the pyramid. However, they are very specific and break down quite easily.

            Say, you want person&.pet(if pet_type == 'cat')&.is_purring which you want to return null if any of these objects are null (or the pet is not a cat), or true/false if they are not null and the pet is cat. Probably you can do something like this in ruby, but Haskell via ‘monad’ (and friends) has highly generic and composable techniques like this that are very clean to use.

            I’m glossing over ‘monad’, it is not complex, but you need to learn the prerequisites before it makes sense. Actually I thought https://www.youtube.com/watch?v=J1jYlPtkrqQ was pretty good as a shotgun explanation if you are somewhat familiar with ruby.

            1. 2

              person&.pet(if pet_type == 'cat')&.is_purring

              This looks more like a place where I’d use a prism, in Haskell with lens I imagine it’d be person ^? pet . asCat . isPurring :: Maybe (). I’d like to know how this is a parsing issue, it looks more like a object traversal problem.

              1. 1

                Yes not a parsing problem. Just trying to explain how Haskell avoids the pyramid of doom problem in a general way that is very flexible. Whereas other languages solutions are very specific and situational.

        2. 3

          What progress were you hoping for but didn’t see? The Haskell Foundation was created to work on ways to improve the Haskell ecosystem and I’m always looking for more improvement ideas myself.

          1. 2

            It’s worth stressing that that 17m compile time is a one off cost. GHC is of course an incremental compiler, so you only pay for the graph of modules affected by a change when developing which is significantly quicker, on the of seconds, not minutes.

            1. 1

              I don’t think the pyramid of doom is a language issue, but an architecture issue.

              I haven’t seen it come up in the context of parsing but instead in chaining together asynchronous operations in languages that lack coroutines, so it’s most common in JS where nearly all IO is forced to be async. In C# you can just do normal IO so it’s not surprising it doesn’t come up. (or maybe because C# has coroutines? honestly not that familiar with it)

            1. 9

              Lmao the first example is so cursed

              git log --graph --abbrev-commit --decorate --all --format=format:"%C(bold blue)%h%C(reset) \ - %C(bold cyan)%aD%C(dim white) - \ %an%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n %C(white)%s%C(reset)"

              1. 5

                Urgh the curse of the tutti frutti.

                I think I’ve developed a physical aversion to cyan.

                1. 1

                  Attack of the Angry Fruit Salad!

                2. 2

                  That is what we have Git aliases for ;)

                  1. 0

                    That is what we have Git aliases for ;)

                  1. 2

                    A great overview.

                    I also wouldn’t pick a new system part that isn’t written in Rust (or a similar safe & efficient language).

                    Existing bits and pieces of my tech stack have Bestandsschutz, but if you try to sell me a replacement, it better be not written in C/C++ if you don’t want to get laughed out of the room.

                    1. 16

                      I also wouldn’t pick a new system part that isn’t written in Rust (or a similar safe & efficient language).

                      This reads as very cargo-cult.

                      1. 4

                        I was thinking the same thing. @soc: are you really worried about your shell segfaulting? Or being attacked somehow? What attack vector would that be? You could easily write a shell just as insecure in Rust, you’d just have different vectors.

                        1. 2

                          I’d compare C/C++¹ with greenhouse emissions:

                          Every line of C/C++ that doesn’t get written is another C/C++ piece that doesn’t need to be decommissioned later.


                          ¹ I use “C/C++” as a catch-all phrase for the shared belief of their users that they can write “safe” C/C++ – despite 50 years of evidence to the contrary.

                        2. 1

                          I really don’t care. :-)

                      1. 7

                        $200 per month in recurring costs at the end. Not bad if you’re running a business, but otherwise pretty steep for home use.

                        But I guess for home use you might as well keep the computer running 24/7… in your home.

                        1. 6

                          But I guess for home use you might as well keep the computer running 24/7… in your home.

                          Pretty much what I do, in conjunction with wireguard (proxying from a $5 VPS).

                          1. 4

                            You may want to proxy from a free oracle VPS instead (10TB transfer/month) https://www.oracle.com/cloud/free/#always-free

                            1. 2

                              What are they getting out of it?

                              1. 1

                                Your contact details, to sell to marketers.

                              2. 1

                                Oh wow thank you for linking this, seems like a great offer. Might make me actually stop paying for hosting completely.

                                1. 4

                                  You become the product there though

                                  1. 1

                                    I recently signed up for one, to use as a secondary VM. For an “always free” plan, that’s sure an excellent offer, assuming they don’t change their mind abruptly one day.

                                    1. 3

                                      they wouldn’t do that, it says “always” right on the box

                              3. 2

                                One (potential) downside of hosting out of your home is running into your ISP’s AUP (Acceptable Use Policy). Sometimes these outright forbid hosting any servers. But even for those that don’t forbid such acts, they usually have clauses that forbid serving material that is not illegal but is simply indecent, racist, or defamatory. It could prove challenging to remain in compliance if you host a site with user-generated content where even a small number of users are inclined towards posting such things.

                                1. 4

                                  Add a jump host somewhere on the net (eg. some $5/month OVH system) that routes all connections through a VPN (or Tor to an onion service, which would make it harder for the provider to tell your ISP about you) back to the host at home: CloudFlare on a shoestring budget (there are many such providers and by tweaking DNS entries you can hop relatively quickly)

                                  1. 2

                                    This doesn’t help you comply with an AUP, just circumvent it.

                                    1. 3

                                      That’s often good enough. Using encryption makes it difficult for other agents to see any details about your internet traffic, and that includes your ISP enforcing its AUP on you (which they would be very prone to enforcing selectively, that is, only if they had some reason to think you specifically were a political problem for them).

                                  2. 2

                                    Which is when you end up towards running your own ISP, or other such nonsense.

                                1. 3

                                  Wow, great illustration!

                                  Is there any extension that automatically accepts the minimum cookies for these prompts? I’ve noticed a lot of sites use the same type of prompt, and I presume it wouldn’t be impossible to automate a lot of it.

                                  1. 3

                                    There are several Firefox extensions that do it. I use consent-o-matic.

                                    1. 1

                                      That’s cool – thanks for the tip!

                                      1. 1

                                        I think the one I use is called “I don’t care about cookies”, which as a statement isn’t strictly true, but I trust the browser and various other extensions I have installed to minimise the third party cookies that are accepted or left around anyway.

                                        1. 1

                                          Would an extension like “Cookie AutoDelete” be more effective if configured to just remove all cookies the site set after the tab is closed? With that, it seems like you wouldn’t necessarily care about these bullshit ‘consent’ prompts if everything is purged when you are done with the site…

                                      1. 4

                                        Interesting about adding lazy evaluation into lisp. From my recollection the original implementation of the idea (in a research paper) was in a lisp.

                                        Henderson, Peter; Morris, James H. (January 1976). “A Lazy Evaluator”. Conference Record of the Third ACM Symposium on Principles of Programming Languages

                                        1. 5

                                          Yes, it appears that lazy evaluation was invented by Lispers (with two independent implementations of lazy Lisp both described in papers published January 1976).

                                          See also “A History of Haskell:Being Lazy With Class” https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf?from=https%3A%2F%2Fresearch.microsoft.com%2F%7Esimonpj%2Fpapers%2Fhistory-of-haskell%2Fhistory.pdf

                                          Quote: “Lazy evaluation appears to have been invented independently three times.”

                                          Another paper about an implementation of lazy evaluation in Lisp, also published January 1976, but by different researchers, was “CONS should not Evaluate its Arguments”. https://help.luddy.indiana.edu/techreports/TRNNN.cgi?trnum=TR44

                                          The third invention of lazy evaluation was in SASL, an ancestor of Haskell. SASL was redesigned to be lazy in 1976. My earliest reference for lazy SASL is “The SASL Language Manual”, December 1976, by David Turner. I believe that Haskell inherits its laziness from SASL

                                          Prior to this, there was “Correct and Optimal Implementations of Recursion in a Simple Programming Language” in 1974 by Jean Vuillemin. This paper explains the theoretical benefits of lazy evaluation in Lisp (some recursive programs do not diverge if they are lazy). But the author doesn’t appear to have implemented it. And the paper misses the key idea of lazy evaluation, which is that after you evaluate the thunk the first time, you replace it with its value. So the thunk is evaluated at most once. This paper instead talks about “call by name” (from the Algol 60 language) which evaluates the thunk each time it is used.

                                          1. 1

                                            Thanks yes. I’m guilty of simplifying down to one paper because it’s from my own school :)

                                        1. 2

                                          Semi-related: Is there anything that you’d recommend for unit testing bash scripts?

                                          1. 5

                                            Noah’s Mill, but I’m also a fan of ryes.

                                            1. 3

                                              I’ve used BATS and it’s been a good experience. If you install via Homebrew just make sure to do brew install bats-core and not bats as the latter is an older, unmaintained release.

                                              1. 2

                                                shunit2

                                                1. 1

                                                  (I’m the blog post author)

                                                  I’ve not actually tried testing bash scripts - once they get passed a fairly simple level I usually replace them with a small go binary

                                                  1. 1

                                                    I’ve looked into BATS, but the only time I bothered testing anything bash, I just ended up doing simple mocking like: https://github.com/adedomin/neo8ball-irc/blob/master/test/test.sh

                                                    of course this is testing something which would probably be considered a strange, if not mental, use of bash.

                                                  1. 2

                                                    Interesting design decision to avoid any heap allocation, even at the cost of performance.

                                                    Thinking about performance, I started to idly wonder just how much of the work could be done at compile time, if you had a better meta programming framework than C macros.

                                                    1. 4

                                                      The costs appear much greater than performance. It looks like providing an invalid regex results in memory corruption: https://github.com/kokke/tiny-regex-c/issues/30

                                                      1. 3

                                                        Yeah, when I saw this library I considered all the potential bugs possible when implementing something as fiddly as regexes in a language as unsafe as C; then I backed slowly away.

                                                        1. 1

                                                          I mean, just because it’s in C doesn’t mean it’s untrustworthy. GNU Grep is written in C (over 3K lines, not including external helpers) and seems to work pretty well.

                                                        2. 1

                                                          That issue was closed as “fixed” a year ago, about 6 months after it was opened. The code now passes analysis by KLEE.

                                                          1. 2

                                                            The response from the maintainer made it seem like it was a design decision. And also, “If you are concerned about security problems, this library is not for you.”

                                                            But good to see that it has been fixed. It looks like the maintainer has gone from “i don’t care about ub” to “let’s do formal analysis to prove it doesn’t happen.” That’s good.

                                                        3. 2

                                                          That decision is probably based on the intended platform:

                                                          Most (all?) of my public projects are designed to be runnable on embedded platforms, and usually that means I make some harsh compromises.

                                                          Static allocation makes it much easier to ensure that code won’t run out of memory on a device with very little of it.

                                                          1. 1

                                                            There is a template-based compile-time regex implementation in C++. I didn’t bookmark it, though; all I remember is it was written by a Russian woman about four years ago.

                                                            I imagine this could be done in Rust, Nim or Zig, too.

                                                            1. 2

                                                              You mean this?

                                                          1. 2

                                                            Yeah, why would you ever expect a package manager to expose a package you were supposed to use?

                                                            1. 2

                                                              The problem here is that they’re using a package manager to install a language and then using a hacky tool (virtualenv) which does some symlinking of binaries which are dynamically linked to libraries provided by that package manager, and then install and link other libraries using an entirely different package manager of which the original package manager is completely oblivious (pip inside the virtualenv), and then upgrade the underlying package against which the extension libraries were linked.

                                                              Of course this is going to break! In the extreme, think of this like installing Python 2, installing some libraries with pip and then upgrading to Python 3, and expecting those pip packages to just work without first rebuilding them against the new Python.

                                                              The real solution is to either do everything through the package manager (which means you’re stuck with whatever versions of Python libraries are provided by homebrew) or nothing (which means installing Python with some other tool).

                                                              edit: After re-reading, it seems to me Homebrew supports having multiple Pythons installed at the same time. So I guess the real problem is that it doesn’t have a mechanism to remember which Pythons you manually installed and want to keep. Or maybe it does and people are just relying on Python being installed through whatever other package and are not explicitly installing a specific version they want to rely on.

                                                              1. 3

                                                                I think you’re missing an important part of my article. The workflow you described worked very well for years, right up until Homebrew added two changes that caused everything to break, most notably the automatic cleanup that causes previous package versions to be deleted automatically.

                                                                To me, the real problem is that Homebrew does not mention this on their Homebrew and Python page. They could say, “Don’t rely on Homebrew Python versions, which can disappear at any time. You might be better off using asdf, pyenv, or Pythonz tooling to install and manage Python interpreter versions.”

                                                                1. 2

                                                                  To me, the real problem is that Homebrew does not mention this on their Homebrew and Python page.

                                                                  This would be a very helpful addition to the page. Have they refused the patch, or just not applied it yet?

                                                                  1. 1

                                                                    Fair enough; they broke something which used to work. Maybe it worked “by accident” in their vision, but if so many people relied on this accidental behaviour, it would behoove them to clearly inform users about it.

                                                                    Note that I was more responding to the parent comment than your post though.

                                                                  2. 3

                                                                    Think of this like installing Python 2, installing some libraries with pip then upgrading to Python 3.

                                                                    The problem here is that Homebrew decided to upgrade, not the user. If I upgraded to Python 3, I wouldn’t expect anything to work, but I didn’t - Homebrew did it for me without asking.

                                                                    But what I’m really complaining about is the way the article describes it as “a misunderstanding” like users should know better. It’s a package manager. Exposing packages under obvious names that the user is not supposed to install is a horrible design failure, and I don’t like the way the article blames the user.

                                                                    1. 4

                                                                      I don’t like the way the article blames the user.

                                                                      Article author here. Thanks for the constructive feedback. My initial reaction to this was, “Huh?? Did we read the same article?” Then I re-read it with your perspective in mind. And now I see your point. Allow me to explain how we got here. Short version: I was trying to be kind.

                                                                      I actually wrote this article last summer, soon after Homebrew’s changes started wreaking havoc. Around that time, a user of VirtualFish (a virtual environment manager for Fish shell that I maintain) encountered the same infuriating problem and posted an issue about it in the VirtualFish repository tracker. I responded by posting a long rant and venting my frustration with how poorly the transition to the new Homebrew behavior was managed. In that comment you will see the basis upon which my article was written, which I purposely softened so as to respect the hard work that unpaid, volunteer Homebrew maintainers put into the project, for free.

                                                                      I fear that in the process of toning down my frustration, I inadvertently left out the part about Homebrew’s culpability in neglecting to inform users about its suitability for Python development, leaving the opportunity for folks to walk away with the impression that I think the fault lies with users and their inability to understand. That was absolutely not my intention — quite the opposite. Mea culpa.

                                                                      I hope that after reading my above-linked screed, you will see that I do not hold users accountable here. Perhaps I should amend the article to make that clearer. Thanks again for communicating your perspective, which will help me express myself better in the future.

                                                                      1. 1

                                                                        Well that makes sense. Thanks for the explanation!

                                                                    2. 1

                                                                      There is still one way that it can break things even if you used another tool like pyenv to install the Python interpreters you actually use: pyenv compiles the interpreter locally, linking against the set of shared libraries you have at the time. Which doesn’t matter much for Python, except in the case of OpenSSL. Sometimes, Homebrew will “helpfully” clean up an older OpenSSL that some pyenv-compiled interpreters linked against, and suddenly those interpreters fail.

                                                                      1. 1

                                                                        Can’t you tell pyenv to link Python against the system-provided OpenSSL though? Or is that so hopelessly out of date that it’s unusable?

                                                                        1. 1

                                                                          I don’t know how it is now. I know at one point you didn’t really have a choice because the system OpenSSL was too old for things like pip to even be able to speak to the Python Package Index.

                                                                  1. 1

                                                                    I’m surprised this wasn’t just apt install cde

                                                                    For retro UIs I still like using, I prefer the next step look and feel (eg via window maker)

                                                                    1. 1

                                                                      There is a distro with packages, I’ve not tested it but here are instructions: https://www.reddit.com/r/linux/comments/jv7zra/guide_the_easiest_way_to_install_cde_common/

                                                                    1. 7

                                                                      I always wonder how much all the privacy changes going into Firefox effect measured market share. Also adblock usage, which I’d (blindly) assume to be higher on Firefox than Chrome.

                                                                      1. 13

                                                                        Mozilla has been placing ads in the German subway. (I’ve seen it in first in Hamburg, but I’ve also seen it in Cologne, Berlin and Munich) It says in German “This ad has no clue about who you are and where you’re coming from. Online-trackers do. Block them! And protect your privacy. With Firefox.” (Not my tweet, but searching for “firefox werbung u-bahn” yielded this tweet)

                                                                        I feel that Mozilla is going all in on privacy. (Context: Germany is a very private society culturally and also due to its past. Also one of the country with the highest usage of firefox.)

                                                                        1. 4

                                                                          But WhatsApp is still the main way to communicate.

                                                                          1. 2

                                                                            That’s probably true in every country. The Germans I know are all big on signal.

                                                                          2. 4

                                                                            Firefox isn’t a particularly aggressive browser on privacy though, Safari and Brave are much further ahead on this and have been for a long time. I think at this point Mozilla’s claims to the contrary are false advertising - possibly literally given that they apparently have a physical marketing campaign running in Germany. Even the big feature Mozilla are trumping in this release has already been implemented by Chrome!

                                                                            While I think privacy is a big motivator for lots of people and could be a big selling point of Firefox, I think consumers correctly see that Mozilla is not especially strong on privacy. Anyway I don’t see this realistically arresting the collapse in Firefox’s market share which is reduced by something like 10% in the last six months alone (ie: from 4.26% to 3.77%). On Mozilla’s current course they will probably fall to sub-1% market share in the next couple of years.

                                                                            1. 10

                                                                              You can dismiss this comment as biased, but I want to share my perspective as someone with a keen interest in strict privacy protections who also talks to the relevant developers first-hand. (I work on Security at Mozilla, not Privacy).

                                                                              Firefox has had privacy protections like Tracking Protection, Enhanced Tracking Protection and First Party Isolation for a very, very long time. If you want aggressive privacy, you will always have to seek it for yourself. It’s seldomly in the defaults. And regardless of how effective that is, Mozilla wants to serve all users. Not just techies.

                                                                              To serve all users, there’s a balance to strike with site breakage. Studies have shown that the more websites break, the less likely it is that users are going to accept the protection as a useful mechanism. In the worst case, the user will switch to a different browser that “just works”, but we’ve essentially done them a disservice. By being super strict, a vast amount of users might actually get less privacy.

                                                                              So, the hard part is not being super strict on privacy (which Brave can easily do, with their techie user base), but making sure it works for your userbase. Mozilla has been able to learn from Safari’s “Intelligent Tracking Protection”, but it’s not been a pure silver bullet ready for reuse either. Safari also doesn’t have to cave in when there’s a risk of market share loss, given that they control the browser market share on iOS so tightly (aside: every browser on iOS has to use a WebKit webview. Bringing your own rendering engine is disallowed. Chrome for iOS and Firefox for iOS are using Webkit webviews)

                                                                              The road to a successful implementation required many iterations, easy “report failure” buttons and lots of baking time with technical users in Firefox Beta to support major site breakage and produce meaningful bug reports.

                                                                              1. 5

                                                                                collapse in Firefox’s market share which is reduced by something like 10% in the last six months alone (ie: from 4.26% to 3.77%)

                                                                                On desktop it’s actually increased: from 7.7% last year to 8.4% this year. A lot of the decrease in total web users is probably attributable to the increase in mobile users.

                                                                                Does this matter? I don’t know; maybe not. But things do seem a bit more complex than just a single 2-dimensional chart. Also, this is still millions of people: more than many (maybe even most) popular GitHub projects.

                                                                                1. 3

                                                                                  That’s reassuring in a sense but also baffling for me as Firefox on mobile is really good and can block ads via extensions so I really feel like if life was fair it would have a huge market share.

                                                                                  1. 5

                                                                                    And a lot of Android phones name Chrome just “Browser”; you really need to know that there’s such a thing as “Firefox” (or indeed, any other browser) in the first place. Can’t install something you don’t know exists. This is essentially the same as the whole Windows/IE thing back in the day, eventually leading to the browserchoice.eu thing.

                                                                                    On iOS you couldn’t even change the default browser until quite recently, and you’re still stuck with the Safari render engine of course. As far as I can tell the only reason to run Firefox on macOS is the sync with your desktop if you use Firefox.

                                                                                    Also, especially when looking at world-wide stats then you need to keep in mind that not everyone is from western countries. In many developing countries people are connected to the internet (usually on mobile only) and are, on average, less tech-savvy, and concepts such as privacy as we have are also a lot less well known, partly for cultural reasons, partly for educational reasons (depending a bit on the country). If you talk to a Chinese person about the Great Firewall and the like then they usually don’t really see a problem with it. It’s hard to understate how big the cultural divide can be.

                                                                                    Or, a slightly amusing anecdote to illustrate this: I went on a Tinder date last year (in Indonesia), and at some point she asked me what my religion was. I said that I have no religion. She just started laughing like I said something incredibly funny. Then she then asked which God I believe in. “Well, ehh, I don’t really believe in any God”. I thought she was going to choke on laughter. Just the very idea that someone doesn’t believe in God was completely alien to her; she asked me all sorts of questions about how I could possibly not have a religion 🤷 Needless to say, I don’t talk much about my religious views here (also, because blasphemy is illegal and people have been fined and even jailed over very minor remarks). Of course, this doesn’t describe all Indonesians; I also know many who hate all this religious bullshit here (those tend to be the fun ones), but it’s not the standard attitude.

                                                                                    So talking about privacy on the internet and “software freedom as in free speech” is probably not too effective in places where you don’t have privacy and free speech in the first place, and where these values don’t really exist in the public consciousness, which is the majority of the world (in varying degrees).

                                                                                    1. 3

                                                                                      And a lot of Android phones name Chrome just “Browser”; you really need to know that there’s such a thing as “Firefox” (or indeed, any other browser) in the first place. Can’t install something you don’t know exists. This is essentially the same as the whole Windows/IE thing back in the day, eventually leading to the browserchoice.eu thing.

                                                                                      Yes. And the good thing is: the EU commission is at it again. Google has been fined in 2018. Actually, new Android devices should now ask the user about the browser.

                                                                                    2. 2

                                                                                      The self-destructing cookies plugin is the thing that keeps me on FireFox on Android. It’s the first sane cookie policy I’ve ever seen: When you leave a page, cookies are moved aside. Next time you visit it, all of the cookies are gone. If you lost some state that you care about (e.g. persistent login), there’s an undo button to bring them back and you can bring them back and add the site to a list that’s allowed to leave persistent cookies at the same time. I wish all browsers would make this the default policy out of the box.

                                                                            1. 36

                                                                              Hello, I am here to derail the Rust discussion before it gets started. The culprit behind sudo’s vast repertoire of vulnerabilities, and more broadly of bugs in general, is accountable almost entirely to one matter: its runaway complexity.

                                                                              We have another tool which does something very similar to sudo which we can compare with: doas. The portable version clocks in at about 500 lines of code, its man pages are a combined 157 lines long, and it has had two CVEs (only one of which Rust would have prevented), or approximately one every 30 months.

                                                                              sudo is about 120,000 lines of code (100x more), its had 140 CVEs, or about one every 2 months since the CVE database came into being 21 years ago. Its man pages are about 10,000 lines and include the following:

                                                                              $ man sudoers | grep -C1 despair
                                                                              The sudoers file grammar will be described below in Extended Backus-Naur
                                                                              Form (EBNF).  Don't despair if you are unfamiliar with EBNF; it is fairly
                                                                              simple, and the definitions below are annotated.
                                                                              

                                                                              If you want programs to be more secure, stable, and reliable, the key metric to address is complexity. Rewriting it in Rust is not the main concern.

                                                                              1. 45

                                                                                its had 140 CVEs

                                                                                Did you even look at that list? Most of those are not sudo vulnerabilities but issues in sudo configurations distros ship with. The actual list is more like 39, and a number of them are “disputed” and most are low-impact. I didn’t do a full detailed analysis of the issues, but the implication that it’s had “140 security problems” is simply false.

                                                                                sudo is about 120,000 lines of code

                                                                                More like 60k if you exclude the regress (tests) and lib directories, and 15k if you exclude the plugins (although the sudoers plugin is 40k lines, which most people use). Either way, it’s at least half of 120k.

                                                                                Its man pages are about 10,000 lines and include the following:

                                                                                12k, but this also includes various technical documentation (like the plugin API); the main documentation in sudoers(1) is 741 lines, and sudoers(5) is 3,255 lines. Well under half of 10,000.

                                                                                We have another tool which does something very similar to sudo which we can compare with: doas.

                                                                                Except that it only has 10% of the features, or less. This is good if you don’t use them, and bad if you do. But I already commented on this at HN so no need to repeat that here.

                                                                                1. 12

                                                                                  You’re right about these numbers being a back-of-the-napkin analysis. But even your more detailed analysis shows that the situation is much graver with sudo. I am going to include plugins, becuase if they ship, they’re a liability. And their docs, because they felt the need to write them. You can’t just shove the complexity you don’t use and/or like under the rug. Heartbleed brought the internet to its knees because of a vulnerability in a feature no one uses.

                                                                                  And yes, doas has 10% of the features by count - but it has 99% of the features by utility. If you need something in the 1%, what right do you have to shove it into my system? Go make your own tool! Your little feature which is incredibly useful to you is incredibly non-useful to everyone else, which means fewer eyes on it, and it’s a security liability to 99% of systems as such. Not every feature idea is meritous. Scope management is important.

                                                                                  1. 9

                                                                                    it has 99% of the features by utility

                                                                                    Citation needed.

                                                                                    what right do you have to shove it into my system?

                                                                                    Nobody is shoving anything into your system. The sudo maintainers have the right to decide to include features, and they’ve been exercising that right. You have the right to skip sudo and write your own - and you’ve been exercising that right too.

                                                                                    Go make your own tool!

                                                                                    You’re asking people to undergo the burden of forking or re-writing all of the common functionality of an existing tool just so they can add their one feature. This imposes a great cost on them. Meanwhile, including that code or feature into an existing tool imposes only a small (or much smaller) cost, if done correctly - the incremental cost of adding a new feature to an existing system.

                                                                                    The key phrase here is “if done correctly”. The consensus seems to be that sudo is suffering from poor engineering practices - few or no tests, including with the patch that (ostensibly) fixes this bug. If your software engineering practices are bad, then simpler programs will have fewer bugs only because there’s less code to have bugs in. This is not a virtue. Large, complex programs can be built to be (relatively) safe by employing tests, memory checkers, good design practices, good architecture (which also reduces accidental complexity) code reviews, and technologies that help mitigate errors (whether that be a memory-safe GC-less language like Rust or a memory-safe GC’ed language like Python). Most features can (and should) be partitioned off from the rest of the design, either through compile-time flags or runtime architecture, which prevents them from incurring security or performance penalties.

                                                                                    Software is meant to serve the needs of users. Users have varied use-cases. Distinct use-cases require more code to implement, and thereby incur complexity (although, depending on how good of an engineer one is, additional accidental complexity above the base essential complexity may be added). If you want to serve the majority of your users, you must incur some complexity. If you want to still serve them, then start by removing the accidental complexity. If you want to remove the essential complexity, then you are no longer serving your users.

                                                                                    The sudo project is probably designed to serve the needs of the vast majority of the Linux user-base, and it succeeds at that, for the most part. doas very intentionally does not serve the needs of the vast majority of the linux user-base. Don’t condemn a project for trying to serve more users than you are.

                                                                                    Not every feature idea is meritous.

                                                                                    Serving users is meritous - or do you disagree?

                                                                                    1. 6

                                                                                      Heartbleed brought the internet to its knees because of a vulnerability in a feature no one uses.

                                                                                      Yes, but the difference is that these are features people actually use, which wasn’t the case with Heartleed. Like I mentioned, I think doas is great – I’ve been using it for years and never really used (or liked) sudo because I felt it was far too complex for my needs, before doas I just used su. But I can’t deny that for a lot of other people (mainly organisations, which is the biggest use-case for sudo in the first place) these features are actually useful.

                                                                                      Go make your own tool! Your little feature which is incredibly useful to you is incredibly non-useful to everyone else

                                                                                      A lot of these things aren’t “little” features, and many interact with other features. What if I want doas + 3 flags from sudo + LDAP + auditing? There are many combinations possible, and writing a separate tool for every one of them isn’t really realistic, and all of this also required maintenance and reliable consistent long-term maintainers are kind of rare.

                                                                                      Scope management is important.

                                                                                      Yes, I’m usually pretty explicit about which use cases I want to solve and which I don’t want to solve. But “solving all the use cases” is also a valid scope. Is this a trade-off? Sure. But everything here is.

                                                                                      The real problem isn’t so much sudo; but rather that sudo is the de-facto default in almost all Linux distros (often installed by default, too). Ideally, the default should be the simplest tool which solves most of the common use cases (i.e. doas), and people with more complex use cases can install sudo if they need it. I don’t know why there aren’t more distros using doas by default (probably just inertia?)

                                                                                      1. 0

                                                                                        What if I want doas + 3 flags from sudo + LDAP + auditing?

                                                                                        Tough shit? I want a pony, and a tuba, and barbie doll…

                                                                                        But “solving all the use cases” is also a valid scope.

                                                                                        My entire thesis is that it’s not a valid scope. This fallacy leads to severe and present problems like the one we’re discussing today. You’re begging the question here.

                                                                                        1. 3

                                                                                          Tough shit? I want a pony, and a tuba, and barbie doll…

                                                                                          This is an extremely user-hostile attitude to have (and don’t try claiming that telling users with not-even-very-obscure use-cases to write their own tools isn’t user-hostile).

                                                                                          I’ve noticed that some programmers are engineers that try to build tools to solve problems for users, and some are artists that build programs that are beautiful or clever, or just because they can. You appear to be one of the latter, with your goal being crafting simple, beautiful systems. This is fine. However, this is not the mindset that allows you to build either successful systems (in a marketshare sense) or ones that are useful for many people other than yourself, for previously-discussed reasons. The sudo maintainers are trying to build software for people to use. Sure, there’s more than one way to do that (integration vs composition), but there are ways to do both poorly, and claiming the moral high ground for choosing simplicity (composition) is not only poor form but also kind of bad optics when you haven’t even begun to demonstrate that it’s a better design strategy.

                                                                                          My entire thesis is that it’s not a valid scope.

                                                                                          A thesis which you have not adequately defended. Your statements have amounted to “This bug is due to sudo’s complexity which is driven by the target scope/number of features that it has”, while both failing to provide any substantial evidence that this is the case (e.g. showing that sudo’s bugs are due to feature-driven essential complexity alone, and not use of a memory-unsafe language, poor software engineering practices (which could lead to either accidental complexity or directly to bugs themselves), or simple chance/statistics) and not actually providing any defense for the thesis as stated. Assume that @arp242 didn’t mean “all” the usecases, but instead “the vast majority” of them - say, enough that it works for 99.9% of users. Why is this “invalid”, exactly? It’s easy for me to imagine the argument being “this is a bad idea”, but I can’t imagine why you would think that it’s logically incoherent.

                                                                                          Finally, you have repeatedly conflated “complexity” and “features”. Your entire argument is, again, invalid if you can’t show that sudo’s complexity is purely (or even mostly) essential complexity, as opposed to accidental complexity coming from being careless etc.

                                                                                    2. 9

                                                                                      I dont’t think “users (distros) make a lot of configuration mistakes” is a good defence when arguing if complexity is the issue.

                                                                                      But I do agree about feature set. And I feel like arguing against complexity for safety is wrong (like ddevault was doing), because systems inevitably grow complex. We should still be able to build safe, complex systems. (Hence why I’m a proponent of language innovation and ditching C.)

                                                                                      1. 11

                                                                                        I dont’t think “users (distros) make a lot of configuration mistakes” is a good defence when arguing if complexity is the issue.

                                                                                        It’s silly stuff like (ALL : ALL) NOPASSWD: ALL. “Can run sudo without a password” seems like a common theme: some shell injection is found in the web UI and because the config is really naïve (which is definitely not the sudo default) it’s escalated to root.

                                                                                        Others aren’t directly related to sudo configuration as such; for example this one has a Perl script which is run with sudo that can be exploited to run arbitrary shell commands. This is also a common theme: some script is run with sudo, but the script has some vulnerability and is now escalated to root as it’s run with sudo.

                                                                                        I didn’t check all of the issues, but almost all that I checked are one of the above; I don’t really see any where the vulnerability is caused directly by the complexity of sudo or its configuration; it’s just that running anything as root is tricky: setuid returns 432 results, three times that of sudo, and I don’t think that anyone can argue that setuid is complex or that setuid implementations have been riddled with security bugs.

                                                                                        Other just mention sudo in passing by the way; this one is really about an unrelated remote exec vulnerability, and just mentions “If QCMAP_CLI can be run via sudo or setuid, this also allows elevating privileges to root”. And this one isn’t even about sudo at all, but about a “sudo mode” plugin for TYPO3, presumably to allow TYPO3 users some admin capabilities without giving away the admin password. And who knows why this one is even returned in a search for “sudo” as it’s not mentioned anywhere.

                                                                                        1. 3

                                                                                          it’s just that running anything as root is tricky: setuid returns 432 results, three times that of sudo

                                                                                          This is comparing apples to oranges. setuid affects many programs, so obviously it would have more results than a single program would. If you’re going to attack my numbers than at least run the same logic over your own.

                                                                                          1. 2

                                                                                            It is comparing apples to apples, because many of the CVEs are about other program’s improper sudo usage, similar to improper/insecure setuid usage.

                                                                                            1. 2

                                                                                              Well, whatever we’re comparing, it’s not making much sense.

                                                                                              1. If sudo is hard to use and that leads to security problems through its misusage, that’s sudo’s fault. Or do you think that the footguns in C are not C’s fault, either? I thought you liked Rust for that very reason. For this reason the original CVE count stands.
                                                                                              2. But fine, let’s move on on the presumption that the original CVE count is not appropriate to use here, and instead reference your list of 39 Ubuntu vulnerabilities. 39 > 2, Q.E.D. At this point we are comparing programs to programs.
                                                                                              3. You now want to compare this with 432 setuid results. You are comparing programs with APIs. Apples to oranges.

                                                                                              But, if you’re trying to bring this back and compare it with my 140 CVE number, it’s still pretty damning for sudo. setuid is an essential and basic feature of Unix, which cannot be made any smaller than it already is without sacrificing its essential nature. It’s required for thousands of programs to carry out their basic premise, including both sudo and doas! sudo, on the other hand, can be made much simpler and still address its most common use-cases, as demonstrated by doas’s evident utility. It also has a much smaller exposure: one non-standard tool written in the 80’s and shunted along the timeline of Unix history every since, compared to a standardized Unix feature introduced by DMR himself in the early 70’s. And setuid somehow has only 4x the number of footgun incidents? sudo could do a hell of a lot better, and it can do so by trimming the fat - a lot of it.

                                                                                              1. 3

                                                                                                If sudo is hard to use and that leads to security problems through its misusage, that’s sudo’s fault.

                                                                                                It’s not because it’s hard to use, it’s just that its usage can escalate other more (relatively) benign security problems, just like setuid can. This is my point, as a reply to stephank’s comment. This is inherent to running anything as root, with setuid, sudo, or doas, and why we have capabilities on Linux now. I bet that if doas would be the default instead of sudo we’d have a bunch of CVEs about improper doas usage now, because people do stupid things like allowing anyone to run anything without password and then write a shitty web UI in front of that. That particular problem is not doas’s (or sudo’s) fault, just as cutting myself with the kitchen knife isn’t the knife’s fault.

                                                                                                reference your list of 39 Ubuntu vulnerabilities. 39 > 2, Q.E.D.

                                                                                                Yes, sudo has had more issues in total; I never said it doesn’t. It’s just a lot lower than what you said, and quite a number are very low-impact, so I just disputed the implication that sudo is a security nightmare waiting to happen: it’s track record isn’t all that bad. As always, more features come with more (security) bugs, but use cases do need solving somehow. As I mentioned, it’s a trade-off.

                                                                                                sudo, on the other hand, can be made much simpler and still address its most common use-cases, as demonstrated by doas’s evident utility

                                                                                                We already agreed on this yesterday on HN, which I repeated here as well; all I’m adding is “but sudo is still useful, as it solves many more use cases” and “sudo isn’t that bad”.

                                                                                                Interesting thing to note: sudo was removed from OpenBSD by millert@openbsd.org; who is also the sudo maintainer. I think he’ll agree that “sudo is too complex for it to the default”, which we already agree on, but not that sudo is “too complex to exist”, which is where we don’t agree.

                                                                                                Could sudo be simpler or better architectured to contain its complexity? Maybe. I haven’t looked at the source or use cases in-depth, and I’m not really qualified to make this judgement.

                                                                                        2. 5

                                                                                          I think arguing against complexity is one of the core principles of UNIX philosophy, and it’s gotten us quite far on the operating system front.

                                                                                          If simplicity was used in sudo, this particular vulnerability would not have been possible to trigger it: why have sudoedit in the first place, which just implies the -e flag? This statement is a guarantee.

                                                                                          If it would’ve ditched C, there is no guarantee that this issue wouldn’t have happened.

                                                                                        3. 2

                                                                                          Did you even look at that list? Most of those are not sudo vulnerabilities but issues in sudo configurations distros ship with.

                                                                                          If even the distros can’t understand the configuration well enough to get it right, what hope do I have?

                                                                                        4. 16

                                                                                          OK maybe here’s a more specific discussion point:

                                                                                          There can be logic bugs in basically any language, of course. However, the following classes of bugs tend to be steps in major exploits:

                                                                                          • Bounds checking issues on arrays
                                                                                          • Messing around with C strings at an extremely low level

                                                                                          It is hard to deny that, in a universe where nobody ever messed up those two points, there are a lot less nasty exploits in the world in systems software in particular.

                                                                                          Many other toolchains have decided to make the above two issues almost non-existent through various techniques. A bunch of old C code doesn’t handle this. Is there not something that can be done here to get the same productivity and safety advantages found in almost every other toolchain for tools that form the foundation of operating computers? Including a new C standard or something?

                                                                                          I can have a bunch of spaghetti code in Python, but turning that spaghetti into “oh wow argv contents ran over some other variables and messed up the internal state machine” is a uniquely C problem, but if everyone else can find solutions, I feel like C could as well (including introducing new mechanisms to the language. We are not bound by what is printed in some 40-year-old books, and #ifdef is a thing).

                                                                                          EDIT: forgot to mention this, I do think that sudo is a bit special given that its default job is to take argv contents and run them. I kinda agree that sudo is a bit special in terms of exploitability. But hey, the logic bugs by themselves weren’t enough to trigger the bug. When you have a multi-step exploit, anything on the path getting stopped is sufficient, right?

                                                                                          1. 14

                                                                                            +1. Lost in the noise of “but not all CVEs…” is the simple fact that this CVE comes from an embarrassing C string fuckup that would be impossible, or at least caught by static analysis, or at very least caught at runtime, in most other languages. If “RWIIR” is flame bait, then how about “RWIIP” or at least “RWIIC++”?

                                                                                            1. 1

                                                                                              I be confused… what does the P in RWIIP mean?

                                                                                              1. 3

                                                                                                Pascal?

                                                                                                1. 1

                                                                                                  Python? Perl? Prolog? PL/I?

                                                                                                2. 2

                                                                                                  Probably Python, given the content of the comment by @rtpg. Python is also memory-safe, while it’s unclear to me whether Pascal is (a quick search reveals that at least FreePascal is not memory-safe).

                                                                                                  Were it not for the relative (accidental, non-feature-providing) complexity of Python to C, I would support RWIIP. Perhaps Lua would be a better choice - it has a tiny memory and disk footprint while also being memory-safe.

                                                                                                  1. 2

                                                                                                    Probably Python, given the content of the comment by @rtpg. Python is also memory-safe, while it’s unclear to me whether Pascal is (a quick search reveals that at least FreePascal is not memory-safe).

                                                                                                    That’s possibly it.

                                                                                                    Perhaps Lua would be a better choice - it has a tiny memory and disk footprint while also being memory-safe.

                                                                                                    Not to mention that Lua – even when used without LuaJIT – is simply blazingly fast compared to other scripting languages (Python, Perl, &c)!

                                                                                                    For instance, see this benchmark I did sometime ago: https://0x0.st/--3s.txt. I had implemented Ackermann’s function in various languages (the “./ack” file is the one in C) to get a rough idea on their execution speed, and lo and behold Lua turned out to be second only to the C implementation.

                                                                                            2. 15

                                                                                              I agree that rewriting things in Rust is not always the answer, and I also agree that simpler software makes for more secure software. However, I think it is disingenuous to compare the overall CVE count for the two programs. Would you agree that sudo is much more widely installed than doas (and therefore is a larger target for security researchers)? Additionally, most of the 140 CVEs linked were filed before October 2015, which is when doas was released. Finally, some of the linked CVEs aren’t even related to code vulnerabilities in sudo, such as the six Quest DR Series Disk Backup CVEs (example).

                                                                                              1. 4

                                                                                                I would agree that sudo has a bigger target painted on its back, but it’s also important to acknowledge that it has a much bigger back - 100× bigger. However, I think the comparison is fair. doas is the default in OpenBSD and very common in NetBSD and FreeBSD systems as well, which are at the heart of a lot of high-value operations. I think it’s over the threshold where we can consider it a high-value target for exploitation. We can also consider the kinds of vulnerabilities which have occured internally within each project, without comparing their quantity to one another, to characterize the sorts of vulnerabilities which are common to each project, and ascertain something interesting while still accounting for differences in prominence. Finally, there’s also a bias in the other direction: doas is a much simpler tool, shipped by a team famed for its security prowess. Might this not dissuade it as a target for security researchers just as much?

                                                                                                Bonus: if for some reason we believed that doas was likely to be vulnerable, we could conduct a thorough audit on its 500-some lines of code in an hour or two. What would the same process look like for sudo?

                                                                                                1. -1

                                                                                                  but it’s also important to acknowledge that it has a much bigger back - 100× bigger.

                                                                                                  Sorry but I miss the mass of users pretesting on the streets for tools that have 100x code compare to other tools providing similar functionality.

                                                                                                  1. 10

                                                                                                    What?

                                                                                              2. 10

                                                                                                So you’re saying that 50% of the CVEs in doas would have been prevented by writing it in Rust? Seems like a good reason to write it in Rust.

                                                                                                1. 11

                                                                                                  Another missing point is that Rust is only one of many memory safe languages. Sudo doesn’t need to be particularly performant or free of garbage collection pauses. It could be written in your favorite GCed language like Go, Java, Scheme, Haskell, etc. Literally any memory safe language would be better than C for something security-critical like sudo, whether we are trying to build a featureful complex version like sudo or a simpler one like doas.

                                                                                                  1. 2

                                                                                                    Indeed. And you know, Unix in some ways have been doing this for years anyway with Perl, python and shell scripts.

                                                                                                    1. 2

                                                                                                      I’m not a security expert, so I’m be happy to be corrected, but if I remember correctly, using secrets safely in a garbage collected language is not trivial. Once you’ve finished working with some secret, you don’t necessarily know how long it will remain in memory before it’s garbage collected, or whether it will be securely deleted or just ‘deallocated’ and left in RAM for the next program to read. There are ways around this, such as falling back to manual memory control for sensitive data, but as I say, it’s not trivial.

                                                                                                      1. 2

                                                                                                        That is true, but you could also do the secrets handling in a small library written in C or Rust and FFI with that, while the rest of your bog-standard logic not beholden to the issues that habitually plague every non-trivial C codebase.

                                                                                                        1. 2

                                                                                                          Agreed.

                                                                                                          Besides these capabilities, ideally a language would also have ways of expressing important security properties of code. For example, ways to specify that a certain piece of data is secret and ensure that it can’t escape and is properly overwritten when going out of scope instead of simply being dropped, and ways to specify a requirement for certain code to use constant time to prevent timing side channels. Some languages are starting to include things like these.

                                                                                                          Meanwhile when you try to write code with these invariants in, say, C, the compiler might optimize these desired constraints away (overwriting secrets is a dead store that can be eliminated, the password checker can abort early when the Nth character of the hash is wrong, etc) because there is no way to actually express those invariants in the language. So I understand that some of these security-critical things are written in inline assembly to prevent these problems.

                                                                                                          1. 1

                                                                                                            overwriting secrets is a dead store that can be eliminated

                                                                                                            I believe that explicit_bzero(3) largely solves this particular issue in C.

                                                                                                            1. 1

                                                                                                              Ah, yes, thanks!

                                                                                                              It looks like it was added to glibc in 2017. I’m not sure if I haven’t looked at this since then, if the resources I was reading were just not up to date, or if I just forgot about this function.

                                                                                                  2. 8

                                                                                                    I do think high complexity is the source of many problems in sudo and that doas is a great alternative to avoid many of those issues.

                                                                                                    I also think sudo will continue being used by many people regardless. If somebody is willing to write an implementation in Rust which might be just as complex but ensures some level of safety, I don’t see why that wouldn’t be an appropriate solution to reducing the attack surface. I certainly don’t see why we should avoid discussing Rust just because an alternative to sudo exists.

                                                                                                    1. 2

                                                                                                      Talking about Rust as an alternative is missing the forest for the memes. Rust is a viral language (in the sense of internet virality), and a brain worm that makes us all want to talk about it. But in actual fact, C is not the main reason why anything is broken - complexity is. We could get much more robust and reliable software if we focused on complexity, but instead everyone wants to talk about fucking Rust. Rust has its own share of problems, chief among them its astronomical complexity. Rust is not a moral imperative, and not even the best way of solving these problems, but it does have a viral meme status which means that anyone who sees through its bullshit has to proactively fend off the mob.

                                                                                                      1. 32

                                                                                                        But in actual fact, C is not the main reason why anything is broken - complexity is.

                                                                                                        Offering opinions as facts. The irony of going on to talk about seeing through bullshit.

                                                                                                        1. 21

                                                                                                          I don’t understand why you hate Rust so much but it seems as irrational as people’s love for it. Rust’s main value proposition is that it allows you to write more complex software that has fewer bugs, and your point is that this is irrelevant because the software should just be less complex. Well I have news for you, software is not going to lose any of its complexity. That’s because we want software to do stuff, the less stuff it does the less useful it becomes, or you have to replace one tool with two tools. The ecosystem hasn’t actually become less complex when you do that, you’re just dividing the code base into two chunks that don’t really do what you want. I don’t know why you hate Rust so much to warrant posting anywhere the discussion might come up, but I would suggest if you truly cannot stand it that you use some of your non-complex software to filter out related keywords in your web browser.

                                                                                                          1. 4

                                                                                                            Agree with what you’ve wrote, but just to pick at a theme that’s bothering me on this thread…

                                                                                                            I don’t understand why you hate Rust so much but it seems as irrational as people’s love for it.

                                                                                                            This is obviously very subjective, and everything below is anecdotal, but I don’t agree with this equivalence.

                                                                                                            In my own experience, everyone I’ve met who “loves” or is at least excited about rust seems to feel so for pretty rational reasons: they find the tech interesting (borrow checking, safety, ML-inspired type system), or they enjoy the community (excellent documentation, lots of development, lots of online community). Or maybe it’s their first foray into open source, and they find that gratifying for a number of reasons. I’ve learned from some of these people, and appreciate the passion for what they’re doing. Not to say they don’t exist, but I haven’t really seen anyone “irrationally” enjoy rust - what would that mean? I’ve seen floating around a certain spiteful narrative of the rust developer as some sort of zealous online persona that engages in magical thinking around the things rust can do for them, but I haven’t really seen this type of less-than-critical advocacy any more for rust than I have seen for other technologies.

                                                                                                            On the other hand I’ve definitely seen solid critiques of rust in terms of certain algorithms being tricky to express within the constraints of the borrow checker, and I’ve also seen solid pushback against some of the guarantees that didn’t hold up in specific cases, and to me that all obviously falls well within the bounds of “rational”. But I do see a fair amount of emotionally charged language leveled against not just rust (i.e. “bullshit” above) but the rust community as well (“the mob”), and I don’t understand what that’s aiming to accomplish.

                                                                                                            1. 3

                                                                                                              I agree with you, and I apologize if it came across that I think rust lovers are irrational - I for one am a huge rust proselytizer. I intended for the irrationality I mentioned to be the perceived irrationality DD attributes to the rust community

                                                                                                              1. 2

                                                                                                                Definitely no apology needed, and to be clear I think the rust bashing was coming from elsewhere, I just felt like calling it to light on a less charged comment.

                                                                                                              2. 1

                                                                                                                I think the criticism isn’t so much that people are irrational in their fondness of Rust, but rather that there are some people who are overly zealous in their proselytizing, as well as a certain disdain for everyone who is not yet using Rust.

                                                                                                                Here’s an example comment from the HN thread on this:

                                                                                                                Another question is who wants to maintain four decades old GNU C soup? It was written at a different time, with different best practices.

                                                                                                                In some point someone will rewrite all GNU/UNIX user land in modern Rust or similar and save the day. Until this happens these kind of incidents will happen yearly.

                                                                                                                There are a lot of things to say about this comment, and it’s entirely false IMO, but it’s not exactly a nice comment, and why Rust? Why not Go? Or Python? Or Zig? Or something else.

                                                                                                                Here’s another one:

                                                                                                                Rust is modernized C. You are looking for something that already exists. If C programmers would be looking for tools to help catch bugs like this and a better culture of testing and accountability they would be using Rust.

                                                                                                                The disdain is palatable in this one, and “Rust is modernized C” really misses the mark IMO; Rust has a vastly different approach. You can consider this a good or bad thing, but it’s really not the only approach towards memory-safe programming languages.


                                                                                                                Of course this is not representative for the entire community; there are plenty of Rust people that I like and have considerably more nuanced views – which are also expressed in that HN thread – but these comments certainly are frequent enough to give a somewhat unpleasant taste.

                                                                                                              3. 2

                                                                                                                Rust’s main value proposition is that it allows you to write more complex software that has fewer bugs

                                                                                                                I argue that it’s actually that it allows you to write fast software with fewer bugs. I’m not entirely convinced that Rust allows you to manage complexity better than, say, Common Lisp.

                                                                                                                That’s because we want software to do stuff, the less stuff it does the less useful it becomes

                                                                                                                Exactly. Software is written for people to use. (technically, only some software - other software (such as demoscenes) is written for the beauty of it, or the enjoyment of the programmer; but in this discussion we only care about the former)

                                                                                                                The ecosystem hasn’t actually become less complex when you do that

                                                                                                                Even worse - it becomes more complex. Now that you have two tools, you have two userbases, two websites, two source repositories, two APIs, two sets of file formats, two packages, and more. If the designs of the tools begin to differ substantially, you have significantly more ecosystem complexity.

                                                                                                                1. 2

                                                                                                                  You’re right about Rust value proposition, I should have added performance to that sentence. Or, I should have just said managed language, because as another commenter pointed out Rust is almost irrelevant to this whole conversation when it comes to preventing these type of CVEs

                                                                                                                2. 2

                                                                                                                  While I don’t approve of the deliberately inflammatory form of the comments, and don’t agree with the general statement that all complexity is eliminateable, I personally agree that, in this particular case, simplicity > Rust.

                                                                                                                  As a thought experiment, world 1 uses sudo-rs as a default implementation of sudo, while world 2 uses 500 lines of C which is doas. I do think that world 2 would be generally more secure. Sure, it’ll have more segfaults, but fewer logical bugs.

                                                                                                                  I also think that the vast majority of world 2 populace wouldn’t notice the absence of advanced sudo features. To be clear, the small fraction that needs those features would have to install sudo, and they’ll use the less tested implementation, so they will be less secure. But that would be more than offset by improved security of all the rest.

                                                                                                                  Adding a feature to a program always has a cost for those who don’t use this feature. If the feature is obscure, it might be overall more beneficial to have a simple version which is used by the 90% of the people, and a complex for the rest 10%. The 10% would be significantly worse off in comparison to the unified program. The 90% would be slightly better off. But 90% >> 10%.

                                                                                                                  1. 1

                                                                                                                    The other issue is that it is a huge violation of principle of least privilege. Those other features are fine, but do they really need to be running as root?

                                                                                                              4. 7

                                                                                                                Just to add to that: In addition to having already far too much complexity, it seems the sudo developers have a tendency to add even more features: https://computingforgeeks.com/better-secure-new-sudo-release/

                                                                                                                Plugins, integrated log server, TLS support… none of that are things I’d want in a tool that should be simple and is installed as suid root.

                                                                                                                (Though I don’t think complexity vs. memory safety are necessarily opposed solutions. You could easily imagine a sudo-alike too that is written in rust and does not come with unnecessary complexity.)

                                                                                                                1. 4

                                                                                                                  What’s wrong with EBNF and how is it related to security? I guess you think EBNF is something the user shouldn’t need to concern themselves with?

                                                                                                                  1. 6

                                                                                                                    There’s nothing wrong with EBNF, but there is something wrong with relying on it to explain an end-user-facing domain-specific configuration file format for a single application. It speaks to the greater underlying complexity, which is the point I’m making here. Also, if you ever have to warn your users not to despair when reading your docs, you should probably course correct instead.

                                                                                                                    1. 2

                                                                                                                      Rewrite: The point that you made in your original comment is that sudo has too many features (disguising it as a point about complexity). The manpage snippet that you’re referring to has nothing to do with features - it’s a mix between (1) the manpage being written poorly and (2) a bad choice of configuration file format resulting in accidental complexity increase (with no additional features added).

                                                                                                                    2. 1

                                                                                                                      EBNF as a concept aside; the sudoers manpage is terrible.

                                                                                                                    3. 3

                                                                                                                      Hello, I am here to derail the Rust discussion before it gets started.

                                                                                                                      I am not sure what you are trying to say, let me guess with runaway complexity.

                                                                                                                      • UNIX is inherently insecure and it cannot be made secure by any means
                                                                                                                      • sudo is inherently insecure and it cannot be made secure by any means

                                                                                                                      Something else maybe?

                                                                                                                      1. 4

                                                                                                                        Technically I agree with both, though my arguments for the former are most decidedly off-topic.

                                                                                                                        1. 5

                                                                                                                          Taking Drew’s statement at face value: There’s about to be another protracted, pointless argument about rewriting things in rust, and he’d prefer to talk about something more practically useful?

                                                                                                                          1. 7

                                                                                                                            I don’t understand why you would care about preventing a protracted, pointless argument on the internet. Seems to me like trying to nail jello to a tree.

                                                                                                                        2. 3

                                                                                                                          This is a great opportunity to promote doas. I use it everywhere these days, and though I don’t consider myself any sort of Unix philosophy purist, it’s a good example of “do one thing well”. I’ll call out Ted Unangst for making great software. Another example is signify. Compared to other signing solutions, there is much less complexity, much less attack surface, and a far shallower learning curve.

                                                                                                                          I’m also a fan of tinyssh. It has almost no knobs to twiddle, making it hard to misconfigure. This is what I want in security-critical software.

                                                                                                                          Relevant link: Features Are Faults.

                                                                                                                          All of the above is orthogonal to choice of implementation language. You might have gotten a better response in the thread by praising doas and leaving iron oxide out of the discussion. ‘Tis better to draw flies with honey than with vinegar. Instead, you stirred up the hornets’ nest by preemptively attacking Rust.

                                                                                                                          PS. I’m a fan of your work, especially Sourcehut. I’m not starting from a place of hostility.

                                                                                                                          1. 3

                                                                                                                            If you want programs to be more secure, stable, and reliable, the key metric to address is complexity. Rewriting it in Rust is not the main concern.

                                                                                                                            Why can’t we have the best of both worlds? Essentially a program copying the simplicity of doas, but written in Rust.

                                                                                                                            1. 2

                                                                                                                              Note that both sudo and doas originated in OpenBSD. :)

                                                                                                                              1. 9

                                                                                                                                Got a source for the former? I’m pretty sure sudo well pre-dates OpenBSD.

                                                                                                                                Sudo was first conceived and implemented by Bob Coggeshall and Cliff Spencer around 1980 at the Department of Computer Science at SUNY/Buffalo. It ran on a VAX-11/750 running 4.1BSD. An updated version, credited to Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso and Don Gworek, was posted to the net.sources Usenet newsgroup in December of 1985.

                                                                                                                                The current maintainer is also an OpenBSD contributor, but he started maintaining sudo in the early 90s, before OpenBSD forked from NetBSD. I don’t know when he started contributing to OpenBSD.

                                                                                                                                So I don’t think it’s fair to say that sudo originated in OpenBSD :)

                                                                                                                                1. 1

                                                                                                                                  Ah, looks like I was incorrect. I misinterpreted OpenBSD’s innovations page. Thanks for the clarification!

                                                                                                                            1. 8

                                                                                                                              Tomorrow seems to be a very bad day for all those poor souls, who didn’t have time/resources to switch to py3 yet. Fortunately enough it can be easily fixed with pip<21 but it will definitely add additional grey hairs to some heads.

                                                                                                                              1. 7

                                                                                                                                As one of those poor souls, thanks. We have eight years of legacy code that Just Works and so seldom gets touched, and a major 3rd party framework dependency that hasn’t updated to Python 3 either. We just got permission and funding to form a new engineering sub-group to try to deal with this sort of thing, and upper management is already implicitly co-opting it to chase new shinies.

                                                                                                                                1. 9

                                                                                                                                  Python 3.0 was released in 2008. I personally find it hard to feel sympathy for anyone who couldn’t find time in the last twelve years to update their code, especially if it’s code they are still using today. Even more so for anyone who intentionally started a Python 2 project after the 3.0 ecosystem had matured.

                                                                                                                                  1. 9

                                                                                                                                    Python 2.7 was released in 2010. Python 3.3 in 2012. Python 2.6 last release was in 2013. Only from this date people could easily release stuff compatible with both Python 2 and Python 3. You may also want to take into consideration the end of support date of some of the distributions shipping Python 2.6 and not Python 2.7 (like Debian Squeeze, 2016).

                                                                                                                                    I am not saying that 8 years is too fast, but Python 3.0 release date is mostly irrelevant as the ecosystem didn’t use it.

                                                                                                                                    1. 7

                                                                                                                                      Python 3.0 was not something you wanted to use; it took several releases before Python 3 was really ready for people to write programs on. Then it took longer for good versions of Python 3 to propagate into distributions (especially long term distributions), and then it took longer for people to port packages and libraries to Python 3, and so on and so forth. It has definitely not been twelve years since the ecosystem matured.

                                                                                                                                      Some people do enough with Python that it’s sensible for them to build and maintain their own Python infrastructure, so always had the latest Python 3. Many people do not and so used supplied Python versions, and may well have stable Python code that just works and they haven’t touched in years (perhaps because they are script-level infrastructure that just sits there working, instead of production frontend things that are under constant evolution because business needs keep changing).

                                                                                                                                      1. 4

                                                                                                                                        Some of our toolchain broke in the last few weeks. We ported to python3 ages ago, but chunks of infrastructure still support both, and some even still default to 2. The virtualenv binary in Ubuntu 18.02 does that; and that’s a still-supported Ubuntu version, and the default runner for GitHub CI.

                                                                                                                                        I think python2-related pain will continue for years to come even for people who have done the due diligence on their own code.

                                                                                                                                        1. 4

                                                                                                                                          Small tip regarding virtualenv: Since python 3.3 virtualenv comes bundled as the venv module in python, so you can just use python -m venv instead of virtualenv, then you are certain it matches the python version you are using.

                                                                                                                                          1. 1

                                                                                                                                            virtualenv has some nice features which do not exist for venv. One of the examples is activate_this.py script, which can be used for configuration of remote environment, similar to what pytest_cloud does.

                                                                                                                                            1. 1

                                                                                                                                              virtualenv has some nice features which do not exist for venv

                                                                                                                                              Huh, thanks for pointing that out. I haven’t been writing so much Python in the last few years, and I totally thought venv and virtualenv were the same thing.

                                                                                                                                        2. 4

                                                                                                                                          Consider, at a minimum, the existence of PyPy; PyPy’s own position is that PyPy will support Python 2.7 forever because PyPy is written in RPython, a strict subset of Python 2.7.

                                                                                                                                          Sympathy is not required; what you’re missing out on is an understanding that Python is not wholly under control of the Python Software Foundation. By repeatedly neglecting PyPy, the PSF has effectively forced them to create their own parallel Python 2 infrastructure; when PyPI finally makes changes which prevent Python 2 code from deploying, then we may see PyPy grow even more tooling and possibly even services to compensate.

                                                                                                                                          It is easy for me to recognize in your words an inkling of contempt for Python 2 users.

                                                                                                                                          1. 21

                                                                                                                                            Every time you hop into one of these threads, you frame it in a way which implies you think various entities are obligated to maintain a Python 2 interpreter, infrastructure for supporting Python 2 interpreters, and versions of third-party packages which stay compatible with Python 2, for all of eternity.

                                                                                                                                            Judging from that last thread, you seem to think I am one of the people who has that obligation. Could you please, clearly, state to me the nature of this obligation – is its basis legal? moral? something else? – along with its origin and the means by which you assume the right to impose it on me.

                                                                                                                                            I ask because I cannot begin to fathom where such an obligation would come from, nor do I understand why you insist on labeling it “contempt” when other people choose not to maintain software for you, in the exact form you personally prefer, for free, forever, anymore.

                                                                                                                                            1. 2

                                                                                                                                              Your sympathy, including any effort or obligation that you might imagine, is not required. I don’t know how to put it any more clearly to you: You have ended up on the winning side of a political contest within the PSF, and you are antagonizing members of the community who lost for no other reason than that you want the political divide to deepen.

                                                                                                                                              Maybe, to get some perspective, try replacing “Python 2” with “Perl 5” and “Python 3” with “Raku”; that particular community resolved their political divide recently and stopped trying to replace each other. Another option for perspective: You talk about “these threads”; what are these threads for, exactly? I didn’t leave a top-level comment on this comment thread; I didn’t summon you for the explicit purpose of flamewar.

                                                                                                                                              Finally, why not reread the linked thread? I not only was clearly the loser in that discussion, but I also explained that I personally am not permanently tied to Python 2, and that I’m trying to leave the ecosystem altogether in order to avoid these political problems. Your proposed idea of obligation towards me is completely imagined and meant to make you seem like a victim.

                                                                                                                                              Here are some quotes which I think display contempt towards Python 2 and its users, from the previous thread (including your original post) and also the thread before that one:

                                                                                                                                              If PyPy wants to internally maintain the interpreter they use to bootstrap, I don’t care one way or another. But if PyPy wants that to also turn into broad advertisement of a supported Python 2 interpreter for general use, I hope they’d consider the effect it will have on other people.

                                                                                                                                              Want to keep python 2 alive? Step up and do it.

                                                                                                                                              What do you propose they do then? Extend Python 2 support forever and let Python 2 slow down Python 3 development for all time?

                                                                                                                                              That’s them choosing and forever staying on a specific dependency. … Is it really that difficult for Python programmers to rewrite one Python program in the newer version of Python? … Seems more fair for the project that wants the dependency to be the one reworking it.

                                                                                                                                              The PyPy project, for example, is currently dependent on a Python 2 interpreter to bootstrap and so will be maintaining their own either for as long as PyPy exists, or for as long as it takes to migrate to bootstrapping on Python 3 (which they seem to think is either not feasible, or not something they want to do).

                                                                                                                                              He’s having a tantrum. … If you’re not on 3, it’s either a big ball of mud that should’ve been incrementally rewritten/rearchitected (thus exposing bad design) or you expected an ecosystem to stay in stasis forever.

                                                                                                                                              I’m not going to even bother with your “mother loved you best” vis a vis PyPy.

                                                                                                                                              You’re so wrapped up in inventing enemies that heap contempt on you, but it’s just fellow engineers raising their eyebrows at someone being overly dramatic. Lol contempt. 😂😂😂

                                                                                                                                              If I didn’t already have a long history of knowing other PyPy people, for example, I’d be coming away with a pretty negative view of the project from my interactions with you.

                                                                                                                                              What emotional word would you use to describe the timbre of these attitudes? None of this has to do with maintainership; I don’t think that you maintain any packages which I directly require. I’m not asking for any programming effort from you. Indeed, if you’re not a CPython core developer either, then you don’t have the ability to work on this; you are also a bystander. I don’t want sympathy; I want empathy.

                                                                                                                                              1. 6

                                                                                                                                                You have ended up on the winning side of a political contest within the PSF, and you are antagonizing members of the community who lost for no other reason than that you want the political divide to deepen.

                                                                                                                                                And this is where the problem lies. Your behavior in the previous thread, and here, makes clear that your approach is to insult, attack, or otherwise insinuate evil motives to anyone who disagrees with you.

                                                                                                                                                Here are some quotes which I think display contempt towards Python 2 and its users

                                                                                                                                                First of all, it’s not exactly courteous to mix and match quotes from multiple users without sourcing them to who said each one. If anyone wants to click through to the actual thread, they’ll find a rather different picture of, say, my engagement with you. But let’s be clear about this “contempt”.

                                                                                                                                                In the original post, I said:

                                                                                                                                                The PyPy project, for example, is currently dependent on a Python 2 interpreter to bootstrap and so will be maintaining their own either for as long as PyPy exists, or for as long as it takes to migrate to bootstrapping on Python 3 (which they seem to think is either not feasible, or not something they want to do).

                                                                                                                                                You quoted this and replied:

                                                                                                                                                This quote is emblematic of the contempt that you display towards Python users.

                                                                                                                                                I remain confused as to what was contemptuous about that. You yourself have confirmed that PyPy is in fact dependent on a Python 2 interpreter, and your own comments seem to indicate there is no plan to migrate away from that dependency. It’s simply a statement of fact. And the context of the quote you pulled was a section exploring the difference between “Python 2” the interpreter, and “Python 2” the ecosystem of third-party packages. Here’s the full context:

                                                                                                                                                Unfortunately for that argument, Python 2 was much more than just the interpreter. It was also a large ecosystem of packages people used with the interpreter, and a community of people who maintained and contributed to those packages. I don’t doubt the PyPy team are willing to maintain a Python 2 interpreter, and that people who don’t want to port to Python 3 could switch to the PyPy project’s interpreter in order to have a supported Python 2 interpreter. But a lot of those people would continue to use other packages, too, and as far as I’m aware the PyPy team hasn’t also volunteered to maintain Python 2 versions of all those packages.

                                                                                                                                                So there’s a sense in which I want to push back against that messaging from PyPy folks and other groups who say they’ll maintain “Python 2” for years to come, but really just mean they’ll maintain an interpreter. If they keep loudly announcing “don’t listen to the Python core team, Python 2 is still supported”, they’ll be creating additional burdens for a lot of other people: end users are going to go file bug reports and other support requests to third-party projects that no longer support Python 2, because they heard “Python 2 is still supported”, and thus will feel entitled to have their favorite packages still work.

                                                                                                                                                Even if all those requests get immediately closed with “this project doesn’t support Python 2 anymore”, it’s still going to take up the time of maintainers, and it’s going to make the people who file the requests angry because now they’ll feel someone must be lying to them — either Python 2 is dead or it isn’t! — and they’ll probably take that anger out on whatever target happens to be handy. Which is not going to be good.

                                                                                                                                                This is why I made comments asking you to consider the effect of your preferred stance on other people (i.e., on package maintainers). This is why I repeated my point in the comments of the previous thread, that an interpreter is a necessary but not sufficient condition for saying “Python 2 is still supported”. I don’t think these are controversial statements, but apparently you do. I don’t understand why.

                                                                                                                                                I also still don’t understand comments of yours like this one:

                                                                                                                                                Frankly, I think that you show your hand when you say “really important packages like NumPy/SciPy.” That’s the direction that you want Python to go in.

                                                                                                                                                Again, this is just a statement of fact. There are a lot of people using Python for a lot of use cases, and many of those use cases are dependent on certain domain-specific libraries. As I said in full:

                                                                                                                                                So regardless of whether I use them or not, NumPy and SciPy are important packages. Just as Jupyter (née IPython) notebooks are important, even though I don’t personally use them. Just as the ML/AI packages are important even though I don’t use them. Just as Flask and SQLAlchemy are important packages, even though I don’t use them. Python’s continued success as a language comes from the large community of people using it for different things. The fact that there are large numbers of people using Python for not-my-use-case with not-the-libraries-I-use is a really good thing!

                                                                                                                                                Your words certainly imply you think it’s a bad thing that there are, for example, people using NumPy and SciPy, or at least that you think that’s a bad direction for Python to go in. I do not understand why, and you’ve offered no explanation other than to hand-wave it as “contempt” and “denigration”.

                                                                                                                                                But really the thing I do not understand is this:

                                                                                                                                                You have ended up on the winning side of a political contest within the PSF

                                                                                                                                                You seem to think that “the PSF” and/or some other group of people or entities in the Python world are your enemy, because they chose to move to Python 3 and to stop dedicating their own time and resources to maintaining compatibility with and support for Python 2. The only way that this would make any sense is if those entities had some sort of obligation, to you or to others, to continue maintaining compatibility with and support for Python 2. Hence I have asked you for an explanation of the nature and origin of that obligation so that I can try to understand the real root of why you seem to be so angry about this.

                                                                                                                                                Admittedly I don’t have high hopes for getting such an explanation, given what happened last time around, but maybe this time?

                                                                                                                                                1. 4

                                                                                                                                                  Your behavior in the previous thread, and here, makes clear that your approach is to insult, attack, or otherwise insinuate evil motives to anyone who disagrees with you.

                                                                                                                                                  As Corbin has said themselves multiple times, they are not a nice person. So unfortunately you can’t really expect anything better than this.

                                                                                                                                        3. 2

                                                                                                                                          Why will tomorrow be a bad day? pip will continue to work. They’re just stopping releasing updates.

                                                                                                                                          1. 1

                                                                                                                                            From my OpenStack experience – many automated gates could go south, because they could do something like: pip install pip --upgrade hence dropping support for py2. I know, that whomever is involved in this conundrum, should know better and should introduce some checks. But I also know, that we’re all humans, hence prone to make errors.

                                                                                                                                            1. 2

                                                                                                                                              pip install pip --upgrade should still work, unless the pip team screwed something up.

                                                                                                                                              When you upload something to PyPI, you can specify a minimal support Python version. So Python 2.7 will get the latest version that still supports Python 2.

                                                                                                                                              And indeed, if you go to https://pypi.org/project/pip/ you will see “Requires: Python >= 3.6”, so I expect things will Just Work for most Python 2 users.

                                                                                                                                        1. 11

                                                                                                                                          The bit about copyright violations is particularly bad, too.

                                                                                                                                            1. 17

                                                                                                                                              That seems less an “other side” and more “so what?”, especially in his response to jwz’s response, but it’s indeed interesting to have more context.

                                                                                                                                              1. 6

                                                                                                                                                Interesting, but I’m inclined to be on jwz’s side

                                                                                                                                                1. 6

                                                                                                                                                  “Your security arguments turned out to be incorrect. So, stop?” Did they though? Did they REALLY?

                                                                                                                                              1. 3

                                                                                                                                                Can anyone suggest a xscreensaver alternative that doesn’t pull a bunch of dependencies?

                                                                                                                                                resolving dependencies...
                                                                                                                                                looking for conflicting packages...
                                                                                                                                                
                                                                                                                                                Packages (21) gdk-pixbuf-xlib-2.40.2-1  glu-9.0.1-2  libglade-2.6.4-7  perl-clone-0.45-2  perl-encode-locale-1.05-7  perl-file-listing-6.14-1  perl-html-parser-3.75-1
                                                                                                                                                              perl-html-tagset-3.20-10  perl-http-cookies-6.10-1  perl-http-daemon-6.06-2  perl-http-date-6.05-3  perl-http-message-6.27-1  perl-http-negotiate-6.01-8
                                                                                                                                                              perl-io-html-1.004-1  perl-libwww-6.52-1  perl-lwp-mediatypes-6.02-8  perl-net-http-6.20-1  perl-try-tiny-0.30-5  perl-www-robotrules-6.02-8
                                                                                                                                                              xorg-appres-1.0.5-2  xscreensaver-5.44-3
                                                                                                                                                

                                                                                                                                                I mean, is this reasonable for everyone?

                                                                                                                                                1. 10

                                                                                                                                                  I use i3lock. Its direct dependencies look reasonable, although I don’t know what they recursively expand to.

                                                                                                                                                  With that said, I don’t know whether it is “secure” or not because my threat model doesn’t really care if it is or not. I only use it to prevent cats and children from messing around on the keyboard. And for that, it works well.

                                                                                                                                                  1. 4

                                                                                                                                                    Try slock, which has no dependencies except X11 itself.

                                                                                                                                                    1. 2

                                                                                                                                                      Build from source and disable the savers/hacks that require the dependencies you aren’t happy about.

                                                                                                                                                      1. 1

                                                                                                                                                        I don’t want any screensaver, just want my screen to lock reliably. I guess I’ll try that.

                                                                                                                                                          1. 2

                                                                                                                                                            It’s a great compromise when using X11, but the whole concept of screen savers on X11 is just so fragile. Actually suspending the session even if the screensaver should crash would be much cleaner (which is how every other platform, and also wayland handle it).

                                                                                                                                                            What I’m even more surprised about is that you said this compromise is possible with 25yo tech - why did no distro actually do any of this before?

                                                                                                                                                          2. 0

                                                                                                                                                            What about physlock?

                                                                                                                                                            1. 5

                                                                                                                                                              No idea about physlock or any other alternative, I am asking because this sentence kind of make me think:

                                                                                                                                                              If you are not running XScreenSaver on Linux, then it is safe to assume that your screen does not lock.

                                                                                                                                                              Though this person’s attitude kind of bothers me, if you run ./configure on xscreensaver you read stuff like:

                                                                                                                                                              configure: error: Your system doesn't have "bc", which has been a standard
                                                                                                                                                                                part of Unix since the 1970s.  Come back when your vendor
                                                                                                                                                                                has grown a clue.
                                                                                                                                                              

                                                                                                                                                              hm. Ok? I guess I don’t have to like it, I just don’t see the need for that.

                                                                                                                                                              1. 19

                                                                                                                                                                jwz ragequit the software industry some 20 years ago and has been trolling the industry ever since. Just some context. He’s pretty funny but can be a bit of an ass at times 🤷

                                                                                                                                                                1. 18

                                                                                                                                                                  He’s also pretty reliably 100% correct about software. This may or may not correlate with the ragequitting.

                                                                                                                                                                  1. 3

                                                                                                                                                                    While ragequitting may not correlate with being correct about software, being correct about software is absolutely no excuse for being an ass.

                                                                                                                                                                    1. 7

                                                                                                                                                                      It’s not his job to put on a customer support demeanor while he says what he wants.

                                                                                                                                                                      He gets to do as he likes. There are worse crimes than being an ass, such as being an ass to undeserving people perhaps. The configure script above is being an ass at the right people, even if it does editorialize (again, not a problem or crime, and really software could use attitudes!)

                                                                                                                                                                      1. 4

                                                                                                                                                                        Lots of people in our industry seem to think that being a good developer you can behave like a 5 years old. That’s sad.

                                                                                                                                                                        1. 4

                                                                                                                                                                          Especially in creative fields, you may choose to portray yourself any way you choose. You don’t owe anybody a pleasant attitude, unless of course you want to be pleasant to someone or everybody.

                                                                                                                                                                          For some people, being pleasant takes a lot of work. I’m not paying those people, let alone to be pleasant, so why do I demand a specific attitude?

                                                                                                                                                                          1. 2

                                                                                                                                                                            Being pleasant may take work, but being an asshole requires some effort too. Unless you are one to begin with and then it comes naturally of course. :D

                                                                                                                                                                        2. 3

                                                                                                                                                                          How is the bc comment being an ass at the right people? Plenty of distros don’t ship with bc by default, you can just install it. What is a “standard part of unix” anyway?

                                                                                                                                                                          1. 9

                                                                                                                                                                            bc is part of POSIX. Those distros are being POSIX-incompatible.

                                                                                                                                                                            1. 8

                                                                                                                                                                              As a developer for Unix(-like) systems, you should be able to rely on POSIX tools (sh, awk, bc etc.) being installed.

                                                                                                                                                                          2. 2

                                                                                                                                                                            It sounds like you view software as an occupation. It is not. It’s a product.

                                                                                                                                                                      2. 2

                                                                                                                                                                        Physlock runs as root and locks the screen at the console level. AFAIK the problems affecting x-server screenlockers aren’t relevant to physlock.

                                                                                                                                                              1. 1

                                                                                                                                                                I dropped all but the 5 latest posts from my feed. I didn’t do it for bandwidth reasons, but to minimise the impact of flooding Planet aggregators if (when) I made a change that bumped old articles into the upper end of the “new articles” feed by mistake. Saving bandwidth is a happy accident.

                                                                                                                                                                1. 2

                                                                                                                                                                  One thing I’m sure about after reading that is this author is the person who cares most about this issue in the world.

                                                                                                                                                                  1. 4

                                                                                                                                                                    I’m not so sure: back when I used to read /g/, an image board, it was one of the main arguments people raised against “Linux” (serious or not). But it makes sense, that if you want to use and pick images all the time, that it will annoy you more. The best workaround I know of is to use the regular file manager to find a file, and then drag-n-drop it into the picker.

                                                                                                                                                                    1. 1

                                                                                                                                                                      more likely the author is able to identify what exactly feels off, rather than just saying “this desktop is crap” and going to something else.

                                                                                                                                                                    1. 2

                                                                                                                                                                      The terminology terminal from Enlightenment may not be the best in many ways, but it’s super useful for irc and such, because it can overlay images on itself, so not everything has to be opened in the browser. Wish that was a thing in more terminal emulators.

                                                                                                                                                                      And tabs, which terminology sucks at. Thus xfce4-terminal is nice for all else.

                                                                                                                                                                      Another thing for the xterm wishlist…

                                                                                                                                                                      1. 3

                                                                                                                                                                        Kitty (which I’ve only learned about recently) has its own inline-image system which the author invented himself; on the one hand it’s really easy as an app programmer to emit an image for inlining (encode to png, base64 encode, wrap in an escape sequence). On the other absolutely nothing else supports it.

                                                                                                                                                                        I don’t know what Enlightenment do but SGI devised “sixel” which a few emulators support.

                                                                                                                                                                        1. 2

                                                                                                                                                                          iTerm2 has a nearly identical protocol for displaying images inline. ❤️

                                                                                                                                                                          1. 1

                                                                                                                                                                            Enlightenment’s the wm, terminology’s the terminal.

                                                                                                                                                                            Checked kitty’s frontpage and the feature I’m talking about isn’t there. Simply terminology sees a url ending in jpg or some other supported format, you click it, the image is overlaid. Click to close and type the lolz to irc.

                                                                                                                                                                            Maybe that image-inline and sixel stuff can be useful too.

                                                                                                                                                                        1. 10

                                                                                                                                                                          I’d happily read more synth stuff on Lobsters.

                                                                                                                                                                          1. 4

                                                                                                                                                                            Another reason why lobste.rs should get a dsp or signal-processing tag.