Linux has many hw/temp sensor monitors and programs (mbmon, lbmon, etc). However (like all major sub-systems in Linux), it does not have a framework to give you a single set of commands that work with all hw/temp sensors out there.
If you want to monitor systemX, you use programX. If you want to monitor systemY, you use programY. And so on. (It's like the horrid mess that is ifconfig/iwconfig/wiconfig/athctl/younameitctl).
On FreeBSD, you just use GEOM Gate (ggated and ggatec) to create a network filesystem/partition. Then you use GEOM Mirror (gmirror) to create a RAID1 array using the local disk and the ggate disk. The GEOM disk layer handles everything for you from there on. No special driver hooks required, works with any and all disks.
If you want to get fancy, you could use ggate to create two network disks/partitions, and graid3 to create a RAID3 array. But the performance probably would be all that great.:)
We do something similar. All the computers that go out to users are locked down with DeepFreeze, with TightVNC installed (with a nice Helpdesk icon on the desktop). We don't do remote management, just remote control and remote support.
The staff just love it. When they have a problem, can't remember how to do something, or come across a strange error message they don't understand, they just call the helpdesk, start TightVNC, give us their IP, and we take control of their desktop. We can show then how to do things, read the error messages for ourselves, watch as they go through the steps. Cuts our call times down, gives the users a greater sense of support, and virtually eliminates the "spend 20 minutes driving to a site to spend 5 minutes fixing the problem" kinds of workorders. Now, the onsite techs are only sent out for major problems.
My first laptop (Fujitsu Lifebook 765Dx) is still going strong. Bought it back in 97 or 98. Sure, it's only a 166 MHz Pentium-MMX with 80 MB RAM, a 2.1 GB HD, 2 MB Trident video, and a 12.1" passive matrix display. But it runs Windows 98SE, FreeBSD, DragonFlyBSD, and Debian well enough. Makes a fun little toy, and a decent firewall box.
My first work laptop (Seanix Sea-Note) is still going strong. Picked it up just about 4 years ago now. It's a Celeron 1 GHz with 384 MB RAM, 20 GB HD, don't recall the video. Runs Windows XP quite nicely.
My primary work laptop (Toshiba Satellite A60) is almost 2.5 years old. It's a Celeron 2.8 GHz w/1 GB RAM, a Radeon 7000 IGP, a 40 GB HD, and a 15" screen. Everything still works on it, and I flip between FreeBSD and Debian on it.
It all depends on what you buy, what you do with it, and how often you drop it.:)
You can get 10K RPM SATA drives from Seagate if you need SATA and want low-latency access. The Seagate SATA Raptor is just a re-packaged SCSI Raptor with a SATA interface.
Celeron processors use the exact same core as the Pentium II, III, and 4 (depending on the model). The only differences between a Celeron and a Pentium 2/3/4 is the size of the L1 and L2 caches, the speed of the L2 cache, and the speed of the frontside bus (the Celeron has less cache, slower cache, and slower FSB).
IOW, Celeron == el cheapo, slow, crappy versions of the Pentium
Where's the fun in that. Over here in Canada (or at least this small town in the heart of BC), the bartenders all use 1 ounce shot glasses to measure the alcolhol. And if you find a bartender that likes you, they keep pouring from the bottle between shots (so a double is actually closer to 2.5 or even 3 ounces).:)
Of course, most of the alcolhol is watered down (shittiest Smirnoff you'll ever taste is in the bar) beforehand, so it all balances out in the end.:)
Some of the bars here use pre-measured mixes for the most popular drinks, and dispense the alcohol from the little guns with a bunch of buttons on it (like for fountain pop).
The nicest, most featureful chat protocol I've ever used with Tribal Force's PowWow. Now there was a chat program worth using. Text chat person-to-person. Chat rooms for multi-person-to-person chats. Chat servers for multi-person chats. Voice chat. The best text-to-speech I've ever heard (and that was on Windows 3.11 and Windows 95B), even now. And a wonderful "group web surfing" feature where one person can control the web browser of all the people in the chat. And it was all done in a 5 MB install.
It's just too bad the protocol was kept so secret, and the marketing was so piss-poor. It was what NetMeeting, MSN/Windows Messenger always hoped to be (and never will be). None of the other chat clients I've used (MSN/Yahoo/AIM/gAIM/Kopete/Trillian/ICQ) compare to that one. The only thing missing, AFAIR, was video, but back then, web cams were still in the multi-hundred dollar range.
And to reach a human being who can actually solve your problem: up, up, down, down, left, right, left, right, b, a, select, start.
Re:busting myths mistakenly
on
Ask The Mythbusters
·
· Score: 3, Interesting
The myth is not that you can hit another arrow (every archer's done that at one point or another), or the same spot twice. The myth is that Robin Hood split the arrow *from nock to tip*. In other words, the entire shaft of the arrow is split down the middle.
While there may be that 1 in a bazillion chance that it would work, all the tests they did showed that it is impossible. The blade of the arrow tip follows the grain in the wood, and unless you have a perfectly straight grain that never hits the edge of the shaft, the arrow will always pop out before it hits the target.
Re:Your show is great fun to watch and all, but...
on
Ask The Mythbusters
·
· Score: 1
The show they did on the various "Put X in the gas tank to kill the motor" myths was one of those "Huh? Who'd a thunk it." shows.
Sugar in the tank... nothing. Bleach in the tank... runs a little rougher the first day, and the rust from the tank plays havoc on the motor the next day. Moth balls in the tank... makes it run better.
But the one that nobody figured on was that cracking an egg into a leaking radiator will plug the leak.
I don't think it's so much that Intel's chips are throttled. The X2 3800+ uses PowerNow, and so it too throttles back and drops voltage down when idle.
You're confusing "throttle" as in power saving and "throttle" as in can't pump enough data to the rest of the system. In essense, you are both arguing the same thing.:)
You obviously did not look very hard, as there is a duplicate of that board available with Opteron support. Uses the AMD 8000-series chipset, and is fully supported under Linux and FreeBSD. We've got several Thunder K8S and Thunder K8SR boards here. Dual-Opteron support, dual-core support (in the K8S-D boards), 16 GB RAM, several 32-bit/33 MHz PCI slots, a couple 64-bit/66/100 MHz PCI-X slots, and 1 64-bit/133 MHz PCI-X slot. Onboard PATA and/or SATA or SCSI support. 10/100 and dual-gigE ports.
Everything your Xeon board has... but with better non-Windows support and faster throughput in every way.:) And a cheaper price tag to boot.
The only thing you have to do when shopping for Opteron motherboards is avoid nVidia and ATI chipsets. Stick to AMD and VIA chipsets, and things work wonderfully.
And another project takes a page out of the KDE development book.:) This is exactly the process taken by the Kontact project. A container application that integrates multiple separate applications into a cohesive whole. You can run the individual apps (KMail, KAddressbook, KNotes, Akregator, Todo, Journal, KNode, etc) as separate applications, or you can run Kontact which provides a nice sidebar with links to each component, and gives you a single window for everything.
Best of both worlds: those that want individual apps can use them as such, and those that like the "everything under the sun integrated together" can use it as such.
Cyrus IMAP does this using the MURDER protocol, which has been submitted as an Internet RFC. Cyrus also supports the SIEVE protocol (another Internet RFC) for server-side filtering.
This is the solution we will be migrating to this year (Postfix, Cyrus, SquirrelMail) for ~1600 accounts in 1 domain, with another setup for next year using ~15,000 accounts across 15 domains. User accounts are stored in an OpenLDAP directory.
Wow, it only took Intel how many years to do this? AMD licensed the Alpha EV6 bus technology back in the 90s when they started development on the K7/Athlon. And they had a few ex-Alpha engineers to help with the K8/Opteron. And they've got this exact setup on their multi-processor boards.
What's really amazing, though, is how long Intel tried to hold onto their antiquated, horribly-performing multi-processor setup.
Hmmm, is it really so hard to: kldload snd_driver (loads every sound driver on the system)
cat/dev/sndstat (read the output to see exactly which sound driver is being used)
echo 'snd__load="YES"' >>/boot/loader.conf (tell the kernel to load the specific sound module at bootup)
Remember, 95% of all device drivers in FreeBSD are compiled as modules and stored under/boot/kernel/, all there for the loading if you need them. You only need to recompile the kernel to remove drivers.
"Administrator" in this context would be users in the wheel group. Users in the wheel group are allowed to run "su" to become root. I'm guessing DesktopBSD is configured similar to MacOS X in that users in the wheel group can also execute "sudo" to perform individual commands as root.
This is nowhere near the same as running Windows as Administrator, or running Unix as root.
First thing to know about 64-bit systems, whether they be Linux, Windows, or BSD: avoid the nForce chipsets. They are not worth the hassle to get working reliably.
That's your first mistake.
Second thing to know about 64-bit systems, whether they be Linux, Windows or BSD: avoid the very latest, bleeding-edge, "I'm so cool, I got it first" technology. It's not worth the hassle to get working reliably.
That's your second mistake.
Third thing to know about 64-bit systems, whether they be Linux, Windows, or BSD: always, always, always research the hardware support before purchasing any hardware. It's not worth the hassle to get things supported after-the-fact. Doing this would have prevented the first two mistakes.:)
And how often do you have multiple keyboards plugged into the same system and need to use more than one of them at a time? Not counting laptops, as they have hardware keyboard mux builtin.
Oh, that many times? Uh huh. And since you use multiple keyboards so often, and it's been such a pain for you all these years, why haven't you developed a software keyboard multiplexor yet?
Yeah, I didn't think it was that big of an issue.
Note, the keyboard multiplexor would not help with the BIOS USB keyboard issue the OP is having.
JDK 1.4.2 works perfectly well on FreeBSD 4.11, 5.4, and 6.0-BETA2. The only "issue" is that the FreeBSD Foundation has not sent Sun barrelsful of cash to certify the BSD JDK, which means they can't ship it in binary form. No biggie, you just compile it yourself using the ports tree.
The plugin even works in Firefox, Mozilla, and Konqueror.
Depends on the USB2 chipset used, and the USB2 devices you plug into it. There are still a couple of combinations of chipset + device that will lock up a FreeBSD system. They're getting rarer, but there's still a couple niggling issues.
For the most part, though, you just add the ehci device to your kernel and plug in your devices.
Been playing with an iPod Shuffle and FreeBSD 6.0-BETA1 connecting to an ATI IXP USB2 chipset without issues.
For instance, the Atheros drivers are developed on Linux, yet the FreeBSD support is far superior (one ifconfig program for all wired and wireless configuration, WPA supplicant in the base system, drivers ship with the OS, etc). Getting sound working on system in FreeBSD was as simple as "kldload snd_driver; cat/dev/sndstat (to see which driver it actually uses); edit/boot/loader.conf to have it load the correct driver at boot time". Getting sound to work on Debian 3.1 required installing a newer version of the kernel, a newer version of the discover scripts, a newer version of ALSA, running through a bunch of module configure scripts, editing a bunch of files, and finally running alsaconf.
I've also had much better luck with hardware RAID controllers (3Ware Escalade and LSI MegaRAID) under FreeBSD.
Depends if you have the BIOS configured to treat USB keyboards as PS/2 keyboards or not. And this is an issue with BSD, Linux, and Windows.
How do you expect to use a USB keyboard if there is no kernel loaded with a USB stack and USB drivers loaded?
I've yet to find a BIOS that will let me plug in a USB keyboard and use that keyboard to muck around in the BIOS, without enabling PS/2 emulation first, using a PS/2 keyboard.
Slashdot Mirror
Linux has many hw/temp sensor monitors and programs (mbmon, lbmon, etc). However (like all major sub-systems in Linux), it does not have a framework to give you a single set of commands that work with all hw/temp sensors out there.
If you want to monitor systemX, you use programX. If you want to monitor systemY, you use programY. And so on. (It's like the horrid mess that is ifconfig/iwconfig/wiconfig/athctl/younameitctl).
On FreeBSD, you just use GEOM Gate (ggated and ggatec) to create a network filesystem/partition. Then you use GEOM Mirror (gmirror) to create a RAID1 array using the local disk and the ggate disk. The GEOM disk layer handles everything for you from there on. No special driver hooks required, works with any and all disks.
:)
If you want to get fancy, you could use ggate to create two network disks/partitions, and graid3 to create a RAID3 array. But the performance probably would be all that great.
We do something similar. All the computers that go out to users are locked down with DeepFreeze, with TightVNC installed (with a nice Helpdesk icon on the desktop). We don't do remote management, just remote control and remote support.
The staff just love it. When they have a problem, can't remember how to do something, or come across a strange error message they don't understand, they just call the helpdesk, start TightVNC, give us their IP, and we take control of their desktop. We can show then how to do things, read the error messages for ourselves, watch as they go through the steps. Cuts our call times down, gives the users a greater sense of support, and virtually eliminates the "spend 20 minutes driving to a site to spend 5 minutes fixing the problem" kinds of workorders. Now, the onsite techs are only sent out for major problems.
You must be buying crappy laptops, then.
:)
My first laptop (Fujitsu Lifebook 765Dx) is still going strong. Bought it back in 97 or 98. Sure, it's only a 166 MHz Pentium-MMX with 80 MB RAM, a 2.1 GB HD, 2 MB Trident video, and a 12.1" passive matrix display. But it runs Windows 98SE, FreeBSD, DragonFlyBSD, and Debian well enough. Makes a fun little toy, and a decent firewall box.
My first work laptop (Seanix Sea-Note) is still going strong. Picked it up just about 4 years ago now. It's a Celeron 1 GHz with 384 MB RAM, 20 GB HD, don't recall the video. Runs Windows XP quite nicely.
My primary work laptop (Toshiba Satellite A60) is almost 2.5 years old. It's a Celeron 2.8 GHz w/1 GB RAM, a Radeon 7000 IGP, a 40 GB HD, and a 15" screen. Everything still works on it, and I flip between FreeBSD and Debian on it.
It all depends on what you buy, what you do with it, and how often you drop it.
You can get 10K RPM SATA drives from Seagate if you need SATA and want low-latency access. The Seagate SATA Raptor is just a re-packaged SCSI Raptor with a SATA interface.
Celeron processors use the exact same core as the Pentium II, III, and 4 (depending on the model). The only differences between a Celeron and a Pentium 2/3/4 is the size of the L1 and L2 caches, the speed of the L2 cache, and the speed of the frontside bus (the Celeron has less cache, slower cache, and slower FSB).
IOW, Celeron == el cheapo, slow, crappy versions of the Pentium
You forgot to include the interest. :)
Where's the fun in that. Over here in Canada (or at least this small town in the heart of BC), the bartenders all use 1 ounce shot glasses to measure the alcolhol. And if you find a bartender that likes you, they keep pouring from the bottle between shots (so a double is actually closer to 2.5 or even 3 ounces). :)
:)
Of course, most of the alcolhol is watered down (shittiest Smirnoff you'll ever taste is in the bar) beforehand, so it all balances out in the end.
Some of the bars here use pre-measured mixes for the most popular drinks, and dispense the alcohol from the little guns with a bunch of buttons on it (like for fountain pop).
The nicest, most featureful chat protocol I've ever used with Tribal Force's PowWow. Now there was a chat program worth using. Text chat person-to-person. Chat rooms for multi-person-to-person chats. Chat servers for multi-person chats. Voice chat. The best text-to-speech I've ever heard (and that was on Windows 3.11 and Windows 95B), even now. And a wonderful "group web surfing" feature where one person can control the web browser of all the people in the chat. And it was all done in a 5 MB install.
It's just too bad the protocol was kept so secret, and the marketing was so piss-poor. It was what NetMeeting, MSN/Windows Messenger always hoped to be (and never will be). None of the other chat clients I've used (MSN/Yahoo/AIM/gAIM/Kopete/Trillian/ICQ) compare to that one. The only thing missing, AFAIR, was video, but back then, web cams were still in the multi-hundred dollar range.
[sniff] Why do the good ones always die young?
And to reach a human being who can actually solve your problem:
up, up, down, down, left, right, left, right, b, a, select, start.
The myth is not that you can hit another arrow (every archer's done that at one point or another), or the same spot twice. The myth is that Robin Hood split the arrow *from nock to tip*. In other words, the entire shaft of the arrow is split down the middle.
While there may be that 1 in a bazillion chance that it would work, all the tests they did showed that it is impossible. The blade of the arrow tip follows the grain in the wood, and unless you have a perfectly straight grain that never hits the edge of the shaft, the arrow will always pop out before it hits the target.
The show they did on the various "Put X in the gas tank to kill the motor" myths was one of those "Huh? Who'd a thunk it." shows.
... nothing. ... runs a little rougher the first day, and the rust from the tank plays havoc on the motor the next day. ... makes it run better.
Sugar in the tank
Bleach in the tank
Moth balls in the tank
But the one that nobody figured on was that cracking an egg into a leaking radiator will plug the leak.
You're confusing "throttle" as in power saving and "throttle" as in can't pump enough data to the rest of the system. In essense, you are both arguing the same thing. :)
You obviously did not look very hard, as there is a duplicate of that board available with Opteron support. Uses the AMD 8000-series chipset, and is fully supported under Linux and FreeBSD. We've got several Thunder K8S and Thunder K8SR boards here. Dual-Opteron support, dual-core support (in the K8S-D boards), 16 GB RAM, several 32-bit/33 MHz PCI slots, a couple 64-bit/66/100 MHz PCI-X slots, and 1 64-bit/133 MHz PCI-X slot. Onboard PATA and/or SATA or SCSI support. 10/100 and dual-gigE ports.
... but with better non-Windows support and faster throughput in every way. :) And a cheaper price tag to boot.
Everything your Xeon board has
The only thing you have to do when shopping for Opteron motherboards is avoid nVidia and ATI chipsets. Stick to AMD and VIA chipsets, and things work wonderfully.
And another project takes a page out of the KDE development book. :) This is exactly the process taken by the Kontact project. A container application that integrates multiple separate applications into a cohesive whole. You can run the individual apps (KMail, KAddressbook, KNotes, Akregator, Todo, Journal, KNode, etc) as separate applications, or you can run Kontact which provides a nice sidebar with links to each component, and gives you a single window for everything.
Best of both worlds: those that want individual apps can use them as such, and those that like the "everything under the sun integrated together" can use it as such.
Cyrus IMAP does this using the MURDER protocol, which has been submitted as an Internet RFC. Cyrus also supports the SIEVE protocol (another Internet RFC) for server-side filtering.
This is the solution we will be migrating to this year (Postfix, Cyrus, SquirrelMail) for ~1600 accounts in 1 domain, with another setup for next year using ~15,000 accounts across 15 domains. User accounts are stored in an OpenLDAP directory.
Wow, it only took Intel how many years to do this? AMD licensed the Alpha EV6 bus technology back in the 90s when they started development on the K7/Athlon. And they had a few ex-Alpha engineers to help with the K8/Opteron. And they've got this exact setup on their multi-processor boards.
What's really amazing, though, is how long Intel tried to hold onto their antiquated, horribly-performing multi-processor setup.
Hmmm, is it really so hard to:
/dev/sndstat
/boot/loader.conf
/boot/kernel/, all there for the loading if you need them. You only need to recompile the kernel to remove drivers.
kldload snd_driver
(loads every sound driver on the system)
cat
(read the output to see exactly which sound driver is being used)
echo 'snd__load="YES"' >>
(tell the kernel to load the specific sound module at bootup)
Remember, 95% of all device drivers in FreeBSD are compiled as modules and stored under
"Administrator" in this context would be users in the wheel group. Users in the wheel group are allowed to run "su" to become root. I'm guessing DesktopBSD is configured similar to MacOS X in that users in the wheel group can also execute "sudo" to perform individual commands as root.
This is nowhere near the same as running Windows as Administrator, or running Unix as root.
First thing to know about 64-bit systems, whether they be Linux, Windows, or BSD: avoid the nForce chipsets. They are not worth the hassle to get working reliably.
:)
That's your first mistake.
Second thing to know about 64-bit systems, whether they be Linux, Windows or BSD: avoid the very latest, bleeding-edge, "I'm so cool, I got it first" technology. It's not worth the hassle to get working reliably.
That's your second mistake.
Third thing to know about 64-bit systems, whether they be Linux, Windows, or BSD: always, always, always research the hardware support before purchasing any hardware. It's not worth the hassle to get things supported after-the-fact. Doing this would have prevented the first two mistakes.
And how often do you have multiple keyboards plugged into the same system and need to use more than one of them at a time? Not counting laptops, as they have hardware keyboard mux builtin.
Oh, that many times? Uh huh. And since you use multiple keyboards so often, and it's been such a pain for you all these years, why haven't you developed a software keyboard multiplexor yet?
Yeah, I didn't think it was that big of an issue.
Note, the keyboard multiplexor would not help with the BIOS USB keyboard issue the OP is having.
JDK 1.4.2 works perfectly well on FreeBSD 4.11, 5.4, and 6.0-BETA2. The only "issue" is that the FreeBSD Foundation has not sent Sun barrelsful of cash to certify the BSD JDK, which means they can't ship it in binary form. No biggie, you just compile it yourself using the ports tree.
The plugin even works in Firefox, Mozilla, and Konqueror.
Depends on the USB2 chipset used, and the USB2 devices you plug into it. There are still a couple of combinations of chipset + device that will lock up a FreeBSD system. They're getting rarer, but there's still a couple niggling issues.
For the most part, though, you just add the ehci device to your kernel and plug in your devices.
Been playing with an iPod Shuffle and FreeBSD 6.0-BETA1 connecting to an ATI IXP USB2 chipset without issues.
Hardware support depends on the hardware.
/dev/sndstat (to see which driver it actually uses); edit /boot/loader.conf to have it load the correct driver at boot time". Getting sound to work on Debian 3.1 required installing a newer version of the kernel, a newer version of the discover scripts, a newer version of ALSA, running through a bunch of module configure scripts, editing a bunch of files, and finally running alsaconf.
For instance, the Atheros drivers are developed on Linux, yet the FreeBSD support is far superior (one ifconfig program for all wired and wireless configuration, WPA supplicant in the base system, drivers ship with the OS, etc). Getting sound working on system in FreeBSD was as simple as "kldload snd_driver; cat
I've also had much better luck with hardware RAID controllers (3Ware Escalade and LSI MegaRAID) under FreeBSD.
So, it all depends on the hardware you use.
Depends if you have the BIOS configured to treat USB keyboards as PS/2 keyboards or not. And this is an issue with BSD, Linux, and Windows.
How do you expect to use a USB keyboard if there is no kernel loaded with a USB stack and USB drivers loaded?
I've yet to find a BIOS that will let me plug in a USB keyboard and use that keyboard to muck around in the BIOS, without enabling PS/2 emulation first, using a PS/2 keyboard.