To get the flavor of this right, you need to get all your neighbor's to sneak their TV into this neighbors yard. Then have them all call the cops and issue a press release that this neighbor is clearly the head of a TV theft gang. He has stolen so many he can't keep them all inside and has to litter his front yard with them. For bonus points get him arrested for littering and creating a pubic nuisance.
If these allegations are true, it is the very definition of unclean hands...
And people wonder why we need net neutrality. This should shine a bright light into why it is so needed.
I've used the various add-ons that make multi-tasking possible on iPhone OS 3.1.2. Of course, I just mean "being able to run multiple GUI applications at once" by this statement, but that's kinda what it means in the popular, non-technical press...
I have a few observations.
First, some applications react very well to running in this mode. In fact, most of the ones I've tried do act well. I can get my facebook updates, have my chat client running, etc. So long as I'm careful with memory usage, things are all fast.
When memory gets tight, things fall apart. Sometimes the app dies, sometimes it gets really slow, etc. I have an old 2G phone, so memory is limited there. I doubt that native support for this would be stable enough to be enabled in iPhone OS 4 by default on the 2G.
Finally, the one reason I'd want this, assuming I had the memory, is that Apple would likely improve the GUI aspects of multi-tasking. There's no notification right now if I get a chat message. There's no mail notification. I'd love to have that stuff be possible while I'm playing a game (or disabled, depending on the game). The various jailbrake add-ons don't address this aspect of things. It is a rough edge in an otherwise highly integrated environment.
Warner
Almost correct. While the case precedents exist, they are still not as strong as you'd like because they have never been reviewed. This means they are still vulnerable to being replaced by precedents from other cases that do get fully reviewed. That's the bad thing about this ending in a settlement: since the case never wound its way entirely through the system, these rulings were never fully tested.
So the fact that the case was weak enough for one side to settle is encouraging, but there's still a long way to go before there's a good level of case law on open source.
The problem here is the 55" rule.
I have a 62" TV at home. And if you read the letter of the law, I have to get permission from the NFL to watch the game on my TV. This rule was put in place years ago when *NOBODY* had TV's this large at home (except maybe for the rear project crowd). Now that TV's bigger than 55" are very affordable, lots of people have them, and it will become more of a problem. I'd hate to see a rule designed to apply to
I have no problems with the NFL charging businesses to make money off their public exhibition of the superbowl, mind you, but when it starts to make life difficult for me as a private citizen I start to get cranky.
As someone who worked on the refit to the Loran-C US chains, I can tell you that the secondary transmitters do *NOT* listen for the master station pulse to send out their pulse. It is all controlled by custom hardware that is fed off atomic clocks that are fed off GPS (when available). If the MASTER station goes down, the secondary stations continue to chirp, and most receivers can work out the master's missing pulses.
The stations, transmitters and arrangements of pulses in LORAN-C were all designed to be redundant to failure of one component wouldn't shut down a station or the network.
Uber coders also know when to trash old code rather than update it to new standards. The culling of the herd to fit the available resources if often more important than keeping the sickly and poorly written code alive. It optimizes resource use for everybody: the code is smaller, less of it has to be maintained, etc. These skills are often overlooked as well since they are devlishly hard to measure.
This is absolutely critical for small companies to have. Otherwise the code grows faster than their ability to keep it up to date. They need more people doing more work than is necessary. This can push the small company over the edge of profitability (either there are too few people to do the work needed so sales suffer, or there's too few sales to support all the mouths needed to keep this extra code around).
Another trait of uber-coders is they have a global view. This global view often allows then do things much more efficiently because they know exactly the right level to do it. They don't have to do a lot of extra work "just in case" at the wrong layers. Poor programmers do the extra work and justify it as being careful, when they are only being wasteful to the project.
Large companies could benefit from these traits, but the way management is setup makes it difficult to properly measure these skills, reward the teams that practice them and to save the company money (which, in theory should be split between the company and the uber-coders). Sometimes the skills are recognized outside of the normal set of metrics, but often times they are not.
finally, if you think you are an uber-coder, it would be in your best interest to also be an uber-communicator. Not that you have to communicate a lot, but often times the right communications at the right times help more than huge reports that nobody does more than glance at anyway. The best prose for me often times is cut down by 1/2 from my initial drafts and 3/4 rewritten, but everybody is different. The uber-communication skills is what will get you noticed, promoted and have raises go your way. This is especially true if you can make other people more productive by merging the uber-coding and uber-communicating roles.
Even this article points out that btrfs isn't ready for production, while ZFS is in production systems today. How does that make brtfs better? Does it have a better license? Does it have more potential? Maybe. But that alone doesn't make it better today.
It all depends on what FreeNAS' target market is going to be. Is it going to be old desktop machines that people recycle into NAS boxes, or will it be the large variety of NAS boxes that are found in the wild today. If the former, then the switch to Linux buys you nothing. Really, FreeBSD and Linux run the same on x86 hardware (sometimes one is faster, or the other, or there's an issue that keeps one or the other from running, but in general both just work damn well). If the target is the latter, then Linux might have a small edge, but only because the FreeBSD project hasn't focused on the proper packaging of FreeBSD for an embedded system that has the tight memory constraints that the non-intel NAS boxes have. Many companies have climbed this hill, but there's nothing that's been standardized enough to be ready to include in FreeBSD (although both NanoBSD and TinyBSD could be made to work). M0m0wall and FreeNAS innovated in other areas, and this area would be easy to innovate in as well, since the problem is well understood and most of the tools necessary to make it work are already extant in the tree.
Forking FreeNAS may or may not be the right thing to do. It might be better to provide a FreeNAS 0.7 -> NewFreeNAS project that is rewritten from scratch for FreeBSD 8.0 that doesn't suffer from the php interface that replaces
Warner
I've been involved in an open source project (FreeBSD) for a long time. There have been a number of complaints about GPL violations in the past. These complaints are usually made in private. That helps a lot. Often times the compaints are wrong (The GPL code that was alleged to have been taken and improperly included in FreeBSD turned out to have been taken from BSD 4.4lite and incorporated into the GPL code was the worst example). There have also been cases where the same code appeared in drivers in multiple places. Again, that wasn't a GPL violation because both places took the code from a common data sheet. Sometimes supposed violations are cleaned up out of an abundance of caution: it isn't clear the code is improperly included, but the code in question is easy to rewrite and/or icky to start with.
There are also times where GPL code is improperly imported code from BSD as well. Even when these are found it isn't always worth it to complain. Sometimes the gain from complaining is so small that it is easier to just let the folks use the code and not worry too much about it. Sometimes having the code out there and improperly licensed is better than getting it removed from the code base.
In general, I've found that most people that aren't lawyers don't know the law or the provenance of the code very well. By complaining in private, you get a chance to learn a bit about both. You also give people a chance to make it right. With large open source projects, the chances for accidental mistakes are high. The projects are generally keen to avoid the mistakes in the first place, and even keener on making sure that they get ironed out after the facts. Turns out most companies have a similar view and will do the right thing when asked (but sometimes it takes a little time, which is OK: the GPL never said instantly on demand).
Of course, this begs the question about the validity of the License to use GPL software after a violation has occurred, the scope to which license is lost, how to get it back, etc. GPLv2 is silent on the issue, while GPLv3 gives you one shot to fix it (but that's likely insufficient for large companies that have multiple product lines done by disjoint sets of people all of whom aren't educated on the finer points of incorporating GPL software into their products).
The GPL has been held to be valid a number of times in a court of law in different countries. This is true. However, the lawyers didn't say it was invalid, so it is also irrelevant.
They said that it was unclear what is meant by derived work, and therefore it was unclear what could be licensed with a different license when combined with GPLv2 software, and what had to have a GPLv2 license. It all hinges, according to them, on if one takes an expansive view or a narrow view reading of the independent work clause. This is something that's very much up in the air right now, with many people playing fast and loose with the rules. You have a continuum of behavior here. Everything from "I wrote this file, therefore I don't have to license it under the GPL, even though it is linked into the kernel" to "I GPL'd the shims to my proprietary driver, but not the driver itself." The authors point out it is unclear how much of this behavior is safe and how much isn't. The ambiguity and shifting attitudes about what is and is not a derived work creates risk and uncertainty when using this license.
They claim GPLv3 doesn't suffer from these weaknesses.
Nowhere to do they claim the GPLv2 is not legally valid. Just that ambiguity exists,
Marriage is the triumph of imagination over intelligence. Second marriage is the triumph of hope over experience.
