D
Don Y
Guest
Hi Phil,
On 9/4/2014 12:03 PM, Phil Hobbs wrote:
> On 9/4/2014 2:35 PM, Don Y wrote:
[attrs elided]
WHICH IS EXACTLY THE POINT I WAS MAKING TO LASSE! I.e., there is no
inherent difference between Windows and OSX (PC vs Mac) -- in terms of
its ability to support "engineering programs".
Where does it assume this is an auto variable and not a static?
Or, that it's an array of "bytes"? The amount of memory that
an app requires doesn't classify certain apps as "bugs" and others
as "non-bugs". How many bytes of store *can* an application have?
As long as you don't exceed the syntactic constraints of the language
(i.e. run out of identifiers, etc.), the limit is determined by the
OS under which the app runs.
In the early 80's, I had to "crack" a "security device" implemented
in hardware. Basically an "undocumented FSM". My approach was
straightforward: build an array of next_state[current_state][stimulus].
Initialize it with "unknown".
Then, interatively query the hardware to determine the "current_state".
For that state, find a "stimulus" for which the "next_state" was, as
yet, unknown. Apply that stimulus driving the machine into a new (?)
next_state.
Lather, rinse, repeat.
When all entries in the array are known, you have a complete map of
the device -- which you can now reduce to "next state logic".
In the early 80's getting 64KB of "data" in an application was
tedious. Two or three times that was even moreso! (e.g., for
an 8 bit state vector, you need at least (256+1)(256) bytes just
to encode the next_state[][] -- double that if you want to make
it easier on yourself!
Rather than screw around with a MS compiler (which wouldn't support
such large objects) *and* an MS OS (which was still dealing with
silly "segment registers" and tiny address spaces), I wrote the
algorithm to run on a UN*X box (knowing it would still "thrash")
without having to cope with the (MS) OS's silly limitations.
*I* was talking about "parallel processing". You assumed multicore
approaches to parallel algorithms. E.g., the SETI example makes no
reliance on number of cores (*or* processes) on an individual
node. The "system" exists above/outside the individual nodes.
*It* has provisions -- exported to the constituent nodes -- that
allow them to operate in the collective.
I am unaware of any "Consumer" kit that is NORMA. But, that doesn't
alter the validity of my statement. *You* keep trying to make these
issues "specific". *I* stated them as "general constraints".
[My home automation system relies extensively on NORMA to get the
bandwidth and network transparency that it exploits (multimedia
and fault tolerance). Doing so in more conventional approaches
pushes all the work into the application (a bad idea, IME)]
I made a point in presenting an argument. Your counterpoints suggest
a failure to see those abstractions. If you want to live in *exactly*
2014 -- with no concept of 2015 or beyond (or awareness of what has
preceded), so be it.
No. RT doesn't preclude hardware independence. It's *easier* if you
can see the actual hardware and its performance. But, unless your
RT system is completely closed (i.e., boring and naive), the workload
can change over time. Effectively, such changes look like a constant
load with changing *hardware* (capabilities).
Isn't all of this about porting *code* to other OS's??
A namespace is a security concept. Write a piece of code that
generates and attempts to resolve every conceivable name. Run that in
a single, unified namespace system and you will get different results
than in a system that has per-task namespaces. I.e., it will
"stumble" on names that it shouldn't be accessing!
Some OS's try to give the illusion of per-task (process) namespaces
for certain devices. E.g., /dev/tty being the controlling [pt]ty for
a process -- regardless of the actual device that is wired to it.
With true independent namespaces, the OS generalizes this and allows
parents to fabricate (and, thus, CONSTRAIN) their offspring (a child
can't access <something> if it can't *name* it!)
E.g., I can bind "/input" to a particular hardware device, file,
etc. Then, "/foo/bar/whatever/output" to another. And, spawning a
child with the intent of copying /input to /foo/bar/whatever/output
will *ensure* that it doesn't "accidentally" access "/secret" or
"/kernel" (because "/secret" doesn't *exist* in the child's namespace).
How you code and how the system enforces these mechanisms varies
as does the reliability and robustness of the system. E.g., it's
as if every process is executing in an explicit jail created
*exclusively* for it! Yet, all existing in a larger namespace
(known, perhaps, only to its parent, grandparent, great-grandparent,
etc.). So, A's "/output" may, in fact, correspond to B's "/input".
Yet, neither is aware of the coexistence of the other -- nor the
fact that the same object has different names in each of their
respective namespaces.
If you don't have this ability in the OS, *adding* it in an emulation
library is difficult, at best, and probably unreliable in most cases!
[E.g., I don't need to worry about a user typing:
COPY SOMETHINGHESHOULDNOTACCESS SOMEPLACEPRIVATE
because SOMETHINGHESHOULDNOTACCESS isn't *visible* to him -- EVEN IF
HE MODIFIES THE SOURCE CODE of COPY.EXE]
No, I don't own a Mac. If you read upthread, you'll note that
I haven't used a Mac since MacOS 7-ish (68040). I'd like to
buy one to play with ProTools. But, that hasn't risen to a level
of interest to warrant my direct attention.
For the record, I don't own an iPhone, iPad, iWatch, iTV, etc.
(though I *have* rescued a few iPod's over the years).
My machines are PC's and Sun workstations. Windows/Solaris/*BSD
instead of OSX.
But, that doesn't change my assertion that there is nothing preventing
"Windows" apps from running on a Mac. Even *before* Mac's went to
"x86" architecture. (e.g., I have Windows XP on an UltraSPARC!).
What I was pointing out to Lasse -- who was standing by the "but the
apps aren't available on Macs" opinion -- was that this could change
tomorrow (though unlikely). I.e., Macs went from 68K's to x86's
so stranger things *have* happened!
Similarly, I can't get FrameMaker, AutoCAD, etc. on a Linux/*BSD box
*today*. But, that *may* change tomorrow. *If* those vendors
perceive a real market, there (users who will NOT buy their product
UNLESS it runs under those other OS's). As long as (folks like me)
will keep a Windows PC running to avail themselves of their product,
then why undertake the cost of porting and supporting yet another
OS (and, having to "jump" everytime MS *or* Apple *or* Linux ... makes
some change to their OS)
I don't really sympathize. I paid $1500 for my first 12MB of RAM.
Or, make a PC *into* a Mac (Hackintosh). You just won't end up
with the same STARK white appearance! :-/
[AFAICT, OSX is more NeXT/FreeBSD derived than Linux.]
On 9/4/2014 12:03 PM, Phil Hobbs wrote:
> On 9/4/2014 2:35 PM, Don Y wrote:
[attrs elided]
WHICH IS EXACTLY THE POINT I WAS MAKING TO LASSE! I.e., there is no
inherent difference between Windows and OSX (PC vs Mac) -- in terms of
its ability to support "engineering programs".
Where does it assume this is an auto variable and not a static?
Or, that it's an array of "bytes"? The amount of memory that
an app requires doesn't classify certain apps as "bugs" and others
as "non-bugs". How many bytes of store *can* an application have?
As long as you don't exceed the syntactic constraints of the language
(i.e. run out of identifiers, etc.), the limit is determined by the
OS under which the app runs.
In the early 80's, I had to "crack" a "security device" implemented
in hardware. Basically an "undocumented FSM". My approach was
straightforward: build an array of next_state[current_state][stimulus].
Initialize it with "unknown".
Then, interatively query the hardware to determine the "current_state".
For that state, find a "stimulus" for which the "next_state" was, as
yet, unknown. Apply that stimulus driving the machine into a new (?)
next_state.
Lather, rinse, repeat.
When all entries in the array are known, you have a complete map of
the device -- which you can now reduce to "next state logic".
In the early 80's getting 64KB of "data" in an application was
tedious. Two or three times that was even moreso! (e.g., for
an 8 bit state vector, you need at least (256+1)(256) bytes just
to encode the next_state[][] -- double that if you want to make
it easier on yourself!
Rather than screw around with a MS compiler (which wouldn't support
such large objects) *and* an MS OS (which was still dealing with
silly "segment registers" and tiny address spaces), I wrote the
algorithm to run on a UN*X box (knowing it would still "thrash")
without having to cope with the (MS) OS's silly limitations.
*I* was talking about "parallel processing". You assumed multicore
approaches to parallel algorithms. E.g., the SETI example makes no
reliance on number of cores (*or* processes) on an individual
node. The "system" exists above/outside the individual nodes.
*It* has provisions -- exported to the constituent nodes -- that
allow them to operate in the collective.
I am unaware of any "Consumer" kit that is NORMA. But, that doesn't
alter the validity of my statement. *You* keep trying to make these
issues "specific". *I* stated them as "general constraints".
[My home automation system relies extensively on NORMA to get the
bandwidth and network transparency that it exploits (multimedia
and fault tolerance). Doing so in more conventional approaches
pushes all the work into the application (a bad idea, IME)]
I made a point in presenting an argument. Your counterpoints suggest
a failure to see those abstractions. If you want to live in *exactly*
2014 -- with no concept of 2015 or beyond (or awareness of what has
preceded), so be it.
No. RT doesn't preclude hardware independence. It's *easier* if you
can see the actual hardware and its performance. But, unless your
RT system is completely closed (i.e., boring and naive), the workload
can change over time. Effectively, such changes look like a constant
load with changing *hardware* (capabilities).
Isn't all of this about porting *code* to other OS's??
A namespace is a security concept. Write a piece of code that
generates and attempts to resolve every conceivable name. Run that in
a single, unified namespace system and you will get different results
than in a system that has per-task namespaces. I.e., it will
"stumble" on names that it shouldn't be accessing!
Some OS's try to give the illusion of per-task (process) namespaces
for certain devices. E.g., /dev/tty being the controlling [pt]ty for
a process -- regardless of the actual device that is wired to it.
With true independent namespaces, the OS generalizes this and allows
parents to fabricate (and, thus, CONSTRAIN) their offspring (a child
can't access <something> if it can't *name* it!)
E.g., I can bind "/input" to a particular hardware device, file,
etc. Then, "/foo/bar/whatever/output" to another. And, spawning a
child with the intent of copying /input to /foo/bar/whatever/output
will *ensure* that it doesn't "accidentally" access "/secret" or
"/kernel" (because "/secret" doesn't *exist* in the child's namespace).
How you code and how the system enforces these mechanisms varies
as does the reliability and robustness of the system. E.g., it's
as if every process is executing in an explicit jail created
*exclusively* for it! Yet, all existing in a larger namespace
(known, perhaps, only to its parent, grandparent, great-grandparent,
etc.). So, A's "/output" may, in fact, correspond to B's "/input".
Yet, neither is aware of the coexistence of the other -- nor the
fact that the same object has different names in each of their
respective namespaces.
If you don't have this ability in the OS, *adding* it in an emulation
library is difficult, at best, and probably unreliable in most cases!
[E.g., I don't need to worry about a user typing:
COPY SOMETHINGHESHOULDNOTACCESS SOMEPLACEPRIVATE
because SOMETHINGHESHOULDNOTACCESS isn't *visible* to him -- EVEN IF
HE MODIFIES THE SOURCE CODE of COPY.EXE]
No, I don't own a Mac. If you read upthread, you'll note that
I haven't used a Mac since MacOS 7-ish (68040). I'd like to
buy one to play with ProTools. But, that hasn't risen to a level
of interest to warrant my direct attention.
For the record, I don't own an iPhone, iPad, iWatch, iTV, etc.
(though I *have* rescued a few iPod's over the years).
My machines are PC's and Sun workstations. Windows/Solaris/*BSD
instead of OSX.
But, that doesn't change my assertion that there is nothing preventing
"Windows" apps from running on a Mac. Even *before* Mac's went to
"x86" architecture. (e.g., I have Windows XP on an UltraSPARC!).
What I was pointing out to Lasse -- who was standing by the "but the
apps aren't available on Macs" opinion -- was that this could change
tomorrow (though unlikely). I.e., Macs went from 68K's to x86's
so stranger things *have* happened!
Similarly, I can't get FrameMaker, AutoCAD, etc. on a Linux/*BSD box
*today*. But, that *may* change tomorrow. *If* those vendors
perceive a real market, there (users who will NOT buy their product
UNLESS it runs under those other OS's). As long as (folks like me)
will keep a Windows PC running to avail themselves of their product,
then why undertake the cost of porting and supporting yet another
OS (and, having to "jump" everytime MS *or* Apple *or* Linux ... makes
some change to their OS)
I don't really sympathize. I paid $1500 for my first 12MB of RAM.
Or, make a PC *into* a Mac (Hackintosh). You just won't end up
with the same STARK white appearance! :-/
[AFAICT, OSX is more NeXT/FreeBSD derived than Linux.]