I haven't seen anybody around here except you claim that Java is a "multithreading-safe language". I can't even imagine what such a concept is.
Refer to the post to which I originally responded:
...and get yourself a technology [sun.com] designed for multi-threaded programming.
What does that mean -- "designed for multi-threaded programming" -- except that the language itself has native capabilities to support multithreading? Java does have such capability, but my argument is that the native capability is insufficient, dangerous, and inefficient. I say it is dangerous because Java "encourages" you to believe that you can get safety thru willy-nilly use of those synchronizing features which are built into the language; in reality, the only real safety comes from a deep understanding of multithreaded programming and proper use of O/S-level sychronizing primitives (or in the case of Java, the primitives supplied by the runtime).
The only claims I've seen by others is that it is easy to do multithreaded coding in Java, because the language was designed with it in mind. For example, consider this:
synchronized (myMutex) {... }
"myMutex" can be any object. "synchronized" is syntax. Only the thread that "won" the myMutex object will be running the code inside the braces; any other thread trying to synchronize on myMutex will block. Note that if the code in that block indirectly tries to synchronize on myMutex again, it will quietly succeed, which is nice. Also, if you get something like a null pointer exception inside that block, you can still rest assured that myMutex will be automatically un-owned when you exit the block.
Compare that to corresponding C++ code:
{
Lock lock(someMutex);
do stuff;
}
Does the same thing. If an exception kicks you out, the mutex unlocks. You can use a mutex that allows multiple locking by the same thread, if you like. Etc. No need for any native language support here (beyond what C++ offers). What about this example lets Java claim native multithreading support (as compared to C++, that is)?
The reason people think of Java-the-language as having multithreading support is that you can declare things (objects or what have you) where all references result in automatic (hidden) mutex (or other synchronization primitive) protection. That, in my book, would qualify as native language support. But, I argue, that is very bad programming practice. In laying out a multithreaded program, the very core of the design should revolve around those primitives. There should be a very small number of these, used in a disciplined way, so that you can maintain a deep understanding of what's going on. Supplying a built-in way to have E-Z mutexes all over the place is just a bad idea.
You could say that, No, Java has native multithreading because, in effect, Java is a miniature O/S, and supplies its own threading and synchronization primitives. Or, it has native multithreading because of the cool debugging features for multithreaded programs. But then you're disavowing the language-level support. What you're then saying is that Java has multithreading primitives (like all major OS's) and a great debugger. There's nothing really special about the _language_ which makes it especially suitable for expressing multithreaded logic (beyond what C++ offers). In fact, because C++ has much tighter semantics about object destruction, I think C++ is more suitable than Java.
In short, C++ (combined with a decent underlying O/S and development environment) is just as much a "technology designed for multithreaded programming". There's nothing about support for multithreading which is particularly compelling about Java vs. C++ (that I'm aware of). There are things about C++ which make it superior, however (object destruction semantics).
No, Java does not give every structure a mutex (as if Java even had structures). It only creates a mutex if synchronization is used on an object, so if you never use locking there are no locks.
So, if you're doing multithreaded programming with Java, you're "encouraged" to have helter-skelter mutexes (i.e. a mutex on each "structure", aka whatever-you-like-to-call-it). That's dangerous and inefficient. On a surface level, it seems kinds of nice. Because of that feature, you can say "Java is multithreading-safe" -- threads will take turns accessing members. And yet, your program is unsafe against deadlock. Indeed, the profusion of mutexes would tend to _increase_ the likelihood of deadlock, in my opinion. Nothing but actually understanding what you're doing will get you true safety.
In my experience, only a very small number of mutexes are required (often one will suffice). One per structure is way too much. It makes it next-to-impossible to have a deep understanding of the program logic (at a multithreading level).
In short, Java's language-supported-automatic-one-mutex-per-structu re shotgun approach may have marketing cachet, but it actually sucks (IMHO, etc).
Java's "builtin thread saftey" is simply a poor hack. The idea is to give _every_ structure a mutex. Any access to the structure requires a mutex lock.
First off, that in itself will not prevent deadlock. Secondly, it's damned inefficient.
Look: there's just no way around it. If you want to do effective (i.e. low bug, high performance) multithreaded programming, you simply have to understand what you're doing. Ultimately, the tools of your trade will be mutexes, condition variables, semaphores, etc -- the O/S primitives. Don't rely on your programming language to "automatically" use these for you, blasting out mutexes machinegun-style. Instead, figure out the logic of your program. You probably need only a small number of mutexes.
A key to effective multithreaded programming is to adhere rigidly to certain programming practices. It must _NEVER_ be the case that 2 threads have write access to a given item at the same time. Duh. But you can use fancy programming tricks to, in effect, automatically add run-time assertions to your code which assure that this practice is being adhered to. In production mode, you remove these runtime assertions.
Another good practice is, if you really need to have multiple mutexes, to arrange them into a hierarchy. When a top-level mutex is locked, no other mutex can be locked. When a second-level mutex is locked, only top-level mutexes can be locked. Etc. This hierarchy can be verified at runtime, in debug mode. Adhering to this regime will go a long way to removing the possibility for deadlocks.
Bottom line: you really have to know what you're doing in order to write good multi-threaded code. You should take the time to really study that problem space. An excellent book I've found for this purpose is "Concurrent Programming in ML". (I know -- nobody uses ML. So what? Learn the language just for the purpose of understanding the book. Then, you can apply your knowledge to any domain you're working in).
According to your logic, it would be impossible to ever disprove the existence of God via any scientific method. It amounts to the same kind of thinking which says the earth really is 7k yrs old -- God put the dino bones there to test our faith. The same kind of thinking allows a person of faith to believe anything they want (for example, that there is a multitude of virgins waiting in heaven for him if he slaughters thousands of civilians).
What if the study took special pains, so that the people praying didn't know they were part of the study, and so that the people being prayed for were near-and-dear? Would that ameliorate your concerns?
I'm guessing it wouldn't. You would doubtless say (assuming that prayer was again shown to be ineffective) that God may have decided not to reveal himself, and was willing to sacrifice the intended prayer beneficiaries in order to prevent nosy scientist types from proving his existence.
First, don't listen to the anti-C++ naysayers. C++ can be used to be complex, highly efficient, and bug-free software. It can also be used to make a horrible, inefficient, and bug-ridden mess, if you don't do it right.
Some basic ideas:
First: study some of the C++ "best practices" type of books (Exceptional C++, Effective C++, etc). Don't do any production C++ programming until you have mastered these. There are many invaluable tips.
Second: stay away from fancy object hierarchies. Try to use template mechanisms instead of object mechanisms. Template code is fast, and has superior safety compared to object-style code.
Third: stay away from explicit allocation. Use STL containers (and other containers from trusted libraries). Going along with this concept: avoid using pointers. I find it is only rarely necessary to use pointers or to allocate things (e.g. Object *x = new Object();). Almost always, I can use a container (e.g. vector x).
Fourth: If you're doing any multithreaded programming (including across different machines) -- and you are, from the description of your problem -- then you should spend time understanding threading issues. Threads (whether in Java or any other programming environment) carry their own very nasty bug risks. Sure, you can avoid many types of memory allocation problems with a "managed code" environment. But what about deadlock? There's nothing for it but to really understand threading. A book I found to be excellent in this regard was Concurrent Programming in ML. Yes, it uses ML. But it's teaching you about threading issues, not C++ issues. Concurrent ML happens to be a very succinct language for its purpose. There may be excellent C++ books which address threading issues, but I haven't seen any.
Fifth: a minor-ish tip: when writing multi-threaded C++ code, don't ever use global objects -- only use pointers to global objects. This point may be covered in one of the above C++ books I mentioned, but I don't recall it. The problem is destruction -- when a program ends, you don't know in which order the threads will die, and when the global objects will get destroyed. So, use pointers to global objects, and destroy them explicitly if you need to (I rarely bother).
Sixth: Look at the Boost libraries (boost.org).
Well, those are some ideas. I've found that C++ does not suffer from bugginess, despite its reputation. There's a perception that C/C++ code makes it easy to make memory-related bugs (accessing invalid memory, failing to free garbage, etc). While the reputation is well deserved for C, and is doubtless deserved for badly-written C++, it is not deserved for well-written C++. Only rarely do I encounter memory-related bugs (or any serious bugs at all). It's all about coding practices, and using STL-type containers instead of doing memory allocation yourself.
"You claim that this man is innocent, but you cannot be trusted since you are a criminal as well."
That's a valid line of reasoning. Say that in court, person A gives testimony that he saw person B killed person C. Person A turns out to be a convicted felon. Can he be trusted? Perhaps not. It's not irrelevant. On the other hand, if the assertion that person A is a criminal can't be backed up, then the ad-hominen attack would look invalid.
"You feel that abortion should be legal, but I disagree because you are uneducated and poor."
OK, that's a pretty irrelevant ad-hominem attack.
"He's physically addicted to nicotine. Of course he defends smoking!"
If the person is, indeed, addicted to nicotine (via smoking), then that's a pretty reasonable line of attack, don't you think? After all, people have a strong tendency to rationalize their actions, no matter how self-destructive.
"Tobacco company representatives are wrong when they say smoking doesn't seriously affect your health, because they're just defending their own multi-million-dollar financial interests."
Indeed! That's a very reasonable line of attack. It's obvious that tobacco companies have a conflict of interest here. Tho it's reprehensible, it's easy to imagine that a tobacco company cares about its own profits more than it cares about any health effects on its customers.
The fact that you're attacking his past actions instead of the argument he made is telling. I think he has a point. Would you like to reply to his actual argument instead of just attacking the man?
As demonstrated above, ad-hominem attacks are not all irrelevant. The point being made is that this person claims to have a principled position: intellectual (and other) property rights should be respected. But the force of that argument is diminished if it turns out the same person is OK with stealing from other people when it suits him. Where's the principle? It starts to look like: "I'm in favor of things which make me more money, and I'm against things which make me less money". Not quite as high-sounding a principle.
Cross-platform GUI RAD (for GTK+, etc): wxDesigner
on
Why Use GTK+?
·
· Score: 5, Informative
Are there any cross platform (linux, mac, windows) GUI RAD tools ala Builder, yet?
Yes -- wxDesigner is a very nice RAD for use with the wxWidgets GUI-building environment. wxWidgets is a cross-platform GUI framework which uses native widgets. On Linux, it uses GTK+. On Windows, it uses Windows widgets. On Mac, it uses Mac widgets. There are other somewhat-supported platforms. This approach contrasts with that of the Qt framework -- another cross-platform builder (which is excellent), which implements all its own widgets on each platform. Also unlike Qt, wxWidgets is not bound by the GPL -- you're pretty much free to do as you like with it (i.e. incorporating it into commercial apps, without the requirement that you release your source code, or pay any licensing fee). wxDesigner is a very nice GUI RAD builder for wxWidgets. It's not free, but it's cheap. You definitely get your money's worth.
Do you use Linux? If you did, you would surely know that the way it works is this: Each distro takes care of compiling all the thousands of apps for you. So, for you, the end user, the apps are binary -- you don't have to worry about any messy compatibility details. Only a small number of experts are needed, to build the binary app for the given distro.
It is not necessary (or even desirable) to have One True Linux. The current system gives you all the ease of installation of a binary package, but with the flexibility of source code. The system of having _only_ a binary release, and no source code, is a limitation of the Windows world. That's why free software is slowly-but-surely eclipsing Microsoft.
Linux is like a many-headed beast. Or a rapidly-evolving cold virus. The distros are in competition with eachother as much (or more) than with Microsoft. Competition provides the fuel for evolution. The distros have become just amazingly powerful, in only the last few years -- each trying to eclipse the other. And all the distros are is the top layer. At each layer, you have the same thing -- lots of competing systems, vying to best eachother (Gnome vs KDE vs..., MySQL vs PostgreSQL vs..., Mozilla vs Konqeror vs..., it goes on and on). Microsoft, by comparison, is completely stuck with their one tired old stack. They're becoming ossified.
Wny not just a bunch of PC's, each with 6x400GB drives? That's 2.4 TB per PC. 25TB is only 10 PC's -- 60 drives. What's the big deal just using NFS? Seems like not a very difficult target to hit.
Now, going to 1 PB -- that would be 400 PC's. At this point you've left the domain of something which is all that simple. Even so, if you use wake-on-LAN, you could no doubt get away with having 400 PCs, without special power, heating/cooling, etc -- as long as you were able to control the flow of information, so that no more than tiny fraction of the PCs would be on at a given time. And, of course, you'd have significant latency -- waiting for a node to wake. Since I don't know your requirements, I can't say how significant a barrier this would be.
You would get into a reliability issue with 400 PC's. Again, it would be useful to understand something about your problem space. It's possible that a butt-simple method would work for you.
Really, the difficulty/cost of the implementation is a direct function of data flow. If your data flow requirements are tiny, then the solution could be quite cheap.
Of course, even with low outgoing data flow, you'll still have your hands full just filling up the disks in the first place! Consider this: a typical cheap hard drive on a cheap PC can sustain, say, 5MB per second. If one PC is handling 2.4 TB, that would take 5-6 days to fill up. I suppose it would be reasonable to fill up, say, 10-20 PCs at a time. For the 25 TB system, you could fill it up in a week, easy. But for the 1 PB system, filling 20 PCs at a time, it would take you 3 months! Still, that might be OK, depending on your requirements...
And if that isn't enough, consider the situation when lexmark gives you a prebate. They are paying you (via a discount) for a service (the return of the empty cartridge) by taking the discount and failing to do so, you are doing the same thing as if a vendor took your money and didn't give you the product.
And you buy into this reasoning? What a smokescreen! After all, Lexmark is only asserting that they've given you a discount.
In my primitive understanding (as a commoner), when I buy something, generally speaking, I have the right to use it in any way I see fit (with a few notorious exceptions, e.g. software, for which I supposedly buy a "license", rather than actually owning it outright). But with the above reasoning, a manufacturer can change any product at all into one of these special-case products, where your use of the product is restricted:
A. Suppose item price is $N. Change the price to $N = $M - $D, where $D is a fictional discount.
B. Claim that, in consideration of $D, the purchaser agrees to onerous term T.
Presto! With this disingenuous reasoning, what we commoners have, until now, been able to take for granted about our rights, can suddenly be stripped away arbitrarily.
Courts are supposed to be smarter than that -- they're to see thru such specious reasoning.
Just get hundreds of gigs of disk (probably you'll need at least 1,000), then use rsync to mirror them. I've used this system for some years, with an amount of data on the order of what you're talking about.
I have multiple mirrors, and I rotate between the mirrors, so that on a given day, I have a backup which is 1 day old, 2-4 days old, and a week or so old. On top of that, I periodically take mirrors out of circulation, say, every month or so.
Yes, I have alot of hard drives. However, drives are cheap. Losing data is expensive. Manually doing backups is expensive (both because of the time it takes you, and because of the cost of screwing up, which is likely). Tapes are useless -- you can never know if they really work. Same with CD-ROMs/DVDs. Tapes & CD's are also useless because their capacity is way too low -- it's the same as a manual backup.
A vast harddrive array is clearly the way to go. Everything is automated -- hence, very low chance of screwing up. Also, you know right away if a hard drive doesn't work. So, you can be sure of several working backup copies to fall back on.
You'll no doubt find that you want multiple computers to house all these drives...
The optimal move is a function of the current game state. Hence, your optimal move is a function of the cumulative moves you and your opponent make.
Chess is not a "solved" game (and even if it were, only a computer would be able to execute perfect play). Why do people select defences other than the optimal one? Because only near the end of a game can anyone perfectly evaluate all the possible lines of play, and thus be able to choose the optimal move(s).
If both sides play perfectly, then every possible game state is already decided as either White wins, Black wins, or draw. It's even possible that the starting position is a White win (or even, I suppose, tho less likely, a Black win). Most likely, it's a draw. But nobody can say for sure.
Which brings me to my Controversial Thesis: chess is a game of luck. Why? Because whenever you make a move whose consequences you can't fully evaluate (which is generally the case in chess, or any other interesting game), then you are making a blind choice (not necessarily totally blind -- the more skilled you are, the less blind your move is -- but still at least partly blind). Whenever you do that, you are trusting to luck. The move may turn out to be either better or worse than you hoped. In the former case, you're lucky; in the latter, you're unlucky.
I don't expect you to agree with my Controversial Thesis -- I haven't yet found anyone who agrees with me that chess is a game of luck!
Why is it a scam? They claim that you will get $N back if you mail in some form, causing the price to be $N less. Then they go ahead and send you the $N.
Some people are claiming rebates are a scam because the rebate companies don't actually send you the $N, even when you follow the agreed-upon instructions. If that happened, I'd agree it was a scam. But in my experience, that doesn't happen. Hence, it is not a scam. Apparantly _annoying_ to many people, but not a scam.
We buy alot of stuff (often via Slickdeals.net) at tremendous prices, and typically involving 1+ rebates. I'd say we submit about 20+ rebates a year. Failing to receive a rebate is a very rare occurrance -- maybe 1 a year. What used to happen, before we became more careful, is that we screwed up in various ways: waited too long, failed to follow instructions, etc. But when we've done everything right on our end, we pretty much always get the rebate.
So, no, it is not a scam, in our experience.
The purpose of a rebate is to allow for a flexible price, while not _appearing_ to. A business, in general, can optimize the amount of money it makes by charging a given person the maximum amount of money that person is willing to pay. Ever see Tin Man? I love the exchange:
Q "So how much is this car?"
A "How much have you got?"
or something like that. With a rebate, only those people who most want the low price will go to the trouble. The price after rebate is set so that you hopefully don't _lose_ money when people return the rebates. The margin comes from the people who don't return them. Classic. I don't see anything wrong with it (unless the business fails to make a profit -- but that's their problem).
Here's another mechanism a business could use to implement flexible pricing (which you may not like as much) how about if you had to haggle for everything you buy?
Clerk: "This here one's a real _beauty_ of a TV. Best they make!"
I tried out MythTV, but, as you would have predicted, it indeed proved to be a FPITA. I also tried out Freevo, which was similarly painful.
However, what I found was that it was pretty darned easy to write my own pvr app. I use the Hauppauge PVR-250. I can't recall if I needed to install a driver -- seems to me the driver came with my Mandrake. On bootup, you get/dev/video0. Use a utility to set the channel, then try cat'ing that to a file, and you'll get something you can play with mplayer:
(the utility came from the IVTV package -- that's the driver I'm using for the Hauppauge).
So, as you can imagine, it's quite easy to write a little command-line app which just sits there snarfing stuff off/dev/video0. Which is what I did. The hard part is the programming.
On that score, MythTV was pretty nice. It uses a MySQL database to store listings which it gets via a free web service provided by Data Direct (or ZapIt, or something like that -- I forgets the details..) You just need to run mythfilldatabase periodically, via cron.
Then, my little command-line app (which runs continuously in the background) reads the MySQL database, and my own control file, periodically, and refigures what it's going to program and in what order.
Not for everyone, I admit. But it was surprisingly easy for me to get it all working. And now, I have what _I_ consider to be The Ultimate PVR Which Does Exactly What I Want It To Do (except when it hits a bug, of course...)
That, to me, is the beauty of Linux!
Re:One of my favorites is "Scotland Yard"
on
Fun Tabletop Games?
·
· Score: 1
Agreed - Scotland Yard is an immensely fun game. We just dusted it off a couple of days ago -- to teach our 8 yr old daughter -- and we've played it several times since then! Lots of fun -- very dramatic. It's really a 2-player game, but it works well to have teams of people (either controlling the robber or the police).
Where to find info (and some personal favs)
on
Fun Tabletop Games?
·
· Score: 4, Informative
First, some suggestions on places to find info on what games are good:
The newsgroup rec.games.board is a great source of info on enthusiasts' opinions on board games. Someone maintains a database of ratings of games, as rated (mostly, or originally) by readers of the newsgroup. Search for "INTERNET TOP 100 GAMES LIST" (posted to the newsgroup every 2 weeks). Here's the current top 10, along with rating (1-10 scale) -- here's the link: http://scv.bu.edu/~aarondf/Top100
1 8.494 Puerto Rico
2 7.865 Euphrat & Tigris
3 7.756 Die Siedler von Catan
4 7.742 Die Fursten von Florenz
5 7.504 Modern Art
6 7.503 El Grande
7 7.451 Carcassonne
8 7.409 Ohne Furcht und Adel
9 7.399 Goa
10 7.387 Vinci
You'll see two of the games you mentioned on the list - Carcassonne and Settlers of Catan (note that the bulk of the best boardgames are German in origin -- the original German names are used in the list). I would guess that if you liked Carc and Settlers, that you match the taste profile of the contributors to the list fairly well, so you'd probably like many of the games on the list.
I've played maybe half the games on the top 10. Personally, I like Settlers, Euphrat & Tigris, and Modern Art particularly well.
One important question is: how many players do you have? 4 seems to be considered to be the optimal number for multi-player games (which are the most fun). If you have a different number, then there are specialized lists you should refer to. However, from your post, it sounds like you have several players, so the above list should be suitable.
Another question is: what type of games do you like? There are economics-style (e.g. Settlers), bidding-style (e.g. Modern Art), deal-making (e.g. Chinatown), path-connection style (e.g. Streetcar), war games (e.g. Axis & Allies), race games (e.g. Detroit-Cleveland Grand Prix), etc. etc. I guess you'd call this the genre.
Another thing to look for is the game designer. If you like a book by a certain author, you're likely to like other books by the same author. It's the same with games. Settlers was designed by Klaus Teuber -- a prolific game designer. So, you might look for other Teuber games. Many of the top-rated games were designed by Reiner Knizia -- I like just about every game of his which I've tried.
Another consideration is the complication of the game. You've mentioned Axis&Allies, which is relatively simple, and Settlers & Carc, which are moderately complex. Some of the games on the Top 100 list are fairly complex -- generally, at least as complex as Settlers and Carc.
Then there's game duration. If you like Axis & Allies, then you're probably not turned off by long-playing games. I'd think most games on the list would be OK.
There's a great website for boardgame enthusiasts, which you'd probably find useful in looking for new games: Boardgame Geek -- http://www.boardgamegeek.com
Finally, bearing all the above in mind, and considering the little scraps of information I have about you and your group, my tenuous suggestions:
I think you have maybe 4-6 people in your group. You have a taste for long games, and war and deal-making are appealing themes for you. Two classic games stand out in this category: Civilization (the board game which inspired the computer game), and Diplomacy. These are games which I would _most_ love to play, if I had a large enuf group of like-minded people available, and an unlimited amount of time. If you try Civilization, I recommend Advanced Civ over Civ.
I envy you, just starting to really delve into boardgames, with a group of enthusiastic players. You have some really great gaming to look forward to!
Taxing everything but possession (income, capital gains, sales, value added, etc) is just a way to tax the creative process.
Well, there is one exception to this rule of no taxation of possession -- and that is the patent maintanence fee.
Possessions/assets are taxed, in various ways:
Most obviously, real estate tax is assessed on the value of the real estate. This is a direct tax on assets. Real estate makes up a very large proportion of the nation's net worth, so this is not an insignificant asset tax.
Less obviously, inflation provides a built-in tax on assets. In particular, if you earn, say, 4% in a bank account, the govt taxes you on that 4%, even tho inflation might be 3%. The tax on the 3% which is inflation is, in effect, an asset tax. If you keep your money under your matress, to avoid paying tax, then inflation itself eats your money away.
I hear alot of complaining from Demo-types (mostly coastal, no doubt), about how disenchanted they are with the "red states" taking over.
Consider: the whole American system of government is _designed_ to allow for big differences in how each State runs its affairs. Back in the Civil War days, the _Dems_ were the champions of States Rights (for bad reasons, but still...) -- it was the 'Pubs who wanted strong centralized government. Perhaps now, the "old North" should come around -- appreciate the wisdom of decentralization. Let the red states have their Christian conservative style of government (outlaw abortion, teach creationism, have prayer in public schools, capital punishment, etc). The coastals (aka blue states) can have a more _liberal_ style (gay marriage, medical marijuana, etc.) The States would then be in (more) competition with eachother -- a true marketplace of ideas.
That is, this _could_ all happen if States Rights were truly respected. Unfortunately, the central government takes in too much tax revenue, and so it has too much power. The Supreme Court has also done its part to dilute the power of the States.
When you have a big country like the US, strong central government -- winner takes all -- leads to excessive political friction. The regional differences are too great.
Slashdot Mirror
Refer to the post to which I originally responded:
What does that mean -- "designed for multi-threaded programming" -- except that the language itself has native capabilities to support multithreading? Java does have such capability, but my argument is that the native capability is insufficient, dangerous, and inefficient. I say it is dangerous because Java "encourages" you to believe that you can get safety thru willy-nilly use of those synchronizing features which are built into the language; in reality, the only real safety comes from a deep understanding of multithreaded programming and proper use of O/S-level sychronizing primitives (or in the case of Java, the primitives supplied by the runtime).
Compare that to corresponding C++ code:
Does the same thing. If an exception kicks you out, the mutex unlocks. You can use a mutex that allows multiple locking by the same thread, if you like. Etc. No need for any native language support here (beyond what C++ offers). What about this example lets Java claim native multithreading support (as compared to C++, that is)?
The reason people think of Java-the-language as having multithreading support is that you can declare things (objects or what have you) where all references result in automatic (hidden) mutex (or other synchronization primitive) protection. That, in my book, would qualify as native language support. But, I argue, that is very bad programming practice. In laying out a multithreaded program, the very core of the design should revolve around those primitives. There should be a very small number of these, used in a disciplined way, so that you can maintain a deep understanding of what's going on. Supplying a built-in way to have E-Z mutexes all over the place is just a bad idea.
You could say that, No, Java has native multithreading because, in effect, Java is a miniature O/S, and supplies its own threading and synchronization primitives. Or, it has native multithreading because of the cool debugging features for multithreaded programs. But then you're disavowing the language-level support. What you're then saying is that Java has multithreading primitives (like all major OS's) and a great debugger. There's nothing really special about the _language_ which makes it especially suitable for expressing multithreaded logic (beyond what C++ offers). In fact, because C++ has much tighter semantics about object destruction, I think C++ is more suitable than Java.
In short, C++ (combined with a decent underlying O/S and development environment) is just as much a "technology designed for multithreaded programming". There's nothing about support for multithreading which is particularly compelling about Java vs. C++ (that I'm aware of). There are things about C++ which make it superior, however (object destruction semantics).
That's fine. But then, what feature of Java, that you make use of, qualifies it as a "multithreading-safe language"?
So, if you're doing multithreaded programming with Java, you're "encouraged" to have helter-skelter mutexes (i.e. a mutex on each "structure", aka whatever-you-like-to-call-it). That's dangerous and inefficient. On a surface level, it seems kinds of nice. Because of that feature, you can say "Java is multithreading-safe" -- threads will take turns accessing members. And yet, your program is unsafe against deadlock. Indeed, the profusion of mutexes would tend to _increase_ the likelihood of deadlock, in my opinion. Nothing but actually understanding what you're doing will get you true safety.
In my experience, only a very small number of mutexes are required (often one will suffice). One per structure is way too much. It makes it next-to-impossible to have a deep understanding of the program logic (at a multithreading level).
In short, Java's language-supported-automatic-one-mutex-per-struct
Java's "builtin thread saftey" is simply a poor hack. The idea is to give _every_ structure a mutex. Any access to the structure requires a mutex lock.
First off, that in itself will not prevent deadlock. Secondly, it's damned inefficient.
Look: there's just no way around it. If you want to do effective (i.e. low bug, high performance) multithreaded programming, you simply have to understand what you're doing. Ultimately, the tools of your trade will be mutexes, condition variables, semaphores, etc -- the O/S primitives. Don't rely on your programming language to "automatically" use these for you, blasting out mutexes machinegun-style. Instead, figure out the logic of your program. You probably need only a small number of mutexes.
A key to effective multithreaded programming is to adhere rigidly to certain programming practices. It must _NEVER_ be the case that 2 threads have write access to a given item at the same time. Duh. But you can use fancy programming tricks to, in effect, automatically add run-time assertions to your code which assure that this practice is being adhered to. In production mode, you remove these runtime assertions.
Another good practice is, if you really need to have multiple mutexes, to arrange them into a hierarchy. When a top-level mutex is locked, no other mutex can be locked. When a second-level mutex is locked, only top-level mutexes can be locked. Etc. This hierarchy can be verified at runtime, in debug mode. Adhering to this regime will go a long way to removing the possibility for deadlocks.
Bottom line: you really have to know what you're doing in order to write good multi-threaded code. You should take the time to really study that problem space. An excellent book I've found for this purpose is "Concurrent Programming in ML". (I know -- nobody uses ML. So what? Learn the language just for the purpose of understanding the book. Then, you can apply your knowledge to any domain you're working in).
"Dangerous" is the word I'd use.
According to your logic, it would be impossible to ever disprove the existence of God via any scientific method. It amounts to the same kind of thinking which says the earth really is 7k yrs old -- God put the dino bones there to test our faith. The same kind of thinking allows a person of faith to believe anything they want (for example, that there is a multitude of virgins waiting in heaven for him if he slaughters thousands of civilians).
What if the study took special pains, so that the people praying didn't know they were part of the study, and so that the people being prayed for were near-and-dear? Would that ameliorate your concerns?
I'm guessing it wouldn't. You would doubtless say (assuming that prayer was again shown to be ineffective) that God may have decided not to reveal himself, and was willing to sacrifice the intended prayer beneficiaries in order to prevent nosy scientist types from proving his existence.
First, don't listen to the anti-C++ naysayers. C++ can be used to be complex, highly efficient, and bug-free software. It can also be used to make a horrible, inefficient, and bug-ridden mess, if you don't do it right.
Some basic ideas:
First: study some of the C++ "best practices" type of books (Exceptional C++, Effective C++, etc). Don't do any production C++ programming until you have mastered these. There are many invaluable tips.
Second: stay away from fancy object hierarchies. Try to use template mechanisms instead of object mechanisms. Template code is fast, and has superior safety compared to object-style code.
Third: stay away from explicit allocation. Use STL containers (and other containers from trusted libraries). Going along with this concept: avoid using pointers. I find it is only rarely necessary to use pointers or to allocate things (e.g. Object *x = new Object();). Almost always, I can use a container (e.g. vector x).
Fourth: If you're doing any multithreaded programming (including across different machines) -- and you are, from the description of your problem -- then you should spend time understanding threading issues. Threads (whether in Java or any other programming environment) carry their own very nasty bug risks. Sure, you can avoid many types of memory allocation problems with a "managed code" environment. But what about deadlock? There's nothing for it but to really understand threading. A book I found to be excellent in this regard was Concurrent Programming in ML. Yes, it uses ML. But it's teaching you about threading issues, not C++ issues. Concurrent ML happens to be a very succinct language for its purpose. There may be excellent C++ books which address threading issues, but I haven't seen any.
Fifth: a minor-ish tip: when writing multi-threaded C++ code, don't ever use global objects -- only use pointers to global objects. This point may be covered in one of the above C++ books I mentioned, but I don't recall it. The problem is destruction -- when a program ends, you don't know in which order the threads will die, and when the global objects will get destroyed. So, use pointers to global objects, and destroy them explicitly if you need to (I rarely bother).
Sixth: Look at the Boost libraries (boost.org).
Well, those are some ideas. I've found that C++ does not suffer from bugginess, despite its reputation. There's a perception that C/C++ code makes it easy to make memory-related bugs (accessing invalid memory, failing to free garbage, etc). While the reputation is well deserved for C, and is doubtless deserved for badly-written C++, it is not deserved for well-written C++. Only rarely do I encounter memory-related bugs (or any serious bugs at all). It's all about coding practices, and using STL-type containers instead of doing memory allocation yourself.
Hope that helps.
That's a valid line of reasoning. Say that in court, person A gives testimony that he saw person B killed person C. Person A turns out to be a convicted felon. Can he be trusted? Perhaps not. It's not irrelevant. On the other hand, if the assertion that person A is a criminal can't be backed up, then the ad-hominen attack would look invalid.
OK, that's a pretty irrelevant ad-hominem attack.
If the person is, indeed, addicted to nicotine (via smoking), then that's a pretty reasonable line of attack, don't you think? After all, people have a strong tendency to rationalize their actions, no matter how self-destructive.
Indeed! That's a very reasonable line of attack. It's obvious that tobacco companies have a conflict of interest here. Tho it's reprehensible, it's easy to imagine that a tobacco company cares about its own profits more than it cares about any health effects on its customers.
As demonstrated above, ad-hominem attacks are not all irrelevant. The point being made is that this person claims to have a principled position: intellectual (and other) property rights should be respected. But the force of that argument is diminished if it turns out the same person is OK with stealing from other people when it suits him. Where's the principle? It starts to look like: "I'm in favor of things which make me more money, and I'm against things which make me less money". Not quite as high-sounding a principle.
Are there any cross platform (linux, mac, windows) GUI RAD tools ala Builder, yet?
Yes -- wxDesigner is a very nice RAD for use with the wxWidgets GUI-building environment. wxWidgets is a cross-platform GUI framework which uses native widgets. On Linux, it uses GTK+. On Windows, it uses Windows widgets. On Mac, it uses Mac widgets. There are other somewhat-supported platforms. This approach contrasts with that of the Qt framework -- another cross-platform builder (which is excellent), which implements all its own widgets on each platform. Also unlike Qt, wxWidgets is not bound by the GPL -- you're pretty much free to do as you like with it (i.e. incorporating it into commercial apps, without the requirement that you release your source code, or pay any licensing fee). wxDesigner is a very nice GUI RAD builder for wxWidgets. It's not free, but it's cheap. You definitely get your money's worth.
Do you use Linux? If you did, you would surely know that the way it works is this: Each distro takes care of compiling all the thousands of apps for you. So, for you, the end user, the apps are binary -- you don't have to worry about any messy compatibility details. Only a small number of experts are needed, to build the binary app for the given distro.
..., MySQL vs PostgreSQL vs ..., Mozilla vs Konqeror vs ..., it goes on and on). Microsoft, by comparison, is completely stuck with their one tired old stack. They're becoming ossified.
It is not necessary (or even desirable) to have One True Linux. The current system gives you all the ease of installation of a binary package, but with the flexibility of source code. The system of having _only_ a binary release, and no source code, is a limitation of the Windows world. That's why free software is slowly-but-surely eclipsing Microsoft.
Linux is like a many-headed beast. Or a rapidly-evolving cold virus. The distros are in competition with eachother as much (or more) than with Microsoft. Competition provides the fuel for evolution. The distros have become just amazingly powerful, in only the last few years -- each trying to eclipse the other. And all the distros are is the top layer. At each layer, you have the same thing -- lots of competing systems, vying to best eachother (Gnome vs KDE vs
Wny not just a bunch of PC's, each with 6x400GB drives? That's 2.4 TB per PC. 25TB is only 10 PC's -- 60 drives. What's the big deal just using NFS? Seems like not a very difficult target to hit.
Now, going to 1 PB -- that would be 400 PC's. At this point you've left the domain of something which is all that simple. Even so, if you use wake-on-LAN, you could no doubt get away with having 400 PCs, without special power, heating/cooling, etc -- as long as you were able to control the flow of information, so that no more than tiny fraction of the PCs would be on at a given time. And, of course, you'd have significant latency -- waiting for a node to wake. Since I don't know your requirements, I can't say how significant a barrier this would be.
You would get into a reliability issue with 400 PC's. Again, it would be useful to understand something about your problem space. It's possible that a butt-simple method would work for you.
Really, the difficulty/cost of the implementation is a direct function of data flow. If your data flow requirements are tiny, then the solution could be quite cheap.
Of course, even with low outgoing data flow, you'll still have your hands full just filling up the disks in the first place! Consider this: a typical cheap hard drive on a cheap PC can sustain, say, 5MB per second. If one PC is handling 2.4 TB, that would take 5-6 days to fill up. I suppose it would be reasonable to fill up, say, 10-20 PCs at a time. For the 25 TB system, you could fill it up in a week, easy. But for the 1 PB system, filling 20 PCs at a time, it would take you 3 months! Still, that might be OK, depending on your requirements...
And you buy into this reasoning? What a smokescreen! After all, Lexmark is only asserting that they've given you a discount.
In my primitive understanding (as a commoner), when I buy something, generally speaking, I have the right to use it in any way I see fit (with a few notorious exceptions, e.g. software, for which I supposedly buy a "license", rather than actually owning it outright). But with the above reasoning, a manufacturer can change any product at all into one of these special-case products, where your use of the product is restricted:
A. Suppose item price is $N. Change the price to $N = $M - $D, where $D is a fictional discount.
B. Claim that, in consideration of $D, the purchaser agrees to onerous term T.
Presto! With this disingenuous reasoning, what we commoners have, until now, been able to take for granted about our rights, can suddenly be stripped away arbitrarily.
Courts are supposed to be smarter than that -- they're to see thru such specious reasoning.
Just get hundreds of gigs of disk (probably you'll need at least 1,000), then use rsync to mirror them. I've used this system for some years, with an amount of data on the order of what you're talking about.
I have multiple mirrors, and I rotate between the mirrors, so that on a given day, I have a backup which is 1 day old, 2-4 days old, and a week or so old. On top of that, I periodically take mirrors out of circulation, say, every month or so.
Yes, I have alot of hard drives. However, drives are cheap. Losing data is expensive. Manually doing backups is expensive (both because of the time it takes you, and because of the cost of screwing up, which is likely). Tapes are useless -- you can never know if they really work. Same with CD-ROMs/DVDs. Tapes & CD's are also useless because their capacity is way too low -- it's the same as a manual backup.
A vast harddrive array is clearly the way to go. Everything is automated -- hence, very low chance of screwing up. Also, you know right away if a hard drive doesn't work. So, you can be sure of several working backup copies to fall back on.
You'll no doubt find that you want multiple computers to house all these drives...
I'm curious -- OK, so AYB is a bad translation of a Japanese game. I'd be interested to see a _good_ translation of that dialog. What is a "zig"?
The optimal move is a function of the current game state. Hence, your optimal move is a function of the cumulative moves you and your opponent make.
Chess is not a "solved" game (and even if it were, only a computer would be able to execute perfect play). Why do people select defences other than the optimal one? Because only near the end of a game can anyone perfectly evaluate all the possible lines of play, and thus be able to choose the optimal move(s).
If both sides play perfectly, then every possible game state is already decided as either White wins, Black wins, or draw. It's even possible that the starting position is a White win (or even, I suppose, tho less likely, a Black win). Most likely, it's a draw. But nobody can say for sure.
Which brings me to my Controversial Thesis: chess is a game of luck. Why? Because whenever you make a move whose consequences you can't fully evaluate (which is generally the case in chess, or any other interesting game), then you are making a blind choice (not necessarily totally blind -- the more skilled you are, the less blind your move is -- but still at least partly blind). Whenever you do that, you are trusting to luck. The move may turn out to be either better or worse than you hoped. In the former case, you're lucky; in the latter, you're unlucky.
I don't expect you to agree with my Controversial Thesis -- I haven't yet found anyone who agrees with me that chess is a game of luck!
Theoretically not true. In a 2-player game, the optimal strategy is always independant of the opponent's strategy.
or maybe just misinformed...
Why is it a scam? They claim that you will get $N back if you mail in some form, causing the price to be $N less. Then they go ahead and send you the $N.
Some people are claiming rebates are a scam because the rebate companies don't actually send you the $N, even when you follow the agreed-upon instructions. If that happened, I'd agree it was a scam. But in my experience, that doesn't happen. Hence, it is not a scam. Apparantly _annoying_ to many people, but not a scam.
We buy alot of stuff (often via Slickdeals.net) at tremendous prices, and typically involving 1+ rebates. I'd say we submit about 20+ rebates a year. Failing to receive a rebate is a very rare occurrance -- maybe 1 a year. What used to happen, before we became more careful, is that we screwed up in various ways: waited too long, failed to follow instructions, etc. But when we've done everything right on our end, we pretty much always get the rebate.
So, no, it is not a scam, in our experience.
The purpose of a rebate is to allow for a flexible price, while not _appearing_ to. A business, in general, can optimize the amount of money it makes by charging a given person the maximum amount of money that person is willing to pay. Ever see Tin Man? I love the exchange:
Q "So how much is this car?"
A "How much have you got?"
or something like that. With a rebate, only those people who most want the low price will go to the trouble. The price after rebate is set so that you hopefully don't _lose_ money when people return the rebates. The margin comes from the people who don't return them. Classic. I don't see anything wrong with it (unless the business fails to make a profit -- but that's their problem).
Here's another mechanism a business could use to implement flexible pricing (which you may not like as much) how about if you had to haggle for everything you buy?
Clerk: "This here one's a real _beauty_ of a TV. Best they make!"
You: "How much is it?"
Clerk: "How much have you got?"
I tried out MythTV, but, as you would have predicted, it indeed proved to be a FPITA. I also tried out Freevo, which was similarly painful.
/dev/video0. Use a utility to set the channel, then try cat'ing that to a file, and you'll get something you can play with mplayer:
/dev/video0 > someFile
/dev/video0. Which is what I did. The hard part is the programming.
However, what I found was that it was pretty darned easy to write my own pvr app. I use the Hauppauge PVR-250. I can't recall if I needed to install a driver -- seems to me the driver came with my Mandrake. On bootup, you get
$ ivtv-ptune.pl 10 # tune to channel 10
$ cat
^C
$ mplayer someFile
(the utility came from the IVTV package -- that's the driver I'm using for the Hauppauge).
So, as you can imagine, it's quite easy to write a little command-line app which just sits there snarfing stuff off
On that score, MythTV was pretty nice. It uses a MySQL database to store listings which it gets via a free web service provided by Data Direct (or ZapIt, or something like that -- I forgets the details..) You just need to run mythfilldatabase periodically, via cron.
Then, my little command-line app (which runs continuously in the background) reads the MySQL database, and my own control file, periodically, and refigures what it's going to program and in what order.
Not for everyone, I admit. But it was surprisingly easy for me to get it all working. And now, I have what _I_ consider to be The Ultimate PVR Which Does Exactly What I Want It To Do (except when it hits a bug, of course...)
That, to me, is the beauty of Linux!
Agreed - Scotland Yard is an immensely fun game. We just dusted it off a couple of days ago -- to teach our 8 yr old daughter -- and we've played it several times since then! Lots of fun -- very dramatic. It's really a 2-player game, but it works well to have teams of people (either controlling the robber or the police).
First, some suggestions on places to find info on what games are good:
The newsgroup rec.games.board is a great source of info on enthusiasts' opinions on board games. Someone maintains a database of ratings of games, as rated (mostly, or originally) by readers of the newsgroup. Search for "INTERNET TOP 100 GAMES LIST" (posted to the newsgroup every 2 weeks). Here's the current top 10, along with rating (1-10 scale) -- here's the link: http://scv.bu.edu/~aarondf/Top100
1 8.494 Puerto Rico
2 7.865 Euphrat & Tigris
3 7.756 Die Siedler von Catan
4 7.742 Die Fursten von Florenz
5 7.504 Modern Art
6 7.503 El Grande
7 7.451 Carcassonne
8 7.409 Ohne Furcht und Adel
9 7.399 Goa
10 7.387 Vinci
You'll see two of the games you mentioned on the list - Carcassonne and Settlers of Catan (note that the bulk of the best boardgames are German in origin -- the original German names are used in the list). I would guess that if you liked Carc and Settlers, that you match the taste profile of the contributors to the list fairly well, so you'd probably like many of the games on the list.
I've played maybe half the games on the top 10. Personally, I like Settlers, Euphrat & Tigris, and Modern Art particularly well.
One important question is: how many players do you have? 4 seems to be considered to be the optimal number for multi-player games (which are the most fun). If you have a different number, then there are specialized lists you should refer to. However, from your post, it sounds like you have several players, so the above list should be suitable.
Another question is: what type of games do you like? There are economics-style (e.g. Settlers), bidding-style (e.g. Modern Art), deal-making (e.g. Chinatown), path-connection style (e.g. Streetcar), war games (e.g. Axis & Allies), race games (e.g. Detroit-Cleveland Grand Prix), etc. etc. I guess you'd call this the genre.
Another thing to look for is the game designer. If you like a book by a certain author, you're likely to like other books by the same author. It's the same with games. Settlers was designed by Klaus Teuber -- a prolific game designer. So, you might look for other Teuber games. Many of the top-rated games were designed by Reiner Knizia -- I like just about every game of his which I've tried.
Another consideration is the complication of the game. You've mentioned Axis&Allies, which is relatively simple, and Settlers & Carc, which are moderately complex. Some of the games on the Top 100 list are fairly complex -- generally, at least as complex as Settlers and Carc.
Then there's game duration. If you like Axis & Allies, then you're probably not turned off by long-playing games. I'd think most games on the list would be OK.
There's a great website for boardgame enthusiasts, which you'd probably find useful in looking for new games: Boardgame Geek -- http://www.boardgamegeek.com
Finally, bearing all the above in mind, and considering the little scraps of information I have about you and your group, my tenuous suggestions:
I think you have maybe 4-6 people in your group. You have a taste for long games, and war and deal-making are appealing themes for you. Two classic games stand out in this category: Civilization (the board game which inspired the computer game), and Diplomacy. These are games which I would _most_ love to play, if I had a large enuf group of like-minded people available, and an unlimited amount of time. If you try Civilization, I recommend Advanced Civ over Civ.
I envy you, just starting to really delve into boardgames, with a group of enthusiastic players. You have some really great gaming to look forward to!
Good luck!
Possessions/assets are taxed, in various ways:
Most obviously, real estate tax is assessed on the value of the real estate. This is a direct tax on assets. Real estate makes up a very large proportion of the nation's net worth, so this is not an insignificant asset tax.
Less obviously, inflation provides a built-in tax on assets. In particular, if you earn, say, 4% in a bank account, the govt taxes you on that 4%, even tho inflation might be 3%. The tax on the 3% which is inflation is, in effect, an asset tax. If you keep your money under your matress, to avoid paying tax, then inflation itself eats your money away.
... you can safely remain ignorant of anything you'd like. It appears you are immune to being persuaded by facts.
I hear alot of complaining from Demo-types (mostly coastal, no doubt), about how disenchanted they are with the "red states" taking over.
Consider: the whole American system of government is _designed_ to allow for big differences in how each State runs its affairs. Back in the Civil War days, the _Dems_ were the champions of States Rights (for bad reasons, but still...) -- it was the 'Pubs who wanted strong centralized government. Perhaps now, the "old North" should come around -- appreciate the wisdom of decentralization. Let the red states have their Christian conservative style of government (outlaw abortion, teach creationism, have prayer in public schools, capital punishment, etc). The coastals (aka blue states) can have a more _liberal_ style (gay marriage, medical marijuana, etc.) The States would then be in (more) competition with eachother -- a true marketplace of ideas.
That is, this _could_ all happen if States Rights were truly respected. Unfortunately, the central government takes in too much tax revenue, and so it has too much power. The Supreme Court has also done its part to dilute the power of the States.
When you have a big country like the US, strong central government -- winner takes all -- leads to excessive political friction. The regional differences are too great.