RE: Imagestream WanIC-520 interface cards
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Louis A. Mamakos Sent: Wednesday, October 17, 2001 4:31 PM To: Ted Mittelstaedt Cc: void; Matt Dillon; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Imagestream WanIC-520 interface cards I am perfectly aware of this. The RBOCs deserved to have those fines levied against them for a number of years, to punish them for attempting to block the CLECs. However, it's been long enough for this, and in fact the money from the RBOCs is no longer being used to increase the CLEC's reach or service area (ie: infrastructure) and being used by the CLECS to bash each other, instead of bashing the RBOCS. The recip-comp charges have nothing to do with extending the reach of a CLEC's network. It's (supposed) to cover the cost of carrying or terminating an inbound POTS voice call. Back up a sec - the reason that Bellcore was busted up is because the trust people claimed that CLECs could provide voice dialup better and cheaper than ILECS by the sheer fact that they were competitive. The FCC has always pushed as hard as it could to give CLECs an advantage over RBOCS to promote competition. The RBOCS forced the call term charges as a fairness issue. Once it was discovered that the cash transfer was going towards the CLECS from the ILECS, the FCC couldn't have been happier. They never wanted things to be fair in the first place between the CLECS and the RBOCS. By the pro-breakup people's definition, the CLECS incur less cost than the RBOCS for terminating a call. If this was a fairness issue then the RBOCS would only have to pay the CLECS the actual cost incurred by the more efficient CLECS for the call term. But instead they pay what it costs the RBOCS to terminate a call (which is higher according to the pro-breakup people's definition) Now, obviously it's hard to know what the truth is because the entire point of Telco accounting is to so confuse the numbers that the PUC's and the FCC and all the other governmental regulators are so baffled by them that they pretty much throw their hands up in the air and accept whatever bullshit the phone companies care to dish out. Telco accounting is the science of making an absolute into a negotiated item. Huh? You might also explain the situation as subsidizing the cost of providing Internet service. It's revenue coming into the business which would otherwise need to come from some other source, such as the customers. And of course the entire point of running a Telco is to not make a profit by the customers that are supposedly paying you for the service your supposedly giving, but to screw everyone else in the business that's otherwise totally unaffiliated into paying for your customers. Yes, I know all about that. :-( There are lots of other examples of charges and tariffs which telecom carriers charge each other because of the bizzare reality set up by FCC regulations. You simply siezed upon one with contemporary sex-appeal. If you want to rant about something, go take a look at how half-circuit pricing is done for international private lines. Don't even get me started. There's a huge litany. Like, why are T1 charges so gouging yet DSL (which delivers more bandwidth in some cases) so rediculously low. Like, why is each trunk on a T1 charged at nearly the same rate as if it were provided by POTS yet it costs the phone company 10% of the expense to deliver trunks over T1 than POTS. Like why is mileage charges allowed in a calling area when it costs the phone company exactly the same amount to run a T1 5 miles as it does to run it 1 mile (and in some cases the CO is 4 miles from both endpoints so the total line length is 8 miles but they still only charge for 5) You think the US carriers are evil, go see what state-supported telecom monopolies get to do. Or the hoops which much be jumped through to get licenses to operate telecom, datacom, or Internet lines of business in some countries around the world. Ah - you mean like China. Don't forget all the state-sponsored porno filtering of the Internet feeds into Iran either. Yes there are some very nasty and greedy people in the world. Frankly, as long as the CLECs and ILECS are using the FCC to beat each other over the heads, I could care less. What I get mad about is that the CLECS seem to have given up fighting with the RBOCS and are turning against the ISPs. It's like they turn around and start bullying the ISP's simply because the ISP's are weaker than they are. Yet it was those ISP's that got the recipri-comp payments wacked out in the CLECs favor to start with. That's gratitude for you. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers
Re: Adding support for Duxbury PCI modem to FreeBSD 4.4
On Tue, Oct 16, 2001 at 11:47:59AM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Simon Dick writes: : Please don't remove the SurfRider one: : sio0: SmartLink 5634PCV SurfRider port 0xa400-0xa407 irq 12 at device 10.0 on pci0 : sio0: moving to sio2 : sio2: type 16550A : : It was me who submitted the ID for it, it's my main modem :) Wow! Cool. I didn't think that there were others. Do you know if this is a kermit chipset or not? Is there a Lucent part on the card with the word kermit on it (well, newer versions don't have kermit on them). I didn't see any, here's what's on the various chips on it if this helps: 1) TOPIC TP560i 9935S14 D7S82.1 2) (my guess is a mem chip) HMC HM62H256DJ-12 9815A D84B1 3) The biggest chip on the board EON EN29F002NT -70P 0021 I won't remove it. I was just surprised to find another one with the plethera of winmodems. Cool. So was I, I just found it advertised as Linux compatible and took a gamble :) -- Simon Dick [EMAIL PROTECTED] Why do I get this urge to go bowling everytime I see Tux? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: Bill Fumerola [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 11:13 PM To: Ted Mittelstaedt Cc: Doug Hass; Mike Smith; Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FYI On Wed, Oct 17, 2001 at 10:51:25PM -0700, Ted Mittelstaedt wrote: When we have a choice, we take the BSD code and improve it as necessary. Otherwise, we take what we can get. Sometimes, even, companies that release the stuff closed source end up opening it up when they see that by doing so that lots more people will contribute bugfixes and such. you say 'we' an awful lot for someone who isn't part of, doesn't represent, and is in no way affiliated with the freebsd project. thankfully, the project's official word can be found here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ policies-encumbered.html And, what exactly on this page is any different from what I've just said? Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Smith Sent: Wednesday, October 17, 2001 10:32 PM To: Ted Mittelstaedt Cc: Doug Hass; Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FYI That's silly, what did you find in it that's flamebait? I think you didn't read it. You're a) misrepresenting the project, b) dismissing the opinions and statements of others that are arguably more in touch with the project, and c) you won't let this stupid thread die. I do not feel that this thread is stupid. To the contrary I'm very concerned when a manufacturer pulls a specialty card supported by FreeBSD off the market and replaces it with nothing that is supported. Every time this happens (and it seems to be happening a lot with network adapters lately) it causes problems for a lot of users, confusion because This rev of the card is supported and That rev isn't, extra work for the maintainers, and in short sets the project back. This does not help FreeBSD to support lots of peripherals, as Doug pointed out we are being ignored by the RAS card manufacturers, and nobody is going to use FreeBSD no matter how good the kernel is if the OS doesen't support the hardware they own. Telling Imagestream we built a module architecture that makes writing, maintaining and deploying binary-only drivers easy is fine, but it does nothing to respond to the problem of how to convert their binary drivers to our framework. They don't even understand we have a framework, let alone how it operates. They are asking us to write the drivers and they don't even understand that some of the developers that could do it have reservations against binary-only drivers only available under NDA, or how much more it could help them if they were to just publish source. And attempting to even talk about this openly leads into irrelevant pointless accusations about stealing intellectual property. Device driver support in PC operating systems seems always to have been a political football no matter what OS vendor - even Microsoft with all their power still was forced into writing drivers for some hardware, despite all the pressure they applied to the hardware vendors to do the work. You seem to be taking the attitude that we made a framework, and that's as far as we go - you write the driver and then labeling any further discussion on the matter as stupid. Well, if this is the attitude in the FreeBSD project (which I doubt) then if it was such an effective one then why does Linux seem to have many more drivers written for it? No, I am well aware of FreeBSD's history and if you don't believe that the project avoids closed-source code then I don't know what to say, frankly. You could say I'm wrong. It'd be a good start. OK, your right, I'm wrong. Contrary to my statement, FreeBSD attempts to get as much closed-source code as possible. That's why the name of the distribution starts with the word Free Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
You're a) misrepresenting the project, b) dismissing the opinions and statements of others that are arguably more in touch with the project, and c) you won't let this stupid thread die. I do not feel that this thread is stupid. This much is obvious. You are, however, largely alone in this opinion. To the contrary I'm very concerned when a manufacturer pulls a specialty card supported by FreeBSD off the market and replaces it with nothing that is supported. If you're very concerned about it, I recommend doing something constructive to mitigate the situation. The vendor in question appears to have offered a bounty for a driver; why don't you get busy on it? Every time this happens (and it seems to be happening a lot with network adapters lately) It does? Really? You know, I can only think of one ethernet chipset currently on the market that we don't support, or don't have imminent support coming for. That's not a lot by any stretch of the imagination. So I'll say it all again, in a slightly different fashion: You sound too much like Brett Glass. Less hysteria, please, and a little more practicality. = Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: altq question.
On Thu, Oct 18, 2001 at 01:46:06PM -0400, Kenneth Wayne Culver wrote: I was wondering if anyone had ever used altq to throttle people on an adsl connection. Basically what I want to do make each user share bandwidth evenly, but in such a way that they can use all the available bandwidth individually if nobody else is using it. However, I also want to be able to set aside some of that bandwidth for ssh. The problem is on my machine, with dummynet, I can do all this, but when I set it up to limit both incoming (608Kbit/s) and outgoing (128Kbit/sec) connections, the ping time through the machine goes up by 5 seconds, if I turn off the queuing either you have set the bandwidth wrong (does ipfw pipe show list the speed you want for the pipes ? can you post its output ?) or you are doing the measurement on a saturated link, in which case when you use dummynet with dynamic queues you have a lot more buffering going on, and this would explain why you see higher ping times (but perhaps without it you see some large amount of losses) ? cheers luigi options on the outgoing connections/packets, the ping returns to normal. Also, I can't figure out with altq how to set up different incoming and outgoing bandwidths. Does anyone have any experience doing anything like this with altq? if not, can someone tell me how to fix my ping problem with dummynet? Thanks. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
Gordon Tetlow [EMAIL PROTECTED] writes: M1 (Patch included) Setup infrastructure Make rcorder compile Your rcorder patch is incorrect. FreeBSD lacks a prototype for fparseln(). It so happens that it doesn't make any difference on any of the platforms FreeBSD supports (because our ints and pointers are the same size), but that's no reason not to do things right. Also, I don't see the point in munging the Makefile like you do - I think we can live with having a Makefile that's slightly (and trivially) different from NetBSD's. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: altq question.
either you have set the bandwidth wrong (does ipfw pipe show list the speed you want for the pipes ? can you post its output ?) or you are doing the measurement on a saturated link, in which case when you use dummynet with dynamic queues you have a lot more buffering going on, and this would explain why you see higher ping times (but perhaps without it you see some large amount of losses) ? ipfw pipe show shows the correct amounts. I did the measurements on a non-saturated link, I'm sure of this because when I ipfw flush, ipfw queue flush, the ping goes back to normal. I have no packet loss either way, whether dummynet is configured or not. An added note, this is running on an 533 MHz alpha with a de type card hooked to the dsl modem running at 10Mbit/sec full duplex (dsl connection is rated at 608Kbit/s down and 128 Kbit/s up), and an xl type card connected to the internal net running at 100Mbit/sec Full duplex. My configuration looks like this: ipfw add queue 1 ip from any to x.x.x.x/24 in via de0 ipfw add queue 2 ip from x.x.x.x/24 to any out via de0 ipfw pipe 1 config bw 570Kbit/s queue 47 ipfw pipe 2 config bw 118Kbit/s queue 10 ipfw queue 1 config pipe 1 weight 40 mask dst-ip 0x00ff ipfw queue 2 config pipe 2 weight 40 mask src-ip 0x00ff I set it to 570Kbit/s download because this is the top download speed I measured (I get this speed to pretty much every site I download from, to arrive at this number I downloaded a file 2 times from a site that gave me around 62Kbytes/sec (my max speed), then I turned on queueing with successively larger bw values for pipe 1 until I could attain my top speed, then I added 10 Kbit/s just to be sure that I was getting the full wirespeed my connection would support. I did this for the upstream as well) Thanks for your help. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Problems with booting of CD-ROM (fwd)
Thomas Dixon wrote: [snip] I have done this now and it loads the mfsroot.gz file, however I can't find any man pages or web pages that tell me how to create an mfsroot file. Any ideas on this? see boot.flp target in /usr/src/release/Makefile it is much simple to work on the original boot.flp or mfsroot.flp, such as : mkdir /kern /flp /mfs vnconfig -c /dev/vn0c /tmp/kern.flp mount -t ufs /dev/vn0c /kern ls -l /kern drwxr-xr-x 2 root wheel 512 Apr 21 13:15 boot -r-xr-xr-x 1 root wheel 1241170 Apr 21 13:15 kernel.gz do your stuffs on /kern (use gzip -9 instead of kgzip is you replace the kernel, it a little bit more efficient). umount /kern vnconfig -u /dev/vn0c vnconfig -c /dev/vn0c /tmp/mfsroot.flp mount -t ufs /dev/vn0c /flp ls -l /flp -rw-r--r-- 1 root wheel 860566 Apr 21 13:11 mfsroot.gz gzcat /iso/mfsroot.gz /tmp/mfsroot vnconfig -c /dev/vn1c /tmp/mfsroot mount -t ufs /dev/vn1c /mfs ls -l /mfs lrwxrwxrwx 1 root wheel 6 Apr 21 13:11 bin - /stand drwxr-xr-x 2 root wheel 512 Apr 21 13:11 boot drwxr-xr-x 2 root wheel 512 Apr 21 13:11 dev drwxr-xr-x 3 root wheel 512 Apr 21 13:11 etc drwxr-xr-x 2 root wheel 512 Apr 21 13:11 mnt lrwxrwxrwx 1 root wheel 6 Apr 21 13:11 sbin - /stand drwxr-xr-x 4 root wheel 1024 Apr 21 13:11 stand do your stuffs on /mfs then reverse everything... umount /mfs vnconfig -u /dev/vn1c gzip -9 /tmp/mfsroot /flp/mfsroot.gz umount /flp vnconfig -u /dev/vn0c not tested but should work... Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. I'm actually working on a driver for the SBS WANic 600 and 800 cards. There is still a lot of work and testing to be done, but (assuming there are no problems with the powers that be over here, and there are no conflicts with our agreements with SBS) I do eventually plan on posting the code (under a BSD license). I'll keep y'all posted. tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
Hi, I've prepared a status report about this project. the xml file in attachment have to be reviewed since I've just put descriptions from FreeBSD-rc's Yahoo! Group and your email message. first of all, there should be a consensus about the owner of this project ? also, who create the FreeBSD-rc's Yahoo! Group ? then you have to submit a status report to avoid duplicates work... I also done some stuffs on this some months ago, but I have to review it. don't remember the status of my job... :( Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] !-- $FreeBSD$ -- project titleImproving FreeBSD startup scripts/title contact person name givenDoug Barton/given commonCommiter/common /name email[EMAIL PROTECTED]/email /person person name givenGordon Tetlow/given commonContributor/common /name email[EMAIL PROTECTED]/email /person /contact links !-- A hypertext link with a description... -- url href=http://groups.yahoo.com/group/FreeBSD-rc/;Improving FreeBSD startup scripts/url url href=http://www.cs.rmit.edu.au/~lukem/bibliography.html;Luke Mewburn's papers/url url href=http://www.netbsd.org/Documentation/rc/;NetBSD Initialization and Services Control/url /links body -- from http://groups.yahoo.com/group/FreeBSD-rc/ -- pThis group is for discussion about the startup scripts in FreeBSD, primarily the scripts in /etc/rc*. Primary focus will be on improvements and importation of NetBSD's excellent work on this topic./p -- from [EMAIL PROTECTED] -- pAlright folks, I finally got off my butt last night and put together a roadmap for the migration to the new rc.d init scripts that were imported from NetBSD a long time ago and just sat in the tree./p pM1 (Patch included)br Setup infrastructurebr Make rcorder compilebr Hook rc.subr into the distribution (and mergemaster)br Hook rcorder into the worldbr Add toggle in rc.conf to switch between rc_ng and current boot scripts/p pM2br Get FreeBSD to boot with the new boot scriptsbr Rewrite the /etc/rc.d scripts to work with FreeBSD/p pM3br Add some FreeBSD specific support into rc.subr/p pM4br Add true dependency checking to the infrastructure so that starting nfsd will start mountd and rpcbindbr Add support into rc.subrbr Add dependencies into rc.d scripts/p pI'd like a couple of people to take a look at this and then I'll submit a pr for it if there aren't too many objections. I'm expecting M2 to run into quite a bikeshed, but hey, I got my nice shiny asbestos back from the cleaners./p /body /project
Circular log patches for syslog
Hi, While working on another project, I made some patches to syslogd to support circular logfiles: http://software.wwwi.com/syslogd/ The syslogd patch includes changes to the man page to reflect the new usage. I don't know if this is useful to anyone else, but it came in handy for me on a small-footprint embedded project that couldn't afford to let logs grow unbounded. We have been using this in house without problems for awhile now. Any feedback on this would be appreciated. Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
after reading -arch, the contact and links sections have been updated. Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] !-- $FreeBSD$ -- project titlercNG: Improving FreeBSD startup scripts/title contact person name givenDoug Barton/given commonCommiter/common /name email[EMAIL PROTECTED]/email /person person name givenKevin Way/given commonContributor/common /name email[EMAIL PROTECTED]/email /person person name givenGordon Tetlow/given commonContributor/common /name email[EMAIL PROTECTED]/email /person /contact links !-- http://groups.yahoo.com/group/FreeBSD-rc/ -- url href=http://groups.yahoo.com/group/FreeBSD-rc/;Improving FreeBSD startup scripts/url url href=http://www.cs.rmit.edu.au/~lukem/bibliography.html;Luke Mewburn's papers/url url href=http://www.netbsd.org/Documentation/rc/;NetBSD Initialization and Services Control/url !-- http://overtone.org/rc.d/ -- url href=http://overtone.org/rc.d/;FreeBSD rc.d reorganization project/url /links body -- from http://groups.yahoo.com/group/FreeBSD-rc/ -- pThis group is for discussion about the startup scripts in FreeBSD, primarily the scripts in /etc/rc*. Primary focus will be on improvements and importation of NetBSD's excellent work on this topic./p -- from [EMAIL PROTECTED] -- pAlright folks, I finally got off my butt last night and put together a roadmap for the migration to the new rc.d init scripts that were imported from NetBSD a long time ago and just sat in the tree./p pM1 (Patch included)br Setup infrastructurebr Make rcorder compilebr Hook rc.subr into the distribution (and mergemaster)br Hook rcorder into the worldbr Add toggle in rc.conf to switch between rc_ng and current boot scripts/p pM2br Get FreeBSD to boot with the new boot scriptsbr Rewrite the /etc/rc.d scripts to work with FreeBSD/p pM3br Add some FreeBSD specific support into rc.subr/p pM4br Add true dependency checking to the infrastructure so that starting nfsd will start mountd and rpcbindbr Add support into rc.subrbr Add dependencies into rc.d scripts/p pI'd like a couple of people to take a look at this and then I'll submit a pr for it if there aren't too many objections. I'm expecting M2 to run into quite a bikeshed, but hey, I got my nice shiny asbestos back from the cleaners./p /body /project
Re: Circular log patches for syslog
Jeffrey D. Wheelhouse wrote: While working on another project, I made some patches to syslogd to support circular logfiles: http://software.wwwi.com/syslogd/ The syslogd patch includes changes to the man page to reflect the new usage. how do you decide the size of the circular log ? Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Circular log patches for syslog
-Original Message- how do you decide the size of the circular log ? There's a utility included to unwind the log file into time order. It includes a command line option to create logfiles of user-defined size. http://software.wwwi.com/syslogd/clog.html Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: clustering code
If you are going to build clusters with over 1000 nodes, you should then install a batch system instead of using kernel-based clustering services. Rayson --- Ronald G Minnich [EMAIL PROTECTED] wrote: well that's just wrong. 4 nodes? nope. I've got buddies at bio startups who start at 1024 nodes. There's lots of other companies too. ron __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
- Original Message - From: Tim Wiess [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 19, 2001 7:12 AM Subject: Re: FYI If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. I'm actually working on a driver for the SBS WANic 600 and 800 cards. There is still a lot of work and testing to be done, but (assuming there are no problems with the powers that be over here, and there are no conflicts with our agreements with SBS) I do eventually plan on posting the code (under a BSD license). I'll keep y'all posted. tim Yay Tim Unfortunately my skills(?) lie in the database arena or I would have jumped in myself a _LOT_ earlier and try to solve the EOL runout myself. Murray T To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Ted Mittelstaedt wrote: From: Doug Hass [mailto:[EMAIL PROTECTED]] The lack of flexibility in accepting various requirements illustrates the difference between an OS WITH legs in the market and one WITHOUT legs. Much to my chagrin, FreeBSD continues to fall more and more into the latter category. This is a gross simplification of a great many issues. I fail to see why you feel that FreeBSD is threatening anyone's IP and I don't understand why you are reacting this way. Any company is free to take the FreeBSD distribution and customize it the way they want and include any proprietary and binary code they want and hand out distributions as they see fit. Imagestream could do this Well, honestly, FreeBSD makes the life of the developers of third-party binary-only drivers fairly difficult. The reason is that there are a lot of API changes happening between the releases (take Julian Elisher's recent problem for example). So the driver writers are forced to at least recompile their drivers for each release. Plus people are very active at ripping away the old APIs even when there is no immediate need for that nor benefit from it (think of phk's removal of the LIST-something macros). So often not a simple recompilation but a noticeable rewrite may be required for a driver between different versions of FreeBSD. That actually is true not only for the drivers but for the usual binaries too. For example, there seems to be no way to combine COFF and ELF libraries into one executable. That made porting of Lyx to 4.0 unfeasible, as the binary-only Xforms library it used was at the time available in the COFF form only. And I haven't found how to build even purely COFF binaries on an ELF-ized system either. ALl this is a significant pain for everyone porting their software to FreeBSD and much stronger yet for those doing binary-only distributions. Maybe we should have an official policy of keeping the things compatible and available for as long as possible even if they are considered obsolete, unless carrying them on requires a major effort. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Well, honestly, FreeBSD makes the life of the developers of third-party binary-only drivers fairly difficult. It does? On the whole, actually, I'd say we do a pretty good job of making it easy. The reason is that there are a lot of API changes happening between the releases (take Julian Elisher's recent problem for example). It's a poor example. Drivers don't involve themselves in the sysinit chain. So the driver writers are forced to at least recompile their drivers for each release. This isn't typically the case, actually. 4.x has in fact been very good in this regard. Plus people are very active at ripping away the old APIs even when there is no immediate need for that nor benefit from it (think of phk's removal of the LIST-something macros). The removal of the LIST* macros doesn't affect the kernel interface (they're macros, not functions). So often not a simple recompilation but a noticeable rewrite may be required for a driver between different versions of FreeBSD. I've been maintaining drivers for a while now, and frankly, I just don't see this. That actually is true not only for the drivers but for the usual binaries too. For example, there seems to be no way to combine COFF and ELF libraries into one executable. Of course there isn't, and there'd be no point in it. That made porting of Lyx to 4.0 unfeasible, as the binary-only Xforms library it used was at the time available in the COFF form only. And I haven't found how to build even purely COFF binaries on an ELF-ized system either. Use a cross-gcc setup. Of course, you mean a.out, but your error doesn't help your case much. Maybe we should have an official policy of keeping the things compatible and available for as long as possible even if they are considered obsolete, unless carrying them on requires a major effort. We do. And we do. Of course, this effort goes largely unnoticed and unthanked, since you're not going to comment on it unless you're personally inconvenienced by it. I've asked before, I'll ask again. Will folks please just let this die? You're producing a great deal of archive-filling material that's just not accurate or relevant, and your misinformation is harmful to the Project in a very real fashion. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
On 18 Oct 2001, Dag-Erling Smorgrav wrote: Gordon Tetlow [EMAIL PROTECTED] writes: M1 (Patch included) Setup infrastructure Make rcorder compile Your rcorder patch is incorrect. FreeBSD lacks a prototype for fparseln(). It so happens that it doesn't make any difference on any of the platforms FreeBSD supports (because our ints and pointers are the same size), but that's no reason not to do things right. I was wondering about that warning myself, but it seemed to work and I don't try to pretend to be a master of C. I'll stick to the shell world in general. Also, I don't see the point in munging the Makefile like you do - I think we can live with having a Makefile that's slightly (and trivially) different from NetBSD's. Fair enough, everyone seemed to be touting the flag of portability so I just added it into the mix as well. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
On 18 Oct 2001, Dag-Erling Smorgrav wrote: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Your rcorder patch is incorrect. Here's a correct patch. Does anybody mind if I commit this and connect rcorder(8) to the build? Actually, fparseln() is defined in libutil.h (per the man page). I don't have my current box available (power outage at home), but if you could look over it, it should work. -gordon Index: rcorder.c === RCS file: /home/ncvs/src/sbin/rcorder/rcorder.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 rcorder.c --- rcorder.c 16 Jun 2001 07:16:14 - 1.1.1.1 +++ rcorder.c 18 Oct 2001 19:45:27 - @@ -41,7 +41,11 @@ #include stdlib.h #include string.h #include unistd.h +#if defined(__NetBSD__) #include util.h +#else +#include libutil.h +#endif #include ealloc.h #include sprite.h To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
Gordon Tetlow [EMAIL PROTECTED] writes: Actually, fparseln() is defined in libutil.h (per the man page). I don't have my current box available (power outage at home), but if you could look over it, it should work. Ah, that's right - I couldn't find the right header, I should have simply looked at the libutil Makefile. Thanks! DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
On 18-Oct-01 Dag-Erling Smorgrav wrote: Gordon Tetlow [EMAIL PROTECTED] writes: M1 (Patch included) Setup infrastructure Make rcorder compile Your rcorder patch is incorrect. FreeBSD lacks a prototype for fparseln(). It so happens that it doesn't make any difference on any of the platforms FreeBSD supports (because our ints and pointers are the same size), but that's no reason not to do things right. Huh? Int on alpha is 32, and pointer is 64. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
John Baldwin [EMAIL PROTECTED] writes: Huh? Int on alpha is 32, and pointer is 64. I thought we were ILP64 on 64-bit archs, but you're right. And I ought to know better... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Your rcorder patch is incorrect.
Here's a correct patch. Does anybody mind if I commit this and
connect rcorder(8) to the build?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: Makefile
===
RCS file: /home/ncvs/src/sbin/rcorder/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile 16 Jun 2001 07:16:14 - 1.1.1.1
+++ Makefile 18 Oct 2001 19:44:57 -
@@ -3,11 +3,12 @@
PROG= rcorder
SRCS= ealloc.c hash.c rcorder.c
MAN= rcorder.8
+WARNS?= 2
LDADD+= -lutil
DPADD+= ${LIBUTIL}
# XXX hack for make's hash.[ch]
-CPPFLAGS+= -DORDER
+CFLAGS+= -DORDER
.include bsd.prog.mk
Index: rcorder.c
===
RCS file: /home/ncvs/src/sbin/rcorder/rcorder.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 rcorder.c
--- rcorder.c 16 Jun 2001 07:16:14 - 1.1.1.1
+++ rcorder.c 18 Oct 2001 19:45:27 -
@@ -41,7 +41,11 @@
#include stdlib.h
#include string.h
#include unistd.h
+#if defined(__NetBSD__)
#include util.h
+#else
+char *fparseln(FILE *, size_t *, size_t *, const char[3], int);
+#endif
#include ealloc.h
#include sprite.h
Possible bug in scheduler.
FreeBSD 4-stable. Suspect the same in FreeBSD-current. resetpriority() calls maybe_resched() at the end after updating p_usrpri based on changed p_estcpu. maybe_resched() uses curpriority_cmp to compare priorities of current and given process and this function ( curpriority_cmp ) uses p_priority which is unchanged yet - the new p_usrpri is not reflected to p_priority yet. I'd appreciate an answer from anybody who can assess this problem. Regards Alex Levine. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
