My company went with Lynuxwork's BlueCat as our embedded Linux and continually regretted it. We had no Linux expertise and so wanted the professional services that was available from Lynuxworks along with their distro. However, we found that 1) we had a hard time getting them to honor our business priorities, and 2) the distro was based on a kernel old enough that we couldn't update to the latest releases of things to get bugs fixed. It would have been much better to hire a good Linux guy (which we ended up needing to do anyway) and going with a standard distro. The amount of support we could rustle up from the community and consultants was at least as good and sometimes better than the support from Lynuxworks that we were paying for.
Well I talked with him about a year ago or so. I shouldn't I talked with him exactly, as rather he talked at me. It was completely impossible to hold a conversation with him as he would talk and talk and talk and not acknowledge any of the usual social cues that the other person might like to get a word in edgewise. He talked right over every attempt to converse. Yet it was just him and me; it's not like he was playing to a crowd or anything. The part of it that I remember was that he was pushing his website with his podcasts.
It must be hard to work with someone that you can't communicate with. It must be hard to get past an job interview if you don't let the interviewer ask you some questions.
Part of evolution is adaptation to the environment. We are changing the environment (civilization, medicine, technology, etc.) far faster than evolution can react to it, so to speak, given the length of a human generation. We are seriously adapting the environment to us, rather than the other way around.
>...we neither have the time to fully document the code...
This is so totally untrue that it is sad the people still say this. Documentation is essential for both bug fixing and new features even if it is a one-person project that is going to last more than a few months. The time saved is enormous when you have to revisit code you wrote some time back. Not only in understanding the code but also to help not writing additional code that breaks previous code. And if there is more than one person on a project, lack of good documentation causes time and quality losses to go through the roof.
It does take a bit of discipline. A couple rules of thumb help tremendously: 1) code must be commented the same day that it is written, and 2) never check in code that's not documented.
Slashdot Mirror
Connections in the network sense and in the social sense.
My company went with Lynuxwork's BlueCat as our embedded Linux and continually regretted it. We had no Linux expertise and so wanted the professional services that was available from Lynuxworks along with their distro. However, we found that 1) we had a hard time getting them to honor our business priorities, and 2) the distro was based on a kernel old enough that we couldn't update to the latest releases of things to get bugs fixed. It would have been much better to hire a good Linux guy (which we ended up needing to do anyway) and going with a standard distro. The amount of support we could rustle up from the community and consultants was at least as good and sometimes better than the support from Lynuxworks that we were paying for.
This is a true groundbreaker. It is still alive here. Developed at Essex University in 1978 by Roy Trubshaw and Richard Bartle.
Well I talked with him about a year ago or so. I shouldn't I talked with him exactly, as rather he talked at me. It was completely impossible to hold a conversation with him as he would talk and talk and talk and not acknowledge any of the usual social cues that the other person might like to get a word in edgewise. He talked right over every attempt to converse. Yet it was just him and me; it's not like he was playing to a crowd or anything. The part of it that I remember was that he was pushing his website with his podcasts. It must be hard to work with someone that you can't communicate with. It must be hard to get past an job interview if you don't let the interviewer ask you some questions.
If the box is big enough, then you don't need to think outside it to have truly interesting experiences. Chris is building a bigger box...
Part of evolution is adaptation to the environment. We are changing the environment (civilization, medicine, technology, etc.) far faster than evolution can react to it, so to speak, given the length of a human generation. We are seriously adapting the environment to us, rather than the other way around.
>...we neither have the time to fully document the code...
This is so totally untrue that it is sad the people still say this. Documentation is essential for both bug fixing and new features even if it is a one-person project that is going to last more than a few months. The time saved is enormous when you have to revisit code you wrote some time back. Not only in understanding the code but also to help not writing additional code that breaks previous code. And if there is more than one person on a project, lack of good documentation causes time and quality losses to go through the roof.
It does take a bit of discipline. A couple rules of thumb help tremendously: 1) code must be commented the same day that it is written, and 2) never check in code that's not documented.
Their Whistler Music Synthesizer is a descendant of VocalWriter which has been around for more than 5 years.