Another thing is the stdlib integration of goroutines. We see this in Python where various generations of paradigms kind-of coexist. Golang built their goroutines into the heart of the stdlib which puts it IMHO in a special position.
This is the reason why I implemented rather dumb but individual, hand-crafted captchas for my own websites in the past. Things like input fields which must be left empty, silly multiple choice questions only humans could properly answer at that time, etc.
I have seen communities to implement their own captchas with domain knowledge. For instance, math/STEM people showing captchas with rather easy calculus tasks (such as solving a definite integral). This can be fun to solve and as a human you feel valued. It is this handmade feeling of the "old internet".
The problem with self-made captchas is that even them are rather easy to solve nowadays with LLMs and thelike. Therefore I don't believe that decentralized individualized captchas are the solution as they tend to be rather simple.
The issue is that AI bots can answer pretty much any captcha that isn't ridiculously obtuse. Your homemade captcha can be solved with an LLM, but so can the latest version of Recaptcha or whatever.
But I feel that there may be some other tools here. Spammers in general tend to be fairly predictable in their behaviour, so tracking that could help. If a member is including links to a third party site in dozens of messages, that should be a pretty big hint that their intentions are questionable. If they blast through the registration page in seconds, same thing.
Personally, I've not seen more than a single spammer on the forum I run for the last 6 months or so, so I'm still optimistic that most don't bother unless it's easy to attack and worth their time.
It's unfair to compare an idling deep sleep device with a cold boot.
However, there is a shortcut: Just don't boot a full OS (thinking of custom firmware which boots in fractions of seconds, standard in the Microcontroller world). Or boot an optimized Linux user space. I am confident with a bit fiddling one can bring down a standard SBC Linux to a few seconds from cold to ready.
Functional comparisons among devices within a category are always fair. Pointing out a device’s perceived shortcomings is not an attack on the people that made it. One crucial role designers play (ideally) in product development is seeking out honest feedback, filtering it, and figuring out if that feedback can help make the product better for end users. The FOSS landscape needs a lot more of that.
> Functional comparisons among devices within a category are always fair
When they have the same prerequisites, yes.
But then you need to count in the time the iPhone needs to boot as well, which will probably mean you are at a similar range.
No, because the criteria here is state transition from not-in-use/power saving to in-use/"on". The Pi Zero has no meaningful sleep state, as I lamented above, thus the only valid "off-on" state transition for the Optocam Zero is a full boot. Sure, if you were to leave it on in your bag then there's no boot time, but then you're limited to 70-80 minutes of runtime. Then you get "instant-on", but you're limited to the photos you can take within an hour off the charger, which also renders it useless as a camera, and compares unfavorably to the iPhone . If it had a sleep state then we could compare apples to apples. Since the iPhone's default "off" state is sleep, that's what counts for "turning it on".
You don’t even need to technically justify the comparison. Apples and oranges can be compared if you’re discussing how useful each is for a particular purpose or in a particular context. Oranges are nice because the skin proffers protection from soil and bumps during travel. Apples are nice because you don’t have to peel them or deal with sections — you just bite hunks off of it. If you’re not throwing it in your bag, the shortcomings of the Apple might be totally irrelevant. If you’re going on a picnic, the convenience of the Apple might be less important. Similarly, it wouldn’t make much sense to abstractly compare whether moving trucks or motorcycles are better. It makes complete sense to say one has better cargo capacity, and one is way more fun to operate.
In other terms: The "recent" success of AI is mostly the commercialization of industrial scale stochastic plagiarism. Compare it to piracy, done by individuals for the benefit of themselves and their friends. If they ever thought about selling their stolen goods, what could they have done for economy!
Zig 0.16.0 was the big, recent async update. Go channels are handled as std.Io.Queue, the select keyword is handled with std.Io.Select, and goroutines are handled with std.Io.async and std.Io.concurrent. The difference between async and concurrent calls are essentially: async calls may be called concurrently, or they may not (the execution of the async function is not dependent on the caller continuing to execute - like reading a set of files), and concurrent must execute concurrently (the execution of the concurrent function depends on the caller continuing to execute - like a client+server interaction, and will crash if the environment cannot spawn concurrent processes).
The fully userspace implementation is a bit more syntactically clunky than the concurrency primitives in Go, but it is very similar semantically.
I remember having read somewhere that zig now requires to pass the Io argument around, which one can interpret again as "colored functions". IMHO it is a missed opportunity not to implement a more polished syntax and make a message passing paradigm a "first class citizen" in zig. Anyway, I like the fact that zig is iteratively "improved" and not a virtually "dead" language compared to golang :-)
This is in fact useful for people who demand you to print out and sign contracts. Did so many times in the past, using some ghostscript+imagemagick scripting to avoid the cargo culturing.
Lyapunov sounds a good tool but the README reads so LLM-generated and with little love that I am not bothered to look further into whether this is solid or not.
