You want to know why there is no "innovation?" It's because of comments like these that happen when anybody tries the tiniest "innovation" of the user interface. This is a literal reply to one of my posts to slashdot where I made a tiny suggestion on how to improve pop-up menus:
Sure, you couldn't do any of those things, but why would you want to? There are indeed ways to get the mouse pointer to pre-point at the default choices: you install a program on the computer. Logitech's MouseWorks does this, IIRC. You, on the other hand, advocate ONE application to behave inconsistently with every other. That's not innovation. That is pissing off me, the user. If I want the button to do that I'll install the software that will facilitate it system-wide,damnit. I don't want one single application to think it's cool.
Furthermore, this does not hinder interface innovation. The innovations will come in future OS revisions, which is when users expect that things will be different. You don't go changing the way Windows works until the next version of Windows comes out.
I know I sound bitchy and cranky, but this is how I get when people try to be Jakob Neilsen [uesit.com] when they obviously aren't. A general rule about interfaces: if you don't know what your talking about, don't mess with them.
And there you have it. We are not allowed to "innovate", that is actually something that only "experts" (paid professionals?) are allowed to do. As long as this mentality remains, there will be no innovation no matter how much the programmers want to do it.
Yes, it is exactly like X and a crash in the rendering brings the whole system down. Since X is more the level of the Win32 GDI however this is not quite as likely as a bug in html rendering.
Now back to the original argument. The speed of IE verses Mozilla. You should now compare the speed of starting Konquerer on an already-running KDE desktop with the speed of starting X and Mozilla, if you want the same type of comparison as being spouted about IE versus Mozilla.
Now there is nothing wrong with putting html rendering in the system, or as a service. In fact it is a HUGE win because it makes programs needing html rendering FASTER! But this is the reason IE is faster and every IE defender here seems to be trying to claim that that is not the reason, instead of logically saying that perhaps MicroSoft's design is better?
Oh come on. There is another "initialization" that is run the first time the DLL is loaded. It is well documented. It does not create a process, but the DLL is occupying memory and large amounts of data structures have been initialized and are reused by every instance. This represents a significant amount of startup time.
It is also a very good idea and I am flabbergasted that people will deny a feature of Windows just to win the "IE is faster" argument.
Believe me, I'm on your side in this argument. But in fact you don't "know how to fix the bug" in Outlook, because you don't have the source. What I am saying is for people who have access to the source (ie users inside MicroSoft for Outlook, and users everywhere for Open-Source software) the results are about the same: only a person who knows how to fix the bug fixes it, people telling others about the bug rarely results in anything happening.
Same thing for the added features. Here I see paying somebody actually works, if you pay somebody to add a feature, it gets done.
I think the reason is that the knowledge that a feature could work involves less work than implementing the feature. That is not true of bug fixes, as it takes more effort to explain the bug and how to fix it than to fix it yourself, and saying "find and fix this" is usually noneffective because it usually means it cannot be fixed. Knowing it can be fixed requires almost all the knowledge needed to fix it, so by the time you know that paying somebody is cost-effective you can fix it yourself.
Some people were born on these company lots and had no choice other than to work for it. Leaving the company was about as practical as swimming to another country is. Also many people "outside" had the choice of working for the company or starving. I fail to see much difference between that and a country. You might say that they "chose" to work for the company because it was better than starving, but even living in Communist Russia under Stalin was probably preferrable to living on the Artic ice and starving.
It is true that the companies employed the government to crack down on worker revolts. This would be a good argument to make: if there was not a government with a military willing to obey the company and funded by taxing many people (and thus having a larger source of funds than the company has access to) perhaps they could not crack down on the worker's revolt. It is possible that trying to fund a military of their own would not be cost-effective for the company.
What do you think of turn-of-the-century mining towns where the company owned all the land that all the houses were on and paid everybody with company scrip? I guess I still don't see the difference. Outlawing such companies requires a government to outlaw them, and then that government probably has the power to outlaw other things.
"Fixing" may be the wrong term here. As far as I can tell, "fixing" is the same in Open Source and closed source, despite any claims to the contrary on either side.
In open source if somebody notices a bug, they either don't know how to fix it, so they ignore it or they post a notice to the bug traq or mailing list and it is ignored there (anybody claiming they are not ignored is challenged to find one that was really fixed due to the bug report rather than claimed "we know about that and are working on it"). Or the *do* know how to fix it, so they fix it. They might, just maybe, try to tell another person how to fix it, but by the time they are finished it is so frustrating (because they know the answer) that they say "screw it, I'll fix it".
In closed source if somebody notices a bug, they either don't know how to fix it, so they ignore it or they post a notice to the bug database and it is ignored there (anybody claiming they are not ignored is challenged to find one that was really fixed due to the bug report rather than claimed "we know about that and are working on it"). Or the *do* know how to fix it, so they fix it. They might, just maybe, try to tell another person how to fix it, but by the time they are finished it is so frustrating (because they know the answer) that they say "screw it, I'll fix it".
So "Fixing" is the wrong term. However it is true that "adding features" is different in closed source. It is possible to hire somebody to add a feature, and this is done all the time. Features are treated like bugs in Open Source. You can make an argument that this is good because it avoids bloat, but that is about the only argument for it.
As I pointed out in another post, the DLL's are ALREADY "initialized". They are not just shared libraries, but also Windows method of making modules/daemons.
A single DLL has a single SHARED piece of memory and an init that is called the FIRST time it is loaded (not the first time it is loaded by an application). I think it can even launch a thread and have an event loop.
Therefore the IE DLL's are already "loaded and initialized".
Goddamn, it's not even a bad idea, and you Windows defenders will ignore it in order to try to make your stupid point.
Also that's why a rendering bug brings down the entire desktop rather than just IE.
DLL's are both *services* (or daemons in Unix terms) and shared libraries. They are *already* "started". The comparison is like comparing running "cat" on Linux with loading all the disk drivers and mounting all the disks and then running "cat".
It is pretty pathetic that the Window's defenders don't even know how their system works.
Unfortunatly your goals would prevent any innovation in GUI design. That is the problem with toolkits. For instance you cannot use the Windows API to make a pop-up menu that pops up with the cursor pre-pointing at an item. Therefore you cannot use it to make a Motif/Mac style choice (oh, I'm sorry, a "combo box"...), You cannot put buttons into the menu bar. These are all simple things but they are primitive stupid mistakes from 1985 or earlier and we are still living with them because of the inability to modify the toolkit without breaking the programs that use it.
Now it may be possible if, instead of "widgets", people would come up with some "drawing" code. Some elements are pretty consistent: "draw a raised box", "draw a raised box I can press", "draw it pressed", etc. Then maybe systems could use it, most toolkits have calls like this inside them. Then again, even at this level I worry about a complexity and forced design, for instance the obvious implementations would not let you make non-square widgets, while a non-square one would be complex and could be rightly claimed to be too much overhead.
Also NONE of this has anything to do with enforcing consistent shortcuts between applications. From a programming point of view it is impossible. Imagine that they said Ctrl+C will ALWAYS do "cut". Then they say you must write a program with the function cut() and Ctrl+C will call that and you cannot do anything about it. That is what enforcing a consistent set of shortcuts means (Ignore the fact that you could make cut() do anything you wanted, I'm not assumming malicious programmers here). Imagine now you make up a new function, blorg, and you want Ctrl+E to call it. They know nothing about blorg so they cannot possibly call it. Okay, perhaps there is an interface that says "make Ctrl+E call blorg()". Great but what happens when they decide that Ctrl+E means a new standard (say go-to-end-of-line). Does your program stop working in that Ctrl+E stops calling blorg()? What if you relied on this fact? Or does Ctrl+E still call blorg()? Then you have an inconsistent user interface!
The fact is that ALL systems allow the shortcuts to be arbitrarily arranged. The fact is that programs, especially on Windows, are consistent is because the programmers have an incentive to make them consistent. This incentive is always ignored by the people who keep yelling for "single toolkit".
I think that will only be true for a short time. As soon as cracked programs come out that work when this is turned off there will be a government/DMCA requirement that it be always on.
Actually I'm pretty sure a car is copyrighted, or at least a lot of parts of it are. If you had your own machine shop and machined an exact copy, including the logos and various shapes of manifolds and whatever else the car company considers IP, and then sold it (ignoring the fact that it is impossible to do this at the same price the original car sells for) I think you would be in trouble.
So the copyright has nothing to do with your ability to modify the car.
Yea, only illegal products are banned. That's just great. You know that laws can change and legal products can become illegal, right?
DeCSS was legal at one time.
Re:Two powerful commands on the OS X command line
on
More Switching Stories
·
· Score: 3, Informative
Actualy the usual use of the command is "open filename". It performs the same action as double-clicking the file. I think the -a switch forces the file to be opened using a given program rather than the default? Not sure what it means when you provide -a but no filename, probably it runs the appliation as though you double-clicked it, but you could also achieve this by "open blah.app" where blah.app is the.app directory containing the MicroSoft Word or whatever you want.
I hightly recommend that the KDE/Gnome guys get together and make a Linux "open" command, so we don't have to parse all their files just to figure out what a double-clicked file means. Even Windows does this (they call it "start") but for some reason the Linux guys, despite such familiarity with the command line, have not come up with this.
There is a stupid problem on Apple which is why you cannot just type the name of the program. All clickable applications are in ".app" directories, with the exectuable and support files all in one directory. This is a good idea but the implementation sucks:
First of all, if there are no support files they should allow a single exectuable rather than a.app directory, this is how Windows and KDE/Gnome handle files, on OS/X a compiled executable cannot be double-clicked from the finder, which is stupid. It also makes it a pain to write portable programs that can be run from the command line.
Second they should get rid of the ".app" suffix so that they don't have to special-case a "hide suffix" operation in the finder. If you rename any directory.app it screws up, this is probably a bad idea. They should also fix it so that exec can run these, right now to run such a command from the shell you have to type command.app/command to run the executable inside it. Again, pretty stoopid.
You realize that your HDTV screen will not show anything other than 480i after they introduce the new encrypted digital broadcast. The converter box analog outputs will ONLY be 480i. Enjoy your HDTV picture while you can, and I hope you liked spending your money.
You will have to get a new walkman that will play the new downloaded streams, and if you think it is going to play those an unlimited number of times you are seriously deluded.
There will be new machines that will play "old" CD's, but they will not play anything other than CD's and encrypted music files. Such a device can certainly determine that the data it is playing is coming off it's own laser, so you will at least have to burn a CD to get your music to play. But your new computer will not run the music-burning software! So you can use your old one, I guess. But the player may very well be able to detect writable CD's and refuse to play them. Well, I guess you can use your old player. Until it breaks, or until it needs batteries and you find that they have switched battery design to new "secure" batteries. And you better stock up on those CD blanks because the new ones will have a serial number burned into the CD directory area.
If MicroSoft's IE pops up enough "this may be an insecure transaction and you may lose your life savings, continue or cancel?" type questions you can bet such a huge number of idiots will switch to Passport that Ebay will have to support it. MicroSoft will then set it up so Passport users can be paid for their sales, but only if they buyers are Passport users. Suddenly Passport is required to buy on Ebay. It wouldn't even be very hard...
The CPU will not run anything that can decode OGG files. It will not play unsigned files. The encoder will not tag files as copyrighted, in fact there will be no encoder, there will be the side effect that the average person will not be able to make a recording (or at least not a portable one that can be played back on different devices). The RIAA will say "aww, that's a shame, but it is the price we have to pay to stop those awful terrorist-pirates". And now suddenly nobody can produce music without signing a contract with an RIAA house.
This stuff is going to happen. Knowing that it can happen, and convincing the general public that it will happen and that this is a serious threat, is the only way we are going to stop it from happening. So denying it, like you seem to want to, is wrong.
Nonsense. The chip has access to large amounts of data at the same time, when it pages in memory into the cache. It can make a checksum of this, do a PK encryption of that, and compare it with another piece of data on some other page, and if it does not match it refuses to load the page. The system crashes soon after that. It has no need to "understand" what it is executing, it simply has to see if the data is correct.
This system is very bad news. Opt-out will be very short lived, as I'm sure MicroSoft expects Windows and many Windows apps to be broken very quickly, and the hackers will tell people to turn off TCPA to run the hacked binaries. Then the RIAA/MPAA will insist that the government make a regulation that requires people to stop making chips where it can be turned off.
You won't be able to purchase or sell on Ebay because the credit cards go through Passport which has been "security enhanced" so that it only talks to clients running Palladium.
Yes you will have to pay for the sample stream of the song. And that is IT, you will not be able to download anything. Why should they download anything when they can force you to pay each time to listen to it?
I think the answer they will give is that the employees entered into a contract with the employer and are free to leave.
However it seems that this means a government can do anything it wants as long as people are free to emigrate and it would be ok with libertarians. I don't think that is true, so yes they have to explain this a bit.
You may be right, I only just got Jaguar and was basing my observations on 10.1.
I don't see how you can avoid damage events as without them a hostile program can easily wipe out the system by asking for huge windows. It also seems they are necessary for resizing the windows anyway. An examination of the Cocoa objects may show whether they are needed, I doubt it is possible to support them without exposing the "repaint" method in the base class of widget.
As people have tried to explain about 6000 times here, the difference is that the EULA tries to reduce the rights you have by default under law.
The GPL tries to add to those rights. If you don't agree to the GPL you can do less with the code than you could do if you did agree to it (basically you can't redistribute it at all because that violates US and many other countries copyright laws). So you have no incentive to not agree with the GPL.
If you disobey the EULA (while still not violating copyright or other laws) you are ok if EULA's are unenforcable, but in legal trouble if they are not. But it is not possible to disobey the GPL without also breaking copyright laws, so you are in legal trouble anyway, whatever the legal status of the GPL is.
It's not clear that OS/X is doing 3D texture mapping or any kind of transform of the off-screen window images. I certainly don't see them using it: the "genie" effect appears to be a pixel-skipping effect that does "affine" transforms rather than the perspective transformation you would expect of a 3D system, and the miniature dock icons do not update, both of which would be easy to do if this could 3D texture-map the offscreen windows.
The resizing could be sped up to avoid reallocation by 2 things: first clip all windows to the size of the screen and don't store data outside that. Then when somebody tries to resize, the first time they need more memory than they are allocated it should allocate a screen-sized area. Then it never needs to be resized. Also don't reallocate when the window gets smaller. Then at some "garbage collection" step you can reallocate all windows to match the current size. It may make sense to always keep the full-screen-size buffer around.
Slashdot Mirror
But, but, but, you sputter, I thought all the SlashDot posters were sheep who want to steal music!
Sorry to rain on your parade. We aren't.
Sure, you couldn't do any of those things, but why would you want to? There are indeed ways to get the mouse pointer to pre-point at the default choices: you install a program on the computer. Logitech's MouseWorks does this, IIRC. You, on the other hand, advocate ONE application to behave inconsistently with every other. That's not innovation. That is pissing off me, the user. If I want the button to do that I'll install the software that will facilitate it system-wide,damnit. I don't want one single application to think it's cool.
Furthermore, this does not hinder interface innovation. The innovations will come in future OS revisions, which is when users expect that things will be different. You don't go changing the way Windows works until the next version of Windows comes out.
I know I sound bitchy and cranky, but this is how I get when people try to be Jakob Neilsen [uesit.com] when they obviously aren't. A general rule about interfaces: if you don't know what your talking about, don't mess with them.
And there you have it. We are not allowed to "innovate", that is actually something that only "experts" (paid professionals?) are allowed to do. As long as this mentality remains, there will be no innovation no matter how much the programmers want to do it.
Yes, it is exactly like X and a crash in the rendering brings the whole system down. Since X is more the level of the Win32 GDI however this is not quite as likely as a bug in html rendering.
Now back to the original argument. The speed of IE verses Mozilla. You should now compare the speed of starting Konquerer on an already-running KDE desktop with the speed of starting X and Mozilla, if you want the same type of comparison as being spouted about IE versus Mozilla.
Now there is nothing wrong with putting html rendering in the system, or as a service. In fact it is a HUGE win because it makes programs needing html rendering FASTER! But this is the reason IE is faster and every IE defender here seems to be trying to claim that that is not the reason, instead of logically saying that perhaps MicroSoft's design is better?
It is also a very good idea and I am flabbergasted that people will deny a feature of Windows just to win the "IE is faster" argument.
Uh, no. Non-palladium programs do not run when palladium is enabled. That is the whole point!
Same thing for the added features. Here I see paying somebody actually works, if you pay somebody to add a feature, it gets done.
I think the reason is that the knowledge that a feature could work involves less work than implementing the feature. That is not true of bug fixes, as it takes more effort to explain the bug and how to fix it than to fix it yourself, and saying "find and fix this" is usually noneffective because it usually means it cannot be fixed. Knowing it can be fixed requires almost all the knowledge needed to fix it, so by the time you know that paying somebody is cost-effective you can fix it yourself.
It is true that the companies employed the government to crack down on worker revolts. This would be a good argument to make: if there was not a government with a military willing to obey the company and funded by taxing many people (and thus having a larger source of funds than the company has access to) perhaps they could not crack down on the worker's revolt. It is possible that trying to fund a military of their own would not be cost-effective for the company.
What do you think of turn-of-the-century mining towns where the company owned all the land that all the houses were on and paid everybody with company scrip? I guess I still don't see the difference. Outlawing such companies requires a government to outlaw them, and then that government probably has the power to outlaw other things.
In open source if somebody notices a bug, they either don't know how to fix it, so they ignore it or they post a notice to the bug traq or mailing list and it is ignored there (anybody claiming they are not ignored is challenged to find one that was really fixed due to the bug report rather than claimed "we know about that and are working on it"). Or the *do* know how to fix it, so they fix it. They might, just maybe, try to tell another person how to fix it, but by the time they are finished it is so frustrating (because they know the answer) that they say "screw it, I'll fix it".
In closed source if somebody notices a bug, they either don't know how to fix it, so they ignore it or they post a notice to the bug database and it is ignored there (anybody claiming they are not ignored is challenged to find one that was really fixed due to the bug report rather than claimed "we know about that and are working on it"). Or the *do* know how to fix it, so they fix it. They might, just maybe, try to tell another person how to fix it, but by the time they are finished it is so frustrating (because they know the answer) that they say "screw it, I'll fix it".
So "Fixing" is the wrong term. However it is true that "adding features" is different in closed source. It is possible to hire somebody to add a feature, and this is done all the time. Features are treated like bugs in Open Source. You can make an argument that this is good because it avoids bloat, but that is about the only argument for it.
A single DLL has a single SHARED piece of memory and an init that is called the FIRST time it is loaded (not the first time it is loaded by an application). I think it can even launch a thread and have an event loop.
Therefore the IE DLL's are already "loaded and initialized".
Goddamn, it's not even a bad idea, and you Windows defenders will ignore it in order to try to make your stupid point.
Also that's why a rendering bug brings down the entire desktop rather than just IE.
It is pretty pathetic that the Window's defenders don't even know how their system works.
Now it may be possible if, instead of "widgets", people would come up with some "drawing" code. Some elements are pretty consistent: "draw a raised box", "draw a raised box I can press", "draw it pressed", etc. Then maybe systems could use it, most toolkits have calls like this inside them. Then again, even at this level I worry about a complexity and forced design, for instance the obvious implementations would not let you make non-square widgets, while a non-square one would be complex and could be rightly claimed to be too much overhead.
Also NONE of this has anything to do with enforcing consistent shortcuts between applications. From a programming point of view it is impossible. Imagine that they said Ctrl+C will ALWAYS do "cut". Then they say you must write a program with the function cut() and Ctrl+C will call that and you cannot do anything about it. That is what enforcing a consistent set of shortcuts means (Ignore the fact that you could make cut() do anything you wanted, I'm not assumming malicious programmers here). Imagine now you make up a new function, blorg, and you want Ctrl+E to call it. They know nothing about blorg so they cannot possibly call it. Okay, perhaps there is an interface that says "make Ctrl+E call blorg()". Great but what happens when they decide that Ctrl+E means a new standard (say go-to-end-of-line). Does your program stop working in that Ctrl+E stops calling blorg()? What if you relied on this fact? Or does Ctrl+E still call blorg()? Then you have an inconsistent user interface!
The fact is that ALL systems allow the shortcuts to be arbitrarily arranged. The fact is that programs, especially on Windows, are consistent is because the programmers have an incentive to make them consistent. This incentive is always ignored by the people who keep yelling for "single toolkit".
I think that will only be true for a short time. As soon as cracked programs come out that work when this is turned off there will be a government/DMCA requirement that it be always on.
So the copyright has nothing to do with your ability to modify the car.
DeCSS was legal at one time.
I hightly recommend that the KDE/Gnome guys get together and make a Linux "open" command, so we don't have to parse all their files just to figure out what a double-clicked file means. Even Windows does this (they call it "start") but for some reason the Linux guys, despite such familiarity with the command line, have not come up with this.
There is a stupid problem on Apple which is why you cannot just type the name of the program. All clickable applications are in ".app" directories, with the exectuable and support files all in one directory. This is a good idea but the implementation sucks:
First of all, if there are no support files they should allow a single exectuable rather than a .app directory, this is how Windows and KDE/Gnome handle files, on OS/X a compiled executable cannot be double-clicked from the finder, which is stupid. It also makes it a pain to write portable programs that can be run from the command line.
Second they should get rid of the ".app" suffix so that they don't have to special-case a "hide suffix" operation in the finder. If you rename any directory .app it screws up, this is probably a bad idea. They should also fix it so that exec can run these, right now to run such a command from the shell you have to type command.app/command to run the executable inside it. Again, pretty stoopid.
You realize that your HDTV screen will not show anything other than 480i after they introduce the new encrypted digital broadcast. The converter box analog outputs will ONLY be 480i. Enjoy your HDTV picture while you can, and I hope you liked spending your money.
There will be new machines that will play "old" CD's, but they will not play anything other than CD's and encrypted music files. Such a device can certainly determine that the data it is playing is coming off it's own laser, so you will at least have to burn a CD to get your music to play. But your new computer will not run the music-burning software! So you can use your old one, I guess. But the player may very well be able to detect writable CD's and refuse to play them. Well, I guess you can use your old player. Until it breaks, or until it needs batteries and you find that they have switched battery design to new "secure" batteries. And you better stock up on those CD blanks because the new ones will have a serial number burned into the CD directory area.
If MicroSoft's IE pops up enough "this may be an insecure transaction and you may lose your life savings, continue or cancel?" type questions you can bet such a huge number of idiots will switch to Passport that Ebay will have to support it. MicroSoft will then set it up so Passport users can be paid for their sales, but only if they buyers are Passport users. Suddenly Passport is required to buy on Ebay. It wouldn't even be very hard...
This stuff is going to happen. Knowing that it can happen, and convincing the general public that it will happen and that this is a serious threat, is the only way we are going to stop it from happening. So denying it, like you seem to want to, is wrong.
This system is very bad news. Opt-out will be very short lived, as I'm sure MicroSoft expects Windows and many Windows apps to be broken very quickly, and the hackers will tell people to turn off TCPA to run the hacked binaries. Then the RIAA/MPAA will insist that the government make a regulation that requires people to stop making chips where it can be turned off.
Yes you will have to pay for the sample stream of the song. And that is IT, you will not be able to download anything. Why should they download anything when they can force you to pay each time to listen to it?
I think the answer they will give is that the employees entered into a contract with the employer and are free to leave.
However it seems that this means a government can do anything it wants as long as people are free to emigrate and it would be ok with libertarians. I don't think that is true, so yes they have to explain this a bit.
I don't see how you can avoid damage events as without them a hostile program can easily wipe out the system by asking for huge windows. It also seems they are necessary for resizing the windows anyway. An examination of the Cocoa objects may show whether they are needed, I doubt it is possible to support them without exposing the "repaint" method in the base class of widget.
The GPL tries to add to those rights. If you don't agree to the GPL you can do less with the code than you could do if you did agree to it (basically you can't redistribute it at all because that violates US and many other countries copyright laws). So you have no incentive to not agree with the GPL.
If you disobey the EULA (while still not violating copyright or other laws) you are ok if EULA's are unenforcable, but in legal trouble if they are not. But it is not possible to disobey the GPL without also breaking copyright laws, so you are in legal trouble anyway, whatever the legal status of the GPL is.
The resizing could be sped up to avoid reallocation by 2 things: first clip all windows to the size of the screen and don't store data outside that. Then when somebody tries to resize, the first time they need more memory than they are allocated it should allocate a screen-sized area. Then it never needs to be resized. Also don't reallocate when the window gets smaller. Then at some "garbage collection" step you can reallocate all windows to match the current size. It may make sense to always keep the full-screen-size buffer around.