314

But Aaron Swartz did it for the benefit of other people. These fine people did it to uphold american values and enrich themselves at the expense of others. The law is clearly on their side.

ssshhhhhh, the Rust Evangelism Squad will hear you.

To be fair that whole boat sailed with the "I'm a mac he is PC" series of adverts.

I tried this on a random Swedish person and she identified all of the names as people that sounded like a genius. Seems legit.

Nice. I'll have to try this. I may have ssh'd into a sleeping mac before and assumed that it had failed to sleep. I did not realise what it was doing.

It's ok to like different things - there is no need to attack a different approach. If you find the visual layout comfortable and accessible then thank you for answering the question.

I prefer to use vite - you get handling of imports without needing a separate bundler step, but you get hot reload as well. I find it is a nicer experience, YMMV but it is good to have alternative options:

  FROM node:19.1.0
  WORKDIR /project/vite_project
  RUN npm init -y
  RUN npm install react react-dom
  RUN npm install -g esbuild
  RUN npm install vite
  EXPOSE 8081
  CMD ["npm","run","dev"]

The react install isn't normally there if I start light - but it shows that the path to throwing in a framework is smooth. Typically combined with:

  #!/usr/bin/env bash
  docker build -t vite_play -f Dockerfile.vite emp/

Obviously there is something to a bundler step happening in the background, but it is fast enough (and implicit) so it doesn't get in the way of rapid prototyping.

I guess that I'm not the target audience for this - I like grep as UI on top of lsof, maybe in combination with less, and I've always found it fast and easy to use.

For people that are the target audience of this, I'm curious - what do you like about putting the information into a gui and using a mouse instead of a keyboard?

I'm finding it hard to parse your argument. Are you saying that large organizations would rather have cheap-but-mediocre programmers than good-but-expensive programmers? Why would this be a benefit to them, surely they want good programmers?

This is a nice idea, I was jsut wondering how to do that.

Another approach (if it is supported by the adaptor) is to configure WoL so that it does not need a magic packet. Some adaptors can be configured to wake on any "directed packet".

I have a linux server sitting downstairs that I might play around with. It would be nice if the sleep support featured a timer and integration with the system cron daemon. Then it could wake on a directed packet or when there is a scheduled task.

Fair point, I had not really considered it that way. You are correct.

> It's easy to write things like this when you're at the wrong end of the Dunning-Kruger bathtub

Amusingly, only the most simplistic graphs of the Dunning-Kruger efect would portray it as matching a bathtub curve. In particular the rather slow slope of confidence rising as competence improves is dramatically (and significantly) different from the sharp drop-off of false confidence. Rather than two steep sides, there is a marked asymmetry.

I suspect that you may have misunderstood the author's point though. Even if you swap the arguments as you suggest, you still run into this problem described in the link that the author provides:

  When used on a text mode stream, if the amount of data requested (that is, size \* count)
  is greater than or equal to the internal FILE \* buffer size (by default the size is 4096 bytes,
  configurable by using setvbuf), stream data is copied directly into the user-provided buffer,
  and newline conversion is done in that buffer. Since the converted data may be shorter than the
  stream data copied into the buffer, data past buffer[return_value \* size]
  (where return_value is the return value from fread) may contain unconverted data from the file.
  For this reason, we recommend you null-terminate character data at buffer[return_value \* size]
  if the intent of the buffer is to act as a C-style string.

i.e. his complaint is that if he initialises the buffer to zeros and reads N bytes into it there is the possibility that zeros after the N bytes are overwritten.

This is distinct from the problem of not getting enough information back if you swap the argument order, and as it matches his decription in the text before the link I would assume that the swapped arguments are actually a typo rather than a misunderstanding of the API.

So much hurt. Point on the doll to where the academic touched you.

You seem to be making a lot of assumptions, and it's unclear how much direct experience you have of being in a bad situation where the day-to-day job does become saying no.

Some examples that you may be unfamiliar with:

* Working with a manager who is a former dev that likes to micromanage the decisions that their team makes.

* Working on a team that is driven / owned by a product owner who doesn't understand as much engineering as they think that they do.

Neither of these situations are examples of healthy functioning organisations, but they do occur. They are not an exclusive list either, just some random examples from personal experience.

Shooting down ideas may be a symptom of somebody being a prick, or it may indicate that they know why the idea will break the system (even if it closes a ticket or gets a particular feature finished). The ability to propose an alternative can be restricted by just how batshit insane the demand is.

It's not that you are wrong when you say that an engineer should respond "This doesn't work, but how about this?". But that characterization is incomplete - sure it works in theory, but there are many places where it does not work in practice.