lol that's different because it's still the same game. Whereas with Zelda it's an entirely new quest!
Parts of the world have changes, all the items and castles are in different locations and there are completely different/tougher monster types on the various screens.
Hell the first quest was a breeze, although this is pretty damn fast I knew several people (including myself) who could beat it in under an hour when the game was still relatively current. We didn't even count the first quest and half the time would just call our character zelda to skip it altogether when sitting down for a bit of Zelda.
Doesn't beating Zelda mean beating the ENTIRE game, not just half of it?
The second quest is generally more difficult than the first. Saying you've set a speed record for beating the game but not even counting the second quest is pretty lame if you ask me.
With that said, the gameplay was pretty impressive, it's definately the fastest I've ever seen the first half of the game accomplished.
"Shouldn't Open Source be based on collaboration instead of competition?"
Only in the sense that if this protocol is superior to that of gnomemeeting then it's open source and gnomemeeting can adopt it.
There is nothing wrong with honest and fair competition, and what's more honest and fair than the winner only staying that way by actually continuing to innovate in the future.
There are a number of reasons they may not want to collaborate with GnomeMeeting. Maybe the GnomeMeeting chaps are a pain in the arse to deal with. Maybe they feel the GnomeMeeting protocol sucks arse and feel an entirely different protocol is in order.
Who can say, there's nothing wrong with competition in open source. Competition is how you end up with something better. Lack of competition is how you end up with an antiquated XFree86.
Unlike that plumber, electrician, car mechanic, lawyer, or accountant I have gone out of my way to learn a thing or two about plumbing, everything your average electrician knows about electricity and then some, quite a bit about my car and repairing it, enough about the law that I consult with lawyers rather than actually hire them to represent me, and enough about accounting that an actual accountant would only be needed for corporate accounting.
And yes, I generally only call a doctor for surgery or a prescription.
As I said, stupidity is a lack of desire to learn. It's the desire to head to the bar or dinner instead of learning something new. It's avoiding a superior solution because it requires taking 5 minutes to learn something.
Simply put, it's not prioritizing learning new things, and avoiding more complicated but superior solutions in favor of easier inferior ones.
As an example just about anyone can understand, it's choosing to learn and drive an automatic without ever learning how to drive a stick shift.
I've never truely comprehended how someone can say "I don't know" or "I don't understand" and not start working to solve that.
They are either stupid or ignorant (ignorance is generally a side effect of stupidity, since those of us who aren't born with some sort of actual mental defect have more or less the same mental capacity. I define stupity as a lack of desire to learn), and thus will be duped it's the natural way of things.
It's survival of the fittest, and it has thousands of years since the most fit was in reality a measure of any physical characteristic.
Of course with your server you went the reliable route and purchased the kingston ram listed right in the front of MB manual which is guaranteed to work with it, always does in my experience, and pretty much never fails, right?
Hmm afraid my experience definately clashes with yours.
First the price... I've yet to see Kingston ram be the cheapest on the market, actually far from it, sometimes even double the price I could get a crappy Micron or generic chip for. Although the kingston prices tend to be pretty stable, if ram drops alot then kingston is high, if prices rise alot then Kingston is cheap because their prices don't seem to fluctuate as much.
As for stability, in my personal experience I haven't had a kingston chip fail. In my work experience we've only recently started using kingston memory (except for server boards which are pretty picky about what modules work and don't, and there is always a certified kingston chip). Thus far we've used a little over 1200 modules with zero modules DOA and haven't had a single failure except when the ram had been handled improperly (You don't go around actually touching the chips on the modules or working without ESD protection do you?).
You are right about the warranty, with my experience I doubt they lose much by having an ironclad always honored lifetime warranty.
You can have your unstable Corsair that is highly overclockable. I'll take my kingston which I wouldn't dream of running over clock but is solid as a tank if handled properly and run within specs.
Well that's true enough, you do only have edit it on the first install.
Find the process pretty simple myself, although it could be easier it's still the best binary driver I've seen a vendor release (in terms of install).
ATI, Asus, Promise, etc all release drivers that MIGHT work with your kernel/distro/etc Nvidia's driver allows the portion that dependent on these to be recompiled and so works 95% of the time rather than the 20% those other drivers achieve.
That said, changing runlevels is not something your average user should have to do. Even a reboot would be easier for most imho. Annoying to some of us, but anyone can manage a reboot, hell a windows user wouldn't even notice it.
So long as those of us who don't want to reboot can still just restart x.
First, you have to edit/etc/X11/XF86Config and change the driver from nv to nvidia as well as check and make sure the proper modules are loading to install the nvidia drivers as well as run their installer from the command line (which makes no sense to me, why on earth couldn't you do this from the gui and set a line in the script to load the module on next login.
This would let you simply ctrl+alt+backspace rather than init 3, kill the processes that didn't terminate properly, run the installer, init 5 to get back to the gui login and hope it loads properly.
Really, and where do they hide it? I've had to install drivers from the manufacturer for ALMOST EVERY piece of hardware I've put in an XP system.
The fact that these drivers from the manufacturer are included right on a disk with the hardware for windows and are not for linux is another matter entirely and has nothing to do with the OS itself.
When it comes to hardware detecting and installing (truely plug and play) linux is lightyears ahead of Microsoft.
Typical install example, linux.
Build box, install fedora, configure nic. Done with hardware setup.
Same box, shutdown and pull out nic, stick another one in, boot system, it prompts telling me old nic is missing and asks if I'd like to remove the nic from my hardware configuration, next it prompts telling me there is a new nic and asks if I'd like to move the settings from the old nic to it, I say yes, all done.
Typical install example, windows
Build box, install windows. Install ide drivers, and other board drivers for the chipset, usb drivers, etc. Install video drivers, install nic drivers, configure the nic, turn off the power management crap, turn off automatic updating, fix the page file.
Changing the nic.
Write down all the ip and other settings associated with the nic. Remove the nic from device manager, double check network control panel because it may or may not have removed it from here and if it didn't it will kill ip and I'll have to do an ip dump. Uninstall any software or other crap that installed to "manage" the nic. Shutdown, remove the nic, plug in the new nic, power back on, let it boot, hope it detects the nic (which it does fairly well on these days). Install the driver for the nic, configure the ip settings again. Check to make sure ip didn't take a crap when performing this mind boggling task (it does at least 20% of the time, more like 40% of the time if it's not XP, 2000, or 2003). If not great, if so dump ip and the nic driver and repeat.
Hmmm, the windows side of this somehow seems more involved to me when you get right down to it. You sure about that deep driver base thing?
All linux installs should be kept up to date. It's not like windows where the next revision is a new OS, with linux the next revision is generally just a next step increment from the last.
On all but the most critical servers I don't even go on location to upgrade all the packages. Just ssh in, apt-get update, apt-get upgrade. Done.
2.6 is a bit out of the norm in that it IS a major upgrade (although you still shouldn't have to worry about compiling by hand???? On fedora 1 for instance (comparable in newness to your win2k example since win2k isn't all that out of date).
Since of course don't have the gui or sound running on a server. You add one line to your fstab file, change one line in your/etc/sysconfig/gpm IF you have console mouse support going. Delete/etc/sysconfig/hwconf
rpm -ivh *.rpm to install the rpm files for the kernel, reboot and done (make sure kudzu is running since that duh, detects your hardware).
Finished, all done. If you have usb grips and care (although why you would care about usb on a server I don't know) then you change 4 lines in/etc/modprobe.conf.
No reconfiguration of ANY of your server daemons, no formating, no need to reinstall any other portion of the system. Just add a line to fstab, delete your old hardware config so it redetects everything and install two rpm files which won't have any dependency issues on an updated fedora 1 system.
Couldn't tell you about how well virtual pc will handle linux (which is the real question in your case, NOT how well linux handles virtual pc). I haven't seen linux hiccup on a soundblaster 16 in a REAL hardware system, so if it hiccups on your virtual pc then it's a problem with their emulation not linux. Regardless of which version it is.
With that said, if nothing else detects it then redhat/fedora will. I've never seen ANY os or even another distro do as well at detecting and making hardware functional out of the box without anything third party. That includes any version of windows you care to name and yes even MacOS since the mac went pci and third party hardware works.
Another big issue is the form of said drivers when they only want to release a binary driver. Nvidia does this the right way, releasing a bash script which recompiles to match the kernel yet still keeping what they want proprietary.
This works 99% of the time and it doesn't matter what distro your using. No 200 rpms that may or may not work and that have broken or outdated deps. That leads to entirely too much work.
Ever looked at asus or promise linux drivers? Their a joke, don't work 90% of the time.
In theory this IS possible, although it's not really gaining anything. You may be inputting 1 watt of electricity but you are depleting the magnets themselves.
The next piece of the puzzle is natural earth magnets. Sometmes these magnets have been charged for millions of years and thus store an enourmous amount of potential energy. If you succeeded in coming up with a device which is able to tap the potential of these magnets you would have a system which does NOT defy the laws of physics at all.
I haven't investigated his design so wouldn't argue for him even a moment. However simply because nobody has succeeded in doing something doesn't mean that something can't be done, especially when it's completely feasible under the laws of physics as we know them.
As for what he would do with it... yeah, I'd say sell fans. One because so many have tried and failed this concept has moved in most minds from the nobody has done it yet category to the impossible category. Any attempts to do more with this system would simply be met with laughter.
If his claims are real this guy is doing just what he should do. Keep a low profile, get his patents to make sure nobody can take it away. Get his concept out into the world in small functional practice like say, some cheap quiet fans, those aren't supposed to be impossible so you might be able to sell them. Get 40,000 quiet fans using this principle out there in the wild and working and all the sudden the laughs turn to snickers. Move to phase b and get another product out there a bit bigger than a fan.
In 50yrs going this route you might be able to sell some generators. It's sad really, we've thrown away science, not because we've learned it was impossible, but simply because nobody has managed to pull it off yet.
"Remember that the exact amount of potential energy stored in a permanent magnet could be calculated by measuring the energy required to magnetize it, and this quantity is definitely finite."
Without a doubt, but if these are natural earth magnets he's using then finite could quickly turn into virtually infinite. In many cases earth magnets have been building up potential energy for millions if not billions of years...
First of all, your on crack, most of those programs don't run as root as root out of the box, don't recommend running as root in the installation documentation, or at least are configured not to run as root by every distribution which is even vaguely popular.
In addition only one thing there has anything to do with a linux vulnerability, the kernel. The rest are user application software even if they were running as root. If root executes vi then it's running with root privilages, that hardly makes it part of the OS aka kernel.
I think your numbers are a bit screwed, I suppose if your looking at computing in general your probably a bit exaggerated but the concept is right.
However when looking at microsoft vulnerabilities it's a different story, they are extremely varied generally because they are due to a lack of consideration when coding and extremely poor structure and design. For instance, Active X, it's a security flaw, 90% of the sub-flaws reported in it are there because the flaw itself, is poorly designed (hence why it's a flaw) rather than fix the problem (a redesign or elimination of activeX) they create a patchwork changing this or that detail of how it functions.
Why is this is a debate or an issue? Why do most projects still get this wrong? Having configuration stored in a text file is absolutely the way to go, this has tons of benefits, probably the biggest and least mentioned is that the configuration can be passed around or backed up. So although you spend 3hrs configuring server x and services, you then backup the conf files to a floppy and pop them back in place the next time.
Text config is also the most flexible way to go, you always have the most power and control (or potential for it anyway) with text config. That's great, it covers half the battle.
What does that have to do with the absolutely neccesity to have a configuration program? At the cli I should have two options, the text file direct or ncurses configuration app which offers 99% of the functionality available to me by editing the file directly and does so in an intuitive manner. At the gui I also have two options, the gui based configuration app which works like the ncurses one and editing the file directly. Alot of projects come close (although usually they offer one or the other) but they make said app a one time shot, rather than say, letting me configure, and then *gasp* later modify rather than completely start over my existing config or manual modifications.... and this is produced by the same people who already wrote code to parse the config file and read in the values!
The other issue here is conformity, despite configuring dozens of apps via text file every day about once a week I encounter a new style/format of config file. We need to come up with a standard for this. We also need to work on defaults, I've yet to encounter a project with even vaguely reasonable defaults... defining reasonable as the most commonly used values. As an example, neither postfix nor sendmail actually come "out of the box" configured for the most common mail setup, to use the already set host value, and relay for the most commonly used private subnets (namely 192.168.1.0 and 192.168.0.0) and use mbox files. Other configurations are exceptions rather than the rule and 90% of those exceptions would require no more than a change to who to relay for so why don't these programs come with this default config out of the box?
Installer, binary, source, wizard...
I don't see a real question here either, the answer is all of the above again. The source code of course should be available but is hardly the format of consumption for end users. The binary should be available (at least an rpm that doesn't have dependencies or has them packaged with it) and an installer wizard which helps you arrive at your initial configuration, put things where they should go and install any dependencies which the program needs with just a few clicks or key punches (after all there should be an ncurses version of the installer as well). Nvidia has a good concept with downloading the source if the binary doesn't match the system which the app is being installed on.
Someday someone will figure out that there really aren't many distro's that make use of/usr/local so perhaps that shouldn't be the default, or worse ONLY place the installer looks if the app in question is a plugin or some such.
Documentation
There should be some! Most I've seen doesn't cover the whole spectrum, either it's for idiots, or it's for programmers or the worst, it's outdated and inaccurate and/or wasn't even vaguely accurate when it was current. For an example, look to grub documentation on installing the bootloader from the native command prompt, you'll find two different general sets of commands to use, the most common method found on a google does not work on any version of grub I've EVER encountered but is faithfully repeated, the commands listed outright wrong.
Generally a basic, and advanced USER guide which don't reference source code or compiling at all. And then a seperate set of programmers documentation kept as curre
Alot of what was said I agree with, alot I do not, these points annoyed the hell out of me though.
"The most common response to this complaint is "if they can't understand it, they're not ready to install it," but then how are they expected to learn? Documentation should always cater to the lowest common denominator."
This is founded on two MAJOR misconceptions which I'll address in reverse order. Documentation should always cater to the lowest common denominator... why is that? Documentation should be be complete, not concentrating on ANY particular level of user. Documentation for idiots is what proprietary software has, and it's worthless which leads to my second point.
If they can't understand the documentation they absolutely aren't ready to install the software, your average computer user has no buisness installing an OS and/or software for that OS, that's what technicians are for. If someone would like to learn and be qualified to install program x (which by no means implies they are then qualified to install program y) then they should lookup and learn what they need to in order to understand the documentation.
With that said, most projects DO have lousy documentation, not only is it incomplete it's also generally inaccurate, sometimes blatantly, wrong switches given in example commands, sometimes outright wrong commands to do things like flush the cache of proxy x etc. This shit does need fixed.
"Also, anyone who has ever had to debug a problem in Open Source software knows that the answers don't lie in Open Source software documentation: they're found in Usenet articles, bulletin boards and chat logs."
And this is different from proprietary software how? I've seen few (read none that come to mind) proprietary apps which have good documentation. Most cater to things which are painfully obvious to anyone who can understand the documentation and completely ignore any actual useful content. As a result google provides your real documentation whether it be proprietary or open source.
I'm seeing alot of single threaded versus multi-threaded arguments.
That's great and all, but for a single threaded application a cray isn't even going to smash your modern top of the line home pc by too terribly much.
crays are massive smp systems, they need a multi-threaded app to take advantage just as much as a cluster does. The difference is in the bus speed. A cray has a much faster bus, and with equivelent processing and memory it will excel with a number of small quickly terminated threads, whereas a cluster will as well or better with larger more processor consuming threads.
Why would a cluster ever do better? Simple, although a cluster has a drastically slower bus, there is memory local to the processor in question so there is much less congestion on the bus, and since if your shelling out for a cluster you will be switching rather than hub style whatever you do there will be almost without collisions and bus contention. Each node has it's own ram so there isn't much of an issue with contention for the bus and much greater memory throughput.
So like I said, it's all about how fast threads spawn and terminate, because if your rapid firing threads then you will doing alot of communicating between nodes over the slow bus (network), if your sending good sized chunks of data do something and keeping your nodes busy they will spend more time working and less time communicating results and your cluster will tromp all over that cray.
ok ac I'll bite. Why on earth are you debating on a subject which has long since been settled beyond any reasonable doubts?
First of all the virus was called by cnn a linux weapon of mass destruction, that doesn't sound like an accusation of a lone vigilante.
Second it was later proven without question that the DDOS on sco.com was just a cover for the real purpose of the virus which was email harvesting for spammers. It spread as far and fast as it did because it was passed around through well known spammer networks and mass mailed into existance.
Remember how quick the media was to turn on the linux community when a worm appeared to be targeted at SCO.
Let's show we are a couple notches above the media here and give this some time, maybe we can take this thing apart and make sure of it's TRUE intended victim. Not to say I'd put it past the RIAA, but we should make sure before flinging accusations.
Office wasn't going to work on other versions.
on
Microsoft Clips Longhorn
·
· Score: 4, Insightful
"The changes also affect Microsoft's plan to make the next version of its Office software work only on Longhorn. The new plans call for that Office package to work on previous versions of Windows as well.
Windows leaders are meeting through the middle of April to make the hard decisions about which specific features to cut from the operating system."
Slashdot Mirror
lol that's different because it's still the same game. Whereas with Zelda it's an entirely new quest!
Parts of the world have changes, all the items and castles are in different locations and there are completely different/tougher monster types on the various screens.
Hell the first quest was a breeze, although this is pretty damn fast I knew several people (including myself) who could beat it in under an hour when the game was still relatively current. We didn't even count the first quest and half the time would just call our character zelda to skip it altogether when sitting down for a bit of Zelda.
Nope, the fmv file prevents this, it only records the controller action so you simply download it and run it on your own computer and check the time.
It would reduce the time shown in the avi, but not the time shown when you check fmv file.
Doesn't beating Zelda mean beating the ENTIRE game, not just half of it?
The second quest is generally more difficult than the first. Saying you've set a speed record for beating the game but not even counting the second quest is pretty lame if you ask me.
With that said, the gameplay was pretty impressive, it's definately the fastest I've ever seen the first half of the game accomplished.
"Shouldn't Open Source be based on collaboration instead of competition?"
Only in the sense that if this protocol is superior to that of gnomemeeting then it's open source and gnomemeeting can adopt it.
There is nothing wrong with honest and fair competition, and what's more honest and fair than the winner only staying that way by actually continuing to innovate in the future.
There are a number of reasons they may not want to collaborate with GnomeMeeting. Maybe the GnomeMeeting chaps are a pain in the arse to deal with. Maybe they feel the GnomeMeeting protocol sucks arse and feel an entirely different protocol is in order.
Who can say, there's nothing wrong with competition in open source. Competition is how you end up with something better. Lack of competition is how you end up with an antiquated XFree86.
Unlike that plumber, electrician, car mechanic, lawyer, or accountant I have gone out of my way to learn a thing or two about plumbing, everything your average electrician knows about electricity and then some, quite a bit about my car and repairing it, enough about the law that I consult with lawyers rather than actually hire them to represent me, and enough about accounting that an actual accountant would only be needed for corporate accounting.
And yes, I generally only call a doctor for surgery or a prescription.
As I said, stupidity is a lack of desire to learn. It's the desire to head to the bar or dinner instead of learning something new. It's avoiding a superior solution because it requires taking 5 minutes to learn something.
Simply put, it's not prioritizing learning new things, and avoiding more complicated but superior solutions in favor of easier inferior ones.
As an example just about anyone can understand, it's choosing to learn and drive an automatic without ever learning how to drive a stick shift.
I've never truely comprehended how someone can say "I don't know" or "I don't understand" and not start working to solve that.
Yes but who really cares about the sheep?
They are either stupid or ignorant (ignorance is generally a side effect of stupidity, since those of us who aren't born with some sort of actual mental defect have more or less the same mental capacity. I define stupity as a lack of desire to learn), and thus will be duped it's the natural way of things.
It's survival of the fittest, and it has thousands of years since the most fit was in reality a measure of any physical characteristic.
Of course with your server you went the reliable route and purchased the kingston ram listed right in the front of MB manual which is guaranteed to work with it, always does in my experience, and pretty much never fails, right?
Hmm afraid my experience definately clashes with yours.
First the price... I've yet to see Kingston ram be the cheapest on the market, actually far from it, sometimes even double the price I could get a crappy Micron or generic chip for. Although the kingston prices tend to be pretty stable, if ram drops alot then kingston is high, if prices rise alot then Kingston is cheap because their prices don't seem to fluctuate as much.
As for stability, in my personal experience I haven't had a kingston chip fail. In my work experience we've only recently started using kingston memory (except for server boards which are pretty picky about what modules work and don't, and there is always a certified kingston chip). Thus far we've used a little over 1200 modules with zero modules DOA and haven't had a single failure except when the ram had been handled improperly (You don't go around actually touching the chips on the modules or working without ESD protection do you?).
You are right about the warranty, with my experience I doubt they lose much by having an ironclad always honored lifetime warranty.
You can have your unstable Corsair that is highly overclockable. I'll take my kingston which I wouldn't dream of running over clock but is solid as a tank if handled properly and run within specs.
our distributors are actually selling pc133 at almost double the price of pc3200 ddr
Well that's true enough, you do only have edit it on the first install.
Find the process pretty simple myself, although it could be easier it's still the best binary driver I've seen a vendor release (in terms of install).
ATI, Asus, Promise, etc all release drivers that MIGHT work with your kernel/distro/etc Nvidia's driver allows the portion that dependent on these to be recompiled and so works 95% of the time rather than the 20% those other drivers achieve.
That said, changing runlevels is not something your average user should have to do. Even a reboot would be easier for most imho. Annoying to some of us, but anyone can manage a reboot, hell a windows user wouldn't even notice it.
So long as those of us who don't want to reboot can still just restart x.
First, you have to edit /etc/X11/XF86Config and change the driver from nv to nvidia as well as check and make sure the proper modules are loading to install the nvidia drivers as well as run their installer from the command line (which makes no sense to me, why on earth couldn't you do this from the gui and set a line in the script to load the module on next login.
This would let you simply ctrl+alt+backspace rather than init 3, kill the processes that didn't terminate properly, run the installer, init 5 to get back to the gui login and hope it loads properly.
Maybe there is some reason this wouldn't work?
"Microsoft's got a deep driver library database"
Really, and where do they hide it? I've had to install drivers from the manufacturer for ALMOST EVERY piece of hardware I've put in an XP system.
The fact that these drivers from the manufacturer are included right on a disk with the hardware for windows and are not for linux is another matter entirely and has nothing to do with the OS itself.
When it comes to hardware detecting and installing (truely plug and play) linux is lightyears ahead of Microsoft.
Typical install example, linux.
Build box, install fedora, configure nic. Done with hardware setup.
Same box, shutdown and pull out nic, stick another one in, boot system, it prompts telling me old nic is missing and asks if I'd like to remove the nic from my hardware configuration, next it prompts telling me there is a new nic and asks if I'd like to move the settings from the old nic to it, I say yes, all done.
Typical install example, windows
Build box, install windows. Install ide drivers, and other board drivers for the chipset, usb drivers, etc. Install video drivers, install nic drivers, configure the nic, turn off the power management crap, turn off automatic updating, fix the page file.
Changing the nic.
Write down all the ip and other settings associated with the nic. Remove the nic from device manager, double check network control panel because it may or may not have removed it from here and if it didn't it will kill ip and I'll have to do an ip dump. Uninstall any software or other crap that installed to "manage" the nic. Shutdown, remove the nic, plug in the new nic, power back on, let it boot, hope it detects the nic (which it does fairly well on these days). Install the driver for the nic, configure the ip settings again. Check to make sure ip didn't take a crap when performing this mind boggling task (it does at least 20% of the time, more like 40% of the time if it's not XP, 2000, or 2003). If not great, if so dump ip and the nic driver and repeat.
Hmmm, the windows side of this somehow seems more involved to me when you get right down to it. You sure about that deep driver base thing?
All linux installs should be kept up to date. It's not like windows where the next revision is a new OS, with linux the next revision is generally just a next step increment from the last.
/etc/sysconfig/gpm IF you have console mouse support going. Delete /etc/sysconfig/hwconf
/etc/modprobe.conf.
On all but the most critical servers I don't even go on location to upgrade all the packages. Just ssh in, apt-get update, apt-get upgrade. Done.
2.6 is a bit out of the norm in that it IS a major upgrade (although you still shouldn't have to worry about compiling by hand???? On fedora 1 for instance (comparable in newness to your win2k example since win2k isn't all that out of date).
Since of course don't have the gui or sound running on a server. You add one line to your fstab file, change one line in your
rpm -ivh *.rpm to install the rpm files for the kernel, reboot and done (make sure kudzu is running since that duh, detects your hardware).
Finished, all done. If you have usb grips and care (although why you would care about usb on a server I don't know) then you change 4 lines in
No reconfiguration of ANY of your server daemons, no formating, no need to reinstall any other portion of the system. Just add a line to fstab, delete your old hardware config so it redetects everything and install two rpm files which won't have any dependency issues on an updated fedora 1 system.
Couldn't tell you about how well virtual pc will handle linux (which is the real question in your case, NOT how well linux handles virtual pc). I haven't seen linux hiccup on a soundblaster 16 in a REAL hardware system, so if it hiccups on your virtual pc then it's a problem with their emulation not linux. Regardless of which version it is.
With that said, if nothing else detects it then redhat/fedora will. I've never seen ANY os or even another distro do as well at detecting and making hardware functional out of the box without anything third party. That includes any version of windows you care to name and yes even MacOS since the mac went pci and third party hardware works.
Another big issue is the form of said drivers when they only want to release a binary driver. Nvidia does this the right way, releasing a bash script which recompiles to match the kernel yet still keeping what they want proprietary.
This works 99% of the time and it doesn't matter what distro your using. No 200 rpms that may or may not work and that have broken or outdated deps. That leads to entirely too much work.
Ever looked at asus or promise linux drivers? Their a joke, don't work 90% of the time.
In theory this IS possible, although it's not really gaining anything. You may be inputting 1 watt of electricity but you are depleting the magnets themselves.
The next piece of the puzzle is natural earth magnets. Sometmes these magnets have been charged for millions of years and thus store an enourmous amount of potential energy. If you succeeded in coming up with a device which is able to tap the potential of these magnets you would have a system which does NOT defy the laws of physics at all.
I haven't investigated his design so wouldn't argue for him even a moment. However simply because nobody has succeeded in doing something doesn't mean that something can't be done, especially when it's completely feasible under the laws of physics as we know them.
As for what he would do with it... yeah, I'd say sell fans. One because so many have tried and failed this concept has moved in most minds from the nobody has done it yet category to the impossible category. Any attempts to do more with this system would simply be met with laughter.
If his claims are real this guy is doing just what he should do. Keep a low profile, get his patents to make sure nobody can take it away. Get his concept out into the world in small functional practice like say, some cheap quiet fans, those aren't supposed to be impossible so you might be able to sell them. Get 40,000 quiet fans using this principle out there in the wild and working and all the sudden the laughs turn to snickers. Move to phase b and get another product out there a bit bigger than a fan.
In 50yrs going this route you might be able to sell some generators. It's sad really, we've thrown away science, not because we've learned it was impossible, but simply because nobody has managed to pull it off yet.
"Remember that the exact amount of potential energy stored in a permanent magnet could be calculated by measuring the energy required to magnetize it, and this quantity is definitely finite."
Without a doubt, but if these are natural earth magnets he's using then finite could quickly turn into virtually infinite. In many cases earth magnets have been building up potential energy for millions if not billions of years...
First of all, your on crack, most of those programs don't run as root as root out of the box, don't recommend running as root in the installation documentation, or at least are configured not to run as root by every distribution which is even vaguely popular.
In addition only one thing there has anything to do with a linux vulnerability, the kernel. The rest are user application software even if they were running as root. If root executes vi then it's running with root privilages, that hardly makes it part of the OS aka kernel.
I think your numbers are a bit screwed, I suppose if your looking at computing in general your probably a bit exaggerated but the concept is right.
However when looking at microsoft vulnerabilities it's a different story, they are extremely varied generally because they are due to a lack of consideration when coding and extremely poor structure and design. For instance, Active X, it's a security flaw, 90% of the sub-flaws reported in it are there because the flaw itself, is poorly designed (hence why it's a flaw) rather than fix the problem (a redesign or elimination of activeX) they create a patchwork changing this or that detail of how it functions.
text based config vs gui/app based config
/usr/local so perhaps that shouldn't be the default, or worse ONLY place the installer looks if the app in question is a plugin or some such.
Why is this is a debate or an issue? Why do most projects still get this wrong? Having configuration stored in a text file is absolutely the way to go, this has tons of benefits, probably the biggest and least mentioned is that the configuration can be passed around or backed up. So although you spend 3hrs configuring server x and services, you then backup the conf files to a floppy and pop them back in place the next time.
Text config is also the most flexible way to go, you always have the most power and control (or potential for it anyway) with text config. That's great, it covers half the battle.
What does that have to do with the absolutely neccesity to have a configuration program? At the cli I should have two options, the text file direct or ncurses configuration app which offers 99% of the functionality available to me by editing the file directly and does so in an intuitive manner. At the gui I also have two options, the gui based configuration app which works like the ncurses one and editing the file directly. Alot of projects come close (although usually they offer one or the other) but they make said app a one time shot, rather than say, letting me configure, and then *gasp* later modify rather than completely start over my existing config or manual modifications.... and this is produced by the same people who already wrote code to parse the config file and read in the values!
The other issue here is conformity, despite configuring dozens of apps via text file every day about once a week I encounter a new style/format of config file. We need to come up with a standard for this. We also need to work on defaults, I've yet to encounter a project with even vaguely reasonable defaults... defining reasonable as the most commonly used values. As an example, neither postfix nor sendmail actually come "out of the box" configured for the most common mail setup, to use the already set host value, and relay for the most commonly used private subnets (namely 192.168.1.0 and 192.168.0.0) and use mbox files. Other configurations are exceptions rather than the rule and 90% of those exceptions would require no more than a change to who to relay for so why don't these programs come with this default config out of the box?
Installer, binary, source, wizard...
I don't see a real question here either, the answer is all of the above again. The source code of course should be available but is hardly the format of consumption for end users. The binary should be available (at least an rpm that doesn't have dependencies or has them packaged with it) and an installer wizard which helps you arrive at your initial configuration, put things where they should go and install any dependencies which the program needs with just a few clicks or key punches (after all there should be an ncurses version of the installer as well). Nvidia has a good concept with downloading the source if the binary doesn't match the system which the app is being installed on.
Someday someone will figure out that there really aren't many distro's that make use of
Documentation
There should be some! Most I've seen doesn't cover the whole spectrum, either it's for idiots, or it's for programmers or the worst, it's outdated and inaccurate and/or wasn't even vaguely accurate when it was current. For an example, look to grub documentation on installing the bootloader from the native command prompt, you'll find two different general sets of commands to use, the most common method found on a google does not work on any version of grub I've EVER encountered but is faithfully repeated, the commands listed outright wrong.
Generally a basic, and advanced USER guide which don't reference source code or compiling at all. And then a seperate set of programmers documentation kept as curre
Alot of what was said I agree with, alot I do not, these points annoyed the hell out of me though.
"The most common response to this complaint is "if they can't understand it, they're not ready to install it," but then how are they expected to learn? Documentation should always cater to the lowest common denominator."
This is founded on two MAJOR misconceptions which I'll address in reverse order. Documentation should always cater to the lowest common denominator... why is that? Documentation should be be complete, not concentrating on ANY particular level of user. Documentation for idiots is what proprietary software has, and it's worthless which leads to my second point.
If they can't understand the documentation they absolutely aren't ready to install the software, your average computer user has no buisness installing an OS and/or software for that OS, that's what technicians are for. If someone would like to learn and be qualified to install program x (which by no means implies they are then qualified to install program y) then they should lookup and learn what they need to in order to understand the documentation.
With that said, most projects DO have lousy documentation, not only is it incomplete it's also generally inaccurate, sometimes blatantly, wrong switches given in example commands, sometimes outright wrong commands to do things like flush the cache of proxy x etc. This shit does need fixed.
"Also, anyone who has ever had to debug a problem in Open Source software knows that the answers don't lie in Open Source software documentation: they're found in Usenet articles, bulletin boards and chat logs."
And this is different from proprietary software how? I've seen few (read none that come to mind) proprietary apps which have good documentation. Most cater to things which are painfully obvious to anyone who can understand the documentation and completely ignore any actual useful content. As a result google provides your real documentation whether it be proprietary or open source.
I'm seeing alot of single threaded versus multi-threaded arguments.
That's great and all, but for a single threaded application a cray isn't even going to smash your modern top of the line home pc by too terribly much.
crays are massive smp systems, they need a multi-threaded app to take advantage just as much as a cluster does. The difference is in the bus speed. A cray has a much faster bus, and with equivelent processing and memory it will excel with a number of small quickly terminated threads, whereas a cluster will as well or better with larger more processor consuming threads.
Why would a cluster ever do better? Simple, although a cluster has a drastically slower bus, there is memory local to the processor in question so there is much less congestion on the bus, and since if your shelling out for a cluster you will be switching rather than hub style whatever you do there will be almost without collisions and bus contention. Each node has it's own ram so there isn't much of an issue with contention for the bus and much greater memory throughput.
So like I said, it's all about how fast threads spawn and terminate, because if your rapid firing threads then you will doing alot of communicating between nodes over the slow bus (network), if your sending good sized chunks of data do something and keeping your nodes busy they will spend more time working and less time communicating results and your cluster will tromp all over that cray.
ok ac I'll bite. Why on earth are you debating on a subject which has long since been settled beyond any reasonable doubts?
First of all the virus was called by cnn a linux weapon of mass destruction, that doesn't sound like an accusation of a lone vigilante.
Second it was later proven without question that the DDOS on sco.com was just a cover for the real purpose of the virus which was email harvesting for spammers. It spread as far and fast as it did because it was passed around through well known spammer networks and mass mailed into existance.
Remember how quick the media was to turn on the linux community when a worm appeared to be targeted at SCO.
Let's show we are a couple notches above the media here and give this some time, maybe we can take this thing apart and make sure of it's TRUE intended victim. Not to say I'd put it past the RIAA, but we should make sure before flinging accusations.
"The changes also affect Microsoft's plan to make the next version of its Office software work only on Longhorn. The new plans call for that Office package to work on previous versions of Windows as well.
Windows leaders are meeting through the middle of April to make the hard decisions about which specific features to cut from the operating system."
Only Microsoft would call that a feature.