Since "computer literate" is just a nicer way of saying "speaks computer", it seems reasonable that we approach the problem the same way we approach literacy in natural languages. Children learn to speak by watching, emulating, screwing up, and getting corrected. Eventually they pick up patterns and learn to apply them in novel situations. This is the way most/. readers became computer geeks. We watched (or perhaps read in a manual), emulated, screwed up, and got spanked by the computer dutifully deleting everything we told it to. Eventually we figured things out.
This is not the way most people approach computers. And it shows.
I'm sick of car analogies, so I'm going to try a new one. Bear with me. A computer is like a wood shop. If you go in and play with the various pieces, you'll hit the chisel with the hammer wrong and it'll bounce and cut you. You'll probably cut yourself on a saw or two also. And that birdhouse you're trying to make? Crap. But you'll learn something. If, instead, you go into the wood shop because someone told you there's a hammer in there, and you can use it to pound nails, you'll never even see the mitre box.
I guess that kind of works.
Too bad learning language takes hours a day, for a year or so.
Someone who can't differentiate between an exle, differential, and brake pad is not "car literate". (S)He may be able to drive, and if that's all the person requires, there's no shame in it. The problem with a term like "computer literacy" is precisely that it means different things to different people. I think "computer literate" is a rather broad term, so requiring a rather broad set of skills before you can apply it does not seem unreasonable to me.
Obviously requiring that level of computer literacy before allowing someone to use a computer is completely unreasonable and hugely inefficient. On the other hand, letting someone who can't distinguish between email and a web page loose with an admin account on a Windows box is a horrible idea too. It just happens to be a more accepted form of stupidity. As you say, anything else would be unreasonable. But the current situation is untenable and is only getting worse, so something's got to give.
Unfortunately, user education doesn't look to be working. And the ignorant aren't going to stop buying computers: they're just too convenient and attractive. So the only thing I see as having the faintest chance of improving the situation is better software. Writing secure, functional, efficient, attractive software isn't hard. It's not some deep mystical science. But doing it in a time frame and budget such that it can effectively compete in the marketplace with glittery, insecure, buggy software is proving harder than it should be.
In my experience, after a few machines with malware preinstalled, people start to realize that something is wrong, and maybe it's their choice of vendor. Macs are starting to look better and better to a lot of people, and while it's a false panacea, it does indicate that more and more focus is being put on system quality (both hardware AND software), and less and less on raw speed. Before you whip out your story of how you legitimately need the fastest money can buy, remember that we're talking primarily about home and office use, where doubling the system's RAM is way more important than doubling its CPU clock, and much cheaper too. The widening gulf between the average user's actual hardware requirements and what a modern computer can provide is not something even a nasty malware load can hide, and users are starting to realize that they're upgrading their hardware to fix software problems. The second time that happens, they start figuring out that maybe it's worth paying a bit extra to try to get better software in the first place.
And, if you can, some attitude adjustment. It's good that you've got these kids at the freshman level. It's even better if this is an elective rather than a required course, but obviously that's not something you'll have much control over. The only writing class required for my engineering major was a senior course where not-failure was the main goal of most of the students there. I assume they all passed, but I would have failed several of them. Most of the students I talked to didn't have much respect for the class and thus didn't try, but I'd estimate about 10% of them really couldn't write good prose without considerable outside help, even if they were motivated to do so.
You've said you're not looking to be told to teach grammar. Fair enough. I still think you should stress it though. Without good grammar, it's hard to build good sentences, and without good sentences it's hard to build good paragraphs. Engineering type students probably don't need a whole lot of practice stringing together a good long-form response to something, partly because a series of good paragraphs, even if they're not well-connected, would usually get the point across, but mostly because if my classes were any indication, the students won't get the basics down in a semester anyway so there's little point worrying about higher-level issues.
For engineering, logical argument progression and other rhetorical skills are going to be important, but the students are probably stronger in that area than they are in basic English mechanics anyway. Again, drawing on my own experience working on a team project for class, there's considerable need for practice crafting good sentences. Clear, concise, unambiguous sentences that further some goal. As our team's editor, I saw copious amounts of butchered verbiage, but it tended to follow the standard essay format. The problems were that individual sentences needed two or more readings to clarify, and some resisted my best efforts entirely.
You can fix some of these errors through rote application of rules, but ultimately it comes down to practice. Find or write a short manual with the most common errors explained (with multiple examples for each), and have everyone write. A lot. I'm not clear on how focused the course is on writing rather than the semester's topic, but by college it's going to be very difficult to introduce the students to enough well-written prose to teach them by osmosis; they'll need to spend a lot of time writing. And tell them to read what they've written out loud. It sounds dumb, and it's hard to do in a college setting in a way that's comfortable for the student, but if you stress it enough at least some of the kids will give it a try. Writing the way you talk is a bad idea, but even so, reading what you've written makes quite a few errors more visible.
This is getting long, so I'll sign off. Good luck; keep at it; engineering needs the help.
The summary has two extra commas. The first is just after a noun phrase; the second is just before one.
I've been taking Spanish for quite a while, and recognize common English errors that native speakers of Spanish make, but I'm curious about the comma overuse in the summary here. I have come across this particular error quite a bit lately, and I'm curious whether it's common to native speakers of a particular language.
I know this is seriously OT, but I don't know of any linguist blogs, so can someone help me out here? Thanks!
Yes. This is a specific application of secret-sharing algorithms.
In the classic formulation, the secret is split into N parts, such that no part reveals any information about the secret (that is, knowing one of the parts does not make any possible secret more likely than any other possible secret). The really cool thing is that you can decide that's not good enough, and can split up your secret such that knowing M or fewer parts reveals no information about the secret (for sufficiently large N). Normally you could use a mechanism such as this to secure something like nuclear launch codes: no two people (captian and first mate?) can conspire to reveal the secret, but if three or more conspire (== agree that nuclear launch is warranted), they can combine their information and recreate the secret launch codes.
The data storage application reverses the original purpose of secret sharing. Rather than trying to resist conspiracy (keeping M large), distributed backup usage is trying to reduce the effects of data loss (keeping N-M comfortably large. RAID5, in a sense, has N-M=1; RAID6 has N-M=2, etc.) by permitting "conspiracy" of a subset of the original parts to restore the original information. Essentially, this is a somewhat more computationally intensive way of dividing up data, but has the great advantage that it can easily adapt to different desired amounts of redundancy and different numbers of physical data storage targets.
Note: this is based on some math I had in college, not a reading of the ACM article.
Actually, it will have an average latency of 4.16ms. At 7200rpm, the platter rotates once every 8.33ms; on average the data you're looking for will be half a rotation away, or 4.16ms. There will also be seek time, varying from about 1ms for track-to-track seeks, to perhaps 20ms, depending on acoustic management settings and other things. So gripe about the photo containing poorly-chosen specs if you want, but please don't complain that there's something wrong when the spec lists average latency, and tells you what the average latency is.
As for your comment on transfer rate, it too is clear, precise, and accurate. The maximum external transfer rate is as listed. If you want to know the maximum media transfer rate, Seagate will tell you that too. By convention it's expressed in megabits rather than megabytes, but it'll be listed. Usually maximum sustained transfer rate isn't listed as a specification, but it's readily findable if you want to know, and it's nearly irrelevant anyway. If you're curious, it'll be about 80-90MB/sec.
It's all about branding. You can create these criteria, group people based on them, and label a group "intellectually curious", but doing so makes you a nerd. Since the point seems to be to get beyond the "nerd" label, we can't be creating an un-cool label to replace it, especially when it's longer, more complicated, and not generally understood.
I propose "sci-curious". Short, chic, descriptive. Of course, it doesn't cover the politics geeks, but they'll just have to get their own term.
Please read before you post. You don't even need to read the article: the submittor ripped off the relevant article text for the summary.
Dell's not taking credit for 64-bit ISA extensions to x86. They're taking credit for forcing Intel to add them to their Pentium and Xeon lines rather than reserve 64 bit goodness for the doomed Itanium line. The point is that, rather than mutely accept the scraps Microsoft and Intel throw their way, Dell has the clout and the will to push Intel around.
I would agree with your assertion that more subdomains should be used, and that movies are a particularly obvious and egregious example. The switch from moviename.TLD to movienameTHEMOVIE.TLD is an early sign that even those with deep pockets are feeling the crunch. One solution would be moviename.movies.TLD, but of course everyone would object to whoever owns.movies.TLD. Which doesn't affect any studio with the balls to just use moviename.studioname.TLD
Unfortunately, your (and my) opinion that more subdomains should be used is just a consequence of the way the internet's run. Consumers are conditioned to expect blah.TLD as a domain name and to be distrustful of long names (with some justification). Having made the conceptual leap that not all domains ending in.com are safe, and recognizing that longer names are more likely to be, in some poorly-understood way, "bad", it's going to be difficult to get people to accept the logical extension of subdomains: buzzlightyear.actionfigures.merchandise.movies.dis ney.com
Ultimately, the problem is one of control, whether that's self-control or regulatory control. Every time a new TLD opens up, there's the same rush to buy the same domains with another TLD. Why are there country code TLDs? Well, because the USA dominated the early internet and claimed all of.gov for itself. Any rational organization would have put all national governments under.gov, so you'd see navy.mil.us.gov on the same footing as raf.mil.uk.gov. As we've seen, the early lack of foresight in claiming.gov for the USA has resulted in hundreds of country code TLDs, which has benefited countries whose code happens to have some use to foreigners (.tv, for example), but is a net loss in terms of overall rationality.
The namespace has been so poorly managed in the past that it's difficult to exert the necessary control to maintain order. The only positive outcome of that is that there's a reluctance to change, allowing us to become reasonably comfortable with the status quo. Earlier in the internet's development, a different approach to TLDs would have helped whereas today it can only waste more money. Fortunately, if the limited number of TLDs remains small, the overall anarchy can be masked by tighter local control. For an example of that, see the.us domain. Consider the URL for my local library system: www.scls.lib.wi.us. The South Central Library System is a library entity in Wisconsin, which is in the US. Or my home county's webpage: www.co.dane.wi.us. Other than having the CO and DANE in the wrong order, it's the model of rationality. If we can keep the number of TLDs down we will allow such islands of order to exist where they can still be reasonably found.
It's fairly clear that increasing the number of TLDs only marginally increases the number of websites. Most of the.eu domains will end up being the same as existing.com domains. In turn, most of these will in fact be the same page as the.com domains, with a few being owned by the same company and presenting substantially the same information with a more locally-appropriate flavor. Only a few will be completely separate (say, two small companies with the same name in geographically diverse areas). In other words, there is little need for something like a.eu TLD. Most of the blah.eu domains would more properly be served by eu.blah.TLD instead, and the primary result of the existence of.eu is to funnel money into the coffers of those involved in setting up and running the TLD, without creating commensurate value.
I hope that increased reliance on search engines to find desired content will diminish the perceived value of a domain name, with the result that branding and marketing will have less input in the choice of naming, thus hopefully leading to gradually more hierarchical namespaces. At best, that's a long-term goal, and I'm sure it will be preceeded by smaller-scale campaigns to standardize and/or rationalize naming within individiual entities. One example of this would be the namespaces Apple uses internal to OS X.
Yeah, Three Gorges has its (major) problems. But to say it should never have been built is a luxury you have because of living in a country fairly well-provisioned for its future energy needs. As these things go.
China's projecting enormous increased demand, and there's no good way to get the energy.
They can bet on coal, which China actually has quite a lot of (though not so much on a per-capita basis), but it's something of an environmental disaster even if it's burned cleanly. They can bet on nuclear, which presents waste storage problems and relies on finite supplies of fissionable material. They can bet on wind (not sure of the viability of that, but I'm sure at least SOMEWHERE in China there's good wind), but it takes up a lot of area and apparently isn't so good for birds. They can bet on solar, which is even worse in terms of taking up space, and is expensive, and only works for half the day. They can bet on hydroelectric, which displaces people, permanently changes the river, and nukes a whole lot of land. And that enormous lake is going to affect the weather.
There are other options too, of course. And the best solution is a mix of many different technologies. Etc. But the fact is that there's no good solution. China bit the bullet and picked what they hope is the least-bad choice. It had to be done.
What are you talking about? U/320 SCSI is 320 megabytes per second. Not bits. In a regular PCI slot on an unloaded bus, a U/320 HBA is limited to 90-110MB/sec, but with PCI-X or PCIe that limitation is removed, and single HBAs can readily sustain 500+MB/sec sequential reads from arrays spanning multiple SCSI channels.
Of course, in many applications, latency of varying sorts quickly chews that number down to something a bit more sane.
If you're limited to a hard 20MB/sec over SCSI, the first thing I would suggest is to make sure that you're actually operating at U/320 speeds, and your HBA and drive(s) haven't fallen back to one of the SE modes for some reason (faulty connection, crummy cable, missing / buggy / broken / wrong terminator, etc).
"Sugar, for example, doesn't melt, buit decomposes into water and carbon when heated, so it can't be a frozen liquid."
I have candy says otherwise.
Sure, sucrose eventually decomposes into carbon, hydrogen, and oxygen. But then so does pretty much every other organic compound, given sufficient heat.
The egalitarian aspect of saving Disney is illegal, sure. But saving Disney should Increase Shareholder Value(tm), which makes everything OK. Similarly, there's reason enough to believe that the merger could increase shareholder value, even if Jobs' ultimate goal is to cash out, that it'd be legal.
Besides which of course, the SEC apparently considers it kosher...
Whoops, you're right - I plugged the wrong numbers in. 50% Pixar -> 7% Disney is correct. Yes, the new company should have the combined market cap of both (assuming investors consider the new company to be worth the sum of the values of its parts), so it's actually slightly less than that (about 6.15%)
Jobs doesn't make $3.5bn
on
Disney Buys Pixar
·
· Score: 4, Interesting
This deal doesn't make Jobs $3.5bn, as the article claims. It barely makes him any money at all.
Pixar's market cap is just a hair under $7bn, about half of which Jobs owns. Disney is buying all $7bn worth of Pixar stock with $7bn worth of Disney stock. So Jobs isn't making any money, he's just changing the name on part of his stock portfolio (Disney's buy is a bit above market value for Pixar, so he does make SOME money, on the order of 1% of the $3.5bn the article mentions). He's also going from being a 50% owner of a $7bn company to a 14% owner of a $50bn company.
So maybe Jobs thinks he can get in and infect Disney with Pixarness and save it. Maybe he just wants to cash out and do something else, and figures he can sell 14% of Disney a lot easier than he can sell half of Pixer. Could be he thinks Pixar will do better with Disney behind it than with Disney as an enemy. Possibly there's another explanation. Let the speculation continue - we'll know in a few years what the plan was and whether it worked or not.
You've run xbench and it consumes more than about 300MB of RAM? What about quicktime dealing with a 50MB movie? And iTunes - we all know that sucker benefits from having 4GB of RAM to play with.
The quicktime test is streaming - it will be bound by CPU and memory performance. Ditto CD ripping. Ditto Xbench, except for the graphics-bound tests there. I'm not familiar with photoshop, so that might have wanted a bit more memory to work on a 50MB file, but the actual tests run should all be CPU bound as well. After all, that's the whole point of the article - to see what difference the change in CPU / chipset makes.
Would I rather have seen the new imac with a gig of RAM? Sure. But I'd be surprised if it made more than a 5-10% difference in any one test, or more than 2-3% overall. The benchmarks being run just aren't memory-hungry enough.
That would depend on the working set size for the given app.
512MB may be slightly cramping the style of the new imac, but it didn't look like any of Ars' benchmarks would need much more than that. Certainly 4.5GB isn't going to make any difference, and if you've been following Ars' articles, you'd know why that particular machine is so loaded. The CPU-bound, disk-bound, or graphics-bound benchmarks aren't going to notice the change in RAM amount. The photoshop test, being done on a fairly large image, might have seen some impact from the difference in available memory.
Given how heterogenous the systems are already, I'm not too concerned with a slight difference in memory size. Given the different instruction sets, execution hardware, cache layout, and memory controller, I think having only 512MB rather than a gig is unlikely to show up in the benchmarks or in most users' usage.
Not that anyone expected anything different. To be fair, nobody's completely honest with benchmarks, but Apple's among the worst offenders. That said, the Intelmacs are only hideously slow in comparison to the PPCmacs on CPU-bound emulated code, which is to be expected, and is the case with the best chance for improvement in the future. And they actually manage to win a few of the benchmarks, which is nice.
I'd like to see linux running on the new machines. OSX is going to be slow on X86 if for no other reason than the Apple programmers aren't used to the architecture yet. Linux should be a lot closer to best-case speed, so it would be useful to see approximately how much faster OSX can get on the same hardware. I'm not a compiler guy, but my understanding was that GCC still has improvements to be made with regard to newer CPUs and multicore CPUs which should help OSX on Intelmacs as well.
Based on my completely unsubstantiated memory of the M68K -> PPC switchover, Apple's learned some things. It looks like this processor switch is going to go a lot more smoothly than the last one did, which can only mean good things.
I think the decision in the case where an article is submitted by two different people is simple - pick the submittor whose name will cause the least trouble. I presume this isn't what's keeping you up at night, but rather a unique submission by someone who's going to get flamed, so I'll talk about that case.
Actually, I think you had the right solution earlier - the nofollow. Sure, you want to encourage submission of interesting tidbits, and currently there are several kickbacks for doing so: egoboo and google juice being the big ones. I suspect the google juice aspect encourages submission patterns that are ultimately harmful. Altruism and egoboo are probably enough justification for most folks to submit links, and are conveniently nonmonetary. Google juice, on the other hand, is fairly easy to monetize, which tends to bring out the worst in people.
So just add a nofollow. The submittor still gets traffic from the story submission, gets his or her 25 minutes of fame, and has bragging rights for as long as the accepted submission stays in the user profile. There aren't any nofollows in.sig links, so the submittor can get back the google juice by contributing good comments to the discussion, which is one of the big reasons you're conflicted about disliked submittors in the first place.
I know you'd rather live in a world where the messenger doesn't attract attention, but since that world doesn't exist you'll have to attack the problem a different way, and the best way that I can come up with is to discourage the sorts of submittors who cause problems. Hopefully this can be done without materially affecting the overall quality of submissions, which I believe can be accomplished. So run an experiment, and get back to us in a month or two with the results - worst case you'll have to take the nofollow code back out.
You don't need much hardware at all to handle hundreds of requests per second with apache (unless you're doing uncached database queries or other braindead things with scripts).
If this kid can get that many strangers to load up the server that hard for enough hours that the school administrators took notice (in my experience, this can take days), call someone in to poke around, and for him/her to notice what's going on, the school's already out of its league.
The article's a bit thin on details, but it looks like the message wasn't "going here and pressing F5 a lot will slow down my school's computer" (which is informative, and strictly legal) but rather an inducement to commit a crime (possibly - it'd be hard to prove intent to do harm on the part of the folks that actually helped DDOS the machine), which is itself illegal.
So, we have a kid doing something dumb, amusing, actually sort of impressive, and possibly illegal. Yep, sounds like high school.
It's got a four and a quarter gigahertz dual-core Pentium in it. Overclocked like that, the Pentium can probably keep up with a fast Athlon.
There don't seem to be benchmark results anywhere, but if Tom (yeah, I know) is anywhere near right, Intel and Nvidia would have to have gotten a lot of optimization done to make this anywhere near useful. And I mean that in the loosest sense of the term: faster with 4 GPUs than with 2.
Also, you need to be playing games at 1600x1200 or higher resolution, with all the eye candy turned up, to notice a difference. This isn't so much an issue of having a fast enough CPU to keep up. It's really more about piling on enough pointless eye candy to slow the GPUs down to a speed the CPU can handle.
Discussions with friends in the strange countries or for with people of other cultures after the coincidence speak, profit from this kind of the technology. Everything does not remove technical will suffers terriblly and straight under untranslated words (as a everyone, which read at all, the Japanese, Korean or even German small article report places of assembly know).
(This post courtesy of English -> German -> English translation. The first sentence is actually pretty close to what I wrote. The second, ah, not so much.)
Specifically, Mercury's day is 58.65 earth days long, while its year is 87.97 earth days long (source: NASA JPL).
From the same source, we see that Mercury's minimum temperature is about 100K (comfortably colder than liquid nitrogen). Obviously that would occur on the currently-dark side of the planet. So while there's no permanently-dark side of Mercury, there's certainly a cold dark part of mercury somewhere at any given point in time, and that coldest part is only about 50K away from Pluto's temp (presumably an average).
Moral of the story: computers wouldn't like the cold on Pluto, but they wouldn't like the 700K highs on Mercury either. Also, as a wise man once said, "It's funny. Laugh."
Slashdot Mirror
> I thought there were a lot of other more compelling reasons?
There were. But it turns out they're hard. So they're not there anymore.
Vista is the gutted husk of Longhorn: only the pretty new skin remains.
Amen.
/. readers became computer geeks. We watched (or perhaps read in a manual), emulated, screwed up, and got spanked by the computer dutifully deleting everything we told it to. Eventually we figured things out.
Since "computer literate" is just a nicer way of saying "speaks computer", it seems reasonable that we approach the problem the same way we approach literacy in natural languages. Children learn to speak by watching, emulating, screwing up, and getting corrected. Eventually they pick up patterns and learn to apply them in novel situations. This is the way most
This is not the way most people approach computers. And it shows.
I'm sick of car analogies, so I'm going to try a new one. Bear with me. A computer is like a wood shop. If you go in and play with the various pieces, you'll hit the chisel with the hammer wrong and it'll bounce and cut you. You'll probably cut yourself on a saw or two also. And that birdhouse you're trying to make? Crap. But you'll learn something. If, instead, you go into the wood shop because someone told you there's a hammer in there, and you can use it to pound nails, you'll never even see the mitre box.
I guess that kind of works.
Too bad learning language takes hours a day, for a year or so.
Someone who can't differentiate between an exle, differential, and brake pad is not "car literate". (S)He may be able to drive, and if that's all the person requires, there's no shame in it. The problem with a term like "computer literacy" is precisely that it means different things to different people. I think "computer literate" is a rather broad term, so requiring a rather broad set of skills before you can apply it does not seem unreasonable to me.
Obviously requiring that level of computer literacy before allowing someone to use a computer is completely unreasonable and hugely inefficient. On the other hand, letting someone who can't distinguish between email and a web page loose with an admin account on a Windows box is a horrible idea too. It just happens to be a more accepted form of stupidity. As you say, anything else would be unreasonable. But the current situation is untenable and is only getting worse, so something's got to give.
Unfortunately, user education doesn't look to be working. And the ignorant aren't going to stop buying computers: they're just too convenient and attractive. So the only thing I see as having the faintest chance of improving the situation is better software. Writing secure, functional, efficient, attractive software isn't hard. It's not some deep mystical science. But doing it in a time frame and budget such that it can effectively compete in the marketplace with glittery, insecure, buggy software is proving harder than it should be.
In my experience, after a few machines with malware preinstalled, people start to realize that something is wrong, and maybe it's their choice of vendor. Macs are starting to look better and better to a lot of people, and while it's a false panacea, it does indicate that more and more focus is being put on system quality (both hardware AND software), and less and less on raw speed. Before you whip out your story of how you legitimately need the fastest money can buy, remember that we're talking primarily about home and office use, where doubling the system's RAM is way more important than doubling its CPU clock, and much cheaper too. The widening gulf between the average user's actual hardware requirements and what a modern computer can provide is not something even a nasty malware load can hide, and users are starting to realize that they're upgrading their hardware to fix software problems. The second time that happens, they start figuring out that maybe it's worth paying a bit extra to try to get better software in the first place.
Baby steps.
As well you should!
"Sequel cookbook"? Yeah, that's appetizing.
And, if you can, some attitude adjustment. It's good that you've got these kids at the freshman level. It's even better if this is an elective rather than a required course, but obviously that's not something you'll have much control over. The only writing class required for my engineering major was a senior course where not-failure was the main goal of most of the students there. I assume they all passed, but I would have failed several of them. Most of the students I talked to didn't have much respect for the class and thus didn't try, but I'd estimate about 10% of them really couldn't write good prose without considerable outside help, even if they were motivated to do so.
You've said you're not looking to be told to teach grammar. Fair enough. I still think you should stress it though. Without good grammar, it's hard to build good sentences, and without good sentences it's hard to build good paragraphs. Engineering type students probably don't need a whole lot of practice stringing together a good long-form response to something, partly because a series of good paragraphs, even if they're not well-connected, would usually get the point across, but mostly because if my classes were any indication, the students won't get the basics down in a semester anyway so there's little point worrying about higher-level issues.
For engineering, logical argument progression and other rhetorical skills are going to be important, but the students are probably stronger in that area than they are in basic English mechanics anyway. Again, drawing on my own experience working on a team project for class, there's considerable need for practice crafting good sentences. Clear, concise, unambiguous sentences that further some goal. As our team's editor, I saw copious amounts of butchered verbiage, but it tended to follow the standard essay format. The problems were that individual sentences needed two or more readings to clarify, and some resisted my best efforts entirely.
You can fix some of these errors through rote application of rules, but ultimately it comes down to practice. Find or write a short manual with the most common errors explained (with multiple examples for each), and have everyone write. A lot. I'm not clear on how focused the course is on writing rather than the semester's topic, but by college it's going to be very difficult to introduce the students to enough well-written prose to teach them by osmosis; they'll need to spend a lot of time writing. And tell them to read what they've written out loud. It sounds dumb, and it's hard to do in a college setting in a way that's comfortable for the student, but if you stress it enough at least some of the kids will give it a try. Writing the way you talk is a bad idea, but even so, reading what you've written makes quite a few errors more visible.
This is getting long, so I'll sign off. Good luck; keep at it; engineering needs the help.
The summary has two extra commas. The first is just after a noun phrase; the second is just before one.
I've been taking Spanish for quite a while, and recognize common English errors that native speakers of Spanish make, but I'm curious about the comma overuse in the summary here. I have come across this particular error quite a bit lately, and I'm curious whether it's common to native speakers of a particular language.
I know this is seriously OT, but I don't know of any linguist blogs, so can someone help me out here? Thanks!
Yes. This is a specific application of secret-sharing algorithms.
In the classic formulation, the secret is split into N parts, such that no part reveals any information about the secret (that is, knowing one of the parts does not make any possible secret more likely than any other possible secret). The really cool thing is that you can decide that's not good enough, and can split up your secret such that knowing M or fewer parts reveals no information about the secret (for sufficiently large N). Normally you could use a mechanism such as this to secure something like nuclear launch codes: no two people (captian and first mate?) can conspire to reveal the secret, but if three or more conspire (== agree that nuclear launch is warranted), they can combine their information and recreate the secret launch codes.
The data storage application reverses the original purpose of secret sharing. Rather than trying to resist conspiracy (keeping M large), distributed backup usage is trying to reduce the effects of data loss (keeping N-M comfortably large. RAID5, in a sense, has N-M=1; RAID6 has N-M=2, etc.) by permitting "conspiracy" of a subset of the original parts to restore the original information. Essentially, this is a somewhat more computationally intensive way of dividing up data, but has the great advantage that it can easily adapt to different desired amounts of redundancy and different numbers of physical data storage targets.
Note: this is based on some math I had in college, not a reading of the ACM article.
Actually, it will have an average latency of 4.16ms. At 7200rpm, the platter rotates once every 8.33ms; on average the data you're looking for will be half a rotation away, or 4.16ms. There will also be seek time, varying from about 1ms for track-to-track seeks, to perhaps 20ms, depending on acoustic management settings and other things. So gripe about the photo containing poorly-chosen specs if you want, but please don't complain that there's something wrong when the spec lists average latency, and tells you what the average latency is.
As for your comment on transfer rate, it too is clear, precise, and accurate. The maximum external transfer rate is as listed. If you want to know the maximum media transfer rate, Seagate will tell you that too. By convention it's expressed in megabits rather than megabytes, but it'll be listed. Usually maximum sustained transfer rate isn't listed as a specification, but it's readily findable if you want to know, and it's nearly irrelevant anyway. If you're curious, it'll be about 80-90MB/sec.
It's all about branding. You can create these criteria, group people based on them, and label a group "intellectually curious", but doing so makes you a nerd. Since the point seems to be to get beyond the "nerd" label, we can't be creating an un-cool label to replace it, especially when it's longer, more complicated, and not generally understood.
I propose "sci-curious". Short, chic, descriptive. Of course, it doesn't cover the politics geeks, but they'll just have to get their own term.
*sigh*
Please read before you post. You don't even need to read the article: the submittor ripped off the relevant article text for the summary.
Dell's not taking credit for 64-bit ISA extensions to x86. They're taking credit for forcing Intel to add them to their Pentium and Xeon lines rather than reserve 64 bit goodness for the doomed Itanium line. The point is that, rather than mutely accept the scraps Microsoft and Intel throw their way, Dell has the clout and the will to push Intel around.
I would agree with your assertion that more subdomains should be used, and that movies are a particularly obvious and egregious example. The switch from moviename.TLD to movienameTHEMOVIE.TLD is an early sign that even those with deep pockets are feeling the crunch. One solution would be moviename.movies.TLD, but of course everyone would object to whoever owns .movies.TLD. Which doesn't affect any studio with the balls to just use moviename.studioname.TLD
.com are safe, and recognizing that longer names are more likely to be, in some poorly-understood way, "bad", it's going to be difficult to get people to accept the logical extension of subdomains: buzzlightyear.actionfigures.merchandise.movies.dis ney.com
.gov for itself. Any rational organization would have put all national governments under .gov, so you'd see navy.mil.us.gov on the same footing as raf.mil.uk.gov. As we've seen, the early lack of foresight in claiming .gov for the USA has resulted in hundreds of country code TLDs, which has benefited countries whose code happens to have some use to foreigners (.tv, for example), but is a net loss in terms of overall rationality.
.us domain. Consider the URL for my local library system: www.scls.lib.wi.us. The South Central Library System is a library entity in Wisconsin, which is in the US. Or my home county's webpage: www.co.dane.wi.us. Other than having the CO and DANE in the wrong order, it's the model of rationality. If we can keep the number of TLDs down we will allow such islands of order to exist where they can still be reasonably found.
.eu domains will end up being the same as existing .com domains. In turn, most of these will in fact be the same page as the .com domains, with a few being owned by the same company and presenting substantially the same information with a more locally-appropriate flavor. Only a few will be completely separate (say, two small companies with the same name in geographically diverse areas). In other words, there is little need for something like a .eu TLD. Most of the blah.eu domains would more properly be served by eu.blah.TLD instead, and the primary result of the existence of .eu is to funnel money into the coffers of those involved in setting up and running the TLD, without creating commensurate value.
Unfortunately, your (and my) opinion that more subdomains should be used is just a consequence of the way the internet's run. Consumers are conditioned to expect blah.TLD as a domain name and to be distrustful of long names (with some justification). Having made the conceptual leap that not all domains ending in
Ultimately, the problem is one of control, whether that's self-control or regulatory control. Every time a new TLD opens up, there's the same rush to buy the same domains with another TLD. Why are there country code TLDs? Well, because the USA dominated the early internet and claimed all of
The namespace has been so poorly managed in the past that it's difficult to exert the necessary control to maintain order. The only positive outcome of that is that there's a reluctance to change, allowing us to become reasonably comfortable with the status quo. Earlier in the internet's development, a different approach to TLDs would have helped whereas today it can only waste more money. Fortunately, if the limited number of TLDs remains small, the overall anarchy can be masked by tighter local control. For an example of that, see the
It's fairly clear that increasing the number of TLDs only marginally increases the number of websites. Most of the
I hope that increased reliance on search engines to find desired content will diminish the perceived value of a domain name, with the result that branding and marketing will have less input in the choice of naming, thus hopefully leading to gradually more hierarchical namespaces. At best, that's a long-term goal, and I'm sure it will be preceeded by smaller-scale campaigns to standardize and/or rationalize naming within individiual entities. One example of this would be the namespaces Apple uses internal to OS X.
Yeah, Three Gorges has its (major) problems. But to say it should never have been built is a luxury you have because of living in a country fairly well-provisioned for its future energy needs. As these things go.
China's projecting enormous increased demand, and there's no good way to get the energy.
They can bet on coal, which China actually has quite a lot of (though not so much on a per-capita basis), but it's something of an environmental disaster even if it's burned cleanly.
They can bet on nuclear, which presents waste storage problems and relies on finite supplies of fissionable material.
They can bet on wind (not sure of the viability of that, but I'm sure at least SOMEWHERE in China there's good wind), but it takes up a lot of area and apparently isn't so good for birds.
They can bet on solar, which is even worse in terms of taking up space, and is expensive, and only works for half the day.
They can bet on hydroelectric, which displaces people, permanently changes the river, and nukes a whole lot of land. And that enormous lake is going to affect the weather.
There are other options too, of course. And the best solution is a mix of many different technologies. Etc. But the fact is that there's no good solution. China bit the bullet and picked what they hope is the least-bad choice. It had to be done.
What are you talking about? U/320 SCSI is 320 megabytes per second. Not bits. In a regular PCI slot on an unloaded bus, a U/320 HBA is limited to 90-110MB/sec, but with PCI-X or PCIe that limitation is removed, and single HBAs can readily sustain 500+MB/sec sequential reads from arrays spanning multiple SCSI channels.
Of course, in many applications, latency of varying sorts quickly chews that number down to something a bit more sane.
If you're limited to a hard 20MB/sec over SCSI, the first thing I would suggest is to make sure that you're actually operating at U/320 speeds, and your HBA and drive(s) haven't fallen back to one of the SE modes for some reason (faulty connection, crummy cable, missing / buggy / broken / wrong terminator, etc).
"Sugar, for example, doesn't melt, buit decomposes into water and carbon when heated, so it can't be a frozen liquid."
I have candy says otherwise.
Sure, sucrose eventually decomposes into carbon, hydrogen, and oxygen. But then so does pretty much every other organic compound, given sufficient heat.
The egalitarian aspect of saving Disney is illegal, sure. But saving Disney should Increase Shareholder Value(tm), which makes everything OK. Similarly, there's reason enough to believe that the merger could increase shareholder value, even if Jobs' ultimate goal is to cash out, that it'd be legal.
Besides which of course, the SEC apparently considers it kosher...
Whoops, you're right - I plugged the wrong numbers in. 50% Pixar -> 7% Disney is correct. Yes, the new company should have the combined market cap of both (assuming investors consider the new company to be worth the sum of the values of its parts), so it's actually slightly less than that (about 6.15%)
This deal doesn't make Jobs $3.5bn, as the article claims. It barely makes him any money at all.
Pixar's market cap is just a hair under $7bn, about half of which Jobs owns. Disney is buying all $7bn worth of Pixar stock with $7bn worth of Disney stock. So Jobs isn't making any money, he's just changing the name on part of his stock portfolio (Disney's buy is a bit above market value for Pixar, so he does make SOME money, on the order of 1% of the $3.5bn the article mentions). He's also going from being a 50% owner of a $7bn company to a 14% owner of a $50bn company.
So maybe Jobs thinks he can get in and infect Disney with Pixarness and save it. Maybe he just wants to cash out and do something else, and figures he can sell 14% of Disney a lot easier than he can sell half of Pixer. Could be he thinks Pixar will do better with Disney behind it than with Disney as an enemy. Possibly there's another explanation. Let the speculation continue - we'll know in a few years what the plan was and whether it worked or not.
Really?
You've run xbench and it consumes more than about 300MB of RAM? What about quicktime dealing with a 50MB movie? And iTunes - we all know that sucker benefits from having 4GB of RAM to play with.
The quicktime test is streaming - it will be bound by CPU and memory performance. Ditto CD ripping. Ditto Xbench, except for the graphics-bound tests there. I'm not familiar with photoshop, so that might have wanted a bit more memory to work on a 50MB file, but the actual tests run should all be CPU bound as well. After all, that's the whole point of the article - to see what difference the change in CPU / chipset makes.
Would I rather have seen the new imac with a gig of RAM? Sure. But I'd be surprised if it made more than a 5-10% difference in any one test, or more than 2-3% overall. The benchmarks being run just aren't memory-hungry enough.
That would depend on the working set size for the given app.
512MB may be slightly cramping the style of the new imac, but it didn't look like any of Ars' benchmarks would need much more than that. Certainly 4.5GB isn't going to make any difference, and if you've been following Ars' articles, you'd know why that particular machine is so loaded. The CPU-bound, disk-bound, or graphics-bound benchmarks aren't going to notice the change in RAM amount. The photoshop test, being done on a fairly large image, might have seen some impact from the difference in available memory.
Given how heterogenous the systems are already, I'm not too concerned with a slight difference in memory size. Given the different instruction sets, execution hardware, cache layout, and memory controller, I think having only 512MB rather than a gig is unlikely to show up in the benchmarks or in most users' usage.
Truthful, yes. Honest, no.
Not that anyone expected anything different. To be fair, nobody's completely honest with benchmarks, but Apple's among the worst offenders. That said, the Intelmacs are only hideously slow in comparison to the PPCmacs on CPU-bound emulated code, which is to be expected, and is the case with the best chance for improvement in the future. And they actually manage to win a few of the benchmarks, which is nice.
I'd like to see linux running on the new machines. OSX is going to be slow on X86 if for no other reason than the Apple programmers aren't used to the architecture yet. Linux should be a lot closer to best-case speed, so it would be useful to see approximately how much faster OSX can get on the same hardware. I'm not a compiler guy, but my understanding was that GCC still has improvements to be made with regard to newer CPUs and multicore CPUs which should help OSX on Intelmacs as well.
Based on my completely unsubstantiated memory of the M68K -> PPC switchover, Apple's learned some things. It looks like this processor switch is going to go a lot more smoothly than the last one did, which can only mean good things.
I think the decision in the case where an article is submitted by two different people is simple - pick the submittor whose name will cause the least trouble. I presume this isn't what's keeping you up at night, but rather a unique submission by someone who's going to get flamed, so I'll talk about that case.
.sig links, so the submittor can get back the google juice by contributing good comments to the discussion, which is one of the big reasons you're conflicted about disliked submittors in the first place.
Actually, I think you had the right solution earlier - the nofollow. Sure, you want to encourage submission of interesting tidbits, and currently there are several kickbacks for doing so: egoboo and google juice being the big ones. I suspect the google juice aspect encourages submission patterns that are ultimately harmful. Altruism and egoboo are probably enough justification for most folks to submit links, and are conveniently nonmonetary. Google juice, on the other hand, is fairly easy to monetize, which tends to bring out the worst in people.
So just add a nofollow. The submittor still gets traffic from the story submission, gets his or her 25 minutes of fame, and has bragging rights for as long as the accepted submission stays in the user profile. There aren't any nofollows in
I know you'd rather live in a world where the messenger doesn't attract attention, but since that world doesn't exist you'll have to attack the problem a different way, and the best way that I can come up with is to discourage the sorts of submittors who cause problems. Hopefully this can be done without materially affecting the overall quality of submissions, which I believe can be accomplished. So run an experiment, and get back to us in a month or two with the results - worst case you'll have to take the nofollow code back out.
You don't need much hardware at all to handle hundreds of requests per second with apache (unless you're doing uncached database queries or other braindead things with scripts).
If this kid can get that many strangers to load up the server that hard for enough hours that the school administrators took notice (in my experience, this can take days), call someone in to poke around, and for him/her to notice what's going on, the school's already out of its league.
The article's a bit thin on details, but it looks like the message wasn't "going here and pressing F5 a lot will slow down my school's computer" (which is informative, and strictly legal) but rather an inducement to commit a crime (possibly - it'd be hard to prove intent to do harm on the part of the folks that actually helped DDOS the machine), which is itself illegal.
So, we have a kid doing something dumb, amusing, actually sort of impressive, and possibly illegal. Yep, sounds like high school.
A couple points.
It's got a four and a quarter gigahertz dual-core Pentium in it. Overclocked like that, the Pentium can probably keep up with a fast Athlon.
There don't seem to be benchmark results anywhere, but if Tom (yeah, I know) is anywhere near right, Intel and Nvidia would have to have gotten a lot of optimization done to make this anywhere near useful. And I mean that in the loosest sense of the term: faster with 4 GPUs than with 2.
Also, you need to be playing games at 1600x1200 or higher resolution, with all the eye candy turned up, to notice a difference. This isn't so much an issue of having a fast enough CPU to keep up. It's really more about piling on enough pointless eye candy to slow the GPUs down to a speed the CPU can handle.
Discussions with friends in the strange countries or for with people of other cultures after the coincidence speak, profit from this kind of the technology. Everything does not remove technical will suffers terriblly and straight under untranslated words (as a everyone, which read at all, the Japanese, Korean or even German small article report places of assembly know).
(This post courtesy of English -> German -> English translation. The first sentence is actually pretty close to what I wrote. The second, ah, not so much.)
Specifically, Mercury's day is 58.65 earth days long, while its year is 87.97 earth days long (source: NASA JPL).
From the same source, we see that Mercury's minimum temperature is about 100K (comfortably colder than liquid nitrogen). Obviously that would occur on the currently-dark side of the planet. So while there's no permanently-dark side of Mercury, there's certainly a cold dark part of mercury somewhere at any given point in time, and that coldest part is only about 50K away from Pluto's temp (presumably an average).
Moral of the story: computers wouldn't like the cold on Pluto, but they wouldn't like the 700K highs on Mercury either. Also, as a wise man once said, "It's funny. Laugh."