Look at the release notes for each of the test#-pre patches, there is a *ton* of fixes going in.
Linus isn't going for the "it works perfect on the most used hardware" stability - he wants stability accross the board as much as possible. There is alot of technical improvements for large and low memory boxes going in as well as SMP improvements among other non-standard-box items.
The BSD* SMP push has not been to get farther ahead, but rather to catch up to what Linux already has in stable kernels. I know 2.2 SMP isn't perfect, but it's still pretty damn good for what my boxes do.
Yes, I have heard the phrase, and I agree with it but am completely at a loss about what you hope to gain by saying things that are so completely in the realm of FUD.
Hell, I know FreeBSD admins who wouldn't in their wildest dreams imagine telling me their favorite OS has better RAID or SMP support. That's why even though it's their networks, when the boxes need those features they bring me in to work on it with them.
The 2.4 implimentation of SMP is amazing, it's improved in so many ways it's not even funny.
I am interested in what the freeBSD 5 implimentation may be doing so right, got any links/pointers for me? I honestly would like to be able to read up on it further.
Would this be like saying the air you breath is the same air those evil people with different values than you are surviving off as well so obviously a boycot is the best way to protest?
Man, if only people like you could follow through on your logic by testing your actions out, hell of a lot less morons running around.
The upgrade process is beyond simple and cuts way down on your administration requirements. Get squid running and don't mess with crappy upgrades like RH #.buggy;)
Moron - this isn't 65,000 in bugs, and this isn't just the Windows and base OS either (er, and web browser). That 65k was in WINDOWS ALONE.
Complain about something that doesn't make you look like an idiot please - what is it with all these people who think Slashdot is *always* forgiving of Linux and harsh on MS under the same scenario? Pay attention, the scenarios are never the same.
I didn't mean to underestimate or underappreciate any of the developers skills and work, what I meant was to look at it from a often overlooked point of view. Basicaly I think Linus and a few of the first developers wanted to pick something that had so many possible places they could contribute and learn form developing.
Take the same quality coder today (remember, Linus started Linux to *learn* the x86) and give them a choice between trying to improve on IBM's code, and trying to improve or port IBM's stuff to one of the *BSDs or perhaps just develop a feature in another free OS' code. That's the view I was trying to get at.
I agree taking companies altruistic statements at face value isn't good - but I don't believe IBM is making those types of statements here. In the article the IBM guy makes it very clear that isn't a "because it's a good thing to do for people and warm fuzzies" kind of argument for Linux, it's blatently obvious the open source movement and Linux are solid business decisions for IBM.
I think it's important people try out the view that no, the largest benifit of open source and linux is not that "it's simply not Microsoft" - it is justified because is the fastest developing operating system out there, period.
And considering it doesn't show any hint of slowing anytime soon, there isn't a chance anybody can pass it. There also isn't a chance that anybody, microsoft or no can keep their technological or GUI advantage forever. The pace of development is one of the magic hidden benifits that you can't quantify, given time it's impact will be even more prominent.
If IBM walked in tomorow and changed over half of the Linux kernel code that has to do with reliability and speed for major improvements, wouldn't that get a large number of people saying it's not Linus' and co's Linux aymore?
They are being smart about working with Linus and friends into moving towards a better Os technicaly. I think we can expect to see some serious improvements over the next 6 months because of IBMs involvement.
Besides, have you ever read Linus' first few USEnet announcements for the early, EARLY code? One of them was talking about how it was great to work on something that needed so much work - in other words, it was attractive to the early developers because they could pick anything they wanted to work on and odds were they had the skills to develop it further.
At the pace Linux is developing, I could see developers jumping ship to go work on something like FreeBSD because they would have the ability to help there, while the Linux kernel may have surpassed their technical abilities.
The poster you replied to raised a good point though. ever though the "Big Iron" support would bog down 486 installs, it should (hopefully) be possible to have configure/compile time options that would completely remove the big iron code from the compiled kernel and you would basicaly have the 486 version running as fast as possible.
There really shouldn't be anything wrong with that (95% of users never use anything but their distro's stock kernel anyway, which would have the big iron support removed before they touched it.)
Code forks are dangerous things when they are done for reasons like this.
From what I understand from the kernel Mailing list and others I have spoken with, the reason big iron support is not getting into the mainstream parts of the kernel is because IBM has not made it a configurable option - it's been proposed as schedule and memory changes in the main parts of the kernel which I agree would be bad.
I don't think it will be long before IBM changes the policy and it' sall good;)
The point is the kit is just a tool to create the binaries, SUN isn't distributing binaries for anything without code.
It's like saying that a gcc compiler *could* be used to create a binary that a user could distribute in a way that the GPL would not allow, so the creators of gcc are breaking the GPL.
Freak people, the kit does not contain binaries without the GPL'ed code. It's just a tool to create Solaris binaries, there ISN'T ANY PROBLEM WITH THAT.
Even if people take the generated code and staticly enter it into the kernel (people, not SUN) then SUN hasn't screwed up, the people using their kit have.
I really appreciate the answer, alot of good info in there on OpenBSD's abilities. I just have a few comments... (NOTE: my comments are about the 2.4 series, alot of these abilities are new)
1. Linux *does* allow multiple port matching.
2. Linux *does* allow you to redirect to another machine, you are no longer restricted to localhost (under 2.2 you can as well with 3rd party utils which I hated because they sucked.)
3. Host mapping is *not* a problem under 2.4
(I know how useful the redirection can be, that DNS task of yours would be hell without it.)
4. Connection State Matching is possible in Linux.
5. Rate blocking: I *think* so. I would have to look a bit more before being able to say for sure though... the limit match helps on this, but I don't think it does what you wanted it to - but there may be something else.
To help, here is a simple list on the basic options included in the "make menuconfig" under 2.4 for NAT/filtering/MASQ decisions:
limit match, MAC, netfilter MARK, multiple port support, TOS match, connection state match, unclean match, owner match
Packet Filtering Targets: REJECT, MIRROR
Full NAT Targets: MASQUERADE, REDIRECT
Packet Mangling: TOS, MARK
In summary, I know about the limitations you were discussing - at least in regards to the 2.2 series. What I would like to know, is what does *BSD have over the 2.4 Linux Kernel (which I have running on 7 production machines WITHOUT a single hickup) with regards to router functionality?
I should also point out that though I am a fan of Linux, I would use Win2k before I would use RedHat and I believe in using the best tools for the job at hand. (Yes, even if the best tool is Win95 or FreeBSD *shudder*)
So, once again, anyone want to please explain why someone would use OpenBSD over Linux (to clarify, 2.4) as a router? (please avoid the security arguments, that's a whole different can of worms.)
-Nathan
Re:i believe the children R our future-teachem wel
on
Hackers And Mysticism?
·
· Score: 1
Those quotes work very well for 95% of the Christian based Religions, and not very well for Magic and wicca (in general, even witchcraft has it's psychos).
If I am understanding you, if it's Magic, it has to be advanced tech - fair enough, that's basicaly the point. However, if A = B, does A stop being a condition?
I am going to get a friggin' headache form that. Stupid circles.
Linux is still missing some features in the mainstream Kernel for C2.
Auditing & ACL...
I know you can do ACL's swith special setups - I am talking about the core Kernel source.
C2 is crap anyway, what Linux could use is the LSB putting out some requirements for security based configurations by default where you would have to open something up to get nailed by it.
(OpenBSD people -all three of you-, I know you have that now, I don't care. If the system can't do anything but be tight, then it's useless anyway. Got SMP?)
At any rate, does anyone know the status of the work SGI is doing for the B level certs in the Kernel?
>Why Linux lacks the most, as compared to the *BSD (especially the OpenBSD) is the AUDIT, both in security and in scalability contexts.
OpenBSD's AUDIT is crap. Their code base doesn't grow at 1/100th of the speed Linux's does. Not only that, but they have never finished the audit, it's just one of those forever "work in progress" things (unless some miracle has happened since my last review of Open BSD).
OpenBSD is a nitch OS for security only, any requirements beyond that are always better served by another *BSD or Linux.
By the way, Linux comes secure to damnit (box must be delivered turned off for Linux, just like all the abilities are in OpenBSD.)
The idea is to present one set of instructions to the Morphing engine, then have the freedom to change whatever they need to on the underlying chip and it's instruction set(s).
That seems like more of a bonus to me than being able to stare at a MacOSvapor bootup screen;)
Linus has stated (I believe around the time he got his butt kicked in Quake at the initial demo) that they don't even "want" people to port the OS to the underlying chip.
Slashdot Mirror
Look at the release notes for each of the test#-pre patches, there is a *ton* of fixes going in.
Linus isn't going for the "it works perfect on the most used hardware" stability - he wants stability accross the board as much as possible. There is alot of technical improvements for large and low memory boxes going in as well as SMP improvements among other non-standard-box items.
-Nathan
The SMP implimentation under 2.2 kicks BSD* ass.
Right now, it's not even close.
The BSD* SMP push has not been to get farther ahead, but rather to catch up to what Linux already has in stable kernels. I know 2.2 SMP isn't perfect, but it's still pretty damn good for what my boxes do.
Yes, I have heard the phrase, and I agree with it but am completely at a loss about what you hope to gain by saying things that are so completely in the realm of FUD.
Hell, I know FreeBSD admins who wouldn't in their wildest dreams imagine telling me their favorite OS has better RAID or SMP support. That's why even though it's their networks, when the boxes need those features they bring me in to work on it with them.
The 2.4 implimentation of SMP is amazing, it's improved in so many ways it's not even funny.
I am interested in what the freeBSD 5 implimentation may be doing so right, got any links/pointers for me? I honestly would like to be able to read up on it further.
-Nathan
And there is a problem with someone being able to give a final answer?
The only thing BSD has going for it are the people who just can't let yesteday go...
Oh, and you are dead wrong about the devel speed of BSD being faster than Linux - I can't actualy figure out what logic you are twisting to say it.
So, SMP in OpenBSD tomorow? Oh wait, it's still in the "some people are interested in trying it" phase. Good thing there are multiple trees!
-Nathan
Would this be like saying the air you breath is the same air those evil people with different values than you are surviving off as well so obviously a boycot is the best way to protest?
Man, if only people like you could follow through on your logic by testing your actions out, hell of a lot less morons running around.
Sorry, I completely disagree with you.
/dev/null
I prefer wireless linux-driven network information over the repetitive mega-cool/atari-handheld stuff.
Gee, Slashdot posting things that are not incredibly interesting for every single reader?
Wah.
The Slashdot guys do a decent job of getting interesting stuff - no filter is perfect.
cat Flame.didntmeanto >
Ok, so some filters are perfect.
One tenth of the development effort generaly means one tenth of the actual development which usualy means a heck of alot easier to avoid bugs.
;)
Think about it - if your development is x10, then shouldn't your bugs be at least x4 of who you are comparing yourself to?
RedHat improves over time and gets out regular releases. hell run down a list of *other* compliments given to Microsoft and see how many apply
Apples to oranges?
You mean QNX to Windows?
Or do you mean QNX to Linux, per chance?
I'm sorry, were you trying to be funny when you made yourself look like an idiot for doing what you were complaining about, or was that an accident?
None of the above.
;)
Use Debian - it rocks as a squid server.
The upgrade process is beyond simple and cuts way down on your administration requirements. Get squid running and don't mess with crappy upgrades like RH #.buggy
Moron - this isn't 65,000 in bugs, and this isn't just the Windows and base OS either (er, and web browser). That 65k was in WINDOWS ALONE.
Complain about something that doesn't make you look like an idiot please - what is it with all these people who think Slashdot is *always* forgiving of Linux and harsh on MS under the same scenario? Pay attention, the scenarios are never the same.
I didn't mean to underestimate or underappreciate any of the developers skills and work, what I meant was to look at it from a often overlooked point of view. Basicaly I think Linus and a few of the first developers wanted to pick something that had so many possible places they could contribute and learn form developing.
Take the same quality coder today (remember, Linus started Linux to *learn* the x86) and give them a choice between trying to improve on IBM's code, and trying to improve or port IBM's stuff to one of the *BSDs or perhaps just develop a feature in another free OS' code. That's the view I was trying to get at.
I agree taking companies altruistic statements at face value isn't good - but I don't believe IBM is making those types of statements here. In the article the IBM guy makes it very clear that isn't a "because it's a good thing to do for people and warm fuzzies" kind of argument for Linux, it's blatently obvious the open source movement and Linux are solid business decisions for IBM.
I think it's important people try out the view that no, the largest benifit of open source and linux is not that "it's simply not Microsoft" - it is justified because is the fastest developing operating system out there, period.
And considering it doesn't show any hint of slowing anytime soon, there isn't a chance anybody can pass it. There also isn't a chance that anybody, microsoft or no can keep their technological or GUI advantage forever. The pace of development is one of the magic hidden benifits that you can't quantify, given time it's impact will be even more prominent.
-Nathan
It's simple.
If IBM walked in tomorow and changed over half of the Linux kernel code that has to do with reliability and speed for major improvements, wouldn't that get a large number of people saying it's not Linus' and co's Linux aymore?
They are being smart about working with Linus and friends into moving towards a better Os technicaly. I think we can expect to see some serious improvements over the next 6 months because of IBMs involvement.
Besides, have you ever read Linus' first few USEnet announcements for the early, EARLY code? One of them was talking about how it was great to work on something that needed so much work - in other words, it was attractive to the early developers because they could pick anything they wanted to work on and odds were they had the skills to develop it further.
At the pace Linux is developing, I could see developers jumping ship to go work on something like FreeBSD because they would have the ability to help there, while the Linux kernel may have surpassed their technical abilities.
-Nathan
The poster you replied to raised a good point though. ever though the "Big Iron" support would bog down 486 installs, it should (hopefully) be possible to have configure/compile time options that would completely remove the big iron code from the compiled kernel and you would basicaly have the 486 version running as fast as possible.
;)
There really shouldn't be anything wrong with that (95% of users never use anything but their distro's stock kernel anyway, which would have the big iron support removed before they touched it.)
Code forks are dangerous things when they are done for reasons like this.
From what I understand from the kernel Mailing list and others I have spoken with, the reason big iron support is not getting into the mainstream parts of the kernel is because IBM has not made it a configurable option - it's been proposed as schedule and memory changes in the main parts of the kernel which I agree would be bad.
I don't think it will be long before IBM changes the policy and it' sall good
The point is the kit is just a tool to create the binaries, SUN isn't distributing binaries for anything without code.
It's like saying that a gcc compiler *could* be used to create a binary that a user could distribute in a way that the GPL would not allow, so the creators of gcc are breaking the GPL.
Freak people, the kit does not contain binaries without the GPL'ed code. It's just a tool to create Solaris binaries, there ISN'T ANY PROBLEM WITH THAT.
Even if people take the generated code and staticly enter it into the kernel (people, not SUN) then SUN hasn't screwed up, the people using their kit have.
gaaaahhhhhhhhhhhhhhhhhhhhhh
I really appreciate the answer, alot of good info in there on OpenBSD's abilities. I just have a few comments... (NOTE: my comments are about the 2.4 series, alot of these abilities are new)
1. Linux *does* allow multiple port matching.
2. Linux *does* allow you to redirect to another machine, you are no longer restricted to localhost (under 2.2 you can as well with 3rd party utils which I hated because they sucked.)
3. Host mapping is *not* a problem under 2.4
(I know how useful the redirection can be, that DNS task of yours would be hell without it.)
4. Connection State Matching is possible in Linux.
5. Rate blocking: I *think* so. I would have to look a bit more before being able to say for sure though... the limit match helps on this, but I don't think it does what you wanted it to - but there may be something else.
To help, here is a simple list on the basic options included in the "make menuconfig" under 2.4 for NAT/filtering/MASQ decisions:
limit match, MAC, netfilter MARK, multiple port support, TOS match, connection state match, unclean match, owner match
Packet Filtering Targets: REJECT, MIRROR
Full NAT Targets: MASQUERADE, REDIRECT
Packet Mangling: TOS, MARK
In summary, I know about the limitations you were discussing - at least in regards to the 2.2 series. What I would like to know, is what does *BSD have over the 2.4 Linux Kernel (which I have running on 7 production machines WITHOUT a single hickup) with regards to router functionality?
I should also point out that though I am a fan of Linux, I would use Win2k before I would use RedHat and I believe in using the best tools for the job at hand. (Yes, even if the best tool is Win95 or FreeBSD *shudder*)
So, once again, anyone want to please explain why someone would use OpenBSD over Linux (to clarify, 2.4) as a router? (please avoid the security arguments, that's a whole different can of worms.)
-Nathan
Those quotes work very well for 95% of the Christian based Religions, and not very well for Magic and wicca (in general, even witchcraft has it's psychos).
If I am understanding you, if it's Magic, it has to be advanced tech - fair enough, that's basicaly the point. However, if A = B, does A stop being a condition?
I am going to get a friggin' headache form that. Stupid circles.
This is a good day, a OpenBSD fan who sounds like they know what they are talking about.
Seriously, I am interested in knowing what power ipnat and ipfilter have that IOS and Linux are lacking.
Please expand on that?
Nope, it doesn't look like you care, or know for that matter ;)
No worries. We all have our dilusions *grin*
"usualy" being the key word.
You sounded like way smart there for a second, couldn't you have made it mean something?
Electricity used to be magic, people classify magic as what they don't understand yet.
I don't remember Arthur C. Clark's quote at the moment, must go dig.
I love it when people walk around with their eyes closed screaming that everyone else is blind.
*shakeno*
Linux is still missing some features in the mainstream Kernel for C2.
Auditing & ACL...
I know you can do ACL's swith special setups - I am talking about the core Kernel source.
C2 is crap anyway, what Linux could use is the LSB putting out some requirements for security based configurations by default where you would have to open something up to get nailed by it.
(OpenBSD people -all three of you-, I know you have that now, I don't care. If the system can't do anything but be tight, then it's useless anyway. Got SMP?)
At any rate, does anyone know the status of the work SGI is doing for the B level certs in the Kernel?
-Nathan
>Why Linux lacks the most, as compared to the *BSD (especially the OpenBSD) is the AUDIT, both in security and in scalability contexts.
OpenBSD's AUDIT is crap. Their code base doesn't grow at 1/100th of the speed Linux's does. Not only that, but they have never finished the audit, it's just one of those forever "work in progress" things (unless some miracle has happened since my last review of Open BSD).
OpenBSD is a nitch OS for security only, any requirements beyond that are always better served by another *BSD or Linux.
By the way, Linux comes secure to damnit (box must be delivered turned off for Linux, just like all the abilities are in OpenBSD.)
Laugh dangit.
-Nathan
The underlying instruction set changes too often.
;)
The idea is to present one set of instructions to the Morphing engine, then have the freedom to change whatever they need to on the underlying chip and it's instruction set(s).
That seems like more of a bonus to me than being able to stare at a MacOSvapor bootup screen
Linus has stated (I believe around the time he got his butt kicked in Quake at the initial demo) that they don't even "want" people to port the OS to the underlying chip.