PC or Mac for at- home engineering?

[Don Y]

On 9/1/2014 11:56 PM, miso wrote:

Don Y wrote:
On 8/31/2014 3:23 PM, radams2000@gmail.com wrote:
Thanks for the advice. Even though I use Linux every day, I'm not
much of a sys admin and the last time I tried to install Linux on a
PC I got pretty frustrated. But that was about 10 years ago and I
suspect things are better now.

I'm kind of liking the 3-way Mac idea. I could invest in a pretty
high- end desktop Mac.

I don't like multi-boot machines, VMs, etc. I'd rather just have
another desktop, laptop, etc. squirreled away for<whatever
applications it may need. It also minimizes the amount of stuff on
any particular spindle (e.g., a disk crash doesn't cost you *all*
your "environments")

Sometimes you need to flash a peripheral. They write the code for windows
nowadays. In the dark ages, they would give you a boot program to flash a
peripheral.

My solution is just to have individual machines (One CPU, One OS)
for each particular need. I.e., replace contents of sock drawer with
a stack of laptops...

About the only thing that runs better on a mac is photshop elements, only
because Adobe is to lazy to write a 64 bit version. But there is good linux
photo software these days. Gimp is still 8 bits per pixel, and the 16 bit
version never seems to get released.

Dunno. I've not run anything "Apple" since the 68040 days (MacOS 7?).

However, the folks I know who run Macs tend to run Apple *throughout*.
I.e., Desktop, laptop, iPad, iPod, iPhone, etc. I suspect it is a
far more seamless experience than the MS approach -- to ANYTHING!

 

[miso]

Neon John wrote:

On Tue, 2 Sep 2014 04:26:31 -0700 (PDT), radams2000@gmail.com wrote:

Does anyone have experience with FPGA programming tools on non- PC
platforms?

Quartus comes in a native Linux flavor. It's configured for RedHat so
it takes some minor tinkering to get it to run under Ubuntu. It runs
fine - well, as fine as Quartus is ever going to run - under Linux.

John

Generally if they target RedHat it works easily on opensuse since they use
rpm. It is a bit harder to get them going on Debian distribution like
Ubuntu, but as you say, not impossible.

 

[miso]

Don Y wrote:

I've never heard anyone say anything OTHER than pejoratives re: MS!

Windows is far more useful than OSX for engineering.

I'm not a fan of windows update. Never let it updates anthing other than a
MS product. But I maintain a few windows machines for critical programs. [A
dual boot notebook and a desktop.]

I haven't use a mac since the 1980s. Of course, why would I?

 

[Lasse Langwadt Christense]

Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:

On 9/3/2014 2:39 AM, miso wrote:

Don Y wrote:



I've never heard anyone say anything OTHER than pejoratives re: MS!



Windows is far more useful than OSX for engineering.



No, more engineering *apps* run under Windows than OSX. There is an

important semantic difference in the statements.

not really, if the apps you need doesn't run it is useless


-Lasse

 

[Lasse Langwadt Christense]

Den onsdag den 3. september 2014 19.56.04 UTC+2 skrev Don Y:

Hi Lasse,



On 9/3/2014 10:03 AM, Lasse Langwadt Christensen wrote:

Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:

On 9/3/2014 2:39 AM, miso wrote:



Windows is far more useful than OSX for engineering.



No, more engineering *apps* run under Windows than OSX. There is an

important semantic difference in the statements.



not really, if the apps you need doesn't run it is useless



Can you point to some characteristic of OSX (as an OS) that

would preclude an app -- written for OSX -- from running?

no, but if the app isn't written for OSX it doesn't matter if
it could have been

I could understand an app that inherently is graphic-oriented

would "find trouble" being supported by an OS that deals

entirely with "character devices" (e.g., running Ventura Publisher

under DOS 3.3 required GEM as middleware as the OS didn't natively

support this sort of user interface).



But, you can do damn near everything that Windows supports under

OSX -- just with a different API and "look and feel" conventions.



My (above) point is that more engineering app vendors have chosen

Windows as the platform of choice on which to offer their products.

They could just as easily have chosen OSX. Windows doesn't offer

any "technological advantage" that makes it better suited to those

apps!

"could have been" doesn't matter. If you can only buy nails what you need
is a hammer, even the fanciest screwdriver isn't going to do you any good


-Lasse

 

[Don Y]

On 9/3/2014 2:39 AM, miso wrote:

Don Y wrote:

I've never heard anyone say anything OTHER than pejoratives re: MS!

Windows is far more useful than OSX for engineering.

No, more engineering *apps* run under Windows than OSX. There is an
important semantic difference in the statements.

I'm not a fan of windows update. Never let it updates anthing other than a
MS product. But I maintain a few windows machines for critical programs. [A
dual boot notebook and a desktop.]

I run Windows (online) update exactly once for a machine -- when I
initially build it (after drivers installed and before any apps).
Thereafter, any updates are applied "offline" and only if I deem
them necessary (i.e., as the machines NEVER talk to the outside
world, 90% of the updates are unnecessary)

> I haven't use a mac since the 1980s. Of course, why would I?

My attitude towards Linux! :>

 

On Tue, 02 Sep 2014 21:34:52 -0700, Don Y <this@is.not.me.com> wrote:

On 9/1/2014 11:56 PM, miso wrote:
Don Y wrote:
On 8/31/2014 3:23 PM, radams2000@gmail.com wrote:
Thanks for the advice. Even though I use Linux every day, I'm not
much of a sys admin and the last time I tried to install Linux on a
PC I got pretty frustrated. But that was about 10 years ago and I
suspect things are better now.

I'm kind of liking the 3-way Mac idea. I could invest in a pretty
high- end desktop Mac.

I don't like multi-boot machines, VMs, etc. I'd rather just have
another desktop, laptop, etc. squirreled away for<whatever
applications it may need. It also minimizes the amount of stuff on
any particular spindle (e.g., a disk crash doesn't cost you *all*
your "environments")

Sometimes you need to flash a peripheral. They write the code for windows
nowadays. In the dark ages, they would give you a boot program to flash a
peripheral.

My solution is just to have individual machines (One CPU, One OS)
for each particular need. I.e., replace contents of sock drawer with
a stack of laptops...

Ick! Getting data from one to another is a RPITA. I have that problem
with a couple of tools that require XP or a PCMCIA slot. XP is no
longer allowed on our intranet, so there isn't any choice but I'd sure
rather not have to have three laptops (four, including this one) all
over my workspace.

About the only thing that runs better on a mac is photshop elements, only
because Adobe is to lazy to write a 64 bit version. But there is good linux
photo software these days. Gimp is still 8 bits per pixel, and the 16 bit
version never seems to get released.

Dunno. I've not run anything "Apple" since the 68040 days (MacOS 7?).

However, the folks I know who run Macs tend to run Apple *throughout*.
I.e., Desktop, laptop, iPad, iPod, iPhone, etc. I suspect it is a
far more seamless experience than the MS approach -- to ANYTHING!

I have an iPod Touch (the market for that class of player is limited).
It sure doesn't play nice with Windows and the UI sucks, even by
itself.

 

[Don Y]

Hi Lasse,

On 9/3/2014 10:03 AM, Lasse Langwadt Christensen wrote:

Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:
On 9/3/2014 2:39 AM, miso wrote:

Windows is far more useful than OSX for engineering.

No, more engineering *apps* run under Windows than OSX. There is an
important semantic difference in the statements.

not really, if the apps you need doesn't run it is useless

Can you point to some characteristic of OSX (as an OS) that
would preclude an app -- written for OSX -- from running?

I could understand an app that inherently is graphic-oriented
would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher
under DOS 3.3 required GEM as middleware as the OS didn't natively
support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.
They could just as easily have chosen OSX. Windows doesn't offer
any "technological advantage" that makes it better suited to those
apps!

 

[Bill Sloman]

On Thursday, 4 September 2014 09:11:30 UTC+10, k...@attt.bizz wrote:

On Wed, 03 Sep 2014 17:59:13 -0500, John Fields
jfields@austininstruments.com> wrote:
On Wed, 03 Sep 2014 18:43:24 -0400, krw@attt.bizz wrote:
On Wed, 03 Sep 2014 10:56:04 -0700, Don Y <this@is.not.me.com> wrote:
On 9/3/2014 10:03 AM, Lasse Langwadt Christensen wrote:
Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:
On 9/3/2014 2:39 AM, miso wrote:

Windows is far more useful than OSX for engineering.

No, more engineering *apps* run under Windows than OSX. There is an important semantic difference in the statements.

not really, if the apps you need doesn't run it is useless

Can you point to some characteristic of OSX (as an OS) that
would preclude an app -- written for OSX -- from running?

I could understand an app that inherently is graphic-oriented would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher under DOS 3.3 required GEM as middleware as the OS didn't natively support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.

They could just as easily have chosen OSX. Windows doesn't offer any "technological advantage" that makes it better suited to those
apps!

Sure there is. Cost.

Cost is an economic advantage, not a technological one.

Which just shows, once again, that you're a has-been wannabe.

Not really. "Cost" really is an economic advantage, rather than a technological advantage. You may find it irritating that John Fields pointed this out, but the fact that he pointed it out would make him - at worst - a pedant, rather than a retiree trying to raise his status (which does happen to be higher than yours around here, because he does sometimes post technical answers to technical question, even if most of them do involve the NE555).

--
Bill Sloman, Sydney

 

On Wed, 03 Sep 2014 10:56:04 -0700, Don Y <this@is.not.me.com> wrote:

Hi Lasse,

On 9/3/2014 10:03 AM, Lasse Langwadt Christensen wrote:
Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:
On 9/3/2014 2:39 AM, miso wrote:

Windows is far more useful than OSX for engineering.

No, more engineering *apps* run under Windows than OSX. There is an
important semantic difference in the statements.

not really, if the apps you need doesn't run it is useless

Can you point to some characteristic of OSX (as an OS) that
would preclude an app -- written for OSX -- from running?

I could understand an app that inherently is graphic-oriented
would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher
under DOS 3.3 required GEM as middleware as the OS didn't natively
support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.
They could just as easily have chosen OSX. Windows doesn't offer
any "technological advantage" that makes it better suited to those
apps!

Sure there is. Cost.

 

[John Fields]

On Wed, 03 Sep 2014 18:43:24 -0400, krw@attt.bizz wrote:

On Wed, 03 Sep 2014 10:56:04 -0700, Don Y <this@is.not.me.com> wrote:

Hi Lasse,

On 9/3/2014 10:03 AM, Lasse Langwadt Christensen wrote:
Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:
On 9/3/2014 2:39 AM, miso wrote:

Windows is far more useful than OSX for engineering.

No, more engineering *apps* run under Windows than OSX. There is an
important semantic difference in the statements.

not really, if the apps you need doesn't run it is useless

Can you point to some characteristic of OSX (as an OS) that
would preclude an app -- written for OSX -- from running?

I could understand an app that inherently is graphic-oriented
would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher
under DOS 3.3 required GEM as middleware as the OS didn't natively
support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.
They could just as easily have chosen OSX. Windows doesn't offer
any "technological advantage" that makes it better suited to those
apps!

Sure there is. Cost.

---
Cost is an economic advantage, not a technological one.

John Fields

 

On Wed, 03 Sep 2014 17:59:13 -0500, John Fields
<jfields@austininstruments.com> wrote:

On Wed, 03 Sep 2014 18:43:24 -0400, krw@attt.bizz wrote:

On Wed, 03 Sep 2014 10:56:04 -0700, Don Y <this@is.not.me.com> wrote:

Hi Lasse,

On 9/3/2014 10:03 AM, Lasse Langwadt Christensen wrote:
Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:
On 9/3/2014 2:39 AM, miso wrote:

Windows is far more useful than OSX for engineering.

No, more engineering *apps* run under Windows than OSX. There is an
important semantic difference in the statements.

not really, if the apps you need doesn't run it is useless

Can you point to some characteristic of OSX (as an OS) that
would preclude an app -- written for OSX -- from running?

I could understand an app that inherently is graphic-oriented
would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher
under DOS 3.3 required GEM as middleware as the OS didn't natively
support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.
They could just as easily have chosen OSX. Windows doesn't offer
any "technological advantage" that makes it better suited to those
apps!

Sure there is. Cost.

---
Cost is an economic advantage, not a technological one.

Which just shows, once again, that you're a has-been wannabe.

 

[Don Y]

Hi Lasse,

On 9/3/2014 12:10 PM, Lasse Langwadt Christensen wrote:

Den onsdag den 3. september 2014 19.56.04 UTC+2 skrev Don Y:
On 9/3/2014 10:03 AM, Lasse Langwadt Christensen wrote:

Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:
On 9/3/2014 2:39 AM, miso wrote:

Windows is far more useful than OSX for engineering.

No, more engineering *apps* run under Windows than OSX. There is an
important semantic difference in the statements.

not really, if the apps you need doesn't run it is useless

Can you point to some characteristic of OSX (as an OS) that
would preclude an app -- written for OSX -- from running?

no, but if the app isn't written for OSX it doesn't matter if
it could have been

I could understand an app that inherently is graphic-oriented
would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher
under DOS 3.3 required GEM as middleware as the OS didn't natively
support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.
They could just as easily have chosen OSX. Windows doesn't offer
any "technological advantage" that makes it better suited to those
apps!

"could have been" doesn't matter. If you can only buy nails what you need
is a hammer, even the fanciest screwdriver isn't going to do you any good

If there are no underlying technological differences/advantages to
one OS over another, then it is conceivable and practical to use
an emulation library or other middleware to RELATIVELY easily
port an application from one to another.

Contrast this, for example, with an application that is designed as
multiple communicating processes on an OS that supports some form of
IPC/RPC and then trying to port it to an S that has no such
communication mechanisms (or, very poor/inefficient equivalents).

Or, an OS that only supports a single execution context (vs. one
that supports multiples).

Or, an OS that supports true parallel processing (vs. one that only
supports the illusion of same).

etc.

 

[Phil Hobbs]

On 09/03/2014 07:22 PM, Don Y wrote:

Hi Lasse,

On 9/3/2014 12:10 PM, Lasse Langwadt Christensen wrote:
Den onsdag den 3. september 2014 19.56.04 UTC+2 skrev Don Y:
On 9/3/2014 10:03 AM, Lasse Langwadt Christensen wrote:

Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:
On 9/3/2014 2:39 AM, miso wrote:

Windows is far more useful than OSX for engineering.

No, more engineering *apps* run under Windows than OSX. There is an
important semantic difference in the statements.

not really, if the apps you need doesn't run it is useless

Can you point to some characteristic of OSX (as an OS) that
would preclude an app -- written for OSX -- from running?

no, but if the app isn't written for OSX it doesn't matter if
it could have been

I could understand an app that inherently is graphic-oriented
would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher
under DOS 3.3 required GEM as middleware as the OS didn't natively
support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.
They could just as easily have chosen OSX. Windows doesn't offer
any "technological advantage" that makes it better suited to those
apps!

"could have been" doesn't matter. If you can only buy nails what you need
is a hammer, even the fanciest screwdriver isn't going to do you any good

If there are no underlying technological differences/advantages to
one OS over another, then it is conceivable and practical to use
an emulation library or other middleware to RELATIVELY easily
port an application from one to another.

Contrast this, for example, with an application that is designed as
multiple communicating processes on an OS that supports some form of
IPC/RPC and then trying to port it to an S that has no such
communication mechanisms (or, very poor/inefficient equivalents).

That isn't so bad. I've written and supported a cross-platform
clusterized simulator code (Linux, Windows, and at one time OS/2).

Or, an OS that only supports a single execution context (vs. one
that supports multiples).

Like DOS? Everybody's had multiple threads for the last 20 years. Unix
and OS/2 had it further back than that.

Or, an OS that supports true parallel processing (vs. one that only
supports the illusion of same).

That makes almost no difference at all as far as the coder is concerned.
SIMD is a bit different, but usually the compiler looks after
vectorizing stuff. But multithreaded apps on one core vs multiple cores
is no problem--usually you just ignore the issue, because the
serialization problems are just the same.

It's different GUIs that are the real pain.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Phil Hobbs]

On 09/04/2014 10:32 AM, Phil Hobbs wrote:

On 09/03/2014 07:22 PM, Don Y wrote:
Hi Lasse,

On 9/3/2014 12:10 PM, Lasse Langwadt Christensen wrote:
Den onsdag den 3. september 2014 19.56.04 UTC+2 skrev Don Y:
On 9/3/2014 10:03 AM, Lasse Langwadt Christensen wrote:

Den onsdag den 3. september 2014 18.43.32 UTC+2 skrev Don Y:
On 9/3/2014 2:39 AM, miso wrote:

Windows is far more useful than OSX for engineering.

No, more engineering *apps* run under Windows than OSX. There is an
important semantic difference in the statements.

not really, if the apps you need doesn't run it is useless

Can you point to some characteristic of OSX (as an OS) that
would preclude an app -- written for OSX -- from running?

no, but if the app isn't written for OSX it doesn't matter if
it could have been

I could understand an app that inherently is graphic-oriented
would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher
under DOS 3.3 required GEM as middleware as the OS didn't natively
support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.
They could just as easily have chosen OSX. Windows doesn't offer
any "technological advantage" that makes it better suited to those
apps!

"could have been" doesn't matter. If you can only buy nails what you
need
is a hammer, even the fanciest screwdriver isn't going to do you any
good

If there are no underlying technological differences/advantages to
one OS over another, then it is conceivable and practical to use
an emulation library or other middleware to RELATIVELY easily
port an application from one to another.

Contrast this, for example, with an application that is designed as
multiple communicating processes on an OS that supports some form of
IPC/RPC and then trying to port it to an S that has no such
communication mechanisms (or, very poor/inefficient equivalents).

That isn't so bad. I've written and supported a cross-platform
clusterized simulator code (Linux, Windows, and at one time OS/2).


Or, an OS that only supports a single execution context (vs. one
that supports multiples).

Like DOS? Everybody's had multiple threads for the last 20 years. Unix
and OS/2 had it further back than that.


Or, an OS that supports true parallel processing (vs. one that only
supports the illusion of same).

That makes almost no difference at all as far as the coder is concerned.
SIMD is a bit different, but usually the compiler looks after
vectorizing stuff. But multithreaded apps on one core vs multiple cores
is no problem--usually you just ignore the issue, because the
serialization problems are just the same.

It's different GUIs that are the real pain.

Oh, and the security APIs, of course.

Cheers

Phil Hobbs

 

[whit3rd]

On Thursday, September 4, 2014 12:39:00 PM UTC-4, Don Y wrote:

At the limit, a *simulator* can run under "foreign OS, foreign iron"
that mimics the behavior of "native OS, native iron" -- typically at
a *huge* performance penalty! For example, (MULTICS, GE645) running
on (Windows, IA64)?

Actually, ARM and MIPS and Alpha (all RISC type machines) have little
difficulty doing emulations. Also, 'modern' software works with runtime library
functions so that compiling up a few native libraries is a more important
speed consideration than whether the main application is native or
interpreted.

ARM cpus ran the 68000 code of earlier Palm devices just fine.
Windows NT was fully supported on DEC Alpha workstations.
A trio of generations of Macintosh CPUs ran (until Apple dropped
the software compatibility functions) 68000 code on PowerPC, and PowerPC
code on Intel.

 

[Don Y]

Hi Phil,

On 9/4/2014 7:32 AM, Phil Hobbs wrote:

On 09/03/2014 07:22 PM, Don Y wrote:
On 9/3/2014 12:10 PM, Lasse Langwadt Christensen wrote:
Den onsdag den 3. september 2014 19.56.04 UTC+2 skrev Don Y:

I could understand an app that inherently is graphic-oriented
would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher
under DOS 3.3 required GEM as middleware as the OS didn't natively
support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.
They could just as easily have chosen OSX. Windows doesn't offer
any "technological advantage" that makes it better suited to those
apps!

"could have been" doesn't matter. If you can only buy nails what you
need is a hammer, even the fanciest screwdriver isn't going to do
you any good

If there are no underlying technological differences/advantages to
one OS over another, then it is conceivable and practical to use
an emulation library or other middleware to RELATIVELY easily
port an application from one to another.

Contrast this, for example, with an application that is designed as
multiple communicating processes on an OS that supports some form of
IPC/RPC and then trying to port it to an S that has no such
communication mechanisms (or, very poor/inefficient equivalents).

That isn't so bad. I've written and supported a cross-platform
clusterized simulator code (Linux, Windows, and at one time OS/2).

You can write damn near *any* sort of environment emulation (assuming
you can draw on the necessary resources -- secondary store, "time",
etc.) But you end up having to *build* that system *under* the existing
(constrained) OS.

E.g., if the OS doesn't allow any form of IPC, you have to either
build a VM under it *or* resort to kludges to pass data between
different, ISOLATED processes (e.g., pass data through buffers on
some other shared medium -- like disk files).

The cost of doing so (in time porting the app as well as the impact
on the UX) typically makes it a non-starter. Especially if it is for
one or two apps that you own (i.e., have authored) -- simpler to expect
users/customers to move to that "native" platform.

Or, an OS that only supports a single execution context (vs. one
that supports multiples).

Like DOS? Everybody's had multiple threads for the last 20 years. Unix
and OS/2 had it further back than that.

How long a feature has been available wasn't the point of my comment.
Rather, to illustrate the types of issues that make an OS sufficiently
different from another -- at a technological level -- to complicate
(or, alternatively, enhance) an application's development on one
platform over another.

E.g., an app intended to run on a 64-bit OS trying to be hosted on a
32b one.

Or, an app that expects gobs of memory to be available (real or virtual)
instead of what the current OS supports.

Or, an app that expects real-time guarantees trying to run on an
OS that has no concept of such.

Etc.

Or, an OS that supports true parallel processing (vs. one that only
supports the illusion of same).

That makes almost no difference at all as far as the coder is concerned.
SIMD is a bit different, but usually the compiler looks after
vectorizing stuff. But multithreaded apps on one core vs multiple cores
is no problem--usually you just ignore the issue, because the
serialization problems are just the same.

Don't limit your thinking to SMP. :> (remember, apps can be written
BEFORE "current" features are available or in widespread use! I've been
writing multitasking and RT apps for over 30 years -- the latter still
isn't "widely embraced" in the programming community)

An app written expecting a *particular* parallel processing model (e.g.,
before multiple core machines were en vogue) isn't easily ported to
an environment where you are limited to a single active thread.

> It's different GUIs that are the real pain.

The trick to writing *any* graphic-intensive application is to pick
some middleware that you control (or *can* control) and, in doing so,
allow the interface to be (relatively) easily ported from platform
to platform. If you climb in bed with a particular (OS) vendor,
then you're (later) stuck trying to second guess how their API
behaves internally IN ENOUGH DETAIL that you can draw parallels
to the "other" targeted API.

If, OTOH, you've inserted a layer as middleware with cleanly defined
interfaces above and below, you've already gone through the exercise
of "porting it" to the original host OS.

[Of course, the typical hit, here, is performance -- the extra
middleware's cost and the "impedance mismatch" between what the
middleware expects from the supporting OS and what the OS actually
supplies].

At the limit, a *simulator* can run under "foreign OS, foreign iron"
that mimics the behavior of "native OS, native iron" -- typically at
a *huge* performance penalty! For example, (MULTICS, GE645) running
on (Windows, IA64)?

 

[Phil Hobbs]

On 09/04/2014 12:39 PM, Don Y wrote:

Hi Phil,

On 9/4/2014 7:32 AM, Phil Hobbs wrote:
On 09/03/2014 07:22 PM, Don Y wrote:
On 9/3/2014 12:10 PM, Lasse Langwadt Christensen wrote:
Den onsdag den 3. september 2014 19.56.04 UTC+2 skrev Don Y:

I could understand an app that inherently is graphic-oriented
would "find trouble" being supported by an OS that deals
entirely with "character devices" (e.g., running Ventura Publisher
under DOS 3.3 required GEM as middleware as the OS didn't natively
support this sort of user interface).

But, you can do damn near everything that Windows supports under
OSX -- just with a different API and "look and feel" conventions.

My (above) point is that more engineering app vendors have chosen
Windows as the platform of choice on which to offer their products.
They could just as easily have chosen OSX. Windows doesn't offer
any "technological advantage" that makes it better suited to those
apps!

"could have been" doesn't matter. If you can only buy nails what you
need is a hammer, even the fanciest screwdriver isn't going to do
you any good

If there are no underlying technological differences/advantages to
one OS over another, then it is conceivable and practical to use
an emulation library or other middleware to RELATIVELY easily
port an application from one to another.

Contrast this, for example, with an application that is designed as
multiple communicating processes on an OS that supports some form of
IPC/RPC and then trying to port it to an S that has no such
communication mechanisms (or, very poor/inefficient equivalents).

That isn't so bad. I've written and supported a cross-platform
clusterized simulator code (Linux, Windows, and at one time OS/2).

You can write damn near *any* sort of environment emulation (assuming
you can draw on the necessary resources -- secondary store, "time",
etc.) But you end up having to *build* that system *under* the existing
(constrained) OS.

E.g., if the OS doesn't allow any form of IPC, you have to either
build a VM under it *or* resort to kludges to pass data between
different, ISOLATED processes (e.g., pass data through buffers on
some other shared medium -- like disk files).

The cost of doing so (in time porting the app as well as the impact
on the UX) typically makes it a non-starter. Especially if it is for
one or two apps that you own (i.e., have authored) -- simpler to expect
users/customers to move to that "native" platform.

Or, an OS that only supports a single execution context (vs. one
that supports multiples).

Like DOS? Everybody's had multiple threads for the last 20 years. Unix
and OS/2 had it further back than that.

How long a feature has been available wasn't the point of my comment.
Rather, to illustrate the types of issues that make an OS sufficiently
different from another -- at a technological level -- to complicate
(or, alternatively, enhance) an application's development on one
platform over another.

I understand, but even the Raspberry Pi has a pthreads library. What
are you writing for, Voyager 2?

E.g., an app intended to run on a 64-bit OS trying to be hosted on a
32b one.

Or, an app that expects gobs of memory to be available (real or virtual)
instead of what the current OS supports.

That's a bug, not a porting issue.

Or, an app that expects real-time guarantees trying to run on an
OS that has no concept of such.

Etc.

Or, an OS that supports true parallel processing (vs. one that only
supports the illusion of same).

That makes almost no difference at all as far as the coder is concerned.
SIMD is a bit different, but usually the compiler looks after
vectorizing stuff. But multithreaded apps on one core vs multiple cores
is no problem--usually you just ignore the issue, because the
serialization problems are just the same.

Don't limit your thinking to SMP. :> (remember, apps can be written
BEFORE "current" features are available or in widespread use! I've been
writing multitasking and RT apps for over 30 years -- the latter still
isn't "widely embraced" in the programming community)

I'm not limiting myself to SMP, I'm saying that there's no difference
between the programming models of single-core multithread and SMP, or
various flavours of NUMA, as long as cache-coherency is maintained.

An app written expecting a *particular* parallel processing model (e.g.,
before multiple core machines were en vogue) isn't easily ported to
an environment where you are limited to a single active thread.

Okay, so a Cray program won't run on a toaster, even in 2014. So what?

I thought we were talking about running engineering programs on desktops?

<snip>

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Don Y]

Hi Phil,

On 9/4/2014 10:53 AM, Phil Hobbs wrote:
> On 09/04/2014 12:39 PM, Don Y wrote:

[attrs elided]

Or, an OS that only supports a single execution context (vs. one
that supports multiples).

Like DOS? Everybody's had multiple threads for the last 20 years. Unix
and OS/2 had it further back than that.

How long a feature has been available wasn't the point of my comment.
Rather, to illustrate the types of issues that make an OS sufficiently
-----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
different from another -- at a technological level -- to complicate
(or, alternatively, enhance) an application's development on one
platform over another.

I understand, but even the Raspberry Pi has a pthreads library. What are
you writing for, Voyager 2?

Please read what I wrote.

E.g., SETI@home won't run on a *single*, isolated uniprocessor (well,
it will *run*, it will just have ZERO chances of producing any results).
I.e., you can't have enough MIPS in a single processor to *ever*
expect a "non-serendipitous" result. You *need* an OS that will
support VERY many concurrent processors working on the same problem
concurrently. And, IPC alone will not suffice as those processors
can't (in the foreseeable future!) coexist in a location that would
allow IPC transport mechanisms; some form of RPC is *required*.

In this example, you can cheat and rely on a network stack to give
you the RPC because there is very little communication required
(relative to the workload performed on each host). You can build an
emulation layer (even if it is just a convention used for passing
messages over the Internet to distribute workloads, report results,
etc.) to bind heterogeneous systems together.

E.g., an app intended to run on a 64-bit OS trying to be hosted on a
32b one.

Or, an app that expects gobs of memory to be available (real or virtual)
instead of what the current OS supports.

That's a bug, not a porting issue.

No, it isn't. How is "myarray[65535][65535]" a bug? It's syntactically
correct. It will run on an OS that supports big memory spaces (virtual
or real) but not on one that doesn't.

OTOH, "speed = distance / time" is a *bug* -- because "time" can
conceivably be zero. (regardless of the OS)

Or, an app that expects real-time guarantees trying to run on an
OS that has no concept of such.

Etc.

Or, an OS that supports true parallel processing (vs. one that only
supports the illusion of same).

That makes almost no difference at all as far as the coder is concerned.
SIMD is a bit different, but usually the compiler looks after
vectorizing stuff. But multithreaded apps on one core vs multiple cores
is no problem--usually you just ignore the issue, because the
serialization problems are just the same.

Don't limit your thinking to SMP. :> (remember, apps can be written
BEFORE "current" features are available or in widespread use! I've been
writing multitasking and RT apps for over 30 years -- the latter still
isn't "widely embraced" in the programming community)

I'm not limiting myself to SMP, I'm saying that there's no difference
between the programming models of single-core multithread and SMP, or
various flavours of NUMA, as long as cache-coherency is maintained.

So, NORMA systems aren't considered "parallel processing"?

An app written expecting a *particular* parallel processing model (e.g.,
before multiple core machines were en vogue) isn't easily ported to
an environment where you are limited to a single active thread.

Okay, so a Cray program won't run on a toaster, even in 2014. So what?

I thought we were talking about running engineering programs on desktops?

I made a general statement. You chose to ignore its generality and
apply it to specifics:

"If there are no underlying technological differences/advantages to
one OS over another, then it is conceivable and practical to use
an emulation library or other middleware to RELATIVELY easily
port an application from one to another."

NOT having an RPC/IPC facility is a technological difference.
NOT having a network stack (or even the NOTION of a "remote" host)
is a technological difference.
NOT having a capabilities based security model is a technological
difference (i.e., it impacts the code you write!).
NOT having support for big/virtual memory is a technological difference
(want to REFACTOR your code as OVERLAYS???).
NOT having support for the concept of "timeliness" in an OS is a
technological difference.
NOT having per-task namespaces is a technological difference.
Etc.

I see no technological differences between OSX and Windows (or Linux)
that preclude using "an emulation layer or other middleware" to port
an application -- especially an "engineering program" -- from one to
the other (I would have a different opinion if we were discussing a
process control system, etc.)

The fact (?) that fewer "engineering programs" run on Macs than PC's
simply suggests that the markets that Macs and PCs address have an
imbalance in terms of the types of users AND APPLICATIONS THEY DEMAND.

But, that doesn't mean EngineeringApplicationX couldn't be ported
from, e.g., Windows to OSX (or Linux) *if* the vendor/author decided
there was sufficient market for it, there. (Or, if a third party
saw a large enough market to produce a complete emulation ENVIRONMENT
of systemA under systemB so one acts as the other) This is the point I
was making to Lasse -- just because EngineeringApplicationX (or Y or Z)
isn't available TODAY on a Mac doesn't mean it won't be, tomorrow.
(unless you can point to some technological capability that is
MISSING in OSX -- but present in Windows -- that those apps rely upon).

 

[Phil Hobbs]

On 9/4/2014 2:35 PM, Don Y wrote:

Hi Phil,

On 9/4/2014 10:53 AM, Phil Hobbs wrote:
On 09/04/2014 12:39 PM, Don Y wrote:

[attrs elided]

Or, an OS that only supports a single execution context (vs. one
that supports multiples).

Like DOS? Everybody's had multiple threads for the last 20 years. Unix
and OS/2 had it further back than that.

How long a feature has been available wasn't the point of my comment.
Rather, to illustrate the types of issues that make an OS sufficiently
-----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
different from another -- at a technological level -- to complicate
(or, alternatively, enhance) an application's development on one
platform over another.

I understand, but even the Raspberry Pi has a pthreads library. What are
you writing for, Voyager 2?

Please read what I wrote.

I did read it. I just think that it's an irrelevant counterfactual
digression, because there isn't a lot of opportunity to suffer from any
of these constraints on modern hardware.

E.g., SETI@home won't run on a *single*, isolated uniprocessor (well,
it will *run*, it will just have ZERO chances of producing any results).
I.e., you can't have enough MIPS in a single processor to *ever*
expect a "non-serendipitous" result. You *need* an OS that will
support VERY many concurrent processors working on the same problem
concurrently. And, IPC alone will not suffice as those processors
can't (in the foreseeable future!) coexist in a location that would
allow IPC transport mechanisms; some form of RPC is *required*.

In this example, you can cheat and rely on a network stack to give
you the RPC because there is very little communication required
(relative to the workload performed on each host). You can build an
emulation layer (even if it is just a convention used for passing
messages over the Internet to distribute workloads, report results,
etc.) to bind heterogeneous systems together.

E.g., an app intended to run on a 64-bit OS trying to be hosted on a
32b one.

Or, an app that expects gobs of memory to be available (real or virtual)
instead of what the current OS supports.

That's a bug, not a porting issue.

No, it isn't. How is "myarray[65535][65535]" a bug? It's syntactically
correct. It will run on an OS that supports big memory spaces (virtual
or real) but not on one that doesn't.

It's a bug because it assumes that the program will have at least 4 gig
of stack space, which it won't on any machine that I'm familiar with.

OTOH, "speed = distance / time" is a *bug* -- because "time" can
conceivably be zero. (regardless of the OS)

There are lots of different kinds of bugs.

Or, an app that expects real-time guarantees trying to run on an
OS that has no concept of such.

Etc.

Or, an OS that supports true parallel processing (vs. one that only
supports the illusion of same).

That makes almost no difference at all as far as the coder is
concerned.
SIMD is a bit different, but usually the compiler looks after
vectorizing stuff. But multithreaded apps on one core vs multiple cores
is no problem--usually you just ignore the issue, because the
serialization problems are just the same.

Don't limit your thinking to SMP. :> (remember, apps can be written
BEFORE "current" features are available or in widespread use! I've been
writing multitasking and RT apps for over 30 years -- the latter still
isn't "widely embraced" in the programming community)

I'm not limiting myself to SMP, I'm saying that there's no difference
between the programming models of single-core multithread and SMP, or
various flavours of NUMA, as long as cache-coherency is maintained.

So, NORMA systems aren't considered "parallel processing"?

As in Norma Jean Brady? I don't know of any actual NORMA boxes, do you?
You can make something similar with a cluster, but we were talking
about multithread vs multicore.

An app written expecting a *particular* parallel processing model (e.g.,
before multiple core machines were en vogue) isn't easily ported to
an environment where you are limited to a single active thread.

Okay, so a Cray program won't run on a toaster, even in 2014. So what?

I thought we were talking about running engineering programs on desktops?

I made a general statement. You chose to ignore its generality and
apply it to specifics:

If you're just writing the Great American Mythological Computer Novel, OK.

"If there are no underlying technological differences/advantages to
one OS over another, then it is conceivable and practical to use
an emulation library or other middleware to RELATIVELY easily
port an application from one to another."

NOT having an RPC/IPC facility is a technological difference.
NOT having a network stack (or even the NOTION of a "remote" host)
is a technological difference.

Right, that's the toaster controller again. Are you running SPICE on a
toaster?

NOT having a capabilities based security model is a technological
difference (i.e., it impacts the code you write!).

Right, I said that at first. Security APIs and GUIs are the things that
make porting a pain.

NOT having support for big/virtual memory is a technological difference
(want to REFACTOR your code as OVERLAYS???).
NOT having support for the concept of "timeliness" in an OS is a
technological difference.

Real-time apps are generally tightly tied to the hardware, because
otherwise you wouldn't care about guaranteed latency bounds. So that's
a whole other issue, not just OS and processor.

> NOT having per-task namespaces is a technological difference.

What? A namespace is a source code concept. You can use any language
you like, even on toasters.

Etc.


I see no technological differences between OSX and Windows (or Linux)
that preclude using "an emulation layer or other middleware" to port
an application -- especially an "engineering program" -- from one to
the other (I would have a different opinion if we were discussing a
process control system, etc.)

The fact (?) that fewer "engineering programs" run on Macs than PC's
simply suggests that the markets that Macs and PCs address have an
imbalance in terms of the types of users AND APPLICATIONS THEY DEMAND.

But, that doesn't mean EngineeringApplicationX couldn't be ported
from, e.g., Windows to OSX (or Linux) *if* the vendor/author decided
there was sufficient market for it, there. (Or, if a third party
saw a large enough market to produce a complete emulation ENVIRONMENT
of systemA under systemB so one acts as the other) This is the point I
was making to Lasse -- just because EngineeringApplicationX (or Y or Z)
isn't available TODAY on a Mac doesn't mean it won't be, tomorrow.
(unless you can point to some technological capability that is
MISSING in OSX -- but present in Windows -- that those apps rely upon).

'Twas't my point at all. I realize that you're a Mac fanboy, which is
fine with me--I was too, at least for a brief while in in 1984. Then
Apple screwed over its original Mac customers by charging $1000 for a
$75 memory upgrade, and has never looked back. (Neither have I.)

Newer Macs are basically closed-hardware PCs running Linux with eye
candy on top of it, so there's no reason in principle that you couldn't
run anything you like.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net