In theory, yes, landlords have a general incentive to make improvements to allow them to more easily fill their units and to charge higher rent. In practice, I believe that energy efficiency is not something that tenents consider before renting, so I believe that it is a valid example.
Minor nitpick: Polio is not genetic. I believe it is a virus, and, like many viruses, we developed a vaccine. Genetic issues are far more complicated. Not that we can't eventually develop cures...
Of more subtance: I agree with the argument that pooling of risks is important. We have to draw the line somewhere and say what insurance companies (and employers) can and can not discriminate against, even when they have a good scientific basis for the discrimination. I probably overstated my case in my first post. I'm not sure where to draw the line, but we must be careful to consider all the issues.
Unfortunately, lassez faire breaks down when the person making the purchasing decision is not directly spending their own money. I can think of several good examples:
Landlords have no incentive to make their units energy-efficient if the tennents pay the utility bills.
Corporations (and individuals) have no direct financial incentive to avoid polluting the environment.
People have no incentive to reduce health care expenditures when they are covered by insurance.
It's that last point that is the problem here. Insurance breaks down the laws of supply and demand, because cost is no longer an issue. Hence, government regulation is necessary to correct the situation, either by regulating the market, or by altering the rules of the market to restore supply and demand.
Insurance companies may well need to discriminate on the basis of genetic testing. Whether this discrimination takes the form of higher premiums or outright refusal of coverage doesn't really matter, but the right of the company to make such discrimination should be considered.
Why?
Because the people they are insuring may have access to the same genetic testing information. This information may be direct, through the same sort of genetic testing, or indirect, through family history of ailments or such.
Consider life insurance: If anyone with a terminal illness could go and buy a million dollars in term life insurance, the life insurance companies would go bankrupt. Hence, most life insurance policies require some sort of health review to make sure you don't have some sort of known terminal illness.
It's a matter of having a level playing field. Insurance companies should be able to have as much medical information about you as you do. They need to be able to determine the risk of insuring you as well as you are able to determine the risk yourself.
Something to consider before complaining about evil privacy-invading mega-corporations.
My feature list is based on my view of what is necessary to make full use of the web pages that I visit. While CSS may, indeed, have a lot of potential, my casual observation is that it isn't important for using the web as it stands today.
In other words, for any given feature I listed, I was rating it based roughly on the following criteria:
* How many web sites can I think of that use the feature?
Of those:
* How many won't work correctly without the feature?
(By "work correctly," I mean display the desired information and allow the user to navigate through the site to obtain the desired result.)
You'll note that I didn't list PNG support, even though I use one on my home page. It's a luxury.
First, you need a solid list of what features you really want in your web browser. In theory, you could then use Mozilla and compile out all the ones you don't really want. In theory, you could use the fully-featured Mozilla with some extra code to log which features you use, then use that to only compile in what you want. In practice you can only cut out some of the major chunks like mail and news.
So my take on what you need:
* HTTP and FTP support
* HTML rendering, including frames, tables, GIF, and JPG
* Forms support
* SSL support
* Cookies
* JavaScript
You probably also would find useful:
* Support for plugins (Flash and such)
* Support for Java, probably using an external JVM
Luxury items:
* CSS (Cascading Style Sheets)
Note that unlike others, I consider FTP to be critical. I use it all the time from sites that use HTML indices for downloading software, such as Freshmeat.
So we may want to move our planet into a higher orbit over the course of the next billion years. Given that goal, this is the wrong approach. Using a single (or small number of) large, short-duration adjustment to the orbit is dangererous. The risks of stress fractures (earthquakes), even if all the calculations are correct, is too great. And if there is a miscalculation, well, game over.
No, we want a slow long-duration force applied to the planet. Something moving us no more than perhaps a meter or so a day. That would give us a nice safe slow adjustment.
Now how do we acheive such a change? That's a good question. Perhaps we could do something magnetic, similar to how satellites can use tethers and electrical charge to push off the magnetic field? Perhaps we could tap into the solar wind in a novel way? Perhaps we could find a way to convert nuclear explosion energy into magnetic energy to push off of the earth's magnetic field?
I use exmh as my mail client. The mh tools use a separate file per message. Here are the issues with it as I see them:
Advantages:
* Easy to access any message with standard Unix text utilites (grep, more, and such).
* No worry about corrupting the entire mailbox if one message gets clobbered by a broken client (or broken file system or whatnot).
* Incremental backups and syncronization is easier
Disadvantages:
* Uses lots of storage. [Oh wait, I work for a storage company, so this is an advantage.]
* With one file per message, you can get more files in a directory than your shell will allow you to use as command line arguements. (e.g., `grep important *` may fail)
I guess the big safety issue is how well it behaves if you have more than one mail client accessing your email at a time. I don't see this as a very likely situation, but still something that should work.
I always thought NASA could make a mint by selling ads painted on the shuttle's external fuel tank. Imagine launching a giant Pepsi can?
On the other hand, do you want a symbol of our national pride looking like a NASCAR race car?
It's a tough issue. Ultimately, it boils down to one thing: The government needs the revenue from the ads, but it can get the funds from taxes instead. If (and only if) citizens find the advertising less palatable than paying taxes, then it shouldn't be there.
I'm on three egroups lists, and it didn't seem to cause any significant problems. I just made one small update to my filters to strip out the ads since they changed the text slightly.
If you want the ultimate in high-availability storage, go with EMC. You get the highest possible level of reliability within one box, and you can get remote mirroring to another machine room in another building if need be.
I can't believe how many times I've heard people refer to babies as a "little Jeffery" (where Jeffery is the father's name) or the same for the mother if it's a girl. Too often, parents buy into that idea and expect their kids to be just like them. They're at best disapointed when this doesn't happen.
Kids need their own identity.
Now you think that's bad when they have a mix of genes from both parents... Wait until you have a kid that is essentially a 30-year-younger identical twin of the parent. Ick.
That might work, but you probably don't want to do that. There isn't enough redundancy in regular uncompressed CD audio to get away with that for compressed audio. I'm not clear on what VCD tracks look like, though--it may well work. Either way, though, you probably don't want to use over 100 tracks--those standards usually aren't designed with such a large number in mind, so I don't know how well they would deal with it.
Still, that's an interesting idea to look at.
Also, with the proliferation of various CD players that will play MP3s, we should be working towards a standard format that they will all play. Using ISO9660 seems to be that format, at least for now. Any player you build should start with that as a base, and then add as much more flexibility as possible, given the limitations of the firmware size.
Assuming you have the space in your firmware, a player that reads CDs should be a flexible as possible. Inlcude support for ISO9660, including all the extensions. Include support for HFS, so it can read Mac-only CDs, just to be safe. Include support for UDF (DVD file system), in case you get a chance to toss in DVD-R reading hardware in the next revision. You could also look into other file systems that might make sense (like ROMFS); there might be some with less overhead than ISO9660 that would work just fine.
And you didn't ask, but you should add support for ID3 tags (revisions 1.0, 1.1, and 2.0, if I recall correctly).
And survey users of other MP3 players to see what they wish their player could do, and make yours do it.
Slackware has lost the market for x86 to Red Hat and others. Now they want to revitalize the distribution, so they're going after the architectures that Red Hat and friends are ignoring. That way they can be the default installation for non-x86 systems. That will lead back into the x86 market, starting at sites that use a variety of hardware.
This just requires that the person inside your building be a little smarter. MAC addresses can be changed, so all that is required is to wait until a trusted box goes offline, and then just borrow its MAC address.
Of course, this eliminates a good portion of those who would try to hack in. Just don't rely on it to be fool-proof.
I was always tempted to use a laptop running Linux to spoof one of the main campus Unix systems at Dartmouth when it went down for backups, but never did. (I think they had some public systems on the same subnet as the machine room.)
Emulators have several advantages over real hardware:
Emulators are software, and software is often free.
If you want to play games from a bunch of different consoles, then you have to either manually switch your connections around all the time or buy an extra a/v switch. (I only have one input on my receiver available for a game console.)
When you start getting a number of different consoles, you get quite a bit of clutter.
If you have to manually change connections or unpack each console, odds are you'll find yourself not bothering very often--you may well find that you get more use out of older games with an emulator.
Of course, you have the obvious disadvantages: Different feel of the controllers and imperfections in the emulation.
A first class stamp may be only $.34, but the business is charged an additional per-item fee. This can vary from $.35 down to only $.01, depending on volume. Hence, if it's a small organization, you're really sticking it to them, but for bulk mailers, it's not as big a deal.
Reminds me of an archeologist from about a hundred years ago that went around Egypt studying ancient pyrimids with dynamite. He drilled a hole in the side of the head of the Sphyinx looking to see if there was a chamber inside, and dammaged it a bit with one blast.
Of course, this is quite different, but it still seems funny how the old ways come back.
The first thing to decide in a receiver is what type and how many connections you need.
Figure out how many audio-only components you have (or will have) and how many audio/video components you need to support. If your receiver doesn't have enough inputs to support them, you're hosed (or have to mess with a secondary switch; ick).
For example, I need:
DVD player: audio/S-video inputs, optical input
VCR: audio/video inputs, audio/video outputs
ReplayTV: audio/S-video inputs, audio/S-video outputs.
and so on.
You can use splitters on the non-digital outputs, if you don't have enough.
Keep in mind with the S-video and composite connections that in most cases you need to hook up both, unless all your components only use S-video. Many receivers don't convert between the two, so you'll need to use the composite out if you're relying on a composite input somewhere.
Unfortunately, it's mostly irrelevant that Linux will be available first. How many hardware vendors are going to actually develop systems to use this chip and market them without Windows? Will Dell accept the overhead of carrying Linux-only hardware? I don't think so.
On the other hand, this may be a chance for VA Linux to have a product that you can't buy elsewhere.
Slashdot Mirror
In theory, yes, landlords have a general incentive to make improvements to allow them to more easily fill their units and to charge higher rent. In practice, I believe that energy efficiency is not something that tenents consider before renting, so I believe that it is a valid example.
Minor nitpick: Polio is not genetic. I believe it is a virus, and, like many viruses, we developed a vaccine. Genetic issues are far more complicated. Not that we can't eventually develop cures...
Of more subtance: I agree with the argument that pooling of risks is important. We have to draw the line somewhere and say what insurance companies (and employers) can and can not discriminate against, even when they have a good scientific basis for the discrimination. I probably overstated my case in my first post. I'm not sure where to draw the line, but we must be careful to consider all the issues.
Landlords have no incentive to make their units energy-efficient if the tennents pay the utility bills.
Corporations (and individuals) have no direct financial incentive to avoid polluting the environment.
People have no incentive to reduce health care expenditures when they are covered by insurance.
It's that last point that is the problem here. Insurance breaks down the laws of supply and demand, because cost is no longer an issue. Hence, government regulation is necessary to correct the situation, either by regulating the market, or by altering the rules of the market to restore supply and demand.
Insurance companies may well need to discriminate on the basis of genetic testing. Whether this discrimination takes the form of higher premiums or outright refusal of coverage doesn't really matter, but the right of the company to make such discrimination should be considered.
Why?
Because the people they are insuring may have access to the same genetic testing information. This information may be direct, through the same sort of genetic testing, or indirect, through family history of ailments or such.
Consider life insurance: If anyone with a terminal illness could go and buy a million dollars in term life insurance, the life insurance companies would go bankrupt. Hence, most life insurance policies require some sort of health review to make sure you don't have some sort of known terminal illness.
It's a matter of having a level playing field. Insurance companies should be able to have as much medical information about you as you do. They need to be able to determine the risk of insuring you as well as you are able to determine the risk yourself.
Something to consider before complaining about evil privacy-invading mega-corporations.
My feature list is based on my view of what is necessary to make full use of the web pages that I visit. While CSS may, indeed, have a lot of potential, my casual observation is that it isn't important for using the web as it stands today.
In other words, for any given feature I listed, I was rating it based roughly on the following criteria:
* How many web sites can I think of that use the feature?
Of those:
* How many won't work correctly without the feature?
(By "work correctly," I mean display the desired information and allow the user to navigate through the site to obtain the desired result.)
You'll note that I didn't list PNG support, even though I use one on my home page. It's a luxury.
At least with gnapster, instant messages show up in the console window instead of popping up in the foreground, so they are far less obtrusive.
First, you need a solid list of what features you really want in your web browser. In theory, you could then use Mozilla and compile out all the ones you don't really want. In theory, you could use the fully-featured Mozilla with some extra code to log which features you use, then use that to only compile in what you want. In practice you can only cut out some of the major chunks like mail and news.
So my take on what you need:
* HTTP and FTP support
* HTML rendering, including frames, tables, GIF, and JPG
* Forms support
* SSL support
* Cookies
* JavaScript
You probably also would find useful:
* Support for plugins (Flash and such)
* Support for Java, probably using an external JVM
Luxury items:
* CSS (Cascading Style Sheets)
Note that unlike others, I consider FTP to be critical. I use it all the time from sites that use HTML indices for downloading software, such as Freshmeat.
So we may want to move our planet into a higher orbit over the course of the next billion years. Given that goal, this is the wrong approach. Using a single (or small number of) large, short-duration adjustment to the orbit is dangererous. The risks of stress fractures (earthquakes), even if all the calculations are correct, is too great. And if there is a miscalculation, well, game over.
No, we want a slow long-duration force applied to the planet. Something moving us no more than perhaps a meter or so a day. That would give us a nice safe slow adjustment.
Now how do we acheive such a change? That's a good question. Perhaps we could do something magnetic, similar to how satellites can use tethers and electrical charge to push off the magnetic field? Perhaps we could tap into the solar wind in a novel way? Perhaps we could find a way to convert nuclear explosion energy into magnetic energy to push off of the earth's magnetic field?
I use exmh as my mail client. The mh tools use a separate file per message. Here are the issues with it as I see them:
Advantages:
* Easy to access any message with standard Unix text utilites (grep, more, and such).
* No worry about corrupting the entire mailbox if one message gets clobbered by a broken client (or broken file system or whatnot).
* Incremental backups and syncronization is easier
Disadvantages:
* Uses lots of storage. [Oh wait, I work for a storage company, so this is an advantage.]
* With one file per message, you can get more files in a directory than your shell will allow you to use as command line arguements. (e.g., `grep important *` may fail)
I guess the big safety issue is how well it behaves if you have more than one mail client accessing your email at a time. I don't see this as a very likely situation, but still something that should work.
I always thought NASA could make a mint by selling ads painted on the shuttle's external fuel tank. Imagine launching a giant Pepsi can?
On the other hand, do you want a symbol of our national pride looking like a NASCAR race car?
It's a tough issue. Ultimately, it boils down to one thing: The government needs the revenue from the ads, but it can get the funds from taxes instead. If (and only if) citizens find the advertising less palatable than paying taxes, then it shouldn't be there.
I'm on three egroups lists, and it didn't seem to cause any significant problems. I just made one small update to my filters to strip out the ads since they changed the text slightly.
What was the big deal?
If you want the ultimate in high-availability storage, go with EMC. You get the highest possible level of reliability within one box, and you can get remote mirroring to another machine room in another building if need be.
Disclaimer: I work for EMC.
I can't believe how many times I've heard people refer to babies as a "little Jeffery" (where Jeffery is the father's name) or the same for the mother if it's a girl. Too often, parents buy into that idea and expect their kids to be just like them. They're at best disapointed when this doesn't happen.
Kids need their own identity.
Now you think that's bad when they have a mix of genes from both parents... Wait until you have a kid that is essentially a 30-year-younger identical twin of the parent. Ick.
That might work, but you probably don't want to do that. There isn't enough redundancy in regular uncompressed CD audio to get away with that for compressed audio. I'm not clear on what VCD tracks look like, though--it may well work. Either way, though, you probably don't want to use over 100 tracks--those standards usually aren't designed with such a large number in mind, so I don't know how well they would deal with it.
Still, that's an interesting idea to look at.
Also, with the proliferation of various CD players that will play MP3s, we should be working towards a standard format that they will all play. Using ISO9660 seems to be that format, at least for now. Any player you build should start with that as a base, and then add as much more flexibility as possible, given the limitations of the firmware size.
Assuming you have the space in your firmware, a player that reads CDs should be a flexible as possible. Inlcude support for ISO9660, including all the extensions. Include support for HFS, so it can read Mac-only CDs, just to be safe. Include support for UDF (DVD file system), in case you get a chance to toss in DVD-R reading hardware in the next revision. You could also look into other file systems that might make sense (like ROMFS); there might be some with less overhead than ISO9660 that would work just fine.
And you didn't ask, but you should add support for ID3 tags (revisions 1.0, 1.1, and 2.0, if I recall correctly).
And survey users of other MP3 players to see what they wish their player could do, and make yours do it.
Slackware has lost the market for x86 to Red Hat and others. Now they want to revitalize the distribution, so they're going after the architectures that Red Hat and friends are ignoring. That way they can be the default installation for non-x86 systems. That will lead back into the x86 market, starting at sites that use a variety of hardware.
This just requires that the person inside your building be a little smarter. MAC addresses can be changed, so all that is required is to wait until a trusted box goes offline, and then just borrow its MAC address.
Of course, this eliminates a good portion of those who would try to hack in. Just don't rely on it to be fool-proof.
I was always tempted to use a laptop running Linux to spoof one of the main campus Unix systems at Dartmouth when it went down for backups, but never did. (I think they had some public systems on the same subnet as the machine room.)
Emulators have several advantages over real hardware:
Emulators are software, and software is often free.
If you want to play games from a bunch of different consoles, then you have to either manually switch your connections around all the time or buy an extra a/v switch. (I only have one input on my receiver available for a game console.)
When you start getting a number of different consoles, you get quite a bit of clutter.
If you have to manually change connections or unpack each console, odds are you'll find yourself not bothering very often--you may well find that you get more use out of older games with an emulator.
Of course, you have the obvious disadvantages: Different feel of the controllers and imperfections in the emulation.
A first class stamp may be only $.34, but the business is charged an additional per-item fee. This can vary from $.35 down to only $.01, depending on volume. Hence, if it's a small organization, you're really sticking it to them, but for bulk mailers, it's not as big a deal.
(This was verified at www.usps.gov)
Reminds me of an archeologist from about a hundred years ago that went around Egypt studying ancient pyrimids with dynamite. He drilled a hole in the side of the head of the Sphyinx looking to see if there was a chamber inside, and dammaged it a bit with one blast.
Of course, this is quite different, but it still seems funny how the old ways come back.
Imagine if they also stripped out ads, using something like Junkbuster.
Now imagine if they decided instead of stripping out ads, they would substitute ads. Now that would be a fun discussion!
The first thing to decide in a receiver is what type and how many connections you need.
Figure out how many audio-only components you have (or will have) and how many audio/video components you need to support. If your receiver doesn't have enough inputs to support them, you're hosed (or have to mess with a secondary switch; ick).
For example, I need:
DVD player: audio/S-video inputs, optical input
VCR: audio/video inputs, audio/video outputs
ReplayTV: audio/S-video inputs, audio/S-video outputs.
and so on.
You can use splitters on the non-digital outputs, if you don't have enough.
Keep in mind with the S-video and composite connections that in most cases you need to hook up both, unless all your components only use S-video. Many receivers don't convert between the two, so you'll need to use the composite out if you're relying on a composite input somewhere.
http://us.imdb.com/Title?0218817
I see no reference to Miguel or John Hall.
If they're in it, they're uncredited cameos.
This is a brilliant idea for the Russians.
They just need to get the United States to partner with them, and then when they fail to meet their financial obligations, the US will cover for them.
It's working for the space station, why not a tunnel?
Unfortunately, it's mostly irrelevant that Linux will be available first. How many hardware vendors are going to actually develop systems to use this chip and market them without Windows? Will Dell accept the overhead of carrying Linux-only hardware? I don't think so.
On the other hand, this may be a chance for VA Linux to have a product that you can't buy elsewhere.