Linux Kernel 2.2.14 301
So everyone and their unkle wrote in to tell us that Linux 2.2.14 has officially been released. If your uptime isn't to sacred to ya, it may be worth upgrading. You know where to get the good stuff if ya need it.
Re:The importance (or lack thereof) of uptime (Score:1)
Of course you probably know that and are trying to trick us in to thinking you don't care about long uptimes to make us think you have a long penis. What kind of excuse is that? script kiddies? puh-leeeze. you might as well have said that you don't want to ruin the environment by consuming the electricity needed for longer uptimes. like anyone would believe that.
So I'm calling your bluff. I bet you've got really long uptimes.
And for the record, my uptime is just the right size. Not too big, not too small. So don't even bother asking.
help a newbie out! (Score:1)
I'm not actually planning on doing it, as I'm not proficient enough to recompile and replace a kernel yet, but I need to know how soon I have to try and take this step.
thanks.
Why I switched to Net/OpenBSD... (Score:1)
I recently switched from Linux to OpenBSD and NetBSD on my ix86 and Alpha machines after a year's evaluation of the free *BSDs on a couple of spare boxes; now I'm going to detail the reasons for the switch and elicit (hopefully constructive) feedback from /. readers.
Mind you, I did not switch for any political reasons (i.e. - GPL/FSF vs. BSD/MIT/X) - I actually prefer the 'restriction' of always-available source-code+improvements of the GPL and am philosophically aligned with the FSF.
Nor did I switch for preferring a 'Cathedral' development model over the 'Bazaar'.
Though I'm quite happy with most of the developers and contributors, I switched because I am becoming increasingly dissatisfied with the general, overall _attitude_ and _focus_ of the Linux community and, moreover, the practical and pragmatic potential pitfalls that I see Linux moving towards.
Here's a synopsis of my view:
1. Preoccupation with Microsoft
Why is the Linux community _so_ vocal about their dissatisfaction/hatred of Microsoft Corporation? Isn't this obsession somewhat absurd?
If proprietary and monopolistic are so terrible, why the soft spots (much less criticism at least) over Apple, Be, Sun or other Unix/hardware vendors? All of the above are really no better than MS and would *love* to be in Microsoft's place, reducing consumer choice and limiting their own liability.
How is this a liability to the Linux community? How about the proposed khttp? Four years ago, a kernel service like this would be unthinkable and considered an anathema to good Unix design; the post-Mindcraft attitude makes this permissible.
Is 'one-upping' NT4+IIS by introducing real dangers all that necessary to win corporate/popular mindshare? Why is this happening?
2. Lack of focus and the 'World-Domination' syndrome
Lack of focus for the general Linux community probably stems from the 'Bazaar' development model. While not necessarily bad (it is indeed the most democratic and fair development model, much more so over *BSDs), now that Linux has become more popular, the community now suffers from the 'World Domination' syndrome.
Does _every_ device need to be supported under Linux? Even devices whose quality and performance are questionable, when similarly-priced, higher-quality devices are available?
Personally, I use devices and only spec devices to others that I know are well-supported and whose vendors provide specs/development help to developers. For example, I only use Buslogic Multimaster and QLogic ISP-based SCSI controllers because they work, they don't time out, and their support does not vary (greatly) from one firmware revision to the next. The manufacturers have seen Linux as a viable market from the beginning and have provided specs/documentation to minimize the amount of reverse-engineering for developers. These are the vendors we should support, and perhaps the others will see free software as a viable market as well.
However, the Linux community wants *every* device supported, seemingly again to 'one-up' the other OSes (*BSDs, but particularly MS) and 'win over' more users. And as a result, the quality of support for many devices ranges from excellent to severely abysmal...
Can we decide on a range of devices to support (the level proportional to the amount of support from the vendors) and _really_ support those devices?
3. Lastly, the details and fine-tuning code.
For the most part, the kernel maintainers do an excellent job considering the volume and rapid rate of development on the kernel. Even so, is this rapid rate of development really conducive to a necessarily better kernel and/or OS? Also, are we ignoring potential pitfalls with the 'release early and often' methodology?
The details (an admittedly minor but poignant detail): disk device files and partitioning:
Let's compare this to the *BSD world... addressing the issues above.
1. The *BSDs are obviously not MS-friendly, but they don't seem to have many loud-mouths (i.e.- ESR) disparaging the Gates Empire at every opportunity. Though beset by lack of publicity (I believe they are waiting for the Linux hype to subside before pursuing the limelight), their users are growing, and increasingly including many ex-Linux users :(
2., 3. The *BSD teams are exceptionally well-focused, and that shows in the overall quality of code and distributions. Certainly the development is far less democratic, but it seems the users truly benefit from the focus on 'getting it right the first time.'
The hardware support (peripherals, not architectures since NetBSD supports just about arch) in *BSDs is limited in comparison to Linux but there is a marked difference - nearly all the supported hardware works well. For a new user (or a boss you're trying to impress), this is definitely preferable to wide-inclusion/spotty performance that we have under Linux.
Also, NFS works perfectly under *BSD. This is probably the number one reason why I switched.
Although the IP stack under Linux is good, it's even better on *BSD.
*BSD pays attention to the details. Bug fixes are fairly rapid (though not instantaneous as under Linux) but the maintainers always strive to make *correct* bug fixes - that is, fixes that won't become a potential problem six- ten- twelve- months from now...
*BSDs use proper disklabels, partitioning and device file naming schemes from the start; no need to worry about managing multiple host adapters, etc.
Sorry for the ranting... actually, I hope this will be considered constructive criticism.
The Linux community _does_ have an unusually high proportion of talented programmers, but, because of some of the more _social_ issues above, may lose mindshare and advantage to other free OSes...
~AC
Okay, I'll concede... Actually, I find that the Debian [debian.org] distribution, with its long release cycles, thorough and robust package management and exceptionally high-quality (in the Linux world) packages is the Linux distribution that approaches the quality of Net/OpenBSD. They obviously have extremely stringent standards (though not quite at *BSD level) and seem to attempt to 'get it right the first time'. Kudos to the Debian team!
probably not (Score:1)
- you have some hardware, and a driver for it was added/fixed in the new kernel
- there was some grevious security hole that was fixed (not the case with this release)
- there was some grevious file corruption bug that was fixed (again, not the case)
- for some reason, you upgrade a different piece of software, and it requires a newer kernel (far more common when upgrading from 2.0 to 2.2 than from 2.2.13 to 2.2.14, so it probably won't apply)
- you feel the need for whiz-bang features, in which case you're probably already running the unstable kernels
:), and consequently you wouldn't be asking this question
usually, reason #1 is the reason for upgrading. if you look at the changelogs for stable kernels, you'll find that the vast majority of changes are tiny (or occasionally not so tiny) fixes with obscure pieces of hardware that run on obscure systems (okay, maybe a slight exaggeration). anyway, unlike with the 2.3 kernels, you won't find any new whiz-bang features in the 2.2 kernels, so if you don't need to upgrade, don't!I wish NcFTPd would put their server to real test (Score:1)
Ext3 (Score:1)
had no problems (except two obvious rejects of
2 lines of code in the kdb-patch, and further
2 lines in the ext3 patch), but it failed to
compile... I guess I'll have to wait until
Stephen Tweedie fixes this. And of course, the
missing ext3 is the sole reason that keeps me
from trying out 2.3.x-kernels.
Kirth
Re:At last! (Score:1)
Re:At last! (Score:1)
Ah, let me tell you the joy one feels as a bonefied kernel contributor. I remember it like it was yesterday. Picture it, 1997 (or so), I guess something in the 2.1 line. A kernel is released, and some goofy driver that I used, a sound card or something, has a typo. Seizing the opportunity, I expertly craft a patch to handle this mishap, using all the resources at my disposal. Then, crossing my fingers, I wade through the compile to ensure everything works. 15 minutes later, it's compiled.
Then, the ever so daunting reboot and test it routine. I edit lilo.conf with a fury like I've never edited lilo.conf before. Run it, reboot, and closly watch the scrolling messages. Then, like the sun rising in the morning, I see it. Before my eyes is the startup lines for that piece of hardware, the IRQ, the IO address. It was a beauty I had only seen before when I actually paid attention to the bootup. Finally, after all was booted up, I did the final test. Playing a sound file, or whatever the thing was. And it worked! "Eureka!!" I shouted from my desk. The neighbor's dog starts barking. "Yes, boy. It is true. I have fixed the kernel," I reassure the young pup.
Hastily I booted up my PPP scripts. The modem fires up with it's random assortment of buzzes and bings. Then I see those magical characters from my ISP, "Your IP is now: 123.45.67.89." (IP changed to protect the innocent.) Without skipping a beat, I fire up pine and type one heck of an email to the kernel list. "Um, there was a typo in the xxx driver of 2.1.xx. Patch below," (an approximation, my memory isn't that good).
Anxiously I waited, day after day. "When is that crazy Fin gonna release a new kernel with my patch??" I asked myself. Each morning I awoke, checked the sunsite mirrors. With each passing day I only got more anxious to see my patch in all it's glory. And then, one day it happened. All my vigilant waiting had finally paid off. Linus released another revision of the kernel! I downloaded that patch like no other patch in the world, gunzipped it, and fired up less. Remembering which file it was I had to skillfully edit, I executed a search for it. Then a quiet peace fell upon the world. It was as though all the powers in the universe were converging to celebrate my patch. For there, upon that console screen, on that cold, wintry day (I'm guessing, it adds atmosphere to the story), I see the modification over which I toiled so diligently. I was now, a Linux kernel contributor.
That is my story, and that is all I have to say about that.
Re:AGP? (Score:1)
Re:AGP? (Score:1)
As I said in another post, AGP is not explicitly supported in the current stable kernels, it's just used as another PCI bus (which is largely how the system treats/sees it). 2.3.x includes developing support for the special features of AGP (texture data in system RAM and (maybe?) DMA support).
How do you patch the kernel? (Score:1)
had any problems but for some reason I can't
figure out how to get it to work with the Linux
src. I have the linux-2.2.12 src and the files
patch-2.2.14 and patch-2.2.13. What do I need to do?
lrwxrwxrwx 1 root root 12 Jan 4 17:58 linux -> linux-2.2.12/
drwxr-xr-x 18 root root 1024 Jan 4 17:40 linux-2.2.12/
drwxr-xr-x 2 root root 12288 Nov 14 18:28 lost+found/
-rw-rw-r-- 1 root root 3111595 Jan 4 17:37 patch-2.2.13
-rw-rw-r-- 1 root root 7269094 Jan 4 17:37 patch-2.2.14
Re:101 days on 2.2.10 (Score:1)
Re:The importance (or lack thereof) of uptime (Score:1)
Sure if you are running a single user machine upgrade by all means but the only reasons to upgrade real servers are if the new kernels has security patches and possible imporovements in the drivers for your specific hardware. Otherwise keep the uptime high, the users appreciate it.
Re:What should I do to work with the new modules? (Score:1)
Building a modular kernel isn't that hard, just a matter of putting " make modules ; make modules_install " after your " make dep ; make clean ; make zImage ; ".
There are several cons of building a monolithic kernel these days. In my experience the first think I have is that, for me, it's too big to be a monolithic one (even with make bzImage).
That's why I build everything I can as modules.
They're simple (IMO) and smart. If set up right (usually the case) they are only loaded when a program needs them and unloaded shortly after I turn off the program (my bttv modules do that anyway). That ensures that it only uses the RAM it needs and no more.
One question though, that SCSI controller isn't the one you hook up your scsi harddrive to (I'm assuming your harddrives are SCSI only..) is it? in which case you'll HAVE TO build support for it in the kernel itself (no modules here).
Re:The importance (or lack thereof) of uptime (Score:1)
Their #1 uptime system is a HPUX box that's been up for over 100 years.
Re:uncle? what has he got to do with that? (Score:1)
i've seen the expression formulated as "everyone and their [dog|uncle|brother]".
-l
special king of bugfixes: security fixes (Score:1)
i just want to point out security holes
with rule "not unless you need to fix a bug, or gain a feature." you can consider not to upgrade just because of for example tulip driver error because you are not experiencing troubles even when using tulip card. :)
BUT if this tulip bug is security hole you SHOULD update even when usual usage is OK. hackers are not producing usual thinkg on systems
disclaimer: take it as advice to newbies.
Re:security fixes fix bugs :) (Score:1)
exactly. i just "explained" special case of bug fix to newbies (i hope).
Re:Filesystem problems fixed? (Score:1)
2) formulate a useful bug report?
take a look at /usr/src/linux/REPORTING-BUGS (2.2.X).
Re:Uptimes and kernel upgrades. (Score:1)
It is not uptiem alone that sells an OS to other people. If you can upgrade your kernel to take advantage of new functionality then that is more likely to make Linux appear robust, usable and so on.
Re:Link for the lazy (Score:1)
Re:Why? (Score:1)
In addition, I've got some TCP/IP problems I hope 2.2.14 will fix, like returning fd 0 on accept() and generally breaking under high loads.
/* Steinar */
Re:AGP? -- Never will happen (Score:1)
Also note that there are two (or more) AGP specifications that would have to be supported: Intel's, VIA's, and whoever else puts out an AGP chipset.
jf
Re:Framebuffer Devices (Score:1)
security fixes fix bugs :) (Score:1)
----
Re:Uptimes and kernel upgrades. (Score:1)
my $.02
Steve
Re:damn it... (Score:1)
It was plugged into a UPS and I was so tempted to move it without shutting down. Unfortunately the good side of me took over and I shut down the machine. I'd be at about 250 days or so of uptime after the move if it wasn't for the great-popcorn-burning-and-setting-off-the-fire-su
I'm at 71 days on that machine, so I'm happy. I really wanted to shoot for a year....maybe I'll get it this time.
S/390s and VAXen (Score:1)
As for Linux on VAX, see http://www.mssl.ucl.ac.uk/~atp/linux-vax/ - there is a port in progress, though right now NetBSD seems a better choice for everday use.
Re:AS/400s too... (Score:1)
Given that the AS/400 has such an unusual architecture, it seems like a very difficult port, far more so than the S/390, but you never know...
Re:pppoe (Score:1)
Re:AGP? (Score:1)
Re:What should I do to work with the new modules? (Score:1)
When selecting what to include in or exclude from the kernel, choose "m" to include items as modules.
After you do "make zImage" or "make zlilo" or "make vmlinux" or whatever your choice for building the monolithic part of the kernel, issue "make modules" to build the modules, and then "make modules_install" to install all of the modules. If you don't already have this version of the kernel/modules installed, you've got nothing to worry about here--2.2.14's modules will all be in
Re:Ext3 (Score:1)
would you?
i lost mine, and linux.org.uk seems down
Re:Uptime... (Score:1)
The only upgrades that cause me to bring a system down are kernel upgrades and hardware upgrades. I can do all other upgrades without rebooting the machine.
If my kernel supports my hardware, and there's not some major bug in it, what's the point of upgrading it? If my hardware is capable of doing the job, what's the point of upgrading it?
If it works, don't fix it...
Re:AGP? (Score:1)
Not particularly, asshole. I was correcting his acronym error, not indicating that USB support wasn't available yet.
BTW, USB support is included in the standard 2.2 kernel. Look under linux/drivers/usb.
PS: Go crawl back under your rock and die, you stupid piece of shit.
Re:could not be done (Score:1)
Think about what you'd have to code if an internal structure changes (this happens a lot!). It would add to much code only going from one version to the next. I think they effort of implementing such a thing doesn't compare to the downtime of a few minutes that you would have.
If your uptime is really that sacred, that don't upgrade. Apparently your system is already stable enough that a reboot for a kernel upgrade is considered harmful. This implies that the current version of the kernel already suits your needs in terms of stability. Then there is no reason to upgrade anyway.
If security or stability is an issue, then you should take the time to reboot. Consider the time you lose because someone cracks your system or because unnecesary instability and you know why.
Regards,
Marco.
Re:help a newbie out! (Score:1)
Does it support the parallelism? (Score:1)
Thanks and note (Score:1)
Re:Uptime... (Score:1)
You know, our local power company needed to "upgrade" our area again a few weeks ago. Nevermind that they'd done an all night (1am to 6am) outage less than 6 months before, but this time they decided it would be more convenient to shut power down at 5am on a Saturday! Allowing for up to 12 hours to do the upgrade of course! Surprise surprise, they started an hour late, and barely got the power back up before 6pm.. when it was already getting dark.
There's not a whole lot you can do at home on a Saturday with no freaking power. Needless to say noone in the neighborhood is happy with them right now. God forbid they might schedule an outage of this length for either a weekday when people will be at work, or better yet, during the night again when the impact to people will be minimal.
Re:AGP? (Score:2)
Re:AGP? (Score:2)
----
How many webcams use GART? (Score:2)
----
Re:AGP? (Score:2)
Re:Ext3 (Score:2)
I made up a patch [mtco.com] based on 2.2.14pre18. It applies and compiles cleanly with this final 2.2.14. I took out some of the kdb stuff, because well, I don't care about debugging it.
Re:Ext3 (Score:2)
dd if=/dev/zero of=/mnt/journal.dat
ls -i
umount
mount
The -o journal= is only needed the first time. Afterwards just edit
Re:help a newbie out! (Score:2)
What you state is indeed true, _however_...
Most newbies, in the US, at least, run RedHat.
RH, like the majority of distros, does not ship
stock kernel sources.
This can cause some parts of a patch to fail.
Not necessarily fatally, but certainly enough
to be disquieting to a newbie. I would suggest
either downloading the full sources _or_
waiting for RH to release an updated kernel rpm.
The former being the preferred method.
Patches are a good thing once you have
pristine sources to run them on.
Supermount patch here (Score:2)
http://www.fargocity.co m/~ccondit/supermount-2.2.14-1.patch [fargocity.com]
This has been modified from the original supermount patch to patch cleanly on 2.2.14-final (md.c failed before).
Re:Uptime... (Score:2)
A few weeks ago I went into work to find the local paper with a front page article stating the utility company of this small town was going to upgrade the substations. I had a spare car battery hooked to the UPS and thought it would ride through. Uh huh... looking at the logs, it looked like the battery was a half an hour shy of the four hours of no power.
Re:Filesystem problems fixed? (Score:2)
--
Filesystem problems fixed? (Score:2)
----
Checklist was for 2.4 (Score:2)
This article was about the 2.2.14 release.
----
Re:help a newbie out! (Score:2)
To either fix bugs, or to gain features
is that something you need to do a lot?
not unless you need to fix a bug, or gain a feature. :)
if your system is running ok, do you still need to upgrade?
See above.
I'm not actually planning on doing it, as I'm not proficient enough to recompile and replace a kernel yet, but I need to know how soon I have to try and take this step. :)
You should look at the kernel HOWTO at www.linuxdoc.org/HOWTO [linuxdoc.org] - it's a bit daunting at first, but it's really not that difficult. The main reason to recompile your kernel is to tailor it exactly to your needs, removing all the cruft that doesn't apply to your system. Plus, as someone said, you'll never be a real Linux user until you do.
----
Re:Filesystem problems fixed? (Score:2)
I did get a kernel oops that seemed ext2 related, and sent it to the ext2 maintaner, but got no reply.
Any suggestions on what I could do to:
1) be sure this really was a bug, and
2) formulate a useful bug report?
This last time, I got a whole slew of:
Jan 1 10:44:05 Lager kernel: EXT2-fs error (device ide0(3,7)): ext2_add_entry:
bad entry in directory #11873: rec_len is smaller than minimal - offset=0, inode
=11873, rec_len=6, name_len=1
entries in the log, and there were in fact several problems when I fsck'd. (This was with 2.2.13) Also, interesting (but probably unrelated) datapoint... it was the postfix files/directories that were damaged each time...
----
Re:Filesystem problems fixed? (Score:2)
Ok, ok, I get it! :) I promise to do that next time. As I said, though, I wanted to make sure that I didn't bother the list with something unimportant, and it's hard for me to tell sometimes...
Compiling 2.2.14 as we speak....
----
Re:The importance (or lack thereof) of uptime (Score:2)
And you think this hypothetical hacker will be savvy enough to code holes into the kernel (as opposed to into the utilities, such as login, which authenticate users), but won't be savvy enough to fake the uptime?
Uhm, sure, yeah, that'll happen. You'll be warned of it by the monkeys flying out of my butt.
Yes, in that extremely bizarre contrived case, it would be a security hole. However, if we're assuming the attacker can replace the kernel with one of this choosing, *EVERY* Unix-like OS has that hole. They have the hole now.
If your system is that owned, you shouldn't be trusting what any piece of software on it tells you, not even the BIOS if you're flash upgradeable.
Re:it compiled okay... (Score:2)
We do all we can to fix bugs, but we can't fix them unless people report them (ok, we do sometimes when we stumble over silly code by accident, when doing rehauling of code or when having little else to do, but those cases are not in majority.)
linux-kernel@vger.rutgers.edu is the place where you report your problems. Good luck!
Re:AGP? (Score:2)
AGP? Methinks you mean USB...
Boy, your face must be red right about now
VM to boot new kernel (Score:2)
Yes I guess that would work. The main problem would be getting hold of the other kernel's memory - you wouldn't have to do any copying at all, but you have to get the memory from somewhere. Presumeably you'd be running under VMWare, or better, an open source vm os, and there would be some kind of api for sharing memory among the various client os's. You'd use that to recover the memory from the halted os. Then figure out how to hot-swap your VM os and you're done.
Re:could not be done (Score:2)
it compiled okay... (Score:2)
I don't think that checklist posted earlier was completed.
*sigh* i guess that'll be worked out in the 'ac' patches...
Incase you DON'T know where to get the good stuff. (Score:2)
KernelNotes.org [kernelnotes.org] has changelists and things but hasn't been updated for 2.2.14 yet.
Re:damn it... (Score:2)
Re:The importance (or lack thereof) of uptime (Score:2)
Re:AGP? (Score:2)
long uptime = proof of few resource leaks etc. (Score:2)
A long uptime on an active system is proof that the system doesn't have significant resource leaks. The same logic applies to systems that don't require frequent disk "defragmentation", etc.
Resource leaks, by themselves, aren't dangerous other than the fact that they force you to reboot the system to recover the lost resources... but they are excellent indicators of the overall quality of the software. In my experience, all program with significant resource leaks have *always* had an unusually large number of other bugs... and the times that someone has tried to eliminate the leaks just to shut up their noisy boss they ended up fixing a large number of unrelated bugs.
Note I did not say that they "found" those bugs - many of the bugs were due to wild pointers that simply disappeared once the programmer took care to properly manage their resources. IMHO, the second most powerful bug-finding strategy, after fixing all warnings issued by the compiler, is elimination of resource leaks.
Re:Uptime... (Score:2)
-> 2 39 days, 20:21:28 | Linux 2.2.13 Thu Nov 25 19:50:22 1999
So, you see, I am a mere 5 days from beating my 2.2.9 record (at which point I rebooted to use a upgraded kernel), when they go and release 2.2.14. Those bastards.
Ah well, since devfs for 2.2.14 isn't out yet (AFAIK), it'll be a while before I go and upgrade
(Linus PLEASE put Devfs in 2.4)
---
Re:New platform introduced with v2.2.14 (S/390) (Score:2)
I really wish someone would port Linux to one of the older rev AS/400's.. I've had a few chances to snag one off of a scrap deal, but w/ no OS they're useless to me..
MediaGX processor support? (Score:2)
The 2.2 kernel boots and runs fine until I try to do something radical like startx. 2.3 however, detects that it's a MediaGX at boot up, but locks up after 'checking the hlt instruction.'
numb
Re:Ken Thompson (Score:2)
If you'll follow the link that he gave to Computer, you'll see that Dr. Daniel Cooke is listed as one of the guys that wrote the article interviewing Ken. As I said in a previous post, Dr. Cooke received permission from Computer and Bell Labs to show SPUUG (South Plains Unix User Group; Texas Tech's little group that I coordinate) an unreleased video of him interviewing Ken in person. Alot of different material than that in the printed version.
Also, Dr. Cooke mentioned to me several times that he received QUITE a bit of flame from the Linux community when that stuff that Ken said was printed, even though he was just the one who wrote it up for Computer.
Again, I can't believe Tom actually posted about this stuff. Wow. Let me just say that backward: woW.
-Will the Chill
Re:You guys EAT tulips?!?!? (Score:2)
Course not, I just typed it because I thougt you guys wouldn't know what Holland is if I didn't mention tulips and wooden shoos
If you ever visit the Netherlands, don't be surprised to see 0.000001% of the population with wooden shoos and 500 others types of flowers in the flower-shops
I've never really tasted flowers, but some people say they are great. I personally prefer steak with french fries
Thank you for your reply, it now is perfectly clear to me that Americans (or wherever you're from) just beleave anything a foreigner says
Telephony Support (Score:2)
This could be an area were Linux could really shine. Telephony is all about reliability and can be very price sensitive, especially when you are trying to put together systems for small companies.
I should know, I work for a company producing exactly these kind of systems, unfortunately on NT
For more details see this article [linuxtelephony.org] on LinuxTelephony.
Re:AGP? (Score:2)
Re:Ken Thompson (Score:2)
Look at Bobby Fischer's anti-semitism, or Einstein's belief in the solid state universe, etc.
Someday Linus will be 50 or 60 and he'll say that the hot new idea is a piece of crap.
It seems to me that people are first anonymous, then we find out about them from some great accomplishment(s), and then they become yesterday's news when the environment that created them changes.
If his comments about Linux being worse as a firewall than Windows are actually attributable to him, then it is obvious, at least on this topic, he is walking, breathing anachronism.
AGP? (Score:2)
Re:How do you patch the kernel? (Score:3)
cd into
patch -p1 (for both two patches)
or, easier and automated:
cd into
Some limited mirrors... (Score:3)
---
Another non-functioning site was "uncertainty.microsoft.com." The purpose of that site was not known. -- MSNBC 10-26-1999 on MS crack
Re:The importance (or lack thereof) of uptime (Score:3)
Let people fudge their damn uptime and all the BS will stop.
Re:AGP? (Score:3)
When it comes to the experimental patches, everything depend on the hardware you have. I've been running v2.3.xx kernels on my trustworthy IBM PS/2 9556slc2 (SCSI) without troubles (apart from having to patch the ibmmca.c scsi-driver in an ugly way) whatsoever, others report lots of trouble.
v2.3 is good, no doubt about that; lots of new interesting stuff, but it isn't feature-complete; lots of stuff that works in v2.2 is broken for v2.3, such as some of the filesystems, etc (but as long as ext2 and fat works, I'm all happy), and the pre-patches are sometimes hard to get to compile.
Finally, more often than not, at least some platform is broken. Sparc seem to have had most problems, but they were fixed up just a while ago, if I'm not all wrong.
If you have important data on your disk or need 24/7 uptime, use v2.2.14. If you don't fall into any of those categories, and have any hardware not supported in v2.2.xx, try out v2.3; it'll be a nice experience, and we need all the bug- testers we can find.
Good luck!
Re:Filesystem problems fixed? (Score:3)
What you should remember is, that if you suspect file-corruption, please send a bug-report and a careful description (hardware, kernel-version, etc.) to linux-kernel@vger.rutgers.edu. More often than not, such reports can be of great help to us when we try to find bugs. This of course applies to other kernel-related bugs too (hangs, etc.)
Re:Filesystem problems fixed? (Score:3)
Remember that the stream of mail to most kernel- hackers is huge, so if you just send them personal mail, simply procmail it away. You never know for sure. Always send to linux-kernel@vger.rutgers.edu (My, this must be the 3rd or 4th time I write that eddy here on Slashdot today...) as well. Others may be experiencing the same problems.
Remember, without bug-reports we don't know about the bugs...
Changelist (Score:3)
Hopefully soon
Re:The importance (or lack thereof) of uptime (Score:3)
I think you missed something important. remote and local exploits come from userland programs. bind, pop3d, etc. The kernel might have DOS problems, but AKAIK there are no remote root exploits for the linux kernel itself.
Re:Linux NFS (Score:3)
Re:Filesystem problems fixed? (Score:3)
I haven't followed up on that recently though, so I may be wrong..
Re:Why? (Score:3)
On another note, they also made the memory buffer hash table more efficient. I also like speed
---
it's not blind faith (Score:3)
-Will the Chill
Re:The importance (or lack thereof) of uptime (Score:3)
-Superiority of an operating system
-Ability to administer a computer
-Programing skill
-"Eliteness/coolness"
Let us take this point by point:
Superiority - You are correct. I've had Windows NT and even 95 boxes up for months at a time.
Administration ability - depends on the circumstances. I have a colocated web server that I have been working on quite heavily since I installed it, and I haven't been within 30 miles of it since it was turned on 50 days ago. Uptime is currently at 50 days.
Programming skill - has nothing to do with uptime
Eliteness/coolness - while not quite the same thing, I am very close to closing a business deal with someone that I have been trying to get to sign on with me for months. In the end, it was the uptime that mattered. Or, more specifically, the fact that the machine didn't flinch during a live load test (real content, real users, no simulations) with this person present. The uptime is like a victory -- you can point to it frequently, and then show someone your logs to prove that your machine can do what you say.
Uptime == bragging rights in some circumstances.
uncle? what has he got to do with that? (Score:3)
AFAIK my uncle doesn't even know where the powerswich of his son's computer is, so I don't think he submitted a post about a new kernel
That's valid, but one-sided. (Score:3)
Some high-availability (am I using the right term there?) systems actually have uptime requirements (such as "we can only be offline for ten minutes every month") that make it risky to upgrade with every new kernel. Particularly since new kernels can introduce new bugs.
My point is that it can be irresponsible to upgrade without knowing what the upgrade does, just as it can be irresponsible to not upgrade.
All that aside, not everyone is running mission critical servers. Some people use their computers for fun, and long uptimes can be a source of amusement.
I personally have two systems with long uptimes, and I will not be upgrading them. They're non-critical systems, and not worth messing with. Besides, I like to see how long it's been since the last power failure.
ext3? (Score:4)
Re:The importance (or lack thereof) of uptime (Score:4)
On the other hand, for a visible machine with a static IP address, hosting web pages or other advertised services, you have to keep ahead of the script kiddies. But not all machines are in that category, far from it.
New platform introduced with v2.2.14 (S/390) (Score:4)
Have a look at IBM's homepage and search around for some information on them. They have BANDWIDTH.
This is at least cool, if nothing else. Now if just anyone could port Linux to VAX, things would be chilling.
Uptimes and kernel upgrades. (Score:4)
Old kernels are still important (Score:4)
1) they are well tested
2) the C library for that kernel is well tested
3) the programs for that library are well tested
the importance of this can't be overemphasized. There are a lot of situations where it's much more important to work with a known quantity than to get the ultimate bit of performance or flexibility.
It's worth noting that one of the most damning complaints against Microsoft as an "enterprise class" OS & application suite is the fact that they have repeatedly demonstrated a cavalier attitude towards making big changes in a way that forces users to upgrade everything to fix a single bug in the kernel (e.g., Win95->Win98) or application (e.g., Office file formats).
That's why Linux, and all real enterprise-ready OSes, allow fairly independent maintenance paths for all major versions of the kernels/libraries/applications. It's a bit more work for the developer, but it's criticial when you're talking about systems which *must* remain up. (E.g., if a hospital's systems go down due to an unexpected bug in an upgraded OS, patients may die. If an airline's systems go down due to an unexpected bug, they can lose millions of dollars in lost bookings and contractual penalties for delays.)
Re:Ahh.... (Score:5)
I wouldn't be able to get anywhere near it. It would be /.'d to capacity. A total of maybe a foot difference between the height of the bridge and the pile of geeks next to it.
Changelog Info (Score:5)
[linuxtoday.com]
http://linuxtoday.com/story.php3?sn=14481
It is a fairly long list of things. The S/390 port is there. Some nice-sounding bugfixes are there, so I'll probably recompile tonight. Also, supposedly it should now compile fine with gcc 2.95.
Re:The importance (or lack thereof) of uptime (Score:5)
Off course not all systems run under the same conditions; windows computers are probably more often turned off at night than VMS systems, SunOS is usually used on high-end hardware while Linux often runs on crappy hardware and OpenBSD-systems probably have better admins than Linux-systems (no offense, but most unix-newbies tend to use Linux, not *BSD). But still I dare say that the uptime is a real good measurement for the stability of an operating system.
Apart from that I agree with the fact that one should not fail to upgrade because one wants to get the highest uptime possible. On the other hand, people shouldn't upgrade when there's no need to; if there are no new features/fixes in the new kernel which apply to your system, don't upgrade :)
Check http://www.uptimes.net [uptimes.net] for a list of uptimes per OS. There are about 500 hosts in the list, so it ought to give a rather clear view of the situation.
Re:Ken Thompson (Score:5)
[...time passes...]
Alright, here you go. Read this, which I got from IEEE Computer Magazine [computer.org]:
Delving deeper, we have this article [linuxtoday.com] by Eric Raymond in Linux Today, in which he clarifies what Ken said, as follows: The really bad news, of course, is that Ken was wrong about the volatile and irrational reaction by the members of the Linux community against those who cast aspersions on the current state of apotheosis of Linux--or of the FSF, for that matter. This kind of thing most certainly does happen, as all here can doubtless attest. So much for the good old days.The importance (or lack thereof) of uptime (Score:5)
Uptime should *never* be sacred to any computer user in the sense that preserving a high uptime should not preclude one from installing a neccessary software or hardward upgrade. What is important is that an operating system has the ability to run stably and for extended periods of time such that the use of the computer is not impaired. I've known quite a few users who claim ridiculously high uptimes (ie. > 1 year). The kernel is so out of date that any random script kiddie can grab an exploit or buffer overflow from bugtraq and root the system, obviously not a Good Thing if your computer is running any sort of critical task.
Uptime is just that: a measure of how much time has elapsed since the last reboot of the system. It does not measure any of the following things:
-Superiority of an operating system
-Ability to administer a computer
-Programing skill
-"Eliteness/coolness", whatever that is