> That is one of the great ironies of modern Open Source. The distributed version control system won, and then the world standardized on one enormous centralized service for hosting it.
Cycles everywhere indeed. Perhaps we should ->
> GitHub wrote a remarkable chapter of Open Source, and if that chapter is ending, the next one should learn from it and also from what came before.
Indeed! Try to learn from the inevitable iterations to make the next instance at least that slightly better.
... Where the stuff meets the metastuff it seems all works under very similar forces.
My thinking is step-by-step - it works on the individual level, and it scales up.
Day to day is step by step and a step today funds the step tomorrow.
As much as the notion of "Purchasing Power" is <macro>economic, thus perhaps having a greater chance of being related to reality, I've been wondering if - and how - could these long-term measures account for greater diversity and "scale" of "things money can buy".
Nowadays if you're properly rich you can buy a seat on a sub-orbital flight. This wasn't an option in '00, no matter how rich you were.
On the other end of the scale, for basic things a (really) good quality loaf of bread will always be cheaper in Poland than say up north from Oslo, Norway; whereas a USA-designed made-in-China laptop pretty much never did scale with the rest of the "CPI basket"...
Point being: we sure do have numbers - what they really mean in practice is vague at best.
The most interesting is the realization that if the LLM's input is only the output of a professional (human), then by definition the LLM cannot mimic the process the (human) professional applied to get from whatever input they had to produce the output.
In other words an LLM can spit out a plausible "output of X", however it cannot encode the process that lead X to transform their inputs into their output.
Pro-tip I only realized later when making much bigger ones: it's worth to pay attention to the "grain", that is the orientation of the corrugations.
Find it hard to describe, but they should go "perpendicular to the axis of load". E.g. if you have an upright wall the top and bottom edge should show the "waves"; your base (and top) plate should have the "waves" showing on the left and right edges.
Took me some time to get used to thinking about it and it makes cutting out individual pieces (a lot) more involved, but the payoff is real for big units (big as in 50 x 30 x 40 cm; no longer can you move it one-handed!).
I do a lot of free-standing "holders" from industrial (5 ply) cardboard and hot glue. Surprisingly sturdy! Made a video about this too: https://youtu.be/s-aNW3h15K0 - all of these are still in use and I made more & more complex ones too.
Seems the calculator is designed for a "collection of boxes", which I guess is a start, but when I hear "organizer" a collection of separate boxes ain't what I want. The most significant factor of making one's own is that it's 105% customized to the need, no more no less. That means usually a lot of thought between "target place bounding box" vs "bounding boxes of things the holder shall hold".
For "organize a drawer, quickly!" I got myself a couple of sets of "modular" boxes - they have little tabs on their sides so one can snap them together like lego.
An approach very close to one I've been thinking about lately.
My three cents: compact the journal when its size exceeds the actual data size.
With thresholds or other knobs; with the point being the initial load time should be directly proportional to the amount of actual data. Everything else/older is a backup.
As a sysadmin I'm very familiar with `makepkg`, its config file and the fact that sooner or later one will need both `clang` and `gcc`, because they're equivalent only in theory ;-)
But as I maintain only a library of pre-build(-once) software, rather than being an actual package maintainer - surely there is the whole other side that I normally do not see, much less touch.
Having said that, I'm all for better tooling - it's just that the project doesn't even hint, much less describe, the actual benefits for the people who will (sooner or later? have to?) use it.
And, unfortunately, I've been doing this for long enough to approach _any_ increase in complexity with at least anxiety, if not outright sadness (at "you could have spent that time/money on more _useful_ work", usually).
> The ALPM project arose from the need for more clearly specifying the interfaces, as well as providing bindings and tools in a memory-safe programming language.
Whose need?
As an admin and a user I kindly ask: why? what for?
`pacman` which has been and is working fine for over two decades on multiple architectures is two packages - and that includes mirror finder.
This project seems like a CS exercise: funded by a grant, designed by committee, producing a lot of complex artifacts (already over a dozen packages)... and it's unclear if the lot of that can even install a single package.
Because doing all the driving, decoding and serial comms pretty much required a computer anyway, so the most sensible approach was to use what they already had in supply.
Also, find it very difficult to find this newsworthy - sorta like being amazed that modern PCs can run MS-DOS.
As someone who grew up with Amiga... I find it amazing these boards still keep coming (X1000, X5000... anyone?) - they have always been insanely expensive for specs that are decade(s) old, all in the name of... really no idea what beyond "we can".
Or in other words: I wonder what if all that time, money and effort went into say AROS[1] and/or emulation. I can imagine still using AmIRC and HippoPlayer if I could run them as any other software on Linux.
The point is that we should acknowledged those "cheats" came with their reasons and that they did improve performance etc. But, they also did come with a cost (Meltdown, Spectre anyone?) and fundamentally introduced _complexities_, which at today's level of manufacturing and end of Moore's law may not be the best tradeoffs.
I'm just expressing the general sentiment of distaste for piling stuff upon stuff and holding it with a duct-tape, without ever stepping back and looking at what we have, or at least should have, learnt and where we are today in the technological stack.
Instruction pipelining and this is exactly why I wish we still have the time to go back to "it is exactly as it is", think the 6502 or any architecture that does not pretend/map/table/proxy/ringaway anything.
That, but a hell lot of it with fast interconnect!
This is inspiring. Cooking is this sort of an activity that is simple enough to not be overwhelming but also complex enough to be very interesting.
Both in practice and in modelling :-)