HDTenEightyP/NetNews huggingface dataset:
From: ulma@coli.uni-sb.de (Ulrich Mayring)
Newsgroups: comp.fonts
Subject: Re: Why Unicode is 16-bit
Date: 11 Sep 92 19:14:29 GMT
Organization: U of Saarbruecken, Dept. of Computational Linguistics

ulma@coli.uni-sb.de (Ulrich Mayring) writes:

>glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) writes:


>>  In article <1992Sep6.222220.14143@coli.uni-sb.de> ulma@coli.uni-sb.de (Ulrich Mayring) writes:

>>  >Then why not go on to 32 bit? It would come a lot closer to including ALL
>>  >characters of ALL languages. (BTW does anybody know if 32 bit would suffice
>>  >or would we need still more? Assuming we only wanted to include spoken
>>  >languages, not dead ones)

>>32-bits are *not* needed, 16-bits suffices for representing the primary
>>content of *all* languages, both modern and archaic.  Of course, 32-bits
>>might be useful for glyph encodings; but Unicode doesn't encode glyphs.

>Well, 16 bits are 32768 different characters. Now, I always thought that
>Chinese alone had over 40000 characters, however only a fraction is taught
>in school and even less necessary to write basic Chinese. Does UNICODE
>include only these or is the "40000" number wrong?

Well, I'll answer my own question: Chance has it that 16 bit is 32768 only
signed. Unsigned it is of course 65536. Obviously Unicode is unsigned.
Well, that comes from thinking in signed categories without being aware that
it is a simplification imposed upon the user mostly by the operating systems.
Thanks to the people who pointed me to it. They also said that Unicode in-
cludes some 22000 characters of these 40000, if that is the correct number.

Now, after all that criticism: I would LOVE it, if Unicode became standard,
because I rely heavily on ASCII and Unicode obviously would be an enormous
improvement over ASCII.


     Ulrich Mayring
     volksdesign.

       - Man muss schon sehr genau hinhoeren -
From: a036450@rd821.UUCP (Bob Goldrich)
Newsgroups: comp.fonts
Subject: Dingbats Copyrightable?
Date: 14 Sep 92 12:24:52 GMT
Organization: The Gleason Works, Rochester New York
X-Newsreader: Tin 1.1 PL4

It seems to be a general consensus that, as of now, in the United 
States typefaces are not protected under Copyright law.  Would this
include Dingbat fonts?  It would seem to me that this law would not
cover Dingbats because they don't really constitute an alphabet.

How about the legality of reproducing some simple clip art in a 
Dingbat font?  Is there any legal precedent on this matter?

	             Bob Goldrich    a036450@rd821.gleason.com
From: walver@kielo.uta.fi (Ville V. Walveranta)
Newsgroups: comp.fonts
Subject: Re: Star Trek font?
Date: 6 Sep 92 02:26:40 GMT
Reply-To: walver@uta.fi (Ville Walveranta)
Organization: University of Tampere, Finland
In-reply-to: yefchak@hplred.HP.COM's message of 22 Aug 92 00:44:35 GMT


	Ooops... forgot the contact information to "Computer Safari":

	Computer Safari
	353 W.Main St., Suite K
	Woodland, CA  95695

	PH    (800) 824-2547
	PH/FX (916) 666-1813

	-- Willy
--

 ***********************************************************************
  ***   Ville V. Walveranta      Tel/Fax.....: (510) 420-0729       ***
   ***  96 Linda Ave., Apt. #5   From Finland: 990-1-510-420-0729  ***
    *** Oakland, CA  94611, USA  (FAXes automatically recognized) ***
   ***                                                             ***  
  ***   Email: walver@uta.fi     "Do you want to escape?"           ***
 ***********************************************************************
Newsgroups: comp.fonts
From: dmandl@bilbo.shearson.com (David Mandl)
Subject: Re: Books for beginners
Organization: Lehman Brothers
Date: Tue, 8 Sep 1992 14:48:48 GMT

It's definitely not a lightweight beginner's introduction, but
I've found

Better Type, by Betty Binns

to be indispensible.  It's a large-format hardcover, but you can
find it remaindered for cheap if you look around.  The book goes
into great detail about how factors like line spacing, line length,
point size, and design of typeface (evenness of stroke weight,
x-height, etc.) affect readability.  When you've gotten the basics
out of the way and want to learn more about the fine nuances of
type color, this book is an absolute must.

   --Dave.

--
---------------------------------------------------------------
         Dave Mandl            |    Opinions expressed here
       New York City           | are not those of my employer,
 (dmandl@bilbo.shearson.com)   |          believe me.
---------------------------------------------------------------
Newsgroups: comp.fonts
From: c9101548@cc.newcastle.edu.au
Subject: Attn Non U.S. Mac owners
Organization: University of Newcastle, AUSTRALIA
Date: Fri, 11 Sep 1992 00:26:55 GMT

While as I understand it fonts converted to truetype
from other formats, may be illegal in the US,
Australian law does not specifically prohibit
font convertion. Therefore if the source fonts are
freeware any convertion of them will be also.
So as a service to non US Mac users, I've
uploaded about 40 truetype fonts converted from their
windows counterpart to the Australian site
sorokin.anu.edu.au in the pub/truetypes directory
with the permission of Gavin Longmuir the archivist.

- Justin Fitzgibbon
Newsgroups: comp.fonts
From: dhosek@lucy.claremont.edu
Subject: Re: URW Font CD-ROM
Organization: Harvey Mudd College
Date: 10 Sep 92 10:38:20 PDT

In article <1347000018@igc.apc.org>, pfraterdeus@igc.apc.org (Peter Fraterdeus) writes:
> ... The fonts
> they're selling are Postscript translations of the original IKARUS database
> that the fonts were originally digitzed to. These are NOT knock offs! However,
> the deal is not as good as it looks (though almost). The 3000 fonts are
> actually 500 fonts with 5  additional variations on each. So instead of $0.30
> per font it's really more like $1.79 a font.....
> (Plus Inline, Outline, Relief, Shadow, and round cornered verisons of each...)
> Basically, they are taking advantage of the broadening of the type market to
> pull the rug out from under alot of the other discount vendors.

Well, now the price isn't so competitive. The Monotype CD runs
around $3000 unlocked and considering that it really has 2000
fonts, you're looking at a lower cost per font. Adobe and NEC's
CDs are comparably priced unlocked. The big advantage that URW
gives is a lower entry cost. On the other hand, does URW have a
commitment to expanding their library and maintaining current
owners of their CD? I know both Adobe and Monotype do, meaning
that if you buy their CD, you'll periodically get an update CD
with the newest additions (I think Monotype even does it for
free).

But of course, in practice one doesn't use these astronomically
large numbers of fonts and except for print shops, I'd guess that
unlocked font CDs are difficult to justify economically (From
where I stand, I'd need to get 45 usable faces off the disk to
justify the cost of the URW CD.)

-dh
Newsgroups: comp.fonts
From: dhosek@cbrown.claremont.edu
Subject: Re: URW Font CD-ROM
Organization: Harvey Mudd College
Date: 4 Sep 92 19:06:32 PDT

In article <Bu2AMB.LtI@vcd.hp.com>, Carl Peterson <carlp@hp-vanc.hp.com> writes:
>   I have before me a short article about a CD-ROM
> offered by the German type foundry URW called
> TypeWorks.  The CD-ROM is supposed to contain
> a collection of some 3,000 Type 1 fonts, all
> unlocked, for a reasonable price.

Fonts are the one place where price almost always equates to
quality. Anything in the font world that's cheap is almost always
a knock-off version. Yes, in most countries it's legal to steal
fonts, but that doesn't necessarily make it right. Plus it's very
rare that the quality of a knock-off will be comparable to a font
licensed from the designer.

If you want inexpensive fonts, get the Monotype FoneFonts CD
($50) and buy your unlocking from Publisher's Toolbox in
Wisconsin (last I checked they charged $20/font to unlock). Then
you get high quality fonts (the full Monotype and Adobe
libraries) for a good price. Not to mention that Monotype has
most of the best designs (if you see a version of a font from
Monotype and a version from somebody else, get the Monotype
version).

-dh

Don Hosek                  
dhosek@ymir.claremont.edu  
Quixote Digital Typography 
714-621-1291
From: abnous@cory.Berkeley.EDU (Arthur Abnous)
Subject: Windows 3.1 fonts for DOS boxes
Organization: University of California, at Berkeley
Distribution: usa
Date: Tue, 15 Sep 1992 05:47:32 GMT


In Windows 3.1, how are the fonts used for DOS boxes different from
the other fonts? How does one go about creating more fonts for use
in DOS boxes? I would greatly appreciate any info.

Thank you,

Arthur Abnous

Newsgroups: comp.fonts
From: hennesse@chemdept.chem.ncsu.edu (Glenn Hennesse)
Subject: Allotype Typegraphics
Keywords: allotype
Organization: Chemistry Department, North Carolina State University
Date: Wed, 9 Sep 1992 20:15:31 GMT

Does anyone know if Allotype Typegraphics is still in business?  I have not 
been able to find any mention of them in any location.  The reason I am 
looking for them is that they had a font called SciTimes or Scientific Times 
which had a feature of having bars over the letters like:
  _
  A.
Thanks for your help.
Glenn Hennessee
Box 8204
Department of Chemistry
North Carolina State University              "It's hard to work in a group
(919) 515-2947                                when you're omnipotent." --Q 
Glenn_Hennessee@ncsu.edu
Newsgroups: comp.sw.components
From: yossi@mcil.comm.mot.com (Yossi Cohen-Shahar)
Subject: Guidelines for writing reusable C and Assembly code.
Organization: Motorola Communications Israel Ltd., Tel Aviv
Date: Wed, 9 Sep 1992 15:16:22 GMT

I'm a member in a Software Reuse Committee of 
Motorola Communications Israel.

Our committee has started its work a year ago.
We have established an organization reuse database, 
rewarding program to engineers for encouraging 
software reuse and we have invested in increasing the
awareness to it as well.

As part of establishing the software reuse we are also 
writing a "Software Reuse Handbook" for the software
managers and the software engineers. This handbook
contains information regarding the reuse process
and the use of the tools.

In order to complete this handbook, we are seeking 
for information / handbook / guidelines that describes
how to write C code and Assembly code in "reusable manner",
meaning how to write code in a way it would be easier
to reuse it in the future.

Thanks.



-- 
 _______________________________  ____________________________________ 
[                               ][                                    ]
[       Yossi Cohen-Shahar      ][ Internet: yossi@mcil.comm.mot.com  ]
[      Radio Products Group     ][ Post:     cyc001                   ]
[ Motorola Communications Israel][ Phone:    +972 (3) 565-8365 (UTC-2)]
[                               ][ Fax:      +972 (3) 565-8736        ]
[_______________________________][____________________________________]    
Newsgroups: comp.sw.components
From: peter@ferranti.com (peter da silva)
Subject: Re: Guidelines for writing reusable C and Assembly code.
Organization: Xenix Support, FICC
Date: Thu, 10 Sep 1992 18:04:15 GMT

In article <1992Sep9.151622.11062@lmpsbbs.comm.mot.com> yossi@mcil.comm.mot.com (Yossi Cohen-Shahar) writes:
> In order to complete this handbook, we are seeking 
> for information / handbook / guidelines that describes
> how to write C code and Assembly code in "reusable manner",
> meaning how to write code in a way it would be easier
> to reuse it in the future.

Ah! This is one of my hot buttons. I'm really upset about some of
the supposedly reusable code I've seen. It's usually way too application
specific or depends too much on other parts of an application to really
reuse it.

The main rules I use in designing code (or a tool) for reuse are:

	1.	How much can I generalize this without losing
		efficiency. For example, in a symbol table for
		a text based application I allowed the use of
		any arbitrary chunk of data in the target, rather
		than simply a text string.

	2.	How can I simplify the interface without losing
		efficiency. In the case of this symbol table, I
		only use four basic routines: create a symbol
		table, look up an entry, execute a subroutine for
		each element, and destroy a symbol table. Lookup
		automatically creates an entry if none exists,
		simplifying external code design: it's not hard to
		check explicitly, but it's something more to forget.

	3.	How can I AVOID using other reusable tools in this
		tool. If I build a tool that's dependent on MY
		private code library other people are unlikely to
		be able to use it. It means I may take more time,
		but it's time well spent. If I can't avoid it, I
		document what the tool I'm referencing does so it
		can be reimplemented by a third party if it's
		missing.
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
From: ckd@eff.org (Christopher Davis)
Newsgroups: comp.security.misc
Subject: Re: Locking terminals (was Re: New Princeton Policy)
Date: 11 Sep 92 19:39:31 GMT
	<1992Sep10.161835.20380@rz.uni-karlsruhe.de> <68006@hydra.gatech.EDU>
Organization: Electronic Frontier Foundation Tech Central

Danny> == Danny McGurl <dsm@prism.gatech.EDU> 

 Danny> Heck, we hav trouble keeping people from bringing in cokes into
 Danny> some of our clusters (even though we have huge signs).  Somehow
 Danny> I think people would laugh at a reguirement to use the system
 Danny> lockscreen :)

Simple policy fix: ``If the terminal is locked with anything other than
the "standard" lockscreen, it may be rebooted in order to clear the
lock.''
--
Christopher Davis   | ]CALL -151       
<ckd@eff.org>       | *300: 20 DD FB 60
System Administrator| *3D0G            
EFF +1 617 864 0665 | ]CALL 768        
Newsgroups: comp.security.misc
From: ckd@eff.org (Christopher Davis)
Subject: Re: Locking terminals (was Re: New Princeton Policy)
Organization: Electronic Frontier Foundation Tech Central
	<68006@hydra.gatech.EDU> <CKD.92Sep11153929@loiosh.eff.org>
	<1992Sep12.183351.5857@news.iastate.edu>
Date: Sun, 13 Sep 1992 08:25:52 GMT

John> == John Hascall <john@iastate.edu> 

 ckd> Simple policy fix: ``If the terminal is locked with anything other
 ckd> than the "standard" lockscreen, it may be rebooted in order to
 ckd> clear the lock.''

 John> And how do you (or the average user walking up to it) tell the
 John> two apart?

Is there a timer?  Is it moving?  Has the button appeared yet?  Does the
button work?  Did the timer just surreptitiously subtract 10 minutes? :-)

The main problem, as has been noted, is what to do about people who are
remotely logged in.  I tend to follow the MIT/Athena interpretation that
since the workstation is physically under the power of the person at its
console, it should be logically under their power as well.  (Athena
workstations don't allow remote logins, and the root password is freely
distributed.  If you want to renice your window manager, feel free.)
--
Christopher Davis   | ]CALL -151       
<ckd@eff.org>       | *300: 20 DD FB 60
System Administrator| *3D0G            
EFF +1 617 864 0665 | ]CALL 768        
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
From: sims@drake.mitre.org (Jim Sims)
Subject: Re: Beta testers needed for security tool
Organization: The MITRE Corporation
Date: Sun, 6 Sep 1992 01:32:14 GMT

(buncha stuff about a utility to diff files as a security measure deleted)

 It seems to me rather useless and extremely CPU and I/O expensive to diff
files as a security measure. How ooften you gonna run this thing? Every 10
minutes? What's the expected delta between logins that someone could be
snagging passwords on your system? Seems like better control over changing
the files is the answer rather than finding out afterwards....

 If I was gonna hack some system, I'd be sure the first thing I'd do to is
find the root's version of tripwire and change it to *always* spit out the
"don' worry, be happy message"....
Newsgroups: comp.security.misc
From: cristy@eplrx7.es.duPont.com (Cristy)
Subject: Re: Available Speed for MD 4/MD 5 / RSA
Organization: DuPont Central Research & Development
Date: Tue, 8 Sep 1992 00:14:44 GMT

In article <2967@ucl-cs.uucp> B.Kumar@cs.ucl.ac.uk writes:
>What are the average (or claimed) speeds for computing MD4/MD5/RSA 
>using specialised hardware (such as Cylink CY1024 (?) public key 
>processor) chips?

I did a quick benchmark-- 6 seconds of cpu for computing the MD5 on 5MB
of data on a Sparc II.
-- 
cristy@dupont.com
Xref: sparky comp.security.misc:1206 alt.security:4306
From: egurney@vcd.hp.com (Ed J. Gurney)
Newsgroups: comp.security.misc,alt.security
Subject: Info requested on "computer crime"
Date: 8 Sep 92 22:42:58 GMT
Organization: Hewlett-Packard VCD
X-Newsreader: Tin 1.1 PL5

Greetings!  I'm looking for any references to the general topic
of 'computer crime' for a paper I'm working on.  I already have the
various papers on the Internet 'worm', and I'd like to expand my
coverage to other aspects of computer crime.  If you have any ideas
for other topics or any information on a bibliography relating to
this information, please contact me!

Thanks and regards,
Eddy
<egurney@vcd.hp.com>

-- 
Eddy J. Gurney, N8FPW       Hewlett-Packard Company, Vancouver Division
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
From: Ross Ridge <ross@zooid.guild.org>
Subject: Re: Beta testers needed for security tool
Organization: ZOOiD BBS
Date: Mon, 7 Sep 1992 10:26:53 GMT

ckd@eff.org (Christopher Davis) writes:
><unlock SysAdm Cabinet>
><remove "special" floppy>
><insert "special" floppy>
>mount -r /dev/fd0c /floppy
>/floppy/tripwire
>
>This is one possible way to do it on floppy-equipped systems (say, an
>SS2 or IPX or whatever).  Maybe this should go in the docs?

While this would be what I'd do, even this isn't 100% guaranteed if
someone has broken security on the machine.  It's possible, for instance,
that the mount command, shell or even kernel has been hacked to prevent
tripwire from doing it's job properly.

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //
Xref: sparky comp.security.misc:1177 alt.security:4269 alt.sources.d:1108 comp.sources.testers:5 comp.unix.admin:4910
From: genek@mentor.cc.purdue.edu (Gene Kim)
Newsgroups: comp.security.misc,alt.security,alt.sources.d,comp.sources.testers,comp.unix.admin
Subject: Re: Beta testers needed for security tool
Date: 7 Sep 92 02:04:01 GMT
Organization: Purdue University

holland@matt.ksu.ksu.edu (Rich Holland) writes:

>sims@drake.mitre.org (Jim Sims) writes:

>> If I was gonna hack some system, I'd be sure the first thing I'd do to is
>>find the root's version of tripwire and change it to *always* spit out the
>>"don' worry, be happy message"....

>...but it may not be '/etc/tripwire' or something so obvious.  What if
>the admin put it in '/var/spool/mail/some-user' and changed the perms
>so that it's not executable (harder to find).  You gonna poke through 
>EVERY file on the system lookin' for it?  What're the chances you'll be
>detected before you do?  :-)

    You are right in pointing out that Tripwire is only as reliable
and secure as the database and Tripwire executable files.  Therefore,
putting these files on the local system where they can be tampered with
would be a bad idea.

    In the documentation for Tripwire, we suggest putting both the 
database and the Tripwire executable on a ``secure-server''.  For
instance, putting them on read-only media on a remote file-system
with the files accessed via read-only NFS would be prudent.

Gene
    
(genek@mentor.cc.purdue.edu)
Newsgroups: comp.security.misc,alt.security
From: wolff@zen.et.tudelft.nl (Rogier Wolff)
Subject: Re: Software Copyright protection devices
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Sat, 05 Sep 1992 07:31:14 GMT

Nicholas Marshall Kramer <nk24+@andrew.cmu.edu> writes:

>Remember, we're talking lost sales here. You can go on and on all you
>want about the morality of it, but a software company does not lose ONE
>CENT when someone pirates something they wouldn't have otherwise bought.
>(That's why companies aren't terribly reluctant to give out demo
>copies... Because the users wouldn't have actually bought it if they had
>to pay for it.)

Well... I know a few companies that actually buy packages, use them for a 
few days, and decide they can't use it. In this case they wouldn't have
bought it if they'd had a demo version. However I agree with you that a
software producer is better off in this case giving away the demo version:
they have a "satisfied customer" who knows that they don't make what they
need, instead of a dissatisfied customer who feels bad because they paid
for something they don't use.

					Roger.
-- 
If the opposite of "pro" is "con", what is the opposite of "progress"? 
(stolen from  kadokev@iitvax.iit.edu, who got it from brydon@asl.sinet.slb.com)
EMail:  wolff@duteca.et.tudelft.nl   ** Tel  +31-15-783644 or +31-15-142371
Newsgroups: comp.security.misc
From: avalon@coombs.anu.edu.au (Darren Reed)
Subject: Re: Hiding Processes from ps -ax
Organization: Computer Services Centre, Australian National University
Date:  7 Sep 92 15:19:32 GMT

flaps@dgp.toronto.edu (Alan J Rosenthal) writes:

>sxjcb@orca.alaska.edu (Jay C. Beavers) writes:
>>I've recently heard that you can hide a process from being displayed by a
>>ps -ax command.  Is this true, and if so what security implications does it
>>have?  How is this done,

>#include <stdio.h>
>#include <string.h>

>int main(argc, argv)
>    int argc;
>    char **argv;
>{
>    char *p;

>    for (p = argv[0]; *p; p++)
>	*p = 0;
>    strcpy(argv[0], "rn");

>    (void)getchar();  /* to allow you to see that ps reports "rn" */
>    return(0);
>}

Some people reported that "ps" showed "rn ut".

Here, it shows "rn (a.out)".

eg, I commonly have this:

18570 p8   I     0:01 -tcsh (tcsh)

However, if you can get the pid of a process then you can also
get the inode number of it too and if you have a decent OS, it
shouldnt let you delete it while its running (SunOS allows you
to unlink running processes :-/).

Just now I tried the following:

main(argc, argv)
int	argc;
char	*argv[];
{
	char	**s, *t;

	for (s = argv; *s; s++)
		for (t = *s; *t;)
			*t++ = '\0';
	pause();
}

% cc foo.c
% a.out &
% ps
...
19645 q5   S     0:00  (a.out)
...

If you have problems with ps showing the right name, try checking using
top to see if it will tell you the real name of the process.

Darren.

p.s the above code was compiled/tested on a Pyramid 9825 using OSx5.1 and
    SunOS 4.1.2 where the same results occured.
From: amoss@huji.ac.il (Amos Shapira)
Newsgroups: comp.security.misc
Subject: Re: Locking terminals (was Re: New Princeton Policy)
Date: 13 Sep 92 08:03:25 GMT
Organization: Mail to News Gateway at Wang Labs

ckd@eff.org (Christopher Davis) writes:

>Simple policy fix: ``If the terminal is locked with anything other than
>the "standard" lockscreen, it may be rebooted in order to clear the
>lock.''

And what will prevent users from hacking a lock programme which looks just like
the real thing, only without its restrictions?

And, on the other side, what will prevent users who want a locked terminal from
rebooting it and saying it looked like it wasn't locked by the right programme?

From meny discussions like this I got to the general desparing conclusion that
the best way to deal with such problems is to educate the users to be honest,
now how do you do that?

Cheers,
--
--Amos Shapira (Jumper Extraordinaire)
C.S. System Group, Hebrew University, Jerusalem, Israel
amoss@cs.huji.ac.il