I think it's actually the opposite - the commercial-size shipments of medications don't tend to have tamper-resistant caps and other features.
For over-the-counter drugs tamper-proof packaging is required by 21CFR211.132.
I couldn't see any regs regarding non-OTC packages, but I think that most big companies provide fairly strong tamper-evident packaging for drugs when they are in transit. They may not need tamper-evident seals on individual packages, but they usually use shrink-wrap on shipping containers and stuff like that to protect large shipments.
Big companies don't want drugs to be tampered with. When 10 people who take some branded product die of poisoning, it doesn't matter if the tampering was shown to have happened after purchase, or in the store - the brand is damanged. Likewise, big companies don't like counterfeits since they are the ones who are likely to get sued when it happens.
I believe that many big companies take steps to mark their drugs using high-tech methods at the chemical level - this is usually kept secret (security by obscurity). I remember reading an article about a company that came out with a way of making microscopic beads that were multi-layered and each layer could be a different color. You could make up a code system (like used on resistors) and toss the beads into your granulation prior to pressing tablets. In the event that somebody dies from your drug, you could analyze a sample of the material to see if you really made it.
Drug counterfeiting is serious business - since it is undetectable to the consumer.
From the screenshots it looks like they're using vncserver/vncviewer to accomplish this.
My understanding is that this requires that you use the Xvnc X server, and then probably attach to it locally via a regular X server. This is probably NOT accellerated at all for particular hardware, and requires that you run two X servers (which has to add at least a little overhead).
I contemplated this setup at home so that I could seemlessly access my X session from another windows-based computer at home if the KVM on my linux box was in use already, but I decided it probably wasn't worth the pain especially with the extra overhead and probable loss of accelleration.
Now, since Fedora is aimed at business users maybe the loss of accelleration is no big deal. For a server they would probably be accessing the server remotely anyway.
The problem with X11 is that the seamless network interface works real well in one direction - launching a remote application on your local screen. What it doesn't do well is taking a remote application already attached to a remote screen, and moving the window to a local screen - at least not without some support for this built into the individual application. You can always kill the app and re-launch it, and for many well-built apps this is fine since they'll checkpoint on a SIGTERM and launch gracefully.
On the other hand, if you have an app which doesn't save state open on one computer with 12 unsaved open, and you want to continue browsing from a different computer, then you're kind of out-of-luck unless you have something like vnc.
The screenshot states that to connect remotely you should use the "vncviewer" command - that ISN'T remote desktop. I have it installed on my gentoo box for when the occassion demands...
These are all optional dependencies for mplayer (just a small subset of them). If you don't have the associated use flag set, then the dependency isn't checked and isn't compiled in.
Why configure all this stuff yourself when somebody else has already taken the trouble to?
First, just use the etc-update script which does all this interactively. Unless you haven't updated a single packgae in six months you're unlikely to have many important files to actually update. Also, if the only thing that has changed is the version number in the file header the script will just overwrite the file without asking.
Second, how else should it behave? There are really only two viable options:
1. Just blindly overwrite config files. Many other distros I've used did this with at least some other packages and it was a major pain to deal with.
2. Write scripts for every package under the sun to smartly patch config files. This would probably still need to be interactive. Honestly, unless upstream package maintainers do this, I doubt any distro would undertake this. A few packages do have this kind of behavior, but not many.
3. Just never update config files. Often this works OK since defaults are usually sane, however sometimes a security patch involves config changes - and if a user wants to ignore the config change it should be a conscious decision...
Makes sense. You were booted using an x86 kernel, which only understands the 32-bit x86 world. The amd64 stage3 tarball contains 64-bit binaries, and an x86 kernel has no idea what to do with those.
You probably could install it the other way around - booting off an amd64 CD and installing the x86 tarball. The amd64 kernel (assuming multilib is supported on the CD version) understands both archs and could install a 32bit x86 stage3 and run it. Of course, you'd still need an amd64 in order to pull this off (can't boot an amd64 kernel on an x86 chip).
Just remember, the amd64 is backwards compatible (with suitable configuration). The x86 is NOT forwards compatible...
Reading your description of ripple patterns made me think of good way of visualizing how x-ray crystallography works.
In crystallography you basically get a measurement of the amplitudes of a bunch of spacial wave functions (3D ripples of existance and non-existance of matter). If you visualize this in 2D, a checkerboard kind of looks like a set of two waves - one which ripples along the vertical axis, and another along the horizontal.
The problem in crystallography is that you don't have phase information for the waves. For a checkerboard this is no big deal, but if you are trying to describe a complex figure with the sum of hundreds of waves that all cancel each other out just right, then not having them aligned is a big deal.
The art of crystallography is basically taking a phase-less JPG file, doing a few tricks to get a rough approximation for the phases, which yields a very-low-resolution image, and then drawing over the low-res image as best you can and using the tentatively-decoded image to better-estimate the phases in the real data. As you can imagine, there is a lot of potential for bias.
I figured that anybody interested in wavelets and discreet cosine transforms of 2D images might have some curiousity about real physical experiments that end up generating fourier transforms of 3D images.
(Real quick - the reason that crystallography generates wave amplitudes (reciprocal space) rather than a real image (real space) is that the measurement passes photons through a substance, which tend to bouce off of it. When they bounce you get interference if photons tend to bounce off the substance at depths that are multiples of the wavelength. So, you essentially are measuring the extent to which a substance has a pattern of mass concentrated at equally spaced intervals of various multiples of the wavelength of the X-ray beam. Of course, a pattern of something concentrated at an interval is a wave - so you're looking at matter as a sum of mass-waves in 3D space. Each wave frequency leads to a different interference pattern peak. So, if you look at the interference pattern bounced off the substance each spot corresponds to a different wave component, and the intensity of that spot corresponds to the amplitude. The detector can't pick up phase, so that is lost.)
Are you in fact making that statement in comparison to the x86_64 - aka Athlon64? While it can execute x86 instructions it is definitely a big leap forward.
My year-old 2GHz AMD64 can keep up with even the latest Intel P4s at most applications (there are a few where the raw GHz helps). It certainly puts out FAR less heat than a typical Intel chip. And that isn't counting its capability to throttle down when idle.
Backwards compatiblity is a big deal. Even though the amd64 architechture is nearly identical to the x86 there are still tons of apps that are buggy when compiled 64bit. As a result, I can just run them 32bit. That gives me 64bit performance on most applications without having to make tough decisions over "must-have" apps which refuse to work without significant patching.
Don't get me wrong - even x86_64 has a lot of baggage from its x86 heritage. However, if you do a little reading up on it you'll probably find that it gets around many of the x86 limitations.
There is plenty of room for improvement, but the x86-based architechture has been remarkably long-lasting. I look forward to the day when there is a smooth migration path to something better, but we're not there yet...
The trick is finding the right balance. All jobs have ebbs and flows when it comes to workload. You don't want to make the low point 40 hours and then let your hours vary from 40-60. The trick is to make your average at or below 40, and find developmental or project-oriented stuff to do on lighter weeks, and focus on the critical stuff when your job seems to be ready to explode.
If everybody is busy for a solid 40 hours on a non-busy week, then the company is understaffed. You can't staff for peaks either, obviously. However, management should be staffing for at least an average load.
If I never left work when something important was being worked on, then I'd never come home. Most projects span months - and all the invested time is important. Importance should determine what you work on - not whether you lose your hair while working on it.
Try scheduling developmental activites and longer-term projects into your workweek. Then when things flare up you can drop the non-urgent tasks to make room.
IMHO, 50 yards is too close for a gas station, too. Children are not expendible to me...
Nobody is expendible to me. However, I'm not advocating that flammable materials not be stored anywhere within 50 yards of any place that a human being spends a lot of time...
Tanks should be stored with reasonable safety precautions even if they're in the middle of nowhere. It shouldn't matter if a school is nearby. If it isn't safe, the fact that it isn't near a school but instead near my office building doesn't make me feel better...
Of course, what disturbs me isn't that MTBE makes water taste bad, but the fact that people seem unconcerned about all the other stuff apparently leaking into their water supply which doesn't taste bad, but is likely to be at least as bad for your health.
There wouldn't be MTBE in water supplies if gas tanks didn't leak. And if there is MTBE, there is probably other stuff which is harmful. However, that stuff isn't cosmetically apparent, so why bother fixing the real problem (leaking tanks)?
Now if only there were an extension that made the firefox entensions page searchable that would be something!:)
Seriously, though, there are somewhere around 100 extensions on the page, and no way to search other than displaying them 50 at a time and doing a text search on the webpage...
Java and Flash on Linux are at least as good as their Windows versions.
That is of course assuming you are running 32-bit x86 code. Java and Flash are definitely not mature on AMD64, speaking from personal experience. Flash is OK some of the time, Java virtually never works just right in my experience, unless you are litterally running helloworld...
I think you have to use some sense - try to look at what you shoot at before you shoot at it.
Also - if you and the kids are tucked away in a corner of the house then call the police and wait with the shotgun pointed at the door - no need to go hunting for trouble.
On the other hand, if your bedroom is on the first floor, and the kids are upstairs, and the intruder is somewhere in-between, then use judgement and shoot to kill if necessary. You should probably give warning and an opportunity to flee, but if the guy so much as flinches you've already given him more opportunity than he deserves.
In any case, don't bother owning a gun unless you're willing to kill somebody with it - otherwise the gun is more likely to get yourself killed. If you point a gun at somebody then you had better mean to fire. Sure, it would be nice if somehow you didn't have to, but if you tell the guy to put his hands on his head and go out the door he came in, then if the guy so much as reaches towards you he should be pumped full of lead.
If I were on a jury for somebody who killed somebody in defence of his home and he didn't do anything criminally idiotic, I'd hang the jury in deliberation for ten years if that is what it took to get the guy acquited. Yeah, it is a shame that some junkie got wasted, but not nearly as much of a shame as if one of his kids got hurt.
If a crook is after property he should be smart and break in at 2PM when everybody is at work - not at 2AM when everybody is asleep...
I would agree that fake files should be easy to block - you just need volunteers to tag them and software to automatically figure out where they are coming from and put the IP on the ban list for x hours.
However, what most people are probably interested in is avoiding survailence. I'd be skeptical of whether any program could really accomplish this.
If I were an investigator for the ??AA I would just get a broadband account on AOL and start scouring the net. If your software was smart enough you could even do it over dialup - you'd just download a few blocks of the shared file and use some algorithm to check them against your database of infringing works.
The volunteer effort would be ineffective against this. Even if you could detect this scanning you would still have a delay between the onset of scanning and institution of the ban. In the case of blocking fake files that is no biggie - so a few slip through. In the case of enforcement, however, those volunteers suddenly are on the front lines...
Just a little clarification for the sake of readers who don't know anything about unix file unlinking.
If you use unix/linux, try this experiment:
Create a file foo.txt. Open it with an editor.
Now, from a separate shell, rm the file.
The editor can still save changes. As soon as the editor exits, the file will be completely deleted. I'm not sure about current versions of linux, but in the past at least you could do an ls -a of the directory containing the file and see a hidden file with a random name which contained the file's contents.
In unix, the rm command unlinks a file. That is, it removes its directory entry. If there is another hard link to the same file, it will not be deleted. If there is a file descriptor linked to the file, it will not be deleted.
As soon as the last link is destoryed and there are no open file descriptors for the file, it gets deallocated on the disk.
Personally, I like the linux way - it lets me backup open software, the kernel, the X server, whatever. On windows, backups tend to miss critical files like the registry, OS files, etc. I'm sure commercial backup software use some sort of trick to get around some of this, and other utilities require booting from CD so that the files aren't in use in the first place. I've found the best way to backup windows profiles is to have them roam from samba shares and then back them up in linux, which doesn't care who has the file in use...
Since when does the constitution say that you have to use an austrailian ballot?
The constitution simply says that the states choose electors, and those electors choose the president. If there is no majority, then Congress picks the winner.
So, all you need is to change your local state laws to allow for approval voting within that state. I believe that Louisiana already has a runnoff-style election.
Now, I think that the electoral college needs some reform as well, but that would take an ammendment.
In any case, the major parties could back a move to approval voting. Suppose that 20% of the population voted green, 35% democrat, and 45% republican. The democrats would have a strong incentive to push approval voting through the system, since it would give them an advantage over the republicans (who would gain a minority of the 2nd-choice votes). Now, if the greens just vote democrat, then the democrats have no incentive to push for a change...
Under your strategy, we will never have approval voting.
After all, if the winner-take-all system ensures that all votes go to the two parties in power, why would the two parties in power want to change the system?
On the other hand, if you keep an elusive set of votes beyond the reach of the parties in power, they will have motivation to change the rules.
You pretend that voters have no control over the rules - when if fact they do. This changes voting strategy - if your only goal is to see the lesser of two evils in office then you vote mainstream. If your goal is to reform voting then you vote 3rd-party.
There is a point you are missing - you're assuming that we can't change our voting system.
By having a significant pool of 3rd-party votes in every election, we encourage the two main parties to adopt a system like approval voting which would allow them to get 2nd-choice votes from the otherwise 3rd-party voters.
Most 3rd-party voters would be willing to vote for a mainstream candidate as their 2nd choice.
-O3 generates larger code than -O2, so you lose the performance gains in increased application startup for most types of programs. I suggest -O2 or even -Os.
I hear that with gcc 3.4 this is less of an issue. I used to be -O2 with 3.3, but with 3.4 I've been running -O3 as a result. I'm not sure if anybody has done a conclusive study. Don't forget -fstack-protector either! (Although not all packages support it yet. When problems are uncovered ebuilds are usually modified accordingly.)
I'm not sure about x86, but gcc 3.4 is becoming fairly mainstream on amd64. (Granted amd64 itself is hardly mainstream, but it is reasonably solid on gentoo, aside from a few packages that don't get good outside support (such as Java - not much stability in the 64-bit JVMs).)
Sounds like a solution to the IT unenployment problem! Just sleep right through it. Maybe in 1000 years or so the demand for a Java developer will be once-again=measurable...
That is easily solved. Require that landing fees be fixed for anybody who wants to land at an airport. If you can land 100 planes in a day, then auction off 100 spots - if a carrier is willing to pay more, then they get the spot.
The best way of dealing with a fixed commodity is usually to auction it.
If we want to lower prices across the board, then a new airport should be built. Assuming that we can get past the NIMBY issue, that should happen on its own once auction prices rise to a sufficient level.
If Ma Bell were still in existence, the Feds could have easily required broadband access to every home.
Uh, you do realize that back in the days of Ma Bell you weren't allowed to even plug a modem into a phone jack? Why do you think that people used acoustic couplers?
Sure, you'd have high speed internet access. Oh, you would only be able to use it on a genuine Bell computer - buy your 1.2 GHz model for only $1500!
The problem is that barriers to local phone competition need to be lifted. Sure, you won't see competition in the suburbs - at least not initially, but in major cities it would probably take off quickly since the per-capita cost of additional wiring isn't too bad. It would probably slowly spread out into the suburbs much as phone service did in the first place.
We also trashed our airline industry all in the name of competition -- too bad that those really cheap airline tickets are being subsidized by the American taxpayer in the form of airline bankruptcy bailouts and fuel subsidies.
Regardless about how you feel about phone service monopolies - airlines clearly are not a "natural monopoly" (perhaps airport management is, but certainly not flying the planes themselves). All the federal government needs to do is let some airlines fold, and let the industry consolidate to a reasonable number of players. Fares would rise, of course, but not to the levels they used to be at. Back before deregulation, airline fares were such that only the "jet set" could afford to fly at all. There were no sales - prices were imposed from on high. Even the food served was regulated, in order to prevent airlines from differentiating themselves. That is just crazy.
Regardless of what you think about phone service, airlines should be in complete competition. Barriers to entry are fairly low, no real infrastructure is required (besides the planes and a few mechanics) - none of the usual arguments for natural monopolies really apply. If you're going to regulate airlines, we should be regulating the convenience stores down the street...
But I do not agree SCC should have the right to do a byte copy of the Lexmark code.
The court merely ruled that by abusing the purpose of copyright, Lexmark lost their right to copyright protection. It was Lexmark's foul, and they've already made tons of profit by slowing down the tide of ink competition through legal fear.
Who was harmed by this ruling? Lexmark lost nothing (well, except for an illegal monopoly, but they'd have lost that with your solution as well).
Basically, the court said that if your software checks for a particular series of bytes in a particular location before interoperating with something, then somebody can copy those bytes. If Lexmark wants to execute those bytes as code, that is on them.
In the end, both the court's and your rememdies seem to be the same. However, your's requires lexmark consumers to ship in their printers for firmware replacement, and basically puts SCC out of business since most consumers won't bother to do that. In other words, it rewards the abuser.
The court has it right - the purpose of copyright is to allow somebody to profit from an original work, not to perpetuate monopolies on hardware. If Lexmark wanted to take steps to prevent somebody from stealing their firmware code and sue somebody under the DMCA for doing so, they'd be acting within the purpose of the law. On the other hand, SCC didn't care about the firmware, they only copied it because Lexmark forced them to do so in order to allow for interoperability.
Slashdot Mirror
I think it's actually the opposite - the commercial-size shipments of medications don't tend to have tamper-resistant caps and other features.
For over-the-counter drugs tamper-proof packaging is required by 21CFR211.132.
I couldn't see any regs regarding non-OTC packages, but I think that most big companies provide fairly strong tamper-evident packaging for drugs when they are in transit. They may not need tamper-evident seals on individual packages, but they usually use shrink-wrap on shipping containers and stuff like that to protect large shipments.
Big companies don't want drugs to be tampered with. When 10 people who take some branded product die of poisoning, it doesn't matter if the tampering was shown to have happened after purchase, or in the store - the brand is damanged. Likewise, big companies don't like counterfeits since they are the ones who are likely to get sued when it happens.
I believe that many big companies take steps to mark their drugs using high-tech methods at the chemical level - this is usually kept secret (security by obscurity). I remember reading an article about a company that came out with a way of making microscopic beads that were multi-layered and each layer could be a different color. You could make up a code system (like used on resistors) and toss the beads into your granulation prior to pressing tablets. In the event that somebody dies from your drug, you could analyze a sample of the material to see if you really made it.
Drug counterfeiting is serious business - since it is undetectable to the consumer.
From the screenshots it looks like they're using vncserver/vncviewer to accomplish this.
My understanding is that this requires that you use the Xvnc X server, and then probably attach to it locally via a regular X server. This is probably NOT accellerated at all for particular hardware, and requires that you run two X servers (which has to add at least a little overhead).
I contemplated this setup at home so that I could seemlessly access my X session from another windows-based computer at home if the KVM on my linux box was in use already, but I decided it probably wasn't worth the pain especially with the extra overhead and probable loss of accelleration.
Now, since Fedora is aimed at business users maybe the loss of accelleration is no big deal. For a server they would probably be accessing the server remotely anyway.
The problem with X11 is that the seamless network interface works real well in one direction - launching a remote application on your local screen. What it doesn't do well is taking a remote application already attached to a remote screen, and moving the window to a local screen - at least not without some support for this built into the individual application. You can always kill the app and re-launch it, and for many well-built apps this is fine since they'll checkpoint on a SIGTERM and launch gracefully.
On the other hand, if you have an app which doesn't save state open on one computer with 12 unsaved open, and you want to continue browsing from a different computer, then you're kind of out-of-luck unless you have something like vnc.
The screenshot states that to connect remotely you should use the "vncviewer" command - that ISN'T remote desktop. I have it installed on my gentoo box for when the occassion demands...
They basically let you pick the dependencies on either a global or a package level. My settings look like:
USE="acpi apache2 cups debug divx4linux dvd ethereal evo fbcon flac gd gimpprint glut imagemagick imap innodb -java kerberos maildir multilib nptl ntlm oav pda php samba sasl speex theora tiff wmf qt readline -ldap"
Of course, I also inherit a bunch of default flags with this as well (but as you can see I negatively overrode two default flags).
A typical ebuild file (the gentoo equivalent of a package) might contain lines like:
These are all optional dependencies for mplayer (just a small subset of them). If you don't have the associated use flag set, then the dependency isn't checked and isn't compiled in.
Why configure all this stuff yourself when somebody else has already taken the trouble to?
A few things:
First, just use the etc-update script which does all this interactively. Unless you haven't updated a single packgae in six months you're unlikely to have many important files to actually update. Also, if the only thing that has changed is the version number in the file header the script will just overwrite the file without asking.
Second, how else should it behave? There are really only two viable options:
1. Just blindly overwrite config files. Many other distros I've used did this with at least some other packages and it was a major pain to deal with.
2. Write scripts for every package under the sun to smartly patch config files. This would probably still need to be interactive. Honestly, unless upstream package maintainers do this, I doubt any distro would undertake this. A few packages do have this kind of behavior, but not many.
3. Just never update config files. Often this works OK since defaults are usually sane, however sometimes a security patch involves config changes - and if a user wants to ignore the config change it should be a conscious decision...
Makes sense. You were booted using an x86 kernel, which only understands the 32-bit x86 world. The amd64 stage3 tarball contains 64-bit binaries, and an x86 kernel has no idea what to do with those.
You probably could install it the other way around - booting off an amd64 CD and installing the x86 tarball. The amd64 kernel (assuming multilib is supported on the CD version) understands both archs and could install a 32bit x86 stage3 and run it. Of course, you'd still need an amd64 in order to pull this off (can't boot an amd64 kernel on an x86 chip).
Just remember, the amd64 is backwards compatible (with suitable configuration). The x86 is NOT forwards compatible...
Reading your description of ripple patterns made me think of good way of visualizing how x-ray crystallography works.
In crystallography you basically get a measurement of the amplitudes of a bunch of spacial wave functions (3D ripples of existance and non-existance of matter). If you visualize this in 2D, a checkerboard kind of looks like a set of two waves - one which ripples along the vertical axis, and another along the horizontal.
The problem in crystallography is that you don't have phase information for the waves. For a checkerboard this is no big deal, but if you are trying to describe a complex figure with the sum of hundreds of waves that all cancel each other out just right, then not having them aligned is a big deal.
The art of crystallography is basically taking a phase-less JPG file, doing a few tricks to get a rough approximation for the phases, which yields a very-low-resolution image, and then drawing over the low-res image as best you can and using the tentatively-decoded image to better-estimate the phases in the real data. As you can imagine, there is a lot of potential for bias.
I figured that anybody interested in wavelets and discreet cosine transforms of 2D images might have some curiousity about real physical experiments that end up generating fourier transforms of 3D images.
(Real quick - the reason that crystallography generates wave amplitudes (reciprocal space) rather than a real image (real space) is that the measurement passes photons through a substance, which tend to bouce off of it. When they bounce you get interference if photons tend to bounce off the substance at depths that are multiples of the wavelength. So, you essentially are measuring the extent to which a substance has a pattern of mass concentrated at equally spaced intervals of various multiples of the wavelength of the X-ray beam. Of course, a pattern of something concentrated at an interval is a wave - so you're looking at matter as a sum of mass-waves in 3D space. Each wave frequency leads to a different interference pattern peak. So, if you look at the interference pattern bounced off the substance each spot corresponds to a different wave component, and the intensity of that spot corresponds to the amplitude. The detector can't pick up phase, so that is lost.)
Except that their market is teenagers, and half of the non-teenagers aren't in the IT profession and could care less.
Boycotts aren't going to work well...
Are you in fact making that statement in comparison to the x86_64 - aka Athlon64? While it can execute x86 instructions it is definitely a big leap forward.
My year-old 2GHz AMD64 can keep up with even the latest Intel P4s at most applications (there are a few where the raw GHz helps). It certainly puts out FAR less heat than a typical Intel chip. And that isn't counting its capability to throttle down when idle.
Backwards compatiblity is a big deal. Even though the amd64 architechture is nearly identical to the x86 there are still tons of apps that are buggy when compiled 64bit. As a result, I can just run them 32bit. That gives me 64bit performance on most applications without having to make tough decisions over "must-have" apps which refuse to work without significant patching.
Don't get me wrong - even x86_64 has a lot of baggage from its x86 heritage. However, if you do a little reading up on it you'll probably find that it gets around many of the x86 limitations.
There is plenty of room for improvement, but the x86-based architechture has been remarkably long-lasting. I look forward to the day when there is a smooth migration path to something better, but we're not there yet...
The trick is finding the right balance. All jobs have ebbs and flows when it comes to workload. You don't want to make the low point 40 hours and then let your hours vary from 40-60. The trick is to make your average at or below 40, and find developmental or project-oriented stuff to do on lighter weeks, and focus on the critical stuff when your job seems to be ready to explode.
If everybody is busy for a solid 40 hours on a non-busy week, then the company is understaffed. You can't staff for peaks either, obviously. However, management should be staffing for at least an average load.
If I never left work when something important was being worked on, then I'd never come home. Most projects span months - and all the invested time is important. Importance should determine what you work on - not whether you lose your hair while working on it.
Try scheduling developmental activites and longer-term projects into your workweek. Then when things flare up you can drop the non-urgent tasks to make room.
IMHO, 50 yards is too close for a gas station, too. Children are not expendible to me...
Nobody is expendible to me. However, I'm not advocating that flammable materials not be stored anywhere within 50 yards of any place that a human being spends a lot of time...
Tanks should be stored with reasonable safety precautions even if they're in the middle of nowhere. It shouldn't matter if a school is nearby. If it isn't safe, the fact that it isn't near a school but instead near my office building doesn't make me feel better...
Of course, what disturbs me isn't that MTBE makes water taste bad, but the fact that people seem unconcerned about all the other stuff apparently leaking into their water supply which doesn't taste bad, but is likely to be at least as bad for your health.
There wouldn't be MTBE in water supplies if gas tanks didn't leak. And if there is MTBE, there is probably other stuff which is harmful. However, that stuff isn't cosmetically apparent, so why bother fixing the real problem (leaking tanks)?
Now if only there were an extension that made the firefox entensions page searchable that would be something! :)
Seriously, though, there are somewhere around 100 extensions on the page, and no way to search other than displaying them 50 at a time and doing a text search on the webpage...
Java and Flash on Linux are at least as good as their Windows versions.
That is of course assuming you are running 32-bit x86 code. Java and Flash are definitely not mature on AMD64, speaking from personal experience. Flash is OK some of the time, Java virtually never works just right in my experience, unless you are litterally running helloworld...
I think you have to use some sense - try to look at what you shoot at before you shoot at it.
Also - if you and the kids are tucked away in a corner of the house then call the police and wait with the shotgun pointed at the door - no need to go hunting for trouble.
On the other hand, if your bedroom is on the first floor, and the kids are upstairs, and the intruder is somewhere in-between, then use judgement and shoot to kill if necessary. You should probably give warning and an opportunity to flee, but if the guy so much as flinches you've already given him more opportunity than he deserves.
In any case, don't bother owning a gun unless you're willing to kill somebody with it - otherwise the gun is more likely to get yourself killed. If you point a gun at somebody then you had better mean to fire. Sure, it would be nice if somehow you didn't have to, but if you tell the guy to put his hands on his head and go out the door he came in, then if the guy so much as reaches towards you he should be pumped full of lead.
If I were on a jury for somebody who killed somebody in defence of his home and he didn't do anything criminally idiotic, I'd hang the jury in deliberation for ten years if that is what it took to get the guy acquited. Yeah, it is a shame that some junkie got wasted, but not nearly as much of a shame as if one of his kids got hurt.
If a crook is after property he should be smart and break in at 2PM when everybody is at work - not at 2AM when everybody is asleep...
I would agree that fake files should be easy to block - you just need volunteers to tag them and software to automatically figure out where they are coming from and put the IP on the ban list for x hours.
However, what most people are probably interested in is avoiding survailence. I'd be skeptical of whether any program could really accomplish this.
If I were an investigator for the ??AA I would just get a broadband account on AOL and start scouring the net. If your software was smart enough you could even do it over dialup - you'd just download a few blocks of the shared file and use some algorithm to check them against your database of infringing works.
The volunteer effort would be ineffective against this. Even if you could detect this scanning you would still have a delay between the onset of scanning and institution of the ban. In the case of blocking fake files that is no biggie - so a few slip through. In the case of enforcement, however, those volunteers suddenly are on the front lines...
Just a little clarification for the sake of readers who don't know anything about unix file unlinking.
If you use unix/linux, try this experiment:
Create a file foo.txt. Open it with an editor.
Now, from a separate shell, rm the file.
The editor can still save changes. As soon as the editor exits, the file will be completely deleted. I'm not sure about current versions of linux, but in the past at least you could do an ls -a of the directory containing the file and see a hidden file with a random name which contained the file's contents.
In unix, the rm command unlinks a file. That is, it removes its directory entry. If there is another hard link to the same file, it will not be deleted. If there is a file descriptor linked to the file, it will not be deleted.
As soon as the last link is destoryed and there are no open file descriptors for the file, it gets deallocated on the disk.
Personally, I like the linux way - it lets me backup open software, the kernel, the X server, whatever. On windows, backups tend to miss critical files like the registry, OS files, etc. I'm sure commercial backup software use some sort of trick to get around some of this, and other utilities require booting from CD so that the files aren't in use in the first place. I've found the best way to backup windows profiles is to have them roam from samba shares and then back them up in linux, which doesn't care who has the file in use...
Since when does the constitution say that you have to use an austrailian ballot?
The constitution simply says that the states choose electors, and those electors choose the president. If there is no majority, then Congress picks the winner.
So, all you need is to change your local state laws to allow for approval voting within that state. I believe that Louisiana already has a runnoff-style election.
Now, I think that the electoral college needs some reform as well, but that would take an ammendment.
In any case, the major parties could back a move to approval voting. Suppose that 20% of the population voted green, 35% democrat, and 45% republican. The democrats would have a strong incentive to push approval voting through the system, since it would give them an advantage over the republicans (who would gain a minority of the 2nd-choice votes). Now, if the greens just vote democrat, then the democrats have no incentive to push for a change...
Under your strategy, we will never have approval voting.
After all, if the winner-take-all system ensures that all votes go to the two parties in power, why would the two parties in power want to change the system?
On the other hand, if you keep an elusive set of votes beyond the reach of the parties in power, they will have motivation to change the rules.
You pretend that voters have no control over the rules - when if fact they do. This changes voting strategy - if your only goal is to see the lesser of two evils in office then you vote mainstream. If your goal is to reform voting then you vote 3rd-party.
There is a point you are missing - you're assuming that we can't change our voting system.
By having a significant pool of 3rd-party votes in every election, we encourage the two main parties to adopt a system like approval voting which would allow them to get 2nd-choice votes from the otherwise 3rd-party voters.
Most 3rd-party voters would be willing to vote for a mainstream candidate as their 2nd choice.
-O3 generates larger code than -O2, so you lose the performance gains in increased application startup for most types of programs. I suggest -O2 or even -Os.
I hear that with gcc 3.4 this is less of an issue. I used to be -O2 with 3.3, but with 3.4 I've been running -O3 as a result. I'm not sure if anybody has done a conclusive study. Don't forget -fstack-protector either! (Although not all packages support it yet. When problems are uncovered ebuilds are usually modified accordingly.)
I'm not sure about x86, but gcc 3.4 is becoming fairly mainstream on amd64. (Granted amd64 itself is hardly mainstream, but it is reasonably solid on gentoo, aside from a few packages that don't get good outside support (such as Java - not much stability in the 64-bit JVMs).)
Sounds like a solution to the IT unenployment problem! Just sleep right through it. Maybe in 1000 years or so the demand for a Java developer will be once-again=measurable...
That is easily solved. Require that landing fees be fixed for anybody who wants to land at an airport. If you can land 100 planes in a day, then auction off 100 spots - if a carrier is willing to pay more, then they get the spot.
The best way of dealing with a fixed commodity is usually to auction it.
If we want to lower prices across the board, then a new airport should be built. Assuming that we can get past the NIMBY issue, that should happen on its own once auction prices rise to a sufficient level.
If Ma Bell were still in existence, the Feds could have easily required broadband access to every
home.
Uh, you do realize that back in the days of Ma Bell you weren't allowed to even plug a modem into a phone jack? Why do you think that people used acoustic couplers?
Sure, you'd have high speed internet access. Oh, you would only be able to use it on a genuine Bell computer - buy your 1.2 GHz model for only $1500!
The problem is that barriers to local phone competition need to be lifted. Sure, you won't see competition in the suburbs - at least not initially, but in major cities it would probably take off quickly since the per-capita cost of additional wiring isn't too bad. It would probably slowly spread out into the suburbs much as phone service did in the first place.
We also trashed our airline industry
all in the name of competition -- too bad that
those really cheap airline tickets are being
subsidized by the American taxpayer in the form
of airline bankruptcy bailouts and fuel subsidies.
Regardless about how you feel about phone service monopolies - airlines clearly are not a "natural monopoly" (perhaps airport management is, but certainly not flying the planes themselves). All the federal government needs to do is let some airlines fold, and let the industry consolidate to a reasonable number of players. Fares would rise, of course, but not to the levels they used to be at. Back before deregulation, airline fares were such that only the "jet set" could afford to fly at all. There were no sales - prices were imposed from on high. Even the food served was regulated, in order to prevent airlines from differentiating themselves. That is just crazy.
Regardless of what you think about phone service, airlines should be in complete competition. Barriers to entry are fairly low, no real infrastructure is required (besides the planes and a few mechanics) - none of the usual arguments for natural monopolies really apply. If you're going to regulate airlines, we should be regulating the convenience stores down the street...
But I do not agree SCC should have the right to do a byte copy of the Lexmark code.
The court merely ruled that by abusing the purpose of copyright, Lexmark lost their right to copyright protection. It was Lexmark's foul, and they've already made tons of profit by slowing down the tide of ink competition through legal fear.
Who was harmed by this ruling? Lexmark lost nothing (well, except for an illegal monopoly, but they'd have lost that with your solution as well).
Basically, the court said that if your software checks for a particular series of bytes in a particular location before interoperating with something, then somebody can copy those bytes. If Lexmark wants to execute those bytes as code, that is on them.
In the end, both the court's and your rememdies seem to be the same. However, your's requires lexmark consumers to ship in their printers for firmware replacement, and basically puts SCC out of business since most consumers won't bother to do that. In other words, it rewards the abuser.
The court has it right - the purpose of copyright is to allow somebody to profit from an original work, not to perpetuate monopolies on hardware. If Lexmark wanted to take steps to prevent somebody from stealing their firmware code and sue somebody under the DMCA for doing so, they'd be acting within the purpose of the law. On the other hand, SCC didn't care about the firmware, they only copied it because Lexmark forced them to do so in order to allow for interoperability.