I'm the moron that suggested the motor oil... Personally, I think my flux tastes like peanut oil...
Hey, it works to keep the aluminum from oxidizing while soldering. And since I have motor oil and solder, but not conductive epoxy at hand, that's easier for me.
And, yes, he can try getting lithium coins from Digikey. But I assumed that if it was a standard battery with tabs, he'd have found it pretty easily.
Well, if it's just the matter of a tab on the thing, just take an electrically compatible coin battery, and solder on a piece of wire...
This assumes, of course, that the problem is with the battery. Are you sure about that?
Anwyays, there is a trick to soldering a wire onto batteries -- the aluminum doesn't like being soldered -- first, clean the surface thorougly using a fine abrasive to throughly remove the oxide layer and make sure it doesn't get contaminated.
Next, pour liquid flux (or in an emergency, a drop of motor oil) onto the aluminum, taking care to avoid trapping air under the oil.
Then, with a soldering iron, apply a good dose of melted solder onto the flux-covered spot. Then, attach the wire to the solder.
This spam did not interest me, specifically (because my son isn't into toys like that), but my coworker (who also has a 7 year old), who actually ordered some these cars, went on to say "Yeah, for once, some spam was actually useful. Go figure." Go figure, indeed.
Except that if he bought it from the spammer's, he's likely paying $29.95 for the lower-quality Chinese "knockoffs" which I can go downtown and buy a dozen for $66 from "cash-and-carry" distributors. Hell, for real wholesalers, the real cost is even lower.
the microprocessor and the answering machine invented in the same year!?
Yup. They were beastly electro-mechanical things about the size of a VCR.
Believe it or not, lots of technology existed before uP/uC's existed.
Take the automatic phone switch, for example... It was invented when a funeral home realized that the competitor's wife was working the switchboards and referring all businesses to him. It was basically a big rack of relays and switches.
What the hell? I was downloading porn from BBS's back in 1982. Sure, much of it were 7-bit ASCII graphics, but heck, it was digital content transferred over an information channel... Dang, where did I put those CP/M 5.25" floppies with them text files?
I had it good. I even had a daisy wheel that provided better looking output then them cheap 7 pin dot matrix text with no descenders.
For my situation, Telocty (aka DirecTVDSL) was the best deal from technical and economic standpoints. Damn. They offered rock-solid static IP service that was down for only 2 hours out of the last two years. Damn. Their autoconfiguring routers were a joy to use and get up and running. Damn. I really don't want to go to SBC/PacificBell(SpecificHell) for my connectivity. Oh gawd no. Damn.
An 18-wheeler is not usable by the average consumer.
A Toyota pickup truck is not usable by an interstate commercial carrier.
The power of general purpose computing is the ability to hide a powerful, complex, and feature-rich program behind a new-user-friendly interface. Someone just has to write the appropriate front end.
Of course, it does help that large companies like Apple, Microsoft, and IBM can hire a team to maintain UI standards for their products. That's something the OSS community definitely lacks. Heck, "uniformity" runs counter to the chaotic free-for-all that marks the OS community.
Giong back to my vehicle analogy, the reason why cars are so popular is because the really critical UI has been standardized over the years. Gas pedal, brake pedal, PRNDL, steering.
I rode a Japanese maglev demo track in Japan, around 1985. The system worked very well, and I've been a believer ever since. It glides with an unspeakable smoothness. If you didn't look out the window, you wouldn't even know that you're in motion. (Well, except during speed changes -- during departure "takeoff", you're pinned to your seat like a jetline taking off, but without the jet's vibrations.)
To declare the maglev dead on the basis of the costs and untested-ness of the first designs is ridiculous. The first commercial jet airplanes were expensive and guzzled fuel -- and the industrial infrastructure wasn't yet there. Many years later, with successive refinements in technology, and gearing up of supporting industries, modern jetliners have pushed down the costs of travel and transport to incredible new lows.
When the Havilland Comet and the Boeing 707's first came they were immediately popular, but had their share of detractors. It took successive generations of planes, notably the popular 727's and the 747's to really show off the potential of jetliners.
And then there's the fleets of 737's that let's us now freely move about the country on low-cost airlines.
Granted, train tracks are fixed and can not be "rerouted" to quickly adapt to changing markets. But where there are markets with enough current air/car traffic (Eastern sea-corridor being the obvious one; So/No. California and Las Vegas being a likely candidate), the maglev is a potential optimization.
I for one would love to use the Maglev to go from L.A. to S.F. Trains are likely to have higher up-time and lowered cycle time compared to airplanes, and would more likely have last-minute "walk on" convenience (even in today's security-minded environment).
Let's just be glad the Chinese are willing to take the first-mover disadvantages on new technology problems and costs (they clearly want the first mover advantage on prestige and willing to pay for that). From their experience, only improved systems can result!
One possibility that comes to mind is that you are at a place that is too big for you to immediately "move up" and take the reigns of network administration. You might need to move to a smaller organization where you can apply your current skills in sysadmin 20%, and then devote the other 80% to expanding your skills to networking and management (of systems and networks).
It's sort of like the navy -- to go up in the ranks, you sometimes have to move to a smaller ship!
There's been a growing shift of attention to embedded devices in the last few years. In the last five years or so, we're starting to see Joe Consumer spend more time with their embedded computers:
Palm Pilots and Handheld PC's. Smart Cell phones (with games and cameras, even!). Sophisticated set-top boxed. In-car navigation/entertainment systems. Portable entertainment and recreational technology.
One of the reasons Microsoft went into developing WindowsCE is the realization that there is consumer demand for lower-performance systems that are also less resource-intensive.
AMD is going after some of this market -- witness their acquisition of Alchemy -- the Au1x core cranks out 500 MIPS of processing at 1 Watt. (Heck, at lower speeds, you can almost get down to 1/4 watt.) And does it much cheaper than Intel or Motorolla.
AMD also came out with their new 802.11b chipset that will wifi-enable the next generation of portable gadgets, reducing processor overhead and power demands.
AMD should stop trying to compete head on only int he PC Market. There's a lot of money selling silicon for other applications.
I'd rather see these on prime-time TV than glorified remote-controlled chainsaws destroying each other... The views of the horizon gliding into place is absolutely breathtaking!
I read in Frontline that one of the holy grails is to get "smart staples" that you would attach to printed documents (even one page documents) that would allow tracking of paper documents -- the price target for that application is $0.02 per tag.
It depends on what you want to do -- but when you are running on a resource limited platform to run only a handful of programs (as is often the case with embedded systems), the memory footprint of the shared library does matter.
Also, it turns out that glibc and uclibc have different startup code, and the startup code for uclibc is smaller than that for glibc.
Hrmph. I think joto got the short stick from moderators...
I think he's right -- it used to be that console based WP's were popular because it required less resources and ran much faster than GUI WYSIWYG WP's. But that was back in the days when console-mode VGA ops were still magnitudes faster than rendering the same text on the graphics-mode VGA.
Times have changed -- with HW acceleration, gobs of memory, and 2,000 MHz PC's (with much faster execution clock counts), there's just no market (community) need for new WP's to be text-based.
What's wrong with WordPerfect? There has been Linux, DOS and SCO versions that could certainly run fine on a 486.
With new Linux PC's selling for $200 at Walmart, it's hard to believe someone would take poverty so seriously as to try to make do on a 486 *and* try to run the latest linux.
Of course, maybe I'm missing the original poster's intention. Maybe he's homebrewing an uber-Tandy-Model-100 using recycled 486 parts and a FLASH drive... And he intends to have a 40x12 LCD as his console... But I somehow doubt that...
Heh - I guess I left out an important bit of data...
We built static glibc because we couldn't fit the glibc shared libraries on to our fs -- glibc libraries totaled to 11 MB. uClibc's libraries totaled to 1 MB.
My embedded system just had enough room to store about 4 MB of files. That made using shared glibc impossible, and statically-linked glibc usable for a few programs. After uclibc, we crammed in a heck of a lot more programs.
Mind you, there are other solutions to cramming the code. There are library "reducers" (I think they're called?) that will analyze a collectino of programs and build a partial glibc that only contain routines used by your programs.
A lot of the thanks should go to the work by uClibs and Busybox maintainers. Trimming the kernel is important, but the big savings in size is indeed the small footprint of the C libraries and the "combined" busybox binary.
How much space saving? Well, at my work, we initially prototyped some programs that ended up at around 1 MByte, statically linked to glibc. The same program was 120K after statically linking to uclibc, and then 35K after dynamic linking to uclibc.
I know there's various individual efforts out there to re-build Debian around uclibc. Imagine being able to put a full-featured Debian package on a business-card-sized mini-CD's that you can always keep in your wallet!
What's so wrong about having the GUI stored in the database? It's not like you can't download once to the local client... Heck, AOL's been doing that for years!
Just because there's a database in the center of everything, doesn't mean the clients can't cache data locally....
Sure, there are times when writing an RDBMS-based solution seems like a big overhead. But there's a good reason for using RDBMS on projects that are likely to mutate and add new features over time, and/or have to interoperate with other programs and systems.
On the other hand, if you just want to stores a small array of data that fits in a 100 line text file, and the program is completely closed and self contained, there's no need for the flexibility of a RDBMS.
Imagine a business that has to "send and receive stuff"...
If you're moving two or three little packages to nearby local area businesses, only, you can get by with a small car.
But imagine your regularly ship objects large and small to locations local and international... Then you need an intermodal transportation system. Sure, your interface might be "the shipping guy", but the backbone of the transportation is heavy duty...
Boy, 5 GB doesn't sound like much these days... though I suppose it's plenty enough to back up critical data. Although drives are certainly getting bigger and getting filled up, a lot of that is non-critical cruft and bloated software that can be reinstalled from source. So, maybe 5 GBytes is okay...
One thing I worry about is the reliability of RW media. How many erase/write transitions can a DVDRW blank take? And how long does it take to "reformat" the medium and to write everything back on again?
According to the DVD+RW alliance, 2.4x DVD write is 3.32 MBytes/sec. That's faster than 2.5MBytes/sec of DLT, but tape drives erase-and-write at the same time. Supposedly AIT's sustain 4MBytes/sec (but I just looked this up, and I have never used AIT's).
Price out the cost of different automated backup systems, figure out the cost per MB, and then "sell" the different quality levels of storage the teams that are gobbling up disk space.
Slashdot Mirror
I'm the moron that suggested the motor oil... Personally, I think my flux tastes like peanut oil...
Hey, it works to keep the aluminum from oxidizing while soldering. And since I have motor oil and solder, but not conductive epoxy at hand, that's easier for me.
And, yes, he can try getting lithium coins from Digikey. But I assumed that if it was a standard battery with tabs, he'd have found it pretty easily.
Well, if it's just the matter of a tab on the thing, just take an electrically compatible coin battery, and solder on a piece of wire...
This assumes, of course, that the problem is with the battery. Are you sure about that?
Anwyays, there is a trick to soldering a wire onto batteries -- the aluminum doesn't like being soldered -- first, clean the surface thorougly using a fine abrasive to throughly remove the oxide layer and make sure it doesn't get contaminated.
Next, pour liquid flux (or in an emergency, a drop of motor oil) onto the aluminum, taking care to avoid trapping air under the oil.
Then, with a soldering iron, apply a good dose of melted solder onto the flux-covered spot. Then, attach the wire to the solder.
Good luck.
This spam did not interest me, specifically (because my son isn't into toys like that), but my coworker (who also has a 7 year old), who actually ordered some these cars, went on to say "Yeah, for once, some spam was actually useful. Go figure." Go figure, indeed.
Except that if he bought it from the spammer's, he's likely paying $29.95 for the lower-quality Chinese "knockoffs" which I can go downtown and buy a dozen for $66 from "cash-and-carry" distributors. Hell, for real wholesalers, the real cost is even lower.
the microprocessor and the answering machine invented in the same year!?
Yup. They were beastly electro-mechanical things about the size of a VCR.
Believe it or not, lots of technology existed before uP/uC's existed.
Take the automatic phone switch, for example... It was invented when a funeral home realized that the competitor's wife was working the switchboards and referring all businesses to him. It was basically a big rack of relays and switches.
What the hell? I was downloading porn from BBS's back in 1982. Sure, much of it were 7-bit ASCII graphics, but heck, it was digital content transferred over an information channel... Dang, where did I put those CP/M 5.25" floppies with them text files?
I had it good. I even had a daisy wheel that provided better looking output then them cheap 7 pin dot matrix text with no descenders.
For my situation, Telocty (aka DirecTVDSL) was the best deal from technical and economic standpoints. Damn. They offered rock-solid static IP service that was down for only 2 hours out of the last two years. Damn. Their autoconfiguring routers were a joy to use and get up and running. Damn. I really don't want to go to SBC/PacificBell(SpecificHell) for my connectivity. Oh gawd no. Damn.
Part of the problem is the meaning of "usable".
An 18-wheeler is not usable by the average consumer.
A Toyota pickup truck is not usable by an interstate commercial carrier.
The power of general purpose computing is the ability to hide a powerful, complex, and feature-rich program behind a new-user-friendly interface. Someone just has to write the appropriate front end.
Of course, it does help that large companies like Apple, Microsoft, and IBM can hire a team to maintain UI standards for their products. That's something the OSS community definitely lacks. Heck, "uniformity" runs counter to the chaotic free-for-all that marks the OS community.
Giong back to my vehicle analogy, the reason why cars are so popular is because the really critical UI has been standardized over the years. Gas pedal, brake pedal, PRNDL, steering.
The's a whole bunch of ways to cool things. It's just a matter of what works for a particular application.
Thermo-acoustic cooling has been considered for use in space to reduce the weight and mechanical complexity of traditional refrigeration systems. iirc, there was also the advantage of using less dangerous/toxic gasses with acoustic cooling.
I rode a Japanese maglev demo track in Japan, around 1985. The system worked very well, and I've been a believer ever since. It glides with an unspeakable smoothness. If you didn't look out the window, you wouldn't even know that you're in motion. (Well, except during speed changes -- during departure "takeoff", you're pinned to your seat like a jetline taking off, but without the jet's vibrations.)
To declare the maglev dead on the basis of the costs and untested-ness of the first designs is ridiculous. The first commercial jet airplanes were expensive and guzzled fuel -- and the industrial infrastructure wasn't yet there. Many years later, with successive refinements in technology, and gearing up of supporting industries, modern jetliners have pushed down the costs of travel and transport to incredible new lows.
When the Havilland Comet and the Boeing 707's first came they were immediately popular, but had their share of detractors. It took successive generations of planes, notably the popular 727's and the 747's to really show off the potential of jetliners.
And then there's the fleets of 737's that let's us now freely move about the country on low-cost airlines.
Granted, train tracks are fixed and can not be "rerouted" to quickly adapt to changing markets. But where there are markets with enough current air/car traffic (Eastern sea-corridor being the obvious one; So/No. California and Las Vegas being a likely candidate), the maglev is a potential optimization.
I for one would love to use the Maglev to go from L.A. to S.F. Trains are likely to have higher up-time and lowered cycle time compared to airplanes, and would more likely have last-minute "walk on" convenience (even in today's security-minded environment).
Let's just be glad the Chinese are willing to take the first-mover disadvantages on new technology problems and costs (they clearly want the first mover advantage on prestige and willing to pay for that). From their experience, only improved systems can result!
One possibility that comes to mind is that you are at a place that is too big for you to immediately "move up" and take the reigns of network administration. You might need to move to a smaller organization where you can apply your current skills in sysadmin 20%, and then devote the other 80% to expanding your skills to networking and management (of systems and networks).
It's sort of like the navy -- to go up in the ranks, you sometimes have to move to a smaller ship!
There's been a growing shift of attention to embedded devices in the last few years. In the last five years or so, we're starting to see Joe Consumer spend more time with their embedded computers:
Palm Pilots and Handheld PC's.
Smart Cell phones (with games and cameras, even!).
Sophisticated set-top boxed.
In-car navigation/entertainment systems.
Portable entertainment and recreational technology.
One of the reasons Microsoft went into developing WindowsCE is the realization that there is consumer demand for lower-performance systems that are also less resource-intensive.
AMD is going after some of this market -- witness their acquisition of Alchemy -- the Au1x core cranks out 500 MIPS of processing at 1 Watt. (Heck, at lower speeds, you can almost get down to 1/4 watt.) And does it much cheaper than Intel or Motorolla.
AMD also came out with their new 802.11b chipset that will wifi-enable the next generation of portable gadgets, reducing processor overhead and power demands.
AMD should stop trying to compete head on only int he PC Market. There's a lot of money selling silicon for other applications.
I'd rather see these on prime-time TV than glorified remote-controlled chainsaws destroying each other... The views of the horizon gliding into place is absolutely breathtaking!
I read in Frontline that one of the holy grails is to get "smart staples" that you would attach to printed documents (even one page documents) that would allow tracking of paper documents -- the price target for that application is $0.02 per tag.
It depends on what you want to do -- but when you are running on a resource limited platform to run only a handful of programs (as is often the case with embedded systems), the memory footprint of the shared library does matter.
Also, it turns out that glibc and uclibc have different startup code, and the startup code for uclibc is smaller than that for glibc.
Hrmph. I think joto got the short stick from moderators...
I think he's right -- it used to be that console based WP's were popular because it required less resources and ran much faster than GUI WYSIWYG WP's. But that was back in the days when console-mode VGA ops were still magnitudes faster than rendering the same text on the graphics-mode VGA.
Times have changed -- with HW acceleration, gobs of memory, and 2,000 MHz PC's (with much faster execution clock counts), there's just no market (community) need for new WP's to be text-based.
What's wrong with WordPerfect? There has been Linux, DOS and SCO versions that could certainly run fine on a 486.
With new Linux PC's selling for $200 at Walmart, it's hard to believe someone would take poverty so seriously as to try to make do on a 486 *and* try to run the latest linux.
Of course, maybe I'm missing the original poster's intention. Maybe he's homebrewing an uber-Tandy-Model-100 using recycled 486 parts and a FLASH drive... And he intends to have a 40x12 LCD as his console... But I somehow doubt that...
Heh - I guess I left out an important bit of data...
We built static glibc because we couldn't fit the glibc shared libraries on to our fs -- glibc libraries totaled to 11 MB. uClibc's libraries totaled to 1 MB.
My embedded system just had enough room to store about 4 MB of files. That made using shared glibc impossible, and statically-linked glibc usable for a few programs. After uclibc, we crammed in a heck of a lot more programs.
Mind you, there are other solutions to cramming the code. There are library "reducers" (I think they're called?) that will analyze a collectino of programs and build a partial glibc that only contain routines used by your programs.
A lot of the thanks should go to the work by uClibs and Busybox maintainers. Trimming the kernel is important, but the big savings in size is indeed the small footprint of the C libraries and the "combined" busybox binary.
How much space saving? Well, at my work, we initially prototyped some programs that ended up at around 1 MByte, statically linked to glibc. The same program was 120K after statically linking to uclibc, and then 35K after dynamic linking to uclibc.
I know there's various individual efforts out there to re-build Debian around uclibc. Imagine being able to put a full-featured Debian package on a business-card-sized mini-CD's that you can always keep in your wallet!
Here's the corrected link.
$99 from HelloDirect. Cheaper elsewhere, I'm sure.
http://www.hellodirect.com/catalog/Product.jhtml?C ATID=2011&PRODID=13669
I used to get sales calls...
... so I got the SalesCall Buster.
... and I had to go get a SalesCall Buster Buster.
... and they're gonna get me now, I know it!
But then they got the SalesCall Buster Buster...
But now, they're armed with the SalesCall Buster Buster Buster...
What's so wrong about having the GUI stored in the database? It's not like you can't download once to the local client... Heck, AOL's been doing that for years!
Just because there's a database in the center of everything, doesn't mean the clients can't cache data locally....
Sure, there are times when writing an RDBMS-based solution seems like a big overhead. But there's a good reason for using RDBMS on projects that are likely to mutate and add new features over time, and/or have to interoperate with other programs and systems.
On the other hand, if you just want to stores a small array of data that fits in a 100 line text file, and the program is completely closed and self contained, there's no need for the flexibility of a RDBMS.
Imagine a business that has to "send and receive stuff"...
If you're moving two or three little packages to nearby local area businesses, only, you can get by with a small car.
But imagine your regularly ship objects large and small to locations local and international... Then you need an intermodal transportation system. Sure, your interface might be "the shipping guy", but the backbone of the transportation is heavy duty...
Never under-estimate the bandwidth of a plane full of CD's... ...or the CD-RW drive at your nearest Internet Cafe.
Boy, 5 GB doesn't sound like much these days... though I suppose it's plenty enough to back up critical data. Although drives are certainly getting bigger and getting filled up, a lot of that is non-critical cruft and bloated software that can be reinstalled from source. So, maybe 5 GBytes is okay...
One thing I worry about is the reliability of RW media. How many erase/write transitions can a DVDRW blank take? And how long does it take to "reformat" the medium and to write everything back on again?
According to the DVD+RW alliance, 2.4x DVD write is 3.32 MBytes/sec. That's faster than 2.5MBytes/sec of DLT, but tape drives erase-and-write at the same time. Supposedly AIT's sustain 4MBytes/sec (but I just looked this up, and I have never used AIT's).
Price out the cost of different automated backup systems, figure out the cost per MB, and then "sell" the different quality levels of storage the teams that are gobbling up disk space.