Re: Pull in upstream before 9.1 code freeze?
At 04:03 PM 7/4/2012, Doug Barton wrote: >Other than that, if whoever actually pushes all the rocks uphill to make >the installer more modular in this regard decides to include djbdns, >more power to them. :) I'm not suggesting that everyone will prefer djb, and the last thing I want to do is start a religious war regarding the merits of different resolvers or the efficacy of DNSSEC. I'm merely asking that any change to the base system or the installation procedure allow me to choose this or any of the other most popular resolvers, at install time, with as little pain as possible. --Brett Glass ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
At 06:39 AM 7/3/2012, Dag-Erling Smørgrav wrote: >I'm willing to import and maintain unbound (BSD-licensed validating, >recursive, and caching DNS resolver) if you remove BIND. I've been using djb, and -- despite its quirks -- I'm very happy with it. I'd like to have the option of installing dnscache, with the so-called "Jumbo" patch, as the default resolver. I beleive that the code has been released into the public domain. --Brett Glass ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: Negative ping times with FreeBSD 8.1-RELEASE on older Celeron system
More information regarding the odd behavior I'm seeing. Turns out that packets do not even need to leave the machine for it to report large negative ping times, on the order of more than half a second. (See below.) Clearly something is odd about timekeeping in this system (SiS motherboard chipset, PII-generation Celeron but still effectively a "686") which was not a problem when it was running FreeBSD 4.11-RELEASE (as it was before). Any ideas? --Brett Glass # ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=-0.148 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=-0.151 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=-686.111 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=-0.180 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.110 ms 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=686.351 ms 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=-686.376 ms 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.121 ms 64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=-686.402 ms 64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=-686.105 ms 64 bytes from 127.0.0.1: icmp_seq=10 ttl=64 time=686.623 ms 64 bytes from 127.0.0.1: icmp_seq=11 ttl=64 time=0.107 ms 64 bytes from 127.0.0.1: icmp_seq=12 ttl=64 time=0.119 ms 64 bytes from 127.0.0.1: icmp_seq=13 ttl=64 time=0.418 ms 64 bytes from 127.0.0.1: icmp_seq=14 ttl=64 time=0.401 ms 64 bytes from 127.0.0.1: icmp_seq=15 ttl=64 time=-0.169 ms 64 bytes from 127.0.0.1: icmp_seq=16 ttl=64 time=0.113 ms 64 bytes from 127.0.0.1: icmp_seq=17 ttl=64 time=0.401 ms 64 bytes from 127.0.0.1: icmp_seq=18 ttl=64 time=-686.117 ms 64 bytes from 127.0.0.1: icmp_seq=19 ttl=64 time=0.115 ms 64 bytes from 127.0.0.1: icmp_seq=20 ttl=64 time=0.111 ms ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Negative ping times with FreeBSD 8.1-RELEASE on older Celeron system
Here's a puzzler. I just put FreeBSD 8.1 up on an old (but good) 500 MHz Celeron with half a gig of RAM. Interfaces are classic xl (3Com) and dc (DEC tulip). Works quite nicely except for one quirk: ping times that ought to be positive (no more than 200 ms worst case) are coming out negative! Can't figure out what might be causing this. dmesg output is as follows: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE-p2 #5: Fri Apr 15 16:10:53 MST 2011 br...@washington.lariat.net:/usr/obj/usr/src/sys/WASHINGTON i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Family = 6 Model = 6 Stepping = 5 Features=0x183f9ff real memory = 536870912 (512 MB) avail memory = 515813376 (491 MB) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at devic e 0.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xbc00-0xbc7f mem 0xee80-0xeeff,0xef6f-0xef6f irq 11 at device 0.0 on pci1 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdc00-0xdc7f mem 0xefffaf80-0xefffafff irq 11 at devic e 8.0 on pci0 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:01:03:be:8b:c1 xl0: [ITHREAD] dc0: port 0xd800-0xd8ff mem 0xefffa800-0xefffabff irq 12 at device 9.0 o n pci0 miibus1: on dc0 ukphy0: PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:14:bf:5b:f5:ed dc0: [ITHREAD] xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xefffaf00-0xefffaf7f irq 9 at device 10.0 on pci0 miibus2: on xl1 xlphy1: <3Com internal media interface> PHY 24 on miibus2 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: Ethernet address: 00:40:ca:97:13:7a xl1: [ITHREAD] acpi_button0: on acpi0 acpi_button0: enable wake failed atrtc0: port 0x70-0x71 irq 8 on acpi0 orm0: at iomem 0xc-0xc7fff,0xc8000-0xc87ff,0xc8800-0xd7fff pnpid ORM on is a0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] Timecounter "TSC" frequency 501141912 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, nat enabled, rule-based forwarding enabled, default to accept, l ogging disabled load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched FIFO loaded ad0: 9787MB at ata0-master UDMA66 Trying to mount root from ufs:/dev/ad0s1a Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) Bump sched buckets to 64 (was 0) xl0: promiscuous mode enabled xl0: promiscuous mode disabled dc0: TX underrun -- increasing TX threshold dc0: TX underrun -- increasing TX threshold Any hints here as to what's wrong? --Brett Glass ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Wine compatibility and performance on FreeBSD 7
At 10:01 AM 12/11/2007, Julian H. Stacey wrote: >http://en.wikipedia.org/wiki/Wine_%28software%29 > "... originally released Wine under the same MIT License as the X > Window System, but owing to concern about proprietary versions > of Wine not contributing their changes back to the core project, > work as of March 2002 has used the LGPL" What apparently happened is that one or two of the developers of Wine got their knickers in a twist about the idea that -- heaven forbid! -- someone might possibly make some money for the enhancements they made to Wine. (Never mind that the marketing and development costs for their commercial versions of Wine were eating all of their profits, and it was unclear whether they actually WOULD make any money.) Also, it is rumored (though I have not seen proof of it) that John Gilmore, an underwriter of the Wine project, threatened to withdraw support from some of these developers unless the license was switched to the GPL, thus forcing their hands. --Brett Glass ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wine compatibility and performance on FreeBSD 7
It's worth noting that the WINE project, not long ago, abandoned the BSD license for the GPL despite urging from many sources to keep the code open and free for use by developers. We've stopped using it as a result. --Brett Glass At 10:59 AM 12/6/2007, Tom Wickline wrote: >Oh yea, were seeking contributors... if your interested in Wine on >FreeBSD and believe you can >help us out see : >http://wine-review.blogspot.com/2007/12/wine-review-is-currently-seeking.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where is FreeBSD going?
At 07:47 PM 1/6/2004, Avleen Vig wrote: >Advocacy is NOT a race Yes, it is. Linux is where it is today because it grabbed more buzz, sooner, than BSD. --Brett Glass ___ [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?
At 04:00 PM 1/5/2004, Munden, Randall J wrote: >I think this is what is on my mind these days. I'm preparing to load >up some machines for production soon (I've already put it off for too >long waiting for 5-STABLE) and I don't like what I'm seeing -- with >both the mud slinging here and the performance in the lab (mostly >anecdotal). I don't think that *this* conversation is mud slinging. What's happening on Slashdot, on the other hand, is. >> >> FreeBSD also keeps falling farther and farther behind Linux >> in the area of advocacy (and, hence, corporate adoption). >> Again, this is a governance >> issue. Many of the developers actually have an antipathy >> toward advocacy, >> since they dislike answering newbie FAQs and don't want too >> many people to adopt the OS for fear that it'll overcrowd >> their "sandbox." So, some of the criticism is actually valid. > >I noticed it too but I just chalked it up to being crazy busy >and not paying much attention. Nope, it's not because you're too busy. It's true. FreeBSD is getting fewer mentions in the mainstream press, and fewer commercial apps, lately. Linux is mentioned as if it was the ONLY alternative to Windows. Work is needed to raise FreeBSD's profile. --Brett ___ [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?
At 12:40 PM 1/5/2004, Munden, Randall J wrote: >Right. What concerns me most is the rise in the incidence of trolls all >trolling about the same subject or along the same vein. Would someone >please explain what is going on? As a production user of fBSD this is >troubling. It's probably one of the Slashdot "BSD is dead" trolls. The fact is, though, that there ARE things about FreeBSD that could stand improvement. These days, when I build a box, I am torn between using FreeBSD 5.x -- which is not ready for prime time but is at least being worked on actively -- and using 4.9, which isn't as stable as it should be because the developers broke the cardinal rule of making radical changes to -STABLE. This *is* a real issue for those of us who are admins. FreeBSD also keeps falling farther and farther behind Linux in the area of advocacy (and, hence, corporate adoption). Again, this is a governance issue. Many of the developers actually have an antipathy toward advocacy, since they dislike answering newbie FAQs and don't want too many people to adopt the OS for fear that it'll overcrowd their "sandbox." So, some of the criticism is actually valid. --Brett ___ [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?
I'd like to see a more open and inclusive form of governance for FreeBSD. The current system of governance has, as its underlying assumption, that the most prolific coders make the best leaders. In my personal experience, this isn't a valid assumption. System administrators and end users have a big stake in FreeBSD, and are just as likely (perhaps more likely) to be good leaders for the project. --Brett Glass At 11:43 AM 1/5/2004, Munden, Randall J wrote: >This makes me wonder if it isn't time for a new -core. > >-Original Message- >From: Maxim Hermion [mailto:[EMAIL PROTECTED] >Sent: Monday, January 05, 2004 12:30 PM >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Subject: Where is FreeBSD going? > > >I've been an avid follower of the developments in FreeBSD for around 5 >years now, so my overview of the entire history of "glue that binds" >FreeBSD together isn't complete. That said, I've come to be a bit >disappointed at how events in the last 18 months or so seem to be >pushing the project in a direction that has made things more difficult, >instead of >more successful, that has shown distain for experience and quality and >made FreeBSD a platform for large ego's to push their personal projects >down >everyone's throat. > >The statistics sample from 2001 over a year was a cheap attempt to >minimize Matt's contribution to the project. The reason why he has been >mostly silent is probably one of the most prominent signs of his >superior maturity. The fact that the official defense (mostly fronted by >Greg, >atm) >he wasn't such a substantial committer is crap, for the most part. If >one wanted to go by the stats, Jeff Robertson (sorry if I munged the >spelling) >would be one of the key committers, and his UMA system isn't even >entirely >ripe yet, it's just been committed within the sample timeframe. That >suddenly phk is at the top of the list, is simple a result of his newest >attempt to add another large chunk of bit rot to the project that he can >later claim not to have time to maintain "unless someone is willing to >pay for my time" (like the atm bits, the half-finished devd monster, >et.al.) One can hardly get him to look at his malloc bits, that put his >name in lights at some point in the long past. > >Matt didn't contribute because he was convinced that that the smp >development direction that was chosen (my impression at least from the >archives and my fading memory) was overly complex, too complex for the >number and talent level of the contributers involved, and that it would >delay a release from the -current branch significantly. So he was right. >I'll almost bet that that was a constant sore for John, who still hasn't >gotten his long-promised, but little delivered re-entrant work done, but >he always had time enough to object to any other commits that might help >along the way. Strangely Julian and Matt could work together. One might >attribute certain commits to both Matt and Julian (if that would matter >anyway, since -core is interested in proving the opposite >statistically). > >If the issue here had anything to do with IPFW, then you all better get >out your C-coder hats and take a little more time to fix that rotting >pile of muck that has been the standard broken packet filter interface >for FreeBSD long past its possible usefulness. A packet filter with no >central maintainer which is subject to once yearly random feature bloat >through some wild university project from Luigi. The brokenness that >Luigi introduced (and the repository bloat through backing out and >recommitting, ad absurdum) was probably no less a threat to security >than anything Matt did. If the security officer was to be blatantly >honest with himself, ipfw would be marked broken for either a full audit >or full removal (just port obsd's pf or something that someone actually >actively _cares_ about). > >You've alienated Jordan, Mike, Bill Paul (for all I can see), Greenman, >you constantly rag on Terry, even though he's seen and done more with >FreeBSD than most of you, O'Brien is on the verge of quitting (since he, >like I, am not convinced that GEOM is anything more than an ego trip >that will never be completely maintained or usefully documented). There >are certainly others, too, that have attempted to make technically >correct contributions, but didn't fit into the sort of paranoid "glee >club" that core would like to have around them. You guys lack the >talent to steer the positive from Matt into the project and let the crap >fall by the wayside. I'm not saying Matt's rants are the most >intelligent thing he's
Forged messages
It has come to my attention that an unknown party has been sending messages to several of the FreeBSD mailing lists from the address "[EMAIL PROTECTED]". The messages are not mine; they're being sent from a bogus account on a Webmail service known as FastMail. An abuse report has been filed with that service. Until the account is disabled, kindly ignore all mail from that address. --Brett Glass To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bgcc, an idea
Bill Fumerola wrote: > Fuck you Brett, we don't want you here. Speak for yourself asshole. Or have you forgotten already that it was you who caused asmodai to resign? A lot of people have contacted me already and given positive feedback for the 0.0 beta, so shut up. Sincerely, -- Brett Glass [EMAIL PROTECTED] -- http://fastmail.fm - Or how I learned to stop worrying and love email again To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bgcc, an idea
David O'Brien wrote:
> Excellent job, Brett, however, it gives me an error when I try to compile this:
> main ()
> {
> int i;
> i="Hello, world";
> printf("%i\n",i);
> return 0;
> }
David, don't send this kind of newbie programmer question to the hackers
list, or to any of the FreeBSD lists. If you're not up to the job, don't
bother sending bogus bug reports and patches. Now go and read a book on
Unix programming.
Sincerely,
--
Brett Glass
[EMAIL PROTECTED]
--
http://fastmail.fm - One of many happy users:
http://www.fastmail.fm/docs/quotes.html
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
bgcc, an idea
After the thread on GPL'd parts of FreeBSD, specially the compiler, I've decided to contribute my bit to the FreeBSD community. I'm proud to preset bgcc, 'The Brett Glass compiler collection', released under the BSD license, of course. As a lot of you know, I'm a professional programmer who does mostly embedded systems work, and the need for a truly free (free as in Richard Stallman blows dead goats) has arised many times. People can try an early beta, currently builds on FreeBSD and NetBSD. Get it from: http://www.brettglass.com/downloads/bgcc-0.0.tar.gz Brett Glass to the rescue one more time. Sincerely, -- Brett Glass [EMAIL PROTECTED] -- http://fastmail.fm - Or how I learned to stop worrying and love email again To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Great. Now, the anti-BSD spammers are spamming BSD mailing lists.
Time to get that Hotmail account turned off. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The problem with FreeBSD
At 02:39 AM 6/18/2002, Bill Flamerola wrote: >Okay, this is not really intended as a flame, but kinda necessary, given the current >situation in the FreeBSD camp. > >Let's see, some weeks ago a couple of people dropped their ports maintainership, why >did this happen? Sergey dropped his ports because David O'Brien is an asshole. Yes, >no news, we all know that. Asmodai resigned some days ago, why? Because fucking Bill >Fumerola is a royal asshole. Has fucking Bill Fumerola ever done any worthwhile work >for FreeBSD? NO. He prefers to spend his time flaming other people. FUCK YOU FUMEROLA! You actually make some good points about the nastiness of some people in the FreeBSD community. Alas, you discredit yourself by posting pseudonymously and by doing a great deal of flaming yourself. --Brett Glass To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ppp problems on 4.3-RELEASE and PPPoE
Brian: If he's having the same lockup as me, PPP is blocking on a select() while trying to re-establish a connection that has gone down. If there's a pppctl socket open and you're issuing commands it doesn't lock up. But when you shut down the socket by terminating pppctl the lockup occurs. The lockup also occurs if pppctl wasn't running at the outset. To reproduce the problem (and it's easily reproducible here), pull the client's Ethernet cable. The client will retry properly once. The second time it retries, it will lock. Since this may be adapter-dependent, try with an ed card (I think that everyone in the universe must have at least one of these). --Brett At 06:32 AM 5/21/2001, Brian Somers wrote: >Hi, > >I think it's important to quantify what a lockup is here. > >If pppctl is still working (ppp will talk to it), then it may be >worth seeing what ``show physical'' and ``show timer'' say (is the >link open, or is ppp waiting for something to happen via a timeout?). > >If pppctl isn't working it's worth building with -g and trying a kill >-11 (or attaching with gdb) to get a stack trace. > >Brett Glass (cc'd) has complained about a similar problem where it >seems that the ng_pppoe node is locked up. I can't reproduce the >problem here though :( > >> According to James Housley: >> > and I am not in Canada. I am using natd and ipfw for NAT and the >> > firewall. The link has a static IP if it matters. Below I am attaching >> > ppp.conf. I have watched some of the data with tcpdump on both tun0 and >> >> I'm also using ppp + ng_pppoe on a 4.3-STABLE system. My MTU is >> 1492. Configuration below. I'm experiencing lockups from ppp (average is one >> time a day). ppp stops recieving anything from the modem (Alcatel Speed Touch >> Home with ethernet). >> >> Any idea where it could come from? >> >> -=-=- >> default: >> set device /dev/cuaa0 >> set speed 115200 >> disable lqr >> deny lqr >> set redial 15 0 >> set reconnect 15 1 >> set accmap 0 >> set server +3000 >> >> adsl: >> set device PPPoE:ed0: >> set authname * >> set authkey * >> set timeout 0 >> set mtu 1492 >> set mru 1492 >> set speed sync >> disable acfcomp protocomp >> deny acfcomp >> set log Phase Chat LQM hdlc LCP IPCP CCP tun >> set ifaddr 0/0 0/0 >> add 0 0 HISADDR >> dial >> -=-=- >> >> Nothing interesting from the ppp log :-( >> -- >> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] >> FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 > >-- >Brian <[EMAIL PROTECTED]> > <http://www.Awfulhak.org> >Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Great American Gas Out
At 04:42 PM 3/3/2000 , Mark Newton wrote: >Our prices are held *up* by the fact that over 50% of them constitute >State and Federal taxes. Same in the US and Europe. Driving is a sin that must be taxed, y'know. This week, I traveled from Wyoming to California and discovered that gas prices were 25% higher in the Golden State than in the Cowboy State. Why? Because Californians "tax" themselves by requiring that everyone buy fuel with high concentrations of MTBE, an oxygenating agent. MTBE was supposed to reduce pollution, but in fact is a worse pollutant than oxides of nitrogen ever were. However, since only California refineries make gas with a high enough concentration of MTBE, Californians are locked into buying from these few sources and the price goes up. WAY up. Los Angeles will have $2.50 gas this summer. It's the same the whole world over. Energy policies and fuel costs aren't driven by markets or even common sense. They are controlled by big cartels, big government, and politics. --Brett Glass To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible optimization in VM?
At 10:42 PM 1/6/2000 , Matthew Dillon wrote: >Hmm. Well, you could copy the page to C1 in order to avoid creating > a C2 layer, at least as long as you do not have other entities sharing > B directly (e.g. C3, C4, ...). Yes, if you had C3, C4, etc. (multiple children), you'd need to make sure that each of them could get at what was originally in B. This means more copying -- either to each of the C's or someplace else. The thing is, most forks are followed by execs. The most common case is that they would never look at the old contents of B. So, it pays to make the copy operation as "lazy" as possible, since the odds are that not a single child will look at B. > This sort of optimization would reduce > the parent object's layering complexity but at the cost of increasing > the child object's layering complexity. > > The problem that we hit is that we really mess up the 'All Shadowed' > optimization if we start throwing pages into C1 that C1 didn't touch > itself. The C1 layer may wind up contaiing a significant number of > *additional* dirty pages, pages the child never actually touched > itself and thus pages that an additional forked child of the child > probably will not ever touch. They'd be substitutes for pages that would have been in C2, so we'd have as many dirty pages in either case, right? > This will prevent the 'All Shadowed' > optimization from occuring, resulting in a potentially deep VM Object > layering on one side of the graph. Hmmm. It seems to me that it would cause more pages to be "shadowed," thus actually accelerating the application of the optimization. Am I off base here? >The key to the 'All Shadowed' optimization is that it depends on locality > of reference in nearby layers. The locality of reference is messed up > if we start copying pages to layers whos governing processes didn't > actually touch. > > Another reason why we wouldn't want to do this is that it complicates > the VM Object layer accounting. It would be hard to tell whether C1 could > be collapsed into B without a C2. Or, if not hard, definitely more complex > then the C1,C2 -> B case where the collapsability of layers is visually > obvious. Well, in essence, we've really collapsed C2 into B (since it's serving to hold the parent's pages). So, haven't we already "won" by going straight to the state that an optimization might have achieved? --Brett To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
