Linux lover consumed a quarter of the network Ah, gentle reader, we find ourselves once again at that juncture of the week we call Who, Me? in which your fellow Regizens' tales of technical not-quite-competence brighten an otherwise dull Monday. This week our story comes from "Charlie" who, some quarter of a century ago, was working on his PhD at "a large tertiary …
[Bah! Too slow to edit!]
Nice coincidence on the title MyffyW! I watched all of the Charley Says a few days ago - proper memory lane! Charley says...all 6 episodes.
This post has been deleted by its author
"Hamm is the code name for a former Stable Debian distribution. It was released on July 24th 1998 as Debian GNU/Linux 2.0. It was superseded by Debian/Slink on 09 Mar 1999."
(https://wiki.debian.org/DebianHamm)
I had mine through snail mail from some nice volunteer, IIRC linking from the Debian webpage. No chance to download it via a 33.6 modem.
> stationary on the M20
Aka Operation Stack
Which really gets one right in the old pedantry nerve: that is a FIFO not a LIFO! They aren't stacking their operations, they are queueing!
Although calling it Operation Queue would just get it confused with SOP on the M25.
Canonically, that's "Never underestimate the bandwidth capability of a station wagon full of mag tape."
The quote is often attributed to Tanenbaum in 1996, but it was a common expression when I was at DEC long before that ... and I remember a similar comment from a student at Stanford in the early '80s when a professor expressed surprise at one of the vaxen already running the latest BSD build, released just a few hours before. Conversation went "How on earth did you get that code across the network that fast?" answer was "My motorcycle's latency might be sub-par, but it still has a much higher bandwidth capability than your network!".
Way before 1996, people at CERN referred to a network called "Jumbo Jet on line" (mag tapes by air freight were very competitive with the early Internet). Andy Tanenbaum was often at CERN so he could have learned about it there.
On site, they used "bicycle on line" (mag tapes could cross the site on the back of a bike quicker than the bits could cross the site network).
Many years ago I grabbed a server from the office to take for EMC testing in a small wooden shed in the middle of a field...
The tests were booked for the next day, so I took the server home overnight, and then to the EMC testing facility in the morning. I spent some of the journey home doing some basic calculations:
24 disks, 1TB per disk (biggest available at the time, must have been 2007/2008), 70 minute journey time.... that's a little shy of 50 gbps
I mean the latency sucked (two days to get data back to the office), but the bandwidth was quite substabital.
The other amusing calculation was how much more valuable the server was than the vehicle it was riding in...
How many of us have carried some new peice of equipment across the campus, only to be told after mounting it in its new rack: "You know, that box you just carried downstairs, across campus, and up two flights of stairs under your arm is worth more than we pay you in a year."
If you were like me, you'd immediately send in a requisition for a pushcart...
When I did more of a system role, we had to do DR practice. I remember walking to the truck with all the tapes thinking that I had the entire output of a five hundred person research site for twenty years in nothing more that a tatty cardboard box[0]
[0] This backup wasn't the latest so if we did screw it up we'd still be covered
"The other amusing calculation was how much more valuable the server was than the vehicle it was riding in..."
Yeah, installed a DNS server that cost far more than a luxury sports car.
Irritatingly, some idiot second lieutenant (but, I repeat myself) decided its partner was excess inventory and sent it to the property auction to be sold for pennies on the thousand dollar. He's probably a twenty star General by now, with that level of performance.
At the college I was attending, the police came to the computer center and said they found someone with several 9-track tapes and an incoherent story about them -- something about research or something. So we mounted the tapes and didn't find anything suspicious. Then we had a hard time convincing the police that it was perfectly normal for a computer scientist to have a load of tapes with a very confused story about them.
We had a similar situation - towards the end of the last century, our company successfully migrated off one of the ancient applications onto a new (for then) platform.
At the celebration party one of the key people was presented with a 9-track tape reel from the decommissioned system as a souvenir.
However this person overdid the celebration a bit and was found later that night by the Met - as the tape had 'property of $big_corporation ' printed on it they thought they had stumbled on an industrial espionage attempt.
It took a late night phone call to the head of IT to get it all sorted out.
While Rule One continues to rule (the bandwidth of a pile of USB sticks in hand luggage still beats anything with wires) , it can fail catastrophically. Very many years ago, before the Internet was a gleam in anyone's eyes, I shared an office with a PhD student. Said student had recorded data in The Arctic on film (this was before digital cameras!) and then shipped it back to the UK. Unfortunately, the film went missing in transit and was never recovered. A whole season's work went up in smoke; the student was EXTREMELY upset, but fortunately managed to recover from it (she is now a respectable member of Norway's academic elite).
We very nearly suffered something similar because of the inflexibility of airport security. Again, we had a bunch of data recorded on 35mm film. At that time, you could ask for film not to be passed through airport X-ray devices; AFAIR it was guaranteed by international agreement. Also, the fieldwork had been at least partially financed by the Norwegian government, We arrived at Oslo airport, and the security flatly refused to allow the film to bypass their X-Ray machine. They were very proud that it was a model that would not fog film, and they insisted on everything going through it, despite my boss arguing about international agreements and about the cost to the Norwegian government if the film was damaged. Fortunately, the film did survive, but if it had been a more sensitive emulsion, it might not have!
Back in the day (early-mid 1980s), I was doing a PhD in astronomy in a venerable university in the Fenlands. There were two systems: the University computer, connected to the nationwide academic network JANET, and a dedicated inter-University astronomy network called STARLINK.
To get data from one to the other, there were two methods available:
[1] From the University computer, hop on the JANET link to a rival university (on the Thames wearing the wrong shade of blue), hop across their link to STARLINK, and then come back to the Fenlands over the STARLINK network. Or, going the other way, reverse all the steps.
[2] At the University computer site in the centre of town, put your data onto magnetic tape, load it onto a motorbike and have it delivered to the satellite [appropriately...] site where we were working and where the STARLINK terminals were.
The two methods transferred data at about the same bit rate.
If it's the place I'm thinking of, having truly sucky bandwidth has resulted in some interesting System Design work, centering on both availability of power and bandwidth.
I wish someone would publish the detailed info as lesson to the rest of us. I wish I could, but it's not my place to do so, and I'm a little too far 'outside' for my version to be accurate.:-)
It's not that many years ago that, as an experiment, they tried downloading a film (movie for non-Brits) from a server in London to a computer in Nottingham (130 miles or so by road), at the same time they sent a USB drive strapped to a pigeon's leg. The USB drive arrived before the download completed.
We had an incident 10-12 years ago with TomTom updates over our 2 meg leased line. The downloading PC sent the request to the Akamai server hosting the updates which duly sent the update, then when the server hadn't received an acknowledgement within a relatively short time frame it sent it again, and again, and again... I believe at one point there were 7 copies of the update being downloaded simultaneously, and not a lot else being done. Shutting down the PC concerned and terminating the connections cured the immediate problem, as did telling the user to not try that again. I then gradually blocked every Akamai address on the firewall to prevent a recurrence.
TomTom updates were horrific.
I bought one for the "lifetime updates" and ability to buy maps for other areas for travel.
The purchase and update application was possibly the worst piece of **** I've ever had the misfortune to encounter.
In the end, the only way I could actually get the maps was to intercept the HTTP request and download the ISO myself.
Then chargeback the map purchase because it didn't bloody work...
IIRC, it was a dozen (or more) 3.5" diskette images. At least that was Slackware, which was what I used. And, yes, I FTP'd them from Sunsite or TSX-11 or DECWRL. And it took forever to write them to the diskettes.
It was a great day when Walnut Creek CD offered distributions on CD for like $10.
The neophyte user might not have understood that he only needed the one binary installation CD, and had no immediate need for the two source CDs, no need for the binary CDs of the other CPU architectures available, and no need for the several foreign language CDs. I don't think it was quite a full dozen 25 years ago, but it would have been close.
Yep, I think I paid 15 quid at PC World in 1997/98 for a box containing a Mandrake distro. I think it was 4 CDs. Worked out that it would have cost me double that (and several days) to FTP them over my crappy Psion 33.6 modem - that only used to like to link at about 20kbps.
I'm pretty sure it was debian I installed, back in 1995 or thereabouts. Download one floppy, boot of it, and it grabs everything else it needs via a network connection. This was being provided at that time by a windows machine sharing a standard dial-up connection. Whilst it took a while, I don't recall it taking so long that I ran out of free phone call time. (I was lucky enough to find a local (UK) ISP with access numbers on the local cable network; that got me free calls to them, off-peak, once I signed up for a line myself.)
I remember when i was still in university that a professor once shared the tale of when he DoS'ed the debian servers by trying to set up a mirror at the university lab, with the only caveat that being an academic institution, the Uni had 2 10gig lines to the literal national backbone... Let's just say that he's not welcome anymore on the other debian mirrors....
Those things were marvelous. You could pop one in your laptop and, if you ordered your laptop with a spare battery in leiu of a cdrom drive, you could work from 8:30am until 4:30pm in the break area outside....Ah, the good old days. Today, with the hotspot on my phone, I could work from a beach in Hawaii if I wanted to.
I remember when irDA was similarly used as a terrific way to share stuff between Thinkpads and Nokia 8310s - from memory it was 50-100Kbps between devices which was good enough. I even remember "free" (but slow as hell) data over GPRS because the mobile companies hadn't really figured out how to monetise it or prevent what was effectively pairing.
Years ago, I worked for a Uni doing staff support. Can't remember the specs, but we had a decent internet link that was also available in one of the University owned student accomodation sites (basically a small housing estate on one of the campuses. Obviously accomodation in this estate was *very* sought after, because they got a much faster connection than they would outside the Uni.
I had friends on the University Networks team, and was talking to one of them one day. He pointed out that during the academic year, nearly a quarter of University bandwidth (and this was a University that had 3 large campuses housing over 18,000 students and a couple of thousand staff) was used by two of the larger buildings on this estate. Funnily enough when, after getting cease and desist orders from at least one record company, they introduced measures to reduce file sharing (Napster, Limewire etc). I don't think they ever entirely stopped it, but bandwidth usage went down massively.
I think I was in this halls, 100Mbit in 2000, took along time to get the same at home.
There was a not insignificant percentage of Napster's catalogue available and someone got a cease and desist letter from Paramount.
It was one of the smaller halls too, only about 100 people and came in 3rd after the entire campus and the largest hall for internet usage.
A simpler time.
In 2002, our 5-person townhouse got a warning letter from our ISP about the amount of bandwidth we were using. Me and the other geek checked our setups - no, nothing crazy going on with ours. So I called the ISP and asked just how much was being used (the letter didn't say). A couple gigs *UPLOAD* per day, apparently. Talked to the two guys in the basement, and helped them make Napster stop sharing. Suddenly bandwidth went back to normal.
Friend of mine was at nottingham trent when cable modems (at 128kbps) were new. He NFS mounted sunsite from the uk source (IIRC, imperial).
It worked well till a cron script kicked off that checked for some files. Which 2 days later was still trying to work it's way though the entire sunsite folder structure looking for what ever files he had told it too!
Chloe
My old university used to gauge people's internet usage by the amount of local storage they were using.
They didn't have the kit to monitor the BLINDINGLY fast connection of the day (I think 100Mbps), and so they weren't able to monitor usage directly, so they correlated it to those students downloading tons of stuff and keeping it on their account.
Every few weeks, they'd send out an email of shame to everyone naming the people using the most local storage, and next week those people would have cleaned up and taken the slap on the wrist.
Except... if you looked, the emails were always generated from data produced at a certain predictable date and time. Obviously some scheduled task or cron job somewhere.
I managed to go three years, in which I knew I was literally trouncing everyone on the name-and-shame list, by the simple precept of removing all the downloads the day before the script was scheduled to run. That sometimes meant an evening with a bunch of floppy disks (and later ZIP disks), and an intense familiarity with the PKZIP command line options for spanning disks, but I would pack all my stuff up, go home and "download" it to my machine, clear out my university storage, and then repeat over the next week.
They never seemed to cotton on, and I was literally orders of magnitude more downloading and storage than those on the list, and I never made it onto the list personally. Not even once.
But when your only home connection was 56K dial-up, then "sneakernet" to a 100Mbps location and the cost of a box of disks was actually far superior, even if it required far more patience (especially if I got home and the spanned set had a failed disk!).
Also, because of the loss of the storage on a regular basis, I would later make a bunch of CD-R copies (at 1x speed!) so I didn't have to download things again. I still have them. They all still work. I would burn them in pairs so I had two copies of everything.
Including one that, the day I burned it, failed verification when it was read back. It's copy burned absolutely fine, no problems. When I looked, a single byte was incorrect in a single file. I attached a post-it to the CDR with the hex address and what the byte should read.
To this day, if you load up that CD-R, hex-edit that one file, change that one byte, the archive passes all tests and opens and give you the files inside perfectly intact.
Back in the early 1990s I used to work graveyard shift, 1am to 8am, overnight it was just watching batches, backups and cleaning PCs of junk, updating AV, etc. However we had a company internet connection that no one used overnight, it was around 512k speed line when everyone had 9600 dialup at home if they were lucky. I had access to a SPARC desktop that didn't have any monitoring software! So I'd trawl university FTP sites for, ahem less them legal software then dump it onto an IoMega ZIP drive ( remember "click of death"? ).
One day someone asked me what i was doing and I told them the line was unused overnight, this lead to me being Mr Collector, I'd get emails during the day with orders from various people looking for software and games, then spent my free time overnight fulfilling them for my colleagues who'd collect the floppies and CDs ( we had a £5k SCSI CD writer in the office too! ), all the time getting paid for it! I'd be downloading 250MB a night, 5 nights a week. I had to buy more ZIP disks and blank CDs which cost about £20 per blank at the time.
As I said, off topic, but I do like the thumbnail from the access road to Oamaru Penguin colony
https://www.google.co.uk/maps/@-45.1087654,170.9728437,3a,75y,67.66h,83.86t/data=!3m6!1e1!3m4!1skA9loeUyJKVSbzW32B-AJQ!2e0!7i13312!8i6656?entry=ttu
I'd recommend a visit if you ever in the area, especially when they come ashore in the evening.
I was in Japan in the 1990's when hotel connectivity was to plug the phone line into the back of your computer. This didnt work because of a dialler problem ( which allowed me to connect to the corporate network) but there was a fix for it. My problem was how do I download the fix to be able to download the fix. This was late Friday night and I was working a a customer over the weekend.
I took the subway (1 hour) to our corporate building, but I could not get into the floor because my badge was not on their system, and there was no one in! I found there was a corporate WiFii signal if I held my laptop up. I downloaded the fix, went down the ground floor, and borrowed a telephone line from a security guard (who spoke no English) - and it worked!
These days with hotel Wifi - it is so easy.!
I still have an old laptop with a built-in modem (but actually a winmodem, ick), and it came with quite the variety of novelty connectors for different phone systems, I suppose they are still somewhere in box with old serial cables &etc.
the Debian installation required "something like a dozen CD-ROMs."
Even today it doesn't require that much!
Unfortunately, the internet connection in Charlie's office was slow and unreliable at the best of times,
I hope Charlie learned about wget, curl, and other download managers since then. I was using Go!Zilla and GetRight in the mid-90s to download Linux ISOs over dial-up on Windows.
I definitely remember, once upon a time, that Debian did take up a good handful of CDs. Admittedly, that probably included "everything in the repos, the full kitchen sink", but it might well have been the case that although most of the core stuff was on CD 1, you would probably have needed at least one of the others for X and your favourite desktop environment…? I think it was only rather later that it occurred to distros that a cut down single-CD (and/or 'live') release was a good idea, with enough to get a desktop system up and running, but with the expectation that (by then) you could and would download the bloatier or less commonly used packages over broadband after the initial install.
The whole point of the CD collections was essentially sneakernet, back in the days when dialup (or even early broadband, if you were very lucky) was too slow and/or too expensive.
(Arbitrarily chosen Linux Emporium snapshot from the Internet Archive, which suggests at least 7 CDs, more if you want the sources!)
> even with today's bloatware the download (that took less time that to click on reply) is 642Mb - basically an overstuffed CDROM
Not even "overstuffed". I burned a LOT of uncompressed raw live audio. A Sony-standard 74 music-minute CD is 650MB user-bits (not counting ECC and overhead). 642Mb-- Clearly someone had an eye on the scale and chickened-out in the last 10MB, to allow for wonky drives, screwball filesystems, and such. (As deposition etc improved we were putting 80 and more minutes on a disc, At Own Risk.)
I remember a unix-alike on 23 diskettes (33MB). I remember base CD and extra CD. I was rather stunned the first time an ISO-burner demanded I find a DVD, and later a Double Layer CD.
We're talking about compressed data on a CD. Technologically impressive that you can boot from what is loosely a Zip file.
I'm going to allege that Knoppix on home-made CD went up to around 700 MB because also technologically you could put on more data than 74 minutes / 650 MB. I suppose that the last 50 MB was stuff that you could live without.
ahhh, the good old days of using wget to resume interrupted downloads...
I can remember downloading StarOffice when it was made available for free, on a 33k modem. Took a couple of days using Telkom's R7 Callmore time (after-hours you'll only get billed or the first R7 of the telephone call).
And Roblist. The Roblist.
Those were the days.
If somebody ever manage to get a multi-user BBS up and running (which will allow more than two users simultaneously) I'll gladly have a shufty at it! Miss those days of text-only consoles.
"If somebody ever manage to get a multi-user BBS up and running (which will allow more than two users simultaneously) I'll gladly have a shufty at it! Miss those days of text-only consoles."
Sounds like you want to take a look at SDF or tilde.club (or various others…)
"We people on the fringes didn't have the luxury of direct tcp connections"
There was usually a BBS with an FTP gateway somewhere fairly local. Failing that, UUCP over dial-up to a local Uni was a thing.
I helped people all over the UK (and parts of Europe) get connected in the early days ... it was there, if you knew how, and who to talk to.
I was the person that created the Debian ISO images for a while, which was done at the time on a machine that was in an ISP near Bracknell, and which had a 10Mbit network interface.
Previous releases had demonstrated that that _really_ wasn't enough, so I asked the people I knew at Imperial's DoC (doc.ic.ac.uk) if they could mirror the image on Sunsite for me.
Just after the Debian release, the folks at JANET in London noticed that their backbone was completely flooded, and the cause was coming from the I.C link, so they pulled the plug, and I.C. was off the air for (IIRC a couple of days) while they worked out how to limit the link, which was something like twice the bandwidth of the 100Mbit backbone.
Oops!
Didn't Walnut Creek agree to host Debian in the early days, like they did Slackware and FreeBSD (and the simtel collection, Project Gutenberg, X11R5 (and later R6), perl, the complete monstrosity known as ADA ... later, that new-fangled Apache & accessories for people fiddling about with the WorldWideWait thingie, and ... ).
Have a beer for services rendered.
"NFS is probably the only protocol in the unix world, that is worst that its Microsoft counter part.
It's always been shite, performance and reliability wise."
--Flame Bait--
If your trying to say NFS is worse than SMB/CIFS I beg to differ. NFSv3 performance is very good albeit single threaded. NFSv3 also works reasonably well over higher latency connections. SMB/CIFS falls over. That being said, Microsoft's NFS implementation is abysmal. If you are running a *nix box run NFS, If you are running Windows run CIFS, though both can be abysmal under windows. I've used NFS extensively since
I note NetApp still uses NFS as the core protocol for VMware storage connectivity, and it routinely out-performed iSCSI in years past. I know more recently they support multi-threaded NFSv4, though I haven't followed the benchmarks recently.
Some years ago I was looking after some Research Scientists Linux/Unix systems
Just by chance I noticed that someone was pulling a lot of data across the "private" line from the US to the UK. A quick check showed it had been running for >12 hours, but probably only had an hour to go. It would have been more efficient to compress it, send it, uncompress it so I made a note to have a chat to the user (as we actually had a utility that woudl do this for them).
About 10 mins later I had a 'phone call from someone in the network support team.
"It seems that someone is pulling a lot of data across the Atlantic - do you know anything about this?"
I apologized, said it could have been done more efficiently and I was going to chat to the user in question.
The reply to that was somewhat unexpected.
"No, we're not complaining - the network is there to be used."
After I got up off the floor (mentally) I discovered that they were interested in why it was going at twice the speed as any file transfer they could do.
(The answer was not to use FTP on a Solaris system. FTP on Irix or Linux was noticeably faster - probably to do with window sizes).
I was on University IT helpdesk as a part time thing while a student. This was just as two things happened - university Halls of Residence got ethernet sockets (not mine ... booo) and people were playing with Linux. I'd been around that loop, but without network it was mostly about compiling kernels and getting X to load.
However, some student had got a disk, and decided to install everything, and turn on everything. Including a DHCP server.... Blam - nobody could get on the network. Fun day that...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
