|
in reply to (jcwren) RE: RE: why i may have to leave perl...
in thread why i may have to leave perl...
My home node says my beliefs about criticism, and this rant
just went into the list of links I keep there. Perl is
not and never should be all things to all people. Indeed
anything that sincerely tries will fail. And some of your
points I have said before and will again, for instance in
Re: FS OS sysprog I pointed out that Perl is bad for kernel
programming.
I do disagree on some things though. Linux is not actually
a bad fit for a lot of the embedded market. Sure, at the
very bottom end it doesn't make sense. But betting against
it is IMO betting against Moore, and Moore has a few years
yet to run. Plus as soon as you want an embedded device
that is able to network using standard protocols, you won't
wind up with requirements much below Linux' and guess which
is less work?
As for memory mapped devices, it is possible in theory but
the same hiding of details that makes Perl so easy to
develop in makes it hard. OTOH take a look at
IPC::Shareable and you see that Perl can be taught to be
careful with what it does after all.
There is just one point I would like to wind up with. And
that is that there is a very good reason that Perl doesn't
work like a lot of other languages. Most people who think
about maintainability start with the idea that they are
going to keep a large project under control. In saying
that they have already lost sight of the fact that the act
of keeping something short and sweet makes it easier to
maintain. Perl is a master of that school of design.
In order to be that, Perl goes out of its way to be
expressive, emulates a way of thinking that people find
natural, concentrates on simplicity of interfaces to a
relatively small number of important concepts, and in
general finds reason to break most of the classical CS
rules. But in the end it works! The classical CS people
are right that you wouldn't want to maintain many Perl
programs with 30K lines. OTOH what takes 30K in C will
take an order of magnitude less in Perl - with better
debugging information yet!
Not to mention fewer buffer overflows... |
(jcwren) RE: (4): why i may have to leave perl...
by jcwren (Prior) on Nov 09, 2000 at 21:56 UTC
|
I was just going back through a few old nodes, re-reading the good stuff, and came across something here. (This is from the node that this node is a reply to, by tilly.)
I do disagree on some things though. Linux is not actually a bad fit for a lot of the embedded market. Sure, at the very bottom end it doesn't make sense. But betting against it is IMO betting against Moore, and Moore has a few years yet to run. Plus as soon as you want an embedded device that is able to network using standard protocols, you won't wind up with requirements much below Linux' and guess which is less work?
While Moore does say we get faster systems on a fairly regular basis, there is more to an embedded system than just the CPU speed and architecture.
One of the issues is an embedded systems is the number of connections. PCBs (Printed Circuit Boards) are costed by several factors, some of them being the material used (typically FR-4), the number of square inches per board (board area), the number of vias and pads (the pads are for integrated circuit pins, and vias are used when a trace has to make a transition from one side of the board to the other), and the number of components.
While Moore may double the horsepower, if the number of connections and interconnects aren't reduced, the product price can't go down past a certain point. A typical rule of thumb for board costing is about $0.06USD per pad/via in medium quantity runs (5K to 50K). After you've added up all the pad and via costs, board space, packaging requirements, and cost all the required ICs, you may find that no matter how much you want to run Linux on a board, you can't get the underlying fixed cost down low enough to make a product viable.
I am, in fact, in the middle of such a quandary. I'm looking at doing the software side of a project involving vehicle location and performance dynamics, and my hardware friend (and I) want to wind up with (as a result of our development for the customer) a platform that we can use on other projects. We can go buy an off-the-shelf PC/104 system, but they're way over priced (I'll address that at the end). If we develop our own hardware, we own all the technology (schematics, layout, etc) for it, and can produce additional boards at a pure manufacturing cost (as opposed to an aggregated design/mfg/support cost).
Sadly, embedded Linux is not looking viable. The two major players, BlueCat and etLinux still have memory footprint requirements that make them impractical for a system with 2MB of DRAM, and 1MB of FLASH (actually, it'll fit in the FLASH fine, but the uncompressed image kills us).
Whereas, I can buy (for a lot more money) lynxOS, OS/9, vxWorks, etc that will easily run in the memory requirements. These companies have different licensing requirements (vxWorks is $50K, and isn't in the market, OS/9 is lot more reasonable) that affect the total project pricing.
Now some of you will say "But 2MB or 6MB more RAM is cheaper than the per license requirement!". How true. It would be far cheaper to put 8MB on the board, and run embedded Linux, than it would be to use vxWorks. But this means we're now raising the fixed cost point of the hardware to support 8MB on each and every board, to run a free O/S. Yes, it's open source, but if I buy OS/9, I get technical support (and very good technical support, I might add. Most of these OS vendors have good support departments). I may be able to fix problems I find in any OS components, but then I reduce my time to market by chasing down demons that I may or may not be able to fix. Whereas, I pay them, it gets fixed. If I have a wide time to market window, then this may become acceptable. Also, the documentation for embedded Linux is still far behind the commerical embedded OS products.
This is not a rant against Linux, embedded Linux or open software. It's a matter of market economics, where sometimes, it's better to pay someone else to take care of certain problems. There are plenty of projects that need heavier duty CPU power than a lot of projects I work on, and embedded Linux is a natural fit (Tivo being an excellent example). But for the price window we need to hit, and the fact that we don't have a large development time window means we're probably going to wind up going with a embedded OS vendor, and probably OS/9. Maybe next time...
On the topic of why somethings cost more than you think they should: Consider a company that makes amateur radios. A typical mobile (one for the car) amateur radio transceiver runs about $500USD, average. That's a lot of bucks. However, Yaesu, Icom, Kenwood, et al have to pay for the cost of development, manufacturing, distribution, advertising, etc, amortized across a comparatively small number of units (say, compared to selling a particular model of a VCR). Whereas the technology in a PlayStation 2 is more sophisticated, you're selling a helluva lot more units. Same applies to software. Company X sells package Y for $Z, and $Z has to pay for the janitor that cleans their bathrooms, the marketing exec, the development cost, shrinkwrap, lawyers, etc. There's a lot of "hidden" cost in that package you pay for, and if they don't sell the software, they still have to feed the people that work for them. Open Source and all that aside, keep that in mind next time you wonder why something costs so much for something that seems so "simple". Consider all those hidden costs behind it, and what the volume of product they have to ship to be an economically viable company is.
--Chris
e-mail jcwren | [reply] |
|
|
Choose the right tool for the job.
Linux works in a lot of the embedded market, but certainly not all. It sounds to me like you have done your research and found it didn't fit for you. However over time I think you will first of all find that the minimum requirements for embedded Linux will fall a little more, and the fixed cost of meeting those requirements will fall a lot more.
Therefore even though you are not choosing it now, you have every reason to believe that in a couple of years you would be likely to make the opposite decision. And that raises a couple of very interesting issues.
First of all Linux support. Anecdotal evidence is that technical support for Linux is very good. There is reason to believe that it will get better since as the embedded market matures that will be all that really differentiates the vendors.
Second of all what is the future of vxWorks et al? You are depending upon support for them. But Linux is looking to eat away their current revenue base, and you have to ask questions about what new markets they have. History says that when companies run into financial crunches, they tend to start trying to cut back and quality suffers. I don't mean to spread FUD here, but think about what timeline you expect to need support over and whether you think that the vendor you are dealing with will be able to give that support. This is a sad decision that you need to make quite often in software and in business in general.
Thirdly there is a lot of misunderstanding about the entire, "You can fix problems yourself" facet of Open Source. Yes, you can theoretically fix problems yourself. That doesn't mean that you should. As Bob Young likes to comment, buying proprietary software is like buying a car with the hood welded shut. We buy cars with hoods that are not welded shut. There are a lot of good reasons to do so. One of the best is that we then get a competitive market in auto-mechanics. And in fact companies like LinuxCare are willing to take contracts to fix problems in open-source software. (Specifically in the Linux kernel.)
Now I don't say that after all of this you will decide on Linux. In fact in your case you may well not. But long-term, for a fixed need, betting against Linux in the embedded space is IMNSHO stupid. However short-term, for a fixed use, it may well be insane to go with Linux.
History shows that in computers, the commodity wins. History also shows that in computers, the commodity is often not the best choice to make at a given point in time. :-)
| [reply] |
|
|
I agree that Linux will probably become more and more viable for smaller platforms, in the future. This can really only achieved by better modularization of various components. Most embedded OS kernels are highly modularized, down to 'Do you want threads or not', or 'Does the PPP include auto-dialing' levels.
This is where Linux is behind, at the moment. BlueCat and etLinux are steps in the right direction. And believe me, I would *love* to run an embedded Linux kernel on this project. I have no qualms about developing under it. But this is where these kernels excel, is that they've become very tuned over the years. LynxOS (from LynuxWorks) claims that a minimal (non-TCP stacked) kernel can run in 33K. I built a minimal BlueCat kernel, and it wouldn't boot in 2MB (kernel went through signon, but somewhere near the last step, it just has a seizure, and doesn't indicate why. Feeding it more memory solved the problem.)
You're also correct that I can buy service contracts through third party shops. However, the cost of this option is moderately comparable to the recurring support contracts that Microware, WindRiver and others charge. If you are talking to a customer, it's easier to tell them that "Yes, we get the OS, support, and licenses, etc all from the same company.", rather than "Well, we go here for this, there for that, another over yonder to do something else." Customers, as a rule, like cohesive solutions.
There are several dozen embedded OS vendors in the market (Kadak, Treck, Microware, WindRiver, pSOS, many more). All have different capabilities, marketing strageties, and cost/performance curves. Some will inevitably go out of business. One could argue that if the embedded Linux distro that you're dependent on stops being supported, you're in a similiar (but not as bad) situation. My solution has been in the past to write into the contract that we get full rights to any products we buy, should the company go out of business. We had to cancel one contract with an OS vendor at the last minute because of a failure to agree to escrowing it. Linux, of course, really doesn't have this problem, but if you're reliant on the support for the distro, you have to figure out what it takes to port to some other release, and how customized the kernel and everything is. There are less hassles, legally, involved, but it's a time sink any time you have to deal with this crud.
I consider it unlikely that many of the larger OS vendors will go out of business anytime soon. One of the reasons for that is platform diversity. Linux runs on far fewer platforms (at the moment) than OS/9 does, for example. Also, the knowledge base built into those companies, as far as embedded systems goes, is phenominal. I would have to speculate that most shops that are supporting embedded Linux have a smaller knowledge base regarding embedded system support (not skills, tho) than Microware does (who's been doing this for over 15 years).
So no, I'm not going to bet against Linux in any way imaginable. I'm disappointed, if anything, that we won't be using it on this project. But I'm not betting on Microware, WindRiver, or pSOS blowing away anytime soon, either.
--Chris
e-mail jcwren
| [reply] |
|
|
