Comparing algorithm costs

And now that ram is cheap, the bloat remains.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Virtual memory has lots of uses beyond emulating larger physical RAM.

E.g., I don't have a traditional backing store ("disk") in my design yet exploit VMM in many places.

What do you do when the PHYSICAL memory into which you've loaded your code develops an uncorrectable error? You've linked it at compile time so that physical memory address MUST contain that value -- even if it can't! So, your product misbehaves (at best) and requires replacement.

Of course, it will be perceived as a software bug even though the HARDWARE has failed!

With VMM, you can swap out that physical page and install another "corrected" page in that page frame and the product keeps on ticking.

You can share physical memory between protected domains (so two instances of a process can share the same TEXT). Fork/exec is sped up considerably by exploiting CoW.

You can leverage it to pass large data structures between processed (e.g., "here is a frame of video that I have decompressed, YOU analyze it -- without worrying that I may be scribbling in it while you are doing so... I'll use another data structure to decompress the next frame")

Most PMMU-based VMMs allow you to set protections on individual pages -- so you can catch attempts to execute DATA memory (as well as providing interprocess protections). You can dynamically extend and contract stack segments as well as determine when the maximum allocation has been exceeded (instead of relying on guards)

Of course, your developers need to understand how it works and how to leverage its capabilities -- much like any other mechanism. (Would you eschew recursion simply because neophytes can create recursive algorithms that don't properly terminate? Hire better people!)

ISTR LORAN-C has been "turned off" (at least the GRIs in the US). This may prove to be a mistake if GPS is ever hacked (or, attacked in space).

LORAN doesn't give the same level of precision that GPS can. And, being terrestrial, is affected by propagation paths (slower over sea water than land, etc. -- as it is TIME that is being measured, this is important).

Nowadays, one could likely build a LORAN receiver in an FPGA as it's all low frequency RF and modest timing requirements (~10MHz).

Don Y snipped-for-privacy@foo.invalid wrote: |-----------------------------------------------------------------------| |"[I knew of a piece of code that read a byte at a time from a | |file and incremented a counter after each successful read -- to | |determine the size of the file. Clearly a naive approach and | |terribly inefficient. But, the result was always accurate, | |even if costly to compute!]" | |-----------------------------------------------------------------------|

Websites often allow users to upload a file but such websites often impose a size limit.

Today I used an imperfect website which is oriented for Gaelic purposes to upload a file. This website had not warned that it imposes a size limit. I attempted to upload that 122-megabyte file:

"Le fichier chargé dépasse la taille de fichier maximale autorisée." said

Don Y snipped-for-privacy@foo.invalid wrote: |-----------------------------------------------------------------------| |"Because, if I had built a discrete device to close the garage door | |at sundown, I would never think of giving it access to the thermostat!"| |-----------------------------------------------------------------------|

You are thinking of it right now!!! :) (S.

Can the web app "stat(2)" the file? (I have no idea what the capabilities of client-side apps esp considering sandboxing issues) I.e., is it even possible for it to know the size of the file before "collecting" it?

No, I'm thinking of NOT giving it access -- a very different issue!

Don Y snipped-for-privacy@foo.invalid wrote: |-------------------------------------| |"Can the web app "stat(2)" the file?"| |-------------------------------------|

It can not exactly use "stat(2)", but it can use an equivalent feature which a web browser permits it to.

|------------------------------------------------------------------------| |"(I have no idea what the capabilities | |of client-side apps esp considering sandboxing issues) I.e., is it even| |possible for it to know the size of the file before "collecting" it?" | |------------------------------------------------------------------------|

Yes. This web app is not written to bother to check, whereas different web apps do check sizes so they refuse to even begin to upload big files. (S.

Clearly, a mismatch between what the developer THOUGHT the user would be doing and what the user *might* do. No surprise, there.

This is why it's important to have specifications/"contracts" so stakeholders can determine the suitability of an implementation for a particular envisioned use.

I once used a website hosting company that would re-encode large gifs for my website to a lower resolution to save space. I remember posting a big circuit diagram that was clear here, but came out fuzzy on the website. People complained, downloaded it back from my website, indeed fuzzy. Had a little talk about that with them, they then stopped doing that. Have a different hosting company now, seems to work OK.