Loss of jobs starting with manufacturing, but now quickly moving up through intellectual "white collar" professions, points to a growing joblessness with no end in sight.
The loss of US manufacturing jobs essentially started in the '70's and finished in the '80's. You might as well be wringing your hands about the "loss of jobs" in agriculture in the 1940's. Guess what: those manufacturing workers haven't just been sitting around unemployed for 20 years. They have gotten into different careers, relocating if need be.
To put things in perspective, the recent tech downturn is MUCH smaller in its impact on employment than were the end of manufacturing and agriculture. Both of those fields shed 10's of percentages of the country's total population in employees in just a few short decades, and yet the 20th century in America was hardly one of starvation and rampant joblessness. The move from agriculture to manufacturing, and from manufacturing to services, were profound shifts in the nation's output. What has happened in tech, on the other hand, is kind of a sidenote. It's comparable in scope to what happened on Wall Street in the '80's. In both '90's tech and '80's Wall Street, a media-propelled hoard of prospectors crowded into a field that was perceived as "lucrative", creating a glut of workers for relatively specialized fields. This glut, coupled with an eventual market down-cycle, made the field less lucrative than many had hoped, and lots of people lost their jobs. But guess what: both the computer industry and finance have carried on, and just as the world isn't crowded with unemployed bond traders who lost their jobs in 1988, I strongly doubt 2020 will see us with a surfeit of unemployed web developers who just never found anything else to do.
Hey, dip stick, your last comment is way outa line.
No, it was the original poster who was way out of line. Many, many people in this world really do run a risk of losing their own or their families lives to starvation. The originial poster, and I would claim, you and the candidates you're seeing have trouble finding jobs, are not among that unlucky many. Claiming to be so is shameful, and cheapens the suffering of those for whom starvation is more than a metaphor.
* Money that leaves never supports U.S. economy and infrastructure. *
Wrongo. If it's true that US dollars spent abroad never come back to the US, why would anyone abroad perceive dollars to have any value at all? Don't say, "because you can convert US dollars to local currency!" This is an effect of the fact that foreigners perceive dollars as valuable, not a cause.
The ultimate value of a US dollar, anywhere in the world, comes from its power to buy goods and services from US businesses, period. Those dollars being spent overseas find their way back to the US. Perhaps indirectly, perhaps over many years, and perhaps passing through many hands (and foreign reserve banks) on the way. But if they weren't ultimately headed back into US pockets, nobody overseas would bother exchanging them.
We are all reduced to the same level of living enjoyed by billions of starving people all over the world.
Really? ALL of us? ARE already reduced. Hmm. It seems like you, at least, haven't been reduced quite to starvation level yet. In fact, you seem to have enough surplus time and energy to be posting to a rather wanker-y tech website. I'm sure the world's (very real) starving multitudes don't appreciate being equated with disgruntled, laid-off HTML jocks who had to buy a less nice car than they'd hoped for.
Before you starve to death, don't forget to hock the computer you're posting to slashdot from. It'll buy a lot of happy meals.
"First person interitave"? I think you mean the familiar imperative. Va is also the third person present. "No va" is a complete sentence, meaning "he/she/it doesn't go." The whole story is total hogwash, never the less; "nova" is also a Spanish word, and real, live Spanish speakers have no problem with the distinction. My Puerto Rican grandfather actually owned a Nova, and was mildly amused when the "No Va" thing was pointed out to him after years of ownership, but didn't come up with it on his own.
had to have someone brand new enter new REAL cash into the market in order for Y to "cash out"
Ever heard of dividends, Mr. "simple math"? Companies do make profits, and distribute them to shareholders in the form of cold, hard cash.
This makes the stock market far from the pyramid scheme you describe. In the example above, person Y might buy the security for less than the price that X paid, and X might still be perfectly happy, because X earned a tidy dividend stream while owning the stock over the years. The opportunity to participate in profit-making through dividends is the real, tangible value of stock. It's why stock isn't just a piece of pretty paper. For companies that don't currently pay dividends, the promise of future dividends underlies the current stocks' prices.
Squirreling away a small amount of money, frequently, in a market-weighted group of common stocks over the course of a lifetime has been the surest way to wealth during the twentieth century. While some caution is in order, the fact that people taking massive risks occasionally get massively burned is no reason to keep your money in your mattress. Even cash is risky; inflation eats it over time much more surely than the stock market.
Not quite. "Network byte order" is big endian. So on big endian ppc's, which macs are, all those "ntos" macros, etc., expand to NOPs. Once you introduce little endian machines into the mix, they start doing real work to transform internal representations for the wire.
The real tragedy is when you have homogenously little endian machines; e.g., a network that only has PCs on it. An integer gets byteswapped twice to end up in exactly the same byte order it was all along.
IANAEconomist, but all of the folks saying, "It's econ 101! In competitive industries, companies can't change prices, MS is warning that they're going to change prices, ergo they're a monopoly!" should be aware that economics has retreated from this simple "price setting" == "monopoly" claim since the 1930's. Now, it so happens that microsoft really is a monopoly. However, the fact that there is some elasticity in their pricing doesn't prove it.
By the "economics 101" definition, common sense tells us that very very few modern industries are "competitive," because in almost all real industries, companies have pricing power. E.g., Nike is not a monopoly, but they obviously have a lot of latitude in how they price their shoes.
The classical market model, wherein producers have absolutely no control over the prices of their products, was a great model for the mercantile systems of the 18th and 19th century, when they were developed. If you're a cotton planter, or molasses distributor, or lumber baron, etc. your production accounts for a small enough fraction of available goods that you really can't effect prices at all; you have no choice but to take the going price.
Very few modern industries fit this model, in part because not many modern industries involve true commodities; there's always some difference between McDonald's and Burger King that's important enough to some consumers that they'll pay a bit extra for their favorite. But also because most industries have a few behemoth leaders that are responsible for most of the production. But even for chemically identical commodities like steel and salt, companies end up having pricing power because so few companies account for so much of the production. In the US, if C&H stopped selling sugar, there would be a noticeable "sugar crunch"; this effectively gives C&H an ability to price sugar, since consumers can't credibly threaten to just get all their sugar somewhere else.
(Been reading Galbraith on my AM commute lately. Would genuinely appreciate any real econ types smacking me down.)
You've got to be careful with this line of reasoning. The basic argument: "Oh it panic'ed? Your hardware suX0rz!!11!" will be familiar to those who lurked on linux-kernel in the pre 2.0 days. It's been a while since I've seen it in its textbook form. Now that Linux has 20 times the user base, why don't we see 20 times the panics caused by flaky hardware? Has hardware quality improved this much in the meantime? Or were some of those panics potentially reflecting real problems in the kernel?
Don't get me wrong; it's perfectly possible that this problem really was a result of bad hardware. However, for my money, reiserfs is nowhere near mature enough that we can just assume that any problems are the result of user error. For all of you getting ready to reply, "I've been running reiser for a gazillion years and it's never been a problem for me!", please save the typing. Filesystems are complicated things, and sometimes bugs can linger for years before a user bumps into the usage pattern that exposes some weird bug.
Right, but intense statistical analysis won't make the ants and bacteria any more intelligent, or affect how they perform.
No freaking kidding. That's why I chose the analogy. The only person claiming that studying baseball will make individual players more intelligent is you. What studying baseball has accomplished, and will continue to accomplish, is making managers better able to decide the value of individual players. Capiche?
Let's get out the sock puppets, ok? Suppose you attach tiny little harnesses to ants, and have them pull carriages. That's what you do for a living. You make money at it, and you're locked in a zero-sum struggle with other ant-carriage competitors for your slice of the ant carriage pie. Conventional wisdom, and tradition, dictate that red ants are the best sort of ants for this work. However, you've done some scientific study, and discovered that, in fact, army ants are ideal. You're able to reduce your costs, and you wipe the floor with your competition, at least until they catch on.
Notice that the ants are no more intelligent; yet your "ant team," as it were, is more effective than it would have been had you not studied the task.
As for your claim that steroids are the dominating factor in the modern game, how would you back up such a claim? Home run records get headlines, but it is far from clear that they win pennants. The only way you would be able to argue this point would be to study baseball in a systematic way, the very thing you're claiming is a waste of time.
You seem a little confused about this whole "baseball studies" enterprise. Saying that players are stupid is a non-sequitur. While it sounds like your dismissal of players' intelligence is the result of some sort of chip on your shoulder, let's grant for the sake of argument that the players are stupid. Ants are much stupider, and eubacteria more stupid still, but smart people can still observe them and reach interesting, non-trivial conclusions.
The idea isn't that players taken as individuals are strategic geniuses worthy of study; indeed, individual players' strengths and weaknesses are mostly set in stone by their early 20's. The questions these geeks are studying are for the most part not, e.g., "how do you pitch to left-handed slugger with such-and-such a count,"; rather, they are questions about how different players contribute to a winning team. How important is being able to hit? How do you really measure hitting (hint: not batting average)? How do you measure defensive prowess? Is it possible to separate defensive prowess from good pitching? And what is good pitching, anyway (hint: not just a low ERA)? These are essentially statistical problems, and answering them well requires that we build better mathematical models of the game than we've done in the past. Since smart people have only recently gotten interested, there are lots of results that are counter-intuitive. E.g., stellar defensive plays often make highlight reels, and play a large role in fan psychology, but data mining suggests that awesome defense doesn't matter that much.
I hope this doesn't come across as inordinately ugly, but since you're calling yourself "the cream of the crop", and talking about your super-genius friends stuck pumping gas for a living, I got curious about just what sort of rocket science the good folks at Array Services are cooking up.
Array Services is an open source, network solutions provider. Offering innovative, yet proven Linux solutions for network, and e-commerce applications. We feel that by offering open source solutions we can better serve your specific infrastructure needs....
It sounds an awful lot like you guys package and integrate existing software to apply it to various customer needs. Some paint, duct tape, nails, glue, perhaps the odd pulley or two, et voila': another e-commerce widget. There's nothing wrong with that; it's honorable work, and I don't doubt that you provide real value to your customers. But it's also a long way away from the sort of hardcore R&D taking place at companies pushing the edge of the technologically possible. So, with that in mind, I tentatively call bullshit on the following claim:
Could you please repeat that about low-grade tech skills to all of my recently laid-off friends with Masters of CompSci degrees and patents pending?
If:
your friends really have masters degrees that they didn't get out of cracker jack boxes;
their patents aren't raging crocks;
they're still looking for work;
and they're willing to relocate to the Bay Area
have them send me a resume. I could use the referral bonus. And yes, I'm quite serious.
Despite the double memory/instruction access time created by accessing words twice the size of the 32-bit chips, I think they're using the new chaining instruction set to double or triple most of their refresh operations.
Yeah, that "double memory/instruction access time" is a doozy. Luckily they reversed the polarity of the "chaining instruction set" to create a discontinuity in the computron field. By rerouting the tachyons to the ALU, they've been able to double-pump the, umm, chain cache.
Re:Given that they need the money, I doubt it.
on
EMC To Acquire VMware
·
· Score: 4, Informative
Speaking as a VMware employee (not speaking for the company, yada, etc.), I'm feeling rather more "stoked" than "burned in the ass." In fact, I'm turning freaking cartwheels in the streets over this deal. The whole idea with pre-IPO companies is that you take the risk of working somewhere unstable in exchange for a larger than average stake in the company. Remember that whole "getting paid in options" thing? That's still how startups work.
So, it's not just three people walking away with 9 digit checks, as you are imagining. It's hundreds of employees whose stakes are now worth 6 digits. The terms of our purchase are quite likely better for me than an IPO would have been. From the inside, it looks as though the board actually gave a lot of thought to how this would impact employees.
Guess again, or just read the article. "The company has been profitable for five quarters in a row, and should post between $175 million and $200 million in revenue next year." That's a sizable bite of EMC's annual revenue of $2.2bn last year.
Same level of quality? Have you actually seen the code coming from India?
Call me "PC" if you must, but this seems like borderline racist thinking. You are, I hope, aware that India offers state of the art technical education, right? I mean, because, otherwise, you'd kind of be shooting your mouth off about something you, you know, don't know anything about.
So if education can't explain it, what is it? The hot climate? All that spicy food? What? Spell it out for us, Daytona955i. We're all ears.
I work with many people born and educated in India (and Asia, and Europe, and the former Soviet Union) and some of them are absolute cream-of-the-crop, as-good-as-you-could-ever-hope-to-be, top 10th of the top percentile good. Smart people are rare everywhere, but it's a huge world, and I don't ever kid myself that there isn't some hungry kid in Uzbekistan who could do my job better than me for half the money.
Ehh. In my opinion, people overestimate how big a deal x86 architecture complexity is, in part because it flatters their preconception that Intel is evil. ("If only dastardly Intel hadn't been holding the world back with this demon architecture from hell, think how fast CPUs could be now!") While working at VMware, I've gotten to know the x86 architecture on a first name basis. He now lets me call him "Archie."
While Archie is undoubtedly an ugly, drunk screw-up, he's really a droplet in the ocean of effort that goes into a competitive CPU implementation. Yeah, we've got lots of code to deal with him, and he's an ongoing source of work, but not all that much code, nor that much work. If Archie were really such a terrible guy, it wouldn't be possible for Intel and AMD to be eating so many RISC vendors' lunches.
Mike Johnson, the lead x86 designer at AMD, probably put it most succinctly when he said, "The x86 isn't all that complex -- it just doesn't make a lot of sense." It's peculiar all right, but not so peculiar that it can explain Transmeta's failure to be performance competitive. From speaking with Transmetans, I get the strong impression that they got bogged down because making a high performance dynamic translation system is ridiculously hard, rather than, say, because they just couldn't get the growdown segment descriptors right.
Dude? Pantani's a climber. Or he was one, before he got all depressed and started hitting the canollis hard.
Cippollini, Petacchi, McEwen, and Zabel are the current cream of the sprinting crop. And you're indeed right that Cipo puts out over 1 horsepower in full flight.
My perfectly average eight year old daughter uses Debian.... She prefers it to windows xp because "it has better games", "cooler menus", and "no blue screens!"
I don't know you, cshark, or your daughter. But I'm just going to go out on a limb here, and claim that this never happened. Specifically, your eight year old daughter never said to you, unprompted, that she liked Debian because "no blue screens!" Any eight year old who is significantly vexed by blue screens is a far cry from "perfectly average."
Someone was bitching "why can't XYZ OS run under VMWare if it runs perfectly well under generic PC hardware". Someone responded to the effect that VMWare was tuned to make certain concessions for the OSs they supported.
Right. The OS'es we "support." Not the OS'es "we're able to run." And those "concessions" are mostly performance trade-offs, not correctness.
It's still true that some OS'es don't run; but that's because our software has bugs. OS'es sometimes have bugs, too, though if the OS is important enough, we'll work around it. The bugs that prevent you from running the OS that some drunken Swede cooked up for course credit are admittedly less important to fix than the bugs that, say, prevent you from running Linux. However, in the long run, we try to fix even the bugs exposed only by drunken Swedes.
That's why AtheOS, OpenStep, BeOS, NetBSD, FreeDOS, B-Right, Plan9, QNX, and myriad other commercially unimportant OS'es run ok. Not because they're important to our customers (man, oh man, they aren't), but because they enable us to be sure our x86 virtualization layer is reasonably correct. That way, when Ingo Molnar decides to start using 80286-style 16-bit tasks with lots of grow-down and conforming code segments to do system calls in Linux 2.6, we won't get caught out too badly.
They need to tweak VMWare for each OS. A true emulator, like bochs, doesn't need this tweaking.
How high are you? Do you really think VMware, Inc. pays me to "tweak" our monitor so ~12 slashdot-reading customers can try running plan9 in a VM? Plan9, OpenStep, AtheOS and the rest of the hobbyist OS'es just work, because VMware contains a basically correct x86 virtual machine monitor. Much like they just work on bochs, a basically correct x86 emulator. The VMM and the emulator accomplish the same computational task; they simply use different techniques to accomplish it.
If you have a copy of the Lions Book, flip to line 2527. Then look at lines 87 through 205 of/usr/src/linux/arch/ia64/sn/io/ate_utils.c.
atefree and atealloc are verbatim copies of UNIX 6th Edition's malloc and free. The only changes are mapping the ancient C compilerism "=+" to "+=", some comment changes, some ASSERTs, and a spinlock. The code is undeniably copied.
Do I _REALLY_ want to pull in libpng and libSDL just to do this?
Yes.
What kind of risks does pulling these libraries in add to my project?
The risk that you will hit a bug in the library. Which is much smaller than the risk that there will be a bug in your one-off k-spiff png display engine (hence, OOKSPDE).
How much will this bloat my code?
It will bloat your code by the additive inverse of the code size of your OOKSPDE. The user already has the library on their disk. If it is dynamically linked to your executable, they pay nothing to use it.
Will users be confused from the different versions of these libraries?
Would you rather they lose data because your broken OOKSPDE doesn't handle transparency properly?
Turns out it's usually simpler, easier, and less risky to just roll your own.
It sounds like you either have a delusionally high estimation of your own abilities relative to those of your library-writing peers ("Of course the code I write will be faster, more correct, and less bloaty than the specialised code that those people who really understand the problem and spend time solving it well!") or you place very little value on your time. Oh well. Have fun writing png-frobbing code for the rest of your life.
I've worked with CS grads before and I'd consider recommending them for writing documentation or being a liason between the real programmers and the customers, but the ones I've worked with suck at writing code.
Funny, that. I've met exactly one self-taught software person who could tell his ass from a hole in the ground. Most people beating their chests about how they don't need some galdurn longhair hippy telling them how to code have learned some subset of a couple of programming languages, and think they're masters of the universe. Since programming has always been easy for them, they assume that they are gifted programmers, never stopping to notice that they aren't attempting anything particularly difficult.
Difficult programming is like chess. Even the most extremely gifted can learn a lot by studying other practitioners, and even very experienced people can benefit from the perspective that theoretical knowlege can provide. The louder someone proclaims the pointlessness of an education, the more sure I become that they've never attempted anything truly difficult.
Also note that W^X is also available on x86 in -current.
How do they accomplish that, when that the x86 doesn't differentiate between execute and read permissions for paging? Is is some sort of crock involving limits on the code segment?
Slashdot Mirror
Loss of jobs starting with manufacturing, but now quickly moving up through intellectual "white collar" professions, points to a growing joblessness with no end in sight.
The loss of US manufacturing jobs essentially started in the '70's and finished in the '80's. You might as well be wringing your hands about the "loss of jobs" in agriculture in the 1940's. Guess what: those manufacturing workers haven't just been sitting around unemployed for 20 years. They have gotten into different careers, relocating if need be.
To put things in perspective, the recent tech downturn is MUCH smaller in its impact on employment than were the end of manufacturing and agriculture. Both of those fields shed 10's of percentages of the country's total population in employees in just a few short decades, and yet the 20th century in America was hardly one of starvation and rampant joblessness. The move from agriculture to manufacturing, and from manufacturing to services, were profound shifts in the nation's output. What has happened in tech, on the other hand, is kind of a sidenote. It's comparable in scope to what happened on Wall Street in the '80's. In both '90's tech and '80's Wall Street, a media-propelled hoard of prospectors crowded into a field that was perceived as "lucrative", creating a glut of workers for relatively specialized fields. This glut, coupled with an eventual market down-cycle, made the field less lucrative than many had hoped, and lots of people lost their jobs. But guess what: both the computer industry and finance have carried on, and just as the world isn't crowded with unemployed bond traders who lost their jobs in 1988, I strongly doubt 2020 will see us with a surfeit of unemployed web developers who just never found anything else to do.
Hey, dip stick, your last comment is way outa line.
No, it was the original poster who was way out of line. Many, many people in this world really do run a risk of losing their own or their families lives to starvation. The originial poster, and I would claim, you and the candidates you're seeing have trouble finding jobs, are not among that unlucky many. Claiming to be so is shameful, and cheapens the suffering of those for whom starvation is more than a metaphor.
* Money that leaves never supports U.S. economy and infrastructure. *
Wrongo. If it's true that US dollars spent abroad never come back to the US, why would anyone abroad perceive dollars to have any value at all? Don't say, "because you can convert US dollars to local currency!" This is an effect of the fact that foreigners perceive dollars as valuable, not a cause.
The ultimate value of a US dollar, anywhere in the world, comes from its power to buy goods and services from US businesses, period. Those dollars being spent overseas find their way back to the US. Perhaps indirectly, perhaps over many years, and perhaps passing through many hands (and foreign reserve banks) on the way. But if they weren't ultimately headed back into US pockets, nobody overseas would bother exchanging them.
We are all reduced to the same level of living enjoyed by billions of starving people all over the world.
Really? ALL of us? ARE already reduced. Hmm. It seems like you, at least, haven't been reduced quite to starvation level yet. In fact, you seem to have enough surplus time and energy to be posting to a rather wanker-y tech website. I'm sure the world's (very real) starving multitudes don't appreciate being equated with disgruntled, laid-off HTML jocks who had to buy a less nice car than they'd hoped for.
Before you starve to death, don't forget to hock the computer you're posting to slashdot from. It'll buy a lot of happy meals.
"First person interitave"? I think you mean the familiar imperative. Va is also the third person present. "No va" is a complete sentence, meaning "he/she/it doesn't go." The whole story is total hogwash, never the less; "nova" is also a Spanish word, and real, live Spanish speakers have no problem with the distinction. My Puerto Rican grandfather actually owned a Nova, and was mildly amused when the "No Va" thing was pointed out to him after years of ownership, but didn't come up with it on his own.
Economies aren't closed systems. Labor adds real value that wasn't there before.
Ever heard of dividends, Mr. "simple math"? Companies do make profits, and distribute them to shareholders in the form of cold, hard cash.
This makes the stock market far from the pyramid scheme you describe. In the example above, person Y might buy the security for less than the price that X paid, and X might still be perfectly happy, because X earned a tidy dividend stream while owning the stock over the years. The opportunity to participate in profit-making through dividends is the real, tangible value of stock. It's why stock isn't just a piece of pretty paper. For companies that don't currently pay dividends, the promise of future dividends underlies the current stocks' prices.
Squirreling away a small amount of money, frequently, in a market-weighted group of common stocks over the course of a lifetime has been the surest way to wealth during the twentieth century. While some caution is in order, the fact that people taking massive risks occasionally get massively burned is no reason to keep your money in your mattress. Even cash is risky; inflation eats it over time much more surely than the stock market.
Not quite. "Network byte order" is big endian. So on big endian ppc's, which macs are, all those "ntos" macros, etc., expand to NOPs. Once you introduce little endian machines into the mix, they start doing real work to transform internal representations for the wire.
The real tragedy is when you have homogenously little endian machines; e.g., a network that only has PCs on it. An integer gets byteswapped twice to end up in exactly the same byte order it was all along.
IANAEconomist, but all of the folks saying, "It's econ 101! In competitive industries, companies can't change prices, MS is warning that they're going to change prices, ergo they're a monopoly!" should be aware that economics has retreated from this simple "price setting" == "monopoly" claim since the 1930's. Now, it so happens that microsoft really is a monopoly. However, the fact that there is some elasticity in their pricing doesn't prove it.
By the "economics 101" definition, common sense tells us that very very few modern industries are "competitive," because in almost all real industries, companies have pricing power. E.g., Nike is not a monopoly, but they obviously have a lot of latitude in how they price their shoes.
The classical market model, wherein producers have absolutely no control over the prices of their products, was a great model for the mercantile systems of the 18th and 19th century, when they were developed. If you're a cotton planter, or molasses distributor, or lumber baron, etc. your production accounts for a small enough fraction of available goods that you really can't effect prices at all; you have no choice but to take the going price.
Very few modern industries fit this model, in part because not many modern industries involve true commodities; there's always some difference between McDonald's and Burger King that's important enough to some consumers that they'll pay a bit extra for their favorite. But also because most industries have a few behemoth leaders that are responsible for most of the production. But even for chemically identical commodities like steel and salt, companies end up having pricing power because so few companies account for so much of the production. In the US, if C&H stopped selling sugar, there would be a noticeable "sugar crunch"; this effectively gives C&H an ability to price sugar, since consumers can't credibly threaten to just get all their sugar somewhere else.
(Been reading Galbraith on my AM commute lately. Would genuinely appreciate any real econ types smacking me down.)
You've got to be careful with this line of reasoning. The basic argument: "Oh it panic'ed? Your hardware suX0rz!!11!" will be familiar to those who lurked on linux-kernel in the pre 2.0 days. It's been a while since I've seen it in its textbook form. Now that Linux has 20 times the user base, why don't we see 20 times the panics caused by flaky hardware? Has hardware quality improved this much in the meantime? Or were some of those panics potentially reflecting real problems in the kernel?
Don't get me wrong; it's perfectly possible that this problem really was a result of bad hardware. However, for my money, reiserfs is nowhere near mature enough that we can just assume that any problems are the result of user error. For all of you getting ready to reply, "I've been running reiser for a gazillion years and it's never been a problem for me!", please save the typing. Filesystems are complicated things, and sometimes bugs can linger for years before a user bumps into the usage pattern that exposes some weird bug.
Right, but intense statistical analysis won't make the ants and bacteria any more intelligent, or affect how they perform.
No freaking kidding. That's why I chose the analogy. The only person claiming that studying baseball will make individual players more intelligent is you. What studying baseball has accomplished, and will continue to accomplish, is making managers better able to decide the value of individual players. Capiche?
Let's get out the sock puppets, ok? Suppose you attach tiny little harnesses to ants, and have them pull carriages. That's what you do for a living. You make money at it, and you're locked in a zero-sum struggle with other ant-carriage competitors for your slice of the ant carriage pie. Conventional wisdom, and tradition, dictate that red ants are the best sort of ants for this work. However, you've done some scientific study, and discovered that, in fact, army ants are ideal. You're able to reduce your costs, and you wipe the floor with your competition, at least until they catch on.
Notice that the ants are no more intelligent; yet your "ant team," as it were, is more effective than it would have been had you not studied the task.
As for your claim that steroids are the dominating factor in the modern game, how would you back up such a claim? Home run records get headlines, but it is far from clear that they win pennants. The only way you would be able to argue this point would be to study baseball in a systematic way, the very thing you're claiming is a waste of time.
You seem a little confused about this whole "baseball studies" enterprise. Saying that players are stupid is a non-sequitur. While it sounds like your dismissal of players' intelligence is the result of some sort of chip on your shoulder, let's grant for the sake of argument that the players are stupid. Ants are much stupider, and eubacteria more stupid still, but smart people can still observe them and reach interesting, non-trivial conclusions.
The idea isn't that players taken as individuals are strategic geniuses worthy of study; indeed, individual players' strengths and weaknesses are mostly set in stone by their early 20's. The questions these geeks are studying are for the most part not, e.g., "how do you pitch to left-handed slugger with such-and-such a count,"; rather, they are questions about how different players contribute to a winning team. How important is being able to hit? How do you really measure hitting (hint: not batting average)? How do you measure defensive prowess? Is it possible to separate defensive prowess from good pitching? And what is good pitching, anyway (hint: not just a low ERA)? These are essentially statistical problems, and answering them well requires that we build better mathematical models of the game than we've done in the past. Since smart people have only recently gotten interested, there are lots of results that are counter-intuitive. E.g., stellar defensive plays often make highlight reels, and play a large role in fan psychology, but data mining suggests that awesome defense doesn't matter that much.
Array Services is an open source, network solutions provider. Offering innovative, yet proven Linux solutions for network, and e-commerce applications. We feel that by offering open source solutions we can better serve your specific infrastructure needs....
It sounds an awful lot like you guys package and integrate existing software to apply it to various customer needs. Some paint, duct tape, nails, glue, perhaps the odd pulley or two, et voila': another e-commerce widget. There's nothing wrong with that; it's honorable work, and I don't doubt that you provide real value to your customers. But it's also a long way away from the sort of hardcore R&D taking place at companies pushing the edge of the technologically possible. So, with that in mind, I tentatively call bullshit on the following claim:
Could you please repeat that about low-grade tech skills to all of my recently laid-off friends with Masters of CompSci degrees and patents pending?
If:
- your friends really have masters degrees that they didn't get out of cracker jack boxes;
- their patents aren't raging crocks;
- they're still looking for work;
- and they're willing to relocate to the Bay Area
have them send me a resume. I could use the referral bonus. And yes, I'm quite serious.Despite the double memory/instruction access time created by accessing words twice the size of the 32-bit chips, I think they're using the new chaining instruction set to double or triple most of their refresh operations.
Yeah, that "double memory/instruction access time" is a doozy. Luckily they reversed the polarity of the "chaining instruction set" to create a discontinuity in the computron field. By rerouting the tachyons to the ALU, they've been able to double-pump the, umm, chain cache.
Speaking as a VMware employee (not speaking for the company, yada, etc.), I'm feeling rather more "stoked" than "burned in the ass." In fact, I'm turning freaking cartwheels in the streets over this deal. The whole idea with pre-IPO companies is that you take the risk of working somewhere unstable in exchange for a larger than average stake in the company. Remember that whole "getting paid in options" thing? That's still how startups work.
So, it's not just three people walking away with 9 digit checks, as you are imagining. It's hundreds of employees whose stakes are now worth 6 digits. The terms of our purchase are quite likely better for me than an IPO would have been. From the inside, it looks as though the board actually gave a lot of thought to how this would impact employees.
I'm guessing a few million bucks per year
Guess again, or just read the article. "The company has been profitable for five quarters in a row, and should post between $175 million and $200 million in revenue next year." That's a sizable bite of EMC's annual revenue of $2.2bn last year.
Same level of quality? Have you actually seen the code coming from India?
Call me "PC" if you must, but this seems like borderline racist thinking. You are, I hope, aware that India offers state of the art technical education, right? I mean, because, otherwise, you'd kind of be shooting your mouth off about something you, you know, don't know anything about.
So if education can't explain it, what is it? The hot climate? All that spicy food? What? Spell it out for us, Daytona955i. We're all ears.
I work with many people born and educated in India (and Asia, and Europe, and the former Soviet Union) and some of them are absolute cream-of-the-crop, as-good-as-you-could-ever-hope-to-be, top 10th of the top percentile good. Smart people are rare everywhere, but it's a huge world, and I don't ever kid myself that there isn't some hungry kid in Uzbekistan who could do my job better than me for half the money.
Ehh. In my opinion, people overestimate how big a deal x86 architecture complexity is, in part because it flatters their preconception that Intel is evil. ("If only dastardly Intel hadn't been holding the world back with this demon architecture from hell, think how fast CPUs could be now!") While working at VMware, I've gotten to know the x86 architecture on a first name basis. He now lets me call him "Archie."
While Archie is undoubtedly an ugly, drunk screw-up, he's really a droplet in the ocean of effort that goes into a competitive CPU implementation. Yeah, we've got lots of code to deal with him, and he's an ongoing source of work, but not all that much code, nor that much work. If Archie were really such a terrible guy, it wouldn't be possible for Intel and AMD to be eating so many RISC vendors' lunches.
Mike Johnson, the lead x86 designer at AMD, probably put it most succinctly when he said, "The x86 isn't all that complex -- it just doesn't make a lot of sense." It's peculiar all right, but not so peculiar that it can explain Transmeta's failure to be performance competitive. From speaking with Transmetans, I get the strong impression that they got bogged down because making a high performance dynamic translation system is ridiculously hard, rather than, say, because they just couldn't get the growdown segment descriptors right.
Dude? Pantani's a climber. Or he was one, before he got all depressed and started hitting the canollis hard.
Cippollini, Petacchi, McEwen, and Zabel are the current cream of the sprinting crop. And you're indeed right that Cipo puts out over 1 horsepower in full flight.
My perfectly average eight year old daughter uses Debian.... She prefers it to windows xp because "it has better games", "cooler menus", and "no blue screens!"
I don't know you, cshark, or your daughter. But I'm just going to go out on a limb here, and claim that this never happened. Specifically, your eight year old daughter never said to you, unprompted, that she liked Debian because "no blue screens!" Any eight year old who is significantly vexed by blue screens is a far cry from "perfectly average."
Someone was bitching "why can't XYZ OS run under VMWare if it runs perfectly well under generic PC hardware". Someone responded to the effect that VMWare was tuned to make certain concessions for the OSs they supported.
Right. The OS'es we "support." Not the OS'es "we're able to run." And those "concessions" are mostly performance trade-offs, not correctness.
It's still true that some OS'es don't run; but that's because our software has bugs. OS'es sometimes have bugs, too, though if the OS is important enough, we'll work around it. The bugs that prevent you from running the OS that some drunken Swede cooked up for course credit are admittedly less important to fix than the bugs that, say, prevent you from running Linux. However, in the long run, we try to fix even the bugs exposed only by drunken Swedes.
That's why AtheOS, OpenStep, BeOS, NetBSD, FreeDOS, B-Right, Plan9, QNX, and myriad other commercially unimportant OS'es run ok. Not because they're important to our customers (man, oh man, they aren't), but because they enable us to be sure our x86 virtualization layer is reasonably correct. That way, when Ingo Molnar decides to start using 80286-style 16-bit tasks with lots of grow-down and conforming code segments to do system calls in Linux 2.6, we won't get caught out too badly.
They need to tweak VMWare for each OS. A true emulator, like bochs, doesn't need this tweaking.
How high are you? Do you really think VMware, Inc. pays me to "tweak" our monitor so ~12 slashdot-reading customers can try running plan9 in a VM? Plan9, OpenStep, AtheOS and the rest of the hobbyist OS'es just work, because VMware contains a basically correct x86 virtual machine monitor. Much like they just work on bochs, a basically correct x86 emulator. The VMM and the emulator accomplish the same computational task; they simply use different techniques to accomplish it.
If you have a copy of the Lions Book, flip to line 2527. Then look at lines 87 through 205 of /usr/src/linux/arch/ia64/sn/io/ate_utils.c .
atefree and atealloc are verbatim copies of UNIX 6th Edition's malloc and free. The only changes are mapping the ancient C compilerism "=+" to "+=", some comment changes, some ASSERTs, and a spinlock. The code is undeniably copied.
Do I _REALLY_ want to pull in libpng and libSDL just to do this?
Yes.
What kind of risks does pulling these libraries in add to my project?
The risk that you will hit a bug in the library. Which is much smaller than the risk that there will be a bug in your one-off k-spiff png display engine (hence, OOKSPDE).
How much will this bloat my code?
It will bloat your code by the additive inverse of the code size of your OOKSPDE. The user already has the library on their disk. If it is dynamically linked to your executable, they pay nothing to use it.
Will users be confused from the different versions of these libraries?
Would you rather they lose data because your broken OOKSPDE doesn't handle transparency properly?
Turns out it's usually simpler, easier, and less risky to just roll your own.
It sounds like you either have a delusionally high estimation of your own abilities relative to those of your library-writing peers ("Of course the code I write will be faster, more correct, and less bloaty than the specialised code that those people who really understand the problem and spend time solving it well!") or you place very little value on your time. Oh well. Have fun writing png-frobbing code for the rest of your life.
I've worked with CS grads before and I'd consider recommending them for writing documentation or being a liason between the real programmers and the customers, but the ones I've worked with suck at writing code.
Funny, that. I've met exactly one self-taught software person who could tell his ass from a hole in the ground. Most people beating their chests about how they don't need some galdurn longhair hippy telling them how to code have learned some subset of a couple of programming languages, and think they're masters of the universe. Since programming has always been easy for them, they assume that they are gifted programmers, never stopping to notice that they aren't attempting anything particularly difficult.
Difficult programming is like chess. Even the most extremely gifted can learn a lot by studying other practitioners, and even very experienced people can benefit from the perspective that theoretical knowlege can provide. The louder someone proclaims the pointlessness of an education, the more sure I become that they've never attempted anything truly difficult.
Also note that W^X is also available on x86 in -current.
How do they accomplish that, when that the x86 doesn't differentiate between execute and read permissions for paging? Is is some sort of crock involving limits on the code segment?