> Are there any legal issues with this or since the company closed down
> its all well and good ?
I've been researching it for some time... At one point you could download
Coherent from ftp.mayn.de which contained a note saying it was OK and that the
sources had been released publicly. I firmly remember seeing that note
long ago. Many others seem to have seen the note and to remember it. But of
course my memory might be deluding me.
The problem is that ftp.mayn.de went down on 2004 and the original archive
was lost. The only copies that survived were the ones at Demon and unixarchive
which contained additional materials but lacked the original release message.
The problem composited when some German? company bought the rights to the
manual and started asking sites to take the mirrors down.
At the time, I remember I had lost my own copy (I'm still looking around on
old disks for it to see if I can recover that notice), but hadn't cared much
because of the existence of the main site. When that was wiped, the copies
at demon and tliquest begot prominence as the only remains. The notice lost
meant that some people started questioning it. Nowadays, some people is
trying to get it released again as open source with a clear statement
(see comp.os.coherent), Andrzej Popielewicz leading the initiative. It
seems all rights to Coherent reverted to Robert Swartz after MWC disappeared:
> On Mar 31, 8:10 pm, Oliver White <sil...(a)callysto.com> wrote:
>
> > On Mon, 26 Mar 2007 22:26:55 +0200, Markus E Leypold wrote:
> > > A bit difficult to get written permission from an entity that doesn't
> > > exist and Bob Swartz who wasn't really reachable for some time (and
> > > still seems not to be able to make up his mind on the question of a
> > > hobbyist license).
>
> > I was talking to Randall Howard a few days ago and he said that the
> > copyright was sold to Ron Lachman for $30 000. Apparently MWC never
> > bankrupted, simply was shut down because it was loosing too much money.
>
> There been a few posting about the status of the copyrights of
> Coherent and what the status of the assets of Mark Williams Company,
> perhaps I can clarify things.
>
> Mark Williams Company ceased operations and its assets became the
> property of its bank. These assets which included the copyrights to
> all Mark Williams Company's software were subsequently sold to
> Kinetech. I was the person who managed these assets for Kinetech.
> Early this year Kinetech sold all assets of Mark Williams to Open
> Coherent LLC. A company of which I am the manager. The copyrights in
> Coherent remain and are the property of Open Coherent LLC. At this
> point in time we are working on how to making Coherent more generally
> available and there should be more news on this shortly. If there are
> any questions about Coherent or its copyrights I would be happy to
> respond to them.
>
> Thanks,
>
> Robert Swartz
>
Problem is that I can find no trace of said company on Google or Yahoo.
Andrezj claims to have permission to distribute it for personal use, and
has an updated version, 4.2.10ap of the kernel.
He claims
> If You have purchased Coherent , You can of course still use it.
> Otherwise the only authorized(by the owner) versions of Coherent kernel
> can be legally downloaded(but not redistributed), but only for
> noncommercial use , from
>
> http://main2.amu.edu.pl/~apopiele/embed.html
>
> There You will find
> a)rescue floppy package for those , who have problems with installing
> their Coherent 4.2.10 on newer systems
> b) patched (by me) Coherent 4.2.10ap kernel, with support for 64/128MB
> RAM. Originally Coherent 4.2.x supports 16 MB only
>
> Of course You can download legally GNU/GPL/Xfree stuff from
> http://www.tuhs.org , for example X-windows 1.2 or gcc 2.56 etc, which
> was once available for free download from MWC.
> As far as sources/binaries of Coherent available at tuhs, well I do not
> know. The owner knows about it, but he did not comment.
>
> The last sold version of Coherent was 4.2.12. The version 4.2.14 was in
> development phase.
>
> OpenCoherent license is in preparation, but I cannot estimate how long
> will it take.
>
> Andrzej
>
The notice remaining on demon is dated 1995, and things had changed a lot
in one decade:
From Aaron Swartz site (http://www.aaaronsw.com/history/2001) I see
> Sites I Host
>
> * ChicagoForce.org - Star Wars fans unite!
> * OpenCoherent.com - YAOSOS (Yet Another Open-Source Operating System).
> * SwartzFam.com - The Swartz Family Server.
Which supports my memories of Coherent having been released as Open Source.
The Internet Archive contains only two pages of opencoherent.com dated Apr
22, 2001 and May 18, 2001, but both of them contain only
> OpenCoherent
> Coming Soon!
Again, that would point that as early as 2001 the Swartzs were already
intending to open source Coherent, and would justify my memories of an
actual open sourcing notice in ftp.mayn.de but until (if) I can find that
announcement I should suspect my memory.
So, you are on your own, free to guess as much as anyone else. Bob Swartz
or Open Coherent LLC are certainly elusive. That much I could find. I'll
keep on digging if I have time. Personally, I don't quite see any of this
clear at all, but you know, having been a system manager for decades makes
one paranoid.
j
--
These opinions are mine and only mine. Hey man, I saw them first!
José R. Valverde
De nada sirve la Inteligencia Artificial cuando falta la Natural
Hi all,
I just had a try to install Coherent on qemu (once more), and this time
it did work. Formerly it would fail during installation complaining about floppy
disks being unavailable, no root device or some other such error. Now it is
happily finishing configuration using qemu 0.9.1
So, for all of you nostalgics who wanted to have Coherent up and running
again, QEMU can finally run it since release 0.9.1. The distribution disks and
serial number for Coherent are available on a number of sites, as you may know.
j
--
These opinions are mine and only mine. Hey man, I saw them first!
José R. Valverde
De nada sirve la Inteligencia Artificial cuando falta la Natural
hi all,
The recent flurry of activity in early pre-C UNIX for an 11 with a
small memory got me back to working on my 11/05. So far I've
identified two nasty problems with the data paths board, the M7260.
One of the 8266 MUX chips looks like the plastic boiled and bubbled
and circuit board is discolored underneath it. I'd welcome both
sources for replacement chips and techniques for replacing it.
Additionally there's a lifted and broken trace on the non-component
side of the module near the F edge connector. Any sugestions for
repairing a damaged trace would be welcome.
Lastly, I'd just as soon use a DL11W in the 11/05 rather than go to
the trouble of setting up an external clock to feed the on board UART.
I can get both 9600 baud and RS232 from the DL11W instead of 2400 baud
current loop from the built-in interface. I haven't yet found the
jumpers to remove/install that would disable the built-in console
interface. There's also the LTC.
TIA,
Milo
--
Milo Velimirović, Unix Computer Network Administrator
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA 43 48 48 N 91 13 53 W
--
Unix: Where /etc/init is job #1.
Dear Oliver
Astounding work!
What reference source are you using for the reconstruction process?
I bet you are having a look at the source code for Plexis sys3 in the
TUHS archives, and comparing with the stock sysIII from SCO, right?
FWIW from the source trees from SCO and Plexis, the code layout was
arranged by CPU. I'd bet the WEGA authors had access so SysIII sources,
and if they'd gone through the pains to get it, then they might as
well got both -or perhaps Plexis, which should have been more easy
to get- to use as their codebase. So a comparison of both source
trees should yield useful insights from the differences between PDP11,
VAX and Z8000.
BTW, as I remember practice in the '80s it was not uncommon to write
source in C and then tweak the assembler produced by hand to gain some
extra efficiency or fixes. It is also possible that the authors resorted
to tricks (like casting an int parameter to char) to force the compiler
generate the code they wanted. You should also watch out for external or
global symbols. It is also possible that the system was compiled with a
different (may be earlier) version of the compiler that was later shipped.
If you can't get stock code to render the same asm then I'd bet for the
latest explanation (different compiler versions).
Other than that, you are doing an astounding work!
BTW, there are other Z8000 UNIX floating around. Maybe one of them will
shed some extra light.
> So my goal is now to get the kernel sources right now to make the
> neccessary changes to get TCP/IP running in the kernel. As you might
> think now this is not so easy as it sounds. The sources for some objects
> of the kernel survied over the time, but many are missing. I'm now
> sitting here since a month disassembling the original kernel object and
> writing the disassembled code back in C. I've started this by having lets
> say nearly-to-zero ASM knowldege and I'm making good progress. Not much
> is left, but from time to time the C files are not compiling to
> exactly the same object which is in the kernel. Some times other
> temporary registers are used for operations, or I can't get to the same C
> code doesn't matter of what I'm trying and so on. I'm trying to get 100%
> the same object to be 100% sure I have the same code the object was built
> with. The compiler on that system should be the same but of course I
> can't guarantee that for sure.
--
These opinions are mine and only mine. Hey man, I saw them first!
José R. Valverde
De nada sirve la Inteligencia Artificial cuando falta la Natural
Hi.
I'm reading TCP/IP Illustrated - for the first time; talk about slack! - and
noticed Stevens used BSD/386. I remember seeing in DDJ in the early '90s ads
for various software-plus-source from a Texas repackaging company, and they
had BSD/[386|i|OS] at various times for $1k.00.
That was then - this is now. Is it likely, or even possible, that BSDi the
company would be ready to consider BSD/386 and such early releases, legacy
that could be donated to TUHS? And if so, who should we contact, to ask?
Thanks
Wesley Parish
--
Clinersterton beademung, with all of love - RIP James Blish
-----
Gaul is quartered into three halves. Things which are
impossible are equal to each other. Guerrilla
warfare means up to their monkey tricks.
Extracts from "Schoolboy Howlers" - the collective wisdom
of the foolish.
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.
All Simh version 3.8-0 has been released by Bob Supnik. It now has all the
support that we need to run 1st Edition UNIX. In our Subversion repository,
I've updated the Readme file and the simh.cfg file to match the new simulator.
Cheers,
Warren
Hello.
Very interesting article from http://arstechnica.com here:
http://arstechnica.com/news.ars/post/20080501-deluded-sco-ceo-on-witness-st…
A quote from that article:
"Greg Jones, VP of Technology at Novell, was called as a witness. Jones
was asked if SCO ever told Novell that it would sue Linux users. He
said, "No, never that specific." When asked if SCO notified Novell under
the Asset Purchase Agreement Amendment 2 that it would enter into a
license with Microsoft, he said, "No."
Jones testified that SVRX code is in Solaris and that he had discovered
several cases of this. At that point, Novell entered into evidence at
least 21 examples of OpenSolaris code that had been taken from the SVRX
code base (one such example can be found on the OpenSolaris web site)
and re-licensed under Sun's open-source CDDL license.
He further testified that the agreement between SCO and Sun was
"extraordinary" in allowing a move from a proprietary license to an
open-source license, and if Novell had been asked, it would have
prevented SCO from entering into that agreement. He said the same thing
regarding the Microsoft agreement with SCO, as well as the agreement
between SCO and Computer Associates."
And then this pearl:
"SCO argues that it was not authorized to execute license agreements and
that interested third parties such as Sun and Microsoft should get their
money back, but it says that Novell is not entitled to hold the money in
the interim. If you purchased a license from SCO that was unauthorized,
the argument is that you'll need sue them to get it back. Since SCO is
currently in bankruptcy proceedings, that could be difficult."
------
Ain't it funny?
--
Pepe
pepe(a)naleco.com
With the successful restoration of Unix V1, I was thinking of other
operating systems that could be restored in a similar way. The most
historically significant would probably be CTSS. The SIMH IBM 7094
simulator has everything necessary to run CTSS implemented already,
although the CTSS-specific stuff is untested (since as far as I know,
nobody has booted CTSS in it yet) and may need some patching.
There are several tapes of listings (for almost all of the system), and
a few tapes of binaries (one with supervisor binaries, and one with
"standalone" utilities, but nothing with user-mode programs) available.
The listings need to be converted back into source that can be assembled
or compiled. Part of this can be done automatically (I have written some
dumb scripts to do this), but there will likely be quite a bit of manual
editing involved. There is nothing to be OCRed, since everything is on
magtapes.
Most of the source is either assembly or MAD (an Algol-58 dialect), with
a few files in AED (another Algol dialect, for which no compiler appears
to have survived). Restoring the assembler stuff should be easy (there
exists a cross-assembler which would work), but restoring the MAD stuff
will be a little bit harder. There is no cross-compiler for it (there is
a compiler that runs under IBSYS, but it is probably just for an IBSYS
target, and I'm not sure if anyone has even figured out how to run it).
The AED stuff will have to be rewritten in MAD (which shouldn't be
especially hard, since AED and MAD are somewhat similar). Only a few
non-essential programs are written in AED.
I think that all (or at least most of) the stuff required for booting is
written in assembler, so the best way to get it working would be get a
minimal system booting (I suspect all that is necessary is the
supervisor, so the binaries on the tape might be of use), and run the
CTSS MAD compiler under it to compile all the MAD stuff (which includes
many of the "core" commands).
I'm not sure what the best way to get stuff into a filesystem is. The
standalone utilities run under FMS, and there is no bootable FMS tape.
There is a version of FMS that runs under IBSYS, but for some reason, it
returns an error when attempting to load the utilities off the tape.
It is probably possible to patch it to fix that bug, though. It would
also work to write utilities that run on the host system, much like what
was done for Unix V1 (although I think that fixing the bug in FMS would
probably be easier).
Maybe I should start a Sourceforge project.
Another, much simpler, system which might be possible to restore is
MUMPS-15, for which a PDF of a paper listing is available on bitsavers.
Restoring it would probably just be a matter of OCRing, correcting, and
assembling it (and maybe writing a bootstrap).
Hi,
while creating a web-page about the open questions of how to create C
code which compiles through the optimizer run to the same ASM code as the
original object was made from, I found the fix for one of my two "top"
questions.
The (right now) remaining question is here:
http://pofo.de/P8000/problems.php
The other (solved) problem was:
I had the following ASM code:
ldk r2,#0
ldb rl2,_u+1060
ld r3,r2
neg r3
add r3,#256
ldb rh3,rl3
clrb rl3
ld _u+48,r3
so i created the following C code out of it:
u.u_count = (-u.u_segmts[NUSEGS-1].sg_limit+0x100)<<8;
but this compiled to this ASM code:
ldk r2,#0
ldb rl2,_u+1060
neg r2
add r2,#256
ldb rh2,rl2
clrb rl2
ld _u+48,r2
As you can see the copy of r2 to r3 and the further processing with r3 is
missing here. I also thought "who the fuck would write such an C-code,
the code must look different". but I did not found the solution what
could have been written in the C code until I've talked today with a
colleague of mine at work about ASM and my problems. He isn't familar
with Z80(00)-ASM but he used to program ASM years ago with his C64. We
took the ASM code and simulated it with values:
_u+1060 contains 15 and is loaded to rl2 15 (0x000F / 00000000 00001111)
this gets negated (2 complement formed) -15 (0xFFF1 / 11111111 11110001)
to that, 256 gets added 241 (0x00F1 / 00000000 11110001)
this is 8 bit rightshiftet 61696 (0xF100 / 11110001 00000000)
the result gets loaded into _u+48
He then got the idea that all this could be aritmetical written
as ((256 - 15)*256) because -15+256 is == 256-15 and rightshifts are done
aritmetically by multiplying the value with 256. It could have also been
done by having 256² - 256*x. This was great. With that information I wrote
in C:
u.u_count = (256-u.u_segmts[NUSEGS-1].sg_limit)<<8;
And this generated the same ASM code as in the original code
problem solved :)
--
Oliver Lehmann
http://www.pofo.de/http://wishlist.ans-netz.de/
Hi everybody,
I don't know if it's usual or not to write an introduction but I'll just
do so by keeping more an eye on the computer system I own.
If you don't care just skip this mail ;)
As my From header states my name is Oliver, I live in germany and right
now I'm 27 years old. That should be enough to my person - now let me
tell you a bit more about the computer system I own ;)
EAW P8000
This system was built between 1987 and the breakdown of the former GDR -
the eastern part of germany - 1990. The system itself is split up into
two "towers" connected together. The first tower called "P8000 Computer"
contains a 8Bit system (Z80) and a 16Bit system (Z8001).The 2nd case -
the "P8000 Winchester" - contains a Winchester Disc Controller which runs
with a Z80 CPU and is connected to the 16Bit part of the "P8000
Computer". Up to three MFM drives (all with the same geometry while the
geometry itself can be configured) can be connected to the WDC.
The 8Bit part is built on a single board, has 64KB SRAM, 2 SIOs to
connect up to 4 terminals to it, one PIO to connect a EPROM programmer,
and one PIO to establish a connection to the 16Bit part. It has 2 5.25"
floppy drives with an external connector to connect two further 5.25" or
8" floppy drives. The systemmonitor is loaded from two 2732 EPROMs.
The system originally supported three operating systems while two
survived the time being. I own UDOS which is a Z80-RIO clone and OS/M
which is a CP/M clone. There also was an OS called IS/M which was an ISIS
clone.
The more interesting (at least for me) part is the 16Bit part. The 16Bit
part is built on a single board too (6layer) while the DRAM are single
board which can be hooked up onto the mainboard.
The system runs a Z8001 with 3 MMUs and Z80-peripherial ICs (PIO, SIO...)
It also has 2 SIOs for 4 terminal connections, and one PIO to connect the
WDC. The system also has two furhter PIO chips to establish a connection
to the 8Bit system. The system runs with up to 4MB of DRAM but it might
run with more RAM with self-made RAM modules. There exists also a RTC for
the system and an extension to connect an 80286CPU + 1MBRAM to the 16BIT
port to run a x86 OS on it while stearing it from the OS running on the
16Bit system.
The Operating-System running on the 16Bit part is WEGA - a ZiLOG ZEUS
clone.
To boot WEGA at first the 8Bit system has to be booted up with UDOS (the
Z80-RIO clone) to load a communication software which handles the
communication over the 8Bit-PIO. After this is done the system switches
over to the 16Bit system and the system monitor there gets loaded. The
WEGA-Kernel (most parts are still original ZEUS objects) itself has the
corresponding part for the 8<->16Bit communication interface in it.
This was done to get access to the floppy drives, the EPROM programmer
and the 4 8Bit-terminal connections which are all connected to the Z80
on the 8Bit-system.
To access for example a floppy, the WEGA-kernel has to send the request
using the PIO connection to the 8Bit system which handles it and sends
the results back to the WEGA-kernel on the 16 Bit system. Same goes with
the WDC which is connected through another PIO directly to the 16Bit
system - command codes are sent to the Z80 on the WDC which handles the
codes and sends the results back to the 16Bit system. Not that fast but
it works good.
Pictures and so one are all collected on my homepage
http://pofo.de/P8000/ while most (if not to say all) of original
documents are written in german...
So - what do I do with the system? I use it for learn more about hardware
processes itself, assembler and to get a deeper UNIX knowledge which is
easier to start with there then with todays UNIX systems.
Las project was to get TCP/IP working and I successed by usingg K5JB to
get FTP and ping to work via SLIP. Because the speed was damn slow (and
not just because of the baud rate), I came to the conclusion that a
better performance could be achieved by implementing TCP/IP in the
kernelspace instead of having it run in the userspace.
So my goal is now to get the kernel sources right now to make the
neccessary changes to get TCP/IP running in the kernel. As you might
think now this is not so easy as it sounds. The sources for some objects
of the kernel survied over the time, but many are missing. I'm now
sitting here since a month disassembling the original kernel object and
writing the disassembled code back in C. I've started this by having lets
say nearly-to-zero ASM knowldege and I'm making good progress. Not much
is left, but from time to time the C files are not compiling to
exactly the same object which is in the kernel. Some times other
temporary registers are used for operations, or I can't get to the same C
code doesn't matter of what I'm trying and so on. I'm trying to get 100%
the same object to be 100% sure I have the same code the object was built
with. The compiler on that system should be the same but of course I
can't guarantee that for sure.
I'll put a web page together with my open C<->ASM questions because I
think I can format things better there so asking and reading would be
easier (probably because it is a lot of text)
My progess can be seen here: http://pofo.de/P8000/kernel.php
And the sources I got so far are here:
http://cvs.laladev.org/index.html/WEGA/src/uts/
I hope you can help me a bit with answering the things I can't find an
answer myself ;)
--
Oliver Lehmann
http://www.pofo.de/http://wishlist.ans-netz.de/
Working with the 1st Edition UNIX code has been a blast. I just thought I'd
quickly summarise the features of the 1st Edition. It's quite amazing the
system that had been written by the end of 1971:
- a multitasking system with up to 16 processes
- multiple users
- a hierachical filesystem, with empty directories used as mountpoints
- read/write file protection for user/other (no group), plus the
execute and set-userid bits
- i-nodes, and filenames separated from i-nodes, allowing hard links
- device files
Just as interesting is the fact that, out of the 33 system calls in 1st
Edition UNIX, only one has disappeared completely from modern UNIXes;
four have merged into signal(), and a few have morphed into other syscalls:
V1_RELE 0 /* release the CPU, i.e. pre-empt this process */
V1_EXIT 1 exit()
V1_FORK 2 fork()
V1_READ 3 read()
V1_WRITE 4 write()
V1_OPEN 5 open()
V1_CLOSE 6 close()
V1_WAIT 7 wait()
V1_CREAT 8 open(path, O_CREAT | O_TRUNC | O_WRONLY, mode);
V1_LINK 9 link()
V1_UNLINK 10 unlink()
V1_EXEC 11 exec()
V1_CHDIR 12 chdir()
V1_TIME 13 gettimeofday()
V1_MKDIR 14 mkdir()
V1_CHMOD 15 chmod()
V1_CHOWN 16 chown()
V1_BREAK 17 brk()
V1_STAT 18 stat()
V1_SEEK 19 lseek()
V1_TELL 20 lseek(fd, 0, SEEK_CUR);
V1_MOUNT 21 mount()
V1_UMOUNT 22 umount()
V1_SETUID 23 setuid()
V1_GETUID 24 getuid()
V1_STIME 25 settimeofday()
V1_QUIT 26 signal(SIGQUIT,...)
V1_INTR 27 signal(SIGINT,...)
V1_FSTAT 28 fstat()
V1_CEMT 29 signal(SIGEMT,...)
V1_SMDATE 30 utimes()
V1_STTY 31 fcntl(), tcsetattr()
V1_GTTY 32 fcntl(), tcgetattr()
V1_ILGINS 33 signal(SIGILL,...)
The fact that we are still using these system calls today speaks volumes
for the original design.
Cheers,
Warren
Seen in a .sig:
Unix is the answer, but only if you phrase the question very carefully.
--
Milo Velimirović
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA 43 48 48 N 91 13 53 W
> Date: Thu, 22 May 2008 18:10:33 +0200
> From: "Jose R. Valverde" <jrvalverde(a)acm.org>
> Subject: Re: [TUHS] V8 - V10
>
> Solaris has been open sourced and is heavily System V based. Novell
> argues now SCO was not entitled to, and so the Sun-SCO agreement that made it
> possible is probably void.
>
> [...]
> There remains the issue of the flow of SystemV licenses money to Novell
> after and if it is open sourced... I don't know how much that is, nor how much
> it might be 4-10 years from now when the SCO appeals are heard. So my evaluation
> is probably faulty.
I concur with your opinion.
If Novell could not get paid from The SCO Group of the percentage (about
90%) they are entitled to of the SVRX License Payment SUN made to The SCO
Group, and of the SVRX License Payment Microsoft made to The SCO Group
(because, you know, The SCO Group has filled for bankruptcy), then they are
probably going to action on the basis of said Licenses being void, or at
least in being void the part of such Licenses that allows to Sub-license
the material changing the terms of the License, or changing the License
altogether. According to this hypothesis on the future, in case The SCO
Group cannot find the money to pay Novell, Novell will probably try to
renegotiate such Licenses directly with SUN and Microsoft. Microsoft
will probably just return the material instead of paying for it (as they
don't need it), but SUN is in a totally different position.
SUN has now OpenSolaris, which was made possible by that License they got
from The SCO Group. So SUN will renegotiate and pay Novell to legalize
the SVRX License they got from The SCO Group which allowed them to
"open-source" Solaris.
Only after Novell gets that payment(s), either from The SCO Group or
SUN, will they consider "open-sourcing" the historical SVRX and
classical UNIX code. Otherwise, they could hardly monetize on it, as
they currently have the opportunity to do.
Regards,
--
Pepe
pepe(a)naleco.com
My take on this is multiple:
If I remember well from IBM vs. SCO the agreements between IBM and alike
and AT&T stated that the code was to be kept confidential but that if a third
party did release it, the licensees would no longer be bound by that restriction.
Solaris has been open sourced and is heavily System V based. Novell
argues now SCO was not entitled to, and so the Sun-SCO agreement that made it
possible is probably void.
Novell is now engaged against SCO. Once that is over, they'll have to
look at the Sun and MS agreements. My take on this is that they will renegotiate.
In the case of Sun there is no longer sense in asking for the code to be closed.
It's in the open now and has been for a long time. If I were Novell, I would
negotiate in a oblique direction: Solaris _may_ pose a competing threat to Novell
Linux business... arguably. Sun is interested in making Solaris GPL. If it were,
then Novell would have no standpoint against Sun as it would make no difference
then for them to use either Linux or Solaris, both being equally available and
third-party originated under the same license. Going after Solaris would give
them a very bad reputation among OSS followers. Thus, what would make more sense
would be to negotiate with Sun and ask for some more money in exchange for
dropping any charges and Solaris becoming GPL. Everybody wins and everybody is
happy.
Should it go that way, and probably only afterward, Novell may consider
opening up System V under an OSS license, as most of it would have been rendered
obsolete by OSS Solaris. It would also increase Novell's reputation and clear
this mess forever. Hopefully by the time this happens (counting on SCO or their
successors to appeal the Utah decision), maybe 10 years from now, System V will
have become as irrelevant -commercially I mean- as e. g. UNIX v5 is now while
historical interest and value will have raised after several years of TUHS
applying moderate pressure ;-) It would also be the time to ask IBM to release
the code for AIX and DYNIX (which is already in the wild according to
soothsayers), HP to open Tru64 (same and which they insist on phasing out),
etc...
There remains the issue of the flow of SystemV licenses money to Novell
after and if it is open sourced... I don't know how much that is, nor how much
it might be 4-10 years from now when the SCO appeals are heard. So my evaluation
is probably faulty.
Oh, well, I woke up in a dreamy mood today! :-)
j
--
These opinions are mine and only mine. Hey man, I saw them first!
José R. Valverde
De nada sirve la Inteligencia Artificial cuando falta la Natural
> From: Aharon Robbins <arnold(a)skeeve.com>
>
> Is the SCO "stuff" settled enough that DMR can release V8 - V10 to TUHS?
It seems clear, now, that the copyright on that is Novell's, and that
The SCO Group *never* had the copyright for that transferred to them by
Novell, and that therefore the "open-sourcing" of that material done by
Caldera is void because Caldera was lacking just title to do such
re-licensing.
Therefore, you can legally release it to TUHS, provided you have a license or
permission from Novell to do so.
You could always release it anyway, and hope for the best, but then you
are on your own and betting for your luck. Anything could happen, but it
is unknown.
--
Pepe
pepe(a)naleco.com
Yow. I didn't expect such a flurry of legalese when I asked the question.
> Date: Wed, 21 May 2008 17:54:41 -0700
> From: lm(a)bitmover.com (Larry McVoy)
> Subject: Re: [TUHS] V8 - V10?
> To: Pepe <pepe(a)naleco.com>
> Cc: tuhs(a)minnie.tuhs.org
>
> > Therefore, only Novell can "open-source" V8 - V10, which is the point
> > being discussed here, and Caldera had no title to do it.
I hadn't kept up, so this was an interesting surprise. At least we know
more or less what's going on now.
> Has anyone asked Novell?
Indeed. Do we even know who to ask there?
Thanks,
Arnold
I was just browsing through the 1974 UNIX CACM paper, the one that first
publicly described the design and functionality of UNIX. I came across
some sentences which describe the file permissions, and they sounded quite odd:
When a file is created, it is marked with the user ID of its owner.
Also given for new files is a set of seven protection bits.
Six of these specify independently read, write, and execute permission
for the owner of the file and for all other users. [The seventh bit
is the set-user-id bit. ]
This seems to indicate that there are "rwx" bits for owner, "rwx" bits for other,
and no "rwx" bits for group. I've never seen a UNIX system with 6 file
permission bits, so I thought I would poke around to see what I could find. It
turns out that none of the source code or document artifacts that we have
describe a UNIX system with just 6 "rwxrwx" bits: there are either "rw" user,
"rw" other and a separate execute bit, or the modern 9 "rwxrwxrwx" permission
bits.
1st Edition UNIX (Nov 1971) has these permission bits for an i-node:
#define I_SETUID 0000040 set-user-id
#define I_EXEC 0000020 a single execute bit
#define I_UREAD 0000010
#define I_UWRITE 0000004 read/write for user
#define I_OREAD 0000002
#define I_OWRITE 0000001 read/write for other
3rd Edition UNIX (Feb 1973) has these permission bits for an i-node:
000040 set user ID on execution
000020 executable
000010 read, owner
000004 write, owner
000002 read, non-owner
000001 write, non-owner i.e same as for 1st Edition
By the time we get to the Nsys kernel (Aug 1973, just before 4th Edition UNIX),
the system has the concept of groups and the setgid() & getgid() system calls.
The inode.h header file defines these permission bits:
#define ISUID 04000
#define ISGID 02000
#define IREAD 0400
#define IWRITE 0200
#define IEXEC 0100
This is a bit unclear, but the code for the access() kernel function implies
that there are read/write/execute bits for user, group and other. Here is the
code for access() with my comments:
/* Determine if the current user can access a file with the given mode */
access(ip, mode)
int *ip;
{
register *rip;
if(u.u_uid == 0) /* root can access all files */
return(0);
rip = ip;
if(u.u_uid != rip->i_uid) { /* not owner, shift mode 3 bits, lose */
mode =>> 3; /* user bits, replace with group bits */
if(u.u_gid != rip->i_gid) /* not group, shift 3 again, lose */
mode =>> 3; /* group bits, replace with other bits */
}
if((rip->i_mode&mode) != 0) /* If mode mask and file's mode leave */
return(0); /* some bits enabled, allow access */
u.u_error = EACCES;
return(1);
}
And when we get to the 4th Edition (Nov 1973), the filesystem manual gives
these permissions:
000400 read (owner)
000200 write (owner)
000100 execute (owner)
000070 read, write, execute (group)
000007 read, write, execute (others)
So, editions up to the 3rd Edition had "rwrw" + "x"; the Nsys kernel and
onwards had "rwxrwxrwx" permission bits.
The only possibility that I can see is, as 3rd Edition was being rewritten
from assembly into C, the filesystem went through a stage where there
"rwx" execute bits for user, and "rxw" execute bits for other as the CACM
paper described, but groups had not been introduced yet. Then, the idea of
groups was added: the i-node structure had the i_gid field added, and the
access() function was extended with the lines:
if(u.u_gid != rip->i_gid) /* not group, shift 3 again, lose */
mode =>> 3; /* group bits, replace with other bits */
I'll have to ask Dennis is this sounds plausible.
Cheers,
Warren
For fun, I tried building the kernel under V1 and booting it and it
looks like it simply works.
I did the following, outside the simulator:
tools/assemv2
mkdir fs/usr/kernel
cp -pi build/u?.s fs/usr/kernel
tools/imgbuild
boot/installboot
tools/pdp11 boot/simh.cfg
Then, I logged in as root and did:
chdir /usr/kernel
as u?.s
chdir ../boot
sh run
msys2 u ../kernel/a.out
More realistically, the kernel should be built in /usr/sys.
James Markevitch
All work and no play...
Here's a fun hack for first edition unix. From MAIL (I) :
When followed by the names of a letter and one or more people, the
letter is appended to each person's mailbox. Each letter is
preceded by the sender's name and a postmark.
A person is either the nameof an entry in the directory /usr, in
which case the mail is sent to /usr/person/mailbox, or the path
of a directory, in which case mailbox in that directory is used.
Mail is setuid root:
# ls -l /bin/mail
80 surwr- 1 root 3940 Jan 1 00:00:00 mail
login as a non-root user (ie "bin"), create a file "letter" with the
contents "hack::0:/:". Run:
@ ln /etc/passwd /tmp/mailbox
@ mail letter /tmp
log out and log back in as "hack". You are now root. Cat /etc/passwd
and notice:
From bin Jan 1 00:49:22
hack::0:/:
clean up the file a little and enjoy your new elevated status.
Tim Newsham
http://www.thenewsh.com/~newsham/
On Sun, May 18, 2008 at 03:40:05PM +0200, Magnus Danielson wrote:
> Warren!
> Thanks for a couple of interesting posts!!!
> Makes me want to read some source... you seems to have it at hand.
> Where is it?
Most of it is here:
http://www.tuhs.org/Archive/PDP-11/Distributions/research/
which includes source for 5th, 6th and 7th Editions, and a kernel
written just before 4th Edition. We don't have 2nd, 3rd, or 4th Edition
source, but the 3rd and 4th Edition manuals are in there.
The source to the 1st Edition UNIX kernel has recently been found in
a paper document, available at
http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Prelim….
Cheers,
Warren
For fun, I tried building the kernel under V1 and booting it and it
looks like it simply works.
I did the following, outside the simulator:
tools/assemv2
mkdir fs/usr/kernel
cp -pi build/u?.s fs/usr/kernel
tools/imgbuild
boot/installboot
tools/pdp11 boot/simh.cfg
Then, I logged in as root and did:
chdir /usr/kernel
as u?.s
chdir ../boot
sh run
msys2 u ../kernel/a.out
More realistically, the kernel should be built in /usr/sys.
James Markevitch
While I'm investigating the legacy of the UNIX syscalls, I might as well
go into the later versions.
2nd Edition UNIX kept all the syscalls of 1st Edition, and added these:
34 hog lower process priority, becomes nice()
35 sleep sleep()
36 sync sync()
37 kill kill()
38 getcsw reads console switches: this goes away in 7th Edition
3rd Edition UNIX kept all the syscalls of 2nd Edition, and added these:
39 boot reboot the system, becomes reboot()
40 fpe catch floting point errors, becomes signal(SIGFPE, ...)
41 dup dup()
42 pipe pipe()
43 times get process time details, becomes getrusage()
Note pipe() appears in the 3rd Edition, which was still in assembly.
4th Edition UNIX is the first kernel written in C. We start to see changes:
14 mknod was mkdir(), now can make directories and device files
34 nice was hog()
20 tell goes away, as seek() does the same job
44 profil profil()
45 tiu interface to Spider digital switching network: goes away
46 setgid setgid()
47 getgid getgid()
48 signal signal()
It's interesting to note that signal() appears, but the existing signal-like
syscalls do not disappear just yet, although tell() does go away. It's also
to note that seek() has the usual 0=SEEK_SET, 1=SEEK_CUR, 2=SEEK_END, but
there are also 3, 4, 5 which mean the same except that offsets are multiplied
by 512 bytes. This is to do long seeks on block devices. Earlier UNIX kernels
automatically multiplied offsets on block devices by 512, but now the task
of doing this has been shifted to the process.
In 5th Edition, we see some more changes:
20 getpid getpid(), fills the slot vacated by tell()
26 quit goes away to be replaced with signal(SIGQUIT, ...)
27 intr goes away to be replaced with signal(SIGINT, ...)
29 cemt goes away to be replaced with signal(SIGEMT, ...)
33 ilgins goes away to be replaced with signal(SIGILL, ...)
39 boot goes away
40 fpe goes away to be replaced with signal(SIGFPE, ...)
45 tiu goes away
6th Edition has few changes over 5th Edition:
26 ptrace ptrace(), fills the slot vacated by quit()
30 smdate becomes inoperative
7th Edition has some significant changes over 6th Edition:
27 alarm alarm(), fills the slot vacated by intr()
29 pause pause(), fills the slot vacated by cemt()
30 utime utime(), replaces the missing smdate()
33 access access(), fills the slot vacated by ilgins()
35 ftime get date and time, later becomes gettimeofday()
38 getcsw goes away
39 setpgrp setpgrp(), but not yet implemented, i.e. reserved slot
49 unused
50 unused
51 sysacct turn accounting off/on
52 sysphys set user physical addresses
53 syslock lock user in core
54 ioctl ioctl()
55 unused
56 mpxchan create mpx communications channel
57 unused
58 unused
59 exece execve(), note that existing syscall 11 exec() has no envp[]
60 umask umask()
61 chroot chroot()
Note that 35 sleep() is now gone, as its functionality can be simulated with
27 alarm().
Cheers,
Warren
> > For building under UNIX itself, there are a variety of strategies. Here
> > is my list, in order of preference:
> >
> > 2. Modify the V2 assembler to produce V1 binaries.
>
> I'm going to take a "devil's advocate" stance here, and argue to keep the
> existing "as" binary untouched.
In any event, the msys2.s will work to install a V2-assembled kernel
into the boot area.
I've sent a new copy of the boot directory and fs/usr/boot to Warren and
Tim to install. msys2.s is now the program to use to install the bootstrap
and the fs/usr/boot/unix.out file is a copy of build/a.out.
This means that if the kernel is assembled using the V2 assembler under
UNIX V1 itself, then the a.out from that assembly can be used directly
by msys2 to install into the boot area.
James Markevitch
