saltcured

I think you need to analyze the disaster scenarios and recovery costs you are trying to balance before you can really evaluate these different options.

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?

This kind of advice is very dependent on the scenario.

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.

Well, it does rely on decomposing the problem to optimize cache efficiency.

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.

Understood and agreed. I admit I was feeling a bit pithy with that comment.

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.

One of the most common interactions I witness at our local supermarket butcher counter is the guy explaining to yet another customer that the advertised weekly special sold out before lunch a couple days prior.

Now let's talk about how AI could replace Kaiser middle management and streamline bureaucracy to preserve more budget for doctors and nurses...

You say "digital" rather than "smart". Digital or analog, a basic watch has that single advantage of being mounted on the wrist. It is always there, supporting a quick glance when you don't have time, free hands, or social context to pull a phone out.

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.

An annoyance with Garmin is that they use something as trivial as customizable shortcuts as a price discriminator. They have it in their UI already, but remove it from the affordable budget models.

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...

I find so many of these things utterly insane. Much like the way a fax of a signed document is considered legally meaningful. I think we have to stop pretending any kind of digital media presentation of a document, face, voice, etc. can be authenticated by its content.

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.

Sad times are coming for a lot of families and individuals. It isn't just that technology is upending our naive ideas of trust and authenticity. This is, essentially, the broad class of "confused deputy" attacks. And the robust mitigation is to disempower the easily confused deputy, rather than to think you can block confusing signals.

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.

This is actually a laptop with its builtin display.

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.

The input latency that has been driving me crazy lately is the screen unblank latency to allow input to a program.

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!

Are you using the tools a lot and having first-hand exposure that gives you this sensitivity to phrasing? Or are you reacting to second-hand exposure? To a large degree, I've been isolating myself from the LLM craze. I have zero natural interest or impulse to prompt an LLM and read the results. Almost all my exposure is second-hand and involuntary. So, I haven't trained myself to know what phrasings are typical of which LLM product.

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...

I'll never accept a 24 hour dial that puts midnight at the top and noon at the bottom.

I think the day needs time units which are factors of 10x or 1000x to match SI prefixes. I give translations assuming current solar day length and current normal units:

- 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. ;-)

Ideally the single-use slop should just go straight into the self-satisfied user's system and never appear in the public "release" arena.

But we have to suffer through this awkward phase where people want to have it both ways. They don't want to run a successful collaborative development project, but the want the imagined accolades.

It's hard to really comprehend. It's a bit like people wanting to have fame as musicians for successfully pressing the buttons on a jukebox?

They should have started adopting olive size factors.

After Ultra High, we could have had Jumbo, Colossal, Super Colossal. and Mammoth frequency ranges.

Not to be confused with Colossal wavelengths, which is what we could have used if we need to fiddle around below Extremely Low frequencies..

RAM is more like agricultural products (with short shelf-life) than commodities like fossil fuels, mineral ores, etc. You can manage an inventory or speculate on production, but you cannot really hold a "portfolio" of it in any sensible way.

So, you should get into RAM futures if you believe this is more than a transient arbitrage sort of situation. All extant RAM will become obsolete as the demand shifts to newer, fancier versions.

It could make sense along an electrified rail line, if the power lines used to supply the trains can be leveraged for distribution?

But, putting panels between the rails seems foolhardy to me too.

Yeah, I can only imagine the stability when breezy weather hits that big sail

But does it have FX!32 working to run important x86 software in there?

Back in the 90s when I was in university, SQL (and databases in general) sounded like a boring topic that appealed to people who wanted to go into accounting/finance or some consultancy. I didn't study CS to learn to use an application! So, I took other practical curriculum options like operating systems, compiler writing, and graphics.

Then I went off and did distributed systems and HPC work for a decade or two, and the closest I got to "databases" was when we had to interact with LDAP. But, eventually our R&D contracts shifted and we were mixing with bioinformatics people. Then, we had a need for structured metadata management, and RDBMS seems like the right tool. So I finally had a reason to teach myself SQL, with a range of OLTP and analytics sorts of workloads on PostgreSQL.

I have found the existing ORMs in our Python landscape to be really alien and off-putting. I much prefer using the lower-level DB connector and doing my own SQL query building. We also do a bunch of generic/polymorphic work, defeating the main theses of ORMs. Mostly, our schemas are not known at development time, rather they change dynamically. There is no sense in mapping schema to classes, since a developer would have no contact with such classes. Instead, our code has to do "metaprogramming" about table definitions, keying, and reference patterns at runtime.

Yeah I'm just lazy about dealing with the room. If I find the motivation, I'll pull the original equipment back out of storage.

Yes, perhaps the amplitude was subtly different.

This was supposed to be running the DACs to match the source configuration, not resampling into some common format. I think that is an unavoidable part of the whole end-to-end ABX test concept.

Maybe it would be interesting to up-sample back into 24/192 and play both in that mode. But then people would argue about what type of up-sample to use.

I was in my mid 20s for this test. I understand my high-band hearing was better back then.

As referenced in the article, a common explanation for those audible differences is that the high-resolution version of the album is sourced from a different master.

In this case, it was my brother's own 24/192 recording, down-mixed by him to CD format with the intent that it be transparent. I believe he said his software was supposed to be dithering, but this was ~25 years ago and I can't really confirm the details anymore.

Decades ago, I was treated to an ABX test in my brother's recording studio. I easily recognized and preferred a 24/192 master he played versus the 16/44.1 down-mix. I honestly don't know whether there was something wrong with the down-mix, but qualitatively it did feel like it was "muffled" and coming from speakers, while the master really felt like live performance. He was surprised that I could tell them apart.

I also spent a lot of time ripping my old CDs to FLAC and trying different MP3 and AAC encoder settings to get playback that felt transparent enough to me. I could never tolerate Sirius/XM radio streaming due to the horrid compression I heard with every futile attempt. I still seem to have more sensitive hearing than most people around me, but in my 50s I know it isn't what it once was.

I never had huge budgets, but did strive for hi-fi in my limited ways. I used things like toslink and HDMI to send raw PCM data from Linux to my Yamaha A/V receiver's DACs + amplifier to drive somewhat nice Polk tower speakers. But then COVID-19 happened, and this stuff was packed up to move house.

Nowadays, music playback is streaming with mundane "subwoofer + satellite" PC speakers or MP3 playback with a mini-SD card permanently parked in my car's infotainment system.

USENET with a threaded newsreader like "trn" provided the optimal experience here.

You saw things in their threaded context, but it remembered what you've read and there is a direct action to "go to next unread" that will jump around and follow the fringe. You don't have to open individual root posts.

It wouldn't work so well if you expect to read sparsely though. People used moderation and killfiles to prune out garbage. The death of USENET was in many ways the flood of posts that made this no longer feasible.

The other missing thing here is topics, i.e. newsgroups. HN is not as broad as USENET as a whole, but also not as narrow as one newsgroup. These groups are what you would open, then skim through all the messages in that forest, catching up on what is new since last visit. HN topics are too narrow to want to bother reopening each one to catch up, but there is no collective layer above them to help find your own sparse subset of worthwhile HN conversations.

You make it sound like there are no ideas until words arrive? For me, my normal ground state is full of thinking that is not linguistic. My mode switch is more like having to turn on the whole language subsystem and pay attention to it, often to the detriment of my native concentration.

When I do think with words, it is usually something I am manipulating with a purpose. It is not the thoughts themselves. I have a thought, and I attempt to render it into words.

Outside of recollection of past speech, it is extremely rare for me to feel like words arrive with a thought I wasn't already holding. Most often, it happens when making jokes and puns in real-time. I am in a mood to be playful, and may have a vague feeling that there is something funny to interject, but cannot separate it from the word combination that comes to mind.

But I can't really think and deliberate verbally. It feels like an act of puppetry.

My first Linux PC was a 386DX-40 with 20 MB RAM and about 80 MB of HDD space.

I was able to run X Windows, Emacs, and gcc for university CS work. I had to use 8 bit psuedocolor graphics to have a decent sized desktop like 1024x768 or 1280x1024 (on a nice CRT).

But, I put it into a swapping frenzy by opening one JPEG that I had downloaded from an academic website. It was a high-resolution scan of some old manuscript, but probably lower pixel count than a typical smartphone photo from this decade.

Doing normal work also involved frequent swapping delays as you launched new programs and evicted old ones.

Yeah, I used WordStar on CP/M for my school homework in the early-mid 80s. (As soon as we had our first "typing allowed" or "typing required" kinds of assignments.)

My dad brought home a circus of different PCs in those years. First a Sinclair ZX80 kit; a VIC 20; several Morrow Designs CP/M machines; Apple III, with a IIe emulator card; this interesting sequence terminated when he hit DOS/Windows and got stuck there.

He was a pack-rat too. I pulled a CP/M machine's terminal out of storage and used it with my first Linux PC in college. It turned out it worked with an "adm31a" (?) termcap entry...