Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model
Neverminding the ridiculous length of that subject line..
I just thought an interesting thought.
First, a little context, (I know how rms feels about blockchains) I was investigating slock.it and thinking to myself "why don't they just make a hardware standard like eoma instead of closing their development and calling it open?" (Like, Pi-Top is [n]ever gonna release those stl files) (I realize that's a loaded 'just' cause it sounds easy, but is one of the most difficult possible)
Then, it dawned on me: Lulzbot doesn't do that.. Wait, Lulzbot exclusively uses open software in their development.. Then *bam* like a boulder (nothing to do with Lulzbot): GPL-violations, improper GUI training, failing to extend using APIs/Addons, failing to bugsmash/'track-issues', failing to participate in mailing-lists and irc, failing to simply fork when development goals conflict, planned esoteric-ism and/or planned obsolescence, failure to secure clientèle data by using fully free systems (when relevant), failure to participate-in and be-aware-of public conversations about the underlining security of said systems (when relevant), failure to disclose supplychain information/identities (when relevant), failure at general transparency.
All of these things traditionally go wrong with not only companies that use open source, but companies in-general.
Then, it truly truly dawned on me, free software needs standards organizations as well.
On Wed, May 31, 2017 at 2:19 PM, John Luke Gibson eaterjolly@gmail.com wrote:
Then, it truly truly dawned on me, free software needs standards organizations as well.
or something like that.. yeah.
On 5/31/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Wed, May 31, 2017 at 2:19 PM, John Luke Gibson eaterjolly@gmail.com wrote:
Then, it truly truly dawned on me, free software needs standards organizations as well.
or something like that.. yeah.
It would a great opportunity for projects like blender and gimp, that a company could use a certification mark that basically says "they contributed; there were no gpl violations; they made themselves available on mailing lists; they didn't bumble around with the software instead of asking for help; they were transparent with the public about anything we would find ethically-questionable;" etcetera etcetera. That mark would like include a QR code which people could check the status and make sure a physically printed mark hasn't been revoked after printing. And, their could be regular transparent royalty/inspection fee for as long as the company wants that mark to have an active status.
It's brilliant!
huh. hmmm, if it's ok with you i might run that by dr stallman, see what he thinks. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, May 31, 2017 at 6:05 PM, John Luke Gibson eaterjolly@gmail.com wrote:
On 5/31/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Wed, May 31, 2017 at 2:19 PM, John Luke Gibson eaterjolly@gmail.com wrote:
Then, it truly truly dawned on me, free software needs standards organizations as well.
or something like that.. yeah.
It would a great opportunity for projects like blender and gimp, that a company could use a certification mark that basically says "they contributed; there were no gpl violations; they made themselves available on mailing lists; they didn't bumble around with the software instead of asking for help; they were transparent with the public about anything we would find ethically-questionable;" etcetera etcetera. That mark would like include a QR code which people could check the status and make sure a physically printed mark hasn't been revoked after printing. And, their could be regular transparent royalty/inspection fee for as long as the company wants that mark to have an active status.
It's brilliant!
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On 5/31/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
huh. hmmm, if it's ok with you i might run that by dr stallman, see what he thinks.
That'd be awesome; be awesomer if you mentioned me ('d love to win zeh brownie points xS)
On Wed, May 31, 2017 at 6:17 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
huh. hmmm, if it's ok with you i might run that by dr stallman, see what he thinks.
ok, so i spoke to dr stallman, it took me a while to get across the idea, and after clarifying it he said, *in effect*, "please could you write up some developer best practices as long as every GNU Project would automatically conform to them". he didn't exactly say that, so please do not quote me on it.
the starting point should be to take this "list of project *SERVICES* offered to the GNU project" https://www.gnu.org/software/devel.en.html
and turn it into a list of *GENERAL* project *RECOMMENDATIONS*, using the GNU server services as... like... the "Gold Standard".
the one thing that is missing from this list is a "Charter" - like how the Apache Software Foundation has a Charter. i am not entirely sure what to advise / do on that. over the past 20+ years i have witnessed many high-profile projects treat good people in some pretty horrible ways - not once and not on just the one project but many many times.
the Apache Software Foundation on the other hand, whilst they have had problems, their Charter has allowed them to (formally) keep things "civil", including being able to remove a project leader who clearly did not understand the harm he was causing to the project, through his actions.
also worthwhile considering is adding the recommendation for developers to take the "Hippocratic Oath for Software Engineers".
http://farmerandfarmer.org/medicine/printable.html
the nice thing about that oath is that it can just be added simply to make people aware of it... *without* actually requiring that they take it.
anyway i have started a page here in order to coordinate ideas and the actual proposal:
http://rhombus-tech.net/proposed_best_practices/
l.
Alrightie~!
Foremost, since "existing" free software and cultural works aren't likely to be sold, I think a libre software standards organization wouldn't certify individual works or pieces of code, so much as projects as a whole including roles performed by non-developers
Version control is almost ubiquitously used for source code, to the point it should hardly need mentioned; however very rarely are non-source project files, such as .blend files, collaboratively designed this way. I don't think people are unwilling to use version control in this way, rather they just don't think of it since most artists aren't developers and art has been digitally designed for much longer than version control systems have been easy to use. So I think uploading files to repository and saving changes as commits, would be a good 'non-developer' "best practice" to apply to a software certification standard.
Anyways, developer 'best practices'. Having idle hands study and document code, particularly esoteric parts or parts they, the contributors, are unfamiliar with (so they can learn it*). Generally, the instinct we are taught from criticisms of our artwork, is that 'if we can't do something well, it's best not to do it at all', however with our version control systems generally the opposite is much more likely true, leaving room also for the hopefully soon to be colloquial: "if a task seems too easy, it is best leave it for someone else more novice; if a task seems too difficult, it is best to do it sloppily, so someone else won't have to do it start from nothing". So I think doing the best we possibly can do to develop the worst code and worst documentation we possibly can, (xD) is another good developer 'best practice'.
Most of us know it's not uncommon for very large projects to receive access to proprietary source code under NDA, just to mod it**. Likewise libre software is often perceived as insufficient as-is, however proprietary software can be close enough that it is more practical. In these cases, we need to respect reality, however also ensure all is carefully weighed. The biggest pitfall is looking at all the forks, addons, and extensions, then also looking at what you would like to do that one can't with proprietary software out of the box. Whilest being careful not to berate preferences, looking at how modifiable the base program is and what it could accomplish rather than what it can accomplish, is an important thing to make sure both project's developer's and non-developer's occasionally remember to do. So, considering what we could do more proportionally with what we can do, is an important developer and non-developer 'best practice', especially since as least occasionally they'll make one of their could-do'es someone else's can-do.
Another practice that kindof ties in with the other one, and an often unsung aim of the GNU project as a whole, is make programming easier. Occasionally, a project will have extra resources or volunteers/contributors than their described roadmap warrants. Not always is this obvious from the beginning when it does happen. In fact, usually it isn't till the end that it becomes apparent. The ideal would be say 'even if proprietary software is more practical, use/extend free software for the benefit of everyone when you have the resource', but the reality is very rarely will you know you have the resources until it's far too late. Instead, a good programming practice might be to use the extra resources to modify the language itself or some api to make the code smaller. We all should know line counting is a trap, but we should also know we are more likely to read a pamphlet than a book. So, it should be a good developer 'best practice' should be to use extra resources at the end to make your code intuitive and concise, and to fork others so hopefully adaptations to libraries and compilers that make your code more concise and intuitive get upstream.
This is just a rough start, but I wanted to post it here and get feedback before putting it on the wiki.
I really like the analogy of medicine to software development, particularly the use of the Hippocratic Oath as a point of reference. I was looking at the 'original' oath, and there is an interesting intersection with the morals of free software. Take a look at this:
"to impart precept, oral instruction, and all other instruction to my own [kids], the [kids] of my teacher, and to indentured pupils who have taken the physician’s oath, but to nobody else."***
That last bit of 'teaching no one else' is a little tongue-and-cheek for the free software movement xD But, still, it has this aura of freedom of information that's interesting for ancients.
In fact most of the last two and the first two clauses, mutually apply to software. I'm the artistic type who would take the original oath and edit it to apply to software****.
* https://www.youtube.com/watch?v=tkm0TNFzIeg ** https://www.youtube.com/watch?v=yisaDxvBH9s&t=5m50s *** https://en.wikipedia.org/wiki/Hippocratic_Oath#Text_of_the_oath **** https://en.wikipedia.org/wiki/Intertextuality
On 6/5/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Wed, May 31, 2017 at 6:17 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
huh. hmmm, if it's ok with you i might run that by dr stallman, see what he thinks.
ok, so i spoke to dr stallman, it took me a while to get across the idea, and after clarifying it he said, *in effect*, "please could you write up some developer best practices as long as every GNU Project would automatically conform to them". he didn't exactly say that, so please do not quote me on it.
the starting point should be to take this "list of project *SERVICES* offered to the GNU project" https://www.gnu.org/software/devel.en.html
and turn it into a list of *GENERAL* project *RECOMMENDATIONS*, using the GNU server services as... like... the "Gold Standard".
the one thing that is missing from this list is a "Charter" - like how the Apache Software Foundation has a Charter. i am not entirely sure what to advise / do on that. over the past 20+ years i have witnessed many high-profile projects treat good people in some pretty horrible ways - not once and not on just the one project but many many times.
the Apache Software Foundation on the other hand, whilst they have had problems, their Charter has allowed them to (formally) keep things "civil", including being able to remove a project leader who clearly did not understand the harm he was causing to the project, through his actions.
also worthwhile considering is adding the recommendation for developers to take the "Hippocratic Oath for Software Engineers".
http://farmerandfarmer.org/medicine/printable.html
the nice thing about that oath is that it can just be added simply to make people aware of it... *without* actually requiring that they take it.
anyway i have started a page here in order to coordinate ideas and the actual proposal:
http://rhombus-tech.net/proposed_best_practices/
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jun 5, 2017 at 10:47 PM, John Luke Gibson eaterjolly@gmail.com wrote:
Alrightie~!
Foremost, since "existing" free software and cultural works aren't likely to be sold, I think a libre software standards organization wouldn't certify individual works or pieces of code, so much as projects as a whole including roles performed by non-developers
indeed.
Version control is almost ubiquitously used for source code, to the point it should hardly need mentioned;
absolutely dead-wrong. it needs *absolutely* to be clearly defined. the practice of saying "well everyone does it so we don't need to take special note of it" is how, historically, utterly valuable knowledge has been lost through the ages.
a good example is all the folk tunes of medieval times: *nobody knows them any more* because quotes everybody knew them quotes so NOBODY WROTE THEM DOWN.
so no, john: it *is* critical that everything that's ubiquitous and quotes obvious quotes be formally documented.
then, not least, you will discover that actually, everybody uses github "by default".... which, when you read (and take) the software engineer's hippocratic oath you find that it's very hard to honour that oath and use github at the same time.
however very rarely are non-source project files, such as .blend files, collaboratively designed this way. I don't think people are unwilling to use version control in this way, rather they just don't think of it since most artists aren't developers and art has been digitally designed for much longer than version control systems have been easy to use. So I think uploading files to repository and saving changes as commits, would be a good 'non-developer' "best practice" to apply to a software certification standard.
if they're "developing" then by definition they *are* developers, whether they think of themselves that way or not. in the hippocratic oath (both the original and the engineering version i found) it mentions that both practices combine art *and* science.
Anyways, developer 'best practices'. Having idle hands study and document code, particularly esoteric parts or parts they, the contributors, are unfamiliar with (so they can learn it*). Generally, the instinct we are taught from criticisms of our artwork, is that 'if we can't do something well, it's best not to do it at all', however with our version control systems generally the opposite is much more likely true, leaving room also for the hopefully soon to be colloquial: "if a task seems too easy, it is best leave it for someone else more novice; if a task seems too difficult, it is best to do it sloppily, so someone else won't have to do it start from nothing". So I think doing the best we possibly can do to develop the worst code and worst documentation we possibly can, (xD) is another good developer 'best practice'.
ok... there are two different definitions of "developer best practices". the above goes into detail on how an individual developer should best carry out the development process; the document that i would like to see written is one which helps people (covering both users *and* developers) to work as TEAMS. what INFRASTRUCTURE and general mind-set will help people to work together.
not "as a developer we must apply Agile or other Methodology". that's not appropriate: we have no proof that Agile or other "Methodology" will be more effective than any other, and i don't believe it to be appropriate for us to even research that.
Most of us know it's not uncommon for very large projects to receive access to proprietary source code under NDA, just to mod it**.
we are automatically excluding advice to proprietary software groups, so this is not a concern.
Likewise libre software is often perceived as insufficient as-is, however proprietary software can be close enough that it is more practical. In these cases, we need to respect reality, however also ensure all is carefully weighed. The biggest pitfall is looking at all the forks, addons, and extensions, then also looking at what you would like to do that one can't with proprietary software out of the box. Whilest being careful not to berate preferences, looking at how modifiable the base program is and what it could accomplish rather than what it can accomplish, is an important thing to make sure both project's developer's and non-developer's occasionally remember to do. So, considering what we could do more proportionally with what we can do, is an important developer and non-developer 'best practice', especially since as least occasionally they'll make one of their could-do'es someone else's can-do.
i don't understand where you're going with this. what is the main point?
Another practice that kindof ties in with the other one, and an often unsung aim of the GNU project as a whole, is make programming easier.
to make *programming* easier or to make *collaboration* easier?
Occasionally, a project will have extra resources or volunteers/contributors than their described roadmap warrants. Not always is this obvious from the beginning when it does happen. In fact, usually it isn't till the end that it becomes apparent. The ideal would be say 'even if proprietary software is more practical, use/extend free software for the benefit of everyone when you have the resource', but the reality is very rarely will you know you have the resources until it's far too late. Instead, a good programming practice might be to use the extra resources to modify the language itself or some api to make the code smaller. We all should know line counting is a trap, but we should also know we are more likely to read a pamphlet than a book. So, it should be a good developer 'best practice' should be to use extra resources at the end to make your code intuitive and concise, and to fork others so hopefully adaptations to libraries and compilers that make your code more concise and intuitive get upstream.
again, i feel that it is not appropriate to tell people these kinds of things, as it would be a restriction on what they do and learn. counter-example: some projects *have* to have a large code-base, by definition of their goals and scope.
This is just a rough start, but I wanted to post it here and get feedback before putting it on the wiki.
wrong focus / direction, john.
the first step *really is* to quite literally copy - verbatim - the gnu devel.html page and "generify" it.
where it says "we recommend savannah" put instead "we recommend the use of a Libre Hosting Service which has a minimum criteria of an A, as defined by the FSF's Hosting Criteria".
where it says "we recommend mailing lists on gnu.org" put instead "we recommend the use of software libre hosted mailing lists". a later revision should go into further detail as to *why* "announce", "users", "dev" etc. is recommended.
etc. etc.
this is a completely different focus from advising people on *coding methodologies*.
I really like the analogy of medicine to software development, particularly the use of the Hippocratic Oath as a point of reference. I was looking at the 'original' oath, and there is an interesting intersection with the morals of free software.
indeed there is.... but that is simply not understood by the majority of people associated with free software. you can usually tell who they are because they use the words "open" and "source".
which is why i feel it should be part of the recommendations. again: it is one of those things which is never really discussed because those people who *do* understand it just... follow it (without talking about it) and that means that those people who *don't* understand get really *really* confused and misled.
l.
"well everyone does it so we don't need to take special note of it" is how, historically, utterly valuable knowledge has been lost through the ages.
That's a very valid point. However I think the point of a standards organization should be to spread information about their standards that aren't widely or commonly known and it highly useful. Ultimately there will be some very new people looking for information, and for them knowing about the usefulness of version control would be important. Again, though, if only mundane things like that were taken on as a core tenets, I don't think anyone would take the organization seriously.
then, not least, you will discover that actually, everybody uses github "by default".... which, when you read (and take) the software engineer's hippocratic oath you find that it's very hard to honour that oath and use github at the same time.
I don't think there is much wrong the way github is designed, so much as it's economic model for sustaining itself. It requires closed source software development to survive. That's naughty.
if they're "developing" then by definition they *are* developers, whether they think of themselves that way or not. in the hippocratic oath (both the original and the engineering version i found) it mentions that both practices combine art *and* science.
We really don't want to throw around that label, it'll be controversial if we do. The overall point I was try to make in that clause is, 'everyone thinks to collaborate on source, but no one thinks to collaborate on assets'.
I don't think many realize it's possible for 100+ people to collaborate on a single drawing using version control and effective curation. It'd be absurd, but it'd be possible. As it stands, most assets are designed entirely by a single person, because people don't realize the collaboration tools and methodologies out there.
"if a task seems too easy, it is best leave it for someone else more novice; if a task seems too difficult, it is best to do it sloppily, so someone else won't have to do it start from nothing". So I think doing the best we possibly can do to develop the worst code and worst documentation we possibly can, (xD) is another good developer 'best practice'.
ok... there are two different definitions of "developer best practices". the above goes into detail on how an individual developer should best carry out the development process; the document that i would like to see written is one which helps people (covering both users *and* developers) to work as TEAMS. what INFRASTRUCTURE and general mind-set will help people to work together.
not "as a developer we must apply Agile or other Methodology". that's not appropriate: we have no proof that Agile or other "Methodology" will be more effective than any other, and i don't believe it to be appropriate for us to even research that.
Hmm.. *searches 'Agile development methodology'* I agree. I always hated those cause they felt like a tight 'inside of the inside box' structure. What I'm suggesting here is Definitely a collaborative methodology and -I think- a pretty abstract and general one.
Essentially the point is, in a large open development, odds are there will be people more senior and more novice to you. To develop the most difficult code 'for you' possible, we prioritize personal development over project development. I think that's a pretty solid general rule. If the code is really sincerely important, someone will clean up your mistakes and use your successes.
Yes, I the principle is of focusing on the individual, but there's nothing more important to remind a collective to do.
Most of us know it's not uncommon for very large projects to receive access to proprietary source code under NDA, just to mod it**.
we are automatically excluding advice to proprietary software groups, so this is not a concern.
For one, I think that's problematic. There are some projects to advance humanity stuck in closed-development, sometimes for honorable not-profit-motivations. Take radar development for example. Or, AI development. The last one is a hot-button topic, but I think AI development has to be relegated to those careful to avoid AI hating us.
For two, Some projects have a goal besides open source or profit. I really like Star Citizen*. They show us EVERYTHING, except their source. Obviously they can't because what they are trying to do, Requires modding closed source software. It's very open, even if it's very closed. If an organization like that wants to contribute to the development of some libre software they are borrowing, we should recognize them. Maybe if we buildup a strong rapport with them, they'll release their game into the public domain one day just to say 'thankz, for all the lulz'.
* https://robertsspaceindustries.com/about-the-game
[blah blah, about choosing between proprietary and free software]
i don't understand where you're going with this. what is the main point?
Most projects will be hardware projects and, like with your decision not to use kicad, there will be many incidences where open projects need to decide between modding-up open software or using proprietary software. Occasionally, the former is just not practical.
A standards organization, would do best to make sure they weighed both possibilities realistically and didn't just assume one or the other was more practical.
Another practice that kindof ties in with the other one, and an often unsung aim of the GNU project as a whole, is make programming easier.
to make *programming* easier or to make *collaboration* easier?
Both. Most languages today are pretty esoteric, even today. And, the problem isn't so much with the docs, as these languages were designed for people that already new another language equally esoteric, etc.
I would think Lisp's resurgence (as well as developing Guile) is a demonstration of GNU trying to break away from that paradigm.
[blah blah blah about making programming easier]
again, i feel that it is not appropriate to tell people these kinds of things, as it would be a restriction on what they do and learn. counter-example: some projects *have* to have a large code-base, by definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is. I only mean concise when it means intuitive. If a projects roadmap demands a large code base that is highly-esoteric and unintuitive, then that exhibits fault in the underlying language.
I'm not suggesting any project change to prioritize this. To the contrary, I think I was quite clear: a project should only dedicate 'extra' resources to this type of endeavor.
This is just a rough start, but I wanted to post it here and get feedback before putting it on the wiki.
wrong focus / direction, john.
the first step *really is* to quite literally copy - verbatim - the gnu devel.html page and "generify" it.
No one will want to advice from an organization that bible thumps the same points, much less financially support them in exchange for doing so. I think it is important to develop universally acceptable principles (i.e. things people find interesting to hear, but not necessarily want to hear) which are useful.
where it says "we recommend savannah" put instead "we recommend the use of a Libre Hosting Service which has a minimum criteria of an A, as defined by the FSF's Hosting Criteria".
Eh, 0-to-1. Redundancy is nice, but can be confusing. I think it would probably more effective to just let any libre hosting service which has criteria A call themselves savanna, but I don't think were a person stores their code should be a huge point of tension.
Ultimately, in a 0-to-1 paradigm, we are trying to develop closer to perfection, rather than closer to more competitive. Having multiple types of libre hosting services is like having multiple https://en.wikipedia.org/wiki/WP:POVFORK 'es.
On Tue, Jun 06, 2017 at 08:01:02AM -0400, John Luke Gibson wrote:
Both. Most languages today are pretty esoteric, even today. And, the problem isn't so much with the docs, as these languages were designed for people that already new another language equally esoteric, etc.
I would think Lisp's resurgence (as well as developing Guile) is a demonstration of GNU trying to break away from that paradigm.
Racket is a rather interesting variant of Scheme. Aside from having good tutorials and documentation, it explicitly allows mixed-language development. In fact, the first line of a Racket module usually states which language to use for the rest. And Racket has tools for defining alternative syntax and/or semantics.
[blah blah blah about making programming easier]
again, i feel that it is not appropriate to tell people these kinds of things, as it would be a restriction on what they do and learn. counter-example: some projects *have* to have a large code-base, by definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is. I only mean concise when it means intuitive. If a projects roadmap demands a large code base that is highly-esoteric and unintuitive, then that exhibits fault in the underlying language.
Racket's language-definition tool can be used to shorten notation within a large program, and also to define completely new languages.
For example, one of the languages so implemented is Algol 60.
Another is Scribble, a document compiler. Being based on Racket, it's possible to use arbitrary Scheme code in generating your document, should you choose to.
-- hendrik
I'm not suggesting any project change to prioritize this. To the contrary, I think I was quite clear: a project should only dedicate 'extra' resources to this type of endeavor.
There's one case in which a project decided they needed a scripting language, and they chose Gambit, a Scheme dialect that compiles to C or C++.
After they installed it, they discovered that it was often easier to add features in the scripting language than in the original C++ code.
Then they disovered that fixing bugs could often be done by replacing buggy C++ code by Scheme code.
After a few years, the codebase shrank from about 200,000 lines of code to about 30,000. (I'm not sure of the exact numbers, but they were of these orders of magnitude.)
-- hendrik
After a few years, the codebase shrank from about 200,000 lines of code to about 30,000. (I'm not sure of the exact numbers, but they were of these orders of magnitude.)
Dats bootiful (ﾉ◕ヮ◕)ﾉ*:･ﾟ✧
On 6/6/17, Hendrik Boom hendrik@topoi.pooq.com wrote:
On Tue, Jun 06, 2017 at 08:01:02AM -0400, John Luke Gibson wrote:
Both. Most languages today are pretty esoteric, even today. And, the problem isn't so much with the docs, as these languages were designed for people that already new another language equally esoteric, etc.
I would think Lisp's resurgence (as well as developing Guile) is a demonstration of GNU trying to break away from that paradigm.
Racket is a rather interesting variant of Scheme. Aside from having good tutorials and documentation, it explicitly allows mixed-language development. In fact, the first line of a Racket module usually states which language to use for the rest. And Racket has tools for defining alternative syntax and/or semantics.
[blah blah blah about making programming easier]
again, i feel that it is not appropriate to tell people these kinds of things, as it would be a restriction on what they do and learn. counter-example: some projects *have* to have a large code-base, by definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is. I only mean concise when it means intuitive. If a projects roadmap demands a large code base that is highly-esoteric and unintuitive, then that exhibits fault in the underlying language.
Racket's language-definition tool can be used to shorten notation within a large program, and also to define completely new languages.
For example, one of the languages so implemented is Algol 60.
Another is Scribble, a document compiler. Being based on Racket, it's possible to use arbitrary Scheme code in generating your document, should you choose to.
-- hendrik
I'm not suggesting any project change to prioritize this. To the contrary, I think I was quite clear: a project should only dedicate 'extra' resources to this type of endeavor.
There's one case in which a project decided they needed a scripting language, and they chose Gambit, a Scheme dialect that compiles to C or C++.
After they installed it, they discovered that it was often easier to add features in the scripting language than in the original C++ code.
Then they disovered that fixing bugs could often be done by replacing buggy C++ code by Scheme code.
After a few years, the codebase shrank from about 200,000 lines of code to about 30,000. (I'm not sure of the exact numbers, but they were of these orders of magnitude.)
-- hendrik
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Jun 6, 2017 at 1:01 PM, John Luke Gibson eaterjolly@gmail.com wrote:
"well everyone does it so we don't need to take special note of it" is how, historically, utterly valuable knowledge has been lost through the ages.
That's a very valid point. However I think the point of a standards organization should be to spread information about their standards that aren't widely or commonly known and it highly useful. Ultimately there will be some very new people looking for information, and for them knowing about the usefulness of version control would be important. Again, though, if only mundane things like that were taken on as a core tenets, I don't think anyone would take the organization seriously.
then, not least, you will discover that actually, everybody uses github "by default".... which, when you read (and take) the software engineer's hippocratic oath you find that it's very hard to honour that oath and use github at the same time.
I don't think there is much wrong the way github is designed, so much as it's
... you mean the word "its", not the two words "it" and "is" which are abbreviated as "it apostrophe s".
economic model for sustaining itself. It requires closed source software development to survive. That's naughty.
it does deeper than that, in a very seductive and insidious way. what is the primary focus - what does github drive people to do, that distinguishes it from sourceforge, savannah, alioth, codeforge and other group collaboration systems?
if they're "developing" then by definition they *are* developers, whether they think of themselves that way or not. in the hippocratic oath (both the original and the engineering version i found) it mentions that both practices combine art *and* science.
We really don't want to throw around that label,
what ambiguous concept are you referring to with the word "that" which has not been made explicitly clear? there are about 40 words in the paragraph that you are referring to: i have no idea which one the word "that" refers to.
Essentially the point is, in a large open development, odds are there will be people more senior and more novice to you. To develop the most difficult code 'for you' possible, we prioritize personal development over project development. I think that's a pretty solid general rule. If the code is really sincerely important, someone will clean up your mistakes and use your successes.
not if they are there to further their own personal agenda because there is no "Charter" to keep them goal-focussed, they won't. there are a number of large software libre projects where individuals have, over time, used their technical expertise to become the most vicious, horrible, deceptive bullies you will ever encounter in a technical environment. their peers become *so afraid* to do something about it that these people *remain* in power, abusing others whenever the opportunity presents itself.
this is something that i have encountered not just once but *multiple* times, in several extremely high-profile strategic software libre projects.
Most of us know it's not uncommon for very large projects to receive access to proprietary source code under NDA, just to mod it**.
we are automatically excluding advice to proprietary software groups, so this is not a concern.
For one, I think that's problematic. There are some projects to advance humanity stuck in closed-development, sometimes for honorable not-profit-motivations. Take radar development for example. Or, AI development. The last one is a hot-button topic, but I think AI development has to be relegated to those careful to avoid AI hating us.
true.
however - and i am applying the "Bill of Ethics" here - the Bill of Ethics is very clear as to what to do in these situations. "Creativity" is defined as "resources times intelligence". therefore, if someone is using Creativity for unethical purposes (where in this case we *know* that proprietary software is unethical.... let's not argue about that), then there are two options to ETHICALLY undermine their unethical objective:
(1) reduce their access to resources (2) reduce their access to intelligence enhancement.
now, in the process of writing a standard, we do not have the means to (directly) reduce the amount of resources that unethical proprietary software teams have access to, but we *can* reduce their access to intelligence enhancement... by *SPECIFICALLY* designing the standard so that it targets ETHICAL software development, and that means LIBRE SOFTWARE ONLY.
i am NOT going to aid or assist unethical practices - period, luke. i will NOT be involved in ANY WAY in the development of a standard which could be utilised for the advancement, augmentation, acceleration or improvement of unethical software development practices, and that really is the end of the matter.
[blah blah, about choosing between proprietary and free software]
i don't understand where you're going with this. what is the main point?
Most projects will be hardware projects and, like with your decision not to use kicad,
that's mainly to do with the fact that it's shit software. sadly, it's only when you've utilised well-written proprietary software that you realise quite how hostile kicad actually is to getting the job done. i'm not very happy about that, but it turns out that i am not the only person to have tried.
there will be many incidences where open projects need to decide between modding-up open software or using proprietary software. Occasionally, the former is just not practical.
A standards organization, would do best to make sure they weighed both possibilities realistically and didn't just assume one or the other was more practical.
no. sorry. i cannot be involved in anything which is unethical. that is ABSOLUTE and non-negotiable. the consequences for me to be involved in anything that is unethical are too disastrous to contemplate.
writing a high-profile standard (which is to be published by the FSF) that helps proprietary software to improve its success would be totally unethical.
again, i feel that it is not appropriate to tell people these kinds of things, as it would be a restriction on what they do and learn. counter-example: some projects *have* to have a large code-base, by definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is. I only mean concise when it means intuitive. If a projects roadmap demands a large code base that is highly-esoteric and unintuitive, then that exhibits fault in the underlying language.
no it does not. certain tasks *require* specific languages. for example: the linux kernel *requires* that you use assembler and c. UNDER NO CIRCUMSTANCES is c++ permitted to be utilised.
likewise, python is also developed in c. you can look up how pypy has been getting on, to find out how unsuccessful it was to attempt to implement python in anything other than c.
also you can look up the efforts by the samba team to abandon c and to try to write parts of samba 4 in python. this was also a spectacular and long-drawn-out failure.
in the case of samba, it has to be realised that samba is an amalgamation of something like over TEN different network protocols, at least FOUR separate and distinct RPC mechanisms, and over FORTY separate and distinct inter-related services! the complexity of the endeavour is just... astounding.
when samba 4 was first announced i thought it was a joke. they intended to implement not only the MSRPC services, but also to implement their own Kerberos Server and LDAP server. what the FUCK?? Heimdal is a QUARTER of a MILLION lines of code on its own. openldap is likewise similarly large... and samba is probably getting on for HALF a million lines of code WITHOUT these projects added to it!
they're completely out of their MINDS if they think that's going to work... or be accepted by sysadmins... and guess what? 10 years later they still hadn't finished, and 15 years later they'd driven pretty much every single large Enterprise (that had deployed samba for years) right back to Windows NT Server!
the reason i am mentioning the example of Samba is because despite following what is known to be "best software libre hosting practices", they DO NOT HAVE A CHARTER and the developers *certainly* do not sign up to the Software Engineer's variant of the Hippocratic Oath.
there is more, but i will relay that another time.
This is just a rough start, but I wanted to post it here and get feedback before putting it on the wiki.
wrong focus / direction, john.
the first step *really is* to quite literally copy - verbatim - the gnu devel.html page and "generify" it.
No one will want to advice from an organization that bible thumps the same points, much less financially support them in exchange for doing so.
do you understand why those software development practices (with the addition of a Charter) listed on the gnu devel page are so effective?
ok let's go over it.
what are the defining (common) characteristics of the following high-profile long-running strategic free software projects, and, of the superset of those combined characteristics, which projects LACK those characteristics?
* Samba * Wine * ReactOS * Python * Perl * Exim4 * sendmail * Linux Kernel * GNU Projects (as defined by that devel.html page) * Webkit * Blink * Firefox * Debian * Ubuntu * Slackware * systemd * mysqldb * mariadb * openoffice * libreoffice * X11 * Xorg * Kerberos * Heimdal * OpenLDAP
make a list of all the things that those projects have in common, then, after making that list, identify the things on that list which individual projects *do not* have.
i will then provide you with some illustrations of events that have occurred within those teams which have been extremely detrimental to the users of those packages.
we will then cross-reference the things that are MISSING from those projects with the detrimental consequences, to see if there is any correlation.
if you can think of any other long-standing high-profile projects which should be on that list, feel free to add them.
where it says "we recommend savannah" put instead "we recommend the use of a Libre Hosting Service which has a minimum criteria of an A, as defined by the FSF's Hosting Criteria".
Eh, 0-to-1.
i don't understand this colloquial turn of phrase. anyway it is not important: going through the list above is much more important.
I don't think were a person stores their code should be a huge point of tension.
i know you don't. so i therefore need to walk you through the process of understanding why it is, in fact, one of *the* most important factors (in amongst many of roughly equal priority). going through that list, above, will help to do that.
l.
On Tue, 6 Jun 2017 18:47:48 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Tue, Jun 6, 2017 at 1:01 PM, John Luke Gibson eaterjolly@gmail.com wrote:
"well everyone does it so we don't need to take special note of it" is how, historically, utterly valuable knowledge has been lost through the ages.
That's a very valid point. However I think the point of a standards organization should be to spread information about their standards that aren't widely or commonly known and it highly useful. Ultimately there will be some very new people looking for information, and for them knowing about the usefulness of version control would be important. Again, though, if only mundane things like that were taken on as a core tenets, I don't think anyone would take the organization seriously.
then, not least, you will discover that actually, everybody uses github "by default".... which, when you read (and take) the software engineer's hippocratic oath you find that it's very hard to honour that oath and use github at the same time.
I don't think there is much wrong the way github is designed, so much as it's
<snip>
economic model for sustaining itself. It requires closed source software development to survive. That's naughty.
it does deeper than that, in a very seductive and insidious way. what is the primary focus - what does github drive people to do, that distinguishes it from sourceforge, savannah, alioth, codeforge and other group collaboration systems?
I give up. Why do some people dislike github or sourceforge? This is at least the third mailing list in which I've seen discontent without a reason given.
[blah blah, about choosing between proprietary and free software]
i don't understand where you're going with this. what is the main point?
Most projects will be hardware projects and, like with your decision not to use kicad,
that's mainly to do with the fact that it's s*** software. sadly, it's only when you've utilised well-written proprietary software that you realise quite how hostile kicad actually is to getting the job done. i'm not very happy about that, but it turns out that i am not the only person to have tried.
Just out of interest, not that I can do something about it *now*, is there any sort of list of "Things-that-a-kicad-or-clone-aught-to-do"? People can't fix or add what they don't know that they are missing and I, for one, would not ever use, or if I did not read this mailing list, know the name of, a "better" proprietary alternative.
there will be many incidences where open projects need to decide between modding-up open software or using proprietary software. Occasionally, the former is just not practical.
A standards organization, would do best to make sure they weighed both possibilities realistically and didn't just assume one or the other was more practical.
no. sorry. i cannot be involved in anything which is unethical. that is ABSOLUTE and non-negotiable. the consequences for me to be involved in anything that is unethical are too disastrous to contemplate.
writing a high-profile standard (which is to be published by the FSF) that helps proprietary software to improve its success would be totally unethical.
??? Why not start with recommending them to make their software open source? Or set up a time table with the sources being released when the project has reached a certain reasonable financial goal or age. Age was used to determine when to release at least warzone2100, firefox, and X. Money wise, a company could say that after they made, say 2X the amount of their costs for producing the SW, then the users have "Bought the code". You have to start converting the closed source SW fanboys from somewhere.
again, i feel that it is not appropriate to tell people these kinds of things, as it would be a restriction on what they do and learn. counter-example: some projects *have* to have a large code-base, by definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is. I only mean concise when it means intuitive. If a projects roadmap demands a large code base that is highly-esoteric and unintuitive, then that exhibits fault in the underlying language.
no it does not. certain tasks *require* specific languages. for example: the linux kernel *requires* that you use assembler and c. UNDER NO CIRCUMSTANCES is c++ permitted to be utilised.
likewise, python is also developed in c. you can look up how pypy has been getting on, to find out how unsuccessful it was to attempt to implement python in anything other than c.
also you can look up the efforts by the samba team to abandon c and to try to write parts of samba 4 in python. this was also a spectacular and long-drawn-out failure.
in the case of samba, it has to be realised that samba is an amalgamation of something like over TEN different network protocols, at least FOUR separate and distinct RPC mechanisms, and over FORTY separate and distinct inter-related services! the complexity of the endeavour is just... astounding.
when samba 4 was first announced i thought it was a joke. they intended to implement not only the MSRPC services, but also to implement their own Kerberos Server and LDAP server. what the FUCK?? Heimdal is a QUARTER of a MILLION lines of code on its own. openldap is likewise similarly large... and samba is probably getting on for HALF a million lines of code WITHOUT these projects added to it!
they're completely out of their MINDS if they think that's going to work... or be accepted by sysadmins... and guess what? 10 years later they still hadn't finished, and 15 years later they'd driven pretty much every single large Enterprise (that had deployed samba for years) right back to Windows NT Server!
the reason i am mentioning the example of Samba is because despite following what is known to be "best software libre hosting practices", they DO NOT HAVE A CHARTER and the developers *certainly* do not sign up to the Software Engineer's variant of the Hippocratic Oath.
there is more, but i will relay that another time.
<snip>
If they want all that functionality, why not just utilize the already opensource libraries for the task? Developing everything in house seems so.... wasteful and slow. The typical reason given is control, but if you are in control then *you are responsible* and then and there ball gets dropped. Look at blender, if I build with anything other than their in house copies of libraries it SEGFAULTS when I start it up.
Thanks, David
doark@mail.com writes:
I give up. Why do some people dislike github or sourceforge? This is at least the third mailing list in which I've seen discontent without a reason given.
Same reason they dislike proprietary software in general.
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
I give up. Why do some people dislike github or sourceforge?
I don't think the two are in the same category at all (and the message to which you replied was specifically putting SourceForge in the "other" category, indeed).
As to why some people dislike GitHub? I can't talk about other people, but personally, I don't have much trust in it for the following reasons: - It's a commercial company, so it has to make money somehow from its free service. - It doesn't publish its own code as Free Software (not even the Javascript code you download into your browser to use the site). - I feel a lot of pressure to use it. IOW they work hard to use the so-called "networking effect" to pull people to their site. The more you use it, the more you pressure other people to do likewise. I hate this kind of centralization because it gives too much power to a single unaccountable entity.
Stefan
doark@mail.com writes:
I give up. Why do some people dislike github or sourceforge? This is at least the third mailing list in which I've seen discontent without a reason given.
But reasons are given and to the point here: https://www.fsf.org/news/gnu-releases-ethical-evaluations-of-code-hosting-se...
One major problem addressed is the need to run non-free java-script to use the service I think.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Jun 11, 2017 at 9:50 PM, doark@mail.com wrote:
Just out of interest, not that I can do something about it *now*, is there any sort of list of "Things-that-a-kicad-or-clone-aught-to-do"? People can't fix or add what they don't know that they are missing and I,
i've tried that: reported several bugs. the developers of kicad became entrenched in their own belief that their approach was absolutely correct, superior, and that the problem did not exist. after about a year, including input from other people who supported the bugreport (also ignored), i went, "y'know what? this isn't worth my time and effort".
??? Why not start with recommending them to make their software open source?
have you seen how oracle's attitude works out? mysqldb, virtualbox, openoffice - look up how those have been received by the software libre community.
l.
On Sun, Jun 11, 2017 at 04:50:50PM -0400, doark@mail.com wrote:
I give up. Why do some people dislike github or sourceforge? This is at least the third mailing list in which I've seen discontent without a reason given.
Git is a nice distributed version control system. That is: each node contains the whole archive including all of the history. No inherent central node. So all you need to develop with it is some basic hosting, right?
Now Github comes along and tells you: if you use git in our site, you can have extra goodies. Pull requests work. But only so long as you are a user of Github to begin with. If it's not in Github, it might as well not exist.
So suddenly you have a single point of failure. This is not that good. For instance, what if Github decides not to allow you to host your project (for whatever legitimate reason)?
I believe most people who object using Github here object using those extra services and not merely using Github as a git hosting service. But this point is mostly moot, as why would you use Github and not use bug pull requests, bug tracking etc.?
Are they evil? Certainly not. They provide a great service that people like. We should also provide quality services / software or otherwise people will keep depending on walled gardens.
Sourceforge has held a somewhat similar position in the past (at around 1999-2005 or so) when a large portion of the projects were hosted there because it provided a very fine hosting facility (files, web, shell, mailing list, tasks, and more) for free. It is no longer in that position. One problem with it nowadays is that they have been shown to used some non-optimal methods of getting ad money in the recent past.
when i began a property business i read several books on the subject. one of them had this wonderful quirky advice to view 100 houses before putting any money down. i booked several viewings a day with multiple estate agents, spending at most 10 minutes in each.
after about 80 houses i came across one that was very strange: the price was much lower than it was for comparable houses that i'd seen. without having viewed so many houses i would not have known this.
this same lesson i applied to the development of the EOMA68 standard. i spent several years studying dozens of successful SoCs, looking for the common factors between them all. several iterations had to be made to get it right.
if we are to develop a standard i feel that it is imperative to do a similar analysis of what constitutes a successful software libre project.
this task isn't actually very difficult: it's almost mechanical and purely logical. but i feel that it is very important that anything that goes into the standard is backed up by a heck of a lot of evidence that whatever advice is in it is demonstrably and consistently long-term successful across not one but *multiple* projects.
l.
On Tue, Jun 6, 2017 at 6:47 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
what are the defining (common) characteristics of the following high-profile long-running strategic free software projects, and, of the superset of those combined characteristics, which projects LACK those characteristics?
- Samba
- Wine
- ReactOS
- Python
- Perl
- Exim4
- sendmail
- Linux Kernel
- GNU Projects (as defined by that devel.html page)
- Webkit
- Blink
- Firefox
- Debian
- Ubuntu
- Slackware
- systemd
- mysqldb
- mariadb
- openoffice
- libreoffice
- X11
- Xorg
- Kerberos
- Heimdal
- OpenLDAP
make a list of all the things that those projects have in common, then, after making that list, identify the things on that list which individual projects *do not* have.
i will then provide you with some illustrations of events that have occurred within those teams which have been extremely detrimental to the users of those packages.
we will then cross-reference the things that are MISSING from those projects with the detrimental consequences, to see if there is any correlation.
if you can think of any other long-standing high-profile projects which should be on that list, feel free to add them.
On Tue, Jun 06, 2017 at 05:51:33AM +0100, Luke Kenneth Casson Leighton wrote: ...
the first step *really is* to quite literally copy - verbatim - the gnu devel.html page and "generify" it.
where it says "we recommend savannah" put instead "we recommend the use of a Libre Hosting Service which has a minimum criteria of an A, as defined by the FSF's Hosting Criteria".
where it says "we recommend mailing lists on gnu.org" put instead "we recommend the use of software libre hosted mailing lists". a later revision should go into further detail as to *why* "announce", "users", "dev" etc. is recommended.
etc. etc.
As it seems to me the above points are done. Thank you Luke for fixing my mishappened sentence. There is now a point for version control, mailing lists and web pages at the wiki (http://rhombus-tech.net/proposed_best_practices/). Regarding the goal of a general standard for libre projects I don't think it is necessary to cover the quite specific further points of the gnu devel.html page: "FTP", "Login accounts", "Hydra: Continuous builds and portability testing" and "platform-testers: Manual portability testing".
I have read a good part of the Maintainer's Guide: https://www.gnu.org/prep/maintain/maintain.txt and wonder how to best incorporate it into the draft for best practices. For example from gnu devel.html page we took the point about web pages and generalised it: "we recommend to host the webpages for the project using resources that meet the FSF's Hosting Criteria" Chapter 12 Web Pages of the Maintainer's Guide covers a lot of details.
Some questions: Has anyone else started to work on it (offline)? How long shall the first draft of the standard be (e.g. 10 pages, 100 pages, as long as necessary)?
As you can see I am looking for guidance and some kind of roadmap to prevent working in the wrong direction.
kind regards Pablo
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Jul 12, 2017 at 11:36 AM, Pablo Rath pablo@parobalth.org wrote:
On Tue, Jun 06, 2017 at 05:51:33AM +0100, Luke Kenneth Casson Leighton wrote: ...
the first step *really is* to quite literally copy - verbatim - the gnu devel.html page and "generify" it.
where it says "we recommend savannah" put instead "we recommend the use of a Libre Hosting Service which has a minimum criteria of an A, as defined by the FSF's Hosting Criteria".
where it says "we recommend mailing lists on gnu.org" put instead "we recommend the use of software libre hosted mailing lists". a later revision should go into further detail as to *why* "announce", "users", "dev" etc. is recommended.
etc. etc.
As it seems to me the above points are done. Thank you Luke for fixing my mishappened sentence. There is now a point for version control, mailing lists and web pages at the wiki (http://rhombus-tech.net/proposed_best_practices/). Regarding the goal of a general standard for libre projects I don't think it is necessary to cover the quite specific further points of the gnu devel.html page: "FTP", "Login accounts", "Hydra: Continuous builds and portability testing" and "platform-testers: Manual portability testing".
if mentioned at all there should be some documented "upload / download" method (upload for developers, download for users) but nothing quite as specific as "You Must Use FTP" or even saying how to set up FTP. "use libre hosting service" pretty much covers what needs to be done here.
build-testing? other than "if it is needed, using libre source build and test programs so that people can duplicate the test and build results for themselves" is *partially* covered under the terms of the GNU GPL(s).... but *not* if people say use the Apache License.
so... yes, my feeling is that build and test procedures *if used and/or needed* should really be specified in a general way.
Some questions: Has anyone else started to work on it (offline)?
been too busy here
How long shall the first draft of the standard be (e.g. 10 pages, 100 pages, as long as necessary)?
short... but as long as necessary. i don't see any reason it should be longer than 10 pages.
As you can see I am looking for guidance and some kind of roadmap to prevent working in the wrong direction.
great!
Meh, I don't really think myself ready to write this kind of a document. I really don't know as much as I'd like to on the topic.
On Thu, Jul 13, 2017 at 2:11 PM, Jean Flamelle eaterjolly@gmail.com wrote:
Meh, I don't really think myself ready to write this kind of a document. I really don't know as much as I'd like to on the topic.
well... would you like to help evaluate some of the long-standing well-known free software projects out there? i vaguely recall making a list a few weeks ago. we need a table showing what "features" each of them has. do they use mailing lists, do they have a forum, do they have a charter, do they have a "code of conduct" *shudder*, do they properly honour free software licenses or do they have some sort of unethical "forced contributor agreement" (oracle in particular).
a comparison of pre and post forks for major projects such as x11 / xorg, openoffice / libreoffice, mysql / mariadb, and so on, would be really *really* interesting and informative.
l.
On 7/13/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Thu, Jul 13, 2017 at 2:11 PM, Jean Flamelle eaterjolly@gmail.com wrote:
Meh, I don't really think myself ready to write this kind of a document. I really don't know as much as I'd like to on the topic.
well... would you like to help evaluate some of the long-standing well-known free software projects out there? i vaguely recall making a list a few weeks ago. we need a table showing what "features" each of them has. do they use mailing lists, do they have a forum, do they have a charter, do they have a "code of conduct" *shudder*, do they properly honour free software licenses or do they have some sort of unethical "forced contributor agreement" (oracle in particular).
a comparison of pre and post forks for major projects such as x11 / xorg, openoffice / libreoffice, mysql / mariadb, and so on, would be really *really* interesting and informative.
l.
I would be glad to do that! I think it would be very important to focus on projects that create software or firmware, which are of particular relevance to non-programmers. I think this because they'll likely be under significantly disproportionate proportionate pressure compared to the amount of contributions to code that they receive. Blender, Gimp, and Aperture, are just a few that come to mind immediately, but projects like RISC-V and Kicad would arguably also count since there are still large portions of their audiences likely specialize very far away from the type of software programming knowledge required to contribute.
I think for most people the inclination to donate to any software projects fiscally, would be predictable (with a high confidence value) by the the ratio of technical programming knowledge and their dependence on the software created by that project. For that reason you could also say, it would be a higher priority to evaluate gnome as as a software project than debian, because ubuntu is more often pitched to a less technical audience. Of course, the fsf already evaluates distributions and doesn't endorse ubuntu anyway, so it would probably be perceived in really bad taste if the libre community started listing reasons why they gave gnome a poor evaluation score if that was the outcome, so I suppose it would be best to avoid it all together and only evaluate desktop environments as software projects if the are made available in an fsf-endorsed distribution by default. (I know I've heard people say trisquel is based on ubuntu, but I don't know what desktop environment it uses by default).
All in all, for a base, I think aperture would be a good starting point, since GIMP and Blender get a lot of flack that aperture doesn't atm. I realize most of what they are doing is hardware, but their is a lot of firmware involved. Also, I haven't heard very many complaints about inkscape, so that would be a decent one to start with. I'm hesitant to talk about OpenShot or libreoffice early on, because they are (as we like to say in the wikipedia community) POV-forks than independent projects. In other words, it's impossible to honestly and sincerely evaluate LibreOffice as a project without comparing it to OpenOffice and likewise OpenShot to Blender and in small part Audacity.
Since I don't feel especially confident in my ability handling this topic, I would probably sooner get feedback through this thread than add any "evaluations" I make straight to the wiki. Because of this, I think it's important I start by documenting on which ever of the "good candidate" projects attracts the most interest in this thread, at least on the philosophical level of how they "go about their business" if not on a fundamental level of "I really like this project".
On Fri, Jul 14, 2017 at 2:18 PM, Jean Flamelle eaterjolly@gmail.com wrote:
well... would you like to help evaluate some of the long-standing well-known free software projects out there? i vaguely recall making
I would be glad to do that!
yay!
I think it would be very important to focus on projects that create software or firmware, which are of particular relevance to non-programmers. I think this because they'll likely be under significantly disproportionate proportionate pressure compared to the amount of contributions to code that they receive. Blender, Gimp, and Aperture, are just a few that come to mind immediately, but projects like RISC-V and Kicad would arguably also count since there are still large portions of their audiences likely specialize very far away from the type of software programming knowledge required to contribute.
oo good point. yeah feel free to add some to the list.
doing the samba one, it really didn't take long. took about... 4 minutes? looked to see if they have a charter (they don't), looked at their "dev" page to see if they have a VCS (they do: git), etc. etc. oh - i forgot one column: IRC channels!
http://rhombus-tech.net/proposed_best_practices/
added.
I think for most people the inclination to donate to any software projects fiscally, would be predictable (with a high confidence value) by the the ratio of technical programming knowledge and their dependence on the software created by that project. For that reason you could also say, it would be a higher priority to evaluate gnome as as a software project than debian, because ubuntu is more often pitched to a less technical audience.
ok the first phase is: get the info. evaluation comes later.
Of course, the fsf already evaluates distributions
not like this they don't. they evaluate them for *freedom* related (ethical) criteria. the purpose of this exercise is to first compile a list of projects and then "distil" the best and most efffective *development* practices, by demonstrating provably that, of the top NN% most highly respected projects, this is what they do.
that's very very different... and means that the FSF's development practices (ok actually the GNU projects') are "on the list for evaluation".
and doesn't endorse ubuntu anyway, so it would probably be perceived in really bad taste if the libre community started listing reasons why they gave gnome a poor evaluation score if that was the outcome, so I suppose it would be best to avoid it all together and only evaluate desktop environments as software projects if the are made available in an fsf-endorsed distribution by default. (I know I've heard people say trisquel is based on ubuntu, but I don't know what desktop environment it uses by default).
All in all, for a base, I think aperture would be a good starting point, since GIMP and Blender get a lot of flack that aperture doesn't atm.
well.... we would get to find that out as part of having a look at exactly what each of those projects do, and then seeing if there's a correlation, yes?
but first we need to collect the information.
oh. also, we need to make some sort of measure of the "effectiveness" of the project. whether it's caused people hassle (taken up inordinate amounts of time), whether the developers are liked or despised, whether they are welcoming and supportive of contributors (or not), how many people use it, and so on.
it'll actually be quite a fascinating study.
I realize most of what they are doing is hardware, but their is a lot of firmware involved. Also, I haven't heard very many complaints about inkscape, so that would be a decent one to start with. I'm hesitant to talk about OpenShot or libreoffice early on, because they are (as we like to say in the wikipedia community) POV-forks than independent projects. In other words, it's impossible to honestly and sincerely evaluate LibreOffice as a project without comparing it to OpenOffice and likewise OpenShot to Blender and in small part Audacity.
that's *exactly* the point of the exercise.... but that should not be done *right now*. at the moment all i would like there to be is a collation of "info". 3-4 minutes per project, "do they have a charter yes no do they use version control yes no is their infrastructure libre-hosted yes no".
that's all.
Since I don't feel especially confident in my ability handling this topic, I would probably sooner get feedback through this thread than add any "evaluations" I make straight to the wiki.
right now all that needs to be done is find the website for the project, and record what you find. take a look at the samba one as a starting point.
Because of this, I think it's important I start by documenting on which ever of the "good candidate" projects attracts the most interest in this thread, at least on the philosophical level of how they "go about their business" if not on a fundamental level of "I really like this project".
we can discuss that later. and make sure that ideas on how to evaluate / compare projects are recorded in the wiki. but... later.
l.
On Fri, Jul 14, 2017 at 5:02 PM, Jean Flamelle eaterjolly@gmail.com wrote:
rhombus-tech.net appears to be down for me atm lol
http://downforeveryoneorjustme.com/rhombus-tech.net
it's just you :)
That was weird, but anyways I updated the table by reorganizing it, cleaned the source a bit, added data for apertus and projects on the list.
Let me know what you think of the formating changes.
On Sat, Jul 15, 2017 at 6:04 PM, Jean Flamelle eaterjolly@gmail.com wrote:
That was weird, but anyways I updated the table by reorganizing it, cleaned the source a bit, added data for apertus and projects on the list.
*well-known* :) is urbit actually... well-known??
Let me know what you think of the formating changes.
liked some, didn't like others. "etiquette guidelines" doesn't have the same toxic punch as "code of conduct" is well-known for. liked the idea of including the VCS and if it's libre-hosted (likewise for bugtracker) but *not* the wording you chose ("self-hosted"). self-hosted could mean "proprietary and therefore unethical" and people would put "yeah it's GR8 maaan!" so i changed it back *specifically* to "is it libre hosted yes or no" because that's really important.
basically we're collating info - evidence - that ethical (or unethical) practices support a project's lifecycle... and other obseervations. what practices make a project both ethical *and* long-term successful.
also i turned the table round by 90 degrees as i could see it getting far too long, and then broke them down into related groups. still some TODO.
l.
liked some, didn't like others. "etiquette guidelines" doesn't have the same toxic punch as "code of conduct" is well-known for. liked the idea of including the VCS and if it's libre-hosted (likewise for bugtracker) but *not* the wording you chose ("self-hosted"). self-hosted could mean "proprietary and therefore unethical" and people would put "yeah it's GR8 maaan!" so i changed it back *specifically* to "is it libre hosted yes or no" because that's really important.
basically we're collating info - evidence - that ethical (or unethical) practices support a project's lifecycle... and other obseervations. what practices make a project both ethical *and* long-term successful.
also i turned the table round by 90 degrees as i could see it getting far too long, and then broke them down into related groups. still some TODO.b
l.
I think any distro that is at devuan standards or better should be on the list.
I would have said debian standard, but, I thought you might want me to stay clear of that... so yeah...
as for repositories for hosting libre packages, notabug and gogs are good ones.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sat, Jul 15, 2017 at 8:57 PM, zap calmstorm@posteo.de wrote:
I think any distro that is at devuan standards or better should be on the list.
agreed.
I would have said debian standard, but, I thought you might want me to stay clear of that... so yeah...
... hadn't occurred to me at all, but now that you mention it, let's think about it... yes i would, because each project stands on its own merits and is responsible for its own management.
as for repositories for hosting libre packages, notabug and gogs are good ones.
are they well-known, well-established and prominent?
l.
as for repositories for hosting libre packages, notabug and gogs are good ones.
are they well-known, well-established and prominent?
l.
Notabug is used for libreboot so it cannot be a bad idea. as for gogs, librecmc uses gogs.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Hi EOMA68 community,
the Free Software Foundation Europe chose Gitea, a gogs fork, for their new source code hosting service: https://git.fsfe.org/
Cheers, Christian
Am 16. Juli 2017 18:26:40 MESZ schrieb zap calmstorm@posteo.de:
as for repositories for hosting libre packages, notabug and gogs are good ones.
are they well-known, well-established and prominent?
l.
Notabug is used for libreboot so it cannot be a bad idea. as for gogs, librecmc uses gogs.
When I try to update the wikipage, I get: "An error occurred while writing CGI reply" Fortunately didn't lose anything.
On Thu, Dec 21, 2017 at 7:42 PM, Jean Flamelle eaterjolly@gmail.com wrote:
When I try to update the wikipage, I get: "An error occurred while writing CGI reply"
that shouldn't happen. you've created a login? let's ping phil.
Fortunately didn't lose anything.
send it to me, i have git repo access.
On 12/21/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
that shouldn't happen. you've created a login? let's ping phil.
Yu, and its worked before.
[Btw, does look much better with a monospace font and spaces instead of tabs; Some one should patch ikiwiki to display source in a monospaced font.]
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Dec 22, 2017 at 7:52 PM, Jean Flamelle eaterjolly@gmail.com wrote:
On 12/21/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
that shouldn't happen. you've created a login? let's ping phil.
Yu, and its worked before.
ok. one for phil, definitely. btw http://rhombus-tech.net/recentchanges/ shows that there has been a successful edit
[Btw, does look much better with a monospace font and spaces instead of tabs; Some one should patch ikiwiki to display source in a monospaced font.]
it does. on both chrome and firefox. some as-yet-unidentified factor involved here, i feel.
l.
On 7/15/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
liked some, didn't like others. "etiquette guidelines" doesn't have the same toxic punch as "code of conduct" is well-known for.
The word "code" in "code of conduct" does usually implies formal membership, so I thought it might be confusing to some people if the phrase became popular in closed circles.
Etiquette guidelines isn't perfect either, because samba technically actually has a page called "Etiquette" however that refers to trimming mailing list posts and not in any way how people ought to treat each other.
Perhaps "Contributor Conduct Guidelines"?
liked
the idea of including the VCS and if it's libre-hosted (likewise for bugtracker) but *not* the wording you chose ("self-hosted").
I opted to separate it like that to make it more unambiguous, since there are two possible definitions of libre in regard to websites: open-source/free scripts and open-source/free server code. Most browsers provide no practical way to prove the source code belongs to the scripts actually sent by the server, without running them, and because of this it might be argued that the server code should also be libre so that anyone could run an offline mirror.
If we say arbitrarily that a website is libre it could mean one of three things: functions w/o script, open-source/free scripts, or open-source/free server code.
The assumption is that if the server code is libre, then self-hosting should make by extension the repositories libre. Though, I suppose there would be nothing hindering someone from just omitting that part of the server code, on second thought. It's a tricky situation.
also i turned the table round by 90 degrees as i could see it getting far too long, and then broke them down into related groups. still some TODO.
Thanks, much less cluttered!
I use cut-and-paste to convert the spaces to tabs just now to clean the source.
Also, on a side note, I put urbit on there because they are unorthodox and because they have an unusually high ratio interest compared to people actually able to contribute, much like you would expect from RISC or KiCAD, but not 'another' replacement for apache.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Jul 16, 2017 at 6:58 AM, Jean Flamelle eaterjolly@gmail.com wrote:
On 7/15/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
liked some, didn't like others. "etiquette guidelines" doesn't have the same toxic punch as "code of conduct" is well-known for.
The word "code" in "code of conduct" does usually implies formal membership, so I thought it might be confusing to some people if the phrase became popular in closed circles.
no - it's well-known that "code of conduct" is a dangerous, toxic and highly unethical system of "control" over contributors. *i* didn't know that, so i did a comprehensive analysis here on the list about 6-8 months ago, and emphatically agreed with the assessment.
unfortunately there are many many projects that have absolutely no idea of the dangers of "codes of conduct" so continue to deploy them.
so the idea is to *specifically* identify those projects that have one of these dangerous "codes of conduct" in order to see if there is a correlation between harm done to developers and end-users and the use of such toxic documents.
Etiquette guidelines isn't perfect either, because samba technically actually has a page called "Etiquette" however that refers to trimming mailing list posts and not in any way how people ought to treat each other.
okaaay.... sooo.... that should probably go on a "/" mailing list / ML-etiquette
Perhaps "Contributor Conduct Guidelines"?
no. sorry. explained above.
liked
the idea of including the VCS and if it's libre-hosted (likewise for bugtracker) but *not* the wording you chose ("self-hosted").
I opted to separate it like that to make it more unambiguous, since there are two possible definitions of libre in regard to websites: open-source/free scripts and open-source/free server code.
hmmm.... *thinks*... is the distinction important? don't know. so it should probably go on the list. it might be statistically significant.
so a column "Web site source available / License" and now that i think about it "Documentation source available / License"
should be added
Most browsers provide no practical way to prove the source code belongs to the scripts actually sent by the server, without running them,
someone somewhere will run librejs to determine that
and because of this it might be argued that the server code should also be libre so that anyone could run an offline mirror.
more importantly they can *fork* the project.... but only if the full source of the web site server source is available and does not critically depend on proprietary components.
If we say arbitrarily that a website is libre it could mean one of three things: functions w/o script, open-source/free scripts, or open-source/free server code.
true.
The assumption is that if the server code is libre, then self-hosting should make by extension the repositories libre. Though, I suppose there would be nothing hindering someone from just omitting that part of the server code, on second thought. It's a tricky situation.
also i turned the table round by 90 degrees as i could see it getting far too long, and then broke them down into related groups. still some TODO.
Thanks, much less cluttered!
I use cut-and-paste to convert the spaces to tabs just now to clean the source.
yuck. please don't: i use 4-spaces-per-tab where other people will use 8. also, the reason for using spaces is because you can just put your editor into "replace" mode and the formatting remains stable.
please put it back.
Also, on a side note, I put urbit on there because they are unorthodox and because they have an unusually high ratio interest compared to people actually able to contribute, much like you would expect from RISC or KiCAD, but not 'another' replacement for apache.
hmmm, ok, cool. hmm... reminds me, established date should be added.
l.
On 7/16/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
The word "code" in "code of conduct" does usually implies formal membership, so I thought it might be confusing to some people if the phrase became popular in closed circles.
no - it's well-known that "code of conduct" is a dangerous, toxic and highly unethical system of "control" over contributors. *i* didn't know that, so i did a comprehensive analysis here on the list about 6-8 months ago, and emphatically agreed with the assessment.
Ah - I see. I think I see it as more a representation of what moderators will probably do regardless of if said document exists or not. I think it very toxic if they try to hurt project forks that do things differently, but moderators inevitably will try to establish a certain culture within their project and documenting the moderators behaviors will set the right expectations in people.
Inevitably, and especially as the open-source and free software communities grow, there will be project forks based simply on certain people that can't cooperate with each other. I think this kind of conflict can breed a healthy diversity in people, so, if a small group of contributors write up a small "code of conduct" on how they like to be treated, I think that can be healthy depending on the circumstances.
I see it that such a doc could mean "don't talk to me, if you do X" or it could mean "you can't have my code, if you do X". The former is all well and fine, but the later I'd agree is toxic.
I opted to separate it like that to make it more unambiguous, since there are two possible definitions of libre in regard to websites: open-source/free scripts and open-source/free server code.
hmmm.... *thinks*... is the distinction important? don't know. so it should probably go on the list. it might be statistically significant.
so a column "Web site source available / License" and now that i think about it "Documentation source available / License"
should be added
I'm starting to really feel the usefulness of collecting this data :>
yuck. please don't: i use 4-spaces-per-tab where other people will use 8. also, the reason for using spaces is because you can just put your editor into "replace" mode and the formatting remains stable.
please put it back.
I got this error trying to revert the change back "Error: Failed to revert commit 27584a06584f4942b6d24bda08511cedd3f867d3 'git revert --no-commit 27584a06584f4942b6d24bda08511cedd3f867d3' failed: "
Hm, the web editor uses a proportional-pitch font, so it's impossible to tell the number of spaces in a table to get alignment. (didn't realize you could use git to edit it, so I thought you also saw this.)
I'm not in on the spaces v. tabs holy war. lol
On Sun, Jul 16, 2017 at 12:26 PM, Jean Flamelle eaterjolly@gmail.com wrote:
I got this error trying to revert the change back "Error: Failed to revert commit 27584a06584f4942b6d24bda08511cedd3f867d3 'git revert --no-commit 27584a06584f4942b6d24bda08511cedd3f867d3' failed: "
yep you'll need to do it manually: i edited the page in the meantime. sorry.
Hm, the web editor uses a proportional-pitch font, so it's impossible to tell the number of spaces in a table to get alignment.
stuff it into a text editor with a fixed-width font.
On Sun, Jul 16, 2017 at 2:12 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Sun, Jul 16, 2017 at 12:26 PM, Jean Flamelle eaterjolly@gmail.com wrote:
I got this error trying to revert the change back "Error: Failed to revert commit 27584a06584f4942b6d24bda08511cedd3f867d3 'git revert --no-commit 27584a06584f4942b6d24bda08511cedd3f867d3' failed: "
yep you'll need to do it manually: i edited the page in the meantime. sorry.
Hm, the web editor uses a proportional-pitch font, so it's impossible to tell the number of spaces in a table to get alignment.
stuff it into a text editor with a fixed-width font.
... or... get the previous version, work out what i did, go the previous-previous version, restore that (manually) then hand-add what i added...
ah y'know what? sod it - i have access to git: i'll do it :)
l.
On Sun, Jul 16, 2017 at 2:14 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
Hm, the web editor uses a proportional-pitch font, so it's impossible to tell the number of spaces in a table to get alignment.
stuff it into a text editor with a fixed-width font.
... or... get the previous version, work out what i did, go the previous-previous version, restore that (manually) then hand-add what i added...
ah y'know what? sod it - i have access to git: i'll do it :)
done. there's no "war" on tabs/spaces, there's just "one is more appropriate for the circumstances than the other". for c i always use tabs. for python i *always* follow PEP8. it always depends on circumstances.
l.
On Fri, Jul 14, 2017 at 04:36:49PM +0100, Luke Kenneth Casson Leighton wrote:
oh - i forgot one column: IRC channels!
http://rhombus-tech.net/proposed_best_practices/
added.
Should we also add a line and check if the projects have a wiki. Personally I get a ton of information from Debian and Arch wikis and they a good way for collaboration between developers and users.
kind regards Pablo
On Mon, Jul 17, 2017 at 11:26 AM, Pablo Rath pablo@parobalth.org wrote:
On Fri, Jul 14, 2017 at 04:36:49PM +0100, Luke Kenneth Casson Leighton wrote:
oh - i forgot one column: IRC channels!
http://rhombus-tech.net/proposed_best_practices/
added.
Should we also add a line and check if the projects have a wiki. Personally I get a ton of information from Debian and Arch wikis and they a good way for collaboration between developers and users.
good point - "wiki / license"
On Mon, Jun 05, 2017 at 05:47:35PM -0400, John Luke Gibson wrote:
Alrightie~!
Foremost, since "existing" free software and cultural works aren't likely to be sold, I think a libre software standards organization wouldn't certify individual works or pieces of code, so much as projects as a whole including roles performed by non-developers
Version control is almost ubiquitously used for source code, to the point it should hardly need mentioned; however very rarely are non-source project files, such as .blend files, collaboratively designed this way. I don't think people are unwilling to use version control in this way, rather they just don't think of it since most artists aren't developers and art has been digitally designed for much longer than version control systems have been easy to use. So I think uploading files to repository and saving changes as commits, would be a good 'non-developer' "best practice" to apply to a software certification standard.
A lot of file formats, especially those used by artists, are hostile to the essential 'merge' operation in version control.
Even the current real standards for word processors (such as odt) are bad for this.
They use compression, which has an effect like cryptographic hashing on ones efforts to distinguish change from background.
Even the uncompressed .odf word processor format has this problem, being based on xml. If a merge operation sees enough similarity it guesses what the actual changes are. If it guesses wrong the merged file may have its bracket structure severely damaged, requirg manual repair. But users do not interact with their documents at the XML level, so they are completely lost.
Why this isn't a problem with C is that programmers do interact with their code in a textual level, so they ar very familiar with the editing of brackets.
For word processing, I think the only good solution is a document compiler, with the writer editing the source code.
I know of nothing comparable for visual arts.
-- hendrik
On Tue, Jun 6, 2017 at 2:47 PM, Hendrik Boom hendrik@topoi.pooq.com wrote:
For word processing, I think the only good solution is a document compiler, with the writer editing the source code.
I know of nothing comparable for visual arts.
there are two separate concepts here: revision control of non-text-based documents, and the relevance of "art" to science.
the first is a well-known problem, for which things like "yodl", "tex" and other complex-document-formats-from-easy-text-based-generators already exist.
another example: i wrote pyopenscadobj and am the de-facto maintainer of pyopenscad, because you can write python programs which generate SCAD files which in turn generates 3D models.... and the python programs can be checked into git revision control. can you check in .blend or .iges or .step files into git revision control? no you can't because they're a dog's dinner.
for file formats which do *not* lend themselves to this technique, all i really have to say on the subject is: tough titty. find an alternative program and file-format... or just put up with the fact that your git repository becomes nothing more than a file store with zero ability to store or track "differences".
the second, hendrik, you may have misunderstood why "art" was mentioned in the context of science and engineering. we are *not* discussing "traditional artistic subjects" such as painting, sculpting and so on.
we are referring to (as does the hippocratic oath) the application of artistic *principles* to scientific endeavour, which is something that is, admittedly, quite hard to understand let alone actually do.
some examples include: taking "intuitive" decisions in solving engineering problems; applying "creativity"; and other such things. these are *general principles* which are most commonly used in the "arts", and hippocrates was pointing out that when science does *not* apply them then science suffers.
l.
Hendrik:
A lot of file formats, especially those used by artists, are hostile to the essential 'merge' operation in version control.
A lapse on my part. I didn't think of that when I was typing that whole thing up. That makes it quite a bit difficult, as multiple forks can't be merged and one simply has to decide between them, then, if worthwhile, refactor the new version to include the merits of other forks. Okay, maybe not possible for 100+ collaborators xD
On the bright side, it appears to be a problem that's been tackled before for blender: https://blenderartists.org/forum/showthread.php?344037-Addon-Blender-Git-Ver...
It would be interesting if there might be a way to convert blend files to python, since blender has heavy support of its python api.
This problem appears to have been solved for gimp, under the radar: https://sites.google.com/site/httimchen/2011_imagesvn
Luke:
the second, hendrik, you may have misunderstood why "art" was mentioned in the context of science and engineering. we are *not* discussing "traditional artistic subjects" such as painting, sculpting and so on.
we are referring to (as does the hippocratic oath) the application of artistic *principles* to scientific endeavour, which is something that is, admittedly, quite hard to understand let alone actually do.
Naw, one of my tings definitely did mention CVS of art assets somewhere in dat confuddled mess xd
On Tue, Jun 6, 2017 at 4:36 PM, John Luke Gibson eaterjolly@gmail.com wrote:
we are referring to (as does the hippocratic oath) the application of artistic *principles* to scientific endeavour, which is something that is, admittedly, quite hard to understand let alone actually do.
Naw, one of my tings definitely did mention CVS of art assets somewhere in dat confuddled mess xd
that is still completely out-of-scope for the discussion. we are not here to solve the problem of version control for artists or sculptors.
l.
2017-06-06 15:47 GMT+02:00 Hendrik Boom hendrik@topoi.pooq.com:
On Mon, Jun 05, 2017 at 05:47:35PM -0400, John Luke Gibson wrote:
For word processing, I think the only good solution is a document compiler, with the writer editing the source code.
The're is a way for arbitrary documents so work with version control. conversion to an intermediate format like markdown. http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/ https://github.com/vigente/gerardus/wiki/Integrate-git-diffs-with-word-docx-...
It uses pandoc to convert to markdown and then to git.
Found it on hackady http://hackaday.com/2017/05/23/stupid-git-tricks
arm-netbook@lists.phcomp.co.uk
-
Adam Van Ymeren -
Christian Pietsch -
doark＠mail.com -
Hendrik Boom -
Jean Flamelle -
John Luke Gibson
-
Luke Kenneth Casson Leighton -
mike.valk＠gmail.com -
Pablo Rath -
Stefan Monnier -
Tomas Nordin -
Tzafrir Cohen -
zap