> Actually, ext3 does prevent data loss in full data journalled mode.
And? that still doesn't prevent incomplete writes. WHen you lose power in the muiddle of a write, that write is hosed, completely regardless of what filesystem you use.
> Also, a journalled FS will only ever have to roll back at most one transaction to recover; under all normal circumstances, not even that is neccecary as transactions can be replayed instead of undone.
As already mentioned, when you lose power in the middle of the actual write, that write is incomplete. You cannot replay an incomplete write.
This is also the only situation where ffs will ever lose data, so the difference is virtually none with regards to this.
A big difference is that neither ext3fs or reiser have to do a time consuming filesystem check to detect and recover from such things whereas ffs needs a fsck which takes its time usually (not much of a problem in FreeBSD 5.x due to snapshots and background fsck)
> I've read the source and I disagree, if you can pick up anything in particular then fine but you don't beat flames with more flames. My USB stuff worked fine in 2.4 so I'm assuming you're annoyed with the parents flamish tones, which I can agree with.
Well, as mentioned elsewhere, untill 2.6, it did not manage to properly use my mouse and sd card reader. Judging from people around me as well as what I am reading on here and the rest of the web, I am far from unique in having had such problems. Both devices work with a generic kernel on FreeBSD 4.x and 5.x.
Of course that doesn't say much about the quality of the source code, I cannot point at one specific file that 'sucks', but while reading it and trying to fix it, I found the code very unfriendly to work with. (I have made private changes to both Linux and FreeBSD, and have the skills for it)
At any rate, it wasn't an unfounded flame or such, but my experience and an opinion based on it.
> Agreed, however FFS is a lot more mature than reiser so not entirely unexpected.
True, you'd think tho that ufs has at least the same level of maturity.. (point being that the reliability of ffs is a result of a few design decisions more then anything)
> There's really nothing wrong with the license, despite what the GNU team thinks.
I do not see them saying it is wrong, I see them saying it is incompatible with the GNU GPL.
To quote their statement on it:
"This is a simple, permissive non-copyleft free software license, incompatible with the GNU GPL because of its requirements that apply to all documentation in the distribution that contain acknowledgements."
They believe it is a very bad idea to make licenses incompatible with the GPL, but there it ends. If GPL compliance is not relevant for you (as it is in the case of *BSD) there is no issue (well, except when you are called Theo maybe).
A much better reason to move to X.org is that it quite looks like most development moved to X.org as well.
> They changed it to the same license that the rest of FreeBSD uses.
Oh really?
The XFree86 1.1 license has an advertisement clause, the new BSD license (which is what Free/Net/OpenBSD use) does not, so it is definitely not the same.
> Its not like BSD has a GPL-compatibility requirement like Debian does
That is true, and I doubt this was the issue here really.
> So it performs poorly, but it can "scale". Do you happen to work for Sun Micro?
Considering the concept was used on 68k machines and was quite able to handle dozens of phone lines in realtime (something I have done with such hardware and software), I'd say it doesn't perform poorly, it does however have more overhead then for example a monolythic kernel with a unix style userland even when both concepts are perfected as far as technically feasable.
> That's not the desirable effect and also such proprietary situation was already existing before GIFT [my example] even started
Uh, this effect is quite desirable according to those people in their copy-left argument. Note, it is an effect desired by the people who wrote that license, and often by those who use it. If that applies to you personally is another matter.
> You're contradicting yourself. If you license your code under the GPL and the BSD license while you don't want to push licenses, you are pushing a license with the GPL by putting your code under the GPL.
Uh? that is not about pushign a license but about wanting a specific result for the code I wrote.
> You try to push it as a rule of thumb for protocols. As i argumented, not by definition true. Sometimes GPL code can't even used on a different platform. I really depends on the situation, and i don't see how Samba or GIFT would be more succesful when they were BSD licensed.
This is entirely because the original implementation is not licensed in a way that allows you to reuse its source code (even if you do have access to it)
The situation would be entirely different when the original implementations were available with a GPL or BSD license or similar. For a free software developer it wouldn't matter much which as logn as it would be compatible with his/her license of choice, but to proprietary software makers it would matter.
Releasing Samba with a BSD license would allow SCO to stick a modified version into their unix versions with help of MS and never make the changes available.. this would obviously not help anyone:)
At any rate.. the situation can be different when you are re-implementing an already existing proprietary protocol, but for newly developed protocols, I'd definitely decide on a BSD style license for a reference implementation if I want it to be widely used (and not just in Linux)
> A real technical decision, on pure merit, wouldn't have chosen BSD/Mach in the late 90s. MacOS X is one of the worst performing OSes on the market (which fortunately doesn't matter much for Ghz desktop boxes).
Hmm. a real technical decision, on pure merit.. that would include a lot more then raw performance (or better said, lack of overhead).
A big advantage of mach and similar kernels is that all IPC is message based, which prevents the need for locking. This makes it really easy to scale it to more parallel environments and prevents quite a bit of complicated and bug prone code.
> I haven't seen an official statement from Apple on this, but I believe OS X as we know it is possible only on a BSD foundation for legal, rather than technical, reasons. This is why--if I'm right--you will never see the OS X core moved to a Linux distro.
I believe this has more then just legal reasons. It probably has a lot to do with Apple buying NeXT, which was using a BSD style userland on a microkernel... not that different from OS X in setup, and had been doing that way before Linux would have been a viable alternative.
So they have the skills and experience and had a setup that worked but needed a more modern userland while they wanted to concentrate on the gui.. Those things together would for me result in one option only (tho NetBSD and OpenBSD are catching up, for a while their userland felt like that of FreeBSD from half a decade ago.. and to many of your Linux people, the FreeBSD one probably already looks somewhat achaic..
At any rate.. I doubt there are technical reasons to use one or the other that are very relevant to Apple, in either case they won't be using the kernel, and the kernel is where most of the technical differences between Linux and FreeBSD are. A FreeBSD userland is organized differently from a Linux one (usually that is... with the 100+ linux distributions you can no doubt find oen that is almost identical..) and the legalities are different. From what I know you do get things like gcc with OS X so well.. the legalities of the GPL itself don't stop them it seems.. maybe that is different for things in their core OS? I somehow doubt it.. so I end up with their past experience, directly available skills and cost being the main arguments.
> Silly wabbit! They don't. Many proprietary protocols, GPL protocols, etc have been cloned or reverse engineered even when they were standard. However not ALL. With GPL, one is able to port say GIFT to a proprietary UNIX and run it there. Voila, not any harder than that the software was BSD licensed.
Yes it is harder because you can directly use the BSD code while you can only do that with the GPL code if you are willing to publish your source with the binaries. That is a desirable effect maybe, but those who want to keep their software proprietary disagree. Result, they can directly use BSD code, they can only indirectly use GPL code.
> To say TCP/IP never happened with one GPL implementation is a statement which isn't based on any solid grounds. The source is open, so people are at least able to learn from it if they don't wanna contribute to the GPL version.
The TCP/IP implementation that was initially used by Linux, that is still part of the basis of that of WIndows, and is obviously the basis for that in Free/Open/NetBSD was BSD (old 3 clause version) licensed.
If it were GPL licensed, it is extremely likely that it would not have been adopted widely as it is because doing so would have been more expensive for proprietary software makers. The 'proof'? Point me at any proprietary network protocol that is implemented as widely as TCP/IP. Why proprietary? because untill recently, there were very few companies even willing to consider using GPL licensed code, and when havign to write their own code anyway, they want to make some money on it directly.
> Makes way for GPL, proprietary and PD, BSD, etc just fine and more so than proprietary protocols. It does recommend GPL though because you can use the foundation itself which is already there. Fact is you want to use push license as much as you whine on GPL zealots. Pot, meet kettle.
Uh?
First of all, you have the source regardless of GPL or BSD.
THe difference CAN be with derived works where you may not get the sources if the original was BSD licensed while you will if it was GPL licensed.
I do not want to push license, and I use both, and I will use what is appropriate for the situation.
Fact is that GPL imposes a restriction which is at times desirable, at times not.
Re:That's exactly the quote I remembered
on
Ethernet at 10 Gbps
·
· Score: 3, Funny
Well.. I wish my compu had less ram... so that a system dump takes a bit shorter..;)
> It's not that software should be free, it's that credit should be given to those who create the code,....
Interestingly enough, that was the exact argument given for the license change of XFree86;P
>.... and when distributed, all code that is under the licence should be made available to those who use the software.
And the difference is in believing that last little bit, not in if credit should be given.
> No the GPL doesn't always fit with people's intentions, but neither does the BSD licence (not that I'm saying you said it did). Some people aren't comfortable with allowing code they write and distribute "freely" to be used by people who don't have the same values in regards to software.
Which is really fine, use what you think best for your situation.
I have used both, and am likely to keep usign both, depending on what I am making.
I may find it more important that everyone, proprietary or not, can use some kind of interface, and I want to encourage peopel in doing so.. a BSD license achieves that much better then the GPL.
I may also find it more important that things derived from my work are available to me and others, and I will use the GPL.
Both happen.
The problem is some people on both sides believign that their way of doign is the only possible way.. well, just like with programming languages.. there is no silver bullet.
> Some distros suck at recognizing some configurations, while another distro will recognize it without problems. A pain in the butt, but go figure.
Which of course is somewhat interestign seeign how the actual drivers are part of Linux and not added by the distribution normally.. Of course it is upto the distribution what they enable by default and how.
> You didn't mention which distro(s) you tried, but first try the Knoppix live CD here or here. Its hardware recognition is very good and if it recognizes your hardware, it takes about 20 minutes to install to your hard drive (YMMV).
Interestingly, when I personally tried Knoppix early this year, the most recent version failed to recognize: - my broadcom onboard gigabit ethernet chipset - any usb device whatsoever
I still have to see the broadcom chipset work correctly with Linux, I did get USB to work.
Booting from a FreeBSD 5.2 live CD on the other hand got all hardware recognized (not configured in all cases, it didn't contain sane or such for the scanner which I happen to have)
> Regarding printers. Some printers are better supported under Linux than others. Go here to see how well your printer is supported. Go here for more help.
How well a printer is supported has usually more to do with what features of a printer you can use, not with failure of the system to recognize that a printer is connected to a usb port.
> Check your scanner compatibility here. And find more help here.
That is the most tricky one, alltho the usb drivers should be able to tell that I have an usb scanner connected even if it is unable to actually do somethign with the device. This is simply a consequence of how USB works.
> If you still can't get Linux to work, stick with windows, it's not that bad.
I suggest trying FreeBSD instead (that is, if you wat a Unix like environment and want a better chance of 'supported' hardware actually workign out of the box)
> The root problem is that FreeBSD suffers from a couple of serious process flaws
Just wondering... what the fuck does this have to do with them moving to X.org?
> Furthermore the license allows proprietary software to "steal" source code and use it. The combination of these problems leads to a somewhat inferior OS.
Ah, all clear, GPL zealot. GO push your agenda somewhere else if you do not have any relevant information to add.
I know who owns hotmail, and I know that their backend mail servers and webservers are running a different OS. I also know that netcraft only tells you what the webserver is running. I'll leave the rest to you.
I suggest you google around a bit for 'hotmail operating system' or such.
> That's not the issue. The problem is that the XFree86 build system is such that to compile one little bit of X the whole of the X source tree has to be rebuilt. Right now, Xorg has that same problem, but its developers are working on fixing it.
That is not entirely true.
First of all, the FreeBSD port of XFree86-4 is split up in multiple seperate parts that can be built independently, Second, I am rather sure I have rebuilt small parts manually after changing some code.
If you want to do it it is rather messy, agreed, but it is far from impossible really. (hint, you can tell the build process to not rebuild all makefiles... that is a very good start towards partial rebuilds, however, you will have to build them at least once to get anythign working at all)
I did this quite a bit in the early days of XFree86 4.0 to test things out. My machien back then was too slow to do full rebuilds for some small changes really.
AT any rate, I agree that the build process is messy, and the whole source tree is messy.
> the FreeBSD ports system will just install both Bar's and confuse you. Then you uninstall Bar v1.0 and it breaks everything that compiled against it.
Well, except for the fact that it won't install bar 1.1 normally, rather, it will tell you that an older version of bar is already installed, and give a suggestion about how to upgrade it.
Exceptions to this exist there where bar 1.0 and 1.1 can coexist peacefully and where there would be a good reason for them to coexist.
Re:BETTER QUESTION: Why do we even need FreeBSD?
on
FreeBSD Moves to X.Org
·
· Score: 4, Insightful
> See it's only these silly amateurs who think BSD is so freaking exciting.
And with that one comment you have proven yourself to be utterly and completely clueless with regards to the subject.
*BSD is not about being exciting, it is about doing its job well. That is very boring actually, nothing exciting there.
> Linux has superior support for USB
Since when? Linux USB support is such an amazingly horrible hack that it is surprising it does anything at all. I suggest you go read the source instead of posting bullshit.
only on very recent Linux versions things like my USB mouse and sd card reader started working (2.6 series kernel on gentoo) while it has worked out of the box on FreeBSD for the last 3 or 4 years at least.
> Linux actually has journaling filesystems so you don't lose files in a crash where as BSD still fails to have one,
Hrm, there exists a JFS implementation for BSD, but I would not use that for any production work. More promissing sounds the porting of XFS.
At any rate, Reiser has caused me way more problems then FFS ever did (while I have a lot more data on FFS)
I hear the same from everyone here who has seriously tried both.
Besides, you seem to be a bit clueless once more.. journaling filesystems do not prevent data loss, they prevent situations where your data and meta data is out of sync, and they provide for a rollback to resync those in case they do end up being out of sync still.
You can still lose data with that, but you will not get a filesystem that is in a inconsistant state... normally.
Now, unlike traditional ufs and filesystems like ext2fs, the FFS filesystem does not write data and metadata asynchroneously, so the inconsistancy between those two is extremely unlikely.
That said, a production quality journalling filesystem would be nice to have
I'd rather want to have FFS2 snapshop functionality to go with that tho.
> RPM hell only existed on distros that used RPM and even then it has been fixed for years with tools like urpmi, up2date and yum.
Last time I checked RPM is part of the LSB but you are right here, it is not used by every distro, and not even part of "Linux" itself.
Re:BETTER QUESTION: Why do we even need FreeBSD?
on
FreeBSD Moves to X.Org
·
· Score: 0, Flamebait
> Listen: Freebsd is for amateur tinnkerers and college kids.
So Yahoo and hotmail are college kids?
> Only some old fart who started working in the 90s would still use BSD for anything important.
Lets turn that around, only people who have too little experience workign would skip on it.
> The last time FreeBSD was ahead of linux in anything was what? 1996? maybe 1998?
2004 actually, but never mind, you have your mind set already anyway.
> Name anything freebsd actually does better than linux? There is never anything specific basked up by facts. It's always just some "well it's like more robust or something..."
Yeah, some crap which is incidentely believed by for example Juniper and other makers of routers, Yahoo and such.. I'm sure they love wasting their money on such things.
> crap which means nothing and is not even true. BSD is running on fumes of hype right now, once people wake up and realize it sucks it will be all done.
You know what? go stick your head in a pig or something.. (not that it matters really, you don't seem to be able to use it anyway)
Re:BETTER QUESTION: Why do we even need FreeBSD?
on
FreeBSD Moves to X.Org
·
· Score: 4, Insightful
> Why do we even need FreeBSD when we have Linux? The developers of FreeBSD should abandon it and migrate over to Linux.
Because WE NEED CHOICE.
There is no reason whatsoever to turn Linux into the enxt monoculture, that in fact is one of the most important things to prevent.
Besides the fact that FreeBSD is better at specific things, but you as home linux zealot are extremely unlikely to have a need for those else you'd have known about them already and not have asked this utterly stupid question.
If I derive from a GPLed work, my work is automatically GPLed as well, not only the parts that I used from the GPLed work, but also those parts that I added.
This is why it is considered viral, and is a desired effect of the GPL.
Completely wrong, it is THE ONLY REASON why different operating systems, OSS or not, speak the same protocols on the internet.
> This weakness made it possible for IBM, Sun, HP, etc. to proprietize Unix and make many incompatible versions that only run on their hardware.
You may not like that, BSD people actually like that, but it has nothign whatsoever to do with right/wrong untill the moment you have the agenda to make all software "free". An agenda some GPL zealots have, most BSD peopel have not.
> I'm in the legally blind group, but thankfully my vision was correctable with lenses.
So am I, but my vision is only partially correctable.
> (I have learned to rely on hearing quite a bit though... I can tell about how far a wall is away from the way sound bounces, and I can hear when a cup is full.)
Heh, yep.. and from walkign around with people, I notice I am far more aware of traffic around us regardless of it being visible from where we are standing etc.
> I really wished I had periferal vision, which contacts won't work for someone like me, so it's on my TODO list, but I've come to love my vision. I've formed some interesting things in my head from the experience though. I really don't judge people by how they look, and don't really understand all the "Am I hot?" BS. In exchange for that though, my bad habbit is to judge people by how they sound, which I'm trying to not do.
The way people speak gives away a lot more then they realize. Part of the issue here is that when not seeing well, you lack the information from facial expression, which most people compensate by what they hear in someones voice and way fo expressing.
I've found that combining those can give you a very nice edge when negotiating things;)
At any rate.. with regards to Linux and DOS... both were designed without realtime operations in mind.. DOS just doesn't get in the way, Linux may, depending on use. I've seen the problems you describe, and yet I've also seen it work rather reliably, and not just on ultra fast machines either.
FreeBSD supports posix realtime scheduling, and depending on the latency that is acceptable for your application, that may or may not do. But you are right of course that QNX or a 'real' realtime OS would be the better choice for controlling such a device..
On the other hand, I'd be very surprised if the actual realtime control isn't handled by a microcontroller in the device itself, under guidance of a slightly less 'realtime' PC.
Slashdot Mirror
> Actually, ext3 does prevent data loss in full data journalled mode.
And? that still doesn't prevent incomplete writes. WHen you lose power in the muiddle of a write, that write is hosed, completely regardless of what filesystem you use.
> Also, a journalled FS will only ever have to roll back at most one transaction to recover; under all normal circumstances, not even that is neccecary as transactions can be replayed instead of undone.
As already mentioned, when you lose power in the middle of the actual write, that write is incomplete. You cannot replay an incomplete write.
This is also the only situation where ffs will ever lose data, so the difference is virtually none with regards to this.
A big difference is that neither ext3fs or reiser have to do a time consuming filesystem check to detect and recover from such things whereas ffs needs a fsck which takes its time usually (not much of a problem in FreeBSD 5.x due to snapshots and background fsck)
Well, I should try again then with a more recent kernel maybe.
> I've read the source and I disagree, if you can pick up anything in particular then fine but you don't beat flames with more flames. My USB stuff worked fine in 2.4 so I'm assuming you're annoyed with the parents flamish tones, which I can agree with.
Well, as mentioned elsewhere, untill 2.6, it did not manage to properly use my mouse and sd card reader. Judging from people around me as well as what I am reading on here and the rest of the web, I am far from unique in having had such problems.
Both devices work with a generic kernel on FreeBSD 4.x and 5.x.
Of course that doesn't say much about the quality of the source code, I cannot point at one specific file that 'sucks', but while reading it and trying to fix it, I found the code very unfriendly to work with. (I have made private changes to both Linux and FreeBSD, and have the skills for it)
At any rate, it wasn't an unfounded flame or such, but my experience and an opinion based on it.
> Agreed, however FFS is a lot more mature than reiser so not entirely unexpected.
True, you'd think tho that ufs has at least the same level of maturity.. (point being that the reliability of ffs is a result of a few design decisions more then anything)
Xorg...... what does that sound like...
Ah.. Borg of course.
> Enhance it a bit, add your own logos,
Yes.
> claim it as your own work and sell it back to me even
No.
> There's really nothing wrong with the license, despite what the GNU team thinks.
I do not see them saying it is wrong, I see them saying it is incompatible with the GNU GPL.
To quote their statement on it:
"This is a simple, permissive non-copyleft free software license, incompatible with the GNU GPL because of its requirements that apply to all documentation in the distribution that contain acknowledgements."
They believe it is a very bad idea to make licenses incompatible with the GPL, but there it ends. If GPL compliance is not relevant for you (as it is in the case of *BSD) there is no issue (well, except when you are called Theo maybe).
A much better reason to move to X.org is that it quite looks like most development moved to X.org as well.
> They changed it to the same license that the rest of FreeBSD uses.
Oh really?
The XFree86 1.1 license has an advertisement clause, the new BSD license (which is what Free/Net/OpenBSD use) does not, so it is definitely not the same.
> Its not like BSD has a GPL-compatibility requirement like Debian does
That is true, and I doubt this was the issue here really.
> So it performs poorly, but it can "scale". Do you happen to work for Sun Micro?
Considering the concept was used on 68k machines and was quite able to handle dozens of phone lines in realtime (something I have done with such hardware and software), I'd say it doesn't perform poorly, it does however have more overhead then for example a monolythic kernel with a unix style userland even when both concepts are perfected as far as technically feasable.
> That's not the desirable effect and also such proprietary situation was already existing before GIFT [my example] even started
:)
Uh, this effect is quite desirable according to
those people in their copy-left argument. Note, it is an effect desired by the people who wrote that license, and often by those who use it. If that applies to you personally is another matter.
> You're contradicting yourself. If you license your code under the GPL and the BSD license while you don't want to push licenses, you are pushing a license with the GPL by putting your code under the GPL.
Uh? that is not about pushign a license but about wanting a specific result for the code I wrote.
> You try to push it as a rule of thumb for protocols. As i argumented, not by definition true. Sometimes GPL code can't even used on a different platform. I really depends on the situation, and i don't see how Samba or GIFT would be more succesful when they were BSD licensed.
This is entirely because the original implementation is not licensed in a way that allows you to reuse its source code (even if you do have access to it)
The situation would be entirely different when the original implementations were available with a GPL or BSD license or similar. For a free software developer it wouldn't matter much which as logn as it would be compatible with his/her license of choice, but to proprietary software makers it would matter.
Releasing Samba with a BSD license would allow SCO to stick a modified version into their unix versions with help of MS and never make the changes available.. this would obviously not help anyone
At any rate.. the situation can be different when you are re-implementing an already existing proprietary protocol, but for newly developed protocols, I'd definitely decide on a BSD style license for a reference implementation if I want it to be widely used (and not just in Linux)
> A real technical decision, on pure merit, wouldn't have chosen BSD/Mach in the late 90s. MacOS X is one of the worst performing OSes on the market (which fortunately doesn't matter much for Ghz desktop boxes).
Hmm. a real technical decision, on pure merit.. that would include a lot more then raw performance (or better said, lack of overhead).
A big advantage of mach and similar kernels is that all IPC is message based, which prevents the need for locking. This makes it really easy to scale it to more parallel environments and prevents quite a bit of complicated and bug prone code.
> I haven't seen an official statement from Apple on this, but I believe OS X as we know it is possible only on a BSD foundation for legal, rather than technical, reasons. This is why--if I'm right--you will never see the OS X core moved to a Linux distro.
I believe this has more then just legal reasons. It probably has a lot to do with Apple buying NeXT, which was using a BSD style userland on a microkernel... not that different from OS X in setup, and had been doing that way before Linux would have been a viable alternative.
So they have the skills and experience and had a setup that worked but needed a more modern userland while they wanted to concentrate on the gui.. Those things together would for me result in one option only (tho NetBSD and OpenBSD are catching up, for a while their userland felt like that of FreeBSD from half a decade ago.. and to many of your Linux people, the FreeBSD one probably already looks somewhat achaic..
At any rate.. I doubt there are technical reasons to use one or the other that are very relevant to Apple, in either case they won't be using the kernel, and the kernel is where most of the technical differences between Linux and FreeBSD are. A FreeBSD userland is organized differently from a Linux one (usually that is... with the 100+ linux distributions you can no doubt find oen that is almost identical..) and the legalities are different. From what I know you do get things like gcc with OS X so well.. the legalities of the GPL itself don't stop them it seems.. maybe that is different for things in their core OS? I somehow doubt it.. so I end up with their past experience, directly available skills and cost being the main arguments.
> Silly wabbit! They don't. Many proprietary protocols, GPL protocols, etc have been cloned or reverse engineered even when they were standard. However not ALL. With GPL, one is able to port say GIFT to a proprietary UNIX and run it there. Voila, not any harder than that the software was BSD licensed.
Yes it is harder because you can directly use the BSD code while you can only do that with the GPL code if you are willing to publish your source with the binaries. That is a desirable effect maybe, but those who want to keep their software proprietary disagree. Result, they can directly use BSD code, they can only indirectly use GPL code.
> To say TCP/IP never happened with one GPL implementation is a statement which isn't based on any solid grounds. The source is open, so people are at least able to learn from it if they don't wanna contribute to the GPL version.
The TCP/IP implementation that was initially used by Linux, that is still part of the basis of that of WIndows, and is obviously the basis for that in Free/Open/NetBSD was BSD (old 3 clause version) licensed.
If it were GPL licensed, it is extremely likely that it would not have been adopted widely as it is because doing so would have been more expensive for proprietary software makers. The 'proof'? Point me at any proprietary network protocol that is implemented as widely as TCP/IP. Why proprietary? because untill recently, there were very few companies even willing to consider using GPL licensed code, and when havign to write their own code anyway, they want to make some money on it directly.
> Makes way for GPL, proprietary and PD, BSD, etc just fine and more so than proprietary protocols. It does recommend GPL though because you can use the foundation itself which is already there. Fact is you want to use push license as much as you whine on GPL zealots. Pot, meet kettle.
Uh?
First of all, you have the source regardless of GPL or BSD.
THe difference CAN be with derived works where you may not get the sources if the original was BSD licensed while you will if it was GPL licensed.
I do not want to push license, and I use both, and I will use what is appropriate for the situation.
Fact is that GPL imposes a restriction which is at times desirable, at times not.
Well.. ;)
I wish my compu had less ram... so that a system dump takes a bit shorter..
> It's not that software should be free, it's that credit should be given to those who create the code, ....
;P
.... and when distributed, all code that is under the licence should be made available to those who use the software.
Interestingly enough, that was the exact argument given for the license change of XFree86
>
And the difference is in believing that last little bit, not in if credit should be given.
> No the GPL doesn't always fit with people's intentions, but neither does the BSD licence (not that I'm saying you said it did). Some people aren't comfortable with allowing code they write and distribute "freely" to be used by people who don't have the same values in regards to software.
Which is really fine, use what you think best for your situation.
I have used both, and am likely to keep usign both, depending on what I am making.
I may find it more important that everyone, proprietary or not, can use some kind of interface, and I want to encourage peopel in doing so.. a BSD license achieves that much better then the GPL.
I may also find it more important that things derived from my work are available to me and others, and I will use the GPL.
Both happen.
The problem is some people on both sides believign that their way of doign is the only possible way.. well, just like with programming languages.. there is no silver bullet.
> Some distros suck at recognizing some configurations, while another distro will recognize it without problems. A pain in the butt, but go figure.
Which of course is somewhat interestign seeign how the actual drivers are part of Linux and not added by the distribution normally.. Of course it is upto the distribution what they enable by default and how.
> You didn't mention which distro(s) you tried, but first try the Knoppix live CD here or here. Its hardware recognition is very good and if it recognizes your hardware, it takes about 20 minutes to install to your hard drive (YMMV).
Interestingly, when I personally tried Knoppix early this year, the most recent version failed to recognize:
- my broadcom onboard gigabit ethernet chipset
- any usb device whatsoever
I still have to see the broadcom chipset work correctly with Linux, I did get USB to work.
Booting from a FreeBSD 5.2 live CD on the other hand got all hardware recognized (not configured in all cases, it didn't contain sane or such for the scanner which I happen to have)
> Regarding printers. Some printers are better supported under Linux than others. Go here to see how well your printer is supported. Go here for more help.
How well a printer is supported has usually more to do with what features of a printer you can use, not with failure of the system to recognize that a printer is connected to a usb port.
> Check your scanner compatibility here. And find more help here.
That is the most tricky one, alltho the usb drivers should be able to tell that I have an usb scanner connected even if it is unable to actually do somethign with the device. This is simply a consequence of how USB works.
> If you still can't get Linux to work, stick with windows, it's not that bad.
I suggest trying FreeBSD instead (that is, if you wat a Unix like environment and want a better chance of 'supported' hardware actually workign out of the box)
> The root problem is that FreeBSD suffers from a couple of serious process flaws
Just wondering... what the fuck does this have to do with them moving to X.org?
> Furthermore the license allows proprietary software to "steal" source code and use it. The combination of these problems leads to a somewhat inferior OS.
Ah, all clear, GPL zealot. GO push your agenda somewhere else if you do not have any relevant information to add.
I know who owns hotmail, and I know that their backend mail servers and webservers are running a different OS. I also know that netcraft only tells you what the webserver is running. I'll leave the rest to you.
I suggest you google around a bit for 'hotmail operating system' or such.
> That's not the issue. The problem is that the XFree86 build system is such that to compile one little bit of X the whole of the X source tree has to be rebuilt. Right now, Xorg has that same problem, but its developers are working on fixing it.
That is not entirely true.
First of all, the FreeBSD port of XFree86-4 is split up in multiple seperate parts that can be built independently, Second, I am rather sure I have rebuilt small parts manually after changing some code.
If you want to do it it is rather messy, agreed, but it is far from impossible really. (hint, you can tell the build process to not rebuild all makefiles... that is a very good start towards partial rebuilds, however, you will have to build them at least once to get anythign working at all)
I did this quite a bit in the early days of XFree86 4.0 to test things out. My machien back then was too slow to do full rebuilds for some small changes really.
AT any rate, I agree that the build process is messy, and the whole source tree is messy.
> the FreeBSD ports system will just install both Bar's and confuse you. Then you uninstall Bar v1.0 and it breaks everything that compiled against it.
Well, except for the fact that it won't install bar 1.1 normally, rather, it will tell you that an older version of bar is already installed, and give a suggestion about how to upgrade it.
Exceptions to this exist there where bar 1.0 and 1.1 can coexist peacefully and where there would be a good reason for them to coexist.
> See it's only these silly amateurs who think BSD is so freaking exciting.
And with that one comment you have proven yourself to be utterly and completely clueless with regards to the subject.
*BSD is not about being exciting, it is about doing its job well. That is very boring actually, nothing exciting there.
> Linux has superior support for USB
Since when? Linux USB support is such an amazingly horrible hack that it is surprising it does anything at all. I suggest you go read the source instead of posting bullshit.
only on very recent Linux versions things like my USB mouse and sd card reader started working (2.6 series kernel on gentoo) while it has worked out of the box on FreeBSD for the last 3 or 4 years at least.
> Linux actually has journaling filesystems so you don't lose files in a crash where as BSD still fails to have one,
Hrm, there exists a JFS implementation for BSD, but I would not use that for any production work. More promissing sounds the porting of XFS.
At any rate, Reiser has caused me way more problems then FFS ever did (while I have a lot more data on FFS)
I hear the same from everyone here who has seriously tried both.
Besides, you seem to be a bit clueless once more.. journaling filesystems do not prevent data loss, they prevent situations where your data and meta data is out of sync, and they provide for a rollback to resync those in case they do end up being out of sync still.
You can still lose data with that, but you will not get a filesystem that is in a inconsistant state... normally.
Now, unlike traditional ufs and filesystems like ext2fs, the FFS filesystem does not write data and metadata asynchroneously, so the inconsistancy between those two is extremely unlikely.
That said, a production quality journalling filesystem would be nice to have
I'd rather want to have FFS2 snapshop functionality to go with that tho.
> RPM hell only existed on distros that used RPM and even then it has been fixed for years with tools like urpmi, up2date and yum.
Last time I checked RPM is part of the LSB but you are right here, it is not used by every distro, and not even part of "Linux" itself.
> Listen: Freebsd is for amateur tinnkerers and college kids.
So Yahoo and hotmail are college kids?
> Only some old fart who started working in the 90s would still use BSD for anything important.
Lets turn that around, only people who have too little experience workign would skip on it.
> The last time FreeBSD was ahead of linux in anything was what? 1996? maybe 1998?
2004 actually, but never mind, you have your mind set already anyway.
> Name anything freebsd actually does better than linux? There is never anything specific basked up by facts. It's always just some "well it's like more robust or something..."
Yeah, some crap which is incidentely believed by for example Juniper and other makers of routers, Yahoo and such.. I'm sure they love wasting their money on such things.
> crap which means nothing and is not even true. BSD is running on fumes of hype right now, once people wake up and realize it sucks it will be all done.
You know what? go stick your head in a pig or something.. (not that it matters really, you don't seem to be able to use it anyway)
> Why do we even need FreeBSD when we have Linux? The developers of FreeBSD should abandon it and migrate over to Linux.
Because WE NEED CHOICE.
There is no reason whatsoever to turn Linux into the enxt monoculture, that in fact is one of the most important things to prevent.
Besides the fact that FreeBSD is better at specific things, but you as home linux zealot are extremely unlikely to have a need for those else you'd have known about them already and not have asked this utterly stupid question.
And you are an anonymous idiot.
If I derive from a GPLed work, my work is automatically GPLed as well, not only the parts that I used from the GPLed work, but also those parts that I added.
This is why it is considered viral, and is a desired effect of the GPL.
> Wrong it is a very bad weakness.
Completely wrong, it is THE ONLY REASON why different operating systems, OSS or not, speak the same protocols on the internet.
> This weakness made it possible for IBM, Sun, HP, etc. to proprietize Unix and make many incompatible versions that only run on their hardware.
You may not like that, BSD people actually like that, but it has nothign whatsoever to do with right/wrong untill the moment you have the agenda to make all software "free". An agenda some GPL zealots have, most BSD peopel have not.
> I'm in the legally blind group, but thankfully my vision was correctable with lenses.
;)
So am I, but my vision is only partially correctable.
> (I have learned to rely on hearing quite a bit though... I can tell about how far a wall is away from the way sound bounces, and I can hear when a cup is full.)
Heh, yep.. and from walkign around with people, I notice I am far more aware of traffic around us regardless of it being visible from where we are standing etc.
> I really wished I had periferal vision, which contacts won't work for someone like me, so it's on my TODO list, but I've come to love my vision. I've formed some interesting things in my head from the experience though. I really don't judge people by how they look, and don't really understand all the "Am I hot?" BS. In exchange for that though, my bad habbit is to judge people by how they sound, which I'm trying to not do.
The way people speak gives away a lot more then they realize. Part of the issue here is that when not seeing well, you lack the information from facial expression, which most people compensate by what they hear in someones voice and way fo expressing.
I've found that combining those can give you a very nice edge when negotiating things
At any rate.. with regards to Linux and DOS... both were designed without realtime operations in mind.. DOS just doesn't get in the way, Linux may, depending on use. I've seen the problems you describe, and yet I've also seen it work rather reliably, and not just on ultra fast machines either.
FreeBSD supports posix realtime scheduling, and depending on the latency that is acceptable for your application, that may or may not do. But you are right of course that QNX or a 'real' realtime OS would be the better choice for controlling such a device..
On the other hand, I'd be very surprised if the actual realtime control isn't handled by a microcontroller in the device itself, under guidance of a slightly less 'realtime' PC.