There are of course many other holes to poke in a high level estimate like this.
303 karma · joined January 25, 2010
There are of course many other holes to poke in a high level estimate like this.
The idea of an intelligence being consistent as it becomes more capable is probably not a good assumption. However I think everyone will settle for consistently "correct".
(I'm ignoring current LLM non-determinism within the same model which so far is attributed to parallel processing race conditions).
If I was designing a software system, I could introduce a time constraint. An imagined conversation: "How long will it take to get an answer? Between half a second and the heat death of the universe. OK. Can we just issue a timeout error after 1 second?"
This is putting controls in place so the system doesn't exceed its constraints and although hypothetical it might be able to do a job for any input, it can't because we haven't been able to find a more efficient solution for certain known and unknown scenarios.
However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its efficiency and breaking points.
What's very different is the cost to change the system to do something new and that's where this unbounded complexity blows up in our face.
I'm generally pro-publicly funded research. There is not any direct ROI on say the LHC, but it does fund advanced manufacturing and engineering work that might enable other more practical industrial applications. The ROI might be a century away.
Some of the smaller mom-and-pop stores just use small business accounting systems like quickbooks but those get pretty tedious to maintain with any sizable number of sales or employees per month.
There is nothing scientific about this conjecture, simply a thought I haven't had time to fully contemplate. What if there were loops and turns such that light and energy from distant galaxies would loop back around not just in space but in time creating weird feedback loops.
Tweets from Delkus and the Fort Worth National Weather Service are the main way I pay attention to new developments. Typically stuff will get posted there before live TV coverage starts. There's almost always a graphic posted of what the window is they expect for storms to form which helps me understand what I need to pay attention to.
I have a relative in another state whose a meteorologist and he doesn't have nearly as much fun as Delkus's team does online.
As far as over-indexing on preparedness goes, there has been at least twice our kids school has dismissed early in light of a severe weather forecast, however they do this several hours ahead of time (parents can't react that fast anyways). Only for the storms to be your more normal strength T-storm by the time carline starts. I can certainly appreciate the intent, but it's almost never that certain what's going to happen unless the storms are already popping up.
I consider myself a very weather aware person living near the edge of tornado alley in Dallas, I get all the alerts, generally keep a strong watch on radar development and storm arrival times (hail is just as much as a concern as tornadoes).
In general if there is a detection of a rotation or a strong hail core on radar, emergency sirens will go on near the affected area. Sometimes it just happens too fast, so if there is another method like the article sounds to detect a strong potential a tornado is forming it will absolutely reduce casualties.
As an example I lived through in October 2019. There was one hour between a Tornado Watch being issued and when the EF2/EF3 hit the ground. Watches generally last a long time and cover a large area so they aren't particularly helpful to me other than to indicate to 'check the radar on the regular'.
Because I was already glued to my phone I saw the warning right away, I was able to text friends that lived a few minutes from the tornado touchdown point that there was a tornado right next to them. Their sirens hadn't gone off yet, by the time they had taken shelter they heard the sirens and the wind kicking up right after. They got off light on damage compared to the rest of their neighborhood but I can't imagine someone out walking their dog or running an errand and then only having 1 or 2 minutes to find shelter. I'm still amazed this thing didn't cause more injuries particularly in the early minutes when the news crews and meteorologist were playing catch up. https://en.wikipedia.org/wiki/Tornado_outbreak_of_October_20...
Maybe this tech would have helped give a clearer indicator versus the usual approach of waiting to see something on radar or manually spotting it. Or maybe some storms will just form too fast to have any useful indicators.
It would be interesting to see if how rent markets change if more data becomes available. In the auto-industry, a car dealer can offload the unit to the wholesale market to minimize loss, whereas a landlord is less liquid.
The inventory pressure is there in both situations. An unsold car after 30-60 days is a problem both because of typical retail business dynamics and additional factors with general vehicle depreciation and high maintenance overhead of a vehicle compared to other capital goods, but the exit strategy is there and risk exposure can be limited.
The auto world works a little different since there is an entire wholesale operation behind the scenes that also drives pricing. There are several alternatives to KBB although less targeted to consumers. Also way more standardized in condition reporting.... but I know too much about the industry.
If there was significant uncertainty in what resources needed to be deployed to where then I could see a benefit to having an onboard team of humans who could assemble workers or payloads on the fly from orbit. However this would be a big shift from current mindset of designing robots for exact problem/solutions with precise payloads to instead having an excess of resources on board.
If the perspective shifted to "we're colonizing Mars so every ounce of metal in orbit will get used at some point" this is less of a concern.
I can't remember exactly why HSQL/H2 wasn't used but I think it had to do with fault tolerance and redundancy and what we could do with postgres replication was preferred over what we would have otherwise used SQLite for.
* Getting real deep with detecting OS/instruction set and edge cases
* Constantly validating permissions on every directory and file
* Constantly verifying checksums on everything put in place
* Concurrency controls to make sure the user didn't launch the installer twice, or the system wasn't live running when being reinstalled.
* Dependency verification was it's own rats nest of problems
* Uninstalling
Easier problems: * Logging
* Status tracking (except for really large files things get weird...)
* Aborting/Cancelling installThe testing cycle was the biggest pain, this was right as VirtualBox had become a thing so at least starting with a fresh system was slightly easier. (The entire company had 4 engineers + some researchers).
I think I was two years post-college as were most of my other colleagues... I'm fairly certain that product never made it out of initial trial (I left the company before it finished).
Splunk was used by a much larger product (easily 10x our scale) for monitoring events so there was no red tape to start using it.
After launching the detailed instrumentation (1 structured log event per HTTP request with a breakout of database/service activity) I was able to gain all of the insight needed and build a simple user/url lookup dashboard page to help other engineers see what was going on. We went from being mostly blind to almost full visibility in less than two weeks.
The downside was, we increased our billable Splunk usage by 50% since we were capturing so much more data per log event than the other product just consuming standard IIS/Apache logs.
That type of flexibility was totally worth it. Due to some acquisition shenanigans we broke off from that group and wound up on ELK stack which didn't perform quite as well, but was still usable with the same data. In today's day and age we could have just built an OpenTelemtry library.
We can easily see the population of divorced families, it's much harder for us to shine a light on "should be divorced but aren't". I have a hard time believing kids with a dysfunctional parent relationship at home would be better off.
I'd much rather see policies towards solving these problems versus one that has the government getting in the middle of my marriage or parenting.
Particularly since Alton delves straight into the scientific 'why' things are happening. I don't remember exact recipes well, but processes and how things work I can hold well so his explanation of what's happening with the mallard reaction or gluten in bread or any number of topics have made it possible for me to execute very simple meals very well.
In hindsight, most other cooking shows at the time were basically just food porn. Watch me make this simple recipe, trust me it's easy in 30 minutes! (Ignore prep instructions, ignore how to pick produce, ignore any explanation of why you're doing what you're doing).
A related example I lived through with a Perl application, someone decided to use this library 'Storable' that would serialize the memory in a binary format. We upgraded the library and started seeing "slow" performance across the server farm.
We recognized the processes were intermittently crashing and after decoding core dumps... figured out it was this upgrade to the Storable library. Apache httpd server chugged along just fine restarting processes. So different run-time, different type of crash resiliency.
Long-term lesson... be extra cautious with memory-serialized objects. Newer libraries have better protection on this to parse a header to detect compatible issues before loading the raw object into memory, but the potential is there especially with distributed systems today.
General industry practice people are put in delinquency buckets, and generally not by amount but in the 'are they past due or not?' I'm speculating but there could be other behavioral scoring as well and if they just automated the process of dispatching well... that's on them and good luck with that overhead.
"Cross-platform apps have never been easier. All the features customers love from native now on the web... We call it iApps."