lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest172
gohigh 32616db5a4 add directory ftp-archives
2024-02-19 00:24:15 -05:00

793 lines
26 KiB
Plaintext
Raw Blame History

From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To: Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date: Wed, 14 Sep 94 11:13:18 EDT
Subject: Linux-Development Digest #172
Linux-Development Digest #172, Volume #2 Wed, 14 Sep 94 11:13:18 EDT
Contents:
Re: queue_glue: no memory for gluing queue in 1.1.50 (Alan Cox)
Driver for NCR 53C825 on the horizon? (Janne Sinkkonen)
Re: nvi has a seriouis bug (Re: Help with development using vi.) (NightHawk)
Re: netstat -r takes ages to complete. (Harald T. Alvestrand)
Re: MSDOS FS dates off by 5 days! (Slackware 2.0 bug?) (Kevin Lentin)
Re: Don't use Linux?! (Mark 'Enry' Komarinski)
Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) (Rob Janssen)
Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) (Michael Haardt)
Please share your experiences on Laptop with Linux+XFree86 (N B Venkateswarlu)
Re: IDE Hard Drives w/ over 1024 cylinders (Mark Lord)
Re: 320x200 X resolution? (Alan Cox)
Re: ext2fs dump/restore (Remy CARD)
Re: Slow curses - is there a better/faster curses? (Jay Ashworth)
----------------------------------------------------------------------------
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: queue_glue: no memory for gluing queue in 1.1.50
Date: Wed, 14 Sep 1994 12:32:58 GMT
In article <Cw0py0.CC@setanta.demon.co.uk> at@setanta.demon.co.uk (Amrik Thethi) writes:
>>Couldn't get a free page.....
>>IP: queue_glue: no memory for gluing queue 0x113D158
>>Couldn't get a free page.....
>>IP: queue_glue: no memory for gluing queue 0xD0D158
>>Couldn't get a free page.....
>>NFS server cichlid not responding, still trying
>>NFS server cichlid OK
>One thing you could try is to mount the NFS directories with an 'rsize'
>of 1024 or 4096 ( anything less than a mem page ). This may make life
>easier for the IP fragment assembly code, and thereby prevent the
>problem. No guarentees tho'
That is by far the best way of doing it - but has a speed cost thanks to the
SunOS I/O & VM subsystems. The other thing to do is to double the size of
the secondary page queue (look in mm/*.c). The current Linux memory system
keeps 40 pages handy (when possible) for interrupts to use. Unfortunately
it doesn't accumulate pages that are adjacent for kmalloc to allocate
big blocks. That is the proper fix but its one for someone with a good
head for memory allocation algorithms.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
------------------------------
From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen)
Crossposted-To: comp.os.linux.help
Subject: Driver for NCR 53C825 on the horizon?
Date: 14 Sep 1994 15:28:42 +0300
Does it exist (as ALPHA) or is there any hope that one will appear in
near future? I've a PCI Pentium here with a NCR 53C825 and an ISA
SCSI is currently the only available option.
Or should the 53C810 driver work with 53C825?
--
Janne
------------------------------
From: fsosi@j51.com (NightHawk)
Crossposted-To: comp.os.linux.help
Subject: Re: nvi has a seriouis bug (Re: Help with development using vi.)
Date: 13 Sep 1994 01:05:37 -0400
Bryan S. So (so@brownie.cs.wisc.edu) wrote:
: :
: : >Get a better vi. nvi from ftp.cs.berkeley.edu (if I remember the
: : >address correctly) is a much better vi than elvis. (And let's you
: : >cut&paste under X, which is the exact reason why I dumped elvis)
: The problem with nvi (mine is ver 1.03) is, you can delete a line and put it
: into a buffer. Try this:
: "add
: to delete a line and put it in register a. And use
: "ap
: to put it back. It says "buffer a is empty" ... very scary!
I have no problem with nvi 1.34.
NH
: Use another better vi -- "vim".
: Bryan
------------------------------
From: hta@uninett.no (Harald T. Alvestrand)
Subject: Re: netstat -r takes ages to complete.
Date: 14 Sep 1994 10:32:44 GMT
Try netstat -rn and compare.
My guess is most of the time is spent in DNS lookups, trying to
find names for things.
(n = -no names)
--
Harald Tveit Alvestrand
Harald.T.Alvestrand@uninett.no
G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
+47 73 59 70 94
My son's name is Torbj<62>rn. The letter between "j" and "r" is o with a slash.
------------------------------
From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin)
Subject: Re: MSDOS FS dates off by 5 days! (Slackware 2.0 bug?)
Date: 14 Sep 1994 12:50:46 GMT
Matthias Urlichs (urlichs@smurf.noris.de) wrote:
> Well, it _should_ contain (not sustain) minutes.
> > Try
> > secs += sys_tz.tz_minuteswest;
> >
> Don't.
> > Of course, its better to set tz_minute in munute....
> True. Therefore, the problem is not in the kernel but in whichever program
> uses seconds for minuteswest in the settimeofday() system call. See "man
> settimeofday"; it talks about minutes.
It's /sbin/clock in certain Slackware distributions. The 'timezone' files
have a secondswest field in them and /sbin/clock just copies it across to
the settimeofday() minuteswest field.
Here is the info I got from Alan Modra. I doubt he'll mind me reposting
it...
=====
From alan@spri.levels.unisa.edu.au Wed Aug 31 14:57:28 1994
Received: by molly (5.57/1.34)
id AA08494; Wed, 31 Aug 94 14:57:28 +1000
Received: by bruce (5.57/1.34)
id AA06435; Wed, 31 Aug 94 14:57:25 +1000
Received: by spri.levels.unisa.edu.au
id OAA06268; Wed, 31 Aug 1994 14:27:23 +0930
From: alan@spri.levels.unisa.edu.au (Alan Modra)
Message-Id: <199408310457.OAA06268@spri.levels.unisa.edu.au>
Subject: Re: Time bugs
To: kevinl@bruce.cs.monash.edu.au (Kevin Lentin)
Date: Wed, 31 Aug 1994 14:27:22 +0930 (ACST)
In-Reply-To: <no.id> from "Kevin Lentin" at Aug 31, 94 03:17:44 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 11012
Status: OR
>
> I believe we've discovered some major problems with the time code. It
> manifests itself in setting dates on FAT filesystems that look ages into
> the future under DOS. Here are some news articles and an email reply which
> seem to identify it all.... [The news article is my followup to Alberto and
> the mail is his reply to me]
>
I hit this bug quite a while ago, and fixed util-linux-1.9/clock.c. The
following is the relevant patch I sent to Rik Faith. If util-linux-1.10
is not yet out, you may wish to apply the following patch yourself.
=========================================================================
3) The major reason for sending in this diff: modifications to clock.c
a) Fix a few typos in comments and remove reference to making
clock -u a cron job. The kernel adjusts cmos time every 11
minutes - see kernel/sched.c and kernel/time.c set_rtc_mmss().
This means we should really have a cron job updating
/etc/adjtime every 11 mins (set last_time to the current time
and not_adjusted to ???).
b) Swapped arguments of outb() to agree with asm/io.h macro of the
same name. Use outb() from asm/io.h as it's slightly better.
c) Changed CMOS_READ and CMOS_WRITE to inline functions. Inserted
cli()..sti() pairs in appropriate places to prevent possible
errors, and changed ioperm() call to iopl() to allow cli.
d) Moved some variables around to localise them a bit.
e) Fixed bug with clock -ua or clock -us that cleared environment
variable TZ. This fix also cured the annoying display of bogus
day of week on a number of machines. (Use mktime(), ctime()
rather than asctime() )
f) Use settimeofday() rather than stime(). This one is important
as it sets the kernel's timezone offset, which is returned by
gettimeofday(), and used for display of MSDOS and OS2 file
times.
diff -ur orig/util-linux-1.9/clock.c util-linux-1.9/clock.c
--- orig/util-linux-1.9/clock.c Thu Jun 23 11:43:29 1994
+++ util-linux-1.9/clock.c Fri Aug 5 20:24:02 1994
@@ -5,9 +5,14 @@
#include <getopt.h>
#include <time.h>
#include <string.h>
+#include <sys/time.h>
#define USE_INLINE_ASM_IO
+#ifdef USE_INLINE_ASM_IO
+#include <asm/io.h>
+#endif
+
/* V1.0
* CMOS clock manipulation - Charles Hedrick, hedrick@cs.rutgers.edu, Apr 1992
*
@@ -56,8 +61,7 @@
* c) set your system time using the 'date' command.
* d) update your cmos time using 'clock -wu' or 'clock -w'
* e) replace the first number in /etc/adjtime by your correction.
- * f) put the command 'clock -au' or 'clock -a' in your '/etc/rc.local' or
- * let 'cron' start it regularly.
+ * f) put the command 'clock -au' or 'clock -a' in your '/etc/rc.local'
*
* If the adjustment doesn't work for you, try contacting me by E-mail.
* V1.2
@@ -68,12 +72,12 @@
*
* "I found the explanation and solution for the CMOS reading 0xff problem
* in the 0.99pl13c (ALPHA) kernel: the RTC goes offline for a small amount
- * of time for updateing. Solution is included in the kernel source
+ * of time for updating. Solution is included in the kernel source
* (linux/kernel/time.c)."
*
- * "I modified clock.c to fix this problem and add an option (now default,
- * look for USE_INLINE_ASM_IO) that I/O instructions were used as inline
- * code and not via /dev/port (still possible vila #undef ...)."
+ * "I modified clock.c to fix this problem and added an option (now default,
+ * look for USE_INLINE_ASM_IO) that I/O instructions are used as inline
+ * code and not via /dev/port (still possible via #undef ...)."
*
* With the new code, which is partially taken from the kernel sources,
* the CMOS clock handling looks much more "official".
@@ -89,9 +93,6 @@
/*#define DEBUG */
/*#define KEEP_OFF */
-/* Stupid constants */
-#define SECONDSPERDAY 86400
-
/* Globals */
int readit = 0;
int adjustit = 0;
@@ -117,11 +118,25 @@
int cmos_fd;
#endif
-#define CMOS_READ(addr) ({outb(0x70,(addr)|0x80); inb(0x71);})
-#define CMOS_WRITE(addr,val) ({outb(0x70,(addr)|0x80); outb(0x71,(val)); })
+static inline unsigned char cmos_read(unsigned char reg)
+{
+ register unsigned char ret;
+ __asm__ volatile ("cli");
+ outb (reg | 0x80, 0x70);
+ ret = inb (0x71);
+ __asm__ volatile ("sti");
+ return ret;
+}
+static inline void cmos_write(unsigned char reg, unsigned char val)
+{
+ outb (reg | 0x80, 0x70);
+ outb (val, 0x71);
+}
+
+#ifndef outb
static inline void
-outb (short port, char val)
+outb (char val, unsigned short port)
{
#ifdef USE_INLINE_ASM_IO
__asm__ volatile ("out%B0 %0,%1"::"a" (val), "d" (port));
@@ -130,9 +145,11 @@
write (cmos_fd, &val, 1);
#endif
}
+#endif
+#ifndef inb
static inline unsigned char
-inb (short port)
+inb (unsigned short port)
{
unsigned char ret;
#ifdef USE_INLINE_ASM_IO
@@ -143,12 +160,13 @@
#endif
return ret;
}
+#endif
void
cmos_init ()
{
#ifdef USE_INLINE_ASM_IO
- if (ioperm (0x70, 2, 1))
+ if (iopl (3))
{
fprintf(stderr,"clock: unable to get I/O port access\n");
exit (1);
@@ -172,31 +190,26 @@
cmos_read_bcd (int addr)
{
int b;
- b = CMOS_READ (addr);
+ b = cmos_read (addr);
return (b & 15) + (b >> 4) * 10;
}
static inline void
cmos_write_bcd (int addr, int value)
{
- CMOS_WRITE (addr, ((value / 10) << 4) + value % 10);
+ cmos_write (addr, ((value / 10) << 4) + value % 10);
}
int
main (int argc, char **argv, char **envp)
{
struct tm tm;
- struct tm *tmp;
time_t systime;
time_t last_time;
- char *zone;
- char zonebuf[256];
char arg;
- FILE *adj;
double factor;
double not_adjusted;
int adjustment = 0;
- int i;
unsigned char save_control, save_freq_select;
while ((arg = getopt (argc, argv, "rwsua")) != -1)
@@ -233,6 +246,7 @@
if (adjustit)
{ /* Read adjustment parameters first */
+ FILE *adj;
if ((adj = fopen (ADJPATH, "r")) == NULL)
{
perror (ADJPATH);
@@ -251,18 +265,19 @@
if (readit || setit || adjustit)
{
+ int i;
/* read RTC exactly on falling edge of update flag */
/* Wait for rise.... (may take upto 1 second) */
for (i = 0; i < 10000000; i++)
- if (CMOS_READ (10) & 0x80)
+ if (cmos_read (10) & 0x80)
break;
/* Wait for fall.... (must try at least 2.228 ms) */
for (i = 0; i < 1000000; i++)
- if (!(CMOS_READ (10) & 0x80))
+ if (!(cmos_read (10) & 0x80))
break;
/* The purpose of the "do" loop is called "low-risk programming" */
@@ -278,7 +293,7 @@
tm.tm_year = cmos_read_bcd (9);
}
while (tm.tm_sec != cmos_read_bcd (0));
- tm.tm_mon--; /* DOS uses 0 base */
+ tm.tm_mon--; /* DOS uses 1 base */
tm.tm_wday -= 3; /* DOS uses 3 - 9 for week days */
tm.tm_isdst = -1; /* don't know whether it's daylight */
#ifdef DEBUG
@@ -286,16 +301,17 @@
#endif
}
- if (readit)
+ if (readit || setit || adjustit)
{
/*
- * Mktime assumes we're giving it local time. If the CMOS clock
- * is in GMT, we have to set up TZ to mktime knows it. Tzset gets
+ * mktime() assumes we're giving it local time. If the CMOS clock
+ * is in GMT, we have to set up TZ so mktime knows it. tzset() gets
* called implicitly by the time code, but only the first time. When
- * changing the environment variable, better call tzset explicitly.
+ * changing the environment variable, better call tzset() explicitly.
*/
if (universal)
{
+ char *zone;
zone = (char *) getenv ("TZ"); /* save original time zone */
(void) putenv ("TZ=");
tzset ();
@@ -303,31 +319,37 @@
/* now put back the original zone */
if (zone)
{
- if ((strlen (zone) + 4) > sizeof (zonebuf))
- {
- fprintf (stderr, "Size of TZ variable is too long\n");
- exit (2);
- }
+ char *zonebuf;
+ zonebuf = malloc (strlen (zone) + 4);
strcpy (zonebuf, "TZ=");
- strcat (zonebuf, zone);
+ strcpy (zonebuf+3, zone);
putenv (zonebuf);
+ free (zonebuf);
}
else
{ /* wasn't one, so clear it */
putenv ("TZ");
}
tzset ();
- printf ("%s", ctime (&systime));
}
else
{
- printf ("%s", asctime (&tm));
+ systime = mktime (&tm);
}
+#ifdef DEBUG
+ printf ("Number of seconds since 1/1/1970 is %d\n", systime);
+#endif
}
- if (setit || adjustit)
+ if (readit)
{
+ printf ("%s", ctime (&systime));
+ }
+ if (setit || adjustit)
+ {
+ struct timeval tv;
+ struct timezone tz;
/* program is designed to run setuid, be secure! */
if (getuid () != 0)
@@ -336,18 +358,12 @@
exit (2);
}
- if (universal)
- (void) putenv ("TZ=");
- systime = mktime (&tm);
-#ifdef DEBUG
- printf ("Number of seconds since 1/1/1970 is %d\n", systime);
-#endif
if (adjustit)
{ /* the actual adjustment */
double exact_adjustment;
exact_adjustment = ((double) (systime - last_time))
- * factor / SECONDSPERDAY
+ * factor / (24 * 60 * 60)
+ not_adjusted;
if (exact_adjustment > 0)
adjustment = (int) (exact_adjustment + 0.5);
@@ -364,19 +380,23 @@
not_adjusted);
#endif
}
-#ifdef KEEP_OFF
- if (0 != 0)
- {
-#else
- if (stime (&systime) != 0)
+#ifndef KEEP_OFF
+ tv.tv_sec = systime;
+ tv.tv_usec = 0;
+ tz.tz_minuteswest = timezone / 60;
+ tz.tz_dsttime = daylight;
+
+ if (settimeofday (&tv, &tz) != 0)
{
-#endif
fprintf (stderr, "Unable to set time -- probably you are not root\n");
exit (1);
}
+#endif
}
+
if (writeit || (adjustit && adjustment != 0))
{
+ struct tm *tmp;
systime = time (NULL);
if (universal)
tmp = gmtime (&systime);
@@ -384,10 +404,11 @@
tmp = localtime (&systime);
#ifndef KEEP_OFF
- save_control = CMOS_READ (11); /* tell the clock it's being set */
- CMOS_WRITE (11, (save_control | 0x80));
- save_freq_select = CMOS_READ (10); /* stop and reset prescaler */
- CMOS_WRITE (10, (save_freq_select | 0x70));
+ __asm__ volatile ("cli");
+ save_control = cmos_read (11); /* tell the clock it's being set */
+ cmos_write (11, (save_control | 0x80));
+ save_freq_select = cmos_read (10); /* stop and reset prescaler */
+ cmos_write (10, (save_freq_select | 0x70));
cmos_write_bcd (0, tmp->tm_sec);
cmos_write_bcd (2, tmp->tm_min);
@@ -397,8 +418,9 @@
cmos_write_bcd (8, tmp->tm_mon + 1);
cmos_write_bcd (9, tmp->tm_year);
- CMOS_WRITE (10, save_freq_select);
- CMOS_WRITE (11, save_control);
+ cmos_write (10, save_freq_select);
+ cmos_write (11, save_control);
+ __asm__ volatile ("sti");
#endif
#ifdef DEBUG
printf ("Set to : %d:%d:%d\n", tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
@@ -411,6 +433,7 @@
/* Save data for next 'adjustit' call */
if (adjustit)
{
+ FILE *adj;
if ((adj = fopen (ADJPATH, "w")) == NULL)
{
perror (ADJPATH);
> --
> By the yard, life is hard.
> By the inch, it's a cinch.
> --
> Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
> Schleiermacherstra<72>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
> 90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
> PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
> Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
========
--
[==================================================================]
[ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]
------------------------------
From: komarimf@craft.camp.clarkson.edu (Mark 'Enry' Komarinski)
Subject: Re: Don't use Linux?!
Date: 14 Sep 1994 13:00:23 GMT
Riku Saikkonen (riku.saikkonen@compart.fi) wrote:
: >Wrong. You may make statically linked, binary-only releases.
: >All you have to do is to distribute an unlinked version of your
: >program along the ready-to-use version. This is not too much
: >of a hassle.
: Uh... Stupid question: What is the best way to distribute the unlinked
: binary? The .o files?
They used to be. (Anyone else remember this?) Files were distributed
in .a and .o format. You had to link them yourself. I think the reason
was that you could linik it in static or the 'new' dynamic libraries.
--
- Mark Komarinski - komarimf@craft.camp.clarkson.edu
"...And if I have none of those deficiencies, I hope to get them sometime."
-Car Talk (on NPR)
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders)
Reply-To: pe1chl@rabo.nl
Date: Wed, 14 Sep 1994 08:36:33 GMT
In <9409123702@fangorn> Michael Haardt <(michael)u31b3hs@pool.informatik.rwth-aachen.de> writes:
>rob@pe1chl.ampr.org (Rob Janssen) writes:
>> You wouldn't believe how much stir-up a small patch like this can sometimes
>> cause. I think Linus has become more careful before incorporating things
>> like this....
>I believe very well how much a small patch can do, but a changed printk
>like the posted one is obviously not dangerous.
That is *not* true at all!
The patch I referred to in my original post also caused no more grief
that printing an unnecessary and wrong message during bootup (about the
availability of a disk that was not really there), and as long as you
would not access that disk nothing was wrong.
You should have seen the stir-up that this caused in the newsgroups!!!
Suddenly, people were believing there systems were about to die, there
disks were being smoked, etc etc. Not good.
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: Michael Haardt <(michael)u31b3hs@pool.informatik.rwth-aachen.de>
Subject: Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders)
Date: Wed, 14 Sep 94 11:42:34 MET
mlord@bnr.ca (Mark Lord) writes:
> Yeah. The above patch would cause linux to "recognize" non-existant devices
> that are entered in the BIOS tables but not physically present.
I don't want to try it out, but I think at least my BIOS will refuse to
let me boot without changing the setup with MFM/IDE drives being
configured but not present. The patch only changes a printk() from
printing "identity unknown" to a more descriptive message.
Michael
--
Twiggs and root are a wonderful tree (tm) Twiggs & root 1992 :-)
------------------------------
From: venkat@epcc.ed.ac.uk (N B Venkateswarlu)
Subject: Please share your experiences on Laptop with Linux+XFree86
Date: Wed, 14 Sep 1994 11:10:21 GMT
Hi,
If you have Linux+XFree86 intsalled on your Laptop could you please clarify
my doubt how to set XConfig with Laptops.
When I use SuperProbe I got the following details of my video
Chip Set: Western Digital/Paradise 90C22
Memory: 256Kbytes
Genreic 8-bit pseudo coolour DAC with 6-bit wide lookup tables.
Please do reply
Venkat
------------------------------
From: mlord@bnr.ca (Mark Lord)
Subject: Re: IDE Hard Drives w/ over 1024 cylinders
Date: 14 Sep 1994 13:07:46 GMT
In article <1994Sep8.213522.20007@unlv.edu> ftlofaro@unlv.edu writes:
>Why not have the kernel figure out the geometry itself?
>If heads > 16 and <= 32, assume its doubled and halve it and double cylinders
>If heads > 32 and <= 48, assume tripled,
>and so on.
Err.. the 1.1.x kernels already do better than this.
They ask the drive for the real physical geometry,
but pretend that the BIOS is correct when dealing with fdisk.
Oh, that's for IDE only. If you have SCSI, tough luck.
--
mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
------------------------------
Crossposted-To: comp.os.linux.misc
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: 320x200 X resolution?
Date: Wed, 14 Sep 1994 13:56:31 GMT
In article <CvuCws.9JJ@serval.net.wsu.edu> a0017097@wsuaix.csc.wsu.edu (Christopher Wiles) writes:
>Seriously, IMHO Doom will probably be more useable in the promised
>pixel-doubling mode than in a straight 320x200. Easier to make things
>look innocent when the boss walks in ... "Hey, you're not actually
>_working_ in 320x200, are you?"
Rumour has it Xfree86 3.1 has 320x200x256 support for DOOM. As to mode
switching you just hit CTRL-ALT-+ and go back 1024x768 when the boss is
around.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
------------------------------
From: card@masi.ibp.fr (Remy CARD)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
Subject: Re: ext2fs dump/restore
Date: 14 Sep 1994 11:31:50 GMT
In article <354b12$3au@raffles.technet.sg>,
Mathias Koerber <Mathias.Koerber@swi.com.sg> wrote:
] s there a dump/restore for ext2fs or xiafs or any other good/fast
] Linux fs? I'd like to be able to use Amanda to back up my Linux
] box, but that requires dump to work.
]
] Any hints appreciated
I have ported the 4.4BSD dump and restore programs to Linux. My port
understands the ext2fs structure. It is currently in alpha test. When a
beta version is available, it will be announced in c.o.l.a.
] mathias
]
] --
] Mathias Koerber Tel: +65 / 778 00 66 x 29
] SW International Systems Pte Ltd Fax: +65 / 777 94 01
] 14 Science Park Drive #04-01 The Maxwell e-mail: Mathias.Koerber@swi.com.sg
] S'pore 0511 <A HREF=http://www.swi.com.sg/public/personal/mk.html>MK</A>
] The Vatican has the highest population of popes: 5.2 / m^2
Remy
------------------------------
From: jra@zeus.IntNet.net (Jay Ashworth)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.admin
Subject: Re: Slow curses - is there a better/faster curses?
Date: 14 Sep 1994 09:04:44 -0400
jamesd@teleport.com (James Deibele) writes:
>Console output under Linux was very quick and I'm sure X performance is
>pretty good. But curses performance is a little sluggish and adding
>lines near the bottom of the screen is a real killer - curses seems to
>clear the screen with blank lines <then> adds the new text.
That sounds like a termcap entry problem... I don't have it, and I'm using
a different distribution. The console vt100 emulation -- an attribute of
the _kernel_ -- supports IL and DL directly, even correctly interacting
with the scrolling region. Check other termcaps, and if you're equipped,
take a look at the console.c in your kernel source tree to see what it
expects. This is an area that deserves better documentation. The
authoritative source for the emulation ought not to be the termcap file.
Cheers,
-- jra
--
Jay R. Ashworth Ashworth
Designer & Associates
ka1fjx/4 High Technology Systems Consulting
jra@baylink.com +1 813 790 7592
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.development) via:
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
Linux may be obtained via one of these FTP sites:
nic.funet.fi pub/OS/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development Digest
******************************
Reference in New Issue View Git Blame Copy Permalink