It's defined harshly, but not well. A copy is at http://www.missingkids.com/missingkids/servlet/PageServlet?PageId=1476. It has significant problems with eroitic, rather than pornographic, imagery of children. A great deal of anime focuses on young, Western looking girls with surprisingly large busts and hips being accidentally squeezed or grabbed in the course of their adventures. Is that art, or pornography?
And negotiating with people who try to relicense your code can be even worse. Look up the old OpenBSD/Linux/Broadcom driver issue. It's a fascinating thread, at http://thread.gmane.org/gmane.linux.kernel.wireless.general/1558/focus=1558. And there was clearly a great deal going on behind the scenes with both thoughtful and easily irritated people trying to resolve things.
There's an enormous difference in a business sense between your pursuing a hobby, supporting a work related open source project, and running a side market the company has not yet taken on and using your work time, work resources, or consultation with other company engineers to enhance this project. I've seen far too many junior engineers and excited new managers do precisely this and try to steal everythiung they could in the process, ignoring the existing law and creating intense personnel problems as they tried to hire away their former colleagues, only to bankrupt them with yet another ill-conceived startup. We saw a _lot_ of that in the dotcom era.
Discuss the project first with your manager or the people who work directly with it. Especially with open source, it's usually easy to get a clause added to your IP agreement to allow you to support the project in your own time, or even to get permission to publish your patches. In fact, it can be _required_ if the software is GPL and you publish binaries to your clients or partners, and that's actually a powerful reason to use GPL licensed tools rather than Apache or BSD licensed tools. It protects the programmers from pursuing "ratholes" of customized forks without being able to merge back to the primary code line. I frequently review partner agreements and make sure that our legal department adds appropriate licensing contingencies for projects based on open source software so we can get any useful patches pushed upstream into the code base.
Of course it wasn't deleted. To these businesses, the old personal data is _valuable_. They resell it, as a matter of course, to their corporate partners for targeted advertising. That's why one should use a throwaway email account for such a purpose: not merely to protect your online persona, but to be able to cut off the spew of spam that is inevitable from signing up for such a service.
The bandwidth of fiber optic is ridiculously larger than that of the same weight and diameter of a bundle of copper. So is the electrical cost of a long bundle of fiber, which does not waste anywhere near as much electricity and energy on simple conductive losses of telephone wire driving DC electricity across dozens or thousands of miles of electrical wiring in a single building. Unfortunately, we've turned right around and wasted the resources elsewhere. Providing network traffic to every single electronic device in our homes and offices, "paperless" offices with a dozen times as much useless and unpreserved priinted material going in the recycling bin every day, and the _amazing_ proliferation of electronic spam of every sort continue to overwhelm office resources. Let us also not forget all the glowing LED's and short lifecycle portable devices sitting on recharging stands all day: that represents a very real cost, even though it's coming out of our home and office budgets, not the telephone colmpany's budget.
The tradeoffs are also fascinating Take a very good look at the "fax" business, which remains active for legal documents and all sorts of office document, although every step of the system has been replaced by a superior transmission or reproduction.
Then I suggest you go read Chapter 62 of the Runnymede version of the Magna Carta signed in 1215, which pardoned those who had rebelled against the king, and review the general pardons issued at the coronation of Edward II in 1327. The idea that a pardon somehow imperils "the rule of law" is belied by over 700 years of British law. The similar idea that pardoning a dead man would somehow discredit British law is directly in conflict with the 2006 general pardon of soldiers executed for cowardice in World War I.
I'm afraid NDA prevents me going into details, even pseudonymously, on my professional experiences with this sort of nonsense. But I have _had it_ with this kind of claim of imperiling the moral fiber of a nation from handling an exceptional procedure _written into the law itself_ from people who haven't actually read the law, and cite instead their departmental policies as somehow being even more binding.
No, this is typical British "the procedure is king, even when it's unjust, destructive, and actively interferes with its announced purpose". The British worship of procedure is long established: anything that calls a procedure into question is ignored, even it is, in fact, contravened by procedure from a higher authority..
Because I'd like to recruit people from wherever you learned. The recognition that testing is appropriate, and that you have things to learn, is so rare among working systems personnel that your school and mentors should be congratulated.
If you can, talk to the QA people where you work about their processes. Don't simply take their word: have lunch with them, walk through it with them, and note where they deviate from the planned or published release process and why they skip or redo parts. (This is often political, which I'm afraid is part of testing.) And get involved in some GPL projects with test suites, to learn more about how they're structured.
I'm afraid that your tale of road warrior machismo has nothing to do with the original story, nor the claim that "you don't need dormitories". To house 8000 manufacturing workers within a half hour commute of the manufacturing facility, if you don't use dormitories, your costs will be ludicrously high in salaries or other support of housing costs. And dormitories effectively divorce the employees from day-to-day family and household maintenance requirements, allowing the 8000 employees to work that shift and still get a meal during and after the shift so they're productive the _next_ day.
Short term contract workers wouldn't normally be capable of this kind of goal. To put in a sudden 12-hour shift on unfamiliar equipment with a changed procedure is to encourage very expensive mistakes, such as injuries and ruining the manufacturing equipment itself. Longer term contract workers or employees can do this and do it well: take a look in any US based auto manufacturing plant for constantly handling last minute revisions as the next model year is built.
The political diatribe is also fascinating. The idea that American spirit is allbout "MAKING money" is lethal to quality engineering and research, because both involve longer term projects that need experienced and educated staff who've really learned their way around a field and can integrate with that knowledge. Factors other than money are vital.
A worse threat than the "high priests of IT" are the middle managers who polarize the workplace, teaching people to scheme to overcome management or other departments in order to stake out their own special "turf", often to the detriment of everyone. It occurs in physical space management, office furniture, catering, and contracting companies. In a recent environment I saw, there were _five different_ ticketing systems, only one of which included inventory management, and that department wasn't used by the shipping department because their staff had not been taught, and thus had rejected, the system with inventory management. So they wasted the time of their most important staff filling out and passing around Excel spreadsheets with no tracking of who added, or changed the inventory, of the equipment.
Wi-fi access was worse. There was a written policy banning wi-fi devices without encryption, and a security policy that relied on external firewalls and low internal security. Much of their internal software relied on this to operate. But a casual scan for wi-fi devices revealed unauthorized access points without passwords, inside the company firewall, at _numerous_ locations. The IT staff was actually _blocked_ by the VP in charge of security and told they'd be fired if they did "unauthorized" scans, because it set off alerts in the VP's very expensive and mostly unused "security management toolkit". That security VP was _not_ IT staff: they were an MBA who dressed well and did beautiful pretty flow charts and slides slides, but didn't understand the field.
If the species that were part of the ecosystem are killed off one by one, treating it only on the "big picture" level is going to create numerous disasters that can be avoided by planning and forethought.. Like focusing only on the firewall and ignoring internal security under the claim that "once they're inside our network, we have bigger problems", cleaning up after the "big problem" is solved becomes much more difficult if the "littler problems" are entirely ignored.
Perhaps we can think of this effort as keeping code samples from earlier projects, so we don't have to start over completely when the ecosystem can support coral again.
I've had this occur, crossing legally. When someone is used to urban traffic, checks before crossing,a nd doesn't notice the silent electric or hybrid car that legally pulled into the right hand turn lane and is aobut to make legal right hand turn on a green light when the "walk" sign is active in the same direction, it can be quite dangerous to the pedestrian. It's also disconcerting, even dangerous, to a bicyclist trying to drive legally to have a hybrid car quietly pull into the lane next to them when the cycliest is about to shift lanes or make a turn. Couple this with _parking lots_, where traffic can be very random and a hybrid can pull out from anywhere quite silently, and there are going to be accidents.
Oh, no! 3 mg of chlorine! Shock and horrors, added to the 1500 mg of sodium chloride in the FDA maximum salt intake guidelines!!!!
No one who lives near an ocean is going to freak out about a small extra amount of "chlorine ions" in their water. It's the E. Coli from sewage treatment that they're going to worry about.
Yes, I saw that same episode of law and order with the youth leaders teaching the young bicycle ideas about "Stoic" manhood. The whole thing was very much about how boys become men in grease.
The trick works badly, and is likely to spill liquid nitrogen or shatter metal shards where you do *not* want them.
Yes, it is. The lack of specialized hardware or connectors for the upgrade makes the update fully software dependent. And with modern GPS systems, it makes unauthorized tracking (or unconstitutional law enforcement tracking) a personal privacy risk as well. And it creates fascinating tune-up paths for local mechanics with the skills to manipulate the carburetor and automatic transmission settings. The ability to turn off automatic headlight settings in software is invaluable for illegal activities, and to alter fuel-air ratios for high performance driving is criticial to access in software for modern systems.
I do hope that Ford's engineers are a good team, and not been forced to follow management policy decisions made in hurried moments between policy meetings that affect the safety and reliability of basic engine systems. I've certainly seen that happen with critical manufacturing and networking architectures, with managers too busy or unable to have the meetings with their employees insted of their own managers to listen to negative concerns about subtle flaws in a planned architecture. "We'll fix that if it happens" is a very dangerous approach that I had to deal with yesterday.
This is not true. Look into the "nuclear winter" scenarios where the use of nuclear weapons in oceans creates reflective cloud cover and a significant cooling of Earth's climate.
You've missd some other causes. More than a dozen of those 99 times, the CIO's will be commiting fiscal fraud and charging the other departments for RHEL licenses and installing CentOS instead. I've repeatedly run into this with corporations ignoring the number of licenses they've bought versus the number they've installed, and had a very difficult time negotiating with some of them to prevent any of my personnnel getting involved in such fiscal and legal abuses.
This kind of fiscal abuse is far, far, far too common.
RHN is broken, period. Fortunately, it's easy to set up a local mirror with a single licensed server and use that as your local yum source: just make sure you have licenses for the "channels" you use.
In fact, the "channels" of Red Hat's current licensing and deployments is one of the largest support reasons to use use CentOS or the much better supported and integrated Scientific Linux. Having to track the licensing and activate separate chennels was quite surprising when a partner bought server class Red Hat licenses, because the workstation versions had it and because CentOS had it, and they spent quite a bit of political capital apoligizing to their developers when their installer tools failed to discover OpenOffice components without painful manual "channel" activation.
But if you're not a licensed Red Hat customer, you have no leverage to get them to include new drivers in the kernels. Another partner ran into this with their new 10G network components, when they'd assumed without checking that the new components from HP were supported because "HP supports Linux" but found that they couldn't run it on their locked down RHEL 5.2 systems which they refused to do updates on. I had the opportunity speak with the engineer who had to resolve this, and put him in touch with the kernel engineers at Red Hat he needed to talk to and find out what components besides the kernel itself he'd need to update, becuase another client had had other issues they needed resolved and I still had the engineer's number. (And I note that the Red Hat and Linux kernels were solving bugs that Microsoft had not even acknowledged yet, so that wasn't even an option.)
The CentOS community would have been utterly useless: they have no access to Red Hat's engineers who actually do the kernel updates for new hardware, and Red Hat's engineers actually *wrote* some of the drivers. So the licenses to get support there were invaluable.
To back this up, I've looked. There are _no_ mass drivers on earth, anywhere, that reach a muzzle velocity of even 200 MPH. Reaching orbit takes about 18,000 MPH. That's roughly 9 times the velocity, and thus roughly 81 times the energy per unit mass of the projectile. The technology has only ever worked, and only badly, in demonstrations. The "EMALS" system planned for launching aircraft from aircraft carriers actually launched a plane _backwards_ in testing, and the world's newest aircraft carrier is facing the possibility of being the world's largest floating helicopter launching pad. The technology has been a failure at every planned milestone.
There is a great deal to like about the idea of mass drivers, but the engineering simply has not yet worked.
Or one set of ads. Browsers are not for _advertisers_, they are for _viewers_. We can work with advertising to pay for content we want, such as on Slashdot, but forcing additional paging and scrolling for screens of variable sizes and user layouts is simply selling out to advertisers.
I'm afraid the article doesn't give enough credit for this failure to Google's insistence on real names. I know roughly a dozen people who've used pseudonyms online for decades who could not get an account in their recognized pseudonym, and others who attempted to use it, found a problem with their alias, and were _locked out_ of their other Google services without warning or a reasonable path to restore those services. If you use Gmail for personal business purposes, this is completely unacceptable and will absolutely deter people from using the new service.
The service may be exciting, but it's not exciting enough to justify that kind of headache and risk when FaceBook is a few clicks away. And even Slashdot allows modest pseudonymity. While the potential for abuse of pseudonyms is very real, the need for them is also very real indeed, and rejecting them by the unpredictable standards in use at Google alienated many socially active people of the online world, exactly the customers they _wanted_.
Google has shown no sign of being willing to change this "you must use your real name" policy. Until they relax that, I will not touch it.
I'm afraid that you've missed some of the moral points of those stories, and of when they were written. Human sacrifice was _much_ more common at the time of Abraham, and has been throughout human history. What made Abraham's story unusual is that his god _released_ the child, and told Abraham to sacrifice an animal, instead. That was a pretty odd tale _for that period_. A typical tale would have had Abraham refusing to sacrifice Isaac, and suffering for his refusal.
The story of Lot offering his daughters to the neighbors at Sodom and Gomorrah is also often misread. The guests had "guest right" by staying in Lot's home, and it was Lot's and his family's task to protect them at any cost. Guest right is a _serious_ issue in many cultures, and is why welcoming someone into your home is done so carefully.
There is, unfortunately, no "universal morality" by which those acts can be "universally condemned". Both suffer profoundly from protecting or obeying the "god" and the god's representatives and rules at the cost of your own family, but that's a vital lesson for any civilized society. Loyalty to the larger group has to be given _some_ precedence over the interests of yourself or your own family, or the civilization will be ruined by greedy families. Every major religion and every civilization teaches this, or they won't make it through a bad winter or a drought year.
> Debian 5 is outdated. Debian 6 ("Squeeze") is the new Stable.
If only. It's often difficult if not impossible to run production services on it without reaching out to "testing" or "development" repositories which are poorly managed and integrated, discard old packages from their repositories so there is no reference, and change package names without warning. Coupled with the tendency of updates to be applied on top of locally edited configurations written by admins who ignore package management, and the resulting chaos is predictable.
I am _exhausted_ with Debian admins who insist on manually editing httpd.conf and xorg.conf and refuse to use the various configuration subdirectories, then act so surprised when their changes are lost or do not integrate well with new packages.
Slashdot Mirror
It's defined harshly, but not well. A copy is at http://www.missingkids.com/missingkids/servlet/PageServlet?PageId=1476. It has significant problems with eroitic, rather than pornographic, imagery of children. A great deal of anime focuses on young, Western looking girls with surprisingly large busts and hips being accidentally squeezed or grabbed in the course of their adventures. Is that art, or pornography?
And negotiating with people who try to relicense your code can be even worse. Look up the old OpenBSD/Linux/Broadcom driver issue. It's a fascinating thread, at http://thread.gmane.org/gmane.linux.kernel.wireless.general/1558/focus=1558. And there was clearly a great deal going on behind the scenes with both thoughtful and easily irritated people trying to resolve things.
There's an enormous difference in a business sense between your pursuing a hobby, supporting a work related open source project, and running a side market the company has not yet taken on and using your work time, work resources, or consultation with other company engineers to enhance this project. I've seen far too many junior engineers and excited new managers do precisely this and try to steal everythiung they could in the process, ignoring the existing law and creating intense personnel problems as they tried to hire away their former colleagues, only to bankrupt them with yet another ill-conceived startup. We saw a _lot_ of that in the dotcom era.
Discuss the project first with your manager or the people who work directly with it. Especially with open source, it's usually easy to get a clause added to your IP agreement to allow you to support the project in your own time, or even to get permission to publish your patches. In fact, it can be _required_ if the software is GPL and you publish binaries to your clients or partners, and that's actually a powerful reason to use GPL licensed tools rather than Apache or BSD licensed tools. It protects the programmers from pursuing "ratholes" of customized forks without being able to merge back to the primary code line. I frequently review partner agreements and make sure that our legal department adds appropriate licensing contingencies for projects based on open source software so we can get any useful patches pushed upstream into the code base.
Of course it wasn't deleted. To these businesses, the old personal data is _valuable_. They resell it, as a matter of course, to their corporate partners for targeted advertising. That's why one should use a throwaway email account for such a purpose: not merely to protect your online persona, but to be able to cut off the spew of spam that is inevitable from signing up for such a service.
The bandwidth of fiber optic is ridiculously larger than that of the same weight and diameter of a bundle of copper. So is the electrical cost of a long bundle of fiber, which does not waste anywhere near as much electricity and energy on simple conductive losses of telephone wire driving DC electricity across dozens or thousands of miles of electrical wiring in a single building. Unfortunately, we've turned right around and wasted the resources elsewhere. Providing network traffic to every single electronic device in our homes and offices, "paperless" offices with a dozen times as much useless and unpreserved priinted material going in the recycling bin every day, and the _amazing_ proliferation of electronic spam of every sort continue to overwhelm office resources. Let us also not forget all the glowing LED's and short lifecycle portable devices sitting on recharging stands all day: that represents a very real cost, even though it's coming out of our home and office budgets, not the telephone colmpany's budget.
The tradeoffs are also fascinating Take a very good look at the "fax" business, which remains active for legal documents and all sorts of office document, although every step of the system has been replaced by a superior transmission or reproduction.
Then I suggest you go read Chapter 62 of the Runnymede version of the Magna Carta signed in 1215, which pardoned those who had rebelled against the king, and review the general pardons issued at the coronation of Edward II in 1327. The idea that a pardon somehow imperils "the rule of law" is belied by over 700 years of British law. The similar idea that pardoning a dead man would somehow discredit British law is directly in conflict with the 2006 general pardon of soldiers executed for cowardice in World War I.
I'm afraid NDA prevents me going into details, even pseudonymously, on my professional experiences with this sort of nonsense. But I have _had it_ with this kind of claim of imperiling the moral fiber of a nation from handling an exceptional procedure _written into the law itself_ from people who haven't actually read the law, and cite instead their departmental policies as somehow being even more binding.
No, this is typical British "the procedure is king, even when it's unjust, destructive, and actively interferes with its announced purpose". The British worship of procedure is long established: anything that calls a procedure into question is ignored, even it is, in fact, contravened by procedure from a higher authority..
Because I'd like to recruit people from wherever you learned. The recognition that testing is appropriate, and that you have things to learn, is so rare among working systems personnel that your school and mentors should be congratulated.
If you can, talk to the QA people where you work about their processes. Don't simply take their word: have lunch with them, walk through it with them, and note where they deviate from the planned or published release process and why they skip or redo parts. (This is often political, which I'm afraid is part of testing.) And get involved in some GPL projects with test suites, to learn more about how they're structured.
I'm afraid that your tale of road warrior machismo has nothing to do with the original story, nor the claim that "you don't need dormitories". To house 8000 manufacturing workers within a half hour commute of the manufacturing facility, if you don't use dormitories, your costs will be ludicrously high in salaries or other support of housing costs. And dormitories effectively divorce the employees from day-to-day family and household maintenance requirements, allowing the 8000 employees to work that shift and still get a meal during and after the shift so they're productive the _next_ day.
Short term contract workers wouldn't normally be capable of this kind of goal. To put in a sudden 12-hour shift on unfamiliar equipment with a changed procedure is to encourage very expensive mistakes, such as injuries and ruining the manufacturing equipment itself. Longer term contract workers or employees can do this and do it well: take a look in any US based auto manufacturing plant for constantly handling last minute revisions as the next model year is built.
The political diatribe is also fascinating. The idea that American spirit is allbout "MAKING money" is lethal to quality engineering and research, because both involve longer term projects that need experienced and educated staff who've really learned their way around a field and can integrate with that knowledge. Factors other than money are vital.
A worse threat than the "high priests of IT" are the middle managers who polarize the workplace, teaching people to scheme to overcome management or other departments in order to stake out their own special "turf", often to the detriment of everyone. It occurs in physical space management, office furniture, catering, and contracting companies. In a recent environment I saw, there were _five different_ ticketing systems, only one of which included inventory management, and that department wasn't used by the shipping department because their staff had not been taught, and thus had rejected, the system with inventory management. So they wasted the time of their most important staff filling out and passing around Excel spreadsheets with no tracking of who added, or changed the inventory, of the equipment.
Wi-fi access was worse. There was a written policy banning wi-fi devices without encryption, and a security policy that relied on external firewalls and low internal security. Much of their internal software relied on this to operate. But a casual scan for wi-fi devices revealed unauthorized access points without passwords, inside the company firewall, at _numerous_ locations. The IT staff was actually _blocked_ by the VP in charge of security and told they'd be fired if they did "unauthorized" scans, because it set off alerts in the VP's very expensive and mostly unused "security management toolkit". That security VP was _not_ IT staff: they were an MBA who dressed well and did beautiful pretty flow charts and slides slides, but didn't understand the field.
If the species that were part of the ecosystem are killed off one by one, treating it only on the "big picture" level is going to create numerous disasters that can be avoided by planning and forethought.. Like focusing only on the firewall and ignoring internal security under the claim that "once they're inside our network, we have bigger problems", cleaning up after the "big problem" is solved becomes much more difficult if the "littler problems" are entirely ignored.
Perhaps we can think of this effort as keeping code samples from earlier projects, so we don't have to start over completely when the ecosystem can support coral again.
I've had this occur, crossing legally. When someone is used to urban traffic, checks before crossing,a nd doesn't notice the silent electric or hybrid car that legally pulled into the right hand turn lane and is aobut to make legal right hand turn on a green light when the "walk" sign is active in the same direction, it can be quite dangerous to the pedestrian. It's also disconcerting, even dangerous, to a bicyclist trying to drive legally to have a hybrid car quietly pull into the lane next to them when the cycliest is about to shift lanes or make a turn. Couple this with _parking lots_, where traffic can be very random and a hybrid can pull out from anywhere quite silently, and there are going to be accidents.
Oh, no! 3 mg of chlorine! Shock and horrors, added to the 1500 mg of sodium chloride in the FDA maximum salt intake guidelines!!!!
No one who lives near an ocean is going to freak out about a small extra amount of "chlorine ions" in their water. It's the E. Coli from sewage treatment that they're going to worry about.
Those weren't women.
Yes, I saw that same episode of law and order with the youth leaders teaching the young bicycle ideas about "Stoic" manhood. The whole thing was very much about how boys become men in grease.
The trick works badly, and is likely to spill liquid nitrogen or shatter metal shards where you do *not* want them.
Yes, it is. The lack of specialized hardware or connectors for the upgrade makes the update fully software dependent. And with modern GPS systems, it makes unauthorized tracking (or unconstitutional law enforcement tracking) a personal privacy risk as well. And it creates fascinating tune-up paths for local mechanics with the skills to manipulate the carburetor and automatic transmission settings. The ability to turn off automatic headlight settings in software is invaluable for illegal activities, and to alter fuel-air ratios for high performance driving is criticial to access in software for modern systems.
I do hope that Ford's engineers are a good team, and not been forced to follow management policy decisions made in hurried moments between policy meetings that affect the safety and reliability of basic engine systems. I've certainly seen that happen with critical manufacturing and networking architectures, with managers too busy or unable to have the meetings with their employees insted of their own managers to listen to negative concerns about subtle flaws in a planned architecture. "We'll fix that if it happens" is a very dangerous approach that I had to deal with yesterday.
This is not true. Look into the "nuclear winter" scenarios where the use of nuclear weapons in oceans creates reflective cloud cover and a significant cooling of Earth's climate.
You've missd some other causes. More than a dozen of those 99 times, the CIO's will be commiting fiscal fraud and charging the other departments for RHEL licenses and installing CentOS instead. I've repeatedly run into this with corporations ignoring the number of licenses they've bought versus the number they've installed, and had a very difficult time negotiating with some of them to prevent any of my personnnel getting involved in such fiscal and legal abuses.
This kind of fiscal abuse is far, far, far too common.
RHN is broken, period. Fortunately, it's easy to set up a local mirror with a single licensed server and use that as your local yum source: just make sure you have licenses for the "channels" you use.
In fact, the "channels" of Red Hat's current licensing and deployments is one of the largest support reasons to use use CentOS or the much better supported and integrated Scientific Linux. Having to track the licensing and activate separate chennels was quite surprising when a partner bought server class Red Hat licenses, because the workstation versions had it and because CentOS had it, and they spent quite a bit of political capital apoligizing to their developers when their installer tools failed to discover OpenOffice components without painful manual "channel" activation.
But if you're not a licensed Red Hat customer, you have no leverage to get them to include new drivers in the kernels. Another partner ran into this with their new 10G network components, when they'd assumed without checking that the new components from HP were supported because "HP supports Linux" but found that they couldn't run it on their locked down RHEL 5.2 systems which they refused to do updates on. I had the opportunity speak with the engineer who had to resolve this, and put him in touch with the kernel engineers at Red Hat he needed to talk to and find out what components besides the kernel itself he'd need to update, becuase another client had had other issues they needed resolved and I still had the engineer's number. (And I note that the Red Hat and Linux kernels were solving bugs that Microsoft had not even acknowledged yet, so that wasn't even an option.)
The CentOS community would have been utterly useless: they have no access to Red Hat's engineers who actually do the kernel updates for new hardware, and Red Hat's engineers actually *wrote* some of the drivers. So the licenses to get support there were invaluable.
That should ahve been "2000 MPH", not "200 MPH. Please excuse my error.
To back this up, I've looked. There are _no_ mass drivers on earth, anywhere, that reach a muzzle velocity of even 200 MPH. Reaching orbit takes about 18,000 MPH. That's roughly 9 times the velocity, and thus roughly 81 times the energy per unit mass of the projectile. The technology has only ever worked, and only badly, in demonstrations. The "EMALS" system planned for launching aircraft from aircraft carriers actually launched a plane _backwards_ in testing, and the world's newest aircraft carrier is facing the possibility of being the world's largest floating helicopter launching pad. The technology has been a failure at every planned milestone.
There is a great deal to like about the idea of mass drivers, but the engineering simply has not yet worked.
Or one set of ads. Browsers are not for _advertisers_, they are for _viewers_. We can work with advertising to pay for content we want, such as on Slashdot, but forcing additional paging and scrolling for screens of variable sizes and user layouts is simply selling out to advertisers.
I'm afraid the article doesn't give enough credit for this failure to Google's insistence on real names. I know roughly a dozen people who've used pseudonyms online for decades who could not get an account in their recognized pseudonym, and others who attempted to use it, found a problem with their alias, and were _locked out_ of their other Google services without warning or a reasonable path to restore those services. If you use Gmail for personal business purposes, this is completely unacceptable and will absolutely deter people from using the new service.
The service may be exciting, but it's not exciting enough to justify that kind of headache and risk when FaceBook is a few clicks away. And even Slashdot allows modest pseudonymity. While the potential for abuse of pseudonyms is very real, the need for them is also very real indeed, and rejecting them by the unpredictable standards in use at Google alienated many socially active people of the online world, exactly the customers they _wanted_.
Google has shown no sign of being willing to change this "you must use your real name" policy. Until they relax that, I will not touch it.
I'm afraid that you've missed some of the moral points of those stories, and of when they were written. Human sacrifice was _much_ more common at the time of Abraham, and has been throughout human history. What made Abraham's story unusual is that his god _released_ the child, and told Abraham to sacrifice an animal, instead. That was a pretty odd tale _for that period_. A typical tale would have had Abraham refusing to sacrifice Isaac, and suffering for his refusal.
The story of Lot offering his daughters to the neighbors at Sodom and Gomorrah is also often misread. The guests had "guest right" by staying in Lot's home, and it was Lot's and his family's task to protect them at any cost. Guest right is a _serious_ issue in many cultures, and is why welcoming someone into your home is done so carefully.
There is, unfortunately, no "universal morality" by which those acts can be "universally condemned". Both suffer profoundly from protecting or obeying the "god" and the god's representatives and rules at the cost of your own family, but that's a vital lesson for any civilized society. Loyalty to the larger group has to be given _some_ precedence over the interests of yourself or your own family, or the civilization will be ruined by greedy families. Every major religion and every civilization teaches this, or they won't make it through a bad winter or a drought year.
> Debian 5 is outdated. Debian 6 ("Squeeze") is the new Stable.
If only. It's often difficult if not impossible to run production services on it without reaching out to "testing" or "development" repositories which are poorly managed and integrated, discard old packages from their repositories so there is no reference, and change package names without warning. Coupled with the tendency of updates to be applied on top of locally edited configurations written by admins who ignore package management, and the resulting chaos is predictable.
I am _exhausted_ with Debian admins who insist on manually editing httpd.conf and xorg.conf and refuse to use the various configuration subdirectories, then act so surprised when their changes are lost or do not integrate well with new packages.