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?
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.
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...
It would be interesting if there was a DNS record of some kind to announce a PKI registry for a particular domain's email addresses. This would allow for some kind of decentralized discovery of suitable public keys for individual addressees.
But, a potential sender with important messages still needs do some pre-flight email verification over this path, e.g. sending a verification code encrypted the same way, to validate that the intended user can read it and send it back via another authenticated channel. This ensures that the sender-specific user identity actually possesses control of that email address and the discovered private key. It also reduces the impact of a malicious email provider to only denial-of-service rather than content interception.
So, is that discovery protocol worth it, versus just having an opt-in setting where the user supplies their desired public key and email address in the same form?
Oh, I think I misunderstood your description. I just jumped to the conclusion of a bastion host being used via the old proxy command method (what we did before the "jump" feature got added).
But, you're saying all these remote devices individually connect "back" to the central host to keep a tunnel open?
Honestly, I've never had this problem at large scale. When I did have it, I used one of these methods rather than SSH TCP tunneling tricks:
1. I'm in control of the firewall/NAT router itself, deployed OpenWRT, and setup the port-forwarding rules there (i.e. iptables address rewriting).
2. I really need to punch through uncooperative NAT, so I setup OpenVPN with that remote device initiating the persistent tunnel.