i'm sorry - that didn't occur to me. it certainly didn't occur to me that a project that has only not had any postings about it for only three months to be "dead".
plus, the fact that the code exists _at all_ - and is preserved - makes it possible to retrieve and revive it.
_plus_, if it does the purpose for which it is designed (look at http://htmltmpl.sf.net/ for an example), it doesn't _need_ further work; it doesn't need further "development" - it just "works".
they do indeed. the one thing that people forget about rainbow-powered unicorns is that those spikes are _really_ sharp, and unicorns have a natural instinct to stampede over eeviiillll mwahahahah
i think that google might be a bit peeved if the people who were on that particular GSoC-sponsored project decided that they wanted to use github.org, not code.google.com....:)
notwithstanding: even github would be sidelined by gittorrent - or would have to adapt gittorrent...
in cases where internet access is prohibitively expensive or even impossible, it makes perfect sense to have everything in easily-syncable git repositories.
once you have the documentation, the wiki, the code and the bugtracker in repositories, you could even sync those repositories up with the rest of the world through the exchange of floppy disks, CDs or USB memory sticks.
Persistence happens by mistake when people forget to clean out their gittorrent-backed git repositories.
the nice thing about using gittorrent is that you would end up with copies of the bits of source code and the binaries that YOU were interested in - and, consequently, so would anyone else.
so, if you were a maintainer of a project, you would be interested in hosting a "central" repository, just like is done now, keeping all the revisions of the software, but it would *happen* to also be _distributed_...
in many ways, you have to _forget_ what bittorrent is currently used for, and think a bit deeper about what it _can_ be used for...
A distributed repository has no political implications that mirroring in general don't have already have.
China. Dubai. internet access is monitored and censored. In Dubai, if a mime-encoded download *happens* to have the letters "sEx" in it, it gets shut off.
there's nothing to stop an EXISTING site from being the one that publishes their "central" repository via gittorrent. in fact, that's the whole point - initially - of gittorrent: to take the load off the "central" repositories, currently utilising http mirroring.
but thank you - i will make mention of that, explicitly, in the article.
the project was found by accident: the author of the article and the project's authors are not related, in any way.
think of google code as a bootstrap mechanism: you have to get from here to there _somehow_, and if it wasn't for the old, you'd never get a leg-up into the new....
read the article: in it, you will see links to the fact that Git already has GPG signing on tags.
also, you will see references to KeyNote, aka RFC 2704. for convenience, i'm cut/pasting the top bit, here:
"Trust management, introduced in the PolicyMaker system [BFL96], is a unified approach to specifying and interpreting security policies, credentials, and relationships; it allows direct authorization of security-critical actions. A trust-management system provides standard, general-purpose mechanisms for specifying application security policies and credentials. Trust-management credentials describe a specific delegation of trust and subsume the role of public key certificates; unlike traditional certificates, which bind keys to names, credentials can bind keys directly to the authorization to perform specific tasks."
across most of europe, america and asia, internet access is near-unlimited.
have you considered the implications of receiving linux on a CD, and being cut off from the rest of the internet?
how would a group of 100 developers, or 1000 developers, or 10,000 developers - all of them "used to" the current levels of internet access and speed, cope in a situation where the access to the internet was restricted to intermittent 56k dialup?
The primary purpose of peer to peer systems are to either avoid censorship or provide lots of cheap/free bandwidth.
the primary purposes _now_ are to avoid censorship and to provide lots of cheap/free bandwidth.
the last major upgrade of debian REDLINED the world's internet backbone infrastructure for a WEEK.
with the total linux usage only being - what... 1% of the world's desktop systems, and debian being a small fraction of that, the debian mirror system are ALREADY creaking under the load.
Neither of these really apply to source code management.
why not?
Hosting is easily sponsored and the files aren't very big anyway. Few projects will face censorship anywhere other than the most regressive regimes (ie, China or the US).
i don't _want_ "sponsorship". i don't _want_ my pet project hosted by a large corporation. i want it completely independent.
i want my web site content hosted and automatically mirrored across the world, along with its bugs database and its wiki all linked together.
i want people in the emerging markets and the third world to be able to have exactly the same kind of luxury that we do - and they DO NOT have "continuous access to the web site or access to the lovely sponsored hosting".
think much bigger and you will start to see why this is so damn important.
This is cool, your code can be free. But unfortunately you're still stuck with hosting the documentation on a central website of some sort.
no - you're not:) read the article: it mentions that static content such as that generated by ikiwiki could perfectly well be generated by a locally-checked-out (gittorrent-distributed) copy of the documentation
extend that concept a little further (one step at a time!) and you have, as you rightly mention:
a standard for hosting the documentation website. IE PHP + SQlite + GitTorrent docRoot == Distributed website.
yes! although, to be much better, technically, you'd have a distributed SQL server - a peer-to-peer SQL server. there's a project that IngreSQL are keeping an eye on, called "d", that might show some promise, here.
Could even contain Trac or something, so all the bug tracking is also in the GitTorrent repository.
whilst many people would be capable of making the same deductions, many people are not.
so, consequently, i thought it best to spell them out. not least so that other people who are _not_ as technically aware as you or i, who may be just coming in or out of university, can take a look at the list of inter-related projects listed on the original article, and go "cool!"
it was a bit of a shock that the article was accepted, that _never_ happens.
i genuinely actually wanted to hear what alternatives there were to MVC: i just picked MVC as a good "hook" against which to hang the issue of having to do duplication of input validation, and how if you have it written in a language that can be compiled to javascript, it takes away that pain.
if it wasn't MVC, i would have picked whatever-it-was.
One thing i specifically left out of the article was Pyjamas-Desktop - http://pyjd.org/
it's a port of the pyjamas API to "straight" python, and so the EXACT same app, from the exact same source code, runs natively under the standard python interpreter.
there's no reason why GWT's libraries should not, likewise, be ported to the desktop.
there's no reason why pyjamas should not be ported to c++.
there's no reason why rubyjs / rwt should not be ported to the desktop.
the nice thing that pyjamas-desktop shows is that, thanks to the abstraction layer using webkit underneath, and webkit being available for qt, gkt, wx-widgets and also (as shown in google chrome) google's "silk" drawing API, the pyjamas API is toolkit-independent.
and, again, it can also sit on top of gecko, thanks to Hulahop.
in this way, you get a user-interface applications development widget set and framework that is os-independent, language-independent, browser-independent, platform-independent and widget-set-independent.
i don't know of *any* UI framework that comes *remotely* close to being able to claim that, yet pyjamas + GWT + rwt is *well* on the way.
also, regarding the "incompatibilities" issue: pyjamas, GWT and rwt all support a mechanism to "overload" classes and class functions with browser-specific code, on a per-class and on a per-function basis. so, it *can* be done.
i think.... i think if you turned every assumption about what you _believe_ i believe into its opposite, you'd come close to what i think.
can i suggest, respectfully, that you re-read it without making any assumptions, and then, perhaps, give us the benefit of your experience by mentioning what alternatives there are to MVC?
Slashdot Mirror
i'm sorry - that didn't occur to me. it certainly didn't occur to me that a project that has only not had any postings about it for only three months to be "dead".
plus, the fact that the code exists _at all_ - and is preserved - makes it possible to retrieve and revive it.
_plus_, if it does the purpose for which it is designed (look at http://htmltmpl.sf.net/ for an example), it doesn't _need_ further work; it doesn't need further "development" - it just "works".
sadly, though, gittorrent isn't _quite_ finished.
*shrugs*
look more closely at the way that debian works, paying particular to apt-keyring.
ha ha :)
no, not every single one - just the ones that get the wrong end of the stick in some subtle way that could misdirect readers.
they do indeed. the one thing that people forget about rainbow-powered unicorns is that those spikes are _really_ sharp, and unicorns have a natural instinct to stampede over eeviiillll mwahahahah
i think that google might be a bit peeved if the people who were on that particular GSoC-sponsored project decided that they wanted to use github.org, not code.google.com.... :)
notwithstanding: even github would be sidelined by gittorrent - or would have to adapt gittorrent...
thank you!
because it's the *only* project that links git with a p2p protocol. so, i'm interested in seeing it revived.
You're used to permanent online Internet access.
in cases where internet access is prohibitively expensive or even impossible, it makes perfect sense to have everything in easily-syncable git repositories.
once you have the documentation, the wiki, the code and the bugtracker in repositories, you could even sync those repositories up with the rest of the world through the exchange of floppy disks, CDs or USB memory sticks.
so the article is about "thinking ahead".
Persistence happens by mistake when people forget to clean out their gittorrent-backed git repositories.
the nice thing about using gittorrent is that you would end up with copies of the bits of source code and the binaries that YOU were interested in - and, consequently, so would anyone else.
so, if you were a maintainer of a project, you would be interested in hosting a "central" repository, just like is done now, keeping all the revisions of the software, but it would *happen* to also be _distributed_...
in many ways, you have to _forget_ what bittorrent is currently used for, and think a bit deeper about what it _can_ be used for...
debian has a keysigning process that creates a web of trust.
http://www.chaosreigns.com/code/sig2dot/debian.html
http://www.debian.org/events/keysigning
oh _goodie_! i always wanted to be a _frothing_ idiot.
A distributed repository has no political implications that mirroring in general don't have already have.
China. Dubai. internet access is monitored and censored. In Dubai, if a mime-encoded download *happens* to have the letters "sEx" in it, it gets shut off.
there's nothing to stop an EXISTING site from being the one that publishes their "central" repository via gittorrent. in fact, that's the whole point - initially - of gittorrent: to take the load off the "central" repositories, currently utilising http mirroring.
but thank you - i will make mention of that, explicitly, in the article.
ohmmmmmmmmmmmm
"i am at onnnne with the universe. i am greeeen!"
the project was found by accident: the author of the article and the project's authors are not related, in any way.
think of google code as a bootstrap mechanism: you have to get from here to there _somehow_, and if it wasn't for the old, you'd never get a leg-up into the new....
Git GPG signing, and KeyNote.
http://www1.cs.columbia.edu/~angelos/keynote.html
read the article: in it, you will see links to the fact that Git already has GPG signing on tags.
also, you will see references to KeyNote, aka RFC 2704. for convenience, i'm cut/pasting the top bit, here:
"Trust management, introduced in the PolicyMaker system [BFL96], is a unified approach to specifying and interpreting security policies, credentials, and relationships; it allows direct authorization of security-critical actions. A trust-management system provides standard, general-purpose mechanisms for specifying application security policies and credentials. Trust-management credentials describe a specific delegation of trust and subsume the role of public key certificates; unlike traditional certificates, which bind keys to names, credentials can bind keys directly to the authorization to perform specific tasks."
across most of europe, america and asia, internet access is near-unlimited.
have you considered the implications of receiving linux on a CD, and being cut off from the rest of the internet?
how would a group of 100 developers, or 1000 developers, or 10,000 developers - all of them "used to" the current levels of internet access and speed, cope in a situation where the access to the internet was restricted to intermittent 56k dialup?
The primary purpose of peer to peer systems are to either avoid censorship or provide lots of cheap/free bandwidth.
the primary purposes _now_ are to avoid censorship and to provide lots of cheap/free bandwidth.
the last major upgrade of debian REDLINED the world's internet backbone infrastructure for a WEEK.
with the total linux usage only being - what... 1% of the world's desktop systems, and debian being a small fraction of that, the debian mirror system are ALREADY creaking under the load.
Neither of these really apply to source code management.
why not?
Hosting is easily sponsored and the files aren't very big anyway. Few projects will face censorship anywhere other than the most regressive regimes (ie, China or the US).
i don't _want_ "sponsorship". i don't _want_ my pet project hosted by a large corporation. i want it completely independent.
i want my web site content hosted and automatically mirrored across the world, along with its bugs database and its wiki all linked together.
i want people in the emerging markets and the third world to be able to have exactly the same kind of luxury that we do - and they DO NOT have "continuous access to the web site or access to the lovely sponsored hosting".
think much bigger and you will start to see why this is so damn important.
This is cool, your code can be free. But unfortunately you're still stuck with hosting the documentation on a central website of some sort.
no - you're not :) read the article: it mentions that static content such as that generated by ikiwiki could perfectly well be generated by a locally-checked-out (gittorrent-distributed) copy of the documentation
extend that concept a little further (one step at a time!) and you have, as you rightly mention:
a standard for hosting the documentation website. IE PHP + SQlite + GitTorrent docRoot == Distributed website.
yes! although, to be much better, technically, you'd have a distributed SQL server - a peer-to-peer SQL server. there's a project that IngreSQL are keeping an eye on, called "d", that might show some promise, here.
Could even contain Trac or something, so all the bug tracking is also in the GitTorrent repository.
yes!
_now_ you're getting it :)
GitTorrent isn't my project. and, if you read the description of the projecton its own, gittorrent looks utterly boring.
Read the article - which i _did_ write - http://advogato.org/article/994.html - to get an idea of what the absolutely massive implications are.
whilst many people would be capable of making the same deductions, many people are not.
so, consequently, i thought it best to spell them out. not least so that other people who are _not_ as technically aware as you or i, who may be just coming in or out of university, can take a look at the list of inter-related projects listed on the original article, and go "cool!"
*grin*.
it was a bit of a shock that the article was accepted, that _never_ happens.
i genuinely actually wanted to hear what alternatives there were to MVC: i just picked MVC as a good "hook" against which to hang the issue of having to do duplication of input validation, and how if you have it written in a language that can be compiled to javascript, it takes away that pain.
if it wasn't MVC, i would have picked whatever-it-was.
kinda... but in a politely ambiguous way, that doesn't slam the door in the guy's face :)
i have to give him the benefit of the doubt that he genuinely has something to contribute. wouldn't be fair otherwise.
One thing i specifically left out of the article was Pyjamas-Desktop - http://pyjd.org/
it's a port of the pyjamas API to "straight" python, and so the EXACT same app, from the exact same source code, runs natively under the standard python interpreter.
there's no reason why GWT's libraries should not, likewise, be ported to the desktop.
there's no reason why pyjamas should not be ported to c++.
there's no reason why rubyjs / rwt should not be ported to the desktop.
the nice thing that pyjamas-desktop shows is that, thanks to the abstraction layer using webkit underneath, and webkit being available for qt, gkt, wx-widgets and also (as shown in google chrome) google's "silk" drawing API, the pyjamas API is toolkit-independent.
and, again, it can also sit on top of gecko, thanks to Hulahop.
in this way, you get a user-interface applications development widget set and framework that is os-independent, language-independent, browser-independent, platform-independent and widget-set-independent.
i don't know of *any* UI framework that comes *remotely* close to being able to claim that, yet pyjamas + GWT + rwt is *well* on the way.
also, regarding the "incompatibilities" issue: pyjamas, GWT and rwt all support a mechanism to "overload" classes and class functions with browser-specific code, on a per-class and on a per-function basis. so, it *can* be done.
i think.... i think if you turned every assumption about what you _believe_ i believe into its opposite, you'd come close to what i think.
can i suggest, respectfully, that you re-read it without making any assumptions, and then, perhaps, give us the benefit of your experience by mentioning what alternatives there are to MVC?
i would be delighted to analyse the alternatives.
l.