[Info-vax] BASIC compiler in the hobbyist distribution

[David Froble]

Stephen Hoffman wrote:
> On 2015-05-31 15:35:09 +0000, David Froble said:
> 
>> seasoned_geek wrote:
> 
>>> What is severely lacking in the Linux world is professionalism.
> 
> Have you offered to send hardware, or have you worked out the problem 
> and the fix and sent along a pull request?    Or have you forked some of 
> the code and started to maintain it yourself?   Because that's how open 
> source works.  Or how it sometimes doesn't work.
> 
> At least if you're not paying for support from one of the larger 
> providers, or not paying your own folks to deal with the software, as 
> both approaches would potentially provide you with some recourse for 
> problems and issues identified.
> 
> Your configuration looks fairly specialized — old serial devices, old 
> parallel printers — and not something that's using typical hardware, 
> too.  Which means those get less or little testing.
> 
> You're not the first that has had complaints about the difficulty of 
> extracting fixes from free code from unpaid volunteers, either.
> 
> If your production is important enough to warrant it, you can get 
> "four-walls" support contracts from some major vendors.  Those aren't 
> cheap.  But they're available.
> 
>>> All of the little script kiddies actually coding want to put "Added 
>>> feature X to package Y" on their resume and not one of them wants to 
>>> fix bugs with other people's code.
> 
> Sure.  I'm certainly not fond of wading into an unfamiliar software 
> package and fixing bugs either, but sometimes that's part of getting my 
> own work done expeditiously.   Yes, I've sent diffs upstream for most of 
> those cases, too.   Sometimes it means recoding something of mine.   
> Sometimes the more intractable bugs have meant porting some code to a 
> different package or platform.
> 
> As much as I'd sometimes like the era of all IT from International 
> Computer or General Computer or Digital Computer back again — where 
> those folks provide the complete package of custom hardware and bespoke 
> software and one-call-away support services, and with little or no 
> open-source involved — all usually provided at no small cost, of course 
> — well, that world just isn't returning.  That era was also a rather big 
> mess, too.
> 
>>> Even if you can prove beyond a shadow of a doubt the bug is theirs 
>>> they will let the bug report rot in bugzilla while they go off adding 
>>> new stuff, unless they can kick the bug to an up-stream maintainer so 
>>> they get credit for closing it and still avoid doing anything.
> 
> Or a more widely-known ad decade-old version: 
> <http://www.jwz.org/doc/cadt.html>
> 
>> This was a rather funny read.  Mostly because I don't use any of that 
>> *ux shit.  What you write is one of the reasons I don't.
>>
>> Got a solution for you.  Keep those bug reports going.  Increase the 
>> number as much as you can.  Ought to be plenty of room for expansion. 
>> The people getting them will learn who is "bugging" them, and soon 
>> begin to ignore you.  Then you will no longer get back any of those 
>> really stupid replies.
>>
>> :-)
> 
> Can't say my experiences with Unix are similar, but then the Unix 
> platform I most often deal with has decent vendor support.
> 
> Yes, there are stupidities within all of the platforms I deal with, 
> too.  Including OpenVMS.
> 
> Not sure that any of the above is specific to the hardware architecture 
> underneath the particular software, of course.
> 
> As my aunt had posted in her kitchen: "the first complainer is the next 
> meal's cook".  Don't like something?  Fix it.  Or pay for a fix.
> 
> 
> 

I guess I can have some specific opinions about "free" software.  Mostly 
because it isn't from the world I'm used to.

I'm a bit more used to "you keep my mortgage paid up and I'll keep your 
software working".