but clearly, that $1,100 system is "simply too expensive" for the average user.
Hm. Here in Europe the eMac goes for EUR 1199,00[1] (that's about USD 1480) and I can buy a PC + Monitor + Software[2] with about the same specs for about 2/3 of the price here. If I don't go for the specs but consider what most people I know buy for their needs, most go at about EUR 500, maybe EUR 600 (excluding the monitor they still have). Or the other way around, for EUR 1200 you get quite a high end machine with 19" Monitor, Radeon 9800, 512MB, 160GB, almost everything.
If the proportion is much different in the US (i.e. that not all computers, but only Macs are cheaper than in Europe), I take back what I said. Well, at least with regard to the rest of the world. For Europeans the saying still goes that you get 2 PCs for the price of 1 Mac.;) Or in other words, the cost of 1 eMac is much more than the average European is willing to pay for a computer.
[1] On this page click on the eMac picture in the middle (sorry, but a direct link would contain a session id that will expire).
[2] Software with the same purpose, I mean. I don't argue that Mac software is usually nicer, and not to speak of the iDVD discussion itself.
Unless you actually want to get work done [...], and are looking at packages that are at least the cost of eMac + DVD Studio Pro. Which you would be, if you wanted something of DVD Studio's quality on Windows.
I am not sure if I understand you correctly, but considering the cost you suggest, do you imply that there is no usuable DVD authoring software outside of the professional market? [1]
authoring under Linux is virtually a lost cause unless you have a lot of [...] discs to waste learning how to use
Why are DVD-/+RW not usuable for tests during DVD authoring?
[1] And yes, in this context I count Macs to the professionial market, for they are usually used for professional or fan reasons only. For the average user they are simply too expensive.
Who said that I was talking about this vulnerability . All I said was that it is impossible to do any proper testing of a patch if it is realeased minutes/hours/days after it is discovered.
Two things:
1. Why aren't "days" enough to do proper testing? I agree that minutes aren't enough. And neither are hours usually, but there cases where I would argue that, depending on the kind of change, the testsuites and the QA requirements.
2. In OSS, most times a patch isn't released in the conventional meaning of the word ("released", I mean). The patch is made available (often when it is checked into CVS). What will be released is a new tar ball or announcement, after the QA process. Me, I consider it released, when my favored distribution has an updated package for it on its security site. And contrary to some Microsoft fixes, I never had a Mandrake or Debian security update break my installation - so the QA process seems to work.
It's simple to mix up those, because in closed source you don't see the step where a patch/fix is internally distributed from devs to QA. In OSS you do, but that doesn't imply an official release.
But on the other side, the difference in availibility matters. Having access to the patch before a security update is officially released, gives me a choice. If it's criticial enough for my infrastructure, I can dig into it and do my own QA and deploy it even before an official announcement is available.
Heck, if it's important enough, I can start even before a patch is available, because I have the source. And if you follow security lists, you will notice that it is no exception that a so created patch will find its way into the official release (in other words: the time to release is cut short, because a suggested fix is already available the moment the core team starts looking at the problem).
(i.e. it doesn't matter how the police found the evidence, as long as it is found
Oh yeah, that's fuckin great. Do they torture confessions out of people, too?
If so, so what? The suspect can argue in court that he just confessed, because he was intimidated.[1] And second, the officer who did this, will find himself in court[2] and even if he manages to avoid jail, probably won't stay in his position for much longer. Do you really think someone willing to take that risk and willing (for whatever reason) to turture someone else will be stopped by the question whether this will result in usable evidence?
In other words, although they theoretically can do something illegal in order to get evidence (and may try to use it afterwards), practically it isn't known to happen.[3] Officers have better things to do than bringing legal (and disciplinary) action upon themselves.
And in order to show that it may happen[4], there is currently a case in proceedings, where a suspect would confess to have abducted a 11-year old boy, but would lie about the whereabouts of the child. Believing that the child was still alive, the second highest ranked police officer instructed the officers to threaten the kidnapper to be hurt (by a martial artist) until he would tell. Finally, the suspect told, but the child was only found dead. Next thing, the high ranked officer reported his behaviour himself to the state attorney (he had written a protocol of what happened).
Today, the kidnapper has already been found guilty (the corpse and so being valid evidence) and has to serve a lifelong sentence.
In other words: Yes, the officer did something illegal and he will face the consequences. He did it hoping to find the child before it has to die. Most people sympathize with him, but think he will (and should) be sentenced anyhow, though as midly as law allows. Initially he was charged with a "forced confession"[2], but that was dropped (didn't read why yet), but several other charges still stand: coercion, abuse of authority, etc.
And to come back to my point above: Do you think this officer had stopped and not tried to save the child, even if this would have meant the illegally retrieved evidence couldn't be used?
Luckily, most times, two wrongs don't make a right here.
[1] Unless, of course, they find further proof, like e.g. the corpse at the place where the criminal described.
[2] To force a confession out of someone is a felony which has a minimum sentence of one year of jail.
[3] And no, that doesn't mean it happens and just nobody talks about it. That may happen once or twice but not regularly. Somewhen somebody would talk.
[4] Just to make that clear: that is the first case of that kind in the legal history of Germany (i.e. where an officer does this and then reports himself)
if linux want's to go mainstream and come out of the server room linus will have to compromise.
"If Linux wants" again. Linux doesn't want anything than being useful to those who want to run Linux (see Linus' interviews...). The (grand-)parent poster was right: If you want to run Linux, there is usually no problem to find hardware that is supported without the need for proprietary drivers (the exceptions being GFX cards and hardware niche uses).
Yes, it's a problem if you want to migrate your existing hardware. But that hardware will stay usable only for so long. After that, if you really do want to run Linux, you know to check the hardware compatibility before you buy the replacement.
"Must have experience with a write-only scripting language" which we all know refers to Perl:P
Spoken like someone who has never programed Bourne Shell, yet alone C shell or JCL.
Hm. I am mainly a tcsh user and must say that I never had any particular problems reading bash scripts from others (including but not limited to system startup files under Solaris, FreeBSD or Linux) while I still have regular problems with Perl code others write.
So, bash and csh scripts may be harder to read and write in general, but IMHO there is not that gap in difficulty between writing and reading as there is with Perl.
hey there cat... we argued before... hope it doesn't happen again...:):-)
many programs for "noraml" users _are_ limited by tight loops. look to the wikipedia for info on big-o noataion.
think about a VPN or router vendor that needs to route traffic for users. for each user, we must route each packet O(n).
now think of a firewall vendor. we must route each packet after checking it against this set of deny or allow rules. this is a common case.. but represents an O(n^2).
Technically, that's O(n), too. If you double the number of packets to filter, you need twice the time, not four times. Same with the number of rules. So have it O(n) and O(m) (so to speak), depending on what you consider as primary input, but not O(n^2).
now O(n^2) can be "ok" for small n... and perhaps the "bugs" you talk about are poorly designed rule lookups. Now imagine a large ISP that uses a firewall to block virus' from being sent outbound. this is still O(n^2), but the n can be huge, and that loop is executed for each packet... also a huge number. hard to optimize.
That's why I spoke of programs for normal users, i.e. application programming. Yes, there are plenty of programs that are limited by a tight loop. But in my experience those are mostly found in special software (that has limited purposes), like, for example, routers.
it usually takes a shift in philiosophy to break out of this kind of case. say, come up with a way that we don't have to check every deny/allow rule for each connection and you have beat it.
Agreed.
Just to make myself clear: I don't deny that there is plenty of room for optimization in lots of programs. But the stuff your average developer writes (i.e. user applications, web pages, etc.) makes only a small percentage of those programs (aka "when did you last write firewall or router software?"). So my point was, that the results of benchmarking tight loops is not too relevant with regard to the kind of software most of us write.
Okay, you are either ignorant or trolling. Probably the latter. I will answer anyhow, because for others it might be not as obvious.
you: that is a 2.6-test kernel... not the same thing as the 2.6 kernel itself.
me: You are provably wrong. Where are you taking your information from?
you: no.. really... 2.6 is not the same as 2.6-test. prove me wrong. please.
Yeah, of course, you never happen to think - even considering the rest of my comment - that I was referring to the other part of the sentence, namely that [you claim that the kernel that Cooker contains since december] is a 2.6-test kernel, did you? To make it clear even for you: Yes, I completely agree, there is a diferrence between 2.6-testx and 2.6.x (but not as big as you like it to make), but that was never the point I argued.
original poster and me: provides Linux 2.6 as kernel default since december
you: That is the line I was talking about. Using the parent's citation at cooker snapshot, I can show that indeed, he was talking about 2.6 being there when his citation said 2.6-test.
From that page:
- content: 1 ISO image with Linux 2.6.0-test1, XFree 4.4pre, Gcc 3.3.2 and KDE 3.2pre. [that belongs to: Cooker Snapshot 20031217]
Also on that page (for Cooker Snapshot 20031231)
content: 2 ISO images with Linux 2.6.0, kde 3.1.94 or XFree86 4.3.99
Ah, I see, 2003-12-31 is not part of december nowadays.[1]:-)
Ok, more seriously, there is a difference between Cooker and Cooker snapshots. I made that as clear as possible in my parent post, but you choose to ignore it. The orignal poster said: For your information, Cooker provides Linux 2.6 as kernel default since december. ISO snapshots are available here for download, with also a preview of the new KDE.
He doesn't say anything about when 2.6 was available in ISO snapshots. He says, that 2.6 was available in Cooker since december (for which I provided a reference which showed that it was mid-december). And that additionally, snapshot are available somewhere. Just because you misread him and misquote him now, doesn't make you right. I even went previously with the point that you might referring to the 2003-12-17 snapshot, but you choose to ignore that, too, in your reply.
But let's presume your point of view for a moment. The page you cite implies the 2.6.0 kernel went into Cooker between 2003-12-17 (which had a 2.6-test) and 2003-12-31 (which had 2.6.0), a time range which includes the 2003-12-18 (when 2.6.0 went into Cooker), a day which most of us would call part of mid-december.
If you can show me, where the parent poster or me said that Cooker snapshots had 2.6 since december, I will happily apologize. And even if he had referred to a snapshot, he could have meant the one of 2003-12-31 and would be correct in a sense of the meaning.
you: Again, for the hard of hearing.... 2.6-test is not the same as the full 2.6 kernel.
Yeah, yeah, we heard you. And maybe you should clean your ears, because nobody claimed the contrary.
you: Try not to be such a condescending prick when you are wrong, or confused about the topic.
Oh, I am not confused at all. And I am not wrong either. A prick, maybe.:-) Ah, and may I ask you to hold you to your own standards and at least consider that you misread him?
[1] Yeah, yeah, I know that it was released only a day later. See the smiley there?
I'd venture it's because the Slashdot community holds their villians to a higher standard than their heroes.
Or maybe because he doesn't makes Microsoft and MS Windows and its license bad with every breath he takes. In other words: he may be critic of them, but he doesn't spread FUD. Most times he simply doesn't care and openly admits that.
If Linus had bad-mouthed Microsoft with every speech, I dare say he would get the almost same backslash as Mr. Gates would get.
For your information, Cooker provides Linux 2.6 as kernel default since december. ISO snapshots are available here [mandrakelinux.com] for download, with also a preview of the new KDE.
that is a 2.6-test kernel... not the same thing as the 2.6 kernel itself.
You are provably wrong. Where are you taking your information from?
Cooker had the final 2.6.0 since Dec, 18th [1] and is currently available with 2.6.1 by contributers. Maybe you refer to the first snapshot ISOs, which were made mid-december and so couldn't possibly include anything than a 2.6-test kernel (2.6.0 was released after the snapshots were taken, and so the 2.6-test kernels were all that was available at that time).
But that snapshot is long outdated. The latest was released on the 1st and included a 2.6.0 kernel. The next Cooker snapshot is due any day now should even more recent kernel packages. Not sure, if 2.6.1 will make it (regardless, an up-to-date 2.6.1 kernel, heavily based on the -mm tree, is available in contribs already [2]).
Anyhow, the point of the original poster was that Mandrake Linux 10.0 will ship with a reasonably recent 2.6 kernel as option. AFAIK, the aim is to let it be the default option, with 2.4 as alternative, but that will be determined by how stable it is at the time of the freeze and if all the common hardware is supported good enough. (I am too lazy too dig up a link to the cooker mailing list archive... if you don't believe me after I showed references for all my other claims, go looking yourself;).
[1] From the rpm changelog... You can get the rpm here (currently it's 2.6.0.1mdk-1-1mdk and view the log with
rpm -qip --changelog filename
* Thu Dec 18 2003 Nicolas Planel <xxx@mandrakesoft.com> 2.6.0-1mdk
[2] And before anyone screams about not wanting to run a kernel by contributers: Nobody says you must. But experience shows these contributers know what they do and that most patches get integrated in the official mdk-kernel later (note that the contributers mainly integrate existing patches by "official" kernel developers and don't write their own). It's kind of a testbed like the -mm tree is for the "official" Linus kernel, currently.
My point is that there will always be problems with getting any machine working properly after a fresh install - Linux, XP, BSD. The real key to desktop acceptance by Joe Camera/Scanner/Dialup is for manufacturers to ship boxes with Linux loaded and a generous set of drivers/modules installed - they're out there. All it takes is for one major computer maker to do the quality testing of everything for their hardware.
But, don't you see, most people WILL NEVER INSTALL AN OPERATING SYSTEM. Windows came with their computer. It works out of the box. All of the hardware is configured. There is no repartitioning. No hacking your X configuration.
Which part of the real key to desktop acceptance [...] is for manufacturers to ship boxes with Linux loaded didn't you understand? He said exactly what you repeated: That the main reason for a better user experience is that Windows comes preloaded (and once computer makers start the preload Linux, that advantage is gone).
If you've ever done much optimization work, you'd realize that most programs are speed limited by a few small, often simple loops that just happen to execute an expensive operation or just plain run a lot. So while micro-benchmarks are never perfect, these ones aren't too bad at reflecting what actually happens in real life programs.
I wonder which kinds of programs you are writing (that is not meant as a rhetoric, but a serious question).
What you describe doesn't reflect my experience (except for the simulations in physics I've done). Any program for "normal users" that I profiled hadn't such obvious points for improvement (except if the algorithm was buggy to begin with or for inputs that were corner cases - like CGI's that produce 30MB web pages which no normal user would want wait for that).
Last but not least, I think their packagers have 2 left hands. When I was using 9.1 (witch comes with python 2.2) I needed python 2.3 (need tarfile module). I thought "no problem, let's see what urpmi can do". This simple upgrade gives me 105 dependencies!!!!
I am curious what wacky thing you did. I am quite positive that this python 2.3 was not for ML 9.1. They practically never release "new version" updates for a package.
So where was this python 2.3 from? A third party? Then don't complain about Mandrake's packagers. Cooker (pre-9.2) or 9.2? Then you indirectly asked for a dist-upgrade. Be glad it was only 105 packages.
Beware, there are a few spoilers ahead; obviously, most of the Slashdot crowd knows the story in the books, but what will follow should be considered a spoiler, as I am describing Jackson's adaptation of the book.
Hm. That must means that all "funny moderators" have either a rather lame sense of humour (as the parent poster said, it's the second repetition for these movies) or they didn't read the review past the first paragraph.
Well, who I am kidding, this is Slashdot, so it's both.
As I said, "maximum number of pages" already implies no reasonable structure. As soon as you start worrying about structure and/or reasonable content, you won't reach the maximum. So it makes no sense to argue about the kind of links when trying to determine the upper limit.
Any pages (including leaf ones) with only 7 links would rule out most existing hypertext of today.
But I bite: Nonwithstanding the fact that we were talking about the maximum number of pages, which implies that we disregard reasonable structure/layout, I see no problem with the index pages containing (some of) the links in the content.
If you can have at most three clicks... and only seven choices at each point... then your site can hold only 7 ** 3 == 343 pages!
Just for completeness: Your math is wrong.
With 3 clicks you have 4 levels. The first (which you see without clicks), and the three following. The maximum number of pages you can have, given that there are no cross-links is:
level 1: 1 page, links to 7 pages of level 2 level 2: 7 pages, links to 7*7=49 pages of level 3 level 3: 49 pages, links to 49*7=7^3=343 pages of level 4: level 4: 343 pages, no links (3 clicks reached). sum: 400 pages.
So your calculation was only for the 4th level alone.
Another side-note: Since the rule states 7+-2, you are allowed 9 links at most and so the overall maximum is: 1+9+81+729=820 pages.
According to Mandrake's site, they provide Mandrake Packs of Acrobat, Flash, Real, nVidia drivers, and other non-OSS software. Not 100% OSS.
That are the commercial boxes, e.g. the PowerPack edition. Yes, they accomodate people who prefer a commercial package for ease of use (no need to handle nVidia drivers etc. yourself) or other reasons.
The "100% OSS" applies to the Download editition (a comparison).
The latter is the one you can download for free. The former has been made available for download only for MandrakeClub members (silver and higher) and contributors as of ML9.2, and is sold as boxed set, too, of course.
But I doubt that Mandrake itself would use the 100% OSS label. IMHO, it's not really technically correct. They don't require all licenses to be OSI approved. AFAIK, they require the license to allow the software (source and binary) to be (re-)distributed freely on the the download edition. Which basically boils down to: the licenses usually fit into the OSI spirit, but aren't necessarily officially OSI approved.
Though, the analogy doesn't hold. Open source developers don't think/act like predators. If anything, this incident increased the chance that somebody will look for further things that look strange (well, rather "many sombodies").
It even increased the chance that people who never looked at the kernel before, just look now because of this.
Monopoly != popularity. Monopoly is taking market share by force rather than by normal market behavior.
No, monopoly means "exclusive control by one group of the manufacture, or production, or selling of a comodity" whether that monopoly was gained by the popularity of the product or by "force" is irrelevant.
Correct. And just to be clear, the definition you cited makes obvious that Apache[1] isn't a monopoly[1]. Because the ASF has no control. Neither has anyone else. Everyone can go and fork Apache for their own need, if they want to. E.g. if you don't want to switch to Apache 2.0 in the foreseeable future, you are free to start a long-living support branch for 1.3.
The Webster entry makes this even more obvious:
1 : exclusive ownership through legal privilege, command of supply, or concerted action
2 : exclusive possession or control 3 : a commodity controlled by one party
If you think about it, neither 1. nor 2. apply to the ASF, nor 3. to Apache.
[1] Let's ignore for a moment that Apache has not (yet) the market penetration needed to have a monopoly.
Sigh. Why got this modded up? Only because he mentions that previous moderation was unfair? He is trolling!
For anyone who thinks about taking him seriously, just some comments:
He "proofs" his claim that Apache is not the most secure web server mainly by going to show that MacOS is a better operating system than others. (See? If not, think about how his arguments applies for running Apache on MacOS). That leaves only point 4 (the first one, not the one at the place of point 6), the only one talking about another webserver:
4. Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension)...
As has Apache. So what is the point?
File types on Macs are not easily settable by users, expecially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
Without commenting about the correntness of this claim, if the alleged problems are gone now, what do they have to with how secure Apache is today?
Another proof for trolling:
2. No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidian's birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.
Yeah, and that's why Microsoft Windows 98 security is so good. NOT! Really, ask anyone serious in the security community and you get the answer that privilege separation is the way to go.
They might have just made a whole new release and bumped the version number. As it stands now, distributing diffs between 9.2 and a future 9.3 would be extremely difficult. At least bump the revision to 9.2.1 or something. You would think they would know how to do releases by now.
And one would think that you know not to blindly believe anything in a./ story but to read the article, by now.
The only mention of a new 9.2. is in the./ story. The article speaks only of
A new kernel (2.4.22-21mdk) has been released that fixes this problem in the kernel, although the CD-ROM devices are still not up to specification. New CDs and ISOs will be available shortly to correct these problems; they will come with the new kernel.
No mention whether they keep the label 9.2 or not. And news.osdir.com probably doesn't have any more insight, anyhow, because that paragraph is simply a direct letter by letter copy of the one in the official Mandrake errata.
AFAICS, there was no statement about the label in any official place (mandrakeclub, mandrake.com, the mailing lists,...). I don't imply to say that they won't keep the 9.2 label. I just say that there is no way to know yet, what they will see as most practical way to handle the situation.
Because his link points to FreeBSD, so obviously he's trolling against Mandrake and Linux in general.... or something like that, who knows?
Obviously? Obviously? Just because he outs himself as BSD fan, this makes im trolling as soon as he speaks about another OS?
Forget about the FreeBSD link for a moment and you will realize that he asked a valid question that a majority of Mandrake users (and "wanna-be"s) are wondering about. And if you don't have to believe me on this: simply read the Mandrake-specific forums or mailing lists, where this question is all over the place.
We seem to have a communication hole here. I don't see how your answer relates to my rebuttal of your claims. I'll try to clarify...
Compiling? Why? Why not just log into the box and do your compiling there?
Which box, the one with the left or the right part of the mirror of the RAID system? Remember, this was about a network file system configured in a way, that the overlying RAID system would give redundancy by storing the two parts of a mirror configuration on different computers. In other words: no matter on which machine you are logged in, some disk of the RAID is not on the local computer.
But to come back to your question of why not just log into the box and do your compiling there: Because the idea of the network file system was to connect several (8, IIRC) computers in the LAN. If he could do all his work with only 1 computer, he had no reason to have a LAN to begin with. E.g. different OSes. I don't know, if it is a matter for the original poster, but he explicitly said, it was a misc envirement and I would rather not try to cross-compile Windows to Linux or vice versa, if I don't absolutely have to.
As for the floppy example, you should note how good the performance was. He moved a 3.6MB file to it in 32 seconds, that might sound slow to you and me,
I didn't argue the speed of the floppy RAID at all, but the speed of USB.
but 112KB/s, close to the USB maximum throughput.
This was my point. I argued that saying "if you can do RAID over USB..." is bogus, when USB was only good enough, because it was a floppy RAID and as you just said yourself, even then USB barely managed to keep up.
If I'vr decided I want to archive something via my network, I've already decided that the delay is worth it.
But this was not only about archiving, but about replacing the complete local data storage by a network storage (in order to have a global redundancy).
If a net RAID sucks down my data as fast as I can send it, but also gives me error correction, I've done myself a favor by using it.
I completely agree. But I never argued about that point. What I argued was your claim, that one would not notice the speed loss [at least on Windows].
This might not work so well for kernel compiling, but it would be just fine for tar files of images.
Nope. I already anticipated that argument in my previous post and answered it there: "Ah, and if compiling does not fall into the "data storage" category: Well, simply copy that 50MB log file around, and some seconds become minutes (regarding the nobody would notice a "10 MBit" link)." (if you do log files or images doesn't make a big difference, as long as the file size is counted in MB).
Slashdot Mirror
but clearly, that $1,100 system is "simply too expensive" for the average user.
;) Or in other words, the cost of 1 eMac is much more than the average European is willing to pay for a computer.
Hm. Here in Europe the eMac goes for EUR 1199,00[1] (that's about USD 1480) and I can buy a PC + Monitor + Software[2] with about the same specs for about 2/3 of the price here. If I don't go for the specs but consider what most people I know buy for their needs, most go at about EUR 500, maybe EUR 600 (excluding the monitor they still have). Or the other way around, for EUR 1200 you get quite a high end machine with 19" Monitor, Radeon 9800, 512MB, 160GB, almost everything.
If the proportion is much different in the US (i.e. that not all computers, but only Macs are cheaper than in Europe), I take back what I said. Well, at least with regard to the rest of the world. For Europeans the saying still goes that you get 2 PCs for the price of 1 Mac.
[1] On this page click on the eMac picture in the middle (sorry, but a direct link would contain a session id that will expire).
[2] Software with the same purpose, I mean. I don't argue that Mac software is usually nicer, and not to speak of the iDVD discussion itself.
I am not sure if I understand you correctly, but considering the cost you suggest, do you imply that there is no usuable DVD authoring software outside of the professional market? [1]
authoring under Linux is virtually a lost cause unless you have a lot of [...] discs to waste learning how to use
Why are DVD-/+RW not usuable for tests during DVD authoring?
[1] And yes, in this context I count Macs to the professionial market, for they are usually used for professional or fan reasons only. For the average user they are simply too expensive.
Who said that I was talking about this vulnerability . All I said was that it is impossible to do any proper testing of a patch if it is realeased minutes/hours/days after it is discovered.
Two things:
1. Why aren't "days" enough to do proper testing? I agree that minutes aren't enough. And neither are hours usually, but there cases where I would argue that, depending on the kind of change, the testsuites and the QA requirements.
2. In OSS, most times a patch isn't released in the conventional meaning of the word ("released", I mean). The patch is made available (often when it is checked into CVS). What will be released is a new tar ball or announcement, after the QA process. Me, I consider it released, when my favored distribution has an updated package for it on its security site. And contrary to some Microsoft fixes, I never had a Mandrake or Debian security update break my installation - so the QA process seems to work.
It's simple to mix up those, because in closed source you don't see the step where a patch/fix is internally distributed from devs to QA. In OSS you do, but that doesn't imply an official release.
But on the other side, the difference in availibility matters. Having access to the patch before a security update is officially released, gives me a choice. If it's criticial enough for my infrastructure, I can dig into it and do my own QA and deploy it even before an official announcement is available.
Heck, if it's important enough, I can start even before a patch is available, because I have the source. And if you follow security lists, you will notice that it is no exception that a so created patch will find its way into the official release (in other words: the time to release is cut short, because a suggested fix is already available the moment the core team starts looking at the problem).
In other words, although they theoretically can do something illegal in order to get evidence (and may try to use it afterwards), practically it isn't known to happen.[3] Officers have better things to do than bringing legal (and disciplinary) action upon themselves.
And in order to show that it may happen[4], there is currently a case in proceedings, where a suspect would confess to have abducted a 11-year old boy, but would lie about the whereabouts of the child. Believing that the child was still alive, the second highest ranked police officer instructed the officers to threaten the kidnapper to be hurt (by a martial artist) until he would tell. Finally, the suspect told, but the child was only found dead. Next thing, the high ranked officer reported his behaviour himself to the state attorney (he had written a protocol of what happened).
Today, the kidnapper has already been found guilty (the corpse and so being valid evidence) and has to serve a lifelong sentence.
In other words: Yes, the officer did something illegal and he will face the consequences. He did it hoping to find the child before it has to die. Most people sympathize with him, but think he will (and should) be sentenced anyhow, though as midly as law allows. Initially he was charged with a "forced confession"[2], but that was dropped (didn't read why yet), but several other charges still stand: coercion, abuse of authority, etc.
And to come back to my point above: Do you think this officer had stopped and not tried to save the child, even if this would have meant the illegally retrieved evidence couldn't be used?
Luckily, most times, two wrongs don't make a right here.
[1] Unless, of course, they find further proof, like e.g. the corpse at the place where the criminal described.
[2] To force a confession out of someone is a felony which has a minimum sentence of one year of jail.
[3] And no, that doesn't mean it happens and just nobody talks about it. That may happen once or twice but not regularly. Somewhen somebody would talk.
[4] Just to make that clear: that is the first case of that kind in the legal history of Germany (i.e. where an officer does this and then reports himself)
if linux want's to go mainstream and come out of the server room linus will have to compromise.
"If Linux wants" again. Linux doesn't want anything than being useful to those who want to run Linux (see Linus' interviews...). The (grand-)parent poster was right: If you want to run Linux, there is usually no problem to find hardware that is supported without the need for proprietary drivers (the exceptions being GFX cards and hardware niche uses).
Yes, it's a problem if you want to migrate your existing hardware. But that hardware will stay usable only for so long. After that, if you really do want to run Linux, you know to check the hardware compatibility before you buy the replacement.
So, bash and csh scripts may be harder to read and write in general, but IMHO there is not that gap in difficulty between writing and reading as there is with Perl.
hey there cat... we argued before... hope it doesn't happen again... :) :-)
many programs for "noraml" users _are_ limited by tight loops. look to the wikipedia for info on big-o noataion.
think about a VPN or router vendor that needs to route traffic for users. for each user, we must route each packet O(n).
now think of a firewall vendor. we must route each packet after checking it against this set of deny or allow rules. this is a common case.. but represents an O(n^2).
Technically, that's O(n), too. If you double the number of packets to filter, you need twice the time, not four times. Same with the number of rules. So have it O(n) and O(m) (so to speak), depending on what you consider as primary input, but not O(n^2).
now O(n^2) can be "ok" for small n... and perhaps the "bugs" you talk about are poorly designed rule lookups. Now imagine a large ISP that uses a firewall to block virus' from being sent outbound. this is still O(n^2), but the n can be huge, and that loop is executed for each packet... also a huge number. hard to optimize.
That's why I spoke of programs for normal users, i.e. application programming. Yes, there are plenty of programs that are limited by a tight loop. But in my experience those are mostly found in special software (that has limited purposes), like, for example, routers.
it usually takes a shift in philiosophy to break out of this kind of case. say, come up with a way that we don't have to check every deny/allow rule for each connection and you have beat it.
Agreed.
Just to make myself clear: I don't deny that there is plenty of room for optimization in lots of programs. But the stuff your average developer writes (i.e. user applications, web pages, etc.) makes only a small percentage of those programs (aka "when did you last write firewall or router software?"). So my point was, that the results of benchmarking tight loops is not too relevant with regard to the kind of software most of us write.
Wow. You suprised me! (And I mean that in the most positive way). Not sure if I had answered - considering that my last post was kind of snappy.
/me goes trolling elsewhere :-)
And yeah, kind of offtopic now...
Okay, you are either ignorant or trolling. Probably the latter. I will answer anyhow, because for others it might be not as obvious.
:-)
:-) Ah, and may I ask you to hold you to your own standards and at least consider that you misread him?
you: that is a 2.6-test kernel... not the same thing as the 2.6 kernel itself.
me: You are provably wrong. Where are you taking your information from?
you: no.. really... 2.6 is not the same as 2.6-test. prove me wrong. please.
Yeah, of course, you never happen to think - even considering the rest of my comment - that I was referring to the other part of the sentence, namely that [you claim that the kernel that Cooker contains since december] is a 2.6-test kernel, did you? To make it clear even for you: Yes, I completely agree, there is a diferrence between 2.6-testx and 2.6.x (but not as big as you like it to make), but that was never the point I argued.
original poster and me: provides Linux 2.6 as kernel default since december
you: That is the line I was talking about. Using the parent's citation at cooker snapshot, I can show that indeed, he was talking about 2.6 being there when his citation said 2.6-test.
From that page:
- content: 1 ISO image with Linux 2.6.0-test1, XFree 4.4pre, Gcc 3.3.2 and KDE 3.2pre.
[that belongs to: Cooker Snapshot 20031217]
Also on that page (for Cooker Snapshot 20031231)
content: 2 ISO images with Linux 2.6.0, kde 3.1.94 or XFree86 4.3.99
Ah, I see, 2003-12-31 is not part of december nowadays.[1]
Ok, more seriously, there is a difference between Cooker and Cooker snapshots. I made that as clear as possible in my parent post, but you choose to ignore it. The orignal poster said: For your information, Cooker provides Linux 2.6 as kernel default since december. ISO snapshots are available here for download, with also a preview of the new KDE.
He doesn't say anything about when 2.6 was available in ISO snapshots. He says, that 2.6 was available in Cooker since december (for which I provided a reference which showed that it was mid-december). And that additionally, snapshot are available somewhere. Just because you misread him and misquote him now, doesn't make you right. I even went previously with the point that you might referring to the 2003-12-17 snapshot, but you choose to ignore that, too, in your reply.
But let's presume your point of view for a moment. The page you cite implies the 2.6.0 kernel went into Cooker between 2003-12-17 (which had a 2.6-test) and 2003-12-31 (which had 2.6.0), a time range which includes the 2003-12-18 (when 2.6.0 went into Cooker), a day which most of us would call part of mid-december.
If you can show me, where the parent poster or me said that Cooker snapshots had 2.6 since december, I will happily apologize. And even if he had referred to a snapshot, he could have meant the one of 2003-12-31 and would be correct in a sense of the meaning.
you: Again, for the hard of hearing.... 2.6-test is not the same as the full 2.6 kernel.
Yeah, yeah, we heard you. And maybe you should clean your ears, because nobody claimed the contrary.
you: Try not to be such a condescending prick when you are wrong, or confused about the topic.
Oh, I am not confused at all. And I am not wrong either. A prick, maybe.
[1] Yeah, yeah, I know that it was released only a day later. See the smiley there?
I'd venture it's because the Slashdot community holds their villians to a higher standard than their heroes.
Or maybe because he doesn't makes Microsoft and MS Windows and its license bad with every breath he takes. In other words: he may be critic of them, but he doesn't spread FUD. Most times he simply doesn't care and openly admits that.
If Linus had bad-mouthed Microsoft with every speech, I dare say he would get the almost same backslash as Mr. Gates would get.
Cooker had the final 2.6.0 since Dec, 18th [1] and is currently available with 2.6.1 by contributers. Maybe you refer to the first snapshot ISOs, which were made mid-december and so couldn't possibly include anything than a 2.6-test kernel (2.6.0 was released after the snapshots were taken, and so the 2.6-test kernels were all that was available at that time).
But that snapshot is long outdated. The latest was released on the 1st and included a 2.6.0 kernel. The next Cooker snapshot is due any day now should even more recent kernel packages. Not sure, if 2.6.1 will make it (regardless, an up-to-date 2.6.1 kernel, heavily based on the -mm tree, is available in contribs already [2]).
Anyhow, the point of the original poster was that Mandrake Linux 10.0 will ship with a reasonably recent 2.6 kernel as option. AFAIK, the aim is to let it be the default option, with 2.4 as alternative, but that will be determined by how stable it is at the time of the freeze and if all the common hardware is supported good enough. (I am too lazy too dig up a link to the cooker mailing list archive... if you don't believe me after I showed references for all my other claims, go looking yourself
[1] From the rpm changelog... You can get the rpm here (currently it's 2.6.0.1mdk-1-1mdk and view the log with
rpm -qip --changelog filename
* Thu Dec 18 2003 Nicolas Planel <xxx@mandrakesoft.com> 2.6.0-1mdk
- 2.6.0 final version
- ndis wrapper 0.3.
- fix uss725.
[2] And before anyone screams about not wanting to run a kernel by contributers: Nobody says you must. But experience shows these contributers know what they do and that most patches get integrated in the official mdk-kernel later (note that the contributers mainly integrate existing patches by "official" kernel developers and don't write their own). It's kind of a testbed like the -mm tree is for the "official" Linus kernel, currently.
Which part of the real key to desktop acceptance [...] is for manufacturers to ship boxes with Linux loaded didn't you understand? He said exactly what you repeated: That the main reason for a better user experience is that Windows comes preloaded (and once computer makers start the preload Linux, that advantage is gone).
If you've ever done much optimization work, you'd realize that most programs are speed limited by a few small, often simple loops that just happen to execute an expensive operation or just plain run a lot. So while micro-benchmarks are never perfect, these ones aren't too bad at reflecting what actually happens in real life programs.
I wonder which kinds of programs you are writing (that is not meant as a rhetoric, but a serious question).
What you describe doesn't reflect my experience (except for the simulations in physics I've done). Any program for "normal users" that I profiled hadn't such obvious points for improvement (except if the algorithm was buggy to begin with or for inputs that were corner cases - like CGI's that produce 30MB web pages which no normal user would want wait for that).
Last but not least, I think their packagers have 2 left hands. When I was using 9.1 (witch comes with python 2.2) I needed python 2.3 (need tarfile module). I thought "no problem, let's see what urpmi can do". This simple upgrade gives me 105 dependencies!!!!
I am curious what wacky thing you did. I am quite positive that this python 2.3 was not for ML 9.1. They practically never release "new version" updates for a package.
So where was this python 2.3 from? A third party? Then don't complain about Mandrake's packagers. Cooker (pre-9.2) or 9.2? Then you indirectly asked for a dist-upgrade. Be glad it was only 105 packages.
Yeah, and the reviewer even preempted that joke:
Beware, there are a few spoilers ahead; obviously, most of the Slashdot crowd knows the story in the books, but what will follow should be considered a spoiler, as I am describing Jackson's adaptation of the book.
Hm. That must means that all "funny moderators" have either a rather lame sense of humour (as the parent poster said, it's the second repetition for these movies) or they didn't read the review past the first paragraph.
Well, who I am kidding, this is Slashdot, so it's both.
As I said, "maximum number of pages" already implies no reasonable structure. As soon as you start worrying about structure and/or reasonable content, you won't reach the maximum. So it makes no sense to argue about the kind of links when trying to determine the upper limit.
Any pages (including leaf ones) with only 7 links would rule out most existing hypertext of today.
But I bite: Nonwithstanding the fact that we were talking about the maximum number of pages, which implies that we disregard reasonable structure/layout, I see no problem with the index pages containing (some of) the links in the content.
Just for completeness: Your math is wrong.
With 3 clicks you have 4 levels. The first (which you see without clicks), and the three following. The maximum number of pages you can have, given that there are no cross-links is:
level 1: 1 page, links to 7 pages of level 2
level 2: 7 pages, links to 7*7=49 pages of level 3
level 3: 49 pages, links to 49*7=7^3=343 pages of level 4:
level 4: 343 pages, no links (3 clicks reached).
sum: 400 pages.
So your calculation was only for the 4th level alone.
Another side-note: Since the rule states 7+-2, you are allowed 9 links at most and so the overall maximum is: 1+9+81+729=820 pages.
According to Mandrake's site, they provide Mandrake Packs of Acrobat, Flash, Real, nVidia drivers, and other non-OSS software. Not 100% OSS.
That are the commercial boxes, e.g. the PowerPack edition. Yes, they accomodate people who prefer a commercial package for ease of use (no need to handle nVidia drivers etc. yourself) or other reasons.
The "100% OSS" applies to the Download editition (a comparison).
The latter is the one you can download for free. The former has been made available for download only for MandrakeClub members (silver and higher) and contributors as of ML9.2, and is sold as boxed set, too, of course.
But I doubt that Mandrake itself would use the 100% OSS label. IMHO, it's not really technically correct. They don't require all licenses to be OSI approved. AFAIK, they require the license to allow the software (source and binary) to be (re-)distributed freely on the the download edition. Which basically boils down to: the licenses usually fit into the OSI spirit, but aren't necessarily officially OSI approved.
1) "Boi de piranha":
Nice one.
Though, the analogy doesn't hold. Open source developers don't think/act like predators. If anything, this incident increased the chance that somebody will look for further things that look strange (well, rather "many sombodies").
It even increased the chance that people who never looked at the kernel before, just look now because of this.
Correct. And just to be clear, the definition you cited makes obvious that Apache[1] isn't a monopoly[1]. Because the ASF has no control. Neither has anyone else. Everyone can go and fork Apache for their own need, if they want to. E.g. if you don't want to switch to Apache 2.0 in the foreseeable future, you are free to start a long-living support branch for 1.3.
The Webster entry makes this even more obvious: If you think about it, neither 1. nor 2. apply to the ASF, nor 3. to Apache.
[1] Let's ignore for a moment that Apache has not (yet) the market penetration needed to have a monopoly.
Sigh. Why got this modded up? Only because he mentions that previous moderation was unfair? He is trolling!
For anyone who thinks about taking him seriously, just some comments:
He "proofs" his claim that Apache is not the most secure web server mainly by going to show that MacOS is a better operating system than others. (See? If not, think about how his arguments applies for running Apache on MacOS). That leaves only point 4 (the first one, not the one at the place of point 6), the only one talking about another webserver:
4. Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension)...
As has Apache. So what is the point?
File types on Macs are not easily settable by users, expecially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
Without commenting about the correntness of this claim, if the alleged problems are gone now, what do they have to with how secure Apache is today?
Another proof for trolling:
2. No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidian's birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.
Yeah, and that's why Microsoft Windows 98 security is so good. NOT! Really, ask anyone serious in the security community and you get the answer that privilege separation is the way to go.
And one would think that you know not to blindly believe anything in a
The only mention of a new 9.2. is in the
AFAICS, there was no statement about the label in any official place (mandrakeclub, mandrake.com, the mailing lists,
Because his link points to FreeBSD, so obviously he's trolling against Mandrake and Linux in general.... or something like that, who knows?
Obviously? Obviously? Just because he outs himself as BSD fan, this makes im trolling as soon as he speaks about another OS?
Forget about the FreeBSD link for a moment and you will realize that he asked a valid question that a majority of Mandrake users (and "wanna-be"s) are wondering about. And if you don't have to believe me on this: simply read the Mandrake-specific forums or mailing lists, where this question is all over the place.
We seem to have a communication hole here. I don't see how your answer relates to my rebuttal of your claims. I'll try to clarify...
Compiling? Why? Why not just log into the box and do your compiling there?
Which box, the one with the left or the right part of the mirror of the RAID system? Remember, this was about a network file system configured in a way, that the overlying RAID system would give redundancy by storing the two parts of a mirror configuration on different computers. In other words: no matter on which machine you are logged in, some disk of the RAID is not on the local computer.
But to come back to your question of why not just log into the box and do your compiling there: Because the idea of the network file system was to connect several (8, IIRC) computers in the LAN. If he could do all his work with only 1 computer, he had no reason to have a LAN to begin with. E.g. different OSes. I don't know, if it is a matter for the original poster, but he explicitly said, it was a misc envirement and I would rather not try to cross-compile Windows to Linux or vice versa, if I don't absolutely have to.
As for the floppy example, you should note how good the performance was. He moved a 3.6MB file to it in 32 seconds, that might sound slow to you and me,
I didn't argue the speed of the floppy RAID at all, but the speed of USB.
but 112KB/s, close to the USB maximum throughput.
This was my point. I argued that saying "if you can do RAID over USB..." is bogus, when USB was only good enough, because it was a floppy RAID and as you just said yourself, even then USB barely managed to keep up.
If I'vr decided I want to archive something via my network, I've already decided that the delay is worth it.
But this was not only about archiving, but about replacing the complete local data storage by a network storage (in order to have a global redundancy).
If a net RAID sucks down my data as fast as I can send it, but also gives me error correction, I've done myself a favor by using it.
I completely agree. But I never argued about that point. What I argued was your claim, that one would not notice the speed loss [at least on Windows].
This might not work so well for kernel compiling, but it would be just fine for tar files of images.
Nope. I already anticipated that argument in my previous post and answered it there: "Ah, and if compiling does not fall into the "data storage" category: Well, simply copy that 50MB log file around, and some seconds become minutes (regarding the nobody would notice a "10 MBit" link)." (if you do log files or images doesn't make a big difference, as long as the file size is counted in MB).