Of course, that assumes people are stupid enough to not run a portscanner before an attack. Frankly, I would imagine only the most neophyte crackers would neglect a portscan, especially since there are often easier and more tempting ports to target (especially in the first few days after an exploit is published).
what is up with the 2MB vid cards on most laptops?
From Dell?
Dell, I believe, ships as standard on most laptops the ATI Mobility chipset, which is an 8MB video controller. I purchased an Inspiron 3800 (which will be running Slack shortly), which is probably the low-end of the personal/home user laptops (not that the laptop is all that bad, but it's not meant to replace your server IOW), and that came with just such a controller.
Granted, the Mobility chipset sucks major ass when running any sort of remotely-modern 3D game (Descent III, for instance, crawled on this chipset), but the 8MB is respectable (if not awe-inspiring).
Sure, an argument can be made that Slackware packagers are more careful in their package selection and the testing of said packages, but considering that most of what is shipped by each distribution is composed of the same software packages (which incidentally are not created by either Slackware or Redhat), this is really a moot point.
There are a couple of problems in your statement here which render it "not a moot point."
For one thing, while the type of software that Red Hat and Slackware (since you use this as a comparison) ship may be similar (both, for instance, ship XFree86, GNOME, KDE, etc.), the specific software varies. Slackware may ship slightly older software, or may in fact wait a much longer period of time before shipping a specific version of software. Such was the case in the libc5 vs. libc6/glibc. Red Hat jumped into the fray with libc6/glibc, and to their detriment found it was not quite ready for primetime use. As a result, the perceived quality of Red Hat's software was lowered in the eyes of many users, because the library was not fully tuned, tested, or debugged. Slackware, up until 7.0, continued using libc5 because it was a tried, tested, and debugged library. Only when libc6/glibc was finally quality, dependable software did Slackware switch over. For some, Slackware's reluctance to switch was a hindrance because they couldn't use the latest-and-greatest software that was compiled for other platforms like Red Hat. Others, however, saw that the libc6/glibc libraries were more prone to problems and wanted to avoid them until they were ready.
For another thing, you'll find that because Slackware takes their time in shipping bleeding edge software, the distribution is less prone to security faults than Red Hat's distribution is. While Red Hat has the latest and greatest software, and as a result can offer somewhat more features than Slackware can (depending on the software), Red Hat issues security updates/patches for their distribution more than Slackware does. A significant number of people value security/stability over features - and Slackware is more to their taste. Is this to say Red Hat is crash-prone, or "bad" software? No. It's simply catering to different tastes.
For a third thing, your statement ignores the qualitative differences between distributions that having nothing to do with software. The style of Red Hat's init scripts versus Slackware's, for instance. Some prefer Slackware's init script style because it's more BSD-ish than Red Hat. Does that make it bad? No - it's just catering to a different taste. Some people also like the fact that Slackware has a very minimalistic package management system, because it forces them to learn more about the system and because it offers them more control over their software (whether it actually does or not is an arguable point). Does this make SysV scripts and RPMs bad? No - it just offers a different way of doing things that some people might find less to their taste. Others, as can be witnessed on this thread, find RPMs to be the greatest thing since sliced bread!
So what is really fair when comparing distributions? IMHO it's what they aggregate (package management systems, new packages etc), and in that respect, Redhat produces more and better software than Slackware.
Quantity vs. quality as a valid metric? Shove as much into the distribution as possible, and you're guaranteed to be considered "the best?" That's a spotty judgement call at best.
You're right when you say it's fair to judge distributions on what they aggregate. But relying *soley* on that aggregative factor is ignoring everything else that makes distributions unique. It's just as much propaganda to claim that Red Hat is better because it has more to it as it is to claim that Slackware is better because it is "rock solid." It's just different, not better.
Further, judging which distribution is "best" involves knowing who you are judging it for. For desktop users who want an install-and-go Linux experience, Red Hat is overwhelmingly the better choice. However, for those users who want to delve into the system and not have their hand held by GUI utilities, or who want a slightly more "generic" Linux experience (and, admit it or not, Red Hat provides an awful lot of custom utilities for administrating their distribution), or who don't want to become dependent on a packaging system, Slackware is probably the better choice.
Don't be a distribution bigot. Choose the distribution because it's the best for you, not because some Slashdot hack says so. (It's kinda like those Sprite commercials. You wouldn't listen to some moron spout off his mouth about other things; why listen to them do it about distributions?) Just be content that what you use is the best one for you, and let everybody be free to choose their distribution based on the merits of those distributions.
I got it now! When my car runs out of gas it is "rock solid" too: its position in my garage is "stable" and it is not prone to crashes or accidents. Glad you clarified that for me...
A wise man once said, and I think it entirely appropriate for your comment, "Don't be a dick.
In this instance, referring to software, "rock solid" means "stable." A "rock solid" piece of software is robust, bug-free, and fault tolerant. A "rock solid" program can handle bad user input with grace, doesn't have memory leaks or security issues, does not crash at random, and is capable of handling any problems that come up during the use of the program (traps errors before they become problematic enough that the program can't continue).
When referring to cars, "rock solid" means that the vehicle in question is of high-quality, can run for a very long time (years) without things going wrong with the car, and capable of performing feats that lesser quality cars could not - hauling sailboats three times its size, filling a truck bed with several tons of rock and moving it up 45-degree-incline hills, and so on (hence the line of Chevy truck commercials that end with the tagline, "Chevy - Like A Rock").
You misunderstand what that little phrase is saying.
Essentially, anything you create is copyrighted by you by mere fact that you created it (notwithstanding patent infringements, etc.). What that blurb means is that "copylefting" a program first acknowledges there is a copyright on it, and that with that copyright comes a whole boatload of permissions and restrictions.
Then, after the FSF/GPL acknowledges all of those permissions and restrictions on the program given by the copyright, the program is then given additional permissions and restrictions that may or may not modify the ones given to you by the copyright (such as distribution terms).
In the absence of a copyleft, you have only the permissions and restrictions given by the copyright, which in turn is given to you by the mere fact that you created an original piece of work.
Now, copyrights do need to be inforced or they become worthless, but that's a different kettle of fish.
Ironically, that's the way open source is supposed to work.:) You write some software, and other people take a look at it. They find some flaws, point them out, and you get to patch the problems. In this case, you write a license agreement, and other people take a look at it. they find some flaws, point them out, and you write a new license that fixes all the problems.
Even in license agreements, with enough eyes all bugs are shallow.:)
For example, in the proposed.net world, you automatically download a copy (or a cached subset, depending upon your device) of your work from the "cloud" and automatically synchronize your changes later. This permits disconnected operation, e.g. working from a disconnected notebook or low-bandwidth wireless handheld.
As someone else said, "Feh.
Aside from gratuitous use of the word "automated," there is nothing new about this approach. This morning when I left for work, I FTP'd some files from my home machine to my laptop. When I get home, I will FTP my updated files back. If I really wanted to, I could simply set up an automated task that periodically FTPs the files back to my main system.
It sounds to me like this is simply some sort of technology that makes a shared client/server folder on a computer. When the computer connects, any changed data between the two refreshes in the background. Any changes on the shared folder get updated on the server, up until the time the computer/folder is disconnected.
So what do you need to mimic this?
* File-sharing technology. On UNIX, take your pick. * Monitor on the server and the client (monitors a particular folder for changes, manages connections between computers)
A little bit of NFS, a little bit of user-space daemon, and voila! UNIX.Net.
What this community bashes now, in three years they will eagerly clone -- see OLE2 vs Bonobo.
OLE2? Or is it OLE? Or ActiveX? Or COM? Or COM+? Which is the acronym this month?
At any rate, your idea is flawed. Microsoft didn't invent component-based architecture, and the merits of such an approach were well-known before Microsoft adopted thier technology-acronym-of-the-day. It's a bit disingenuous to claim that every single architectural approach offered in UNIX is only offered because Microsoft did it first. Perhaps if you could offer some evidence to prove that UNIX wouldn't have done it if Microsoft hadn't done it, I would have an easier time believing you.
This will reduce costs dramatically, with a maximum initial setup cost of 25 cents.
Not necessarily. Now we have those fancy Sacagewea dollar coins. So, if you look it another way, the maximum initial setup cost has now ballooned four-fold into $1.
Most downloadable software is based on the notion of registration or access keys.
Some software, such as WinZip, comes as a registerable shareware version. When you "buy" the software, you're really buying a registration number which then enables the software completely. If you delete the software, you can simply download a fresh copy of the shareware version and enter the registration key, and voila! - WinZip is unrestricted again.
Other types of software which can be purchased on-line, such as Partition Magic, works slightly similarly. You get a registration number and special download link. When you go to that link, you have to enter your registration number to get through. Once through, you can download the full version of the software. Should you torch PM, all you need to do is follow through the linking process and download a full, fresh copy.
For operating systems, though, I would imagine you would have to record it on a less volatile medium, such as a Zip disk or CD-ROM.
The problem is that there doesn't seem to be any list of what software in Slackware (or any other distribution for that matter, besides Debian) is non-free.
I wish there was an easier alternative for finding out what non-free is in Slackware than going through package by package...
The controls are more like if we don't like it, it doesn't touch the "official" codebase. These rules even apply to indenting and commenting. They're neither strict nor intrusive, but they do insure that things get done the way Be wants them done.
Why is that a problem?
Any large project requires guidelines for the way things are done, and formatting rules are important - nay, necessary - to keep a project coherent. It's the same reason why, on large projects, you agree on variable naming schemes - so that the code remains consistent throughout. It's difficult to read through code that looks like:
Insisting on a standard naming and formatting scheme is essential for keeping the OpenTracker code in understandable order. The particular naming and formatting schemes may be arbitrary, or not to your particular taste (for example, I detest K&R open-bracket formatting), but they are there for an important reason.
Yeah you can take the source and do what you would with it, but you'd have to maintain all of it yourself, convince BeOS users everywhere to use it instead of the Be-sanctioned option, and go without any support from Be. Instead of "do it our way or we'll sue you," it's "do it our way or we won't help you and neither will anyone else."
Now you're just being silly. You're trying to claim that Be/OpenTracker should somehow be responsible for forked projects.
If you decide to take the Linux kernel and replace the virtual memory system, and Torvalds rejects the patch, does he (or any other kernel hacker, for that matter) have an obligation to support your modifications? Of course not. To paraphrase your own words, "Yeah, you can take the source and do what you would with it, but you'd have to maintain all of it yourself, convince Linux users everywhere to use it instead of the Torvalds-sanctioned option, and go without any support from the Linux kernel hackers."
If you value your modifications, you have two choices: either adjust your code so that it is accepted by the project leader, or maintain a separate, forked project outside of the main code base. If you choose the latter, you are responsible for keeping your code base in sync with the main code base, not the other way around. You have some support, in the sense that you can still integrate changes from the main code into your forked version, but as a forked project it's your responsibility to integrate them.
Like any open source project, if you choose to operate outside of the mainstream, it's not up to the mainstream to validate and support your particular fork.
you can see the kind of controls Be has put in place to prevent these things from happening.
Yes, they maintain such strict control. After all, OpenTracker is licensed under the BSD license - and we all know how controlling and restrictive that is.
No, you don't seem to quite understand who is saying what.
People are demanding KDE be included in Debian. People *want* KDE in Debian, and that the issue comes up some many times means that there is some significant number of people who are putting pressure on Debian to include KDE.
Debian isn't demanding KDE take their interpretation of the GPL. Debian is simply saying, "We cannot include KDE in our distribution because of what we see as some legal issues regarding the mixing of licenses." Because of the pressure people put on them to include KDE in Debian proper, Debian has tried to work out an acceptable compromise with KDE. It hasn't worked out, so Debian will not include KDE in the main distribution.
That's fine by me, and I respect that choice. It seems a shame that you can't respect it either.
How much swap is truly necessary when you have large amounts of RAM?
My home machine - a dual PII/400 - has 512Mb of PC100 memory. I'm considering installing Debian 2.2 on it when it is released. Do I really even need swap space?
Say, for some reason, you have two identically named people, one on AIM and one on ICQ. In order to send a message to the person on AIM, you would address your Jabber message as: JoeBlow@aim. ICQ would be: JoeBlow@icq. (Notwithstanding that you can't have somebody on ICQ named JoeBlow, because ICQ identifiers are numbers...)
The Jabber service simply checks the "domain" of the message (aim, icq, msn, etc.) and then routes the message through the appropriate service.
Is his total ignorance about things, but his die-hard persistence that he is right.
Q: Did you also testify before congress that the Fair Use Exception was not cut out by the DMCA?
A: Yes. The concept of Fair Use is intact in the DMCA.
Q: Tell he how that is. [sic]
A: Well, I don't know except that the concept is intact.
So he doesn't have any understanding of the law itself, and can't provide information as to the relevant portions of the law. He can't explain how fair use survives under the law, but he absolutely and unequiovacably knows that fair use is intact? Granted, I'm not a lawyer either - but I've read the DMCA myself and could probably explain how fair use *doesn't* survive under the law, and I'm not a party to the case! He sounds like one of those people you meet at a party: "I don't know anything about what you're talking about, but you want to know what I think on the matter?"
I wish I had his diehard infallibility. "I don't know anything, but I know I'm right!"
I mean, can you see any other rationale behind their new policy of no install media for OEM Win9x licenses?
Yes, as a bulwark against Linux and other alternative OSes.
Would *you* try and partition your disk and install Linux if you knew you didn't have a way to recover your Windows partition if something went wrong?
Without physical media, fewer people will be willing to try installing a second operating system because they don't have any way of restoring their machines to working order if something goes kaplooie.
You would need a tremendous amount of fuel using conventional propulsion methods, and the cost would be prohibitive.
That's actually false. Should humanity have the where-with-all, we could launch a manned mission to Mars in the next twenty years for a total tab of $50 billion dollars or so, using only the materials and know-how we have today. For one thing, going to Mars does not require any type of fancy, exotic engine. Rockets got us to the moon, and a rocket would be perfectly satisfactory to get a human crew to Mars in a six month period of time with minimal health complications.
The longer the voyage, the more mass you will have to take in order to provide for your crew, and thus the more fuel you will need to propel the extra mass...
Yes, and?
There is a limit to that equation. Assuming that the fuel you are using has a positive thrust-to-weight ratio, eventually you will get to a point where you will have enough fuel to push the fuel, the occupants, the "consumables," and the ship itself. For another thing, it is possible to send a lot of necessary material to Mars before you send a human crew there, which would drastically cut down on the amount of material they would need to take with them on-board.
Slashdot Mirror
Of course, that assumes people are stupid enough to not run a portscanner before an attack. Frankly, I would imagine only the most neophyte crackers would neglect a portscan, especially since there are often easier and more tempting ports to target (especially in the first few days after an exploit is published).
what is up with the 2MB vid cards on most laptops?
From Dell?
Dell, I believe, ships as standard on most laptops the ATI Mobility chipset, which is an 8MB video controller. I purchased an Inspiron 3800 (which will be running Slack shortly), which is probably the low-end of the personal/home user laptops (not that the laptop is all that bad, but it's not meant to replace your server IOW), and that came with just such a controller.
Granted, the Mobility chipset sucks major ass when running any sort of remotely-modern 3D game (Descent III, for instance, crawled on this chipset), but the 8MB is respectable (if not awe-inspiring).
Sure, an argument can be made that Slackware packagers are more careful in their package selection
and the testing of said packages, but considering that most of what is shipped by each distribution is
composed of the same software packages (which incidentally are not created by either Slackware or
Redhat), this is really a moot point.
There are a couple of problems in your statement here which render it "not a moot point."
For one thing, while the type of software that Red Hat and Slackware (since you use this as a comparison) ship may be similar (both, for instance, ship XFree86, GNOME, KDE, etc.), the specific software varies. Slackware may ship slightly older software, or may in fact wait a much longer period of time before shipping a specific version of software. Such was the case in the libc5 vs. libc6/glibc. Red Hat jumped into the fray with libc6/glibc, and to their detriment found it was not quite ready for primetime use. As a result, the perceived quality of Red Hat's software was lowered in the eyes of many users, because the library was not fully tuned, tested, or debugged. Slackware, up until 7.0, continued using libc5 because it was a tried, tested, and debugged library. Only when libc6/glibc was finally quality, dependable software did Slackware switch over. For some, Slackware's reluctance to switch was a hindrance because they couldn't use the latest-and-greatest software that was compiled for other platforms like Red Hat. Others, however, saw that the libc6/glibc libraries were more prone to problems and wanted to avoid them until they were ready.
For another thing, you'll find that because Slackware takes their time in shipping bleeding edge software, the distribution is less prone to security faults than Red Hat's distribution is. While Red Hat has the latest and greatest software, and as a result can offer somewhat more features than Slackware can (depending on the software), Red Hat issues security updates/patches for their distribution more than Slackware does. A significant number of people value security/stability over features - and Slackware is more to their taste. Is this to say Red Hat is crash-prone, or "bad" software? No. It's simply catering to different tastes.
For a third thing, your statement ignores the qualitative differences between distributions that having nothing to do with software. The style of Red Hat's init scripts versus Slackware's, for instance. Some prefer Slackware's init script style because it's more BSD-ish than Red Hat. Does that make it bad? No - it's just catering to a different taste. Some people also like the fact that Slackware has a very minimalistic package management system, because it forces them to learn more about the system and because it offers them more control over their software (whether it actually does or not is an arguable point). Does this make SysV scripts and RPMs bad? No - it just offers a different way of doing things that some people might find less to their taste. Others, as can be witnessed on this thread, find RPMs to be the greatest thing since sliced bread!
So what is really fair when comparing distributions? IMHO it's what they aggregate (package management systems, new packages etc), and in that respect, Redhat produces more and better software than Slackware.
Quantity vs. quality as a valid metric? Shove as much into the distribution as possible, and you're guaranteed to be considered "the best?" That's a spotty judgement call at best.
You're right when you say it's fair to judge distributions on what they aggregate. But relying *soley* on that aggregative factor is ignoring everything else that makes distributions unique. It's just as much propaganda to claim that Red Hat is better because it has more to it as it is to claim that Slackware is better because it is "rock solid." It's just different, not better.
Further, judging which distribution is "best" involves knowing who you are judging it for. For desktop users who want an install-and-go Linux experience, Red Hat is overwhelmingly the better choice. However, for those users who want to delve into the system and not have their hand held by GUI utilities, or who want a slightly more "generic" Linux experience (and, admit it or not, Red Hat provides an awful lot of custom utilities for administrating their distribution), or who don't want to become dependent on a packaging system, Slackware is probably the better choice.
Don't be a distribution bigot. Choose the distribution because it's the best for you, not because some Slashdot hack says so. (It's kinda like those Sprite commercials. You wouldn't listen to some moron spout off his mouth about other things; why listen to them do it about distributions?) Just be content that what you use is the best one for you, and let everybody be free to choose their distribution based on the merits of those distributions.
Oops. Sorry - you're right. Brain-cramp. :)
I got it now! When my car runs out of gas it is "rock solid" too: its position in my garage is "stable" and it is not prone to crashes or accidents. Glad you clarified that for me...
A wise man once said, and I think it entirely appropriate for your comment, "Don't be a dick.
In this instance, referring to software, "rock solid" means "stable." A "rock solid" piece of software is robust, bug-free, and fault tolerant. A "rock solid" program can handle bad user input with grace, doesn't have memory leaks or security issues, does not crash at random, and is capable of handling any problems that come up during the use of the program (traps errors before they become problematic enough that the program can't continue).
When referring to cars, "rock solid" means that the vehicle in question is of high-quality, can run for a very long time (years) without things going wrong with the car, and capable of performing feats that lesser quality cars could not - hauling sailboats three times its size, filling a truck bed with several tons of rock and moving it up 45-degree-incline hills, and so on (hence the line of Chevy truck commercials that end with the tagline, "Chevy - Like A Rock").
Now, are you through being a dick?
What is "rock solid"?
Stable. Very, very stable. Not prone to crashing, bugs, or security holes.
Ok, ok, so the GPL is not GPL'ed. :)
"Losers always whine about their best; winners go home and fuck the prom queen.
:)
My favorite line from The Rock.
You misunderstand what that little phrase is saying.
Essentially, anything you create is copyrighted by you by mere fact that you created it (notwithstanding patent infringements, etc.). What that blurb means is that "copylefting" a program first acknowledges there is a copyright on it, and that with that copyright comes a whole boatload of permissions and restrictions.
Then, after the FSF/GPL acknowledges all of those permissions and restrictions on the program given by the copyright, the program is then given additional permissions and restrictions that may or may not modify the ones given to you by the copyright (such as distribution terms).
In the absence of a copyleft, you have only the permissions and restrictions given by the copyright, which in turn is given to you by the mere fact that you created an original piece of work.
Now, copyrights do need to be inforced or they become worthless, but that's a different kettle of fish.
Ironically, that's the way open source is supposed to work. :) You write some software, and other people take a look at it. They find some flaws, point them out, and you get to patch the problems. In this case, you write a license agreement, and other people take a look at it. they find some flaws, point them out, and you write a new license that fixes all the problems.
:)
Even in license agreements, with enough eyes all bugs are shallow.
If you wanted to show your ignorance, you just succeeded.
Strong words coming from somebody either too lazy or too scared to log in and identify themselves.
And you still didn't answer the question in any meaningful way. If I'm so ignorant, why don't you correct me?
For example, in the proposed .net world, you automatically download a copy (or a cached subset, depending upon your device) of your work from the "cloud" and automatically synchronize your changes later. This permits disconnected operation, e.g. working from a disconnected notebook or low-bandwidth wireless handheld.
As someone else said, "Feh.
Aside from gratuitous use of the word "automated," there is nothing new about this approach. This morning when I left for work, I FTP'd some files from my home machine to my laptop. When I get home, I will FTP my updated files back. If I really wanted to, I could simply set up an automated task that periodically FTPs the files back to my main system.
It sounds to me like this is simply some sort of technology that makes a shared client/server folder on a computer. When the computer connects, any changed data between the two refreshes in the background. Any changes on the shared folder get updated on the server, up until the time the computer/folder is disconnected.
So what do you need to mimic this?
* File-sharing technology. On UNIX, take your pick.
* Monitor on the server and the client (monitors a particular folder for changes, manages connections between computers)
A little bit of NFS, a little bit of user-space daemon, and voila! UNIX.Net.
What this community bashes now, in three years they will eagerly clone -- see OLE2 vs Bonobo.
OLE2? Or is it OLE? Or ActiveX? Or COM? Or COM+? Which is the acronym this month?
At any rate, your idea is flawed. Microsoft didn't invent component-based architecture, and the merits of such an approach were well-known before Microsoft adopted thier technology-acronym-of-the-day. It's a bit disingenuous to claim that every single architectural approach offered in UNIX is only offered because Microsoft did it first. Perhaps if you could offer some evidence to prove that UNIX wouldn't have done it if Microsoft hadn't done it, I would have an easier time believing you.
Windows.Net: Because it's full of holes, and the only thing holding it together is a bit of string.
Sounds almost like full-body Simon.
"Wait - was it green-green-red-blue, or green-blue-green-yellow?"
:)
This will reduce costs dramatically, with a maximum initial setup cost of 25 cents.
Not necessarily. Now we have those fancy Sacagewea dollar coins. So, if you look it another way, the maximum initial setup cost has now ballooned four-fold into $1.
Most downloadable software is based on the notion of registration or access keys.
Some software, such as WinZip, comes as a registerable shareware version. When you "buy" the software, you're really buying a registration number which then enables the software completely. If you delete the software, you can simply download a fresh copy of the shareware version and enter the registration key, and voila! - WinZip is unrestricted again.
Other types of software which can be purchased on-line, such as Partition Magic, works slightly similarly. You get a registration number and special download link. When you go to that link, you have to enter your registration number to get through. Once through, you can download the full version of the software. Should you torch PM, all you need to do is follow through the linking process and download a full, fresh copy.
For operating systems, though, I would imagine you would have to record it on a less volatile medium, such as a Zip disk or CD-ROM.
The problem is that there doesn't seem to be any list of what software in Slackware (or any other distribution for that matter, besides Debian) is non-free.
I wish there was an easier alternative for finding out what non-free is in Slackware than going through package by package...
The controls are more like if we don't like it, it doesn't touch the "official" codebase. These rules even apply to indenting and commenting. They're neither strict nor intrusive, but they do insure that things get done the way Be wants them done.
Why is that a problem?
Any large project requires guidelines for the way things are done, and formatting rules are important - nay, necessary - to keep a project coherent. It's the same reason why, on large projects, you agree on variable naming schemes - so that the code remains consistent throughout. It's difficult to read through code that looks like:
void OnFunctionFubar (int nParam1, int nParam2)
{
DoSomething (nParam1, nParam2);
}
VOID
on_Func_Do_This
(int intParOne, int intParTwo) {
do_SomethingElse (intParam1,
intParam2);
}
Insisting on a standard naming and formatting scheme is essential for keeping the OpenTracker code in understandable order. The particular naming and formatting schemes may be arbitrary, or not to your particular taste (for example, I detest K&R open-bracket formatting), but they are there for an important reason.
Yeah you can take the source and do what you would with it, but you'd have to maintain all of it yourself, convince BeOS users everywhere to use it instead of the Be-sanctioned option, and go without any support from Be. Instead of "do it our way or we'll sue you," it's "do it our way or we won't help you and neither will anyone else."
Now you're just being silly. You're trying to claim that Be/OpenTracker should somehow be responsible for forked projects.
If you decide to take the Linux kernel and replace the virtual memory system, and Torvalds rejects the patch, does he (or any other kernel hacker, for that matter) have an obligation to support your modifications? Of course not. To paraphrase your own words, "Yeah, you can take the source and do what you would with it, but you'd have to maintain all of it yourself, convince Linux users everywhere to use it instead of the Torvalds-sanctioned option, and go without any support from the Linux kernel hackers."
If you value your modifications, you have two choices: either adjust your code so that it is accepted by the project leader, or maintain a separate, forked project outside of the main code base. If you choose the latter, you are responsible for keeping your code base in sync with the main code base, not the other way around. You have some support, in the sense that you can still integrate changes from the main code into your forked version, but as a forked project it's your responsibility to integrate them.
Like any open source project, if you choose to operate outside of the mainstream, it's not up to the mainstream to validate and support your particular fork.
you can see the kind of controls Be has put in place to prevent these things from happening.
Yes, they maintain such strict control. After all, OpenTracker is licensed under the BSD license - and we all know how controlling and restrictive that is.
No, you don't seem to quite understand who is saying what.
People are demanding KDE be included in Debian. People *want* KDE in Debian, and that the issue comes up some many times means that there is some significant number of people who are putting pressure on Debian to include KDE.
Debian isn't demanding KDE take their interpretation of the GPL. Debian is simply saying, "We cannot include KDE in our distribution because of what we see as some legal issues regarding the mixing of licenses." Because of the pressure people put on them to include KDE in Debian proper, Debian has tried to work out an acceptable compromise with KDE. It hasn't worked out, so Debian will not include KDE in the main distribution.
That's fine by me, and I respect that choice. It seems a shame that you can't respect it either.
How much swap is truly necessary when you have large amounts of RAM?
My home machine - a dual PII/400 - has 512Mb of PC100 memory. I'm considering installing Debian 2.2 on it when it is released. Do I really even need swap space?
Actually, this is what Jabber does.
Say, for some reason, you have two identically named people, one on AIM and one on ICQ. In order to send a message to the person on AIM, you would address your Jabber message as: JoeBlow@aim. ICQ would be: JoeBlow@icq. (Notwithstanding that you can't have somebody on ICQ named JoeBlow, because ICQ identifiers are numbers...)
The Jabber service simply checks the "domain" of the message (aim, icq, msn, etc.) and then routes the message through the appropriate service.
Is his total ignorance about things, but his die-hard persistence that he is right.
Q: Did you also testify before congress that the Fair Use Exception was not cut out by the DMCA?
A: Yes. The concept of Fair Use is intact in the DMCA.
Q: Tell he how that is. [sic]
A: Well, I don't know except that the concept is intact.
So he doesn't have any understanding of the law itself, and can't provide information as to the relevant portions of the law. He can't explain how fair use survives under the law, but he absolutely and unequiovacably knows that fair use is intact? Granted, I'm not a lawyer either - but I've read the DMCA myself and could probably explain how fair use *doesn't* survive under the law, and I'm not a party to the case! He sounds like one of those people you meet at a party: "I don't know anything about what you're talking about, but you want to know what I think on the matter?"
I wish I had his diehard infallibility. "I don't know anything, but I know I'm right!"
I mean, can you see any other rationale behind their new policy of no install media for OEM Win9x licenses?
Yes, as a bulwark against Linux and other alternative OSes.
Would *you* try and partition your disk and install Linux if you knew you didn't have a way to recover your Windows partition if something went wrong?
Without physical media, fewer people will be willing to try installing a second operating system because they don't have any way of restoring their machines to working order if something goes kaplooie.
You would need a tremendous amount of fuel using conventional propulsion methods, and the cost would be prohibitive.
That's actually false. Should humanity have the where-with-all, we could launch a manned mission to Mars in the next twenty years for a total tab of $50 billion dollars or so, using only the materials and know-how we have today. For one thing, going to Mars does not require any type of fancy, exotic engine. Rockets got us to the moon, and a rocket would be perfectly satisfactory to get a human crew to Mars in a six month period of time with minimal health complications.
The longer the voyage, the more mass you will have to take in order to provide for your crew, and thus the more fuel you will need to propel the extra mass...
Yes, and?
There is a limit to that equation. Assuming that the fuel you are using has a positive thrust-to-weight ratio, eventually you will get to a point where you will have enough fuel to push the fuel, the occupants, the "consumables," and the ship itself. For another thing, it is possible to send a lot of necessary material to Mars before you send a human crew there, which would drastically cut down on the amount of material they would need to take with them on-board.