Do you really think you can scale that easily ? Just by keeping the code efficient and avoiding frameworks ? Mmmm
Scaling is not just about your application. It's about the network, the bandwidth, the infrastructure (hardware and software - load balancing, caching, etc), getting rid of single point of failures, etc. This requires resources and knowldedge to handle. Once you start dealing with all that, the performance of your code is just one of your problems.
> If bandwidth there was so amazingly cheap every > hotel would have amazing service.
Hotels don't have the same deals because * customer and business market show a big price difference. Hotels are seen as ISP when they resell access. * hotels don't see it necessary to have free/cheap internet to be attractive * they outsource the infrastructure/service and the pricing is thus made by the third parties. Think telecom companies. And Telecom companies suck.
One reason Internet is cheap in France is that there was competition (in part thanks to Free). Mobile phone prices are high (because of price collusions during many years with the main actors - http://www.highbeam.com/doc/1G1-139542623.html).
This is hopefully going to change as Free enters the telecom market in ~2 years.
"Leakage is generally high and in many cases 30-50% of the water is lost." Even with that, we have the lowest consumer country using at least as much as what you found to be a enormous amount.
I had a kernel issue with Lucid. I tracked it down upstream, followed the bug fixing on lkml *(testing patches), got it fixed on latest development branch and in -stable, backported it to Maverick s kernel and now am running Maverick happy.
> 1 directory extract locally... my SVN repo is 12Gb. [..]
I meant one extract instead of multiple checkouts. When I was working with subversion, I always had to play with multiple checkouts when working on several things at a time (not nice, but sometimes you're forced to). With SVN, no ability to stash the changes, need to be online to make a checkout or new branch, etc. And it's slow!
> That's a lot of network traffic and disc space for a lot of stuff I do not need to see of manage.
For the do not see. It's pretty educative to have the ability to understand why things are one way or another. For the space, I don't know. I have a 320 G disk on my laptop, 12 G isn't much. And even: * You don't need to clone all history * if you decide to get the 12 G, then fine, it's a *one time* operation. That's less than one hour to write this on your disk (40 min at 40MB/s). Once.
> I suppose the git solution would be to have many > repositories.. but then you're losing the > benefit you've claimed.
I was talking of having one checkout per tree, instead of multiple checkouts per tree. Never claimed to have a single git tree. And if you had multiple trees, you would probably not need them all.
> full local history: fair enough, but its not > that big a deal, on the relatively few occasions > I want history (that isn't just the previous > version), a hit on the server isn't a problem.
* I use history more often than before now that it's quickly available (blame, find changes, etc) * yes you can hit the server for history but it's damn slow, and _sometimes_ you don't have a server (server upgrade, server crash, network down, offsite, etc...)
> but ultimately you're going to send your commits to the server
I never said using git locally would remove the need for sane data handling procedure. It's the same if you work without committing to SVN. With a DVCS, it's just faster to be able to commit anytime, and push every so often. You end up doing it more often and you make your code changes smaller, easier to review by your co-workers. YMMV
> I think git has its place, but for a business, > the DVCS advantages are not so much of an > advantage, and the disadvantages usually > outweigh them
I probably didn't do a fine job selling git out. I know many businesses that use git (or mercurial) with great pleasure and they wouldn't go back for anything.
I won't spend more time trying to convince you. I agree that for some people, especially with git, DVCS can seem a bit too complicated.
For me it's a paradigm shift.
Given your comments, I am not sure you really tried one. I advice you to try one DVCS for yourself for a full week. And start with bridging SVN with git or mercurial.
I dont believe in the 2M issue. Most users upload their images on servers that resize the images appropriately.
I would tend to believe a company that has produced the site that more than 40% of the internet users use daily, a web browser and tools to verify if your site loads fast.
Show me your study that shows that on the top 1000 sites saving 40% on images wouldnt improve web pages load ?
I think youre missing on a lot of values a DSCM can bring you.
Some of my clients use svn, I use git svn bridge. Some of the things I can do: * have one directory extract locally * full local history * stash / pop when a quick fix request comes in * local branches (I used to have multiple checkouts laying around with svn...) Particularly useful when working disconnected (travelling, or on site without access to companys network). And that helps me make multiple commits, which makes my commits easily reviewable. Otherwise I face the I might "have to merge" fear that I have with SVN.
As for some of your arguments * you say businesses wont host in the open with github but you advice another service? I am pretty happy to use github for my business. I also have other servers for build etc * extra step ? Crap. In many cases, the merge in git helps you to go faster. Yes you have multiple commands, but the operations are faster and save you time (merge after commit instead of update breaking your changes) * hard disk breaking ? Thats crap. Just sync your disk with your server. You should do it anyway with subversion. And its faster than syncing your multiple checkouts directories.
Now I recognize that git is isnt easy to use. I stick to the minimal. But dont dismiss DVCS beacuse you havent found value for them. Try git svn for a week. Then come back.
There are some good reasons to change name. (think witness protection program). Some are traceable, some are not. Depends on the intent.
But saying you want an ID isn't necessarily the same as saying you agree with biometrics. In France and in Norway, we have a unique social security number, but we don't use biometrics to define it.
That's your job of installing the proper cron package:
apt-cache show anacron [...]
Anacron (like `anac(h)ronistic') is a periodic command scheduler. It
executes commands at intervals specified in days. Unlike cron, it
does not assume that the system is running continuously. It can
therefore be used to control the execution of daily, weekly and
monthly jobs (or anything with a period of n days), on systems that
don't run 24 hours a day. When installed and configured properly,
Anacron will make sure that the commands are run at the specified
intervals as closely as machine-uptime permits.
.
This package is pre-configured to execute the daily jobs of the Debian
system. You should install this program if your system isn't powered on 24 hours a day to make sure the maintenance jobs of other Debian packages [...]
And one important note about canonical-sensus:
"The package can easily be removed and only applies to the OEM installed versions of Ubuntu."
Isn't that's what they are doing right now ? They give the raw sources. The only thing they seem to be doing with the telegrams is rendering them anonymous. The journalism part was outsourced to the 3 main newspapers.
If you use a megaphone to talk while at your home, do you expect what you say to stay private ?
If you build a swimming pool at home, and make it so large that it becomes accessible from outside your property, would you feel outraged if people started using the bit that lies outside of the limits of your house (and for others to note on a map where accessible areas of water lie)?
It's not unreasonable to think that if someone @ Google has encountered the issue, someone else outside of Google might have. The reporter claims it.
Google has still probably thousand of computers affected by the problem. They want the problem fixed. In a less important manner, they also want their (thousands of) customers protected as well.
It's their responsibility to make sure that their machines and their customers are not at risk.
Microsoft is the only one who can not only properly fix the issue, but investigate the source and fix similar issues.
Not being able to come up with at least a commitment to fix the issue is bad.
> This isn't walking into someone's house through > an open door, it's taking photos from the street
Not even that: it's hearing from the street that there were people talking from the house at that particular moment (not necessarily even hearing what they were saying).
If you don't want them to hear that you are talking and what you are saying, hide your SSID and encrypt your communications. Done.
The only illegal problem I could see is the large scale of the information gathering. Personally, as an owner of a open hotspot, I don't care.
> The problem with that argument is these support > periods aren't currently transparent
That's what I said. We need one manufacturer to take the risk and take this market by saying something like: we support 2 years upgrades on our devices. It shouldn't be too hard, they could pay one or 2 of these hackers from XDA to work on it full time. Today, some have to rely on donations to replace their phone when they fry it.
'fragmentation' isn't an issue, it's an enabler. In my case a lot of innovation comes to the OS to be able to support older devices. That's good for everyone.
The skype protocol isn't reimplemented here.
This software used skype4java
http://blogs.skype.com/developer/2006/10/skype4java_a_developers_collab.html
> DRM, undocumented protocols, and the like are always cracked
Still waiting for skype to be cracked... :(
Do you really think you can scale that easily ? Just by keeping the code efficient and avoiding frameworks ? Mmmm
Scaling is not just about your application. It's about the network, the bandwidth, the infrastructure (hardware and software - load balancing, caching, etc), getting rid of single point of failures, etc. This requires resources and knowldedge to handle. Once you start dealing with all that, the performance of your code is just one of your problems.
> If bandwidth there was so amazingly cheap every
> hotel would have amazing service.
Hotels don't have the same deals because
* customer and business market show a big price difference. Hotels are seen as ISP when they resell access.
* hotels don't see it necessary to have free/cheap internet to be attractive
* they outsource the infrastructure/service and the pricing is thus made by the third parties. Think telecom companies. And Telecom companies suck.
One reason Internet is cheap in France is that there was competition (in part thanks to Free). Mobile phone prices are high (because of price collusions during many years with the main actors - http://www.highbeam.com/doc/1G1-139542623.html).
This is hopefully going to change as Free enters the telecom market in ~2 years.
http://news.xinhuanet.com/english2010/sci/2010-10/13/c_13554298.htm
Try again.
"Leakage is generally high and in many cases 30-50% of the water is lost." Even with that, we have the lowest consumer country using at least as much as what you found to be a enormous amount.
http://www.grid.unep.ch/product/publication/freshwater_europe/images/eurohousehold.jpg
Even Lithuania was using more than twice that in 2003:
http://www.grid.unep.ch/product/publication/freshwater_europe/consumption.php
Here's your bug I think: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268502
This is maybe an upstream bug, https://bugzilla.kernel.org/show_bug.cgi?id=12045
so it's not Ubuntu's fault. Debian has probably the same issue (hint: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525220)
If you want to get it fixed, go on LKML and bluetooth userspace developer list, reproduce the issue and find the maintainer(s).
My experience is different.
I had a kernel issue with Lucid. I tracked it down upstream, followed the bug fixing on lkml *(testing patches), got it fixed on latest development branch and in -stable, backported it to Maverick s kernel and now am running Maverick happy.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/86820
What have you done to get the bug fixed ?
> 1 directory extract locally... my SVN repo is 12Gb. [..]
I meant one extract instead of multiple checkouts. When I was working with subversion, I always had to play with multiple checkouts when working on several things at a time (not nice, but sometimes you're forced to). With SVN, no ability to stash the changes, need to be online to make a checkout or new branch, etc. And it's slow!
> That's a lot of network traffic and disc space for a lot of stuff I do not need to see of manage.
For the do not see. It's pretty educative to have the ability to understand why things are one way or another.
For the space, I don't know. I have a 320 G disk on my laptop, 12 G isn't much. And even:
* You don't need to clone all history
* if you decide to get the 12 G, then fine, it's a *one time* operation. That's less than one hour to write this on your disk (40 min at 40MB/s). Once.
> I suppose the git solution would be to have many
> repositories.. but then you're losing the
> benefit you've claimed.
I was talking of having one checkout per tree, instead of multiple checkouts per tree. Never claimed to have a single git tree.
And if you had multiple trees, you would probably not need them all.
E.g. http://android.git.kernel.org/ You can pick all trees, or just one.
> full local history: fair enough, but its not
> that big a deal, on the relatively few occasions
> I want history (that isn't just the previous
> version), a hit on the server isn't a problem.
* I use history more often than before now that it's quickly available (blame, find changes, etc)
* yes you can hit the server for history but it's damn slow, and _sometimes_ you don't have a server (server upgrade, server crash, network down, offsite, etc...)
> but ultimately you're going to send your commits to the server
I never said using git locally would remove the need for sane data handling procedure. It's the same if you work without committing to SVN.
With a DVCS, it's just faster to be able to commit anytime, and push every so often. You end up doing it more often and you make your code changes smaller, easier to review by your co-workers. YMMV
> I think git has its place, but for a business,
> the DVCS advantages are not so much of an
> advantage, and the disadvantages usually
> outweigh them
I probably didn't do a fine job selling git out.
I know many businesses that use git (or mercurial) with great pleasure and they wouldn't go back for anything.
I won't spend more time trying to convince you. I agree that for some people, especially with git, DVCS can seem a bit too complicated.
For me it's a paradigm shift.
Given your comments, I am not sure you really tried one. I advice you to try one DVCS for yourself for a full week. And start with bridging SVN with git or mercurial.
This sounded like one of the most interesting comment in that thread. It's probably too late...
Feel free to contact LWN.net (they might probably write something on the topic).
I dont believe in the 2M issue. Most users upload their images on servers that resize the images appropriately.
I would tend to believe a company that has produced the site that more than 40% of the internet users use daily, a web browser and tools to verify if your site loads fast.
Show me your study that shows that on the top 1000 sites saving 40% on images wouldnt improve web pages load ?
Start by reading the study: http://code.google.com/speed/webp/docs/c_study.html
I think youre missing on a lot of values a DSCM can bring you.
Some of my clients use svn, I use git svn bridge. Some of the things I can do:
* have one directory extract locally
* full local history
* stash / pop when a quick fix request comes in
* local branches (I used to have multiple checkouts laying around with svn...) Particularly useful when working disconnected (travelling, or on site without access to companys network). And that helps me make multiple commits, which makes my commits easily reviewable. Otherwise I face the I might "have to merge" fear that I have with SVN.
As for some of your arguments
* you say businesses wont host in the open with github but you advice another service? I am pretty happy to use github for my business. I also have other servers for build etc
* extra step ? Crap. In many cases, the merge in git helps you to go faster. Yes you have multiple commands, but the operations are faster and save you time (merge after commit instead of update breaking your changes)
* hard disk breaking ? Thats crap. Just sync your disk with your server. You should do it anyway with subversion. And its faster than syncing your multiple checkouts directories.
Now I recognize that git is isnt easy to use. I stick to the minimal. But dont dismiss DVCS beacuse you havent found value for them. Try git svn for a week. Then come back.
YMMV
Even better: a blacklist of hashed names and passport numbers.
Haven't they heard of shadowed information ?
Was this to allow sending packets in a way that is not traceable by common sniffers ?
Because you will now see UUIDs in newspapers ?
There are some good reasons to change name. (think witness protection program). Some are traceable, some are not. Depends on the intent.
But saying you want an ID isn't necessarily the same as saying you agree with biometrics. In France and in Norway, we have a unique social security number, but we don't use biometrics to define it.
not for me
Unfortunately, trust isn't something you can rely upon when it comes to sex. That's just a fact of life.
That's your job of installing the proper cron package:
apt-cache show anacron
[...]
Anacron (like `anac(h)ronistic') is a periodic command scheduler. It
executes commands at intervals specified in days. Unlike cron, it
does not assume that the system is running continuously. It can
therefore be used to control the execution of daily, weekly and
monthly jobs (or anything with a period of n days), on systems that
don't run 24 hours a day. When installed and configured properly,
Anacron will make sure that the commands are run at the specified
intervals as closely as machine-uptime permits.
.
This package is pre-configured to execute the daily jobs of the Debian
system. You should install this program if your system isn't powered on 24 hours a day to make sure the maintenance jobs of other Debian packages
[...]
And one important note about canonical-sensus:
"The package can easily be removed and only applies to the OEM installed versions of Ubuntu."
https://answers.launchpad.net/ubuntu/+source/canonical-census/+question/120594
Isn't that's what they are doing right now ? They give the raw sources. The only thing they seem to be doing with the telegrams is rendering them anonymous. The journalism part was outsourced to the 3 main newspapers.
You want analogies ?
If you use a megaphone to talk while at your home, do you expect what you say to stay private ?
If you build a swimming pool at home, and make it so large that it becomes accessible from outside your property, would you feel outraged if people started using the bit that lies outside of the limits of your house (and for others to note on a map where accessible areas of water lie)?
It's not unreasonable to think that if someone @ Google has encountered the issue, someone else outside of Google might have. The reporter claims it.
Google has still probably thousand of computers affected by the problem. They want the problem fixed. In a less important manner, they also want their (thousands of) customers protected as well.
It's their responsibility to make sure that their machines and their customers are not at risk.
Microsoft is the only one who can not only properly fix the issue, but investigate the source and fix similar issues.
Not being able to come up with at least a commitment to fix the issue is bad.
> This isn't walking into someone's house through
> an open door, it's taking photos from the street
Not even that: it's hearing from the street that there were people talking from the house at that particular moment (not necessarily even hearing what they were saying).
If you don't want them to hear that you are talking and what you are saying, hide your SSID and encrypt your communications. Done.
The only illegal problem I could see is the large scale of the information gathering. Personally, as an owner of a open hotspot, I don't care.
I have an ADP1 (aka G1), it's very limited hardware wise, making it hard to support the latest OS version. I could say I almost got burned.
But thanks to the open nature of Android and the XDA community, I am able to upgrade to 2.1 and soon 2.2: http://db.androidspin.com/androidspin_developer_display.asp?developerid=105
> The problem with that argument is these support
> periods aren't currently transparent
That's what I said. We need one manufacturer to take the risk and take this market by saying something like: we support 2 years upgrades on our devices. It shouldn't be too hard, they could pay one or 2 of these hackers from XDA to work on it full time. Today, some have to rely on donations to replace their phone when they fry it.
http://twitter.com/ChiefzReloaded/status/14681541487
> fragmentation
'fragmentation' isn't an issue, it's an enabler. In my case a lot of innovation comes to the OS to be able to support older devices. That's good for everyone.
See also http://android-developers.blogspot.com/2010/05/on-android-compatibility.html
Can't the people sued make a class action suit ?