If so, we've found the scientific foundation for defining the afterlife.
Seriously, some cell death is vital for correct development of the tissues and complex structures that we all carry around. But by understanding cellular death, we might better understand cellular stasis and cellular growth. Every piece of the puzzle hints at what is missing.
Diskless X clients have been attractive due to the lack of remote configurations and disk/data failures.
Clusters suck up a lot of electricity because of the hardware they support.
I'm sure the next step involves skipping the extra motherboard components (IDE, USB, AGP, etc.) and making the CPU/Memory mount to a TCP/IP Switch backplane. Better yet, drive the thing with low power CPU's so it won't sound like a helicopter prior to take off/reqire a new nuclear plant to power it up/create a new market for Frigidair.
Apart from Apple's "rumored" port of OSX to x86 architecture, there's little chance of this happening.
Apple makes it's money from the hardware it sells, not from the OS. That's why the move to OSX was a bit of genious. Now they have dramatically reduced their OS costs, but their OS sale price was always around $100.
Now if they had to buy x86 from Intel, that would cripple their big revenue stream; hardware. Apple has had a history of hardware innovation (SCSI, Fire-Wire...) I just can't imagine they're seriously considering dumping what they do best.
Look at the x86 market. How many people are pushing the high end hardware? Not many. x86 is all about big CPU's mated to low end subsystems.
Even if the system can automate many of the typical operations that sysadmins perform, it's not going to:
1. Restore itself after a failure.
2. Plan it's expansion.
3. Install it's own software.
(Too many options=user (badly) plays sysadmin, few/no software options=no flexibility)
4. Implement it's own security plan.
(This extends way beyond a box)
5. Manage it's user base
(auto-adding users? Where's the security in that?)
6. Attend meetings.
7. Answer ANY computer question.
8. Know when to throw the power switch
(hung modems make big long distance bills, etc)
9. Evaluate new software.
10. Find lower cost solutions.
11. Answer the phone.
More like saying a Lamborghini compared to a 3rd world moped.
Sure, they'll both get you there, but one lacks a few features.
Not just a marketing ploy, not just a holy war.
on
IBM, MS Critique MySQL
·
· Score: 2, Insightful
Of course IBM and MS will bash Mysql, it's to be expected.
But before you think that the bashing is solely due to marking ploys, think again. Mysql IS lacking many of the features that "real" databases have. In the past MySQL was unabashadly vocal in not including these features as they could be programmed around, and would slow down the database.
Remember, we're not talking about the latest SQL extensions, but common things like FOREIGN KEY, and stored procedures.
MySQL rocks when you don't need the extras, but that's not a reason to migrate to MySQL, or to ignore that MySQL lacks features common to general-purpose databases. Just because MySQL is my favorite "quick and dirty" db, does not make it the best tool for all jobs. That's like arguing that MSAccess is most popular db (by having the most installations) therefore it's the most technically advanced/secure/useful/etc.
Since this is a pre-beta, can the software be considered released?
If you can consider it released, clearly they are in the wrong, but if the company wants some extra eyes to overlook their bug-laden code, what do they do?
Can they not release it, yet distribute it to developers they can trust as to not spill the beans to their competition?
What sort of arrangement must be made to be considered an "inside" developer?
Perhaps I'm simply not ready to burn UL since I haven't heard any FSF / GNU statements demonizing this action.
The intro to the article sets the tone for big business bashing, and the allusions to removed executives and emphasis on mis-pronunciation only create a literary atmosphere of distrust.
Which brings me to my only useful question. Why are we reporting about a "May be" on NewsForge? If we can get a "They violated X" that's real news!
In reguards
1)
C# should look a lot like C and C++
C++ was developed to add a lot of features to C while retaining the formatting of C.
Java was developed to look like C while embracing the object-oriented aspects of Smalltalk.
Since the mindset was to make everything look like C, I have a hard time understanding why you think Java and C# don't look remotely the same.
2)
Not true, most languages have no internal constructs to deal with the internet, and only some languages deal with networking at all.
However, most general purpose languages do use the internet/network. Sometimes this is done by referencing external libraries (as in C), but some languages make the references part of the language.
One advantage of internalizing the internet reference would be the ability to reference file names by URL instead of socket/ip address, but for thoses advantages, there is the cost of overhead.
3)
CLR is assembly code, and so is the JVM.
Only assembly code can run on your computer, and any other type of code must be translated to assembly first. As such, interperters (like the JVM or CLR) take your code and translate it to corresponding assembly commands at run time.
C on the other hand is compiled tieing it to a cpu (and hurting it's ability to run on different machines, a requirement of internet programming)
4.
Programmers only get to choose what the corporate policy dictates. Corporate policy is determined by what sells. Consumers know little about programming languages, but they know what has been advertised. As such, programmers really don't get to freely choose their languages, as such there are always limits on what the client wants and what support is willing to deal with.
Ok, I understand your position..NET is NOT java, but to understand why most people view one as a proprietary version of the other observe:
1..NET is programmed in C# which looks suspiciously like Java (with the exception that C# allows you to directly manipulate pointers, a "backwards to C/C++ compatiblity" issue that seriously weakens the language design of C#).
2..NET is proposed to make internet/network programming easier (much like java)
3..NET code runs on a virtual machine (much like the JVM)
4..NET was initially released as a "Java Killer" As such, you can expect it to be very similar to Java.
I can remember Sun initially reacting to.NET as, "That's ok because while your product is due to be released in 2 years, ours has been working in the field for 2 years" Now I can imagine Sun worrying about.NET "leveraging" Sun out of it's own market much in the same way that IE "leveraged" the (at that time) more powerful and popular Netscape.
I know a lot of the complaints sound like whining, but a little paranoia might be justified. Remember that Sun and Microsoft both worked with the W3C on the XML standard, and just after it was released and agreed to, Microsoft came out with incompatible MSXML. It took serious whistle-blowing and a lot of big money to move them back to standard XML. Since that worked, it is generally believed that without a HUGE ruckus, Microsoft will generally ignore any agreement it has made that doesn't fit with it's business/idealogical model.
In recent news military analysts discovered new air to ground capability for the laser with the potential to destory an entire two story house.
Said a bystander, "It was incredible, but the smell was overpowering." The smell, reminiscent of burnt popcorn, was detected as far as a mile away.
Although environmental activists were busy protesting the demonstration, representatives from the U.S. Department of Agriculture were nearby explaining that the environmental impact was minimal, "After all, it's just popcorn!"
One odd aspect comes to mind directly, modifications to CVS code must be made in two places to have effect.
Modify it once to support the old "there's no network" calls. Modify it again to support the added on "network enabling code".
For most users this is not a visible issue, that is until:
1. You issue a command via network and it doesn't act like a command when you're in the box. 2. You want to know why #1 happens.
Yes, you can argue that having a web server is extra overhead, but that burden is being supported by people who worry about web servers full time, not by those who worry about source code control. And if you're not using a network, why the extra overhead of CVS? RCS would remove the network overhead entirely.
Subversion exists because every now and then, after doing tons of patching, fixing, feature adding, and code tweaking you realize that if you started with a different sort of code architecture life would be easier.
The CVS guys are working on subversion, but "fixing" CVS would not necessairly be the best way to fix their problems. Massive changes in CVS would raise a cry of desperation from the masses of programmers that rely on CVS for day-to-day operation. Also, if it is discovered that a totally new way of handling things is much better than the way CVS works, you encounter nasty if not impossible upgrade difficulties.
People don't want to put their code at risk. Too much time and money goes into it. Subversion "solves" the migration problem by making a totally new project.
It's been awhile since I looked at it, but as I recall:
In 20 words or less:
Subversion is CVS on steroids without being tied down to the history of CVS.
And some of the reasons why are:
Subversion handles directories. CVS does not. Subversion handles file permissions. CVS does not. Subversion makes atomic commits (and rolls back prior to the commit if necessary). CVS cannot, it will stop at the last file processed (and you have to clean it up by hand). Subversion uses HTTP/WebDAV (both reliable protocols). CVS uses it's own protocols which might be less reliable. Subversion performs more operations in constant time. CVS uses more time for the same operations although it is not necessary. Subversion is naitvely client-server. CVS had the client-server added on after the core code was developed creating some odd aspects of operation. Subversion transmits deltas, so costs are porportional to change size. CVS changes are (I believe, not know) proportional to project or file size.
--- Fabrication is the stuff filling the holes of memory.
After building for myself and various friends and family over the years, here's one point of view:
1. It's not cheaper to build. The bottom of the line PC's will always be cheaper than you can build DIY. This is likey due to the powers of mass purchasing and mass markets. On the other hand, if you are putting together a top of the line PC, the markup for a "brand name" is usually not justifiable. "Off brand" top of the line PCs usually have a reasonable price for the "I just want to buy one" types.
2. It's much better to build. The quality of parts that you put into the system are usually much higher than any manufacturer will use. Unless the manufacturer bothers to promote the video card/disk drive/memory/etc by stating the exact make and model, odds are it's a generic whitebox or built-into-the-motherboard. These guys are in a tough market, and they cut corners on the pieces inside to stay in business.
3. It's easier to expand after you build. With a little prior planning, you won't get a motherboard that lacks sufficent PCI/memory/whatever slots. Plus you can call the shots. Want SCSI?, plop it in. As long as you don't get an integrated motherboard, upgrading the sound/video/network card shouldn't be very difficult.
4. It's easier to reinstall after you build. You installed the OS the first time, so you can burn your system down to the ground and build it again. You know it will work the second time, as it was tested by the first install.
Problems encountered:
1. Often you become your own support desk. Not always a problem unless you don't trust your knowledge about the OS you are running or about basic hardware setup. But if you are building this for someone else, remember they will be calling you to sort out their last failed install of XXX.
2. The first install can often be the cruelest. Didn't know that card YYY was unsupported? Plugged that IDE cable in backwards? You'll find out soon.
3. Bugs lurk in partially configured systems. You'll set up that network card driver later, like when you need it... sure you will!
4. Constant upgrades lead to piles of junk. Now that you know the ropes, it's so easy to drop in that latest video card. Never mind that you have no home for all the others you pulled out of your system.
Anyone who is watched with this camera is just asking for it. Privacy concious users of the atmosphere are aware that their photons are not encrypted in transmission. Heck, even little Kodak kiddies can capture and analize them using widely available tools like the One-Shot(tm) obtained from their local grocery store.
That's why it is imperative that security concious users embrace encryption. With a sufficent application of trees, smoke, camoflauge, and other photon encrypting material it is virtually impossible to seperate the subject from the background noise.
That IBM would validate Linux was a big stamp of approval that even PHBs could recogonize.
I can't tell how many times before IBM jumped into the ring I heard from the Linux ignorant, "I hear great things about it, but who uses it?" You could then rattle off names all day without effect.
I'm sorry, but unless I'm severly mistaken the author seemed to think that C# prevented the coding of certain errors.
I'll give C# it's due, it does prevent some very basic coding errors, but with it's backward compatibility enhancements (aka raw pointer artithmetic) it's not nearly as foolproof as it could be, but that's missing the issue.
The answer does not lie withing language A or B (heaven bless all who know B). The answer lies in an engineering practices that design software for maintainance. Such processes are only in their infancy and are usually ill-adapted to dealing with the ton-of-code(tm) that already exists in the market.
I like the newer engineering practices that are coming down the line, but how can I apply them to my 10 year old project with a mix of C / Fortran / SQL / C++ / sh / csh / Tcl / Tk / VBasic which was designed emphasizing output over maintenance?
This seems to fall into the category of "Yes they've been punished, but let's kick them once again!"
If a company has been convicted, and their sentence has been served, where do governments get the idea that they can impose extra-judicial punishment? Remember, we are not talking about a private corporation (which could buy however it pleases), but a governing body which should minimally respect it's judical branch by accepting it's decisions.
01 Cents PIC V99 VALUE.02.
Lack of Communication leads to packaging hell...
on
Is RPM Doomed?
·
· Score: 1
Many fine point have been raised, but my favorite RPM nitpick is found in Mozilla.
For awhile a not-so-fun package conflict existed when Ximian (a fine company) decided to grab a library out of Mozilla (a fine project) and reuse the code in another package (a fine idea).
Unfortunately, this led to packaging a library in it's own rpm (a good idea), but this ONE FILE INCONSISTENCY created all sorts of minor annoyances every time Mozilla hit another milestone (and who doesn't want the bugfixes?)
True, the inconsistencys were minor, and it wasn't difficult to overcome them (after reading Maximum-RPM, which was what I both should have done in the first place and what I recommend to anyone using an RPM based distro) but I felt that a bit of communication between the two packagers could have eliminated this problem.
Then I thought about it some more... How would a project developing something with reusable code (like Mozilla) know that someone else was repackaging it for their needs, and why would they change their packaging model just to satisfy the installation of another product without the need to install the product itself? This does not make sense.
It is easy to want something our way, to want it our way automatically, and to not want to know a thing about it.
After lurking on Slashdot for quite awhile, I have to comment:
This is one of the best articles/editorials I've seen here in quite awhile. Of course it's opinion, but it is well thought out and supported.
Of course, McAfee should also receive it's proper credit for disinfecting millions of users who are just beginning to learn the term "computer security". But like most home security systems, McAfee is getting worse about painting a virus laden world of fear that should make you cringe to touch a computer without it's protective pancea.
Mabye they should rebrand a computer specific can of Lysol too...
Slashdot Mirror
So when all your cells die, you go on living?
If so, we've found the scientific foundation for defining the afterlife.
Seriously, some cell death is vital for correct development of the tissues and complex structures that we all carry around. But by understanding cellular death, we might better understand cellular stasis and cellular growth. Every piece of the puzzle hints at what is missing.
Keep this on the level.
Diskless X clients have been attractive due to the lack of remote configurations and disk/data failures.
Clusters suck up a lot of electricity because of the hardware they support.
I'm sure the next step involves skipping the extra motherboard components (IDE, USB, AGP, etc.) and making the CPU/Memory mount to a TCP/IP Switch backplane. Better yet, drive the thing with low power CPU's so it won't sound like a helicopter prior to take off/reqire a new nuclear plant to power it up/create a new market for Frigidair.
Apart from Apple's "rumored" port of OSX to x86 architecture, there's little chance of this happening.
Apple makes it's money from the hardware it sells, not from the OS. That's why the move to OSX was a bit of genious. Now they have dramatically reduced their OS costs, but their OS sale price was always around $100.
Now if they had to buy x86 from Intel, that would cripple their big revenue stream; hardware. Apple has had a history of hardware innovation (SCSI, Fire-Wire...) I just can't imagine they're seriously considering dumping what they do best.
Look at the x86 market. How many people are pushing the high end hardware? Not many. x86 is all about big CPU's mated to low end subsystems.
Even if the system can automate many of the typical operations that sysadmins perform, it's not going to: 1. Restore itself after a failure. 2. Plan it's expansion. 3. Install it's own software. (Too many options=user (badly) plays sysadmin, few/no software options=no flexibility) 4. Implement it's own security plan. (This extends way beyond a box) 5. Manage it's user base (auto-adding users? Where's the security in that?) 6. Attend meetings. 7. Answer ANY computer question. 8. Know when to throw the power switch (hung modems make big long distance bills, etc) 9. Evaluate new software. 10. Find lower cost solutions. 11. Answer the phone.
More like saying a Lamborghini compared to a 3rd world moped.
Sure, they'll both get you there, but one lacks a few features.
Of course IBM and MS will bash Mysql, it's to be expected.
But before you think that the bashing is solely due to marking ploys, think again. Mysql IS lacking many of the features that "real" databases have. In the past MySQL was unabashadly vocal in not including these features as they could be programmed around, and would slow down the database.
Remember, we're not talking about the latest SQL extensions, but common things like FOREIGN KEY, and stored procedures.
MySQL rocks when you don't need the extras, but that's not a reason to migrate to MySQL, or to ignore that MySQL lacks features common to general-purpose databases. Just because MySQL is my favorite "quick and dirty" db, does not make it the best tool for all jobs. That's like arguing that MSAccess is most popular db (by having the most installations) therefore it's the most technically advanced/secure/useful/etc.
Another fine donation by Sun. Congratulations to them for the offering.
Since this is a pre-beta, can the software be considered released?
If you can consider it released, clearly they are in the wrong, but if the company wants some extra eyes to overlook their bug-laden code, what do they do?
Can they not release it, yet distribute it to developers they can trust as to not spill the beans to their competition?
What sort of arrangement must be made to be considered an "inside" developer?
Perhaps I'm simply not ready to burn UL since I haven't heard any FSF / GNU statements demonizing this action.
The intro to the article sets the tone for big business bashing, and the allusions to removed executives and emphasis on mis-pronunciation only create a literary atmosphere of distrust.
Which brings me to my only useful question. Why are we reporting about a "May be" on NewsForge? If we can get a "They violated X" that's real news!
In reguards 1) C# should look a lot like C and C++ C++ was developed to add a lot of features to C while retaining the formatting of C. Java was developed to look like C while embracing the object-oriented aspects of Smalltalk. Since the mindset was to make everything look like C, I have a hard time understanding why you think Java and C# don't look remotely the same. 2) Not true, most languages have no internal constructs to deal with the internet, and only some languages deal with networking at all. However, most general purpose languages do use the internet/network. Sometimes this is done by referencing external libraries (as in C), but some languages make the references part of the language. One advantage of internalizing the internet reference would be the ability to reference file names by URL instead of socket/ip address, but for thoses advantages, there is the cost of overhead. 3) CLR is assembly code, and so is the JVM. Only assembly code can run on your computer, and any other type of code must be translated to assembly first. As such, interperters (like the JVM or CLR) take your code and translate it to corresponding assembly commands at run time. C on the other hand is compiled tieing it to a cpu (and hurting it's ability to run on different machines, a requirement of internet programming) 4. Programmers only get to choose what the corporate policy dictates. Corporate policy is determined by what sells. Consumers know little about programming languages, but they know what has been advertised. As such, programmers really don't get to freely choose their languages, as such there are always limits on what the client wants and what support is willing to deal with.
Ok, I understand your position. .NET is NOT java, but to understand why most people view one as a proprietary version of the other observe:
.NET is programmed in C# which looks suspiciously like Java (with the exception that C# allows you to directly manipulate pointers, a "backwards to C/C++ compatiblity" issue that seriously weakens the language design of C#).
.NET is proposed to make internet/network programming easier (much like java)
.NET code runs on a virtual machine (much like the JVM)
.NET was initially released as a "Java Killer" As such, you can expect it to be very similar to Java.
.NET as, "That's ok because while your product is due to be released in 2 years, ours has been working in the field for 2 years" Now I can imagine Sun worrying about .NET "leveraging" Sun out of it's own market much in the same way that IE "leveraged" the (at that time) more powerful and popular Netscape.
1.
2.
3.
4.
I can remember Sun initially reacting to
I know a lot of the complaints sound like whining, but a little paranoia might be justified. Remember that Sun and Microsoft both worked with the W3C on the XML standard, and just after it was released and agreed to, Microsoft came out with incompatible MSXML. It took serious whistle-blowing and a lot of big money to move them back to standard XML. Since that worked, it is generally believed that without a HUGE ruckus, Microsoft will generally ignore any agreement it has made that doesn't fit with it's business/idealogical model.
In recent news military analysts discovered new air to ground capability for the laser with the potential to destory an entire two story house. Said a bystander, "It was incredible, but the smell was overpowering." The smell, reminiscent of burnt popcorn, was detected as far as a mile away. Although environmental activists were busy protesting the demonstration, representatives from the U.S. Department of Agriculture were nearby explaining that the environmental impact was minimal, "After all, it's just popcorn!"
One odd aspect comes to mind directly, modifications to CVS code must be made in two places to have effect.
Modify it once to support the old "there's no network" calls. Modify it again to support the added on "network enabling code".
For most users this is not a visible issue, that is until:
1. You issue a command via network and it doesn't act like a command when you're in the box.
2. You want to know why #1 happens.
Yes, you can argue that having a web server is extra overhead, but that burden is being supported by people who worry about web servers full time, not by those who worry about source code control. And if you're not using a network, why the extra overhead of CVS? RCS would remove the network overhead entirely.
Subversion exists because every now and then, after doing tons of patching, fixing, feature adding, and code tweaking you realize that if you started with a different sort of code architecture life would be easier.
The CVS guys are working on subversion, but "fixing" CVS would not necessairly be the best way to fix their problems. Massive changes in CVS would raise a cry of desperation from the masses of programmers that rely on CVS for day-to-day operation. Also, if it is discovered that a totally new way of handling things is much better than the way CVS works, you encounter nasty if not impossible upgrade difficulties.
People don't want to put their code at risk. Too much time and money goes into it. Subversion "solves" the migration problem by making a totally new project.
It's been awhile since I looked at it, but as I recall:
In 20 words or less:
Subversion is CVS on steroids without being tied down to the history of CVS.
And some of the reasons why are:
Subversion handles directories.
CVS does not.
Subversion handles file permissions.
CVS does not.
Subversion makes atomic commits (and rolls back prior to the commit if necessary).
CVS cannot, it will stop at the last file processed (and you have to clean it up by hand).
Subversion uses HTTP/WebDAV (both reliable protocols).
CVS uses it's own protocols which might be less reliable.
Subversion performs more operations in constant time.
CVS uses more time for the same operations although it is not necessary.
Subversion is naitvely client-server.
CVS had the client-server added on after the core code was developed creating some odd aspects of operation.
Subversion transmits deltas, so costs are porportional to change size.
CVS changes are (I believe, not know) proportional to project or file size.
--- Fabrication is the stuff filling the holes of memory.
After building for myself and various friends and family over the years, here's one point of view: 1. It's not cheaper to build. The bottom of the line PC's will always be cheaper than you can build DIY. This is likey due to the powers of mass purchasing and mass markets. On the other hand, if you are putting together a top of the line PC, the markup for a "brand name" is usually not justifiable. "Off brand" top of the line PCs usually have a reasonable price for the "I just want to buy one" types. 2. It's much better to build. The quality of parts that you put into the system are usually much higher than any manufacturer will use. Unless the manufacturer bothers to promote the video card/disk drive/memory/etc by stating the exact make and model, odds are it's a generic whitebox or built-into-the-motherboard. These guys are in a tough market, and they cut corners on the pieces inside to stay in business. 3. It's easier to expand after you build. With a little prior planning, you won't get a motherboard that lacks sufficent PCI/memory/whatever slots. Plus you can call the shots. Want SCSI?, plop it in. As long as you don't get an integrated motherboard, upgrading the sound/video/network card shouldn't be very difficult. 4. It's easier to reinstall after you build. You installed the OS the first time, so you can burn your system down to the ground and build it again. You know it will work the second time, as it was tested by the first install. Problems encountered: 1. Often you become your own support desk. Not always a problem unless you don't trust your knowledge about the OS you are running or about basic hardware setup. But if you are building this for someone else, remember they will be calling you to sort out their last failed install of XXX. 2. The first install can often be the cruelest. Didn't know that card YYY was unsupported? Plugged that IDE cable in backwards? You'll find out soon. 3. Bugs lurk in partially configured systems. You'll set up that network card driver later, like when you need it... sure you will! 4. Constant upgrades lead to piles of junk. Now that you know the ropes, it's so easy to drop in that latest video card. Never mind that you have no home for all the others you pulled out of your system.
The real problem with holographic technology is that it is the next generation of storage medium.
As such it will constantly be just over the horizion.
Stick some project managers on the press releases, have them assign milestones and targeted deadlines.
That way we can claim that it's only 3 years overdue.
Anyone who is watched with this camera is just asking for it. Privacy concious users of the atmosphere are aware that their photons are not encrypted in transmission. Heck, even little Kodak kiddies can capture and analize them using widely available tools like the One-Shot(tm) obtained from their local grocery store.
That's why it is imperative that security concious users embrace encryption. With a sufficent application of trees, smoke, camoflauge, and other photon encrypting material it is virtually impossible to seperate the subject from the background noise.
Oops... my mistake, it's already patented.
That IBM would validate Linux was a big stamp of approval that even PHBs could recogonize.
I can't tell how many times before IBM jumped into the ring I heard from the Linux ignorant, "I hear great things about it, but who uses it?" You could then rattle off names all day without effect.
I'm sorry, but unless I'm severly mistaken the author seemed to think that C# prevented the coding of certain errors.
I'll give C# it's due, it does prevent some very basic coding errors, but with it's backward compatibility enhancements (aka raw pointer artithmetic) it's not nearly as foolproof as it could be, but that's missing the issue.
The answer does not lie withing language A or B (heaven bless all who know B). The answer lies in an engineering practices that design software for maintainance. Such processes are only in their infancy and are usually ill-adapted to dealing with the ton-of-code(tm) that already exists in the market.
I like the newer engineering practices that are coming down the line, but how can I apply them to my 10 year old project with a mix of C / Fortran / SQL / C++ / sh / csh / Tcl / Tk / VBasic which was designed emphasizing output over maintenance?
This seems to fall into the category of "Yes they've been punished, but let's kick them once again!"
.02.
If a company has been convicted, and their sentence has been served, where do governments get the idea that they can impose extra-judicial punishment? Remember, we are not talking about a private corporation (which could buy however it pleases), but a governing body which should minimally respect it's judical branch by accepting it's decisions.
01 Cents PIC V99 VALUE
Many fine point have been raised, but my favorite RPM nitpick is found in Mozilla.
For awhile a not-so-fun package conflict existed when Ximian (a fine company) decided to grab a library out of Mozilla (a fine project) and reuse the code in another package (a fine idea).
Unfortunately, this led to packaging a library in it's own rpm (a good idea), but this ONE FILE INCONSISTENCY created all sorts of minor annoyances every time Mozilla hit another milestone (and who doesn't want the bugfixes?)
True, the inconsistencys were minor, and it wasn't difficult to overcome them (after reading Maximum-RPM, which was what I both should have done in the first place and what I recommend to anyone using an RPM based distro) but I felt that a bit of communication between the two packagers could have eliminated this problem.
Then I thought about it some more... How would a project developing something with reusable code (like Mozilla) know that someone else was repackaging it for their needs, and why would they change their packaging model just to satisfy the installation of another product without the need to install the product itself? This does not make sense.
It is easy to want something our way, to want it our way automatically, and to not want to know a thing about it.
After lurking on Slashdot for quite awhile, I have to comment:
This is one of the best articles/editorials I've seen here in quite awhile. Of course it's opinion, but it is well thought out and supported.
Of course, McAfee should also receive it's proper credit for disinfecting millions of users who are just beginning to learn the term "computer security". But like most home security systems, McAfee is getting worse about painting a virus laden world of fear that should make you cringe to touch a computer without it's protective pancea.
Mabye they should rebrand a computer specific can of Lysol too...