am not looking forward to the spat of much repeated, and edited, reruns of "Bill and Ted's (Bogus Journey | Excellent Adventure)" which will inevitably be shown on the major cable and satellite networks.
The older stand-up routines, however, are a different story altogether.
4.3 days plus or minus 0.01 day would give a 50% probability that it would squarely fit within the coincidental range of the "Deep Thought" answer, provided you're truncating at the first decimal, and not rounding.
Or just an optional "registration" to allow you to know of changes in the "service".
Way back when I set up my home sendmail server and used that rbl entry in my gateway's cf file, they could have pointed me to a way to "register" an admin email address that they could notify if the service would go away. To my discredit, maybe they actually had something like that there when they were alive, I never checked.
If they didn't have a registered users list then this becomes a typical event-driven vs polling problem. Two years ago when they shut this down, I wasn't looking for it, and there wasn't any way they could have contacted me to say "hey, we're outta here". The way it stood, unless I was explicitly looking for this (ie. polling for it) there would have been no way to prevent it.
Being on a registered users list, however, would have prevented it - as they could have then sent a notification that their list was obsolete and useless.
As it is, I found out about this yesterday when I noticed an unusual quiet in the megadik spam that I normally get. I also sent something to a known-running private majordomo listserv I belong to, but it never returned my post back to my inbox. A few minutes of poking around, and an email from my work account to my home account later, and I was "dnl"-ing the offending line in the m4 file and remaking the cf file, and bouncing the daemon. I probably lost about a day or so's worth of email that would have been delivered.
No doubt. But on the flip side those that believe in the scientific method over dogma also have a responsibility to facilitate the election of those who will encourage science over a particular flavor of dogma.
Science and dogma are necessarily at odds with each other, since both start out with different assumptions.
Dogma starts with an assertion that "we think this is the way it works, therefore it *must* be that way".
Science starts with the same edict: "we think this is the way it works", but instead of "it must be that way", it replaces it with "and you can feel free to provide an empirical counterexample of how it doesn't work that way, and we will add your information to the collective body of knowledge that explains reality".
Now, when you add the whole idea of "control" to the mix, that makes things interesting.
Science gives you knowledge, and an element of control over physical things. For example, I see that my barometer is decreasing, therefore I can carry an umbrella, and control that I don't get wet. Science can also give people control over other people, via drugs, weaponry, etc. Science can supply the 'what', but it doesn't supply the 'why', at least not directly.
Dogma, on the other hand gives the people who supply the edicts, or re-interpret ones that have been defined by others, the edict-writers, control over people's ideas, but no real control over the physical things. It's a fake kind of control - not based in reality. Dogma is easy, the edict-writers provide dogma that suits their purposes of control, and the edict-consumers get a warm fuzzy feeling in their tummies that they are in control of things and that they belong to something bigger than themselves. On the other hand, science is hard: you have to invent tools to get the data that explains reality - you have to think, you have to do real work.
For example, over a 1000 year period 2000-3000 years ago, a series of books are written, which for their time explained how to live for a society that did not have a rigorous scientific method. 2000 years later, the edict-writers find these books to have some good information on how to treat other human beings with respect, but lump it all in together with the other not-so-pertinent information contained there, and then interpret it in their own fashion, and place their own values on the information within, necessarily based on their notion of how they want the society to be, as well as a certain demogogery inherent in having a large pool of believers in their interpreted work.
They then say that the entire work is "infallible" since it was "inspired by God", so that if you buy the part that says "love your neighbor", you necessarily have to buy their interpretation of everything else there, including what to do when two people of the same sex want to marry, what to do with discarded embryos that can generate stem cells for already living *sentient* beings, etc.
The edict-writers probably partially believe their own interpretation, or at least they put on a good show for the edict-consumers. Mainly though, they use it to prop up their own power base, and in a rapidly degrading democracy, to garner support for their continued agenda. The dogma gets tweaked depending on the current needs of the edict-writers, and the edict-consumers follow lock-step in doing what they say for fear of divine retribution in the afterlife. Today's edict-writers might even be using the results of science to drive their interpretations (and hence their string-pulling of the edict-consumers), allowing themselves to gain an advantage.
It's seems to me that those two ways of looking at the world are irreconcilable. Science, when done properly, has no ulterior motives. Dogma, on the other hand, is full of them.
Are you saying that Java *doesn't* have strong typing? Sure, I can declare something as an "Object" and bypass typing that way, but I still have to *declare* that reference as being a vanilla Object. In Java all atomic fields and local variables need to be declared as char, int, byte, float, long, etc. You can assign from one to another where it makes sense, and the compiler will catch where it doesn't and flag those things before you get a chance to run the program.
If that's not a strongly typed language then I don't know what is.
That has to say something. 1. Java was strongly typed from the beginning. Perl added typing as an afterthought. Inheritance is implemented in a bizarre fashion by adding to an "@ISA" list and "blessing" things. With Java many of inheritance errors would be caught at compilation time. With perl, there's no compilation, so those kind of things fail at runtime.
2. One has to put a $ or a % or an @ in front of a variable to make sure it's used properly. That (in my opinion) immediately obfuscates code and decreases maintainability. Java: int i = 0; Perl: $i=0; What would you rather look at?
3. Every application I've seen that's been written in Perl looks like a hack. So, if what you need is a quick and dirty throwaway hack, then Perl or PHP may do. However, in many cases those quick and dirty hacks turn into little permanent monsters that someone needs to care and feed every so often.
4. EPIC, the Eclipse IDE plugin for perl, can't find references to variables. Many times it can't find declarations. With Java there's never a problem. How one can do without this kind of functionality is beyond me. I guess you just grep the codebase looking for things that match.
5. Perl trades second generation maintainability for first generation instant gratification.
6. Perl's idomatic quirkiness encourages bad programming practices and butt-ugly code. For example, most Perl code that I've seen uses the "something if (condition)" idiom. If *after* the thing it's suppose to do? C'mon. Or, the "something || die..." grotesqueness. Code written like that is just waiting for someone to come along later and hose it up.
From a perpetual beginner, and lazy-assed brewer we are Mostly Agreed. The Charlie Papazian book is *the* homebrewer's bible.
Here's my $0.02 of Things I've Learned Homebrewing. Doing this will make sure you get a nice drinkable brew, and not a container full of Septic System Helper:
Aside from the rack-over tubing and bottling wand, the beer should touch only stainless steel during the boiling process. I use a plastic funnel to assist in transferring the wort from the pot to the carboy, and haven't had any infection problems. I tried a heat-exchanger once to cool things down, but they are too hard to keep clean, let alone sanitized - better to not do it at all, or put the carboy into a bigger container full of ice water in order to cool the wort down.
Originally I used two plastic pails for fermentation but now I use sanitized glass carboys instead, and sanitized glass bottles for conditioning since plastic can harbor bacteria in the scratches. I stay away from kegging, since it makes transport difficult. For a beginner, saving up a couple of cases of Sam Adams 12 oz empties for a 5 gal batch is pretty cheap.
To sanitize, first I soak the sanitizee in strong bleach solution ( 1 cup per 5 gal or really hot water). After doing this, shooting a stream of water into the bottle or carboy will dislodge the nastiest of schmeg. Bleach is cheap - beer ingredients are not. As a final step, I dunk the bottle in a solution of Iodophor (2 oz per five gal of water), and rinse for a few seconds. For rinsing, a bottle rinser comes in handy.
Initially, I did the hydrometer thing, but I've discovered that as long as the batch gets past the kreusening stage, you're usually home free. I rack over once after the first week, and then I let the batch sit for two to three weeks after the fermentation lock stops bubbling after the first racking. I'd rather not risk introducing something which will foul up the beer when I do the hydrometer reading. I'll do the hydrometer test when I'm really interested in the COOH level, though. Usually for meads and such.
I stay away from hopped kits since the active bittering agents in hops do degrade over time, and it's hard to tell how and for how long the cans were stored.
I use powdered unhopped malt *extract*, light or dark depending on the type of beer. Mashing is a pain in the butt, and if left without a choice I'd do it. I think you can get just as good a result from using the malt extract, and it saves a step.
I get whole-leaf hops that were kept refrigerated, and in light-blocking bags. Light will degrade the active chemical components in hops. I think that, aside from sanitation, this is probably *the* most important thing to be concerned about. Old nasty hops will definitely funk up a beer.
I do ales, they are easy since you don't have to worry about refrigeration. Mead is a good thing to try for this reason also. There are a few other ingredients you need for that - like yeast nutrients, and gypsum to avoid stuck fermentation issues.
My original two plastic pails didn't go to waste, however. I use them to contain the sanitizing solution that I soak the bottles and equipment in. I also put a few bottles into an empty sanitized pail that is sitting on the floor, and fill them in it. That way if I inadvertently overfill the bottle, the overflow goes into the bucket and not onto the kitchen floor.
Or, kind of like when the South Park news channel reported that some 'Puerto Rican Guy' kidnapped poor Butters Stotch. But it was actually his mom who did it, instead.
In my experience, unless you are a developer who needs to build a large application on their desktop, or you are playing some game that requires computation of some sort that cannot be offloaded to a graphics processor, or you are trying to invert the universe (or a small part of it), a desktop with a > 2GHz processor is a waste of money.
I'm sure there is the rare exception, I've never seen an office desktop at 100% CPU utilization which is doing something legitimate. You'd be better off sinking your money into maxxing the memory out, and getting a good malware scrubber package to ensure your machine utilizes its resources properly.
For a server, it's a different story altogether. In many cases, work that runs on servers tends to be quite parallelizable already - for example each request that is accepted by a shopping cart application usually is serviced by a different thread or process (which can be scheduled by the OS to run on a processor that is not doing meaningful work). Scaling involves adding another box to the server farm, and load balancing it, or adding more CPUs to a DB server's backplane. These are scalable as usage increases, where each individual request is not a CPU hog.
I think that the CPU problem really pertains to the problem space where any one of those server threads is always requiring the CPU (versus doing I/O or waiting for another process, human intervention on a HID, etc) - the space of parallelizable CPU-bound and non-parallellizable CPU bound type work.
Things like weather forecasting (solving partial differential equations), with processes that can be broken up into discrete areas, and then recombined are parallellizable via reprogramming. Some are, but only to an extent. For example, computing something like the mandlebrot set is parallellizable over each coordinate. You can kick off a bunch of threads for each point, one for each processor. But, at each point, the iterative process that is occurring produces intermediate results such that the one before depends on the one afterwards. Those individual point computations are not parallellizable.
Of course, if you're running spyware or adware on your server farm, you have other problems to solve too.
That's right. Soon you won't be able to fart without someone trying to claim it as an IP infringement.
Oh, the humanity!
The internet detects censorship as damage and routes around it. In this case, any protocol (even ICMP) can be used to tunnel over. I suspect if passed, we'll be seeing a lot more of that kind of end running around.
So true. I've heard of valgrind, and it is a CPU hog. I recall folks in the C development side of the house where I used to work using it. It was running on a Linux server (not on a user workstation) though, and taking 100% of the CPU for an entire weekend. Over the cube wall could be heard, "don't do anything on devlinux, they're running valgrind there again".
Hopefully your organization is responsive enough to give you the resources you need to do your job in an acceptable amount of time. Fortunately, most of my performance woes have rarely to do with a mix of work that is CPU-bound on my workstation. In my experience, it tends to be lack of memory that constrains my productivity there. Particularly in an MS-Windows environment, once I kick it up to above my "90% of the time" resident working set size, everything "Just Starts Working" again.
What cracks me up are all these ads for kicking up processor speed to make your desktop machine "run faster". Most likely for a general non-gaming, non-development user who complains of slow performance, CPU cycles are not the problem. You're not utilizing the CPU if half of your processes are waiting for pages to swap in. As an example, I've got another older (circa 2000) 400MHz laptop with a gig of memory in it at home. It works just fine for what my wife and I use it for - checking mail, browsing, etc since it never goes above the point where it pages. When I was using it as such, it showed marginal performance as a development box. I was glad when I got a 1.5GB 2Ghz toshiba satellite to replace it for that purpose.
That kind of stuff is the norm when you go out of the IT department's comfortable little box. I've seen it happen time and again when software developers require tools on their machine which require windows local admin access to install, and the tool's installation, configuration, and reason for existence are beyond the workstation administrator's scope and skillset.
For example, one place I worked I had to jump through hoops to get them to change my domain account to allow me local administrator access so I could install a particular tool on my XP workstation, and set it up so that it would start as a service. It took a week to accomplish what could have been done in a couple of hours, because I had to wait for the access. Then, every so often, some new policy would get put in place (because of admin turnover, and the inevitable "oh, why does he have this?"), and I would have to go and ask for it again when I needed to upgrade, reinstall, or whatever.
I've had clueless desktop admins tell me that they won't increase memory in my laptop, because "I shouldn't be running with less than what a general non-developer user has installed. That way you'll be certain to write efficient code that will work in production". Nevermind that the Eclipse IDE, and other development tools that I use to write the code that will eventually run on the *server*, don't run on the server themselves, and that the server-side code I'm writing and unit testing on my workstation will never run on a desktop in production. Eventually, the memory *was* installed, but before that happened, my productivity was markedly decreased, because of the horrible performance hit that occurs once windows starts to page. It's frustrating when code completion takes 15 to 20 seconds to happen.
FWIW, a development workstation (windows or linux) with less than a gig of memory is essentially a brick when all things are cranking. Most of our stock XP workstations came with 512MB, far too small to accomplish most of a Java developer's programming tasks, as well as all of the other things (like source control, browser, Outlook, cygwin, a local tomcat, one or two DBs - like mySql and sql server, a db client like Aqua Data studio, a bunch of ssh sessions, etc).
So, I guess from a purely IT standpoint, I would add:
This brings back some old IBM 370-architecture mainframe era stories, like the half-room-sized, 6MB amdahl that had actual speedometer dials on the front. When you wanted to see how much CPU was being used, you went into the computer room, and opened the hatch on the front of the box. Then came omegamon.
Or some other piece of IBM equipment (a water-chiller perhaps) that had a little locker in it for the SE to hang up his coat. Then came the air cooled System/390 based machines.
A walk through the IS/IT department in an IBM shop circa 1982 would reveal each 3278 terminal having at least one or more cigarette burns on the keyboard, the main operator console located in the computer room, would have the most burns. Then came second hand smoke.
Where the operator would stop the system console from scrolling by hitting the "pause" key on the system console. Since it caused the CPU to stop, it would also hang any in-flight CICS transactions. Fortunately, hitting pause again would cause everything to pick up where it left off *no matter how long you left things paused*. Then came a CICS-based console, called FAQS and everyone was happy.
Or the time we had a picnic in the computer room, using the 16mb IBM 4341 processor as a table for all of the food and beer, some of the 6250 bpi "scratch" tapes became frisbees by the time the party was over. Then came the "taller" 3081, and a ban on parties in the computer room.
Now, get off my lawn!
Re:so much DRM, most data will be inaccessible
on
Security in Ten Years
·
· Score: 1
And we'll have 10 more years worth of bad music, and mediocre movies to attempt to copy illegally. I can hardly wait.
Slashdot Mirror
am not looking forward to the spat of much repeated, and edited, reruns of "Bill and Ted's (Bogus Journey | Excellent Adventure)" which will inevitably be shown on the major cable and satellite networks.
The older stand-up routines, however, are a different story altogether.
Depends on the accuracy and precision.
4.3 days plus or minus 0.01 day would give a 50% probability that it would squarely fit within the coincidental range of the "Deep Thought" answer, provided you're truncating at the first decimal, and not rounding.
Hah. And here I'm thinking that all they wanted to rotate were Rubic's Cubes. How naive of me.
How about this and this
"The drama involves a woman lobbyist who may have helped to write key telecom legislation."
uh-huh. Methinks there's lots of Verizon money creating a green mist around McCain's head.
this
this
Gelgamek overlords.
... "But does it run linux?"
Like this. Then all will be right with the universe again.
Or just an optional "registration" to allow you to know of changes in the "service".
Way back when I set up my home sendmail server and used that rbl entry in my gateway's cf file, they could have pointed me to a way to "register" an admin email address that they could notify if the service would go away. To my discredit, maybe they actually had something like that there when they were alive, I never checked.
If they didn't have a registered users list then this becomes a typical event-driven vs polling problem. Two years ago when they shut this down, I wasn't looking for it, and there wasn't any way they could have contacted me to say "hey, we're outta here". The way it stood, unless I was explicitly looking for this (ie. polling for it) there would have been no way to prevent it.
Being on a registered users list, however, would have prevented it - as they could have then sent a notification that their list was obsolete and useless.
As it is, I found out about this yesterday when I noticed an unusual quiet in the megadik spam that I normally get. I also sent something to a known-running private majordomo listserv I belong to, but it never returned my post back to my inbox. A few minutes of poking around, and an email from my work account to my home account later, and I was "dnl"-ing the offending line in the m4 file and remaking the cf file, and bouncing the daemon. I probably lost about a day or so's worth of email that would have been delivered.
No doubt. But on the flip side those that believe in the scientific method over dogma also have a responsibility to facilitate the election of those who will encourage science over a particular flavor of dogma.
Science and dogma are necessarily at odds with each other, since both start out with different assumptions.
Dogma starts with an assertion that "we think this is the way it works, therefore it *must* be that way".
Science starts with the same edict: "we think this is the way it works", but instead of "it must be that way", it replaces it with "and you can feel free to provide an empirical counterexample of how it doesn't work that way, and we will add your information to the collective body of knowledge that explains reality".
Now, when you add the whole idea of "control" to the mix, that makes things interesting.
Science gives you knowledge, and an element of control over physical things. For example, I see that my barometer is decreasing, therefore I can carry an umbrella, and control that I don't get wet. Science can also give people control over other people, via drugs, weaponry, etc. Science can supply the 'what', but it doesn't supply the 'why', at least not directly.
Dogma, on the other hand gives the people who supply the edicts, or re-interpret ones that have been defined by others, the edict-writers, control over people's ideas, but no real control over the physical things. It's a fake kind of control - not based in reality. Dogma is easy, the edict-writers provide dogma that suits their purposes of control, and the edict-consumers get a warm fuzzy feeling in their tummies that they are in control of things and that they belong to something bigger than themselves. On the other hand, science is hard: you have to invent tools to get the data that explains reality - you have to think, you have to do real work.
For example, over a 1000 year period 2000-3000 years ago, a series of books are written, which for their time explained how to live for a society that did not have a rigorous scientific method. 2000 years later, the edict-writers find these books to have some good information on how to treat other human beings with respect, but lump it all in together with the other not-so-pertinent information contained there, and then interpret it in their own fashion, and place their own values on the information within, necessarily based on their notion of how they want the society to be, as well as a certain demogogery inherent in having a large pool of believers in their interpreted work.
They then say that the entire work is "infallible" since it was "inspired by God", so that if you buy the part that says "love your neighbor", you necessarily have to buy their interpretation of everything else there, including what to do when two people of the same sex want to marry, what to do with discarded embryos that can generate stem cells for already living *sentient* beings, etc.
The edict-writers probably partially believe their own interpretation, or at least they put on a good show for the edict-consumers. Mainly though, they use it to prop up their own power base, and in a rapidly degrading democracy, to garner support for their continued agenda. The dogma gets tweaked depending on the current needs of the edict-writers, and the edict-consumers follow lock-step in doing what they say for fear of divine retribution in the afterlife. Today's edict-writers might even be using the results of science to drive their interpretations (and hence their string-pulling of the edict-consumers), allowing themselves to gain an advantage.
It's seems to me that those two ways of looking at the world are irreconcilable. Science, when done properly, has no ulterior motives. Dogma, on the other hand, is full of them.
I'm not sure what you are getting at.
Are you saying that Java *doesn't* have strong typing? Sure, I can declare something as an "Object" and bypass typing that way, but I still have to *declare* that reference as being a vanilla Object. In Java all atomic fields and local variables need to be declared as char, int, byte, float, long, etc. You can assign from one to another where it makes sense, and the compiler will catch where it doesn't and flag those things before you get a chance to run the program.
If that's not a strongly typed language then I don't know what is.
... than well-commented Perl.
..." grotesqueness. Code written like that is just waiting for someone to come along later and hose it up.
That has to say something.
1. Java was strongly typed from the beginning. Perl added typing as an afterthought. Inheritance is implemented in a bizarre fashion by adding to an "@ISA" list and "blessing" things.
With Java many of inheritance errors would be caught at compilation time. With perl, there's no compilation, so those kind of things fail at runtime.
2. One has to put a $ or a % or an @ in front of a variable to make sure it's used properly. That (in my opinion) immediately obfuscates code and decreases maintainability.
Java: int i = 0;
Perl: $i=0;
What would you rather look at?
3. Every application I've seen that's been written in Perl looks like a hack. So, if what you need is a quick and dirty throwaway hack, then Perl or PHP may do. However, in many cases those quick and dirty hacks turn into little permanent monsters that someone needs to care and feed every so often.
4. EPIC, the Eclipse IDE plugin for perl, can't find references to variables. Many times it can't find declarations. With Java there's never a problem. How one can do without this kind of functionality is beyond me. I guess you just grep the codebase looking for things that match.
5. Perl trades second generation maintainability for first generation instant gratification.
6. Perl's idomatic quirkiness encourages bad programming practices and butt-ugly code. For example, most Perl code that I've seen uses the "something if (condition)" idiom. If *after* the thing it's suppose to do? C'mon. Or, the "something || die
From a perpetual beginner, and lazy-assed brewer we are Mostly Agreed. The Charlie Papazian book is *the* homebrewer's bible.
Here's my $0.02 of Things I've Learned Homebrewing. Doing this will make sure you get a nice drinkable brew, and not a container full of Septic System Helper:
Aside from the rack-over tubing and bottling wand, the beer should touch only stainless steel during the boiling process. I use a plastic funnel to assist in transferring the wort from the pot to the carboy, and haven't had any infection problems. I tried a heat-exchanger once to cool things down, but they are too hard to keep clean, let alone sanitized - better to not do it at all, or put the carboy into a bigger container full of ice water in order to cool the wort down.
Originally I used two plastic pails for fermentation but now I use sanitized glass carboys instead, and sanitized glass bottles for conditioning since plastic can harbor bacteria in the scratches. I stay away from kegging, since it makes transport difficult. For a beginner, saving up a couple of cases of Sam Adams 12 oz empties for a 5 gal batch is pretty cheap.
To sanitize, first I soak the sanitizee in strong bleach solution ( 1 cup per 5 gal or really hot water). After doing this, shooting a stream of water into the bottle or carboy will dislodge the nastiest of schmeg. Bleach is cheap - beer ingredients are not. As a final step, I dunk the bottle in a solution of Iodophor (2 oz per five gal of water), and rinse for a few seconds. For rinsing, a bottle rinser comes in handy.
Initially, I did the hydrometer thing, but I've discovered that as long as the batch gets past the kreusening stage, you're usually home free. I rack over once after the first week, and then I let the batch sit for two to three weeks after the fermentation lock stops bubbling after the first racking. I'd rather not risk introducing something which will foul up the beer when I do the hydrometer reading. I'll do the hydrometer test when I'm really interested in the COOH level, though. Usually for meads and such.
I stay away from hopped kits since the active bittering agents in hops do degrade over time, and it's hard to tell how and for how long the cans were stored.
I use powdered unhopped malt *extract*, light or dark depending on the type of beer. Mashing is a pain in the butt, and if left without a choice I'd do it. I think you can get just as good a result from using the malt extract, and it saves a step.
I get whole-leaf hops that were kept refrigerated, and in light-blocking bags. Light will degrade the active chemical components in hops. I think that, aside from sanitation, this is probably *the* most important thing to be concerned about. Old nasty hops will definitely funk up a beer.
I do ales, they are easy since you don't have to worry about refrigeration. Mead is a good thing to try for this reason also. There are a few other ingredients you need for that - like yeast nutrients, and gypsum to avoid stuck fermentation issues.
My original two plastic pails didn't go to waste, however. I use them to contain the sanitizing solution that I soak the bottles and equipment in. I also put a few bottles into an empty sanitized pail that is sitting on the floor, and fill them in it. That way if I inadvertently overfill the bottle, the overflow goes into the bucket and not onto the kitchen floor.
Or, kind of like when the South Park news channel reported that some 'Puerto Rican Guy' kidnapped poor Butters Stotch. But it was actually his mom who did it, instead.
Yeah, just like that.
I haven't ever gotten p0wn3d by previewing something in pine. In fact, I've never "previewed" anything in pine, since I couldn't figure out how. ;-)
Can't say the same for Outlook.
... on your desktop?
In my experience, unless you are a developer who needs to build a large application on their desktop, or you are playing some game that requires computation of some sort that cannot be offloaded to a graphics processor, or you are trying to invert the universe (or a small part of it), a desktop with a > 2GHz processor is a waste of money.
I'm sure there is the rare exception, I've never seen an office desktop at 100% CPU utilization which is doing something legitimate. You'd be better off sinking your money into maxxing the memory out, and getting a good malware scrubber package to ensure your machine utilizes its resources properly.
For a server, it's a different story altogether. In many cases, work that runs on servers tends to be quite parallelizable already - for example each request that is accepted by a shopping cart application usually is serviced by a different thread or process (which can be scheduled by the OS to run on a processor that is not doing meaningful work). Scaling involves adding another box to the server farm, and load balancing it, or adding more CPUs to a DB server's backplane. These are scalable as usage increases, where each individual request is not a CPU hog.
I think that the CPU problem really pertains to the problem space where any one of those server threads is always requiring the CPU (versus doing I/O or waiting for another process, human intervention on a HID, etc) - the space of parallelizable CPU-bound and non-parallellizable CPU bound type work.
Things like weather forecasting (solving partial differential equations), with processes that can be broken up into discrete areas, and then recombined are parallellizable via reprogramming. Some are, but only to an extent. For example, computing something like the mandlebrot set is parallellizable over each coordinate. You can kick off a bunch of threads for each point, one for each processor. But, at each point, the iterative process that is occurring produces intermediate results such that the one before depends on the one afterwards. Those individual point computations are not parallellizable.
Of course, if you're running spyware or adware on your server farm, you have other problems to solve too.
That's right. Soon you won't be able to fart without someone trying to claim it as an IP infringement.
Oh, the humanity!
The internet detects censorship as damage and routes around it. In this case, any protocol (even ICMP) can be used to tunnel over. I suspect if passed, we'll be seeing a lot more of that kind of end running around.
I wonder how it works in NJ, home of the "jug handle"?
I always think that too... for a few seconds.
Then I realize it still doesn't run Linux, and get depressed.
Fluorescent CATS: All your fluorescent litter box are belong to us!
So true. I've heard of valgrind, and it is a CPU hog. I recall folks in the C development side of the house where I used to work using it. It was running on a Linux server (not on a user workstation) though, and taking 100% of the CPU for an entire weekend. Over the cube wall could be heard, "don't do anything on devlinux, they're running valgrind there again".
Hopefully your organization is responsive enough to give you the resources you need to do your job in an acceptable amount of time. Fortunately, most of my performance woes have rarely to do with a mix of work that is CPU-bound on my workstation. In my experience, it tends to be lack of memory that constrains my productivity there. Particularly in an MS-Windows environment, once I kick it up to above my "90% of the time" resident working set size, everything "Just Starts Working" again.
What cracks me up are all these ads for kicking up processor speed to make your desktop machine "run faster". Most likely for a general non-gaming, non-development user who complains of slow performance, CPU cycles are not the problem. You're not utilizing the CPU if half of your processes are waiting for pages to swap in. As an example, I've got another older (circa 2000) 400MHz laptop with a gig of memory in it at home. It works just fine for what my wife and I use it for - checking mail, browsing, etc since it never goes above the point where it pages. When I was using it as such, it showed marginal performance as a development box. I was glad when I got a 1.5GB 2Ghz toshiba satellite to replace it for that purpose.
That kind of stuff is the norm when you go out of the IT department's comfortable little box. I've seen it happen time and again when software developers require tools on their machine which require windows local admin access to install, and the tool's installation, configuration, and reason for existence are beyond the workstation administrator's scope and skillset.
For example, one place I worked I had to jump through hoops to get them to change my domain account to allow me local administrator access so I could install a particular tool on my XP workstation, and set it up so that it would start as a service. It took a week to accomplish what could have been done in a couple of hours, because I had to wait for the access. Then, every so often, some new policy would get put in place (because of admin turnover, and the inevitable "oh, why does he have this?"), and I would have to go and ask for it again when I needed to upgrade, reinstall, or whatever.
I've had clueless desktop admins tell me that they won't increase memory in my laptop, because "I shouldn't be running with less than what a general non-developer user has installed. That way you'll be certain to write efficient code that will work in production". Nevermind that the Eclipse IDE, and other development tools that I use to write the code that will eventually run on the *server*, don't run on the server themselves, and that the server-side code I'm writing and unit testing on my workstation will never run on a desktop in production. Eventually, the memory *was* installed, but before that happened, my productivity was markedly decreased, because of the horrible performance hit that occurs once windows starts to page. It's frustrating when code completion takes 15 to 20 seconds to happen.
FWIW, a development workstation (windows or linux) with less than a gig of memory is essentially a brick when all things are cranking. Most of our stock XP workstations came with 512MB, far too small to accomplish most of a Java developer's programming tasks, as well as all of the other things (like source control, browser, Outlook, cygwin, a local tomcat, one or two DBs - like mySql and sql server, a db client like Aqua Data studio, a bunch of ssh sessions, etc).
So, I guess from a purely IT standpoint, I would add:
Software Development User
to the list of "users from hell".
This brings back some old IBM 370-architecture mainframe era stories, like the half-room-sized, 6MB amdahl that had actual speedometer dials on the front. When you wanted to see how much CPU was being used, you went into the computer room, and opened the hatch on the front of the box. Then came omegamon.
Or some other piece of IBM equipment (a water-chiller perhaps) that had a little locker in it for the SE to hang up his coat. Then came the air cooled System/390 based machines.
A walk through the IS/IT department in an IBM shop circa 1982 would reveal each 3278 terminal having at least one or more cigarette burns on the keyboard, the main operator console located in the computer room, would have the most burns. Then came second hand smoke.
Where the operator would stop the system console from scrolling by hitting the "pause" key on the system console. Since it caused the CPU to stop, it would also hang any in-flight CICS transactions. Fortunately, hitting pause again would cause everything to pick up where it left off *no matter how long you left things paused*. Then came a CICS-based console, called FAQS and everyone was happy.
Or the time we had a picnic in the computer room, using the 16mb IBM 4341 processor as a table for all of the food and beer, some of the 6250 bpi "scratch" tapes became frisbees by the time the party was over. Then came the "taller" 3081, and a ban on parties in the computer room.
Now, get off my lawn!
And we'll have 10 more years worth of bad music, and mediocre movies to attempt to copy illegally. I can hardly wait.
How old will Britney Spears be by then?