Well, their Linux kernel driver comes with source code (not distributable, but you can read it...) From what I hear, the only reason the GLX doesn't have sources available is because nVidia doesn't own some of the code it uses.
This is not true- What they do have is a pre-compiled binary image and a bunch of source code that hooks it into the linux kernel once the extra source is compiled, it links it into the binary code. The nVidia drivers are far from open-source. (I'm not complaining, mind you. I use the nVidia kernel modules with my machines and get fantastic performance)
Yes, of course we hate them; They're an evil company trying to take our rights away to create interoperability software.
But, jesus, that game looks sexy. It's very VERY hard to keep up your morals when the companies do that to you; I hate blizzard, and I've sworn off Diablo, warcraft AND starcraft because of what they've done. But it's going to take every last drop of willpower left in my body to stop me from buying this game when it comes out, and there's a chance that it just won't be enough.
the least they could do is point out the flaws in the system to somebody who is interested in that project.
There's posts all over lkml talking about the strengths of BK, and the weaknesses of everything else. They've been there since almost the first day Linus started using BK. Anyone could read that, and implement it in $OSS_SCM_TOOL if they wanted.
This argument does not hold water. Why did Linus create the inferior Linux of 1991 at all? There were many superior UNIXes at that time.
Go back in time and substitute "BitKeeper" with "Minix" to see the hypocracy of his statement.
He created it for fun. Everyone knows that. It had nothing to do with becoming a superior unix, and he didn't expect then for anyone to go out and install it on a production server.
The BK->CVS gateway is now explicitly prohibited by the BK license. The only way around it would be a non-realtime solution whereby one individual makes available BK->patch files and another individual makes a patch->CVS gateway. This solution is a non-solution - it's slow and awkward and is not protected from a future licensing whim change of Larry McVoy.
Bullshit. There's nothing in the license that prohibits that. It prohibits someone from using bk if they write for another SCM system. But, larry doesn't own the data.you send through bk, and as long as you're not a CVS developer, you can export a new tree. Go read the entire set of threads on it lately, he says that explicitly a few times. In fact, there's an rsync'able tree that you can sync with sccs right now.
All of the actions you speak of include re-transmitting the entire file; if you modify a binary file, you can't just update the changes. likewise, if you rename a file, you have to remove one from the archive, and create a new one. although that works, that's significant overhead if you change a lot of things.
Actually, I *read* the thread, and Larry was attempting to claim that everyone should stay away from free version-control systems, and that he felt it was necessary to impede their development in any way possible.
Larry never says that; in fact, in recent threads, he talks about what he tells his customers. They'll walk up and say "Why should i use BK over CVS?". His reply is "Does CVS hurt?". if they say no, he'll tell them to come back when it hurts.
His reasoning was essentially that someone could make a free bitkeeper clone which would be "good enough" to draw bitkeeper users away and bankrupt him, but that (because they would be unpaid/amateur/lazy/not Larry McVoy) they would be unable to acheive bk's high level of quality, the sun would fall out of the sky, the seas would
boil, etc.
Again, you're a little off; People have asked many times what he thinks it would take to create a new SCM of bk's quality from scratch. His answer is always multiple years with multiple full-time coders and millions of dollars, and that he doesn't think anyone has that sort of dedication.
Does that not seem a little childish, to demand of the person who gave you most of the operating system you are now using, that he continue to get you out of proprietary software ruts in the future?
Not really; I'm not the one who has a problem with the kernel developers using BitKeeper. But that's what my problem is. Over the years, RMS's attitude has gone from "The world is wrong, I should fix it" to "The world is wrong. I should tell everyone else to fix it."
The answer that's repeatedly given on the kernel mailing list is "Well, if you want us to use something else, build it for us.". This is like RMS walking up to a carpenter, taking his hammer, and telling the carpenter to invent something better-- Nevermind that he's in the middle of building a house.
But none of the naysayers ever ask "What can *I* do to fix this?". I only expect more out of RMS, because he didn't say "HEY! YOU GUYS ARE USING PROPRIETARY UNIX COMPILERS! USE SOMETHING MORE FREE!". He said "Hey, i should make a truly free compiler."
On the other hand, while I don't follow lkml, Slashdot user fv believes that Linus is subtly encouraging BK.
Reading that link, it sounds like Linus is complaining because someone else's patches won't merge correctly into his tree.
He does outwardly support BK; claiming it's made him more productive and his life easier. However, this link isn't that. It's just him bitching about bad patches coming in.
I would expect that in addition to this post to the kernel list, RMS is also doing what he can to support BK alternatives. But that probably would not be as public or controversial.
That's precisely the problem. He's making himself look like more of an ass by doing this. It would be 5000% more effective for his post to lkml to say "I've decided to support the (subversion|arch|aegis|pcrs|whatever) project as an official GNU project, and give them funding and development help so that the kernel team will have a viable alternative to BitKeeper. The project page is at http://www.gnu.org/projects/gnukeeper. Any input from kernel developers about what features are needed to replace BK are welcome at the mailing list, gnukeeper-devel@gnu.org"
*THAT* is constructive. Sending a post that says that he's doing something about his situation. Otherwise he looks like every other crybaby group, like the Group of university students earlier this year, or whoever started last weeks huge thread. Saying "I Hate that you're using this closed product!" is all good and well, but if you don't follow it up with "So here's what I'm doing to remedy the situation", you look like an idiot. If you care that strongly about something, especially if you're in charge of or high up in the GNU foundation or the Free Software Foundation, you should put some backing behind your words.
I expect more out of RMS as this; Others have pointed out that the linux environment is kind of a "flagship" of opensource development in GNU/FSF's eyes. You'd think they'd be committed to providing an alternative if they cared. They've done it with lots of other stuff in the unix world, and they've done a very good job. But, it's been since April or so since bk started being used for kernel devel, and not a single project has stepped up with GNU/FSF's backing and put some real work into doing everything bitkeeper does and more.
Or, the reason could be that Larry McVoy's estimates on the time and money required to create another such beast are shockingly accurate, that's why nothing's stepped up.
There are plenty of huge open source projects, and they work fine with CVS. GNU Hurd is being developed with CVS. BSD is. To me, the real question is: what is going wrong with Linux kernel development that CVS is not sufficient?
Neither have the magnitude of Developers or incoming patches that the Linux kernel has- *BSD have very small development teams. HURD's developer team is slightly larger, but still nowhere as large.
Here's an archive of the recently-set-up bk-commits-head mailing list, which shows patchsets sent through the bk 2.5 development tree alone.
Software with non-restrictive licenses should be used for important free software projects even when it is not seemingly the best tool for the job.
Try telling them this; The kernel developers would laugh in your face. They've said before (Linus Especially) that they're not going to use an inferior tool just because it's free. As long as it doesn't hurt them, they'll use what they consider the best tool for the job.
A license like this makes things harder for someone who wants to hack on the kernel but who is prohibited by BitKeeper from getting the source the way the rest of the kernel team does.
Not really. like has been pointed out many many times on lkml, you don't need to even touch BK to be involved in kernel development.
As linus said in one of his posts to lkml a while back, "Or just go on and ignore the fact
that some people are using BK - you don't actually have to ever even
know.". The kernel team using bk doesn't hurt on anyone's ability to develop the kernel.
Here'sahandful of links to kernel archive mirrors discussing subversion. There current attitude of kernel developers is that subversion is nowhere near mature enough to replace bk for kernel use yet. once it is, people will happily switch.
So, for the time being, live with them using BK, and know that you don't have to use it at all to help with kernel development.
Well, CVS is fine for small projects. Linux is anything BUT a small project; there's a lot of things that cvs either doesn't support, or supports poorly. Binary files and renaming files, for example. There's a handful of other things, but the bottom line is, the linux developers who are using BK would laugh in your face if you told them CVS was a viable replacement.
That said, this is all the more reason for developers to switch from BitKeeper to alternatives. BitKeeper can impose any draconian restrictions on you they wish, and you'd best not wait until you're trapped into using BitKeeper and dependant on it to change.
Trapped? Not so. If they stop using bk, everything bk ever did still works in patches, and they'd just be in the same boat they were BEFORE using bk-- diff and patch. In fact, right now, if RMS wanted to send Linus a regular patch, he could, without ever using bk. There's also currently a rsync'able bk mirror out there, and bitkeeper retains SCCS compatibility. Anyone can use that and get the latest bk tree, write a patch, and send it on to Linus.
But ask yourself this- If any SCM software out there worked anywhere near as well as bk, why are there so many out there with personal bk trees, and using bk, and none using anything else, exporting their stuff to diff format, and sending the patches that way?
Because none of the OSS SCM tools can do that for them. So all the complainers out there should get to hard work fixing up an OSS SCM to the linux developers' needs, and spend less time bitching.
Maybe its time for someone to start developing a OSS competitor to BitKeeper (without using BitKeeper of course!)
Nobody will; Why? Nobody has really tried so far- even RMS is too stubborn to ask "Well, what is it that bitkeeper does that (cvs|subversion|arch|pcrs) doesn't do?", and then gone off and tried to implement it- in fact, this is what all of bitkeeper's advocates, including it's creator, Larry McVoy, and Linus Torvalds have been saying all this time. "Make me something better, and we'll use it.". Yet, everyone is very willing to complain, and just ignore when $KERNEL_DEVELOPER_USING_BK says "$FEATURE is something i use every day with BK, and isn't in any of the OSS source management tools."
It's funny how much people will bitch when they're not the ones that have to deal with the inadequacies of $OSS_SM_TOOL when it comes to kernel development.
(Actually, i believe that the subversion author (although i may be wrong about which project) has asked, but they're still a ways off in everyone else's eyes- Hell, even bitkeeper isn't there yet. Larry takes plenty of input and actually implements the missing features that Linus and company ask for, though, which is much better than any oss project.)
I'm fairly dissappointed in RMS in this- You'd think if anyone was going to make a GNUkeeper, it'd be him.
On the other hand, Sony does support Linux on their PS/2 and develops for it. I guess that they think (rightfully) that if you buy a PS/2, you will most likely buy games for it too. Having Linux (and network on it) might just be the extra push the customer needs.
Part of sony's Linux/PS2 push is trying to get more people proficient at coding for the playstation2- More people who can code, more people who can get jobs at PS2 devel houses. This means more money for them in the long run.
Did I miss something? I thought the Bon Jovi thing was just like printing a unique serial on the booklet or a piece of paper that comes with the thing, or something.
How the hell is that technology, or more to the point, patentable?
Actually, last I read, under the GPL, modules which are inserted into running code count as derivative works. The linux kernel makes a special exception saying that binary-only modules are allowed. In any case, it's a sticky subject, and they'd need to at least secure permission for this specific use of the code.
My question about whether or not third-party modules could be created was meant as "has apple made the interface for this an open specification?".. That is, I know how microkernels work, but I don't know how feasible it is for mac os X. Do they include the right header files and provide an API for third-party (especially open-source-- They can very possibly put some sticky licensing into a developer license for the API) modules?
As for the "viral" nature of the GPL, It's so called because a large number of open-source licenses allow their code to be included into GPL'd code, but the GPL does not allow that same liberty.
It's worth mentioning that QuakeNet doesn't allow warez or piracy channels, while I'm pretty sure most of the other "big five" do. EFNet is in fact known for piracy. If they instituted such a policy, they'd drop to somewhere around 5k users, falling somewhere behind the feeble freenode (Which is a name laughed at by the big boys, who have about 15 times as many users, but ask for no donations of any kind, especially not $25k)
Mac OS X should be able to see all partition types that FeeBSD can see. Linux too.
Not entirely true; Mac OS X has a FreeBSD compatibility layer, but is not based on the FreeBSD kernel. It uses a Mach Microkernel, similar to GNU HURD. Although they can technically port any filesystem drivers from FreeBSD over to OS X, this is not true for Linux filesystem drivers- Since Linux is covered under the GPL, filesystem drivers in Linux are also covered. Hence, without GPL'ing OS X (at least their entire Kernel), they can't pull anything from Linux.
So, you won't likely see anything like reiserfs in OS X anytime soon.
Does anyone know if it's easy / possible to create a third-party filesystem driver for OS X? I don't like Apple stuff, so I don't know much about that part of OS X internals. Do they have a Loadable Kernel Module interface? Anything like that?
It's not even that; What the reviewer doesn't realize is that even though they want to appeal to new users, SuSE does NOT want to alienate any of their CURRENT userbase. And although I don't particularly love SuSE, I know a fair amount of competent Linux users who swear by it.
it requires zero configuration once you're configured properly
.... Um. I may have missed something, but isn't this the way all software works? I know that, once I've configured something properly on my LFS system, it requires zero configuration after that...
That's a little critical; Hell, opera ran better on my p233mmx than mozilla runs on my Duron 800. Yeah, it's not that necessary for/Opera/ to improve speed, but IE and Mozilla sure could use some improvements.
Besides that, opera's only two downsides right now are less-than-perfect DOM support, which they claim is being fixed in O7, and jscript not always working right.
Opera has support to remove popup ads (Well, you can either disable popups or not or open them in the background). Their cookie rules editor is excellent, being able to masquerade as any other browser is nice for sites that say "We only allow IE" just so they don't have to listen to bug reports for other browsers, and the ability to choose between Showing images, not showing images, and only showing images already in the cache on a Per-Page basis is excellent. (Especially when trying to view an image-heavy page in the process of being/.ed- get the text first, and only load the images that look good to you)
So, with all that/Already/ working, if you can throw some speed enhancements in while fixing the DOM support, why not?
That ONE $200/mo server would most likely cover most of OPN's users. IRC is VERY low-traffic, and OPN only carries about 7000 users.
That, to me, adds up to $2400 over a 1-year period. Double that, you'll for sure cover all bandwidth costs for OPN by far, and you're still under $5k. And you'll have plenty of spare bandwidth to put your own stuff up.
Slashdot Mirror
Your LED could do morse code? All Mine could print was binary.... and I LIKED it that way!
Well, their Linux kernel driver comes with source code (not distributable, but you can read it...) From what I hear, the only reason the GLX doesn't have sources available is because nVidia doesn't own some of the code it uses.
This is not true- What they do have is a pre-compiled binary image and a bunch of source code that hooks it into the linux kernel once the extra source is compiled, it links it into the binary code. The nVidia drivers are far from open-source. (I'm not complaining, mind you. I use the nVidia kernel modules with my machines and get fantastic performance)
Yes, of course we hate them; They're an evil company trying to take our rights away to create interoperability software.
But, jesus, that game looks sexy. It's very VERY hard to keep up your morals when the companies do that to you; I hate blizzard, and I've sworn off Diablo, warcraft AND starcraft because of what they've done. But it's going to take every last drop of willpower left in my body to stop me from buying this game when it comes out, and there's a chance that it just won't be enough.
the least they could do is point out the flaws in the system to somebody who is interested in that project.
There's posts all over lkml talking about the strengths of BK, and the weaknesses of everything else. They've been there since almost the first day Linus started using BK. Anyone could read that, and implement it in $OSS_SCM_TOOL if they wanted.
This argument does not hold water. Why did Linus create the inferior Linux of 1991 at all? There were many superior UNIXes at that time. Go back in time and substitute "BitKeeper" with "Minix" to see the hypocracy of his statement.
He created it for fun. Everyone knows that. It had nothing to do with becoming a superior unix, and he didn't expect then for anyone to go out and install it on a production server.
The BK->CVS gateway is now explicitly prohibited by the BK license. The only way around it would be a non-realtime solution whereby one individual makes available BK->patch files and another individual makes a patch->CVS gateway. This solution is a non-solution - it's slow and awkward and is not protected from a future licensing whim change of Larry McVoy.
Bullshit. There's nothing in the license that prohibits that. It prohibits someone from using bk if they write for another SCM system. But, larry doesn't own the data.you send through bk, and as long as you're not a CVS developer, you can export a new tree. Go read the entire set of threads on it lately, he says that explicitly a few times. In fact, there's an rsync'able tree that you can sync with sccs right now.
All of the actions you speak of include re-transmitting the entire file; if you modify a binary file, you can't just update the changes. likewise, if you rename a file, you have to remove one from the archive, and create a new one. although that works, that's significant overhead if you change a lot of things.
Actually, I *read* the thread, and Larry was attempting to claim that everyone should stay away from free version-control systems, and that he felt it was necessary to impede their development in any way possible.
Larry never says that; in fact, in recent threads, he talks about what he tells his customers. They'll walk up and say "Why should i use BK over CVS?". His reply is "Does CVS hurt?". if they say no, he'll tell them to come back when it hurts.
His reasoning was essentially that someone could make a free bitkeeper clone which would be "good enough" to draw bitkeeper users away and bankrupt him, but that (because they would be unpaid/amateur/lazy/not Larry McVoy) they would be unable to acheive bk's high level of quality, the sun would fall out of the sky, the seas would boil, etc.
Again, you're a little off; People have asked many times what he thinks it would take to create a new SCM of bk's quality from scratch. His answer is always multiple years with multiple full-time coders and millions of dollars, and that he doesn't think anyone has that sort of dedication.
Does that not seem a little childish, to demand of the person who gave you most of the operating system you are now using, that he continue to get you out of proprietary software ruts in the future?
Not really; I'm not the one who has a problem with the kernel developers using BitKeeper. But that's what my problem is. Over the years, RMS's attitude has gone from "The world is wrong, I should fix it" to "The world is wrong. I should tell everyone else to fix it."
The answer that's repeatedly given on the kernel mailing list is "Well, if you want us to use something else, build it for us.". This is like RMS walking up to a carpenter, taking his hammer, and telling the carpenter to invent something better-- Nevermind that he's in the middle of building a house.
But none of the naysayers ever ask "What can *I* do to fix this?". I only expect more out of RMS, because he didn't say "HEY! YOU GUYS ARE USING PROPRIETARY UNIX COMPILERS! USE SOMETHING MORE FREE!". He said "Hey, i should make a truly free compiler."
So why isn't this the situation for BitKeeper?
On the other hand, while I don't follow lkml, Slashdot user fv believes that Linus is subtly encouraging BK.
Reading that link, it sounds like Linus is complaining because someone else's patches won't merge correctly into his tree.
He does outwardly support BK; claiming it's made him more productive and his life easier. However, this link isn't that. It's just him bitching about bad patches coming in.
I would expect that in addition to this post to the kernel list, RMS is also doing what he can to support BK alternatives. But that probably would not be as public or controversial.
That's precisely the problem. He's making himself look like more of an ass by doing this. It would be 5000% more effective for his post to lkml to say "I've decided to support the (subversion|arch|aegis|pcrs|whatever) project as an official GNU project, and give them funding and development help so that the kernel team will have a viable alternative to BitKeeper. The project page is at http://www.gnu.org/projects/gnukeeper. Any input from kernel developers about what features are needed to replace BK are welcome at the mailing list, gnukeeper-devel@gnu.org"
*THAT* is constructive. Sending a post that says that he's doing something about his situation. Otherwise he looks like every other crybaby group, like the Group of university students earlier this year, or whoever started last weeks huge thread. Saying "I Hate that you're using this closed product!" is all good and well, but if you don't follow it up with "So here's what I'm doing to remedy the situation", you look like an idiot. If you care that strongly about something, especially if you're in charge of or high up in the GNU foundation or the Free Software Foundation, you should put some backing behind your words.
I expect more out of RMS as this; Others have pointed out that the linux environment is kind of a "flagship" of opensource development in GNU/FSF's eyes. You'd think they'd be committed to providing an alternative if they cared. They've done it with lots of other stuff in the unix world, and they've done a very good job. But, it's been since April or so since bk started being used for kernel devel, and not a single project has stepped up with GNU/FSF's backing and put some real work into doing everything bitkeeper does and more.
Or, the reason could be that Larry McVoy's estimates on the time and money required to create another such beast are shockingly accurate, that's why nothing's stepped up.
There are plenty of huge open source projects, and they work fine with CVS. GNU Hurd is being developed with CVS. BSD is. To me, the real question is: what is going wrong with Linux kernel development that CVS is not sufficient?
Neither have the magnitude of Developers or incoming patches that the Linux kernel has- *BSD have very small development teams. HURD's developer team is slightly larger, but still nowhere as large.
Here's an archive of the recently-set-up bk-commits-head mailing list, which shows patchsets sent through the bk 2.5 development tree alone.
Software with non-restrictive licenses should be used for important free software projects even when it is not seemingly the best tool for the job.
Try telling them this; The kernel developers would laugh in your face. They've said before (Linus Especially) that they're not going to use an inferior tool just because it's free. As long as it doesn't hurt them, they'll use what they consider the best tool for the job.
A license like this makes things harder for someone who wants to hack on the kernel but who is prohibited by BitKeeper from getting the source the way the rest of the kernel team does.
Not really. like has been pointed out many many times on lkml, you don't need to even touch BK to be involved in kernel development.
As linus said in one of his posts to lkml a while back, "Or just go on and ignore the fact that some people are using BK - you don't actually have to ever even know.". The kernel team using bk doesn't hurt on anyone's ability to develop the kernel.
Here's a handful of links to kernel archive mirrors discussing subversion. There current attitude of kernel developers is that subversion is nowhere near mature enough to replace bk for kernel use yet. once it is, people will happily switch.
So, for the time being, live with them using BK, and know that you don't have to use it at all to help with kernel development.
Well, CVS is fine for small projects. Linux is anything BUT a small project; there's a lot of things that cvs either doesn't support, or supports poorly. Binary files and renaming files, for example. There's a handful of other things, but the bottom line is, the linux developers who are using BK would laugh in your face if you told them CVS was a viable replacement.
That said, this is all the more reason for developers to switch from BitKeeper to alternatives. BitKeeper can impose any draconian restrictions on you they wish, and you'd best not wait until you're trapped into using BitKeeper and dependant on it to change.
Trapped? Not so. If they stop using bk, everything bk ever did still works in patches, and they'd just be in the same boat they were BEFORE using bk-- diff and patch. In fact, right now, if RMS wanted to send Linus a regular patch, he could, without ever using bk. There's also currently a rsync'able bk mirror out there, and bitkeeper retains SCCS compatibility. Anyone can use that and get the latest bk tree, write a patch, and send it on to Linus.
But ask yourself this- If any SCM software out there worked anywhere near as well as bk, why are there so many out there with personal bk trees, and using bk, and none using anything else, exporting their stuff to diff format, and sending the patches that way?
Because none of the OSS SCM tools can do that for them. So all the complainers out there should get to hard work fixing up an OSS SCM to the linux developers' needs, and spend less time bitching.
Maybe its time for someone to start developing a OSS competitor to BitKeeper (without using BitKeeper of course!)
Nobody will; Why? Nobody has really tried so far- even RMS is too stubborn to ask "Well, what is it that bitkeeper does that (cvs|subversion|arch|pcrs) doesn't do?", and then gone off and tried to implement it- in fact, this is what all of bitkeeper's advocates, including it's creator, Larry McVoy, and Linus Torvalds have been saying all this time. "Make me something better, and we'll use it.". Yet, everyone is very willing to complain, and just ignore when $KERNEL_DEVELOPER_USING_BK says "$FEATURE is something i use every day with BK, and isn't in any of the OSS source management tools."
It's funny how much people will bitch when they're not the ones that have to deal with the inadequacies of $OSS_SM_TOOL when it comes to kernel development.
(Actually, i believe that the subversion author (although i may be wrong about which project) has asked, but they're still a ways off in everyone else's eyes- Hell, even bitkeeper isn't there yet. Larry takes plenty of input and actually implements the missing features that Linus and company ask for, though, which is much better than any oss project.)
I'm fairly dissappointed in RMS in this- You'd think if anyone was going to make a GNUkeeper, it'd be him.
On the other hand, Sony does support Linux on their PS/2 and develops for it. I guess that they think (rightfully) that if you buy a PS/2, you will most likely buy games for it too. Having Linux (and network on it) might just be the extra push the customer needs.
Part of sony's Linux/PS2 push is trying to get more people proficient at coding for the playstation2- More people who can code, more people who can get jobs at PS2 devel houses. This means more money for them in the long run.
Did I miss something? I thought the Bon Jovi thing was just like printing a unique serial on the booklet or a piece of paper that comes with the thing, or something.
How the hell is that technology, or more to the point, patentable?
Actually, last I read, under the GPL, modules which are inserted into running code count as derivative works. The linux kernel makes a special exception saying that binary-only modules are allowed. In any case, it's a sticky subject, and they'd need to at least secure permission for this specific use of the code.
My question about whether or not third-party modules could be created was meant as "has apple made the interface for this an open specification?".. That is, I know how microkernels work, but I don't know how feasible it is for mac os X. Do they include the right header files and provide an API for third-party (especially open-source-- They can very possibly put some sticky licensing into a developer license for the API) modules?
As for the "viral" nature of the GPL, It's so called because a large number of open-source licenses allow their code to be included into GPL'd code, but the GPL does not allow that same liberty.
It's worth mentioning that QuakeNet doesn't allow warez or piracy channels, while I'm pretty sure most of the other "big five" do. EFNet is in fact known for piracy. If they instituted such a policy, they'd drop to somewhere around 5k users, falling somewhere behind the feeble freenode (Which is a name laughed at by the big boys, who have about 15 times as many users, but ask for no donations of any kind, especially not $25k)
Mac OS X should be able to see all partition types that FeeBSD can see. Linux too.
Not entirely true; Mac OS X has a FreeBSD compatibility layer, but is not based on the FreeBSD kernel. It uses a Mach Microkernel, similar to GNU HURD. Although they can technically port any filesystem drivers from FreeBSD over to OS X, this is not true for Linux filesystem drivers- Since Linux is covered under the GPL, filesystem drivers in Linux are also covered. Hence, without GPL'ing OS X (at least their entire Kernel), they can't pull anything from Linux.
So, you won't likely see anything like reiserfs in OS X anytime soon.
Does anyone know if it's easy / possible to create a third-party filesystem driver for OS X? I don't like Apple stuff, so I don't know much about that part of OS X internals. Do they have a Loadable Kernel Module interface? Anything like that?
It's not even that; What the reviewer doesn't realize is that even though they want to appeal to new users, SuSE does NOT want to alienate any of their CURRENT userbase. And although I don't particularly love SuSE, I know a fair amount of competent Linux users who swear by it.
it requires zero configuration once you're configured properly
.... Um. I may have missed something, but isn't this the way all software works? I know that, once I've configured something properly on my LFS system, it requires zero configuration after that...
That's a little critical; Hell, opera ran better on my p233mmx than mozilla runs on my Duron 800. Yeah, it's not that necessary for /Opera/ to improve speed, but IE and Mozilla sure could use some improvements.
/.ed- get the text first, and only load the images that look good to you)
/Already/ working, if you can throw some speed enhancements in while fixing the DOM support, why not?
Besides that, opera's only two downsides right now are less-than-perfect DOM support, which they claim is being fixed in O7, and jscript not always working right.
Opera has support to remove popup ads (Well, you can either disable popups or not or open them in the background). Their cookie rules editor is excellent, being able to masquerade as any other browser is nice for sites that say "We only allow IE" just so they don't have to listen to bug reports for other browsers, and the ability to choose between Showing images, not showing images, and only showing images already in the cache on a Per-Page basis is excellent. (Especially when trying to view an image-heavy page in the process of being
So, with all that
That ONE $200/mo server would most likely cover most of OPN's users. IRC is VERY low-traffic, and OPN only carries about 7000 users.
That, to me, adds up to $2400 over a 1-year period. Double that, you'll for sure cover all bandwidth costs for OPN by far, and you're still under $5k. And you'll have plenty of spare bandwidth to put your own stuff up.
So, there's still about $20k to be accounted for.