In the UK most if not all road atlas publishers license their mapping infomation off the Ordanance Survey, a government body who publishes maps on various scales of the whole country. This ensures that they get up-to-date details, as road layout are always changing, and road numbers have a habit of being changed as well (such as the M1 around Leeds).
There would be a legal mine-field getting hold of this infomation for free. The money put into these surveys needs to be re-couped somehow.
I already have a fairly cheap dialup account, and as I don't do that much from home it works fine.
The main reason for not using the net too much at home is that dialup access is too sodding slow, even with a 56K modem.
When are Tory B Liar and his cronies and Oftel to pull their fingers out and force BT to open up the local loop, particularly for those of us who live in the smaller towns without cable.
I would move to Hull, where BT don't run things, but the place is an utter sh*t-hole.
When a former customer decommissioned their network, he purchased around 20 multi-port serial cards off them, as we had sold a number of these in the past.
What he didn't realise was that this batch of cards were 3 revisions out of date, and the current model was faster, offered more operational modes, was easier to configure, and came with better cables.
When I left the place 3 years later, all but one was still sat on the shelf. The other I took on site with me, and was sat, still wrapped up, in my over-night bag, unused since acquired.
You may find that it's running with generic IDE drivers instead of DMA/UDMA ones. It's remarkable how many Windows (95 or NT) machines I've seen configured this way.
I also know of one major company who not only had this fault with *every* desktop, but were resolving every Netware name lookup via DNS prior to NDS. It took over 5 minutes to boot up Windows and log on to their network.
I think Novell has a very decent line of products and has piss-poor marketing and sales.
Ahem! 10 years ago Novell's marketing was way ahead of Banyan, their major competitor, who had *zero* marketing, yet a powerful (at the time) product, and sold mainly on word-of-mouth.
A few years ago wasn't there talk of Lotus (now part of IBM) and Novell merging? For reasons I've since lost all memory of, the merger never went ahead.
I worked for a Banyan reseller at the time, and this news scared ourselves and some of our customers.
I'm going to d/l the 16 or so floppy images and do a base floppy install, then apt-get whatever else takes my fancy.
Unfortunatly no-one in town seems to sell blank floppies any more! Even the local supermarket sells CD-Rs, but I don't have a CD-R drive or a fast network connection.
At the time I had two mediocre-size HDDs. I installed a minimal slackware on a 300MB partition on one drive, and used this to install my own system on the second.
Within a few days of downloading I had a working system which was able to re-compile the kernel and most software. Occasionally I'd find something that wouldn't build, usually due to the build process requiring something obscure I hadn't yet installed. I learnt a lot - pity these skills havn't come in handy workwise.
The system ran for 9 months before the disk expired. I'm now running an old slackware with almost everything upgraded. Next time, though, I'll plump for Debian.
Two, the other extreme: some places you can't make ANY unauthorized changes to production code without fifteen signatures. Touching the kernel on a production server would be a firing offense.
I spent some time working at a site like that. Every change (no matter how slight or trivial) to a production or even pre-production system had to be booked in advance, and signed off by 5 different people. At least one would refuse a change, usually because they didn't understand what the change was. (The worst case was when a Unix system needed a kernel parameter change, and the Suit seemed to believe this was something to do with Kermit). As a result of this I spent two weeks doing absolutely nothing other than sitting in meetings. Some changes could take years to implement.
They would also take a long time when it came to decomissioning hardware. Some Netware servers were no longer being used, as no client PCs were configured to connect to them. Yet they left them running for 3 months before powering the things down.
I wouldn't have minded, but the rest of the department was chaos. The NT domain password had been 'password' for 18 months, none of the workstations being rolled out were set up correctly (two major performance problems), documentation on installing new servers was just plain wrong, and other utter horrors. It was amazing anything worked at all.
I heard of one site where the sysadmin shut down their router after every port scan attempt. Given that some script kiddies seem to scan subnets at random, it lead to a lot of denial of service.
Maybe they should have shut down the sysadmin instead.
What if I use my home ISP account to portscan and probe my employer's web server via Nessus to look for potential security problems from outside, and my ISPs T&Cs forbid portscanning?? This is something I propose to do for work when we move offices later this month. Would I still be in the clear?
My home ISP changed ownership last week, and I havn't looked at the new T&Cs in detail to see if this affects this one.
I'm considering more and more of getting out of the industry all together. Finding a decent position in this area is proving very difficult, with most of the ignorant fools in charge of hiring people. I've been asked some really stupid questions during interviews which has given me absolutely no confidence in the people actually hiring me. IBM themselves were particularly worrying - I complained to the agency that arranged the interview that the interviewer knew absolutely nothing about his subject.
The lunatics have definitly taken over the asylum.
There's another class of abandonware, stuff that is activly published but whose developer (a different entity) doesn't want to know.
I've had a few cases where the software either had a serious bug, or needed modifying to adapt to some other change (such as a revised API). Getting the fix was impossible, yet the product was still being sold.
Any ideas on how to workaround this, other than hand-hacking the binary?
I did helpdesk work for many a year in a simillar environment. We sold network operating systems and associated tools, and sold support contracts on to our customers. It paid quite well.
In the early days the calls were usually quite complex, usually concerning connectivity between disparate machines or getting some 3rd party tool to work in some way not envisaged by the manufacturers.
In later years we just became a helpline for any fool who would call us. I once spent 3 hours trying to determine why a mail system had lost a vast amount of mail, only to discover that the fool that called me had deleted the directory and wanted to find an excuse to cover his back. I also wasted a whole day looking into a filesystem problem which didn't exist, instead of a network device driver issue due to some idiot not being able to read me the last line in a log file, and instead reading the line 5 entries from the end.
I pity the poor sods working in that department now, if they have anyone left!
OOP (well C++) is not efficient when it comes to memory utilisation - this due to many factors, including the automatic inlining of a lot of code. But how many developers actually care about program size?
I've got a Solaris machine here which is constantly down due to many huge binaries wanting to run simultaneously. Each process consumes 8-19 MB of RAM, and it is possible that there could be 100 or more running at once. Not one of the processes is that complex in design. Neither the machine nor the code are under my control in any form, but I've still got to interact with the thing. Grr!!
I tried to use UMSDOS with the 2.2 kernel. Big problems! At the time I had a fairly small HD, and still needed to be able to run Windows. I believe it should be left to rest in peace.
During the 2.1 kernel development cycle, UMSDOS wouldnt even compile for over a year, due to the introduction of dentries. The original author dropped out, and eventually someone else took over the code. The code he had to work on was a mess, and error messages reported undocumented abbreviations in French, which didn't help. It to ok a while before anything usable came about, even longer for support for a root filesystem.
For a while I was running 2.0 and 2.2 side by side on the same filesystem. I had problems with files being present under 2.0 but missing under 2.2, the most important one being/etc/passwd. It was odd trying to log into 2.2, getting message indicating that/etc/password wasn't there, then rebooting 2.0 and finding nothing wrong.
Things may be stabler in more recent 2.2 releases. UMSDOS now fails to compile the last time I tried it (2.4.0-test6-pre-somthing).
Its a lot worse with commercial software. I've had a few things over the years that I've had to simply stop using because no-one is maintaining the code any more, and the source code itself has not been released.
What was more annoying is that the reason for the program no longer working was trivial - usually an API change that can be fixed by 5 minutes work with the source and a recompile.
The worst case was when a network utility vendor who was good at updating all their code, (some had been in constant use for 7-8 years), sold everything to another vendor. This second vendor effectivly killed everything off, and when the new version of the host OS appeared a few months later not one of the tools would work on the then current version. Pity, as there were no real replacements for the majority of them.
One system I worked with would keep the root password secret, and only the companies own people (not even ourselves, and we were this coutry's largest dealer). Given that the manufacturer's HQ was south of London and some of our customers were in Scotland, getting someone on site to fix things took some time. They could do some work over a modem, but root was often required to resolve boot-up problems. Problems would occur if we were doing maintenance over a weekend and root was required, and the manufacturer of course only worked 8am to 6pm, Monday to Friday. Not nice!
Keeping the root password for themselves was a significant revenue stream. Luckily I discovered a hole in a software install routine which would give anyone root provided they had a floppy containing a particular shell script. Eventually they gave root to all, but it was many years too late.
I recall seeing on UK television a few years ago a gentleman who could identify the work (and sometimes the actual recording) just by looking a the grooves on the vinyl LP. The presenter handed him a stack of LPs with the label and matrix numbers covered with a sticker, and this man correctly identified every one.
I am learning things every day. It just I have to depend upon so many clueless people to get things done.
The latest problem is with a Solaris box with a lot of custom written daemons running on it. The machine is swapping away like mad, and new process can't be started. I've just looked at the code, and each daemon is statically linked against the same massive library, plus a few smaller ones as well. If they'd bothered to implement thisusing shared libraries, I could have got my work done this week.<p>
I'm sick of working in an industry where possesion of a nice suit is worth more than technical competance.
How long have you been working in the industry? Not long, I'd say!
Remember the old days, prior to NT, when file servers genrally had uptimes measured in months. When code wasn't bloated. When software did what it was supposed to do, without additional doo-dahs. When people adminstering networks actually knew what they were doing. When an email server could serve 200 users on a 386 with 16MB of RAM, and still work quicker than the current dual-processor Exchange system I have to use, which only serves a quarter of the users. And when it actually required real in-depth knowledge to gain a certification, an not just the money.
Microsoft have done a lot of damage with their regressive software. I am appalled by some of the systems currently in use, compare to what I cut my teeth on 10 years ago, when things were generally more reliable and usually quicker.
My career was in network-operating system support. That is now over, due to everyone switching to MS for the network, and my skills not being needed.
I've now had to take a pay cut and in the past 2 years havn't found anyone that really appreciates my skills. My life has suffered, and it is all Microsoft's fault.
I've subscribed to all of their lists. No traffic as of yet.
Their next meeting is just over a week away. No special talks, just a general chat and drinking session. Only problem is getting home afterwards - I don't want to miss the last bus home.
Slashdot Mirror
There would be a legal mine-field getting hold of this infomation for free. The money put into these surveys needs to be re-couped somehow.
The main reason for not using the net too much at home is that dialup access is too sodding slow, even with a 56K modem.
When are Tory B Liar and his cronies and Oftel to pull their fingers out and force BT to open up the local loop, particularly for those of us who live in the smaller towns without cable.
I would move to Hull, where BT don't run things, but the place is an utter sh*t-hole.
You can't be the genuine E J Thribb - there's no reference to Keith's mum!
When a former customer decommissioned their network, he purchased around 20 multi-port serial cards off them, as we had sold a number of these in the past.
What he didn't realise was that this batch of cards were 3 revisions out of date, and the current model was faster, offered more operational modes, was easier to configure, and came with better cables.
When I left the place 3 years later, all but one was still sat on the shelf. The other I took on site with me, and was sat, still wrapped up, in my over-night bag, unused since acquired.
I also know of one major company who not only had this fault with *every* desktop, but were resolving every Netware name lookup via DNS prior to NDS. It took over 5 minutes to boot up Windows and log on to their network.
It was aimed at teaching BASIC in schools in North Wales, where there is a large anti-English movement.
If management actually understood what they were supposed to be managing, no-one would be running NT.
Ahem! 10 years ago Novell's marketing was way ahead of Banyan, their major competitor, who had *zero* marketing, yet a powerful (at the time) product, and sold mainly on word-of-mouth.
I worked for a Banyan reseller at the time, and this news scared ourselves and some of our customers.
Unfortunatly no-one in town seems to sell blank floppies any more! Even the local supermarket sells CD-Rs, but I don't have a CD-R drive or a fast network connection.
Within a few days of downloading I had a working system which was able to re-compile the kernel and most software. Occasionally I'd find something that wouldn't build, usually due to the build process requiring something obscure I hadn't yet installed. I learnt a lot - pity these skills havn't come in handy workwise.
The system ran for 9 months before the disk expired. I'm now running an old slackware with almost everything upgraded. Next time, though, I'll plump for Debian.
I spent some time working at a site like that. Every change (no matter how slight or trivial) to a production or even pre-production system had to be booked in advance, and signed off by 5 different people. At least one would refuse a change, usually because they didn't understand what the change was. (The worst case was when a Unix system needed a kernel parameter change, and the Suit seemed to believe this was something to do with Kermit). As a result of this I spent two weeks doing absolutely nothing other than sitting in meetings. Some changes could take years to implement.
They would also take a long time when it came to decomissioning hardware. Some Netware servers were no longer being used, as no client PCs were configured to connect to them. Yet they left them running for 3 months before powering the things down.
I wouldn't have minded, but the rest of the department was chaos. The NT domain password had been 'password' for 18 months, none of the workstations being rolled out were set up correctly (two major performance problems), documentation on installing new servers was just plain wrong, and other utter horrors. It was amazing anything worked at all.
Maybe they should have shut down the sysadmin instead.
My home ISP changed ownership last week, and I havn't looked at the new T&Cs in detail to see if this affects this one.
The lunatics have definitly taken over the asylum.
I've had a few cases where the software either had a serious bug, or needed modifying to adapt to some other change (such as a revised API). Getting the fix was impossible, yet the product was still being sold.
Any ideas on how to workaround this, other than hand-hacking the binary?
In the early days the calls were usually quite complex, usually concerning connectivity between disparate machines or getting some 3rd party tool to work in some way not envisaged by the manufacturers.
In later years we just became a helpline for any fool who would call us. I once spent 3 hours trying to determine why a mail system had lost a vast amount of mail, only to discover that the fool that called me had deleted the directory and wanted to find an excuse to cover his back. I also wasted a whole day looking into a filesystem problem which didn't exist, instead of a network device driver issue due to some idiot not being able to read me the last line in a log file, and instead reading the line 5 entries from the end.
I pity the poor sods working in that department now, if they have anyone left!
I've got a Solaris machine here which is constantly down due to many huge binaries wanting to run simultaneously. Each process consumes 8-19 MB of RAM, and it is possible that there could be 100 or more running at once. Not one of the processes is that complex in design. Neither the machine nor the code are under my control in any form, but I've still got to interact with the thing. Grr!!
During the 2.1 kernel development cycle, UMSDOS wouldnt even compile for over a year, due to the introduction of dentries. The original author dropped out, and eventually someone else took over the code. The code he had to work on was a mess, and error messages reported undocumented abbreviations in French, which didn't help. It to ok a while before anything usable came about, even longer for support for a root filesystem.
For a while I was running 2.0 and 2.2 side by side on the same filesystem. I had problems with files being present under 2.0 but missing under 2.2, the most important one being /etc/passwd. It was odd trying to log into 2.2, getting message indicating that /etc/password wasn't there, then rebooting 2.0 and finding nothing wrong.
Things may be stabler in more recent 2.2 releases. UMSDOS now fails to compile the last time I tried it (2.4.0-test6-pre-somthing).
What was more annoying is that the reason for the program no longer working was trivial - usually an API change that can be fixed by 5 minutes work with the source and a recompile.
The worst case was when a network utility vendor who was good at updating all their code, (some had been in constant use for 7-8 years), sold everything to another vendor. This second vendor effectivly killed everything off, and when the new version of the host OS appeared a few months later not one of the tools would work on the then current version. Pity, as there were no real replacements for the majority of them.
Keeping the root password for themselves was a significant revenue stream. Luckily I discovered a hole in a software install routine which would give anyone root provided they had a floppy containing a particular shell script. Eventually they gave root to all, but it was many years too late.
I recall seeing on UK television a few years ago a gentleman who could identify the work (and sometimes the actual recording) just by looking a the grooves on the vinyl LP. The presenter handed him a stack of LPs with the label and matrix numbers covered with a sticker, and this man correctly identified every one.
The latest problem is with a Solaris box with a lot of custom written daemons running on it. The machine is swapping away like mad, and new process can't be started. I've just looked at the code, and each daemon is statically linked against the same massive library, plus a few smaller ones as well. If they'd bothered to implement thisusing shared libraries, I could have got my work done this week.<p>
I'm sick of working in an industry where possesion of a nice suit is worth more than technical competance.
Remember the old days, prior to NT, when file servers genrally had uptimes measured in months. When code wasn't bloated. When software did what it was supposed to do, without additional doo-dahs. When people adminstering networks actually knew what they were doing. When an email server could serve 200 users on a 386 with 16MB of RAM, and still work quicker than the current dual-processor Exchange system I have to use, which only serves a quarter of the users. And when it actually required real in-depth knowledge to gain a certification, an not just the money.
Microsoft have done a lot of damage with their regressive software. I am appalled by some of the systems currently in use, compare to what I cut my teeth on 10 years ago, when things were generally more reliable and usually quicker.
My career was in network-operating system support. That is now over, due to everyone switching to MS for the network, and my skills not being needed.
I've now had to take a pay cut and in the past 2 years havn't found anyone that really appreciates my skills. My life has suffered, and it is all Microsoft's fault.
Their next meeting is just over a week away. No special talks, just a general chat and drinking session. Only problem is getting home afterwards - I don't want to miss the last bus home.