>Department said Social Security numbers were included in the public database because >doing so was the common practice years ago when the database was first created, >before online identity theft was as well-known a threat as it is today.... and if any company gave that same excuse they would still be liable, investigated, and be sued.
I wonder if they will inform the individuals whose numbers were compromised?
VMS was a great operating system (except for I/O throughput). Anyone that was an engineer at DEC would say so. It was COMMON for those systems to stay up for years without a reboot (software upgrades did nto need rebooting), and it had a lot to do with the design of the software and the developers rather than the hardware. The OS had proper protections of resources and privileges, software was released with the constant concern of migration or backward compatibility, and languages all had a common call API -- making it easy to link objects compiled in different languages. Commands were user-friendly, and the GUI (if you wanted it) was X (Motif at that time). Remember that you could also not just control user privs, but about 32 other items such as disk quota, how much memory they could consume, the maximum CPU time before being forced to swap, etc. From a business perspective, a multi-user, time-sharing, reliable, networking (supported TCP/IP, LAT, DECnet, SNA,...), and popular (DEC was #2 in the world) system was a good choice. The enemy was the mainframe -- a non-dristributed, expensive investment. It's sad developers that did not grow up in this environment will not be able to see it as anything but old technology.
BTW -- yes, Y2k had little to no impact on VMS. It was designed to be date "correct" from the beginning. Extremely few Y2k patches for VMS appeared, and they were mostly for applications rather than the OS.
What killed VMS was being tied to the expensive hardware it ran on. When support for a sytem costs you 5-6 figures a year compared to buying a Linux/NT server for $1-$5k brand new, plus the VAX hardware was not compatible with other systems (except for the Alpha perhaps), you had to question it's value in your server room. Don't forget the large power consuption of the older systems as well.
If DEC had been allowed to release VMS for Intel as a product (which DID exist as a prototype within DEC), it might still be a viable choice today. I understood this did not happen due to the agreement between Microsoft and DEC when they partnered to port applications to NT and cross-train personnel for PC support -- a smart move on Microsoft's part, as it would certainly have prevented NT from catching on.
Even now Linux and Microsoft strive to achieve the same level of clustering integration VMS enjoyed almost transparently. Unix/Linux is much more flexible and efficient and cost-effective, but this comes at a trade-off of being more technical to use and with less administrative control. Eventually the "lack of applications" problem will fade away.
Hopefully Linux adoption can return us to those "no Microsoft products in use here" days.
Keith-who-was-a-VMS-product-developer-and-admin- at -DEC
You remember wierdly then. It was not an uppercase only system. Perhaps you were on an upper-case only terminal. VMS was case insensitive on input, but displayed and accepted lowercase as normal. Even the very first thing you saw, "Username:", was not in uppercase.
I was a VMS engineer for 13 years (I worked at DEC for 5 of them), have been involved in Linux for 10 years, and a user of other unix's for more than 5 years. I have written fairly well known products for all 3. NT, VMS, and unix all have strengths and weakness that give them niches, but let me report my personal experience on VMS. I can tell many people voicing opinions on VMS have no real experience with it.
First; I can tell you that VMS and NT has nothing in common from the perspective of an end-user or programmer. The architcture in common is in the OS level, and NT is a bastardized version of it. Do NOT believe that if you are familiar with NT that you have any experience in VMS.
Second; VMS is much more secure than NT or unix. Why? Well; first by default it came secure "out of the box" (except for default passwords). Networking did not allow free access into the system unless you set it up that way. Also, there were 32 individualized levels of privileges, not 2 (root or non-root, or the weird levels of NT). Privileges and file securities were defined in a manner that ryou really could set up a printer admin, password admin, backup operator, etc. without compromising system security. You controlled what people could get to and how much of the system resources there were limited to. In no way was this because people are more savey now or do it for fame -- people have always been savy and tried to claim fame. Unix came originaly from a universe where the goal was to share information. VMS originated from a universe for business applications and where sharing was to be "set up". It was frowned on to do things like preview email and automatically run shells on network connects. Logging was decent, controls were good, and systems fairly secure by default (provided the admins changed the stupid passwords). ACLs, disk quotas, and "temporary privileges" were the norm in VMS. Sure there were hacking break-ins, and with the internet audience larger now than in VMS days there are more of them, but I believe VMS would have held it's own just slightly ahead of unix today.
Third; VMS was stable (unlike NT). I was personally aware of VMS systems that had not been rebooted in over 5 YEARS! Like unix, software installs and process terminations did not require the OS to fail or reboot.
Fourth; The language calling standard. Anything could call easily anything!:-) Fifth; It was much more user friendly. Commands were obvious, and switches were universal. For those being honest, unix commands are the most cryptic of all OS's (mv for rename, cp for copy, ls for directory or list, man for help?). You have to learn to use unix -- vms you could pretty much type broken english or "help".
Sixth; Clustering. Even today, nothing matches the ease and functionality of VMS clustering. All the computers looked and acted as one, and a device on one was availabel to anyone. And talk about single sign-on.
Seventh; DECnet networking was better than anything before it, and was as good as tcp/ip. Today, networking has surpassed it. But this did not really matter, and VMS supported both well.
Eighth; Like unix, the GUI is a tool, not a necessity.
Nineth; great documentation, and plenty of it, all in a standardized layout.
Tenth; portability. VMS ran perfectly on VAX and Alpha CPUs, and programs written for one ran unchanged on the other. The only reason that there was no VMS/intel was due to business situations, not technology.
But there were downsides...
The main reason VMS died was that it ran on expensive, proprietary hardware. Microsoft made it's way into the server room and intel hardwaqre was cheaper and multi-os compatible. If DEC has released VMS on intel as a product (it did exist internally, after all we are engineers), we might actually have 3 competing server OS's today.
File I/O. VMS I/O was designed to be reliable, with lots of abilities for control, recovery, and logging. The result was that it sucked in performance. unix I/O beats the pants off VMS I/O, even when you turned all the VMS features off. VMS systems make terrible file servers.
Licensing. It was DEC that introduced software licensing (as a software enforced tool with database). This was a side-effect of networking and clustering becoming the norm. Before this; you bought something you owned it. I remember cringing the first time I installed a license -- knowing that it artifically crippled software to limit it to nn users. It was much more fun before this nonsense.
Poor kernel Customization. While MicroVMS broke up the "kernel" into 4 major pieces that could be installed or left out, linux allows to build a kernel that does or has nothing you don't want in it.
Hardware detection. All VMS administrators remember the horrors of making sure VAX boards were installed in the correct slots and in the correct order so that SYSGEN could discover them, and still having to enter manual overrides to get it all working.
Performance tuning was an art. There were so many parameters that could be manipulated, and so many inter-dependencies, that tuning was quite a feat. SYSTEM FEEDBACK helped a lot!, but you really needed to learn the tools (SPA).
VMS also would have all the same difficulties that unix and linux have competing with Microsoft today (compatible office apps, desktop GUI, etc.).
When I worked at Red Hat and had talks with Compaq on HA technologies, I did ask on several occassions for them to consider releasing VMS (or at least VMS clustering) into Open Source. Never happened though:(
>The Tivo has a 30 second commercial skip feature too, contrary to popular opinion. SELECT-PLAY-SELECT-3-0-SELECT.
This also is deceptive. You are just fast forwarding for 30 secs. You still watch the commercial, and it's not intelligent. The older Replays actually JUMP the 30 seconds. And in the new Replay4000, the unit actually detects and skips the commercial.
You aren't the only one with a head crash story like that. I remember one site where their RP04 disk was operating so fast, that the heads came off and smashed the drive cover.
I also have in my trophy collection an RK05 disk, and Altair 680 literature, but I must confess that it's still fun to flip the PDP-11 switches ones in a while:-). It was fun toggling in boot programs.
I knew someone that started a PDP-11 RSX BBS running in his basement. When the next month's electric bill showed up and was several hundred dollars more, he killed the whole thing.
I well remember the WANK "Worm against nuclear killers" worm. I was a DEC engineer and had to remove it from the systems in CT that got hit.
It was harmless, but interesting. Somewhere someone connected a system to DEC's internal network for a few hours (this would have been necessary for the DECnet addressing to work) and ran it. Basically, The worm (written entirely in DCL) tried to gain access to a systems by brut force -- trying to log into every numerical DECnet node address by using transparent DECnet and default accounts created by the various DEC products, and pitched default or obvious passwords at them. If it got in (which did happen because Admins were not good about changing default passwords or closing transparent DECnet), it then captured the list of logged in users and emailed them back to that connected system. If it had gained privileges, it also modified your welcome banner to display the announcement that you've been hit.
Then this unknown user disconnected that system, and reconnecedt it again the next day (different net address) and try hacking into all the user accounts it collected. Since I already did a cleanup and changed all the passwords, they didn't get in so I don't know what would have happened at that point. Never heard wether the users got caught.
>I think I'll print this out for my Grandma to read!
Your parents perhaps, but Grandma?
All this happened less than 20 years ago. I'm in my early 40's, but my whole career started in high school with DEC 20's with punch cards and PDP-11's with RSTS and papertape (110 baud modems), then RSX & RT11, VAX/VMS, Alphas, and finally intel (which was a technology step backward at that time, especially with windows). The pace of computer technology is incredibly fast. 20 years ago, half a meg of disk and 64k of memory was a lot.
Languages move fast too. First interpreted BASIC (I skipped COBOL because I started on DEC systems), then compiled BASIC, FORTRAN, C, then C++/smalltalk/java/perl/whatever... Every 4-5 years you have to learn a new language.
Expect that everything you are writing will be obsolete within 10 years, and that something will come to rival Linux within 20.
Also expect that 10 years into your career, you'll be encountering younger people that believe what occured before them was bogus, and that what they are doing is totally new & different:-)
I've worked for many software companies, including Digital Equipment and Red Hat. In the research world, your work is part of a process moving toward a goal. In the business world, R&D are almost always treated as overhead, even when designing new product.
In previous companies, I have met many programmers just out of college whose work productivity and priorities would have been much better if they had been placed in a situation where they did not get a paycheck unless the customer was satisified.
If you want experience that will help with your career, I'd choose the internship at a company.
However if you have ANY desire spend some time in a pure research environment (where money is granted, research is not overhead, etc), then do that internship first and later move on. Pure research roles do not appear very often in the business world.
Speaking as a lead developer on Red Hat's piranha team, I found the
whole situation extremely educational.
First there was ISS. In all their communications to us, you got
the impression that they believed they found the "holy grail" of
security holes. Even though they assured us in private phone
calls that they understood this was not a backdoor, they announced
it that way anyway. I would think that more than anyone, an
organization that wants to serve as a public source of security
information would use accurate terminology in their reporting.
The general public certainly isn't able to.
As it has been pointed out here, this was not a backdoor, and
the situation only allowed read-only access to unconfigured
data. You had to change the password in order to configure the
product. It was documented that you needed to change the
password, and piranha's GUI would not allow you to enter valid
data into the configuration until you did change it.
Then there was the press. The first public media to report
the story was Microsoft owned MSNBC. What does that say?
Then later stories came out saying that this was the terrible
risk of using open source, or indicated that Red Hat's R&D is poor.
I have worked in R&D several Fortune 500 companies, and Red Hat
is not worse than any of them (and in several cases they are much
better). I can tell you that (and this is going to sound corny)
Red Hat takes security reports VERY seriously! They are always
given priority and It's standard operating procedure to check
them and (if needed) release patches as fast as possible. We had
a piranha patch done within 24hrs and out-the-door within
48. This is the ADVANTAGE of open source, and is much better
than being forced to wait for a single source of proprietary
software to even admit there is a problem, let alone quickly
provide a solution. Thanks for recognizing we did this.
Many people looked at piranha before it was released; this was
something that simply did not occur to anyone. After all; piranha
doesn't set this password, it's the default behavior of the
os/applications when you create an account via the mechanism that
was called.
Is the media biased? I think so. Almost no one called us to
get the correct information, and the few that did are the
only ones that presented a more balanced story. I think some do
not want to alienate their main source of income -- MS product
advertisers. Others may just be lazy.
Even a month ago, when the
High Availability Server product was announced, some reports
couldn't help but add something like "piranha, the software
that had a security backdoor problem back in Feb" -- as if
this was still important. You can find some in tail end
of the HA web site doc area at
http://people.redhat.com/kbarrett/HA/documentation .html
I'm happy to see I'm not the only one that sees these things.
It must mean that Linux is being effective, or else they
wouldn't waste so much time or effort on it.
While I cannot make an ISO available for a 600meg download image of the product, all of the components that you add to the Red Hat Linux distribution WILL always be available on the HA web site (and in the box).
[A properly formatted response] A couple of points.
1. I too am from Digital Equipment, and although Linux clustering has quite a way to go before it matches what was available under VMS/TrueClusters, it IS clustering by definition (i.e. making several machines appear as doing the work of one). This is largely due to LVS.
2. The "downloadable" version is pretty much 6.2 + "upgrades to bring it to 6.2.16-2" + "the latest piranha and ivpsadm" posted on our new web site. You'll get a functionally equal system, but not identical because you did not run the HA installer. I will probably post the comps and install cript for those that want to recreate that.
3. Piranha will no longer be bundled in Red Hat Linux, but will continue to be available via download, raw hide, and the HA product.
4. As people have pointed out, the price on the product is for the year's support, the bundled software (since the Linux release won't have it), and the hardcopy book. There is a dedicated web site for this project at
A couple of points. 1. I too am from Digital Equipment, and although Linux clustering has quite a way to go before it matches what was available under VMS/TrueClusters, it IS clustering by definition (i.e. making several machines appear as doing the work of one). This is largely due to LVS. 2. The "downloadable" version is pretty much 6.2 + "upgrades to bring it to 6.2.16-2" + "the latest piranha and ivpsadm" posted on our new web site. You'll get a functionally equal system, but not identical because you did not run the HA installer. I will probably post the comps and install script for those that want to recreate that. 3. Piranha will no longer be bundled in Red Hat Linux, but will continue to be available via download and the HA product. 4. As people have pointed out, the price on the product is for the year's support, the bundled software (since the Linux release won't have it), and the hardcopy book. There is a dedicated web site for this project at http:://people.redhat.com/kbarrett/HA/ Thanks Keith Barrett Red Hat HA Team Leader
Slashdot Mirror
>Department said Social Security numbers were included in the public database because ... and if any company gave that same excuse they would still be liable, investigated, and be sued.
>doing so was the common practice years ago when the database was first created,
>before online identity theft was as well-known a threat as it is today.
I wonder if they will inform the individuals whose numbers were compromised?
VMS was a great operating system (except for I/O throughput). Anyone that was an engineer at DEC would say so. It was COMMON for those systems to stay up for years without a reboot (software upgrades did nto need rebooting), and it had a lot to do with the design of the software and the developers rather than the hardware. The OS had proper protections of resources and privileges, software was released with the constant concern of migration or backward compatibility, and languages all had a common call API -- making it easy to link objects compiled in different languages. Commands were user-friendly, and the GUI (if you wanted it) was X (Motif at that time). Remember that you could also not just control user privs, but about 32 other items such as disk quota, how much memory they could consume, the maximum CPU time before being forced to swap, etc. From a business perspective, a multi-user, time-sharing, reliable, networking (supported TCP/IP, LAT, DECnet, SNA, ...), and popular (DEC was #2 in the world) system was a good choice. The enemy was the mainframe -- a non-dristributed, expensive investment. It's sad developers that did not grow up in this environment will not be able to see it as anything but old technology.
- at -DEC
BTW -- yes, Y2k had little to no impact on VMS. It was designed to be date "correct" from the beginning. Extremely few Y2k patches for VMS appeared, and they were mostly for applications rather than the OS.
What killed VMS was being tied to the expensive hardware it ran on. When support for a sytem costs you 5-6 figures a year compared to buying a Linux/NT server for $1-$5k brand new, plus the VAX hardware was not compatible with other systems (except for the Alpha perhaps), you had to question it's value in your server room. Don't forget the large power consuption of the older systems as well.
If DEC had been allowed to release VMS for Intel as a product (which DID exist as a prototype within DEC), it might still be a viable choice today. I understood this did not happen due to the agreement between Microsoft and DEC when they partnered to port applications to NT and cross-train personnel for PC support -- a smart move on Microsoft's part, as it would certainly have prevented NT from catching on.
Even now Linux and Microsoft strive to achieve the same level of clustering integration VMS enjoyed almost transparently. Unix/Linux is much more flexible and efficient and cost-effective, but this comes at a trade-off of being more technical to use and with less administrative control. Eventually the "lack of applications" problem will fade away.
Hopefully Linux adoption can return us to those "no Microsoft products in use here" days.
Keith-who-was-a-VMS-product-developer-and-admin
Obviously someone under 35 years old with no real experience in VMS.
You remember wierdly then. It was not an uppercase only system. Perhaps you were on an upper-case only terminal. VMS was case insensitive on input, but displayed and accepted lowercase as normal. Even the very first thing you saw, "Username:", was not in uppercase.
I was a VMS engineer for 13 years (I worked at DEC for 5 of them), have been involved in Linux for 10 years, and a user of other unix's for more than 5 years. I have written fairly well known products for all 3. NT, VMS, and unix all have strengths and weakness that give them niches, but let me report my personal experience on VMS. I can tell many people voicing opinions on VMS have no real experience with it.
:-)
:(
First; I can tell you that VMS and NT has nothing in common from the perspective of an end-user or programmer. The architcture in common is in the OS level, and NT is a bastardized version of it. Do NOT believe that if you are familiar with NT that you have any experience in VMS.
Second; VMS is much more secure than NT or unix. Why? Well; first by default it came secure "out of the box" (except for default passwords). Networking did not allow free access into the system unless you set it up that way. Also, there were 32 individualized levels of privileges, not 2 (root or non-root, or the weird levels of NT). Privileges and file securities were defined in a manner that ryou really could set up a printer admin, password admin, backup operator, etc. without compromising system security. You controlled what people could get to and how much of the system resources there were limited to. In no way was this because people are more savey now or do it for fame -- people have always been savy and tried to claim fame. Unix came originaly from a universe where the goal was to share information. VMS originated from a universe for business applications and where sharing was to be "set up". It was frowned on to do things like preview email and automatically run shells on network connects. Logging was decent, controls were good, and systems fairly secure by default (provided the admins changed the stupid passwords). ACLs, disk quotas, and "temporary privileges" were the norm in VMS. Sure there were hacking break-ins, and with the internet audience larger now than in VMS days there are more of them, but I believe VMS would have held it's own just slightly ahead of unix today.
Third; VMS was stable (unlike NT). I was personally aware of VMS systems that had not been rebooted in over 5 YEARS! Like unix, software installs and process terminations did not require the OS to fail or reboot.
Fourth; The language calling standard. Anything could call easily anything!
Fifth; It was much more user friendly. Commands were obvious, and switches were universal. For those being honest, unix commands are the most cryptic of all OS's (mv for rename, cp for copy, ls for directory or list, man for help?). You have to learn to use unix -- vms you could pretty much type broken english or "help".
Sixth; Clustering. Even today, nothing matches the ease and functionality of VMS clustering. All the computers looked and acted as one, and a device on one was availabel to anyone. And talk about single sign-on.
Seventh; DECnet networking was better than anything before it, and was as good as tcp/ip. Today, networking has surpassed it. But this did not really matter, and VMS supported both well.
Eighth; Like unix, the GUI is a tool, not a necessity.
Nineth; great documentation, and plenty of it, all in a standardized layout.
Tenth; portability. VMS ran perfectly on VAX and Alpha CPUs, and programs written for one ran unchanged on the other. The only reason that there was no VMS/intel was due to business situations, not technology.
But there were downsides...
The main reason VMS died was that it ran on expensive, proprietary hardware. Microsoft made it's way into the server room and intel hardwaqre was cheaper and multi-os compatible. If DEC has released VMS on intel as a product (it did exist internally, after all we are engineers), we might actually have 3 competing server OS's today.
File I/O. VMS I/O was designed to be reliable, with lots of abilities for control, recovery, and logging. The result was that it sucked in performance. unix I/O beats the pants off VMS I/O, even when you turned all the VMS features off. VMS systems make terrible file servers.
Licensing. It was DEC that introduced software licensing (as a software enforced tool with database). This was a side-effect of networking and clustering becoming the norm. Before this; you bought something you owned it. I remember cringing the first time I installed a license -- knowing that it artifically crippled software to limit it to nn users. It was much more fun before this nonsense.
Poor kernel Customization. While MicroVMS broke up the "kernel" into 4 major pieces that could be installed or left out, linux allows to build a kernel that does or has nothing you don't want in it.
Hardware detection. All VMS administrators remember the horrors of making sure VAX boards were installed in the correct slots and in the correct order so that SYSGEN could discover them, and still having to enter manual overrides to get it all working.
Performance tuning was an art. There were so many parameters that could be manipulated, and so many inter-dependencies, that tuning was quite a feat. SYSTEM FEEDBACK helped a lot!, but you really needed to learn the tools (SPA).
VMS also would have all the same difficulties that unix and linux have competing with Microsoft today (compatible office apps, desktop GUI, etc.).
When I worked at Red Hat and had talks with Compaq on HA technologies, I did ask on several occassions for them to consider releasing VMS (or at least VMS clustering) into Open Source. Never happened though
These are not my gadgets! ;-)
>The Tivo has a 30 second commercial skip feature too, contrary to popular opinion. SELECT-PLAY-SELECT-3-0-SELECT.
This also is deceptive. You are just fast forwarding for 30 secs. You still watch the commercial, and it's not intelligent. The older Replays actually JUMP the 30 seconds. And in the new Replay4000, the unit actually detects and skips the commercial.
I also have in my trophy collection an RK05 disk, and Altair 680 literature, but I must confess that it's still fun to flip the PDP-11 switches ones in a while
---
Keith Barrett (kgb)
Red Hat HA Team
visit http://ftp.uk.linux.org/~kgb/Caterham7, then email me
---
Keith Barrett (kgb)
Red Hat HA Team
It's only for 2 years, then you have to do it again.
---
Keith Barrett (kgb)
Red Hat HA Team
SIXBIT and RAD50 were different OK. I was wrong.
RADIX50 was a 40-character set system. The "50" was an octal number
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
Red Hat HA Team
I also remember SNAKE and TANK -- two good multi-user VT100 graphic games.
I also remember when ADVENTURE and DUNGEON first came out. Lost 5 months of my life to those games!
---
Keith Barrett (kgb)
Red Hat HA Team
Remember the cleaning brushes that would come out when the drive spun up?
---
Keith Barrett (kgb)
Red Hat HA Team
Basically, squishing 3 characters into 2 (or 24 bits into 16) because the character set did not include lowercase.
It was commonly used to store passwords on RSTS/E
(boy, I remember this stuff like it was yesterday).
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
Red Hat HA Team
It was harmless, but interesting. Somewhere someone connected a system to DEC's internal network for a few hours (this would have been necessary for the DECnet addressing to work) and ran it. Basically, The worm (written entirely in DCL) tried to gain access to a systems by brut force -- trying to log into every numerical DECnet node address by using transparent DECnet and default accounts created by the various DEC products, and pitched default or obvious passwords at them. If it got in (which did happen because Admins were not good about changing default passwords or closing transparent DECnet), it then captured the list of logged in users and emailed them back to that connected system. If it had gained privileges, it also modified your welcome banner to display the announcement that you've been hit.
Then this unknown user disconnected that system, and reconnecedt it again the next day (different net address) and try hacking into all the user accounts it collected. Since I already did a cleanup and changed all the passwords, they didn't get in so I don't know what would have happened at that point. Never heard wether the users got caught.
---
Keith Barrett (kgb)
Red Hat HA Team
Your parents perhaps, but Grandma?
All this happened less than 20 years ago. I'm in my early 40's, but my whole career started in high school with DEC 20's with punch cards and PDP-11's with RSTS and papertape (110 baud modems), then RSX & RT11, VAX/VMS, Alphas, and finally intel (which was a technology step backward at that time, especially with windows). The pace of computer technology is incredibly fast. 20 years ago, half a meg of disk and 64k of memory was a lot.
Languages move fast too. First interpreted BASIC (I skipped COBOL because I started on DEC systems), then compiled BASIC, FORTRAN, C, then C++/smalltalk/java/perl/whatever ... Every 4-5 years you have to learn a new language.
Expect that everything you are writing will be obsolete within 10 years, and that something will come to rival Linux within 20.
Also expect that 10 years into your career, you'll be encountering younger people that believe what occured before them was bogus, and that what they are doing is totally new & different :-)
---
Keith Barrett (kgb)
Red Hat HA Team
I've worked for many software companies, including Digital Equipment and Red Hat. In the research world, your work is part of a process moving toward a goal. In the business world, R&D are almost always treated as overhead, even when designing new product.
In previous companies, I have met many programmers just out of college whose work productivity and priorities would have been much better if they had been placed in a situation where they did not get a paycheck unless the customer was satisified.
If you want experience that will help with your career, I'd choose the internship at a company. However if you have ANY desire spend some time in a pure research environment (where money is granted, research is not overhead, etc), then do that internship first and later move on. Pure research roles do not appear very often in the business world.
---
Keith Barrett (kgb)
Red Hat HA Team
First there was ISS. In all their communications to us, you got the impression that they believed they found the "holy grail" of security holes. Even though they assured us in private phone calls that they understood this was not a backdoor, they announced it that way anyway. I would think that more than anyone, an organization that wants to serve as a public source of security information would use accurate terminology in their reporting. The general public certainly isn't able to.
As it has been pointed out here, this was not a backdoor, and the situation only allowed read-only access to unconfigured data. You had to change the password in order to configure the product. It was documented that you needed to change the password, and piranha's GUI would not allow you to enter valid data into the configuration until you did change it.
Then there was the press. The first public media to report the story was Microsoft owned MSNBC. What does that say? Then later stories came out saying that this was the terrible risk of using open source, or indicated that Red Hat's R&D is poor. I have worked in R&D several Fortune 500 companies, and Red Hat is not worse than any of them (and in several cases they are much better). I can tell you that (and this is going to sound corny) Red Hat takes security reports VERY seriously! They are always given priority and It's standard operating procedure to check them and (if needed) release patches as fast as possible. We had a piranha patch done within 24hrs and out-the-door within 48. This is the ADVANTAGE of open source, and is much better than being forced to wait for a single source of proprietary software to even admit there is a problem, let alone quickly provide a solution. Thanks for recognizing we did this.
Many people looked at piranha before it was released; this was something that simply did not occur to anyone. After all; piranha doesn't set this password, it's the default behavior of the os/applications when you create an account via the mechanism that was called.
Is the media biased? I think so. Almost no one called us to get the correct information, and the few that did are the only ones that presented a more balanced story. I think some do not want to alienate their main source of income -- MS product advertisers. Others may just be lazy.
Even a month ago, when the High Availability Server product was announced, some reports couldn't help but add something like "piranha, the software that had a security backdoor problem back in Feb" -- as if this was still important. You can find some in tail end of the HA web site doc area at http://people.redhat.com/kbarrett/HA/documentation .html
I'm happy to see I'm not the only one that sees these things. It must mean that Linux is being effective, or else they wouldn't waste so much time or effort on it.
---
Keith Barrett (kgb)
Red Hat HA Team
Anyone have it tatoo'd on their back yet so that they can attempt to outlaw skin?
The HA parts of the product are entirely GPL.
Keith Barrett Red Hat HA Team
1. I too am from Digital Equipment, and although Linux clustering has quite a way to go before it matches what was available under VMS/TrueClusters, it IS clustering by definition (i.e. making several machines appear as doing the work of one). This is largely due to LVS.
2. The "downloadable" version is pretty much 6.2 + "upgrades to bring it to 6.2.16-2" + "the latest piranha and ivpsadm" posted on our new web site. You'll get a functionally equal system, but not identical because you did not run the HA installer. I will probably post the comps and install cript for those that want to recreate that.
3. Piranha will no longer be bundled in Red Hat Linux, but will continue to be available via download, raw hide, and the HA product.
4. As people have pointed out, the price on the product is for the year's support, the bundled software (since the Linux release won't have it), and the hardcopy book. There is a dedicated web site for this project at
http:://people.redhat.com/kbarrett/HA/
Thanks
Keith Barrett
Red Hat HA Team Leader
A couple of points. 1. I too am from Digital Equipment, and although Linux clustering has quite a way to go before it matches what was available under VMS/TrueClusters, it IS clustering by definition (i.e. making several machines appear as doing the work of one). This is largely due to LVS. 2. The "downloadable" version is pretty much 6.2 + "upgrades to bring it to 6.2.16-2" + "the latest piranha and ivpsadm" posted on our new web site. You'll get a functionally equal system, but not identical because you did not run the HA installer. I will probably post the comps and install script for those that want to recreate that. 3. Piranha will no longer be bundled in Red Hat Linux, but will continue to be available via download and the HA product. 4. As people have pointed out, the price on the product is for the year's support, the bundled software (since the Linux release won't have it), and the hardcopy book. There is a dedicated web site for this project at http:://people.redhat.com/kbarrett/HA/ Thanks Keith Barrett Red Hat HA Team Leader