About 10ish years ago, I ended up finding a deadlock in the Linux raid driver when turning on Oracle’s async writes with raid10 on lvm on AWS. I traced it to the ring buffers the author mentioned, but ended up having to remove lvm (since it wasn’t that necessary on this infrastructure) to get the throughput I needed.
Readit Newslstroud commented on Async I/O on Linux in databases blog.canoozie.net/async-i... · Posted by u/jtregunna
lstroud commented on Ask HN: Any active COBOL devs here? What are you working on? · Posted by u/_false
I’m not a COBOL dev but I work with mainframes(z/OS).
Most COBOL applications I’ve seen have been banking and insurance related with few exceptions.
Most of them either run as a series of batch jobs or via transaction managers like IMS and CICS.
Backends are usually sequential files(we call them datasets),DB2,VSAM(Virtual Storage Access Method) or DL/1(hierarchical DB that’s part of IMS).
Quite a few places I’ve seen have run IBM MQ as well.
If changes are made to these systems it’s often due to changes in regulation or driven by changes in the business(new financial products being offered etc.
Off-topic: I’ve seen quite a few mainframe related posts on HN fly by over the years. I’ve been meaning to create an account and participate but I’ve only gotten around to it just now.
It would be kinda cool if you’d create a CICS Hacker News UI. ;)
This is quite possibly due to most of these patients already receiving DNA-damaging chemo before CAR-T therapy. It also represents only 20 cases out of tens of thousands of doses.
myasthenia gravis patients already get chemo therapy to destroy their immune cells as part of the infusion protocols. That is a treatment and is not curative. If CAR-T works on MG, then it’s not the chemo that’s doing it.
lstroud commented on Four Eras of JavaScript Frameworks pzuraq.com/blog/four-eras... · Posted by u/RafelMri
I wasn't aware of anyone using GWT outside of Google. Prototype.js + Scriptaculous was what really started the JS craze IMHO, followed by jQuery. Then came the increasingly more complex MooTools and YUI and Ext.js and friends, though nothing really took off nearly as hard as jQuery did. Backbone is probably also noteworthy as the bridge between jQuery spaghetti and the structured frameworks we see today (on the library consumption side). Knockout.js also deserves a shout out on the front of library authors looking for better abstractions.
A bunch of people messed with Rhino (IIRC Jaxer was one of the bigger ones), but Rhino had a bunch of quirks. For example, strings were Java strings, meaning that length is obtained via `"foo".length()` instead of `"foo".length`. Perhaps the biggest showstopper was the JVM variable limit per class file. Compiling large enough Rhino JS code would yield class files that crashed due to that limitation. And since JS didn't have modules back then, big balls of code were the norm.
Back then, the divide between frontend and backend was also wider. "Full stack" and the uplevelling of frontend folks towards backend skillsets wasn't really as popular as it is today. Node was also seen as revolutionary due to its async I/O first philosophy, whereas Rhino was more or less just a worse Java.
Glad you mentioned ext.js. It was one of the early frameworks that tried to create a complete, all js, gui component model.
lstroud commented on Four Eras of JavaScript Frameworks pzuraq.com/blog/four-eras... · Posted by u/RafelMri
I wasn't aware of anyone using GWT outside of Google. Prototype.js + Scriptaculous was what really started the JS craze IMHO, followed by jQuery. Then came the increasingly more complex MooTools and YUI and Ext.js and friends, though nothing really took off nearly as hard as jQuery did. Backbone is probably also noteworthy as the bridge between jQuery spaghetti and the structured frameworks we see today (on the library consumption side). Knockout.js also deserves a shout out on the front of library authors looking for better abstractions.
A bunch of people messed with Rhino (IIRC Jaxer was one of the bigger ones), but Rhino had a bunch of quirks. For example, strings were Java strings, meaning that length is obtained via `"foo".length()` instead of `"foo".length`. Perhaps the biggest showstopper was the JVM variable limit per class file. Compiling large enough Rhino JS code would yield class files that crashed due to that limitation. And since JS didn't have modules back then, big balls of code were the norm.
Back then, the divide between frontend and backend was also wider. "Full stack" and the uplevelling of frontend folks towards backend skillsets wasn't really as popular as it is today. Node was also seen as revolutionary due to its async I/O first philosophy, whereas Rhino was more or less just a worse Java.
Nobody talking about the DHTML days when we were all writing our own “JavaScript” components?
lstroud commented on On iPhone sideloading: it’s ok, I’m changing my mind numericcitizen.me/2022/02... · Posted by u/keleftheriou
You can already side load.
You can load adhoc distribution apps through itunes onto your phone. Or, you can download Xcode build and run apps onto your phone. You just can’t distribute the app in binary form to a large group.
Seems like this is about alternate app stores, not side loading.
lstroud commented on The EARN IT act is back, and it’s more dangerous than ever cyberlaw.stanford.edu/blo... · Posted by u/grappler
Will all government agencies be required to comply? I would think that would be an issue.
lstroud commented on WebAssembly: The New Kubernetes? wingolog.org/archives/202... · Posted by u/signa11
Sounds a lot more like WebAssembly is the new JavaVM. WORA, security, portability, edge, etc.
Can they at least add a liability provision allowing disaffected drivers to sue for malfunction? Maybe that would balance the scales.
It wasn’t also easy to make a living fixing bad VB apps (or going back to Delphi).
I’m not saying that components are a bad idea, but the 90s implementations didn’t quite realize the dream.