Now, two of those are header (.h) files, because in C the programmer typically splits units of code into headers (aka declarations), and body (aka implementation), unlike say, Pascal, where headers and implementations typically share the same file.
That is, there are really just two pieces of functionality here.
One is the file getting (uget.h, uget.c), and the other is the SSL interface to OpenSSL (ssl.h, ssl.c):
#ifdef ENABLE_SSL
#include <openssl/x509v3.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
[etc.]
Now those files (and the OpenSSL dependency) are only required only because the modern web predominantly uses the encrypted SSL protocol (i.e., https) -- compare to the earlier web which predominantly used unencrypted http, where all of that extra code is basically unnecessary (but of course, you lose encryption -- that's the trade-off).
As a commercial, production-ready tool, the author is quite right that you should probably use 'wget' or 'curl' instead, but as a teaching tool (or tool to be included on a minimal educational operating system), one where simplicity, understandability and minimal lines of code are virtuous, I believe that 'uget' is quite good, heck, I'd go as far as to say 'quite excellent' at achieving the smallest codebase and the greatest understandability for the purpose!
While other HN readers may disagree with me (and are free to do so!), I have to commend the author for a great minimal utility, and job well done!
>"Stage two was RLHF training on general chat prompts using a reward model to improve helpfulness. This worked. AlpacaEval scores jumped around 18.9 points on average compared to the fine-tuned checkpoints.
Then something broke. The RLHF stage, while improving chat quality, caused math benchmark scores to drop. GSM8K and DeepMind-Math both regressed."
Observation: Math (which when fully decomposed, results in Logic) is at the core of how computers (traditional/older, non-LLM, programming languages work. If an LLM gets Math training wrong at any stage for any reason, then, in my opinion, that should be viewed as something that needs to be fixed at a lower level, not a higher one; not a later training level...
I think it would be interesting exercise to train an LLM that only deals in simple Math, simple English, and only the ability to compute simple equations (+,-,x,/)... like, what's the absolute minimum in terms of text and layers necessary to train a model like that?
I think some interesting understandings could be potentially be had by experimentation like that...
I myself would love a pure (simplest, smallest possible)
Text-to-Math only LLM (TTMLLM, TTMSLM?)
, along with all of the necessary corpuses (which would ideally be as small as possible) and instructions necessary to train such an LLM...
Yes, that's about the shape of it, thanks! By controlling variables of the env (ie removing, fixing confounding factors), you can approach a more scientific process to development and testing, and make more rapid progress toward stability :)
>"Virtually all processors today have data parallel instructions (sometimes called SIMD) that can check several values at once.
[...]
The binary search checks one value at a time. However, recent processors can load and check more than one value at once. They have excellent memory-level parllelism. This suggest that instead of a binary search, we might want to try a quaternary search..."
First of all, brilliant observations! (Overall, a great article too!)
Yes, today's processors indeed have a parallelism which was unconceived of at the time the original Mathematicians, then-to-be Computer Scientists, conceived of Binary Search...
Now I myself wonder if these ideas might be extended to GPU's, that is, if the massively parallel execution capability of GPU's could be extended to search for data like Binary Search does, and what such an appropriately parallelized algorithm/data structure would look like... keep in mind, if we consider an updateable data structure, then that means that parts of it may need to be appropriately locked at the same time that multiple searches and updates are occurring simultaneously... so what data structure/algorithm would be the most efficient for a massively parallel scenario like that?
Now map that onto software. A junior developer needs three to five years to become a competent mid-level engineer. Five to eight years to become senior. Ten or more to become a principal or architect. That timeline can’t be compressed by throwing money at it. It can’t be compressed by AI either."
>"Single, reusable primitives play a disproportionately large aesthetic and practical role in mathematics, engineering, and even biology. Widely known classical examples include the NAND gate (and its dual, Peirce Arrow, logical NOR) for Boolean 0/1 logic [2, 12], the operational amplifier [13] for positive and negative feedback processes, and, more recently, the rectified linear unit (ReLU) ”ramp” activation function [14] in deep learning [15]. We also mention Wolfram’s single axiom [16], K,S combinators from combinatory logic [17, 18],
Interaction Combinators [19], and fuzzy versions of the Sheffer stroke [20]. Other wellknown examples are one-instruction set computers (OISC), e.g. SUBLEQ [21], Conway’s FRACTRAN [22] and the Rule 110 cellular automaton [16, 23]."
>"If AI makes every engineer 50% more productive, you don't get 50% more output. You get 50% more pull requests. 50% more documentation. 50% more design proposals. And someone, somewhere, still has to review all of it.
When two or three early adopters start generating more PRs than before, the team absorbs it. No big deal.
When everyone does it, review becomes the constraint.
The bottleneck doesn't vanish. It moves upstream, to the parts of the job that are irreducibly human: deciding what to build, defining "done," understanding the domain, making judgment calls about risk.
I've written about this pattern before:
the work didn't disappear, it moved.
What's new here is that it moved specifically into verification - and most teams haven't consciously staffed or structured for that yet.
[...]
The question isn't "how do we produce more code?" anymore. The question is "how do we verify more code?" And I don't think most teams have a real answer to that yet."
Excellent article!
It's a great question... how do we verify AI produced code? We could use AI to do that too, but then:
Who verifies the verifier?
Related:
Quis custodiet ipsos custodes? (Alternatively known as: "Who watches the watchmen?" / "Who oversees the overseers?" / "Who manages the managers?" / "Who guards the guardians?" / "Who reviews the reviewers?", etc., etc.):
I wholeheartedly disagree!
I claim, much to the contrary, that it is very, very intelligent!
See in terms of simplicity, in terms of understandability, in terms of the codebase, there are only 4 C source files here: https://github.com/troglobit/uget/tree/master/src .
Now, two of those are header (.h) files, because in C the programmer typically splits units of code into headers (aka declarations), and body (aka implementation), unlike say, Pascal, where headers and implementations typically share the same file.
That is, there are really just two pieces of functionality here.
One is the file getting (uget.h, uget.c), and the other is the SSL interface to OpenSSL (ssl.h, ssl.c):
#ifdef ENABLE_SSL
#include <openssl/x509v3.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
[etc.]
Now those files (and the OpenSSL dependency) are only required only because the modern web predominantly uses the encrypted SSL protocol (i.e., https) -- compare to the earlier web which predominantly used unencrypted http, where all of that extra code is basically unnecessary (but of course, you lose encryption -- that's the trade-off).
As a commercial, production-ready tool, the author is quite right that you should probably use 'wget' or 'curl' instead, but as a teaching tool (or tool to be included on a minimal educational operating system), one where simplicity, understandability and minimal lines of code are virtuous, I believe that 'uget' is quite good, heck, I'd go as far as to say 'quite excellent' at achieving the smallest codebase and the greatest understandability for the purpose!
While other HN readers may disagree with me (and are free to do so!), I have to commend the author for a great minimal utility, and job well done!
Well done, uget author, well done!
(Related: https://suckless.org/ https://en.wikipedia.org/wiki/Suckless.org)
reply