I've recently gone back to my roots and started dabbling with 3D animation and compositing again. My fileserver is a FreeBSD machine running on a decent 64-bit CPU with 16GiB RAM, with ZFS. And let me tell you, ZFS is dog slow for some uses, without it being anywhere near full. In my case, lossless-encoded video, and directories with thousands of 4MiB+ images, and working against that in realtime(or trying to), the filesystem stalled out at 80MiB/s, while my old fileserver running Linux and XFS easily saturated the gigabit link

The mainframe people I know, when they rarely refer to transactions, have a slightly different meaning from when windows or unix people do it. The mainframe people more often rever to messages, which is a whole discrete task, which can often require multiple database transactions, some computational passes etc. They usually talk about hundreds of thousands of messages per hour, so if it's 2.5 billion mainframe-style "transactions"(messages), it's pretty damn impressive.

Let's not forget something as simple as debugging. Someone who understands the hardware and knows Assembler will always have an advantage when it comes to debugging.

Hardware should always be a concern, because hardware is the reality that implements the abstraction of a program. No matter how efficient something is in purely mathematical terms, it's the hardware that determines the actual performance, complexity and problems. ISA, I/O capabilities, amount of RAM etc all matter in deciding what will be the best way to implement something.

No matter how many layers of abstraction you put in to provide the illusion of being able to ignore the hardware, the reality of hardware will always matter.

Nono, like other big IT projects in the UK, it will be using "the very latest in Agile know-how", and cost 3 times as much as any clusterfuck that involves Oracle, take 50% longer, and spread 300% more blame on "old fossiles"....

Disclaimer: Had to interface with a EU project under UK IT auspices last year.... Painful....

While your faith in the religion of liberretardianism sounds fun, history empirically proves you 100% wrong.

Except that the Xbox One runs Shadows of Mordor at 720p and 30FPS. An el-cheapo PC built now can run Shadows of Mordor in 1080p and above 60 FPS stable, and with better details etc.

Something I wish I could have in a workstation again is a full-fledged crossbar switch like the Octane and Octane 2 had.

Even with emergency shutdowns, you can still get massive damage

Data invariance, even if you can somehow implement it properly on a hardware level, does not protect you if it's the execution pattern that is the attack method for example.

As an example, rapid power cycling/power state change due to a program swiftly being shunted between CPU intensive and idle threads, etc can cause power surges that can damage the PSU or the motherboard or even the CPU(as voltage regulators etc move onboard, they become ever more vulnerable to this), and for all intents and purposes the data input to the program will be fully valid and unchanged. Excessive head parking on a mechanical HD can cause the HD to become faulty. Frequent standby/active cycles on monitors can kill them fairly rapidly.

As for the emergency shutdown, nowadays, with modern equipment, the big red button and the emergency shutdown button in the control program do the same thing: Send a signal to the correct circuit and halt all operation. In some heavy machinery that means just cutting all power, in others it disengages pneumatic valves and thus engaging mechanical brakes etc etc. It depends on what kind of machinery it is.

Actually, bar codes and QR codes are used in some industrial systems to input orders, for larger batch jobs. The problem is when you are in need of continuous feedback etc, or running lots of small custom jobs.

"Sure. But software shouldn't be able to make hardware damage itself.

Also, designing something like a steelworks without some kind of hardware-level override is so stupid it borders on criminal."

As long as software can make the hardware do something, it can make it damage itself.

As for the damage, it was probably the emergency shutdown that caused the damage(i.e, what you incorrectly label hardware-level override), since it does a direct quick stop, without following the proper, slower and safer procedures for shutdown.

POSIX is, if we are to be really strict, about interaction between Unix variants. So, while it can certainly argued that it's a fault with OS/X, it's not a fault with Windows, since it's not a Unix OS. And hilariously, I know of no Linux distro that is fully POSIX compliant for that matter, nor is FreeBSD or OpenBSD etc.

Purpose built for embedding does not mean it's suitable for game use.

In fact, all of the examples you mention have serious drawbacks when it comes to using in games. Civ style games sort of forgive the use of Python, in that users are already waiting between turns in end-game, so a second or two extra doesn't matter. But a RTS, a FPS or a simulator, it definitely becomes a hindrance to the gamer, even though it might be convenient for lazy or incompetent programmers.

As another poster mentions, lack of decent multithreading is one such hindrance.

To echo the other poster: Torque is so bad that I would not force enemy combatants to use it, because that would be too cruel.