On Thu, Mar 22, 2018 at 5:05 PM, Bakul Shah <bakul(a)bitblocks.com> wrote: ​....​ ​Maybe and maybe not.​ I worried about this a bit myself. But I think the difference I think is that while computer scientist may be using Fortran, it is still pretty heavily used in the 'hard science' - certainly physics and chemistry - because as was already pointed out -- it is still the best language for doing complex mathematics. And more over, the language (like UNIX) has changed. If you look at modern Fortran code, it looks more like Algol than Fortran-IV. Every scientific code that I know of (with the exception of SPICE), that got recoded into C or C++ -- *has slowed down or gotten more complex.* And in SPICE3's case, TQ spend hours staring at Ellis code in SPICE2. Tom was on his own a 'bad ass' Fortran programmer, so he knew the trick Ellis was taking. And, like other codes I know, it took a bit before TQ got SPICE3 in parity much less better. In the end, what made SPICE3 replace its older brother, was a new feature (easy addition of new transistor models), but I think TQ would we one the first to tell you, it was very hard to beat Ellis's FORTRAN. The reality is Fortran is a great tool for what it is designed to do. An most of us on this list don't do that work, so we don't value it. But if you have to nasty math is partial differentials, complex numbers, etc - Python, C, C++ are fine for very small things. But if you have a production code that is going to run for hours, if not days, on a supercomputer, chances are it is Fortran. For instance the last time I looked at WRF about a a year ago, which is the premier weather code (and you hear about every night on the news with the different 'models' the weatherman talk about), that is a FORTRAN-90 code. We were looking at the how to speed of the messaging stack under the covers and were interested in how it stressed the networking stack. It has begin/end style looping, and its very modular. The complex and unreadable part is MPI and the stuff to make it run in parallel. It's not the Fortran-ness. I suspect anyone on this list like me, that reads C could look at that code and understand it pretty quick. The question (and a good one) is if you are not 'a Fortran person,' are you going to be able to understand it well enough to not do damage to it, if you modify it? Which is of course the crux the question Bakul is asking. I suspect, it is not as bad the science fiction movies profess. Because the codes have matured over time, which is not what happened with Y2K. Are their 'dusty decks' sure - but they are not quite so dusty as it might think, and as importantly, the code we care about are and have been in continuous use for years. So there has been a new generation of programmers that took of the maintenance of them. ᐧ

I'm really not worried about it. When I got into kernel programming I had no idea what I was doing. I just kept at it, did small stuff, the bigger picture slowly came into focus. After a couple of years there wasn't much that I wouldn't take on. I stayed away from drivers because I had figured out that Sun had their stuff but it was going to be different than SGI's stuff and both different from PC stuff (even the PC stuff was different, I would have been working on ISA bus devices and that's long gone so far as I know). But file systems, networking, VM, processes, signals, all of that stuff was pretty easy after you got to know the code. Every year someone takes some young hotshot and points them at some "impossible" thing and one of them makes it work. I don't see that changing. On Fri, Mar 23, 2018 at 12:28:47PM -0700, Bakul Shah wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On Fri, Mar 23, 2018 at 3:23 PM, Clem Cole <clemc(a)ccc.com> wrote: Speaking of how ancient code works... There's still AT&T code dating to v5 or older in *BSD.... It's been updated, improved upon, parts replaced, etc. But there's still some bits dating all the way back to those early times. Having competition from Linux is great and keeps the BSDs honest... Warner

On 23 Mar 2018, at 19:28, Bakul Shah <bakul(a)bitblocks.com> wrote: I think that this is indeed a problem: it just isn't a problem for the kind of huge numerical simulation that gave rise to this thread. In general programs where - you continually are looking for more performance, - you are continually updating what the program can do (adding better cloud models, say), are pretty safe. But programs which get deployed *and then just work* are liable to rot. So, for instance, a retail bank's writes or buys a system to deal with mortgages: once this thing works then the chances are it will keep working for a very long time because the number of mortgages might double in ten years or something, but it won't go up by enormous factors and mortgages (at the retail bank end, not at the mortgage-backs end) are kind of boring. Retail banks are risk-averse so they like to avoid the risks associated with porting the thing to new platforms. And since there's no development most of the developers leave. And then ten or twenty years later you have this arcane thing which no-one understands any more running on a platform which is falling off the end of support. And if that was the only problem everything would be fine. In fact, several times during the life of this thing, the bank wanted to offer some new kind of mortgage. But no-one understood the existing mortgage platform any more, *so they deployed a new one alongside it*. So in fact you have *four* of these platforms, all of them critical, and none of them understood by anyone. To bring this back to Unix history, I think this is an example of a place where Unix has failed (or, perhaps, where people have failed to make use of it properly). Half the reason these things are such a trouble is that they aren't written to any really portable API, so the bit that runs on Solaris isn't going to run on AIX or Linux, and it only might run on the current version of Solaris in fact. I don't know what the solution to this problem: I think it is essentially teleological to assume that there *is* a solution. --tim

On 3/26/2018 12:19 PM, Paul Winalski wrote: For Sun, it was quite the contrary. It was normal to run binaries from SunOS on Solaris. For the longest time, the "xv" binary I used on SPARC hardware was compiled on SunOS. It's even an X-windows application, and the libraries work. Even in Solaris 10, it still runs: -bash-3.00$ ./xv.sparc ld.so.1: xv.sparc: warning: /usr/4lib/libX11.so.4.3: has older revision than expected 10 ld.so.1: xv.sparc: warning: /usr/4lib/libc.so.1.9: has older revision than expected 160 -bash-3.00$ file xv.sparc xv.sparc:       Sun demand paged SPARC executable dynamically linked -bash-3.00$ uname -a SunOS redacted 5.10 Generic_120011-11 sun4u sparc SUNW,SPARC-Enterprise This has been deprecated as of Solaris 11, supposedly. Backwards compatibility for Solaris binaries is also a "thing". art k.

On Mon, Mar 26, 2018 at 12:19 PM, Paul Winalski <paul.winalski(a)gmail.com> wrote: ​Paul be careful here. Yes, BSD did that. I'll never forget hearing Joy once saying he thought it was a good idea to make people recompile because their code stayed fresh. But as UNIX move from Universities to commercial firms, ​binaries became really important. DEC, Masscomp (being ex-DECies) and eventually Sun took that same promise with them. Linux has been mixed. The problem is that UNIX is more than just the kernel itself. As the SPEC1170 work revealed in the late 1980s/early 1990's - there were 1170 different interfaces that ISVs had to think about and agreeing between vendors much less releases within vendors was difficult. And here is an interesting observation ... The ideas behind UNIX was (more or less) HW independant. Just think, how hard it was for DEC, Masscomp or SUN to keep VMS or Ultrix/Tru64, RTU, SunOS/Solaris binary compatible. It's part of why the whole UNIX standards of API *vs.* ABI wars raged. It was and is a control problem. Linux (sort of) solves it by keeping the Kernel as their definition. But that really only partly works. kernel.org streams out new kernels way faster than the distros. And the distros can not agree on the different placements for things. Then you get into things like Messaging stacks. It why Intel had to develop 'Cluster Ready.' I will not say to protect the guilty, but one very well known HPC ISV had a test matrix of 144 different linux combinations before they could ship.... Just to give you an idea .. if they developed say on IBM/Lenovo under RHEL version mumble, but tried to release a binary on the same RHEL but on say HP gear, it would not work, because IBM had used Qlogic IB and HP Mellanox say. Or worse they both had used the same vendor of the gear but different releases of the IB stack (it gets worse and worse). The issue is that each vendor wants (needs) to have some level of control. Clem ᐧ

Portability and standard API are very good for users, but manufacturers hate them.  Unix portability was supported by AT&T in part because they were getting flak from non-DEC manufacturers about Unix running only on the PDP-11.   Once Unix was ported, applications could run on hardware that was cheapest and most appropriate to the application rather than where it was first written.  Users, much more than computer companies, benefited from portability.  And DARPA, with a similarly broad view, for the most part did things that helped users rather than specific manufacturers. In fact, the first thing most manufacturers did with Unix was to change it.  The rot set in quickly, leading to long boring chaotic standards efforts over POSIX and C (remember OSF?). On the other hand, manufacturers love open source.   There are no apparent limits on growth, and few guiding hands to prevent silly, or downright dangerous features from creeping into the endlessly bloating code bases.  Each company can get their own version at low cost and keep their customers happy, serene in the knowledge that if the customers try to use another system they will have to deal with the 100+ pages of incompatible GCC options and have to tame piles of poorly concieved and documented code.  None of the stakeholders in open source have anything to gain by being compatible, or even letting people know when they change something incompatibly without warning.  After all, it can only hurt the other stakeholders, not them... Yes, I'm old and cynical, and yes there are some islands of sanity fighting the general trend.   And yes, I think this is a cyclical problem that will swing back towards sanity, hopefully soon.  But where is the AT&T or DARPA with enough smarts and resources to do things simply, and motivation to make users happy rather than increasing profits? Steve ----- Original Message ----- From: "Tim Bradshaw" <tfb(a)tfeb.org>rg>. . . To bring this back to Unix history, I think this is an example of a place where Unix has failed (or, perhaps, where people have failed to make use of it properly).  Half the reason these things are such a trouble is that they aren't written to any really portable API, so the bit that runs on Solaris isn't going to run on AIX or Linux, and it only might run on the current version of Solaris in fact.

On 22 Mar 2018, at 21:05, Bakul Shah <bakul(a)bitblocks.com> wrote: My experience of large systems like this is that this isn't how they work at all. The program I deal with (which is around 5 million lines naively (counting a lot of stuff which probably is not source but is in the source tree)) is looked after by probably several hundred people. It's been through several major changes in its essential guts and in the next ten years or so it will be entirely replaced by a new version of itself to deal with scaling problems inherent in the current implementation. We get a new machine every few years onto which it needs to be ported, and those machines have not all been just faster versions of the previous one, and will probably never be so. What it doesn't do is to just sit there as some sacred artifact which no-one understands, and it's unlikely ever to do so. The requirements for it to become like that would be at least that the technology of large-scale computers was entirely stable, compilers, libraries and operating systems had become entirely stable and people had stopped caring about making it do what it does better. None of those things seems very likely to me. (Just to be clear: this thing isn't simulating bombs: it's forecasting the weather.) --tim