A single dnet client cannot cost 59 cents a second, and neither can a single email.
Unless it's stolen bandwidth, in which case the victim can charge the highest plausible rate for the bandwidth itself. They can also charge pretty much arbitrary prices for the inconvenience and other losses suffered as a result of the unavailability of the bandwidth.
Let's also remember that we don't know what basis that $0.59/minute cost includes. The perpetrator was very vague on this, probably in an attempt to shift blame to the victim. It may include the aggregate cost of several items:
Machine integrity. Reformatting and reinstalling hundreds of machines.
Data integrity. Sanitizing every single piece of data stored and handled by the compromised machines during the period of compromise.
Loss of reputation. Decreased revenues when partner organizations learn that the victim's information infrastructure was compromised. (Yes, I know it's a school. Schools have revenue just like any other business, and depend on their reputations for income.)
Downtime. The victim is under no obligation to minimize recovery costs or live with the compromised system for a millisecond longer than necessary. The moment they learn of the compromise, they can shut down every compromised machine immediately, and it may take several days for technicians to become available to start doing anything. They can keep the entire network shut down until every single machine has been reinstalled from scratch and all the data has been sanitized. The personnel who jobs revolve around using the machines can be furloughed for the duration. The attacker could potentially end up being responsible for the entire operating costs of the organization for several weeks.
Costs of investigation. Due diligence, especially of a public organization, demands that skilled investigators be immediately put to work on the case, as well as a team of lawyers. This sort of skilled assistance can easily cost $500/hour.
Come on, people. Walking into a building full of hundreds of computers and personally compromising the security of each one at its console is *stupid*. It's like trying to rob a police station.
...the PS2 has basically turned out to be, although a marketing success, a major letdown technically.
It's the software. I've seen the hardware render *nice* graphics, so I know what it's capable of. The problem is that the hardware is very complex and cuspy, and Sony didn't provide good abstractions and libraries. The toolkit vacuum has left game companies flailing about reinventing the wheel. Since truly inspired engine designers are rare, the first couple of years of games are basically mediocre rehashes no better than the PS1 state of the art. It's only in the last 6 months that truly excellent engines have been developed, and it will take another full development cycle for them to be sublicensed and incorporated in other games, and another development cycle after that for them to become prevalent.
The distinction is that Linux doesnt RUN the mainframe.
Exactly. VM runs the S/390 machine, and the Linuces run in sandboxes where they can't blow everything away. Sigh. I wish the PC hardware architecture would support something like VM...
OTOH, this Scientific American article says that he left Japan for UC Santa Barbara because he considers the Japanese industrial R&D system as "communist". "Here I can start a venture company-in five or 10 years, if I could invent a new device. I want to achieve the American dream."
Zoho.com was one of the companies in the article. This is their page on monster.com.
And here's what you'll get as a Zoho employee: The opportunity to be a part of something truly cutting edge, under the leadership of a truly focused, mature executive team.... So, if you've been searching for a successful career with an industry leader, look no further. Zoho gives you the chance to grow your skills as a professional in a unique environment that blends startup excitement with blue chip stability.
Admit that Apple did something right, for once: the Mac OS, up to and including X, will never show cryptic messages or break out of the GUI unless you give it a direct order to do so or a fatal error occurs.
You can get away with poor brittle engineering if you are willing to tightly restrict the hardware that is used. OS X runs on, what, a single CPU architecture and half-a-dozen machine variants? Linux runs on half-a-dozen architectures and tens of thousands of machine variants. It is *normal* for commodity PC hardware to randomly blow up and do weird things, and being able to handle it without training people to press special key combinations is *good*.
This is a good thing, it makes the experience seamless and friendly. Remember that consumers don't care about what drivers got loaded when...
Until some random driver wedges for 5 minutes during boot up or shut down, as it eventually will on commodity no-name hardware. If you can see a message for which thing is wedging, you are 99% of the way towards solving the problem. OTOH, with the Windows/Mac approach, the poor end-user will need a trip to the technician for a reformatting. Transparency and diagnosibility are Good Things.
I personally don't think it's a huge deal on an internal network if you can trust the people;
Two points: 1. On a large network, you *can't* trust the people. 2. There will be compromised machines on a large network.
we've got a switch,
Switches are somewhat overrated, esp. in an environment of corporate novices. Compromise a box. Use nmap to identify the active netblocks. At the start of each day, agressively ARP as a single box. As soon as somebody tries to login to the box, record their password and stop ARPing. The login won't work, they'll try again and it will work, and they'll write off the failure to the vagaries of computers. A couple of weeks of this, and the organization is 0WN3D.
Granted, now that I'm looking at reconfiguring everythign to allow outside access to my box, I'm having second thoughts....
Interrupt handling does not exist at the user level, nor should it.
Signals could be used, although that would be ugly.;-) A special lightweight signalling mechanism might be a solution. E.g., you could wake up a sleeping X server when the interrupt occurred. That'd take minimal kernel involvement, and at least for Linux switching to the X server process wouldn't be particularly slower than switching to a kernel timer handler.
Also, I believe we're talking about two different points here. You are referring more to the interface between the running program and X. I'm talking about the interface to pass data to the graphics card quick and efficiently.
I was talking about both. For the latter, X is about as fast as possible: it jams the data directly into the video card and twiddles the bits as appropriate. That code is about as fast as possible.
And by the way, all the 3-D rendering and texturing in the world is not going to speed up 2-D frame based applications...i.e. live video etc...and it's a fact that X does not perform well in this area...
Triangles, motion compensation, bitblts, whatever. It's all just math. If somebody comes up with a new acceleration mode, just write an X extension for it.
If you write a video (movie player, etc..) app in Windows and in X. The Direct Show interface to the graphics hardware will win hands down...sorry to say it, I love Linux, but Windows wins that one...
You've hit the nail on the head, sort of. Ugly as they are, the Windows multimedia timers and real-time priorities rock for audio and video. The problem is not userland vs. kernel, it is that Linux has historically been optimized for good batch-mode performance and processor sharing. Windows goes to great efforts to schedule processes *exactly* when they want to be scheduled, and allows them to coopt the entire system if they want to. These are diametric opposites.
I think it's really just a matter of time. Linux has only been a serious desktop contender for a couple of years, whereas Microsoft has been one since the early 80s and Gates's dream of 'a computer on every desk' (remember that catchphrase?). Linux/XFree86 multimedia stuff has so far had a few tens of millions of dollars spent on it; hundreds of millions has been spent on Windows. Hell, it's just in the past couple of years that the video card vendors have started actually cooperating with XFree86. Honestly, if we were willing to spend a couple of billion on X and throw it away three or four times over a period of about eight years, it would reach Window's state of performance: fast but inflexible. I'm willing to settle for steady progress and flexibility.
Reposting the parent comment because it makes an *excellent* point about 1.2 GHz logic, but is rated 0 and therefore won't be seen by many people:
Plus, at a 1.2GHz external bus, you start to run into speed of light limitations. The clock cycle at 1.2GHz is about 833ps. During that
time frame, light travels about 10 inches (25cm). Compare that to a 266MHz bus, where the cycle time is about 3.5ns. You get just
over a yard. Also, consider that you have to cycle from high to low and back to high in that time frame, so (I think) that at 1.2GHz,
your traces can't be any longer than about 5 inches, whereas at 266MHz, you can have 18inch traces.
On a side note, it's nice that the *nix's have this graphical server, but if they, and most specifially Linux, are going to make it in the desktop world, X needs to go.
Have you actually done X programming, or are you just repeating 'common wisdom'.
It's nothing short of a mess how these graphics card drivers have to deal with communicating between user and kernel space.
X servers (generally) run as root and have TOTAL access to the graphics hardware. The video driver portion could not possibly run faster, even if it ran in kernel mode. At the same time, since X runs in userland, a wild pointer or lockup stands a good chance of only killing the X server. If it was in the kernel, it would stand a good chance of causing deep file system and data corruption.
The latter point is not academic. I've actually done debugging on XFree86, and it's a simple kill-edit-compile-restart debugging cycle. Few system crashes, little rebooting.
X is an app, and what we really need is something on the system level to compete in the desktop market.
X being an app can actually speed things up. A complex draw that invovles numerous graphics operations can be built up in a buffer, then sent to the X server in one fell swoop. A system-call based architecture like Microsoft Windows generally requires one system call for each graphics primitive, which can be hellishly slow.
...and what we really need is something on the system level to compete in the desktop market.
In a few years, gigabit Ethernet, bazillion polygon/frame graphics cards, and monster Ethernet switches will be ubiquitous and dirt cheap. At that point, the centralized administration benefits of X will be tremendous, and the resource cost will be negligible. Even if X did have the supposed performance penalties today, they don't matter in the long run.
Everything was great until some dork in Network operations found out we were using X11 across the "enterprise network". I learned something very important during the week following this revelation- X terminals are like Unix- they suffer from a bad name.
X terminals are like telnet: less than total security competence, or a momentary brain fart, and a sniffer gets your passwords. If you're a sysadmin, the organization is screwed. Random people doing remote logins gives me the heeby-jeebies.
Non- Unix users don't give a damn about the power of X. They don't get why it's useful or appreciate the advantages.
They don't know about the power of X. All they've ever seen is Microsoft Windows on the console. Let them play with VNC or Terminal Server, though, and you'll make them true believers.
Vaporware. The best current technology can only do 64-bits @ 1.2GHz for a few millimeters inside a CPU. Extending that to 20 centimeters on commodity circuit-board materials will take technology that does not exist and will not exist for a long time.
Yeah, K, but the next paragraph describes how they expect this to put them solidly in the red (or keep them there) for the next entire fiscal year.
True, but their burn rate will be lower. They'll be spending money from cash accounts, but it will be at a much lower rate than the hardware business which is currently hemorraghing red ink.
Of course "Revenue != profit," but it seems a strange move indeed to abandon what you acknowledge to be your strongest revenue stream.
Profit is god, revenue is nothing. If a business is losing money and has no prospects of ever becoming profitable -- as their hardware business was -- you have to kill it.
Anyway, I'm not an insider at VA, I don't know what they're thinking, but this seems to indicate that there's major trouble within.
I know exactly what they're thinking: hardware is not profitable, and has no prospects of becoming profitable. Once you reach a consensus on that fact, the only logical path is eliminating that business. It doesn't matter how much revenue there is if it's being collected at a net loss. This allows resources to be concentrated on business areas that have a chance of becoming profitable. It also gives them more burn time to develop the businesses that have a chance of becoming profitable.
A move like this takes guts. Plenty of companies would keep pissing away money on the failing business area out of habit, or out of fear of change. It's a good sign that they are willing to face the facts and make cold, calculating decisions. If they succeed in turning themselves into a profitable open source powerhouse, today will be remembered like Microsoft's famous Internet reorientation.
The majority of apps out there do not need the memory that a 64 bit address space can get them. I dont know of many web servers that have more than a gig of ram in them, do you?
You can buy 1 gig DIMMs today. That means that in ~3 years (late 2004), a single high-end DIMM will use all of a 32-bit CPU's address bits. That's a brick-wall limit for the 32-bit architectures, a limit that cannot be broken no matter how much money you have to spend.
IMHO, it's not a theoretical limit. There are plenty of database servers today that would cheerfully use 8 gigs. Likewise for scientific and engineering programs. Late 2003 will see this market really open up, and whoever can ship >32-bit boxen will be able to collect $100s per system in pure profit. Whoever doesn't pursue 64-bit will see themselves locked out of a lucrative market. The big chip makers see this brick wall, and that's why everybody is developing 64-bit CPUs.
I don't understand why the Linux community shuns C++.
They don't. They just have a long history of using C, and the C++ compilers were poor for a long time.
If you ask me, GTK being based on C is a critical weakness.
It's a critical strength. The GTK+ object model is much more flexible and general than the C++ model. C also makes GTK+ more portable: it is trivial to port to any platform that has a C compiler and Xlib. Actually, GTK+ isn't tied strongly to Xlib -- it abstracts the low-level graphics stuff into Glib. Glib has been ported to Win32.
C++, if used correctly, removes complexity.
The C stuff is infrastructure that most app developers rarely need to touch. If you want to write your app in C++, just use one of the C++ bindings.
Language bindings are actually a good argument for writing GTK+ in C, since just about every language can call C libraries, but calling C++ libraries is usually considerably painful. This approach also shines for languages like Python and Scheme, whose flexible object model and typing are a good fit to the GTK+ object model.
Re:Disappearing lines on maps
on
LED Flashlights
·
· Score: 2
Diodes need to overcome a certain critical voltage (the reverse bias voltage) before they let more than nanoamps of current through (~.7 volts for silicon at room temperature).
(It's 'forward voltage drop', but we understand.)
I was actually referring to the weird properties of tungsten-filament incandescent lamps: First, their resistance increases as the filament gets hotter. Second, their ability to get hot (and therefore produce light) depends on having a sufficiently high resistance. When one is first turned on, it has a low resistance because it's cold and therefore draws a large current. As it warms up, the resistance goes up, and the current drops to a more reasonable level. Unfortunately, this means that if the battery doesn't have enough 'ooomph' to supply the large startup current, the filament will never get hot enough to glow.
What happens with LEDs is that, as the battery nears exhaustion and starts approaching the forward voltage drop, less and less current flows through the LEDs and they become fainter. However, the forward voltage drop isn't the cause: the battery running out of juice is.
The cool thing is that if you matched the LEDs and resistors to the battery, the current will start to drop just as the battery is getting dangerously low, which reduces the load on the battery just when it is running out of energy. This means that the LEDs get dim towards the end, and make that last little bit of energy last a long time. (BTW, this holds for regular alkaline batteries only. Ni-cads will die much faster.)
Perhaps you meant to say that they work well at low currents.
That's true too: LEDs usually have the highest quantum efficiency (photons per electron) at the lowest currents. This is a double bonus: not only do they preserve the last little bit of energy in the battery, they use it more efficiently. The net effect is that LED lamps gradually dim over tens of hours, while incandescent lamps just suddenly go dead over the course of maybe 15 minutes.
Plans for 4 D cell LED flashlight
on
LED Flashlights
·
· Score: 2
Unfortunately, I haven't written it up. Maybe I'll get around to it someday. The hardest part was disassembling the Maglite: you have to pry out the rubber button over the power switch, and then stick a long Allen (hex) key through the hole in the button and loosen a set screw. This frees the switch/bulb holder assembly, which can then be slid out the bottom of the tube (the end where you put in batteries). I learned this the hard way by removing the snap ring above the switch assembly and driving it out from below! Needless to say, that ruined it, but I learned what to do the next time.
Re:Disappearing lines on maps
on
LED Flashlights
·
· Score: 4
Ha! Yes, LEDs are very monochromatic. For map reading (or working on electrical wiring, etc.) you'd be wise to get a lamp with multiple colors of LEDs. I've seen the 'disappearing ink' effect with the LED flashlight I built (4 D cell Maglite case, 56 ultra-bright red LEDs from Digi-Key). In a dimly lit room, I drew a red, a green, and a blue dot on a whiteboard. When I light them with the LED flashlight, the red dot totally disappears. It's a very cool effect.
Somebody asked above how well LED flashlights work. Mine is blindingly bright: looking into the beam at close range produces a dazzle effect like a flashbulb, complete with sparkly afterglow. I used highly-focused LEDs: it makes a beam about 2 feet across at a distance of 10 feet. Unfortunately, since the human eye isn't very sensitive to red, the beam doesn't appear very bright, but it's plenty good enough to see with at night. Battery life is very good: I gave up trying to run it down after 24 hours, although there was noticeable dimming by that point. One good thing about LEDs is that they simply grow dimmer as the battery runs down, unlike incandescents which have a tendency not to glow at all once the voltage falls below a critical point.
I agree in principle, but it would be a difficult, risky lawsuit. Unless you just enjoy fighing lawsuits, it is better to assume that the binary is a derived work of the headers.
To use a DLL, you have to have header files for the exported functions, as well as any symbolic constants used with those functions. For the purposes of copyright law, any binary compiled with those headers is a derivative of them, and therefore affected by the license of the headers.
If those headers come from the original VirtualDub package, they are protected by the GPL, and any binary compiled with them is therefore subject to the GPL.
On the other hand, if SloMedia created their own headers from scratch, those headers are not protected by the GPL, and the binary is therefore not a derived work.
Also as I said before, mentioning security will remind people that they have no idea if it is secure. After all anything claiming to be secure in the past seems to have had later announcements about how it's not exactly as secure as first claimed...
True. If I were doing it, I'd publish the security info so interested parties could review it for themselves.
Ok, if they spin their own silicon they might be able to do it, I don't own one of those things, so I can't check to see if it is all off the shelf parts, or has any custom ICs, or even FPGAs.
I don't know either. I would suspect they used one of the many wireless chips that are available, but there is enough profit margin and the market is small enough that they could have rolled their own radios.
I'm assuming these small area designs have been openly published and withstood attack? Or are small area designs of real cyphers...
Well, there are the multiple LFSR ciphers which can be implemented in a few hundred transistors. Bluetooth uses this type, precisely because it takes a trivial, albeit custom, amount of silicon to implement. These aren't the greatest ciphers, but they can be decent. Schneier's Twofish cipher was specifically designed to fit into smart cards and uses very few resources.
You need long term storage to hold the key (FLASH, NVRAM, whatever),...
True. But that wouldn't add much cost, especially if they microcontrollers already include a little EEPROM.
...and if it is battery backed you will need that cable again in a few years, or there is another 800 call.
Battery backed == bad. If it's not EEPROM, I'd say don't bother. As for replacing the cable, it would be a wire with a mini banana plug on each end. The customer could replace it themselves with a piece of 18 AWG solid wire with the insulation stripped off each end. Or you could sell them a replacement (which replacement would have a breathtaking profit margin).
Hmm...I sense a business plan. All these little gizmos, like remote controls, garage door openers, Bluetooth cards and telephones, game controllers, SPIKE gizmos, and so forth have one thing in common: for proper security, they need a hardware key-exchange system. Which means a cable. Which means an enormous business selling cables. Which means that cable companies could give away strong encryption as a loss-leader, and make it up with a captive market for synchonization cables.
I haven't actually seen one of these keyboards, but I was thinking of a design that has a small dongle that plugs into the back of the computer with little or no cabling. To get at the contacts, you'd have to turn the machine around and touch a keyboard to it. That's possible, but a real PITA.
As for the iButton/1-wire/MicroLAN stuff from Dallas, I've played with it. They have some really cool devices. Their superfast 8051-compatible microcontrollers are neat too.
But for any real Van Eck threat, my point stands. You lose 6 dB of signal every time the distance doubles, which will easily cost you an additional 6 dB of money and effort each time.:-) By the time you're sitting in a van on the street outside, you're looking at NSA-style budgets.
It's only expensive if you use MIL-SPEC equipment designed by gov't contractors. Switch to ham radio equipment, a commercial digital o'scope board, and homebrew, and it's a few thousand dollars tops. I.e., within the budget of anybody who wants to take the time to do it. Think Pinkertons. Think Church of Scientology. Think drug dealers. Think credit card fraud rings.
Anything that increases the cost has to increase sales.
Logitech could have put in good encryption, and talked up the weakness of their competitors. One press release per weak about how your competitors are betraying the public can drum up a lot of business.
You won't be able to shoehorn much encryption into the tiny CPU that decides keystrokes and drives a little RF and emulates the original keyboard controller.
Wrong. Lots of work has been done to stuff good encryption in tiny CPUs. Think smart cards. In particular, ciphers that use multiple LFSRs require miniscule amounts of silicon.
Plus it is hard to imagine anything simple that works out of the box...
Yeah, running a wire between them for a moment when it's first installed is *so* hard...
I mean look at the problems 802.11's WEP has, and it is on a $100 and up device!
WEP was designed by a microcephalic crack-smoking monkey. Price had nothing to do with it. It is poor entirely because it's designers had essentially no understanding of cryptosystem design, and they didn't bother to have it reviewed by experts.
Slashdot Mirror
Let's also remember that we don't know what basis that $0.59/minute cost includes. The perpetrator was very vague on this, probably in an attempt to shift blame to the victim. It may include the aggregate cost of several items:
Come on, people. Walking into a building full of hundreds of computers and personally compromising the security of each one at its console is *stupid*. It's like trying to rob a police station.
It's the software. I've seen the hardware render *nice* graphics, so I know what it's capable of. The problem is that the hardware is very complex and cuspy, and Sony didn't provide good abstractions and libraries. The toolkit vacuum has left game companies flailing about reinventing the wheel. Since truly inspired engine designers are rare, the first couple of years of games are basically mediocre rehashes no better than the PS1 state of the art. It's only in the last 6 months that truly excellent engines have been developed, and it will take another full development cycle for them to be sublicensed and incorporated in other games, and another development cycle after that for them to become prevalent.
OTOH, this Scientific American article says that he left Japan for UC Santa Barbara because he considers the Japanese industrial R&D system as "communist". "Here I can start a venture company-in five or 10 years, if I could invent a new device. I want to achieve the American dream."
I think it's really just a matter of time. Linux has only been a serious desktop contender for a couple of years, whereas Microsoft has been one since the early 80s and Gates's dream of 'a computer on every desk' (remember that catchphrase?). Linux/XFree86 multimedia stuff has so far had a few tens of millions of dollars spent on it; hundreds of millions has been spent on Windows. Hell, it's just in the past couple of years that the video card vendors have started actually cooperating with XFree86. Honestly, if we were willing to spend a couple of billion on X and throw it away three or four times over a period of about eight years, it would reach Window's state of performance: fast but inflexible. I'm willing to settle for steady progress and flexibility.
Plus, at a 1.2GHz external bus, you start to run into speed of light limitations. The clock cycle at 1.2GHz is about 833ps. During that time frame, light travels about 10 inches (25cm). Compare that to a 266MHz bus, where the cycle time is about 3.5ns. You get just over a yard. Also, consider that you have to cycle from high to low and back to high in that time frame, so (I think) that at 1.2GHz, your traces can't be any longer than about 5 inches, whereas at 266MHz, you can have 18inch traces.
The latter point is not academic. I've actually done debugging on XFree86, and it's a simple kill-edit-compile-restart debugging cycle. Few system crashes, little rebooting.
X being an app can actually speed things up. A complex draw that invovles numerous graphics operations can be built up in a buffer, then sent to the X server in one fell swoop. A system-call based architecture like Microsoft Windows generally requires one system call for each graphics primitive, which can be hellishly slow. In a few years, gigabit Ethernet, bazillion polygon/frame graphics cards, and monster Ethernet switches will be ubiquitous and dirt cheap. At that point, the centralized administration benefits of X will be tremendous, and the resource cost will be negligible. Even if X did have the supposed performance penalties today, they don't matter in the long run.Vaporware. The best current technology can only do 64-bits @ 1.2GHz for a few millimeters inside a CPU. Extending that to 20 centimeters on commodity circuit-board materials will take technology that does not exist and will not exist for a long time.
A move like this takes guts. Plenty of companies would keep pissing away money on the failing business area out of habit, or out of fear of change. It's a good sign that they are willing to face the facts and make cold, calculating decisions. If they succeed in turning themselves into a profitable open source powerhouse, today will be remembered like Microsoft's famous Internet reorientation.
IMHO, it's not a theoretical limit. There are plenty of database servers today that would cheerfully use 8 gigs. Likewise for scientific and engineering programs. Late 2003 will see this market really open up, and whoever can ship >32-bit boxen will be able to collect $100s per system in pure profit. Whoever doesn't pursue 64-bit will see themselves locked out of a lucrative market. The big chip makers see this brick wall, and that's why everybody is developing 64-bit CPUs.
Language bindings are actually a good argument for writing GTK+ in C, since just about every language can call C libraries, but calling C++ libraries is usually considerably painful. This approach also shines for languages like Python and Scheme, whose flexible object model and typing are a good fit to the GTK+ object model.
I was actually referring to the weird properties of tungsten-filament incandescent lamps: First, their resistance increases as the filament gets hotter. Second, their ability to get hot (and therefore produce light) depends on having a sufficiently high resistance. When one is first turned on, it has a low resistance because it's cold and therefore draws a large current. As it warms up, the resistance goes up, and the current drops to a more reasonable level. Unfortunately, this means that if the battery doesn't have enough 'ooomph' to supply the large startup current, the filament will never get hot enough to glow.
What happens with LEDs is that, as the battery nears exhaustion and starts approaching the forward voltage drop, less and less current flows through the LEDs and they become fainter. However, the forward voltage drop isn't the cause: the battery running out of juice is.
The cool thing is that if you matched the LEDs and resistors to the battery, the current will start to drop just as the battery is getting dangerously low, which reduces the load on the battery just when it is running out of energy. This means that the LEDs get dim towards the end, and make that last little bit of energy last a long time. (BTW, this holds for regular alkaline batteries only. Ni-cads will die much faster.)
That's true too: LEDs usually have the highest quantum efficiency (photons per electron) at the lowest currents. This is a double bonus: not only do they preserve the last little bit of energy in the battery, they use it more efficiently. The net effect is that LED lamps gradually dim over tens of hours, while incandescent lamps just suddenly go dead over the course of maybe 15 minutes.Unfortunately, I haven't written it up. Maybe I'll get around to it someday. The hardest part was disassembling the Maglite: you have to pry out the rubber button over the power switch, and then stick a long Allen (hex) key through the hole in the button and loosen a set screw. This frees the switch/bulb holder assembly, which can then be slid out the bottom of the tube (the end where you put in batteries). I learned this the hard way by removing the snap ring above the switch assembly and driving it out from below! Needless to say, that ruined it, but I learned what to do the next time.
Somebody asked above how well LED flashlights work. Mine is blindingly bright: looking into the beam at close range produces a dazzle effect like a flashbulb, complete with sparkly afterglow. I used highly-focused LEDs: it makes a beam about 2 feet across at a distance of 10 feet. Unfortunately, since the human eye isn't very sensitive to red, the beam doesn't appear very bright, but it's plenty good enough to see with at night. Battery life is very good: I gave up trying to run it down after 24 hours, although there was noticeable dimming by that point. One good thing about LEDs is that they simply grow dimmer as the battery runs down, unlike incandescents which have a tendency not to glow at all once the voltage falls below a critical point.
I agree in principle, but it would be a difficult, risky lawsuit. Unless you just enjoy fighing lawsuits, it is better to assume that the binary is a derived work of the headers.
If those headers come from the original VirtualDub package, they are protected by the GPL, and any binary compiled with them is therefore subject to the GPL.
On the other hand, if SloMedia created their own headers from scratch, those headers are not protected by the GPL, and the binary is therefore not a derived work.
Hmm...I sense a business plan. All these little gizmos, like remote controls, garage door openers, Bluetooth cards and telephones, game controllers, SPIKE gizmos, and so forth have one thing in common: for proper security, they need a hardware key-exchange system. Which means a cable. Which means an enormous business selling cables. Which means that cable companies could give away strong encryption as a loss-leader, and make it up with a captive market for synchonization cables.
As for the iButton/1-wire/MicroLAN stuff from Dallas, I've played with it. They have some really cool devices. Their superfast 8051-compatible microcontrollers are neat too.