From: Steve Nickolas <usotsuki@buric.co>
To: Larry McVoy <lm@mcvoy.com>
Cc: TUHS <tuhs@tuhs.org>
Subject: [TUHS] Re: Re-implementations/Clean-Rooms et al.
Date: Thu, 8 Sep 2022 20:52:57 -0400 (EDT) [thread overview]
Message-ID: <alpine.DEB.2.21.2209082044540.13328@sd-119843.dedibox.fr> (raw)
In-Reply-To: <20220909001750.GW11929@mcvoy.com>
[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]
On Thu, 8 Sep 2022, Larry McVoy wrote:
> On Thu, Sep 08, 2022 at 08:05:44PM -0400, Steve Nickolas wrote:
>>
>> I'm probably the only one brazen enough to put it to the test.
>>
>> For some years, I've wanted to create a free implementation of System V, and
>> then move on from there. (I know there's limited utility for such a thing,
>> because of the BSDs.)
>
> Why? Have you booted 32V? Run in it for a while? No VM, no networking,
> very basic system. Other than historical, I don't understand the point.
Wasn't so much about 32V itself, as 32V being potentially clear and the
source for a lot of SysV, that having 32V would make rewriting SysV a lot
easier. 🤪
I've used v7/386, which is probably a comparable system.
>> A few things actually hinge on this. If it were considered a fact, and not
>> a mere opinion, that 32V was PD, then I could be sure that certain things
>> were safe to use, rather than having to rewrite (including some particularly
>> tricky stuff the BSDs never fully reimplemented, like diff(1)).
>
> I'm a source management guy, I've written a couple of systems. I live and
> breath diff and diff(1) is not in the slightest way hard. I wrote my own
> version of SCCS in a way that you could get as many different versions of
> the history as you wanted in one pass. That's a lot harder than diff(1).
>
> But maybe I don't understand what you think is tricky about diff, you
> may have some insight I'm missing, care to share?
I'm not actually that good a programmer. Step me through an algo, I can
probably interpret that as C, BASIC, 6502 ASM or 8086 ASM - but whether I
can implement it from just an explanation, that's hit or miss.
Frequently I come up with stupid ideas that I think are beyond me, and
often I'm right. Once in a while they're not, and I'm able to actually
implement something. 😜
Stuff like diff or sccs might be easy for some people here - but I've
spent months wracking my brain on things I think are simpler (6502 CPU
core for example - which is why for 20 years I used others' cores) and
been fruitless.
-uso.
next prev parent reply other threads:[~2022-09-09 0:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 21:50 Clem Cole
2022-09-08 22:16 ` Larry McVoy
2022-09-08 22:26 ` Warner Losh
2022-09-08 22:28 ` Warner Losh
2022-09-08 23:30 ` Steve Nickolas
2022-09-08 23:42 ` Warner Losh
2022-09-09 0:05 ` Steve Nickolas
2022-09-09 0:17 ` Larry McVoy
2022-09-09 0:52 ` Steve Nickolas [this message]
2022-09-09 2:16 ` Larry McVoy
2022-09-08 23:34 ` Clem Cole
2022-09-08 22:17 ` Warner Losh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.2209082044540.13328@sd-119843.dedibox.fr \
--to=usotsuki@buric.co \
--cc=lm@mcvoy.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).