I have been developing embedded systems for over 20 years and I have never seen the need to upgrade the OS. Never! The beauty of an embedded system is that the user does not see the OS and really does not (or should not) care what it is. You are going through a development cycle and if you do your job well, you will be fixing most problems during the development cycle before the first release and immediately after. Over the years, you will be in a maintenance mode and you will only be fixing some functionality problems.
You will NEVER want to destabilize your product and have significant retesting by upgrading the Kernel or OS. Why? What new features in the OS matter to your customers? After all the OS is not your product and the customer should not care. Keep in mind that the OS vendors will be trying to get you to distribute upgrades, but resist the temptation. You will be spending money for no reason.
When you need to develop phase II of the product, its a different ball-game. Then you can use a new version of the OS, or a different OS. The point is, you are not "upgrading" your kernel, you are developing an evolution of your product on a new OS. Different mindset.
Re:This is a great book for implementors
on
Implementing CIFS
·
· Score: 1
Simple. Its the same reason I buy CDs when I like the music (not that I use filesharing anyway). Its the right thing to do.
This is a great book for implementors
on
Implementing CIFS
·
· Score: 4, Interesting
I read this book on Chris's web site even before it was published (yes, I have bought a copy) and it was an invaluable guide for me as I wrote a CIFS implementation. The book is fairly easy to read, even though it is highly technical. What it does cover, it covers extremely well.
However, I did need the sniffer method of reverse engineering for much of what the book did not cover. One complaint I had is that I needed more information on the higher level protocols such as LANMAN for handling printer queues and this information was either non-existent or schetchy in the book. Although the book is long, much of it is taken up by a CIFS document which you could download for free on the internet. So I do think that the description part of the book could be more extensive (Sorry Chris). Maybe in the next revision.
You might ask why I was implementing CIFS from scratch? Its a valid question, since Samba would/should be anyone's implementation of choice. I did it because we are developing a printer which is not GPL (and unfortunately not based on Linux). We are not using any GPL code in it, and so this was really the only choice besides buying it from someone (but where's the fun in that). I am planning on releasing this code under a BSD license, but it's not ready for prime time yet and I need to get back to it (in a couple of months).
So this was a really good book for CIFS implementors, but how many of those could there be?
I just came back from touring the exhibit hall. I had heard that Linuxworld was bigger this year, so I had been looking forward to going, but I was disapointed. The majority of the exhibitors were pushing products and services aimed towards enterprise server computing. That was it. Where was the embedded stuff (Montevista or Lineo)? Where were the desktop applications? I even have to ask where the distributions were. I saw SuSE and Red Hat. What happened to TurboLinux or Mandrake? Even the new guys like Lindows did'nt show up.
They need to rename the show LinuxEnterpriseWorld.
Slashdot Mirror
I have been developing embedded systems for over 20 years and I have never seen the need to upgrade the OS. Never! The beauty of an embedded system is that the user does not see the OS and really does not (or should not) care what it is. You are going through a development cycle and if you do your job well, you will be fixing most problems during the development cycle before the first release and immediately after. Over the years, you will be in a maintenance mode and you will only be fixing some functionality problems.
You will NEVER want to destabilize your product and have significant retesting by upgrading the Kernel or OS. Why? What new features in the OS matter to your customers? After all the OS is not your product and the customer should not care. Keep in mind that the OS vendors will be trying to get you to distribute upgrades, but resist the temptation. You will be spending money for no reason.
When you need to develop phase II of the product, its a different ball-game. Then you can use a new version of the OS, or a different OS. The point is, you are not "upgrading" your kernel, you are developing an evolution of your product on a new OS. Different mindset.
Simple. Its the same reason I buy CDs when I like the music (not that I use filesharing anyway). Its the right thing to do.
However, I did need the sniffer method of reverse engineering for much of what the book did not cover. One complaint I had is that I needed more information on the higher level protocols such as LANMAN for handling printer queues and this information was either non-existent or schetchy in the book. Although the book is long, much of it is taken up by a CIFS document which you could download for free on the internet. So I do think that the description part of the book could be more extensive (Sorry Chris). Maybe in the next revision.
You might ask why I was implementing CIFS from scratch? Its a valid question, since Samba would/should be anyone's implementation of choice. I did it because we are developing a printer which is not GPL (and unfortunately not based on Linux). We are not using any GPL code in it, and so this was really the only choice besides buying it from someone (but where's the fun in that). I am planning on releasing this code under a BSD license, but it's not ready for prime time yet and I need to get back to it (in a couple of months).
So this was a really good book for CIFS implementors, but how many of those could there be?
They need to rename the show LinuxEnterpriseWorld.
What a world. What a world.