Re: El Reg Redesign - leave your comment here.
As with the vast majority of opinion here - please back this out ASAP.
Who signed off this grande heap de merde during change control? Back them out too!
27 posts • joined 30 Dec 2010
As with the vast majority of opinion here - please back this out ASAP.
Who signed off this grande heap de merde during change control? Back them out too!
In an home context, I'm not infrequently printing photos and other documents from my Android Note 2 to my Epsom Stylus Photo. Works fine for what I want.
Agreed, a business context is very different and I'm generally only after colour to print documents where there are complex colour coded project plans and architectural artifacts. They are not so much fun in grey scale.
I think that you have answered your own question. Of course not. Where else in your IT system will you tolerate 'Single Points of Failure'? You may consider RAIT-1 or -5 (or some variant) acceptable, but in general I prefer eggs in multiple baskets.
Also you need to consider the effective life of media, and the ability of (possibly museum quality) kit to read it in 20 years.
In general, look back to the good practice instituted in the golden years of the mainframe and plan for (and estimate costs for) regular technology refresh and transfer of content from one generation to another of storage technology. Go read the LTO road map and remind yourself which LTO generation formats are still readable by an LTO drive you could buy today (ebay is cheating!) - and then check your media store (and salt mine)!
(PS: where's the icon that means: "contains the flaming obvious - requires primary school level education or lower?)
This may sound quite daft - but two words : "Salt Mines".
Way, way back in my personal history I worked for the owner of mega-large, mega-deep salt mines in Cheshire (three lettered UK company starting with "I" - but not either of the IT ones!). In the space where the salt used to be one found .... archived documents.
The lesson is that the documents were sent away to a long-term storage place that was safer than houses - but that wasn't enough. You had to know what was there, how to get it back and whether you'd be able to make any sense of it.
Apply the same lessons to no longer actively required IT data and we will get somewhere with the question of archive. Take particular notice of my statement "whether you'd be able to make any use of it". Consider whether a document created in an early word processor (what shall we say, WordPerfect, Manuscript?) being pulled from an "archived" file set. The bits in the data object might well be in perfect order - but do you have a copy of anything that can make the content readable?
I said not to get me started ... the challenge of Archive isn't infrastructure processes (and BTW it certainly isn't storing annual full dumps on Tape - fancy reading my TOPS-20 written DUMPER format 9-track 1600bpi PE tapes from the early 1980s anyone?) - it has to be a mind set approach - how does my business preserve its business records should they be needed in the future? Having worked too in the Pharmaceutical industry I do understand the necessity of keeping near indefinite records.
There's another approach needed where we're talking Big, BIG Data and places like CERN understand that full well.
I have spent much of the past ten years reviewing the validity of technical solutions being proposed by a major IT outsourcing services corporation.
If I received a solution proposal describing the 'backup' solution, I immediately red-lined it and asked what their Recovery solution was. I have several classic examples of this but company confidentiality forbids me publishing them on an open forum such as this - but one of the best is proposing 'incremental for ever' (< 5% periodic churn) backup over a WAN circuit with bandwidth sized for this (typically daily) activity - and then being surprised when that they should be asked how long recovery of a total storage entity (be that file system or database) would take over the same bandwidth constrained WAN circuit. I think the lesson has now been learned ... but storage volumes continue to increase ....
Nobody wants to perform backup ... although virtually every business wants assurance that its data is recoverable.
(and please, don't get me started on 'Archive' ....)
>>> "Today, the e-Borders system is capable of checking the identities of 80 per cent of arriving visitors, we're told. It was designed to centrally store details of every journey into and out of the UK by 2014, and check passports against various watch lists. A new computer is being developed to supersede it." <<<
Gosh ... a whole "new computer" to supersede a $750M (failed?) system? Where can I get one of these !
El Reg - get your sh*t together and employ some decent sub-editors/proof-readers! Once upon a time decent reporting and writing standards were one of the reasons why this site was worth reading. I'm increasingly coming to the conclusion that's no longer the case.
Disgruntled (not) of Tumbridge Wells etc ....
>> "you do know he was bought and paid for by the road builders yes"
In as much as Ernest Marples, the Minister of Transport who appointed Dr Beeching, was a prominent member of the British Roads Federation, then I believe that it is an argument that is widely held.
Beeching himself, had no background in either transport industry being at the time the Technical Director of ICI.
Hopefully useful corrections.
>> Are the train companies not private companies?
In some cases, yes and in others no. Many of them (sometimes in consortium with private companies) are actually foreign state companies - DB (German Rail) owns the largest UK freight company (DB Schenker) and several Train Operating Companies (TOCs) both franchise and open access. The only UK state operated 'franchise' today is East Coast Trains (Directly Operated Railways - http://www.directlyoperatedrailways.co.uk/html/about-DOR.php) and by some measure Eurostar / London & Continental Railways (recently transferred the stock ownership from Department for Transport to the Treasury - https://www.gov.uk/government/speeches/london-and-continental-railways).
>> Are the track companies not private companies?
In a word - No. And from the 1st September 2014 even less so as Network Rail becomes effectively nationalised.
You're obviously happy for all future motorways and other roads to be built by private enterprise?
If so, why in hell does the "country" have to pay to build a <road> ? Let the private companies build their own <roads>. What's that? Not economically viable? Well don't build it then.
Or have I misunderstood some thing about society and the national good?
Without wanting to go through all the debate elsewhere, one of the key benefits of building HS2 is that capacity on existing rail routes will be released when the long-distance (ie non-stopping) passenger services are re-routed onto the high speed backbone (aka HS2). The key beneficiary of this must be to provide additional train paths for freight traffic - it should not be necessary to debate the benefit of moving freight from road to rail other than for local distribution - although the passenger services that will benefit will include semi-fast inter-regional and 'commuter' traffic.
One of the most beneficial attributes of moving fast, long distance passenger trains to a dedicated backbone is that services on both HS and classic routes can then be optimised for grouping by speed. The throughput of any discrete railway line is to a large extent constrained by the necessity to separate trains by an adequate safety margin. If a faster train is behind a slower one, then it is obvious that if the faster train must have sufficient 'space' into which it runs before catching up with the slower one (where of course the slower one must be regulated - switched to a holding or passing loop - while the faster one passes it by). When trains run at the same speed then relatively fixed spacing works. It is this principle that will allow Thameslink / Crossrail / Underground to run in the order of 25 - 35 trains per hour (TPH) where mixed speed main lines sometimes struggle to provide 15 - 20 paths in the hour. That's a massive difference in total capacity.
It is also worth noting that extension of train lengths can be a mixed blessing and very expensive indeed - and in some cases virtually impossible, typically where station geography is not suitable. Look at the work involved in the Waterloo area to extend 8-car trains to 10- and in future 12 (if it were not for the ex-Eurostar area I believe that Waterloo would need to loose at least one platform to permit train length extension).
Cab signaling? it you mean ETCS - its on the way (eventually) but ECML and GWML are ahead of WCML!
Google might not but try http://realtimetrains.co.uk - does a pretty good job of taking National Rail feeds, assembling them into something meaningful and (IME) accurate predictions for arrivals - and it does normally pick up on cancellations, even part way through a journey.
Useful extra is that it also confirms platforms for large stations long before the departure board will (well, at Euston it works).
[mobile apps are available for iPhone and Android]
No connection to the company other than a satisfied user.
"As I recall it, that story was about a DEC VAX/VMS machine. Unlike modern stuff, they did not need patching every week."
Actually, I think that the world was somewhat different then and (if we are really taking VAX/VMS - not Open VMS) the number of systems connected to the Interwebs was miniscule - I'm not counting Arpanet, JANET or other early networks. I think that patching (tapes or later CDs) came out either monthly or quarterly and it was a right faff-on trying to apply them.
Of course, that was luxury compared to the previous generations of systems where the patches were delivered in paper in stapled books and had to be typed into running copies of system debugging tools - typically of the DDT family - or edited into source code and recomplied. Few if any had the benefit of test, development or pre-production systems so getting test slots on the production systems (often at unsocial hours) was the order of the day.
Doubtless others of a older generation will have their own stories of how it once was and how sysadmins today don't know they are born, but neither were we exposed to the same levels of malware and miscellaneous nasties seen today.
>> There were almost no books on programming, I worked out most of the syntax of DEC BASIC from the error messages.
I think that I still have a 1975 DECsystem-10 Basic manual in my garage ... can I send you a copy?
But more seriously, my early programming experience at school from 1973 was learning Algol-60 from an ICL Manual and using the formal Algol-60 Revised Report (in BNF) as bedtime reading. Weekly job turn round from the local technical college using mark-sense punch cards, eventually graduating to using the sixth-form 'Wednesday Sports afternoon' to visit the college to use their proper punch card machine and get a couple of jobs run each week.
Sad isn't it?
Are you sure that this wasn't just running VMS on the Charion emulator under Windows? That seems to be more-or-less the way forward that I am seeing in a number of situations where VMS applications have to be re-platformed to something reasonably modern.
No port involved - unless somebody from HP willing to break ranks and confirm speculation that there was a skunkworks project to port OpenVMS from IA64 to standard 64-bit Intel architecture ...
@Tristram Shandy (not PRIME 20!)
I was the Technical Support Manager for the DECSYSTEM-20s at Wilton from 1984 to 1990. You are referring to the PMS system running on HQ2. This application was an early attempt to move up a level from SCADA and other Plant Control layer systems to provide management information at a higher layer. PMS formed the foundation for a later application known initially as PMC and later as 'QUESTAR' which was implemented on VMS and widely used across the ICI group in the later 1980s and 1990s.
PMS took readings (over RS232 async terminal type ports) from some control systems but primarily from VTx00 terminals from plant operators. It was only ever implemented on the Wilton Nylon Inters and North Tees Aromatics plants.
ICI ran three DECSYSTEM-2060 systems at Wilton and a further one in the NETCC at Billingham - there were also a couple of DECSYSTEM-2020s which were more or less inactive by the time I arrived. Before ICI I worked for an East Midlands Polytechnic supporting their 2060 so I do not know where your suggestion that there was only one other in the UK came from. The population (at peak) was at least 30 and they were widespread in the Higher Education sector, including (IIRC) :
Polytechnic of South Wales
Robert Gordon's Institute of Technology, Aberdeen
Glasgow College of Technology
Bournemouth Institute of Technology (? name)
The Open University (3 sites)
and that is not taking into account the many other organisations that ran DECsystem-10s (including ICI!)
The architecture of the PDP-10 family (including all models of -10 and -20) was indeed 36-bit an d implemented a variable byte length of anywhere between 1 and 36 bits, depending on the byte descriptor.
Yes, ICI Engineering had various real-time systems involved in plant supervision and/or control environments running on PDP-11 hardware - some of which mutated into wider scope applications running on VAXen.
Ex-colleagues from ICI may be able to shed more light on whether these were running as real-time OS alternates, or under RT-11 or one of the RSX flavours. I recall several VMS applications but not whether any of the real time stuff was ever delivered on the real-time VAX OS 'VAXeln'.
And IIRC correctly these systems were available to the open market - I can remember many visits to the ICI subsidiary (whose name escapes me) in central Middlesbrough in the late 1980s.
"Also the OS lineage for DEC went TOPS - TSS - RT-11 - RSTS/E - RSX and VMS"
Well, I can agree that these were all DEC operating systems, but they never ran on the same hardware architectures.
TSS/RT11/RSTS/E and the IAS/RSX families (and various flavours of UNIX as noted by others) all ran on the 16-bit PDP-11 systems, VAX/VMS ran on the 32-bit VAX family in its first incarnation (later Alpha and subsequently IA64 as OpenVMS) .
The TOPS family was of course a very different world of 36-bit systems ... but I'm sure that I have mentioned that before in other posts (!)
It's been a while since I was involved in applications on any PDP-11 - although in my time I've supported various models running operating systems including RSX-11S/M/M+/uRSX/20F (that's a give away!), RSTS, RT-11, Unix etc. It comes as no surprise to me that SCADA systems will be using this architecture for many years to come, having had considerable exposure to industrial control systems in the period 1985-2000.
While original hardware configurations must be well advanced in years by now I do recall that rights to develop and manufacture ongoing products using the PDP-11 architecture were sold off by Digital Equipment even before they were acquired by Compaq - let alone HP.
Guess that it's a case of if it works - don't fix it.
BTW: Sad that a Register author could be so confused as to suggest that VMS was the successor to the PDP-11. Somebody needs to understand the difference between software and hardware methinks. Agree that VAX/VMS was (in part at least) the successor of the RSX family - although the RSX emulation/comparability was dropped somewhere in the mid-1980s and was certainly never carried forward into OpenVMS (VAX, Alpha or IA64), it was the VAX-11 (Virtual Address Extension) that was the follow on to the various PDP-11 hardware families. BUT - harking back to 'Soul of a New Machine' - there was an 'emulation bit' between PDP-11 and VAX. (Incidentally, who else remembers attending VMS training where that virtual address space of 4GB [32-bit] was considered so massive nobody would ever have to worry about addressing limits again?)
Actually no. It was the other way round. The Turbomotive (LMS 6202, BR 46202) was first rebuilt as a conventional locomotive and was then wrecked in the crash at Harrow and Wealdstone.in 1952.
It is widely understood that the loss of 46202 (named 'Princess Anne') led to the decision that one class 8P locomotive could be added to the Riddles designed BR standard programme. And so Duke of Gloucester (71000) was authorised. Many debates on how effective and efficient 71000 was in its BR form and post preservation a number of flaws in the original build have been addressed - or not depending on your bias / point of view.
Try looking here http://www.5at.co.uk/
There are several areas where 'Advanced' steam has been taken well beyond where British main-line steam ended in the 1960's (and most of North American steam locomotion several decades before that).
Having said that, I think that there are too many obstacles relating to infrastructure (water supply for one) and maintenance that would make a return to steam non-viable in the 21st Century as a front line method of mainline traction.
And the I.T. angle is ... ?
According to the Nikon support site, applies only to cameras and batteries sold after 29th February 2012. Should be OK with my D7000 and spare battery from August last year then!
(In fact strictly, picture 5 is of the PDP-11/40 FEP for the KL-10)
Picture 5 is certainly, as it proclaims, a KL-10 (A or B model) which is the CPU unit of, in this case, a DECsystem-10 which was the blue variant running TOPS-10, as distinct from the orange version which ran TOPS-20 (DECSYSTEM-20) - (KL-10E). KL-10 based DEC-10s also were different from DEC-20s in that they booted from DECtape where -20s booted from RX01 (5 inch) floppies - in both cases using a PDP-11/40 as the primary front-end computer, and -10s had external memory busses while -20s had internal memory. (Exception for the purists who remember these things, the 1091 was indeed a blue 2060 and did boot from floppy - I think that there was also a -1095 with the same relationship to the 2065.)
If picture 8 isn indeed the central backplane wire-wrap of a KL-10, then I have an enduring memory of having this Field Replacable Module' being replaced not once but twice on a DECSYSTEM-20 (2060) in the mid/late 1980s for ICI on Teesside. Shipment on a pallet some 3m x 1.5m x 2m as I recall!
In addition, Digital eventually shipped us a 2065 (and then downgraded it to 2060 because I'd never go round to upgrading the OS - failing to maintain n-1 is nothing new!) diverted from initial installation to keep us running until the main machine was eventually fixed.
PS: If anybody wants a picture of it, I have part of a KI-10 control console in my garrage!
Not on the main point ... but Tru64 and the associated TruCluster products never ran on VAX hardware ... it was always an OS for the Alpha platform, and to the best of my knowledge never successfully ported to any other architecture - despite HP's worst efforts!
And in any case - who cares about HP-UX any more - post the Oracle debacle isn't it going the same way as Tru64 anyway.
And BTW - anticipate that the reference to September 2009 update should read 2011?
"Decsystem-20 -- the poor man's Dec-10, running Tops-20 (Tops-10 with a different hat on)."
There was of course considerable rivalry between the supporters of the two (mainstream) operation systems for the "PDP-10" family. (Other operating systems were available - but not from DEC). There is a recorded view that the DECSYSTEM-20 was indeed marketed at a smaller customer than the equivalent -10, and the -20 never evolved to support multiprocessing as the -10 did in the 1088/1099 models (two KL10As back to back). Where identical hardware (1091/2060 KL10-E) was deployed, you could probably attach more terminals to a TOPS-10 system. But perhaps that was the blue paint.
However, the two operating systems were significantly different. TOPS-20 was perhaps one of the most interesting Operating Systems of its generation and the internals were completely different from TOPS-10. TOPS-20 was perhaps even more thread and process driven than UNIX, and exploited virtual memory and mapping techniques that were not seen in other systems for another 20 years. There are a number of accounts available of the evolution of early versions of TOPS-10 into TENEX (with the addition of university developed paging hardware for the KA-10), and then ultimately into TOPS-20 at the hands of Digital themselves with the introduction of the early KL-10 - but -10 and -20 models ran different microcode to provide the different virtual memory management required (-10s were an evolution of the KI-10, -20s had the full native mode).
What is true is that many utilities and applications (including many DEC products) were shared between the two platforms and the availability of a compatibility package (PA1050) provided with TOPS-20 allowed aspects of the TOPS-10 stack to run under TOPS-20. To the best of my knowledge, native TOPS-20 code could never run under TOPS-10.
Both TOPS-10 and TOPS-20 were however evolutionary dead ends, sad to say. My memory is beginning to fail, but my recollection of TOPS-20 was that the bulk of the OS code was written in MACRO-20 and was highly tailored to the unique PDP-10 architecture with its 36-bit word structure. Extending memory addressing beyond the 18 bits provided in pre-KL and on the KS models always appeared to me to be a real kludge. (I generally found extended sections to be more trouble than they were worth.) It was this dependence on the hardware architecture that would have really prevented movement to other hardware architectures - as was proven as UNIX developed. It is perhaps sobering to recall that VMS went through several major re-writes during its lifetime, and that the OpenVMS that was ported across to originally the Alpha architecture by Digital and later to Itanium under HP (I'm still waiting to hear if it evers makes it to x64) bears little source code resemblance to the V1.0 version VMS that shipped for the VAX-11/780 in 1977.
(mines the one with 36 pockets)
No sorry, the KL-10 was by no means 'cool'. How many times did we find our DEC on-site Field Services rep curled up having a kip in the KL-10E (2060 ie an orange one) expansion cabinet? Very nice warm comfortable spot if I remember correctly among all that ECL logic!
Talking of KL-10's, was the 'Massbus' replacement CI and Ethernet option the most expensive NIC ever? My memory is of the order of $36K (Thirty Six Thousand US dollars) in the late 1980s.
Yes, many interesting memories over the years. Here's one that few people may have realised was possible. Back in the late 1980s a certain large British (nay imperial) chemicals company was implementing a 'market intelligence' system based around the ALL-IN-1 products. Availability was wanted fairly much 24x7 (yes, it was on a VAXcluster) however as anyone who has designed infrastructure to support ALL-IN-1 will recall, it was necessary to ensure that the whole of the file store was backed up while fully consistent. That really meant shutting down the system and trowing all the users off while the backups were performed. Our solution was to use the (RA8x) disk mirroring capability of the HSC storage controllers to break out a member of the mirror-set(s), mount it up and run the backups against those volumes ... then of course re-sysnc them back into the mirror sets. EMC BCVs eat your hearts out - this was when EMC2 (remember the 2 superscript?) was still a bit player selling add on RAM and other boards. I still have the glass tankard given me by an EMC2 salesperson to prove it!
I guess that alongside the other great Digital systems I've worked on from DECsystem-10 and DECSYSTEM-20 of various flavours (including having a Jupiter order canceled under my future employer when the LCG part of DEC was killed in 1983 - does any body in the UK remember the York meeting when this was commincated?), a number of PDP-11 hardware variants and operating systems, virtually all types of VAX system (save the 9000 which ought to be explicitly called out in the list of DEC super-losers) and through into many flavours of Alpha with both VMS and Unix, I stayed an advocate of Digital storage through to the end of the true StorageWorks era and participated in the Digital Storage Fellowship programme.
So, like many others on this and other threads I too owe a considerable debt to Digital Equipment Company. Although I have never worked for the company, the skills and attitudes have left me well positioned to meet many career challenges. Even today, working in an outsourcing business it is still fun to run through asset lists from contracts to see how many VAX and Alpha boxes are still running out there. It's far more than many people might expect.
Actually, that could be a real pain if you had a mixed bag of a cluster. Our first (V4) cluster included a 11/785, 11/750, an 8600 and an 8700. You didn't want the 750 to own any of the master capabilities (including mastering any distributed locks) if you wanted any decent performance!
Happy (and simpler) days!