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:
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 agree, while it’s nice to go back to basics, I am more concerned with the end result, and vite works really nicely to achieve this. Any real project is going to use CI at some point so what’s the issue with having a build step in your pipeline?
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?
>what do you like about putting the information into a gui and using a mouse instead of a keyboard?
I don't have to remember anything to use it, I just click self-explaining buttons and the thing works. The search function is also very nice, and navigating an outline view with the arrow keys, quickly collapsing subtrees as needed, is a very useful tool. Also, drag and drop.
For guis in general, I like how the actions available to me are much easier to learn, and therefore use. The information conveyed through the layout often provides context for related actions.
In my experience, CLIs are great for efficiency, if I am doing a task so often that it becomes rote behavior and learning the tool is no longer helpful, or if I want to automate it. I find my real world need for either of these to be relatively slim, but I am not surprised that it is common for others.
What do you like about having to remember and execute a series of precise and arcane text commands instead of seeing everying comfortably and accessibly presented to you in a graphical form?
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'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.
Interesting! I believe all the new Mac products also work like this. While sleeping a Mac will still stay on WiFi if it’s on a power adapter and the sleeping M1/M2 Macs stay on WiFi even while on battery. They also still respond to some mDNS traffic. When I try to access certain services on a sleeping Mac, like SSH, it’ll immediately wake up. Even port scanning with `nmap -p 22 <ip>` will cause a wake up. That sounds like the wake on “directed packet” thing? In practice I think this mostly obviates the need for a Bonjour Sleep Proxy.
Also, fun tip: You can easily check if a Mac on the network is sleeping or not based on its ping response TTL. While awake it uses a TTL of 64 but while sleeping it uses a TTL of 32. You can use this little signal to roughly keep a log of when the Macs on your network are awake vs sleeping. (Not too much of an actual privacy concern I think)
> 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.
I know a large section of the internet considers it edgy and cool to say things like this but you really should reflect inwardly on this comment and consider that what you're actually doing here is making a joke about child sexual abuse. People who have survived this horrendous crime may not see the funny side.
