Well, if your wedding video was produced by a commercial wedding videographer, then yes you might not be able to copy your wedding video. The videographer might well own the copyright on the video and might enable content protection so you cannot make a copy, but instead have to come back to them to purchase each copy. And they would have the legal right to do this unless your contract with them specified otherwise.
Secondly, Nikon's customers don't want new and interesting software for their cameras. They want to depress the shutter and get photos out. They can do that now, admirably, with the software Nikon already provides.
Wow, are you really that ignorant of the marketplace for the camera being discussed here? We're talking about a camera being sold to the very high end -- professionals. People who have a preferred tool chain, who know a lot about the chioces, and who have reasons for working a particular way. An average consumer camera marketed to people who won't use the raw format might work with what you said above. Pros, however, want to do MUCH more than just depress the shutter and get photos out.
Also, you say that they can get photos out "admirably." Have you used this software? According to many pros who do use Nikon Capture, it is much slower than many alternatives.
The market only works for well informed consumers. IN this case the market does not work because consumers are not educated and frankly could not understand what's going on even if you tried to educate them.
Actually, in this case the market is highly educated because this is a camera targeted at pros and rich amateurs. These are people who will use raw format and who do a lot of work in Photoshop or some other toolchain. They will react to any limits placed on their toolchain of choice by Nikon. I expect that Nikon will see a retaliation from their fans. Every Nikon fan I know personally is outraged about Nikon encrypting white balance information.
I have to say that Nikon's response is just as outrageous as their original action. It's the old, "We know better than you do and we are doing this to protect you, the consumer." Yeah, right.
Collusion is illegal when companies are working together to keep another company's product off the market by predatory pricing, for example. But when two companies (or consortiums) work together to choose a common standard, that is just plain good sense. The companies are wisely (I hope) seeing that the market will not welcome competing standards, and that the market (and thus their pocketbooks) are bettered by there being exactly one new DVD standard. There is no illegal activity here because no-one is being prevented from doing anything and they are not controlling prices by choosing to implement a common standard. There is no anti-competitive behavior.
Now, if the companies fixed the pricing of this standard and refused to allow anyone to undercut the pricing and used their size in the marketplace to control the availability and cost of the new DVD players, that could be collusion. If they were somehow working together (like a cartel) to prevent another company from competing in the marketspace, that might be collusion. (Depending on the tactics, etc.) However, just agreeing on a common standard does not collusion make.
Well, I was specifically referring to the activation schemes that more and more Adobe products are getting... activiation as a form of DRM.
You are right. DRM in and of itself is not Instant Evil(tm). It is just the case that almost all implementations of DRM that exist today ARE. I welcome implementations of DRM that protect the author's rights without removing fair use rights.
This is the manufacturer's fault. He provided you with faulty equipment and should repair it at his expense or refund your money.
Not if the warrantee period is up. Want to take bets on how long the warrantee will last for these devices? 90 days maybe? This would only help if the model you purchase has its keys revoked and you notice this within the warrantee period.
I have an iRiver H340 which plays ogg vorbis very well. There are also integer based ogg vorbis methods available. I don't know if the iRiver players use floating or integer codecs for ogg, but I do know that I can listen to my ogg files with no problem.
Go ahead, get rid of copyright law and you'll not just get rid of Brittney Spears, but also probably every band you like.
When it comes to actual CASH that a musical artist sees, most of that cash comes from touring and not from CD sales. If you like David Bowie and someone else is touring playing his music, will you pay the same amount to see the other band that you would pay to see David Bowie? Probably not. Even if others play the same music, only David Bowie plays it like he does, and that is a HUGE part of what people like.
Also, your argument above would make "cover bands" or "tribute bands" illegal. Just two nights ago I was at a place that had a "tribute band" for Pearl Jam. (By coincidence and not because the band was there.) Now, does the existence of this tribute band cause the actual Pearl Jam to have no incentive to write or produce music? If you say "yes" then I don't know what universe you are in.
This "without copyright, no-one would ever produce anything" straw man argument is always trotted out in these debates, and that argument is equally weak every time I hear it.
Having said all of this, I hated every RIAA and MPAA lawsuit until they actually started suing those who were doing the wrong thing -- the people who were uploading music to be shared. I completely support the RIAA and MPAA's ethical right to sue those who upload music illegally to be shared. But I do NOT support lawsuits against toolmakers when those tools have a substantial legal and ethical use. (Such as bittorrent, decss, and others.)
I had a professor for a cosmology class that worked at the Fermi lab and he said that another scientist that used to work their went a bit off the deep end and now protests outside saying that they would eventually make a black hole and it would suck us all in.
I was a grad student at Fermilab on the CDF experiment, and I received a letter from the crackpot you are referring to. He sent the letter to every person on the experiment. He is (or at least was in the 90s) a professor of psychology at U of Hawaii who did a calculation that told him that collisions at Fermilab had a good probability of causing a vacuum transition to a deSitter space. Such a transition, if possible, would indeed destroy the Earth and solar system. Possibly the universe as we know it.
This fellow was not swayed by the fact that the Earth has always been bombarded with cosmic rays of much higher energy than we have the ability to create. I believe I still have that letter somewhere. Hmm. I should try to find it!
Figer estimated the stars' masses by measuring the ages of the cluster and the brightness of the individual stars. He also collaborated with Francisco Najarro of the Instituto de Estructura de la Materia in Madrid, who produced detailed models to confirm the masses, chemical abundances, and ages of the cluster's stars.
[... ]
Astronomers must know the cluster's distance to reliably estimate the brightness of its stars, a key ingredient used to estimate a star's mass. The cluster also must be close enough to see individual stars.
Hey, there is a primary article at Hubble Site
on
Stars Have a Weight Limit
·
· Score: 3, Informative
Hmm, last I checked, gravity discriminates against fat people.
Gravity doesn't discriminate against fat people. It pulls on them too. Just imagine if all you had to do to avoid gravity was gain weight. (Wait a minute...)
Wouldn't any accumulation of mass about that size that's not a star be a black hole?
I think the issue is that if you start with a diffuse cloud whose mass is too great, as the inner part of the cloud collapses and starts to heat up and eventually grow, its radiation pressure on the cloud's dust particles will be greater than the force of gravity on those particles. The outer layers of the cloud will be blown into interstellar space. This causes a limit to the maximum mass of a star.
You could probably create a larger star then the limit spoken of in the article by merging two smaller ones. Thus, if the above process limits the maximum star mass to (say) 140 stellar masses, then once you have formed two stars of that mass, just merge them into one star of much larger mass. However, getting two stars to collide in such a way that they merge takes some doing.
By the way, it is believed that there is an upper mass limit for a newly formed black hole, which is obviously smaller than the maximum mass for a star. With stars larger than a certain size, the stellar core collapses more rapidly than the outer layers and the "explosion" from the stellar core's collapse blows the star's outer layers into space instead of allowing them to collapse as well.
Of course, two black holes can merge, assuming the accretion disks and polar jets don't provide enough pressure to prevent the black holes from approaching closely. The frame dragging that takes place around a black hole may (speculation on my part) make it easier for black holes to merge than for stars of the same size to merge.
Point being, your vested interest in your career of being a programmer is perhaps keeping you from the honesty of the purpose and goal of programming enough to lie to the general public as you and many others in your situation, proprietary and open source have both lied so to protect your trade
WOW. I almost have no words to respond to the arrogant assumptions evident in your post! You are certainly putting a lot of words in the original AC's mouth. Most of my surprise at reading your post involved the array of assumptions you make about the AC. (It was not me, BTW. I don't post as AC.)
You also broadly overstate the ease of programming, the quickness of programming automation, and the ability of the patent office to realize that something is so simple that it does not deserve to be patented. The very existence of the 1-click patent should be enough to show your entire point is moot. The very fact that one can patent a mathematical algorithm -- something originally explicitly prohibited -- even though implmeneting an algorithm in code is usually very straightforward.
How is it that you take one AC's frustration with the patent system as the person in fact being a part of the problem, and a liar and intellectually dishonest to boot? I cannot see how you make that leap without vast assumptions.
If I had mod points (and hadn't already posted here, of course!) I would mod your post up. Looks like I need to do some research on XMLHttp. I assume you mean the XMLHttp JavaScript object? (It's an object I've not run into before and wasn't aware of.) From what you describe above, this could clean some of our "code" up quite a bit. (in quotes to represent HTML as well as JavaScript)
In a matter of speaking, yes. Strictly speaking, yes. In that respect, everything is a matter of consensus. At that point you are so deep in philosophy that you cannot prove or disprove anything, so it's not a terribly productive place to reason from.
That doesn't mean that reality is consensual. That is, if reality were consensual, why would scientists repeatedly measure results that disagree not only with scientific expectations, but also with popular expectations?
Where science is useful is where it makes predictions of measurements that have not yet been made. That makes the theory disprovable. You could say that science is the set of theories that have not yet been disproven, and you would be philosophically correct. But -- except for taking potshots or being post-modern -- there isn't much you can do with such a viewpoint. At least with science there is a method for finding errors and for moving forward.
There are many people out there who call our world "consensual reality."
So? There are people out there who say all kinds of things. There are people who don't believe the moon landing happened. I know people who believe in the New World Order and who supposedly have spoken to folks of that organization. People say all kinds of stuff. That doesn't mean there is any meaning or value to it.
How can you tell the difference between consensus and truth?
How about the scientific method? It doesn't work as well for things where facts are somewhat subjective (such as history or political science or psychology), but it works better than other alternatives.
I spoke imprecisely. You're right, as far as processor power goes, pushing validation to the client end helps a system scale. However, you still have to validate input on the server end as well if you want to be secure and safe against malicious mis-entry from people working around the scripting. Notice that it was scripting that I said didn't scale, not the separation of user agent and server. Scripting a form is one way of validating or automating input at the user agent end, but none of that allows you to skimp in input checking on the server or application end.
But as I said, I was speaking about the code maintenance end of things, not processing power. I wasn't clear. My fault.
When I code a web page with a lot of scripting, I tend to separate the JavaScript into a separate file for scalability purposes -- because most of the work I have done involved dynamically generated pages. By putting the Javascript into a separate page, the web server (rather than the server generating pages, whether it be PHP or JSP or whatever) can serve the static content. That helps scalability. However, it also means that now information about a form is in two separate locations: The HTML of the form, and the Javascript file containing the scripting.
It was in that sense I was saying scripting doesn't scale. It increases maintenance work and the likelihood of making a mistake. However, if you can cleanly represent in one location the form and the set of allowable values, the code will scale better (as far as creating a large application that is cleanly maintainable).
Is this true? If so, that seems like a hole in the system. The FAQ talks about not being allowed to post and mod the same discussion, and it doesn't say "unless you post anonymously." Have I read into the FAQ a rule that isn't there?
Good luck with those snarky corrections;)
Well, I tried! But I'm always willing to listen to factual corrections.
But I know nothing about the XForms standard, so I can't speak intelligently about it.
You're absolutely right, because you make statements like this:
Microsoft is ignoring XForms just like everyone else. Microsoft would prefer people use XAML
Hey, at least I was honest and not trying to represent myself as being an expert on something I wasn't! Geez. The statement I made above that you have corrected came from the FA. I made the apparently mistaken assumption that the article author had a clue. I did RTFA before my post.
As far as XAML vs XUL, I wasn't aware that anyone had even proposed using XUL as a standard. XAML I was aware of.
Let's also not forget that Microsoft is a member of the W3C XForms committee.
That doesn't necessarily mean anything positive or negative, although it is a better sign than them not being a member of the committee. But membership on a committee doesn't mean a company has any intention of implementing the standard, nor that if they started with such intent they wouldn't change their mind if the standard went in a different direction. Witness the wide variety of CD/DVD writing standards.
But to be clear, I stand corrected on XAML not being a competitor of XForms and I apologize for my seemingly egregious error in assuming the FA author had a clue.
I'm not certain who you modded down, but assuming it was your parent post, I hope you understand that by posting about it in this discussion, you just undid all of your mod points in this discussion! Still, your post was funny. Good luck finding those Free IPod sigs.
Nope, Microsoft is ignoring XForms just like everyone else. Microsoft would prefer people use XAML (from Avalon). It seems the only folks implementing XForms are not browser makers, but people developing intranet based software.
Having written forms-based code with current browsers, I agree with the XForms supporters in that scripting is a terrible way to handle form input. It just doesn't scale and you have the form in one location and the code scripting in another place, so if you change something you have two separate locations to update everything in.
But I know nothing about the XForms standard, so I can't speak intelligently about it.
And the idea of being able to upgrade a library just doesn't work - we end up having to fork the library half the time!
Not really. Not to fix a bug. You can fork a library to add features, but even that does not stop you from patching an older version of the library. The great thing about versioned dynamically linked libraries (as used in ELF) is that you can have many versions of the same library installed at the same time and each application is able to use the one it was linked against.
You only need to fork a library if fixing the bug means making incompatible changes to the API. And if you have to do that, then you have to rebuild everything linked against it anyway. But if you are fixing a bug without changing the API, then you don't need to relink anything and you don't even need to reboot. Just stop and start any process using the old version of the dynamic library and viola, bug fixed.
Especially with something like clib -- if you go all static linking, then a patch to clib will be the size of the distribution (when you distribute the new packages rather than a delta). And I strongly prefer distributing the whole new package rather than a delta. It uses more space -- you are saying the space and bandwidth are cheap anyway -- but it is much cleaner because you know exactly what you have installed and you can easily verify (like with "rpm -V package") the correct unmodified contents of the current package.
To unbundle as you suggest would make just about every clib patch monstrous in size, which would make updates prohibitive to apply to those who don't have good bandwidth to the update sites.
Slashdot Mirror
Well, if your wedding video was produced by a commercial wedding videographer, then yes you might not be able to copy your wedding video. The videographer might well own the copyright on the video and might enable content protection so you cannot make a copy, but instead have to come back to them to purchase each copy. And they would have the legal right to do this unless your contract with them specified otherwise.
Secondly, Nikon's customers don't want new and interesting software for their cameras. They want to depress the shutter and get photos out. They can do that now, admirably, with the software Nikon already provides.
Wow, are you really that ignorant of the marketplace for the camera being discussed here? We're talking about a camera being sold to the very high end -- professionals. People who have a preferred tool chain, who know a lot about the chioces, and who have reasons for working a particular way. An average consumer camera marketed to people who won't use the raw format might work with what you said above. Pros, however, want to do MUCH more than just depress the shutter and get photos out.
Also, you say that they can get photos out "admirably." Have you used this software? According to many pros who do use Nikon Capture, it is much slower than many alternatives.
The market only works for well informed consumers. IN this case the market does not work because consumers are not educated and frankly could not understand what's going on even if you tried to educate them.
Actually, in this case the market is highly educated because this is a camera targeted at pros and rich amateurs. These are people who will use raw format and who do a lot of work in Photoshop or some other toolchain. They will react to any limits placed on their toolchain of choice by Nikon. I expect that Nikon will see a retaliation from their fans. Every Nikon fan I know personally is outraged about Nikon encrypting white balance information.
I have to say that Nikon's response is just as outrageous as their original action. It's the old, "We know better than you do and we are doing this to protect you, the consumer." Yeah, right.
Collusion is illegal when companies are working together to keep another company's product off the market by predatory pricing, for example. But when two companies (or consortiums) work together to choose a common standard, that is just plain good sense. The companies are wisely (I hope) seeing that the market will not welcome competing standards, and that the market (and thus their pocketbooks) are bettered by there being exactly one new DVD standard. There is no illegal activity here because no-one is being prevented from doing anything and they are not controlling prices by choosing to implement a common standard. There is no anti-competitive behavior.
Now, if the companies fixed the pricing of this standard and refused to allow anyone to undercut the pricing and used their size in the marketplace to control the availability and cost of the new DVD players, that could be collusion. If they were somehow working together (like a cartel) to prevent another company from competing in the marketspace, that might be collusion. (Depending on the tactics, etc.) However, just agreeing on a common standard does not collusion make.
Well, I was specifically referring to the activation schemes that more and more Adobe products are getting ... activiation as a form of DRM.
You are right. DRM in and of itself is not Instant Evil(tm). It is just the case that almost all implementations of DRM that exist today ARE. I welcome implementations of DRM that protect the author's rights without removing fair use rights.
Why on Earth would DRM in flash movies bother you?
Very good point! +1 Insightful and +1 Funny both.
That does seem to be what Adobe is doing to its full product line lately, adding all kinds of DRM. Hmm.
This is the manufacturer's fault. He provided you with faulty equipment and should repair it at his expense or refund your money.
Not if the warrantee period is up. Want to take bets on how long the warrantee will last for these devices? 90 days maybe? This would only help if the model you purchase has its keys revoked and you notice this within the warrantee period.
I have an iRiver H340 which plays ogg vorbis very well. There are also integer based ogg vorbis methods available. I don't know if the iRiver players use floating or integer codecs for ogg, but I do know that I can listen to my ogg files with no problem.
Go ahead, get rid of copyright law and you'll not just get rid of Brittney Spears, but also probably every band you like.
When it comes to actual CASH that a musical artist sees, most of that cash comes from touring and not from CD sales. If you like David Bowie and someone else is touring playing his music, will you pay the same amount to see the other band that you would pay to see David Bowie? Probably not. Even if others play the same music, only David Bowie plays it like he does, and that is a HUGE part of what people like.
Also, your argument above would make "cover bands" or "tribute bands" illegal. Just two nights ago I was at a place that had a "tribute band" for Pearl Jam. (By coincidence and not because the band was there.) Now, does the existence of this tribute band cause the actual Pearl Jam to have no incentive to write or produce music? If you say "yes" then I don't know what universe you are in.
This "without copyright, no-one would ever produce anything" straw man argument is always trotted out in these debates, and that argument is equally weak every time I hear it.
Having said all of this, I hated every RIAA and MPAA lawsuit until they actually started suing those who were doing the wrong thing -- the people who were uploading music to be shared. I completely support the RIAA and MPAA's ethical right to sue those who upload music illegally to be shared. But I do NOT support lawsuits against toolmakers when those tools have a substantial legal and ethical use. (Such as bittorrent, decss, and others.)
I had a professor for a cosmology class that worked at the Fermi lab and he said that another scientist that used to work their went a bit off the deep end and now protests outside saying that they would eventually make a black hole and it would suck us all in.
I was a grad student at Fermilab on the CDF experiment, and I received a letter from the crackpot you are referring to. He sent the letter to every person on the experiment. He is (or at least was in the 90s) a professor of psychology at U of Hawaii who did a calculation that told him that collisions at Fermilab had a good probability of causing a vacuum transition to a deSitter space. Such a transition, if possible, would indeed destroy the Earth and solar system. Possibly the universe as we know it.
This fellow was not swayed by the fact that the Earth has always been bombarded with cosmic rays of much higher energy than we have the ability to create. I believe I still have that letter somewhere. Hmm. I should try to find it!
What exactly do they consider direct versus indirect?
The article at hubblesite answers your question:
A better read than the ./ article reference is an article at hubble site.
Hmm, last I checked, gravity discriminates against fat people.
Gravity doesn't discriminate against fat people. It pulls on them too. Just imagine if all you had to do to avoid gravity was gain weight. (Wait a minute...)
Wouldn't any accumulation of mass about that size that's not a star be a black hole?
I think the issue is that if you start with a diffuse cloud whose mass is too great, as the inner part of the cloud collapses and starts to heat up and eventually grow, its radiation pressure on the cloud's dust particles will be greater than the force of gravity on those particles. The outer layers of the cloud will be blown into interstellar space. This causes a limit to the maximum mass of a star.
You could probably create a larger star then the limit spoken of in the article by merging two smaller ones. Thus, if the above process limits the maximum star mass to (say) 140 stellar masses, then once you have formed two stars of that mass, just merge them into one star of much larger mass. However, getting two stars to collide in such a way that they merge takes some doing.
By the way, it is believed that there is an upper mass limit for a newly formed black hole, which is obviously smaller than the maximum mass for a star. With stars larger than a certain size, the stellar core collapses more rapidly than the outer layers and the "explosion" from the stellar core's collapse blows the star's outer layers into space instead of allowing them to collapse as well.
Of course, two black holes can merge, assuming the accretion disks and polar jets don't provide enough pressure to prevent the black holes from approaching closely. The frame dragging that takes place around a black hole may (speculation on my part) make it easier for black holes to merge than for stars of the same size to merge.
Point being, your vested interest in your career of being a programmer is perhaps keeping you from the honesty of the purpose and goal of programming enough to lie to the general public as you and many others in your situation, proprietary and open source have both lied so to protect your trade
WOW. I almost have no words to respond to the arrogant assumptions evident in your post! You are certainly putting a lot of words in the original AC's mouth. Most of my surprise at reading your post involved the array of assumptions you make about the AC. (It was not me, BTW. I don't post as AC.)
You also broadly overstate the ease of programming, the quickness of programming automation, and the ability of the patent office to realize that something is so simple that it does not deserve to be patented. The very existence of the 1-click patent should be enough to show your entire point is moot. The very fact that one can patent a mathematical algorithm -- something originally explicitly prohibited -- even though implmeneting an algorithm in code is usually very straightforward.
How is it that you take one AC's frustration with the patent system as the person in fact being a part of the problem, and a liar and intellectually dishonest to boot? I cannot see how you make that leap without vast assumptions.
If I had mod points (and hadn't already posted here, of course!) I would mod your post up. Looks like I need to do some research on XMLHttp. I assume you mean the XMLHttp JavaScript object? (It's an object I've not run into before and wasn't aware of.) From what you describe above, this could clean some of our "code" up quite a bit. (in quotes to represent HTML as well as JavaScript)
here's a hint: science is based on consensus....
In a matter of speaking, yes. Strictly speaking, yes. In that respect, everything is a matter of consensus. At that point you are so deep in philosophy that you cannot prove or disprove anything, so it's not a terribly productive place to reason from.
That doesn't mean that reality is consensual. That is, if reality were consensual, why would scientists repeatedly measure results that disagree not only with scientific expectations, but also with popular expectations?
Where science is useful is where it makes predictions of measurements that have not yet been made. That makes the theory disprovable. You could say that science is the set of theories that have not yet been disproven, and you would be philosophically correct. But -- except for taking potshots or being post-modern -- there isn't much you can do with such a viewpoint. At least with science there is a method for finding errors and for moving forward.
There are many people out there who call our world "consensual reality."
So? There are people out there who say all kinds of things. There are people who don't believe the moon landing happened. I know people who believe in the New World Order and who supposedly have spoken to folks of that organization. People say all kinds of stuff. That doesn't mean there is any meaning or value to it.
How can you tell the difference between consensus and truth?
How about the scientific method? It doesn't work as well for things where facts are somewhat subjective (such as history or political science or psychology), but it works better than other alternatives.
I spoke imprecisely. You're right, as far as processor power goes, pushing validation to the client end helps a system scale. However, you still have to validate input on the server end as well if you want to be secure and safe against malicious mis-entry from people working around the scripting. Notice that it was scripting that I said didn't scale, not the separation of user agent and server. Scripting a form is one way of validating or automating input at the user agent end, but none of that allows you to skimp in input checking on the server or application end.
But as I said, I was speaking about the code maintenance end of things, not processing power. I wasn't clear. My fault.
When I code a web page with a lot of scripting, I tend to separate the JavaScript into a separate file for scalability purposes -- because most of the work I have done involved dynamically generated pages. By putting the Javascript into a separate page, the web server (rather than the server generating pages, whether it be PHP or JSP or whatever) can serve the static content. That helps scalability. However, it also means that now information about a form is in two separate locations: The HTML of the form, and the Javascript file containing the scripting.
It was in that sense I was saying scripting doesn't scale. It increases maintenance work and the likelihood of making a mistake. However, if you can cleanly represent in one location the form and the set of allowable values, the code will scale better (as far as creating a large application that is cleanly maintainable).
He replied as AC. His mods stand.
Is this true? If so, that seems like a hole in the system. The FAQ talks about not being allowed to post and mod the same discussion, and it doesn't say "unless you post anonymously." Have I read into the FAQ a rule that isn't there?
Good luck with those snarky corrections ;)
Well, I tried! But I'm always willing to listen to factual corrections.
But I know nothing about the XForms standard, so I can't speak intelligently about it.
You're absolutely right, because you make statements like this:
Microsoft is ignoring XForms just like everyone else. Microsoft would prefer people use XAML
Hey, at least I was honest and not trying to represent myself as being an expert on something I wasn't! Geez. The statement I made above that you have corrected came from the FA. I made the apparently mistaken assumption that the article author had a clue. I did RTFA before my post.
As far as XAML vs XUL, I wasn't aware that anyone had even proposed using XUL as a standard. XAML I was aware of.
Let's also not forget that Microsoft is a member of the W3C XForms committee.
That doesn't necessarily mean anything positive or negative, although it is a better sign than them not being a member of the committee. But membership on a committee doesn't mean a company has any intention of implementing the standard, nor that if they started with such intent they wouldn't change their mind if the standard went in a different direction. Witness the wide variety of CD/DVD writing standards.
But to be clear, I stand corrected on XAML not being a competitor of XForms and I apologize for my seemingly egregious error in assuming the FA author had a clue.
I'm not certain who you modded down, but assuming it was your parent post, I hope you understand that by posting about it in this discussion, you just undid all of your mod points in this discussion! Still, your post was funny. Good luck finding those Free IPod sigs.
Nope, Microsoft is ignoring XForms just like everyone else. Microsoft would prefer people use XAML (from Avalon). It seems the only folks implementing XForms are not browser makers, but people developing intranet based software.
Having written forms-based code with current browsers, I agree with the XForms supporters in that scripting is a terrible way to handle form input. It just doesn't scale and you have the form in one location and the code scripting in another place, so if you change something you have two separate locations to update everything in.
But I know nothing about the XForms standard, so I can't speak intelligently about it.
And the idea of being able to upgrade a library just doesn't work - we end up having to fork the library half the time!
Not really. Not to fix a bug. You can fork a library to add features, but even that does not stop you from patching an older version of the library. The great thing about versioned dynamically linked libraries (as used in ELF) is that you can have many versions of the same library installed at the same time and each application is able to use the one it was linked against.
You only need to fork a library if fixing the bug means making incompatible changes to the API. And if you have to do that, then you have to rebuild everything linked against it anyway. But if you are fixing a bug without changing the API, then you don't need to relink anything and you don't even need to reboot. Just stop and start any process using the old version of the dynamic library and viola, bug fixed.
Especially with something like clib -- if you go all static linking, then a patch to clib will be the size of the distribution (when you distribute the new packages rather than a delta). And I strongly prefer distributing the whole new package rather than a delta. It uses more space -- you are saying the space and bandwidth are cheap anyway -- but it is much cleaner because you know exactly what you have installed and you can easily verify (like with "rpm -V package") the correct unmodified contents of the current package.
To unbundle as you suggest would make just about every clib patch monstrous in size, which would make updates prohibitive to apply to those who don't have good bandwidth to the update sites.