I don't know a lot about ISPs and the peering agreements between them, but I would think there's a good chance that if BellSouth tries to extract fees from individual companies for use of bandwidth, that would be a violation of those agreements. At least it's a violation in spirit, because the cost that Google pays to be served to BellSouth's customers is part of the cost they pay to their ISP, which agrees to exchange traffic with BellSouth.
I think that if the other giant ISPs wanted to stop this they could demand terms in peering agreements that these dealings could not happen.
But then again, I admit that my understanding of this situation is far from full.
Yup. This is, in general, a problem that happens whenever server software asks a bunch of client computers for information and depends on the returned results to be honest. Only this time, it doesn't seem that there would be any particular reward for, say, visiting advertising sites a particular number of times or anything like that. As long as they build their scheme such that there's no reward for browsing for more than a few hours a day they can probably avoid shenanigans aimed simply at making money. And since I really doubt that too many people are going to go out of their way to mess up this company's statistics with no profit involved, they could rest easy.
Actually, I was thinking about this again, and when I wrote my previous post (parent) I was thinking about the GPL as a license for arbitrary software projects and not what RMS is thinking about, which is the GPL as the license for the GNU project.
The goal of GNU, of course, is and always was "political", revolutionary and "subversive" (to the non-Free vendors; to RMS it is the restrictive vendors that are subversive to the ideals that governed the early software world, but since I wasn't alive back then I can't really offer my personal perspective on that). RMS is creating a license that expresses what he wants for his GNU project.
Not every person that creates GPL-licensed software has the same goals as GNU, and this has always been the case. But the old GPL, expressing a limited set of GNU's goals, still managed to resonate with a lot of these developers. The new GPL will force people to really evaluate their views on the software world and why they contribute their time and effort to Free Software. If enough people are turned off by the restrictions of the new GPL, we might witness the birth of a GAGWITINU (GAGWITINU Ain't GNU, Which In Turn Is Not Unix). And wouldn't that be fun?
So what happens then - I give you software with DRM with the GPL v2 or later, but the v3 causes problems with the DRM.
Actually as long as you distribute your software under GPL v2 you're fine; if someone else decides to distribute the same software with DRM under the terms of GPL v3 then they're the ones who have violated the license. Oddly enough, they've violated a license offered to them by you, not the other way around.
On your last point I agree; the "or later" clause to me means that anyone could choose to distribute so-licensed software under the terms of GPLv2 or GPLv3. But IANAL and there might be some other effect.
I don't think, however, that GPLv2 expresses the FSF's political views in the same was that GPLv3 does. GPLv2 restricts only the ways that derivative works can be distributed (they must be distributed with source). GPLv3 also appears to restrict the function of your derivative works (they cannot be used for DRM). And I think it means that using GPLv3 on your own servers to facilitate DRM is also not allowed (might be wrong on that one though) which would make it an end-user license.
GPLv2 expresses FSF's views on software distribution, while GPLv3 expresses FSF's views on software function. There is a big difference, and it could cause a lot of problems in the Free Software community. I can't say I agree with the changes in GPLv3, as someone that often waffles between preferring BSD-style licenses and GPLv2-style ones.
Being a geek isn't about technology. I know lots of geeks that aren't really all that fascinated with technology. They might be art geeks, language geeks, philosophy geeks or math geeks, and when I (as a computer geek) talk to those people it's like we're speaking a common language. It's the language of inquiry and passion for understanding. They want to understand a bit about why I get so pissed off at BellSouth or SCO, or what Linux is (and I usually tell them "It's acutally GNU/Linux" and then go off on a Stallmanesque rant). I want to understand the difference between artistic and musical minimalism or what the Incompleteness Theorem actually means.
Wow, I must have forgotten to take my cynicism pill before that post.
God damn. I have ranted many times on this website about people that use excessive line lengths. I program in fucking vim, often in the console. For those situations limiting line length to 80 characters is what should be done. When making plain old text files designed to be viewed straight on screens that's what should be done. In fact I've argued on slashdot before that programming is much easier when lines are truncated at less than 80 characters (In some programs a 70-character line looks out of place, so I'll split that too).
On web pages that's not what should be done. Leave out the BR tags and let the web browser do the word wrapping. The way this page rendered on my computer I had to widen my browser window so the wasn't wrapping around before 80 characters. It looked like this:
Here is some text blah blah blah text and the end of each 80-character line wraps to the next line making it very hard to read.
In VIM when you have text that looks like this you can put your cursor in the paragraph and type "gqap" and it formats the current paragraph with line breaks matching your terminal width. This is good. It appears that the web page linked to in the article summary was generated dynamically by Plone from a text file with linebreaks every 80 characters (which is a fine way to write a text file), but since everyone's browser windows are different sizes Plone should use similar logic to VIM to strip out all the linebreaks that don't mean "new paragraph" before converting line breaks to BR tags.
I don't know how your ass gets modded up insightful by flaming me about e-mail. I get my e-mail with mutt on the fucking console. In the mother fucking nineties dumb e-mail programs when sending a quote in a reply would take text formatted to 80 characters, stick a few characters at the beginning of each line and just send it off, leading to the same thing that happens with this article viewed in a narrow browser window. That's what I mean by 90s e-mail. Plain text e-mail is a good thing. Programs should figure out how to deal with it intelligently. Just like that this new GPL document being plain text, 80 characters is a good thing, but Plone should create output suited for the web.
Yeah, this would mean that plone would have to have different rules for displaying text than code. But if you're displaying a web site you should display it like a web site. In fact, the BR nonsense should be replaced with P tags!
Gah... why couldn't there be a web page that didn't have BR tags at the 80-character mark every time. This is like reading e-mail in the 90s! (Actually this looks like a plone-based site so it's probably serving up auto-generated *ml from a text file... which is no excuse, really. If vim can fix up stuff like that then plone could too.)
The problem is the "legacy code" in Vista is going to be Win32 - and there's a hell of a lot fo Win32 out there.
We've all heard stories about how Win32 got to be a beast because some bugs had to be maintained in order to keep certain software working. Win32 is OK to keep around, and even those long-standing bugs can be kept around to keep things working. But they should take a real look as they re-implement some of that functionality: does any of this cause security problems? When bugs appear in any of the new Vista APIs they should fix them, announce to the developers that xxxyyy function has changed so its behavior is now correct, and they should retest all their software and be prepared to offer updates. Apple does this; they're willing to break backwards compatibility and keep developers from holding them back. (Apple had been changing things in OSX really quickly for a while, it seems to me, and developers there were forcing users to buy OS upgrades to use their new software! I don't know how expensive this was for them or anything, as I don't own a Mac.)
The real danger, though, isn't the use of old APIs, it's the use of old security practices. I think that if at the introduction of NT, or at least at NT4 or 2000 Microsoft had really stressed the importance of non-priviledged user accounts and asked developers to fix software that needed Administrator priviledges in stupid times they could have saved everyone from certain problems. If they had that kind of attitude, they have the size to pull it off. Learn to read; I didn't say MS forced developers to write bad code, I said sloppy developers force users into bad security practices like running as Admin, but that MS has allowed this for way too long. In Vista they ought to take the simple solution to the problem and just tell developers that they actually plan on strongly encouraging user accounts this time around at that they'd better fix their broken software.
Well one might say there are multiple kind of precedent. There is precedent in the legal sense where our courts must decide whether these statistics can be owned, and there is also what one might call "historical precedent". Businesses will constantly try to bend the law in their favor, even if historically rulings have gone the other way. Big and powerful businesses have a pretty good chance of doing it, even. But if there's a historical precedent that back in the days of nought-six the MLB got too greedy and fans lost their connection and walked away... well businesses know there's no judge to whom they can argue to try to get that overturned. They'll be careful to not repeat those mistakes because their money depends on it.
(I guess it must be pretty hard to be greedy enough to be subject to the second kind of precedent, 'eh? We can see that in almost every industry. I guess that's why we need the lawmakers and courts to step in sometimes. I agree with you that this is one of those times.)
Microsoft has been constrained by a choice they made: to make binary backwards compatibility a major priority. Intel also prized backwards compatibility and Microsoft sticking with them for the long run helped also. Some (not all but quite a few) old old old old DOS programs still will run on Windows XP today; only the new 64-bit versions of Windows will cut off support for this stuff that's more than 20 years old.
Impressive, sure. But also problematic. The way I see it it's nice to be able to run old programs seamlessly. But I don't think Microsoft would lose much business if they just stopped supporting parts of the old API they didn't like. Software in active development would adjust; abandonware would be replaced, hopefully by something better. Life would go on. And if you ever really need to run some horribly old program virtualization technologies should be your answer. Far better in my opinion to annoy a minority of people depending on legacy code than to allow sloppy application coders to force almost all Windows users into bad security practices.
I simply don't understand why the lack of some third-party software should preclude a release. Best to have people testing out the browser itself in everyday situations so it's as solid as possible when those items are released.
Sure, some Linux users care about Flash and Java, but others don't. Might as well at least give'em the choice.
I don't think it's impossible to create DRM that won't undermine your system; DRM acheived with encryption can effectively limit the reading of a file to one computer or to that computer and a handful of devices. The DRM would enable the computer to read the file, not prevent it from doing anything. It would "work" (in the sense of preventing unauthorized listening) on any computer, music player or toaster, but only "work" (in the sense of allowing authorized listening) on suppported systems.
The real problem with, say, the Sony/Sunncomm DRM is that it's trying to prevent you from copying files that are written in an open format. Doing this means removing functionality from a system. Therefore the DRM must damage your system, but fortunately can only work on specific systems.
The type of DRM I described in the first paragraph is what the record companies really want. And if there must be a DRM system, I'd really it rather be one that wasn't going to try to harm my computer.
I guess the problem is that as long as the model persists in which albums are sold in physical form in stores and have to play on a variety of "consumer electronic" devices without hassle they will always have to be protected by the harmful type of DRM if they are to be protected. And yet this type of DRM is also doomed to failure (anything released on a CD that can be read in anything resembling a CD player will be on the Internet within a few days of its release, regardless of the DRM attached to it). It appears that DRM that degrades a CD's quality has been rejected, and we seem to be in the process of loudly rejecting DRM that tries to modify users' computers. I don't know if there are any more steps beyond creating a new encrypted music format and protecting the secret better than they did with DVDs.
In terms of writing a program for Mac that's absolutely true. In terms of working with the Wine project to build something for Unix in general it's absolutely wrong, since they'll spend a lot of their time duplicating the work of the current x11-based project instead of fixing the compatibility of desired apps.
Same deal with OpenOffice and much other OSS not having a Mac-specific port (and many other programs), only Windows and X11. By supporting X11 they meet their original goal, by supporting Windows they expose their software to a lot more users, by supporting Mac they'd get what?
Good point. One of the reasons there is such confusion is that there are multiple definitions for both atheism and agnosticism. The two most common definitions of atheism I see essentially boil down to: 1. Lack of belief in God 2. Belief that there is not a God
And the two most common definitions of agnosticism I see essentially boil down to: 1. Belief that it is impossible for people to know about the existence of God (the originally coined definition by Huxley, as parent said). 2. Lack of belief in God (the same as #1 for atheism, but these people usually emphasize that they don't believe against God either)
A lot of people that I've talked to use the #2 definitions for both terms, and others (like myself and the parent) use the #1 definitions for both, which is what confuses things.
I've seen some people that try to clear it up by calling agnosticism by the Huxley definition and then defining "Strong Atheism" to mean the affirmative belief that there is no God and "Weak Atheism" to mean the lack of a belief in God. This set of definitions is nice because it covers the bases, but I don't like to call my beliefs weak!;-)
I use both Portage and Ports, and there are some things that Portage does that Ports doesn't. For example, if you want to install some random package that might have a ton of dependencies, in Portage you can easily get a list of everything that will be installed when it's all said and done, and a prompt to allow or veto the installation based on this info (emerge -av foo). In Portage you have USE flags that can tell the system globally not to, for example, turn off Gnome-specific hooks if you don't have Gnome. Or to compile a version of octave without ATLAS (because I don't use octave enough that the speed advantage provided by ATLAS would justify the compile time, which on my old BSD machine would be measured in days; it can be done in BSD with some effort, but it can be done in Gentoo with almost none). I imagine those features would be pretty hard to implement in make. Probably a little easier in shell, probably easier than that in Python.
BSD Ports is clean and consistent, for sure, and it really feels like a natural extension of the Unix system. But Portage gives you a little more, and sometimes that little more is helpful.
At any rate, if your system is tight enough on space that you can't afford a Python installation then you probably won't have space for the Portage tree itself, and you're probably not working on a system that would enjoy doing much compiling either.
The thing that I don't understand is how getting rid of files would make a system less prone to "lock-in". Perhaps I'm lacking in imagination here, but without files you'd basically be using your whole hard drive as swap space and programs would just store all the "things they know" in their address space (IIRC this is basically the way EROS, an operating system based on capabilities rather than permissions (www.eros-os.org) works). But this would mean that in order to get at the data you'd actually have to ask the program for it! Or maybe I don't understand quite how EROS works either, as I've never used it.
I wouldn't call myself a web applications expert, but I've worked a bit on them and I'd say your solution should be to write yer own durn error pages. It's generally not a very good idea to expose error pages to users that you didn't write yourself. Writing your own error pages, besides being a good security practice (because you're not showing what kind of server and database technology you're using), also makes sure that you think about the types of errors that could occur and how to recover from them.
Though I'm sure you already knew that. Perhaps if your site is internal with just a few trusted users that already know what technology you're using it's not a big deal... though in that situation it would seem silly to roll your own CMS when there seemingly are many commercial and FOSS ones available for cheap or free.
I was fairly sure ISPs didn't have common-carrier status in the first place, and the reason was because they didn't want it. I don't remember why they didn't want it, though. At any rate, given the TOS of many ISPs as they stand they couldn't really be common carriers anyway because they ban too much stuff.
As a result, we have the silly situation where ISPs can be threatened with lawsuits if they don't cooperate with file sharing investigations... which doesn't necessarily bother me so much as that it applies to any other potential civil lawsuit. For example, if I was accused of slandering someone with my Internet connection, the offended party would go to the ISP threatening to sue them if they don't stop me, rather than going straight to me and dealing with the problem like civilized litigious bastards. Thus, my ISP (Comcast in Champaign, IL) prohibits using their connection to transmit any material that "a reasonable person" could construe as "embarassing" (and a whole host of other things too, such as "pornographic", "obscene" and even "distressing", which means I'd better stop using the Internet to discuss things like... reality...).
So no, I'm pretty sure ISPs aren't common carriers, despite the common slashdot myth.
I've never had Carpal Tunnel, but I used to have a cyst in my right wrist, which would cause pain if I overused it. It seems to be better with a trackball than a mouse, but sometimes anything is painful. So I just found an old junker mouse lying around (had to find one that was not right-hand specific as was the fad for a while) and have it connected and placed to the left of the keyboard while my trackball (which is a right-hander) is to the right.
Sometimes when the pain was very bad I typed with just my left hand also. Used the space between 'f' and 'j' for a home row, unless there were a bunch of left-side letters in a row, in which case I moved over to the left side. Never got very fast at it, though, or managed to completely type without looking at the keyboard.
The fact that they're releasing the spec and an open-source library should mean that once your Jabber client has Jingle support you can chat with anyone on any server that will peer with yours. Now, granted, that doesn't include their server, but that's their loss; you could just go to some other random server that would allow it.
Yeah, server-to-server would be cool, but we already have server-to-server and it works as long as it stays small enough that the spammers don't notice. Google wants to make this thing huge, and if they do, spammers will notice.
Unless "gtalk" is something different than I'm thinking of it just uses XMPP, aka the Jabber protocol. I think you can use any Jabber client to access it. I guess the voice stuff probably wouldn't work... personally I don't care about anything on IM networks as long as the text goes through.
If you're Apple you can prevent people from thinking because they'll never have to configure much because the software and hardware are one package that you control.
If you're Microsoft you can prevent people from thinking because though you don't make the hardware you're bigger than all the hardware makers and they'll make their hardware work with your software (think laptops and ACPI) and write drivers for you.
If you're KDE or Gnome you have a lot more work to do. You have a ton of hardware configurations to deal with. Your software must run under many versions of Linux, *BSD and various commercial Unixen; furthermore since there's no strong "Unix authority" for certain things you have to deal with users that want to use some parts of your desktop and libraries but not others (I had to install tons of KDE libs to get Rosegarden working, for example, but I want nothing to do with arts). Relatedly, the underlying servers were written by different authors with different ideas of how to handle configuration. Try to imagine writing a GUI configurator for Apache. There are many ways to write an httpd.conf file that mean exactly the same thing, so if you want your GUI to understand and edit the httpd.conf file correctly you'd better hope the user isn't editing it by hand. So you're probably best off getting as many of the settings in the GUI as possible.
There necessarily is a lot of configuration to do if you expect a Unix desktop to match the functionality of a Windows desktop with all of the installed drivers. This particular comment by Linus was about printer drivers. If you remove some of the complexity from a screen you'll probably only have to use once while configuring your printer you'll force the user to the command line to do something that the desktop won't recognize (so there's a chance the configuration would be ruined if the user ever went back to that screen to change some other settings).
Slashdot Mirror
I don't know a lot about ISPs and the peering agreements between them, but I would think there's a good chance that if BellSouth tries to extract fees from individual companies for use of bandwidth, that would be a violation of those agreements. At least it's a violation in spirit, because the cost that Google pays to be served to BellSouth's customers is part of the cost they pay to their ISP, which agrees to exchange traffic with BellSouth.
I think that if the other giant ISPs wanted to stop this they could demand terms in peering agreements that these dealings could not happen.
But then again, I admit that my understanding of this situation is far from full.
Yup. This is, in general, a problem that happens whenever server software asks a bunch of client computers for information and depends on the returned results to be honest. Only this time, it doesn't seem that there would be any particular reward for, say, visiting advertising sites a particular number of times or anything like that. As long as they build their scheme such that there's no reward for browsing for more than a few hours a day they can probably avoid shenanigans aimed simply at making money. And since I really doubt that too many people are going to go out of their way to mess up this company's statistics with no profit involved, they could rest easy.
Actually, I was thinking about this again, and when I wrote my previous post (parent) I was thinking about the GPL as a license for arbitrary software projects and not what RMS is thinking about, which is the GPL as the license for the GNU project.
The goal of GNU, of course, is and always was "political", revolutionary and "subversive" (to the non-Free vendors; to RMS it is the restrictive vendors that are subversive to the ideals that governed the early software world, but since I wasn't alive back then I can't really offer my personal perspective on that). RMS is creating a license that expresses what he wants for his GNU project.
Not every person that creates GPL-licensed software has the same goals as GNU, and this has always been the case. But the old GPL, expressing a limited set of GNU's goals, still managed to resonate with a lot of these developers. The new GPL will force people to really evaluate their views on the software world and why they contribute their time and effort to Free Software. If enough people are turned off by the restrictions of the new GPL, we might witness the birth of a GAGWITINU (GAGWITINU Ain't GNU, Which In Turn Is Not Unix). And wouldn't that be fun?
So what happens then - I give you software with DRM with the GPL v2 or later, but the v3 causes problems with the DRM.
Actually as long as you distribute your software under GPL v2 you're fine; if someone else decides to distribute the same software with DRM under the terms of GPL v3 then they're the ones who have violated the license. Oddly enough, they've violated a license offered to them by you, not the other way around.
On your last point I agree; the "or later" clause to me means that anyone could choose to distribute so-licensed software under the terms of GPLv2 or GPLv3. But IANAL and there might be some other effect.
I don't think, however, that GPLv2 expresses the FSF's political views in the same was that GPLv3 does. GPLv2 restricts only the ways that derivative works can be distributed (they must be distributed with source). GPLv3 also appears to restrict the function of your derivative works (they cannot be used for DRM). And I think it means that using GPLv3 on your own servers to facilitate DRM is also not allowed (might be wrong on that one though) which would make it an end-user license.
GPLv2 expresses FSF's views on software distribution, while GPLv3 expresses FSF's views on software function. There is a big difference, and it could cause a lot of problems in the Free Software community. I can't say I agree with the changes in GPLv3, as someone that often waffles between preferring BSD-style licenses and GPLv2-style ones.
Being a geek isn't about technology. I know lots of geeks that aren't really all that fascinated with technology. They might be art geeks, language geeks, philosophy geeks or math geeks, and when I (as a computer geek) talk to those people it's like we're speaking a common language. It's the language of inquiry and passion for understanding. They want to understand a bit about why I get so pissed off at BellSouth or SCO, or what Linux is (and I usually tell them "It's acutally GNU/Linux" and then go off on a Stallmanesque rant). I want to understand the difference between artistic and musical minimalism or what the Incompleteness Theorem actually means.
Wow, I must have forgotten to take my cynicism pill before that post.
God damn. I have ranted many times on this website about people that use excessive line lengths. I program in fucking vim, often in the console. For those situations limiting line length to 80 characters is what should be done. When making plain old text files designed to be viewed straight on screens that's what should be done. In fact I've argued on slashdot before that programming is much easier when lines are truncated at less than 80 characters (In some programs a 70-character line looks out of place, so I'll split that too).
On web pages that's not what should be done. Leave out the BR tags and let the web browser do the word wrapping. The way this page rendered on my computer I had to widen my browser window so the wasn't wrapping around before 80 characters. It looked like this:
Here is some text blah blah blah text
and the end
of each 80-character line wraps to the
next line
making it very hard to read.
In VIM when you have text that looks like this you can put your cursor in the paragraph and type "gqap" and it formats the current paragraph with line breaks matching your terminal width. This is good. It appears that the web page linked to in the article summary was generated dynamically by Plone from a text file with linebreaks every 80 characters (which is a fine way to write a text file), but since everyone's browser windows are different sizes Plone should use similar logic to VIM to strip out all the linebreaks that don't mean "new paragraph" before converting line breaks to BR tags.
I don't know how your ass gets modded up insightful by flaming me about e-mail. I get my e-mail with mutt on the fucking console. In the mother fucking nineties dumb e-mail programs when sending a quote in a reply would take text formatted to 80 characters, stick a few characters at the beginning of each line and just send it off, leading to the same thing that happens with this article viewed in a narrow browser window. That's what I mean by 90s e-mail. Plain text e-mail is a good thing. Programs should figure out how to deal with it intelligently. Just like that this new GPL document being plain text, 80 characters is a good thing, but Plone should create output suited for the web.
Yeah, this would mean that plone would have to have different rules for displaying text than code. But if you're displaying a web site you should display it like a web site. In fact, the BR nonsense should be replaced with P tags!
Gah... why couldn't there be a web page that didn't have BR tags at the 80-character mark every time. This is like reading e-mail in the 90s! (Actually this looks like a plone-based site so it's probably serving up auto-generated *ml from a text file... which is no excuse, really. If vim can fix up stuff like that then plone could too.)
The problem is the "legacy code" in Vista is going to be Win32 - and there's a hell of a lot fo Win32 out there.
We've all heard stories about how Win32 got to be a beast because some bugs had to be maintained in order to keep certain software working. Win32 is OK to keep around, and even those long-standing bugs can be kept around to keep things working. But they should take a real look as they re-implement some of that functionality: does any of this cause security problems? When bugs appear in any of the new Vista APIs they should fix them, announce to the developers that xxxyyy function has changed so its behavior is now correct, and they should retest all their software and be prepared to offer updates. Apple does this; they're willing to break backwards compatibility and keep developers from holding them back. (Apple had been changing things in OSX really quickly for a while, it seems to me, and developers there were forcing users to buy OS upgrades to use their new software! I don't know how expensive this was for them or anything, as I don't own a Mac.)
The real danger, though, isn't the use of old APIs, it's the use of old security practices. I think that if at the introduction of NT, or at least at NT4 or 2000 Microsoft had really stressed the importance of non-priviledged user accounts and asked developers to fix software that needed Administrator priviledges in stupid times they could have saved everyone from certain problems. If they had that kind of attitude, they have the size to pull it off. Learn to read; I didn't say MS forced developers to write bad code, I said sloppy developers force users into bad security practices like running as Admin, but that MS has allowed this for way too long. In Vista they ought to take the simple solution to the problem and just tell developers that they actually plan on strongly encouraging user accounts this time around at that they'd better fix their broken software.
Well one might say there are multiple kind of precedent. There is precedent in the legal sense where our courts must decide whether these statistics can be owned, and there is also what one might call "historical precedent". Businesses will constantly try to bend the law in their favor, even if historically rulings have gone the other way. Big and powerful businesses have a pretty good chance of doing it, even. But if there's a historical precedent that back in the days of nought-six the MLB got too greedy and fans lost their connection and walked away... well businesses know there's no judge to whom they can argue to try to get that overturned. They'll be careful to not repeat those mistakes because their money depends on it.
(I guess it must be pretty hard to be greedy enough to be subject to the second kind of precedent, 'eh? We can see that in almost every industry. I guess that's why we need the lawmakers and courts to step in sometimes. I agree with you that this is one of those times.)
Microsoft has been constrained by a choice they made: to make binary backwards compatibility a major priority. Intel also prized backwards compatibility and Microsoft sticking with them for the long run helped also. Some (not all but quite a few) old old old old DOS programs still will run on Windows XP today; only the new 64-bit versions of Windows will cut off support for this stuff that's more than 20 years old.
Impressive, sure. But also problematic. The way I see it it's nice to be able to run old programs seamlessly. But I don't think Microsoft would lose much business if they just stopped supporting parts of the old API they didn't like. Software in active development would adjust; abandonware would be replaced, hopefully by something better. Life would go on. And if you ever really need to run some horribly old program virtualization technologies should be your answer. Far better in my opinion to annoy a minority of people depending on legacy code than to allow sloppy application coders to force almost all Windows users into bad security practices.
I simply don't understand why the lack of some third-party software should preclude a release. Best to have people testing out the browser itself in everyday situations so it's as solid as possible when those items are released.
Sure, some Linux users care about Flash and Java, but others don't. Might as well at least give'em the choice.
I don't think it's impossible to create DRM that won't undermine your system; DRM acheived with encryption can effectively limit the reading of a file to one computer or to that computer and a handful of devices. The DRM would enable the computer to read the file, not prevent it from doing anything. It would "work" (in the sense of preventing unauthorized listening) on any computer, music player or toaster, but only "work" (in the sense of allowing authorized listening) on suppported systems.
The real problem with, say, the Sony/Sunncomm DRM is that it's trying to prevent you from copying files that are written in an open format. Doing this means removing functionality from a system. Therefore the DRM must damage your system, but fortunately can only work on specific systems.
The type of DRM I described in the first paragraph is what the record companies really want. And if there must be a DRM system, I'd really it rather be one that wasn't going to try to harm my computer.
I guess the problem is that as long as the model persists in which albums are sold in physical form in stores and have to play on a variety of "consumer electronic" devices without hassle they will always have to be protected by the harmful type of DRM if they are to be protected. And yet this type of DRM is also doomed to failure (anything released on a CD that can be read in anything resembling a CD player will be on the Internet within a few days of its release, regardless of the DRM attached to it). It appears that DRM that degrades a CD's quality has been rejected, and we seem to be in the process of loudly rejecting DRM that tries to modify users' computers. I don't know if there are any more steps beyond creating a new encrypted music format and protecting the secret better than they did with DVDs.
In terms of writing a program for Mac that's absolutely true. In terms of working with the Wine project to build something for Unix in general it's absolutely wrong, since they'll spend a lot of their time duplicating the work of the current x11-based project instead of fixing the compatibility of desired apps.
Same deal with OpenOffice and much other OSS not having a Mac-specific port (and many other programs), only Windows and X11. By supporting X11 they meet their original goal, by supporting Windows they expose their software to a lot more users, by supporting Mac they'd get what?
Good point. One of the reasons there is such confusion is that there are multiple definitions for both atheism and agnosticism. The two most common definitions of atheism I see essentially boil down to:
;-)
1. Lack of belief in God
2. Belief that there is not a God
And the two most common definitions of agnosticism I see essentially boil down to:
1. Belief that it is impossible for people to know about the existence of God (the originally coined definition by Huxley, as parent said).
2. Lack of belief in God (the same as #1 for atheism, but these people usually emphasize that they don't believe against God either)
A lot of people that I've talked to use the #2 definitions for both terms, and others (like myself and the parent) use the #1 definitions for both, which is what confuses things.
I've seen some people that try to clear it up by calling agnosticism by the Huxley definition and then defining "Strong Atheism" to mean the affirmative belief that there is no God and "Weak Atheism" to mean the lack of a belief in God. This set of definitions is nice because it covers the bases, but I don't like to call my beliefs weak!
I use both Portage and Ports, and there are some things that Portage does that Ports doesn't. For example, if you want to install some random package that might have a ton of dependencies, in Portage you can easily get a list of everything that will be installed when it's all said and done, and a prompt to allow or veto the installation based on this info (emerge -av foo). In Portage you have USE flags that can tell the system globally not to, for example, turn off Gnome-specific hooks if you don't have Gnome. Or to compile a version of octave without ATLAS (because I don't use octave enough that the speed advantage provided by ATLAS would justify the compile time, which on my old BSD machine would be measured in days; it can be done in BSD with some effort, but it can be done in Gentoo with almost none). I imagine those features would be pretty hard to implement in make. Probably a little easier in shell, probably easier than that in Python.
BSD Ports is clean and consistent, for sure, and it really feels like a natural extension of the Unix system. But Portage gives you a little more, and sometimes that little more is helpful.
At any rate, if your system is tight enough on space that you can't afford a Python installation then you probably won't have space for the Portage tree itself, and you're probably not working on a system that would enjoy doing much compiling either.
The thing that I don't understand is how getting rid of files would make a system less prone to "lock-in". Perhaps I'm lacking in imagination here, but without files you'd basically be using your whole hard drive as swap space and programs would just store all the "things they know" in their address space (IIRC this is basically the way EROS, an operating system based on capabilities rather than permissions (www.eros-os.org) works). But this would mean that in order to get at the data you'd actually have to ask the program for it! Or maybe I don't understand quite how EROS works either, as I've never used it.
I wouldn't call myself a web applications expert, but I've worked a bit on them and I'd say your solution should be to write yer own durn error pages. It's generally not a very good idea to expose error pages to users that you didn't write yourself. Writing your own error pages, besides being a good security practice (because you're not showing what kind of server and database technology you're using), also makes sure that you think about the types of errors that could occur and how to recover from them.
Though I'm sure you already knew that. Perhaps if your site is internal with just a few trusted users that already know what technology you're using it's not a big deal... though in that situation it would seem silly to roll your own CMS when there seemingly are many commercial and FOSS ones available for cheap or free.
http://yro.slashdot.org/article.pl?sid=05/08/07/12 40206&tid=123&tid=215&tid=95
(there ya go... Internet service is considered an "information service", not a "common carrier", according to /.)
I was fairly sure ISPs didn't have common-carrier status in the first place, and the reason was because they didn't want it. I don't remember why they didn't want it, though. At any rate, given the TOS of many ISPs as they stand they couldn't really be common carriers anyway because they ban too much stuff.
As a result, we have the silly situation where ISPs can be threatened with lawsuits if they don't cooperate with file sharing investigations... which doesn't necessarily bother me so much as that it applies to any other potential civil lawsuit. For example, if I was accused of slandering someone with my Internet connection, the offended party would go to the ISP threatening to sue them if they don't stop me, rather than going straight to me and dealing with the problem like civilized litigious bastards. Thus, my ISP (Comcast in Champaign, IL) prohibits using their connection to transmit any material that "a reasonable person" could construe as "embarassing" (and a whole host of other things too, such as "pornographic", "obscene" and even "distressing", which means I'd better stop using the Internet to discuss things like... reality...).
So no, I'm pretty sure ISPs aren't common carriers, despite the common slashdot myth.
I've never had Carpal Tunnel, but I used to have a cyst in my right wrist, which would cause pain if I overused it. It seems to be better with a trackball than a mouse, but sometimes anything is painful. So I just found an old junker mouse lying around (had to find one that was not right-hand specific as was the fad for a while) and have it connected and placed to the left of the keyboard while my trackball (which is a right-hander) is to the right.
Sometimes when the pain was very bad I typed with just my left hand also. Used the space between 'f' and 'j' for a home row, unless there were a bunch of left-side letters in a row, in which case I moved over to the left side. Never got very fast at it, though, or managed to completely type without looking at the keyboard.
Easy: the researchers perfected a revolutionary technique of writing non-male software!
The fact that they're releasing the spec and an open-source library should mean that once your Jabber client has Jingle support you can chat with anyone on any server that will peer with yours. Now, granted, that doesn't include their server, but that's their loss; you could just go to some other random server that would allow it.
Yeah, server-to-server would be cool, but we already have server-to-server and it works as long as it stays small enough that the spammers don't notice. Google wants to make this thing huge, and if they do, spammers will notice.
Unless "gtalk" is something different than I'm thinking of it just uses XMPP, aka the Jabber protocol. I think you can use any Jabber client to access it. I guess the voice stuff probably wouldn't work... personally I don't care about anything on IM networks as long as the text goes through.
If you're Apple you can prevent people from thinking because they'll never have to configure much because the software and hardware are one package that you control.
If you're Microsoft you can prevent people from thinking because though you don't make the hardware you're bigger than all the hardware makers and they'll make their hardware work with your software (think laptops and ACPI) and write drivers for you.
If you're KDE or Gnome you have a lot more work to do. You have a ton of hardware configurations to deal with. Your software must run under many versions of Linux, *BSD and various commercial Unixen; furthermore since there's no strong "Unix authority" for certain things you have to deal with users that want to use some parts of your desktop and libraries but not others (I had to install tons of KDE libs to get Rosegarden working, for example, but I want nothing to do with arts). Relatedly, the underlying servers were written by different authors with different ideas of how to handle configuration. Try to imagine writing a GUI configurator for Apache. There are many ways to write an httpd.conf file that mean exactly the same thing, so if you want your GUI to understand and edit the httpd.conf file correctly you'd better hope the user isn't editing it by hand. So you're probably best off getting as many of the settings in the GUI as possible.
There necessarily is a lot of configuration to do if you expect a Unix desktop to match the functionality of a Windows desktop with all of the installed drivers. This particular comment by Linus was about printer drivers. If you remove some of the complexity from a screen you'll probably only have to use once while configuring your printer you'll force the user to the command line to do something that the desktop won't recognize (so there's a chance the configuration would be ruined if the user ever went back to that screen to change some other settings).