From: Joel Koltner on
"Joerg" <invalid(a)invalid.invalid> wrote in message
news:8b8epnF9t7U1(a)mid.individual.net...
> Even Windows (usually) lets you decide where to put a program. Unless
> the program installer is written very restrictively which sometimes is
> the case with CAD.

That's really more "broken" than "restrictive." :-)

ORCAD doesn't work quite right if you install it into a directory that has
spaces in the path... including, of course, "c:\program files." (By default
it wants to install to something like c:\cadence\spb_16.5.)

This fact alone suggests to me that there's a serious problem with the folks
in charge of developing and maintaining ORCAD (...long file names/those with
space in them started with Windows 95 in... 1995...); they've really got to be
scrapping the bottom of the Windows programmers barrel!

---Joel

From: Joerg on
Joel Koltner wrote:
> "Joerg" <invalid(a)invalid.invalid> wrote in message
> news:8b8epnF9t7U1(a)mid.individual.net...
>> Even Windows (usually) lets you decide where to put a program. Unless
>> the program installer is written very restrictively which sometimes is
>> the case with CAD.
>
> That's really more "broken" than "restrictive." :-)
>
> ORCAD doesn't work quite right if you install it into a directory that
> has spaces in the path... including, of course, "c:\program files." (By
> default it wants to install to something like c:\cadence\spb_16.5.)
>

I try to stick with the old DOS rules when setting up directories and
never put spaces in there. That way, in a pinch, I can get into things
with DOS plus a NTFS converter routine. DOS was written by smart people
who thought ahead. Even if the directory name is messed up it replaces
the end with a tilde and not throw in the towel.

It seems that "modern" is not always good. I say that from experience
with "modern" programs, analyzers, scopes, ovens, cars, dishwashers ...


> This fact alone suggests to me that there's a serious problem with the
> folks in charge of developing and maintaining ORCAD (...long file
> names/those with space in them started with Windows 95 in... 1995...);
> they've really got to be scrapping the bottom of the Windows programmers
> barrel!
>

I gave up on Orcad a long, long time ago. Not as many crashes as
Acrobat, but too many for my taste. Cadsoft Eagle never crashes.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
From: Jim Thompson on
On Tue, 27 Jul 2010 10:44:43 -0700, "Joel Koltner"
<zapwireDASHgroups(a)yahoo.com> wrote:

>"Joerg" <invalid(a)invalid.invalid> wrote in message
>news:8b8epnF9t7U1(a)mid.individual.net...
>> Even Windows (usually) lets you decide where to put a program. Unless
>> the program installer is written very restrictively which sometimes is
>> the case with CAD.
>
>That's really more "broken" than "restrictive." :-)
>
>ORCAD doesn't work quite right if you install it into a directory that has
>spaces in the path... including, of course, "c:\program files." (By default
>it wants to install to something like c:\cadence\spb_16.5.)
>
>This fact alone suggests to me that there's a serious problem with the folks
>in charge of developing and maintaining ORCAD (...long file names/those with
>space in them started with Windows 95 in... 1995...); they've really got to be
>scrapping the bottom of the Windows programmers barrel!
>
>---Joel

Cadence is noted for buying and (attempting) destroying good
competitive products.

In my opinion OrCAD Capture is the biggest piece of excrement on the
market.

...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

Spice is like a sports car...
Performance only as good as the person behind the wheel.
From: Grant on
On Tue, 27 Jul 2010 09:11:29 -0700, Joerg <invalid(a)invalid.invalid> wrote:

>Grant wrote:
>> On Mon, 26 Jul 2010 16:48:31 -0700, Joerg <invalid(a)invalid.invalid> wrote:
>>
>>> Grant wrote:
>>>> On Mon, 26 Jul 2010 14:03:24 -0700, Joerg <invalid(a)invalid.invalid> wrote:
>>>>
>>>>> Joel Koltner wrote:
>>>>>> "Grant" <omg(a)grrr.id.au> wrote in message
>>>> ...
>>>> >From a serious CAD user it can be expected that he or she understands
>>>>> the basics of file management. In fact, gEDA was written completely
>>>>> Linux-centric, ports to Windows have largely failed because some not so
>>>>> compatible code must have been employed (in laymen's terms). Yet even
>>>>> gEDA does what every CAD does, store libraries in program directories.
>>>> Well that's plain stupid.
>>>>
>>> Care to explain why?
>>
>> Linux is multi-user, there's system wide rules need to be followed so
>> that the system can protect the users from themselves and other users.
>>
>> Even when there's only one user account, that user is isolated from
>> damaging the OS, simply by not allowing the user to write anywhere they
>> please ;)
>>
>> If you install and run a CAD program under your user area, you may
>> do anything you like, as it has no impact on the system (apart from
>> using resources). Stuff in your own area follows your rules.
>>
>
>Usually I do that. I have a directory "Programs", then sub-directories
>"Electric", "Editors", Utilities" and so on. Works fine. But
>occasionally programs come with a crippled installer and will only
>install under the Windows default "Program Files".
>
>
>> But I'm guessing you CAD app didn't come as source, therefore you
>> had no choice as to where it was compiled to run. and which directories
>> it uses for data files.
>>
>> This is a difference between Linux and windows. Under Linux, people
>> compile their applications and have control over the app's runtime
>> resource allocation.
>>
>
>I know, and that's another reason why I prefer Windows. I do analog and
>RF engineering. So I neither have the inclination nor the time to piece
>together this, that and the other thing, re-write stuff here and there,
>and then compile.
>
>Even Windows (usually) lets you decide where to put a program. Unless
>the program installer is written very restrictively which sometimes is
>the case with CAD.
>
>
>> If you're running some commercial binary, you're not fully in control
>> of your own system.
>>
>
>Question is: Do I want to be?
>
>
>> Under unix or linux there's three places you might add an application,
>> in the system area for all users, under /usr/local, again for all users,
>> or create a ~/bin and run the app from user area. Most Linux apps
>> distributed as source give you that choice, which is setup as a normal
>> part of compiling the app for your machine.
>>
>
>With a properly configured installer I can write it to just about
>anywhere on Windows. Unfortunately one must live with the installer the
>CAD company furnishes.
>
>
>> The reason for compiling apps is that a machine might be big or little
>> ended CPU, different system libraries, shell, *BSD, Linux or Solaris!
>
>
>I don't want to compile :-)
>
>>>
>>>>> Meaning user libs and non-custom libs get splintered up. What's wrong
>>>>> with allowing write access to the lib directory?
>>>> Question is, which lib directory.
>>>>
>>>> The proper place for writable system libraries is /var/lib/$appname :)
>>>>
>>>> For example, my Slackware-11 box has:
>>>>
>>>> grant(a)deltree:~$ ls /var/lib
>>>> arpd/ bsdgames/ elm/ logrotate/ misc/ mysql/ nfs/ rpm/ stunnel/ xdm/ xkb/
>>>>
>>>> The program may create its own directory there and allow user access
>>>> and writing. It's difficult to find an exception to the standard
>>>> unix rules for basic layout (Sorry, I forget the exact name,
>>>> hierarchical file system or similar) that's been around for a
>>>> decade or more.
>>>>
>>>> Simple, no?
>>>>
>>> All I can say is that I asked in the gEDA group why I can't have the std
>>> libs and mine in one default place and the answer was pretty much, well,
>>> that I can't easily do that. And that I should just log in sudo.
>>
>> That's the windows solution, run as admin all the time. We don't do
>> that with Linux, it's bad for many reasons. And, by saying log in
>> sudo, sounds like that *ubuntu windows wannabe nonsense? Indicates
>> you don't compile the app (I guess it's commercial binary), thus have
>> no control over where it wants to keep things.
>
>
>This was said by hardcore Linux users. And yes, I am using Ubuntu.
>
>
>>> But it didn't matter anymore anyhow because gschem bungles refdeses upon
>>> auto-annotate. That's a big no-no in CAD.
>>
>> I'm still trying to pick a freebie circuit and PCB CAD, only single
>> sided and two-layer through hole plated required. The eagle size
>> limit (80x100mm) is a wee bit small. No budget for CAD 'cos only
>> hobby level that might grow, into something. And, I'm on low income,
>> retired, sorta.
>
>
>Well, since you know Linux well you might want to look into gEDA then.
>It's ok for digital stuff, just IMHO not for hardcore RF and analog.
>There is a good newsgroup for it:
>
>gmane.comp.cad.geda.user
>
>Another open source CAD that I think is even better is Kicad, which
>AFAIR comes in Windows and Linux installer versions. So you don't have
>to compile anything.
>
>>>
>>>> Users may have private libraries under /home/username/whatever
>>>>> I don't want an OS to tell me what I can't and cannot do, just like I
>>>>> don't want a car to decide when to shift :-)
>>>> There are standards out there that define a framework for these things,
>>>> of course it is not rigid, as there's no Linux Incorporated controlling
>>>> this stuff. Each application author has a choice of what standards to
>>>> follow. A high end CAD system should follow the standard patterns for
>>>> flexible target OS. (I haven't used CAD for 17 years, no idea what's
>>>> what these days).
>>>>
>>> Well, I live with CAD for 24 years now :-)
>>
>> Last I worked in design, it was maybe 15-20% CAD for schematic and PCB,
>> then software to define the product, often variations on same hardware
>> for different product end applications. Then there was another product
>> 30-40k lines of assembler that I worked on, off and on for nine years
>> until the hardware was no longer produced. Started on cp/m box with 8"
>> floppies and ended on a win3 box with hard drive and 3.5" floppies...
>
>
>Wow, last time I saw 8" floppies was on a Racal Redac CAD system that
>ran on a VAX. But I couldn't get reasonable time-slots on it so drew my
>(large) schematic by hand.
>
>>>
>>>> It's not about deciding when to shift, more about expecting the shift
>>>> to have a standard H plus extras (reverse and fifth) pattern (or paddles,
>>>> or gated semi-auto) and be roughly in the same spot (or two), within
>>>> reach of the driver.
>>>>
>>>> You know, standards, so many to choose from ;)
>>>>
>>> I don't care which place they are in, or which side the steering wheel
>>> is on. As long as there is no automatic transmission.
>>
>> Fair enough :) My current car is auto, first time, I think I prefer
>> manuals, that annoying delay, waiting for the transmission to decide
>> it's time to shift...
>>
>
>Wait until the road ices up, that when the "fun" begins in an automatic :-)
From: Grant on
On Tue, 27 Jul 2010 09:11:29 -0700, Joerg <invalid(a)invalid.invalid> wrote:

>Grant wrote:
>> On Mon, 26 Jul 2010 16:48:31 -0700, Joerg <invalid(a)invalid.invalid> wrote:
>>
>>> Grant wrote:
>>>> On Mon, 26 Jul 2010 14:03:24 -0700, Joerg <invalid(a)invalid.invalid> wrote:
>>>>
>>>>> Joel Koltner wrote:
>>>>>> "Grant" <omg(a)grrr.id.au> wrote in message
>>>> ...
>>>> >From a serious CAD user it can be expected that he or she understands
>>>>> the basics of file management. In fact, gEDA was written completely
>>>>> Linux-centric, ports to Windows have largely failed because some not so
>>>>> compatible code must have been employed (in laymen's terms). Yet even
>>>>> gEDA does what every CAD does, store libraries in program directories.
>>>> Well that's plain stupid.
>>>>
>>> Care to explain why?
>>
>> Linux is multi-user, there's system wide rules need to be followed so
>> that the system can protect the users from themselves and other users.
>>
>> Even when there's only one user account, that user is isolated from
>> damaging the OS, simply by not allowing the user to write anywhere they
>> please ;)
>>
>> If you install and run a CAD program under your user area, you may
>> do anything you like, as it has no impact on the system (apart from
>> using resources). Stuff in your own area follows your rules.
>>
>
>Usually I do that. I have a directory "Programs", then sub-directories
>"Electric", "Editors", Utilities" and so on. Works fine. But
>occasionally programs come with a crippled installer and will only
>install under the Windows default "Program Files".

Windows always had that issue of mixing programs and data. And the
silly idea that made any file executable by associating the filetype
with a program.

Unix is fundamentally different, in that if you sent me a raw script,
it would not be executable until I told it to be. It's difficult to
convey this basic and simple idea across to someone grew up with
ms-dos + windows.

Linux is inherently safer, when one follows the rules of mostly
acting through a user account. However, the last few year's of
populist *ubuntu advertising has produced a heap of Linux users
with no clue as to 'normal' operation of a unix-like OS. The
ubuntu crowd sometimes tried to contribute to linux, but there
suggestions came way too late, the issues were already solved.

On top of all that, instead of creating their own distro, they
simply repackage Debian. That makes ubuntu yet another useless
derivative distro, only they got some notice because anybody,
anywhere could write and ask for a couple hundred CDs delivered
free, to use as bird scare reflectors on their orchards ;^)
>
>
>> But I'm guessing you CAD app didn't come as source, therefore you
>> had no choice as to where it was compiled to run. and which directories
>> it uses for data files.
>>
>> This is a difference between Linux and windows. Under Linux, people
>> compile their applications and have control over the app's runtime
>> resource allocation.
>>
>
>I know, and that's another reason why I prefer Windows. I do analog and
>RF engineering. So I neither have the inclination nor the time to piece
>together this, that and the other thing, re-write stuff here and there,
>and then compile.

There's a lot of very scientific tools on Linux, via the university
unix labs and engineering or math depts.
>
>Even Windows (usually) lets you decide where to put a program. Unless
>the program installer is written very restrictively which sometimes is
>the case with CAD.

But windows still lets you mix program and data, you cannot run windows
from a CD, you cannot run windows securely.
>
>
>> If you're running some commercial binary, you're not fully in control
>> of your own system.
>>
>
>Question is: Do I want to be?

sometimes, sometimes not -- because there is a standard to follow,
large applications are distributed as precompiled binaries, the ones
I'm likely to use are well behaved: vmware, java, the web browsers.

Because compiling large apps is time consuming. Debian acts as the
repository for most of the free Linux software, even I don't use
Debian, I may find a source tarball there and compile it for my
Linux box.

Compiling from source is what gives users freedom with unix-like OS.

Can modify the source too.
>
>
>> Under unix or linux there's three places you might add an application,
>> in the system area for all users, under /usr/local, again for all users,
>> or create a ~/bin and run the app from user area. Most Linux apps
>> distributed as source give you that choice, which is setup as a normal
>> part of compiling the app for your machine.
>>
>
>With a properly configured installer I can write it to just about
>anywhere on Windows. Unfortunately one must live with the installer the
>CAD company furnishes.

Yup. But you're not seeing the point about not doing any damage to
the OS?

Know what modern windows do now? They keep each different version
of a .dll ever produced available on the OS disk, just so the program
works with the various toolchains they've released over the years.

If you're running Vista or Win7, do a right-click -> properties on
c:\windows\winsxs, where this madness resides on your hard drive.

On this win7 x64 box I type on, there's 42,421 files consuming 6.38GB
disk space, call that efficient, good, sane? Windows is falling apart
when they need this type of workaround to stay around. MSFT is simply
not able to draw a line in the sand and start at some new point.

I can install Slackware x64 complete with several desktops, application
suites and full compiler toolset on about the same space windows uses
just to perform its application fixups with.

Every time we Linux users update to a later version of out favourite
distro, we get a brand new set of libraries, and all the applications
are compiled against that know set of libraries. The windows binary
only plus backwards compatibility is groaning at the seams and only
practical because of the low price of memory -- but windows users pay
a performance price for that mess, which gets bigger and worse over
time.
>
>> The reason for compiling apps is that a machine might be big or little
>> ended CPU, different system libraries, shell, *BSD, Linux or Solaris!
>
>
>I don't want to compile :-)

Ahh, you really do want to run on automatic ;') Anyway, you don't have
to compile. That's why you use a distro, they compile most everything
for you, and large apps will provide a precompiled package (.rpm, .deb)
for the biggie distros, plus a generic binary tarball that'll work on
most distros.
>
>>>
>>>>> Meaning user libs and non-custom libs get splintered up. What's wrong
>>>>> with allowing write access to the lib directory?
>>>> Question is, which lib directory.
>>>>
>>>> The proper place for writable system libraries is /var/lib/$appname :)
>>>>
>>>> For example, my Slackware-11 box has:
>>>>
>>>> grant(a)deltree:~$ ls /var/lib
>>>> arpd/ bsdgames/ elm/ logrotate/ misc/ mysql/ nfs/ rpm/ stunnel/ xdm/ xkb/
>>>>
>>>> The program may create its own directory there and allow user access
>>>> and writing. It's difficult to find an exception to the standard
>>>> unix rules for basic layout (Sorry, I forget the exact name,
>>>> hierarchical file system or similar) that's been around for a
>>>> decade or more.
>>>>
>>>> Simple, no?
>>>>
>>> All I can say is that I asked in the gEDA group why I can't have the std
>>> libs and mine in one default place and the answer was pretty much, well,
>>> that I can't easily do that. And that I should just log in sudo.
>>
>> That's the windows solution, run as admin all the time. We don't do
>> that with Linux, it's bad for many reasons. And, by saying log in
>> sudo, sounds like that *ubuntu windows wannabe nonsense? Indicates
>> you don't compile the app (I guess it's commercial binary), thus have
>> no control over where it wants to keep things.
>
>
>This was said by hardcore Linux users. And yes, I am using Ubuntu.

Hardcore? Nah, just people who appreciate the difference between
a toy OS trying to grow up to be unix, and the 'real' thing. Even
Apple is running unix now (their 'new' OS is based on the *BSD code).
>
>
>>> But it didn't matter anymore anyhow because gschem bungles refdeses upon
>>> auto-annotate. That's a big no-no in CAD.
>>
>> I'm still trying to pick a freebie circuit and PCB CAD, only single
>> sided and two-layer through hole plated required. The eagle size
>> limit (80x100mm) is a wee bit small. No budget for CAD 'cos only
>> hobby level that might grow, into something. And, I'm on low income,
>> retired, sorta.
>
>
>Well, since you know Linux well you might want to look into gEDA then.
>It's ok for digital stuff, just IMHO not for hardcore RF and analog.

If don't do much RF, do some analog where I care about the layout,
and some digital where I care a little less about layout, and power
stuff that might be as bad as RF?

>There is a good newsgroup for it:
>
>gmane.comp.cad.geda.user

Okay, thanks.
>
>Another open source CAD that I think is even better is Kicad, which
>AFAIR comes in Windows and Linux installer versions. So you don't have
>to compile anything.

Compiling is not evil :) Can be time consuming for large apps though.

I compile small apps, as it takes about the same effort as installing
precompiled, and I get to choose where it goes.
>
>>>
>>>> Users may have private libraries under /home/username/whatever
>>>>> I don't want an OS to tell me what I can't and cannot do, just like I
>>>>> don't want a car to decide when to shift :-)
>>>> There are standards out there that define a framework for these things,
>>>> of course it is not rigid, as there's no Linux Incorporated controlling
>>>> this stuff. Each application author has a choice of what standards to
>>>> follow. A high end CAD system should follow the standard patterns for
>>>> flexible target OS. (I haven't used CAD for 17 years, no idea what's
>>>> what these days).
>>>>
>>> Well, I live with CAD for 24 years now :-)
>>
>> Last I worked in design, it was maybe 15-20% CAD for schematic and PCB,
>> then software to define the product, often variations on same hardware
>> for different product end applications. Then there was another product
>> 30-40k lines of assembler that I worked on, off and on for nine years
>> until the hardware was no longer produced. Started on cp/m box with 8"
>> floppies and ended on a win3 box with hard drive and 3.5" floppies...
>
>
>Wow, last time I saw 8" floppies was on a Racal Redac CAD system that
>ran on a VAX. But I couldn't get reasonable time-slots on it so drew my
>(large) schematic by hand.

Oh, my cp/m box was only for programming, we were still doing layouts
with tape and donuts back then -- by hand on over a 2x 0.1" grid on a
lightbox. But I was doing layouts like that for years, once or twice
did a red/blue double-sided layout, not so easy -- but the company had
lots of the red/blue tapes, so I tried it.

My first look at CAD was pcad, on a '286 PC-AT running at 6MHz, with
the full 640kB of memory (we had to import a 128kB full slot memory
card before the CAD program would load, boss bought the PC-ATs on
grey market before their official release in .au).
>
>>>
>>>> It's not about deciding when to shift, more about expecting the shift
>>>> to have a standard H plus extras (reverse and fifth) pattern (or paddles,
>>>> or gated semi-auto) and be roughly in the same spot (or two), within
>>>> reach of the driver.
>>>>
>>>> You know, standards, so many to choose from ;)
>>>>
>>> I don't care which place they are in, or which side the steering wheel
>>> is on. As long as there is no automatic transmission.
>>
>> Fair enough :) My current car is auto, first time, I think I prefer
>> manuals, that annoying delay, waiting for the transmission to decide
>> it's time to shift...
>>
>
>Wait until the road ices up, that when the "fun" begins in an automatic :-)

No snow where I live :) We do get some black ice. I had more fun
in the wet with my last car, manual with a limited slip diff :)

Driving in rain this morning, only problem was putting the foot down
too hard on accel pedal and losing acceleration, not enough to drift
sideways very far though. Just the usual surprise how slippery the
roads are when wet.


Anyway, compiling your own stuff on Linux is like driving a manual,
easy to do once you see how simple it usually is :)


But for large apps, a waste of time, they're usually a binary
install to sensible places, /usr/local (most common), /usr
(though might interfere with system), /opt/app_name (usually
freeform, outside the rules or conventions) and /home/username,
which is only good if there's no data or libs to be shared with
other users.

Stuff under /home/username is also restricted on what system services
it can access.

My, much OT writing here...

Grant.