Getting NVidia drivers installed for RedHat is extremely awkward. You wind up having to go to a non-RedHat provided repository like Livna. Check out http://rpm.livna.org/livna-switcher.html for notes on how that repository does it better for Fedora Core than RedHat has ever done for their "commercial" releases.
And they're paing several thousand dollars a year for the various consusingly named "server" licenses. The turn-around time of their more complex support questions has not impressed me over the years, even where I've identified a verifiable bug and sent them the patch in the process of getting help.
Oddly, for typical users, the CentOS community which uses a RHEL OS rebuilt from source code actually works better for support. I've actually watched a data center manager on the phone with RedHat sales saying "No, I'm using CentOS because they have longer licenses and the community is more responsive: these are the trouble tickets I called RedHat about and which the CentOS community helped me solve before I even reached a real RedHat engineer to discuss it. And here's the fix."
The main problem seems to be that RedHat took way, way, way too long for its next RHEL release, and the world evolved under them.
I agree. And many of the people who disable it do it incorrectly, by editing their bootloader, rather than using the options in init scripts to set it to "permissive" mode and get reports of what it is detecting, then fix those and publish those fixes or get it into the software package deployments.
Please remember that significant pieces of the Patriot Act are not publicly available, for "national security reasons". That's always a bad sign for civil liberties or personal privacy. Then take a look at the Wikipedia entries on it, which seem well founded, and describe numerous circumstances for "sneak and peek" previews where the existence of a warrant need not be revealed to the person searched (such as warrants from FISA). And note that FISA warrants are not normal criminal search warrants, they're much easier to obtain.
In particular, examine the parts about revealing library records which has led to libraries warning patrons that their borrowing records may be requested without their knowledge.
Not unless they're running virtual environments, not just spare accounts. Build and testing environments *cannot* have random pieces of other people's software and build environments lying around, or you don't know what you're actually testing.
Remember, various sourceforge tools have various dependencies: compiler, web server, glibc and gcc PHP and perl and regexp and make, all of which may affect compilation and proper behavior. That's a nightmare to predict on someone's private server. If folks were willing to run VMware or Xen or something like to provide defined build environments, OK. That makes sense. But to simply open up user accounts to other sourceforge developers randomly is begging for massive trouble.
It's not even just a security problem. A simple bug in PHP can blow away the rest of the Apache owned user space, or overflow any partition on the system that the web server can write to. And it can suck down all the CPU resources, the memory resource, or the inodes on the partition even without using up the disk space. I've seen all of these happen in debugging. Maintaining a reliable build environment and protecting the other build environments from the inevitable errors in one build environment takes work and understanding of security and building scalable infrastructure for auto-testing and autobuilding.
I've done things like this professionally. But my time is not cheap: even if I'm willing to contribute my time (and I might be!), is my free source development time better spent elsewhere? Modesty and a desire for privacy preclude my listing them, but I'm currently involved in active development of 3 notable projects. Should I give up my involvement in those, especially because I'm getting paid for one of them, to work on this?
It's expensive: power, cooling, rent on the building with the rackspace, and bandwidth all add up to a considerable chunk of change. And the professional skills to run such a farm are unusual and expensive to hire, or to contribute. Even a modest Q/A testing and evaluation farm can cost a few hundred thousand dollars a year when you add up all the costs.
Slow down: The Hodgkins Huxley model of neural conduction is far too well supported by experiment, and by the observed behavior changes of nerve in response to ionic concentrations. You can't just throw that out due to a lack of thermal effects.
Moreover, "heat produced by electrical conduction" and the like have to come from somewhere. The amount of energy processed by a cell is limited mostly by glucose metabolism. (We could chat about protein metabolism as well, but let's not get distracted.) That glucose metabolism and related heat production for keeping the cell active in other ways is far higher than that one would expect from electrical conduction by any model I know: delicately measuring "resistive" losses (which do not quite mean the same thing in electrolytic conduction, let me tell you!) is like measure the paint on rocks in an avalanche. You don't bother to measure it by heat or weight, you measure it by more obvious factors like color (or electrical potentials, in this case, since HH style experiments demonstrate it quite well).
Fortunately, the actual original article is much better than the confusing and misleading analysis in the Slashdot lead-in and the linked article.
Of course, many modern viruses send the mail from an infected machine, from someone you know, sending viruses to the accounts of addresses on that machine. The approach has certainly been around for decades and remains in wide use.
And Microsoft taught people, for years, to click on random URL's in emails and random attachments to get all those "features". So your advice to "modern users" is in fact in diametric opposition to Microsoft's historical policies, and is in fact impossible to meaningfully. It's frankly easier to not send attachemnts and always send URL's, except that Microsoft's history of auto-flagging URL's as clickable links has encouraged people not to actually check the contents of the link, but to assume it's usable. It is, in fact, Microsoft's own fault for adding "features" in the face of glaring security holes.
Well, yes. But Microsoft is really attached to that monolithic, proprietary database approach to files. It's of course destabilizing and vulnerable to corruption that's extremely difficult to track down, but it does make the software stuffed with "features" that no one else can or is even allowed ot duplicate, if Microsoft can exert its sway with trade secrets, violating their own published API's, and patent protection.
Defibrillators transmit *current*, not voltage. Voltage is merely potential energy difference: curent is the charge flowing.
It actually makes a difference when designing all kinds of circuitry: if you're unfamilar enough with basic electronics and physics, just trust me on this.
The actual article makes interesting sense. The write-up for slashdot, and the article cited in the Slashdot editorial, are awful and neglect the substance of the article. I'm embarassed at not having found the original article, which is in fact interesting.
The "nerves use sound, not electricity" simplification is overstated and sensationalist: I'm embarassed at having taken it seriously.
And electro-shock, EEG's, retinal implants, and the old squid cell experiments where you stick electrodes in a squid neuron and measure its behavior are all based on a wrong theory, because the idiot who wrote The Fine Article can't figure out where the heat went from conduction of electricity in living matter? It's sitting inside a living organism with lots of *other* thermal processes going on: the heat generation is easily lost in the thermal noise.
I'll believe it when I see experimental evidence: but the article as presented is pretending that God makes timepieces himself because you found a watch in the desert. It's nonsense.
No, there is not even a hint that a subpoena is necessary in Microsoft's policies. While a subpoena is nice, since the Patriot Acts do not require subpoenas and since admitting that a Patriot Act based request for information occurred would itself be a violation of the Patriot Acts, there is almost no way to be sure whether or when such information was released.
Couple that with the per host or per software installation or per user key management of Trusted Computing in the next generation of Microsoft hardware and you have a privacy nightmare.
Not at all. Such data, coupled with the Trusted Computing software integrated into Vista, allows the direct location and tracking of individual hardware platforms by the keys used to authenticate software. And it is or will be coupled with Word and other data documents, so that the author of a document can be identified or tracked by the keys used.
This is guaranteed to be used for law enforcement, industrial espionage, and monitoring political speech. It' inherent in the design of the system and the centralization of the Trusted Computing keys in a primary signature authority's hands (specifically Microsoft!)
This is not quite true. Follow the access_log information in the Yum repository: your install or update request can be analyzed to give quite a lot of information about other software installed, due to the record of other updates or installations associated with that target.
RedHat is also integrating their license keys into RedHat Enterprise 5 and using authorized yum access to RedHat repositories, so yum requests for RHEL 5 software will be uniquely identifiable to individual client machines. The way to avoid this is to designate a licensed RedHat machine inside your network to download *EVERYTHING* to, and use it as a local yum repository for your licensed machines without wasting bandwidth for hundreds of RedHat machines doing the yum-ified version of up2date to the RedHat repository.
This is legal, as near as I can tell, as long as you don't use it to update unlicensed copies of RedHat Enterprise. If you're going to engage in that sort of craziness, avoid it altogether and use CentOS or Fedora Core or something without the registered licensing.
And wait until the "Trusted Computing" features take root in Microsoft software: expect to have your hardware and tools much more firmly locked down, tracked, and accessible to court-order-free investigation by companies like Microsoft and whatever governmental agencies tell them to provide it.
Also, since those "Trusted Computing" keys will often be set to expire, expect to start losing access to data, software, and hardware features unless you pay regular licensing fees. Trusted Computing has other legitimate uses, but these are the abuses which are completely predictable given the way it's designed.
Weavng ribbons *into* hair braids and styles, however, remains amazingly attractive. It looks a bit odd on a beard, but I've met folks who consider it quite attractive.
Not for me: even obtaining the Exchange Server address required negotation through the IT department, and there are intricacies of the OWA URL that may not match properly, depending on the vagaries of your Exchange setup.
How about actual documentation for Evolution. It assumes you already know your local network settings, and provides no or almost no clues on how to actually look up your settings from a live MS Outlook client so you can switch over, or what is necessary on the Exchange server end to support its use.
Of course, with the recent patent deals with Microsoft, expect Novell to cooperate a lot more in supporting Microsoft's closed source, proprietary tools, and MS-violated standards.
I've seen what you describe: the easy way to avoid it is to test with a text-based browser. I've refused to sign a contractor's paycheck until he stopped using Javascript for everything and wrote it as cleaner, standard pop-ups because the Javascript ws simply not reliable for oddball display settings. Every time he tried it in Javascript, I could break it within 5 minutes with a configuration already in use in the same workgroup for a product.
We lost some prettiness of the application that way, but gained incredibly in reliability.
POP3 does have two advantages to the provider: it doesn't support distinct mailboxes on the server side, so that takes a computational load off the server. And every default POP3 client in the world autodeletes mail from the server, so it helps reduce the load off the servers for clueless users.
Malware has also been done in UNIX: take a look at the old Morris Worm of 1988. But it's much more rare.
But expect a lot of departments to spin off their email services to something internal, even without the knowledge of the IT department. And expect someone to challenge it on legal grounds concerning the preservation of documents for accounting or grant renewal purposes.
POP3 can go away. Seriously, the lack of server-side mailboxes and the default behavior of every POP3 client in the universe of automatically deleting email from the server when first installed makes it a nightmare to support for people with laptops or other tools allowed to synchronize with the server. It only takes one accident with a new POP client to accidentally flush someone's entire mail spool from the server and take it out of the backup system, and porting such email *back* from the client to the server to make it accessible to the other clients is a nightmare.
POP3 gains you nothing over IMAP these days, except that it's slightly less work for the mail server to maintain a single mail-spool and force each clients to set up their own set of mailboxes. This is, of course, an insane amount of work for someone who uses multiple mail clients on multiple machines.
Also, neither IMAP nor POP3 should be supported *without* encyrption in any sane environment these days.
Yes, a vaccine for preventing cancer is incredibly exciting. I appreciate your enthusiasm for it.
Now take that $400/full vaccination, and use it for a real sex education class. Figured at 20 girls per class, that's $80,000/year, more than enough for a full-time teacher in most school districts. Since that would help prevent both unwanted pregnancy and the spread of HPV, would that be more life-saving and efficient? I think so. A vaccine for HPV is like body armor in Iraq. It's great if you get shot, but wouldn't it be smarter not to be in the risky zone in the first place?
Slashdot Mirror
Getting NVidia drivers installed for RedHat is extremely awkward. You wind up having to go to a non-RedHat provided repository like Livna. Check out http://rpm.livna.org/livna-switcher.html for notes on how that repository does it better for Fedora Core than RedHat has ever done for their "commercial" releases.
And they're paing several thousand dollars a year for the various consusingly named "server" licenses. The turn-around time of their more complex support questions has not impressed me over the years, even where I've identified a verifiable bug and sent them the patch in the process of getting help.
Oddly, for typical users, the CentOS community which uses a RHEL OS rebuilt from source code actually works better for support. I've actually watched a data center manager on the phone with RedHat sales saying "No, I'm using CentOS because they have longer licenses and the community is more responsive: these are the trouble tickets I called RedHat about and which the CentOS community helped me solve before I even reached a real RedHat engineer to discuss it. And here's the fix."
The main problem seems to be that RedHat took way, way, way too long for its next RHEL release, and the world evolved under them.
I agree. And many of the people who disable it do it incorrectly, by editing their bootloader, rather than using the options in init scripts to set it to "permissive" mode and get reports of what it is detecting, then fix those and publish those fixes or get it into the software package deployments.
Please remember that significant pieces of the Patriot Act are not publicly available, for "national security reasons". That's always a bad sign for civil liberties or personal privacy. Then take a look at the Wikipedia entries on it, which seem well founded, and describe numerous circumstances for "sneak and peek" previews where the existence of a warrant need not be revealed to the person searched (such as warrants from FISA). And note that FISA warrants are not normal criminal search warrants, they're much easier to obtain.
In particular, examine the parts about revealing library records which has led to libraries warning patrons that their borrowing records may be requested without their knowledge.
Not unless they're running virtual environments, not just spare accounts. Build and testing environments *cannot* have random pieces of other people's software and build environments lying around, or you don't know what you're actually testing.
Remember, various sourceforge tools have various dependencies: compiler, web server, glibc and gcc PHP and perl and regexp and make, all of which may affect compilation and proper behavior. That's a nightmare to predict on someone's private server. If folks were willing to run VMware or Xen or something like to provide defined build environments, OK. That makes sense. But to simply open up user accounts to other sourceforge developers randomly is begging for massive trouble.
It's not even just a security problem. A simple bug in PHP can blow away the rest of the Apache owned user space, or overflow any partition on the system that the web server can write to. And it can suck down all the CPU resources, the memory resource, or the inodes on the partition even without using up the disk space. I've seen all of these happen in debugging. Maintaining a reliable build environment and protecting the other build environments from the inevitable errors in one build environment takes work and understanding of security and building scalable infrastructure for auto-testing and autobuilding.
I've done things like this professionally. But my time is not cheap: even if I'm willing to contribute my time (and I might be!), is my free source development time better spent elsewhere? Modesty and a desire for privacy preclude my listing them, but I'm currently involved in active development of 3 notable projects. Should I give up my involvement in those, especially because I'm getting paid for one of them, to work on this?
It's expensive: power, cooling, rent on the building with the rackspace, and bandwidth all add up to a considerable chunk of change. And the professional skills to run such a farm are unusual and expensive to hire, or to contribute. Even a modest Q/A testing and evaluation farm can cost a few hundred thousand dollars a year when you add up all the costs.
Slow down: The Hodgkins Huxley model of neural conduction is far too well supported by experiment, and by the observed behavior changes of nerve in response to ionic concentrations. You can't just throw that out due to a lack of thermal effects.
Moreover, "heat produced by electrical conduction" and the like have to come from somewhere. The amount of energy processed by a cell is limited mostly by glucose metabolism. (We could chat about protein metabolism as well, but let's not get distracted.) That glucose metabolism and related heat production for keeping the cell active in other ways is far higher than that one would expect from electrical conduction by any model I know: delicately measuring "resistive" losses (which do not quite mean the same thing in electrolytic conduction, let me tell you!) is like measure the paint on rocks in an avalanche. You don't bother to measure it by heat or weight, you measure it by more obvious factors like color (or electrical potentials, in this case, since HH style experiments demonstrate it quite well).
Fortunately, the actual original article is much better than the confusing and misleading analysis in the Slashdot lead-in and the linked article.
Of course, many modern viruses send the mail from an infected machine, from someone you know, sending viruses to the accounts of addresses on that machine. The approach has certainly been around for decades and remains in wide use.
And Microsoft taught people, for years, to click on random URL's in emails and random attachments to get all those "features". So your advice to "modern users" is in fact in diametric opposition to Microsoft's historical policies, and is in fact impossible to meaningfully. It's frankly easier to not send attachemnts and always send URL's, except that Microsoft's history of auto-flagging URL's as clickable links has encouraged people not to actually check the contents of the link, but to assume it's usable. It is, in fact, Microsoft's own fault for adding "features" in the face of glaring security holes.
Well, yes. But Microsoft is really attached to that monolithic, proprietary database approach to files. It's of course destabilizing and vulnerable to corruption that's extremely difficult to track down, but it does make the software stuffed with "features" that no one else can or is even allowed ot duplicate, if Microsoft can exert its sway with trade secrets, violating their own published API's, and patent protection.
Defibrillators transmit *current*, not voltage. Voltage is merely potential energy difference: curent is the charge flowing.
It actually makes a difference when designing all kinds of circuitry: if you're unfamilar enough with basic electronics and physics, just trust me on this.
The actual article makes interesting sense. The write-up for slashdot, and the article cited in the Slashdot editorial, are awful and neglect the substance of the article. I'm embarassed at not having found the original article, which is in fact interesting.
The "nerves use sound, not electricity" simplification is overstated and sensationalist: I'm embarassed at having taken it seriously.
And electro-shock, EEG's, retinal implants, and the old squid cell experiments where you stick electrodes in a squid neuron and measure its behavior are all based on a wrong theory, because the idiot who wrote The Fine Article can't figure out where the heat went from conduction of electricity in living matter? It's sitting inside a living organism with lots of *other* thermal processes going on: the heat generation is easily lost in the thermal noise.
I'll believe it when I see experimental evidence: but the article as presented is pretending that God makes timepieces himself because you found a watch in the desert. It's nonsense.
No, there is not even a hint that a subpoena is necessary in Microsoft's policies. While a subpoena is nice, since the Patriot Acts do not require subpoenas and since admitting that a Patriot Act based request for information occurred would itself be a violation of the Patriot Acts, there is almost no way to be sure whether or when such information was released.
Couple that with the per host or per software installation or per user key management of Trusted Computing in the next generation of Microsoft hardware and you have a privacy nightmare.
Not at all. Such data, coupled with the Trusted Computing software integrated into Vista, allows the direct location and tracking of individual hardware platforms by the keys used to authenticate software. And it is or will be coupled with Word and other data documents, so that the author of a document can be identified or tracked by the keys used.
This is guaranteed to be used for law enforcement, industrial espionage, and monitoring political speech. It' inherent in the design of the system and the centralization of the Trusted Computing keys in a primary signature authority's hands (specifically Microsoft!)
This is not quite true. Follow the access_log information in the Yum repository: your install or update request can be analyzed to give quite a lot of information about other software installed, due to the record of other updates or installations associated with that target.
RedHat is also integrating their license keys into RedHat Enterprise 5 and using authorized yum access to RedHat repositories, so yum requests for RHEL 5 software will be uniquely identifiable to individual client machines. The way to avoid this is to designate a licensed RedHat machine inside your network to download *EVERYTHING* to, and use it as a local yum repository for your licensed machines without wasting bandwidth for hundreds of RedHat machines doing the yum-ified version of up2date to the RedHat repository.
This is legal, as near as I can tell, as long as you don't use it to update unlicensed copies of RedHat Enterprise. If you're going to engage in that sort of craziness, avoid it altogether and use CentOS or Fedora Core or something without the registered licensing.
And wait until the "Trusted Computing" features take root in Microsoft software: expect to have your hardware and tools much more firmly locked down, tracked, and accessible to court-order-free investigation by companies like Microsoft and whatever governmental agencies tell them to provide it.
Also, since those "Trusted Computing" keys will often be set to expire, expect to start losing access to data, software, and hardware features unless you pay regular licensing fees. Trusted Computing has other legitimate uses, but these are the abuses which are completely predictable given the way it's designed.
Weavng ribbons *into* hair braids and styles, however, remains amazingly attractive. It looks a bit odd on a beard, but I've met folks who consider it quite attractive.
Not for me: even obtaining the Exchange Server address required negotation through the IT department, and there are intricacies of the OWA URL that may not match properly, depending on the vagaries of your Exchange setup.
How about actual documentation for Evolution. It assumes you already know your local network settings, and provides no or almost no clues on how to actually look up your settings from a live MS Outlook client so you can switch over, or what is necessary on the Exchange server end to support its use.
Of course, with the recent patent deals with Microsoft, expect Novell to cooperate a lot more in supporting Microsoft's closed source, proprietary tools, and MS-violated standards.
I've seen what you describe: the easy way to avoid it is to test with a text-based browser. I've refused to sign a contractor's paycheck until he stopped using Javascript for everything and wrote it as cleaner, standard pop-ups because the Javascript ws simply not reliable for oddball display settings. Every time he tried it in Javascript, I could break it within 5 minutes with a configuration already in use in the same workgroup for a product.
We lost some prettiness of the application that way, but gained incredibly in reliability.
POP3 does have two advantages to the provider: it doesn't support distinct mailboxes on the server side, so that takes a computational load off the server. And every default POP3 client in the world autodeletes mail from the server, so it helps reduce the load off the servers for clueless users.
Malware has also been done in UNIX: take a look at the old Morris Worm of 1988. But it's much more rare.
But expect a lot of departments to spin off their email services to something internal, even without the knowledge of the IT department. And expect someone to challenge it on legal grounds concerning the preservation of documents for accounting or grant renewal purposes.
POP3 can go away. Seriously, the lack of server-side mailboxes and the default behavior of every POP3 client in the universe of automatically deleting email from the server when first installed makes it a nightmare to support for people with laptops or other tools allowed to synchronize with the server. It only takes one accident with a new POP client to accidentally flush someone's entire mail spool from the server and take it out of the backup system, and porting such email *back* from the client to the server to make it accessible to the other clients is a nightmare.
POP3 gains you nothing over IMAP these days, except that it's slightly less work for the mail server to maintain a single mail-spool and force each clients to set up their own set of mailboxes. This is, of course, an insane amount of work for someone who uses multiple mail clients on multiple machines.
Also, neither IMAP nor POP3 should be supported *without* encyrption in any sane environment these days.
Yes, a vaccine for preventing cancer is incredibly exciting. I appreciate your enthusiasm for it.
Now take that $400/full vaccination, and use it for a real sex education class. Figured at 20 girls per class, that's $80,000/year, more than enough for a full-time teacher in most school districts. Since that would help prevent both unwanted pregnancy and the spread of HPV, would that be more life-saving and efficient? I think so. A vaccine for HPV is like body armor in Iraq. It's great if you get shot, but wouldn't it be smarter not to be in the risky zone in the first place?
I'm not: but getting the youngsters a bit more relaxed might help disband young Republican clubs in a lot of places.