It probably won't happen, because one of the people who think it's too early is our Project Leader, Wichert Akkerman.
The opinion of the Project Leader is irrelevant (well, it's as relevant as the opinion of any individual developer). He can't overturn a decision made by one of his delegates (see the Constitution, point 8.2).
Yes, I am leaking information here.
Well, next time please be sure to leak correct information:-)
It seems to me that most of the packages could be checked in to unstable, screened for bugs & stuff, then promoted to stable. Only the main infrastructure stuff, like installation and admin packages would really have to follow a more conventional release process.
Several schemes similar to this have been proposed. The most important reason Debian has not switched is that it would require huge changes in project infrastructure (including an enormous one-time hit on the mirrors, I believe) and there simply isn't the energy (enthusiastic manpower, that is) to revamp the system that thoroughly.
I suggest you check out past discussion on the Debian lists, through the public archives.
...not yet running Debian, but wanting to, is there an FTP site(s) which will more than likely have an.ISO available? Thanks in advance.
Debian creates CD-ROM images for stable releases only. You can find more information in the Debian CD image site. If you want to participate in testing new releases (including new CD images), please join the debian-testing list (see the subscription information).
This assumes the U.S. would have jurisitiction. They may not.
The "all rights reserved" default is not a unique feature of the US copyright law. In fact, it is part of the Berne convention, on which copyright law is based in almost everywhere on the world. (In fact, my comments were based on Finnish copyright law, not that of the US.
It would be very unlikely for the US DoJ to take any criminal action in cases where the copyright was not registerred.
Copyright registration is not required, and in fact in most (some? certainly in Finland) countries there is no mechanism to register copyright, as it is an automatic right.
If you're so gung-ho by calling Perl "interpreted", then I wonder what you mean by a "real compiler".
The distinction between an interpreter and a compiler is not at all well defined. Both contemporary interpreters and compilers contain a translator as an essential component, a translator which usually outputs machine code for some (real or virtual) processor. So what's the difference? A naive definition (which should be sufficient for discussing perl) says that the output of an interpreter's translator is targeted at a hardware emulator (the virtual machine implementation). The emulator may be embedded in an executable together with the translator output. Conversely, the output of a compiler is targeted at some real chip's machine code, and you can't separate a posteriori the output into an emulator and bytecode. But this is by no means a comprehensive definition, so don't read too much into it.
The Perl compiler gives you C code. Which you can compile with a C compiler. Which gives you a huge binary, which basically is the same as you have after perl compiles the code.
I was told by someone who I regard as an authority on matters perl that the perl compiler can generate C code that is better than what you describe: that you cannot separate it into bytecode and its interpreter or into a trivial variation of this theme.
Perl is "interpreted" about the same way compiled C code is - by a low-level interpreter.
I doubt the perl interpreter is as low-level as chip hardware or microcode.
The MIT X license explicitly allows relicensing the work, the BSD license gives an equivalent right by allowing the work to be distributed without any restrictions. So, both licenses allow me to put on the GPL.
The damn GPL won't even let you use a GPLd subroutine in your non-GPLd program or even link to a GPLd library.
True. I'd say that's a good thing except that if I did say that, I'd be flamed to death;-) Seriously, the GPL was designed to keep software free, and I can't think of a way to do this better.
If a license is invalid, then there is no license and the default "all rights reserved" applies. You can't make a program free by declaring its license invalid.
First of all, *nothing* but GPL code can link to the GPL - not BSD, not QPL - no other license.
This is totally false. Linking a program against a GPL library makes (this particular copy of) the whole program GPL'd. If the program is licensed so that it can be distributed under the GPL (for example the BSD license without the advertising clause and the MIT X license allow this), there is no problem.
That is why libraries use the *LGPL*
This is again false. The L in LGPL used to stand for Library, but this was confusing people, so it now stands for Lesser. It is perfectly all right to license a library under the GNU GPL, in fact, the GNU project encourages people to do that. They regard GNU LGPL as inferior in all respects (as the name suggests); only rarely does a GNU library use the LGPL.
This is the only library I ever heard to use GPL
In that case you have very limited knowledge on free software. There are many examples of GPL'd libraries, including GNU readline and Guile (which has a similar but more general exception clause to the one mentioned in this story).
OK very dated was a bit harsh but at the rate GNU/Linux moves it did seem very dated to me when I switched:)
a.out would be very dated. libc5 would be dated. Linux 0.x would be very dated, even Linux 1.0 would be very dated. Perhaps we mean different things with the word "dated"?
There are no guarentees if you use stable either!
There are no warranties, true. But with stable you know the system will not break tomorrow, if it didn't break today. With stable, you also know that if you could install it yesterday, you can install it today, too. With unstable, you have no such knowledge.
Too many people rely on Potato for people to throw in untested system breaking stuff; that would lose someone their developer status I think.
No. I know only one or two cases where people were thrown out of the project, and although I can't discuss the details, I can tell you this was not done because they broke the system (if they ever did that). No. If a system throws one out because of a mistake, you'd lose all the creativity: if you can't afford to make errors, you can't afford to do anything excellently.
We have recently seen an incident where a package wiped out an entire system directory (I forget whether it was/etc or/dev). The developer who made the mistake is still with us.
any really experimental stuff is suposed to go in the experimental branch as I recall.
This is true when the code really is critical and experimental. But it is possible to make critical errors without experimenting.
The current ``stable'' version is slink and is very dated
Dated? It was released on March, and frozen on November. So it's less than a year old anyhow. I don't think being a year old qualifies Slink as "very dated".
Yes you can. But don't do it unless you can stand total system failure. There are no guarantees if you use unstable. That said, I've never personally experienced a total system breakdown due to a bug in unstable, although I've missed a couple with luck.
... will Corel Linux be stuck with doing just Deb's, or will it be able to handle both Deb's and RPM's by default?
You should understand that installing packages not created for your distribution can be problemous, regardless of what package format is used. That said, Alien can convert between many packaging formats, including deb's and rpm's.
Something that may help the whole community out, espicialy with all the new distros coming out based on redhat/debian/etc is a "generic" package format.
That's an illusion. The differences between package formats are mostly trivial nowadays - a correct translation between rpm's and deb's is possible and afaik alien does that. The big problems are not because of package formats, but because of different policies between distributions. Those things cannot be automatically translated between distributions, and a common package format will not fix that.
According to you. Spam is unsolicited *advertising*, by my definition.
My definition is based on what Usenet cancellers use. There, content is never part of the question. All that matters is the BI of the posting in question (ie the amount of multiposting and crossposting).
I just sent a mail to 10 people I know at university, and I didn't ask them first.
People expect to get mail from people they know personally. That would make your mail solicited, depending on what the mail was all about. (No, content still does not enter the definition. We usually just accept only certain kinds of mail as accepted behaviour from acquaintances.)
This also applies to the mail to Slashdot posters you mentioned. One expects to get comments on one's public words.
If I were to suck a list of Linux kernel developers and mail them all saying `here, have a free Quad PII Xeon box, to help with your development work', would that be spam?
If you mail them all the same form letter, then yes, you'd be spamming.
If they'd researched your background, you'd have screamed - "PRIVACY INVASION!"
No, I wouldn't have. The information they would have needed is publically available from my home page and is also evident from the email address I use most of the time.
If I decided to email you about some investment opportunity, would you consider that spam too?
Content does not define what's spam.
How about if I was just telling you about the new Debian release?
Content does not define what's spam.
Or what the weather was like where I live?
Content does not define what's spam.
Where do you draw the line?
If it was sent to a list of people who did not solicit the mail, it is spam. No exceptions.
People abuse the word spam.
They do indeed.
Re:Just Blame Them With Spam ... Riiiight....
on
Red Hat IPO Surprise
·
· Score: 1
How many emails and of what nature constitute spam?
I define spam as unsolicited mass email. It was certainly unsolicited, and I don't think anyone would argue that it wasn't mass mailed.
Unless they sent you like 5 emails I don't see why you're whining.
I get over 10 spam messages in a week. Usually I get only one copy of each, but later it will turn out I was not the sole victim. In this case, the message rang all my spam bells and whistles, if we disregard the sender. And really, the sender should not matter.
Are people saying this is not spam because they don't believe RH would spam?
For all of you that think this is spam think again this is a GREAT offer.
It may be a great offer. I don't comment on that. However, content does not define what's spam. Spam is an unsolicited mass mail. And that's what this was.
Yes it is.
It probably won't happen, because one of the people who think it's too early is our Project Leader, Wichert Akkerman.
The opinion of the Project Leader is irrelevant (well, it's as relevant as the opinion of any individual developer). He can't overturn a decision made by one of his delegates (see the Constitution, point 8.2).
Yes, I am leaking information here.
Well, next time please be sure to leak correct information :-)
Several schemes similar to this have been proposed. The most important reason Debian has not switched is that it would require huge changes in project infrastructure (including an enormous one-time hit on the mirrors, I believe) and there simply isn't the energy (enthusiastic manpower, that is) to revamp the system that thoroughly.
I suggest you check out past discussion on the Debian lists, through the public archives.
Debian creates CD-ROM images for stable releases only. You can find more information in the Debian CD image site. If you want to participate in testing new releases (including new CD images), please join the debian-testing list (see the subscription information).
The "all rights reserved" default is not a unique feature of the US copyright law. In fact, it is part of the Berne convention, on which copyright law is based in almost everywhere on the world. (In fact, my comments were based on Finnish copyright law, not that of the US.
It would be very unlikely for the US DoJ to take any criminal action in cases where the copyright was not registerred.
Copyright registration is not required, and in fact in most (some? certainly in Finland) countries there is no mechanism to register copyright, as it is an automatic right.
The distinction between an interpreter and a compiler is not at all well defined. Both contemporary interpreters and compilers contain a translator as an essential component, a translator which usually outputs machine code for some (real or virtual) processor. So what's the difference? A naive definition (which should be sufficient for discussing perl) says that the output of an interpreter's translator is targeted at a hardware emulator (the virtual machine implementation). The emulator may be embedded in an executable together with the translator output. Conversely, the output of a compiler is targeted at some real chip's machine code, and you can't separate a posteriori the output into an emulator and bytecode. But this is by no means a comprehensive definition, so don't read too much into it.
The Perl compiler gives you C code. Which you can compile with a C compiler. Which gives you a huge binary, which basically is the same as you have after perl compiles the code.
I was told by someone who I regard as an authority on matters perl that the perl compiler can generate C code that is better than what you describe: that you cannot separate it into bytecode and its interpreter or into a trivial variation of this theme.
Perl is "interpreted" about the same way compiled C code is - by a low-level interpreter.
I doubt the perl interpreter is as low-level as chip hardware or microcode.
Bytecode is an implementation technique for interpreters.
Well, you can call it interpreted if you want but if you do then so is java.
Yes, they both are interpreted languages.
BTW, there is a real perl compiler in the latest release. It's just experimental.
The MIT X license explicitly allows relicensing the work, the BSD license gives an equivalent right by allowing the work to be distributed without any restrictions. So, both licenses allow me to put on the GPL.
The damn GPL won't even let you use a GPLd subroutine in your non-GPLd program or even link to a GPLd library.
True. I'd say that's a good thing except that if I did say that, I'd be flamed to death ;-) Seriously, the GPL was designed to keep software free, and I can't think of a way to do this better.
What part of it? I see nothing here that contradicts what I said. Am I missing something?
If a license is invalid, then there is no license and the default "all rights reserved" applies. You can't make a program free by declaring its license invalid.
This is totally false. Linking a program against a GPL library makes (this particular copy of) the whole program GPL'd. If the program is licensed so that it can be distributed under the GPL (for example the BSD license without the advertising clause and the MIT X license allow this), there is no problem.
That is why libraries use the *LGPL*
This is again false. The L in LGPL used to stand for Library, but this was confusing people, so it now stands for Lesser. It is perfectly all right to license a library under the GNU GPL, in fact, the GNU project encourages people to do that. They regard GNU LGPL as inferior in all respects (as the name suggests); only rarely does a GNU library use the LGPL.
This is the only library I ever heard to use GPL
In that case you have very limited knowledge on free software. There are many examples of GPL'd libraries, including GNU readline and Guile (which has a similar but more general exception clause to the one mentioned in this story).
a.out would be very dated. libc5 would be dated. Linux 0.x would be very dated, even Linux 1.0 would be very dated. Perhaps we mean different things with the word "dated"?
There are no guarentees if you use stable either!
There are no warranties, true. But with stable you know the system will not break tomorrow, if it didn't break today. With stable, you also know that if you could install it yesterday, you can install it today, too. With unstable, you have no such knowledge.
Too many people rely on Potato for people to throw in untested system breaking stuff; that would lose someone their developer status I think.
No. I know only one or two cases where people were thrown out of the project, and although I can't discuss the details, I can tell you this was not done because they broke the system (if they ever did that). No. If a system throws one out because of a mistake, you'd lose all the creativity: if you can't afford to make errors, you can't afford to do anything excellently.
We have recently seen an incident where a package wiped out an entire system directory (I forget whether it was /etc or /dev). The developer who made the mistake is still with us.
any really experimental stuff is suposed to go in the experimental branch as I recall.
This is true when the code really is critical and experimental. But it is possible to make critical errors without experimenting.
Dated? It was released on March, and frozen on November. So it's less than a year old anyhow. I don't think being a year old qualifies Slink as "very dated".
If you're missing Linux 2.2, you can upgrade your slink to it easily. Just remember to look out for trouble. If you want Gnome, there are unofficial updates (with this caveat). There are also other unofficial updates listed on the Slink release page and the unofficial apt sources list.
Yes you can. But don't do it unless you can stand total system failure. There are no guarantees if you use unstable. That said, I've never personally experienced a total system breakdown due to a bug in unstable, although I've missed a couple with luck.
Ouch. Ignore the earlier post...
Yes, and ... ?
You should understand that installing packages not created for your distribution can be problemous, regardless of what package format is used. That said, Alien can convert between many packaging formats, including deb's and rpm's.
That's an illusion. The differences between package formats are mostly trivial nowadays - a correct translation between rpm's and deb's is possible and afaik alien does that. The big problems are not because of package formats, but because of different policies between distributions. Those things cannot be automatically translated between distributions, and a common package format will not fix that.
I mean I did get the mail.
a) Yes b) No c) No d) Perhaps e) Yes.
According to you. Spam is unsolicited *advertising*, by my definition.
My definition is based on what Usenet cancellers use. There, content is never part of the question. All that matters is the BI of the posting in question (ie the amount of multiposting and crossposting).
I just sent a mail to 10 people I know at university, and I didn't ask them first.
People expect to get mail from people they know personally. That would make your mail solicited, depending on what the mail was all about. (No, content still does not enter the definition. We usually just accept only certain kinds of mail as accepted behaviour from acquaintances.)
This also applies to the mail to Slashdot posters you mentioned. One expects to get comments on one's public words.
If I were to suck a list of Linux kernel developers and mail them all saying `here, have a free Quad PII Xeon box, to help with your development work', would that be spam?
If you mail them all the same form letter, then yes, you'd be spamming.
No, I wouldn't have. The information they would have needed is publically available from my home page and is also evident from the email address I use most of the time.
Do you consider a mass email which reaches people who are not entitled to take advantage on this offer targetted? I don't.
Content does not define what's spam.
How about if I was just telling you about the new Debian release?
Content does not define what's spam.
Or what the weather was like where I live?
Content does not define what's spam.
Where do you draw the line?
If it was sent to a list of people who did not solicit the mail, it is spam. No exceptions.
People abuse the word spam.
They do indeed.
I define spam as unsolicited mass email. It was certainly unsolicited, and I don't think anyone would argue that it wasn't mass mailed.
Unless they sent you like 5 emails I don't see why you're whining.
I get over 10 spam messages in a week. Usually I get only one copy of each, but later it will turn out I was not the sole victim. In this case, the message rang all my spam bells and whistles, if we disregard the sender. And really, the sender should not matter.
Are people saying this is not spam because they don't believe RH would spam?
Spam is not defined by content or by like or dislike. Spam is unsolicited mass email, and that's what this was.
I wish *I* had got the letter!
I did get it. I was not impressed - such a respectable organisation spamming, ouch!
It may be a great offer. I don't comment on that. However, content does not define what's spam. Spam is an unsolicited mass mail. And that's what this was.
I would have thought RH knew better. :-(