drbig

Strikes a practical chord or two:

1. "You need to have taste (so: experience) to do DRY right". Same chunk of code more than once, so natural/expected behavior is to export to a helper... Aaaand the now introduced coupling is (too) often ignored, as in "no thought given whatsoever".

2. "Sometimes it's better to just leave it as is". 95% to 98% of "same chunk of code" in a number of places. The temptation to DRY is strong, yet the "numerically mere 2 to 5 pp" make the extracted helper an exercise in all manners of gymnastics. The only correct answer is: do not start.

(Own experience; your mileage may vary - if it does, feel free to comment back!)

> This time last year, it was still unclear if AI could develop their own free will or even have true fluid intelligence. Both of these questions are now clearly answered.

Answered how?

-> Do you, as a person, can tell me when your "model training phase" ended and when your "prompt answer with memory and internet access" phase started?

I'm asking the above only the "LLM are people or better!"... people. Bugs Bunny isn't real, and is only funny because actual people wrote and animated him that way.

Thank you for sharing!

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 :-)

And in case you are elsewhere... In Poland it's on the 26th, so hey buy some appropriate flowers or other gift while you have the time!

Great through-history write-up! Thank you.

> 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.

> The example is supposed to illuminate the limits of ppp or gdp adjustment.

... Yes, but that's like exemplifying the value of an actual slice of bread vs bitcoin to someone who is hungry.

Macroeconomic numbers may have an impact on the local - as in the individual scale - but that's neither the topic nor the thread.

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!).

Thanks for the nightmare fuel! ... These things should have a warning label.

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).