Linux Kernel 2.6.35 Released
eldavojohn writes "Linus has announced the release of 2.6.35 for people to download and test after he found not a lot of changes between this week and last. The big features to look out for include: 'Transparent spreading of incoming network traffic load across CPUs, Btrfs improvements, KDB kernel debugger frontend, Memory compaction and Support for multiple multicast route tables' as well as various performance and graphics improvements. Linus also praised the community saying that 'regression changes only' after rc1 improved this time around and gave numbers to back it up saying 'in the 2.6.34 release, there were 3800 commits after -rc1, but in the current 35 release cycle we had less than 2000.' Good to see the process is becoming more refined and controlled after the first release candidate — hopefully there's no impending burnout."
Wow. The future has arrived.
Way to double-check your article, Timothy.
It says so, with big Caution images all over the linked page.
Love sees no species.
I understand why, but there are a ton of people out there that think OSS is OSS. You wonder why corporations are weary of OSS it's because of this. I really hope this project goes somewhere or Debian's kFreeBSD project works as well as I'm hoping.
Reminds me of this joke:
I was walking across a bridge one day, and I saw a software developer standing on the edge, about to jump off. I immediately ran over and said "Stop! Don't do it!"
"Why shouldn't I?" he said.
I said, "Well, there's so much to live for!"
"Like what?"
"Well ... do you develop Closed Source or Open?"
"Open."
"Me too! Are you BSD or GPL?"
"GPL."
"Me too! Are you GPL v2 or GPL v3?"
"GPL v3!"
To which I said, "Die, heretic scum!" and pushed him off.
2010 will be the year of Linux on the desktop. Eat that M$ and Crapple.
Hello,
As a consultant for several large companies, I'd always done my work on
Windows. Recently however, a top online investment firm asked us to do
some work using Linux. The concept of having access to source code was
very appealing to us, as we'd be able to modify the kernel to meet our
exacting standards which we're unable to do with Microsoft's products.
Although we met several technical challenges along the way
(specifically, Linux's lack of Token Ring support and the fact that we
were unable to defrag its ext2 file system), all in all the process
went smoothly. Everyone was very pleased with Linux, and we were
considering using it for a great deal of future internal projects.
So you can imagine our surprise when we were informed by a lawyer that
we would be required to publish our source code for others to use. It
was brought to our attention that Linux is copyrighted under something
called the GPL, or the Gnu Protective License. Part of this license
states that any changes to the kernel are to be made freely available.
Unfortunately for us, this meant that the great deal of time and money
we spent "touching up" Linux to work for this investment firm would
now be available at no cost to our competitors.
Furthermore, after reviewing this GPL our lawyers advised us that any
products compiled with GPL'ed tools - such as gcc - would also have to
its source code released. This was simply unacceptable.
Although we had planned for no one outside of this company to ever
use, let alone see the source code, we were now put in a difficult
position. We could either give away our hard work, or come up with
another solution. Although it was tough to do, there really was no
option: We had to rewrite the code, from scratch, for Windows 2000.
I think the biggest thing keeping Linux from being truly competitive
with Microsoft is this GPL. Its draconian requirements virtually
guarantee that no business will ever be able to use it. After my
experience with Linux, I won't be recommending it to any of my
associates. I may reconsider if Linux switches its license to
something a little more fair, such as Microsoft's "Shared Source".
Until then its attempts to socialize the software market will insure
it remains only a bit player.
Thank you for your time.
The big features to look out for include: "Transparent spreading of incoming network traffic load across CPUs, Btrfs improvements, KDB kernel debugger frontend, Memory compaction and Support for multiple multicast route tables"
I'm sure most or all of these mean nothing to 99%+ of Linux users. This isn't a big feature release; it's a small incremental improvement release.
Perhaps the people who fear Linus is going to burn out again spent too many years watching Seinfeld and deeply internalized "no hugging, no learning". Linus != George. OTOH, given his acidic tongue, he's probably not well suited to a career in stand up comedy. Anyone else think that Larry McVoy would make a good Kramer? </rimshot>
I suppose if you're a linux fanbois such a minimal increment in kernel nomenclature is a very big deal. Maybe even warrants a slashdot article. (And people say it's Apple's Kool-aid...)
Do we still have to talk about "burnout" every time we mention kernel maintenance?
More than ever.
I worked a defence contract once where the same policy applied. The argument there is they wanted to have somebody to sue when the planes fell out of the sky. by Anonymous Coward on Monday August 02, @12:55AM (#33107066)
Whether you like it or not? See my subject-line above. That IS how the real world really is and especially in business... and, were YOU in their shoes, would you blame them?? I mean, for example, you probably have a vehicle of somekind. Let's say it has a KNOWN defect that demands recall because it is costing lives. Wouldn't you want some form of remuneration/compensation and care for such an issue?? You certainly would. The same rules apply to the world of software as well. People being people, they definitey do, especially those who do not have the skills to do the work themselves (as in the case of say, cars/vehicles, not everyone is a mechanic... and in the case of softwares & OS' also?? Well, face it: Not everyone is a software engineer or network engineer/techie even, either). So, yes, the person you replied to as well as yourself in both cases?? Guys, it's the real world, and we all know it and also demand the same (as in the case of other products you buy such as cars/vehicles as I noted above (yes, I know - another "Car Analogy", but it does fit here)). People want somekind of "plan B" to fall back on when things matter with tools they use, period. By the way? I am also a professional software engineer/network engineer by trade since 1995 also, and though you or I may not LIKE this scenario, we also may be hypocrites sounding off on it being "wrong" etc., because again, in the case of other products we use, we often demand this ourselves (again, cars serve as an example for many here, or even our computer hardware, if when found faulty? We want remuneration/compensations via warranties, etc./et al).
The fix for World of Warcraft under WINE made it into 2.6.35, though it is not mentioned in the changelist above. WoW 3.3.5 crashed under recent Linux kernels because it apparently made use of the "icebp" instruction, whatever that is; the kernel stopped sending SIGTRAP for icebp instructions in an earlier 2.6 build for whatever reason.
Diff of fix
Source code of file, showing the icebp fix merged in (search for "icebp")
WINE compat page
Do we still have to talk about "burnout" every time we mention kernel maintenance?
Yep. It isn't a meme unless it gets repeated over and over.
It is difficult to get a man to understand something when his job depends on not understanding it.
Bert64, see subject line above & I am wondering WHY you avoided noting that (not, I know why you did)! I'll explain it for others to avoid your 1/2 truths here:
By having to purchase a support contract for your open sores software? You're stuff's no longer REALLY "free" and it's actually quite deceptive advertising imo @ least to then say it's free. Also, by your now espousing having to PURCHASE something for your "Open SORES" stuff, well... face it: You're actually subverting a LARGE feature of what actually makes "Open SORES" (where errors are more easily found for both fixes and finding vulnerabilities (in the latter to use AGAINST IT, not just to fix them also)) attractive in being a money saving thing vs. commercially produced closed-source softwares.
No, the sword cuts BOTH ways here Bert64, & though you made a few good points, it was "FUNNY" how you avoided noting those support contracts for "Open SORES" stuff, co$t MONEY!
"A young whippersnapper, then. When you have a bit more experience of the real world you might start to understand just how many critical systems already run on Linux." - by 0123456 (636235) on Monday August 02, @03:06AM (#33107656)
LMAO - Oh, really? You'd be surprised at how many MORE run on say, Microsoft's Windows NT-based OS' as well as those from the likes of IBM for instance... & as to "young whippersnapper"?? LMAO, again, because I've actually been around these systems for over 28++ yrs. now, & for nearly 16 professionally as both a dev using multiple languages, tools, & OS' + as a network administrator as well (in addition to having done quite well in publication & technical contests for my works in commercial wares, such as MS' Tech Ed, 2yrs. in a row no less & in its hardest category). I also possess multiple degrees around this science... have you done the same to ALL of the above? Somehow, despite your attempted ad hominem attack upon myself, rather than disputing points I made (which is the last resort of trolls on both accounts mind you on your part), and attempting to act as if YOU were my "senior" in this art & science? I doubt it. As to wares written for defence contractors? Check with Raytheon and their artillery control wares written for the IRAQ conflict, because the poster I replied to mentioned working for defense contractors. Soldiers lives depend on it, and yes, it works, and it's written on the Windows platform, so... Better luck next time, troll.
LOL, see subject above, & this admission of the TRUTH from "Open SORES zealot #1" around here, in Bert64:
"Support contracts for *ANYTHING* cost money... - by Bert64 (520050) writes: on Monday August 02, @04:39AM (#33108002) Homepage
Funny you mention that NOW, but "StRaNgE" (not) how you avoided noting that in your first reply, eh? Again: "NOT"...
Bert64, but this was what gives away your "FrUsTrAtEd" & "FoAmInG @ tHe MoUtH" rage, lol, in this ad hominem attack by you:
"Over all, a very poor troll. I feel insulted to be trolled by you. - by Bert64 (520050) writes:bert@NosPAM.slashdot.firenzee.com> on Monday August 02, @04:39AM (#33108002) Homepage
Well, I got you to first of all admit that Linux and other "Open SORES" support contracts CO$t MONEY, and now to see you reduced to name tossing so... lol to you.
(Best you & yours had is name tossing and unjustified mod downs as well Bertie boy. Give up: You just do not have the intelligence to get the better of me and your name tossing adhominem attacks prove that much above, in your own words quoted no less!)
Poor performance on your part to have to try the "grammar and spellcheck" routine Bert64. It's the last resort of a troll and we all know it, unless you can show us that this is the "grammar & spellcheck section" of /. and, it's shown your frustration at being exposed in the oldest scam of all that "Open SORES" uses: Bert64 & Open SORES version of "FREE" is along the lines of BEER IS FREE, BUT THERE IS A $1,000 CHARGE FOR THE BOTTLE DEPOSIT Which is of course, complete bullshit and deceptive advertising. Stating others trolled you also only makes you look all the more frustrated at being outsmarted in being spotted in your rather sneaky omission and 1/2 truth in your not noting that Open SORES support contracts are NOT FREE and CO$T MONEY buddy. You got burned, as well as caught spouting your 1/2 truth "OPEN SORES FUD", and all you have is your name calling and mod downs Bert64. You're not smart enough to pull the wool over our eyes old boy, so face that fact, ok?
See subject, & neither does it make the BEER IS FREE BUT $1,000 BOTTLE RENTAL so-called "FREE" of OPEN SORES any better does it Bertie boy? No, it does not. Funny how you omitted that it costs for those support contracts for say, Linux though on your part (& since you have to pay to get Linux supported, it's not exactly "FREE" anymore is it, Bert? Nope, not really!)
Nor does it change the fact that finding security vulnerabilities to exploit in OPEN SORES any better either since it IS possessed of a freely available source which is far easier to find security vulnerabilities in than is closed source (where you must resort to either fuzzers or debuggers/disassemblers, which is far more difficult to do and more time consuming than reading actual sourcecode).
In the end, after your POOR "spell check" trolls and unjustified mod downs here??
LMAO - Man... Give up Bert64, because on your BEST day? I've always taken you to the cleaners in technical debate here, everytime...
APK
P.S.=>
"Go and read the original post." - by Bert64 (520050) writes: on Monday August 02, @04:52AM (#33108034) Homepage
Uhm, that changes what I said above HOW, Bertie? Oh, so you know?? I am posting this from KUbuntu 10.04 (iirc that's the build # of latest stable etc. I dl'd & used) so you can't call me a "closed source shill" etc. as you "Open SORES" trolls & shills often try to do, as well as FireFox (and have my other rig here running Free BSD's latest stable build in a few minutes too)... Plus, of course, my last system on Windows 7 (all 64 bit builds on ALL OS & systems here) - I am OPEN MINDED Bert, but at least I can state the ups & downs of them all, without omitting facts as YOU have in the support contract costs of LINUX! apk
"$1,000++ BOTTLE RENTAL FEE" for support contracts for Open SORES wares & OS, which in essence makes them NOT TOTALLY FREE!
So, so much for "FREE" per Bert64, and gee: Isn't it "ODD" that Bert64 omitted the costs involved on that end of things also?
Bert64 also neglected to mention that Open SORES, in being "Open SORES" that security vulnerabilities are easier to find and thus exploit against an Open SORES OS or ware because of it vs. closed source having to have either fuzzers or debuggers/disassemblers taken to it to do the same which means MORE TIME & harder to do in finding bugs against it also.
(Yes, when you point out truths about "Open SORES" here on /., all you get is more FUD, name tossing, grammar and spellchecks plus other ad hominem attacks taken to you as well as unjustified mod downs sent your way by these numerous alternate registered account using OPEN SORES TROLLS (like they fool anyone? LOL, we all know they do it in fact so they can mod themselves up and others down with their multiple registered accounts here)).
Better luck next time boys because you'll have a hell of a time disproving the points I just made here and also in other posts here as well.
> As a consultant for several large companies
Could you name some ?
> a top online investment firm asked us to do some work using Linux
What was the name of this investment firm?
> The concept of having access to source code was very appealing to us, as we'd be able to modify the kernel to meet our exacting standards
What projects do you work on that require recompiling the kernel :
> Although we met several technical challenges along the way
(specifically, Linux's lack of Token Ring support
Who still uses Token Ring ?
> and the fact that we were unable to defrag its ext2 file system)
Enough of this bullshit already ...
Funny how Bert64's post gets a "+5 INSIGHTFUL" rating, despite it omitting the fact that support of LINUX actually costs money and he "conveniently" avoided noting that in his supposedly "insightful" posting about OPEN SORES. It's also funny how in the rest of this exchange the AC's posting had their posts also rather "conveniently modded down", despite pointing out how Bert64 err'd in his omission on support contract costs for LINUX as well as the fact that Open SORES code is exactly that: OPEN, where the "security vulnerability sores" in it can be spotted in it, TO USE SAID FOUND SECURITY VULNERABILITIES IN IT AGAINST SAID OPEN SORES OS &/OR OPEN SORES APPS, & far easier than they are in closed source code (because closed source is that, closed, and needs disassemblers/debuggers &/or fuzzers taken to it to do the same in finding vulnerabilities in it to use against closed source stuff).
When did Linus get a motorcycle?
Nerd rage is the funniest rage.
Since there seems to be no place on the internet where to post feature-requests for linux, here's four points from my list:
1. User-space scheduling. It would be nice if a process could have better control on the priority of each of its threads. For example, on a web service where multiple users are active, it is often necessary to give each user his/her share of the cpu. Right now this is rather difficult to do in a fair way, since multiple threads may belong to the same user.
2. Recursive strace: Currently it is not possible to run "strace" on a process which is already being straced. So for example: "strace -f strace -f ls" will not work (you'll get an "operation not permitted" inside the first strace. This makes it impossible for programs to use strace (or the related ptrace system call), since other programs which might also use strace, may depend on them.
3. "Nice" for bandwidth. It would be great if there was a command similar to "nice", which acts not on cpu-cycles but instead on bandwidth.
4. "Select" or "poll" with access to inter-thread synchronization structures. Select and poll are system calls which act mainly on file-descriptors. However, sometimes you'd like to wait also on a mutex or semaphore. Some support for this would be great.
This list is just from the top of my head. I could probably come up with a lot more.
Alex
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Eh. Sun intentionally chose the license to be GPL incompatible.
This keeps being said. Do you have a source for this?
Have a little config file consulted by the shim library:
~/.bwnice.conf: 199.237.54.1:80 5 MB/s /tmp/videocache.bin 5 MB/s
etc...
I dunno what your use case is, you could use this for stuff you start as a user, or added to the system config, and have it apply to all users. To do system-wide stuff, tc is already plenty good enough, thought it only applies to network stuff. Dunno of anything for limiting b/w to local disk.
anyway, you don't need any kernel anything for this feature. basic rule is if it can be done in user space, it very often ought to be done there.
http://www.ibm.com/developerworks/linux/library/l-glibc.html
http://www.linuxjournal.com/article/7795
http://www.tuxradar.com/content/control-your-bandwidth-trickle
It's done! by google, no less...
anyway, you don't need any kernel anything for this feature. basic rule is if it can be done in user space, it very often ought to be done there.
Totally agree with you on the last part! However, this raises the rhetoric question why "nice" itself isn't totally handled inside libc :P
Also, such a feature should not be too difficult to add to the kernel. If it really would be difficult, then isn't the kernel getting just too complicated for its own good?
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Stop talking about Linus' burn-out. Why bring up pointless issues? What are you trying add to add to the conversation by saying that?
how is babby formed?
Maybe the moderation is a hint that everyone else thinks you're stupid? - by Anonymous Coward
on Monday August 02, @07:56AM (#33108650)
Yea, see subject-line above: Says it ALL about the "moderation" here, & especially since ALL YOU'VE GOT ARE YOUR AD-HOMINEM ATTACKS instead of attacking the points I made (which are, indisputable, because they're simply the truth is all (and you KNOW it)).
You & they may THINK I am stupid, but to tell you the truth, based on your lack of being able to dispute the 2-3 points I made here? Well, I KNOW you are stupid, period.
Nice is done in libc, at least the interface to handing the nice setting to the scheduler is. This is just an added setting into the kernel's process scheduler. You'll find that a lot of people argue a lot about how to do scheduling right. The nice setting is just one constant that it inserted into an algorithm that has to exist anyways.
For I/O, traditionally there has never really been a "scheduler". The whole idea was to use the device to it's maximum capability all the time. Devices are controlled by single drivers, and the idea of preferring some blocks over others doesn't exist. So there is no kernel level thing to hook into. You would have to add new stuff... in many places, because network and block devices don't share much below libc level.
Nowadays, there are bits and pieces such as laptop drive spinup preventers and such that perhaps do perform a bit of prioritization (stopping the spin up of drives by using cache a bit more aggresively.) But I've never seen a general mechanism.
I'm not convinced that one that worked by process is necessarily the best approach. My hunch is that it makes more sense to set a priority as a file attribute, and set i/o priorities based on what file is being accessed.
For example, A low priority job trying to write a log message might monopolize the system log for a long time because it is low priority. It makes more sense for i/o to the log to be high priority, but i/o to an application data file that is exclusively accessed by a user app be lower priority. there are a lot more cases of exclusive access locks with i/o scheduling vs. process scheduling... the benefits for i/o scheduling in the kernel probably are not that clear.
It would probably make a better case for it if someone implemented the libc case (eg. taking trickle and extending it to deal with block i/o as well, and and extending it to be system-wide, instead of per process.) to build a prototype i/o scheduler. This would give some real-world use cases. After it was thoroughly beaten upon, then folks could look at what bits of it makes sense to fold it into the kernel proper, and what is just fine in user space. fun project!
Using a libc shim for controlling network access is stupid. Libc is completely optional, so the only place to reliably control such a thing is in the network stack, which means in the kernel.
As for the rhetorical question, libc doesn't have any control of scheduling, so it's not even possible to implement features provided by nice.
And throttling (shaping) is supported by the kernel infrastructure. Incoming and outcoming packets can be processed by netfilter/iptables. I just haven't seen any user friendly program for changing them on a per process or program basis.
why is it per process/program? I suspect the real problem is that individual files should be prioritized, not processes. kernel eventually maybe. demo in user space first
See subject above, and all I have to say to that is this:
Ahem - BULLSHIT!
(I know this because I have seen kernel panics and application hangups or crashes on it)
Man, you have to LOVE how the zealots and fanboys of Linux won't admit that it has hassles also (and that it only does a fraction of what Windows does on a PC in terms of apps available for it and what not).
In regards to that then, well, I'd like to see someone explain WHY this documentation exists then:
Reboot Linux box after a kernel panic:
http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kernel-panic.html
Hmmm?
(Gotta love the Linux fanboys'/zealots' "straight-outta-pravda" BULLSHIT around here!)
A big problem with doing it per file is that many processes run from the same file. It's not at all uncommon to have multiple processes accessing the network that are the same binary file. Think about interpreters or virtual machines like python or java.
So, Linux NEVER, EVER screws up or crashes (same with its apps too)? Hmmm?? See this then below:
----
Reboot Linux box after a kernel panic:
http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kernel-panic.html
----
(Gotta love the Linux fanboys'/zealots' "straight-outta-pravda" BULLSHIT around here!)
Linux NEVER, EVER screws up or crashes (same with its apps too), Bert64? Tell us about KERNEL PANICS then please, won't you, Bert64? See below:
----
Reboot Linux box after a kernel panic:
http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kernel-panic.html
----
(Gotta love the Linux fanboys'/zealots' "straight-outta-pravda" BULLSHIT around here - Especially Bert64's)
He & his multiple registered user accounts usage to mod up his posts and to mod down the posts of others here when they show him up as the deceptive 1/2 truth spewing old fool he really is.
Example? Ok, see here:
http://linux.slashdot.org/comments.pl?sid=1739756&cid=33108472
(That's where Bert64 "conveniently omits" that LINUX SUPPORT CONTRACTS CO$T MONEY... so that really means that Linux isn't TRULY "free" and that their deceptive advertising policy is along the lines of "BEER IS FREE: $1,000 DOLLAR BOTTLE DEPOSIT FEE THOUGH")
http://linux.slashdot.org/comments.pl?sid=1739756&cid=33120408 It's merely truths, just like this URL above is, along with others which were down modded in this exchange, vs. the BULLSHIT propoganda the Linux fanboys can't handle. See that URL above where just some of the negative truths about LINUX are mentioned, and then witness the technically unjustified mod downs you get around here. Do the Linux dimwits with their effete mod downs fool anyone? Answer = NO. They merely show they're full of it and all they are left with is their unjustified effete mod downs of others posts.
For example, I would make DNS requests very high priority. I would have something like *.dns, assigned very high priority, and ptp stuff relatively low, which would help optimize browser responsiveness. If I have some data at a particular web site that is important to me, I could increase priority of i/o to that web site, versus ordinary i/o.
Someone would have to implement this to see if it actually makes any difference in real life. Typically, I find that an idea that is simple enough that isn't already done, probably has something wrong with it ;-)
See subject-line above and realize 1 thing Linux dolts: You may effetely mod down posts' points you cannot dispute, but you cannot destroy the truths they contain!
Truths, such as:
1.) Linux support contracts costing money, meaning it's not free. It's more like it's deceptive advertising like "FREE BEER, $1,000 DOLLAR BOTTLE DEPOSIT FEE"
and
2.) That Linux being "Open SORES" is just that - since it's code is freely available, the hacker/cracker types can find security holes TO USE AGAINST IT, quicker (quicker than can be done to closed source because that demands more time consuming methods such as fuzzers &/or debuggers-disassemblers).
So, please: KEEP BLOWING YOUR MOD POINTS AND DOING YOUR UNJUSTIFIED MOD DOWNS WITH NO TECHNICAL SUBSTANCE BEHIND THEM - Because by doing so, You're really only showing the rest of us you are "on the ropes" because all you have are your unjustified mod downs!
See subject-line above and realize 1 thing Linux dolts: You may effetely mod down posts' points you cannot dispute, but you cannot destroy the truths they contain!
Truths, such as:
1.) Linux support contracts costing money, meaning it's not free. It's more like it's deceptive advertising like "FREE BEER, $1,000 DOLLAR BOTTLE DEPOSIT FEE"
and
2.) That Linux being "Open SORES" is just that - since it's code is freely available, the hacker/cracker types can find security holes TO USE AGAINST IT, quicker (quicker than can be done to closed source because that demands more time consuming methods such as fuzzers &/or debuggers-disassemblers).
So, please: KEEP BLOWING YOUR MOD POINTS AND DOING YOUR UNJUSTIFIED MOD DOWNS WITH NO TECHNICAL SUBSTANCE BEHIND THEM - Because by doing so, You're really only showing the rest of us you are "on the ropes" because all you have are your unjustified mod downs...
See subject-line above and realize 1 thing Linux dolts: You may effetely mod down posts' points in this exchange that you cannot dispute, but you cannot destroy the truths they contain!
Truths, such as:
1.) Linux support contracts costing money, meaning it's not free. It's more like it's deceptive advertising like "FREE BEER, $1,000 DOLLAR BOTTLE DEPOSIT FEE"
and
2.) That Linux being "Open SORES" is just that - since it's code is freely available, the hacker/cracker types can find security holes TO USE AGAINST IT, quicker (quicker than can be done to closed source because that demands more time consuming methods such as fuzzers &/or debuggers-disassemblers).
as well as
3.) LINUX KERNEL PANICS DO HAPPEN, as well as apps on it crashing or malfunctioning (despite the Linux fanboys b.s. they do not)
In fact, on the last note? See here, as proof thereof:
----
Reboot Linux box after a kernel panic:
http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kernel-panic.html
----
So, that all said & aside?
Please: DO KEEP BLOWING YOUR MOD POINTS AND DOING YOUR UNJUSTIFIED MOD DOWNS WITH NO TECHNICAL SUBSTANCE BEHIND THEM - Because by doing so, You're really only showing the rest of us you are "on the ropes" because all you have are your unjustified mod downs!
So buy RHEL and stop flaming. - by Thinboy00 (1190815) writes: > on Monday August 02, @11:09AM (#33110536) Journal
I run these OS' here @ home and on the job:
A.) KUbuntu 10.4 latest stable
B.) FreeBSD 8.1
C.) Windows 7
(Each is 64 bit, and each has its hassles... not a single one is "Crash-Proof" either, given enough of a load and time...)
Also, see subject-line above, and realize 1 thing Linux dolts: You may effetely mod down posts' points in this exchange that you cannot dispute, but you cannot destroy the truths they contain!
Truths, such as:
1.) Linux support contracts costing money, meaning it's not free. It's more like it's deceptive advertising like "FREE BEER, $1,000 DOLLAR BOTTLE DEPOSIT FEE"
and
2.) That Linux being "Open SORES" is just that - since it's code is freely available, the hacker/cracker types can find security holes TO USE AGAINST IT, quicker (quicker than can be done to closed source because that demands more time consuming methods such as fuzzers &/or debuggers-disassemblers).
as well as
3.) LINUX KERNEL PANICS DO HAPPEN, as well as apps on it crashing or malfunctioning (despite the Linux fanboys b.s. they do not)
In fact, on the last note? See here, as proof thereof:
----
Reboot Linux box after a kernel panic:
http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kernel-panic.html
----
So, that all said & aside?
Please: DO KEEP BLOWING YOUR MOD POINTS AND DOING YOUR UNJUSTIFIED MOD DOWNS WITH NO TECHNICAL SUBSTANCE BEHIND THEM - Because by doing so, You're really only showing the rest of us you are "on the ropes" because all you have are your unjustified mod downs!
libc is completely optional.