I like the following x86 assembly real-mode to protected-mode bootloader a lot:
(Taking a quick glance, it seems to be very well written and robust -- at least as far as "old-skool" (should run on ancient PC's back to 386's!) FAT, non-UEFI, x86 assembly bootloaders go...)
>"In the framekernel OS architecture, the entire OS resides in the same address space (like a monolithic kernel) and is required to be written in Rust. However, there's a twist---the kernel is partitioned in two halves: the privileged Framework (akin to a microkernel) and the unprivileged Services.
Only the privileged Framework is allowed to use unsafe features of Rust, while the unprivileged Services must be written exclusively in safe Rust."
An interesting and novel idea!
Use unsafe Rust for the higher privilege supervisor and safe Rust for everything else... that's definitely novel, and an interesting idea!
Observation: The code for the kernel could be divided into microkernel and non-microkernel parts and separated, and the microkernel itself could be written in unsafe Rust, and everything else could be written in safe Rust, and a system could arise where there might be more effective memory protection than putting both sets of code into the same memory, but at the expense of speed (using slower messages instead of direct calls)... but that of course may not be desirable...
I don't think I know of any language/compiler/loader that could specifically flag, say, the 4K (or other size) memory page that compiled code will be loaded into as say, having a specific privilege level (the compiler would need specific additional keywords for that), and a map of such pages might have to be made by the compiler during compile time, and set by the OS loader at (or directly after) load time... but Rust's (or another language's) 'safe' and 'unsafe' keywords (or equivalents) could conceivably be made to do that, with the compiler outputting an appropriate map file, and OS loader that knows how to set memory page permissions based on that map file...
Anyway, Asterinas looks very interesting and novel!
Wishing the Asterinas team the best of luck in their endeavor!
I personally like this article, its concepts, its charts and its graphs...
Observation: There probably is a market for documenting all of a business's processes and workflows (which business owner wouldn't want some really cool charts of all of their business processes?), and that should be able to done quickly and cheaply with Text-to-Image LLM's (NanoBanana, ?, ???). Well, if there's value on the one side, and the ability to deliver under cost and under budget on the other, then that's a value-to-cost asymmetry and subsequently a candidate for a scalable service business...
Yes. As someone else points out: the techniques for this exist (and have existed for decades). It was never worth it to fully pursuit it, especially for more messy human-heavy processes.
Now with AI you can get way more detailed (AI can interview humans, and you can do it in a format that doesn't feel like an interview - e.g by 'simply' having AI be a fly on the wall). AI can make sense of messy inputs and then you can present that to people who know the process, who can easily point out flaws. The flows/maps will not be perfect, but you can always get more detailed once you bump into the limitations of imperfection.
And absolutely do business leaders want maps like this. They often have no idea what exactly is happening in their org. Or they have a gut feel that there are massive inefficiencies, but they cannot get the insights into where they are because there are too many moving parts that do not effectively talk to each other (silos, politics, etc).
If we think about it, any WiFi adapter (in its most basic core functionality) is just the ability to send/receive radio at a specific frequency, and a modulation (send) and corresponding demodulation (receive) scheme on top of that.
If the modulation/demodulation can be handled by a DSP, FPGA or fast-enough CPU, then all that's really required to create a WiFi device is that and the radio component, and then of course, there are devices like "Cantennas" that could give increased range, although loss of omnidirectionality is the trade-off there...
Anyway, I never thought about the fact that different encoding methods are used relative to distance prior to reading this article (i.e., I learned something!) -- but it makes perfect sense now that I think about it!
It would be tremendously interesting, I think, to learn all of the Chemistry involved in carpet manufacturing, both historical and current-day, both for carpets which are manufactured domestically and those manufactured abroad (different regulatory frameworks = probable different and/or subtly different chemical processes)...
Now, that sounds really boring and potentially a waste of time, right?
Well, yes, and no, and yes!
Well it's complicated!
I would speculate (being horrendously undereducated on the subject!) that there probably exist a set of chemical processes which could create Carpets without any harmful environmental waste or residual chemicals which subsequently require disposal.
What these would be or could be, I as-of-yet do not know...
It's a subject that needs research... a lot of research... lots and lots of research!
But, while it might sound like a really boring, uninteresting, "there's nothing to see here" kind of goal, keep in mind this quote from the article:
>"Mohawk logged more than $3.4 billion in net sales. Shaw Industries reported $4.2 billion."
Yup, the global carpet market is worth... (wait for it!)... "Billion$"!
So -- an interesting problem for present and future Scientists/Chemists! Crack it (in whole or in part!) and your solution or partial solution could be worth Billion$!
I mean, I'd put that up against a Clay Millennium Prize for solving a complex Math problem, I'd put that against a Nobel Prize or Fields Medal or Dirac Medal or Feynman Prize!
Yup, solve The Carpet Chemistry Problem(tm) (let's give it a name!) -- and your share of Billion$ (as Carl Sagan would say!) could be yours! :-)
(I now will humbly submit this post for the obligatory yes-I-know-they-are-coming downvotes! :-) )
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 :)
(Taking a quick glance, it seems to be very well written and robust -- at least as far as "old-skool" (should run on ancient PC's back to 386's!) FAT, non-UEFI, x86 assembly bootloaders go...)
https://github.com/ZystemOS/pluto/tree/develop/src/bootloade...
reply