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

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.

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

Yes. In fact I even made a video about them: https://www.youtube.com/watch?v=kdbfPa1L6JQ (shameless self-plug, yes).

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.

1: https://aros.sourceforge.io/introduction/

Lers of Spoil: this is about a NES game ;-) Pretty cool still, especially if one's into reverse engineering.

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!

... one can always dream.

False alarm.

Very clever, and playable! Thanks.

Thanks for the replies! Will note the UE5 specificity.

> It's no wonder UE5 games have the reputation of being poorly optimized

Care to exemplify?

I find UE games to be not only the most optimized, but also capable of running everywhere. Take X-COM, which I can play on my 14 year old linux laptop with i915 excuse-for-a-gfx-card, whereas Unity stuff doesn't work here, and on my Windows gaming rig always makes everything red-hot without even approaching the quality and fidelity of UE games.

To me UE is like SolidWorks, whereas Unity is like FreeCAD... Which I guess is actually very close to what the differences are :-)

Or is this "reputation of being poorly optimized" only specific to UE version 5 (as compared to older versions of UE, perhaps)?

This being the UK... Perhaps better to establish The Office of Permission, then ban everything except requesting a permission form the new office... And thus create a whole permission economy, putting the `Great` back in Great Britain... /s

> No amount of expressive design will beat basic functionality.

...I am very afraid this will sacrifice a lot of (basic) functionality in the name of looking different.

May only hope there will be options to "tame it down".

> If I understand correctly, the critique here is that is that LLMs cannot generate new knowledge, and/or that they cannot remember it.

> The former is false, and the latter is kind of true -- the network does not update itself yet, unfortunately, but we work around it with careful manipulation of the context.

Any and all examples of where an LLM generated "new knowledge" will be greatly appreciated. And the quotes are because I'm willing to start with the lowest bar of what "new" and "knowledge" mean when combined.

...In due time he decomposes, leaving the skeleton which will last much much longer. Just like everybody else.

I think Jorge would appreciate that.

As a skeptic of the "organized" part of any "organized religion" I had and have deep respect for both Francis and Jean Paul II. May only keep fingers crossed the next choice will also be of that sort.

I remember coming across Pike about two decades ago (or more), as a young amateur developer... I couldn't understand why anyone would choose Pike.

And today I still can't.

Legacy projects?