John Carmack Goes On Coding Retreat With OpenBSD

[DrYak]

It's still a poor choice to use an underdeveloped OS with a shitty old stack for such a sophisticated purpose though.

Well actually, when you look into it...

openbsd looks like joke os

...that might actually be the point. The "Joke" part.

John Carmack finally goes into vacations, even if he isn't much into it(*).

Remember your latest week-end skiing ? When you decided to take *that* ski hiking trail ? The shitty one, but you decided to take it anyway as a challenge, just for shit and giggles ?
That's why Carmack picked-up OpenBSD. For the lulz. For the challenge.

His best vacations is trying something new and unusual (a new OS, a new field of work) on his most favourite hobby (computers).
So he decided to pick-up OpenBSD to take it on a rite with NN. Juste because.

He's not trying to state that BSD is the new best OS. He's just doing something new for a change.

----

(*) He's a big geek who loves computers, and managed to find people who are ready to give him money for his favourite hobby. Why would he go on vacation ? This "thing" that other people call work *is* what he would love to do.
So when he is finally pressured by his wife into taking some time of, he does the thing he likes the most : still hacking computer.

[coder]

Thought this old .plan file of his might be relevant here:

http://rmitz.org/carmack.on.operating.systems.html

I remember reading that, BITD. Also, played Quake on Win NT SMP and was disappointed to see it was only single-threaded.

Anyway, given his glowing praise of NeXT, I wonder if he stuck with its spiritual successor in OS X, as that .plan promised.

[dwagner]

if you ask me, having public streets with no speed limit is a plain dumb choice, but who am I to judge? I'm not german after all.

Some nations' citizens are allowed to buy guns from their supermarkets, some don't require any kind of technical qualification of vehicles safety, some do not require furnaces and chimneys to be inspected for not exhausting CO into the room, some allow companies to put almost whatever chemicals they like to into food... I guess the perception of risks are just pretty different among nations, and not quite rational in many cases.

[sabriah]

Not because it's a good language. They're either too stuck in their ways to learn anything new, or still believing it's faster.

Restricted pointers closed most of the performance gap, and anyone wanting really fast numerical code is using GPUs.

Well, they'll have CUDA Fortran for the GPU:s; I haven't seen any benchmarks but I guess the speed is there too.

[AndyChow]

Yes it does, "rot" happens because the rest of the environment the software runs in does not support it anymore.

Banks core operation didn't change much in the last few centuries. Only thing that is changed is the interface for the front-ends, assuming they need that at all. Since they are using a backend server anyway, they can afford to not care in the slightest about what OS is running in there.

Is this a bad example? yes it is.

Also, I'm pretty sure you meant COBOL, banks here have mostly COBOL, not Fortran.

Costs of development have been ignored to write this post.

Also PHP should just die in a fire.

Banking has changed a lot. How many transactions happen daily compared to 10 years ago? Do you think online transactions changed the playing field a little bit? And fraud management, cost of revenue models, etc, it's changed a lot. Yes, you're correct, it's handled by the mainframe back-end, which people ignore because it "just works", but it just works because the infrastructure it there, working, invisibly.

If you buy a suit and have just a few dollars left in your account, then go buy groceries in another store a few minutes later, without the money in your account, that transaction is refused. The merchant terminals can operate in completely different banking systems, in different countries, and yet the system works. And if you do have money, the transactions passes. It's not put on hold for a few minutes while the systems try to ascertain your situation. Different acquirers than your bank, different geographical systems, handling billions of transactions daily, and it always works. That's something.

You're right, I did mean COBOL. I'm still used to my old life in insurance where it was all FORTRAN, and sometimes, if you are unlucky, APL. Banking is mostly COBOL, on the mainframe side.

Pragmatic people seem to like PHP. I don't, but hey, if they do, it's okay by me. Java needs to die in a fire.

[AndyChow]

Don't forget that many scientists still run Fortran code too! Think NASA and the like.

Hope that could cheer you up, at least a little bit.

Hey, thanks. I used to work in insurance as an actuary, and all the backbone was Fortran. Some APL, but I'd rather forget about that. I was pondering about all the wasted resources from resolving the same problems over and over again, and got in a funk. I'm all good now. But thanks for the humanity. Cheers!

[coder]

The merchant terminals can operate in completely different banking systems, in different countries, and yet the system works.

That's not the banks' doing - that's what credit card companies like Visa and Mastercard do.

...and for that, they're rewarded with a very handsome tax on a substantial portion of all financial transactions in the countries they dominate. Hopefully, there will one day be a crypto currency that can scale well enough to give them real competition.

[starshipeleven]

Banking has changed a lot.

I said CORE banking operations. Banks do transactions and store them in some bigass list, or look in this list to get information out of it. This didn't change in the last centuries.

Compare with industries like oil and gas where they are now running physical simulations to decide where is best to drill, or a generic big company marketing that does shenaningans with search statistics from Google or other tracking while in the 80s they just snorted cocaine and followed their feelings.

How many transactions happen daily compared to 10 years ago?

Writing down transactions is a parallelizable task. The only thing that has to be a single thing (or be a centralized system with local caches) is the database itself, and a banking software is usually using a DBMS so it's already designed to send stuff to a database server which can be scaled independently.

Just add more servers running the banking software and split/share the load, while sending the SQL to the same DBMS.

Do you think online transactions changed the playing field a little bit?

More parallelizable stuff = more copies of the same program running on more physical servers, talking to a more beefy (remote?) database server or a smaller local copy/cache of the main one which then syncs the transactions over. This is a job for IT admins, not developers.

And fraud management, cost of revenue models, etc, it's changed a lot.

That's just some additional checks (i.e. more sql queries), or data mining happening regardless of the main operation.

If you buy a suit and have just a few dollars left in your account, then go buy groceries in another store a few minutes later, without the money in your account, that transaction is refused.

Did I say massively parallelizable task? Yeah I did.

Did I also say dedicated DBMS? Yeah I also did that too.

They just add more servers running the same COBOL software and talking to the same database server(s).

If there are traffic issues they add local databases caching the most common requests, but again this is all irrelevant for the COBOL program doing the business logic as it 100% happens behind its back. It gets messages to tell it of new transactions to make and it sends SQL queries to a database (decided by the IT administrators that set up the infrastructure), the same thing that did even in the stone age of computing, what magic does the database server is none of its business.

And being newer, the logic dealing with keeping databases in sync is either something commercial, sold by the DBMS provider (Oracle has something for this I think), or it's something in Java or something.

The merchant terminals can operate in completely different banking systems, in different countries, and yet the system works.

Credit card companies do this, not banks. And even then, it's not really instantaneous. It takes from 1 to 10 seconds to process a transaction, which for a computer is a pretty long time. And I suspect that they are also exploiting the time you need to physically type the password to also do stuff in the background (another 3-4 seconds).

Pragmatic people seem to like PHP.

It's much worse than java just because it is a script language, not compiled. I've seen so much dumb mistakes allowing code injections for PHP that would plain not be possible in Java.

[grok]

I remember reading that, BITD. Also, played Quake on Win NT SMP and was disappointed to see it was only single-threaded.

Anyway, given his glowing praise of NeXT, I wonder if he stuck with its spiritual successor in OS X, as that .plan promised.

You can enable SMP in Quake 3 and gain 3 to 5 fps (dual Pentium Pro 200 is still too slow.)

I remember that he did the reveal off the Doom 3 engine in 2001 I think, running on the geforce 3, G4 1GHz, and OS X.

[coder]

You can enable SMP in Quake 3 and gain 3 to 5 fps (dual Pentium Pro 200 is still too slow.)

This was Quake 1 on a quad-Pentium Pro 200 MHz in 1997 or 1998. Not sure if it had any 3D accel, at that point, but if so it was only for one or two cards we certainly didn't have. I know Quake 1 eventually got support for Rendition Verite and I think a couple others.

I emailed Michael Abrash about it and was rather surprised that he actually replied. I had read a couple of his books and many articles, so I regarded him as a sort of demigod.