I remember when the Facebook was cool. Back in 2002 or so, while I was still in college. Now ALL my immediate supervisors/bosses are on it. Fuck that shit.
OS X could, with hardly any effort at all on Apple's part. FileVault implements an encrypted disk system. If you swap the encryption algorithm out, you have a compressed disk system. This could potentially be done in a week by a single coder. But why bother? Most large data files are already compressed, so (statistically speaking) re-compression wouldn't be a gain in space, at a loss of speed. Seems like a bad trade-off to me.
Virtually every shared system in the history of the known universe has been over-subscribed. They sell more of it than they have, safe in the knowledge that everybody doesn't use all they can at once. This happens with water, electricity, gas, phone lines, bandwidth - everything.
What you're describing isn't "over-subscription", but capacity planning. A utility isn't "over-subscribed" until actual demand for its service (which can be defined a number of ways) exceeds its maximum capacity. ISPs have done a much worse job of this than the other utilities, and have been advertising "unlimited internet". That lead to over-subscription.
None of the other utilities you mentioned promise unlimited access anyway. You pay for what you use.
Wrong. No matter what object I'm working with, I can find its length with the.length property if such property is meaningfull. "len()" on the other hand, only works for certain types of objects.
(I don't do Python, but I know my type theory) What exactly do you think a type is in a language like Ruby or Python?
A "duck type" for an object is the type defined by the methods (and their signatures) it responds to. So tell me, if "length" isn't meaningful for an object, why would "len()" be?
What I'm trying to get at is that you described length and len using different words, but said the same thing about them both. Indeed, while len() only works for certain kinds of objects, length only works on objects for which it is "meaningful".
Still, I do prefer consistent notation, and the . or -> syntax is appropriate for object orientation.
Having a high-quality cable made sense in the days of Analog audio, because a poor-quality cable could distort the sound
A broken cable could. Lamp cord is good enough for speakers. If you want to spend money on an audio stack, spend it on things that will make a difference: the room, speakers, turntable/stylus, amplifier, more-or-less in that order.
How else could you rationalize paying only $60/month for faster-than-T1 level service?
Poor upstream bandwidth, no guaranteed latency across the line, and no service level agreement. In any case, a digital subscription line isn't shared with your neighbors. The DSLAM is the bottleneck, and it can be alleviated the same way T-1 connected networks alleviate theirs: faster routers and more bandwidth into them on the WAN side.
Also, DSL service isn't faster than T-1 service if you're not getting at least T-1 speed out of it. Right now, I am getting 50 kBps out of my DSL connection. A dedicated T-1 would give me four times that much.
If my (hypothetical) bonded T-1 went down in the middle of the night before Black Friday, somebody would get an angry phone call, and it would be fixed in a few hours or else they would be sued for breaking their SLA. If my DSL line went down in the middle of the night, I wouldn't have anybody to turn to for help.
Lightbulb: patentable - the combination of electricity and filament producing light was not an obvious result at the time of invention.
As someone else said, this was an extremely obvious idea. Humphrey Davy invented the carbon filament incandescant lamp by 1809. It was impractical because carbon oxidizes in the presence of heat and oxygen. It took advances in vacuum pump technology before more engineering in the field could be done, and by the time that happened, dozens were working on the light bulb.
Refrigerator: As a whole, not patentable (the principles of refrigeration were already known at the time). Various components to make the refrigeration system work - patentable.
Except, there is only one component assembly necessary to make a refrigeration unit: the compressor and decompression chamber. The first refrigeration units (industrial ammonia-based units) were patented. Many later refrigerator designs were patented.
That's the problem; this isn't an invention at all. It's an agglomeration (or conglomeration, or perhaps both) of existing technologies to obtain the expected result of combining those technologies.
So was the car. And the lightbulb. And the refrigerator. And the washing machine. And so on and so forth. What's your point?
Sounds like you didn't read "Connections" as a kid.
I wrote this in response to another, and decided against posting it (since the GP specifically asked about gaming, but I missed that), but then decided to use it in response to your post. It expands on your points.
Addressing the GP's question: It depends on your application/use-case. A database server can do fine with a relatively slow multi-core CPU, as long as it has fast enough IO and a LOT of RAM. A scientific computing/numerical analysis machine will likely need the fastest FPUs it can find -- hence the popularity of the PowerPC architecture in that field. Depending on the domain of scientific computing (discrete data mining or other discrete mathematics problems), something like a Sun UltraSPARC T2 could potentially do very well. These sorts of machines often have a LOT of RAM too, since hitting swap can turn a 10 hour long run into a year long run. Gamers need fast FPUs, usually provided by the graphics card.
The average user will probably benefit most from a quick IO subsystem combined with 4GB of RAM. Fast IO will allow your applications to be loaded quickly, and lots of RAM will help keep your applications and data cached, so you won't have to hit the disk for them again. (Which means the second time you start an application will be several orders of magnitude faster) Fast processors are nice, but only if you actually do processing. There's no point in keeping a 4.0 GHz Core Quad Extreme idle, or waiting on disk or user input, except for bragging rights.
I wouldn't worry about things like the L2 cache much as long as you get a modern processor or are doing serious number crunching. A cache is only useful if it gets "hit" -- if the value the processor is looking for is already stored in cache. A cache miss means going to RAM or disk (or reprocessing) for the value. A MB is enough to store the most used parts of your OS's kernel. Scientific computing applications are often designed to fit in the L1 or L2 cache -- if the main loop is going to run a hundred trillion times, it's better to keep its instructions in the cache so you don't have to go to RAM for them, wasting 2-4 cycles each time. Also, if the main loop is bigger than a cache, you will ALWAYS have to go to the next layer of memory, either from L1 to L2, or from L2 to L3 or RAM.
Other processor subsystems are similar -- you would already know what you needed if you "really" needed it.
If you want to compute faster, figure out which component/subsystem is slowing you down. And look for specific recommendations about that component/subsystem. The rest of your system will fall into place around it, at least as fast as your current one, since everything has gotten incrementally faster. The adage regarding premature optimization is true of both software and hardware.
Some of the extra costs Adventure games would've had that FPSes almost certainly wouldn't would've been employing 1 or several PROFESSIONAL WRITERS. Those guys usually don't work cheaply lol...
Slashdot Mirror
I remember when the Facebook was cool. Back in 2002 or so, while I was still in college. Now ALL my immediate supervisors/bosses are on it. Fuck that shit.
Apple dropped the Finder?
I often leave notes for desk-Nazi's like you: "e@t_a_d1ck" or "Stop looking under my keyboard, asshole"
Password-space is a set, not a symbol.
OS X could, with hardly any effort at all on Apple's part. FileVault implements an encrypted disk system. If you swap the encryption algorithm out, you have a compressed disk system. This could potentially be done in a week by a single coder. But why bother? Most large data files are already compressed, so (statistically speaking) re-compression wouldn't be a gain in space, at a loss of speed. Seems like a bad trade-off to me.
...we might need to wait and see a little bit(no pun intended) ...
FUCK YOU
Virtually every shared system in the history of the known universe has been over-subscribed. They sell more of it than they have, safe in the knowledge that everybody doesn't use all they can at once. This happens with water, electricity, gas, phone lines, bandwidth - everything.
What you're describing isn't "over-subscription", but capacity planning. A utility isn't "over-subscribed" until actual demand for its service (which can be defined a number of ways) exceeds its maximum capacity. ISPs have done a much worse job of this than the other utilities, and have been advertising "unlimited internet". That lead to over-subscription.
None of the other utilities you mentioned promise unlimited access anyway. You pay for what you use.
Wrong. No matter what object I'm working with, I can find its length with the .length property if such property is meaningfull. "len()" on the other hand, only works for certain types of objects.
(I don't do Python, but I know my type theory) What exactly do you think a type is in a language like Ruby or Python?
A "duck type" for an object is the type defined by the methods (and their signatures) it responds to. So tell me, if "length" isn't meaningful for an object, why would "len()" be?
What I'm trying to get at is that you described length and len using different words, but said the same thing about them both. Indeed, while len() only works for certain kinds of objects, length only works on objects for which it is "meaningful".
Still, I do prefer consistent notation, and the . or -> syntax is appropriate for object orientation.
Anyway, shouldn't an industrial-strength RDBMS be able to interpret and optimize the simplest possible range join written as such?
HAHA!
Rule 36 doesn't imply that fuckedupness is unbounded above.
Oh really? I call Rule 34 on Rush Limbaugh, Whoopi Goldberg, a midget, and Steve Buschemi,
and you can jam your fucking morals. that's god speak. you probably want id taught in biology classes too. mercy is for weak little bible beaters.
No, it's not "god speak". It's character, a trait you clearly lack (along with the ability to reason, humor, empathy).
Bravado is not a substitute for strength.
Shit cocks!
What was I posting about? I forgot.
Oh, that's right.
HUMAN FECES ON A STICK.
Having a high-quality cable made sense in the days of Analog audio, because a poor-quality cable could distort the sound
A broken cable could. Lamp cord is good enough for speakers. If you want to spend money on an audio stack, spend it on things that will make a difference: the room, speakers, turntable/stylus, amplifier, more-or-less in that order.
It depends on what the "+" operator does.
And that depends on context. I'll defer to a meteorologist as to whether the sum of small clouds is a small cloud. I suspect it might just be.
1 + 1 = 2 will be true in any universe, under any god(s), in any circumstances.
Not true. It is often 0.
How else could you rationalize paying only $60/month for faster-than-T1 level service?
Poor upstream bandwidth, no guaranteed latency across the line, and no service level agreement. In any case, a digital subscription line isn't shared with your neighbors. The DSLAM is the bottleneck, and it can be alleviated the same way T-1 connected networks alleviate theirs: faster routers and more bandwidth into them on the WAN side.
Also, DSL service isn't faster than T-1 service if you're not getting at least T-1 speed out of it. Right now, I am getting 50 kBps out of my DSL connection. A dedicated T-1 would give me four times that much.
If my (hypothetical) bonded T-1 went down in the middle of the night before Black Friday, somebody would get an angry phone call, and it would be fixed in a few hours or else they would be sued for breaking their SLA. If my DSL line went down in the middle of the night, I wouldn't have anybody to turn to for help.
Lightbulb: patentable - the combination of electricity and filament producing light was not an obvious result at the time of invention.
As someone else said, this was an extremely obvious idea. Humphrey Davy invented the carbon filament incandescant lamp by 1809. It was impractical because carbon oxidizes in the presence of heat and oxygen. It took advances in vacuum pump technology before more engineering in the field could be done, and by the time that happened, dozens were working on the light bulb.
Refrigerator: As a whole, not patentable (the principles of refrigeration were already known at the time). Various components to make the refrigeration system work - patentable.
Except, there is only one component assembly necessary to make a refrigeration unit: the compressor and decompression chamber. The first refrigeration units (industrial ammonia-based units) were patented. Many later refrigerator designs were patented.
That's the problem; this isn't an invention at all. It's an agglomeration (or conglomeration, or perhaps both) of existing technologies to obtain the expected result of combining those technologies.
So was the car. And the lightbulb. And the refrigerator. And the washing machine. And so on and so forth. What's your point?
Sounds like you didn't read "Connections" as a kid.
Me too!
I wrote this in response to another, and decided against posting it (since the GP specifically asked about gaming, but I missed that), but then decided to use it in response to your post. It expands on your points.
Addressing the GP's question: It depends on your application/use-case. A database server can do fine with a relatively slow multi-core CPU, as long as it has fast enough IO and a LOT of RAM. A scientific computing/numerical analysis machine will likely need the fastest FPUs it can find -- hence the popularity of the PowerPC architecture in that field. Depending on the domain of scientific computing (discrete data mining or other discrete mathematics problems), something like a Sun UltraSPARC T2 could potentially do very well. These sorts of machines often have a LOT of RAM too, since hitting swap can turn a 10 hour long run into a year long run. Gamers need fast FPUs, usually provided by the graphics card.
The average user will probably benefit most from a quick IO subsystem combined with 4GB of RAM. Fast IO will allow your applications to be loaded quickly, and lots of RAM will help keep your applications and data cached, so you won't have to hit the disk for them again. (Which means the second time you start an application will be several orders of magnitude faster) Fast processors are nice, but only if you actually do processing. There's no point in keeping a 4.0 GHz Core Quad Extreme idle, or waiting on disk or user input, except for bragging rights.
I wouldn't worry about things like the L2 cache much as long as you get a modern processor or are doing serious number crunching. A cache is only useful if it gets "hit" -- if the value the processor is looking for is already stored in cache. A cache miss means going to RAM or disk (or reprocessing) for the value. A MB is enough to store the most used parts of your OS's kernel. Scientific computing applications are often designed to fit in the L1 or L2 cache -- if the main loop is going to run a hundred trillion times, it's better to keep its instructions in the cache so you don't have to go to RAM for them, wasting 2-4 cycles each time. Also, if the main loop is bigger than a cache, you will ALWAYS have to go to the next layer of memory, either from L1 to L2, or from L2 to L3 or RAM.
Other processor subsystems are similar -- you would already know what you needed if you "really" needed it.
If you want to compute faster, figure out which component/subsystem is slowing you down. And look for specific recommendations about that component/subsystem. The rest of your system will fall into place around it, at least as fast as your current one, since everything has gotten incrementally faster. The adage regarding premature optimization is true of both software and hardware.
Some of the extra costs Adventure games would've had that FPSes almost certainly wouldn't would've been employing 1 or several PROFESSIONAL WRITERS. Those guys usually don't work cheaply lol...
You don't know many professional writers, do you?
tikz wins.
If a chair would post on slashdot, it wouldn't be a chair, but a computer in the shape of a chair, or a human disguised as a chair.
And what if the computer in the shape of a chair was for sitting on? That would make it a bona-fide chair, with an embedded CPU.
Get him a book on Haskell and tell him to get his ass in gear.
Which is one of the more tractable aspects of the homeomorphism problem -- the classification of knots in three-space.