Re: so where is our press-release about MacOS X ?
At 11:18 PM -0800 3/24/01, Dan Feldman wrote: >You're right, there's no need to pick fights. But I'm just pointing out >that there's no reason FreeBSD should work particularly hard to create the >appearance of an alliance with Apple, when all they've done is use the >source of some kernel components and a number of utilities for a >commercial product. After all, Microsoft is rumored to have done exactly >the same thing at times and I have yet to see any press releases about a >relationship with _them_. Actually, Apple has done a bit more than that. As I understand it, they have given back fixes and plan to keep doing so. They have also started talking about how robust the underlying "BSD Unix" system is (I wonder if they'll be hearing from The Open Group soon :-). They have also made the command line available to every user and supplied a Developer CD with the distribution; finally, they have released their Mach and I/O Kit work as (almost :-) open source. In short, I think they are starting to get it; with some positive feedback, they might actually become a good neighbor. In the meanwhile, why not ride their publicity wave a bit. After all, they didn't base their work on Linux! -r -- http://www.cfcl.com/rdm - home page, resume, etc. http://www.cfcl.com/Meta/md_fb.html - The FreeBSD Browser email: [EMAIL PROTECTED]; phone: +1 650-873-7841 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Displaying options for current NFS mounts
On Sun, Mar 25, 2001 at 02:18:43PM +1000, Bruce Evans wrote: > On Sat, 24 Mar 2001, Dima Dorfman wrote: > > > I tried to export this stuff in struct statfs, but ran into a problem: > > I'd need the complete definitions of _args in , but I > > can't include, e.g., because the latter includes the > > former ()! > > mount.h used to know too much about all sorts of filesystems, but this > was fixed in 4.4BSD. It is impossible for mount.h or mount(8) to know > about all file systems, since filesystems can be dynamically loaded, > and ugly for it to know about more than 1 (or 0 -- ffs is too special). > > > The patch below kind of implements this functionality. I only export > > nfs_args (not _args), and I only modified mount(8) to print > > the NFS version, but printing the transport and others is simple from > > there. To work around the above problem, I pasted the struct nfs_args > > definition into mount.h. It is *horribly* ugly, but it does work. > > Only mount_foofs can reasonably know about the options for foofs. > perhaps mount(8) could fork-exec mount_foofs(8) to print options for > foofs. Or could mount(8) invoke a couple of sysctl's to get a string representation of each mountpoint's mount options? G'luck, Peter -- I am the thought you are now thinking. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Displaying options for current NFS mounts
* Peter Pentchev <[EMAIL PROTECTED]> [010325 00:38] wrote: > > > Or could mount(8) invoke a couple of sysctl's to get a string representation > of each mountpoint's mount options? > That seems like abuse of an interface. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/23620: Fore PCA200E driver
On Fri, 23 Mar 2001, Richard Hodges wrote: > I hate to follow up on my own post, but I have not heard a > word of comment, positive or negative... You're probably one of the few people that has the hardware to play with the ATM code in FreeBSD. This might account for your lack of feedback. Would you be interested in taking a more active role in maintaining the ATM code? I've got a couple of ATM driver related stuff on my TODO but it doesn't seem likely I'll get around to them any time soon. Regardless, I'll pester the release-engineer and see if I can get this committed. > On Fri, 2 Mar 2001, Richard Hodges wrote: > > > Hi, all! > > > > A couple months ago, I submitted PR kern/23620 describing a problem > > with the Fore PCA200E driver for HARP. It includes a description > > of the problems and a patch. > > > > Could someone commit this to STABLE so that it has a chance of > > making it into 4.3 RELEASE? > > --- >Richard Hodges | Matriplex, inc. >Product Manager | 769 Basque Way > [EMAIL PROTECTED] | Carson City, NV 89706 > 775-886-6477| www.matriplex.com > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/23620: Fore PCA200E driver
In message <[EMAIL PROTECTED]>, "Matthe w N. Dodd" writes: >On Fri, 23 Mar 2001, Richard Hodges wrote: >> I hate to follow up on my own post, but I have not heard a >> word of comment, positive or negative... > >You're probably one of the few people that has the hardware to play with >the ATM code in FreeBSD. This might account for your lack of feedback. > >Would you be interested in taking a more active role in maintaining the >ATM code? > >I've got a couple of ATM driver related stuff on my TODO but it doesn't >seem likely I'll get around to them any time soon. I can probably get away with sending a Fore and a efficient card to our new maintainer if we get one... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Displaying options for current NFS mounts
On Sun, 25 Mar 2001, Peter Pentchev wrote: > > Only mount_foofs can reasonably know about the options for foofs. > > perhaps mount(8) could fork-exec mount_foofs(8) to print options for > > foofs. > > > Or could mount(8) invoke a couple of sysctl's to get a string representation > of each mountpoint's mount options? > My bikeshed believes that string processing doesn't belong in the kernel :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Displaying options for current NFS mounts
In message <[EMAIL PROTECTED]>, Bruce Ev ans writes: >On Sun, 25 Mar 2001, Peter Pentchev wrote: > >> > Only mount_foofs can reasonably know about the options for foofs. >> > perhaps mount(8) could fork-exec mount_foofs(8) to print options for >> > foofs. >> >> >> Or could mount(8) invoke a couple of sysctl's to get a string representation >> of each mountpoint's mount options? >> > >My bikeshed believes that string processing doesn't belong in the kernel :-). I tore down my version of that bikeshed after I saw what kind of bogosities it resulted in. Sometimes ascii is the right API. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Displaying options for current NFS mounts
On Sun, 25 Mar 2001, Peter Pentchev wrote: > > Or could mount(8) invoke a couple of sysctl's to get a string representation > of each mountpoint's mount options? > This is not a bikeshed, but sysctl is the wrong interface to do this. Use VFSs/VOPs instead. This isn't a big problem with passing string from kernel to userland. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
doscmd
Hello, Does someone maintain/develop doscmd ? It looks like there were no more commits since 1999... Igor. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: so where is our press-release about MacOS X ?
[in reply to [EMAIL PROTECTED], 25-03-2001] > In the meanwhile, why not ride their publicity wave a bit. After all, > they didn't base their work on Linux! Yeah, but we could argue if this was a choice based on technical details or if FreeBSD was just picked for the BSD license (although I do run around yelling "HA!" at the local Linux evangelists all the time ;)) -- Walter Hop <[EMAIL PROTECTED]> | +31 6 24290808 | PGP key ID: 0x84813998 "we are in a race between education and catastrophy" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: so where is our press-release about MacOS X ?
At 3:52 PM +0200 3/25/01, Walter Hop wrote: >Yeah, but we could argue if this was a choice based on technical details >or if FreeBSD was just picked for the BSD license The NeXT work had been done on 4.3BSD, so both the code base and the implementors' background made the use of a BSDish platform a win. By moving to the Open Source versions of BSD and Mach, however, Apple got out of paying license fees. Given that they are selling the whole OS for $129, handing $50 of that to SCO (or Caldera or ???) wouldn't fly. Also, giving out the kernel source code allows external developers to write drivers and such far more easily. Although it is true that the Apple license is incompatible with the GPL, but compatible with the UC license, the fact that Apple has released the entire underpinnings of the OS makes this look like a fairly minor point. Bear in mind that Mac OS X includes GCC and such, so they still have to deal with _some_ GPL issues. These points aside, I would submit that Apple had looked fairly hard at Linux before choosing BSD. Specifically, they created and distributed MkLinux, a Mach-based version of Linux. In fact, there was a certain amount of yelling from the Linux camp when Apple chose BSD. BTW, it is my understanding that the final choice came down to BSD and Solaris (!). The choice between FreeBSD and NetBSD involves no legal issues, but does have some interesting technical twists. Apple initially said that they would "mix and match" pieces of assorted BSD distributions. I remember sending them a note which warned against doing this in a detailed way, as they didn't want to get caught up in a version-control nightmare. As it turned out, they decided to use the FreeBSD kernel and the NetBSD userland. This kept their version-control issues fairly simple, while giving them some technical benefits: * The NetBSD apps already worked on the PowerPC, so they didn't have to chase thousands of little architecture-specific issues. * For whatever reason, they liked the FreeBSD kernel. I don't know the exact reasons, but I'm sure there were some (otherwise, they would have gone with NetBSD for everything). -r -- http://www.cfcl.com/rdm - home page, resume, etc. http://www.cfcl.com/Meta/md_fb.html - The FreeBSD Browser email: [EMAIL PROTECTED]; phone: +1 650-873-7841 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
old business (was Re: Intel driver doc's Take 2.)
On Sat, 24 Mar 2001, Dennis wrote: > > If the if_wx driver sucks, why not fix it rather than trying to coerce a > mega-companies with a deep political structure to change is policies? > But if youre not going to maintain it, dont do it at all. You cant stick it to > users by deciding later that you dont want to support it anymore. I am going to fix it (but this has been low on my priority list- you got the bucks to pay for this, buddy, &and& make it more attractive then the other things I'm currently getting paid to work on? money talks...), and I *also* am trying to change Intel's policy. > I complained for days and then fixed the fxp driver in about 4 hours. Maybe > its time to do work and complain less. Work is good. Complaints just are. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
problems with: /usr/src/lib/libc
Hello, (concerning freebsd4.2 Release) I am a little bit in panic: why are all my .o files in /usr/obj/usr/src/lib/libc and not in /usr/src/lib/libc ? I changed syscalls.master, created new syscall, made headers in /usr/src/include and tried to make the libs via make install in /usr/src/lib/libc. (I did a cvs-update some time ago) What am I doing wrong? My kernel doesn't seem to like me any more and spits tons of messages like: ../../libkern/divdi3.c:42: quad.h: No such file or directory ../../libkern/moddi3.c:42: quad.h: No such file or directory ../../libkern/qdivrem.c:47: quad.h: No such file or directory How May I fix it? I am a little bit in panic due to deadline reasons, so please forgive me if question is stupid, thx a lot Jochen Kaiser -- Jochen Kaiserkind@IRCNET, phone +49 9131 85-28134 Network Administration mailto:[EMAIL PROTECTED] Regionales Rechenzentrum Universitaet Erlangen-Nuernberg, Germany GPG public key: http://www.uni-erlangen.de/~unrza2/public_key.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to disallow the build of modules
In message <[EMAIL PROTECTED]> Maxime Henrion writes:
: Here is a patch to select the modules you want and don't want.
: The patch is for /usr/src/sys/modules/Makefile from RELENG_4.
My patch is even simpler:
Index: Makefile
===
RCS file: /home/imp/FreeBSD/CVS/src/sys/modules/Makefile,v
retrieving revision 1.171
diff -u -r1.171 Makefile
--- Makefile2001/03/09 20:10:30 1.171
+++ Makefile2001/03/19 19:17:28
@@ -30,4 +30,8 @@
SUBDIR+=osf1
.endif
+.if defined(MODULES_OVERRIDE)
+SUBDIR=${MODULES_OVERRIDE}
+.endif
+
.include
I then put make
makeoptions MODULES_OVERRIDE="pcic pccard cardbus pccbb oldcard"
in my config file. This gives you the ability to opt into just those
modules you want. Yes, I know that it computes SUBDIR twice in
modules/Makefile, but I did that to minimize diffs between my Makefile
and the real one for easier merging.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: problems with: /usr/src/lib/libc
On Sun, Mar 25, 2001 at 08:09:31PM +0200, Jochen Kaiser wrote: > why are all my .o files in /usr/obj/usr/src/lib/libc and not in > /usr/src/lib/libc ? Because that is how our make framework works w/in /usr/src See the readme in /usr/share/mk/ > I changed syscalls.master, created new syscall, made headers in > /usr/src/include and tried to make the libs via > make install in /usr/src/lib/libc. ... > How May I fix it? cd /usr/src/lib/libc make cleandir make cleandir # do NOT do a `make obj' make depend make make install If that does not work, then rm -rf /usr/obj/* and try again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to disallow the build of modules
On Sun, Mar 25, 2001 at 11:23:20AM -0700, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Maxime Henrion writes:
> : Here is a patch to select the modules you want and don't want.
> : The patch is for /usr/src/sys/modules/Makefile from RELENG_4.
>
> My patch is even simpler:
>
> Index: Makefile
> ===
> RCS file: /home/imp/FreeBSD/CVS/src/sys/modules/Makefile,v
> retrieving revision 1.171
> diff -u -r1.171 Makefile
> --- Makefile 2001/03/09 20:10:30 1.171
> +++ Makefile 2001/03/19 19:17:28
> @@ -30,4 +30,8 @@
> SUBDIR+=osf1
> .endif
>
> +.if defined(MODULES_OVERRIDE)
> +SUBDIR=${MODULES_OVERRIDE}
> +.endif
> +
> .include
>
>
> I then put make
>
> makeoptions MODULES_OVERRIDE="pcic pccard cardbus pccbb oldcard"
>
> in my config file. This gives you the ability to opt into just those
> modules you want. Yes, I know that it computes SUBDIR twice in
> modules/Makefile, but I did that to minimize diffs between my Makefile
> and the real one for easier merging.
See -arch for a detailed discussion :)
G'luck,
Peter
--
What would this sentence be like if pi were 3?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to disallow the build of modules
In message <[EMAIL PROTECTED]> Peter Pentchev writes: : See -arch for a detailed discussion :) Right. I just did. I still think mine is *MUCH* simpler and easier to deal with. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
nmap 2.54B22 Permission Denied error
When testing the new -sO feature, I got this: bash-2.04# nmap -sO 10.0.0.1 Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) sendto in send_ip_raw: sendto(3, packet, 20, 0, 10.0.0.1, 16) => Permissi on denied Sleeping 15 seconds then retrying sendto in send_ip_raw: sendto(3, packet, 20, 0, 10.0.0.1, 16) => Permissi on denied Sleeping 60 seconds then retrying ^Ccaught SIGINT signal, cleaning up Note i'm root. My sniffer shows outgoing and incoming packets as expected, i.e. zero sized length packets of different protocols. This is -stable of Mar-14. Anyone else seeing this? Yonatan. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: nmap 2.54B22 Permission Denied error
One potential source of Permission Denied on a network socket for the root user is the ipfw system. Do you have IP firewalling enabled, using either ipfw or ipfilter, and if so, could those rules potentially be denying the packets being generated? If you have logging/counters available for those rules, do they go up when you run nmap? Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 25 Mar 2001, Yonatan Bokovza wrote: > When testing the new -sO feature, I got this: > > bash-2.04# nmap -sO 10.0.0.1 > Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) > sendto in send_ip_raw: sendto(3, packet, 20, 0, 10.0.0.1, 16) => Permissi > on denied > Sleeping 15 seconds then retrying > sendto in send_ip_raw: sendto(3, packet, 20, 0, 10.0.0.1, 16) => Permissi > on denied > Sleeping 60 seconds then retrying > ^Ccaught SIGINT signal, cleaning up > > Note i'm root. > My sniffer shows outgoing and incoming packets as expected, i.e. > zero sized length packets of different protocols. > This is -stable of Mar-14. > Anyone else seeing this? > > Yonatan. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Displaying options for current NFS mounts
Boris Popov <[EMAIL PROTECTED]> writes:
> This is not a bikeshed, but sysctl is the wrong interface to do
> this. Use VFSs/VOPs instead. This isn't a big problem with passing string
> from kernel to userland.
I like your idea of using the extattr interface. It isn't a perfect
match, since ideally this would be a VFS operation, but it works quite
well. The only modifications required are to mount(8) to try to get
this attribute, and then to any filesystem which wishes to support it.
Below is a patch which makes the necessary changes to mount(8), and
adds support for this to NFS. It's amazingly simple, and doesn't
interfere with anything else (i.e., you don't have to rebuild half the
world to use it). The only thing I don't like is that the "mountopts"
and "mountopts_verbose" constants aren't macroized, but that can be
easily solved (I just didn't know where to put them). With it,
mount(8) outputs stuff like this:
dima@spike% /sbin/mount -vt nfs
pid295@spike:/host on /host (nfs, v2, udp, hard, intr)
pid295@spike:/st on /st (nfs, v2, udp, hard, intr)
bazooka:/a on /.amd/bazooka/host/a (nfs, nodev, nosuid, v3, tcp, hard, intr)
bazooka:/b on /.amd/bazooka/host/b (nfs, nodev, nosuid, v3, tcp, hard, intr)
Comments? Suggestions?
Thanks in advance
Dima Dorfman
[EMAIL PROTECTED]
P.S. Would anyone have a fit if I wrote man pages for
extattr_get_file, extattr_set_file, and extattr_delete_file?
Index: sbin/mount/mount.c
===
RCS file: /st/src/FreeBSD/src/sbin/mount/mount.c,v
retrieving revision 1.41
diff -u -r1.41 mount.c
--- sbin/mount/mount.c 2000/11/22 17:54:56 1.41
+++ sbin/mount/mount.c 2001/03/25 22:16:14
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
@@ -505,6 +506,8 @@
int flags;
struct opt *o;
struct passwd *pw;
+ struct iovec iov;
+ char buf[128];
(void)printf("%s on %s (%s", sfp->f_mntfromname, sfp->f_mntonname,
sfp->f_fstypename);
@@ -515,6 +518,11 @@
(void)printf(", %s", o->o_name);
flags &= ~o->o_opt;
}
+ iov.iov_base = buf;
+ iov.iov_len = sizeof(buf);
+ if (extattr_get_file(sfp->f_mntonname,
+ verbose ? "mountopts_verbose" : "mountopts", &iov, 1) > 0)
+ (void)printf(", %s", iov.iov_base);
if (sfp->f_owner) {
(void)printf(", mounted by ");
if ((pw = getpwuid(sfp->f_owner)) != NULL)
Index: sys/nfs/nfs_vnops.c
===
RCS file: /st/src/FreeBSD/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.164
diff -u -r1.164 nfs_vnops.c
--- sys/nfs/nfs_vnops.c 2001/02/28 04:13:11 1.164
+++ sys/nfs/nfs_vnops.c 2001/03/25 22:16:14
@@ -62,6 +62,7 @@
#include
#include
#include
+#include
#include
#include
@@ -130,6 +131,7 @@
static int nfs_print __P((struct vop_print_args *));
static int nfs_advlock __P((struct vop_advlock_args *));
static int nfs_bwrite __P((struct vop_bwrite_args *));
+static int nfs_getextattr __P((struct vop_getextattr_args *));
/*
* Global vfs data structures for nfs
*/
@@ -169,6 +171,7 @@
{ &vop_symlink_desc,(vop_t *) nfs_symlink },
{ &vop_unlock_desc, (vop_t *) vop_stdunlock },
{ &vop_write_desc, (vop_t *) nfs_write },
+ { &vop_getextattr_desc, (vop_t *) nfs_getextattr },
{ NULL, NULL }
};
static struct vnodeopv_desc nfsv2_vnodeop_opv_desc =
@@ -3397,4 +3400,51 @@
}
}
return (VOCALL(fifo_vnodeop_p, VOFFSET(vop_close), ap));
+}
+
+/*
+ * Get extended attributes. Currently this is only used to retrieve
+ * filesystem-specific mount options for consumption by mount(8).
+ */
+static int
+nfs_getextattr(ap)
+ struct vop_getextattr_args /*{
+ IN struct vnode *a_vp;
+ IN const char *a_name;
+ INOUT struct uio *a_uio;
+ IN struct ucred *a_cred;
+ IN struct proc *a_p;
+ }; */ *ap;
+{
+ struct nfsmount *nmp = VFSTONFS(ap->a_vp->v_mount);
+ struct sbuf sb;
+ char *outp;
+ int outl, verbose = 0, error = 0;
+
+ /* XXX macroize "mountopts" and "mountopts_verbose"! */
+ if (strncmp(ap->a_name, "mountopts", 9) != 0)
+ return (ENOENT);
+ if (strncmp(ap->a_name, "mountopts_verbose", 17) == 0)
+ verbose = 1;
+
+ sbuf_new(&sb, NULL, 128, 0);
+ sbuf_printf(&sb, "%s", nmp->nm_flag & NFSMNT_NFSV3 ? "v3" : "v2");
+ sbuf_printf(&sb, ", %s",
+ (nmp->nm_sotype == SOCK_DGRAM) ? "udp" : "tcp");
+ if (nmp->nm_flag & NFSMNT_SOFT)
+ sbuf_cat(&sb, ", soft");
+ else if (verbose)
+ sbuf_cat(&sb, ",
Re: so where is our press-release about MacOS X ?
At 10:19 PM -0800 3/24/01, Dan Feldman wrote: >FOR IMMEDIATE RELEASE - 1 Apr 2000 > >SEATTLE - The FreeBSD Project, Inc. officially welcomed >today the introduction of Apple Computer's Mac OS X. The >next-generation operating system uses the TCP/IP stack >of an obsolete version of FreeBSD's flagship product, >and is otherwise completely unrelated. >:) > > - dan feldman >student, garfield high school, seattle While this is a good attempt at humor, I think it is not fair to Apple nor is it worthwhile to anyone. Apple had some people who contribute to freebsd directly (ie, they have commit access). Apple donated some hardware to help encourage FreeBSD/PPC along. Apple buys ads at several of the BSD-specific web sites. Apple has mentioned their connection to BSD's in several press releases. In short, Apple has been doing a hell of a lot more for freebsd (and all the BSD's, for that matter) then this little april-fool's article. And we're supposed to greet that positive publicity with sarcasm? At 11:18 PM -0800 3/24/01, Dan Feldman wrote: >You're right, there's no need to pick fights. But I'm >just pointing out that there's no reason FreeBSD should >work particularly hard to create the appearance of an >alliance with Apple, when all they've done is use the >source of some kernel components and a number of >utilities for a commercial product. After all, Microsoft >is rumored to have done exactly the same thing at times >and I have yet to see any press releases about a >relationship with _them_. You might want to think a bit more. Microsoft rarely admits that any of the BSD's even exist, whatever they may have done with some of the code. They do not donate anything to any BSD project. They do not sponsor BSD- related activities or web sites. At times they amuse themselves by spreading FUD about the BSD's, as they do with just about all open-source projects. If you were following the darwin mailing lists, you would know that Apple has plans to include more code from all the other BSD's, while still maintaining their own operating system. All of this is good for freebsd. Certainly I see no reason to rain on their parade. We CLAIM we want anyone to use our code for whatever they see fit, but when someone does that are we then going to give them a bunch of crap? Furthermore, the point of a press release isn't to help THEM, per se, it's to increase OUR visibility. Your suggested press release will increase our visibility in a very negative way. That is not the kind of visibility we will benefit from. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Locking and Mail spool Files
So, in a discussion a while back, it was established that file locking is basically broken under NFS. Does this mean that it is simply a REALLY BAD idea to put mail spool files on NFS mounts, or are there ways that programs like /bin/mail can correctly ensure consistency while reading in data ... ? Thanks! marc. Marc W, San Francisco, CA Kiltdown -- a free email client for X www.kiltdown.org -- it's what's underneath that counts. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Locking and Mail spool Files
Look for Alfred's commit of Mar 19th. There has been a *huge* overhaul of the nfs stuff and (I think) a working lockd. I haven't looked at it myself, so check it out for yourself. -gordon On Sun, 25 Mar 2001, Marc W wrote: > So, in a discussion a while back, it was established that file > locking is basically broken under NFS. Does this mean that it is > simply a REALLY BAD idea to put mail spool files on NFS mounts, or are > there ways that programs like /bin/mail can correctly ensure > consistency while reading in data ... ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Locking and Mail spool Files
Excellent, I will look for that. However, in the meantime, on older systems (3.x, 4.x, etc ...), is the below assertion correct? thanks! marc. Marc W, San Francisco, CA Kiltdown -- a free email client for X www.kiltdown.org -- it's what's underneath that counts. > - > From: Gordon Tetlow <[EMAIL PROTECTED]> > To: Marc W <[EMAIL PROTECTED]> > Cc: FreeBSD Hackers <[EMAIL PROTECTED]> > Subject: Re: Locking and Mail spool Files > Sent: 03/25/01 19:19> > > > Look for Alfred's commit of Mar 19th. There has been a *huge* overhaul of > the nfs stuff and (I think) a working lockd. I haven't looked at it > myself, so check it out for yourself. > > -gordon > > On Sun, 25 Mar 2001, Marc W wrote: > > > So, in a discussion a while back, it was established that file > > locking is basically broken under NFS. Does this mean that it is > > simply a REALLY BAD idea to put mail spool files on NFS mounts, or are > > there ways that programs like /bin/mail can correctly ensure > > consistency while reading in data ... ? > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Locking and Mail spool Files
In message <[EMAIL PROTECTED]> Marc W writes: : Excellent, I will look for that. However, in the meantime, on : older systems (3.x, 4.x, etc ...), is the below assertion correct? I ran mail over NFS for a while, as well as using a mail program that didn't do locking to sort my mail. In both cases I'd lose mail when two messages arrived at the same time. They would both be written to the same place in the mail spool file, causing all kinds of fun corruption that took weeks to track down. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Locking and Mail spool Files
On Sun, 25 Mar 2001, Marc W wrote: : :Excellent, I will look for that. However, in the meantime, on :older systems (3.x, 4.x, etc ...), is the below assertion correct? : You don't want to put mail spools on NFS filesystems. If you must, use the maildir format, ala qmail. David Scheidt -- [EMAIL PROTECTED] Bipedalism is only a fad. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
technical docs
hello, i was wondering if anyone knew where i could find some good documentation of freebsd internels, i am trying to get The Design and Implimentation of the 4.4BSD Operating System but for right now i am looking for some freely available docs on freebsd internels thanks :-) _ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Locking and Mail spool Files
In the last episode (Mar 25), Marc W said: > So, in a discussion a while back, it was established that file > locking is basically broken under NFS. Does this mean that it is > simply a REALLY BAD idea to put mail spool files on NFS mounts, or > are there ways that programs like /bin/mail can correctly ensure > consistency while reading in data ... ? As long as everything that touches your mailboxes use dotlocking, you should be safe. Use procmail as your local mailer, and make sure your mailreaders use dotlocking. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Mike Smith wrote: > > > On Fri, 23 Mar 2001, Daniel C. Sobral wrote: > > > > > Let me just pipe in a bit. Compromise seems just like the kind of thing > > > marketing or legal would want to do. The problem is that _we_ cannot > > > compromise because one cannot write a "half-way there" driver. It's a > > > technical impossibility. > > > > I agree 100%. I don't think this will fly either. I am just making the > > effort to work with Intel to get what we need. It's not going to happen > > overnight. Period. They are not going to change their NDA policy. In the > > future maybe. Actually I will forward the email she sent me this last time > > after I got off the phone with her an hour ago. I mentioned the problems > > Jonathan had with the GigE card. That's why she refers to him. Anyway I > > will forward it in a sec to the list. > > [Speaking here from some experience with this set of issues.] > > The compromise that you want to strike, and really the *only* compromise > that is going to work, is that the *documents* will remain undisclosed, > but information from the documents that is necessary to produce a > functional, high-performance driver may be disclosed, but *only* through > the source code of the driver. > > Thus one or a small group of people sign the NDA, and keep the > documentation. The driver is then developed and maintained by this team, > who also have the opportunity to interact with Intel's engineering > people. The source code resulting from this effort is then released > publically. Intel should probably retain the right to veto code that you > might want to put in the driver if they feel that it risks disclosure > they don't want, but you don't have to suggest this to them unless you > feel you need it as a bargaining chip. > > This would put them in the same situation as they are already in with > their source-available Linux driver; it should not present any more > intellectual property risks than they already face, and as a bonus, it > gets us a better-supported driver. In case anyone is truly interested in doing this, I have a "limited liability company" setup to do exactly this sort of work. If someone is interested in approaching Intel about this, under "contract" to my LLC, let me know via private e-mail. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: technical docs
On Sun, Mar 25, 2001 at 11:48:46PM -0500, Arthur Munn wrote: > hello, i was wondering if anyone knew where i could find some good > documentation of freebsd internels, i am trying to get The Design and > Implimentation of the 4.4BSD Operating System but for right now i am looking > for some freely available docs on freebsd internels Check out the various "Blueprints" articles published in Daemon News (www.daemonnews.org). They aren't exactly comprehensive, but the do provide good information about the systems they do cover. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: technical docs
For a while I was working on an OS Development section for COTSE (www.cotse.com), but unfortunately we never finished it. What I can recommend is 4.4BSD D&I, and (if you have the spendage, or have a friend who owns them) the MKM videos from www.mckusick.com. There's some _really_ great documentation about the FreeBSD VM, as well as the Mach VM (which FreeBSD's is/was based on). HTH, /joseph -- Joseph Mallett <[EMAIL PROTECTED]> http://www.xMach.org/ xMach - The 4.4BSD-like microkernel Operating System. On Sun, 25 Mar 2001, Brooks Davis wrote: > On Sun, Mar 25, 2001 at 11:48:46PM -0500, Arthur Munn wrote: > > hello, i was wondering if anyone knew where i could find some good > > documentation of freebsd internels, i am trying to get The Design and > > Implimentation of the 4.4BSD Operating System but for right now i am looking > > for some freely available docs on freebsd internels > > Check out the various "Blueprints" articles published in Daemon News > (www.daemonnews.org). They aren't exactly comprehensive, but the do > provide good information about the systems they do cover. > > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rtl8139 driver.
I currently have a Sharp pc ax20 laptop with an inbuilt rtl8139 nic. It works wonderfully well on my works 100 meg switched network, at home I have a 10 meg hub (can't afford a 100 meg switch yet) and it also works great for downloading off the net nat'ed off my adsl connection. Though copying internally to any of my windows / freebsd or linux machines I am lucky to acheive 4k/sec and the connections normally time out. All of the other machines on my network can do 700+ k/sec in between each other. I can only think it would be the driver that causes these problems, either that or it is not auto detecting the type of network that it is on in some way. Using win2k on same laptop I get normal speeds copying internally. I am using 4.3 RC If anyone has any ideas please let me know. I will probably end up trashing this machine anyways as my pcmcia DVD-ROM & usb floppy drive both stopped working after I cvsup'ed to 4.2-STABLE & haven't worked since. Cheers, Mark -- The Briggs/Chase Law of Program Development: To determine how long it will take to write and debug a program, take your best estimate, multiply that by two, add one, and convert to the next higher units. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rtl8139 driver.
[Charset iso-8859-1 unsupported, filtering to ASCII...] > I currently have a Sharp pc ax20 laptop with an inbuilt rtl8139 nic. It works i have an AX10, similar design i suppose, and it works fast and fine for me at 10megs. Are you sure the card isn't autoconfiguring for full duplex or something like that, killing other packets on the lan ? cheers luigi > wonderfully well on my works 100 meg switched network, at home I have a 10 meg > hub (can't afford a 100 meg switch yet) and it also works great for downloading > off the net nat'ed off my adsl connection. Though copying internally to any of > my windows / freebsd or linux machines I am lucky to acheive 4k/sec and the > connections normally time out. All of the other machines on my network can do > 700+ k/sec in between each other. I can only think it would be the driver that > causes these problems, either that or it is not auto detecting the type of > network that it is on in some way. Using win2k on same laptop I get normal > speeds copying internally. > > I am using 4.3 RC > > If anyone has any ideas please let me know. I will probably end up trashing > this machine anyways as my pcmcia DVD-ROM & usb floppy drive both stopped > working after I cvsup'ed to 4.2-STABLE & haven't worked since. > > Cheers, > > Mark > > -- > The Briggs/Chase Law of Program Development: > To determine how long it will take to write and debug a > program, take your best estimate, multiply that by two, add one, and > convert to the next higher units. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
making release without full CVS tree?
Hello there! I just read FAQ on making release and have one question. FAQ says I must be having full CVS source tree (or be able to access it via CVSROOT), but I'm behind modem connection. So I'm curious why it is not enough to have a cvsupped src-all/doc-all/ports-all collections? And is there a way to avoid loading CVS tree for making release and generate it from these collections? # Alexey PS. The goal is to make a CD with a 5.0 snapshot to install it at home (where I have no internet access) and keep it up-to-date by later burning cvsuppable collections on a CD-RW at work. -+-- "May the Sun and Water gently| mailto: [EMAIL PROTECTED] fall upon you!" (Supox, from SC2)| -+-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
