I have seen these stories about the IDE drives and have heard people saying that IBM isn't doing well with IBM drives, but I have expereinced that QA in general with IBM is crap. The other day we received a system direct from IBM, a rackmount server. The thing shipped with no hard drive. Additionally, an upgrade we ordered pre-installed came in a separate box. When calling to get the order fixed, the order number on the box was not listed in their database. Eventually they said the order number on the box was only a 'partial' order number, and the hard drive was shipped.
Three of the four CDs they shipped were cracked beyond usability, packing was horrible. IBM needs to get QA better before I'll considr them again for purchases.
And this helps you know what happens how? RPM doesn't provide perfect tracking either (packages can lie about what they do and be believed by the database), but it at least makes an effort to track what files were created on behalf of what package. Blindly compiling and installing packages to the default location does not offer enhanced security or better tracking by itself. Maybe if you take the time to manually review all the Makefiles and source, then yes, you are in better shape (and of course record all these changes somewhere). You can even use a program to timestamp everything and figure out what files changed in the intervals, but this isn't perfect either.
as soon as you type./configure, you give the package permission to execute whatever it wants. Though currently you can reasonably expect good things to happen, in a world with more malicious linux software, this could be very dangerous.
Of course, current package managers don't protect things sufficiently either, as they provide their own list of modified/new files. What the package *actually* installs/modifies does not necessarily coincide with what the package claims. A sort of enhancement I would like to see is a packgame managemant system in which packages are chrooted to a safe playground for all operations, and when it wishes to make changes/add new files to the real filesystem (presumably out of that playground), it would be *required* to do so only through a special commit facility provided by the package management utility. This commit facility could be configured for various levels of trust per app, from prompting on each operation to rejecting to allowing operations. Also, every operation is logged at a minimum of saying when and by what a file has been modified (keep a running history), to storing diffs between package modifications (good for, say,/etc files where changes are typically small and compress well).
Of course, as with anything, it couldn't protect against bypassing the mechanism (well, maybe with extensive kernel modifications, but probably not worth it), but for people currently relying on package management to keep their system consistent, this sort of infrastructure may be a good next step in the face of bad behaving packages.
Real is pretty crappy quality... As far as the player support goes, they have apparently decided to screw non-windows development, and cease to offer RealPlayer 8 from their page. Used to be the case that if you dug around enough, you could find the non-windows versions lying in the depths of their crappy website, but now it seems it has been cut off completely. I have the RealOne preview for Linux, and it looks like that will be the last...
Webmasters will get at least as much complaining as AOL, if not more so. I know a webmaster of a site who regularly gets flamed because the site they manage won't render correctly in AOL 3.0. When asked to at least upgrade to a more recent AOL client or even better, use Netscape, Mozilla, or IE, they get angry and insist AOL's client should be good enough. The truth is, long time users of any software package develop loyalty to that product, and will defend it even when it does act like crap. Of course, AOL users are also typically not that crazy about upgrading, what they have is fine to them, so who knows how much exposure to the fiercely defensive users this will get.
He isn't dumb, he pointed out that most AOL users don't bother to upgrade, why do you think he referenced the fact that most AOL hits he sees are 5.0, which is not the newest version?
As far as I can tell, DVD macrovision is by and large done by the playback device, and therefore depends on implementation. For example, my dxr2 has a register that has the effect of disabling or enabling macrovision. The linux drivers document this register (precisely what manufactuers don't want):)
Under windows this translates to an enable/disable macrovision checkbox in special apps...
As to whether a DVD can explictly request MacroVision or if it is always *supposed* to be on, I don't know. In any event it seems that the playback device can ignore any such request:)
Well in your comment about maintaining compatiblity you point out a very good example of MS embrace and extend, samba. Samba tries to mimick windows network services as best it can, but each release of Windows "happens" to break it somehow. Particularly the PDC code has been broken so many times while MS maintains classic compatibility. (Exploiting minor details of the PDC that were ignored before, for example). Their goal has historically been to screw over standards in the name of profit. Try to implement Active Directory with OpenLDAP and Kerberos. If MS stuck with the standards as you claim, this would be no problem, but, as we know, this is not feasible thanks to "improvements" on the standards by MS...
As far as performance, I agree that DB based filesystem on very large volumes may be better. I was debating the existance of file extensions. The filesystem itself I have no qualms with. I may use it or not, but I'll still keep filenames with associations. I use XFS and extended attributes, I have no problems with this.
Most are viable points, however, *display* on TV should always, in theory, be fine (though you can certainly tell the difference side-by-side, most of the time you can't tell independently. So the point about playing DVD on TV can be thrown out, computers are no worse, if not better than most standalone players (progressive-scan easier). So you refuse to buy MacroVision products? Have you bought any Paramount VHS tapes? A standalone DVD player? Those are MacroVision encoded. The point is to screw over VCRs, by sending signal spikes that would not be perceived by the human eyes but trick a VCR into reducing signal strength of normal content to compensate. On much older VCRs, which don't automatically adjust the signal, this makes no difference. Also, you can pick up devices to defeat MacroVision at Best-Buy that work perfectly. Pre-MacroVision would mean pre-PCI, this is not new technology. Fortunately, if you search the web enough you can probably figure out how to disable MacroVision for nearly any video chipset.
As an aside to your point, in most cases, MacroVision is typically only enable when the drivers detect that content is being displayed that "shouldn't" be copied, so game recording probably works. I think in most cases they go by process listing and display state, if you open an overlay in a different colorspace, macrovision enables, if realplay.exe, mplayer.exe, qtplayer.exe appears in process table, macrovision enables. This is one of the major reasons companies are reluctant to release open-source drivers for tv-out devices, as they all have modifiable registers for enabling/disabling macrovision, and open source drivers would probably get them it hot water with the MPAA/RIAA.
You left out the Open Source movement. Already to play most DVDs under linux you must install something like libdvdcss which is technically illegal by the DMCA. With the SSSCA, this would extend at the very least to any Open Source media player, and quite probably to Open Source platforms. In fact, any platform that doesn't license DRM technology from MS will then be illegal (making MS a legally endorsed monopoly, what a change in postition from suing them). Of course, maybe it would simply be that only MS-licensed products could read the format, but either way MS gets a lot of control.
So far under linux I have illegal dvd playback and even illegal font rendering (freetype w/ bytecode interpreter enabled). If SSSCA passes, there goes PythonTheater, noatun, xmms, etc....
It's not about making copying impossible, it is about raising the PITA factor so high so that for the vast majority of users it is easier just to buy the damn CD/DVD than to copy it. Same as the principle behind most copy protection on software. If you work hard enough, you can probably get it to work illegally, but trying to learn or figure out how is too much trouble to be worth saving the money. Product Activation is a good example of this. It is far from perfect, but for MS it strikes a good balance of making the platform harder to copy and usability.
Of course, so long as a small handful of the people on the internet can rip, the content will pop up. That is where these laws come in (DMCA, SSSCA). Anyone who would dare violate the RIAA/MPAA's precious pet laws and distribute material on the internet can get sued into poverty. Also, it can be used to scare consumers away from the free alternative.
Software makers by and large have dealt with perfect copying a lot longer than the MPAA/RIAA and haven't gotten any huge breaks from the government similar to the SSSCA, and they are not all bankrupt. In any event, I have no plans to upgrade to any SSSCA-endorsed device in the future. I *might* have not worried about it if they had simply released the technology, but trying to buy a federal law to force me to do so pisses me off. The DMCA, UCITA, and SSSCA really need to go away. With all these laws in place you could kiss open source multimedia software goodbye in the US.... Hell, by the SSSCA Linux, FreeBSD, Solaris, MacOS would all become illegal unless distributers purchase licenses from MS (legally endorsed monopoly by the SSSCA thanks to DRM patents), and even then source could never be disclosed...
I would say that, unfortunately, those who say migrating from MS is impractical are probably right for most organizations. Users are used to Windows, and that is the simple truth. For workstations/desktops, the benefits of a 'better' os are insufficient to justify switches in most cases (unless upgrading, then cost can be a factor...)
For servers where you need fewer people retrained and availability/performance are important, that is when it is worth some time to get things right....
As far as studies showing that other platforms may be easier to learn, they very well may be right. However, anyone claiming it would be easier for someone to transistion to a new OS rather than continuing to use their familiar OS is an idiot.
Yes, that is enabled, all part of the trying to protect users from themselves. The icon in theory should be enough of a visual cue to a user without an extension listed. However, the true test is how this data is treated in areas such as the file-type editor, where the file-types must be presented in a sorted list. In 98, it is sorted by Description, showing that yes, MS has been keen to move away from extensions because they seem ugly to the user. However, in XP, it is sorted by extension, showing that they realize the user is most likely to know and want to search by extension, and since you can't sort by icon and icons are generic, extensions are shown to be the preferred style.
As far as hiding the virus through a likely hidden extension, shouldn't you notice that a) the icon is horribly wrong (huge visual cue) and that b) the.txt is showing when it shouldn't? In any case having executable status by extension is a dumb idea, that does belong outside the file entirely, no file should be able to tell the operating system it should be executable.
I have not seen a single solid argument against extensions that makes screwing everything we have over worth it. Sure it seems ugly, but in practice there isn't anything horribly wrong with it that will be fixed by using metadata, and there are plenty of ways to have the extensions around but out of view of users for the most part (the hide extensions option in Windows, for example.)
Getting rid of extensions is not necessarily a good thing...
First off, all kinds of things are already designed around the extension idea, redesigning everything won't work that easily. Also, users are used to the concept of extensions. MS is very much aware of this. If you take, say, Windows 98 and go to edit file type associations, the list is sorted by type description. This doesn't work, as the user is not likely to know the string attributed to the file type he is thinking of. For example, recently my fiancee wanted to change the default viewer for.avi files. Of course she checked a and then w and then mi* area and no guesses were right. The right answer was "Movie Clip" (way to generic, but anyway...) Now look at the same dialog under, say XP. You will see that things are sorted by extension. While it may seem clunky and inelegant conceptually, in practice it is elegant. I would say identifying type is important enough to belong in the filename.
Secondly, these extended attributes are not portable. Many widely used protocols would be unable to automatically notify client machine of this information, forcing the user on every file downloaded to set the type of the file manually. Sure you can embed them directly in the file, but who gets to dictate the format? I can bet you that MS would extend any standard to break compatibility with other systems if it existed. By tying in the reading of these extended attributes more tightly with the opening of files, you are inviting MS to come and make life harder on non-MS platforms, as well as technologies such as DRM to have more success...
Finally, what about performance? As it stands, a system based on/etc/magic would be prohibitively slow. If you suddenly designate a part of the file space as needing to contain type information, tons of legacy problems can arise, and that field better be pretty long, and have a standard organization dictating what gets to use what codes. You can keep the information out of the file and efficient through Extended Attributes (already possible with NTFS, XFS, Be's FS, among others), but as I mentioned before this would not work cross-platform.
The system as it stands now works quite well. Windows explorer already works to "protect the user from himself" by not allowing renaming of extension on a file easily. We have an established, cross-platform standard for identifying file types, we don't need to blow that...
From sourcecode, in the file include/freetype/config/ftoption.h, there is a line that says #undef TT_CONFIG_OPTION_BYTECODE_INTERPRETER change that to #define and recompile and install freetype, now you have a much nicer, if not patent infringing font engine for X to work with...
Of course, that was simply disabling hinting, which is nothing new, it is a freetype option, the better, but illegal way is to enable the proper bytecode interpreter of freetype, that does 'proper' hinting, but infringes on a patent...
Between that modification and MS fonts, my desktop looks much better now:) Sawfish, gnome-panel and ROX look great with GTK2:)
Movie theater screens are 16:9 ratio, they didn't just draw a new ratio out of thin air, they wanted the TV to more closely match the movie standard.
Now if they take a version that was pan and scanned to 4:3 and then modify it again to 16:9 without the original, then it is messed up.
Letterboxing in general means to present 16:9 aspect ration in an assumed 4:3 screen geometry. When the actual screen is 16:9, then you get horrible horizontal strecthing. Switching TV to show 4:3 corrects ratio, but it means you have big black areas above, beneath, and on either side, when you could get proper aspect by simply filling the screen.
While not exactly what you describe, I have some experience with a "Smart Board" that really is a rear-projection screen that accepts touch input as a pointer device. You have to calibrate the sucker just right, but then the resolution depends on your projector, and there are plenty of quality projectors out there. I think it also had fake markers and an eraser (the fake markers just provided intuitive way of indicating color, didn't even have a real tip on the screen, for good reason, this is never meant to operate without a computer display on it.
There coulde be a number of things. For professional software, companies like MS realize that winning over students is important as they make future decisions/recommendations. So through things like StudentDev and MSDNAA they get software to students at nothing to next-to-nothing prices. They realize the exploitable profit margins are slim, a student lacks money and will make due with what they can get, i.e. research cheaper alternatives or do it themselves, and when they go out into the workforce, they can recommend these cheaper alternatives to their business.
Of course, a huge part of piracy is game software. And lately the trend is for games to be massively multiplayer, and have to connect to central servers controlled by companies to play with other strangers. Part of the connection negotiation now typically includes the CD-Key, and if people try to share keys or generate keys that may be duplicate, they get shut out. While it may be possible to *eventually* cheat enough to get a CD-Key that is both valid and not duplicated, it is much more trouble than just buying the damn thing.
MS realizes this is the only way to prevent piracy, so they have to maintain a CD-Key to hardware hash database and use it to lock people out. Sure, you can generate CD-Keys all day long for professional and probably slip through WPA eventually, but there is a good chance that down the road someone else will be screwed over by doing that, when they try to activate. The only way is to disable WPA, and that isn't uncommon, since WPA offers no features. This strategy works extremely well for games, as the online verification is tightly tied to an important component of the games functionality that people don't want to give up.
I don't think any of this has to do with ClearType really. I think people are motivated by seeing how nice fonts look on other systems (including ClearType, but also Mac, and what Be had, etc...) The bits that make ClearType above and beyond typical anti-aliasing are actually in the Xrender extension used by the AA font system, and that is subpixel operations (i.e. taking advantage of order of red, green, and blue elements in an LCD screen to effectivvely triple horizontal resolution). The key things needed are a) well-hinted fonts and b) good strategy for understanding and following those hints. a is easy to solve by downloading, say, MSs fontset. A more proper solution will eventually happen, but for now it works. b has caused some problems, as this little thing shows. The "auto-hinting" functionality where FreeType tries to guess the hints without actually interpreting them causes fonts to look worse than better, and in the end we are better off with no hinting than auto-hinting. The "proper" solution to hinting is in FreeType, a bytecode interpreter for the hints. The problem here is it is not a default because doing so would make Apple (who has a patent on reading and using those hints) angry. I posted already in this forum the "right" way of disabling hinting in freetype or enabling the better, but illegal bytecode interpreter....
A lot of the growing pains has more to do with Apple than it does with MS.... AA fonts look nice, even if they bring next to nothing to the table in terms of utility and usability, and I don't think the development needs the prodding of MS to seek out better eye-candy. If anything, MS is pushing more eye-candy (XP) because of prodding from Apple and X based eye-candy...
You got it right, I should flag someone down and have them notice, it is a simple change to the DETAILS file, the problem is, I can't find anywhere that makes it clear who to submit updates to the grimoire to....
If you want to accomplish something similar, before compiling freetye, look at line 435 of include/freetype/config/ftoption.h in the source distribution before compiling. That disables the hinter. I'm not if this is as effective as what the guy did to the Xft library. I don't have the orginal source files at the moment, so I can't tell exactly what he changed. I also can use his libXft.
Another option is to realize that the hint guessing that freetype does to avoid patent infringement problems by default can be changed to use a bytecode interpreter that does proper hinting of TrueType fonts, Change line 378 of the above mentioned file for this to occur. I still don't understand how making the code "optional" makes it any less patent infringing..
Of course, no matter how you configure freetype, it will still look like crap without good fonts. http://www.linuxquebec.com/~nomis80/ has a script to automate installation of Microsoft true type fonts.
Of course by enabling the bytecode interpreter and *possibly* by getting MS fonts without a MS OS, you may be doing illegal stuff, but if pretty fonts under X is outlawed, then only outlaws will have pretty fonts under X, or something like that....
Disabling hinting with the default fonts is probably the most legal way to go, but what is the fun in that?
Are the rpms you provide simply the result of changing line 378 of include/freetype2/config/ftoption.h, to #define TT_CONFIG_OPTION_BYETCODE_INTERPRETER?
My distribution happens to do that by default:) Some fonts still look really ugly, but better than that auto-hinting crap.
Slashdot Mirror
I have seen these stories about the IDE drives and have heard people saying that IBM isn't doing well with IBM drives, but I have expereinced that QA in general with IBM is crap. The other day we received a system direct from IBM, a rackmount server. The thing shipped with no hard drive. Additionally, an upgrade we ordered pre-installed came in a separate box. When calling to get the order fixed, the order number on the box was not listed in their database. Eventually they said the order number on the box was only a 'partial' order number, and the hard drive was shipped.
Three of the four CDs they shipped were cracked beyond usability, packing was horrible. IBM needs to get QA better before I'll considr them again for purchases.
And this helps you know what happens how? RPM doesn't provide perfect tracking either (packages can lie about what they do and be believed by the database), but it at least makes an effort to track what files were created on behalf of what package. Blindly compiling and installing packages to the default location does not offer enhanced security or better tracking by itself. Maybe if you take the time to manually review all the Makefiles and source, then yes, you are in better shape (and of course record all these changes somewhere). You can even use a program to timestamp everything and figure out what files changed in the intervals, but this isn't perfect either.
./configure, you give the package permission to execute whatever it wants. Though currently you can reasonably expect good things to happen, in a world with more malicious linux software, this could be very dangerous.
as soon as you type
Of course, current package managers don't protect things sufficiently either, as they provide their own list of modified/new files. What the package *actually* installs/modifies does not necessarily coincide with what the package claims. A sort of enhancement I would like to see is a packgame managemant system in which packages are chrooted to a safe playground for all operations, and when it wishes to make changes/add new files to the real filesystem (presumably out of that playground), it would be *required* to do so only through a special commit facility provided by the package management utility. This commit facility could be configured for various levels of trust per app, from prompting on each operation to rejecting to allowing operations. Also, every operation is logged at a minimum of saying when and by what a file has been modified (keep a running history), to storing diffs between package modifications (good for, say, /etc files where changes are typically small and compress well).
Of course, as with anything, it couldn't protect against bypassing the mechanism (well, maybe with extensive kernel modifications, but probably not worth it), but for people currently relying on package management to keep their system consistent, this sort of infrastructure may be a good next step in the face of bad behaving packages.
Real is pretty crappy quality... As far as the player support goes, they have apparently decided to screw non-windows development, and cease to offer RealPlayer 8 from their page. Used to be the case that if you dug around enough, you could find the non-windows versions lying in the depths of their crappy website, but now it seems it has been cut off completely. I have the RealOne preview for Linux, and it looks like that will be the last...
Webmasters will get at least as much complaining as AOL, if not more so. I know a webmaster of a site who regularly gets flamed because the site they manage won't render correctly in AOL 3.0. When asked to at least upgrade to a more recent AOL client or even better, use Netscape, Mozilla, or IE, they get angry and insist AOL's client should be good enough. The truth is, long time users of any software package develop loyalty to that product, and will defend it even when it does act like crap. Of course, AOL users are also typically not that crazy about upgrading, what they have is fine to them, so who knows how much exposure to the fiercely defensive users this will get.
He isn't dumb, he pointed out that most AOL users don't bother to upgrade, why do you think he referenced the fact that most AOL hits he sees are 5.0, which is not the newest version?
On VHS tapes, it is on the tapes....
:)
:)
As far as I can tell, DVD macrovision is by and large done by the playback device, and therefore depends on implementation. For example, my dxr2 has a register that has the effect of disabling or enabling macrovision. The linux drivers document this register (precisely what manufactuers don't want)
Under windows this translates to an enable/disable macrovision checkbox in special apps...
As to whether a DVD can explictly request MacroVision or if it is always *supposed* to be on, I don't know. In any event it seems that the playback device can ignore any such request
Well in your comment about maintaining compatiblity you point out a very good example of MS embrace and extend, samba. Samba tries to mimick windows network services as best it can, but each release of Windows "happens" to break it somehow. Particularly the PDC code has been broken so many times while MS maintains classic compatibility. (Exploiting minor details of the PDC that were ignored before, for example). Their goal has historically been to screw over standards in the name of profit. Try to implement Active Directory with OpenLDAP and Kerberos. If MS stuck with the standards as you claim, this would be no problem, but, as we know, this is not feasible thanks to "improvements" on the standards by MS...
As far as performance, I agree that DB based filesystem on very large volumes may be better. I was debating the existance of file extensions. The filesystem itself I have no qualms with. I may use it or not, but I'll still keep filenames with associations. I use XFS and extended attributes, I have no problems with this.
Most are viable points, however, *display* on TV should always, in theory, be fine (though you can certainly tell the difference side-by-side, most of the time you can't tell independently. So the point about playing DVD on TV can be thrown out, computers are no worse, if not better than most standalone players (progressive-scan easier). So you refuse to buy MacroVision products? Have you bought any Paramount VHS tapes? A standalone DVD player? Those are MacroVision encoded. The point is to screw over VCRs, by sending signal spikes that would not be perceived by the human eyes but trick a VCR into reducing signal strength of normal content to compensate. On much older VCRs, which don't automatically adjust the signal, this makes no difference. Also, you can pick up devices to defeat MacroVision at Best-Buy that work perfectly. Pre-MacroVision would mean pre-PCI, this is not new technology. Fortunately, if you search the web enough you can probably figure out how to disable MacroVision for nearly any video chipset.
As an aside to your point, in most cases, MacroVision is typically only enable when the drivers detect that content is being displayed that "shouldn't" be copied, so game recording probably works. I think in most cases they go by process listing and display state, if you open an overlay in a different colorspace, macrovision enables, if realplay.exe, mplayer.exe, qtplayer.exe appears in process table, macrovision enables. This is one of the major reasons companies are reluctant to release open-source drivers for tv-out devices, as they all have modifiable registers for enabling/disabling macrovision, and open source drivers would probably get them it hot water with the MPAA/RIAA.
You left out the Open Source movement. Already to play most DVDs under linux you must install something like libdvdcss which is technically illegal by the DMCA. With the SSSCA, this would extend at the very least to any Open Source media player, and quite probably to Open Source platforms. In fact, any platform that doesn't license DRM technology from MS will then be illegal (making MS a legally endorsed monopoly, what a change in postition from suing them). Of course, maybe it would simply be that only MS-licensed products could read the format, but either way MS gets a lot of control.
So far under linux I have illegal dvd playback and even illegal font rendering (freetype w/ bytecode interpreter enabled). If SSSCA passes, there goes PythonTheater, noatun, xmms, etc....
It's not about making copying impossible, it is about raising the PITA factor so high so that for the vast majority of users it is easier just to buy the damn CD/DVD than to copy it. Same as the principle behind most copy protection on software. If you work hard enough, you can probably get it to work illegally, but trying to learn or figure out how is too much trouble to be worth saving the money. Product Activation is a good example of this. It is far from perfect, but for MS it strikes a good balance of making the platform harder to copy and usability.
Of course, so long as a small handful of the people on the internet can rip, the content will pop up. That is where these laws come in (DMCA, SSSCA). Anyone who would dare violate the RIAA/MPAA's precious pet laws and distribute material on the internet can get sued into poverty. Also, it can be used to scare consumers away from the free alternative.
Software makers by and large have dealt with perfect copying a lot longer than the MPAA/RIAA and haven't gotten any huge breaks from the government similar to the SSSCA, and they are not all bankrupt. In any event, I have no plans to upgrade to any SSSCA-endorsed device in the future. I *might* have not worried about it if they had simply released the technology, but trying to buy a federal law to force me to do so pisses me off. The DMCA, UCITA, and SSSCA really need to go away. With all these laws in place you could kiss open source multimedia software goodbye in the US.... Hell, by the SSSCA Linux, FreeBSD, Solaris, MacOS would all become illegal unless distributers purchase licenses from MS (legally endorsed monopoly by the SSSCA thanks to DRM patents), and even then source could never be disclosed...
I would say that, unfortunately, those who say migrating from MS is impractical are probably right for most organizations. Users are used to Windows, and that is the simple truth. For workstations/desktops, the benefits of a 'better' os are insufficient to justify switches in most cases (unless upgrading, then cost can be a factor...)
For servers where you need fewer people retrained and availability/performance are important, that is when it is worth some time to get things right....
As far as studies showing that other platforms may be easier to learn, they very well may be right. However, anyone claiming it would be easier for someone to transistion to a new OS rather than continuing to use their familiar OS is an idiot.
Yes, that is enabled, all part of the trying to protect users from themselves. The icon in theory should be enough of a visual cue to a user without an extension listed. However, the true test is how this data is treated in areas such as the file-type editor, where the file-types must be presented in a sorted list. In 98, it is sorted by Description, showing that yes, MS has been keen to move away from extensions because they seem ugly to the user. However, in XP, it is sorted by extension, showing that they realize the user is most likely to know and want to search by extension, and since you can't sort by icon and icons are generic, extensions are shown to be the preferred style.
.txt is showing when it shouldn't? In any case having executable status by extension is a dumb idea, that does belong outside the file entirely, no file should be able to tell the operating system it should be executable.
As far as hiding the virus through a likely hidden extension, shouldn't you notice that a) the icon is horribly wrong (huge visual cue) and that b) the
I have not seen a single solid argument against extensions that makes screwing everything we have over worth it. Sure it seems ugly, but in practice there isn't anything horribly wrong with it that will be fixed by using metadata, and there are plenty of ways to have the extensions around but out of view of users for the most part (the hide extensions option in Windows, for example.)
Getting rid of extensions is not necessarily a good thing...
.avi files. Of course she checked a and then w and then mi* area and no guesses were right. The right answer was "Movie Clip" (way to generic, but anyway...) Now look at the same dialog under, say XP. You will see that things are sorted by extension. While it may seem clunky and inelegant conceptually, in practice it is elegant. I would say identifying type is important enough to belong in the filename.
/etc/magic would be prohibitively slow. If you suddenly designate a part of the file space as needing to contain type information, tons of legacy problems can arise, and that field better be pretty long, and have a standard organization dictating what gets to use what codes. You can keep the information out of the file and efficient through Extended Attributes (already possible with NTFS, XFS, Be's FS, among others), but as I mentioned before this would not work cross-platform.
First off, all kinds of things are already designed around the extension idea, redesigning everything won't work that easily. Also, users are used to the concept of extensions. MS is very much aware of this. If you take, say, Windows 98 and go to edit file type associations, the list is sorted by type description. This doesn't work, as the user is not likely to know the string attributed to the file type he is thinking of. For example, recently my fiancee wanted to change the default viewer for
Secondly, these extended attributes are not portable. Many widely used protocols would be unable to automatically notify client machine of this information, forcing the user on every file downloaded to set the type of the file manually. Sure you can embed them directly in the file, but who gets to dictate the format? I can bet you that MS would extend any standard to break compatibility with other systems if it existed. By tying in the reading of these extended attributes more tightly with the opening of files, you are inviting MS to come and make life harder on non-MS platforms, as well as technologies such as DRM to have more success...
Finally, what about performance? As it stands, a system based on
The system as it stands now works quite well. Windows explorer already works to "protect the user from himself" by not allowing renaming of extension on a file easily. We have an established, cross-platform standard for identifying file types, we don't need to blow that...
From sourcecode, in the file include/freetype/config/ftoption.h, there is a line that says
#undef TT_CONFIG_OPTION_BYTECODE_INTERPRETER
change that to #define and recompile and install freetype, now you have a much nicer, if not patent infringing font engine for X to work with...
Of course, that was simply disabling hinting, which is nothing new, it is a freetype option, the better, but illegal way is to enable the proper bytecode interpreter of freetype, that does 'proper' hinting, but infringes on a patent...
:) Sawfish, gnome-panel and ROX look great with GTK2 :)
Between that modification and MS fonts, my desktop looks much better now
Movie theater screens are 16:9 ratio, they didn't just draw a new ratio out of thin air, they wanted the TV to more closely match the movie standard.
Now if they take a version that was pan and scanned to 4:3 and then modify it again to 16:9 without the original, then it is messed up.
Letterboxing in general means to present 16:9 aspect ration in an assumed 4:3 screen geometry. When the actual screen is 16:9, then you get horrible horizontal strecthing. Switching TV to show 4:3 corrects ratio, but it means you have big black areas above, beneath, and on either side, when you could get proper aspect by simply filling the screen.
While not exactly what you describe, I have some experience with a "Smart Board" that really is a rear-projection screen that accepts touch input as a pointer device. You have to calibrate the sucker just right, but then the resolution depends on your projector, and there are plenty of quality projectors out there. I think it also had fake markers and an eraser (the fake markers just provided intuitive way of indicating color, didn't even have a real tip on the screen, for good reason, this is never meant to operate without a computer display on it.
There coulde be a number of things. For professional software, companies like MS realize that winning over students is important as they make future decisions/recommendations. So through things like StudentDev and MSDNAA they get software to students at nothing to next-to-nothing prices. They realize the exploitable profit margins are slim, a student lacks money and will make due with what they can get, i.e. research cheaper alternatives or do it themselves, and when they go out into the workforce, they can recommend these cheaper alternatives to their business.
Of course, a huge part of piracy is game software. And lately the trend is for games to be massively multiplayer, and have to connect to central servers controlled by companies to play with other strangers. Part of the connection negotiation now typically includes the CD-Key, and if people try to share keys or generate keys that may be duplicate, they get shut out. While it may be possible to *eventually* cheat enough to get a CD-Key that is both valid and not duplicated, it is much more trouble than just buying the damn thing.
MS realizes this is the only way to prevent piracy, so they have to maintain a CD-Key to hardware hash database and use it to lock people out. Sure, you can generate CD-Keys all day long for professional and probably slip through WPA eventually, but there is a good chance that down the road someone else will be screwed over by doing that, when they try to activate. The only way is to disable WPA, and that isn't uncommon, since WPA offers no features. This strategy works extremely well for games, as the online verification is tightly tied to an important component of the games functionality that people don't want to give up.
I don't think any of this has to do with ClearType really. I think people are motivated by seeing how nice fonts look on other systems (including ClearType, but also Mac, and what Be had, etc...)
The bits that make ClearType above and beyond typical anti-aliasing are actually in the Xrender extension used by the AA font system, and that is subpixel operations (i.e. taking advantage of order of red, green, and blue elements in an LCD screen to effectivvely triple horizontal resolution). The key things needed are a) well-hinted fonts and b) good strategy for understanding and following those hints. a is easy to solve by downloading, say, MSs fontset. A more proper solution will eventually happen, but for now it works. b has caused some problems, as this little thing shows. The "auto-hinting" functionality where FreeType tries to guess the hints without actually interpreting them causes fonts to look worse than better, and in the end we are better off with no hinting than auto-hinting. The "proper" solution to hinting is in FreeType, a bytecode interpreter for the hints. The problem here is it is not a default because doing so would make Apple (who has a patent on reading and using those hints) angry. I posted already in this forum the "right" way of disabling hinting in freetype or enabling the better, but illegal bytecode interpreter....
A lot of the growing pains has more to do with Apple than it does with MS.... AA fonts look nice, even if they bring next to nothing to the table in terms of utility and usability, and I don't think the development needs the prodding of MS to seek out better eye-candy. If anything, MS is pushing more eye-candy (XP) because of prodding from Apple and X based eye-candy...
that you take your glasses *off* to anti-alias fonts? :)
Which problem?
You got it right, I should flag someone down and have them notice, it is a simple change to the DETAILS file, the problem is, I can't find anywhere that makes it clear who to submit updates to the grimoire to....
If you want to accomplish something similar, before compiling freetye, look at line 435 of include/freetype/config/ftoption.h in the source distribution before compiling. That disables the hinter. I'm not if this is as effective as what the guy did to the Xft library. I don't have the orginal source files at the moment, so I can't tell exactly what he changed. I also can use his libXft.
Another option is to realize that the hint guessing that freetype does to avoid patent infringement problems by default can be changed to use a bytecode interpreter that does proper hinting of TrueType fonts, Change line 378 of the above mentioned file for this to occur. I still don't understand how making the code "optional" makes it any less patent infringing..
Of course, no matter how you configure freetype, it will still look like crap without good fonts.
http://www.linuxquebec.com/~nomis80/ has a script to automate installation of Microsoft true type fonts.
Of course by enabling the bytecode interpreter and *possibly* by getting MS fonts without a MS OS, you may be doing illegal stuff, but if pretty fonts under X is outlawed, then only outlaws will have pretty fonts under X, or something like that....
Disabling hinting with the default fonts is probably the most legal way to go, but what is the fun in that?
Are the rpms you provide simply the result of changing line 378 of include/freetype2/config/ftoption.h, to #define TT_CONFIG_OPTION_BYETCODE_INTERPRETER?
:) Some fonts still look really ugly, but better than that auto-hinting crap.
My distribution happens to do that by default