314's comments

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.

In a similar vein there is https://www.youtube.com/@ExploringtheUnbeatenPath

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.

You don't know what their job was, or what kind of engineering decisions they were having to work around. You don't know what kind of corporate hieracrchy they were stuck in, or what effect it had on what they were building. Without knowing any of those things it is a bit premature to be making character judgements.

The project name sounded familiar: CETEC. It has taken a fair amount of googling to realise that it is not Setec (astronomy) and there are still secrets.

In my experience I've found it easier to write Python code. The set of basic types is a little larger, and the core builtins cover more of what I need to do. Lua is a bit more fiddly and verbose, which leads to a more difficult development process (in my opinion). Why would you argue that they have the same level of difficulty?

Nice idea, as python is much easier to write code for than lua so should fit game scripting well.

But, the examples are not the kinds of things that I would care about before trying to put this into a game engine. It needs a different set of examples.

* How hard is it to call into a C function from a hook in the py code?

* How hard is it to wrap / unwrap values from their py representation to C?

If you want people to embed the interpreter into an engine then show that it is clean/easy to do the embedding, rather than showing that the interpreter can execute code. I would assume that it executes python, but need to know how well it embeds.

It's been more obvious that they are losing against SEO in the past few years. When searching for programming results it is rare for an authoritative source to be be above w3schools or geeksomethinggeeks. Even with a specific query for something that is not a beginner tutorial you have to wade through that shit to even get to stackoverflow answers.

Either google engineers have really started to dig w3schools or they don't eat their own dogfood any more.

> Computers can't learn from their mistakes. Humans can.

So.... Machine Learning is a thing.

> That's the whole point behind bans, is it not?

No, it may be one point behind imposing bans but it is not the whole (only) point. People can also learn from watching other's make mistakes. Bans communicate to people other than the person getting banned that something is unacceptable.

In this case it seems to communicate that "but it is not a person it's a bot" will not be a srong enough reason to break their rules and escape a ban.