I believe this is denser than uranium. Is Israel planning to eventually build specially equipped armored vehicles?
Correct, Rt is 111, U is 92.
My first thought was along the same lines; replacing depleted uranium with stable Roentgenium would be safer, more politically acceptable, and perhaps even cheaper.
... my second thought is that this is too good to be true; it flies in the face of a lot of established assumptions on the elements and its proof could lead to some large revisions to how we understand things work. Occam's razor suggests this is too improbable to be true.
'You can put your box inside a printer tray and glue it shut, and who will notice if there are one or two or three power cables coming out?'
I, for one, would certainly notice THAT. But who in the corporate world would notice or even care?
No you wouldn't. For an extra ~$20 or so, the attacker could put a power splitter and network switch inside the box, making it just one power cable and one network cable. Given how trivial that is, any real attacker (as in a person or group expecting a hefty profit on the operation) would go that extra step. Security groups are more budget-constrained (they also proved that you don't need that level of sophistication for most targets).
It should also be rather simple to use an embedded computer that controls the printer and is powered by the printer's PSU (this would let you save copies of every printed, faxed, and copied document and send them to an off-site haven whenever it is deemed most convenient/safe. This sort of system wouldn't really be suspect even if opened up; of course it has a controller board. The fact that it's aftermarket can be explained by its lower cost (which department paid for it again? It just seemed to show up one day...).
This isn't limited to printers; you can do this with any network-enabled appliance, be it a printer, file server, firewall, wifi system, etc. Just phone the company and say you're an authorized reseller of the product and that you'd like to offer them a free 90-day evaluation and then never show up to reclaim it (or actually sell it to them for a ridiculously low price claiming that you need the sale to hit your quarterly quota). Most of these appliances are full-featured x86 servers anyway, and it's quite unlikely that somebody would notice your rootkit or stealth processes.
This also isn't limited to the device itself; once you're in the network, you can seize a few Windows systems and use them instead. This lets you take the device back at the end of the free trial. With a netbook or other embedded system (e.g. a smartphone with an ethernet adapter), you could do this while in the office on a tour or while pretending to deliver a package or use the bathroom (assuming you're not chaperoned).
The United States Court of Appeals for the Fifth Circuit has vacated a judgment restraining Parsons Technology Inc. from selling and distributing Quicken Family Lawyer Version 8.0 and Quicken Family Lawyer '99 legal software within the State of Texas.
Maintainability: It's hard to maintain a system that has billions of different iterations — "billions" might be an understatement; your typical system has one to two thousand packages installed. If half of them get a nontrivial update every month (which is a pretty conservative estimate), that's still 125 million (500^3) combinations each quarter. The easiest solution to this isn't a very user-friendly one; make internal 'milestone' markers and force upgrades that would push beyond them to incrementally hit each one before coming up to speed (this also has the pleasant side-effect of leaving a system stable at a more updated place than where it was rather than chunking through an upgrade that fails part-way through). Ubuntu could move to this model immediately (it's already there; each milestone would merely be an unannounced LTS (long-term support) release... Server Edition would probably move to publishing LTS exclusively).
The big hurdle is how to determine that an update failed; just because the software looks intact and post-install scripts succeed doesn't mean that hardware support wasn't retracted or that things don't play nice. Some smoke-tests are needed, compatibility must be itemized, and a big decision must be made about what to do with people who can't (or won't) upgrade past a certain point. I think the milestones are a good solution there, but that's assuming the LTS model will be continued.
Debian Testing: Unless Debian is frozen for an upcoming stable release, Debian Testing is a rolling release. I often wish that Debian would fork the Testing repo with that freeze rather than once it's fully released as stable (which would create a new name, perhaps "beta"), though I understand the limited resources for both developers and testers (those of us using Testing). Given the relationship between the two projects, I wonder what Ubuntu Rolling v. Debian Testing will do, and how they'll differentiate themselves...
hm, that's a really old story (I had assumed it was new because I saw I somewhere else today as well) dating back to 2005. Here's the full abstract with links to the full paper in PDF: http://www.cs.washington.edu/homes/yoshi/papers/PDF/
I see no sample code, and the paper was too verbose for me to quickly skim to find how it does its measurements, but the conclusion sticks out a bit:
Although the techniques we described will likely remain applicable to current generation systems, we suspect that future generation security systems might offer countermeasures to resist some of the finger-printing techniques that we uncover.
I think five years counts as more than fair with respect to a 'future generation' or two. Even if the paper was being overly optimistic about its own impact (which was probably the case...), system bus speeds have radically improved since the Pentium 4's quad-pumped 100MHz and the CPU die size shrank from 90nm to 45nm and are about to hit 32nm; it remains unclear whether or not those and similar improvements have increased the clock precision to a level that is surpassed by noise that might render this fingerprinting method ineffective.
Unless I'm reading this the wrong way, evercookies can exist because of flaws in HTML processing. So, why not do something to fill that hole instead of sticking a band-aid on it in the form of Nevercookie?
Flash isn't Mozilla's fault, so Firefox can't "fix" its persistent cookies (though you can nuke Flash cookies with cron).
As to the HTML5 pieces... it's typical that an add-on implements something before Mozilla proper. This serves as a proof-of-concept and side-steps the pains of the Mozilla Foundation's development cycle. It also serves as a way to prove desirability. There's nothing preventing this from getting pushed into the Mozilla core later on. I hope it does.
NTP solves that issue. If you're extra paranoid, sync your clock more often. If you're extra extra paranoid disable your ntp daemon and put this in root's crontab instead:
This syncs your clock every fifteen minutes with a random delay of fifteen minutes. It is also overkill.
Also note that while tor continues to be slow as molasses, its latency may help defeat this kind of identification for any properly synched system clock.
The biggest problem is in off-the-shelf appliances (like wifi routers) for the whole spectrum (from personal to enterprise); they don't have domain names, so you can't have an internal CA root blessing them (at least, not out of the box), and a non-enterprise location can't easily do that.
One solution could be to bundle a CA root into the router. Initial setup would involve picking an internal TLD (with a randomly generated suggestion so we don't have everybody using "home" or "linksys"), then the CA root certificate is generated for that TLD. New appliances would have to somehow register with that CA, and for proper security, this would have to be approved by the human setting it up, but this could conceivably be streamlined.
I'm actually surprised this problem isn't solved via workaround; properly-encrypted wifi doesn't really need SSL (though a MitM attack is possible for the first connection since the AP MAC isn't yet known), and everything seems to be moving to wifi.
I'd also like to see an extension to USB Mass Storage devices that puts a tiny CGI-enabled web browser in the "filesystem" that enables configuration. Since you're plugged in, security is easier.
How is this different from defining it by an artifact locked up beyond your reach? We have the technology to make such precise measurements on all of those fronts, and you'll have to entrust it to experts at a standards body either way you slice it.
Funnily enough I never ever think of a kilogram as the weight of some standard weight in a vault somewhere. The only way I ever think about the kilogram is the weight of one liter of water. Also comes in handy when I'm calculating how much liquids I can afford to buy when shopping groceries, given that I often go to the store on foot for the exercise and have to make sure I can manage the haul back.
Water is where the standard came from, but for one reason or another, it was replaced by that platinum brick. I think we now have the scientific expertise to return that that definition. I'd certainly prefer that as well, as it reduces the number of independently defined bases (like the five postulates of Euclid's Elements).
The NIST article has two conflicting statements on that front:
The definitions of the ampere (electric current), mole (amount of substance) and candela (luminous intensity) ultimately depend on the platinum-iridium artifact. For example, a mole is currently defined as the number of carbon-12 atoms whose total mass is 12 grams.
but later, it says
The seven SI base units from which all others are derived are the second (time), the meter (length), the kilogram (mass), the ampere (electric current), the kelvin (thermodynamic temperature), the mole (amount of substance) and the candela (luminous intensity).
So amperes and moles are defined by a (kilo)gram and are therefore not independent. I would assume, based on that second quote, that each of those SI base units was independent...
If grams were once again derived from meters, those "seven" SI base units would actually be four.
Adults need fancy chairs because they've abused their bodies over time and their bodies can't adapt as quickly. Children are extremely adaptable and their plasticity should enable them to sit on rocks. Therefore, it is merely a cost issue. Since children tend to stick gum under desks, carve into their tops, and bowl them all over the place, they needn't be built to last the test of time. They need to be robust enough to tolerate a decent about of abuse and then get replaced in a few years.
If you're now thinking that better chairs would prevent that body abuse in adults, I'd argue that you're misguided there, too. It's a posture and ergonomics issue more than anything else.
Disclaimer: I don't subscribe to the need for $700 chairs. My Staples Berwell Luxura Task Chair was $90 and is, in many ways, just as comfortable (though not as adjustable) as chairs that cost 2-5 times as much. It does everything I need it to do. If it falls apart or is destroyed, I'll buy another. I've been in a lot of fancy offices and labs with a lot of really nice (and expensive) chairs. The Berwell isn't as nice, but it's 90% of the way there and simply precludes any reason for me to consider something over the $100 price point.
Another major contributor to this crap is their bad statistics. This is a law of small numbers, similar to when a baseball player is batting.500 early in the season (a.400 season's average is godly). There isn't enough data to make that a meaningful number. TLDs like.VN are very small quantities, so they are easily overrun by a few spammers buying their typical bulk quantities of spamvertising domains.
Reports like this can accidentally suggest dangerous blanket blacklisting. I think it's far better to use the more sophisticated systems of IP reputation (URIBLs in this case). That said, organizations that bring legal pressure to improperly relaxed registrars need this kind of data to move forward. Knujon ("no junk" backwards) is doing this, though their efforts are mostly restricted to the USA.
A year ago, some MIT undergrads wrote up a short piece called Project Gaydar which showcased how they were able to successfully identify gay men who were still in the closet.
Facebook might not expose this information directly (via the "sexual preferences" profile information), but your friends list is enough to extrapolate it. Since there's money in that kind of data and it is easily fetched via the Facebook API, it's being done.
Interesting, Debian has chromium-browser (the brand-stripped chrome that lacks some of the phone-home features) in its experimental repository as 7.0.544.0~r61416-1 while Google's apt repository is featuring 7.0.517.41-r62167 as both beta and stable (unstable has moved to 8.0.552.5-r62886). Unless I'm mistaken, those version numbers are composed of [version]~[VCS revision]-[package version] and chromium-browser's versions are pinned to their equivalent google-chrome version. That makes the current versions rather peculiar since Debian's (older) 544 is higher than Google's current 517 while the Debian's VCS revision 61416 is (as expected) earlier than Google's 62167.
ESP and Experimental College are example models for wiki-style universities; anybody can teach whatever they want at either of those schools (with or without a PhD). Tufts undergrads even get credits for the courses they take at the Experimental College.
JPEG2000 is an example of basic research, though also an example of some of the hurdles faced by it when not funded by corporate interests. A large number of startups come from basic research projects that grew up (sorry, I don't have the time to look up some better examples here).
Most people forget about the basic research performed by most universities, which is absolutely necessary to the academic industry and flows into every aspect of the rest of the world (especially including tech, medical, and military). A good deal of the criticism on the current system comes from a lack of understanding of basic research and its part in academia. While the Wikipedia-style likely has merits for far more than we currently expect (it was equally ill-received when proposed for encyclopedias!), it can't fit into our current paradigm of research universities while retaining the current organization of journals and how they handle submissions (which is another point of contention that needs a serious upgrade of its own).
Therefore, perhaps the part-time lecturer model is preferable as a starting-point. However, due to its for-profit (not to mention anticompetitive and controversial) nature, Phoenix is not an appropriate role model.
Take a look at examples that are already far closer to Wikipedia, like MIT's ESP and Tuft's Experimental College.
Hasn't the US Department of Defense fully moved to IPv6? It shouldn't need any more than a single block (really, not even that much) of IPv4, yet they still have the following eleven/8 blocks: 7, 11, 21, 22, 26, 28, 29, 30, 33, 214, and 215. The US Army also has 6 and 55 and the US Postal Service (USPS) has 56. That's a LOT of unused IPs.
As reported by Wired on 2009-09-23 in the story 1 Million Spiders Make Golden Silk for Rare Cloth. Fascinating read, especially if you're like me and wholly entranced by the concept of a super-fiber like spider silk.
I'm a SpamAssassin developer, both on the official project and on a commercial derivative. Others on my commercial team independently verified my claim as well. I highly doubt we're all wrong.
That said, I decided to FULLY dig into the issue to see what's going on under the hood. In addition to a careful analysis of the spamassassin debug output, I spun up Wireshark to look at the actual DNS queries. Since SA knows what example.com is ([84234] dbg: uridnsbl: domain example.com in skip list), I had to use something else. I ran two tests: one on a nonexistant domain as separated by the SHY character in a manner that doesn't result in delimiting the latter portion into an existing domain, and then one as a heavily-spammed domain with a SHY character again breaking it into a nonexisting domain.
Analysis: Debug output from SA 3.3.1 and SVN trunk (rev 1005948, build reports version as 3.4.0-r929098) displays the SHY character (which my terminal renders as a space but after a paste, my browser does not) and uses \255 in its DNS lookups (older versions display it as \173 and I didn't capture the raw lookups). In addition to looking for the domain with the SHY character, it also queries without the SHY character. My live test confirmed a hit in URIBL for the defanged domain and no hit for the obfuscated one (I didn't test a real sample of the obfuscation -- presumably, the blocklists can learn the obfuscated domain in addition to the defanged one). I see no reference to the IDN syntax you mentioned.
A sample of the debug output (tweaked to convert the SHY to a space so it is distinguishable on the web):
$ grep obinemedic ~/url.eml.output |grep -i uribl |sed 's/r.obin/r obin/'
Oct 8 15:06:55.950 [1570] dbg: dns: providing a callback for id: 64792/r obinemedic.ru.multi.uribl.com/A/IN
Oct 8 15:06:55.950 [1570] dbg: async: starting: URI-DNSBL, DNSBL:multi.uribl.com.:r obinemedic.ru (timeout 15.0s, min 3.0s)
Oct 8 15:06:55.955 [1570] dbg: dns: providing a callback for id: 40779/robinemedic.ru.multi.uribl.com/A/IN
Oct 8 15:06:55.955 [1570] dbg: async: starting: URI-DNSBL, DNSBL:multi.uribl.com.:robinemedic.ru (timeout 15.0s, min 3.0s)
Oct 8 15:06:55.985 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_DBL_SPAM): 127.0.1.2
Oct 8 15:06:55.987 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_AB_SURBL): 127.0.0.102
Oct 8 15:06:55.988 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_WS_SURBL): 127.0.0.102
Oct 8 15:06:55.988 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_JP_SURBL): 127.0.0.102
Oct 8 15:06:55.989 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_SC_SURBL): 127.0.0.102
Oct 8 15:06:56.121 [1570] dbg: async: completed in 0.162 s: URI-DNSBL, DNSBL:multi.uribl.com.:robinemedic.ru
Oct 8 15:06:56.121 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_BLACK): 127.0.0.2
Oct 8 15:06:56.122 [1570] dbg: async: completed in 0.167 s: URI-DNSBL, DNSBL:multi.uribl.com.:r obinemedic.ru
Oct 8 15:06:57.980 [1570] dbg: async: timing: 0.162 . DNSBL:multi.uribl.com.:robinemedic.ru
Oct 8 15:06:57.980 [1570] dbg: async: timing: 0.167 . DNSBL:multi.uribl.com.:r obinemedic.ru
Just tested this in SpamAssassin with http://exa ­ mple.com (spaced to evade slashdot's own obfuscation-eliminator) - Result: The URL domain (example.com) is properly extracted without the obfuscation.
That said, SA is fully capable of detecting the obfuscation attempt itself (using a rawbody rule)...
You don't need an accelerometer; the phone already knows its location is moving due to its interactions with the towers (or GPS). However, there's no way to determine that the person using the phone isn't a passenger (or riding a bus or streetcar... a train can be detected by the fact that it's not on a road).
Consider this: a law that requires new cars to include bluetooth speakerphones that automatically connect when the car is turned on (yes, it requires the driver to pair a bluetooth-capable phone, but who wouldn't?). This would reduce the issue of only one hand on the wheel and its tether would allow the phone to know that its user is driving. Now there are several options, such as text-to-speech (and vice-versa) as well as phone software that limits time on the phone in one manner or other (limits texting composition time, splits incoming messages into smaller chunks and then prevents your checking them too quickly, etc).
Another law idea (complementary or stand-alone): accidents caused by driver negligence due to texting have harsher penalties... make it the same as DUI. No reason not to also put cellphone handset issues here too. Note that this will be difficult to "prove" in court, but I think it's a start.
find.adobe.macromedia -type f -mtime +1 2>/dev/null |xargs rm -f
I forgot to mention what that does. It searches your.adobe and.macromedia directories for all files older than one day, ignores errors, and then removes the hits, ignoring failures like those from an empty file list.
Because I use ac power as a prerequisite for several cron tasks, I've actually worked the acpitool command into its own shell script, but I wanted to keep it simple for this post.
I've posted on this before, but here's an update based on some info from that link, hopefully doing a better job of limiting the damage from blowing away actively used LSOs:
Slashdot Mirror
I believe this is denser than uranium. Is Israel planning to eventually build specially equipped armored vehicles?
Correct, Rt is 111, U is 92.
My first thought was along the same lines; replacing depleted uranium with stable Roentgenium would be safer, more politically acceptable, and perhaps even cheaper.
... my second thought is that this is too good to be true; it flies in the face of a lot of established assumptions on the elements and its proof could lead to some large revisions to how we understand things work. Occam's razor suggests this is too improbable to be true.
'You can put your box inside a printer tray and glue it shut, and who will notice if there are one or two or three power cables coming out?'
I, for one, would certainly notice THAT. But who in the corporate world would notice or even care?
No you wouldn't. For an extra ~$20 or so, the attacker could put a power splitter and network switch inside the box, making it just one power cable and one network cable. Given how trivial that is, any real attacker (as in a person or group expecting a hefty profit on the operation) would go that extra step. Security groups are more budget-constrained (they also proved that you don't need that level of sophistication for most targets).
It should also be rather simple to use an embedded computer that controls the printer and is powered by the printer's PSU (this would let you save copies of every printed, faxed, and copied document and send them to an off-site haven whenever it is deemed most convenient/safe. This sort of system wouldn't really be suspect even if opened up; of course it has a controller board. The fact that it's aftermarket can be explained by its lower cost (which department paid for it again? It just seemed to show up one day...).
This isn't limited to printers; you can do this with any network-enabled appliance, be it a printer, file server, firewall, wifi system, etc. Just phone the company and say you're an authorized reseller of the product and that you'd like to offer them a free 90-day evaluation and then never show up to reclaim it (or actually sell it to them for a ridiculously low price claiming that you need the sale to hit your quarterly quota). Most of these appliances are full-featured x86 servers anyway, and it's quite unlikely that somebody would notice your rootkit or stealth processes.
This also isn't limited to the device itself; once you're in the network, you can seize a few Windows systems and use them instead. This lets you take the device back at the end of the free trial. With a netbook or other embedded system (e.g. a smartphone with an ethernet adapter), you could do this while in the office on a tour or while pretending to deliver a package or use the bathroom (assuming you're not chaperoned).
US Court Of Appeals Lifts Texas Ban On Sales Of Quicken Family Lawyer (one of the first hits in a search for "quicken family lawyer texas" sans quotes) states:
The United States Court of Appeals for the Fifth Circuit has vacated a judgment restraining Parsons Technology Inc. from selling and distributing Quicken Family Lawyer Version 8.0 and Quicken Family Lawyer '99 legal software within the State of Texas.
Maintainability: ... Server Edition would probably move to publishing LTS exclusively).
It's hard to maintain a system that has billions of different iterations — "billions" might be an understatement; your typical system has one to two thousand packages installed. If half of them get a nontrivial update every month (which is a pretty conservative estimate), that's still 125 million (500^3) combinations each quarter. The easiest solution to this isn't a very user-friendly one; make internal 'milestone' markers and force upgrades that would push beyond them to incrementally hit each one before coming up to speed (this also has the pleasant side-effect of leaving a system stable at a more updated place than where it was rather than chunking through an upgrade that fails part-way through). Ubuntu could move to this model immediately (it's already there; each milestone would merely be an unannounced LTS (long-term support) release
The big hurdle is how to determine that an update failed; just because the software looks intact and post-install scripts succeed doesn't mean that hardware support wasn't retracted or that things don't play nice. Some smoke-tests are needed, compatibility must be itemized, and a big decision must be made about what to do with people who can't (or won't) upgrade past a certain point. I think the milestones are a good solution there, but that's assuming the LTS model will be continued.
Debian Testing:
Unless Debian is frozen for an upcoming stable release, Debian Testing is a rolling release. I often wish that Debian would fork the Testing repo with that freeze rather than once it's fully released as stable (which would create a new name, perhaps "beta"), though I understand the limited resources for both developers and testers (those of us using Testing). Given the relationship between the two projects, I wonder what Ubuntu Rolling v. Debian Testing will do, and how they'll differentiate themselves...
Here's a paper from 2007 (two years after the one we're discussing) demonstrating how to mask your skew: Skewmask: Frustrating Clock Skew Fingerprinting Attempts
hm, that's a really old story (I had assumed it was new because I saw I somewhere else today as well) dating back to 2005. Here's the full abstract with links to the full paper in PDF: http://www.cs.washington.edu/homes/yoshi/papers/PDF/
I see no sample code, and the paper was too verbose for me to quickly skim to find how it does its measurements, but the conclusion sticks out a bit:
Although the techniques we described will likely remain applicable to current generation systems, we suspect that future generation security systems might offer countermeasures to resist some of the finger-printing techniques that we uncover.
I think five years counts as more than fair with respect to a 'future generation' or two. Even if the paper was being overly optimistic about its own impact (which was probably the case...), system bus speeds have radically improved since the Pentium 4's quad-pumped 100MHz and the CPU die size shrank from 90nm to 45nm and are about to hit 32nm; it remains unclear whether or not those and similar improvements have increased the clock precision to a level that is surpassed by noise that might render this fingerprinting method ineffective.
Unless I'm reading this the wrong way, evercookies can exist because of flaws in HTML processing. So, why not do something to fill that hole instead of sticking a band-aid on it in the form of Nevercookie?
Flash isn't Mozilla's fault, so Firefox can't "fix" its persistent cookies (though you can nuke Flash cookies with cron).
As to the HTML5 pieces ... it's typical that an add-on implements something before Mozilla proper. This serves as a proof-of-concept and side-steps the pains of the Mozilla Foundation's development cycle. It also serves as a way to prove desirability. There's nothing preventing this from getting pushed into the Mozilla core later on. I hope it does.
NTP solves that issue. If you're extra paranoid, sync your clock more often. If you're extra extra paranoid disable your ntp daemon and put this in root's crontab instead:
SHELL=/bin/bash
*/15 * * * * sleep $(($RANDOM%900)) && ntpdate pool.ntp.org
This syncs your clock every fifteen minutes with a random delay of fifteen minutes. It is also overkill.
Also note that while tor continues to be slow as molasses, its latency may help defeat this kind of identification for any properly synched system clock.
The biggest problem is in off-the-shelf appliances (like wifi routers) for the whole spectrum (from personal to enterprise); they don't have domain names, so you can't have an internal CA root blessing them (at least, not out of the box), and a non-enterprise location can't easily do that.
One solution could be to bundle a CA root into the router. Initial setup would involve picking an internal TLD (with a randomly generated suggestion so we don't have everybody using "home" or "linksys"), then the CA root certificate is generated for that TLD. New appliances would have to somehow register with that CA, and for proper security, this would have to be approved by the human setting it up, but this could conceivably be streamlined.
I'm actually surprised this problem isn't solved via workaround; properly-encrypted wifi doesn't really need SSL (though a MitM attack is possible for the first connection since the AP MAC isn't yet known), and everything seems to be moving to wifi.
I'd also like to see an extension to USB Mass Storage devices that puts a tiny CGI-enabled web browser in the "filesystem" that enables configuration. Since you're plugged in, security is easier.
FTFS: "I've written for courses in history, cinema, labor relations, pharmacology, theology, sports management, maritime security, airline services, sustainability, municipal budgeting, marketing, philosophy, ethics, Eastern religion, postmodern architecture, anthropology, literature, and public administration."
Hah! I'd love to see how this guy would do a physics or calculus paper...
Keep reading. If you quoted it, I shouldn't have to tell you to RTFA...
As long as it doesn't require me to do any math or video-documented animal husbandry, I will write anything.
How is this different from defining it by an artifact locked up beyond your reach? We have the technology to make such precise measurements on all of those fronts, and you'll have to entrust it to experts at a standards body either way you slice it.
Funnily enough I never ever think of a kilogram as the weight of some standard weight in a vault somewhere. The only way I ever think about the kilogram is the weight of one liter of water. Also comes in handy when I'm calculating how much liquids I can afford to buy when shopping groceries, given that I often go to the store on foot for the exercise and have to make sure I can manage the haul back.
Water is where the standard came from, but for one reason or another, it was replaced by that platinum brick. I think we now have the scientific expertise to return that that definition. I'd certainly prefer that as well, as it reduces the number of independently defined bases (like the five postulates of Euclid's Elements).
The NIST article has two conflicting statements on that front:
but later, it says
So amperes and moles are defined by a (kilo)gram and are therefore not independent. I would assume, based on that second quote, that each of those SI base units was independent...
If grams were once again derived from meters, those "seven" SI base units would actually be four.
Adults need fancy chairs because they've abused their bodies over time and their bodies can't adapt as quickly. Children are extremely adaptable and their plasticity should enable them to sit on rocks. Therefore, it is merely a cost issue. Since children tend to stick gum under desks, carve into their tops, and bowl them all over the place, they needn't be built to last the test of time. They need to be robust enough to tolerate a decent about of abuse and then get replaced in a few years.
If you're now thinking that better chairs would prevent that body abuse in adults, I'd argue that you're misguided there, too. It's a posture and ergonomics issue more than anything else.
Disclaimer: I don't subscribe to the need for $700 chairs. My Staples Berwell Luxura Task Chair was $90 and is, in many ways, just as comfortable (though not as adjustable) as chairs that cost 2-5 times as much. It does everything I need it to do. If it falls apart or is destroyed, I'll buy another. I've been in a lot of fancy offices and labs with a lot of really nice (and expensive) chairs. The Berwell isn't as nice, but it's 90% of the way there and simply precludes any reason for me to consider something over the $100 price point.
Another major contributor to this crap is their bad statistics. This is a law of small numbers, similar to when a baseball player is batting .500 early in the season (a .400 season's average is godly). There isn't enough data to make that a meaningful number. TLDs like .VN are very small quantities, so they are easily overrun by a few spammers buying their typical bulk quantities of spamvertising domains.
Reports like this can accidentally suggest dangerous blanket blacklisting. I think it's far better to use the more sophisticated systems of IP reputation (URIBLs in this case). That said, organizations that bring legal pressure to improperly relaxed registrars need this kind of data to move forward. Knujon ("no junk" backwards) is doing this, though their efforts are mostly restricted to the USA.
A year ago, some MIT undergrads wrote up a short piece called Project Gaydar which showcased how they were able to successfully identify gay men who were still in the closet.
Facebook might not expose this information directly (via the "sexual preferences" profile information), but your friends list is enough to extrapolate it. Since there's money in that kind of data and it is easily fetched via the Facebook API, it's being done.
Interesting, Debian has chromium-browser (the brand-stripped chrome that lacks some of the phone-home features) in its experimental repository as 7.0.544.0~r61416-1 while Google's apt repository is featuring 7.0.517.41-r62167 as both beta and stable (unstable has moved to 8.0.552.5-r62886). Unless I'm mistaken, those version numbers are composed of [version]~[VCS revision]-[package version] and chromium-browser's versions are pinned to their equivalent google-chrome version. That makes the current versions rather peculiar since Debian's (older) 544 is higher than Google's current 517 while the Debian's VCS revision 61416 is (as expected) earlier than Google's 62167.
What am I missing?
(The Debian chromium-browser package info page for developers is http://packages.qa.debian.org/c/chromium-browser.html)
ESP and Experimental College are example models for wiki-style universities; anybody can teach whatever they want at either of those schools (with or without a PhD). Tufts undergrads even get credits for the courses they take at the Experimental College.
JPEG2000 is an example of basic research, though also an example of some of the hurdles faced by it when not funded by corporate interests. A large number of startups come from basic research projects that grew up (sorry, I don't have the time to look up some better examples here).
Most people forget about the basic research performed by most universities, which is absolutely necessary to the academic industry and flows into every aspect of the rest of the world (especially including tech, medical, and military). A good deal of the criticism on the current system comes from a lack of understanding of basic research and its part in academia. While the Wikipedia-style likely has merits for far more than we currently expect (it was equally ill-received when proposed for encyclopedias!), it can't fit into our current paradigm of research universities while retaining the current organization of journals and how they handle submissions (which is another point of contention that needs a serious upgrade of its own).
Therefore, perhaps the part-time lecturer model is preferable as a starting-point. However, due to its for-profit (not to mention anticompetitive and controversial) nature, Phoenix is not an appropriate role model.
Take a look at examples that are already far closer to Wikipedia, like MIT's ESP and Tuft's Experimental College.
Hasn't the US Department of Defense fully moved to IPv6? It shouldn't need any more than a single block (really, not even that much) of IPv4, yet they still have the following eleven /8 blocks: 7, 11, 21, 22, 26, 28, 29, 30, 33, 214, and 215. The US Army also has 6 and 55 and the US Postal Service (USPS) has 56. That's a LOT of unused IPs.
As reported by Wired on 2009-09-23 in the story 1 Million Spiders Make Golden Silk for Rare Cloth. Fascinating read, especially if you're like me and wholly entranced by the concept of a super-fiber like spider silk.
I'm a SpamAssassin developer, both on the official project and on a commercial derivative. Others on my commercial team independently verified my claim as well. I highly doubt we're all wrong.
That said, I decided to FULLY dig into the issue to see what's going on under the hood. In addition to a careful analysis of the spamassassin debug output, I spun up Wireshark to look at the actual DNS queries. Since SA knows what example.com is ([84234] dbg: uridnsbl: domain example.com in skip list), I had to use something else. I ran two tests: one on a nonexistant domain as separated by the SHY character in a manner that doesn't result in delimiting the latter portion into an existing domain, and then one as a heavily-spammed domain with a SHY character again breaking it into a nonexisting domain.
Analysis: Debug output from SA 3.3.1 and SVN trunk (rev 1005948, build reports version as 3.4.0-r929098) displays the SHY character (which my terminal renders as a space but after a paste, my browser does not) and uses \255 in its DNS lookups (older versions display it as \173 and I didn't capture the raw lookups). In addition to looking for the domain with the SHY character, it also queries without the SHY character. My live test confirmed a hit in URIBL for the defanged domain and no hit for the obfuscated one (I didn't test a real sample of the obfuscation -- presumably, the blocklists can learn the obfuscated domain in addition to the defanged one). I see no reference to the IDN syntax you mentioned.
A sample of the debug output (tweaked to convert the SHY to a space so it is distinguishable on the web):
$ grep obinemedic ~/url.eml.output |grep -i uribl |sed 's/r.obin/r obin/'
Oct 8 15:06:55.950 [1570] dbg: dns: providing a callback for id: 64792/r obinemedic.ru.multi.uribl.com/A/IN
Oct 8 15:06:55.950 [1570] dbg: async: starting: URI-DNSBL, DNSBL:multi.uribl.com.:r obinemedic.ru (timeout 15.0s, min 3.0s)
Oct 8 15:06:55.955 [1570] dbg: dns: providing a callback for id: 40779/robinemedic.ru.multi.uribl.com/A/IN
Oct 8 15:06:55.955 [1570] dbg: async: starting: URI-DNSBL, DNSBL:multi.uribl.com.:robinemedic.ru (timeout 15.0s, min 3.0s)
Oct 8 15:06:55.985 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_DBL_SPAM): 127.0.1.2
Oct 8 15:06:55.987 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_AB_SURBL): 127.0.0.102
Oct 8 15:06:55.988 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_WS_SURBL): 127.0.0.102
Oct 8 15:06:55.988 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_JP_SURBL): 127.0.0.102
Oct 8 15:06:55.989 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_SC_SURBL): 127.0.0.102
Oct 8 15:06:56.121 [1570] dbg: async: completed in 0.162 s: URI-DNSBL, DNSBL:multi.uribl.com.:robinemedic.ru
Oct 8 15:06:56.121 [1570] dbg: uridnsbl: domain "robinemedic.ru" listed (URIBL_BLACK): 127.0.0.2
Oct 8 15:06:56.122 [1570] dbg: async: completed in 0.167 s: URI-DNSBL, DNSBL:multi.uribl.com.:r obinemedic.ru
Oct 8 15:06:57.980 [1570] dbg: async: timing: 0.162 . DNSBL:multi.uribl.com.:robinemedic.ru
Oct 8 15:06:57.980 [1570] dbg: async: timing: 0.167 . DNSBL:multi.uribl.com.:r obinemedic.ru
Just tested this in SpamAssassin with http ://exa ­ mple.com (spaced to evade slashdot's own obfuscation-eliminator) - Result: The URL domain (example.com) is properly extracted without the obfuscation.
That said, SA is fully capable of detecting the obfuscation attempt itself (using a rawbody rule)...
You don't need an accelerometer; the phone already knows its location is moving due to its interactions with the towers (or GPS). However, there's no way to determine that the person using the phone isn't a passenger (or riding a bus or streetcar ... a train can be detected by the fact that it's not on a road).
Consider this: a law that requires new cars to include bluetooth speakerphones that automatically connect when the car is turned on (yes, it requires the driver to pair a bluetooth-capable phone, but who wouldn't?). This would reduce the issue of only one hand on the wheel and its tether would allow the phone to know that its user is driving. Now there are several options, such as text-to-speech (and vice-versa) as well as phone software that limits time on the phone in one manner or other (limits texting composition time, splits incoming messages into smaller chunks and then prevents your checking them too quickly, etc).
Another law idea (complementary or stand-alone): accidents caused by driver negligence due to texting have harsher penalties ... make it the same as DUI. No reason not to also put cellphone handset issues here too. Note that this will be difficult to "prove" in court, but I think it's a start.
find .adobe .macromedia -type f -mtime +1 2>/dev/null |xargs rm -f
I forgot to mention what that does. It searches your .adobe and .macromedia directories for all files older than one day, ignores errors, and then removes the hits, ignoring failures like those from an empty file list.
Because I use ac power as a prerequisite for several cron tasks, I've actually worked the acpitool command into its own shell script, but I wanted to keep it simple for this post.
I've posted on this before, but here's an update based on some info from that link, hopefully doing a better job of limiting the damage from blowing away actively used LSOs:
Put this in your crontab:
* */4 * * * find .adobe .macromedia -type f -mtime +1 2>/dev/null |xargs rm -f
If you're on a laptop (test this first!), you can limit it to when you're plugged in:
* */4 * * * acpitool -a 2>/dev/null |grep -q online && find .adobe .macromedia -type f -mtime +1 2>/dev/null |xargs rm -f
This uses short circuiting in sh. You need to verify with this command first:
acpitool -a 2>/dev/null |grep -q online && echo it works || echo it failed
If you're not using GNU grep but acpitool works fine, try using grep online >/dev/null instead.