What if the complaint is from one of these people who just clicks on "spam" when they don't want the mail, even when it's not spam?
If I clicked on the spam button, it's spam. I don't care why you think we have a business relationship. We don't, I'm not interested.
If I buy a product online and have to register I *always* untick any "send me product updates" checkbox. If you didn't ask that question, you have no permission to send me any emails, and are thus sending me spam.
If the attacker has access to your phone they can simply remove the sd card and mount it on another system. Complaining that it can be accessed via USB seems a bit redundant.
But even if you do attach a usb cable, you must enable remote debugging or manually confirm every time you wish to share the sdcard.
http://sparkleshare.org for the front end. Throwing a windows client together shouldn't be too difficult.
For the back end, gitolite on a central server with local mirrors at each office that are readonly. Configure client git repo's to push writes centrally and read from a local mirror.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 1
Perhaps with a small number of commits like your 13 example, this would work fine. But what about r32185? Are you going to sit there and count them all by hand? No, you'd use your source control tools to find it. Sure e209309 or 18d3ba doesn't tell you which commit came first, or which tagged build it was first included in. But git's command line tools can answer those questions.
Yes, the learning curve is steeper. But the primitives that git is built on are actually quite simple and understandable. And the tools that have been built around them are very powerful indeed.
With git, the server the commit is currently stored on is much less important than who wrote it, when and what they changed. In a project the scale of the linux kernel, a commit might be copied around a large number of repositories before finally being blessed by Linus or one of his lieutenants and included in the next release. In all of those moves, the commit id will not change. But the branch it has been included in, and perhaps even the order it was merged will change.
More fundamentally in git the focus is not on controlling the history of a specific central branch. But on making it easy to accept and apply patches from anyone. Recognizing that in a large project, merging can be more common than committing.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 1
If you want to write a commit hook that runs on your master repository, that automatically creates a numbered tag for every push to the master branch. That's fine, you can do that if you wish, using whatever numbering scheme you like. Git is flexible enough to do just about anything.
Personally I would rather wait until I'm certain the code is releasable before assigning version numbers and creating tags. But, to each his own.
If a disk fails, you lose 3TB not 145. You'd only lose access to 135TB if you lose connectivity to a whole pod, and even then the disks might be recoverable. So of their 9,000 disks, about 10 fail and are replaced per week. So you'd want to ensure that you can lose any random set of disks without losing data.
From their first article, they put 15 disks into a RAID array and would need to lose 3 of them before they can't rebuild the array. But even when you do replace a drive, the rebuild on a 3 TB disk @ 150MB/s is going to leave quite a long window between drive failure and your data being safe again.
Instead if you do something close to what I believe google does. You make sure every block of data is stored on say 3 randomly chosen disks, on separate machines (though you might want more than that). And you lose any two disks at once, the number of data blocks that would be down to one copy would be quite small and only take a few seconds to replicate again.
Data is also duplicated across different pods so you can lose one due to power supply issues and not care for a while. RAID across local groups of disks does seem a bit pointless when you already have a layer of redundancy across the whole rack.
The main reason we're still seeing high unemployment since the "great recession", is that everyone is still paying back or defaulting on their debts. Before this financial crisis Americans were adding about 1 trillion dollars a year of private debt growth to the demand in the economy. Now the level of private debt is falling rapidly. So instead of having all that extra spending power fueling growth and jobs, we have lots of debts being repaid and a massive reduction in spending power.
It's the 1930's all over again. Well, almost. In the 30's it was primarily businesses who had accumulated large debts, and as they tried to reduce their margins, they triggered a deflationary price spiral. This time around, we don't have that much control over manufacturing, and there's not much room left for prices to drop. We've been pretty ruthless at reducing production costs for quite a while.
But we're going to see high unemployment for a long time to come, as there simply isn't enough cash floating around the economy to pay everyone who was previously employed.
Another similar thing I've noticed. Mobile phones have certainly had an effect on how people plan to meet somewhere, and how much patience they have to wait or look around.
I would say more generally, that G+ needs more options to let you pick what is in your stream. Maybe you have people in circles so you can easily send them directed messages, but that doesn't mean you want to see all their public posts.
They'd have to drop it to $5 if they want me to play it at all. I'm not in the habit of playing story based single player games twice. But what if I have to jump up from the game quickly during a cut scene and I miss something?
No. Even for $5 I wouldn't consider it. Though I'm certain that pirates will find a way around it.
The devil is in the details though. The cheapest connection via the NBN is currently planned to be $24 a month for 24MBit at the customer end. However there is an additional $20 per month per MBit charge at the peering point that the ISP will have to pay for all traffic flowing over this last mile network. With no way for traffic to flow directly between households. And while I realise the pricing structure is based on a fairly large and probably normal over-subscription ratio, this means that anyone who wants to provide any kind of data service over this network would have to add a whopping $480 a month to the bill to allow one customer to use their connection 24/7. And that's without considering any other costs you may have.
What's the point of building an uber fast fiber network if you are going to gouge anyone who dares to actually use it? Why are we building this thing if ISP prices and services wont get any better than they are now?
BitCoin has a quite elegant solution to the problem of double spending a digital currency. But as you rightly point out it fails completely as a means of exchange with existing currencies. I'd say that most of the issues stem from the way coins are created out of nothing as you can only sell those coins for the amount that someone else is willing to buy them.
The best alternative I've come up with so far (and that's not saying much..) would be something like a Promissory Note or Bond. For example a trusted "bank" might create an initial stock of coins denominated in an existing currency, with a legal liability to always honor anyone who wishes to exchange them for that currency. Some external accounting and auditing rules would need to be enforced to ensure that the "bank" always holds onto sufficient assets to cover the value of the coins they have issued. From that point onwards, a system like BitCoin could be used to anonymously track the current owner of each bundle of coins and enforce that they cannot be duplicated.
A slight modification to the above scheme, would be using BitCoins to track the current owner of units in a mutual fund or perhaps the shareholders of a listed company.
BitCoin is an interesting idea, and it elegantly solves a number of technical hurdles that any digital currency must solve. But it cannot be used as a global currency unless it can be made to fit into the existing financial system. And for that task, BitCoin is woefully inadequate.
The $2 million "internet in a suitcase" grant from TFA is going towards OTI's Commotion Wireless project. Pulling together a secure solutions using open source software and involving developers from GNU Radio, OpenBTS, TOR, Serval, and others. So no, we won't be including any back doors in our software.
I visited those offices on L St mentioned in TFA last week. Where I was attending the Commotion code sprint.
Over the two days we managed to integrate OpenBTS and Serval phones and successfully placed a call from a GSM phone, through an OpenBTS tower, over an automatically configured mesh network running the OLSR routing protocol, to an android phone running Serval's software. Unfortunately we didn't capture this on film before we had to pack up and go our separate ways.
It should be fairly interesting to see where this project is headed.
The problems bitcoin solves, eg electronic transfer of value and prevention of double spending, I think it does solve well. Unfortunately currency exchange is a fundamental problem that bitcoin, by itself, does not solve. As you have rightly pointed out, any implementation of such a system *must* have a viable plan to exchange with existing local currencies to have any usefulness and to avoid becoming a ponzy scheme.
I would be very interested in trying to build a solution to this problem, as I think an open global micro-payment system would have tremendous potential. However without authorities that can be trusted to issue and destroy value tokens in exchange for local currency, I'm not certain that it can be done.
But still, there's heaps an application can do to reduce the number of memory pages that need to be read into ram at any point in time. If an application runs some kind of tree search, and each element it considers is on a separate memory page, then that will result in a lot more memory pages being read from disk. If, on the other hand, you optimise algorithms such that related data is located on the same memory pages, the number of hard faults can be drastically reduced.
At The Serval Project, among our other phone / adhoc mesh networking projects, we are working on a GPL solution for live streaming video from android phones. We've recently made some progress and the source should be available at some point in the near future if anyone is interested in helping or using it for other projects.
Hmmm. The trends for both Correlation and Causation have a graph similar to the ribosome example given by google. With peaks and troughs of interest that seem to match the semesters of the school year. With less interest in summer, though smaller schools in the southern hemisphere would still be running. And a massive drop off around Christmas when schools world wide would be on holidays. But the two terms have an R value less than 0.91 (I haven't bothered to work out how much less though). So I guess there is some truth in the age old saying, Correlation != Causation.
Slashdot Mirror
What if the complaint is from one of these people who just clicks on "spam" when they don't want the mail, even when it's not spam?
If I clicked on the spam button, it's spam. I don't care why you think we have a business relationship. We don't, I'm not interested.
If I buy a product online and have to register I *always* untick any "send me product updates" checkbox. If you didn't ask that question, you have no permission to send me any emails, and are thus sending me spam.
If the attacker has access to your phone they can simply remove the sd card and mount it on another system. Complaining that it can be accessed via USB seems a bit redundant.
But even if you do attach a usb cable, you must enable remote debugging or manually confirm every time you wish to share the sdcard.
http://sparkleshare.org for the front end. Throwing a windows client together shouldn't be too difficult.
For the back end, gitolite on a central server with local mirrors at each office that are readonly. Configure client git repo's to push writes centrally and read from a local mirror.
Perhaps with a small number of commits like your 13 example, this would work fine. But what about r32185? Are you going to sit there and count them all by hand? No, you'd use your source control tools to find it. Sure e209309 or 18d3ba doesn't tell you which commit came first, or which tagged build it was first included in. But git's command line tools can answer those questions.
Yes, the learning curve is steeper. But the primitives that git is built on are actually quite simple and understandable. And the tools that have been built around them are very powerful indeed.
With git, the server the commit is currently stored on is much less important than who wrote it, when and what they changed. In a project the scale of the linux kernel, a commit might be copied around a large number of repositories before finally being blessed by Linus or one of his lieutenants and included in the next release. In all of those moves, the commit id will not change. But the branch it has been included in, and perhaps even the order it was merged will change.
More fundamentally in git the focus is not on controlling the history of a specific central branch. But on making it easy to accept and apply patches from anyone. Recognizing that in a large project, merging can be more common than committing.
If you want to write a commit hook that runs on your master repository, that automatically creates a numbered tag for every push to the master branch. That's fine, you can do that if you wish, using whatever numbering scheme you like. Git is flexible enough to do just about anything.
Personally I would rather wait until I'm certain the code is releasable before assigning version numbers and creating tags. But, to each his own.
Or you could just encrypt the database.
If a disk fails, you lose 3TB not 145. You'd only lose access to 135TB if you lose connectivity to a whole pod, and even then the disks might be recoverable. So of their 9,000 disks, about 10 fail and are replaced per week. So you'd want to ensure that you can lose any random set of disks without losing data.
From their first article, they put 15 disks into a RAID array and would need to lose 3 of them before they can't rebuild the array. But even when you do replace a drive, the rebuild on a 3 TB disk @ 150MB/s is going to leave quite a long window between drive failure and your data being safe again.
Instead if you do something close to what I believe google does. You make sure every block of data is stored on say 3 randomly chosen disks, on separate machines (though you might want more than that). And you lose any two disks at once, the number of data blocks that would be down to one copy would be quite small and only take a few seconds to replicate again.
Data is also duplicated across different pods so you can lose one due to power supply issues and not care for a while. RAID across local groups of disks does seem a bit pointless when you already have a layer of redundancy across the whole rack.
The main reason we're still seeing high unemployment since the "great recession", is that everyone is still paying back or defaulting on their debts. Before this financial crisis Americans were adding about 1 trillion dollars a year of private debt growth to the demand in the economy. Now the level of private debt is falling rapidly. So instead of having all that extra spending power fueling growth and jobs, we have lots of debts being repaid and a massive reduction in spending power.
It's the 1930's all over again. Well, almost. In the 30's it was primarily businesses who had accumulated large debts, and as they tried to reduce their margins, they triggered a deflationary price spiral. This time around, we don't have that much control over manufacturing, and there's not much room left for prices to drop. We've been pretty ruthless at reducing production costs for quite a while.
But we're going to see high unemployment for a long time to come, as there simply isn't enough cash floating around the economy to pay everyone who was previously employed.
Another similar thing I've noticed. Mobile phones have certainly had an effect on how people plan to meet somewhere, and how much patience they have to wait or look around.
I would say more generally, that G+ needs more options to let you pick what is in your stream. Maybe you have people in circles so you can easily send them directed messages, but that doesn't mean you want to see all their public posts.
They'd have to drop it to $5 if they want me to play it at all. I'm not in the habit of playing story based single player games twice. But what if I have to jump up from the game quickly during a cut scene and I miss something?
No. Even for $5 I wouldn't consider it. Though I'm certain that pirates will find a way around it.
The devil is in the details though. The cheapest connection via the NBN is currently planned to be $24 a month for 24MBit at the customer end. However there is an additional $20 per month per MBit charge at the peering point that the ISP will have to pay for all traffic flowing over this last mile network. With no way for traffic to flow directly between households. And while I realise the pricing structure is based on a fairly large and probably normal over-subscription ratio, this means that anyone who wants to provide any kind of data service over this network would have to add a whopping $480 a month to the bill to allow one customer to use their connection 24/7. And that's without considering any other costs you may have.
What's the point of building an uber fast fiber network if you are going to gouge anyone who dares to actually use it? Why are we building this thing if ISP prices and services wont get any better than they are now?
BitCoin has a quite elegant solution to the problem of double spending a digital currency. But as you rightly point out it fails completely as a means of exchange with existing currencies. I'd say that most of the issues stem from the way coins are created out of nothing as you can only sell those coins for the amount that someone else is willing to buy them.
The best alternative I've come up with so far (and that's not saying much..) would be something like a Promissory Note or Bond. For example a trusted "bank" might create an initial stock of coins denominated in an existing currency, with a legal liability to always honor anyone who wishes to exchange them for that currency. Some external accounting and auditing rules would need to be enforced to ensure that the "bank" always holds onto sufficient assets to cover the value of the coins they have issued. From that point onwards, a system like BitCoin could be used to anonymously track the current owner of each bundle of coins and enforce that they cannot be duplicated.
A slight modification to the above scheme, would be using BitCoins to track the current owner of units in a mutual fund or perhaps the shareholders of a listed company.
BitCoin is an interesting idea, and it elegantly solves a number of technical hurdles that any digital currency must solve. But it cannot be used as a global currency unless it can be made to fit into the existing financial system. And for that task, BitCoin is woefully inadequate.
The $2 million "internet in a suitcase" grant from TFA is going towards OTI's Commotion Wireless project. Pulling together a secure solutions using open source software and involving developers from GNU Radio, OpenBTS, TOR, Serval, and others. So no, we won't be including any back doors in our software.
Once you identify an individual member of anonymous don't they immediately cease being a member?
I visited those offices on L St mentioned in TFA last week. Where I was attending the Commotion code sprint.
Over the two days we managed to integrate OpenBTS and Serval phones and successfully placed a call from a GSM phone, through an OpenBTS tower, over an automatically configured mesh network running the OLSR routing protocol, to an android phone running Serval's software. Unfortunately we didn't capture this on film before we had to pack up and go our separate ways.
It should be fairly interesting to see where this project is headed.
The problems bitcoin solves, eg electronic transfer of value and prevention of double spending, I think it does solve well. Unfortunately currency exchange is a fundamental problem that bitcoin, by itself, does not solve. As you have rightly pointed out, any implementation of such a system *must* have a viable plan to exchange with existing local currencies to have any usefulness and to avoid becoming a ponzy scheme.
I would be very interested in trying to build a solution to this problem, as I think an open global micro-payment system would have tremendous potential. However without authorities that can be trusted to issue and destroy value tokens in exchange for local currency, I'm not certain that it can be done.
But still, there's heaps an application can do to reduce the number of memory pages that need to be read into ram at any point in time. If an application runs some kind of tree search, and each element it considers is on a separate memory page, then that will result in a lot more memory pages being read from disk. If, on the other hand, you optimise algorithms such that related data is located on the same memory pages, the number of hard faults can be drastically reduced.
At The Serval Project, among our other phone / adhoc mesh networking projects, we are working on a GPL solution for live streaming video from android phones. We've recently made some progress and the source should be available at some point in the near future if anyone is interested in helping or using it for other projects.
Hmmm. The trends for both Correlation and Causation have a graph similar to the ribosome example given by google. With peaks and troughs of interest that seem to match the semesters of the school year. With less interest in summer, though smaller schools in the southern hemisphere would still be running. And a massive drop off around Christmas when schools world wide would be on holidays. But the two terms have an R value less than 0.91 (I haven't bothered to work out how much less though). So I guess there is some truth in the age old saying, Correlation != Causation.
When you're in AU, Steam still lists prices in USD.
There's a fair number of firefox addons that help you shorten urls. Are there any that show you where short urls redirect to?
I'd consider buying it, when steam stops adding a 60% markup just because I live in Australia.