XP runs like a snail on Valium on the machine in question, which is why I'm investigating Linux. For the use intended, ME is known to work without problems. It should never even be connected to a network more closely than by sneakernet and a shared USB drive, so security won't be a problem.
Workflow will be 4 or 6 audio sources - record - edit- burn CD.
While editing, backups will be made, but not over a network.
For 2 track work, I've got a nice, silent laptop that runs 98, and a very nice little interface to gowith it. Total power use is about 30W.
That kind of obsessive BIT was commonplace in the military and aerospace environments years ago. It may still be but I got out of the industry. IIRC I pointed out the same thing myself but got the standard answer "It's in the spec" so we had to implement it.
Yes.... It was actually 'better' than that.... The entire project was designed in some kind of supa-duper high-level design methodology (MASCOT - if my memory serves me right). This was all about high-level graphical designs (using pencil & paper!) and multiple reviews at every stage. They solemnly designed and reviewed the spec for my POST, and discussed in infinite detail whether it'd be better to clear a register or load 'zero' into it.... that kind of committee-based nonsense Eventually, a detailed spec arrive with me, which I coded in TI assembler.
Then they realised that nobody else on the project spoke TI assembler - (which is why I was there on contract in the first place!) so there was no way that anybody could independently review by finished work.
So they just scribbled some made-up initials in the 'reviewed' box, and carried on......
Daft! - but it kept me off the streets for a year or so....
That takes me back a bit... the joys of the ACP diagram! A standard that does not quite know if its a design methodology, a language, or a run time system ;-) (answer: its most of those, with a strong leaning toward CORAL 66 IIRC).
Sounds somewhat similar... played much the same game for a network of milspec workstations running 16MHz 80386 when 80386 was new and sexy[1] in the late 80's.
[1] They built a working system running on standardised (to the project)
8086 cards, and found firstly this particular app was going to be two slow on them, and secondly, although each application would fit in the available EPROM space, the box was supposed to be able to behave in one of four different roles selected at startup, and there was not room to get all four in there. The hardware team had come up with a '386 card to "solve" the problems. Had they have left it at that, they could have slapped some extra storage in the box and a bit of bank switching logic, let the thing power up in real mode and stay there, and they would have been back to a working system in a couple of weeks what what looked like a 'kin fast 8086 and some switchable ROM space.
Alas someone thought it would be fun to play with the new '386 toy and set about building a MASCOT kernel for it in protected mode, and then titting about attempting to create virtual 8086 tasks to run each role, having cobbled together the required address space for it using the memory protection tools the processor has. All clever stuff at the time, but in the days when you asked intel for assistance and their response was "wow, no one has tried that before, can you let us know how you get on!" - it took over two years to get back to square one!
Actually some of the mil spec stuff made sense, like watchdog timers and filling spare blocks of ROM with reset instructions..so if your missile got EMP'ed it would reset itself, or self destruct if that failed.
And there was a bit of a fuffle round the lab when some bright spark remarked that if an early version of sea wolf would pop its clogs 1/4 second after losing radar beam ride, this would be embarrassing as it didn't get INTO the beam for half a second..and would self destruct as it passed the ship's bridge.
I had the reverse. Did some work for Gould - digital scope.
After a week looking aghast at getting on for a meg of bank switched RAM on a 6809 I sweetly asked 'frankly, why didn't you get a PC motherboard, plug in all your clever analogue D to A, and use it as a scope instead with a standard VGA screen?'
"mumble mumble..we didn't know it would get this big when we started.."
Never worked on miltary kit - but similar requirements on warehouse automation / automatically guided vehicles etc - though we tended towards the 'I'm confused - I'll sit here, flash my lights and look pathetic' rather than actually self-destructing
Mmmm! There was the story (possibly true) of the torpedo guidance system that had a fail-safe mechanism built into the code by a helpful programmer.
Logic ran - 'if I suddenly find that I'm on a reciprocal compass bearing to the one I was on when I left the sub, then '
Allegedly, one day on weapons trials, the armed fish got stuck in the launch tube, at which point the Captain said - "B*gger this, lets go home" and executed a swift 180-degree turn... and blew the sharp end of the sub to bits!
As long as what I want to do is supported. The machine I'm working on is to be used for recording 4 tracks of audio to 24 bit, 44.1KHz files at a time, through an interface which Linux supporters claim "just works".
Ubuntu studio with Ardour or XP with Cubase would be the ideal as far as software goes. I'll have a look tonight, maybe, if I'm not starting work at sparrowfart tomorrow.
I seem to recall one tale of a homing torpedo that had a nice bit of logic in the control software to self destruct it should it find itself on the reverse of its launch bearing. Was a nice idea until someone tried a test launch that failed totally - and it was left sat on the deck not having moved. Then they turned the ship round to come home...
(it was not fitted with a main charge, but it did have a detonator!)
Military kit tends to avoid safety critical software if at all possible (using easily provable hardware interlocks etc). However the MoD definition I always found slightly amusing, as begin "software that has the capability of unintentionally causing death". I.e. accepting that its quite possible to have software designed to kill you that is not safety critical.
Well not having read your post I just posted the version of this I heard... so there may be some truth.
There are a few other possibly apocryphal tales of a similar nature that do the rounds.
The one I herd was a fly by wire fighter on a test flight and he pulled the stick right back.
At some point this caused a digital multiplier to overflow offering a large negative number and it went into a steep dive instead.
I alwys liked the 'Slide Rule' book where Neville Shute works on the private R100. Their competition is the R101 which is to be given diesel engines, by government decree. It is heavier, and therefore they worry about the ability of the pilot to turn the wheel that works the rudder. Power steering is employed, and of course, this has to be limited to prevent the pilot from tearing it off.
This worries Shute and his colleagues, as they are simply using cables..they redo the calculation and indeed confirm that with the gearing they have, the pilot simply wont be strong enough to tear the rudder off against the back pressure....
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.