Well, that's very interesting. Except that most of the information I've found today says that the 760MP chipset is due out in Q4 of 2000, with motherboards arriving around the same time, or very shortly thereafter.
Once again I have to thank you for going that extra mile towards making Slashdot a better place. Your 'help' towards answering a simple question is greatly appreciated.
Thanks for the URL. Most of the sites I've checked for info are more general hardware and tech sites, I don't have URLs for very many AMD specific ones.
Actually, he's been to a great deal of hardware sites, but he found very little solid information.
First, he went to AMD's web site. He browsed it thoroughly, and then did a number of searches. He discovered that AMD has essentially no information on their website about SMP, period. Almost no mention of it, even.
He then checked out Tom's hardware, Ars Technica, as well as 4 other similar hardware review and news sites. Do you know what he found there? A few rumors about AMD's supporting SMP, a single mention of 760MP chipset, without any dates or informaiton on it, and a couple of claims that AMD would have an SMP motherboard out sometime in 2001.
He wasn't impressed with most of the information out there.
You see, I wasn't looking for vague rumors, I was looking for facts. I was hoping that someone might have heard something from a reputable source, or someone might have a URL or two to a site that I haven't checked.
I'm glad that you were able to provide some insightful commentary here. Thank you for helping 'make slashdot what it has become'.
Yes, but these benchmarks are essentially worthless.
The newest benchmark listed on that page that includes PostgreSQL and MySQL is dated October 5th, 1999. I'm afraid that just doesn't cut it. That's several minor releases and one helluva major release behind on PostgreSQL, and prolly somewhat behind on MySQL releases, as well.
I saw mention in some comments that this was most likely due to lack of time, and that's prolly true, but t hat doesn't make these benchmarks any more valid.
Additionally, as quoted on that page:
As some entries are posted to us from anonymous MySQL users we can't guarantee that all benchmarks
are completely accurate, so we suggest that you run the benchmark yourself on your favorite database.
This also invalidates these benchmarks entirely, as far as I'm concerned. As the MySQL author stated in his article, unless you can do a benchmark correctly, including full discloser of information on all accounts of the testing, then it is less than worthless. These pretty much fall into that catagory from what I can tell.
Availability of the Linux version was the reason that I didn't buy it.
I spent a week trying to find a copy of the Linux version, unfortunately, none of the local stores carried it. I finally said "Screw it" and bought the Windows version so I had something to play.
I know I'm not the only one, either, because a good friend of mine told me he did the same thing. Had the Linux version been available locally, I would have bought it in a second.
However, Debian does provide packages for much of those things, specifically, there is a QMail package. (Though it's slightly different from most others because of QMail distribution requirements).
qmail is technically non-free (it fails to meet the Debian Free Software Guidelines) because its license prevents redistribution of modified versions. Instead, one must distribute a patch which can be applied to the pristine upstream source.
Erm, yes, hence the note, which you quoted, where I mention that it is different from standard Debian packages.;-)
Debian can't package a pristine qmail binary, because qmail's design conflicts with the Debian policy. (qmail uses ~/Mailbox for message storage instead of/var/spool/mail/$USER; and Debian requires that all mail programs use the Debian locking library, which qmail naturally does not use.)
This is correct.
Thus, Debian cannot provide qmail binaries. Instead, they provide "Debianized qmail sources" -- which is basically a collection of the pristine qmail source tarball along with Debian patches and build scripts.
Actually, there is more to it than just the 'Debianized QMail sources'. When you get the qmail-src debian package, it also pulls down a build script that will automatically build and install QMail for you. This script can be run with 'build-qmail'. (Modified versions of this script are included with most of the QMail related programs, such as ezmlm, ucspi-tcp, dot-forward, and rblsmtpd, making it as easy as a single command to have working QMail binary packages.)
I've used the Debianized qmail before, but honestly, I just don't like it. (It's also caused grief for a lot of people, since at some point during potato it stopped working. I don't have details beyond that, because I stopped attempting to use it, and stopped caring about it.)
Interesting, I've been using QMail since before it became a Debian package, and I've been using the Debian package as long as it's been available, and I've never run into this problem. I've also tracked the (semi-official) Debian QMail mailing list since it's creation, and I don't recall hearing about any problems like that there. I've actually been very impressed with the high quality of the package, and the excellent job it's maintainer has done delivering an easy to install QMail binary with minimal hassle, thanks to the build scripts.
Personally, I recommend building qmail yourself from the source code (download it from qmail.org). Debian already gave you the user-IDs and group-IDs in/etc/passwd and/etc/group, so that much of the installation is already done before you even download the source.
For the record, I'd strongly suggest just grabbing the Debian QMail 'src' packages. Doing that will have QMail up and running for you in just minutes, and with essentially no hassle at all. Considering the license restrictions the QMail pacakge maintainer has to work around, the ease with which it installs is little short of amazing.
Of course, building something as fundamental as a mail transfer agent tends to raise issues with the Debian packaging system. But there's an easy solution: equivs. The Debian "equivs" package allows you to tell the packaging system that you already have a mail-transfer-agent package installed, thankyouverymuch, and please don't delete all the packages that depend on mail-transfer-agent.:)
Ugh. I would *strongly* recommend against the above mentioned procedure, especially in order to get QMail working. The Debian equivs package is something of an ugly hack, and should only be used when it's absolutely necessary. When packages are already there, you're just gonna get yourself in trouble unless you really know what you're doing. (In which case getting the qmail pacakges built and installed should be cake.
Oh, and in answer to a previous question in this thread: the default Debian MTA is exim, not sendmail.
This is correct, with a significant minority of the Debian developers pushing for Postfix as a possible replacement for exim as the default.
(Some of you may know me as greycat on #debian.)
(None of you will know me as anything on #debian, as I tend to live on SorceryNet.;-)
How is Debian with mixed packages (i.e. deb packages and.tar.gz).
If you put your custom software in/usr/local, then Debian packages will *NEVER* touch them. Debian policy is that/usr/local is sacrosanct, and must always be left for the sysadmin.
I usually like to get my kernels directly, mostly because the RedHat patches make it impossible a patch the kernel from ftp.kernel.org
Then you'll prolly love Debian's make-kpkg utility. Debian provides standard kernel packages, for those who choose to use them. They also provide make-kpkg, which allows you to download the kernel source yourself, and then compile it according to *your* configuration, and then turn that kernel into a Debian package.
This way, you can add in whatever custom patches you want, and still install your kernel as a standard Debian package for organizational purposes.
I also don't like to use packages like BIND or Sendmail (using dnsdjb and qmail instead).
Again, if you just place all of your own stuff in/usr/local, you'll be just fine, as Debian will never touch it. However, Debian does provide packages for much of those things, specifically, there is a QMail package. (Though it's slightly different from most others because of QMail distribution requirements).
If you like adding custom patches to software that has Debian packages, it is *very* easy to get the source [package] (Debian doesn't actually have source packages, but you can grab the full source of a program, along with the debian build scripts, as easy as 'apt-get source packagename', which you can then patch as you like and then turn it into a Debian package which you can install as easy as the original.
RPM doesn't have a problem with this, but then again. RPM seems pretty braindead compared to apt-get
apt-get should have no problems with any of this, either. And it is much more intelligent and powerful than RPM.;-)
I always buy Anime with the original Japanese dialog because I happen to *greatly* prefer it.
I don't like supporting them when they do something that is strongly against my interests.
I have never yet found an Anime where I prefered an English dub over the original Japanese dialog. I find Japanese to be a beautiful and musical langauge, and I enjoy listening to it. Also, it always tends to match up better to the animation.
By purchasing this anime anyway, without the Japanese dialog, I am implicitly giving them my approval to continue with that type of action. I refuse to do that. I want them to know that I don't wish to buy a crippled version of the movie, and I hope that if there are enough people out there like me, perhaps they'll get the message and do things right.
Oh, wow, please tell me you're joking. Nausicaa was horrid? Are you sure you watched it? You didn't by any chance watch 'Warriors of the Wind' did you? That's the name of the unbelievably bad English dub that was done of Nausicaa. It cuts out literally about a half an hour from the story, including almost the entire plot. (The justification for it was that animation was only enjoyed by kids, and kids don't want a good story, they just want action. Incidentally, this terrible hack job is the reason that Ghibli Studios has been so reserved about releasing English dubs of their movies.) The dub was an absolute massacre.
However, the full, unedited, Nausicaa of the Valley of Wind is an amazing piece of work. Easily the greatest Anime I've ever seen.
(And I have read, and own, the entire Nausicaa Manga set. Yes, it is amazing, but that doesn't take away from the Anime.)
Re:Anime is cartoon child porn
on
Tenchi Muyou 3?
·
· Score: 1
You realize you are just splitting hairs here. You sound like ESR trying to force cracker on everybody instead of hacker. Hentai is simply a subset of Anime, but it is anime none the less. Sorry but movies about tentacles raping 15 year old girls is kiddie porn. Have you ever seen Kekko Kamen? That is some disgusting pedophilia.
And you are making an amazingly overly broad generalization. Are you trying to point out that the existence of hentai, 'anime porn', makes all Anime worthless porn?
That's like saying that because movie pornography exists, all movies are nothing but worthless porn. Hrm....that really doesn't make much sense when viewed in that context, now does it.
The simple fact is, Japanese Animation, Anime, is as varied in quality and topic as live action films are in the United States.
I love Anime. I loved Princess Mononoke. In fact, it's prolly either my second or third favorite anime at this time (Only one I'm sure I like better is Nausicaa of the Valley of Wind.
However, I also *love* Japanese dialog. I had my name on the preorder list for this DVD, and I removed it when I heard they weren't going to include the original Japanese dialog. Now I get to put it back on.
I can only say thank you and congratulations to the online Anime Community for making this happen.
Hrm, very interesting. When I posted that, www.uswest.com was actually being redirected to www.qwest.com, which has full information on the merger. It seems that it is back to pointing to US West's old homepage again.
However, and interesting thing to check out is the 'About...' link on US West's home page.
Well, I'm going to guess that quite a lot of people care. US West is the primary local phone carrier (basically, the phone monopoly) for 14 states in the Central and Northwestern United States. They also provide Internet access through their USWest.net service, and recently started offering DSL.
If you're lucky enough to live in one of them, they also have a wholly owned subsidiary known as US West TeleChoice which offers cable television and cable modems (TeleChoice Online).
While they do have many problems, I personally don't think of them as quite the worst phone company around. There are many who are in fact much worse (BellSouth comes to mind).
Either way, this is a *very* big thing, because US West and Qwest aren't just merging. US West is being bought by Qwest. This will have a major impact on a whole lot of people, both for their local phone service, and more.
I will admit that I'm slightly biased here, as I do cable modem installations for US West TeleChoice Online. However, I'm also very excited here. You see, TeleChoice has been rejoicing over this buy-out for a while now. Qwest is not a phone company, their an Internet service oriented company. Therefore, this buying of US West is primarily to give them access to US West's phone subscriber base to start a major roll out of High Speed Internet Access.
That's right, Qwest is most likely going to be pumping out some major advances in high speed access. I expect we'll be seeing VDSL as soon as it is technically feasible (as in Very Soon (tm)).
I saw a few posts, along with the mention at the top where the story is posted, about who will be in control of the new company. Well, ease your fears, the control goes to Qwest. Again, this merger is Qwest buying US West, so they will be primarily in control. In fact, if you go to US West's homepage (www.uswest.com) you'll see that it's no longer US West's homepage. Instead, you are now looking at Qwest's homepage!
You see, the GPL requires all code in a program, including linked libraries, to be either GPLed, or to not impose any additional restrictions on use and distribution beyond the those in the GPL.
You just misstated the GPL, neglecting the "base system component" exception.
There's people out there that will tell you that it's not legal to distribute Motif-based GPL programs that run on Solaris, or Java-based GPL programs, or even MFC-based GPL programs. Don't believe them, read the licence.
You are in fact correct. I left that out primarily for the sake of clarity. While it is in fact true, it has little relevance to this issue.
I prolly should have included it anyway, though, so I appreciate your pointing it out.
quite frankly, Debian has Netscape Communicator as part of the main distro, and one could use the same arguments used against KDE against Netscape. Compiling software for Linux is damn near impossible without somewhere using some includes from GPL software. One could argue Communicator is an illegal derivation of GPLed software.
I think you misunderstand the problem here. Netscape has a clear license for how it can be used and distributed. Any software licensed under the GPL has a clear license of how it can be used and distributed. Qt has a clear license of how it can be used and distributed. None of that is in question. Also, all of these work, because there are no direct conflicts between licenses.
If you have not read the GPL, you should read that know, so you understand exactly what is entailed in it. According to the GPL, Netscape is perfectly legal. It does not violate any licenses. Qt, on its own, does not violate any licenses. It is a perfectly legal, and even free library.
The problem comes when you link an application that is licensed under the stock GPL with the Qt libraries. You see, the GPL requires all code in a program, including linked libraries, to be either GPLed, or to not impose any additional restrictions on use and distribution beyond the those in the GPL. Unfortunately, the QPL does include additional restrictions. Unless you include a specific item with the software license that explicitly allows linking with the Qt library, then legally you cannot distribute the application (unless you are the author) becuase the GPL does not allow it. This is not just some argument someone cooked up to keep KDE out of Debian. It is a simple legal fact that there is a conflict between licenses on software licensed under the stock GPL and linked with QPL libraries.
I've seen it argued by some that this is just a plot by Debian against KDE because it uses Qt, and I've even seen it mentioned in posts that Debian doesn't accept any software that isn't licensed under the GPL. These are both completely and totally wrong. In fact, there are probably hundreds of programs that are not licensed under the GPL. Debian will allow any software that meets the Debian Free Software Guidelines into the distribution (In fact, there are applications that use the Qt library, along with the library itself, included with Debian. These applications have properly licensed their software under the GPL with an explicit statement concerning Qt). However, this is a completely seperate issue from the KDE issue, even though people often confuse them.
KDE is absent from Debian because it has an invalid license, not because it isn't free software. Hopefully, eventually, the KDE authors will put forth the little bit of effort required to fix their mistake, and make their software legally distributable by everyone.
It appears that pretty much all the links to the free chapters are currently bad. Since they're all dead, and there's no mention of it on the site, I'm guessing it's due to a mistake. Especially as they were all working a week or two ago.
However, it's still freely available via anonymous CVS. See http://cvsbook.red-bean.com/anoncvs.html for instructions on getting it. (I just tried it, and it does work)
The CVS version is the texinfo format, and includes a Makefile to build the alternate formats.
What, is something preventing you from writing a tool in $OTHER_LANGUAGE and announcing it on freshmeat? So it can't be entered in a Python competition. Oh well.
Nothing prevents me from doing so. However, one of the primary goals for this project, which I do agree with, is to create a set of tools all of which have a similar user interface, to make learning them and using them easier on inexperienced developers.
Redesigning multiple important tools, including autoconf/automake, GNATS/Bugzilla, and a regression testing suite is *not* a small project. It requires a number of people, and a lot of work. This project is providing that framework, they're just limiting it unecessarily, in my oppinion.
I really dislike a lot of the things going on with this project. The fact that they mandate the use of Python is one of my primary objections. I personally think Python is a fine language, and I support it's use in general....however, forcing everyone who wants to participate in this project to use Python seems unfair.
That, and I dislike the idea that a single langauge is ideal for all situations. Personally, I think a consistant User Interface to these utilities is much more important than what langauge they are implemented in. If they all work and act similar, then they'll be easy to use. And if people aren't forced to use Python, you might end up with better results....at the least, you'll most likely end up with more results, simply because you aren't locking people out.
When fixing the problem, fix it smartly. I agree with some of the goals of this project, I just really don't like how they're going about it.
Of course not. People have been predicting the death of Unix almost as long as they've been predicting the death of mainfraimes. And a year of so ago, IBM released a mainframe (don't remember the model) which became the best selling mainframe ever in initial 6 month sales.
I predict that 20 years from now, we'll still be hearing how Unix is dying and almost extinct, prolly by the same people who will still be saying the same thing about mainframes.
It generally works with any Cable modem or DSL service that connects to a PC via Ethernet. LinkSys also makes one of these, and you can find information here. It includes a 4 port switch, NAT, firewall, etc.
I do installations for a local Cable Modem company here, and we've been playing with the LinkSys model for the past few days. They run around $200US and work pretty well.
Basically, it has one 10BaseT port to connect to the Internet Service (Cable Modem or DSL) and 4 ports to connect to the computers on the Local network. Setup is almost nil, and performance is impressive.
I have a feeling we'll see more companies making these very soon.
Another suggestion might be NetBSD. In my experience, and discussion with other devlopers, I've come to the conclusion that NetBSD has one of the most elegant and cleanly written kernels anywhere.
I believe this comes about due to a difference in philosophy. With linux, the philosophy is to get it done, period. It may not be pretty, nor as good as it could be, but it will work. Perfecting it can always be done later.
NetBSD developement follows a different philosophy, that of getting it right the first time. For this reason, NetBSD isn't always quite as cutting edge as Linux, but what they do implement, they plan careful and do well.
Also, the ever present goal of ultimate portability has helped NetBSD. I've found portability to be a key aid in writing good programs, as a well written program tends to be inherantly more portable than a badly written one.
You can have their Debian based mini-distro soon, I've found the information on LinuxCare's site, here. At the moment, it doesn't say very much, but it does mention that more information will be provided soon, as well as ISO images, and source code!
They also have a mailing list setup for discussion of the business card. You can subscribe by sending an e-mail to the list request address, with the word 'subscribe' in the body.
This is one cool thing, and I've gotta give props to LinuxCare for this.;-)
Slashdot Mirror
Well, that's very interesting. Except that most of the information I've found today says that the 760MP chipset is due out in Q4 of 2000, with motherboards arriving around the same time, or very shortly thereafter.
Once again I have to thank you for going that extra mile towards making Slashdot a better place. Your 'help' towards answering a simple question is greatly appreciated.
--
Toph
Thanks for the URL. Most of the sites I've checked for info are more general hardware and tech sites, I don't have URLs for very many AMD specific ones.
--
Toph
Actually, he's been to a great deal of hardware sites, but he found very little solid information.
First, he went to AMD's web site. He browsed it thoroughly, and then did a number of searches. He discovered that AMD has essentially no information on their website about SMP, period. Almost no mention of it, even.
He then checked out Tom's hardware, Ars Technica, as well as 4 other similar hardware review and news sites. Do you know what he found there? A few rumors about AMD's supporting SMP, a single mention of 760MP chipset, without any dates or informaiton on it, and a couple of claims that AMD would have an SMP motherboard out sometime in 2001.
He wasn't impressed with most of the information out there.
You see, I wasn't looking for vague rumors, I was looking for facts. I was hoping that someone might have heard something from a reputable source, or someone might have a URL or two to a site that I haven't checked.
I'm glad that you were able to provide some insightful commentary here. Thank you for helping 'make slashdot what it has become'.
--
Toph
Yes, but these benchmarks are essentially worthless.
The newest benchmark listed on that page that includes PostgreSQL and MySQL is dated October 5th, 1999. I'm afraid that just doesn't cut it. That's several minor releases and one helluva major release behind on PostgreSQL, and prolly somewhat behind on MySQL releases, as well.
I saw mention in some comments that this was most likely due to lack of time, and that's prolly true, but t hat doesn't make these benchmarks any more valid.
Additionally, as quoted on that page:
This also invalidates these benchmarks entirely, as far as I'm concerned. As the MySQL author stated in his article, unless you can do a benchmark correctly, including full discloser of information on all accounts of the testing, then it is less than worthless. These pretty much fall into that catagory from what I can tell.Availability of the Linux version was the reason that I didn't buy it.
I spent a week trying to find a copy of the Linux version, unfortunately, none of the local stores carried it. I finally said "Screw it" and bought the Windows version so I had something to play.
I know I'm not the only one, either, because a good friend of mine told me he did the same thing. Had the Linux version been available locally, I would have bought it in a second.
qmail is technically non-free (it fails to meet the Debian Free Software Guidelines) because its license prevents redistribution of modified versions. Instead, one must distribute a patch which can be applied to the pristine upstream source.
Erm, yes, hence the note, which you quoted, where I mention that it is different from standard Debian packages. ;-)
Debian can't package a pristine qmail binary, because qmail's design conflicts with the Debian policy. (qmail uses ~/Mailbox for message storage instead of /var/spool/mail/$USER; and Debian requires that all mail programs use the Debian locking library, which qmail naturally does not use.)
This is correct.
Thus, Debian cannot provide qmail binaries. Instead, they provide "Debianized qmail sources" -- which is basically a collection of the pristine qmail source tarball along with Debian patches and build scripts.
Actually, there is more to it than just the 'Debianized QMail sources'. When you get the qmail-src debian package, it also pulls down a build script that will automatically build and install QMail for you. This script can be run with 'build-qmail'. (Modified versions of this script are included with most of the QMail related programs, such as ezmlm, ucspi-tcp, dot-forward, and rblsmtpd, making it as easy as a single command to have working QMail binary packages.)
I've used the Debianized qmail before, but honestly, I just don't like it. (It's also caused grief for a lot of people, since at some point during potato it stopped working. I don't have details beyond that, because I stopped attempting to use it, and stopped caring about it.)
Interesting, I've been using QMail since before it became a Debian package, and I've been using the Debian package as long as it's been available, and I've never run into this problem. I've also tracked the (semi-official) Debian QMail mailing list since it's creation, and I don't recall hearing about any problems like that there. I've actually been very impressed with the high quality of the package, and the excellent job it's maintainer has done delivering an easy to install QMail binary with minimal hassle, thanks to the build scripts.
Personally, I recommend building qmail yourself from the source code (download it from qmail.org). Debian already gave you the user-IDs and group-IDs in /etc/passwd and /etc/group, so that much of the installation is already done before you even download the source.
For the record, I'd strongly suggest just grabbing the Debian QMail 'src' packages. Doing that will have QMail up and running for you in just minutes, and with essentially no hassle at all. Considering the license restrictions the QMail pacakge maintainer has to work around, the ease with which it installs is little short of amazing.
Of course, building something as fundamental as a mail transfer agent tends to raise issues with the Debian packaging system. But there's an easy solution: equivs. The Debian "equivs" package allows you to tell the packaging system that you already have a mail-transfer-agent package installed, thankyouverymuch, and please don't delete all the packages that depend on mail-transfer-agent. :)
Ugh. I would *strongly* recommend against the above mentioned procedure, especially in order to get QMail working. The Debian equivs package is something of an ugly hack, and should only be used when it's absolutely necessary. When packages are already there, you're just gonna get yourself in trouble unless you really know what you're doing. (In which case getting the qmail pacakges built and installed should be cake.
Oh, and in answer to a previous question in this thread: the default Debian MTA is exim, not sendmail.
This is correct, with a significant minority of the Debian developers pushing for Postfix as a possible replacement for exim as the default.
(Some of you may know me as greycat on #debian.)
(None of you will know me as anything on #debian, as I tend to live on SorceryNet. ;-)
How is Debian with mixed packages (i.e. deb packages and .tar.gz).
If you put your custom software in /usr/local, then Debian packages will *NEVER* touch them. Debian policy is that /usr/local is sacrosanct, and must always be left for the sysadmin.
I usually like to get my kernels directly, mostly because the RedHat patches make it impossible a patch the kernel from ftp.kernel.org
Then you'll prolly love Debian's make-kpkg utility. Debian provides standard kernel packages, for those who choose to use them. They also provide make-kpkg, which allows you to download the kernel source yourself, and then compile it according to *your* configuration, and then turn that kernel into a Debian package.
This way, you can add in whatever custom patches you want, and still install your kernel as a standard Debian package for organizational purposes.
I also don't like to use packages like BIND or Sendmail (using dnsdjb and qmail instead).
Again, if you just place all of your own stuff in /usr/local, you'll be just fine, as Debian will never touch it. However, Debian does provide packages for much of those things, specifically, there is a QMail package. (Though it's slightly different from most others because of QMail distribution requirements).
If you like adding custom patches to software that has Debian packages, it is *very* easy to get the source [package] (Debian doesn't actually have source packages, but you can grab the full source of a program, along with the debian build scripts, as easy as 'apt-get source packagename', which you can then patch as you like and then turn it into a Debian package which you can install as easy as the original.
RPM doesn't have a problem with this, but then again. RPM seems pretty braindead compared to apt-get
apt-get should have no problems with any of this, either. And it is much more intelligent and powerful than RPM. ;-)
Have fun, and good luck!
Why did I take my name off the preorder list?
I did it for two reasons:
- I always buy Anime with the original Japanese dialog because I happen to *greatly* prefer it.
- I don't like supporting them when they do something that is strongly against my interests.
I have never yet found an Anime where I prefered an English dub over the original Japanese dialog. I find Japanese to be a beautiful and musical langauge, and I enjoy listening to it. Also, it always tends to match up better to the animation.By purchasing this anime anyway, without the Japanese dialog, I am implicitly giving them my approval to continue with that type of action. I refuse to do that. I want them to know that I don't wish to buy a crippled version of the movie, and I hope that if there are enough people out there like me, perhaps they'll get the message and do things right.
In this case, it would appear to have worked.
Nausicaa movie was horrid. Read the manga...
Oh, wow, please tell me you're joking. Nausicaa was horrid? Are you sure you watched it? You didn't by any chance watch 'Warriors of the Wind' did you? That's the name of the unbelievably bad English dub that was done of Nausicaa. It cuts out literally about a half an hour from the story, including almost the entire plot. (The justification for it was that animation was only enjoyed by kids, and kids don't want a good story, they just want action. Incidentally, this terrible hack job is the reason that Ghibli Studios has been so reserved about releasing English dubs of their movies.) The dub was an absolute massacre.
However, the full, unedited, Nausicaa of the Valley of Wind is an amazing piece of work. Easily the greatest Anime I've ever seen.
(And I have read, and own, the entire Nausicaa Manga set. Yes, it is amazing, but that doesn't take away from the Anime.)
You realize you are just splitting hairs here. You sound like ESR trying to force cracker on everybody instead of hacker. Hentai is simply a subset of Anime, but it is anime none the less. Sorry but movies about tentacles raping 15 year old girls is kiddie porn. Have you ever seen Kekko Kamen? That is some disgusting pedophilia.
And you are making an amazingly overly broad generalization. Are you trying to point out that the existence of hentai, 'anime porn', makes all Anime worthless porn?
That's like saying that because movie pornography exists, all movies are nothing but worthless porn. Hrm....that really doesn't make much sense when viewed in that context, now does it.
The simple fact is, Japanese Animation, Anime, is as varied in quality and topic as live action films are in the United States.
I love Anime. I loved Princess Mononoke. In fact, it's prolly either my second or third favorite anime at this time (Only one I'm sure I like better is Nausicaa of the Valley of Wind.
However, I also *love* Japanese dialog. I had my name on the preorder list for this DVD, and I removed it when I heard they weren't going to include the original Japanese dialog. Now I get to put it back on.
I can only say thank you and congratulations to the online Anime Community for making this happen.
Hrm, very interesting. When I posted that, www.uswest.com was actually being redirected to www.qwest.com, which has full information on the merger. It seems that it is back to pointing to US West's old homepage again.
However, and interesting thing to check out is the 'About...' link on US West's home page.
It clearly says that US West is now Qwest.Well, I'm going to guess that quite a lot of people care. US West is the primary local phone carrier (basically, the phone monopoly) for 14 states in the Central and Northwestern United States. They also provide Internet access through their USWest.net service, and recently started offering DSL.
If you're lucky enough to live in one of them, they also have a wholly owned subsidiary known as US West TeleChoice which offers cable television and cable modems (TeleChoice Online).
While they do have many problems, I personally don't think of them as quite the worst phone company around. There are many who are in fact much worse (BellSouth comes to mind).
Either way, this is a *very* big thing, because US West and Qwest aren't just merging. US West is being bought by Qwest. This will have a major impact on a whole lot of people, both for their local phone service, and more.
I will admit that I'm slightly biased here, as I do cable modem installations for US West TeleChoice Online. However, I'm also very excited here. You see, TeleChoice has been rejoicing over this buy-out for a while now. Qwest is not a phone company, their an Internet service oriented company. Therefore, this buying of US West is primarily to give them access to US West's phone subscriber base to start a major roll out of High Speed Internet Access.
That's right, Qwest is most likely going to be pumping out some major advances in high speed access. I expect we'll be seeing VDSL as soon as it is technically feasible (as in Very Soon (tm)).
I saw a few posts, along with the mention at the top where the story is posted, about who will be in control of the new company. Well, ease your fears, the control goes to Qwest. Again, this merger is Qwest buying US West, so they will be primarily in control. In fact, if you go to US West's homepage (www.uswest.com) you'll see that it's no longer US West's homepage. Instead, you are now looking at Qwest's homepage!
Actually, you're not quite correct. Qwest hasn't sold out, they've bought out. They are the ones in control of the new Qwest-US West corporation.
Check out US West's Home Page and you'll see it very prominently shown that they are now Qwest.
Nope, actually Qwest is going to be in control of the company after the merger.
In fact, the new company will be taking on the Qwest name.
(My mother works for US West, my father used to, and I work for one of their subsidiaries, US West TeleChoice.)
You just misstated the GPL, neglecting the "base system component" exception.
There's people out there that will tell you that it's not legal to distribute Motif-based GPL programs that run on Solaris, or Java-based GPL programs, or even MFC-based GPL programs. Don't believe them, read the licence.
You are in fact correct. I left that out primarily for the sake of clarity. While it is in fact true, it has little relevance to this issue.
I prolly should have included it anyway, though, so I appreciate your pointing it out.
quite frankly, Debian has Netscape Communicator as part of the main distro, and one could use the same arguments used against KDE against Netscape. Compiling software for Linux is damn near impossible without somewhere using some includes from GPL software. One could argue Communicator is an illegal derivation of GPLed software.
I think you misunderstand the problem here. Netscape has a clear license for how it can be used and distributed. Any software licensed under the GPL has a clear license of how it can be used and distributed. Qt has a clear license of how it can be used and distributed. None of that is in question. Also, all of these work, because there are no direct conflicts between licenses.
If you have not read the GPL, you should read that know, so you understand exactly what is entailed in it. According to the GPL, Netscape is perfectly legal. It does not violate any licenses. Qt, on its own, does not violate any licenses. It is a perfectly legal, and even free library.
The problem comes when you link an application that is licensed under the stock GPL with the Qt libraries. You see, the GPL requires all code in a program, including linked libraries, to be either GPLed, or to not impose any additional restrictions on use and distribution beyond the those in the GPL. Unfortunately, the QPL does include additional restrictions. Unless you include a specific item with the software license that explicitly allows linking with the Qt library, then legally you cannot distribute the application (unless you are the author) becuase the GPL does not allow it. This is not just some argument someone cooked up to keep KDE out of Debian. It is a simple legal fact that there is a conflict between licenses on software licensed under the stock GPL and linked with QPL libraries.
I've seen it argued by some that this is just a plot by Debian against KDE because it uses Qt, and I've even seen it mentioned in posts that Debian doesn't accept any software that isn't licensed under the GPL. These are both completely and totally wrong. In fact, there are probably hundreds of programs that are not licensed under the GPL. Debian will allow any software that meets the Debian Free Software Guidelines into the distribution (In fact, there are applications that use the Qt library, along with the library itself, included with Debian. These applications have properly licensed their software under the GPL with an explicit statement concerning Qt). However, this is a completely seperate issue from the KDE issue, even though people often confuse them.
KDE is absent from Debian because it has an invalid license, not because it isn't free software. Hopefully, eventually, the KDE authors will put forth the little bit of effort required to fix their mistake, and make their software legally distributable by everyone.
It appears that pretty much all the links to the free chapters are currently bad. Since they're all dead, and there's no mention of it on the site, I'm guessing it's due to a mistake. Especially as they were all working a week or two ago.
However, it's still freely available via anonymous CVS. See http://cvsbook.red-bean.com/anoncvs.html for instructions on getting it. (I just tried it, and it does work)
The CVS version is the texinfo format, and includes a Makefile to build the alternate formats.
It's still freely available via anonymous CVS. See http://cvsbook.red-bean.com/anoncvs.html for instructions on getting it.
The CVS version is the texinfo format, and includes a Makefile to build the alternate formats.
What, is something preventing you from writing a tool in $OTHER_LANGUAGE and announcing it on freshmeat? So it can't be entered in a Python competition. Oh well.
Nothing prevents me from doing so. However, one of the primary goals for this project, which I do agree with, is to create a set of tools all of which have a similar user interface, to make learning them and using them easier on inexperienced developers.
Redesigning multiple important tools, including autoconf/automake, GNATS/Bugzilla, and a regression testing suite is *not* a small project. It requires a number of people, and a lot of work. This project is providing that framework, they're just limiting it unecessarily, in my oppinion.
I really dislike a lot of the things going on with this project. The fact that they mandate the use of Python is one of my primary objections. I personally think Python is a fine language, and I support it's use in general....however, forcing everyone who wants to participate in this project to use Python seems unfair.
That, and I dislike the idea that a single langauge is ideal for all situations. Personally, I think a consistant User Interface to these utilities is much more important than what langauge they are implemented in. If they all work and act similar, then they'll be easy to use. And if people aren't forced to use Python, you might end up with better results....at the least, you'll most likely end up with more results, simply because you aren't locking people out.
When fixing the problem, fix it smartly. I agree with some of the goals of this project, I just really don't like how they're going about it.
Of course not. People have been predicting the death of Unix almost as long as they've been predicting the death of mainfraimes. And a year of so ago, IBM released a mainframe (don't remember the model) which became the best selling mainframe ever in initial 6 month sales.
I predict that 20 years from now, we'll still be hearing how Unix is dying and almost extinct, prolly by the same people who will still be saying the same thing about mainframes.
It generally works with any Cable modem or DSL service that connects to a PC via Ethernet. LinkSys also makes one of these, and you can find information here. It includes a 4 port switch, NAT, firewall, etc.
I do installations for a local Cable Modem company here, and we've been playing with the LinkSys model for the past few days. They run around $200US and work pretty well.
Basically, it has one 10BaseT port to connect to the Internet Service (Cable Modem or DSL) and 4 ports to connect to the computers on the Local network. Setup is almost nil, and performance is impressive.
I have a feeling we'll see more companies making these very soon.
Another suggestion might be NetBSD. In my experience, and discussion with other devlopers, I've come to the conclusion that NetBSD has one of the most elegant and cleanly written kernels anywhere.
I believe this comes about due to a difference in philosophy. With linux, the philosophy is to get it done, period. It may not be pretty, nor as good as it could be, but it will work. Perfecting it can always be done later.
NetBSD developement follows a different philosophy, that of getting it right the first time. For this reason, NetBSD isn't always quite as cutting edge as Linux, but what they do implement, they plan careful and do well.
Also, the ever present goal of ultimate portability has helped NetBSD. I've found portability to be a key aid in writing good programs, as a well written program tends to be inherantly more portable than a badly written one.
You can have their Debian based mini-distro soon, I've found the information on LinuxCare's site, here. At the moment, it doesn't say very much, but it does mention that more information will be provided soon, as well as ISO images, and source code!
;-)
They also have a mailing list setup for discussion of the business card. You can subscribe by sending an e-mail to the list request address, with the word 'subscribe' in the body.
This is one cool thing, and I've gotta give props to LinuxCare for this.