On 1/8/2022 11:52 AM, Jeroen Belleman wrote:
> On 2022-01-08 19:00, Lasse Langwadt Christensen wrote:
>> lørdag den 8. januar 2022 kl. 18.37.19 UTC+1 skrev Phil Hobbs:
>>> Jeroen Belleman wrote:
>>>> For years, interaction with the internet worked through a
>>>> universal browser. Lately, every service, gadget or whatnot
>>>> wants you to download their special-purpose app. Why??
>>>> What's the deal? It seems like a huge step backwards to me.
>>>>
>>>> Jeroen Belleman
>>> The way they ask for ridiculously broad permissions should be a clue.
>>
>> I think sometimes it is just lazy developers that doesn't bother picking what
>> they actually need
>>
>>> "Why does Walmart need access to my camera, phone, and messages?"
>>>
>>> One guess.
>>
>> if it scans barcodes it need access to the camera, it might need access to
>> messages
>> to read a message with something like a discount coupon
>>
>
> You can trust them to purposely invent ways to make the broad
> permissions seem legitimate, so that they can better spy on you as
> a result.

It is amusing that no one has developed a sandbox that you can interpose
between any/every app and your actual resources. This would allow
the user to see *which* resources are ACTUALLY being accessed as well
as allowing you to "dummy up" some bogus resources to appease/confuse
the app.
"Yeah, my address book has just one contact in it -- and that
happens to be the email address of the app's CEO! Please feel
free to spam him."
(of course, the next app has the email of THAT app's CEO in its place)

I.e. turn every phone into a honeypot.

But, sheeple aren't concerned with these issues. If you bring
them (or "privacy", in general) to their attention, they will shrug
and say "they have nothing to hide" or "no one would be interested
in (pwning) me". Of course, when they get *bit*, they'll never think
that it was their behavior that facilitated that!

Even without letting an app peek into your "other stuff", it already
discloses enough about you as soon as you turn it on

(Yes, the visitor checking out at kiosk #23 is now identified -- from
his charge card -- as John Doe. Prior to reaching the checkout, he
visited the following departments, lingering at the following displays
for these periods of time. We can now correlate length of time
at a particular display with probability of making a purchase of
those displayed items...)

(Yes, the browser with fingerprint 0xFEEDABE was seen visiting
this other site just a few minutes ago. We've seen this pattern,
before, so we know to serve up THIS version of the web page
to better hook them into a purchase than a cold visitor)

On 9/1/22 5:52 am, Jeroen Belleman wrote:
> On 2022-01-08 19:00, Lasse Langwadt Christensen wrote:
>> lørdag den 8. januar 2022 kl. 18.37.19 UTC+1 skrev Phil Hobbs:
>>> Jeroen Belleman wrote:
>>>> For years, interaction with the internet worked through a
>>>> universal browser. Lately, every service, gadget or whatnot
>>>> wants you to download their special-purpose app. Why??
>>>> What's the deal? It seems like a huge step backwards to me.
>>>>
>>>> Jeroen Belleman
>>> The way they ask for ridiculously broad permissions should be a clue.
>>
>> I think sometimes it is just lazy developers that doesn't bother
>> picking what they actually need
>>
>>> "Why does Walmart need access to my camera, phone, and messages?"
>>>
>>> One guess.
>>
>> if it scans barcodes it need access to the camera, it might need
>> access to messages
>> to read a message with something like a discount coupon
>>
>
> You can trust them to purposely invent ways to make the broad
> permissions seem legitimate, so that they can better spy on you as
> a result.

Apps can run continuously in the background too, they don't wait for you
to visit the web page.

On Sat, 08 Jan 2022 14:18:24 +0100, Jeroen Belleman
<jeroen@nospam.please> wrote:

>For years, interaction with the internet worked through a
>universal browser. Lately, every service, gadget or whatnot
>wants you to download their special-purpose app. Why??
>What's the deal? It seems like a huge step backwards to me.
>
>Jeroen Belleman

There's a rhetorical question if ever.

Don Y wrote:
>
> It is amusing that no one has developed a sandbox that you can
> interpose between any/every app and your actual resources. This
> would allow the user to see *which* resources are ACTUALLY being
> accessed as well
> as allowing you to "dummy up" some bogus resources to appease/confuse
> the app.
> "Yeah, my address book has just one contact in it -- and that
> happens to be the email address of the app's CEO! Please feel
> free to spam him."
> (of course, the next app has the email of THAT app's CEO in its place)
>
> I.e. turn every phone into a honeypot.

Google's OS and Apple's OS probably wouldn't allow it. If more people
had Linux phones it could be done, but they cost around $800 which gives
an idea how much Google and Apple make from your phone.

--
Defund the Thought Police
Andiamo Brandon!

On 1/8/2022 9:37 PM, Tom Del Rosso wrote:
> Don Y wrote:
>>
>> It is amusing that no one has developed a sandbox that you can
>> interpose between any/every app and your actual resources. This
>> would allow the user to see *which* resources are ACTUALLY being
>> accessed as well
>> as allowing you to "dummy up" some bogus resources to appease/confuse
>> the app.
>> "Yeah, my address book has just one contact in it -- and that
>> happens to be the email address of the app's CEO! Please feel
>> free to spam him."
>> (of course, the next app has the email of THAT app's CEO in its place)
>>
>> I.e. turn every phone into a honeypot.
>
> Google's OS and Apple's OS probably wouldn't allow it. If more people
> had Linux phones it could be done, but they cost around $800 which gives
> an idea how much Google and Apple make from your phone.

Apple may not allow the app to be distributed via their stores
(not sure if Google has a similar hold on "installables") but,
in theory, such an app could underlay all other apps (if installed
first) and *interpret* their code, as the worst case scenario.

No idea as to the performance hit as I don't use a cell phone and
can't speak to the nature/complexity of the apps hosted thereon
(is there a "render 3D model" app? "perform DRC on PCB" app?)

I support "applets" in my current design but they are intentionally
high-level abstractions that rely on services offered by the underlying
system. One could "hook" each of those services and run an applet
in a sandbox "at processor speed" with very little effort (that
was one of the design goals for the RTOS).

Tom Del Rosso wrote:
> Don Y wrote:
>>
>> It is amusing that no one has developed a sandbox that you can
>> interpose between any/every app and your actual resources. This
>> would allow the user to see *which* resources are ACTUALLY being
>> accessed as well
>> as allowing you to "dummy up" some bogus resources to appease/confuse
>> the app.
>> "Yeah, my address book has just one contact in it -- and that
>> happens to be the email address of the app's CEO! Please feel
>> free to spam him."
>> (of course, the next app has the email of THAT app's CEO in its place)
>>
>> I.e. turn every phone into a honeypot.
>
> Google's OS and Apple's OS probably wouldn't allow it. If more people
> had Linux phones it could be done, but they cost around $800 which gives
> an idea how much Google and Apple make from your phone.
>
>

Nah, you can get a Pinephone for $200.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

In article <src2v1$a58$1@gioia.aioe.org>, jeroen@nospam.please says...
>
> For years, interaction with the internet worked through a
> universal browser. Lately, every service, gadget or whatnot
> wants you to download their special-purpose app. Why??
> What's the deal? It seems like a huge step backwards to me.
>
> Jeroen Belleman

They don't have to tell you what "cookies" they are storing...

On 08/01/2022 13:18, Jeroen Belleman wrote:
> For years, interaction with the internet worked through a
> universal browser. Lately, every service, gadget or whatnot
> wants you to download their special-purpose app. Why??
> What's the deal? It seems like a huge step backwards to me.
>
> Jeroen Belleman

Spyware. Profiling and selling personal data. Just look at the
ridiculous permissions many of them request by default.

I agree it seems to be a retrograde step to have everything as an app
and it clutters up the screen to hell with random icons some of which
only make sense to the dope headed Californian designer on an acid trip.

A bit like with browser cookies most people just click OK without even a
second though about why a supermarket would want access to your photos,
email and phone contacts list, microphone and webcam.

The odd one can be useful like an app for finding the nearest bank
machine which has its compressed database and map data in the phone.
(memory is cheap so some things do work better this way)

Unfortunately in the UK they are closing banks and their machines left,
right and centre so you do have to update it fairly often if you want to
be directed to a still working one as opposed to a blanking plate where
a hole in the wall bank machine and a bank used to be!

Cash has become a lot less common thanks to Covid - everyone prefers
contactless payment these days. Limit for that now raised to £100.

--
Regards,
Martin Brown

On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote:

> It is amusing that no one has developed a sandbox that you can interpose
> between any/every app and your actual resources. This would allow
> the user to see *which* resources are ACTUALLY being accessed as well
> as allowing you to "dummy up" some bogus resources to appease/confuse
> the app.

Yeah, and Java was envisioned (write once, run anywhere...) as
an interface between every app and actual resources.

The three B's kinda ruined that.

Bugs, bloat, business. Can't live with 'em, can't live without 'em.

Bugs buried in a third-party library with no one accepting responsibility
means that software and firmware can become untenable, and unfixable.

Bloat in use of oddball functions means you need versions of firmware, software,
and addons to match some arbitrary list of specifications or the new (or even old) app won't run.
There's no clear listing available, of course....

Business decisions (or outright collapses, or purchases/mergers) take away
infrastructure, so the box can't run. Or, phone-home functions are required
to un-brick the thing, and there's no one home when the checks don't arrive regularly.

On 1/9/2022 12:38 PM, whit3rd wrote:
> On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote:
>
>> It is amusing that no one has developed a sandbox that you can interpose
>> between any/every app and your actual resources. This would allow
>> the user to see *which* resources are ACTUALLY being accessed as well
>> as allowing you to "dummy up" some bogus resources to appease/confuse
>> the app.
>
> Yeah, and Java was envisioned (write once, run anywhere...) as
> an interface between every app and actual resources.
>
> The three B's kinda ruined that.
>
> Bugs, bloat, business. Can't live with 'em, can't live without 'em.
>
> Bugs buried in a third-party library with no one accepting responsibility
> means that software and firmware can become untenable, and unfixable.
>
> Bloat in use of oddball functions means you need versions of firmware, software,
> and addons to match some arbitrary list of specifications or the new (or even old) app won't run.
> There's no clear listing available, of course....
>
> Business decisions (or outright collapses, or purchases/mergers) take away
> infrastructure, so the box can't run. Or, phone-home functions are required
> to un-brick the thing, and there's no one home when the checks don't arrive regularly.

All of these are "survivable" *if* you have control over the design.
The ENTIRE design.

For a business, that means owning source licenses to all hardware and
software.

Sadly, for a *consumer* (| user), it means the same thing! Because having
all of that reside in the arms of a vendor does YOU no good if the vendor
decides not to support it any longer.

[I think anyone who buys a "smart appliance" is begging to be screwed-over
in the future. How long does a vendor support a "smart TV"? Do the codecs
keep being upgraded/repaired? Or, does the vendor move on to developing
Model N+1 with the newer codecs and leaving the older model(s) to languish?
(i.e., treat your TV as a DUMB *monitor* and move all of the smarts *out* of
it and into an appliance that YOU can control)]

Gotta wonder about these smart refrigerators, thermostats, "Alexa", etc. How
much of the functionality is *in* the device and how much relies upon some
other service? (when that service goes away, you've got a dumb little box that
can't even be repurposed to fill its original role!)

[Of course, the vendor can rationalize moving the smarts out of the device
and into a service as a means of driving the per unit cost down AND
facilitating improvements to the service without "push updates". And,
you're just *renting* the device, after all...]

On Saturday, January 8, 2022 at 5:37:19 PM UTC, Phil Hobbs wrote:
> Jeroen Belleman wrote:
> > For years, interaction with the internet worked through a
> > universal browser. Lately, every service, gadget or whatnot
> > wants you to download their special-purpose app. Why??
> > What's the deal? It seems like a huge step backwards to me.
> >
> > Jeroen Belleman
> The way they ask for ridiculously broad permissions should be a clue.
>
> "Why does Walmart need access to my camera, phone, and messages?"
>
> One guess.
>
> Cheers
>
> Phil Hobbs
>
> --
> Dr Philip C D Hobbs
> Principal Consultant
> ElectroOptical Innovations LLC / Hobbs ElectroOptics
> Optics, Electro-optics, Photonics, Analog Electronics
> Briarcliff Manor NY 10510
>
> http://electrooptical.net
> http://hobbs-eo.com

One reason could be, sloppy programming.

Developers use old past-practices or
carry-overed modules, and would rather assume
they "need it" to get the product working &
out the door, rather than stop, consider the user's
privacy & security concerns.

my organization has a a digital lab division,
working on these consumer issues. They
released a "Digital Standard" document, which
we are rolling out as way to evaluate connected
products. WiFi routers, TVs, apps, etc.

Printers, for example, largely the situation
I describe above.

cheers, RS

Phil Hobbs wrote:
> Tom Del Rosso wrote:
>>
>> Google's OS and Apple's OS probably wouldn't allow it. If more people
>> had Linux phones it could be done, but they cost around $800 which
>> gives an idea how much Google and Apple make from your phone.
>>
>>
>
> Nah, you can get a Pinephone for $200.

Wow. I only looked at the high end with switches to power off
components.

--
Defund the Thought Police
Andiamo Brandon!

On 1/9/2022 22:27, Don Y wrote:
> On 1/9/2022 12:38 PM, whit3rd wrote:
>> On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote:
>>
>>> It is amusing that no one has developed a sandbox that you can interpose
>>> between any/every app and your actual resources. This would allow
>>> the user to see *which* resources are ACTUALLY being accessed as well
>>> as allowing you to "dummy up" some bogus resources to appease/confuse
>>> the app.
>>
>> Yeah, and Java was envisioned (write once, run anywhere...) as
>> an interface between every app and actual resources.
>>
>> The three B's kinda ruined that.
>>
>> Bugs, bloat, business.   Can't live with 'em, can't live without 'em.
>>
>> Bugs buried in a third-party library with no one accepting responsibility
>> means that software and firmware can become untenable, and unfixable.
>>
>> Bloat in use of oddball functions means you need versions of firmware,
>> software,
>> and addons to match some arbitrary list of specifications or the new
>> (or even old) app won't run.
>> There's no clear listing available, of course....
>>
>> Business decisions (or outright collapses, or purchases/mergers) take
>> away
>> infrastructure, so the box can't run.   Or, phone-home functions are
>> required
>> to un-brick the thing, and there's no one home when the checks don't
>> arrive regularly.
>
> All of these are "survivable" *if* you have control over the design.
> The ENTIRE design.
>
> For a business, that means owning source licenses to all hardware and
> software.

But this is not realistic unless you are the galaxy emperor... We do not
depend on anyone for software, so what. Cut us the silicon and we are
dead.

>
> Sadly, for a *consumer* (| user), it means the same thing!  Because having
> all of that reside in the arms of a vendor does YOU no good if the vendor
> decides not to support it any longer.
>
> [I think anyone who buys a "smart appliance" is begging to be screwed-over
> in the future.  How long does a vendor support a "smart TV"?  Do the codecs
> keep being upgraded/repaired?  Or, does the vendor move on to developing
> Model N+1 with the newer codecs and leaving the older model(s) to languish?
> (i.e., treat your TV as a DUMB *monitor* and move all of the smarts
> *out* of
> it and into an appliance that YOU can control)]
>
> Gotta wonder about these smart refrigerators, thermostats, "Alexa",
> etc.  How
> much of the functionality is *in* the device and how much relies upon some
> other service?  (when that service goes away, you've got a dumb little
> box that
> can't even be repurposed to fill its original role!)
>
> [Of course, the vendor can rationalize moving the smarts out of the device
> and into a service as a means of driving the per unit cost down AND
> facilitating improvements to the service without "push updates".  And,
> you're just *renting* the device, after all...]

They are all going this way as far as they can manage it of course.
Design software people use (not us, we have our own) is nowadays
based on yearly subscriptions, so is office etc. Exceptions/ways
through it still exist I guess but for how long.
The picture is turning pretty dystopian and all we can do is
just live the rest of our lives the best we can, I don't think we
can do much to avoid a catastrophe.
Let's take it as easy as we can - while it lasts :-).

On 1/9/2022 2:57 PM, Dimiter_Popoff wrote:
> On 1/9/2022 22:27, Don Y wrote:
>> On 1/9/2022 12:38 PM, whit3rd wrote:
>>> On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote:
>>>
>>>> It is amusing that no one has developed a sandbox that you can interpose
>>>> between any/every app and your actual resources. This would allow
>>>> the user to see *which* resources are ACTUALLY being accessed as well
>>>> as allowing you to "dummy up" some bogus resources to appease/confuse
>>>> the app.
>>>
>>> Yeah, and Java was envisioned (write once, run anywhere...) as
>>> an interface between every app and actual resources.
>>>
>>> The three B's kinda ruined that.
>>>
>>> Bugs, bloat, business. Can't live with 'em, can't live without 'em.
>>>
>>> Bugs buried in a third-party library with no one accepting responsibility
>>> means that software and firmware can become untenable, and unfixable.
>>>
>>> Bloat in use of oddball functions means you need versions of firmware,
>>> software,
>>> and addons to match some arbitrary list of specifications or the new (or
>>> even old) app won't run.
>>> There's no clear listing available, of course....
>>>
>>> Business decisions (or outright collapses, or purchases/mergers) take away
>>> infrastructure, so the box can't run. Or, phone-home functions are required
>>> to un-brick the thing, and there's no one home when the checks don't arrive
>>> regularly.
>>
>> All of these are "survivable" *if* you have control over the design.
>> The ENTIRE design.
>>
>> For a business, that means owning source licenses to all hardware and
>> software.
>
> But this is not realistic unless you are the galaxy emperor... We do not
> depend on anyone for software, so what. Cut us the silicon and we are
> dead.

You can always find another source for silicon. If the design is locked
up behind closed doors, NDAs, <whatever>, then having all the silicon
in the world won't help you if the vendor stops selling the item that
you need.

We designed a $300K device that relied on a $5K software license.
Vendor stopped issuing licenses. What recourse did we have? It's
not that the "item" disappeared from the face of the Earth... just
was no longer available for our LEGAL use.

We either stop selling our existing product *or* redesign it to
use some other replacement for that licensed component. Of course,
vendor would love to sell us some NEW component to take its place.
But, would we want to open ourselves up to his intransigence on
a *future* decision to stop selling THAT license?

>> Sadly, for a *consumer* (| user), it means the same thing! Because having
>> all of that reside in the arms of a vendor does YOU no good if the vendor
>> decides not to support it any longer.
>>
>> [I think anyone who buys a "smart appliance" is begging to be screwed-over
>> in the future. How long does a vendor support a "smart TV"? Do the codecs
>> keep being upgraded/repaired? Or, does the vendor move on to developing
>> Model N+1 with the newer codecs and leaving the older model(s) to languish?
>> (i.e., treat your TV as a DUMB *monitor* and move all of the smarts *out* of
>> it and into an appliance that YOU can control)]
>>
>> Gotta wonder about these smart refrigerators, thermostats, "Alexa", etc. How
>> much of the functionality is *in* the device and how much relies upon some
>> other service? (when that service goes away, you've got a dumb little box that
>> can't even be repurposed to fill its original role!)
>>
>> [Of course, the vendor can rationalize moving the smarts out of the device
>> and into a service as a means of driving the per unit cost down AND
>> facilitating improvements to the service without "push updates". And,
>> you're just *renting* the device, after all...]
>
> They are all going this way as far as they can manage it of course.
> Design software people use (not us, we have our own) is nowadays
> based on yearly subscriptions, so is office etc. Exceptions/ways
> through it still exist I guess but for how long.

You stick with what you already have/had -- insofar as it is able
to meet your ongoing needs.

Or, embrace more "open" offerings... often with the need to make some
commitment (time or money) to ensuring their continued availability,
development, etc.

(Too often, folks buy into FOSS for $0 -- thinking it "free" and not
realizing that it can go away just as easily, without support, as
any other offering!)

> The picture is turning pretty dystopian and all we can do is
> just live the rest of our lives the best we can, I don't think we
> can do much to avoid a catastrophe.
> Let's take it as easy as we can - while it lasts :-).

On 1/10/2022 0:06, Don Y wrote:
> On 1/9/2022 2:57 PM, Dimiter_Popoff wrote:
>> On 1/9/2022 22:27, Don Y wrote:
>>> On 1/9/2022 12:38 PM, whit3rd wrote:
>>>> On Saturday, January 8, 2022 at 3:17:20 PM UTC-8, Don Y wrote:
>>>>
>>>>> It is amusing that no one has developed a sandbox that you can
>>>>> interpose
>>>>> between any/every app and your actual resources. This would allow
>>>>> the user to see *which* resources are ACTUALLY being accessed as well
>>>>> as allowing you to "dummy up" some bogus resources to appease/confuse
>>>>> the app.
>>>>
>>>> Yeah, and Java was envisioned (write once, run anywhere...) as
>>>> an interface between every app and actual resources.
>>>>
>>>> The three B's kinda ruined that.
>>>>
>>>> Bugs, bloat, business.   Can't live with 'em, can't live without 'em.
>>>>
>>>> Bugs buried in a third-party library with no one accepting
>>>> responsibility
>>>> means that software and firmware can become untenable, and unfixable.
>>>>
>>>> Bloat in use of oddball functions means you need versions of
>>>> firmware, software,
>>>> and addons to match some arbitrary list of specifications or the new
>>>> (or even old) app won't run.
>>>> There's no clear listing available, of course....
>>>>
>>>> Business decisions (or outright collapses, or purchases/mergers)
>>>> take away
>>>> infrastructure, so the box can't run.   Or, phone-home functions are
>>>> required
>>>> to un-brick the thing, and there's no one home when the checks don't
>>>> arrive regularly.
>>>
>>> All of these are "survivable" *if* you have control over the design.
>>> The ENTIRE design.
>>>
>>> For a business, that means owning source licenses to all hardware and
>>> software.
>>
>> But this is not realistic unless you are the galaxy emperor... We do not
>> depend on anyone for software, so what. Cut us the silicon and we are
>> dead.
>
> You can always find another source for silicon.  If the design is locked
> up behind closed doors, NDAs, <whatever>, then having all the silicon
> in the world won't help you if the vendor stops selling the item that
> you need.
>
> We designed a $300K device that relied on a $5K software license.
> Vendor stopped issuing licenses.  What recourse did we have?  It's
> not that the "item" disappeared from the face of the Earth... just
> was no longer available for our LEGAL use.
>
> We either stop selling our existing product *or* redesign it to
> use some other replacement for that licensed component.  Of course,
> vendor would love to sell us some NEW component to take its place.
> But, would we want to open ourselves up to his intransigence on
> a *future* decision to stop selling THAT license?
>
>>> Sadly, for a *consumer* (| user), it means the same thing!  Because
>>> having
>>> all of that reside in the arms of a vendor does YOU no good if the
>>> vendor
>>> decides not to support it any longer.
>>>
>>> [I think anyone who buys a "smart appliance" is begging to be
>>> screwed-over
>>> in the future.  How long does a vendor support a "smart TV"?  Do the
>>> codecs
>>> keep being upgraded/repaired?  Or, does the vendor move on to developing
>>> Model N+1 with the newer codecs and leaving the older model(s) to
>>> languish?
>>> (i.e., treat your TV as a DUMB *monitor* and move all of the smarts
>>> *out* of
>>> it and into an appliance that YOU can control)]
>>>
>>> Gotta wonder about these smart refrigerators, thermostats, "Alexa",
>>> etc.  How
>>> much of the functionality is *in* the device and how much relies upon
>>> some
>>> other service?  (when that service goes away, you've got a dumb
>>> little box that
>>> can't even be repurposed to fill its original role!)
>>>
>>> [Of course, the vendor can rationalize moving the smarts out of the
>>> device
>>> and into a service as a means of driving the per unit cost down AND
>>> facilitating improvements to the service without "push updates".  And,
>>> you're just *renting* the device, after all...]
>>
>> They are all going this way as far as they can manage it of course.
>> Design software people use (not us, we have our own) is nowadays
>> based on yearly subscriptions, so is office etc. Exceptions/ways
>> through it still exist I guess but for how long.
>
> You stick with what you already have/had -- insofar as it is able
> to meet your ongoing needs.
>
> Or, embrace more "open" offerings... often with the need to make some
> commitment (time or money) to ensuring their continued availability,
> development, etc.
>
> (Too often, folks buy into FOSS for $0 -- thinking it "free" and not
> realizing that it can go away just as easily, without support, as
> any other offering!)
>

Well we have dps for power only but it comes with everything necessary
to do all the software for pretty sophisticated products without needing
a single bit of software from anyone else.
How does product lifetime licensing sound? :-)

On 1/9/2022 3:26 PM, Dimiter_Popoff wrote:
> On 1/10/2022 0:06, Don Y wrote:

>> You stick with what you already have/had -- insofar as it is able
>> to meet your ongoing needs.
>>
>> Or, embrace more "open" offerings... often with the need to make some
>> commitment (time or money) to ensuring their continued availability,
>> development, etc.
>>
>> (Too often, folks buy into FOSS for $0 -- thinking it "free" and not
>> realizing that it can go away just as easily, without support, as
>> any other offering!)
>
> Well we have dps for power only but it comes with everything necessary
> to do all the software for pretty sophisticated products without needing
> a single bit of software from anyone else.

This is the approach I've taken with all of my projects -- even if the
toolchain had to be purchased, commercially (it will still function
years later -- albeit without potential updates).

And, if you avoid "exotic" hardware/components, you can usually avoid
any dependence on particular suppliers (alas, the days of multiple
second-sources are long gone but you can still minimize the effort
involved in "porting" a design to a different BoM).

> How does product lifetime licensing sound? :-)

That's what you have when you own the technology. Many folks now
*can* have this by adopting open toolchains AND SUPPORTING THEM
(as most folks aren't interested in building tools from scratch but
*can* contribute -- bug reports, test cases, etc. -- to improving
an open toolchain's codebase)

Have you tried to guesstimate the effort required to port DPS to
another processor? (genuine question as I've not delved into
your code enough to understand it's "assumptions")

Tom Del Rosso wrote:
> Phil Hobbs wrote:
>> Tom Del Rosso wrote:
>>>
>>> Google's OS and Apple's OS probably wouldn't allow it. If more people
>>> had Linux phones it could be done, but they cost around $800 which
>>> gives an idea how much Google and Apple make from your phone.
>>>
>>>
>>
>> Nah, you can get a Pinephone for $200.
>
> Wow. I only looked at the high end with switches to power off
> components.
>
>
I have a Pinephone Beta and an early Pinephone tout court (not Pro).
Both have the dip switches.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Phil Hobbs wrote:
> Tom Del Rosso wrote:
>> Phil Hobbs wrote:
>>> Tom Del Rosso wrote:
>>>>
>>>> Google's OS and Apple's OS probably wouldn't allow it. If more
>>>> people had Linux phones it could be done, but they cost around
>>>> $800 which gives an idea how much Google and Apple make from your
>>>> phone.
>>>
>>> Nah, you can get a Pinephone for $200.
>>
>> Wow. I only looked at the high end with switches to power off
>> components.
>>
>>
> I have a Pinephone Beta and an early Pinephone tout court (not Pro).
> Both have the dip switches.

On the models I was looking at, there were slide switches on the side,
not DIP switches.

--
Defund the Thought Police
Andiamo Brandon!

On 1/10/2022 3:00, Don Y wrote:
> On 1/9/2022 3:26 PM, Dimiter_Popoff wrote:
>> On 1/10/2022 0:06, Don Y wrote:
>
>>> You stick with what you already have/had -- insofar as it is able
>>> to meet your ongoing needs.
>>>
>>> Or, embrace more "open" offerings... often with the need to make some
>>> commitment (time or money) to ensuring their continued availability,
>>> development, etc.
>>>
>>> (Too often, folks buy into FOSS for $0 -- thinking it "free" and not
>>> realizing that it can go away just as easily, without support, as
>>> any other offering!)
>>
>> Well we have dps for power only but it comes with everything necessary
>> to do all the software for pretty sophisticated products without needing
>> a single bit of software from anyone else.
>
> This is the approach I've taken with all of my projects -- even if the
> toolchain had to be purchased, commercially (it will still function
> years later -- albeit without potential updates).
>
> And, if you avoid "exotic" hardware/components, you can usually avoid
> any dependence on particular suppliers (alas, the days of multiple
> second-sources are long gone but you can still minimize the effort
> involved in "porting" a design to a different BoM).
>
>> How does product lifetime licensing sound? :-)
>
> That's what you have when you own the technology.  Many folks now
> *can* have this by adopting open toolchains AND SUPPORTING THEM
> (as most folks aren't interested in building tools from scratch but
> *can* contribute -- bug reports, test cases, etc. -- to improving
> an open toolchain's codebase)
>
> Have you tried to guesstimate the effort required to port DPS to
> another processor?  (genuine question as I've not delved into
> your code enough to understand it's "assumptions")

It won't be a huge effort but there will be a performance hit for
ARM, not that much for MIPS. The hit won't be that huge anyway.
But at the moment I am finishing something I have started a few
years ago (and had to put on hold for scheduling reasons), it started
as a file browser and is becoming an "object browser", fingers crossed
it won't take much longer (getting back into it took nearly a month).
So porting is not directly on the agenda, not yet anyway.

On 08/01/2022 20.17, legg wrote:
> On Sat, 8 Jan 2022 08:56:33 -0800 (PST), Lasse Langwadt Christensen
> <langwadt@fonz.dk> wrote:
>
>> lørdag den 8. januar 2022 kl. 16.33.18 UTC+1 skrev legg:
>>> On Sat, 08 Jan 2022 14:18:24 +0100, Jeroen Belleman
>>> <jer...@nospam.please> wrote:
>>>
>>>> For years, interaction with the internet worked through a
>>>> universal browser. Lately, every service, gadget or whatnot
>>>> wants you to download their special-purpose app. Why??
>>>> What's the deal? It seems like a huge step backwards to me.
>>>>
>>>> Jeroen Belleman
>>> Have been trying to get an Android OS running on a PC,
>>> just in order to communicate with hardware using a
>>> bluetooth link - which is what mfr app provides.
>>>
>>> Android cannot recognize, access or use most of
>>> PC hardware, to do this. Complete flop.
>>>
>>> Android not ready for anything other than use as toy.
>>
>> there are 3 billion active Android devices ...
>>
>
> The option of buying an android tablet and setting it
> up to run the app seems the only current alternative.
>
> Why? because Google doesn't want to do the work of
> creating a real OS. Revenue from toys id apparently
> enough.

There is no reason at all why they would want to do that. It is an OS
designed to run on phones and tablets, not computers. And in that role
it is king.

--
Cheers, Carlos.

On 08/01/2022 14.18, Jeroen Belleman wrote:
> For years, interaction with the internet worked through a
> universal browser. Lately, every service, gadget or whatnot
> wants you to download their special-purpose app. Why??
> What's the deal? It seems like a huge step backwards to me.

Not being limited by the browser.

For example, a radio station promotes their own app to listen to that
station. To make it run, you have to login, so they have you pinpointed.
Once there, you can not refuse their adverts. Your privacy is lost. Of
course, they also provide features to entice you and keep you in.

Even if you close the app, it can keep running in the background, and
for example, tell you that your favourite program is coming now.

--
Cheers, Carlos.

On 1/10/2022 1:47 AM, Dimiter_Popoff wrote:
>> Have you tried to guesstimate the effort required to port DPS to
>> another processor? (genuine question as I've not delved into
>> your code enough to understand it's "assumptions")
>
> It won't be a huge effort but there will be a performance hit for
> ARM, not that much for MIPS. The hit won't be that huge anyway.

What drives the efficiency aspect? My impression of your code
was that it abstracts a register-file based architecture (?); does
number (and color) of registers factor into how well it layers onto
a new platform?

> But at the moment I am finishing something I have started a few
> years ago (and had to put on hold for scheduling reasons), it started
> as a file browser and is becoming an "object browser", fingers crossed
> it won't take much longer (getting back into it took nearly a month).

For development use? Or, just as a general utility?

I tried to avoid building many tools for my system -- beyond ones that
let me watch transactions across multiple processors (e.g., flatten
RPCs so they look like simple function calls -- though annotated with
system timestamps and related metrics). Here, that's the toughest
aspect of debugging to wrap your head around (as the actual function
isn't executing on the node that initiates it so watching execution is
problematic).

And, a simple monitor that lets me attach a console to a node and step
through code, pull down binaries over the network, check clock
synchronization, etc. "Old tech" :>

> So porting is not directly on the agenda, not yet anyway.

"Agenda"? What's that?! :>

[I've some other questions but probably not suitable to ask in a
public forum. I'll drop you a line when I get all my immediate
"issues" behind me...]

On 1/10/2022 12:56, Don Y wrote:
> On 1/10/2022 1:47 AM, Dimiter_Popoff wrote:
>>> Have you tried to guesstimate the effort required to port DPS to
>>> another processor?  (genuine question as I've not delved into
>>> your code enough to understand it's "assumptions")
>>
>> It won't be a huge effort but there will be a performance hit for
>> ARM, not that much for MIPS. The hit won't be that huge anyway.
>
> What drives the efficiency aspect?  My impression of your code
> was that it abstracts a register-file based architecture (?); does
> number (and color) of registers factor into how well it layers onto
> a new platform?

Mainly the number of registers, much of the code thinks 32 registers
(r0-r31, d0-d7 are r8-r15, a0-a7 are r16-r23, a7 being the SP by
convention). Now I first use do-d7 a0-a5 (a6 usually holds the top
of the current stack frame), in the 68340 days I had only these
anyway, then I resort to r24-r31 as needed, r0-r3 have meanwhile
some specialized use (mapping them in memory would mean almost
no efficiency hit though - I think). r4-r7 are volatile on a per
source statement basis, used to calculate effective address etc.
Another aspect is the endianness, if the core cannot do both
accesses, especially big endian, this will cost something, too.
But the code is so compact and efficient things will still be
way better than a compiler output for something written in a
high level language.

>
>> But at the moment I am finishing something I have started a few
>> years ago (and had to put on hold for scheduling reasons), it started
>> as a file browser and is becoming an "object browser", fingers crossed
>> it won't take much longer (getting back into it took nearly a month).
>
> For development use?  Or, just as a general utility?

Mostly as a general utility for the users, people are used to see
something similar to windows explorer etc. Only this is becoming
very flexible/expandable, being based on dps objects (which are
runtime maintained, located etc., it is a largish thing and I
have spent well over a decade getting better and better at utilizing
it... never mind I have changed its basics very little since I
introduced it, wait, this was > 20 years ago, 1995-6 or so).

>
> I tried to avoid building many tools for my system -- beyond ones that
> let me watch transactions across multiple processors (e.g., flatten
> RPCs so they look like simple function calls -- though annotated with
> system timestamps and related metrics).  Here, that's the toughest
> aspect of debugging to wrap your head around (as the actual function
> isn't executing on the node that initiates it so watching execution is
> problematic).

I also do tooling "on demand", like everyone else I suppose.

>
> And, a simple monitor that lets me attach a console to a node and step
> through code, pull down binaries over the network, check clock
> synchronization, etc.  "Old tech"  :>

Oh I am using a monitor which is the basic part of the ROM like
forever, a new board still first comes up talking through an UART
(the flash being written to using boundary scan via jtag, never
had the details of the debug port beyond that, an NDA was not
enough for it and well, I can live without it anyway).
On a booted system it is the same monitor only the terminal is a
window via a "link" driver and a task entering the monitor
does not block the scheduler (but try to have a second task
exit to the monitor while the first one is in it and wait for
the reboot :).
I made a (now pretty old) version of this monitor freely available,
there has been no huge crowd downloading it but from time to time
someone does. ( http://tgi-sci.com/tgi/download/m52.htm )

On 1/10/2022 8:00 AM, Dimiter_Popoff wrote:
>>> But at the moment I am finishing something I have started a few
>>> years ago (and had to put on hold for scheduling reasons), it started
>>> as a file browser and is becoming an "object browser", fingers crossed
>>> it won't take much longer (getting back into it took nearly a month).
>>
>> For development use? Or, just as a general utility?
>
> Mostly as a general utility for the users, people are used to see
> something similar to windows explorer etc. Only this is becoming
> very flexible/expandable, being based on dps objects (which are
> runtime maintained, located etc., it is a largish thing and I
> have spent well over a decade getting better and better at utilizing
> it... never mind I have changed its basics very little since I
> introduced it, wait, this was > 20 years ago, 1995-6 or so).

Ah! I had a mistaken impression as to how the user interacts with
your instrument! I had assumed it was mainly a data collection
device and any real interaction/analysis was done on an attached
PC (even if that attachment was over the network).

>> I tried to avoid building many tools for my system -- beyond ones that
>> let me watch transactions across multiple processors (e.g., flatten
>> RPCs so they look like simple function calls -- though annotated with
>> system timestamps and related metrics). Here, that's the toughest
>> aspect of debugging to wrap your head around (as the actual function
>> isn't executing on the node that initiates it so watching execution is
>> problematic).
>
> I also do tooling "on demand", like everyone else I suppose.

Yes, esp if your needs don't fit neatly with existing tools (or
design approaches)

>> And, a simple monitor that lets me attach a console to a node and step
>> through code, pull down binaries over the network, check clock
>> synchronization, etc. "Old tech" :>
>
> Oh I am using a monitor which is the basic part of the ROM like
> forever, a new board still first comes up talking through an UART
> (the flash being written to using boundary scan via jtag, never
> had the details of the debug port beyond that, an NDA was not
> enough for it and well, I can live without it anyway).

Likewise. In my case (on production hardware), the serial port
is just a set of pads that can be probed with the right "accessory"
(similar to many consumer devices -- except I don't "dedicate"
the I/Os to that purpose). If the monitor detects that accessory
as being present, then it configures the I/Os as necessary and then
spawns a console on that port (overriding any intended use for those
pins)

> On a booted system it is the same monitor only the terminal is a
> window via a "link" driver and a task entering the monitor
> does not block the scheduler (but try to have a second task
> exit to the monitor while the first one is in it and wait for
> the reboot :).

My monitor runs in several different modes. In single-threaded
mode it controls the processor exclusively -- sort of like the
monitors of decades past. This is primarily useful for bringing
up new I/O subsystems as I can peek and poke various bits of the
hardware without worrying about anything else running on
the board.

In multi-threaded mode, it (can) "attaches" to a process and
let the rest of the system operate normally while the attached
process is subject to the control of the monitor. This is more
useful in bringing up core services -- like debugging the
initial network stack (used before the OS and *its* stack is
loaded) -- as it lets other services on the node run that
the new service may rely upon (e.g., timing services).

Bootstrap is painfully complicated because the code all has
to be loaded over the wire. And, the boot ROM doesn't know
what I/Os are present on the local node. Plus, the whole
transaction has to be "secure" so a node can't be compromised.

And, because there is no user interface (other than an idiot light),
a node has to convey "issues" to the rest of the system indirectly
(and hope something else can get the user's attention).

E.g., after power is applied, the PSE expects a hardware handshake
in a certain short interval - else it will remove power (this to
safeguard against the processor being insane and the hardware
being in an indeterminate state -- you wouldn't want a mechanism
"in motion" because the hardware had faulted.

So, there are lots of "baby steps" between application of power and
the intended invocation of "main()".

I suspect I will remove the monitor functionality from the boot ROM
image as it is unlikely that anyone will ever try to debug (at that
level) in the field. In consumer applications, they'll just replace
a node thinking it to be "defective". In industrial and commercial
applications, they'll swap out a node as downtime isn't worth the
cost of diagnosis.

[And, I'm not sure how vulnerable things would be if I left this
sort of "back door" in such an accessible place!]

> I made a (now pretty old) version of this monitor freely available,
> there has been no huge crowd downloading it but from time to time
> someone does. ( http://tgi-sci.com/tgi/download/m52.htm )

My monitors have evolved from simple to incredibly complex (including
support for breakpoint and trace hardware before processors had
those abilities). And, now, back to simpler (with the exception of
things like support for VMM).

As with most things, old ideas become new and the cycle endlessly repeats.

On 1/10/2022 3:55 AM, Carlos E.R. wrote:
> On 08/01/2022 14.18, Jeroen Belleman wrote:
>> For years, interaction with the internet worked through a
>> universal browser. Lately, every service, gadget or whatnot
>> wants you to download their special-purpose app. Why??
>> What's the deal? It seems like a huge step backwards to me.
>
> Not being limited by the browser.
>
> For example, a radio station promotes their own app to listen to that station.
> To make it run, you have to login, so they have you pinpointed. Once there, you
> can not refuse their adverts. Your privacy is lost. Of course, they also
> provide features to entice you and keep you in.

Using any device with it's own unique identifier (think MAC) means
your privacy is lost.

"I" may not know who you are, today, when I encounter your "identifier".
But, if I kabitz with others -- esp places where you are likely to identify
yourself directly (like a login/UID) or indirectly (like making a credit card
purchase) -- then the identifiers can be correlated and augmented, over time.

Amazon, ebay, google, etc. all "recognize" me even without logging in.
Even if I *never* log in! Because they can see my IP, fingerprint my
browser, etc.

So, when/if I ever *do* make a purchase (or otherwise identify myself),
they can now *add* my identity to the past observations they have made
about my interests, activities, etc.

> Even if you close the app, it can keep running in the background, and for
> example, tell you that your favourite program is coming now.

You can do the same with a browser. But, it is a considerably heavier
weight process -- because it has to cover more contingencies -- than an
app using (ONLY) the resources that it needs for given functionality.