My impression from this document is that it is an optional feature, only active when the creator of the document specifies who can read it. When the creator thinks it should only be readable on Windows 2003, and not on other software, that is his responsibility. And it is the responsibility of the reader to reject such documents as unusable.
This is hardly new. We use StarOffice 5.2 at work, and it cannot open password-protected documents from Office 95 or 2000. This is amongst the least problems when using that package in a mixed Office-StarOffice environment.
The problem exists, but only for "a-brand" computers. That means it exists for oranizations, yes. When you go to the shop nearby they will happily sell you their clone-of-today, usually offering a much more modern machine for the same price, and you get get it without Windows.
But sure, when you want to have something from HP, Dell, IBM etc it will be Microsoft-tax-included.
Of course this involves only the operating system, which is pretty useless by itself. When you need additional software like Office, it will be cheaper to discard the license, format the disk, and install Linux and OpenOffice.
That is not a stupid and greedy business model. Today's consumers expect a small entrance cost. Mobile telephony (at least in Europe) has boomed just because of that: you get your phone for free and you pay when you make a call. When you don't make a call it costs you nothing. Consumers like that. Furthermore, such a model protects the consumer against the risk of the provider going out of business. When they do, the subscription ends and they have no or little investment loss. This is very important, especially for services where the applicance is mostly or completely useless when the service you subscribe to is no longer available.
Newer versions of Windows attempt to solve the reboot problem, but it seems certain application installers request a reboot "just in case", or because they do not make this behaviour dependent on the OS version.
But the fundamental issue of replacing a shared library (DLL) file that is in use without rebooting still hasn't been solved. Unix filesystem semantics make this a very simple operation (you can remove a file that is open), but Windows cannot do it (file is in use, so nothing can be done to it).
This was no random example. This has already happened.
>It is no different then me going out and buying a new Ford Taurus, taking it apart, finding different uses for the various parts and then telling others about those various uses.
Yes it is different. The difference is that Ford charges you the whole value of your Taurus plus all profit at the time of sale. They hope you will spend more on maintenance, but that is not part of the calculation.
Now look at today's subscription-based electronics. I gave an example, other examples are mobile phones, other mobile gadgets that require some Internet connection service, a game console, etc. When you get one (nearly) for free and then do not pay a subscription or never buy games, you are actually attacking their business model. Of course that is their risk, but when this happens all the time they will have to change it.
For example: a small computer system that runs Linux and can be used to browse the Internet using a subscription that is part of the deal. You get the system for a very small amount of money and the company expects you to subscribe for a monthly fee to use it. Then, Linux gurus find out how to use it with their existing Internet account or use it as a plain terminal, and just buy the box and not the monthly subscription.
When a manufacturer would think there is a market for an Internet browsing box using this marketing model, and they use Linux as the OS, the entire techies world laughs and buys only the machine and not the subscription, the next time they probably would not select Linux but something more closed that they maybe can lock down easier or that the nerds will not focus on so much.
> You're not taking into account that some systems sit in boxes in the warehouse or in transit when some updates are released.
I think this is not the way Dell manufactures.
>I would find it hard to believe that the OP's father's box was devoid of any fix.
Me too, but seeing is believing. We normally overwrite the pre-install immediately, but recently we bought a Dell for some employee to use privately and when starting Windows update it wanted to install ALL the post-SP1 fixes.
Installation from images sucks. But I can understand why a manufacturing plant needs to do it.
What I don't understand is why a manufacturing plant cannot download Microsoft fixes, and update their images with those. I presume Microsoft has ready-made tools to do that, and if not the manufacturer should devise a mechanism. E.g. make a directory where hotfixes are stored, and in the scripts run on the first boot automatically run all the hotfixes found in that directory.
That should make it very easy to add a fix once it appears, and have it on all machines delivered to customers a few days later.
No excuse to deliver bare SP1-level systems with no hotfix whatsoever.
When you buy a Windows XP system from Dell and start Windows update, it is gong to download about 30MB worth of patches... not nice when you have a modem line.
But this seems to be M$ policy. They don't update their distribution versions, they just bring out patches and service packs. And even that they no longer seem to do at a high priority.
When we powerup a new Dell system the first thing that we do is press F2, enter BIOS setup, enable network boot (set LAN device to LAN w/PXE), save and exit, hit F12, and boot from network.
On the network is a boot image that formats the disk and automatically installs Windows 2000 and all desired applications. We never see the EULA screen.
Why would anyone in a medium to large company want to use a pre-installed Windows that has to be manually configured on each box, when an unattended setup procedure is so much more convenient?
I have a DVB-S (digital satellite TV) receiver that runs Linux, and I must say it is a very nice box for the computer hobbyist, and probably still quite usable for the normal consumer.
Out of the box one can just use it as a receiver, but once you connect it to your LAN (ethernet) you can browse its contents using SMB (it runs SAMBA) or a web browser. You can edit its configuration files using "vi" over telnet, you can NFS-mount a disk on another system and record movies on it, plug in a USB memory key and backup your configuration, etc etc.
Not all are things that a consumer would want to do, but very nice to have. I presume not all Linux-based consumer electronics boxes will be as open as this one, though.
What "we" have to avoid, I think, is to criticize manfacturers that use Linux and do not at the same time make the box open to access like described above. Especially bad is to "hack" into Linux-based devices beyond what one can be reasonably expected to do with something you own, and to blackmail manufacturers into releasing information and source code of proprietary parts.
Behaviour like that could quickly make the big manufacturers a lot less enthousiastic about using Linux.
In the case of hardware, for certain classes of hardware there is not much choice when one wants to use Linux. People are happy that even a single manufacturer wants to support Linux. The driver may be very complex and contain lots of proprietary code. E.g. a PCI ADSL card. One can use these in a router, and may want to move on to a new kernel to have more advanced networking features.
In the case of Mozilla, the situation is even more complicated. One wants to install the new version of Mozilla to see if the IMAP code is improved, then finds that a plugin no longer works. "Then don't upgrade" is often not practical.
I agree that it is sometimes required to improve an interface and that it is not always practical to keep compatability, but I think it is too often waved away with a simple "just recompile". This happened with a couple of C library changes as well, and I think there is not only a C++ change in this case, because the compiler version change affects the kernel and loadable kernel modules as well. Maybe that is a different issue, as the kernel is written in C.
Open source advocates tend to ignore the fact that some parts of some people's systems are not open source. When I decide to buy a piece of hardware from a manufacturer who is the only one that supports Linux and supports it using a binary-only driver, I can decide to go with that solution. Then I don't like it when arbitrary changes to interfaces break the module, as the manufacturer may no longer be around or may no longer be supporting Linux. Same for browser plugins.
So whenever possible it would be preferred when existing modules or plugins continue to work, maybe not with the functionality of newly written or recompiled ones. Sure a balance always has to be found.
That would be nice, but there you also assume that whenever you make a change to the binary interface, providers of binary-only plugins will quickly line up to make their new plugin available.
When that method would have been used, you would just not be able to install the new Mozilla beta now, because dependencies that cannot be solved would exist.
Sure that prevents unfortunate mistakes, but it does not solve the underlying problem.
The problem is known. It does not need to be found through a beta.
What makes you think this will be fixed before the final version will be released? The bug reports seem to consider it a fact of life, not a problem somebody is actively working on.
This just demonstrates that the plugin interface is broken.
The problem of interfacing GCC 2.95 compiled code to GCC 3.x compiled code should be fixed, preferably once for all cases (it also affects kernel modules, for example) and if that is not possible it should be fixed inside Mozilla or in a "shim" plugin.
And while that is done, a new interface should be defined that does not depend on things like this, and the plugin coders should be motivated to move to that new interface.
Do you think the providers of binary-only plugins will be helping is for much longer when we lock them out at arbitrary moments and require them to spend work on building a new distribution package? As it is now, the percentage of plugins supported on Linux is already relatively small. Moves like this are certainly not going to make it better.
What if Real or Adobe decide that this is it and no GCC 3.x compilation of their product will be brought out? Will Mozilla step back to GCC 2.95, will they fix the problem, or will they just kill their browser product by saying "sorry guys, no more Acrobat PDF viewing!"???
When one has a great product and firmly believes another party has stolen intellectual property from it, why would anyone in their right mind let that great product impersonate as the competing and allegedly fraudulous one?
Wouldn't it be more appropriate if a UTP Ethernet be called "wired Ethernet"? "Ethernet" by itself should be more than descriptive enough for a wireless network...
This thread is about a card. There are other cards as well. DVB is in wide use in Europe, mainly on satellite (DVB-S) but also on cable (DVB-C) and terrestrial (DVB-T). I am not aware of any HDTV transmission in Europe, but it may well be that tests are going on.
>Now I finally get it -- you're looking for the magic header of DOS.exe files by examining its Base64-encoded representation.
That is how it works. When you examine a couple of messages that include an executable attachment you will see this pattern appear all the time.
>It's possible, though not likely, that the payload will slip through your filter if for some reason it was uuencoded
That can be handled by a similar pattern. Of course it does not hurt to do both the extension matching and the content matching. Remember that a program in Windows can register its own extensions and define them as executable code.
I have posted this answer a couple of times in other threads and on other forums, so maybe the surrounding explanation has been cut back too far after repeatedly giving this suggestion.
I am not discomforted by the moderation, I was just amazed.
Of course that is true, but not really a solution for the card I have now. It has a single VGA and a single TV-OUT. For this solution a card with two VGA outputs is required. I could not find one that also has TV-IN (they exist but not in the shops nearby).
With Linux it should be possible to generate the correct (or at least close enough) sync signals while in Xfree.
The external circuit will be required, yes. Also to generate the SCART switching voltages to enable RGB.
And then, it may be a short lived solution as I have found that many video products are switching from RGB to YPrPb, for a reason I still have to find out (maybe only to make existing RGB equipment unusable with new stuff?)
Slashdot Mirror
My impression from this document is that it is an optional feature, only active when the creator of the document specifies who can read it.
When the creator thinks it should only be readable on Windows 2003, and not on other software, that is his responsibility. And it is the responsibility of the reader to reject such documents as unusable.
This is hardly new. We use StarOffice 5.2 at work, and it cannot open password-protected documents from Office 95 or 2000. This is amongst the least problems when using that package in a mixed Office-StarOffice environment.
Ok, for us that is only possible on servers, not on workstations.
The problem exists, but only for "a-brand" computers. That means it exists for oranizations, yes.
When you go to the shop nearby they will happily sell you their clone-of-today, usually offering a much more modern machine for the same price, and you get get it without Windows.
But sure, when you want to have something from HP, Dell, IBM etc it will be Microsoft-tax-included.
Of course this involves only the operating system, which is pretty useless by itself. When you need additional software like Office, it will be cheaper to discard the license, format the disk, and install Linux and OpenOffice.
That is not a stupid and greedy business model.
Today's consumers expect a small entrance cost.
Mobile telephony (at least in Europe) has boomed just because of that: you get your phone for free and you pay when you make a call. When you don't make a call it costs you nothing. Consumers like that.
Furthermore, such a model protects the consumer against the risk of the provider going out of business. When they do, the subscription ends and they have no or little investment loss.
This is very important, especially for services where the applicance is mostly or completely useless when the service you subscribe to is no longer available.
Newer versions of Windows attempt to solve the reboot problem, but it seems certain application installers request a reboot "just in case", or because they do not make this behaviour dependent on the OS version.
But the fundamental issue of replacing a shared library (DLL) file that is in use without rebooting still hasn't been solved. Unix filesystem semantics make this a very simple operation (you can remove a file that is open), but Windows cannot do it (file is in use, so nothing can be done to it).
> I don't see it happening this way.
This was no random example. This has already happened.
>It is no different then me going out and buying a new Ford Taurus, taking it apart, finding different uses for the various parts and then telling others about those various uses.
Yes it is different. The difference is that Ford charges you the whole value of your Taurus plus all profit at the time of sale. They hope you will spend more on maintenance, but that is not part of the calculation.
Now look at today's subscription-based electronics. I gave an example, other examples are mobile phones, other mobile gadgets that require some Internet connection service, a game console, etc.
When you get one (nearly) for free and then do not pay a subscription or never buy games, you are actually attacking their business model.
Of course that is their risk, but when this happens all the time they will have to change it.
This is what it says in the upper-right corner of the screen.
Or is that only when played on Linux?
For example: a small computer system that runs Linux and can be used to browse the Internet using a subscription that is part of the deal.
You get the system for a very small amount of money and the company expects you to subscribe for a monthly fee to use it.
Then, Linux gurus find out how to use it with their existing Internet account or use it as a plain terminal, and just buy the box and not the monthly subscription.
When a manufacturer would think there is a market for an Internet browsing box using this marketing model, and they use Linux as the OS, the entire techies world laughs and buys only the machine and not the subscription, the next time they probably would not select Linux but something more closed that they maybe can lock down easier or that the nerds will not focus on so much.
But should that lesson be "DON'T USE LINUX"?
I already said: "beyond what one can be reasonably expected to do with something you own".
> You're not taking into account that some systems sit in boxes in the warehouse or in transit when some updates are released.
I think this is not the way Dell manufactures.
>I would find it hard to believe that the OP's father's box was devoid of any fix.
Me too, but seeing is believing.
We normally overwrite the pre-install immediately, but recently we bought a Dell for some employee to use privately and when starting Windows update it wanted to install ALL the post-SP1 fixes.
Installation from images sucks.
But I can understand why a manufacturing plant needs to do it.
What I don't understand is why a manufacturing plant cannot download Microsoft fixes, and update their images with those.
I presume Microsoft has ready-made tools to do that, and if not the manufacturer should devise a mechanism. E.g. make a directory where hotfixes are stored, and in the scripts run on the first boot automatically run all the hotfixes found in that directory.
That should make it very easy to add a fix once it appears, and have it on all machines delivered to customers a few days later.
No excuse to deliver bare SP1-level systems with no hotfix whatsoever.
When you buy a Windows XP system from Dell and start Windows update, it is gong to download about 30MB worth of patches... not nice when you have a modem line.
But this seems to be M$ policy. They don't update their distribution versions, they just bring out patches and service packs. And even that they no longer seem to do at a high priority.
When we powerup a new Dell system the first thing that we do is press F2, enter BIOS setup, enable network boot (set LAN device to LAN w/PXE), save and exit, hit F12, and boot from network.
On the network is a boot image that formats the disk and automatically installs Windows 2000 and all desired applications.
We never see the EULA screen.
Why would anyone in a medium to large company want to use a pre-installed Windows that has to be manually configured on each box, when an unattended setup procedure is so much more convenient?
I have a DVB-S (digital satellite TV) receiver that runs Linux, and I must say it is a very nice box for the computer hobbyist, and probably still quite usable for the normal consumer.
Out of the box one can just use it as a receiver, but once you connect it to your LAN (ethernet) you can browse its contents using SMB (it runs SAMBA) or a web browser. You can edit its configuration files using "vi" over telnet, you can NFS-mount a disk on another system and record movies on it, plug in a USB memory key and backup your configuration, etc etc.
Not all are things that a consumer would want to do, but very nice to have.
I presume not all Linux-based consumer electronics boxes will be as open as this one, though.
What "we" have to avoid, I think, is to criticize manfacturers that use Linux and do not at the same time make the box open to access like described above. Especially bad is to "hack" into Linux-based devices beyond what one can be reasonably expected to do with something you own, and to blackmail manufacturers into releasing information and source code of proprietary parts.
Behaviour like that could quickly make the big manufacturers a lot less enthousiastic about using Linux.
In the case of hardware, for certain classes of hardware there is not much choice when one wants to use Linux. People are happy that even a single manufacturer wants to support Linux. The driver may be very complex and contain lots of proprietary code. E.g. a PCI ADSL card.
One can use these in a router, and may want to move on to a new kernel to have more advanced networking features.
In the case of Mozilla, the situation is even more complicated. One wants to install the new version of Mozilla to see if the IMAP code is improved, then finds that a plugin no longer works.
"Then don't upgrade" is often not practical.
I agree that it is sometimes required to improve an interface and that it is not always practical to keep compatability, but I think it is too often waved away with a simple "just recompile".
This happened with a couple of C library changes as well, and I think there is not only a C++ change in this case, because the compiler version change affects the kernel and loadable kernel modules as well. Maybe that is a different issue, as the kernel is written in C.
Open source advocates tend to ignore the fact that some parts of some people's systems are not open source. When I decide to buy a piece of hardware from a manufacturer who is the only one that supports Linux and supports it using a binary-only driver, I can decide to go with that solution. Then I don't like it when arbitrary changes to interfaces break the module, as the manufacturer may no longer be around or may no longer be supporting Linux.
Same for browser plugins.
So whenever possible it would be preferred when existing modules or plugins continue to work, maybe not with the functionality of newly written or recompiled ones.
Sure a balance always has to be found.
That would be nice, but there you also assume that whenever you make a change to the binary interface, providers of binary-only plugins will quickly line up to make their new plugin available.
When that method would have been used, you would just not be able to install the new Mozilla beta now, because dependencies that cannot be solved would exist.
Sure that prevents unfortunate mistakes, but it does not solve the underlying problem.
The problem is known. It does not need to be found through a beta.
What makes you think this will be fixed before the final version will be released? The bug reports seem to consider it a fact of life, not a problem somebody is actively working on.
This just demonstrates that the plugin interface is broken.
The problem of interfacing GCC 2.95 compiled code to GCC 3.x compiled code should be fixed, preferably once for all cases (it also affects kernel modules, for example) and if that is not possible it should be fixed inside Mozilla or in a "shim" plugin.
And while that is done, a new interface should be defined that does not depend on things like this, and the plugin coders should be motivated to move to that new interface.
Do you think the providers of binary-only plugins will be helping is for much longer when we lock them out at arbitrary moments and require them to spend work on building a new distribution package? As it is now, the percentage of plugins supported on Linux is already relatively small. Moves like this are certainly not going to make it better.
What if Real or Adobe decide that this is it and no GCC 3.x compilation of their product will be brought out? Will Mozilla step back to GCC 2.95, will they fix the problem, or will they just kill their browser product by saying "sorry guys, no more Acrobat PDF viewing!"???
When one has a great product and firmly believes another party has stolen intellectual property from it, why would anyone in their right mind let that great product impersonate as the competing and allegedly fraudulous one?
Wouldn't it be more appropriate if a UTP Ethernet be called "wired Ethernet"?
"Ethernet" by itself should be more than descriptive enough for a wireless network...
This thread is about a card.
There are other cards as well.
DVB is in wide use in Europe, mainly on satellite (DVB-S) but also on cable (DVB-C) and terrestrial (DVB-T).
I am not aware of any HDTV transmission in Europe, but it may well be that tests are going on.
>Now I finally get it -- you're looking for the magic header of DOS .exe files by examining its Base64-encoded representation.
That is how it works. When you examine a couple of messages that include an executable attachment you will see this pattern appear all the time.
>It's possible, though not likely, that the payload will slip through your filter if for some reason it was uuencoded
That can be handled by a similar pattern.
Of course it does not hurt to do both the extension matching and the content matching.
Remember that a program in Windows can register its own extensions and define them as executable code.
I have posted this answer a couple of times in other threads and on other forums, so maybe the surrounding explanation has been cut back too far after repeatedly giving this suggestion.
I am not discomforted by the moderation, I was just amazed.
What do you have in mind?
HDTV will not be transmitted in PAL (Analogue) but only in digital (DVB) standard.
Of course that is true, but not really a solution for the card I have now. It has a single VGA and a single TV-OUT. For this solution a card with two VGA outputs is required. I could not find one that also has TV-IN (they exist but not in the shops nearby).
With Linux it should be possible to generate the correct (or at least close enough) sync signals while in Xfree.
The external circuit will be required, yes. Also to generate the SCART switching voltages to enable RGB.
And then, it may be a short lived solution as I have found that many video products are switching from RGB to YPrPb, for a reason I still have to find out (maybe only to make existing RGB equipment unusable with new stuff?)