Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!gmi!zombie.ncsc.mil!news.duke.edu!convex!cs.utexas.edu!news.cs.utah.edu!news.provo.novell.com!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.os.386bsd.misc
Subject: Re: Trans-Ameritech announcing: Linuxware
Date: 3 Mar 1995 20:09:37 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 39
Message-ID: <3j7t21$iud@park.uvsc.edu>
References: <3j2rk0$st3@openlink.openlink.com> <3j636c$j2d@sundog.tiac.net>
NNTP-Posting-Host: hecate.artisoft.com
rmk@tiac.net (Rick Kelly) wrote:
] Roman Yanovsky roman@btr.com (roman@btr.btr.com) wrote:
] : Trans-Ameritech Systems announcing:
] : LinuxWare(tm) - the easiest Linux to install ever, even for a first time user.
]
] : A powerful 100% UNIX(R) compatible Operating System for your desktop PC!
] ^^^^^^^^^^^^
]
] Unbelievable!! Could you please post the results of the SVID and SVVS
] test sets? Or is this just hot air?
Which UNIX do you use?
I can pretty much guarantee that gettimeofday(RT), getitimer(RT),
and setitimer(RT) don't conform to SVID requirements.
UnixWare, for instance, fails in these categories, as does Solaris
prior to 2.4, and even then, you have to run the code as compiled
on a SunOS 4.1.x box in compatability mode to get better than 10mS
resoloution on timers. That is, it requires the ability to
emulate another OS, since it can't natively pass.
Read the SVID: it says "system clock frequency", not "system clock
update frequency". 10mS is unacceptably *low* resoloution... it
reflects the rate at which the system clock as returned by the
gettimeofday(RT) call is updated, not the actual frequency of the
system clock.
If you don't believe that it is unacceptable, I suggest you
investigate the concept "double click" as it applies to X window
systems.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.