Slashdot Mirror


Cygnus Announces "Embedded Linux Solution"

While I was unaware that this was even a problem, Cygnus Solutions announced EL/IX API which is "...a major step to pre-empt the fragmentation of embdedded Linux..." Essentially, it's an open source, configurable API that lets developers create software for embedded devices running Linux or Cygnus "eCos" OS. Standardization is a good idea, I suppose, and embedded seems to be the way the wind is blowing.

12 of 40 comments (clear)

  1. Cygnus by scumdamn · · Score: 2

    Cygnus is one of the premier open source companies. We're lucky to have those guys on our side. Before the Open Source phenominon took off the software company landscape was looking pretty bleak as far as ethics and idealism went, but now there are so many good companies producing high quality software, making money, and not selling out. It's truly heartening to see.
    Thanks, Cygnus, and keep the software coming!

  2. Fragmentation by Anonymous Coward · · Score: 4

    The problem is that most embedded systems has no MMU. I know Axis have made some linux implementations and I have seen other local companies advertising about a job to deal with these problems.

    Writing programs without an MMU to rely on is probably dependent on strict use of a good memory management system, and from what I have heard this is the main problem with linux and these applications.

    Patrik Carlsson

  3. Re:Not so good by J.Random+Hacker · · Score: 3

    I think that you mis-read the dispute. I understood the issue to be one of continued stability on the one hand (rms, et.al.) vs inclusion of new optimization strategies, better implementation of some increasingly important C++ features (and tracking the C++ standard), and the addition of some new front-end languages that required some back-end support on the other hand. What was appeared to be happening was that the changes to support things like a non-broken template instantiation mechanism were not being included in the 2.7.x releases, and 2.8 was taking *way* too long (18 months or so at the time of the initial fork IIRC).

    egcs gave the folks who wanted the new features a place to hack, and check their results. The egcs team has done such a good job with these enhancements, that they have become the GCC maintainers.

    I view this as a Good Thing.

    Let us judge this announcement on its technical merit, and on its openness and free(dom)ness, and leave personalities at the door.

  4. Re:Not so good by tiemann · · Score: 5
    Fooey! Here's my rebuttal:
    1. The relationship I have with Stallman is cordial. The last time he visited California (during the Linux World show in August), he called me, ask for help to support a cause, and I answered the call with an endorsement from Cygnus. Note that I could have wimped out and done nothing, or I could have said "it's ok to use my name, but not the name of Cygnus", but I went the extra mile to get our CEO and CFO to agree to participate in this action.
    2. It's very easy to talk a good free software story when you're preaching to the converted. Stallman and I share the experience of talking not to the converted, but to the skeptical. Stallman has taken one approach, that of the unapologetic idealist. This approach tends to polarize opinion and result in reporting that either brands him a saint or a lunatic. I take the approach of the unapologetic pragmatist, and that tends to lead to reporting that acknowledges the merits of the case. Either way, Stallman and I catch a lot of flames, but we catch them for different reasons. I'm glad that Stallman has established the position that he has...it enables me to work the field from a different angle.
    3. The splintering of the GCC compiler was due to the fact that Cygnus was able to build its development reasources faster than the FSF could build the infrastructure to deal with them. The fact is that when all was said and done, the splintering was healed, and the FSF has endorsed the steering committee that Cygnus helped to create, and now both Cygnus and the FSF are working on a common version of GCC. How many other open source project have you seen come together once they splintered? *BSD? Ha!
    M
  5. Stupid Q. by sTeF · · Score: 2

    Is it possible to let eCos run on my Handheld instead of WinCE?

  6. Re:Pre-empt Linux Fragmentation? by Capt+Dan · · Score: 2

    I think it's been posted here before, but there is a big difference between an honest to goodness news article and a Company Press Release. Which is what the cygnus article is.

    Of course the company will put a spin on their press releases. The better they sound, the more product they sell. Simple. But if this action helps out something like embedded Linux in the process, more power to 'em.

    You are correct that the stock kernels are missing some stuff. To the best of my knowledge, Linux cannot currently run inside a doorknob. Other embedded system can and do.

    And there are also other embedded systems that, for example, run Win95. I worked on one in college.

    --
    Sig:
    Barbeque is a noun. Not a verb.
  7. Pre-empt Linux Fragmentation? by Eric+Seppanen · · Score: 2

    Hey, I think Cygnus is cool too, but this just doesn't make much sense to me. The title of the press release is "CYGNUS ANNOUNCES EMBEDDED LINUX OFFERING; PRE-EMPTS LINUX FRAGMENTATION", and it's subtitled "New EL/IX API Enables Developers to Extend Linux into Embedded Computing Environments". There are two misleading statements here: first, that Linux is about to fragment and we need Cygnus to save us, and second, that Linux isn't capable of running in an embedded system right now. The first one is just plain stupid; that one's easy. The second one is a little more fuzzy.

    It's true that the stock kernels are missing some stuff that some embedded projects need. Maybe you need flash-disk drivers or real-time scheduling. And if Cygnus wants to jump in and provide these services, that's great (just so we all realize they're not the only ones). But a stock Linux kernel works great for a lot of embedded systems.

    The real point here seems to be building some kind of a bridge between Cygnus' eCos embedded OS and Linux, so that apps that are a little too heavy for eCos can move to Linux and keep a common API. That's cool, too. But this press release portrays that as the savior of the embedded-linux world, and that's just degrading. It makes me respect Cygnus a little less.

    --
    314-15-9265
  8. Very interesting. by Capt+Dan · · Score: 4

    So I just skimmed the eCos whitepaper which can be found linked from the eCos page For those of you ho are unfamiliar with how embedded systems are designed/work/react this whitepaper should be informative. From the quick glance I gave it, eCos seems quite nice with the key feature being POSIX compliant. eCos seems to implement a process model where POSIX threads are also available. Thank God. I've been getting tired of this holy war going on between the process based embedded systems camp and the thread based embedded systems camp.

    I think that the point that should be made is that while Cygnus will be supporting work for both eCos and embedded Linux, eCos is their baby. Now before someone gets all huffy and ticked off, note that eCos is a real time embedded system, and Opensource. And when it comes to embedded systems, designing real time into the kernel is a major boon as opposed to something like rt-linux where linux is essentially run as a process of a smaller real-time kernel (yes, that is an oversimplification, but basically true).

    Quite frankly, I do not see embedded linux being able to run inside a doorknob anytime soon, there's a lot of work still to be done. eCos already has that ability, and according to the whitepaper Linux and gdb can be used as the development platform. The real point is that all the reasons I have heard of for wanting embedded Linux, seem to be embodied in eCos. POSIX compliant, open source, real time embedded system.

    Ahem. Go Cygnus, go Cygnus, go Cygnus, go. (Insert cheerleaders and dance routine here)

    Now all we need is support for broadband multimedia to take the settop box market away from CE. The fact that CE is pretty much guaranteed to have directx and realaudio/video is a *major* selling point.

    And if you don't like what I had to say about embedded Linux, you know what you can do? Go code it. Get its development going that much faster.

    --
    Sig:
    Barbeque is a noun. Not a verb.
    1. Re:Very interesting. by shambler+snack · · Score: 2

      *laughing out loud*
      This reminds me of what Java/Sun went through to get Java back into embedded systems. Original Java was way to big to fit in the proverbial doornob (or JavaRing, in their case), so they backed up and gave us several leaner versions targeted for small machines.

      As far as DirectX and RealAudio/Video, what open standards-based technology exists that has equivalent serious capabilities of those two that could be incorporated into eCos and/or Linux?

      I've glanced at eCos but never had the time to give it much review. Think I'll dig a little deeper. Thanks for the insites.

  9. Rob is *no* idiot by Mads-Martin · · Score: 2

    If Rob Malda feels that ./ is not yet mature enough for OS - then it's 100% ok.
    If Rob Malda never want's to make ./ OS because he want's money for it - then it's 100% ok.
    If Rob Malda's coding abilities sucks and he is ashamed of them - then it's 200% ok

    Why is it so hard for the Open Source community to accept that not everyone want to release their products as OS? If people want to go OS, then it's a great thing, but if people don't, then we should accept it and let them be commercial or whatever their desire is!!

  10. Ecos/Linux embedded not suitable - GPL sealed fate by AaronW · · Score: 4

    I researched replacing our current product with VxWorks to use either Linux or eCos. Neither would be an effective solution. eCos is far too limiting. The last I checked it didn't even have TCP/IP support, nor support the Mips processor (which is extremely popular for embedded environments [eCos does have an eval version for the NEC VR4300]). Another problem with Linux is the GNU public license. In an embedded environment it is often necessary to hack the kernel or pieces of it to do what you need.

    I found RTEMS http://www.rtems.com is an excellent solution. It is open source and has the latest BSD TCP/IP stack. The license also allows us to hack up parts of the kernel without having to release the source code back.

    For our current product, any RTOS we use we need to make some custom changes to the TCP/IP stack (which involve changes that would NOT be of benefit to the open source community unless the company wanted to compete with us). The eCos license would let us do this, Linux does not.

    Don't get me wrong. I support open source and feel that any changes that enhance a product, fix a bug, or whatever that are not proprietary to one specific application certainly deserve to be released back to the community.

    Another problem with the Linux kernel is that it is far too bloated. It would take a lot of work to bring it down to size. For example, everything we have is in flash. There is no file system. Our current image, symbols and all, is around 1.25MB compressed (using Zlib, which incidently is much faster than Gzip). We have a lot of code and not a lot of room. Having a small kernel is often necessary. We don't need a file system, virtual memory, security, loadable modules, or many of the other features of the Linux kernel. In fact, due to the fact that everything must be physically linked to the kernel, this totally rules out Linux. The 1.25MB is EVERYTHING, all of our code, protocol snooping, debugger, routing, console, SNMP, and firmware for supporting a second CPU (which runs our custom RTOS which is only a few pages of code).

    eCos and RTEMS fill the void nicely in that one can pick and choose which features get compiled in. Unfortunately eCos is missing some very important pieces (i.e. TCP/IP).

    VxWorks is a pain in the *ss since it has numerous bugs (i.e. improper cache operation on the NEC VR4300 CPU) and has terrible support (after paying thousands of dollars a year it's not unusual to have to wait weeks or months for a response). Not only that, but we had to buy their networking source code which costs many thousands of dollars (it's mostly just the BSD 4.3 TCP/IP stack, nothing special, and various daemons).

    I am seriously looking at moving to RTems in the future. They have always responded promptly and have the features we need. My boss was all for Linux until I told him about what was involved to use it, and the GPL immediately killed it.

    If we do move to RTems, I would certainly make a number of the changes we would make available back to the source code, but there are a number of others that we cannot release (since there's competition).

    --
    This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
  11. The major problem with running anything on Hand... by mattz · · Score: 2

    ...helds is getting a bootloader. There is some substantial progress towards a bootloader for a linux implementation on the MIPS wince handhelds--it's at linuxce.org

    --
    Remember this...no eternal reward will forgive us now for wasting the dawn....(jim morrison)