A couple of other individuals and I posted comments on this on Amazon's site a year or so ago to warn off potential subscribers. It's very, very old news. They haven't changed their ways.
They should also change the lock LEDs to Luxor 5 watt batwing emitter LEDs. That would further encourage eyes-off typing skills, because of the brightness of the LED (nearly 120 lumens). That would probably draw too much current through the keyboard, though, and smoke the USB/PS2 driver chipset.
Looks to me like classic Sam Clemens (Mark Twain). Take a $15 keyboard, add whitewash (remove letters), add propaganda (ubergeekness) and they'll flock.
I haven't had a major Microsoft update yet that didn't cause some problem. I've been supporting heterogeneous networks for 22 years in a number of organizations, and I've done a lot of consulting.
You can't really claim MS's automatic updating tools are any better than the standards discussed here. Microsoft's online automatic updates blew out an entire computer center for me once. Something in the "critical fix" refused to work with the standard AMI SCSI controllers in all my Win servers (60+). Imagine having to back the update out of each of them manually. Took two days and 6 people. And I have never allowed MS auto updates to run again.
On the other hand, the Unix systems have been pretty solid. I don't consider scripts bad things. They're easy to build, easy to maintain. And good standard tools like rdist and rsynch work across lots of platforms.
But, you left out one thing in your comparison, The Bungi. If you include the "after conversion" salary, you have to include the "before conversion" salary for a MS tech that's worth his/her salt. I've never had to add a body to support *nix systems when MS systems were already in place. Often, a judicious bit of training, which costs far less than $15,000, is all that's needed.
Sounds good in theory. Seldom in practice does the CEO support the idea of making all his/her users responsible for their computers. Has something to do with doing the job they're paid to do. Usually, they're doing something else that's needed. And that's why we have jobs.:)
I'm not missing any key points. You are missing the point. I'm only discussing at this time how SCO could argue this, given your earlier comments. But I've also pointed out where SCO's arguments could break down.
On Linus: I honestly believe he did recreate errno.h, but as I said, it would be somewhat difficult to prove that in court, because of the ability to copy and edit. And if you're defending Linus, it's kind of off-key to say he had no good reason to change the error numbers and cause some things to break. After all, his stuff worked fine, it was the attempt to directly port lots of stuff over from other *nixes that caused problems because of the shift in numbers. I can't find him at fault because other people didn't port stuff real well.
You need to understand, also, that 10 years didn't just "go by" after the AIX JFS development. It was a continuing evolution of features and capabilities, continued development. IBM's development by the same team, after 10 years of work on the AIX JFS, means that it's going to be difficult for IBM to prove "no derivation" based solely on the claim of a new source _base_, should the question ever be raised by SCO. And Steve Best did _not_ claim that no code was reused, only that a new source base was started. Nor did he claim that JFS2 is completely different in concept from JFS1. His claim is more one of performance and scalability, and scalability was the claimed reason to start a fresh code base. It is not clear that IBM would win that one in court. That is the key point here.
But again, it doesn't matter, because the original JFS was also IBM's, and it would be nearly impossible to prove derivation from anything "SCO" on that. I believe that was your original point. I'm saying that part of your original point was flawed, but that's addressed above.
I've had enough of this. I made a comment to state a fact on POSIX/FIPS, and that SCO can't claim any kind of violation with Microsoft and NT POSIX compliance. And your point on errno.h was that it was in the POSIX standard, but it was not. The standard didn't define that, and if it had, then SCO couldn't have claimed it as their IP.
I'm not interested in beating this dead horse anymore. And honestly, these picky tangent issues aren't interesting, either. I won't be reading this thread any longer. Post all you want.
Well, really, again, my point was that POSIX standards included the interface to the o/s, but not really the.h files. And your "proof" that errno.h is original because the numbers are different is not proof at all. Anyone could copy it, then change the numbers. I'm only pointing out that your argument wasn't based on substantive evidence. But that's not important nor is it worth arguing about further.
I'm an ardent Unix and Linux supporter, and I am not implying by any means that Linus did something untoward. I've replaced a lot of Microsoft and other systems with Linux and other *nixes over the years, and I even contributed some code to OSS.
As far as JFS goes, you need to read this: http://www.osnews.com/story.php?news_id=69. In it, Steve Best describes how the JFS team redesigned JFS and started with new source. In another published article, he describes key team members as being members of the original AIX JFS team. (See slide 8 here: http://www.perl.org/tpc/2002/sessions/best_steve.p df ) And in another part of one article, he states that JFS for AIX was around for 10 years before they started the new JFS. That's a very long time.
This doesn't meet the standard definition of a "sterile" redevelopment environment. He never explicitly states that _no_ code was reused. He only says they started with a new source base.
Fact remains that they would have a difficult time proving that it wasn't a derived work of their own work. But the crux is that even if it was derived from the AIX system, which in all likelihood the design was, at the very least, the original work was IBM's and not SCO's. And I like IBM's work. I never much cared for SCO's, and I certainly don't care for SCO's attitude these days.
Well, actually, the POSIX standard doesn't define.h files, as I recall. The standard just defined the interface for the system calls, and how libraries would react as a standard. Setting up the headers in the.h files was up to each company that wrote a compiler or built a library. If the code was an exact copy, then IBM might have stepped on it... And errno.h goes back a lot farther than Linux, so you'd have to prove to me that Linus typed it in. Personally, I suspect it came from GNU, and their compilers were available for years before Linus started on Linux.
But you missed my point altogether, which was that Microsoft didn't need to purchase a license to do POSIX. I was merely agreeing with wfberg on that point.
And OS/2 and Warp never had a journalling file system quite like what IBM implemented in AIX. As I recall, that file system actually appeared in AIX first, and early versions were being developed on the CS9000. You may not recall that, an early IBM Xenix computer that predated their RS6000 AIX system. There was some research done while the CS9000 was out on a journalling file system. That was in 1983, and OS/2 didn't start to surface until 1986.
Well, that's my recollection, anyway. I worked with all those systems, and I remember being pleasantly surprised to see some of the AIX developments make it to OS/2. I was a big user of OS/2 for a long time, right next to my AIX - RS6000s and Chromatics systems.
POSIX was a large _set_ of FIPS standards from NIST back when it had a different acronym. There was a standard for the o/s system calls, for interfaces, for libraries, etc. I don't recall the exact numbers, but it was like FIPS 152, 153, etc.
And you're correct. They were standards that were transferred to the IEEE. Mostly because NIST decided that they didn't really need to push for standards anymore, as a result of a decision at Commerce. Some of this was probably pressure because DoC and NBS/NIST were attempting to enforce POSIX compliance for all government systems, and about 70% of government "systems" were desktop computers running Wintel, which was not POSIX compliant. It was a huge nightmare in $$$$$$$$.
Now, IEEE has it, and the world has evolved since POSIX, and it's not really an issue any more, at least for the US Gov.
No one needs a license to "do POSIX." POSIX is merely a set of Federal Information Processing Standards (FIPS) - definitions of how various o/s interfaces and services operate, among other things. There is no true "POSIX" to license. A number of companies wrote dramatically different releases of software that met the POSIX standards.
You might be right, the future is difficult to predict. But as health cares hire salaried people with initial offerings and negotiations, that amounts to an opening bid. I know plenty of people that didn't take a job with a given organization because of the low starting salary (in their view, at least). And I know of situations where organizations didn't hire the best or most qualified individual as a result of the salary limitations.
Unless this model changes drastically, they have a base salary for their normal working shift. Extra money for extra shift work above and beyond the base seems to be the issue here. But I can't see individuals accepting lower base salaries than they would have in a normal hiring system. They still have to pay their bills.
And I've been on the other side of the fence and been frustrated because I didn't have enough of a budget to hire the person I really wanted, and no support from upper management to increase the budget. So I had to fill a position with a less qualified individual, and figure out how to get by with less expertise.
I've hired a lot of tech people, and I bring salary up at varying points, depending on the circumstances and the individual. Once I had a Ph.D. apply for a pretty low-level management job. He must have misunderstood the posting. So I told him the salary range and he withdrew immediately.
Again, I don't know, but I don't see salaries going down over the long haul anywhere I look. If bidding were to have an effect, I can't see how it could be a significant one. Just my opinion, though. My crystal ball shattered last week.
To far too many people in the world, salaries already count more than the quality of the work they perform. Generally, except in monopolies, companies care about quality of work and the resulting profit. I've seen bidding systems of all kinds, and I don't see a problem, providing that in each case, parameters are established to determine who qualifies to bid.
The original story was about the same nurses already working for the hospital, trying to get them to work extra shifts for extra money. If they're already qualified to work there, a couple hundred of the comments posted here don't apply.
This is all about finding a way to take care of patients at a time when health care professionals are in high demand. And we all complain about high health care costs as it is. Hospitals need extra help and cannot find it. Overtime from within is an acceptable and traditional practice.
Having had 4 nurses in the family, the traditional on-call practice was always tough because they were assigned by supervisors. This bidding at least puts a bit of control back in the hands of the nurses. "I'll take call on Christmas if you pay me enough," is not all bad.
While this may sound like serious issues to some, I feel compelled to point out that in reality, the omni-directional antennas buried inside wireless laptops or mobile devices do not have the gain characteristics necessary to get significant past the 30db limitation with the power available from the card itself. The vast majority of wireless device users would probably use power controls to eek out a few extra minutes of battery time, and a subset would be interested in maximum gain. Yes, there would be some that would strive to increase power. But to get 24db gain, you have to have a fairly stable antenna, highly directional, and that's not practical for laptops in typical use.
There are other ways to bump up power, but they just don't always make sense. Sure, you can add an inline amp in your transmitter, but unless there's a similarly amped system at the other end of your transmission, it doesn't gain you a lot.
If law enforcement was a valid reason for disallowing a technical capability, we could easily start discussing governors for cars to prevent them from exceeding the speed limit. I certainly would never have mine retrofitted:)
I'd prefer to have open source choice. If a driver has to be kept proprietary for business reasons, no matter what they are, let them support their hardware with non-kernel modules. It's their business choice. I won't necessarily agree with it, but mine is one of many opinions.
An ideal wireless NIC driver would be open source. It would dynamically adjust gain levels up and down to balance power consumption (battery life) without compromising data integrity.
And if someone wants to tweak the open source for max power, power to them!
SBC stands for Smith Bailey Coleman or something like that. It's actually the name of three founding partners. It is NOT for southwestern bell, they just happened to grow from and subsume southwestern bell.
I wish I could remember the names accurately, but I have forgotten in the last couple of years.
I have known a number of people working for Ameritech, now SBC. They're mostly engineering types, who spend a great deal of time dealing with similar issues. SBC has steadily decreased its engineering staff and increased its sales staff over the last 12 years. The CWA staff has remained somewhat level. Yet, there has been more buildout of systems, and a continuing advancement in plant capability throughout, resulting in tougher jobs for everyone. Now the engineers are facing a probably sales quota, too. Pretty stupid, huh? There aren't enough engineers to work all the jobs assigned now. I asked for an estimate on a job last summer and it took nearly two months to get it. The engineers were backlogged that long. I think SBC is run by some real idiots who've forgotten what customers need, especially those of us dealing with large projects.
At one time, SCO Xenix was the only protected-mode operating system available for the pre-286 non-protected mode hardware sold by Intel. In 1985, I supported a number of Suns, Apollos, Masscomps, and ATT systems running Unix variants including BSD 3.x and 4.x. The only way we could work with pcs effectively was to put SCO Xenix on them. Eventually, other, better alternatives became available as Intel developed more powerful hardware (such as the 286 with supervisory mode, and the 386 even later). We shifted to Microport's Unix Sys V for the 286/386, but continued to use Xenix as it evolved on a variety of equipment, until it was no longer practical. Dell shipped it for a number of years as an alternative operating system. Though it wasn't perfect, it was far superior to MS systems.
By the way, though we usually called it "S C O" the company reps we talked to usually pronounced it "sko" with a long o, even in 1985.
Slashdot Mirror
A couple of other individuals and I posted comments on this on Amazon's site a year or so ago to warn off potential subscribers. It's very, very old news. They haven't changed their ways.
Hasn't anyone here read Michael Chichton's newest book? It makes some very, very good reading on global warming.
They should also change the lock LEDs to Luxor 5 watt batwing emitter LEDs. That would further encourage eyes-off typing skills, because of the brightness of the LED (nearly 120 lumens). That would probably draw too much current through the keyboard, though, and smoke the USB/PS2 driver chipset.
Looks to me like classic Sam Clemens (Mark Twain). Take a $15 keyboard, add whitewash (remove letters), add propaganda (ubergeekness) and they'll flock.
I haven't had a major Microsoft update yet that didn't cause some problem. I've been supporting heterogeneous networks for 22 years in a number of organizations, and I've done a lot of consulting.
You can't really claim MS's automatic updating tools are any better than the standards discussed here. Microsoft's online automatic updates blew out an entire computer center for me once. Something in the "critical fix" refused to work with the standard AMI SCSI controllers in all my Win servers (60+). Imagine having to back the update out of each of them manually. Took two days and 6 people. And I have never allowed MS auto updates to run again.
On the other hand, the Unix systems have been pretty solid. I don't consider scripts bad things. They're easy to build, easy to maintain. And good standard tools like rdist and rsynch work across lots of platforms.
But, you left out one thing in your comparison, The Bungi. If you include the "after conversion" salary, you have to include the "before conversion" salary for a MS tech that's worth his/her salt. I've never had to add a body to support *nix systems when MS systems were already in place. Often, a judicious bit of training, which costs far less than $15,000, is all that's needed.
Sounds good in theory. Seldom in practice does the CEO support the idea of making all his/her users responsible for their computers. Has something to do with doing the job they're paid to do. Usually, they're doing something else that's needed. And that's why we have jobs. :)
I'm not missing any key points. You are missing the point. I'm only discussing at this time how SCO could argue this, given your earlier comments. But I've also pointed out where SCO's arguments could break down.
On Linus: I honestly believe he did recreate errno.h, but as I said, it would be somewhat difficult to prove that in court, because of the ability to copy and edit. And if you're defending Linus, it's kind of off-key to say he had no good reason to change the error numbers and cause some things to break. After all, his stuff worked fine, it was the attempt to directly port lots of stuff over from other *nixes that caused problems because of the shift in numbers. I can't find him at fault because other people didn't port stuff real well.
You need to understand, also, that 10 years didn't just "go by" after the AIX JFS development. It was a continuing evolution of features and capabilities, continued development. IBM's development by the same team, after 10 years of work on the AIX JFS, means that it's going to be difficult for IBM to prove "no derivation" based solely on the claim of a new source _base_, should the question ever be raised by SCO. And Steve Best did _not_ claim that no code was reused, only that a new source base was started. Nor did he claim that JFS2 is completely different in concept from JFS1. His claim is more one of performance and scalability, and scalability was the claimed reason to start a fresh code base. It is not clear that IBM would win that one in court. That is the key point here.
But again, it doesn't matter, because the original JFS was also IBM's, and it would be nearly impossible to prove derivation from anything "SCO" on that. I believe that was your original point. I'm saying that part of your original point was flawed, but that's addressed above.
I've had enough of this. I made a comment to state a fact on POSIX/FIPS, and that SCO can't claim any kind of violation with Microsoft and NT POSIX compliance. And your point on errno.h was that it was in the POSIX standard, but it was not. The standard didn't define that, and if it had, then SCO couldn't have claimed it as their IP.
I'm not interested in beating this dead horse anymore. And honestly, these picky tangent issues aren't interesting, either. I won't be reading this thread any longer. Post all you want.
Well, really, again, my point was that POSIX standards included the interface to the o/s, but not really the .h files. And your "proof" that errno.h is original because the numbers are different is not proof at all. Anyone could copy it, then change the numbers. I'm only pointing out that your argument wasn't based on substantive evidence. But that's not important nor is it worth arguing about further.
I'm an ardent Unix and Linux supporter, and I am not implying by any means that Linus did something untoward. I've replaced a lot of Microsoft and other systems with Linux and other *nixes over the years, and I even contributed some code to OSS.
As far as JFS goes, you need to read this: http://www.osnews.com/story.php?news_id=69. In it, Steve Best describes how the JFS team redesigned JFS and started with new source. In another published article, he describes key team members as being members of the original AIX JFS team. (See slide 8 here: http://www.perl.org/tpc/2002/sessions/best_steve.p df ) And in another part of one article, he states that JFS for AIX was around for 10 years before they started the new JFS. That's a very long time.
This doesn't meet the standard definition of a "sterile" redevelopment environment. He never explicitly states that _no_ code was reused. He only says they started with a new source base.
Fact remains that they would have a difficult time proving that it wasn't a derived work of their own work. But the crux is that even if it was derived from the AIX system, which in all likelihood the design was, at the very least, the original work was IBM's and not SCO's. And I like IBM's work. I never much cared for SCO's, and I certainly don't care for SCO's attitude these days.
Well, actually, the POSIX standard doesn't define .h files, as I recall. The standard just defined the interface for the system calls, and how libraries would react as a standard. Setting up the headers in the .h files was up to each company that wrote a compiler or built a library. If the code was an exact copy, then IBM might have stepped on it... And errno.h goes back a lot farther than Linux, so you'd have to prove to me that Linus typed it in. Personally, I suspect it came from GNU, and their compilers were available for years before Linus started on Linux.
But you missed my point altogether, which was that Microsoft didn't need to purchase a license to do POSIX. I was merely agreeing with wfberg on that point.
And OS/2 and Warp never had a journalling file system quite like what IBM implemented in AIX. As I recall, that file system actually appeared in AIX first, and early versions were being developed on the CS9000. You may not recall that, an early IBM Xenix computer that predated their RS6000 AIX system. There was some research done while the CS9000 was out on a journalling file system. That was in 1983, and OS/2 didn't start to surface until 1986.
Well, that's my recollection, anyway. I worked with all those systems, and I remember being pleasantly surprised to see some of the AIX developments make it to OS/2. I was a big user of OS/2 for a long time, right next to my AIX - RS6000s and Chromatics systems.
POSIX was a large _set_ of FIPS standards from NIST back when it had a different acronym. There was a standard for the o/s system calls, for interfaces, for libraries, etc. I don't recall the exact numbers, but it was like FIPS 152, 153, etc.
And you're correct. They were standards that were transferred to the IEEE. Mostly because NIST decided that they didn't really need to push for standards anymore, as a result of a decision at Commerce. Some of this was probably pressure because DoC and NBS/NIST were attempting to enforce POSIX compliance for all government systems, and about 70% of government "systems" were desktop computers running Wintel, which was not POSIX compliant. It was a huge nightmare in $$$$$$$$.
Now, IEEE has it, and the world has evolved since POSIX, and it's not really an issue any more, at least for the US Gov.
No one needs a license to "do POSIX." POSIX is merely a set of Federal Information Processing Standards (FIPS) - definitions of how various o/s interfaces and services operate, among other things. There is no true "POSIX" to license. A number of companies wrote dramatically different releases of software that met the POSIX standards.
You might be right, the future is difficult to predict. But as health cares hire salaried people with initial offerings and negotiations, that amounts to an opening bid. I know plenty of people that didn't take a job with a given organization because of the low starting salary (in their view, at least). And I know of situations where organizations didn't hire the best or most qualified individual as a result of the salary limitations.
Unless this model changes drastically, they have a base salary for their normal working shift. Extra money for extra shift work above and beyond the base seems to be the issue here. But I can't see individuals accepting lower base salaries than they would have in a normal hiring system. They still have to pay their bills.
And I've been on the other side of the fence and been frustrated because I didn't have enough of a budget to hire the person I really wanted, and no support from upper management to increase the budget. So I had to fill a position with a less qualified individual, and figure out how to get by with less expertise.
I've hired a lot of tech people, and I bring salary up at varying points, depending on the circumstances and the individual. Once I had a Ph.D. apply for a pretty low-level management job. He must have misunderstood the posting. So I told him the salary range and he withdrew immediately.
Again, I don't know, but I don't see salaries going down over the long haul anywhere I look. If bidding were to have an effect, I can't see how it could be a significant one. Just my opinion, though. My crystal ball shattered last week.
To far too many people in the world, salaries already count more than the quality of the work they perform. Generally, except in monopolies, companies care about quality of work and the resulting profit. I've seen bidding systems of all kinds, and I don't see a problem, providing that in each case, parameters are established to determine who qualifies to bid.
The original story was about the same nurses already working for the hospital, trying to get them to work extra shifts for extra money. If they're already qualified to work there, a couple hundred of the comments posted here don't apply.
This is all about finding a way to take care of patients at a time when health care professionals are in high demand. And we all complain about high health care costs as it is. Hospitals need extra help and cannot find it. Overtime from within is an acceptable and traditional practice.
Having had 4 nurses in the family, the traditional on-call practice was always tough because they were assigned by supervisors. This bidding at least puts a bit of control back in the hands of the nurses. "I'll take call on Christmas if you pay me enough," is not all bad.
While this may sound like serious issues to some, I feel compelled to point out that in reality, the omni-directional antennas buried inside wireless laptops or mobile devices do not have the gain characteristics necessary to get significant past the 30db limitation with the power available from the card itself. The vast majority of wireless device users would probably use power controls to eek out a few extra minutes of battery time, and a subset would be interested in maximum gain. Yes, there would be some that would strive to increase power. But to get 24db gain, you have to have a fairly stable antenna, highly directional, and that's not practical for laptops in typical use. There are other ways to bump up power, but they just don't always make sense. Sure, you can add an inline amp in your transmitter, but unless there's a similarly amped system at the other end of your transmission, it doesn't gain you a lot. If law enforcement was a valid reason for disallowing a technical capability, we could easily start discussing governors for cars to prevent them from exceeding the speed limit. I certainly would never have mine retrofitted :)
I'd prefer to have open source choice. If a driver has to be kept proprietary for business reasons, no matter what they are, let them support their hardware with non-kernel modules. It's their business choice. I won't necessarily agree with it, but mine is one of many opinions.
An ideal wireless NIC driver would be open source. It would dynamically adjust gain levels up and down to balance power consumption (battery life) without compromising data integrity.
And if someone wants to tweak the open source for max power, power to them!
SBC stands for Smith Bailey Coleman or something like that. It's actually the name of three founding partners. It is NOT for southwestern bell, they just happened to grow from and subsume southwestern bell.
I wish I could remember the names accurately, but I have forgotten in the last couple of years.
I have known a number of people working for Ameritech, now SBC. They're mostly engineering types, who spend a great deal of time dealing with similar issues. SBC has steadily decreased its engineering staff and increased its sales staff over the last 12 years. The CWA staff has remained somewhat level. Yet, there has been more buildout of systems, and a continuing advancement in plant capability throughout, resulting in tougher jobs for everyone. Now the engineers are facing a probably sales quota, too. Pretty stupid, huh? There aren't enough engineers to work all the jobs assigned now. I asked for an estimate on a job last summer and it took nearly two months to get it. The engineers were backlogged that long. I think SBC is run by some real idiots who've forgotten what customers need, especially those of us dealing with large projects.
At one time, SCO Xenix was the only protected-mode operating system available for the pre-286 non-protected mode hardware sold by Intel. In 1985, I supported a number of Suns, Apollos, Masscomps, and ATT systems running Unix variants including BSD 3.x and 4.x. The only way we could work with pcs effectively was to put SCO Xenix on them. Eventually, other, better alternatives became available as Intel developed more powerful hardware (such as the 286 with supervisory mode, and the 386 even later). We shifted to Microport's Unix Sys V for the 286/386, but continued to use Xenix as it evolved on a variety of equipment, until it was no longer practical. Dell shipped it for a number of years as an alternative operating system. Though it wasn't perfect, it was far superior to MS systems. By the way, though we usually called it "S C O" the company reps we talked to usually pronounced it "sko" with a long o, even in 1985.