You're getting close, and you're right, this is definitely NOT the same as selling you a crippled chip that is upgradeable.
Many enterprise customers LOVE this functionality. Often times, enterprise software is priced by number of CPUs. As a result, customers don't WANT additional CPUs when they don't need them. However, business needs may change in the future, so they want the option to upgrade. Often, they will pay EXTRA to have that CPU in there lying dormant. If they need it, they pay to turn it on. If they don't, the amount extra they paid is less (often significantly less, due mainly to software costs) than they would have paid if they had bought the upgrade initially.
For the consumer market, I don't think this makes sense. A newly purchased computer is likely to have all the performance a user needs, even on the low end. Once that is no longer the case, one of two things will have happened:
1.) The user has so much junk running in the background that their CPU is always pegged running junk. In this case, a CPU upgrade might help, but more likely that will just get 100% utilized too. The real solution in this case (for Joe Sixpack) is to buy a new PC. As an alternative they can pay someone to reinstall Windows, which would cost about the same as the CPU upgrade and be much more effective.
2.) It's 3-5 years later and there are new applications (like HD video) that require significantly more computing power. In this case, even adding the new cores won't be enough because the cores you'll be adding are 3-5 year old cores, and there's no guarantee that other components (like the GPU) will be up to it. Again, the correct solution is to buy a new PC.
The key here is that for the majority of consumers, low-end is good enough. When they do want an upgrade they either have software problems or they need a BIG upgrade.
The reason math and science classes are different is because they have a large component of learning how to DO something.
Foreign languages and, to a lesser extent, history are some of the few college areas that at the undergraduate college level are still about memorization. Undergraduate foreign language courses are almost pure memorization. "What is pictured?" and "conjugate this verb," are both memorization questions. "If Alice has 12 coins and together Alice and Bob have 30 coins, how many coins does Bob have?" is a skill question.
Many college-level English courses do allow you to bring the book you've been studying into the exam. They may also let you bring your notes into the exam (but not Cliff Notes.) This is because "In The Scarlet Letter, analyze the priest's motivation for revealing himself" is an analysis problem, and not a memorization problem.
History exams tend to lie somewhere in-between, but often the text and notes are allowed, with the realization that while all students may be able to get the memorization problems, ill-prepared students will do a poor job and have insufficient time to adequately complete the analysis problems.
Given that the information they want is so innocuous (see their examples,) the way I would probably handle it is:
1.) Get a list of past DefCon attendees from the company. 2.) Find prior attendees NOT attending the current DefCon. 3.) Call those prior attendees up and say "DefCon this year is doing a social engineering CTF, can you help me out by providing some silly and innocuous data about your company/building?"
This could work surprisingly well, so long as you got somebody willing to play along and help you "cheat."
In fact, this approach (or something similar) would probably be so common and so effective that there might be a rule added against it.
What would be particularly funny is if you didn't actually check if they were attending this year, and the "victim" was sitting in the audience!
The argument for "plug-ins" being derivative isn't that cut-and-dry.
First, let's be careful about the word "plug-in", it has lots of image attached to it, and there has been some argument that a wordpress plug-in isn't a plug-in in the typical sense.
Let's try another phrasing: "dynamically applied patch." A dynamically applied patch is a piece of code that is added to another piece of code at run-time to make it do something different than it originally did. In order to do this, it has to include references to the original program: function names, data types, and other aspects of the original program will be included. Much of this information would be purely factual and not be covered by copyright but some of it could be, and that's where a plug-in becomes a derivative work.
Is there a well-defined line at how much reference to the original work is required to become derivative? No... welcome to the real world.:) Could some of it be covered by copyright? Yes.
It's in these gray areas where it's best if all involved (particularly licensors) clearly state where they think the lines are. This doesn't really modify the law, but it can help ensure everyone feels they're being treated fairly, and helps avoid situations where people disagree if someone is playing by the rules.
I intentionally glossed over the detail that it isn't actually the modification itself that creates the obligation.
Copying and/or Distributing (particularly distributing, in the case of the GPL) the original code causes you to be subject to its license (the only thing that gives you the right to copy it.) In the case of the GPL, that license gives you a specific responsibility to license derivative works under the GPL, or else you may no longer distribute the original code.
My discussion centered on what constitutes a derivative work, and left out the specific details on when copying/distributing that derivative work actually makes it subject to the GPL.
I was assuming that the interface was unchanged across the license change, such that wordpress 0.1 plugins would be compatible with wordpress 5.0.
The reality though is that a jury is likely to still be on the "publicly usable" side if the changes were "minor." A complete redesign of the API after a license change would of course change things.
Also, the license change might make it such that the plugin and wordpress could not be distributed together.
Wine is a pretty good example of what happens after an open source license change when all the parties are acting within legal bounds. Some users may keep using the old code under the old license. Some code won't change much under the new license, and will be maintained essentially identically in both trees. Other code will diverge rapidly, resulting in users under the old license being unable to use it. I was assuming the plug-in API fell under the "didn't change much" area, especially based on the apparent confusion even within the wordpress community.
This is why (particularly for things like interpreted languages, but even for things like the Linux kernel) the correct thing to do is to label various interfaces as internal or external. Internal interfaces are those that, if called, make your work a derivative work. External interfaces are those that are considered "using" your work, and thus do not create a derivative work.
As a rule, internal interfaces are specific to HOW your implementation works, whereas external interfaces are more general to WHAT your software does. As such, internal interfaces are more subject to change. There are of course exceptions.
This kind of distinction is particularly important for applications that offer a plug-in or theming API.
Some cases are cut-and-dry: If you modify GPL source code, your modification becomes GPL. Most GPL libraries are pretty explicit that EVERYTHING is an internal interface and referencing it make a derivative work. Data is the only thing that doesn't. For LGPL libraries, linking and calling pretty much any function exported by the original work fails to create a LGPL derivative work.
Other cases are tougher: A plug-in may operate in the same process space as the main application, but may be considered a separate work if it only calls documented plug-in APIs. Certain Linux kernel drivers are considered okay (graphics drivers) but others are considered too tightly tied to the original work.
Consider this: If a minor modification to the function call implementation (think remote function call) causes the answer on whether or not it's a derivative work to change, then the line wasn't clearly drawn.
This smells like one of those cases. If PHP scripts were called in a different process space, that would seem to change the result of the analysis, which means we're definitely in dangerous territory.
Without really understanding all the details, it sounds like the developers have made what was generally treated as a public API into an internal one. If it was clearly (READ: In the API documentation) stated as being an internal API that creates a derivative work, then you're okay. If, after the fact, you're saying "no, that API that we treated as public/external really wasn't" then you're in hot water. If this goes to court, you better believe that the documentation and the early mailing list/forum posts by the primary developers will be presented as evidence. If it looks like they EVER implied that you were free to use those without creating a derivative work, then the argument for NOT derivative has a pretty strong case.
NOTE: As was conceded in the comments of the analysis, simply running in the same PHP process without calling WordPress (WP) code isn't enough to create a derivative work. Also conceded in the main article was that using the WP RSS APIs (presumably outside PHP) also do not create a derivative work. In that sense, it seems pretty clear that he considers the RSS APIs to be external while the theming APIs are internal.
The question becomes: Was this ALWAYS clear? If not, you can't go changing the rules just because you don't like what somebody is doing with your work. If it was just ambiguous, then it's a toss up as to who wins. If you were lenient earlier and are now trying to tighten your grip saying that they were wrong all along then you are likely to lose, at least with a jury.
Consider, for comparison, a GPL C library, where there's pretty good agreement on what the rules are. The C library is released as an incomplete "part of a program" where a program that derives from that part must become GPL. It's generally fair game to make that a simple but useful program (think cat/grep) and release to code for that. Then that GPL program can be called by a more complicated program that then does not become GPL. It gets ambiguous but generally not allowed when you make a program that basically exposes the internal APIs without doing anything useful beyond exposing those APIs, and then write a separate non-G
How do you handle a name that cannot be expressed using UTF? Allow an infinite-sized JPEG to be submitted in lieu of a text name?
That is an incredibly ugly hack for something as obscure as a non-UTF name.
As for the size, it is reasonable for the programmer to set an arbitrary size and say that NO, I won't let you use the name field as a remote disk drive. Sorry. As to whether or not 2048 UTF-16 characters (512 UTF-32 characters) is big enough for that is hard to say, as the choice of boundary is by definition arbitrary. The nice thing about 2048 UTF-16 characters is that it matches the page size of most computers, and so seems to be a reasonable boundary.
I used to live across the street from a fairly large apartment complex at:
12345 Lamplight Village.
I had a friend who lived there, and I can't count the times she complained that mail would be returned to sender saying it was an invalid address. The worst part is that it was often returned by the LOCAL post office, who should have known better.
Just because a number (or a name) "looks" fake doesn't mean it is.
This surprises me. When AOL bought ICQ it seemed to be for one reason, to destroy it. ICQ was, at the time, the main competitor to AOL instant messenger, which was the market leader in instant messaging.
If what you say is correct, AOL both failed to destroy ICQ AND failed to make money on it. That's somewhat impressive, in a sad way.
The problem with console accessories, even if they're pretty cool, is they seldom sell nearly as well as the base system. This results in a lack of games, which further depresses accessory sales.
There are some signs that this has changed, with dance pads and guitar hero/rock band, but history is still on Nintendo's side (putting out a new console with the accessory integrated) on this one. Dance pads aren't really comparable, as they are really cheap, so the only really close example is musical instruments. The difference with musical instruments is that the third party developer is making money on the instruments themselves, and not giving that up to the console maker and relying purely on game sales.
If Microsoft really wanted to sell Kinect, they would drop all Xbox models except for an Xbox 360/Kinect model selling for $299. That would really get these into the market, AND probably increase the number of people buying the new Xbox 360. I'm still not sure if that would be enough to bring in the developers.
Cutting fuel consumption in half makes a BIG difference when the fuel consumption was high to begin with. When the fuel consumption starts out good (say, 33mpg) then even cutting it to a third doesn't make as big of a change.
Ironically, the message here is that the standards we should be improving are those on light trucks, not those on small cars where they already sip gas.
If the hardware can detect the error in order to put it in the register, the hardware should be able to flush and redo the instruction. The real problems either internally screw up the processor to the point that it can't process instructions, or are undetected by the hardware.
I could see how in certain applications (video decoding/encoding) the attitude could be taken to just ignore the errors, but it isn't obvious to me how to handle errors that screw up the processor. The only solution I see there is for an application where the processor is periodically reset. That could also be practical for something like video encoding, where you could simply reset the processor something like every frame, or if it's "taking too long." I think someone more familiar with this said that it is just these kinds of fault-tolerant applications like video being considered, and not general-purpose computing.
The real problem I see here is that if the user is in a noisy environment (say, outside in the sun) the error rate could go high enough that it would be unacceptable to the user. Even modern servers have problems with periods of increased solar flare activity, which would be killer to a device like this.
I'll begin with two questions, the first slightly obscure: 1.) Are Archaea Bacteria? 2.) What is the correct way to classify a platypus?
Ironically, I am probably going to use exactly the methods suggested in the article to reason about this discussion. I understand the issues involved in Pluto's removal as a planet as well as most lay-people, so I understand myself as being knowledgeable enough to at least reason about the problem.
Whether or not Pluto is a planet relies on a taxonomic issue, not a scientific one, in the sense that there is no "true" answer. No informed scientist argues the facts about Pluto. Pluto is a round block of rock and perhaps ice orbiting far way from the sun. It has sufficient gravity to pull it into a round shape. More recently, we have discovered that it lies in a collection of mostly smaller objects known as the Kuiper belt. The discovery of a number of other large, round objects in the Kuiper belt (and at least one beyond it) left scientists with a conundrum. Either they had to accept that the far reaches of the solar system contained significantly more planets than we had first anticipated, some of which shared an orbit, or they needed a new classification system that would, of necessity, remove Pluto as a planet. The choice they made was perhaps a reasonable one, but it was nevertheless a choice, not a change in the facts.
Other taxonomies were possible. The first would be to continue counting Pluto as a planet, admit Eris as a planet, and make a decision whether or not to call the other plutoids planets.
A second possible taxonomy would be to introduce a new level of astronomical classification (see the Archaea question above) and call both dwarf planets and what are currently called planets some sub-category of planet, such as unified planet, or something like that.
Why this matters: The reason all this matters is that school children, particularly young children, are taught about the planets, but not about the complex reality that is our solar system. Pretty early on they learn the distinction between the solid and gaseous planets, and having the dwarf planets as "planets" would mean that an explanation of the Kuiper belt would be included in that early study. In the collective consciousness, planets are important, everything else is just uninteresting hunks of rock and/or ice. Classifying dwarf planets as "not planets" means that the Kuiper belt objects and Eris (and the scattered disc) are removed from the collective consciousness of what is in our solar system.
I've seen my children's science textbooks, and it's not that Pluto has been replaced with Kuiper belt, it's simply been removed. If we're lucky, textbooks will begin to put in Kuiper belt in the same way the put the asteroid belt between Mars and Jupiter, but even then they will see the asteroid belt and the Kuiper belt as the same thing, even though the Kuiper belt contains much more interesting objects including, but no, we now know not limited to, Pluto.
Liability insurance requirements are done by the states, who most assuredly DO have the authority to force you to buy something, and to tax whatever the heck they like.
That said, I think a later poster got this one right. This will be a 2% tax across the board, with a credit for those who have health insurance. I'm not clear on how they're going to justify the $700 minimum provision, though, as that isn't an income-based tax. Also, the details of the exact wording in the bill are important to the constitutionality of this provision.
Most of the other provisions are definitely the purview of the federal government under the commerce clause.
This one is trivially easy to do fairly, and thus there is no reason to do it wrong.
Bad question: "If an object in space with a mass m1 is placed d meters away from a fixed object with mass m2, how far away will it be after 10 seconds?"
Good question: "USING NEWTON'S LAWS, if an object in space..."
The answer to the first question is correct if answered using relativistic equations. The second question is ABSOLUTELY incorrect is answered using relativistic equations, as the student is explicitly asked not to use them. (The question is perhaps easier because the student has been given a hint, but this is the only way to explicitly exclude the relativistic answer, if it is listed among the choices.)
HOWEVER, if the first question was asked and the correct answer using newton's laws was available, but the correct relativistic answer was NOT available, then "NONE OF THE ABOVE" is NOT correct. If the answer from newton's laws is available, ALL students should be able to recognize that the answer calculated using them is "close enough" for a basic high-school level test.
This is an example of why you do NOT want to allow the names to be public record for a referendum. A major figure for a company has just the same rights to anonymity as you or I do when acting as a private citizen. Signing a petition requesting a vote (as opposed to actively campaigning, or even funding a campaign) is a private act.
Let's assume your boss likes to wear white shoes after labor day. You, however, think this is so offensive that it should be illegal. If a petition asking for a vote on a law to make this illegal is requesting signatures you should not fear work repercussions for signing that petition. These types of petitions are a key part of American democracy in many areas, and keeping them secret preserves that right for more people.
Similarly, even the CEO of a corporation should have every right to participate in such a petition. They should be able to do so without the fear of financial repercussions.
However, if the CEO, for instance, made a large campaign donation then their influence is significantly more than that of an average private citizen. This is when their role should become public record.
This is the only good reason I've seen for making the names public, and the solution is relatively simple: have a standard non-disclosure agreement for any person or organization that want to view the list for the purpose of verifying signatures, with significant penalties (jail time AND fines) for disclosure, even through negligence, and even larger penalties if used in the commission of a crime.
Otherwise, the importance of anonymity serves a much greater role in protecting our freedoms.
The way such laws always have to be considered is to assume a large, well-funded, and morally corrupt entity (read: organized crime) has vested interests in a particular issue.
If they are for the referendum, they threaten to kill anyone in a certain area who doesn't sign it. If they are against the referendum, they threaten to kill anyone who does sign it. In either case, the public nature of the referendum gives them significantly more power. A private referendum with the above private disclosure options would reduce the ability to influence in this way. While the private disclosures would still allow some intimidation, the benefits could outweigh the potential abuses.
Also, a key thing to realize is that, in general, democracy is much better served by referendums calling for a vote favoring passing in error instead of failing in error. Elections are much better protected from external influence than the signature gathering process. Anonymous referendums serve this goal far better than public ones, where people would choose not to sign to avoid their viewpoints on a certain issue being disclosed. If a person wishes it to be public that they favor a certain issue, they are always able to declare their views separately from the referendum process, just as a person is always able to tell others how they choose to vote.
I went to a Verilog school and have since moved on to a career with VHDL. Coming from a mixed hardware/software background, I found it VERY tempting to build something in Verilog that looked pretty to my software design eyes but didn't translate to hardware well at all. When this happened, I at least understood what was going on and how I had messed up. For many of my classmates, they had very little concept of how the verilog procedures would be converted into hardware. There were a lot of class projects where I had to explain: "No, you can't have a procedure like that. I know it works in C, but in real hardware that is going to be something like 100 stages of logic because you don't have any latch stages in the middle."
VHDL tends to be built in a way that is much more like real hardware, with the massive concurrency and limited cycle time characteristics being much more obvious. While it's definitely possible to mess things up, the restrictions of the language tend to make this more clear.
You have added a significant new requirement on the software in that it must be able to detect not just a non-existent, but a corrupt config file. That alone is fairly onerous, but it's worse that that.
The worst part is that this actually doesn't work, but the reason is subtle.
Consider if the file is being altered twice in the commit interval (fairly likely for a long commit interval like the one for ext4.) In this case, the expectation is that the use should be able to recover any of three versions of the file, but doesn't care which.
However, the updates could be committed to disk in the following order:
Lines with a - are non-existent. Lines with a * lack valid data.
1. rename file- file.old 2. create file* 3. rename file- file.old* <CRASH> 4. create file* <CRASH> 5. write file data (file.old* still corrupt) 6. write file.old data (now all clean.)
If a crash occurs in either of the lines marked <CRASH> then the data on disk will still be unrecoverable. Using the generally recommended method and having a behavior like ext3 data=ordered will have the desired behavior of allowing one of the three versions in a recoverable state. Your method would also work, but only with data=ordered. However, failure recovery is more difficult using the method you suggest.
In fact, if order of operations makes it possible to end up with a corrupt file after a crash, it may well be possible that this could happen even if you do an fsync(). The system can still crash in the middle of your fsync(), and if at any time, the filesystem produces something inconsistent on disk, you can end up with a problem. No filesystem should ever be coded that intentionally creates inconsistent data on disk, however transient. Imagine a DBMS doing that.
<p>Just to be clear, the filesystem will be okay with this new definition IF THEY ADD fsync(), so long as the user does what everyone agrees was best practice and uses the rename method. In that case the rename() will not occur until after the fsync().
fsync() doesn't really mean what the POSIX spec says it means, and hasn't for a while.
Technically, fsync() means sit and wait until the data has been written to disk, and then return. Since the commit interval on this new filesystem is over a minute, using this view would mean that the application could hang for all of that time.
Because commit windows are now so long (even 5 seconds was a long time), filesystem authors have altered the behavior of fsync() to mean "write to the filesystem NOW." With this new meaning of fsync() and a pedantic view of the POSIX APIs, there is no longer a way to say "I want the old data or the new data after a crash, but don't really care which." (BTW, saying this with POSIX would require spawning a separate thread to do the writes.) Instead, the user is saying "write this to disk, NOW." That's a whole different set of guarantees.
If all of the applications start replacing "I want the old or the new data, but don't care which," with "I want the new data written, NOW," then THAT will REALLY prevent the kind of write optimization that ext4 is trying to do. Delaying writing the rename until after the data is written shouldn't hurt filesystem performance significantly at all. The only cost should be in the in-memory data structures necessary to track this dependency.
In this case, what the application writers are asking for is both good for system integrity AND good for filesystem performance. The alternatives (database, fsync) are all worse, not better.
(Aside: All of this applies to the atomic rename() method. Everyone agrees that using O_TRUNC on an existing file was just dumb.)
The GPL restricts developers and distributors, not end users. GPLv3 adds additional restrictions.
If a business was built around exploiting "loopholes" in the GPLv2 and then the project they were relying on as a whole moves to GPLv3, then the business may have lost access to further updates.
So, even the GPL is not exempt from creating tighter restrictions. Just because some people happen to like the restrictions doesn't mean they aren't beyond those originally applied.
Slashdot Mirror
You're getting close, and you're right, this is definitely NOT the same as selling you a crippled chip that is upgradeable.
Many enterprise customers LOVE this functionality. Often times, enterprise software is priced by number of CPUs. As a result, customers don't WANT additional CPUs when they don't need them. However, business needs may change in the future, so they want the option to upgrade. Often, they will pay EXTRA to have that CPU in there lying dormant. If they need it, they pay to turn it on. If they don't, the amount extra they paid is less (often significantly less, due mainly to software costs) than they would have paid if they had bought the upgrade initially.
For the consumer market, I don't think this makes sense. A newly purchased computer is likely to have all the performance a user needs, even on the low end. Once that is no longer the case, one of two things will have happened:
1.) The user has so much junk running in the background that their CPU is always pegged running junk. In this case, a CPU upgrade might help, but more likely that will just get 100% utilized too. The real solution in this case (for Joe Sixpack) is to buy a new PC. As an alternative they can pay someone to reinstall Windows, which would cost about the same as the CPU upgrade and be much more effective.
2.) It's 3-5 years later and there are new applications (like HD video) that require significantly more computing power. In this case, even adding the new cores won't be enough because the cores you'll be adding are 3-5 year old cores, and there's no guarantee that other components (like the GPU) will be up to it. Again, the correct solution is to buy a new PC.
The key here is that for the majority of consumers, low-end is good enough. When they do want an upgrade they either have software problems or they need a BIG upgrade.
The reason math and science classes are different is because they have a large component of learning how to DO something.
Foreign languages and, to a lesser extent, history are some of the few college areas that at the undergraduate college level are still about memorization. Undergraduate foreign language courses are almost pure memorization. "What is pictured?" and "conjugate this verb," are both memorization questions. "If Alice has 12 coins and together Alice and Bob have 30 coins, how many coins does Bob have?" is a skill question.
Many college-level English courses do allow you to bring the book you've been studying into the exam. They may also let you bring your notes into the exam (but not Cliff Notes.) This is because "In The Scarlet Letter, analyze the priest's motivation for revealing himself" is an analysis problem, and not a memorization problem.
History exams tend to lie somewhere in-between, but often the text and notes are allowed, with the realization that while all students may be able to get the memorization problems, ill-prepared students will do a poor job and have insufficient time to adequately complete the analysis problems.
Given that the information they want is so innocuous (see their examples,) the way I would probably handle it is:
1.) Get a list of past DefCon attendees from the company.
2.) Find prior attendees NOT attending the current DefCon.
3.) Call those prior attendees up and say "DefCon this year is doing a social engineering CTF, can you help me out by providing some silly and innocuous data about your company/building?"
This could work surprisingly well, so long as you got somebody willing to play along and help you "cheat."
In fact, this approach (or something similar) would probably be so common and so effective that there might be a rule added against it.
What would be particularly funny is if you didn't actually check if they were attending this year, and the "victim" was sitting in the audience!
The argument for "plug-ins" being derivative isn't that cut-and-dry.
:) Could some of it be covered by copyright? Yes.
First, let's be careful about the word "plug-in", it has lots of image attached to it, and there has been some argument that a wordpress plug-in isn't a plug-in in the typical sense.
Let's try another phrasing: "dynamically applied patch." A dynamically applied patch is a piece of code that is added to another piece of code at run-time to make it do something different than it originally did. In order to do this, it has to include references to the original program: function names, data types, and other aspects of the original program will be included. Much of this information would be purely factual and not be covered by copyright but some of it could be, and that's where a plug-in becomes a derivative work.
Is there a well-defined line at how much reference to the original work is required to become derivative? No... welcome to the real world.
It's in these gray areas where it's best if all involved (particularly licensors) clearly state where they think the lines are. This doesn't really modify the law, but it can help ensure everyone feels they're being treated fairly, and helps avoid situations where people disagree if someone is playing by the rules.
I intentionally glossed over the detail that it isn't actually the modification itself that creates the obligation.
Copying and/or Distributing (particularly distributing, in the case of the GPL) the original code causes you to be subject to its license (the only thing that gives you the right to copy it.) In the case of the GPL, that license gives you a specific responsibility to license derivative works under the GPL, or else you may no longer distribute the original code.
My discussion centered on what constitutes a derivative work, and left out the specific details on when copying/distributing that derivative work actually makes it subject to the GPL.
I was assuming that the interface was unchanged across the license change, such that wordpress 0.1 plugins would be compatible with wordpress 5.0.
The reality though is that a jury is likely to still be on the "publicly usable" side if the changes were "minor." A complete redesign of the API after a license change would of course change things.
Also, the license change might make it such that the plugin and wordpress could not be distributed together.
Wine is a pretty good example of what happens after an open source license change when all the parties are acting within legal bounds. Some users may keep using the old code under the old license. Some code won't change much under the new license, and will be maintained essentially identically in both trees. Other code will diverge rapidly, resulting in users under the old license being unable to use it. I was assuming the plug-in API fell under the "didn't change much" area, especially based on the apparent confusion even within the wordpress community.
This is why (particularly for things like interpreted languages, but even for things like the Linux kernel) the correct thing to do is to label various interfaces as internal or external. Internal interfaces are those that, if called, make your work a derivative work. External interfaces are those that are considered "using" your work, and thus do not create a derivative work.
As a rule, internal interfaces are specific to HOW your implementation works, whereas external interfaces are more general to WHAT your software does. As such, internal interfaces are more subject to change. There are of course exceptions.
This kind of distinction is particularly important for applications that offer a plug-in or theming API.
Some cases are cut-and-dry:
If you modify GPL source code, your modification becomes GPL.
Most GPL libraries are pretty explicit that EVERYTHING is an internal interface and referencing it make a derivative work. Data is the only thing that doesn't.
For LGPL libraries, linking and calling pretty much any function exported by the original work fails to create a LGPL derivative work.
Other cases are tougher:
A plug-in may operate in the same process space as the main application, but may be considered a separate work if it only calls documented plug-in APIs.
Certain Linux kernel drivers are considered okay (graphics drivers) but others are considered too tightly tied to the original work.
Consider this: If a minor modification to the function call implementation (think remote function call) causes the answer on whether or not it's a derivative work to change, then the line wasn't clearly drawn.
This smells like one of those cases. If PHP scripts were called in a different process space, that would seem to change the result of the analysis, which means we're definitely in dangerous territory.
Without really understanding all the details, it sounds like the developers have made what was generally treated as a public API into an internal one. If it was clearly (READ: In the API documentation) stated as being an internal API that creates a derivative work, then you're okay. If, after the fact, you're saying "no, that API that we treated as public/external really wasn't" then you're in hot water. If this goes to court, you better believe that the documentation and the early mailing list/forum posts by the primary developers will be presented as evidence. If it looks like they EVER implied that you were free to use those without creating a derivative work, then the argument for NOT derivative has a pretty strong case.
NOTE: As was conceded in the comments of the analysis, simply running in the same PHP process without calling WordPress (WP) code isn't enough to create a derivative work. Also conceded in the main article was that using the WP RSS APIs (presumably outside PHP) also do not create a derivative work. In that sense, it seems pretty clear that he considers the RSS APIs to be external while the theming APIs are internal.
The question becomes: Was this ALWAYS clear? If not, you can't go changing the rules just because you don't like what somebody is doing with your work. If it was just ambiguous, then it's a toss up as to who wins. If you were lenient earlier and are now trying to tighten your grip saying that they were wrong all along then you are likely to lose, at least with a jury.
Consider, for comparison, a GPL C library, where there's pretty good agreement on what the rules are. The C library is released as an incomplete "part of a program" where a program that derives from that part must become GPL. It's generally fair game to make that a simple but useful program (think cat/grep) and release to code for that. Then that GPL program can be called by a more complicated program that then does not become GPL. It gets ambiguous but generally not allowed when you make a program that basically exposes the internal APIs without doing anything useful beyond exposing those APIs, and then write a separate non-G
I agree. I would much rather have two 1-day gaps in delivery than one 2-day gap.
Businesses might be the opposite, so it might make sense to deliver to businesses M-F and residential M-W, F-Sa.
I'll bite.
How do you handle a name that cannot be expressed using UTF? Allow an infinite-sized JPEG to be submitted in lieu of a text name?
That is an incredibly ugly hack for something as obscure as a non-UTF name.
As for the size, it is reasonable for the programmer to set an arbitrary size and say that NO, I won't let you use the name field as a remote disk drive. Sorry. As to whether or not 2048 UTF-16 characters (512 UTF-32 characters) is big enough for that is hard to say, as the choice of boundary is by definition arbitrary. The nice thing about 2048 UTF-16 characters is that it matches the page size of most computers, and so seems to be a reasonable boundary.
Postal addresses are a whole other problem.
I used to live across the street from a fairly large apartment complex at:
12345 Lamplight Village.
I had a friend who lived there, and I can't count the times she complained that mail would be returned to sender saying it was an invalid address. The worst part is that it was often returned by the LOCAL post office, who should have known better.
Just because a number (or a name) "looks" fake doesn't mean it is.
This surprises me. When AOL bought ICQ it seemed to be for one reason, to destroy it. ICQ was, at the time, the main competitor to AOL instant messenger, which was the market leader in instant messaging.
If what you say is correct, AOL both failed to destroy ICQ AND failed to make money on it. That's somewhat impressive, in a sad way.
The problem with console accessories, even if they're pretty cool, is they seldom sell nearly as well as the base system. This results in a lack of games, which further depresses accessory sales.
There are some signs that this has changed, with dance pads and guitar hero/rock band, but history is still on Nintendo's side (putting out a new console with the accessory integrated) on this one. Dance pads aren't really comparable, as they are really cheap, so the only really close example is musical instruments. The difference with musical instruments is that the third party developer is making money on the instruments themselves, and not giving that up to the console maker and relying purely on game sales.
If Microsoft really wanted to sell Kinect, they would drop all Xbox models except for an Xbox 360/Kinect model selling for $299. That would really get these into the market, AND probably increase the number of people buying the new Xbox 360. I'm still not sure if that would be enough to bring in the developers.
It is anyway.
For a 1000 mile trip:
@10mpg: 100 gallons
@20mpg: 50 gallons
@33mpg: 30 gallons
@50mpg: 20 gallons
@100mpg: 10 gallons
Cutting fuel consumption in half makes a BIG difference when the fuel consumption was high to begin with. When the fuel consumption starts out good (say, 33mpg) then even cutting it to a third doesn't make as big of a change.
Ironically, the message here is that the standards we should be improving are those on light trucks, not those on small cars where they already sip gas.
If the hardware can detect the error in order to put it in the register, the hardware should be able to flush and redo the instruction. The real problems either internally screw up the processor to the point that it can't process instructions, or are undetected by the hardware.
I could see how in certain applications (video decoding/encoding) the attitude could be taken to just ignore the errors, but it isn't obvious to me how to handle errors that screw up the processor. The only solution I see there is for an application where the processor is periodically reset. That could also be practical for something like video encoding, where you could simply reset the processor something like every frame, or if it's "taking too long." I think someone more familiar with this said that it is just these kinds of fault-tolerant applications like video being considered, and not general-purpose computing.
The real problem I see here is that if the user is in a noisy environment (say, outside in the sun) the error rate could go high enough that it would be unacceptable to the user. Even modern servers have problems with periods of increased solar flare activity, which would be killer to a device like this.
I'll begin with two questions, the first slightly obscure:
1.) Are Archaea Bacteria?
2.) What is the correct way to classify a platypus?
Ironically, I am probably going to use exactly the methods suggested in the article to reason about this discussion. I understand the issues involved in Pluto's removal as a planet as well as most lay-people, so I understand myself as being knowledgeable enough to at least reason about the problem.
Whether or not Pluto is a planet relies on a taxonomic issue, not a scientific one, in the sense that there is no "true" answer. No informed scientist argues the facts about Pluto. Pluto is a round block of rock and perhaps ice orbiting far way from the sun. It has sufficient gravity to pull it into a round shape. More recently, we have discovered that it lies in a collection of mostly smaller objects known as the Kuiper belt. The discovery of a number of other large, round objects in the Kuiper belt (and at least one beyond it) left scientists with a conundrum. Either they had to accept that the far reaches of the solar system contained significantly more planets than we had first anticipated, some of which shared an orbit, or they needed a new classification system that would, of necessity, remove Pluto as a planet. The choice they made was perhaps a reasonable one, but it was nevertheless a choice, not a change in the facts.
Other taxonomies were possible. The first would be to continue counting Pluto as a planet, admit Eris as a planet, and make a decision whether or not to call the other plutoids planets.
A second possible taxonomy would be to introduce a new level of astronomical classification (see the Archaea question above) and call both dwarf planets and what are currently called planets some sub-category of planet, such as unified planet, or something like that.
Why this matters:
The reason all this matters is that school children, particularly young children, are taught about the planets, but not about the complex reality that is our solar system. Pretty early on they learn the distinction between the solid and gaseous planets, and having the dwarf planets as "planets" would mean that an explanation of the Kuiper belt would be included in that early study. In the collective consciousness, planets are important, everything else is just uninteresting hunks of rock and/or ice. Classifying dwarf planets as "not planets" means that the Kuiper belt objects and Eris (and the scattered disc) are removed from the collective consciousness of what is in our solar system.
I've seen my children's science textbooks, and it's not that Pluto has been replaced with Kuiper belt, it's simply been removed. If we're lucky, textbooks will begin to put in Kuiper belt in the same way the put the asteroid belt between Mars and Jupiter, but even then they will see the asteroid belt and the Kuiper belt as the same thing, even though the Kuiper belt contains much more interesting objects including, but no, we now know not limited to, Pluto.
Liability insurance requirements are done by the states, who most assuredly DO have the authority to force you to buy something, and to tax whatever the heck they like.
That said, I think a later poster got this one right. This will be a 2% tax across the board, with a credit for those who have health insurance. I'm not clear on how they're going to justify the $700 minimum provision, though, as that isn't an income-based tax. Also, the details of the exact wording in the bill are important to the constitutionality of this provision.
Most of the other provisions are definitely the purview of the federal government under the commerce clause.
This one is trivially easy to do fairly, and thus there is no reason to do it wrong.
Bad question:
"If an object in space with a mass m1 is placed d meters away from a fixed object with mass m2, how far away will it be after 10 seconds?"
Good question:
"USING NEWTON'S LAWS, if an object in space..."
The answer to the first question is correct if answered using relativistic equations. The second question is ABSOLUTELY incorrect is answered using relativistic equations, as the student is explicitly asked not to use them. (The question is perhaps easier because the student has been given a hint, but this is the only way to explicitly exclude the relativistic answer, if it is listed among the choices.)
HOWEVER, if the first question was asked and the correct answer using newton's laws was available, but the correct relativistic answer was NOT available, then "NONE OF THE ABOVE" is NOT correct. If the answer from newton's laws is available, ALL students should be able to recognize that the answer calculated using them is "close enough" for a basic high-school level test.
This is an example of why you do NOT want to allow the names to be public record for a referendum. A major figure for a company has just the same rights to anonymity as you or I do when acting as a private citizen. Signing a petition requesting a vote (as opposed to actively campaigning, or even funding a campaign) is a private act.
Let's assume your boss likes to wear white shoes after labor day. You, however, think this is so offensive that it should be illegal. If a petition asking for a vote on a law to make this illegal is requesting signatures you should not fear work repercussions for signing that petition. These types of petitions are a key part of American democracy in many areas, and keeping them secret preserves that right for more people.
Similarly, even the CEO of a corporation should have every right to participate in such a petition. They should be able to do so without the fear of financial repercussions.
However, if the CEO, for instance, made a large campaign donation then their influence is significantly more than that of an average private citizen. This is when their role should become public record.
This is the only good reason I've seen for making the names public, and the solution is relatively simple: have a standard non-disclosure agreement for any person or organization that want to view the list for the purpose of verifying signatures, with significant penalties (jail time AND fines) for disclosure, even through negligence, and even larger penalties if used in the commission of a crime.
Otherwise, the importance of anonymity serves a much greater role in protecting our freedoms.
The way such laws always have to be considered is to assume a large, well-funded, and morally corrupt entity (read: organized crime) has vested interests in a particular issue.
If they are for the referendum, they threaten to kill anyone in a certain area who doesn't sign it. If they are against the referendum, they threaten to kill anyone who does sign it. In either case, the public nature of the referendum gives them significantly more power. A private referendum with the above private disclosure options would reduce the ability to influence in this way. While the private disclosures would still allow some intimidation, the benefits could outweigh the potential abuses.
Also, a key thing to realize is that, in general, democracy is much better served by referendums calling for a vote favoring passing in error instead of failing in error. Elections are much better protected from external influence than the signature gathering process. Anonymous referendums serve this goal far better than public ones, where people would choose not to sign to avoid their viewpoints on a certain issue being disclosed. If a person wishes it to be public that they favor a certain issue, they are always able to declare their views separately from the referendum process, just as a person is always able to tell others how they choose to vote.
6. Someone may break into your home/place of business and steal anything that looks remotely "technical." This requires some sort of remote backups.
I also agree with this completely.
I went to a Verilog school and have since moved on to a career with VHDL. Coming from a mixed hardware/software background, I found it VERY tempting to build something in Verilog that looked pretty to my software design eyes but didn't translate to hardware well at all. When this happened, I at least understood what was going on and how I had messed up. For many of my classmates, they had very little concept of how the verilog procedures would be converted into hardware. There were a lot of class projects where I had to explain: "No, you can't have a procedure like that. I know it works in C, but in real hardware that is going to be something like 100 stages of logic because you don't have any latch stages in the middle."
VHDL tends to be built in a way that is much more like real hardware, with the massive concurrency and limited cycle time characteristics being much more obvious. While it's definitely possible to mess things up, the restrictions of the language tend to make this more clear.
You have added a significant new requirement on the software in that it must be able to detect not just a non-existent, but a corrupt config file. That alone is fairly onerous, but it's worse that that.
The worst part is that this actually doesn't work, but the reason is subtle.
Consider if the file is being altered twice in the commit interval (fairly likely for a long commit interval like the one for ext4.) In this case, the expectation is that the use should be able to recover any of three versions of the file, but doesn't care which.
However, the updates could be committed to disk in the following order:
Lines with a - are non-existent.
Lines with a * lack valid data.
1. rename file- file.old
2. create file*
3. rename file- file.old*
<CRASH>
4. create file*
<CRASH>
5. write file data (file.old* still corrupt)
6. write file.old data (now all clean.)
If a crash occurs in either of the lines marked <CRASH> then the data on disk will still be unrecoverable. Using the generally recommended method and having a behavior like ext3 data=ordered will have the desired behavior of allowing one of the three versions in a recoverable state. Your method would also work, but only with data=ordered. However, failure recovery is more difficult using the method you suggest.
In fact, if order of operations makes it possible to end up with a corrupt file after a crash, it may well be possible that this could happen even if you do an fsync(). The system can still crash in the middle of your fsync(), and if at any time, the filesystem produces something inconsistent on disk, you can end up with a problem. No filesystem should ever be coded that intentionally creates inconsistent data on disk, however transient. Imagine a DBMS doing that.
<p>Just to be clear, the filesystem will be okay with this new definition IF THEY ADD fsync(), so long as the user does what everyone agrees was best practice and uses the rename method. In that case the rename() will not occur until after the fsync().
Actually, there's a deeper issue.
fsync() doesn't really mean what the POSIX spec says it means, and hasn't for a while.
Technically, fsync() means sit and wait until the data has been written to disk, and then return. Since the commit interval on this new filesystem is over a minute, using this view would mean that the application could hang for all of that time.
Because commit windows are now so long (even 5 seconds was a long time), filesystem authors have altered the behavior of fsync() to mean "write to the filesystem NOW." With this new meaning of fsync() and a pedantic view of the POSIX APIs, there is no longer a way to say "I want the old data or the new data after a crash, but don't really care which." (BTW, saying this with POSIX would require spawning a separate thread to do the writes.) Instead, the user is saying "write this to disk, NOW." That's a whole different set of guarantees.
If all of the applications start replacing "I want the old or the new data, but don't care which," with "I want the new data written, NOW," then THAT will REALLY prevent the kind of write optimization that ext4 is trying to do. Delaying writing the rename until after the data is written shouldn't hurt filesystem performance significantly at all. The only cost should be in the in-memory data structures necessary to track this dependency.
In this case, what the application writers are asking for is both good for system integrity AND good for filesystem performance. The alternatives (database, fsync) are all worse, not better.
(Aside: All of this applies to the atomic rename() method. Everyone agrees that using O_TRUNC on an existing file was just dumb.)
And GPLv3 is proof of his point.
The GPL restricts developers and distributors, not end users. GPLv3 adds additional restrictions.
If a business was built around exploiting "loopholes" in the GPLv2 and then the project they were relying on as a whole moves to GPLv3, then the business may have lost access to further updates.
So, even the GPL is not exempt from creating tighter restrictions. Just because some people happen to like the restrictions doesn't mean they aren't beyond those originally applied.