TUHS

tuhs@tuhs.org

5 participants
6532 discussions

by segaloco

So a project I'm working on recently includes a need to store UTF-8 Japanese kana text in source files for readability, but then process those source files through tools only guaranteed to support single-byte code points, with something mapping the UTF-8 code points to single-byte points in the destination execution environment. After a bit of futzing, I've landed on the definition of iconv(1) provided by the Single UNIX Specification to push this character mapping concern to the tip of my pipelines. It is working well thus far and insulates the utilities down-pipe from needing multi-byte support (I'm looking at you Apple). I started thumbing through my old manuals and noted that iconv(1) is not a historic utility, rather, SUS picked it up from HP-UX along the way. Was there any older utility or set of practices for converting files between character encodings besides the ASCII/EBCDIC stuff in dd(1)? As I understand it, iconv(1) is just recognizing sequences of bytes, mapping them to a symbolic name, then emitting them in the complementary series of bytes assigned to that symbolic name in a second charmap file. This sounds like a simple filter operation that could be done in a few other ways. I'm curious if any particular approach was relatively ubiquitous, or if this was an exercise largely left to the individual and so solutions were wide and varied? My tool chain doesn't need to work on historic UNIX, but it would be cool to understand how to make it work on the least common denominator. - Matt G.

7 months, 1 week

Proposed release goal: [PATCH] [pic] Add support for arbitrary polygons

by Douglas McIlroy

A worthy objective, but it should not be released without user documentation. Where can one see that? Doug

7 months, 1 week

Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Douglas McIlroy

>>> malloc(0) isn't undefined behaviour but implementation defined. >> >> In modern C there is no difference between those two concepts. > Can you explain more about your view There certainly is a difference, but in this case the practical implications are the same: avoid malloc(0). malloc(0) lies at the high end of a range of severity of concerns about implementation-definedness. At the low end are things like the size of ints, which only affects applications that may confront very large numbers. In the middle is the default signedness of chars, which generally may be mitigated by explicit type declarations. For the size of ints, C offers guardrails like INT_MAX. There is no test to discern what an error return from malloc(0) means. Is there any other C construct that implementation-definedness renders useless? Doug

7 months, 1 week

Looking for historical vi sources

by Anton Shepelev

Hello, all. Have you an idea where one could find the sources of the various versions of the ex/vi editor, besides those archived at TUHS: 1BSD/ex-1.1 2.11BSD/src/ucb/ex 2.9BSD/usr/src/ucb/ex/ex2 2.9BSD/usr/src/ucb/ex/ex3 2BSD/src/ex 3BSD/usr/src/cmd/ex 4.1cBSD/usr/src/ucb/ex 4.2BSD/usr/src/ucb/ex 4.3BSD-Reno/src/usr.bin/ex 4.3BSD-Tahoe/usr/src/ucb 4.3BSD-UWisc/src/ucb/ex 4.3BSD/usr/src/ucb/ex 4.4BSD/usr/src/usr.bin/ex 4BSD/usr/src/cmd/ex OpenSolaris_b135/cmd/vi There include vv. 1.1, 2.13, 3.2, 3.6, and many variants of 3.7. Has anything else been preserved to your knowledge?

7 months, 2 weeks

RIP Darl McBride former CEO of SCO

by Will Senn

It happened in September, apparently, but is only now making the rounds. Darl McBride, known for taking everybody and his brother to court over stolen code, has passed away. https://fossforce.com/2024/11/once-linuxs-biggest-enemy-darl-mcbride-dies-a… I actually remember liking SCO back in the day, before the company leadership went dark-side. These days, we get to play with ancient unix cuz of their license. What a topsy turvy world. Is there a concise summary of the SCO suits and fallout out there? I've seen a lot on the AT&T side of things, but other than having lived through it, I've not seen much on what eventually happened and why it all sort of just dissappeared. Will

7 months, 3 weeks

Fwd: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

by Warner Losh

---------- Forwarded message --------- From: Warner Losh <imp(a)bsdimp.com> Date: Fri, Nov 8, 2024 at 3:17 PM Subject: Re: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) To: David Barto <barto(a)kdbarto.org> On Fri, Nov 8, 2024 at 1:07 PM David Barto <barto(a)kdbarto.org> wrote: > > > On Nov 8, 2024, at 12:27 PM, Warner Losh <imp(a)bsdimp.com> wrote: > > > > On Fri, Nov 8, 2024, 6:20 AM Dan Cross <crossd(a)gmail.com> wrote: > >> On Tue, Nov 5, 2024 at 2:02 PM Warner Losh <imp(a)bsdimp.com> wrote: >> > On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich(a)gmail.com> wrote: >> >> I keep wondering if this assertion of code difference or lack thereof >> can be tested. Are not all these sources available? Which bits are missing? >> > >> > Yes. Great question. >> > >> > https://people.freebsd.org/~imp/pmap/pmap.32v >> > https://people.freebsd.org/~imp/pmap/pmap.4.2 >> > https://people.freebsd.org/~imp/pmap/pmap.4.3 >> > https://people.freebsd.org/~imp/pmap/pmap.net.2 >> >> Hmm; these all 404 for me? > > > Doh! Too much muscle memory. Those should all be bmap: > > https://people.freebsd.org/~imp/bmap/bmap.32v > <https://people.freebsd.org/~imp/pmap/pmap.32v> > https://people.freebsd.org/~imp/bmap/bmap.4.2 > <https://people.freebsd.org/~imp/pmap/pmap.4.2> > https://people.freebsd.org/~imp/bmap/bmap.4.3 > <https://people.freebsd.org/~imp/pmap/pmap.4.3> > https://people.freebsd.org/~imp/bmap/bmap.net.2 > <https://people.freebsd.org/~imp/pmap/pmap.net.2> > > https://people.freebsd.org/~imp/bmap/bmap.32v https://people.freebsd.org/~imp/bmap/bmap.4.2 https://people.freebsd.org/~imp/bmap/bmap.4.3 https://people.freebsd.org/~imp/bmap/bmap.net.2 Not sure why the previous... Warner

7 months, 3 weeks

Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

by Warner Losh

On Fri, Nov 8, 2024, 6:20 AM Dan Cross <crossd(a)gmail.com> wrote: > On Tue, Nov 5, 2024 at 2:02 PM Warner Losh <imp(a)bsdimp.com> wrote: > > On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich(a)gmail.com> wrote: > >> I keep wondering if this assertion of code difference or lack thereof > can be tested. Are not all these sources available? Which bits are missing? > > > > Yes. Great question. > > > > https://people.freebsd.org/~imp/pmap/pmap.32v > > https://people.freebsd.org/~imp/pmap/pmap.4.2 > > https://people.freebsd.org/~imp/pmap/pmap.4.3 > > https://people.freebsd.org/~imp/pmap/pmap.net.2 > > Hmm; these all 404 for me? Doh! Too much muscle memory. Those should all be bmap: https://people.freebsd.org/~imp/bmap/bmap.32v <https://people.freebsd.org/~imp/pmap/pmap.32v> https://people.freebsd.org/~imp/bmap/bmap.4.2 <https://people.freebsd.org/~imp/pmap/pmap.4.2> https://people.freebsd.org/~imp/bmap/bmap.4.3 <https://people.freebsd.org/~imp/pmap/pmap.4.3> https://people.freebsd.org/~imp/bmap/bmap.net.2 <https://people.freebsd.org/~imp/pmap/pmap.net.2> which shows the progression before the rewrite in 4.4BSD-lite. Warner

7 months, 3 weeks

Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote: >> The bmap implementations I saw were bit for bit identical, same code, >> same variables, same style, same indentation. I'm 100% sure they were >> not independent. > They are different in 4.3BSD. They are different in 4.2BSD (but less > different). The underlying filesystems are different on disk, so they > routines have to be different. That last sentence points out something important that people need to remember in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD switched to the BSD Fast File System, so I very much doubt that the low-level (i.e. logical file block to disk block) file system code in anything after 4.1A looks much like the AT+T low-level file system code. (I have no idea how the BSD code compares to the Linux file system code, but that's between the Linux people, and Berkeley.) Noel

7 months, 4 weeks

IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO))

by Douglas McIlroy

As a bit-part expert witness for the other side of the SCO case, I saw hundreds of pages of evidence in the form of side-by-side code comparison. As I recall, the vast majority of highlighted correspondences were small snippets, often rearranged. I didn't interact with the lawyers enough to form a solid opinion about where this stood on the spectrum of coincidence to fair use to plagiarism. It certainly wasn't wholesale copying. I do not recall being asked to opine on whether trade secrets had been stolen. Apropos of rearranged snippets, one of the diff algorithms I experimented with in the mid-70s identified rearrangements. I abandoned it because real life code contains lots of similar lines, so many in PDP-11 assembler programs as to suggest that these programs are largely permutations of each other. The phenomenon is much less common in C, but still present; witness the prevalence of code like int i, n; for(i=0; i<n; i++) { The phenomenon may have been afoot in the SCO evidence. In regard to trade secrets, I was surprised when I moved from Unix at Bell Labs to Linux at Dartmouth and found calendar(1) to be completely rewritten, but with logic absolutely identical to the original version I wrote at the Labs. That was so idiosyncratic that the identity of the two could not have been an accident. Doug

7 months, 4 weeks

QED Archive updated

by arnold＠skeeve.com

Hi All. For anyone who's interested, my QED archive at https://github.com/arnoldrobbins/qed-archive has been updated. Changes were provided by Sean Jensen. The usenix-80-caltech subdirectory is now more complete and the README.md points at Sean's updated QED port which now works with Unicode. I thank him. Arnold

8 months, 1 week

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS