February 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] petsc-dev on bitbucket
by Sean Farley 10 Feb '12

10 Feb '12

> > As I understand it - for more than 5 folks to be able to access a > private repo - one needs to be on a paid plan with bitbucket. [not a > big deal - but want to put that up front] > Not for educational accounts. Any email that has an .edu is automatically put in that plan.

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Satish Balay 10 Feb '12

10 Feb '12

On Fri, 10 Feb 2012, Barry Smith wrote: > > On Feb 10, 2012, at 9:13 AM, Matthew Knepley wrote: > > > The thread has become too deep for me to read, hence the top posting. > > > > Barry's question is the right one: What do we gain by changing? > > > > 1) Reliability and Availability > > > > Barry, you should know that this crap about petsc.cs being backed up is farcical. We > > would have the same situation we had with the first 10 years of PETSc history again. > > BB is definitely more reliable in terms of backups, uptime, and connectivity (SSH issues). > > > > 2) Better management support > > > > The infrastructure for supporting user permissions is better on BB. We don't edit a file, > > calling a script someone hacked together. We have accounts, and when accounts are > > shut down they go away. A user can manage his SSH key independently of us. > > > > Those for me make it a slam dunk. However, I will ask the question in reverse: What do we > > give up? > > I decent way of hierarchically organizing our repositories. Tell me how to do this on bitbucket and you have your slam dunk. > Also some discussion on private repos. I guess none of you have objections for hosting private [for all kinds of collaboration work] at bitbucket. [I don't claim 'iit' is better - for some work 'mcs' hosting was prefered]. Also lot of this work collabartion stuff is hosted at google docs - so I guess this isn't an issue. As I understand it - for more than 5 folks to be able to access a private repo - one needs to be on a paid plan with bitbucket. [not a big deal - but want to put that up front] > > I think the only thing we give up is the security blanket of being able to log in > > ourselves and mess with a machine directly. For some things its was easier to do it ourselves than wait for someone else [aka admin to do things.] I think there was a significant benefit with this [for a lot of issues that came up in the past few years.] Satish

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Jed Brown 10 Feb '12

10 Feb '12

On Fri, Feb 10, 2012 at 09:30, Matthew Knepley <knepley(a)gmail.com> wrote: > I decent way of hierarchically organizing our repositories. Tell me how >> to do this on bitbucket and you have your slam dunk. > > > Mailing BB. > https://bitbucket.org/site/master/issue/2323/create-folders-to-organize-the…

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Matthew Knepley 10 Feb '12

10 Feb '12

On Fri, Feb 10, 2012 at 9:23 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 10, 2012, at 9:13 AM, Matthew Knepley wrote: > > > The thread has become too deep for me to read, hence the top posting. > > > > Barry's question is the right one: What do we gain by changing? > > > > 1) Reliability and Availability > > > > Barry, you should know that this crap about petsc.cs being backed up > is farcical. We > > would have the same situation we had with the first 10 years of PETSc > history again. > > BB is definitely more reliable in terms of backups, uptime, and > connectivity (SSH issues). > > > > 2) Better management support > > > > The infrastructure for supporting user permissions is better on BB. > We don't edit a file, > > calling a script someone hacked together. We have accounts, and when > accounts are > > shut down they go away. A user can manage his SSH key independently > of us. > > > > Those for me make it a slam dunk. However, I will ask the question in > reverse: What do we > > give up? > > I decent way of hierarchically organizing our repositories. Tell me how > to do this on bitbucket and you have your slam dunk. Mailing BB. Matt > > Barry > > > > I think the only thing we give up is the security blanket of being able > to log in > > ourselves and mess with a machine directly. > > > > Matt > > > > On Fri, Feb 10, 2012 at 8:26 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 9, 2012, at 11:15 PM, Sean Farley wrote: > > > > > > > > Even if you were right about this specific issue (which you are not) > it doesn't matter. All you've done is removed the need for a releases > subdirectory. What about tutorials subdirectory, externalpackages > subdirectory, anothercoolthingwethinkofnextweek subdirectory. > > > > > > Why does the *server* have to have the subdirectory? > > > > Because I want to have a bunch of repositories organized in a > hierarchical manner. You response seems to be: > > > > 1) no you don't want that or > > > > 2) you should put them all in one giant repository or > > > > 3) have them in different bitbucket accounts (like a petsc account and a > externalpackages account) that have nothing to do with each other. > > > > Just admit that not supporting a directory structure at bitbucket is > lame and stop coming up with lame reasons why it is ok. Then get bitbucket > to add this elementary support and we'll be all set. > > > > Barry > > > > > > > > > > > > > > $ hg clone bb://petsc/anothercoolthing > subdirectory-that-can-suck-eggs/anothercoolthing > > > > > > Please explain to me the real reasons bitbucket is better than > petsc.cs. and stop rationalizing around bitbuckets weaknesses. Every > choice has some tradeoffs and I haven't heard much about bitbuckets > advantages so I am confused why you guys are so in love with it. (Well I > understand Sean's reasons, being pretty lazy myself :-)). > > > > > > I'll let Jed explain about forks and have the reverse look-up (how > many people have forked petsc). For me, it's drop-dead simple management. > > > > > > > > > > -- > > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > > -- Norbert Wiener > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Barry Smith 10 Feb '12

10 Feb '12

On Feb 10, 2012, at 9:13 AM, Matthew Knepley wrote: > The thread has become too deep for me to read, hence the top posting. > > Barry's question is the right one: What do we gain by changing? > > 1) Reliability and Availability > > Barry, you should know that this crap about petsc.cs being backed up is farcical. We > would have the same situation we had with the first 10 years of PETSc history again. > BB is definitely more reliable in terms of backups, uptime, and connectivity (SSH issues). > > 2) Better management support > > The infrastructure for supporting user permissions is better on BB. We don't edit a file, > calling a script someone hacked together. We have accounts, and when accounts are > shut down they go away. A user can manage his SSH key independently of us. > > Those for me make it a slam dunk. However, I will ask the question in reverse: What do we > give up? I decent way of hierarchically organizing our repositories. Tell me how to do this on bitbucket and you have your slam dunk. Barry > I think the only thing we give up is the security blanket of being able to log in > ourselves and mess with a machine directly. > > Matt > > On Fri, Feb 10, 2012 at 8:26 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 9, 2012, at 11:15 PM, Sean Farley wrote: > > > > > Even if you were right about this specific issue (which you are not) it doesn't matter. All you've done is removed the need for a releases subdirectory. What about tutorials subdirectory, externalpackages subdirectory, anothercoolthingwethinkofnextweek subdirectory. > > > > Why does the *server* have to have the subdirectory? > > Because I want to have a bunch of repositories organized in a hierarchical manner. You response seems to be: > > 1) no you don't want that or > > 2) you should put them all in one giant repository or > > 3) have them in different bitbucket accounts (like a petsc account and a externalpackages account) that have nothing to do with each other. > > Just admit that not supporting a directory structure at bitbucket is lame and stop coming up with lame reasons why it is ok. Then get bitbucket to add this elementary support and we'll be all set. > > Barry > > > > > > > > $ hg clone bb://petsc/anothercoolthing subdirectory-that-can-suck-eggs/anothercoolthing > > > > Please explain to me the real reasons bitbucket is better than petsc.cs. and stop rationalizing around bitbuckets weaknesses. Every choice has some tradeoffs and I haven't heard much about bitbuckets advantages so I am confused why you guys are so in love with it. (Well I understand Sean's reasons, being pretty lazy myself :-)). > > > > I'll let Jed explain about forks and have the reverse look-up (how many people have forked petsc). For me, it's drop-dead simple management. > > > > > -- > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. > -- Norbert Wiener

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Satish Balay 10 Feb '12

10 Feb '12

On Fri, 10 Feb 2012, Satish Balay wrote: > > With Bitbucket, GitHub, and all the others, the web account is *not* a unix > > account. It's just a way to manage identity/keys. Everyone using ssh has > > hg(a)bitbucket.org (and git(a)github.com, etc). > > sure the implemtation details are different - but I mean - the top > level models as I described are equivalent - and can be implemented > equivallly. > > Yesh all users go though a single unix account [for ssh] - and a > [thats implementation detail - and it shouldnm't matter]. Ok - I'll agree the account management at Bitbucket is better than what we have at petsc.cs.iit.edu [esp when one is involved in multiple projects hosted at bitbucket]. wrt the other 2 issues yo've raised: 1. fail2ban blocking on messages of the following type: Oct 24 14:48:15 petsc sshd[1782]: Address 71.74.181.122 maps to cpe-71-74-181-122.mi.res.rr.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! fixed fail2ban to ignore these messages. 2: ssh not working from crappy networks [aka istanbul airport] - so https is preferable. Here - I'll say its more about port 22 being blocked - and port 443 beeing open. So I'm having ssh listen on port 443 aswell. [there are multiple ways of doing this. I'm currently using ipatbles for this. Will see how stable the current approach is]. from ~/.ssh/config host petsc-ssh-over-https.cs.iit.edu HostName petsc.cs.iit.edu Port 443 asterix:/home/balay/spetsc>hg pull ssh://[email protected]://hg/petsc/petsc-dev running ssh petsc(a)petsc-ssh-over-https.cs.iit.edu 'hg -R /hg/petsc/petsc-dev serve --stdio' pulling from ssh://[email protected]//hg/petsc/petsc-dev searching for changes no changes found asterix:/home/balay/spetsc> Some migh prefer https [esp windows] - becase its easier to completely avoid dealing with ssh. This can also be fixed on petsc.cs.iit - but since this is not elegant - I'll avoid that. You guys can still decide on moving over to bitbucket though.. Satish

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Matthew Knepley 10 Feb '12

10 Feb '12

The thread has become too deep for me to read, hence the top posting. Barry's question is the right one: What do we gain by changing? 1) Reliability and Availability Barry, you should know that this crap about petsc.cs being backed up is farcical. We would have the same situation we had with the first 10 years of PETSc history again. BB is definitely more reliable in terms of backups, uptime, and connectivity (SSH issues). 2) Better management support The infrastructure for supporting user permissions is better on BB. We don't edit a file, calling a script someone hacked together. We have accounts, and when accounts are shut down they go away. A user can manage his SSH key independently of us. Those for me make it a slam dunk. However, I will ask the question in reverse: What do we give up? I think the only thing we give up is the security blanket of being able to log in ourselves and mess with a machine directly. Matt On Fri, Feb 10, 2012 at 8:26 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 9, 2012, at 11:15 PM, Sean Farley wrote: > > > > > Even if you were right about this specific issue (which you are not) it > doesn't matter. All you've done is removed the need for a releases > subdirectory. What about tutorials subdirectory, externalpackages > subdirectory, anothercoolthingwethinkofnextweek subdirectory. > > > > Why does the *server* have to have the subdirectory? > > Because I want to have a bunch of repositories organized in a > hierarchical manner. You response seems to be: > > 1) no you don't want that or > > 2) you should put them all in one giant repository or > > 3) have them in different bitbucket accounts (like a petsc account and a > externalpackages account) that have nothing to do with each other. > > Just admit that not supporting a directory structure at bitbucket is > lame and stop coming up with lame reasons why it is ok. Then get bitbucket > to add this elementary support and we'll be all set. > > Barry > > > > > > > > $ hg clone bb://petsc/anothercoolthing > subdirectory-that-can-suck-eggs/anothercoolthing > > > > Please explain to me the real reasons bitbucket is better than petsc.cs. > and stop rationalizing around bitbuckets weaknesses. Every choice has some > tradeoffs and I haven't heard much about bitbuckets advantages so I am > confused why you guys are so in love with it. (Well I understand Sean's > reasons, being pretty lazy myself :-)). > > > > I'll let Jed explain about forks and have the reverse look-up (how many > people have forked petsc). For me, it's drop-dead simple management. > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] DMGetMatrix --> DMGetMatrices?
by Matthew Knepley 10 Feb '12

10 Feb '12

On Fri, Feb 10, 2012 at 12:05 AM, Dmitry Karpeev <karpeev(a)mcs.anl.gov>wrote: > > > On Fri, Feb 10, 2012 at 12:01 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> On Thu, Feb 9, 2012 at 23:55, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: >> >>> In a somewhat related matter, it appears that I cannot duplicate a >>> preallocated MATXXXAIJ until it has been assembled: >>> if my DM implementation keeps a preallocated MATSEQAIJ, which it wants >>> to duplicate on every call to DMGetMatrix, >>> it would have to put in fake entries before any duplication is possible. >>> >> >> Doesn't it already do this (inserting 0)? >> > I don't think so. Preallocating doesn't set any values and seems to leave > the matrix marked !assembled. > MatDuplicate for such a matrix will fail. Assemblying it before setting > values (just to force an assembled flag) > will squeeze out the extra values, won't it? I think it would just be > reasonable to allow to duplicate unassembled > matrices, or, better yet, have a matrix be "assembled" by default until > MatSetValues has been called. > But I'm not sure whether either solution will break something else. > Actually, preallocating does do this now. I have to change the unstructured code to do it. Matt > Dmitry. > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] petsc-dev on bitbucket
by Barry Smith 10 Feb '12

10 Feb '12

On Feb 9, 2012, at 11:15 PM, Sean Farley wrote: > > Even if you were right about this specific issue (which you are not) it doesn't matter. All you've done is removed the need for a releases subdirectory. What about tutorials subdirectory, externalpackages subdirectory, anothercoolthingwethinkofnextweek subdirectory. > > Why does the *server* have to have the subdirectory? Because I want to have a bunch of repositories organized in a hierarchical manner. You response seems to be: 1) no you don't want that or 2) you should put them all in one giant repository or 3) have them in different bitbucket accounts (like a petsc account and a externalpackages account) that have nothing to do with each other. Just admit that not supporting a directory structure at bitbucket is lame and stop coming up with lame reasons why it is ok. Then get bitbucket to add this elementary support and we'll be all set. Barry > > $ hg clone bb://petsc/anothercoolthing subdirectory-that-can-suck-eggs/anothercoolthing > > Please explain to me the real reasons bitbucket is better than petsc.cs. and stop rationalizing around bitbuckets weaknesses. Every choice has some tradeoffs and I haven't heard much about bitbuckets advantages so I am confused why you guys are so in love with it. (Well I understand Sean's reasons, being pretty lazy myself :-)). > > I'll let Jed explain about forks and have the reverse look-up (how many people have forked petsc). For me, it's drop-dead simple management.

1 0

Re: [petsc-dev] DMGetMatrix --> DMGetMatrices?
by Jed Brown 10 Feb '12

10 Feb '12

On Fri, Feb 10, 2012 at 00:05, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > I don't think so. Preallocating doesn't set any values and seems to leave > the matrix marked !assembled. > MatDuplicate for such a matrix will fail. Assemblying it before setting > values (just to force an assembled flag) > will squeeze out the extra values, won't it? I think it would just be > reasonable to allow to duplicate unassembled > matrices, or, better yet, have a matrix be "assembled" by default until > MatSetValues has been called. > But I'm not sure whether either solution will break something else. > Are you calling DMSetMatrixPreallocateOnly()?

1 0