The problem with electric cars, if that's what you have in mind, is: batteries. Think of your laptop. You may well, have Moore's Law in full swing for the CPU, but that hasn't applied to batteries too. They're big, they're bulky and they can store only so much juice.
That's the problem. We may control nuclear energy, and we may already build very good electric engines, but _storing_ that energy for the car to use is the weakest link. By far. As energy-per-lbs goes, nothing comes even _near_ chemical stuff that burns. Gasoline packs more joules per kg than any battery. (And gunpowder packs even more, which is why soldiers still use that, instead of railguns with a battery pack.)
However, it's still not all lost. If you have another energy supply, you can make enough stuff that will burn in a car's conventional engine.
E.g., a real no-brainer is using the electricity generated by a nuclear plant to split water into hydrogen and oxygen. Hydrogen can be then burned in a relatively conventional internal combustion engine, taking the oxygen back from the atmosphere and giving water vapour back.
Other ways exist to combine that hydrogen with carbon from coal (of which there are far more reserves than oil), creating synthetic liquid fuel. You don't even need a nuclear plant for that.
(A lot of the panzer warfare in WW2 happened on synthetic fuel. It wasn't that cheap, but it kept the panzers rolling.)
Or in some limited cases you can just replace the fossil fuel use with electricity. E.g., see how we replaced the coal and diesel train engines with electric ones. Electric busses and trams exist already, and could eventually replace the diesel ones if the economics are right. Also, if the investment were justified, one could build a power grid along highways to support at least electric trucks.
Ultimately, though, everything boils down to economics. As long as it's cheaper to bring in oil from the middle east, than to brew local synthetic fuels, people will bring oil from the middle east. As long as it's cheaper to fill up your tank with gas coming from the middle east, than to get an expensive hydrogen powered car and hydrogen, people will continue importing oil from the middle east. And as long as electric cars will continue to be expensive _and_ have a 50 mile range, after which they need several hours to recharge (as opposed to minutes to fill a fuel tank), people will buy conventional cars.
When the economics will be right, however, expect to see someone coming with such replacements. The whole civilization collapsing into anarchy and famine as soon as we pumped the last barrel of oil out, makes a good Hollywood scenario, but ain't gonna happen in RL. More realistically we'll then start producing synthetic fuel in the short run, and pumping billions into R&D for better solutions, and life will go on. It won't be as cheap as it is today, but it ain't gonna be Armageddon either.
Well, that's not the only problem
on
Retro Gaming Gets Hot
·
· Score: 2, Interesting
And conversely, I don't know of many modern PC games where you actually get 20 hours of gameplay out of it. Most shooters are somewhere in the range of 6 to 8 hours nowadays, and some are even shorter than that.
But I guess the more disturbing thing is that the interface isn't that easy to get into for a new user any more. With PacMan, it was obvious. Even someone who's never played it before, could just jump into it.
By contrast, most modern 3D games take quite some getting used to the interface. Now for those of us who pretty much grew up on Quake, WASD comes naturally. Doing rocket jumps, shooting rockets at someone's legs (instead of head) and switching weapons in mid-flight is our second nature. But for a casual gamer it can be quite a put off.
E.g., I've recently coaxed/coached mom into playing a new 3D game. (Let's just say fairly standard over-the-shoulder 3rd person game and controlls.) Now mom isn't stupid, but she's never played more than PacMan/Tetris/other old games before.
So it went something like this. I'll quote only my lines, from memory:
"Now talk to that guy. Uh, click on him... Yes, you need to be closer to him... Umm, no these keys here... Hmm, yes, I guess if you really want the arrow keys, you can always reconfigure it that way. I wouldn't recommend it... Uh, see, yeah, if you have the right hand on the arrows, now you'll have to move it to the mouse to click on him. Told you... Yeah, you're supposed to click on that answer to get a mission... Yes, you need to get a mission first... Uh, you closed it without getting a mission. Try again... right, now go in the direction on your compass... No, of course not through the building. Go around it... now jump over the fence... yeah, the jump key... uh, no, sorry, I meant press the jump key _and_ the forward key... no, see, just keep pushing forward while you jump... yes, keep pushing forward and press the jump key... ugh... yes, that's the guy you need to kill. Click to select him... yes, click on him... told you the arrow keys with the right hand were a bad idea... uh, no, you're too far away to attack... umm, well, either you start using the mouse for that, or you could press the '1' or '2' keys... yes, press 1 or 2... no, mom, you're pressing 3 and 4... don't worry, you'll get the hang of it, we all occasionally have to look at the keys instead of the screen... right, so keep going where the compass points you... yes, it's behind a building again... uh, ok, you remember that right, but you can't jump over this... no, mom, stop jumping... yes, I told you to jump before, but that was a lower fence... jeeze, no, you can't jump over the _building_. You're not superman... no, honestly, you can stop trying..."
Actually, IMHO it just means we might as well start doing more complex stuff, now that the basics are done well enough.
Yes, at some point people paid good money to have programs not only written by hand in assembly, but also translated by hand in hex/octal/binary. Machines were too expensive to be used for such mechanical tasks as converting assembly to hex. (No, literally.) Then the assembler started doing that for you.
Yes, at some point the only way to get good performance out of a C program (at least on an x86, with its few registers and other quirks) was to write the critical parts in hand-optimized assembly. No, not just mechanical conversion like a compiler would do, but it actually involved knowing the exact timings for a mis-predicted branch, for a cache miss, etc. The more details you knew about the underlying machine, the better you could optimize, and you were actually appreciated for it. Nowadays noone except people making compilers or drivers need to even know that assembly even exists.
Yes, at one time everyone wrote their own carefully crafted hash tables, allocated memory pools, etc. Billions of dollars per year went into just reinvening the exact same square wheel, the millionth time. Now any self-respecting standard library includes very good implementations of those. If your most prized talent was writing an efficient hash-table, you're _really_ out of luck nowadays.
Yes, at some point everyone had their own team to code how the data is to be saved into files, and file locking schemes, and their own caching schemes, and whatever. Now we have databases, so we can spend more time solving the problem, instead of reinventing data storage all over again.
Etc.
And IMHO that's a _good_ thing. A damn good thing.
Each such focus shift has allowed us to tackle bigger problems and/or be more efficient. Can you imagine how limited programs would still be if you still had to write everything in assembly, and convert it to hand into hex? Manually counting the number of bytes to jump over, for each condition or loop?
I can still remember doing that. It was slow, it was error-prone and it was practically unmaintainable. Inserting even a single instruction meant copying the assembly program by hand to another set of paper sheets for a start. (Remember: the only form your program could possibly exist on the computer was the binary object code. The source only existed on paper.) Then you'd start counting bytes all over again, because that inserted instruction shifted all your addresses and messed your relative jumps.
Then when you made a mistake (and you made _plenty_ when you worked like that), it was time to transcribe and count bytes all over again. And again.
As a consequence, any program coded like that was small and of very limited scope.
So I say "bring it on!" The sooner we can forget about coding the exact same stuff all over again (e.g., whoppee, yet another identical corporate site), and move on to tackling other problems, the better. Society as a whole will benefit more if we learn to solve a new problem, than if we all spend the next 20 years programming the exact same stuff again and again and again.
He didn't say one should hold pointless team-building or morale-building meetings. (My "favourite" kind: the mandatory after-work meeting, but which you're not supposed to put on the timesheet. Yeah, verily, being dragged once a week to a boring meeting in my own free time has got to make me cheerful and happy to be in that team. Not.) Nor anything equally stupid.
He merely says that they have to submit _some_ code regularly. It may be once in 3 days, or once a week, but you have to check that they're at least coding in the right direction. And not, say, coding a square peg while the rest of the team is happily carving a triangular hole for it.
Now I myself am (more than) a bit introverted and I appreciate being left to concentrate on solving a problem. But, dunno, being left in the dark with no feedback or sense of direction is not the happy coding experience, it's actually stress. Am I doing the right thing? Does anyone need this stuff? Does it have the interface that the others expect? Chaos and stabbing at the darkness are not fun.
Again, by feedback or sense of direction, I do _not_ mean stupid meetings where the boss is making verbal love to himself and generally wasting everyone's time. It doesn't even have to be some formal event or anything.
I mean, for example, that I check my stuff into CVS, even in the early stages, when most of the functionality is empty method stubs. And someone actually uses it and tells me if I'm going in the right direction, or maybe awfully misunderstood the specs. (And conversely I'll tell them if I can't link with their module or it seems to do funny stuff when I do.)
Basically it's just about communication inside a team. You must have at least _some_ of it.
Now that some PHBs turn it into an ego-masturbation exercise, instead of actually helping communication, is an entirely different problem. Still, just because some people do it wrong, isn't IMHO a reason not to have any communication at all.
Well, I really doubt that they're _really_ getting full of viruses and spyware from Yahoo and Ebay.
Most likely, well, it's just that 99% of the people will never admit they're browsing for porn or warez. Gotta wonder how those sites account for 99% of the clicks on the Internet, with everyone claiming to either not even know that they exist, or being outraged that they exist.
In practice much of the Internet's growth and technologies (e.g., streaming media) were sponsored and pioneered by porn sites. And the first sites that made money on the net... well, let's just say it wasn't the dot-coms with big IPOs.
So were some of the worst practices on the net. Dialers, spyware, trojans, _barrages_ of popups on both entering and leaving a page, ActiveX installing of crap, plugins or codecs that install crap, abuse of IE bugs to install crap, etc.
So to cut a long story short, I usually just _really_ start wondering about anyone who claims they've never ever visited any site except Yahoo, Ebay and MSN, and still got trojaned to hell and back. Chances are they're forgetting to mention a few sites.
And I may be wrong, but it sorta makes me wonder about the article too. Now it _could_ be like they say. But it could also be that a bunch of people there got trojanned to hell and back while surfing for porn (and/or warez) at work. Then it's "uh, I got this dialer and bookmarks to porn sites from the MSN site. Honest." time.
You see, there are perfectly good reasons to tunr a computer off, regardless of whether it's running Linux or Windows or Solaris or MacOS X. And then you'll want it to start as quickly as possible when you want it back on.
Laptops are the prime example. You don't want it on all the time, when you don't need it. You want to still have some juice in the battery when you do need it. You'll also want it up and running as fast as possible when you do need it.
Dunno about you, but I'd rather just start using it, instead of sitting and watching through 5 minutes of Linux loading everything _and_ the kitchen sink at startup, then loading KDE, then taking ages to start Open Office, etc. If MRAM lets me have it up and ready in 1 second, I'm all for it.
E.g., there are computers in a lot of gadgets. Take my CD-based MP3 player, for example. Whenever I power it up, it takes a couple of seconds to basically boot and read the track list. If all that could stay in MRAM, and have it start playing the millisecond I hit that button, it would be a much more convenient gadget.
And even with regular PCs, you have to understand that some people actually _use_ their PC. They don't just keep them for a retarded "my uptime can beat yours" contest. And, like any other tool, there are perfectly good reasons to turn it off when you're not using it any more.
If nothing else, for the noise. Now this computer is a lot more silent since I replaced the fans with 12 dBA ones, and got Seagate drives. But all else being equal, I'd still _not_ have an extra source of noise near my bed when I'm trying to sleep.
For a lot of people the electricity bill is a factor too. Yes, it's not a small fortune, but for a lot of people it matters. And it's still paying money for something they don't need. They're getting exactly zero use out of that computer running all night, so why would that be on their electricity bill?
Basically all I'm saying is: next time make sure brains are engaged, before jumping in with the standard knee-jerk "Microsoft sucks" post. Yes, I know. It gives retards the impression of belonging to some big sad community. Makes you sooo cool if you're whining about Microsoft too.
But sometimes it still can't hurt to pull your head out of your ass. There _are_ uses for some stuff (e.g., the MRAM we're talking about here) that aren't a Windows-vs-Linux thing at all. They're just as useful for either.
Of course, that would mean actually thinking and actually doing a real analysis, instead of just reaching for the fashionable dogma. But I'm sure you'll get the hang of that, eventually.
You have to understand that what the Romans valued 2000 years ago, is a different story than what natural selection valued 2,000,000 years ago.
Romans valued warfare and conquest above all else. The proper things for a young roman to study were military stuff and administration. Everything else was for the lesser people. (E.g., almost all the medics were Greek. It was below the worth of a true Roman to learn medicine.) Hence the ideal of a fit soldier.
Any form of state and organized warfare is a _very_ new invention, if you think what kind of intervals are involved in evolution. Even tribal warfare isn't as common as you'd think.
E.g., take the Bushmen in a Africa, which are a prime example of hunters-gatherers in a very hostile environment. Would fit what mankind had to deal with for most of its evolution.
Do they have muscular warriors killing each other for territory and prestige? Well, no. Quite au contraire on both accounts.
First of all their culture is all about sharing and solving conflicts peacefully. If you just can't stand to see someone's face, no matter what, you move to another tribe, not challenge him to a duel. Basically they have enough trouble surviving as it is, without starting taking down other men.
Second, they don't look particularly muscular to me. Au contraire, they look thinner than any geek you'd see in the Western world. Must have something to do with having a shortage of food.
Basically warfare for protection and territory, and having fit soldiers to kill other men, started making a lot more sense once you had agriculture or herds of sheep/goats/cows/whatever. Then the land itself started having a value. But hunters-gatherers tended to be a lot more flexible about where they are, and about solving problems with each other.
While some of their hunters did end up doubling as warriors, it was late and as a response to others threatening them. They were still primarily valued as hunters, and still thought twice before going to war.
E.g., think about the early Europeans arriving in America. While it was (and still is) fashionable to think of the native Indians as bloodthirsty barbarian tribes of warriors, there also is a day called Thanksgiving. Giving thanks for what? For the fact that those tribes not only didn't attack and enslave on sight, like the Europeans would have, but were willing to peacefully let the Europeans have some land. Even taught those Europeans a bunch of useful stuff.
That's what a hunter-gatherer culture is like: it will rather try to coexist peacefully and share, rather than directly reach for the war axe.
""Evolving into something more muscular and slower was _not_ an option."
To nitpick to death, it was an option. Just not a good one:)."
Well, given the time intervals needed for evolution, and the environment, I still say that it wasn't an option at all. Small mutations in that direction happened all the time, and died, but actually _evolving_ in that direction for any signifficant interval was not realistically possible.
As you undobtedly know, evolution works in _very_ small steps. The mutations along the line are almost infinitesimal.
Such abrupt one-in-a-million mutations like this kid don't count, because the chance is pretty much zero that in a tribe of, say, 100 people he'd also find a similar wife, so they can transmit this abrupt mutation to their children. Or if they do, it's not too far.
Such big deviations randomly appear, and then die.
So to start evolving in a given direction, _tiny_ deviations in that direction have to offer a very immediate short-term advantage.
I.e., you can imagine that an 800 pound ape, pure muscle, and with razor sharp claws and tiger-like teeth, would have been _perfect_ for that environment. However, evolving into that was not an option. Why? Because it involves going through steps like a _slightly_ more musculare ape, and maybe with _slightly_ bigger fingernails.
Which step just lacks the survival advantage to continue along that line. It would need to go on like that for a couple million years, before it starts being an advantage. Before that it's actually a disadvantage, so it gets purged out of the gene pool.
The opposite direction, namely the ape with a _slightly_ bigger brain and other small deviations towards human had a much bigger advantage, so those were the ones who lived to have kids.
You are of course right, but you're talking about a whole other time interval than I was.
Once that ape developped the tools needed to hunt, yes, it indeed became a hunter-gatherer species, instead of just gatherer. And indeed, at that point the factors changed a little. E.g., having a steady supply of meat made it a much safer bet to have a bigger brain than poaching half-eaten corpses did.
Inventing the fire changed the factors too. For starters it brought the vegetables back into the menu. This brought more protein intake, which in turn was needed to support an even bigger brain.
As I've said, it was a sort of a spiral, with needing a bigger brain to invent the next big thing, which in turn allowed an even bigger brain, and so on. This continued for a long time, including, yes, a very long interval of hunting-gathering.
But in the first millions of years of the evolve-or-go-extinct race, it simply couldn't hunt. It had no natural weapons, and it didn't yet invent any weapon that could kill a fast herbivore, nor a trap that could catch one.
It started as a scavenger. Later, yes, it evolved into hunter-gatherer. Then much later into agriculture.
I know it's a joke, but just for record sake, evolution was not a beauty contest. ("Chicks dig muscular guys! I want to be muscular too!") It was about tuning an animal to be able to at least survive its environment.
As was already mentioned by several other people, the food intake is one factor. I won't go into that again.
What I will go into is the situation humans evolved in. Humans didn't evolve as brave muscular cavemen wrestling sabertooth tigers in 1-on-1 combat. Au contraire. It was more like a stealth game, if you will.
It was a rather small and wimpy fruit eating ape, only suddenly there were less and less trees with fruit. It had to find a new source of food.
Now contrary to popular belief (e.g., among rabid vegetarian zealots) not all animals can eat grass and leaves. Raw grass and leaves contain an enzyme that prevents you from extracting the protein in it. Unless you have the _very_ specialized digestive system of a herbivore, _or_ can boil those plants (high temperature destroys that enzyme), you can't survive on leaves. That ape didn't fit either category. (We're still millions of years before taming the fire.)
There is, howver, one thing that any animal can digest, and provides all the aminoacids needed: meat. Yes. Sorry, vegans. The human species evolved on _meat_.
There was another problem, however: that ape couldn't hunt. It didn't have the speed to catch an antelope, nor the claws or teeth to kill it with.
It had to survive by basically stealing food killed by the carnivores. The problem not ending up as second course for those carnivores.
It was a game of stealth, speed and cunning, not one of brutal hand-to-hand combat. Evolving into something more muscular and slower was _not_ an option. A small ape twice as muscular still can't kill a tiger with its bare hands.
The correct evolutionary path was to become more agile and, most importantly, _smarter_. Being able to improvise a plan raised your survival chances a lot more. And conversely, having a supply of meat allowed you to have a bigger brain. This cycle is what put us on the evolutionary course to what we are today.
I.e., in a way, yes, the correct evolutionary course was to become a scrawny smart geek. That was the survival trait.
And you can see it in how the species evolved. In the original ape, the male was about twice as big as the female, much more muscular and had bigger teeth and jaws. It was originally supposed to be, yes, the muscular jock that can defend his woman.
What the species evolved into, was something where the two genders are a lot more comparably sized. Most of the muscle advantage disappeared, and the big jaws were lost too.
It's easy to extrapolate that the brave and muscular jocks were the first to get out of the gene pool. That was not a survival trait.
Let me guess... anything that doesn't involve 7 hours of meetings a day and colourful power-point foils, doesn't count as design or important to you?
Guess what? 90%+ of programming _is_ design and analysis, even if it happens in front of the computer. The routine mechanical parts are already handled by the compiler, IDE, plugins, standard libraries, frameworks, etc. That's the easy part.
The hard part is taking a problem and splitting it into an architecture and algorithm that solves the problem. Preferrably also in a way that's robust, easy to maintain, and easy to change when the client comes and says that now he wants something different. Those don't happen by themselves. That's what programming is all about: mostly design work.
Of course, if the respect you have for programming work is summarized by the words "code monkeys", you probably do get monkey quality at the end of the day. The pipe dream and marketting fraud of the last 20 years straight was that somehow you could buy a silver bullet that makes any monkey able to write a good program. Never happened so far.
Of course, it still doesn't stop idiots from trying. When you read statistics like "68% of Java 'programmers' don't even know Java" or "3 out of 4 programmers can't actually program"... well, you know who hired them. Someone who thought that it's all monkey job and hired the cheapest monkeys.
Of course, then the programming takes ages to finish, is awfully buggy, is an unmaintainable mess, and 2 years later ends up scrapped and programmed from scratch all over again. But hey, this time we have a silver bullet +1. It surely can't go wrong again this time.
Either way, I'm not saying there isn't a time and place for meetings, documentation, and drawing a grand diagram on the whiteboard. There sure is. And there sure is a need for people who, yes, mostly do analysis and architecture design. Yep. Please do hire those.
But at some point, _someone_ has to sit down and implement it. Someone like me. Call him a "code monkey" if that makes you feel somehow superior. But someone has to do it.
You can't have only meeting-happy people sitting around and showing off colourful powerpoint foils, 8 hours a day, 5 days a week, and have the program auto-magically just materialize sometime before the deadline. Someone has to actually sit down at a keyboard, and implement that grandious architecture and design sometime.
And at thet time, they better have a door they can close, so that they can concentrate on that work. It's a mental exercise, not just mindlessly typing like a secretary. If they have to listen to 5 others in 2 different conversations about their vacation, trips, car, and whatever else, it's damn hard to think about converting that spec into an algorithm.
Oh, I can easily believe that there are tons of lemmings getting sucked into this corporation battle. Heck, I can even see around me every day. It's even become the current IT fashion to be anti-MS. Gives some people a sense of belonging to some sad community, I guess.
Don't get me wrong, if you have nothing better to do with your life than donate work, time and money to helping Corporation A against Corporation B, I'm not even going to try to stop you. Sure. For all I care you could just as well start a "help big corporation CEOs buy a new yacht" charity, or just send a donation to whichever corporation you favour. Please do.
Either way, that's the beauty of it. Unlike Microsoft's think-tanks, this is one case of propaganda which actually worked astonishingly well. I'm impressed.
I'd say that whoever came up with that idea deserves a big bonus, but... here's one more piece of trivia for you: it was invented by Microsoft itself. Noone really gave half a damn about Linux until Microsoft mentioned it as a competitor in their anti-trust lawsuit. _Then_ everyone and their grandma, including the corporations, started actually rallying around what seemed like the +5 magic weapon that could defeat Microsoft.
Then again, who knows? MS may well be in control of this after all. Suddenly all the rebels-without-a-clue who were ranting and raving for Novel Netware, Solaris, IBM OS/2 and whatever, now are suddenly all Linux zealots. Linux has already cost Sun, for example, more server sales than it cost Microsoft, plus made Sun dump money into supporting it.
Either way, it will be an interesting battle to watch. I already have the popcorn ready.
"In their opinion, open source development should be best left to companies that develop software"
And that would be different... how?
Most of the OSS work _is_ done by companies. If you look at who contributes to the kernel, GCC, various other stuff, there's one helluva lot of people with email addresses from IBM, Intel, Red Hat, SuSE, Sun, etc. Or who acknowledge being funded by a company. (E.g., ReiserFS is sponsored by SuSE.)
The whole thing is one big FUD and astroturfing game between corporations.
In that corner you have MS, with its funded think-tanks trying to sell one illusion.
In the other corner, you have a bunch of corporations pissed off at Microsoft, pitching their funds into hopefully hurting Microsoft. And actively promoting their own FUD and lies. Including the myth that Linux somehow happened by itself. That somehow thousands of hackers weren't paid to code an anti-MS weapon, but just spontaneously did it all by themselves in their free time.
Still disguising paid work as some grassroots movement against MS's oppression. Shouldn't that count as astroturfing too?
And as astroturfing goes, I'd say MS isn't even the biggest liar in that game.
Yes, and how many of the Windows services listen to the network? I'm looking at the services list on a Windows 2000 computer right now.
Does the "Login" service on Windows listen to incoming connections? Well, no.
Does the logger listen to incoming TCP/IP connections? I don't think so.
Does that task planner listen to the network? Well, no, just like any Unix cron daemon doesn't.
Does the printer queue accept incoming connections? Nope.
So _you_ cut it out with the FUD already. Yes, there are a couple of services which ought to have been firewalled by default. But that's it: 2-3 services. Not "waah! Run for the hills! 30 services with remote vulnerabilities!" that some linux zealots make it sound like.
And let's talk about another thing. Sure, it's fun to moan and bitch about all the poor Windows 2000 users who got hit by some RPC virus, because the computer wasn't firewalled by default.
Well, have you used a _Linux_ distro in the year 2000? Let me tell you that back then the damn thing not only didn't install any firewall by default, it also loaded 3 times more daemons than Windows 2000 ever had services. I even ended up with an Apache with PHP started by default, a MySQL server, etc.
And let's talk about where the terms "rootkit" or "to get rooted" started. Or where did the advice to never surf or use IRC as root start. Right. In the Unix and Linux world. It used to be that if you took a Linux computer on IRC without a firewall, you'd have another user logged in, within the first hour or two.
It took a _very_ long time for Linux to get its shit together and start checking buffer sizes too. Or to not listen on two dozen ports by default.
Yeah, now Linux is getting a helluva lot better. So is Microsoft's shit, gradually. They actually both went and are going through the exact same stages. Linux may have a little head start nowadays. Praiseworthy, but hardly justifying the infatuated moaning about how MS only ever codes crap. Again: Linux went through the exact same stages itself.
Think of what happens when a normal sabot round hits. It's also just a sharp bar with fins, much like a medieval crossbow bolt.
The friction as the bar punches through a hard target, will turn the rod itself into molten metal and partially vapour. In the case of a metal armoured target (e.g., a tank or ship), some of that metal too. The liquid spray and partially vapor metal that formerly was the rod, will flash burn and literally cook anyone behind that wall.
I.e., so far, if you hit a hospital or a house, not only you'll do massive structural damage, you'll also cook quite a few people inside. Hitting a gas station or refinery, well, that can get quite spectacular.
But it gets better. Heavy metal burning in air produces, unsurprisingly a fine dust of metal oxide. It can be inhaled, it can contaminate ground water, and it can get on the clothes and skin of kids playing in or near the destroyed building or tank.
And the funny thing with heavy metals, is that they're toxic. They also tend to stay inside you for the rest of your life, once they entered your body.
The problem with depleted uranium rods isn't that they're radioactive. They're actually nowhere _near_ being dangerous enough because of radiation. The problem is each hit produces kilos of toxic dust.
Now I do understand that war is war, and you'd better destroy an enemy tank by any means, before it kills _you_. It's not pretty, it's not humane, it's war. Fair enough.
But at least have the decency not to pretend that your shit stinks less and never causes collateral damage. If a few grams of anthrax were (rightfully so) considered a terror attack, how do you call the many _tons_ of toxic uranium oxide your troops left all over Iraq? Right.
Again, I understand that war is war. But precisely _because_ it's war, it's never a clear cut case of "those are the 100% bad guys, and ours are the 100% good guys who never cause any civilian casualties." No weapon ever was 100% clean, and modern ones have the tendency to become less and less clean, rather than the other way around. Yours and theirs alike. Might as well stop pretending that you have some magical weapon that only kills the enemy.
Well, yes and no. I still see it as a contiunation of the real damage that overclocking did, historically. That is: hurting other people.
What caused Intel and AMD to lock the multipliers, a few years back, was a much worse phenomenon: dishonest OEM's selling overclocked systems, without even testing if they work at that speed.
A lot of moms and pops back then bought an expensive 150 MHz Pentium system, but under the heatsink it really had an overclocked 100 MHz chip. Or their kid bought a chip marked 150 MHz, except it really was a remarked 100 MHz part. Again: bulk remarked, without any testing.
Now your normal overclocker at least knows that they've overclocked their system. If it doesn't work at that speed, they reset the BIOS and try a lower speed.
Those moms and pops didn't know, and wouldn't have opened the case to mess with FSB speed jumpers and multiplier jumpers anyway. All they knew was that their shiny new "Intel Inside" computer crashes randomly, and sometimes needs to be left to cool down before it boots again.
That wasn't just cutting into Intel's profits, it was giving them a bad name. All those people only knew that they bought an "Intel Inside" computer and it's crashing. Lots.
When Intel first implemented the multiplier locks, for a while it was the AMD and Cyrix chips that were used in this fraud. And unsurprisingly, then you started hearing people complaining that "AMD processors are unstable".
Heck, I was talking to an IT professional last month, and when I mentioned the VIA/Cyrix CPUs as a silent low power (if slow) solution, he _still_ was like, "but Cyrix CPUs crashed lots!" and "Why would you want a CPU that crashes?!?" After all these years, VIA is still damaged by what those dishonest OEMs did back then.
I.e., it wasn't just the cost of support calls, it actually caused a lot of lost sales in the long run.
Nowadays most OEM's know better than to mess with the FSB speed, because it's easily visible. However, your kid who wants to brag about his 3D Mark score, or the "smart" computer-oriented neighbour who helps you tune your system, or even the occasional idiot employee if you have a company, don't.
They tweak it in December when it's cold, then in July or August you start wondering why your computer starts crashing. Well, duh. Because when the ambient temperature is 20 Fahrenheit higher, so is the CPU temperature.
With the P4 thermal throttling it can get even worse. The computer might look like it works, it will even finish a run of SuperPI or 3DMark, but after a while it starts going into thermal throttling mode every 2 seconds. That's something you'd be hard pressed to diagnose if you're the average non-geek end-user. You just see that the computer crawls or has random hickups where nothing happens.
I.e., there still are very good reasons why an end-user might actually _want_ a physically non-overclockable computer, and there's a good reason why Intel doesn't want them to start thinking "Intel sucks."
There's a reason why ESR came with that idea. Code only happens when you sit at the damn keyboard and type it, not when you're spending 7 hours a day talking to everyone you can find in the building.
Coding is inherently a _very_ boring activity, if you're a total extrovert. And I can see it around me every day. The ones who produce good code and lots of it, are the ones who can shut up for hours straight and just program.
This doesn't mean being a complete hermit, and unable to communicate at all. Sometimes, yeah, it's necessary to talk to someone else in the team. Sometimes you have to convince people of your vision of the architecture. And the occasional chatting pause at the water cooler or smoking place is OK, too. (Noone is 100% introverted either.)
But in the end, to actually have a program by the deadline, and earn your 8 hours a day pay, you damn better be able to spend at least 7 of them actually coding.
On the other hand, the least productive two, the ones who haven't actually produced anything in two years straight (not a joke), are also the most social people. Not only they'll talk to each other for hours, they'll even turn any communication with other team members into a 2 hour negotiation.
To get any of them to actually fix their own bugs, it turns into something resembling a negotiation with terrorists. You first have to explain to them why you want that bugs fixed, why you can't possibly live with their function returning the wrong result, listen to their view of why it's OK, listen to their grandious view of their architecture and why it shouldn't be changed (even if it returns the wrong result or crashes), etc.
Not only they're not producing anything in that time, they're also keeping other people from producing something.
When such people get promoted, it's even worse. They end up calling endless pointless meetings, just because they're bored. The kind of meetings where in the best case you spend 2 hours learning that nothing is new and worth discussing, and in the worst case you spend 3 hours hearing about their vacation or their kids. The kind of pointless meetings that keeps a whole team from working, just to entertain a bored PHB.
Either way, please do realize that some people would rather concentrate and work than listen to you. Hence the request for doors.
The absolute worst environment I've been in, was one freaking big room with 20+ people in it. No walls, no cubicles, just a ton of people in a cathedral sized room. And with the accoustics of a cathedral.
At any given time you'd hear at least two different conversations, one co-worker slurping tea in the loudest possible way, one idiot listening to music on his speakers (I bought him headphones, but he said he hated headphones and continued the noise pollution), 2-3 idiots taking a break to play Counter-Strike (at least one of them on the speakers, on a bad day also with a subwoofer), etc.
It was such a noise cacophony that it was plain old impossible to concentrate on doing any work. Eventually I started listening to loud music on the headphones just to cover that disruptive ambient noise. Of course, that was a bit of a distraction in itself, but it still beat listening to the equivalent of coding in a railway station.
Just wanted to add that synchronizing a collection isn't as easy as it sounds, either.
Contrary to the mistake everyone makes when they start with Java, just using a Vector or declaring every single method as synchronized doesn't even start to cut it. You'll still get rare race condition exceptions if you do only that, as soon as one thread uses an Iterator.
To actually use a collection in a truly thread-safe manner, you have to separately synchronize in a way where every single iterator loop is in a synchronized block. To be precise, synchronized to the same monitor as every single method which can add or remove elements. Anything less than that is a very rare race condition waiting to happen.
And that's a lot less easy than it sounds when the iterator loop is buried deep in Swing and not under your control. You end up needing to also move all data transfers to the element's model in those Runnable implementation for later invoking.
And you'd be surprised how often people get that wrong.
Swing or no Swing. I've seen cache implementations which lock wrong too. But Swing just begs for that to happen.
OK, guess I better answer the "invokeLater()" thing before I get 10 more replies to the exact same end.
Give me some minimal credit, people. I know how to invoke later. For tiny projects where you only need to invoke later, but don't actually share any collections between a thread and a GUI model, it even works wonderfully.
I also know that every single collection class throws an exception if you change it while someone (e.g.: a Swing component) traverses it with an iterator. And therein lies the problem.
When that loading thread shares some baroque collections with Swing, you end up having to add synchronization to each of them, or the very Swing event Thread will die to an exception. OK, that is at least obvious. (We all know we should synchronize collections for multithreaded access, Swing or no Swing.)
A more perverse problem, is when that loading has to add or remove elements to a Swing List or to components to a Swing form. It's not even hard to end there. Just takes a spec along the lines of "I want this and that to only be on the page if the loaded data contains this other thing."
There the collections may not even be under your control, but are burried deep in Swing. It's not that hard, especially if you bring someone new into the project, to see them code something which ought to work all right in the Windows API, but bombs the Swing event thread.
Either way, whether you actually add "synchronized" blocks, or move code into a Runnable implementation for invoking later, it's still extra work. It's still moving it in another block. And still a chance for someone to forget to do it. Or do it wrong.
That's all I'm saying. If Swing was synchronized to start with, like, say the normal Windows API is, you wouldn't have to do it.
That said, yep, your reasons are very good ones too.
I've programmed both in assembly, so, yes, I have some idea of what they can do:) I'm not concerned with what the ALU can do with 16 bit operands. At the very least you could always take the same C code and generate Z80 code out of it, instead of 8086 code anyway.
I'm concerned with space. One thing the 8086 does do, and the Z80 doesn't do (or not natively), is being able to address up to 1MB of RAM via segment registers. Somehow I just can't see Linux run in 64K of RAM, no matter how you optimize it. (And some of those 8080 and Z80 machines had less than a full 64k available, since they also had to shove a BIOS somewhere in that address space.)
Now you could do bank switching and whatnot in hardware, to swap more than 64k in and out of the Z80's address space, and code kernel support for that. But that'd pretty much be designing a new machine, as opposed to reusing existing 8080 computers that used to run CP/M. Most of those had no such hardware.
Well, various other flavours of Unix are a different story. Unix or some variant have been ported to pretty much every single computer ever made in the last 20 years or so. The parent poster explicitly said Linux, though, which is why I was asking.
"Is there something wrong with this approach? Sounds reasonable to me. Might be a tad memory-intensive, I guess."
There is nothing inherently wrong with caching already open (but invisible) frames, if that was your design to start with.
What's wrong is that you end up _having_ to modify your architecture like that, just to get out of the inherently leak-prone design of Swing. Not because you did a performance analysis and decided to cut down on time with caching. But because you've already spent pointless weeks tracking listener allocation and deallocation, you're already hopelessly past the deadline, and still can't get Swing's normal architecture to work right.
Either that, or to give an example from another actual project, you end up extending every single Swing class to include some form of listener tracking, and a baroque dispatcher mechanism to help with that. (Ironically enough, in the end they still ended up with the "closed window cache" way out, when some new team members failed to use that baroque dispatcher properly.)
Either way it's extra work, which shouldn't have been there. Why are listeners hard references anyway? Why can't they be a soft or weak reference that doesn't prevent garbage collection? Why do I have to go through loops like that just to get a frame out of memory? Wasn't the whole idea of Java and its Garbage Collector to _avoid_ personally tracking pointers?
I.e., why can't it be like, say, the Windows API, where I never had to do such silly tricks? I'd just close the window, any child windows or controlls would automatically get the right event, so that they too can unload any resources they keep, and that would be it.
If anyone actually made Linux on an 8080 CPU, I'll _really_ want to know how. For whoever isn't an old dinosaur like yours truly, the 8080 was an 8 bit CPU and could address a total of 64 KB of RAM. (Yes, that's _kilo_bytes, not megabytes.) It also boasted speeds in the low single digit MHz range.
Now maybe you mean 8086, but even then... if anyone actually got Linux to run on anything lower than an 80386, I'd really want to hear about it.
Well, guess we can both aggree that Swing is pathetic crap. But I also can't see how Swing could ever be considered a "clean API".
E.g., take the listeners memory leak problem. I don't know of _any_ major Swing project that didn't end up chasing listener leaks. (No, home brewn programs with 5 buttons and 2 windows don't count.)
I also know projects, and _been_ in one, which ended up throwing up a two hands salute to that problem. Basically, "screw it, we'll implement the windows/frames/whatever as singletons, or recycle them in a list for future use, rather than spend another month chasing the last listener." (If you're new in a project and the architecture involves singletons for every single frame, or recycling windows into a cache instead of closing them, that's your clue: they ran into that problem, spent weeks, and gave up on even trying any more.)
E.g., take the idiocy of Swing being inherently non-thread-safe. Then the client comes and says "yeah, it's nice, but this loading sometimes takes 5 seconds, and in the meantime it looks like the app has crashed. Can't you display some progress bars, or something? And can't that other thing preload in the background?" Whop-de-do. Now you're cooking with threads. Time to go through the whole program, adding synchronized blocks (or synchronized child classes of the original Swing controls) everywhere. And still end up spending weeks to chase some spurrious thread problem, which occasionally crashes the Swing dispatcher thread.
Seems to me like if you took C or C++, and any major GUI API of your choice (X or Windows, pick your poison), you'd still end up with less problems. Even adding the regular C memory leaks from the non-GUI part of that program, it usually still ends up better than the Swing equivalent. Which defeats one of the major advantages Java was supposed to have in the first place.
Don't get me wrong, I'm not generally against Java or anything, but a Swing fan I ain't. It could be a textbook example of how _not_ to design a GUI API.
Slashdot Mirror
The problem with electric cars, if that's what you have in mind, is: batteries. Think of your laptop. You may well, have Moore's Law in full swing for the CPU, but that hasn't applied to batteries too. They're big, they're bulky and they can store only so much juice.
That's the problem. We may control nuclear energy, and we may already build very good electric engines, but _storing_ that energy for the car to use is the weakest link. By far. As energy-per-lbs goes, nothing comes even _near_ chemical stuff that burns. Gasoline packs more joules per kg than any battery. (And gunpowder packs even more, which is why soldiers still use that, instead of railguns with a battery pack.)
However, it's still not all lost. If you have another energy supply, you can make enough stuff that will burn in a car's conventional engine.
E.g., a real no-brainer is using the electricity generated by a nuclear plant to split water into hydrogen and oxygen. Hydrogen can be then burned in a relatively conventional internal combustion engine, taking the oxygen back from the atmosphere and giving water vapour back.
Other ways exist to combine that hydrogen with carbon from coal (of which there are far more reserves than oil), creating synthetic liquid fuel. You don't even need a nuclear plant for that.
(A lot of the panzer warfare in WW2 happened on synthetic fuel. It wasn't that cheap, but it kept the panzers rolling.)
Or in some limited cases you can just replace the fossil fuel use with electricity. E.g., see how we replaced the coal and diesel train engines with electric ones. Electric busses and trams exist already, and could eventually replace the diesel ones if the economics are right. Also, if the investment were justified, one could build a power grid along highways to support at least electric trucks.
Ultimately, though, everything boils down to economics. As long as it's cheaper to bring in oil from the middle east, than to brew local synthetic fuels, people will bring oil from the middle east. As long as it's cheaper to fill up your tank with gas coming from the middle east, than to get an expensive hydrogen powered car and hydrogen, people will continue importing oil from the middle east. And as long as electric cars will continue to be expensive _and_ have a 50 mile range, after which they need several hours to recharge (as opposed to minutes to fill a fuel tank), people will buy conventional cars.
When the economics will be right, however, expect to see someone coming with such replacements. The whole civilization collapsing into anarchy and famine as soon as we pumped the last barrel of oil out, makes a good Hollywood scenario, but ain't gonna happen in RL. More realistically we'll then start producing synthetic fuel in the short run, and pumping billions into R&D for better solutions, and life will go on. It won't be as cheap as it is today, but it ain't gonna be Armageddon either.
And conversely, I don't know of many modern PC games where you actually get 20 hours of gameplay out of it. Most shooters are somewhere in the range of 6 to 8 hours nowadays, and some are even shorter than that.
But I guess the more disturbing thing is that the interface isn't that easy to get into for a new user any more. With PacMan, it was obvious. Even someone who's never played it before, could just jump into it.
By contrast, most modern 3D games take quite some getting used to the interface. Now for those of us who pretty much grew up on Quake, WASD comes naturally. Doing rocket jumps, shooting rockets at someone's legs (instead of head) and switching weapons in mid-flight is our second nature. But for a casual gamer it can be quite a put off.
E.g., I've recently coaxed/coached mom into playing a new 3D game. (Let's just say fairly standard over-the-shoulder 3rd person game and controlls.) Now mom isn't stupid, but she's never played more than PacMan/Tetris/other old games before.
So it went something like this. I'll quote only my lines, from memory:
"Now talk to that guy. Uh, click on him... Yes, you need to be closer to him... Umm, no these keys here... Hmm, yes, I guess if you really want the arrow keys, you can always reconfigure it that way. I wouldn't recommend it... Uh, see, yeah, if you have the right hand on the arrows, now you'll have to move it to the mouse to click on him. Told you... Yeah, you're supposed to click on that answer to get a mission... Yes, you need to get a mission first... Uh, you closed it without getting a mission. Try again... right, now go in the direction on your compass... No, of course not through the building. Go around it... now jump over the fence... yeah, the jump key... uh, no, sorry, I meant press the jump key _and_ the forward key... no, see, just keep pushing forward while you jump... yes, keep pushing forward and press the jump key... ugh... yes, that's the guy you need to kill. Click to select him... yes, click on him... told you the arrow keys with the right hand were a bad idea... uh, no, you're too far away to attack... umm, well, either you start using the mouse for that, or you could press the '1' or '2' keys... yes, press 1 or 2... no, mom, you're pressing 3 and 4... don't worry, you'll get the hang of it, we all occasionally have to look at the keys instead of the screen... right, so keep going where the compass points you... yes, it's behind a building again... uh, ok, you remember that right, but you can't jump over this... no, mom, stop jumping... yes, I told you to jump before, but that was a lower fence... jeeze, no, you can't jump over the _building_. You're not superman... no, honestly, you can stop trying..."
And it went like that for some more time.
Guess that was quite a lesson in usability.
Actually, IMHO it just means we might as well start doing more complex stuff, now that the basics are done well enough.
Yes, at some point people paid good money to have programs not only written by hand in assembly, but also translated by hand in hex/octal/binary. Machines were too expensive to be used for such mechanical tasks as converting assembly to hex. (No, literally.) Then the assembler started doing that for you.
Yes, at some point the only way to get good performance out of a C program (at least on an x86, with its few registers and other quirks) was to write the critical parts in hand-optimized assembly. No, not just mechanical conversion like a compiler would do, but it actually involved knowing the exact timings for a mis-predicted branch, for a cache miss, etc. The more details you knew about the underlying machine, the better you could optimize, and you were actually appreciated for it. Nowadays noone except people making compilers or drivers need to even know that assembly even exists.
Yes, at one time everyone wrote their own carefully crafted hash tables, allocated memory pools, etc. Billions of dollars per year went into just reinvening the exact same square wheel, the millionth time. Now any self-respecting standard library includes very good implementations of those. If your most prized talent was writing an efficient hash-table, you're _really_ out of luck nowadays.
Yes, at some point everyone had their own team to code how the data is to be saved into files, and file locking schemes, and their own caching schemes, and whatever. Now we have databases, so we can spend more time solving the problem, instead of reinventing data storage all over again.
Etc.
And IMHO that's a _good_ thing. A damn good thing.
Each such focus shift has allowed us to tackle bigger problems and/or be more efficient. Can you imagine how limited programs would still be if you still had to write everything in assembly, and convert it to hand into hex? Manually counting the number of bytes to jump over, for each condition or loop?
I can still remember doing that. It was slow, it was error-prone and it was practically unmaintainable. Inserting even a single instruction meant copying the assembly program by hand to another set of paper sheets for a start. (Remember: the only form your program could possibly exist on the computer was the binary object code. The source only existed on paper.) Then you'd start counting bytes all over again, because that inserted instruction shifted all your addresses and messed your relative jumps.
Then when you made a mistake (and you made _plenty_ when you worked like that), it was time to transcribe and count bytes all over again. And again.
As a consequence, any program coded like that was small and of very limited scope.
So I say "bring it on!" The sooner we can forget about coding the exact same stuff all over again (e.g., whoppee, yet another identical corporate site), and move on to tackling other problems, the better. Society as a whole will benefit more if we learn to solve a new problem, than if we all spend the next 20 years programming the exact same stuff again and again and again.
He didn't say one should hold pointless team-building or morale-building meetings. (My "favourite" kind: the mandatory after-work meeting, but which you're not supposed to put on the timesheet. Yeah, verily, being dragged once a week to a boring meeting in my own free time has got to make me cheerful and happy to be in that team. Not.) Nor anything equally stupid.
He merely says that they have to submit _some_ code regularly. It may be once in 3 days, or once a week, but you have to check that they're at least coding in the right direction. And not, say, coding a square peg while the rest of the team is happily carving a triangular hole for it.
Now I myself am (more than) a bit introverted and I appreciate being left to concentrate on solving a problem. But, dunno, being left in the dark with no feedback or sense of direction is not the happy coding experience, it's actually stress. Am I doing the right thing? Does anyone need this stuff? Does it have the interface that the others expect? Chaos and stabbing at the darkness are not fun.
Again, by feedback or sense of direction, I do _not_ mean stupid meetings where the boss is making verbal love to himself and generally wasting everyone's time. It doesn't even have to be some formal event or anything.
I mean, for example, that I check my stuff into CVS, even in the early stages, when most of the functionality is empty method stubs. And someone actually uses it and tells me if I'm going in the right direction, or maybe awfully misunderstood the specs. (And conversely I'll tell them if I can't link with their module or it seems to do funny stuff when I do.)
Basically it's just about communication inside a team. You must have at least _some_ of it.
Now that some PHBs turn it into an ego-masturbation exercise, instead of actually helping communication, is an entirely different problem. Still, just because some people do it wrong, isn't IMHO a reason not to have any communication at all.
Well, I really doubt that they're _really_ getting full of viruses and spyware from Yahoo and Ebay.
Most likely, well, it's just that 99% of the people will never admit they're browsing for porn or warez. Gotta wonder how those sites account for 99% of the clicks on the Internet, with everyone claiming to either not even know that they exist, or being outraged that they exist.
In practice much of the Internet's growth and technologies (e.g., streaming media) were sponsored and pioneered by porn sites. And the first sites that made money on the net... well, let's just say it wasn't the dot-coms with big IPOs.
So were some of the worst practices on the net. Dialers, spyware, trojans, _barrages_ of popups on both entering and leaving a page, ActiveX installing of crap, plugins or codecs that install crap, abuse of IE bugs to install crap, etc.
So to cut a long story short, I usually just _really_ start wondering about anyone who claims they've never ever visited any site except Yahoo, Ebay and MSN, and still got trojaned to hell and back. Chances are they're forgetting to mention a few sites.
And I may be wrong, but it sorta makes me wonder about the article too. Now it _could_ be like they say. But it could also be that a bunch of people there got trojanned to hell and back while surfing for porn (and/or warez) at work. Then it's "uh, I got this dialer and bookmarks to porn sites from the MSN site. Honest." time.
You see, there are perfectly good reasons to tunr a computer off, regardless of whether it's running Linux or Windows or Solaris or MacOS X. And then you'll want it to start as quickly as possible when you want it back on.
Laptops are the prime example. You don't want it on all the time, when you don't need it. You want to still have some juice in the battery when you do need it. You'll also want it up and running as fast as possible when you do need it.
Dunno about you, but I'd rather just start using it, instead of sitting and watching through 5 minutes of Linux loading everything _and_ the kitchen sink at startup, then loading KDE, then taking ages to start Open Office, etc. If MRAM lets me have it up and ready in 1 second, I'm all for it.
E.g., there are computers in a lot of gadgets. Take my CD-based MP3 player, for example. Whenever I power it up, it takes a couple of seconds to basically boot and read the track list. If all that could stay in MRAM, and have it start playing the millisecond I hit that button, it would be a much more convenient gadget.
And even with regular PCs, you have to understand that some people actually _use_ their PC. They don't just keep them for a retarded "my uptime can beat yours" contest. And, like any other tool, there are perfectly good reasons to turn it off when you're not using it any more.
If nothing else, for the noise. Now this computer is a lot more silent since I replaced the fans with 12 dBA ones, and got Seagate drives. But all else being equal, I'd still _not_ have an extra source of noise near my bed when I'm trying to sleep.
For a lot of people the electricity bill is a factor too. Yes, it's not a small fortune, but for a lot of people it matters. And it's still paying money for something they don't need. They're getting exactly zero use out of that computer running all night, so why would that be on their electricity bill?
Basically all I'm saying is: next time make sure brains are engaged, before jumping in with the standard knee-jerk "Microsoft sucks" post. Yes, I know. It gives retards the impression of belonging to some big sad community. Makes you sooo cool if you're whining about Microsoft too.
But sometimes it still can't hurt to pull your head out of your ass. There _are_ uses for some stuff (e.g., the MRAM we're talking about here) that aren't a Windows-vs-Linux thing at all. They're just as useful for either.
Of course, that would mean actually thinking and actually doing a real analysis, instead of just reaching for the fashionable dogma. But I'm sure you'll get the hang of that, eventually.
You have to understand that what the Romans valued 2000 years ago, is a different story than what natural selection valued 2,000,000 years ago.
Romans valued warfare and conquest above all else. The proper things for a young roman to study were military stuff and administration. Everything else was for the lesser people. (E.g., almost all the medics were Greek. It was below the worth of a true Roman to learn medicine.) Hence the ideal of a fit soldier.
Any form of state and organized warfare is a _very_ new invention, if you think what kind of intervals are involved in evolution. Even tribal warfare isn't as common as you'd think.
E.g., take the Bushmen in a Africa, which are a prime example of hunters-gatherers in a very hostile environment. Would fit what mankind had to deal with for most of its evolution.
Do they have muscular warriors killing each other for territory and prestige? Well, no. Quite au contraire on both accounts.
First of all their culture is all about sharing and solving conflicts peacefully. If you just can't stand to see someone's face, no matter what, you move to another tribe, not challenge him to a duel. Basically they have enough trouble surviving as it is, without starting taking down other men.
Second, they don't look particularly muscular to me. Au contraire, they look thinner than any geek you'd see in the Western world. Must have something to do with having a shortage of food.
Basically warfare for protection and territory, and having fit soldiers to kill other men, started making a lot more sense once you had agriculture or herds of sheep/goats/cows/whatever. Then the land itself started having a value. But hunters-gatherers tended to be a lot more flexible about where they are, and about solving problems with each other.
While some of their hunters did end up doubling as warriors, it was late and as a response to others threatening them. They were still primarily valued as hunters, and still thought twice before going to war.
E.g., think about the early Europeans arriving in America. While it was (and still is) fashionable to think of the native Indians as bloodthirsty barbarian tribes of warriors, there also is a day called Thanksgiving. Giving thanks for what? For the fact that those tribes not only didn't attack and enslave on sight, like the Europeans would have, but were willing to peacefully let the Europeans have some land. Even taught those Europeans a bunch of useful stuff.
That's what a hunter-gatherer culture is like: it will rather try to coexist peacefully and share, rather than directly reach for the war axe.
""Evolving into something more muscular and slower was _not_ an option."
:)."
To nitpick to death, it was an option. Just not a good one
Well, given the time intervals needed for evolution, and the environment, I still say that it wasn't an option at all. Small mutations in that direction happened all the time, and died, but actually _evolving_ in that direction for any signifficant interval was not realistically possible.
As you undobtedly know, evolution works in _very_ small steps. The mutations along the line are almost infinitesimal.
Such abrupt one-in-a-million mutations like this kid don't count, because the chance is pretty much zero that in a tribe of, say, 100 people he'd also find a similar wife, so they can transmit this abrupt mutation to their children. Or if they do, it's not too far.
Such big deviations randomly appear, and then die.
So to start evolving in a given direction, _tiny_ deviations in that direction have to offer a very immediate short-term advantage.
I.e., you can imagine that an 800 pound ape, pure muscle, and with razor sharp claws and tiger-like teeth, would have been _perfect_ for that environment. However, evolving into that was not an option. Why? Because it involves going through steps like a _slightly_ more musculare ape, and maybe with _slightly_ bigger fingernails.
Which step just lacks the survival advantage to continue along that line. It would need to go on like that for a couple million years, before it starts being an advantage. Before that it's actually a disadvantage, so it gets purged out of the gene pool.
The opposite direction, namely the ape with a _slightly_ bigger brain and other small deviations towards human had a much bigger advantage, so those were the ones who lived to have kids.
You are of course right, but you're talking about a whole other time interval than I was.
Once that ape developped the tools needed to hunt, yes, it indeed became a hunter-gatherer species, instead of just gatherer. And indeed, at that point the factors changed a little. E.g., having a steady supply of meat made it a much safer bet to have a bigger brain than poaching half-eaten corpses did.
Inventing the fire changed the factors too. For starters it brought the vegetables back into the menu. This brought more protein intake, which in turn was needed to support an even bigger brain.
As I've said, it was a sort of a spiral, with needing a bigger brain to invent the next big thing, which in turn allowed an even bigger brain, and so on. This continued for a long time, including, yes, a very long interval of hunting-gathering.
But in the first millions of years of the evolve-or-go-extinct race, it simply couldn't hunt. It had no natural weapons, and it didn't yet invent any weapon that could kill a fast herbivore, nor a trap that could catch one.
It started as a scavenger. Later, yes, it evolved into hunter-gatherer. Then much later into agriculture.
I know it's a joke, but just for record sake, evolution was not a beauty contest. ("Chicks dig muscular guys! I want to be muscular too!") It was about tuning an animal to be able to at least survive its environment.
As was already mentioned by several other people, the food intake is one factor. I won't go into that again.
What I will go into is the situation humans evolved in. Humans didn't evolve as brave muscular cavemen wrestling sabertooth tigers in 1-on-1 combat. Au contraire. It was more like a stealth game, if you will.
It was a rather small and wimpy fruit eating ape, only suddenly there were less and less trees with fruit. It had to find a new source of food.
Now contrary to popular belief (e.g., among rabid vegetarian zealots) not all animals can eat grass and leaves. Raw grass and leaves contain an enzyme that prevents you from extracting the protein in it. Unless you have the _very_ specialized digestive system of a herbivore, _or_ can boil those plants (high temperature destroys that enzyme), you can't survive on leaves. That ape didn't fit either category. (We're still millions of years before taming the fire.)
There is, howver, one thing that any animal can digest, and provides all the aminoacids needed: meat. Yes. Sorry, vegans. The human species evolved on _meat_.
There was another problem, however: that ape couldn't hunt. It didn't have the speed to catch an antelope, nor the claws or teeth to kill it with.
It had to survive by basically stealing food killed by the carnivores. The problem not ending up as second course for those carnivores.
It was a game of stealth, speed and cunning, not one of brutal hand-to-hand combat. Evolving into something more muscular and slower was _not_ an option. A small ape twice as muscular still can't kill a tiger with its bare hands.
The correct evolutionary path was to become more agile and, most importantly, _smarter_. Being able to improvise a plan raised your survival chances a lot more. And conversely, having a supply of meat allowed you to have a bigger brain. This cycle is what put us on the evolutionary course to what we are today.
I.e., in a way, yes, the correct evolutionary course was to become a scrawny smart geek. That was the survival trait.
And you can see it in how the species evolved. In the original ape, the male was about twice as big as the female, much more muscular and had bigger teeth and jaws. It was originally supposed to be, yes, the muscular jock that can defend his woman.
What the species evolved into, was something where the two genders are a lot more comparably sized. Most of the muscle advantage disappeared, and the big jaws were lost too.
It's easy to extrapolate that the brave and muscular jocks were the first to get out of the gene pool. That was not a survival trait.
Let me guess... anything that doesn't involve 7 hours of meetings a day and colourful power-point foils, doesn't count as design or important to you?
Guess what? 90%+ of programming _is_ design and analysis, even if it happens in front of the computer. The routine mechanical parts are already handled by the compiler, IDE, plugins, standard libraries, frameworks, etc. That's the easy part.
The hard part is taking a problem and splitting it into an architecture and algorithm that solves the problem. Preferrably also in a way that's robust, easy to maintain, and easy to change when the client comes and says that now he wants something different. Those don't happen by themselves. That's what programming is all about: mostly design work.
Of course, if the respect you have for programming work is summarized by the words "code monkeys", you probably do get monkey quality at the end of the day. The pipe dream and marketting fraud of the last 20 years straight was that somehow you could buy a silver bullet that makes any monkey able to write a good program. Never happened so far.
Of course, it still doesn't stop idiots from trying. When you read statistics like "68% of Java 'programmers' don't even know Java" or "3 out of 4 programmers can't actually program"... well, you know who hired them. Someone who thought that it's all monkey job and hired the cheapest monkeys.
Of course, then the programming takes ages to finish, is awfully buggy, is an unmaintainable mess, and 2 years later ends up scrapped and programmed from scratch all over again. But hey, this time we have a silver bullet +1. It surely can't go wrong again this time.
Either way, I'm not saying there isn't a time and place for meetings, documentation, and drawing a grand diagram on the whiteboard. There sure is. And there sure is a need for people who, yes, mostly do analysis and architecture design. Yep. Please do hire those.
But at some point, _someone_ has to sit down and implement it. Someone like me. Call him a "code monkey" if that makes you feel somehow superior. But someone has to do it.
You can't have only meeting-happy people sitting around and showing off colourful powerpoint foils, 8 hours a day, 5 days a week, and have the program auto-magically just materialize sometime before the deadline. Someone has to actually sit down at a keyboard, and implement that grandious architecture and design sometime.
And at thet time, they better have a door they can close, so that they can concentrate on that work. It's a mental exercise, not just mindlessly typing like a secretary. If they have to listen to 5 others in 2 different conversations about their vacation, trips, car, and whatever else, it's damn hard to think about converting that spec into an algorithm.
Oh, I can easily believe that there are tons of lemmings getting sucked into this corporation battle. Heck, I can even see around me every day. It's even become the current IT fashion to be anti-MS. Gives some people a sense of belonging to some sad community, I guess.
Don't get me wrong, if you have nothing better to do with your life than donate work, time and money to helping Corporation A against Corporation B, I'm not even going to try to stop you. Sure. For all I care you could just as well start a "help big corporation CEOs buy a new yacht" charity, or just send a donation to whichever corporation you favour. Please do.
Either way, that's the beauty of it. Unlike Microsoft's think-tanks, this is one case of propaganda which actually worked astonishingly well. I'm impressed.
I'd say that whoever came up with that idea deserves a big bonus, but... here's one more piece of trivia for you: it was invented by Microsoft itself. Noone really gave half a damn about Linux until Microsoft mentioned it as a competitor in their anti-trust lawsuit. _Then_ everyone and their grandma, including the corporations, started actually rallying around what seemed like the +5 magic weapon that could defeat Microsoft.
Then again, who knows? MS may well be in control of this after all. Suddenly all the rebels-without-a-clue who were ranting and raving for Novel Netware, Solaris, IBM OS/2 and whatever, now are suddenly all Linux zealots. Linux has already cost Sun, for example, more server sales than it cost Microsoft, plus made Sun dump money into supporting it.
Either way, it will be an interesting battle to watch. I already have the popcorn ready.
"In their opinion, open source development should be best left to companies that develop software"
And that would be different... how?
Most of the OSS work _is_ done by companies. If you look at who contributes to the kernel, GCC, various other stuff, there's one helluva lot of people with email addresses from IBM, Intel, Red Hat, SuSE, Sun, etc. Or who acknowledge being funded by a company. (E.g., ReiserFS is sponsored by SuSE.)
The whole thing is one big FUD and astroturfing game between corporations.
In that corner you have MS, with its funded think-tanks trying to sell one illusion.
In the other corner, you have a bunch of corporations pissed off at Microsoft, pitching their funds into hopefully hurting Microsoft. And actively promoting their own FUD and lies. Including the myth that Linux somehow happened by itself. That somehow thousands of hackers weren't paid to code an anti-MS weapon, but just spontaneously did it all by themselves in their free time.
Still disguising paid work as some grassroots movement against MS's oppression. Shouldn't that count as astroturfing too?
And as astroturfing goes, I'd say MS isn't even the biggest liar in that game.
Yes, and how many of the Windows services listen to the network? I'm looking at the services list on a Windows 2000 computer right now.
Does the "Login" service on Windows listen to incoming connections? Well, no.
Does the logger listen to incoming TCP/IP connections? I don't think so.
Does that task planner listen to the network? Well, no, just like any Unix cron daemon doesn't.
Does the printer queue accept incoming connections? Nope.
So _you_ cut it out with the FUD already. Yes, there are a couple of services which ought to have been firewalled by default. But that's it: 2-3 services. Not "waah! Run for the hills! 30 services with remote vulnerabilities!" that some linux zealots make it sound like.
And let's talk about another thing. Sure, it's fun to moan and bitch about all the poor Windows 2000 users who got hit by some RPC virus, because the computer wasn't firewalled by default.
Well, have you used a _Linux_ distro in the year 2000? Let me tell you that back then the damn thing not only didn't install any firewall by default, it also loaded 3 times more daemons than Windows 2000 ever had services. I even ended up with an Apache with PHP started by default, a MySQL server, etc.
And let's talk about where the terms "rootkit" or "to get rooted" started. Or where did the advice to never surf or use IRC as root start. Right. In the Unix and Linux world. It used to be that if you took a Linux computer on IRC without a firewall, you'd have another user logged in, within the first hour or two.
It took a _very_ long time for Linux to get its shit together and start checking buffer sizes too. Or to not listen on two dozen ports by default.
Yeah, now Linux is getting a helluva lot better. So is Microsoft's shit, gradually. They actually both went and are going through the exact same stages. Linux may have a little head start nowadays. Praiseworthy, but hardly justifying the infatuated moaning about how MS only ever codes crap. Again: Linux went through the exact same stages itself.
Think of what happens when a normal sabot round hits. It's also just a sharp bar with fins, much like a medieval crossbow bolt.
The friction as the bar punches through a hard target, will turn the rod itself into molten metal and partially vapour. In the case of a metal armoured target (e.g., a tank or ship), some of that metal too. The liquid spray and partially vapor metal that formerly was the rod, will flash burn and literally cook anyone behind that wall.
I.e., so far, if you hit a hospital or a house, not only you'll do massive structural damage, you'll also cook quite a few people inside. Hitting a gas station or refinery, well, that can get quite spectacular.
But it gets better. Heavy metal burning in air produces, unsurprisingly a fine dust of metal oxide. It can be inhaled, it can contaminate ground water, and it can get on the clothes and skin of kids playing in or near the destroyed building or tank.
And the funny thing with heavy metals, is that they're toxic. They also tend to stay inside you for the rest of your life, once they entered your body.
The problem with depleted uranium rods isn't that they're radioactive. They're actually nowhere _near_ being dangerous enough because of radiation. The problem is each hit produces kilos of toxic dust.
Now I do understand that war is war, and you'd better destroy an enemy tank by any means, before it kills _you_. It's not pretty, it's not humane, it's war. Fair enough.
But at least have the decency not to pretend that your shit stinks less and never causes collateral damage. If a few grams of anthrax were (rightfully so) considered a terror attack, how do you call the many _tons_ of toxic uranium oxide your troops left all over Iraq? Right.
Again, I understand that war is war. But precisely _because_ it's war, it's never a clear cut case of "those are the 100% bad guys, and ours are the 100% good guys who never cause any civilian casualties." No weapon ever was 100% clean, and modern ones have the tendency to become less and less clean, rather than the other way around. Yours and theirs alike. Might as well stop pretending that you have some magical weapon that only kills the enemy.
Well, yes and no. I still see it as a contiunation of the real damage that overclocking did, historically. That is: hurting other people.
What caused Intel and AMD to lock the multipliers, a few years back, was a much worse phenomenon: dishonest OEM's selling overclocked systems, without even testing if they work at that speed.
A lot of moms and pops back then bought an expensive 150 MHz Pentium system, but under the heatsink it really had an overclocked 100 MHz chip. Or their kid bought a chip marked 150 MHz, except it really was a remarked 100 MHz part. Again: bulk remarked, without any testing.
Now your normal overclocker at least knows that they've overclocked their system. If it doesn't work at that speed, they reset the BIOS and try a lower speed.
Those moms and pops didn't know, and wouldn't have opened the case to mess with FSB speed jumpers and multiplier jumpers anyway. All they knew was that their shiny new "Intel Inside" computer crashes randomly, and sometimes needs to be left to cool down before it boots again.
That wasn't just cutting into Intel's profits, it was giving them a bad name. All those people only knew that they bought an "Intel Inside" computer and it's crashing. Lots.
When Intel first implemented the multiplier locks, for a while it was the AMD and Cyrix chips that were used in this fraud. And unsurprisingly, then you started hearing people complaining that "AMD processors are unstable".
Heck, I was talking to an IT professional last month, and when I mentioned the VIA/Cyrix CPUs as a silent low power (if slow) solution, he _still_ was like, "but Cyrix CPUs crashed lots!" and "Why would you want a CPU that crashes?!?" After all these years, VIA is still damaged by what those dishonest OEMs did back then.
I.e., it wasn't just the cost of support calls, it actually caused a lot of lost sales in the long run.
Nowadays most OEM's know better than to mess with the FSB speed, because it's easily visible. However, your kid who wants to brag about his 3D Mark score, or the "smart" computer-oriented neighbour who helps you tune your system, or even the occasional idiot employee if you have a company, don't.
They tweak it in December when it's cold, then in July or August you start wondering why your computer starts crashing. Well, duh. Because when the ambient temperature is 20 Fahrenheit higher, so is the CPU temperature.
With the P4 thermal throttling it can get even worse. The computer might look like it works, it will even finish a run of SuperPI or 3DMark, but after a while it starts going into thermal throttling mode every 2 seconds. That's something you'd be hard pressed to diagnose if you're the average non-geek end-user. You just see that the computer crawls or has random hickups where nothing happens.
I.e., there still are very good reasons why an end-user might actually _want_ a physically non-overclockable computer, and there's a good reason why Intel doesn't want them to start thinking "Intel sucks."
There's a reason why ESR came with that idea. Code only happens when you sit at the damn keyboard and type it, not when you're spending 7 hours a day talking to everyone you can find in the building.
Coding is inherently a _very_ boring activity, if you're a total extrovert. And I can see it around me every day. The ones who produce good code and lots of it, are the ones who can shut up for hours straight and just program.
This doesn't mean being a complete hermit, and unable to communicate at all. Sometimes, yeah, it's necessary to talk to someone else in the team. Sometimes you have to convince people of your vision of the architecture. And the occasional chatting pause at the water cooler or smoking place is OK, too. (Noone is 100% introverted either.)
But in the end, to actually have a program by the deadline, and earn your 8 hours a day pay, you damn better be able to spend at least 7 of them actually coding.
On the other hand, the least productive two, the ones who haven't actually produced anything in two years straight (not a joke), are also the most social people. Not only they'll talk to each other for hours, they'll even turn any communication with other team members into a 2 hour negotiation.
To get any of them to actually fix their own bugs, it turns into something resembling a negotiation with terrorists. You first have to explain to them why you want that bugs fixed, why you can't possibly live with their function returning the wrong result, listen to their view of why it's OK, listen to their grandious view of their architecture and why it shouldn't be changed (even if it returns the wrong result or crashes), etc.
Not only they're not producing anything in that time, they're also keeping other people from producing something.
When such people get promoted, it's even worse. They end up calling endless pointless meetings, just because they're bored. The kind of meetings where in the best case you spend 2 hours learning that nothing is new and worth discussing, and in the worst case you spend 3 hours hearing about their vacation or their kids. The kind of pointless meetings that keeps a whole team from working, just to entertain a bored PHB.
Either way, please do realize that some people would rather concentrate and work than listen to you. Hence the request for doors.
The absolute worst environment I've been in, was one freaking big room with 20+ people in it. No walls, no cubicles, just a ton of people in a cathedral sized room. And with the accoustics of a cathedral.
At any given time you'd hear at least two different conversations, one co-worker slurping tea in the loudest possible way, one idiot listening to music on his speakers (I bought him headphones, but he said he hated headphones and continued the noise pollution), 2-3 idiots taking a break to play Counter-Strike (at least one of them on the speakers, on a bad day also with a subwoofer), etc.
It was such a noise cacophony that it was plain old impossible to concentrate on doing any work. Eventually I started listening to loud music on the headphones just to cover that disruptive ambient noise. Of course, that was a bit of a distraction in itself, but it still beat listening to the equivalent of coding in a railway station.
Just wanted to add that synchronizing a collection isn't as easy as it sounds, either.
Contrary to the mistake everyone makes when they start with Java, just using a Vector or declaring every single method as synchronized doesn't even start to cut it. You'll still get rare race condition exceptions if you do only that, as soon as one thread uses an Iterator.
To actually use a collection in a truly thread-safe manner, you have to separately synchronize in a way where every single iterator loop is in a synchronized block. To be precise, synchronized to the same monitor as every single method which can add or remove elements. Anything less than that is a very rare race condition waiting to happen.
And that's a lot less easy than it sounds when the iterator loop is buried deep in Swing and not under your control. You end up needing to also move all data transfers to the element's model in those Runnable implementation for later invoking.
And you'd be surprised how often people get that wrong.
Swing or no Swing. I've seen cache implementations which lock wrong too. But Swing just begs for that to happen.
OK, guess I better answer the "invokeLater()" thing before I get 10 more replies to the exact same end.
Give me some minimal credit, people. I know how to invoke later. For tiny projects where you only need to invoke later, but don't actually share any collections between a thread and a GUI model, it even works wonderfully.
I also know that every single collection class throws an exception if you change it while someone (e.g.: a Swing component) traverses it with an iterator. And therein lies the problem.
When that loading thread shares some baroque collections with Swing, you end up having to add synchronization to each of them, or the very Swing event Thread will die to an exception. OK, that is at least obvious. (We all know we should synchronize collections for multithreaded access, Swing or no Swing.)
A more perverse problem, is when that loading has to add or remove elements to a Swing List or to components to a Swing form. It's not even hard to end there. Just takes a spec along the lines of "I want this and that to only be on the page if the loaded data contains this other thing."
There the collections may not even be under your control, but are burried deep in Swing. It's not that hard, especially if you bring someone new into the project, to see them code something which ought to work all right in the Windows API, but bombs the Swing event thread.
Either way, whether you actually add "synchronized" blocks, or move code into a Runnable implementation for invoking later, it's still extra work. It's still moving it in another block. And still a chance for someone to forget to do it. Or do it wrong.
That's all I'm saying. If Swing was synchronized to start with, like, say the normal Windows API is, you wouldn't have to do it.
That said, yep, your reasons are very good ones too.
The Commodore didn't have a Z80 or 8080, did it? Buy ZX Spectrum would indeed qualify. You're right there. Forgot about that one.
I've programmed both in assembly, so, yes, I have some idea of what they can do :) I'm not concerned with what the ALU can do with 16 bit operands. At the very least you could always take the same C code and generate Z80 code out of it, instead of 8086 code anyway.
I'm concerned with space. One thing the 8086 does do, and the Z80 doesn't do (or not natively), is being able to address up to 1MB of RAM via segment registers. Somehow I just can't see Linux run in 64K of RAM, no matter how you optimize it. (And some of those 8080 and Z80 machines had less than a full 64k available, since they also had to shove a BIOS somewhere in that address space.)
Now you could do bank switching and whatnot in hardware, to swap more than 64k in and out of the Z80's address space, and code kernel support for that. But that'd pretty much be designing a new machine, as opposed to reusing existing 8080 computers that used to run CP/M. Most of those had no such hardware.
Well, various other flavours of Unix are a different story. Unix or some variant have been ported to pretty much every single computer ever made in the last 20 years or so. The parent poster explicitly said Linux, though, which is why I was asking.
"Is there something wrong with this approach? Sounds reasonable to me. Might be a tad memory-intensive, I guess."
There is nothing inherently wrong with caching already open (but invisible) frames, if that was your design to start with.
What's wrong is that you end up _having_ to modify your architecture like that, just to get out of the inherently leak-prone design of Swing. Not because you did a performance analysis and decided to cut down on time with caching. But because you've already spent pointless weeks tracking listener allocation and deallocation, you're already hopelessly past the deadline, and still can't get Swing's normal architecture to work right.
Either that, or to give an example from another actual project, you end up extending every single Swing class to include some form of listener tracking, and a baroque dispatcher mechanism to help with that. (Ironically enough, in the end they still ended up with the "closed window cache" way out, when some new team members failed to use that baroque dispatcher properly.)
Either way it's extra work, which shouldn't have been there. Why are listeners hard references anyway? Why can't they be a soft or weak reference that doesn't prevent garbage collection? Why do I have to go through loops like that just to get a frame out of memory? Wasn't the whole idea of Java and its Garbage Collector to _avoid_ personally tracking pointers?
I.e., why can't it be like, say, the Windows API, where I never had to do such silly tricks? I'd just close the window, any child windows or controlls would automatically get the right event, so that they too can unload any resources they keep, and that would be it.
If anyone actually made Linux on an 8080 CPU, I'll _really_ want to know how. For whoever isn't an old dinosaur like yours truly, the 8080 was an 8 bit CPU and could address a total of 64 KB of RAM. (Yes, that's _kilo_bytes, not megabytes.) It also boasted speeds in the low single digit MHz range.
Now maybe you mean 8086, but even then... if anyone actually got Linux to run on anything lower than an 80386, I'd really want to hear about it.
Well, guess we can both aggree that Swing is pathetic crap. But I also can't see how Swing could ever be considered a "clean API".
E.g., take the listeners memory leak problem. I don't know of _any_ major Swing project that didn't end up chasing listener leaks. (No, home brewn programs with 5 buttons and 2 windows don't count.)
I also know projects, and _been_ in one, which ended up throwing up a two hands salute to that problem. Basically, "screw it, we'll implement the windows/frames/whatever as singletons, or recycle them in a list for future use, rather than spend another month chasing the last listener." (If you're new in a project and the architecture involves singletons for every single frame, or recycling windows into a cache instead of closing them, that's your clue: they ran into that problem, spent weeks, and gave up on even trying any more.)
E.g., take the idiocy of Swing being inherently non-thread-safe. Then the client comes and says "yeah, it's nice, but this loading sometimes takes 5 seconds, and in the meantime it looks like the app has crashed. Can't you display some progress bars, or something? And can't that other thing preload in the background?" Whop-de-do. Now you're cooking with threads. Time to go through the whole program, adding synchronized blocks (or synchronized child classes of the original Swing controls) everywhere. And still end up spending weeks to chase some spurrious thread problem, which occasionally crashes the Swing dispatcher thread.
Seems to me like if you took C or C++, and any major GUI API of your choice (X or Windows, pick your poison), you'd still end up with less problems. Even adding the regular C memory leaks from the non-GUI part of that program, it usually still ends up better than the Swing equivalent. Which defeats one of the major advantages Java was supposed to have in the first place.
Don't get me wrong, I'm not generally against Java or anything, but a Swing fan I ain't. It could be a textbook example of how _not_ to design a GUI API.