On 10/26/2022 3:39 AM, Theo wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 10/26/2022 2:09 AM, Theo wrote:
>>> I don't have a product :-) But really just making a thought experiment
>>> about what would happen if I did have a product - let's say an IoT thingy
>>> (wifi, display, etc) in the <$100 sticker price, initial volumes let's say
>>> hundreds.
>>
>> But, you're only looking at Linux (or, any "fleshy" OS) because you
>> think it will make WiFi, networking, display, etc. "more straight-forward".
>> You don't really care, functionally, if it is "Linux" (i.e., a particular
>> kernel) that makes that happen, do you? As long as the API isn't
>> too bizarre...
>
> The reason people use Linux is for the software stacks.

But that same argument applies to any device (including microcontrollers).
Its why manufacturers develop support libraries and the like -- because
they want to make their products (components) easier to design into a
final product.

Would you care if it was ManufacturerOS instead of Linux -- if it
supported the "mechanisms" that you need? Even if it was "closed"
source? (are you *really* going to do any kernel hacking?)

> It allows you to
> write in a more friendly language, have better libraries for doing
> complicated things, use existing tooling, not have to worry about boring
> housekeeping things like the networking (does your thing support IPv6?
> Linux has for decades, does your homebrew embedded RTOS? What about WPA3?).
> Can you interact securely with whatever cloud service your widget needs to
> do its thing? (especially if that service is not designed specifically for
> talking to low-end widgets)

But you're assuming your product NEEDS those things. I don't have
a filesystem anywhere in my design. Persistent storage is handled
by a database -- because storage often wants to be *structured*, not
a collection of unstructured files that the application has to
parse (and verify) the structure thereof.

Because I don't support the notion of a filesystem, everything
related to that is unnecessary.

Only devices designed to *be* displays HAVE displays. So, why burden
other devices with that overhead/complexity?

Encryption isn't a bolt-on feature but, rather, inherent in all
comms. It doesn't make sense (in my application) to have comms
that aren't encrypted!

OTOH, everything in my world is object-based with fine-grained capabilities
governing the actions that can be invoked on specific objects. So, I can
let you transmit on a serial port but not receive; and someone else
configure that serial port but never access the content passing through
it; and someone else...

(It's likely that your code configures the port in one place but
doesn't need to access the content, there -- so, why should it be
ABLE to do so? Likewise, why should something that is interested
in accessing the content be able to alter the configuration -- likely
"by accident"?)

I don't need to "bolt this onto" some other implementation (and
hope there are no cracks through which an exploit/bug can creep
UNDER that) as it's part of the system's foundation. Because I
have to tolerate foreign code that could actively try to subvert
the security of my design (attempting to do something for which
you don't have a suitable capability traps to the OS -- which,
by default, kills off your process; you're either a malevolent
entity or a bug... in either case, no reason to let you continue
to execute!)

I have no global namespace (a filesystem typically is the namespace
for most products). So, task A doesn't even know that object X exists
(even if the developer of task A is 100.00% sure it does!) and, because
A doesn't have a name for object X, there is no way it can access it.

I.e., I build the mechanisms that are appropriate for my product
and care little about what a "desktop OS" thinks is appropriate.

Yet, I can still build the common libraries that you're used to seeing
ATOP my mechanisms. So, when you pepper your code with diagnostic
"printf()s", they get delivered to an appropriate diagnostic device
*somewhere* in the system -- the location and implementation of which
is not important to your code.

> Essentially you trade off ease of software development for hardware
> complexity. If you're playing in the low volume game, development effort
> and time to market is more important than saving cents on production costs.
> If you're selling by the million the tradeoff is different.

It's not just quantities. What would you do if you developed yet another
"low volume" product -- would you start your quantity count from zero, there?

Also, there may be other factors at play in your market. E.g., we would
sell *12* tablet presses in a year. That's TWELVE (no typos). How sloppy
could we be with our implementation at that production level? Why not use all
OTS assemblies to make life easy?!

Ah, but OTS assemblies are often designed to fit a variety of applications.
Lots of "if (WHATEVER)..." scattered through the codebase as it tries to
configure itself for a specific application.

But, WHATEVER will either be always true or always false (for a given
configuration). Meaning, one branch of the code will NEVER be executed.
In some industries, it wouldn't be allowed to remain in the product
("dead code") -- regardless of how few units you made!

"What's all this filesystem code doing in the kernel? You don't
HAVE a filesystem in your product!"

Ooops!

>> The problem, I see, is ending up with lots of "features" that you
>> don't really need in a given product.
>>
>> Do you *really* need a filesystem -- let alone support for a variety
>> of them (and a structure that facilitates supporting many even if you
>> only use *one*?).
>
> If you want to run <tool> and that needs a filesystem, yes you do. I'm sure
> you could reimplement it to do without, but that takes effort.

That argument can apply to any proposed criteria. The question you
should ask is: "Do you NEED to run <tool> *in* your product? Or,
are you just resorting to creeping featurism and running it because
you *can*?"

You can run bc(1) on a linux box. Should you offer a calculator
utility to the product's users just because you *can* do so?
You can run a web server. Does doing so actually add value -- to
offset the added complexity and opportunity for bugs?

I bought a scanner, recently. I wanted a network connection to transport
the scanned images to a remote host (farther away than a USB cable would
tolerate). It's got more *cruft* in it (TELNET, HTTPd, SSH, etc.) than I
can imagine anyone needing or wanting! A long list of features is also a
long list of likely *bugs*!

[E.g., I can do 1200dpi scans using the USB interface but someone forgot to
add that capability via the network interface! So, the i/f that I most
desire is crippled -- despite all the extra cruft taht they've spent time
developing/maintaining!]

>> Do you really need to be able to support multiple network interfaces
>> with a stack that is designed to allow "equivalent" interfaces to
>> their drivers to slide under it?
>>
>> Once your app is up and running, will the page tables EVER change?
>
> That depends on the app.

As I said, above, "That argument can apply to any proposed criteria."
using that sort of logic, one can argue that you should embelish your
solution with as much cruft as possible -- to cover all bases!

> The point here is to be able to use existing
> software without having to re-engineer it. Once you start re-engineering
> things, that's where your time goes.

You're assuming you won't have to understand any of the things that you
are embracing. Is your product support going to be reliant on linux forums?
When a customer calls with a problem, are you going to have to HOPE someone
takes an interest in understanding your product, its implementation and
the expressed problem?

So, when you've an "upset (not yet "angry") customer, you're going to
cross your fingers and hope for a solution -- because you don't
understand the "component" you are using (are you sure it's configured
properly?)

>>> The ESP32s are nice as they're a simple, cheap, wifi module. If you wanted
>>> to cut costs you could use the bare chip. The Pis aren't: the Zero is a
>>> nice form factor, but you can't buy it in volume. The regular Pis can't
>>> really be mounted on a custom PCB if you don't have a large enclosure. The
>>> Compute Modules are better, but still larger than an ESP32. However you
>>> can't really buy any of them at the moment, and if you could they would be
>>> quite expensive. The Pi2040 is an ok microcontroller but nothing special
>>> (and wifi is an extra chip). Also none of them have any protection from
>>> someone changing or stealing your firmware.
>>
>> That last isn't as easy to guard against as you might think...
>
> Indeed, which is why microcontrollers have various secure boot and encrypted
> firmware support.
>
> (which aren't perfect, but prevent somebody just pulling your flash chip and
> reading it out)

Yes. But, there are often other ways to get at the data.

If you are small enough (and your products don't have high margins that
make them attractive to a cloner), you can likely get away with this -- save
for the individual "hacker" who takes an interest in your particular
device.

[And, of course, said hacker can now disseminate anything he learns
easily in ways that make it easy for folks to stumble onto his efforts
with the help of a search engine]

If your device is simple enough -- and you've not done anything to protect
it "legally" -- then it's easier for someone to just copy the *notion*
and not worry about your specific implementation.

[Ages ago, we manufactured a radar unit for boats. A japanese company came
by wanting to sell our units in asia. We were very accommodating. They
eventually just *copied* the design and we got nothing out of the deal
(save for an initial sale of a dozen units). But, in the copying, they
also made enhancements to our design -- some of which were so obvious,
in hindsight, that we kicked ourselves for not having thought of them
in the original design! I.e., in some ways, their version of OUR
product was better than our own!]

>>> It is interesting in the above article how much the complexity starts to
>>> rise once you start going beyond a single chip solution: BGAs, DDR routing,
>>> numerous power supplies and sequencing, etc.
>>
>> But there's no black magic, there. This is all "common practice", now.
>> If you don't have the skills, you develop them (as the author suggests).
>> Layout tools do a lot of this for you. And, if you are looking at
>> smallish "products", the hairy parts of the design are usually close
>> to the CPU and don't extend far into the field.
>
> Indeed, no black magic, just time and cost. Don't do it if you don't need
> it.

That's true if you look at the effort as a "one off". You wouldn't buy a
logic analyzer if you were only debugging ONE, relatively simple design.
OTOH, the time lost debugging that first design WITHOUT a LA could have
reduced the effective cost of the LA purchased for the *second* design!

I've found it usually pays to make investments in tools, skills, etc.
But, because I've known where I wanted my career to go. So, I knew
that an investment today would pay off in the future by making me better
equipped to tackle a future project (that I may already have planned on!)

OTOH, things that I *know* are one-offs have too high a bar to justify
any long-term commitments/investments.

E.g., I'm making a Rube Goldberg-esque kinematic sculpture in the back
yard. Every piece is hand-made -- because there will only EVER be one
of these. Why invest in castings if I'm going to only use each once?

>> If you want to be in a business (regardless of size), you have to invest
>> in the tools necessary to make that business work. The tools can be
>> physical assets -- or, intellectual skillsets.
>>
>> Only you can identify the likely direction your business (products)
>> will take. So, only you can decide which "tools" are sensible
>> investments.
>
> The thing here is choosing your battles. Spend your time on the things that
> add value to the product. Don't make life needlessly harder when that's not
> necessary. Everything *can* be done, but some things shouldn't *need* to be
> done. If you're in the high-volume game, saving $1m using cheaper parts
> makes sense. If you're in the low-volume game, you might only save $1000
> but spend $10K in time doing so.

But that requires you to know what your PRODUCTS (plural) are likely to be.
Only you can know what your future actions/needs are *likely* to be.

If I wanted to go in the kinematic sculpture business, I'd be approaching
*mine* very differently -- even if it meant mine being more costly and
taking longer to complete (due to all of the "investments" for future
efforts). *My* finished result would likely look more "professional"...
but, it would also look to be just one of N such units!