Yes. The arguments were strong and the discussion about how it went looked promissing. We'll have to wait for the actual decision to see the details. Hopefully, they worded their decision in a way that would discourage Congress from extending the term again (and again, and again...).
It's not so much that the fix might break something, but anytime someone changes something without your knowledge, there is cause for concern. Whenever you detect that something has changed with one of the systems you manage, you have to try to understand how and why. If someone is going around fixing things and not telling anyone, even if it is someone in the organization, you (or your monitoring tools) may notice something strange. When you try to follow up and understand how and why, you are missing information about what happened.
That means the content (DVDs, CDs, Ebooks and downloads of same) and the devices that won't support fair use. For the content stuff it should be very clear, but it will be more murky with devices because more that one component will often be involved. You can't cut a CD or DVD on a player, but they are trying to also protect the play signal so only a DRM writer is compatible, so you have to consider the whole system.
For computers, the critical DRM component is the system software. Palladium does constitute a core DRM technology. If you must use Windows, disable palladium, and don't use programs and content that require it to be enabled. If this makes Windows useless to you, then boycott windows. As long as putting the hardware support there doesn't interfere with running Linux, I would not hold the HW vendor responsible.
A boycott is an inappropriate response to this. Putting support for DRM into the hardware or BIOS is not the problem, and nobody should be punished for putting in the required features at this level. Besides, what are you going to do, buy Intel or AMD chips instead? In case you haven't noticed, they are going along too.
Yes, do boycott companies that actually release content with objectionable DRM technology. A simple rule of thumb is if you can't view it under Linux (assuming there has been time and information necessary to create drivers, etc.), then it is unreasonably restrictive. Apple may be a good benchmark too, but they might cave at some point. It's really not possible for Linux to cave on this (well, maybe in an embedded box, but I doubt it).
As a side note, Linux will lose bigtime if it doesn't adopt a fair DRM system. Otherwise, Microsoft will be the only player in this new market.
The problem is that with ??AA dictating what DRM is with MS as their accomplice, this is unlikely to be allowed.
I was thinking further about the discussion about how "trusted" is understood in the phrase "trusted computing". The essence of what is being proposed is being able to trust the computer when you can't, or more correctly won't trust the operator (user/admin) of that computer.
Trusting the user is fundamental to the philosophy behind Open/Free Source. There is no practical way to keep the admin of a Linux system from being able to defeat any DRM system that Linux implements. You have the source, so you can always hack up a version that strips it out and lets you do whatevery you want.
That being said, it is completely possible to implement a fair DRM scheme in Linux, and since you are trusting the operator anyway, any special support in the HW/BIOS isn't really needed. Since we are now back in control, we can design it to be fair, and have the 'R' in DRM stand for rights, not restrictions. In other words, we would empower the user in excercising fair-use rights to back-up, change formats, share with friends (within fair use bounds, of course).
This probably won't satisfy DRM proponents, but I think it is important that the community respond to them with a true willingness to protect the copyright holders rights as well. If all the standard distros make good faith efforts to produce a system that respects both DRM and fair use, the average user will leave all the controls in place and when they make copies, they will know that there are fair use limits to be respected. Some may still choose to cross the line, and others will go further to circumvent controls completely. But the community will be demonstrating their stand for the rights of all parties involved.
Still, the ugly head of the DMCA rears its head. At least in the US, this law gives all the power to the DRM proponents to just deny Linux access to protected content. It would be bold, but not unreasonable to assert the right to implement the program outlined above even in the face of the DMCA. After all, you are making a good faith effort to implement the controls (sans fair use restictions), not trying to "break" the controls. Now, I wouldn't do this on my own and risk the legal attention of a number of large companies, but this would require a lot of coordination in the community to pull it off anyway.
I agree with this almost completely. Sun has attempted to introduce "open" standards with varying amounts of control. I think if you analysed it, the more control they went for, the less successful the technology has been. The recognised from the start that NFS had to be very open, or it would not succeed, and by making it very open from the start, sponsoring connectathons, and such, it is a huge success story. They tried to control NEWS, and it flopped. With Java they are trying more of a middle road, but it's hard to say yet.
Bottom line is that they practically invented the idea of "Open Systems", and were a pioneer with the SunOSs (essentially a BSD fork). In the late 80s, I was working at AT&Ts Summit, NJ facility (later to be spun off and sold as USO, Unix Software Operation). Bill Joy came to speak at a nearby AT&T location, and I heard him give his rant on "the vendor motel" (you know, you check in, but you don't check out). At that time, this was more directed at IBM, DEC, HP, and anyone who was still maintaining their own non-Unix OS. MicroSoft wasn't even on anyone's radar screen then, but then, you can't blame them, Windows 3.0 hadn't come out yet, so it was hard to consider it more than a toy.
In the end, Sun continues to deliver a lot of value to their customers. It's going to cost a bit more than buying commodity PC hardware and using Linux, but in my experience it is a lot more foolproof. You can probably get most of this with the best PC vendors, and Linux, but the service and support will be better from Sun. You have the commitment of a single vendor to deliver a complete hardware/software system. All of the Linux distribution houses are in the mode of packaging what they get from the community, not putting together a complete system (well, that's my impression anyway, it would be nice to see a vendor prove me wrong).
It is fair to say Sun has been reluctant to fully support Linux on their hardware, but I see that position as well justified. Until recently, Solaris was significantly more stable than Linux, so not many customers wanted it. Now, with so many huge server farms with many x86 boxes running Linux, and say a few larger Suns running databases and such, I can see wanting to run Linux on the Sun servers too. Your going to have less support cost for an all Linux environment than a Sun/Linux environment. For Sun, it doesn't matter if you run the box on Solaris or Linux, they aren't making much money on the software anyway. In fact, it probably costs less to support the user on Linux, so it is conceivable that they eventually drop Solaris altogether.
It's really the same dynamic is IBM has with AIX and Linux. As long as there is a strong demand from the customer base for Solaris, or AIX, they will keep them going. At some point, it will be attractive to port a couple of distictive tools to Linux and be done with it. These tools would be the ones that keep the holdouts for AIX/Solaris hanging around. It also means that Linux is just at stable as AIX/Solaris (I would say it is pulling close or even by now, but this is a difficult thing to measure).
It seems to me that a lot of people are responding to this as if it real (this comment, I'm still considering the whole store). Get a grip people, this really can't be real. There are lots of clues, the biggest being, why would they publish this story if it was true? Right, they would keep it secret.
Another thing, people seem to be missing the boat on the legality issues as well. Yes, this probably is illegal, but it is exactly the sort of thing that would be legal under proposed legislation (not passed, but not dead either as far as I know). I'm too lazy to post a link to a relavent/. story, but I'm sure people can find it if easily enough.
Sure, you can distribute it however you like, it just won't be a valid application of the GPL, and therefore non of the terms of the GPL would apply. My point still stands as it did in my first comment. The assertion of patent rights invalidates the application of GPL, not the patent.
Sure there is. SCO has redistributed Linux. Therefore, they have accepted, and are bound by, the terms of the GPL. That affects how they can prosecute patents related to Linux.
Correct, but I have already ackowledged this point in an earlier comment. The comment you include is referring to what the situation would be if SCO never acquired Caldera, and had never distributed Linux. Given that they have, this still does not, on the face of it, say that they have given up their patent claims against Linux. However, as I said before, the courts are unlikely to look favorably on all of this, and SCO would find it difficult to enforce their claim even if it otherwise had merit (which it doesn't).
The only time you would need storage is if a packet was received for an interface that is already busy or backed up. A simple minded switch might even kill this packet by signalling a collision on the sending interface. Any decent switch would have enough bandwidth on the backplane to support all the interfaces it has. Perhaps "switching fabric" is more descriptive of most switch architectures than backplane, but in principle it could be a backplane running much faster than the links.
Perhaps someone with actual knowledge of specific switch designs could comment, but bottom line, only very poor switch designs would have a processor interacting directly with packet flow (for the typical case).
If you write some code, and SCO says you need a license for their patent to use it, then you may not distribute it under the GPL. If using it would violate the patent, then distributing it violates the GPL. The language of that clause is simple, and this is what it says.
Now, in the case of Thompson and mp3 decoding it is a little different. They are saying that it is ok at least for non-commercial use, but depending on what they mean by this it may or may not be GPL compatible. For example, say you want to sell an player based on GPL decoder software, do you need to pay for the license? How about a commercial Linux distro? Do I pay a license based on the number of CDs actually purchased (as apposed to downloads, and counting multiple installes). It seems to me that the intent of the GPL is to demand that the patent holder may not extract a royalty selectively based on who or how it is used.
If you assume for a moment that SCO has a valid patent claim, and that they intend to enforce it WRT Linux, there is nothing the GPL can do to prevent this. What it can do is cause the offending code to be removed, and if that is not possible it would prevent the distribution of Linux under the GPL. This could be a nightmare scenario for Linux if the claim was not so weak to begin with. Of course, it is also likely that the patented feature would be removed and a better non-infringing feature put in its place.
In the example cases, it isn't that pure, but there is always the danger of discovering a patent long after an GPL program is developed. It doesn't have to be malicious either (unless you thing all patents are evil, but I digress). If the GPL program author and the patent holder are unaware that the other exists for a long time, and the patent holder then discovers that the GPL program is in fact an implementation of their patent... If you're lucky, you can establish that the GPL program predates the patent, and therefore is in itself evidence of prior art.
Distributing the source code doesn't violate the patent. Running the resulting executable does.
What you say is correct, but misses the point. It violates the GPL, not the patent. As I said, the GPL has no interest in covering code that cannot be used. Read between the lines, and what I meant is completely clear from the context.
You can redistribute your source code all you like, but anybody using it would be violating Thompson's patent.
No, you can't distribute it under GPL if it would violate the patent. The patent holder would have to grant a transferrable no-cost license. GPL rightly has no interest in code that cannot be used.
If Thompson does the redistribution, I think they open themselves up to the claim that they are granting a free license implicitely, but a court would have to decide that. This is the equivalent situation to SCO.
That is the specific GPL grant for the code that is in violation of the patent. If the patented technology cannot be removed with the program still functioning, then, in effect, the program is no longer GPL (cannot be by the terms of GPL).
The point here is that there really isn't any way for SCO to extract royalties here, but they could stop everyone from distributing Linux under the GPL (depending on how extensive and isolatable the violation are). This applies to SCO (caldera) just as much as the others.
A side point can be made that the very act of distributing Linux, suggests that they did not believe they had a patent claim against Linux. If it ever got to a court, I suspect they would be very hard on SCO for this history and the way the claim was made. This sort of behavior is very destabilizing in the markets, so the courts aren't going to reward it easily.
It seems like you are deriding the way this language is being used, but it really does make sense. The idea is that you only need to trust a person, company or system if that entity has the access, authority and control to compromise system security. The trust comes in because you have to be able to trust the entities that actually have the power to break that trust.
We understand this implicitely in the kernel/user space distinction. Kernel programs and drivers are trusted not to do bad things to kernel memory because they can (usually by mistake).
The problem as I see it with the whole TCPA concept, is that the trust required is too extensive. As a practical matter, we could try to create versions of Linux that follow this standard, but because in principle, any kernel driver could snoop and interfere with any other kernel function. The only way to make guarantees is to outlaw the running of any modified drivers, and the ability to make changes is exactly why we wanted Linux in the first place.
Does anyone see any value in TCPA for Linux? Distributions could implement TCPA functions based on signing keys and key databases that are sourced from the distribution vendors. I think this could have some value in securing the platform, but in a way it is very indirect.
Personally I don't know enough about Windows to truly regain control, myself. I can only exercise control by being darned careful about what I let on the machine in the first place.
It's not you, computer systems are too complex for any one person to be able to understand what it is really doing and prove that it isn't doing things you wouldn't want. You have to trust your vendors, and they are (in your words) "vying for control", and often at your expense. The market helps to some extent as people become aware of what tricks are being played, and talk about it (thanks, slashdot).
But Linux gives me control limited only by my learning. Not only that, but the community shuns the spyware stunts common in Windows.
Of course even open source isn't a guarantee here, but at least it gives the user and the community the information they need. The community values are also a big help with this, as any break with community values gets publicized and shunned quite quickly.
MS has to sign everything secured.
Now the question is: imagine (or dream;-) MS publicily saying that they will make some association / trustee company, including people from FreeSoftware community, competitors, and so on, which would review software & sign it. Would that be acceptable ?
The only really acceptable policy would be to allow for multiple signing authorities. The use should be able to control who they trust to write and update their system software.
The problem with this is that it could open a hole in DRM that you can drive a truck through. The essence of the problem is that DRM has the goal of implementing a system that third parties can trust, not the users. It would be very difficult to maintain the chain of trust necessary for a content vendor to maintain control unless you can control all of the drivers, but I can see how it would be possible to make sure that managed content is only handled by managed drivers. On the other hand, this would be pretty complex. The content provider has to have a way to specify acceptable signing authorities, and the system must keep track of the "trust domains" in the system as well as the "trust requirements" (or level?) of any content (data).
Wouldn't the best idea be to have a power supply designed and built from the ground up with water cooling? Power supplies themselves are probably cheaper than the CPU water cooling kits, so the water cooled PS shouldn't cost much more than a PS cooling kit.
Even better would be a complete case and power supply, so you could route some water to the drive carriers, so the sound insulation doesn't make them fry. You'd have to do some custom plumbing to hook in the CPU cooler, but the rest of the system could be completely assembled with the case and PS.
Back in the kit computer days, there was one manufacturer that used a special type of transformer (fero-resonant, maybe, don't remember for sure) that would protect against brown outs. I think they did this for the advantages in the industrial markets.
Yes, this is really the reason I suggested consultants. I know that all of this is possible, but not what gear would do it best. Would you use something line ATM based connections with channel adapters to hook up the raw video stream (more like 300MB according to the other reply, which seems about right)? If I understand the purpose of ATM protocols, it is designed for these situations (disperate services sharing a single high speed channel), but I would call on a good network consultant who has experience with similar configurations.
The TOS stuff isn't relavent to dark fiber, because in effect you aren't going outside of your private network, so you control everything. If you also run and own your own PBXs in both locations, you should be able to connect them over the fiber as well. This probably would not be voice over IP, but it could be.
WRT FDDI, in my experience, FDDI was already well on the way out for the last of the dotcom period. I'm not surprised that a lot of it didn't work well, and if I was sitting on a cache of FDDI hardware, I'd probably junk it and take the right off. I'd be interested in a more informed report, on what are/were the more popular technologies. I thought ATM was big with the telcos and big pipe providers. The telcos also have a set of standards are protocols that are more "circuit switched" and related to ISDN where 64K channels that support a single voice channel are agregated to T1 (24 channels at 1.5M in the US, 32 channels elsewhere), and then into higher bandwidth channels.
Yes, it has been three years since the boom, so a lot of the used equipment dumped on the market is probably in use someplace else (hopefully, if you are CISCO). I supose it is likely that whatever is still available (if anything) is likely to be stuff you don't want (e.g. broken FDDI stuff), but again, this is where the consultants come in. Besides, the bust isn't finished, so some stuff will become available. DirectTV DSL is being taken off line (a pain for me), and I doubt they have an use for all of the equipment that will be taken out of service.
I love to be the one to break this to you: network gear is just machines with NICs in it.
I hate to break it to you, but this is wrong. The simplest switches will be nothing but a backplane and special purpose hardware to connect each link up to the backplane. No processor necessary. More complex and flexible gear that can do a lot of complex routing an filtering will probably have a processor, but it only gets involved in configuration. Packets flow in and out without a processor every touching them.
PCs have lots of things that aren't even a little necessary for this, in particular disks that have a very high failure rate compared with chips and such. Further, the biggest problem is the OS that you have to boot and configure, and a purpose built device will just turn on and go. It is just much more likely to just work, whether you are talking about cheap simple NetGear stuff or more complex Cisco routers and switches.
Did you fail to notice the 'Ask Slashdot' aspect of this? This place is full of network consultants. Hell, anyone who has ever answered someone's networking questions for money outside of a salaried position is a network consultant.
So what, my point was that there are a lot hardware choices, and as others have pointed out, he didn't specify enough to know for sure. Rather than spend money on devices that don't quite work for the job, get a little help from someone who can say for sure what will and won't work. I've actually done networking work both for salary and as a consultant, but I don't consider myself a network consultant because I don't do it enough to be able to definitively say what will and won't work. Expirimenting can be expensive.
Machines with NICs are much more expensive and complex than network gear. The type of thing that is needed here is probably available used for not much money. So much network hardware was purchased in the dotcom boom, that there is probably still a backlog of really nice stuff on the resale market.
Get advice from a network consultant, because you need someone who knows what to buy and how to hook it up. With the right kind of hardware, you can probably share with the video link too (might be expensive, that's why you need some advice).
Exactly, you can patent algorithms (sort of, as a method of doing something specific), but you can't copyright them. You cannot patent or copyright ideas, which is the source to the objection to software patents in general. An algorythm is an idea, so it is hard to say just what you are patenting with a software patent, but I digress.
Besides the tactical advantages of the patent in defending other infringement claims, there is one thing the patent would give for OSS.
Without the patent, a company can commercialize the technology even if it is protected by the GPL. They just can't copy the code and call it theirs, but they can re-implement the technology in new code and sell it as theirs. After the patent expires, they are the same.
Of course, you could just install first on the work machine, and everything would be fine still. That is beside the point, but it would work.
I started buying TaxCut (Kiplinger) a few years back, but last year it wouldn't install properly on the one ancient windows box that I still had running. I think it was Windows that was bolluxed, but didn't want to waste a lot of time with it; it had a missing DLL error when I tried to start it up after install (which went fine). I just punted and did it manually.
I really like using a program because the instructions are so complex that it is just about impossible to get it right without some help. Apparently, I did something wrong manually because the IRS fixed something and sent a check after their program corrected it. It would be nice if they gave you some detail about the error so I don't to the same again... It was a nice surprise to get the check back, but alarming that such a large mistake was that easy to make.
It sure would be nice if the gov published an open source reference program, or standardized encoding of the rules, otherwise it isn't likely that we'll be able to do taxes under Linux. Perhaps Wine works well enough now (anyone do it this way?). Don't tell me to do it on-line, because I won't do it unless I have a way to trust they will protect my privacy.
Don't you think it is rather silly to pick apart what I wrote this way? The data does indeed show segmented exponential improvements in a number of dimensions, and the only real question is the value of the exponent. A straight line on semi-log graphs is exponential, and while there are some outlying, the trend is clear. Also, you didn't touch my point that memory would have been a much better test. Without getting to precise, we have 16K dynamic rams about 75-78 timeframe, and now, it is what 1G or at least.5G. Thats 16 doublings in about 24 years. That looks pretty close to the 18mo empirical figure. People didn't just pull that figure out of a hat, it has some real world validity. The journalists who quote that as Moore's figure just aren't checking their sources. I remember learning about Moore's law with the figure 2yrs (correct after '75), and seeing 18mos quoted empirically.
Let's go back to the points from the original paper (as layed out it this one). In 1965, putting planar circuits together was in its infancy, and Moore correctly asserted that there was a lot of room for improvement without even doing anything fancy. Later as certain limits were approached, even these were pushed much further back. The paper is correct in pointing out that the original paper doesn't factor in things like design cost, complexity and other effects. With the exception of memory technologies, modern devices are more and more dominated by interconnect. Wires are components too, even if they are pretty much passive. Moore even makes the important point that costs are dominated by packaging and external interconnect, particularly at the lower intergration levels at that time. These costs are still very significant if no longer dominant in all cases.
I would assert that whenever a new information technology emerges, it sparks a new and more rapid period of near exponential change, both in society and in human intellectual advances as well. In evolutionary time scales, WWII to the present (the whole history of electronic computing fits in this period) is a blink of an eye. In the fossil record, it is impossible to sort out changes that happen at that scale, so it is just about impossible to sort out the internal structure of how it happens.
With modern technology, we have records that give a pretty accurate picture of the evolutionary process in action. Changes is discontinuous; a new process emerges and there is rapid progress as the process undergoes variation and selection at a rapid rate, then the limits of that process is reached and things may settle down for a while. Or the new position may spark additional new processes of a fundamentally different nature and continue the progress for a few more technological generations.
We know that we have only scratched the surface of what is possible with information technology, even if chip technology stagnates, which it won't for a while yet (to 2016 at least according to the experts, which is suspect is the limit of their willingness to attempt to map it, not the possibilities or even the most likely path).
The really frustrating thing about this paper is that it comes very close to making some very good points, but then just drops them. From here on out, technological progress is going to be all about managing extreme complexity, and finding appropriate uses for technology. It is clear that we will be able to design technology to accomplish just about any task we set our collective minds to, and the more important questions become why and how (socially, more than technically).
Without going into all the arguments about why, I will assert that it is the power of sharing ideas and information as embodied in the Free/Open Software movement that has the potential to lead the way.
BTW, in this line of argument is also the best way to refute all the MS FUD on the subject of the GPL. It's all about doing more for less. If you build it they will come, although it may take a little longer than first thought. For simple circuits, you can ignore the design/complexity costs, and nobody has a monopoly on good ideas, so exponential growth is a natural consequence. Things get bottled up when one player tries to monopolize a particular idea (or expression of one). OSS commoditizes software solutions for well known problems, and having a large library of off the shelf solutions to build on is the only way to extend our reach significantly. The control tactics of MS and companies like that are holding back progress, not the other way around as they are now trying to assert.
Slashdot Mirror
Yes. The arguments were strong and the discussion about how it went looked promissing. We'll have to wait for the actual decision to see the details. Hopefully, they worded their decision in a way that would discourage Congress from extending the term again (and again, and again ...).
It's not so much that the fix might break something, but anytime someone changes something without your knowledge, there is cause for concern. Whenever you detect that something has changed with one of the systems you manage, you have to try to understand how and why. If someone is going around fixing things and not telling anyone, even if it is someone in the organization, you (or your monitoring tools) may notice something strange. When you try to follow up and understand how and why, you are missing information about what happened.
For computers, the critical DRM component is the system software. Palladium does constitute a core DRM technology. If you must use Windows, disable palladium, and don't use programs and content that require it to be enabled. If this makes Windows useless to you, then boycott windows. As long as putting the hardware support there doesn't interfere with running Linux, I would not hold the HW vendor responsible.
Yes, do boycott companies that actually release content with objectionable DRM technology. A simple rule of thumb is if you can't view it under Linux (assuming there has been time and information necessary to create drivers, etc.), then it is unreasonably restrictive. Apple may be a good benchmark too, but they might cave at some point. It's really not possible for Linux to cave on this (well, maybe in an embedded box, but I doubt it).
The problem is that with ??AA dictating what DRM is with MS as their accomplice, this is unlikely to be allowed.
I was thinking further about the discussion about how "trusted" is understood in the phrase "trusted computing". The essence of what is being proposed is being able to trust the computer when you can't, or more correctly won't trust the operator (user/admin) of that computer.
Trusting the user is fundamental to the philosophy behind Open/Free Source. There is no practical way to keep the admin of a Linux system from being able to defeat any DRM system that Linux implements. You have the source, so you can always hack up a version that strips it out and lets you do whatevery you want.
That being said, it is completely possible to implement a fair DRM scheme in Linux, and since you are trusting the operator anyway, any special support in the HW/BIOS isn't really needed. Since we are now back in control, we can design it to be fair, and have the 'R' in DRM stand for rights, not restrictions. In other words, we would empower the user in excercising fair-use rights to back-up, change formats, share with friends (within fair use bounds, of course).
This probably won't satisfy DRM proponents, but I think it is important that the community respond to them with a true willingness to protect the copyright holders rights as well. If all the standard distros make good faith efforts to produce a system that respects both DRM and fair use, the average user will leave all the controls in place and when they make copies, they will know that there are fair use limits to be respected. Some may still choose to cross the line, and others will go further to circumvent controls completely. But the community will be demonstrating their stand for the rights of all parties involved.
Still, the ugly head of the DMCA rears its head. At least in the US, this law gives all the power to the DRM proponents to just deny Linux access to protected content. It would be bold, but not unreasonable to assert the right to implement the program outlined above even in the face of the DMCA. After all, you are making a good faith effort to implement the controls (sans fair use restictions), not trying to "break" the controls. Now, I wouldn't do this on my own and risk the legal attention of a number of large companies, but this would require a lot of coordination in the community to pull it off anyway.
Bottom line is that they practically invented the idea of "Open Systems", and were a pioneer with the SunOSs (essentially a BSD fork). In the late 80s, I was working at AT&Ts Summit, NJ facility (later to be spun off and sold as USO, Unix Software Operation). Bill Joy came to speak at a nearby AT&T location, and I heard him give his rant on "the vendor motel" (you know, you check in, but you don't check out). At that time, this was more directed at IBM, DEC, HP, and anyone who was still maintaining their own non-Unix OS. MicroSoft wasn't even on anyone's radar screen then, but then, you can't blame them, Windows 3.0 hadn't come out yet, so it was hard to consider it more than a toy.
In the end, Sun continues to deliver a lot of value to their customers. It's going to cost a bit more than buying commodity PC hardware and using Linux, but in my experience it is a lot more foolproof. You can probably get most of this with the best PC vendors, and Linux, but the service and support will be better from Sun. You have the commitment of a single vendor to deliver a complete hardware/software system. All of the Linux distribution houses are in the mode of packaging what they get from the community, not putting together a complete system (well, that's my impression anyway, it would be nice to see a vendor prove me wrong).
It is fair to say Sun has been reluctant to fully support Linux on their hardware, but I see that position as well justified. Until recently, Solaris was significantly more stable than Linux, so not many customers wanted it. Now, with so many huge server farms with many x86 boxes running Linux, and say a few larger Suns running databases and such, I can see wanting to run Linux on the Sun servers too. Your going to have less support cost for an all Linux environment than a Sun/Linux environment. For Sun, it doesn't matter if you run the box on Solaris or Linux, they aren't making much money on the software anyway. In fact, it probably costs less to support the user on Linux, so it is conceivable that they eventually drop Solaris altogether.
It's really the same dynamic is IBM has with AIX and Linux. As long as there is a strong demand from the customer base for Solaris, or AIX, they will keep them going. At some point, it will be attractive to port a couple of distictive tools to Linux and be done with it. These tools would be the ones that keep the holdouts for AIX/Solaris hanging around. It also means that Linux is just at stable as AIX/Solaris (I would say it is pulling close or even by now, but this is a difficult thing to measure).
Another thing, people seem to be missing the boat on the legality issues as well. Yes, this probably is illegal, but it is exactly the sort of thing that would be legal under proposed legislation (not passed, but not dead either as far as I know). I'm too lazy to post a link to a relavent /. story, but I'm sure people can find it if easily enough.
Sure there is. SCO has redistributed Linux. Therefore, they have accepted, and are bound by, the terms of the GPL. That affects how they can prosecute patents related to Linux.
Correct, but I have already ackowledged this point in an earlier comment. The comment you include is referring to what the situation would be if SCO never acquired Caldera, and had never distributed Linux. Given that they have, this still does not, on the face of it, say that they have given up their patent claims against Linux. However, as I said before, the courts are unlikely to look favorably on all of this, and SCO would find it difficult to enforce their claim even if it otherwise had merit (which it doesn't).
Perhaps someone with actual knowledge of specific switch designs could comment, but bottom line, only very poor switch designs would have a processor interacting directly with packet flow (for the typical case).
Now, in the case of Thompson and mp3 decoding it is a little different. They are saying that it is ok at least for non-commercial use, but depending on what they mean by this it may or may not be GPL compatible. For example, say you want to sell an player based on GPL decoder software, do you need to pay for the license? How about a commercial Linux distro? Do I pay a license based on the number of CDs actually purchased (as apposed to downloads, and counting multiple installes). It seems to me that the intent of the GPL is to demand that the patent holder may not extract a royalty selectively based on who or how it is used.
If you assume for a moment that SCO has a valid patent claim, and that they intend to enforce it WRT Linux, there is nothing the GPL can do to prevent this. What it can do is cause the offending code to be removed, and if that is not possible it would prevent the distribution of Linux under the GPL. This could be a nightmare scenario for Linux if the claim was not so weak to begin with. Of course, it is also likely that the patented feature would be removed and a better non-infringing feature put in its place.
In the example cases, it isn't that pure, but there is always the danger of discovering a patent long after an GPL program is developed. It doesn't have to be malicious either (unless you thing all patents are evil, but I digress). If the GPL program author and the patent holder are unaware that the other exists for a long time, and the patent holder then discovers that the GPL program is in fact an implementation of their patent ... If you're lucky, you can establish that the GPL program predates the patent, and therefore is in itself evidence of prior art.
What you say is correct, but misses the point. It violates the GPL, not the patent. As I said, the GPL has no interest in covering code that cannot be used. Read between the lines, and what I meant is completely clear from the context.
No, you can't distribute it under GPL if it would violate the patent. The patent holder would have to grant a transferrable no-cost license. GPL rightly has no interest in code that cannot be used.
If Thompson does the redistribution, I think they open themselves up to the claim that they are granting a free license implicitely, but a court would have to decide that. This is the equivalent situation to SCO.
The point here is that there really isn't any way for SCO to extract royalties here, but they could stop everyone from distributing Linux under the GPL (depending on how extensive and isolatable the violation are). This applies to SCO (caldera) just as much as the others.
A side point can be made that the very act of distributing Linux, suggests that they did not believe they had a patent claim against Linux. If it ever got to a court, I suspect they would be very hard on SCO for this history and the way the claim was made. This sort of behavior is very destabilizing in the markets, so the courts aren't going to reward it easily.
We understand this implicitely in the kernel/user space distinction. Kernel programs and drivers are trusted not to do bad things to kernel memory because they can (usually by mistake).
The problem as I see it with the whole TCPA concept, is that the trust required is too extensive. As a practical matter, we could try to create versions of Linux that follow this standard, but because in principle, any kernel driver could snoop and interfere with any other kernel function. The only way to make guarantees is to outlaw the running of any modified drivers, and the ability to make changes is exactly why we wanted Linux in the first place.
Does anyone see any value in TCPA for Linux? Distributions could implement TCPA functions based on signing keys and key databases that are sourced from the distribution vendors. I think this could have some value in securing the platform, but in a way it is very indirect.
It's not you, computer systems are too complex for any one person to be able to understand what it is really doing and prove that it isn't doing things you wouldn't want. You have to trust your vendors, and they are (in your words) "vying for control", and often at your expense. The market helps to some extent as people become aware of what tricks are being played, and talk about it (thanks, slashdot).
But Linux gives me control limited only by my learning. Not only that, but the community shuns the spyware stunts common in Windows.
Of course even open source isn't a guarantee here, but at least it gives the user and the community the information they need. The community values are also a big help with this, as any break with community values gets publicized and shunned quite quickly.
The only really acceptable policy would be to allow for multiple signing authorities. The use should be able to control who they trust to write and update their system software.
The problem with this is that it could open a hole in DRM that you can drive a truck through. The essence of the problem is that DRM has the goal of implementing a system that third parties can trust, not the users. It would be very difficult to maintain the chain of trust necessary for a content vendor to maintain control unless you can control all of the drivers, but I can see how it would be possible to make sure that managed content is only handled by managed drivers. On the other hand, this would be pretty complex. The content provider has to have a way to specify acceptable signing authorities, and the system must keep track of the "trust domains" in the system as well as the "trust requirements" (or level?) of any content (data).
Even better would be a complete case and power supply, so you could route some water to the drive carriers, so the sound insulation doesn't make them fry. You'd have to do some custom plumbing to hook in the CPU cooler, but the rest of the system could be completely assembled with the case and PS.
Back in the kit computer days, there was one manufacturer that used a special type of transformer (fero-resonant, maybe, don't remember for sure) that would protect against brown outs. I think they did this for the advantages in the industrial markets.
The TOS stuff isn't relavent to dark fiber, because in effect you aren't going outside of your private network, so you control everything. If you also run and own your own PBXs in both locations, you should be able to connect them over the fiber as well. This probably would not be voice over IP, but it could be.
WRT FDDI, in my experience, FDDI was already well on the way out for the last of the dotcom period. I'm not surprised that a lot of it didn't work well, and if I was sitting on a cache of FDDI hardware, I'd probably junk it and take the right off. I'd be interested in a more informed report, on what are/were the more popular technologies. I thought ATM was big with the telcos and big pipe providers. The telcos also have a set of standards are protocols that are more "circuit switched" and related to ISDN where 64K channels that support a single voice channel are agregated to T1 (24 channels at 1.5M in the US, 32 channels elsewhere), and then into higher bandwidth channels.
Yes, it has been three years since the boom, so a lot of the used equipment dumped on the market is probably in use someplace else (hopefully, if you are CISCO). I supose it is likely that whatever is still available (if anything) is likely to be stuff you don't want (e.g. broken FDDI stuff), but again, this is where the consultants come in. Besides, the bust isn't finished, so some stuff will become available. DirectTV DSL is being taken off line (a pain for me), and I doubt they have an use for all of the equipment that will be taken out of service.
I hate to break it to you, but this is wrong. The simplest switches will be nothing but a backplane and special purpose hardware to connect each link up to the backplane. No processor necessary. More complex and flexible gear that can do a lot of complex routing an filtering will probably have a processor, but it only gets involved in configuration. Packets flow in and out without a processor every touching them.
PCs have lots of things that aren't even a little necessary for this, in particular disks that have a very high failure rate compared with chips and such. Further, the biggest problem is the OS that you have to boot and configure, and a purpose built device will just turn on and go. It is just much more likely to just work, whether you are talking about cheap simple NetGear stuff or more complex Cisco routers and switches.
Did you fail to notice the 'Ask Slashdot' aspect of this? This place is full of network consultants. Hell, anyone who has ever answered someone's networking questions for money outside of a salaried position is a network consultant.
So what, my point was that there are a lot hardware choices, and as others have pointed out, he didn't specify enough to know for sure. Rather than spend money on devices that don't quite work for the job, get a little help from someone who can say for sure what will and won't work. I've actually done networking work both for salary and as a consultant, but I don't consider myself a network consultant because I don't do it enough to be able to definitively say what will and won't work. Expirimenting can be expensive.
Get advice from a network consultant, because you need someone who knows what to buy and how to hook it up. With the right kind of hardware, you can probably share with the video link too (might be expensive, that's why you need some advice).
Exactly, you can patent algorithms (sort of, as a method of doing something specific), but you can't copyright them. You cannot patent or copyright ideas, which is the source to the objection to software patents in general. An algorythm is an idea, so it is hard to say just what you are patenting with a software patent, but I digress.
Without the patent, a company can commercialize the technology even if it is protected by the GPL. They just can't copy the code and call it theirs, but they can re-implement the technology in new code and sell it as theirs. After the patent expires, they are the same.
I started buying TaxCut (Kiplinger) a few years back, but last year it wouldn't install properly on the one ancient windows box that I still had running. I think it was Windows that was bolluxed, but didn't want to waste a lot of time with it; it had a missing DLL error when I tried to start it up after install (which went fine). I just punted and did it manually.
I really like using a program because the instructions are so complex that it is just about impossible to get it right without some help. Apparently, I did something wrong manually because the IRS fixed something and sent a check after their program corrected it. It would be nice if they gave you some detail about the error so I don't to the same again ... It was a nice surprise to get the check back, but alarming that such a large mistake was that easy to make.
It sure would be nice if the gov published an open source reference program, or standardized encoding of the rules, otherwise it isn't likely that we'll be able to do taxes under Linux. Perhaps Wine works well enough now (anyone do it this way?). Don't tell me to do it on-line, because I won't do it unless I have a way to trust they will protect my privacy.
Let's go back to the points from the original paper (as layed out it this one). In 1965, putting planar circuits together was in its infancy, and Moore correctly asserted that there was a lot of room for improvement without even doing anything fancy. Later as certain limits were approached, even these were pushed much further back. The paper is correct in pointing out that the original paper doesn't factor in things like design cost, complexity and other effects. With the exception of memory technologies, modern devices are more and more dominated by interconnect. Wires are components too, even if they are pretty much passive. Moore even makes the important point that costs are dominated by packaging and external interconnect, particularly at the lower intergration levels at that time. These costs are still very significant if no longer dominant in all cases.
I would assert that whenever a new information technology emerges, it sparks a new and more rapid period of near exponential change, both in society and in human intellectual advances as well. In evolutionary time scales, WWII to the present (the whole history of electronic computing fits in this period) is a blink of an eye. In the fossil record, it is impossible to sort out changes that happen at that scale, so it is just about impossible to sort out the internal structure of how it happens.
With modern technology, we have records that give a pretty accurate picture of the evolutionary process in action. Changes is discontinuous; a new process emerges and there is rapid progress as the process undergoes variation and selection at a rapid rate, then the limits of that process is reached and things may settle down for a while. Or the new position may spark additional new processes of a fundamentally different nature and continue the progress for a few more technological generations.
We know that we have only scratched the surface of what is possible with information technology, even if chip technology stagnates, which it won't for a while yet (to 2016 at least according to the experts, which is suspect is the limit of their willingness to attempt to map it, not the possibilities or even the most likely path).
The really frustrating thing about this paper is that it comes very close to making some very good points, but then just drops them. From here on out, technological progress is going to be all about managing extreme complexity, and finding appropriate uses for technology. It is clear that we will be able to design technology to accomplish just about any task we set our collective minds to, and the more important questions become why and how (socially, more than technically).
Without going into all the arguments about why, I will assert that it is the power of sharing ideas and information as embodied in the Free/Open Software movement that has the potential to lead the way.
BTW, in this line of argument is also the best way to refute all the MS FUD on the subject of the GPL. It's all about doing more for less. If you build it they will come, although it may take a little longer than first thought. For simple circuits, you can ignore the design/complexity costs, and nobody has a monopoly on good ideas, so exponential growth is a natural consequence. Things get bottled up when one player tries to monopolize a particular idea (or expression of one). OSS commoditizes software solutions for well known problems, and having a large library of off the shelf solutions to build on is the only way to extend our reach significantly. The control tactics of MS and companies like that are holding back progress, not the other way around as they are now trying to assert.