I find it endlessly amusing that Hollywood is so staunchly in support of intellectual property rights, but is more than willing to enjoy the benefits of Linux.
Well, that's perhaps because you have a simplistic view of what Linux, open source, and the free software movement stand for.
First of all, open source is simply an economic and practical movement: as a user, I want the source to applications I use and I want to be able to modify them. If the vendor doesn't give them to me, I just don't use their software and hardware if I can help it. There is no long term political, economic, or IP agenda bound up in that--it's simple supply and demand.
Free software advocates do want changes in IP laws, but they don't want to abolish them--they want them to be different. But their arguments apply mostly to software, so there isn't necessarily any contradiction between Hollywood and the FSF.
You are including programs like social security and Medicare/Medicaid in those taxes. That doesn't make sense. If you look at just discretionary spending, you pretty much cut collected taxes in half, which basically confirms the lower end of my statement.
Furthermore, Bush's spending bill doesn't account anywhere near for all the costs to the US government associated with the war (let alone the cost to our economy).
I suspect the Iraqis have little need of GPS--their military probably knows their country pretty well and they don't have much in the way of smart weapons.
GPS is much more important to the US military, which does not have on-the-ground knowledge there. The US should be more worried about the Iraqis jamming GPS signals and other communications.
Of course, so far, it looks like Iraq is pretty feeble militarily. I suspect the war will be over very quickly. Which brings up the question again: why are we going?
The military isn't a private entity. The military, and anything they own, is paid for by your and my tax dollars, and it is owned by the US government. We, the voters, get to decide how it's going to be used ultimately, by electing and kicking out the executive and legislative branches of government.
Incidentally, the many billions of dollars of equipment the military is about to blow up in Iraq don't come from nowhere either--they are coming from the check you and I are sending to Uncle Sam on April 15. The war may amount to somewhere between 10% and 20% of our taxes. I hope it's worth it because it sure is a lot of money.
Under the MS license you can redistribute software either in source/binary or binary form only, i.e. you are not obligated to include source code, also allowing you to effectively sell commercial software. If they allowed the GPL compatibility they would lose this feature of the license.
Yes, but so what? If I link their code with GPL'ed code, then my combination must be redistributed in source form. That doesn't affect anybody else's use of Microsoft's code. So, I don't see what their problem with this is.
This is radically different from most of GPL that covers only redistribution and not use.
Sure, but I don't see serious implications; it's not like the license obligates you to do anything unless you redistribute.
First of all, my reading of this license doesn't grant user any patent rights at all; does this statement? Second, am I allowed to redistribute the patented parts of software when they are included in the derivative works?
No.
If MS holds a patent on a piece of code under this license, and I redistribute my derivative work based on the software which also includes the patented code, am I finally liable to MS for patent royalties? Are my customers?
Yes, and yes.
I think GPL is more clear on this issue.
I think both are clear. Microsoft's choice is different from the GPL. And that's fine, I think. I actually also think it makes less of a practical difference than one might think: patents are public, so if an important piece of software is covered by patents, people will find out about it and can decide whether they want to use it or not. While patent abuse by contributors is possible, usually a more common threat is unexpected patents coming out of nowhere.
But overall, it is a step closer to the OSS. Could this be considered for an OSI approval?
I think it could be. This license looks a lot less obnoxious than the Apple public license or the Plan 9 public license.
The real question is whether there is any useful software Microsoft is going to put under this license. Apple and Plan 9 actually have software that might be useful to open source. I can't think of anything I would want from Microsoft.
No, but neither will matching closing tags, because most likely, you will have library code that generates matching closing tags automatically. So, if you have a bad transformation, you'll just get bad output in which all tags still match.
A quick reading of that license suggests that software under it could be shipped and run on BSD and Linux systems, that it can be modified and redistributed, that it can link with LGPL and BSD code, and that it might be considered Open Source. The restriction of not linking with GPL'ed software seems spiteful and a gratuitious incompatibility--there isn't really any commercial or legal interest that that serves (I guess Microsoft's licenses work like their software), but other open source licenses are incompatible with the GPL, so that's not necessarily and issue.
The real question, however, is whether any interesting software will be shipped under this license. Rotor, for example, still comes with the "non-commercial-only" license (here).
If this is one of several shared source licenses they have but they don't use it for anything interesting, then it's just a PR ploy. Of course, I have a hard time thinking of what kind of open source software I would want from Microsoft anyway: none of the stuff they have is of much interest to me.
This is not particularly surprising: viruses in that family cause a lot of "common colds" and other URIs (among them, parainfluenza is in that family). See here and here.
You are probably best off getting yourself a bunch of low-cost computers like a mini-itx or Walmart PC. If you are really pressed for cost, you can get a bare mini-ITX motherboard for abour $80 and add an ATX power supply for another $20, and whatever keyboard and mouse you like, and stick it into a cookie tin.
You can then either boot the machine from an Linux Terminal Server floppy or CD, or from something like a Knoppix CD, or you can netboot them; you don't even have to bother installing anything locally. You wire everything together with a small Ethernet hub. Since nothing is installed on the local machines, it's easy to set up. Applications are run remotely through terminal emulators, X11, or VNC. All you need to do on the server is set up a DHCP server and xdm (if they aren't already set up).
That kind of setup is not going to be a lot more expensive than plugging in multiple graphics cards, but it's a whole lot easier to set up, scales better, lets you add more servers easily, will perform better, and your users will probably be happier, too.
Well, that indeed is a good thing. Because if machines did corrupt files, I'd worry first about databases and executable files, neither of which contains much "validation". In fact, we decided long ago to leave that kind of validation to disk controllers, file systems, and TCP, and to ensure syntactic correctness of machine-generated files by using parsing and generation tools.
One interesting hurdle along the path is likely to be finding a way to build a dual-kernel system that can add T-Kernel's real-time capabilities to Linux's rich set of sophisticated OS features without violating the RTLinux patent.
I don't see that as necessary. The validity of the patent seems very much in question to many people. I can't think of anybody better to test the validity of the patent than a large association of Japanese real-time companies.
How can you "agree" when you restate something completely different?
Gnome and KDE get the job done but are full of inconsistencies and "ugliness" and places where the limitations of X11 peek through.
And I suppose OS X, with its mix of OS9 and OS X applications is more consistent? Or Windows, with its mix of anything from Windows 3.1 to Windows XP applications? If you restrict yourself to a handful of applications, any desktop becomes consistent. That's particularly easy for OS X and Windows XP because they ship with so little. Given the scope and range of applications included with KDE or Gnome, the degree of consistency among dozens of applications is unmatched by any commercial desktop.
As for "limitations of X11", you are simply wrong. Gnome and KDE use X11 in a specific way, for historical reasons and for a certain degree of cross-platform compatibility. Nowadays, there is little in the OS X graphics model that can't be done in X11.
Realistically, most regular Linux systems are not secure against local exploits: making a system secure that way is possible, but it's quite a bit of work. You certainly won't get such a system by just doing a [insert your favorite distribution] install. This isn't exactly news either--it's been like that for a long time.
Of course, it is good that these kinds of bugs get fixed. Some people do run multiuser systems, and it provides an additional barrier against intrusions. But don't lose any sleep over it.
Incidentally, these kinds of exploits are probably rampant on Windows systems; there, people don't even bother looking for them because there are very few multiuser machines and most people have local Administrator privileges anyway. Also note that Microsoft didn't even try to get Windows certified secure for multiuser use.
One other nice thing about XML is that closing tags are matched with ending tags. If you leave of a closing paren in Lisp, the parser will give you an error but it can't pinpoint where you screwed up. But an XML parser can spot which closing tag is missing, which means you don't have to hunt for it yourself.
That would be a valid argument if XML were designed to be regularly input by humans. But XML is so cumbersome otherwise that almost all of it will be either machine generated or edited in special editors. And balancing closing tags is easy in Lisp if you use a special editor.
Also, most versions of Lisp give you two separate, equivalen pairs of parens that you can use for checking. So, you write:
Also, one of the major ideas of XML is to separate code from data, as opposed to Lisp where code and data are the same thing. Similar syntax, different philosophy, I guess.
Lisp programs separate code from data all the time, just like well-written programs in any other language. It's just that on those occasions when you do have to deal with code, you can do so using the same syntax as you use for data. In different words, separating code from data does not require for code and data to have different syntax.
The fact that several web standards use incompatible syntax (DTD, CSS, etc.) is actually a big problem. And the fact that almost no web code is written in XML syntax means that all those scripts are inaccessible to XML parsers and easy automatic analysis. Just imagine how nice it would be if the stuff inside the JavaScript tags could be analyzed and indexed with a bit more confidence.
Now, I have to say: a universal syntax for tree-structured data is very useful: experience since the 1970s with one such universal syntax, Lisp, has shown that. It is unfortunate that XML is about the worst imaginable implementation of that idea. XML combines being a nuisance to type with having comparatively complex semantics and lots of redundant features.
What is ironic is that the same "real world programmers" who wax ecstatic about XML also condemn Lisp as too complicated and too difficult to read. The universal syntax that XML aspires to, Lisp syntax delivered many decades ago. It's just that prejudice and ignorance caused people to re-invent the wheel (and in square form, too) in the form of XML.
I am pretty torn between whether XML is a blessing or a curse. We really need something like it, but XML is so bad that it may not even live up to the level of "poorly designed industry standard but better than nothing".
Eww, you're using the default voices. What you want to do is install the OGI RES LPC pack, the OGI Lexicon, the tll voice, and write a bit of scheme to get the thing configured.
Someone who has figured out how to configure that should put it into Debian as a package... then ordinary users could use it.
It would be easier just to take a hollow spherical acrylic lamp, put the lights in there, and roughen up the surface with steel wool or spray translucent paint on the inside. No casting needed.
Display Postscript is proprietary and costs money to license from Adobe. Tell me how to get it running on my RH8 box please.
What does that have to do with anything I wrote? DisplayPostscript has been available for X11 commercially since before Linux even existed, back when Apple was barely past black-and-white Macs.
XFree86 4 used to ship with a DPS extension (based on a donated IBM DPS implementation, I believe), but that isn't being developed anymore because X11 now has better mechanisms for doing the same thing. Look at the DPS site for the rationale. If you like, you can still download and use it. And if you want to see what the open source equivalent of Cocoa is doing, look at the GNUstep site.
Basically, the mainstream, about a decade ago, tried and abandoned the graphics architecture that Apple has chosen for OS X. Now, the use of PDF fixes some problems with DPS, and one can argue that machines are faster now so it doesn't matter as much anymore, but I don't think so.
In a very REAL practical sense, I can't do stuff in Gnome or KDE that I can do easily in Mac OS X.
And I fully agree with that. But that's not what we are talking about here. What we are talking about is whether that is a limitation of the underlying technology (X11 vs. Quartz) or whether it is an implementation choice by the implementors of the desktop, and I argue it is the latter.
I predict you will see X11-based desktops with all the pizazz of Mac OS X and little of the Mac OS X bloat and overhead within a couple of years.
Therefore the technology used behind these DEs is an important factor on this comparison. In fact, this factor can be what allows a DE to do, or what locks a DE to not be able to do because the back-end functionality is not there or because architecture or legacy problems might prevent the creation of new cool stuff (and that's bad for the future potential of any DE).
[...]
MacOSX takes the lead here regarding the technology used. Double buffering everywhere, non-flickered UI, vector icons, good font rendering engine, "real" transparency support, PDF-based, QuartzExtreme for 3D assistance on the 2D space of the desktop and my personal favorite "smooth window dragging" (for lack of a better naming of a VSYNC'ed desktop).
It's a myth that Mac OS X has any advantage here over either X11 or Windows. X11 has support for all those features, including VSYNC (which has been in there since the mid-1980's). X11, in fact, has support for pretty much exactly the Mac OS X graphics model through DisplayPostscript.
The reason why these features are not used much in Gnome and KDE (or XP, for that matter) are partly historical and partly technical. Technically, it is not clear whether they are even desirable at this point. In particular, while the Mac does a few things like dragging windows around really well, on most normal graphics tasks, it is quite slow and consumes a lot of resources.
Basically, this guy's review is essentially a reiteration of common pre-conceptions: "XP is usable", "OS X is technically superior", and "Gnome/KDE is just third rate". Well, that's not news. It's also wrong.
Slashdot Mirror
Well, that's perhaps because you have a simplistic view of what Linux, open source, and the free software movement stand for.
First of all, open source is simply an economic and practical movement: as a user, I want the source to applications I use and I want to be able to modify them. If the vendor doesn't give them to me, I just don't use their software and hardware if I can help it. There is no long term political, economic, or IP agenda bound up in that--it's simple supply and demand.
Free software advocates do want changes in IP laws, but they don't want to abolish them--they want them to be different. But their arguments apply mostly to software, so there isn't necessarily any contradiction between Hollywood and the FSF.
Besides, my facts are right--Zuke's figures actually confirm it.
Furthermore, Bush's spending bill doesn't account anywhere near for all the costs to the US government associated with the war (let alone the cost to our economy).
Yeah, along the same lines, it would also be funny if the US would be doing something other than
(a) bombing some other country
or
(b) finding fault with someone else instead
GPS is much more important to the US military, which does not have on-the-ground knowledge there. The US should be more worried about the Iraqis jamming GPS signals and other communications.
Of course, so far, it looks like Iraq is pretty feeble militarily. I suspect the war will be over very quickly. Which brings up the question again: why are we going?
Incidentally, the many billions of dollars of equipment the military is about to blow up in Iraq don't come from nowhere either--they are coming from the check you and I are sending to Uncle Sam on April 15. The war may amount to somewhere between 10% and 20% of our taxes. I hope it's worth it because it sure is a lot of money.
Yes, but so what? If I link their code with GPL'ed code, then my combination must be redistributed in source form. That doesn't affect anybody else's use of Microsoft's code. So, I don't see what their problem with this is.
This is radically different from most of GPL that covers only redistribution and not use.
Sure, but I don't see serious implications; it's not like the license obligates you to do anything unless you redistribute.
First of all, my reading of this license doesn't grant user any patent rights at all; does this statement? Second, am I allowed to redistribute the patented parts of software when they are included in the derivative works?
No.
If MS holds a patent on a piece of code under this license, and I redistribute my derivative work based on the software which also includes the patented code, am I finally liable to MS for patent royalties? Are my customers?
Yes, and yes.
I think GPL is more clear on this issue.
I think both are clear. Microsoft's choice is different from the GPL. And that's fine, I think. I actually also think it makes less of a practical difference than one might think: patents are public, so if an important piece of software is covered by patents, people will find out about it and can decide whether they want to use it or not. While patent abuse by contributors is possible, usually a more common threat is unexpected patents coming out of nowhere.
But overall, it is a step closer to the OSS. Could this be considered for an OSI approval?
I think it could be. This license looks a lot less obnoxious than the Apple public license or the Plan 9 public license.
The real question is whether there is any useful software Microsoft is going to put under this license. Apple and Plan 9 actually have software that might be useful to open source. I can't think of anything I would want from Microsoft.
No, but neither will matching closing tags, because most likely, you will have library code that generates matching closing tags automatically. So, if you have a bad transformation, you'll just get bad output in which all tags still match.
The real question, however, is whether any interesting software will be shipped under this license. Rotor, for example, still comes with the "non-commercial-only" license (here).
If this is one of several shared source licenses they have but they don't use it for anything interesting, then it's just a PR ploy. Of course, I have a hard time thinking of what kind of open source software I would want from Microsoft anyway: none of the stuff they have is of much interest to me.
This is not particularly surprising: viruses in that family cause a lot of "common colds" and other URIs (among them, parainfluenza is in that family). See here and here.
You can then either boot the machine from an Linux Terminal Server floppy or CD, or from something like a Knoppix CD, or you can netboot them; you don't even have to bother installing anything locally. You wire everything together with a small Ethernet hub. Since nothing is installed on the local machines, it's easy to set up. Applications are run remotely through terminal emulators, X11, or VNC. All you need to do on the server is set up a DHCP server and xdm (if they aren't already set up).
That kind of setup is not going to be a lot more expensive than plugging in multiple graphics cards, but it's a whole lot easier to set up, scales better, lets you add more servers easily, will perform better, and your users will probably be happier, too.
Well, that indeed is a good thing. Because if machines did corrupt files, I'd worry first about databases and executable files, neither of which contains much "validation". In fact, we decided long ago to leave that kind of validation to disk controllers, file systems, and TCP, and to ensure syntactic correctness of machine-generated files by using parsing and generation tools.
I don't see that as necessary. The validity of the patent seems very much in question to many people. I can't think of anybody better to test the validity of the patent than a large association of Japanese real-time companies.
How can you "agree" when you restate something completely different?
Gnome and KDE get the job done but are full of inconsistencies and "ugliness" and places where the limitations of X11 peek through.
And I suppose OS X, with its mix of OS9 and OS X applications is more consistent? Or Windows, with its mix of anything from Windows 3.1 to Windows XP applications? If you restrict yourself to a handful of applications, any desktop becomes consistent. That's particularly easy for OS X and Windows XP because they ship with so little. Given the scope and range of applications included with KDE or Gnome, the degree of consistency among dozens of applications is unmatched by any commercial desktop.
As for "limitations of X11", you are simply wrong. Gnome and KDE use X11 in a specific way, for historical reasons and for a certain degree of cross-platform compatibility. Nowadays, there is little in the OS X graphics model that can't be done in X11.
Of course, it is good that these kinds of bugs get fixed. Some people do run multiuser systems, and it provides an additional barrier against intrusions. But don't lose any sleep over it.
Incidentally, these kinds of exploits are probably rampant on Windows systems; there, people don't even bother looking for them because there are very few multiuser machines and most people have local Administrator privileges anyway. Also note that Microsoft didn't even try to get Windows certified secure for multiuser use.
That would be a valid argument if XML were designed to be regularly input by humans. But XML is so cumbersome otherwise that almost all of it will be either machine generated or edited in special editors. And balancing closing tags is easy in Lisp if you use a special editor.
Also, most versions of Lisp give you two separate, equivalen pairs of parens that you can use for checking. So, you write:
[item (part-no 123456) (available 5) (stores 3 7 9)]
And checks can be incorporated into the definition of specific constructs. So, you could have:
(item (part-no 123456) (available 5) (stores 3 7 9) enditem)
Or, you could make this an optional part of the syntax, allowing people to close a list starting with "x" with "/x", but not requiring it:
(item (part-no 123456) (available 5) (stores 3 7 9) /item)
Also, one of the major ideas of XML is to separate code from data, as opposed to Lisp where code and data are the same thing. Similar syntax, different philosophy, I guess.
Lisp programs separate code from data all the time, just like well-written programs in any other language. It's just that on those occasions when you do have to deal with code, you can do so using the same syntax as you use for data. In different words, separating code from data does not require for code and data to have different syntax.
The fact that several web standards use incompatible syntax (DTD, CSS, etc.) is actually a big problem. And the fact that almost no web code is written in XML syntax means that all those scripts are inaccessible to XML parsers and easy automatic analysis. Just imagine how nice it would be if the stuff inside the JavaScript tags could be analyzed and indexed with a bit more confidence.
Sure, just look here, which lists many of the problems quite well.
I do rsync to a dedicated backup server at a different location. As a fallback, I backup portions regularly to CD-ROM.
Now, I have to say: a universal syntax for tree-structured data is very useful: experience since the 1970s with one such universal syntax, Lisp, has shown that. It is unfortunate that XML is about the worst imaginable implementation of that idea. XML combines being a nuisance to type with having comparatively complex semantics and lots of redundant features.
What is ironic is that the same "real world programmers" who wax ecstatic about XML also condemn Lisp as too complicated and too difficult to read. The universal syntax that XML aspires to, Lisp syntax delivered many decades ago. It's just that prejudice and ignorance caused people to re-invent the wheel (and in square form, too) in the form of XML.
I am pretty torn between whether XML is a blessing or a curse. We really need something like it, but XML is so bad that it may not even live up to the level of "poorly designed industry standard but better than nothing".
Someone who has figured out how to configure that should put it into Debian as a package... then ordinary users could use it.
It would be easier just to take a hollow spherical acrylic lamp, put the lights in there, and roughen up the surface with steel wool or spray translucent paint on the inside. No casting needed.
Actually, turns out the XFree86 DPS extension was based on GhostScript.
What does that have to do with anything I wrote? DisplayPostscript has been available for X11 commercially since before Linux even existed, back when Apple was barely past black-and-white Macs.
XFree86 4 used to ship with a DPS extension (based on a donated IBM DPS implementation, I believe), but that isn't being developed anymore because X11 now has better mechanisms for doing the same thing. Look at the DPS site for the rationale. If you like, you can still download and use it. And if you want to see what the open source equivalent of Cocoa is doing, look at the GNUstep site.
Basically, the mainstream, about a decade ago, tried and abandoned the graphics architecture that Apple has chosen for OS X. Now, the use of PDF fixes some problems with DPS, and one can argue that machines are faster now so it doesn't matter as much anymore, but I don't think so.
In a very REAL practical sense, I can't do stuff in Gnome or KDE that I can do easily in Mac OS X.
And I fully agree with that. But that's not what we are talking about here. What we are talking about is whether that is a limitation of the underlying technology (X11 vs. Quartz) or whether it is an implementation choice by the implementors of the desktop, and I argue it is the latter.
I predict you will see X11-based desktops with all the pizazz of Mac OS X and little of the Mac OS X bloat and overhead within a couple of years.
Doesn't seem that hard...
# apt-get install festival festvox-poslex festvox-kallpc16k
# lynx -dump -nolist http://www.slashdot.org/ | festival --tts
It's a myth that Mac OS X has any advantage here over either X11 or Windows. X11 has support for all those features, including VSYNC (which has been in there since the mid-1980's). X11, in fact, has support for pretty much exactly the Mac OS X graphics model through DisplayPostscript.
The reason why these features are not used much in Gnome and KDE (or XP, for that matter) are partly historical and partly technical. Technically, it is not clear whether they are even desirable at this point. In particular, while the Mac does a few things like dragging windows around really well, on most normal graphics tasks, it is quite slow and consumes a lot of resources.
Basically, this guy's review is essentially a reiteration of common pre-conceptions: "XP is usable", "OS X is technically superior", and "Gnome/KDE is just third rate". Well, that's not news. It's also wrong.