I admit I got bored before getting through the whole thing, but the distribution of winning numbers ranged from between +2 to -3 standard deviations from the mean. That isn't exactly pointing to any numbers with a substantially-higher probability of getting chosen. Pretty Darn Random covers the results pretty well.
In my rather limited experience, the first step is almost always a strongly-worded letter, since those are: 1. Cheap 2. Surprisingly effective, if someone didn't know they were doing something wrong
The lawsuit usually comes about after you send the threatening letter, and the recipient replies with a politely-worded message like "go pound sand"...
I've been looking for a project to use one of these for. I probably wouldn't be able to get it down to aspirin tablet size because of the battery, but I bet that all of the required circuitry would fit on the target board, which is about the size of a penny.
The development kit only costs $20. The microcontrollers themselves are only about $1-$2 each, in quantity. Probably wouldn't be "home-brew" enough for the folks at the BBC, though.
That's why you build your Sputnik's outer casing out of two stainless steel pet bowls soldered together. A millimeter or so of steel will knock the incoming radiation way down, and will incidentally shield the insides from electromagnetic fields and solar wind.
It's not like you'd just be duct-taping the componbents together and shooting it into space - that'd be silly.
The accelerated-dispatch feature is optional, so you might well expect that security-conscious developers would learn to disable it. I don't recall ever hearing of anybody writing an Objective-C based exploit before, even as a proof-of-concept (though I may have missed it). It sure sounds like it could be done. I guess in that case, you'd have to depend on other security features minimizing the damage.
I may have overstated things a bit when I said that verifying heat transfer was the primary purpose of testing at elevated temperatures. It's an important thing to verify though. Depending on the level of analysis performed beforehand, you'll have greater or lesser confidence that the product won't overheat, but nothing beats actually sticking a thermometer in/on the device and checking.
Of course in addition to that, you've got all sorts of other issues to look for - differential expansion causing components to separate, solder cracking, adhesives flowing when they shouldn't, verifying that the battery safety circuits work correctly, etc, etc.
40 degrees C is a sort-of standard for "elevated ambient" testing of electronics. The point of testing at higher temperatures is mostly to ensure that heat transfer out of the chips is sufficient at that temperature to keep them from overheating. The chips themselves will likely be running at much greater temperatures internally, but as long as the heat sinks are efficient enough, the chips shouldn't overheat.
For consumer electronics, I guess the assumption is that if it's 40 degrees in your room, you're going to go find somewhere cooler to be, rather than sitting there with your PC blowing hot air on you.
In other industries, the standards are different. Many products designed for use in an automobile are tested at 50-60 degrees, which is closer to the interior temperature of a car in full sun in a temperate climate.
You could probably sell cryogenic speaker cables for a lot of money. They'd have to look extremely cool, though, or sales would suffer. On the other hand, just the presence of the cryostat, water-cooling plumbing, and other paraphenalia would lend a sirious air to the while thing.
High-temp superconducting wires and cables are already commercially available, you "just" have to solve the packaging problem.
I've never heard of a month-to-month option for iPhone. I almost certainly would have chosen such a plan if I'd know it existed. Oh well. Caveat Emptor, as the saving goes,
Yeah, that kind of surprises me, too - they're not on iTunes, Yahoo! Music, or Napster. I seem to remember someone from the band making a public statement to the effect that they thought single-song sales were a violation of their artistic vision, or some such.
If I didn't already have every US-released CD from them, I'd be downloading like mad before the band notices that their songs are on there...
Don't pick up a $100 telescope from Wal-Mart or whatever, "just to see if it's fun". That's a good way to frustrate yourself out of of a potentially interesting hobby. At a minimum, you need a scope with an equatorial mount (and you'll need to learn how to set it up). Trying to track things moving through the sky with an altitude/azimuth control is just way too annoying. For most photographic purposes, a motorized mount is necessary. These days, that probably also means you'll get a remote controller and computer interface.
Why not buy an OpenMoko phone? Well, it's certainly poised to bring the same success to the mobile phone market as we've been seeing with Linux on the desktop.
from http://wiki.openmoko.org/wiki/Developer_preview What you can expect a functional bootloader with support for firmware upgrades a functional Linux kernel with basic drivers for the various hardware subsystems, with small bugs here and there a basic, simple linux distribution based on OpenEmbedded, that you have to install yourself as rootfs image using USB DFU all the source code that we have at this point in time, and the corresponding build system mailing lists
What you CAN NOT expect yet reliable means of making phone calls, esp. not from the UI reliable means of sending/receiving SMS, esp. not from the UI integrated GPRS data access bluetooth integration (basic bluez driver works) proper power management (i.e. no reasonable battery life yet) ringtone (or other) profile management network preferences (call deflection, manual operator selection,...) a complete application framework where third party application developers can write apps that easily integrate with the OpenMoko world
Maybe I'm just a stupid Apple fan-boy, but I'm willing to spend a little extra for a cellular phone that can, you know, make phone calls.
OZYMANDIAS by Percy Bysshe Shelley I met a traveller from an antique land Who said: Two vast and trunkless legs of stone Stand in the desert. Near them on the sand, Half sunk, a shatter'd visage lies, whose frown And wrinkled lip and sneer of cold command Tell that its sculptor well those passions read Which yet survive, stamp'd on these lifeless things, The hand that mock'd them and the heart that fed. And on the pedestal these words appear: "My name is Ozymandias, king of kings: Look on my works, ye mighty, and despair!" Nothing beside remains: round the decay Of that colossal wreck, boundless and bare, The lone and level sands stretch far away.
"In compliance with US DMCA, this product has been designed and produced to enable legally authorized "fair use" rights of creating and operating from backup media.
The WHOLE POINT of the DMCA is that it does away with the concept of "fair use" copying, for any creative work that's protected by an "effective" (their term) technological copy-prevention system. The "intent" of the modchip manufacturers doesn't enter into it - if the device is primarily designed to foil a copy-prevention system, then it's illegal.
Modchip manufacturers could certainly implement a system where the modchip was linked in some way to the copying system, to prevent secondary copies. That idea has two basic problems:
1. Making the first copy is illegal under the DMCA, so it doesn't actually help their legal stance at all.
2. Eliminating interoperability would take away the primary market for this device - people who want to play copies of games without buying the originals - i.e. "pirates". We all know that there are "legitimate" uses of these chips, but the vast majority of the people who buy them aren't interested in those uses.
It doesn't necessarily mean that the figures are wrong, but it does make them somewhat suspect. If nothing else, using Watts where WattHours was meant makes a factor of 60 difference in the magnitude of the number..
This is the fundamental problem with the current "go back to the Moon, go on to Mars" space-exploration fantasy. It's not worth the trouble to send people to Mars if they basically have to immediately come right back.
When (if) we send people to Mars, they ought to be able to stay there and get some real scientific work done. The robots should have already cleared a landing field, built shelters, and extracted sufficient Oxygen for them to live there for a period of at least a few months.
Until we can do that, going to Mars is just a stunt. "We can't tell enough about conditions on Mars with the robot probes we've sent" isn't an argument for sending people, it's an argument for building better robots.
I'll tell you what - when NASA can keep half a dozen people alive for six months with no re-supply in a completely sealed habitat here on Earth (maybe on the Antarctic Plateau, to make conditions as close as possible), then they can use my tax money to start planning a trip to Mars.
The actual exploit code would need to be different for Windows than for Mac OS X, but it's a safe bet that the underlying vulnerability (buffer overflow or whatever) is present in Bonjour for Windows, as well.
So, not quite like the Internet-spanning, DDOS-producing Windows worms we've come to know and hate. I'm not too surprised the vulnerability was in MDNSResponder, though. Someone I work with found a few problems in the code when running it on Linux.
Reading is no problem - standard magneto-optical drives can read the magnetization of a disk with a laser very effectively. As mentioned above, the real breakthrough here is being able to write to the disk quickly. Current M-O drives take 2-3 times longer to write data than to read it.
Oh yeah, you don't use conventional warheads in your SAMs for targets like this. The USSR and USA had nuclear-tipped ABMs and SAMs as far back as the 60s. As the saying goes "a nuclear warhead solves a whole lot of targeting problems". You're seriously suggesting that a country would detonate nuclear weapons over its own territory to prevent an enemy taking pictures of a sensitive area? This makes sense how, exactly?
"I enjoy shooting my friends. If I were to do that IRL I would have many less friends and probably a jail sentence."
Given the average level of "skill" I see from most online game players, I'd guess that your friends would be in no real danger. Without an aimbot and unlimited ammo, most gamers couldn't hit the side of a barn, from inside.
I was just responding to someone that claimed that GCC's output wasn't covered by the GPL, and never would be. Last year, you could have said that the GPL didn't put any restrictions on hardware developers in terms of how they implemented security for their products. Now the GPL v3 does exactly that (with weasel words about which hardware might or might not be immune to the new restrictions).
"FSF/GNU own the copyright to GCC... They can do anything they want with it."
Well, yeah - that was exactly the point I was trying to make. It's irresponsible for someone to claim that anything related to the GPL is absolutely not going to change. In addition to the general case of not making absolute statements, the FSF has made it clear that they're planning to change GPL however they need to to respond to what they consider "new threats to user's freedoms".
Do you happen to have a reference for that claim? Has anyone from FSF ever publically stated that they have no interest in making the output of GCC covered by the GPL?
Given Stallman and the FSF's recent power-grab with the "anti-tivoisation" language in the GPLv3, why wouldn't they change the license such that anything compiled with GCC is automatically covered by the GPL, as well?
For the OS group, it was necessary to make the distinction between "this is something that's okay for folks inside the company to use" and "this is okay for customers to see". Typically we'd release something internally when the APIs had mostly firmed up, and didn't release Beta versions to customers until the software was more visually polished.
That was probably a somewhat unique situation. Everybody at the company had a dependency of some sort on the next version of the OS, so it was important to have a milestone for "this software is complete enough for someone to use for development and testing of related products".
I admit I got bored before getting through the whole thing, but the distribution of winning numbers ranged from between +2 to -3 standard deviations from the mean. That isn't exactly pointing to any numbers with a substantially-higher probability of getting chosen. Pretty Darn Random covers the results pretty well.
In my rather limited experience, the first step is almost always a strongly-worded letter, since those are:
1. Cheap
2. Surprisingly effective, if someone didn't know they were doing something wrong
The lawsuit usually comes about after you send the threatening letter, and the recipient replies with a politely-worded message like "go pound sand"...
I've been looking for a project to use one of these for. I probably wouldn't be able to get it down to aspirin tablet size because of the battery, but I bet that all of the required circuitry would fit on the target board, which is about the size of a penny.
The development kit only costs $20. The microcontrollers themselves are only about $1-$2 each, in quantity. Probably wouldn't be "home-brew" enough for the folks at the BBC, though.
That's why you build your Sputnik's outer casing out of two stainless steel pet bowls soldered together. A millimeter or so of steel will knock the incoming radiation way down, and will incidentally shield the insides from electromagnetic fields and solar wind.
It's not like you'd just be duct-taping the componbents together and shooting it into space - that'd be silly.
The accelerated-dispatch feature is optional, so you might well expect that security-conscious developers would learn to disable it. I don't recall ever hearing of anybody writing an Objective-C based exploit before, even as a proof-of-concept (though I may have missed it). It sure sounds like it could be done. I guess in that case, you'd have to depend on other security features minimizing the damage.
-Mark
I may have overstated things a bit when I said that verifying heat transfer was the primary purpose of testing at elevated temperatures. It's an important thing to verify though. Depending on the level of analysis performed beforehand, you'll have greater or lesser confidence that the product won't overheat, but nothing beats actually sticking a thermometer in/on the device and checking.
Of course in addition to that, you've got all sorts of other issues to look for - differential expansion causing components to separate, solder cracking, adhesives flowing when they shouldn't, verifying that the battery safety circuits work correctly, etc, etc.
40 degrees C is a sort-of standard for "elevated ambient" testing of electronics. The point of testing at higher temperatures is mostly to ensure that heat transfer out of the chips is sufficient at that temperature to keep them from overheating. The chips themselves will likely be running at much greater temperatures internally, but as long as the heat sinks are efficient enough, the chips shouldn't overheat.
For consumer electronics, I guess the assumption is that if it's 40 degrees in your room, you're going to go find somewhere cooler to be, rather than sitting there with your PC blowing hot air on you.
In other industries, the standards are different. Many products designed for use in an automobile are tested at 50-60 degrees, which is closer to the interior temperature of a car in full sun in a temperate climate.
You could probably sell cryogenic speaker cables for a lot of money. They'd have to look extremely cool, though, or sales would suffer. On the other hand, just the presence of the cryostat, water-cooling plumbing, and other paraphenalia would lend a sirious air to the while thing.
High-temp superconducting wires and cables are already commercially available, you "just" have to solve the packaging problem.
I've never heard of a month-to-month option for iPhone. I almost certainly would have chosen such a plan if I'd know it existed. Oh well. Caveat Emptor, as the saving goes,
Yeah, that kind of surprises me, too - they're not on iTunes, Yahoo! Music, or Napster. I seem to remember someone from the band making a public statement to the effect that they thought single-song sales were a violation of their artistic vision, or some such.
If I didn't already have every US-released CD from them, I'd be downloading like mad before the band notices that their songs are on there...
I imagine that the Martian lifeforms we're going there to look for might care.
Don't pick up a $100 telescope from Wal-Mart or whatever, "just to see if it's fun". That's a good way to frustrate yourself out of of a potentially interesting hobby. At a minimum, you need a scope with an equatorial mount (and you'll need to learn how to set it up). Trying to track things moving through the sky with an altitude/azimuth control is just way too annoying. For most photographic purposes, a motorized mount is necessary. These days, that probably also means you'll get a remote controller and computer interface.
Why not buy an OpenMoko phone? Well, it's certainly poised to bring the same success to the mobile phone market as we've been seeing with Linux on the desktop.
...)
from http://wiki.openmoko.org/wiki/Developer_preview
What you can expect
a functional bootloader with support for firmware upgrades
a functional Linux kernel with basic drivers for the various hardware subsystems, with small bugs here and there
a basic, simple linux distribution based on OpenEmbedded, that you have to install yourself as rootfs image using USB DFU
all the source code that we have at this point in time, and the corresponding build system
mailing lists
What you CAN NOT expect yet
reliable means of making phone calls, esp. not from the UI
reliable means of sending/receiving SMS, esp. not from the UI
integrated GPRS data access
bluetooth integration (basic bluez driver works)
proper power management (i.e. no reasonable battery life yet)
ringtone (or other) profile management
network preferences (call deflection, manual operator selection,
a complete application framework where third party application developers can write apps that easily integrate with the OpenMoko world
Maybe I'm just a stupid Apple fan-boy, but I'm willing to spend a little extra for a cellular phone that can, you know, make phone calls.
Were you thinking of this?
OZYMANDIAS by Percy Bysshe Shelley
I met a traveller from an antique land
Who said: Two vast and trunkless legs of stone
Stand in the desert. Near them on the sand,
Half sunk, a shatter'd visage lies, whose frown
And wrinkled lip and sneer of cold command
Tell that its sculptor well those passions read
Which yet survive, stamp'd on these lifeless things,
The hand that mock'd them and the heart that fed.
And on the pedestal these words appear:
"My name is Ozymandias, king of kings:
Look on my works, ye mighty, and despair!"
Nothing beside remains: round the decay
Of that colossal wreck, boundless and bare,
The lone and level sands stretch far away.
The WHOLE POINT of the DMCA is that it does away with the concept of "fair use" copying, for any creative work that's protected by an "effective" (their term) technological copy-prevention system. The "intent" of the modchip manufacturers doesn't enter into it - if the device is primarily designed to foil a copy-prevention system, then it's illegal.
Modchip manufacturers could certainly implement a system where the modchip was linked in some way to the copying system, to prevent secondary copies. That idea has two basic problems:
1. Making the first copy is illegal under the DMCA, so it doesn't actually help their legal stance at all.
2. Eliminating interoperability would take away the primary market for this device - people who want to play copies of games without buying the originals - i.e. "pirates". We all know that there are "legitimate" uses of these chips, but the vast majority of the people who buy them aren't interested in those uses.
It doesn't necessarily mean that the figures are wrong, but it does make them somewhat suspect. If nothing else, using Watts where WattHours was meant makes a factor of 60 difference in the magnitude of the number..
This is the fundamental problem with the current "go back to the Moon, go on to Mars" space-exploration fantasy. It's not worth the trouble to send people to Mars if they basically have to immediately come right back.
When (if) we send people to Mars, they ought to be able to stay there and get some real scientific work done. The robots should have already cleared a landing field, built shelters, and extracted sufficient Oxygen for them to live there for a period of at least a few months.
Until we can do that, going to Mars is just a stunt. "We can't tell enough about conditions on Mars with the robot probes we've sent" isn't an argument for sending people, it's an argument for building better robots.
I'll tell you what - when NASA can keep half a dozen people alive for six months with no re-supply in a completely sealed habitat here on Earth (maybe on the Antarctic Plateau, to make conditions as close as possible), then they can use my tax money to start planning a trip to Mars.
The actual exploit code would need to be different for Windows than for Mac OS X, but it's a safe bet that the underlying vulnerability (buffer overflow or whatever) is present in Bonjour for Windows, as well.
So, not quite like the Internet-spanning, DDOS-producing Windows worms we've come to know and hate. I'm not too surprised the vulnerability was in MDNSResponder, though. Someone I work with found a few problems in the code when running it on Linux.
Reading is no problem - standard magneto-optical drives can read the magnetization of a disk with a laser very effectively. As mentioned above, the real breakthrough here is being able to write to the disk quickly. Current M-O drives take 2-3 times longer to write data than to read it.
"I enjoy shooting my friends. If I were to do that IRL I would have many less friends and probably a jail sentence."
Given the average level of "skill" I see from most online game players, I'd guess that your friends would be in no real danger. Without an aimbot and unlimited ammo, most gamers couldn't hit the side of a barn, from inside.
I was just responding to someone that claimed that GCC's output wasn't covered by the GPL, and never would be. Last year, you could have said that the GPL didn't put any restrictions on hardware developers in terms of how they implemented security for their products. Now the GPL v3 does exactly that (with weasel words about which hardware might or might not be immune to the new restrictions).
"FSF/GNU own the copyright to GCC... They can do anything they want with it."
Well, yeah - that was exactly the point I was trying to make. It's irresponsible for someone to claim that anything related to the GPL is absolutely not going to change. In addition to the general case of not making absolute statements, the FSF has made it clear that they're planning to change GPL however they need to to respond to what they consider "new threats to user's freedoms".
Do you happen to have a reference for that claim? Has anyone from FSF ever publically stated that they have no interest in making the output of GCC covered by the GPL?
Given Stallman and the FSF's recent power-grab with the "anti-tivoisation" language in the GPLv3, why wouldn't they change the license such that anything compiled with GCC is automatically covered by the GPL, as well?
For the OS group, it was necessary to make the distinction between "this is something that's okay for folks inside the company to use" and "this is okay for customers to see". Typically we'd release something internally when the APIs had mostly firmed up, and didn't release Beta versions to customers until the software was more visually polished.
That was probably a somewhat unique situation. Everybody at the company had a dependency of some sort on the next version of the OS, so it was important to have a milestone for "this software is complete enough for someone to use for development and testing of related products".