1. 8

    I love her work, but this is naked product advertising. Flagged.

    1. 12

      I also find it weird (as the author) for this to be on lobsters – to me if something costs money to read, I’m not sure that it makes sense for it to be posted to a site like this, because most folks won’t be able to read it and then it’s not possible to have a discussion about the content :)

      1. 3

        Indeed. Congratulations again though on your work! :)

        1. 1

          Thanks a lot for your work, I am a big fan myself and distributed a bunch of print copies of your CC-licensed work among friends and colleagues! :)

          I could imagine that the fact that gumroad seems to support only credit card payments hinders some customers who, like myself, live in a region were credit cards are not as common as they seem to be in the US. I bought a pre-paid card just for your zines, but supporting at least something like paypal would be great.

          1. 2

            Gumroad now has paypal support for me. (I live in Europe, maybe it’s a regional thing?) When I click to the payment dialogue, it shows the credit card one, but also a button where I can pay with paypal.

            I tried that out last week, when I bought the Bite size linux zine. :)

            1. 1

              You are right, that works for me too. I just had missed the paypal button, thanks for the hint!

      1. 10

        I’m actually going to send this article to a few peers, maybe even my manager. I live about 1h away from the office when there’s no traffic. If I want to encounter no traffic, I have to leave home at the latest at 5 AM, or no sooner than 8:45. This essentially means working from 6:00-6:30 to 15:00, or from 9:45-10:00 to 18:00. There’s also traffic on the way back.

        I don’t want to get closer to the office because: this is my childhood neighborhood, I live right across the street from my parents (which is great when you have 4 kids and/or a cordial relationship with your parents), and the land + house that we have would be worth 2.5 ~ 3 times as much if I moved to a closer location.

        Logistics aside, this is also much better for my concentration, I get much less often interrupted too. I need more of this.

        1. 14

          one really cool side effect of having a remote-friendly team is that it makes it normal for people to work from home occasionally – one person on my team has kids and he’ll pretty frequently work from home so that it’s easier for him to pick up his kids from school or something, and it’s not an issue at all since half the team is remote anyway :)

          1. 5

            My commute isn’t quite as bad as yours. When I started my current job, I negotiated the expectation that I would be working from home about half of the days. I now work from home 2 days a week some weeks and 3 days a week on other weeks. My commute is still terrible half the time, but on average it’s not a bad commute. I would phrase it as “I’m feeling burnt out because of my commute and I don’t think I can keep doing it 5 days a week for much longer. I would like to begin working X days per week from home so that I can continue to work for the company”. This doesn’t send an aggressive ultimatum, but it signals that you’re probably going to quit soon if they don’t accommodate you. If that doesn’t work, it’s probably time to find a new job.

          1. 2

            Ugh. I hate performance reviews, whether writing or receiving. There is literally no upside. You’re giving HR words that may be used against someone– or against you.

            Feedback should be verbal and direct. You should be able to get a sense of who can handle tough feedback and who might respond better to gentler language. There’s no formula for it.

            As for written feedback and the futility thereof, management knows (or should know) who the high performers are and will reward and promote them. If they get it wrong, there’s nothing you can do as a grunt to change their minds. The only thing that comes from putting stuff in writing and handing it over to management is risk.

            Of course, if you’re a manager, you have to use performance reviews to protect your people so they can focus on their work rather than politics. It’s part of your job. You can’t not write reviews because you don’t like doing it. But reviewing peers is, in my view, inadvisable. If you have something to say, deliver it privately.

            1. 4

              this is an interesting comment! At my job “just don’t write peer reviews” isn’t really something I can do, which is why I wrote this post – this is a small but mandatory part of my job, so how do I handle it when it comes up?

              The only thing that comes from putting stuff in writing and handing it over to management is risk.

              Part of the reason I wrote this post is that I feel like putting negative feedback in writing where I have no idea who will see it is a bit risky! But I feel like writing down positive feedback is a lot less risky, and so my hope is that if I mostly stick to that then the outcomes will be okay, and maybe I’ll even say something useful by accident.

              1. 1

                I’m late to come around to this; I’ve been in Mexico for the past week.

                I agree. Ratting someone out to management is bad form and a way to make a permanent enemy, but putting positive feedback (or even having a conversation with the person about what you should be saying) is not a bad idea. What this ought to be, instead of a way for workers to slag each other (to executives’ benefit), is a way for them to help each other out and build up each other’s stories. If used properly, these tools can be used for good (i.e., in workers’ favor instead of executives’).

            1. 2

              I don’t know enough about Linux namespaces. Couldn’t this just be handled with chroot?

              1. 2

                I don’t know what you mean by “couldn’t this just be handled with chroot” (what solution are you suggesting exactly?), but mount namespaces are not the same as chroot! here are a couple of articles that might be helpful: http://man7.org/linux/man-pages/man7/mount_namespaces.7.html, https://lwn.net/Articles/689856/

                1. 1

                  You can’t access the cgroup namespaces from the host system? That’s crazy. This is such a crucial feature of jails and zones.

              1. 9

                She should be able to use dtrace to investigate deeper.

                1. 13

                  Where would you start with using dtrace to investigate this? I already know the responsible system call – is the idea that I could use dtrace somehow to trace what resource is under contention inside the kernel?

                  I’ve basically never used dtrace except running dtruss occasionally to look at system calls so it’s pretty unclear to me where to start.

                  1. 12

                    I’m not a dtrace master, or even low-level amateur but this might be a first start:

                    sudo dtrace -n ':::/pid == $target/{@[stack()] = count();} tick-5s {exit(0);}' -p PID_OF_YOUR_STUCK_PROGRAM

                    That will sample the kernel stack of the process any time something happens with it and count them, then after 5 seconds it’ll print the kernel stacktraces out in ascending order of count. You can also look at -c instead of -p

                    That’ll probably give you way too much stuff, though. You can only get the stack traces when it does a syscall with:

                    sudo dtrace -n 'syscall:::/pid == $target/{@[stack()] = count();} tick-5s {exit(0);}' -p PID_OF_YOUR_STUCK_PROGRAM

                    Maybe what you could do is use dtruss to figure out what it’s stuck in (probably a syscall?) and then use dtrace to see what’s going on there. For example, to see what syscalls were called in doing sleep 10 I did (on FreeBSD):

                    sudo dtrace -n 'syscall:::/pid == $target/{}' -c "sleep 10"

                    And I got a bunch of output, where it clearly sat for 10 seconds on:

                      2  80973                  nanosleep:entry

                    Then, to see exactly what goes on in the kernel for this process between nanosleep:entry and nanosleep:return, I did:

                    sudo dtrace -n 'BEGIN {trc = 0} syscall::nanosleep:entry /pid == $target/ {trc = 1} syscall::nanosleep:return /pid == $target/{trc = 0;} ::::/pid == $target && trc == 1/{@[stack()] = count();}' -c "sleep 10"

                    Kind of hard to read but if you pull the stuff in quotes out you can see it’s using a variable called trc and for this pid, when nanosleep is entered it sets the variable to 1, and when nanosleep returns it sets trc to 0. Then, for any probe for this pid if trc is 1 then record the kernel stack. I got a bunch of output in that.

                    Hopefully that is helpful. I’m not near a trace wizard so I’m sure there is some much more clever things one can do, but that might be a start to digging.

                    You can see probes available to you with dtrace -l.

                1. 7

                  One can imagine a scenario where one of the nodes has a latency higher than it’s election timeout, causing it to continuously start elections

                  I have used Raft in production and can confirm this is a real thing that happens. Here’s an issue on the etcd repo discussing this problem https://github.com/coreos/etcd/issues/7970. basically: “a 5-node cluster can function correctly if two nodes are down. But it won’t work if one node has slow disk.”. Which is a weird failure mode!

                  also I found this post valuable, I’d never read the raft website/paper but this appeared in my RSS reader and it caused me to actually learn more about how Raft works!

                  1. 3

                    Using Raft’s PreVote extension should alleviate this issue, though etcd’s current PreVote implementation could be more stable. See https://github.com/coreos/etcd/issues/8501, https://github.com/coreos/etcd/pull/8517, https://github.com/coreos/etcd/pull/8288 and https://github.com/coreos/etcd/pull/8334.

                  1. 3

                    I don’t understand why these, frankly, childish drawings of things you can learn from reading a wikipedia article have reached this level of popularity.

                    1. 24

                      I’d be the first to point out that I’m not a particularly talented artist. So why do I spend my time drawing comics, when I’m not even that good at drawing?

                      it’s because I’ve found they’re, in some situations, such a great way to communicate that I feel silly not taking advantage of it

                      A few reasons:

                      • Comics are great for summarizing. I wrote a blog post at work about how we do service discovery. I started out with just writing 1200 words, and trying to be as informative as possible. I thought it was pretty good. But then I drew a comic summarizing a main ideas! A really common reaction was “wow, the blog post took me 15 minutes to understand, but after reading the comic I understood the main ideas in 30 seconds”. This is awesome because somebody can see the main ideas and decide whether they want to continue reading.

                      • I can trick people into reading about concepts that they might otherwise think are too hard or not useful or not fun. I wrote a zine called “linux debugging tools you’ll love” (here). This zine discusses a lot of tools which are traditionally considered a little bit advanced. Because of that, a lot of people don’t even know they exist, or might not consider trying them! All kinds of people have told me “julia, i read your zine, and the next day I used a tool in it to fix a bug at work”.

                      • They’re an awesome way to introduce people to new ideas. Anyone can learn about /proc! It is not that complicated. But a lot of people don’t even know /proc is interesting. This comic about /proc took me maybe 15 minutes to draw. I posted it on twitter and it got 180,000 impressions. A lot of people replied to me “wow, that’s so useful, I didn’t even know that that existed, I’m going to go learn more about that now!!”. They will probably learn more about it by reading the man page or Wikipedia or some more traditional means. But they learned about it from a silly drawing :)

                      Basically, I do it because I love telling people things about computers that help them (“omg julia, i had no idea about this, this, this is so useful”), and silly drawings turn out to be a pretty effective way to do that.

                      1. 2

                        Thanks for the great answer, but as I’ve already been downvoted as a ‘troll’, I won’t comment any more.

                      2. 8

                        Because they have a carefully chosen tone that maintains a sense of psychological safety. If you’ve never been told off for learning I doubt it’d make a lot of sense.

                        1. 2

                          Yeah, it doesn’t make much sense for me to need psychological safety when learning about /proc.

                      1. 4

                        I think someone making books for Linux beginners should consider offering her a job or gig making imagery for both common and complex stuff. She beautifully presents system calls, proc, signals, and killing processes. Her graphics might help the learning process for visual learners.

                        1. 8

                          i’m a much better professional developer than professional artist, or at least I hope so given my art skills :) (and the job market is much better <3)

                          probably going to stick to writing software.

                          1. 1

                            Well keep up your hobby. We definitely enjoy it. Might even turn into something profitable on the side one day if you’re lucky. :)

                            1. 1

                              Stick to writing software, by all means, but please please please continue to write and draw about it. I know I’m not alone in admiring your work.

                          1. 2

                            I went to Hacker School and I found that the social rules worked very well.

                            I’m not sure the Lobsters needs to be a place free of discussions of sexism. That works well at Hacker School for reasons that I can’t quite articulate, but there’s certainly a place for discussions of bigotry in the world at large.

                            1. 3

                              Could call it “Dev Culture”

                              1. 1

                                I like “dev culture”.

                                1. 1

                                  But, so far, all tags are one word. So maybe not.

                                1. 5

                                  I do an awful lot of interviews. Sadly, few people ask questions like this.

                                  It’s too bad because at least with me, I’m far more impressed with candidates who turn the tables on me and interview me as well. Far too many end up just trying to be “amendable” and “impress”. My advice to people interviewing is, don’t worry about fucking it up. Think about what you want in a job and make sure the place you are looking at will give you what you want. If the place is really good, the interviewer is probably going to be delighted that you asked more probing questions.

                                  1. 5

                                    I worry a bit about this advice – asking tons of questions is working well for me right now, but it also depends on the market and how much privilege/power you have as an interviewee.

                                    1. 2

                                      and if you don’t and end up somewhere were you only got the job because you didn’t ask questions? it fills an immediate economic need but we are talking about software engineering jobs. the ratio of supply to demand is greatly skewed towards demand.

                                      1. 5

                                        Eh, I’m totally on board the ask-lots-of-questions train–I have been known to ask more questions of my interviewer than they asked me!–but let’s not pretend there’s not risk involved. For example, a company’s parental leave policies are a GREAT (maybe one of the best) indicators of their approach to gender relations and work-life balance, but as a woman of childbearing age there is no way in hell I’m risking an offer by bringing that up in an interviewing situation, even though I know that legally and in a perfect world that is not supposed to influence hiring decisions. (FFS, I feel the need to disclaim that I have no interest in taking advantage of anywhere’s paternal leave anytime soon, in case someone I know in real life is reading this!) Most of the questions under “quality of life” have similar implications that can potentially be negative; if you’re working against various implicit biases to begin with the risks involved in even planting that seed of doubt may not be acceptable. There’s other skews than demand over supply in the software engineering world…

                                        1. 3

                                          i wasn’t trying to say there is no risk. i’m suggesting that not asking those questions mean you risk ending up somewhere you aren’t going to want to work and that has to be balanced again the need for gainful employment. we are fortunate as engineers that we can be more selective. unfortunately, due to various biases, some of us can afford to be more selective than others, but as a profession, we are blessed that we can regularly take this into account.

                                          1. 3

                                            Agreed! I’d add that if you’re on the hiring/recruitment side it’s worth thinking about how your potential hires are weighing that risk vs information calculation. If the answers to any of those more risky questions are a selling point for your company, getting out ahead of that dilemma by volunteering that info up front or highlighting it in your job listings is a great idea.

                                            1. 2

                                              i try to do that as the vast majority of the time, i’m on the hiring/recruiting side.

                                      2. 1

                                        It doesn’t need to be tons of questions, but 3 good probing questions can easily give you a feel for what the company and environment are really like.

                                      3. 1

                                        My advice to people interviewing is, don’t worry about fucking it up.

                                        I think I understand the intended mindset this is meant to advocate, but I wonder if this works when I know I’m interviewing for my dream job? How do I not worry about the interview, when I, as the interviewee, already know the job is precisely what I want? This seems like a special case where my primary objective has to be to impress and possibly show I’m amenable (we’re talking about a dream job after all).

                                        Further, what if I give the interviewer the wrong impression by asking questions that could either be interpreted as pedantic or intrusive? What if I give the interviewer the impression I don’t trust the company to get even the basics right? Leading with the impression that I’m concerned at once with small details most decent places are bound to get right or showing mistrust doesn’t seem like something an employer is likely to respond positively to. Conversely I do see how some of these questions might be interpreted positively, as showing an interest in the particulars of the job and how they relate to you as a potential employee–certainly that should be a positive signal to the interviewer.

                                        However, if I know I’m interviewing for my dream job, I’m probably not wondering if they use version control, for instance. And asking a question like that seems like it could be a bit of a red flag or at best noise that could be avoided in favor of more relevant discussion. So maybe this list is potentially less applicable to an interview you know you can’t fuck up. In which case, I’m not sure I can walk into an interview without worrying if I’m going to make a misstep.