Forgot your password?
typodupeerror

Comment: Re:Only your friends see your +1 (Score 1) 218

by macbutch (#35682610) Attached to: Google Is Introducing the +1 Button

'So?' yourself.

You are correct that my quote 'does nowhere show that Google will NOT aggregate the information to improve their pagerank algorithim' (grammar notwithstanding). However that is a different topic (but as far as it goes I'm inclined to agree with you and they need to do something to improve pagerank...).

Anyway, I was replying to this part:

As stated IN THE ARTICLE, when you +1 something, only your contacts see it.

Which I believe my quote does show to be incorrect.

Comment: Re:Only your friends see your +1 (Score 4, Informative) 218

by macbutch (#35679750) Attached to: Google Is Introducing the +1 Button

Mmmm, yeah, except Google themselves say:

+1’ing is a public action. Anyone on the web can potentially see that you’ve +1’d content when they’re searching on Google or viewing content you’ve +1’d. For this reason, you should only +1 pages when you’re comfortable sharing your recommendation with the world."

Your +1’s may appear to anyone who sees the pages you’ve +1’d. However, we'll try to display your +1’s to people (specifically those in your social connections) who would find them most useful.

https://www.google.com/support/profiles/bin/answer.py?answer=1186915

Comment: Re:pardon, your ignorance is showing (Score 1) 244

by macbutch (#34284698) Attached to: An Illustrated Version Control Timeline

Sure, those are all pretty reasonable comments. I'll describe two ways of working with Git that I think address this somewhat.

I guess first up I would say that Git doesn't really push you towards a specific way of working so if there is a particular way that you want to do things then chances are you can do that with Git (that said there are definitely ways to do things that would be less worthwhile than others).

We switched to Git from Subversion where I work about 6 months ago and it's worked extremely well for us. We have a small team but it is spread across two or three countries (some of us move around a bit). For us we use a central model where there is a single 'authoritative' repository which we all push and pull from. So I don't share my repository directly with the other developers we all push and pull from the same central one (which we integrate with Hudson for CI).

So really we're not using the distributed for the sake of sharing code directly between us but because having access to the full repository (and did I mention that Git is fast?) allows us to do stuff we couldn't before. Once you've done the initial clone Git is very very fast (and things like svn log are much much faster with git because you don't have to do any network operations). Essentially we still have a central repository that update from and commit too simimlarly to SVN it's just that we can continue committing without a network connection and split our commits into sensible chunks of work that go into the central repository etc.

Now, in terms of doing something really distributed, you can do that too more easily than you described (though I've not really done it in any seriousness so not sure whether it is worth setting up). If you give me access to your repository, I give you access to mine and we both have access to a third repository. We can set up our own repositories to pull from both the others - so it is not so much more difficult to fetch the work of the other repositories into our own working tree. There is a tiny bit of extra work here - generally Git commands are bit more fine grained than something like Subversion so you do end up with more commands. For my use (and for my team) I've written some simple scripts that tie some stuff together (so I run 'git up' which simulates 'svn up' or 'cvs up' you could easily do the same for fetching from multiple repositories if you wanted ... ).

Generally I wouldn't really recommend working that way for a small group. What would make more sense would if you had two teams working on a product (maybe a team doing support and a team doing a product release) the release team might want to pull changes from the support team as they're finished and make sure that they're incorporated into the next release. Generally I think you'd have one person doing that and pushing it into a central repository for the release team (so each team would have a central repository but you might pull changes from one into the other). All this is far easier with Git than with Subversion (and I've worked in situations in the past where something like what I just described would have saved a lot of heartache and angst between teams).

But generally your point about Git being more complicated to use is absolutely correct and, sadly, when you ask for help you don't always get a nice answer (sometimes it's more along the lines of 'well the manuals say you shouldn't do that so you did it anyway now you're screwed and it serves you right for not understanding the internals of our magically wondrous system). So... Git *is* awesome, I'm really glad that my company uses it but it does have a very steep learning curve.

In terms of ease of use I quite like the look of Kiln which is some proprietary code wrapped around Mercurial and looks relatively easy to use (in general my impression is that Mercurial is easier to use). That said - Git is free...

I hope that helps I'm certainly not an expert with the finer points of Git but I'm happy to tell you what I know if you're interested (even if you stay with whatever you use if you're more informed then you're still going to make better decisions)....

-mark

Comment: Re:pardon, your ignorance is showing (Score 1) 244

by macbutch (#34265230) Attached to: An Illustrated Version Control Timeline

Git will be faster and (much) more reliable.

CVS can lose your history without you noticing, Git won't do that. I've had subversion repositories become corrupted. On the other hand a) if a Git repository is corrupted then you know and b) in a worst case you can restore from one of the clones (as every developer has a clone of the central repository).

Comment: Re:pardon, your ignorance is showing (Score 1) 244

by macbutch (#34262596) Attached to: An Illustrated Version Control Timeline

Git would still be much faster for almost every operation than Subversion.

We have a small team but switching to Git from Subversion meant that check outs actually took measurably less time despite being a full copy of the repository rather than just the most recent revision.

Admittedly Subversion is probably a particularly bad example of non-DVCS but still...

Encryption

OpenSSH 5.4 Released 127

Posted by timothy
from the but-it's-secret dept.
HipToday writes "As posted on the OpenBSD Journal, OpenSSH 5.4 has been released: 'Some highlights of this release are the disabling of protocol 1 by default, certificate authentication, a new "netcat mode," many changes on the sftp front (both client and server) and a collection of assorted bugfixes. The new release can already be found on a large number of mirrors and of course on www.openssh.com.'"

Comment: Re:Linking to Realclimate is not the best idea (Score 1) 874

by macbutch (#30313744) Attached to: Scientists Step Down After CRU Hack Fallout

Thats insane - if someone publishes a paper and objections are raised then the *first* person you should look to for a response is the original author. Giving the right to reply is normal just about anywhere (e.g. http://www.bbc.co.uk/guidelines/editorialguidelines/edguide/fairness/rightofreply.shtml*). It is completely nuts to say that because someone has been criticised they're then out of the discussion because they'll try to defend themselves.

Beyond that:

So to see a site that is run by Mann and others he agrees with supporting him, well that doesn't really say much, does it?

It really depends on what they have to say doesn't it? If they're making poor arguments and fail to respond to criticism and just continue to restate the original argument then that would be bad. On the other hand what seems to be the case is that a group of scientists have grouped together to engage their critics and make clear responses and explanations where their original argument was unclear or misunderstood etc. Surely that is exactly what they should do?

* right of reply in a journalistic sense is slightly different but the concept is the same/similar

Comment: Re:It's Not About Health, It's About Control (Score 1) 1698

by macbutch (#30023028) Attached to: Landmark Health Insurance Bill Passes House

Once the government is paying for your health care, they can pretty much mandate what you eat, what you smoke, what you drink, how long you live, etc.

Yeah... because that happens all the time in other countries I can see how you'd be scared of health care that actually works.

wtf?

Comment: Re:Evolution or just surving? (Score 1) 461

by macbutch (#29793407) Attached to: Observing Evolution Over 40,000 Generations

Are you kidding? This is insightful...?

First up - citrate is not an 'adverse condition' it is just something that the original bacteria were unable to use as a food source. That is not 'unable to use well' but unable to use *at all* - so if you put the original bacteria in a solution of only citrate (and no glucose) the population would not be able to grow due to lack of food but not because the citrate is harmful - they need glucose. So you're out right wrong to say that they already could metabolise it - that is really the whole point and if you'd read the article you'd know that btw - same for the morons that modded you insightful. If there was an 'adverse condition' then that would be that the amount of glucose in the solution was limited so that the bacteria would exhaust it everyday.

In an attempt to clarify why this is so interesting - the experiment* was to put the original strain in a solution of glucose and citrate - only the glucose was the limiting factor in the growth of the bacteria - as when the glucose was exhausted the bacteria could no longer continue to grow. This was repeated - so at the end of each day an extract of the bacteria in a phial would be extracted and put into a new phial of solution containing glucose and citrate.

The expected result - which kind of matches what you're describing, I think - is that subsequent generations would become more efficient at metabolising glucose and thats exactly what happened up to a point (and yes this is tweaking of an ability that was already there in that the bacteria was already able to metabolise glucose but they become more efficient at it). The really interesting thing is that after a while thousands of generations the bacteria evolved the ability to metabolise citrate - something that it could not do at all before.

Linking all this back to the summary - there were 45 mutations that they measured which were mostly related to the increased efficiency of glucose use (one of which was larger cell size, I believe). After the the ability to use citrate as a food source there was a much larger number of mutations (653) but more of these later mutations were neutral whereas the earlier mutations were largely about more efficient use of food. Anyway - the point of this new paper (as opposed to the original one which was about evolving to use citrate) is about measuring and observing rates of evolutionary change.

* disclaimer - my descriptions are largely based from memory, I don't have time to re-read the details and I may have a few points wrong. If there is a biologist around I'm sure they'll be able to correct me - however I am 100% certain that the original strain can not metabolise citrate as that is a large part of why this research is so impressive (the other part is the detailed level of record keeping that they've done to the point where they have frozen examples of the bacterial strain for every few hundred (few thousand? I forget the details) generations going back 20 years or more (hence they're able to do a lot of work from this - the citrate metabolism is just one part of that).

Medicine

Study Finds the Pious Fight Death Hardest 921

Posted by timothy
from the would-like-a-mulligan-please dept.
Stanislav_J writes "A US study suggests that people with strong religious beliefs appear to want doctors to do everything they can to keep them alive as death approaches. The study, following 345 patients with terminal cancer, found that 'those who regularly prayed were more than three times more likely to receive intensive life-prolonging care than those who relied least on religion.' At first blush, this appears paradoxical; one would think that a strong belief in an afterlife would lead to a more resigned acceptance of death than nonbelievers who view death as the end of existence, the annihilation of consciousness and the self. Perhaps the concept of a Judgment produces death-bed doubts? ('Am I really saved?') Or, given the Judeo-Christian abhorrence of suicide, and the belief that it is God who must ultimately decide when it is 'our time,' is it felt that refusing aggressive life support measures or resuscitation is tantamount to deliberately ending one's life prematurely?"

Ma Bell is a mean mother!

Working...