Re: New FreeBSD packaging system
Throwing caution to the wind and speaking without thinking about what was being said on Tue, May 15, 2007 at 12:00 , [EMAIL PROTECTED] blurted this: [much text deleted as I only am going to comment on one part - wjv] Message: 6 Date: Mon, 14 May 2007 23:34:52 -0700 From: Bert JW Regeer [EMAIL PROTECTED] Subject: Re: New FreeBSD package system (a.k.a. Daemon Package System (dps)) To: Garrett Cooper [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org On May 14, 2007, at 10:03 PM, Garrett Cooper wrote: Bert JW Regeer wrote: On May 12, 2007, at 5:14 AM, Philippe Laquet wrote: Stanislav Sedov a ?crit : On Fri, 11 May 2007 02:10:05 +0200 Ivan Voras [EMAIL PROTECTED] mentioned: - I think it's time to give up on using BDB+directory tree full of text files for storing the installed packages database, and I propose all of this be replaced by a single SQLite database. SQLite is public domain (can be slurped into base system), embeddable, stores all data in a single file, lightweight, fast, and can be used to do fancy things such as reporting. ... I am able to understand many of the gripes with using a databases, and have to import yet another code base into the FreeBSD base, however as one of the young ones, and knowing sed/awk/grep and SQL, I prefer SQL over having to process hundreds of text files using text processing tools. It saddens me each time I run one of the pkg_* tools that needs to parse the flat file structure since it takes so long. I have friends running Ubuntu and their apt-get returns results much faster. True. I was thinking of backup, and recreation from scratch, considering that the database wouldn't be more than a few megs. In place replacement just seems like a hairy situation sometimes.. ... The experience I got from running SVN with BDB as the back-end database to store my data, I say no thanks. In that case I would much rather stick with the flat text files than go with a database. Well, a few comments: -Text files are bloated. Although many people are for XML, it takes much longer to parse than binary databases. /var/db/pkg/ are all plain flat text files. I am not a supporter of XML at all. -Custom text files require custom format capable parsers, no matter what the format, and the less coverage a parser has, the more probable the likelihood of bugs IMO. We already have these in the pkg_* functions, so i'd hope they are fairly solid! ... I am not opposed to text files, other than that they can be slow. I am against BDB because over the years, in my experience they have shown to be extremely unreliable and easily corrupted. If we are going to be making changes to the way the ports/packages store the information about what exists, it should be done in such a way that it is scalable and at the same time extensible (is this a word?). So why not take the same approach that is used in the password and shadow files. That way you have a plain text editable file which then builds the pwd.db and spwd.db files that are used by the system. Or am I missing something there. Bert JW Regeer Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A handy utility (at least for me)
On Tue, Aug 29, 2006 at 12:00 [EMAIL PROTECTED] saw Error reading FAT table? Try SKINNY table? And promptly said: Date: Mon, 28 Aug 2006 18:18:58 +0200 (CEST) From: Oliver Fromme [EMAIL PROTECTED] Subject: Re: A handy utility (at least for me) Rick C. Petty wrote: Mario Lobo wrote: My /usr/ports directory was occuping 24 gigs, of which 20 was just from the 'work' directories ! You should type make clean more often. ;-) And to ensure that 'make clean' in the /usr/ports directory runs much faster, be sure to add NOCLEANDEPENDS=YES in your /etc/make.conf. After you run that on the entire tree besure to comment it out so that when you run make clean inside a port you clean all the dependancies too. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
While stranded on the shoulder of the Information Superhiway and trying to flag down some passing bytes [EMAIL PROTECTED] said Bits don't fail me now, and continued with: Date: Wed, 19 Apr 2006 13:03:57 -0400 From: Coleman Kane [EMAIL PROTECTED] Subject: Re: [PATCH] Fancy rc startup style RFC On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], Coleman Kane [EMAIL PROTECTED] typed: On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: How about we all discuss good choices for default colors? Depends on the goal: do you want the default to work for everyone, or do you want the default to be prettier and/or better for most people but absolutely suck for a few? I was thinking perhaps of having a predefined set of templates (with the option and documentation to add your own). Perhaps implement one that creates the traffic-light style that seems to make intuitive sense to many americans (Bold Red: error, Bold Green: Success, Bold Yellow: warning/notice), and also have another perdefined one that uses a different color set. Traffic-light style is also designed to be useable by completely color-blind people - which is rare. By that if you notice traffic lights are always in the same order, green, yellow, red so that all you have to do is be able to see the luminance value in the abscence of any chroma information.. That's the problem with web-sites which depend on chroma value, and often have colors which are easily discernable by normally sighted people, but the luminance is very close which can make things almost invisible. I have a noticed a traffic-sign problem which another person also wrote to the local newspaper - and the traffic division is looking to change the signs. In Florida bright days are indeed very bright. There are signs that use lights to spell out the message with what someone feels the most important part in 'red'. The signs have a black background. On a bright day I see NO TURN ON or TO PEDS as the word RED in the first message is invisible to me, and the YIELD in the second has the same effect. There is also a sign that I came up to that used the universal sign for turn. I started to turn and my wife had me stop because the circle with bar through it was in RED and I could not see it. On overcast days or at night these signs are easily viewable. For those of you who remember the late 1980s when IBM came out with OS/2 and MS came out with a new Windows, the complaints were the default screens on OS/2 were drab while the Windows had bright colors. IBM is very good at designing things for people with disabilites and the OS/2 default screen was designed to be readable by someone with total color-blindness - which as I said is rare. The way to check if a web-site is readable by all it to use a monochrome monitor [ exceedingly hard to find nowdays ], and at least some government sites are now required to be that way. Color can be a great way to emphasize items IF the chroma and luminance values are carefully chosen. If not you can take away a lot of functionality. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim [EMAIL PROTECTED] Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: [PATCH] Fancy rc startup style RFC
Ang utong ko ay sasabog sa sarap! exclaimed Sergey Babkin while reading this message on Wed, Apr 19, 2006 at 12:18 and then responded with: From: Bill Vermillion [EMAIL PROTECTED] has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. When I have time and patience to mess around, I set the LS_COLORS and such variables to the complementary bitmasks of what they've been, and that fixes the problem with contrast on the black background. Well I run in 80x24 text mode almost all the time, and when I need some graphics/web stuff I hit the KVM and move to an XP machine. I use vidcontrol to set my screen /home/bv/.profile:vidcontrol green black /home/bv/.profile:vidcontrol -b blue /home/bv/.profile:vidcontrol -c blink That gives me green on black, with a blue border defining the edge of the screen. With my vision it works very well. I got to something with white on black and I find it too bright to use, except on dying monitors :-) [I've had some clients with really bad server monitors - typically SCO. On those I'd set the white to bright white to make them readable] Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: [PATCH] Fancy rc startup style RFC
They all laughed on Wed, Apr 19, 2006 at 13:32 when Mike Meyer said: In [EMAIL PROTECTED], Sergey Babkin [EMAIL PROTECTED] typed: From: Bill Vermillion [EMAIL PROTECTED] has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. So where do linux's blasted ls colors come from? It prints some file type as green. Green on white is simply bad news, whether or not you have vision problems. I always have to go disable them (and some linux distros make them *hard* to disable). I just checked in on one Linux machine I admin - SuSE 9.2 - and the colors are set with the variable LS_OPTIONS. I've set LS_OPTIONS to '-N --color=none -T 0' And looking at the .bashrc there is also a test for the binary dircolors, and then looks for user files .dir_colors I also notice that as shipped the .bashrc has a comment line that says If LS_COLROS is set but empty the terminal has no colors. It is spelled COLROS not COLORS - but that's just cosmetic and sloppy. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Filesystem monitoring question
On Fri, Nov 18, 2005 at 12:00 , [EMAIL PROTECTED] showing utter disregard for spell-checkers gave us this: Date: Thu, 17 Nov 2005 15:07:48 + From: Cornelis Swanepoel [EMAIL PROTECTED] Subject: Filesystem monitoring question I have a FreeBSD 6.0 box with a partition that is accessible to a number of clients via SMB and NFS. I would like to monitor activity on this partition so that every time a write to it is completed, my C program is run (which stats the file and stores some info about it in a database amongst other things) My question is: What do I need to learn in order to construct a trigger for my code? If anyone can point me in the right direction I would greatly appreciate it. What is that you need that fam won't do. See man 1m fam. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system password's file --failed
Throwing caution to the wind and speaking without thinking about what was being said on Tue, Oct 18, 2005 at 12:00 , [EMAIL PROTECTED] blurted this: Send freebsd-hackers mailing list submissions to Date: Tue, 18 Oct 2005 12:17:54 - (UTC) From: [EMAIL PROTECTED] Subject: Re: system password's file --failed To: freebsd-hackers@freebsd.org Hi all, I failed this steps. FreeBSD cannot recognized my username. I will try it again. Have anybody another solution ?? Thanks before. regards. If you used those steps no wonder it failed. shadow is NOT at all like master.passwd. ... I would suggest you to try the below and make sure this works 1 ) Install a new freebsd server 2 ) create a user on your linux machine say with username freebsd and some password 3 ) now copy the data in your /etc/passwd file of linux machine to freebsd machine And the /etc/passwd in Linux and System V [or all the old Unix systems] is not the same format as in BSD. 4 ) Also copy the /etc/shadow file to freebsd server and renmae it as /etc/master.passwd I'm surprised you could even log in with that. 5 ) Also copy /etc/groups Groups are used differently by default in BSD. Don't blindly apply Linux knowledge to BSD 6 ) Now try to login to freebsd machine with the new user created on the linux machine. Note : Please create a copy of the original file on freebsd machine before you change the real file And DO NOT LOG OUT - as you might not be able to log in again. Look at the file formats of BSD and Linux. You'll note extra fields. If you have separate passwd and shadow on Linux, you need to manipulate those before putting in BSD. You can simply cut and paste [using Unix cut/paste not a gui thing] to add the fields and put the encrypted portion of shadow where it belongs. And put that in master.passwd and USE VIPW - which will check the file. If master.passwd is correct when you exit vipw it will build /etc/passwd. I don't recall the script the other person posted, but the directions above are really wrong. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: systems password's file
From: Matthew D. Fuller [EMAIL PROTECTED] Subject: Re: Re: system password's file On Fri, Oct 14, 2005 at 06:54:26AM -0500 I heard the voice of Sergey Babkin, and lo! it spake thus: I don't know if it's fixed now or not. I just converted a Mandrake box a month or so ago, which used MD5 hashes. Worked flawlessly. Hm, considering the we'd like people to migrate from Linux to FreeBSD, having such a conversion script/program (especially if someone writes it for their own use anyway) in the base system would make a lot of sense. It's not that hard. Somebody mentioned an awk script. I slapped it together in perl in about 5 minutes. I'll bet it's in /tmp somewhere... I've done this a couple of time - but both times I just did it manually - with the tools in the OS - as this was the quickest. One was from an SGI IRIX, the other was from SunOS. The latter had a really slow sendmail system on a very old box. The move to a FreeBSD was not planned that far in advance and not planned for - but the Sun had gotten so slow they moved to getting their mail directly from their ISP. It was about a 10 minute job [max] using cut(1) and paste(1). Since I'd started with Unix before pool and on limited systems, those tools came to mind naturally. Both the SGI and SunOS conversions worked flawlessly. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Software suspend on FreeBSD
Earlier in the linear time track, on approximately Fri, Sep 09, 2005 at 23:01 , [EMAIL PROTECTED] divulged this public information: From: Bruno Ducrot [EMAIL PROTECTED] Subject: Re: Software suspend on FBSD. To: Pranav Peshwe [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Fri, Sep 09, 2005 at 07:52:46PM +0530, Pranav Peshwe wrote: Hello, Does FreeBSD have 'software suspend' like linux ? or maybe something similar... No. Yes. It depends upon which shell you are using. For shells that support it you just suspend it with control-Z. A restart is issued with 'fg' - foreground. Unless of course the OP means something entirely different. -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
Bits dont fail me now! was what [EMAIL PROTECTED] muttered as he hastily typed this on Fri, Aug 19, 2005 at 12:00 : 1. Re: Parking disk drive heads (Glenn Dawson) Message: 1 Date: Wed, 17 Aug 2005 12:47:32 -0700 From: Glenn Dawson [EMAIL PROTECTED] Subject: Re: Parking disk drive heads At 11:32 PM 8/16/2005, [EMAIL PROTECTED] wrote: Hi, which is the correct way to park the hd head? Seagate drives park the heads automatically when they are turned off. As far as I know, this applies to other manufacturer's drives as well. To which he replied: Message: 2 Date: Thu, 18 Aug 2005 08:14:47 +0200 From: [EMAIL PROTECTED] Subject: Re: Parking disk drive heads I don't want to park them on turn off. I want to park them before a possible strong shock which could cause damage and unpark them afterwards. The setups for parking heads pretty much went away when the move from MFM drive to ATA technology. And if your are worried about a shock that could damage the drive, you will probably lose your computer at the same time. Check the technical specs on current drives. You will see that most will handled well over 100G shocks when not running, and usually far over 20G in operational mode. Considering that 20G to the human body usually means death you aren't going to have to worry about losing drives to operating bumps unless you have a habit of dropping them in parachutes from airplanes. :-) I have ruined drives with a bad bump in the past - but those were MFM drives - and that happened in the mid-to-late 1980s. The first HDs I saw could withstand less than 1G in shipping so the 5.25 Shugart ST-505 drives - $25090 for 5MB [that is MegaByte] were shipped in foam padded boxes a bit larger than the drive, and these boxes were suspended by springs from the corners of a much larger shipping box - in the 18x18 size category. IOW - unless you are running some early ATA drives, shocks when running are something you don't have to really worry about, unless you plan to shove the entire computer off the desk when it is running with the power on. Bill [The orignal post was in of freebsd-hackers Digest, Vol 126, Issue 5] -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to reset root passwd FreeBSd4.7
While normally not able to pour water out of a boot with instructions on the heel, on Fri, Jul 15, 2005 at 12:00 our dear friend [EMAIL PROTECTED] uttered this load of codswallop: Message: 3 Date: Thu, 14 Jul 2005 09:55:16 -0400 (EDT) From: John Von Essen [EMAIL PROTECTED] Subject: Re: How to reset root passwd FreeBSdD4.7 Boot with 1st CD, goto the Fixit Shell (will need 2nd CD). From there you have to manually mount the / filesystem and edit passwd (just clear out the passwd, root::). However, do an fsck on the device first (you may have to reboot afterwards) since if you have any fragmentation following an unclean shutdown, you will not be able to mount the device. Just a short comment. 'Fragmentation' has nothing to do with this. An bad shutdown fails to sync the data and thus requiring and fsck to ensure the filesystem is in an stable state. The 'fragments' you see referenced in the fsck only reference the number of files that are stored in fragments - eg not occupying a full block allocation. Bill Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: immenent disk failure ?
On or about Fri, Apr 15, 2005 at 12:01 , while attempting a Zarathustra emulation [EMAIL PROTECTED] thus spake: Message: 4 Date: Thu, 14 Apr 2005 10:58:02 -0500 (CDT) From: H. S. [EMAIL PROTECTED] Subject: imminent disk failure ? ... I have a server running 4.X for almost two years now, without problems - rock solid as it should be - yesterday the server became unresponsive, now that I have access again, and while checking the logs, I found this as the last message before the unresponsiveness: /kernel: ad0: READ command timeout tag=0 serv=0 - resetting The next message is the system getting back on, 1hour later. I have not changed anything kernel-related on this system for a long time (jul 2004), just apply the occasional kernel patch and rebuild/reboot the system. I never encountered this problem before. Could this message mean this disk is giving its last breaths ? It might help if we knew a bit more about the system such a drive make and model - you can see that in dmesg. That may point out some device that is known to be problematic. The last time I got timeout errors like that was in the 3.x era with a SCSI controller. Last IDE problem I had was a bad read that force the system into PIO mode with over 75% performance decrease. The only way around that one that I was aware of was a reboot. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Design and Implemenations of FreeBSD
On or about Thu, Mar 24, 2005 at 12:00 , while attempting a Zarathustra emulation [EMAIL PROTECTED] thus spake: Message: 3 Date: Thu, 24 Mar 2005 02:15:07 + From: klowd9 - [EMAIL PROTECTED] Subject: Re: Kernel documentation and specification Reading the CVS logs for the relevant files should give you ideas about who might be able to answer your questions. However, you shouldn't expect that people have time to answer lots of questions. Of course, it helps if your interest is in the context of contributing something back to the project. Kirk's book, ``The Design and Implementation of the FreeBSD Operating System'' probably contains the answers to basic questions about scheduling and IPC. I considered purchasing that book, which is very very good imo, but a bit overpriced at $60.. Any other resources about kernel development, and to whom may i speak with to help me get started.. Considering it's coming from a publisher which specializes in technical books and many of theirs are used in college courses it's a typical price. However - with one or two rare exceptions - I've bought almost all my tech books dealing with computers from Bookpool. http://www.bookpool.com They currently have McKusick's book in stock at $33.95. The other BSD books are also priced similarly. I have no relationship with Bookpool other than being a very satisfied customer and always go there first for any tech book. I even managed to get the O'Reilly 4.4BSD books from them - the set of five - for about $100 - when they were still in print. Highly recommended. This month they are having an 'Open Source' sale with 43% discounts - over 700 books. I hate to think how much I've spent on computer books in the past 20 years or so - but it's in the thousands. Sort of a college educations at home. I still have my first Unix books - the Bell Labs Unix Programmers Manuals - that got me hooked on Unix. Total pages on that entire system was less than that of part I of SysV. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Flushing HD cache - was Re: FUD about CGD and GDBE
-- Message: 18 Date: Wed, 2 Mar 2005 13:15:49 -0800 (PST) From: ALeine [EMAIL PROTECTED] Subject: Re: FUD about CGD and GBDE [EMAIL PROTECTED] wrote: I gave up on journalling myself because IMO it complicates things a lot and the problem it solves is very very small. If only hardware manufacturers were to equip hard drives with a mechanism to ensure atomic writes. A capacitor large enough to hold enough energy to flush the cache upon detecting the power supply was cut would be sufficient. They could even use a battery the status of which could be monitored via S.M.A.R.T., I don't see how implementing something like that could possibly make the cost noticably higher. Actually at least some used to do something similar. In some IBM SCSI drives of a few years ago, if there was a power failure, the energy in the rotational momentum of the platters was used as the motor was changed over to a miniature generator that provided enough current to flush the contents of the on-board cache to the platters. A capacitor large enough might be too large considering how small everyone is trying to make thier drives. And the main goal seems to be to make drives cheaper - so until enough people want this feature and are willing to pay for - I don't think we'll see this return. Recent IBM Thinkpad and Apple PowerBook G4 laptops have sudden motion sensors which park the disk heads when a sudden motion is detected in order to prevent damage from a fall and similar, so this atomic write guarantee mechanism should be trivial for them to implement and it would save us a lot of work. The first hard drive I ever saw - a genuine Shugart ST-506 - had to be shipped in two boxes with the internal box being suspended by springs from the larger box - as it would only take about .5G before it had problems. At the time it was the only 5.25 hard drive being made. Now drives routinely have 100G shock survivability static and at least 20G when turning. And a human body will not normaly survive a 20G shock. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAPI CD changers anybody ?
On Mon, Jan 24, 2005 at 23:27 in [EMAIL PROTECTED]: -- Message: 6 Date: Mon, 24 Jan 2005 17:36:52 +0100 From: S?ren Schmidt[EMAIL PROTECTED] Subject: ATAPI CD changers anybody ? Seems I lost my lonely ATAPI CDROM with built in changer to the eternal HW scrapyards, let it rest in peace :) Finding a new one seems difficult so I thought I'd ask around how many still has one of these ? I ask because the support code for those seem to have suffered bitrot to the degree that it most likely hasn't worked on -current (maybe even 5.x) for a long time, but alas I cant test that. Now, since it seems that such devices are no longer made, and newer really caught on, I need some good reasons to keep the (broken) support in there. My own opinion since HD capacity is getting larger and larger is that unless you have a large amount of CDs that you need to rotate in and out - and if there are many it would constantly be reloading the changer - is to make images of all the CDs you need to access, then run vnconfig to set up mount points, and access the as local file systems? IT surely is a lot faster. You could mount 10 CD images this way and only use up 6GB space and with 500GB HDs coming in at $399 [I saw local ads for that last week] it could be cheaper than trying to find a changer. End of freebsd-hackers Digest, Vol 97, Issue 2 -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protecting from the dreaded rm -fr /
On Sun, Oct 03, 2004 at 00:20 , Men gasped, women fainted, and small children were reduced to tears as [EMAIL PROTECTED] confessed to all: Message: 2 Date: Sat, 2 Oct 2004 22:43:49 +1000 From: Peter Jeremy [EMAIL PROTECTED] Subject: Re: Protection from the dreaded rm -fr / To: Giorgos Keramidas [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Sat, 2004-Oct-02 11:51:43 +0300, Giorgos Keramidas wrote: The reason I liked this idea is that root has zillions of other ways to destroy an entire system, but not many of them are likely to be the result of mistyping a single character as shown below: # rm -fr / home/someuser/* I've had a customer write a cronjob that did almost exactly this. He managed to 'test' it on all the (redundant) production systems as well as the test model. We were only called in when he found that there were some unexpected console messages and the systems wouldn't boot when he pressed the reset button. Luckily it managed to kill itself before it destroyed all the evidence (since the culprit initially denied doing anything). Based on that, I'm definitely in favour of some anti-foot-shooting measures. I don't think it should fail quietly: If I ask the computer to do something (stupid or not), it should either do it or tell me that it hasn't done it. Failing to do what I ask and not telling me means that I can't trust the computer - I have to double-check that the files I wanted to delete have actually gone away. You can always trust the computer to do exactly what you tell it to, even if what you told it to was not what you wanted it to do. If you customer tested the program on non production machines and it failed on the production machine then it was obvious the customer made the mistake of re-creating the crontab line instead of copying it over. The way to keep from shooting yourself in the foot is 1) always check with an 'ls' argument before doing any exterme wildcarding and if you like what you see use your shell editing to change 'ls' to 'rm'. 2) is to let the end user know that certain things are very dangerous and they could destory their system, 3) have automated and verified backups run on the complet system every night. I've been using Unix too long to want to see this behaviour changed, and I'll use the same argument that others do when they advise against aliasing rm to rm -i. If you know that you can't shoot yourself in the foot, you will not treat rm as if it were a loaded automatic pistol and you don't reinforce your double checking. Then one day you go to a machine that doesn't have the safety-net and you make a mistake and it won't be recoverable. If we could arrange to change all the rm's on all the Unix machines in the world at the same - maybe then I'd go for it :-) Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to read bad blocks error message marking of same
to determine if the drive failed or the controller failed. And by that time 15Mhz ESDI controllers were impossible to find. The drive was a Maxtor. The other drive that ran almost 7 years migrated from one ISP to another. I replaced it after I made one of my rare trips to the colo and noticed there was noise from the HD that was heard above the noise of the 4 Liebert air-handlers in the colo. That was a SCSI 'cudda. The bearings were getting really bad. As one of the other posters notice SCSI and drives designed for server work - not made to be the cheapest desk-top just run and run. I bought a half-dozen 'as-is' HDs that had been pulled. A couple were totally shot. These were IDE in the 10MB range. I dl'ed the manufacturers utitlities for the drives that had them, ran them, and things came to life. I found Spanish versions of Windows. The MS format and 'recovery' utilities had failed on these, just as Spinrite indicates. I've found no need for things such as SpinRite in the Unix world. I'd like to hear from others who have found the opposite. Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck fails - mark sectors as bad?
Message: 4 Date: Sun, 28 Mar 2004 18:43:03 -0500 From: Dan Langille [EMAIL PROTECTED] Subject: fsck fails - mark sectors as bad? To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII I had a hard drive failure. I'm trying to get as much data off it as I can before I restore from backup. I have mounted the drive in another box and I'm attempting to salvage what I can. I thought I might be able to mark the bad sectors as bad, and get the file system mounted. [fsck out put deleted in this reply - wjv ] ... this froze up and I found this in /var/log/messages: Mar 28 17:11:31 tmp /kernel: ad2s1a: hard error reading fsbn 6399 of 3168-3295 (ad2s1 bn 6399; cn 0 tn 101 sn 36) trying PIO mode Mar 28 17:11:31 tmp /kernel: ad2: DMA problem fallback to PIO mode Mar 28 17:11:36 tmp /kernel: ad2s1a: hard error reading fsbn 6415 of 3168-3295 (ad2s1 bn 6415; cn 0 tn 101 sn 52) status=59 error=4 0 Mar 28 17:11:41 tmp /kernel: ad2s1a: hard error reading fsbn 3187 (ad2s1 bn 3187; cn 0 tn 50 sn 37) status=59 error=40 Mar 28 17:11:46 tmp /kernel: ad2s1a: hard error reading fsbn 3188 (ad2s1 bn 3188; cn 0 tn 50 sn 38) status=59 error=40 Mar 28 17:11:51 tmp /kernel: ad2s1a: hard error reading fsbn 3189 (ad2s1 bn 3189; cn 0 tn 50 sn 39) status=59 error=40 Mar 28 17:11:56 tmp /kernel: ad2s1a: hard error reading fsbn 3190 (ad2s1 bn 3190; cn 0 tn 50 sn 40) status=59 error=40 Mar 28 17:12:01 tmp /kernel: ad2s1a: hard error reading fsbn 3191 (ad2s1 bn 3191; cn 0 tn 50 sn 41) status=59 error=40 Mar 28 17:12:06 tmp /kernel: ad2s1a: hard error reading fsbn 3192 (ad2s1 bn 3192; cn 0 tn 50 sn 42) status=59 error=40 Mar 28 17:12:11 tmp /kernel: ad2s1a: hard error reading fsbn 3194 (ad2s1 bn 3194; cn 0 tn 50 sn 44) status=59 error=40 Mar 28 17:13:24 tmp /kernel: ad2: READ command timeout tag=0 serv=0 - resetting Mar 28 17:13:24 tmp /kernel: ata1: resetting devices .. ata1-slave: ATA identify retries exceeded Mar 28 17:13:24 tmp /kernel: done Definately some bad sectors there. But you should be able to moun that drive in a read only mode. In read only you can get by without an fsck, and often this is the only way to be able to get to the data. When you get the data off be sure to check it's integrity as depending on what is read or how it is read you could have blocks of junk or blocks of nulls. I've been lucky and never had one corrupt this badly needing to mount RO in at least 10 years, so I've never had to do this on a current BSD type FS - just the old S51 and early FFS on commercial Unix systems. Bill End of freebsd-hackers Digest, Vol 54, Issue 1 ** -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Somewhere around Fri, Jan 09, 2004 at 17:11 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: -- Message: 16 Date: Fri, 09 Jan 2004 22:57:56 +0100 From: Martin Nilsson [EMAIL PROTECTED] Subject: Re: Discussion on the future of floppies in 5.x and 6.x Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed This is getting stupid! This discussion is just like when the i386 support was removed from the GENERIC kernel, a lot of noise about old systems that wouldn't be able to run (or benefit) from FreeBSD 5 anyway. There is a difference between old systems and new systems that don't have CDs. And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. I fail to see the difference in required labour between creating two floppies or a CD-R/RW disc. Most new machines ship with CD-RW drives today, the only boxes that can't boot from a CD are early Pentium1 class and frankly why run 5.x or 6.x on those? I have several PIII's that can't boot from a CD because there is no room for a CD. These are 1RU units in a colo. A floppy, two HDs, on the back two NICs, a serial connector, and a keyboard connector. The iNTEL 1RU units don't even have graphics cards and the BIOS boot messgages are routed out the serial port which changes to true serial after POST. All are in a colo facility - and I suspect many other have the same problem. The only 1RU units I've personally seen with CD units in them are the little Sun pizza box Netras - SPARC platform - that a colo client had has front ends for their G4s [running Web Objects] and the large Sun running an Oracle back end for a data base. And those CD players were custom made - and exceptionally thin - and instead of a drawer that came out, the spindle mechanism came out that you put the CD onto and then it slid back in. Space is a big consideration in those small units. All my 2RU machine have CDs in them. I'd hate to have to think of taking the devices out of the racks and then the building to install a new OS. It's no fun with a floppy and minimal work space in the racks but I've only had to access them via floppy about twice, as I can rebuild and reinstall remotely. As long as I don't have to remake a file system I'm in good shape. But CD's just aren't always in 'industrial' type machines - as the only time they'd be used is during install. Luckily at least a couple will support PXE. Not all will be that lucky. End of freebsd-hackers Digest, Vol 42, Issue 10 *** Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adding more ram
While normally not able to pour water out of a boot with instructions on the heel, on Wed, Dec 10, 2003 at 02:41 our dear friend Mike Silbersack uttered this load of codswallop: Just one slight addendum here. I'm replying because I want to answer your real question. g The notion of swap = 2 x ram is an old one, and is no longer applicable. (Some) older VM systems used very simplistic swapping mechanisms, which required entire processes to be swapped, thereby requiring large amounts of swap space. FreeBSD (and other modern OSes) page out to the swap file in increments of 4K pages, and do so in a flexible manner. As a result, you should always have *some* swap space to handle overload cases, but it's not necessary to keep any specific ram to swap ratio. Systems such as the Irix I used before moving the servers to FBSD around 1996 - reserverd swap space for applications when the application started up so those needed large swap space. Often it was never used, but the design allocated it anyway. Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Minimalist FreeBSD 4.8
While humming that old rock song Yackety Yacc - Dont Awk Back [EMAIL PROTECTED] sang or SED something like this: -- Message: 10 Date: Wed, 27 Aug 2003 10:53:38 +1000 From: Greg Black [EMAIL PROTECTED] Subject: Re: Minimalist FreeBSD 4.8 To: Diomidis Spinellis [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On 2003-08-26, Diomidis Spinellis wrote: Tyler Kellen wrote: The information I'm looking to aquire is the absolute minimum files required to boot FreeBSD 4.8 into multi-user mode. If this involves deleting a massive amount of directories and files, or setting up a new drive and copying only the needed files, I think I can make it work. You can use the system the way you intent to for two weeks, and then run find / -atime +2w -print0 | xargs -0 rm -f This command will delete all files that have not been accessed within the last two weeks. And it would also remove things like find and xargs and all the other system binaries -- their atime does not get changed when they are executed. Check your facts before giving this kind of advice. And if you had an entry like this in your /etc/fstab file it could cause some suprises too. # DeviceMountpoint FStype Options DumpPass# ...[deleted - only left significant line - wjv] /dev/da0s1f /usrufs rw,noatime 2 2 This has among other things a new hierarchy and in this underpowered system I saw no need to write atimes to the inode which are probably going to be gone in two weeks anyway. atime is probably not needed in the vast majority of systems IMO. Bill -- Bill Vermillion - bv @ wjv . com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
low level format of an IDE drive
Knocking over a stack of dishes in the heat sink freebsd-hackers-digest wondered out loud about: -- Date: Mon, 8 Jul 2002 14:08:27 -0700 (PDT) From: Matthew Dillon [EMAIL PROTECTED] Subject: Re: offtopic: low level format of IDE drive. :One of my FreeBSD development boxes had a hernia last week :when it lost power while writing to disk. The drive wrote out :garbage to a track. :I want to reformat the drive, (low level) but the bios doesn't :have any support to do this (In the past That is how I did :this). The machiine has 1 CD drive and no floppy.. :anyone with any ideas as to how one can reformat a hard drive :feel free to lend me a clue.. Two things: (1) dd if=/dev/zero of=raw_device bs=32k This will force the drive to reassign broken sectors. Run this command twice. If the second run of the command is successful and does not stall (looking at running 'iostat 10' output will tell you whether it stalled) then you are golden. Use the base device for the dd output file, e.g. like. '/dev/ad0' Do not specify a slice or a partition . (2) If the command fails for any reason other then hitting the end of the media, or if it stalls on the second go-around, throw the drive away and buy a new one. Not neccesarily true. I picked up some as-is where-is drives. MS's fdisk would take hours trying to map out bad spots, failures galore. I got the manufacturers format disk and these came back as if they never had a problem. Disks are available for Western Digital, Seagate, and Maxtor. I've found no others. I had a install on FreeBSD go astry because of an old-bios and could not get anything to work. It was a brand new warranted drive. Manufacturer 'recertify' - one of the options on the Maxtor disk - made everything lovely again. For SCSI problems I have access to an SGI and their low-level SCSI utility is wonderful - commercial version at hundreds. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: lsof and listening processes on 4.5
Date: Mon, 11 Feb 2002 16:18:35 -0800 From: David O'Brien [EMAIL PROTECTED] Subject: Re: lsof and listening processes on 4.5 On Mon, Feb 11, 2002 at 01:19:23PM +0100, Rogier R. Mulhuijzen wrote: If you did recompile, maybe we broke lsof =) We did with 4.5. Unfortunately the latest LSOF changed how it is packed. I spent an hour trying to update the port but got pulled away before I was done. Grab the latest tarball and build by hand. Hm. Something must be broken then. I run cvs from cron and update ports all the time. I'm running 4.5-Stable #9 and I recompiled lsof yesterday from the prots with absolutely no problems. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: forwarding broadcast
On Thu, Aug 09, 2001 at 11:36:38AM -0400, Jonathan Chen thus sprach: On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not forwarded. For instance, if I have a FreeBSD router with interfaces 192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to 192.168.2.255, the packets are dropped to the floor. IMO, this is wrong... But the question now is - what is the netmask on these interfaces.? That will make a difference. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: forwarding broadcast
On Thu, Aug 09, 2001 at 12:30:56PM -0400, Jonathan Chen thus sprach: On Thu, Aug 09, 2001 at 12:23:52PM -0400, Bill Vermillion wrote: On Thu, Aug 09, 2001 at 11:36:38AM -0400, Jonathan Chen thus sprach: On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not forwarded. For instance, if I have a FreeBSD router with interfaces 192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to 192.168.2.255, the packets are dropped to the floor. IMO, this is wrong... But the question now is - what is the netmask on these interfaces.? That will make a difference. These are both class C networks, and their netmask is specified accordingly (/24). I'm pretty sure my setup is correct here. So they are two separate networks therefore a broadcast for one should not go the other. If on the other hand you netmask was 255.255.252.0 then 192.168.0.x thru 192.168.3.255 would be part of the same network and you'd expect a broadcast to propagate. At least this is how I understand how it works, and I could be wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: freebsd-hackers-digest V5 #152
Re: Query: How to tell if Microsoft is using BSD TCP/IP code? -- From: [EMAIL PROTECTED] (Jordan Hubbard) Date: Fri 15 Jun, 2001 Subject: Re: Query: How to tell if Microsoft is using BSD TCP/IP code? root@winston- strings FTP.EXE |grep University of California @(#) Copyright (c) 1983 The Regents of the University of California. You can't tell much from the utilities, there are still too many obvious traces of the proprietary product they originally licensed (much of which was not BSD-derived, ... Using Windows Explorer and searching for contain text with Regents of the University of California yield results for: C:\windows\ftp.exe -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Patented algorithm in FreeBSD
Patents don't always require licensing. Ever Unix system extant has a patented piece in it [or perhaps HAD is more appropriate] as the patents had expired. I saw the copy of it years ago and I looked for it recently but can't figure out where it is. The permissions - the old -rwx- etc we are so familiar with was patented, Ritchie or Thompson, and was patented and permitted to be used by anyone. This was so no one could monopolize it. Jordan pointed out the XOR routing for curosor hiding, and 15 years ago there was big hub-bub and a lot of net-posting on that fearing that someone might try to enforce that. It was a well-know useage but someone did patent it. This goes to the era of the suits on 'look and feel'.We just need to hide all the code from the lawyers. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel size..
On Thu, May 10, 2001 at 11:51:18AM +0100, vishwanath pargaonkar thus sprach: i have free bsd 4.2 stable. i did some changes may be 10-15 lines to kernel source. but thing i am amazed is kernel size. size of kernel.GENERIC is 3258128. but as of my kernel is 13068130 when i cheked it. my kernel is stable there is no probs. but y is size soo big?? No one will have a clue unless you at least tell us what lines you modified. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: freebsd-hackers-digest V5 #1
Date: Sun, 7 Jan 2001 05:07:06 -0800 (PST) From: Gordon Tetlow [EMAIL PROTECTED] Subject: Re: OT: silence as an answer? (was: how to test out cron.c changes?) Hello there! On Fri, 5 Jan 2001, Doug Barton wrote: Gerhard Sittig wrote: [snip] Consider the following. We are in the spring and DST is "springing forward" at 2am. We have a job scheduled at 2:15 that takes one hour to run. There is another job scheduled at 3:20 that ABSOLUTELY POSITIVELY cannot run unless the first job finishes. Aside from the fact that this is bad design, how should cron handle this situation? I think this is a really horrible example. It is impossible for FreeBSD to expect to catch bad design on a local administrator's part. The admin should implement some sort of semaphore (a file in /tmp) or just append the dependent job to the first job. We can't insulate stupidity, at least we shouldn't, otherwise FreeBSD is going to start looking more like Windows. I agree on that. Cron can't know the just how a program runs. Taking the above example and shifting the first program back to prior to 2AM - and that it take over an hour to run - what happens when a the clock springs forward and the hour is missing. The job wasn't scheduled in the 2AM black hole area. Programmers do have to consider DST. That's what we get paid for, right. Just like getting things like Y2K straight :-0 And the last Y2K bugs occured this past week. In Norway [as I recall] on train schedules, because 12/31/2000 hadn't been tested and this week in the US when all the 7/11 stores POS system though 01/01/01 was 1901, and that all the credit cards were invalid. I think that cron is broken because it doesn't handle DST shift properly. Just my opinion though, and we seem to get plenty of those around here =) ISTR that at least in the last couple of years some of the OSes handle the DST shift properly. eg - not running a job twice for example. I've not had a problem on BSD - but then I don't have anything scheduled in those hours except things that run every hour. -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
