2,740 karma · joined June 29, 2016
The pigeon-hole principle isn't an instruction guide for birds, it just describes the reality of occupancy. An egg-tooth keeps pecking, escaping at most one egg. A dog may circle, but occupies at most one bed.
The real value of idempotence is being truly end-to-end. It is about the final effect being controlled, rather than about some message hop in the middle. In my opinion, the impulse to isolate it to a messaging layer is often misguided. It presupposes that the other layers don't also have similar failure modes.
It makes for a more robust system when you can elicit the desired idempotence from natural keys and occupancy rules. For example, the way REST can make creation idempotent when the name can be established ahead of the creation request, or deletion is idempotent when names are not reused.
There are families out there still with 18-20 year cycles and could pretty much tick off every generation.
And families like mine that more or less skip every other: Silent -> X -> Z -> ???.
Of course there are other permutations, since life is full of so many uncontrollable factors.
Imagine pusing for locked down paper so kids can't pass notes nor make spit-wads and airplanes. Or locked down pens to prevent tic-tac-toe, doodling, lewd drawings, or scrawling graffiti on those old desks.
Some kind of KYC rules so that the older kids at school cannot pass their broader understanding of the world and cussing vocabulary down to the impressionable younger kids. Age restrictions on the trail to the woods, where kids somehow always knew about that stash of dirty magazines...
The parallel trees could have different ownership and access privileges, so that the editable working copy does not require the same filesystem access rights as the metadata tree. The git CLI actions would be performed with the more privileged filesystem role, and it would also have to be audited to make sure it treats all the working copy content as untrusted payload.
Edit: Or, a fair closed-system comparison to a battery would need to include a liquid oxygen tank or similar so you have the two components stored but can control the delivery...
But that's because today's world is forcing us towards overwhelming risk management and compliance systems like NIST 800-53 and friends. If anything, these mechanisms are being drawn, quartered, and spread to the opposite corners of the Earth.
Control via configuration management systems with configuration drift detection etc. Outputs and diagnostics via monitoring, logging, audit, and accountability systems. Authorization systems with extreme least privilege, draconian rules for privileged role assumption. Interaction removed from the entire operations plane, so it only exists in some application domain concepts as a sort of ship in a bottle, which eventually perversely recurses into the same mindset for domains with interesting content and user roles.
Lots of access path restrictions intentionally limiting which usage scenario is available in which combination to which user type from which locale with which client device.
So the idea of flexible and convenient fusion of many different IO and control paths into a portable and remotely attachable terminal UX seems like the complete antithesis..?
I have a long term interest in full electrification, but find the process daunting due to the interlocking set upgrades. Between insulation envelope upgrades and electrical system upgrades, there is a lot of potentially disruptive work needed to even allow permits to be issued for heat-pump HVAC and water heater or fully electric kitchen.
If the internal wiring also needs much work, it threatens to be almost as invasive as a gut renovation. Then, I ponder what other work we'd want to piggyback on it. But then it all sounds too much for life and budgets, so we procrastinate...
The steering of the jet stream seems to have some qualitative changes in these conditions but also more chaos. It could steer storms anywhere along the coast, so different parts of CA, OR, and WA get different impact. Just in my lifetime in CA, I've witnessed some very wet El Niño winters but also some drier than average.
The biggest precipitation threat on the west coast seems to be a repeat of some of the biggest flooding events known historically or geologically. But, these are relatively infrequent and most of the record predates any understanding or tracking of the El Niño oscillation. So the correlation cannot be stated so clearly. These are atmospheric river events which seem to stall, producing heavy rains over the same area for a much longer period.
Just in the recent centuries of CA history, there have been massive floods in northern and southern regions in different month-long rain events. There have been improvements to flood control infrastructure since then. But, the only reason those events aren't known as the most costly is because there wasn't as much economic development here back when the floods happened.
Our usual storms sweep through an area the heaviest rains over just part of a day. Our varied terrain means that each individual storm also has very uneven rainfall amounts due to orographic intensification. Prominences with the right aspect towards the wind will get far more accumulation. Our watersheds can absorb quite a bit of this, but even those brief rains can cause localized flooding.
If the rain continues for many days in a row, we will see widespread mudslides and flooding of larger rivers, basins, etc. Some of the historically extreme events had rain persisting for over a month!
Edit: along with these "mega storm" scenarios, we also have evidence of "mega droughts". It's worrisome to imagine what challenges may come from a more energetic and chaotic climate.
I think its just as important to realize ideas themselves can be conflicted or contradictory, and that practical action requires compromise. Many seductive ideas may not be well-formed if you really dig deeply enough. It's not just economic or political pragmatism. Even the solo designer/thinker needs to compromise such untested ideas in search of a realizable system.
So, at best, the argument seems to be that the surviving gene pool may get more complex with lots of optional mutations which all coexist? Could we end up like some plant species full of cultivars where larger swathes of genes are expressing differently out of a very convoluted library?
If you're envisioning medical science to allow people to survive with otherwise lethal mutations, I would say that is not an escape from evolution. Instead, you've revised the reproductive cycle to include more epigenetic components. The species is still the survivable set of genes and cultural practices which are evolving together, and which terminate when they no longer function as a system.
Any usage of the name in identifiers includes the epoch. Identifiers from several epochs could be concurrently in use. Identifiers rooted in different name epochs are not be comparable.
Out of band networking effects need to establish the meaning of a specific name epoch. The disambiguation doesn't work if the intended consumers are unwilling to learn and distinguish the epoch component of identifiers they care about.
I suppose, at the limit, this is the same as just having everyone add some numeric suffix to names they try to register? But it would be more constrained, e.g. structurally enforce that the digits correspond to some kind of clock metadata which is a witnessed and signed part of the decentralized ledger.
Some of the people shoveling LLM slop seem to miss that point.
If you are on reasonable storage, I think it is arguable that the main reason you would have to recover is due to a software failure leading to corruption of the PostgreSQL backing state files. Otherwise, you would simply be restarting PostgreSQL on your durable and available storage. So, if the content has been corrupted by bugs, can you trust the recent WAL log in this scenario? Or can a plain dump be a more reliable "known-good" database recovery point?
And what is the business cost to rolling back to a less frequent dump such as nightly? Not every DB is some kind of multi-party OLTP ledger. Sometimes, a day of lost "new data" may be just a day of labor to repeat some data entry or other repeatable work...
A really robust contingency plan probably has both of these kinds of backup, and scenarios where one recovery versus the other is attempted. But if you are starting at a very small scale, hosted on some reasonable cloud storage like EBS, a cron-based dump that goes into a normal hierarchical file backup system may be totally sufficient for the extreme disaster scenario where you cannot simply restart your DB server on top of the surviving and available storage volume?
If you are doing some kind of full cross product where the join creates a much larger set of rows, it could optimize the DB load and network traffic to fetch the source sets and then generate the permuted set locally.
But, many inner join patterns are selective. They produce a much smaller output than the source records. The traffic to pull all the records and then intersect and filter locally is much worse than having the DB do it.
And that's before you even consider indexed joins, where the query plann is able to make good use of indexes to avoid doing brute-force table scans, sorting, and filtering.
I don't read Portuguese, but the tables of results seem to imply they are tuning block sizes that leverage the L3 cache. They also talk about prefetch, which tends to matter more as you are approaching a streaming pattern.
So, a single core result may not scale linearly for multicore, given that there will be some cache contention, right? It's a very different tuning problem to optimize each of N cores to use its 1/N fraction of cache while sharing the available bandwidth for cache misses.
I shouldn't really have referenced "replace" at all, but rather "optimize". And not targeting middle management but the whole non-medical structure above. This is where I think most of the waste in our modern US medical system lives.
But I understand it is still mostly a half-baked concept. We'd need a revolution far outside of just some management system. I believe it's the whole enclosing system that is rotten and driving medical costs away from the actual encounter costs. Profiteering, risk management, regulatory capture, etc.
I woudl argue there was a point, long ago, where these things have taken on a life of their own and no longer serve the need of improving care outcomes and the actual medical cost-benefit tradeoff we should be optimizing in a just and caring society.
Once you add vibration, now you open a class of discreet alerts. Even an offline watch can give you a silent alarm function, which is great to reduce disturbance to your sleepmate. And some people value the smart notification alerts when awake too. The phone may be in a bag or coat pocket where vibration isn't obvious.
Then there are all the wearable sensor platform things, which divide the population into very different use case priorities. I.e. all the accelerometer and heart-rate tracking for sports, fitness, and lifestyle modification.
Or for outdoorsy people, the wearable GPS, digital compass, and barometric altimeter. This is my reason for having a Garmin watch. I find zero value in a "smart watch" that lacks these sensors. And I don't care for the other connected-watch features, so I actually have the bluetooth link disabled almost all the time. I go back and forth on the fitness tracking. It is bundled in the watch, so I use those sensors sometimes. But, I didn't actually care for them at all when shopping. There just isn't enough market for a good GPS+compass+altimeter watch without fitness sensors, so they don't make it.
Compared to any phone app I've tried, my watch records much cleaner tracks for hiking, both in terms of all the tight turns and accurate elevation data. It also presents the real-time data in a much more convenient, wearable format. When navigating a planned route, it can also vibrate and show me a course hint as I approach a faint trail junction in the wilderness.
On the other side, I think they are a little trapped in their legacy UX. A lot of people have Garmin watches long term, and will probably scream bloody murder if everything changes.
I don't mind so much. I have one of those budget models without a touch screen, and I find the UI vastly easier to use than my prior Casio hiking watches at least...
We really need to get to the point where any legally-binding digital authentication MUST be rooted in an in-person identity-proofing and authenticator binding ritual. Something you perform in front of a trained official, where physical inspection and local demonstration/activation of the authenticator is possible. This should be the basic standard to associate digital authenticators used in KYC legal and financial scenarios. The outcome should be some kind of standard digitally-signed certificate which can then be presented to KYC-compliant vendors to link the authenticator to a legal identity when establishing or maintaining financial accounts and records.
Perhaps there could be tiered certificates, where a high-stakes one would require this to be done in a secure facility where you expose yourself to risk of immediate arrest if presenting falsifiable identity claims. A more typical and decentralized version might be an upgrade of the notary public system in the US. Some kind of public digital ledger should record these certifications as well as revocations done by complementary rituals.
For social or informal accounts without KYC goals, some of this same machinery could be adopted. Simply modify or downgrade the identity-proofing part of the ritual as appropriate. This could link into other strategies like PGP web-of-trust or lesser kinds of identifiers like possession of phone numbers, email addresses, etc.
There would need to be criminal liability for officials misbehaving and certifying such identity and authenticator bindings without performing the requisite identity-proofing procedures.
A looming problem with shifts in demographics and family structure is that many people will be slipping into cognitive decline without a formal transition to address their incompetence. Sadly, there is a point where the older person really needs to permanently delegate important decision-making to a trusted third party. They should no longer be legally empowered to authorize funds transfers, sign contracts, or even make medical decisions.
We're not really setup to handle this well. Not at the systemic level of protecting people from themselves, and not at the personal level of relinquishing control over our own lives. So we often have to let the sufferer fumble along and cause a lot of damage before the protections eventually kick in.
And, ironically, these protection mechanisms can also be corrupted into another scam and form of abuse. To totally de-risk would require some kind of time travel or perfect foresight. But in the real world, the damage is often not fully reversible when it is detected after the fact.
Edit to add: I don't think it has too much to do with display latency.
It is some convolution of the desktop environment and display server deciding that keyboard input doesn't go to the focused window while it is in this nominal screen blank state. This Fedora 43 on a boring generic Thinkpad.
E.g. I have an old laptop running a browser playing some internet radio stream. Eventually the screen blanker (without locking) activates.
Some real life event makes me want to hit the space bar to pause music. But the modern screen blank has decided that it should eat/ignore key presses while blank. So hitting the key doesn't pause music. I have to wait for the screen to light up before it will be possible to trigger the pause, and this delay feels interminable!
I seem to recall that in the old days the input remained active to the focused window even if the screen was in a power saving state. This power saving was not conflated with screen-lock security etc. I much prefer that. I think this was because DPMS power saving was an underlying X server behavior, not delegated to a screensaver/lock application?
I'd also be partially satisfied with the async behavior of old terminal programs. My inputs should be buffered and processed even if the effects haven't returned to the screen yet. Then I could at least hit keys twice and be trained to know that one would unblank, the other would pause, and all would be well (eventually).
The current behavior is like having a temporarily numb hand, and being frustrated waiting for sensation to return before I can operate anything!
I don't feel as triggered LLM phrasing as people report here. At most, it feels like the same inane corporate jargon I've rolled my eyes at for my whole career. Perhaps it is amped up a bit, with too many forms of jargon multiplexed? It's a bit like when multilingual people code-switch too rapidly or even start to form some pidgin language. However, it is lacking the shared social context for this switching to be communicative. It's a bit more like spinning the dial on an old radio with random cuts between programming styles.
Stripped bare, I think What bugs me is the aggravated feeling that I am wading through word salad, and no longer being able to give the purveyor the benefit of the doubt. It was frustrating enough in the past, when it came from someone who was struggling to write or express themselves well. But now, it carries the implicit insult that they didn't even try, and it is constant and unrelenting.
So for me it's not the phrasing, it's that the phrases eventually don't add up. The meandering feels like a random walk. I get the same feeling from a lot of the egregious generated code I see in my day job. It's all superficial window dressing, but seems to miss the signature of an actual mind grappling with ideas and having intent to communicate.
It feels like we're trapped in some elaborate conceptual art piece, confronted by impenetrable symbolism. It invites nihilism but doesn't seem to actually reflect an artistic intent. The abyss gazes back...
- deciday (2.4 hrs)
- centiday (~0.24 hrs, ~14.4 minutes)
- milliday (~1.44 minutes, ~86.4 seconds)
- microday (~86.4 milliseconds)
But, to really get into the decimal clock, we want to also extend this into culturally useful multi-day units.
- decaday is somewhat akin to weeks
- hectoday is somewhat akin to months or quarters
- kiloday is somewhat akin to years
So we need to do some hard thinking and invent some insane tech to adjust planetary mechanics so that we can have decimal relationships between diurnal, lunar, and annual cycles. ;-)