3182da3965
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:
- D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
invisible until moved across by hand.
- Development happens from Windows and from Linux, and each looks in a
different place for the same checkout.
Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.
The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
3.3 KiB
| name | description | metadata | ||
|---|---|---|---|---|
| schos-rename-and-git | Schunix is now SchOS, the kernel is SchIFT; the tree is under local git as of 2026-08-09 |
|
On 2026-08-09 the project was renamed from Schunix to SchOS, to drop the "-unix" element and any trademark exposure to The Open Group. Nexoniarz's ecosystem layout:
| Layer | Name |
|---|---|
| Operating system | SchOS |
| Kernel | SchIFT |
| Desktop environment | SchDE |
| Window manager | SchWM |
| Compositor | SchCom |
| API / subsystem | SchAPI |
| File system | SchFS (unchanged) |
Every memory written before this date says "Schunix" and is filed under a
schunix- slug. That is the old name for this same project -- read it as
SchOS. They were deliberately not renamed: 42 files and every [[link]]
between them, for no gain.
SchOS vs SchIFT is a real distinction, not a synonym. Nexoniarz chose the split explicitly. SchIFT appears only where a Unix names its kernel:
uname(2)sysname ->SchIFT(nodename isschos, it is the host)/proc/version->SchIFT version 0.1.0 (schift) #1 SMP x86_64- the two licence sentences that say "kernel" outright, in LICENSE.MIT and NOTICE
Everything a user reads as the product is SchOS: panic screen, boot menu,
error prefixes, docs, LICENSE, NOTICE. schunix.img is now schos.img;
__SCHUNIX__ is __SCHOS__. The kernel source stays at kernel/, not
schift/ -- asked and declined, to keep the diff small.
The Assets/SchOS * Logo.* files are renamed but the artwork inside the
Full and Text logos may still spell the old name as vector paths. That is
design work, not a code change.
The tree is under git now -- local only
git init on 2026-08-09, first commit d0f7acf = the tree as it stood before
the rename, second e04ca28 = the rename. Before this there was no version
control at all, which had already cost real damage: a blanket sed rewrote
#include lines and string literals with no way to undo it.
core.autocrlf is false and .gitattributes pins * text eol=lf. This
matters: the build runs under Git Bash, and a Makefile recipe or .S file
checked out with CRLF fails in ways that point nowhere near the cause.
.gitignore excludes build/, sysroot/, dist/ and the images -- dist/
alone is 61 MB of upstream tarballs the build re-fetches.
There is no remote and there must not be one. See
nexoniarz-sharing-preference -- the standing rule is that unfinished work
never leaves the machine. Local commits are fine and wanted; git push is not.
The rename broke two things, both the same mistake
Both found by tools/bootcheck.ps1, neither visible at compile time:
cmd/shmtest/main.cwrote"SCHUNIX-MMAP-OK"with a hardcoded length of15and compared it back by hand-counted offsets (m[3]=='U',m[14]=='K'). The shorter marker made the write run two bytes past the literal and the compare read past the data -- failing a file-backed mmap that was working perfectly. Now one constant plussizeof.- bootcheck asserted a 31-byte file after appending to
"hello-from-schunix"; the shorter string makes it 29.
The lesson for any future rename: grep for string literals whose length is written out separately from the literal. A compiler cannot catch it and the failure looks like a broken subsystem.