"they could release their code under the GPL, but then Stallman will just draft a GPLv4 that says whoever uses the license needs to release the source code to Windows if they are called "Microsoft""
You said that, I cut and pasted it out of your previous statement. Releasing your code under the GPL does not give Stallman control over what you can do with your code. Thus the above sentence is an incorrect statement. And you don't have the word "I think" or "I feel" anywhere near there.
I'm sorry but you are being a making a complete ass of yourself. There are intelligent arguments against the GPL but you are not doing your side any good by being an idiot.
You are an idiot. "using the GPL" is not the same as "sign your copyright over to the FSF". Look up and study and understand "dual licensing" and "relicensing" and then try to think a little tiny bit. I know it is difficult but please try.
The GPL is being used very well by Trolltech, for one, for the explicit purpose of selling their software. Without the GPL they would have no ability to advertise or sell their product because nobody would be able to try it. Microsoft fears this, and thus spews FUD such as "it forces you to open all your source code" and your inane rant that somehow the FSF gets to control what you do.
The problem is that Microsoft then goes on to talk plenty about how *some* of the "shared source" licenses are approved by the OSI, and how *some* of them are very much like the GPL or BSD licenses. But that "some" is usually made very tiny and disappears after awhile, so that the end result is that it sounds like *everything* called "shared source" is the same as Open Source, when in fact that most stuff that term is used on is *NOT* open source.
Comparing music copyright infingement to GPL infringement is a strawman argument.
If somebody were to copy music and release an album and claims that they wrote and performed it, thus denying the original author the credit, then it would be equivalent.
Conversely if somebody complained because a person copied a GPL program from one machine to another then it would be equivalent.
Technically the GPL is violated ALL THE TIME, millions of times a day. For instance a bittorrent client is violating it, as it likely only has a piece of a compiled code and not likely also has the equivalent source. I don't see the FSF acting like the RIAA and going after bittorrent clients.
Until you can actually make two equivalent cases you have no argument.
I think it is hilarious how you guys get so deranged when you see the M$ abbreviation. In fact you don't spell Microsoft "MS", that is most commonly an abbreviation for Multiple Sclerosis. I never used to but I now make sure I use that abbreviation as much as possible, because your knee-jerk reactions are so hilarious.
M$ is a company in Seattle. It makes M$ Windows. M$ was run by Bill Gates but now the president is Ballmer. M$ is a very large company. M$ has some low-level employees who feel that their great company is insulted because somebody used a punctuation mark in an abbreviation and thus makes the horrible grivious insulting impression that M$ might have something to do with *money*, when in fact M$ is a totally benevolent act of god.
How about having the title show *only the name of the file it is working on*. This should include the full path name. That I would like to see. There is no reason to show which program: the user either does not care, or can easily figure it out by the name of the file, or can open the window and look at it to figure this out.
It used to be that windows were titled this way. Whatever happened? This is not just Linux, but Windows and OSX as well. OSX is worse, the "dock" *only* shows the program, as though which file is completely irrelevant!
You misunderstood what he was saying. There are not 2 useable settings, there are 3 of them (both off, and either one on).
Certainly you can work around the above (ie don't change the menubar until user clicks in a window or types a key). Or change the control panel to a pulldown with the 3 working options on it. But in the real world there are often dozens of these on/off options and certain combinations do not work. There are then 2^n possible settings, of which a large fraction do not work. You cannot make a pulldown with 2^n-x possibilities, and you cannot write x different solutions for the wrong combinations.
I know this because I have been writing software with a user interface and people ask for options, and I certainly have to resist or it will become a nightmare of untested combinations that fail. Options are one of the big reasons user interfaces fail to work correctly.
Conversely though, if there is strong dislike for something, remove it! I don't care how clever you think it is, it is obviously wrong. This solves the problem without adding an option.
They may also have "cut costs" by stealing code (from competitors or GPL code), or by knowingly violating patents, and they need to hide this. In fact the fear that some engineer may have done this may make them hide the souce code, even if they don't know it happened for a fact.
How do you replace the lack of performance? Are you kidding? That electric is going to leave that V8 in the dust. You might want to read up on what an electric motor can do.
The surface-mounted optic nerve does have a function: light suppression
Don't make yourself look more idiotic than you appear to be.
The IRIS deals with light suppression. The eye can handle a lighting ratio of over 100,000 to 1 from brightest to dimmest area it functions in. You realize this is 6 or 7 orders of magnitude more than any filtering caused by the overlaying nerves and thus your explaination is so wrong it boggles the mind!
You are just upset that the Octopus eye disproves the "well maybe it has to be that way" argument about why the eye is so grossly misdesigned. It is unbelievable how desperate all you evolution deniers will get to try to say you have an argument.
The "standard" is enormously complex and is designed so that only Microsoft Word can read/write it, by being directly tied to internal data structures in the existing.doc format. All other programs that try to read it will work approximately as well as current non-Microsoft programs do at loading.doc and excel spreadsheets.
There are also claims that it is impossible to implement the standard without using patented or copyrighted software owned by Microsoft.
If you read the article, you would know that the president said "NO VOTING". Only if everybody agreed could things continue.
So what happened is for 2 of the articles, everybody agreed yes. For 2 of them everybody agreed no. For the remaining 6 not everybody agreed. According to the article the writer thought they were 80% no and 20% yes on these.
I said: expand the current functionality with something that simply *must* have better performance. Think laying out functioncalls in shared memory and calling interrupts for local clients. Think transporting events back to the client in the same way. Think painting directly in the frame buffer using shared memory. Actually ipc is the fastest way if designed right. You are ignoring the fact that it can easily send MORE than one message in a single context switch, by buffering them. Windows only got modern speeds by changing as many of the calls as possible to ones that write messages in a buffer, only sending that buffer when a return value or sync is needed. So in some ways the design of X is already the correct one for maximum performance. Pipelines are how graphics hardware runs so fast, you know.
Also, I realize that there are a load of APIs on top of the X client library that paint beautiful (and sometimes less beautiful) widgets, but a) they can't be fast because they wrap both the way in (XCreateWindow) and the way out (XGetEvent), and b) it would be a lot nicer if the X server actually understood what you *meant* when you said: 'make a scrollbar'. It can implement a faultless scrollbar namely. And generate scrollbar specific events. Here you are making a serious mistake. If X had done this from the start, it would be using something that looked like Athena widgets, and it would never be able to change. The reason X can run UI designs that were made 30 years after it was created is precisely because it was designed this way. If you believe that "theming" will magically make an obsolete widget library competitive there are some bridges in Brooklyn I would like to sell to you, too.
Also if you have done any work with talking to window managers or toolkits, you will probably notice that such api's have the annoying tendency to balloon into requiring far more code to talk to the interface than you would require to implement the widgets yourself. You don't want this mess locked into the basic design of your system, you want to be able to replace it when it gets too baroque to use.
With respect to cut-n-paste; they exist in Gnome and KDE. Separately. And also, separately inside WindowMaker and XFCE. It is a royal *bitch* to program against in X client lib, it depends entirely on the cooperation of the various program- and windowmanager-makers and a few conventions, and it is *very* incomplete. Here I agree. Somebody should write a wrapper for that xlib mess which acknoledges the fact that programs just want to treat the cut & paste as a single block of memory, no matter how large it is, and that should be the official xlib cut/paste api. Right now you cannot get it without using a toolkit and sometimes you don't want to use a toolkit, for instance if you want to write your own toolkit.
Graphics are also a huge mess, but Cairo seems to be addressing this.
The problem is NOT with the IPC. So "gut instinct" might make you know there is a problem, but also leads to wrong conclusions.
There are imho two problems with how X works:
First there is the ICCCM window manager design. This makes it absolutely impossible to have clean updates and resizes of windows because two asyncrhonous processes are updating different parts of the window. Programs that bypass the window manager, such as media players that do it to make windows without borders, work obviously faster and more smoothly, despite the fact that X is otherwise not changed. The real solution to this is to have the toolkits/libraries draw the window borders. Of course then you will run into the luddites who will scream that the user will be "confused" because all their window borders are not exactly the same color. But that is the correct solution, and users don't seem "confused" that buttons are being drawn by local libraies. If this is politically unacceptable, then solutions involving synchronization between the processess, primarily by letting the application call some code to redraw the borders and also having messages to indicate the desired size/position so the app can resize the window and immediately draw, may work. But that is much messier.
The second problem is synchronous calls to the xlib where the program has to wait for an answer (which the program often then throws away, but xlib had no idea it did not need to wait). The result is that latency gets turned into bandwidth. In fact we are fairly lucky that ipc was used because it's latency discouraged this design far more than the Win32 kernel api does, but not enough... I think a lot of this is being addressed with xcb replacing xlib.
Wrong. Imagine it takes 2 seconds to stop. Now imagine the road is so wide that it takes 10 seconds to get all the way across it. A yellow of 9 seconds would still not be any good even though that is far longer than the 2 seconds it takes to stop.
Conversely, imagine you had some kind of weird car that took 10 seconds to stop, by decelerating very quickly for 1 second and then going slowly for 9 seconds, but the distance it takes to stop is the distance it would travel in 1 second (this is possible, try drawing a plot of position verses time). Also imagine the road is exactly the same width as this distance. Then a yellow of 2 seconds is ok, despite being far shorter than "the time it takes you to stop". If you are less than one second from the intersection, you continue, and thus exit the intersection in less than 2 seconds. If you are 1 second or more away, you start the decelartion, stopping 10 seconds later but outside the intersection.
Now these are contrived, but it shows that the stopping time is irrelevant when compared to the yellow time.
The stopping *DISTANCE* as you said is quite relevant. If this distance plus the width of the intersection, divided by your velocity, is less than the length of the yellow, then the yellow is too short (in reality you also have to add the decision time which is probably 10 times bigger than the time it takes to travel the stopping distance).
But too many people say "I can't stop in the time the yellow has". This is wrong.
Actually this is wrong. Comparing the length of the yellow to the time it takes to stop is misleading and an error.
First, you have more than 1 second to stop. Lets say you are exactly 1 second away from the intersection at the moment the light turns yellow and you decelerate and stop at the intersection (thus not violating the law). Since you would have covered that distance in 1 second at your original velocity, and since by decelerating you are slowing down, it must take you more than 1 second to reach the intersection and stop (the light will turn red while you are still moving).
The *real* problem is that there *is* some point at which you are too close to the intersection to stop safely in that remaining distance. This could be when you are *less* than the 1 second length of the yellow away. At that point what you are supposed to do is continue at your current velocity through the intersection. Since you are not decelerating, the time it takes you to stop is irrelevant. However the yellow could be so short that at your current speed you will not exit the intersection before the yellow ends. This means you will violate the law, yet your other decision would be to make an "unsafe stop" and thus no matter what you will do you will violate the law. This is what the complaints are about.
You can see that the length of the yellow has nothing to do with how long it takes you to stop. Imagine the crossing road is very wide and/or you are travelling very slow, so that it takes 10 seconds to drive across it. If the yellow is 9 seconds long and turns on just as you enter the intersection, you cannot obey the law, even if you can stop is 1 second. So again comparing the length of the yellow to stopping time is irrelevant.
Also in reality, there is a far larger "how long it takes to decide whether to stop or continue" time. This time must be added to the length of the yellow and is probably much larger than the time it takes to cross the road or any other time.
That is NOT what "everyone else is saying". The initial poster CLEARLY stated "say I know the yellow is 6 seconds". The length of the yellow is irrelevant if the driver is deciding "can I stop safely before entering the intersection". The yellow could stay on for 1 microsecond or 10 years and it will have zero difference in whether slowing the car at a safe amount of deceleration will cause it to come to rest before or after the intersection.
The length of the yellow is only relevant if you want to know "can I exit the intersection before the yellow ends". Anybody who says any such thing about "knowing" the length of the yellow is therefore disobeying the law.
Now there *are* arguments to be made:
First of all, it is possible for the yellow to be so short that a car which is at the position at which point stopping before the intersection safely is not possible, and instead continues at it's current velocity, will not reach the exit point of the intersection before the yellow ends. This is the main accusation against cities, since that by definition means that somebody completely obeying the law will get a ticket. However whether this length is too short still has ZERO effect on what you should do when you see the yellow, it can, as I said, be 1 microsecond long, and that still makes no difference in whether the safe deceleration will stop you before you enter the intersection.
The other argument is the rear-ending one. This argument is basically "other drivers are going to assume I will disobey the law and by not doing what they expect I am endangering myself". That is a valid argument, but it does not apply if there are no cars behind you!
In any case I am sure the cities are rigging their lights to collect revenue, but I am pretty shocked at the attitude of some posters here at rationalizing their own bad driving practices.
Once upon a time the floating point was done on a seperate chip. You could buy a cheaper "non-professional" machine that emulated the fpu in software and ran slower. You could also upgrade your machine by adding the fpu chip.
I can't believe you confused "OOXML" with "Open Office's XML". Why they are totally different, as a hundered M$ apologists will post here immediatly at any time somebody says they chose that name in order to make it confusing.
Can somebody tell me exactly what Windows does when it is in "hide extensions mode" and the file is named foo.jpg.exe? One weird thing is that nobody anywhere seems to be answering that question. Hard to believe but there really are people who don't use Windows enough to figure out a test for this question (I don't know what software to use, I don't know where the option is, etc).
I'm beginning to suspect it shows just "foo", which would indicate really bad programming at Microsoft (basically using different rules for the extension when hiding verses when figuring out what to do).
However if it shows "foo.jpg" then this is really a good indication of two things: first that hiding the extensions is a really bad idea. But, perversely, it is an indication that the extension is a *really good* idea for determining what a file is, better than hidden attributes used by OSX and Mime or magic bytes used by a lot of Unix utilities.
Another question: these programs show some sort of icon or preview, don't they? Do they show the exe icon or the jpg icon, or the jpg.exe icon? If they actually show an icon different from what Windows will do when they double-click, then that is incredibly stupid on Microsoft's part. However I find it hard to believe they could be that stupid, or at least so stupid that they would not have fixed this years ago. So another question: what icon is shown?
Here are some concrete little suggestions that would prove Microsoft really is trying. Not nonsense that they won't do (like open-source stuff, or port Word to Linux). Very simple stuff that they have refused to do for years and years:
1. Do not "certify" software that will not accept a filename that is typed in or is dragged & dropped or cut & pasted that has forward slashes in it.
2. Do not "certify" software that cannot read a text file with bare linefeeds in it and preserve the line breaks.
3. Add a way to name a file on any disk that starts with a slash and works in any piece of software using any Windows calls that manipulate files, and that shows up in an attempt to list the directory it is in. My recommendation is "/A:/blah".
4. Add symbolic links and fix the finder to not screw up if you copy or delete them.
5. Include bash or some other Unix shell by default with Windows.
6. Add C99 standards to header files, such as NAN, sinf(), etc. Remove the underscores added to about 1/2 of the c99 library functions like snprintf. In general do all the obvious and easy things to fix POSIX compatability.
7. Add working "export" keyword to vc++ compiler so that you don't have to write macros with "__declspec(dllimport/export)" in order to make a shared library.
There is also OpenStep or GnuStep or whatever it is called. Seems like Cocotron should get together with them, I searched but see no mention of it on their web site. They should at least explain how they are different.
I'm not sure what problems will be run into in making a "blank" window. I suspect it will be better than NeXTStep because Apple had to support the Carbon api which required such an interface at a low level.
Typical problems I ran into in NeXTStep was the inability to make a window that you could cut & paste to without also making an associated floating menu.
What people are failing to notice is that Cocoa is a "higher level" api than Carbon. That sounds good to a PHB, but in many cases it is worse.
It is an entire toolkit, similar to Qt, except it only runs on one platform. This is a serious impediment to anybody wanting to make software that runs on something other than that platform. The closest Linux equivalent would be to say that all software on Linux must use Motif, and that if you want to port to Windows or Mac you must emulate Motif.
"So write a wrapper for it to make a portable api". The problem is that it is vastly easier to write such a wrapper over a lower-level library, than to try to adapt two different high-level apis. This is why EVERY portable toolkit in existence uses Carbon and all programs using them are not going to have 64 bit osx versions for awhile. This includes Qt, incidentally!
Qt is probably going to be the first to solve it. But the solution is going to be by figuring out how to get Cocoa to make a "blank" window with no widgets and then drawing everything inside it. This may represent the waste of considerable overhead. My experience with NeXTStep indicates that a lot of required communication about the windows, such as what program they belong to, is intricately tied up with stuff that makes the window less "blank", and that trying to get a working low-level api that seems to be a native program is going to be a real pain to implement.
The argument is that if you follow your logic that the r,g,b subpixels give you 256^3 colors, than you can also claim that a larger block of subpixels, for instance one more red from the next pixel, gives you 256^4 colors, or at least 256*256*512 if you just assume the two reds are indistinguisable and add together. If you claim the whole screen is a "pixel" then you get an astronomical number of colors.
Thus the argument is that the only logical way to count the colors is to count the colors that the subpixels can produce. There are 3 types of subpixels each producing 256 different shades, thus 3*256 colors.
Your counter-example of using the bits for the subpixel does not take into account that the bits produce different amounts of light. The "light" controlled by bit 1 is twice as bright as the "light" controlled by bit 0. Thus the combination of bits 1 and 0 produce 4 different amounts of light.
The more subjective argument is that it seems at worst a 6-bit screen only displays about 1/4 as many colors, not the 1/12 as many colors or the 1/48th that some arguments claim.
The counter-argument is that the documentation coming with the screen that says "millions of colors" also says exactly how many pixels there are on the screen, thus it defines a pixel as being a rgb triplet.
DRM/Encryption: these are NOT the same. Encryption relies on the hostile party *not* having the key. DRM attempts to rely on the hostile party *having* the key. This makes the totally different.
User tracking/Browser history: huge difference here is that the browser history is local and not actually sent to anybody.
Phoning home/automatic updates: yep I will give you that one.
Rootkits / game anti-cheat systems: game anti-cheat systems are almost identical to rootkit-detection and prevention, thus these are almost exact opposites of each other!
Slashdot Mirror
Here is an incorrect fact:
"they could release their code under the GPL, but then Stallman will just draft a GPLv4 that says whoever uses the license needs to release the source code to Windows if they are called "Microsoft""
You said that, I cut and pasted it out of your previous statement. Releasing your code under the GPL does not give Stallman control over what you can do with your code. Thus the above sentence is an incorrect statement. And you don't have the word "I think" or "I feel" anywhere near there.
I'm sorry but you are being a making a complete ass of yourself. There are intelligent arguments against the GPL but you are not doing your side any good by being an idiot.
You are an idiot. "using the GPL" is not the same as "sign your copyright over to the FSF". Look up and study and understand "dual licensing" and "relicensing" and then try to think a little tiny bit. I know it is difficult but please try.
The GPL is being used very well by Trolltech, for one, for the explicit purpose of selling their software. Without the GPL they would have no ability to advertise or sell their product because nobody would be able to try it. Microsoft fears this, and thus spews FUD such as "it forces you to open all your source code" and your inane rant that somehow the FSF gets to control what you do.
The problem is that Microsoft then goes on to talk plenty about how *some* of the "shared source" licenses are approved by the OSI, and how *some* of them are very much like the GPL or BSD licenses. But that "some" is usually made very tiny and disappears after awhile, so that the end result is that it sounds like *everything* called "shared source" is the same as Open Source, when in fact that most stuff that term is used on is *NOT* open source.
Comparing music copyright infingement to GPL infringement is a strawman argument.
If somebody were to copy music and release an album and claims that they wrote and performed it, thus denying the original author the credit, then it would be equivalent.
Conversely if somebody complained because a person copied a GPL program from one machine to another then it would be equivalent.
Technically the GPL is violated ALL THE TIME, millions of times a day. For instance a bittorrent client is violating it, as it likely only has a piece of a compiled code and not likely also has the equivalent source. I don't see the FSF acting like the RIAA and going after bittorrent clients.
Until you can actually make two equivalent cases you have no argument.
I think it is hilarious how you guys get so deranged when you see the M$ abbreviation. In fact you don't spell Microsoft "MS", that is most commonly an abbreviation for Multiple Sclerosis. I never used to but I now make sure I use that abbreviation as much as possible, because your knee-jerk reactions are so hilarious.
M$ is a company in Seattle. It makes M$ Windows. M$ was run by Bill Gates but now the president is Ballmer. M$ is a very large company. M$ has some low-level employees who feel that their great company is insulted because somebody used a punctuation mark in an abbreviation and thus makes the horrible grivious insulting impression that M$ might have something to do with *money*, when in fact M$ is a totally benevolent act of god.
How about having the title show *only the name of the file it is working on*. This should include the full path name. That I would like to see. There is no reason to show which program: the user either does not care, or can easily figure it out by the name of the file, or can open the window and look at it to figure this out.
It used to be that windows were titled this way. Whatever happened? This is not just Linux, but Windows and OSX as well. OSX is worse, the "dock" *only* shows the program, as though which file is completely irrelevant!
You misunderstood what he was saying. There are not 2 useable settings, there are 3 of them (both off, and either one on).
Certainly you can work around the above (ie don't change the menubar until user clicks in a window or types a key). Or change the control panel to a pulldown with the 3 working options on it. But in the real world there are often dozens of these on/off options and certain combinations do not work. There are then 2^n possible settings, of which a large fraction do not work. You cannot make a pulldown with 2^n-x possibilities, and you cannot write x different solutions for the wrong combinations.
I know this because I have been writing software with a user interface and people ask for options, and I certainly have to resist or it will become a nightmare of untested combinations that fail. Options are one of the big reasons user interfaces fail to work correctly.
Conversely though, if there is strong dislike for something, remove it! I don't care how clever you think it is, it is obviously wrong. This solves the problem without adding an option.
They may also have "cut costs" by stealing code (from competitors or GPL code), or by knowingly violating patents, and they need to hide this. In fact the fear that some engineer may have done this may make them hide the souce code, even if they don't know it happened for a fact.
The surface-mounted optic nerve does have a function: light suppression
Don't make yourself look more idiotic than you appear to be.
The IRIS deals with light suppression. The eye can handle a lighting ratio of over 100,000 to 1 from brightest to dimmest area it functions in. You realize this is 6 or 7 orders of magnitude more than any filtering caused by the overlaying nerves and thus your explaination is so wrong it boggles the mind!
You are just upset that the Octopus eye disproves the "well maybe it has to be that way" argument about why the eye is so grossly misdesigned. It is unbelievable how desperate all you evolution deniers will get to try to say you have an argument.
The "standard" is enormously complex and is designed so that only Microsoft Word can read/write it, by being directly tied to internal data structures in the existing .doc format. All other programs that try to read it will work approximately as well as current non-Microsoft programs do at loading .doc and excel spreadsheets.
There are also claims that it is impossible to implement the standard without using patented or copyrighted software owned by Microsoft.
If you read the article, you would know that the president said "NO VOTING". Only if everybody agreed could things continue.
So what happened is for 2 of the articles, everybody agreed yes. For 2 of them everybody agreed no. For the remaining 6 not everybody agreed. According to the article the writer thought they were 80% no and 20% yes on these.
Reading comprehension is your friend.
Also if you have done any work with talking to window managers or toolkits, you will probably notice that such api's have the annoying tendency to balloon into requiring far more code to talk to the interface than you would require to implement the widgets yourself. You don't want this mess locked into the basic design of your system, you want to be able to replace it when it gets too baroque to use. With respect to cut-n-paste; they exist in Gnome and KDE. Separately. And also, separately inside WindowMaker and XFCE. It is a royal *bitch* to program against in X client lib, it depends entirely on the cooperation of the various program- and windowmanager-makers and a few conventions, and it is *very* incomplete. Here I agree. Somebody should write a wrapper for that xlib mess which acknoledges the fact that programs just want to treat the cut & paste as a single block of memory, no matter how large it is, and that should be the official xlib cut/paste api. Right now you cannot get it without using a toolkit and sometimes you don't want to use a toolkit, for instance if you want to write your own toolkit.
Graphics are also a huge mess, but Cairo seems to be addressing this.
The problem is NOT with the IPC. So "gut instinct" might make you know there is a problem, but also leads to wrong conclusions.
There are imho two problems with how X works:
First there is the ICCCM window manager design. This makes it absolutely impossible to have clean updates and resizes of windows because two asyncrhonous processes are updating different parts of the window. Programs that bypass the window manager, such as media players that do it to make windows without borders, work obviously faster and more smoothly, despite the fact that X is otherwise not changed. The real solution to this is to have the toolkits/libraries draw the window borders. Of course then you will run into the luddites who will scream that the user will be "confused" because all their window borders are not exactly the same color. But that is the correct solution, and users don't seem "confused" that buttons are being drawn by local libraies. If this is politically unacceptable, then solutions involving synchronization between the processess, primarily by letting the application call some code to redraw the borders and also having messages to indicate the desired size/position so the app can resize the window and immediately draw, may work. But that is much messier.
The second problem is synchronous calls to the xlib where the program has to wait for an answer (which the program often then throws away, but xlib had no idea it did not need to wait). The result is that latency gets turned into bandwidth. In fact we are fairly lucky that ipc was used because it's latency discouraged this design far more than the Win32 kernel api does, but not enough... I think a lot of this is being addressed with xcb replacing xlib.
Wrong. Imagine it takes 2 seconds to stop. Now imagine the road is so wide that it takes 10 seconds to get all the way across it. A yellow of 9 seconds would still not be any good even though that is far longer than the 2 seconds it takes to stop.
Conversely, imagine you had some kind of weird car that took 10 seconds to stop, by decelerating very quickly for 1 second and then going slowly for 9 seconds, but the distance it takes to stop is the distance it would travel in 1 second (this is possible, try drawing a plot of position verses time). Also imagine the road is exactly the same width as this distance. Then a yellow of 2 seconds is ok, despite being far shorter than "the time it takes you to stop". If you are less than one second from the intersection, you continue, and thus exit the intersection in less than 2 seconds. If you are 1 second or more away, you start the decelartion, stopping 10 seconds later but outside the intersection.
Now these are contrived, but it shows that the stopping time is irrelevant when compared to the yellow time.
The stopping *DISTANCE* as you said is quite relevant. If this distance plus the width of the intersection, divided by your velocity, is less than the length of the yellow, then the yellow is too short (in reality you also have to add the decision time which is probably 10 times bigger than the time it takes to travel the stopping distance).
But too many people say "I can't stop in the time the yellow has". This is wrong.
Actually this is wrong. Comparing the length of the yellow to the time it takes to stop is misleading and an error.
First, you have more than 1 second to stop. Lets say you are exactly 1 second away from the intersection at the moment the light turns yellow and you decelerate and stop at the intersection (thus not violating the law). Since you would have covered that distance in 1 second at your original velocity, and since by decelerating you are slowing down, it must take you more than 1 second to reach the intersection and stop (the light will turn red while you are still moving).
The *real* problem is that there *is* some point at which you are too close to the intersection to stop safely in that remaining distance. This could be when you are *less* than the 1 second length of the yellow away. At that point what you are supposed to do is continue at your current velocity through the intersection. Since you are not decelerating, the time it takes you to stop is irrelevant. However the yellow could be so short that at your current speed you will not exit the intersection before the yellow ends. This means you will violate the law, yet your other decision would be to make an "unsafe stop" and thus no matter what you will do you will violate the law. This is what the complaints are about.
You can see that the length of the yellow has nothing to do with how long it takes you to stop. Imagine the crossing road is very wide and/or you are travelling very slow, so that it takes 10 seconds to drive across it. If the yellow is 9 seconds long and turns on just as you enter the intersection, you cannot obey the law, even if you can stop is 1 second. So again comparing the length of the yellow to stopping time is irrelevant.
Also in reality, there is a far larger "how long it takes to decide whether to stop or continue" time. This time must be added to the length of the yellow and is probably much larger than the time it takes to cross the road or any other time.
That is NOT what "everyone else is saying". The initial poster CLEARLY stated "say I know the yellow is 6 seconds". The length of the yellow is irrelevant if the driver is deciding "can I stop safely before entering the intersection". The yellow could stay on for 1 microsecond or 10 years and it will have zero difference in whether slowing the car at a safe amount of deceleration will cause it to come to rest before or after the intersection.
The length of the yellow is only relevant if you want to know "can I exit the intersection before the yellow ends". Anybody who says any such thing about "knowing" the length of the yellow is therefore disobeying the law.
Now there *are* arguments to be made:
First of all, it is possible for the yellow to be so short that a car which is at the position at which point stopping before the intersection safely is not possible, and instead continues at it's current velocity, will not reach the exit point of the intersection before the yellow ends. This is the main accusation against cities, since that by definition means that somebody completely obeying the law will get a ticket. However whether this length is too short still has ZERO effect on what you should do when you see the yellow, it can, as I said, be 1 microsecond long, and that still makes no difference in whether the safe deceleration will stop you before you enter the intersection.
The other argument is the rear-ending one. This argument is basically "other drivers are going to assume I will disobey the law and by not doing what they expect I am endangering myself". That is a valid argument, but it does not apply if there are no cars behind you!
In any case I am sure the cities are rigging their lights to collect revenue, but I am pretty shocked at the attitude of some posters here at rationalizing their own bad driving practices.
Once upon a time the floating point was done on a seperate chip. You could buy a cheaper "non-professional" machine that emulated the fpu in software and ran slower. You could also upgrade your machine by adding the fpu chip.
Such FPU's do not exist today.
I think Nvidia should be worried about this.
I can't believe you confused "OOXML" with "Open Office's XML". Why they are totally different, as a hundered M$ apologists will post here immediatly at any time somebody says they chose that name in order to make it confusing.
Can somebody tell me exactly what Windows does when it is in "hide extensions mode" and the file is named foo.jpg.exe? One weird thing is that nobody anywhere seems to be answering that question. Hard to believe but there really are people who don't use Windows enough to figure out a test for this question (I don't know what software to use, I don't know where the option is, etc).
I'm beginning to suspect it shows just "foo", which would indicate really bad programming at Microsoft (basically using different rules for the extension when hiding verses when figuring out what to do).
However if it shows "foo.jpg" then this is really a good indication of two things: first that hiding the extensions is a really bad idea. But, perversely, it is an indication that the extension is a *really good* idea for determining what a file is, better than hidden attributes used by OSX and Mime or magic bytes used by a lot of Unix utilities.
Another question: these programs show some sort of icon or preview, don't they? Do they show the exe icon or the jpg icon, or the jpg.exe icon? If they actually show an icon different from what Windows will do when they double-click, then that is incredibly stupid on Microsoft's part. However I find it hard to believe they could be that stupid, or at least so stupid that they would not have fixed this years ago. So another question: what icon is shown?
Here are some concrete little suggestions that would prove Microsoft really is trying. Not nonsense that they won't do (like open-source stuff, or port Word to Linux). Very simple stuff that they have refused to do for years and years:
1. Do not "certify" software that will not accept a filename that is typed in or is dragged & dropped or cut & pasted that has forward slashes in it.
2. Do not "certify" software that cannot read a text file with bare linefeeds in it and preserve the line breaks.
3. Add a way to name a file on any disk that starts with a slash and works in any piece of software using any Windows calls that manipulate files, and that shows up in an attempt to list the directory it is in. My recommendation is "/A:/blah".
4. Add symbolic links and fix the finder to not screw up if you copy or delete them.
5. Include bash or some other Unix shell by default with Windows.
6. Add C99 standards to header files, such as NAN, sinf(), etc. Remove the underscores added to about 1/2 of the c99 library functions like snprintf. In general do all the obvious and easy things to fix POSIX compatability.
7. Add working "export" keyword to vc++ compiler so that you don't have to write macros with "__declspec(dllimport/export)" in order to make a shared library.
There is also OpenStep or GnuStep or whatever it is called. Seems like Cocotron should get together with them, I searched but see no mention of it on their web site. They should at least explain how they are different.
I'm not sure what problems will be run into in making a "blank" window. I suspect it will be better than NeXTStep because Apple had to support the Carbon api which required such an interface at a low level.
Typical problems I ran into in NeXTStep was the inability to make a window that you could cut & paste to without also making an associated floating menu.
What people are failing to notice is that Cocoa is a "higher level" api than Carbon. That sounds good to a PHB, but in many cases it is worse.
It is an entire toolkit, similar to Qt, except it only runs on one platform. This is a serious impediment to anybody wanting to make software that runs on something other than that platform. The closest Linux equivalent would be to say that all software on Linux must use Motif, and that if you want to port to Windows or Mac you must emulate Motif.
"So write a wrapper for it to make a portable api". The problem is that it is vastly easier to write such a wrapper over a lower-level library, than to try to adapt two different high-level apis. This is why EVERY portable toolkit in existence uses Carbon and all programs using them are not going to have 64 bit osx versions for awhile. This includes Qt, incidentally!
Qt is probably going to be the first to solve it. But the solution is going to be by figuring out how to get Cocoa to make a "blank" window with no widgets and then drawing everything inside it. This may represent the waste of considerable overhead. My experience with NeXTStep indicates that a lot of required communication about the windows, such as what program they belong to, is intricately tied up with stuff that makes the window less "blank", and that trying to get a working low-level api that seems to be a native program is going to be a real pain to implement.
The argument is that if you follow your logic that the r,g,b subpixels give you 256^3 colors, than you can also claim that a larger block of subpixels, for instance one more red from the next pixel, gives you 256^4 colors, or at least 256*256*512 if you just assume the two reds are indistinguisable and add together. If you claim the whole screen is a "pixel" then you get an astronomical number of colors.
Thus the argument is that the only logical way to count the colors is to count the colors that the subpixels can produce. There are 3 types of subpixels each producing 256 different shades, thus 3*256 colors.
Your counter-example of using the bits for the subpixel does not take into account that the bits produce different amounts of light. The "light" controlled by bit 1 is twice as bright as the "light" controlled by bit 0. Thus the combination of bits 1 and 0 produce 4 different amounts of light.
The more subjective argument is that it seems at worst a 6-bit screen only displays about 1/4 as many colors, not the 1/12 as many colors or the 1/48th that some arguments claim.
The counter-argument is that the documentation coming with the screen that says "millions of colors" also says exactly how many pixels there are on the screen, thus it defines a pixel as being a rgb triplet.
Your examples do not really conflict:
DRM/Encryption: these are NOT the same. Encryption relies on the hostile party *not* having the key. DRM attempts to rely on the hostile party *having* the key. This makes the totally different.
User tracking/Browser history: huge difference here is that the browser history is local and not actually sent to anybody.
Phoning home/automatic updates: yep I will give you that one.
Rootkits / game anti-cheat systems: game anti-cheat systems are almost identical to rootkit-detection and prevention, thus these are almost exact opposites of each other!