wolletd

To stay in the examples: when it came to the text file and database I thought.

The issue usually isn't that you receive too many mails for the size of a text file, but that you probably want to store additional data soon, in a structured way. So you start hacking some field separators in your file, it's becoming a file format and switching to a database later is notably more work than it would have been at the start.

Technically, COM1, COM2 etc. are filenames as well. They are just special in that they are available everywhere. That's why you are not allowed to create any file named COM1 or such.

But it's a DOS relic. Actually, Windows has a "Win32 Device Namespace" under "\\.\", which is something like /dev/ in Unixoids. COM1 is actually \\.\COM1: https://learn.microsoft.com/en-us/windows/win32/fileio/namin...

I'm working at a small company that does computer vision and image processing stuff, doing a lot with embedded systems.

At some point, I was asked to write code to save images on live systems to be downloaded and used for... CV stuff. Also, the images had to be (although weakly) encrypted for IP reasons. The issue being that those cameras run at 200fps when there's anything of interest and use their compute to do image processing. The flash memory used also isn't made for this kind of write speed.

All that is to say: JPEG is insanely efficient. It takes a moment to compress the image, but only encrypting 10% of the data saves a lot more and the flash memory can keep up way longer than with raw images.

I had to generate some difference images though to convince some CV and management people that we don't need raw images. If our analysis results would depend on a dozen pixels not being off 1-2 gray values, it's broken. There's more noise in every single image than JPEG-induced errors.

And there are also already copyright holders filing lawsuits against AI image generators for exactly that: https://www.theverge.com/2023/2/6/23587393/ai-art-copyright-...

I somehow forgot about fortune over the years.

Guess I know what will be set up on my severs over the weekend.

On some devices, I see the line "EFI stub: load initrd from command line option" (or similar) as just another line on the same text screen that prints early UEFI messages.

And I'm still wondering about that and how text-mode/console output works.

I get it when I'm attached via a serial port, but... how many console rendering implementations for VGA output are on my system?

I'd say that's just the view from one side. If you overdo your automation without considering generalization and parameters, you lose flexiblity.

But when approached from the other side, you can also have generalization without automation: if you don't create a script for your five commands even if they turn out to be used over and over again.

For example, I'm imagining deployment of software releases:

  1. If you don't even have a defined way of deploying a release, you have neither generalization nor automation
  2. If your deployment is well defined, but requires several commands to be executed manually each time, you have generalization, but no automation
  3. If you can deploy a release with a single command or two, you have both generalization and automation
  4. If your release always deploys on a git push automatically, you lost generalization again

The last one is maybe a little odd, but in terms of generalization, I think of it as "being in control of which version is deployed without working against your own scripts".

To be fair, the package must be provided by your distribution, otherwise it's just another random download, only in a different format.

Even if you are adding a third-party package repository, you just change the downloader. Although you usually get signature checking with that step for free.

And therein lies the issue: It's not the job of the software developers to provide packages for your distribution, but the job of your distribution maintainers.

So, if your distribution will probably not backport $newver of some tool to your release, you are only left with installing it via different means.

If you find yourself always installing software like this because your package repositories don't contain what you want, it may be a good idea to just check out different distros.

I've seen Fleet in my JB Toolbox, but haven't touched it yet.

But it is the obvious move. All the current JB IDEs are built upon the same basic IntelliJ platform, anyway.

It's "only" a matter of restructuring all that to have only one IDE where you can opt-in to support specific languages and now you have something like VSCode.

I guess the point is that it generates convincing and consistent texts. That's new and it's a building block for any futuristic AI that actually knows stuff: it also has to generate good text to communicate the knowledge.

Some days ago, it told me "well, Boost has a function for that". I was surprised that I haven't found that myself.

I took me 10 minutes and opening the Git Log of Boost ("maybe they removed it?") until I realized "well, it just made that up". The whole answer was consistent and convicing enough, that I started searching, but it was just nonsense. It even provided a convincing amount of example code for it's made up function.

That experience was... insightful.

While we often say "If you need something in C++, Boost probably has it" and it's not untrue, ChatGPT seems to exercise that idea a little too much.

I let ChatGPT build a simple glue class in C++ to set the backlight of a display, just because that was what I was doing at the moment.

I noticed a bug, informed ChatGPT and it fixed it correctly, which is cool and all.

But I'm really interested in the next thing: I didn't save the code and so reran the same prompt a few days later. Now it was correct the first time. Did it learn the bug? It also lost the Exception handling it had in the first version, though. And it changed it's naming scheme for member variables from `m_foo` to `foo_`.

I recently built something to connect asio with gRPC: https://github.com/WolleTD/asio-grpc-callback

The channels and co_yield-capable coros from asio::experimental are quite fun to use for streams. When you have prior experience with async programming in other languages, e.g. Python or Rust, it's really handy that you don't have to define any awaitable types to use asio with coroutines.

Zeroing is just a form of initialization. If you initialize the memory right away (and completely!) with actual data, there's no need for additional zeroing.

Zeroing is something one should do if the allocated memory isn't completely initialized right away. In my experience, that's not only about someone finding exploits, but also about stability.

When people write code, most of the time they simply work with the assumption that an `int` contains a 0 by default and that code usually fails in unpredictable ways if it does not.

Accessing uninitalized memory is just always an error and having uninitalized memory laying around in your application has rarely any benefit. Either assign a value or zero it. Not doing either of those suggests the allocation isn't needed right there in the first place.

I think it was a notebook with aluminium frame, which would make grounding appropriate.

I had a Dell XPS 15 with aluminium frame once and discovered that it was grounded when I was in a hotel abroad with no ground on the outlets and – my wrist-rest got uncomfortable.

I then quickly fudged some wire from the notebook to a radiator, though.

I think there's place for both. When I build software installers for our embedded systems, the "frontend" tools production uses are written in a "sane" language, but the actual installation of software and configuration of the systems is done in shell. Because for running a bunch of apt/tar/cp/ln/sed commands to configure a Linux machine, it is the sane language.

I can only agree with this. In my experience, everybody coming from a lifetime with windows has to learn that a "working directory" has a very real and everyday meaning in Linux. Windows software just isn't designed that way because it usually has GUIs and "Open file" dialogs and doesn't use the cwd mostly. Most shortcuts even execute software in their installation directory (because it's most compatible with developers using relative paths for their assets and ignoring the existence of the cwd mechanic altogether, I guess?).

So for somebody just coming from Windows, this isn't just the wrong mindset for shell scripts, more dangerously it's a mindset they find appealing, because it matches their prior experience on Windows better.

I love that Arch has no extra configuration system. I'm building Debian images at work for like three years now and still don't really get how debconf works.

Also, the amount of patches, workarounds and custom configuration files in most packages and maintainer scripts is just wild. Coming from more than ten years of Arch, it took me a while to learn to check the debian packaging source if upstream doesn't match the behaviour on my system.