Apple's hardware has always been uninspired, 2nd rate dreck. The best hardware designs came from Jay Miner and friends in the Atari and Commodore camp. While Apple was inventing new ways to make a fast processor slow (single 68000 CPU running the entire system, no DMA, etc. etc.) the Amiga and Atari had custom coprocessors for disk I/O, graphics, sound, keyboard, mouse etc., getting *great* performance out of the same CPU. And doing it all for less $$ overall.
I totally agree that Microsoft *and Intel* have retarded the state of the art by at least 15 years. There have been so many other worthwhile, efficient CPU architectures (MIPS, Alpha, 680x0) that have gone by the wayside, while the bloated hulk of x86 keeps rolling on.
I really do wonder where Linux would be today without Microsoft. I wonder why Minix didn't experience the same explosive growth. (Anyone even remember it?)
One can only hope that as we push thru the 21st century, marketing will less frequently win out over superior technology.
After messing around with MUD way back when, that was the first thing that came to mind when I first heard about Java, all those years ago. One of the problems with MUD was that even though you could bring your character from dungeon to dungeon, none of the artifacts or special objects you found in one GM's dungeon had any effect in someone else's, because the code to implement that artifact couldn't go with you. If all the little MUD objects were implemented in bytecode, then everything would be portable, and you could keep on using that awesome +9 flamethrower in every other dungeon you visited...
Good points. This is one of the things that made prosecuting hackers so hard; the police had to catch them in the act - physically at their keyboards, issuing the commands - to make a prosecution stick. Otherwise there is NO WAY to prove that any specific person was using any given machine to commit any particular action.
You have a valid point about people who slavishly follow rules and never have an original thought.
But still you must learn to walk before you can run. If you haven't mastered the basics then you haven't earned the right to be an architect yet. If you're unwilling to demonstrate your mastery of the basics in an interview, then you're probably too contrary to be a reasonable employee.
If you'd prefer to BS your way through the interview by demonstrating architectural ideas, well - lots of people can talk a good game. Anybody can think about a problem and say "I would solve it by doing X, Y, and Z" but few people actually have what it takes to write the actual code.
Now, you might think that missing a semicolon in a 20-line code snippet is too trivial to really worry about. But really, if you can't (or rather, *won't* make the effort to) formulate a correct answer to a small problem, I still doubt your ability to handle a larger one.
As for who you'd like to work for, and who I'd like to hire - no loss either way. Just like other human relationships, some things just aren't meant to be.
As a programmer who takes pride in my work, I pay attention to details. Paying attention to what one is doing is one of those worthwhile expenditures of effort that means you may not have to keep re-doing it umpteen times down the road.
If you can't be bothered to get 20 lines of code absolutely correct on an employment test, then why should I trust you to get 2,000 lines of code correct in a production environment? If you can't write 10 lines of code correctly without needing a compiler or IDE to check your syntax for you, then you're just lazy, and I will happily toss your resume' in the trash, cursing the time I wasted interviewing you.
Good tools certainly help you to work more efficiently. But I would rather give a good developer a set of tools that makes him stellar, than take a poor/mediocre developer who churns out "just passable" code.
Wasn't Sony showing off some BlueRay discs at the last CES?
Looking at my 120GB and 160GB firewire drives, there's no way I'm going to sit around waiting to back them up to 5 or 9GB DVDs. Maybe it's time to write a data-to-DV converter and backup to my MiniDV camcorder...
I'll agree with the post above that said whoever decided HTML in email was a good idea ought to be shot.
Outlook is a treacherous mail client, but Mozilla isn't a great improvement. The POP3 and IMAP protocols allow a client to retrieve message headers before retrieving the message body. At least Outlook for Exchange offers a Remote Mail setup where headers are downloaded in a separate pass from full messages. (Unfortunately the damn thing uses a modal dialog and locks down Outlook to single-threaded mode while it runs. Piece of $#!t.) Mozilla still doesn't offer this feature, even though the exact same functionality is intrinsic to its Newsreader client.
The other problem with both Outlook/Remote and Mailwasher is that it doesn't show you the To field. Frequently you can identify spams because their RFC822 To: field doesn't match the delivery envelope and doesn't match any of your valid email addresses.
I've downloaded the Thunderbird source to try and add these features myself, but my hands are full enough with OpenLDAP that I probably won't get to it soon. In the meantime, I use a simple curses-based POP client to delete spam on my server before letting my GUI client get it.
I think it's ironic, in an industry where the common practice was to build chips targeted at a particular speed, and sell the ones that didn't pass certification as slower parts, that Motorola was stuck selling perfectly good 16MHz chips as 8MHz chips just to keep that price point open. (There was absolutely no difference between an 8MHz and 16MHz chip by the end of their product life.) And there were people routinely running their 16MHz chips at 32MHz, because the fact was that they were produced off the same process used to make the 25MHz 68020s, and that core was the same as the 32MHz 68030. It was all the same silicon, all of it good enough for 32MHz.
You're off by at least a decade. Maybe the original Pong and Atari 2600 were cycle-counters. Everything made after that used VBI timing. Newer arcade boxes like the NeoGeo used 68020s, which of course had instruction caches that made cycle-counting impossible.
I'd love to get an Atari ST emulator up and running Spectrum Holobyte's Falcon, overclocked. It would be cool to see it running at a smooth frame rate.
As I recall, by the end of life the Motorola 68000s were all made as 16MHz parts. The slower parts were simply not made or sold any more. Also, even when they were genuine 8MHz parts, they were pretty reliable with 50% overclocking; we did this sort of thing all the time in Atari STs before the 68020 and 68030 upgrades got popular.
There were limits to what you could gain though, since the 68000 had no on-chip caches of any kind and the system bus generally couldn't handle as much of a speedup. The better upgrades included a memory cache with the accelerated 68000 on a daughterboard that plugged into the original CPU socket, to allow the processor to run at full speed without disturbing the rest of the system. It was all a dicey job though; the tolerances in the rest of the system were pretty ragged. I remember having to desolder a bunch of 74LS series buffers and replace with 74HC or AS series or somesuch that worked at faster clock rates, more noise immunity, etc., adding tantalum capacitors everywhere, etc... Ah, the good old days.
There is already an electric "race car" - The Tzero from AC Propulsion, does 0-60mph in 4.7 seconds. Go to www.acpropulsion.com and read up on it, it's really a great piece of work. 200hp electric motor.
The original version used Lead Acid batteries but they have one now using Lithium Ion. The car can cruise for 300 miles on a single charge. That, to me is a real winner.
Lengthy (overnight) charge times seem less of an issue now; I get about 300 miles on a tank of gas in my current car and have to gas up every week or so. With a Tzero I could recharge whenever convenient, and not really worry about it, because *somewhere* within the span of a week I'm sure to get 8-12 hours of charge time.
I think there's a lot to be said for centralized emission controls (in an electrical power plant) versus millions of questionably-maintained controls in IC engines. However, there are also plenty of interesting technologies for IC engines that are worth looking into, like the Coates Spherical Rotary Valve Engine or the Roton Rotary Valve Engine. These new technologies hold a lot of promise for improving the efficiency and cleanliness of IC engines.
And let's not forget the venerable Wankel Rotary Engine and all the potential it has to offer.
But personally, I'm getting on the waiting list for a Tzero. The fact that their *entire car's* power to weight ratio is greater than *just the battery system* in the Honda electric vehicle says plenty, to me. These guys have their technology in order, now all they need is some investors to dump enough cash on them to go mass production.
Well, wherever you send the money, a greedy person will step in to receive it. That's guaranteed.
In a civil case, I think it's clear that damages should be limited to an actual loss value. If a big corporation mistreats one person in a trivial manner, then there's no justification for a multimillion dollar award. If a big corporation systematically mistreats many people, then the damage may still be small in each case, but it gets multiplied by the number of injured parties. That's all perfectly fine; the awards will tend to grow as the size of the defendant grows because it takes a big company to be able to injure a large number of people in the first place.
For a criminal case, the plaintiff is the State, which represents all citizens together, so one could say that the number of injured parties is Very Large. It seems appropriate then that the penalties must be large enough to have a significant effect on the company, so here I would say there should be no limits. The penalties must be sufficiently dire to discourage any company from taking the risk.
Systems that charge for CPU time do it based on number of machine/instruction cycles. If you have two machines of identical architecture, one running at a faster clock rate, then both should solve an identical problem in an identical number of cycles. In these cases, the machine provider will generally charge a higher price per cycle for the faster machine.
In today's competitive world "time = money" is always true, but some kinds of time are more expensive than others. Buying time on the fastest processor isn't always the right choice.
If one were really smart, the lock would use a pulse-modulated light source and a pulse-train detector, so you can't just fool it by shining a flashlight down all the fibers.
I would also consider using multiple grades of optical fiber with different transparencies / refractive indices. Then you can't just use a combination of mirrors and plain fibers to fool it. If the lock uses coherent (e.g. laser) light and fibers with various (circular, vertical) polarization then forgery becomes even harder.
But then again, maybe I'm just over-engineering...
I don't think this is such a big problem. "Checksums" is only almost-a-solution. What you want is a digital signature, and this is pretty easy to create. PGP has demonstrated that you don't need a centralized certification authority to make digital signatures viable.
It's a foregone conclusion that physical media distribution is less critical today. The way to make money on the electronic front is to create the music search engine - the master catalog of all Indie music on the web. Yes, any artist can publish anything they want now, but their fans still need mechanisms for finding them. Whoever controls the music search engines will essentially control Internet Music Distribution.
And if you get in there at the start, and offer a registration service that includes assigning digital certificates for digital signatures for each artist that registers, then the rest is trivial.
Asfor "incentive" for P2P downloaders to pay - it's really simple - if you don't pay, your favorite artist will starve to death, and will no longer create music for you to enjoy. If you *really* like them, you'll feel good about supporting them. If you don't really like them, don't waste your time...
I guess the mechanical rate has gone up since the last time I looked. No biggie. I own all the rights to all of my stuff, and released it on my own label, so I don't need to negotiate with anyone else. I'm glad you did your homework and didn't get screwed as badly as most.
We made enough in two months of gigs to pay for the studio time and our first 1000 CDs, so everything was paid for when we walked in to record. All of those sales (along with T-shirts and posters) paid for the subsequent CDs, which we've sold a few thousand of since then, and all of the proceeds went straight to our band members. I've also licensed a couple tracks to 3 movies and another sampler CD, but we get piddly amounts from those compared to our own CD sales. When you're motivated to do the work and make the deals, you don't need labels or any other middlemen.
Yep. A band can make at most about 7 cents a track for their recording royalties, and usually makes less. The label keeps everything else.
I personally will not pay real money for lossy-compressed audio.
All we (musicians) really need is a music search engine that brings listeners to our web sites, and Paypal accounts.
My band's current CD is online in low-quality MP3 (24kbps) for free. It's a try-before-you-buy offering, you can download it relatively quickly, give it a listen, then decide for yourself. If you want the full-quality recording, you can order the CD from us or from Amazon. (Fyi - the band is Highland Sun - Traditional Music from Ireland, Scotland, and Parts Unknown - the URL is by my name above...)
I drive a '97 Ford and my factory keyless entry often failed unless I stood right next to the car antenna. These things operate at 295MHz and seem to be extremely susceptible to interference. I modified my spare keyfob and replaced the "operating" LED with an IR emitter, and added an IR receiver inside the car. This pretty much always works, and since it's just using the same code over IR it didn't require any reprogramming of the keyless entry system. It has another advantage in that it's a narrow beam transmission, not like the omnidirectional RF broadcast, which anyone with a portable scanner can record and duplicate.
And as some others pointed out - opening the door manually will trigger the alarm. The factory alarm is wired into the keyless entry system, it will only disarm if it receives an Unlock code. The alarm has sensors on all the doors to detect if they are open or closed, it doesn't have sensors to detect that you used a key to unlock the door.
Y'know, if these other articles on rapid climate change are to be believed, and a huge chunk of the Antarctic ice shelf really did just break off into the ocean recently, soon there's going to be a lot of these multi-million-year-old bacteria waking up and wandering around in our ecosystem, completely uncontrolled, carried by ocean currents and airborne wind patterns...
1999 Research with references to the IEEE Spectrum article (since I am not now an IEEE member and didn't feel like paying to download the original article).
The page there shows that the referenced article was talking mT - milliTesla, not micro, and showed that risk of children developing leukemia increased with EMF field strength, on the order of.2mT.
Indeed, there's more in the NASA code library than the flight software, whose necessarily redundant features have already been pointed out.
When I worked at JPL I worked on the Ground Data Processing System for a Space Shuttle-mounted imaging radar. The volume of data we were getting beamed down in realtime was huge, and we were using a lot of bleeding edge hardware to make it happen. Mainly in the high-speed tape drives, fiber optic communications, etc. One of my projects as a distributed queuing system to move image processing jobs across a cluster of machines; the processing task was so huge we pipelined across supercomputers to get it done. (Think 1993, and a 4-channel data stream coming down at 45Mbps, turning into gigabyte image files.) For another phase of the project I tweaked a vendor's SMP TCP/IP stack to get double the throughput. (We were only seeing 500KB/sec on 10Mbit ethernet, I bumped it up to 1.1MB/sec. When we switched to HIPPI my optimizations had a commensurate speedup there as well...) We had to produce multiple copies of the product images, at least two for off-site archiving, a couple for our European partners, and a couple for various other requesting scientists around the world. I wrote a SCSI fanout app that would write a single SCSI-2 data packet to up to 16 exabyte tape drives simultaneously, so I could stream 16 copies of an image at once without using up 16x the bandwidth of one copy. This is all stuff that was way ahead of anyone else in the industry at the time.
The image processing guys were always tweaking their FFT algorithms for the specific cache size of a particular CPU, etc... There's a lot of bleeding edge work going on here, but also, a lot of its useful life is very short, because the hardware used in projects keeps turning over, upgrading to the latest, fastest CPUs and buses. In that respect, I sorta wonder how much of what we produced is relevant outside the lab...
It worked for Robin Hood, and nobody accused him of supporting oppression and tyranny.
When I started my band in 1996 the statutory rate for artist royalty payments was 6 cents per track. So for a CD with say, 12 songs on it, a signed artist makes 72 cents per sale of the CD *maximum*. If the artist happened to sign a "sucker deal" with their recording label, then they probably agreed to pay management fees, theft/destruction contingencies, promotional fees and assorted other gouging, bringing their take down to less than 1 cent per track. There are plenty of bands out there whose first big-label CD sold hundreds of thousands of copies but the artists earned effectively nil. (And they have only themselves to blame, for signing such an abusive contract. But anyway...)
With the actual reproduction costs of CDs down in the 10-20 cent range, the amount of money that the labels and RIAA collectively rakes in vs pays out is stupendous.
By the way, while giving people the guilt trip about stealing money from the hands of their favorite artists, think about it again. For the $20 you might have paid for a CD, only $0.72 maximum would have gone to the artist. That's a whopping 3.6% at most. Of the remaining 96.4%, probably half of it went to the retailer, whose basic expense is shelf space, and the other half went to the label. Most of that is pure profit that never would have gone anywhere near the artist in the first place. And if the artist had a sucker deal, their cut was probably less than 1/3 of a percent. Just noise.
No matter how you slice it, the RIAA is screwing everyone, and still doing a fine job of getting away with it.
When I worked at JPL, every 6 months to a year there'd be talks of layoffs because the headcount was too high; people would leave and return to the same projects as contractors, then get a higher hourly wage for doing the same work with less accountability.
The whole reason for that lost probe (feet vs meters, anyone?) was because of a political squabble between two teams (one JPL-internal, one outside contractors as I recall) who simply failed to cooperate productively. The whole management structure inside that world is screwed. People's project leads are not the same as their section/department leads, so the reporting chain is a mes{h,s}. Time and energy is wasted in contract(or) management, all in the name of "reduced costs" even though having all the work done in-house would eliminate a full layer or two of mid-level management waste.
NASA/JPL are totally hamstrung by beancounters who think they're saving the public's money, but truly can't see the big picture, missing the forest for the trees. (Either that, or they *do* see the big picture, and are busily lining their own pockets with the excess that gets tossed around thru all the churn.)
Apple's hardware has always been uninspired, 2nd rate dreck. The best hardware designs came from Jay Miner and friends in the Atari and Commodore camp. While Apple was inventing new ways to make a fast processor slow (single 68000 CPU running the entire system, no DMA, etc. etc.) the Amiga and Atari had custom coprocessors for disk I/O, graphics, sound, keyboard, mouse etc., getting *great* performance out of the same CPU. And doing it all for less $$ overall.
I totally agree that Microsoft *and Intel* have retarded the state of the art by at least 15 years. There have been so many other worthwhile, efficient CPU architectures (MIPS, Alpha, 680x0) that have gone by the wayside, while the bloated hulk of x86 keeps rolling on.
I really do wonder where Linux would be today without Microsoft. I wonder why Minix didn't experience the same explosive growth. (Anyone even remember it?)
One can only hope that as we push thru the 21st century, marketing will less frequently win out over superior technology.
The Peruvian government seem to have a better understanding of the issues...
Peru and Microsoft
If a government policy specified that video files must be distributed in WMV, that policy needs to be revisited...
After messing around with MUD way back when, that was the first thing that came to mind when I first heard about Java, all those years ago. One of the problems with MUD was that even though you could bring your character from dungeon to dungeon, none of the artifacts or special objects you found in one GM's dungeon had any effect in someone else's, because the code to implement that artifact couldn't go with you. If all the little MUD objects were implemented in bytecode, then everything would be portable, and you could keep on using that awesome +9 flamethrower in every other dungeon you visited...
Good points. This is one of the things that made prosecuting hackers so hard; the police had to catch them in the act - physically at their keyboards, issuing the commands - to make a prosecution stick. Otherwise there is NO WAY to prove that any specific person was using any given machine to commit any particular action.
You have a valid point about people who slavishly follow rules and never have an original thought.
But still you must learn to walk before you can run. If you haven't mastered the basics then you haven't earned the right to be an architect yet.
If you're unwilling to demonstrate your mastery of the basics in an interview, then you're probably too contrary to be a reasonable employee.
If you'd prefer to BS your way through the interview by demonstrating architectural ideas, well - lots of people can talk a good game. Anybody can think about a problem and say "I would solve it by doing X, Y, and Z" but few people actually have what it takes to write the actual code.
Now, you might think that missing a semicolon in a 20-line code snippet is too trivial to really worry about. But really, if you can't (or rather, *won't* make the effort to) formulate a correct answer to a small problem, I still doubt your ability to handle a larger one.
As for who you'd like to work for, and who I'd like to hire - no loss either way. Just like other human relationships, some things just aren't meant to be.
As a programmer who takes pride in my work, I pay attention to details. Paying attention to what one is doing is one of those worthwhile expenditures of effort that means you may not have to keep re-doing it umpteen times down the road.
If you can't be bothered to get 20 lines of code absolutely correct on an employment test, then why should I trust you to get 2,000 lines of code correct in a production environment? If you can't write 10 lines of code correctly without needing a compiler or IDE to check your syntax for you, then you're just lazy, and I will happily toss your resume' in the trash, cursing the time I wasted interviewing you.
Good tools certainly help you to work more efficiently. But I would rather give a good developer a set of tools that makes him stellar, than take a poor/mediocre developer who churns out "just passable" code.
Wasn't Sony showing off some BlueRay discs at the last CES?
Looking at my 120GB and 160GB firewire drives, there's no way I'm going to sit around waiting to back them up to 5 or 9GB DVDs. Maybe it's time to write a data-to-DV converter and backup to my MiniDV camcorder...
I'll agree with the post above that said whoever decided HTML in email was a good idea ought to be shot.
Outlook is a treacherous mail client, but Mozilla isn't a great improvement. The POP3 and IMAP protocols allow a client to retrieve message headers before retrieving the message body. At least Outlook for Exchange offers a Remote Mail setup where headers are downloaded in a separate pass from full messages. (Unfortunately the damn thing uses a modal dialog and locks down Outlook to single-threaded mode while it runs. Piece of $#!t.) Mozilla still doesn't offer this feature, even though the exact same functionality is intrinsic to its Newsreader client.
The other problem with both Outlook/Remote and Mailwasher is that it doesn't show you the To field. Frequently you can identify spams because their RFC822 To: field doesn't match the delivery envelope and doesn't match any of your valid email addresses.
I've downloaded the Thunderbird source to try and add these features myself, but my hands are full enough with OpenLDAP that I probably won't get to it soon. In the meantime, I use a simple curses-based POP client to delete spam on my server before letting my GUI client get it.
Thanks for the thought.
I think it's ironic, in an industry where the common practice was to build chips targeted at a particular speed, and sell the ones that didn't pass certification as slower parts, that Motorola was stuck selling perfectly good 16MHz chips as 8MHz chips just to keep that price point open. (There was absolutely no difference between an 8MHz and 16MHz chip by the end of their product life.) And there were people routinely running their 16MHz chips at 32MHz, because the fact was that they were produced off the same process used to make the 25MHz 68020s, and that core was the same as the 32MHz 68030. It was all the same silicon, all of it good enough for 32MHz.
You're off by at least a decade. Maybe the original Pong and Atari 2600 were cycle-counters. Everything made after that used VBI timing. Newer arcade boxes like the NeoGeo used 68020s, which of course had instruction caches that made cycle-counting impossible.
I'd love to get an Atari ST emulator up and running Spectrum Holobyte's Falcon, overclocked. It would be cool to see it running at a smooth frame rate.
As I recall, by the end of life the Motorola 68000s were all made as 16MHz parts. The slower parts were simply not made or sold any more. Also, even when they were genuine 8MHz parts, they were pretty reliable with 50% overclocking; we did this sort of thing all the time in Atari STs before the 68020 and 68030 upgrades got popular.
There were limits to what you could gain though, since the 68000 had no on-chip caches of any kind and the system bus generally couldn't handle as much of a speedup. The better upgrades included a memory cache with the accelerated 68000 on a daughterboard that plugged into the original CPU socket, to allow the processor to run at full speed without disturbing the rest of the system. It was all a dicey job though; the tolerances in the rest of the system were pretty ragged. I remember having to desolder a bunch of 74LS series buffers and replace with 74HC or AS series or somesuch that worked at faster clock rates, more noise immunity, etc., adding tantalum capacitors everywhere, etc... Ah, the good old days.
There is already an electric "race car" - The Tzero from AC Propulsion, does 0-60mph in 4.7 seconds. Go to www.acpropulsion.com and read up on it, it's really a great piece of work. 200hp electric motor.
The original version used Lead Acid batteries but they have one now using Lithium Ion. The car can cruise for 300 miles on a single charge. That, to me is a real winner.
Lengthy (overnight) charge times seem less of an issue now; I get about 300 miles on a tank of gas in my current car and have to gas up every week or so. With a Tzero I could recharge whenever convenient, and not really worry about it, because *somewhere* within the span of a week I'm sure to get 8-12 hours of charge time.
I think there's a lot to be said for centralized emission controls (in an electrical power plant) versus millions of questionably-maintained controls in IC engines. However, there are also plenty of interesting technologies for IC engines that are worth looking into, like the Coates Spherical Rotary Valve Engine or the Roton Rotary Valve Engine. These new technologies hold a lot of promise for improving the efficiency and cleanliness of IC engines.
And let's not forget the venerable Wankel Rotary Engine and all the potential it has to offer.
But personally, I'm getting on the waiting list for a Tzero. The fact that their *entire car's* power to weight ratio is greater than *just the battery system* in the Honda electric vehicle says plenty, to me. These guys have their technology in order, now all they need is some investors to dump enough cash on them to go mass production.
Well, wherever you send the money, a greedy person will step in to receive it. That's guaranteed.
In a civil case, I think it's clear that damages should be limited to an actual loss value. If a big corporation mistreats one person in a trivial manner, then there's no justification for a multimillion dollar award. If a big corporation systematically mistreats many people, then the damage may still be small in each case, but it gets multiplied by the number of injured parties. That's all perfectly fine; the awards will tend to grow as the size of the defendant grows because it takes a big company to be able to injure a large number of people in the first place.
For a criminal case, the plaintiff is the State, which represents all citizens together, so one could say that the number of injured parties is Very Large. It seems appropriate then that the penalties must be large enough to have a significant effect on the company, so here I would say there should be no limits. The penalties must be sufficiently dire to discourage any company from taking the risk.
Systems that charge for CPU time do it based on number of machine/instruction cycles. If you have two machines of identical architecture, one running at a faster clock rate, then both should solve an identical problem in an identical number of cycles. In these cases, the machine provider will generally charge a higher price per cycle for the faster machine.
In today's competitive world "time = money" is always true, but some kinds of time are more expensive than others. Buying time on the fastest processor isn't always the right choice.
If one were really smart, the lock would use a pulse-modulated light source and a pulse-train detector, so you can't just fool it by shining a flashlight down all the fibers.
I would also consider using multiple grades of optical fiber with different transparencies / refractive indices. Then you can't just use a combination of mirrors and plain fibers to fool it. If the lock uses coherent (e.g. laser) light and fibers with various (circular, vertical) polarization then forgery becomes even harder.
But then again, maybe I'm just over-engineering...
I don't think this is such a big problem. "Checksums" is only almost-a-solution. What you want is a digital signature, and this is pretty easy to create. PGP has demonstrated that you don't need a centralized certification authority to make digital signatures viable.
It's a foregone conclusion that physical media distribution is less critical today. The way to make money on the electronic front is to create the music search engine - the master catalog of all Indie music on the web. Yes, any artist can publish anything they want now, but their fans still need mechanisms for finding them. Whoever controls the music search engines will essentially control Internet Music Distribution.
And if you get in there at the start, and offer a registration service that includes assigning digital certificates for digital signatures for each artist that registers, then the rest is trivial.
Asfor "incentive" for P2P downloaders to pay - it's really simple - if you don't pay, your favorite artist will starve to death, and will no longer create music for you to enjoy. If you *really* like them, you'll feel good about supporting them. If you don't really like them, don't waste your time...
I guess the mechanical rate has gone up since the last time I looked. No biggie. I own all the rights to all of my stuff, and released it on my own label, so I don't need to negotiate with anyone else. I'm glad you did your homework and didn't get screwed as badly as most.
We made enough in two months of gigs to pay for the studio time and our first 1000 CDs, so everything was paid for when we walked in to record. All of those sales (along with T-shirts and posters) paid for the subsequent CDs, which we've sold a few thousand of since then, and all of the proceeds went straight to our band members. I've also licensed a couple tracks to 3 movies and another sampler CD, but we get piddly amounts from those compared to our own CD sales. When you're motivated to do the work and make the deals, you don't need labels or any other middlemen.
Yep. A band can make at most about 7 cents a track for their recording royalties, and usually makes less. The label keeps everything else.
I personally will not pay real money for lossy-compressed audio.
All we (musicians) really need is a music search engine that brings listeners to our web sites, and Paypal accounts.
My band's current CD is online in low-quality MP3 (24kbps) for free. It's a try-before-you-buy offering, you can download it relatively quickly, give it a listen, then decide for yourself. If you want the full-quality recording, you can order the CD from us or from Amazon. (Fyi - the band is Highland Sun - Traditional Music from Ireland, Scotland, and Parts Unknown - the URL is by my name above...)
I drive a '97 Ford and my factory keyless entry often failed unless I stood right next to the car antenna. These things operate at 295MHz and seem to be extremely susceptible to interference. I modified my spare keyfob and replaced the "operating" LED with an IR emitter, and added an IR receiver inside the car. This pretty much always works, and since it's just using the same code over IR it didn't require any reprogramming of the keyless entry system. It has another advantage in that it's a narrow beam transmission, not like the omnidirectional RF broadcast, which anyone with a portable scanner can record and duplicate.
And as some others pointed out - opening the door manually will trigger the alarm. The factory alarm is wired into the keyless entry system, it will only disarm if it receives an Unlock code. The alarm has sensors on all the doors to detect if they are open or closed, it doesn't have sensors to detect that you used a key to unlock the door.
Y'know, if these other articles on rapid climate change are to be believed, and a huge chunk of the Antarctic ice shelf really did just break off into the ocean recently, soon there's going to be a lot of these multi-million-year-old bacteria waking up and wandering around in our ecosystem, completely uncontrolled, carried by ocean currents and airborne wind patterns...
Antarctic ice and CO2
1999 Research with references to the IEEE Spectrum article (since I am not now an IEEE member and didn't feel like paying to download the original article).
.2mT.
The page there shows that the referenced article was talking mT - milliTesla, not micro, and showed that risk of children developing leukemia increased with EMF field strength, on the order of
Indeed, there's more in the NASA code library than the flight software, whose necessarily redundant features have already been pointed out.
When I worked at JPL I worked on the Ground Data Processing System for a Space Shuttle-mounted imaging radar. The volume of data we were getting beamed down in realtime was huge, and we were using a lot of bleeding edge hardware to make it happen. Mainly in the high-speed tape drives, fiber optic communications, etc. One of my projects as a distributed queuing system to move image processing jobs across a cluster of machines; the processing task was so huge we pipelined across supercomputers to get it done. (Think 1993, and a 4-channel data stream coming down at 45Mbps, turning into gigabyte image files.) For another phase of the project I tweaked a vendor's SMP TCP/IP stack to get double the throughput. (We were only seeing 500KB/sec on 10Mbit ethernet, I bumped it up to 1.1MB/sec. When we switched to HIPPI my optimizations had a commensurate speedup there as well...) We had to produce multiple copies of the product images, at least two for off-site archiving, a couple for our European partners, and a couple for various other requesting scientists around the world. I wrote a SCSI fanout app that would write a single SCSI-2 data packet to up to 16 exabyte tape drives simultaneously, so I could stream 16 copies of an image at once without using up 16x the bandwidth of one copy. This is all stuff that was way ahead of anyone else in the industry at the time.
The image processing guys were always tweaking their FFT algorithms for the specific cache size of a particular CPU, etc... There's a lot of bleeding edge work going on here, but also, a lot of its useful life is very short, because the hardware used in projects keeps turning over, upgrading to the latest, fastest CPUs and buses. In that respect, I sorta wonder how much of what we produced is relevant outside the lab...
It worked for Robin Hood, and nobody accused him of supporting oppression and tyranny.
When I started my band in 1996 the statutory rate for artist royalty payments was 6 cents per track. So for a CD with say, 12 songs on it, a signed artist makes 72 cents per sale of the CD *maximum*. If the artist happened to sign a "sucker deal" with their recording label, then they probably agreed to pay management fees, theft/destruction contingencies, promotional fees and assorted other gouging, bringing their take down to less than 1 cent per track. There are plenty of bands out there whose first big-label CD sold hundreds of thousands of copies but the artists earned effectively nil. (And they have only themselves to blame, for signing such an abusive contract. But anyway...)
With the actual reproduction costs of CDs down in the 10-20 cent range, the amount of money that the labels and RIAA collectively rakes in vs pays out is stupendous.
By the way, while giving people the guilt trip about stealing money from the hands of their favorite artists, think about it again. For the $20 you might have paid for a CD, only $0.72 maximum would have gone to the artist. That's a whopping 3.6% at most. Of the remaining 96.4%, probably half of it went to the retailer, whose basic expense is shelf space, and the other half went to the label. Most of that is pure profit that never would have gone anywhere near the artist in the first place. And if the artist had a sucker deal, their cut was probably less than 1/3 of a percent. Just noise.
No matter how you slice it, the RIAA is screwing everyone, and still doing a fine job of getting away with it.
One word: outsourcing.
When I worked at JPL, every 6 months to a year there'd be talks of layoffs because the headcount was too high; people would leave and return to the same projects as contractors, then get a higher hourly wage for doing the same work with less accountability.
The whole reason for that lost probe (feet vs meters, anyone?) was because of a political squabble between two teams (one JPL-internal, one outside contractors as I recall) who simply failed to cooperate productively. The whole management structure inside that world is screwed. People's project leads are not the same as their section/department leads, so the reporting chain is a mes{h,s}. Time and energy is wasted in contract(or) management, all in the name of "reduced costs" even though having all the work done in-house would eliminate a full layer or two of mid-level management waste.
NASA/JPL are totally hamstrung by beancounters who think they're saving the public's money, but truly can't see the big picture, missing the forest for the trees. (Either that, or they *do* see the big picture, and are busily lining their own pockets with the excess that gets tossed around thru all the churn.)
Except that fully mirrored RAM would use way too much power, something that no space probe can afford.
No really!
http://yro.slashdot.org/~hyc/journal/