[Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model

[doark at mail.com]

On Tue, 6 Jun 2017 18:47:48 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> On Tue, Jun 6, 2017 at 1:01 PM, John Luke Gibson <eaterjolly at 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.


> > * 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,  
> 
>  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