Microsoft is trying to lie and spin Palladium as something benefiting the end user when
nothing could be further from the truth. Palladium will hurt the end user by exposing
technology that will be used to restrict rights. Microsoft tries very hard (and you are too) to
white wash this as something other than it is. They would have the public believe that this
is good for them and that Microsoft is doing this to help there customers while the only
thing this will help is Microsofts bottom line and Hollywood.
This is hardly unique to Palladium. Virtually every time Microsoft announces a new (or upgraded) product they trumpet how it's good for the customer and contains loads of new "features" users were crying out for. This is basically marketing.
Re:Dams don't change world water levels.
on
Tidal Power a Reality
·
· Score: 3, Interesting
Even if you built dams around all continents, the amount of water you'd trap would be about 0.1% of the surface area of the ocean, for a sea level change of one thousandth the height of the _dam_ (not the ocean). This is truly miniscule.
0.1% of the surface area of the ocean is still huge area, probably far more than you could reasonably build a dam to contain. With respect to the volume of the ocean and dam would be the proverbian "drop".
If you are doing a project of a decent size you can write this kind of stuff into the contract. As the poster said, the commercial vendors were willing to give him exact costs for support over the lifetime of the product.
If your vendor goes bankrupt about the only thing your contract might do is move you up a few places in the creditor queue. How will that fix your problems?
Alot of bean counters will prefer a fixed cost over an unknown cost that may or may not be cheaper. Remember, the license may be free but that doesn't make the product free.
Just because you paid a lot of money for something dosn't mean it's worth it (or indeed worth anything at all.)
Very large empires has folded like the old Greeks, the romans and so on - why not Microsoft ?
It may take some time but it is not unthinkable.
If a business actually folds it can be very quick. Think Pan Am or Enron... Even if some party were to want to take over Microsoft's products they won't be able to until the dust has settled and creditors have been paid.
Which is why the only sensible course of action in most cases is to bet on the horse that you think is most likely to stay in the race longest. Which is more likely? That Microsoft will go out of business, or that Red Hat will go out of business? Smart money's on the Fortune 100 company with $40 billion in the bank.
Alternativly you can do something other than gambling. If Microsoft goes out of business then you have zero support. Whilst $40 billion might sound a lot how does it compare with the turnover of Microsoft Corporation or their stock market valuation. Will that money help out much with cash flow problems (e.g. the EU freezing any Microsoft assets within the EU) or having to prop up all their share options.
Finally, MS needs to sell a lot of Office copies. OfficeXP isn't and hasnt sold well - there is nothing there that makes it any special amount better than Office2k. This new version will be major and will induce a lot of people to buy Office. MS wants that.
Sounds like changing to a new format, in order to force people to upgrade in order to be able to read files they might be sent... From the user POV a new file format isn't really of much interest. Except possibly something like the Star/Open Office format, which creates smaller files. Which thus can more easily be sent as attachments. The typical user is more interested in if the new program will make the things they need to do easier or will allow them to do things they want to do, but havn't been able to do before.
I know you think you are/.'s head iconoclast, but you know as well anyone that MS has NO interest in encouranging crossplatform compatibility in ANY document formats, outside of enough lipservice to fill out the RFP acronym checklist of the day. The *default* save format (i.e. the one that 99% of the user base will use), while possibly being XML based, will no doubt be encumbered by very onerous NDA and licensing restrictions.
Microsoft's idea of "cross platform" office formats is one way. That other programs should be able to output something office can import. Not that other apps should be (easily) able to read the output of an office app.
But Mark in IT can do that whole job in about 15 minutes and have an install script to populate your workstations in 20.
Without needing to bother the users. If an admin has to boot a user off to upgrade the software on a machine then you are paying for two people's time whilst that happens.
I see the holes in my argument, but there are many people who think that the whole cost or 95% of owning a piece of software is the purchase price, and dont take into account the fact that admins cost a measurable amount of money. I was aiming the post more towards those type of people who just see the initial cost as the only cost of a piece of software and then cheerlead for OSS.
Proprietary, "off the shelf", software quite often still needs installing, configuring and ongoing administration (including management of EULA's, per whatever licences, etc.) Having a reduced purchase price and eliminating one ongoing admin cost (not to mention that you cannot wind up having to relicence if your busines merges, splits or otherwise restructures) certainly looks like something to put in the "plus" column. As does not being tied to a specific third party for support.
Presently, I'm working for a company which is using an open source component. We have spent a lot of time debugging the component, since the author no longer supports it. I'm sure we have spent way more than we would have if we had bought a closed source component, but our OS component happens to behave in a way we need and has functionality we couldn't find in other off-the-shelf products.
How much could you have spent, time and money, trying to find a proprietary product which did exactly what you wanted? Or in changing the way you worked to suit the available proprietary software...
Source code includes all the information about what the program will do, but not always in the best form for humans to understand. Depending on the quality of the comments it may not include any information on design or requirements. Thus you may not be able to tell the difference between bugs and features if you only have the source.
Nor can you tell if you just have a piece of binary object code. However it is generally accepted that this is an easier task with source code, especially if you plan on making modifications.
No doubt there were people saying the same about Pan Am, Enron and Worldcom...
however, any open source software important enough to attract a large amount of users, and business users relatively has a higher chance of survival than MS.
Even if you are the only company on the planet using a certain piece of OS software you still have the possibility of having it supported.
Software costs big no matter whether you go open source or closed source. With open source you have to have your own knowledgeable (expensive) staff, but you get to control your own destiny.
Hopefully in the direction of improving your business. But in the end that's down to the managers, same as with any other part of the business
With closed source you can get by with cheap point-n-click monkeys but the software vendor herds you in the direction THEY want you to go... which is straight to their feeding trough.
If it happens to help your business it will only be as a side effect (with you being likely to wind up paying for lots of "junk" from your POV) or it could easily be somewhere you most definitly don't want to go.
In the commerical software world, you cannot use the same product for 10 years. You will purchase upgrades, and you will purchase new hardware to run those upgrades if you want support.
To the timescale of your supplier. You can be in real trouble if you are running more than one proprietary application and their needs conflict.
Since a 52-bit key is 2^57 times easier than a 109-bit key, and it took 4 years for the 109-bit key, please tell me how to break a 52-bit key in one nanosecond.
The length of the key in itself does not tell you the size of the keyspace. Criteria such as all keys having to be prime, have the same parity, etc can make a big difference
It took four years to decode ONE document and this isn't even using standard key-length sizes. What do you mean by "relatively insecure". Relative to what?
It depends on the value of the information in the document. If that information is only valuable for 2 years then it's a waste of time. If the information is valuable for 10 or 20 years then 4 years is time well spent.
True, but you can have as much physical security as you think you need (or can afford). Plus, if it takes someone a year and a half to decode your data, you have a fair bit of time to do whatever damage control is necessary.
If you know that your data has been compromised. A typical spy will copy your data, rather that stealing it. The real use of encryption is to protect data, either in storage or in transit (there are plenty of ways in which you can send data where third party evesdropping is trivial), that it will have lost it's value before any third party can have made sense of it.
Encrypt your data using a key large enough in proportion to the length of time it will take to brute force if someone started today with a supercomputer. Essentially it takes X amount of time to check if a key is valid multiply that by number of combinations and you have a rough guess. So if you want something to be safe for a longer period of time (assuming no fundamental weakness is found in the algorithm), then encrypt it with a larger key - every bit doubles the probable time to break it at current cpu speeds. Of course you have to factor in the approximate doubling of cpu speeds every 18 months... but all that really means is that if we add a bit to the key length every 18 months going forward it will continue to take just as long to break into newly encrypted data.
Where this does become relevent is the (mis)application of cryptography to DRM. Where not only do you have to give everyone a "black box" decryption machine you also want to be able to keep something secret for something of the order of a century.
I think the reason is simply price. I would love to be able to use the features of these 2 products, pause live tv, skip commericals on playback, very easy recording of tv shows. But the truth is, this type of convenience is not worth the $400, $500, $600, or more that they charge for the unit. That's in addition to the monthly fee.
VCRs were hugely expensive 20 odd years ago. Though what proportion of the VCR market does JVC have now...
Furthermore it may be `easy' technically, but the person doing the reverse-engineering may not be the one writing the competing piece of software or designing the piece of competing hardware. The reverse-engineer can only write a spec, from which a clean-room rewrite/redesign can be done by somebody else.
These may be the rules in the US. How much do you think someone in Seoul, Taipai or Bombay cares about them?
However, with low level hardware interfaces, its 100x worse. At that level, every clockcycle DOES matter. Developers don't seem to realize that any latency added by a clunky driver and/or 'wrapper' interface adds the absolute minimum response time a device can have on a given system for users. Therefore, a primary goal should be to MINIMIZE latency. Even drivers written for Microsoft's WDM interface take quite a performance hit compared to the older VXD interfaces.
This can be rather important in an embedded system. Where you probably don't want to use the "latest and greatest" hardware. Due to issues of cost, power consumption, known bugs, etc. Also the code may well have to fit into a fairly small ROM or flash memory.
You forgot:...an army of competitors in the same market who now have your source code which they can use to make their product compatible with your own,
All using a binary only product might do is slow them down a bit.
while you are stuck spending tons of research dollars on reverse engineering their product to compete.
The only way this could happen is if your competitor was producing at least two product lines. Since all of the stuff they are producing which is compatable with yours has GPL drivers.
I think you're missing the point here...that's why it needs to be non-GPL from company's points of view. Merely including a flash code (not text) to be run from a GPL program makes that flash code GPL.
So far as the program is concerned the firmware is "text", simply something it has to output in a certain way to some specific device on some specific bus.
The problem with making a driver GPL is that the firmware code needs to be hidden, which is impossible if any part of that driver is under the GPL. Firmware code can often make a DSP's functionality very, very easy to duplicate - more so than software drivers.
Unless you know exactly what the hardware is any firmware is for all practical purposes a meaningless string of bytes. Anyone capable of cracking open the hardware (even if it's custom) isn't going to find it too hard to disassemble a binary driver or to plug the hardware in through a data capture device.
Slashdot Mirror
Microsoft is trying to lie and spin Palladium as something benefiting the end user when nothing could be further from the truth. Palladium will hurt the end user by exposing technology that will be used to restrict rights. Microsoft tries very hard (and you are too) to white wash this as something other than it is. They would have the public believe that this is good for them and that Microsoft is doing this to help there customers while the only thing this will help is Microsofts bottom line and Hollywood.
This is hardly unique to Palladium. Virtually every time Microsoft announces a new (or upgraded) product they trumpet how it's good for the customer and contains loads of new "features" users were crying out for. This is basically marketing.
Even if you built dams around all continents, the amount of water you'd trap would be about 0.1% of the surface area of the ocean, for a sea level change of one thousandth the height of the _dam_ (not the ocean). This is truly miniscule.
0.1% of the surface area of the ocean is still huge area, probably far more than you could reasonably build a dam to contain. With respect to the volume of the ocean and dam would be the proverbian "drop".
If you are doing a project of a decent size you can write this kind of stuff into the contract. As the poster said, the commercial vendors were willing to give him exact costs for support over the lifetime of the product.
If your vendor goes bankrupt about the only thing your contract might do is move you up a few places in the creditor queue. How will that fix your problems?
Alot of bean counters will prefer a fixed cost over an unknown cost that may or may not be cheaper. Remember, the license may be free but that doesn't make the product free.
Just because you paid a lot of money for something dosn't mean it's worth it (or indeed worth anything at all.)
Very large empires has folded like the old Greeks, the romans and so on - why not Microsoft ? It may take some time but it is not unthinkable.
If a business actually folds it can be very quick. Think Pan Am or Enron... Even if some party were to want to take over Microsoft's products they won't be able to until the dust has settled and creditors have been paid.
Which is why the only sensible course of action in most cases is to bet on the horse that you think is most likely to stay in the race longest. Which is more likely? That Microsoft will go out of business, or that Red Hat will go out of business? Smart money's on the Fortune 100 company with $40 billion in the bank.
Alternativly you can do something other than gambling. If Microsoft goes out of business then you have zero support. Whilst $40 billion might sound a lot how does it compare with the turnover of Microsoft Corporation or their stock market valuation. Will that money help out much with cash flow problems (e.g. the EU freezing any Microsoft assets within the EU) or having to prop up all their share options.
And considering that Office 11 is apparently openly based on XML file formats, this is a sticking point in your theory.
The key point is "based on", a bit like active directory being "based on" open formats...
Finally, MS needs to sell a lot of Office copies. OfficeXP isn't and hasnt sold well - there is nothing there that makes it any special amount better than Office2k. This new version will be major and will induce a lot of people to buy Office. MS wants that.
Sounds like changing to a new format, in order to force people to upgrade in order to be able to read files they might be sent...
From the user POV a new file format isn't really of much interest. Except possibly something like the Star/Open Office format, which creates smaller files. Which thus can more easily be sent as attachments. The typical user is more interested in if the new program will make the things they need to do easier or will allow them to do things they want to do, but havn't been able to do before.
I know you think you are /.'s head iconoclast, but you know as well anyone that MS has NO interest in encouranging crossplatform compatibility in ANY document formats, outside of enough lipservice to fill out the RFP acronym checklist of the day. The *default* save format (i.e. the one that 99% of the user base will use), while possibly being XML based, will no doubt be encumbered by very onerous NDA and licensing restrictions.
Microsoft's idea of "cross platform" office formats is one way. That other programs should be able to output something office can import. Not that other apps should be (easily) able to read the output of an office app.
But Mark in IT can do that whole job in about 15 minutes and have an install script to populate your workstations in 20.
Without needing to bother the users. If an admin has to boot a user off to upgrade the software on a machine then you are paying for two people's time whilst that happens.
I see the holes in my argument, but there are many people who think that the whole cost or 95% of owning a piece of software is the purchase price, and dont take into account the fact that admins cost a measurable amount of money. I was aiming the post more towards those type of people who just see the initial cost as the only cost of a piece of software and then cheerlead for OSS.
Proprietary, "off the shelf", software quite often still needs installing, configuring and ongoing administration (including management of EULA's, per whatever licences, etc.)
Having a reduced purchase price and eliminating one ongoing admin cost (not to mention that you cannot wind up having to relicence if your busines merges, splits or otherwise restructures) certainly looks like something to put in the "plus" column. As does not being tied to a specific third party for support.
Presently, I'm working for a company which is using an open source component. We have spent a lot of time debugging the component, since the author no longer supports it. I'm sure we have spent way more than we would have if we had bought a closed source component, but our OS component happens to behave in a way we need and has functionality we couldn't find in other off-the-shelf products.
How much could you have spent, time and money, trying to find a proprietary product which did exactly what you wanted? Or in changing the way you worked to suit the available proprietary software...
Source code includes all the information about what the program will do, but not always in the best form for humans to understand. Depending on the quality of the comments it may not include any information on design or requirements. Thus you may not be able to tell the difference between bugs and features if you only have the source.
Nor can you tell if you just have a piece of binary object code. However it is generally accepted that this is an easier task with source code, especially if you plan on making modifications.
Though the chance of MS go fold is very small,
No doubt there were people saying the same about Pan Am, Enron and Worldcom...
however, any open source software important enough to attract a large amount of users, and business users relatively has a higher chance of survival than MS.
Even if you are the only company on the planet using a certain piece of OS software you still have the possibility of having it supported.
Software costs big no matter whether you go open source or closed source. With open source you have to have your own knowledgeable (expensive) staff, but you get to control your own destiny.
Hopefully in the direction of improving your business. But in the end that's down to the managers, same as with any other part of the business
With closed source you can get by with cheap point-n-click monkeys but the software vendor herds you in the direction THEY want you to go... which is straight to their feeding trough.
If it happens to help your business it will only be as a side effect (with you being likely to wind up paying for lots of "junk" from your POV) or it could easily be somewhere you most definitly don't want to go.
In the commerical software world, you cannot use the same product for 10 years. You will purchase upgrades, and you will purchase new hardware to run those upgrades if you want support.
To the timescale of your supplier. You can be in real trouble if you are running more than one proprietary application and their needs conflict.
Since a 52-bit key is 2^57 times easier than a 109-bit key, and it took 4 years for the 109-bit key, please tell me how to break a 52-bit key in one nanosecond.
The length of the key in itself does not tell you the size of the keyspace. Criteria such as all keys having to be prime, have the same parity, etc can make a big difference
It took four years to decode ONE document and this isn't even using standard key-length sizes. What do you mean by "relatively insecure". Relative to what?
It depends on the value of the information in the document. If that information is only valuable for 2 years then it's a waste of time. If the information is valuable for 10 or 20 years then 4 years is time well spent.
True, but you can have as much physical security as you think you need (or can afford). Plus, if it takes someone a year and a half to decode your data, you have a fair bit of time to do whatever damage control is necessary.
If you know that your data has been compromised. A typical spy will copy your data, rather that stealing it.
The real use of encryption is to protect data, either in storage or in transit (there are plenty of ways in which you can send data where third party evesdropping is trivial), that it will have lost it's value before any third party can have made sense of it.
Encrypt your data using a key large enough in proportion to the length of time it will take to brute force if someone started today with a supercomputer. Essentially it takes X amount of time to check if a key is valid multiply that by number of combinations and you have a rough guess. So if you want something to be safe for a longer period of time (assuming no fundamental weakness is found in the algorithm), then encrypt it with a larger key - every bit doubles the probable time to break it at current cpu speeds. Of course you have to factor in the approximate doubling of cpu speeds every 18 months... but all that really means is that if we add a bit to the key length every 18 months going forward it will continue to take just as long to break into newly encrypted data.
Where this does become relevent is the (mis)application of cryptography to DRM. Where not only do you have to give everyone a "black box" decryption machine you also want to be able to keep something secret for something of the order of a century.
I think the reason is simply price. I would love to be able to use the features of these 2 products, pause live tv, skip commericals on playback, very easy recording of tv shows. But the truth is, this type of convenience is not worth the $400, $500, $600, or more that they charge for the unit. That's in addition to the monthly fee.
VCRs were hugely expensive 20 odd years ago. Though what proportion of the VCR market does JVC have now...
But nothing sucks like an Electrolux.
Vax actually tried to use "nothing sucks like a Vax" upsetting DEC in the process.
Furthermore it may be `easy' technically, but the person doing the reverse-engineering may not be the one writing the competing piece of software or designing the piece of competing hardware. The reverse-engineer can only write a spec, from which a clean-room rewrite/redesign can be done by somebody else.
These may be the rules in the US. How much do you think someone in Seoul, Taipai or Bombay cares about them?
However, with low level hardware interfaces, its 100x worse. At that level, every clockcycle DOES matter. Developers don't seem to realize that any latency added by a clunky driver and/or 'wrapper' interface adds the absolute minimum response time a device can have on a given system for users. Therefore, a primary goal should be to MINIMIZE latency. Even drivers written for Microsoft's WDM interface take quite a performance hit compared to the older VXD interfaces.
This can be rather important in an embedded system. Where you probably don't want to use the "latest and greatest" hardware. Due to issues of cost, power consumption, known bugs, etc. Also the code may well have to fit into a fairly small ROM or flash memory.
You forgot: ...an army of competitors in the same market who now have your source code which they can use to make their product compatible with your own,
All using a binary only product might do is slow them down a bit.
while you are stuck spending tons of research dollars on reverse engineering their product to compete.
The only way this could happen is if your competitor was producing at least two product lines. Since all of the stuff they are producing which is compatable with yours has GPL drivers.
I think you're missing the point here...that's why it needs to be non-GPL from company's points of view. Merely including a flash code (not text) to be run from a GPL program makes that flash code GPL.
So far as the program is concerned the firmware is "text", simply something it has to output in a certain way to some specific device on some specific bus.
The problem with making a driver GPL is that the firmware code needs to be hidden, which is impossible if any part of that driver is under the GPL. Firmware code can often make a DSP's functionality very, very easy to duplicate - more so than software drivers.
Unless you know exactly what the hardware is any firmware is for all practical purposes a meaningless string of bytes. Anyone capable of cracking open the hardware (even if it's custom) isn't going to find it too hard to disassemble a binary driver or to plug the hardware in through a data capture device.