It doesn't require that you know how the drivers are mapped and pulled in by the OS -- which you can set up by hand if you want to, with BSD or Linux. What concerns me is how the way TBB/PCR/TCMA is set up to enable interference with any device or driver you could ever write, and how it could be applied in an anti-competetive manner towards makers of third party peripherals.
Perhaps I injected some confusion here. By 'pulled-in' I wasn't referring to how they actually got in, but to how a Palladium system with TCPA hardware would go about validating devices and drivers. It seems like a very difficult task, and probably easily fooled by a little configuration trickery. Most driver configuration is past boot, and past bios, so it is going to be in control of the OS.
If I get what you are saying about drivers under Linux or BSD, you are suggesting that the card itself could disable itself if you don't follow the rules exactly. I don't think this is likely or even part of the TCPA spec. After all, it is designed to be disabled, although there may be a lot of things that won't function if it is disabled, but those things aren't going to work under *NIX anyway. I've never seen anything to suggest that I/O cards will do anything to support TCPA, just that drivers may be effected, or at least approved (signed) to be used. Also, that would be Palladium, not TCPA.
Bottom line is that according to the article, TCPA is the hardware support, and it can be disabled, so it won't be able to prevent you from running Linux. My initial comment was related to a dual boot situation, and the fact that you will be sending your IPL checksum to any CA that you need keys from. That checksum may contain sufficient latent information for them to know which boot loader you are using, although the variable partition information may mess this up enough to make it hard.
Backhanded, maybe? You have a point, but the flipside is that it is a valuable skill to be able to get your point across quickly and clearly. Clearly, she valued the fact that they were responsive to the needs of the media format, but I suppose we see this taken too far way too often, so there is some value in unselfconsciously going about your business. The comments about these differences are interesting.
Exactly what I was asking about. Looks like this project was just getting started when I looked around before. Almost ready for prime time, and plenty of functionality to make it worthwhile now. Now if I only had some spare cash to dump into this. Oh well, it will be cheaper and better when I do.
When I though about trying to do this a while back, it didn't look like it was a no-brainer. There were some groups trying to put the pieces together, but it would be nice to have some definitive information about just what is required to make this work. It's got to be better and more flexible than a dedicated box like this, or it has to run on older hardware so I can use an old PII or something. If its not cheaper, it has to be better.
Not just overwriting your MBR -- what about the potential of the TCPA subsystem in collaboration with the TBB to block your own device drivers written for your own (experimental, read: uncertified) devices?
It's a bit unclear (or maybe I didn't completely 'get' that part), how the trusted drivers would be pulled in. I think this would be 99% in the OS and not strictly part of the TCPA. Look at it this way, just what are you going to checksum to make a fingerprint that assures you that the complete OS/driver/configuration set remains unchanged? Even if you manage to do this, you have to allow for it changing, or it is hard to change anything on the system after initial configuration. All this adds up to a situation where either the system is useless, or the controls are relatively easy to circumvent (which is why they need DMCA too). Perhaps more worrysome is the fact that DMCA probably makes it illegal to do any interesting hacking or reverse engineering on a Palladium system.
I don't find TCPA to be that much of a problem in and of itself. As the article points out, the problem is that it is relatively weak at points, and the privacy issues that you have to trust to the CAs. The really nasty bits are not in the TCPA, but in how it is applied. If your goal is to beef up the security of your corporate network, you should be able to implement the CA yourself, and protect any information exchanged with the CA within your own operations, but if your need is to work with DRM media, I doubt this will be possible.
Keep in mind that Palladium is still pretty much vaporware, so we don't know how or what it will restrict. It doesn't look like anything can disuade MS from going down this path, and it is likely that the worst of our fears will be realized in the next few years. OTOH, there are bound to be problems with the implementation, and if MS burns themselves badly enough early on, they may just scrap the whole thing. I doubt that though, more likely they will stubornly keep at it until the realize that Linux has gotten ahead of them in market share, and their business is now doomed. At that point, they might even get religion and adopt Open Source as a business model.
He is pretty clear on MS wanting everyone to believe that TCPA == Palladium, even though it is false. It's also pretty clear that TCPA is just some very limited hardware and firmware support for a few crypto and identity functions. It is essentially OS neutral, and there is no particular security and privacy advantage for Windows no matter what the MS marketdroids say.
The interesting and worrysome parts are the potential to use Palladium for DRM, and that a lot of people could be shut out depending on the details. Most likely there will be a requirement to get a certificate from a 'participating' CA, which could be MS only, but is just as worrysome even if it isn't (say a small list approved by the MPAA and RIAA).
Note also the small comments about DOS attacks that could exploit known MS vulnerabilities to in effect disable your trusted hardware and make it hard to use your computer for just about anything. Basically, the ability of this hardware and associated software to validate your certificate to play content is pretty fragil, and it could be trashed by a virus, or many types of valid upgrades and maintanance of your computer. I think he mentions the difficulty in re-certifying your machine after a change, and that the spec doesn't really cover it. In part, it is because you have to go to TTPs (trusted third parties) to re-certify. That means you have to 'tell' MS when you make your system dual boot and write a GRUB MBR to your boot partition. Tell me that there is no potential for abuse here.
It was all the rage in the early 90s, with every PC company trying to jump on the bandwagon plus a couple of companies dedicated to it as a single concept. MS jumped in with their product which quickly squashed anyone doing actual innovative work, and people quickly realized that all the talk about handwriting recognition was mostly hype. Clearly there is demand for products like this if they can get it right, and it makes great marketting hype even if they don't.
Clearly there is demand for this type of thing if it is well done and well integrated, but there is little to be learned from a rigged demo. The technology background piece has some interesting tidbits, but it doesn't seem like any of the interesting research is coming from MS in the first place.
If we are lucky, some interesting hardware will be built with higher quality input devices, and maybe that will spark some good research. Research is better done in open source, so hopefully the hardware drivers will be available to make this work in Linux.
Yes, the typical arms race situation applies, but the defenders now have some good weapons at their disposal. If the methods that implement the quench feature is robust and hard to subvert, then it is just the server that needs to be updated. Many techniques could be used to identify the sources of the attacks, including some manual help from the system operators. Over time, the demon could get very good at recognizing attacks bases on heuristics, so changes to the flooding packets or patterns might not help get around the filtering.
But it is not your choice. It is the choice of the government, and they should make the choice that maximizes freedom and opportunity. THEY own the copyright, not you.
The government is theoreticaly my representative and/or agent, so this is my choice, or more properly all of ours. You have a right to think that public domain is more free than GPL, but by my reasoning, this is wrong.
The real question is about whether it is a right for the public to be able to exploit government work for their own benefit. Ok, I accept that this is often how it works, but I think it is a better principle to make them pay a reasonable licensing fee if they want to take it private in a derivitive work. The government has given away far to many things to private interests whose idea of paying for it is to buy polititions. All of this is a corruption of the nation and its political system.
I find GPL and LGPL terms for software to be more free in most situations than BSD style licensing. You may disagree, but simply stating your position isn't an argument.
Think about it. If you're a software company doing work under contract for the government. Given a choice between "Release under GPL" and "Release under BSD or straight public domain", which would you choose? I would choose GPL because in keeps my competitors from just picking up my work and taking it private in an "upgraded" version.
Even if I have a piece of code that I hold the copyright exclusively, I would consider releasing a version under GPL, but not BSD. The reason is simple, I can still create derivitive works under whatever license I choose, but if I choose BSD, then my competiters can do the same thing.
It is clear that a lot of people just don't get this. Yes, GPL is more restrictive, but that is a good thing and it protects the original owner of the copyright as well by keeping derivitives free and open.
Maybe, but as far as I know he never 1) used the information against the company in any way, and 2) his intention was always to help them improve security. Yes, he was stupid for not getting some sort of permission to probe for security weaknesses, but the employer was much more stupid for how they treated him. A reprimand would have been more than sufficient. I would never want to work for a company that treated people that way, wrong or right.
From what I recall, I don't think he had done this from outside, but rather he had copies of the password files and cracking tools on his work machine. Maybe someone has a link to more specific information, but this is an important distinction.
SGI didn't appreciate the work of the guy who developed "Satan" either. Some people would rather not know about their security holes, then they might have to actually do something to fix them.
You could talk to a lawyer, but it's probably overkill. Write something up that describes generally what you will be working on, and how and why you are going to use snooping tools. Even without a non-disclosure agreement, you shouldn't reveal anything you accidentally find out, and only record and report on data that is related to work you are doing. Simple clear language, and having it acknowledged in writing by the client will make it easy to defend yourself if it comes to that. Of course, you don't want it to come to that, but the danger is really from politics. If you think the people you work for are challenging internal politics, and aren't completely in control of it, be very careful. Even then, as long as everyone knows what you are there for, and your work is outside of the very political, you should be fine.
The bands of blue stars suggests that there is quite a bit of large star formation triggered by the collision. It could be either or both dust clouds from one galaxy triggered into star formation by star masses in the other, or merged clouds that are now above some critical density.
I've never heard of this type of thing, although it would be perfect for this application.
The cluster of them around the CDW in Chicago is still there over a year later, so I think it was actually paint at least in this case. None of the reports I heard about this said it was chalk, which makes it a bit more of an aggressive act toward people with homes and businesses in the immediate area.
This and other replies confirm my thinking that it was cell phones, and not the on-flight phones. Anybody know if these can be disabled from the cockpit? Likely, the minimally trained terrorist pilots wouldn't know where the control is unless it had a simple clear label, but my point was that any 'flight' system would be vulnerable this way.
I don't think they had enough people to try to take all the cell phones away, so I doubt they would have even tried. They were counting on surprise and coordination to make the scenario that played out on this flight less likely. For the future, the important thing is it will never be as easy to get control of the cockpit of any flight. Planes might be crashed, but I think it is very unlikely that anyone will get control of a cockpit again.
My understanding was that the people on the flight that went down in Pennsylvania were using cell-phones to get updated about what was going on in the real world. Or were they using the on-board phones they usually have in the seat backs? If the latter, it begs the question of whether the terrorists could have shut down that system from the cockpit, or did they? Even though cell-phones are not designed to be used from 30,000 feet, I imagine they work fine over most of the country.
This proposed systems would probably be controllable from the cockpit as well, and could easily make any cell phone on the plane inoperable. Maybe that is what the control oriented security freaks want, but I think it has many dangers.
You people are confusing the universe with maps of the universe. e and pi are mathematical objects, and important tools for understanding the highly detailed and fairly accurate *maps* of the world, but they should never be confused with the world itself.
Or maybe in keeping with the theme from that paper about Postmodern programming, we could call it a postmodern community.
At first, I was going to respond to the grandparent to say that/. is a community, but on further reflection, I think I would say it is both. You can read/. for interesting links and such and never really see or experience the community aspects. Or you can skip the headlines, and 'cruze the journal circuit' as you suggest.
Clearly there is a lot of diversity of opinion, although moderation tends to reward certain viewpoints closer to the center of the bell curve. The community values as expressed through moderation are not mainstream, and I would say it is defined by a high level of tech knowledge, but I wouldn't say it is fringe.
I love/. because it has a similar feel to netnews in the early days, and the moderation tends to push the trolls and flames further away. It's also pretty clear that most slashdotters have not been around since those early days, so they might not even know what I'm talking about here, but they have the same in-your-face, prove-your-assertion attitudes that were present all along. That's what is cool about it, it bridges between generations of hackers. Some came of age after HTTP and HTML revolutionized the technology of online community, and others were part of the hobbie computer movement that started it all. Moderation means I don't spend nearly as much time reading through BS arguments and other drivel as the old days (essential since the wider ready of the modern internet means even more people who would disrupt things just for attention).
IBM release th framework in which to do so because of the governmental investigation they were under at the time.
I don't think there was any connection to the IBM anti-trust case. They had been trying to get into the small and 'home' computer markets for years. The DisplayWriter had some limited success. I don't think they realized that the big market for the machines was business, not the home. If you look at the first offering, this is pretty clear. It had casset tape support, not floppies nor any hint of a hard disk option. The configuration that was sold most often had most of the ISA slots filled so you could have: floppies, Monochrome text plus printer, extra memory, and ??? (memory fade). The XT wasn't far behind, and it had all of that and a hard disk as a base configuration.
All the talk at the time was that if IBM had really known what they had, they would have tried a lot harder to control things and lock up the standard. It probably wouldn't have been the success it was if they had, but it's hard to know since it didn't happen that way.
It looks like it is designed correctly from a physical standpoint. Hot swap should and blind mating should be part of the program. I looked at it in some detail a while back. They even planned for progressive mating of the ground first. All the big drive manufacturers seem to be behind it.
The only thing I haven't seen is any noise about chip sets that support in on the system side. As soon as these are available, you'll see MBs and systems. SCSI will probably stay important for larger faster arrays, but scaling bandwidth seems to look pretty good for this as well.
As soon as mainstream MBs are there, these will quickly become the commodity drives for all the manufacturers, and they will phase out Parallel ATA stuff.
This wasn't mentioned in the LCD roundup the other day, but the really big pro on the LCD side is that it doesn't look like something to climb on top of to my 2 year old. We use our "17 KDS in the living room, and it is just perfect for our application.
Yes, the >17 are still way to expensive, and I would be happy to pay a few hundred less for a one the size I have now, but the difference in cost is now small enough to justify the advantages (depending on importance to you, of course).
This issue gets right to the heart of the central purpose of the GPL, to prevent embrace and extend unless the extention is just as free as the original. The important question is which licensing scheme best serves the public interest, not which one meets your definition of publicly available.
Take TCP/IP, which is BSD licensed originally. What would have changed if it was GPL as well? Would it have prevented MS from adopting it (after much resistance anyway)? Would it have prevented "Embrace and extend"? MS does lots of proprietary protocols layered on top of TCP/IP, but I doubt GPL would really prevent that. SMB, WINS and such would still be much as they are now. They (MS) may have even read GPL code before coding their varient of the basic protocal stacks rather than just deriving from the BSD source base. None of this would have changed much. Free software would still be free, and commercial would be commercial.
OTOH, languages are different than protocols, and I think it is very important to prevent embrace and extend for languages at all levels. From HTML and Word.doc formats to Java, C, C++, and all the associated standard APIs, system call interfaces and such. All of these require open standards and GPL style copy protection for a standard toolset. Anything less tends to destroy the long term value of any program written 'with' the tools. This doesn't preclude proprietary implementations of various tools and standards.
Legislation to prevent the use of GPL or similar license terms by governments agencies would prevent them from making a decision that GPL is in the public interest for a particular program.
The real question is which formats make a difference to the people who might actually buy one of these things. MP3 is no doubt a must. WMA? I have no idea, and I don't care, but Ogg would definitely be a selling point for me. So if you do a market study of likely buyers of this product category, is Ogg going to make the list or not? If you survey/., I'm sure it would make the list. I suspect the market for this is slanted toward/. types generally, but how much.
I gather it doesn't have the outputs to play directly to a TV, that's a bummer too. In my quick read I thought they implied it could be used with a TV, but it wasn't that clear. Is it just a matter of the outputs, or does DVD playing require some processing in the PC that would normally be handled in a dedicated DVD player.
Negative! Do not attempt to combine the distinct tasks of packing and weeding out. These are both more time consuming than one initially realizes.
All too true, but I was trying to say weed and sort beforehand. The more organized and de-junked you are the more ready you are at the time of the move. Realistically a lot of people haven't done enough before the move, so there will always be things you decide it isn't worth it to move (depending on distance of move, size of truck, etc.)
Slashdot Mirror
Perhaps I injected some confusion here. By 'pulled-in' I wasn't referring to how they actually got in, but to how a Palladium system with TCPA hardware would go about validating devices and drivers. It seems like a very difficult task, and probably easily fooled by a little configuration trickery. Most driver configuration is past boot, and past bios, so it is going to be in control of the OS.
If I get what you are saying about drivers under Linux or BSD, you are suggesting that the card itself could disable itself if you don't follow the rules exactly. I don't think this is likely or even part of the TCPA spec. After all, it is designed to be disabled, although there may be a lot of things that won't function if it is disabled, but those things aren't going to work under *NIX anyway. I've never seen anything to suggest that I/O cards will do anything to support TCPA, just that drivers may be effected, or at least approved (signed) to be used. Also, that would be Palladium, not TCPA.
Bottom line is that according to the article, TCPA is the hardware support, and it can be disabled, so it won't be able to prevent you from running Linux. My initial comment was related to a dual boot situation, and the fact that you will be sending your IPL checksum to any CA that you need keys from. That checksum may contain sufficient latent information for them to know which boot loader you are using, although the variable partition information may mess this up enough to make it hard.
Backhanded, maybe? You have a point, but the flipside is that it is a valuable skill to be able to get your point across quickly and clearly. Clearly, she valued the fact that they were responsive to the needs of the media format, but I suppose we see this taken too far way too often, so there is some value in unselfconsciously going about your business. The comments about these differences are interesting.
Thanks for the link.
When I though about trying to do this a while back, it didn't look like it was a no-brainer. There were some groups trying to put the pieces together, but it would be nice to have some definitive information about just what is required to make this work. It's got to be better and more flexible than a dedicated box like this, or it has to run on older hardware so I can use an old PII or something. If its not cheaper, it has to be better.
It's a bit unclear (or maybe I didn't completely 'get' that part), how the trusted drivers would be pulled in. I think this would be 99% in the OS and not strictly part of the TCPA. Look at it this way, just what are you going to checksum to make a fingerprint that assures you that the complete OS/driver/configuration set remains unchanged? Even if you manage to do this, you have to allow for it changing, or it is hard to change anything on the system after initial configuration. All this adds up to a situation where either the system is useless, or the controls are relatively easy to circumvent (which is why they need DMCA too). Perhaps more worrysome is the fact that DMCA probably makes it illegal to do any interesting hacking or reverse engineering on a Palladium system.
I don't find TCPA to be that much of a problem in and of itself. As the article points out, the problem is that it is relatively weak at points, and the privacy issues that you have to trust to the CAs. The really nasty bits are not in the TCPA, but in how it is applied. If your goal is to beef up the security of your corporate network, you should be able to implement the CA yourself, and protect any information exchanged with the CA within your own operations, but if your need is to work with DRM media, I doubt this will be possible.
Keep in mind that Palladium is still pretty much vaporware, so we don't know how or what it will restrict. It doesn't look like anything can disuade MS from going down this path, and it is likely that the worst of our fears will be realized in the next few years. OTOH, there are bound to be problems with the implementation, and if MS burns themselves badly enough early on, they may just scrap the whole thing. I doubt that though, more likely they will stubornly keep at it until the realize that Linux has gotten ahead of them in market share, and their business is now doomed. At that point, they might even get religion and adopt Open Source as a business model.
The interesting and worrysome parts are the potential to use Palladium for DRM, and that a lot of people could be shut out depending on the details. Most likely there will be a requirement to get a certificate from a 'participating' CA, which could be MS only, but is just as worrysome even if it isn't (say a small list approved by the MPAA and RIAA).
Note also the small comments about DOS attacks that could exploit known MS vulnerabilities to in effect disable your trusted hardware and make it hard to use your computer for just about anything. Basically, the ability of this hardware and associated software to validate your certificate to play content is pretty fragil, and it could be trashed by a virus, or many types of valid upgrades and maintanance of your computer. I think he mentions the difficulty in re-certifying your machine after a change, and that the spec doesn't really cover it. In part, it is because you have to go to TTPs (trusted third parties) to re-certify. That means you have to 'tell' MS when you make your system dual boot and write a GRUB MBR to your boot partition. Tell me that there is no potential for abuse here.
Clearly there is demand for this type of thing if it is well done and well integrated, but there is little to be learned from a rigged demo. The technology background piece has some interesting tidbits, but it doesn't seem like any of the interesting research is coming from MS in the first place.
If we are lucky, some interesting hardware will be built with higher quality input devices, and maybe that will spark some good research. Research is better done in open source, so hopefully the hardware drivers will be available to make this work in Linux.
Yes, the typical arms race situation applies, but the defenders now have some good weapons at their disposal. If the methods that implement the quench feature is robust and hard to subvert, then it is just the server that needs to be updated. Many techniques could be used to identify the sources of the attacks, including some manual help from the system operators. Over time, the demon could get very good at recognizing attacks bases on heuristics, so changes to the flooding packets or patterns might not help get around the filtering.
The government is theoreticaly my representative and/or agent, so this is my choice, or more properly all of ours. You have a right to think that public domain is more free than GPL, but by my reasoning, this is wrong.
The real question is about whether it is a right for the public to be able to exploit government work for their own benefit. Ok, I accept that this is often how it works, but I think it is a better principle to make them pay a reasonable licensing fee if they want to take it private in a derivitive work. The government has given away far to many things to private interests whose idea of paying for it is to buy polititions. All of this is a corruption of the nation and its political system.
I find GPL and LGPL terms for software to be more free in most situations than BSD style licensing. You may disagree, but simply stating your position isn't an argument.
Even if I have a piece of code that I hold the copyright exclusively, I would consider releasing a version under GPL, but not BSD. The reason is simple, I can still create derivitive works under whatever license I choose, but if I choose BSD, then my competiters can do the same thing.
It is clear that a lot of people just don't get this. Yes, GPL is more restrictive, but that is a good thing and it protects the original owner of the copyright as well by keeping derivitives free and open.
Read the article. They have a heater to warm up the CPU pins and surrounding MB area to prevent condensation.
Maybe, but as far as I know he never 1) used the information against the company in any way, and 2) his intention was always to help them improve security. Yes, he was stupid for not getting some sort of permission to probe for security weaknesses, but the employer was much more stupid for how they treated him. A reprimand would have been more than sufficient. I would never want to work for a company that treated people that way, wrong or right.
From what I recall, I don't think he had done this from outside, but rather he had copies of the password files and cracking tools on his work machine. Maybe someone has a link to more specific information, but this is an important distinction.
SGI didn't appreciate the work of the guy who developed "Satan" either. Some people would rather not know about their security holes, then they might have to actually do something to fix them.
You could talk to a lawyer, but it's probably overkill. Write something up that describes generally what you will be working on, and how and why you are going to use snooping tools. Even without a non-disclosure agreement, you shouldn't reveal anything you accidentally find out, and only record and report on data that is related to work you are doing. Simple clear language, and having it acknowledged in writing by the client will make it easy to defend yourself if it comes to that. Of course, you don't want it to come to that, but the danger is really from politics. If you think the people you work for are challenging internal politics, and aren't completely in control of it, be very careful. Even then, as long as everyone knows what you are there for, and your work is outside of the very political, you should be fine.
The bands of blue stars suggests that there is quite a bit of large star formation triggered by the collision. It could be either or both dust clouds from one galaxy triggered into star formation by star masses in the other, or merged clouds that are now above some critical density.
The cluster of them around the CDW in Chicago is still there over a year later, so I think it was actually paint at least in this case. None of the reports I heard about this said it was chalk, which makes it a bit more of an aggressive act toward people with homes and businesses in the immediate area.
I don't think they had enough people to try to take all the cell phones away, so I doubt they would have even tried. They were counting on surprise and coordination to make the scenario that played out on this flight less likely. For the future, the important thing is it will never be as easy to get control of the cockpit of any flight. Planes might be crashed, but I think it is very unlikely that anyone will get control of a cockpit again.
This proposed systems would probably be controllable from the cockpit as well, and could easily make any cell phone on the plane inoperable. Maybe that is what the control oriented security freaks want, but I think it has many dangers.
Category errors are a bitch.
At first, I was going to respond to the grandparent to say that /. is a community, but on further reflection, I think I would say it is both. You can read /. for interesting links and such and never really see or experience the community aspects. Or you can skip the headlines, and 'cruze the journal circuit' as you suggest.
Clearly there is a lot of diversity of opinion, although moderation tends to reward certain viewpoints closer to the center of the bell curve. The community values as expressed through moderation are not mainstream, and I would say it is defined by a high level of tech knowledge, but I wouldn't say it is fringe.
I love /. because it has a similar feel to netnews in the early days, and the moderation tends to push the trolls and flames further away. It's also pretty clear that most slashdotters have not been around since those early days, so they might not even know what I'm talking about here, but they have the same in-your-face, prove-your-assertion attitudes that were present all along. That's what is cool about it, it bridges between generations of hackers. Some came of age after HTTP and HTML revolutionized the technology of online community, and others were part of the hobbie computer movement that started it all. Moderation means I don't spend nearly as much time reading through BS arguments and other drivel as the old days (essential since the wider ready of the modern internet means even more people who would disrupt things just for attention).
I don't think there was any connection to the IBM anti-trust case. They had been trying to get into the small and 'home' computer markets for years. The DisplayWriter had some limited success. I don't think they realized that the big market for the machines was business, not the home. If you look at the first offering, this is pretty clear. It had casset tape support, not floppies nor any hint of a hard disk option. The configuration that was sold most often had most of the ISA slots filled so you could have: floppies, Monochrome text plus printer, extra memory, and ??? (memory fade). The XT wasn't far behind, and it had all of that and a hard disk as a base configuration.
All the talk at the time was that if IBM had really known what they had, they would have tried a lot harder to control things and lock up the standard. It probably wouldn't have been the success it was if they had, but it's hard to know since it didn't happen that way.
The only thing I haven't seen is any noise about chip sets that support in on the system side. As soon as these are available, you'll see MBs and systems. SCSI will probably stay important for larger faster arrays, but scaling bandwidth seems to look pretty good for this as well.
As soon as mainstream MBs are there, these will quickly become the commodity drives for all the manufacturers, and they will phase out Parallel ATA stuff.
Yes, the >17 are still way to expensive, and I would be happy to pay a few hundred less for a one the size I have now, but the difference in cost is now small enough to justify the advantages (depending on importance to you, of course).
Take TCP/IP, which is BSD licensed originally. What would have changed if it was GPL as well? Would it have prevented MS from adopting it (after much resistance anyway)? Would it have prevented "Embrace and extend"? MS does lots of proprietary protocols layered on top of TCP/IP, but I doubt GPL would really prevent that. SMB, WINS and such would still be much as they are now. They (MS) may have even read GPL code before coding their varient of the basic protocal stacks rather than just deriving from the BSD source base. None of this would have changed much. Free software would still be free, and commercial would be commercial.
OTOH, languages are different than protocols, and I think it is very important to prevent embrace and extend for languages at all levels. From HTML and Word .doc formats to Java, C, C++, and all the associated standard APIs, system call interfaces and such. All of these require open standards and GPL style copy protection for a standard toolset. Anything less tends to destroy the long term value of any program written 'with' the tools. This doesn't preclude proprietary implementations of various tools and standards.
Legislation to prevent the use of GPL or similar license terms by governments agencies would prevent them from making a decision that GPL is in the public interest for a particular program.
I gather it doesn't have the outputs to play directly to a TV, that's a bummer too. In my quick read I thought they implied it could be used with a TV, but it wasn't that clear. Is it just a matter of the outputs, or does DVD playing require some processing in the PC that would normally be handled in a dedicated DVD player.
All too true, but I was trying to say weed and sort beforehand. The more organized and de-junked you are the more ready you are at the time of the move. Realistically a lot of people haven't done enough before the move, so there will always be things you decide it isn't worth it to move (depending on distance of move, size of truck, etc.)