TUHS

tuhs@tuhs.org

6420 discussions

Re: [TUHS] Russian Ancient UNIX stuff in the Archive

by msokolov＠ivan.Harhan.ORG

Sven Mascheck <sven.mascheck(a)student.uni-ulm.de> wrote: > Then the following might be an option, /UnixArchive/Applications/Ritter_Vi/ > > "This is basically ex/vi 3.7, 6/7/85, from the 2.11BSD distribution" > "A larger addition is the ability to handle ISO character sets." > > (recent development continued on <http://ex-vi.berlios.de/>) Where can I get the early versions of this effort? http://ex-vi.berlios.de/Changes lists at the very bottom: : Release 31/05/00 : * String extraction using mkstr and xstr is not longer be done. : * An ANSI C preprocessor may be used. : * Changes of symbol names due to collisions on newer systems. : * Fixed a null pointer reference in ex_tty.c. : * Included the 2.11BSD termcap in a subdirectory. Ex could use any : termcap library, however, that does not use malloc(). : * Support of eight bit characters excluding the range 0200 to 0237 is : enabled with -DISO8859_1. It does not include the regular expression code, : but otherwise works well in practice with the ISO-8859-1 character set. And all the newer stuff up to late 2002 is porting to "modern UNIX". But I don't want "modern UNIX", I'm running the original UNIX in its virgin form, I just want the 8-bit fix. The only files downloadable from ex-vi.berlios.de are 2002 releases and in the UNIX Archive Applications/Ritter_Vi contains only a tiny README file pointing to http://ex-vi.berlios.de/. Where are the old 2000 versions? MS

21 years, 10 months

Russian Ancient UNIX stuff in the Archive

by msokolov＠ivan.Harhan.ORG

Hi there, I remember seeing in the Unix Archive a few years ago (back when the $100 licenses just came out and it was called PUPS Archive) some Russian Ancient UNIX stuff, some things contributed to the UNIX community by the early Russian UNIX users (on Soviet PDP-11s). However, I am now looking for it and cannot find it. Would anyone have a pointer? I am trying to russify my flagship UNIX (4.3BSD-Quasijarus) and I'm adding/ fixing 8-bit support in various parts of the system, and I got stuck on ex/vi. The sucker just won't handle 8-bit chars. Since my job is to maintain Ancient UNIX (my flavor thereof) rather than replace it, replacing the original ex/vi with one of the modern reimplementations is not an option. I need to massage 8-bit support into the existing original Berkeley ex/vi with as few changes as possible. A friend of mine told me that Back in The Days the first UNIX users in the then USSR were running patched (russified) 2.xBSD on Soviet PDP-11s and had KOI-8 for Russian. Since the flagship editor on <any>BSD is ex/vi, this makes me think that those early Russian users used it and thus their patches accomplished just what I need. And so I'm looking for those patches. TIA for any help, MS

21 years, 10 months

Re: [pups] 2BSD build problem - unix.o not too big

by Steven M. Schultz

> From: "Ian King" <iking(a)killthewabbit.org> > I'm building a 2.11BSD kernel on my 11/73 (so I can include the networking > code and put my machine on the LAN!), and I'm seeing the error "too big for > type 431". Through the wonders of Google, I saw your discussion of this > error and followed your advice (from 1996!). However, when I ask 'size I'd have, up to now, sworn that the overlay setup was in the documentation (one of the appendices) but it could well be that it's still off in a file somewhere in the mess I call my filesystem ;) > unix.o', I get a size comfortably within the limits for base - 50112, well > below the 57344 you cite. None of the overlays exceeds 8192, and the 'total > text' figure is well below your example, too. FWIW, I did a 'naive build' Do you have any 0 length overlays? There can't be any gaps in the overlay structure. For example, this is legal: overlays: 8128,7552,8000,7296,8192,7424,5824,6784,3520 but this is not: overlays: 8128,7552,8000,7296,8192,0,5824,6784,3520 > first, copying GENERIC and changing a few parameters; after seeing the error > 'text segment too big' I went through the config file with a little more > thought and eliminated drivers I clearly didn't need (I don't have RL01/02s, You might need to go thru the Makefile too. Good idea to eliminate drivers you don't have (save their D-space requirements) but that can create empty overlays and that does not work. > for instance). Then I started getting this error. I did a 'make clean' > just to be sure, but still make gives me the 'too big for type 431' error. > (Yes, I RTFM on ld.) Hmmm, patch level 431 is recent enough I'd have thought to avoid a 'ld' problem (current is 444 but nothing recently has touched ld). What is the output from 'size unix.o'? Cheers, Steven Schultz

21 years, 10 months

[pups] 2BSD build problem - unix.o not too big

by Ian King

Steven, I'm building a 2.11BSD kernel on my 11/73 (so I can include the networking code and put my machine on the LAN!), and I'm seeing the error "too big for type 431". Through the wonders of Google, I saw your discussion of this error and followed your advice (from 1996!). However, when I ask 'size unix.o', I get a size comfortably within the limits for base - 50112, well below the 57344 you cite. None of the overlays exceeds 8192, and the 'total text' figure is well below your example, too. FWIW, I did a 'naive build' first, copying GENERIC and changing a few parameters; after seeing the error 'text segment too big' I went through the config file with a little more thought and eliminated drivers I clearly didn't need (I don't have RL01/02s, for instance). Then I started getting this error. I did a 'make clean' just to be sure, but still make gives me the 'too big for type 431' error. (Yes, I RTFM on ld.) I am standing here beside myself. :-) And I am humbly soliciting suggestions.... -- Ian PS: I'm at patch level 431, per the VERSION file.

21 years, 10 months

[pups] Re: PUPS digest, Vol 1 #148 - 1 msg

by Bill Pechter

pups-request(a)minnie.tuhs.org wrote: >Send PUPS mailing list submissions to > pups(a)minnie.tuhs.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://minnie.tuhs.org/mailman/listinfo/pups >or, via email, send a message with subject or body 'help' to > pups-request(a)minnie.tuhs.org > >You can reach the person managing the list at > pups-admin(a)minnie.tuhs.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of PUPS digest..." > > >Today's Topics: > > 1. Installing Venix or 2.9bsdpro on a DEC PRO350 (Franco Tassone) > >--__--__-- > >Message: 1 >From: "Franco Tassone" <franco.tassone(a)inwind.it> >To: <pups(a)minnie.tuhs.org> >Date: Thu, 13 Mar 2003 23:30:08 +0100 >Subject: [pups] Installing Venix or 2.9bsdpro on a DEC PRO350 > >Hi all, > >after having downloaded both distributions from a PUPS mirror, I was trying >to install Venix or 2.9bsd modified for the PRO350. >I've created for both distributions the installations floppy using a mvaxII >with an rx50 floppy. The mvaxII actually runs netbsd, so I did a dd >if=floppy.img of=/dev/rx0a for all the floppy images of the distributions, >but when I go and try to boot the bot floppies of venix (and 2.9bsd too) on >the PRO350, they fail to boot. The drive seems to try a little then the >machine hangs, no messages on the console, except a nice capital DIGITAL, no >messages on the serial terminale connected to the printer port with the >maintenance cable. >With venix floppy instead, after failing to boot, after a litle P/OS starts >from hd. >What am I missing, what did I wrong ? >Any hint will be greatly appreciated. >P.S. I definitively want to install an ancient unix on my dec pro350..., >help me ! >... >Franco Tassone > > I think those may be teledisk images so DD probably wouldn't work. You need an IBM PC with 80 track drives, IIRC to recreate the images... It's been a long time since I looked at those images. Bill

21 years, 10 months

[pups] Installing Venix or 2.9bsdpro on a DEC PRO350

by Franco Tassone

Hi all, after having downloaded both distributions from a PUPS mirror, I was trying to install Venix or 2.9bsd modified for the PRO350. I've created for both distributions the installations floppy using a mvaxII with an rx50 floppy. The mvaxII actually runs netbsd, so I did a dd if=floppy.img of=/dev/rx0a for all the floppy images of the distributions, but when I go and try to boot the bot floppies of venix (and 2.9bsd too) on the PRO350, they fail to boot. The drive seems to try a little then the machine hangs, no messages on the console, except a nice capital DIGITAL, no messages on the serial terminale connected to the printer port with the maintenance cable. With venix floppy instead, after failing to boot, after a litle P/OS starts from hd. What am I missing, what did I wrong ? Any hint will be greatly appreciated. P.S. I definitively want to install an ancient unix on my dec pro350..., help me ! ... Franco Tassone

21 years, 10 months

Linux Journal article (Doc Searles) on SCO suit

by Wm. G. McGrath

Hi all, Some will be interested to read Doc Searles take on the SCO suit here: http://www.linuxjournal.com/article.php?sid=6706 bill

21 years, 11 months

SCO sues IBM?

by Greg 'groggy' Lehey

I'm sure I'm not the only person who sees SCO's recent legal activities with dismay. For those of you still looking for facts, take a look at the links off http://www.sco.com/scosource/, and particularly the complaint at http://www.sco.com/scosource/complaint3.06.03.html. There are a number of things there which concern me, but particularly: 85. For example, Linux is currently capable of coordinating the simultaneous performance of 4 computer processors. UNIX, on the other hand, commonly links 16 processors and can successfully link up to 32 processors for simultaneous operation. This difference in memory management performance is very significant to enterprise customers who need extremely high computing capabilities for complex tasks. The ability to accomplish this task successfully has taken AT&T, Novell and SCO at least 20 years, with access to expensive equipment for design and testing, well-trained UNIX engineers and a wealth of experience in UNIX methods and concepts. Apart from the fact that I can't see any factual evidence that System V as licensed from SCO or its predecessors had any competitive SMP scalability, the "20 years" concerns me. That could go back to the days of the Seventh Edition. Which brings me to the real point: a little over a year ago, we received a message from Dion Johnson releasing Ancient UNIX under a BSD licence. For those of you who have misplaced it, I'm attaching it again. While none of us doubt that it is genuine, SCO has no record of it on their web site, nor (as far as I know) do any of us have this in signed form. In view of SCO's aggression, I think we should contact them and ask them to at least put the statement somewhere on their web site. Comments? Greg -- Finger grog(a)lemis.com for PGP public key See complete headers for address and phone numbers

21 years, 11 months

documment it and call it a feature

by norman＠nose.cs.utoronto.ca

Aharon Robbins: Sigh. This is the response on gcc and `conj.' Terms of disgust elided, since the sentiments are undoubtedly shared. This list isn't the right place for a general discussion of the matter, but I cannot resist remarking that this is one of the best arguments I have ever seen in support of gnu control. Norman Wilson Toronto ON

21 years, 11 months

documment it and call it a feature

by Aharon Robbins

Sigh. This is the response on gcc and `conj.' Terms of disgust elided, since the sentiments are undoubtedly shared. Arnold > Date: 11 Mar 2003 15:07:13 -0000 > To: arnold(a)skeeve.com, gcc-bugs(a)gcc.gnu.org, gcc-prs(a)gcc.gnu.org, > nobody(a)gcc.gnu.org > From: bangerth(a)dealii.org > > Synopsis: gcc 3.2.2 recognizes complex functions even without complex.h > > State-Changed-From-To: open->closed > State-Changed-By: bangerth > State-Changed-When: Tue Mar 11 15:07:12 2003 > State-Changed-Why: > This is a gnu extension. The builtin conj function is switched > off if you use -ansi or -std=c89. > > W. > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&…

21 years, 11 months

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