It's an understandable sentiment. I find that I enjoy WoW more (and games like Civ4) when I stop and smell the roses and stop rushing from place to place. The trick then, is to learn how to use QH only when I get stuck because the quest text is purposely or accidentally extra-obtuse.
But at this point, I've seen 80-90% of the quests. I've gotten to 80, and the only time I pay close attention is if I'm on a quest chain that is involved and interesting. Or it happens to be one that I hadn't done yet on my myriad of alts.
One of the nicer things about QH is when I'm questing with others who also have QH (the people that I quest with frequently). That makes it extremely nice, because we can coordinate our actions, and we're all on pretty much the same page without an excessive bit of typing about status. We'd much rather leave our brains free to talk about other stuff, or roleplay.
Either way, with the use of credentials - you have a way to contact the *right* person. Without authentication, you're taking stabs in the dark which is not worth doing. You can't prove which user caused the issue because all you have is an IP address. (Although the RIAA is trying hard...)
With authentication, it basically boils down to one of two cases:
A) The user's PC is infected, the spambot read their username/password out of a configuration file. In this case, you've identified the correct person to contact and you can, via your TOS contract, require them to take corrective action before reconnecting to your network.
B) The user's authentication credentials have been stolen or shared (almost always against the terms of service). Once again, you have a person that you can contact and tell them to correct the situation. Maybe you block them entirely, maybe you rate limit down to 1 email per hour, or force all their web traffic to go to a notification page. Or you have a CS rep call them and have them change their password. Bottom line, you can prove that the user account was used for actions not within the TOS contract and can then force the other party to take corrective action.
And it's not a black/white corrective situation. You might decide to apply a variety of methods. The initial contact might be via e-mail listed in the customers contact profile. If that doesn't work, an automated phone call might fit the bill. Or progressively worse rate limiting (100 per day down to 1 e-mail per day) until the issue is fixed. Since all of the traffic flows through a single point (the Verizon mail server) and has credentials attached to it, management of the situation is simply a lot easier.
- ISPs have structured their networks where download speeds are higher then upload speeds, because that works for 80%+ of their user base.
- They don't want to be bothered with service calls from people trying to run their own servers. If you want that, get a business package with better support for doing things that the large majority of the user base does not do.
- It's about control and revenue. Business are willing to pay more for less control, therefore it makes sense from a revenue standpoint to charge more to those who are willing to pay for more.
- Bandwidth is not free. It's getting cheaper every year, but those really big links to other ISPs (or even other sections of the ISP network) are expensive.
Which all boils down to - if you want more service then the other 80% of the population, you're going to have to pay more for it. If you're not willing to pay for it, then it is apparently not important enough for you. (Or your business model is flawed because you're wishing that the world worked differently. In which case you can either get into the ISP business yourself and do it the way that you want to, or shop around for a better ISP.)
Which is fine, because it narrows the area that you have to watch for outbound spam runs. Instead of having to run filtering software on port 25 at the border routers (which are probably already overworked), you can now make the mail server do it.
And as a bonus, the mail server (because of authentication) will be able to e-mail the sender (whose credentials were used to do the run) that either their machine is infected or their credentials have been stolen. You're no longer guessing on which IP number is associated with which ISP customer, or what their contact address might be.
As for the line "we don't trust our ISP's mail server"... well, tough. At some point, you *have* to trust some mail server to transmit your e-mail. If you want to run your own mail server, go ahead, and get the ISP to unblock you on port 25. Odds are, if you do this, you're probably not part of the 99.99% of the ISP's customer base who are causing the problem. Or you can sign up with a 3rd party e-mail provider (GMail?) and submit your e-mails to their mail server for further delivery.
Heck, as a bonus, you're more likely to get SSL/TLS over port 465 or 587 then you could over port 25 with a 3rd party e-mail provider. So now your outbound e-mails and authentication details are protected from snooping until they get to the 3rd party mail server.
Mostly it's hotel internet access that filters anything listed as a "common" tcp port until you pay an exorbitant fee. I could have gotten around that by putting SSH on a non-standard port and making a tunnel, but what's the fun in that.
Eh, SSH should almost always be run on a non-standard port if it's a public-facing IP address. If for no other reason then to stop the ceaseless and unrelenting dictionary attacks on your SSH server that fill up log files. It doesn't stop focused attacks, or crackers who use nmap first, but it definitely cuts the number of log messages by a few orders of magnitude.
(Even with only public-key authentication to our SSH servers, we still move it to a non-standard port.)
Which pretty much boils down to, for smaller shops:
- VMWare is nice, but too damned expensive
- Xen is basically free, or we can pay for better support, but is rough around the edges
- Microsoft's solution... well, we simply don't trust Microsoft not to lock us in, even if it's free
So we run Xen. Maybe we'll upgrade to the commercial version someday when I have the spare cash laying around not being used.
If AMD hadn't rushed with their 64 bit version of the x86, about now, itanium would be getting popular and hence cheap.
Market forces have so much to do with technology advancement. A lot of times, superior technology has to take a back seat...
Superior tech or not for Itanium, it sure didn't feel superior at the time. To go with Itanium, you would have:
- been locked back into a single chip vendor, like the days of yore before Cyrix, AMD and VIA hit the scene
- had to put up with sub-par 32bit performance
- bet the farm that Itanium would truly be the future
- spend a lot more
Thanks, but no thanks. AMD came out with Athlon64 and Opteron 64bit, which gave you 64bit future-proofing while giving you outstanding (for the time) 32bit performance. There was simply no short-term (or long-term) downside to going with the AMD chips. You were covered no matter which way the market moved.
While I agree it's unlikely that the nuclear weapons would actually detonate, the probability of the breach of containment of nuclear materials would be very high indeed.
The reactor... maybe. It's pretty hard to tear through a few meters of hull along the long axis and then still have enough energy to rip apart anywhere from 1/2 meter to a full meter of that which encloses the reactor vessel. How often to car engine blocks shatter and turn into little pieces in accidents?
The primary heat exchange portion with the radioactive steam? Sure. But the odds of breaching the reactor vessel itself? Not very high. Or not enough that it would end up as more then a single lump on the floor of the ocean. The majority of the fuel inside the reactor would still end up in a single place.
Same thing with the ICBMs. The reentry vehicles are pretty tough little cones with the nuclear material packed inside an even smaller denser mass. It would be pretty tough to rip one of those apart, and even harder to turn that lump of plutonium or whatever into a dust cloud instead of a simple misshapen inert lump that falls to the ocean floor intact.
And getting one to detonate? Let's assume that you did manage to set fire to one of the explosive blocks. Because you would not have managed a properly timed explosion all the way around, you would get at best a fizzle and more likely nothing more then the ignition of the explosive blocks. And the now misshapen lump of plutonium would simply fall to the bottom of the ocean without going off.
And the scariest thing here is how bad their math was, predicting it would hit somewhere in Alberta and then having it land off the coast of AFRICA. Someone move a decimal place?
That or it's because the upper atmosphere is lumpy and bulgy? So you can get a fair difference in atmospheric drag, along with the fun of calculating drag for a tumbling odd-shaped object.
MS-Access QBE was just the ready example at hand that most people would have exposure to. I have used it in the past to figure out more complex SQL statements, but it's also Jet SQL - which is about 2 steps away from standard SQL in a weird direction. Never used Paradox (we switched from a mainfram SQL query server on top of DB2 to MS Access 2.0).
I still prefer for people to learn SQL rather then some QBE tool. SQL is fairly universal, and QBE isn't always available. QBE then becomes a learning tool for the times when the QBE simply can't represent what you need it to. To only know one or the other is not wise.
I still use QBE for about 80% of my workload though.
Over 15 years ago Paradox's query-by-example was light-years ahead of today's soul-killing SQL crap.
QBE grids are nothing more then a UI abstraction of the underlying SQL SELECT statement. In fact, in MS-Access (which has a QBE grid), you can flip between looking at the QBE and looking at the raw SQL SELECT statement.
Sometimes it's faster to do it in raw SQL, sometimes it's faster to setup the query in a QBE grid.
Given the closure of major electronic/computer retailers that used to provide the venue where customers could see MS products in action MS probably wants to ensure it keeps a presence in front of consumers.
So they're going to compete directly against retailers for Microsoft business? That sounds like a surefire method for ticking off the retailers who are selling your product.
Especially since Microsoft has not been known for good vendor relations.
The usual problems with letting people take a cat for a "mouser" are:
They think that the cat doesn't need to be fed because it will go hunt for its food. Which means that you're going to have an undernourished kitty, in constant need of de-worming, that will have to wander over a possibly large area which exposes it to lots of risks. Especially in an urban or semi-urban environment. Cars, dogs, poisons, or anti-social humans who think cats are there for their sick amusement.
Secondly, the rescue places will typically not know or be able to figure out which cats are "mousers" and which aren't. Unless you're going to bring live mice along in your pockets and hold a field test in a secure room, you won't be able to tell before you take the kitty home.
But mostly, people who ask for "mousers" are those who will not see the cat as a companion with needs. For a cat raised to associate with humans, this lack of attention and care will lead to behaviors that aren't desirable. These behaviors are generally the result of stress because the cat's needs are not being met. Such as being left alone all the time, lack of adequate food/water, pent-up energy or aggression, only negative contact with humans resulting in fear/aggression.
(It's not true that everyone looking for a "mouser" is going to be an absentee, hands-off, throw the cat to the wild, owner. But there have been enough problems over the years that it's a red flag.)
Most of the farms I'm familiar with have a colony of cats living in each barn. Each colony gets a fixed ration of food each day, and no, none of the cats have ever been "fixed". Those cats will chase anything they think they can eat.
Starving or not starving the cats has no effect on their catches. The key is that they were taught to be mousers by their mother. Even fixed / not fixed doesn't have any effect (and ultimately, the cats would be healthier if they were fixed).
You can try being an apologist for OO.org all you want. Unfortunately, there are still some large glaring holes in their product (even as of v3).
The latest one that I've run into is the Base component. Which doesn't offer any simple way to import/export data from CSV, XLS, tab-delimited or other external data files. For some of those data file types, you have to go through the spreadsheet component of OO.org, which is extremely convoluted. The equivalent in MS-Access is pretty much "File, Import" or "File, Export" (depending on the version of MS-Access).
Or say that I want to link to some MDB file. I have to create a registered data connection in order to do so. So for each MDB that I work with, I'm going to have to create at least one registered connection. Which is going to be damn ugly about the time that I start working with my 500th MDB file. On the MS-Access side, they've chosen to simply make that file-specific and if you need a global, permanent, registered type connection, you create a user/system DSN.
Now, that's not to say that OO.Base isn't getting better. But there are still some really really sucky UI choices that simply make getting work done harder then it has to be.
In general, you can build a mid-range gaming rig for about $900 ($250 for the MB/CPU/RAM, $150 for the case/PSU, $150 for the Windows license, $150 for a mid-range video card, $200 for drives and misc).
You could probably shave a few corners and still have a very good rig for low-end gaming for about $700.
Not sure I'd go much below that price point personally, as you end up with too many low-end components, or things that you'll have to replace constantly.
The point is when I got into computing ( and yes I'm old, dammit!) programmers squeezed every bit of performance they possibly could while using as little resources as possible. Why? Because they didn't have multicores with craploads of RAM to waste. But now I have noticed the software has taken on the SUV model of not caring how crappy the resource suckage as long as you can add more crap to it. That is why I am hoping that this trend towards Netbooks ends up with programmers looking at performance again. There is NO reason you should need a freaking dual core to watch Youtube! Coders need to learn to write efficient code again instead of expecting Moore's law to do the heavy lifting. Because with the economy in the toilet and prices likely to go no where but up when it comes to energy we could all use more efficient machines instead of simply filling up the cycles with ever more bloated code.
If hardware is more expensive then programmer time - then optimization counts.
If more hardware is less expensive then programmer time - optimization isn't worth it.
For the large part of the past 15 years, adding more hardware has been a lot less expensive then spending the money on good programmers who optimize code. If energy costs continue to rise and CPUs can no longer be made to do more with less power, then we'll start to see a shift back to worrying about optimization.
I clearly remember when the Pentium (original 60-MHZ version) came out, that was the big selling point was the capability of watching videos on it. In fact, I've got a CD I picked up back then that had the Beatles movie A Hard Days Night on it, and it played fine on my old 486.
At what resolution and frame rate?
Back then, it was probably 160x120, 15fps. Which was pretty common for the Intel Indeo codec (IIRC). If you were lucky, it was MPEG2 320x240 at 30fps.
The first is a data stream which is probably only around 300KB/sec (a lot less with compression), the second is a data stream that is around 4500KB/sec (again, a lot less with compression). DVD streams are typically 3-4 Mbps (300-400 KB/sec compressed) and expand out to around 32,000 KB/sec of raw data.
And a raw 720p data stream is closer to 85,000 KB/sec. Fortunately, you can compress that down with the modern MPEG4 codecs to under 300 KB/sec. A raw 1080p stream would be even larger (around 190,000 KB/sec).
Ignoring all the numbers, my point is that higher resolution video requires a lot more CPU power in order to do all of the number crunching. Modern codecs are generally easy to decompress, but hard to compress. So most of the power is needed on the input side, but you still need a modest amount of CPU power on the output side to keep up.
I really feel sorry for people living around airports today. We have noise pollution laws for everything but aircraft.
Eh... I think you're off-base here. Back in the mid-90s, UPS (for one), retrofitted a large portion of their jet fleet with quieter engines or kits that would reduce the radiated noise.
Now, whether anything has been done on a similar scale in the past 12 years, I'm not sure. (I no longer work for UPS.)
Is there a dedicated bootable media that will stress test the system since memtest86 is near useless?
Bootable? Probably not, but try the Prime95 client from mersenne.org. It has a self-test function, and because of the calculations involved, it places an extremely heavy load on CPU/RAM/cache. (It also self-checks its calculations to see whether an error has crept in.)
The post you reply to is written by a numbskull. Compiling software doesn't even begin to ensure that all possible memory locations accessed and bit values are written. The vast majority of what is going on during a compile and/or md5 sum is going to happen in the processor's L1 & L2 caches.
On the other hand memtest86(+) has a methodology that includes disabling cache and ensures that all possible locations are written to and read from. Additionally there is a mixture of patterns used, from random patterns for general testing to specific patterns (both bit value & access ordering) for exercising known failure modes of DRAM.
Finally the idea that you can "stress" you RAM is nuts. Outside of running the device out of spec (e.g. overclocking), the only "stress" possible is heat and just being on will get it into the normal operating temperatures. Anything else is what it's designed to do, there is no ubermagic access pattern driven by that "well known" gcc that causes DRAM to fall over dead.
I'll chime in here. MemTest86 and MemTest86+ are only capable of finding memory that has completely failed. Where MemTest86(+) falls down is cases where the timings between the CPU and RAM are marginal. Such as setting the memory timings in the BIOS too low (even if the memory is reportedly spec'd as such). Been there, done that. The system would pass MemTest86(+) with flying colors, but would crash regularly (although randomly as is the wont with timing issues) under normal use.
My preferred method for finding borderline memory issues like that is Prime95 in torture-test mode. Calculation of the Mersennes is extremely CPU/cache/memory intensive, and the Prime95 program self-checks the calculations. Which means, in general, that you can get it to uncover instability issues within the first 24-48 hours of starting the self-test. On the flip side, if you can run 48+ hours without seeing an error, you're probably not going to see memory errors under normal use.
(I've also seen cases in the past where a Windows 2000 server would corrupt data going across the onboard SATA ports. But only when the CPU was running close to 100% utilization. And this was a server/workstation class motherboard from a well known supplier. So often, the only way to really uncover stability issues is to come up with an access pattern that stress tests the various components simultaneously.)
Which is why "motherboard bundles" were invented. Go to some place like MWave.com, go to their motherboard bundle section. Pick a CPU, motherboard and RAM, then pay about $10 to have the vendor assemble and test it before shipping.
For $10, I'm guaranteed that those 3 components will work together and won't be DoA. I don't have to keep up with the various socket types, or memory types, or figure out that socket X fits CPUs Q and W.
The big problem with the early Athlons was that they would not self-limit when their heatsink failed.
But they fixed that issue at least 5 years ago (all of the Athlon64 parts are self-throttling and will not fry themselves).
It's one of the few mis-steps that AMD made over the years.
The primary reason that we switched to AMD was back when the Athlon64 chips were first released. At the time, 64bit future was hazy. Would it arrive next year? Three years? How soon would we need to have 64bit capable machines? Your choices back then were either Intel's Itanium - which was an absolute dog at running 32bit x86 code, or AMD Athlon64 - which ran 32bit x86 code like a champ and gave you the potential to switch to 64bit later.
So we got the best of both worlds. Good 32bit x86 performance in the near term with future proofing so that we could run 64bit code later. We didn't have to wait around for Intel to release the Core 2 Duo line.
Slashdot Mirror
It's an understandable sentiment. I find that I enjoy WoW more (and games like Civ4) when I stop and smell the roses and stop rushing from place to place. The trick then, is to learn how to use QH only when I get stuck because the quest text is purposely or accidentally extra-obtuse.
But at this point, I've seen 80-90% of the quests. I've gotten to 80, and the only time I pay close attention is if I'm on a quest chain that is involved and interesting. Or it happens to be one that I hadn't done yet on my myriad of alts.
One of the nicer things about QH is when I'm questing with others who also have QH (the people that I quest with frequently). That makes it extremely nice, because we can coordinate our actions, and we're all on pretty much the same page without an excessive bit of typing about status. We'd much rather leave our brains free to talk about other stuff, or roleplay.
Either way, with the use of credentials - you have a way to contact the *right* person. Without authentication, you're taking stabs in the dark which is not worth doing. You can't prove which user caused the issue because all you have is an IP address. (Although the RIAA is trying hard...)
With authentication, it basically boils down to one of two cases:
A) The user's PC is infected, the spambot read their username/password out of a configuration file. In this case, you've identified the correct person to contact and you can, via your TOS contract, require them to take corrective action before reconnecting to your network.
B) The user's authentication credentials have been stolen or shared (almost always against the terms of service). Once again, you have a person that you can contact and tell them to correct the situation. Maybe you block them entirely, maybe you rate limit down to 1 email per hour, or force all their web traffic to go to a notification page. Or you have a CS rep call them and have them change their password. Bottom line, you can prove that the user account was used for actions not within the TOS contract and can then force the other party to take corrective action.
And it's not a black/white corrective situation. You might decide to apply a variety of methods. The initial contact might be via e-mail listed in the customers contact profile. If that doesn't work, an automated phone call might fit the bill. Or progressively worse rate limiting (100 per day down to 1 e-mail per day) until the issue is fixed. Since all of the traffic flows through a single point (the Verizon mail server) and has credentials attached to it, management of the situation is simply a lot easier.
What, is that a rule of some kind?
It's a defacto rule for a couple of reasons
- ISPs have structured their networks where download speeds are higher then upload speeds, because that works for 80%+ of their user base.
- They don't want to be bothered with service calls from people trying to run their own servers. If you want that, get a business package with better support for doing things that the large majority of the user base does not do.
- It's about control and revenue. Business are willing to pay more for less control, therefore it makes sense from a revenue standpoint to charge more to those who are willing to pay for more.
- Bandwidth is not free. It's getting cheaper every year, but those really big links to other ISPs (or even other sections of the ISP network) are expensive.
Which all boils down to - if you want more service then the other 80% of the population, you're going to have to pay more for it. If you're not willing to pay for it, then it is apparently not important enough for you. (Or your business model is flawed because you're wishing that the world worked differently. In which case you can either get into the ISP business yourself and do it the way that you want to, or shop around for a better ISP.)
Which is fine, because it narrows the area that you have to watch for outbound spam runs. Instead of having to run filtering software on port 25 at the border routers (which are probably already overworked), you can now make the mail server do it.
And as a bonus, the mail server (because of authentication) will be able to e-mail the sender (whose credentials were used to do the run) that either their machine is infected or their credentials have been stolen. You're no longer guessing on which IP number is associated with which ISP customer, or what their contact address might be.
As for the line "we don't trust our ISP's mail server"... well, tough. At some point, you *have* to trust some mail server to transmit your e-mail. If you want to run your own mail server, go ahead, and get the ISP to unblock you on port 25. Odds are, if you do this, you're probably not part of the 99.99% of the ISP's customer base who are causing the problem. Or you can sign up with a 3rd party e-mail provider (GMail?) and submit your e-mails to their mail server for further delivery.
Heck, as a bonus, you're more likely to get SSL/TLS over port 465 or 587 then you could over port 25 with a 3rd party e-mail provider. So now your outbound e-mails and authentication details are protected from snooping until they get to the 3rd party mail server.
Mostly it's hotel internet access that filters anything listed as a "common" tcp port until you pay an exorbitant fee. I could have gotten around that by putting SSH on a non-standard port and making a tunnel, but what's the fun in that.
Eh, SSH should almost always be run on a non-standard port if it's a public-facing IP address. If for no other reason then to stop the ceaseless and unrelenting dictionary attacks on your SSH server that fill up log files. It doesn't stop focused attacks, or crackers who use nmap first, but it definitely cuts the number of log messages by a few orders of magnitude.
(Even with only public-key authentication to our SSH servers, we still move it to a non-standard port.)
Which pretty much boils down to, for smaller shops:
- VMWare is nice, but too damned expensive
- Xen is basically free, or we can pay for better support, but is rough around the edges
- Microsoft's solution... well, we simply don't trust Microsoft not to lock us in, even if it's free
So we run Xen. Maybe we'll upgrade to the commercial version someday when I have the spare cash laying around not being used.
If AMD hadn't rushed with their 64 bit version of the x86, about now, itanium would be getting popular and hence cheap. Market forces have so much to do with technology advancement. A lot of times, superior technology has to take a back seat ...
Superior tech or not for Itanium, it sure didn't feel superior at the time. To go with Itanium, you would have:
- been locked back into a single chip vendor, like the days of yore before Cyrix, AMD and VIA hit the scene
- had to put up with sub-par 32bit performance
- bet the farm that Itanium would truly be the future
- spend a lot more
Thanks, but no thanks. AMD came out with Athlon64 and Opteron 64bit, which gave you 64bit future-proofing while giving you outstanding (for the time) 32bit performance. There was simply no short-term (or long-term) downside to going with the AMD chips. You were covered no matter which way the market moved.
While I agree it's unlikely that the nuclear weapons would actually detonate, the probability of the breach of containment of nuclear materials would be very high indeed.
The reactor... maybe. It's pretty hard to tear through a few meters of hull along the long axis and then still have enough energy to rip apart anywhere from 1/2 meter to a full meter of that which encloses the reactor vessel. How often to car engine blocks shatter and turn into little pieces in accidents?
The primary heat exchange portion with the radioactive steam? Sure. But the odds of breaching the reactor vessel itself? Not very high. Or not enough that it would end up as more then a single lump on the floor of the ocean. The majority of the fuel inside the reactor would still end up in a single place.
Same thing with the ICBMs. The reentry vehicles are pretty tough little cones with the nuclear material packed inside an even smaller denser mass. It would be pretty tough to rip one of those apart, and even harder to turn that lump of plutonium or whatever into a dust cloud instead of a simple misshapen inert lump that falls to the ocean floor intact.
And getting one to detonate? Let's assume that you did manage to set fire to one of the explosive blocks. Because you would not have managed a properly timed explosion all the way around, you would get at best a fizzle and more likely nothing more then the ignition of the explosive blocks. And the now misshapen lump of plutonium would simply fall to the bottom of the ocean without going off.
And the scariest thing here is how bad their math was, predicting it would hit somewhere in Alberta and then having it land off the coast of AFRICA. Someone move a decimal place?
That or it's because the upper atmosphere is lumpy and bulgy? So you can get a fair difference in atmospheric drag, along with the fun of calculating drag for a tumbling odd-shaped object.
MS-Access QBE was just the ready example at hand that most people would have exposure to. I have used it in the past to figure out more complex SQL statements, but it's also Jet SQL - which is about 2 steps away from standard SQL in a weird direction. Never used Paradox (we switched from a mainfram SQL query server on top of DB2 to MS Access 2.0).
I still prefer for people to learn SQL rather then some QBE tool. SQL is fairly universal, and QBE isn't always available. QBE then becomes a learning tool for the times when the QBE simply can't represent what you need it to. To only know one or the other is not wise.
I still use QBE for about 80% of my workload though.
Over 15 years ago Paradox's query-by-example was light-years ahead of today's soul-killing SQL crap.
QBE grids are nothing more then a UI abstraction of the underlying SQL SELECT statement. In fact, in MS-Access (which has a QBE grid), you can flip between looking at the QBE and looking at the raw SQL SELECT statement.
Sometimes it's faster to do it in raw SQL, sometimes it's faster to setup the query in a QBE grid.
Better than PokemonDB. Then you have to jump on top of your desk and shout "Customer Table, I select you!" every time you run a damn query.
*polite golf clap*
Given the closure of major electronic/computer retailers that used to provide the venue where customers could see MS products in action MS probably wants to ensure it keeps a presence in front of consumers.
So they're going to compete directly against retailers for Microsoft business? That sounds like a surefire method for ticking off the retailers who are selling your product.
Especially since Microsoft has not been known for good vendor relations.
The usual problems with letting people take a cat for a "mouser" are:
They think that the cat doesn't need to be fed because it will go hunt for its food. Which means that you're going to have an undernourished kitty, in constant need of de-worming, that will have to wander over a possibly large area which exposes it to lots of risks. Especially in an urban or semi-urban environment. Cars, dogs, poisons, or anti-social humans who think cats are there for their sick amusement.
Secondly, the rescue places will typically not know or be able to figure out which cats are "mousers" and which aren't. Unless you're going to bring live mice along in your pockets and hold a field test in a secure room, you won't be able to tell before you take the kitty home.
But mostly, people who ask for "mousers" are those who will not see the cat as a companion with needs. For a cat raised to associate with humans, this lack of attention and care will lead to behaviors that aren't desirable. These behaviors are generally the result of stress because the cat's needs are not being met. Such as being left alone all the time, lack of adequate food/water, pent-up energy or aggression, only negative contact with humans resulting in fear/aggression.
(It's not true that everyone looking for a "mouser" is going to be an absentee, hands-off, throw the cat to the wild, owner. But there have been enough problems over the years that it's a red flag.)
Most of the farms I'm familiar with have a colony of cats living in each barn. Each colony gets a fixed ration of food each day, and no, none of the cats have ever been "fixed". Those cats will chase anything they think they can eat.
Starving or not starving the cats has no effect on their catches. The key is that they were taught to be mousers by their mother. Even fixed / not fixed doesn't have any effect (and ultimately, the cats would be healthier if they were fixed).
OS/2 lost the war because of the price of memory in 1993-1995 timeframe. It would have replaced Windows entirely if it could have run in 4MB of RAM.
They lost out for a few reasons in addition to that:
- Microsoft FUD and Win95.
- The cost of development tools were too high. Hobbyists had no cheap and inexpensive way to get started on writing applications.
I ran OS/2 for a few years as my primary operating system (skipping directly from DOS 5.0 to OS/2 to NT v4, bypassing Win95/Win98 entirely).
You can try being an apologist for OO.org all you want. Unfortunately, there are still some large glaring holes in their product (even as of v3).
The latest one that I've run into is the Base component. Which doesn't offer any simple way to import/export data from CSV, XLS, tab-delimited or other external data files. For some of those data file types, you have to go through the spreadsheet component of OO.org, which is extremely convoluted. The equivalent in MS-Access is pretty much "File, Import" or "File, Export" (depending on the version of MS-Access).
Or say that I want to link to some MDB file. I have to create a registered data connection in order to do so. So for each MDB that I work with, I'm going to have to create at least one registered connection. Which is going to be damn ugly about the time that I start working with my 500th MDB file. On the MS-Access side, they've chosen to simply make that file-specific and if you need a global, permanent, registered type connection, you create a user/system DSN.
Now, that's not to say that OO.Base isn't getting better. But there are still some really really sucky UI choices that simply make getting work done harder then it has to be.
In general, you can build a mid-range gaming rig for about $900 ($250 for the MB/CPU/RAM, $150 for the case/PSU, $150 for the Windows license, $150 for a mid-range video card, $200 for drives and misc).
You could probably shave a few corners and still have a very good rig for low-end gaming for about $700.
Not sure I'd go much below that price point personally, as you end up with too many low-end components, or things that you'll have to replace constantly.
The point is when I got into computing ( and yes I'm old, dammit!) programmers squeezed every bit of performance they possibly could while using as little resources as possible. Why? Because they didn't have multicores with craploads of RAM to waste. But now I have noticed the software has taken on the SUV model of not caring how crappy the resource suckage as long as you can add more crap to it. That is why I am hoping that this trend towards Netbooks ends up with programmers looking at performance again. There is NO reason you should need a freaking dual core to watch Youtube! Coders need to learn to write efficient code again instead of expecting Moore's law to do the heavy lifting. Because with the economy in the toilet and prices likely to go no where but up when it comes to energy we could all use more efficient machines instead of simply filling up the cycles with ever more bloated code.
If hardware is more expensive then programmer time - then optimization counts.
If more hardware is less expensive then programmer time - optimization isn't worth it.
For the large part of the past 15 years, adding more hardware has been a lot less expensive then spending the money on good programmers who optimize code. If energy costs continue to rise and CPUs can no longer be made to do more with less power, then we'll start to see a shift back to worrying about optimization.
I clearly remember when the Pentium (original 60-MHZ version) came out, that was the big selling point was the capability of watching videos on it. In fact, I've got a CD I picked up back then that had the Beatles movie A Hard Days Night on it, and it played fine on my old 486.
At what resolution and frame rate?
Back then, it was probably 160x120, 15fps. Which was pretty common for the Intel Indeo codec (IIRC). If you were lucky, it was MPEG2 320x240 at 30fps.
The first is a data stream which is probably only around 300KB/sec (a lot less with compression), the second is a data stream that is around 4500KB/sec (again, a lot less with compression). DVD streams are typically 3-4 Mbps (300-400 KB/sec compressed) and expand out to around 32,000 KB/sec of raw data.
And a raw 720p data stream is closer to 85,000 KB/sec. Fortunately, you can compress that down with the modern MPEG4 codecs to under 300 KB/sec. A raw 1080p stream would be even larger (around 190,000 KB/sec).
Ignoring all the numbers, my point is that higher resolution video requires a lot more CPU power in order to do all of the number crunching. Modern codecs are generally easy to decompress, but hard to compress. So most of the power is needed on the input side, but you still need a modest amount of CPU power on the output side to keep up.
I really feel sorry for people living around airports today. We have noise pollution laws for everything but aircraft.
Eh... I think you're off-base here. Back in the mid-90s, UPS (for one), retrofitted a large portion of their jet fleet with quieter engines or kits that would reduce the radiated noise.
Now, whether anything has been done on a similar scale in the past 12 years, I'm not sure. (I no longer work for UPS.)
Is there a dedicated bootable media that will stress test the system since memtest86 is near useless?
Bootable? Probably not, but try the Prime95 client from mersenne.org. It has a self-test function, and because of the calculations involved, it places an extremely heavy load on CPU/RAM/cache. (It also self-checks its calculations to see whether an error has crept in.)
The post you reply to is written by a numbskull. Compiling software doesn't even begin to ensure that all possible memory locations accessed and bit values are written. The vast majority of what is going on during a compile and/or md5 sum is going to happen in the processor's L1 & L2 caches.
On the other hand memtest86(+) has a methodology that includes disabling cache and ensures that all possible locations are written to and read from. Additionally there is a mixture of patterns used, from random patterns for general testing to specific patterns (both bit value & access ordering) for exercising known failure modes of DRAM.
Finally the idea that you can "stress" you RAM is nuts. Outside of running the device out of spec (e.g. overclocking), the only "stress" possible is heat and just being on will get it into the normal operating temperatures. Anything else is what it's designed to do, there is no ubermagic access pattern driven by that "well known" gcc that causes DRAM to fall over dead.
I'll chime in here. MemTest86 and MemTest86+ are only capable of finding memory that has completely failed. Where MemTest86(+) falls down is cases where the timings between the CPU and RAM are marginal. Such as setting the memory timings in the BIOS too low (even if the memory is reportedly spec'd as such). Been there, done that. The system would pass MemTest86(+) with flying colors, but would crash regularly (although randomly as is the wont with timing issues) under normal use.
My preferred method for finding borderline memory issues like that is Prime95 in torture-test mode. Calculation of the Mersennes is extremely CPU/cache/memory intensive, and the Prime95 program self-checks the calculations. Which means, in general, that you can get it to uncover instability issues within the first 24-48 hours of starting the self-test. On the flip side, if you can run 48+ hours without seeing an error, you're probably not going to see memory errors under normal use.
(I've also seen cases in the past where a Windows 2000 server would corrupt data going across the onboard SATA ports. But only when the CPU was running close to 100% utilization. And this was a server/workstation class motherboard from a well known supplier. So often, the only way to really uncover stability issues is to come up with an access pattern that stress tests the various components simultaneously.)
Which is why "motherboard bundles" were invented. Go to some place like MWave.com, go to their motherboard bundle section. Pick a CPU, motherboard and RAM, then pay about $10 to have the vendor assemble and test it before shipping.
For $10, I'm guaranteed that those 3 components will work together and won't be DoA. I don't have to keep up with the various socket types, or memory types, or figure out that socket X fits CPUs Q and W.
The big problem with the early Athlons was that they would not self-limit when their heatsink failed.
But they fixed that issue at least 5 years ago (all of the Athlon64 parts are self-throttling and will not fry themselves).
It's one of the few mis-steps that AMD made over the years.
The primary reason that we switched to AMD was back when the Athlon64 chips were first released. At the time, 64bit future was hazy. Would it arrive next year? Three years? How soon would we need to have 64bit capable machines? Your choices back then were either Intel's Itanium - which was an absolute dog at running 32bit x86 code, or AMD Athlon64 - which ran 32bit x86 code like a champ and gave you the potential to switch to 64bit later.
So we got the best of both worlds. Good 32bit x86 performance in the near term with future proofing so that we could run 64bit code later. We didn't have to wait around for Intel to release the Core 2 Duo line.