I use.Mac for backing up my contacts, passwords, and a few small things that I don't want to bother finding on my harddrive.
I can't get it to work through the corporate firewall, it's kind of slow, and it's very small as you said.
On the plus side, it has very good integration with the native Apple backup utility. I do find a USB HD more useful, though. And a USB HD works well with the Apple backup util, too.
I'm an embedded FW engineer, MS in CS, 10+ yrs experience. My previous employer (my profile says extendsys.com but that's two jobs back) shut down our office here in Boise, ID, USA.
The tech job market here is on an upswing. Micron is hiring again but HP has a hiring freeze (I think). There are a LOT of very small high tech companies around here looking for people. The trouble is finding them.
I started asking friends and previous coworkers about opportunities. I had four offers within a few weeks. I landed at an excellent company (Agilent) doing hardcore embedded development and I'm having more fun than I've had in a couple years.
Who I knew got me in the door. Every interview was either with former coworkers or I'd been recommended by a former coworker. I can't say enough about how important it is to maintain a good network of peers and a good reputation.
But don't move to Boise. I'm a greedy ba**ard and don't want any competition.:-)
Because our idiot government (USA) has spent the better part of the last decade doing their damnedest to stomp out encryption.
When the huge boom in software and the Internet hit 10 years ago, if we had been able to integrate decent encryption into software *maybe* some of these dumb-ass password sniffing problems wouldn't be an issue.
Of course we'd still have a) buffer overflows b) bad passwords c) bad coding even though encrypted d) non-nerd users doing insecure things (sticky notes) and so on and so forth.
Re:Thoughts of Python...
on
Dive Into Python
·
· Score: 5, Interesting
I use it daily in my job (http://www.mobl.com/handheld/cradles). Our test fixture (tests new boards coming off the line at our custom manufacturer) is written in shell scripts and Python on an embedded SiS-550 Linux board running 2.4.9, uClibc, BusyBox, etc.
I rewrote our Windows-based management tools into Python for myself. Using that protocol library, I've sent quick and dirty py2exe wxWindows programs to customers. "Just unzip and run." Unless they look closely, I'm sure they don't know (and don't care) they're running Python apps.
It's not exactly "in your face" like Zope but it glues together my day.
I have a living will that states if I fail to read Slashdot for six consecutive days, I'm to be considered legally brain dead.
My brother got married on Koh Samui, an island off Thailand last fall. I checked/. daily from the ubiquitous internet cafes in Bangkok and Koh Samui.
We investigated the Etrax for our current project but it didn't have USB host. Otherwise we would have jumped at it because of the mature tools support.
The embedded world is still largely about ASM routines and tight little loops that dont leave the cache, etc, etc.. You can write and test your fancy-shamcy hand-assembled routine at your leisure on your desktop computer....
Not really. There isn't much assembly necessary on a modern embedded platform. Even the little 4- and 8-bit processors have specialized C compilers available. Assembly is necessary for startup but that's about it; then we just jump to main(). I think Windows game programmers write more assembly than most embedded systems folks do.
Embedded systems development is just like any other development. How can I get the best product out as quickly as I can? ASM doesn't get me there quickly enough.
That's why using embedded x86 can be a good fit. It may not be the best technical solution, but we'll get to market quickly because the tools and available leveragable source is so good.
As an embedded Linux developer moving from x86 to ARM, there are good reasons to stick with embedded x86.
- My Linux development PC runs x86 so stuff compiles/runs on my development machine will tftp over to my embedded board and run immediately.
- The GNU x86 toolchain is WAY easier to use than the cross GCC tools. All GNU (Linux kernel and gcc especially) projects target x86 first and everyone plays catchup. Bugs are found/fixed in x86 first. Features work on x86 first.
Reasons to move from x86 to ARM.
- ARM is designed as an embedded CPU and x86 is designed as a desktop CPU. So the ARM has a very simple memory map, you don't have to worry about working around 15 year old cruft (why the foo doesn't a modern x86 boot straight to protected mode?).
- It's hard to find an x86, even one ostensibly designed for the embedded market, without the "kitchen sink" problem. Our product with >500 parts with an SiS x86 dropped to 300 with an Atmel AT91 ARM. Most of the passive parts on the SiS board were to turn OFF crap we didn't need (IDE controller, SD controller, video controller and so forth).
- ARM is cheaper. ARM is smaller. ARM uses less power. ARM is cooler (temperature). ARM is cooler (it's a very nifty chip design).
Just my opinions, lightly flavored with experience.
Re:a few extra notes from someone using OSS
on
Evaluating Open Source
·
· Score: 5, Interesting
I agree. In my experience over the last several years, I've found people who use OSS projects tend to be more self-starters, curious, and technically adept.
I joke that you learn a lot with Linux, et al, because you *have* to. Show me someone who is running Linux (or BSD) at home and I'll show you someone who knows and likes computers.
Re:a few extra notes from someone using OSS
on
Evaluating Open Source
·
· Score: 4, Informative
Lest I seem to negative up there, I should also mention that in using OSS you will learn more than you expect. It's a lot of fun to be able to mess around in USB device drivers one week then dig into a linker bug the next week. With time, patience, and persistence, you'll be able to understand how all the stuff actually works ("oh, that's how a shared library is loaded from disk into memory"). It's the keys to the kingdom!
a few extra notes from someone using OSS
on
Evaluating Open Source
·
· Score: 5, Informative
- Be prepared to become an expert on everything. If you have problems with component X, if no one in the community is interested in fixing it or if you're under time pressure, you'll have to fix it yourself. Also known as the "if you don't have a kernel expert on staff, you will eventually" rule.
- Almost nothing works the first time. OSS engenders infinite flexibility which eventually reaches infinite permutations. The plethora of configuration options to a large project's source can be very daunting. Everything interlocks with everything else for maximum flexibility which means more work up front to understand how the pieces fit together.
- Forget about binary portability. OSS is designed to support source code across platforms in the same way Windows is designed to support binary backwards compatilbity.
- Expect complexity and plan for it. OSS supports every platform under the sun which breeds extra complexity.
- Have lots and lots of patience.
Just my two cents from having developed embedded x86 and ARM Linux for the last two years.
The RIAA & MPAA are rightly concerned about digital copies making their way out onto the market. They also correctly state there is no way for a copying mechanism to tell the difference between a copy for personal use and a copy for a friend.
I have friends with small kids who have to buy 2-3 copies of Disney movies because the previous copy gets damanged. So backups are also a legitimate need.
So why not include 2 copies of the DVD in the box? One for use, one for backup? Maybe the "backup" adds an extra $1.50 to the cost. Most of the "backup problem" is now solved.
Or better yet, take the comb approach. Warranty a free product replacement for the lifetime of the purchaser. Another reason I make backups is I'm never sure the product will be around 10 years from now if my original copy goes bye-bye.
This might (and I say might) be true if they were competing for resources.
I must vehemently disagree.
They are competing for resources--users and product developers. Developing a commercial desktop application for Linux is almost impossible because of the crazy-quilt of user interfaces.
Saying choice is good is like saying it's a bad thing we all standardized on TCP/IP.
The majority of my work is embedded Linux done on a Linux box. But I bought a Mac because Linux-desktop is all over the map and has been for years. Before that I did all my work ssh'd into a Linux box from Windows.
Linux-desktop is in trouble until there is a STANDARD. Like networking has standards, like hardware has standards.
Not just the SCSI cards but those **** Intel EExpress cards that wait for 4 seconds for ctrl-s before continuing the boot.
Or, on cheaper hardware (like mine), those IDE controllers scanning the bus for ATA100 devices. I have an el-cheapo whitebox that takes almost 2 minutes to get to the GRUB prompt.
The Three R's of Windows Debugging
on
Debugging
·
· Score: 1, Funny
MIPS? Nuts. That's right. It was the NetWinder that was ARM. Hey, I wonder if Rebol has released their source?
They don't have to release the BIOS and bootloader if they don't want to since neither were probably GPL or based on Linux (I think).
Booting the system is hard. Running Linux is easy. In our current embedded products, we're using OpenBIOS and ROLO to start the system and boot Linux. Once Linux is running, life is cherries.
Hey, it's not the SIZE of the extinguisher, it's how you use it!
*cough*
What do you do with a dead Cobalt cube?
on
Sun Opens Cobalt Code
·
· Score: 5, Funny
Thus inviting disaster to my oh-so-dainty home DSL line, I nevertheless boldly post a link to a set of humorous uses for a dead Cobalt Cube. These pictures were done by a former coworker of mine, Scott Lundberg (Hi Scott!) about four years ago.
In a related rant, to heck with the upper level source code. I want them to release the schematics, BIOS, and boot code for the ARM cube! Having a turnkey ARM system like that would be an incredible boon to the embedded Linux world. Open Source doesn't necessarily have to mean just source code, IMO.
Nah. I've had a e500 (Celeron 500) for a couple of years as my main development machine. I had to beef up the cooling but it's run Linux non-stop for quite a while now.
I do embedded Linux development so I don't need a screaming machine.
The Museum of the Rockies in Bozeman is the dinosaur museum. Jack Horner, who was the technical consultant on the Jurassic Park movies and I think was the inspiration for Sam Neil's character, works there.
The museum planetarium also rocks.
I lived in Bozeman for a couple years work on my masters. Town itself is kind of dull.
how do we know they didn't take from Linux?
on
SCO vs Linux.. Continued
·
· Score: 2, Insightful
So, why are we supposed to believe SCO didn't take Linux source and copy it into their product?
Are they willing to open up a decade or more of their source to these experts?
And what the hell difference does it make if they point to the Linux code and say "here, here, and here". It's all already out there. It's not like the kernel folks can remove the evidence!
No source pretty much removes any reason I have to care about CE.
I'm trying to develop some WinCE apps to do something Microsoft didn't expect. That means they don't have an API for it. Which means, in order to do my job and implement what I want to implement, I have to reverse engineer the damn thing.
Like all Microsoft stuff, if you're doing exactly what the MS programmers and designers expected you to do, you're fine. If you color within the lines, you're fine. Everything works great. If you go *outside* the lines, may the gods help you.
I downloaded the CE.NET platform kit. The source within was all but useless to me.
Slashdot Mirror
I use .Mac for backing up my contacts, passwords, and a few small things that I don't want to bother finding on my harddrive.
I can't get it to work through the corporate firewall, it's kind of slow, and it's very small as you said.
On the plus side, it has very good integration with the native Apple backup utility. I do find a USB HD more useful, though. And a USB HD works well with the Apple backup util, too.
I challenge a non-root user to screw up a system as bad as this.
dd if=bootimage.bin of=/dev/hda
"Weird," I thought. "Why did it come back so fast? Usually floppy writes take a whole lot longer?"
I had been doing
dd if=bootimage.bin of=/dev/fd0
and brainlocked.
That's the idea! Yeah, yeah! Boise is a terrible place to live. Stay away. We're full. Are all you Californians listening? :-)
I'm an embedded FW engineer, MS in CS, 10+ yrs experience. My previous employer (my profile says extendsys.com but that's two jobs back) shut down our office here in Boise, ID, USA.
:-)
The tech job market here is on an upswing. Micron is hiring again but HP has a hiring freeze (I think). There are a LOT of very small high tech companies around here looking for people. The trouble is finding them.
I started asking friends and previous coworkers about opportunities. I had four offers within a few weeks. I landed at an excellent company (Agilent) doing hardcore embedded development and I'm having more fun than I've had in a couple years.
Who I knew got me in the door. Every interview was either with former coworkers or I'd been recommended by a former coworker. I can't say enough about how important it is to maintain a good network of peers and a good reputation.
But don't move to Boise. I'm a greedy ba**ard and don't want any competition.
Oh, that's an easy one.
Because our idiot government (USA) has spent the better part of the last decade doing their damnedest to stomp out encryption.
When the huge boom in software and the Internet hit 10 years ago, if we had been able to integrate decent encryption into software *maybe* some of these dumb-ass password sniffing problems wouldn't be an issue.
Of course we'd still have a) buffer overflows b) bad passwords c) bad coding even though encrypted d) non-nerd users doing insecure things (sticky notes) and so on and so forth.
I use it daily in my job (http://www.mobl.com/handheld/cradles). Our test fixture (tests new boards coming off the line at our custom manufacturer) is written in shell scripts and Python on an embedded SiS-550 Linux board running 2.4.9, uClibc, BusyBox, etc.
I rewrote our Windows-based management tools into Python for myself. Using that protocol library, I've sent quick and dirty py2exe wxWindows programs to customers. "Just unzip and run." Unless they look closely, I'm sure they don't know (and don't care) they're running Python apps.
It's not exactly "in your face" like Zope but it glues together my day.
I have a living will that states if I fail to read Slashdot for six consecutive days, I'm to be considered legally brain dead. My brother got married on Koh Samui, an island off Thailand last fall. I checked /. daily from the ubiquitous internet cafes in Bangkok and Koh Samui.
We investigated the Etrax for our current project but it didn't have USB host. Otherwise we would have jumped at it because of the mature tools support.
Not really. There isn't much assembly necessary on a modern embedded platform. Even the little 4- and 8-bit processors have specialized C compilers available. Assembly is necessary for startup but that's about it; then we just jump to main(). I think Windows game programmers write more assembly than most embedded systems folks do.
Embedded systems development is just like any other development. How can I get the best product out as quickly as I can? ASM doesn't get me there quickly enough.
That's why using embedded x86 can be a good fit. It may not be the best technical solution, but we'll get to market quickly because the tools and available leveragable source is so good.
As an embedded Linux developer moving from x86 to ARM, there are good reasons to stick with embedded x86.
- My Linux development PC runs x86 so stuff compiles/runs on my development machine will tftp over to my embedded board and run immediately.
- The GNU x86 toolchain is WAY easier to use than the cross GCC tools. All GNU (Linux kernel and gcc especially) projects target x86 first and everyone plays catchup. Bugs are found/fixed in x86 first. Features work on x86 first.
Reasons to move from x86 to ARM.
- ARM is designed as an embedded CPU and x86 is designed as a desktop CPU. So the ARM has a very simple memory map, you don't have to worry about working around 15 year old cruft (why the foo doesn't a modern x86 boot straight to protected mode?).
- It's hard to find an x86, even one ostensibly designed for the embedded market, without the "kitchen sink" problem. Our product with >500 parts with an SiS x86 dropped to 300 with an Atmel AT91 ARM. Most of the passive parts on the SiS board were to turn OFF crap we didn't need (IDE controller, SD controller, video controller and so forth).
- ARM is cheaper. ARM is smaller. ARM uses less power. ARM is cooler (temperature). ARM is cooler (it's a very nifty chip design).
Just my opinions, lightly flavored with experience.
I agree. In my experience over the last several years, I've found people who use OSS projects tend to be more self-starters, curious, and technically adept.
I joke that you learn a lot with Linux, et al, because you *have* to. Show me someone who is running Linux (or BSD) at home and I'll show you someone who knows and likes computers.
Lest I seem to negative up there, I should also mention that in using OSS you will learn more than you expect. It's a lot of fun to be able to mess around in USB device drivers one week then dig into a linker bug the next week. With time, patience, and persistence, you'll be able to understand how all the stuff actually works ("oh, that's how a shared library is loaded from disk into memory"). It's the keys to the kingdom!
- Be prepared to become an expert on everything. If you have problems with component X, if no one in the community is interested in fixing it or if you're under time pressure, you'll have to fix it yourself. Also known as the "if you don't have a kernel expert on staff, you will eventually" rule.
- Almost nothing works the first time. OSS engenders infinite flexibility which eventually reaches infinite permutations. The plethora of configuration options to a large project's source can be very daunting. Everything interlocks with everything else for maximum flexibility which means more work up front to understand how the pieces fit together.
- Forget about binary portability. OSS is designed to support source code across platforms in the same way Windows is designed to support binary backwards compatilbity.
- Expect complexity and plan for it. OSS supports every platform under the sun which breeds extra complexity.
- Have lots and lots of patience.
Just my two cents from having developed embedded x86 and ARM Linux for the last two years.
The RIAA & MPAA are rightly concerned about digital copies making their way out onto the market. They also correctly state there is no way for a copying mechanism to tell the difference between a copy for personal use and a copy for a friend.
I have friends with small kids who have to buy 2-3 copies of Disney movies because the previous copy gets damanged. So backups are also a legitimate need.
So why not include 2 copies of the DVD in the box? One for use, one for backup? Maybe the "backup" adds an extra $1.50 to the cost. Most of the "backup problem" is now solved.
Or better yet, take the comb approach. Warranty a free product replacement for the lifetime of the purchaser. Another reason I make backups is I'm never sure the product will be around 10 years from now if my original copy goes bye-bye.
This might (and I say might) be true if they were competing for resources.
I must vehemently disagree.
They are competing for resources--users and product developers. Developing a commercial desktop application for Linux is almost impossible because of the crazy-quilt of user interfaces.
Saying choice is good is like saying it's a bad thing we all standardized on TCP/IP.
The majority of my work is embedded Linux done on a Linux box. But I bought a Mac because Linux-desktop is all over the map and has been for years. Before that I did all my work ssh'd into a Linux box from Windows.
Linux-desktop is in trouble until there is a STANDARD. Like networking has standards, like hardware has standards.
Not just the SCSI cards but those **** Intel EExpress cards that wait for 4 seconds for ctrl-s before continuing the boot.
Or, on cheaper hardware (like mine), those IDE controllers scanning the bus for ATA100 devices. I have an el-cheapo whitebox that takes almost 2 minutes to get to the GRUB prompt.
Retry
Reboot
Reinstall
And that's why I love having source code!
MIPS? Nuts. That's right. It was the NetWinder that was ARM. Hey, I wonder if Rebol has released their source?
They don't have to release the BIOS and bootloader if they don't want to since neither were probably GPL or based on Linux (I think).
Booting the system is hard. Running Linux is easy. In our current embedded products, we're using OpenBIOS and ROLO to start the system and boot Linux. Once Linux is running, life is cherries.
Hey, it's not the SIZE of the extinguisher, it's how you use it!
*cough*
Thus inviting disaster to my oh-so-dainty home DSL line, I nevertheless boldly post a link to a set of humorous uses for a dead Cobalt Cube. These pictures were done by a former coworker of mine, Scott Lundberg (Hi Scott!) about four years ago.
http://www.mbuf.com/deadcube.php
In a related rant, to heck with the upper level source code. I want them to release the schematics, BIOS, and boot code for the ARM cube! Having a turnkey ARM system like that would be an incredible boon to the embedded Linux world. Open Source doesn't necessarily have to mean just source code, IMO.
Nah. I've had a e500 (Celeron 500) for a couple of years as my main development machine. I had to beef up the cooling but it's run Linux non-stop for quite a while now.
I do embedded Linux development so I don't need a screaming machine.
The Museum of the Rockies in Bozeman is the dinosaur museum. Jack Horner, who was the technical consultant on the Jurassic Park movies and I think was the inspiration for Sam Neil's character, works there.
The museum planetarium also rocks.
I lived in Bozeman for a couple years work on my masters. Town itself is kind of dull.
So, why are we supposed to believe SCO didn't take Linux source and copy it into their product?
Are they willing to open up a decade or more of their source to these experts?
And what the hell difference does it make if they point to the Linux code and say "here, here, and here". It's all already out there. It's not like the kernel folks can remove the evidence!
No source pretty much removes any reason I have to care about CE.
I'm trying to develop some WinCE apps to do something Microsoft didn't expect. That means they don't have an API for it. Which means, in order to do my job and implement what I want to implement, I have to reverse engineer the damn thing.
Like all Microsoft stuff, if you're doing exactly what the MS programmers and designers expected you to do, you're fine. If you color within the lines, you're fine. Everything works great. If you go *outside* the lines, may the gods help you.
I downloaded the CE.NET platform kit. The source within was all but useless to me.
Sigh.
Source code makes life so much easier.
Yuk yuk yuk!
And all the "FUN" of programming Windows!
Gods, I hate programming in Windows CE. What a pile of crap.