On 1/10/2022 20:30, Don Y wrote:> 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).Oh no, the user gets a screen of dps on a display, with the netMCA this is on a PC etc. via VNC (like a remote desktop) as the netMCA has no display controller - but it does maintain a framebuffer in system memory all right. http://tgi-sci.com/tgi/wwwfront.gif <- 3 netMCA-s via VNC on a PC http://tgi-sci.com/tgi/pnfrxx.gif <- with own display (around y. 2002) http://tgi-sci.com/tgi/fr64.gif <- earlier (pre-2000). I never wanted to work on software running under anyone's OS but mine - for reasons we both mentioned earlier - so even the first TGI product had its version of dps and MCA software, no PC needed at all (last link above, with mono display, no TFT back then). I still do have the file browser from that time which is good enough for use with 8.4 names (the only type of directories dps supported until some 10 years ago, now it does also up to 255 byte long names). Not a "windows explorer" but you can load/save a spectrum easily, will prompt you if you have typed in a unique name beginning etc., has been around since 1995 or so. http://tgi-sci.com/misc/fbr.gif <- just did a shot, 1995 was mono.> >> 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).So pretty much the same what my monitor does (mine is limited to a single task at a time though, keeps the user registers in the same locations etc.; while the entire monitor work area is changeable by a single pointer - done so for this purpose nearly 30 years ago - I never got around to do it... well, never really needed to, the "on demand" thing came into play.> > 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()".Debugging the boot process is the thing I most hate, especially after not having had to do it for years (so I have forgotten plenty of details).> > 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!]The back door consideration makes sense but I would not remove it just to not have it there. You never know what and when will end up at your desk...
Why apps?
Started by ●January 8, 2022
Reply by ●January 10, 20222022-01-10
Reply by ●January 10, 20222022-01-10
On 1/10/2022 12:19 PM, Dimiter_Popoff wrote:> On 1/10/2022 20:30, Don Y wrote: >> 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). > > Oh no, the user gets a screen of dps on a display, with the netMCA > this is on a PC etc. via VNC (like a remote desktop) as the netMCA has > no display controller - but it does maintain a framebuffer in system > memory all right.Yes, but I didn't think the user "did work" on the instrument. I thought the display was just to coax it to "do its thing" and review results. Anything beyond that would be handled "offline".> http://tgi-sci.com/tgi/wwwfront.gif <- 3 netMCA-s via VNC on a PC > http://tgi-sci.com/tgi/pnfrxx.gif <- with own display (around y. 2002)Was the case a "custom"? Or, something you found COTS?> http://tgi-sci.com/tgi/fr64.gif <- earlier (pre-2000).The probe looks like Q-bert: <http://images3.wikia.nocookie.net/__cb20130323030456/wreckitralph/images/5/5e/Qbert.png> [Which reminds me to rewatch _Pixels_... maybe tonight!]> I never wanted to work on software running under anyone's OS but > mine - for reasons we both mentioned earlier - so even the first TGI > product had its version of dps and MCA software, no PC needed at all > (last link above, with mono display, no TFT back then). > > I still do have the file browser from that time which is > good enough for use with 8.4 names (the only type of directories > dps supported until some 10 years ago, now it does also up to 255 byte > long names). Not a "windows explorer" but you can load/save a > spectrum easily, will prompt you if you have typed in a unique > name beginning etc., has been around since 1995 or so. > http://tgi-sci.com/misc/fbr.gif <- just did a shot, 1995 was mono. > >>> 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). > > So pretty much the same what my monitor does (mine is limited to > a single task at a time though, keeps the user registers in the same > locations etc.; while the entire monitor work area is changeable > by a single pointer - done so for this purpose nearly 30 years > ago - I never got around to do it... well, never really needed to, > the "on demand" thing came into play.In practice, you really only need to deal with one process at a time AS A MONITOR. If you're trying to debug "real" code, I rely on a more capable set of tools (with a PC hosting them). But, I learned from early projects that there is a lot of value to being able to "hot patch" a system in development. Esp if the system executes out of RAM.>> 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()". > > Debugging the boot process is the thing I most hate, especially > after not having had to do it for years (so I have forgotten > plenty of details).Booting the processor module is relatively straightforward (CPU, ROM, RAM, NIC, internal I/Os). And, knowing how large a "bite" to take in each step is now second nature (e.g., can't use RAM until you know it works; can't use ROM until you know it's not been corrupted; etc.) But, each node can have any number of I/O modules attached (same boot rom in the processor module). So, the CPU has to probe the I/O "space" and identify the modules that are present on *this* node (without powering them up!). Then, issue a request to the database server for the appropriate "boot rom" for each of those modules... run POST on them, etc. Only when all of that is done can the OS be loaded. And, then whatever applications the system wants hosted on that node. (but, once the OS is in place, there are lots of services that can make life easier)>> 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!] > > The back door consideration makes sense but I would not remove it > just to not have it there. You never know what and when will end up at > your desk...I won't have to support this so, from a personal perspective, it buys me nothing to leave it in place (I could always replace the CPU module on a given node with one that has a "fleshier" ROM image, in a pinch). I just don't like leaving what is essentially "dead code" in a product. Esp if the product is trying to be secure. (one more potential attack surface to analyze) There's some protection from abuse as the monitor doesn't activate unless it recognizes particular hardware "bolted on". But, that's security-by-obscurity (never to be trusted).
Reply by ●January 10, 20222022-01-10
On 1/10/2022 23:55, Don Y wrote:> On 1/10/2022 12:19 PM, Dimiter_Popoff wrote: >> On 1/10/2022 20:30, Don Y wrote: >>> 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). >> >> Oh no, the user gets a screen of dps on a display, with the netMCA >> this is on a PC etc. via VNC (like a remote desktop) as the netMCA has >> no display controller - but it does maintain a framebuffer in system >> memory all right. > > Yes, but I didn't think the user "did work" on the instrument. > I thought the display was just to coax it to "do its thing" > and review results. Anything beyond that would be handled > "offline". > >> http://tgi-sci.com/tgi/wwwfront.gif <- 3 netMCA-s via VNC on a PC >> http://tgi-sci.com/tgi/pnfrxx.gif <- with own display (around y. 2002) > > Was the case a "custom"? Or, something you found COTS?It was a "custom". Ventso (the father of my niece) made both cases you saw, pretty much handmade. Incredible guy. Died in January 2018 aged 66, just dropped dead in the street. I hope I'll manage to repeat that when my time comes, drop while still active, like him. https://www.flickr.com/photos/didi_tgi/43422741851/in/album-72157698828238075/ > ....> > Booting the processor module is relatively straightforward > (CPU, ROM, RAM, NIC, internal I/Os). And, knowing how large > a "bite" to take in each step is now second nature (e.g., > can't use RAM until you know it works; can't use ROM > until you know it's not been corrupted; etc.)Hah, we have a language issue here :-). To me this is "coming out of reset", it goes into the monitor and stays there or boots the OS automatically from disk (a bit in an eeprom called autoboot); if it autoboots it gives you a chance for 2 seconds to press escape and still go to the monitor (and perhaps boot from some device/partition other than the default found in the eeprom). IOW, to me "boot" is about starting the OS, the thing before that is "reset". The part I hate to debug is exactly this boot process, when you still don't have the OS running but you are starting it, many addresses are still unknown etc., memory paging is being setup etc. > ....
Reply by ●January 10, 20222022-01-10
On 1/10/2022 3:55 PM, Dimiter_Popoff wrote:> On 1/10/2022 23:55, Don Y wrote: >> On 1/10/2022 12:19 PM, Dimiter_Popoff wrote: >>> On 1/10/2022 20:30, Don Y wrote: >>>> 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). >>> >>> Oh no, the user gets a screen of dps on a display, with the netMCA >>> this is on a PC etc. via VNC (like a remote desktop) as the netMCA has >>> no display controller - but it does maintain a framebuffer in system >>> memory all right. >> >> Yes, but I didn't think the user "did work" on the instrument. >> I thought the display was just to coax it to "do its thing" >> and review results. Anything beyond that would be handled >> "offline". >> >>> http://tgi-sci.com/tgi/wwwfront.gif <- 3 netMCA-s via VNC on a PC >>> http://tgi-sci.com/tgi/pnfrxx.gif <- with own display (around y. 2002) >> >> Was the case a "custom"? Or, something you found COTS? > > It was a "custom". Ventso (the father of my niece) made both cases > you saw, pretty much handmade. Incredible guy.Impressive.> Died in January 2018 aged 66, just dropped dead in the street. > I hope I'll manage to repeat that when my time comes, drop while > still active, like him. > > https://www.flickr.com/photos/didi_tgi/43422741851/in/album-72157698828238075/ > > > .... >> >> Booting the processor module is relatively straightforward >> (CPU, ROM, RAM, NIC, internal I/Os). And, knowing how large >> a "bite" to take in each step is now second nature (e.g., >> can't use RAM until you know it works; can't use ROM >> until you know it's not been corrupted; etc.) > > Hah, we have a language issue here :-). To me this is "coming > out of reset",There are different OS's running at different times in the boot process. "Coming out of reset" is purely a bare-metal event. Nothing is known about the state of the hardware. I first reset the "field" (the attached IOs) to ensure that, if no other instruction executes, it will be driven to a safe state. Then, I reset the processor. Then, verify integrity of ROM -- before using *more* ROM to perform other tests (like checking the RAM, etc.). Once the "CPU module's resources" are known to be operational, I set up a small/fast RTOS that lets me use those to probe the I/O space to determine which modules are present, here (with the RTOS, I can now rely on things like timers and alternate threads to perform these tests). Part of that process is probe()ing for the monitor hardware. If it is not detected, then that code is never activated. No *way* to interrupt the boot process if you physically don't have the monitor hardware to provide an interface to a human! :> And, I can bring up the initial network stack to contact the database server (which acts as my filesystem) to load the POST routines for the modules that have been detected. POST doesn't require the advanced features of the real RTOS -- and wants to be relatively static over the life of the product -- so it can run on the streamlined RTOS more deterministically. Eventually, I can load the real RTOS from the RDBMS and start to resemble a functional node. [If I can't access the RDBMS or the real RTOS is unavailable, I can still react to the system but can't participate in its activities (because the "real" services rely on the real RTOS)] At this point, I can load the BIST (which runs on the real RTOS as it has to be able to operate while the application is running) to provide advanced diagnostics to the rest of the system so *it* can decide what parts of my functionality it wants to use, or make note of for later use. (a node sits idle, running diagnostics, until the system has a need for its resources *or* powers it down so it acts as a "warm spare")> it goes into the monitor and stays there or > boots the OS automatically from disk (a bit in an eeprom called > autoboot); if it autoboots it gives you a chance for 2 seconds > to press escape and still go to the monitor (and perhaps boot > from some device/partition other than the default found in > the eeprom). > IOW, to me "boot" is about starting the OS, the thing before > that is "reset".My nodes "do things" before the (real) OS is up because the real OS isn't "locally" accessible. I wouldn't want to have to keep running on bare metal just because the *real* RTOS isn't loadable. E.g., it's a much nicer environment to be able to run the network stack *alongside* the code that is trying to fetch the RTOS image instead of having to do these in sequential code. Likewise, with the real RTOS already running, the system can migrate any process to the node with a single system call so there's no real need to "load" an application. It's more like another (set of) cores coming online, suddenly, and the workload manager becoming aware of the availability of those resources.> The part I hate to debug is exactly this boot process, when you > still don't have the OS running but you are starting it, > many addresses are still unknown etc., memory paging is being > setup etc.Yes. That's the value of the monitor in development. You can verify the values that you *think* need to be poked into the PMMU and actually see if they work properly. In ages past, you might have a real ICE to do this interactively on a desktop. The monitor is just a poor-man's alternative. All of that has to be known to work before I can load the real RTOS. So, I want as rich an environment as possible *before* loading the RTOS to make that determination easier.
Reply by ●January 10, 20222022-01-10
Dimiter_Popoff <dp@tgi-sci.com> wrote in news:sridg9$ls1$1@dont- email.me:> Died in January 2018 aged 66, just dropped dead in the street. > I hope I'll manage to repeat that when my time comes, drop while > still active, like him.I just hope it doesn't hurt and that I don't poop all over the place. Not that I should care anyway.
Reply by ●January 11, 20222022-01-11
On 2022-01-08, 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 BellemanDo you want us to send you a brochure (browser), or shall we send someone round to hand you the brochure and search through your house while you're reading it, to see what else we can sell you (app)? </cynical> -- Ian "Tamahome!!!" - "Miaka!!!"
Reply by ●January 11, 20222022-01-11
On 2022-01-11 10:16, Ian wrote:> On 2022-01-08, 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 > > Do you want us to send you a brochure (browser), or shall we > send someone round to hand you the brochure and search through > your house while you're reading it, to see what else we can sell > you (app)? > > </cynical> >I don't even have a smart phone, so myself, I'm not at risk. However, it's quite clear that more and more things are done through smart phone apps. (Covid vaccination certificates, access to e-banking, on-line payments, to mention just a few that have harassed me lately.) Jeroen Belleman
Reply by ●January 11, 20222022-01-11
On 08/01/2022 23:17, 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.<https://netguard.me/> -- Jeff
Reply by ●January 11, 20222022-01-11
On 1/11/2022 3:53 AM, Jeff Layman wrote:> On 08/01/2022 23:17, 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. > > <https://netguard.me/>That addresses a different problem (and I'm not sure it does so comprehensively). What I think would be more useful is a filter that lets existing resources masquerade as something else. So, your GPS location is reported as "Oval Office, White House, Washington, D.C." regardless of where you are actually located -- but, only for application X. For application Y, it may report a completely random (lat,lon). And, for application Z, it may report the truth. Likewise, your contacts listed as "Mickey Mouse, Goofy, Pluto" for application X but "Fred, Barney, Wilma, Betty" for application Y. The list of installed apps reported as "NONE" for application X but a truthful disclosure for application Y and a fanciful list for Z (that doesn't include Z in that list! sort that one out, Z-developer!) Etc. You'd still need to add a number of active and conditional hooks to take actions that you'd likely be too undisciplined to take consistently (e.g., turn off BT and WiFi when near the following locations -- so infrastructure in those locations can't "see" your phone). The System is gamed against the user if privacy is a goal. "The only winning move is not to play".
