279 karma · joined July 30, 2021
https://med.stanford.edu/news/all-news/2022/01/epstein-barr-...
It really feels at this point that not by connecting these diseases together and treating them as a class, we're missing the woods for the trees. Sadly, all of the economic incentives are to keep treating them separately and reductively because chronic diseases are great long-term revenue generators. TBC, I'm not attacking the drug companies here (UC was a killer until pred was discovered in the 1950s and Vedolizumab is working fantasically well for me) but we need the immune system to be treated as genuine clinical and research discipline to really cure these things.
My last UC flare was preceeded by a bout of shingles which is caused by an opportunistic latent virus. My doctors always talk of my immune system as being over-active. It really seems to me that it's more the immune system becoming disordered - which latent viruses play a major role in. My docs aren't remotely interested in having that discussion because it doesn't involve the details of gut epithelial cells. Fascinating as they are, I don't think we're going to cure UC or any other AI disease by focusing on them.
A friend who was recently diagnosed with UC (but with many other obviously AI symptoms / conditions) has managed to get himself referred to a Rheumatologist which is almost certainly a good thing.
But regardless of how good a rheumatologist might be at dealing with it, it isn't a fix for the issue that the immune system isn't treated as a first class citizen in medicine.
Other folk I know with AI diseases have seen similar patterns and have for example seen improvements to things like PN when they went on anti-inflammatory drugs (5-ASA in the case of one friend) which were prescribed for UC.
I don't think the PN was caused by the Azathioprine. I have always felt it was a co-sypmption that I get as a "bonus" when the colitis flares.
Yet another case of the environmental Baptists providing cover for the polluting bootleggers.
I've worked my way through azathioprine (poisons your bone marrow to reduce white blood cell count - great for getting skin cancer) to vedolizumab which targets a single gut immune system signaling molecule. I'm lucky in that both have induced full remission which means all the inflammation related symptoms go away, not just the colitis. But I know many people who aren't that lucky and who get some symptoms controlled while others continue unabated. And then there are folk like you who seem to get nothing.
The immune system in complex in the proper sense but we still treat the problems it causes reductively. Worse, most of the research that is done treats it reductively also. If COVID had a silver lining it was that it seemed immune system research got a couple of decades of research done in two years. But when I'm talking to my GI, I really feel that nothing has changed and that at some point, I'm going to flare again, get deeply depressed, be unable to move properly or exercise, lose feeling in my toes and after the steroids have ruined me a bit more, I'll be stuck on a new IBD drug and will hope for the best.
We need these diseases to be treated systemically, as a class and for the immune system to have it's own specialists in research and treatment. They would be able to act as sherpas for sufferers but more importantly, would be a point of nucleation for new ideas about the immune system since they would be exposed to the gamut of problems sufferers face.
It makes me angry, which is probably a flare-risk factor...
Lack of impetus
There are plenty of neobanks out there that have built scalable, secure infrastructures using modern development practices in the cloud. But despite growing rapidly, none of them has the scale to challenge the big banks. Similarly in areas like the airline industry, the big airlines are all old and back-end technology is rarely the deciding factor in whether or not one airline is more efficient than another. There simply isn't as strong an impetus to change as you'd expect.
Risk
There is very little incentive for any given executive at one of these firms to take the risk involved in staking their reputation on a big technology migration. Equally, there's nothing quite like a failed transformation project to destroy the careers of those associated with it. If you think mainframe is antediluvian, take a look at the ERP software the same companies are running. Layer upon layer of legacy with custom code built to manage myriad edge-cases that nobody understands anymore. Why take the risk when you can build a new system that integrates with the mainframe using (for example) a modern database that gives you a modern transactional API while micro-batching updates back to the mainframe. The incentives are all to create additional cruft.
Outsourcing
Most if not all of the big banks, airlines etc. have outsourced considerable parts of their operations over the years. In doing so, institutional knowledge was shifted out of the business into those outsourcers. The outsourcers in turn have little incentive to drive transformation of the mainframe given that a move to cloud sees their revenue deriving from the infrastructure management go to near zero. The outsourcers don't even have to act in bad faith for this to be a major problem. McKinsey and the rest thrive on complexity and by advising clients to outsource, they layered organizational and contractual complexity on the technology complexity, making the problem of transformation increasingly irreducible.
After risk, outsourcing is probably the most important factor since it is extremely difficult to create outsourced structures which maintain and develop an organic link between those responsible for business processes, and those responsible for technology. The result is an ever growing pile of sclerotic processes, dysfunctional governance bodies and uni-functional teams (often themselves outsourced to different parties for competitive purposes) that purport to control but which really just create complexity.
Outsourcing has served to worsen the organizational complexity that most mainframe users already suffered from. The result is a situation in which any programme of work to get off mainframe becomes fearsomely complex. I've worked in places which would have regular meetings of large parts of the company to try to coordinate major business process change in a single area. I've seen companies nearly break themselves trying to bring a single outsourced business function back in house. The question is why, when they're so incredibly inefficient and inflexible, they aren't competed away. That's a different question on which I have my own opinions, but this comment is too long already.
Knowledge
The loss of COBOL and other mainframe technology knowledge is real. I remember working at a bank in the EU around 2010 where I sat with a bunch of elderly gentlemen (walking sticks were a theme) who had been contracted back into the bank to develop integration between an ancient mainframe application and something modern the bank was building.
But that stereotype aside (there are surprising numbers of younger mainframe experts in India thanks to outsourcing), the problem is real, particularly when it comes to migration of software from mainframe to cloud using modern development practices. Any migration away from mainframe software requires understanding the whole technology stack and more importantly, how that stack interacts with the equally complex stack of business processes.
AI code interpretation and generation might take a COBOL program and translate it into modern code, or even help re-architect it using modern principles. But without that understanding of the business processes as well as the up and downstream dependencies in their many forms, anything other than piecemeal change looks terrifying to anyone who might try to move away from mainframe.
IBM
The fact is that mainframe is an effective technology stack. But more importantly, IBM has become extremely good at both keeping it up to date while also owning the best ways of modernizing it.
They're good at making sure they control the path away from mainframe. The best, simplest and lowest risk approaches to getting off legacy code on mainframe are either developed by or bought by IBM. By enabling Linux on mainframe and providing straightforward migration paths from legacy code to that platform, IBM (and its many partners) ensures that modernization of mainframe for the most part means staying on mainframe. This has gone through multiple phases and taken lots of forms over the years but really, IBM has done a stupendous job of ensuing that the future of mainframe is usually mainframe.
The advent of AI code interpretation and generation is another example of this. IBM has already announced their own AI tooling to help customers make the migration to mainframe Linux faster and smoother: https://newsroom.ibm.com/2023-08-22-IBM-Unveils-watsonx-Gene....
The challenge for any AI startup or professional services company wanting to help customers move away from mainframe is that the people best placed to sell those tools are... IBM and its partners.
Might the situation change?
AI code interpretation and generation is getting better all the time. LLM context sizes are growing rapidly. The possibility of fine-tuning a code-generation model using a business' own source code is there. It's even possible that businesses who no longer have source code can use AI to analyze and decompose binaries. The days when AI can analyze a whole software infrastructure, re-architect it and re-write it whole-cloth are coming. But even with those tools, the organizational layering, process cruft and generalized loss of institutional knowledge is going to make elimination of mainframe a long-term, high-risk project.
This is not to say that it won't happen. But technology change can only ever happen successfully at the rate an organization is able to change along with it. The organizations which still use mainframe tend to be the biggest, most complex and sclerotic organizations on the planet. IBM is going to be enjoying the benefits of what it built decades ago for decades to come.
There was an interview with Jim Radcliffe recently in which he described Ineos’ approach to safety. It’s a variation on what’s described my Steven J. Spears in his case study of Alcoa. The truth is that the private sector has innovated much of what’s best in modern safety practice in a way that has made monumentally dangerous industrial processes routine.
There are perhaps good reasons to keep nuclear weapons management in the public sector. Canards about the safety record of the private sector are not though.
If there’s a real problem, it’s that we have still not made publication of negative results sufficiently attractive. That’s still a problem throughout science and one we desperately need to address since it is what would let us think more clearly in situations like this.
Feels like a good way to consolidate and push forward. It also gives me a bit of culture since news articles are revealing of the way people think.
"When ordered to produce information about what 149 different data systems within Meta do, and what parts of Meta’s business use them, the company was unable to respond. This was despite having conducted a year-long investigation of those systems."
There is no point having a law which essentially no company can be compliant with. It means that the law will almost certainly be applied only by exception and hence capriciously. The likes of Facebook may be able to use that as a defense despite their breaches being egregious.
As a side-note, the idea that Meta only has 149 in-scope data systems sounds ridiculous.
The U.K. monarchy clearly lacks the wherewithal to influence Australian politics today that it possibly had back then and has nothing like the influence (through the Euro) of the ECB on the democratic Governments of Eurozone countries.
The lesson might actually be (ironically if so) that the monarchy would be more resilient to republican opinion if it wielded more power. It is the perceived pointlessness of it that will lead to its decline, not any strength.
https://classicsforall.org.uk/news-and-events/events/moot-tr...
File system filter drivers were where the chaos this caused manifested. If there was just one loaded, you might not see any problems (though the anti-virus guys could be relied on to find a way...). But once you had a few (AV, file system quotas, backup etc.) all sorts of horrible things would start happening.
People always complained about blue screens but experience taught us to love and cherish them as it meant the damage a filter driver had done had actually been caught rather than it silently doing horrible things to files. The other nice thing about the BSODs was that you could always pinpoint the driver that had pooped its pants by analyzing the dump file.
In the NT4 days, manipulating the load order was a simple registry entry for the driver. We put a lot of time and effort into finagling them to figure out which were the worst offenders. In the end, we just figured out which combinations of filters were worst and quit using them.
Windows 2000 (I think) fixed this by removing the ability of drivers to manipulate the load order. That forced the driver writers to up their game a bit and write the code necessary to deal with whatever something lower in the stack had done.
It's vitally important that Southerners keep talking in silly accents. It's useful to spot people who are going to try to steal your stuff using emails.
Monks: opinion that requires authority