Watching your own hand movements through your phone camera is a good demonstration of this. Set 60 Hz video mode, and the latency is probably less than 30 ms - but still extremely obvious.
it's quite a lot more than 30ms, as phone cameras do some real heavy-weight image processing to compensate for their tiny size, I'm talking neural networks and such. the throughput might be 60fps when it's all conveyor-ed but the latency sure isn't
You're right. Looks like it's more around 90 ms, at least for my iPhone 12 Mini. Test setup was taking a photo of the iPhone 12 Mini watching an incrementing counter on a 50 Hz CRT.
I had to read your comment a couple of times to understand it. I assume you are saying that "/bin/ls" is the "most ordinary command imaginable"? I think your original quote is saying most ordinary when running ffmpeg, which has a famously complex command line interface.
This question is answered by the post? There is reportedly actually no way of stopping it happen. Perhaps the poster had a brain fart while typing it. Maybe they speak a different dialect of English from you.
Many kinds of double negative are acceptable in many English dialects, and are interpreted as emphasis. The negatives add, rather than multiply. (Though I admit I myself don't speak such a dialect, hence the equivocation.)
He's got subscribers. Maybe the attitude is one he's found plays well with them.
I find it quite refreshing in some ways. Lots of people, when they start complaining about this or that aspect of this AI stuff, are wont to add in a little disclaimer that, despite all of the above, they actually really like AI and use it all the time. I assume this is to avoid the scenario of a bunch of pragmatic builders turning up and calmly shipping nuance in the comments (or whatever you call it these days when you get brigaded by a pile of angry keyboard warriors with chips on their shoulder) - and it sure is tiring having to wade through the equivocation.
That's a criticism that'd be hard to level at Zitron! Say what you like about the man, but he's unafraid to appear to take a side.
> Maybe the attitude is one he's found plays well with them.
Kind of a self-fulfilling prophecy.
What's not a problem, by the way. That's why people always recommend content creators to be themselves. If they try to be somebody else, they find their public is already busy following other people.
It can affect shell subprocess startup time as well, which, depending on your setup and the tools you use, might be worth optimising for.
I don't remember when I did it, but it looks like I must have gone through this at some point (maybe due to using GNU Make a lot? Or perhaps it was some other tool) - my zsh setup does a bunch of autocomplete setup only in the interactive case, and it seems to help a bit with startup time, at least on macOS:
% for i in {1..5}; do /usr/bin/time zsh -i -c exit; done # zsh in interactive mode
0.05 real 0.03 user 0.02 sys
0.02 real 0.01 user 0.01 sys
0.02 real 0.01 user 0.00 sys
0.02 real 0.01 user 0.00 sys
0.02 real 0.01 user 0.00 sys
% for i in {1..5}; do /usr/bin/time zsh -c exit; done # zsh in non-interactive mode
0.01 real 0.00 user 0.01 sys
0.01 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
For the interactive case, I don't really mind (within limits - the worst case, on macOS after a reboot, takes several seconds, and that's tedious). I also start new interactive terminal sessions fairly rarely.
Depends on the system. Each thing did its own thing at the time.
8-bit Acorn systems did work kind of roughly as you describe. Handwaving a bit: there was no shell, but there was an OS call roughly corresponding to system(3), and add-on ROMs (e.g., the driver-type ROM that came with the disk interface) could extend the default (fairly limited) set of available commands.
With no shell, there was no standard UI for typing in a command and having it run, but this OS call was one of the main ways to interact with the OS, so the inbuilt BASIC made it very easy to do. For a lot of the stuff you'd use the DOS prompt for in MS-DOS, you'd do the equivalent from the BASIC prompt on the Acorn systems. In place of batch files, there were a couple of options, and one of them was that you'd write a BASIC program that contained the commands you wanted executed, in order.
AI multiplied by Linux overcommit. What times we live in!
(My own view: 10.8 GB is nothing these days. Your sprintf buffers are probably larger than that. (And if they aren't: they should be. That, or you should start using snprintf...))
If you pass NULL as the destination pointer, it doesn't write any string. If you combine this with %n at the end of the format string, you can get the exact length that the output string would be. Then you allocate that, then you print again, into the actual destination buffer this time.
If anything I just got entrenched in my opinion. The second best option, maybe, would be to not accept any destination pointers and have the default and only possible behavior just like what you describe.
I agree. I tend to use the gnu "asprintf" which simply returns a properly allocated char buffer with the formatted string in it. And on platforms that don't feature asprintf (windows) you can build your own using sprintf!
Do you think we could convince hypothetical AGIs to buy NFTs? Since they're not embodied (or at least not limited to one body), it might be the only way they could really properly indulge in fine art speculation.
"An AI can't smell a painting, but it can smell an NFT"
This original author is mentioned in the second sentence of the linked article, and then again in the third sentence, along with a link to the original story.
reply