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.
Running it on my home-server via pip (no containers for me, thanks) I do not try the "kind-of-firmware approach, just different zfs volumes, with auto-snapshots and backups for bin (python venv), data and config. Mostly I have had issues upgrading HA but still even with my config at hand, written in org-mode and tangle-ed anyway to be less of a hell and to embed docs/references in the YAML hell, the main issue came from integrations only configurable from the WebUI. In most case it's just a matter of remove the configured part from the running config, add the integration from the WebUI, add back the config, reload etc. But it's still a PAINFUL process. Less hard than configuring via NixOS, but still hard.
As you rightly say HA works well enough and have less issues than OpenHAB, but as long as something less yaml-illish and webui-tied appear I'll switch instantaneously. My setup have probably far less devices than you, bus some have a gazillion of sensors (i.e. my main battery inverter a Victron MultiPlus with ECV charging station have at least 1248 lines of yaml, NOT counting the template code for many sensors usages) while it could be a simple python data structure of 1/5 of the size. My main usage is just monitoring and a bit of automation to maximize self-consumption like piloting hot water heater, running A/C etc, videosurveillance and co are managed separately.
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
Surely the use case for this tool is to precompile your image into ASCII and then just output that on every shell start up, right? There’s no reason to convert the image every time.
I would assume that performance wasn't the prime concern, but rather the accuracy/appearance of the generated image. Most people aren't putting this in their shell startup, just as most people aren't putting an ffmpeg encode command in their shell startup.
And I would assume neofetch is relatively slow because getting some of the system information is relatively slow. e.g. to get the GPU name it does "lspci -mm":
% time lspci -mm >/dev/null
lspci -mm > /dev/null 0.03s user 0.03s system 2% cpu 2.993 total
% time lspci -mm >/dev/null
lspci -mm > /dev/null 0.03s user 0.01s system 76% cpu 0.053 total
Guess it's faster that second time due to kernel cache or whatnot, but 50ms is still fairly slow. And that's only the GPU.
The algorithm involved is actually very hefty: for each cell of a 9px by 15px grid over the image, compare each pixel of the cell to its equivalent pixel in each of the 95 ascii characters. To solve for optimal grid alignment, it repeats this for each of the 9x15 possible positionings of the image under the grid.
Am I the only one that feels that EVERYTHING is wrong in this ELK, Splunk, etc. Grafana world? The user interfaces that these monstrosities present us with are barely useable, everyone has their own query language, they force us to install their own agents own our hosts and servers, when I upload logs, many can't even take random JSON logs and input them in a structured way without defining pipeline rules or what now. And did I say that the Logstashes and Promtails and Vectors and what not pipeline tools with their Grok etc. filters feel like somebody wanted to really make busywork cool.
I am happy that in my day to day work I can dump my mostly Linux logs to rsyslog, and eventually forward them to S3 glacier for a few years.
So I am guessing the question I am asking is that what in the world are you doing with these observability or SIEM platforms and is anyone actually deriving some REAL value from using them?
Genuine question: does your job involve troubleshooting from logs on a regular basis? Because if it does, I would be surprised that you feel the way you do.
My experience is with ELK but at least Kibana interface is pretty decent for applying filter combinations to find the needle in a haystack of logs.
And in terms of ingestion, if you are in a container environment you can just configure stdout from the container to be ingested - no agent required.
Building a system that can ingest a few GB of logs a day, index them in near real time and keep them around for a few months while keeping search speed usable is not as easy as it might seem at cursory glance.
But the real challenge is to get developers to write software that outputs structured logs that don’t suck. :)
And don’t even get me started on all the snowflake non-json log formats I’ve had to deal with …
I used to spend a lot of time looking at logs from a complex state machine. I would pull up a half day of logs in less (maybe a few GB), and search for something I was interested in like an id from an error message. This could be slow (tricks were disabling line numbers and searching backwards from the end) and then answer questions of the form ‘how long from this line until the next line matching x?’ or ‘what events of type y happened after the first event of type x after this log line’ or ‘what events of type x containing y happened between these log lines’ and suchlike. This is annoying to do with less; useful tricks were learning the shortcuts, taking advantages of regexes to highlight things or advance long wrapped lines with /^ and copying interesting messages into an editor and writing notes.
ELK/grafana don’t give great solutions here. Elastic/kibana already struggles with the first part because it doesn’t make it ergonomic to separate the part of your query that is ‘finding the log file’ and the part that is ‘searching within the file’. For the rest the UI tends to be more clunky and less information-dense than less, though if your data is sufficiently structured the kibana tables help. In particular, you’re still copying notes somewhere but next before/after queries aren’t easy/quick/ergonomic to express (I think), and changing the query and waiting is pretty slow. The typical search described above would be fast because the result wouldn’t be far away, and pressing n or N brings the next result exactly where you expect it on the screen, so you don’t need to try to find it on a page.
I think sql-like queries aren’t great here either because they are verbose to write and require either very complicated self-joins/ctes trying to write queries that find rows to search between/after or copying a bunch of timestamps back and forth.
Something people sometimes talk about is ltl (linear temporal logic) for log analysis. I think it can be useful for certain kinds of analysis but is less useful for interactive exploratory log querying. I don’t know of how to do ltl queries against data in Loki or Elasticsearch.
To be clear, most of the reasons that elk/grafana don’t work for the use case I described vaguely above are problems with the frontend ui rather than fundamental issues with the backend. It may just be the kind of logs too – if your logs all look similar to logs of incoming http requests, the existing ui may work great.
In the past I spent a lot of time cutting up logs with grep, less, jq and Perl. It was amazing UX that Kibana can't beat in terms of performance, assuming you already know the time-window you are interested in (although I never learned enough gnuplot to be able to do visualisations so Kibana wins there). However, all that went out of the window when I moved into a world of milti-instance micro-services in the cloud and SOC2 compliance. No more downloading of logs to my local machine and cutting them up with sensible tools. :(
That said, nothing that you outlined above is particularly difficult in Kibana, the main annoyance being the response time of the query API (somewhat mitigated by indexing). Based on your vague description my vague workflow would be:
- filter for type x
- limit time range to between occurrences of x
- change filter to type y
- an any point pick out the interesting fields of the log message to reduce noise in UI
- save and reuse this query if it is something I do regularly
- if your state machine has a concept of a flow then filter by a relevant correlation ID
Not sure what you mean by "finding the log file" since Elasticsearch is a document database where each log line is a document.
- It natively supports 'stream' concept [1] - this is basically logs received from a single application instance.
- It allows efficiently querying all the logs, which belong to a single stream, on the given time range, via 'curl', and passing them to 'less' or to any other Unix command for further processing in streaming manner [2].
Take a look at quickwit. Its basically a clone of elasticsearch but in rust.
I have around 380 TBs of logs currently in s3 and have sub 1s searches for needle in the haystack searches. It handles all that with just 5 search nodes running on kubernetes with 6gig of RAM each.
Yes there's real value there. That everyone's got their own flavor is a bunch of extra work because we haven't solved the coordination problem yet is annoying, but that's solved by choosing one and sticking with it. Learn that query language really really well, and don't touch anything else. Splunk is useful as all hell once you get over the hump of learning their proprietary query language. it's really friggin useful. it's useful to the tune of Cisco buying them for $28 billion. people are deriving real value from them, the question is what are your problems that this can solve for you, but do you even have those problems in the first place? If you've not found it useful then why are you stuffing logs into S3? just send them to /dev/null instead
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.
As other commenters already suggested I think it just comes down to what your actual day-to-day job is. In some companies you have dedicated data engineers whose job it is to understand these complex logging systems. But despite the complexity they may still derive value from it since they are deeply involved in writing SomeQL queries pretty much all day.
At my place of work we do not derive much value from our ELK installation, because we do not interact with it every day. But since everyone is used to grep, awk to some extent from other activities, these are the tools that are used when incidents/bugs happen and the cause has to be found.
As with all the other stuff out there, ELK etc. may simply not be for everyone.
I actively use grep, cat, uniq, sort, less and other Unix commands every day. That's why I added good integration with Unix pipes into VictoriaLogs, since it may cover missing functionality [1].
> And did I say that the Logstashes and Promtails and Vectors and what not pipeline tools with their Grok etc. filters feel like somebody wanted to really make busywork cool.
The worst part about Promtail/Vector is that you have to write code in YAML. Why.
that, plus having support for built-in support for "unit testing" processing pipelines [1] are two features that made me immediately want to ditch our existing Promtail configs and switch to Vector.
This is what I am wondering every time I am updating my TV (to a larger model, better HDR, etc. ]). I almost exclusively use the TV to watch movies. Movies that have been shot at 24fps, or 29.97 or 48fps. So this being my use case, all I need is that the player chain and the TV can change refresh rate to the actual movie refresh rate/fps.
For my use case, is there anything I am missing here? Or have I been in the wrong all these years to brush off the TV sales guys at the store trying to push me 240Hz etc. latest fads?
Okay you. Its common for people to call the big led/oled monitor you put in ur living room a tv. And as far as I know there's no difference between them tech wise. My tv is a 65inch 4k 120hz oled panel. Everyone calls it a tv. They are also still sold as "tv"'s online. Smart tv, etc.
Sidenote the word monitor is also a pretty clear sign of age. If I hear somebody call my screen a monitor its like when my grandma calls the toilet the comode.
There’s a pretty big difference between them technically, mostly the latency of the display chain. TVs can have signal input to picture on screen latencies of dozens of milliseconds, whereas a monitor would be considered defective if it was more than one frame.
This only matters for interactive content, but it’s where a lot of the price difference comes from.
Most TVs have a "game mode" that reduces latency to a single frame time, give or take a few milliseconds[1]. Not as good as the best monitors, but close, and certainly not dozens of milliseconds.
Only recently have low latency screens been the default expectation for flat panel computer displays. (I know the crt's were really fast) For most of my life most flat panel computer displays were high latency. Me and my gamer buds have always had to check we were buying a screen with sub whatever ms latency. Nowadays though they are pretty much all fast like that.
This applies to the tvs too. Most of them have a low latency mode. Mine has it. I use it all the time.
Anyways, point is the uneducated consumer can't tell the difference between them, and me the well educated consumer also can't tell the difference, and they come with all the same features, so people just call the big ones tvs, and the small ones screens. (Except the smart tv stuff)
Obviously, if you exclusively watch 24/29.97/48 fps movies, a display that updates faster than that has no benefit to you. I suppose it does get the next frame faster.
But have you watched 60/120/240 fps content? How often do you update your TV? If you're going to keep it for more than a few years, definitely get 240 Hz.
I was similarly dismissive of high-frame-rate displays, until I got a new monitor (4k, 120fps, replacing an ancient 1080p display with screwed up vsync settings that capped it at 30 fps because I didn't know any better) and watched some content I'd shot on my own Insta360. Oh my god was it incredible. Buttery smooth and sharp and fast, like real life instead of a movie. I booted up Rocket League just to see the difference. It's like walking around while looking through a smartphone camera preview versus looking at the world with your own eyes. 30 fps is now hard to watch and totally unplayable for me. (Yes, unplayable, not unwatchable; if you ever hook up a PC gaming system to the TV there's zero dispute in my mind that 240 Hz is worth it, even if it's less important for movies).
I understand that 24/29.97/48 fps have incredible inertia in because of limitations in distribution - if it can't be played on Blu Ray at high frame rates, and can't be played at the box office at high frame rates, there's a chicken-and-egg problem where studios don't produce HFR content so distributors don't support HFR content.
But I cannot imagine that this will hold off high-frame-rate content forever. More and more distribution is over vertically-integrated streaming providers. Because each frame is similar, the bitrate of compressed 120fps content isn't 2x that of 60 fps which isn't 2x that of 30 fps (it's more like 1.5x, with diminishing returns), so it won't cost 2x as much to distribute high frame rate video. It takes more compute from the encoders, but the AI boom is fueling GPU improvement at incredible rates.
I think that the first sports league (XFL? UFC?) to offer 120 fps or 240 fps content will put a crack in the dam that will quickly erode. Some AAA blockbuster action movie (by Ang Lee?) will premier exclusively on some streaming service, with special treatment to be distributed at 120 or 240 fps. A few top-tier cinemas will update some of their projectors to run at high frame rates. Eventually mainstream sports and mainstream movies and optical media standards will be at high frame rates.
Whether that's before or after your next TV upgrade or not, I don't know.
Modern TVs (or at least those I've been interested in) have upscaling functions both for resolution and motion. So they can take your 24fps movie up to some more manageable frame rate.
I personally cannot watch anything lower than 60fps (and 60fps is still inconvenient, but passable). I see it as a really fast slide show which gets my eyes tired quickly.
Also you can watch clips recorded at higher fps natively - like nature videos on YT etc (I think these still max out at 60fps, but with motion upscaling it is quite decent).
Combined with a good sound system, these can be quite relaxing and if you have an OLED screen it can even be mesmerising to watch.
>> He goes as far as justifying Hitler's attack on Poland
And why wouldn't he. We should not forget that it was russians and nazi's that started the world war 2[0][1]. It's just that the rusians got lucky, and Germany bore all the guilt.
Since then, russians of course have been actively trying to rewrite history.
My grandfather fought russia and later its ideology in battles across the world. I did forget for a while, but his words now shine brightly in front of me: NEVER trust a russian.
Rewriting history is pretty much real — there is a head of Ministry of Culture in Russia that openly states that "our history books for students should serve the national interests" (and he is a co-author of those books), implying that the truth can be manipulated to indoctrinate young people.
> NEVER trust a russian
P.S. I am myself Russian — not saying you should trust me... (just kidding). Its just not every Russian out there likes what Russia does.
The trouble with the very smart people is that even when wrong, they can come up with very elaborate and convincing reasoning why they in fact are not in the wrong, and indeed convince themselves (and then others in the process) that what they are preaching indeed is the correct solution or answer to a problem.
No, the guy who kept saying you should buy the Model 3 because it will get level 5 FSD around the corner, and you'll be able to use it as a robotaxi and the car will pay for itself.
The guy who said "fuck advertisers" in public even though his X business depended on them.
It's the same person you're talking about, he's done both of those things. He seems to be doing fine for himself. Which suggests that he's not falling victim to his own intelligence as described in the article, but rather just lying.
Given russias current trajectory with their war of genocide against Ukraine[0], it is not foreseeable that any western commercial airlines would be able to fly in their airspace for years to come[1].
