I once developed for PC-GEOS, which wanted all memory in exactly 8K sized blocks. I wrote a set of C macros that presented an array-of-arrays as a single collection by using mod/divide operations on the index.
"generally make it flow" is exactly the problem. It's a process of smoothing over any interesting features of the text to replace them with plastic. It's submerging the actual information you wish to convey under a layer of low-entropy noise. The whole signal may still be there, but having to find it under a uniform glossy finish is work for the reader. It's work you didn't need to delegate to the reader.
LLMs generate low-entropy text. That's their entire purpose. But good writing isn't about being as low-entropy as possible. It's about producing peaks and valleys. As a person who's been participating in human-to-human communication your entire life, you probably have a pretty well-developed sense of how to structure the flow of a piece of communication. The small arcs with their ebbs and flows of tension and density provide the reader a rough surface that gives them enough traction to easily move from point to point. Don't let an LLM smooth out all the gaps. It makes it hard for a reader to keep their footing in the text.
> As a person who's been participating in human-to-human communication your entire life, you probably have a pretty well-developed sense of how to structure the flow of a piece of communication.
Not OP, but this is where you're wrong. The vast majority of people, myself included, have difficulty structuring communication for effectiveness to a wide audience. When I manage to pull it off I'm very proud of the work, but I can't just sit down and do it. Review with an LLM helps me find those places where it CLANKS, distracting the reader, taking them out of the flow. This is why every professional writer has an editor; good communication is quite hard.
He's not writing the bible. He's writing a blog post about segment registers. It's fine if there's a sharp edge here or there. You're probably better at communication than you think, and your readers are probably less picky than you're imagining. An occasional sharp edge in your text is not the end of the world.
I've reviewed what I originally wrote and I prefer the text I published. Sure, I could review it all myself (indeed I used to) but that takes time and it was becoming a barrier to actually publishing stuff. Maybe I'd have got around to finishing it in a few months.
I don't use AI to write for me. I hate people who do that.
Yeah. My challenge is how to distinguish from folks like you versus pure AI generated stuff. (I’ve added you to my mental whitelist, though, so I expect to enjoy posts from you in the future despite the AI tells in the grammar.)
But what should Intel have done? They needed a CPU that can run 8080 code but with more memory. Also it's the year ~1980 and we're limited to the technology of the age.
A system with 64k sized windows seems unavoidable.
If you extend the size of the address registers, 8080 code will only run in the first 64k, or require some kind of current window register.
An 8080 mode might have worked but that would have been expensive.
> Also it's the year ~1980 and we're limited to the technology of the age.
Tbf the Motorola 68000 which was released around the same time (1979) had a proper linear address space with 32-bit address registers (of which 24 bits were wired up).
Also the 8086 was intended as a cheap and temporary stop gap until Intel's "proper" 32-bit CPU architecture was ready for prime time (the doomed iAPX 432).
New platforms were 68000, old platforms with legacy code just wanted access to more memory, so 8086 segments allowed 64kb chunks. A hack only usable by folks that still wanted to run their old 64kb programs.
It would be a piece of trivia today if motorola were not 6 months late which forced IBM in frustration to change tracks to Intel and MS DOS instead (which worked on 8086). That 6 month drlay created WinTel of today.
Thanks, and that POSIX link is exactly the one I expected someone to bring up.
The key point is that POSIX does not actually define a real, physical epoch, and it explicitly avoids doing so. POSIX says every day is exactly 86400 seconds, leap seconds are ignored, the relationship between POSIX time and UTC is unspecified. In other words, POSIX defines how the "time()" API behaves, not what the underlying timeline is. It’s an OS level contract, not a timekeeping standard.
The problem I’m addressing is that POSIX retroactively assumes a form of UTC that didn’t exist in 1970–1971 and it provides no authoritative mapping between POSIX time and actual UTC. That’s why you can’t use POSIX as a normative reference for "seconds since 1970". It’s not a definition of time, it’s a behavioural model for system clocks.
This document is trying to define the actual timeline that people implicitly assume when they say "Unix timestamp", in a way that’s historically honest and citable. When I was looking at a number of RFCs that use these timestamps they didn't cite this reference, but went with the wooly "Number of seconds since 1970".
I forget where I encountered it, but I've seen similar encodings that eliminated the possibility of many possible encodings for the same number by making the length part of the value.
Values 0-127 are a single byte, but if that first byte has the continuation bit set, not only does that indicate the next byte has 7 more bits to contribute, it also moves the base up to the next window.
10000000 00000000 is the only way to represent 128.
10000000 10000000 00000000 is the only way to represent 16512.
Bitcoin has a variable width encoding (`CompactSize`), but it doesn't prevent overlong encodings - however there are various canonicalization rules in the Bitcoin protocol to require minimal encoding.
UTF-8 notoriously doesn't prevent ambiguous encoding by construction, but only prohibiting it in the specs. It's known as overlong encoding. It's up to the encoder/decoder to prevent, correct, or reject it. This burden on the software is exactly what TFA tries to eliminate with the bijou64 format (unfortunately replacing it with another burden: overflow check).
Do any formats using ZIP as the underlying format use ZIP comments for metadata? Unless there's a lot of compressors leaving "Zip file generated by MySuperZipper™" then I imagine any comments left were probably done for a good reason.
I'm not aware of any, but it wouldn't be insane to build a seekable deflate implementation by defining offsets in a zip comment. This would leave the zip file backwards compatible to usual decompression while allowing internal seeking within an individual file if the decompressor was aware of this index.
For seekable gzip indexes in zip, there SOZip: https://github.com/sozip/sozip-spec . However, it stores the indexes as files succeeding the actual file entry. To hide these index files and avoid extraction, they are not listed in the central directory, but a linear scan of the local headers, which some wrongly-behaved ZIP tools do, or which might be necessary for recovering broken ZIP files, would find those hidden indexes.
True, but I wanted this to be something anyone could do with equipment they might already have lying around and also get a feel for what gravity is actually doing.
Switching on a machine that displays "9.8m/s²" isn't that much removed from looking it up in a book.
Well, sure, but this is HN ... timing the fall of an object is one thing (Gallileo deserves a mention or three here).
"Measuring gravity" suggests more continuous measurement, such as what myself and various scaly mates used to do 40 odd years past with LaCoste and Romberg gravity meters that may or may not have had a shop built element to them for use in light aircraft to run grids across country scale areas.
