They famously did better than the proprietary shell tools in the original fuzzpocalypse https://users.cs.northwestern.edu/~robby/courses/395-495-200... . I also think I recall reading, somewhere on jwz dot org, something which purported to be an internal SGI email giving a dismal account of the quality of the Irix tools. GNU tools often have expanded feature sets, too. But I think that GNU-tools adopters were probably also driven by a standardisation impulse to at least have the same bugs and quirks as everyone else.
I mean a lot of the stuff he's complaining about being crap aren’t exactly replaceable by the GNU coreutils.
People installed them on AIX/Solaris etc because the BSD/SysV tools they came with were basically abandoned. The GNU tools had a lot more useful features, not specifically more performant (although they probably were)
> I don't know but it seems people (or at least old geezers) install GNU on top of Macs these days.
Me, I do this! I like being able to tack flags on after positional args if I remember them after typing a command. I like some of the convenience flags added to the GNU versions coreutils, grep, and findutils. Even `parallel` implementation I've used before is GNU parallel. I've never really learned mawk, to the extent I know awk at all, it's gawk.
(I don't like the common convention of prefixing them with `g` on macOS, either. I install them with Nix and just preempt the system ones on my PATH.)
Missing the little detail that since Sun started charging for developer tools, all other UNIX vendors followed suit, thus GCC finally started to get mindshare.
I think you got most details from the others, but insurance is two basically two different things:
Life Insurance is mostly a savings product, and the insurance part protects you if you live too long.
Property and casualty insurance protects you from losses, including someone's life, but also houses, cars, etc.
The domains are quite different, but they both have specific "insurance business" computing that's related to actuarial science or analysis, i.e. the statistics needed to calculate reserves, policies, prices etc.
I doubt COBOL is used for any actuarial analysis. I think SAS is still strong, but I suspect R is used now. Maybe Python is used in the more static calculations that are handed over to developers, but the actuaries are typically coding whatever they need when they create their models.
The rest is just case management, automating business rules, bookkeeping, payments, and for life insurance also systems for trading securities and funds, and possibly in-house tools for asset management.
There isn't really a strong case for COBOL. The only reason COBOL still is used is that the insurance companies where early adopters and saw computing as a way to reduce the administrative overhead. The investments were made at a time when trusting some hippies running UNIX wasn't really on the table, and even less so trusting some nerds and their rickety PCs. They built up a workforce with COBOL devs that also gained quite a lot of business knowledge.
The digitalisation created another problem - a lot of the older employees were hired to do simple administrative tasks. Even big corporations aren't totally psychopathic so it actually has taken a long time to shift out the employees, and retrain the remainder for the jobs that got more demanding. Even the employees that didn't really have that much high-value domain-specific knowledge to begin with. So the case for more automation was actually not as strong as it could have been.
Even still, although especially life insurance is a totally digital product (damage claims is not), they primarily see IT as a cost centre at heart although they probably claim they do not.
This has shaped their systems and they have tended to replace their old systems when they're forced by external factors, as the upsides - better digital sales, more automated decisions, better trading experience for their customers,etc
are not as easy to achieve as the more tangible administrative automation cost savings they started out with.
Actually, this also applies to banks. You could totally run an insurance company or bank without any mainframes or a single line of COBOL. But the organisations still have COBOL developers and maybe more important an upper management that come from that tradition.
No not really. You need an explosion or energetic impact to trigger it, and potentially a fire too. But it might become unstable by heat and more so if it's contaminated by oil.
One early industrial disaster and the biggest explosion of it's time happened because the workers in a production plant in Germany regularly used Dynamite to clear out stuck ammonium nitrate in silos. The last time they tried, the plant was obliterated together with most of the nearby town.
Maybe not as nice visuals, but it emulates the Original Spectrum port but transplants it in a VR capable renderer and adds David Whittakers Amiga soundtrack.
Interestingly, the game mechanics is as if it was made for VR.
My only problem with this (and every other) game on Linux is that it always, always wants to start on my portrait screen, which invariably screws things up. It never starts on my landscape screen, even if that's set as primary.
I don't know how to make games start on a specific screen by default, I wish games had more options for this.
This is even less complicated than an adaptive cruise control system. If you point it to in the general direction of a mountain, it very much depends on luck if the descent is possible or not.
Terrain-following is significantly more complex than the most basic forms of adaptive cruse control. Radar works much better for tracking discrete objects moving at different speeds than mapping 3d terrain. This is why adaptive cruse control will often hit stationary objects and generally disengage at low speeds.
Remember, the aircraft needs to avoid everything in a line in front of it. But, they also want to stay as low as possible to avoid enemy radar, so it also wants steer steer around hills and even trees vs simply going up.
> the distinguishing factor of effective engineers is their ability to build and maintain clear mental models.
reply