--- 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.