The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
We had a pair of VAX 785s (I think - my memory of the last millenium occasionally fails me) and were running real-time flight telemetry and analysis on them. So cool and, since we very close to the runway, very noisy! Jet fighters on reheat make a LOT of noise on take-off.
- I would love to change the world, but they won’t give me the source code.
Maybe there were good uVax implementations. But the first attempt to build a small Vax was the 730. From a performance point of view, it was a nightmare!
Friends of mine were using it and reported that had timed the filling an 80 char input buffer with spaces to take 20 milliseconds. A process switch took 100 ms - 1/10 second(!). In their project, they had to change the software architecture from three to two processes (and redistribute the functions) in order to reduce the required number of process switches; that significantly increased the performance of their application. It took just a few weeks before someone got hold of a big yellow-green "Turtle Wax" sticker to put on the front panel of the machine.
The 730 was an extremely microcoded machine, with a highly vertical architecture: While the 780 had a 96 bit microcode word, so that it could issue 96 signals per microcycle, the 730 had 24 bits, heavily multiplexed. So the meaning of one bit could depend a lot on other bits, and had to be decoded by a logic network before sent to the actual circuits. The hardware itself was also far simpler, so it took a lot more microcycles to perform one complete machine instruction.
Even the 780 had some hardware limitations, the strictest one (for the performance) was that all page tables had to be resident in memory; it couldn't handle a page fault in the page fault interrupt handler. In 1970 or 80, our university had one 780 with a whooping 1 megabyte of RAM. Whenever the electronics guys ran their circuit layout program, which used immense amounts of virtual memory, they had to reboot the machine with a large page table configuration so that more than 600K was taken by the page tables and resident part of the OS, slightly more than 300 kbyte was available for paging of user programs and non-resident OS parts. You may call it "CPU abuse" to run a VAX 780 CPU on 1 megabyte of RAM, but if you weren't there at the time, you would never believe the cost of RAM in those days...
I guess they figured if you were coming from a Unix/Linux background that's the way it's always been and you should know what to expect. But if you're coming from windows you need all the help you can get...you know the GUI thing and all!
I'm currently unsupervised, I know it freaks me out too! JaxCoder.com
Raymond Chen, in his delightful book "The old new thing" (based on his equally delightful blog of the same name, [^]) he tells about this web server that just had to be available 24/7, but some memory leak made it crash every now and then, every few days. To keep the service running while they debugged the software, they replaced the server with a small cluster and a load balancer: Whenever one of the machines were reaching memory saturation, it was taken out of the cluster and rebooted. In the meantime, the other machine served the users. Later, the other cluster node would be the one to be taken out and rebooted while the first served the customers.
They did find the memory leak, and the installation could go back to single server operation. (There was no need to run a cluster for performance reasons.)
Thumbs up for "The old new thing", both book and blog! The book is fun, but you can actually learn a whole lot from it, especially about legacy and backwards compatibility. (And especially if you just completed your degree and have very limited experience in the commercial world.)
that's from the console - it's then assumed that it's either a single user machine or locked up in a server room - so that user accessing the command should have a clue or two what they're choosing to do.
running the gui remotely normally* doesn't allow root operations (* - of course there are hoops that if correctly arranged and jumped through that can change)
sudo is only for children and below* (* - people that really should just stay on windows)