Modern tactics are to use every radar around via datalink (AWACS, Ground Station, stealthy drones flying ahead). The onboard radar is last resort, but still very capable.
Useless tidbit about myself: Back in the mid-90s I was in the USAF in the 552nd Air Control Group, and the team I was on specifically did the 'external test' of the data link. Spent a lot of time in a simulator pushing buttons pretending to be an AWACS guy on a plane while recording all of the data, then later painstakingly comparing that data to the manual log and radio recordings.
I would be interested to see how far they've brought the technology in the intervening, uh ... 30 years. Damn. That old computer (old by technology, ours was pretty new in practical terms) was the only mainframe I've ever used. Booted it up by loading a tape reel and programming registers. I still remember that the 'happy' code was something like 0B00BE in between cycles, anything else and it had crashed.
The US is stuck with older F-16s than the current export models with advanced radar. They're gradually being upgraded with some Block 70 components. That requires the new cockpit so it isn't just a quick part substitution.
I agree with you. The good news is that it looks like some of the alternate clients are focusing on it. https://commet.chat/ has voice channels (video rooms but default to camera off), and cinny's element call support PR defaults to camera off in video rooms as well iirc.
There are tools such as deploy-rs, colmena, and morph that let you deploy nixOs configs using nix. I can't speak to how good they are personally, I use ansible to push my nix configs.
I wrote a blog post about my experience using Clickhouse on a side project. You normally see discussions of Clickhouse involving large data sets and complex problems. I previously used Timescale to store the same data, so this also covers a comparison of the development experience between the two.
I was using Timescale for a small project of mine and eventually switched to Clickhouse. While there was a 2-4x disk space reduction, the major benefits have operational (updates & backups). The documentation is much better since Timescale's mixes their cloud product documentation in, really muddying the water.
Despite that, man it is really nice to be able to join your non-timeseries data in your queries (perhaps the fdw will allow this for clickhouse? I need to look into that). If you don't have to deal with the operations side too much and performance isn't a problem, Timescale is really nice.
Can you tell me more about why timescale doesn't perform in your opinion? My use case for timescale would be to gather my IoT telemetry data (perhaps 20/100 points per second) and store eg 1 year worth of it to do some analysis and query some past data, then offload that to parquet files on S3 for older data
I'd like to be able to use that for alert detection, etc, and some dashboard metrics, so I was thinking that it was the kind of perfect use-case for timescale, but because I haven't been using it yet "at scale" (not deployed yet) I don't know how it will behave
How do you do JOINs with business data for Clickhouse then? Do you have to do some kind of weird process where you query CH, then query Postgres, then join "manually" in your backend?
I was a little unclear, I think Timescale performs quite well. Just that in my (very limited) experience, Clickhouse performs better on the same data.
I actually have a blogpost on my experience with it here: https://www.wkrp.xyz/a-small-time-review-of-timescaledb/ that goes into a bit more detail as to my use case and issues I experienced. I'm actually half-way through writing the follow up using Clickhouse.
As detailed in the blog post, my data is all MMO video game stats such as item drops. With Timescale, I was able to join an "items" table with information such as the item name and image url in the same query as the "item_drops" table. This way the data includes everything needed for presentation. To accomplish the same in clickhouse, I create an "items" table and an "items_dict" dictionary (https://clickhouse.com/docs/sql-reference/dictionaries) that contains the same data. The Clickhouse query then JOINs the item_dict against item_drops to achieve the same thing.
If you know the shape of your data, you can probably whip up some quick scripts for generating fake versions and inserting into Timescale to get a feel for storage and query performance.
LiveView is so nice for full stack development, it's a wonderful palette cleanser after a day of enterprise programming.
I can attest to its JS interoperability. I have a project that streams data realtime into a liveview page that uses a combination of ag-grid, maplibre-gl, vega+lite, and Google's model-viewer all at once. All it takes is a little bit of JS plumbing to handle create and updates.
If it is possible can you share an example/samples integrating the mentioned libraries. I’m starting to learn LiveView again, mostly want to use aggrid and other custom libraries. An article highlighting the possibility and pointers to samples would greatly help everyone in this space.
I don't have any examples from my code, so the best I can do is the relevant documentation.
Its all done using phx-hook https://hexdocs.pm/phoenix_live_view/js-interop.html#client-... . While the documentation makes it look a bit more fancy, it is just a JS object with mounted() function. I set up my columnDefs and gridOptions in that function, and add the handleEvent() callbacks that are where I get data from the elixir side using send_update/3. Ag-grids vanilla JS documentation has been very helpful for how to use it without the benefit of react/vue,
reply