He wanted a to be able to panic() a machine from console without being
able to drop to DDB from console. I think this is because he believes
that DDB is a security problem. :-)
Well, I'm missing something: the beginning of this thread, so this may
not be 100% relevant, but I've just had the
Lee Cremeans wrote:
On Sun, Sep 19, 1999 at 12:50:09PM +1000, [EMAIL PROTECTED] wrote:
Hi,
/kernel: shared address space fork attempted: pid: 281
/kernel: cmd setup.bin pid 281 tried to use non-present sched_yield
last message repeated 1926 times
Has anyone seen this
Hi,
I've been running the following patch (which uses discreet
tests vs a common temp off_t variable). Would someone please
consider committing either this patch or the one given in
the pr? It doesn't really matter to me, but I would like to
see this bug put to rest.
Comments welcome!
Doug wrote:
possible. To my (albeit limited) knowledge nothing in the base depends on
GLOBAL, so I would be one of those who would be calling for its removal
from the base. Of course, a port of your program would be welcome, and in
Nvi(1), more(1) and build system(bsd.*.mk) depends on GLOBAL.
W Gerald Hicks wrote:
imho, global (a fine software package) shouldn't have been in the
OS source tree anyway. To me, the proper place seems to be in the
ports collection along with many other development utilities.
It seems that you misunderstand.
Current GLOBAL(3.53 and earlier) is
There are some types of software for which the GPL is the best license.
In my opinion, programming tools of many sorts -- compilers, linkers,
editors, assemblers -- fit into this category. Contrary to what some
Tag system doesn't fit into this category?
believe, we BSD'ers are not rabid
Michael Kennett wrote:
As the owner/author of a piece of software, you can distribute the source
code under any license that you like (GNU/BSD/Artistic etc...). Indeed, there
is no reason to choose just a single license under which you distribute your
code -- it should be possible for you to
Peter Wemm wrote:
I think we should also remove the nvi patches as it contains global derived
code. Since GPL is incompatable with the (bsd-style) nvi license and the
global patches add code to nvi, then it would be better to remove the
conflicting code.
You need not remove it, because I
On Mon, Sep 20, 1999, Shigio Yamaguchi wrote:
But GPLed command brings no problem, because the rest of the system just
"utilize" it, not "use it. GPL is not applied to "utilize". So the rest of
the system is safe from GPL.
You cannot modify and incorporate a GPL command into a product
imho, global (a fine software package) shouldn't have been in the
OS source tree anyway. To me, the proper place seems to be in the
ports collection along with many other development utilities.
It seems that you misunderstand.
Current GLOBAL(3.53 and earlier) is BSD-style licensed and
Greg Lehey [EMAIL PROTECTED] writes:
The nice thing about kadb is that it has a usable macro languge.
Compared to ddb, yes. Compared to gdb, no.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Sat, 18 Sep 1999, Julian Elischer wrote:
DEVFS itself works fine however a subsystem it required to be a useful
abstraction was vandalised and stripped out by some people who "didn't get
it" and it has not yet been replaced by equivalent code.
It seems more correct (to me) to state that
Greetings.
I am having a little difficulty with one of my web/nfs servers and am in
need of some guidance. I am getting the following errrors on this machine:
--
panic: vm_fault; fault on nofault entry. addr: cc24a000
mp_lock=0002; cpuid=o; lapicid=0100
boot called on cpu#0
:On Sat, 18 Sep 1999, Julian Elischer wrote:
:
: DEVFS itself works fine however a subsystem it required to be a useful
: abstraction was vandalised and stripped out by some people who "didn't get
: it" and it has not yet been replaced by equivalent code.
:
:It seems more correct (to me) to
On Sun, 19 Sep 1999, Chuck Robey wrote:
On Sat, 18 Sep 1999, Julian Elischer wrote:
DEVFS itself works fine however a subsystem it required to be a useful
abstraction was vandalised and stripped out by some people who "didn't get
it" and it has not yet been replaced by equivalent
as far as I know DEVFS itself is working just fine..
there was some problem with mfs and vn devices at some stage as they used
'dummy' vnodes that were set up to look like device nodes, but mfs and vn
tried to use incestuous knowledge which was no longer true and crashed..
I believe that PHKs
On Sun, 19 Sep 1999, Julian Elischer wrote:
On Sun, 19 Sep 1999, Chuck Robey wrote:
On Sat, 18 Sep 1999, Julian Elischer wrote:
DEVFS itself works fine however a subsystem it required to be a useful
abstraction was vandalised and stripped out by some people who "didn't get
Hi,
I saw 'fsck_msdos' in the NetBSD sources.
Does somebody plan to put it (or similar one) in the FreeBSD
distribution?
Thanks
--iani
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Sunday, 19 September 1999 at 18:29:34 +0900, Kazutaka YOKOTA wrote:
He wanted a to be able to panic() a machine from console without being
able to drop to DDB from console. I think this is because he believes
that DDB is a security problem. :-)
Well, I'm missing something: the beginning
On Sunday, 19 September 1999 at 23:29:15 +0200, Assar Westerlund wrote:
Greg Lehey [EMAIL PROTECTED] writes:
The nice thing about kadb is that it has a usable macro languge.
Compared to ddb, yes. Compared to gdb, no.
I'd rather have adb's macro language.
Greg
--
See complete headers for
That was exactly the suggestion the original poster made in his PR.
He also believed that assiging the PANIC function to a key
is no worse than having the DDB function key.
I think that's a valid statement. Sure, you can return from ddb,
whereas you can't from panic, but any abuse
On Monday, 20 September 1999 at 2:06:18 +0200, Leif Neland wrote:
That was exactly the suggestion the original poster made in his PR.
He also believed that assiging the PANIC function to a key
is no worse than having the DDB function key.
I think that's a valid statement. Sure, you can
Johan Kruger wrote:
I mounted the boot.flp image and replaced kernel.gz with my own, for use
of bootable CD.
I don't want the default sysinstall ( presumably compiled into the
kernel ) to come up on screen, instead i want a command prompt only. I
will insert my scripts into .profile.
The
And now for a wish:
[ST_AIO stuff cut]
If I understand what you are trying to say, then
when real time signals are added, this will be unnecessary.
You can get the completion of an aio_* call from the signal
queue.
-jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
Sorry forgot something:
the Linux way of doing this is to fill in the si_band with information
on what has happened. This sound acceptable and there is no need to
be incompatible if the idea isn't too bad.
-jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
Shigio Yamaguchi wrote:
There are some types of software for which the GPL is the best license.
In my opinion, programming tools of many sorts -- compilers, linkers,
editors, assemblers -- fit into this category. Contrary to what some
Tag system doesn't fit into this category?
Shigio Yamaguchi wrote:
Michael Kennett wrote:
Does the license really matter? Surely the important consideration is quality
of the code?
I agree with you.
No, the license really does matter if we want to keep FreeBSD FREE. We do.
--
"Where am I, and what am I doing
:you're on, but there are 2 sides to the argument. Isn't there some way
:that it can be set up to *optionally* have permission persistence?
:
:If you would get past that point, then all the political problems that
:remain are solvable.
:
:Whatever, let's please not get into an argument over
like a virus to everything it touches. For this reason, the FreeBSD Project
has decided no GPL code will be included in the system itself, unless the
Actually, that's not *quite* accurate. What we decided was that GNU
code would be kept well-segregated from the rest, just to make it
clear
On Fri, 17 Sep 1999, Ruslan Ermilov wrote:
You know, natd(8) is not guilty, this is a bug in libalias(3) :-(
I have made a patch for this and yet another bug and will send my
patch for review to Brian Somers and Eivind Eklund.
Please let me know if you would like to test these patches, and
On Sun, 19 Sep 1999, Chuck Robey wrote:
But it was to the subject on the Subject: line, Julian. We know what side
you're on, but there are 2 sides to the argument. Isn't there some way
that it can be set up to *optionally* have permission persistence?
Seems like a devfsd using the file
31 matches
Mail list logo
