I don't know much about git, but what I have read this would defenitely be an option. Then also synching developer and millers version should be easier if I understood that correctly ?

What do the others think ?

i recently started using git for nova, it is really an extremely powerful tool, compared to cvs/svn ... especially for nonlinear distributed development it is far more suited than cvs/svn ... also maintaining parallel branches is way easier ...

however i am not sure, if it is the right tool for the pd developer community, which seems to be quite conservative in terms of which tools are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...

best, tim

-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org

Happiness is a byproduct of function, purpose, and conflict; those who seek happiness for itself seek victory without war. William S. Burroughs

On Oct 23, 2007, at 2:41 PM, Stephen Sinclair wrote:

...

are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...

You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.

Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.

Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.

I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".

Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.

I won't try any more to push the idea, but I think it's worth considering.

Actually, it would be good if you did push the idea. :D I think if we aren't switching to SVN, we really should consider a distributed system. I am just not sure which one is the best one for the Pd community. While Linus' personality is funny, his ideas about software usability are what make me think there are better systems than git.

From what I see, Git is good for someone who's immersed in it, therefore the extra complexity is beneficial. Pd committers don't do it that often, and are rarely immersed in coding everyday. That says that we should use something that is really easy to learn, setup, and administer, even if that means it might be less efficient for more advanced tasks.

For example, GNU Arch says on the first page (http://www.gnu.org/ software/gnu-arch/) that "GNU arch has some features that make it particularly useful for public free software projects: it's easy to learn; it's inexpensive and easy to administer". Git (http:// git.or.cz/) repeatedly mentions "speed and efficiency".

.hc

Steve

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

------------------------------------------------------------------------ ----

I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.

Also, I believe IOhannes already did a lot of work to get SVN running; last I saw we were basically just waiting for everyone else to be ready? I'll let him confirm but it would be a shame to have wasted his time : ). Info on SVN 1.5 is here: http://subversion.tigris.org/svn_1.5_releasenotes.html

On 10/23/07, Luke Iannini (pd) lukexipd@gmail.com wrote:

Actually, it would be good if you did push the idea. :D I think if

...

we aren't switching to SVN, we really should consider a distributed system. I am just not sure which one is the best one for the Pd community. While Linus' personality is funny, his ideas about software usability are what make me think there are better systems than git.

From what I see, Git is good for someone who's immersed in it, therefore the extra complexity is beneficial. Pd committers don't do it that often, and are rarely immersed in coding everyday. That says that we should use something that is really easy to learn, setup, and administer, even if that means it might be less efficient for more advanced tasks.

For example, GNU Arch says on the first page ( http://www.gnu.org/ software/gnu-arch/) that "GNU arch has some features that make it particularly useful for public free software projects: it's easy to learn; it's inexpensive and easy to administer". Git (http:// git.or.cz/) repeatedly mentions "speed and efficiency".

Sigh, anything is better than CVS... so I won't complain too loudly if we go with something other than SVN. But considering how long it's taking to go to SVN, which everyone agrees with, I'm worried we'll just get bogged down in discussion of the myriad options.

Many of SVN's deficiencies are being addressed in the very-very-soon upcoming 1.5 update, which includes vastly improved merging to compete with Git.

Also, since SVN has such wide adoption, it has really excellent client tools. I use SCPlugin, which integrates SVN with the Mac OS X Finder, along with TextMate's absolutely incredible SVN bundle. Windows users have access to the amazing TortoiseSVN, which offers the best integration I've seen.

Anyways, here's to a swift death for CVS. Cheers Luke

...

Actually, it would be good if you did push the idea. :D I think if

Okay then.. ;-) It's a good discussion anyway..

I think these are all very good arguments for / against svn and git.

I'll just note that I've briefly tested out the Windows git installer, and it is pretty nice. I did get an error during a "clone" operation at one point, which was solved by just doing the same thing on the command line.. (yes, strange, but as you said, alpha.)

Svn is obviously way better than CVS, but I don't really follow the arguments about how Pd is different from Linux. In fact, I see a lot of similarity between pd and Linux:

- a kernel that takes pretty intense "hacking skillz" to understand and efficiently improve - externals that add useful functionality (kernel modules) - satellite projects that make it usable (abstractions)

Honestly I think that the only reason git (or at least, distributed SCM) seems "weird" is because we're all so used to thinking in a centralized way. I'm not at all convinced that a "newbie" would find CVS or Svn somehow easier or more natural than git.

Most of the weird commands in git are intended for doing odd things like retroactively fixing a broken commit or to pull a particular branch from another user's public repo.

Most of the time, git is like this:

git-clone http://some-server/pd-extended.git -- make a local copy of the repo *work work work *... git-commit -m "my fantastic new changes" *work work work*... git-commit -m "more fantastic new changes" git-push (to my public server..)

Oh look there's been a nice update, and they've pulled my changes git-pull *work work work*...

etc.

I'm not claiming there would be no learning curve. But I think there are some advantages.

In any case, as I said previously, using SVN doesn't necessarily rule out being able to use git along with it for those who want to. There is a script, git-svn, which can be used to keep a local git repo in sync with a public Svn repo. So you'd work exactly as I described above, but instead of the git-push command, you'd use git-svn and your Svn repo would be your public repository.

(I haven't tested this much, so it would be worth "trying before buying.")

Of course then you're back to everyone potentially stepping on toes. The thing I like best about it so far, especially since I've only used it on very small projects, is that you can commit many changes before actually publishing them. So you can really think of commits as "semantic building blocks" instead of as "publishing". It separates these two ideas nicely.

Anyways.. hm, also keep in mind there are other distributed SCMs around. There's even one that is more Svn-oriented, called SVK (which I haven't used.) I admittedly only jumped on git because of how it is used for Linux, but also because I've noticed more and more projects taking an interest in it lately. Also I was very attracted to the fact that you can publish your repo on a regular old http server without requiring any kind of special apache module or installing anything. (Since I don't have access to install things on my web server.)

I researched it for quite some time before actually moving one of my projects to it, so I did consider things carefully. So far it's been quite a satisfying move.

Steve

Hallo!

actually publishing them. So you can really think of commits as "semantic building blocks" instead of as "publishing". It separates these two ideas nicely.

apropos: to the Montreal SVN discussion:

Didn't also Miller say, that he wants something like this ? (he also mentioned such a distributed system - don't rember if it was git)

LG Georg

There are a couple key factors in this decision that seem to be getting confused with each other. I'm new to PD, but I've been using Git for over a year now with my own repositories. In various consulting projects over the last few years I've developed with CVS, SVN, Mercurial, Darcs, Arch and Bazaar-ng. There are a couple facets to the decision.

1) Distributed Development

The first, and I think most important, is the development model. Distributed development supports a different kind of collaboration, that I think is showing itself to be quite advantageous for open source software. It lets groups of people organize themselves, get a piece of code working, and then it can be shared with the world. Permissions and management of a central repository is no longer an issue. It doesn't exist. Instead Hans-Christoph, for example, would manage an official pd-extended branch that had the fully tested features, while everyone else could still share the latest and greatest stuff without having a centralized bottle-neck.

2) Personal development advantages

In git you have the whole repository locally. This takes more storage space, which is incredibly cheap, but saves LOTS of time. SVN can never merge as well as GIT because you don't have past versions of the repository to merge against. Additionally, with git you get local versioning, local branching, and tons of distributed back-ups of the repository. I'm always working on the train, for example, and with Git I can maintain a much better log of my development because I commit all the time without needing internet access. Branches in git, even for huge projects, are basically free. In space and time. This changes the way you develop. You can make a branch for any little idea you want to mess with or any tricky feature you are working on. It's quite easy to then merge these branches, share them with friends, update them from other's repositories etc. This is a level of power and control that you can not get with svn.

3) User Interface

Git was originally designed to function as a back-end suite that would support easy to use front-end utilities. That has changed over time, and it now includes a nice set of commands and tools that make it work just like you would expect. For sure Git doesn't have the GUI plugins like SVN or CVS and it will take some learning, but I think the benefits in the long term will far, far outweight the initial investment.

There is a Tk interface, GitK, which is incredibly useful to visually look at the history of a repository, merges, branches etc. There is also git-web, which lets you view the repository online. Git also lets you publish a repository just by copying a directory to an http accessible location. This means anyone can share their ideas, features, abstractions etc, without setting up a server, getting permission for a centralized location or anything. Also relevant to the user experience is speed. Git blows away all the other systems in terms of speed. It does everything faster, and you really notice this because it changes what you do. In some of the other systems, like Bazaar-ng, committing, pulling and pushing took so long I wouldn't do it that often, but with git it's all so cheap I do it every time I get a new unit test to pass.

4) Technical

Git writes the repository into a highly compressed format, and then it does not mess with the files. Append only is the standard operation, except for when you occasionally compress the whole thing, in which case it can verify sanity. It is also much cleaner to work with in terms of permissions and access, just because of the whole usage model. I've had many experiences with subversion where the repository had to be recovered because of permissions issues and/or corruption. This is very bad, especially since it is a centralized server that everyone is counting on. It takes a root user to go in and run "svnadmin recover", which in my opinion is a command that shouldn't need to exist in something as important as a source repository.

Keith Packard who runs the X.org project wrote a very good post detailing his research and opinions into source control. It's a bit old now, but worth the read: http://keithp.com/blog/Repository_Formats_Matter/index.html

Sorry for the long post, but this is something I have dealt with a lot recently. In my mind distributed versioning is the only proper way to run a modern open source project. PD is a great piece of software with a seemingly cool and diverse group of developers, which seems perfect for a decentralized model. Either way, I think the decision should be made first between a centralized or distributed versioning system, and then the decision can be simplified to figuring out compatibility, usability etc. It's great news that Git now runs on windows though, because I think it is far better than the others. To quote one of Hans-Christoph's recent signature lines:

Mistrust authority - promote decentralization. - the hacker ethic

:-)

Ciao, Jeff

David Plans Casal wrote:

Speaking from experience, having suffered several migrations to prcs from cvs, to svn from cvs, and to darcs from svn, in commercial projects, I have to say the only one that worked well, made sense, and was least painful was cvs-->svn, and I'd vote for that.

David

On 23 Oct 2007, at 19:41, Stephen Sinclair wrote:

...

...

are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...

You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.

Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.

Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.

I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".

Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.

I won't try any more to push the idea, but I think it's worth considering.

Steve

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

That still leaves me with questions about the interface of git. That blog post is interesting, but as he says in the first sentence, he is ignoring the interface. He then goes on to say:

The key detractors for Git was (and remains) the steep learning curve for the native Git interface; ameliorated for some users by alternate interfaces (such as Cogito), but not for core developers.

The most technically amazing system in the world is useless if people in question don't want to spend the extra effort to learn how to use it.

It sounds to me like the best system is SVN as the core repository, then people can use git if they want, and sync it to SVN. Miller currently does this with Git->CVS.

.hc

On Oct 24, 2007, at 8:39 AM, Jeff Rose wrote:

There are a couple key factors in this decision that seem to be getting confused with each other. I'm new to PD, but I've been using Git for over a year now with my own repositories. In various consulting projects over the last few years I've developed with CVS, SVN, Mercurial, Darcs, Arch and Bazaar-ng. There are a couple facets to the decision.

1. Distributed Development

The first, and I think most important, is the development model. Distributed development supports a different kind of collaboration, that I think is showing itself to be quite advantageous for open source software. It lets groups of people organize themselves, get a piece of code working, and then it can be shared with the world. Permissions and management of a central repository is no longer an issue. It doesn't exist. Instead Hans-Christoph, for example, would manage an official pd-extended branch that had the fully tested features, while everyone else could still share the latest and greatest stuff without having a centralized bottle-neck.

2. Personal development advantages

In git you have the whole repository locally. This takes more storage space, which is incredibly cheap, but saves LOTS of time. SVN can never merge as well as GIT because you don't have past versions of the repository to merge against. Additionally, with git you get local versioning, local branching, and tons of distributed back-ups of the repository. I'm always working on the train, for example, and with Git I can maintain a much better log of my development because I commit all the time without needing internet access. Branches in git, even for huge projects, are basically free. In space and time. This changes the way you develop. You can make a branch for any little idea you want to mess with or any tricky feature you are working on. It's quite easy to then merge these branches, share them with friends, update them from other's repositories etc. This is a level of power and control that you can not get with svn.

3. User Interface

Git was originally designed to function as a back-end suite that would support easy to use front-end utilities. That has changed over time, and it now includes a nice set of commands and tools that make it work just like you would expect. For sure Git doesn't have the GUI plugins like SVN or CVS and it will take some learning, but I think the benefits in the long term will far, far outweight the initial investment.

There is a Tk interface, GitK, which is incredibly useful to visually look at the history of a repository, merges, branches etc. There is also git-web, which lets you view the repository online. Git also lets you publish a repository just by copying a directory to an http accessible location. This means anyone can share their ideas, features, abstractions etc, without setting up a server, getting permission for a centralized location or anything. Also relevant to the user experience is speed. Git blows away all the other systems in terms of speed. It does everything faster, and you really notice this because it changes what you do. In some of the other systems, like Bazaar-ng, committing, pulling and pushing took so long I wouldn't do it that often, but with git it's all so cheap I do it every time I get a new unit test to pass.

4. Technical

Git writes the repository into a highly compressed format, and then it does not mess with the files. Append only is the standard operation, except for when you occasionally compress the whole thing, in which case it can verify sanity. It is also much cleaner to work with in terms of permissions and access, just because of the whole usage model. I've had many experiences with subversion where the repository had to be recovered because of permissions issues and/or corruption. This is very bad, especially since it is a centralized server that everyone is counting on. It takes a root user to go in and run "svnadmin recover", which in my opinion is a command that shouldn't need to exist in something as important as a source repository.

Keith Packard who runs the X.org project wrote a very good post detailing his research and opinions into source control. It's a bit old now, but worth the read: http://keithp.com/blog/Repository_Formats_Matter/index.html

Sorry for the long post, but this is something I have dealt with a lot recently. In my mind distributed versioning is the only proper way to run a modern open source project. PD is a great piece of software with a seemingly cool and diverse group of developers, which seems perfect for a decentralized model. Either way, I think the decision should be made first between a centralized or distributed versioning system, and then the decision can be simplified to figuring out compatibility, usability etc. It's great news that Git now runs on windows though, because I think it is far better than the others. To quote one of Hans-Christoph's recent signature lines:

Mistrust authority - promote decentralization. - the hacker ethic

:-)

Ciao, Jeff

David Plans Casal wrote:

...

Speaking from experience, having suffered several migrations to prcs from cvs, to svn from cvs, and to darcs from svn, in commercial projects, I have to say the only one that worked well, made sense, and was least painful was cvs-->svn, and I'd vote for that.

David

On 23 Oct 2007, at 19:41, Stephen Sinclair wrote:

...

...

are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...

You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.

Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.

Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.

I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".

Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.

I won't try any more to push the idea, but I think it's worth considering.

Steve

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

------------------------------------------------------------------------ ----

"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore

Hallo, Stephen Sinclair hat gesagt: // Stephen Sinclair wrote:

...

The most technically amazing system in the world is useless if people in question don't want to spend the extra effort to learn how to use it.

It sounds to me like the best system is SVN as the core repository, then people can use git if they want, and sync it to SVN. Miller currently does this with Git->CVS.

I still don't think that git is all that hard to use once you understand the distributed paradigm, but in any case I think this would be a perfectly safe decision.

Actually I think, that the code in the CVS is not developed in a really distributed way anyway. Most of the stuff there is rather focused on single persons or very small teams. For example: Most commits in zexy come from IOhannes, most in list-abs from me, only Matju commits to DD, Hans has his pd-extended branch, but also uses a lot of separate patch files and the list goes on.

It's not like a team of 60 developers would work on the same files or even the same binary, like it is with the Linux kernel, it's much more separate. And I don't think it's separate, because of technical restrictions coming from CVS - it's separate because of the way the people in the Pd community work.

Ciao

Hallo, Stephen Sinclair hat gesagt: // Stephen Sinclair wrote:

...

Actually I think, that the code in the CVS is not developed in a really distributed way anyway. Most of the stuff there is rather focused on single persons or very small teams.

Hm, your second sentence seems to contradict your first sentence... ;-)

It only seems so. ;)

What I meant to express was, that somehow the repository is like a collection of many separate repositories. It's not so much distributed as divided into independent entities. At least a large part of it is.

Ciao

On Wed, Oct 24, 2007 at 09:27:15PM -0400, Hans-Christoph Steiner wrote:

It sounds to me like the best system is SVN as the core repository, then people can use git if they want, and sync it to SVN. Miller currently does this with Git->CVS.

So wait, Miller is currently using Git? It seems to me that that is a major pro in favour of other developers using Git. The big issue with Pd development (apart from some slightly sharp personalities sometimes) is with:

a) Miller not accepting people's patches, often without giving a reason. b) People finding it difficult to merge Miller's monolithic changes (e.g. what Tim had to do with the devel branches).

Surely if more people were also using git it would make both of those issues moot since Miller could more easily pull the patches he wanted and people could more easily merge Miller's changes.

On the other hand it might change nothing and everyone will continue to refuse to merge good patches and fork eachothers code bases. Maybe it has more to do with license issues, such as most developers releasing source under the GPL whilst Miller releases under the BSD? I would love to hear some comments from Miller about this, especially if he's publishing his Git repository somewhere.

Best,

Chris.

------------------- http://mccormick.cx

The hard thing for me with patches is that I feel I should understand the patch fully and believe it both works and that it won't make future trouble. For the last month or more I've been working on HC's font patch, trying to adapt it so that it's bug-free but still accomplishes HC's aim.

one way to go would be: 1. point hc to the bugs, ask him to fix them 2. when the patch is bug-free, ask hc to document it 3. read the docs, read the code, try to understand it 4. point hc to the issues that you don't like in the code 5. review the patch again 6. if the patch doesn't match your criteria, go to point 4

tim

-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org

Who need fossil fuel when the sun ain't goin' nowhere Amiri Baraka

On Wed, 24 Oct 2007, Chris McCormick wrote:

On the other hand it might change nothing and everyone will continue to refuse to merge good patches and fork eachothers code bases.

When the policy is to refuse any patch that don't add or fix any functionality, and to refuse any part of a patch that doesn't add or fix any functionality, and to aim for the smallest patches possible, the whole project necessarily decreases in some form of quality that users are oblivious to, but that determines the level of difficulty of any further improvement.

Switching to svn or git doesn't fix policy problems.

Maybe it has more to do with license issues, such as most developers releasing source under the GPL whilst Miller releases under the BSD?

No. Patches to Pd itself are all assumed to be SIBSD'd unless explicitly stated otherwise, and I have never seen someone requesting to add GPL'd code directly into Pd.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

On Tue, 2007-10-23 at 11:56 -0400, Hans-Christoph Steiner wrote:

A distributed repository sounds interesting, but given Linus Torvald's love of KDE, constant dissing of usability, and the fact that git has 119 commands, this gives me pause.

in order to evaluate git, one should maybe give it a try ...

Sounds like software designed for someone with an encyclopedic memory. I really only use 8 commands in CVS (update, commit, checkout, add, remove, tag, diff, import).

do you remember all the cvs command options?

tim

-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org

Every word is like an unnecessary stain on silence and nothingness Samuel Beckett

My experience is that Linus is super focused on issues that affect him and pretty much totally ignores other issues that don't affect him. Also, he approaches things with arrogance. So chances are, that effects the software he writes.

i am not sure whether one should judge the functionality of a piece of software by the personality of the author ...

I want to write code, not play with SCM systems.

i think it took me two days to merge devel_0_38 to devel_0_39 with cvs ... it could have been done in one day with git ... 4 hours learning git and setting up the repository, 2 hours doing the merge :)

cheers, tim

-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org

Every word is like an unnecessary stain on silence and nothingness Samuel Beckett