[9fans] Plan9 Sources Repository

[9fans] Plan9 Sources Repository

[dante]

Dear 9Fans,

I see that Bell Labs offers a sources repository of Plan9, that is
kindly kept up-to-date by volonteers (thanks!).

Yet: is there a source control system behind it?
Would it be possible to check out directly from there?

If there is none, could it be that this contributes to the lack of
popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy,
PlanB, other plans...)?

Kind Regards,
Dante

Re: [9fans] Plan9 Sources Repository

[Aram Hăvărneanu]

Sources is not kept up-to-date by volunteers, unless you mean
contrib, it is maintained by the Labs. Also, in a way, the sources
server *is* Plan 9, rather than being updated *with* Plan 9.

Plan 9 doesn't traditionally use version control. Rather, most
disk-based Plan 9 file servers offer some form of history in the
form of dumps or snapshots. 9fs sourcesdump will mount the sources
dump, and you can inspect daily changes starting around some 12
years ago using regular Plan 9 tools such as editors, yesterday(1)
and diffy(1).

History management is superior in Plan 9 compared to git and
mercurial. What git does better (at least according to some people),
is patch management. The Labs and 9atom use some patch management
technology best described in their manuals rather than on the mailing
list. 9front uses mercurial for patch management.

-- 
Aram Hăvărneanu

Re: [9fans] Plan9 Sources Repository

[cam]

> Yet: is there a source control system behind it?
> Would it be possible to check out directly from there?

for the bell-labs distribution, the filesystem itself keeps
a daily record of the source tree.  you can access it with
9fs sourcesdump and the daily state of sources will be
in /n/sourcesdump.

> If there is none, could it be that this contributes to the lack of
> popularity

9front and 9legacy both use mercurial as their revision
control systems.  9legacy keeps a mirror of the bell-labs
distribution in mercurial as well if that suits your needs.

9front's repo:

http://code.google.com/p/plan9front

9legacy's various repositories and mirrors:

https://hg.9grid.fr/

> and to the fragmentation of Plan9 (9front, 9atom, 9legacy,
> PlanB, other plans...)?

the reason for the different distributions is really no
different than the motivation for the different bsd or
linux distributions:  they each have their own goals
and purpose.

Re: [9fans] Plan9 Sources Repository

[erik quanstrom]

> Yet: is there a source control system behind it?
> Would it be possible to check out directly from there?

there is nothing most folks would recognize as a distributed
revision control system.

the repo is sources itself.  history is through history(1).
you can "check out" code with cp(1), tar(1), mkfs(8); you can
keep up with the repo with replica(1).

patches are submitted via patch(1).

> If there is none, could it be that this contributes to the lack of
> popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy,
> PlanB, other plans...)?

i would think the "lack of popularity" can be most directly attributed
to the closed license in the early 90s, when there was an unfilled niche,
and linux was seriously lacking.

i starting doing something slightly different when il was pulled from
the distribution while i was in no position to stop using it.  it had nothing
to do with source control.

- erik

Re: [9fans] Plan9 Sources Repository

[dante]

I would like first to thank everyone for the kind replies!
Each was useful in it's own way.

On 18.07.2014 16:36, erik quanstrom wrote:
>> Yet: is there a source control system behind it?
>> Would it be possible to check out directly from there?
>
> there is nothing most folks would recognize as a distributed
> revision control system.
>
> the repo is sources itself.  history is through history(1).
> you can "check out" code with cp(1), tar(1), mkfs(8); you can
> keep up with the repo with replica(1).
>
> patches are submitted via patch(1).

I would argument that the Status Quo has the following disadvantages
when compared to the the current usual way of doing things:

1. The history is confined to Plan9.
     It is hard to do small fixes (typos, documentation) from another
system.

2. There are no commit comments.
     There is no "blame" command.
     There are no release tags (allowing for unstable work in between).
     There are no branches (allowing for collective work on an unstable
version). OK, my machine is my branch...

3. Contrib packages are tied to people; there is no common repository.
     This leads to the situation where you can't update a package of a
long gone user.
     Please tell me how many Mercurial packages you can find in Contrib!

I maintain my impression that the Status Quo, though good for a small
team, does not allow the project to grow.
Were there any efforts to change this?
Or is it a controversial matter and it stays as it is?
Or is the team indeed so small (or even loosing members), s.t. that a
change won't make sense?

Kind Regards,
Dante

>
>> If there is none, could it be that this contributes to the lack of
>> popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy,
>> PlanB, other plans...)?
>
> i would think the "lack of popularity" can be most directly attributed
> to the closed license in the early 90s, when there was an unfilled
> niche,
> and linux was seriously lacking.
>
> i starting doing something slightly different when il was pulled from
> the distribution while i was in no position to stop using it.  it had
> nothing
> to do with source control.
>
> - erik

Re: [9fans] Plan9 Sources Repository

[Riddler]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

You are not the first one to bring this up. There is a chain titled
"CMS/MMS (VCS/SCM/DSCM) [was syscall 53]" that discusses it. I'd suggest
giving it a skim if you can find it in the archives.

That said, in my opinion:

> 1. The history is confined to Plan9.
>     It is hard to do small fixes (typos, documentation) from another
system.

I agree.

> 2. There are no commit comments.
>     There is no "blame" command.
>     There are no release tags (allowing for unstable work in between).
>     There are no branches (allowing for collective work on an unstable
version). OK, my machine is my branch...

I recall reading in one of the wiki pages that there is a procedure to get
a historical list of patches applied to the main sources and a message to
go with it (might have been just a readme file). I took a quick look and
can't find it again, perhaps someone else knows?

> 3. Contrib packages are tied to people; there is no common repository.
>     This leads to the situation where you can't update a package of a
long gone user.
>     Please tell me how many Mercurial packages you can find in Contrib!

I don't see how a repository would fix this. When the user is gone you
would still lose the only person with write access to the repo. You would
need to fork it. The only difference is now people just copy it.

What's really missing is an index of what current versions live where. Or
at least if it exists I am not aware of it.

> I maintain my impression that the Status Quo, though good for a small
team, does not allow the project to grow.
> Were there any efforts to change this?
> Or is it a controversial matter and it stays as it is?
> Or is the team indeed so small (or even loosing members), s.t. that a
change won't make sense?

In the short time I've been here I think its came up twice. So it is
something at least some people are interested in looking at. I'm sure it
will keep coming up.

[-- Attachment #2: Type: text/html, Size: 2287 bytes --]

Re: [9fans] Plan9 Sources Repository

[pmarin]

Plan9 in general doesn't follow the Bazaar model ( the current usual
way of doing things ).



On Sat, Jul 19, 2014 at 11:31 AM, dante <subscriptions@posteo.eu> wrote:
> I would like first to thank everyone for the kind replies!
> Each was useful in it's own way.
>
>
> On 18.07.2014 16:36, erik quanstrom wrote:
>>>
>>> Yet: is there a source control system behind it?
>>> Would it be possible to check out directly from there?
>>
>>
>> there is nothing most folks would recognize as a distributed
>> revision control system.
>>
>> the repo is sources itself.  history is through history(1).
>> you can "check out" code with cp(1), tar(1), mkfs(8); you can
>> keep up with the repo with replica(1).
>>
>> patches are submitted via patch(1).
>
>
> I would argument that the Status Quo has the following disadvantages when
> compared to the the current usual way of doing things:
>
> 1. The history is confined to Plan9.
>     It is hard to do small fixes (typos, documentation) from another system.
>
> 2. There are no commit comments.
>     There is no "blame" command.
>     There are no release tags (allowing for unstable work in between).
>     There are no branches (allowing for collective work on an unstable
> version). OK, my machine is my branch...
>
> 3. Contrib packages are tied to people; there is no common repository.
>     This leads to the situation where you can't update a package of a long
> gone user.
>     Please tell me how many Mercurial packages you can find in Contrib!
>
> I maintain my impression that the Status Quo, though good for a small team,
> does not allow the project to grow.
> Were there any efforts to change this?
> Or is it a controversial matter and it stays as it is?
> Or is the team indeed so small (or even loosing members), s.t. that a change
> won't make sense?
>
> Kind Regards,
> Dante
>
>
>>
>>> If there is none, could it be that this contributes to the lack of
>>> popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy,
>>> PlanB, other plans...)?
>>
>>
>> i would think the "lack of popularity" can be most directly attributed
>> to the closed license in the early 90s, when there was an unfilled niche,
>> and linux was seriously lacking.
>>
>> i starting doing something slightly different when il was pulled from
>> the distribution while i was in no position to stop using it.  it had
>> nothing
>> to do with source control.
>>
>> - erik
>
>

Re: [9fans] Plan9 Sources Repository

[dante]

Hi,

On 19.07.2014 13:20, Riddler wrote:
>> 3. Contrib packages are tied to people; there is no common 
>> repository.
>  >     This leads to the situation where you can't update a package
> of a long gone user.
>  >     Please tell me how many Mercurial packages you can find in 
> Contrib!
> 
> I don't see how a repository would fix this. When the user is gone
> you would still lose the only person with write access to the repo.
> You would need to fork it. The only difference is now people just copy
> it.

Well, it takes 1 minute to "hg mv" a project from 
long_gone_user/project to contrib/project.
As it is now, I have to convince the master to *create* the central 
contrib repository, then to copy the project there etc.
Moreover, as the stuff is now spread all around, it is hard to set up a 
nightly build for all the stuff.

As I said, the status quo is perfect for a small team, but I doubt that 
is encourages the project to get some traction.

>> I maintain my impression that the Status Quo, though good for a small 
>> team, does not allow the project to grow.
>  > Were there any efforts to change this?
>  > Or is it a controversial matter and it stays as it is?
>  > Or is the team indeed so small (or even loosing members), s.t.
> that a change won't make sense?
> 
> In the short time I've been here I think its came up twice. So it is
> something at least some people are interested in looking at. I'm sure
> it will keep coming up.

I could help (a bit, time permitting), but I think that the most 
important thing is to get support from the current project maintainers 
(the people you submit patches to).
This discussion can only be started by the veterans.
I think that a solution that does not increase the burden on the 
current volunteer maintainers is possible.

What do you people think?

Kind Regards,
Dante

Re: [9fans] Plan9 Sources Repository

[dante]

On 19.07.2014 13:49, pmarin wrote:
> Plan9 in general doesn't follow the Bazaar model ( the current usual
> way of doing things ).

And this might lead to the problems pointed in my previous mails.
Or not, I might be wrong.

Kind Regards,
Dante

Re: [9fans] Plan9 Sources Repository

[dante]

This was an unfair statement from you, pmarin.
You make me answer twice.

I did not imply anywhere that I proposed the bazaar model (whatever
that is, no one wants the Linux .
Scalability is also possible in projects maintained by a central
authority.

My whole argument goes about the following hypotheses:
1. increasing the amount of contributions may not scale in the current
model.
2. submitting trivial contributions is not trivial for the contributor.

Kind Regards,
Dante

On 19.07.2014 13:51, dante wrote:
> On 19.07.2014 13:49, pmarin wrote:
>> Plan9 in general doesn't follow the Bazaar model ( the current usual
>> way of doing things ).
> And this might lead to the problems pointed in my previous mails.
> Or not, I might be wrong.
> Kind Regards,
> Dante

Re: [9fans] Plan9 Sources Repository

[tlaronde]

On Sat, Jul 19, 2014 at 01:49:10PM +0200, pmarin wrote:
>
> Plan9 in general doesn't follow the Bazaar model ( the current usual
> way of doing things ).
>
The Bazaar model is the one for not doing or undoing.

Small is beautiful. The attraction for Plan9 is its consistency and size.

As far as I'm concerned, the current organization is not a drawback
from contributing more---time is. Another organization will not
offer, for me, more opportunity to contribute. When I have something
to contribute (and for now, this is only user level kerTeX), nothing
impeds me from doing.

This is for user level.

For kernel, the problems may be more involved. But clearly, the number
of persons able to contribute is far more limited. And consistency shall
be the primary aim. So an organization good for a "small team" is an
organization good for kernel level.

My 1 cent,
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
              http://www.renaissance-francaise.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Plan9 Sources Repository

[dante]

Please, be so kind and stop this "Bazaar" thread.

The proposal was to use some maybe more scalable tools while
maintaining the current responsibilities.
This could allow for more contributions to be done with the same burden
for the maintainers.

An example for what it's worth could be OpenBSD.
They have AFAIK a central package system with a couple of maintainers
and nightly builds and many-many contributors.

Not Linux. Linux is nowadays so complex that no one can understand the
whole kernel.
Linux is IMHO way too lax about new, orthogonal interfaces,
functionality overlap and rewriting in a different flavour.

Kind Regards,
Dante


On 19.07.2014 14:03, tlaronde@polynum.com wrote:
> On Sat, Jul 19, 2014 at 01:49:10PM +0200, pmarin wrote:
>>
>> Plan9 in general doesn't follow the Bazaar model ( the current usual
>> way of doing things ).
>>
> The Bazaar model is the one for not doing or undoing.
>
> Small is beautiful. The attraction for Plan9 is its consistency and
> size.
>
> As far as I'm concerned, the current organization is not a drawback
> from contributing more---time is. Another organization will not
> offer, for me, more opportunity to contribute. When I have something
> to contribute (and for now, this is only user level kerTeX), nothing
> impeds me from doing.
>
> This is for user level.
>
> For kernel, the problems may be more involved. But clearly, the number
> of persons able to contribute is far more limited. And consistency
> shall
> be the primary aim. So an organization good for a "small team" is an
> organization good for kernel level.
>
> My 1 cent,
> --
>         Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
>                       http://www.kergis.com/
>               http://www.renaissance-francaise.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Plan9 Sources Repository

[erik quanstrom]

> 1. The history is confined to Plan9.
>      It is hard to do small fixes (typos, documentation) from another
> system.

that's true.  but it's easy to get a plan 9 system, or drawterm into one.
in my experience, plan 9 is a system one spends siginficant time in.

i would not want to change the system to support foreign patches unless
it's a proven issue, and experiments show that such patches are of equal
quailty to ones made from a plan 9 system.

solutions like hg pull python into the system as a hard requirement, and
i wouldn't want to make (more) external things like python a hard
requirement, if possible.  also, python doesn't currently work on
arm or mips, so it would making the minimum requirements for a plan 9
system much greater.

> 2. There are no commit comments.
>      There is no "blame" command.

but there is!  history(1) will display the last modifier of the file.
in plan 9 the rule typically is: you touch it, you own it.

>      There are no release tags (allowing for unstable work in between).
>      There are no branches (allowing for collective work on an unstable
> version). OK, my machine is my branch...

it's just a different model.

given your questions, i am wondering if you have spent much time with
the system.  especially one with history enabled.

- erik

Re: [9fans] Plan9 Sources Repository

[Aram Hăvărneanu]

On Sat, Jul 19, 2014 at 11:31 AM, dante <subscriptions@posteo.eu> wrote:
> It is hard to do small fixes (typos, documentation) from another system.

One could argue this is a feature. Everything has to be tested.
I've seen way too many botched patches that purportedly only fixed
documentation. Also, how do you write documentation if you don't
use the system?

Typos are not worth fixing unless it is done systematically and
many errors are corrected at once, otherwise they just create noise
and break existing patches creating merge nightmares.

This is true even with git, typos impact the precision of bisect
and blame. Every change starts at -100 points. Unless the net benefit
is positive it shouldn't go in. A change fixing a typo only gets
you up to -99 points. It's not worth it.

>From my experience with Plan 9 and many other different open source
projects like Linux, OpenBSD and Go, patches coming from people not
really using the system are of very low quality. Changing the model
is very disruptive and would not bring any more good contributions.

Plan 9 is easy to get if you want it.

> There are no commit comments.

Actually patches do have comments. The filesystem doesn't carry any
metadata. Maybe it should, more likely it shouldn't; a changelog
file is easy to write, one could even automate it from existing
patch metadata.

There is a net benefit to be gained, but the benefit is small,
otherwise somebody would have done the work. One property of the
existing model is that it works. You are proposing a new model, as
if the existing model doesn't work. But it does.

> There are no release tags.

It's just a different model. There's no evidence that one is superior
to the other.

> There are no branches.

Actually, Plan 9 private namespaces give you branches and much more.
You can pick and choose; assemble any number of views over the tree
as you like. You see, you're criticizing the Plan 9 development
model by thinking in traditional terms. The Plan 9 model is simpler,
perhaps too simple for Unix software, but Plan 9 is not Unix.
Combining the Plan 9 model with orthogonal Plan 9 primitives gives
you a much richer and cleaner environment that all falls naturally
from the design of the system, rather than having all features
backed in the vcs blob.

-- 
Aram Hăvărneanu

Re: [9fans] Plan9 Sources Repository

[dante]

Hi Eric,

Thanks for your answers! They are really a good start for me with
Plan9.

So, you and the others convinced me that a source management system for
the main system is not really necessary.
What's left from my initial questions is if it won't be a bad idea to
have an integrated contrib (or packages) system.

Refined proposal:

1. Gather the good packages from the user's directories and other
sources on the net into a central system, like the core Plan9.
     There is some work implied to check licenses and get permissions.

2. Someone should filter the subsequent submissions, just the same as
with the core Plan9 (work:).
     If you guys don't like source control systems, let patch(1) be it.

3. Set up a maintenance routine for the whole package system, like
regular builds on all architectures, not to speak of automated tests.
     Packages that fall out of the maintenance routine shall be removed
after a while.

4. What could also happen in the long run is that some software is
ported from POSIX/Ape/X11 to the native Plan9 interfaces.

What do you think, 9fans?

On 19.07.2014 16:41, erik quanstrom wrote:
> given your questions, i am wondering if you have spent much time with
> the system.  especially one with history enabled.

Sincerely: no. That's homework.

Kind Regards,
Dante

Re: [9fans] Plan9 Sources Repository

[Jacob Todd]

[-- Attachment #1: Type: text/plain, Size: 58 bytes --]

Are you intentionally trying to make plan  bureaucratic?

[-- Attachment #2: Type: text/html, Size: 76 bytes --]

Re: [9fans] Plan9 Sources Repository

[dante]

Usable, not bureaucratic.
And you don't need to invest work.
Just use it if you like it.

Take a look at how it works now. Is this OK with you?

1. "/n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib"
     Why do I need to know about "fgb", why not 
"/n/sources/packages/contrib/rc/bin/contrib/install contrib ?

2. bichued/hg -- 1.0.2
     jas/hg-src
     mjl/hgfs
     stallion/mercurial -- 2.2.3
     Which one now?

3. What about 
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ ?
     What about the broken links there?
     Can we still save that software?
     Archive.org?

Regards,
Dante

P.S. I knew that I will receive a certain amount of 
conservative/negative answers for questioning the Status Quo.
       I also got some very helpful ones, see Eric.

       Maybe this is the right moment to ask such questions.
       For years, Plan9 was hard to install on common hardware, lacking 
drivers (I tried more than once and failed).
       This all changed with Raspberry Pi.
       There is a good, stable (in the medium/long term) platform that 
costs next to nothing for people to play with Plan9.

       The core system is very elegant and flexible.
       Yet, I have the impression that some potential users may be put 
off by the lack of polish in some other places (installer, ports etc.).
       These potential users are also potential contributors.
       More mass could mean:
       - having a useable (like useable in 2014) Web browser
       - having a useable (or having one at all) video/media player
       - having an SSH2 server (there is one in 9atom, but I didn't see 
it in the stock Plan9). Are you sure it doesn't have the Heartbleed?
       - having a useable driver for touch pads or 2-button-plus-wheel 
mice. I couldn't find a 3-button mouse these days, and  clicking on the 
wheel is awful.
       - up-to-date versions of modern programming languages. I miss 
Ruby a lot.
       Wouldn't that be nice?

8D

On 19.07.2014 17:11, Jacob Todd wrote:
> Are you intentionally trying to make plan  bureaucratic?

Re: [9fans] Plan9 Sources Repository

[hiro]

> 1. Gather the good packages from the user's directories and other
> sources on the net into a central system, like the core Plan9.
>      There is some work implied to check licenses and get permissions.

Try 9front :)

Re: [9fans] Plan9 Sources Repository

[dante]

yes

On 19.07.2014 19:31, hiro wrote:
>> 1. Gather the good packages from the user's directories and other
>> sources on the net into a central system, like the core Plan9.
>>      There is some work implied to check licenses and get
>> permissions.
>
> Try 9front :)

Re: [9fans] Plan9 Sources Repository

[Kurt H Maier]

Quoting dante <subscriptions@posteo.eu>:

> Usable, not bureaucratic.

Lots of people already use plan 9, therefore it is already
useable.

> And you don't need to invest work.

This seems like a load of garbage, since you're already demanding
that other people do work to support your preferences.

>       This all changed with Raspberry Pi.
>       There is a good, stable (in the medium/long term) platform
> that costs next to nothing for people to play with Plan9.

The Raspberry Pi is not universally considered a good platform, but
maybe that's a discussion for a different thread.

>       Yet, I have the impression that some potential users may be
> put off by the lack of polish in some other places (installer, ports
> etc.).
>       These potential users are also potential contributors.

Why would anyone want patches from someone unwilling to learn how this
system works?

>       More mass could mean:
>       - having a useable (like useable in 2014) Web browser

We already have operating systems that focus on this nonsense.  Why
must plan 9 also?

>       - having a useable (or having one at all) video/media player

see above

>       - having an SSH2 server (there is one in 9atom, but I didn't
> see it in the stock Plan9). Are you sure it doesn't have the
> Heartbleed?

Are *you*?  Do you even know what heartbleed is?  Why would we throw plan
9's existing communications standards in the trash?  SSH is wildly
inferior and makes tons of assumptions about the hosts that only really
apply to unix or unix-wannabes.

>       - having a useable driver for touch pads or
> 2-button-plus-wheel mice. I couldn't find a 3-button mouse these
> days, and  clicking on the wheel is awful.

Almost every mouse for sale to day has three buttons.  Click your scroll
wheel.

>       - up-to-date versions of modern programming languages. I miss
> Ruby a lot.

If you want Ruby, you know where to find it.

>       Wouldn't that be nice?

No.

It sounds like you're trying to rewire the entire plan 9 community with the
goal of turning plan 9 into ubuntu with a plan 9 theme.  Why the hell would
anyone who appreciates what plan 9 has to offer be interested in these
enormous steps backwards?  Why don't you just use the operating systems that
already support all this crap?


khm

Re: [9fans] Plan9 Sources Repository

[erik quanstrom]

> 1. "/n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib"
>      Why do I need to know about "fgb", why not
> "/n/sources/packages/contrib/rc/bin/contrib/install contrib ?
>
> 2. bichued/hg -- 1.0.2
>      jas/hg-src
>      mjl/hgfs
>      stallion/mercurial -- 2.2.3
>      Which one now?

this is no different than any other system.  there are a number of
versions of ssl floating around google code, bitbucket and the like.

by the way, jas' python follows the tip, so it might be interesting.

> 3. What about
> http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ ?
>      What about the broken links there?
>      Can we still save that software?
>      Archive.org?

you may edit the wiki yourself to correct these issues.

>        Maybe this is the right moment to ask such questions.
>        For years, Plan9 was hard to install on common hardware, lacking
> drivers (I tried more than once and failed).
>        This all changed with Raspberry Pi.
>        There is a good, stable (in the medium/long term) platform that
> costs next to nothing for people to play with Plan9.

i agree with this.  many thanks to richard for putting this together.

>        - having a useable (like useable in 2014) Web browser
>        - having a useable (or having one at all) video/media player

this is an interesting problem.  keeping the core simple is in conflict
with the massive amount of code required for a usable-in-2014 browser.
i don't have a solution.

>        - having an SSH2 server (there is one in 9atom, but I didn't see
> it in the stock Plan9). Are you sure it doesn't have the Heartbleed?

i'm sure it doesn't have heartbleed.  code for that sort of renegotiation
was never written.

>        - having a useable driver for touch pads or 2-button-plus-wheel
> mice. I couldn't find a 3-button mouse these days, and  clicking on the
> wheel is awful.

i agree.  if you come up with a patch solving this problem, it will be
strongly considered for merging.

>        - up-to-date versions of modern programming languages. I miss
> Ruby a lot.
>        Wouldn't that be nice?

we might differ on this point.  :-)

- erik

Re: [9fans] Plan9 Sources Repository

[Anthony Sorace]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On Jul 19, 2014, at 8:02 , dante <subscriptions@posteo.eu> wrote:

> My whole argument goes about the following hypotheses:
> 1. increasing the amount of contributions may not scale in the current model.

Okay, it *may* not. But we have no evidence of that. There's no indication that the current distribution model represents a scaling problem (it may represent a higher barrier to entry, but that's a different claim). I'm pretty convinced (from using the system, and having worked in shared environments using this model) that the limiting factor to scale is human attention.

> 2. submitting trivial contributions is not trivial for the contributor.

While on Plan 9, it's pretty darn easy. I'll grant that it's not trivial if you're not on Plan 9. I'm not convinced that's worth spending much attention on fixing (I suspect we're likely to get better contributions from people using the system for real), but it is fixable without changing the model. It wouldn't be hard to write a patch(1) for plan9port. Go to town. But you'll want to do so after being familiar with the normal operation.

Anthony


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: [9fans] Plan9 Sources Repository

[Christopher Nielsen]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Jul 19, 2014 1:17 PM, "erik quanstrom" <quanstro@quanstro.net> wrote:
>
[snip]

> >        - having an SSH2 server (there is one in 9atom, but I didn't see
> > it in the stock Plan9). Are you sure it doesn't have the Heartbleed?
>
> i'm sure it doesn't have heartbleed.  code for that sort of renegotiation
> was never written.

Not to mention heartbleed has nothing to do with ssh... It was an
implementation bug in openssl only; it wasn't even a protocol bug.

[-- Attachment #2: Type: text/html, Size: 660 bytes --]

Re: [9fans] Plan9 Sources Repository

[Aram Hăvărneanu]

On Sat, Jul 19, 2014 at 9:20 PM, Christopher Nielsen <cnielsen@pobox.com> wrote:
> Not to mention heartbleed has nothing to do with ssh... It was an
> implementation bug in openssl only; it wasn't even a protocol bug.

Yes, OpenSSH doesn't even use OpenSSL.

-- 
Aram Hăvărneanu

Re: [9fans] Plan9 Sources Repository

[dante]

On 19.07.2014 20:17, erik quanstrom wrote:
>> 3. What about
>> http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ ?
>>      What about the broken links there?
>>      Can we still save that software?
>>      Archive.org?
>
> you may edit the wiki yourself to correct these issues.

The Wiki seems to be frozen (i.e., not editable anymore):
- no "Edit" button on
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/
- no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki
444)

Cheers,
Dante

Re: [9fans] Plan9 Sources Repository

[erik quanstrom]

> The Wiki seems to be frozen (i.e., not editable anymore):
> - no "Edit" button on
> http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/
> - no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki
> 444)

edit from plan 9.

- erik

Re: [9fans] Plan9 Sources Repository

[Brian L. Stuart]

>> you  may edit the wiki yourself to correct these issues.
>
> The Wiki seems to be frozen (i.e., not editable anymore):
>  - no "Edit" button on
>  http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/

It was changed some time back to allow edits only using
the acme wiki interface, rather than a web browser.

BLS

Re: [9fans] Plan9 Sources Repository

[Brian L. Stuart]

 >       - having an SSH2 server (there is one in 9atom, but I didn't  
 > see it in the stock Plan9).

Geoff included the same ssh implementation as 9atom
has in /sys/src/cmd/ssh2 but with some code clean-up.
So the server code is there.  I've been meaning to go
back an reconcile the two different versions, including
some bug fixes in the 9atom version, but my supply of
round tuits is small.

> Are you sure it doesn't have the Heartbleed?
 
For a number of reasons, yes, I am.   The Plan 9 ssh v2
implementation is completely new and doesn't share any
code with either OpenSSH or OpenSSL.  That decision
was made for a lot of reasons, one of which was to make
the system less susceptible to the script kiddies.  While
I certainly don't have the hubris to suggest it is without
flaws, I'm pretty sure its flaws are different than those
of the mainstream implementations.  So one is unlikely
to get very far using a mainstream exploit.

Having said all that, I would not recommend running an
SSH server on Plan 9, unless you have a really compelling
reason.  With all due respect to those who developed
the protocol, its authentication model is not, in my opinion,
as solid as that of Plan 9.  If you want to remotely "log into"
a Plan 9 system from a foreign system, use drawterm, or
cpu from a virtualized Plan 9 terminal.

BLS

Re: [9fans] Plan9 Sources Repository

[Brian L. Stuart]

> My whole argument goes about the following hypotheses:
> 1. increasing the amount of contributions may not scale in
> the current model.
> 2. submitting trivial contributions is not trivial for the contributor.

Both of these points seem to come from a mental model
that just doesn't apply to Plan 9.  In earlier messages, you
used the word team to describe the set of people contributing
to Plan 9.  However, in reality, there isn't a Plan 9 team, per
se.  Essentially, Plan 9 is a research system.  It's a platform
and a vehicle for doing systems research.  It is true that it
has been very useful as the basis of products, as infrastructure,
and as a daily-use OS.  However, rather than being its raison
d'etre, Plan 9's utility is a tribute to and the acid test of the
research work done on it.  After all, I'm hardly going to suggest
that a file system I develop is worthy of study or use if I'm
not willing to put my own data on it.  (So yes, my main file
server is running on thetafs, and has been for months.)

Given that the primary function of Plan 9 is to be a research
system, neither increasing numbers of contributions nor
trivial contributions are to be expected.  In fact, it's not
clear they would be particularly desirable.

The flip side of all this is that because it has been very useful,
many of us use it heavily enough that we'd be loathe to
return to a world where we'd have to do without it.  So there
is valid motivation to expand the set of supported hardware,
fix bugs, make it easier to install and use, etc.  While, I'm
not in a position to speak for the principals involved, from
my perspective, both 9atom and 9front are laregely so
motivated.  I don't think I'm speaking out of turn when I say
that the maintainers of both of those systems would be more
than happy to accept contributions to them.  If, in the course
of making such contributions, you reach a point where the
contribution channel could be improved, then contributing
an improved contribution mechanism would be just as welcome,
I suspect.

In other words, welcome to the Plan 9 community.  We'll
be glad to help you however we can.  We encourage and
look forward to seeing any contributions you make that
emerge from what captures your interest.

BLS

Re: [9fans] Plan9 Sources Repository

[dante]

done

On 20.07.2014 00:30, erik quanstrom wrote:
>> The Wiki seems to be frozen (i.e., not editable anymore):
>> - no "Edit" button on
>> http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/
>> - no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki
>> 444)
>
> edit from plan 9.
>
> - erik

Re: [9fans] Plan9 Sources Repository

[dante]

thanks.

On 20.07.2014 02:12, Brian L. Stuart wrote:
>> My whole argument goes about the following hypotheses:
>> 1. increasing the amount of contributions may not scale in
>> the current model.
>> 2. submitting trivial contributions is not trivial for the
>> contributor.
>
> Both of these points seem to come from a mental model
> that just doesn't apply to Plan 9.  In earlier messages, you
> used the word team to describe the set of people contributing
> to Plan 9.  However, in reality, there isn't a Plan 9 team, per
> se.  Essentially, Plan 9 is a research system.  It's a platform
> and a vehicle for doing systems research.  It is true that it
> has been very useful as the basis of products, as infrastructure,
> and as a daily-use OS.  However, rather than being its raison
> d'etre, Plan 9's utility is a tribute to and the acid test of the
> research work done on it.  After all, I'm hardly going to suggest
> that a file system I develop is worthy of study or use if I'm
> not willing to put my own data on it.  (So yes, my main file
> server is running on thetafs, and has been for months.)
>
> Given that the primary function of Plan 9 is to be a research
> system, neither increasing numbers of contributions nor
> trivial contributions are to be expected.  In fact, it's not
> clear they would be particularly desirable.
>
> The flip side of all this is that because it has been very useful,
> many of us use it heavily enough that we'd be loathe to
> return to a world where we'd have to do without it.  So there
> is valid motivation to expand the set of supported hardware,
> fix bugs, make it easier to install and use, etc.  While, I'm
> not in a position to speak for the principals involved, from
> my perspective, both 9atom and 9front are laregely so
> motivated.  I don't think I'm speaking out of turn when I say
> that the maintainers of both of those systems would be more
> than happy to accept contributions to them.  If, in the course
> of making such contributions, you reach a point where the
> contribution channel could be improved, then contributing
> an improved contribution mechanism would be just as welcome,
> I suspect.
>
> In other words, welcome to the Plan 9 community.  We'll
> be glad to help you however we can.  We encourage and
> look forward to seeing any contributions you make that
> emerge from what captures your interest.
>
> BLS