True or false: there are countries in the world that would be more interested in curing citizens than propping up costly, government-owned pharmaceutical labs.
True or false: if the above is true, at least one of those countries is capable of developing medicines on their own without relying on US and European labs.
Your conspiracy-driven position requires the belief that there are no pharm researchers in the entire world motivated by the desire to actually cure disease. You sincerely believe that "Red China" would rather pay US companies for monthly prescriptions to treat common conditions than to develop a cure for them once and for all? Your assumption that all American labs are thoroughly corrupt and that every other lab in every other country in the whole world is corrupt in exactly the same way is amazingly arrogant, astoundingly misguided, and just doesn't jibe with reality.
How would either the FDA or HIPAA be involved with individual customers posting comments about their experiences? The FDA doesn't regulate conversation between patients, and HIPAA only governs what information (and how) a medical provider can share about a patient.
Intel heat sinks have always been sufficient to run the CPU at stock speeds. What more do you want from a stock cooler?
No, they haven't. I bought an E8400 from Newegg and installed it in a very well-ventilated case and set it to run at the precise spec voltages and frequency. With the stock heat sink and fan, the CPU would regularly hit 70C, nearly it's maximum rated temperature. I bought a replacement sink and fan (looked a little overclocker-ish but I didn't want to go halfway) and now it never gets over 48C under heavy load.
Most of Intel's sinks are sufficient, but all of them most certainly are not.
Those numbers are very accurate, except that I rounded my times up slightly and his down to the nearest hour. He wasn't concerned about megabyte-seconds. He was concerned about the horrific idea of a single process using half a gigabyte of RAM for any length of time whatsoever. I'm sure that if you asked him, I was the young punk with no consideration for resource usage.
And again, I understand to a point. I wouldn't want to run a horribly inefficient process that used multiple gigs of RAM simply because it was poorly written. But if I can throw some RAM at a problem to dramatically lighten other resource usage, I'll do it in a heartbeat.
The indices are there not only for data modeling purposes, but also to minimize the amount of uber expensive disk I/O necessary to perform most queries.
For historical reasons, one of our largest tables stores a person's name as "Last, First" instead of using separate fields. I wrote a PostgreSQL functional index like UPPER(SUBSTR(name,1,STRPOS(name,','))). According to "explain analyze", that reduced searching for the last name "Smith" from 1628ms to 79ms.
I know the importance of indexes isn't your main point, but I felt the need to brag.
Or, if we must motivate the hippies, call it "green optimisation". Yes, faster code finishes quicker, using less power to complete the same job.
If I write an inefficient process that causes the CPU to dissipate an extra 10W 24/7, the additional local cost for that electricity would run about $0.60 per month. That works out to approximately 50 seconds salary. While Google-scale operations would probably consider that a worthwhile expenditure, for most small companies it'd be much cheaper (and a lot greener!) to not spend the programmer time to improve it.
Also consider that my desktop, extra monitor, office lights, and office air conditioning add up to a lot more than 10W. I like to eat sometimes, too, and I have to get back and forth to work somehow. It might not be green at all to invest more energy into the optimization process than we'd ever recoup.
If spending an extra day optimizing my code could save me $2000 / mo off my colo bill, I'd be a fool not to invest that time.
Maybe, unless the opportunity cost of deploying your application runs to more than $2,000/day. And will it cost more to maintain your optimized code than the (presumably) more straightforward equivalent?
Some old-school developers prematurely optimize for things we no longer need to optimize for (and shouldn't). From an older post of mine:
A recent experience with an ex-coworker illustrated this pretty well for me:
Said fellow, call him "Joe", had about 30 years of COBOL experience. We're a Python shop but hired him based on his general coding abilities. The problem was that he wrote COBOL in every language he used, and the results were disastrous. He was used to optimizing for tiny RAM machines or tight resource allocations and did things like querying the database with a rather complex join for each record out of quite a few million. I stepped in to look at his code because it took about 4 hours to run and was slamming the database most of the time. I re-wrote part of it with a bit of caching and got the run-time down to 8 seconds. (Choose to believe me or not, but I'd testify to those numbers in court.) I gave it back to him, he made some modifications, and tried it again - 3 hours this time. I asked him what on Earth he'd done to re-break the program, and he'd pretty much stripped out my caching. Why? Because it used almost half a gig of RAM! on his desktop and he thought that was abhorrent.
Never mind that it was going to be run on a server with 8GB of RAM, and that I'd much rather use.5GB for 8 seconds than 1MB for 3 hours of intense activity.
So Joe isn't every COBOL programmer, but you and I both know that he's a lot of them. But back to the direct point, how much of that 250GLOC was written with the assumption that it'd be running on 512KB machines or with glacial hard drives or where making the executable as tiny as possible was an extreme priority? Doing things like storing cache data in hash tables would've been obscenely expensive back in the day, so those old algorithms were designed to be hyper-efficient and dog slow. Whether you think that constitutes "working well" is up to you.
He was optimizing for resources that were no longer constrained, and consequently pessimizing for the resources we actually cared about. RAM? Dirt cheap, at least for the dataset sizes involved in that project. Much more expensive was all the extra disk and CPU load he was creating on the company-wide database server (which is sufficiently powerful to serve the entire company when it's not being deliberately assaulted).
I'm not "anything goes" by any means, and I'm the guy responsible for making sure that lots of processes can peacefully coexist on an efficiently small number of servers. But for all intents and purposes, most of our apps have unlimited resources available to them. If they want to use 100% of a CPU core for 5 minutes or 2GB of RAM for half an hour a day, so be it. I'd much rather run simple, testable, maintainable code that happens to use a lot of server power than lovingly hand-mangled code that no one but the original programmer can understand and which interacts with the rest of the network in entertainingly unpredictable ways.
I have no idea what BRD means, but yeah, that's the gist of it. I hope we can also agree that would-be casual editors outnumber entrenched, abusive editors by a couple of orders of magnitude.
Next time this happens, take the revert to the article's talk page.
What you cannot seem to be made to understand is that no one outside Wikipedia can be bothered to give a shit about "the proper process". We don't care. It's one thing to see an article we can copy-edit or add a little bit to. Hey, I can spend two minutes adding to the collection of human knowledge? I'm in! But it's entirely different to expect us to want to spend time babysitting our edits so that the griefer jackasses who stake ownership to large swaths of a hard drive don't delete our work on a whim.
You keep saying "well, all you have to do is..." but that's never going to happen. We're not "into" Wikipedia in the same way that the Aspie teen hitting "reload" 100 times an hour is, and aren't willing to donate large chunks of time to it.
The problems (and any possible solutions) lie wholly with Wikipedia and not with casual editors. Expecting the entire world to modify their behavior to cater to Wikipedia's processes and procedures - which were cooked up by those same editors who are ruining it for everyone else - is a pipe dream at best.
he actually made us double the cost of the build, simply because that then matched his budget so that it wouldn't be cut the next year (spend it or lose it!)
I genuinely feel sorry for anyone having to work within those constraints, and hope the policies contribute to the (relatively) quick death of their organizations. Here's how my company's budgeting works:
Once a year, the boss asks what purchases we've planned for the next year or so. He uses that to estimate our budget needs.
When we need to make those expenditures, we tell him. If it's a good day in the budget cycle (e.g. we didn't just host a convention a few days earlier), he authorizes the purchase. If not, he asks us to wait a week or so first.
If we need something extra and unforeseen, we tell him what we need and why it will benefit the company. We buy it.
If I show him how I saved money by using our current resources more efficiently, he remembers it come annual evaluation day. His long-term response is to become even more receptive to purchase requests because he trusts me to spend his money wisely.
I understand that managing a large corporation is a lot different from running a small company, but the basic principals stand. If you punish departments for efficiency, you deserve bankruptcy.
GPL3 is a (commercial) plague - anything that uses any GPL3 library MUST comply by GPL3 and any license that is not GPL3 becomes GPL3, so Apple had to abandon SAMBA - if they integrate a SAMBA interfacing gui into their OS (which they did under GPL2), they immediately are required to release the entire OS under the GPL.
So many statements, and not a single one factually correct. I applaud your determination!
I just wish it was a little more user friendly. That was the one thing MySQL had going for it.. dead simple to use and admin..
I totally disagree. I've been using PostgreSQL for years and it makes sense. I've had to deal with MySQL from time to time (usually when setting up a blog or some other app that only supports it) and I never can remember how to do the simplest things without heading off to the online manual.
Is MySQL really harder to use than PostgreSQL? Not really. I'm just not used to it. Is PostgreSQL really harder to use than MySQL? Not really. You're just not used to it.
For some people with expensive existing music collections/movie collections (that predate iTunes or that were not gotten through iTunes), an Android tablet is really the only option they have. To a consumer, it's not a question of freedom, they rarely care about that, it's really a question of being able to play the stuff they already paid for.
WTF are you talking about about? I have a huge collection of MP3s from ripped CDs. They import to iTunes (and from their to iOS devices) just fine. I use Handbrake to transcode movies to the Apple -> iPhone 4 preset just because it makes no sense to carry around Blu-Ray quality files on a tiny device. So, what media that predates iTunes or that were not gotten through iTunes are you thinking I'm missing out on?
That's an excellent point. Sega is eternally grateful that Sonic kept them relevant as a console manufacturer so that they never had to stoop to porting their franchises to other platforms.
I'm guessing about.1% of ISP's will be able to support native V6 by then...
We're use a little-known ISP named "Qwest". I asked about native IPv6 last week on a conference call, and the engineer replied, "oh, sure! When do you want to turn it up?" He needs to verify that all the equipment along our routes was ready to go before we make an appointment to go live, but they're actively rolling out IPv6 capability to their customers who want it.
One of the first rules a toddler's parent develops is "hands off the glass! You'll get fingerprints on it!" Never has a parent actually encouraged their kids to smear their peanut-buttery fingers all over a car window.
I had an Amiga in 1985 with all that except 2D instead of 3D. There were viable alternatives to DOS - and those of us happily using them laughed at the little single-tasking green screens with their beeps and text interfaces - but all of them but MacOS fell by the wayside for various reasons.
They don't eat that much battery unless something's broken. It's certainly not the normal state of things. I think the only times I've ever turned off my netbook with Ubuntu is when upgrading the RAM and before removing the battery for travel.
Slashdot Mirror
In fact, I haven't even bothered picking up a smartphone myself.
Then,
Thing is, smartphone games can't hold my attention for more than a few minutes.
So, how would you actually know? There are other games than Angry Birds.
True or false: there are countries in the world that would be more interested in curing citizens than propping up costly, government-owned pharmaceutical labs.
True or false: if the above is true, at least one of those countries is capable of developing medicines on their own without relying on US and European labs.
Your conspiracy-driven position requires the belief that there are no pharm researchers in the entire world motivated by the desire to actually cure disease. You sincerely believe that "Red China" would rather pay US companies for monthly prescriptions to treat common conditions than to develop a cure for them once and for all? Your assumption that all American labs are thoroughly corrupt and that every other lab in every other country in the whole world is corrupt in exactly the same way is amazingly arrogant, astoundingly misguided, and just doesn't jibe with reality.
How would either the FDA or HIPAA be involved with individual customers posting comments about their experiences? The FDA doesn't regulate conversation between patients, and HIPAA only governs what information (and how) a medical provider can share about a patient.
Intel heat sinks have always been sufficient to run the CPU at stock speeds. What more do you want from a stock cooler?
No, they haven't. I bought an E8400 from Newegg and installed it in a very well-ventilated case and set it to run at the precise spec voltages and frequency. With the stock heat sink and fan, the CPU would regularly hit 70C, nearly it's maximum rated temperature. I bought a replacement sink and fan (looked a little overclocker-ish but I didn't want to go halfway) and now it never gets over 48C under heavy load.
Most of Intel's sinks are sufficient, but all of them most certainly are not.
Those numbers are very accurate, except that I rounded my times up slightly and his down to the nearest hour. He wasn't concerned about megabyte-seconds. He was concerned about the horrific idea of a single process using half a gigabyte of RAM for any length of time whatsoever. I'm sure that if you asked him, I was the young punk with no consideration for resource usage.
And again, I understand to a point. I wouldn't want to run a horribly inefficient process that used multiple gigs of RAM simply because it was poorly written. But if I can throw some RAM at a problem to dramatically lighten other resource usage, I'll do it in a heartbeat.
The indices are there not only for data modeling purposes, but also to minimize the amount of uber expensive disk I/O necessary to perform most queries.
For historical reasons, one of our largest tables stores a person's name as "Last, First" instead of using separate fields. I wrote a PostgreSQL functional index like UPPER(SUBSTR(name,1,STRPOS(name,','))). According to "explain analyze", that reduced searching for the last name "Smith" from 1628ms to 79ms.
I know the importance of indexes isn't your main point, but I felt the need to brag.
Or, if we must motivate the hippies, call it "green optimisation". Yes, faster code finishes quicker, using less power to complete the same job.
If I write an inefficient process that causes the CPU to dissipate an extra 10W 24/7, the additional local cost for that electricity would run about $0.60 per month. That works out to approximately 50 seconds salary. While Google-scale operations would probably consider that a worthwhile expenditure, for most small companies it'd be much cheaper (and a lot greener!) to not spend the programmer time to improve it.
Also consider that my desktop, extra monitor, office lights, and office air conditioning add up to a lot more than 10W. I like to eat sometimes, too, and I have to get back and forth to work somehow. It might not be green at all to invest more energy into the optimization process than we'd ever recoup.
If spending an extra day optimizing my code could save me $2000 / mo off my colo bill, I'd be a fool not to invest that time.
Maybe, unless the opportunity cost of deploying your application runs to more than $2,000/day. And will it cost more to maintain your optimized code than the (presumably) more straightforward equivalent?
Some old-school developers prematurely optimize for things we no longer need to optimize for (and shouldn't). From an older post of mine:
He was optimizing for resources that were no longer constrained, and consequently pessimizing for the resources we actually cared about. RAM? Dirt cheap, at least for the dataset sizes involved in that project. Much more expensive was all the extra disk and CPU load he was creating on the company-wide database server (which is sufficiently powerful to serve the entire company when it's not being deliberately assaulted).
I'm not "anything goes" by any means, and I'm the guy responsible for making sure that lots of processes can peacefully coexist on an efficiently small number of servers. But for all intents and purposes, most of our apps have unlimited resources available to them. If they want to use 100% of a CPU core for 5 minutes or 2GB of RAM for half an hour a day, so be it. I'd much rather run simple, testable, maintainable code that happens to use a lot of server power than lovingly hand-mangled code that no one but the original programmer can understand and which interacts with the rest of the network in entertainingly unpredictable ways.
I have no idea what BRD means, but yeah, that's the gist of it. I hope we can also agree that would-be casual editors outnumber entrenched, abusive editors by a couple of orders of magnitude.
Next time this happens, take the revert to the article's talk page.
What you cannot seem to be made to understand is that no one outside Wikipedia can be bothered to give a shit about "the proper process". We don't care. It's one thing to see an article we can copy-edit or add a little bit to. Hey, I can spend two minutes adding to the collection of human knowledge? I'm in! But it's entirely different to expect us to want to spend time babysitting our edits so that the griefer jackasses who stake ownership to large swaths of a hard drive don't delete our work on a whim.
You keep saying "well, all you have to do is..." but that's never going to happen. We're not "into" Wikipedia in the same way that the Aspie teen hitting "reload" 100 times an hour is, and aren't willing to donate large chunks of time to it.
The problems (and any possible solutions) lie wholly with Wikipedia and not with casual editors. Expecting the entire world to modify their behavior to cater to Wikipedia's processes and procedures - which were cooked up by those same editors who are ruining it for everyone else - is a pipe dream at best.
Why double your efforts to increase your pool of potential victims by only ~10%?
So that you have own 100% of that 10% market share instead of 1/1000th of the 90%.
he actually made us double the cost of the build, simply because that then matched his budget so that it wouldn't be cut the next year (spend it or lose it!)
I genuinely feel sorry for anyone having to work within those constraints, and hope the policies contribute to the (relatively) quick death of their organizations. Here's how my company's budgeting works:
If I show him how I saved money by using our current resources more efficiently, he remembers it come annual evaluation day. His long-term response is to become even more receptive to purchase requests because he trusts me to spend his money wisely.
I understand that managing a large corporation is a lot different from running a small company, but the basic principals stand. If you punish departments for efficiency, you deserve bankruptcy.
It's evolution in action. Anyone so high-strung that they have to invent illnesses will die early of stress.
GPL3 is a (commercial) plague - anything that uses any GPL3 library MUST comply by GPL3 and any license that is not GPL3 becomes GPL3, so Apple had to abandon SAMBA - if they integrate a SAMBA interfacing gui into their OS (which they did under GPL2), they immediately are required to release the entire OS under the GPL.
So many statements, and not a single one factually correct. I applaud your determination!
I just wish it was a little more user friendly. That was the one thing MySQL had going for it.. dead simple to use and admin..
I totally disagree. I've been using PostgreSQL for years and it makes sense. I've had to deal with MySQL from time to time (usually when setting up a blog or some other app that only supports it) and I never can remember how to do the simplest things without heading off to the online manual.
Is MySQL really harder to use than PostgreSQL? Not really. I'm just not used to it. Is PostgreSQL really harder to use than MySQL? Not really. You're just not used to it.
My fucking Atari 800 blew the doors off of anything that came along for more than a decade
Macs came out in '84. Amigas debuted in '85. Either you're prone to hyperbole to prove specious points, or you were way, way too into Atari hardware.
depends how stupid the user is and how he uses it
Like, being stupid enough to use Visio? Have a Bluetooth device? Work with Excel? Have .NET installed? Use Silverlight to watch Netflix? Ever allow their desktops to display text for any reason? Run an app that uses DNS?
Yeah. You'd have to be a complete moron to want to do any of those extreme, unusual, inherently risky things.
no?
No.
For some people with expensive existing music collections/movie collections (that predate iTunes or that were not gotten through iTunes), an Android tablet is really the only option they have. To a consumer, it's not a question of freedom, they rarely care about that, it's really a question of being able to play the stuff they already paid for.
WTF are you talking about about? I have a huge collection of MP3s from ripped CDs. They import to iTunes (and from their to iOS devices) just fine. I use Handbrake to transcode movies to the Apple -> iPhone 4 preset just because it makes no sense to carry around Blu-Ray quality files on a tiny device. So, what media that predates iTunes or that were not gotten through iTunes are you thinking I'm missing out on?
...up until now, when they're slashing the price of just-released platforms because no one (relatively speaking) is buying them.
That's an excellent point. Sega is eternally grateful that Sonic kept them relevant as a console manufacturer so that they never had to stoop to porting their franchises to other platforms.
I'm guessing about .1% of ISP's will be able to support native V6 by then...
We're use a little-known ISP named "Qwest". I asked about native IPv6 last week on a conference call, and the engineer replied, "oh, sure! When do you want to turn it up?" He needs to verify that all the equipment along our routes was ready to go before we make an appointment to go live, but they're actively rolling out IPv6 capability to their customers who want it.
One of the first rules a toddler's parent develops is "hands off the glass! You'll get fingerprints on it!" Never has a parent actually encouraged their kids to smear their peanut-buttery fingers all over a car window.
I had an Amiga in 1985 with all that except 2D instead of 3D. There were viable alternatives to DOS - and those of us happily using them laughed at the little single-tasking green screens with their beeps and text interfaces - but all of them but MacOS fell by the wayside for various reasons.
They don't eat that much battery unless something's broken. It's certainly not the normal state of things. I think the only times I've ever turned off my netbook with Ubuntu is when upgrading the RAM and before removing the battery for travel.
None whatsoever, because the people that hardcore into systems work probably wouldn't work on PulseAudio if you held them at gunpoint.