Re: will 9.2 be called 'diehard'? or maybe Naktomi?
On Aug 15, 2013, at 3:38 PM, Jakub Lach jakub_l...@mailplus.pl wrote: Well, that took me by surprise... That's probably the same thing 20th Century Fox's legal counsel said this morning. ;-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Kernel dumps [was Re: possible changes from Panzura]
On Jul 11, 2013, at 7:27 AM, Julian Elischer jul...@freebsd.org wrote: I could imagine that we could stash away a vimage stack just for this purpose. yould set it up on boot and leave it detached until you need it. you just need to switch the interfaces over to the new stack on panic and put them into 'poll' mode. That sounds like a rather clever solution to this problem (OS X doesn't support vimage, despite repeated attempts on my part to change that). How much work do you think it would take to bang out a proof of concept? Is anyone up to the challenge? Any incentives I can provide? This would be really useful. :-) - Jordan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] should crunchgen use basename(3) instead of homebrew code?
Wow. A couple of questions.
1. Is it really worth messing with code as old as crunchgen(1) at all?
Seriously. What's there isn't exactly broken, and it seems like needlessly
walking into a vampire's crypt without so much as a stake or clove of garlic on
your person. Only something bad can happen.
2. basename(3) also strips trailing '/' characters, which the code you are
replacing does not. Does this actually matter? Hell if I know, I haven't
looked at the inputs to that code in ages and I have enough common sense to
stay out of musty crypts, so I'm not going to look, either. :)
- Jordan
On Jan 1, 2011, at 11:37 PM, Eitan Adler wrote:
I'm not sure about this patch because of the behavior change of
-slash = strrchr(path, '/');
-basename = slash? slash+1 : path;
+bn = basename(slash);
CCed to the last few people to touch the relevant code (via svn praise)
Index: crunched_main.c
===
--- crunched_main.c (revision 216884)
+++ crunched_main.c (working copy)
@@ -33,6 +33,7 @@
*or calls one of them based on argv[1]. This allows the testing of
*the crunched binary without creating all the links.
*/
+#include libgen.h
#include stdio.h
#include stdlib.h
#include string.h
@@ -47,22 +48,21 @@
int main(int argc, char **argv, char **envp)
{
-char *slash, *basename;
+char *slash, *bn;
struct stub *ep;
if(argv[0] == NULL || *argv[0] == '\0')
crunched_usage();
-slash = strrchr(argv[0], '/');
-basename = slash? slash+1 : argv[0];
+bn = basename(argv[0]);
for(ep=entry_points; ep-name != NULL; ep++)
- if(!strcmp(basename, ep-name)) break;
+ if(!strcmp(bn, ep-name)) break;
if(ep-name)
return ep-f(argc, argv, envp);
else {
- fprintf(stderr, %s: %s not compiled in\n, EXECNAME, basename);
+ fprintf(stderr, %s: %s not compiled in\n, EXECNAME, bn);
crunched_usage();
}
}
@@ -70,14 +70,13 @@
int crunched_here(char *path)
{
-char *slash, *basename;
+char *slash, *bn;
struct stub *ep;
-slash = strrchr(path, '/');
-basename = slash? slash+1 : path;
+bn = basename(slash);
for(ep=entry_points; ep-name != NULL; ep++)
- if(!strcmp(basename, ep-name))
+ if(!strcmp(bn, ep-name))
return 1;
return 0;
}
--
Eitan Adler
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On May 10, 2007, at 8:20 PM, Garrett Cooper wrote: Yipes. The name of the game is to get something working in the base system, instead of dragging in multiple 3rd party packages, with licensing schemes that may not be aligned with the BSD license. SQL's great, SQL's wonderful for db use, but the problem is that supporting it from my POV would cause a lot more grief and waiting than having me wait a few months to get a BDB compatible scheme out the door. One of the issues here, however, is the fact that BDB is basically just a key/value database (and all the really robust versions from Sleepycat have licensing problems of their own). SQLite has an extremely liberal license and quite a bit of power besides (and Apple has contributed a considerable number of robustness-increasing fixes to it given that it's our embedded database of choice for quite a few applications). I wouldn't get too hung up on the database part of this in any case - packaging systems are difficult to create due to the fact that they're so broad, not because they're deep. There are a huge number of issues to resolve regarding upgrades, dependency tracking (which mutates somewhat in each of the install/delete/upgrade scenarios) and package creation and husbandry in general. - Jordan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD's netcat in base or ports?
I agree. FWIW, we bundled netcat in with Mac OS X's base distribution in Panther. I got a lot of requests for it before that and it's already come in handy several times, so I don't regret the decision at all. FreeBSD would benefit from having it in the base system. - Jordan On Jan 26, 2005, at 4:14 AM, Robert Watson wrote: It's always surprised me netcat isn't in the base system -- it's a very useful testing tool. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPC nsswitch implementation
Sounds similar to, but not as functional as, the lookupd in Mac OS X. :) On Mar 5, 2004, at 12:45 AM, Michael Bushkov wrote: We want you to look at this lookupd. It would be great for us to know if you like or not the way we made it. And we also want to know if this project can be added to FreeBSD project. -- Jordan Hubbard Engineering Manager, BSD Technology Group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPC nsswitch implementation
The Mac OS X lookupd does aggressive caching with cache invalidation support, supports the notion of flushing the cache on certain events (like when you reconfigure your network interfaces or switch authentication plugins), and quite a few other things. No surprise, really, given that it's been around for years. Julian was asking where to find it, and for those who get lost navigating Apple's darwin site, there's also opendarwin's cvsweb interface. Darwin's nsswitch implementation lives in Libinfo, of which lookupd is a sub-project: http://cvs.opendarwin.org/index.cgi/src/Libinfo/ - Jordan On Mar 5, 2004, at 6:46 AM, Michael Bushkov wrote: Hello! What do you mean exactly by saying not as functional? Michael Bushkov Software Engineer, Rostov State University On Fri, 5 Mar 2004, Jordan K Hubbard wrote: Sounds similar to, but not as functional as, the lookupd in Mac OS X. :) On Mar 5, 2004, at 12:45 AM, Michael Bushkov wrote: We want you to look at this lookupd. It would be great for us to know if you like or not the way we made it. And we also want to know if this project can be added to FreeBSD project. -- Jordan Hubbard Engineering Manager, BSD Technology Group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to [EMAIL PROTECTED] -- Jordan Hubbard Engineering Manager, BSD Technology Group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPC nsswitch implementation
Why not use a UNIX domain socket as the transport and then use credential passing to pass the credentials lookupd should use to do the lookup? On Mar 5, 2004, at 1:27 PM, Michael Bushkov wrote: When you're using current nss-modules they work as part of your program - and geteuid functions work correctly. But when lookupd is used, euid of the process is lookupds' euid. -- Jordan Hubbard Engineering Manager, BSD Technology Group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Another conformance question... This time fputs().
I submit for your consideration the following test program and the
wonderful variety of test results it produces:
#include stdio.h
#include errno.h
int main(int argc, char *argv[])
{
int rc;
FILE *fp=fopen(/dev/zero, r);
rc = fputs(Hello world\n, fp);
printf(errno = %d, rc = %d\n, errno, rc);
errno = 0;
rc = fwrite(Hello world again\n, 1, 18, fp);
printf(fwrite errno = %d, rc = %d\n, errno, rc);
fclose(fp);
}
On Red Hat Linux 9.0, it outputs the following:
errno = 9, rc = -1
fwrite errno = 9, rc = 0
Just to save you the grepping, errno #9 is EBADF, bad file number.
Now we KNOW that the mode on that fopen is (a) on a device which
doesn't allow writing and (b) of the wrong open mode (r rather than
w), but this discussion concerns the right thing to do when faced
with just these sorts of bogus situations and one could probably argue
that Linux returns the wrong errno here, but it does set errno.
What does FreeBSD do? It does this:
errno = 0, rc = -1
fwrite errno = 0, rc = 0
Given that it's just not kosher to write on a read-only fp and get no
error back at all, I would argue (though not passionately) for the
following diff to libc:
--- stdio/fvwrite.c 22 Mar 2002 21:53:04 - 1.15
+++ stdio/fvwrite.c 2 Mar 2004 08:40:25 -
@@ -43,6 +43,7 @@
#include stdio.h
#include stdlib.h
#include string.h
+#include errno.h
#include local.h
#include fvwrite.h
@@ -67,8 +68,10 @@
if ((len = uio-uio_resid) == 0)
return (0);
/* make sure we can write */
- if (cantwrite(fp))
+ if (cantwrite(fp)) {
+ errno = EACCES;
return (EOF);
+ }
#defineMIN(a, b) ((a) (b) ? (a) : (b))
#defineCOPY(n) (void)memcpy((void *)fp-_p, (void *)p,
(size_t)(n))
That gives us this behavior for our little test program:
errno = 13, rc = -1
fwrite errno = 13, rc = 0
In both cases, we get EACCES for fputs() or fwrite() attempts on a
read-only file pointer pointing to a read-only device, something we'd
expect to get permission denied for I think. In the case where we
open the fp for write access, the FreeBSD behavior is unchanged:
errno = 19, rc = 0
fwrite errno = 0, rc = 18
Which gives us ENODEV for the fputs(3) and no error for the fwrite(3).
I'm not sure why an error is returned at all in the fputs(3) case since
it seems perfectly valid to write onto /dev/null and simply have the
data be discarded, but that error is coming back from somewhere deeper
of the bowels of stdio and has nothing to do with my proposed diff in
any case. Red Hat Linux, interestingly enough, returns errno 25 in
this case (ENOTTY)!
This is your libc. This is your libc on SUSv2*. Any questions?
* References:
http://www.opengroup.org/onlinepubs/007908799/xsh/fwrite.html
http://www.opengroup.org/onlinepubs/007908799/xsh/fputs.html
--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer
Re: C++ code in a kernel module?
I can't believe nobody has yet suggested that FreeBSD switch to IOKit... On Sep 9, 2003, at 12:38 PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Matthew Emmerton [EMAIL PROTECTED] writes: : I've been silently following this thread, and unless I missed something, has : anyone asked John why he wants/needs to use C++ in the kernel? I refrained from posting the name of a good neurologist in Boulder that he could go see to get his head checked. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
I did try to get core to bless the libh effort and, in so doing, get more people to jump in and help Alex and Max, but it seems this particular bill's more like health care - nobody wants to touch it or sponsor it through the senate lest their names be linked with any failure. :-) - Jordan On Wednesday, June 18, 2003, at 11:57 PM, Terry Lambert wrote: It would be nicer if there could just be a land grant to one or two people over that area, and whatever they said goes, if you are inside those borders (Bob and Tom own the installer; you want to work on it, talk to one of them; you don't like a change that's happened, talk to them; if they're unresponsive, be prepared to have to find 66% of people to agree with you, because we're going to cut them a lot of slack, once they own the area). -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
On Wednesday, June 18, 2003, at 03:01 AM, Paul Robinson wrote: I hate sysinstall. I had some spare time and was going to start on something when Jordan piped up with libh. I'm not sure if libh was the right way to go anyway - it just prettied up sysinstall and made it more confusing to a novice user. Hmmm. That is an interesting statement given that libh has not made any attempt so far to pretty up sysinstall or has really provided anything in the way of an installer so far. The first and foremost goal of libh was to provide a set of base primitives which would deal with various architectural issues common to any installer effort, issues such as: 1. Providing a user interface abstraction layer so the same installer (whatever it ended up looking like) could end up running on X displays or serial consoles. 2. Providing reversible upgrades and a central software registration database so that the artificial distinction between things added via ports and things added via the base install could finally be removed. 3. Adding the notion of flexible security policies so that the administrator could choose how and where various packages were installed on the system, prohibiting rogue packages from splatting themselves just anywhere. These are just three of the challenges libh has taken on and by no means an exhaustive list. Nowhere, however, is any intention of making sysinstall more pretty or even following in sysinstall's footsteps in any way. If you've seen any UI's for libh to date, they've been essentially mock-ups who's sole purpose was to demonstrate the various capabilities of the UI abstraction layer. Most discussions around the various approaches to actual system installation have focused on how NOT to present UI to the user and to streamline the process for users who just don't care about the details and want to answer, at most, a question or two up-front about whether or not the installer should take over all disk space on the system or just the unpartitioned space and what sort of role the system is expected to play (desktop, server, etc). After that, the installer is expected to simply DTRT. If people want to discuss installation from the perspective of 'mechanism', I think they'd do better to focus on just how to break it into two parts: The installation bootstrap, which would be designed to be very small and largely do little more than find some larger media somewhere (CD, network, ...) establish where the system's boot partition is going to be and copy the 2nd stage install into it. Then you can reboot off the hard drive and get much fancier with a VGA16 X server or ncurses based installer which uses as much of the UI capabilities as are available depending on what the person doing the install is sitting in front of. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
The principal problem with libh is too many chiefs and not enough indians. Poor Alex and Max have done a HUGE amount of work on the system but it's large enough in scope that 2 people cannot hope to do it all by themselves, particularly when there's no relief shift to take things over when they get tired occasionally. From an architectural perspective, there's nothing which would stop libh from fulfilling all the dreams I've seen laid out here (and a number people haven't even mentioned yet, like scriptable installs or alternate look-and-feels). The principle thing standing in the way of this and every other let's get rid of sysinstall effort, for that matter, is a lack of engineers. This one's a bit like government. Everyone has an opinion about how it should work or what it could be doing better, but very few people want to actually get involved in changing it. :-) On Wednesday, June 18, 2003, at 08:23 AM, Samy Al Bahra wrote: Though, before we all get excited about the possibilities of such an installer, what's happening with libh? Isn't it supposed to deal with all of sysintall's short-comings? All I see now is a lot of talk and no code, maybe such discussion should go to libh's mailing list (where we can talk design there)? -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAPIB (was: Drawing graphics on terminal)
Sorry to hear you say that. It was probably the only effort (which attempted to solve the larger set of issues and not simply peck away at the problem piecemeal) to ever have any code associated with it. On Wednesday, June 18, 2003, at 08:40 AM, The Anarcat wrote: libh's dead, folks. It's been dead for a good while now. I was just kicking it to make it look like we could tear something out of this monster. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interview in Byte with Chris Sontag/SCO and FUD relating toBSDsettlement agreement
You can't. A provision of the settlement agreement was that none of the signatories could publish the settlement agreement. If I remember correctly, Chris Demetriou was the signatory for NetBSD, Rob Kolstad was the signatory for BSD/OS and I was the signatory for FreeBSD. The agreement was pretty clear on the fact that by signing the agreement and putting the mutual lawsuits behind us, Novell agreed that anyone based on 4.4Lite2 going forward would be free and clear. - Jordan On Tuesday, June 17, 2003, at 05:14 AM, Josef Grosch wrote: Where can one find a copy of the settlement agreement? -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD tar (was Re: Making pkg_XXX tools smarter about filetypes...)
Given ample personal experience with this issue, all I can say is that actions speak a lot louder than words where it's concerned. :-) I don't mean this in the usual and offensive put up or shut up sense either, believe it or not. It's just that I've seen literally years worth of discussion on this topic and all the threads generally wind up in exactly the same place: Everyone agrees that the format should support good compression, random access to contents (or at least a good and fast way of skipping over unwanted items), a library as well as command-line API for manipulation, rich and extensible metadata for file attributes/signatures/checksums/comments/etc etc, the usual laundry list. Then everyone starts pulling up various package file formats from the 70's and 80's (which is about when all of the current ones were designed) and arguing the pros and cons of each, none of which were exactly designed with the current range of file attributes and computing capabilities in mind so this leads to lots of the foo format sucks! kinds of comments. Eventually everyone gets tired and leaves the discussion for another few months/years. That is why the deadlock will only be broken by someone coming forward with a new file format AND implementation (library and command line API) on a plate, pointing to all of its obvious advantages and suitability for current needs and then seeking to evangelize that rather than getting trapped in the endless cycle of tar/zip/rar/zoo/arc/blah debates. - Jordan On Sunday, March 30, 2003, at 11:47 AM, Tim Kientzle wrote: I've given up trying to argue for a well-designed package file format. tar works well enough, I suppose. (Better than the oft-suggested 'zip' format. Ugh.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: magic symbolic links (ideas/patches?)
So did David Greenman. He did a fully general variant symbolic link implementation but never, AFAIK, released it. David? :-) - Jordan On Thursday, March 13, 2003, at 02:55 AM, Guido van Rooij wrote: IIRC Willem-Jan Withagen has done this years ago. I Cc ed him. -Guido On Wed, Mar 12, 2003 at 07:39:52PM -0500, John wrote: Hi Folks, I have a need to implement a highly specific variant usage of what are commonly referred to as magic symlinks, ie: /src - /.src/$ARCH/src where $ARCH needs to come from the user environment. A related patchset from NetBSD (1995) can be seen here: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=1781 In my specific implementation, the value of $ARCH will ALWAYS be 3 characters (Not having implemented anything yet, and to avoid possibly playing the userland game, I was thinking of adding a field to the proc structure and having the setenv/putenv functions place the value there via a sysctl, thus allowing a very simple interface... short sighted?). If anyone has any comments, or patches hanging around for this type of implementation, I would appreciate a pointer to them. Many, Many Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Guido van Rooij | Phone: ++31 653 994 773 Madison Gurkha, Technology Think-Tank | [EMAIL PROTECTED] | FreeBSD committer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Trailing whitespace in FreeBSD
If you take up sky-diving* and chain-smoking next, we're gonna be REALLY worried** about you, Peter! - Jordan * Obligatory trivia: I wonder how many remember that freefall was named after Rod's passion for the sport ** Not that we aren't already. On Monday, February 10, 2003, at 06:01 PM, Peter Wemm wrote: Jordan Hubbard wrote: Wow, deja-vu! Hey! I've got a GREAT idea! I whipped up this nifty perl script and I can run it over the src tree to delete all the trailing whitespace! And even better, I can collapse tabs at the beginning of lines! What a great deal! That should be good for a few hundred commits! :-) - Jordan On Monday, February 10, 2003, at 03:00 PM, Simon L. Nielsen wrote: Hello I have noticed that that several FreeBSD files (.c, .h and so on) have trailing whitespace (spaces/tabs after last charecter on a line). Should I send patches for this, or is it not important to fix? A random example is stdbool.h v. 1.6 on line 30 which has a trailing tab. -- Simon L. Nielsen mime-attachment To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Trailing whitespace in FreeBSD
Needed? Probably not. But look at it this way - he's learned a lot more about FreeBSD project history and why this one's such an exposed nerve in the process than he probably ever would have otherwise. Did he want to learn this? Well, we'll just have to let him answer that for himself. :) - Jordan On Monday, February 10, 2003, at 06:17 PM, Julian Elischer wrote: Um, is the sarcasm needed? The guy really does want to know if this would be helpful or not.. On Mon, 10 Feb 2003, Peter Wemm wrote: Jordan Hubbard wrote: Wow, deja-vu! Hey! I've got a GREAT idea! I whipped up this nifty perl script and I can run it over the src tree to delete all the trailing whitespace! And even better, I can collapse tabs at the beginning of lines! What a great deal! That should be good for a few hundred commits! :-) - Jordan On Monday, February 10, 2003, at 03:00 PM, Simon L. Nielsen wrote: Hello I have noticed that that several FreeBSD files (.c, .h and so on) have trailing whitespace (spaces/tabs after last charecter on a line). Should I send patches for this, or is it not important to fix? A random example is stdbool.h v. 1.6 on line 30 which has a trailing tab. -- Simon L. Nielsen mime-attachment To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 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 -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weak port system or how can I attract attention to my PRs?
Hmmm. This looks interesting. I'll review your patches this weekend, OK? - Jordan On Thursday, January 16, 2003, at 09:15 AM, Sergey Matveychuk wrote: Hi! For a long time I'v been disapointed with features in ports system. No ports conflicts checking and other stuff. Last year I'v begun make some things - I'v found obsoleted bin/13649 and ports/13650 PRs that introduce a ports conflics checking, I'v asked in freebsd-ports and portmgr about this patches fortune. I'v got an answer from portmgr: it's good features and could I adapt this patches for current bsd.port.mk and pkg_tools? I'v spend a weekend for rewriting patches (many changes really was done) and send it as followup to the PRs. It was 1 December 2002. Till now there is no reactions. I'v wrote a few mails to portmgr but I'v just ignored. Now I decide to make a new my own PRs: bin/47145 and ports/47156. Is there a chance somebody look on it and commit it? I'v got more ideas about improvement of bsd.ports.mk. Is interesting my patches to team? May be I'v just spend a time for nothing? I'd like to hear some reaction somebody of team. Comments, advises or so. Who can I talk about bsd.ports.mk improvements? Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Reading rc.conf from C programs?
You're somewhat mistaken if you think there was EVER any defined policy
with respect to this, it was simply a shell configuration file that
gained prominance as it went along, from its humble beginnings as
/etc/sysconfig or whatever it was we called it back then. There was
never any specific mandate that it be a key/value pair configuration
variable database, that was simply a de-facto standard and one which
was never clearly documented.
In hindsight, if we'd really wanted a key/value pair database then we
should have done it in XML and simply dealt with it at arm's length
through a accessor utility, e.g. instead of:
case ${ipsec_enable} in
We'd have:
case `sysconfig -r ipsec_enable` in
Or something to that effect.
If you're really looking for the real solution underlying this
problem then you need to look past the format being used at the moment
and at the fundamental problem it was originally trying to solve.
- Jordan
On Thursday, January 2, 2003, at 01:35 PM, Terry Lambert wrote:
[EMAIL PROTECTED] wrote:
Well, perhaps I'm missing something here, but can't you just tokenize
the items
in rc.conf using strtok after opening up the file in your C program?
You are missing something. Someone violated policy, and put
shell code into rc.conf, instead of leaving it a name/value
pairs.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Reading rc.conf from C programs?
There's no canned code for doing this, though sysinstall has some very basic parsing routines for reading/writing rc.conf variables you could certain crib from. It sounds like that thefish utility someone else mentioned has an even more exotic parser, though I haven't compared the two implementations. The readConfigFile() routine in sysinstall simply reads the configuration data into a fixed-size array, so it's pretty braindead. - Jordan On Wednesday, January 1, 2003, at 01:51 PM, Tim Kientzle wrote: I'm trying to figure out how to read and use /etc/rc.conf configuration variables from within a C program. The standard technique, of course, is to use a shell-script wrapper and pass the extracted values to the C program on the command line. But I want access to _all_ of the rc.conf variables, not just a couple of them, and I don't see any reasonable way to accomplish that with a shell wrapper. One approach would embed /bin/sh and drive that from my program. (E.g., tell the embedded interpreter to read and interpret the config file, then programmatically query the config variables.) It's not clear to me how simple it would be to build an embeddable /bin/sh. Alternatively, I suppose I could fire up /bin/sh via popen and drive it from my program (passing 'echo $var' to query variables, etc.). But I'm not entirely convinced this would work; what if a variable value has a newline in it, for example? Has anyone done anything like this before? Thanks, Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: /usr/src/ed/bin/re.c:99
It's legal, though one would have to know what the author was thinking
(or at least read the surrounding code) before stating that it's also
correct.
It's legal because, unlike the example given in that FAQ entry you
referenced, there's an implicit ordering in the expression that even
the most aggressive compiler optimizer couldn't change. In order for
the value of parse_char_class() to be returned, its arguments must
obviously be evaluated first and that means that ++nd will always occur
before the assignment operator.
Stylistically, of course, it's ugly as hell and would be dinged by any
CS professor grading this as homework. Is nd a local variable? If
so, why didn't the author simply pass nd + 1 as the argument since
the extra assignment from the unary operator is essentially wasted
cycles? Or is nd a global variable also referenced from within
parse_char_class(), thus requiring the use of the ++ operator and if
so, then why didn't parse_char_class() simply side-effect the global
rather than forcing a re-assignment from within the parent function?
Indeed, why is nd a global at all? These and other questions are left
as an exercise for the reader. :-)
- Jordan
On Wednesday, November 6, 2002, at 08:46 AM, Marc Olzheim wrote:
..
if ((nd = parse_char_class(++nd)) == NULL) {
..
Hmmm... is this legal ?
http://www.eskimo.com/~scs/C-faq/q3.1.html seems to tell otherwise...
Zlo
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Hotmail (was Re: Insider's scoop: Why FreeBSD is dying)
Can we maybe stop debating this and just have our postmaster do what he can to filter this kind of noise out? Recycled slashdot trolls are hardly the kind of content we want to see on [EMAIL PROTECTED] and what goes on in IRC has been repeatedly made clear to have nothing to do with the project on any official basis, so we don't need discussions of IRC behavior on hackers either. If we took it up in -hackers every time somebody dissed somebody else in IRC, we'd never have the bandwidth to discuss anything else. Filters? Please? Enough is enough. - Jordan On Sunday, August 18, 2002, at 10:34 AM, Terry Lambert wrote: Andy wrote: Remember that Hotmail is a part of MSN, and they would have a need for that many IP addresses, what with their Internet content service. Oh, I could definitely see Microsoft needing a lot of VIPs; they would need one per unique, deployed services, and potentially one per branding partner (depends on whether they expect a modern browser -- Host: being set correctly for virtual hosting). I'm pretty sure, that they have other address blocks, as well. 8-). For service availability, though, they would only really need a small number of VIPs per colocation facility, for a large and distributed service (basically, one per redundant virtual circuit path for initial distribution). So if they were widely deployed, you would expect maybe 8 VIPs per colocation facility... but you would not expect them to be in a large, contiguous netblock: you'd expect them to be 8 here, and 8 there, etc., based on geographic location. It's actually my understanding (I'm willing to be corrected here) that HotMail is pretty centrally served, because of the protocols involved, and because of their architecture. Anyway, I guess if I could get a full class B, I'd have one, and I wouldn't be questioning *why* someone had been willing to give it to me. 8-) 8-). It just seemed mighty strange. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Does FreeBSD have a problem with some AMD processors?
I'll bet you wouldn't have any trouble running -stable on it. There was a problem with MTRR support which still needs a little fixing in order to shut down properly but that's nowhere near as bad as X not running. Fix should be in FreeBSD 4.6 as well. - Jordan On Thursday, May 30, 2002, at 17:31 US/Pacific, Morsal Rodbay wrote: I recenetly bought an Athlon XP 1800+... and it turned out that it wouldnt run XFree. Everything worked well besides X. Since a workstation without X is useless I was forced to switch to WinXP and it's very stable so there is nothing wrong with the hardware which means it's a FreeBSD issue. 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: Does FreeBSD have a problem with some AMD processors?
I haven't read the AMD errata docs so I can't comment on that, but it appears to be an issue with AMD CPUs and certain support chipsets, I believe the early VIAs. Reading the cvs logs for the MTRR support code will certainly yield more detailed information (and author attribution) than I've provided. In fact, here, I'll simply do it for you. :-) RCS file: /home/ncvs/src/sys/i386/i386/i686_mem.c,v Working file: i686_mem.c head: 1.14 revision 1.14 date: 2002/04/14 20:13:08; author: dwmalone; state: Exp; lines: +53 -32 Make the MTRR code a bit more defensive - this should help people trying to run X on some Athlon systems where the BIOS does odd things (mines an ASUS A7A266, but it seems to also help on other systems). Here's a description of the problem and my fix: The problem with the old MTRR code is that it only expects to find documented values in the bytes of MTRR registers. To convert the MTRR byte into a FreeBSD Memory Range Type (mrt) it uses the byte value and looks it up in an array. If the value is not in range then the mrt value ends up containing random junk. This isn't an immediate problem. The mrt value is only used later when rewriting the MTRR registers. When we finally go to write a value back again, the function i686_mtrrtype() searches for the junk value and returns -1 when it fails to find it. This is converted to a byte (0xff) and written back to the register, causing a GPF as 0xff is an illegal value for a MTRR byte. To work around this problem I've added a new mrt flag MDF_UNKNOWN. We set this when we read a MTRR byte which we do not understand. If we try to convert a MDF_UNKNOWN back into a MTRR value, then the new function, i686_mrt2mtrr, just returns the old value of the MTRR byte. This leaves the memory range type unchanged. I'd like to merge this before the 4.6 code freeze, so if people can test this with XFree 4 that would be very useful. PR: 28418, 25958 Tested by: jkh, Christopher Masto [EMAIL PROTECTED] MFC after: 2 weeks - Jordan On Thursday, May 30, 2002, at 06:41PM, Darren Pilgrim wrote: Jordan K Hubbard wrote: I'll bet you wouldn't have any trouble running -stable on it. There was a problem with MTRR support which still needs a little fixing in order to shut down properly but that's nowhere near as bad as X not running. Fix should be in FreeBSD 4.6 as well. The MTRR issue you're referring to, is this related to the one in the AMD errata docs about SMM TSEG and large page mappings? Which CPUs does this bug affect? Is it AMD specific at all? -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel driver doc's Take 2.
Amen! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: linux expo san jose tomorrow
hey, is there gonna be a freebsd or bsd booth there tomorrow in san jose for that linux expo thing? I may go if there is a bsd booth... There will be a BSDi booth at the show. Look for the usual black monolith with the daemon on it. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /tmp on a ramdisk?
MD has supplanted MFS, it doesn't run in conjunction with it. Just consider MD the new name for MFS if it makes it easier. - Jordan On Fri 2000-07-28 (17:23), Doug Barton wrote: Ted Sikora wrote: A while ago several people suggested using /tmp on a ramdisk along with softupdates. Right now I am running several production servers with 4.1-STABLE with softupdates. I'm really happy with the performance. What benefits would I realize using /tmp on a ramdisk? CW on this is varied, but the current trend is that /tmp on a md is jus t a waste of ram, since (basically) everything in /tmp is in ram twice. I think that's MFS, not MD. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] 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
4.1-RELEASE will be tagged and done tonite, starting at 18:00 PDT
Just a heads-up to say that the last few issues have been dealt with and it looks like we're on target for a July 25th, 18:00 PDT (Pacific Daylight Time) tag and (as soon as that's finished) release operation. I'll be putting the i386 and alpha bits together throughout the night and will be shooting for some FTPable / ISO image bits on ftp.freebsd.org by early morning (the 26th). Thanks for all the hard work people have put into getting many important changes merged into 4.1! We may not have gotten every last minute cosmetic or semi-experimental hack into this release, but then that's not really the objective, either. :-) I'd say 4.1 looks like a good one. - Jordan
Re: sysinstall script disklabel problems -- help
I'm trying to automate most of the FreeBSD installation process via sysinstall's scripting mechanism. Its showing signs of life, but keeps barfing on the disklabel step. Below is appended my script. Do this instead: # the disks... disk=da0 partition=all bootManager=standard diskPartitionEditor disk label da0s1-1=ufs 102400 / da0s1-2=swap 1050624 none da0s1-3=ufs 1050624 /usr da0s1-4=ufs 1050624 /usr/local da0s1-5=ufs 204800 /var diskLabelEditor disk=da1 partition=all bootManager=standard diskPartitionEditor You want to do each disk "completely" before you move on to the next one rather than fdisking one, labelling it, then jumping back to fdisk. If you understood how truly evil a hack sysinstall's "scripting" was, you probably wouldn't need to ask why. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documentation selection in sysinstall
What happened to the plans to move to the TurboVision library? We're still working on it. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ieee1394 driver
Someone asked at the USENIX BOF about the status of ieee1394 driver for FreeBSD. For those who want to play with DV cameras, a set of tools to transmit DV streasms over IP is available from http://www.sfc.wide.ad.jp/DVTS/ It includes the ieee1394 driver presented at the last year's freenix. Thanks for the pointer, I see the latest set of patches are at: ftp://new-tremaine.cc.uec.ac.jp/pub/firewire/firewire-freebsd-4.0-2515 My question is simply: Why don't we bring this into the system? Is it for lack of manpower in committers or a desire from the development team that it stay a separate set of patches? Some observations on the code: Most of the cards they want to support are still on the TODO list, only one type of card being marked as fully working. Still, there's nothing like having users of your code to help that process along, so I wouldn't consider this reason enough to keep the code out. I'm not sure how I feel about /sys/net1394 as a new subdirectory for a lot of the lynx stuff. Is that really necessary? Most of the code patches straight into -current, though it's clear that a bit more work will need to be done to make it fully conform. Still, we need firewire support! Any suggestions on how to proceed? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documentation selection in sysinstall
And while I've got Jordan's attention -- did the last attempt at re-writing sysinstall generate any specification documents? If nothing else, they'd be useful content for the doc project. ] No, this is one of the items on my TODO list which I really really really have to get to soon or we'll never get Son Of Sysinstall finished. In theory, this is a doddle. sysinstall already lets the user choose from packages to install. In practice, I think it's a little more difficult, because: I'm still wondering why the docs bits can't be, at a minimum, "front-ended" by the ports collection in a new doc category? I can understand why you'd want to keep them in their own CVS repository section (doc/), but it would be cool if you could use ports to build and install (or make packages out of) the various documentation sets, especially now that there's talk of breaking up the handbook. Once that happened, you'd automagically appear in the INDEX and under your own category. No work would need to be done to sysinstall. My life would be easier. :) 2. We need to find a UI model that allows the user to efficiently select the language and formats they want to install. This wouldn't be quite so elegant, but perhaps Satoshi also wouldn't object to giving you more than one category under ports, just as the German, Japanese, Korean, etc. ports have done. It's either that or accelerate his efforts to go to a multi-layered ports collection so you could have sub-categories. That would lead to menu items like doc-english, doc-vietnamese, doc-french, etc. I'm thinking of initially presenting a dialog box that looks like this: I'm certain that once you start writing code for libdialog, my suggestions above will start sounding a lot less icky than they probably do to you right now. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3dfx driver for freebsd
Seeing as how it has been a link on Daemon News' front page for several months, I find that hard to believe. :-P Not all of us read daemon news, either. As far as I'm concerned, if it's not part of www.freebsd.org, it doesn't exist. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3dfx driver for freebsd
People still read .sigs? :) On Sat, 17 Jun 2000, Bill Fumerola wrote: On Sat, Jun 17, 2000 at 07:51:38PM -0700, John Baldwin wrote: Seeing as how it has been a link on Daemon News' front page for several months, I find that hard to believe. :-P ... and mentioned countless times in various mailing lists. And in all my .sigs :) Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-multimedia" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3dfx driver for freebsd
Coleman Kane [EMAIL PROTECTED] writes: Here's the address of the 3dfx device driver I wrote for freebsd: http://pohl.ececs.uc.edu/~cokane/ Please test it some more and give me feedback. Could someone please email m e with information on submitting this to the CVS commit team? did you register it at the BSD Driver Database ? http://www.posi.net/freebsd/drivers/ Probably not since he, like I, probably only just now heard about this "Driver Database" :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
So, I repeat: easily done, not acceptable to freebsd core. Erm, hello? I really don't understand this message at all, Ron. As far as I know, FreeBSD core has expressed NO opinion on this issue whatsoever and it's therefore highly unfair of you to state that we: a) Even have a firm opinion on the linuxbios effort b) Have already concluded it's "not acceptable" If you're talking about Mike Smith's comments then even the most elementary research on your part will turn up several pertinent facts: a) Mike Smith speaks purely for himself and states only his own opinion. Nobody appointed him "spokesperson for the FreeBSD community" any more than Jesus Monroy, Jr. holds that position. b) Mike Smith is not core. Thank you, - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Way off-topic, but anybody know how to resurrect files from FAT-12?
Actually, I have indeed dd'd the image off since I wasn't having any luck with the DOS utilities. :( - Jordan On Mon, Jun 12, 2000 at 05:32:31PM -0700, Jordan K. Hubbard wrote: Ah, I should also have noted that undelete.exe (which I also fetched from simtel) doesn't seem to work for me since it won't operate from a DOS box and if I shut down to DOS, the pccard services go away and I'm no longer able to mount the smartcard which I'd like to undelete files on. Catch-22. :( Use 'dd' to put the disk image somewhere persistant? Thanks for the suggestions so far though folks! - Jordan -- Brian 'you Bastard' Reichert [EMAIL PROTECTED] 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-ha nd path 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: Way off-topic, but anybody know how to resurrect files from FAT-12?
Ah, I should also have noted that undelete.exe (which I also fetched from simtel) doesn't seem to work for me since it won't operate from a DOS box and if I shut down to DOS, the pccard services go away and I'm no longer able to mount the smartcard which I'd like to undelete files on. Catch-22. :( Thanks for the suggestions so far though folks! - Jordan In the last episode (Jun 12), Jordan K. Hubbard said: I'm sitting here in Seoul, Korea (which is very nice, by the way) and I've just managed to delete all 82 images of Kyoto off the FAT-12 format Smartcard they were on. Wh! $ simx "undelete|unerase" Primary Mirror Directory simtelnet/msdos/dirutl/ FilenameType Length DateDescription = == derase.zip B13229 890201 Pgm to unerase files oz111.zipB83633 920918 Multiple-version undelete + HD Protection Primary Mirror Directory simtelnet/msdos/microsft/ FilenameType Length DateDescription = == pd0646.zip B21113 921209 Updated CHKDSK.EXE UNDELETE.EXE for DOS 5. 0 $ Try one of those, from your favorite Simtel mirror. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: An IA-64 port?
On Sat, 3 Jun 2000, Jordan K. Hubbard wrote: Intel has furnished us with IA-64 hardware and a porting effort is already underway. Contact [EMAIL PROTECTED] if you would like to help out in some way with the process. What can those of us just out here do? That depends on what resources you have. Some of you out there have IA-64 machines of your own due to affiliations your company might have with Intel, others of you are compiler / driver / kernel wizards who often work straight from specs just for the sheer perversity of it, if nothing else. :) In other words, you tell us! - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: An IA-64 port?
Is there any effort(or at least, any thought) on making an IA-64 port of FreeBSD? It seems Intel is trying to push IA-64 to be 'the platform' for servers and workstations, and I think FreeBSD definitely can't be left out Intel has furnished us with IA-64 hardware and a porting effort is already underway. Contact [EMAIL PROTECTED] if you would like to help out in some way with the process. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
So you are running this right before Usenix? Thats annoying - I've already booked a flight to San Diego on the 17th. Meeting *at* Usenix would be good though. Well, we can do that too since most of the engineers who will be in this meeting will be at USENIX as well (I can't speak for the Apple engineers who are attending the SMP meeting, but pretty much all the BSDi/FreeBSD people will be there). Sorry there was a scheduling conflict - we actually held this right before USENIX so that most people could fly directly from one event to the other. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
Kirk McKusick is planning an "all BSD BOF" which runs for about 4 hours (woo!). More details will be available on the BOF board and/or from Kirk when he's got them finalized. - Jordan Doug Rabson wrote: On Thu, 1 Jun 2000, Jordan K. Hubbard wrote: Does this mean we won't get the SMP stuff done next week? I'm back on the 15th (you gain 10 hours coming back) and the SMP meeting isn't until the 16th and 17th. Of course it will. :) So you are running this right before Usenix? Thats annoying - I've already booked a flight to San Diego on the 17th. Meeting *at* Usenix would be good though. By the way, is any FreeBSD event planned for Usenix ? I would be interested in meeting/looking at all the giants of FreeBSD thought :-) -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multilingual Installer for 3.2-RELEASE (Re: pccard boot.flp...)
Just following up on this - are there any plans to merge this work back into the mainstream so that we can generate "localized" installation floppies for the Japanese community in future releases? Thanks! (Yes, I'm really catching up on email over a year old today). - Jordan In [EMAIL PROTECTED] I wrote, Thank you. Now I'm working on updated sysinstall messages. I'll send the URL of message.lt_EN, *.TXT, *.hlp files to translate when I finished this work. I want translators to other languages. I finished updating indices of messages, and complied the first public test version. Currently, following binary package is compiled with English, Japanese and Korean support. As a result of increased size of boot.flp, Japanese and Korean support is now merged again into the same boot.flp image. http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/floppies-19990608.tar.gz (Compiled boot.flp, kern.flp, and mfsroot.flp binaries) http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/release-19990608.tar.gz (Patched source tree of /usr/src/release) http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/translation-kit-19990608.tar.gz (All you have to translate is this tarball) Current Translation Status: --- JapaneseKorean --- sysinstall messages: almost okay NG help files: NG almost okay --- -- HOSOKAWA, Tatsumi Assistant Manager Information Technology Center, Keio University [EMAIL PROTECTED] 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: I will be in Japan and Korea from June 7th through June 15th
Does this mean we won't get the SMP stuff done next week? I'm back on the 15th (you gain 10 hours coming back) and the SMP meeting isn't until the 16th and 17th. Of course it will. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0 - Isa devices not being probed
YesWhose brainstorm was it to use the new convoluted bus nonsense in FreeBSD 4.0? Clearly someone who never wrote a driver with a complex controller with indexed memory mapped registers.Whats next, assembler drivers If you cannot conduct yourself in a professional manner in these mailing lists, and my definition of "professional" here is "without needless invective or the usage of language virtually guaranteed to alienate anyone who reads your messages", then perhaps you should simply refrain from posting. I think everyone here has seen enough of your invective to last them several lifetimes and if insults are your primary objective then take it on the road with Don Rickles, stop attempting to communicate with those who's primary focus is engineering. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD kernel as a replacement for Linux kernel
Anyone remember the old Pyramid OSX 'universe' command?
Yes, I do. It was very evil. :)
The way Apollo solved this problem was much more elegant and general
purpose and one of my favorite soapbox topics: Variant symlinks.
Rather than using the "universe" concept for getting at a different
command set, Apollo gave you the ability to expand variable names
inside of symlinks, e.g. "ln -s /bin.${OSTYPE} /bin" would cause
/bin to point to /bin.sysv if OSTYPE=sysv or /bin.bsd if OSTYPE=bsd.
Using that, you could create something very similar to a Pyramid
dual-universe environment with the added bonus of also being able to
use it for localization purposes, selecting different documentation
sets, whatever.
Of course, every time we've had this discussion in the past, people
usually jump in and say that the environment variable space is
insufficiently powerful for this and what we really need is something
more like VMS logical names where you can have system-wide, group-wide
and user-specific variables which then are applied to the variant
symlink expansion.
At that point, everyone generally agrees that it's too hard to do and
we should put off the entire concept for another couple of years. :)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD kernel as a replacement for Linux kernel
I have in my archives some code from the "person" who usually brings up the logical name stuff (the code implements them). AIE. OK, I think this thread will probably die in *record* time now. I'm certainly running for the hills as we speak. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD kernel as a replacement for Linux kernel
1. You can run /compat/linux/bin/bash and then you in a sort of Linux/FreeBSD directory mix. The root directory looks just like your FreeBSD root, but changing to a directory that is in /compat/linux, like /bin, will put in the linux tree of this directory, but changing to a directory that doesn't exist, like /home, will keep you in the FreeBSD Well, what do you know - you're right! :) I learn something new every day. I've found the Linux emulation on FreeBSD to be one of the best, most integrated emulation I've ever seen of anything. I've messed around with it quite a bit and discovered quite a few nifty tricks you can do. I've never actually tried it, but I think you could probably compile Linux binaries under FreeBSD by installing the Linux version of gcc and using it. There used to be a linux-devel port which did exactly this. Don't know what became of it, however.. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Teaching sysinstall about the documentation packages
So, the time has come to think about ripping out the doc distro from "make release", and to teach sysinstall about these packages instead. Actually, if the doc distro becomes a set of packages then sysinstall doesn't need to know about them as a special case at all (which is good, every package dependency sysinstall gets is another millstone around my neck). They can just show up in the packages menu and people can select docs, if they wish, while they're selecting their favorite shells or editors. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD kernel as a replacement for Linux kernel
But seriously, I think the problem can be fixed with a more transparent interface for Linux programs. Rather than requiring Linux libraries to be put in /compat/linux, it would be much easier if everything could be put in /usr/lib. Which probably means having the SAME interface as Linux. That would also result in a highly undesirable mish-mash of binaries in one's /usr/lib, nor do I see the real advantage since the linux compatability shim will look in /compat/linux/usr/lib first anyway. Perhaps we should go just a bit further with that approach and make things _write_ into that hierarchy first as well, e.g. if you run /compat/linux/bin/bash and then install something with rpm, it will install (as far as it's concerned) into /usr/bin, /usr/lib, etc. but really be chrooted into the /compat/linux hierarchy and only affect things there. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What do people think of maybe using the sourceforge software?
Second, the projects page we have now, with all due respect to the people that try to keep it reasonably organised, is a mess due to the lack of updates. people only maintain their project pages perhaps, but certainly not the links that lead to them. Being able to work with more people on the same project on an equal bases would be a good idea IMHO. Well, I have to say that I installed and played with sourceforge for awhile and it's, well, highly dedicated to being sourceforge. The various product links *all* point back to sourceforge.com relative addresses and there's no concept of "$PROJECTNAME" or "$PROJECTBASE" to customize the sourceforge software for someone else, like the FreeBSD project. It's very much an example of a "code straight to the goal and for one purpose" implementation and, unfortunately, thus completely unsuitable for our purposes without some major hackery. Maybe if we could find something else... - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel SMP thread
Jordan said that the kernel SMP thread is ready in CURRENT FreeBSD, but I could not find any document for the SMP kthread. Huh? I never said any such thing. You must have misinterpreted something else I said. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel SMP thread
I asked a question "Is FreeBSD working on SMP thread?" at both USENIX and FreeBSDcon last year, you answered that it is already in the kernel, but there is no API for userland. Maybe we misunderstund each other :-( I answered that we had *kernel* threads but that there was no native API yet, just the "linuxthreads" kernel thread API. Actual SMP-capable kernel threads remain a pipe dream for us, however. Want to work on it? :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] Finding people with GSM phones (was Re: GPS heads up )
GCC and Compaq's proprietary compiler. Compaq's C compiler kicked GCC's ass in almost every metric. My questions: Is such a compiler available for *BSD? Not yet. Talk to your friendly Compaq sales rep and request it. :) Why is GCC so bad at Alpha optimization when it does so well on x86? Is somebody asleep at the wheel here? I don't know which "somebody" you're even referring to here, so it's hard to answer that question. gcc's alpha optimization will get better when somebody makes it better. The fact that it's weak has been a very well-known fact for over 4 years now, but everyone keeps waiting for "somebody" to ride up on his white horse, I guess. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump
Got a new ASUS K7V with AMD K7 700Mhz processor trying to install FreeBSD-4.0 from the kern.flp on ftp.freebsd.org. It dumps the registers immediately after saying Mount the kern floppy on another FreeBSD box and do some surgery on it along the following lines: mount /dev/fd0 /mnt rm /mnt/boot.config umount /mnt That should keep the -P flag out of your boot line and ensure that the keyboard is properly detected. I think our use of -P was over-eager since there are motherboards which don't play nice with it, like this one. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for the major device number
in the near future I'm going to release beta version of native, kernel side SMB/CIFS filesytem for FreeBSD. It uses device /dev/net/nsmbX You're a committer, just grab an available one. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: somewhat random mostly-lockups in 5.0
The syptoms are that the machine locks up. Hard. But there's a catch: Erm, Brian, You *know* nobody can debug a problem like this without hard information. It's like calling a mechanic on the phone and saying "My car won't go. It just doesn't move at all! Tell me what's wrong!" Compile in the kernel debugger and start hunting around when the system "locks up" next time. Just figuring out which wait address processes are stuck on would be a BIG HELP. Saying your machine locks up but is still pingable narrows it down to only several thousand lines of code. Even jlemon's "diagnosis" is of only marginal help without actually having access to the failing machine. - Jordan P.S. My -current box from April 6th has yet to do anything like this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-STABLE?
Yup.. however if you use.. " pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupit.tgz " It does not use it... It just asks questions.. Problem is (with 4.0 now being in the stable branch, that it now asks the wrong questions.. Mea culpa - I meant to fix this and got distracted away from it. Thanks for the reminder. The cvsupit package is now updated to deal with the current branch state of affairs, the cvsup 16.1 upgrade AND it's linked-to properly so that simply: pkg_add -r cvsupit Should now work just fine. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: md_image compression?
I'm sort of thinking in my head about adding the ability for the md driver to handle gziped images. md's drvinit() looks like And you can't load the kernel and the gzipped images from the boot loader, letting the boot loader decompress the stuff and just using the existing MD_ROOT option hook to load it? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver
It's also the case that there's never been anything in the release/3.x-STABLE or release/4.x-STABLE directories except a package link since those directories are there only for sysinstall, they're not for humans to go to and browse. Humans looking for actual source code for these branches should refer to the Handbook and then cvsup, CTM, etc. - Jordan Dennis wrote: Well its gone from cdrom.com which is where i usually get it cdrom.com has not been the correct location for a *long* time (like 4+ years!). The proper hostname is ftp.freebsd.org - that hasn't changed and the paths there are still perfectly valid. Cheers, -Peter 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: Why not gzip iso images?
Can I step in here for a moment? I'm not going to gzip the ISO images. Please just live with it. End of discussion. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting CPU usage in FreeBSD
I'm definitely for it... If I can get permission from Jordan, perhaps the attached patches can make it into upcoming release. I think it's a fine idea, I'm just not sure one day before release is the time to be talking about it. It should have been raised before now. :( - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
I hope I'm totally wrong and that FreeBSD will continue as it was before And I hope that people will actually wait to SEE if they're wrong before acting as if they really know how this is all going to turn out, as it appears you and several other people are already doing in extremely premature fashion. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
One day we will discover that we can't use FreeBSD as freely and / or with the same quality. I wish you doom-sayers would actually come up with some conclusive rationale for your fears here. Nobody has yet to come up with a single reason as to how or why all these disaster scenarios would come to pass and there has been considerable evidence to the contrary already presented here. All I see here are a lot of fears and unfounded statements about who BSDI are or what they're going to be in a year's time. If you think you know all the answers to those questions, please introduce me to your fortune teller! Otherwise, I'd say you're doing a lot more harm than good with this kind of speculation and have to seriously question your motives at this point. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
the equations are quite simple Only if you're taking powerful drugs, perhaps. There are a number of things which are hardly "simple" here and let's go over them: bsd/os = $$ for bsdi freebsd = lack of bsd/os sold by bsdi -- lack of $$ for bsdi False. If BSDI thought there was no money in selling support, consulting and training services for FreeBSD (none of which involve "selling bits") then there would have been no reason to merge the companies. You're thinking one-dimensionally here at best. merge + give code to freebsd -- lack of $$ but future investment bsdi unhappy to have given code but thinking to the future freebsd users happy of the new features I don't even understand quite what you're trying to say here, but even assuming that there are lots of new features we could become "addicted" to (and that's an awfully strange concept) indicates that you're not actually that familiar with the BSD/OS code base. There are SOME features we may be interested in going forward, but only some. It's the cooperative work we can do going forward in FreeBSD that interests me a lot more than BSD/OS's feature set now. If you want to do something more concrete than just spread FUD, however, then perhaps you can tell ME just what these features we're supposed to get and become addicted to are. Be specific! You've already thrown out enough vague and unsubstantiated crap to completely lose any credibility you might have once had here, so perhaps it's time for you to stop doing that. bsdi is doing everything to slow down the development of freebsd... AHA! And tell me please just how that's supposed to happen? Again, some credible specifics would be a good idea right about now. freebsd is late behind bsd/os some freebsd users have started to pay for bsd/os [too many drivers / features are missing in freebsd and bsd/os is the nearest compatible system so it's easyier to move from freebsd to bsd/os rather than to linux] And now I know you're off in the weeds somewhere, looking for a pipe. The actual reality of the situation is likely to be quite the opposite given that there are hundreds of FreeBSD developers and, at last count, somewhere around 10 BSD/OS developers. Since none of these hundreds of FreeBSD developers can be prevented from doing their work (and if you think so, again, be SPECIFIC as to how and why) I can't see how any of this makes any sense. In short, Didier, I think it's time for you to end this thread since you're clearly in the grip of a paranoia so deep that it borders on the clinical at this point. I don't see any rationality to your arguments, just a lot of fear and general hand-waving. I can understand the fear since these are new and uncertain times, but the hand-waving we can really do without. If you want to go run OpenBSD or NetBSD now, that's your choice and I daresay that there are now many here who would be quite happy to see you do so. This kind of insubstantial and unsubstantiated FUD we can all really do without. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
FreeBSD.org website, I quote the following, "BSDI will continue to distribute packaged versions of FreeBSD" Is this another way of saying that in the future that the distribution of FreeBSD may take on the Sun model for their "free" operating system software, which you pay $$$ for the media, and it is not freely downloadable from the net nor freely distributable? No, it is not another way of saying that. In fact, in other press announcements BSDI has been very clear in saying that it will offer the SAME degree of support that Walnut Creek CDROM did, and that includes making it available for download. Heck, if we stopped doing that I can also tell you exactly what would happen: Someone else would start making ISO images and putting them up on the net and CheapBYTES, who already sells CDs very cheaply, would make even more money. The FreeBSD genie is out of the bottle and has been for over 7 years now. Any attempts to put it back in are doomed to failure and everyone at BSDI knows this very well already. Do you folks honestly think I haven't covered this in great detail in our pre-merger discussions already? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?(NO)
Since WC didn't control any more than the server for the CVS tree, and since we all have mirrors of that thanks to cvsup, if they decided to make it unfree, then we as the FreeBSD development group would just nominate a different central server and life would continue as before, ... without them. Thank you for making this point. Sometimes I see things like this as being so obvious that I forget that others may not, in fact, see them at all. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
I am sure of the FreeBSD Projects intentions but like the previous post things can 'turn ugly fast with the greatest intentions' The fact a for-profit company controlling it's movements is cause for concern. How many different ways can we say this? THE COMPANY DOES NOT CONTROL THE FREEBSD PROJECT'S MOVEMENTS. It can't! - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
Corporations care only for their interests. Their stockholders will be pissed if they act otherwise. Do you really think there's something wrong with people who are scrutinizing this move? No, I only feel there's something wrong with those who are both scrutinizing it and jumping to a lot of premature conclusions about it. I expect scrutiny. I don't expect chicken-little running around and yelling about the sky falling. Your view of this will obviously be different from ours since you actually discussed this merger with BSDI --- Wait, JUST HOW LONG has this been going on anyway? You've probably been discussing this for at least more Since around August of last year, and if you think that it would have been prudent for me to discuss something as sensitive (to BSDI) as a potential merger in this mailing list then you're completely off-base. All through our discussions, BSDI was terrified that word would get out prematurely, their customers would hear about it, and sales of BSD/OS would drop to zero as everyone waited to see what the next move was. Which could very well have been nothing. I've been involved in two merger attempts which collapsed just hours before signing (that being when the real issues tend to come up) and we honestly weren't sure there WOULD be a merger until last Friday. BSDI requested our discretion on this until it was done-deal and we understood why. Now that said, we DID have some sensitivity to this taking people by surprise and that's why the entire core team also met with BSDI upper management last October and set some of the framework in place. We also sent out an announcement to everyone in -committers (the ostensible developers of FreeBSD), and that's over 150 people, last year when it looked like this might even be a serious prospect. Just getting BSDI to agree to let us do that was like pulling teeth, the "leak" prospects from over 150 people in-the-know being pretty big. If you think I could have just blythly discussed this in -hackers without shooting the whole deal dead in the process (BSDI would have considered that an irrevokable breach of trust) then there's certainly someone being stupid in this discussion, but it's not me. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
me..). WC/BSDI could take away the bandwidth. WC/BSDI could take away the hosting of servers, there are a ton of people with servers and bandwidth that would take over exactly what hub/freefall/bento/etc do right now. The USWest machines are living proof of that. I'd even venture to say that Jordan (and core) already have contingent plans for such a "disaster". We have more than contingency plans - we're seriously investigating moving everything to a co-location facility at this point purely for bandwidth reasons. As much as we've sincerely appreciated its use all these years, from a connectivity perspective Walnut Creek CDROM's T1 connection simply sucks. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
I guess it's a sad day for FreeBSD. I can't imagine how a company selling it's own BSD could at the same time let another BSD free. And I can't imagine how *anyone* could take this perspective given any of the stuff they've read so far. FreeBSD will remain, as I have gone to great pains to state in every interview I've granted, COMPLETELY UNCHANGED as far as being free and open is concerned. How could BSDI *not* let FreeBSD be free, perhaps I should ask you that? You know of some special way of herding cats that's been hitherto undiscovered, perhaps? I've been using FreeBSD since August 1994 (FreeBSD 1.1.5.1) If you think it's possible to bend the FreeBSD project to anyone's corporate will then you've never even come close to understanding who we are or what we stand for. That's a shame since one would think 6 years to be more than enough time to gain such an understanding. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
For the FreeBSD project : - many more supported platforms (Sparc, PowerPC, Arm ?) - better Intel SMP ? - new developpers ? - increased credibility via the support network of BSDi ? Hopefully all of those things, though just days after the merger is no time to be making promises either. All I can say is that each and every one of the things you mention have been discussed in positive terms. For BSD/OS : - better exposure thanks to OpenSource ? - Yahoo dollars ? - access to a greater community of **volunteer** testers ? All these things and: - the ability to provide support, training and consulting services to a much larger market - More direct sharing of open source technologies and being able to leverage some of the rapid pace of innovation there; it's not just our testers which are valuable. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
Will there be some kind of "business-like" presentation of all the goodies which will comme from this merge of codebases ? (BSD-mergemania for Dummies (TM) ?) I really couldn't say at this stage. Hopefully? :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sysinstall 'A'uto partitioning
For complete newbies, having "two formatting menus" seems weird too, and may be confusing. (I'm quoting one of my housemates). For complete newbies, you really only want to ask one question up-front: "Do you want to use all available disk space for FreeBSD?" If the answer is yes, you go do the rest on their behalf without asking anything more than, perhaps, what kind of installation they want (desktop, server, etc). If the answer is no, then you get into the more detailed questions. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sysinstall 'A'uto partitioning
For the level above that (and I count myself here) a merged menu might just be more user friendly. And I don't disagree. The only thing which prevented me from merging them to begin with was the fact that dialog/curses represent an insufficiently advanced UI technology for taking adequate advantage of the available screen real-estate. No scrolling list boxes and such make it necessary to simulate that kind of behavior in the application and I didn't have time to do that on top of everything else in sysinstall. Maybe Mr. Gold will handle this for us in his semi-mythical sysinstall rewrite. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sysinstall 'A'uto partitioning
The first time I installed freebsd, I picked numbers that were a little larger than the defaults for '/' and '/var', and still found myself needing to redo the entire installation in less than a week because /var was too small. That was fine enough And as you've seen by subsequent discussion, it's impossible to derive a "one size fits all" solution for something like /var. I would expect this to come out of the "I know where you want it, now what kind of install will this be?" question which the newbie installer gets to answer second. If they pick "mail server" from the menu then /var will get a totally different ratio % assigned to it. If they pick "personal workstation" then 20MB is, if anything, perhaps a little high. Or are you saying that the newbie option would just use the entire disk as one partition (the way that MacOS 10 server does...)? No, that's evil for a lot of reasons which I won't go into here. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sysinstall 'A'uto partitioning
No, that's evil for a lot of reasons which I won't go into here. :) I don't agree... A small /, and a huge /usr, with an additional var Not surprising since you're not even arguing with the point I was making. :) I said that a big / was evil. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sysinstall 'A'uto partitioning
Bottom line: I think it should stay the way it is now. :-) And since I agree, I suspect it will. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we can talk. Let's see how it does Quake, then we can talk. Alpha does quake? :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
The situation here, I hate to say, is that you were simply very lucky in having a software memory tester show you anything at all. If your experience had been more typical, you would have run memtest86 and it would have declared your memory to be free of errors. Then you'd have gone right on having problems and losing more hair until you finally just came back to the memory and swapped it out on suspicion. Bingo, the problems are suddenly fixed and you're dragging memtest86 to KDE's trashcan with a resolve to never trust it again. The reason why software memory testers are so generally ineffectual is that there's a whole bunch of things getting in their way. Leaving aside for the moment the nasty problem of having your memory checker loaded into the bad memory in question, the cache also seriously gets in your way (and I'll bet you never even thought to turn both L1 and L2 caches off, did you? :-) by masking errors in a way which is transparent to the program. How's it supposed to know its accesses are getting cached or how much cache it has to "defeat" to get meaningful access to main memory? It can't, really, at least not in a way that's truly foolproof or workable across the entire range of Intel/AMD CPUs it might be run on, and that's why serious bench techs use hardware memory testers exclusively. I've used all kinds of software memory checkers, from "CheckIt" to highly proprietary packages that cost even more money, and the only thing they managed to convince me of is that swapping in known-good memory is the best and fastest way out of these situations. Unless you have a hardware memory tester available, trying to test it yourself is just too likely to give you a false sense of security and send you down more blind alleys. I've even put known BAD memory into boxes and had CheckIt tell me "looks good to me, boss!", just to verify my suspicion that it had lied to me before. It's also very slow to run a software memory tester without the caches enabled and swapping the memory is generally a whole lot faster than that. I'm impatient. :) So, to summarize, I am actually somewhat against the idea of including tools like this on the grounds that they can also help to convince people of the wrong things while they're debugging a problem. I also don't look forward to having to argue with users who've just run such tests and are still getting signal 11's but now refuse to believe that the memory could be bad because "they checked it." If I then turn around and tell them not to trust the tool I also stuck on the CD for them, they're going to ask why I put it there in the first place and a nice long argument will then ensue instead of us just replacing that damn memory and moving on. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? Waiting for somebody at Intel to give us either hardware or simulator time. Without either of those things, "working on" Itanium support is a pretty pointless exercise. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for CD reorganisation for 4.0
It's something we've been considering. :) Hi, I was thinking (I know, I know, I shouldn't do that, it's bad for me ;)... Since we now have 3000+ ports, what are the chances of getting a special "FreeBSD Ports Distfiles" CD-ROM subscription set, which would just contain the distfiles? Since this set would be fairly low maintainance (just dump a copy of the FTP site onto CD :) it could be released at a low cost and with a fairly frequent update interval. I'm sure plenty of people would go for something which worked out to around $5 per month, including a lot of Linux people, since the CD would not have anything specific to FreeBSD on it. NetBSD and OpenBSD people should also be interested. This would also make the 4.0 set easier to get onto 4 disks, and it would do out of date slower (since the packages are prebuilt for that snapshot of -CURRENT). Another advantage is that we might be able to get rid of some NO_CDROMs, since the distfiles CD set would be around the cost of the media. Regards, -Jeremy -- |If I was not so weak, if I was not so cold, --+-- If I was not so scared of being broken, growing old, |I would be. I would be... frail. | - jars of clay / much afraid / frail 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
My views on Eclipse/BSD
Since everyone seems to be jumping up and down on this, I thought I'd just chime in with my two cents on the matter. I saw the Lucent folks behind this when they first brought a demo of Eclipse to FreeBSDCon '99 and, frankly, I was just pleased that they were willing to show up as exhibitors and to show it off at all. Now we see it more widely available under a license which allows us to play with it but not to sell it. Where's the harm in that? We can all still benefit from the experience of examining yet another type of approach in dealing with Quality Of Service issues. The truly interested can also use it as a springboard for looking past Eclipse and into the future of QoS systems, hopefully to then begin implementing something in the open source space which takes us to an even greater level of technical sophistication in FreeBSD's QoS infrastructure. None of that requires Lucent to be any more "open" than they currently are with the licensing of Eclipse and we really ought to be thanking them right now (instead of whining) for allowing us to take such an open and thorough look at their design strategies. It took a lot longer than for Plan9 to escape from Lucent and we should, if anything, be marvelling at the speed at which this has taken place at all. :-) I'd also venture to say that if such a next-generation QoS movement springs up as a result of what people see in Eclipse, it won't be long before these very same folks at Lucent are among the loudest voices of all, screaming for a truly OSS license and the ability to work cooperatively on Eclipse's follow-up act. By the very nature of software engineering Eclipse is already obsolete, and what we can learn from it going forward interests me a lot more than its license at the moment. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Yahoo under attack
Just saw it in the news, http://abcnews.go.com/sections/tech/DailyNews/yahoo000207.html Does anyone know the detail? I just exchanged email with David Filo this morning about this and it appears to have been a DoS attack using the usual array of stream/synflood tools. It also primarily hit the routers and FreeBSD 3.4 was largely unaffected (2.2 had some problems, but they were already in the process of upgrading those machines). There is some additional hardening work we can do here as a result of what was learned during the attack, however, and you should be seeing the relevant commits going into 4.0 shortly. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: enhancement of pkg_* tools
I'm planning to work on enhancing pkg_install tools following after NetBSD's effort. Seems they've been making some remarkable improvements over FreeBSD's original work since 1997. For example: As the author of these tools, I would welcome those sorts of enhancements. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (forw) Re: readdir_r thread safe?
Ugh, I should have brought this up before the code freeze but... I think that pretty much says it all, and reflects my own opinion on the matter. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Mailing list search engine at www.freebsd.org down for repair.
Hi all, Our primary mail server, using the special type of evil ESP abilities which all critical hardware items possess, took advantage of everyone (including our postmaster) being away at LinuxWorld in New York to exhibit the "F" in "MTBF" with respect to hard drive specifications. We have mail services running again on a backup system but it will take a little while longer until all other mail-related services (like web search) are restored. We apologize for the inconvenience and hope to have this problem fixed shortly. A situation almost exactly like this (disk hardware failure) occurred with freefall during FreeBSDCon '99, incidently, and with this second incident we've certainly gotten the message: All critical freebsd.org assets will use (hardware) RAID arrays for storage in the future and we'll begin implementing that just as soon as we return. Regards, - Jordan
Re: Why was rsh removed from the fixit floppy?
script. The script basically translates tar commands to cpio commands, which makes sense, since the cpio binary is a LOT smaller than tar. But there's no cpio on the fixit floppy... And there's no ifconfig on the floppy either, so why even bother with telnet/ftp/mount_nfs? You need to also look at what's on the mfsroot floppy because they're used in conjunction with one another. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Better fixit (was: Why was rsh removed from the fixit floppy?)
There's still space on there; what else could we put there? A copy of nethack to play while you're waiting for that fsck? [ducks] - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why was rsh removed from the fixit floppy?
I would *strongly* suggest to put rsh/rlogin + tar onto the root filesystem. I allways found these commands to be *extremely* useful in single user mode with all other partitions unmounted (e.g. when reorganizing the structure of my partitions/disks etc.) How about it? I doubt it. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Query??
1)Are BSD drivers not really documented?(I fear that I may not end up
re-inventing the wheel)
I assume that by "drivers" you mean "device drivers" in this context,
e.g. our code for supporting various network interface cards, SCSI
controllers, etc.
They are documented in the sense that there are various files one
refers to when writing a new device drivers in FreeBSD (usually
assorted header files and the sources to at least one related driver)
and the skillful kernel programmer generally knows where to look for
them. If there were no information at all, new device drivers would
never be written in FreeBSD.
They're not, however, documented in the sense that there's a well
laid-out DDK with lots of examples and high-level architectural
overviews of various subsystems. The new-bus system, in particular,
is in great need of documentation.
2)I am new in this field. Will it be possible for you to tell me from where
should I start as I dont have any experience in this field?
Start at the beginning. :)
Seriously, it is a bit like saying "I wish to build and fly my own
experimental airplane. I have no aviation or aeronautical experience,
however, so could somebody please tell me where I should start?"
Well, perhaps that particular question would be more easily answered
than yours ("with an excellent life insurance policy"), but I think
you get the basic idea. It's a very broad subject and there are
dozens of individual skills which go into producing a really good doc
set in this area. That's why it's work usually done by teams when you
get over to the corporate side of things.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Why was rsh removed from the fixit floppy?
Why was it removed? If there are no good reasons, please could somebody put back rsh onto the floppy! Currently I don't see how to do cloning easily without rsh? The fixit floppy is very full and its days as a truly useful tool are sort of numbered. By the way: How about putting the boot + fixit stuff onto a cdrom That's what CD #2 of every Walnut Creek CDROM product is. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Encryption rules changes coming up - win for open source
Have we had an opportunity to have the Walnut Creek (or other) legal staff review the actual rules for gotchas? No, this is something I hope to sit down with our corporate counsel over very shortly. It's an annoying drive to San Jose from here, but I'm prepared to make that sacrifice. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AIO was Re: Kernel threads
This is very interesting data and I was just wondering about the actual state of functionality in our AIO code just the other day, oddly enough. Does anyone have a PR# for the mentioned patches? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about GLIDE...
Though doug didn't say so, I think the equivalent code in freeBSD is
if ((fd = open("/dev/io",O_RDWR,0)) == -1) {
ERROR...
}
Correct, and I find it a little embarassing. I mean god, what a hack! :-)
There has just *got* to be a better way of granting (and checking for)
this privilege.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
I think the solution here is to change the release mechanism slightly. I believe we made a huge mistake splitting of the 4.x tree from 3.x so early. I was going to make a point about this, but thank you for making it for me. :-) My point was going to be that it was clearly not possible to please even a large fraction of the FreeBSD user base with respect to scheduling and Matt's statement above only underscores that in flashing neon. Those who were actually around at the time will remember that the -current branch had already gone "dot zero" with 3.0 and still we refused to branch 3.x-stable, despite great public pressure to do so. More months went by and finally the -current branch was running on 18 months with no branch, many feeling compelled to comment that we were supposed to "roll over" every 12 months and that this extra 6 month delay was unconscionable. Many arguments about how we were holding up progress and that volunteers were going to start wandering off to other *BSD projects were raised, along with more dire predictions, and finally enough was enough and we set a date by which all the late committers should get their stuff in so that we could finally branch the sucker. We did so and there was much rejoicing, at least up until now when various folks felt compelled to creatively reinterpret history and turn an "unconscionable delay" into a "precipitous rush to branch." I tell you, it's just not possible to win, especially when those doing the most yelling are always conspicuously absent when crunch time comes. Matt wasn't really fully on board at the time and I'm not pointing my finger at him specifically, but it seems like everyone's hindsight is 20-20 whereas their immediate vision concerning what needs to be fixed in a timely fashion often comes closer to the legal definition of blindness. If you want to make this or any other branch a decent release target, the time to start is not 10 days before it enters a feature freeze, the time to start is right after it branches! It's my hope that people will take this lesson more to heart when 4.0's own time to branch comes up. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
I've been with BSD a long time--from back when my email address was decvax!randvax!edhall. I want it to succeed, for reasons that are more emotional than rational; my nightmare was having to say that my project (1) worked on Solaris, (2) worked on Linux, but (3) broke FreeBSD. And I hope that you'll not hesitate to chime in the next time you run into a problem and not just wait for it to become the flame topic of the week. :-) If you have a hard time getting responses out of our developers, I'm also happy to offer my own phone numbers (both of which are in my finger entry at freebsd.org) and email address as a point of contact if something seems to be stuck and you need it fast-tracked. This is no more or less than I'd offer to anyone else in your position and I hope you realize that some people around here are more than willing to go the extra mile, with or without what others might consider a "proper bug report." - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
In otherwords, we should branch with the 4.1 release rather then the 4.0 release. Sounds a lot like 3.x to me. We didn't branch at 3.0 either, we branched one release afterwards and only after people threatened to mutiny if we didn't since the usual pattern up to that point had been to branch immmediate at the dot-zero. It didn't seem to help, as your own complaints would indicate. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
