What wasn't clear from the post is both missions (Dawn and Kepler) were both successful and lasted well past their intended mission lengths. Specifically, Dawn was finished over a year ago, and at that point they decided that they'd continue to collect data until the fuel ran out - which happened yesterday. Kepler lasted well over twice its designed mission lifetime. Again - "it still works, so we'll use it until the fuel runs out".
Kepler ended up surveying over 500,000 stars and has detected greater than 2600 planets. The data collected will be continued to be used for decades to come to find more planets and other information about the physics of planetary system development. The successor to Kepler, the Transiting Exoplanet Survey Satellite (TESS) was launched in April and just had first-light a couple of months ago.
Dawn was successful as the first NASA probe to use ion drives which let it enter and leave the orbits of the two asteroids. It successfully made maps of both bodies as well as detailed spectroscopic maps in both the infrared and visible spectrums.
Both missions did excellent science, outlived their planned lifetimes and should be celebrated for it.
It should come out to a cost-benefit analysis for you and your family. I'll explain my family's decision to bank my son's cord blood and then try to give you an idea of what you might want to think about in your case.
When my son was born, we did bank the cord-blood. But I'm under no illusions as to any potential benefits.
My wife has a nephew with Cystic Fibrosis. He has no siblings, nor is likely to have any. There is a slim chance that a treatment might be developed within his lifetime that could utilize stem cells from cord blood, and a slim chance that our son could be a close enough match to make it work. Slim chance * slim chance = very slim chance. I also suppose there is a chance that our son could develop something that could be treated in the future from his banked cord blood, but for now all is well.
My in-laws paid 100% of all the cord-bank fees. They let us decide on our own, but let us know they'd pay for it if we decided to do it. In the end it all came to a few thousand dollars.
We decided to do it. It cost us nothing other than a very minor hassle (you've got to get the doctor to do it, not a problem, and then you've got to arrange for the courier. The company made it trivially easy, but you still have to do a phone call). And while there aren't any current benefits, a few thousand dollars is little to pay for the tiny bit of hope it provides my sister-in-law.
But for other people considering it: 0. Realize there are few current benefits that can be derived from this, you're putting away something in the hope that IFF something happens and IFF someone develops a treatment that can utilize this material, you've at least got the raw materials at hand. 1. Can you afford the fees? 2. Do you have an expectation that your son, daughter, or a future sibling might need this? Easy question to answer if genetic screening shows one of the parents carriers for something or the baby is already known to have a problem. Harder if everything seems to be fine right now. 3. Do you have a close relative that this might help?
For us, the cost issue didn't matter, and we had an easy "yes" answer to #3, so the hardest thing was researching the options and choosing the company.
Would we have banked it if my in-laws hadn't paid for it? Probably not. Would we have banked it if we didn't have a nephew with a severe genetic disorder? Probably not. But we did have these conditions, so it was an easy decision.
I wish you luck and good heath for you and your family.
For "using Linux seriously": Um, well... about 5 minutes ago. I've got a current release of Fedora running in a VM that I installed a few weeks ago.
I use it every day. I write both kernel-level and application level software for it every day. Yet I find I need to spend lots more time configuring and maintaining Linux than I do OSX. That's me. YMMV.
Assuming you were actually replying to me (not exactly clear based on your quote and what you said), I'd like to answer you.
First off, I'm not evangelizing anything. I was merely answering the parent poster when he asked about the benefits to purchasing a Mac over a PC. I was describing why it works best for me; I recognize that other people might want/need other things.
I've just always thought it ironic that I'm so much more productive developing Linux software on OSX than when I used Linux as my primary OS.
Please use whatever you want to use. I would never dream of suggesting that because a Mac is perfect for what I do, it is perfect for what you do.
However, I think the main point of my post is valid: why multi-boot? Even what you point out is different hardware running a single OS most of the time.
As a note, I am all about the right tool for the right job. I run several machines: A Linux fileserver for our home network server, my OSX laptop (often running Win or Linux in a VM) for my day-to-day work, a Linux server for web hosting, a Windows laptop for my wife, a Tivo (Linux again), and a Linux server for my piano. I even have an old desktop that I never turn on that is configured to dual-boot WinME (don't ask) and Linux; but I never actually use the dual-boot on it...I haven't even turned in on in a year.
I agree with your: "what is the point of buying a Mac and then triple booting OS X, Windows, and Linux?" But for totally different reasons.
I ask: why would you bother with even a double boot, let alone a triple boot? There is nothing you can't do with a Mac, in OSX alone, that you can do with any other OS.
First, hardware: Apple hardware is clean, reliable, with features that are difficult to find in combination on other systems. Apple hardware works; and when it doesn't they fix it. You don't have to keep fussing with it like you do if you build a machine from scratch. And its price is comparable to similarly equipped PC equipment (there was a recent post here on/. about that specifically). Yes, you can buy a PC for less... but that misses the point doesn't it?
As for the OS: OSX is like running Linux in many ways. It is solid, never breaks, it performs well, doesn't have virus and worm issues: basically everything that Windows isn't.
It is based on BSD, and has gcc and other open source tools. It has ssh, bash, tcsh, and X. You can build and run nearly any open-source application or tool.
What OSX is missing from Linux: fiddlyness. While running a Linux distribution feels good, at the same time it's a fair amount of work. Need to get a new piece of hardware working: compile a new kernel module, add that, and muck with configuration files in/etc. And if you're unlucky, possibly have to muck with device nodes in/dev or monkey around with udev configurations. And that's just one example. Every time you want to add or change something it's rinse and repeat time. Oh and forget Linux on laptops... it's famous for having spotty laptop hardware support.
But really the question is "why multi-boot"? With VMWare Fusion on the Mac, I really don't know. Just run Windows applications side-by-side with your Mac ones in OSX. Run an entire Linux development server in a virtual box. When you need to compare configurations, clone the sucker and try out a different one. When your Windows VM starts to get a polluted registry, slows down and starts to eat itself, delete and reinstall it...while compiling the Linux kernel in a Linux VM, while writing a software certification test proposal in OpenOffice running directly in OSX. No lost productivity simply because you have to reinstall Windows.
The real question here is not "Mac vs Linux vs Windows?", it's "why are you still multi-booting?"
It likely doesn't have anything to do with your tech support experience. Sorry. And I'm not trying to be insulting, just helpful.
Take a good deep critical look at yourself, your interviewing skills and your resume. Maybe your experience is sub-par. Most employers that I know won't care if you have other pluses: * Enthusiasm. * You've done your homework on the company and the position. * A great resume.
A recruiters default answer is "no". It's much safer to have a few false-negatives than a false positive. Unless you make the hiring manager say "wow, that guy has it together and I must hire him", you're not getting the job. And the "your professional background isn't what we're looking for line" is often a good default line.
There are lots of things you can do to improve your chances. Blaming it on your job as a tech-support monkey isn't going to help. And honestly: if the manager you interviewed with actually is not hiring you due to that specific job being on your resume, you really don't want to work for them anyway.
It's not x-platform (it runs on OSX), but it's probably the best editor I've ever used (and this includes Eclipse, Emacs, VIM, SNiFF+, MS DOS's Edit, VisualStudio, various Borland editors, Metrowerks, and just about every mainstream editor included in various distributions of Linux).
It supports Python as well as dozens of other languages; I've used C/C++, Perl, shell scripting, PHP and HTML on it; looking at the menu I count 42 different languages or variants. It supports multiple SCM types, including CVS and Subversion.
Qualifications: * I did go to a major university, top 10 in many engineering fields, though the CS program is probably only top-50. We have a HUGE CS program, so much so that there's two, one by the College of Engineering and one by the College of Letters and Science (I did the engineering program). * I hire and direct programmers, as well as do some of the work myself, mainly in Linux systems programming for embedded devices.
My experience: * Small is good. Most of my classes were huge. CS classes in the 50-100 range were not unusual. I got a much better education, and enjoyment, in the few classes that were small.
* Huge school often equals hard to get classes. I often had a hard time getting _required_ CS courses when I needed them. And getting in was all about seniority in number of units.
* Most major tech schools and large universities are major research centers. This is good and bad. Great if you want to do research. Horrible if you want an education. I'd say 90% of my professors actually cared more about their research than the students and courses they were teaching. Some of the worst classes were from the best researchers: my absolutely worst class was in networking theory; 85% of the class failed (upper-division, long past weed-out courses, and these students all got A or B in a retake from a different prof), but the prof is now CTO of a new startup making lots of $$$ from his research while still retaining his professorship.
* Theory is GOOD. My whole time I complained that they kept pushing theory, ignoring practical applications. My favorite is when they present a model of something (ah, the 7-layer networking model), then proceed to tell you that, "oh, but nothing ever implements this, it's too perfect." But after graduating and getting jobs in the field, I learned how important the theory was. The theory is the base foundation you build your skills on. I know how differant types of languages work, how compilers function, basically how everything works and is build and why they work and why they're built that way. Because I know and understand theory, I can pick up a new programming language in just a few days (and that's not because I'm smart or have a good memory: I've programmed in C++ for a decade and still keep a book handy for syntax issues), all because I just understand the fundamentals.
Any school can teach you how to program in a language, even a heavy theory school typically has a program in {C,C++,C#,JAVA...pick one} class as the first introduction course. If all you want is some technical skills, go read a "PHP in 10 days" book and save yourself or your parents some big bucks. If you want to really learn and be valuable to an employer, learn not the language, but how the language works.
As someone who interviews for technical possitions, I am always more concerned about how the candidate comes up with the answer to my techincal questions, than the specific answer. I may ask programming questions, but I never care about the correct answer, I'm looking at if they _understand_ what and why and more subtle things like programming style.
BTW, I rarely ever ask about specific programming languages, other than the 'standard' ones; a good programmer can pickup a new language quickly. At small companies it's more important that the new hire can understand things quickly than that they have a specific skill.
Another place the theory helps: if you do get hired, no matter what task they set you on first, your first task is learning the IP of that new company. How the code works, how the equipment works, the processes, the lingo. Learning a new language from scratch those first 60 days may be the least of what you'll need to learn ASAP. Theory helps here 1000x more than knowing how to program in Java.
I can't tell you what school to choose, but hopefully the issues or guidelines above will help you frame your questions and requirements about the two schools.
Looks like someone over there has been reading Larry Niven and Steven Barnes' book: Saturn's Race!
Hopefully they got to the end and realized it didn't end well...
When I first started with my current company over 3 years ago, I was asked to put together a coding standard. I started with: http://www.ganssle.com/fsm.htm If doing embedded/firmware it's a great start; though it's a great start for any code work.
Here's my opinions: 1. Good comments are valuable. Comments that tell you why something was done the way it was are invaluable.
2. Use a code repository. CVS is what we use. And use the thing, check-in frequently.
3. Backups. 'nuf said.
4. Don't worry about specific code style issues (especially brackets). Just make a requirement that people follow the style already in a project (or file if you want to get that granular) as they add and modify. Be flexable, there's really much more importaint issues (like vi vs. emacs).
5. make and other automated ways are your friends. Automate as much as possible; it's too easy to forget that one silly commandline incantation you have to do to build the major product and end up having to re-release to fix something.
6. Templates. Have a project in CVS of standardized file templates. Make one for each file type you've got: header_c_template.h, header_cpp_template.h, module_c_template.c, module_template.cpp, Makefile_template, etc...
Saves time and avoids unnecessary rework. Also, new people to your organization will know what you expect in your files.
Ok, maybe I'll burn some karma with this but I just can't let this stand...
"Seriously", how could you read/. and miss Drupal. I just implemented several Drupal sites; I discovered Drupal primarily due to the coverage of it here on/..
I do agree that often articles here need a bit more context, especially when discussing a software package, but when I don't know what a post is talking about I either Google it or just figure I don't care.
It is important that the design doc be started at the very start of the project, and that it continues to be maintained throughout the projects life-cycle.
A design doc must grow and change with the project. Without that it's totally useless two years down the line. I would include it with the project in your code revision system with regular check ins and tags.
I recomend that it includes information about any design decisions and why they were made that way. It is always painful several years in the project when you look at something and go: "Hey that's a weird way to do that. I know there was a reason, but I can't remember why..."
RTAI simply wouldn't help in our particular appliction domain. Jitter of more than about 100nsec would be too much for our system to work properly. And, ALL stuff our system does must be done each 40 usec. The scheduler alone from Linux would cost too much time.
We don't even use an "OS" as you know it. Basically we've got one piece of code that runs in a loop with some hardware interrupts (the period on the hw interrupts is about every 3.65 usec with each interrupt taking ~2 usec with 11 interrupts per loop) and that's it. Linux would just add too much overhead to get our stuff done.
We evaluated MULTI back when we were researching tools. First off, I didn't want a full IDE solution, but that's neither here nor there. If I remember correctly, at the time (about 2 years ago) MULTI didn't support Linux. Also, it had a number of issues with automagically doing things and the user not being able to undo some of it.
I've been trying to get Insight working with a basic P&E wiggler, but so far no luck due to gcc not having patches (there are patches out there, but not for the current gcc version and for some reason no one has managed to get them commited to the mainline gcc) for the coldfires and me not having time to deal with it.
Ok, first my quals: * I am an embedded programmer. * I've used a variety of embedded OSs including both vendor (pay) and home-grown (free except for labor) and Linux. * I love Linux. I use it at work and home as my desktop, and at work on servers. I have contributed to several projects including ALSA and gcc and binutils.
The way I see it, Dan is both right and wrong.
He's right in that Linux is not approprate for many "true" embedded applications. Most apps have very stringent memmory requirements, don't need most services, and work on severly limited chips (over 70% of all processors sold are 8-bitters). Also, Linux can not meet the real-time reqirements of many applications (feel free to flame me, but it is definately true, despite any "real-time layers" that have been added to Linux). For example, I work on a product that has 512k of SRAM, with a processor clock speed of 156 MHz, and it's "clock tick" has to be less than 40 usec (typical times of Linux include 5 msec). We use an in-house "OS" which isn't a true OS anyway, just a tightly coded main loop in order to meet our requirments.
On the otherhand, we have another "embedded" project that does use Linux. It is the best OS for the job in this case.
As usual in engineering, one must chose the right tool for the right job.
But, for companies that make development tools, we'd be a poor choice on that Linux system because it is highly modded and they'd not be able to support it econommically.
What it comes down to is embedded projects MUST chose the right tools for the right job, and Linux is not allways the right tool.
For embedded tools vendors, Linux OSs will be difficult to support for the very reasons that Dan mentions.
But this doesn't mean that there's no place for Linux in embedded or psudo-embedded applications (psudo-embedded apps look like embedded systems on the surface, but are usually full-featured general purpose systems on the inside. Think TiVo).
The Linux support I'd like to see from tools vendors is better tools on the Linux workstations. Support gcc and binutils for more processors or optimize the code output better on gcc. Help with gdb, insight and DDD to make your hardware emulators work with them on the workstation. I'm tired of having to keep a dual-boot system just to run VisionClick so I can debug my 5407 embedded systems.
Primarily an embedded OS and tools company. They sell VxWorks (OS), the Vision* (...Probe,...ICE,...Click) products, SNiFF+ (A code management/editor/analysis package that rocks and runs on Linux), and Diab (embedded compiler).
We use several of their products at my company to develop MCF5407 systems. Not that I'd buy WR products again though...
Actually, they're really a "aquire and kill" company...over the last several years they've gone on a major aqusions binge, and many of the products of companies they've aquired (mostly competitors, and often with superior products) they've either let stagnate or killed outright.
Upgrading from 2.96 to 3.3 (or 3.2) gotchas?
on
GCC 3.3 Released
·
· Score: 1
I do development work using gcc on my local Mandrake machine with 3.2. I tried to compile one of my projects on our server which uses gcc 2.96 and it fails (3.2 follows the ANSI C++ standard, 2.96 is old-style) due to the older C++ libs.
I want to upgrade our server to gcc 3.2, but since we've got other projects that work fine under 2.96, we are afraid of breaking the other projects (especially since we are close to release). Does anyone know of any gotchas? Can I just download, compile, and install 3.3 (or 3.2)? Will I also need to download, compile and install a new glibc? Can I install gcc 3.3 and not change my glibc version?
Thanks,
- Steve
You'll have people that have no interest in this. Perhaps they don't use the net much or are perfectly happy with their $20.00/ month AOL dialup (or whatever they charge now). So do people subscribe or do they get charged with the local taxes, water, garbage or whatever? How do you deal with someone that abuses the TOS...if they have to pay for it in their local taxes or other "fees" I don't think you can leagally cut them off.
Also, if you put a locally run cable company on this, usually you'd end up with a few locals + a few cable channels. Forget any choices with special pay channels or DirectTV or so on. "Wait, I pay $40 a month for this thing and I don't even get TiVo service?"
My sugestion would be to setup a local ISP to handle the accounts and service with infrastructure (fiber) provided by the town and leased to the ISP. The infrastructure could be built using standard tax stuff (find room in the budget, try to pass a bond, etc), but since there's a private ISP running the accounts they can sell the access, maintain the network, and deal with TOS issues.
Slashdot Mirror
What wasn't clear from the post is both missions (Dawn and Kepler) were both successful and lasted well past their intended mission lengths. Specifically, Dawn was finished over a year ago, and at that point they decided that they'd continue to collect data until the fuel ran out - which happened yesterday. Kepler lasted well over twice its designed mission lifetime. Again - "it still works, so we'll use it until the fuel runs out".
Kepler ended up surveying over 500,000 stars and has detected greater than 2600 planets. The data collected will be continued to be used for decades to come to find more planets and other information about the physics of planetary system development. The successor to Kepler, the Transiting Exoplanet Survey Satellite (TESS) was launched in April and just had first-light a couple of months ago.
Dawn was successful as the first NASA probe to use ion drives which let it enter and leave the orbits of the two asteroids. It successfully made maps of both bodies as well as detailed spectroscopic maps in both the infrared and visible spectrums.
Both missions did excellent science, outlived their planned lifetimes and should be celebrated for it.
It should come out to a cost-benefit analysis for you and your family. I'll explain my family's decision to bank my son's cord blood and then try to give you an idea of what you might want to think about in your case.
When my son was born, we did bank the cord-blood. But I'm under no illusions as to any potential benefits.
My wife has a nephew with Cystic Fibrosis. He has no siblings, nor is likely to have any. There is a slim chance that a treatment might be developed within his lifetime that could utilize stem cells from cord blood, and a slim chance that our son could be a close enough match to make it work. Slim chance * slim chance = very slim chance. I also suppose there is a chance that our son could develop something that could be treated in the future from his banked cord blood, but for now all is well.
My in-laws paid 100% of all the cord-bank fees. They let us decide on our own, but let us know they'd pay for it if we decided to do it. In the end it all came to a few thousand dollars.
We decided to do it. It cost us nothing other than a very minor hassle (you've got to get the doctor to do it, not a problem, and then you've got to arrange for the courier. The company made it trivially easy, but you still have to do a phone call). And while there aren't any current benefits, a few thousand dollars is little to pay for the tiny bit of hope it provides my sister-in-law.
But for other people considering it:
0. Realize there are few current benefits that can be derived from this, you're putting away something in the hope that IFF something happens and IFF someone develops a treatment that can utilize this material, you've at least got the raw materials at hand.
1. Can you afford the fees?
2. Do you have an expectation that your son, daughter, or a future sibling might need this? Easy question to answer if genetic screening shows one of the parents carriers for something or the baby is already known to have a problem. Harder if everything seems to be fine right now.
3. Do you have a close relative that this might help?
For us, the cost issue didn't matter, and we had an easy "yes" answer to #3, so the hardest thing was researching the options and choosing the company.
Would we have banked it if my in-laws hadn't paid for it? Probably not.
Would we have banked it if we didn't have a nephew with a severe genetic disorder? Probably not.
But we did have these conditions, so it was an easy decision.
I wish you luck and good heath for you and your family.
- Steve
For "using Linux seriously": Um, well... about 5 minutes ago. I've got a current release of Fedora running in a VM that I installed a few weeks ago.
I use it every day. I write both kernel-level and application level software for it every day. Yet I find I need to spend lots more time configuring and maintaining Linux than I do OSX. That's me. YMMV.
Assuming you were actually replying to me (not exactly clear based on your quote and what you said), I'd like to answer you.
First off, I'm not evangelizing anything. I was merely answering the parent poster when he asked about the benefits to purchasing a Mac over a PC. I was describing why it works best for me; I recognize that other people might want/need other things.
I've just always thought it ironic that I'm so much more productive developing Linux software on OSX than when I used Linux as my primary OS.
Please use whatever you want to use. I would never dream of suggesting that because a Mac is perfect for what I do, it is perfect for what you do.
However, I think the main point of my post is valid: why multi-boot? Even what you point out is different hardware running a single OS most of the time.
As a note, I am all about the right tool for the right job. I run several machines: A Linux fileserver for our home network server, my OSX laptop (often running Win or Linux in a VM) for my day-to-day work, a Linux server for web hosting, a Windows laptop for my wife, a Tivo (Linux again), and a Linux server for my piano. I even have an old desktop that I never turn on that is configured to dual-boot WinME (don't ask) and Linux; but I never actually use the dual-boot on it...I haven't even turned in on in a year.
I agree with your: "what is the point of buying a Mac and then triple booting OS X, Windows, and Linux?" But for totally different reasons.
I ask: why would you bother with even a double boot, let alone a triple boot? There is nothing you can't do with a Mac, in OSX alone, that you can do with any other OS.
First, hardware: Apple hardware is clean, reliable, with features that are difficult to find in combination on other systems. Apple hardware works; and when it doesn't they fix it. You don't have to keep fussing with it like you do if you build a machine from scratch. And its price is comparable to similarly equipped PC equipment (there was a recent post here on /. about that specifically). Yes, you can buy a PC for less... but that misses the point doesn't it?
As for the OS: OSX is like running Linux in many ways. It is solid, never breaks, it performs well, doesn't have virus and worm issues: basically everything that Windows isn't.
It is based on BSD, and has gcc and other open source tools. It has ssh, bash, tcsh, and X. You can build and run nearly any open-source application or tool.
What OSX is missing from Linux: fiddlyness. While running a Linux distribution feels good, at the same time it's a fair amount of work. Need to get a new piece of hardware working: compile a new kernel module, add that, and muck with configuration files in /etc. And if you're unlucky, possibly have to muck with device nodes in /dev or monkey around with udev configurations. And that's just one example. Every time you want to add or change something it's rinse and repeat time. Oh and forget Linux on laptops... it's famous for having spotty laptop hardware support.
But really the question is "why multi-boot"? With VMWare Fusion on the Mac, I really don't know. Just run Windows applications side-by-side with your Mac ones in OSX. Run an entire Linux development server in a virtual box. When you need to compare configurations, clone the sucker and try out a different one. When your Windows VM starts to get a polluted registry, slows down and starts to eat itself, delete and reinstall it...while compiling the Linux kernel in a Linux VM, while writing a software certification test proposal in OpenOffice running directly in OSX. No lost productivity simply because you have to reinstall Windows.
The real question here is not "Mac vs Linux vs Windows?", it's "why are you still multi-booting?"
It likely doesn't have anything to do with your tech support experience. Sorry. And I'm not trying to be insulting, just helpful.
Take a good deep critical look at yourself, your interviewing skills and your resume. Maybe your experience is sub-par. Most employers that I know won't care if you have other pluses:
* Enthusiasm.
* You've done your homework on the company and the position.
* A great resume.
A recruiters default answer is "no". It's much safer to have a few false-negatives than a false positive. Unless you make the hiring manager say "wow, that guy has it together and I must hire him", you're not getting the job. And the "your professional background isn't what we're looking for line" is often a good default line.
I recommend that you purchase and listen to the Manager Tools interviewing series http://www.manager-tools.com/category/interviewing-series/ (no I'm not associated with them, but I do listen to the podcasts weekly). It is worth every penny. At the very least, listen to the free "your resume stinks" podcast http://www.manager-tools.com/2005/10/your-resume-stinks/ .
There are lots of things you can do to improve your chances. Blaming it on your job as a tech-support monkey isn't going to help. And honestly: if the manager you interviewed with actually is not hiring you due to that specific job being on your resume, you really don't want to work for them anyway.
It's not x-platform (it runs on OSX), but it's probably the best editor I've ever used (and this includes Eclipse, Emacs, VIM, SNiFF+, MS DOS's Edit, VisualStudio, various Borland editors, Metrowerks, and just about every mainstream editor included in various distributions of Linux).
It supports Python as well as dozens of other languages; I've used C/C++, Perl, shell scripting, PHP and HTML on it; looking at the menu I count 42 different languages or variants. It supports multiple SCM types, including CVS and Subversion.
http://www.barebones.com/products/bbedit/
Even better: the company is great. They came out with a new version 8 months after I bought the previous version, and sent me a free key to upgrade!
Qualifications:
* I did go to a major university, top 10 in many engineering fields, though the CS program is probably only top-50. We have a HUGE CS program, so much so that there's two, one by the College of Engineering and one by the College of Letters and Science (I did the engineering program).
* I hire and direct programmers, as well as do some of the work myself, mainly in Linux systems programming for embedded devices.
My experience:
* Small is good. Most of my classes were huge. CS classes in the 50-100 range were not unusual. I got a much better education, and enjoyment, in the few classes that were small.
* Huge school often equals hard to get classes. I often had a hard time getting _required_ CS courses when I needed them. And getting in was all about seniority in number of units.
* Most major tech schools and large universities are major research centers. This is good and bad. Great if you want to do research. Horrible if you want an education. I'd say 90% of my professors actually cared more about their research than the students and courses they were teaching. Some of the worst classes were from the best researchers: my absolutely worst class was in networking theory; 85% of the class failed (upper-division, long past weed-out courses, and these students all got A or B in a retake from a different prof), but the prof is now CTO of a new startup making lots of $$$ from his research while still retaining his professorship.
* Theory is GOOD. My whole time I complained that they kept pushing theory, ignoring practical applications. My favorite is when they present a model of something (ah, the 7-layer networking model), then proceed to tell you that, "oh, but nothing ever implements this, it's too perfect." But after graduating and getting jobs in the field, I learned how important the theory was. The theory is the base foundation you build your skills on. I know how differant types of languages work, how compilers function, basically how everything works and is build and why they work and why they're built that way. Because I know and understand theory, I can pick up a new programming language in just a few days (and that's not because I'm smart or have a good memory: I've programmed in C++ for a decade and still keep a book handy for syntax issues), all because I just understand the fundamentals.
Any school can teach you how to program in a language, even a heavy theory school typically has a program in {C,C++,C#,JAVA...pick one} class as the first introduction course. If all you want is some technical skills, go read a "PHP in 10 days" book and save yourself or your parents some big bucks. If you want to really learn and be valuable to an employer, learn not the language, but how the language works.
As someone who interviews for technical possitions, I am always more concerned about how the candidate comes up with the answer to my techincal questions, than the specific answer. I may ask programming questions, but I never care about the correct answer, I'm looking at if they _understand_ what and why and more subtle things like programming style.
BTW, I rarely ever ask about specific programming languages, other than the 'standard' ones; a good programmer can pickup a new language quickly. At small companies it's more important that the new hire can understand things quickly than that they have a specific skill.
Another place the theory helps: if you do get hired, no matter what task they set you on first, your first task is learning the IP of that new company. How the code works, how the equipment works, the processes, the lingo. Learning a new language from scratch those first 60 days may be the least of what you'll need to learn ASAP. Theory helps here 1000x more than knowing how to program in Java.
I can't tell you what school to choose, but hopefully the issues or guidelines above will help you frame your questions and requirements about the two schools.
Looks like someone over there has been reading Larry Niven and Steven Barnes' book: Saturn's Race! Hopefully they got to the end and realized it didn't end well...
When I first started with my current company over 3 years ago, I was asked to put together a coding standard. I started with:
http://www.ganssle.com/fsm.htm
If doing embedded/firmware it's a great start; though it's a great start for any code work.
Here's my opinions:
1. Good comments are valuable. Comments that tell you why something was done the way it was are invaluable.
2. Use a code repository. CVS is what we use. And use the thing, check-in frequently.
3. Backups. 'nuf said.
4. Don't worry about specific code style issues (especially brackets). Just make a requirement that people follow the style already in a project (or file if you want to get that granular) as they add and modify. Be flexable, there's really much more importaint issues (like vi vs. emacs).
5. make and other automated ways are your friends. Automate as much as possible; it's too easy to forget that one silly commandline incantation you have to do to build the major product and end up having to re-release to fix something.
6. Templates. Have a project in CVS of standardized file templates. Make one for each file type you've got: header_c_template.h, header_cpp_template.h, module_c_template.c, module_template.cpp, Makefile_template, etc...
Saves time and avoids unnecessary rework. Also, new people to your organization will know what you expect in your files.
Ok, maybe I'll burn some karma with this but I just can't let this stand...
/. and miss Drupal. I just implemented several Drupal sites; I discovered Drupal primarily due to the coverage of it here on /..
"Seriously", how could you read
I do agree that often articles here need a bit more context, especially when discussing a software package, but when I don't know what a post is talking about I either Google it or just figure I don't care.
It is important that the design doc be started at the very start of the project, and that it continues to be maintained throughout the projects life-cycle.
A design doc must grow and change with the project. Without that it's totally useless two years down the line. I would include it with the project in your code revision system with regular check ins and tags.
I recomend that it includes information about any design decisions and why they were made that way. It is always painful several years in the project when you look at something and go: "Hey that's a weird way to do that. I know there was a reason, but I can't remember why..."
RTAI simply wouldn't help in our particular appliction domain. Jitter of more than about 100nsec would be too much for our system to work properly. And, ALL stuff our system does must be done each 40 usec. The scheduler alone from Linux would cost too much time.
We don't even use an "OS" as you know it. Basically we've got one piece of code that runs in a loop with some hardware interrupts (the period on the hw interrupts is about every 3.65 usec with each interrupt taking ~2 usec with 11 interrupts per loop) and that's it. Linux would just add too much overhead to get our stuff done.
We evaluated MULTI back when we were researching tools. First off, I didn't want a full IDE solution, but that's neither here nor there. If I remember correctly, at the time (about 2 years ago) MULTI didn't support Linux. Also, it had a number of issues with automagically doing things and the user not being able to undo some of it.
I've been trying to get Insight working with a basic P&E wiggler, but so far no luck due to gcc not having patches (there are patches out there, but not for the current gcc version and for some reason no one has managed to get them commited to the mainline gcc) for the coldfires and me not having time to deal with it.
Ok, first my quals:
* I am an embedded programmer.
* I've used a variety of embedded OSs including both vendor (pay) and home-grown (free except for labor) and Linux.
* I love Linux. I use it at work and home as my desktop, and at work on servers. I have contributed to several projects including ALSA and gcc and binutils.
The way I see it, Dan is both right and wrong.
He's right in that Linux is not approprate for many "true" embedded applications. Most apps have very stringent memmory requirements, don't need most services, and work on severly limited chips (over 70% of all processors sold are 8-bitters). Also, Linux can not meet the real-time reqirements of many applications (feel free to flame me, but it is definately true, despite any "real-time layers" that have been added to Linux). For example, I work on a product that has 512k of SRAM, with a processor clock speed of 156 MHz, and it's "clock tick" has to be less than 40 usec (typical times of Linux include 5 msec). We use an in-house "OS" which isn't a true OS anyway, just a tightly coded main loop in order to meet our requirments.
On the otherhand, we have another "embedded" project that does use Linux. It is the best OS for the job in this case.
As usual in engineering, one must chose the right tool for the right job.
But, for companies that make development tools, we'd be a poor choice on that Linux system because it is highly modded and they'd not be able to support it econommically.
What it comes down to is embedded projects MUST chose the right tools for the right job, and Linux is not allways the right tool.
For embedded tools vendors, Linux OSs will be difficult to support for the very reasons that Dan mentions.
But this doesn't mean that there's no place for Linux in embedded or psudo-embedded applications (psudo-embedded apps look like embedded systems on the surface, but are usually full-featured general purpose systems on the inside. Think TiVo).
The Linux support I'd like to see from tools vendors is better tools on the Linux workstations. Support gcc and binutils for more processors or optimize the code output better on gcc. Help with gdb, insight and DDD to make your hardware emulators work with them on the workstation. I'm tired of having to keep a dual-boot system just to run VisionClick so I can debug my 5407 embedded systems.
Primarily an embedded OS and tools company. They sell VxWorks (OS), the Vision* (...Probe, ...ICE, ...Click) products, SNiFF+ (A code management/editor/analysis package that rocks and runs on Linux), and Diab (embedded compiler).
We use several of their products at my company to develop MCF5407 systems. Not that I'd buy WR products again though...
Actually, they're really a "aquire and kill" company...over the last several years they've gone on a major aqusions binge, and many of the products of companies they've aquired (mostly competitors, and often with superior products) they've either let stagnate or killed outright.
I do development work using gcc on my local Mandrake machine with 3.2. I tried to compile one of my projects on our server which uses gcc 2.96 and it fails (3.2 follows the ANSI C++ standard, 2.96 is old-style) due to the older C++ libs. I want to upgrade our server to gcc 3.2, but since we've got other projects that work fine under 2.96, we are afraid of breaking the other projects (especially since we are close to release). Does anyone know of any gotchas? Can I just download, compile, and install 3.3 (or 3.2)? Will I also need to download, compile and install a new glibc? Can I install gcc 3.3 and not change my glibc version? Thanks, - Steve
You'll have people that have no interest in this. Perhaps they don't use the net much or are perfectly happy with their $20.00/ month AOL dialup (or whatever they charge now). So do people subscribe or do they get charged with the local taxes, water, garbage or whatever? How do you deal with someone that abuses the TOS...if they have to pay for it in their local taxes or other "fees" I don't think you can leagally cut them off.
Also, if you put a locally run cable company on this, usually you'd end up with a few locals + a few cable channels. Forget any choices with special pay channels or DirectTV or so on. "Wait, I pay $40 a month for this thing and I don't even get TiVo service?"
My sugestion would be to setup a local ISP to handle the accounts and service with infrastructure (fiber) provided by the town and leased to the ISP. The infrastructure could be built using standard tax stuff (find room in the budget, try to pass a bond, etc), but since there's a private ISP running the accounts they can sell the access, maintain the network, and deal with TOS issues.
Just my $.02 of course.
- Alinraz