i know i picked it up like 10 years ago as a teen on anime irc chans. i don't think i've seen it in a true manga per se tho.. it's fanculture as far as i know.
It's not uncommon in Japanese manga, but I don't recall ever seeing it in English translations. It's more common in Japanese manga, where onomatopoeia is more vibrant. For example, you sometimes see things like "Wai~" (in Katakana, of course) for where we'd use "Wheeeee!".
SBC is the parent company of Southwestern Bell. It doesn't stand for anything. They also own one of the cell provider companies or something, and a few other companies.
MSNBC is a TV channel. Or maybe it's a website. I wasn't ever really sure.
It's not as though someone would deliberately insert code to broadcast a MAC address into a mail client.
No, not specifically. Here's the scoop.
Each email is supposed to have a unique Message-Id header. Other than logging and tracing, this is so that, when it's referenced by other emails via the In-Reply-To: and References: headers, the mail reader can properly thread the emails.
Second, there's a common unique ID format called the UUID. This is a 128-bit value that is unique across space and time until AD 3400. If you've looked at CLSIDs in Windows RegEdit, then you've seen UUIDs. (Windows calls them GUIDs.) They're also used in a lot of RPC-type protocols, in Mozilla plugins, and other places. One common way to generate a UUID incorporates the computer's MAC address as the last 48 bits, so that no two computers will generate the same UUID (assuming the MACs were properly registered), along with the clock time.
Since UUIDs are an easily-generated random number (lots of library routines to generate them, as well as the OS X uuidgen tool), that's what Mail used for its Message-Ids.
No, the OP was right. Out of 1800 marketroids, you can only harvest intelligence from 1500. The other 300 are beyond repair. But you can't tell the difference, so to get 1500 marketroids' intelligence (= 8 high-school students), you have to find 1800.
There's a "ringer equivalence" specification that indicates how much juice it takes to make the bell gong.
Yup. But the currents required aren't "standard" in the sense that all phones require the same current. (As far as that goes, ring voltage also varies wildly based on loop length and line load.) The load of a phone-- which is usually dominated by the ringer-- is measured as its REN, the Ringer Equivalence Number. That's the standard: one of labeling. The phone company tells you how many REN you're allowed to connect (usually 3 to 5). If you're allowed 5, you can connect 25 phones with an REN of 0.2. But I've heard tell of Korean phones with RENs of 3; if you connected two of those to your line, it might not ring (and may be considered always off-hook).
Fortunately, we know the REN of the type of phone we're talking about: the Western Electric Model 500. It's the yardstick for REN; it has an REN of 1.0. (Modern phones have specific tests to determine REN.)
Modern devices usually have comparatively low RENs. My new phone has an REN of 0.1, for instance, although it pulls its power from a power outlet instead of a landline. The Cellular Connection product to which the grandparent referred is designed to be a portable interface for things like credit card machines or modems, which typically have low RENs. So my question was, would it provide enough juice to drive a high-powered device too?
As it turns out, it does. A quick search didn't find the product on Motorola's website, but I did find a seller. The web page fortunately had the maximum REN that the product could drive: 3.0. This comes at a price, though: the battery life is only 2 hours.
I know this is more information than you probably wanted, but maybe this info will be of use to somebody who's thinking about the same thing.
Maybe, but do you know how much current it takes to ring an old, telco-owned rotary phone? We're talking about a pair of electromagnets the size of D cells here. I doubt that many devices designed to be portable would be able to supply enough to drive it.
I once found a TWO sheet screed in San Angelo, TX on how various corporate logos SECRET CONTAIN THE NUMBER OF THE BEAST, but that was a rare find.
I'm from San Angelo, and don't remember seeing this sort of thing stapled to telephone poles, let alone a 2-sheeter. (Contrast Austin.) Where was this find? I'm curious about what "culture of randomness" I've been missing.
I've been reading the documents involved, particularly the Ninth Circuit's decision and the **AA's petition for cert (request that the Supreme Court hear the case). It's been a while since I read Betamax, so I'll have to go back and read it next.
But quotes from the petition are sometimes thought-provoking, sometimes absurd. Most of the petition is **AA saying, "The Ninth Circuit misinterpreted Betamax! Look at the Seventh Circuit; they got it right!" Much of the arguments in the **AA's petition revolve around the argument that since the network could have been designed to block infringement, it should. (Personally, I doubt that the network could be so designed, since not even the mighty **AA has demonstrated an ability to effectively distinguish infringing uses. But most of the arguments have talked about the ability to block, rather than the technically more problematic ability to identify.)
One of the sidesplitters in the petition is this:
Similarly, under the Ninth Circuit's test a defendant's ability to block infringement is rendered irrelevant except in the narrowest circumstances.
The narrowest circumstances? The circumstances we have to consider are those on what we call planet Earth, not whatever alternative dimension that the **AA would like to live in. Indeed, the problem they have is that the "ability to block infringement" is only considered relevant if they actually, in real life do have such ability.
Oh, well, those are narrow circumstances indeed; we should instead consider if, in any imaginable world, they might have such an ability, and bend reality to match that world. Sorry, guys, we have to consider actual ability to block, not what they might have if they set themselves up exactly like Napster.
Most of the petition reads like this. The **AA feel that, because the network was designed without central control, that's evidence that they're guilty. It should have been designed with central control, and should prevent any infringing uses, because that would make the **AA happy. Because it's not designed that way, then Streamcast/Grokster are guilty of contributory and vicarious infringement.
The Ninth Circuit's opinion, by the way, is also a good read. Much less maddening than this petition, for sure.
Thanks for the info. While you did qualify this with "the C standard", I was mostly thinking of obscure systems when I qualified this. For example, on a system that predates prototypes, the value will generally get pushed onto the argument stack as an integer 0, but read off as an all-bits-zero pointer, which isn't necessarily a null pointer (but you already knew that).
"((void *) 0)" is tempting, and does occur in some C header files, but it's wrong!
Of course, in this case whether or not printf sees a null pointer here is academic anyway; the actual behavior of printf under these circumstances is, I believe, undefined.
Perhaps you're right. I actually don't care -- I only put in the alt tag to be standards compliant.
In that case, I apologize. You didn't say what you felt the bug was, and the most apparent difference was of the alt tag handling, so I assumed that's what you were referring to.
But the failure of Firefox to properly implement window.status is definitely a bug.
I suppose that's partially open to interpretation. The window object is not, as far as I know, part of any standard. It's a bit of a cop-out, but you could argue that, since it's not standardized, Firefox is still standards-conformant.
But that's a cop-out. Like others said, blocking window.status changes isn't a bug, it's a feature. Would you like to hover over a link that says "news.yahoo.com" in the status bar, but actually takes you to goatse? Neither would the Firefox developers, so they gave you an option to disable it, and default that option to disabled.
Mozilla has the same feature, as does Konqueror. Safari defaults to blocking window.status changes, but I don't know if there's an option for it.
Use it to access my resume and you'll find a really nasty Javascript bug. (The link to my email is generated on the fly, to hide it from spambots. The hover behavior works correctly in IE but not Firefox.)
I don't see any nasty bug in Firefox. I do see a minor bug in Internet Explorer, and some bad HTML design in that code.
The IE bug is that it displays, when you hover over the image, "click here to send me email". It is getting that from the alt tag on your image, and shouldn't. The alt tag is to "specify alternate text to serve as content when the element cannot be rendered normally". However, the image is being rendered normally, so IE shouldn't be rendering that tag. If there were a title tag, it should render that, though.
Now, think about why the alt attribute is mandatory on img elements. It's to achieve device independence. When somebody isn't loading images (because they're blind and using a screen reader, or using a cellphone or other low-bandwidth device, or because they haven't started X and are using lynx, or for whatever reason) then they should be able to get a coherent web page. The web community has been trying for years to get authors to include alt tags; they wrote the accessibility guidelines mostly just to be able to officially say to include alt tags. Finally, in HTML 4, the alt tag was made mandatory.
So, what's the point of your alt tag? It doesn't replace the image in a non-image setting. In fact, in most cases when there are no images (blind, cellphone, lynx, etc) there is no mouse, so your replacement text is usually inappropriate. In some such cases, there may not even be JavaScript. (You can handle that gracefully too.)
Now, suppose I saw your sig and was considering hiring you. One thing I'd do is to check your resume. I see that you spent most of your career as a tech writer, and still can't think about the range of your audience. Since (in this hypothesis) I saw your sig on/., I'd check your posting history and see your post. Here, you flame about a "really nasty JavaScript bug" which, as far as I can tell, has nothing to do with JavaScript, and is also not a bug but a correct implementation of the XHTML spec. You claim to be qualified in XHTML, but don't understand something as simple and well-documented as the purposes of alt vs title. Did you never actually read the XHTML spec? What gave you the idea that alt should provide tooltips? Mr. Rabinovitch, why (in this hypothesis) should I continue to consider you?
That's a rhetorical question, by the way. I don't care about hiring you; my team is currently full of people who do think about cross-compatibility, and read documentation, and understand their tools. I'm just telling you that you've done yourself a disservice in posting this. If I were you, I'd think about fixing that resume webpage before somebody also thinks that you don't learn from your mistakes.
When you write lots of smaller modules, each one can be create a single, small TEXT and DATA section, or a collection of small code sections. This makes the job of memory mapping in virtual memory systems much easier. Do it all as one big thing, and you're liable to get one big TEXT section.
That's the only one I don't buy. The individual text sections-- if they're even separate after ld is done with it-- will get merged into one big text section (along with the data and bss) when they're loaded into memory, and so the VM only has to deal with a range of pages, regardless of where the section boundaries were.
The rest of your arguments were fine, and were why I cursed at my predecessors at my first real programming job.
iTunes reports 44.1khz, 16 bit Stereo.wav and.aiff files to be 1411kbps.
We're talking about the same number here: 1.41e6 bits/sec. It appears that iTunes is basing their numbers on kilobit=1000 bits. Since I had been comparing to a value based on that 150KB/s number, in which 1KB=1024 bytes, I used 1024 instead, hence 1378.
Slashdot Mirror
It's the off-topic sig thread! Wai~!
"onward!" cried the copper man, little knowing brass corrupts...
I surrender a geek point and request an explanation of this joke.
i know i picked it up like 10 years ago as a teen on anime irc chans. i don't think i've seen it in a true manga per se tho.. it's fanculture as far as i know.
It's not uncommon in Japanese manga, but I don't recall ever seeing it in English translations. It's more common in Japanese manga, where onomatopoeia is more vibrant. For example, you sometimes see things like "Wai~" (in Katakana, of course) for where we'd use "Wheeeee!".
No, he just picked it up from manga. I'm not exactly sure how you pronounce "that~", though.
If you track the trades
How do you do that?
If only it had more than the first page.
Mirrordot shows me the same "Problem in Database Connection" page.
Keeping it quiet? sbc.com has a box on the front page with the SBC and AT&T logos, linking to sbc.merger-news.com.
Is this the way that Gengis Khan kept his real estate aquisitions quiet?
SBC is the parent company of Southwestern Bell. It doesn't stand for anything. They also own one of the cell provider companies or something, and a few other companies.
MSNBC is a TV channel. Or maybe it's a website. I wasn't ever really sure.
AT&T is a modem test command.
Lessee, 12:00: lunch with Mike, 13:00: complete TPS reports, 14:00: relinquish all world power to the cybernetic race...
The solution he proposes can be thought of in two ways. One is to look at it a shortcut keys of infinate length.
How is this different than M-x in Emacs?
It's not as though someone would deliberately insert code to broadcast a MAC address into a mail client.
No, not specifically. Here's the scoop.
Each email is supposed to have a unique Message-Id header. Other than logging and tracing, this is so that, when it's referenced by other emails via the In-Reply-To: and References: headers, the mail reader can properly thread the emails.
Second, there's a common unique ID format called the UUID. This is a 128-bit value that is unique across space and time until AD 3400. If you've looked at CLSIDs in Windows RegEdit, then you've seen UUIDs. (Windows calls them GUIDs.) They're also used in a lot of RPC-type protocols, in Mozilla plugins, and other places. One common way to generate a UUID incorporates the computer's MAC address as the last 48 bits, so that no two computers will generate the same UUID (assuming the MACs were properly registered), along with the clock time.
Since UUIDs are an easily-generated random number (lots of library routines to generate them, as well as the OS X uuidgen tool), that's what Mail used for its Message-Ids.
Later versions of the UUID spec
No, the OP was right. Out of 1800 marketroids, you can only harvest intelligence from 1500. The other 300 are beyond repair. But you can't tell the difference, so to get 1500 marketroids' intelligence (= 8 high-school students), you have to find 1800.
There's a "ringer equivalence" specification that indicates how much juice it takes to make the bell gong.
Yup. But the currents required aren't "standard" in the sense that all phones require the same current. (As far as that goes, ring voltage also varies wildly based on loop length and line load.) The load of a phone-- which is usually dominated by the ringer-- is measured as its REN, the Ringer Equivalence Number. That's the standard: one of labeling. The phone company tells you how many REN you're allowed to connect (usually 3 to 5). If you're allowed 5, you can connect 25 phones with an REN of 0.2. But I've heard tell of Korean phones with RENs of 3; if you connected two of those to your line, it might not ring (and may be considered always off-hook).
Fortunately, we know the REN of the type of phone we're talking about: the Western Electric Model 500. It's the yardstick for REN; it has an REN of 1.0. (Modern phones have specific tests to determine REN.)
Modern devices usually have comparatively low RENs. My new phone has an REN of 0.1, for instance, although it pulls its power from a power outlet instead of a landline. The Cellular Connection product to which the grandparent referred is designed to be a portable interface for things like credit card machines or modems, which typically have low RENs. So my question was, would it provide enough juice to drive a high-powered device too?
As it turns out, it does. A quick search didn't find the product on Motorola's website, but I did find a seller. The web page fortunately had the maximum REN that the product could drive: 3.0. This comes at a price, though: the battery life is only 2 hours.
I know this is more information than you probably wanted, but maybe this info will be of use to somebody who's thinking about the same thing.
Pulse dialing will slowly stop working on analog phone lines over the next few years or so...
It wasn't until last year that they stopped charging me for touch-tone!
Maybe, but do you know how much current it takes to ring an old, telco-owned rotary phone? We're talking about a pair of electromagnets the size of D cells here. I doubt that many devices designed to be portable would be able to supply enough to drive it.
I once found a TWO sheet screed in San Angelo, TX on how various corporate logos SECRET CONTAIN THE NUMBER OF THE BEAST, but that was a rare find.
I'm from San Angelo, and don't remember seeing this sort of thing stapled to telephone poles, let alone a 2-sheeter. (Contrast Austin.) Where was this find? I'm curious about what "culture of randomness" I've been missing.
I've been reading the documents involved, particularly the Ninth Circuit's decision and the **AA's petition for cert (request that the Supreme Court hear the case). It's been a while since I read Betamax, so I'll have to go back and read it next.
But quotes from the petition are sometimes thought-provoking, sometimes absurd. Most of the petition is **AA saying, "The Ninth Circuit misinterpreted Betamax! Look at the Seventh Circuit; they got it right!" Much of the arguments in the **AA's petition revolve around the argument that since the network could have been designed to block infringement, it should. (Personally, I doubt that the network could be so designed, since not even the mighty **AA has demonstrated an ability to effectively distinguish infringing uses. But most of the arguments have talked about the ability to block, rather than the technically more problematic ability to identify.)
One of the sidesplitters in the petition is this:
Similarly, under the Ninth Circuit's test a defendant's ability to block infringement is rendered irrelevant except in the narrowest circumstances.
The narrowest circumstances? The circumstances we have to consider are those on what we call planet Earth, not whatever alternative dimension that the **AA would like to live in. Indeed, the problem they have is that the "ability to block infringement" is only considered relevant if they actually, in real life do have such ability.
Oh, well, those are narrow circumstances indeed; we should instead consider if, in any imaginable world, they might have such an ability, and bend reality to match that world. Sorry, guys, we have to consider actual ability to block, not what they might have if they set themselves up exactly like Napster.
Most of the petition reads like this. The **AA feel that, because the network was designed without central control, that's evidence that they're guilty. It should have been designed with central control, and should prevent any infringing uses, because that would make the **AA happy. Because it's not designed that way, then Streamcast/Grokster are guilty of contributory and vicarious infringement.
The Ninth Circuit's opinion, by the way, is also a good read. Much less maddening than this petition, for sure.
Thanks for the info. While you did qualify this with "the C standard", I was mostly thinking of obscure systems when I qualified this. For example, on a system that predates prototypes, the value will generally get pushed onto the argument stack as an integer 0, but read off as an all-bits-zero pointer, which isn't necessarily a null pointer (but you already knew that).
"((void *) 0)" is tempting, and does occur in some C header files, but it's wrong!
Actually, it is allowable under ANSI C; see the comp.lang.c FAQ, sec 5.6, or the Rationale, sec 4.1.5.
Of course, in this case whether or not printf sees a null pointer here is academic anyway; the actual behavior of printf under these circumstances is, I believe, undefined.
If you think that extensible programming languages aren't already here, then read On Lisp (some familiarity with Lisp is necessary).
At a guess, it segfaults when printf tries to read its formatting string and gets (on most platforms) a null pointer instead.
FFS not everything remotely related to the web is a tag! You are talking about an attribute of the img element type, not a tag. The alt attribute.
Hence my more precise phrasing in the next paragraph. I hope that my more lax terminology in the first paragraph didn't confuse you.
Perhaps you're right. I actually don't care -- I only put in the alt tag to be standards compliant.
In that case, I apologize. You didn't say what you felt the bug was, and the most apparent difference was of the alt tag handling, so I assumed that's what you were referring to.
But the failure of Firefox to properly implement window.status is definitely a bug.
I suppose that's partially open to interpretation. The window object is not, as far as I know, part of any standard. It's a bit of a cop-out, but you could argue that, since it's not standardized, Firefox is still standards-conformant.
But that's a cop-out. Like others said, blocking window.status changes isn't a bug, it's a feature. Would you like to hover over a link that says "news.yahoo.com" in the status bar, but actually takes you to goatse? Neither would the Firefox developers, so they gave you an option to disable it, and default that option to disabled.
Mozilla has the same feature, as does Konqueror. Safari defaults to blocking window.status changes, but I don't know if there's an option for it.
Use it to access my resume and you'll find a really nasty Javascript bug. (The link to my email is generated on the fly, to hide it from spambots. The hover behavior works correctly in IE but not Firefox.)
I don't see any nasty bug in Firefox. I do see a minor bug in Internet Explorer, and some bad HTML design in that code.
The IE bug is that it displays, when you hover over the image, "click here to send me email". It is getting that from the alt tag on your image, and shouldn't. The alt tag is to "specify alternate text to serve as content when the element cannot be rendered normally". However, the image is being rendered normally, so IE shouldn't be rendering that tag. If there were a title tag, it should render that, though.
Now, think about why the alt attribute is mandatory on img elements. It's to achieve device independence. When somebody isn't loading images (because they're blind and using a screen reader, or using a cellphone or other low-bandwidth device, or because they haven't started X and are using lynx, or for whatever reason) then they should be able to get a coherent web page. The web community has been trying for years to get authors to include alt tags; they wrote the accessibility guidelines mostly just to be able to officially say to include alt tags. Finally, in HTML 4, the alt tag was made mandatory.
So, what's the point of your alt tag? It doesn't replace the image in a non-image setting. In fact, in most cases when there are no images (blind, cellphone, lynx, etc) there is no mouse, so your replacement text is usually inappropriate. In some such cases, there may not even be JavaScript. (You can handle that gracefully too.)
Now, suppose I saw your sig and was considering hiring you. One thing I'd do is to check your resume. I see that you spent most of your career as a tech writer, and still can't think about the range of your audience. Since (in this hypothesis) I saw your sig on /., I'd check your posting history and see your post. Here, you flame about a "really nasty JavaScript bug" which, as far as I can tell, has nothing to do with JavaScript, and is also not a bug but a correct implementation of the XHTML spec. You claim to be qualified in XHTML, but don't understand something as simple and well-documented as the purposes of alt vs title. Did you never actually read the XHTML spec? What gave you the idea that alt should provide tooltips? Mr. Rabinovitch, why (in this hypothesis) should I continue to consider you?
That's a rhetorical question, by the way. I don't care about hiring you; my team is currently full of people who do think about cross-compatibility, and read documentation, and understand their tools. I'm just telling you that you've done yourself a disservice in posting this. If I were you, I'd think about fixing that resume webpage before somebody also thinks that you don't learn from your mistakes.
When you write lots of smaller modules, each one can be create a single, small TEXT and DATA section, or a collection of small code sections. This makes the job of memory mapping in virtual memory systems much easier. Do it all as one big thing, and you're liable to get one big TEXT section.
That's the only one I don't buy. The individual text sections-- if they're even separate after ld is done with it-- will get merged into one big text section (along with the data and bss) when they're loaded into memory, and so the VM only has to deal with a range of pages, regardless of where the section boundaries were.
The rest of your arguments were fine, and were why I cursed at my predecessors at my first real programming job.
iTunes reports 44.1khz, 16 bit Stereo .wav and .aiff files to be 1411kbps.
We're talking about the same number here: 1.41e6 bits/sec. It appears that iTunes is basing their numbers on kilobit=1000 bits. Since I had been comparing to a value based on that 150KB/s number, in which 1KB=1024 bytes, I used 1024 instead, hence 1378.