Having a search and having a functional search are two very different things though. To this day, the search on many sites is so bad that it's actually better to use a search engine and scope by site rather than use the site search.
While I see the point the author is trying to make, I'm not really sure I agree. Most users don't even read error messages, never mind logs. At best, logs are something they need for compliance, for most, the concept doesn't exist at all. I do agree that the logs should help you understand what went wrong and why, but in that regard the principle is the same for both sysadmins and developers and I don't really see the difference?
In my sysadmin work I curse every developer who makes me fire up strace, tcpdump, procmon, Wireshark, etc, because they couldn't be bothered to actually say what file couldn't be found, what TCP connection failed to be established. etc.
I get the impression that often it isn't laziness but the concept that error details leak information to an attacker and are therefore a vulnerability.
I disagree with this view, but it definitely exists.
Sysadmins needs logs that tell them what action they can do fix it. Developers need logs that tell them what a system is doing.
Generally a sysadmin needs to know "is there an action I can do to correct this" where as a dev has the power to alter source code and thus needs to know what and where the system is doing things.
> Most users don't even read error messages, never mind logs.
Yes, see all the questions on StackOverflow with people posting their error message without reading it, like “I got an error that says ‘fail! please install package xyz!’, what should I do?!?”.
I think that's being very generous. If you've ever been in tech support, you'll be amazed at how often you'll be asked what to do when it tells me to do X.
If they don't know how to do X, then they should be able to look up how to do X. If it's something like install 3rd party library, then that's not the first party's responsibility. Especially OSS for different arch/distros. They are all different. Look up the 3rd party's repo and figure it out.
I've worked in tech support. I get that 25-50% of the cases appear to be "read the docs to me." But the majority of those is because docs are poorly written, are overwhelming for new users, or they don't understand them and won't admit that directly.
on friday i got 2 calls saying "my phone is no longer showing me my emails, please fix" when the error message they received was roughly "please reenter your password to continue using outlook".
on wednesday i got a call saying "the CRM wont let me input this note, please fix" when the error message was "you have included an invalid character, '□' found in description. remove invalid characters and resubmit".
> but in that regard the principle is the same for both sysadmins and developers and I don't really see the difference?
No, it's very different: developers generally want to know about things they control, so they want detailed debugging info about a program's internal state that could have caused a malfunction. Sysadmins don't care about that (they're fine with coalescing all the errors that developers care about under a general "internal error"), and they care about what in the program environment could have triggered the bug, so that they may entirely avoid it or at least deploy workarounds to sidestep the bug.
> Most users don't even read error messages, never mind logs.
They don't need to. The log message is so helpdesk have something actionable, or so it can be copy pasted into google to find people with similar problem maybe having solution.
Oddly enough though, my journey into computers was greatly assisted by my curiosity at random log files that were being dumped to my desktop constantly.
In all honesty, if you scoped this well, one of the big players in the LLM space could definitely host a big marketing event on this spin. Get together a bunch of well known industry folks, have them vibe code a working <thing> in a given time constraint, presentations and prizes, lots of marketing.
The final part is a long solved problem, pass in mock tokens, pass all requests through a proxy, only swap in the real tokens if the request matches whatever filtering requirements you have.
Just because tests pass does not mean that they're testing the right thing to begin with. Reviewing tests is as important, if not even more important than reviewing code.
This is like asking why someone built a text editor as a hobby project when Microsoft Word exists. There is value in experimentation and play, in trying to understand things from first principles. It would often be faster to just ask others, but if everyone did that, we would miss out on a lot of innovation.
If you're looking at it solely from perspective of "value" in experimentation and play, then that value mostly comes from expert level understanding of the ingredients and the process. To not ask for guidance from people right near you who know far more than you just seems like egotism.
Who has a better chance of developing an innovative omelette dish? Thomas Keller, or someone who can't make scrambled eggs without setting off the smoke alarm?
The point is, experts can bootstrap you so you can progress quicker than you can on your own. This is why mentors exist, and is the basis of Bloom's 2 sigma study.
It really depends on what your goal is. Some people just like "play." For example, I am terrible at video games--when somebody tells me that they "beat" a game, this usually seems unfathomable to me. The last video game I finished was Riven, back when Riven was new. I still do play now and then. I play Skyrim poorly. I like walking around and discovering things in the Skyrim world. If my goal had been to beat the game in some way, then I would be going about it terribly. But that's not my goal. It does not have to be because egotism.
Firstly, fear and honor are far from being the same thing. Second, we already have this in our society today via smartphones and things have not changed for the better. If anything, society is more torn than ever.
It is incredibly fast, on that I agree, but even simple queries I tried got very inaccurate answers. Which makes sense, it's essentially a trade off of how much time you give it to "think", but if it's fast to the point where it has no accuracy, I'm not sure I see the appeal.
the hardwired model is Llama 3.1 8B, which is a lightweight model from two years ago. Unlike other models, it doesn't use "reasoning:" the time between question and answer is spent predicting the next tokens. It doesn't run faster because it uses less time to "think," It runs faster because its weights are hardwired into the chip rather than loaded from memory. A larger model running on a larger hardwired chip would run about as fast and get far more accurate results.
That's what this proof of concept shows
If it's incredibly fast at a 2022 state of the art level of accuracy, then surely it's only a matter of time until it's incredibly fast at a 2026 level of accuracy.
I think it might be pretty good for translation. Especially when fed with small chunks of the content at a time so it doesn't lose track on longer texts.
reply