I did something simillar, but I used a Linux root/boot floppy, and dd'd the image too and from tape. I used this for a number of OS's, including Linux, Win/NT.
Luckily I had access to a number of spare tapes that were surplus to requirements.
The system broke down when I needed to install Banyan VINES - vines needed the IDE drive parameters modifying. Then someone at work stole my tape drive whilst I was out of the office.
How many NT machines are installed incorrectly?
on
CNN Installs Linux
·
· Score: 1
I started work at a major UK high-street company 3 months ago, working for a contractor. (I don't want to mention their name or even field of work).
I quickly discovered that ever NT Workstation and Windows 95 machine was incorrectly installed, resulting in severe performance problems.
Not one of the 100s of IDE machines based at either the HQ or the remote sites had had DMA enabled on the IDE channel. This is a fundamental with either operating system; in 95 it can be circumvented by installing the latest driver disk from the motherboard chipset manufacturer, and under NT a registry key needs setting - Microsoft even provide a utility to set the key automatically. This simple change produces dramtic results, freeing up many wasted CPU cycles.
There were other problems as well with the network client taking a long time to resolve names, due to the incorrect protocol order.
This got me thinking - how many machines worldwide are setup in such a way? Must be millions. In fact I've hardly ever come across a Windows95 machine that has had the correct IDE drivers installed.
I reverse engineered a few 8-bit games in the mid 80's. I have honestly not even thought of this for at least 10 years. I mainly cracked games on the ZX Spectrum, using a Z80 processor.
Uncommented assembler is very difficult to understand, althogh a couple of games did leave an ASCII dump of part of the source giving clues to the purpose of a couple of symbols. Looking at the individual operations may give some clues - XORs were common in many display manipulation routines.
The best mechanism I had was to look for addresses pointing to the start of the data areas, which could usually be easily found with an ASCII or HEX dump. This worked well with adventure games, until they started to use complex data compression mechanisms. I did manage to reverse engineer some simpler compression mechansims, but these mainly used substitution through look-up tables.
Another method I used, which worked with the action games, was to look for an instruction that assigned the accumulator register with the number of lives. This instruction was often infrequent, and by a process of elimination the correct one could be deduced. The next step was to look at the code around this instruction to find the address that this counter was stored in, and then look for all other occurrances of this memory address. One of these would be the code to decrease the number of lives. NOP out this instruction, and bingo, infinite lives.
The other notable reverse engineering I did was to write a printer driver for Framework that allowed my printer to both handle bitmap graphics and the pound sign by merging two drivers.
Since then, most reverse engineering has been by means of ASCII dumps of executables to discover hidden command line arguments or other messages. I also discovered a root exploit on Banyan fileservers by means of reverse engineering the toolkit install process - basically the installation mechanism ran as root, extracting a tar file to a temp location, then running a named script in that tar-file. By creating script to run sh, it was possible to access root which was otherwise impossible.
And now all these talents go wasted. I'm working with MS crap all the time, were back engineering is almost impossible, or too time consuming.
I have to use it as the central repositry for CA's Unicenter (an even crappier product). We keep having significant performance and reliability problems, and the system so far has not been fully rolled out into mainstream production.
One annoying problem is that occasionally a database will run out of space, yet there is plenty of space on the device file. There is a manual time consuming procedure that needs to be run to fix this problem - Microsoft's idea of resolving this is to schedule this process once a week!
SQL 7.0 is better, it now dynamically resizes database devices when needs arise. The management tool is a lot better, but is now a real resource hog, and requires IE 4.0 to be installed as the default web browser to function at all.
I also had nightmares in the past with both 4.21 and 6.0. There was once problem that would cause the server to lock up cold, requiring a manual reboot. MS were of course aware of it, but did not consider it such a significant problem to issue a fix. I also spent around 2 weeks with MS support attempting to get the scheduler to dump databases on s single server. The problem was caused by the sever being unable to use loopback to connect to itself with certain netlibraries. I discovered this with no help from MS.
The clueless management at my then employer considered me to be an expert on SQL server, when all I had done was install the product a few times. I had to spend hours reading 3rd party documentation to learn how to really support the product.
I recall these benchmarks quite well. It happened when accelarated Windows drivers were starting to appear on the marked.
One test repeatedly wrote a short phrase to random parts of the screen, and video driver manufacturers hard-coded this string into their driver to make this benchmark run as fast as possible. I infact did an ASCII dump of one such video driver, and found this string embedded in there.
Another was to test the polygon drawing API calls. The benchmark drew multiple pentagons, and the video driver authors then optimised their code to handle pentagons as quickly as possible, at the detriment to other polygons.
This just shows how dishonest some closed source authors can be, and since that day I have never paid any attention to a benchmark, as in the real world they prove very little.
Funny, you never see this evil activity in the open-source community, do you?
ISDN's cost was not BT's only problem.
on
ISP War in the UK
·
· Score: 2
I was involved with the roll-out of ISDN to a number UK teleworkers a few years ago.
We had a constant problem where the ISDN connection to one teleworker's home would suddenly fail. A call would be placed to BT to resolve the fault, and it would eventually be fixed. In some areas this could happen two to three times a month.
I eventually managed to speak to a BT engineer. He stated that some BT engineers where cutting corners when connecting up unused pairs in the trunking system to traditional analogue phones. Instead of checking the documentation to discover which wire pairs were unused, to save time they measured the voltage across the pair - if there was no voltage it was assumed the pair was unused. Unfortunatly ISDN pairs also carried no voltage when not being used, and the ISDN pair got patched into the analogue network!
Of course BT never admitted a problem.
Also, when my employer relocated a few years back, it took almost a week for BT to get ISDN working to our new office. Since we relied on ISDN for our email communications to and from customers and suppliers, this was a major problem.
When I got my PC around 3 years ago I installed then current Slakware using UMSDOS on the Win95 partition. It worked in a fashion, although due to the limitations of the VFAT16 filesystem, each file was hugh, even a device node took up one alloaction unit, and I quickly ran out of space. There were additional problems with UMSDOS and VFAT16 not being totally compatable with each other, and some Win95 files lost their long filenames. I even added an icon to the start menu to boot straight into Linux.
This distribution has been made possible by advancements made with VFAT32 support in UMSDOS.
As a matter of fact I recently installed the VFAT32 version of Windows95, to allow me to run some games, and also to browse a job related website that only works with IE4 (natch!). I will probably stick a UMSDOS filesystem on this drive to allow me to share the disk between the 2 operating systems.
Re:Why IP? Lets Invent a new Protocol...
on
CNN On IPv6
·
· Score: 1
Well Banyan had a 48-bit network address way whenever VINES IP was introduced. Also an intelligent route mangement system that worked most of the time. The only time I saw really broken routing was when a 3rd party router was introduced to the network. Scorpion/Xylogics ISDN devices could mess the routing tables up so badly that they could induce server panics.
Unfortunatly Banyan suffered from a lack of marketing, and a scant regard for quality control in their later years - ever seen BeyondMail 3.0.
I have many tales of Banyan if anyone is interested.
I've always wanted to try a *BSD, and now that I've blown away my Lose95 partition, I am able to do so.
Is there any easy way to get hold of a CD in the UK? The local company that used to stock various CDs of this nature a few years ago seems to no longer bother to stock anything actually useful.
What has happened to the IT industry? Quite simply too many clueless people are being employed, usually hired by equally if not more clueless management.
I've seen networks brought to their knees entiely due to management making decisions on the network topology. I have seen distributed networks fail due to a management descision to consolidate all logins to one single server! (Doh!) I have spent hours trying to bring dead systems back to life because no one bothered to maintain or monitor the system for 7 years, hoping the system would look after itself, and once I got it working the machine suffered a catastrophic hardware failure, and no more spares were avaialble world wide. And it goes on...
The most ironic thing is that earlier this year I spent 4 months out of work. For every single interview, the decision rested on someone with no technical experience. I've found a position now, but it is 200 miles from home, and half the team I have to work don't deserve their position.
There are too many fools in this industry making decisions. No wonder NT is so bloody popular.
The moron who thought of this, and the bozo who hired him should never be allowed to touch a keyboard again.
They could have been bought out by Computer Associates.
Visio would then be renamed DrawIT or something simillar, and then have CAs terrible software licensing added to it, which basically prevents the software from running until a 70 character keycode is typed in.
I had the same problem with KDE 1.1.1. However since then I have upgraded to gcc-2.95.1 and the latest binutils (the latter to hoepfully resolve some linking problems elsewhere). However I have not got round to trying a compiling KDE again, as I knew that 1.1.2 was due anytime.
What versions of gcc, binutils, glibc did you use?
Try downloading the URW fonts - there's a link somewhere on the Gimp website. These fonts are a scalable set of the common Postscript fonts.
Another common problem is that some X configurations have FontPath references to the 75 and 100 dpi directories without the unscaled keyword, typically at the end of the list of fontpaths. This leads to X scaling any 75 or 100 dpi font to fit if an exact match or scalable font is not found. Commenting out these lines should prevent this from happening. Netscape uses some odd sizes for the Times Roman font which doesn't help.
It may be a good idea to install the Gnome font viewer, part of the Gnome utilities. This will inidicate which fonts are currently installed, and if they are scaled or exact size matches.
Some variables could only store numerical values, which were defined as a number of numeric digits, presumably using BCD as the internal storage value. It was necessary to use magic numbers to indicate special conditions, such as EOF or no more records. Since most files were indexed sequentially, all 9s was often used as special EOF indicator since it would always be sorted last.
However, by the mid 1980s, COBOL introduced a special value, HIGHVALUES, to which any numerical variable could be assigned, which was always higher than all 9s, and was to be recommended for such magic numbers. I think there was an equivalent LOWVALUES as well.
I do not know when these to keywords were introduced, but it was at least 15 years ago.
If 9/9/99 is a problem with COBOL, it must be using a very old variant of the language.
At a previous employee, we initially used Pipex as our ISP, and they had a mailing list of all site admins to which reports of this nature were sent. I believe that it covered problems outside of Pipex's own jurisdiction, but mainly affecting the UK. I recall receiving many outage notifications, and a few security issues with well used pieces of software.
However one prat at my employer began to hold too much power, and changed our ISP to another cheaper one, one that would not even inform us that they had shut down their news-server permanently.
If any of the moaning posters bothered to read the source and compile it themselves, they might realise that passing options to configure would reduce the size and components built.
I downloaded and compiled M9 this weekend, and managed to get it working. However I need to compile it again without the debug code in place, as by default it compiles with debug in everything. I ran out of time (need a faster processor!).
This weekend I'll try again.
I did receive a number of sig 11 faults during the build; more importantly I found the cause of them and ways of working around them. AFAIK, neither of the causes of the sig 11's were in sig 11 FAQ. One cause was a lack of conventional memory when ld was processing a large link. In this case exiting X appeared to resolve the problem. The other cause was a lack of disk space, seen during the building of a 50MB library. I had around 100MB free, but there was not enough disk space for the scratch-files and a core dump. Running 'make clean' and building the components in a different order fixed this, but I ran out of disk space completly.
Finally got it compiled by blowing away my 800+MB Win95 partition. When finished there was only 1% free.
I got so fed up of waiting for this to happen that I rolled my own setup. Everything on my system I have personally compiled, and all is glibc2.1, except for findutils which fails to compile. I can unfortunatly only work on it at weekends, until I change jobs.
This weekend I will be upgrading to gcc-2.95.1, installing PPP. KDE 1.1.2 should be out the week after.
Try and detect the DOS version of LANWatch. I used this a lot at a previous employer, running it on anything from a 286 luggable upwards. Since the packet driver just picked up packets, and no more (it had no IP address, IPX address or anything else), there was no way that anything else could detect this.
It would also work on a token-ring network, but in this case there would be some MAC frames put on the ring.
I will pay £1000 to anyone who could detect that such a LANWatch PC was scanning an Ethernet network.
I have used a number of sniffers and there is no way on earth that they can be detected remotely. All just capture packets - no more, no less.
Of course if the sniffer was running as a process on an NT or Windows 95 machine, then it is possible that sniffed packets get passed up to the protocol stack, but I have not been daft enough to run such a sniffer.
Looks like another means of making money out of ignorance.
I've seen this problem in the Linux community - having recently started reading uk.comp.os.linux for the first time in 6 months, I have noticed a major increase in the number of 'clueless' questions being asked - often the answer is simple. Also a lot of the replies seem as equally ill informed.
However the entire industry has changed. For 9 years I have done second-line support for a major NOS VAR in the UK. Over the past six months or so the quality of the calls being logged has dropped dramatically. For example, last month I wasted 2 days attempting to replicate a particular problem - the prime cause was that the 'idiot' logging the call could not even give me the messages scrolling up the server console, in the order they appeared; Consequentially I spent 2 days looking into what I suspected was an odd file-system corruption problem, when instead it was a incorrectly configured device driver. In the end the was only one customer that called regularly that had staff that I classed as competant.
There are now too many people working in the industry that quite frankly do not deserve their jobs - and some of these are working on contracts earning up to 1000UKP per day. I should know - I've had to support them.
Urgently looking for a position in the industry myself. Can anyone help??
If you bothered to look at the contents of the patch file, you will notice that the majority of this patch falls into 3 distinct changes.
i. New device drivers for support of additional serial cards. One of these drivers is huge with many comments. New drivers are always being added - it is called progress
ii. Minor source code changes that do not remove functionality (replacing obsoleted calls and removing include files no longer needed).
iii. Modifications to the Sparc and Sparc64 architecure trees - most users won't need this either.
How many slashdotters actually bother to check the contents of a patch to see what has changed - having worked as a support engineer for 9 years I wager that the answer is 'Not Many'.
I first came across Slackware EONs ago - I recall downloading it from Compuserve at work a couple of years before we had an internet connection.
My current setup is loosley based on a basic Slackware 3.4 with a lot of extras on top - the only binaries I have downloaded being Netscape and a glibc2 Xfree.
I still prefer slackware to any other distro - I have tried Debian, Redhat, S.U.S.E and FTlinux in the past with poor results.
I just hope that a glibc 2.1 Slackware release appears soon. I would then reinstall removing all libc5 from this machine for once and for all.
Slashdot Mirror
I did something simillar, but I used a Linux root/boot floppy, and dd'd the image too and from tape. I used this for a number of OS's, including Linux, Win/NT.
Luckily I had access to a number of spare tapes that were surplus to requirements.
The system broke down when I needed to install Banyan VINES - vines needed the IDE drive parameters modifying. Then someone at work stole my tape drive whilst I was out of the office.
I started work at a major UK high-street company 3 months ago, working for a contractor. (I don't want to mention their name or even field of work).
I quickly discovered that ever NT Workstation and Windows 95 machine was incorrectly installed, resulting in severe performance problems.
Not one of the 100s of IDE machines based at either the HQ or the remote sites had had DMA enabled on the IDE channel. This is a fundamental with either operating system; in 95 it can be circumvented by installing the latest driver disk from the motherboard chipset manufacturer, and under NT a registry key needs setting - Microsoft even provide a utility to set the key automatically. This simple change produces dramtic results, freeing up many wasted CPU cycles.
There were other problems as well with the network client taking a long time to resolve names, due to the incorrect protocol order.
This got me thinking - how many machines worldwide are setup in such a way? Must be millions. In fact I've hardly ever come across a Windows95 machine that has had the correct IDE drivers installed.
I reverse engineered a few 8-bit games in the mid 80's. I have honestly not even thought of this for at least 10 years. I mainly cracked games on the ZX Spectrum, using a Z80 processor.
Uncommented assembler is very difficult to understand, althogh a couple of games did leave an ASCII dump of part of the source giving clues to the purpose of a couple of symbols. Looking at the individual operations may give some clues - XORs were common in many display manipulation routines.
The best mechanism I had was to look for addresses pointing to the start of the data areas, which could usually be easily found with an ASCII or HEX dump. This worked well with adventure games, until they started to use complex data compression mechanisms. I did manage to reverse engineer some simpler compression mechansims, but these mainly used substitution through look-up tables.
Another method I used, which worked with the action games, was to look for an instruction that assigned the accumulator register with the number of lives. This instruction was often infrequent, and by a process of elimination the correct one could be deduced. The next step was to look at the code around this instruction to find the address that this counter was stored in, and then look for all other occurrances of this memory address. One of these would be the code to decrease the number of lives. NOP out this instruction, and bingo, infinite lives.
The other notable reverse engineering I did was to write a printer driver for Framework that allowed my printer to both handle bitmap graphics and the pound sign by merging two drivers.
Since then, most reverse engineering has been by means of ASCII dumps of executables to discover hidden command line arguments or other messages. I also discovered a root exploit on Banyan fileservers by means of reverse engineering the toolkit install process - basically the installation mechanism ran as root, extracting a tar file to a temp location, then running a named script in that tar-file. By creating script to run sh, it was possible to access root which was otherwise impossible.
And now all these talents go wasted. I'm working with MS crap all the time, were back engineering is almost impossible, or too time consuming.
SQL 6.5 is utterly ghastly.
I have to use it as the central repositry for CA's Unicenter (an even crappier product). We keep having significant performance and reliability problems, and the system so far has not been fully rolled out into mainstream production.
One annoying problem is that occasionally a database will run out of space, yet there is plenty of space on the device file. There is a manual time consuming procedure that needs to be run to fix this problem - Microsoft's idea of resolving this is to schedule this process once a week!
SQL 7.0 is better, it now dynamically resizes database devices when needs arise. The management tool is a lot better, but is now a real resource hog, and requires IE 4.0 to be installed as the default web browser to function at all.
I also had nightmares in the past with both 4.21 and 6.0. There was once problem that would cause the server to lock up cold, requiring a manual reboot. MS were of course aware of it, but did not consider it such a significant problem to issue a fix. I also spent around 2 weeks with MS support attempting to get the scheduler to dump databases on s single server. The problem was caused by the sever being unable to use loopback to connect to itself with certain netlibraries. I discovered this with no help from MS.
The clueless management at my then employer considered me to be an expert on SQL server, when all I had done was install the product a few times. I had to spend hours reading 3rd party documentation to learn how to really support the product.
I recall these benchmarks quite well. It happened when accelarated Windows drivers were starting to appear on the marked.
One test repeatedly wrote a short phrase to random parts of the screen, and video driver manufacturers hard-coded this string into their driver to make this benchmark run as fast as possible. I infact did an ASCII dump of one such video driver, and found this string embedded in there.
Another was to test the polygon drawing API calls. The benchmark drew multiple pentagons, and the video driver authors then optimised their code to handle pentagons as quickly as possible, at the detriment to other polygons.
This just shows how dishonest some closed source authors can be, and since that day I have never paid any attention to a benchmark, as in the real world they prove very little.
Funny, you never see this evil activity in the open-source community, do you?
I was involved with the roll-out of ISDN to a number UK teleworkers a few years ago.
We had a constant problem where the ISDN connection to one teleworker's home would suddenly fail. A call would be placed to BT to resolve the fault, and it would eventually be fixed. In some areas this could happen two to three times a month.
I eventually managed to speak to a BT engineer. He stated that some BT engineers where cutting corners when connecting up unused pairs in the trunking system to traditional analogue phones. Instead of checking the documentation to discover which wire pairs were unused, to save time they measured the voltage across the pair - if there was no voltage it was assumed the pair was unused. Unfortunatly ISDN pairs also carried no voltage when not being used, and the ISDN pair got patched into the analogue network!
Of course BT never admitted a problem.
Also, when my employer relocated a few years back, it took almost a week for BT to get ISDN working to our new office. Since we relied on ISDN for our email communications to and from customers and suppliers, this was a major problem.
When I got my PC around 3 years ago I installed then current Slakware using UMSDOS on the Win95 partition. It worked in a fashion, although due to the limitations of the VFAT16 filesystem, each file was hugh, even a device node took up one alloaction unit, and I quickly ran out of space. There were additional problems with UMSDOS and VFAT16 not being totally compatable with each other, and some Win95 files lost their long filenames. I even added an icon to the start menu to boot straight into Linux.
This distribution has been made possible by advancements made with VFAT32 support in UMSDOS.
As a matter of fact I recently installed the VFAT32 version of Windows95, to allow me to run some games, and also to browse a job related website that only works with IE4 (natch!). I will probably stick a UMSDOS filesystem on this drive to allow me to share the disk between the 2 operating systems.
Well Banyan had a 48-bit network address way whenever VINES IP was introduced. Also an intelligent route mangement system that worked most of the time. The only time I saw really broken routing was when a 3rd party router was introduced to the network. Scorpion/Xylogics ISDN devices could mess the routing tables up so badly that they could induce server panics.
Unfortunatly Banyan suffered from a lack of marketing, and a scant regard for quality control in their later years - ever seen BeyondMail 3.0.
I have many tales of Banyan if anyone is interested.
I've always wanted to try a *BSD, and now that I've blown away my Lose95 partition, I am able to do so.
Is there any easy way to get hold of a CD in the UK? The local company that used to stock various CDs of this nature a few years ago seems to no longer bother to stock anything actually useful.
What has happened to the IT industry? Quite simply too many clueless people are being employed, usually hired by equally if not more clueless management.
I've seen networks brought to their knees entiely due to management making decisions on the network topology. I have seen distributed networks fail due to a management descision to consolidate all logins to one single server! (Doh!) I have spent hours trying to bring dead systems back to life because no one bothered to maintain or monitor the system for 7 years, hoping the system would look after itself, and once I got it working the machine suffered a catastrophic hardware failure, and no more spares were avaialble world wide. And it goes on...
The most ironic thing is that earlier this year I spent 4 months out of work. For every single interview, the decision rested on someone with no technical experience. I've found a position now, but it is 200 miles from home, and half the team I have to work don't deserve their position.
There are too many fools in this industry making decisions. No wonder NT is so bloody popular.
The moron who thought of this, and the bozo who hired him should never be allowed to touch a keyboard again.
They could have been bought out by Computer Associates.
Visio would then be renamed DrawIT or something simillar, and then have CAs terrible software licensing added to it, which basically prevents the software from running until a 70 character keycode is typed in.
I had the same problem with KDE 1.1.1. However since then I have upgraded to gcc-2.95.1 and the latest binutils (the latter to hoepfully resolve some linking problems elsewhere). However I have not got round to trying a compiling KDE again, as I knew that 1.1.2 was due anytime.
What versions of gcc, binutils, glibc did you use?
Try downloading the URW fonts - there's a link somewhere on the Gimp website. These fonts are a scalable set of the common Postscript fonts.
Another common problem is that some X configurations have FontPath references to the 75 and 100 dpi directories without the unscaled keyword, typically at the end of the list of fontpaths. This leads to X scaling any 75 or 100 dpi font to fit if an exact match or scalable font is not found. Commenting out these lines should prevent this from happening. Netscape uses some odd sizes for the Times Roman font which doesn't help.
It may be a good idea to install the Gnome font viewer, part of the Gnome utilities. This will inidicate which fonts are currently installed, and if they are scaled or exact size matches.
Some of his comments seem to indicate he does not know what he is talking about.
How come so many large companies hire ignorant executives??
I studied COBOL in the mid 80's.
Some variables could only store numerical values, which were defined as a number of numeric digits, presumably using BCD as the internal storage value. It was necessary to use magic numbers to indicate special conditions, such as EOF or no more records. Since most files were indexed sequentially, all 9s was often used as special EOF indicator since it would always be sorted last.
However, by the mid 1980s, COBOL introduced a special value, HIGHVALUES, to which any numerical variable could be assigned, which was always higher than all 9s, and was to be recommended for such magic numbers. I think there was an equivalent LOWVALUES as well.
I do not know when these to keywords were introduced, but it was at least 15 years ago.
If 9/9/99 is a problem with COBOL, it must be using a very old variant of the language.
At a previous employee, we initially used Pipex as our ISP, and they had a mailing list of all site admins to which reports of this nature were sent. I believe that it covered problems outside of Pipex's own jurisdiction, but mainly affecting the UK. I recall receiving many outage notifications, and a few security issues with well used pieces of software.
However one prat at my employer began to hold too much power, and changed our ISP to another cheaper one, one that would not even inform us that they had shut down their news-server permanently.
If any of the moaning posters bothered to read the source and compile it themselves, they might realise that passing options to configure would reduce the size and components built.
I downloaded and compiled M9 this weekend, and managed to get it working. However I need to compile it again without the debug code in place, as by default it compiles with debug in everything. I ran out of time (need a faster processor!).
This weekend I'll try again.
I did receive a number of sig 11 faults during the build; more importantly I found the cause of them and ways of working around them. AFAIK, neither of the causes of the sig 11's were in sig 11 FAQ. One cause was a lack of conventional memory when ld was processing a large link. In this case exiting X appeared to resolve the problem. The other cause was a lack of disk space, seen during the building of a 50MB library. I had around 100MB free, but there was not enough disk space for the scratch-files and a core dump. Running 'make clean' and building the components in a different order fixed this, but I ran out of disk space completly.
Finally got it compiled by blowing away my 800+MB Win95 partition. When finished there was only 1% free.
For how many more times, it is not called X Windows!
I got so fed up of waiting for this to happen that I rolled my own setup. Everything on my system I have personally compiled, and all is glibc2.1, except for findutils which fails to compile. I can unfortunatly only work on it at weekends, until I change jobs.
This weekend I will be upgrading to gcc-2.95.1, installing PPP. KDE 1.1.2 should be out the week after.
Try and detect the DOS version of LANWatch. I used this a lot at a previous employer, running it on anything from a 286 luggable upwards. Since the packet driver just picked up packets, and no more (it had no IP address, IPX address or anything else), there was no way that anything else could detect this.
It would also work on a token-ring network, but in this case there would be some MAC frames put on the ring.
I will pay £1000 to anyone who could detect that such a LANWatch PC was scanning an Ethernet network.
I have used a number of sniffers and there is no way on earth that they can be detected remotely. All just capture packets - no more, no less.
Of course if the sniffer was running as a process on an NT or Windows 95 machine, then it is possible that sniffed packets get passed up to the protocol stack, but I have not been daft enough to run such a sniffer.
Looks like another means of making money out of ignorance.
I've seen this problem in the Linux community - having recently started reading uk.comp.os.linux for the first time in 6 months, I have noticed a major increase in the number of 'clueless' questions being asked - often the answer is simple. Also a lot of the replies seem as equally ill informed.
However the entire industry has changed. For 9 years I have done second-line support for a major NOS VAR in the UK. Over the past six months or so the quality of the calls being logged has dropped dramatically. For example, last month I wasted 2 days attempting to replicate a particular problem - the prime cause was that the 'idiot' logging the call could not even give me the messages scrolling up the server console, in the order they appeared; Consequentially I spent 2 days looking into what I suspected was an odd file-system corruption problem, when instead it was a incorrectly configured device driver. In the end the was only one customer that called regularly that had staff that I classed as competant.
There are now too many people working in the industry that quite frankly do not deserve their jobs - and some of these are working on contracts earning up to 1000UKP per day. I should know - I've had to support them.
Urgently looking for a position in the industry myself. Can anyone help??
If you bothered to look at the contents of the patch file, you will notice that the majority of this patch falls into 3 distinct changes.
i. New device drivers for support of additional serial cards. One of these drivers is huge with many comments. New drivers are always being added - it is called progress
ii. Minor source code changes that do not remove functionality (replacing obsoleted calls and removing include files no longer needed).
iii. Modifications to the Sparc and Sparc64 architecure trees - most users won't need this either.
How many slashdotters actually bother to check the contents of a patch to see what has changed - having worked as a support engineer for 9 years I wager that the answer is 'Not Many'.
The 'Mein Kampf' of the 1990's.
I first came across Slackware EONs ago - I recall downloading it from Compuserve at work a couple of years before we had an internet connection.
My current setup is loosley based on a basic Slackware 3.4 with a lot of extras on top - the only binaries I have downloaded being Netscape and a glibc2 Xfree.
I still prefer slackware to any other distro - I have tried Debian, Redhat, S.U.S.E and FTlinux in the past with poor results.
I just hope that a glibc 2.1 Slackware release appears soon. I would then reinstall removing all libc5 from this machine for once and for all.