I've seen this sort of thing many times over the years.
A few years ago I had a problem with Compaq DAT drives self destructing after a few months of regular use. Compaq never admitted that there was a problem, but the drives would be replaced, where they'd fail again. ISTR having simillar problems with 1/4 inch catridge drives before then, also with Compaq.
I've also been aware of numerous faults with low-volume manufacturers. I spent a short time working for one, and in that time discovered that they had a serious problem with every machine that they'd recently shipped, if that machine was running Windows98. Automatic shutdown would power down the system before the disk cache had been completely flushed, leading to corrupted filesystems. Although there was a simple fix, and they knew the details of everyone affected, they didn't bother to notify them unless the customer reported a problem. I walked out after this and other frightening issues.
I'm annoyed that Cathedral is used to describe a system whose design is consistant.
I live in England. I live around 200 yards from Ripon Cathedral. This building is the only on in the UK (if not the world) that has portions in every arcitechtural style from Norman (10-11th century) to Perpendicular (15-16th century). ESR's rantings just cause me to burst out into hysterical laughter.
They can't have been very good network trouble shooters if astounded by Ethereal.
When I worked in networking, a sniffer that could decode the protocol I dealt with was the only real tool I used. At the time Lanwatch was the only one that could really decode the protocol I used.
The article on the de Havalind Comet is also inacurrate. True the initial model did crash due to metal fatigue, but by redesigning the shape of the passenger windows the Comet 4 was a successful design. In fact the RAF's Nimrod was based upon rebuilt Comet 4s and should be in service for many more years to come.
I once worked for a UK PC seller. I only worked for them for a couple of days, but in that time learn't so much that I'm wary of almost everyone in this industry.
I took up the post because of their good reviews in the UK computer press. Once I started with them I realised that the reason they got the good reviews was that the review machines were produced on a totally different production line to those sold to the public. The casing was of a far superior quality, and the disk cabling was tied up and routed together. The publicly sold machines were shoddy by comparison - for example I managed to damage a soundcard on removing a cover because the loose cabling got caught in the case.
They had a problem with disk caches on Windows98 machines where the ATX powerdown would cause the drive to power off prior to a cache flush, causing lost data. They knew of the fix for this, but didn't bother to contact customers until a fault was reported. What b*st*rds!
I also had a customer ring up and complain that the NICs we had supplied them with did not work, and would I supply Windows NT drivers for them. No-one in the factory could tell me what type of card they were sold, and the serial number did not match. I just emailed them every NIC driver I could find. Even Emailing them was difficult, as the access to outgoing internet mail was so contrived, mainly by the managing director being so bloody ignorant on security.
They also treated the customers like dirt - once they had the money they didn't want to know. I was told off by the boss for taking too long to resolve a problem - despite the fact that the customer was satisified when all was working.
There were other aspects of the position as well, such as me being asked to steal support contracts from my past employer to gain customer details, and used goods being passed on as brand-new.
I didn't bother to turn up after 2 days. Unfortunatley they are still in business. Email me if you want to know their name!
When I had an Atari VCS many years ago, I had a copy of the Spacewar cartridge (which at the time was only available in Europe, as it was PAL only). There were around 10 different versions of the game, with features such as elastic or warping galaxy boundaries, and the central body was either a sun or a space station. Hitter the former caused a loss of life, and the latter replenished fuel and weapons.
This version was more playable than this, but then again so is anything not written in Java. The only issue here is that the graphics are more accurate.
Is it me, or is Java the most overhyped, unstable, resource hungy idea to enter this industry in 10 years. Not everyone has an up-to-date processor.
Having had to move to London to find work, I feel that all the people are downright miserable gits. I don't think I have had a single conversation with anyone outside work since moving down there, apart from a long conversation on the bus when travelling back north - and he was a Geordie!
In London people with no skills whatsoever seem to get paid £25,000 with no problems - the person who sits next to me is one such person.
The main problem with the UK is the large percentage of clueless managers who don't have a clue about the skills of the people they hire or fire, or any of the technology they are dealing with. The boss of my department thinks the clueless numbskull who sits next to me is exceedingly talented - this is someone who does not even know what a comma delimited file is, for gods sake.
The biggest problem with London is accomodation pricing - quite simply it is obscene, and has risen sharply in the 4 months I have been working down there.
Ever tried installing Netscape Communicator from a tarball recently? Ever release I have tried from 4.5 onwards has been dynamically linked against a different C++ runtime. There is a workaround to create symlinks pointing to the current library, but these do not always work, giving undefined symbols.
The C++ library depends upon the revision of the compiler used to create the executable, and must also be itself linked against the correct libc. My box used to have 6 different C++ runtimes in place to allow me to run different packages, and getting hold of some of them was a nightmare. (Try finding the one generated by egcs when compiled on a libc5 system!).
This is the major problem with binary files under Linux, and the reason why I compile the binary if I can. It is making binary distribution a nightmare.
I cannot see the point in using closed source code on anything as fundamental as a firewall. Most closed source products I have seen have some form of back-door built into them for the manufacturers own use, but this mechanism does often fall into the wrong hands, and I have seen dissasterous results as a consequence.
The last commercial firewall I saw was Borderware. It was utterly appalling. The hardware choice was very limited - only certain SCSI cards were supported, and network cards had to be set to specific I/O addresses and IRQs. Finding a platform it would run on was difficult, sometimes impossible. It could only be configured by a very slow Java interface, which due to differences in Jave meant that the only supported client interface was a particular release of Netscape Navigator.
Finally, and most insulting, a customer of mine had a serious security breach, allowing remote users to use the firewall as a mail relay. Borderware were aware of the fault, and stated that a fix would be available in the next release, due out in 6 months time. Unbelievable!
I will never run a commercial firewall - they are mainly installed by the ignorant.
I've used systems like this in the past, but not Zenworks. The problem with every product is that they need a lot of knowledge to configure them correctly in the first place. Misadministration will cause much unwanted network activity, performance costs, and generally prevent people from doing their work.
I can give an example. The site where I am currently reluctantly employed uses Ghost to configure all their Win95 PCs, which was a management decision. I do not know who was responsible for the initial PC build, but it has a number of terrible faults. Basically, whoever did it was clueless regarding PC installations - the default IDE driver is used, without DMA, as opposed to the correct driver from the PC manufacturer. Consequentially, all PCs are running at around 20% efficiency when accessing the hard disk. In addition, many applications are incorrectly configured. The company has then decided to use a software deployment and asset management package to manage all these workstations. This was installed on the Ghost image, but again not configured correctly. We now have an asset management database with 100s of unknown PCs, not one of them can be traced. Management themselves are blaming my department, yet we did not roll out the software.
The other major problem with these machines is that they are dual login (WinNT, Novell 3). Every PC has the name service provider in the incorrect order, meaning it can take up to 5 minutes to log into the morning.
I do not like these so called administration saving products. Every time I hace seem them installed, an idiot has been responsible, and the whole site has badly configured machines.
Then again, the industry nowadays is full of ignorant morons who do not deserve their pay-cheques.
My system used to be loosley based on an old Slackware (can't remember the version, but it came with a 2.0.0 kernel). I gradually upgraded over time, installing and upgrading everything from source, but in the end I built my own from scratch, using an old slakware to compile the basics. I also needed glibc2.1.
I have tried other distros, SuSe, various Redhats and a couple of other lesser ones. It seems to be the case the most of the packages are misconfigured, or not properly tuned. And there are also problems with dependencies upon particular libraries. I now build everything from source - the only binary install on my box is Netscrape, and I had problems with that due to the C++ runtime libraries.
Modern distros seem to be attracting the moron market - the users that think that all config is done through a GUI, To extend this, a UK Linux magazine hit the newstands. Pages and pages of screenshots of dialog boxes on how to setup IP addresses, with not a script sample in sight. A complete waste of £5, as the cover CD contains Redhat 6.0.
If Redhat continues in this way, we are going to end up with a lot of clueless Linux admins, who havn't a clue whats going on underneath, in the same way now that the NT world is full of useless idiots. Point, click, drool, euch! Even where I work now there is a so-called Unix admin who can't extra a tarball. I dread to think what will happen in the future.
When Banyan started supporting the Macintosh, the first release of the OS with Mac filesystem support was really flakey.
They added a separate FS layer after the fsck that checked additional filesystem structures. On a server with no macintosh files, this could take 2 hours on a 486 with approx 6GB of data. I came across a server hosting some macintosh services that took all day after an enforced reboot to come back up. This process could not be easily circumvented in those early days.
I can't recall anyone using Macintosh support on these servers for very long, most of the systems I supported were ripped out after 6 months.
SCO UNIX (at least the releases I have used) and prior to that Xenix were very poor implementations of Unix.
When I had to support a number of SCO systems it was very buggy, and difficult to install on fairly common hardware platforms.
Back in 1992 I supported a number of Xenix systems. There was a well known bug in the fs code that caused the superblock to erroneously report too little free space, and requiring a regular fsck. Could SCO be bothered to fix it - no!
Later we switched to SCO unix - this was equally poor. For example installing and removing a LPD aware version of the print subsystem (via a couple of MKDEV scripts) completly messed up the entire print system, requiring a reinstallation of base OS packages. The cause of the fault was an error in the script - it made a backup copy of the executables, but copied the files back. A bit of care could have prevented the whole problem. There were some other equally hairy faults, but the mists of time has clouded my memory.
The biggest pain was having to pay more for the compiler, TCP/IP and NFS - each was then a different package.
Obtaining patches from SCO used to be very difficult, with a list of files but no description of what they did. Support in the UK was non existant - we had a 3rd party to go through, who like 99% of 3rd party support organisations knew sod all. (It was made worse by my boss selling a SCO support contract which covered both our software and the OS to a major 24 hour site).
SCOs lack of QA testing for the OS lost them (and UNIX in general) at lot of users. The sooner SCO disappears from the planet, the better!
In the UK in the 1970's, Cadbury's used a family of robots to advertise their Smash instant mashed potato. They appeared very high tech, and the budget for the commercials appeared to be more than the amount the BBC put into the over-rated Dr Who. They appeared to be very intelligent beings.
There was a whole family, including a cat, if my memory isn't failing. They were pitched against the Oxo family, and the PG Tips chimps.
Who else remembers them? Some sad individual somewhere must have a website dedicated to them.
If you want to really see bloat with Corba, look at the agent processes supplied as part of CA Unicenter.
It varies from OS to OS, but on most systems the agents, which do no more than monitor a few OS stats and parameters (and badly chosen ones too:-) ), take up at least 32MB of RAM, and a large percentage of CPU cycles. Neither of these are acceptable for the purpose this software was designed for - systems management. The system is consequentially unusable in the environment I have been tasked to install it in.
It is often the case that software developers adopt a new technology without realising the full consequences, and when they do, it is too late to go back. I have seen a major application become unusable due to the developers wanting to recode the next version in C++, as opposed to ironing out the bugs in the C port. This application consumed four times as much memory, was noticably slower, and was incompatable with the majority of existing installations. CORBA appears to be the new fad.
I may even get round to trying a development release KDE 2.0. I have not been able to install KDE 1.1.2, as I can't get Qt to compile with gcc-2.95.1. Maybe 2.95.2, just released will fix this.
I've been having sporadic hangs with the bttv TV card driver for a while, and I noticed that the 2.2.13 pre patches contained a fixed driver, which modifies the interrupt code. I have not installed any of the pre-patches.
I will compile now and see if this fixes my problem, and report back.
Having thought about this a bit more, and checked some drivers, this is not exactly the case. In fact all the code I have looked at will exit immediately on a wrap-around condition. Counting jiffies is not too common, though.
Therefore at around the roll-over time, some device drivers may fail temprarily.
The volatile variable jiffies is used in some kernel drivers as a quick and dirty counter. Jiffies is incremented every clock tick, which in the i386 kernel occurs 100 times a secound.
Some drivers perform waits by monitoring jiffies until it reaches a calculated value. If one of these loops starts just before jiffies wraps around, then the value calculated should also wrap around, providing the correct data-type is used. Therefore such a loop should still exit normally.
If you're feeling paranoid, search the source of all the drivers you use in your version of the kernel.
There are some modules that depend upon other modules being available, although the configuration process does not check - a common one being the bttv TV card driver, which also requires sound drivers enabled.
More infomation will allow others to help you better.
Although I have the latest 2.3.x source tree bar one, I have not played with it as much as I did with 2.1.x, mainly due to a lack of time.
One of the major improvements seems to be the changes with the filesystem caching mechanism. 2.2.x and earlier used two separate caches, one for reads and the other for writes. 2.3.x amalgamates them together into one single cache. Is the performance any better??
The other changes appear to be mainly for hardware I do not have (still using a humble Pentium 100).
I will be applying 2.3.19 this weekend, recompile PPP to use the new kernel, and switch exclusivly to 2.3.x. Heck, most of my system is running seat of the pants releases as it is, one more will not make too much difference.
Slashdot Mirror
At least one of those hotfixes, Q276324, is not available for download. Pity as it appears to resolve a problem I've got here.
A few years ago I had a problem with Compaq DAT drives self destructing after a few months of regular use. Compaq never admitted that there was a problem, but the drives would be replaced, where they'd fail again. ISTR having simillar problems with 1/4 inch catridge drives before then, also with Compaq.
I've also been aware of numerous faults with low-volume manufacturers. I spent a short time working for one, and in that time discovered that they had a serious problem with every machine that they'd recently shipped, if that machine was running Windows98. Automatic shutdown would power down the system before the disk cache had been completely flushed, leading to corrupted filesystems. Although there was a simple fix, and they knew the details of everyone affected, they didn't bother to notify them unless the customer reported a problem. I walked out after this and other frightening issues.
I live in England. I live around 200 yards from Ripon Cathedral. This building is the only on in the UK (if not the world) that has portions in every arcitechtural style from Norman (10-11th century) to Perpendicular (15-16th century). ESR's rantings just cause me to burst out into hysterical laughter.
The Cathedral vs The Bazaar - pah!
I'd rather they went after Computer Associates - those bastards should be shut down for some of their stunts, some of which are illegal in Europe.
When I worked in networking, a sniffer that could decode the protocol I dealt with was the only real tool I used. At the time Lanwatch was the only one that could really decode the protocol I used.
I need to reinstall XFree86 at sometime anyway, as a disk crash due to a power outage caused fsck to remove some files.
The article on the de Havalind Comet is also inacurrate. True the initial model did crash due to metal fatigue, but by redesigning the shape of the passenger windows the Comet 4 was a successful design. In fact the RAF's Nimrod was based upon rebuilt Comet 4s and should be in service for many more years to come.
I once worked for a UK PC seller. I only worked for them for a couple of days, but in that time learn't so much that I'm wary of almost everyone in this industry.
I took up the post because of their good reviews in the UK computer press. Once I started with them I realised that the reason they got the good reviews was that the review machines were produced on a totally different production line to those sold to the public. The casing was of a far superior quality, and the disk cabling was tied up and routed together. The publicly sold machines were shoddy by comparison - for example I managed to damage a soundcard on removing a cover because the loose cabling got caught in the case.
They had a problem with disk caches on Windows98 machines where the ATX powerdown would cause the drive to power off prior to a cache flush, causing lost data. They knew of the fix for this, but didn't bother to contact customers until a fault was reported. What b*st*rds!
I also had a customer ring up and complain that the NICs we had supplied them with did not work, and would I supply Windows NT drivers for them. No-one in the factory could tell me what type of card they were sold, and the serial number did not match. I just emailed them every NIC driver I could find. Even Emailing them was difficult, as the access to outgoing internet mail was so contrived, mainly by the managing director being so bloody ignorant on security.
They also treated the customers like dirt - once they had the money they didn't want to know. I was told off by the boss for taking too long to resolve a problem - despite the fact that the customer was satisified when all was working.
There were other aspects of the position as well, such as me being asked to steal support contracts from my past employer to gain customer details, and used goods being passed on as brand-new.
I didn't bother to turn up after 2 days. Unfortunatley they are still in business. Email me if you want to know their name!
When I had an Atari VCS many years ago, I had a copy of the Spacewar cartridge (which at the time was only available in Europe, as it was PAL only). There were around 10 different versions of the game, with features such as elastic or warping galaxy boundaries, and the central body was either a sun or a space station. Hitter the former caused a loss of life, and the latter replenished fuel and weapons.
This version was more playable than this, but then again so is anything not written in Java. The only issue here is that the graphics are more accurate.
Is it me, or is Java the most overhyped, unstable, resource hungy idea to enter this industry in 10 years. Not everyone has an up-to-date processor.
Please learn to spell Perl, you sound like a recruitment agency! :->
Having had to move to London to find work, I feel that all the people are downright miserable gits. I don't think I have had a single conversation with anyone outside work since moving down there, apart from a long conversation on the bus when travelling back north - and he was a Geordie!
In London people with no skills whatsoever seem to get paid £25,000 with no problems - the person who sits next to me is one such person.
The main problem with the UK is the large percentage of clueless managers who don't have a clue about the skills of the people they hire or fire, or any of the technology they are dealing with. The boss of my department thinks the clueless numbskull who sits next to me is exceedingly talented - this is someone who does not even know what a comma delimited file is, for gods sake.
The biggest problem with London is accomodation pricing - quite simply it is obscene, and has risen sharply in the 4 months I have been working down there.
Ever tried installing Netscape Communicator from a tarball recently? Ever release I have tried from 4.5 onwards has been dynamically linked against a different C++ runtime. There is a workaround to create symlinks pointing to the current library, but these do not always work, giving undefined symbols.
The C++ library depends upon the revision of the compiler used to create the executable, and must also be itself linked against the correct libc. My box used to have 6 different C++ runtimes in place to allow me to run different packages, and getting hold of some of them was a nightmare. (Try finding the one generated by egcs when compiled on a libc5 system!).
This is the major problem with binary files under Linux, and the reason why I compile the binary if I can. It is making binary distribution a nightmare.
I cannot see the point in using closed source code on anything as fundamental as a firewall. Most closed source products I have seen have some form of back-door built into them for the manufacturers own use, but this mechanism does often fall into the wrong hands, and I have seen dissasterous results as a consequence.
The last commercial firewall I saw was Borderware. It was utterly appalling. The hardware choice was very limited - only certain SCSI cards were supported, and network cards had to be set to specific I/O addresses and IRQs. Finding a platform it would run on was difficult, sometimes impossible. It could only be configured by a very slow Java interface, which due to differences in Jave meant that the only supported client interface was a particular release of Netscape Navigator.
Finally, and most insulting, a customer of mine had a serious security breach, allowing remote users to use the firewall as a mail relay. Borderware were aware of the fault, and stated that a fix would be available in the next release, due out in 6 months time. Unbelievable!
I will never run a commercial firewall - they are mainly installed by the ignorant.
I've used systems like this in the past, but not Zenworks. The problem with every product is that they need a lot of knowledge to configure them correctly in the first place. Misadministration will cause much unwanted network activity, performance costs, and generally prevent people from doing their work.
I can give an example. The site where I am currently reluctantly employed uses Ghost to configure all their Win95 PCs, which was a management decision. I do not know who was responsible for the initial PC build, but it has a number of terrible faults. Basically, whoever did it was clueless regarding PC installations - the default IDE driver is used, without DMA, as opposed to the correct driver from the PC manufacturer. Consequentially, all PCs are running at around 20% efficiency when accessing the hard disk. In addition, many applications are incorrectly configured. The company has then decided to use a software deployment and asset management package to manage all these workstations. This was installed on the Ghost image, but again not configured correctly. We now have an asset management database with 100s of unknown PCs, not one of them can be traced. Management themselves are blaming my department, yet we did not roll out the software.
The other major problem with these machines is that they are dual login (WinNT, Novell 3). Every PC has the name service provider in the incorrect order, meaning it can take up to 5 minutes to log into the morning.
I do not like these so called administration saving products. Every time I hace seem them installed, an idiot has been responsible, and the whole site has badly configured machines.
Then again, the industry nowadays is full of ignorant morons who do not deserve their pay-cheques.
Agree totally.
My system used to be loosley based on an old Slackware (can't remember the version, but it came with a 2.0.0 kernel). I gradually upgraded over time, installing and upgrading everything from source, but in the end I built my own from scratch, using an old slakware to compile the basics. I also needed glibc2.1.
I have tried other distros, SuSe, various Redhats and a couple of other lesser ones. It seems to be the case the most of the packages are misconfigured, or not properly tuned. And there are also problems with dependencies upon particular libraries. I now build everything from source - the only binary install on my box is Netscrape, and I had problems with that due to the C++ runtime libraries.
Modern distros seem to be attracting the moron market - the users that think that all config is done through a GUI, To extend this, a UK Linux magazine hit the newstands. Pages and pages of screenshots of dialog boxes on how to setup IP addresses, with not a script sample in sight. A complete waste of £5, as the cover CD contains Redhat 6.0.
If Redhat continues in this way, we are going to end up with a lot of clueless Linux admins, who havn't a clue whats going on underneath, in the same way now that the NT world is full of useless idiots. Point, click, drool, euch! Even where I work now there is a so-called Unix admin who can't extra a tarball. I dread to think what will happen in the future.
When Banyan started supporting the Macintosh, the first release of the OS with Mac filesystem support was really flakey.
They added a separate FS layer after the fsck that checked additional filesystem structures. On a server with no macintosh files, this could take 2 hours on a 486 with approx 6GB of data. I came across a server hosting some macintosh services that took all day after an enforced reboot to come back up. This process could not be easily circumvented in those early days.
I can't recall anyone using Macintosh support on these servers for very long, most of the systems I supported were ripped out after 6 months.
SCO UNIX (at least the releases I have used) and prior to that Xenix were very poor implementations of Unix.
When I had to support a number of SCO systems it was very buggy, and difficult to install on fairly common hardware platforms.
Back in 1992 I supported a number of Xenix systems. There was a well known bug in the fs code that caused the superblock to erroneously report too little free space, and requiring a regular fsck. Could SCO be bothered to fix it - no!
Later we switched to SCO unix - this was equally poor. For example installing and removing a LPD aware version of the print subsystem (via a couple of MKDEV scripts) completly messed up the entire print system, requiring a reinstallation of base OS packages. The cause of the fault was an error in the script - it made a backup copy of the executables, but copied the files back. A bit of care could have prevented the whole problem. There were some other equally hairy faults, but the mists of time has clouded my memory.
The biggest pain was having to pay more for the compiler, TCP/IP and NFS - each was then a different package.
Obtaining patches from SCO used to be very difficult, with a list of files but no description of what they did. Support in the UK was non existant - we had a 3rd party to go through, who like 99% of 3rd party support organisations knew sod all. (It was made worse by my boss selling a SCO support contract which covered both our software and the OS to a major 24 hour site).
SCOs lack of QA testing for the OS lost them (and UNIX in general) at lot of users. The sooner SCO disappears from the planet, the better!
In the UK in the 1970's, Cadbury's used a family of robots to advertise their Smash instant mashed potato. They appeared very high tech, and the budget for the commercials appeared to be more than the amount the BBC put into the over-rated Dr Who. They appeared to be very intelligent beings.
There was a whole family, including a cat, if my memory isn't failing. They were pitched against the Oxo family, and the PG Tips chimps.
Who else remembers them? Some sad individual somewhere must have a website dedicated to them.
I applaud KDE for this decision.
:-) ), take up at least 32MB of RAM, and a large percentage of CPU cycles. Neither of these are acceptable for the purpose this software was designed for - systems management. The system is consequentially unusable in the environment I have been tasked to install it in.
If you want to really see bloat with Corba, look at the agent processes supplied as part of CA Unicenter.
It varies from OS to OS, but on most systems the agents, which do no more than monitor a few OS stats and parameters (and badly chosen ones too
It is often the case that software developers adopt a new technology without realising the full consequences, and when they do, it is too late to go back. I have seen a major application become unusable due to the developers wanting to recode the next version in C++, as opposed to ironing out the bugs in the C port. This application consumed four times as much memory, was noticably slower, and was incompatable with the majority of existing installations. CORBA appears to be the new fad.
I may even get round to trying a development release KDE 2.0. I have not been able to install KDE 1.1.2, as I can't get Qt to compile with gcc-2.95.1. Maybe 2.95.2, just released will fix this.
I've been running the new code for 2 hours, and not had a crash, yet.
The patch adds an extra cli() to the bttv.c code, which appears to fix a part of the driver where interrupts could be disabled and not re-enabled.
No one else using it??
I've been having sporadic hangs with the bttv TV card driver for a while, and I noticed that the 2.2.13 pre patches contained a fixed driver, which modifies the interrupt code. I have not installed any of the pre-patches.
I will compile now and see if this fixes my problem, and report back.
Having thought about this a bit more, and checked some drivers, this is not exactly the case. In fact all the code I have looked at will exit immediately on a wrap-around condition. Counting jiffies is not too common, though.
Therefore at around the roll-over time, some device drivers may fail temprarily.
The volatile variable jiffies is used in some kernel drivers as a quick and dirty counter. Jiffies is incremented every clock tick, which in the i386 kernel occurs 100 times a secound.
Some drivers perform waits by monitoring jiffies until it reaches a calculated value. If one of these loops starts just before jiffies wraps around, then the value calculated should also wrap around, providing the correct data-type is used. Therefore such a loop should still exit normally.
If you're feeling paranoid, search the source of all the drivers you use in your version of the kernel.
What are the unresolved symbols?
There are some modules that depend upon other modules being available, although the configuration process does not check - a common one being the bttv TV card driver, which also requires sound drivers enabled.
More infomation will allow others to help you better.
Although I have the latest 2.3.x source tree bar one, I have not played with it as much as I did with 2.1.x, mainly due to a lack of time.
One of the major improvements seems to be the changes with the filesystem caching mechanism. 2.2.x and earlier used two separate caches, one for reads and the other for writes. 2.3.x amalgamates them together into one single cache. Is the performance any better??
The other changes appear to be mainly for hardware I do not have (still using a humble Pentium 100).
I will be applying 2.3.19 this weekend, recompile PPP to use the new kernel, and switch exclusivly to 2.3.x. Heck, most of my system is running seat of the pants releases as it is, one more will not make too much difference.