The famous German computer magazine c't reported the same as Tom in a recent article. (It was about coolers, IIRC.) They said that you have to be very careful to mount the cooler correctly. If it doesn't sit correctly, i.e. it doesn't contact the CPU flatly and there is a millimeter or so of air between cooler and CPU, then the CPU burns and is destroyed "within seconds" - the machine won't even boot anymore. They said so, because it happened to them during the tests. It was an 1.2 MP, IIRC.
> It's to prevent such problems that the FSF
> requires people making significant contributions
> to a GNU Project project to sign their copyrights
> (for just that specific project, of course) to
> the FSF.
I don't think, that helps anything here. In both cases (GNU copyright vs. just licensing), you rely on the statement of the developer that this is his own code.
> Everyone agrees that it's a pain, but most
> people (but not all, such as some XEmacs
> hackers) agree with the reasoning behind it.
Actually, a lot of people not involved with the GNU project are not involved for exactly this reason.
I always counted the error handling as big advantage for open-source.
In commercial GUI apps, you usually get an error with the content of approximately "Sorry, something went wrong. Please see our Help" - the last word points to a completely generic and useless help or web page.
RealPlayer is especially bad. Just about every error I ever got was the above error dialog, and the webpage told me that 'this is an infrequent error, for which there is no description. Please excuse.' Interestingly, those "infrequent errors" included a non-reachable Internet.
I guess that commercial programmers want to "save" users from the messy details (forgetting that the user has to care about them anyway, because he has to fix them) or just have "no time" (but prefer to add features).
With open-source, you have to look harder for error msgs (usually in/var/log/something -
grep appname/var/log/*
helps a lot), but those that you get usually point you very precisely to the problem, which makes fixing the problem *a lot* easier.
Of course, a program being open-source (or a programmer using those licenses) doesn't automatically give it such attributes like good error handling. There are good and bad apps in each "league".
Error handling (and proper reporting of them to the user) might be dry to program, but saves the user countless hours of hair-tearing - regardless, if expericed or novice users.
I saw a 2 year old (IIRC) report on TV where a reporter tested airport security by putting a pistol in his shue. He got through the checks (2 times, IIRC).
It is also necessary that my belt doesn't contain a mini-knife or something. Do they check that? No.
My point: Concentrate on checks that/sufficiently/ rule out possibilities *and* that don't harm the "good" people's rights too much. Many of the recently introduced checks (and laws BTW) seem to fail both criteria.
> Someone could make a distribution where everything > would be tuned for speed and ease of use, perhaps > comprimising security, but as long as it only
> affects the machine it's running on it's no one's
> business.
We are talking about PCs. Their idea is that you can do more than one thing with them.
If an "ISP" blocks *any* traffic, it is not an ISP (Internet Service Provider) anymore. The core business of an ISP is to allow me to participate on the whole Internet and communicate using IP, otherwise it's just a better AOL. If it fails to provide free IP communication to the Internet, it fails to do its job.
If you argue that blocking direct SMTP is a good idea, good luck arguing when the RIAA wants Freenet traffic to be blocked.
I'd argue that this is "fair use". He uses the word to refer to the real Linux in a normal text. To my knowledge, there is no legal requirement to add "(TM)" to each use of the trademark. Otherwise, you would have to write:
"Linux(TM) *is also* a registered trademark, Microsoft(TM)."
or similar. What about "linuxtmjournal"? Of course, that's silly.
Trademarks protect from *abuse*, e.g. from you labelling your own product "Linux".
> We will not release that code under a less
> restrictive license (such as the Wine license)
> unless and until we have a paying subscriber base
> of at least 20,000 users.
Why?
I assume that they take the subscription fees, pay themselves their salaries for it and start to develop for the time paid. Repeat.
So, once they wrote code, it is already paid by the subscribers. Why not immediately release it as open-source then?
In that case, subscribers would do nothing else than paying someone (in small portions) to do certain open-source development.
I think that this is a better model, because I don't know, if they will ever open-source the code. With the model I describe, my risk is about 5$, with their model, my risk is all the fees I pay until they reached their goal.
But for typical job loads under Linux, the processor type is nearly a red herring[...]
If you don't believe this, you may find it enlightening to keep top(1) running for a while as you use your machine. Notice how seldom the CPU idle percentage drops below 90%.
While the statement has some truth, it uses a bad rationale.
How long, during "typical job"s, do you wait for a modern PC usually? 500ms? At most 2s, right?
But |top| typically gives you one value every 5s or so, and only averages. If |top| would show you the peak of CPU usage during the last interval, you would see that during the times you wait for the PC, the CPU almost always has a load of 100% at some point.
Which means that part of the time, you indeed wait for the CPU during typical usage. (Often, that's only milliseconds, but with Mozilla, it can be 1s:-/.)
If you are interested, I suggest, you use a CPU-load graph tool in your GNOME/KDE/WindowMaker panel, set the interval really low (like 10ms) and make the "contrast" high (black background and bright foreground). This will show you almost every CPU peak and thus show you, when you are really waiting for the CPU (even if it's just ms).
If you say, milliseconds don't matter, then you don't need a top-notch PC for "typical job[...]s under Linux"
We'll stick with Intel hardware. [...]
PC hardware has all the advantages of the biggest market; it's the easiest to get serviced and least expensive to upgrade, and thus scores high on the hardware-you-can-live-with scale.
Just like Microsoft software, right?
Re:Whats wrong with more features?
on
Mozilla 0.9.5
·
· Score: 2, Informative
Every feature adds bugs. Some are probably crashs, some of them might even be security bugs.
Also, the more time you spend on features, the less time you have for bugfixing the rest.
When the homewoek is done
on
Mozilla 0.9.5
·
· Score: 2, Insightful
Let's first implement the existing useful standards (of which the tag is certainly one) before we start to "innovate".
Actually, the license seems to be a closed-source license. It doesn't give you rights to distribute the "work" in compliance with the license. I.e. (assuming there are no other licenses applicable to the "work") you can't distribute the "work".
But, since the author said, he "proposed [...] the License", does that imply that he encourages modifications to the license? Is the license text itself maybe available under Free Software terms? That would be consistent with the intention of inconsistency of the license.
> I just wonder what is different about the training
> of *nix admins
They need to learn a lot to get a Unix system going well. They are forced to read documentation. In that documentation, the author has a chance to tell the admin about security and its importance.
Slashdot Mirror
mozilla.org requires a written document, too, but doesn't require to assign the copyright to it.
The famous German computer magazine c't reported the same as Tom in a recent article. (It was about coolers, IIRC.) They said that you have to be very careful to mount the cooler correctly. If it doesn't sit correctly, i.e. it doesn't contact the CPU flatly and there is a millimeter or so of air between cooler and CPU, then the CPU burns and is destroyed "within seconds" - the machine won't even boot anymore. They said so, because it happened to them during the tests. It was an 1.2 MP, IIRC.
> They just removed all that code and a developer
> reimplimented it.
The poster said "thoroughly integrated" - removing it would be very hard.
"Thanks your great code. You don't know, what to eat, but I don't care - I have my cool theme."
> It's to prevent such problems that the FSF
> requires people making significant contributions
> to a GNU Project project to sign their copyrights
> (for just that specific project, of course) to
> the FSF.
I don't think, that helps anything here. In both cases (GNU copyright vs. just licensing), you rely on the statement of the developer that this is his own code.
> Everyone agrees that it's a pain, but most
> people (but not all, such as some XEmacs
> hackers) agree with the reasoning behind it.
Actually, a lot of people not involved with the GNU project are not involved for exactly this reason.
The URL goves me "Access denied - This homepage has exceeded the maximum amount of traffic for one day.". Here's Google's cache: home - features.
I always counted the error handling as big advantage for open-source.
/var/log/something -
/var/log/*
In commercial GUI apps, you usually get an error with the content of approximately "Sorry, something went wrong. Please see our Help" - the last word points to a completely generic and useless help or web page.
RealPlayer is especially bad. Just about every error I ever got was the above error dialog, and the webpage told me that 'this is an infrequent error, for which there is no description. Please excuse.' Interestingly, those "infrequent errors" included a non-reachable Internet.
I guess that commercial programmers want to "save" users from the messy details (forgetting that the user has to care about them anyway, because he has to fix them) or just have "no time" (but prefer to add features).
With open-source, you have to look harder for error msgs (usually in
grep appname
helps a lot), but those that you get usually point you very precisely to the problem, which makes fixing the problem *a lot* easier.
Of course, a program being open-source (or a programmer using those licenses) doesn't automatically give it such attributes like good error handling. There are good and bad apps in each "league".
Error handling (and proper reporting of them to the user) might be dry to program, but saves the user countless hours of hair-tearing - regardless, if expericed or novice users.
I saw a 2 year old (IIRC) report on TV where a reporter tested airport security by putting a pistol in his shue. He got through the checks (2 times, IIRC).
> It is necessary but not sufficient.
/sufficiently/ rule out possibilities *and* that don't harm the "good" people's rights too much. Many of the recently introduced checks (and laws BTW) seem to fail both criteria.
It is also necessary that my belt doesn't contain a mini-knife or something. Do they check that? No.
My point: Concentrate on checks that
> Someone could make a distribution where everything > would be tuned for speed and ease of use, perhaps > comprimising security, but as long as it only
> affects the machine it's running on it's no one's
> business.
We are talking about PCs. Their idea is that you can do more than one thing with them.
Qwest also runs backbones, i.e. even if you are not a Qwest customer (maybe even in a different country), your traffic might pass through Qwest.
Does that mean that MS may have a chance to peek on that traffic?
If an "ISP" blocks *any* traffic, it is not an ISP (Internet Service Provider) anymore. The core business of an ISP is to allow me to participate on the whole Internet and communicate using IP, otherwise it's just a better AOL. If it fails to provide free IP communication to the Internet, it fails to do its job.
If you argue that blocking direct SMTP is a good idea, good luck arguing when the RIAA wants Freenet traffic to be blocked.
I'd argue that this is "fair use". He uses the word to refer to the real Linux in a normal text. To my knowledge, there is no legal requirement to add "(TM)" to each use of the trademark. Otherwise, you would have to write:
"Linux(TM) *is also* a registered trademark, Microsoft(TM)."
or similar. What about "linuxtmjournal"? Of course, that's silly.
Trademarks protect from *abuse*, e.g. from you labelling your own product "Linux".
IANAL.
> Too bad phones don't have the equivalent of procmail filters.
Actually, I am working on such an application. Watch my homepage - I'll release it soon.
> We will not release that code under a less
> restrictive license (such as the Wine license)
> unless and until we have a paying subscriber base
> of at least 20,000 users.
Why?
I assume that they take the subscription fees, pay themselves their salaries for it and start to develop for the time paid. Repeat.
So, once they wrote code, it is already paid by the subscribers. Why not immediately release it as open-source then?
In that case, subscribers would do nothing else than paying someone (in small portions) to do certain open-source development.
I think that this is a better model, because I don't know, if they will ever open-source the code. With the model I describe, my risk is about 5$, with their model, my risk is all the fees I pay until they reached their goal.
I just created a page where I post comments about some hardware I used, telling if I am satisfied with it or not.
I suggest that you do the same, so we can all make better buying decisions.
While the statement has some truth, it uses a bad rationale.
How long, during "typical job"s, do you wait for a modern PC usually? 500ms? At most 2s, right?
But |top| typically gives you one value every 5s or so, and only averages. If |top| would show you the peak of CPU usage during the last interval, you would see that during the times you wait for the PC, the CPU almost always has a load of 100% at some point.
Which means that part of the time, you indeed wait for the CPU during typical usage. (Often, that's only milliseconds, but with Mozilla, it can be 1s
If you are interested, I suggest, you use a CPU-load graph tool in your GNOME/KDE/WindowMaker panel, set the interval really low (like 10ms) and make the "contrast" high (black background and bright foreground). This will show you almost every CPU peak and thus show you, when you are really waiting for the CPU (even if it's just ms).
If you say, milliseconds don't matter, then you don't need a top-notch PC for "typical job[...]s under Linux"
Every feature adds bugs. Some are probably crashs, some of them might even be security bugs.
Also, the more time you spend on features, the less time you have for bugfixing the rest.
Let's first implement the existing useful standards (of which the tag is certainly one) before we start to "innovate".
> I realize S/MIME is a "standard", but I've not
> seen it used at all...
S/MIME is big in the business sector, much like PGP in the private one.
> Essential for any Free Software project.
Actually, the license seems to be a closed-source license. It doesn't give you rights to distribute the "work" in compliance with the license. I.e. (assuming there are no other licenses applicable to the "work") you can't distribute the "work".
But, since the author said, he "proposed [...] the License", does that imply that he encourages modifications to the license? Is the license text itself maybe available under Free Software terms? That would be consistent with the intention of inconsistency of the license.
> still available under the MPL
...or NPL.
> When Mozilla copylefts SAMPLE code
But it didn't. the code is still available under the MPL. The GPL is only an *option*. Please read the MPL 1.1. Thanks.
> I just wonder what is different about the training
> of *nix admins
They need to learn a lot to get a Unix system going well. They are forced to read documentation. In that documentation, the author has a chance to tell the admin about security and its importance.