Linux-Development-Sys Digest #583, Volume #6 Mon, 5 Apr 99 04:14:21 EDT
Contents:
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Victor Wagner)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Victor Wagner)
Help - want to let users set up POP accounts and passwords over net. (Nico Zigouras)
Re: 4 Gb memory? ECC? (Andy Isaacson)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Alexander Viro)
Re: no setuid for scripts (Peter Samuelson)
Re: Help - want to let users set up POP accounts and passwords over net. (David T.
Blake)
Re: Took one guy 3 days, another 1 day, me 1 hour... (Peter Samuelson)
Re: can we do float point calculation in kernel module? (Peter Samuelson)
Re: Trusted Linux (Peter Samuelson)
Re: Proposal: "Linux 2000 Platform" (Peter Samuelson)
Re: 4 Gb memory? ECC? (Peter Samuelson)
Re: Took one guy 3 days, another 1 day, me 1 hour... (Peter Samuelson)
Re: Proposal: "Linux 2000 Platform" (Peter Samuelson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: 4 Apr 1999 19:07:28 +0400
In comp.os.linux.development.apps Alexander Viro <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>,
: Joseph H Allen <[EMAIL PROTECTED]> wrote:
:>In article <7dk3c5$[EMAIL PROTECTED]>,
:>Alexander Viro <[EMAIL PROTECTED]> wrote:
:>> 7) Learn *powerful* editor. No, Borland-alikes do not qualify.
[skip]
: of JOE (IMHO) being the command set. Borland stuff is simply out of question -
: it lacks regex search, for one.
Borland stuff has regular expressions since at least Turbo Pascal
5.0/Turbo C 2.0. xwpe has them too. Just learn your editor.
Of course, now I prefer vim, as much more powerful beast than Borland things
or qedit. But I cannot stand when good program is ashamed by person who
never tried to read what search options mean.
--
========================================================
Victor Wagner @ home = [EMAIL PROTECTED]
I don't answer questions by private E-Mail from this address.
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: 4 Apr 1999 19:02:39 +0400
In comp.os.linux.development.apps Johan Kullstam <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Victor Wagner) writes:
:> Note that one of the best C compiliers for DOS/Novell is Watcom, and it
:> comes with editor, which is called vi, and really _is_ vi.
: it is? how does it run in dos? i thought the real bill joy vi
It is vi in sense of keyboard command compatibility. I think watcom
programmers rewrote thing from scratch, adding some dos-specific
interface goodies like popup menues. So it is vi no more than vim or
elvis (and they run on the DOS too).
: required termcap, /bin/ed and /usr/bin/ex. last time i looked at the
: source it did.
: --
: johan kullstam
--
========================================================
Victor Wagner @ home = [EMAIL PROTECTED]
I don't answer questions by private E-Mail from this address.
------------------------------
From: Nico Zigouras <[EMAIL PROTECTED]>
Subject: Help - want to let users set up POP accounts and passwords over net.
Date: Sun, 04 Apr 1999 21:37:16 -0400
Hi:
I am wondering if someone can help me with this. I want to set up a
script that lets users set their password over the web. Before you
start worrying about secuirty, I have locked out all FTP access and
telnet access to all except admin. Basically I want users to
automatically set up POP accounts for themselves.
I am able to change adduser to suid root so it can get called from a web
script, but passwd does not want to budge and insists that I am logged
on as root to change each password.
Thanks in advance for your help..
Sincerely,
Nico Zigouras.
------------------------------
From: [EMAIL PROTECTED] (Andy Isaacson)
Subject: Re: 4 Gb memory? ECC?
Date: 5 Apr 1999 02:30:57 GMT
In article <[EMAIL PROTECTED]>, Mikko Hyvarinen wrote:
> What is the maximum physical memory size supported by Linux on an Alpha
> machine? I have seen patches for 2GB on Alpha, is this the current
> limit? If so, why?
AFAIK the max memory on Alpha is 2GB right now (2.2 with patches from
axp-list). It's difficult to go higher than 4GB physical memory,
because PCI devices can only address 4GB memory and the current
architecture wants PCI devices to be able to DMA to anywhere in
memory. The UltraSPARC port supports more than 4GB I think (I haven't
checked but others claim that it does) but it does it by using bounce
buffers.
There is discussion going on on axp-list (check out
archive.redhat.com) about how to support more memory. It should be
possible to support arbitrarily large physical memories on Alpha by
using bounce buffers, but this is a performance hit. Some Alpha
platforms have cool hardware in the PCI interface which can be used to
work around the 4GB PCI address limit.
> Now that I'm at it, how's the ECC support for Linux doing? (on x86 and
> Alpha)
ECC on Alphas that support it should work fine. I never experienced
an ECC error, but according to the docs the system should correct it
and continue, logging a message in the process.
-andy
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: 4 Apr 1999 21:17:17 -0400
In article <7e7v7g$e08$[EMAIL PROTECTED]>,
Victor Wagner <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps Alexander Viro <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]>,
>: Joseph H Allen <[EMAIL PROTECTED]> wrote:
>:>In article <7dk3c5$[EMAIL PROTECTED]>,
>:>Alexander Viro <[EMAIL PROTECTED]> wrote:
>:>> 7) Learn *powerful* editor. No, Borland-alikes do not qualify.
>[skip]
>: of JOE (IMHO) being the command set. Borland stuff is simply out of question -
>: it lacks regex search, for one.
>
>Borland stuff has regular expressions since at least Turbo Pascal
>5.0/Turbo C 2.0. xwpe has them too. Just learn your editor.
>Of course, now I prefer vim, as much more powerful beast than Borland things
>or qedit. But I cannot stand when good program is ashamed by person who
>never tried to read what search options mean.
Ex-cu-se-me? Could you be bothered to launch TC 2.0 and try to do a
search for, say it, [ab](c|fe*f)*d. I.e. find a combination of search pattern
and options to do the search for such regex. And post it here. If you don't
have TC around... well, I don't think that loaning you a copy would upset
Borland. I have it. Deal? BTW, I *had* looked through their search
implementation right now. It has soundex search, right, but it has *no*
regex.
Please, post the proof of your claim. I.e. combination of search
pattern and options giving the search for aforementioned regex in TC 2.0 or
TP 5.0.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: no setuid for scripts
Date: 4 Apr 1999 22:42:01 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[H. Peter Anvin <[EMAIL PROTECTED]>]
> Perl is a good example on an interpreter which handles setuid scripts
> just fine, and securely.
Well, it works well enough -- except that it suffers from an inherent
design problem: suidperl basically duplicates kernel permissions checks
and must do so with convincing fidelity. This sounds simple enough,
but in practice this is fragile. For example, a recently published
exploit points out that suidperl can be tricked into running setuid
even with a script on a partition (say /mnt/floppy) mounted `nosuid'.
This can be (and probably has been) fixed by having suidperl parse
/proc/mounts, but that is definitely a kludge. I don't know a better
solution, though ... I'm not sure I like `sh /proc/self/fd/3' any more
than you do.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Help - want to let users set up POP accounts and passwords over net.
Date: 04 Apr 1999 20:52:10 -0700
Nico Zigouras <[EMAIL PROTECTED]> writes:
>Hi:
>
>I am wondering if someone can help me with this. I want to set up a
>script that lets users set their password over the web. Before you
>start worrying about secuirty, I have locked out all FTP access and
>telnet access to all except admin. Basically I want users to
>automatically set up POP accounts for themselves.
>
>I am able to change adduser to suid root so it can get called from a web
>script, but passwd does not want to budge and insists that I am logged
>on as root to change each password.
Well, it is your machine and therefore your headache.
Just rewrite adduser in Perl as an suid script. Grab a
username and password, splat the password line onto the
password file, and create the /home/$USER directory with
proper permissions, and also touch /var/spool/mail/$USER with
proper ownership and permissions.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Took one guy 3 days, another 1 day, me 1 hour...
Date: 4 Apr 1999 22:48:47 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Phil Howard]
> That may have come from the "fdisk" program. This program originated
> before Linux could handle partition table changes properly. I
> remember it failing to find logical partitions if the extended
> partition moved. This is fixed now, but the message may still be in
> the program. Linux does NOT need a reboot to make use of new
> partitions or partition table changes.
Not as used in a typical install program ... but the kernel does not
seem to handle partition table changes quite as gracefully if the drive
in question is already busy, i.e. something is mounted from it. Even
if the mounted partition was itself not changed. I wish the kernel
handled this better, but having thought about the issues for a little
while, I concluded that the fix would be just complicated enough that
it would take me awhile to do it right.... Maybe some day. I am a
great one for seeing projects I would like to take on but then never
quite having the time.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: can we do float point calculation in kernel module?
Date: 4 Apr 1999 22:28:23 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[<[EMAIL PROTECTED]>]
> Do you imply that the context-switching FP registers is more
> efficient in a Pentium II PC?
Yes, if you use the FXSAVE and FXRESTORE commands.
I don't really know more than that. (I'm very much a wannabe in terms
of asm hacking.) I don't even know in which CPU generation this was
introduced or what kind of performance you see. For all I know it's
really a K6-ism....
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Trusted Linux
Date: 4 Apr 1999 23:52:30 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Christopher B. Browne <[EMAIL PROTECTED]>]
> Hm. Yes, I see it there.
>
> 'Tis not clear how integrated it is into the rest of the system.
Well, there is basically no user-space support for capabilities, but
the kernel uses them. Changing this would require hacking a lot of
user space, IMHO.
> I would presume that there is some similarity here to the situation
> with ACLs, where there is some code in the kernel that *could* be
> supportive, but where further effort is required to make it useful
> with respect to connecting out to libraries and user mode code.
Not quite the same -- kernel support for capabilities is (AFAIK)
relatively complete and functional, whereas ACL's are at the moment
just hooks. sct apparently helped write preliminary ext2 support for
ACL's but didn't release it at least partially because they are not
useful without significant user-space support (hacks in libc, hacks in
`tar', `cp' and the like, hacks in rpm/dpkg and their package formats,
etc). This makes no sense to me, since that makes it a chicken-&-egg
problem. The logical place to break the cycle is in kernel space, as
with capabilities.
I strongly suspect I do not know the whole story, but I would *love* to
have ACL's to play around with even if `mv' couldn't preserve them
across mount points.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: 4 Apr 1999 23:17:44 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Jeremy Crabtree <[EMAIL PROTECTED]>]
> Okay...I was really hoping for a way to past from, say, tty1 (an
> actual console, not an XTerm) to someplace in X.
I thought about this some time ago. (I am quite adept at thinking of
ways to implement features I am likely never to get around to acting
on. Sometimes I think I am the ultimate hacker wannabe.)
One way to do this would be to provide an API within gpm -- or possibly
a helper app -- that would bridge the X selection and the gpm
selection, keeping them in sync as one changed. I originally thought
it would involve simply signalling gpm to open such-and-such an X
display, and would be pretty simple. Then I started thinking and began
to foresee problems:
- getting permission to connect to the X server. Have to have an
easy way to pass GPM the right MIT-MAGIC-COOKIE-1 or whatever.
- handling a server reset, i.e. user logs out and/or back in. This
is why gpm can't just connect at startup time.
- this only complicates the issue gpm already has to deal with, to
wit: deciding when to use the mouse and when to ignore it.
Currently it has to suspend operations when you switch to a VC with
X in it. The gpm/X incest I'm proposing would make it worse.
> Again, I was hoping for something that would work on a regular
> console, and paste into X...a pipe dream, I know, but still...
Not a pipe dream, more likely something on the lines of sockets....
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: 4 Gb memory? ECC?
Date: 4 Apr 1999 23:01:49 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Andy Isaacson <[EMAIL PROTECTED]>]
> AFAIK the max memory on Alpha is 2GB right now (2.2 with patches from
> axp-list). It's difficult to go higher than 4GB physical memory,
> because PCI devices can only address 4GB memory and the current
> architecture wants PCI devices to be able to DMA to anywhere in
> memory.
The Right Way to fix this would be the same as the Right Way to fix the
ISA DMA 16MB problem on PC's: if you detect that you've got more than
4GB of memory, preallocate something early -- a few megs should be
plenty, and unnoticeable for a machine with that much memory -- and
have all device drivers use a alloc/free calls that use that memory.
(Yeah, like I know anything about device drivers or PCI hardware.
Carry on, guys.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Took one guy 3 days, another 1 day, me 1 hour...
Date: 4 Apr 1999 22:54:09 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Phil Howard]
> Someone I was talking to was mentioning that the next coming user
> interface is voice
[...]
> you could just tell the computer what you wanted done, and didn't
> have to go find the right menu or dialog.
Cute. Does the general public really not grasp the concept that voice
recognition and natural language parsing are orthogonal technologies?
Or is using a keyboard just not an acceptible option for these people?
(Rhetorical question. I know the general public does not grasp this.
But it seems so obvious that I wonder why not.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: 4 Apr 1999 23:40:19 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Kendall Bennett <[EMAIL PROTECTED]>]
> The important thing that I was trying to get across, something that
> everyone seems to have completely missed is that Linux needs:
> . Cooperation
> . Standardisation
> . Uniformity
> Those three points are vital for the continued growth of Linux. I am
> not talking about this in the sense of 'continuing to challenge
> Windows'.
I can't speak for the rest of the newsgroups but to me, your idea
looked an awful lot like it would yield big restrictions in flexibility
and small benefits. Drop dpkg in favor of rpm? Thanks but no thanks.
I suspect many rpm users wouldn't be very happy if you proposed the
reverse.
Believe it or not, and I know you do believe it because you have been a
Linux user since version 0.90, about a year before *I* ever used Linux,
Linux is quite well standardized. The myth of fragmentation is only a
myth, and only exists in the rather high layers. Everyone [except
David Parsons of course] uses either libc 5.4.x or glibc 2.0/2.1, and
have nearly finished standardizing on glibc. Everyone uses XFree86
3.3.x with only cosmetic differences between compilations. Everyone's
binaries can run on everyone else's systems, if you don't count base
system stuff that might have compiled-in init.d pathnames, etc.
My point being that third-party software should have *no* difficulty
interacting with various flavors of Linux, as long as it is reasonably
self-contained. If it wants to modify boot scripts or replace system
library versions -- I don't think *I* want to trust its install scripts
on my box anyway.
> The standard response to my proposal seems to be something along the
> lines of 'Hell, you can solve those problems; you are just too
> lazy!'. Well a lazy programmer is a good programmer, and if there
> are ways that things can be streamlined to cut down on the amount of
> effort someone needs to expend to release a product that supports
> Linux, that is a good thing right?
I just don't see how an application can *not* support most
distributions pretty much by default. If you really feel the need to
modify the user's system in distribution-dependent ways, to me it looks
like poor design, or (to use words that might push buttons) "thinking
like a Windoze developer". This is not to slight Windoze developers,
but they do think differently; they think in terms of a platform
standard enough that you can make all sorts of assumptions about it.
Even if Linux were as standard as this, I would not want installation
procedures doing this.
On the other hand, there is the issue of software testing, and any sort
of guarantee that it works properly on a given distribution. I can see
the problems a house would have validating everything. But to me, if
you follow sensible rules on Separation of Church and System Stuff,
most distro-specific bugs would be distro bugs, and thus the
responsibility of the distro, not the third-party house.
> It appears to me that many in the Linux community are either just to
> vain, or too damn ignorant to realise this. So forget that I ever
> brought up the subject...
Look, you can drop the martyr act. To me, at least, the issues aren't
personal, they aren't about whether you're thinking as a Windoze user
or as a Red Hat bigot or what. To me, it's about the ideas, and
frankly, I don't like them.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
