[fbsd_questions] mac and windoze formats
howdy, folks --- this may be a stupid question, but, i figure that it is better to ask than to assume. premise: i was looking at a retail site that is offering a dvd_archive of every issue of a particular magazine back to its beginning, many decades ago [ these have become popular, lately ]. usually, i put these things on my windoze_box, until it was no longer new enough. then, i looked for linux [ aka, elf ] compatability, which also works. well, it has finally happened. something i want is only available for windoze and os_x. research: now, freebsd handles all sorts of elf; but, mac is not elf, it is derived from mach [ a long_unused word from my youth ]. so, this question is about emulation. i found the section in the faq and in the handbook on elf, but, there is no mention of mac, osx, mach or anything else that is not elf, not even wine. i found a recent _questions post that suggested that there is no current ability to run a mach-o binary. because no one challenged this assertion, i take it as true. q:where do things stand regarding the future ability to run either a windoze or mac binary [ as these are the general_public's notion of a computer ] ? q:would the present situation be described as closer to real_soon_now ! , to are you kidding ? or to somewhere between these two endpoints ? happy everything, to everybody, all of the time, even to those who don't celebrate anything, at any time. rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [fbsd_questions] mac and windoze formats - a
chuck --- thank you. your clarity is warmly appreciated. fyi, would that these --were-- pdfs. regrettably, these are not computer people; they are print_the_magazine_on_paper_and_sell_the_paper people. the usual approach is to install a binary on the box that, at the least, requires the presence of the optical_disc in the drive to operate. well, that's what happens when one charges money for something that is easily duplicated. their loss; i didn't include this item in today's order for some single_issues. ciao. rob Chuck Swiger wrote: On Dec 8, 2010, at 12:12 PM, spellberg_robert wrote: premise: i was looking at a retail site that is offering a dvd_archive of every issue of a particular magazine back to its beginning, many decades ago [ these have become popular, lately ]. If the archive contains this magazine in a common format like PDF, you can view such under nearly any platform (including FreeBSD). usually, i put these things on my windoze_box, until it was no longer new enough. then, i looked for linux [ aka, elf ] compatability, which also works. ELF is a binary file format. It's used by Linux, FreeBSD, Solaris, and other platforms. research: now, freebsd handles all sorts of elf; but, mac is not elf, it is derived from mach [ a long_unused word from my youth ]. Yes, MacOS X uses the Mach kernel from CMU, also used by NEXTSTEP. The binary file format for the Mac is called MachO. so, this question is about emulation. i found the section in the faq and in the handbook on elf, but, there is no mention of mac, osx, mach or anything else that is not elf, not even wine. i found a recent _questions post that suggested that there is no current ability to run a mach-o binary. because no one challenged this assertion, i take it as true. It is. q:where do things stand regarding the future ability to run either a windoze or mac binary [ as these are the general_public's notion of a computer ] ? You can use emulation software like VMWare 3 to run a Windows environment under FreeBSD; however, that won't let you run MacOS X or Mac programs. Regards, ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[fbsd_questions] 7.3 , 8.1 , je_malloc , mmap , brk , gcc
greetings, all --- this is a follow_up to my recent inquiry. a while back, i took apart mr. kamp's malloc(3), so, i have a fair idea of its operation. i have not, as yet, done the same for its replacement. therefore, treat these questions, regarding je_malloc(3), as coming from a user. q:given that brk(2) and sbrk(2) can fail due to an interaction with the swapper, does mmap(2) suffer from the same issue, given that it has to look up the things that brk(2) already knows about ? q:if mmap(2) does not have this problem, then does that mean that if i use only the m option to je_malloc(3), it will fail only when it --really_is-- out_of_memory, including insufficient data_size resource_limit [ increasing resource_limits are a separate topic ] ? q:if mmap(2) --does-- still have this interaction, then should i continue to check resource_limits to be sure ? separately, q:is gcc(1) still at 4.2.1 ? q:if so, what plans are there for which next_version and when ? tia. rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [fbsd_questions] i386 fbsd_platform vs amd64 fbsd_platform, on intel_64_architecture cpu
[ note that there is a new question, about half_way down ] first, i thank you, most sincerely, for the time that you took to type detailed responses. this is most helpful. second, let me posit that there exists no perfect notation, so, i err on the sides of readability and clarity, at the expense of economy [ or, rather, my perceptions of these ]. to this end, i do several things. i connect the components of a multi_word noun_phrase with under_score characters, to aid the differentiation of adjectives from nouns. similarly, i separate the components of combination words. i use doubled under_scores, if a component is under_score__connected. i use the neutral_double_quote character to repeat, verbatim, the words of another, to indicate odd word_usage and to emphasize differences. i use commas liberally, to set_off subordinate_clauses and to indicate pauses, --but--, i do not put a comma before or after a conjunction [ except as part of a comma_pair, used with a subordinate_clause ]. i italicize or under_score word as --word--. outside of prose, i put white_space between tokens [ don't you wish everybody did ? ]. there are other rules [ hmmm ... , i ought to publish these ]. note that i am, in_frequently, in_consistent in my rule_application. third, i will address your points in_line. note that my text is delimited by one blank_line above and three blank_lines below. Dan Nelson wrote: In the last episode (Oct 05), spellberg_robert said: well, i looked at questions back to the beginning of august. on aug_09 i found a thread that suggests the following questions. i have, since, examined subject_lines back to the beginning of june. i have researched other places, also. You might want to just use i386 and amd64 instead of making up your own terminology (i_386, intel_64, amd_64, etc). not mine. intel_64 and intel 64 and intel64 are synonyms for a concept found here: http://developer.intel.com/technology/intel64/index.htm i_386 and i386 are synonyms for a concept found, as one example, here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/8.1 amd_64 and amd64 are synonyms for a concept found, as one example, here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.1 note that the words on the subject_line are spelled i386 and amd64, for the benefit of those who use freebsd.org's mailing_list__archive search_engine. note that i have revised the subject_line, in an effort to be clearer, regarding jargon. Note that Intel has chips that support two competing 64-bit instruction sets: ia64, which is used by their Itanium line, actually, i am aware of this; however, just because i did not discuss it does not mean that you can assume that i was not thinking about it. mea culpa. being explicit is a_good_thing. [ i don't need to explain the acronym assume, do i ? good. ] and amd64, which originated on AMD chips but Intel adopted for their 64-bit-capable x86 chips (Xeon, Core etc). I'll assume that any time you say intel_64 or amd_64 you really mean amd64, no. intel_64 and amd64 are as defined, above. one is a manufacturer's proprietary architecture; the other is a freebsd_release_platform that runs on several substantially_similar proprietary architectures, which belong to different manufacturers. since nobody uses Itaniums :) if they used itania in redmond, ... . for a given release of freebsd, q:is it that the version labeled i386 contains only 32_bit headers and source, which creates the 32_bit version of freebsd, as well as 32_bit versions of what i write, which will run as 32_bit code on either i_386, intel_64 or amd_64 ? Yes, assuming you have COMPAT_FREEBSD32 in your kernel config (which GENERIC has, so most people have it). i will look into COMPAT_FREEBSD32; i have not built a kernel since 4.early. i would take out stuff that i did not have installed and, then, it would get bigger. now, i change hardware so frequently, it is better to include probes for everything. q:is it that the version labeled amd64 contains only 64_bit headers and source, which creates the 64_bit version of freebsd, as well as 64_bit versions of what i write, which will run as 64_bit code on the intel_64 and the amd_64, but, not the i_386 ? Yes. i think we understand one_another here; i could have been clearer. i was trying to make a distinction between products manufactured by intel_corp, amd_corp and others, all_of_which were derived from intel's original 80386 [ released, circa 1985 ], whose architecture intel named ia-32 [ synonyms of ia32 and ia_32 ], which, mostly, but, not_exactly, used the same machine_code, to produce the same instruction_results [ an analogy would be firefox versus the high_priced spread, regarding html ]. my cpu distinction was between intel's ia_32 and intel's intel_64
[fbsd_questions] i386 vs amd64, on intel_64
howdy, y'all --- these may be stupid questions and, if so, i am prepared to slap my forehead with the palm of my hand. i recently acquired my first batch of intel cpus with 64_bit integer registers [ celeron 440 ], specifically for the 16 registers and the potential for a truly_gargantuan datasize. intel has called this many things, currently intel 64 architecture. to me, this is just a bigger, faster 386, just like my 486 and several flavors of pentium [ now, all retired ]. i have never owned an amd cpu. this may be the source of my confusion. what prompted my recent searches was the observation, while working on my killer_app, in machine/types.h, as i recall, that the size of an intptr is 32_bits. [ i am aware of the gcc double_integer implementation of 64_bit data_integers. that is not the issue; i want big memory. ] i want my app to exist in two sizes, small [ 8_, 16_ and 32_bit integers and 32_bit pointers ] and large [ 8_, 16_, 32_ and 64_bit integers and 48_bit pointers ], the choice between the two being made by my users, according to their needs. my objective is to produce both versions, simultaneously. so, i have been looking at many pages, mostly at freebsd.org [ http and ftp ] and gcc.gnu.org, as well as some others [ release notes, in particular ]. the last question is the big one. consider a dvd_image [ to pick an approach ] of a release to be found on ftp.freebsd.org. q:if the release_name includes the string i386, am i restricted to 8 32_bit registers and 32_bit pointers, notwithstanding its installation on an intel_64 platform ? next, from what i have been reading, those releases whose names contain amd64 not only are for amd cpus, but, also, are for the intel_64 variant [ no doubt, probing the cpu for its feature_set ]. q:if i install an amd64 version on an intel_64 platform, am i restricted to 16 64_bit registers and 48_bit pointers or can i compile for both cpu_models [ perhaps, with nothing more complicated than a compiler option ] ? please cc. in advance, thanks big_time. rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [fbsd_questions] i386 vs amd64, on intel_64
hmmm ..., you did not answer the question that i asked. per your statement, on i386, amd64 or both ? David Brodbeck wrote: On Mon, Oct 4, 2010 at 12:51 PM, spellberg_robert email...@emailrob.com wrote: q:if i install an amd64 version on an intel_64 platform, am i restricted to 16 64_bit registers and 48_bit pointers or can i compile for both cpu_models [ perhaps, with nothing more complicated than a compiler option ] ? Take a look at gcc's -m32 and -m64 options. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [fbsd_questions] i386 vs amd64, on intel_64
aha ! this relates to what i found in machine/types.h, on my existing i386 version of freebsd on my intel_64 hardware platform. i will look into the questions archive. meanwhile, back at the ranch, does this mean that i need the amd64 version of freebsd to get the right headers ? Dan Nelson wrote: In the last episode (Oct 04), David Brodbeck said: On a 64-bit system, if you build a binary with the -m32 flag, it should run on both i386 and x86-64 systems. A binary built with -m64 will only run on x86-64. Does that help? Actually, -m32 on amd64 won't generate usable binaries, since /usr/include/machine/* are all amd64 headers and you end up with things like struct FILE with wrong-size elements. There was a thread a few weeks ago discussing this. If you need to generate 32-bit executables, you'll need to do it inside an all-32-bit chroot or a virtual machine. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [fbsd_questions] i386 vs amd64, on intel_64
well, i looked at questions back to the beginning of august. on aug_09 i found a thread that suggests the following questions. for a given release of freebsd, q:is it that the version labeled i386 contains only 32_bit headers and source, which creates the 32_bit version of freebsd, as well as 32_bit versions of what i write, which will run as 32_bit code on either i_386, intel_64 or amd_64 ? q:is it that the version labeled amd64 contains only 64_bit headers and source, which creates the 64_bit version of freebsd, as well as 64_bit versions of what i write, which will run as 64_bit code on the intel_64 and the amd_64, but, not the i_386 ? q:if a i386 version is installed on an intel_64 platform, then the pointers are 32_bits_wide, no matter what ? q:if i want to produce both 32_bit and 64_bit versions of my killer_app, then i need two machines, one a 32_bit or a 64_bit running i386, the other --only-- a 64_bit running amd64 ? q:given that i have intel_64 hardware, do i need to start acquiring the amd64 versions of the releases, rather_than / in_addition_to the i386 versions ? q:given that --i-- am committed to 64_bit hardware, perhaps, i should give up on the i386 versions of the releases and require my users to spend us$_300 on 64_bit hardware [ it would save a large number of conditional_compilation directives; nudge_nudge, wink_wink, say no more ] ? again, i thank you for your assistance. rob Dan Nelson wrote: In the last episode (Oct 04), David Brodbeck said: On a 64-bit system, if you build a binary with the -m32 flag, it should run on both i386 and x86-64 systems. A binary built with -m64 will only run on x86-64. Does that help? Actually, -m32 on amd64 won't generate usable binaries, since /usr/include/machine/* are all amd64 headers and you end up with things like struct FILE with wrong-size elements. There was a thread a few weeks ago discussing this. If you need to generate 32-bit executables, you'll need to do it inside an all-32-bit chroot or a virtual machine. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[ fbsd_questions ] tar(1) vs. msdos_fs: a death_spiral ?
greetings, all --- i confess that this one has me flummoxed. the short question: does tar(1) spit_up when extracting onto an msdos_fs hard_drive ? [ i tried the mailing_list archives tar AND msdos, for -questions, -chat, -bugs, -newbies, -performance ] [ other research as indicated ] i have no problem using tar(1) on ufs. large files, small files; if i am on ufs, everything is fine. i have been creating tarballs from medium_size msdos_fs drives, also. this worked fine. i would check them by extracting into a ufs root_point. no problem. this week, i tried to do something new. i wanted to take a tarball, already on ufs, that was created from an msdos_fs drive and extract it onto an msdos_fs drive. this, to me, actually seems like a reaasonable idea; but, what do i know ? well, it starts out just fine, but, it rapidly degenerates into what is, normally, infinite_loop land. when ps(1) says cpu_% of 1%, 2%, 5%; ok, it is an active process. in about ten minutes, tar(1) enters 90% cpu. after 20 minutes, 99%. i does not matter if X_windows is running. foreground or background process, no difference. it seems to be working correctly because the error_file is always of zero_size. i suspect that if i left it alone, after a few days, it would finish. some details [ everything is ufs, using 8kB/1kB, except /mnt, which is clustered as indicated; of course, the tarball is not named ball, nor is the path, to the tarball, named path, but, then, you knew that ]. mkdir /path_c mkdir /path_c/88_x mkdir /path_d mkdir /path_d/88_x mount -v -t msdos /dev/ad1s1 /mnt [ fat_32, about 6_GB, 4_KB cluster, the c:\ drive, primary partition. ] cd /mnt ( tar cvplf /path_c/99_ball.tar . /path_c/90_cvpl.out ) /path_c/91_cvpl.err[ real time 16m 07s, exit_status 0 ] cd / ; umount /mnt mount -v -t msdos /dev/ad1s5 /mnt [ fat_32, about 12_GB, 8_KB cluster, the d:\ drive, extended partition. ] cd /mnt ( tar cvplf /path_d/99_ball.tar . /path_d/90_cvpl.out ) /path_d/91_cvpl.err[ real time 20m 15s, exit_status 0 ] cd / ; umount /mnt cd /path_c/88_x ( tar xvplf ../99_ball.tar ../92_xvpl.out ) ../93_xvpl.err [ real time 08m 11s; exit_status 0 ] diff ../9[02]* [ exit_status 0; the tables_of_contents are the same ] ls -l ..[ visually inspect the error_files to be of zero_size - verified ] cd /path_d/88_x ( tar xvplf ../99_ball.tar ../92_xvpl.out ) ../93_xvpl.err [ real time 12m 37s; exit_status 0 ] diff ../9[02]* [ exit_status 0; the tables_of_contents are the same ] ls -l ..[ visually inspect the error_files to be of zero_size - verified ] [ note that this approach works; it is a good excuse to refill my coffee_cup. ] [ physically replace the source hard_drive w/ 80_GB capacity, 32_KB cluster, primary_partition only, virgin hard_drive. this destination hard_drive was fdisked and formated yesterday_morning; this drive was scandisked yesterday for 12 hours, using the thorough option, it has zero bad clusters [ i wanted to eliminate the drive as the problem ] ]. mount -v -t msdos /dev/ad1s1 /mnt mkdir /mnt/path_cc cd/mnt/path_cc ( tar xvplf /path_c/99_ball.tar ../92_xvpl.out ) ../93_xvpl.err[ started this at 18:05_utc, it is now about 21:35_utc; the toc_file, from the 8_minute extraction above, has 87517 lines in it; the current toc_file has only 12667 lines. ] [ this is the second hard_drive i have tried this on, this week; i will probably kill the process as xterm is being updated about 8 seconds apart, now. ] on the first hard_drive [ i have not done this on the second drive, yet ] i noted that i had a successful extraction on the ufs drive. not being the smartest person around, i had, what i thought to be, a --brilliant-- idea, what if i try a recursive copy of the successful extraction ? this is interesting; the recursive copy started_out like gang_busters, then, just like the extraction, slowly bogged_down to 99%_cpu. hmmm..., two different msdos_fs hard_drives, two different normally_reliable utilities, same progressive_hogging of the cpu. this makes me wonder about the msdos_fs hard_drive, which is, rapidly, becoming the only remaining common factor. ok. i tried the mailing lists. right now, i am web_page searching; tar(1) seems to be slow in some situations, but, i have not, yet, found --this-- situation. also, in reading the
[ fbsd_quest ] file_caching and hd caches
howdy, y'all --- so, i was looking over the offerings of the on_line retailing usual suspects, when i got to thinking: q: to what extent does freebsd cache recently_used hard_drive files ? q: under freebsd, to what extent are hard_drive internal_caches and their sizes [ e. g., 2mb, 8mb, 16mb ] important ? i am not so much looking for a history_ and theory_of_operation as i am looking for a yes/no to the question: q: should i pay up for hd_cache, if the other hd parameters are the same ? something else that i just thought up while typing this: q: are hd internal_caches non_volatile ? id est, q: do the cache contents survive a power_cycle ? [ some supplementary fyis: yes, i am aware that hd access_times are a relative eternity to a chip_set's hd_port. i am not thinking about ram_size and swap_size and thrashing; all of my boxen have plenty of ram. i know i have to read it in the first time. rather, i am thinking about opening and reading some file that i recently wrote and closed. ] in advance, i thank you. please cc. rob ps --- remember, slavery sucks; so, have a happy pesach. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [ fbsd_quest ] file_caching and hd caches
thanks, warren [ love your dot_com, btw ] --- Warren Block wrote: On Wed, 8 Apr 2009, spellberg_robert wrote: howdy, y'all --- so, i was looking over the offerings of the on_line retailing usual suspects, when i got to thinking: q: to what extent does freebsd cache recently_used hard_drive files ? To the extent that RAM is available. q: under freebsd, to what extent are hard_drive internal_caches and their sizes [ e. g., 2mb, 8mb, 16mb ] important ? It depends on workload. i am not so much looking for a history_ and theory_of_operation as i am looking for a yes/no to the question: q: should i pay up for hd_cache, if the other hd parameters are the same ? Again, depends on workload. Also the difference in price for relatively small differences in cache RAM on the hard drive. now that i have a handle on today's prices, the choice of retailer is very important. it also appears [ from my reading of manufacturer's literature ] that the hd internal_cache is used as a write_buffer for the benefit of the chip_set, then the drive can take its own sweet time writing to its notion of sectors. therefore, for a mobo that is stuffed_to_the_gills with ram [ relative to the apps that it is running ], if i read you correctly, then reads will tend to come from mobo_ram and the hd_cache is mostly a write_buffer. i suspect that the hd_cache would be more important for an os that doesn't do its own caching [ until its notion of idleness occurs ]. something else that i just thought up while typing this: q: are hd internal_caches non_volatile ? No. not surprised. id est, q: do the cache contents survive a power_cycle ? No. You may want to look at SSDs. understood. [ some supplementary fyis: yes, i am aware that hd access_times are a relative eternity to a chip_set's hd_port. i am not thinking about ram_size and swap_size and thrashing; all of my boxen have plenty of ram. i know i have to read it in the first time. rather, i am thinking about opening and reading some file that i recently wrote and closed. FreeBSD is pretty good at that. For example, reboot and start Firefox. Then close it and start it again. understood. There may be ways of prioritizing what's kept in cache, although I don't know them. not important. thanks for the thought, though. to summarize, it looks like, for freebsd, i should get a good price from a reputable retailer on a high_quality product from a reputable manufacturer. then, i can save my worrying_time for really important subjects, like the determination of the correct yardarm height for the hanging of pirates. -Warren Block * Rapid City, South Dakota USA nice part of the country, that. chicago north western territory. rob mchenry county, illinois ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [ free_bsd_questions ] selecting a cpu heatsink / fan combo [ a ]
Mark Picone wrote: it's that i don't recognize so many of the manufacturers names. some look familiar, but they might just be similar to something i remember from long ago. q: would anyone care to wax rhapsodic about any manufacturer with whose heatsink / fan combo product[s] they have had good success ? IMO: Pure copper zalman heatsink/fan combo (cant go wrong) thank you, mark. i saw your response first thing this morning. this was one of the names that looked familiar. several retailers have these. attempting research on the product line earlier today, i got more info from them than i did from the manufacturer's web_site [ my pet peeve: more presentation, less content ]. rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [ free_bsd_questions ] selecting a cpu heatsink / fan combo [ b ]
Chuck Robey wrote: q: would anyone care to wax rhapsodic about any manufacturer with whose heatsink / fan combo product[s] they have had good success ? OK, I will. I got taught, in extremely clear fashion, about the direct linkage between keeping the temperatures low and even, and the ultimate reliability of your system. I won't go into the war story, but most everyone knows this is true, anyhow. I won't go into the fan either, because it's my personal opinion that there are a large selection of good fans. The item I want to extoll is the Ultimate 120 heatsink from Thermalright. Huge heatsink, and the 120mm fan that you get separately mounts on the _side_, not the top, like you might be used to. One look at this, at the great engineering ... well you might possibly find something else as good, but I bet you'd not be able to find anything better. Get that installed, and you can be really certain you didn't short on the CPU cooling. thank you, chuck. wowie, zowie ! --passion-- !!! this tells me something. yes, getting the heat out is the point. 120 mm ? that's an optical disk. bet it's a blowhard. i'm a fool for great engineering. i'm also a fool for a myrna loy film, but, i digress. on the side, eh ? nothing like trying out a new position. this was followed, very soon after, by marc coyles: thank you, marc. 1 - Don't use tip of finger to apply thermal goop unless finger is within a plastic bag. Grease off your skin will detract from the efficiency of the Thermal Bond, and seeing as the TIM bond accounts for a HUGE proportion of a processor-cooling-solution's c/w rating, it's better to pop finger in a bag, and then apply compound. [ wistful sigh ] another fond memory from my youth: gone forever. [ another wistful sigh ] well, that's what we were doing at the big m in schaumburg. it was almost thirty years ago. what did we know ? we were younger and stupider. besides, most of the watts were going out the antenna [ that would be aerial, on your side of the pond ]. it wasn't any good for clothing, either. 2 - Best of the best is still Thermalright, but there is a price premium as always. I generally go with their Ultra120 Extreme as it supports all sockets and all CPUs on the market, so you won't have to bin it if you switch to something else at a later date... And partner it with a decent 120mm fan of your choosing according to your noise preference. Personally I stick with Nexus fans as they're nice n' quiet... another vote, which is why i combined these responses. yeah, well, something that works well is worth something, just to get rid of the aggravation factor. keeping the number of line_items in my qpl few is always good. i'll look into those. you know, i've been ruminating on this point. i'm starting to think that quiet is more important to me than i had previously thought. i do like to put a bunch of 19th_century chamber_music discs into the changer. The above combo is currently sitting atop a Q6600 cpu in my recording studio system and keeps it at 40 deg C full-load in total silence. If you want better cooling, then find a more powerful fan. the recording studio is the acid_test for quiet. [ ever see the size of the box that a three_color_technicolor camera was in, back in the 1930s ? those things were --loud--. two supply reels, two take_up reels, at right_angles to a beam_splitter. no wonder the actors had to loop their dialogue so much. ] that 40 degree number gets my attention. why, that's barely warmer than i am ! 3 - Meh - Thermal Compound performance is much debated, and any testing done on it isn't done to a sufficient quality to give reliable results. Either way, the Thermalright Heatsinks all come with goop that is plenty good enough for most purposes. on this point, i was more concerned if someone had had a bad experience with stuff that just doesn't work. rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [ free_bsd_questions ] selecting a cpu heatsink / fan combo [ c ]
Chris Whitehouse wrote: If you haven't already bought your cpu you could check out how much heat different cpu's produce, they vary quite a lot. Lower power = lower heat production = less stress on heatsink/fan (and = lower electricity costs). Also the overclockers websites and forums usually have opinions about heatsinks. Chris thank you, chris. no, i haven't. i hope to get the cpu order out by friday or mon^H^H^Htuesday. i spent all day today on [ mostly ] intel's web_site pointing, clicking and downloading. all very true. i've been looking for such info but intel's web_site isn't too geeky. i --have-- downloaded new copies of data_sheets, though, so, i have some reading to do. [ this internet thing has potential; i just don't request data_books from manufacturers, anymore. ] keeping my electric bill low is high on my list. it is my understanding that the 65_nm p4 consumes less power than the 90_nm p4. i am of two minds about the gaming community. on the one hand, they --do-- push the cpu hard. it's a form of testing. so, their opinion is worth something. on the other hand, i tend to use multiple boxen to split_up the responsibilities, so, my boxen tend to be idle, more so than those of most others, and, therefore, my environment just isn't the same as that of the gamers. apples and oranges. i used to think that overclocking meant 5_% or 10_%. then, today, i saw one report of a 3200_mhz cpu being clocked at over 8000_mhz ! i have, absolutely, no idea if this is, at all, possible. i do know that --my-- cpu will clock within 1_% of rating. almost immediately after the above, this arrived. Wojciech Puchar wrote: If you haven't already bought your cpu you could check out how much heat different cpu's produce, they vary quite a lot. Lower power = lower heat production = less stress on heatsink/fan (and = lower electricity costs). Also the overclockers websites and forums usually have opinions about heatsinks. and of course - make sure then that your motherboard doesn't overclock by default. no, i'm not joking, it's true but it sounds like a joke. thank you, wojciech. ok, let me revise and extend my remarks, i --think-- it will be within 1_% [ it's a plan, anyway ]. i have --never-- heard of this one. maybe, it's because i check every mobo setting at installation time ? are you certain that this isn't propaganda from the joke in redmond ? please explain. rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
[ free_bsd_questions ] selecting a cpu heatsink / fan combo
greetings, all --- this isn't exactly a free_bsd question, --but--, since free_bsd is popular w/ the i386 crowd and there are many rugged individualists on these lists who like to roll their own, i figure i'll get way less hyperbole and more practical experience here, than at some of the places i've visited today. i had always been able to find the cpu / heatsink / fan as a sub_assembly, so, i didn't have to deal with this issue. i'm making some new boxen to replace some 800mhz_p3, 256mb units which will be re_assigned. i found a mobo i like; d_ram just keeps getting cheaper; etc., etc. i even found a processor that appeals to me, but, it's oem. it's the p4 641 which is 3200 mhz, 65 nm, 775 case. the mobo maxes out at 2048mb, which is just fine. these are probably the last single_core boxen that i will build. now, back in the day, i had acquired the skill of using my index finger to properly apply that white_stuff, from the good folks at wakefield, to the tops of uhf pa transistors, from the good folks at motorola. no, this isn't a case of fear. it's that i don't recognize so many of the manufacturers names. some look familiar, but they might just be similar to something i remember from long ago. q: would anyone care to wax rhapsodic about any manufacturer with whose heatsink / fan combo product[s] they have had good success ? q: is there a short list of manufacturers who are generally accepted as producers of reliable products [ as is, e. g., antec, for cases and power_supplies ] ? q: conversely, are there any manufacturers with justifiably bad reputations ? i have seen several diameters described as appropriate for the 775. q: should i prefer any particular size ? wakefield is still around, but there are other names. q: are there any opinions, pro or con, about thermal compounds ? noise_level is not a criterion in this situation. i'll err on the side of more cf/m. money doesn't appear to be an issue. i've seen a range of $_10 to $_130, so far, but, most are $_15 to $_30 or so. thanks in advance for any advice. please cc. rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: extracting 7_bit_ascii from ms_word files
thanks to everyone for their assistance. thanks, especially, for reports of personal satisfaction with a particular solution. it appears, now, that i had found everything that there is to be found, currently. without the feedback, however, i would not know that. i will give these ideas a whirl. happy coding to all and to all a good compile. rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
extracting 7_bit_ascii from ms_word files
greetings --- i finally ran into a situation where my existing approaces are no longer satisfactory. i never bought office. i have a twelve_year_old version of wordperfect from [ at that time ] novell that still works just fine [ i first used wordperfect in the early 1980's; why change ? ]. it doesn't recognize new ms formats. sometimes, i can use wordpad on my win_98_se box that still works; but not always. my lawyer insists on hard_copy and snail_mail, so my principal application is, actually, obviated. if files only had a few dozen lines, i could edit them by hand in vi. i simply did not have enough situations to demand a more sophisticated approach; now, i do. i started here [ over 1000 entries ] http://www.freebsd.org/ports/textproc.html where i found nothing relevant under doc and where i found word2x, which looks --really-- old and where i found wv, which seemed more promising. searching the questions and newbies mail archives, i found antiword and catdoc, but this is from 2002_feb. while reading up on wv, i found this http://www.abisource.com/ which caused me to search. i found this http://www.freebsd.org/cgi/ports.cgi?query=abiwordstype=all both of these seem to jog my memory, but my memory my application is to exchange text files, by e_mail, with someone who thinks ms products are the be_all and end_all [ after all, if everyone is spending thousands of dollars on software, just like he is, what makes me so special ? ]. i anticipate acquiring other people like this in the near future, so my time on this just may be well_spent. in general, these are not the kind of folks who find manipulating files intuitively obvious. yet, i may find that i have to give them special instruction. i am not looking for something wonderful, just reasonably competent and reasonably current. if, in addition to my desired direction, i can convert a 7_bit_ascii to a .doc file for his benefit, that's some further whining that i can avoid. i strongly suspect that, as soon as this becomes a solved problem, ms changes something critical, so this may be a fool's errand. none_the_less, i'll give it a try. which one or several things are generally accepted for this format_conversion task ? is this abiword one of them or do i seek something else ? if something else, can someone point me in a useful direction [ whether or not it is something i have named ] ? while 6.2 and, soon, 7.x are de rigeur, if it works on 4.11 [ very long story ], that's a plus. thanks whole bunches in advance. [ please cc me, as my attempt to re_subscribe to the list as a courtesy doesn't seem to be taking. ] rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: why can't i turn off fast_time? [ success w/ post_mortem ]
greetings, all --- i've been meaning to write a whole lot sooner. too many non_maskable interrupts. thank you, matthew. thank you, duane. as it eventuated, i spent all day for four days, mar_01_thu through 04_sun, working on this. most of the results occurred thursday, but i wound up being snowed in on friday, most of which i spent hacking. saturday and sunday were spent refining and exploring source for use in alternative solutions to be implemented when i have some free time. duane --- the solution you proposed is perfect. further, it is truly elegant. i only spent about three minutes on it thursday night. after all of the various things that i had tried, it is the approach that i chose to implement. matthew --- i recognized your name from other sources in my possession, so i was heartened to see you respond. although your solution did not exactly address the problem as stated, it was sufficiently close to something that i had tried that i chose to work with it first. i will summarize. i selected a victim^H^H^H^H^H^Htest machine. my /etc/localtime [ well, the last one i left there last summer ] was .../Etc/Europe/London. my TZ was set to gmt0. i rebooted and verified that the mobo was on utc. i removed TZ. i copied Factory, London, New_York, Indianapolis, Chicago, Denver, Phoenix, Los_Angeles, UTC, GMT, GMT+5, GMT+6, GMT+7 and GMT+8 to /etc, giving them names that are substantially similar, but which start with localtime. for the benefit of ls -a l*. i would reboot frequently to check the mobo clock and to set the date to march or june. rebooting also let me verify the timestamps being logged, in real time, during startup and shutdown. i think these use /etc/localtime but not TZ. i stopped rebooting once i verified what date(1) did to the mobo clock. i discovered that /bin/tcsh resets the timestamp percent_escapes for its prompt variable only at login, while date(1) checks on each invocation. i believe this to be a major source of my confusion. i believe another source was not making a distinction between date and date -u [ i thought i was in utc, but maybe i wasn't always ? ]. further, to me, utc is local time and the other zones are all remote time. however, these routines think the user's zone time is local and utc is remote. also, to me, chicago is london MINUS six. einstein was right; it's all about one's frame_of_reference. i did most of my testing with Chicago, GMT+6, GMT and UTC, with winter and summer dates. once i was satisfied, i copied GMT+6 to a new file i named CST. using vi, i changed the string to CST and the length to four. it's a good thing the length wasn't ten [ hey, it's a kloodge ]. thoughtfully, vi added the missing newline at the end of the line. checking the source for localtime(3), i don't believe the extra byte will be a problem. i'll fix this when i have some free time. while localtime(3) itself checks /etc/localtime, i get the idea to create a routine that will read other files in localtime format, so that i can have utc, local standard time, local legal time and [ thanks to a messy formula in dershowitz and reingold, calendrical calculations, cambridge press, 1997 ] apparent solar time [ woo_hoo !!! ], all at the same time. i hacked similar files for EST, MST and PST. all of these have names beginning with /etc/localtime.. then, i ln -f to the file of interest. later, looking at the link count, i can see immediately which file is /etc/localtime. three examples of my naming convention [ i'm big on filename completion, e. g., l*zm6 ]: /etc/localtime.m6_.usz.etc.gmt+6.zm6 /etc/localtime.m6a.usz.america.chicago.zm6a /etc/localtime.m6h.cst.zm6h usz is short for usr/share/zoneinfo. h is the hacked file. zm is zulu minus. i also added a file /etc/localtime.readme.r, wherein i explained all of this to myself. for the record, i have stopped using TZ. now i know how to do localtime format files, so i don't think i need it. i never used tzsetup(8). i confess that there --was-- some serendipity. for example, about midway through thursday, the most productive question i asked myself was, why is this off by seven hours when it should be off by five?. if matthew had told me GMT instead of GMT+6, i would have been +/- an hour around zero hours instead of being around six hours. then, i would have chalked it up to being backwards instead of forwards instead of forwards instead of backwards [ or is it the other way around ? ]. i think the reason the existing documentation is insufficiently clear [ and i went through a lot of it ! ] is because the authors assume [ correctly, for the overwhelming majority of people ] that the user wants their timestamps in local legal time. when an eccentric like me comes along wanting to do something unanticipated [ i don't set my clock ahead, the outside world starts running early ], it becomes a challenge. perhaps,
why can't i turn off fast_time?
greetings, all --- as long as folks are paying attention to this whole time zone foolishness foisted on us by congress [ as if they don't have --real-- work to do; but, i digress ], it seems to be a good time to inquire about my pet peeve. please note: this is the --one-- thing about freebsd that --really--, and i mean --really--, hacks me off. i have yet to figure out how to turn off the warm_weather fast_time bug^h^h^hfeature. i am outside chicago, so i am six hours earlier than london. i choose to not observe fast_time any more than absolutely necessary. twice a year, these nimrods in washington actually expect me to drop what i am doing and go around everywhere and change the clocks. to put not too fine a point on it, i refuse. [ quite by accident, i discovered that this eliminates what i call solar_shock. now, when others grumble on monday about the sun not being where it was on friday, i laugh. ] the first thing i did was to rtfm. then, i selected a box on which to experiment. the method that seems to work most successfully is to tell the box it's in arizona. this would be great if i were in, say, laramie, but, i haven't moved there, yet. so, it's a little irritating. then, i thought i would be exceedingly clever by creating the missing file that would be logically found between arizona and indiana, using those files as templates. surprise, surprise, they're in binary; just like --windoze--. having read eric raymond's art of unix programming, i agree completely that configuration files should be in human_readable form, not encoded in binary, mega_corp style. i have put off playing with this approach. last, i tried the environment variable trick, both for the local zone and for utc [ surely, i can make the box do everything in utc, i thought ]. sha_ZAM!!! i thought i had struck the mother_lode. everything was working just as i wanted. i smiled smugly to myself. euphoric, i arose from my throne [ no, silly, the other one ], outstretched my arm and commanded shutdown -h now. alas, logged messages were timestamped off by one hour. i was crestfallen. this suggests that the mobo clock is on utc [ or something ], fbsd is kloodging this into local fast_time and, then, the environment variable is re_kloodging the kloodge to display what i want to see, but shutdown doesn't honor the re_kloodge. or some such. this is the point where i gave up. i recount the above from memory. the last time i tried to get this right was about a year ago. windoze gets this right [ this is one of the few times when i prefer windoze; think about this ]. i cam select a time_zone, then uncheck the observe fast_time box. no problem. but, my 'nix boxen have their own agenda. i solved this by setting them to what displays as utc and what produces the right epoch_offset, then i calculate the correct timestamps myself in my apps. i simply accept that my timestamps are right and some of the system generated timestamps are wrong. c'est la guerre. -- i wouldn't bother writing except that congress decided to meddle, so some really_smart_people are paying attention. all i want is to be able to set my boxes to utc, with no fast_time, and to have my apps and all of the other apps agree on what the clock says, at --all-- times. it would be a plus if there were binary files for the 4 contiguous us time_zones [ 2 of these already exist ], --if-- that's the trick to getting what i want. [ i suspect that it would be considered a plus by others elsewhere on the planet if such files existed for all 25 hourly zones and the several whose offset is not a multiple of 60 minutes. unlike mowing the lawn, this job well done would not have to be done again. ] it would be a really big plus if non_textual config files were eliminated, but i suspect that this is a bigger project than most folks have time for right now. [ if there is interest, since, at least, --i-- care about this, perhaps i could take this on, but i'm full_up for the next several months. however, it strikes me that this might make a useful project for some one or more of my students. any thoughts? ] --- thanks for letting me inquire. if anyone thinks this sufficiently worthy of either positive or negative response, please cc me as i am not subscribed to -questions. rob spellberg woodstock, illinois ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
