I used KiCAD recently. I overcame the unchangeable drawing frame problem by plotting to DXF without the frame, then inserting my own frame around that in DraftSight (A free ACad-ish program). The only problem was that I had to scale up my template by 11,000 or so to get the A-size schematic to fit my (AutoCad) A-size template.
-- Peter Bennett, VE7CEI peterbb (at) telus.net GPS and NMEA info: http://vancouver-webpages.com/peter Vancouver Power Squadron: http://vancouver.powersquadron.ca
Sure! Now think of things like libqt -- how much of it do you think is *not* used in an application with a graphic interface? If your app doesn't use OpenGL, you can *conceivably* not need that module -- unless, the developer of some other module that you *do* need happened to draw on some bits of code from it.
What about the litany of libs for KDE (for those apps that opted to go with a different GUI)? Or, GTK?
Or libreadline, libc, libm, or any of the DOZENS of other libraries routinely used in core applications/services.
It's not just storing the "quiescent (disk) image" that you're concerned about. When the program is loaded, the entire image occupies memory (for the CODE segment as well as any DATA needs of the various parts thereof... even if the user doesn't *invoke* any of those pieces).
[technically, only the portions accessed need to be faulted into memory. But, you still have to plan for ALL of it to potentially be available -- even if some other application is using the exact same copy of the library currently! With lots of common libraries, chances are, there is a lot of this going on at any given time.]And, who keeps track of which libraries are statically linked into which executables so that when a bug *is* uncovered, you can swap in the new library *without* having to rebuild every thing that uses its predecessor, *test* them (to make sure nothing has broken in the process) and/or back-out the new library in favor of the old?
If you are security conscious, chances are, the exploits that you are vulnerable to are embedded in your libraries moreso than in the "application code".
[I avoid the security exposure by simply keepping most of the network "unrouted"]Who decides what gets linked static and what gets linked .so? Do you create a custom distribution for each user's needs? Do you build a tool that lets each user declare how each of his binaries are built so he can easily determine what is required of him when a bugfix/update is available?
E.g., I count on /bin and /stand to be static executables. Because I want them to be runnable with /usr/lib not mounted! Just a simple matter of being able to recover a crashed partition without having to boot a live CD for the repair tools...
I'd rather use my RAM for data than multiple copies of the same pieces of code -- even worse, to have to pay the price of paging that out to disk to make room for yet *another* copy of the same piece of code (since the OS has no way of leveraging the static linked copy of one instance against another instance).
But, then again, I tend to run my workstations with only 4-8G of RAM so YMMV.
[...]
Me too. Debian since 2001.
-- John Devereux
Hint: regression testing. Despite the maker's good intentions new versions of libraries often break things that (unintentionally) rely on a 'bug' or certain behaviour.
Downloading is not an issue at all. Even a 3G connection offers fast downloads.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
As long as you're OK with using whatever the current fashion is, and don't mind e.g. switching editors when one goes out of favour with the Great Library Maintainers In The Sky, go for it.
I'd far rather have my software continue to work. And if anybody can hack my machine via my text editor or electromagnetic simulator, he's a better man than I am, for sure.
I very rarely get anywhere close to filling up RAM, even on my preferred old laptops that only have 2G. Have you actually done any profiling to back up your claims of extreme code bloat?
Cheers
Phil
-- 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 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net
Those programs do run under Linux. But in my shoes you'd likely get stuck pretty soon. At least when I started using my PC-controlled receiver for EMC work the required control software only came for Windows. There were some drivers for Linux but you'd have to painstakingly write all that software from scratch AFAIR. No thanks :-)
-- Regards, Joerg http://www.analogconsultants.com/
gEDA works quite well, at least the schematic editor that I tried. Just not for hardcore analog stuff.
-- Regards, Joerg http://www.analogconsultants.com/
Ok, but you probably do not design circuitry for aerospace or medical where such tricks are very much frowned upon by auditors. If you put an iron-clad process in place that supposedly prevents document screw-ups they might let it slide. However, they will then likely be on hightened alert for the rest of the audit. Just like if the taxman finds a deduction he thinks is fishy but the taxpayer can prove as borderline legit.
-- Regards, Joerg http://www.analogconsultants.com/
Well, yes, but as far as I'm aware they haven't changed what the page template looks like in years now; realistically at this point they couldn't do so with major user outrage.
Yep. What they *could* do -- and I think that patch someone referred to here might do this -- is to simply let you toggle the bloody built-in drawing code for the template on and off programmatically. Over time you make "off" the default as you add facilities to let users draw their own templates as "normal" schematic objects that would be stored in the schematic file.
It was probably more of a "quick hack" to get a template in there when they didn't yet have the tools to let you draw your own, I expect. I would imagine a good case study of how such quick hacks often take on a life of their own over time!
Yeah, I meant to write something like "small handful of application package types" or somesuch. Your verbiage looks even more correct. :-)
Yes, Phil and others have made it quite clear to me that .deb/.apt aren't quite the panacea of software installation that I had been thinking. The usual case where just a little bit of information on my part proves dangerous...
Still, many distributions should still only "count as one" -- Ubuntu, Kubuntu, Lubuntu, and Xubuntu are the all going to use the same paths other than the GUI bits (Unity, KDE, LXDE, and XFCE respectively), for instance.
I agree. Usually people pronounce some philosophical difference to rationalize Yet Another Distribution, but I suspect that we're often talking about smart, energetic, younger guys here who find it easier to tackle the technical problem of creating a new distribution (indeed, it might almost be viewed as a rite of passage) than going through the drawn-out, potentially political process of trying to get their otherwise-favorite distribution "fixed" -- or come to the realization that, you know, maybe the 99% solution really is "good enough" in the grand scheme of things.
There are people actively working on making Linux less fragmented, however -- these guys are the ones I've heard of:
---Joel
Nah, there are several reasonably respectable (i.e., reasonably "polished") and powerful SDR programs for Linux out there, and (as with Windows SDR programs) they're written to accept "plug-ins" to support different hardware front-ends... so with SignalHound providing the Linux drivers, you usually only need a very small amount of glue code, and you're good to go.
From looking at their web page --
Exactly. It just doesn't seem to make much sense to hard code that sort of thing. Just build different "frame symbols" (for various page sizes) and different "title block symbols", etc. Then, let the customer use those -- OR, create his own using the "symbol editor".
I.e., they don't *force* resistors to look a certain way, do they??
Again, I just can't see how this is quicker than telling someone on staff to "draw up a title block symbol", etc. Presumably, they can extract attributes/fields from symbols (part number, location, value, tolerance, etc.) so what's the big deal about having "company name", "design name", etc.?
The BSD's use the "pkgsrc" collection (I think it even includes support for other OS's).
"Packages" are offered in source form or precompiled for a particular target. Of course, if you chicken out and take the prebuilt option, you have to live with whatever "configuration options" the builder chose as appropriate. E.g., the binary might not have certain features enabled. Or, might rely on other packages that you hadn't intended on installing, etc. And, of course, the binary et al. have to reside where the builder decided it should!
The BSD's avoid this by not bundling a desktop with the OS itself. You can elect NOT to support X at all. Not to include the standard software development tools. Not to include man(1) pages, etc. You can really squeeze a release down to very tiny iron -- FreeBSD used to *officially* support a 5MB 386sx (!) configuration (that could thrash like hell if you ever tried to beat on it)
NetBSD opted for the "runs on anything" philosophy. And, made architectural choices that would ensure the code tried to remain decoupled from the hardware. I.e., if a certain feature was only available on one platform, they would try NOT to rely on that feature to implement some aspect of the OS.
OpenBSD opted for the "security" philosophy. Trying to ensure they never released a version with obvious exploits (a bit of smoke and mirrors, here). It also tried to mimic NetBSD's "multiple platform" approach. OTOH, I think there were also some "personality" issues involved.
FreeBSD opted for the Linux-wannabe philosophy (no apologies... I callz 'em like I seez 'em!). Sticking with just the i386 target, initially, and putting on blinders to design decisions that might, later, bite them when/if they tried to support other platforms. It was only later, "once established", that they started thinking about moving into other targets.
I started with NetBSD 0.8 in ~1993. Prior to that, I was running an AT&T flavor on a "coprocessor board" -- just using the PC as an "I/O processor" (remarkably responsive for that era!). But, found there were too many little things broken/missing -- no doubt a result of the relatively small "core" developer group trying to address multiple targets in lock step (a *BSD release for *any* target applies to *all* targets! And, the OS is more than "just the kernel" -- Linux.)
So, I switched over to FreeBSD (0.9) as they were making more headway without the multiple platform issue diluting their efforts (so many folks have PC's, why bother supporting Sun2, Sun3, Sun4, etc.).
When the quality of the releases started suffering (IMO), I moved back to NetBSD and have been there, since.
Of course, I just use it as a *tool* so care nothing/little about the zealotry that the fanboys seem to exhibit. I also use Solaris and Windows -- as each gives me support for a special set of tools that aren't easily available in the other OS's.
Sheesh! All that effort serving only as a "distraction". And, they wonder why taking the desktop from MS seems so elusive a goal. By the time they sort it out, the desktop will cease to be an issue! Google *almost* has the right idea with replacing the desktop with the browser. Of course, that brings us full circle YET AGAIN (is this the third or fourth time??) as we return to the "central computer plus terminals" model... :-/
Yup. Many years ago I had hacked a test suite for a bit of military kit we were building. Certain portions of the acceptance test just took *hours* to run -- and we already knew those subsystems worked reliably. So, I patched the executable to just skip over them.
Previously, when we were still debugging those subsystems, I had patched the executable to display "Go for lunch" as a reminder to folks that this part of the test was a lengthy one (the test suite didn't give you any a priori indications of how expensive certain parts were... you learned that by experience!).
Prior to "sell off", I had reintegrated (repatched?) the complete test suite so that we were sure *everything* was working prior to contacting the customer.
An hour into the certification test, "Go for lunch" appeared on the screen. Customer's representative -- whom I had befriended over the many months we'd had the project -- just looked at me (as if to say, "No doubt this is something *you* did?"), shook his head, hit HALT and pulled a clean copy of the test suite out of his briefcase.
Of course, it was a harmless error on my part and not an attempt to defraud -- as the passing of the "unadulterated" test proved a few hours later. But, the incident got written up, regardless :<
The Signalhound would not be a big problem, although I do not know whether the Linux version of their SW is up to snuff. Personally, I really do not want to have to be writing glue code. With Windows I don't have to do that, I can jump right into the EMI case and be productive.
Unless something has drastically changed in SW support the Icom R-1500 has no Linux control software at all. I need that receiver for really tough cases where the Signalhound would choke.
-- Regards, Joerg http://www.analogconsultants.com/
Agreed. Why this wasn't deemed feasible historically I couldn't tell you -- although I wouldn't be surprised if, e.g., version 1.0 wouldn't let you have attributes on any old object, so the title block was "special" in that it did support them or whatever.
(Speaking of attributes... one of the things that really annoys me in Ansoft Designer is that user-created schematic symbols can't access many of the "magic" [dynamic] attributes, such as @ID to retrieve the symbol's reference designator. I've never gotten a straight answer out of them how it is that they can create symbols that are much more useful/robust than any I might create because of this; IMO a CAD program shouldn't come with library components that are more powerful than what a user can create themselves.)
Thanks for all the information on BSD!
---Joel
Yeah, understood. Don't worry, though -- I'd predict someone will choose to do so in the next year, so you won't have to. :-)
The main problem there is that Icom never published the USB protocol though (and actively declines providing it to those who ask), isn't it?
There's already an option to print/plot the schematic without the template. On the Print dialog box "Print sheet reference and title block" and on Plot it's "Print page references."
Easy enough to plot to DXF and suck it into CAD to add a custom frame and title block around the "naked" schematic but it is an extra step. It's also quite understandable why, in cases like Joerg's, that step is a big no-no.
As you point out, it should be easy enough to extend that to hiding the default title block in the working page.
-- Rich Webb Norfolk, VA
Because the developers didn't think through their design completely! I.e., *why* is "foo" special? What INHERENTLY makes it so? Why can't "bar" also be special in a similar way?
So, they come up with two pieces of code that handle two different types of objects differently -- instead of thinking about how much of that is "common" to both. (Or, if both are, actually, *similar*!)
E.g., DASH/STRIDES treated symbols differently from schematics. And, hierarchical schematics as yet another sort of beast. Why not a single, *unified* "element editor" that can be applied to create a symbol -- within a schematic -- in EXACTLY the same way that a schematic appears to be a *symbol* inside a hierarchical schematic? They are conceptually the same so any code that doesn't apply to all is "unnecessary effort" (and a potential source of problems)
(There are arguably efficiency concerns that have to be considered. OTOH, resources always get cheaper. But, maintaining multiple "similar" implementations is something that needs human involvement.)
Ok, but for business I prefer a solution that is on a documented R&D path and supported by a real brick&mortar corporation. This is not to say that this is always a guarantee for good stuff. However, my experience has been that in most cases this is an advantage.
Another point is that many of my measurement results go into formal reports so it is kind of nice that I can base that on released software. Especially with SDR it is kind of crucial because much of the processing is being done on the computer and not in a DSP. That's how they got the power consumption of a Signalhound down to around two watts.
Yes. I believe that is a mistake on Icom's part. But t'is what it is. The R-1500 is a dang good receiver and probably not very useful on a Linux computer.
-- Regards, Joerg http://www.analogconsultants.com/
Seems the OS itself can have bit rot, too. Some time early last year my Ubuntu just went *PHUT* ... lights out, gone, would never start again. Since the whole thing is (for Windows) inside a big blob on the hard drive I can't tell what went. Oh well.
Is bit rot similar to dry rot? Then maybe I could use some of the leftover Rot Terminator from ACE hardware :-)
[...]-- Regards, Joerg http://www.analogconsultants.com/
I've had that happen with Windows too.
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 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.