1. 4

    A lot of companies seem to think that if they gave out what their process looks like, their process will be gamed and cheated. So I don’t expect them to change their mind.

    1. 2

      I think you’re correct, sadly. I have worked at companies which took this view and don’t think it’s a coincidence that in at least one case the interview process was a common cause of poor reviews on Glassdoor. But it’s a weird view to take!

      If somebody is capable of learning the things they need to perform well in your interview, you would hope they are capable of learning what they need to perform well at the job. If that doesn’t hold true, perhaps the interview process has a problem.

      1. 2

        If somebody is capable of learning the things they need to perform well in your interview, you would hope they are capable of learning what they need to perform well at the job.

        I think that sometimes this is the issue. The interview bears only passing resemblance to the job, so you see other tests to check for stuff like algorithmic implementation ability.

        In the places I had any control over the interview process, I tried to make it as close to the job experience as possible (in terms of resources they could use, interactions with the team, and tasks). This, in my opinion, is best for both the candidate and the company.

        1. 1

          This plan is fine until you get 400 resumes for a job.

    1. 9

      This is amazingly pretty. Some further reading tells me that the author also co-created Cinder, which I didn’t even know existed, but now has sparked my curiosity about making art-through-code. Does anyone have further reading on creating… gesticulates wildly at article this?

      1. 4

        Possibly not quite what you’re looking for? But I’ve been enjoying Robin Sloan’s development diary for a game called “Perils of the Overworld”:


        It’s a bit wider ranging, covering things from map generation (which is why I thought of it here) to story, mechanics and storefront considerations. But, particularly as a fan of his writing, I’ve found the discussion of the process to be very interesting.

        1. 3

          Not quite what I was looking for, but an excellent read where I sort of read the entire thing the first go anyways. Thanks for the new reading material!

      1. 17

        Weird timing (posting the story now as the article is from 2019) with the Perl 7 PR a few days ago. I think like a lot of other programming languages, it will no go away or “die”. The Perl 6/Raku take a clear different path, Perl 7 and 8 coming. The syntax is weird by today standard, yes but is it a problem? I mean we have see the rise of Clojure with a s-expression syntax, functional, etc. making it almost mainstream, why not the idiosyncrasies of Perl?

        1. 16

          s-expressions provide regularity. Perl’s idiosyncrasies are truly idiosyncratic. There are a large number of operators that are single punctuation characters. Many of these behave different in different contexts. This makes it so that when looking at other people’s code you are constantly encountering new idioms. So when I’m looking at a legacy code base I’m seeing idioms from 2015, 2010, 2005, 2000 and earlier.

          1. 5

            That’s why I like Perl. Once I am old and tired, I will find a job maintaining an obscure tool written in Perl, and I will have job security. ‘Maintainable’ software is an evil ploy from corporations scheming to pit employees against each other.

            1. 3

              Obligatory: `perl -e ‘print reverse “dog”’

              In Vyatta and then VyOS, we’ve had our butts bitten by stuff like this countless times, even with strict and warnings. Strict and warnings only take you that far. Then there’s error handling. Exceptions aren’t there, and monadic approach isn’t really possible because there are no types. Then there’s a GC that hopefully will learn how to break circular references in Perl7, four decades after everyone else.

              The code we’ve rewritten in Python has much fewer bugs on average, and when there are bugs, it’s much easier to track them down. Of course it’s not just because of the language, we are fixing old design flaws at the same time, but just rewriting the same code word for word would already be an improvement.

              It’s more like, you can make C safe and reliable by memorizing the MISRA rules and installing an external checker. Or you can switch to Ada or Rust and get a whole bunch of great features in addition to built-in safety checks.

              1. 2

                Ha, ha. Be careful what you wish for. While we achieve a work life balance that corporations are incapable of, I’m on the hook for several dozen different collaborations with huge budgets grinding to a halt during outages. Those muons are not going to research themselves.

                1. 2

                  As a friend is fond of saying: 90% automation, 10% job security

            1. 42

              I’ve always felt the whole “terminal size” thing is a massive irrelevant distraction; I wrap lines (usually at 80) because I think shorter lines are easier to read.

              Obsessively wrapping at 80 (or any other limit) is not helpful though; 90 or 100 can be fine too; the important question is “is it easier to read?” and often – but far from always – I find a length of 80 “easier to read”.

              People/tools that are obsessive about “80” are annoying as it forces unnatural weird line-breaks and make things harder to read, and that’s basically the issue at hand here; the change that prompted this discussion:

              -ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos)
              +ssize_t __kernel_write(struct file *file, const void *buf, size_t count,
              +               loff_t *pos)

              The original line was 85 characters, and it makes little sense to break there IMO.

              1. 14

                The TeX papers cited a study that showed that humans read best (on average) when lines are 66 non-whitespace characters. That actually corresponds pretty well to an 80-column terminal (14 words, average word length 4-5, a bit longer if you have leading whitespace for indentation). I wrote a style guide a long time ago that included that as the rule: lines should not be longer than 66 non-whitespace characters unless breaking them would harm readability.

                The get-out clause is important, because sometimes you really can’t usefully make them shorter, but often you can. The non-whitespace rule is important because it avoids one of the problems the Linux kernel has: they define their tab width to be 8 characters and so any line in a function has only 72 characters to play with and one inside an if block has only 64, which is a tighter restriction than you need for readability.

                1. 20

                  I assume that study was about prose rather than code though. Code is fundamentally different: more punctuation, fewer “words”, and heavy use of indentation that shrinks the line count for the majority of lines in any codebase.

                  I wouldn’t expect a study tested on prose to completely generalize to code. As a hypothesis, I would suspect that people tend to skim through code looking at the “shape” of the text: looking at indentation, statements, balancing parentheses, etc. Lines that are too short means more cases where that shape is modified due to wrapping, hampering readability.

                  1. 5

                    I don’t know if anyone has done the study for code, but I have recently been surprised by some that show that they are more similar than I would have thought. For example, most of us know that syntax highlighting makes it easier to read code. There was a study that I read a couple of years ago for English text that applied part-of-speech tagging and then highlighted words based on this (so nouns, verbs, and so on were coloured differently). They found either an increased retention rate when reading at the same speed or an increased reading speed for the same retention rate.

                    I’d be really interested in seeing a study on comprehension related to line length for code, especially compared across languages (any HCI folks looking for a grant idea?). I’m also not sure how generalisable the originals studies were to across Latin-alphabet languages and I’d be curious if the difference between English and Python is more or less pronounced than the difference between English and German or C and Python.

                  2. 1

                    The TeX papers cited a study that showed that humans read best (on average) when lines are 66 non-whitespace characters.

                    What TeX papers are you referring to here?

                    1. 2

                      Knuth and the PhD students that he had working on TeX published a load of papers about how and why the system works. They’re a great resource for anyone interested in typesetting because they describe the algorithms they implemented, the algorithms they wanted to implement but couldn’t because of resource constraints, and the rationale for picking those algorithms.

                      The paper describing the hyphenation algorithm, for example, describes a technique that MIT is now making a big fuss about where you train a simple ML model (in their case, as I recall, a two-deep Markov chain) and then record the instances where it makes the wrong prediction. For English, the entire hyphenation dictionary is the single model + about 70 outliers. It’s both small and very fast to search.

                  3. 12

                    One reason for “strong feelings” (for the lack of a better word) is multiple buffers open side-by-side in vim for example. I often tend to have 2 buffers open split screen in vim, one with the source file and the other one with the test. Shorter lines make it much easier to support this workflow.

                    1. 1

                      Can you have no more than a width of 160 characters comfortably displayed on your monitor?

                      1. 9

                        With my current hardware that number is about 180-200 (leaving out the space that the file browser plugin takes up on the left).

                        Any more characters and I would have to decrease the font size to still be able to work with split buffers. But I’ve noticed that I feel strain in my eyes when the font size is too low.

                        1. 1

                          If you close the file browser, and have two files side by side, does the file length really have to be limited to 80 for the font size to be comfortably large to read? I find this hard to belive unless you have an unusually small monitor.

                          1. 4

                            With the file browser disabled, each buffer can accommodate about 115 characters at font size 12 (~110 to still have some spacing for comfortable reading). While that’s certainly more than 80, I feel my personal upper limit would be 90-ish. More than that I think I would have to either change my workflow or invest in a new display.

                            Also, yes my hardware might qualify as being slightly dated. The laptop I use has a max resolution of 1920x1080. I do have an external display but that’s even older than the laptop and only supports 1440x900. ¯\_(ツ)_/¯

                            1. 1

                              That makes sense. I vote for 90 being the new default maximum line length, then. ;)

                    2. 10

                      I agree in spirit, but in practice many people lack common sense. Subjective criteria alone are not enough.

                      1. 4

                        Besides the common sense issue, some people appreciate hard formal restrictions for their creations. For example, that’s the whole point of poetry: to write stuff according to arbitrary rules that are orthogonal to the meaning. A sonnet has 14 lines of 10 syllables, just as linux kernel code has indentations of width 8 and a maximum of 80 columns per line.

                        1. 6

                          I would find it hard to argue that arbitrarily limiting the length of a line of code makes it any more “poetic”, in some way?

                          More to the point, much as we like to compare code and poetry, real-world concerns impose. Sometimes it’s preferable to do the less poetic/more verbose thing in the name of keeping your code maintainable and (hopefully by extension) working in the future, for example.

                          1. 4

                            I think what GP is getting at is that (for many people, anyway) one of the top killers of creativity is, ironically, the blank canvas. The total freedom. One of the most common tips for getting around creative blockage is imposing arbitrary constraints.

                            Not saying software engineering is 100% creativity, but at least a part of it is?

                            1. 4

                              Yes, that was exactly my point. I have found that artificially adhering to 80 chars per line and 8-width tabs forces me to code in a very productive way (and especially, that functions have at most 30 or 40 lines). Sure, I have to rewrite and refactor the code quite a few times until it reaches that state, but I do not feel like I’m losing my time, quite the contrary.

                          2. 2

                            Quite the opposite, rules such as the sonnet format are anything but arbitrary. They exist so the message can be delivered in a specific poetic fashion. They allow for a singer or a poetry reader to resource to a certain set of vocal/techniques techniques.

                            It might sound counter intuitive, but meaning of a particular sonnet is not easily transferable to other formats. Much like the meaning of a ballad would hardly had the same strength if passed as an heavy metal song.

                            I do not think there is an equally strong point at all when it comes to people wanting hard formal restrictions in their code because they like it. Engineering should be more pragmatic than this. If there are valid reasons, such as screen real estate in old days, that’s ok. But reasons without practical motivation become an unnecessary annoyance in my experience.

                            1. 2

                              Quite the opposite, rules such as the sonnet format are anything but arbitrary.

                              I have the exact opposite view on the nature of poetry (not that there’s anything wrong with that). While the origins of poetic forms may have something to do with singing, this is not what the poetic thing is about. For example, when writing the lyrics of a song you may need to add an extra syllable on one of your lines and this will not matter: the singer will simply pronounce the two syllables faster, it happens all the time. However, if you add a single spurious syllable in a sonnet or a haiku, then the whole thing falls apart and ceases to be a sonnet or a haiku.

                              If you read modern poetry (i.e., not influenced by any musical form that motivated it) you’ll find that the best poems can be also read as perfect prose, and the strict formal properties (rhythm, rhyme) just fall casually into place.

                        2. 2

                          I wrap to 80 characters almost always when creating a patch, just so there’s one less thing for people to complain about. However, I think wrappings like the above are a particularly egregious failure case. Sometimes adding or modifying a single argument can necessitate a second line…

                        1. 2

                          I love my e-ink ebook reader. It’s convenient, lightweight, it can be read one-handed or easily propped up when I’m cooking or standing on public transport. I don’t have to worry about books being damaged in a bag while I’m travelling.

                          Barring books where I really want the physical item to keep (and some reference books), I will often buy an ebook over physical copy because I know that honestly I will find it harder to make space for reading a physical copy.

                          But I agree that the current options for buying ebooks are largely predatory and that DRM offers an incredibly bad user experience for most people. I try to buy DRM-free where I can, and sadly I do sometimes buy and jump through hoops to remove DRM where I can’t find content another way.

                          My normal trick is to look directly at the publisher’s site for DRM-free copies. Does anyone have any good recommendations for stores which only offer DRM-free content?

                          1. 16

                            We, um, don’t seem to have a pascal tag. So, there’s that I guess.

                            1. 4

                              Wow! I wonder how many games on Steam are written in Pascal.

                              1. -1

                                Why? It is a mature and tried language. It’s not fancy enough. Unlike Rust. /s

                                1. 4

                                  at least now we have the possibility to rewrite it in rust!11

                              1. 24

                                This is an advertisement for a Kickstarter and does not contain the type of technical content worthy of a Lobsters post.

                                1. 7

                                  It links to these technical places:

                                  1. 11

                                    Those would’ve been better submissions!

                                    1. 4

                                      These are what I wanted to see, and I’d have been tempted to hide/flag if the content given had lacked any links to further technical detail.

                                      But since that wasn’t the case, I think there’s value in highlighting the Kickstarter so people can support the project if they’re interested?

                                      I’m often tempted to write comments like this on “does x belong here?” threads then abandon them to avoid spamming up the discussion further. So, an actual suggestion:

                                      Perhaps in cases like this where there’s a good reason to link to the PR material, we could encourage people to also add a comment or blurb calling out any relevant links or technical information?

                                    2. 7

                                      Agreed! I think this is squarely on-topic. It’s an interesting product that inspired me to read about https://pwnagotchi.ai/ and other associated devices. I learned a lot from reading the reading this page and searching the web for the topics mentioned. The USB stack fuzzing idea is interesting. I think I might try exactly that on a piece of embedded equipment I have lying around.

                                    3. 5

                                      It might be. Or it might just be performance art, as the kickstarter in question does not even exist.

                                      If it ships, I’d sure like to see a link to the promised firmware and hardware source. It’ll be an interesting gadget if it ever becomes real.

                                      1. 5

                                        The heart of it seems to be this very impressive beast https://www.ti.com/lit/gpn/cc1101

                                        Probably a real swine to write drivers for, but as usual, ti supplies a bunch of libraries you could use.

                                        Moore’s Law has ceased to be “Doubling of CPU speed every 18 months”. Actually, it never was.

                                        Actually as stated by Moore, it was “Doubling the number of transistors every 12”. That has reach the peak of how much plain CPU speed that can be delivered.

                                        What is still happening, is more and more powerful and weirder and more exotic chips like this.

                                        1. 2

                                          Can you explain what makes this a weird, exotic, impressive beast? Almost all of my deep knowledge relates to server hardware, I haven’t worked with microcontroller-scale things for about a decade.

                                          1. 9

                                            Read the data sheet I linked to for the full details, but basically…

                                            It’s a radio receiver transmitter (transceiver) that frequency hops over 300-348 MHz, 387-464 MHz and 779-928 MHz bands and converts from an RF baseband signal to a stream of samples (i/q’s) and then encode/decode data from that via a bunch of different modem algorithms, plus a bunch of nifty stuff require to make it practical (sync detect, address and crc check, …) in a tiny (2.4mmx2.4mm) package.

                                            In The Bad Old Days that used to require a lot of fancy rf circuitry, maybe an fpga, certainly a dsp, and a hell of a lot of very fancy maths and very smart code.

                                            (Source. I do this stuff for a living)

                                            1. 1

                                              Ahh interesting. Yes, this is why I needed an explanation because I don’t do this stuff for a living. But certainly want to learn more. I can’t do much with a data sheet just yet

                                              edit: And thank you!

                                              1. 2

                                                I’m on the software side of the picture so there is always more for me to learn on the RF/hardware side, but I at least know where the various tasks are done on the device I work on.

                                                There are a lot of these super smart super tiny chips coming on the market… the down side smart equals complex to drive, and chip tends to mean you get what you get, if the chip doesn’t do what you want…. get another chip (means PCB redesign) and have a massive task of rewriting your drivers.

                                                If you ever pull the bluetooth standard and print it out, (you will need to buy a new bookcase), you get an idea of the scale of “tiny,cheap,super smart aka insanely complex” I’m talking about.

                                                That said, a lot of things that were very expensive, are becoming available at commodity prices. In some ways dumber, someways less customised, but with 90% of what you want.

                                                And that will probably improve in time.

                                            2. 1

                                              yes i’d love to know as well!

                                            3. 1

                                              i guess if it is paired with another ti µc it should be quite easy. i have still an ez430 chronos lying around, which wasn’t too hard to write code for, given the examples etc.

                                              1. 1

                                                It would be nice if they marked PDF links more visibly.

                                            4. -1

                                              I don’t think so and so you are wrong because what determines posts to be worthy of lobste.rs is the users, and I am a user of lobste.rs :)

                                              1. 2

                                                I don’t think a flat “you are wrong” is correct when the post has already been spam-flagged over ten times.

                                                1. 0

                                                  It’s just a joke about “x on lobste.rs should only ever be y” purity posts. You know what they say about death, taxes, and arguments about what lobsters “is”…

                                            1. 29

                                              I’ve never worked on a project complicated enough to need something like Ninja, but I appreciated the humble, down-to-earth tone here. This part especially struck me, about being a maintainer:

                                              A different source of sadness were the friendly and intelligent people who made reasonable-seeming contributions that conflicted with my design goals, where I wanted to repay their effort with a thorough explanation about why I was turning them down, and doing that was itself exhausting.

                                              1. 15

                                                I really liked the article too, and learned a bunch of things from it, but I would quibble with this one part:

                                                People repeatedly threatened to fork the project when I didn’t agree to their demands, never once considering the possibility that I had more context on the design space than they did.

                                                Forking is a feature, not a bug. Forks are experiments, and can be merged, and that has happened many times (XEmacs, etc.)

                                                So if I were the maintainer, I would encourage all the dissenters to fork (as well as rewrite, which he mentioned several people did). Ninja is used by Chrome so it’s not like its core purpose will be diluted.

                                                Of course acting like it’s a “threat” to fork is silly … the forkers will quickly find out that this just means they have a bunch more work to do that the maintainers previously did for them.

                                                So in other words, if you don’t want users to treat the project as a product with support, then don’t look down upon forks? That is pretty much the way I think about Oil. It’s a fairly opinionated project, and I don’t discourage forks (but so far there’s been no reason to).

                                                I would use the forks as a sign that people actually care enough to put their own skin in the game… and figure out a way to merge the changes back compatibility after a period of research/development (or not, if it is deemed out of scope).

                                                Anyway, I think Ninja is a great project, and I hope to switch Oil to it in the near future for developer builds (distro builds can just use a non-incremental shell script). A couple years ago, I wrote a whole bunch of GNU make from scratch and saw all its problems first hand. Oil has many different configurations, many steps that could be executed in parallel, and many different styles of tools it invokes (caused by DSLs / codegen). So GNU make falls down pretty hard for this set of problems.

                                                1. 10

                                                  I think it really depends on the fork itself. Experimental forks are great, but often when someone “threatens” it, they also intend on trying to pull part of the community off with them and may not have any intention on ever giving back anything. One example of this was ffmpeg vs libav, where the latter was “hostile fork” that caused all sorts of general trouble (remember when running ffmpeg on Debian said the command was deprecated), and even though it eventually died off in popularity, it didn’t happen soon enough to avoid all sorts of nasty drama.

                                                  1. 5

                                                    If you don’t plan to support the project, the prospect of others pulling part of the community off should feel like a relief.

                                                    I agree with you that it is possible for forking to be a threat, but it’s usually just the way it’s said: do this or else. (And usually it’s an empty threat. Someone clueless enough to consider it a threat is usually not actually planning to follow through.)

                                                    But a polite heads-up that one intends to fork a project should always be cause for relief, in working out some unresolved tension in the community. Taking part of the community away is the whole point of a fork. If the new fork doesn’t intend to support a part of the community they wouldn’t be talking about it. And if people didn’t try it out, it wouldn’t be an experiment.

                                                    1. 2

                                                      Yeah that is one fork I remember being surprised by since I’m a Debian/Ubuntu user… But I would still say the occasional fork is evidence of the system working as intended. There was a slight inconvenience to me, but that doesn’t outweigh improving the overall health of the ecosystem through a little competition.

                                                      Some people may do it in bad faith, but it doesn’t change the principle. It’s hard to see any instance where forking made things worse permanently, where I can see many cases where the INABILITY to fork (e.g. closed source software) made things worse forever.

                                                      e.g. when I used windows I used to use http://www.oldversion.com/

                                                      e.g. Earlier versions of Winamp were much better. Same with a lot of Microsoft products. If it were open source then there would be no need for “oldversion.com” (and there is no none AFAIK). The offending new features can be modularized / optimized. There are some open source releases that are bungled, but outsiders are often able to fix them with patches or complaints.

                                                    2. 4

                                                      [OP here] Thanks for this comment, it is very insightful.

                                                      Upon reflecting after writing the post I came to the same conclusion as you, that I should have encouraged forks more as a way to offload responsibility. I think at the time I was more excited about “fame” or whatever for my project, and now that I’m on the other side of it I realize that it wasn’t worth it. I have a similar thing with my work at Google – a younger me wanted to share it all with the world, but these days I am relieved when only people within Google can ask me about it.

                                                      Unfortunately forks are not as free as we’d like. Imagine someone makes a fork that adds some command-line flag they want, and then some random package starts depending on that; now users are confused about which fork to use, contributors are split, Debian has to decide whether to package both forks, and so on.

                                                      I think I wouldn’t mind forks if they were about meaningful changes, like the person who wanted to make Ninja memory resident to make it scale to their problem space. Especially when you’re making an app that works on multiple platforms, I’ve sometimes wondered if the best way to maintain it is via mutually communicating forks (e.g. a new release on Linux means that the Windows fork can adapt which changes are relevant to it). It’s the forks about trivialities that are frustrating, and in particular because in the context of a trivial change the word “fork” is brought up not in the way you intend, but rather just as a rhetorical weapon.

                                                      1. 2

                                                        Yeah it’s a tough issue for sure. I think different names are important, so a publicly distributed fork of ninja shouldn’t be called ninja. That way it can support different flags, or even a different input language.

                                                        That seems to be respected by most forkers: libav != ffmpeg, and emacs != xemacs, etc. The distro issue is also tricky, as Debian switched to libav and then back to ffmpeg. IMO they should try to make packages “append only”, but I understand that curation also adds some value.

                                                        But I’d say the people who actually would follow through on a fork rather are the least of the problem. Of course it’s not easy to tell who those people are to begin with. Those are people who have the technical expertise to help the project too!

                                                        Another good example of a fork is Neovim. In this video one of the primary contributors to Neovim shows some pretty good evidence that it has met user demand, and also motivated vim author Bram Moolenaar to add features that he resisted for many years!



                                                        It may not have been pleasant for Bram to have his work criticized, but I think it’s a healthy criticism when someone puts in work, rather than low effort, uneducated flaming.

                                                        (I’m still a Vim user, and haven’t tried Neovim, but I appreciate the experimentation. And honestly I learned a whole bunch of things about Vim internals from that talk, despite having used it for 15 years. It’s good to have new eyes on old code.)

                                                        1. 2

                                                          I should also mention that I think the Elm project could save themselves a lot of hassle and drama by respecting several open source norms:

                                                          1. If you don’t want people to treat your project like a product, don’t engage in “marketing”!

                                                          There’s too much marketing on their home page, in a way that appear to elevate the authors/maintainers above the users: https://elm-lang.org/

                                                          It looks like a product. In contrast, peers don’t market to each other. Instead they tell people what they did in plain language. Sometimes that involves teaching and I’ve found that people respect that. But there is a lot of marketing that’s not teaching.

                                                          1. SImilarly, put the limitations up front and center. WE BREAK CODE THAT WORKED. That is perfectly within your right to do, as long as you clearly state that you violate that norm. I wrote a couple years ago that they need a FAQ here: http://faq.elm-community.org/ about that, since it appears to literally be the #1 FAQ, but it’s not mentioned anywhere.

                                                          2. Don’t be hostile to forking. This is mentioned here: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#forkability

                                                          The author of that post may have been unreasonable in other respects, but I do agree about forking.

                                                          So while I think the talk you linked is thoughtful (I watched it awhile ago), I think the project is suffering from some self-inflicted pain…

                                                          1. 1

                                                            I think the Elm project is trying to forge a new form of financing code production, midway between outright corporatization and open source “share cropping”.

                                                            Leaving aside their internal politics, I think something like that is worth exploring and maybe required for the long term health of the space.

                                                      2. 5


                                                        Although this is older now and some sections may be out of date, the author also has an essay on ninja in The Performance of Open Source Applications which is well worth reading.

                                                        The tone is similarly down-to-earth and there’s a bit more in-depth technical content on how it was optimised. It made an impression on me during a recent re-read as one of the better essays in an overall excellent book.

                                                      1. 1

                                                        Arch for my personal machine.

                                                        I like that it’s minimal and doesn’t push a default desktop, tools etc on me: but it has a good package base and decent defaults too. For me it’s a good balance between configurability and usability. I also really like the rolling release model.

                                                        I tried a few other things a while back, mostly to see if I could dodge systemd, but ended up back on Arch.

                                                        1. 4

                                                          I was half expecting a 40-character line length limit.

                                                          1. 2


                                                            1. 6

                                                              50% off

                                                          1. 1

                                                            Company site: Automation Logic

                                                            Positions: Consulting Engineer, Senior Consulting Engineer, Lead Consulting Engineer

                                                            Location: London. Obviously remote for now but normally onsite with some travel within the UK (mostly but not limited to London area).

                                                            Description: We’re an independent IT consultancy primarily focused on public cloud work.

                                                            We’re hiring because we’re growing fast and looking for DevOps engineers from all backgrounds.

                                                            Tech stack varies by client but you’ll be working mainly with Linux, on AWS/Azure/GCP. There’s a whole load of variation within that and plenty of opportunity to train and learn new things.

                                                            We’re officially a Great Place to Work and have a score of 4.5 on Glassdoor.

                                                            Contact: Apply at the link above.

                                                            I’m not directly involved with hiring but happy to answer any questions I can via DM or refer you to our hiring manager.

                                                            1. 4

                                                              I’ve generally worked at places with existing conventions for this sort of thing, and more than once arrived in between naming things. It’s difficult!

                                                              My personal favourite is along the lines of:

                                                              {role}{number}-{environment}.{region or datacentre location}{number}.{company name}.tld

                                                              eg kafka-broker01-dev.lon01.fakecompany.com

                                                              My reasoning being:

                                                              • I want to know what something does at a glance
                                                              • If it does too much to fit in a single name, maybe that’s a red flag
                                                              • I don’t like having to maintain mappings of where things live in racks but I’ve also seen too many boxes get moved and never renamed to ever believe what they’re telling me without proof
                                                              • I never want to see servers named after tube lines again

                                                              For my home machines, generally mythological/cryptozoological. There’s no real naming convention but if it’s a fictional creature that sounds like it would cause trouble I’m in.

                                                              1. 19

                                                                This gave me flashbacks to 2006/7 and the Compiz cube…

                                                                1. 11

                                                                  those were such good times! Also, Beryl and Emerald, oh, can’t forget compiz-fusion (iirc). So much lag with lots of bells and whistles enabled, but so many dropped jaws when showing it off. I even gave a speech on it for a speech class. Good times.

                                                                  1. 10

                                                                    For reasons I tried Compiz as a possible replacement for Marco (the default MATE desktop compositor), and I’ve got to say: it’s pretty performant! The animations that used to be so laggy are just smooth on even modest modern hardware. I fell into the rabbit hole of checking what the project was up to and there’s been some bit of drama about how the versions have changed and broken previous plug-ins, there was even a fork and so on… felt just like the good old times, lol

                                                                  2. 4

                                                                    We have a cube these days in Wayfire. And wobbly windows. And burning windows! :D

                                                                  1. 5

                                                                    OSTEP would probably fit into this list as well. It’s written by an academic even though the author says they prefer books written by practitioners, but I’d argue it belongs still.

                                                                    1. 1

                                                                      OSTEP is wonderful, +1

                                                                    1. 2

                                                                      just finished a song for a new day, and recommend it very highly. deals with a near-future post-apocalyptic world where a pandemic has made congregation illegal, and where a couple of large corporations have absorbed everything.

                                                                      1. 2

                                                                        I guess I’ll add it to the non-fiction pile, thanks

                                                                      1. 2

                                                                        Blue Mars by Kim Stanley Robinson. His Mars trilogy is a monumental work of hard science fiction. It’s become one of my favourites.

                                                                        Also A Fine Balance by Rohinton Mistry. It’s beautifully written but distressing in its unfortunate realism.

                                                                        1. 1

                                                                          Aaah I was thinking I should pick up Blue Mars soon. Love those books, but they are heavy (in the best way)! I found I needed to breathe between reading each one…

                                                                          1. 2

                                                                            Haha, yes, they require quite a bit of work from the reader, and could potentially benefit from some editing. But on the other hand, they’re unmatched in the level of detail and scope.

                                                                        1. 4

                                                                          For me:

                                                                          Arlott, Swanton and the Soul of English Cricket. I’m not normally a big reader of sports books but this was a present and is thoroughly wonderful. Also ended up being well timed since there’s no cricket on at the moment.

                                                                          Agency by William Gibson. His latest, probably doesn’t need an introduction, and so far as good as you would expect.

                                                                          Designing Data Intensive Applications. I’ve had this book since it was in early access several years ago and it’s fantastic: but I’ve never actually read it cover to cover. Highly recommended for good all-round coverage of databases, data processing and distributed systems.

                                                                          Recently finished: The Lean Startup, and Becoming a Technical Leader.

                                                                          1. 10

                                                                            It seems like the author is misconstruing things that are operating-as-intended as “quirks”, because it didn’t fit their initial expectations. Much of these points are non-issues for seasoned Go developers

                                                                            Edit: For example, the gripe about time.Duration wouldn’t be a problem if the author checked the documentation, which explicitly states:

                                                                            A Duration represents the elapsed time between two instants as an int64 nanosecond count […]

                                                                            You can’t really blame the language for something if you didn’t read the documentation…

                                                                            1. 22

                                                                              It seems far too easy to just handwave things away with “it’s documented”; people make tiny mistakes all the time; it’s normal. Minimize the surface area for these kind of tiny mistakes and facilitating easy learning are explicitly among Go’s goals.

                                                                              context.WithTimeout() accepts a time.Duration; it’s not unreasonable to expect that it will reject a simple int value. It’s an (arguably silly) mistake, but also he kind that people make all the time, since you can’t remember everything and it’s an easy one to make. All other things being equal, Go would be better and more robust of the typechecker was more strict about this.

                                                                              We could, by the way, use your same “read the documentation”-argument against using any type checking at all: “why did you pass an int to this function? It’s clearly documented it only accepts string!”

                                                                              1. 10

                                                                                Much of these points are non-issues for seasoned Go developers

                                                                                What about beginners or people new to the language? To them it may just be, like the author points out, surprising.

                                                                                1. 2

                                                                                  Just because something is surprising doesn’t make it a quirk

                                                                                  1. 7

                                                                                    Doesn’t it? I thought that was pretty much the definition.

                                                                                    Quirks aren’t a killer and I don’t think the author is arguing against using Go. But if its behaviour is surprising or unexpected to newcomers then that’s something to be aware of and hopefully improve upon.

                                                                                2. 1

                                                                                  Much of these points are non-issues for seasoned Go developers.

                                                                                  Go’s goal is to enable inexperienced developers to churn out code fast. So I think what you are arguing is missing the point on Go’s target demographic.

                                                                                  Especially when it comes to time, I think Go does not have a good track record, as described in I want off Mr. Golang’s Wild Ride.

                                                                                  1. 2

                                                                                    Go’s target demographic, experienced or not, still has to read the documentation even if the features are intended to be easy to learn/use.

                                                                                    Quirks are peculiarities or minor departures from the intended effect of a feature; it’s fair to argue some of these even constitute bugs, but I don’t think that’s the case in several of the cases addressed in the article.

                                                                                    1. 13

                                                                                      You seem to be misinterpreting the word “quirks”. The author is talking about design quirks, meaning parts of Go’s design which, while working as designed, is still surprising or awkward in some way. The most extreme case I can think of right now is probably Javascript’s == operator; it does exactly what it was designed to do, but the consequence is that == isn’t a transitive operator, which is really surprising (a “quirk”).

                                                                                    2. 1

                                                                                      I don’t think that article supports the conclusion you draw from it.

                                                                                      1. 0

                                                                                        No, the goal of Go was to fix the issues Google had with large C++ project.

                                                                                        1. 2

                                                                                          The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

                                                                                          – Rob Pike

                                                                                          1. 4

                                                                                            Also Rob Pike:

                                                                                            The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at Google. The computing landscape today is almost unrelated to the environment in which the languages being used, mostly C++, Java, and Python, had been created. The problems introduced by multicore processors, networked systems, massive computation clusters, and the web programming model were being worked around rather than addressed head-on. Moreover, the scale has changed: today’s server programs comprise tens of millions of lines of code, are worked on by hundreds or even thousands of programmers, and are updated literally every day. To make matters worse, build times, even on large compilation clusters, have stretched to many minutes, even hours.

                                                                                            Go was designed and developed to make working in this environment more productive. Besides its better-known aspects such as built-in concurrency and garbage collection, Go’s design considerations include rigorous dependency management, the adaptability of software architecture as systems grow, and robustness across the boundaries between components.


                                                                                            1. 2

                                                                                              Where does this quote come from?

                                                                                              1. 2

                                                                                                That quote is from the talk From Parallel to Concurrent. He says it at 20:40.

                                                                                      1. 2

                                                                                        I can’t speak to the ITSB cert, but am certified in other areas.

                                                                                        Firstly, I would say that whether it helps you get a promotion/raise in your current position really depends on your situation and company. You will have more sense of the atmosphere there - but in general, if your employer is willing to pay for a cert then that’s a good signal that they value the effort you are putting into it.

                                                                                        To answer your specific question: I took a certification because I wanted to challenge myself. My employer paid and I believe it contributed to my being promoted later that year.

                                                                                        When it comes to moving jobs that same certificate has been called out as a positive in more than one interview, including for the position I currently hold, so I believe it was worth maintaining.

                                                                                        My personal opinion would be: take a cert to challenge yourself and prove you have reached a certain level in that area. Don’t do it just to get the piece of paper (although, if it’s free and contributes to a checkbox on a “can I be promoted” action plan then it’s hard to argue against).

                                                                                        In the long term, I think the effort and aim to improve is what people will hopefully recognise.

                                                                                        1. 5

                                                                                          calibre does this too, and with the dreaded curl | bash to boot.

                                                                                          Discord is not necessarily a privacy-preserving medium, and it’s not free software: but maybe that’s fine for some use cases like gaming where you may not want to host a server, and are willing to make the trade-off for a no-hassle experience.

                                                                                          Ideally we’d have a free option with a similarly easy experience, but I’m not sure we do. Meanwhile, I don’t put this down to malice.