Government has for a long time charged taxes on products imported. What is the difference with a web service?
The difference is that it's much easier to sneak web services into the country than it is to sneak physical products in. To tax services the government would have to ban all encrypted traffic going into or out of the US, and then monitor all internet traffic, looking for tariff violations. Even then steganography would become popular, and it'd probably be a losing battle (I suppose they could ban possession of encryption or steganography products too).
The only reason the USA does not have laws going after offshore casinos is because polticians have not figured out it can generate votes.
Stopping porn from being viewed by children is something that most people would support.
Stopping casinos from being used by children is something that most people would support too. Stopping casinos completely, as well as stopping porn completely, isn't.
And most would not loose any sleep if it was taxed just like other vices, like cigarettes or alcohol. They have always been taxed higher than other items.
As long as it was limited to commercial porn enterprises, I personally wouldn't have a problem with a tax on porn, in theory. The problem I'd have with it is that it'd likely cost more money to enforce than it brought in in revenues, and/or the enforcement would cost us dearly in terms of other freedoms (encryption, protection against unreasonable searches, etc.)
Most Unix systems now do use TAI as their time base (except with an epoch of 1 JAN 1970) - the correction for leap seconds is done using the timezone files, leap seconds don't modify the clock value.
Any system which does this isn't a Unix® system. The POSIX standard is to use UTC, not TAI. I think you're wrong with regard to what most unixlike operating systems use, too. Do you have any cite to back up your claim?
For myself, I've never had a problem with figuring out what day it was, even though I'm usually up at midnight. Do it like baseball - you call the day based on when it started when referring to "whole days", otherwise just use whatever the current time stamp shows.
So if the date changes at the peak of the sun, and I tell you "let's have lunch Wednesday", what day am I referring to?
While we're at it, let's either change 12:00 to 0:00 or change the date at 1 AM. That's another big source of confusion.
It actually does matter a lot in some applications. Take satellite tracking. A low earth orbit satellite moves about 7 km in one second. If you're off by one second because of confusion about a leap second, you've made a position error of 7 km. That's a lot.
No, I wasn't talking about calculating the current time. I'm talking about calculating the number of seconds between now and some time in the future. That's what you can't do, and I can't think of any reason why you'd ever need to do that.
There are many perfectly valid arguments against leap seconds. The difficulty in calculating the exact number of seconds between two events
That's impossible to do precisely anyway due to relativity, and as the time between the two events increases the precision goes down more and more. But it's not even that difficult to calculate within a system of leap seconds (within the limitations of the relative motions and gravitational effects of the two clocks and/or the distance between the locations of the events), you just need a table of historical leap seconds.
If you want to make things even easier on yourself, then don't record the times of things using UTC if what you care about is measuring the number of seconds between things. UTC isn't about that. It's about making it easy for humans to communicate times which can easily be converted to local times. And local times are, more than anything else, about measuring positions within a day.
the fact that calculations involving future times can give different results after leap seconds are declared
This is the part that I was talking about previously. I don't see why one would need to calculate the number of seconds until a time in the future (for practical purposes). If it's really necessary, then that time in the future shouldn't (can't, actually) be declared in UTC.
the difficulty of dating events that occur near or during leap seconds
What's difficult about it? I don't understand this point at all. There is a very clear and unambiguous way to date any event, regardless of whether or not it occurs near or during a leap second. "1998-12-31T23:59:59.00Z, 1998-12-31T23:59:60.00Z, 1999-01-01T00:00:00.00Z, 1999-01-01T00:00:01.00Z". You must be talking about UNIX time.
But these are not good arguments for removing leap seconds from UTC! Why do that when you can choose from two perfectly good standard time scales that don't have leap seconds?
I guess we're on the same page here. But I still don't understand the practical benefit of knowing the number of seconds between now and some date/time in the future.
It would have been really nice had the UNIX designers chosen the TAI timescale instead of UTC as the internal representation of time.
UNIX time, as declared by POSIX, is broken in design. They use an integer which is supposed to represent "the number of seconds elapsed since 00:00:00 on January 1, 1970" then they say it's in Coordinated Universal Time. But UTC is not an integer, and it doesn't measure the number of seconds elapsed since midnight 1/1/1970 (at least not under the UTC definition of the second which is equal to the SI definition).
Since converting an integer into a date/time involves some calculation anyway, I agree with you it would have made much more sense to use TAI as the base. See http://cr.yp.to/proto/utctai.html for another argument.
Of course, this system would only be useful for timestamps since about 1955, when we started paying attention to leap seconds in the first place. Before that we can't accurately measure the number of seconds between two events, using the modern definition of the second. Depending how far back you go the systems become more and more convoluted.
I wonder if it's too late to make such a change...
Depends how much control you have over your system, and how much you're willing to break POSIX. For backward compatibility, we would probably need to come up with a new system call, though maybe a good hybrid solution would be to use UT1 internally. At least then the clock slews are spread out.
TAI (atomic time) is a "digital" represenation of time: e.g. a second is a known quantity, and we count one after the other forever and ever.
Even that's not really true, though. A second in one part of the earth is not exactly the same as a second on another part of the earth, due to the relative velocity and gravitational differences.
Because UNIX time_t is based on UTC, coversions have to be done to consult tables of leap seconds, and, what's worse, time_t can produce ambiguous results when referring to events occuring during a leap second.
Well, the way UNIX time is stored according to POSIX, no tables are needed to convert UNIX time to UTC, but you do get the abiguous results. If you're going to store time as a single number, you have to have one or the other.
If we are going to be talking about time kept by computers, lets do it in a way that's convenient to the computers (e.g. TAI).
Considering that we're only talking about something like one second per year, I agree here. We don't need leap seconds. If the position of the sun shifts by one hour over the course of 500 years people will be able to handle it.
I don't see the point of the leap second, but by the same token, I don't see how it's so harmful either. All that really matters is that we have a precise definition so that people can communicate properly, and then it's up to the programmers to be careful. This means not using localtime() for scheduling cron jobs or other things which need a number which is non-ambiguous, nor using it for measuring the time between two events when that needs to be accurate to the second. At least not on a POSIX-compliant computer.
With our current system of leap seconds, does the Unix timestamp actually reflect the CORRECT number of seconds since Jan 1st, 1970?
The other answers to this were somewhat confusing, so I'll give one too: No, unix timestamps don't reflect the number of seconds since 1/1/1970, at least not if they follow the POSIX standards. Unix timestamps reflect the UTC time. Here's another link.
It doesn't need to be nearly as complicated as you make it out to be, and computers have to deal with date changes in the middle of a day all the time.
Computers have no problem with this, but humans would. The fact that the day would change while most people were wide awake and working would be very confusing. Universal time is fine for computers, and many computers are set to UTC. They really should be set to TAI, which is what you suggest (UTC without the leap seconds). But for humans, it makes more sense to make a day rougly equivalent to the time you wake up and go to sleep. In fact, if you're going to change things, it'd probably be better if we just did away with noon being the high point of the sun, and instead set midnight to somewhere around the middle of the time when people are asleep. It's those couple hours discrepancy which cause the most confusion already anyway ("I'll meet you tonight at 1AM" when you technically mean tomorrow morning).
And are the library functions able to account for future leap seconds that haven't even been scheduled yet? Clearly they can not be, which means the addition of leap seconds will cause values returned by those functions today to differ with the values returned in the future.
I think you are wrong on this one, and the prove is Linux, you see, on Linux, it IS difficult to spread a virus because of the system DESIGN for security. Maybe it is kind of cumbersome for the user to have to introduce the root password when installing a RPM but, at the end, you have 99% less viruses spreading.
I'm not sure how you define "virus", but by my view of what a virus is you don't have to be root to have or spread a virus.
The only real advantage of linux in this space is if you have a multi-user system. Then, at least in theory, you can't spread a virus from one user to another. But for a single user desktop machine this is pretty much meaningless, and in practice it's relatively meaningless anyway due to the possibility of using a root exploit.
I guess here I'm lumping all Linux systems together, and maybe that's not fair. After all, there are some build-it-yourself Linux systems out there that utilize different users for every single software package, and on those systems it's much more difficult to spread a virus. But this idea hasn't really caught on with any of the mainstream distros I know of.
Most privilege escalation vulnerabilities are in the kernel or in applications that run as root.
Aren't all privilege escalation vulnerabilities are in the kernel or in applications that run as root? If an application which doesn't run as root can allow someone to gain root, then there must be a bug in the kernel.
There was a recent one in the Linux kernel involving an old shared library loading system call.
I'm not sure what that has to do with the kernel. Aren't shared libraries handled by ld.so? Which system call are you referring to?
So, essentially, what you're saying is that a program shouldn't be allowed to modify the operating system while it's running, because that might crash the operating system. I don't see the point.
A program running with administrator privileges can install a driver.
Now granted, with most OSes, including unix ones, it's much easier than that. For instance, if you screw with the inodes of a running system, you can crash HP/UX (at least you could when I worked for HP). I wouldn't necessarily call that a design flaw, though. In fact, it could very well be considered a security feature. If something that fundamental is screwed up, either you've got buggy hardware, a buggy OS, or you're under attack. In any of those three cases I'd say it's safer from a security standpoint to panic than to try to repair yourself.
Some people of course have different needs. Some systems can't afford to reboot, they're that mission critical. But for most operating systems it's better to blue screen or to panic or whatever it's called. Reliability can be handled by having multiple systems running.
Probably. But maybe he's running a system with a microkernel, which doesn't need to be rebooted to patch a root exploit.
Hell, maybe he installed a minimal version of Linux a year ago, and is using kernel modules for all the advanced functionality. There probably aren't any root exploits in that (what root exploits are there in the kernel, and not the apps, anyway?)
Airwaves aren't like food or books. But I agree with you that the best solution would be to eliminate the government intervention beyond defining and enforcing property rights.
Actually treating the airwaves as property is a big mistake. The current division of the spectrum is an artifact of nearly 100 year old technology.
Just because something is treated as property doesn't mean you have to split it up the way it's currently split up.
With UWB transmissions, the airwaves could be used like a huge Ethernet network that everyone can utilize at the same time.
UWB transmissions work fine with a small number of point to point transmissions over a small area, something like a wifi connection. But something like the radio or television spectrum, where it is one person broadcasting high bandwidth content to a lot of people over a wide area, those people having very cheap receivers, treating it like an ethernet network would cause far too many collissions. Think about what would happen if 20 people tried to broadcast 10 mbps streams over 100 gig ethernet (with a hub, not a switch). Think about what would happen if you used the ethernet protocol over a wide-area network. Either of these problems alone are enough to force you to use a different protocol.
As the technology improves and the costs come down, maybe we can move to a system of point to point links, and bandwidth will be essentially unlimited. One news station (I think it was CNN) has built a system to track a satellite in a moving car. They use it in Iraq. With a system like that, for instance, anyone with a satellite in the sky could share the same airwaves. Make it terrestial based somehow (it'd be hard due signals bouncing all over the place), and you wouldn't even need the satellite. But the time when every Joe can afford one of these in his car is a long way off, and it'll probably always be more costly than normal old broadcasting.
The airwaves need to be regulated, and only the power of the state can back such regulation. People have to agree only to use certain frequencies within certain ranges for radio to be effective and useful for the most people. Do you have a better solution?
I wouldn't call it regulation to enforce property rights. Regulation implies the government is telling you what to do with your property, not that they are enforcing a property owner's right to do what they want with it.
Is this the first step toward getting our airwaves back or is this just a slap on the wrist?
We'll get our airwaves back as soon as the government stops telling us what to do with it, and not a moment before. I don't see it happening any time soon. There's far too much corporate interest in keeping these government handouts.
There is the really lame argument that the airwaves are a public trust, but that just means the government was dumb enough not to auction them to the highest bidder.
Exactly. That's the first step toward getting our airwaves back. Get rid of the government interference, and treat it like any other real property. Auction it off, let people use it for whatever they want (hint, it probably won't be free any more), and collect a property tax once a year based on the value of the portion of the spectrum.
Sure, you can reserve one or two stations for public interest, which must be run by non-profit charities, but the rest of it is so commercialized nowadays that we shouldn't bother pretending it's in the public interest.
Ultimately, there's no problem if you have a free market on the airwaves.
But there isn't a free market on the AM/FM radio airwaves. Not even close. This part of the radio spectrum is given to the radio stations essentially for free, in return for acting in the public interest in certain ways (not encrypting, not being obscene, broadcasting public safety announcements, not accepting payola, etc).
If the airwaves really were free, if they were auctioned off to the highest bidder who could then use them for any reason, similar to the satellite and cell phone frequencies, this wouldn't be a problem. But that's not how the AM/FM radio airwaves work, and that, to answer the original question, is why this should be illegal.
I believe US law treats companies as legal personae, granting them similiar rights to people.
That would be a gross oversimplification of the matter. Only people have rights, but people have those rights while acting through a corporation, just like they do while acting as individuals.
Slashdot Mirror
vote for hopeless third parties as some kind of "statement" that in the end means nothing.
The same could be said of any individual vote. Each one means nothing. Votes are only meaningful in aggregate.
Government has for a long time charged taxes on products imported. What is the difference with a web service?
The difference is that it's much easier to sneak web services into the country than it is to sneak physical products in. To tax services the government would have to ban all encrypted traffic going into or out of the US, and then monitor all internet traffic, looking for tariff violations. Even then steganography would become popular, and it'd probably be a losing battle (I suppose they could ban possession of encryption or steganography products too).
The only reason the USA does not have laws going after offshore casinos is because polticians have not figured out it can generate votes.
Stopping porn from being viewed by children is something that most people would support.
Stopping casinos from being used by children is something that most people would support too. Stopping casinos completely, as well as stopping porn completely, isn't.
And most would not loose any sleep if it was taxed just like other vices, like cigarettes or alcohol. They have always been taxed higher than other items.
As long as it was limited to commercial porn enterprises, I personally wouldn't have a problem with a tax on porn, in theory. The problem I'd have with it is that it'd likely cost more money to enforce than it brought in in revenues, and/or the enforcement would cost us dearly in terms of other freedoms (encryption, protection against unreasonable searches, etc.)
Most Unix systems now do use TAI as their time base (except with an epoch of 1 JAN 1970) - the correction for leap seconds is done using the timezone files, leap seconds don't modify the clock value.
Any system which does this isn't a Unix® system. The POSIX standard is to use UTC, not TAI. I think you're wrong with regard to what most unixlike operating systems use, too. Do you have any cite to back up your claim?
For myself, I've never had a problem with figuring out what day it was, even though I'm usually up at midnight. Do it like baseball - you call the day based on when it started when referring to "whole days", otherwise just use whatever the current time stamp shows.
So if the date changes at the peak of the sun, and I tell you "let's have lunch Wednesday", what day am I referring to?
While we're at it, let's either change 12:00 to 0:00 or change the date at 1 AM. That's another big source of confusion.
It actually does matter a lot in some applications. Take satellite tracking. A low earth orbit satellite moves about 7 km in one second. If you're off by one second because of confusion about a leap second, you've made a position error of 7 km. That's a lot.
No, I wasn't talking about calculating the current time. I'm talking about calculating the number of seconds between now and some time in the future. That's what you can't do, and I can't think of any reason why you'd ever need to do that.
There are many perfectly valid arguments against leap seconds. The difficulty in calculating the exact number of seconds between two events
That's impossible to do precisely anyway due to relativity, and as the time between the two events increases the precision goes down more and more. But it's not even that difficult to calculate within a system of leap seconds (within the limitations of the relative motions and gravitational effects of the two clocks and/or the distance between the locations of the events), you just need a table of historical leap seconds.
If you want to make things even easier on yourself, then don't record the times of things using UTC if what you care about is measuring the number of seconds between things. UTC isn't about that. It's about making it easy for humans to communicate times which can easily be converted to local times. And local times are, more than anything else, about measuring positions within a day.
the fact that calculations involving future times can give different results after leap seconds are declared
This is the part that I was talking about previously. I don't see why one would need to calculate the number of seconds until a time in the future (for practical purposes). If it's really necessary, then that time in the future shouldn't (can't, actually) be declared in UTC.
the difficulty of dating events that occur near or during leap seconds
What's difficult about it? I don't understand this point at all. There is a very clear and unambiguous way to date any event, regardless of whether or not it occurs near or during a leap second. "1998-12-31T23:59:59.00Z, 1998-12-31T23:59:60.00Z, 1999-01-01T00:00:00.00Z, 1999-01-01T00:00:01.00Z". You must be talking about UNIX time.
But these are not good arguments for removing leap seconds from UTC! Why do that when you can choose from two perfectly good standard time scales that don't have leap seconds?
I guess we're on the same page here. But I still don't understand the practical benefit of knowing the number of seconds between now and some date/time in the future.
It would have been really nice had the UNIX designers chosen the TAI timescale instead of UTC as the internal representation of time.
UNIX time, as declared by POSIX, is broken in design. They use an integer which is supposed to represent "the number of seconds elapsed since 00:00:00 on January 1, 1970" then they say it's in Coordinated Universal Time. But UTC is not an integer, and it doesn't measure the number of seconds elapsed since midnight 1/1/1970 (at least not under the UTC definition of the second which is equal to the SI definition).
Since converting an integer into a date/time involves some calculation anyway, I agree with you it would have made much more sense to use TAI as the base. See http://cr.yp.to/proto/utctai.html for another argument.
Of course, this system would only be useful for timestamps since about 1955, when we started paying attention to leap seconds in the first place. Before that we can't accurately measure the number of seconds between two events, using the modern definition of the second. Depending how far back you go the systems become more and more convoluted.
I wonder if it's too late to make such a change...
Depends how much control you have over your system, and how much you're willing to break POSIX. For backward compatibility, we would probably need to come up with a new system call, though maybe a good hybrid solution would be to use UT1 internally. At least then the clock slews are spread out.
over the past 30 years (coincidentally since the inception of leap seconds) the rotation of the earth's crust has accelerated.
Relative to what? Couldn't we equally say that over the past 30 years our clocks have been slowing down?
TAI (atomic time) is a "digital" represenation of time: e.g. a second is a known quantity, and we count one after the other forever and ever.
Even that's not really true, though. A second in one part of the earth is not exactly the same as a second on another part of the earth, due to the relative velocity and gravitational differences.
Because UNIX time_t is based on UTC, coversions have to be done to consult tables of leap seconds, and, what's worse, time_t can produce ambiguous results when referring to events occuring during a leap second.
Well, the way UNIX time is stored according to POSIX, no tables are needed to convert UNIX time to UTC, but you do get the abiguous results. If you're going to store time as a single number, you have to have one or the other.
If we are going to be talking about time kept by computers, lets do it in a way that's convenient to the computers (e.g. TAI).
Considering that we're only talking about something like one second per year, I agree here. We don't need leap seconds. If the position of the sun shifts by one hour over the course of 500 years people will be able to handle it.
I don't see the point of the leap second, but by the same token, I don't see how it's so harmful either. All that really matters is that we have a precise definition so that people can communicate properly, and then it's up to the programmers to be careful. This means not using localtime() for scheduling cron jobs or other things which need a number which is non-ambiguous, nor using it for measuring the time between two events when that needs to be accurate to the second. At least not on a POSIX-compliant computer.
With our current system of leap seconds, does the Unix timestamp actually reflect the CORRECT number of seconds since Jan 1st, 1970?
The other answers to this were somewhat confusing, so I'll give one too: No, unix timestamps don't reflect the number of seconds since 1/1/1970, at least not if they follow the POSIX standards. Unix timestamps reflect the UTC time. Here's another link.
It doesn't need to be nearly as complicated as you make it out to be, and computers have to deal with date changes in the middle of a day all the time.
Computers have no problem with this, but humans would. The fact that the day would change while most people were wide awake and working would be very confusing. Universal time is fine for computers, and many computers are set to UTC. They really should be set to TAI, which is what you suggest (UTC without the leap seconds). But for humans, it makes more sense to make a day rougly equivalent to the time you wake up and go to sleep. In fact, if you're going to change things, it'd probably be better if we just did away with noon being the high point of the sun, and instead set midnight to somewhere around the middle of the time when people are asleep. It's those couple hours discrepancy which cause the most confusion already anyway ("I'll meet you tonight at 1AM" when you technically mean tomorrow morning).
And are the library functions able to account for future leap seconds that haven't even been scheduled yet? Clearly they can not be, which means the addition of leap seconds will cause values returned by those functions today to differ with the values returned in the future.
And this matters because????
My point is still valid: if interest rates go up, house prices stay flat, or wages stay flat, a lot of people will lose their houses.
If that's your only point, then I agree with it fully. A lot of people will lose their houses.
Ah right, sys_ulib(). A good example of linux moving in the wrong direction. This shouldn't be something handled by the kernel in the first place.
I think you are wrong on this one, and the prove is Linux, you see, on Linux, it IS difficult to spread a virus because of the system DESIGN for security. Maybe it is kind of cumbersome for the user to have to introduce the root password when installing a RPM but, at the end, you have 99% less viruses spreading.
I'm not sure how you define "virus", but by my view of what a virus is you don't have to be root to have or spread a virus.
The only real advantage of linux in this space is if you have a multi-user system. Then, at least in theory, you can't spread a virus from one user to another. But for a single user desktop machine this is pretty much meaningless, and in practice it's relatively meaningless anyway due to the possibility of using a root exploit.
I guess here I'm lumping all Linux systems together, and maybe that's not fair. After all, there are some build-it-yourself Linux systems out there that utilize different users for every single software package, and on those systems it's much more difficult to spread a virus. But this idea hasn't really caught on with any of the mainstream distros I know of.
Most privilege escalation vulnerabilities are in the kernel or in applications that run as root.
Aren't all privilege escalation vulnerabilities are in the kernel or in applications that run as root? If an application which doesn't run as root can allow someone to gain root, then there must be a bug in the kernel.
There was a recent one in the Linux kernel involving an old shared library loading system call.
I'm not sure what that has to do with the kernel. Aren't shared libraries handled by ld.so? Which system call are you referring to?
So, essentially, what you're saying is that a program shouldn't be allowed to modify the operating system while it's running, because that might crash the operating system. I don't see the point.
Drivers crashing the OS is afaik unavoidable.
A program running with administrator privileges can install a driver.
Now granted, with most OSes, including unix ones, it's much easier than that. For instance, if you screw with the inodes of a running system, you can crash HP/UX (at least you could when I worked for HP). I wouldn't necessarily call that a design flaw, though. In fact, it could very well be considered a security feature. If something that fundamental is screwed up, either you've got buggy hardware, a buggy OS, or you're under attack. In any of those three cases I'd say it's safer from a security standpoint to panic than to try to repair yourself.
Some people of course have different needs. Some systems can't afford to reboot, they're that mission critical. But for most operating systems it's better to blue screen or to panic or whatever it's called. Reliability can be handled by having multiple systems running.
Probably. But maybe he's running a system with a microkernel, which doesn't need to be rebooted to patch a root exploit.
Hell, maybe he installed a minimal version of Linux a year ago, and is using kernel modules for all the advanced functionality. There probably aren't any root exploits in that (what root exploits are there in the kernel, and not the apps, anyway?)
If an OS can crash because of software then it has a basic design flaw.
Not if that software is running as the administrator.
If an OS can get a virus then it has a basic design flaw.
I don't understand that one. How could an OS possibly protect against all viruses? It'd have to be impossible to modify executables.
Pretty much. Windows gets slow every once in a while, forcing me to reboot it, but I don't think I've ever had this system shut down on its own.
Airwaves aren't like food or books. But I agree with you that the best solution would be to eliminate the government intervention beyond defining and enforcing property rights.
Actually treating the airwaves as property is a big mistake. The current division of the spectrum is an artifact of nearly 100 year old technology.
Just because something is treated as property doesn't mean you have to split it up the way it's currently split up.
With UWB transmissions, the airwaves could be used like a huge Ethernet network that everyone can utilize at the same time.
UWB transmissions work fine with a small number of point to point transmissions over a small area, something like a wifi connection. But something like the radio or television spectrum, where it is one person broadcasting high bandwidth content to a lot of people over a wide area, those people having very cheap receivers, treating it like an ethernet network would cause far too many collissions. Think about what would happen if 20 people tried to broadcast 10 mbps streams over 100 gig ethernet (with a hub, not a switch). Think about what would happen if you used the ethernet protocol over a wide-area network. Either of these problems alone are enough to force you to use a different protocol.
As the technology improves and the costs come down, maybe we can move to a system of point to point links, and bandwidth will be essentially unlimited. One news station (I think it was CNN) has built a system to track a satellite in a moving car. They use it in Iraq. With a system like that, for instance, anyone with a satellite in the sky could share the same airwaves. Make it terrestial based somehow (it'd be hard due signals bouncing all over the place), and you wouldn't even need the satellite. But the time when every Joe can afford one of these in his car is a long way off, and it'll probably always be more costly than normal old broadcasting.
The airwaves need to be regulated, and only the power of the state can back such regulation. People have to agree only to use certain frequencies within certain ranges for radio to be effective and useful for the most people. Do you have a better solution?
I wouldn't call it regulation to enforce property rights. Regulation implies the government is telling you what to do with your property, not that they are enforcing a property owner's right to do what they want with it.
Is this the first step toward getting our airwaves back or is this just a slap on the wrist?
We'll get our airwaves back as soon as the government stops telling us what to do with it, and not a moment before. I don't see it happening any time soon. There's far too much corporate interest in keeping these government handouts.
There is the really lame argument that the airwaves are a public trust, but that just means the government was dumb enough not to auction them to the highest bidder.
Exactly. That's the first step toward getting our airwaves back. Get rid of the government interference, and treat it like any other real property. Auction it off, let people use it for whatever they want (hint, it probably won't be free any more), and collect a property tax once a year based on the value of the portion of the spectrum.
Sure, you can reserve one or two stations for public interest, which must be run by non-profit charities, but the rest of it is so commercialized nowadays that we shouldn't bother pretending it's in the public interest.
Ultimately, there's no problem if you have a free market on the airwaves.
But there isn't a free market on the AM/FM radio airwaves. Not even close. This part of the radio spectrum is given to the radio stations essentially for free, in return for acting in the public interest in certain ways (not encrypting, not being obscene, broadcasting public safety announcements, not accepting payola, etc).
If the airwaves really were free, if they were auctioned off to the highest bidder who could then use them for any reason, similar to the satellite and cell phone frequencies, this wouldn't be a problem. But that's not how the AM/FM radio airwaves work, and that, to answer the original question, is why this should be illegal.
I believe US law treats companies as legal personae, granting them similiar rights to people.
That would be a gross oversimplification of the matter. Only people have rights, but people have those rights while acting through a corporation, just like they do while acting as individuals.