Anyone forced to pay royalties to SCO for using this code could sue SCO for damages (in the amount of the royalties, plus penalties, which tend to run 2x) for their current refusal to reveal the information necessary to avoid copyright infringement.
Anyone wishing to distribute Linux would be forced to remove the code from their distribution, since nobody can offer the code under the GPL, as they would lack a suitable license to it. So all new installations would quickly be exempt. Distributors would probably be eligible for damages, as well, due to SCO's refusal to provide the information on their copyrighted work.
SCO will essentially have to GPL the code in order to avoid being sued by everybody whose life they're making difficult; they want to postpone this occurrence until after the contract case with IBM is done, so as not to interfere with that. They also want to spread FUD as long as possible without getting sued; as soon as they reveal what their code is and who seems to be using it, the FUD ends and the legal fingerpointing starts.
Yeah, it's nice that now anyone can have a reproduction of the Bayeux Tapestry woven on their USB loom from the LoomML version. It's nice that there's a substantial area of art where the great works are in the public domain now.
Of course, I'm kidding; the Bayeux Tapestry is actually not a tapestry but embroidery, and I don't know of any consumer automatic looms. But it would be fitting if the device which inspired the invention of treating programs as data were brought up to date with the technology of distribution of programs. Just so long as I don't get spam for thread cartridges.
Am I right in thinking that you just said that you use OOo formats primarily in programs you wrote, and do not generally use OpenOffice itself for most of the stuff you do? This is very interesting, but does not quite invalidate my point.
It seems to me that you use other tools to generate and use OOo files and use OOo to write documents, save them locally as OOo files, but use other formats to distribute them. I had neglected the possibility of people using the native format and PDF but not MSFT, I suppose.
The thing about OOo is that it is a WYSIWYG word processor, which has the fundamental issue that you are editting formatted text, and therefore have to do a substantial amount of formatting yourself, and cannot interact with formatting instructions for an automatic system. If you are not Douglas Hofstadter, you'd probably be better off telling the system your general ideas about formatting, and letting it arrange the text to suit the page when you're done and select an output medium. The messing with layout that you have to do in Word is similarly required in OOo, but is not in LaTeX.
Also, the thing I'd really like to do with a document format is put it under version control. Unfortunately, OOo format doesn't work that well with CVS.
Incidentally, if you know jed, you actually know enough of emacs to use that, since jed is essentially a rewritten specialization of emacs, and emacs behaves almost exactly like jed if you do only things that jed supports. The advantage of using emacs over jed is that it lets you find out about and enable lots of nice things that jed doesn't support. Also, you can get nice results out of LaTeX by putting a little header and footer on a plain text document; from there, you can start learning LaTeX features as needed (if you actually need any; for most documents, all you need to do is separate paragraphs with a blank line).
Everyone that has ever complained for these "features" in my mind has never actually understood java, thus they are probably just C++ coders that don't want to learn a new language. It looks like their language, but they can't be bothered to use an interface, so they'll continue to complain about multiple inheritance until Java is C++.
Generics aren't at all the same as C++ templates, although they draw on C++ experience to avoid the C++ problems, like most of Java. This is like how Java includes single inheritance like C++, but not multiple inheritance, which is complicated to specify, use, and implement. The issues with C++ templates are the type variable computations and the different resulting object files for different types; Java skips these, and manages to implement generics entirely at compile time.
Guy Steele was an author of an ACM paper about adding generics to Java and Gilad Bracha is the specification lead for the JCP group. So two of the people who complained for these feature are authors of The Java Language Specification, and one of them was an original language designer. I'd defer to them on what fits the spirit of the language.
Java's design goals include that any unsafe memory usage be prevented, either at runtime, or, ideally, at compile time. Generics help with this. While it seems to be true of Java that you have to write 20 lines of code whenever you want to do something, this is not actually a design goal.
The OpenOffice format isn't really preferable to MSFT file formats for any practical reason (aside from not including random secret information, which OpenOffice presumably doesn't put into the MSFT files anyway). Any other supported format you're likely to want, you'd use a more suitable program to create. Everyone I know who uses OpenOffice only uses it to deal with MSFT files and writes their books, papers, and web pages in plain text or LaTeX with emacs or vi.
(In fact, most of the documents you're likely to receive are plain text or HTML email, judging from the spam I get, but you won't use OpenOffice with them)
It seems unlikely that there's actually a substantial amount of revenue expected at the beginning of the year that gets shifted to the previous year. I'd expect that almost all of the revenue early in the year comes from companies whose IT budgets have gone up, meaning that they can suddenly afford a mainframe; these can't be shifted to the previous year because they can't spend the money earlier. There's probably a certain amount of stuff that didn't get shipped in time for the end of the year which is left over, but it's probably not that much.
Although, these days, just about nobody actually uses calendar years for their business cycle, because there is always month-change and year-change paperwork, and it's easier on everybody if the quarter-change and financial-year-change paperwork is offset from that. Furthermore, it's beneficial if your company's paperwork doesn't coincide with other companies' paperwork exactly, so everybody's different.
It's one of the things that's a pain when you do a project involving business quarters.
This is actually not at all "practical" knowledge, because circuits these days are exclusively done with CAD tools producing results which can only be seen with a magnifying glass (or very good vision). This is more like doing chemistry with plastic models, where you can actually see and touch the things you're talking about. You actually do build circuits out of wavy lines and parallel lines, not ceramic and metal.
On the other hand, assembling a circuit out of macroscopic elements by hand gives you a valuable opportunity to look at what happens with different resistor values and play around with the devices. This will give you a feel for what's going on that you can't get with the computerized versions that you'll use in every other course and the real world.
Getting a 1-square-meter area marked is somewhat useful, but not all that great for mail delivery. What happens to people whose apartment is directly above another apartment? What about people with a common front door? If you decide to have your mail delivered to the garage door in the winter, you you need a change of address? What if you move your mailbox?
Even worse, what about situations where you have dozens of mailboxes for unrelated people in the same square meter? I doubt any postal service would adopt a system which didn't work for post office boxes.
Postal addresses aren't really for locating places; they're for specifying routing. Given a postal address, each office involved has to be able to determine how to get an item to the next office along the way. For all those weird Japanese addresses, all anyone outside of the Japanese postal system has to know is to send stuff to Japan. Aside from that, all that matters is that people who want to send items by able to copy addresses.
This system, on the other hand, may be useful for specifying addresses for travel; it would probably actually be quite helpful to have a standard way to specify where you live, as opposed to how you get a package delivered to you.
None of this is particularly complicated, really. Generics are easy; rather than saying something is a List, you say it's a List of Somethings, just like you've always done with arrays. Variance is a bit trickier, but you don't need to use it unless you're writing a library (since you know the exact types you intend most of the time). Enums are easy; they do the obvious thing better than you could sanely implement it otherwise. The rest of the stuff is simple syntactic variation, doing the obvious things.
Anonymous inner classes are terribly ugly syntax, but neither too difficult, nor are they necessary to teach to students. They are, at least, preferable to the alternatives in the situation where you actually have any reason to use them.
Nope, actually "Variance". The idea is that sometimes you need to know that something is exactly of some type, sometimes you need to know that something is "at least" of some type (i.e., equal or a subtype), and sometimes you need to know that something is "at most" of some type.
Say you have a List, and you want to do:
Number num = list.get(0);
In this case, you need to know that the list contains elements which are Number or a subtype of Number, so you declare that you're taking a List<+Number>
If you want to put a Number into the list, you need to know that the list can contain Numbers, which means that it has to be a list of "at most" Numbers (i.e., it is not a List of something more specific, which would not accept a Number). You thus declare that you're taking a List<-Number>.
If you're going to do both, you require that the list contain nothing that's not a Number and that it be able to contain anything that is a Number, so you declare it to be List<=Number> (the = is optional in this case).
If you don't care what type the elements are, you can use List<*>, rather than the equivalent List<+Object> (a list which contains Objects and subtypes; unrestrictive, since everything that's not a primitive type is a subtype of Object). This is somewhat clearer, since it means that you don't care at all.
Of course, actual code is more likely to use type variables rather than Number; sort(), for instance, takes a List which is exactly of some unspecified type and a Comparator which does not require anything more specific than that type.
Variance is a neat idea, but what's the rush? The issue is dealing with arrays. Traditional arrays require that a variable of Number[] get a value of at least Number[] (i.e., +Number in the new syntax), but they allow you to store a Number in the array, even if the array is actually of a subtype of Number; if it doesn't fit, you get a runtime exception. However, the extra type information for generics isn't around at runtime, so nothing can stop a List<Number> from being stored into an array of List<Double> which has been passed into a method which takes an array of Object (at compile time, it is an array of Object getting a List<Number>, at runtime, it is an array of List getting a List, but then a[0].get(0) might be an Integer not a Double like it's supposed to be). So the idea is to get a version of arrays like the variance-using Lists above into the language to be used with generics, which implies including variance at the same time as generics, so that unsafe arrays mixed with generics can be prohibited.
The only way in which generics make code less readable is the awful angle brackets; otherwise it's a bit more verbose but no less clear, and verbosity has been an aspect of Java from the beginning.
In C++, the reason people are scared of templates is that they're actually quite complicated, with historical stability problems and continuing unexpected behavior. Java only supports the more obvious cases.
Java has been designed by committee from the start, but it's always been an extremely conservative committee; they only include features that a lot of people agree on and of which there are working implementations which have been tested enough to verify that the feature behaves as expected. They're also perfectly happy to not add a feature if it would cause problems, or to send it back for more discussion. C++ has had a lot of problems due to idealism and abstract discussion.
It is significant that, in working on generics and variance, they've gone through the entire Collection library and considered how it should be modified to support all existing code while giving benefits to new code.
Unless, of course, people buy a cluster of PCs from IBM or Sun. "Big iron" technology is remarkably applicable to PC cluster interconnects, and IBM has been making PCs since "PC" was an IBM model. IBM, in particular, has positioned themselves as the people you buy a large Linux system from, regardless of its composition. That's why all of the computers they produce can run Linux, not just a particular line they're trying to push.
I'm not sure exactly what, if any, stake MicroSoft has in this. Possibly they want to minimize the money spent on the computing portion, because that leaves more money for the data collection portion, and most of the software for interacting with scientific equipment is Windows-based.
I haven't used a version of Word quite that recent; I assume that they've done something sensible to reduce the load time. So I'll claim instead that Word was bloated until recently, and recently they've taken steps to manage it.
As for Emacs starting, starting Emacs in tty mode takes under a second for me (P3 1Gz); it's actually only loading the mode for the file I'm editing (so just C mode or just Java mode or even none of the language modes for a plain text file). On the other hand, I usually use Emacs server mode, which lets you edit files from the command line in an existing emacs process and pops up a window even faster. In any case, at this level the speed doesn't matter, since you're going to spend more time scrolling to the part of the file you mean to edit.
It would be trivial to get exactly this effect with a simple fvwmrc. Why go to the trouble of doing this as a new window manager when you can produce a smaller and more stable result distributing a single small config file? Why exactly do people seem to switch from fvwm to something more flashy, and, when they find they miss fvwm's simplicity, which to a new non-flashy window manager, rather than back to fvwm, with which they have experience already?
The real measure of bloat is how many features are provided to you with no real reason to believe that you want them. The major cause of bloat is a flat feature space, where the program has no way to know what features the user might want (or might want at this particular moment) and therefore has to offer all of them. This makes for big programs in terms of memory usage, and, more significantly, very complicated interfaces.
Emacs is probably actually the program most effective at controlling (as opposed to not having) bloat. It has a huge number of features, both useful and silly, enormous flexibility, support for a large number of tasks, and extensible support for a lot of file formats. On the other hand, it doesn't load any of these features or offer them in menus unless you ask for them.
Compare this with Word, which probably has a comparable number of features, but they're all in the menus all the time. It takes forever to load all of this code (versus a mere moment to load enough of Emacs to do the thing you're trying to do), and you have to sort through all of the features to find the one you want to use.
The real measure of efficiency is how long it takes the user to complete the task. The largest factor, these days, is the complexity and speed of the interface. Smaller than this is runtime efficiency of the software (although some tasks still take noticeable processor/disk time; generally loading the program). Of varying significance is the time the user spends redoing work lost (due the crashes or user mistakes). Lastly, there is the amount of time the user spends waiting for the software to be written.
Of course, the task that window managers enable the uer to accomplish is sufficiently straightforward that there are few features which would improve efficiency; most of the common features are intended to improve the user's enjoyment, which is a somewhat different thing. For this reason, most window managers are bloated, although it may be worthwhile bloat if the user finishes the task later but happier.
Re:Cringley, Linus, and Christoph Hellwig
on
Today's SCO News
·
· Score: 4, Informative
SCO's actual allegations in the actual lawsuit seem to be that IBM started a joint project with SCO, learned some secrets, got some code, saw some patent-pending ideas, and then dropped the project. Then they put this stuff into Linux, where they make money on consulting and hardware, and SCO doesn't get anything out of the deal. This is plausible; I'm sure every slashdot reader can come up with a case of a company pulling this stunt. It's something that people practically expect from MicroSoft, and IBM has been similarly regarded at times in the past.
Of course, the press releases and interviews give a very different story. But these have been generally quite incoherent and show no evidence of being better informed than outsider speculation. The whole thing may be unrelated to any UNIX IP, but to more recent and less public development efforts.
The real reason actually is reducing bugs; it only has a significant difference in efficiency when types are entirely static (i.e., no subclassing).
The idea is that people actually do have to select and at least document types if anyone is going to be able to use the code; the question is merely whether this is done in a machine-readable and up-front way.
I've used Scheme a significant amount, and, while it's extremely nice to be able to return values of arbitrary types, it also requires a whole lot of discipline to make sure you return the types the caller is expecting. Watching novice programmers use Scheme, it is possibly the most common bug (other than misplaced parentheses) in their programs; they find their code trying to take the car of #t because the wrong structure has ended up somewhere.
Personally, I think the ideal situation would be optional static typing, with type inference supplying information which could be imported into the source file by an IDE. That is, you can write your program without any types, and the compiler will figure out what the types are (using superclasses and wrappers for primitive types when necessary); once you're happy with your program, you can import the types you've selected implicitly into your source files, so that you'll find out if they change without your knowledge. Furthermore, you can debug type errors effectively by finding places where the compiler couldn't prove that a type was correct.
What, incidentally, is with naming files with.ogg? That tells you what kind of container it is, but nothing about what's in it. It would make much more sense to use ".oa" (Ogg audio), or ".ov" (Ogg video), or ".oav" (Ogg audio and video), so that you know what sort of output you expect to get out of this file.
I've not found commercial advance to do a good job of identifying the commercials, and always turn it off. The skip forward feature is just as effective, particularly if you're watching a show you watch frequently enough to know the pattern of the commercials.
I think the networks should align the commercials very regularly, such that a 30-second skip will give you a few frames after the start of each commercial. I've been watching TV with a ReplayTV recently, and haven't seen any of the commercials people have talked about. Ideally, people would skip all of the commercials which aren't targetting at them and watch the ones that are because they're interesting.
Ads between shows are also effective, since ReplayTV continues to play the audio while you're selecting a show and doesn't let you skip if there's nothing to skip to.
Functional languages are useful for a couple of problems, of which the main one is writing compilers. On the other hand, they make a really good research platform for language features. So the neat features start out in functional languages and then propagate to imperative languages, and then they show up in mainstream imperative languages.
I expect to see features like first class functions in JDK 1.6, and type inference and anonymous functions in JDK 1.7; C# may get them before or after. (And generics, an important first step toward first class functions, are in JDK 1.5).
There are two reasons you haven't seen higher-order functions much in mainstream languages: static typing and higher-order functions are really hard to combine, and people like static typing because you can tell whether your program could possibly work at compile time with static typing; and managing closures automatically (or at least, without driving your programmers crazy) is extremely difficult without garbage collection, and garbage collection is only becoming popular now.
Of course, it will be a long time, I think, before any mainstream language gets fully general captured continuations (i.e., Thowable.resume(), which causes whatever threw the exception to resume running with a provided value), although the special (and probably, most sane and useful) case of generators is likely to be sooner (i.e., a function which returns a sequence of values, with each being computed, by having the function resume running, as needed).
The.NET CLR was designed for C#. None of the other.NET languages are any better for anything than C#, because every feature that isn't in C# has been removed from the other languages to make it a.NET language. It's not actually more generally applicable than the JVM, it's just that there's a bigger marketting push to demonstrate that you can implement a bit of a lot of languages on it.
Sure, it's a minor bug, but how could they possibly have missed it while testing? It's not so much that the bug is a problem as that it indicates that they didn't check whether the patch worked before releasing it.
Anyone who wishes to distribute or publish GPL-derived software legally does have to license it under the GPL. There are two choices: SCO never licensed that code under the GPL, but merely passed on the (invalid) license they received with the copy they got back, and they don't intend to license it under the GPL; this is perfectly fine, and everyone (including SCO) who wants to do anything with the affected code will need to remove SCO's code from it (there is no way anyone else could have known, or could now know, that they are violating SCO's copyright, though, which makes it a tough case for SCO if they want to go after Red Hat; only SCO could have told Red Hat about SCO's IP, and SCO expressly refused to do so in hopes that Red Hat would violate it. Er...).
The other possibility is that SCO now licenses the IP properly, since they can, and then they can resume distributing it (and derived works), under the GPL.
I don't think the fact that SCO happens to own the content in question as well as being a redistributor of the same content without knowing, means that they've chosen the second option implicitly. In fact, I assume they'd take the first option, since they've put themselves out of the Linux business anyway. They're probably going to try to collect as much money as possible and go out of business before everyone using Linux sues them for damages for refusing to reveal what IP they own, thereby preventing people from working around the problem.
Re:What a spin he puts on it.
on
I, Spammer
·
· Score: 1
On the other hand, this gives reasonable evidence that eliminating forged sender information would greatly reduce spam. Just making it hard to forge sender information (requiring that you successfully hijack or forge a TCP connection, e.g.) would probably reduce spam to a manageable (and unprofitable) quantity.
Nice of him to tell us how we can put him out of business using exclusively technological means...
The FCC doesn't care if you give out the specs; the FCC just cares that there not be any way to send on restricted frequencies (and they'd like it if you can't receive on other restricted frequencies, either, at least not without knowing you're on a restricted frequency, so you can obey the law on disclosure of what you get).
Basically, the card makers may some stuff configurable which shouldn't be configurable, and they need to deal with getting it configured in the legal way by default. The tricky thing is that there isn't a universal legal default.
The situation is that it's illegal to disrupt police communications, and it's pretty easy, but it's also pretty obvious. If you're doing it, they can trivially track you down and arrest you. The manufacturer gets in trouble if you're doing it with an unmodified transmitter, because you might not realize you're breaking the law. If anyone who uses the SuSE driver for a Broadcom card (configured, of course, for Germany) in the US is breaking the law and causing problems for the police, someone will get in trouble, and it's likely to be Broadcom.
Slashdot Mirror
Anyone forced to pay royalties to SCO for using this code could sue SCO for damages (in the amount of the royalties, plus penalties, which tend to run 2x) for their current refusal to reveal the information necessary to avoid copyright infringement.
Anyone wishing to distribute Linux would be forced to remove the code from their distribution, since nobody can offer the code under the GPL, as they would lack a suitable license to it. So all new installations would quickly be exempt. Distributors would probably be eligible for damages, as well, due to SCO's refusal to provide the information on their copyrighted work.
SCO will essentially have to GPL the code in order to avoid being sued by everybody whose life they're making difficult; they want to postpone this occurrence until after the contract case with IBM is done, so as not to interfere with that. They also want to spread FUD as long as possible without getting sued; as soon as they reveal what their code is and who seems to be using it, the FUD ends and the legal fingerpointing starts.
Yeah, it's nice that now anyone can have a reproduction of the Bayeux Tapestry woven on their USB loom from the LoomML version. It's nice that there's a substantial area of art where the great works are in the public domain now.
Of course, I'm kidding; the Bayeux Tapestry is actually not a tapestry but embroidery, and I don't know of any consumer automatic looms. But it would be fitting if the device which inspired the invention of treating programs as data were brought up to date with the technology of distribution of programs. Just so long as I don't get spam for thread cartridges.
Am I right in thinking that you just said that you use OOo formats primarily in programs you wrote, and do not generally use OpenOffice itself for most of the stuff you do? This is very interesting, but does not quite invalidate my point.
It seems to me that you use other tools to generate and use OOo files and use OOo to write documents, save them locally as OOo files, but use other formats to distribute them. I had neglected the possibility of people using the native format and PDF but not MSFT, I suppose.
The thing about OOo is that it is a WYSIWYG word processor, which has the fundamental issue that you are editting formatted text, and therefore have to do a substantial amount of formatting yourself, and cannot interact with formatting instructions for an automatic system. If you are not Douglas Hofstadter, you'd probably be better off telling the system your general ideas about formatting, and letting it arrange the text to suit the page when you're done and select an output medium. The messing with layout that you have to do in Word is similarly required in OOo, but is not in LaTeX.
Also, the thing I'd really like to do with a document format is put it under version control. Unfortunately, OOo format doesn't work that well with CVS.
Incidentally, if you know jed, you actually know enough of emacs to use that, since jed is essentially a rewritten specialization of emacs, and emacs behaves almost exactly like jed if you do only things that jed supports. The advantage of using emacs over jed is that it lets you find out about and enable lots of nice things that jed doesn't support. Also, you can get nice results out of LaTeX by putting a little header and footer on a plain text document; from there, you can start learning LaTeX features as needed (if you actually need any; for most documents, all you need to do is separate paragraphs with a blank line).
Everyone that has ever complained for these "features" in my mind has never actually understood java, thus they are probably just C++ coders that don't want to learn a new language. It looks like their language, but they can't be bothered to use an interface, so they'll continue to complain about multiple inheritance until Java is C++.
Generics aren't at all the same as C++ templates, although they draw on C++ experience to avoid the C++ problems, like most of Java. This is like how Java includes single inheritance like C++, but not multiple inheritance, which is complicated to specify, use, and implement. The issues with C++ templates are the type variable computations and the different resulting object files for different types; Java skips these, and manages to implement generics entirely at compile time.
Guy Steele was an author of an ACM paper about adding generics to Java and Gilad Bracha is the specification lead for the JCP group. So two of the people who complained for these feature are authors of The Java Language Specification, and one of them was an original language designer. I'd defer to them on what fits the spirit of the language.
Java's design goals include that any unsafe memory usage be prevented, either at runtime, or, ideally, at compile time. Generics help with this. While it seems to be true of Java that you have to write 20 lines of code whenever you want to do something, this is not actually a design goal.
The OpenOffice format isn't really preferable to MSFT file formats for any practical reason (aside from not including random secret information, which OpenOffice presumably doesn't put into the MSFT files anyway). Any other supported format you're likely to want, you'd use a more suitable program to create. Everyone I know who uses OpenOffice only uses it to deal with MSFT files and writes their books, papers, and web pages in plain text or LaTeX with emacs or vi.
(In fact, most of the documents you're likely to receive are plain text or HTML email, judging from the spam I get, but you won't use OpenOffice with them)
It seems unlikely that there's actually a substantial amount of revenue expected at the beginning of the year that gets shifted to the previous year. I'd expect that almost all of the revenue early in the year comes from companies whose IT budgets have gone up, meaning that they can suddenly afford a mainframe; these can't be shifted to the previous year because they can't spend the money earlier. There's probably a certain amount of stuff that didn't get shipped in time for the end of the year which is left over, but it's probably not that much.
Although, these days, just about nobody actually uses calendar years for their business cycle, because there is always month-change and year-change paperwork, and it's easier on everybody if the quarter-change and financial-year-change paperwork is offset from that. Furthermore, it's beneficial if your company's paperwork doesn't coincide with other companies' paperwork exactly, so everybody's different.
It's one of the things that's a pain when you do a project involving business quarters.
This is actually not at all "practical" knowledge, because circuits these days are exclusively done with CAD tools producing results which can only be seen with a magnifying glass (or very good vision). This is more like doing chemistry with plastic models, where you can actually see and touch the things you're talking about. You actually do build circuits out of wavy lines and parallel lines, not ceramic and metal.
On the other hand, assembling a circuit out of macroscopic elements by hand gives you a valuable opportunity to look at what happens with different resistor values and play around with the devices. This will give you a feel for what's going on that you can't get with the computerized versions that you'll use in every other course and the real world.
Getting a 1-square-meter area marked is somewhat useful, but not all that great for mail delivery. What happens to people whose apartment is directly above another apartment? What about people with a common front door? If you decide to have your mail delivered to the garage door in the winter, you you need a change of address? What if you move your mailbox?
Even worse, what about situations where you have dozens of mailboxes for unrelated people in the same square meter? I doubt any postal service would adopt a system which didn't work for post office boxes.
Postal addresses aren't really for locating places; they're for specifying routing. Given a postal address, each office involved has to be able to determine how to get an item to the next office along the way. For all those weird Japanese addresses, all anyone outside of the Japanese postal system has to know is to send stuff to Japan. Aside from that, all that matters is that people who want to send items by able to copy addresses.
This system, on the other hand, may be useful for specifying addresses for travel; it would probably actually be quite helpful to have a standard way to specify where you live, as opposed to how you get a package delivered to you.
None of this is particularly complicated, really. Generics are easy; rather than saying something is a List, you say it's a List of Somethings, just like you've always done with arrays. Variance is a bit trickier, but you don't need to use it unless you're writing a library (since you know the exact types you intend most of the time). Enums are easy; they do the obvious thing better than you could sanely implement it otherwise. The rest of the stuff is simple syntactic variation, doing the obvious things.
Anonymous inner classes are terribly ugly syntax, but neither too difficult, nor are they necessary to teach to students. They are, at least, preferable to the alternatives in the situation where you actually have any reason to use them.
Nope, actually "Variance". The idea is that sometimes you need to know that something is exactly of some type, sometimes you need to know that something is "at least" of some type (i.e., equal or a subtype), and sometimes you need to know that something is "at most" of some type.
Say you have a List, and you want to do:
Number num = list.get(0);
In this case, you need to know that the list contains elements which are Number or a subtype of Number, so you declare that you're taking a List<+Number>
If you want to put a Number into the list, you need to know that the list can contain Numbers, which means that it has to be a list of "at most" Numbers (i.e., it is not a List of something more specific, which would not accept a Number). You thus declare that you're taking a List<-Number>.
If you're going to do both, you require that the list contain nothing that's not a Number and that it be able to contain anything that is a Number, so you declare it to be List<=Number> (the = is optional in this case).
If you don't care what type the elements are, you can use List<*>, rather than the equivalent List<+Object> (a list which contains Objects and subtypes; unrestrictive, since everything that's not a primitive type is a subtype of Object). This is somewhat clearer, since it means that you don't care at all.
Of course, actual code is more likely to use type variables rather than Number; sort(), for instance, takes a List which is exactly of some unspecified type and a Comparator which does not require anything more specific than that type.
Variance is a neat idea, but what's the rush? The issue is dealing with arrays. Traditional arrays require that a variable of Number[] get a value of at least Number[] (i.e., +Number in the new syntax), but they allow you to store a Number in the array, even if the array is actually of a subtype of Number; if it doesn't fit, you get a runtime exception. However, the extra type information for generics isn't around at runtime, so nothing can stop a List<Number> from being stored into an array of List<Double> which has been passed into a method which takes an array of Object (at compile time, it is an array of Object getting a List<Number>, at runtime, it is an array of List getting a List, but then a[0].get(0) might be an Integer not a Double like it's supposed to be). So the idea is to get a version of arrays like the variance-using Lists above into the language to be used with generics, which implies including variance at the same time as generics, so that unsafe arrays mixed with generics can be prohibited.
The only way in which generics make code less readable is the awful angle brackets; otherwise it's a bit more verbose but no less clear, and verbosity has been an aspect of Java from the beginning.
In C++, the reason people are scared of templates is that they're actually quite complicated, with historical stability problems and continuing unexpected behavior. Java only supports the more obvious cases.
Java has been designed by committee from the start, but it's always been an extremely conservative committee; they only include features that a lot of people agree on and of which there are working implementations which have been tested enough to verify that the feature behaves as expected. They're also perfectly happy to not add a feature if it would cause problems, or to send it back for more discussion. C++ has had a lot of problems due to idealism and abstract discussion.
It is significant that, in working on generics and variance, they've gone through the entire Collection library and considered how it should be modified to support all existing code while giving benefits to new code.
Unless, of course, people buy a cluster of PCs from IBM or Sun. "Big iron" technology is remarkably applicable to PC cluster interconnects, and IBM has been making PCs since "PC" was an IBM model. IBM, in particular, has positioned themselves as the people you buy a large Linux system from, regardless of its composition. That's why all of the computers they produce can run Linux, not just a particular line they're trying to push.
I'm not sure exactly what, if any, stake MicroSoft has in this. Possibly they want to minimize the money spent on the computing portion, because that leaves more money for the data collection portion, and most of the software for interacting with scientific equipment is Windows-based.
I haven't used a version of Word quite that recent; I assume that they've done something sensible to reduce the load time. So I'll claim instead that Word was bloated until recently, and recently they've taken steps to manage it.
As for Emacs starting, starting Emacs in tty mode takes under a second for me (P3 1Gz); it's actually only loading the mode for the file I'm editing (so just C mode or just Java mode or even none of the language modes for a plain text file). On the other hand, I usually use Emacs server mode, which lets you edit files from the command line in an existing emacs process and pops up a window even faster. In any case, at this level the speed doesn't matter, since you're going to spend more time scrolling to the part of the file you mean to edit.
It would be trivial to get exactly this effect with a simple fvwmrc. Why go to the trouble of doing this as a new window manager when you can produce a smaller and more stable result distributing a single small config file? Why exactly do people seem to switch from fvwm to something more flashy, and, when they find they miss fvwm's simplicity, which to a new non-flashy window manager, rather than back to fvwm, with which they have experience already?
The real measure of bloat is how many features are provided to you with no real reason to believe that you want them. The major cause of bloat is a flat feature space, where the program has no way to know what features the user might want (or might want at this particular moment) and therefore has to offer all of them. This makes for big programs in terms of memory usage, and, more significantly, very complicated interfaces.
Emacs is probably actually the program most effective at controlling (as opposed to not having) bloat. It has a huge number of features, both useful and silly, enormous flexibility, support for a large number of tasks, and extensible support for a lot of file formats. On the other hand, it doesn't load any of these features or offer them in menus unless you ask for them.
Compare this with Word, which probably has a comparable number of features, but they're all in the menus all the time. It takes forever to load all of this code (versus a mere moment to load enough of Emacs to do the thing you're trying to do), and you have to sort through all of the features to find the one you want to use.
The real measure of efficiency is how long it takes the user to complete the task. The largest factor, these days, is the complexity and speed of the interface. Smaller than this is runtime efficiency of the software (although some tasks still take noticeable processor/disk time; generally loading the program). Of varying significance is the time the user spends redoing work lost (due the crashes or user mistakes). Lastly, there is the amount of time the user spends waiting for the software to be written.
Of course, the task that window managers enable the uer to accomplish is sufficiently straightforward that there are few features which would improve efficiency; most of the common features are intended to improve the user's enjoyment, which is a somewhat different thing. For this reason, most window managers are bloated, although it may be worthwhile bloat if the user finishes the task later but happier.
SCO's actual allegations in the actual lawsuit seem to be that IBM started a joint project with SCO, learned some secrets, got some code, saw some patent-pending ideas, and then dropped the project. Then they put this stuff into Linux, where they make money on consulting and hardware, and SCO doesn't get anything out of the deal. This is plausible; I'm sure every slashdot reader can come up with a case of a company pulling this stunt. It's something that people practically expect from MicroSoft, and IBM has been similarly regarded at times in the past.
Of course, the press releases and interviews give a very different story. But these have been generally quite incoherent and show no evidence of being better informed than outsider speculation. The whole thing may be unrelated to any UNIX IP, but to more recent and less public development efforts.
The real reason actually is reducing bugs; it only has a significant difference in efficiency when types are entirely static (i.e., no subclassing).
The idea is that people actually do have to select and at least document types if anyone is going to be able to use the code; the question is merely whether this is done in a machine-readable and up-front way.
I've used Scheme a significant amount, and, while it's extremely nice to be able to return values of arbitrary types, it also requires a whole lot of discipline to make sure you return the types the caller is expecting. Watching novice programmers use Scheme, it is possibly the most common bug (other than misplaced parentheses) in their programs; they find their code trying to take the car of #t because the wrong structure has ended up somewhere.
Personally, I think the ideal situation would be optional static typing, with type inference supplying information which could be imported into the source file by an IDE. That is, you can write your program without any types, and the compiler will figure out what the types are (using superclasses and wrappers for primitive types when necessary); once you're happy with your program, you can import the types you've selected implicitly into your source files, so that you'll find out if they change without your knowledge. Furthermore, you can debug type errors effectively by finding places where the compiler couldn't prove that a type was correct.
What, incidentally, is with naming files with .ogg? That tells you what kind of container it is, but nothing about what's in it. It would make much more sense to use ".oa" (Ogg audio), or ".ov" (Ogg video), or ".oav" (Ogg audio and video), so that you know what sort of output you expect to get out of this file.
I've not found commercial advance to do a good job of identifying the commercials, and always turn it off. The skip forward feature is just as effective, particularly if you're watching a show you watch frequently enough to know the pattern of the commercials.
I think the networks should align the commercials very regularly, such that a 30-second skip will give you a few frames after the start of each commercial. I've been watching TV with a ReplayTV recently, and haven't seen any of the commercials people have talked about. Ideally, people would skip all of the commercials which aren't targetting at them and watch the ones that are because they're interesting.
Ads between shows are also effective, since ReplayTV continues to play the audio while you're selecting a show and doesn't let you skip if there's nothing to skip to.
Functional languages are useful for a couple of problems, of which the main one is writing compilers. On the other hand, they make a really good research platform for language features. So the neat features start out in functional languages and then propagate to imperative languages, and then they show up in mainstream imperative languages.
I expect to see features like first class functions in JDK 1.6, and type inference and anonymous functions in JDK 1.7; C# may get them before or after. (And generics, an important first step toward first class functions, are in JDK 1.5).
There are two reasons you haven't seen higher-order functions much in mainstream languages: static typing and higher-order functions are really hard to combine, and people like static typing because you can tell whether your program could possibly work at compile time with static typing; and managing closures automatically (or at least, without driving your programmers crazy) is extremely difficult without garbage collection, and garbage collection is only becoming popular now.
Of course, it will be a long time, I think, before any mainstream language gets fully general captured continuations (i.e., Thowable.resume(), which causes whatever threw the exception to resume running with a provided value), although the special (and probably, most sane and useful) case of generators is likely to be sooner (i.e., a function which returns a sequence of values, with each being computed, by having the function resume running, as needed).
The .NET CLR was designed for C#. None of the other .NET languages are any better for anything than C#, because every feature that isn't in C# has been removed from the other languages to make it a .NET language. It's not actually more generally applicable than the JVM, it's just that there's a bigger marketting push to demonstrate that you can implement a bit of a lot of languages on it.
Sure, it's a minor bug, but how could they possibly have missed it while testing? It's not so much that the bug is a problem as that it indicates that they didn't check whether the patch worked before releasing it.
Anyone who wishes to distribute or publish GPL-derived software legally does have to license it under the GPL. There are two choices: SCO never licensed that code under the GPL, but merely passed on the (invalid) license they received with the copy they got back, and they don't intend to license it under the GPL; this is perfectly fine, and everyone (including SCO) who wants to do anything with the affected code will need to remove SCO's code from it (there is no way anyone else could have known, or could now know, that they are violating SCO's copyright, though, which makes it a tough case for SCO if they want to go after Red Hat; only SCO could have told Red Hat about SCO's IP, and SCO expressly refused to do so in hopes that Red Hat would violate it. Er...).
The other possibility is that SCO now licenses the IP properly, since they can, and then they can resume distributing it (and derived works), under the GPL.
I don't think the fact that SCO happens to own the content in question as well as being a redistributor of the same content without knowing, means that they've chosen the second option implicitly. In fact, I assume they'd take the first option, since they've put themselves out of the Linux business anyway. They're probably going to try to collect as much money as possible and go out of business before everyone using Linux sues them for damages for refusing to reveal what IP they own, thereby preventing people from working around the problem.
On the other hand, this gives reasonable evidence that eliminating forged sender information would greatly reduce spam. Just making it hard to forge sender information (requiring that you successfully hijack or forge a TCP connection, e.g.) would probably reduce spam to a manageable (and unprofitable) quantity.
Nice of him to tell us how we can put him out of business using exclusively technological means...
The FCC doesn't care if you give out the specs; the FCC just cares that there not be any way to send on restricted frequencies (and they'd like it if you can't receive on other restricted frequencies, either, at least not without knowing you're on a restricted frequency, so you can obey the law on disclosure of what you get).
Basically, the card makers may some stuff configurable which shouldn't be configurable, and they need to deal with getting it configured in the legal way by default. The tricky thing is that there isn't a universal legal default.
The situation is that it's illegal to disrupt police communications, and it's pretty easy, but it's also pretty obvious. If you're doing it, they can trivially track you down and arrest you. The manufacturer gets in trouble if you're doing it with an unmodified transmitter, because you might not realize you're breaking the law. If anyone who uses the SuSE driver for a Broadcom card (configured, of course, for Germany) in the US is breaking the law and causing problems for the police, someone will get in trouble, and it's likely to be Broadcom.