Java is well specified, and is open enough for me. It can be implemented in open source. It is nowhere near a "proprietary environment", in the sense that Windows is. I have just as much ability to influence Sun's direction on Java as I do with W3C on Web standards, that is to say, little to none unless I'm willing to spend an inordinate amount of time at it.
In other words, Java is a poor solution because Microsoft doesn't support it properly.
I guess if we could get rid of those pesky Firefox, Safari and Opera users, we'd REALLY have a good cross-platform solution (those Linux users don't count, of course). It's funny, though - I never have any problems running Java applets in Safari. How is that everyone who uses Java is targeting Safari's version of Java, if they're all so different? Certainly, it isn't that they're targeting Safari as a Web browser, there are plenty of sites that don't work properly (although, to American Airline's credit, they do suggest using Firefox as a solution).
When IE7 comes out, you have to wonder if all sorts of AJAX applications are going to suddenly break, or if new ones won't work with IE6 (so you'll be forced to upgrade to Vista).
How is IMAP slow? I've always found IMAP to be almost instantaneous. IMAP even supports server-side searching. Perhaps you're connecting to a really slow server, or are using a lousy client, or have it configured to download new messages immediately.
Server machines are no faster than fast desktop machines. They have a lot of storage, and a lot of memory, but also have to support a lot of users. If they're faster at searching, it's because they're using better programs.
AJAX require makiing sure that the runtime is installed, that the server is configured to support it, etc.
You can do the server side any way you want. I don't understand the comment about the client machine, though. How is that different from being able to run a JVM that can do the same thing? And how is development time "nil"? How is implementation and deployment any more difficult with Java than with this?
"This site only supports Internet Explorer version 6 or higher" - how is that any different from the JVM situation? What's going to happen when IE7 comes out? If you make the browser environment totally static, then you can target it, but as soon as you try to advance it at all, you're going to start having incompatibilities. I just had to subject myself to using IE in order to book a flight at American Airlines web site. They confirm that their site has a problem in some cases with Safari.
Then, of course, the next great development after AJAX will be the re-discovery of ActiveX, and we'll be back to only supporting one platform all over again.
I just don't understand why incompatible JVM implementations are any different from incompatible browsers and incompatible implementations of Javascript.
The ONLY advantage that something like AJAX has is that most people now have browsers that can support it. Other than that, it is an extremely poor "cross platform" virtual windowing/execution environment - it substitutes one type of incompatible platform (CPU, OS) for another (Web browser). Sure, supposedly Web browsers are supposed to all be conforming to a standard that can be used, but we all know they aren't.
Web development, especially when doing something like this, is no less expensive, and can easily be much more expensive, than creating a classical application. If you want cross platform, it would make much more sense to do such development to another platform which most people have, which is Java. Web browser or JVM, in either case you need to do an installation of the platform once (or it can be pre-loaded on your machine, of course). Different JVMs should be more compatible than different Web browsers currently are. People who complained that Java was too slow should be absolutely aghast at the speed of AJAX.
With something like Java Web Start, all of the convenience of just going to a Web page to start your application is there, along with the ability to cache and update applications. You can certainly do anything in Java that you could do in a Web browser, and you can do it a lot faster.
I thought smoke and soot had lots and lots of nanotubes and buckyballs in it already. The quantities being used for electronics are extremely small, and they aren't floating around in the air.
They're not saying it IS interfering with anything, they're saying they're afraid that the security systems are such crap that they MIGHT be interfered with, but that somehow the commercial operator's equipment (and, incidentally, the equipment in all the laptops that are used by their customers) doesn't interfere with it. If they can show that somehow the equipment Continental is using is actually interfering with licensed equipment, then they have a valid case.
Of course, this isn't about technology, it isn't about specs, it isn't about interference, it is about the perceived absolute right of an airport authority to control anything and everything on the premises, and charge as much as they can for anything they can get away with. I bet there must be some law somewhere that prevents them from putting nickel coin slots on the water fountains, or they'd be doing it. I'm surprised they don't put vile smells into the air and then charge an hourly fee on gas masks.
You do realize that this was some independent analyst suggesting this is what Sony MIGHT do, not a press release from Sony saying what they plan to do.
I said you don't need to agree to the GPL in order to get a copy of GPL software and use it. I never said you could then go ahead and modify it and distribute it without agreeing to the GPL. Distributing GPL software without agreeing to the license is a copyright violation, not a "license violation". It can't be a license violation if you never agreed to the license. The copyright holder (which is not necessarily the FSF) won't be suing you because you violated the terms of the license. They'll probably give you the OPTION of agreeing to abide by the license in exchange for dropping the copyright infringement lawsuit, however.
Copyright law doesn't say anything about a publisher restricting how the work may be "handled". Copyright law gives certain very specific exclusive rights to the copyright holder. The copyright holder can give permission to others to exercise those rights, and (under normal contract law) require consideration in exchange for those (limited) rights. The only things the GPL allows you to do were already exclusive rights of the copyright holder - the copyright holder had the exclusive right to distribute source code and derivative works, and grants you SOME of those exclusive rights (the right to distribute the source code as long as you do so under specific terms, and the right to distribute derivative non-source works (i.e. binaries) as long as you do so under certain other specific terms). If you reject the GPL, you in no way lose any rights that you would have had anyway, including the right to run the program.
Reasonable copyright and patent terms are a bargain with society. The problem is that the bargain has become too one-sided. When that happens, respect for the bargain degrades. Since that bargain includes a restriction on what would happen naturally (the ability to copy something), trying to restrict it when there is no respect for it is going to be problematic (as we've seen).
With regard to your feeling of "burns me up like nothing else" - take it in a different context (which is not to say that in the current context, there's anything wrong with it, just that it isn't universally "natural"). A world of plenty (say, robots or nanotechnology produces everything we need to survive in comfort). Everyone else releases all of their creativity with no expectation of explicit return. You've used plenty of their creativity, some of your work is certainly based on some of it. You still put in just as much effort. Do you still feel really burned that once you release something, anyone is free to do with it what they will?
At least with air, something is actually being consumed, even if in the context of the Earth it is a practically unlimited resource (as far as breathing is concerned, that is - the "right" to pollute the air is one that is currently bought and sold by companies). A better example would be the right to view a sunset. My viewing of a sunset doesn't affect anyone else in any way. Even if I close my eyes, those light rays weren't going somewhere else. A law granting exclusive rights to "The Sunset Company" wouldn't make viewing a sunset "theft", even though viewing it without permission means they're being "robbed of their profits".
What fine print? I own an "authorized copy" of the software. True, I don't "own the software" in the sense that Apple does - they have the copyright, not me. A publisher can't sell me a book and claim that I only own the paper and ink, but somehow they retain all other rights to the words on the page, and I can't read it unless I agree to do so wearing rose-colored glasses. Selling me "the media that it is stored on" IS selling me a copy. I own that copy. I can use it. I don't need any further permission to do so.
Do what a lawyer suggested when opening a package that says "opening this package signifies that you agree with the following terms": cross out each line, initial each crossing out, then open it.
For installer click agreements, fire up a debugger and modify the text of the agreement before you click I Agree (because white-out on the screen is so annoying). Or click on I Disagree, then go and do anything that copyright lets you do, such as modify your copy to make it run even if you click on I Disagree (or even just change the text of the I Agree button to I Disagree). Clicking on I Disagree shouldn't be able to take away any rights you already had, which included the right to the product you bought. The advertisement said it did this and that and the other, so if it doesn't, aren't they guilty of false advertisement?
You're right that the GPL relies on copyright, and that if copyright on software were abolished then companies could use GPL source code in their products and not be required to release their modifications. That doesn't mean they can't release the source. The BSD model still works (and would continue essentially unchanged with no copyright).
However, copyright does exist, and you don't need to agree to the GPL in order to get a copy of GPL software and use it. The GPL simply doesn't apply to you. Don't know about it? Fine! But then, you don't know that you are allowed to copy it, modify it and distribute it, so you are bound by simple copyright law (which is not a license, it's a law, so you don't have the choice of accepting it). So by not accepting the GPL, you're not allowed to do any of the things it lets you do that are otherwise prohibited by copyright law. Accepting it doesn't prevent you from doing anything you couldn't do already, and that's an important point. The GPL is offering consideration for consideration (some rights to their copyrighted work in exchange for some rights in your copyrighted work), and you can turn it down freely without losing something you already have.
No, it's sold. I bought a copy. It came in a box. I OWN that copy. It's an "authorized copy" under copyright law. I can use that copy in any way that doesn't violate the listed rights of a copyright holder, which includes running it on a computer. I don't need further permission from anyone to use it. If I want to "read it", run it through a disassembler, I can do that as well. I can't send copies of that disassembled version around to other people, of course, but I can tell them what I found out (just as I can tell you who dies in Harry Potter without violating copyright). I can modify the software in order to get it to work.
If I modify my copy of OSX to change the terms it presents in the installer, to remove anything I find objectionable, then click on I Agree to the modified terms, how do you think that would stand up in court? What if I add some terms such as "You have the right to make copies of this software and sell them"? What if, instead, I give the machine a counteroffer: "If you agree that these terms are ridiculous and they should all be null and void, continue to leave the "I Agree" button where it is and I'll click it, OK?"
Regarding your last point, there is no 12:00 AM or 12:00 PM. It is correctly referred to as "noon" or "midnight". That doesn't solve the ambiguity of whether a day specified with "midnight" means the beginning or end of that day.
From the BSD man page for time2posix (3):
IEEE Std 1003.1-1988 (``POSIX.1'') legislates that a time_t value of
536457599 shall correspond to "Wed Dec 31 23:59:59 GMT 1986." This
effectively implies that POSIX time_t's cannot include leap seconds and,
therefore, that the system time must be adjusted as each leap occurs.
If the time package is configured with leap-second support enabled, how-
ever, no such adjustment is needed and time_t values continue to increase
over leap events (as a true `seconds since...' value). This means that
these values will differ from those required by POSIX by the net number
of leap seconds inserted since the Epoch.
Typically this is not a problem as the type time_t is intended to be
(mostly) opaque--time_t values should only be obtained-from and passed-to
functions such as time(3), localtime(3), mktime(3) and difftime(3). How-
ever, IEEE Std 1003.1-1988 (``POSIX.1'') gives an arithmetic expression
for directly computing a time_t value from a given date/time, and the
same relationship is assumed by some (usually older) applications. Any
programs creating/dissecting time_t's using such a relationship will typ-
ically not handle intervals over leap seconds correctly.
The time2posix() and posix2time() functions are provided to address this
time_t mismatch by converting between local time_t values and their POSIX
equivalents. This is done by accounting for the number of time-base
changes that would have taken place on a POSIX system as leap seconds
were inserted or deleted. These converted values can then be used in
lieu of correcting the older applications, or when communicating with
POSIX-compliant systems.
I think this is from the same package that is used for the timezone package usually installed on Linux systems.
So you're right that doing it that way makes it non-POSIX-compliant, but except for programs that divide the value returned by time() by 86400 to determine the number of days and time of day instead of calling the library routines, it appears that it shouldn't be a big deal to do it that way.
I don't have the sources to the timezone files, and it looks like the Mac zone files don't have leap second support in them, so I can't really easily play around with this at the moment (it's a pain that the GNU date command doesn't have a simple way to enter a time value and convert it to a date string - BSD date command has a -r option, but for GNU that means to use the date of a file).
The person I was referring to was not you, but the person who started the discussion about 28-day months because they would then follow the lunar cycle, which is just plain wrong since the lunar cycle isn't 28 days.
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.
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 what if "Saturday night" is technically Sunday morning?
That's absolutely not true. There were plenty of "Y2K problems". Most of them weren't serious, a few were. Most of them could be found and fixed. The ones that couldn't (or weren't) were usually not very serious, and in most cases were trivial.
However, the effort to figure out what all those systems out there would do was not trivial. The effort to convert records in systems that WOULD break was not trivial. It cost real money. And it was all caused by shortsighted people who said "the only software (and that's what the change is about) that will be disrupted by the change will be software that has to be working 20-30 years from now. A lot of programs could safely ignore Y2K". Nobody started doing much about it until 5 years before, and there are still programs and systems that won't handle 2100 correctly, not to mention new programs being written now that completely ignore such issues.
Handling leap seconds is no more difficult than handling DST, leap years, or century changes. Why the hell can't people just do it right? Papering it over by pushing it off 500 years, in a way that is guaranteed to cause problems then, is no solution. That it will also cause problems in just a few years makes it even worse. Just fix the damned systems that were programmed by idiots and stop messing with something that already works just fine.
But as he said, that breaks anything that IS trying to track UT1 by looking at the offset between UTC and UT1. That difference is DEFINED as being less than 1 second, so around 2009, that equipment would no longer work correctly.
Pushing this off on the future, when exactly should they start making watches and programs that will take into account the mythical leap-hour? Everyone will always say "oh, I'm sure this program won't still be running then" or "I'm sure this watch (clock/safe timer) will be obsolete by then", right up to the time they start saying "Boy howdy, there sure is a lot of stuff that's going to break in 5 years".
Actually, when leap seconds are inserted, the time isn't "exactly correct" at that precise instant. Astronomers use the current (day-to-day) offset when they need sub-second accuracy. By using leap seconds, that correction is kept between -1 and +1. Remember, you can sometimes have a negative leap second (the last minute of the day only runs 59 seconds long), although I'm not aware of any having been used since leap seconds were instituted. There's no reason to do it more fine-grained than 1 second, and keeping it to 1 second minimizes the weirdness when it does happen, and keeps it from happening more than once a year. Changing it to 1 minute or 1 hour has exactly the same problems, except the magnitude of the error is much larger. Since leap seconds don't cause problems for properly programmed systems, you're mostly trying to make it imperceptible to people. Having a 61-second minute is much less noticeable than a 61-second minute or 61-minute hour or 25-hour day.
We already have a perfectly adequate mechanism to do the adjustment. GPS, NTP, the standard C library date routines (timezone files, zic), WWV/WWVB all include leap second information, you get a month's advance notice automatically from whatever source you're getting accurate time measurements from (if you're not getting a time feed, then why do you care if there are leap seconds anyway? You'll never see them!). Using the routines is straightforward, there's even a flag when you get the time that says "this second right now we're in the middle of a leap second". Just idiot programmers didn't read the man pages, that's the only problem. I'd worry about their programs crashing on Feb 29 and being wrong starting March 1, 2100, or doing stupid things twice a year when switching to and from DST. Even if they handle DST correctly, let's see them do the right thing in 2007 when the effective date for DST switches. Correctly programmed systems will have no problem with it, and correctly programmed systems have no problem with leap seconds. Eliminating leap seconds won't require any programming changes (the mechanism will still be active, but they'll simply stop inserting them), but astronomical programs that assume the current correction is between -1 and +1 will have problems, GPS units that look at the current leap-second count to heuristically determine which 1024-week period it currently is will have a problem, and 300 years from now, sundials will be off by half an hour. 495 years from now, people will start worrying about all the programs that don't take into account a leap hour, since the mechanism for doing so is still being hammered out in the standards committees. Eventually, it will be decided to just switch all the timezones by one hour instead, by having the next switch to DST be a 2-hour jump. The horrible bugs that such a change will introduce will cripple the economy for 3 months, and the additional bugs that show up when standard time resumes will be just as bad. Everyone will curse the morons who pushed the problem off for 500 years because some idiots couldn't get leap seconds right.
How about this instead: systems that need to be in synch with the rest of the world (so that the date changes right at midnight-with-leap-seconds-included), but are written too stupidly to handle leap seconds correctly, have modified hardware that picks up the time feed (if they don't have a time feed, then how are they picking up leap seconds and staying in synch with the rest of the world?) that doesn't feed them a leap second, but instead adjusts the second that day by making the second run 1/86400 fast or slow. Any such system MUST have a mechanism to adjust the accuracy and/or slew an internal clock, or it already suffers from time discontinuity when it gets off, or it is reading the time directly from the hardware, so it shouldn't be a problem. Such a system will be off by less than a second from the rest of the world all day. Alternatively, just use something like the Unix "slew clock" system request to adjust the clock b
It's even worse than that, since the phase of the Moon during each of those 13 28-day months would go all the way around, there'd be no relation between month and lunar cycle. The lunar cycle is slightly more than 29.5 days, NOT 28 days. There are about 12.37 lunar cycles (synodic months) per year. Adding the extra 1-2 days is just correcting for 28 days going into 365.25 days, while the idea being expressed was to do a lunar month. A lunar month has nothing to do with 28-day months, if you define the month with regard to the Moon's position relative to the Sun and the Earth (i.e. the time between "New Moon").
By the time XBox360 comes out, HD-DVD players and titles should be on the shelves. XBox360 having HD-DVD capability wouldn't be compelling, but could well be enough of a bonus to increase sales, especially by people who don't want to invest in a new DVD player for an untried format. Having it be an "extra" would be a bonus both for the XBox360 and the HD-DVD format.
Instead, the lack of that, combined with uncertainty over a future version which might have something else, plus the PS3 coming out 6 months later with a competing format, will decrease sales. If HD-DVD didn't exist at all, only Blu-Ray, then XBox360 having only DVD capability wouldn't be as much of a big deal. But for the early adopters who are going to drive initial sales, it will be a factor. If that's enough to make initial sales be lower than expected, it will drive a self-reinforcing perception of failure for XBox360, which will help the PS3 when it releases, which will drive a self-reinforcing perception of success for PS3, which will help Blu-Ray, which could well kill HD-DVD.
Well, my guess is that Blu-Ray is going to be the "winner", or that some compromise will be made and all players will support both BR and HD-DVD. In either case, I'm not willing to bet with my dollars, so the PS3 having Blu-Ray from the start is going to mean I can experiment with BR titles without having to buy a new separate player. For HD-DVD, I'm just going to wait. I wasn't going to get an XBox360 anyway, since I have a bunch of PS2 games I'll still want to play, but not having at least one of the new formats certainly makes it even less attractive to buy it out of the starting gate.
Where this could really hurt Microsoft is if initial sales are really soft because of it, that fact alone could hurt future sales more than having simply been late to market. If the HD-DVD version takes 3 or 4 months to come out, putting it close to the PS3 release, I can then see lots of people holding off just a few months to see how that turns out. PS3 demand is likely to be through the roof, and the perception that it is more popular than XBox360 at launch could help keep it there. That in turn could lead to a perception that Blu-Ray is also a more desirable format than HD-DVD, which further decreases demand for the updated XBox360 version.
The only thing that might prevent such a situation is if the initial release includes a coupon for a free (or incredibly cheap - $20 or less) upgrade - either user-installable (not a problem, as most early adopters will be capable of doing it), or including labor. Anything less than that will probably cause a significant number of people to hold off, if only to see how PS3 turns out and how Blu-Ray fares against HD-DVD after that release.
My prediction: PS3 is going to blow away Xbox360, and that will directly solve the chicken-and-egg problem and lead to Blu-Ray becoming an accepted format, which will in turn lead to HD-DVD quickly falling out of favor (unless they immediately decide to license it so cheaply that players that support both Blu-Ray and HD-DVD can be sold for less than $200 by the end of 2006, in which case it may be able to hang on - but all those PS3 consoles that can't do HD-DVD will inhibit that).
All should be fairly clear within a month of the XBox360 release, and crystal clear a week after the PS3 release. I'll crow, or eat crow, then.
Slashdot Mirror
Java is well specified, and is open enough for me. It can be implemented in open source. It is nowhere near a "proprietary environment", in the sense that Windows is. I have just as much ability to influence Sun's direction on Java as I do with W3C on Web standards, that is to say, little to none unless I'm willing to spend an inordinate amount of time at it.
How is maintenance different when the client-side Java byte code can be updated automatically from the network whenever it is out of date?
In other words, Java is a poor solution because Microsoft doesn't support it properly.
I guess if we could get rid of those pesky Firefox, Safari and Opera users, we'd REALLY have a good cross-platform solution (those Linux users don't count, of course). It's funny, though - I never have any problems running Java applets in Safari. How is that everyone who uses Java is targeting Safari's version of Java, if they're all so different? Certainly, it isn't that they're targeting Safari as a Web browser, there are plenty of sites that don't work properly (although, to American Airline's credit, they do suggest using Firefox as a solution).
When IE7 comes out, you have to wonder if all sorts of AJAX applications are going to suddenly break, or if new ones won't work with IE6 (so you'll be forced to upgrade to Vista).
How is IMAP slow? I've always found IMAP to be almost instantaneous. IMAP even supports server-side searching. Perhaps you're connecting to a really slow server, or are using a lousy client, or have it configured to download new messages immediately.
Server machines are no faster than fast desktop machines. They have a lot of storage, and a lot of memory, but also have to support a lot of users. If they're faster at searching, it's because they're using better programs.
AJAX require makiing sure that the runtime is installed, that the server is configured to support it, etc.
You can do the server side any way you want. I don't understand the comment about the client machine, though. How is that different from being able to run a JVM that can do the same thing? And how is development time "nil"? How is implementation and deployment any more difficult with Java than with this?
"This site only supports Internet Explorer version 6 or higher" - how is that any different from the JVM situation? What's going to happen when IE7 comes out? If you make the browser environment totally static, then you can target it, but as soon as you try to advance it at all, you're going to start having incompatibilities. I just had to subject myself to using IE in order to book a flight at American Airlines web site. They confirm that their site has a problem in some cases with Safari.
Then, of course, the next great development after AJAX will be the re-discovery of ActiveX, and we'll be back to only supporting one platform all over again.
I just don't understand why incompatible JVM implementations are any different from incompatible browsers and incompatible implementations of Javascript.
The ONLY advantage that something like AJAX has is that most people now have browsers that can support it. Other than that, it is an extremely poor "cross platform" virtual windowing/execution environment - it substitutes one type of incompatible platform (CPU, OS) for another (Web browser). Sure, supposedly Web browsers are supposed to all be conforming to a standard that can be used, but we all know they aren't.
Web development, especially when doing something like this, is no less expensive, and can easily be much more expensive, than creating a classical application. If you want cross platform, it would make much more sense to do such development to another platform which most people have, which is Java. Web browser or JVM, in either case you need to do an installation of the platform once (or it can be pre-loaded on your machine, of course). Different JVMs should be more compatible than different Web browsers currently are. People who complained that Java was too slow should be absolutely aghast at the speed of AJAX.
With something like Java Web Start, all of the convenience of just going to a Web page to start your application is there, along with the ability to cache and update applications. You can certainly do anything in Java that you could do in a Web browser, and you can do it a lot faster.
I thought smoke and soot had lots and lots of nanotubes and buckyballs in it already. The quantities being used for electronics are extremely small, and they aren't floating around in the air.
They're not saying it IS interfering with anything, they're saying they're afraid that the security systems are such crap that they MIGHT be interfered with, but that somehow the commercial operator's equipment (and, incidentally, the equipment in all the laptops that are used by their customers) doesn't interfere with it. If they can show that somehow the equipment Continental is using is actually interfering with licensed equipment, then they have a valid case.
Of course, this isn't about technology, it isn't about specs, it isn't about interference, it is about the perceived absolute right of an airport authority to control anything and everything on the premises, and charge as much as they can for anything they can get away with. I bet there must be some law somewhere that prevents them from putting nickel coin slots on the water fountains, or they'd be doing it. I'm surprised they don't put vile smells into the air and then charge an hourly fee on gas masks.
You do realize that this was some independent analyst suggesting this is what Sony MIGHT do, not a press release from Sony saying what they plan to do.
I said you don't need to agree to the GPL in order to get a copy of GPL software and use it. I never said you could then go ahead and modify it and distribute it without agreeing to the GPL. Distributing GPL software without agreeing to the license is a copyright violation, not a "license violation". It can't be a license violation if you never agreed to the license. The copyright holder (which is not necessarily the FSF) won't be suing you because you violated the terms of the license. They'll probably give you the OPTION of agreeing to abide by the license in exchange for dropping the copyright infringement lawsuit, however.
Copyright law doesn't say anything about a publisher restricting how the work may be "handled". Copyright law gives certain very specific exclusive rights to the copyright holder. The copyright holder can give permission to others to exercise those rights, and (under normal contract law) require consideration in exchange for those (limited) rights. The only things the GPL allows you to do were already exclusive rights of the copyright holder - the copyright holder had the exclusive right to distribute source code and derivative works, and grants you SOME of those exclusive rights (the right to distribute the source code as long as you do so under specific terms, and the right to distribute derivative non-source works (i.e. binaries) as long as you do so under certain other specific terms). If you reject the GPL, you in no way lose any rights that you would have had anyway, including the right to run the program.
Reasonable copyright and patent terms are a bargain with society. The problem is that the bargain has become too one-sided. When that happens, respect for the bargain degrades. Since that bargain includes a restriction on what would happen naturally (the ability to copy something), trying to restrict it when there is no respect for it is going to be problematic (as we've seen).
With regard to your feeling of "burns me up like nothing else" - take it in a different context (which is not to say that in the current context, there's anything wrong with it, just that it isn't universally "natural"). A world of plenty (say, robots or nanotechnology produces everything we need to survive in comfort). Everyone else releases all of their creativity with no expectation of explicit return. You've used plenty of their creativity, some of your work is certainly based on some of it. You still put in just as much effort. Do you still feel really burned that once you release something, anyone is free to do with it what they will?
At least with air, something is actually being consumed, even if in the context of the Earth it is a practically unlimited resource (as far as breathing is concerned, that is - the "right" to pollute the air is one that is currently bought and sold by companies). A better example would be the right to view a sunset. My viewing of a sunset doesn't affect anyone else in any way. Even if I close my eyes, those light rays weren't going somewhere else. A law granting exclusive rights to "The Sunset Company" wouldn't make viewing a sunset "theft", even though viewing it without permission means they're being "robbed of their profits".
What fine print? I own an "authorized copy" of the software. True, I don't "own the software" in the sense that Apple does - they have the copyright, not me. A publisher can't sell me a book and claim that I only own the paper and ink, but somehow they retain all other rights to the words on the page, and I can't read it unless I agree to do so wearing rose-colored glasses. Selling me "the media that it is stored on" IS selling me a copy. I own that copy. I can use it. I don't need any further permission to do so.
Do what a lawyer suggested when opening a package that says "opening this package signifies that you agree with the following terms": cross out each line, initial each crossing out, then open it.
For installer click agreements, fire up a debugger and modify the text of the agreement before you click I Agree (because white-out on the screen is so annoying). Or click on I Disagree, then go and do anything that copyright lets you do, such as modify your copy to make it run even if you click on I Disagree (or even just change the text of the I Agree button to I Disagree). Clicking on I Disagree shouldn't be able to take away any rights you already had, which included the right to the product you bought. The advertisement said it did this and that and the other, so if it doesn't, aren't they guilty of false advertisement?
You're right that the GPL relies on copyright, and that if copyright on software were abolished then companies could use GPL source code in their products and not be required to release their modifications. That doesn't mean they can't release the source. The BSD model still works (and would continue essentially unchanged with no copyright).
However, copyright does exist, and you don't need to agree to the GPL in order to get a copy of GPL software and use it. The GPL simply doesn't apply to you. Don't know about it? Fine! But then, you don't know that you are allowed to copy it, modify it and distribute it, so you are bound by simple copyright law (which is not a license, it's a law, so you don't have the choice of accepting it). So by not accepting the GPL, you're not allowed to do any of the things it lets you do that are otherwise prohibited by copyright law. Accepting it doesn't prevent you from doing anything you couldn't do already, and that's an important point. The GPL is offering consideration for consideration (some rights to their copyrighted work in exchange for some rights in your copyrighted work), and you can turn it down freely without losing something you already have.
No, it's sold. I bought a copy. It came in a box. I OWN that copy. It's an "authorized copy" under copyright law. I can use that copy in any way that doesn't violate the listed rights of a copyright holder, which includes running it on a computer. I don't need further permission from anyone to use it. If I want to "read it", run it through a disassembler, I can do that as well. I can't send copies of that disassembled version around to other people, of course, but I can tell them what I found out (just as I can tell you who dies in Harry Potter without violating copyright). I can modify the software in order to get it to work.
If I modify my copy of OSX to change the terms it presents in the installer, to remove anything I find objectionable, then click on I Agree to the modified terms, how do you think that would stand up in court? What if I add some terms such as "You have the right to make copies of this software and sell them"? What if, instead, I give the machine a counteroffer: "If you agree that these terms are ridiculous and they should all be null and void, continue to leave the "I Agree" button where it is and I'll click it, OK?"
Regarding your last point, there is no 12:00 AM or 12:00 PM. It is correctly referred to as "noon" or "midnight". That doesn't solve the ambiguity of whether a day specified with "midnight" means the beginning or end of that day.
From the BSD man page for time2posix (3):
I think this is from the same package that is used for the timezone package usually installed on Linux systems.So you're right that doing it that way makes it non-POSIX-compliant, but except for programs that divide the value returned by time() by 86400 to determine the number of days and time of day instead of calling the library routines, it appears that it shouldn't be a big deal to do it that way.
I don't have the sources to the timezone files, and it looks like the Mac zone files don't have leap second support in them, so I can't really easily play around with this at the moment (it's a pain that the GNU date command doesn't have a simple way to enter a time value and convert it to a date string - BSD date command has a -r option, but for GNU that means to use the date of a file).
The person I was referring to was not you, but the person who started the discussion about 28-day months because they would then follow the lunar cycle, which is just plain wrong since the lunar cycle isn't 28 days.
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.
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 what if "Saturday night" is technically Sunday morning?
That's absolutely not true. There were plenty of "Y2K problems". Most of them weren't serious, a few were. Most of them could be found and fixed. The ones that couldn't (or weren't) were usually not very serious, and in most cases were trivial.
However, the effort to figure out what all those systems out there would do was not trivial. The effort to convert records in systems that WOULD break was not trivial. It cost real money. And it was all caused by shortsighted people who said "the only software (and that's what the change is about) that will be disrupted by the change will be software that has to be working 20-30 years from now. A lot of programs could safely ignore Y2K". Nobody started doing much about it until 5 years before, and there are still programs and systems that won't handle 2100 correctly, not to mention new programs being written now that completely ignore such issues.
Handling leap seconds is no more difficult than handling DST, leap years, or century changes. Why the hell can't people just do it right? Papering it over by pushing it off 500 years, in a way that is guaranteed to cause problems then, is no solution. That it will also cause problems in just a few years makes it even worse. Just fix the damned systems that were programmed by idiots and stop messing with something that already works just fine.
But as he said, that breaks anything that IS trying to track UT1 by looking at the offset between UTC and UT1. That difference is DEFINED as being less than 1 second, so around 2009, that equipment would no longer work correctly.
Pushing this off on the future, when exactly should they start making watches and programs that will take into account the mythical leap-hour? Everyone will always say "oh, I'm sure this program won't still be running then" or "I'm sure this watch (clock/safe timer) will be obsolete by then", right up to the time they start saying "Boy howdy, there sure is a lot of stuff that's going to break in 5 years".
Actually, when leap seconds are inserted, the time isn't "exactly correct" at that precise instant. Astronomers use the current (day-to-day) offset when they need sub-second accuracy. By using leap seconds, that correction is kept between -1 and +1. Remember, you can sometimes have a negative leap second (the last minute of the day only runs 59 seconds long), although I'm not aware of any having been used since leap seconds were instituted. There's no reason to do it more fine-grained than 1 second, and keeping it to 1 second minimizes the weirdness when it does happen, and keeps it from happening more than once a year. Changing it to 1 minute or 1 hour has exactly the same problems, except the magnitude of the error is much larger. Since leap seconds don't cause problems for properly programmed systems, you're mostly trying to make it imperceptible to people. Having a 61-second minute is much less noticeable than a 61-second minute or 61-minute hour or 25-hour day.
We already have a perfectly adequate mechanism to do the adjustment. GPS, NTP, the standard C library date routines (timezone files, zic), WWV/WWVB all include leap second information, you get a month's advance notice automatically from whatever source you're getting accurate time measurements from (if you're not getting a time feed, then why do you care if there are leap seconds anyway? You'll never see them!). Using the routines is straightforward, there's even a flag when you get the time that says "this second right now we're in the middle of a leap second". Just idiot programmers didn't read the man pages, that's the only problem. I'd worry about their programs crashing on Feb 29 and being wrong starting March 1, 2100, or doing stupid things twice a year when switching to and from DST. Even if they handle DST correctly, let's see them do the right thing in 2007 when the effective date for DST switches. Correctly programmed systems will have no problem with it, and correctly programmed systems have no problem with leap seconds. Eliminating leap seconds won't require any programming changes (the mechanism will still be active, but they'll simply stop inserting them), but astronomical programs that assume the current correction is between -1 and +1 will have problems, GPS units that look at the current leap-second count to heuristically determine which 1024-week period it currently is will have a problem, and 300 years from now, sundials will be off by half an hour. 495 years from now, people will start worrying about all the programs that don't take into account a leap hour, since the mechanism for doing so is still being hammered out in the standards committees. Eventually, it will be decided to just switch all the timezones by one hour instead, by having the next switch to DST be a 2-hour jump. The horrible bugs that such a change will introduce will cripple the economy for 3 months, and the additional bugs that show up when standard time resumes will be just as bad. Everyone will curse the morons who pushed the problem off for 500 years because some idiots couldn't get leap seconds right.
How about this instead: systems that need to be in synch with the rest of the world (so that the date changes right at midnight-with-leap-seconds-included), but are written too stupidly to handle leap seconds correctly, have modified hardware that picks up the time feed (if they don't have a time feed, then how are they picking up leap seconds and staying in synch with the rest of the world?) that doesn't feed them a leap second, but instead adjusts the second that day by making the second run 1/86400 fast or slow. Any such system MUST have a mechanism to adjust the accuracy and/or slew an internal clock, or it already suffers from time discontinuity when it gets off, or it is reading the time directly from the hardware, so it shouldn't be a problem. Such a system will be off by less than a second from the rest of the world all day. Alternatively, just use something like the Unix "slew clock" system request to adjust the clock b
It's even worse than that, since the phase of the Moon during each of those 13 28-day months would go all the way around, there'd be no relation between month and lunar cycle. The lunar cycle is slightly more than 29.5 days, NOT 28 days. There are about 12.37 lunar cycles (synodic months) per year. Adding the extra 1-2 days is just correcting for 28 days going into 365.25 days, while the idea being expressed was to do a lunar month. A lunar month has nothing to do with 28-day months, if you define the month with regard to the Moon's position relative to the Sun and the Earth (i.e. the time between "New Moon").
The GP post has a link to Wikipedia's Calendar entry, but he apparently didn't read it very well, so missed the information about Lunisolar Calendars.
By the time XBox360 comes out, HD-DVD players and titles should be on the shelves. XBox360 having HD-DVD capability wouldn't be compelling, but could well be enough of a bonus to increase sales, especially by people who don't want to invest in a new DVD player for an untried format. Having it be an "extra" would be a bonus both for the XBox360 and the HD-DVD format.
Instead, the lack of that, combined with uncertainty over a future version which might have something else, plus the PS3 coming out 6 months later with a competing format, will decrease sales. If HD-DVD didn't exist at all, only Blu-Ray, then XBox360 having only DVD capability wouldn't be as much of a big deal. But for the early adopters who are going to drive initial sales, it will be a factor. If that's enough to make initial sales be lower than expected, it will drive a self-reinforcing perception of failure for XBox360, which will help the PS3 when it releases, which will drive a self-reinforcing perception of success for PS3, which will help Blu-Ray, which could well kill HD-DVD.
Well, my guess is that Blu-Ray is going to be the "winner", or that some compromise will be made and all players will support both BR and HD-DVD. In either case, I'm not willing to bet with my dollars, so the PS3 having Blu-Ray from the start is going to mean I can experiment with BR titles without having to buy a new separate player. For HD-DVD, I'm just going to wait. I wasn't going to get an XBox360 anyway, since I have a bunch of PS2 games I'll still want to play, but not having at least one of the new formats certainly makes it even less attractive to buy it out of the starting gate.
Where this could really hurt Microsoft is if initial sales are really soft because of it, that fact alone could hurt future sales more than having simply been late to market. If the HD-DVD version takes 3 or 4 months to come out, putting it close to the PS3 release, I can then see lots of people holding off just a few months to see how that turns out. PS3 demand is likely to be through the roof, and the perception that it is more popular than XBox360 at launch could help keep it there. That in turn could lead to a perception that Blu-Ray is also a more desirable format than HD-DVD, which further decreases demand for the updated XBox360 version.
The only thing that might prevent such a situation is if the initial release includes a coupon for a free (or incredibly cheap - $20 or less) upgrade - either user-installable (not a problem, as most early adopters will be capable of doing it), or including labor. Anything less than that will probably cause a significant number of people to hold off, if only to see how PS3 turns out and how Blu-Ray fares against HD-DVD after that release.
My prediction: PS3 is going to blow away Xbox360, and that will directly solve the chicken-and-egg problem and lead to Blu-Ray becoming an accepted format, which will in turn lead to HD-DVD quickly falling out of favor (unless they immediately decide to license it so cheaply that players that support both Blu-Ray and HD-DVD can be sold for less than $200 by the end of 2006, in which case it may be able to hang on - but all those PS3 consoles that can't do HD-DVD will inhibit that).
All should be fairly clear within a month of the XBox360 release, and crystal clear a week after the PS3 release. I'll crow, or eat crow, then.