So pray explain why they pushed a timezone update for the
US changes earlier in the year?
It's not that the updates aren't going to be made, it's just that
they're made via point releases, not security updates because they
aren't a security bug.
If you don't want to wait for a point release, the packages have
been made available already via volatile and the backports area. It's
trivial to add these to your sources.list and install the updated
package.
the reputation of Debian is being ruined by the
ineptitude and down right stupidity of the management.
You seem to not understand how Debian actually works. The
management of Debian, such as it is, are the actual
developers; the people who actually sit down and do the work. If you
don't like the decisions that they make, you have two choices: jump in
and help out or choose to use something different. The former will
enable you to make decisions in the areas you work in, the latter
means hoping that someone else is going to make decisions that you
agree with. Choose whichever you prefer; presuming to dictate to those
who actually are doing the work isn't one of those choices.
he argues that the needs of the consumers so completely outweigh the
rights of the producers that the producers of goods have no rights at
all. The central thrust of his philosophy is that ownership is bad.
The central thrust of the Free Software philosophy in general is
that the inability to modify and share software and hardware is bad.
To avoid this, instead of exchanging money for software, we exchange
the promise of continued ability to modify for software. While it may
seem like socialism to someone not familiar to zero-cost goods because
of the lack of money exchanged per-copy, the renumeration that
classical capitalists would recognize is still there, though in a
different form.
Furthermore, there appears to be a misconception that producers
somehow lose their rights when they license their works under FOSS
terms. The rights of producers and their maintenance is the very thing
that enables FOSS to work, and the very thing that the GNU GPL and the
SFLC seeks to protect. Without those rights the GNU GPL would be
little more than the MIT license, and copyleft would not exist.
Why would RMS, or anyone else, bellyache, when you are
not forced to use Linux, or some other software you don't agree with?
Why whine about it, why not just go write an ideologically correct
clone?
What do you think HURD is? (Or at least, meant to be)?
You seem to be operating under the misapprehension that RMS does
not write code which conforms to his ideology. He does so, in addition
to trying to convince others to write code.
you are [...] sometimes forced to use the GPL, when you use a library licensed under it
How can you be forced to use a library as a developer?
As a developer you make a choice to use the library because
you have no desire to reimplement things that the library does. It has
little difference from using code from an existing project, with the
caveat that the compartmentalization is enforced.
That works real well when the incoming e-mail is a
complaint to sexual harassment anonymous hot line and the sender
thinks the e-mail went through, but we silently dropped it due to a
mistake on the spelling.
If the incomming e-mail is actually an anonymous complaint then
there's no way to actually notify the sender in any event, is there?
The best case would be the receiving MTA rejecting it immediately
because it was mispelled, but if it doesn't, how do you expect it to
talk to the original sender anyway?
(If you meant to talk about an anonymous remailer, then such a
thing should be bidirectional, and should be doing recipient callouts
for mail that it anonymizes as it relays.)
I hate sending and e-mail and having no idea if it ever
went through or not.
That's why you determine if the mail is going to go through at
submission time. If you are unable to do that, then you can't send
bounces back to untrusted third parties, because you've no clue if
they're actually a party to the communication.
That's a great way to determine VALID accounts to spam
If someone is going to pull off a dictionary attack against the SMTP
server, then you just discard connections to them after a specific
number of invalid users.
Almost all mainstream MUAs support this sort of thing now.
At the end of the day, if you actually accept the message for delivery and later reject it, you should do so silently.
And involves a single, or at most, a handful of specimens.
Whereas GM food involves millions of specimens and can be all over the
globe in one generation.
There's no intrisic difference in the method used to propogate
hybrids of pre-existing stock and hybrids of pre-existing stock which
have had exogenous genes inserted. You can just as easily spread a new
hybrid that isn't "genetically modified" as you can one that is.
Everybody who buys a "class notes" book from the bookstore
should write down the publisher of every work copied in the books, and
confirm that the school indeed obtained permission from the publisher
to make the copies, as well as noting how many people are in the class
to see how many copies were made.
At least at my university, the need
to obtain permission and license the copyrighted works appropriately
is one of the reasons why course readers can be so unbelievably
expensive. [I've seen 200 page readers which cost $40.00, purely
because of the copyrighted content contained within them. (They're
found sitting next to some of the $8.00 readers of equivalent length
which contains stuff written by the instructors of the course.)]
We believe that having to rewrite code that is already available, for any reason (Apart from "I can do this better", of course), is a criminal waste of resources.
It's odd that you would bring this up in defense of BSD/Expat/MIT vs copyleft, because this is almost exactly the same reasoning behind the Free Software movement: the inability to modify software that is not freely available in source code format leads to us rewriting it. Having done so, we license the resultant works so that we won't have to do so again.
At the end of the day, though, most of us wouldn't care what licenser something is released under so long as we can modify it and combine it with other free works; the unfortunate nature of closed source software is the only reason that the GPL exists... if everyone gave away source code, we would never had left the halcyon days of the dawn of computing.
The problem is that Debian doesn't more or less automatically read these bug reports. The mentality is that "if it's not reported to debian, it's not a bug". This eases the burden of being a package maintainer, but it certainly doesn't help Debian or the users.
No, it's the case that if it's not reported to Debian, it's not a bug that we're aware of and can otherwise deal with. Before being so eager to point fingers at other volunteers, point the finger at yourself, ask and answer: "Why didn't I report this bug?" "What can I do to improve the situation?"
Ideally the package maintainers track upstream bugs closely and can do this, but for large packages it's well beyond the ability of volunteers to do easily; even Linus misses reported bugs, and he tracks the kernel full time. The Developers who do this work for Debian don't only work on the kernel.
What is needed, is cooperation of bug-reporting cross-distro, at least for bugs that are not distro-specific. Do we really need dozens of bug-reports for the same bug?
At least in Debian, we need the bugs reported there as well, because we have to know what versions of Debian packages are affected. We have various methods of connecting the Debian bug report to the upstream bug reports, but first someone must notice that the bug affects upstream and also affects the Debian package. Since no one noticed it, nothing happened.
This is a known and documented issue but cannot be found in debian's bug tracking system. This issue is not unique to Debian but it should not have passed through the release engineering for the new stable release.
The reason why it slipped through the release engineering for the new stable release is quite simply because no one reported it as a bug.
If someone had reported it, it would have been dealt with and otherwise resolved. Indeed, it may still be resolved in a point release, but it definetly won't be unless you (or someone like you) who experiences the bug files a bug in the bug tracking system (using reportbug or your MUA). Since (as of a few days ago) no one has filed such a bug related in anyway to MULTIPATH_CACHED, it has not been fixed.
Considering the sheer number of people who (supposedly) use testing, none of whom apparently found the bug and/or bothered to report it, it was just not a popular feature to have been tested properly. Like it or not, a critical part of Debian's QA are the users who are using the testing and unstable distributions and reporting bugs. If they don't find it, no one will. (In case you haven't figured it out yet, there's nothing magical about being a Debian Developer in this regard; we're users too, and do the same type of testing.)
If you use aptitude, you'll find that the following works better:
# on old machine
aptitude search -F '%100p' '~i!~M' > package_list;
# on new machine
xargs aptitude --schedule-only install
This even works for different architectures with a little meddling with the package_list.
To set up home directories (I keep mine in subversion) I just run a single script new_home_directory which checks out the base stuff and configures all of the applications I actually use the way I like them.
The last time I did this it took about 10 minutes of actual work, and the remainder was waiting for packages to download.
While I agree that our documentation does need work, in this case searching for Circumvent debian dependency checking finds equivs right off, and the Debian Reference second. People like you who have run into problems like this and haven't been able to find the documentation should think about what Debian should do to make the documentation more accessible and then file wishlist bugs against the appropriate packages (ideally with patches) so that those of us who already know where the documentation is, and therefore don't ever bother to look for it, know how to make it more accessible.
Debian isn't the best model for usability for non-technical users; glacial release schedules and lack of desktop environment coherence to offset your stability is, well, what you get with Solaris already.
Considering the fact that Ian Murdock isn't currently even a Debian Developer I don't know what Debian is currently doing (or according to you, not doing) has to do with him at all.
We thus performed 494 comparisons: 40 differences (8%) were statistically significant (*p < 0.05); 25 would have been expected under the global null hypothesis of no differences between GMO and control diet effects. Among the 40 significant differences, we retained only the 33 with a relatively ±5% difference to the mean; this most probably also excluded potential incidental differences, if any.
This pretty much sums the paper up; they naively assume that they can multiply 0.05 * 494, getting 24.7, and any "significant" results beyond this mean that they can reject the null hypothesis.
Unfortunately, that's completely incorrect. Because they're publishing in a lower tier journal, this sort of thing can sneak by reviewers who are not statisticians.
What they should have done instead is use FDR, Sidak, or the Bonferroni correction to handle their multiple comparisons and compare their p values to 0.05/494 or approx. 0.0001.
(reposting 'cause I pressed return when I should have clicked "preview")
We thus performed 494 comparisons: 40 differences (8%) were statistically significant (*p
This pretty much sums the paper up; they naively assume that they can multiply 0.05 * 494, getting 24.7, and any "significant" results beyond this mean that they can reject the null hypothesis.
Unfortunately, that's completely incorrect. Because they're publishing in a lower tier journal, this sort of thing can sneak by reviewers who are not statisticians.
What they should have done instead is use FDR, Sidak, or the Bonferroni correction to handle their multiple comparisons and compare their p values to 0.05/494 or approx. 0.0001.
The point is that if Linux has a problem that Windows shares, the Linux community will never fix it because from the Linux community's point of view, it's only a problem in Linux if it's *worse* than in Windows. Therefore, Linux can never possibly be of higher quality than Windows.
You assume that the people who are actually doing work actually care how windows does things, or suddenly are going to stop working on something just because it "got as good as windows" even though it doesn't yet fulfill their needs.
A more accurate complaint would be that the developer community doesn't have the same set of problems using the software that they (or other people) have developed that you do. The solution to that is to jump in, contribute, and fix the software so that it works in the way that you and other users like you find efficient. That the community hasn't done this is not the community's fault; it's merely that the community does not find it interesting to work on at all.
And like I said in my earlier post, decades of studies have shown that mice are a very accurate representation of humans, when it comes to testing chemicals. The organs are proportioned almost exactly the same, and comparable responses to humans have been observed again and again and again. Doubt it if you wish. The fact remains that if something is harmful to mice, we can be sure that a relative proportion of that chemical is harmful to humans.
Having worked personally with mouse and rat models of many human disorders, there are many instances of cases where things have been found to be harmful to mice and have no effect upon humans and vice versa. An effect upon a mouse model or the lack thereof does not necessarily mean that there will be a corresponding effect upon humans. The immune systems of mice are different from those of humans, as well as the fine details of their development, the cancers that they are susceptible too, and a whole host of other not insignificant differences.
That's not to say that we shouldn't investigate the claims of this data or ignore mice models entirely; but merely to point out that jumping to conclusions based on a single unpublished (and therefore unreviewed and unreplicated) study is foolhardy. Do further studies, and examine what the actual results are. (Which, as near as I can tell, are what they are planning on doing in the UK.)
Debian, in my experience, just leaves the old build in place, leaving you stranded if you need a new feature.
If you need a new feature from a new version, you have to upgrade to the new version of the package. Backports with the new versions are made available against the stable distribution all the time, often by the actual maintainer of the package. However, you do this only once when you actually need the new package, and then you track the security updates for that package.
If it's only one or two things, sure, Debian would be fine. Usually it's much more than that, which throws Debian out of consideration.
If you're backporting more than one or two things, you probably should be rethinking what you're actually running on your server. Running non-trivial changes to software in production that hasn't been tested for at least a few months is insane. But in the end, it's your system, your time, and your problem. Use what you want. I'm just telling you what I actually do and why I do it.
Run a mix of unstable/stable. What's the point in a supposedly "stable" distro then?
Run "stable" and live with the old software.
What almost everyone who really uses Debian in production does is run the stable software for everything that can be gotten away with running the stable version, and specific backports of sandbox tested versions from unstable. (In many cases backports.org or other publicly available repositories have actually done the hard work for you.)
In this way you avoid having changes that you haven't specifically asked for sinking your production machines, and can easily keep up with security updates. When you're dealing with whole fleets of systems, this becomes a not inconsiderable advantage.
hiring some full-time workers seems to have had precisely the opposite effective of the intended.
not workers... managers.
They're managers only in the sense that they have some authority over which packages can and cannot transition into testing and therefore manage the release. In reality, though, almost everything Steve and Andreas are doing is programming and fixing bugs in packages which otherwise would not have been fixed.
Their happiness is no longer within their own control - it is now controlled by a fickle population, one beyond their ability to understand.
This is a falicy whose roots are far more depressing than people who are depressed because they don't have perfect skin or c cup breasts. You yourself are entirely responsible for whether you decide to be happy or not. You choose to allow others to affect your sense of self; it's not something that they can force upon you.
Finally, it's worth noting that not all pornography or depictions post-pubescent female breasts are depictions of super models; pornography (and art, for that mater) depicts people with every proclivity, with every physical appearance: from the rubenesque to the pibald to the tatoo clad; there's pornography and art about it.
But what is a belief is that science is the only form
of truth.
This belief is incorrect too, although some people may hold it. Science has nothing
to do with truth. Science is about disproving falsehoods. All
scientists do every single day is try to disprove their (or other's)
latest theories.
Slashdot Mirror
It's not that the updates aren't going to be made, it's just that they're made via point releases, not security updates because they aren't a security bug.
If you don't want to wait for a point release, the packages have been made available already via volatile and the backports area. It's trivial to add these to your sources.list and install the updated package.
You seem to not understand how Debian actually works. The management of Debian, such as it is, are the actual developers; the people who actually sit down and do the work. If you don't like the decisions that they make, you have two choices: jump in and help out or choose to use something different. The former will enable you to make decisions in the areas you work in, the latter means hoping that someone else is going to make decisions that you agree with. Choose whichever you prefer; presuming to dictate to those who actually are doing the work isn't one of those choices.
The central thrust of the Free Software philosophy in general is that the inability to modify and share software and hardware is bad. To avoid this, instead of exchanging money for software, we exchange the promise of continued ability to modify for software. While it may seem like socialism to someone not familiar to zero-cost goods because of the lack of money exchanged per-copy, the renumeration that classical capitalists would recognize is still there, though in a different form.
Furthermore, there appears to be a misconception that producers somehow lose their rights when they license their works under FOSS terms. The rights of producers and their maintenance is the very thing that enables FOSS to work, and the very thing that the GNU GPL and the SFLC seeks to protect. Without those rights the GNU GPL would be little more than the MIT license, and copyleft would not exist.
What do you think HURD is? (Or at least, meant to be)?
You seem to be operating under the misapprehension that RMS does not write code which conforms to his ideology. He does so, in addition to trying to convince others to write code.
How can you be forced to use a library as a developer?
As a developer you make a choice to use the library because you have no desire to reimplement things that the library does. It has little difference from using code from an existing project, with the caveat that the compartmentalization is enforced.
If the incomming e-mail is actually an anonymous complaint then there's no way to actually notify the sender in any event, is there? The best case would be the receiving MTA rejecting it immediately because it was mispelled, but if it doesn't, how do you expect it to talk to the original sender anyway?
(If you meant to talk about an anonymous remailer, then such a thing should be bidirectional, and should be doing recipient callouts for mail that it anonymizes as it relays.)
That's why you determine if the mail is going to go through at submission time. If you are unable to do that, then you can't send bounces back to untrusted third parties, because you've no clue if they're actually a party to the communication.
If someone is going to pull off a dictionary attack against the SMTP server, then you just discard connections to them after a specific number of invalid users.
Almost all mainstream MUAs support this sort of thing now.
At the end of the day, if you actually accept the message for delivery and later reject it, you should do so silently.
There's no intrisic difference in the method used to propogate hybrids of pre-existing stock and hybrids of pre-existing stock which have had exogenous genes inserted. You can just as easily spread a new hybrid that isn't "genetically modified" as you can one that is.
It's odd that you would bring this up in defense of BSD/Expat/MIT vs copyleft, because this is almost exactly the same reasoning behind the Free Software movement: the inability to modify software that is not freely available in source code format leads to us rewriting it. Having done so, we license the resultant works so that we won't have to do so again.
At the end of the day, though, most of us wouldn't care what licenser something is released under so long as we can modify it and combine it with other free works; the unfortunate nature of closed source software is the only reason that the GPL exists... if everyone gave away source code, we would never had left the halcyon days of the dawn of computing.
No, it's the case that if it's not reported to Debian, it's not a bug that we're aware of and can otherwise deal with. Before being so eager to point fingers at other volunteers, point the finger at yourself, ask and answer: "Why didn't I report this bug?" "What can I do to improve the situation?"
Ideally the package maintainers track upstream bugs closely and can do this, but for large packages it's well beyond the ability of volunteers to do easily; even Linus misses reported bugs, and he tracks the kernel full time. The Developers who do this work for Debian don't only work on the kernel.
At least in Debian, we need the bugs reported there as well, because we have to know what versions of Debian packages are affected. We have various methods of connecting the Debian bug report to the upstream bug reports, but first someone must notice that the bug affects upstream and also affects the Debian package. Since no one noticed it, nothing happened.
The reason why it slipped through the release engineering for the new stable release is quite simply because no one reported it as a bug.
If someone had reported it, it would have been dealt with and otherwise resolved. Indeed, it may still be resolved in a point release, but it definetly won't be unless you (or someone like you) who experiences the bug files a bug in the bug tracking system (using reportbug or your MUA). Since (as of a few days ago) no one has filed such a bug related in anyway to MULTIPATH_CACHED, it has not been fixed.
Considering the sheer number of people who (supposedly) use testing, none of whom apparently found the bug and/or bothered to report it, it was just not a popular feature to have been tested properly. Like it or not, a critical part of Debian's QA are the users who are using the testing and unstable distributions and reporting bugs. If they don't find it, no one will. (In case you haven't figured it out yet, there's nothing magical about being a Debian Developer in this regard; we're users too, and do the same type of testing.)
If you use aptitude, you'll find that the following works better:
# on old machineaptitude search -F '%100p' '~i!~M' > package_list;
# on new machine
xargs aptitude --schedule-only install
This even works for different architectures with a little meddling with the package_list.
To set up home directories (I keep mine in subversion) I just run a single script new_home_directory which checks out the base stuff and configures all of the applications I actually use the way I like them.
The last time I did this it took about 10 minutes of actual work, and the remainder was waiting for packages to download.
This pretty much sums the paper up; they naively assume that they can multiply 0.05 * 494, getting 24.7, and any "significant" results beyond this mean that they can reject the null hypothesis.
Unfortunately, that's completely incorrect. Because they're publishing in a lower tier journal, this sort of thing can sneak by reviewers who are not statisticians.
What they should have done instead is use FDR, Sidak, or the Bonferroni correction to handle their multiple comparisons and compare their p values to 0.05/494 or approx. 0.0001.
(reposting 'cause I pressed return when I should have clicked "preview")
You assume that the people who are actually doing work actually care how windows does things, or suddenly are going to stop working on something just because it "got as good as windows" even though it doesn't yet fulfill their needs.
A more accurate complaint would be that the developer community doesn't have the same set of problems using the software that they (or other people) have developed that you do. The solution to that is to jump in, contribute, and fix the software so that it works in the way that you and other users like you find efficient. That the community hasn't done this is not the community's fault; it's merely that the community does not find it interesting to work on at all.
Having worked personally with mouse and rat models of many human disorders, there are many instances of cases where things have been found to be harmful to mice and have no effect upon humans and vice versa. An effect upon a mouse model or the lack thereof does not necessarily mean that there will be a corresponding effect upon humans. The immune systems of mice are different from those of humans, as well as the fine details of their development, the cancers that they are susceptible too, and a whole host of other not insignificant differences.
That's not to say that we shouldn't investigate the claims of this data or ignore mice models entirely; but merely to point out that jumping to conclusions based on a single unpublished (and therefore unreviewed and unreplicated) study is foolhardy. Do further studies, and examine what the actual results are. (Which, as near as I can tell, are what they are planning on doing in the UK.)
If you need a new feature from a new version, you have to upgrade to the new version of the package. Backports with the new versions are made available against the stable distribution all the time, often by the actual maintainer of the package. However, you do this only once when you actually need the new package, and then you track the security updates for that package.
If you're backporting more than one or two things, you probably should be rethinking what you're actually running on your server. Running non-trivial changes to software in production that hasn't been tested for at least a few months is insane. But in the end, it's your system, your time, and your problem. Use what you want. I'm just telling you what I actually do and why I do it.
What almost everyone who really uses Debian in production does is run the stable software for everything that can be gotten away with running the stable version, and specific backports of sandbox tested versions from unstable. (In many cases backports.org or other publicly available repositories have actually done the hard work for you.)
In this way you avoid having changes that you haven't specifically asked for sinking your production machines, and can easily keep up with security updates. When you're dealing with whole fleets of systems, this becomes a not inconsiderable advantage.
This is a falicy whose roots are far more depressing than people who are depressed because they don't have perfect skin or c cup breasts. You yourself are entirely responsible for whether you decide to be happy or not. You choose to allow others to affect your sense of self; it's not something that they can force upon you.
Finally, it's worth noting that not all pornography or depictions post-pubescent female breasts are depictions of super models; pornography (and art, for that mater) depicts people with every proclivity, with every physical appearance: from the rubenesque to the pibald to the tatoo clad; there's pornography and art about it.