The swirly background (especially on the main screen), shiny card effects, and the CRT distortion effect would be genuinely difficult to implement on a system from that era. Balatro does all three with a couple hundred lines of GLSL shaders.
(The third would, of course, be redundant if you were actually developing for a period 486. But I digress.)
> I remember the local press going on about the crypto mining operation and how folks were going get high-tech jobs in this rural area of Texas. Of course it didn't go that way.
That's a disappointingly common crypto industry lie. Cryptocurrency mining involves very little labor beyond initial construction; it's certainly not a major source of permanent employment.
Rockdale is a small town of ~5000 residents. Even if it were practical to install district heating - which I don't think it is - there certainly isn't demand for hundreds of megawatts of it.
> It will be interesting to see how they make this arrangement approachable for Arduino’s audience which generally expects ease of use to be a high priority.
If history is any indication: they won't. See the previous Arduino Linux + MCU systems like Arduino Yún and Tian, for example, or the FPGA-based Arduino MKR Vidor - Arduino's approach has generally been to throw hardware over the wall with a bit of example code and hope the community can come up with a use for it.
Relative times are nice for recent times (e.g. "5 minutes ago" is better than "2025-12-18 13:03"), but they should "decay" into absolute times for anything that isn't fairly recent - like a week or two, perhaps.
It varies by use case. I can think about e.g. an SRS flash card where you next review is in 2 years. I honestly don‘t care if 2 years here means 21 months or 28 months, and I especially don‘t care if the next review is on 21st of February 2028 at 13:52. All I want to know is that the next review is so far in the future it may not actually happen.
That's a fair point. I'm thinking of the use case of formatting a past date on something like a social media post/comment. (For example, a comment on HN - which uses a rather long cutoff for relative dates.)
I don't like just saying "read the article", but this is precisely what the article explains. In short: the rental rates are a condition of the property owner's loan.
Not one of the downvotes, but: as far as I'm aware, there was never any syntax which could be used for HTML transclusion in the browser. There may have been SGML or XML syntaxes proposed for it, but none of them were actually implemented in this context.
You can use entities to create static sites in advance, or by including support in the browser. sgmljs can do both, and simply using shared headers/footers for static site generation from markdown and other SGML partials is explained in [1].
SP/OpenSP and older SGML tools were most certainly available and used to assemble HTML docs from command line apps in the 1990s for complex websites with lots of content such as software documentation. The editor of the HyTime spec with its strong focus on adapting and transforming to multimedia and web was working with a training/education company. W3C's long-term validator service ran off SP.
XSLT was implemented in every browser like 25 years ago and has the ability to include other document templates/fragments client-side. It's exactly the functionality everyone always says is missing.
> With Korean, it looks more jarring, as the input method is apparently very different, and seems to map the keys for unrelated latin letters to Hangul letters?
More or less, yes. Each Hangul character represents a syllable, and is composed of two or more components (jamo) representing individual phonemes (like vowels or consonants) which make up the syllable. The keys on a Korean keyboard are mapped to those jamo.
More specifically, since Korean syllables are of the form CV(C) where C is a consonant and V is a vowel, almost all Hangul keyboard layouts divide the entire keyboard into two or three sections (consonant-vowel or initial-medial-final). The standard KS X 5002 layout is the former, a "bipartite" method (두벌식), while I'm using one of the latter, "tripartite" methods (세벌식).
(The third would, of course, be redundant if you were actually developing for a period 486. But I digress.)
reply