That's precisely when I switched to using Trillian as a client and, more recently, Gaim since switching to Linux.
Gaim also has a Windows port which works nicely. (I run Gaim on Linux at home, but my work involves consulting and custom-modding Windows accounting / inventory / sales / purchasing software, so using anything other than Windows for that would be unjustifiably impractical. Anyone making snide comments about this had better be offering me more money to work on OSS instead, on account of All Babies Must Eat.)
the candidates don't give a crap about the small population areas.
Some people have pointed to the 2000 election as a counterexample. Look at the results on a per-state basis: Gore won some high-population states, Bush won a lot of low-population states, Bush won the majority of electoral votes. (Okay, this assumes that Bush winning Florida was valid, which is a whole other issue that I'm not going to get into.)
I strongly believe that things should continue to be done on some sort of per-state basis. (Attempting to recount Florida was bad enough - imagine if we ever had to recount the entire country!) Proportional allocation of each state's votes would make things a lot more interesting in states that routinely split 60-40 or so.
The performance of any of these strategies is only determined by the opponent strategies that they face, which is arbitrary. It is therefore meaningless to talk of one strategy being 'better' than another - most advanced strategies can beat Tit for Tat given the right opponents.
Players of the card game Magic: the Gathering (where you get to choose which cards go into your deck) refer to this as the "metagame":
Strategy X becomes popular
Cards that defend against X (but are less useful against other strategies) become popular
X becomes less popular
Cards that defend against X become less popular
X becomes popular again
A Google search on "Tit for Two Tats" turns up, among othe things, some excerpts from The Selfish Gene by Richard Dawkins. While Tit for Two Tats would have won the first tournament, it lost the second one, because the metagame had changed.
Programmers in the second tournament had all been provided with the results of the first, including Axelrod's analysis of why Tit for Tat and other nice and forgiving strategies had done so well. It was only to be expected that the contestants would take note of this background information, in one way or another. In fact, they split into two schools of thought. Some reasoned that niceness and forgivingness were evidently winning qualities, and they accordingly submitted nice, forgiving strategies. John Maynard Smith went so far as to submit the super-forgiving Tit for Two Tats. The other school of thought reasoned that lots of their colleagues, having read Axelrod's analysis, would now submit nice, forgiving strategies. They therefore submitted nasty strategies, trying to exploit these anticipated softies!
But once again nastiness didn't pay. Once again, Tit for Tat, submitted by Anatol Rapoport, was the winner, and it scored a massive 96 per cent of the benchmark score. And again nice strategies, in general, did better than nasty ones. All but one of the top 15 strategies were nice, and all but one of the bottom 15 were nasty. But although the saintly Tit for Two Tats would have won the first tournament if it had been submitted, it did not win the second. This was because the field now included more subtle nasty strategies capable of preying ruthlessly upon such an out-and-out softy.
I'm reminded now of Iocaine Powder, the program that won the first Ro-Sham-Bo (iterated rock-paper-scissors) contest. Its strategy was basically the following: "Consider a whole bunch of different strategies, figure out which one would have given me the highest score if I had used it from the beginning, and use that one next turn." I wonder whether that concept has been adapted to the Iterated Prisoner's Dilemma, and if so, how well it holds up?
> IE - College webmail reading (ActiveX)
Have you tried it with Firefox? My work account has Exchange web access and Firefox handles it okay, though it's slightly more awkward than IE.
Heck, get yourself a Gmail account and use that. (*goes to look up the pool-Gmail-invites project at spreadfirefox.com* Dammit, why's the whole site down? They wouldn't be so short-sighted as to get rid of it just because the initial push of 1.0PR is past...)
I thought that even if you let other people review your source code, they're highly unlikely to do so. Isn't that one of the arguments that the anti-OSS crowd march out all the time? Now, Microsoft are doing it, and they're telling people it's for security purposes. Aren't they conceding that this argument is flawed, if they themselves can see some merit in doing so?
Microsoft is letting a clearly targeted set of people review their source code. If they bother answering this charge at all, they'll probably make some over-broad blanket statement like "oh, OSS authors just toss their stuff on SourceForge and think they're done".
Another way to search for the answer to part 2
on
Google's Math Puzzle
·
· Score: 1
They are too busy with their current projects. Gmail has been in beta for almost half a year and it still isn't final.
Diminishing returns. Let's say fifty people are working on Gmail; adding ten more is only going to do a certain amount of good, especially after you subtract the overhead of coordinating those ten with the existing fifty. Put those ten to work on a separate project, on the other hand...
When a harddrive goes out (and they do, they do) you don't replace the whole fricking server. That's stupidity of the highest magnitude.
You might not ever need to upgrade the CPU, but you do want to keep that expensive server operational and in use as long as possible. That means additional storage on occasion and replacing the parts that go bad.
Directly from the article: "...it's a myth that anyone ever fiddles with a production system except to replace a blown part." (emphasis added)
Re:Myth 7: IT Journalists know the field...
on
IT Myths
·
· Score: 1
Any technology is scalable...
Really? I happen to know of a case where someone was fired because they believed this religiously; they insisted that any performance issues the new system might produce could be handled with a server upgrade.
So they upgraded the server, and what do you know - response times fell. From 300 seconds to 90. The system still wasn't usable, and the manager was fired. Perhaps the most embarassing part was the fact that a back-of-the-napkin analysis would have revealed the flaws in the "Use disk space for memory" design.
Directly from the article:
The reality is that there are ways X can be made to scale and ways to screw up trying.
Most IT projects fail...
if you have to redefine words to prove your point, you're probably not telling the truth.
The person who says "Most IT projects fail" is the one redefining words. An imperfect IT project is like an imperfect college essay - you probably get a B or C on it, not an F.
No, perhaps 70% of projects aren't unmitigated failures, but I'll bet that IT projects fare far worse than other industries:
How many unfinished bridges do you know of?
This starts with users having much less of a clear idea of what they want out of an IT project, compared to their idea of what they want out of a bridge. Clear-minded users drive the (failure and/or imperfection) rate right down.
I checked this out (expecting a LastMeasure-type troll and prepared to warn folks about it), but it appears to just be a hit counter. Huh? (Tested with IE 6, Firefox 0.9, Opera 7.11)
Then, he tries to go on to state that there is plenty of software available for Linux. That doesn't address the counterargument. The original assertion is that there are specific apps (let me spell that, s-p-e-c-f-i-c) that are unavailable on Linux that the person is unwilling to lose.
Arguably, users like this are in the minority. How many Joe Users just use their computer for e-mail, web browsing, solitaire, and writing the occasional letter in Word (or Works, or Wordpad, or Notepad)?
For instance, I cannot play Age of Mythology on Linux. I cannot play World of Warcraft on Linux.
The article explicitly admits that games are an exception.
I cannot use MS word on linux.
Arguably, users who actually need MS Word (i.e. OpenOffice isn't close enough) are in the minority.
Hell, test youreselve, read/. at -1. No? Then you want a police webstate.
This is a bad example. So long as you can choose to read at -1, or choose not to, then it's not a police webstate.
Re:Why switching to Linux is not so easy...
on
Moving To Linux
·
· Score: 1
1. GNU is not geared towards the desktop.
2. The filesystem layout is not geared towards the desktop.
I don't see any support for these statements in the rest of your article. If there is some, then please point it out.
3. X11/KDE/GNOME are poor and slow systems compared to everything else. (QNX Neutrino Micro GUI, SkyOS, OS X, Windows, BeOS, you name it)
"Poor and slow" is relative to the type of box. You've got two obvious red flags here, I dunno which is the bulk of your problem:
Old graphics card, buggy driver. If the manufacturer keeps the specs closed, then Linux engineers are stuck with reverse-engineering, and shouldn't be blamed all that much for problems. (If the manufacturer has opened the specs, and Linux engineers have failed to use them properly, then they should be blamed.)
KDE/Gnome are heavyweights. Try something lighter, e.g. Fluxbox, IceWM, WindowMaker, XFCE.
Google site:wikipedia.org "Easter eggs"
Results 1 - 10 of about 37 from wikipedia.org for "Easter eggs". (0.46 seconds)
One of those gives the definition of "Easter eggs" that you're using, and about eight others describe examples (e.g. "about:mozilla" in Mozilla and its descendants). It doesn't appear that any of them actually contain easter eggs, though.
Open new tab as a default rather than a new window, or at least provide the option.
Do you mean "whenever I expect the link to open in the same window, but the link is set up to open in a new window, then compromise and open it in a new tab instead"? After reviewing other replies, that appears to be the case, but it wasn't really clear from your message alone.
If you know you want the link to open in a new tab, then just middle-click it (assuming you have a three-button mouse).
If you're doing customizations for small numbers of clients (as I have been for about ten years), then economy of scale is dwarfed by difficulty of generalization. Of course, as others have pointed out, companies doing customizations are probably also less likely to be affected by the original article's trend toward consolidation.
in your original discussion of ambiguity you *WRONGLY* assume that the ambiguous result would be incorrect. This is an example of the SQL polution the article writer was talking aobut. There are completely valid reasons to want to fetch, in one EXPOSE, both branches of the abmiguous tree. In SQL this compositing is done by the UNION operator.
And you wrongly assume that the ambiguous result would be correct. (That is, you are right in some cases and wrong in others, just as I am right in some cases and wrong in others.)
On the other hand, if I were doing a marketing distribution graph, I would *EXACTLY* want the general answer that one might get from
"EXPOSE Part Nubmer, Zip Code" which would "naturally" find all the Zip Codes that were related to the part number.
I suppose some marketers might want this. The vast majority of my work involves cases in which you want the results from exactly one relation.
EXPOSE Sales Order Number, ZIP Code THROUGH Billing Address
WHERE Sales Order Number == "12345"
As I said in another branch of the discussion, I fail to see how this requires significantly less knowledge than what SQL requires.
SQL, and the HABBITS OF THOUGHT THAT SQL ENGENDERS IN ITS USERS (habbits like those you have demonstrated in your objection), discard whole-scale many of the things that the "relational model" says "ought to be(tm)" stored in the database along with the shema and the data.
Those "things" being the relationships themselves.
As long as the language of access doesn't allow you to think about storing and exploring "relationships" then the RDBMS you are using is just a bunch of lists with Sadly Basic Set Theory Operations on top of it.
I didn't discard the concept of storing relationships in the database. Hell, I pointed out an existing feature (SQL views) that's in the ballpark. I also suggested some tools for implementing such storage in a much more general fashion, and I would welcome the availability of such tools on certain occasions. (The majority of my work involves a small handful of tables that I've used umpteen thousand times before, and thus know like the back of my hand.)
What I'm arguing with is the idea that storing relationships in the database is sufficient to auto-disambiguate ambiguous queries (when disambiguation is desired). I acknowledge now that you didn't intend to put forth that idea.
The first four bases were built on the surface and gradually got covered with snow and ultimately got so deep they became crushed by the weight of ice and had to be replaced
When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built it all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, lad, the strongest castle in all of England!
Nothing in particular, except that knowing enough to specify "Billing Address" is pretty darn close to knowing enough to specify the links yourself:
SELECT SalesOrderNumber, ZIPCode FROM SalesOrder x INNER JOIN Address y ON x.BillingAddressID = y.AddressID WHERE SalesOrderNumber = '12345'
I remain strongly convinced that trying to remain ignorant of the database structure is the wrong route, and that making it easier to understand the structure is the right one. Views, stored procedures, and a list of pair-relationships (whether in code or documentation) are all significant steps toward the latter.
No system, SQL or otherwise, can automatically resolve a question that is conceptually ambiguous.
Again, I point to the example of "give me the ZIP code of sales order #12345". Even if you have a system that efficiently specifies and prioritizes relationships between tables, you've still got to explicitly tell it whether you mean the billing address or the shipping address. And the only ways to do that are (1) tell it to use BillingAddressID rather than ShippingAddressID when linking to the address table, or (2) give up normalization and store BillToZIPCode and ShipToZIPCode directly in the sales order table.
Yes, there are plenty of things that could be added to SQL, or added by tossing out some parts of SQL and revising them. I'm just pointing out that there are also plenty of things that absolutely require the designer to provide more information.
The problem with auto-determining the link from A to B is that sometimes the link is ambiguous. Consider the following:
Address -> ZIP Code Customer -> Billing Address Sales Order -> Sales Order Number Sales Order -> Customer Sales Order -> Shipping Address
EXPOSE Sales Order Number, ZIP Code WHERE Sales Order Number == "12345"
Are you asking for the ZIP code where the physical goods should be sent, or the ZIP code where the bill should be sent? The system has no way of knowing.
What you could do is create a meta-system that determines all the possible choices and lists them, then you pick the correct one and it gives you a template of a SQL query to copy+paste. You would need the following:
A system table that contains the definition of each application table (already exists)
A system table that contains the pair-relationships between tables
Appropriate indexes on these system tables
A depth-first search program that reads these system tables, and handles recursive relationships correctly
You still need to understand basic RDB concepts - PHBs wouldn't know which of the options presented to them is correct. What this would do is allow you to grok a specific RDB with less grunt work on your part, at the expense of more grunt work on the part of the RDB's creator.
Don't waste time trying to auto-determine pair relationships based on field names, either. Even if the RDB's creator makes an effort to keep field names identical, any non-trivial system is practically guaranteed to have (1) fields that have different names but should still be linked, (2) fields that have the same name but should not be linked (e.g. you're buying widgets from a vendor in ZIP code 98765, and selling whatsits to a customer in ZIP code 98765, but there is no relationship beyond the ZIP codes just happening to be the same), or (3) both. The most elegant approach is, when adding a new table to the design, also adding its relationships ("field X in this new table is linked to field Y in the existing table Z").
Slashdot Mirror
(NOV 27)
Gaim also has a Windows port which works nicely. (I run Gaim on Linux at home, but my work involves consulting and custom-modding Windows accounting / inventory / sales / purchasing software, so using anything other than Windows for that would be unjustifiably impractical. Anyone making snide comments about this had better be offering me more money to work on OSS instead, on account of All Babies Must Eat.)
I strongly believe that things should continue to be done on some sort of per-state basis. (Attempting to recount Florida was bad enough - imagine if we ever had to recount the entire country!) Proportional allocation of each state's votes would make things a lot more interesting in states that routinely split 60-40 or so.
- Strategy X becomes popular
- Cards that defend against X (but are less useful against other strategies) become popular
- X becomes less popular
- Cards that defend against X become less popular
- X becomes popular again
A Google search on "Tit for Two Tats" turns up, among othe things, some excerpts from The Selfish Gene by Richard Dawkins. While Tit for Two Tats would have won the first tournament, it lost the second one, because the metagame had changed. I'm reminded now of Iocaine Powder, the program that won the first Ro-Sham-Bo (iterated rock-paper-scissors) contest. Its strategy was basically the following: "Consider a whole bunch of different strategies, figure out which one would have given me the highest score if I had used it from the beginning, and use that one next turn." I wonder whether that concept has been adapted to the Iterated Prisoner's Dilemma, and if so, how well it holds up?> IE - College webmail reading (ActiveX) Have you tried it with Firefox? My work account has Exchange web access and Firefox handles it okay, though it's slightly more awkward than IE. Heck, get yourself a Gmail account and use that. (*goes to look up the pool-Gmail-invites project at spreadfirefox.com* Dammit, why's the whole site down? They wouldn't be so short-sighted as to get rid of it just because the initial push of 1.0PR is past...)
The On-Line Encyclopedia of Integer Sequences
Google site:wikipedia.org "Easter eggs" Results 1 - 10 of about 37 from wikipedia.org for "Easter eggs". (0.46 seconds) One of those gives the definition of "Easter eggs" that you're using, and about eight others describe examples (e.g. "about:mozilla" in Mozilla and its descendants). It doesn't appear that any of them actually contain easter eggs, though.
If you know you want the link to open in a new tab, then just middle-click it (assuming you have a three-button mouse).
If you're doing customizations for small numbers of clients (as I have been for about ten years), then economy of scale is dwarfed by difficulty of generalization. Of course, as others have pointed out, companies doing customizations are probably also less likely to be affected by the original article's trend toward consolidation.
What I'm arguing with is the idea that storing relationships in the database is sufficient to auto-disambiguate ambiguous queries (when disambiguation is desired). I acknowledge now that you didn't intend to put forth that idea.
No system, SQL or otherwise, can automatically resolve a question that is conceptually ambiguous.
Again, I point to the example of "give me the ZIP code of sales order #12345". Even if you have a system that efficiently specifies and prioritizes relationships between tables, you've still got to explicitly tell it whether you mean the billing address or the shipping address. And the only ways to do that are (1) tell it to use BillingAddressID rather than ShippingAddressID when linking to the address table, or (2) give up normalization and store BillToZIPCode and ShipToZIPCode directly in the sales order table.
Yes, there are plenty of things that could be added to SQL, or added by tossing out some parts of SQL and revising them. I'm just pointing out that there are also plenty of things that absolutely require the designer to provide more information.
What you could do is create a meta-system that determines all the possible choices and lists them, then you pick the correct one and it gives you a template of a SQL query to copy+paste. You would need the following:
- A system table that contains the definition of each application table (already exists)
- A system table that contains the pair-relationships between tables
- Appropriate indexes on these system tables
- A depth-first search program that reads these system tables, and handles recursive relationships correctly
You still need to understand basic RDB concepts - PHBs wouldn't know which of the options presented to them is correct. What this would do is allow you to grok a specific RDB with less grunt work on your part, at the expense of more grunt work on the part of the RDB's creator.Don't waste time trying to auto-determine pair relationships based on field names, either. Even if the RDB's creator makes an effort to keep field names identical, any non-trivial system is practically guaranteed to have (1) fields that have different names but should still be linked, (2) fields that have the same name but should not be linked (e.g. you're buying widgets from a vendor in ZIP code 98765, and selling whatsits to a customer in ZIP code 98765, but there is no relationship beyond the ZIP codes just happening to be the same), or (3) both. The most elegant approach is, when adding a new table to the design, also adding its relationships ("field X in this new table is linked to field Y in the existing table Z").