1. 11

    These icons look terrible to me (not an icon designer…) It seems what they did was try a few designs and ask around in some kind of association game until no one was able to associate the icon with anything and then define them to be protein and fat. The approach at least seems a good one, ask many people around the world for feedback to avoid the obvious mistakes, but maybe they took it a little too far.

    “We have accomplished our mission: keep the information simple, easy to understand, language-free and top line.”

    The “Calories” icon sure has a lot of text for being “language-free” /s

    1. 3

      I think if you judge it on “do I know at a glance what this icon means”, I’d agree.

      However, I doubt that’s their primary goal: I think McDonalds is trying to find universally acceptable (i.e., not evoking negative images) iconography so they can have one homogeneous icon set used around the world with local translations to satisfy local labeling requirements.

      In other words: it’s cheaper to do the design and layout once for all their cups, containers, etc. and a spot on the menu that says (three circles) = “salt” (in whatever language).

      1. 2

        From the five final icons, I would have only guessed the calories one correctly. The “universal icons” clearly don’t seem to be working for me.

      1. 54

        Ugh. I’m pretty happy sticking with Python 2, but this post is so bad I’m tempted to switch to Python 3. Even as a joke the Turing complete section is just stupid.

        1. 23

          I couldn’t tell whether the Turing Complete section was a joke or just profoundly confused, to be honest. Conflating the language with the bytecode, claiming that one VM can’t run the bytecode generated by another language (or maybe complaining that the bytecode changed? or that there’s no py2 compiler targeting py3 bytecode?), and trying to tie that to a fundamental property that even “languages” like SQL and Excel have ….

          It was all very muddle-headed.

          Don’t get me wrong, I know he’ll claim that it was a joke, later. That’s not in question. I’m just not sure if it actually is a joke.

          1. 20

            I don’t think this is meant as a joke. The “post” is a chapter in his book Learn Python the Hard Way.

            Difficult To Use Strings

            Wait.. what? Strings are a mess in Python 2. They have been cleaned up in Py3.

            Python 3 Is Not Turing Complete

            No comment.

            Purposefully Crippled 2to3 Translator

            It took me about one day of work to port a 70k lines django application to Py3 with the 2to3 tool. That’s was one year ago. Since then I’ve only found two bugs caused by the conversion. Doesn’t seem that bad to me.

            Too Many Formatting Options

            Yes, I can agree with that. This is the only valid criticism in that chapter.

            1. 15

              I agree, but just as a data point, it’s taken about 3 people-weeks for us to port a large (~200kloc) Django application (over the course of several months).

              The points that made this take a while:

              • We tried to maximize the amount of changes that were Py2 + Py3 compatible. This meant pulling things in over time, heavy usage of six, and catching a lot of bugs early on. Highly recommended for easy reviewing by third parties. For example: a couple changesets that were just “use six for more imports”.

              • we deal with many different encodings, and a lot of old text-to-bytes conversion code was pretty brittle. Py3 forced us to fix a lot of this

              • imports! 2to3 generated way too many false positives for our taste (hard to review the real changes), so it took a while to find the right solution (for us: a monkey-patched six that would minimize changes)

              • changes of standard API from lists to iterators generated a decent amount of busy work. Changes for the better, though.

              • Handling binary files. Here, too, we were often doing the wrong thing in Py2, but it would “just work” before.

              • Lots of dependencies that we needed to upgrade to get the Python 3 support.

              • Pretty minor things around bytes’s defautl __str__ method. For example, checking the output of a process call, we would do if output == "'0'", and that would fail because `“b'0'” != “‘0’” but that turned out to cause more issues down the road.

              • issues around pickling + celery. Our solution mostly centered around lowering usage of pickle even more (dangerous)

              • deployment issues. Juggling Python 2 tooling and Python 3 tooling in the CI pipeline would sometimes mess things up.

              1. 4

                I can only recommend https://pypi.python.org/pypi/modernize

                Instead of translating x.iteritems() to x.items(), it translates it to six.iteritems(x), and adds the six import. Fixes 80% of the boring stuff and you only need to focus on unicode/bytes, etc.

                1. 2

                  The idea of Python 3 was to make iteration cleaner the easier to read and understand. Now we have to insert calls to six in every loop and for every string. The result is hideous code that’s harder to read, not easier.

                  1. 2

                    I was writing this because

                    We tried to maximize the amount of changes that were Py2 + Py3 compatible

                    If that is not your objective, you can just use 2to3 and be ready.

                    By the way, I really do not understand, why the CPython devs haven’t kept iteritems() as an alias to items() in Python 3 with a deprecation warning to be removed in Python 4. I cannot imagine that it would have been a massive maintenance effort. But on the other hand, making a function call instead of a method call is not rendering code unreadable. I have never heard a Python dev complain about calling str(foo).

                    Essentially, Python 3 adoption has not been slow because of “readability”, but because Python 3 bundles fairly boring changes (iteritems->items) with this massive unicode change (requiring quite a few changes to code bases) and few breathtaking new features that weren’t available in 2.7. This changes at the moment with Async, matrix multiplication operators, etc.

              2. 3

                Python 3 Is Not Turing Complete

                No comment.

                Did you read the note?

                1. 12

                  If anything, the note make it seems like he’s really serious about his Turing FUD.

              3. 9

                Joke or not, the fact that we even have to ask that question significantly harms the credibility of the article.

              4. 5

                Just out of curiosity, why are you sticking with Python2 for now? At this point all of the major libraries have been ported to be 2/3 compatible. In addition, while there aren’t any huge new features in Python3 (besides the byte/Unicode separation) there has been an accumulation of small quality of life improvements that from my point of view make it very much worth it to switch.

                1. 1

                  Not sure about the comment author, but I’ve personally moved over some of my open source libraries to support both python 2 and 3. Moving larger project is tricky though as it involves updating the language, all dependencies and forking the ones that don’t support python 3.

                2. -7


                1. 8

                  Personally, I wouldn’t mind removing voting on comments entirely. Most threads are small enough that if I click through, I read all of the comments anyways. Flagging/hiding is probably enough. Maybe with enough hides, it can propagate to other users to discourage lightweight snark and trolling, but I would hesitate on that.

                  As far as community norms, I have been pretty happy with what gets posted so far. There isn’t much trolling, the comments are generally good, and the topics are interesting. I am not sure what people want to change or enforce here.

                  1. 4

                    Maybe not so much change as define what they are for new users and the scope of moderator involvement.

                    1. 3

                      In that case, I’d strongly prefer to keep it as lightweight as possible. I’d like this community to trust its members as much as is practical. And I’d like to trust the moderators to act as benevolent dictators.

                    2. 4

                      As far as community norms, I have been pretty happy with what gets posted so far. There isn’t much trolling, the comments are generally good, and the topics are interesting. I am not sure what people want to change or enforce here.

                      I fully agree and I also think upvotes/downvotes are one of the reasons this is the case.

                      1. 2

                        My first internet communities were on Usenet, and some of the best discussion I remember was on there. Individual killfiles and moderator removal of persistent trolls seemed to be enough.

                        Nostalgia may be tinging my memories, but I suspect the lack of pressure for approval could help increase comment quality.

                        1. 1

                          It’s really hard to assess that sort of thing … a community can only count on feedback, in general, from people who actively participate in it. When people look in but find a place too hostile to want to get to know, so they leave without ever posting… you’re lucky to ever hear about it. And feedback from people who don’t actively participate is generally ignored, even when it is given.

                          1. 1

                            I’m not sure why you immediately jumping to the assumption of hostility. Looking at some groups I was on (eg, comp.compilers, https://groups.google.com/forum/#!forum/comp.compilers), it definitely isn’t the case.

                            1. 3

                              Killfiles, and any ignore mechanism, seem to imply it to me. I do realize that they aren’t necessarily a sign of an unhealthy community; just a particular type of community. But please read my above remark as agnostic to the specific nature of why newcomers might be turned off.

                              I was on Usenet during that time period, and I can’t say I ever felt welcomed enough to participate more than minimally, but I don’t think it was for any reason now under discussion, so I’m just noting it to say that we do have a little shared context here.

                      2. 1

                        Most threads are small enough that if I click through, I read all of the comments anyways.

                        That’s a good point. While the community is low in number, it’s very easy to just scroll through everything. Doing several Lobsters threads is like one on some other sites. I can sometimes do the whole site that way as there’s more people reading stuff than commenting on it. Probably A Good Thing.

                      1. 9

                        This article could be like two paragraphs. It repeats itself all over. Multiple times.

                        1. 4

                          Is this just a mirror or are OpenBSD taking contributions via pull request?

                          1. [Comment removed by author]

                            1. 5

                              Are there specific reasons for this? ruby/ruby allows posting pull requests as long as there’s a tracking issue on the bug tracker for larger things and takes the time and effort to point people to it if necessary. It’s not much, that can be solved by having a block of standard text or even just putting it in the pull request template github provides.

                              1. 11

                                OpenBSD just doesn’t do github pull requests. That’s not how we work. The project mostly only relies on its own infrastructure; github is not part of that.

                                Another reason why pull request won’t be looked at is that you need a browser to use them. When doing reboots all the time during kernel development starting a browser, or even having a browser installed during a libc ABI bump is just a hassle.

                                1. 4

                                  You can easily extract the patch by appending .patch: https://patch-diff.githubusercontent.com/raw/skade/lazers/pull/15.patch . You can respond to PR notifications through email, even send them to your mailing list if you are so inclined.

                                  Assuming you have some way to do HTTP (which I assume if you have some way to read email), you can extract the patch there.

                                  My point was more: why put a sign up that says “if you land here, we will ignore you, because you are not us”, when you could put up a sing “hey, hello, you are welcome, but for many reasons this is not the way we work, but we will happily teach you (and maybe accept small fixes with a grumble)”.

                                  Ruby has also not switched over to Github for many good reasons (one of them being a lot of specialised tooling built around their infrastructure), but they appreciate that this is an angle of approach to the project and will help people coming from there.

                                  Don’t get me wrong, I do understand and support the reasons for doing your own flow. But why actively working against fresh people that know another flow?

                                  1. 4

                                    It’s a little ironic that the solution to “github is unfamiliar” is “hack the URL to add a secret extension”.

                                    1. 3

                                      The URL is not obscure nor secret, it’s in the email notification you get for a pull request, right next to the link to the diff.

                                      1. 1

                                        Ok, that’s fair, but it’s not obvious how one would discover that without already switching to GitHub.

                                  2. 2

                                    It’s not quite true that you need the web to use them (though commenting on them probably does - which is a big part of reviewing):


                                    But kudos on using your own infrastructure (I’m on a bit of an anti-SaaS kick right now)

                                    1. 2

                                      There is also the GitHub CLI for those that prefer doing most work outside a browser.

                                      I’m on a bit of an anti-SaaS kick right now

                                      Ditto. I do wish Gitlab was a bit easier to manage - I’d love to install it but the number of dependencies along with the frequent security updates make me a bit leery. Gogs looks good but I need to investigate further.

                                  3. 5

                                    Pull requests don’t encourage the same kind of code review as email-based workflows:


                                    1. 2

                                      I’m not saying you should move discussions over, but you can still extract the patch and move the people over to your infrastructure. Would you prefer to leave potential commiters there?

                                      1. 5

                                        The quality of the patch itself is also affected by the medium. People just don’t write “patches” when they use PRs. They write a big pile of commits where whitespace changes are mixed with bugfixes are mixed with new features, all at once, with fuzzy boundaries across commits. There’s also the whole rewriting of the commit/patch stack that seldom happens with a PR, because that involves “scary” push-forces that partially lose the history of the code review, whereas with email it’s just a resend.

                                        I don’t know about OpenBSD, but for the projects in which I have seen, yes, I much prefer the quality of the patches sent to email than what I’ve seen in PR. I am grouchy and would not miss leaving behind PR-based commits, because their quality tends to be lower.

                                        1. 3

                                          I don’t know about OpenBSD, but for the projects in which I have seen, yes, I much prefer the quality of the patches sent to email than what I’ve seen in PR. I am grouchy and would not miss leaving behind PR-based commits, because their quality tends to be lower.

                                          Would you feel comfortable leaving behind the potential committer that could learn your way of writing patches?

                                          1. 3

                                            Some might argue that any potential committer should be keen enough to learn the way a project works. But I can see the value in your approach (and it’s one I’d favour personally - help people to swim rather than throwing them in the deep end, where only the strong survive). Wow, what a selection of mixed metaphors there!

                                            1. 2

                                              Some might argue that any potential committer should be keen enough to learn the way a project works.

                                              Sure, I wouldn’t work with people that absolutely refuse the projects flow. But any approach should me met with the benefit of doubt and is an opportunity to start a conversation, ask people to clean up their patch etc.

                                              E.g. when I first submitted to freedesktop, I had to set up git send-mail. It’s horrible. It was hard to find out I even had to do this and then which the exact mailing list to send it to was, as the one I though was correct was slighly abandoned and full of spam. Took me around 5 hours for a tiny patch.

                                              The review experience with the freedesktop people was stellar, then. But the patch nearly got lost on the approach, and I have been doing things like that for nearly a decade.

                                              On the other hand, people complain about lack of committers.

                                              1. 10

                                                5h for a first patch submission is really not that much. Excepting to spend as little time as possible on submitting a patch makes it sound like the submitted contribution is a “fire and forget” one. Those can of course be nice, but no project can survive on them. Which is why contributors who avoid learning the tooling used by a project are really not that interesting.

                                                In OpenBSD’s case, consider that all developers are already volunteering a significant chunk of their time following the mailing lists and reviewing patches by fellow developers and new contributors. When your goal is security, every change can be dangerous. So code review applies to everyone, and the project relies on everyone to be involved in the canonical code review process to keep the code base stable and secure. .Email is where the real action is in this project. If a non-trivial change made it into the central repository but was not shown on a mailing list, or at least to other developers involved in the area, this would be regarded as a major problem..

                                                With a well established (since 1995) process like that, moving the attention span of even just a few developers to a different platform than email can be a huge distraction. Yes, it serves outsiders who don’t feel like learning the tooling. But suddenly everyone has to watch two spaces for upcoming changes to review, because it’s not all in the one usual place, and who knows what kind of breaking changes the other subgroup over on github is up to.

                                                Your best bet for contributing by pull requests it to ask an existing developer to accept pull requests from you and then channel them to the mailing list on your behalf. But why would any existing developer want to do that?

                                                1. 6

                                                  I am inclined to agree when submitting a patch requires jumping through extra hoops. In this case, we’re asking people to do less work, not more. All one need do is send the output of git diff to the list. I’m pretty sure that’s actually less work than creating a pull request.

                                                  1. 2

                                                    Email? What is that? Some obsolete version of slack?

                                                    I agree with everything that has been said here by OpenBSD developers. The proportion of quality patches received over email is light years ahead of the proportion of good GitHub pull requests. And this doesn’t even address the fact that GitHub pull requests force you to use a particular kind of workflow, while email allows actual developers (the people who do 99% of the work) to use what workflow they prefer. Sure, they don’t allow the casual contributor to chose arbitrary workflows, but that is a feature (not a bug) of the release engineering process.

                                                    The process is stable and works very well.

                                  4. 2

                                    I believe it’s just a mirror and I doubt contributions are being taken via pull request (although @jcs can confirm).

                                    BTW, the mirror has been there for quite a while if I’m not mistaken…

                                    1. 4

                                      It’s hitting news because of the official link on the openbsd.org website. See the commit.

                                      1. 5

                                        Or maybe this one ;)

                                        1. 5

                                          I prefer this one ;)

                                          1. 1

                                            Yes! That’s the good one! :D

                                  1. 10

                                    Everything written in the “Virtues of PHP” section is not specific to PHP, but it applies to all CGI based approaches.

                                    1. 1

                                      PHP, by being embedded in the webserver (classically, and now logically) has performance & deployment advantages over pure CGI.

                                    1. 11

                                      Nice article, although I don’t agree with the point it is trying to make. I think the mistake is here: “The only way to not cargo cult is to know everything. And nobody knows everything.” Of course you can’t know everything, but you should be educated about the technology you are working with. Also, style guidelines != cargo culting. The purpose of a style guide is to establish consistency. The actual style used doesn’t really matter that much, as long as everyone uses the same.

                                      1. [Comment removed by author]

                                        1. [Comment removed by author]

                                          1. 4

                                            The author even makes this point in his paragraph about senior devs. There are so many different technologies with different levels of abstraction. Someone may be a senior developer but that doesn’t mean that they understand all of the nuances of all the technologies they use. That’s why we have designers, database engineers, and API designers.

                                          2. [Comment removed by author]

                                            1. 2

                                              Yep… It is important to not mistake cargo culting for copy/pasting!

                                              One way to prevent spreading cargo culting is having some knowledge before “spreading” the knowledge. The classic example is the idea that any HTTP API that responds JSON is a “REST API”.

                                          1. 11

                                            I already wondered why there are both. It more or less makes sense now. ;) Thank you for the interesting link!

                                            1. 15

                                              Auto fsck when you plug in a device?… this is going to make forensics a nightmare.

                                              1. 15

                                                Yes. I don’t get the whole “everything has to be done automatically” philosophy. Apart from security concerns automounters always enraged me. I don’t want a daemon to mount my disk if all I need to do is using fdisk/mkfs or dd.

                                                1. 31

                                                  I don’t think it’s a stretch to suggest that for most people, most of the time they’re plugging in a disk in order to transfer data to/from it. In that case, automounting the drive is a natural expected behavior that saves time and work for the end user.

                                                  While there certainly are users such as yourself who may frequently be making use of fdisk/dd/etc, I suspect it’s a relatively uncommon case in general. I can see how it doesn’t work for you, but I’ve never seen an automount configuration that couldn’t be disabled by an informed user.

                                                  Given that, “enraged” seems a bit of an extreme response to such tools.

                                                  1. 13

                                                    It’s even one of the common jokes I remember people liked to use 10 years ago re: Linux on the desktop. USB drive on windows: plug it in, it shows up. USB drive on OSX: plug it in, it shows up. USB drive on Linux: [consult dmesg to find device names, issue cryptic series of command-line operations, probably after su'ing to root]

                                                    1. 12

                                                      i thought with windows it was: “plug it in, congratulations your machine is now infected!”

                                                  2. 4

                                                    I don’t get the whole “everything has to be done automatically” philosophy

                                                    Getting ready for Linux desktop?

                                                1. 7

                                                  We are in the same situation. 4 years of Mongo and it’s a pain now. We moving to an other db.

                                                  Performing real-time analytics on blobs of data Curious about why ?

                                                  1. 3

                                                    Same thing here about three years ago. To be fair, I don’t think mongo was to blame here, it just wasn’t a good fit for the kind of data we were handling (mostly relational). Not having someone with mongo experience on the team probably also did it’s share.

                                                    1. 1

                                                      Yes you’re right

                                                  1. 2

                                                    The only argument in favor of supporting printf(“%s”, NULL) -> “(null)” that comes to my mind is to aid debugging. Using something like fprintf(stderr, “Whatever: %s”, s) for debugging and getting a “Whatever: (null)” back is somewhat more helpful than the process crashing.

                                                    That said I believe the advantages of not supporting NULL in printf outweight the disadvantages: Simpler code, early crashes in case of unexpected NULL and you can’t count on (null) working anyway, because it’s not required by any standard.