Except users will no longer have the freedom to build DRM software using GPL'd code.
What is the difference between the GPL and the modified BSD license, or the MIT license? Some groups claim that the latter two licenses are more free than the GPL. In one sense, they are correct. The GPL puts certain restrictions on redistribution, whereas the other two licenses put virtually no restrictions.
You are correct that RMS has previously argued that there should be no "anti-suchandsuch" political clauses in the GPL. RMS believes that users should be free to do anything with the software. Thus, your view is correct, but not complete!
In fact, RMS has always stated that users should be free to do anything with the software, except restrict other users' freedom to do anything with the software. That was the whole point of the restrictions in the GPLv2.
When you look at it in this light, you realize that forbidding effective DRM is in fact consistent with the philosophical aims of the GPLv2, because DRM is nothing more than a way of restricting a user's freedom to do whatever he wants with the software. However, this draft of GPLv3 makes this explicit, because DRM-protecting laws like the DMCA have become so dangerous to Free Software.
Furthermore, your basic premise is in fact false. This draft of GPLv3 still allows programmers to write software that encodes or decodes DRM-wrapped file formats. However, this draft of GPLv3 legally defines any such software as not "an effective technological protection measure". These words have a specific legal meaning. The DMCA legally forbids a user from circumventing an effective technological protection measure; as such, if a piece of GPLv2 software implements a DRM-wrapper, it would be illegal under the DMCA to modify the software, even though the GPLv2 otherwise grants you that right. With this draft of the GPLv3, by defining the software legally as not "an effective technological protection measure" the DMCA will never be invoked, and the user is free to excersize his freedom by modifying the software.
What is your market? What is your company name and your application?
Your story sounds interesting, but why have you gone out of your way to avoid giving any specific details. I would have assumed you would make use of the oppurtunity for some free publicity. I am sure that we, the (non-existant;-) community would love to hear about another project that will free companies from obnoxious and expensive proprietary software.
Note: When I refer to language, I mean the syntax and semantics and primitive types. When I refer to environment, I refer to the language plus any standard libraries; I am not refering to a particular VM. I think my definitions may be the source of some of the confusion, as Sun appears to want everyone to think that the java.* and javax.* libraries are part of the language. As far as I am concerned, they are just part of the standard environment. (I bend my own definition a little to include packages under the java.lang library as being part of the language, because they are object-oriented wrappers for the primitive types.)
Your original post mentioned work by Aonix on hard real-time Java. My post referred to Java features that are not able to be used in hard real-time applications. Here is my reference; granted it's a year old, but I haven't found anything newer to contradict it. The author is (or was at the time of writing) in charge of the Aonix real-time JVM.
Note the table of differences between traditional Java, soft real-time Java, hard real-time Java, and safety-critical Java. As you can see, hard real-time and safety-critical Java are highly restricted compared to traditional Java. Safety-critical is a subset of hard real-time that is even more strict; it requires formal proofs of safety and therefore throws out most Java features and standard libraries, leaving only the core syntax and single-threaded semantics of the language. (Well technically, safety-critical allows multiple threads but they cannot overlap, so its like single threaded programming for purposes of proofs.) Safety critical requirements are defined by FAA specification DO-178B and several JVM suppliers are working on DO-178B-compliant JVMs.
Soft real-time applications can use all (or almost all) of the Java standard libraries, whereas hard real-time applications can use only a restricted subset of the standard libraries and safety-critical applications are restricted to an even smaller subset of the standard libraries. Therefore, one great advantage of the Java environment (remember my definition of environment), its extensive standard library, is neutralized with respect to hard real-time and safety-critical applications.
Furthermore, almost all third party libraries depend on standard libraries that are forbidden under hard real-time or safety critical constraints. Therefore, these libraries are also forbidden and another great advantage of the Java environment (remember my definition of environment), the extensive field of third-party libraries, is lost to hard real-time and safety-critical applications.
The Real-Time Specification for Java defines a set of library calls and semantics which, when implemented within a general-purpose Java virtual machine.... [snip] In fact, Sun demonstrated a real-time Java application running alongside non-real-time applications on the same VM. > Note the emphasis on the word "within". Applications that implement real-time features get the JVM+RTS. Applications that do not implement real-time features fall through to use the traditional JVM. However, non-real-time applications do not automatically become real-time applications simply by being run on Java RTS. Nothing here contradicts my original assertions.
I'd like to know more about the real-time application they demonstrated. What kind of real-time application was it: soft or hard? Did you see the source code of the real-time application? If so, what libraries did it use? The link you provided didn't provide much concrete information. However, it did provide a link to Sun's official Java RTS page:
I fully agree with you that the Java language is capable of efficient real-time use. However, I think that everyone needs to be perfectly crystal clear that the Java environment to which most Java developers are accustomed is not.
Hard real-time Java programming is vastly different from normal Java programming. Most of the standard Java class libraries are gone. Exception handling is gone. Automatic garbage collection is gone. Almost all third party class libraries are gone. Coding hard real-time apps in Java feels very much like coding C apps from scratch, even if you don't have to manually allocate and deallocate blocks of memory. From the article:
JRTK, a hard-real-time mission-critical subset of the Real-Time Specification for Java (RTSJ) as defined by the Java Community Process, includes many efficiencies over standard Java offerings. No garbage collection is used on objects in the real-time heap. A standard subset of Java libraries is restricted with each library's time and memory resources clearly defined. Partitioning clearly separates soft real-time components from hard-real-time components to ensure hard-real-time schedules as well as program reliability and robustness.
I guess my point is this: hard real-time Java is not the Java with which 99.9% of so-called Java developers are familiar. Choosing Java over C or Ada for a hard real-time system will not enable you to hire lesser programmers, nor will it significantly increase your pool of eligible employees. No matter which language you use, to do hard real-time systems correctly and effiently you must hire only top-tier programmers. Top-tier programmers can make use of any relevant language. Hire any lesser programmers and they will screw up, regardless of language choice.
Does anyone have a link to their archive of prior art, or any other listing of prior art for this patent? A cursory googling didn't turn up the results I was looking for.
I guess it took a few years before they built up a sufficiently strong case, as well as a sufficiently strong war chest to take on a corporate bully. Good luck to Pub Pat.
DRM diametrically opposed to Free/Open Software
on
Sun Spearheads Open DRM
·
· Score: 2, Interesting
Even assuming I don't object on moral grounds, (which I do, strongly) how would this even work?
Free Software can never implement any Digital Restrictions Management (DRM) technology. Why? Because, a piece of DRM-compatible software must take an encrypted content file, decrypt it, and pipe the output to a user interface such as a speaker or monitor. At the same time, the software must prevent the user, at any point in the above pipeline, from copying the unencrypted content to a file. This is a fundamental problem which all DRM schemes must solve. With Free Software or Open Source software any user can modify the source code so that the unencrypted content is saved to a file, thus breaking the DRM. Therefore, Free Software can never truly implement DRM. Conversely, any system which correctly implements DRM can never fully be Free Software.
I realize that Sun is talking about open standards, which are very different from Open Source or Free Software. However, their stated aim here is to make open standards which will allegedly be friendly to Open Source. However, I think I have already proven that this is bunk, because the concepts of DRM and Free Software/Open Source software are diametrically opposed.
On the other hand, I'm also concerned that these documentations might not be as in-depth as if they were written by the persons involved in these projects.
This may be a blessing in disguise. Often times, software developers do a poor job of writing manuals for their own software; they are simply "too close" to the project. Since they know the project too intimately, they assume that intimate knowledge is shared by users. End users should never be forced to learn implementation details of a program in order to use the program, and having documentation written by an outsider may help to make the documentation more task-focused and less detail focused.
An example is the case where a developer makes a program extremely flexible, usually configured manually through a needlessly complex and difficult to understand configuration file. (I won't name names to avoid embarassing anyonr, but this sounds like many open source projects.) The developer thinks nothing of the configuration process, because he understands all of the intimate details, so he writes a huge document describing every little feature and option. Due to the size and interconnectedness of the options, users typically find such documents impossible to understand. In many cases, most users want generally the same few features and are not interested in every option under the sun. (Once again, if you use open source extensively, you will know what I am taling about.) They generally find such focused and useful documentation written by someone without intimate knowledge of the program.
Also, outsiders will be less likely to forgive and shrug off defects in a program. For example, let's say program FOO has a bug whereby any file saved with a name greater than 8 characters causes FOO to fail to save the data. The lead programmer knows the technical reasons for this and the difficult/kludgy steps needed to correct it, so he simply writes in the documentation that users must remember to use names with fewer than 8 characters. On the other hand, a 3rd party documentation writer would not know this, so he would tell users that a bug existed in FOO with respect to file naming, and encourage the users to pressure the developer for a fix.
Finally, a little theory. In my Software Engineering courses, it is stressed as best practice to write documentation before ever writing one line of code. It is also stressed that when code was written first, (as is the case in almost every professional and open source project on which I have worked) a 3rd party should write documentation to avoid just the problems I have desribed.
Personally I think it would be a good idea to have a 'rerender' command next to 'reload' in the menu that just rerenders the page without downloading it.
I don't think any mainstream browser should go in for such a kludge. The fact that a rerender command is even needed is evidence of a software failure, and should not be painted over by a kludgy workaround. In a properly functioning browser, a page should never render differently by rerendering. If it does, that is evidence that something in the browser software is broken.
A good question. I assume all states have roughly the same process for casting absentee votes.
DISCLAIMER: I don't work for any election board. I am only taking an educated guess at the process based on my experience using absentee ballots.
When you vote with an absentee ballot, you cast your vote on the card, then seal it inside of an envelope. Then you sign a form letter saying that you really are you, and you put the form letter and the sealed envelope in another envelope and mail it in.
I am guessing that the absentee counting process goes as follows: The election board gets the ballot, they check that you were approved for absentee voting and check your name off the list, then pass the unopened inner envelope to another counter. That person, who has no idea whose envelope it is, opens it and counts the vote. And you effectively have anonymous absentee ballot counting.
Of course, we have to trust the ballot counters, but I would hope and assume there is pretty strict auditing of the process.
Under the GPL you are only entitled to the source if you got the binary. I would assume that once your subscription gets canceled, you will be unable to get new binary updates and hence you have no right to the source for those updates.
I would recommend Aldous Huxley's Brave New World and more importantly, his Brave New World Revisited, which is a non-fiction follow-on to BNW. Huxley shows that the longest lasting tyrannies are not those which control the population through intimidation, but that control the population through seemingly-benign mental manipulation.
Consumers (aka citizens) in Brave New World allow their government to rule over them absolutely because the government has trained them to do so. From a young age, consumers are taught to keep their minds on pleasure rather than politics. The basic necessities of life (food, shelter) are provided and drugs, entertainment and sex are so wildly abundant that no one would ever care about whatever the government might be doing. [This introduction alone should be sickeningly familiar to anyone who has ever tried to have a philosophical discussion with average Americans. (I don't mean to single out Americans, but they are the only people I've ever met, so I use them as examples;-)]
Only the absolute cream of the crop ever rise above this to become World Controllers. The few others who actually try to grow a political conscience and push for social change are sent away to isolated areas like remote islands where they are free to live their lives without "disturbing" the populace. On the surface, the world in Brave New World seems like a "nice" place to live but it is in fact one of the most horrible places I could imagine because not only is no one there truly free, but they have all forgotten even the meaning of freedom.
Huxley wrote Brave New World Revisited 25 years after BNW (1957 I think). It is a non-fictional work that explores the concepts underlying the tyrannies of both BNW and Orwell's 1984. For a book written almost 50 years ago, there are some startlingly prescient predictions. For example, here is a prediction he wrote about overpopulation and totalitarian rule. In this quote I am substituting only one word: "Russia" becomes "terrorists".
<snip>For the moment, overpopulation is not a direct threat to the personal freedom of Americans. It remains, however, an indirect threat, a menace at one remove. If over-population should drive the under-developed countries of the world into totalitarianism, and if these new dictatorships should ally themselves with
terrorists, then the military position of the United States would become less secure and the preparations for defense and retaliation would have to be intensified. But liberty, as we all know, cannot flourish in a country that is permanently on a war footing, or even a near war footing. Permanent crisis justifies permanent control of everybody and everything by the agencies of the central government.</snip>
I hope the applicability of that example is obvious. Tyrrany by intimidation will always fail because eventually people will determine that fighting is no worse than being pushed around. The longest lived dictatorships (called scientific dictatorships by Huxley for their application of the scientific method in determining how to rule) are those that rule the people by convincing the people that it is in their best interests to be so ruled.
I would highly recommend both Brave New World and Brave New World Revisited. Together they are only about 300 pages long (and can often be found published in the same volume) and are an extremely quick but worthwhile read.
Actually, it's not surprising Plan 9 came from AT&T. Plan 9 was AT&T's response to the shift from huge time-sharing systems to personal computer networks. Unix was designed for time sharing systems and its architecture really was not suited well for the PC revolution. Unfortunately, by the time Plan 9 started to be remotely usable, Unix vendors (and Linux) had gotten Unix ported well enough to PCs and had created a number of bolt-on networking technologies that did the things companies needed.
Plan 9 was a much more elegant fit for the PC environment (for companies), but it was too much of a revolution in both hardware and software system design and Unix was able to do the job well enough. Thus, Unix type systems have blown Plan 9 away in practical usefulness, despite an inferior architecture.
I really hate to get pedantic, but OpenSSL is Free Software. According to the Free Software Foundation, the OpenSSL license is a Free Software license incompatible with the GPL.
What you should have said is that the Free Software Foundation recommends developers use the GNU TLS library, but using OpenSSL in non-GPL projects is perfectly okay. Remember, GPL licensed software is only a subset of Free Software.
Plan 9 is a very interesting operating system. Its problem is that it was, and still is, too far ahead of its time. It throws away 30+ years of computer hardware and operating systems design for a network centric approach.
Like Unix style operating systems, Plan 9 makes all system resources available in a hierarchical namespace. However unlike the Unix file system, access to the namespace takes place at the network level. With this design, the physical location of a resource cannot be determined by the user. (The other interesting feature is that the namespace changes for each running process, but that is beyond the scope of this thread.)
Using the Plan 9 architecture, a "computer" is built by stringing together a network of file servers, processor servers, and terminals. Making the video device a 3D accelerated server would be a natural extension of this idea.
Of course, the devil is in the details. Plan 9 is not in wide use because it has very limited hardware and software support. Existing hardware and operating systems architectures are "good enough" for general purpose use, so hardware and software vendors see no need to develop for Plan 9 (think Linux 5-10 years ago).
Furthermore, though I have no experience with serious Plan 9 use, I doubt Plan 9 is optimized to the point where it could serve as the rival of a modern 3D accelerated graphics card for a comparable price. So, as outlined earlier in this thread, a good deal of research and development would still be required.
As time goes on, "traditional" operating systems like Linux and Windows are slowly, slowly taking on Plan 9 attributes like pseudo-network transparency. They do it in a kludgy, inferior way but (and this is the important bit) they maintain backward compatibility. Thus, I think it is increasingly unlikely that a pure architecture like Plan 9 will ever come into widespread use outside of a research lab.
I hope the moderators mod this up as interesting, because it certainly is. Very, very naive, but interesting none the less. Such a question implies that you are either a teenager or an ivory tower researcher;-) I hope you manage to keep your idealism.
The system you describe is a distributed operating system. Your hypothetical system has been contemplated by many researchers, perhaps most famously with AT&T's Plan 9. The problem with this, as with all other distributed operating systems, is that is still *very* theoretical and likely will be for some time.
For such a system, you will need a network connecting the two computers. I am assuming you want to go with commodity hardware for price reasons. To get adequate performance for modern graphics cards, as well as to leave room for new cards debuting in the next couple of years, you will need an extremely high speed physical layer. A 1Gbps ethernet bus would be the bare minimum now, and you would likely need to go up to 10Gbps to get good perfromance for today's high end cards or the cards of the next few years. A 1Gbps network is just becoming affordable for high end consumers, while a 10Gbps network is still far too expensive for consumers and likely will be for several years to come.
Next comes building the "graphics card emulating computer". While graphics cards are miniature PCs in an abstract sense, in actual implementation they are very different. I won't claim to fully understand the design of a modern graphics card, but the GPU processor and data bus are highly optimized for graphics handling tasks. You would therefore likely need a top of the line general purpose motherboard and CPU to emulate a modern card's performance. Once again, not an inexpensive thing.
Next come software issues. Assuming you actually hope for more than research lab adoption, you cannot force vendors to rewrite all of their low-level graphics routines. Concordantly, you will need to provide an emulation layer that makes X11 (or whatever graphics system(s) you target) think your graphics computer is just another onboard video card. This will likely require at least a kernel hack, if nothing else. You will probably also want to hack on the drivers of the network cards you use, to improve their performance (mostly reduce latency). This is probably the easiest of your software challenges.
For network transport, TCP will certainly be overkill. If you want to make this friendly to existing network protocols, you will have to design a UDP-based protocol, but even UDP might cause a performance hit. For best performance, you will likely end up ditching compatibility with TCP/IP type networks and programming directly to the data link layer. In any case, designing a quality protocol of this type is an extremely difficult task! Don't expect to get it right on the first few tries.
Last of the software challenges, the software on the graphics computer will have to be customized heavily to emulate the high performance operations provided by a graphics card. Unless you can manage to find an expert in 3D accelerated graphics hardware who is *not* under an NDA from one of the graphics card companies, this will require a lot of research.
Finally come non-technical hurdles. First, you have to worry about competing implementations. If your project builds steam, your team will likely start to face competition. This will inevitably lead to incompatibilities, which will have to be straightened out by some standards process. Add a couple of years to the total time for that.
Even if we assume that after years of research such a system is built and everyone actually standardizes on it, it will likely cost *much* more per unit than an equivalent graphics card. I just don't think that "freedom from lock-in" will be enough to successfully market this to John Q Public, and without that support, even geeks may find it hard to afford such a setup.
While this naively may seem like a good idea, it has enormous potential to blow up in your face.
By installing software on a computer-illiterate person's computer, you are implicitly taking *personal* responsibility for that computer, whether you want to or not. From that moment forward, that person will insist that you provide free technical support for them whenever you need it. Refuse this, and you will cast a bad light on open source. (ie: That Mozilla thing broke my Internet and no one will help me!) From experience, Murphy's law will go into effect, and any and every thing will go wrong.
Be wary whenever you offer to help someone with their computer. I have been so burnt out from helping so many people over the years that I refuse to help anyone, even family members, or even talk to them about computers.
Like it or not, open source cannot forever rely on legions of selfless geeks helping everyone. It's just not infinitely scalable. "Mainstream" open source projects like Mozilla, OpenOffice, etc need to 1) proactively focus on usability by recruiting (by paying if necessary) human-computer interface experts and focusing all development on usability and 2) forming political relationships with as many computer manufacturers, banks, and any other organizations we can to get our stuff in front of mainstream users. There is already some movement on these fronts, but it needs to be at least an order of magnitude greater.
One *huge* difference between Chrenobyl and TMI that people often forget to mention is that Chernobyl released tonnes and tonnes of radioactive material directly into the atmosphere, whereas TMI did not. The background radiation levels of the atmosphere were noticably (with radiation counting instruments) higher even hundreds of miles away from the reactor.
Contrast this with TMI. At the time, my high school Chemistry and Physics teacher lived less than 2 miles downwind of the plant, so naturally he was quite worried. He placed radiation detection badges around his neighborhood. (He was a civil defense neighborhood captain, or something. This was still during the Cold War;-) After monitoring and replacing them for months, he recorded no significant change above natural background radiation. For all intents and purposes, there was no release of radiation.
Technically speaking, there was some release of radiation. The reactor did not "blow" and there was no direct release of radiation. However, the fuel vessel did crack and release radioactive water into the reactor chamber, some of which evaporated into the atmosphere. However, as mentioned before, the amount of radiation was statistically insignificant.
The reason that Chernobyl blew up and TMI did not is a matter of reactor design. Briefly, all nuclear reactors need something called a "mederator" to allow nuclear reactions to happen. They also need a coolant to prevent overheating and meltdown.
The Soviet reactor used graphite (like in a pencil) for the moderator and water for the coolant. When the water circulation system malfunctioned, the reactor continued running full blast until it overheated and blew. America, on the other hand, uses a kind of reactor that used water for both moderator and coolant. Thus, when the water circulation system malfuctioned, the reactor overheated, but there was not enough water to allow it to keep running full blast, and hence it only cracked the vessel rather than blowing it up.
Also, the Soviet reactor was housed in only a cheap warehouse building, whereas American reactors are stored in 7-12 meter thick reinforced concrete domes. Chances are good that such a dome would have held the blast of even a Chernobyl reactor.
So there are definitely major differences between Chernobyl and TMI.
No: Re:Red Hat violating the GPL!?
on
Red Hat Recap
·
· Score: 2, Insightful
Your assumption seems to be unduly alarmist. Here is my understanding of what Red Hat has done, based on reading their publications and talking with their representatives:
Red Hat's support contract is the means they use to restrict you from installing the RHEL binary distribution on multiple machines. When you purchase the RHEL package, you are essentially buying a support contract for one machine, and getting a gratis RHEL distribution with it. Part of the support contract says that you agree to put that copy of the distro on only that one machine. Put it on multiple machines, and you invalidate your support contract, but nothing more; you still have the right to use the distro thanks to the GPL, but don't expect Red Hat to help you with it at all. Therefore, this is not technically a violation of the GPL, because the only thing you lose by invalidating the support contract is your right to get support.
This support contract change was done in response to the common practice of installing RHL on 100 machines, buying support for one machine, then changing the supported machine every time a problem occurred. As far as I am concerned, the tactic is reasonable. As to whether the specific price points are unreasonable, that will be decided by the market.
You misunderstand it slightly. If you buy one copy and install it on a zillion machines, not only can you not expect zillion-machine level support, but you can't expect *any* support.
Their support contract says that if you want support on any one machine, you must buy support for all machines you have running RHEL. In order to get support for a machine, you must give them the right to inspect your facilities to make sure you have a support contract for all machines running RHEL. That is what everyone is in an uproar over.
Red Hat's reason for doing this is to prevent people from buying support for one machine, installing RHEL on 100 machines, then switching which machine is "supported" to the one machine having a problem every time there is a problem. This was a common practice where I worked (and I suspect in a lot of other places too) prior to their support contract change.
This policy is not technically a violation of the GPL, as the per-machine fee relates to support, not to software. If you forego the right to support, you can install on as many machines as you want. Of course, if you don't want Red Hat's support, you might as well go with another distro, such as White Box, Mandrake, or Debian.
Yes, mplayer supports WMF without DRM, but does it support WMF with DRM? I have never accessed a MLB stream, so I don't know if they use DRM, or if mplayer can or cannot play them. Anyone else here know whether mplayer can access DRMed WMF files?
When they refer to market share for a streaming meadia format, I am assuming they are making some kind of estimate of the per cent of all streaming media traffic that is of format X.
For example, if 100 media streams passed through a monitor node during a given time period, and 34 of them were WMF, 19 were RM, you could say that MS had 34% market share and Real had 19% market share. This figure gives a rough estimate of the popularity of each media format.
How do demo Mozilla (or any other OSS replacement package) with people who are afraid of change? Case in point: My uncle would not allow me to install Mozilla on his computer because he was afraid that "it will mess things up." (He is running WinME with whatever version of IE is pushed out by Windows update.) I tried my best to explain to him that Mozilla would not mess up his system, and if he didn't like Mozilla he could just ignore it and keep using IE, or uninstall it. He knows I am a computer expert, but he just would not believe me. His last experience with installing a web browser was installing IE4 on Windows 95, and no matter how I tried to explain it, he was just too scared that it would screw up his computer.
He is not the only person I know like this. Most simple computer users I know manage to get their systems into a (just barely) working state, then forevermore are frightened of changing it, except to add games, until they buy a new computer.
So we have a chicken-and-egg problem. Most people won't bother to use Mozilla every day unless they try it out first. However, most people are so frightened of installing new non-game software that they will not install it to try it.
Maybe what we need to do is to get some major game manufacturer like Id or Blizzard (forget OSS games -- too small a market share to do any good) to package Mozilla and install it by default with all new games. That way, it will sneak Mozilla onto the systems of those who would be too frightened to use it otherwise.
Search on Mozilla's bugzilla database. You will find it listed as a bug. Of course, you will also find considerable debate about whether it should be removed, as so many people like you have accustommed themselves to it. So unfortunately, you will probably get your wish, as this bug will probably not get fixed unless some strong leader takes over that module and makes a non-democratic decision. (unlikely)
However, consider it from a design purity angle rather than the user-1337 trick angle. A user is cutting and pasting values into a web based form. The user acidentally misses the form box by a couple of pixels. BAM! Mozilla clobbers the user's form by loading a new page which it interprets from whatever data the user accidentally pasted. On many pages, particularly secure pages, when the user clicks back, the form data is erased, which is an extremely *major* annoyance.
What you are referring to is a bug in Mozilla's Gecko Runtime Engine. It is not a feature! It is not documented behavior (other than in the bugzilla database) and it should be removed. You should not become accustomed to using it, because hopefully one day, it will be eliminated.
I don't get why you people seem to think that Red Hat is ending its free distro. They are merely renaming it, and if anything changes, they are making it better!
Red Hat always makes a nicely integrated and polished distro, but the biggest problems are that there are 1) not enough different packages available; 2) it takes too long for new versions of apps (particularly GUI apps) to make their way into official release and; 3) it's too hard to hard to upgrade. Fedora fixes #1 by increasing community participation so that volunteers can add official packages in addition to the core packages provided by Red Hat. Because Red Hat no longer has to worry about businesses trying to use the free distro as a production distro, #2 gets fixed automatically. (Those businesses who demand 18 month feature freezes can pay for RHEL or use at their own risk.) Problem #3 is fixed by moving over to yum or apt repositories.
Slashdot Mirror
Except users will no longer have the freedom to build DRM software using GPL'd code.
What is the difference between the GPL and the modified BSD license, or the MIT license? Some groups claim that the latter two licenses are more free than the GPL. In one sense, they are correct. The GPL puts certain restrictions on redistribution, whereas the other two licenses put virtually no restrictions.
You are correct that RMS has previously argued that there should be no "anti-suchandsuch" political clauses in the GPL. RMS believes that users should be free to do anything with the software. Thus, your view is correct, but not complete!
In fact, RMS has always stated that users should be free to do anything with the software, except restrict other users' freedom to do anything with the software. That was the whole point of the restrictions in the GPLv2.
When you look at it in this light, you realize that forbidding effective DRM is in fact consistent with the philosophical aims of the GPLv2, because DRM is nothing more than a way of restricting a user's freedom to do whatever he wants with the software. However, this draft of GPLv3 makes this explicit, because DRM-protecting laws like the DMCA have become so dangerous to Free Software.
Furthermore, your basic premise is in fact false. This draft of GPLv3 still allows programmers to write software that encodes or decodes DRM-wrapped file formats. However, this draft of GPLv3 legally defines any such software as not "an effective technological protection measure". These words have a specific legal meaning. The DMCA legally forbids a user from circumventing an effective technological protection measure; as such, if a piece of GPLv2 software implements a DRM-wrapper, it would be illegal under the DMCA to modify the software, even though the GPLv2 otherwise grants you that right. With this draft of the GPLv3, by defining the software legally as not "an effective technological protection measure" the DMCA will never be invoked, and the user is free to excersize his freedom by modifying the software.
What is your market? What is your company name and your application?
;-) community would love to hear about another project that will free companies from obnoxious and expensive proprietary software.
Your story sounds interesting, but why have you gone out of your way to avoid giving any specific details. I would have assumed you would make use of the oppurtunity for some free publicity. I am sure that we, the (non-existant
Note: When I refer to language, I mean the syntax and semantics and primitive types. When I refer to environment, I refer to the language plus any standard libraries; I am not refering to a particular VM. I think my definitions may be the source of some of the confusion, as Sun appears to want everyone to think that the java.* and javax.* libraries are part of the language. As far as I am concerned, they are just part of the standard environment. (I bend my own definition a little to include packages under the java.lang library as being part of the language, because they are object-oriented wrappers for the primitive types.)
Your original post mentioned work by Aonix on hard real-time Java. My post referred to Java features that are not able to be used in hard real-time applications. Here is my reference; granted it's a year old, but I haven't found anything newer to contradict it. The author is (or was at the time of writing) in charge of the Aonix real-time JVM.
http://www.stsc.hill.af.mil/crosstalk/2004/12/0412 Nilsen.html
Note the table of differences between traditional Java, soft real-time Java, hard real-time Java, and safety-critical Java. As you can see, hard real-time and safety-critical Java are highly restricted compared to traditional Java. Safety-critical is a subset of hard real-time that is even more strict; it requires formal proofs of safety and therefore throws out most Java features and standard libraries, leaving only the core syntax and single-threaded semantics of the language. (Well technically, safety-critical allows multiple threads but they cannot overlap, so its like single threaded programming for purposes of proofs.) Safety critical requirements are defined by FAA specification DO-178B and several JVM suppliers are working on DO-178B-compliant JVMs.
Soft real-time applications can use all (or almost all) of the Java standard libraries, whereas hard real-time applications can use only a restricted subset of the standard libraries and safety-critical applications are restricted to an even smaller subset of the standard libraries. Therefore, one great advantage of the Java environment (remember my definition of environment), its extensive standard library, is neutralized with respect to hard real-time and safety-critical applications.
Furthermore, almost all third party libraries depend on standard libraries that are forbidden under hard real-time or safety critical constraints. Therefore, these libraries are also forbidden and another great advantage of the Java environment (remember my definition of environment), the extensive field of third-party libraries, is lost to hard real-time and safety-critical applications.
The Real-Time Specification for Java defines a set of library calls and semantics which, when implemented within a general-purpose Java virtual machine.... [snip] In fact, Sun demonstrated a real-time Java application running alongside non-real-time applications on the same VM. > Note the emphasis on the word "within". Applications that implement real-time features get the JVM+RTS. Applications that do not implement real-time features fall through to use the traditional JVM. However, non-real-time applications do not automatically become real-time applications simply by being run on Java RTS. Nothing here contradicts my original assertions.
I'd like to know more about the real-time application they demonstrated. What kind of real-time application was it: soft or hard? Did you see the source code of the real-time application? If so, what libraries did it use? The link you provided didn't provide much concrete information. However, it did provide a link to Sun's official Java RTS page:
http://java.sun.com/j2se/realtime/
I am not sure how they can claim conformance for soft real-time, because they do not yet provide a real-ti
Hard real-time Java programming is vastly different from normal Java programming. Most of the standard Java class libraries are gone. Exception handling is gone. Automatic garbage collection is gone. Almost all third party class libraries are gone. Coding hard real-time apps in Java feels very much like coding C apps from scratch, even if you don't have to manually allocate and deallocate blocks of memory. From the article:
I guess my point is this: hard real-time Java is not the Java with which 99.9% of so-called Java developers are familiar. Choosing Java over C or Ada for a hard real-time system will not enable you to hire lesser programmers, nor will it significantly increase your pool of eligible employees. No matter which language you use, to do hard real-time systems correctly and effiently you must hire only top-tier programmers. Top-tier programmers can make use of any relevant language. Hire any lesser programmers and they will screw up, regardless of language choice.
This first came out in 2002.
http://www.jpeg.org/newsrel1.html
Does anyone have a link to their archive of prior art, or any other listing of prior art for this patent? A cursory googling didn't turn up the results I was looking for.
I guess it took a few years before they built up a sufficiently strong case, as well as a sufficiently strong war chest to take on a corporate bully. Good luck to Pub Pat.
Even assuming I don't object on moral grounds, (which I do, strongly) how would this even work?
Free Software can never implement any Digital Restrictions Management (DRM) technology. Why? Because, a piece of DRM-compatible software must take an encrypted content file, decrypt it, and pipe the output to a user interface such as a speaker or monitor. At the same time, the software must prevent the user, at any point in the above pipeline, from copying the unencrypted content to a file. This is a fundamental problem which all DRM schemes must solve. With Free Software or Open Source software any user can modify the source code so that the unencrypted content is saved to a file, thus breaking the DRM. Therefore, Free Software can never truly implement DRM. Conversely, any system which correctly implements DRM can never fully be Free Software.
I realize that Sun is talking about open standards, which are very different from Open Source or Free Software. However, their stated aim here is to make open standards which will allegedly be friendly to Open Source. However, I think I have already proven that this is bunk, because the concepts of DRM and Free Software/Open Source software are diametrically opposed.
Therefore, what is Sun's real goal here?
On the other hand, I'm also concerned that these documentations might not be as in-depth as if they were written by the persons involved in these projects.
This may be a blessing in disguise. Often times, software developers do a poor job of writing manuals for their own software; they are simply "too close" to the project. Since they know the project too intimately, they assume that intimate knowledge is shared by users. End users should never be forced to learn implementation details of a program in order to use the program, and having documentation written by an outsider may help to make the documentation more task-focused and less detail focused.
An example is the case where a developer makes a program extremely flexible, usually configured manually through a needlessly complex and difficult to understand configuration file. (I won't name names to avoid embarassing anyonr, but this sounds like many open source projects.) The developer thinks nothing of the configuration process, because he understands all of the intimate details, so he writes a huge document describing every little feature and option. Due to the size and interconnectedness of the options, users typically find such documents impossible to understand. In many cases, most users want generally the same few features and are not interested in every option under the sun. (Once again, if you use open source extensively, you will know what I am taling about.) They generally find such focused and useful documentation written by someone without intimate knowledge of the program.
Also, outsiders will be less likely to forgive and shrug off defects in a program. For example, let's say program FOO has a bug whereby any file saved with a name greater than 8 characters causes FOO to fail to save the data. The lead programmer knows the technical reasons for this and the difficult/kludgy steps needed to correct it, so he simply writes in the documentation that users must remember to use names with fewer than 8 characters. On the other hand, a 3rd party documentation writer would not know this, so he would tell users that a bug existed in FOO with respect to file naming, and encourage the users to pressure the developer for a fix.
Finally, a little theory. In my Software Engineering courses, it is stressed as best practice to write documentation before ever writing one line of code. It is also stressed that when code was written first, (as is the case in almost every professional and open source project on which I have worked) a 3rd party should write documentation to avoid just the problems I have desribed.
Personally I think it would be a good idea to have a 'rerender' command next to 'reload' in the menu that just rerenders the page without downloading it.
I don't think any mainstream browser should go in for such a kludge. The fact that a rerender command is even needed is evidence of a software failure, and should not be painted over by a kludgy workaround. In a properly functioning browser, a page should never render differently by rerendering. If it does, that is evidence that something in the browser software is broken.
And how do you keep absentee ballots anonymous?
A good question. I assume all states have roughly the same process for casting absentee votes.
DISCLAIMER: I don't work for any election board. I am only taking an educated guess at the process based on my experience using absentee ballots.
When you vote with an absentee ballot, you cast your vote on the card, then seal it inside of an envelope. Then you sign a form letter saying that you really are you, and you put the form letter and the sealed envelope in another envelope and mail it in.
I am guessing that the absentee counting process goes as follows: The election board gets the ballot, they check that you were approved for absentee voting and check your name off the list, then pass the unopened inner envelope to another counter. That person, who has no idea whose envelope it is, opens it and counts the vote. And you effectively have anonymous absentee ballot counting.
Of course, we have to trust the ballot counters, but I would hope and assume there is pretty strict auditing of the process.
Under the GPL you are only entitled to the source if you got the binary. I would assume that once your subscription gets canceled, you will be unable to get new binary updates and hence you have no right to the source for those updates.
Consumers (aka citizens) in Brave New World allow their government to rule over them absolutely because the government has trained them to do so. From a young age, consumers are taught to keep their minds on pleasure rather than politics. The basic necessities of life (food, shelter) are provided and drugs, entertainment and sex are so wildly abundant that no one would ever care about whatever the government might be doing. [This introduction alone should be sickeningly familiar to anyone who has ever tried to have a philosophical discussion with average Americans. (I don't mean to single out Americans, but they are the only people I've ever met, so I use them as examples
Only the absolute cream of the crop ever rise above this to become World Controllers. The few others who actually try to grow a political conscience and push for social change are sent away to isolated areas like remote islands where they are free to live their lives without "disturbing" the populace. On the surface, the world in Brave New World seems like a "nice" place to live but it is in fact one of the most horrible places I could imagine because not only is no one there truly free, but they have all forgotten even the meaning of freedom.
Huxley wrote Brave New World Revisited 25 years after BNW (1957 I think). It is a non-fictional work that explores the concepts underlying the tyrannies of both BNW and Orwell's 1984. For a book written almost 50 years ago, there are some startlingly prescient predictions. For example, here is a prediction he wrote about overpopulation and totalitarian rule. In this quote I am substituting only one word: "Russia" becomes "terrorists".
I hope the applicability of that example is obvious. Tyrrany by intimidation will always fail because eventually people will determine that fighting is no worse than being pushed around. The longest lived dictatorships (called scientific dictatorships by Huxley for their application of the scientific method in determining how to rule) are those that rule the people by convincing the people that it is in their best interests to be so ruled.
I would highly recommend both Brave New World and Brave New World Revisited. Together they are only about 300 pages long (and can often be found published in the same volume) and are an extremely quick but worthwhile read.
Actually, it's not surprising Plan 9 came from AT&T. Plan 9 was AT&T's response to the shift from huge time-sharing systems to personal computer networks. Unix was designed for time sharing systems and its architecture really was not suited well for the PC revolution. Unfortunately, by the time Plan 9 started to be remotely usable, Unix vendors (and Linux) had gotten Unix ported well enough to PCs and had created a number of bolt-on networking technologies that did the things companies needed.
Plan 9 was a much more elegant fit for the PC environment (for companies), but it was too much of a revolution in both hardware and software system design and Unix was able to do the job well enough. Thus, Unix type systems have blown Plan 9 away in practical usefulness, despite an inferior architecture.
I really hate to get pedantic, but OpenSSL is Free Software. According to the Free Software Foundation, the OpenSSL license is a Free Software license incompatible with the GPL.
What you should have said is that the Free Software Foundation recommends developers use the GNU TLS library, but using OpenSSL in non-GPL projects is perfectly okay. Remember, GPL licensed software is only a subset of Free Software.
Plan 9 is a very interesting operating system. Its problem is that it was, and still is, too far ahead of its time. It throws away 30+ years of computer hardware and operating systems design for a network centric approach.
Like Unix style operating systems, Plan 9 makes all system resources available in a hierarchical namespace. However unlike the Unix file system, access to the namespace takes place at the network level. With this design, the physical location of a resource cannot be determined by the user. (The other interesting feature is that the namespace changes for each running process, but that is beyond the scope of this thread.)
Using the Plan 9 architecture, a "computer" is built by stringing together a network of file servers, processor servers, and terminals. Making the video device a 3D accelerated server would be a natural extension of this idea.
Of course, the devil is in the details. Plan 9 is not in wide use because it has very limited hardware and software support. Existing hardware and operating systems architectures are "good enough" for general purpose use, so hardware and software vendors see no need to develop for Plan 9 (think Linux 5-10 years ago).
Furthermore, though I have no experience with serious Plan 9 use, I doubt Plan 9 is optimized to the point where it could serve as the rival of a modern 3D accelerated graphics card for a comparable price. So, as outlined earlier in this thread, a good deal of research and development would still be required.
As time goes on, "traditional" operating systems like Linux and Windows are slowly, slowly taking on Plan 9 attributes like pseudo-network transparency. They do it in a kludgy, inferior way but (and this is the important bit) they maintain backward compatibility. Thus, I think it is increasingly unlikely that a pure architecture like Plan 9 will ever come into widespread use outside of a research lab.
I hope the moderators mod this up as interesting, because it certainly is. Very, very naive, but interesting none the less. Such a question implies that you are either a teenager or an ivory tower researcher ;-) I hope you manage to keep your idealism.
The system you describe is a distributed operating system. Your hypothetical system has been contemplated by many researchers, perhaps most famously with AT&T's Plan 9. The problem with this, as with all other distributed operating systems, is that is still *very* theoretical and likely will be for some time.
For such a system, you will need a network connecting the two computers. I am assuming you want to go with commodity hardware for price reasons. To get adequate performance for modern graphics cards, as well as to leave room for new cards debuting in the next couple of years, you will need an extremely high speed physical layer. A 1Gbps ethernet bus would be the bare minimum now, and you would likely need to go up to 10Gbps to get good perfromance for today's high end cards or the cards of the next few years. A 1Gbps network is just becoming affordable for high end consumers, while a 10Gbps network is still far too expensive for consumers and likely will be for several years to come.
Next comes building the "graphics card emulating computer". While graphics cards are miniature PCs in an abstract sense, in actual implementation they are very different. I won't claim to fully understand the design of a modern graphics card, but the GPU processor and data bus are highly optimized for graphics handling tasks. You would therefore likely need a top of the line general purpose motherboard and CPU to emulate a modern card's performance. Once again, not an inexpensive thing.
Next come software issues. Assuming you actually hope for more than research lab adoption, you cannot force vendors to rewrite all of their low-level graphics routines. Concordantly, you will need to provide an emulation layer that makes X11 (or whatever graphics system(s) you target) think your graphics computer is just another onboard video card. This will likely require at least a kernel hack, if nothing else. You will probably also want to hack on the drivers of the network cards you use, to improve their performance (mostly reduce latency). This is probably the easiest of your software challenges.
For network transport, TCP will certainly be overkill. If you want to make this friendly to existing network protocols, you will have to design a UDP-based protocol, but even UDP might cause a performance hit. For best performance, you will likely end up ditching compatibility with TCP/IP type networks and programming directly to the data link layer. In any case, designing a quality protocol of this type is an extremely difficult task! Don't expect to get it right on the first few tries.
Last of the software challenges, the software on the graphics computer will have to be customized heavily to emulate the high performance operations provided by a graphics card. Unless you can manage to find an expert in 3D accelerated graphics hardware who is *not* under an NDA from one of the graphics card companies, this will require a lot of research.
Finally come non-technical hurdles. First, you have to worry about competing implementations. If your project builds steam, your team will likely start to face competition. This will inevitably lead to incompatibilities, which will have to be straightened out by some standards process. Add a couple of years to the total time for that.
Even if we assume that after years of research such a system is built and everyone actually standardizes on it, it will likely cost *much* more per unit than an equivalent graphics card. I just don't think that "freedom from lock-in" will be enough to successfully market this to John Q Public, and without that support, even geeks may find it hard to afford such a setup.
In conclusion, what you suggest is
While this naively may seem like a good idea, it has enormous potential to blow up in your face.
By installing software on a computer-illiterate person's computer, you are implicitly taking *personal* responsibility for that computer, whether you want to or not. From that moment forward, that person will insist that you provide free technical support for them whenever you need it. Refuse this, and you will cast a bad light on open source. (ie: That Mozilla thing broke my Internet and no one will help me!) From experience, Murphy's law will go into effect, and any and every thing will go wrong.
Be wary whenever you offer to help someone with their computer. I have been so burnt out from helping so many people over the years that I refuse to help anyone, even family members, or even talk to them about computers.
Like it or not, open source cannot forever rely on legions of selfless geeks helping everyone. It's just not infinitely scalable. "Mainstream" open source projects like Mozilla, OpenOffice, etc need to 1) proactively focus on usability by recruiting (by paying if necessary) human-computer interface experts and focusing all development on usability and 2) forming political relationships with as many computer manufacturers, banks, and any other organizations we can to get our stuff in front of mainstream users. There is already some movement on these fronts, but it needs to be at least an order of magnitude greater.
One *huge* difference between Chrenobyl and TMI that people often forget to mention is that Chernobyl released tonnes and tonnes of radioactive material directly into the atmosphere, whereas TMI did not. The background radiation levels of the atmosphere were noticably (with radiation counting instruments) higher even hundreds of miles away from the reactor.
;-) After monitoring and replacing them for months, he recorded no significant change above natural background radiation. For all intents and purposes, there was no release of radiation.
Contrast this with TMI. At the time, my high school Chemistry and Physics teacher lived less than 2 miles downwind of the plant, so naturally he was quite worried. He placed radiation detection badges around his neighborhood. (He was a civil defense neighborhood captain, or something. This was still during the Cold War
Technically speaking, there was some release of radiation. The reactor did not "blow" and there was no direct release of radiation. However, the fuel vessel did crack and release radioactive water into the reactor chamber, some of which evaporated into the atmosphere. However, as mentioned before, the amount of radiation was statistically insignificant.
The reason that Chernobyl blew up and TMI did not is a matter of reactor design. Briefly, all nuclear reactors need something called a "mederator" to allow nuclear reactions to happen. They also need a coolant to prevent overheating and meltdown.
The Soviet reactor used graphite (like in a pencil) for the moderator and water for the coolant. When the water circulation system malfunctioned, the reactor continued running full blast until it overheated and blew. America, on the other hand, uses a kind of reactor that used water for both moderator and coolant. Thus, when the water circulation system malfuctioned, the reactor overheated, but there was not enough water to allow it to keep running full blast, and hence it only cracked the vessel rather than blowing it up.
Also, the Soviet reactor was housed in only a cheap warehouse building, whereas American reactors are stored in 7-12 meter thick reinforced concrete domes. Chances are good that such a dome would have held the blast of even a Chernobyl reactor.
So there are definitely major differences between Chernobyl and TMI.
Your assumption seems to be unduly alarmist. Here is my understanding of what Red Hat has done, based on reading their publications and talking with their representatives:
Red Hat's support contract is the means they use to restrict you from installing the RHEL binary distribution on multiple machines. When you purchase the RHEL package, you are essentially buying a support contract for one machine, and getting a gratis RHEL distribution with it. Part of the support contract says that you agree to put that copy of the distro on only that one machine. Put it on multiple machines, and you invalidate your support contract, but nothing more; you still have the right to use the distro thanks to the GPL, but don't expect Red Hat to help you with it at all. Therefore, this is not technically a violation of the GPL, because the only thing you lose by invalidating the support contract is your right to get support.
This support contract change was done in response to the common practice of installing RHL on 100 machines, buying support for one machine, then changing the supported machine every time a problem occurred. As far as I am concerned, the tactic is reasonable. As to whether the specific price points are unreasonable, that will be decided by the market.
You misunderstand it slightly. If you buy one copy and install it on a zillion machines, not only can you not expect zillion-machine level support, but you can't expect *any* support.
Their support contract says that if you want support on any one machine, you must buy support for all machines you have running RHEL. In order to get support for a machine, you must give them the right to inspect your facilities to make sure you have a support contract for all machines running RHEL. That is what everyone is in an uproar over.
Red Hat's reason for doing this is to prevent people from buying support for one machine, installing RHEL on 100 machines, then switching which machine is "supported" to the one machine having a problem every time there is a problem. This was a common practice where I worked (and I suspect in a lot of other places too) prior to their support contract change.
This policy is not technically a violation of the GPL, as the per-machine fee relates to support, not to software. If you forego the right to support, you can install on as many machines as you want. Of course, if you don't want Red Hat's support, you might as well go with another distro, such as White Box, Mandrake, or Debian.
Yes, mplayer supports WMF without DRM, but does it support WMF with DRM? I have never accessed a MLB stream, so I don't know if they use DRM, or if mplayer can or cannot play them. Anyone else here know whether mplayer can access DRMed WMF files?
When they refer to market share for a streaming meadia format, I am assuming they are making some kind of estimate of the per cent of all streaming media traffic that is of format X.
For example, if 100 media streams passed through a monitor node during a given time period, and 34 of them were WMF, 19 were RM, you could say that MS had 34% market share and Real had 19% market share. This figure gives a rough estimate of the popularity of each media format.
How do demo Mozilla (or any other OSS replacement package) with people who are afraid of change? Case in point: My uncle would not allow me to install Mozilla on his computer because he was afraid that "it will mess things up." (He is running WinME with whatever version of IE is pushed out by Windows update.) I tried my best to explain to him that Mozilla would not mess up his system, and if he didn't like Mozilla he could just ignore it and keep using IE, or uninstall it. He knows I am a computer expert, but he just would not believe me. His last experience with installing a web browser was installing IE4 on Windows 95, and no matter how I tried to explain it, he was just too scared that it would screw up his computer.
He is not the only person I know like this. Most simple computer users I know manage to get their systems into a (just barely) working state, then forevermore are frightened of changing it, except to add games, until they buy a new computer.
So we have a chicken-and-egg problem. Most people won't bother to use Mozilla every day unless they try it out first. However, most people are so frightened of installing new non-game software that they will not install it to try it.
Maybe what we need to do is to get some major game manufacturer like Id or Blizzard (forget OSS games -- too small a market share to do any good) to package Mozilla and install it by default with all new games. That way, it will sneak Mozilla onto the systems of those who would be too frightened to use it otherwise.
Search on Mozilla's bugzilla database. You will find it listed as a bug. Of course, you will also find considerable debate about whether it should be removed, as so many people like you have accustommed themselves to it. So unfortunately, you will probably get your wish, as this bug will probably not get fixed unless some strong leader takes over that module and makes a non-democratic decision. (unlikely)
However, consider it from a design purity angle rather than the user-1337 trick angle. A user is cutting and pasting values into a web based form. The user acidentally misses the form box by a couple of pixels. BAM! Mozilla clobbers the user's form by loading a new page which it interprets from whatever data the user accidentally pasted. On many pages, particularly secure pages, when the user clicks back, the form data is erased, which is an extremely *major* annoyance.
What you are referring to is a bug in Mozilla's Gecko Runtime Engine. It is not a feature! It is not documented behavior (other than in the bugzilla database) and it should be removed. You should not become accustomed to using it, because hopefully one day, it will be eliminated.
I don't get why you people seem to think that Red Hat is ending its free distro. They are merely renaming it, and if anything changes, they are making it better!
Red Hat always makes a nicely integrated and polished distro, but the biggest problems are that there are 1) not enough different packages available; 2) it takes too long for new versions of apps (particularly GUI apps) to make their way into official release and; 3) it's too hard to hard to upgrade. Fedora fixes #1 by increasing community participation so that volunteers can add official packages in addition to the core packages provided by Red Hat. Because Red Hat no longer has to worry about businesses trying to use the free distro as a production distro, #2 gets fixed automatically. (Those businesses who demand 18 month feature freezes can pay for RHEL or use at their own risk.) Problem #3 is fixed by moving over to yum or apt repositories.