Re: Please help with NAT
Gergo Szakal wrote: Damn, sent too soon. :-) So it has altq. other undocumented feature is filtering by uid/gid (many people don't know about this hence they don't switch to pf from ipfw). That sounds good until I recall writing high-speed driver code (machine, asm, Forth) and shudder to think of the CPU cycles it must cost. Not to mention the line-count of C code required. ;-) Bill
Re: Xen vs VMware
Steve Mynott wrote: On 10/18/06, Matthew Dillon [EMAIL PROTECTED] wrote: Generally speaking I prefer the VMWare concept over the Xen concept. Xen actually has to run two operating systems, one serving as the master and the other as the 'guest' OS, and this compounds the number of potential bugs you might run into a lot more then a machine emulator does. I'm surprised by this. Xen (abstracting out some sort of meta operating system) seems a cleaner and simplier solution to me than running a complex software copy of real hardware. Anyway aren't we just talking about lines of C in both cases? I suspect the number of bugs in either would just be a function of the total lines of C. Xen is relatively small. Although vmware source, isn't available AFAIK would anyone care to estimate lines of source for it? Given that it is a commercial product? Aren't such coders paid by printout-weight? ;-) More seriously - look at the sizes of the binaries. The compiler has (hopefuly) sweated the worst of the diffrences out by then, else it would be far slower than it is..) VmWare not only has to emulate an entire machine, it has to also 'virtualize' the peripheral I/O fs - and therein lies a bit of a mystery. I've had my hands on a lot of these sort of products over the years, and one of the more curious experiences came out of the Connectix/InnoTek (Now Microsoft) 'Virtual PC' - from Intel/AMD O- used on OS/2 Windows thru OSX G4 versions. Whether 'benchmarks' or day to day, experience will vary all over the lot, but over time the curiosity was that a 'typical' VPC-emulating-Intel on-Intel with FAT fs seemed to run about 40 to 50% of the speed of the underlying hardware. Actually quite decent if one had a 1 or 2 GHz platform and had become accustomed to a 400-500 Mhz one anyway. The curiosity was that VPC-emulating-intel on-PPC-G4 wiht hfs(+) was much faster! Approximately 700 MHz Intel performance on a mere 1 GHz G4. And I don't kid myself that OSX is anywhere near as efficient as OS/2 (or necessarily even a 'stripped for combat' industrialized-version of NT - see LitePC). So - some of these are well-debugged and refined products. Matt's viewpoint and mine do differ, though. I'd like to see a 'DragonXen' to use for 'mothership' of baby Dragons, and Beasties in general. Something more akin to big-iron VM/MV - 'in between' having to emulate *everything* and bare-bones 'meet me half way or go panic yerself' Xen. AIX-5L-like, perhaps..? If/as/when I am ever moved to an Intel-ized Mac (d'ruther have polio..), 'Parallels' is on my 'must try' list. But to run *BSD guests and legacy OS/2, not WinWoes! What with dualcore and more we are on the brink of a whole new set of major changes. 83 year old mum just told me of a schoolmate of hers, gone deaf, who is now reliant on a real-time speaker-independent speech-to-text telephone with screen. Yesterday's lab gear is today's appliance Bill Bill
Re: Cable internet
Bryan Berch wrote: It is about I get rid of dial-up and get something faster. My only other choice is Comcast broadband. My questions are: 1. Has any one used it and is it worth it? 2. What cable modem did you use? Thanks Bryan I've used Motorola on three different providers and Terrayon on two, prefer the Motorola. All these are mass-produced to a price target and have components that deal with analog and are exposed to rude spikes and such during their lifetime. You CAN get a bad one - right out-of-the box, and the DO suffer damage and failure in use. My response has been to rent, not buy, as a replacement seems to be needed every 12-24 months where there are regular thunderstorms. Caveat: Use some other mx for your e-mail, not comcast. Our MX'en blacklist all of comcast, as they do nothing useful to block outbound to port 25, and are *infested* with Win-Zombies. Bill
Re: Network Slowdowns?
Jamie wrote: * snip* The lights show 100mbs if that means anything. :-) Jamie It could. Dunno if Unix will even (still) DO this, but OS/2 was happy as a clam running 'ethernet protocol' point-to-point between two boxes. No need for the higher-level TCP/IP 'layer'. Lean, mean, and fast, but had to have manual routing set up. Bill
Re: Network Slowdowns
Paul Allen wrote: See commit relating to revision 1.258 of if_fxp.c (in FreeBSD) There is some evidence that this problem is not localized to fxp but common to many driver implementations. - Forwarded message from John-Mark Gurney [EMAIL PROTECTED] - Jeremy Chadwick wrote this message on Thu, Oct 05, 2006 at 09:08 -0700: The problem in that case turned out to be duplex-related. Both boxes were auto-negotiating with the Cisco switch correctly, and indeed the Cisco labelled them as auto-100/full, but as anyone who is familiar with Ciscos knows, auto-negotiation on Catalysts is far from reliable. Both boxes reported auto-neg and being at 100/full as well. I ended up hard-setting the boxes to use 100/full, and set the switch ports to 100/full, then rebooted both boxes (yes, this is sometimes required, as driver auto-neg code is a bit tweaky); voila, problem fixed. It appears that some ethernet drivers don't reset the phy (bring the link down) when changing media (duplex setting, etc).. This means that if you boot w/ autoselect, and the switch autoselects to 100/full, but then later change it to 100/full (w/ autoselect off) it will work fine.. but then if the cabel is pulled, or the switch resets, it attempts to reautoselect, but falls back to 100/half while you are still running 100/full... As you can imagine, it causes a very hard to track down problem since the time it breaks is not readily apparent... First two whole generations of Intel 10/100 did that, *even if* set to fixed 100-FDX. Killer wasn't just cable move - one learned to check on that. But they went walk-about after a power-outage on the 'SWUB' as well. First generation just stopped talking altogether. Switched to DEC until they were bought by Intel, then RealTek, AKA el-cheapo. Back with Intel and Broadcom Gig-E now, and no longer a hassle. an ifconfig iface down; ifconfig iface up may help resolve this issue if you are not sure... I have just committed a patch to fxp0 to do this... Good news! Bill
Re: For the laughs :)
Sascha Wildner wrote: New predictions from our old friend Danial Thom: My prediction is that a year from now we'll all be using DragonflyBSD and you guys will be looking for a new bunch of beta-test guinea pigs. Thanks to Ancient on #dragonflybsd for noticing. http://lists.freebsd.org/pipermail/freebsd-performance/2006-October/002194.html Sascha It gets better ... a few messages further along the 'please don't feed the troll' and '...a known troll' responses show up. One can run, but one cannot hide... === Scene from 'The Life and Times of Judge Roy Bean' Villain: 'Who's there?' Judge Bean: JUSTICE! you son of a bitch! (sound of a Colt .44 fired through the door) ;-) Bill
Re: Network Slowdowns?
Jamie wrote: Just to let anyone know.. As pr. sephe's instructions I did this: line 433 in /usr/src/sys/dev/netif/xl/if_xlreg.h Changed this: #define XL_MIN_FRAMELEN 60 To this: #define XL_MIN_FRAMELEN 240 I don't know what that did though? So far, no errors but file copies are still slow. Makes me suspect the underrun errors weren't related? About ~ 1 mb/sec across a 100mbs ethernet connection. Correct me if I'm wrong, but shouldn't this be closer to 5-10 megabytes/sec, assuming 100mbs is bits pr. second and NFS had a rather large overhead? (say, 1/2 of it is protocol related?) With the most-bandwidth-efficient of uncompressed protocols (never mind 'robust' for the moment) such as IBM bisync or RS-232 serial, you can treat a 'byte' as 10 bits, rule of thumb. It goes downhill from there - ethernet itself being *much* less b/w efficient than, for example, ARCnet/TCNS or even 100VG-Any-LAN, and TCP/IP less efficient on low-latency transmission paths than, for example SNA or even IPX/SPX. File-system overhead aside, 40% overhead is probably close for most TCP/IP over ethernet applications, so, yes - 50% overhead should be close. The Ethernet+TCP/IP payback, of course, is pretty decent soft-fault-tolerance and much easier 'universal' configuration than other optins - which is why most (around 100 alternatives) have faded from the scene. IF you happen to be testing between two fs locations (NFS exported or otherwise) that live on the same media, you can expect to encounter very large slowdowns from head-positioner thrashing. However, none of these seem to be related to the basic problem you have been reporting - don't be distracted by them. The real issue still seems to be an 'intermediate level' hardware, firmware, or driver glitch. The ifconfig up/down trick doesn't seem to make a difference at this point. NFS still locks up as well. (I just did a cat /dev/zero $NFS_MOUNTED_PATH/zero) and it (NFS) froze) Wish I had used dd instead... can't seem to CTRL-C the cat process now. :-/ Jamie (one presumes our cable-plant and any routers are in good shape?) Hmm What DOES happen if you aliase-up a second IP on your NIC and run 'hardware-less' test traffic that doesn't even leave the box? HTH, Bill
Re: Network Slowdowns?
Freddie Cash wrote: Odd, we do the exact opposite, replacing all non-3Com NICs we come across with 3Com NICs, for the exact same reason you do: to get something that we know works, and works reliably. :) No doubt in an all-3Com environment it should do .. For Windows, Linux, and FreeBSD, the only NICs that we found to work well are 3Com 3C905B and 3C905C series NICs. That could be a major differentiator - Windows, how it drives and configures NIC's, and what that requires of other players. After a score of years 'in the barrel' we are down to just 4 legacy WinBoxen + one W2K 'server', and those only on their own internal LAN (Dell with onboard Intel NIC's). Everything else is now *BSD, OS/2-eCS, or OS X. D-Link, NetGEAR, RealTek, even a lot of Intel chipsets have given us grief in the past. Since standardising on 3Com, we haven't had any problems. Now we just need to find a good, solid, GigE chipset. Have had mixed results over time with Intel, scrapping-out 2 different generations of them - but current Gig-E are rock-solid for us. Unless, of course one has a 3Com+Win environment to adapt to? - in which case, 3Com, of course... ;-) But I still maintain that the problem in the original post is addressed best and cheapest by a NIC swapout - and to a different 'race', 'coz that means a device driver change as well. IF THEN: - the problem persists = experimentation by others is warranted (could be a MB bus timing problem, for instance) - the problem goes away = driver-coders may be interested, but it is *probably* not a kernel issue. Could *still* be a system-board/bus hardware/timing issue. Best, Bill..
Re: Network Slowdowns?
Justin C. Sherrill wrote: On Sun, October 8, 2006 1:39 pm, Jonas Trollvik wrote: We *always* replace 3Com on general principal when encountered, and at our own (not client) expense. Not about right or wrong, its about what works *always* and what doesn't always work. Odd, we do the exact opposite, replacing all non-3Com NICs we come across with 3Com NICs, for the exact same reason you do: to get something that we know works, and works reliably. :) At a prior job I had, we'd buy large quantities of (mostly PCI) network cards and hand them out with cable modem installation, at probably the rate of 20-30 a week. We started with 3Com cards, and then switched to RealTek, because they were a third of the price, and (totally counter to my expectations) had half the Dead-On-Arrival rate of the 3Coms. The biggest Realtek issue was Windows driver quality. The RealTek are a bit like the old 'Timex' watches. The design was so crude they had no *right* to work at all! But they were cheap and cheerful (chipset cost reputedly one Hong Kong dollar, i.e under 13 cents US) - so - some very determined folks wrote drivers for them that worked around the problems quite well, and NIC's dropped from US$200+ to HK$ 100, then less. My watchmakers told me, BTW, that the reason the Timex could 'take a licking and keep on ticking' was that the mainspring used to power them more properly belonged in a wall-clock, and was powerful enough to drive sandy gears and corroded bearings that would have stopped a Rolex cols. So, too the original RealTek when backed-up by a powerful CPU and fast RAM. The Intel 3Com NICs of similar vintage, OTOH, were capable of being fully functional, doing low-level handshaking, and looking for / providing netboot even if the CPU was 'hors de combat'. Bill
Re: Network Slowdowns?
Jamie wrote: *SNIP* (all details already posted) (I use 3Com on all machines) Without digressing into decades of *why*, I can just about guarantee that replacing the offending card with almost-anything-else, from el-cheapo Realtek to Gig-E Intel, probable exception of anything-SiS, will cure the problem without further ado. Cost you perhaps US$ 10 to try that if you don't already have some other make of NIC handy. 3Com seem to fall into either 'solved all problems' or 'created a problem' extremes all too often. We *always* replace 3Com on general principal when encountered, and at our own (not client) expense. Not about right or wrong, its about what works *always* and what doesn't always work. The time saved the past dozen years has been more than worth the very modest cost of replacement NIC's. Life is too short etc. JM2CW Bill
Re: mailserver using dfbsd
Matthew Dillon wrote: :Hi, : :I'm going to install dragonflybsd on two mail server proxies: primary and secondary MX with milter-greylist on. :I need to share greylist data on both of them, I can do it using a dbms and I'll modify milter source code to store :such data in dbms instead RAM. : :Are there more efficient features on dfbsd to share (or exchange) such greylist data from primary and secondary host? : : :Best regards,\fer :-- :NonSoLoSoft - http://www.nonsolosoft.com/ I don't think you can safely update a dbms database file shared via NFS, if that's what you intend to do. What I recommend is that you simply make one machine the master and have a cron job on the secondary machinepull the greylist from the primary machine once an hour. Something like (in csh) (cron job script on secondary machine) #!/bin/csh rm -f greylist.new fetch -q -o greylist.new ftp://primary.machine/hidden-location-of-greylist (or http://) if ( $status == 0 ) then mv -f greylist.new greylist.db # be quiet if everything succeeded so no cron mail is generated else echo Secondary machine unable to pull greylist from primary machine endif -Matt Matthew Dillon [EMAIL PROTECTED] This really isn't a DragonFly-specific issue... But if greylisting is to work, it needs data updating capability at sub-one-minute intervals. Not that it matters. Many spam engines and zombies are programmed to defeat greylisting, unless already blocked by other means. As they should be. Most alternatives are more effective and don't need the overhead OR the DB of greylisting. Bill
Re: bmake not killing childrens (going way off-topic)
Martin P. Hellwig wrote: There are these times when things just go horribly wrong, yesterday my new boss (who barely touches a computer) saw me rebooting a old FBSD4 server and asked me what that devil was, ok after some explaining he more or less believed me. Now he came into my office and looked at my laptop which has this thread open and asked me who bmake was and why should he kill the children. He didn't waited for the explanation but I guess he thinks I'm sort of in a devil worship group which frequently sacrifice children, the good thing is that he avoided me the rest of the day so I finally finish my tasks :-) LOL! Somewhere I have (or *had*) base-six Forth code 'bark', and 'beer' that drove a 'Talking Clock' chip over 6 lines of a parallel port to make a computer literally 'bark like a dog', or ask 'Please bring the computer operator an ice cold beer'. Those got laughs. Sometimes even beer. Adding an audio amp chip to a recycled bass-reflex speaker that loudly shouted 'DUMB ASS!' on any stack-underflow error, OTOH, proved a mite embarrassing ;-) Bill
Re: bmake not killing childrens
Victor Balada Diaz wrote: Hi, some of you may have noticed that sometimes when you type Ctrl + C to stop bmake it doesn't stop. I find that behaviour annoying so i created this patch[1] to solve it. I find 'hard to stop' annoying enough in general to always have a second session open, uusally with 'top' in it... A 'kill -9 bmake's PID' or a 'killall bmake's executable name' - can cause just as much joy - or damage - without need of a patch to anything. And fits *almost all known* executables as well... (some modes of DJB's 'daemontools' are hard to find, but those aren't used by grownups anyway). ;-) This patch disables make compatibility mode, so some things WILL break. bmake unit tests is an example of this. So to install the new bmake you'll need to cp /usr/pkgsrc/devel/bmake/work/DragonFly/bmake to /usr/pkg/bin/bmake I've tried it compiling mule-ucs package and seems that bmake with the patch did his job fine, but it may break things, so use with caution. Also it would be great if someone who knows bmake internals could find a better and definitive solution. [1]: http://bsdes.net/~victor/dfbsd/bmake/main.c.patch
Re: bmake not killing childrens
Victor Balada Diaz wrote: On Sat, Sep 30, 2006 at 02:21:00AM +0800, Bill Hacker wrote: I find 'hard to stop' annoying enough in general to always have a second session open, uusally with 'top' in it... A 'kill -9 bmake's PID' or a 'killall bmake's executable name' - can cause just as much joy - or damage - without need of a patch to anything. Try that after doing bmake on /usr/pkgsrc. It does spawn various sh processes. Doing killall -9 sh is not very nice :P Then 'init 6' works well... ;-) Seriously, have you tried simply exiting the shell you invoked it from, or dropping that particular ssh session? Bill
Re: dragonfly wine
David Aubril wrote: Well, unfortunately, I am not a developper ; just a french teacher. I would have love to help, but this is way too far for me. Thanks for your answers, though. And what is it that you have discovered that the French are willing to be taught? ;-) Yury Tarasievich wrote: On 28/09/06, David Aubril [EMAIL PROTECTED] wrote: hi everyone. Well, yet another question. I have dragonfly running on a quite old pc, so I'm waiting for pkgsrc 2006Q3 to build anything, since it's going to take a couple of hours. Well, here is my question : I didn't see any wine binary package, on any of the ftp repositories. Is there a reason for that ? Does that mean that wine doesn't build on dragonfly ? It builds, with making the obvious patches in the sources, however, as Joerg says, it won't run, bailing out with some error in function mapper in ld-elf or whatever. I believe I still have the wine build-enabling patches around (against the wine sources month or so old), if somebody wants to play from there, welcome. ---
Re: How to disable the boot0 menu?
Matthew Dillon wrote: The boot0 menu is run from /boot/loader.rc. You can pretty much do whatever you want there... in the forth language :-) Forth is a lot more than just a 'language'. It is an inherently virtual-memory, dual-stack, virtual machine and the operating system to run it. An environment, IOW. One in which to *define* languages... FICL and predecessors came about 'coz it doesn't need much in the way of resources to do all these things. 12K to 20K for a Wysiwig WP, 32-64K for a full-blown ISAM BOM system. Given decent on-die cache, Forth needs little else to do quite a bit of useful stuff. It is also possible to bypass the forth loader entirely by modifying /boot.config (the boot2 config file). By default boot2 runs /boot/loader but you can give it a different command to run in /boot.config. I'm not entirely sure of the format, it might just be the path to the program to load and options, e.g. '/kernel', or it might not. If you screw up you might have to boot from the live CD to get back in and fix it. -Matt Or another partition, attached drive, CF or USB that can mount and edit the one you need to change. Easily fixed, and nothing to be overly fearful of. Bill
Re: Is fc-cache broken on -current?
walt wrote: Joerg Sonnenberger wrote: On Sun, Sep 24, 2006 at 03:05:44PM -0700, walt wrote: Can anyone confirm this error with the latest fontconfig from pkgsrc? # fc-cache -v /usr/pkg/xorg/lib/X11/fonts/TTF /usr/pkg/xorg/lib/X11/fonts/TTF: caching, 22 fonts, 0 dirs /usr/pkg/xorg/lib/X11/fonts/TTF: failed to write cache fc-cache: failed Works fine here. Can you delete all old font caches just to make sure that it doesn't try to reuse those? Bah. The problem was the old fontconfig config-files in /usr/pkg/etc. I noticed that the update announced that there were existing config files so they were not touched. The problem was that those config files should have been replaced during the update! Ordinarily NOT by the 'update'. But by the 'updater', .. with care to preserve whatever customization is still appropriate, if any. That's why the general rule is to produce a message and NOT over-write. Easy to get the new set that had been skipped spit-out again. Much harder to recover lost ones automatically, and silently, over-written. Bill
Re: boot problem, disk mess.. thinking of suicide.
Vladimir Mitiouchev wrote: 26 Sep 2006 10:49:11 GMT, Oliver Fromme [EMAIL PROTECTED]: And if you did, you should newfs(8) the file system when you replaced the cables with good ones. Q: Why fsck is not enough? Then re-install from your backup. DragonFly's journaling feature allows for nice live backup streams that can be stored on another media. ;-) That's too easy for me. Recovering system file by file and debugging problems give me much more pleasure :-) Live backup would be nice, but i have only 1 HDD. Last 3 months i've broken 5 HDD, that magic power in my fingers is extremely destructive. Or if you have a mirror (RAID1) setup, and the problem did not affect all mirror disks, then you can simply rebuild the failed component, of course. Im going to buy new computer, with some SCSI array :-) That would be nice possiblity to do some RAIDing. I've used RAID0 a few times, and 5 too, but on linux and IDE disks.. RAID0 is of no use save for speeding up video or such. The only thing 'redundant' about it is chances of losing data. RAID5 needs more HDD count and controller logic cost than can be justified with current HDD size reliability. RAID, BTW, is statistically less reliable than a single disk - it just *tolerates* or recovers from the fault(s) way better. KISS. Just put a matched pair of reasonably priced SATA or PATA up as RAID1 and be happy. Western Digital are running cooler than Maxtor, (ex) IBM-Hitachi are again safe to use. Seagate? Still competing with Midland and Kelsey-Hayes to corner the market on flywheels... Not an option for 24 X 7 X 365 X 5+ If you will ever need to remotely tear-down/rebuild them, where all you can ask of 'local' hands is a simple hardware device swap-out, then use either a very expensive 'hardware ATA RAID' controller (not justifiable, IMNSHO) or the dumbest ATA *non-RAID* controller, then atacontrol/gmirror or such. RAID1 write loading on modern CPU/glue/bus/controller is ridiculouslylow. It is nigh impossible to get full control over an alleged-RAID (3-Ware, Promise, High Point, Intel...) w/o hands-on physical presence at BIOS time. SCSI is a whole 'nuther story, but migrating nowadays to fiber Bill
Re: Is fc-cache broken on -current?
Jeremy C. Reed wrote: On Thu, 28 Sep 2006, Bill Hacker wrote: *snip* Ordinarily NOT by the 'update'. But by the 'updater', (person, not process...) On deinstallation of a package, the package's registered configurations are compared with the versions in the share/examples directory. If different, then it is removed. On a package installation, if the configuration does not exist, it will be copied into place from the (newly installed) share/examples version. All well and good, but what you have NOT mentioned is what has been done vs should have been done if the configuration DOES exist. whyzat ? In the case of fontconfig, the fonts.conf file should not be manually edited by the admin as the customizations should be in local.conf. OK - why then was the old fontconfig defaults? NOT removed or replaced? Reality doesn't seem to be following either my preferences or your 'should have' (standard?) here. Not a who is right/wrong issue to me. More one of expectations/predictability - and what is presently in the code Bill
Re: Is fc-cache broken on -current?
walt wrote: Jeremy C. Reed wrote: On Thu, 28 Sep 2006, Bill Hacker wrote: walt wrote: The problem was that those config files should have been replaced during the update! Ordinarily NOT by the 'update'. But by the 'updater', .. with care to preserve whatever customization... In the case of fontconfig, the fonts.conf file should not be manually edited by the admin as the customizations should be in local.conf. Right. 'fonts.conf' has a big banner at the top, cautioning the admin *not* to edit the file. The concept of a 'config' file which must not be edited is a bit bizarre, IMO. That sort of 'config' is done at compile-time (usually). This means that the fontconfig package *should* replace at least those 'do-not-edit' config files without asking. Despite the fact that I am personally a 'worst-case offender' and regularly say 'sod that, if it isn't to be altered it should be a binary' - and edit the core files rather than make chained exceptions - I do agree 100% that this should be the 'expectation'. *however* - if the fingerprint DOES NOT MATCH, I would still far rather have the installation/upgrade process throw a flag and leave it for manual action. Regardless of cause. It is just less 'damaging'. It may not be that the 'luser' has messed with it, but that it is not even from the same rev level or *architecture* (think FreeBSD 6.1 i386 vs 6.1 AMD-64 SMP - either of which will run on Intel Dual-core as well as AMD Only problem is an ancient one - those inlined warnings are almost always missed, even if you DO watch the screen - 'specially wityh fast systesm A broader 'fix' DFLY might be able to convey to the POSIX world is a way to separate-out such message types from the spew of '-WALL ' .. ACK... 'dream on, Bill'... Bill
Re: boot problem, disk mess.. thinking of suicide.
walt wrote: Bill Hacker wrote: ...IBM-Hitachi are again safe to use... Hearsay, or personal experience? Experience. We've had our share of 'Deathstar' - even tracked down one of the faults that IBM, AFAIK, never published. Expect to find an ash-pit about 0.020 inches in diameter in the same spot every time on one of the onboard IC's after a local PS power spike... Or HDD power cable handling sloppiness/crappy connectors, even... BUT - we have *also* had many IBM Hitachi 'Deskstar' run 24 X 7 for five+ years vs a 3 yr warranty. Seagate, OTOH, seems to have perfected the art of failing the day after the warranty expires (if one is lucky!). The much-publicized IBM problems were confined to the electronics (above) - used on many drives, but the electromechanicals and coatings problems applied to a far narrower range - most of which we missed owning. And they have been fixed anyway. At the moment, our preference for 3.5 IDE, in descending order is: - Western Digital (simply for lower power less heat) - Hitachi (cheap and cheerful) - Maxtor (decent performers, but *very hot*) And Hitachi (only) for SCSI. At least since CDC sold their bird-farm to Seagrate... OTOH, we have decided to buy no more 3.5 HDD *anyway*. 2.5 are now large enough, fast enough, and reasonably well priced enough to allow us to put the redundant arrays into 1U, and on less power, that we now need a 2U to hold, power, and cool. This isn't just 'green' awareness - there is a largish $$ jump in rack rental per UPS power budget 'chunk', and all our gear is upstream b/w-limited anyway, not HDD speed/capacity limited. Bill
Re: boot problem, disk mess.. thinking of suicide.
Justin C. Sherrill wrote: On Wed, September 27, 2006 3:53 pm, Bill Hacker wrote: OTOH, we have decided to buy no more 3.5 HDD *anyway*. 2.5 are now large enough, fast enough, and reasonably well priced enough to allow us to put the redundant arrays into 1U, and on less power, that we now need a 2U to hold, power, and cool. This isn't just 'green' awareness - there is a largish $$ jump in rack rental per UPS power budget 'chunk', and all our gear is upstream b/w-limited anyway, not HDD speed/capacity limited. Along the same lines, I'm looking forward to the point where RAM is cheap enough that you can create a multi-gigabyte disk from it. If there's a battery backup, it'd be a darn fast/cool/light 'disk'. Hitachi, I think it is, has 32G of flash available now. There is a totally new (at silicon level) magnetic? phase-change? RAM just coming out of the labs and going into sampling. It has a longer write-cycle life than any current flash, and smaller cell size, IIRC. *Meanwhile* - my first personal HDD was a 5MB (mega, not giga), Rodime, and I used 256 KB (kilo, not mega) RAMdisk on S-100 medical lab gear, 2 MB 'JRAM' on my 386, so I have long been in the never-ending RAM-vs-HDD cycle. If apps and file storage formats would just stop bloating, and a good 'projection' or direct-to-brain display come along, we could do all we need with wristwatches. And networked DFLY back to 'mothership' servers. Meanwhile, I vote for acquiring a pleasant 'partner' with a nice personality, giving *them* a computer and a cell phone to call you at the golf course of pub when a decision is needed. ..Worked well for leaders of nations and industry even before cell phones. OTOH, no computer I have ever worked with ever sued for 'palimony', quit to become a fulltime housewife, or got pregnant, (though some seem to have shown signs of PMS). ..so maybe we *are* better-off than Andrew Carnegie or Ivan the Terrible. Bill
Re: How to disable the boot0 menu?
Justin C. Sherrill wrote: On Tue, September 26, 2006 2:59 pm, Thomas Schlesinger wrote: I there a way to disable the appearance of the boot0 menu completely? 'fdisk -B ad0' or maybe 'boot0cfg -B -b /boot/mbr' or maybe If you have a Windows boot floppy, boot from that and type 'fdisk /mbr'. I have not tried any of these recently, so it may mangle your entire drive... Showing my age, roots, or something no longer in vogue Finding the binary and replacing it with the op-code for a 'noop', 'return' or 'jump' (to the next module) used to work wonders... S'pose these days they are hash fingerprinted or such tho'... And I've long since given up memorizing op codes... 'Too many architetcures, too little time.' Bill
Re: Bridging again
Gergo Szakal wrote: Followed the advice here: http://leaf.dragonflybsd.org/mailarchive/users/2006-05/msg00148.html and tried to pass thru the traffic of the whole dormitory but it does not seem to pass packets (even with PF disabled). With OpenBSD 3.8, I have done the same (/etc/bridgename.bridge0 and same PF configfile) and it works fine, bu I would like to run DragonFly. :-) Can somebody recommend diagnostic steps or give me some hints? Thanks, and sorry for bothering. ;-) If you are going to pass *all* the traffic, what is wrong with a bit of CAT5 and a dumb hub? ;-) (ducks and waddles off a few meters...) OK - do you mean to: - route, NAT, DHCP share a connection for (all those folks)? - firewall/filter for them? - proxy some service(s)? - electronically vampire-tap their traffic? Or what? FWIW, a 'bridging' arrangement is often one of the hardest-working ways to do several of these things for the value-add, so is 'bridging' really what you need? i.e. - what is the intended service? YMMV Bill
Re: boot problem, disk mess.. thinking of suicide.
Vladimir Mitiouchev wrote: *snip* PS2 Thanks God i wasn't running softupdates! Muhh... don't be too sure... 'Softupdates' have saved me far more grief than they have ever contributed to. Lot's of folk misunderstand what they do - and how quickly they can post if all the kit is properly configured. SCSI hardware RAID1 with write-through cache settings is the most bullet-proof, but atacontrol or gmirror software RAID1 on dumb PATA/SATA IDE are decent too. My PowerBook is the only machine I have that does not have RAID. Either way, make your own cables from top-quality connectors and wire or buy the best you can find [1] That cheap cable just cost you 6+ hours of life that no amount of money can ever buy back for you, and you aren't yet fully back to 'normal'. ;-) Bill [1] One of the Apollo astronauts, asked how he felt about the launch, replied with words to the effect: How would *you* feel sitting atop all those billions of dollars worth of equipment, and knowing that every last nut and bolt of it had been supplied by the lowest bidder?
Re: EuroBSDCon registration Open
Massimiliano Stucchi wrote: Hi all, we finally made it, the registration for EuroBSDCon 2006 - Milan is now open to everybody. Please register as soon as possible to ensure a seat for you at the event ! go to http://www.eurobsdcon.org/register/ and complete the registration process. It is also possible to book a room for the conference hotel. We hope to meet you all in Milan ! Ciao IIRC, cars need special permits to be in the inner city? Suggest not missing a climb to the roof of the Duomo di Milano (pressure breathing recommended for climbing the stairs). And, cars aside, if you can, stay well out of town or at least visit. Lugano, CH or Lago d'Iseo, IT. Both within 45 minutes to an hour: http://www.lagoiseo.it/hotel_del_lago_d_iseo.htm Hotel Albergo 'Miranda' has a great view Bill
Re: Hints on kernel config for a dula pII/450 system anyone?
Gergo Szakal wrote: Bill Hacker wrote: We've all been (still are) there w/r the economics. But when funds are needed elsewhere, and 'run what hardware you have' is mandatory, then DFLY would not be the best choice. For that to change sooner, rather than someday-maybe, best to leave the 'scarce resource' DFLY dev team to concentrate on current, reasonably-mainstream hardware. Hard enough to keep up with 5-week/month-old goods, let alone 5+ *years* old. While completely sharing your point, my opinion is that testing DF on older (or any x86) hardware may help catching bugs that are otherwise hidden. :-) It can do. Sometimes. Unfortunately it is very much a 'dimishing returns' exercise, as your experience is proving. First, it requires too much work, as the hardware already has 'minority' presence, and too few players have direct access to something on which to test. Secondly, the problem if/as/when solved at all is frequently related to an environment that was uncommon even when new, and has already left the 'majority' scene, so even a correct result is of limited value. Basically, it is too much work for too little gain - even on, for example, a 'populist' platform, such as Linux, where lots of older hardware abounds, simply because of the size and diversity of the user community. 'Production Server' operators - a majority of *BSD'ers, go without lots of life's niceties - meals included from time to time - to keep reasonably modern and solid hardware online. Not necessarily 'sexy' - but predictable. Odd-designs and 'minority' gear that proves problematic are more likely to be reassigned to less critical use or even scrapped outright than 'accomodated' with kludges. Time is the one thing we cannot 'buy back'. It needs to be invested where it does the most good for the least effort. PII-450 or K62-450 'clones' on dual-CPU MB with rare NIC's are no longer such a target. If ever they were. If there is *really* a code error, it will show up on modern hardware as well as ancient. But here the work toward a solution can proceed more easily, as the hardware is less likely to be unique. Bill
Re: Hints on kernel config for a dula pII/450 system anyone?
Gergo Szakal wrote: Bill Hacker wrote: *BSD folk, unlike Penguins, are generally agnostic. Use whatever is the best 'fit for the purpose'. Using only 1 processor is not enough. An AMD K62/450 is not enough for the amount of traffic going through. theoretically, DF *should* run on this flawlessly, that's why I even bothered reporting (and mde thers bother too :-P). Therein lies justification for (perhaps), a mere Intel Dual-Core 3 GHz at 'remaindered' just-obsoleted silicon prices. Cheaper than latest' Intel and AMD-64. I wanted to avoid polluting the group with personal stuff, but machines of this category are not options now. In the future I'll summarize all this crap, translate to English and post somewhere to terrify people. :-))) We've all been (still are) there w/r the economics. But when funds are needed elsewhere, and 'run what hardware you have' is mandatory, then DFLY would not be the best choice. For that to change sooner, rather than someday-maybe, best to leave the 'scarce resource' DFLY dev team to concentrate on current, reasonably-mainstream hardware. Hard enough to keep up with 5-week/month-old goods, let alone 5+ *years* old. Bill
Re: shutdown on BSD and Linux
Rahul Siddharthan wrote: I've long had a question on the shutdown process. Linux systems run a separate shutdown script for every process that was started at boot, and can take a minute or two to shutdown. FreeBSD and Dragonfly, as far as I can tell, just kill all processes, flush buffers, unmount filesystems and shutdown/poweroff, which takes about 5 seconds. It may be faster on *BSD, but no more 'rude', at least with shutdown now. Each process is asked politely to terminate - per the information in ~/etc/rc and ~/etc/rc.d Only if they dally do they get a firmer reproach. Init 6 is *slightly* less forgiving, it goes directly to *dammit, I mean NOW* mode. No daemon I have run in the last 6+ years was ever bothered by that. OTOH, we use softupdates, RAID1, and forced '-y' not 'p' fscking at boot-time... So what's up? Is BSD-style shutdown dangerous, - not in the least! or are the Linux people stupid? Surely you didn't even need to *ask* that in the face of massive evidence? More 'gently' - *BSD has always been far more coherent, hence more efficient at managing resources. It is also less frequently asked to do dumb Microsoftish-things than Linux. The question came to my mind again when I saw Ubuntu's specification for shutdown in their future versions: https://wiki.ubuntu.com/Teardown Basically, it says the majority of init scripts needn't be called at shutdown because the processes can just be sent signals and trusted to do the right thing. However, some controlled shutdowns *do* need to be done. Why can the BSDs get away with not doing these controlled shutdowns? Because the *BSD's are complete *Operating Systems* - with a very long history of refinement as well as imrovement. Linux is not an Operatign System, and has a shorter, and spottier, history - one with far less strictness in QC. Linux is a 'kernel', hooked - more or less successfully - to a diverse collection of 'GNU' kit that makes it possible to *emulate* an operating system. Thus the 300+ 'distros' out there in Penguin-land. A *BSD variant is NOT a 'distro'. It is developed and tested as a whole-cloth exercise. Th core components are know in advance, and tested together. Think of *BSD as the refined 'whole system' characteristic of a Mercedes - auto or truck. Linux, by comparison, is any of a brazillion varieties of garage-built hot-rod - motorcycle to 'bigfoot' pickup truck - kitted together out of whatever bits of kit the 'distro' packagers happens to hold in high regard. Obviously, some 'garages' are bigger, better funded, and more competant than others. That doesn't mean you can't put together a very good Linux, managed by an expert operator. It DOES mean that there is an element of chance. Distro's aside, Linux' Kernel is nothing to write home about, either, so it is starting off handicapped. But it is free and available, and 'has lots of drivers...' so... BTW - the poweroff on my laptop, with Dragonfly and FreeBSD (last I checked), is also accompanied by a rather alarming and short-lived whine, as if a spinning disk or fan was suddenly stopped. I don't get this sound with linux or windows. Rahul Sounds more like a CPU-fan or HDD spun UP, not down, as needed in a burst of intensive activity (putting stuff away properly before shutdown..) Bill
Re: users as blobs
Jeremy C. Reed wrote: By contrast, *n*x is often irritating in that one can be sitting in the same dir as a given binary, but if it is not on the PATH, still have to prepend at least a './' - if not the entire path - in order to invoke said binary. Even CP/M or DOS ain't *that* picky! Append . to your PATH. (Search about security issues with dot in the execution path. Make some trojan tools with common typos and misspellings as filenames and wait for a superuser to make a typo while in the directory you put the file. And never put the dot early in your PATH.) Thanks for reminding me why I *don't*.. (put the '.' in the path...) ;-) But I stand on the convenience of path-independent local-first local-subtree search, per ancient Netware. That can also make it *very* easy for an app to insyall cleanly, and/or keep its dependencies modules aloof from other rev-levels, libs, etc. Bill
Re: users as blobs
Markus Hitter wrote: Am 04.09.2006 um 00:16 schrieb walt: Are you thinking about, say, pointers to my real blob which exists on one physical server, or actually migrating blob-walt to anywhere I'm actually needed? (Most likely to unplug the sink or the toilet.) This could be something like a mirrored RAID, but over the network. Do a network mount of the /home/bob partition, then, as you work with it, files are copied to a local drive and things start to become faster. Similar to how you'd recover from a drive failure in a two disk RAID. Such a network-RAID would be a great solution for people partly working on a laptop elsewhere and partly working on the own desktop as well, but I couldn't find a piece of software supporting such a strategy so far. Markus Not new. Aside from RAID NAS, even ancient smbfs could handle that - with Warp, anyway. - Find oneself short of local HDD space. - drag an entire app folder or dirtree off my box and drop it into spare space on a drive 'mapped' from another Warp box. - 'alias' icons still open and run the apps, just a bit slower on 100 BT. Gig-E? Probably close to same as ATA speed. (The same stunt would break MS shortcut links. Worse, the dependencies might not be found...). - finish the local cleanup/new disk, drag the dirtree/folder back onto my own box. - 'alias' icons still work, but faster again. Same with a whole user 'tree'. SOM. The 'System Object Model' - the OS/2 DB that tracks paths, settings, dependencies, etc. Auto updated by drag'n drop, but NOT by CLI manual moves. User as a 'BLOB'? M.. more like 'pointers to the app/user's resources' So the concept is well-proven - aside from the issue of OS/2 never doing an automated 'pack' on those DB files... a sorely needed feature. The *BSD's have the 'locate' DB, 'whereis', et al - but do not (ordinarily) automagically use them to override/augment/alter the path during such moves. Clustering and such entirely aside, DFLY might be able to improve on that. To Wit: Long ago and far away... The Novell Netware default was to first search for config files, overlays, modules, and such in the same directory the code that needed them was operating from. If not found, Netware would traverse down all the subdirs from that point - even if NONE of these were in/on the 'PATH'. As is was/is not unreasonable to expect an app to keep all it bits stuff under its own dir, that worked really well. Only when those steps failed did Netware search the PATH. We kept paths simple by calling all apps from a script that began with a 'cd' to wherever the app lived, invoked the app, and did a 'cd' back to where the menus lived on exit. HAd to. PATH environment was too small to cover 'em all. Crude and rude, but effective. By contrast, *n*x is often irritating in that one can be sitting in the same dir as a given binary, but if it is not on the PATH, still have to prepend at least a './' - if not the entire path - in order to invoke said binary. Even CP/M or DOS ain't *that* picky! May be something there for down the road. Bill
Re: The future of NetBSD by Charles M. Hannum
Jonathon McKitrick wrote: I'm starting to imagine the size of the Lisp image I could run on a cluster like the kind being discussed ;-) Jonathon McKitrick -- My other computer is your Windows box. Go and wath out your mouth with thoap! ;-) Bill
Re: The future of NetBSD by Charles M. Hannum
at the moment. 'On-the-fly', automatic, totally transparent to the user, 'visible', but not 'limiting' to the sysop. More like 'roaming' than clustering. We expect it of cellphones. We expect it of browsers - particularly search engines. DFLY could be a better platform for many of these things than what is out there now. And it is a huge and growing market. That's what it is good for, IMNSHO. YOMD, Bill Hacker Note that
Re: DF-BSD on apple hardware
lap wrote: Justin C. Sherrill a écrit : *snip* (Your return email is a bad address, by the way.) Yes I know, I get bored of being spammed. If you are not running windows, you can send mail to me at laurent (at sign) chez (minus sign) le (minus sign) sourd dot name . :) LaP Cuts both ways. Mailing list assistance aside, you probably can't send mail direclty *to* some of us, either. Try me direct on: [EMAIL PROTECTED] Will copy you the logs if you like... (Exim on FreeBSD 6.1 AMD-64 SMP now, on DFLY ... someday...) Bill
Re: question about sendmail
Saverio Iacovelli wrote: After the installation, DFly OS have got a active sendmail server. 1) Does it need to configure a DNS server for sending email with mail client and sendmail? Sendmail (any MTA) will ordinarily follow the internet 'food chain' to find a DNS. You need not run one locally, though a properly implemented one may speed-up the smtp process. 2) Can sendmail works in indipendent way from DNS server? An MTA (Exim, anyway... no longer 'current' with sendmail here) can be set up to do 'local' (on-box) delivery, and 'nearby' private servers such as needed for chron'ed reports, by relying just on the ~etc/hosts file entries and to the 'net at large with 'domain literals', ie: a validuser@some valid IP - which may be all you need for LAN or 'private' testing w/o risk of polluting the 'net, and is the only way to reach boxen that have no published domain.tld. A DNS query is not used just for routing outbound, but also for verification of incoming in a number of places in 'aware' MTA's - Exim especially. In general: ~/etc/rc.conf needs a defaultrouter entry ~/etc/hosts must at least not 'short-circuit' the routing ~/etc/resolv.conf must have a useful way of finding one or more nameservers. manpages have more detail . HTH, Bill
Re: System downtime wednesday for maintainance.
Peter Avalos wrote: On Thu, Aug 17, 2006 at 04:41:00PM +0800, W B Hacker wrote: Have you noticed any electrolytic capacitors - probably in VR section - with slightly bulged tops? Some of those have taken a *long* time to work thru the system and fail - long after the 'big wave' has largely passed from memory. Or maybe it's a new round of bad electrolyte Bill I had a similar problem a few weeks ago. I referenced this site: http://www.badcaps.net/ --Peter That site does note that the problem has not gone away. But part of it may not be bad electrolyte. Simply that designers and component logisticians are not as conservative as to de-rating electrolytic caps subject to high ripple and high temperature as they once were. And/or that makers are too confident in their ratings.. *ALL* electrolytic caps have a finite life, though most will outlast the MB they are installed in for obsolesence reasons. IF it is run cool and under 'consumer' workload Unlike the plain-Jane borax and water B+ filter caps in my 1938 Sparks-Withington all-band receiver .. When upgrading from a 5Y3 to a 5U4 then to a 5R4 rectifier tube still left the plates glowing a dull red and added the smell of transformer windings melting their varnish, it was time to 'recap'... ;-) When the original 180 MHz PentiumPro was still a 'hot' item, I had a pair of HK$ 10,000+ per-each dual PPro PCMCIA SBC's fry their entire VR sections... :-( Bill
Re: Not sure how to do this tricky install...
Jonathon McKitrick wrote: I'm sure this isn't difficult, it's just a little more complex than I've done, and I need the DFly specific way. I have a spare box I want to use for DFLy as a server. It will be totally headless. It will plug into a home broadband gateway/router, and should be accessible by other machines on the same router. The tricky part is since this machine is not the gateway/router, how do I set it up to be accessible from other machines on the network? Is it as simple as /etc/hosts? In any case, is it possible to start the install with a keyboard, but then move to another machine and ssh in to finish? Jonathon McKitrick -- My other computer is your Windows box. Presuming 'headless' means there is not now, or may not in future, even be a graphics adaptor present, my way is to install a very generic kernel to a storage device (HDD, CF, whatever..) using a machine that DOES have a VGA, CRT, keyboard. Set up /etc/rc.conf, assigning DHCP or fixed IP, set up /etc/hosts, /etc/resolv.conf, *set a root password*, *add at least one wheel account*, insure you can ssh in, test everything, etc. THEN: - edit /etc/ttys and enable at least one serial console: ttyd0 /usr/libexec/getty std.9600 dialup on insecure We globally change all 'secure' to 'insecure' at the same time. boot -s will need the root pw. Keeps remote site-techs honest. - creat /boot.config with -P, or if *never* to be keyboard or VGA -h. Make sure all this works through a reboot or three. Shutdown, move the storage device to your 'headless' SBC or MB. - optionally attach a serial terminal (I use an HP-200-LX) or null-modem cable to the serial port on another PC or laptop. - ELSE just boot it, try pinging it, ssh in a few seconds after pings start being returned. You may then use ssh to build a custom kernel, etc. Our rackmount servers typically go their entire lives this way, with MB changes HDD replacement, OS upgrades, etc. HTH, Bill Hacker
Re: Not sure how to do this tricky install...
Chris Csanady wrote: This is only somewhat related, but would it be possible to have the getty on ttyd0 enabled by default, at least for the install cd? I haven't tried to log into the installer account over the network, but this does sound like the best option if you have a dhcp server in place. If you do this though, don't forget to configure PermitRootLogin to yes in /etc/sshd_config before you reboot, otherwise you will be locked out of the machine before you can finish configuring it. Chris *Much* safer to deny direct root login (from anywhere) and install a wheel user that can su. That could be a default account (installer), but a locally-seelcted name is much more secure than anything well-known. The old *BSD 'amnesiac' root default is devastatingly insecure with the present level of massive automated root attempts sloshing about the 'net. Bill
Re: Default PATH in login.conf
Francois Tigeot wrote: Hi, I have been bitten by a PATH issue when trying to configure a remote X terminal. The default PATH in /etc/login.conf includes /usr/X11R6/bin and not /usr/pkg/xorg/bin Shouldn't this be updated to reflect the new pkgsrc installation directories ? Should not *both* be removed unless/until one of those suicide-kits is actually installed? '~/games' as well, while we are cleaning up old mistakes. Bill Hacker
Re: Asynchronous Console Messages?
Ben Cadieux wrote: Hi everyone, I've always been a little curious about the way the typical unix console works. Why is it that applications must wait for text to be displayed on the console before continuing operation? Shouldn't these messages merely enter into a queue to be displayed whenever the system can get to them instead of slowing things down to the maximum speed they can be output? Perhaps I'm mistaken about this issue :) -- and I'm certain that if I'm not there's a reason for it working the way it does. I wouldn't mind knowing the reason, though! Best Regards, Ben Cadieux Historically, the Unix 'console' was most often a DEC Writer, ASR-3X TTY, or 'glass teletype' (ADM-3, SOROQ IQ-120, Televideo 9XX, scads of others) 'dumb' serial terminal - and these, or modern equivalents, are still supported. In our case, we use a few carefully preserved HP-200LX - easy to carry on interncontintal flights, pass though customs in paranoid countries, and usable as 130-column VT-XX terminals - with special eyeglasses.. ;-) Awaiting a hardware or software handshake (RTS/CTS, ACK/NACK, etc) OTOH, is NOT ordinarily required, and a default VGA or other 'virtual' consle doesn't necessarily even have the concept (where you can adjust it, anyway). For the most part, the initiation activities reported to the 'console' are, in fact, already being 'buffered' or otherwise free-running with respect to the underlying progress of the activity being reported. Ordinarily, these are neither constrained by the speed of the I/O device, nor stalled awaiting handshake or response - though such may be provided for, and can be useful in certain types of troubleshooting. The 'delays' are far more often those required by dependencies and sub, and sub-sub dependencies - most, but not all, of which are also reported. IOW - they won't change, regardless of the bahaviour of the console, or if it is beong pipeld to, for example, /var/log/all or /var/log/console.log instead of/as well as a console I/O animal. A few examples: - There are a great many things that must complete before a Unix system is able to leave the 'single user' mode it uses for booting and enter 'multiuser'. Mounting (or not) whatever is in ~/etc/fstab among the most obvious. - *many* of the other 'basics', such as bringing up a NIC, testing that there is a cable and a working TCP/IP connection, finding the gateway and DNS servers, etc. - must run to sucessful full/partial completion, ELSE time-out before other services will attempt to start. SSHD, for example, ordinarily implies 'multiuser' mode, AND must have a means of communication if it is to be of any use. - *most* applications require that their storage be available, so fsck'ing a large HDD can delay most anything that either lives on a given resource, or calls other applications/libraries that do so. We start massive RAID arrays separately from ~/etc/fstab in ~/etc/rc.d scripts, so as to get a server into an ssh-capable state more rapidly after a reboot - even if this means soem of its public-facing services are NOT yet available. - So too with applications that relay on other applications as prerequisites. A couple of easy ways to satisfy your curiosity on these include: - entering a non-available mount into ~/etc/fstab (thereby stalling in single-user mode, incapable of running ssh, so do this on a box you can 'reach' physically, not a remote one!) - disconnecting the CAT5 ethernet cable during bootup, and connecting it much later. Some services will find it 'late' and initialize, others will not. - specifying an unreachable network time server, thereby creating a failrly long time-out. In some cases, you can enter a Ctrl-C when the relevant message appears and proceed more quickly - the daemon may or may not initialize later, and you may or may not proceed sucessfully to a multi-user runlevel. Note that the Ctrl-C is not removing a console delay. It is aborting the attempt to start that particular process. Most of this behaviour is configurable in one or more places, preferably with overrides in boot, loader, or - of course - rc.conf and the content and sequencing of ~/etc/rc.d scripts. HTH, Bill Hacker
Re: disk diagnostics
Pieter Dumon wrote: On 7/26/06, Bill Hacker [EMAIL PROTECTED] wrote: complete in *seconds* what you are reporting in *minutes*. that's what I thought too. Something just has to be wrong with your set up. yep, and I'd like to find out what. Below are some logs. Pieter *SNIP* time rm -rf world_i386 0.070u 0.476s 20:11.87 0.0% 313+264k 7+54102io 0pf+0w The time utility executes and times the specified utility. After the utility finishes, time writes to the standard error stream, (in seconds): the total time elapsed, the time used to execute the utility process and the time consumed by system overhead. (not necessarily in that order?) Am I wrong in interpreting that said act took 7 1/100's of a second of CPU time for itself, needed just under half a second of system overhead, but needed 20+ minutes end-to-end to complete by the wall-clock? 'To be determined' if it was awaiting I/O, or if something else was denying it a place to sit down and eat its hamburger. What do you see on untarring the DFLY iso? Bill
Re: disk diagnostics
Pieter Dumon wrote: Wow, not too fast. I don't have access to my machine right now (I'm at work), so I will post detailed stats later (timed rm, top output, ...) - no servers (web,mail,smb,) are running - no other users present - no cron jobs or other daemons or other processes apart from the standard system processes and X+KDM running. Ummmhhh.. you are doing a make buildworld, ..kernel,...install... cycle in multiuser mode via X+KDM? - disk room enough for what I'm trying to do, only HDD access to that HDD needed. - it's an AMD Sempron 3100+, with Dragonfly on the old disk How much memory? How many swap areas, and how large each? - the 25 minutes was a subjective quantification. But it's O(10min). - DFly-preview 1.5.4, but got the same problem with older versions - I did not want to say it is a bug in DFly, no far from that, it just should be some hardware problem or a configuration issue or something stupid. I'll refrain from calling X+any WM 'stupid' for an OS make/install cycle, but only out of incredulity. There's one hog that should be shut down in favor of a simple (ssh-ed) CLI when doing resource-intensive make/build/install work. *Especially so* if it has a filemanager view window open and is trying to keep it current and sorted. If I remember well, the rm process is spending a lot of time in the IOWAIT status, but I'm not sure anymore. So, wait for more info to come later. OK. Please copy us a 'df' or three as well, just to make sure. Thanks, Bill thanks already, Pieter On 7/26/06, Bill Hacker [EMAIL PROTECTED] wrote: Simon 'corecode' Schubert wrote: Bill Hacker wrote: Warren Hull 25 minutes delay comes in, and I/O tuning doesn't cover that. Too big a number for where it is being reported as happening. Either something else - probably something *basic* but simply overlooked - is placing demands on that storage system, or the 'problem' has been misreported. softupdates? writing meta data with sync will be really slow. cheers simon No, not *that* slow, not even on K6-2-500 with 256 MB of SDRAM, where I have done it on a production FreeBSD 4.8 web mx box for donkey's years (too small to hold a RAID). DFLY may not have focused on that area, but should not be 2 or 3 orders of magnitude slower than 4.9/4.9 BSD. Especially not that slow on a scripted dirtree rm -Rf I'd want to see what is in the ~/messages and other logs, (rampant I/O errors?), what, if anything was mounted from the CD's, where mounted, and what the path was at the time - likewise RAMDISK and if df showed one or more mounts at/near/over 100%+ of capacity, memory and swap stats etc. The 'usual suspects'. The time involved hints at CD's being spun up, paths searched, found not to contain whatever, rewind or some partition being pushed over 100% temporarily. Folsks cramming multiple OS test installs onto media all too rarely pay attention to temporary needs. The 8+ GB needed for building OpenOffice from source caught even this old dog flatfooted, for example. Otherwise, ATA I/O is too 'universal' in use to hide a DFLY bug of such magnitude for very long, so the paucity of related reports says it is a local 'headspace' issue... Bill
Re: disk diagnostics
Joerg Sonnenberger wrote: On Wed, Jul 26, 2006 at 08:06:57AM +0800, Bill Hacker wrote: softupdates? writing meta data with sync will be really slow. No, not *that* slow, not even on K6-2-500 with 256 MB of SDRAM, where I have done it on a production FreeBSD 4.8 web mx box for donkey's years (too small to hold a RAID). DFLY may not have focused on that area, but should not be 2 or 3 orders of magnitude slower than 4.9/4.9 BSD. I see typical disk troughput of 500-1000 transactions/second under load. Let's assume 500 tps for now. Over 25min, that's 750k transactions. The DragonFly tree alone has 42k inodes and the removal of a file needs at least three IO transactions in sync mode (unlink from directory, update of reference count in the inode, update of the block bitmap), resulting in at least 120k transaction. Giving the low queuing and high seeking, utilising a fourth part of the disk transaction rate doesn't sound that bad. In fact, the result seems very likely when looking at the very file systems comparisions. Joerg I'll bow to your superior knowledge of the innards of DFLY and go run a couple of tests for comparison... Bill
Re: disk diagnostics
Bill Hacker wrote: *SNIP* *Especially so* if it has a filemanager view window open and is trying to keep it current and sorted. Also - are you perchance logging the progress and/or appending to a file? Bill
Re: Fwd: disk diagnostics
Pieter Dumon wrote: *snip* ... I get the same problem for instance when untarring an archive of some tens of MB: it takes ages. I haven't had a DragonFly install active for over a year, but using a tarball we all have access to - the 98.5 MB DFLY 1.6 iso, I get: === 2U server: time tar xfz dfly-1.6.0_REL.iso.gz 4.896u 2.366s 0:22.07 32.8% 75+3681k 411+1316io 0pf+0w DreeBSD 6.1 AMD-64, 3 GHz Pentium-D Dual-Core with 2 GB DDR Mount was on twin IBM/Hitachi 80 GB PATA UDMA 133 HDD, gmirror software RAID1 Not sure if it matters for an I/O speed test, but the AMD-64 toolset gives me *many* error messages of the general form: Unsupported RRIP extension for 56 PN(16): 16 00 00 00 00 00 00 16 38 00 00 00 00 00 00 38 === 1U Server: time tar xfz dfly-1.6.0_REL.iso.gz real0m20.255s user0m17.747s sys 0m2.363s FreeBSD 4.11-STABLE, 2000+ VIA C3 Samuel 2 (796.10-MHz clock) 1 GB DDR Mount was on twin IBM 60 GB UDMA 100 HDD, atacontrol software RAID1 === Software RAID1 on obsolescent drives such as these is nowhere near 'bleeding edge', so DragonFly on your hardware should be comparable, if not better - eg complete in *seconds* what you are reporting in *minutes*. Something just has to be wrong with your set up. HTH, Bill
Re: disk diagnostics
Pieter Dumon wrote: Hi, how can I diagnose my disk read/write throughput under DFLy ? my system runs well except that untarring even small tar files or deleting files takes a lot of time (e.g. the removal of /usr/obj/usr/src/world_i386 during a make buildworld takes about 25 minutes (I admit it's got a lot of files, but still)). I don't know if it can have anything to do with my strange configuration of having the two harddisks on ATA1 while the CDs are on ATA0. The disk with the DFly slice is only UDMA33 (there are no DFLy slices on the other disk), but still, under windows and linux I don't have this slow disk access. ad2: 28629MB ST330621A [58168/16/63] at ata1-master UDMA33 ad3: 76319MB WDC WD800BB-00JHC0 [155061/16/63] at ata1-slave UDMA100 acd0: DVD-R AOPEN DUW1608/ARR at ata0-master PIO4 acd1: CDROM CD-ROM 36X/AKU at ata0-slave PIO4 regards, Pieter Agree that is not an optimal set up - faster IDE drives uusally fare best on 80-pin cable to ad0 (master) and ad2 (master) with CD's as slaves, or better yet, on a PCI-bus add-on controller so there is no master/slave speed difference. But neither should it take 25 minutes to do the removal. Perchance, is something *else* running at the same time (what is in 'top'?) Or is extensive other activity hitting the same device/slice/partition as that being rm'ed? (head thrashing...) Or - perchance is a background fsck running on another part of the media you are trying to utilize? Bill
Re: disk diagnostics
Freddie Cash wrote: On Tue, July 25, 2006 12:34 pm, Bill Hacker wrote: Pieter Dumon wrote: how can I diagnose my disk read/write throughput under DFLy ? my system runs well except that untarring even small tar files or deleting files takes a lot of time (e.g. the removal of /usr/obj/usr/src/world_i386 during a make buildworld takes about 25 minutes (I admit it's got a lot of files, but still)). I don't know if it can have anything to do with my strange configuration of having the two harddisks on ATA1 while the CDs are on ATA0. The disk with the DFly slice is only UDMA33 (there are no DFLy slices on the other disk), but still, under windows and linux I don't have this slow disk access. ad2: 28629MB ST330621A [58168/16/63] at ata1-master UDMA33 ad3: 76319MB WDC WD800BB-00JHC0 [155061/16/63] at ata1-slave UDMA100 acd0: DVD-R AOPEN DUW1608/ARR at ata0-master PIO4 acd1: CDROM CD-ROM 36X/AKU at ata0-slave PIO4 Agree that is not an optimal set up - faster IDE drives uusally fare best on 80-pin cable to ad0 (master) and ad2 (master) with CD's as slaves, or better yet, on a PCI-bus add-on controller so there is no master/slave speed difference. It really depends on *snip* (lots of stuff that no way adds up to 25 minutes, and probably not 25 seconds, either...) Let's not start. I still have ISS-80 parts on-hand. The issue is finding Warren Hull. Warren Hull 25 minutes delay comes in, and I/O tuning doesn't cover that. Too big a number for where it is being reported as happening. Either something else - probably something *basic* but simply overlooked - is placing demands on that storage system, or the 'problem' has been misreported. Bill
Re: disk diagnostics
Simon 'corecode' Schubert wrote: Bill Hacker wrote: Warren Hull 25 minutes delay comes in, and I/O tuning doesn't cover that. Too big a number for where it is being reported as happening. Either something else - probably something *basic* but simply overlooked - is placing demands on that storage system, or the 'problem' has been misreported. softupdates? writing meta data with sync will be really slow. cheers simon No, not *that* slow, not even on K6-2-500 with 256 MB of SDRAM, where I have done it on a production FreeBSD 4.8 web mx box for donkey's years (too small to hold a RAID). DFLY may not have focused on that area, but should not be 2 or 3 orders of magnitude slower than 4.9/4.9 BSD. Especially not that slow on a scripted dirtree rm -Rf I'd want to see what is in the ~/messages and other logs, (rampant I/O errors?), what, if anything was mounted from the CD's, where mounted, and what the path was at the time - likewise RAMDISK and if df showed one or more mounts at/near/over 100%+ of capacity, memory and swap stats etc. The 'usual suspects'. The time involved hints at CD's being spun up, paths searched, found not to contain whatever, rewind or some partition being pushed over 100% temporarily. Folsks cramming multiple OS test installs onto media all too rarely pay attention to temporary needs. The 8+ GB needed for building OpenOffice from source caught even this old dog flatfooted, for example. Otherwise, ATA I/O is too 'universal' in use to hide a DFLY bug of such magnitude for very long, so the paucity of related reports says it is a local 'headspace' issue... Bill
Re: What would you like in DF 1.8?
as to how a *BSD-style* kernel resource set(s) can work best to support 'placeless', portable, hot-swappable goods in a near-as-dammit seamless manner. If all goes well, DragonFly may prove to be *way* better than most F/OSS prior art - for both local and remote resources. If not, 'Drag-On, Fly' will still represent a marvelous cleanup and improved understanding of code that can be utilized to some extent in the *BSD's in general - as with lessons learned from the 'trusted' and 'secure' *BSD efforts. IOW - DragonFly has already gone far enough that it cannot 'fail' - just succeed to a greater or lesser degree. ;-) Bill Hacker
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Joerg Sonnenberger wrote: On Thu, Jul 13, 2006 at 05:04:22PM +0800, Bill Hacker wrote: Old or new branches of X are rooted in a very different architectural philosophy than Win vid, and would have to start over from a clean slate to even match the sort of performance of an Amiga, BeBox, Warp/eCS or OS X deliver(ed) on comparable hardware. While I agree on most point, this needs some comments. The problem of current X11 based GUIs is not the protocol or architecture of the X server. The 99% of the slowdown is to completely broken toolkit design. Seriously, how could it have been possible to use a single 50MHz Power CPU and a 10mbit network for a number of X11 terminals 12 years ago? The difference is that applications and toolkits used an asynchronous protocol and had been greatly optimised to keep as much work as possible in the pipeline. Compare that to todays application. A simple GTK program over a slightly laggy WLAN link is visibly drawing itself a number of times whenever e.g. a menu has to be opened. *That's* why X11 performance today sucks. Everyone wants to program X11 like they program Windows, completly ignoring the roundtrip time. Joerg What is needed is really 'none of the above', IOW, there just *has* to be a better way. Two hints that it is possible include: - the snappy browser interface included with the QNX demo floppy of many years ago. - the Bluebottle/Greenbottle UI on Aos / Oberon. Lean, light, quick across the ground, and nearly indifferent to what video hardware is present, both of them. Plan 9 is another. Not much to look at, but the 'plumbing' is straightforward and low-load. 'X' had a reason to live in its early distanced server-client incarnation. Forget the KDE and Gnome resource hogs - even the so-called 'lite' desktops such as Xfce4 are slow and clumsy compared to a well-tuned Warp/eCS Workplace Shell. Most are arguably inferior to Win 3.11 in responsiveness and polish, given the same hardware. I don't see that much improvement is likely to happen on F/OSS - X or otherwise. OS X has closed the gate at one end, Vista will retain MS dominance even if they lose 30% of what is now a maket so huge an entity can get fats on the leavings. While we are generalizing, the 'C' language has long since become more a part of the problem than of the solution My tool of choice for I/O driver work was AS or Forth with native-code-compiler inlining. Never mind... I know where I can get a couple of nearly-new 17 G4 PowerBooks cheap when this one dies... Meanwhile, back at the data centre, we have migrated the 1U servers to VIA C3 with FreeBSD 4.11-stable and the 2U servers to Intel core-duo and FreeBSD AMD-64 6.1-STABLE. Plus one Xeon using 6.1, i386. Not sure DragonFly does C3 as well as 4.11, and reasonably certain DFLY is not AND-64 ready yet. But we'll keep one eye open... ;-) Bill
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Dimitri Kovalov wrote: --- Bill Hacker [EMAIL PROTECTED] wrote: AMD-64 6.1-STABLE. Plus one Xeon using 6.1, i386. Talk about an expensive boat anchor! Dimitri Yes, boat anchors, at least for small craft, are considerably lighter and cheaper. But they don't support 2+ Terabyte fast SCSI raid arrays with 4-hour-max on-site warranty service response nearly as well. Horses for courses Bill
Re: Interview with Matt on bsdtalk about 1.6
Matthew Dillon wrote: :On Thu, July 13, 2006 10:01 am, Dimitri Kovalov wrote: : : I listen to this. Very interesting. I only challange one : thing. You say that 1.6 is more stable than FreeBSD 4.x. : How can you make this claim? FreeBSD 4.x is installed in : 1000s of servers and network devices for many years, and I : don't hear of anyone using Dragonfly for more than a : corporate server or firewall. So how can you claim such : stability before it is battle tested? : :Because a good number of the issues fixed date back to FreeBSD 4.x? Because I'm an optimist. It's definitely more of a gut feeling then anything specific, from having used and worked on FreeBSD almost exclusively until I started the DragonFly project. In anycase, I really do think that DragonFly is now more stable then FreeBSD-4 ever was. And, yes, a good chunk of the bugs that have been fixed, in particular to the buffer cache and softupdates, but also issues with IPSEC, the tcp stack, and a few others, were all present in FreeBSD-4. -Matt Matthew Dillon [EMAIL PROTECTED] The volume, nature, and high level of competance of the *massive* code-clean-up that was the first big chunk of the DFLY project says it has to be at least partially true that *parts of* DFLY are superior to FreeBSD 4.X. OTOH, subsequent progress toward DFLY's goals has led to never-ending need to alter all manner of things that arguably 'ain't broke' in their comparable position in the 4.X BSD world. It might have been more accurate to have said that DragonFly *can be* more stable than 4.X BSD, as this seems to be highly dependent on what one chooses to use either of them for. Arguably 4.X BSD or even 6.X BSD retain advantages in an 'all known possibilities' environment, if only w/r greater certainty that a larger number of ports, drivers, and CPU architectures work 'well enough' for production use. Many of the items fixed in FreeBSD - legitimately in need of fixing or not, were simply not problematical at typical production stress levels. The more curious point of your chat to me was that DragonFly - aimed at serious clustering, among other goals - is not yet concentrating on the AMD-64/enhanced Intel features. Given where dualcore hardware, energy/heat loads, and costs seem to be heading, IMHO one could do worse than to drop all else and focus *exclusively* on those. Bill
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Joseph Garcia wrote: Bill Hacker wrote: - the snappy browser interface included with the QNX demo floppy of many years ago. Are you talking about that QNX enviroment that fit on just a 1.44MB floppy? That was like 10 years ago wasn't it? I have to admit. That thing was freaking AWESOME! It has a browser, networking, a GUI, start bar, and a few little tools/utilities that fit on FLOPPY! A freaking 1.44MB FLOPPY! Now-a-days you can't fit shit, or apple-butter, on a damn 1.44MB floppy. Yep, that thing was neat. Does QNX still do stuff like that? I guess these days people are impressed if they get the same kind of stuff to fit on a 32MB USB drive. Although, I bet QNX can do alot with 32MB, but I haven't looked at what they can do in almost a decade. Joey Given half a century in information technology, I could fill a website with more good ideas that have been abandoned than kept. Part of the 'challenge' is that the focus on *n*x and 'C', or 'the one true path' limits the scope of our vision. A 'hull-down' or 'foxhole' mentality loses wars, too. Bill
Odd News Server symptom?
Folks, Perhaps it is just my client (Mozilla on OS X), but on most postings over a day or two old, I am seeing the header only, and the below message (originally in html) as body: == Error! newsgroup server responded:No such article number in this group Perhaps the article has expired [EMAIL PROTECTED] (5994) Click here to remove all expired articles === Wazzup? Bill Hacker
Re: Argh, Stray interrupts 2006
Danial Thom wrote: My tech tried firing up 1.4 on an opteron MB with an HT1000 chipset and, although it seems to work, the console is literally flooding with stray irq 7 messages. Freebsd at least suppressed these after a few, but when is someone actually going to FIX this in BSD? Someone told me years ago that this was an Intel chipset bug and there was nothing that could be done, but clearly that isn't the case here. whats the workaround solution as the console is unusable in its current state? DT Same as always: 1) ALT-F2 (3, 4, etc.) before logging in. 2) Edit /etc/syslog.conf to send soem/all console messages elsewhere - after which (1) is no longer necessary. Bill
Re: more dragonfly photos
Bob Bagwill wrote: Just in case you haven't seen this site: http://stephenville.tamu.edu/~fmitchel/dragonfly/index.html -- Bob Would that this one were Gates or Ballmer http://stephenville.tamu.edu/~fmitchel/dragonfly/photo/cw_drfly.htm ..ah, well. Dreaming is cheap enuf ;-) Bill
Re: Fwd: How do I instal Dragonfly BSD from a hard drive - rather than CD?
Emiel Kollof wrote: Hi guys, Forwarded to the users list (The forwarded post is below) and also a reply to this guy. I know it's a troll, but I thought it was way too funny for you guys to miss. It nearly made me choke on my morning coffee. This guy owes me a new keyboard because coffee | nose keyboard. Heck for this reason alone I'll bite ;) Emiel, you are too easily amused... ;-) Hi Pete. *SNIP* Installing in windows is not possible, was never possible, and will never be possible. DragonFly is not a windows application. It's a full blown operating system that wants absolute control over your hardware. It's way easy to just dedicate a partition for DragonFly and just boot from network/cd and install. Cheers, Emiel *SNIP* Spiritually correct, ;-) ... but technically inaccurate. Not that I recommend it, BUT DragonFly should be comparable to other *n*x in this regard: - I have run FreeBSD under Connectix / Innotek beta Virtual PC on OS/2 Warp 4.X host. - Likewise FreeBSD and Linux under eCS SVISTA beta. (eCS host) - Likewise FreeBSD and Linux on Mac OS X, VPC 5.X and 6.X - Also OS/2 on Mac OS X host with VPC 5.X 6.X The only one that actually seems to be able to 'pierce the veil' of the virtual machine is OS/2, which takes around three hours to convince that the emulated environment can be used. No surprise, given the way it tests hardware before installing. As Connectix sold VPC to MS between VPC 5 and 6, all of the above should be as do-able on an NT-family WinBox as any other. So DragonFly BSD should be no less 'installable under Windows' than FreeBSD or Linux, i.e - while the 'guest' OS has full use of what it perceives as its own hardware, the 'VPC' is itself a task under the host OS. Needless to say, there are other alternatives to VPC or SVISTA when the host is Unix/Linux. Handy for the wandering sysadmin to do with emulation of client environments on a single laptop. There is however, another very practical use for development: The VPC can be stopped and stored in a 'frozen' state. In this mode, VPC stores the *entire* emulated environment, machine, data, memory, CPU register and program-counter, etc. in a container file. That container file can be e-mailed to a co-worker with a compatible VPC environment, and opened in the identical state as when frozen. But half way 'round the world. That might yet be of value for debugging, and partly because the emulated machine is 'standardized'. Bill Hacker
Re: Fwd: How do I instal Dragonfly BSD from a hard drive - rather than CD?
Hiten Pandya wrote: Emiel Kollof wrote: Hi guys, Forwarded to the users list (The forwarded post is below) and also a reply to this guy. I know it's a troll, but I thought it was way too funny for you guys to miss. It nearly made me choke on my morning coffee. This guy owes me a new keyboard because coffee | nose keyboard. Heck for this reason alone I'll bite ;) Hi Pete. DragonFly can infact be installed from a harddrive. If you searched the archives of the mailing list, you see that it's possible. oh, and why use a harddrive? You can also install via PXE and netboot, just as easy. (well, not really as easy, but it's definately not rocket science). As for your bootable CD argument, well, that's why they invented CD rewritables. You know, those things you can erase and rewrite. Installing in windows is not possible, was never possible, and will never be possible. DragonFly is not a windows application. It's a full blown operating system that wants absolute control over your hardware. It's way easy to just dedicate a partition for DragonFly and just boot from network/cd and install. I don't know about not possible, it can be made possible. I have achieved parts of such an endevour but never continued with it. But while we are on the subject of possibilities, it would be possible to: (o) offer a Windows application that walks a person through creating a specification file for installing dragonfly, during next boot, the whole shebam. The file can then be fed to BSDInstaller, and everything would just work like an automated install. The idea is no different from how Windows uses answer files, except you are pretty much locked into using floppy disks when it comes to Windows. (o) install dragonfly onto a second empty partition from Windows, one of the key parts would be being able to extract information from ISO files. User downloads an ISO file from dragonflybsd.org along with the Install Application, specifies path to ISO file, other config info, etc. I am sure it would attract people to our operating system, no doubt; but I don't consider writing such an application a priority. It's in my horizon of things to do when I get free time. Anyway, the guy who is flaming us is not really articulate otherwise he might just be heard by the right people. :) Kind regards, Hiten Pandya hmp at dragonflybsd.org Hiten, you are onto something here: - Thinking back to when a 'reboot' was not a complete system re-init, i.e. preserving JRAM under DOS 'reboot'... How about a downloadable dumb-but-universal script that would run under anything from CP/M or DOS onward, collect the necessary settings, be made aware of where DragonFly could be found (network, CD, HDD), where it was to be installed, preserve all these settings in RAM, then jump to a routine that shed the host OS and brought itself into life to complete the install. - all without any 'writable' local storage other than RAM. - QA in text. Look and feel much like the MB BIOS or SCSI RAID controller UI or /stand/sysinstall. 'Pretty' GUI not needed. A machine-code or Forth routine to handle all this could reside entirely in CPU cache family resemblance to MBR + the legacy Forth boot loader with 'extras', but from RAM, not external media. Bill
Re: Waiting 15 seconds for SCSI devices to settle *groan*
Wade wrote: On 02/12/05, Emiel Kollof [EMAIL PROTECTED] wrote: See subject for a pet peeve I've had for a while... Might it be an idea to copy FreeBSD here and shorten that to, say, 5 seconds by default? I know it's tunable, but it will shorten boot times a bit for people that are too lazy like me :) That and 15 seconds seems a bit too long. Know of any hardware that actually needs that long to settle in? (and don't you guys go dig up the most antiquated SCSI peripherals that actually do need 15 seconds ;) ) If yes, I'll just shut up about this. Cheers, Emiel -- The real pain for me is, with GENERIC (eg, installation kernel), you end up waiting that time even when you don't have SCSI, can't it detect that theres nothing but IDE ? It can nowadays, but could not in times past. (SCSI user since year ONE and SMD before that). Older on-device controllers said nothing to the host until they had all their ducks lined up, so if you did not wait, you would not know they were there w/o a re-scan. And you might be unable to do that re-scan if the host-bus controller had not seen devices and not grabbed a place at the table by loading its BIOS code at boot time. (CP/M-86 OS/2 anyway - FreeBSD was not yet a factor..) Newer on-device chips are *way* smarter, and will speak to the host 'instanter' with info about what they are (supposed to) have coming up, so the host-bus controller will load its BIOS and report sizes, etc. But nothing I still use regularly [1] needs even a 1 second delay - most of it is reporting-in from silicon before system-board BIOS POST is complete. Motor spin-up is no longer the determinant. Bill Hacker [1] Discounting a still working pair of 20 MB beta Bernoulli II, a pair of Syquest Puma 88, an NEC 2X 'MultiSpin' CD reader, and such. Which get switched almost as seldom as the S-100 gear. Makes one appreciate how much progress has been made. And shed fewer tears over what one has *spent* on it over a lifetime. :-(
Re: Waiting 15 seconds for SCSI devices to settle *groan*
Simon 'corecode' Schubert wrote: Emiel Kollof wrote: That and 15 seconds seems a bit too long. Know of any hardware that actually needs that long to settle in? (and don't you guys go dig up the most antiquated SCSI peripherals that actually do need 15 seconds ;) ) If yes, I'll just shut up about this. my cd writer does. but i have the delay set to 3 secs, and it just reports in later, no big deal. so i'm basically for reducing this timeout. cheers simon Still needed for large arrays, when staggered spin-up is used to reduce PS load. Modern drives generally are designed to ramp-up more gently anyway, so using it is not always required. As an inveterate SCSI user, I would still vote for shortening the time to *zero* anyway. The diminishing universe of SCSI users may then rebuild if/as/when needed with a longer period. Optioning the SCSI device (HDD, anyway) to start at power-ON means it will usually be ready well before the MB BIOS and other devices have finished POST, so it is seldom an issue even with multiple hardware RAID. YMMV, Bill Hacker
Re: how do people play with different versions of DBSD on the same system?
walt wrote: Bill Hacker wrote: Bob Bagwill wrote: How are people playing with different versions of DBSD on the same system? [...] - partition and slice your media into many (preferably equal sized) portions... I like to point out at every opportunity that DragonFlyBSD is the *only* BSD which can load the kernel from an extended DOS partition,\ . you might add '... using only it's own resources.' to make that a true statement. I usually have OS/2's Boot Manager on at least one drive in the system, and Partition Magic used to also ship with it. Doesn't matter which drive BM resides on, as it can 'register' all the others, and in turn, can daisy-chain so as to boot another boot-manager, (*BSD's, ntloader, or Lilo, for example)... .. and, since the controller can be told to boot from any SCSI ID in order to find BM... Most of the modern MB BIOS will do much the same for select the boot IDE device. Regards, Bill
Re: how do people play with different versions of DBSD on the same system?
Bob Bagwill wrote: How are people playing with different versions of DBSD on the same system? Do you install them on separate disks? Separate slices? Separate partitions? If you want to avoid having separate /etc's, /var's, and /home's, what's the most elegant way to do it? The most 'elegant' way is to NOT AVOID having separate ones They need to be allowed to differ! - partition and slice your media into many (preferably equal sized) portions. - install an appropriate boot manager. - install each new entire system into a single slice, with the whole fs on the same slice, directly under '/' - IOW, label only one swap, same one each time - and one '/' mountpoint, different one each time. - On each install, do not touch any of the other slices, and do not let /etc/fstab mount them, either. - use the BM to change 'personality' - manually mount/umount the 'foreign' slices only if/as/when you need to move data between and among them - including 'cloning' an entire slice to another. Far safer than sharing /home, /usr, /var /etc /whatever and trying to remember what matches whatever A separate partition or HDD can be mounted as a common storage / applications area, but should not have any OS-related files or needed resources on it. HTH, Bill Hacker
Re: how do people play with different versions of DBSD on the same system?
Bob Bagwill wrote: On Sat, 24 Sep 2005 06:30:49 -0400, Erik Wikström [EMAIL PROTECTED] wrote: When superVFS is in place, would we be able to have a /release, /preview, /development, and mount them over / at boot-time? Would it not be easier to install one instance of each and use the same /home for all of them, that would probably work even for multiple BSDs. Sometimes. But mail services, to name one, often use /home, and never for 100% of what they read and write. Best if each OS install is fully self-contained, shares only 'non-OS sensitive' app/data storage. True of CP/M 1.X 2X, MPM, CCP/M, DOS, OS/2, and so on as well.. ;-) Give 'em their own toybox. My impression is (correct me if I'm wrong) that the main differences between DEVELOPMENT, PREVIEW, and RELEASE are in the kernel, libraries, and toolchain, in that order. Userland changes are pretty minor. Having to download, build, rebuild, configure, reconfigure the other 95% is a pain. Perhaps so, but a highly 'automated' pain. Start the cvsup and make scripts, go relax. The alternative is too often trying to locate what unexpectedly changed off in some seldom-visited corner... and will change again, differently, next cycle. Any 'modern' OS is too big to keep the whole thing in view, and space is cheap. YMMV, Bill Hacker
