I don't really want to have to code separate versions of every page for Netscape 1.0 and for Lynx.
Well, it's a good thing that what I advocated was the exact opposite of that, then.
Anyone who's done web pages for real has had to deal with browser compatibility. The ASP.NET approach of emitting different HTML for different browsers makes this a LOT less of a pain.
But the types of servers you speak of don't check for *features* supported. They check for brand names, and that's the complaint I have. Just because a browser visiting your page is one you didn't test for, that doesn't automatically mean it can't do the features you need. It's that broken mentality that makes new up-and-coming browsers like Opera have to lie about what kind of browser they are in order to use certain sites developed with a mentality similar to yours. The reason they have to lie just to get the HTML shipped to them is that the servers aren't programed with a default case of "just spit out w3c standard stuff and if the browser can't deal with it that's the browser's fault." So places that program only to IE, or only to IE and Netscape continue to believe the lie that those are the only browsers that exist (because people have to browse with the user-agent string set to the lie that they are IE or Netscape), and that's what shows up in all logs then.
Again I will remind you that I didn't say there would be NO problems at all. I do maintain, however, that it is a much easier problem to fix than y2k was. Every objection raised (such as yours about not having the source code) has been one that y2k shared as well, yet there are problems y2k had that y2038 won't. In other words, y2038's problems are a smaller subset of y2k's problems. Mostly this is due to the fact that y2k dealt with older code tha was not developed under the "make a defined constant for everything" mentality that prevails today.
The programmer's IDE is not a feature of the language nor the.net archetecture. For example, tab-completion of function names is not a feature of Visual Basic. It's a feature of MS Developer Studio.
HTML generated can be transformed to work on all types of browsers (utilising the features of each)
Or it could have just been written to te W3c spec in the first place. No, that wouldn't be the MS way. Instead make something that has to know which browser you are using and change its behaviour accordingly. (Which of course fails utterly to be *forward* compatable with new and improved browsers you haven't heard of yet. I'm sick of websites that tell me I need to "upgrade" to Netscape 4.76 or I.E. 5.0 when I'm running something *newer* that would work if the site would just send me the HTML it would have sent to one of those two browsers.)
The point is that given a particular thing, you cannot categorize it as either tactics or strategy (as the post that started this tried to do) without knowing more context of what depth is being referred to. Asking how to win the war might sound like strategy, if you are looking at it from the standpoint of a general who is already stuck having to fight the war. But if you are talking as a political leader of a country then how to win the war is all "n-1" stuff and therefore tactics. The strategy at that level includes the decision of whether a war should be fought in the first place to achieve the desired aim or if another approach might be better.
Hence the claim that a particular game is really a tactical one and not a strategic one is pretty meaningless. If you're playing "Civilization" the decision of sending bombers to hit a tank batallion (your example of strategy) is actually tactics within the scope of that game.
Emulators always slow things down, that's why they're best for older games.
Well, it's a good thing Wine doesn't work by trying to emulate hardware then. It works by being a *replacement* for the Win32 library that maps calls to Linux operations rather than mapping them to Windows operations. That's why they're so adamant about drilling it into everyone's heads that "Wine Is Not an Emulator". It's merely a second implementation of the Windows API, not necessarily faster or slower than the original one you get with Windows. (In practice it is slower for some API calls and faster for others. Whether a program runs faster on Wine or Windows depends on which calls it uses.)
Wine is an "emulator" only in the same sense that Windows' TCP stack is an "emulator" of Unix's. It emulates the *idea* by reimplemeting it with fresh code.
Wine won't work on the 'wrong' hardware. It isn't emulating the CPU's instruction set. It's letting the binary run directly on the CPU just like it would for any native process. It's just that the CPU most often used with Linux happens to the same type as the one Windows uses, the x86, so there is no need to emulate the machine (And THAT is where the slowness you usually associate with an emulator comes from. VMware, for example, valued correctness over speed, so it implemented the entire hardware of a fake PC and then ran the guest OS inside that, and THAT was slow because it has to hardware trap all the low level hardware except the CPU and emulate it at the lowest level.). Wine merely provides a library to implement the function calls in the Win32 API that would otherwise not be there on a linux system, so it operates at a much higher level, not trying to emulate hardware at all. That is what makes it faster, but that is also what makes it less than 100% "correct" and causes some programs that depended on Windows' *exact* behavior to fail.
But in a real war your units don't need to be ordered to do each move, each fire, each reaction, by the general in order to not act like moron with a single-digit IQ driven by an AI. The problem with RTS in general, (and I agree with the poster here) is that there is a distinct advantage to doing things yourself instead of letting the AI do it, and so the winner is the one with the best ability to navigate the interface and be in more than one place at a time, not necessarily the one with the best mental ability. The next time you trick yourself into believing that RTS is an actal strategy game, imagine playing against someone who is smarter than you but has muscular dystrophy, and think about who would win. RTS is a video game, not a strategy game. If I want a video game, I'll play a FPS. If I want a strategy game, I'll play something like Civ that has turns.
Strategy is a game plan. It's how you intend to accomplish some goal.
Tactics on the other hand are the actual methods used to carry out a strategy.
But then for any particular scale N, the word "tactics" becomes just a pseudonym for "the strategy of N-1, the scale one smaller that the one I'm paying attention to." Which is tactic and which is strategy depends on what level of depth the speaker is talking about.
"Wine is not an emulator" refers to the fact that it is not a PLATFORM emulator. Programs running under wine are just programs running on your unix machine, but linked to a special library to handle all their system calls. They are no different in principle than any other program running on the machine.
If you want to use such a broad definition of "emulator", then MS Office is an "emulator" that emulates a typewriter.
And your evidence for saying that the respondants to the poll who answered "MS office" are the same as the people who bash MS is what exactly? Oh, that's right, you don't have any.
re: Linux/GNU/X11: And had they continued the trend to today, it would take a pargraph to finish writing the name of the OS. Names must be short, and they *must* necessarily leave out some details to be useful. Otherwise you might as well not bother giving something a name and just use the longhand description each time. So the question is, given that GNU is only responsible for writing *some* of the code for the OS, why should it get top billing up in the name? It's not practical to give everyone who deserves it top billing up in the name, because as mentioned above, names *must* necessarily leave details out or there's no point to having them.
So, in order for the y2k coders to not be grafters bamboozling people out of their money, their projects would have had to fail so you'd notice a problem?
I predict the y2038 problem won't take much effort to fix. Most (good) programs these days are designed without hardcoding the exact bytesize of things, and instead using system-supplied types. For example, we don't say:
char timebuff[4];/* 32 bits */ ... *((int*)timebuff) = time(NULL); ...
Instead we do stuff like this:
time_t timebuff; ... timebuff = time(NULL); ...
When the system type for time_t is change to something with more than 32 bits, the code just needs a recompile and voilla - it handles dates past 2038. The work is going to be in making sure every program gets recompiled, and in converting saved files that have the date already stored in 32 bits. The ugly part will be if your system depends on third-party stuff in binary form only that you can't upgrade for whatever reason.
Note, I didn't say the problem will be nonexistant, just that it will be easier to fix than y2k.
Perhaps the quote should read "absence of evidence is not proof of absence,"
Yes. That would be much better in that it is actually true, unlike the original quotation.
..there is no logical reason to believe something does not exist./em>
There is no logical reason to call the stance "I don't think it exists" a belief. It's the default working hypothesis in any question of whether or not something exists, because it is the only situation that is absoltely guaranteed to lead to an utter lack of evidence. There may be other situations that can also lead to a lack of evidence, but "doesn't exist" is the only one that is guaranteed to. Therefore if you start from *any* other stance at all, even one of "maybe", it is completely impossible to ever be swayed from that stance by the facts, even if you are wrong.
Even if other intelligent life doesn't actually exist, those who are looking for it will *never* be able to know that. It's a belief that once adopted, can never go away because it is impervious to assult by real world evidence. It is far better to say, "I don't believe it exists yet" while scanning the skies than to say, "I think it has a good chance of existing" or "It might exist", or "I hold out hope that it exists".
It's that sort of nonsense that starts religions.
I use mozilla and like the interface. The thing that kept me from using it before was the buggy crashiness of it, and the fact that it didn't have much support for java/javascript/realaudio/and so on. Now it does, so I'm going back to using Mozilla, the interface I would have preferred all along to the awful one Opera has, which I lived with because at least the program actually functioned.
I have yet to experience this alleged non-intuativeness of Mozilla to which you are referring. I *have* on the other hand, experienced much instability with it.
But then again, I often switch between using different OS'es during the day, so I don't see having to switch GUI contexts ever so slightly as a major hurdle. I'm very used to it.
This doesn't say a thing about windows UI compliance.
And if you had only read the summary and gone no futher then I would understand how you would come away thinking that he was complaining about more than un-Windowsness. But it is clear that you did read the rest of it, so how did you not notice that ALL the examples he gave of why he disliked the gui were saying that it was wrong because it was unlike other Windows apps. (Which isn't even true in the example he gave of the close vs exit option, by the way. In Windows apps, the bottommost thing on the file menu sometimes *is* to close the whole program not just one if its windows.)
But the important thing is that you are describing an actual bug that breaks the program. He was not.
Am I the only one that sees the irony in complaining that the interface is "unflexible" while simultaneously singing the praises of forcing your app to be exactly like the standard native interface?
Of course there is ambiguity. It's just the other way around then - there can be menu options in the main bar that affect just the one window instead of the whole app.
There are other systems where people would be just as pissed if the last item on the menu *failed* to remove the whole app like they expect. What your whole argument boils down to is, "Mozilla must conform to whatever is already common practice in Windows, regardless of what this may do to people on other platforms. Those other platforms don't matter." This is precisely the attitude that makes it inevitable that MS wins always, no matter what the relative merits of the products may be.
Slashdot Mirror
Again I will remind you that I didn't say there would be NO problems at all.
I do maintain, however, that it is a much easier problem to fix than y2k was. Every objection raised (such as yours about not having the source code) has been one that y2k shared as well, yet there are problems y2k had that y2038 won't. In other words, y2038's problems are a smaller subset of y2k's problems. Mostly this is due to the fact that y2k dealt with older code tha was not developed under the "make a defined constant for everything" mentality that prevails today.
HTML generated can be transformed to work on all types of browsers (utilising the features of each)
Or it could have just been written to te W3c spec in the first place. No, that wouldn't be the MS way. Instead make something that has to know which browser you are using and change its behaviour accordingly. (Which of course fails utterly to be *forward* compatable with new and improved browsers you haven't heard of yet. I'm sick of websites that tell me I need to "upgrade" to Netscape 4.76 or I.E. 5.0 when I'm running something *newer* that would work if the site would just send me the HTML it would have sent to one of those two browsers.)
Hence the claim that a particular game is really a tactical one and not a strategic one is pretty meaningless. If you're playing "Civilization" the decision of sending bombers to hit a tank batallion (your example of strategy) is actually tactics within the scope of that game.
Well, I agree with that. In fact I agree so much I already mentioned it in the post you are replying to. Allow me to cut and paste the relevant part:
So when you hear facts you don't like you ignore them. Noted.
Emulators always slow things down, that's why they're best for older games.
Well, it's a good thing Wine doesn't work by trying to emulate hardware then. It works by being a *replacement* for the Win32 library that maps calls to Linux operations rather than mapping them to Windows operations. That's why they're so adamant about drilling it into everyone's heads that "Wine Is Not an Emulator". It's merely a second implementation of the Windows API, not necessarily faster or slower than the original one you get with Windows. (In practice it is slower for some API calls and faster for others. Whether a program runs faster on Wine or Windows depends on which calls it uses.)
Wine is an "emulator" only in the same sense that Windows' TCP stack is an "emulator" of Unix's. It emulates the *idea* by reimplemeting it with fresh code.
Wine won't work on the 'wrong' hardware. It isn't emulating the CPU's instruction set. It's letting the binary run directly on the CPU just like it would for any native process. It's just that the CPU most often used with Linux happens to the same type as the one Windows uses, the x86, so there is no need to emulate the machine (And THAT is where the slowness you usually associate with an emulator comes from. VMware, for example, valued correctness over speed, so it implemented the entire hardware of a fake PC and then ran the guest OS inside that, and THAT was slow because it has to hardware trap all the low level hardware except the CPU and emulate it at the lowest level.). Wine merely provides a library to implement the function calls in the Win32 API that would otherwise not be there on a linux system, so it operates at a much higher level, not trying to emulate hardware at all. That is what makes it faster, but that is also what makes it less than 100% "correct" and causes some programs that depended on Windows' *exact* behavior to fail.
But in a real war your units don't need to be ordered to do each move, each fire, each reaction, by the general in order to not act like moron with a single-digit IQ driven by an AI. The problem with RTS in general, (and I agree with the poster here) is that there is a distinct advantage to doing things yourself instead of letting the AI do it, and so the winner is the one with the best ability to navigate the interface and be in more than one place at a time, not necessarily the one with the best mental ability. The next time you trick yourself into believing that RTS is an actal strategy game, imagine playing against someone who is smarter than you but has muscular dystrophy, and think about who would win. RTS is a video game, not a strategy game. If I want a video game, I'll play a FPS. If I want a strategy game, I'll play something like Civ that has turns.
Tactics on the other hand are the actual methods used to carry out a strategy.
But then for any particular scale N, the word "tactics" becomes just a pseudonym for "the strategy of N-1, the scale one smaller that the one I'm paying attention to." Which is tactic and which is strategy depends on what level of depth the speaker is talking about.
"Wine is not an emulator" refers to the fact that it is not a PLATFORM emulator. Programs running under wine are just programs running on your unix machine, but linked to a special library to handle all their system calls. They are no different in principle than any other program running on the machine.
If you want to use such a broad definition of "emulator", then MS Office is an "emulator" that emulates a typewriter.
And your evidence for saying that the respondants to the poll who answered "MS office" are the same as the people who bash MS is what exactly? Oh, that's right, you don't have any.
What's wrong with "emulation" is that he knows his claim could be shown false it it was allowed.
re: Linux/GNU/X11: And had they continued the trend to today, it would take a pargraph to finish writing the name of the OS. Names must be short, and they *must* necessarily leave out some details to be useful. Otherwise you might as well not bother giving something a name and just use the longhand description each time. So the question is, given that GNU is only responsible for writing *some* of the code for the OS, why should it get top billing up in the name? It's not practical to give everyone who deserves it top billing up in the name, because as mentioned above, names *must* necessarily leave details out or there's no point to having them.
So, in order for the y2k coders to not be grafters bamboozling people out of their money, their projects would have had to fail so you'd notice a problem?
char timebuff[4];
*((int*)timebuff) = time(NULL);
Instead we do stuff like this:
time_t timebuff;
timebuff = time(NULL);
When the system type for time_t is change to something with more than 32 bits, the code just needs a recompile and voilla - it handles dates past 2038. The work is going to be in making sure every program gets recompiled, and in converting saved files that have the date already stored in 32 bits. The ugly part will be if your system depends on third-party stuff in binary form only that you can't upgrade for whatever reason.
Note, I didn't say the problem will be nonexistant, just that it will be easier to fix than y2k.
Yes. That would be much better in that it is actually true, unlike the original quotation.
There is no logical reason to call the stance "I don't think it exists" a belief. It's the default working hypothesis in any question of whether or not something exists, because it is the only situation that is absoltely guaranteed to lead to an utter lack of evidence. There may be other situations that can also lead to a lack of evidence, but "doesn't exist" is the only one that is guaranteed to. Therefore if you start from *any* other stance at all, even one of "maybe", it is completely impossible to ever be swayed from that stance by the facts, even if you are wrong.
Even if other intelligent life doesn't actually exist, those who are looking for it will *never* be able to know that. It's a belief that once adopted, can never go away because it is impervious to assult by real world evidence. It is far better to say, "I don't believe it exists yet" while scanning the skies than to say, "I think it has a good chance of existing" or "It might exist", or "I hold out hope that it exists". It's that sort of nonsense that starts religions.
I have yet to experience this alleged non-intuativeness of Mozilla to which you are referring. I *have* on the other hand, experienced much instability with it.
But then again, I often switch between using different OS'es during the day, so I don't see having to switch GUI contexts ever so slightly as a major hurdle. I'm very used to it.
This doesn't say a thing about windows UI compliance.
And if you had only read the summary and gone no futher then I would understand how you would come away thinking that he was complaining about more than un-Windowsness. But it is clear that you did read the rest of it, so how did you not notice that ALL the examples he gave of why he disliked the gui were saying that it was wrong because it was unlike other Windows apps. (Which isn't even true in the example he gave of the close vs exit option, by the way. In Windows apps, the bottommost thing on the file menu sometimes *is* to close the whole program not just one if its windows.)
But the important thing is that you are describing an actual bug that breaks the program. He was not.
Oops - I got that backward. The first kind I listed is the kind Mozilla cares about, not the second. Damn me for not proofreading.
Am I the only one that sees the irony in complaining that the interface is "unflexible" while simultaneously singing the praises of forcing your app to be exactly like the standard native interface?
Of course there is ambiguity. It's just the other way around then - there can be menu options in the main bar that affect just the one window instead of the whole app.
There are other systems where people would be just as pissed if the last item on the menu *failed* to remove the whole app like they expect. What your whole argument boils down to is, "Mozilla must conform to whatever is already common practice in Windows, regardless of what this may do to people on other platforms. Those other platforms don't matter." This is precisely the attitude that makes it inevitable that MS wins always, no matter what the relative merits of the products may be.
- Apps behave differently from each other on the same platform, but the same App behaves the same way across many platforms.
- Apps behave the same as each other on a platform, but the same App behaves different ways across many platforms.
Mozilla *does* care about consistency in the gui, but it's the second kind, not the first.They care about browsing, not software politics or technical merits.
Then they don't care about browsing. Not in the long term, anyway. They only care about the here and now.
An idealist is merely a pragmatist with a long view of things.