Just as a woman has the right to terminate an unwanted pregnancy. Just as any person should be able to make a decision/carry out the wishes of an individual's euthenasia. eg. cases of terminal illness
There is still a large difference between the examples you give (which amount to honouring a mentally sane and mature person's explicitly stated wishes) and the example you respond to (a newborn child is not a mentally sane and mature person yet) as well as other cases (people who are no longer capable of expressing their wishes and haven't explicitly stated them when they still could).
Don't get me wrong - I'm not arguing that euthanesia is morally reprehensible in those cases, I'm merely saying that these situations aren't equivalent.
Given that your company has stated it does not consider Linux a competitor in either the server or the desktop market, why is it actively spreading Fear, Uncertainty and Doubt about Linux, and how do you explain the huge growth of this operating environment?
Given the scale involved, it might be unworkable to rely solely on raters one knows already. Perhaps a "web of trust"-like structure (like in PGP) might be workable. E.g. I trust Linus Torvalds as a rater of Linux-related material, and Linus trusts Alan Cox as a rater of same, so through weak transitivity, I trust Alan Cox a little as a rater of Linux-related material because Linus trusts him and I trust linus.
Also, it might be a good idea to have some kind of "matching" system whereby your taste (in raters or items) is matched to other's so that their opinions can be taken into account. This is somewhat similar a recommendation service I've seen on amazon. I haven't studied GroupLens in detail, but perhaps it has these aspects too.
To make things more manageable. Look at usenet, it is currently an extreme case of "information overload". There's quite a lot of good/interesting stuff in it, but sometimes it's like sifting cubic meters of sea water to filter out gold atoms: not worth it.
Information overload is IMO becoming a real problem. Collaborative rating might provide a way to deal with it.
Maybe segfault's License Codes story might become ha-ha only serious. I doubt it though, as there is a strong tendency to reinvent the wheel when it comes to licenses. But who knows. Try proposing it on the license-discuss list (preferably with a concrete template).
Though I don't see how this debunks the notion that encapsulation, and subsequent ease of code maintenance, is not a primary factor is the widespread acceptance of OOP and/or C++.
I didn't intend to debunk this notion, but rather I intended to offer a slightly different perspective on it. In my view OO(P)'s success results from it being the right tool for more jobs than procedural modelling/programming ("if all you have is a hammer, every problem looks like a nail"). Encapsulation just a part of it (as is e.g. the notion of inheritance) and the easier code maintenance is also because the program is more similar to one's mental map of the problem domain than a procedural program for the same problem.
I believe difficulty in code maintenance with languages such as C was one of the primary reasons for the spawning of object oriented programming languages (complex and sometimes unwieldly though they may be to many), such as C++.
Not really. Simula is generally considered to be the first object-oriented language (i.e. being built around the notion of classes: entities which encompass both data and behaviour). It builds on Algol60 and was defined in 1967; it predates both C and Pascal which are early seventies.
Object-orientation gained popularity through SmallTalk (late seventies).
C++ isn't a pure OO language; it's a procedural/OO hybrid language due to being based on C. It's unwieldyness isn't explained by this. Other OO and OO/hybrid languages (say Objective C which was a stronger influence on Java's OO nature than C++) are a lot less unwieldy.
Nowadays, Object Orientation and OO programming are popular because they allow for a more natural modelling of problem domains and implementations of solutions than the procedural approach which makes it possible to deal with larger problem sizes.
The Hurd still has some very neat ideas that appeal to kernel hackers. I really don't know if it will be successful, it's still in early development. If it picks up enough steam, it may well make it, as it can run just about everything Linux runs.
I fail to see what's wrong with Qt. It looks like a nice toolkit, and Qt2 is licensed under a DFSG-free license (the QPL).
The real problem is that many Qt-using applications are licensed under the GPL and that the GPL and QPL interact badly. The KDE developers are migrating from the GPL to the Artistic license, which will end this problem.
Isn't this something for YRO? While I despise virus writers as much as the next guy, I find the idea of being forbidden to code something in the privacy of your own system very chilling, in the order of surpressing knowledge/censorship/dystopia.
Plus ça change, plus ce la même chose (sp). The immanent arrival of AI has been a constant prediction of both science and SF since at least the development of electronic computers (Alan Turing already worked on a minimax-based Chess program), but IMHO what AI has shown us so far is what intelligence is not (one of definitions of AI is perhaps the most and the least revealing simultaneously: that which computers can't do yet).
It has been argued very persuasively that traditional top-down AI won't work (see e.g. Hofstadter's Gödel, Escher, Bach), and while bottom-up AI (be it artificial life, neural networks or evolutionary computation) has produced some interesting results (like the WEBSOM classification system), I'm still very skeptical about "Real Soon Now" predictions of AI.
Of course, I still hope someone proves me wrong (and that if they do that it's going to be "interesting times" but not in the Chinese curse sense).
There's Qui-ne-faut. I haven't studied it in detail, but on a trial run it was at least isolating character shapes well (though the actual identification of characters from them left much to be desired - probably there's some training needed).
Am I restricted to using the RSA ciphers in the US?
Unless you have very good reasons, avoid RSA. While it is quite efficient, it is encumbered by a patent in the US. Unencumbered alternatives, like Diffie-Hellman (patent has expired), exist.
If not then I can use Blowfish or the like and avoid patent royalties.
Apples and oranges. In general, there are two kinds of ciphers:
Public key algorithms, like RSA and Diffie-Hellman. These need no prior secure channel to exchange keys, but are highly computationally intensive.
Private/shared key algorithms, like Blowfish, Twofish, Rijndael, DES etc. These are computationally efficient, but require negotiating a key beforehand (via some sort of secure channel, e.g. meeting in person).
Due to the nature of the algorithms, systems like SSL and SSH combine both types: a public key algorithm is used to securely exchange a session key (for a shared-key algorithm); as such a key is small, it's not too computationally intensive to do so. That session key is then used to encrypt the remainder of the conversation using a shared-key algorithm.
So, for SSL communication without patent hassles, you need to choose an unencumbered public key algorithm (say Diffie-Hellman) and an unencumbered private key algorithm (like 3DES, Blowfish, Twofish, Rijndael, arcfour, RC5).
Wouldn't it be a blatant violation of the GPL if Cobalt had ported linux to MIPS and not returned the changes it made to the community?
No. The GPL imposes an obligation to provide source to those whom you have supplied with binaries, not to the copyright holder of the code, Linus Torvalds or Joe Random Hacker.
RPM and DPKG are really convenient in terms of putting the stuff on your HD and removing it, but then what?
I don't think you're giving dpkg enough credit here (and probably RPM too, but I'm not very familiar with it). Properly managed packages do a lot more than just install and deinstall. They also ensure consistency (via package relationships like Depends:, Recommends:, Suggests:, Conflicts:, Replaces: and Provides:), ensure a safe default configuration and a convenient way to configure packages, register themselves with the menu system (so not just GNOME but also pdmenu, windowmaker, mwm, fvwm etc. know about them), register their documentation with documentation systems like dwww, register themselves as MIME handlers through mime-support etc. etc.
To a large degree, having a policy that is adhered to by package maintainers is more important than the particular packaging system.
So a newbie who downloads something from freshmeat
I know few if any newbies who even know of freshmeat's existance. And in any case, distributions were invented to allow new users not to have to deal with tarballs found on the net directly.
LWN's 1998 Linux timeline had a nice little sidebar about the consistency of Mr. Berst's opinions about Linux.
Linux according to Jesse Berst "I think it's great if you are willing to promote Linux to your boss. As long as you are aware of the risk you are taking. The risk of getting fired." (Feb. 16). "Is a Linux takeover likely? Give me a break. Of course not." (June 23). "I personally think Windows NT will be the mainstream operating system within a few years." [...] "My belief: Linux will never go mainstream" (Sep. 9). "I've always said that Linux could become a serious challenger to Microsoft's Windows NT." Sep. 28).
There's also a Linuxworld review, which goes into this: Fortunately, Corel noted that it plans to return all of its enhancements to the community by making them open source. The exact license has not yet been determined.
I think all of the/. community wishes that people would just stick with the GPL (and LGPL), because that's what got us this far in the first place
In this case, GPL isn't an option, as the GPL and the QPL interact badly. GPL with an exception clause to remove that bad interaction would work (but would of course itself not be compatible with pure GPLed code).
Also, I'm sure that there are BSDers in the/. community who will point out that we got this far also in part due to non-(L)GPLed free software.
The GPL and LGPL are good licenses in many circumstances, but they are not the license panacea (no license is).
Lizard uses Qt, so putting it under the GPL would result in another KDE license issue. Qt's license (be it the old non-free one or the new free QPL) is not compatible with the GPL.
Don't complain about the existence of reasonable rules; don't complain about people enforcing reasonable rules.
I'm not convinced that requiring PDF is a reasonable rule; it offers few if any advantages over other formats. There is little in crypto design documents that requires total control over presentation, so e.g. HTML would have done just as well, and be a whole lot less to download for us poor folks in countries where bandwidth costs real money.
From NIST, being a body concerned with standards, I would find a requirement for documentation submitted in an official standard format (say SGML or XML) more logical than a requirement for a de-facto format like PDF.
Slashdot Mirror
There is still a large difference between the examples you give (which amount to honouring a mentally sane and mature person's explicitly stated wishes) and the example you respond to (a newborn child is not a mentally sane and mature person yet) as well as other cases (people who are no longer capable of expressing their wishes and haven't explicitly stated them when they still could).
Don't get me wrong - I'm not arguing that euthanesia is morally reprehensible in those cases, I'm merely saying that these situations aren't equivalent.
Given that your company has stated it does not consider Linux a competitor in either the server or the desktop market, why is it actively spreading Fear, Uncertainty and Doubt about Linux, and how do you explain the huge growth of this operating environment?
Also, it might be a good idea to have some kind of "matching" system whereby your taste (in raters or items) is matched to other's so that their opinions can be taken into account. This is somewhat similar a recommendation service I've seen on amazon. I haven't studied GroupLens in detail, but perhaps it has these aspects too.
To make things more manageable. Look at usenet, it is currently an extreme case of "information overload". There's quite a lot of good/interesting stuff in it, but sometimes it's like sifting cubic meters of sea water to filter out gold atoms: not worth it.
Information overload is IMO becoming a real problem. Collaborative rating might provide a way to deal with it.
Maybe segfault's License Codes story might become ha-ha only serious. I doubt it though, as there is a strong tendency to reinvent the wheel when it comes to licenses. But who knows. Try proposing it on the license-discuss list (preferably with a concrete template).
I didn't intend to debunk this notion, but rather I intended to offer a slightly different perspective on it. In my view OO(P)'s success results from it being the right tool for more jobs than procedural modelling/programming ("if all you have is a hammer, every problem looks like a nail"). Encapsulation just a part of it (as is e.g. the notion of inheritance) and the easier code maintenance is also because the program is more similar to one's mental map of the problem domain than a procedural program for the same problem.
Not really. Simula is generally considered to be the first object-oriented language (i.e. being built around the notion of classes: entities which encompass both data and behaviour). It builds on Algol60 and was defined in 1967; it predates both C and Pascal which are early seventies.
Object-orientation gained popularity through SmallTalk (late seventies).
C++ isn't a pure OO language; it's a procedural/OO hybrid language due to being based on C. It's unwieldyness isn't explained by this. Other OO and OO/hybrid languages (say Objective C which was a stronger influence on Java's OO nature than C++) are a lot less unwieldy.
Nowadays, Object Orientation and OO programming are popular because they allow for a more natural modelling of problem domains and implementations of solutions than the procedural approach which makes it possible to deal with larger problem sizes.
It's not smelling funny: there's a Debian GNU/Hurd port in progress; see Kernel Cousin debian-hurd for progress info.
The Hurd still has some very neat ideas that appeal to kernel hackers. I really don't know if it will be successful, it's still in early development. If it picks up enough steam, it may well make it, as it can run just about everything Linux runs.
The real problem is that many Qt-using applications are licensed under the GPL and that the GPL and QPL interact badly. The KDE developers are migrating from the GPL to the Artistic license, which will end this problem.
Isn't this something for YRO? While I despise virus writers as much as the next guy, I find the idea of being forbidden to code something in the privacy of your own system very chilling, in the order of surpressing knowledge/censorship/dystopia.
In true 1984 style, it should be the 13 o'clock position of course (we're already at 12 o'clock).
Because that's not a proverb in English? Proverbs have a compactness and impact of expression that rephrasings or translations often lack.
Saying something in another language doesnt make anyone sound smarter (unless they are translating it)
I'm already saying things in another language - I'm not a native speaker of English.
It has been argued very persuasively that traditional top-down AI won't work (see e.g. Hofstadter's Gödel, Escher, Bach), and while bottom-up AI (be it artificial life, neural networks or evolutionary computation) has produced some interesting results (like the WEBSOM classification system), I'm still very skeptical about "Real Soon Now" predictions of AI.
Of course, I still hope someone proves me wrong (and that if they do that it's going to be "interesting times" but not in the Chinese curse sense).
There's Qui-ne-faut. I haven't studied it in detail, but on a trial run it was at least isolating character shapes well (though the actual identification of characters from them left much to be desired - probably there's some training needed).
See e.g. the SuSE announcement.
Unless you have very good reasons, avoid RSA. While it is quite efficient, it is encumbered by a patent in the US. Unencumbered alternatives, like Diffie-Hellman (patent has expired), exist.
If not then I can use Blowfish or the like and avoid patent royalties.
Apples and oranges. In general, there are two kinds of ciphers:
Due to the nature of the algorithms, systems like SSL and SSH combine both types: a public key algorithm is used to securely exchange a session key (for a shared-key algorithm); as such a key is small, it's not too computationally intensive to do so. That session key is then used to encrypt the remainder of the conversation using a shared-key algorithm.
So, for SSL communication without patent hassles, you need to choose an unencumbered public key algorithm (say Diffie-Hellman) and an unencumbered private key algorithm (like 3DES, Blowfish, Twofish, Rijndael, arcfour, RC5).
Yes. This is one of the options being discussed.
Additionally, I'd like to point out that DNSSEC does not depend on RSA; other signature systems (DH and DSA) are possible too.
No. The GPL imposes an obligation to provide source to those whom you have supplied with binaries, not to the copyright holder of the code, Linus Torvalds or Joe Random Hacker.
Check out the story on the other side of the pond.
I don't think you're giving dpkg enough credit here (and probably RPM too, but I'm not very familiar with it). Properly managed packages do a lot more than just install and deinstall. They also ensure consistency (via package relationships like Depends:, Recommends:, Suggests:, Conflicts:, Replaces: and Provides:), ensure a safe default configuration and a convenient way to configure packages, register themselves with the menu system (so not just GNOME but also pdmenu, windowmaker, mwm, fvwm etc. know about them), register their documentation with documentation systems like dwww, register themselves as MIME handlers through mime-support etc. etc.
To a large degree, having a policy that is adhered to by package maintainers is more important than the particular packaging system.
So a newbie who downloads something from freshmeat
I know few if any newbies who even know of freshmeat's existance. And in any case, distributions were invented to allow new users not to have to deal with tarballs found on the net directly.
Linux according to Jesse Berst
"I think it's great if you are willing to promote Linux to your boss. As long as you are aware of the risk you are taking. The risk of getting fired." (Feb. 16).
"Is a Linux takeover likely? Give me a break. Of course not." (June 23).
"I personally think Windows NT will be the mainstream operating system within a few years." [...] "My belief: Linux will never go mainstream" (Sep. 9).
"I've always said that Linux could become a serious challenger to Microsoft's Windows NT." Sep. 28).
There's also a Linuxworld review, which goes into this: Fortunately, Corel noted that it plans to return all of its enhancements to the community by making them open source. The exact license has not yet been determined.
In this case, GPL isn't an option, as the GPL and the QPL interact badly. GPL with an exception clause to remove that bad interaction would work (but would of course itself not be compatible with pure GPLed code).
Also, I'm sure that there are BSDers in the /. community who will point out that we got this far also in part due to non-(L)GPLed free software.
The GPL and LGPL are good licenses in many circumstances, but they are not the license panacea (no license is).
Lizard uses Qt, so putting it under the GPL would result in another KDE license issue. Qt's license (be it the old non-free one or the new free QPL) is not compatible with the GPL.
I'm not convinced that requiring PDF is a reasonable rule; it offers few if any advantages over other formats. There is little in crypto design documents that requires total control over presentation, so e.g. HTML would have done just as well, and be a whole lot less to download for us poor folks in countries where bandwidth costs real money.
From NIST, being a body concerned with standards, I would find a requirement for documentation submitted in an official standard format (say SGML or XML) more logical than a requirement for a de-facto format like PDF.