Re:Pretty odd coincidence...
on
Andromeda
·
· Score: 1
I guess I'll point out the obvious: that the characters that are mere background in one episode get much more attention and development in other episodes. BTW, Rev Bem gets a lot less "silly" towards the end of the season...
If someone can recommend an Athlon motherboard that (right now) doesn't use a VIA chipset, can hold a GForce 2, and is available outside the U.S. I would gladly stop buying Intel.
Uhh, actually there are several. Try looking at some of the motherboard articles at Tom's Hardware. The AMD 760 still uses some VIA chips, but the others don't. They just did an article on the newest SiS chipset, which is a single-chip solution. I don't know about availability where you are, but SiS is taiwanese, IIRC, so I would think they would be available outside the US.
Well, other electronics don't necessarily consume as much power within the delicate IC logic. And newer products sometimes have them (case in point: the PS2; it has a fan in the back that produces a rather annoying whine when I'm trying to watch a DVD).
Part of the problem is that most PCs are dumb when it comes to temperature management. PCs usually keep the fans running all the time, whether they're needed or not; by contrast, many embedded and/or consumer electronic applications only turn the fan(s) on when the ambient hits a certain level.
In addition, PC makers put more cooling power in than is strictly necessary, in order to "brute force" the issue in the absence of good thermo-design. This approach is understandable, given the upgradeable/hackable nature of computers. That new GeForce-57 Tera-Hertz GPU may put out just a *wee* bit more heat than the original cheapie OEM your system shipped with.
Oh and don't forget, many consumer electronics manufacturers are perfectly happy to trade an early "heat-death" for a quieter, sexier product. As long as the MTBF is longer than their warranty...
How much difference does removing the metal cutout make? I've been thinking about doing this with mine, but I don't have the tools on hand.
As for sound dampening material, it helps in some situations, but not in others. It's not the same as sound *absorbing* material, so it doesn't really kill things like fan noise very well (in my experience). Of course if you use the good stuff, you wind up with a spiffy chromed-look interior; bonus!
That's fine if you live in New York City, and have lots of options. What if you live in Podunk, Utah, and there's only a couple of ISPs operating locally? If all those ISPs have the same policy, you're SOL. It would cost you a small fortune to use a long distance dailup, and many people simply can't afford that.
BTW, this is about rights & privileges, not profits. Profits == Right is about as logical in this scenario as Might == Right. Don't know about you, but I don't want to go back to the Dark Ages.
Membership is voluntary for the *provider*, not the user. The whole point of this article is that people who wanted to access the Macromedia site were not able to, because their provider routed through Above.net to get there. Membership was thus "dictated" to them by their provider and/or above.net.
(And yes, they could have chosen another provider, *if* they could find one that is totally unaffected by the RBL. That may, however, prove difficult or impossible for some.)
There are data-grade monitors available in ~36" sizes. I haven't looked into them, but they are occasionally discussed in AVSforums. Of course they're at least as expensive as a comparably sized HDTV.
..."How am I supposed to tell how long it will take to fix bugs we don't even know about yet?"
The problem is that you don't know the bug is there until it is exploited. So the question becomes: how do you estimate the number of bugs in a program? There are several rule-of-thumb based on statistics, but those aren't reliable enough to list as a spec.
The basic issue is that hardware manufacturers can test a statistical sample of their product and use those results to estimate MTBF for that product. With software, each program is unique, so it's difficult to say with any certainty that tests done on past software will extrapolate to new software, even if the statistical analysis is sound.
And when a program "breaks" (ie. a flaw is discovered), all copies of that software (or configuration) are affected. If a company buys 1000 copies of the same hardware, they can be confident that, on average, only a certain percentage of that HW will fail before the MTBF point.
With software, does it matter if the average time-to-exploit is high, if *your* current software package is hacked two weeks after installation? All one thousand software copies in the organization are now vulnerable; all have to be fixed/replaced. So that pretty MTTF spec isn't really very useful anymore.
While it's true that most students who share course material know full well how it will be used, this is not always the case. At UVa, part of the whole honor concept is that people can be trusted. Thus, letting other people see your work is not such a big deal, as long as it's not a homework-type assignment with only one right answer.
As for papers: well, it's certainly unusual, but I can think of numerous (quasi-)legit. reasons for wanting to see an old paper that scored well. For instance, different profs can have widely varying ideas of what constitutes good writing, and I don't see anything wrong with trying to learn the teacher's preferences by reading stuff s/he's graded before.
Also, there's always the truly accidental security breach, where you leave a copy of an assignment on a lab computer, or lying on the printer, by mistake. As they say, never attribute to malice that which can be explained by stupidity:-)
Or, just perhaps, because they all went to the library and had a look at the same books, one after another.
The funny thing is, this is plagiarism! If they use enough of the text from the book, whether directly or from memory, to be recognizably the same, then they have plagiarized the book's author(s). (Unless of course they give credit, but then it shouldn't get flagged anyway.) But the public school system basically teaches kids to do this with all their papers, so it's no wonder that people think it's okay.
And now that I've gotten the obligatory link out of the way, here's my experience:
The main problem with an all-in-Won--err,one, solution is that for full functionality, certain things need to happen in the background, even while you're doing something else.
The biggest example I can think of is recording. To get TiVo-like ease of use, the recording program needs to startup and run adequately no matter what else is going on. On my system, the recording function is tied to the main graphics card. If I'm playing a game when it's time to tape Buffy, the recorder tries to take over and usually both programs crash. Even if things were set up better, you'd still have to deal with an inherent bottleneck either in the GPU or the system bus.
Also, don't even think about doing this with your primary system unless you've got an HD-ready set (or better yet a hi-res projector). TV-out through S-Video just doesn't cut it for computer text. In my case, I'm still waiting for an adapter to convert VGA to component (YPbPr); it's on backorder everywhere I've looked.
IMHO, the solution is to make separate components/peripherals that have a standard, computer controlled interface, preferrably with a data bus. Then you can have separate resources for those devices that need them, and share resources between functions that are mutually exclusive (eg. watching a DVD and playing games; both require your full attention).
(Hmm, wait, that sounds like an XBox and a TiVo, doesn't it?;-)
What's being described here is is known as a HTPC: Home Theater PC. People are already building these, although setup and ease of use are still major issues.
For more information on setting up this type of device, go to the AV Science Forum and check out the Home Theater Computers forum.
Would you trust a surgeon to operate on you if he didn't take medicine seriously and only thought of it as his day job? Would you really go under his knife if in
talking to him he said "Well, I cut people open because it pays well. I happen to hate humanity and I just find people disgusting". I sure as hell wouldn't.
I'd have to agree with you there; I wouldn't trust any doctor who said that to me. The good ones are smart enough not to say it out loud;-)
Trans.: "All you enthusiast sites: don't dare give us bad press, or we'll just take our ball and go home. Nyah!"
Seriously, this sounds like a classic passive-aggressive marketing threat. People who want to see competition in the industry will be hesitant to criticize the new platform, lest it be cancelled. So Nintendo gets free PR from all the desperate enthusiasts out there.
I actually like the idea of having an option to pay or watch ads instead. It's flexible, and allows people to visit a site once in a while without having to register *cough*NYT*cough* but still have a way to bypass ads on those sites that they find the most valuable.
One little problem, though: the people with the most disposable income (ie. the best prospects) are people most likely to shell out for the subscription fee. This means that your demographic would quickly go down the toilet.
On another subject, I recently visited a site that had placed several flashing, moving ads *beside* the article. In addition to being annoying, they made it difficult to concentrate on the article, which was what I came for in the first place. I don't even remember what the ads were for, which is worse than with banner ads. Making ads more annoying is definitely not the answer.
Uhh... no. The point is that many gamers don't really have the money to afford their pastime. They may be scrimping and saving (or begging and pleading) to get the $50 required for their next game. They can't afford even $5 extra per month, especially for online content that isn't a necessary cost. These gamers are understandably disappointed when a free resource they've come to depend on suddenly turns commercial; effectively that content is now off-limits to them, which is an even worse feeling than when the content is not there at all.
The failure of your analogy lies in the fact that hammers and nails are more-or-less standard, commodity products. The situation gets more complicated when you (the customer) have 50,000 MHR-R-Us(TM) ten-penny nails in storage, which only MHR-R-Us Brand hammers can drive. This is the current situation with many software products.
No one is saying that the renter has any current legal obligation; what they're saying is that the lack of such an obligation, in the case of software, makes rental a risky proposition at best. Assuming that rental software becomes the standard business model, it might be wise to add some provision to protect consumers against being left with unreadable data and/or unusable equipment.
Think of it this way: so long as the *data* belongs to the customer (which of course exempts PassPort sites;-) the customer's "Intellectual Property" will lose value as a result of no longer being accessible. If my rent-a-shack tool shed is taken away, that's one thing; but if it's taken away with my lawnmower and power tools still in it, that's another thing entirely!
The funny thing is, it's not always the lusers who screw this up...
In my college dorm where we had Ethernet, the IP addresses were supposedly assigned randomly (this was pre-DHCP, some older protocol). When people began using Linux, the IT geniuses started assigning them permanent IPs to use. Well, lo and behold, my friend's PC stops connecting properly. Turns out that the "random" IP generator always assigned the same address to a particular port, even if it was already in use!
My friend called them up and got them to change the IP for the Linux user, but AFAIK the general problem still persisted until the time I graduated. When I switched to Linux later that year, I didn't even bother asking for an IP; I just sniffed out the address I was getting assigned every time, and used that. Never had a single problem with it, either.
(Which just goes to prove that I shouldn't try to do anything right after I get up in the morning. Actually, getting up in the morning is generally a bad idea anyway.)
I can see where some pure CS types might have a problem with this, but anyone who has done any hardware development lately should feel right at home. Most EEs and CpEs have some training on FPGA and RTL design.
The real issue isn't the paradigm so much as the complexity. Getting this many device blocks to work together and do something useful, much less reliable, is rather a herculean task. It's like writing a 50,000 line program in assembly; maybe even worse. The average "script kiddie" isn't going to manage it.
Eventually, though, if this thing was useful enough, it would become popular, and lots more resources would be thrown into abstracting it. Once you had MPHC (Massively-Parallel Hyper-C) in place, things would get a whole lot easier.
Part of the reason that this hasn't happened already with hardware tools is that HW engineers are even more resistent to abstraction than the old-time assembly programmers were (except for the few hold-outs in the embedded world). As long as the size/number of the devices is below a certain level, there's no need to abstract, and plenty of reason not to. As the size and complexity of the design grows, though, at some point the task becomes unmanageable; that's when C-like programs become attractive.
I don't know anything about this company, so I'll have to take your word for it. But I don't think this is as implausible as you make it sound.
I'm assuming that what they're planning is to have a sort of standard library of FPGA loads for different functions, and programmers will write programs by picking the right loads for each device group. This, no doubt, is what that special language is for, so that programmers won't have to understand all the gory details in order to write code for it. Any custom loads that need to be created will be synthesized at compile time; compilation will be slow, but the run-time can be fast.
Admittedly, programming all those individual FPGAs on the fly is a complex and difficult task, but then, I doubt that most programs will be reconfiguring so often in the real world. Their 1000/s number is a maximum, and may not apply when you're trying to program multiple loads into multiple devices.
Except that they would never be able to trust them. It's sort of like hiring the fox to guard the henhouse. Since these guys would be the experts, the industry and its minions would never know for sure that they hadn't secretly sabotaged the project, by intentionally leaving in a subtle flaw or even a well-hidden back door. And since these guys have already shown a willingness to break the industry's crypto systems (and publish it), they might be tempted to do something like this.
Slashdot Mirror
I guess I'll point out the obvious: that the characters that are mere background in one episode get much more attention and development in other episodes. BTW, Rev Bem gets a lot less "silly" towards the end of the season...
How about:
Pentium 3.5?
Celeron 4?
If someone can recommend an Athlon motherboard that (right now) doesn't use a VIA chipset, can hold a GForce 2, and is available outside the U.S. I would gladly stop buying Intel.
Uhh, actually there are several. Try looking at some of the motherboard articles at Tom's Hardware. The AMD 760 still uses some VIA chips, but the others don't. They just did an article on the newest SiS chipset, which is a single-chip solution. I don't know about availability where you are, but SiS is taiwanese, IIRC, so I would think they would be available outside the US.
Well, other electronics don't necessarily consume as much power within the delicate IC logic. And newer products sometimes have them (case in point: the PS2; it has a fan in the back that produces a rather annoying whine when I'm trying to watch a DVD).
Part of the problem is that most PCs are dumb when it comes to temperature management. PCs usually keep the fans running all the time, whether they're needed or not; by contrast, many embedded and/or consumer electronic applications only turn the fan(s) on when the ambient hits a certain level.
In addition, PC makers put more cooling power in than is strictly necessary, in order to "brute force" the issue in the absence of good thermo-design. This approach is understandable, given the upgradeable/hackable nature of computers. That new GeForce-57 Tera-Hertz GPU may put out just a *wee* bit more heat than the original cheapie OEM your system shipped with.
Oh and don't forget, many consumer electronics manufacturers are perfectly happy to trade an early "heat-death" for a quieter, sexier product. As long as the MTBF is longer than their warranty...
How much difference does removing the metal cutout make? I've been thinking about doing this with mine, but I don't have the tools on hand.
As for sound dampening material, it helps in some situations, but not in others. It's not the same as sound *absorbing* material, so it doesn't really kill things like fan noise very well (in my experience). Of course if you use the good stuff, you wind up with a spiffy chromed-look interior; bonus!
That's fine if you live in New York City, and have lots of options. What if you live in Podunk, Utah, and there's only a couple of ISPs operating locally? If all those ISPs have the same policy, you're SOL. It would cost you a small fortune to use a long distance dailup, and many people simply can't afford that.
BTW, this is about rights & privileges, not profits. Profits == Right is about as logical in this scenario as Might == Right. Don't know about you, but I don't want to go back to the Dark Ages.
Membership is voluntary for the *provider*, not the user. The whole point of this article is that people who wanted to access the Macromedia site were not able to, because their provider routed through Above.net to get there. Membership was thus "dictated" to them by their provider and/or above.net.
(And yes, they could have chosen another provider, *if* they could find one that is totally unaffected by the RBL. That may, however, prove difficult or impossible for some.)
There are data-grade monitors available in ~36" sizes. I haven't looked into them, but they are occasionally discussed in AVSforums. Of course they're at least as expensive as a comparably sized HDTV.
..."How am I supposed to tell how long it will take to fix bugs we don't even know about yet?"
The problem is that you don't know the bug is there until it is exploited. So the question becomes: how do you estimate the number of bugs in a program? There are several rule-of-thumb based on statistics, but those aren't reliable enough to list as a spec.
The basic issue is that hardware manufacturers can test a statistical sample of their product and use those results to estimate MTBF for that product. With software, each program is unique, so it's difficult to say with any certainty that tests done on past software will extrapolate to new software, even if the statistical analysis is sound.
And when a program "breaks" (ie. a flaw is discovered), all copies of that software (or configuration) are affected. If a company buys 1000 copies of the same hardware, they can be confident that, on average, only a certain percentage of that HW will fail before the MTBF point.
With software, does it matter if the average time-to-exploit is high, if *your* current software package is hacked two weeks after installation? All one thousand software copies in the organization are now vulnerable; all have to be fixed/replaced. So that pretty MTTF spec isn't really very useful anymore.
While it's true that most students who share course material know full well how it will be used, this is not always the case. At UVa, part of the whole honor concept is that people can be trusted. Thus, letting other people see your work is not such a big deal, as long as it's not a homework-type assignment with only one right answer.
:-)
As for papers: well, it's certainly unusual, but I can think of numerous (quasi-)legit. reasons for wanting to see an old paper that scored well. For instance, different profs can have widely varying ideas of what constitutes good writing, and I don't see anything wrong with trying to learn the teacher's preferences by reading stuff s/he's graded before.
Also, there's always the truly accidental security breach, where you leave a copy of an assignment on a lab computer, or lying on the printer, by mistake. As they say, never attribute to malice that which can be explained by stupidity
Two words: grading curve.
Or, just perhaps, because they all went to the library and had a look at the same books, one after another.
The funny thing is, this is plagiarism! If they use enough of the text from the book, whether directly or from memory, to be recognizably the same, then they have plagiarized the book's author(s). (Unless of course they give credit, but then it shouldn't get flagged anyway.) But the public school system basically teaches kids to do this with all their papers, so it's no wonder that people think it's okay.
And now that I've gotten the obligatory link out of the way, here's my experience:
;-)
The main problem with an all-in-Won--err,one, solution is that for full functionality, certain things need to happen in the background, even while you're doing something else.
The biggest example I can think of is recording. To get TiVo-like ease of use, the recording program needs to startup and run adequately no matter what else is going on. On my system, the recording function is tied to the main graphics card. If I'm playing a game when it's time to tape Buffy, the recorder tries to take over and usually both programs crash. Even if things were set up better, you'd still have to deal with an inherent bottleneck either in the GPU or the system bus.
Also, don't even think about doing this with your primary system unless you've got an HD-ready set (or better yet a hi-res projector). TV-out through S-Video just doesn't cut it for computer text. In my case, I'm still waiting for an adapter to convert VGA to component (YPbPr); it's on backorder everywhere I've looked.
IMHO, the solution is to make separate components/peripherals that have a standard, computer controlled interface, preferrably with a data bus. Then you can have separate resources for those devices that need them, and share resources between functions that are mutually exclusive (eg. watching a DVD and playing games; both require your full attention).
(Hmm, wait, that sounds like an XBox and a TiVo, doesn't it?
What's being described here is is known as a HTPC: Home Theater PC. People are already building these, although setup and ease of use are still major issues.
For more information on setting up this type of device, go to the AV Science Forum and check out the Home Theater Computers forum.
I'd have to agree with you there; I wouldn't trust any doctor who said that to me. The good ones are smart enough not to say it out loud ;-)
Trans.: "All you enthusiast sites: don't dare give us bad press, or we'll just take our ball and go home. Nyah!"
Seriously, this sounds like a classic passive-aggressive marketing threat. People who want to see competition in the industry will be hesitant to criticize the new platform, lest it be cancelled. So Nintendo gets free PR from all the desperate enthusiasts out there.
(Boy I'm cynical/paranoid, aren't I?)
Or the Foundation series for that matter (specifically the Imperial capital; very similar idea, no?)
I actually like the idea of having an option to pay or watch ads instead. It's flexible, and allows people to visit a site once in a while without having to register *cough*NYT*cough* but still have a way to bypass ads on those sites that they find the most valuable.
One little problem, though: the people with the most disposable income (ie. the best prospects) are people most likely to shell out for the subscription fee. This means that your demographic would quickly go down the toilet.
On another subject, I recently visited a site that had placed several flashing, moving ads *beside* the article. In addition to being annoying, they made it difficult to concentrate on the article, which was what I came for in the first place. I don't even remember what the ads were for, which is worse than with banner ads. Making ads more annoying is definitely not the answer.
Uhh... no. The point is that many gamers don't really have the money to afford their pastime. They may be scrimping and saving (or begging and pleading) to get the $50 required for their next game. They can't afford even $5 extra per month, especially for online content that isn't a necessary cost. These gamers are understandably disappointed when a free resource they've come to depend on suddenly turns commercial; effectively that content is now off-limits to them, which is an even worse feeling than when the content is not there at all.
The failure of your analogy lies in the fact that hammers and nails are more-or-less standard, commodity products. The situation gets more complicated when you (the customer) have 50,000 MHR-R-Us(TM) ten-penny nails in storage, which only MHR-R-Us Brand hammers can drive. This is the current situation with many software products.
;-) the customer's "Intellectual Property" will lose value as a result of no longer being accessible. If my rent-a-shack tool shed is taken away, that's one thing; but if it's taken away with my lawnmower and power tools still in it, that's another thing entirely!
No one is saying that the renter has any current legal obligation; what they're saying is that the lack of such an obligation, in the case of software, makes rental a risky proposition at best. Assuming that rental software becomes the standard business model, it might be wise to add some provision to protect consumers against being left with unreadable data and/or unusable equipment.
Think of it this way: so long as the *data* belongs to the customer (which of course exempts PassPort sites
The funny thing is, it's not always the lusers who screw this up...
In my college dorm where we had Ethernet, the IP addresses were supposedly assigned randomly (this was pre-DHCP, some older protocol). When people began using Linux, the IT geniuses started assigning them permanent IPs to use. Well, lo and behold, my friend's PC stops connecting properly. Turns out that the "random" IP generator always assigned the same address to a particular port, even if it was already in use!
My friend called them up and got them to change the IP for the Linux user, but AFAIK the general problem still persisted until the time I graduated. When I switched to Linux later that year, I didn't even bother asking for an IP; I just sniffed out the address I was getting assigned every time, and used that. Never had a single problem with it, either.
Even worse: I accidentally did this to myself!
(Which just goes to prove that I shouldn't try to do anything right after I get up in the morning. Actually, getting up in the morning is generally a bad idea anyway.)
Programming FPGAs *is* different, but...
I can see where some pure CS types might have a problem with this, but anyone who has done any hardware development lately should feel right at home. Most EEs and CpEs have some training on FPGA and RTL design.
The real issue isn't the paradigm so much as the complexity. Getting this many device blocks to work together and do something useful, much less reliable, is rather a herculean task. It's like writing a 50,000 line program in assembly; maybe even worse. The average "script kiddie" isn't going to manage it.
Eventually, though, if this thing was useful enough, it would become popular, and lots more resources would be thrown into abstracting it. Once you had MPHC (Massively-Parallel Hyper-C) in place, things would get a whole lot easier.
Part of the reason that this hasn't happened already with hardware tools is that HW engineers are even more resistent to abstraction than the old-time assembly programmers were (except for the few hold-outs in the embedded world). As long as the size/number of the devices is below a certain level, there's no need to abstract, and plenty of reason not to. As the size and complexity of the design grows, though, at some point the task becomes unmanageable; that's when C-like programs become attractive.
I don't know anything about this company, so I'll have to take your word for it. But I don't think this is as implausible as you make it sound.
I'm assuming that what they're planning is to have a sort of standard library of FPGA loads for different functions, and programmers will write programs by picking the right loads for each device group. This, no doubt, is what that special language is for, so that programmers won't have to understand all the gory details in order to write code for it. Any custom loads that need to be created will be synthesized at compile time; compilation will be slow, but the run-time can be fast.
Admittedly, programming all those individual FPGAs on the fly is a complex and difficult task, but then, I doubt that most programs will be reconfiguring so often in the real world. Their 1000/s number is a maximum, and may not apply when you're trying to program multiple loads into multiple devices.
Except that they would never be able to trust them. It's sort of like hiring the fox to guard the henhouse. Since these guys would be the experts, the industry and its minions would never know for sure that they hadn't secretly sabotaged the project, by intentionally leaving in a subtle flaw or even a well-hidden back door. And since these guys have already shown a willingness to break the industry's crypto systems (and publish it), they might be tempted to do something like this.