> Native Spanish speaking population in the world 330 million
A web browser is only useful to people with internet access, so the number of people *on the internet* who speak a given language is much more important than the total worldwide population of speakers, when you're deciding which languages to support in a web browser.
And, actually, this is a _beta_ release, so you're mainly interested in web content developers, which is a relatively small subset of the people on the internet, and even further skewed toward peole who are literate in the more strongly represented languages, especially English. (Many, many web developers who are not *native* speakers of English are literate in English as a secondary or tertiary language.)
German has always been strongly represented on the internet, not as strongly as English, but disproportionately strongly compared to the relatively small size of its native-speaking population. We could speculate about the reasons why (most of which would probably be socioeconomic factors at the macro level), but it's kind of just always been that way, since the internet was fairly new. A very high percentage of German speakers have internet access, compared to most other languages.
Spanish and French are more widely spoken in the world than German, but less well represented on the internet. I think the same may also be true of Arabic and Hindi.
Chinese, like Spanish, is under-represented on the internet compared to the size of the native speaker population, but in the case of Chinese the size of said native speaker population is *so* large that it can be a bit under-represented on the internet and still be one of the major languages.
> I would like to do my [three-month] internship in the US, but I do not know how to start.
You mean apart from attempting to land an internship somewhere in the US?
You'll also need to do the government paperwork. You could come to the US for three months on a tourist visa, which is easy to get, but I'm not 100% certain you can be employed on a tourist visa. Maybe on a student visa? There is also such a thing as a work visa (e.g., H1B). I'm not really up on these details, but you'll want to find out exactly what kind of visa you need to get, and apply for that.
Of course, you'll want a passport from your home country first, but you probably already knew that.
> Is it common to send unsolicited applications to companies in the US?
Yes.
You don't expect to get a position every place you apply, of course. Some of them may turn you down, others you may never hear back from at all. But you *certainly* won't hear from them if you don't apply.
> Try the big corporations?
If you want to work for a big corporation, sure.
> Should I go for an employment agency?
That may be an option as well, though I don't know as much about it.
> What about the pay? Where I come from it is common to pay only a fraction of what your work is > actually worth if it's called an 'internship.' Does this apply to the US as well?
Yes. As far as I'm aware, the word "internship" carries this meaning in every English-speaking country on the planet. (In fact, there are some fields wherein interns are ordinarily not paid, but I don't think IT is one of them.) If that's a problem for you, you might check whether your program of study really cares whether the employer views the work as an internship program. Some programs of study require an internship as such (so that you have a supervisor who views you as a student and expects to spend an appropriate amount of time showing you the ropes and such), while others just want you to have some real-world work experience. Find out which situation you're in and plan appropriately.
> Any other recommendations?
In terms of culture, it *does* make a difference which part of the US you come to. California is totally, totally different from Indiana, for example. If you have specific ideas about what you want your experience to be, you might want to discuss them with someone who has moved around a bit in the US.
If you're serious, keep putting in applications until you get something.
> I don't know how high "high density" is in the parts of Japan that are being talked about
Japan is a fairly densely populated country. I mean, it's not Singapore, but it's not Canada either.
The largest of the Japanese islands, Honshu, has a population density greater than every US state except New Jersey. And it's a pretty big island, so presumably some areas of it are a lot less densely populated than its average, and others a lot more. I'd imagine they have areas that are populated about like Manhattan.
On the other hand, Hokkaido (the northernmost of the main islands, and the second-largest) has about the same population density as Indiana or Michigan, which are about average in the US. So one imagines they have some fairly rural areas there.
> The memory protection systems, for.NET languages, were intended to be completely bulletproof.
Completely bulletproof is impossible. Someone will always come up with special tips, special jackets, armor-piercing rounds, exploding bullets, a firing mechanism that yields higher velocity, flechettes or KE penetrators, a higher calibre of bullet (up to and including shells the size of a planet), antimatter bullets, or something.
> In fact, MS goes on about how.NET applications can be verifiably proven to be completely safe WRT memory.
With respect to a specific type of memory attack (e.g., buffer overflows), *maybe*. But there's always some other kind of attack, something you did not anticipate.
There was once a ship that was thought to be unsinkable, and then this iceberg came along...
"'Unbreakable', 'absolute', 'unforgeable', and 'impenetrable' are all words that make no sense when discussing security. If you hear them, you can be sure you're listening to someone who doesn't understand security or is trying to hoodwink you." -- Schneier. Beyond Fear: Thinking Sensibly About Security in an Uncertain World, pp57-58.
> An interesting fix is also to run the plugins in their own address space
No one who understands security would do it any other way, I've said that for years. Plugins that run in the host application's memory space are a scary enough idea in general, but for web browser plugins, where the whole point is to handle untrusted content, which is usually fairly active in nature, to allow third-party binary plugin code to run amok in the browser process is a really REALLY bad idea.
And it's not just a bad idea from a security perspective either. There's also stability to consider, and memory management issues (e.g., what to do if a plugin leaks memory), and a plethora of other unwanted complications.
Helper applications are the way to go. Non-standard content should be launched in external helper apps, each with its own process, its own memory space, and its own window. And only if the user clicks a "launch" button (analogous to the play button FlashBlock provides). Then if Flash crashes, the rest of the browser keeps right on chugging.
> One of the most common problems I used to run across was users changing the extension on a > file then not understanding why it didn't work as expected. Users often change file names, > and with extensions hidden, they can do so without needing to understand why a file has a > particular extension since they don't change it.
The correct way to do this is for the rename dialog to have separate fields for "Name" and "File Type Code (extension)", possibly with the latter only editable if the user has set a preference to that effect.
On FreeBSD, IIRC, bash actually goes into/usr/local. Coming from a Linux background, I was pretty weirded out by that at first. ("What do you _mean_ there's no/bin/bash? I'm at a bash prompt right now! What would I do in an emergency if/usr wasn't mounted?")
Eventually I realized that it's just a cultural thing: pretty much *everything* goes under/usr/local in FreeBSD. In the Linux world we tend to think of/usr/local as being a place where stuff goes that's specific to a particular site, or even to a particular system. For instance, if a kiosk system uses a customized version of xscreensaver, then the customized xscreensaver will probably go in/usr/local. Most applications go in/usr, but critical things like shells, which might be needed in single-user mode when/usr may not be mounted, go in/bin. (These days/usr is almost always on the same filesystem as/, but traditionally that wasn't necessarily the case.)
In the BSD world it's just different. As near as I can tell,/usr/local is where most (but not quite all) of the core operating system files go, as well as all applications, and pretty much anything else that doesn't go in/home or/var.
The main problem with UAC is the culture that has developed for Windows application development. ISVs are accustomed to writing their software in ways that cause UAC to trigger much more often than would really be necessary. Old habits are hard to break, and old codebases take a lot of effort to totally redesign.
For instance, take Symantec Norton Anti-Virus. (Please!) Here's an app that has a legitimate need to regularly retrieve information from the internet (e.g., new signatures) and store it locally. Furthermore, it makes good sense for it to be stored locally in a location where any ordinary user should never ever have write access. That's all good as far as it goes. Now, in the Unix world, there'd be a cron job that runs with different privileges than the normal user and does nothing but retrieve these updates. The normal app that runs with the user's privileges would never need to have those privileges. But Symantec is not from the Unix world. NAV *used* to run on Windows 95 and 98, and has been *updated* for XP and Vista. So what does NAV do to get its updates? LiveUpdate runs from the user's account (and only when the user's logged in, at that) and tries to do what it needs to do from there. That's the only way they could do it on Windows 95 (which didn't really have permissions in the modern sense), and so that's how they're accustomed to doing things. They did it that way even on Windows XP, when UAC was not available, so that the updates sometimes failed for lack of privileges, if the user was logged into a limited account. (And sometimes the updates did not fail from a limited account, which is kind of scary in its own way -- does that mean some of the antivirus info is stored where normal user applications, such as web browsers, have write access?) Under Vista, instead of failure in situations like this, you get a UAC prompt.
It isn't just NAV that causes unnecessary UAC prompts. A lot of Windows applications do, because their design is still heavily influenced by their past, and by the cultural assumption at Microsoft that "the desktop is the barrier to security", i.e., anybody who can log in, and anything they click on, was trusted. Microsoft has started to know better, and to work on fixing their security model, hence UAC (which is essentially gksudo, which is really not a bad design, ultimately). But cultural change takes time, and the legacy of the past still haunts the Windows desktop, and will for some time to come.
Well, they said inversely proportional, which would tend to make you think infinity, but they didn't say inversely _arithmetically_ proportional, so with a more complex inverse relationship it's possible that it actually approaches some finite value asymptotically.
(Sorry, I realize this answer isn't in exactly the same tone and spirit as the original joke, but I just can't resist the urge to bring more mathematics into a conversation.)
*Don't* try to use one of those cheap hand-held CD cleaner/scrubber machines. They don't work worth beans. But there is such a thing as a real resurfacer.
I work at a public library. We have a resurfacer (specifically, an EDR DiscChek). It does work fairly well. Many CDs and DVDs that were so scratched they wouldn't play at all have come out of this machine in like-new condition. It does have limits (e.g., if the backing's flaking off it can't fix that), but for typical scratch damage it really does work.
You probably don't want to buy one of these babies for your house. It's unweildy, for one thing (bucket of solution with a hose running up to the machine, bottle of the other solution with a tube running into the machine, drainage hose running out to another bucket, jugs of distilled water, four different kinds of pads, the thing weighs a ton,...), and then there's the expense. It's the kind of thing you'd only want to invest in if you have an ongoing need to resurface discs on a regular basis -- e.g., if you have a large collection of them that you lend out or rent out. To just do a small collection once, it's not worth it.
But you might not have to buy your own. Once somebody invests in the machine, they have it, and may be willing to do more than just their own discs. Here, the library where I work actually offers a service wherein for $2 per disc we resurface discs for patrons. We don't advertise this, but when people ask... yeah, we do it.
You might ask around in your area and see if any of the libraries or video stores near you offer a similar service.
That has consequences, though. There are whole categories of useful data mining that you can't do if you throw away that information. Among other things, your weeding reports can't distinguish between a book that was checked out thirty times in three years always by the same person (a *strong* candidate for the Friends of the Library booksale) versus a book that was checked out thirty times in three years by twenty-five different people (a book you'd want to keep on the shelf). That may not sound important if you don't work at a library, but with finite shelf space and a continuous influx of new books, every library fights a ceaseless battle to identify old books that aren't really needed in the collection. Much time is spent on this. Being able to run automated reports to identify as many of them as possible is an indispensable tool, and being able to base that at least partly on how many different patrons have checked the book out is invaluable.
And that's just *one* example of something you can't do if you throw away the history information.
Statistical correlation for reader's advisory ("people who checked out this book also read books by these authors") is another.
And another, which you'd have no way to know about if you haven't worked at a library, is answering patrons' own questions about what books they have or haven't checked out in the past. I know this is hard to believe (eight years, and I'm still not used to it), but anyone who has worked the checkout desk in a library can testify that a significant minority of library patrons do not remember whether they've checked this book out before, and they want you to tell them. Throw away the history, and you can't. And they will never understand why you can't just look it up in the computer.
And there are more, too many to list. Fundamentally, throwing away data means you lose information. Information is what libraries are all about, so throwing away data is a hard choice to make. And yes, lots of libraries do throw the information away, because they're concerned about the privacy issue. But that decision has consequences.
> If goons with badges can go about asking for records of who reads what on a whim the police > can effectively shutter a library by flooding it with requests for records.
That's absurd. If the library was okay with providing the desired information to the police, they could just give them a database connection and let them run whatever queries they want. You'd want to set up a read-only connection, so that would take a few minutes of the sysadmin's time, but it would hardly "shutter" the library.
The library association in question was obviously concerned with the privacy issue -- they didn't want the police to be able to find out what people are reading. You can agree or disagree with that position, but that's obviously what they were fighting for.
> But, to the extent that the public expects some measure of anonymity > in a public library, it strikes me as a very bad PR decision.
I suspect that depends where you live. Around here, being uncooperative with the police and making them go back and get a warrant (which can take several days, or hours at the least) would almost certainly be significantly worse PR, especially if the public was under the impression that the case might involve something like Anthrax.
Bear in mind, a library in Maryland probably doesn't care very much what computer geeks in California think about it when they read the news story on slashdot. Insofar as they are concerned about PR, they would mainly be concerned with PR among the people in and around their service area. So in order to predict the PR impact, you'd have to know the local culture in their area.
I don't really know what the PR considerations would be for the library in question, but unless you live near there, you probably don't either.
> Honestly this result is not unexpected. The interactions of electrons > and nuclei depend on several factors: distance, energy, and charge.
Indeed, the Bohr model is just that -- a model, an invented construct designed to allow undergraduates to remember some of the most common interactions and perhaps even superficially understand them, or at least pretend to. It's useful, provided you keep in mind that it is actually just a model. (And, depending on what you're doing, it may tell you everything you need to know, if you don't really need to know the details at the subatomic level.) Like analogies, models will mislead you if you try to hold to them rigidly and use them to predict and explain things they weren't really designed to cover. The Bohr model breaks down when you start trying to use it to predict details about the behavior individual subatomic particles. It wasn't designed to model that. It was designed to model whole atoms.
For example, distance and position at the subatomic level, don't work exactly the way most people think about them. An electron is a subatomic phenomenon (traditionally, a "particle", but that terminology can be misleading if you aren't careful with it). It behaves like a subatomic phenomenon. It does *NOT* behave exactly like the miniature electro-magnetically charged marble revolving around its primary nucleus like a planet orbits a star that you probably envisioned when your junior-high science teacher explained the Bohr model to you for the first time. On the contrary, there are serious questions about whether a given electron actually necessarily occupies a specific spatial position within the atom at any given point in time, or has a specific velocity at that moment, or cetera. The idea that a given electron continues for the entire life of a molecule to occupy a specific spatial position within that molecule is cartoonishly absurd, even if it does make for convenient diagrams on the chalkboard. Electrons don't hold still. They move around. They may stay with the other particles they're with (i.e., stay in the atom or molecule), but that doesn't imply they stay rigidly in exactly the same position within that context. And they sure don't go around in regular periodic elliptical orbits like planets.
Electrons and other subatomic phenomena *do* share certain things in common with the miniature charged marbles your high school chem teacher probably taught you to think of them as. For instance, they are discrete (in the mathematical sense, i.e., at any given moment there are a certain number of them, and that number is an integer). And their position certainly doesn't go all over the map at the macroscopic level -- they're in a given area, generally corresponding to a given atom or, in some cases, mollecule (or part of a mollecule...)
So, yeah, the idea that a certain electron wouldn't ever interact at all because it's not in the valence position is... an idea that never made sense, as far as I'm concerned. You'd only get that idea if you took the models too far and started to think of them as if they were exact representations of the physical reality. Setting the Bohr model aside and looking at the individual parts of an isolated atom (insofar as there is such a thing as an isolated atom) what does it mean, at the sub-atomic level, for one electron in an atom to be a valence electron, and another electron in the same atom to not be a valence electron? They're both electrons, they're both associated with the nucleus via the electromagnetic interaction,... if there are no other atoms about (which, granted, is unlikely) then neither electron is interacting with anything outside the atom... what makes one of them "valence" and the other "not valence"?
But, as I said, IANAC, so perhaps I'm missing something.
> Midori is being designed in such a way that components of the OS communicate with each other in a location > independent manner. API calls to a local machine are no different than API calls to a remote machine.
Sounds a lot like Plan9. It's an old idea now, but it never caught on in a mainstream OS.
It's a theoretically interesting approach, in the sense that a lot can be learned from it, and some of what is learned may potentially be applicable to more mainstream systems. It's good for Microsoft to do this kind of research, because even if the product itself never goes to market, some technologies that come out of the research may make their way into other products.
But hey, maybe if the next Microsoft OS is called Midori, the open-source world can put together a distro called Murasaki.
It doesn't come configured this way out of the box, but you can certainly set up Emacs to do this. Off the top of my head I don't recall the exact hook to use, but I know that there *is* a hook that's called after every operation, however small (even, say, moving the cursor), so at worst you could use that. Ideally, if there's a hook that's called only when something actually changes, that would be better. Anyway, you'd want to add a function to that hook that calls diff and appends the result to a log, or somesuch, depending on exactly how you want it to work. Anyone who's comfortable in elisp should be able to set this up in a couple of minutes.
Of course, then your users have to learn Emacs, which might take rather longer...
Having the *ability* to do math does not automatically cause people to do math. They also have to decide they like math.
You'll notice that the women who *do* go into math tend to be very good at it. One could conclude that this is because women are actually better at math than men, but that's not true either -- there are also men who are very good at math. What's really going on is that a lot of women aren't *interested* in math.
In both genders, there are a few individuals who are exceptionally good at math, and they tend to go into math or related fields. In both genders there are individuals who can't do math to save their lives, and they usually *don't* go into math, which is just as well.
But in between you have individuals who are pretty good at math, but also pretty good at some other stuff. At some point they decide what they want to do with their lives... and when they're making that decision, the males are, on average, more likely to pick math, and the females are, on average, more likely to pick something else -- as evidenced by the fact that some fields are skewed almost as strongly the other direction. For example, the overwhelming majority of library workers are female. This is not because women are naturally better than men at working in libraries. It's because for various reasons they're more likely to *choose* to do that. And no, this isn't just a stereotype, it's really true. I work in a library and have attended numerous library-related conferences and things, and typically in a group of sixty people you can count the men on your fingers. The bias is so strong, that it overrides the otherwise male IT bias: the majority of library IT people are female. Ability isn't the issue. Desire is the issue. What people *want* to do with their lives is heavily influenced by their gender. (This is partly cultural, but not entirely.)
Personally, I find the notion of doing non-lethal crowd control with a howitzer to be intriguing. I assume, in order to avoid seriously harming people, that at the size of howitzer rounds you'd have to make them out of something rather softer than the rubber bullets you'd use with a rifle. That could be... interesting. Lower density is the most obvious way to decrease the lethality of such a large projectile. Polyurethane foam, perhaps? That might be have *too* low a density, but you could coat it in a layer of rubber. Increase the thickness of the rubber coating until the desired impact is achieved. But there may be other possible approaches as well. I've read that a basic ghetto-style potato gun made from PVC pipe and using hairspray for the propellant actually turns the potato into a mush of small particles as it accelerates it to exit velocity. If you could arrange something like that for the crowd-control setting on the howitzer, could you blast people with potato sauce? *Rotten* potato sauce? What about hog manure? So many options...
> Yeah Latin is still available to anyone who wants to take it
Depends on the school.
At my high school, I had the choice of Spanish or French. No other foreign languages were offered, period. At the time, I selected Spanish for idiotic reasons having to do with the nasality of French. Had I to do over again, I'd select French over Spanish because of its greater influence on English over the last several centuries. But if Latin had been offered, I *certainly* would have chosen to take that instead of either Spanish or French. I definitely wanted to take Latin, and annoyed numerous people by saying so. Dead languages have always fascinated me. Alas, Latin was not an option.
But I made up for it in college by taking crosslisted seminary Greek (which fits nicely with the current topic, incidentally) for electives.
Perhaps some day I will take Sanskrit, and then when people boast about knowing Latin I can put them in their place:-)
Slashdot Mirror
> Native Spanish speaking population in the world 330 million
A web browser is only useful to people with internet access, so the number of people *on the internet* who speak a given language is much more important than the total worldwide population of speakers, when you're deciding which languages to support in a web browser.
And, actually, this is a _beta_ release, so you're mainly interested in web content developers, which is a relatively small subset of the people on the internet, and even further skewed toward peole who are literate in the more strongly represented languages, especially English. (Many, many web developers who are not *native* speakers of English are literate in English as a secondary or tertiary language.)
German has always been strongly represented on the internet, not as strongly as English, but disproportionately strongly compared to the relatively small size of its native-speaking population. We could speculate about the reasons why (most of which would probably be socioeconomic factors at the macro level), but it's kind of just always been that way, since the internet was fairly new. A very high percentage of German speakers have internet access, compared to most other languages.
Spanish and French are more widely spoken in the world than German, but less well represented on the internet. I think the same may also be true of Arabic and Hindi.
Chinese, like Spanish, is under-represented on the internet compared to the size of the native speaker population, but in the case of Chinese the size of said native speaker population is *so* large that it can be a bit under-represented on the internet and still be one of the major languages.
Wouldn't all the extra computational cycles devoted to SETI@home and its ilk be a much larger factor?
> I would like to do my [three-month] internship in the US, but I do not know how to start.
You mean apart from attempting to land an internship somewhere in the US?
You'll also need to do the government paperwork. You could come to the US for three months on a tourist visa, which is easy to get, but I'm not 100% certain you can be employed on a tourist visa. Maybe on a student visa? There is also such a thing as a work visa (e.g., H1B). I'm not really up on these details, but you'll want to find out exactly what kind of visa you need to get, and apply for that.
Of course, you'll want a passport from your home country first, but you probably already knew that.
> Is it common to send unsolicited applications to companies in the US?
Yes.
You don't expect to get a position every place you apply, of course. Some of them may turn you down, others you may never hear back from at all. But you *certainly* won't hear from them if you don't apply.
> Try the big corporations?
If you want to work for a big corporation, sure.
> Should I go for an employment agency?
That may be an option as well, though I don't know as much about it.
> What about the pay? Where I come from it is common to pay only a fraction of what your work is
> actually worth if it's called an 'internship.' Does this apply to the US as well?
Yes. As far as I'm aware, the word "internship" carries this meaning in every English-speaking country on the planet. (In fact, there are some fields wherein interns are ordinarily not paid, but I don't think IT is one of them.) If that's a problem for you, you might check whether your program of study really cares whether the employer views the work as an internship program. Some programs of study require an internship as such (so that you have a supervisor who views you as a student and expects to spend an appropriate amount of time showing you the ropes and such), while others just want you to have some real-world work experience. Find out which situation you're in and plan appropriately.
> Any other recommendations?
In terms of culture, it *does* make a difference which part of the US you come to. California is totally, totally different from Indiana, for example. If you have specific ideas about what you want your experience to be, you might want to discuss them with someone who has moved around a bit in the US.
If you're serious, keep putting in applications until you get something.
> I don't know how high "high density" is in the parts of Japan that are being talked about
Japan is a fairly densely populated country. I mean, it's not Singapore, but it's not Canada either.
The largest of the Japanese islands, Honshu, has a population density greater than every US state except New Jersey. And it's a pretty big island, so presumably some areas of it are a lot less densely populated than its average, and others a lot more. I'd imagine they have areas that are populated about like Manhattan.
On the other hand, Hokkaido (the northernmost of the main islands, and the second-largest) has about the same population density as Indiana or Michigan, which are about average in the US. So one imagines they have some fairly rural areas there.
> It is impolite to take photos in people's windows.
There's this nifty invention called a "curtain"...
> The memory protection systems, for .NET languages, were intended to be completely bulletproof.
.NET applications can be verifiably proven to be completely safe WRT memory.
Completely bulletproof is impossible. Someone will always come up with special tips, special jackets, armor-piercing rounds, exploding bullets, a firing mechanism that yields higher velocity, flechettes or KE penetrators, a higher calibre of bullet (up to and including shells the size of a planet), antimatter bullets, or something.
> In fact, MS goes on about how
With respect to a specific type of memory attack (e.g., buffer overflows), *maybe*. But there's always some other kind of attack, something you did not anticipate.
There was once a ship that was thought to be unsinkable, and then this iceberg came along...
"'Unbreakable', 'absolute', 'unforgeable', and 'impenetrable' are all words that make no sense when discussing security. If you hear them, you can be sure you're listening to someone who doesn't understand security or is trying to hoodwink you." -- Schneier. Beyond Fear: Thinking Sensibly About Security in an Uncertain World, pp57-58.
> An interesting fix is also to run the plugins in their own address space
No one who understands security would do it any other way, I've said that for years. Plugins that run in the host application's memory space are a scary enough idea in general, but for web browser plugins, where the whole point is to handle untrusted content, which is usually fairly active in nature, to allow third-party binary plugin code to run amok in the browser process is a really REALLY bad idea.
And it's not just a bad idea from a security perspective either. There's also stability to consider, and memory management issues (e.g., what to do if a plugin leaks memory), and a plethora of other unwanted complications.
Helper applications are the way to go. Non-standard content should be launched in external helper apps, each with its own process, its own memory space, and its own window. And only if the user clicks a "launch" button (analogous to the play button FlashBlock provides). Then if Flash crashes, the rest of the browser keeps right on chugging.
> One of the most common problems I used to run across was users changing the extension on a
> file then not understanding why it didn't work as expected. Users often change file names,
> and with extensions hidden, they can do so without needing to understand why a file has a
> particular extension since they don't change it.
The correct way to do this is for the rename dialog to have separate fields for "Name" and "File Type Code (extension)", possibly with the latter only editable if the user has set a preference to that effect.
On FreeBSD, IIRC, bash actually goes into /usr/local. Coming from a Linux background, I was pretty weirded out by that at first. ("What do you _mean_ there's no /bin/bash? I'm at a bash prompt right now! What would I do in an emergency if /usr wasn't mounted?")
/usr/local in FreeBSD. In the Linux world we tend to think of /usr/local as being a place where stuff goes that's specific to a particular site, or even to a particular system. For instance, if a kiosk system uses a customized version of xscreensaver, then the customized xscreensaver will probably go in /usr/local. Most applications go in /usr, but critical things like shells, which might be needed in single-user mode when /usr may not be mounted, go in /bin. (These days /usr is almost always on the same filesystem as /, but traditionally that wasn't necessarily the case.)
/usr/local is where most (but not quite all) of the core operating system files go, as well as all applications, and pretty much anything else that doesn't go in /home or /var.
Eventually I realized that it's just a cultural thing: pretty much *everything* goes under
In the BSD world it's just different. As near as I can tell,
Oh, so it's basically a privilege escalation attack? Why didn't they just say so?
The main problem with UAC is the culture that has developed for Windows application development. ISVs are accustomed to writing their software in ways that cause UAC to trigger much more often than would really be necessary. Old habits are hard to break, and old codebases take a lot of effort to totally redesign.
For instance, take Symantec Norton Anti-Virus. (Please!) Here's an app that has a legitimate need to regularly retrieve information from the internet (e.g., new signatures) and store it locally. Furthermore, it makes good sense for it to be stored locally in a location where any ordinary user should never ever have write access. That's all good as far as it goes. Now, in the Unix world, there'd be a cron job that runs with different privileges than the normal user and does nothing but retrieve these updates. The normal app that runs with the user's privileges would never need to have those privileges. But Symantec is not from the Unix world. NAV *used* to run on Windows 95 and 98, and has been *updated* for XP and Vista. So what does NAV do to get its updates? LiveUpdate runs from the user's account (and only when the user's logged in, at that) and tries to do what it needs to do from there. That's the only way they could do it on Windows 95 (which didn't really have permissions in the modern sense), and so that's how they're accustomed to doing things. They did it that way even on Windows XP, when UAC was not available, so that the updates sometimes failed for lack of privileges, if the user was logged into a limited account. (And sometimes the updates did not fail from a limited account, which is kind of scary in its own way -- does that mean some of the antivirus info is stored where normal user applications, such as web browsers, have write access?) Under Vista, instead of failure in situations like this, you get a UAC prompt.
It isn't just NAV that causes unnecessary UAC prompts. A lot of Windows applications do, because their design is still heavily influenced by their past, and by the cultural assumption at Microsoft that "the desktop is the barrier to security", i.e., anybody who can log in, and anything they click on, was trusted. Microsoft has started to know better, and to work on fixing their security model, hence UAC (which is essentially gksudo, which is really not a bad design, ultimately). But cultural change takes time, and the legacy of the past still haunts the Windows desktop, and will for some time to come.
Well, they said inversely proportional, which would tend to make you think infinity, but they didn't say inversely _arithmetically_ proportional, so with a more complex inverse relationship it's possible that it actually approaches some finite value asymptotically.
(Sorry, I realize this answer isn't in exactly the same tone and spirit as the original joke, but I just can't resist the urge to bring more mathematics into a conversation.)
*Don't* try to use one of those cheap hand-held CD cleaner/scrubber machines. They don't work worth beans. But there is such a thing as a real resurfacer.
...), and then there's the expense. It's the kind of thing you'd only want to invest in if you have an ongoing need to resurface discs on a regular basis -- e.g., if you have a large collection of them that you lend out or rent out. To just do a small collection once, it's not worth it.
I work at a public library. We have a resurfacer (specifically, an EDR DiscChek). It does work fairly well. Many CDs and DVDs that were so scratched they wouldn't play at all have come out of this machine in like-new condition. It does have limits (e.g., if the backing's flaking off it can't fix that), but for typical scratch damage it really does work.
You probably don't want to buy one of these babies for your house. It's unweildy, for one thing (bucket of solution with a hose running up to the machine, bottle of the other solution with a tube running into the machine, drainage hose running out to another bucket, jugs of distilled water, four different kinds of pads, the thing weighs a ton,
But you might not have to buy your own. Once somebody invests in the machine, they have it, and may be willing to do more than just their own discs. Here, the library where I work actually offers a service wherein for $2 per disc we resurface discs for patrons. We don't advertise this, but when people ask... yeah, we do it.
You might ask around in your area and see if any of the libraries or video stores near you offer a similar service.
> You can diassociate names without losing how many different people checked out the book.
How, exactly?
Because I'm pretty sure I can prove by mathematical induction that it's impossible.
That has consequences, though. There are whole categories of useful data mining that you can't do if you throw away that information. Among other things, your weeding reports can't distinguish between a book that was checked out thirty times in three years always by the same person (a *strong* candidate for the Friends of the Library booksale) versus a book that was checked out thirty times in three years by twenty-five different people (a book you'd want to keep on the shelf). That may not sound important if you don't work at a library, but with finite shelf space and a continuous influx of new books, every library fights a ceaseless battle to identify old books that aren't really needed in the collection. Much time is spent on this. Being able to run automated reports to identify as many of them as possible is an indispensable tool, and being able to base that at least partly on how many different patrons have checked the book out is invaluable.
And that's just *one* example of something you can't do if you throw away the history information.
Statistical correlation for reader's advisory ("people who checked out this book also read books by these authors") is another.
And another, which you'd have no way to know about if you haven't worked at a library, is answering patrons' own questions about what books they have or haven't checked out in the past. I know this is hard to believe (eight years, and I'm still not used to it), but anyone who has worked the checkout desk in a library can testify that a significant minority of library patrons do not remember whether they've checked this book out before, and they want you to tell them. Throw away the history, and you can't. And they will never understand why you can't just look it up in the computer.
And there are more, too many to list. Fundamentally, throwing away data means you lose information. Information is what libraries are all about, so throwing away data is a hard choice to make. And yes, lots of libraries do throw the information away, because they're concerned about the privacy issue. But that decision has consequences.
> If goons with badges can go about asking for records of who reads what on a whim the police
> can effectively shutter a library by flooding it with requests for records.
That's absurd. If the library was okay with providing the desired information to the police, they could just give them a database connection and let them run whatever queries they want. You'd want to set up a read-only connection, so that would take a few minutes of the sysadmin's time, but it would hardly "shutter" the library.
The library association in question was obviously concerned with the privacy issue -- they didn't want the police to be able to find out what people are reading. You can agree or disagree with that position, but that's obviously what they were fighting for.
> But, to the extent that the public expects some measure of anonymity
> in a public library, it strikes me as a very bad PR decision.
I suspect that depends where you live. Around here, being uncooperative with the police and making them go back and get a warrant (which can take several days, or hours at the least) would almost certainly be significantly worse PR, especially if the public was under the impression that the case might involve something like Anthrax.
Bear in mind, a library in Maryland probably doesn't care very much what computer geeks in California think about it when they read the news story on slashdot. Insofar as they are concerned about PR, they would mainly be concerned with PR among the people in and around their service area. So in order to predict the PR impact, you'd have to know the local culture in their area.
I don't really know what the PR considerations would be for the library in question, but unless you live near there, you probably don't either.
IANAC, but...
... if there are no other atoms about (which, granted, is unlikely) then neither electron is interacting with anything outside the atom... what makes one of them "valence" and the other "not valence"?
> Honestly this result is not unexpected. The interactions of electrons
> and nuclei depend on several factors: distance, energy, and charge.
Indeed, the Bohr model is just that -- a model, an invented construct designed to allow undergraduates to remember some of the most common interactions and perhaps even superficially understand them, or at least pretend to. It's useful, provided you keep in mind that it is actually just a model. (And, depending on what you're doing, it may tell you everything you need to know, if you don't really need to know the details at the subatomic level.) Like analogies, models will mislead you if you try to hold to them rigidly and use them to predict and explain things they weren't really designed to cover. The Bohr model breaks down when you start trying to use it to predict details about the behavior individual subatomic particles. It wasn't designed to model that. It was designed to model whole atoms.
For example, distance and position at the subatomic level, don't work exactly the way most people think about them. An electron is a subatomic phenomenon (traditionally, a "particle", but that terminology can be misleading if you aren't careful with it). It behaves like a subatomic phenomenon. It does *NOT* behave exactly like the miniature electro-magnetically charged marble revolving around its primary nucleus like a planet orbits a star that you probably envisioned when your junior-high science teacher explained the Bohr model to you for the first time. On the contrary, there are serious questions about whether a given electron actually necessarily occupies a specific spatial position within the atom at any given point in time, or has a specific velocity at that moment, or cetera. The idea that a given electron continues for the entire life of a molecule to occupy a specific spatial position within that molecule is cartoonishly absurd, even if it does make for convenient diagrams on the chalkboard. Electrons don't hold still. They move around. They may stay with the other particles they're with (i.e., stay in the atom or molecule), but that doesn't imply they stay rigidly in exactly the same position within that context. And they sure don't go around in regular periodic elliptical orbits like planets.
Electrons and other subatomic phenomena *do* share certain things in common with the miniature charged marbles your high school chem teacher probably taught you to think of them as. For instance, they are discrete (in the mathematical sense, i.e., at any given moment there are a certain number of them, and that number is an integer). And their position certainly doesn't go all over the map at the macroscopic level -- they're in a given area, generally corresponding to a given atom or, in some cases, mollecule (or part of a mollecule...)
So, yeah, the idea that a certain electron wouldn't ever interact at all because it's not in the valence position is... an idea that never made sense, as far as I'm concerned. You'd only get that idea if you took the models too far and started to think of them as if they were exact representations of the physical reality. Setting the Bohr model aside and looking at the individual parts of an isolated atom (insofar as there is such a thing as an isolated atom) what does it mean, at the sub-atomic level, for one electron in an atom to be a valence electron, and another electron in the same atom to not be a valence electron? They're both electrons, they're both associated with the nucleus via the electromagnetic interaction,
But, as I said, IANAC, so perhaps I'm missing something.
> Midori is being designed in such a way that components of the OS communicate with each other in a location
> independent manner. API calls to a local machine are no different than API calls to a remote machine.
Sounds a lot like Plan9. It's an old idea now, but it never caught on in a mainstream OS.
It's a theoretically interesting approach, in the sense that a lot can be learned from it, and some of what is learned may potentially be applicable to more mainstream systems. It's good for Microsoft to do this kind of research, because even if the product itself never goes to market, some technologies that come out of the research may make their way into other products.
But hey, maybe if the next Microsoft OS is called Midori, the open-source world can put together a distro called Murasaki.
> That material reach its peak at 950F (~500C).
I think my attic gets nearly that hot in the summertime...
It doesn't come configured this way out of the box, but you can certainly set up Emacs to do this. Off the top of my head I don't recall the exact hook to use, but I know that there *is* a hook that's called after every operation, however small (even, say, moving the cursor), so at worst you could use that. Ideally, if there's a hook that's called only when something actually changes, that would be better. Anyway, you'd want to add a function to that hook that calls diff and appends the result to a log, or somesuch, depending on exactly how you want it to work. Anyone who's comfortable in elisp should be able to set this up in a couple of minutes.
Of course, then your users have to learn Emacs, which might take rather longer...
Having the *ability* to do math does not automatically cause people to do math. They also have to decide they like math.
You'll notice that the women who *do* go into math tend to be very good at it. One could conclude that this is because women are actually better at math than men, but that's not true either -- there are also men who are very good at math. What's really going on is that a lot of women aren't *interested* in math.
In both genders, there are a few individuals who are exceptionally good at math, and they tend to go into math or related fields. In both genders there are individuals who can't do math to save their lives, and they usually *don't* go into math, which is just as well.
But in between you have individuals who are pretty good at math, but also pretty good at some other stuff. At some point they decide what they want to do with their lives... and when they're making that decision, the males are, on average, more likely to pick math, and the females are, on average, more likely to pick something else -- as evidenced by the fact that some fields are skewed almost as strongly the other direction. For example, the overwhelming majority of library workers are female. This is not because women are naturally better than men at working in libraries. It's because for various reasons they're more likely to *choose* to do that. And no, this isn't just a stereotype, it's really true. I work in a library and have attended numerous library-related conferences and things, and typically in a group of sixty people you can count the men on your fingers. The bias is so strong, that it overrides the otherwise male IT bias: the majority of library IT people are female. Ability isn't the issue. Desire is the issue. What people *want* to do with their lives is heavily influenced by their gender. (This is partly cultural, but not entirely.)
> Crowd control via projectile vomit
How about that stuff elementary school janitors pour on vomit to soak it up? That stuff's pretty foul.
Or, if we're going to go for liquids, how about a mixture of two parts buttermilk with one part red paint?
Personally, I find the notion of doing non-lethal crowd control with a howitzer to be intriguing. I assume, in order to avoid seriously harming people, that at the size of howitzer rounds you'd have to make them out of something rather softer than the rubber bullets you'd use with a rifle. That could be... interesting. Lower density is the most obvious way to decrease the lethality of such a large projectile. Polyurethane foam, perhaps? That might be have *too* low a density, but you could coat it in a layer of rubber. Increase the thickness of the rubber coating until the desired impact is achieved. But there may be other possible approaches as well. I've read that a basic ghetto-style potato gun made from PVC pipe and using hairspray for the propellant actually turns the potato into a mush of small particles as it accelerates it to exit velocity. If you could arrange something like that for the crowd-control setting on the howitzer, could you blast people with potato sauce? *Rotten* potato sauce? What about hog manure? So many options...
> Yeah Latin is still available to anyone who wants to take it
:-)
Depends on the school.
At my high school, I had the choice of Spanish or French. No other foreign languages were offered, period. At the time, I selected Spanish for idiotic reasons having to do with the nasality of French. Had I to do over again, I'd select French over Spanish because of its greater influence on English over the last several centuries. But if Latin had been offered, I *certainly* would have chosen to take that instead of either Spanish or French. I definitely wanted to take Latin, and annoyed numerous people by saying so. Dead languages have always fascinated me. Alas, Latin was not an option.
But I made up for it in college by taking crosslisted seminary Greek (which fits nicely with the current topic, incidentally) for electives.
Perhaps some day I will take Sanskrit, and then when people boast about knowing Latin I can put them in their place