PC or Mac for at- home engineering?

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

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)

My attitude towards Linux! :>

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

-Lasse

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.

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.

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!

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

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

"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

Sure there is. Cost.

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

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.

n important semantic difference in the statements.

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

ind trouble" being supported by an OS that deals entirely with "character devices" (e.g., running Ventura Publisher under DO S 3.3 required GEM as middleware as the OS didn't natively support this sor t of user interface).

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

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

"technological advantage" that makes it better suited to those apps!

Not really. "Cost" really is an economic advantage, rather than a technolog ical advantage. You may find it irritating that John Fields pointed this ou t, 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 an swers to technical question, even if most of them do involve the NE555).

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

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

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

Oh, and the security APIs, of course.

Cheers

Phil Hobbs

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.

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

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.

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.

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.

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)?

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

That's a bug, not a porting issue.

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.

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?

Cheers

Phil Hobbs

-----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.

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)

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

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).

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.

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.

There are lots of different kinds of bugs.

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.

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

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

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

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.

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

'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

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.

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 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".

I made a point in presenting an argument. Your counterpoints suggest a failure to see those abstractions. If you want to live in *exactly*

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 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

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!

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

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! :-/

Yes, even Intel is addressing this "in silicon".

Some OS's allow complete OS API patches. In effect, pulling the emulation library *into* the OS instead of layering it atop (think: protection domain cost penalties -- much more efficient to move the emulation library into the kernel's protection domain than to require a layered emulation library to make multiple traps *into* it with those performance hits)

Each comes with a performance penalty. I.e., you *could* emulate a GE645 on a Windows machine -- even with it's funky 36? bit data. But, at some considerable cost.

Of course, you can argue that process improvements have sped up modern processors enough that a *simulation* of such an old architecture could still happen in "near real time" (i.e., if your performance expectations of those apps were that of 1976! :> )