DS-5 opinions/reviews

On 4/21/2015 4:45 PM, Don Y wrote:

> The issue is, what sort of (self-imposed!) obligation do I have to
> pick tools that are "affordable" (with no concern for other issues
> that might affect their overall utility/effectiveness)?

In case it's not obvious, this/these are *rhetorical* questions; obviously
*I* have the sole voice in their answer.

OTOH, folks may want to ask themselves similar questions, if they can do
so, "honestly".

Do you insist on free "hammers" (i.e., large rocks are always handy!)?
Or, are you willing to pay for a *real* one?  How much more effective
*is* that "real" hammer to justify the expense?  :>  (you can find rocks
pretty much *anywhere* - even if your "real hammer" is back home in
your toolbox!)

Den onsdag den 22. april 2015 kl. 01.46.19 UTC+2 skrev Don Y:
> On 4/21/2015 7:34 AM, Theo Markettos wrote:
> > Don Y <this@is.not.me.com> wrote:
> >> Then only folks willing to shell out the $1K would be capable of
> >> kernel hacking "out-of-the-box"!  It doesn't seem uncommon for FOSS
> >> projects to "arbitrarily" pick their own tools, build systems, etc.
> >> How is burdening a prospective developer with having to acquire and
> >> install (even if they are "free") a different version of make(1),
> >> a different VC system, testing framework, etc. any different than
> >> saying "shell out $X instead of your *time* if you want to play"?
> >> Haven't they, in effect, said their time and effort is worth
> >> enough that they should pick the tools and approach that *they*
> >> consider the most effective approach to the problem?
> >
> > All the setup problems can be solved in FOSS by throwing them a
> > preconfigured virtual machine.  You can't do that with proprietary software
> > unless you're very sure of the licences.
> >
> > On a lower level, a package manager solves a lot of the same problems -
> > saying 'take Ubuntu xx.xx, type apt-get install libfoo bar2 xbaz and you're
> > ready'.  Doesn't matter if the project uses wierd tools, just add a few more
> > characters to the apt-get line.  Again it's more pain when you have to mess
> > about with downloading from behind paywalls, setting up licence servers, etc
> > etc.
> 
> The issue is, what sort of (self-imposed!) obligation do I have to
> pick tools that are "affordable" (with no concern for other issues
> that might affect their overall utility/effectiveness)?
> 
> E.g., given that, IN REAL TERMS, few folks will ever be tinkering at
> this level (how many Linux kernel hackers are there?  How many userland
> contributors?  How many "simple users"?  Seriously... offer up REAL
> estimates of each of these!)  Is it really worth burdening *my*
> efforts just to make it "inexpensive" for folks who *might* want to
> tinker in the future?
> 
> My hardware designs are all "open" (schematics, films, etc).  But, does that
> mean I have to use FOSS tools to *create* them, as well?  On the off chance
> that someone will want to *modify* a design?  Is it acceptable to produce
> TIFFs (i.e., un-editable) of schematic pages so they don't have to purchase
> those same tools?  Even if that means more effort required for them to
> create an editable document in their tool-of-choice?
> 
> Should I only use thru-hole components for those folks who can't afford the
> tools for SMT work?  (or, should I leave the burden of making a thru-hole
> version in *their* lap:  "here's the schematic, YOU see if you can find this
> SoC in a DIP...")  What about components that are really only available
> (or affordable) in large production quantities?  Does everything have to
> be a PIC or a PC?
> 
> Do I have to create the molds for the various plastic enclosures using
> FOSS CAD tools in case someone wants to add another mounting boss?
> Ditto any sheet-metal work?
> 
> At what point do you say, "the likelihood of someone tinkering with
> this thing is low enough that *they* can afford to bear the costs
> if they choose to do so"?
> 
> I'm not sure how many FOSS projects you've looked "under the hood".
> Why so many different implementation language choices (yet, never
> a clear analysis of why "this is better than that")?  Or, build
> systems (I have more INCOMPATIBLE "makes" here than I can count!)?
> Different file compressors (I've even got cpio archives!)?  Different
> (incompatible) VCS's?
> 
> Is the criteria "as long as a FREE piece of software/hardware can be
> acquired to do the job, then you are at liberty to use whatever you
> want"?  I.e., within those constraints, the initial developer(s)
> are free to choose whatever environment/implementation they want?
> 
> I'm surprised they are willing to pay for the actual *components*
> (chips) and don't insist on those being "free", as well!  :>

Hi Don, 

I think you are over thinking this, you can of course choose what ever 
tools and parts that will get the job done best and most efficiently. but
the choices have consequences, i.e. 

if the barrier to entry it a $1000 compiler, ability to solder BGAs, buying parts in trays of 100's you have very much limited your possible "audience"

anyway it seem like you are mostly interested in the simulation and debugging
stuff that is separate from building and using the code so it may not be an issue at all
 
-Lasse

Hi Lasse,

On 4/22/2015 4:35 AM, lasselangwadtchristensen@gmail.com wrote:

> I think you are over thinking this, you can of course choose what ever
> tools and parts that will get the job done best and most efficiently. but
> the choices have consequences, i.e.
>
> if the barrier to entry it a $1000 compiler, ability to solder BGAs, buying parts in trays of 100's you have very much limited your possible "audience"
>
> anyway it seem like you are mostly interested in the simulation and debugging
> stuff that is separate from building and using the code so it may not be an issue at all

Replying off-list.  Watch your mail.

--don