They should just extradite him to the US along with all of his seized property, and then the US government can just keep it forever under its insane civil forfeiture laws.
That's what they're trying to do. Unfortunately, NZ judges want this other stuff dealt with before the extradition trial.
The proof of concept I wrote also isn't entirely new code. It's tiny due to using.deb as a container format (minus maintainer scripts, full dependencies, etc.), so I get to save effort by using dpkg to unpack things, which leaves us room to selectively use more of its features in future if we want to.
So they start off with what they think they need, then become more like APT as they need to add more features.
So the scope of what I've been considering is purely leaf apps built on a fixed "base system", which in the case of the initial target of the Ubuntu phone/tablet work would be the run-time part of the Ubuntu SDK.
In other words, this is something to be used in addition to APT (i.e. post-install), rather than instead of APT.
* no dependencies between apps; single implicit dependency on the base
system by way of a Click-Base-System field
Just like Debian has an implicit dependency on the base system (except for base packages, which have more complicated rules). In other words, this system will only accept a single dependency, the Click-Base-System. I'm not quite sure why this is different from only accepting applications that only depend on Click-Base-System.
And note that the "each package will install to its own directory" bit is on the to-do list:
Obvious items I still need to work on:
produce a strawman hooks implementation with some real worked examples
integrate (or demonstrate how to integrate) the container isolation properties worked on elsewhere
Click-Base-System field is skeletally simple right now, and may need to be expanded to at least leave open the possibility of multiple flavours of base system (see also GNOME's profiles idea)
adjust unpack handling to avoid problems with project renames and name clashes, and to unpack each version into its own directory and flip symlinks to allow for multi-user independence
integrate into the Ubuntu SDK, as well as providing examples of how it can be integrated into other build systems too
The thing was that the start menu really was nearly entirely obsolete. None of its features really made sense.
...
Want to [do something you can do from the start menu]? [Carry out procedure n]
That doesn't sound like an obselete thing to me, because you suggest that the described features do make sense. It just sounds like there are multiple ways to do these things. I like the idea of having multiple paths to get something done, but I also like the idea of having a single path that can be used to do many different things — menu systems have this ability.
And one could also make an argument that a 3D printer can not produce anything that I cant already make with tools ranging from a micro CNC to a nail file.
There are some glue-free structures involving enclosed internal parts (moving or non-moving) that can't be created on a milling machine (or similar equivalent machine such as what you have enumerated), but can be printed on a layered additive printer.
It also has a "one-tool for everything" advantage, allowing you to rapidly prototype and evolve things in a fairly short space of time.
Block chain size grows linearly with each transaction. There are 10**10 people on earth, a terabyte drive has 10**12 bytes, and costs $100.
We're unfortunately not at 'atoms of the universe' complexity, so this might be a limiting factor in the future.
Consider a game that uses bitcoin for microtransactions, such that in-game money is bitcoin, and the transactions happen twice every development cycle (e.g. an accelerated day's worth of farm production, one transaction from user to game company, another from the company to the user). Assume these cycles happen roughly once every two seconds -- 3600 transactions per hour, or 86400 per day -- even if someone isn't actively playing the game (i.e. life continues after they leave). Round it up to 10^5 for the sake of simplicity.
A single person carries out 10^5 of these microtransactions per day in their game. With a game population of 10^5 (i.e. 100,000 users), that's 10^10 microtransactions per day for this game. With a transaction size of 100 bytes, this game will generate about 10^12 bytes of transaction data each day (presumably about half shared among all the users, and the other half recorded with the game company's account).
It would be silly to set up a game that did that, but it is probably within the realms of what is possible.
This sort of thing is just what big pharma wants, no human interaction and careful consideration, just a pill dispenser...symptom a + symptom B == Pill 2... How much you wanna bet this thing always prescribes expensive non generic drugs and never tries the 50-70 year old known treatments that are usually the first steps in treatment before new expensive drugs are prescribed.
It's more difficult to bribe computers, so I'd doubt this is what big pharma wants. A properly designed diagnosis system (open source, or government-managed) should offer the cheapest efficacious drug, rather than the latest drug that has been shown to be more effective than a placebo (but curiously untested in effectiveness against the most effective generic drug).
So you're saying that every file is encrypted with the same key? Err no. What they could do would be to hash the file before upload, in the browser, and then send that hash in addition to the encrypted file (and encrypted key).
Sending a hash of the file pre-encryption for a file encrypted differently for each person would not be particularly useful for deduplication at all, because it would give no indication as to the content of the file. The only people it would help would be groups interested in file usage statistics. You could do the block-level deduplication mentioned previously and hope that by random chance some blocks are similar, but that would be a tiny amount of space saved in comparison to the method I have outlined.
To aid deduplication, every file would be encrypted with its own key (different for each file, based on a hash of the file name). You would be able to obtain / decrypt the original file (assuming a sufficiently random / secure encryption key) under the following two situations:
Access to the original file, so that you could generate the encryption key
Access to the encryption key for that file, presumably obtained from someone who has access to the original file
Deduplication can be done perfectly well on a file level even for encrypted files. If this is anything like PGP, you could do it by having multiple encrypted messages attached to the encrypted file (or linked to the file), one for each person with access to the file. Each message contains the same [unencrypted] data — a decryption key for the file — but can only be decrypted by the person who the message is for.
In a well-secured system, all these [small] decryption messages would be stored in a random order in the same place, so you attempt to decrypt all these messages with your personal key in order to retrieve the decryption key for the file. That way, even if you have access to the decryption messages, you can't tell if any particular person will be able to decrypt that file without knowing their decryption key. A more reasonable compromise (faster, a bit less secure / deniable) would be for each person to have their own decryption key store, which is queried whenever they want a particular file.
As long as the file encryption is done on the client side (in the same way by all clients), the server can do deduplication without having any idea what the file contains.
Presumably Mega has the encrypted hashes (or not, it doesn't really matter), which are useless for accessing the contents of the file without access to the keys that are used to decrypt and extract the file hashes. Mega does not need to store these user keys on the server, so they probably don't.
However, Mega should be able to identify files stored on their server if they have access to the original files. Consider if a Mega has access to a file called 'The_HoBBiT_Crazy_Delta_XxXDVDRip_firsTPost.avi' (e.g. they were provided the file by some company who wanted to check for compliance with licensing). They use the Mega client system to encrypt that file, producing an encrypted file and a file decryption key. They then check to see if any files on the server have an exact match to that encrypted file (e.g. first by hash, then by comparing length, then by an exact comparison of the encrypted bytes). It would then be possible to delete the file, check to see who has uploaded this particular file, and produce a list of people who also have access to that file.
I find that changing relative risk to absolute risk makes the wow factor of these studies go down considerably. The absolute risk is of getting oral cancers and dying from them can be derived from the abstract:
Among 968,432 men and women who were cancer free at enrollment, 868 deaths due to oral/pharyngeal cancer occurred during 26 years of follow-up.
So the 26-year absolute risk of death due to oral/pharyngeal cancer in this study was about 1 in 1,000 (one thousand). Assuming an even spread across the years, that's also about 1 in 30,000 for any given year.
Drinking greater than 4 cups of coffee a day has a relative risk of about 0.5, so that's about 1 in 2,000 over 26 years (a difference of 0.045%), or about 1 in 60,000 in any given year (a difference of 0.0017%).
Note that this risk reduction is associated with death due specifically to oral/pharyngeal cancer, not the cancer alone -- it does not follow from these results that drinking coffee reduces your risk of getting cancer. If you get oral/pharyngeal cancer, but die from being impaled by an angry unicorn, it doesn't count for the purposes of this result / association.
The controls for neverball are simple -- just move the mouse. My kid particularly likes zooming round in circles, and somehow managed to get to Level 8 (over the course of a few months) by making what appears to me to be fairly random mouse movements.
Enigma also has a similar control simplicity, at least for puzzles that don't involve extra items.
What you would need to do is presume that on-click is one finger, and the mouse as it moves away is another finger allowing you 2d input.
I would do position at button down is the centre of the rotation, position at drag / release is the second point that defines the angle (with the reference angle being either right horizontal or up vertical, or something else depending on what floats your boat). Although if you do that, you don't get the drag motion that everyone expects, so you need keyboard accelerator keys + mouse for a reasonable (or better) equivalent to navigation using multi-touch.
I think one of the more useful things with multi-touch that is more difficult to replicate with a mouse is defining rectangle borders. Touch 1 dragging defines TL corner (or most appropriate corner), touch 2 dragging defines the opposite corner. When you define boundaries with a single mouse, you need to start off being very specific with the first corner, and only have drag freedom with the second corner. The benefit of multi-touch (or more correctly multi-pointer) for this was demonstrated to me at the 2008 linux.conf.au in Melbourne (resizing windows).
I prefer ProFont, but perhaps that's because I have a low-resolution screen (102ppi). I set up my console font for ProFont at size 8 (size 7 isn't quite clean enough for me). The "Source Code Pro" font has a taller line height at that size, and the dot on the 0 is pushed off to the left (and antialiased), which makes it harder to distinguish from O. ProFont gets around this by using a slash for 0, which is very obvious even at small sizes.
Fraud will not work in peer reviewed work, let alone grant applications - it's too easy to spot
Fraud, at least in the form of bending the truth, is common in both peer reviewed work and in grant applications (and particularly encouraged in the latter). The reality of funding is that scientists need to be increasingly devious in order to make the funding body believe that their work is more important and deserves to be funded over that other group of scientists who are doing similar work (and engaging in similar deception).
I have had trouble thinking of an appropriate solution to this. Most research that gets carried out is useful in some way and deserves some funding, but the outcomes are frequently negative for the particular situations that were initially tested. On the other hand, I don't think it's good idea to give $100,000 to every person who wants to look at how long earthworms will survive after being dropped in water.
This was getting silly a few years ago with the metabolome. How many more omes (i.e. subsets of the total system that influences human biology) do we need to look at until we declare our human model complete? Is there going to be a 'humanome' that describes human-associated environmental factors? What about a 'radiatome' that describes the plethora of electromagnetic signals that enter our body over the course of a lifetime?
The "lock" screen can now optionally control your music player, the system volume, and display notifications so you don't have to type in a password.
Oh, great. How about also adding in a function to enter commands into a terminal from the lock screen. Adding new functions to lock screens is always risk-free, after all. I'm sure jwz would approve.
I'm writing all my essays in Baskerville with included pictures from now on. I'm sure that will go down really well for my next funding application -- do graphs count as pictures?
Slashdot Mirror
... <chirp, chirp>
Oh well, they can canola Nature then.
They should just extradite him to the US along with all of his seized property, and then the US government can just keep it forever under its insane civil forfeiture laws.
That's what they're trying to do. Unfortunately, NZ judges want this other stuff dealt with before the extradition trial.
From the email:
The proof of concept I wrote also isn't entirely new code. It's tiny due to using .deb as a container format (minus maintainer scripts, full dependencies, etc.), so I get to save effort by using dpkg to unpack things, which leaves us room to selectively use more of its features in future if we want to.
So they start off with what they think they need, then become more like APT as they need to add more features.
So the scope of what I've been considering is purely leaf apps built on a fixed "base system", which in the case of the initial target of the Ubuntu phone/tablet work would be the run-time part of the Ubuntu SDK.
In other words, this is something to be used in addition to APT (i.e. post-install), rather than instead of APT.
* no dependencies between apps; single implicit dependency on the base
system by way of a Click-Base-System field
Just like Debian has an implicit dependency on the base system (except for base packages, which have more complicated rules). In other words, this system will only accept a single dependency, the Click-Base-System. I'm not quite sure why this is different from only accepting applications that only depend on Click-Base-System.
And note that the "each package will install to its own directory" bit is on the to-do list:
Obvious items I still need to work on:
The thing was that the start menu really was nearly entirely obsolete. None of its features really made sense.
...
Want to [do something you can do from the start menu]? [Carry out procedure n]
That doesn't sound like an obselete thing to me, because you suggest that the described features do make sense. It just sounds like there are multiple ways to do these things. I like the idea of having multiple paths to get something done, but I also like the idea of having a single path that can be used to do many different things — menu systems have this ability.
And one could also make an argument that a 3D printer can not produce anything that I cant already make with tools ranging from a micro CNC to a nail file.
There are some glue-free structures involving enclosed internal parts (moving or non-moving) that can't be created on a milling machine (or similar equivalent machine such as what you have enumerated), but can be printed on a layered additive printer.
It also has a "one-tool for everything" advantage, allowing you to rapidly prototype and evolve things in a fairly short space of time.
Block chain size grows linearly with each transaction.
There are 10**10 people on earth, a terabyte drive has 10**12 bytes, and costs $100.
We're unfortunately not at 'atoms of the universe' complexity, so this might be a limiting factor in the future.
Consider a game that uses bitcoin for microtransactions, such that in-game money is bitcoin, and the transactions happen twice every development cycle (e.g. an accelerated day's worth of farm production, one transaction from user to game company, another from the company to the user). Assume these cycles happen roughly once every two seconds -- 3600 transactions per hour, or 86400 per day -- even if someone isn't actively playing the game (i.e. life continues after they leave). Round it up to 10^5 for the sake of simplicity.
A single person carries out 10^5 of these microtransactions per day in their game. With a game population of 10^5 (i.e. 100,000 users), that's 10^10 microtransactions per day for this game. With a transaction size of 100 bytes, this game will generate about 10^12 bytes of transaction data each day (presumably about half shared among all the users, and the other half recorded with the game company's account).
It would be silly to set up a game that did that, but it is probably within the realms of what is possible.
That's kinda like saying that I can smoke weed legally because I haven't been busted yet.
More like saying you can smoke weed without legal worries because the US government hasn't busted anyone yet.
This sort of thing is just what big pharma wants, no human interaction and careful consideration, just a pill dispenser...symptom a + symptom B == Pill 2...
How much you wanna bet this thing always prescribes expensive non generic drugs and never tries the 50-70 year old known treatments that are usually the first steps in treatment before new expensive drugs are prescribed.
It's more difficult to bribe computers, so I'd doubt this is what big pharma wants. A properly designed diagnosis system (open source, or government-managed) should offer the cheapest efficacious drug, rather than the latest drug that has been shown to be more effective than a placebo (but curiously untested in effectiveness against the most effective generic drug).
How does this compare with peltier cooling? Is there some obvious reason (e.g. no airflow) why peltier won't work in space?
So you're saying that every file is encrypted with the same key? Err no. What they could do would be to hash the file before upload, in the browser, and then send that hash in addition to the encrypted file (and encrypted key).
Sending a hash of the file pre-encryption for a file encrypted differently for each person would not be particularly useful for deduplication at all, because it would give no indication as to the content of the file. The only people it would help would be groups interested in file usage statistics. You could do the block-level deduplication mentioned previously and hope that by random chance some blocks are similar, but that would be a tiny amount of space saved in comparison to the method I have outlined.
To aid deduplication, every file would be encrypted with its own key (different for each file, based on a hash of the file name). You would be able to obtain / decrypt the original file (assuming a sufficiently random / secure encryption key) under the following two situations:
Deduplication can be done perfectly well on a file level even for encrypted files. If this is anything like PGP, you could do it by having multiple encrypted messages attached to the encrypted file (or linked to the file), one for each person with access to the file. Each message contains the same [unencrypted] data — a decryption key for the file — but can only be decrypted by the person who the message is for.
In a well-secured system, all these [small] decryption messages would be stored in a random order in the same place, so you attempt to decrypt all these messages with your personal key in order to retrieve the decryption key for the file. That way, even if you have access to the decryption messages, you can't tell if any particular person will be able to decrypt that file without knowing their decryption key. A more reasonable compromise (faster, a bit less secure / deniable) would be for each person to have their own decryption key store, which is queried whenever they want a particular file.
As long as the file encryption is done on the client side (in the same way by all clients), the server can do deduplication without having any idea what the file contains.
Presumably Mega has the encrypted hashes (or not, it doesn't really matter), which are useless for accessing the contents of the file without access to the keys that are used to decrypt and extract the file hashes. Mega does not need to store these user keys on the server, so they probably don't.
However, Mega should be able to identify files stored on their server if they have access to the original files. Consider if a Mega has access to a file called 'The_HoBBiT_Crazy_Delta_XxXDVDRip_firsTPost.avi' (e.g. they were provided the file by some company who wanted to check for compliance with licensing). They use the Mega client system to encrypt that file, producing an encrypted file and a file decryption key. They then check to see if any files on the server have an exact match to that encrypted file (e.g. first by hash, then by comparing length, then by an exact comparison of the encrypted bytes). It would then be possible to delete the file, check to see who has uploaded this particular file, and produce a list of people who also have access to that file.
[mostly copied from my response(s) elsewhere]
I find that changing relative risk to absolute risk makes the wow factor of these studies go down considerably. The absolute risk is of getting oral cancers and dying from them can be derived from the abstract:
Among 968,432 men and women who were cancer free at enrollment, 868 deaths due to oral/pharyngeal cancer occurred during 26 years of follow-up.
So the 26-year absolute risk of death due to oral/pharyngeal cancer in this study was about 1 in 1,000 (one thousand). Assuming an even spread across the years, that's also about 1 in 30,000 for any given year.
Drinking greater than 4 cups of coffee a day has a relative risk of about 0.5, so that's about 1 in 2,000 over 26 years (a difference of 0.045%), or about 1 in 60,000 in any given year (a difference of 0.0017%).
Note that this risk reduction is associated with death due specifically to oral/pharyngeal cancer, not the cancer alone -- it does not follow from these results that drinking coffee reduces your risk of getting cancer. If you get oral/pharyngeal cancer, but die from being impaled by an angry unicorn, it doesn't count for the purposes of this result / association.
Does this have any use in the image sensor market?
How much rep could a reprap rap if a reprap could rap rep?
Don't you mean this?
http://www.youtube.com/watch?v=-tkfrBEvbko
The chinese are about 2 years ahead of you:
http://www.youtube.com/watch?v=TBL3ux1o0tM
The controls for neverball are simple -- just move the mouse. My kid particularly likes zooming round in circles, and somehow managed to get to Level 8 (over the course of a few months) by making what appears to me to be fairly random mouse movements.
Enigma also has a similar control simplicity, at least for puzzles that don't involve extra items.
What you would need to do is presume that on-click is one finger, and the mouse as it moves away is another finger allowing you 2d input.
I would do position at button down is the centre of the rotation, position at drag / release is the second point that defines the angle (with the reference angle being either right horizontal or up vertical, or something else depending on what floats your boat). Although if you do that, you don't get the drag motion that everyone expects, so you need keyboard accelerator keys + mouse for a reasonable (or better) equivalent to navigation using multi-touch.
I think one of the more useful things with multi-touch that is more difficult to replicate with a mouse is defining rectangle borders. Touch 1 dragging defines TL corner (or most appropriate corner), touch 2 dragging defines the opposite corner. When you define boundaries with a single mouse, you need to start off being very specific with the first corner, and only have drag freedom with the second corner. The benefit of multi-touch (or more correctly multi-pointer) for this was demonstrated to me at the 2008 linux.conf.au in Melbourne (resizing windows).
I prefer ProFont, but perhaps that's because I have a low-resolution screen (102ppi). I set up my console font for ProFont at size 8 (size 7 isn't quite clean enough for me). The "Source Code Pro" font has a taller line height at that size, and the dot on the 0 is pushed off to the left (and antialiased), which makes it harder to distinguish from O. ProFont gets around this by using a slash for 0, which is very obvious even at small sizes.
Fraud will not work in peer reviewed work, let alone grant applications - it's too easy to spot
Fraud, at least in the form of bending the truth, is common in both peer reviewed work and in grant applications (and particularly encouraged in the latter). The reality of funding is that scientists need to be increasingly devious in order to make the funding body believe that their work is more important and deserves to be funded over that other group of scientists who are doing similar work (and engaging in similar deception).
I have had trouble thinking of an appropriate solution to this. Most research that gets carried out is useful in some way and deserves some funding, but the outcomes are frequently negative for the particular situations that were initially tested. On the other hand, I don't think it's good idea to give $100,000 to every person who wants to look at how long earthworms will survive after being dropped in water.
This was getting silly a few years ago with the metabolome. How many more omes (i.e. subsets of the total system that influences human biology) do we need to look at until we declare our human model complete? Is there going to be a 'humanome' that describes human-associated environmental factors? What about a 'radiatome' that describes the plethora of electromagnetic signals that enter our body over the course of a lifetime?
The "lock" screen can now optionally control your music player, the system volume, and display notifications so you don't have to type in a password.
Oh, great. How about also adding in a function to enter commands into a terminal from the lock screen. Adding new functions to lock screens is always risk-free, after all. I'm sure jwz would approve.
I'm writing all my essays in Baskerville with included pictures from now on. I'm sure that will go down really well for my next funding application -- do graphs count as pictures?
If I have $50, and I have to buy lunch every work day for two weeks, how much can I spend on average?
I can solve that using letters as nothing but unit identifiers:
$50 / (2 weeks * 5 days) = $50 / 10 = $5
Using letters to replace numbers is not always necessary, and can make things more confusing.