theon144
In an environment where providers are almost entirely interchangeable and tiniest of perceived edges (because there's still no benchmark unambiguously judging which model is "better") make or break user retention, I just don't see how it's not ludicrous on its face that any LLM provider would be incentivized to give unreliable answers at some high-enough probability.
I don't doubt the boards could've been sold cheaper, but they clearly were doing something right given how much it changed the hobbyist landscape
I'm not saying it's not a real or an easy problem, just that I wonder if it truly is the reason Arduino is "bad"
The questions were pretty much unlike anything I've ever asked an LLM though, is this how people use LLMs nowadays?
As for the article, I'm also a bit confused because I'm really not sure whether people write that sort of code at the beginning "very commonly" - match and `ok_or` to handle None by turning them into proper Errors is one of the first things you learn in Rust.
Cool, sounds like an organization that is heavily incentivized to make their communication hard to intercept and eavesdrop on.
(I say virtually, because even constant time crypto isn't bulletproof - GoFetch, a recent Apple M-series CPU vulnerability inadvertently broke the "constant" part because of a quirk of the prefetcher. Side channels are hard, no need to make it harder.)
I'm just wondering, why hasn't a SBC-based alternative popped up yet? I think the project is/was awesome, I actually did maintain 2 public PirateBoxen for a while. Is it a simple lack of interest? The fact LibraryBox tried to pick up after PirateBox kind of suggests otherwise. I feel like it's actually easier now than ever to build a Libary/PirateBox-like project (although I do imagine an on-board network card probably has way worse performance than even those old portable routers).
I've even tried to put together an image like that in the past but I couldn't find a reproducible solution for creating raspi images so that put me off, maybe it's time to give it another try...
Prusa (the 3d printer maker) seems to think otherwise! https://github.com/prusa3d/Prusa-Firmware-Buddy/releases/tag...
For that matter, the file types I care about are unfortunately misdetected by Magika (which is also an important point - the `file` command at least gives up and says "data" when it doesn't know, whereas the Magika demo gives a confidently wrong answer).
I don't want to criticize the release because it's not meant to be a production-ready piece of software, and I'm sure the current 116 types isn't a hard limit, but I do understand the parent comment's contention.
...why?
Seriously, why on earth? I don't follow this train of thought at all; if they demonstrate proficiency within the scope of the position, why does it matter if they also happen to know other technologies?
"Oh, Alice? Yeah, she was a great candidate, unfortunately she also had experience in Vue, so there's nothing we could do. We decided to hire Bob, who has 3 years less experience with React, but fortunately that's the only stack he's ever heard of."
If anything, it's a sign the person is interested in learning, most great devs I've met were not proficient only with a single technology. This sounds completely alien to me.
Well, at least the author is responsible and owns up to being one of the cheaf reasons sites like these die :)
This is horribly misleading; most of these lines of code are drivers, which this patchset doesn't even concern.
It's still a massive change that only a handful of developers will ever be able to review in entirety - a fact to which the size of the project is completely irrelevant - if anything, actually, it urges even more caution, given the implied complexity. Which I believe was (at least in part) parent comment's point - given the importance and ubiquity of the Linux kernel, this may be concerning.
That said, I am very confident in the structures put in place by the kernel devs, their competence and the necessity for such a change - but trivializing a 100k LoC patchset because the project it's intended to land in is even more colossally complex isn't how I'd choose my approach.
It's not really about the improvements in technology, rather than the inherent limits in its use cases - there's only so many games and media experiences that truly benefit from VR, and as a rule, they're designed for VR from the beginning.
Without a doubt, VR is a huge leap and a drastically different and exciting medium, but that doesn't mean it's ever going to be more than gimmick worth a couple evenings' entertainment to most people.
Now there is an obvious need for quality control of accepted sources in a project like Wikipedia, the process was transparent, and its conclusion is up for debate (hence being conducted through a Request for Comments). What would you propose instead?
Not to mention the whole "Windows Forms, WinUI3, Win32 and WPF" mess.
According to other comments in this thread, this just freezes when switching apps, and fails. I'm not too surprised, given that the feature (at least on Android) is meant as a security measure (i.e. most of the banking and 2FA apps use it to some extent).
To me, it read like it just didn't work, not that he didn't try or look it up.
>* Complains about the size, when it's comically obvious what the size is from the constant advertising.
It's still a valid criticism, no? The digital pen/e-ink combo gives you way less feedback, hence precision, hence density of writing in a given area. I'm not just speculating, I've tried out a Remarkable 2 my friend got, and that was my impression - nearly like paper, but I still had to focus more and write slightly bigger letters for it to be legible.
Isn't it ironic that this one joke site actually helps solve one of the most commonly quoted issues people have with NFTs, i.e. that "you only own an URL which can be taken down at any time", by providing means of wide-scale decentralized P2P storage?
The article is literally about this scenario, which is why I'm also confused. Yes, `/usr/bin/env python` is a bad idea IF your script depends on a certain version, but that's exactly what the author doesn't need!
Progressively "drilling down" is super low-hanging fruit with regards to tag-based organization, it's seriously neglected.
Strange timing though; according to the liquidsoap slack channel, the "hopefully last beta" of 2.0.0 was released just two weeks ago, and it has some great improvements, like "first-class support of video" (which is huge, it's not just video multiplexing or these 24/7 YouTube streams, but some advanced real-time stuff[1] was already possible), and "Enhanced language features making the script language a fully-featured language" which sort of was a headache in my experience - it was in this "Greenspun's moratorium"[2] where you could do a lot of things, but some of it was really awkward, and there were walls in unexpected places.
So, when I saw this post, I thought 2.0.0 was out, but it seems it's right around the corner still? Anyway, I'm really looking forward to it, and I recommend anyone interested to follow the project!
[1]: https://www.liquidsoap.info/doc-1.4.4/video.html#detailed-ex... [2]: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
However, that also means disabling protection against cryptominers and a host of other nasty stuff, so it's not really a great solution IMHO.