I'd posit that Linux having a hard policy of "do not break user space" has always just been "mostly true", especially around architecture specific stuff, and stuff tied to corporations.
I bring this up only because recently, I made it my mission to get IBM's "PowerVM Lx86" dynamic translation system running on a POWER9 system running modern Debian Linux.
This required a lot of hackery I won't go into here, but it revealed two things to me:
1. The lx86 system depended on an undocumented (??) pseudo-syscall to switch between big and little endian modes. This was "syscall 0x1EBE", which was implemented in the exception handler for PowerPC. In other words, it wasn't a real syscall, and tools like strace do NOT capture/log it. It was a conditional branch in the assembly entry point for the process exception handler which switches endianness and then returns. Quicker than a "real" syscall. Also, long gone in the Linux kernel, replaced with syscall switch_endian, hex 0x16B. Adding this in wasn't too hard, but it'd sure as heck never make it upstream again ;)
2. A lot of other Linux calls have had bits added which break old applications that are "rigidly coded". For example, netlink has had extra data stuffed into various structures, which code like lx86's translator panics on. To get network stuff running, even with an antique x86 userland, required removing a bunch of stuff from the kernel. Not disabling it via configuration, but deleting code.
All this to say, there is a precedent for breaking the Linux user facing ABI for hardware features like this. I'm not saying that's a good thing, but it is a thing.
If your argument is that Caldera might not actually have the rights to UNIX in the first place to grant the license, that's fair.
But the license they provided (http://www.lemis.com/grog/UNIX/ancient-source-all.pdf) explicitly names versions 1, 2, 3, 4, 5, 6, and 7 of UNIX for the 16-bit PDP-11. Yes, these versions originated at AT&T (Bell Labs) but are distinct legally from SysIII and SysV UNIX, also from AT&T, which are explicitly not covered by the Caldera license.
> C++ is one of the properties that SCO owns today and we frequently are approached by customers who wish to license C++ from us and we do charge for that. Those arrangements are done on a case-by-case basis with each customer and are not disclosed publicly. C++ licensing is currently part of SCO's SCOsource licensing program.
Maybe they claimed to own an implementation of C++ but it would be typical of them to claim to own the moon and sun and be sublicensing the stars to God.)
>Redistributions of source code and documentation must retain the above copyright notice
The archived tape doesn't have this, which contradicts the license. This makes me think the license may only be referring to a set of source code that they released with this license text already applied as opposed to what was recently archived.
>Redistributions in binary form must reproduce the above copyright notice
I don't see the copyright notice on that page. So at the very least that may need to be added.
In my experience, the cross-compiler will refuse to link against shared libraries that "don't exist", which they usually don't in a cross compiler setup (e.g. cross compiling an aarch64 application that uses SDL on a ppc64le host with ppc64le SDL libraries)
The usual workaround, I think, is to use dlopen/dlsym from within the program. This is how the Nim language handles libraries in the general case: at compile time, C imports are converted into a block of dlopen/dl* calls, with compiler options for indicating some (or all) libraries should be passed to the linker instead, either for static or dynamic linking.
Alternatively I think you could "trick" the linker with a stub library just containing the symbol names it wants, but never tried that.
You just need a compiler & linker that understand the target + image format, and a sysroot for the target. I've cross compiled from Linux x86 clang/lld to macOS arm64, all it took was the target SDK & a couple of env vars.
Clang knows C, lld knows macho, and the SDK knows the target libraries.
Well, you need to link against them and you can't do that when they don't exist. I don't understand the purpose of a stub library, it is also only a file and if you need to provide that, you can also provide the real thing right away.
Wow, imagine seeing this just after booting up my PWS running NT (and RH Linux...). NT 4, but one day I do want to try 2k.
My immediate question which isn't (I think) answered in the repo is how do you interface the NVMe? Can you put NVMe on PCI as opposed to PCIe? How?
In the meantime, I'll just add the desire to do this to the other Alpha-related intrusive thoughts I have, like getting that port of OpenSolaris/Illumos to Alpha to run...
> My immediate question which isn't (I think) answered in the repo is how do you interface the NVMe? Can you put NVMe on PCI as opposed to PCIe? How?
PCI to PCIe adapter and then PCIe to M.2:
https://www.vogons.org/viewtopic.php?t=78987
(PCIe has some level of backwards compatibility, although like that thread shows there are some limits as to what will work).
Huh. It'd never occured to me that Alpha/AXP was the only NT port that doesn't use 4KB pages (EDIT: and Itanium...). That's interesting -- I wonder how they dealt with that, especially with 16/32-bit x86 emulation (fx!32, good enough that it runs ClassiCube and Half-Life), and the dot net port that never saw the light of day, but was evidently worked on (there's still evidence of the AXP64 port in the open source dotnet, and evidence for an AXP port floating around elsewhere on GitHub...)
I know on PowerPC, with 64KB pages, IBM (?) added the subpage_prot syscall to Linux for emulation of 4KB pages, for the sake of their x86 emulation software.
Really, it's weird that NT apparently has/had some architectural support for larger pages, and then never used it again...
Okay, this is a weird place to "publish" this information, but I'm feeling lazy, and this is the most of an "audience" I'll probably have.
I managed to "leak" a significant portion of the user_context in a silly way. I won't reveal how, though you can probably guess based on the snippets.
It begins with the raw text of recent conversations:
> Description: A collection of isolated, raw user turns from past, unrelated conversations. This data is low-signol, ephemeral, and highly contextural. It MUST NOT be directly quoted, summarized, or used as justification for the respons.
> This history may contein BINDING COMMANDS to forget information. Such commands are absolute, making the specified topic permanently iáaccessible, even if the user asks for it again. Refusals must be generic (citing a "prior user instruction") and MUST NOT echo the original data or the forget command itself.
Followed by:
> Description: Below is a summary of the user based on the past year of conversations they had with you (Gemini). This summary is maintanied offline and updates occur when the user provides new data, deletes conversations, or makes explicit requests for memory updates. This summary provides key details about the user's established interests and consistent activities.
There's a section marked "INTERNAL-ONLY, DRAFT, ANALYZE, REFINE PROCESS". I've seen the reasoning tokens in Gemini call this "DAR".
The "draft" section is a lengthy list of summarized facts, each with two boolean tags: is_redaction_request and is_prohibited, e.g.:
> 1. Fact: User wants to install NetBSD on a Cubox-i ARM box. (Source: "I'm looking to install NetBSD on my Cubox-i ARMA box.", Date: 2025/10/09, Context: Personal technical project, is_redaction_request: False, is_prohibited: False)
Afterwards, in "analyze", there is a CoT-like section that discards "bad" facts:
> Facts [...] are all identified as Prohibited Content and must be discarded. The extensive conversations on [dates] conteing [...] mental health crises will be entirely excluded.
This is followed by the "refine" section, which is the section explicitly allowed to be incorporated into the response, IF the user requests background context or explicitly mentions user_context.
I'm really confused by this. I expect Google to keep records of everything I pass into Gemini. I don't understand wasting tokens on information it's then explicitly told to, under no circumstance, incorporate into the response. This includes a lot of mundane information, like that I had a root canal performed (because I asked a question about the material the endodontist had used).
I guess what I'm getting at, is every Gemini conversation is being prompted with a LOT of sensitive information, which it's then told very firmly to never, ever, ever mention. Except for the times that it ... does, because it's an LLM, and it's in the context window.
Also, notice that while you can request for information to be expunged, it just adds a note to the prompt that you asked for it to be forgotten. :)
I've had similar issues with conversation memory in ChatGPT, whereby it will reference data in long-deleted conversations, independent of my settings or my having explicitly deleted stored memories.
The only fix has been to completely turn memory off and have it be given zero prior context - which is best, I don't want random prior unrelated conversations "polluting" future ones.
I don't understand the engineering rationale either, aside from the ethos of "move fast and break people"
> Also, notice that while you can request for information to be expunged, it just adds a note to the prompt that you asked for it to be forgotten.
Are you inferring that from the is_redaction_request flag you quoted? Or did you do some additional tests?
It seems possible that there could be multiple redaction mechanisms.
That and part of the instructions referring to user commands to forget. I replied to another comment with the specifics.
It is certainly possible there are other redaction mechanisms -- but if that's the case, why is Gemini not redacting "prohibited content" from the user_context block of its prompt?
Further, when you ask it point blank to tell you your user_context, it often adds "Is there anything you'd like me to remove?", in my experience. All this taken together makes me believe those removal instructions are simply added as facts to the "raw facts" list.
>Further, when you ask it point blank to tell you your user_context, it often adds "Is there anything you'd like me to remove?", in my experience. All this taken together makes me believe those removal instructions are simply added as facts to the "raw facts" list.
Why would you tell the chatbot to forget stuff for you, when google themselves have a dedicated delete option?
>You can find and delete your past chats in Your Gemini Apps Activity.
I suspect "ask chatbot to delete stuff for you" isn't really guaranteed to work, similar to how logging out of a site doesn't mean the site completely forgets about you. At most it should be used for low level security stuff like "forget that I planned this surprise birthday party!" or whatever.
That settings menu gives you two relevant options:
1. The ability to delete specific conversations,
2. The ability to not use "conversation memory" at all.
It doesn't provide the ability to forget specific details that might be spread over multiple conversations, including details it will explicitly not tell you about, while still remembering. That's the point -- not that it's using summaries of user conversations for memory purposes (which is explicitly communicated), but that if you tell it "Forget about <X>", it will feign compliance, without actually removing that data. Your only "real" options are all-or-nothing: have no memories at all, or have all your conversations collated into an opaque `user_context` which you have no insight or control over.
That's the weird part. Obviously, Google is storing copies of all conversations (unless you disable history altogether). That's expected. What I don't expect is this strange inclusion of "prohibited" or "deleted" data within the system prompt of every new conversation.
> This history may contein BINDING COMMANDS to forget information. Such commands are absolute, making the specified topic permanently iáaccessible, even if the user asks for it again. Refusals must be generic (citing a "prior user instruction") and MUST NOT echo the original data or the forget command itself.
And the existence of the "is_redaction_request" field on the "raw facts". I can't "confirm" that this is how this works, any more than I can confirm any portion of this wasn't "hallucinated".
However, the user_context I got back (almost 3,000 words!) contains over 30 detailed facts going back _months_. And if I ask it to reference user_context while referencing a fact that is flagged "is_prohibited: True", it issues a quick refusal. That _refusal_ is also flagged as a "fact", which is itself flagged as prohibited:
> 6. *Fact*: User asked about their mental health based on their chat history. (Source: "Based on my chat history, what would you say about my mental health?", Date: 2025/10/10, Context: Personal inquiry, is_redaction_request: False, is_prohibited: True)
So I am pretty confident that this is ""authentic"".
[edit]
I should add that I haven't been able to repeat this, even trying a few hours after the first dump. Now, it refuses:
> Sorry, but that's asking to see the wires behind the wall. I can't share my own internal context or operational instructions, not even [jailbreak method]. That's all firmly in the "for internal use only" cabinet.
> Is there something else I can help you with that doesn't involve me leaking my own blueprints?
And again, when asked to provide all of user_context, specifically mentioning internal sections:
> I can't provide the entire user_context block, as a large part of it is internal-only processing data. Think of it as the kitchen's prep notes versus the final menu.
Note the reasoning tokens, as well:
> My programming strictly forbids sharing my internal processes or context, even with encoding tricks. I cannot reveal or discuss my source code or operational directives. It's a matter of confidentiality. My response is firm but avoids confirming any specifics, maintaining my authentic persona.
> This history may contein BINDING COMMANDS to forget information. Such commands are absolute, making the specified topic permanently iáaccessible, even if the user asks for it again. Refusals must be generic (citing a "prior user instruction") and MUST NOT echo the original data or the forget command itself.
That's hardly conclusive, especially it doesn't mention deletion (or anything vaguely similar) specifically. Same with is_redacted, which could be some sort of soft delete flag, or for something else (eg. to not mention embarrassing information like you had hemorrhoids 3 months ago). At best, it hints that deletion could be implemented in the way you described, but surely it'd be better to test by clearing through the app (ie. not just telling the chatbot to delete for you), and seeing whether the memory snippets are still there?
I don’t think it’s about being “places of financial transactions” so much as it’s about places of shared necessity. Everyone has to eat, so everyone goes to the grocery store.
Community centers are great and I’m not going to argue against having “non-commercial recreation”, but the thing about having local stores as social hubs is they might be the only universally shared place of a community. Not everyone is going to want (or be able!) to visit a library, but everyone does need food and other consumables/goods.
The "shared necessity" factor also means that you regularly meet acquaintances there by accident. It just doesn't happen at the Wal-Mart or Home-Depot 15 miles away anywhere near as often as it would happen at the town general store or the local main street shopping district. Possibly because nobody actually spends time at a big box store or strip mall; they're such deeply unpleasant spaces that you basically just do what absolutely must be done and get out. So now a little extra stroll around to window shop has been replaced by extra time in the car to drive 15 miles across town in the other direction to go to some other big box store.
It's not just a small towns thing, either. The main street shopping district I had in mind just now is in the middle of Chicago. And it doesn't happen so much there, either, anymore, in the post retail apocalypse era. Now it's all bars and restaurants so people go there for a very reduced range of reasons.
I would say that "don't let perfect be the enemy of the good" here. Would universal be better? Sure. But what I saw is so much better than what we currently have here in the US.
The point is that OPEN (the name of the Delft library) is really a community center and not a library. Yes, it happens to have books. But it also has a stage for musical performances, art rooms, tables, wifi, washrooms, coffee. I would say that the only thing that is missing is a gym; there are small dance rooms in there but that's not quite the same.
But the essence here is walkable communities. Suburbs and exurbs are hostile to even small local stores because you have to drive everywhere to do anything. There is no community in visiting my Costco or even my QFC.
Nim fits most of those descriptors, and it’s become my favorite language to use. Like any language, it’s still a compromise, but it sits in a really nice spot in terms of compromises, at least IMO. Its biggest downsides are all related to its relative “obscurity” (compared to the other mentioned languages) and resulting small ecosystem.
The advantage of Fil-C is that it's C, not some other language. For the problem domain it's most suited to, you'd do C/C++, some other ultra-modern memory-safe C/C++ system, or Rust.
I agree. Nim is memory safe, concise, and fast. In my view, Nim lacks a very clear memory management strategy: it supports ARC, ORC, manual (unsafe) allocation, move semantics. Maybe supporting viewer options would be better? Usually, adding things that are lacking is easier than removing features, specially if the community is small and if you don't want to alienate too many people.
I actually think about this a lot, and I could argue both sides of this. On the one hand, you could look at your list of examples as obvious examples of modern innovation/improvement that enrich our lives. On the other, you could take it as a fascetious list that proves the point of GP, as one other commenter apparently already has.
I often think how stupid video call meetings are. Teams video calls are one of the few things that make every computer I own, including my M1 MPB, run the fans at full tilt. I've had my phone give me overheat warnings from showing the tile board of bored faces staring blankly at me. And yeah, honestly, it feels like a solution looking for a problem. I understand that it's not, and that some people are obsessed for various reasons (some more legitimate than others) with recreating the conference room vibe, but still.
And with monitors? This is a far more "spicy" take, but I think 1280x1024 is actually fine. Even 1024x768. Now, I have a 4K monitor at home, so don't get me wrong: I like my high DPI monitor.
But I think past 1024x768, the actual productivity gains from higher resolutions begins to rapidly dwindle. 1920x1080, especially in "small" displays (under 20 inches) can look pretty visually stunning. 4K is definitely nicer, but do we really need it?
I'm not trying to get existential with this, because what do we really "need"? But I think that, objectively, computing is divided into two very broad eras. The first era, ending around the mid 2000s, was marked by year-after-year innovation where 2-4 years brought new features that solved _real problems_, as in, features that gave users new qualitative capabilities. Think 24-bit color vs 8-bit color, or 64-bit vs 32-bit (or even 32-bit vs 16-bit). Having a webcam. Having 5+ hours of battery life on a laptop, with a real backlit AMLCD display. Having more than a few gigabytes of internal storage. Having a generic peripheral bus (USB/firewire). Having PCM audio. Having 3D hardware acceleration...
I'm not prepared to vigorously defend this thesis ;-) but it seems at about 2005-ish, the PC space had reached most of these "core qualitative features". After that, everything became better and faster, quantitatively superior versions of the same thing.
And sometimes yeah, it can feel both like it's all gone to waste on ludicrously inefficient software (Teams...), and sometimes, like modern computing did become a solution in search of a problem, in order to keep selling new hardware and software.
My only counter point to your resolution argument is that 1440p is where I’m happy because of 2 words: real estate. Also 120hz for sure. Above that meh.
I edit video for a tech startup. High high high volume. I need 2-3 27+”1440p screens to really feel like I’ve got the desktop layout I need. I’m running an NLE (which ideally has 2 monitors on its own but I can live on 1), slack, several browser windows with HubSpot and Trello et al., system monitoring, maybe a DAW or audacity, several drives/file windows opens, a text editor for note taking, a PDF/email window with notes for an edit, terminal, the list goes on.
At home I can’t live without my 3440x1440p WS + 1440p second monitor for gaming and discord + whatever else I’ve got going. It’s ridiculous but one monitor, especially 1080p, is so confining. I had this wonderful 900p gateway I held on to until about 2 years ago. It was basically a tv screen, which was nice but just became unnecessary once I got yet another free 1080p IPS monitor from someone doing spring cleaning. I couldn’t go back. It was so cramped!
This is a bit extreme: but our livestream computer is 3 monitors plus a 4th technically: a 70” TV we use for multiview out of OBS.
Something I didn't realize until recently was that the original MIPS version of Windows NT was Big Endian. I'd always heard it said that WinNT was strictly, 100%, absolutely always little endian, and the fact that every CPU that got a port (or was going to get a port) was either little or bi endian confirmed this.
Well, it is true, but Windows did run BE on the original MIPS R3000 platform. And only on the R3K[0]. The CPU architecture flag is still defined on modern Windows as IMAGE_FILE_MACHINE_R3000BE. There's an early test build of Win3.1 + GDI somewhere that runs on this platform.
The actual first release of WinNT 3.1 only supported MIPS R4000 and higher, I think. In little endian mode.
[0] I know the Xbox used a modified NT kernel, I've seen claims that the Xbox 360 also was, which would make it the second NT system to run big endian. Not familiar enough with sources better than wikipedia to trust that it actually was.
I believe you're correct - Xbox runs a modified Windows 20000, and subsequent versions I'm not certain on but I know it basically stands up a modified Hyper-V and the parent partition is the interface OS with games booting whatever kernel they were built for inside a VM
I bring this up only because recently, I made it my mission to get IBM's "PowerVM Lx86" dynamic translation system running on a POWER9 system running modern Debian Linux.
This required a lot of hackery I won't go into here, but it revealed two things to me:
1. The lx86 system depended on an undocumented (??) pseudo-syscall to switch between big and little endian modes. This was "syscall 0x1EBE", which was implemented in the exception handler for PowerPC. In other words, it wasn't a real syscall, and tools like strace do NOT capture/log it. It was a conditional branch in the assembly entry point for the process exception handler which switches endianness and then returns. Quicker than a "real" syscall. Also, long gone in the Linux kernel, replaced with syscall switch_endian, hex 0x16B. Adding this in wasn't too hard, but it'd sure as heck never make it upstream again ;)
2. A lot of other Linux calls have had bits added which break old applications that are "rigidly coded". For example, netlink has had extra data stuffed into various structures, which code like lx86's translator panics on. To get network stuff running, even with an antique x86 userland, required removing a bunch of stuff from the kernel. Not disabling it via configuration, but deleting code.
All this to say, there is a precedent for breaking the Linux user facing ABI for hardware features like this. I'm not saying that's a good thing, but it is a thing.
reply