Re: Discussion on the future of floppies in 5.x and 6.x
Daniel O'Connor wrote: On Thursday 08 January 2004 18:20, Avleen Vig wrote: I understand it is difficult to maintain the floppies. I wish I understood them better :-) Is it not possible to have ftp install floppies, which do nothing more than simple FTP installations? It wouldn't make it any easier. You still need the right drivers, ie which SCSI controller/network/... cards you have to get a minimal install is _more_ when you are doing FTP (you need a network). I think one possibility that wasn't mentioned is to have a floppy maintainer that generates several sets of floppies that are used for non-CD booting/no-CD installs which are available via download, and some are chucked on the CD. ie make it a separate part of the release, so it is not directly the install team's job. This would mean that the default 'make release' produces no floppy images. Instead they are built separately and bundled with 'official' releases. It would even be (fairly trivially) possible to setup a web site where you select what cards you want support for and it makes a floppy image for you. Even just having a page which tells you want card needs what KLD and where to get the KLD's would help, as you could download them on your other OS and put them on floppy yourself. Scott also said stuff like SCSI cards won't get probed if a module is loaded but I can't see why that is true.. The module will load, the device get detected, and then sysinstall is told to reprobe the hardware, so it should pick it up. Incorrect. Scanning SCSI buses is something that does not happen automatically. There is magic in the boot process that makes it happen near the end, right before the kernel looks for the root device. However, that is the exception to the rule. If you load a SCSI driver after the kernel has booted, the SCSI channel behind it will _not_ be probed automatically. Trust me on this one. Fixing this particular problem is well beyond the scope of fixing floppies in general. Until it gets fixed, floppies will just have to deal with it. I see the 'which kld goes with what device' problem as separate to this issue. The KLD load stuff DOES show a small description for each KLD so it isn't a total black box, and heck, you can just pick everything and cross your fingers :) Take something like the if_dc(4) driver. It covers literally _dozens_ of cards and chips, all under different brands and manufacturers. There is no way that a single line description file will tell you if your hardware is supported by the if_dc driver. But this is a minor nit. As I've stated before, loading kernel modules after the kernel has booted is the wrong time to do it. The loader needs to be enhanced to be able to take care of this. Once that happens, we can trivially modify the release scripts to allow an arbitrary number of driver floppies to be created, and the maintenance nightmare goes away for the most part. Well, except when mfsroot.gz becomes too large to fit on a single floppy. Right now it is about 90k away from that. What happens when mount_nfsv4 gets put on there? John Baldwin and I already spent a day over the holiday break making the mfsroot.gz image fit given the new requirements created by having a dynamic root. What happens the next time that it overflows? It's not like the driver floppies where you can dike more stuff to another disk; this is a single image. Do we come up with a method for having multiple, segmented images? Who writes the code to do that? If we are going to keep floppies, then we need people who are willing to tackle these issues and keep them under control. Scott Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Friday 09 January 2004 17:32, Scott Long wrote: Scott also said stuff like SCSI cards won't get probed if a module is loaded but I can't see why that is true.. The module will load, the device get detected, and then sysinstall is told to reprobe the hardware, so it should pick it up. Incorrect. Scanning SCSI buses is something that does not happen automatically. There is magic in the boot process that makes it happen near the end, right before the kernel looks for the root device. However, that is the exception to the rule. If you load a SCSI driver after the kernel has booted, the SCSI channel behind it will _not_ be probed automatically. Trust me on this one. Fixing this particular problem is well beyond the scope of fixing floppies in general. Until it gets fixed, floppies will just have to deal with it. Yech sucky :( I see the 'which kld goes with what device' problem as separate to this issue. The KLD load stuff DOES show a small description for each KLD so it isn't a total black box, and heck, you can just pick everything and cross your fingers :) Take something like the if_dc(4) driver. It covers literally _dozens_ of cards and chips, all under different brands and manufacturers. There is no way that a single line description file will tell you if your hardware is supported by the if_dc driver. But this is a minor nit. Yes.. As I've stated before, loading kernel modules after the kernel has booted is the wrong time to do it. The loader needs to be enhanced to be able to take care of this. Once that happens, we can trivially modify the release scripts to allow an arbitrary number of driver floppies to be created, and the maintenance nightmare goes away for the most part. I don't necessarily agree here - I think sysinstall is a better place because it's much much easier to write stuff for it than the loader. In the example you mention the only reason to use the loader is because the SCSI subsystem won't reprobe when a new SCSI bus comes online which sounds like a bug. BTW Does camcontrol rescan cause the devices to be detected? Perhaps sysinstall could be enhanced to perform this duty as part of it's reprobe machinations. Well, except when mfsroot.gz becomes too large to fit on a single floppy. Right now it is about 90k away from that. What happens when mount_nfsv4 gets put on there? John Baldwin and I already spat ent a day over the holiday break making the mfsroot.gz image fit given the new requirements created by having a dynamic root. What happens the next time that it overflows? It's not like the driver floppies where you can dike more stuff to another disk; this is a single image. Do we come up with a method for having multiple, segmented images? Who writes the code to do that? If we are going to keep floppies, then we need people who are willing to tackle these issues and keep them under control. I agree with that! :) However, given your example above, I would just put mount_nfsv4 on another floppy, although if sysinstall (or it's replacement) is too large, there will need to be the ability to load N floppy images into memory. However they're issues for floppy users ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
* Scott Long [EMAIL PROTECTED] [2004-01-09 00:02 -0700]: Well, except when mfsroot.gz becomes too large to fit on a single floppy. Right now it is about 90k away from that. What happens when mount_nfsv4 gets put on there? John Baldwin and I already spent a day over the holiday break making the mfsroot.gz image fit given the new requirements created by having a dynamic root. What happens the next time that it overflows? It's not like the driver floppies where you can dike more stuff to another disk; this is a single image. Do we come up with a method for having multiple, segmented images? Who writes the code to do that? Shouldn't lib/libstand/splitfs.c do this? Nicolas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 05:50:59PM +1030 I heard the voice of Daniel O'Connor, and lo! it spake thus: I don't necessarily agree here - I think sysinstall is a better place because it's much much easier to write stuff for it than the loader. In the example you mention the only reason to use the loader is because the SCSI subsystem won't reprobe when a new SCSI bus comes online which sounds like a bug. Indeed. I think it's actually (specifically and as a class) the sort of bug/feature that very much impacts on the floppy situation, since it prevents us from using an otherwise open road to move stuff around. Even if we have to write some code in sysinstall or its successors to trigger the rescan from userland (ie, the 'camcontrol rescan' point), I think that's a reasonable road (and likely the easier way). But that's a bit out of my depth. Well, except when mfsroot.gz becomes too large to fit on a single floppy. Right now it is about 90k away from that. What happens when mount_nfsv4 gets put on there? John Baldwin and I already spat ent a day over the holiday break making the mfsroot.gz image fit given the new requirements created by having a dynamic root. However, given your example above, I would just put mount_nfsv4 on another floppy, although if sysinstall (or it's replacement) is too large, there will need to be the ability to load N floppy images into memory. This is that situation where the fetch installer program thingy from install media on the fly solution comes into play. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Daniel O'Connor wrote: On Friday 09 January 2004 17:32, Scott Long wrote: Scott also said stuff like SCSI cards won't get probed if a module is loaded but I can't see why that is true.. The module will load, the device get detected, and then sysinstall is told to reprobe the hardware, so it should pick it up. Incorrect. Scanning SCSI buses is something that does not happen automatically. There is magic in the boot process that makes it happen near the end, right before the kernel looks for the root device. However, that is the exception to the rule. If you load a SCSI driver after the kernel has booted, the SCSI channel behind it will _not_ be probed automatically. Trust me on this one. Fixing this particular problem is well beyond the scope of fixing floppies in general. Until it gets fixed, floppies will just have to deal with it. Yech sucky :( I see the 'which kld goes with what device' problem as separate to this issue. The KLD load stuff DOES show a small description for each KLD so it isn't a total black box, and heck, you can just pick everything and cross your fingers :) Take something like the if_dc(4) driver. It covers literally _dozens_ of cards and chips, all under different brands and manufacturers. There is no way that a single line description file will tell you if your hardware is supported by the if_dc driver. But this is a minor nit. Yes.. As I've stated before, loading kernel modules after the kernel has booted is the wrong time to do it. The loader needs to be enhanced to be able to take care of this. Once that happens, we can trivially modify the release scripts to allow an arbitrary number of driver floppies to be created, and the maintenance nightmare goes away for the most part. I don't necessarily agree here - I think sysinstall is a better place because it's much much easier to write stuff for it than the loader. In the example you mention the only reason to use the loader is because the SCSI subsystem won't reprobe when a new SCSI bus comes online which sounds like a bug. One thing that FreeBSD _sorely_ lacks is the ability to easily use vendor-supplied driver disks. It is not unusual for a vendor to want to replace a buggy/incomplete driver that is in the base system with one that is better. This is incredibly difficult to do in FreeBSD; some drivers cannot be unloaded after being loaded, some drivers are compiled into the kernel for space considerations. If we design a mice interface for handling module loading/unload, multiple floppies, etc, in the boot-loader, then we solve this problem. Btw, I speak of this first-hand; not having a vendor-friendly method for updating drivers makes FreeBSD very, very hard to support, which means that FreeBSD is less likely to receive support. BTW Does camcontrol rescan cause the devices to be detected? Perhaps sysinstall could be enhanced to perform this duty as part of it's reprobe machinations. See my comment about blowing out the mfsroot.gz file. If you're not careful with this one then you'll wind up pulling in libcam, which will certainly create a size problem. Don't forget that some driver modules live on the same floppy as mfsroot.gz. Any increase in here means that another driver doesn't fit there and has to go somewhere else. Well, except when mfsroot.gz becomes too large to fit on a single floppy. Right now it is about 90k away from that. What happens when mount_nfsv4 gets put on there? John Baldwin and I already spat ent a day over the holiday break making the mfsroot.gz image fit given the new requirements created by having a dynamic root. What happens the next time that it overflows? It's not like the driver floppies where you can dike more stuff to another disk; this is a single image. Do we come up with a method for having multiple, segmented images? Who writes the code to do that? If we are going to keep floppies, then we need people who are willing to tackle these issues and keep them under control. I agree with that! :) However, given your example above, I would just put mount_nfsv4 on another floppy, although if sysinstall (or it's replacement) is too large, there will need to be the ability to load N floppy images into memory. Sysinstall is based on the concept that the root filesystem is populated with all of the tools that it needs. It has no concept of looking at other media/filesystems for tools. So, who is going to teach it how to do this? I personally think that this would be a hack anyways. If we need to support an mfsroot.gz that is too big for a single floppy, then we need to invent a way to span it across multiple floppies, not randomly put the tools individually onto whatever floppy isn't full this week. If we are going to do the work to keep floppies, then we need to put in a little effort to do it right and not turn it into a collection of miserable hacks (not more than it already is). Anyways, I've debated this as much as I can. I'm looking
Re: freebsd-hackers Digest, Vol 42, Issue 6
Anyone help me how to untar a file with this extention file.tar.bz2 ? Thanks, ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 8
I have a problem when recompiling my Unix Kernel. I want to enable ipchains modules. Besides this anyone can help me with a detailed docs to use Divert-Sockets to intercept and inject Packets? Thanks, ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Scott Long [EMAIL PROTECTED] writes: Incorrect. Scanning SCSI buses is something that does not happen automatically. There is magic in the boot process that makes it happen near the end, right before the kernel looks for the root device. However, that is the exception to the rule. If you load a SCSI driver after the kernel has booted, the SCSI channel behind it will _not_ be probed automatically. 'camcontrol rescan all' Take something like the if_dc(4) driver. It covers literally _dozens_ of cards and chips, all under different brands and manufacturers. There is no way that a single line description file will tell you if your hardware is supported by the if_dc driver. But this is a minor nit. 1) keep drivers for ISA devices in the kernel 2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI IDs of unclaimed devices, look them up in a list of supported PCI devices, and load the appropriate module. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 12:48:55AM -0700 I heard the voice of Scott Long, and lo! it spake thus: Daniel O'Connor wrote: BTW Does camcontrol rescan cause the devices to be detected? Perhaps sysinstall could be enhanced to perform this duty as part of it's reprobe machinations. See my comment about blowing out the mfsroot.gz file. If you're not careful with this one then you'll wind up pulling in libcam, which will certainly create a size problem. # $FreeBSD: src/release/i386/boot_crunch.conf,v 1.56 2003/01/23 08:30:47 ru Exp $ [...] progs [...] camcontrol [...] libs [...] -lcam [...] -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
YACINE GHANJAOUI [EMAIL PROTECTED] wrote: Anyone help me how to untar a file with this extention file.tar.bz2 ? tar xvfj file.tar.bz2 see man tar for details. greets, josef pgp0.pgp Description: PGP signature
Re: freebsd-hackers Digest, Vol 42, Issue 8
YACINE GHANJAOUI [EMAIL PROTECTED] wrote: I have a problem when recompiling my Unix Kernel. I want to enable ipchains modules. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html greets, josef pgp0.pgp Description: PGP signature
Re: freebsd-hackers Digest, Vol 42, Issue 6
On Fri, 9 Jan 2004, Josef El-Rayes wrote: YACINE GHANJAOUI [EMAIL PROTECTED] wrote: Anyone help me how to untar a file with this extention file.tar.bz2 ? tar xvfj file.tar.bz2 tar xvjf regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
Lukas Ertl [EMAIL PROTECTED] wrote: On Fri, 9 Jan 2004, Josef El-Rayes wrote: tar xvfj file.tar.bz2 tar xvjf i do not think that the order of the parameters have any influence on the result. -josef pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-08 16:36:30 -0800: On Thu, Jan 08, 2004 at 06:36:42PM +0100, Roman Neuhauser wrote: That might be technically true, but the precise semantics of (semi-)freeze aren't as widely known as you seem to think. E. g. yesterday or today I received an email from a committer in response to my two mails to ports@ (the first urging a repocopy requested in a PR some time ago, the other retracting the request because of the freeze) saying (paraphrased) to my surprise I was told repocopies are allowed during freeze. Some people just prefer to err on the safe side. Repo-copies are not allowed during the freeze, but are any other time. ok, so someone (at least two people) out there is confused about this, and this only further proves my statement about the uncertainty. Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) I would have thought the procedure to rectify this would be obvious: The procedure really is obvious, but there's only so much time in a day. Also, I would have thought the Porter's handbook would e. g. contain info on preventing installation of .la files (I gathered from the ports@ list that they shouldn't be installed), isn't this lack quite obvious? No, please raise this on the ports list. ok, cc'd to ports, Mail-Followup-To set. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
On Freitag, 9. Januar 2004 10:33, Josef El-Rayes wrote: Lukas Ertl [EMAIL PROTECTED] wrote: On Fri, 9 Jan 2004, Josef El-Rayes wrote: tar xvfj file.tar.bz2 tar xvjf i do not think that the order of the parameters have any influence on the result. No, but the filename has to be right after the f. The following commands work, and both have the same result: tar -jxvf file.tar.bz2 tar -jxf file.tar.bz2 -v but the following does not work as you expect: tar -jxfv file.tar.bz2 In this command tar(1) tries to extract the file v. Example error message: $ tar -jtfv xfce-4.0.1-src.tar.bz2 tar (child): v: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: xfce-4.0.1-src.tar.bz2: Not found in archive tar: Error exit delayed from previous errors $ Regards, Robert ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Friday 09 January 2004 19:37, Dag-Erling Smørgrav wrote: 2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI IDs of unclaimed devices, look them up in a list of supported PCI devices, and load the appropriate module. You know, when I wrote the code in sysinstall to load KLD's I thought about this.. Unfortunatly there IS no such list :( I am not sure how hard it would be to generate, but I think it's non-trivial (although probably not too difficult to maintain once it exists) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 02:00:40PM +1030, Daniel O'Connor wrote: You still need the right drivers, ie which SCSI controller/network/... cards you have to get a minimal install is _more_ when you are doing FTP (you need a network). Out of around 300+ installs of FreeBSD I've done over the last few years, about 12 of them were by CD. The rest were FTP kick-started off floppy. Normally, because I happened to have the two floppies I needed in my shirt pocket. Since 4.x I have never had a problem with drivers, depsite installing on a range of hardware from non-branded Taiwanese notebooks through to £30k enterprise servers. I don't see the problem with floppy install. However, as Jordan said when discussing libh (http://rtp1.slowblink.com/~libh/sysinstall2/improvements.html): As I mentioned in Section 2.3, one of the more annoying problems with FreeBSD's current distribution format is the dividing line between distributions and packages. There should really only be one type of distribution format and, of course, it should be the package (There Can Be Only One). Achieving this means we're first going to have to grapple with several problems, however: First, eliminating the distribution format means either teaching the package tools how to deal with a split archive format (they currently do not) or divorcing ourselves forever from floppies as a distribution medium. This is an issue which would seem an easy one to decide but invariably becomes Highly Religious(tm) every time it's brought up. In some dark corner of the world, there always seems to be somebody still installing FreeBSD via floppies and even some of the fortune 500 folks can cite FreeBSD success stories where they resurrected some old 386 box (with only a floppy drive and no networking/CD/...) and turned it into the star of the office/saved the company/etc etc. That's not to say we can't still bite that particular bullet, just that it's not a decision which will go down easily with everyone and should be well thought-out. I should point out, this appears to have been written some time ago, late 2002 I'm guessing. -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
New modem. Newbie need help.
Sorry for my basic knownledge about freebsd hacking and english language. Problem: i need to use an internal PCI modem, 56k. I found USR (NO winmodem) pci 56k but it were not right detect by freebsd. test# uname -rs FreeBSD 5.2-RC1 I add all his id in: src/sys/dev/puc/pucdata.c src/sys/dev/sio/sio_pci.c src/sys/dev/uart/uart_bus_pci.c copying and modifing existing similar USR modem pci. Now it's detect as: [EMAIL PROTECTED]:20:0: class=0x078000 card=0x00c412b9 chip=0x100712b9 rev=0x00 hdr=0x00 vendor = '3COM Corp, Modem Division (Formerly US Robotics)' device = 'ERL3263A-0 USR 56k Internal DF GWPCI PC99' class= simple comms It has not a subclass UART, so i have not a cuaa*. Any ideas? Verbose dmesg: http://moto.bmm.it/dmesg Thanks -- Cristiano Deana - FreeCRIS Ho iniziato a usare FreeBSD perche' m$ usava me. ed e' spiacevole in irc su: irc.azzurra.org #freebsd-it ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On 2004.01.08 21:39:07 -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Gary W. Swearingen) writes: : and the Copyright page has that plus a similar claim for : FreeBSD, Inc. (For 2004, even.) That should be changed. To? I have noticed FreeBSD, Inc on the copyright page a few times, but I never really knew what to replace it with. -- Simon L. Nielsen FreeBSD Documentation Team pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
On Thu, 08 Jan 2004 17:29:34 + Doug Rabson [EMAIL PROTECTED] wrote: The three main showstoppers for moving FreeBSD to subversion would be: [...] 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. subversion properties (svn propset) would allow you to do this in a satisfactory manner. -- +---+ | Samy Al Bahra | [EMAIL PROTECTED] | |---| | B3A7 F5BE B2AE 67B1 AC4B | | 0983 956D 1F4A AA54 47CB | |---| | http://www.kerneled.com | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Where is FreeBSD going?
Hello, Doug! Thursday, January 8, 2004, 8:29:34 PM, you wrote: DR 3. Converting the repository. This is a tricky one - I tried the DRcurrent version of the migration scripts and they barfed and died DRpretty quickly. Still, I'm pretty sure that the svn developers DRare planning to fix most of those problems. From mailing-list DRarchives, it appears that they are using our cvs tree as test DRmaterial for the migration scripts. Did you try my (pure-perl) vatinat ``RefineCVS''? http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.76.783.tar.gz But, please, read documentation carefully before reporting bugs -- many errors could be avoided with command-line options, sctipy is paranoid by default. Some parts of FreeBSD repository could not be converted, because contains revisions like 1.2.1 and other `I don't know what I should think about this' errors. If you have some good ideas -- let me know :) -- Lev Serebryakov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
Robert Klein [EMAIL PROTECTED] wrote: On Fri, 9 Jan 2004, Josef El-Rayes wrote: i do not think that the order of the parameters have any influence on the result. No, but the filename has to be right after the f. The following commands work, and both have the same result: In this command tar(1) tries to extract the file v. have you noticed that i am _not_ using the '-'? tar xvfj file.tar.bz2 - if you leave the '-' away then tar does not care about the order of the parameters. when you are using the dash before the arguments than the 'f' has to be just before the filename. tar -xvjf file.tar.bz2 - why this is the case i have not found out, perhaps it is a features, or just a bug :) -josef pgp0.pgp Description: PGP signature
Re: freebsd-hackers Digest, Vol 42, Issue 6
On Friday 09 January 2004 11:27, Robert Klein wrote: On Freitag, 9. Januar 2004 10:33, Josef El-Rayes wrote: Lukas Ertl [EMAIL PROTECTED] wrote: On Fri, 9 Jan 2004, Josef El-Rayes wrote: tar xvfj file.tar.bz2 tar xvjf i do not think that the order of the parameters have any influence on the result. No, but the filename has to be right after the f. The following commands work, and both have the same result: tar -jxvf file.tar.bz2 tar -jxf file.tar.bz2 -v but the following does not work as you expect: tar -jxfv file.tar.bz2 In this command tar(1) tries to extract the file v. Example error message: $ tar -jtfv xfce-4.0.1-src.tar.bz2 tar (child): v: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: xfce-4.0.1-src.tar.bz2: Not found in archive tar: Error exit delayed from previous errors $ Remove the - from the front of the options-list and it will work in your last example. So Josefs statement was correct. What I'm asking me, is why the - makes a difference, though I haven't looked at the sources, yet. The manpage states, that the - is only optional, so tar -jxfv and tar jxvf should be equivalent, but obviously they are not. Markus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
On Fri, 9 Jan 2004, Markus Brueffer wrote: MBOn Friday 09 January 2004 11:27, Robert Klein wrote: MB On Freitag, 9. Januar 2004 10:33, Josef El-Rayes wrote: MB Lukas Ertl [EMAIL PROTECTED] wrote: MB On Fri, 9 Jan 2004, Josef El-Rayes wrote: MBtar xvfj file.tar.bz2 MB MB tar xvjf MB MB i do not think that the order of the parameters MB have any influence on the result. MB MB No, but the filename has to be right after the f. The following MB commands work, and both have the same result: MB MB tar -jxvf file.tar.bz2 MB tar -jxf file.tar.bz2 -v MB MB but the following does not work as you expect: MB MB tar -jxfv file.tar.bz2 MB MB In this command tar(1) tries to extract the file v. MB MB Example error message: MB $ tar -jtfv xfce-4.0.1-src.tar.bz2 MB tar (child): v: Cannot open: No such file or directory MB tar (child): Error is not recoverable: exiting now MB tar: Child returned status 2 MB tar: xfce-4.0.1-src.tar.bz2: Not found in archive MB tar: Error exit delayed from previous errors MB $ MB MBRemove the - from the front of the options-list and it will work in your MBlast example. So Josefs statement was correct. MB MBWhat I'm asking me, is why the - makes a difference, though I haven't looked MBat the sources, yet. The manpage states, that the - is only optional, so MBtar -jxfv and tar jxvf should be equivalent, but obviously they are not. Old tar (v7) and Posix (well, SUSv2) have no dash before the key (the first argument to tar). They take option values from the next arguments in the order the options appear in the key string: tar xfbv file.tar 2 x - no arg f - take next arg (file.tar) b - take next arg (2) v - no arg. Using a dash is a gnu-ism and should be avoided in scripts. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Where is FreeBSD going?
On Fri, 9 Jan 2004, Lev Serebryakov wrote: Hello, Doug! Thursday, January 8, 2004, 8:29:34 PM, you wrote: DR 3. Converting the repository. This is a tricky one - I tried the DRcurrent version of the migration scripts and they barfed and died DRpretty quickly. Still, I'm pretty sure that the svn developers DRare planning to fix most of those problems. From mailing-list DRarchives, it appears that they are using our cvs tree as test DRmaterial for the migration scripts. Did you try my (pure-perl) vatinat ``RefineCVS''? http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.76.783.tar.gz But, please, read documentation carefully before reporting bugs -- many errors could be avoided with command-line options, sctipy is paranoid by default. Some parts of FreeBSD repository could not be converted, because contains revisions like 1.2.1 and other `I don't know what I should think about this' errors. If you have some good ideas -- let me know :) Huh? Whats wrong with revision 1.2.1 ? This is perfectly normal cvs revision number, even if you have to use a command line option to get it. But it should not require any kind of special treatment. -- Lev Serebryakov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
M. Warner Losh [EMAIL PROTECTED] writes: Ryan Sommers [EMAIL PROTECTED] writes: : Something like this might also jeopardize the : project's not for profit status. The project is not a legally incorporated entity at this time, and never has been in the past. And yet the Legal page carries a claim of copyright for The FreeBSD Project and the Copyright page has that plus a similar claim for FreeBSD, Inc. (For 2004, even.) I've not seen a US statute about false copyright claims, but I think it would be less risky to say all intellectual property is owned by its owners, in the manner of some trademark statements. The Legal page could tell about using CVS to determine who owns what so they can be tracked down and asked if the copyright page is correct about what license they've got it under. :) Whether the project is for profit depends upon the definition, if the project is claiming copyright ownership, because gains of intellectual property is considered (by US copyright law, at least) to be a financial gain. But lots of organizations, formal and informal, have financial gains without problems with being considered for profit, so if someone sees for profit problems, they should be specific about what the problems might be. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Leo Bicknell wrote: I'm going to propose a different solution that was brought up about two years ago (although I can't find it now). You start with something like the CD boot image mentioned, that is a 3-5 Meg iso image that basically contains what is now on the floppies (perhaps with a few more drivers/modules) and nothing more. Downloading and burning to CD would be the primary method of install. Then, to replace the current floppy process, a new floppy installer is created. It may or may not be based on FreeBSD, but what it I guess a simple variation would be to split the CD boot filesystem into multiple floppies. Then remove the current contents from the MFSROOT floppy and put there a small program (plus possibly the first part of the split CD filesystem image) that would load the boot filesystem from the bunch of floppies into memory, load the extra kernel modules, and then start the installer from memory just as it would go when booted from CD. That should really be a no-brainer as long as the base kernel still fits onto one floppy. The only inconvenience is that we get something like 6 install floppies instead of 2, but it's not _such_ a big deal. -SB ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
M. Warner Losh [EMAIL PROTECTED] writes: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Gary W. Swearingen) writes: : : And yet the Legal page carries a claim of copyright for The FreeBSD : Project It is a psudonymous work by The FreeBSD Project. Are you saying that The FreeBSD Project is a pseudonym for many of individuals, or what? And why does it matter with respect to whether an extra-legal entity may claim copyright ownership? : I've not seen a US statute about : false copyright claims, but I think it would be less risky to say all : intellectual property is owned by its owners, in the manner of some : trademark statements. No, the above is perfectly legal under US and International Copyright law. Well, I know that it's legal to omit one's own copyright claim, but for some organization to lay claim to copyrights owned by you or me seems very wrong. It's a violation of BSD-type licenses and a violation of the concept of attribution that is behind the licenses. A legal entity has made the false claim of copyright ownership, whether that's an informal organization or the person who wrote the claim with a pseudonym. I'm not sure how you or I have been damaged, but I supose that a lawyer could find a way. What is your theory of why it's legal? I'm really interested. Are you saying it's just another way of saying copyrights are owned by individual members of the informal FreeBSD project? That seems legal enough, I guess, but it's a quite different statement, IMO. And as it doesn't follow the form giving by US copyright law I wonder if it is sufficent legal notice in the USA, if you plan to sue infringers for the most money possible. For profit or not is irrelvant, given that there's no legally incorporated entity for the project. I'm fairly sure that members of informal organizations can be held liable for the acts of other members in the USA. For example, under the Racketeer Influenced and Corrupt Organizations (RICO) Act. And even if all members could not be held liable, persons directly responsible for the wrongdoing could be. Example wrongdoings are not paying taxes on the profit or not reporting the profit. But I admit that this issue seems unlikely to cause problems as long as someone pays taxes on any obvious profits other than copyright licenses. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
YACINE GHANJAOUI writes: Anyone help me how to untar a file with this extention file.tar.bz2 ? Thanks, This is really questions@ material, but... $ tar -y M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-09 15:32:53 +0300: On Thu, 08 Jan 2004 17:29:34 + Doug Rabson [EMAIL PROTECTED] wrote: The three main showstoppers for moving FreeBSD to subversion would be: [...] 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. subversion properties (svn propset) would allow you to do this in a satisfactory manner. Please explain how props can be used to embed custom keywords in bodies of the files in a satisfactory manner, e. g. on svn export. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Gary W. Swearingen) writes: : M. Warner Losh [EMAIL PROTECTED] writes: : : In message: [EMAIL PROTECTED] : [EMAIL PROTECTED] (Gary W. Swearingen) writes: : : : : And yet the Legal page carries a claim of copyright for The FreeBSD : : Project : : It is a psudonymous work by The FreeBSD Project. : : Are you saying that The FreeBSD Project is a pseudonym for many of : individuals, or what? And why does it matter with respect to whether : an extra-legal entity may claim copyright ownership? Yes. It is a collection of individuals. It is explicitly allowed for in copyright law. : : I've not seen a US statute about : : false copyright claims, but I think it would be less risky to say all : : intellectual property is owned by its owners, in the manner of some : : trademark statements. : : No, the above is perfectly legal under US and International Copyright : law. : : Well, I know that it's legal to omit one's own copyright claim, but : for some organization to lay claim to copyrights owned by you or me : seems very wrong. Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In message: [EMAIL PROTECTED] Simon L. Nielsen [EMAIL PROTECTED] writes: : On 2004.01.08 21:39:07 -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : [EMAIL PROTECTED] (Gary W. Swearingen) writes: : : : and the Copyright page has that plus a similar claim for : : FreeBSD, Inc. (For 2004, even.) : : That should be changed. : : To? I have noticed FreeBSD, Inc on the copyright page a few times, but : I never really knew what to replace it with. The FreeBSD Project. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : 2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI :IDs of unclaimed devices, look them up in a list of supported PCI :devices, and load the appropriate module. There's some ongoing work to make this easier to do. There are some issues with doing this, but nothing that can't be overcome. Every PCI driver in the tree will likely need to change in some form to make this happen, however. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[3]: Where is FreeBSD going?
Hello, Narvi! Friday, January 9, 2004, 4:28:57 PM, you wrote: DR 3. Converting the repository. This is a tricky one - I tried the DRcurrent version of the migration scripts and they barfed and died DRpretty quickly. Still, I'm pretty sure that the svn developers DRare planning to fix most of those problems. From mailing-list DRarchives, it appears that they are using our cvs tree as test DRmaterial for the migration scripts. Did you try my (pure-perl) vatinat ``RefineCVS''? http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.76.783.tar.gz But, please, read documentation carefully before reporting bugs -- many errors could be avoided with command-line options, sctipy is paranoid by default. Some parts of FreeBSD repository could not be converted, because contains revisions like 1.2.1 and other `I don't know what I should think about this' errors. If you have some good ideas -- let me know :) N Huh? Whats wrong with revision 1.2.1 ? This is perfectly normal cvs N revision number, even if you have to use a command line option to get it. N But it should not require any kind of special treatment. It is NOT perfectly normal cvs revision number. WHAT TYPE of revision number is it? Normal numbers are (first level of branching is showed only): x.y -- TRUNK x.y.0.(2n) -- MAGIC for branch (in SYMBOLS only) x.y.(2n).z -- Revision on branch x.1.(2n+1) -- Vendor branches (in SYMBOLS only) x.1.(2n+1).z -- Vendor imports Ok, ok, it should be some broken vendor branch. But what do you say about `1.1.2'? Or even simple `1' (look into sysintall's Attic). BTW, repo from FreeBSD 4.9 is parsed almost without such errors (sysinstall, pppd + kernel part of ppp, zoneinfo). Some problems are with double symbols (one symbolic name marks two revisions: MAGIC one and simple one), and with symbols, which marks unexistent revisions (many, many such symbols over all repository). But my computer doesn't have enough memory to finish conversion process. -- Lev Serebryakov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New modem. Newbie need help.
This particular card is a controllerless modem (ie. it is a winmodem), and has no UART. Seeya...Q On Fri, 2004-01-09 at 21:33, Cristiano Deana wrote: Sorry for my basic knownledge about freebsd hacking and english language. Problem: i need to use an internal PCI modem, 56k. I found USR (NO winmodem) pci 56k but it were not right detect by freebsd. test# uname -rs FreeBSD 5.2-RC1 I add all his id in: src/sys/dev/puc/pucdata.c src/sys/dev/sio/sio_pci.c src/sys/dev/uart/uart_bus_pci.c copying and modifing existing similar USR modem pci. Now it's detect as: [EMAIL PROTECTED]:20:0: class=0x078000 card=0x00c412b9 chip=0x100712b9 rev=0x00 hdr=0x00 vendor = '3COM Corp, Modem Division (Formerly US Robotics)' device = 'ERL3263A-0 USR 56k Internal DF GWPCI PC99' class= simple comms It has not a subclass UART, so i have not a cuaa*. Any ideas? Verbose dmesg: http://moto.bmm.it/dmesg Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
M. Warner Losh [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : 2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI :IDs of unclaimed devices, look them up in a list of supported PCI :devices, and load the appropriate module. There's some ongoing work to make this easier to do. There are some issues with doing this, but nothing that can't be overcome. Every PCI driver in the tree will likely need to change in some form to make this happen, however. Not necessarily; one could, as a temporary measure, create and maintain the list of supported PCI IDs manually. I had a prototype once (though my purpose at the time was to generate kernel configs, not load modules). I dropped it because someone else was working on the same thing and had it seemed they'd gotten further than I had. I still have the sources though... (rev 1.32 of sys/dev/pci/pcireg.h was a side effect of that work) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
Hi, when trying to intercept UDP packet after changing the protocol number from 17 to a user one (99) in the ip_input.c file. when trying to regenrate the packet after inserting some bit errors an error message appears in the reciever telling that The udp checksum is incorrect even if i just change the ip Header. What do you think the problem is? Thanks in Advance, ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
There are several documents linked off of http://www.freebsd.org/releng that describe how to build a release. It's not nearly as arcane of a process as it used to be 5 years ago. The biggest barrier to entry is probably disk space. You'll need a good 5GB free to hold the CVS repo, chroot environment, and resulting bits. Well, I've got the CVS repo, though boy, has *THAT* ever grown since I built this system; I had to trim it down to only src and ports, and even so: /dev/da1s1e 2032623 1769089 10092595%/usr/cvs Of course, I left out the ports and docs parts of the release last time I tried (which was in fact about 5 years ago ;), though I had all kinda of troubles with parts of THAT, too. But still, I don't have even a tenth that much hard drive space around. Yes, to build the floppies you need to build most of the release, but once you've built the release, you can back-step and rebuild the floppies at will. And building the whole release is quite an ordeal on a Pentium Pro :) Still, I'm willing to donate some time and brain to the problem, since apparently I kinda care about it. It seems to me that the probing problem above is the biggest problem from a real coding POV; the rest is mostly just a whole heck of a lot of implementation, and inconvenience from the usability standpoint. That's a breaking point. I'll donate the disk space and CPU time if you want to run with this. I have an interest in keeping floppies around, but not much ability to help out. Josh Paetzel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-hackers Digest, Vol 42, Issue 6
On Freitag, 9. Januar 2004 14:04, Josef El-Rayes wrote: Robert Klein [EMAIL PROTECTED] wrote: have you noticed that i am _not_ using the '-'? tar xvfj file.tar.bz2 - if you leave the '-' away then tar does not care about the order of the parameters. when you are using the dash before the arguments than the 'f' has to be just before the filename. tar -xvjf file.tar.bz2 - Oops, sorry. I didn't notice the dash left out. I stand corrected. Best regards, Robert ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Thu, 8 Jan 2004, Doug Rabson wrote: I've been re-evaluating the current subversion over the last couple of weeks and its holding up pretty well so far. It still misses the repeated merge thing that p4 does so well but in practice, merging does seem to be a lot easier than with CVS due to the repository-wide revision numbering system - that makes it easy to remember when your last merge happened so that you don't merge a change twice. The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. I admit to having not tried it, but I wonder how well OpenCM (http://www.opencm.org/) would compare. I think it would have a smaller footprint than Subversion. Sean --- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[3]: Where is FreeBSD going?
On Fri, 9 Jan 2004, Lev Serebryakov wrote: Hello, Narvi! Friday, January 9, 2004, 4:28:57 PM, you wrote: DR 3. Converting the repository. This is a tricky one - I tried the DRcurrent version of the migration scripts and they barfed and died DRpretty quickly. Still, I'm pretty sure that the svn developers DRare planning to fix most of those problems. From mailing-list DRarchives, it appears that they are using our cvs tree as test DRmaterial for the migration scripts. Did you try my (pure-perl) vatinat ``RefineCVS''? http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.76.783.tar.gz But, please, read documentation carefully before reporting bugs -- many errors could be avoided with command-line options, sctipy is paranoid by default. Some parts of FreeBSD repository could not be converted, because contains revisions like 1.2.1 and other `I don't know what I should think about this' errors. If you have some good ideas -- let me know :) N Huh? Whats wrong with revision 1.2.1 ? This is perfectly normal cvs N revision number, even if you have to use a command line option to get it. N But it should not require any kind of special treatment. It is NOT perfectly normal cvs revision number. WHAT TYPE of revision number is it? See, the problem is that you are thinking in overly constrained terms of revision numbers that cvs creates by default, and even so don't think about RCS at all. CVS is not a real CM system its an half-assed one built on top of RCS. 1.2.1 could be a branch (this would be the usual case) or it could be a file revision created by ci(1). in fact, even old (ok, the old here is relative) versions of cvs let you create it as file revision. Normal numbers are (first level of branching is showed only): x.y -- TRUNK x.y.0.(2n) -- MAGIC for branch (in SYMBOLS only) (2n) here is completely - utterly, totaly, etc - bogus. x.y.(2n).z -- Revision on branch x.1.(2n+1) -- Vendor branches (in SYMBOLS only) x.1.(2n+1).z -- Vendor imports see above for 2n. Ok, ok, it should be some broken vendor branch. But what do you say about `1.1.2'? Or even simple `1' (look into sysintall's Attic). simple 1 is simple - somebody was using ci, and forgot about dots. 1.1.2 is similar to 1.2.1. BTW, repo from FreeBSD 4.9 is parsed almost without such errors (sysinstall, pppd + kernel part of ppp, zoneinfo). Some problems are with double symbols (one symbolic name marks two revisions: MAGIC one and simple one), and with symbols, which marks unexistent revisions (many, many such symbols over all repository). But my computer doesn't have enough memory to finish conversion process. It may be worthwhile to collect such and have somebody do a fixup. -- Lev Serebryakov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Large Filesystem Woes
I previously posted this on -fs but got no responce so I'm trying -hackers. Building a box thats going to house many billions of small files. Think innd circa 1998 or someone trying to house AOLs mail system on cyrus or something. To this end I've hung a 3.3TB hardware raid off a BSD box broken into 4 partitions. 3 1TB and 1 300GB. Originally this was on a 4.9 box. da0s1 and da0s2 were formatted stock ( -f 2048 -b 16384 -i 8192 ) da1s1 and s2 were both formatted -f 512 -b 4096 -i 512. Needless to say fsck took a while if the box came up dirty. Switched to 5.2. Newfs'd the RAID for UFS2. First issue, if the machine came up dirty, bgfsck seemed to do its thing and the machine was online and usable after about 20 minutes however after a few hours I get this error : fsck: /dev/da1s1e: CANNOT CREATE SNAPSHOT /export/database/.snap/fsck_snapshot: File too large fsck: /dev/da1s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. And the second thing I've noticed is I have lost a lot of space. Under 4.9 with UFS da1s1e was approx 870gigs and s2e was around 180, now I see : FilesystemSize Used Avail Capacity iused ifree %iused Mounted on /dev/da0s1e 992G 4.0K 912G 0% 2 1344112600% /export/logs1 /dev/da0s2e 992G 4.0K 912G 0% 2 1344112600% /export/logs2 /dev/da1s1e 510G 1.0K 469G 0% 2 21486612280% /export/database /dev/da1s2e94G 1.0K86G 0% 2 3952143320% /export/spare I'm not certain if I've run into some kind of weird limit here or a bug or what and am looking for ideas to persue before I'm stuck going to an OS with something journaled. Thanks! -- - Tom Arnold - When I was small, I was in love, - - Sysabend - In love with everything. - - CareTaker - And now there's only you... - -- -- Thomas Dolby, Cloudburst At Shingle Street - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Diomidis Spinellis wrote: I presume the above means a PXE *client*. This would be cool, but by no means trivial. I looked at this in the past when I wanted to network boot FreeBSD on a couple of machines that did not support a boot ROM and reached a dead end; I ended up using PicoBSD and NFS-mounting most of the stuff. What about etherboot? Doesn't it do exactly this? Jason -- Jason Slagle - CCNP - CCDP /\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Fri, 9 Jan 2004, Gary W. Swearingen wrote: M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. You obviously don't want to discuss this, and it's easy to guess the real reasons. Your main problem here, and apparently that of your lawyers, is that you don't understand what the issues are to which copyright law is to be applied. The legality of collective copyrights was not my issue. Your other problem is putting words in people's mouth; I would never admit to know not knowing US copyright law because I know it quite well enough to argue FreeBSD's IP issues with anybody. If I don't write with the same seeming authority as you, that's more your problem than mine. I expected my comments to be ignored or brushed off, but I didn't expect to be brushed off in your rude and insulting manner. Maybe when I've recovered, and if I haven't made my move to NetBSD yet, I'll write up a more complete explanation of FreeBSD's IP problems instead of trying to deal with the likes of you in a conversation. Please do. But could you also include reasoning for use of US specific view (if thats what you are going to use) as there is essentially no reason why US copyright regulations and practices should preferentialy apply to it. Especially as the licence has no such stipulations about applicable law in it. We can all be glad that it hasn't mattered and might never matter that the FreeBSD IP situation is so shabby, I suppose because it sends the message that it's all essentially a Gentlemen's Agreement, with only a few violators who are more-or-less tolerated. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Matthew D. Fuller wrote: On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: While it is indeed true that most machines since 1997 will support this CD format, please take in to account: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. It seems to me that we could split more out into modules, and/or add more disks of modules (maybe categorize a storage device modules disk, a network drivers modules disk, etc, keeping just the more common devices in the main kernel). Last I saw, the current system only created a single modules disk, which was a godsend to a kernel overflowing one disk, but as we add more and more stuff becomes another, albeit larger, noose. Here at Vicor, we have over a thousand machines spread over about 20 sites. About 10 of those machines have cdrom drives. Our plans call for moving from 4.x to 5.x, probably at the end of 2004, maybe early 2005. Most of the machien swill not have been replaced by then so we'll still have very few cdroms. Luckily this would probably not be an issue for the upgrade, but the Custommer Engineers (CEs) need to be able to rebuild machine quickly in the case of disk failures or other problems. They use floppies at the moment for this. I could immagine that a floppy that did a net-boot might be a possibility, but retraining them to do things differently is always a problem. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 04:38:11PM +0100, Dag-Erling Smørgrav wrote: M. Warner Losh [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : 2) use pciconf -l (or direct access to /dev/pci) to retrieve the PCI :IDs of unclaimed devices, look them up in a list of supported PCI :devices, and load the appropriate module. There's some ongoing work to make this easier to do. There are some issues with doing this, but nothing that can't be overcome. Every PCI driver in the tree will likely need to change in some form to make this happen, however. Not necessarily; one could, as a temporary measure, create and maintain the list of supported PCI IDs manually. These sort of 'temporary measures' have a nasty habit of becoming permanent - witness sysinstall itself. Having to keep two lists of PCI IDs in sync manually is a maintenance nightmare. The (conceptually) simplest approach would be for all drivers to advertise the PCI IDs that they can support (together with a priority) in a manner that would allow such a list to be generated automatically. This would be fairly trivial for the PCI drivers that already scan a table of PCI IDs, but would be a nuisance for the drivers that have the PCI IDs wired into the probe code. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: beastie boot menu, 4th (forth)
Roman Neuhauser wrote: Here's the question perhaps more appropriate for hackers@: I looked into ripping the ascii-art out, but am quite scared. However, forth looks like it's an interesting (love/hate kind of thing) language, and I'd like to get my hands on it. Can anyone recommend good (or just any, really) introductory material? google quickly degrades into misses, and just a few even of those. As someone has already replied, disabling the beastie menu is simple, and requires but a single line in /boot/loader.conf. On the other hand, I'd recommend cheking out the Forth Interest Group web page (http://www.forth.org/) if you want to search for reading material. And, yes, it's a love/hate kind of thing. :-) I think someone ported a userland version of Forth as lang/ficl. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] In related news Microsoft Windows users are now covered under the Americans with Disabilities Act. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Peter Jeremy [EMAIL PROTECTED] writes:
The (conceptually) simplest approach would be for all drivers to
advertise the PCI IDs that they can support (together with a priority)
in a manner that would allow such a list to be generated automatically.
yes, we need something like
struct pci_device_info {
uint32_tpciid;
charbrand[64];
charmodel[64];
} my_supported_devices[] = {
{ 0x12345678, Acme, Nutcracker 2000 }
};
which is placed in a separate ELF section so we can extract it from
the module.
except it needs to be flexible enough to support other buses than PCI
(SBUS, USB...)
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 08:30:17PM -0800, Avleen Vig wrote: A simple website which lets you choose what drivers you want (anyone seen the .muttrc config page? :) That should be really easy to do with a little perl CGI. I might take a crack at this in the next week or so. FWIW, Plan-9 ( http://plan9.bell-labs.com/plan9dist/index.html ) does this: You describe your hardware via a WEB form and the site spits out a boot floppy customised to your hardware. In order for this to be practical, we'd need to avoid having to fully compile a custom kernel - we'd probably need to develop and use the a 'binary distribution' approach (as for all the commercial Unices). Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 10:52:08AM +0100, Daniel Lang wrote: Matthew D. Fuller wrote on Thu, Jan 08, 2004 at 01:58:11AM -0600: [..] And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. That's no point, as you can use a CD-RW, so no media is wasted. Not all CD readers will read CD-RW's (I have one that won't). And this doesn't solve the problem of not having a CD burner or installing onto a system that either doesn't have a CD drive or won't boot off one (I have systems in both categories). On the other hand, I guess such systems are able to boot over the network. I'd love to see a integrated boot and installation procedure that utilizes PXE (or any other network boot method) and advocates it. (In this regard I just love Suns). Keep in mind that older systems probably won't boot over the network without a netboot ROM or similar. The netboot ROM images are (or were) in the distribution but aren't much use without an EPROM burner. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Peter Jeremy [EMAIL PROTECTED] writes: Keep in mind that older systems probably won't boot over the network without a netboot ROM or similar. The netboot ROM images are (or were) in the distribution but aren't much use without an EPROM burner. I believe that in most cases you can dd the ROM image to a floppy and boot from it. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Dag-Erling Smørgrav wrote:
Peter Jeremy [EMAIL PROTECTED] writes:
The (conceptually) simplest approach would be for all drivers to
advertise the PCI IDs that they can support (together with a priority)
in a manner that would allow such a list to be generated automatically.
yes, we need something like
struct pci_device_info {
uint32_tpciid;
charbrand[64];
charmodel[64];
} my_supported_devices[] = {
{ 0x12345678, Acme, Nutcracker 2000 }
};
which is placed in a separate ELF section so we can extract it from
the module.
except it needs to be flexible enough to support other buses than PCI
(SBUS, USB...)
DES
Yeah, this is a good suggestion, the only problem being in making it
flexible enough to not be a burden on the drivers. Many drivers
keep one or more flag elements in their tables to flag hardware than
needs special attention. I'm sure that there are also countless other
pieces of state that drivers would want to associate with a table like
this.
Scott
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Julian Elischer wrote: On Thu, 8 Jan 2004, Matthew D. Fuller wrote: On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: While it is indeed true that most machines since 1997 will support this CD format, please take in to account: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. It seems to me that we could split more out into modules, and/or add more disks of modules (maybe categorize a storage device modules disk, a network drivers modules disk, etc, keeping just the more common devices in the main kernel). Last I saw, the current system only created a single modules disk, which was a godsend to a kernel overflowing one disk, but as we add more and more stuff becomes another, albeit larger, noose. Here at Vicor, we have over a thousand machines spread over about 20 sites. About 10 of those machines have cdrom drives. Our plans call for moving from 4.x to 5.x, probably at the end of 2004, maybe early 2005. Most of the machien swill not have been replaced by then so we'll still have very few cdroms. Luckily this would probably not be an issue for the upgrade, but the Custommer Engineers (CEs) need to be able to rebuild machine quickly in the case of disk failures or other problems. They use floppies at the moment for this. I could immagine that a floppy that did a net-boot might be a possibility, but retraining them to do things differently is always a problem. Can these machines netboot/PXEboot? In any case, there looks to be some prospects for someone stepping forward to help with floppies. If Vicor wants to help out too, that would be wonderful. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: beastie boot menu, 4th (forth)
Hi, re the question from Roman Neuhauser [EMAIL PROTECTED] Fri, 9 Jan 2004: forth looks like it's an interesting .. language. Can anyone recommend good (or just any, really) introductory material? --- If you do want to get into Forth, you can probably find some of the following in a decent research library: * The common leading intro text to Forth was: Starting FORTH, Leo Brodie, FORTH, Inc., Prentice Hall, 1981. * Another good intro was: FORTH, W.P. Salerman, O.Tisserand, and B. Toulout, Springer-Verlag, 1983. * It's not a tutorial, but it may be helpful: FORTH Encyclopedia: The Complete FORTH Programmer's Manual, Mitch Derick and Linda Baker, 2nd ed., Mountain View Press, 1982. * Uneven, but potentially very good for the novice, Invitation to FORTH, Harry Katzan, Jr., PBI, 1981. * If nothing else, you should be able to find this influential introductory paper by an IBMer, which arguably played an important role in legitimizing Forth use: An Architectural Trail to Threaded-Code Systems, Peter M. Kogge, IEEE Computer, v.15,n.3, pp.22-32, March 1982. --- If you are used to any RPN language, such as found on an HP calculator, or Postscript, you will find getting into Forth rather easy (Although not the same, Forth and Postscript are very similar). It's not often described this way, but you can somewhat think of Forth as a stand-alone interactive threaded-code compiler backend, which you can program directly using the compiler's intermediate language and interact with the symbol table. Forth is at it's best when you have small (32K), unique embedded systems (perhaps with custom architecture) and have no existing toolchain. I think you could find a Forth in the ports tree to get up-to-speed with, before looking at boot-time FICL... Paul Frenger has a Forth column in SIGPLAN notices. For instance, the only published academic reference that I am aware of that describes PicoBSD is Forth and the FreeBSD Bootloader, Paul Frenger, ACM SIGPLAN Notices, August 2000, v.35,n.8, pp.15-17. I don't know how active this is, but there are many links: http://www.forth.org Forth seems to have become heavily used in spacecraft. The instrument platform on the US probe that landed on as asteroid awhile back was all Forth, if I understand correctly. Both US and USSR used Forth this way. See also: http://forth.gsfc.nasa.gov Reasonably impressive list... - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going? the never-ending thread
Narvi wrote: M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. So there are cases of code by authors being committed into the codebase without their knowledge/consent? This would be a problem. If code is being committed against license, I definitely see an issue here. However, If you /GIVE/ your IP to the FreeBSD community, it's no longer yours. Either way, apparently you'll never make everyone happy, even as hundreds (or thousands) of people give away their time to produce something at no cost to you, there's still always going to be someone complaining. (We refer to this as a sense of entitlement - Many people have this, and it's an unfortunate growing fad all over.) If you don't want your code in FreeBSD, don't submit it. Anyone going to pursue some indictments against Coyote Point Systems? Since their load-balancing hardware runs FreeBSD, and I don't believe (I'm unsure, but from the info I've gotten, it doesn't sound like it.) that they give you any of the source with your purchase of their hardware, Hmm -mpf + - - | Resistance is futile, assimilation into the FreeBSD community is inevitable. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
This is getting stupid! This discussion is just like when the i386 support was removed from the GENERIC kernel, a lot of noise about old systems that wouldn't be able to run (or benefit) from FreeBSD 5 anyway. And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. I fail to see the difference in required labour between creating two floppies or a CD-R/RW disc. Most new machines ship with CD-RW drives today, the only boxes that can't boot from a CD are early Pentium1 class and frankly why run 5.x or 6.x on those? Here at Vicor, we have over a thousand machines spread over about 20 sites. About 10 of those machines have cdrom drives. Our plans call for moving from 4.x to 5.x, probably at the end of 2004, maybe early 2005. Most of the machien swill not have been replaced by then so we'll still have very few cdroms. That is why I want to get boot from an USB CDROM to work, this way you just plug in the portable drive in the machine that you want to boot just like you do with a floppy, the difference is that you don't have to wait to change floppies. You can also save some money by not having to buy CD/floppy drives for your servers. Slim drives (for server use) are not cheap. Besides floppydrives tend to collect dust and never work anyway when you want to use them. Luckily this would probably not be an issue for the upgrade, but the Custommer Engineers (CEs) need to be able to rebuild machine quickly in the case of disk failures or other problems. They use floppies at the moment for this. PXE boot against an automated backup/restore service would be much more useful for this. /Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
beastie boot menu, 4th (forth)
I have two related questions, one being more appropriate for current@, the other for hackers@, but they're quite the same thing, so sorry for the cross-post, I hope it's tolerable (I bet this won't solicit many replies :). I dislike the boot menu in CURRENT, and would prefer something that * doesn't rob me of the text output so far * displays no mascots or other visual noise Here's the question perhaps more appropriate for hackers@: I looked into ripping the ascii-art out, but am quite scared. However, forth looks like it's an interesting (love/hate kind of thing) language, and I'd like to get my hands on it. Can anyone recommend good (or just any, really) introductory material? google quickly degrades into misses, and just a few even of those. And here's the one for current@: Failing the above query, does anyone have a replacement that meets my requirements? (But I'd really prefer hacking it myself, so links to tutorials are awarded with more points than off-the-shelf programs. :) TIA HAND! -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: beastie boot menu, 4th (forth)
In the last episode (Jan 09), Roman Neuhauser said: I have two related questions, one being more appropriate for current@, the other for hackers@, but they're quite the same thing, so sorry for the cross-post, I hope it's tolerable (I bet this won't solicit many replies :). I dislike the boot menu in CURRENT, and would prefer something that * doesn't rob me of the text output so far * displays no mascots or other visual noise I believe adding beastie_disable=NO to /boot/loader.conf will do what you want. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, 9 Jan 2004, Scott Long wrote: Julian Elischer wrote: Here at Vicor, we have over a thousand machines spread over about 20 sites. About 10 of those machines have cdrom drives. Our plans call for moving from 4.x to 5.x, probably at the end of 2004, maybe early 2005. Most of the machien swill not have been replaced by then so we'll still have very few cdroms. Luckily this would probably not be an issue for the upgrade, but the Custommer Engineers (CEs) need to be able to rebuild machine quickly in the case of disk failures or other problems. They use floppies at the moment for this. I could immagine that a floppy that did a net-boot might be a possibility, but retraining them to do things differently is always a problem. Can these machines netboot/PXEboot? In any case, there looks to be some prospects for someone stepping forward to help with floppies. If Vicor wants to help out too, that would be wonderful. I have grave doubts as to all 1000 machines being able to net/PXE boot.. They have come from varying sources at different times.. Of course we may be able to produce our own boot floppies with unneeded options removed.. A net-booting floppy may be enough, and I'll add it to my list of things that I'll keep my eye on.. If we get close and no-one has worked on it I'll see what I need to do to get it to work for us :-) (At that point I'd get payed to do whatever it took :-) Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, 9 Jan 2004, Martin Nilsson wrote: This is getting stupid! Here at Vicor, we have over a thousand machines spread over about 20 sites. About 10 of those machines have cdrom drives. Our plans call for moving from 4.x to 5.x, probably at the end of 2004, maybe early 2005. Most of the machien swill not have been replaced by then so we'll still have very few cdroms. That is why I want to get boot from an USB CDROM to work, this way you just plug in the portable drive in the machine that you want to boot just like you do with a floppy, the difference is that you don't have to wait to change floppies. You can also save some money by not having to buy CD/floppy drives for your servers. Slim drives (for server use) are not cheap. Besides floppydrives tend to collect dust and never work anyway when you want to use them. Many of the older machines don't have the USB connectors brough out of the boxes The motherboards mostly have them but even then I wouldn't guarantee that all of them do. Certainly I know that many of the machines from 4 or so years ago have no externally accessible USB connectors. (custom cases etc.). These boxes are doign fixed jobs and as long as they can keep up they will not be replaced. That's the real world. Luckily this would probably not be an issue for the upgrade, but the Custommer Engineers (CEs) need to be able to rebuild machine quickly in the case of disk failures or other problems. They use floppies at the moment for this. PXE boot against an automated backup/restore service would be much more useful for this. Assuming they have PXE and a supported card.. /Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 10:57:56PM +0100, Martin Nilsson wrote: This discussion is just like when the i386 support was removed from the GENERIC kernel, a lot of noise about old systems that wouldn't be able to run (or benefit) from FreeBSD 5 anyway. No, this is nothing like that. And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. I fail to see the difference in required labour between creating two floppies or a CD-R/RW disc. Most new machines ship with CD-RW drives today, the only boxes that can't boot from a CD are early Pentium1 class and frankly why run 5.x or 6.x on those? Incorrect. I and others have already given several examples of how modern machines cannot boot from CD for all the various reasons given. If the freebsd hosting mirrors don't mind us NFS mounting their servers to get the boot image, etherboot would be by far the simplest solution to maintain in the long run - then we can go with Scott's approach of getting rid of the current floppies, and adding in the other suggested approach of downloading the boot img from a remote server and running it. (I believe etherboot can be used like this, please someone correct me if i'm wrong). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going? the never-ending thread
On Fri, 9 Jan 2004, Matt Freitag wrote: Narvi wrote: M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. So there are cases of code by authors being committed into the codebase without their knowledge/consent? This would be a problem. If code is being committed against license, I definitely see an issue here. Consider code merges from Net/OpenBSD. There is no explicit permission involved nor needed. However, If you /GIVE/ your IP to the FreeBSD community, it's no longer yours. Either way, apparently you'll never make everyone happy, even as Well... See, this is the place where people go wrong. Nobody is *GIVING* their IP or code to anybody (and this includes the original sources from Berkeley), they are simply licencing it. And unsuprisingly enough, there is a difference - a big one - between two two. Whetever one needs to be concerned about that is yet againan altogether different matter. The same would by the way apply even if all of FreeBSD was GPL licenced. hundreds (or thousands) of people give away their time to produce something at no cost to you, there's still always going to be someone complaining. (We refer to this as a sense of entitlement - Many people have this, and it's an unfortunate growing fad all over.) If you don't want your code in FreeBSD, don't submit it. Anyone going to pursue some indictments against Coyote Point Systems? Since their load-balancing hardware runs FreeBSD, and I don't believe (I'm unsure, but from the info I've gotten, it doesn't sound like it.) that they give you any of the source with your purchase of their hardware, Hmm There is no scenario at all under which they would have to give you their code. None at all. -mpf + - - | Resistance is futile, assimilation into the FreeBSD community is inevitable. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tar's unusual argument handling
Markus Brueffer wondered why:
tar xvfj file.tar.bz2
is not the same as
tar -xvfj file.tar.bz2
What I'm asking me, is why the - makes a difference, though I haven't looked
at the sources, yet. The manpage states, that the - is only optional, so
tar -jxfv and tar jxvf should be equivalent, but obviously they are not.
The manpage has not explained the history here.
The original tar programs (1970s?) used a very peculiar
command line:
tar [letter options] [arguments to those options]
For example, the 'b' and 'f' options both require
arguments, so you would use them as
tar xbfv 32 file.tar
Note that '32' is the argument to 'b' and 'file.tar'
is the argument to 'f'. Also note that there
is no '-' here.
This is totally different from other Unix programs,
of course, so most current tar programs handle the
arguments differently depending on whether there
is a leading '-'. If there is a leading '-', then
it uses common Unix conventions, so that
tar -xfj file.tar.bz2
has 'j' as the argument to '-f', but
tar xfj file.tar.bz2
considers 'file.tar.bz2' to be the argument to 'f'.
To avoid this confusion, always put the 'f' last:
tar xjf file.tar.bz2
and
tar -xjf file.tar.bz2
really do mean the same thing.
It's also worth noting that for many tar programs,
the first argument MUST BE the mode argument ('x', 'c', 't',
'r', 'u', and sometimes 'd' or 'A'), that is
tar xvjf file.tar.bz2 GOOD
but
tar jxvf file.tar.bz2 BAD
My 'bsdtar' implementation, in particular, requires
that the first option be a mode specifier (because
it allows it to provide better feedback about nonsense
options and handles some odd cases where options
don't have quite the same meaning in different modes).
Tim
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
UNIX / BSD parallel port programming documentation
Hi hackers, I have to develop small server which has to manage custom microcontroller via parallel port interface. Does anyone know good manual/documentation about UNIX / BSD parallel port programming ? Thanks in advance! Vladimir ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going
Sorry to jump in the conversation so late, and without reading the entire thread to date, but has anyone considered tla as an scm, it handles merging and branching much more sanely than cvs or svn, not to mention the benefits of distributed development and the dumb server model. and there are tools available (cscvs for one) that will convert cvs to tla archives with full history. Just a thought. And as for the memory issues in conversion, cscvs uses SQLite as a storage medium during conversion to alleviate the need for mass amounts of memory during the conversion process, with quite a nice performance boost. Mike Partin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
M. Warner Losh [EMAIL PROTECTED] writes: Whatever. I've consulted lawyers on this who assure me that it is legal. You've admitted to not knowing US Copyright law and are aguing emotion, which is why I didn't reply to the rest of your message. You obviously don't want to discuss this, and it's easy to guess the real reasons. Your main problem here, and apparently that of your lawyers, is that you don't understand what the issues are to which copyright law is to be applied. The legality of collective copyrights was not my issue. Your other problem is putting words in people's mouth; I would never admit to know not knowing US copyright law because I know it quite well enough to argue FreeBSD's IP issues with anybody. If I don't write with the same seeming authority as you, that's more your problem than mine. I expected my comments to be ignored or brushed off, but I didn't expect to be brushed off in your rude and insulting manner. Maybe when I've recovered, and if I haven't made my move to NetBSD yet, I'll write up a more complete explanation of FreeBSD's IP problems instead of trying to deal with the likes of you in a conversation. We can all be glad that it hasn't mattered and might never matter that the FreeBSD IP situation is so shabby, I suppose because it sends the message that it's all essentially a Gentlemen's Agreement, with only a few violators who are more-or-less tolerated. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Quoting Miguel Mendez [EMAIL PROTECTED]: Matthew Dillon wrote: interdisciplinary people left in the project. The SMP interactions that John mentions are not trivial... they would challenge *ME* and regardless of what people think about my social mores I think most people would agree that I am a pretty good programmer. My thoughts exactly. Every time I have this kind of argument, be it on irc or in a mailing list, I get told that Sun needed X years to do the fine grained locks in Solaris and other similar crap. Solaris was possible because Sun could throw more engineers at the problem if needed. FreeBSD is not in such situation. How many people have intimate knowledge of the VM subsystem? How many people besides John Baldwin have ever touched the SMPng code? I don't think anybody has doubts about your programming-fu, btw :) One comment: I doubt that I could do the things that I used to be able on FreeBSD. However, it has been my position (for years), that the many-mutex ad-hoc approach would require brilliant people to implement, and incredibly brilliant people to maintain. (I have lost alot of context -- due to persistent burnout, but still remember alot of the problems.) serious trouble down the line. The idea (that some people have stated in later followups to this thread) that the APIs themselves will stabilize is a pipedream. The codebase may become reasonably stable, Agreed. Like I've said, the main problem I see is complexity. It wouldn't matter as much if there were 5-10 people with deep knowledge of SMPng, but with 1 or 2 hackers working on it, the chance that everything will be ever fixed is quite small. IMO, the easiest way to start the SMP work (from a FreeBSD monolithic approach), is to flatten as much of the VFS/VM code as possible into a continuation scheme... That is something that I could have done 5yrs ago in a few weeks, and then keep the networking system as it is. There would be shims deployed that would still support the sleep/wakeup scheme, so that the non-networking could and the new flat interface could be debugged... (It is NOT a good idea to bug the networking guys until the new scheme would be debugged.) At that point, there would be a code with explicit context carried around, and no nesting or stack context. This would have a small benefit of avoiding multiple deeply nested kernel stacks... Given the very flat scheme, each subsystem could be recoded into a message passing or simple continuation scheme (whatever is appropriate.) The system would be naturally able to be reworked -- without the hidden dependencies of the stack. VFS/VM layering problems then become resolvable. This is NOT a total solution, but should be the beginning of a thinking exercise that seems to lead into the correct direction. (Don't criticize this based upon the completeness of my prescription, but on what can eventually be developed!!!) IMHO ULE is making progress quite fast. I wouldn't rely on it for production, but so far is looks very good. The need for a new scheduler (or extreme rework on BSD) whenever you see the threads bouncing around from CPU to CPU. My temporary hack solutions couldn't work right, and it is good that the issue is being researched. non-interrupt threads due to priority borrowing, and non deterministic side effects from blocking in a mutex (because mutexes are used for many things now that spl's were used for before, this is a very serious issue). Yes, that's the main problem I see, not much on the scheduler side, but on the 6-trillion-mutexes side. The IQ of the maintainers would probably have to be 6-trillion, which would definitely allow the very few elegible developers to maintain their high priest status forever :-). See? I didn't mention DragonFly even once! Ooops, I didn't mention DFly twice. oops! Well, I didn't mention it more then twice anyway. Makes me wonder if some of the solutions proposed by DragonFly could be ported to FreeBSD, but I doubt it will be done, since it's more or less admitting that the current solution is wrong. Sometimes, I think that people have their egos directed wrongly... The egos should be fed by the excellent behavior/performance/reliability of the FreeBSD OS. Being embarassed about appropriately borrowing code or ideas from other sources (WITH APPROPRIATE ATTRIBUTION) is counter productive. A developer should be able to say I was wrong, or my code/design needs rework, without any problems. No-one produces the golden perfect code for the first iteration!!! Oh well -- I cannot think too much about this stuff, or I'll actually get emotionally involved again. I need to get a 'normal' job, not working at home and need to interact with people instead of CRTs. :-). (I give a sh*t about FreeBSD, and hope that WHATEVER problems that truly exist are fully resolved.) There is alot of
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 02:23:58PM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
Dag-Erling Sm?rgrav wrote:
yes, we need something like
struct pci_device_info {
uint32_tpciid;
charbrand[64];
charmodel[64];
} my_supported_devices[] = {
{ 0x12345678, Acme, Nutcracker 2000 }
};
which is placed in a separate ELF section so we can extract it from
the module.
except it needs to be flexible enough to support other buses than PCI
(SBUS, USB...)
DES
Yeah, this is a good suggestion, the only problem being in making it
flexible enough to not be a burden on the drivers. Many drivers
keep one or more flag elements in their tables to flag hardware than
needs special attention. I'm sure that there are also countless other
pieces of state that drivers would want to associate with a table like
this.
I was poking around a bit (in my completely kernel-fu-lacking way) at
this last night. For one thing, we could avoid the struct definition,
and instead just mandate a few fields in the structure with given names
as above. Then, write a little helper .c file with a main() that goes
through the array (with the name given as a preprocessor -D or something)
and spits the info out into a text file. Compile it up and run it for
each module as we compile it, and assemble the results in a big reference
file. Then, a userland program (like sysinstall, in this case) can
easily poke through that text file to find and describe the drivers for
devices found.
I also was thinking that perhaps we should just stick the vendor/model
ID's (and maybe submodel and bus, too) into a string and export it via
sysctl; that was we don't have to use another tool or manually grub
around /dev/pci and whatever other buses there might be, to identify
devices pining away for a driver to mate with.
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Copyrights (was: Where is FreeBSD going?)
Narvi wrote: We can all be glad that it hasn't mattered and might never matter that the FreeBSD IP situation is so shabby, I suppose because it sends the message that it's all essentially a Gentlemen's Agreement, with only a few violators who are more-or-less tolerated. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. Copyright transfer is certainly not required if the code was released by the original author under a suitable free software licence (BSD/GPL/LGPL or others that permit FreeBSD to redistribute them). All that is required is that you retain the author's copyright statement in the source files. You can of course not do this with copyrighted material in general. It is the free software licence that allows you to do it if you abide by its conditions. If the claim is that there is code in the tree whose licensing status is doubtful, you should point out that code. As for the copyright (C) the FreeBSD project bit: As I understand, editors/publishers who compile anthologies can claim copyright on the anthologies (the act of anthologisation itself being a creative process) even if the individual articles in the anthology are copyright by their respective authors. Similarly, free software distributors like Red Hat can (and do) claim copyright on their distributions. According to OpenBSD's website, Theo de Raadt claims copyright on OpenBSD's CDs and does not permit their copying or distributing ISO images of those CDS, though of course you can assemble your own ISO and distribute those. The assembling of the FreeBSD system through various contributions is a creative act and I'm quite sure it's copyright protected, and the copyright can be claimed by the FreeBSD project ie the community of FreeBSD developers, even if individual components are copyrighted by others. Even the GPL has no problem with that: the GPL explicitly exempts mere aggregation from its virality clause so you needn't get the permission of every copyright holder of GPL'd work in the tree before distributing it, as long as it's not linked to GPL-incompatible code. The FSF does demand transfer of copyright to them for all contributions to official GNU software, but this is not because it would be illegal for them to use these contributions otherwise; it is because they think they can more successfully challenge GPL violators if they, as a single entity, hold all the copyrights. Rahul ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Copyrights (was: Where is FreeBSD going?)
On Fri, 9 Jan 2004, Rahul Siddharthan wrote: Narvi wrote: We can all be glad that it hasn't mattered and might never matter that the FreeBSD IP situation is so shabby, I suppose because it sends the message that it's all essentially a Gentlemen's Agreement, with only a few violators who are more-or-less tolerated. It is not clear that there is a way - as things stand - to get to a point where this wouldnot be the case. In appears very doubtful there is such a way unless you can get to get everybody whose code has been ever commited to send in a real written on paper copyright transfer, the chances of which are essentialy 0, even should you be able to trace down all involved. Copyright transfer is certainly not required if the code was released by the original author under a suitable free software licence (BSD/GPL/LGPL or others that permit FreeBSD to redistribute them). All that is required is that you retain the author's copyright statement in the source files. Required for what? For use of the code as we are all doing, sure, no argument. The paragraph above was about his perception of the code being in a shoddy situation due to apparent attribution of copyright to a body in a way that does not actually cause the transfer of copyright to said body (whetever it exists as a legal / physical entity anywhere or not). I just pointed out that the reversal of such situation is essentialy impossible even if such was desirable (which I doubt it is) or tried. And no, IMHO there is no real reason to even try. You can of course not do this with copyrighted material in general. It is the free software licence that allows you to do it if you abide by its conditions. If the claim is that there is code in the tree whose licensing status is doubtful, you should point out that code. I have made no such claim - and I heavily doubt there is such code. I did not make any claims at all about code, only about the copyright ownership and that it essentialy remains in the hands of the developers. Which is ok. And no, I don't really think there is much point in having long discussions over this... [snip - umm, yes] Rahul ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Thu, 8 Jan 2004, Doug Rabson wrote: DR I've been re-evaluating the current subversion over the last couple of DR weeks and its holding up pretty well so far. It still misses the DR repeated merge thing that p4 does so well but in practice, merging does DR seem to be a lot easier than with CVS due to the repository-wide DR revision numbering system - that makes it easy to remember when your DR last merge happened so that you don't merge a change twice. DR DR The three main showstoppers for moving FreeBSD to subversion would be: DR DR 1. A replacement for cvsup. Probably quite doable using svnadmin DRdump and load. DR 2. Support for $FreeBSD$ - user-specified keywords are not supported DRand won't be until after svn-1.0 by the looks of things. DR 3. Converting the repository. This is a tricky one - I tried the DRcurrent version of the migration scripts and they barfed and died DRpretty quickly. Still, I'm pretty sure that the svn developers DRare planning to fix most of those problems. From mailing-list DRarchives, it appears that they are using our cvs tree as test DRmaterial for the migration scripts. For the third point, take a look at http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.71.763.tar.g The author uses FreeBSD repository as main test field ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: beastie boot menu, 4th (forth)
I go through the love/why am I spending my time learning an obscure language kind of relationship. :) If you want to buy books, good ones are: http://www.forth.com/Content/Handbook/Handbook.html http://www.forth.com/Content/fat/fat.html You can get PDF versions if you download the trial version of Swift Forth. Or you can pick up a few on Amazon. Starting Forth is the classic intro (by Leo Brodie) Thinking Forth is the follow on. Patrick Here's the question perhaps more appropriate for hackers@: I looked into ripping the ascii-art out, but am quite scared. However, forth looks like it's an interesting (love/hate kind of thing) language, and I'd like to get my hands on it. Can anyone recommend good (or just any, really) introductory material? google quickly degrades into misses, and just a few even of those. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Scott Long wrote: All, Every FreeBSD release cycle in the past year has hit bumps due to install floppy problems. This is becoming more and more of a burden on the Release Engineering Team, as we simply do not have the resources to constantly battle the floppies. FreeBSD/i386 is the only port left that generates install floppies. Their primary purpose is to fascilitate installing FreeBSD on systems where a CDROM is either not available or is incompatible with the 'Non-Emulated El Torito' boot method that we use on our CDs. Systems that cannot boot these CDs are typically those that are also not certified for WinNT4, Win2K, or WinXP. Thus, nearly all machines produced after 1997 can boot our CDs. It is certainly possible to run FreeBSD 5.x on machines of this and prior vintage, and I certainly do not want to dispute or question any motives here. However, the number of machines in this category is steadily declining as time goes on, while the effort put into supporting install floppies seems to be on the rise. I certainly do not want to orphan these machines, so we need to find a compromise. One solution is to find a dedicated 'floppy maintainer' that will frequently assess the floppies during the normal developement periods and work closely with the Release Engineering team to ensure that there are few surprises when it's time to cut a release. I would expect this person to develop and execute a test plan that covers all of the common aspects of installing via floppy: basic sanity checks, loading drivers, installing via the various mechanisms, etc. This person should also be comfortable with modifying makefiles and the sysinstall source. The other solution is to replace install floppies with an 'Emulated El Torito' CD image. I'm not going to go into the differences between 'non-emulated' and 'emulated' except to say that 'emulated' is the method used on FreeBSD 4.x (and prior), Win95, and Win98. Virtually every system in existance that supports a CDROM supports this method. This image would contain the loader, kernel, and MFS root, just like the current 'bootonly.iso' image, but would be configured for emulated booting. Users could download this image, burn it, boot it, and then install FreeBSD just like they normally would. Of course this adds the requirement of needing a CD burner, but these devices are becoming common enough that it could be a reasonable expectation. Switching to this method doesn't entirely remove the headache of release floppies, but it does make it signficantly easier to deal with them. The 'emulated' method actually uses a 2.88MB floppy image that combines the first two 1.44MB floppies that we traditionally produce. By combining them, we have a bit more flexibility since the driver modules that are on the second floppy can go back into the kernel image and benefit from the compression that happens there. So, this is something to consider before 5.3. After that, we are stuck with the consequences of whatever we choose (or don't choose) for the entire 5.x lifespan. I do not cherish the thought of fighting floppies for another 2-3 years. I'm happy to work with someone who steps forward and is committed to maintaining the floppies as they are today. Otherwise, we need to seriously consider the alternative. Thanks, Scott I apologize if this is a dumb question. But rather than using two floppies during the install process, why not three or four? Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On 2004-01-09 11:38 -0600, Sean Farley [EMAIL PROTECTED] wrote: I admit to having not tried it, but I wonder how well OpenCM (http://www.opencm.org/) would compare. I think it would have a smaller footprint than Subversion. I have prepared a port of OpenCM, but didn't have time to test it, yet. For that reason, I have not yet imported it into the ports repository. Just in case somebody wants to test OpenCM (or my port ;-) Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Richard Coleman wrote: Scott Long wrote: All, Every FreeBSD release cycle in the past year has hit bumps due to install floppy problems. This is becoming more and more of a burden on the Release Engineering Team, as we simply do not have the resources to constantly battle the floppies. FreeBSD/i386 is the only port left that generates install floppies. Their primary purpose is to fascilitate installing FreeBSD on systems where a CDROM is either not available or is incompatible with the 'Non-Emulated El Torito' boot method that we use on our CDs. Systems that cannot boot these CDs are typically those that are also not certified for WinNT4, Win2K, or WinXP. Thus, nearly all machines produced after 1997 can boot our CDs. It is certainly possible to run FreeBSD 5.x on machines of this and prior vintage, and I certainly do not want to dispute or question any motives here. However, the number of machines in this category is steadily declining as time goes on, while the effort put into supporting install floppies seems to be on the rise. I certainly do not want to orphan these machines, so we need to find a compromise. One solution is to find a dedicated 'floppy maintainer' that will frequently assess the floppies during the normal developement periods and work closely with the Release Engineering team to ensure that there are few surprises when it's time to cut a release. I would expect this person to develop and execute a test plan that covers all of the common aspects of installing via floppy: basic sanity checks, loading drivers, installing via the various mechanisms, etc. This person should also be comfortable with modifying makefiles and the sysinstall source. The other solution is to replace install floppies with an 'Emulated El Torito' CD image. I'm not going to go into the differences between 'non-emulated' and 'emulated' except to say that 'emulated' is the method used on FreeBSD 4.x (and prior), Win95, and Win98. Virtually every system in existance that supports a CDROM supports this method. This image would contain the loader, kernel, and MFS root, just like the current 'bootonly.iso' image, but would be configured for emulated booting. Users could download this image, burn it, boot it, and then install FreeBSD just like they normally would. Of course this adds the requirement of needing a CD burner, but these devices are becoming common enough that it could be a reasonable expectation. Switching to this method doesn't entirely remove the headache of release floppies, but it does make it signficantly easier to deal with them. The 'emulated' method actually uses a 2.88MB floppy image that combines the first two 1.44MB floppies that we traditionally produce. By combining them, we have a bit more flexibility since the driver modules that are on the second floppy can go back into the kernel image and benefit from the compression that happens there. So, this is something to consider before 5.3. After that, we are stuck with the consequences of whatever we choose (or don't choose) for the entire 5.x lifespan. I do not cherish the thought of fighting floppies for another 2-3 years. I'm happy to work with someone who steps forward and is committed to maintaining the floppies as they are today. Otherwise, we need to seriously consider the alternative. Thanks, Scott I apologize if this is a dumb question. But rather than using two floppies during the install process, why not three or four? Richard Coleman [EMAIL PROTECTED] Sorry, I just got caught up on the list, and see that this has already been discussed. Ignore the question. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Somewhere around Fri, Jan 09, 2004 at 17:11 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: -- Message: 16 Date: Fri, 09 Jan 2004 22:57:56 +0100 From: Martin Nilsson [EMAIL PROTECTED] Subject: Re: Discussion on the future of floppies in 5.x and 6.x Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed This is getting stupid! This discussion is just like when the i386 support was removed from the GENERIC kernel, a lot of noise about old systems that wouldn't be able to run (or benefit) from FreeBSD 5 anyway. There is a difference between old systems and new systems that don't have CDs. And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. I fail to see the difference in required labour between creating two floppies or a CD-R/RW disc. Most new machines ship with CD-RW drives today, the only boxes that can't boot from a CD are early Pentium1 class and frankly why run 5.x or 6.x on those? I have several PIII's that can't boot from a CD because there is no room for a CD. These are 1RU units in a colo. A floppy, two HDs, on the back two NICs, a serial connector, and a keyboard connector. The iNTEL 1RU units don't even have graphics cards and the BIOS boot messgages are routed out the serial port which changes to true serial after POST. All are in a colo facility - and I suspect many other have the same problem. The only 1RU units I've personally seen with CD units in them are the little Sun pizza box Netras - SPARC platform - that a colo client had has front ends for their G4s [running Web Objects] and the large Sun running an Oracle back end for a data base. And those CD players were custom made - and exceptionally thin - and instead of a drawer that came out, the spindle mechanism came out that you put the CD onto and then it slid back in. Space is a big consideration in those small units. All my 2RU machine have CDs in them. I'd hate to have to think of taking the devices out of the racks and then the building to install a new OS. It's no fun with a floppy and minimal work space in the racks but I've only had to access them via floppy about twice, as I can rebuild and reinstall remotely. As long as I don't have to remake a file system I'm in good shape. But CD's just aren't always in 'industrial' type machines - as the only time they'd be used is during install. Luckily at least a couple will support PXE. Not all will be that lucky. End of freebsd-hackers Digest, Vol 42, Issue 10 *** Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 02:08:08PM -0800, Julian Elischer wrote: PXE boot against an automated backup/restore service would be much more useful for this. Assuming they have PXE and a supported card.. One point that hasn't been made here against PXE (well, not against it, but not in favour it): What if you dont' have another server to PXE boot from? What if it's the only PC in your house? PXE booting might be fine for a multi-server network, but when it's the only machine you have at home and you don't have a CD burner, you'd be screwed :) If the etherboot code can be made to use FTP, that would be good. Otherwise, can we have the mirror servers allow tftp? That would fix this quite easily. I might be willing to find hosting for a boot image provided it is small, as scott suggested it might be (3mb?) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
help with linking please
This is driving me insane... I would like to provide a client with a .o file so that he can link static against my library. Unfortunatly I need to hide nearly all the symbols in my object file. For a shared object this works out super easy, all I do is generate the .so file, then run strip -N on each symbol I want to nuke. I'm having a hell of a time doing this so I can produce a static .o or .a with most of the symbols stripped. Two problems seem to be that even if I use ld -r -o main.o obj1.o obj2.c libfoo.a then I can not strip symbols in obj1.o that are referenced from obj2.o even after I combine the object files. Any hints? -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Michel TALON wrote: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. Sincerely FreeBSD developers have more important tasks than spending hours to fit an installable system on floppies. When FreeBSD used one floppy, it was tolerable to do floppy installs. With 2 or 3 floppies it is awfully slow, i have done once and will never do it again. I still use floppies to do my installs, and find getting the base system up over FTP to generally take 30minutes *shrug* Faster, IMHO, then downloading the ISO and burning it to a CD .. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
SCM options (was Re: Where is FreeBSD going?)
Hi; There is a comparison here: http://better-scm.berlios.de/comparison/comparison.html I think there are compelling reasons to try subversion, but we have to wait for a 1.0 Release, and this would be something that should be done gradually.. for example moving the ports tree first. cheers, Pedro. __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: beastie boot menu, 4th (forth)
Roman Neuhauser wrote: I have two related questions, one being more appropriate for current@, the other for hackers@, but they're quite the same thing, so sorry for the cross-post, I hope it's tolerable (I bet this won't solicit many replies :). I dislike the boot menu in CURRENT, and would prefer something that * doesn't rob me of the text output so far * displays no mascots or other visual noise As was pointed out, adding 'beastie_disable=YES' to /boot/laoder.conf will do the trick. Here's the question perhaps more appropriate for hackers@: I looked into ripping the ascii-art out, but am quite scared. However, forth looks like it's an interesting (love/hate kind of thing) language, and I'd like to get my hands on it. Can anyone recommend good (or just any, really) introductory material? google quickly degrades into misses, and just a few even of those. A good link to start with is: http://ficl.sourceforge.net/ficl.html#whatis We use FICL, which is a particular implementation of Forth. And here's the one for current@: Failing the above query, does anyone have a replacement that meets my requirements? (But I'd really prefer hacking it myself, so links to tutorials are awarded with more points than off-the-shelf programs. :) TIA HAND! The only point for putting the mascot onto the screen was to fill unused space next to the menu. I you want to keep the menu and remove the mascot, just remove the line in beastie-menu that calls print-beastie. For astetics, you could then reformat the menu dimensions to take up the whole screen. Of course, leaving the menu on the screen at all defeats your first goal mentioned above. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: beastie boot menu, 4th (forth)
# [EMAIL PROTECTED] / 2004-01-09 15:32:35 -0700: Roman Neuhauser wrote: I have two related questions, one being more appropriate for current@, the other for hackers@, but they're quite the same thing, so sorry for the cross-post, I hope it's tolerable (I bet this won't solicit many replies :). I dislike the boot menu in CURRENT, and would prefer something that * doesn't rob me of the text output so far * displays no mascots or other visual noise The only point for putting the mascot onto the screen was to fill unused space next to the menu. I you want to keep the menu and remove the mascot, just remove the line in beastie-menu that calls print-beastie. For astetics, you could then reformat the menu dimensions to take up the whole screen. Of course, leaving the menu on the screen at all defeats your first goal mentioned above. so there's no way of having something output without clearing the screen? then I might just disable the menu completely, supposing there's an alternative similar to (or same as) the boot prompt in STABLE, which I have no problem with. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: beastie boot menu, 4th (forth)
Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2004-01-09 15:32:35 -0700: Roman Neuhauser wrote: I have two related questions, one being more appropriate for current@, the other for hackers@, but they're quite the same thing, so sorry for the cross-post, I hope it's tolerable (I bet this won't solicit many replies :). I dislike the boot menu in CURRENT, and would prefer something that * doesn't rob me of the text output so far * displays no mascots or other visual noise The only point for putting the mascot onto the screen was to fill unused space next to the menu. I you want to keep the menu and remove the mascot, just remove the line in beastie-menu that calls print-beastie. For astetics, you could then reformat the menu dimensions to take up the whole screen. Of course, leaving the menu on the screen at all defeats your first goal mentioned above. so there's no way of having something output without clearing the screen? then I might just disable the menu completely, supposing there's an alternative similar to (or same as) the boot prompt in STABLE, which I have no problem with. Remove the 'clear' word from beastie-start Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: beastie boot menu, 4th (forth)
Scott Long wrote: Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2004-01-09 15:32:35 -0700: Roman Neuhauser wrote: I have two related questions, one being more appropriate for current@, the other for hackers@, but they're quite the same thing, so sorry for the cross-post, I hope it's tolerable (I bet this won't solicit many replies :). I dislike the boot menu in CURRENT, and would prefer something that * doesn't rob me of the text output so far * displays no mascots or other visual noise The only point for putting the mascot onto the screen was to fill unused space next to the menu. I you want to keep the menu and remove the mascot, just remove the line in beastie-menu that calls print-beastie. For astetics, you could then reformat the menu dimensions to take up the whole screen. Of course, leaving the menu on the screen at all defeats your first goal mentioned above. so there's no way of having something output without clearing the screen? then I might just disable the menu completely, supposing there's an alternative similar to (or same as) the boot prompt in STABLE, which I have no problem with. Remove the 'clear' word from beastie-start Scott Actually, this isn't quite right since the menu and mascot will just overwrite whatever is already on the screen. The better solution would be to replace the 'clear' word in /boot/screen.4th with a version that spits out 25 line feeds. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Copyrights
In message: [EMAIL PROTECTED] Rahul Siddharthan [EMAIL PROTECTED] writes: : As for the copyright (C) the FreeBSD project bit: As I understand, : editors/publishers who compile anthologies can claim copyright on the : anthologies (the act of anthologisation itself being a creative : process) even if the individual articles in the anthology are : copyright by their respective authors. This is exactly correct. There's no 'overriding' or 'stealing' other people's copyright going on. This copyright assertion is on the software that's collected, as a whole, just like a collection of short stories have copyrights be the individual owners as well as the folks that published the book. Go to a bookstore and look at a collection of short stories by different authors and you'll usually discover that there are many copyrights listed: one by the publisher, and one for each of the stories by the author of the story. This is indeed different than the GPL where copyright is typically assigned to a third party for purposes of enforcement (usually the FSF). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 04:26:54PM -0600, Matthew D. Fuller wrote:
On Fri, Jan 09, 2004 at 02:23:58PM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
Dag-Erling Sm?rgrav wrote:
yes, we need something like
struct pci_device_info {
uint32_tpciid;
charbrand[64];
charmodel[64];
} my_supported_devices[] = {
{ 0x12345678, Acme, Nutcracker 2000 }
};
which is placed in a separate ELF section so we can extract it from
the module.
except it needs to be flexible enough to support other buses than PCI
(SBUS, USB...)
DES
Yeah, this is a good suggestion, the only problem being in making it
flexible enough to not be a burden on the drivers. Many drivers
keep one or more flag elements in their tables to flag hardware than
needs special attention. I'm sure that there are also countless other
pieces of state that drivers would want to associate with a table like
this.
I was poking around a bit (in my completely kernel-fu-lacking way) at
this last night. For one thing, we could avoid the struct definition,
and instead just mandate a few fields in the structure with given names
as above. Then, write a little helper .c file with a main() that goes
through the array (with the name given as a preprocessor -D or something)
and spits the info out into a text file. Compile it up and run it for
each module as we compile it, and assemble the results in a big reference
file. Then, a userland program (like sysinstall, in this case) can
easily poke through that text file to find and describe the drivers for
devices found.
This is more what I was thinking in terms of. As well as the PCI ID
and brand/model, we probably would need:
- a priority field, so a generic driver can grab a device if a more
specific driver isn't found
- the option to use card ID instead of chip ID
- wild-carding (maybe a bitmask)
And this still isn't enough to identify things like the Realtek 8139C+
chips that would prefer re(4) instead of rl(4) (though rl(4) is good
enough to install FreeBSD).
Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
