I hope next up is the performance and bloat that the LLMs can try and improve.
Especially on perf side I would wager LLMs can go from meat sacks what ever works to how do I solve this with best available algorithm and architecture (that also follows some best practises).
And while at it, ability to mount the resulting archives at some virtual root in nginx|apache. E.g. serve site-archive.extension at /somepath/site. And standalone simple webserver that can take one or more archives from command line and servers them.
Although PG isn't wrong here, people also have larger wrists nowadays that are able to comfortably support larger watches compared to ~50 years a go, never mind at the 1940s or 1950s.
This is awesome! I wish Omega, Zenith, Seiko and other watch manufacturers would do the same and publish their historic catalogs online! And auto manufacturers, and really everyone who is in the kind of business where catalogs like this exists.
I think models will also become snapshots or time capsules (with obvious and non-obvious biases) that archaeologists of tomorrow (like in 500 years) will use to understand us and the change in society (e.g. how the models themselves change over timefrom encyclopaedic standpoint).
What is the current hypothesis on if the context windows would be substantially larger, what would this enable LLMs to do that is beyond capabilities of current models (other than the obvious the
now getting forgetful/confused when you’ve exhausted the context)?
Essentially you're paying human to be a proxy between the requirements, LLM and codebase. Some people I'm talking to lament having to pay top dollar to their junior (and other kinds I'm sure) devs for this, but I think this is and will be the new reality and new normal. And instead we should start thinking how to make best of it, and how to help maximize success for these devs.
Few decades down the road though we are likely to be viewing this current situation similar to how we're looking at 'human computers'[0] of yesteryear.
This should have been named NOTjson-somethingv5. Or similar. Now it is far from obvious for the uninitiated that this might not be the 'latest' version of JSON. And then they end up using this incompatible format by accident, when in all likelihood standard JSON would serve equally well or better in 95% of the use cases.
But what about the heat sinks / fan when you mount the m2 on top? Especially /w Pi 5, to get more perf out of it, it presumably should have a sizeable heat sink complete with the fan?
Rolls sleeves up to start working on custom GPT and training my own LLM to offer service to produce llms.txt for a website by letting them process the website... ;-)
You're probably not wrong. But I think we should recognize that what is humanity is rather fluid. If you were to talk to the 15th century clergymen, I think they would tell the horrors of printing press and how it has/will break humanity. And they wouldn't be wrong either. Humanity evolves, and, well, that's it. And overall, hopefully, and this is where we hopefully can effect positive change, we can steer the change to more humane, and moral direction.
Sir. You Win teh Internets today. This has been my gripe with HA for the longest time. That YAML / GUI-only / etc. approach is just atrocious.
Unfortunately it works well enough, and there are little or no alternatives to it as far as I can tell. Were there a reasonable alternative, with a configuration as an actual code (YAML isn't), I would dump HA in a heartbeat. I mean I could even live without the GUI - just configuration as a code, and stable support for Zigbee (and BLE etc devices). But then again HA mostly works. And if it works, then...shrug.
My use case is mostly to be able to 1) monitor/understand our electricity consumption, 2) be able to turn off all/selected electrical devices when leaving house etc., 3) automatically lower/raise outside shutters based on weather/where sun is(!) to keep house cooler, 4) and as a bonus, have leak detectors send me a text if there is a leak. My setup is some 30 zigbee smart switches / sockets, couple of IKEA badring leak sensors, solar inverter and something zigbee in main electric panel to get total electric consumption. And five door/window sensors (that aren't really used for anything, but you know how one goes down the rabbit hole with these things...).
How I've made it somewhat manageable is that I run it in a following manner (first in Pi5, now in N100 -- no difference between those observed regarding HA):
- have /opt/homeassistant/config mounted to zram
- on boot unpack /opt/homeassistant/backup/latest.tar.zst -> /opt/homeassistant/config
- run HA from docker (where /opt/homeassistant/config is now on zram)
- cron will make a backup of /opt/homeassistant/config weekly (or I can run backup manually if I've made changes/addedd devices) and then these are backed up 'offsite'.
So now whenever HA goes bonkers, or more likely I've messed something up with it, end result being the same, I simply roll back to some earlier known good configuration. Docker is wonderful in this regard. Really, I don't know how else people live with the HA, other than backing up their entire config, and then re-installing.
I wholeheartedly agree (that first ask from ChatGPT, then double check with whatever, and that Google results have become junk - mostly). Alas, I can totally see how AI companies will monetize this by allowing advertisers to influence the answers. And not in a add-in-a-sidebar fashion, but baking the advertisers product etc. into the answers. Personally, I find this somewhat disturbing.
Indeed, I think this is a key area where regulation is needed. If answer from AI is influenced by 'something unexpected' - what ever that might be, then it has to be clearly highlighted in the answer.
On stock rPi5 running this takes > 3 seconds. Three seconds to render 370 x 370, 8-bit/color RGBA image to ASCII on a 2.4GHz CPU. And this is my lead-in to rant about neofetch, which takes about 0.2 seconds to run on the same Pi (see below), which would also be the time it would slow down opening a shell should I put neofetch into my .profile. Lastly, it takes cat to cat output of neofetch to /dev/null about ~0.01 seconds, which also is the time that neofetch should probably take to run (and really, this tool too).
$ time ascii-silhouettify -i neofetch-1.png > /dev/null
real 0m1.817s
user 0m3.541s
sys 0m0.273s
$ time neofetch > out.txt
real 0m0.192s
user 0m0.118s
sys 0m0.079s
$ time cat out.txt > time
real 0m0.001s
user 0m0.001s
sys 0m0.000s
I wish. But 'regulatory compliance'. And 'we might need them' - just not sure for what - but we'll try another data analyst next quarter. Thankfully because of the GDPR (and maybe other reasons) there is a healthy pressure to also cleanse us from the logs we've collected.
That said, I agree, based on my trials (and mostly errors), Splunk seems one of the better ones. Not considering the cost anyway. My trouble is that I am not a data analyst, but I get asked more than I would like about these things.
Especially on perf side I would wager LLMs can go from meat sacks what ever works to how do I solve this with best available algorithm and architecture (that also follows some best practises).