Transfer functions

Matlab started as a more convenient way to access Lapack. They added their own programming language. Now, Matlab offers much more than Lapack. But if Lapack is all you need, then several programming languages (including Python) offer convenient access to Lapack. If you want more, there are several other numerical libraries integrated into various programming languages. So it really depends on what you want to do.

<snip>

Expecting no bugs is unrealistic, FOSS or no FOSS. What I see is that closed source programs do not talk about their bugs. Maybe they have less bugs, but small and unrepresentative sample that I have suggest that the opposite is true. If you are important customer, then chance that vendor of a closed source program fixes bug affecting you may be higher than with FOSS.

Bill Sloman snipped-for-privacy@ieee.org wrote:

I do not know what is contained in Williams and Taylor's book. But you should recalibrate your opinion of what computers can do. Basically, most content of many clasical reference books either can be recalculated on demand or is contained in tables inside modern programs. About 100 pages in Watson book about Bessel functions gives numeric values, that can be easily recalculated now. Notrivial part of Abramowitz and Stegun gives numeric data which can now be recomputed on demand. Similarly, elements values of classic filters can be easily recalculated (and programs can now compute filters going way beyond tables in classic books). At higher level, computers can manipulate formulas. For indefinite integrals there is an algorithms which can handle things beyond what humans can do and beyond what could reasonably fit in a book. Computing definite integrals is less regular, but for example Mathematica claim to be "Gradstein-Ryzik complete", that is clam to be able to do all definite integrals appearing in well known collection by Gradstein and Ryzik. Laplace transforms are closely related to definite integrals, so I would expect similar thing. More generally, single refenece book normally will have content equivalent to few megabytes, so there is no fundemental obstacle to include inside a program content of tens of reference books. And computer can transform formulas, so there is no need to store various derived formuls (which usually take most place in reference books), storing fundamental ones is enough.

Concerning transfer functions, transfer function of a linear system can be computed by linear algebra. With specified element values (and you need to do this using Spice-like programs) one can easiliy get floating point answers for circuits with thousends of elements. If you want exact answer, that should work for hundreds of elements. With symbolic (unspecified) element values computations get harder but you still should be able to do circuits with tens of elements.

There is a lot of programs that can do needed linear algebra. The hard part is to get data out of LTSpice files. Older Spice versions used format that is essentially a netlist and which is easy to parse from any programming language. I have not seen description of LTSpice format (is it trade secret??), but apparently netlist must be build from geometric information about element placement. Which seem to need information about exact shape of elements in LTSpice library (at least ones used in given circuit). I suspect that decoding information from a .pdf schemantics may be easier, as in this case shapes of elements are represented in the picture.

It's not difficult to get LTspice to produce a netlist. There's an "Export Netlist" item in the "Tools" menu of the schematic editor. The format is clumsy though. I prefer the format of "View"->"SPICE Netlist". (Still no good for regular human consumption, but I sometimes use it to debug unexpected behaviour of schematics features.)

Jeroen Belleman

MatLAB now has a shitload more "support packs" tailored to different application domains. I use an off-the-shelf (COTS or FOSS) product if it addresses a need -- regardless of price. (it's really easy to piss away a few kilobucks of time playing with something that doesn't work). But, I want to have confidence that its a finished *product* and not a work-in-progress (looking for alpha testers).

If something is high value to me, then I invest in it -- time or money.

It's not an issue of bugs vs no bugs but whether or not the bug that is eating YOUR lunch will be addressed, and when. YOU have identified it (so it's not something that is still hiding) and, presumably, can tickle it at will. Does that generate any action towards fixing it?

[I was working with a toolchain a few decades back. I had a great rapport with the developers. They'd post a binary for *me* at close of business -- and I'd have identified bugs by start of business, next day ("Christ! Doesn't he *ever* sleep??") But, we both ended up pleased with the outcome as they got a better product and I got the product that I needed]

FOSS "volunteers" tend to be more interested in adding new features instead of making sure the existing features actually work as intended. Users are the *alpha* testers.

I recall testing a port of gnuplot -- one of the few packages that is distributed with a test suite (make test). It failed. Did the volunteer who built that version neglect running the test suite before distributing the built binary? Rather, he likely didn't understand what the various functions were supposed to "look like" (plotted) and was just checking that it never SIGSEGV'd. Shouldn't you at least understand what the software you are working on *does*??

They don't have to talk about them. If they *address* them, then there is no need to talk about bugs that have already been fixed.

My experience has been that I can talk to someone with the ability to fix a bug and get it addressed -- often by being a capable and willing tester for THAT bug... if it is acted on while my interest is still there. Contrast that with submitting a PR and "moving on"... what hope does the FOSS volunteer who is monitoring the PRs have of engaging you at a later date?

I just found a bug in KODI a week ago. Still no official comment on it, despite documenting how to reproduce FROM A CLEAN INSTALL! When/if *it* is addressed, I will document the *bigger* bug that I found (if there's no effort towards addressing the first, then why expect them to address the second? instead, ditch KODI and run VLC on a box.

If you want to use free software look at slicap, it's built on top of symbolic python, kicad and ngspice. You can generate root locus plots from it which is what I assume you want.

If you want to program the symbolic manipulations yourself I'd look at sagemath which is built on smpy and maxima.

IME usually yes. Bug may be hard to fix and you may get info to this effect. Sometimes there is no reaction, but is it any better than "thanks for your report" that some people got from commercial vendors?

Well, my experience on both sides was that developers, especially volunteers were interested in fixing bugs. There may be problem with paid developers who where supposed to implement specific new thing and do not want to do unrelated work. There may be problem when person who developed given part is gone and nobody else is familiar with this part.

The last problem is not specific to open source, closed source vendor may loose developers for various reasons.

Concerning users being testers: AFAIK this is common practice both for closed source software and open source. IMO it is OK as long as it is honest, that I users are told if they are getting an experimental version or a tested one. And if you ask "who wants to use experimental version?", then answer is that a lot of folks wants to try new experimental features.

IME serious open source projects have testsuites. But above you touch a real problem. Namely, when software performs computations, then it is usually quite easy to check that result agree with previously computed answer. For interactive text based programs there are reasonable tools to help with testing. But for graphics and especially GUI I am not aware of good open source tools and at least testing that I do is manual.

In case above it is hard to tell what really happended. I have seen cases where packagers basicaly blindly copied build recipe from other package, without noting that package required special handling. In cases I mention build failed, so users were spared potential problem, but I can imagine that person build the package made a mistake or at least did not look at generated images. Much of build/test ifrastucture is automated so it is possible that the package worked when initially created, but got broken later and automated tests missed this.

That would be OK if they fixed _all_ reported bugs. I personally now use 100% open source, but I heard from users of closed source programs about bugs that remain unfixed for long time.

When I used closed source software it was frequently not clear how to contact somebody competent at the vendor. And the best thing user could hope was "it will be fixed in the next release" (and of course user wanting the fix would have to pay for the next release).

With open source sometimes I got very fast response, sometimes it was slower. Sometimes it was almost no reaction. I remember that in one case I got email saying that bug that I reported few years earlier got fixed. In several case I simply fixed problem myself. I would say that on average it was better than with closed source software.

Can not say anything about KODI. But let me remark that reproducing bug may be a problem (probably not in your case, but who knows). Normally I would expect some notification in bug tracker confirming that bug can be reproduced. If reproducing bug _requires_ clean install, that may slow down things.

Now, concerning second bug, if report requires nontrivial effort or without fix for the first bug you can not use the program, then waiting with reporting second bug makes some sense. But how fast things are handled may be quite random. And there is tendency to address what looks like serious bug first (of course, your idea of serious bug may be different than KODI developers idea of serious bug). So it makes sense to report both.

Over the years, I've had excellent "paid support"! I recall buying a copy of Autodesk's AME 1 (!). A week later, I brought a sample drawing to my VAR, simplified to make the "problem" very obvious (I was perforating a sheet of steel). I had an update shipped to me overnight (software being sold on floppy disks, back then).

I've already mentioned the relationships I've had with toolchain vendors -- but, they tend to have fewer customers so "getting personal" is relatively easy. Even a bug in a MS compiler got me an immediate update (of course, the fact that I could dictate 10 lines of code to the support person to illustrate the issue likely worked to expedite that!)

It's marginally OK for users to be *beta* testers. But, I expect the developer -- any developer -- to have at least done alpha testing on it before releasing it.

For a commercial vendor, people can express "monetary outrage". For FOSS, they can just look for another option, as there is no leverage the "customer" has over the developer -- short of assuming maintenance yourself.

I guess I've always had to *produce* a product, not play with a tool that doesn't help me get to that goal.

A lot of FOSS users are just "penny-pinching hobbyists" who want to tinker (fine!). If a "program" doesn't work, they just stop using it. You don't have that luxury when you select a tool to "do real work".

LOOKING at the plots would have told the developer that something wasn't right. In this case, a CDF that didn't monotonically approach '1'.

If the developer isn't familiar with ow the tool is likely being used IN ITS ENTIRETY of function, then he's not qualified to be signing off on it.

Too much FOSS fails to build without warnings/errors. So, you leave it to the volunteer to decide what needs to be investigated, what needs to be *patched* (to silence a warning) and what needs to be *fixed*.

You don't need a warm body to build a tool; scripts can do so "automatically". The warm body is supposed to be looking at the build and UNDERSTANDING whether it is progressing as intended, or not.

I gave up using binary packages simply because there is no real quality control there. When you have tens of thousands of such packages, its too much effort for a limited crew of volunteers to do "well". So, I build everything from source and patch to ensure the "port" (pkgsrc-speak) is correct.

Like the 15 years cited in the COREUTILS example I posted? Note: coreutils isn't some obscure piece of code that few encounter!

I've always cultivated close relationships with my vendors. When they realize that you're not calling and asking stupid questions, that you HAVE read the documentation and that you've INVESTED time in reducing the problem to a small, focused example, it behooves them to cultivate YOU as a contact. YOU offer them an expedited path to resolving problems with THEIR product. The assumption being that they WANT to improve their product.

With FOSS, you're usually interacting with some N-th generation developer, far removed from the original author(s) of the tool. And, they are trying to squeeze in their efforts between their

*paid* responsibilities -- with just gratitude and their own personal sense of accomplishment as motivators. [I was active in the FOSS scene for much of the 90's. The effort required to "make a difference" is significant.]

I only rely on gcc/clang and PostgreSQL in terms of "supported" FOSS. Anything else that I use, I maintain my own local repository. I no longer feed patches/fixes/enhancements back upstream as it lets me take the tools that I use in whatever direction *I* want, without having to wonder if someone decides they are "appropriate".

And, it saves a lot of time as I can just checkout, patch and checkin.

Trying to reproduce a bug in a configurable product WITHOUT relying on a clean install would be a nightmare. What was the configuration in effect at the time of the bug's manifestation? Does option X influence it? What about Y? What about X *and* Y?

From a clean install, you know that there is nothing other than the hardware that can vary from "my" instance to "yours".

Second bug doesn't manifest after clean install (actually, a THIRD bug does!). So, getting to a *shared* clean install that we can both reproduce means that I can incrementally experiment with the configuration until I have caused the second bug to manifest, return to a clean install and then *script* the steps that I will now take to get to that REPEATABLE failed state. How do I know that "enabling X, then Y, then Z, then DISABLING X" is the same as "enabling Y, then Z"? A good bug report tells someone exactly how

*you* can RELIABLY reproduce the bug. So, if they can NOT, then you have to examine the differences (hardware) that are causing your experience to differ from theirs.

A PR that just says "X is broken" represents too high of a bar for a developer to want to undertake.

OTOH, the 10 lines of code to MS got an immediate review! Or, the perforated sheet of steel for Autodesk.

If I want prompt/good service/support, then it behooves me to put in an effort to facilitate that support!

Good for you.

Terms like alpha or beta are meaninless without definition. My personal standard is that code commited to repository should pass all automatic tests. Possibly if I consider change to be dangerous or hard to test in automatic way I may do extra tests. For relase I normally run some long running tests that are take too much time to run before each commit. And there is bug fix only stabilization period.

Do this catches all bugs? No. Could this be improved? Almost certainly. But any improvement takes time and devoting more time to tests brings diminishing returns.

That may be more subtle (as in your example): do the work without using a tool or do the work using potentially buggy tool.

You also seem to ignore people like security researchers and open source integrators, for whom playing and tinkering is part of (usually payed) job.

If that was numeric value, then is should be caught by normal tests.

Well, Linux distro have scripts that can take a release tarball and create a package from it. But sometimes creating a package needs some thinking.

AFAIK at package level there is verification that package builds and that it successfully runs its automatic tests. The first part gives very weak assurance, the second depends on quality of upstream source and its tests.

Given a bug report packagers usually forward it to upstream project, sometimes bug is due to packaging, then they handle it themselves.

When there are reported bugs and upstream does not fix them, then package gets dropped.

For me binary packages usually work OK. I build from source when needed: program not in distribution, I want a newer/older version, I need custom change. Plain bugs are rarely a problem. In one case my experience was that packaged version after upgrades led to binary inconsistences, (re)building from source ensured that binaries worked.

AFAICS those were freshly discoverd bugs. Unknown bugs may be fixed as a byproduct of developement, but that is rare. Usualy bug must be discoverd before it is fixed.

I keep private versions of some things, but that is usually because source is abandoned. In one case developers took program in direction that is inconvenient to me, so I use private version.

Most of the time contributing back is in my best interest, as in exchange I get other fixes and improvements.

You do not know what matters, so it is right that you report detalis. Developer of a program usually have some idea about possible problems, and if something looks like "general bug", they probably will try in their developement version, which may allow quick confirmation and possibly fix. OTOH if the problem depends on details, before doing anything else with the bug developers may be forced to reproduce enough of your environment and that may take time. For example, I work on Debian Linux. If there is bug happening only on Free BSD, then it would take me nontrivial time to setup developement environment on Free BSD.

sure

No, it's good for the vendor. How many people are going to undertake using a tool TO DO REAL WORK if the tool:

- doesn't work as advertised

- isn't repaired promptly Those that will tolerate this may find themselves using a tool which the vendor has abandoned or left the business -- because other customers moved off to other competing products.

You *want* your product to be "as good as possible" lest someone else make something that *is* as good as possible and steals your market. E.g., dBase was a great product, for its time. But, it was tedious to use and, as a result, other people "stole" its users away by offering "friendlier" products that perform the same function.

It's not like using a word processor that gets the hyphenation wrong on some words; you can work around that. If I want to build a 3D-model that uses a piece of perforated steel and the "perforate" operation doesn't work, what alternatives do I have? Paint black circles on it and attach a note: "Imagine these as being HOLES"? How do I do a rendering if those "imaginary holes" don't allow rays to be traced through them?

What do I do if a compiler won't let me take a pointer to a member function? What's the work-around? How much does it clutter up the code while I wait for a future version to

*hopefully* address that issue? Will I be disciplined enough to back-out all of those work-arounds when that is available? Wouldn't it be easier to adopt a tool that doesn't have this problem? [Moral: do not adopt vendor specific extensions as they tie you to that vendor's tool(s)!]

They are relatively traditionally defined:

"Alpha testing is the first phase of formal testing, during which the software is tested INTERNALLY using white-box techniques. Beta testing is the next phase, in which the software is tested by a larger group of users, typically OUTSIDE THE ORGANIZATION THAT DEVELOPED IT."

(emphasis mine)

That assumes you HAVE a formal test suite (and that you can automate it). Again, look at the TENS of thousands of FOSS offerings out there... many don't even make use of invariants, let alone formal test suites. So, how do you know that a "new version" hasn't introduced (or, worse, REintroduced!) a bug that the earlier version didn't have?

This is one of the big wins of having relationships with developers; you get a version that *just* fixes your bug, "now", so you can avoid any other new bugs that they have introduced in the "new and improved" version.

[I left MS's tools after the aforementioned "10 lines of code" bug exemplar. Sure, they verified my report. And, verified that the *new* version didn't suffer from THIS bug -- and, got me a copy of that version. But, now I was back to square one in my assessment of the tool -- sure, THAT bug has been fixed but what other things that I *thought* were working correctly have been broken or altered in the process??]

You can argue that any time spent more carefully *designing* the code brings diminishing returns!

I spend 40% of my time defining what I'm going to build. Then,

20% of my time actually building it. The balance -- 40% -- to verify that what I *actually* built meets the stated objectives.

This, regardless of whether I am designing hardware, software or a system.

You decide where your value lies. You can buy a shovel and spend a day digging a trench to lay some pipe. Or, a few hours to have a Ditch Witch do the work for you. The former costs time; the latter, money. This, assuming both are of equal quality.

Their "product" is the critique of their target. If everything "just worked", they'd be out of a job, right?

The test suite depends on the person performing the test

*recognizing* the PLOTS that it is producing. That's why the test pauses ("press any key") after each plot.

E.g., one of the "tests" plots a wireframe of the Earth; then, again, using hidden line removal; then, again, using a cylindrical coordinate system. Another shows a *whale* "tumbling". Bessel functions, bar charts, a color wheel, numerous PDFs, CDFs, etc.

Is it possible to fully automate the tests to remove the reliance on the human operator to *recognize* the correctness of the rendering (as well as serving as examples to illustrate how to use the tool)? Possibly. But, I am much happier knowing that there ARE tests, even if they rely on humans for validation -- if the alternative would have been NO tests! (which is the more common case for FOSS)

As does pkgsrc. But, you have to decide how much of a "stickler" you want to be about how the build MUST proceed in order to be considered a success.

Ensure no warnings? Shift/reduce conflicts? etc. The role of the developer ("porter", in this case) is to use his good judgement to decide which of these things can be safely ignored (for a particular target platform) and which MUST be fixed (because they have insidious consequences even if they appear not to be significant).

If the "porter" is just hoping for a "successful" (no errors thrown) compile, then the results are dubious. The version of gnuplot I mentioned built with that level of "success" -- despite having a fatal flaw that affected only some of its outputs. But, anyone installing that version and neglecting to run the test suite -- or, not UNDERSTANDING the test suite -- would have a product that was clearly *demonstrating* itself to be defective!

Moral of story: build from sources so YOU can determine if the build is a "success". (I've not even begun to harp on verifying the accuracy of any documentation that you'll install alongside the tool!)

The "porters" aren't expected to ensure the package is correct. They are just tasked with building it (remember? users as alpha testers). I had this exact conversation as I was porting some tools and wanted to know what was expected of my end result. (essentially, nothing!)

That depends on the severity of the "bug". Usually, I see packages/ports dropped when there is no sign of continued demand for it or it relies on something (often hardware) that is no longer readily available.

But, just because something is still in the repository, doesn't mean it will even *build* under -current. Hence the need for "porters" to keep chasing the dog's tail.

I only install tools that I need and will use. Just because there are 30,000 packages, doesn't mean I want or need even a tiny fraction of those!

I always build from source (I have a complete mirror of /distfiles, here, including items that have been elided, over the years). Part of that process is a review of what the documentation

*claims* (initial conditions, default configuration options, etc.) so I can ensure that -- when I revisit the documentation some months later -- I'm not scratching my head wondering why it DOESN'T act as described.

I chase down every warning and either fix it or convince myself that it is harmless. So, thereafter, if the tool doesn't work as expected, I know there is a genuine bug in the implementation.

Because I've had a look through the sources, I have a better feel for what to expect from the tool and what I can *do* with it. E.g., my dhcpd(8) uses ethers(5) and networks(5); why would you want to hardcode any of that stuff in dhcpd.conf(5) when you already have these mechanisms in place? ("Gee, let's create yet another way of solving the same problem...")

And, when something doesn't work, I decide if *I* want to fix it or live with it (just *reporting* it gets me nothing)

They had been present in the codebase for 15 years. Despite all of those *eyes* that were able to examine the codebase. This, because the eyes only look for problems that have manifested and not been worked around. Imagine having a code review and only looking at the parts of the code that have had reported bugs (what value looking at the rest?)

*If* your changes (which may not always be "bug fixes") are adopted. Otherwise, you're still stuck with merging the divergent sources with yours as time goes by.

That is where the purported value of the "porters" lies. More bodies, more (and varied) hosts, etc. But, they aren't expected to produce a working (in the sense that an end user would define "working") tool.

[I have a friend who has a decent collection of machines who just runs build scripts to verify that they *run* on each target; no effort to verify that the results are actually *useful* or usable! But, he has value in that he has physical hardare available!]

I support three development environments for my project -- to "keep me honest" ensuring that the code is "truly" portable and not tied to a particular platform or architecture. It takes a *lot* of effort. And, I am "highly motivated" -- not someone putting in a few hours each week in their "spare time".

By that definition any testing done by users is _not_ alpha testing. So why do you complain about thing which by definition is impossible?

There is a lot of open source project. I think tens of thousands have resonable testsuite.

Well, there is no warranty. But if there are no testsute, then clearly there is question how/if project manages quality. And the conclusion could be "avoid this project".

Small/medium scale open source project normally will only fix bugs in current developement version. Big one may manage separate stable branch(es), but if what you use diverges from one of maintained branches, then you still may have trouble. To get fix for exact version that you use you probably would need paid support contract (which is offered for some projects).

OTOH, if bug fix is reasonably localized, then one can extract corresponding commit from the repository and try to apply patch to earlier version. Some things which to user may look like a simple bug may require substantial rewrite. Rathem mild example of this sort needed 2000 lines of new code

Well, I probably spend larger fraction of time on design, but it varies a lot from case to case. It is hard to separate building from testing, if possible I verify things incrementally so both are intertwined.

Well, it is tricky do better for pictures (long time ago when working on graphics I used a program to count how many pixels differed, low count normally represented floating point noise, large count could indicate trouble).

But part of quality assurance is to make things easily testable, and minimize aspects that need human work. Plots are graphic representation of numeric data. Testing correctness of underlying data would significantly limit parts that need manual testing. And AFAICS in this case bug was in numeric part so should be caught by automatic testing of numeric part.

So basicaly this bug was due to inefficient approach to testing.

Badly organized projects almost surely are majority of all projects. But they should not be majority of what you try. I do not keep statistics, but for projects that I tried ones without tests seem to by minority.

IMO that is mainly for upstream developer. "porter" needs to do this only if there is actual porting involved, as opposed to strightforward packaging.

As I wrote I am using Debian and my experience is that Debian packages work. I am not saying that there are no bugs, but the only easily visible failures were due to tigthened security, I which case one possibility is to agree that given activity is a risk and should be forbidden or decide that there is no risk and change configuration settings to allow it.

I build a lot of things from source, but my reasons are different than distrust in correct working of Debian packages.

"porters" looks like Free BSD term. AFAIK Debian normally wants a testsuite and packaging machinery have target to run it (you can build without running testsute, but Debian build farm is supposed to run tests). Basicaly, to have package included in official Debian you need to convince Debian folks that it is of sufficient quality and will be reasonably maintained. This process may by unfair and probably is not foolproof, but in effect chance that some random buggy thing will end up as official Debina package is rather low.

I deliberately used plural. Single unfixed bug does not say much. But multiple unfixed bugs may indicate that program is unmaintained or poorly maintained and that is reason to drop it. Of course, there are many aspects.

On my machine I have about 1800 packages. There is something like 600 packages in baze system, the rest is what I installed or dependency of what I wanted. That is few percent of available total, call it tiny fraction if you want.

We are coming back to what I wrote: expecting no bugs is unrealistic so improved technology keep finding new ones. I work on a program that in the past was an expensive commercial product. Well, for long time it was a research project at well funded company, then it was on the market, then company marketing it changed strategy and decided they no longer need such product and decided to release it as open source. Part of program source was distributed with the binary, but customers were not allowed to redistribute it.

AFAIK most unfixed know bugs are from proprietary period, still nontrivial part of newly found bugs is from that period. As an example I could mention short 10 line intensively used routine which contained 2 loosely related bugs. The bugs were discovered at least 20 years and possibly 30 years after they were introduced (there are no version control information from that period). Anyway, in this case being proprietary apparently do not reduce number of bugs. IMO part that was distributed as source code contained less bugs than one distributed only a binary. One possible explantation is that in binary-only part developers wanted to "just get work done" and tolerated ugly workarounds and in general less readible code. In part that were distributed also as source code they cared more about structure and look of code. Let me mention that after program was released as open source there were bugs found by people reading source code. So I would say that more eyes help and even mere potential that unrelated people may look at source is likely to increase quality.

If you want to pick nits, then my statement is "the developer does NO testing before releasing it to the user base". How is that a better interpretation?

Really? Wanna name 100 of them (out of the tens of thousands that are out there, if test suites were commonplace, finding 100 should be a no-brainer -- hint: I build EVERYTHING from source so speak from first-hand experience)

Exactly. If you can't prove (to yourself or others) that you have done what you set out to do, then how can you claim your "product" does *anything*?

Having a personal relationship with the developer(s) means you can get YOUR bug patched. Or, patch it yourself without reliance on it making its way into the regular distribution.

As I said, these are tools that I am actively using to meet *my* goals. So, I need it to work as I expect, NOW -- without breaking (or changing) anything that I've already decided is "working sufficiently" for my needs.

But you're still waiting on -- and relying on -- someone ELSE to "fix" the problem. On *their* schedule/priority, despite the urgency of YOUR need.

I was using a bit of test equipment and had defined a trigger sequence that included: ... delay(1 sec) ... and discovered it NEVER triggered! Because the "delay" function was broken! How do I work around this? How "pressing" would fixing that function be for the developer?

Testing while building only helps to increase your confidence in the work you have done. But, a test that passes "now" may not pass in the final product. So, you can't claim you already tested some aspect of the design until you know how the *rest* of the design might interact with that aspect.

And, if you don't have a formal specification for whatever it is you are designing, you have nothing -- other than your "feel" -- to attest to its compliance with those nonspecified criteria.

If you *know* you will have to formally test, then you invest in developing suitable scaffolding, etc. which pays dividends when you have to REPEAT the testing each time you patch a bug (regression testing). You can't just claim "all I changed was ____ so all I have to retest is ______"

Yet the developers spent far more time creating a test suite than most developers! Hard to complain when someone is doing more of something you want... yet not "enough"?

The host varies for each port. Should the upstream developer have to maintain access to all varieties of hardware and OSs on which his tool might run? Who's going to sign up for that sort of commitment?

So, you have confidence that you can read the man page for a tool and rely completely on that to configure and use the tool, in all cases?

Try looking through the man page for the default configuration. Then, read the sources to see if it agrees -- no contradictions, omissions, deletions, etc.

You need a distinction between a "piece of software" that can run on an OS and a piece of software BUILT to run on that OS. In the BSD world, "ports" are sources and "packages" are BUILT ports. I.e., you *install* a package (and run it immediately) but have to DL a port -- along with all of its dependencies (in port or package form) before you can build/run that tool.

[The pkgsrc system defined build dependencies and run dependencies. E.g., you likely need gcc to build most ports but don't need gcc to RUN those built "packages"]

If a bug doesn't interfere with my use of the tool for the purposes that I want, then I only *care* about that ONE bug. Because its presence is interfering with my using the tool to get *my* work done.

My distfiles mirror is about 1T (sources). There are loads of "programs" that I may or may not decide to use -- either to maintain my systems, here, or to assist in the development of my products.

E.g., I use Adobe Illustrator to draw Bezier curves that represent the idealized "paths" a user would trace out for a particular "gesture" (e.g., a check mark, an hourglass, a spiral, etc.). I then extract the few lines of PostScript from the .AI file and add that to my database of "strokes" from which gestures are built.

I *illustrate* these paths using gnuplot -- because I can coax it to produce a file that I can directly include in the graphical depiction of the composite gesture (without having to support Illustrator).

If gnuplot didn't handle color properly, I wouldn't care as I only need a "background" and "foreground" color to be able to depict the composite gesture path. If gnuplot can't LABEL the graph, I don't care. If it mishandled typefaces, <shrug>. I.e., all I expect from gnuplot is the ability to accurately plot a series of bezier curves in a fixed size field.

If you adopt an attitude of "you EXPECT bugs", then you're just giving yourself (or other developers) a crutch to lean on.

Do you EXPECT the food that is served to you at a restaurant to be poorly prepared? Not what you ordered? Served cold?

Do you EXPECT your mail to be delivered to the wrong address?

It's one thing to tolerate errors/faults. But, once you start EXPECTING them, then there is no reason to AVOID them, is there?

Bugs can exist because they affect features or aspect that aren't commonly used. Or, because there are no effective alternatives to a particular tool! Mathematica handles text poorly so annotating a graph leaves the annotations in the wrong places (e.g., I add annotations in the DTP tool on top of the *imported* graph so I can be assured the text is in the typeface I want and in the correct location).

I could stop using Mathematica. Or, just workaround its shortcomings. Switching to an alternative tool leaves me exposed wrt the issues that *it* might have -- so, stick with the bugs you know instead of hoping for better, elsewhere.

A "recently announced" 9-year-old exploit...