Google Chromium drops support for Linux 3.16 and earlier - <AUTHOR> https://lists.debian.org/debian-kernel/2015/03/msg00133.html <comment><USER2> Chrome "unofficially" dropped support for pre-3.16 kernels, such as the kernel in Ubuntu 14.04 LTS, about half a year ago. More precisely, they introduced a bug that caused installing extensions to fail with that kernel, and then declined to fix it.

[https://code.google.com/p/chromium/issues/detail?id=401655](https://code.google.com/p/chromium/issues/detail?id=401655)

See comment #47: "Ok, while it sounds like this is technically a regression, I'm going to mark this as Wontfix because there is a reasonable workaround of updating your kernel."

<comment><USER3> Happily there's an _even more_ reasonable workaround of upgrading to a browser that doesn't dictate kernel versions.

<comment><USER4> The whole point of even having a kernel is to run the software you like. Kernel by itself doesn't really do anything for you.

There's a feature of the kernel that Chromium wants to use. That's a perfectly good reason to upgrade.

User software should dictate kernel versions.

<comment><USER5> Well, it's a bit more subtle than that. Because it were the Chromimum developers which created the feature in the first place.

seccomp was introduced in the Linux kernel because the Chromium developers wanted a good way to reduce the harm Chromium browser processes could do if they got compromised.

Chromium is pretty much the only user of seccomp right now.

(although for example Docker also has support for it, but I don't think it's widely used)

Now Kees Cook who implemented TSYNC for seccomp in the Linux kernel works for Google. The kernel commit even lists his @chromium.org email address.

</comment></comment></comment></comment><comment><USER6> Really, a browser is now dependent on a particular Linux kernel?

For example RHEL/CentOS 7 which was released just last year with at least a 10 year support ahead of it is now obsolete according to them because it has a kernel version 3.10...

Not that many people are on desktop versions of those OSes, and those that are will not use Chrome (for example, US govt loves them some Desktop RHEL systems, but Chrome is usually not allowed there anyway), but just highlighting how still seems a bit crazy.

<comment><USER7> Chrome isn't your average application, though - it pioneered the modern use of tight process sandboxes in general (in client-side applications, anyway), and in particular was the biggest motivating client for (and Kees Cook on Chrome OS Security wrote some of the code for) seccomp-bpf, the ~3-year-old sandboxing mechanism that allows precise control of permitted syscalls and syscall arguments. The incompatibility here is related to a new seccomp feature. I don't know whether it's reasonable to drop support for older kernels, but it's no surprise that Chrome is using the latest and greatest in kernel sandboxing support.

<comment><USER8> Chrome certainly didn't pioneer anything. Google devs brought seccomp-bpf to the kernel, which is a simpler alternative (but also not always as useable) to many other mechanisms.

Chrome is one of the first products _on linux_ with a large amount of users to support a reasonably strong sandbox. But that's not what _pioneering_ means.

Of course, seccomp-nonbpf, selinux and quite a few other mechanisms have been around for a longer while. In non-Linux kernels in fact, there are FAR more secure mechanisms (but also, they don't run Linux binaries..)

<comment><USER9> There is no stable sandboxed browser protecting against kernel vulnerabilities on any platform that I know of prior to Chrome. That's the very definition of pioneering. Do you have an example of prior art? There may be sandboxing mechanisms in various kernels, but that's not what browser users care about.

As for the other points:

* "seccomp-nonbpf" is a vastly more limited mechanism than seccomp-bfp, and inappropriate for Chrome use-case. [http://en.wikipedia.org/wiki/Seccomp](http://en.wikipedia.org/wiki/Seccomp). seccomp-bfp is pioneering in Linux kernel space, even if, ironically, the team might not have wanted to spend their time there. See below.

* Popular consumer distribution of Linux doesn't have SELinux enabled by default. [https://wiki.ubuntu.com/SELinux](https://wiki.ubuntu.com/SELinux). "SELinux can be enabled in Ubuntu by installing the "selinux" meta-package". In my bubble we everyone uses Ubuntu on desktop, apologies to other distributions vying for the title of "popular consumer Linux distribution".

* Not sure why we are talking about security mechanisms on non-Linux kernels. Chrome is a browser, the team's job is not to innovate in the kernel space. [http://www.chromium.org/developers/design-documents/sandbox](http://www.chromium.org/developers/design-documents/sandbox). "Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't.".

<comment><USER8> if you give enough details you'll always find a way to work around words. For example if i ship a copy of webkit with my ui on top with a sandbox I'll pioneer that. Or a shell. Or a text editor. Or whatever you want. A blue wheel of 29.0349in on a bike. etc.

I'm not sure why I'm even replying sometimes.

</comment></comment></comment></comment></comment><comment><USER10> Replies so far for the lazy:

On Sat, Mar 07, 2015 at 07:17:13PM +0200, Georgi Naplatanov wrote:

> On 03/07/2015 06:38 PM, Ben Hutchings wrote:

> > On Sat, 2015-03-07 at 16:09 +0100, D. F. wrote:

> >> Hello, Julien Tinnes from google says that next releases of

> >> chromium will drops support for kernels without TSYNC

> >> ubuntu 14.10 already has been patched

> >> Can I to expect that debian 8/jessie will have support for

> >> TSYNC?

> > Sounds like another good reason to not use Google spyware.

> Google Chrome for Linux is the only possibility to use latest version

> of Adobe flash player for Linux as far as I know.

another good reason not to use it.

\-- maks

I guess this is why Gentoo is still my distro of choice after all these years.

<comment><USER11> That seems like an exceedingly childish exchange.

<comment><USER12> I cannot believe these are the actual people responsible for Debian. Is this unprofessional attitude common in the Debian community?

<comment><AUTHOR> Could you explain what you mean by "unprofessional" here? Personally Google's business model seems to be the unprofessional thing in this conversation.

<comment><USER13> If Debian were a business and the original poster were one of their customers, how would the OP be feeling about that exchange?

It's unprofessional by definition because it is so clear that the person responding does not consider this their profession.

<comment><USER14> But it's not a business and that person wasn't a customer. Debian is a community, bound partially by common technical ideas about packaging, stability and security, and partially by philosophical ideas about Free software.

Their goal is not to satisfy everyone who comes to their mailing list, that would be insanity.

<comment><USER13> Sure, but most people would consider the original poster's request as quite reasonable.

Instead of considering it in a balanced way and producing a polite & considered response, the response was idealistic rhetoric. For better or worse, I think that does qualify the attitude of response as "unprofessional", as stingraycharles pointed out.

<comment><USER15> Google is the unprofessional one. Threaten to not support Jessie, hey? What an arrogant self-referred world Google lives in?

<comment><USER16> I think Google is more or less "in the wrong" too, but a less snippy, snarky response would probably do more to convince people of that. "You catch more flies with honey than with vinegar", as they say.

<comment><USER15> Probably yes.

As a non-native english speaker it is quite difficult to find an enough but not too much snippy/snarky response (had e.g. to lookup these words)).

<comment><USER12> What are you implying, that when English is not your native tongue, it is easier to be snarky?

English is a second language to me, and I cannot imagine this being true.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> It's much more interesting to see how useful the replies are.

I assume they're because it's a dumb question, but still. This is an excellent example of an unwelcoming / hostile culture.

<comment><USER18> Indeed. The culture was part of the reason I made the switch from debian to opensuse a while ago.

</comment></comment><comment><USER19> I don't think Chromium has dropped support for kernels <= 3.16. ChromiumOS uses 3.4, 3.8, 3.10, and 3.14 depending on device. All of those are less than 3.16, but as far as I know, ChromiumOS is not going away.

It appears a patch needs to be cherry-picked back; a pretty common task for people that maintain older kernels. It's very common to backport patches to drivers you care about (because new kernel versions always introduce bugs in your obscure hardware, you only backport stuff that doesn't already work). There is even a system for doing it in an automated manner: [http://drvbp1.linux-foundation.org/~mcgrof/rel- html/backport...](http://drvbp1.linux-foundation.org/~mcgrof/rel- html/backports/)

<comment><USER20> Google has backported this to ChromiumOS

[https://code.google.com/p/chromium/issues/detail?id=430588](https://code.google.com/p/chromium/issues/detail?id=430588)

<comment><USER19> Yup. So it doesn't seem that unreasonable to do the same in Debian. (Though I already have 3.16 in Debian, so...)

</comment></comment></comment><comment><USER21> Can someone say what TSYNC is? Googling it did not help me, lots of links, but none that said what it actually is.

<comment><USER22> It looks like a "thread-sync" feature for seccomp.

[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1379020](https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1379020) [http://lists.infradead.org/pipermail/linux-arm- kernel/2014-J...](http://lists.infradead.org/pipermail/linux-arm- kernel/2014-July/273472.html)

seccomp ("secure computing") is an application sandboxing mechanism in the Linux kernel (since 2.6.12, 2005-03-08). seccomp allows a process to make a one-way transition into a "secure" state where it cannot make any system calls except exit(), sigreturn(), read() and write() to already-open file descriptors.

[http://en.wikipedia.org/wiki/Seccomp](http://en.wikipedia.org/wiki/Seccomp)

Chrome uses seccomp to sandbox rendering subprocesses and the Adobe Flash Player.

<comment><USER23> It is the seccomp type 2 mechanism, where you choose the system calls and arguments to allow, not the early seccomp type 1 that only allowed exit, read. That one would not really need to sync, as you cannot even create threads afterwards.

</comment></comment></comment><comment><USER24> This is not the first time that Chromium team doesn't care about even slightly older distros. Apart from the infamous RHEL 6 case, there is also the recent wheezy case.

Back in September, there was a plan for requiring at least GCC 4.9 for building Chromium, which made building new releases for Debian wheezy in a pure Debian wheezy environment impossible. [0]

Debian lacks the manpower of RedHat for backporting and supporting new software (which is GCC 4.9 for this case), so Stable Release Team and Security Team are not the most liberal teams when it comes to approving new packages into a stable release, and as a result, Chromium is not supported in Wheezy as of last month. [1]

[0] [https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=763278](https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=763278)

[1] [https://lists.debian.org/debian-security- announce/2015/msg00...](https://lists.debian.org/debian-security- announce/2015/msg00031.html)

</comment><comment><USER8> Wow that's extreme. They could broadcast seccomp across thread for older kernels.

One day it's going to be "use Google's fork of the kernel".

Of course, Firefox and others work fine on "older" kernels.

<comment><USER23> It is a sandbox, you cant trust the threads to apply it I guess, if they have been hacked.

I dont understand why you need to change the seccomp filter after creation though.

</comment></comment><comment><USER25> These long term support distros are toxic to everyone except proprietary software vendors.

<comment><USER26> You are surely joking and you're not good at it.

<comment><USER25> Do you trust package maintainers at Redhat/Debian/etc to properly backport security fixes to ancient branches? They don't exactly have a clean track record.

Look at the terribly old / EOL software in RHEL4 that is on "extended support" until 2017:

      Java 1.4
      SVN 1.1
      Apache 2.0
      Stunnel 4.0.5
      Python 2.3
      Glibc 2.3.4
      Firefox 1.0

edit: I stumbled upon some ELSA advisories a few weeks ago where additional security updates needed to be released for Apache because the CVE for which they intended to backport a fix was not adequately patched.

That is terrifying. There's a reason why upstream doesn't release fixes for those old releases.

</comment></comment></comment><comment><USER27> The answer seems to be "yes", as Jessie has a 3.16 kernel.

Lots of speculation though - there's no official announcement, as far as I'm aware, and the OP on the mailing list did not identify as a Google employee.

<comment><USER20> I believe this seccomp-tsync feature was introduced in 3.17. I can't find the exact commit but I'm looking.

Edit: [https://lkml.org/lkml/2014/7/18/718](https://lkml.org/lkml/2014/7/18/718)

</comment></comment><comment><USER28> Most people update the kernel when their distro does. Ubuntu 12.04 LTS is currently at a .5 version with kernel 3.13. There seem to be no plans for a 12.04.6 with a newer kernel but we'll see.

Maybe TSYNC can be backported to 3.13 (I'm unsure about who has to do it) or Chromium can be compiled without TSYNC (distro's choice). If nothing happens this is going to cost Google some users but obviously it's their browser and their choice of how to implement it and where it can run.

<comment><USER29> Ubuntu already backported TSYNC months ago.

<comment><USER28> Great. I didn't know (actually I didn't know about TSYNC until today). Thank you.

</comment></comment></comment><comment><USER30> So, is this a feature that will also appear in Chrome for Android? Is there even an overlap in codebase? [I honestly have no idea]

Given that a lot of handsets run ridiculously old Kernels, I assume that this feature will not be usable for the next few generations of handsets (or will have to be backported, obviously).

</comment><comment><USER31> Some browsers have different goals. Is that a problem?

<comment><USER32> It's supremely arrogant to tell your users to change the kernel they are using because you couldn't be bothered to fix a regression in your code. The problem with that approach is self-evident.

<comment><USER23> Well I guess their argument is they cannot provide secure sandboxing without this feature, and they do not want to ship it with weaker security.

</comment></comment></comment><comment><USER33> Perhaps it is a good things. Many kernel devs aparently don't like the method of back porting fixes for ages the way Debian does. They say the Arch way is fine and one should not be too afraid to upgrade in between. Perhaps Debian could start trying this? In other words, is the Debian stable method still needed in this day and age? Perhaps a good start for a discussion.

<comment><USER34> Debian has had the "Arch way" before Arch, it's called Unstable :) Personally, I like running that on my laptop and Stable on my server, since I like being able to fix security issues without suddenly having some component replaced or new functionality introduced that breaks the system and requires my intervention. Add unattended-upgrades, and I can essentially leave it running alone for months, if not years.

</comment></comment><comment><USER35> "Most" chromiumOS developers use 14.04 LTS [1]... Which is 3.13.

[1]: [http://www.chromium.org/chromium-os/developer- guide](http://www.chromium.org/chromium-os/developer-guide)

Kinda surprising... but not really.

</comment><comment><USER36> so what's going to happen with chromium in debian?

</comment><comment><USER37> The FUCK does a browser want with the version of my kernel?

<comment><USER38> A security (sandboxing) extension.

</comment></comment><comment><USER39> Google never gave a single fuck about older distros. It took a few days after Debian 7 going stable that they stopped supporting Debian 6 (by requiring newer libc).</comment>


Another Video Of Google's Automated Toyota Prius (On Its Campus) Arrives - <AUTHOR> http://techcrunch.com/2010/10/13/google-car-campus/ <comment><USER2> So, if anyone reading this has a Prius and lives in SF, just bolt a metal bracket and a food blender to the roof and people will take videos of you as well!

</comment><comment><USER3> There is clearly someone in the driver's seat with their hands on the wheel. This one may not have been automated at all but collecting data.</comment>


Don't Get It Wrong: 5 Tips For A Perfect Workation - <AUTHOR> http://franzisk.us/2013/03/30/dont-get-it-wrong-5-tips-for-a-perfect-workation/

<comment><USER2> wow 1.) sounds scary! never would have thought of that! thx for sharing</comment>


Windows dips below 50% of web traffic to US govt websites - <AUTHOR> https://analytics.usa.gov/ <comment><USER2> I am visiting elderly relatives this week, so I get my anecdotal updates. The Windows machine was under a towel (for dust) which basically means it isn't being used anymore. The story: after clicking no every time, his Windows 7 machine auto-upgraded to Windows 10. He has figured out how load Internet Explorer to find his links, but is baffled by the rest of Windows. So he went out and upgraded his phone to a new Samsung smartphone and uses it for all of his email and web searches. He still needs a bigger device and is planning to buy an Android tablet because he thinks it will be similar to his phone and easier than figuring out Windows 10. He also wanted to know if he can still get viruses on Windows 10, which is his other reason to switch to Android. I showed him how he can use voice to interact with his device because his eyesight keeps him from using his devices for long periods of time. Saying "Ok Google" is really un-intuitive, he actually wrote it down. Also, he found new games to replace the ones he played on Windows.

So this Windows 10 auto-update could very well be pushing people to abandon their desktop/laptop altogether if they don't have a use case forcing them to keep Windows.

<comment><USER3> Similar story here, but with iPad (good accessibility for old people eye sight). Only Apple iCloud is still baffling (my cloud storage is full? I think I forgot my password?), but many things like TouchID make it easy to use and the simplicity of the system is unkaputtbar/secure compared to a "real" computer.

<comment><USER4> iCloud storage is baffling to me too, and I work in tech!

<comment><USER5> I just don't use it for iCloud backups. Plug my iDevices to iTunes for local backup once a month and it's all peace.

</comment></comment></comment></comment><comment><USER6> Wow, these are really good stats. I wish my government had something like this.

Was this created by the United States Digital Service[0]? I've heard great things about them.

[0] [https://en.wikipedia.org/wiki/United_States_Digital_Service](https://en.wikipedia.org/wiki/United_States_Digital_Service)

<comment><USER7> Close. It's 18F Digital Services Delivery. The website says the code is on github [1]

[1] [https://github.com/18F/analytics.usa.gov](https://github.com/18F/analytics.usa.gov)

<comment><USER8> It's both. 18F hosts the code and led the development, but there were major contributions from USDS (such as the visual design). And the program itself is owned and directed by the Digital Analytics Program, another team in the GSA. It was a team effort.

</comment></comment></comment><comment><USER9> Mobile keep growing which is the result of the dip in traffic from windows. As a desktop, windows still strong.

<comment><USER10> Unless you can show absolute numbers, you can't call it a "dip".

Like many in various industries there has been a huge push to support mobile, and thus the effect the larger % of the population who use mobiles vs pc's comes into effect

<comment><USER11> Why is that? He's just pointing out that the dwindling numbers are not necessarily because of a desktop market share decline but because of the growth of mobile. We're seeing this everywhere.

<comment><USER12> The point is, as a _share_ the numbers are dwindling, but we can't tell from the share numbers whether the _absolute numbers_ are dwindling, stagnant, or still growing (albeit slower than mobile growth).

</comment></comment></comment></comment><comment><USER13> Interesting that Windows 7 is still twice as common as Windows 10.

<comment><USER14> Don't know about the US government specifically however it's not uncommon for the government to be the biggest single user of it's websites, followed usually by business/corporate users. If this is the case in the US also then a lot of business users have not upgraded to Windows 10 yet.

<comment><USER15> The US Postal Services' websites are by far the most visited.

Followed by things like the Weather services and then things related to health or social security.

Those are "costumer"-oriented sites. But then again, some of them could be browsing from their work computers.

<comment><USER14> That doesn't necessarily mean much, every time I went to the post office here in the UK and asked for something specific they went on their website and printed a page for me (not the most efficient use of resources but hey it works), there's also the case of terminals at public government offices where the public can go to use online resources (home office, and job center are a good example of that), this could be not that different from 30% of the site hits for HSBC in the UK which are from within the internet banking terminals in the branches.

But as tdlowden said apparently only 4% actually comes from US government networks so I guess it's not the case, tho I don't know if it's only federal or also local government since the US has a very tiered form of government.

</comment></comment></comment></comment><comment><USER16> Kinda funny how the NASA & NSF sites see a lot of Linux usage (because their visitors are geekier) but less Android usage (because they are more upper- class, and Apple devices are a status signal).

<comment><USER17> Are Apple devices really seen as a status device?

Maybe I don't see it because I don't need validation.

<comment><USER16> > Are Apple devices really seen as a status device?

By the sort of person who'd rather pay extra for a Mac than just use Linux, sure. I remember seeing an acquaintance wax eloquent to another acquaintance about how perfectly designed the iPhone is (it's not: it's a plain black box) — it was really just a way of showing to his acquaintance how wise and clever he is to appreciate the emperor's new clothes.

> Maybe I don't see it because I don't need validation.

Me neither, which is why I haven't bought an Apple computer in this millennium.

<comment><USER18> In fairness, I have 2 phones. My personal phone is an Android, because I'm cheap. My work phone is an iPhone, and it has MUCH better battery life.

Most features might be quite similar, but as far as I know, using [Objective] C on custom hardware is more efficient than pseudo-Java, resulting in less battery usage, and better audio latency for stuff like Garbage Band on my iPad.

... At least until the Android JIT catches up. When that happens, Android code might well become better/faster, due to there being less of it to glean the intent from. But we're not there, yet. And I'm definitely on a tangent now :-)

(and, I have all 3 major OSs on various home computers)

</comment></comment></comment></comment><comment><USER19> Wow, that's a US government page. Good job!

</comment><comment><USER20> No wonder, given the post-PC era began a few years ago, shifting the focus to portable devices. Although I believe we're entering a post-post-PC era, w/ IoT and VR/AR on the horizon (both of which consume orders of magnitude more internet than ordinary mobile phones.)

</comment><comment><USER21> Confirmed: Russian hackers use Linux.

</comment><comment><USER22> I think Windows has become obsolete. For most people it's now something you choose to install in increasingly annoying update windows vs automatically installed on new PCs that used to sell like hotcakes. Everyone was automatically opted out of Windows 10 as they kept using old computers with no compelling reasons to buy a new PC again (probably 'ever' for most people). Phones usurped a lot of tasks that are more convenient that way and that will only continue.

I think Google will do some damage to Windows next year through Surface clones and Chromebooks. Chrome OS is getting pretty competent with support rolling out for the full Play Store... and through that people have already installed the Windows version of Steam and playable games. The full desktop browser is also very empowering. Overall it's becoming directly equivalent at all the good stuff, it's even Linux under the hood and can co-install full Ubuntu. What it leaves behind allows for mindless security, no upkeep, and performance.

Apple like to think their iPad Pro is the next generation of PCs too -

[http://www.macrumors.com/2016/08/01/apple-new-ipad-pro- compu...](http://www.macrumors.com/2016/08/01/apple-new-ipad-pro-computer- replacement-ad/)

<comment> nommm-nommm I'm not sure there's a single task that I've found more convenient to do on a phone than a desktop.

<comment><USER23> Taking photos :)

But seriously, the small screen and accelerometers viabilize different kinds of interactions. Some games manage to be fun on mobile, while they would obviously be very dull on desktops. I would not be surprised if there were serious applications exploiting those features too.

And there is the "taking photos" category, where I was only half joking. There's a set of tasks that the desktop can't even handle.

<comment><USER24> My 8 inch Windows tablet which is not much larger than many phablets and runs a full desktop OS works better and gives me way more control.

Tell me, what category of tasks could it not handle?</comment></comment></comment></comment>


Rubber duck debugging chat and search engine - <AUTHOR> I just created website where you may ask any question that you googled but haven't found at first page.
I will post your questions at stackoverflow, quora, etc if I can't find it inside search engines. I can look for complicated requests like parsing websites data and returning you results as json or GraphQL API. I have access to Builtwith data and list of 400 mln domains. So I can look for code inside html/js of websites. I can try to be your assistant for Rubber duck debugging. If you are interested to help me answer questions I will add you as a manager to chat app. I will try to answer any question you give and find results for you. It may take up to 1 week to answer some complicated question. So it will ask you for email. In future it will have it's own cryptocurrency with platform like mturk. Currency will be digged and distributed similar to clam. http://fehu.live At first I just want to be helpful as much as possible and attract as much attention. Than I will automate most requested features. And build platform like mturk to automate tasks that hard for machine. At this moment it's just chat with me. One person. I want to figure out how much traffic and workload I can handle chatting. I am not perfect. I am excited with future of conversational marketing. At this moment this idea may seem bizzare. But in 10 years AI will get much better. So I want to get attention and user base as early as possible.
http://fehu.live/about.html <comment><USER2> The url you posted above returns a 404. It looks like http:fehu.live works.</comment>


It's 3.0 Or Die For New iPhone Apps - <AUTHOR> http://www.techcrunch.com/2009/05/07/its-30-or-die-for-new-iphone-apps/ <comment><USER2> As this was mailed to developers, anyone who cares should already know. Also, why the sensational title? No serious rewrites are required to support 3.0.

<comment><USER3> _Also, why the sensational title?_

It's a TechCrunch article ;)

</comment></comment><comment><USER4> It is actually 3.0 or die for all iPhone Apps. (Those that fail 3.0 testing will be removed from the store).

I really hate the timing here. I was planning to submit a new app yesterday, but it got pushed to today. And now this. Though the 3.0 support looks fine so far.

<comment><USER5> Ha - I updated my SDK + iPhone last night - got everything ready to submit my app through iTunes connect and then got shut down (I assume they were setting up the 3.0 stuff).

That kind of sucked...</comment></comment>


The head of Bloomberg's $150M VC fund explains formula for finding an AI startup - <AUTHOR> http://www.businessinsider.com/bloomberg-beta-head-roy-bahat-on-the-formula-for-ai-2016-8 <comment><USER2> This is yet another clickbait-y title that overpromises and underdelivers. Little value, no specificity, and hardly any real description of a "formula" whatsoever. Here, though, is a tl;dr summary for one of the only concrete pieces of the "formula" actually described:

Bloomberg's early-stage VC fund will only invest in Series A or earlier companies. Then when looking at AI companies they ask two questions: "1) Do you have access to your own user? 2) Do you have access to a data set that's yours? If they have both those things, then they can create a virtuous cycle where the user contributes the data, the data gets better, and it makes for a better user experience."

Asking about access and usage rights to data and means of applying learnings from the data is a very obvious qualifier, so there is little valuable insight here.

<comment><USER3> Many AI startups don't have (1) because they provide a service to someone else who has the relationship with the user. For example, startups that provide APIs for image classification, e-commerce fraud risk estimation, ad targeting, or product recommendation. I believe there will be big winners in the API space too, but they'll look different from consumer-facing companies.

<comment><USER4> It's hard to become extremely successful (I'm talking Google/Facebook scale) if you don't have access to your users. It's much easier to build a consumer product that provides an experience 10 times better than what's on the market, than building a technology that is 10 times better than what's on the market. And even when you do come up with something like that, unless you actually capture your own customer (which brings us back to "having access to your users"), others will end up copying you or commoditize you.

</comment></comment></comment><comment><USER5> Summary: _" Bloomberg Beta tends to ask two questions of its potential investments: 1) Do you have access to your own user? 2) Do you have access to a data set that's yours?"_

Business today: can you cut off their air supply, or can they cut off your air supply?

<comment><USER6> I am pretty sure that is the way business has always been. JD Rockefeller didn't get rich playing nice.

</comment></comment><comment><USER7> Disappointed that the answer isn't "We use AI to do it."

</comment><comment><USER8> Just feed the data into an ML algorithm.

</comment><comment><USER9> > and cofounder and chairman of gaming console OUYA

I can't imagine why this would be a good thing to draw attention to.

OUYA's execution was bad enough that it went out of business.

<comment><USER10> Are you looking for white-washing or journalism?

</comment></comment><comment><USER11> As someone that has seen AI come and go through multiple "AI winters", I'm amused to see it coming back around. Of course, it's totally gonna work this time!

Actually, I believe we really are on the cusp of a very different world of software, due to AI. But, it's been a long time coming, and a lot of great minds have kinda gotten lost in the academic pursuit of AI.

</comment><comment><USER12> _" A number of executives at Bloomberg realized technology was being developed in the startup world they were only seeing once it was mature enough to be ready for Bloomberg, but that was often too late to be able to fully understand it."_

That's a peculiar way to think about new technology, to say the least. "Too late to fully understand it", really?

<comment><USER13> They probably mean they could have used the tech early on to gain an advantage over their competitors. But if they waited till it matured then they are no different than anyone else.

</comment></comment><comment><USER6> Having unique data is incredibly important if you are going to build a business around better data analysis. You can live without direct access to end customers, but without access to unique data you are just playing the game of my people are smarter than your people.

</comment><comment><USER14> Believing that only AI startups that will make it big are ones that don't own the data or end user seems like an obviously flawed filter; for example, imagine if someone demand AirBNB or Uber owned the property they ultimately profited from.

<comment><USER15> AirBNB or Uber both have access to their user and have a proprietary data set.</comment></comment>


The Mumps Programming Language - <AUTHOR> http://www.cs.uni.edu/~okane/ <comment><USER2> There is a company called MediTech in Massachusetts that uses a derivative language of MUMPS called Magic. I know several programmers that have worked there. There are thousands of engineers writing in this language as we speak.

From what I can remember:

-Only global variables

-Variables must only be capital letters, maximum length 6. If you run out of variables, you must cleverly use them in a routine and set them back to what they are. This means you can't use a name like myVar - you use AAAFD, ZBVCXZ, etc.

-System functions are usually things like ., >, ', ], so code looks like .'AAAF]{\;:..

-Meditech writes all of their own languages, databases, operating systems, tools, etc. You can only write in a non-Meditech language if you get approval from a multi-tiered architectural design board, which barely ever happens

-The founder hated C with undying passion. No one is ever allowed to use C

-All programming hires go through a 6 to 12 month training process to learn the tools, languages, and systems. As they almost exclusively hire non-CS majors, such as math and physics majors, they don't typically have a programming background and don't realize how bizarre the MediTech stack is

Because MediTech engineers get experience in a proprietary suite of technologies that is only used there, it is extremely difficult for them to get new jobs at the same pay grade and experience level. 5 years at MediTech is worth 0 years anywhere else. However, I have hired a few of these people, and while they knew nothing about say Python, JS, Linux, etc. when hired, their deep understanding of how computers work made them very skilled once they picked up the modern technologies. Not many engineers program for years in low-level nightmare languages before touching JavaScript or Python, most start high-level and go lower. The foundation provided by working in a language like Magic makes them know computers at a deeper level than most.

<comment><USER3> I interviewed at MediTech while I was in college. During the interview I pointed out the issue of how working on proprietary technologies would have an impact on my career. This along with the fact that the compensation they were offering was significantly less than what I was offered as an intern at Goldman Sachs and another company no one would know.

I swear it was something insane like 36k a year in 2005. compared to 55k for GS . I asked them if it came with something to offset that like a pension or housing and they looked at me like I was crazy. I asked them to explain what they had to offer me and they made some stuff up about it being a great job with advancement potential. I think the word loyalty may have come up.

I didn't get an offer not that I would have said yes.

The lobby was nice as I recall. Lot's of open space, granite, and flowing water. Maybe that makes it worthwhile? Oh and you have to wear dress clothes. On 36k a year.

<comment><USER4> Is 36k that insane? That's the average starting salary of French engineers and some PhD-level researchers from relatively well-ranked universities. 1/3 of which are compulsory taxes (not including income tax), so in the end it's about 25k of net disposable income per year.

<comment><USER5> It is insane. I started at the bottom of recession 2009 at a university for 46k.

I'm sure it depends on geography and living cost but 36k is very low imo for a private company.

Public companies such as public university, government, and such still pay a bit above that on top of good compensations (healthcare, vacations, etc...).

This is USA of course.

France in general could be different in term of tax, healthcare, etc...

</comment></comment></comment></comment><comment><USER6> Unpopular opinion: I actually really like working in MUMPS, which is now just called M. I develop in M every day.

There are modern ANSI standards for the language, and several private vendors and open source implementations.

There are 2 things I like about M:

1\. It has limited commands and is whitespace-aware \- Newer developers can jump right into M, precisely because it lacks higher-level abstractions like first-class functions or closures. It's easy to memorize the standard library and easy to read code (because it's whitespace sensitive like Python).

2\. The NoSQL database built right into the code \- You access the built-in, persistent database the same way you access regular data structures. When setting values into an array you do something like "set foo(bar)=1". In order to persist that same data to disk, you just do set ^foo(bar)=1. This means less worrying about query languages and ORMs.

The database is a sparse B-tree structure so it's wicked fast at reads and writes. Great for a fast key-value store. There are people using M's battle- hardened NoSQL database with Node.js drivers, and you're very unlikely to find a bug because it's been in production so long. This makes it good for mission- critical applications like healthcare and finance.

Check out Rob Tweed's work with M: [https://robtweed.wordpress.com/2012/10/24/i-have-seen-the- fu...](https://robtweed.wordpress.com/2012/10/24/i-have-seen-the-future-and- its-node-js-shaped/)

<comment><USER7> > Unpopular opinion: I actually really like working in MUMPS, which is now > just called M. I develop in M every day.

I know people that love working in COBOL. For the most part that is because it is what they know. Do you have extensive experience with other platforms/languages? How do you rate them side-by-side?

> and you're very unlikely to find a bug because it's been in production so > long.

This goes for anything that's old. But that does not equate to 'good', it's just old. Just like new isn't necessarily better old isn't either.

And there are usually plenty of bugs in those codebases, just not in the runtime. But the user supplied code usually pre-dates any kind of automated (or even at all) testing other than 'try stuff and see if it produces the right results'.

The MUMPS codebase I worked on in the 80's was so fragile that deleting a single global string could cause the whole system to break down in ways that required a restore from backups. Don't ask me how I know that ;)

<comment><USER8> I'll second that unpopular opinion and claim I have experience with many other languages that I also enjoy.

The fun part about Mumps is that it's basically Lisp's ugly sibling, without meaningful scoping rules. You can easily do lots of terrible things in Mumps, but those things are usually more straightforward than the terrible things you do in other languages. You can also do elegant things, though a little less straightforwardly.

My single biggest complaint about Mumps codebases is that they're usually old, which means they have shitty documentation. Not that new ones are necessarily any better, but at least there's a chance new things are written in Orgmode or something :)

<comment><USER7> I've yet to see a MUMPS code base that would qualify as 'elegant', do you have any pointers?

I'd love to see how it should be done, the only things I've seen are examples of how things (any things!) really should not be done.

<comment><AUTHOR> [https://github.com/robtweed/EWD/tree/master/m_apache](https://github.com/robtweed/EWD/tree/master/m_apache)

<comment><USER9> This mess makes perl look readable

Thanks for proving without a doubt that Mumps belongs in the trash can

<comment><USER7> You probably won't believe it but this is actually very clean MUMPS code. If that's the shining example then you now have a bit of a glimpse of what the bad stuff looks like.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I used to work at Epic, where this language is used to implement much of the leading healthcare system in the United States. Many people there encouraged me to refer to it by different names like "M," "InterSystems Caché," "Caché," or even to my surprise "C."

I'm very, very happy to not be using this language anymore. After my first year on the job, I read some JavaScript code, and I nearly wept at how comparatively beautiful it was.

<comment><USER11> Why did they encourage you to refer to it by different names? In what context?

<comment><USER12> "Mumps" is a pretty awful name to use for the purposes of healthcare software. You might as well call your database system "Cancer".

</comment></comment></comment><comment><USER7> Mumps is everything a programming language should aspire _not_ to be. It's worse than RPG, worse than MAPPER, worse than MIMER and all of those put together.

If a job description contains the word 'Mumps' and it is not in a sentence about your medical history: run like hell unless you are starving.

Source: was a Mumps programmer long long ago in a short stint at a bank that fortunately got bought out by another bank which had saner ideas about automation.

</comment><comment><USER13> Obscure Mumps trivia: in the 80s, it was fashionable for the Brazilian Judiciary to build systems in M. (I have no idea why). Many courthouses and tribunals in Brazil are backed by large Mumps-based systems, not just for courthouse stuff but also HR and other purposes.

I worked as a civil servant in such a tribunal. Mumps was the first programming language I used professionally - in 2009! I wrote M for a living for around a year. It's still being heavily used in the place I worked at. My colleagues, who were more senior than I by a few decades, had written hundreds of thousands (millions?) of LOC in Mumps and developed a rich ecosystem of internal tools and libraries for it. It was a bit scary to do maintenance work on code that was written in the 80s, but I could often look at the author's signature and find out he was sitting right beside me - still pumping out Mumps. :-)

I can't say I loved the language, but it has some interesting concepts and reading about it makes me feel nostalgic.

Something weird about Mumps that I didn't see others mentioning here is how common it is for M programmers to abbreviate commands. Every command in Mumps can be abbreviated; "w" for "write", "i" for "if"; "s" for "set" and so on. This causes code to be extremely terse, and hard to understand for a beginner. A very simple example:

> I ($G(^ATM(1000))+$G(^ATM(500))+$G(^ATM(100)))<=0 D

> . W #,!,"There is no money available in this Machine. Sorry for the > inconvenience."

> . Q

It gets way more complicated than that. After reading this kind of code for a few months, you get really good at parsing it.

<comment><USER14> >>It gets way more complicated than that. After reading this kind of code for a few months, you get really good at parsing it.

This must be how APL language users feel parsing their ultra-terse syntaxes (includes J/K/Q variants). Seems most applicable to quant shops that still use kdb+.

</comment></comment><comment><USER15> This page mentions the EHR used by the U.S. Department of Veterans Affairs, known as VistA[0], developed using MUMPS.

Interestingly, the source code for VistA has been obtained via FOIA requests and so the code is available in the public domain[1]. There are now forks of VistA, like OpenVista.

At one point we had to argue with Github to support syntax highlighting for M/MUMPS: [https://github.com/github/linguist/pull/148](https://github.com/github/linguist/pull/148)

[0] [https://en.wikipedia.org/wiki/VistA](https://en.wikipedia.org/wiki/VistA) [1] [https://en.wikipedia.org/wiki/VistA#Usage_in_non- governmenta...](https://en.wikipedia.org/wiki/VistA#Usage_in_non- governmental_hospitals)

<comment><USER16> There's a docker image floating around somewhere out there that gets a VistA install up and running.

<comment><USER17> Has anyone tried this? Played with this? Is this a viable EMR system for an org that doesn't have a lot of money? Like for support either?

</comment></comment></comment><comment><USER18> I worked at a company that used Mumps. They used some super-old interpreter that had a pretty low limit on the code size.

The actual size of the source code.

As the codebase grew, they had to shrink down the code to be able to fit it all in. Comments were the first to go. The end result was single letter variable and function names. The code was impenetrable!

Presumably this is no longer a limitation :)

<comment><USER19> Reminds me of how V8 used the length of a function's source code as a heuristic to decide if it should be inlined or not -> adding comments could slow down your JS. But of course JS already had code minifiers.

</comment></comment><comment><USER20> I took a look at the "Code examples from the book". I haven't, ever, seen a nightmare like this.

Just one snippet from the User's Guide:

      If you use a goto command, all do command pending returns
      are canceled. That is if you invoke a section of code by
      means of a do and the section of code executes a goto
      command, the return to the line the do was on is canceled
      as well as any other pending returns.

Even BASIC does better than that.

<comment><USER7> That's because they drop the stack.

Yes, basic did better than that _but_ you can actually 'goto' into some line in another subroutine in BASIC which can cause all kinds of interesting results (usually not the ones you intended though).

<comment><USER21> You can do the same with longjmp in C. You jump onto an empty stack, so you only have global variables to work with. It's fascinating, but not recommended :)

</comment></comment></comment><comment><USER22> [http://thedailywtf.com/articles/A_Case_of_the_MUMPS](http://thedailywtf.com/articles/A_Case_of_the_MUMPS)

<comment><USER23> beat me to it...

[http://thedailywtf.com/articles/MUMPS- Madness](http://thedailywtf.com/articles/MUMPS-Madness)

[http://thedailywtf.com/articles/Revenge-of-MUMPS- Madness](http://thedailywtf.com/articles/Revenge-of-MUMPS-Madness)!

<comment><USER24> I, too, have googled MUMPS.

<comment><USER23> I read the DailyWTF article on MUMPS when it was originally posted, so that prompted me to go look for it.

<comment><USER24> My comment was aimed more at tsomctl and moomin than at you, to be honest. Say "MUMPS" and people will fall over themselves to cite The Daily WTF, as if it were all there was to be said on the matter.

<comment><USER22> I, too, read the Daily WTF when that article first came out (in middle school! Time flies.) Although, to be honest, it was a lot funnier then than it is now.

</comment></comment></comment></comment></comment></comment><comment><USER25> Ex-Epic developer here.

MUMPS is older than SQL, so preSQL might be more appropriate than NoSQL.

There were moments of joy programming M, and the performance, scalability, and HA aspects of the Intersystems implementation don't hurt Epic one bit in the sales process.

At Epic, there are so many abstractions away from M that you might start to think you're working in another language. You never set globals in production code, instead using Epic's homegrown ORM to define schemas for your data.

At the end of the day, lack of first order functions and any other data structure other than the B-tree array makes for fun problem solving, but not necessarily clean and concise code.

<comment><USER26> It's funny, this is the first I've heard of Chronicles being called an ORM. I wouldn't really hesitate to call it a full database itself, written in M. But now that I think about it, I think you're quite on point there.

(You're telling me though you never came across "end-user" API-level code that was directly digging around in ^ER, ^ER1? Hahah)

<comment><USER25> Yeah smart people work at Epic, and smart people with ties to the midwest end up staying longer than 5-6 years. Epic does get a lot of things right, especially the code review process. If someone saw a reference to ^ER in code being committed, you can bet that it would get changed. The linter (HXPARSE) would actually prevent you from moving code with certain global references.

</comment></comment></comment><comment><USER27> One fun fact: MUMPS had an early "NoSQL" precursor key-value storage engine (the "M" database), that could be directly accessed as if it were a global variable.

"The M database is a key-value database engine optimized for high-throughput transaction processing. As such it is in the class of "schema-less", "schema- free," or NoSQL databases. Internally, M stores data in multidimensional hierarchical sparse arrays (also known as key-value nodes, sub-trees, or associative memory). Each array may have up to 32 subscripts, or dimensions. A scalar can be thought of as an array element with zero subscripts. Nodes with varying numbers of subscripts (including one node with no subscripts) can freely co-exist in the same array." [1]

I had to work with MUMPS once in the past when I was working in the green- screen world in healthcare. I also had to work with Pick/D3 and Basic. It was kind of nice to start there, then move to relational databases, and then see the world get excited again in older models of databases with the NoSQL movement (albeit, much more scalable and distributed).

[1] [https://en.wikipedia.org/wiki/MUMPS](https://en.wikipedia.org/wiki/MUMPS)

<comment><USER10> Yeah, MUMPS was pretty prescient in this way. As someone who's experienced the changes first-hand, what do you feel are the most important NoSQL developments since MUMPS?

Do you have a preference on NoSQL vs relational databases?

<comment><USER27> Well, this is my opinion.

The latest generation of NoSQL databases really tried to add to the distributed / scalability story of databases, as well as provide simpler "input", "output" and "storage mechanisms". This, often at the cost of a degree of ease of use of query languages to be able to easily analyze data.

As NoSQL movement started to come into focus, folks saw that the then dominant traditional relational / ACID model was not scaling to internet scale (too many JOINs, too hard to do ACID at that size or not needed, etc.). In reaction to "internet scale", the search turned to finding new or innovative alternatives to the relational model (which really, just represented what was the state of the art at the time). This is how we got BASE instead of ACID, and went back to key-value.. or document-oriented.. or graph-based... or Hadoop/Map-Reduce, etc. People exploring lots of alternatives.

I think people mentally "threw relational databases out" for a while as quickly as they threw out the other alternatives (the precursors to relational databases), when relational databases came along. Many have found it hard to live without relational databases.

I think modern NoSQL databases try to maximize on input/output/storage and distribution / MPP of data. By now, they give some more expressiveness for query (like MongoDB, Cassandra, Hive/Impala in the Hadoop world), although SQL still beats them in my opinion for ease of use. SQL also could have advanced as the query interface for those systems too, and if you look at the SQL:2011 standard, you'll see that it included methods for querying things that are distinctly "non-relational" (multivalue fields, etc.).

NoSQL databases also more cleanly map to object models, the dominant programming paradigm (although who knows, maybe one day that too shall change).

No, I don't have a preference of NoSQL vs relational databases in general. I believe they are complementary and maybe there isn't such a thing as a general purpose database for every use case. I do believe in the old saying, "try to use the right tool for the job". There are cases when a NoSQL database works superbly, and others where a relational database just feels right. For example, storing "objects" quickly works well with a NoSQL database vs. querying for a denormalized data warehouse seems to fit well into a relational database (ironically of course, since they are often denormalized and not third-normal-form 3NF).

Anyway, that's my take... but anyone else who has input should feel free to chime in.

<comment><USER28> I've been reading more on datalog, it seems to be a better way for data handling.

</comment></comment></comment></comment><comment><USER29> I work with M/MUMPS on a daily basis. It's no surprise that it is a primitive language, as it was developed in 1966 to run on PDP-7 computers, less powerful than a raspberry pi. But M is still very relevant today because it is the power behind many (most?) of the electronic medical health record (EHR) systems in the world: Epic, Meditech, VistA (from the VA), Allscripts (more here: [https://en.wikipedia.org/wiki/MUMPS#Current_users_of_MUMPS_a...](https://en.wikipedia.org/wiki/MUMPS#Current_users_of_MUMPS_applications)). Note that it is also extensively used in the banking industry. I have heard it said that at least 50% of people have their money run through a Mumps financial system during electronic fund transfers. Mumps is very fast and very stable, IMHO because of it's lack of bells and whistles. GT.M's version of Mumps is serious about it's moto of "Rock Solid. Lightning fast". ([https://www.osehra.org/content/fis-gtm](https://www.osehra.org/content/fis- gtm)).

The most important part about any computing system/language is the resulting application. Yes, it is nicer for programmers when they have advanced language features. But ultimately, the test of how "good" a language is should really be about how useful it is, and how widely it is used.

The wheel is very old technology and yet still very important.

<comment><USER30> lol... Last time I checked GT.M was way behind lightning fast by comparison to Intersystems' implementation

<comment><USER31> If you put the money you save on Cache licenses toward better hardware, GT.M will be faster. Cache would still be necessary only for the most demanding cases.

</comment></comment></comment><comment><USER32> MUMPS (the programming language not the disease) found a niche in the medical world where it was developed. The name is an acronym for Massachusetts General Hospital Utility Multi-Programming System where it was developed. There is an ANSI standard for the language: see [http://22.214.171.124/Demo/AnnoStd](http://188.8.131.52/Demo/AnnoStd), for example.

I worked with the MUMPS Standard Committee trying make the language better while simultaneously trying to minimize the problems moving the large base of existing code to the new Standard MUMPS. MUMPS was filled with hidden gotchas. For example, in some early versions, trailing blanks in statements were significant.

The Wikipedia MUMPS article ([https://en.wikipedia.org/wiki/MUMPS](https://en.wikipedia.org/wiki/MUMPS)) provides some insight into the language and its genesis. The inclusion of a key-value store embedded into the language was a significant innovation and helped the language to be successful.

</comment><comment><USER33> Never thought I would see a professor from my alma mater show up on the front page of HN! I could have maybe seen Dr. Wallingford ([http://www.cs.uni.edu/~wallingf/](http://www.cs.uni.edu/~wallingf/)) for his love of functional programming or Dr. McCormick ([http://www.cs.uni.edu/~mccormic/](http://www.cs.uni.edu/~mccormic/)) for contributions to ADA, but not Dr. O'Kane!

Took Database Systems from Dr. O'Kane. He was a pretty fun professor.

</comment><comment><USER34> My name has been mentioned a couple of times, so let me give my take.

Forget the Mumps language which always ends up being criticised for all manner of reasons, as witnessed here already.

Check out the database, however - it's the hidden treasure, which sadly gets overlooked and dismissed because of conflation with the Mumps language and its poisonous baggage.

You don't need the Mumps language to access the database. My work with it these days is in JavaScript/Node.js, using it purely as a multi-model NoSQL database, accessed in-process.

Check out what can be done with it here: [http://ec2.mgateway.com/ewd/ws/training.html](http://ec2.mgateway.com/ewd/ws/training.html)

In particular check out the multi-model capabilities of the database and the JavaScript-orientated abstractions that are possible - see parts 17 - 27.

Some may also find this interesting: [https://github.com/robtweed/ewd-redis- globals](https://github.com/robtweed/ewd-redis-globals)

</comment><comment><USER35> A friend of mine wrote in MUMPS, banking terminal applications. greenscreens, that kind of stuff. He hated it, but he told me then it was a job for life, he got paid well (not many people with those skills) and didn't really have a lot in the way of stress....

<comment><USER36> I used to do a lot of work in dBase & Clipper and because of that I got projects in other 'language integrated databases'(?) like DataEase, MUMPS, Cache as well as Access, Foxpro and Informix. Besides Access (I guess?) these are mostly jobs for life without stress. I still get requests and it has been 15-20 years since I touched most of those.

<comment><USER37> How many FoxPro jobs are still around?

<comment><USER36> Not sure, but many. These are usually not very well advertised in my experience as the people who still can do this are known and/or advertise themselves to wanting to do that work.

</comment></comment></comment></comment><comment><USER38> The Daily WTF has a number of MUMPS-related articles. This one is good for the basics: [http://thedailywtf.com/articles/A_Case_of_the_MUMPS](http://thedailywtf.com/articles/A_Case_of_the_MUMPS)

</comment><comment><USER39> I know at least one of the two top major EHR systems uses MUMPS (Epic Software) at its core. If your a member of Kaiser Permanente, or hundreds and hundreds of other hospitals/medical systems, you rely on it for your medical records..

</shudder>

<comment><USER40> I worked at Epic for a bit more than 2 years.

It was about 3 years too long. Yes, that math is correct.

As far as I recall, MUMPS is essentially the dedicated coding language for a b-tree based database, and the only reason to ever use it for anything is for processing huge numbers of transactions through your NoSQL database every second, forever. I guess you also might want it if none of your employees knew how to correctly normalize a relational database.

Other than the nightmarish accumulation of technical debt continually rolled over since 1979, and the ungodly high turnover of people jumping ship after realizing MUMPS was a golden ball-and-chain, it was a pretty nice place to work. But management had a culture that it needed to force down everyone's throats, and the tech stack was a real resume killer. I still get contacted by recruiters desperate for MUMPS developers, and they make me feel like someone trapped inside a house besieged by zombies. I get really quiet, and hope they don't break any windows.

It only works because they throw a huge amount of money at it, and no one has any incentive to cheap out on medical management software.

<comment><USER41> EPIC management's (at every level) embrace of M and all things old as holy and glorious was what turned me off of it most. I could somewhat understand the need to keep working with cold in an old, bad language because it was still printing money (most anything related to healthcare does). I could not understand that consideration any possibility of modernizing the codebase was completely off the table--there were no R&D teams looking at new developments in database design as possible improvements, even though the tech most in fashion at the time (NoSQL) had striking similarities to M's own database structure. All effort was spent towards squeezing every last ounce of blood from ossified technology. This persisted well outside MUMPS itself: I was in the server management division, which was a champion of AIX and HP/UX (and in the weirder corners, VMS) over Linux. When I left there were a few people warming to the idea that RedHat might be enterprise-y enough to serve as a base for running M databases, but general sentiment was that most customers would continue to use old school _nixes well into the future. Much of our time was spent painstakingly guiding rural hospital sysadmins through manual configuration of every sysctl and OS parameter needed to make Cache happy. Configuration management would have reduced this to about 3 minutes of tossing a Chef /Puppet/Salt/whatever config at a server, but was considered anathema because it was necessary to have that special human touch involved in spinning up a _nix environment--surely no automated system could understand or be trusted with the intricacies of setting ulimits to values obtained via a function utilizing, at most, three inputs and grade school arithmetic.

Since I was more in their systems department I had limited opportunity to observe their archaic superstitions about code structure, but the short introduction course to M they provided confirmed that most current and new employees were willing to accept that certain control flow tools or function structures were dangerous because they were necessarily slower than something that made sense in hand assembly programming, since there had obviously been no developments in compiler optimization since M was designed (in the good old days, before C existed).

<comment><USER40> There were no archaic superstitions about code structure. Those had to be removed, because the code had long ago grown large enough to push up against size limitations. You couldn't put comments in the code. You _had_ to use the abbreviated syntax. If you tried to make anything human-readable, it wouldn't fit.

You weren't even allowed to touch the infrastructural M code. Mostly, you worked on superficial or peripheral M code, or on the GUI in VB6. I heard rumors of a GUI modernization team, but never saw any direct evidence of it.

It was a result of the iron grip of the top management. They didn't want to yield control of the company to the people actually running it. You were expected to use your expertise to do what you were told to do, in the best way you could, while still remaining completely within your lane.

After the 6 months of training, I gave it a year to read the character of the company, and then another 6 months to soak some potentially major family health care costs with that sweet insurance plan, then spent 4 months job hunting. It was the best employer-offered health insurance plan I ever had.

But make no mistake. Companies like Epic are why health care costs in the US are huge and growing. Epic never refactors _anything_ that still works well enough to hold together with some expensive human labor. It is a technology company that runs on well-trained people instead of well-designed code and processes.

<comment><USER26> When did you work there?? I find it surprising you never saw anyone writing C# or TypeScript if it was any time recent. These days there's quite a bit of web-based UI replacing the VB6, though you might not notice if you don't look carefully enough.

<comment><USER30> If it was any more than a year ago, there were parts of the company that had barely started and web migration due to dependencies. Epic is still slow playing this to make sure they don't have some of the issues they had with the early 2015 releases

</comment></comment></comment></comment></comment></comment><comment><USER42> Many moons ago, during one summer before starting uni I had the chance to work on porting a mumps application to... Visual Basic :)

That's the summer I decided I didn't want to be a programmer.

</comment><comment><USER43> There are some cool features in M. One of the neatest is the ability to create arrays on the fly.

Ex:

      >set array("node1")="Hello"
      >set array("node1","subNode1")="Hola"
      >set array("node1","subNodeX")="Howdy"
      >set array("node2")=39481
      >set array(19849,1,1,1,3,"Godzilla",5,8)="Greetings"

All dynamically created on the fly - no need to define the array in any way ahead of time! The nodes are also automatically sorted after any addition/deletion.

Looping over the arrays is very easy too. M has a function that lets you set a variable to the next node.

Ex. (using the above example):

      >set foo=$O(array(foo)) - result: foo="node1"
      >set foo=$O(array(foo)) - result: foo="node2"
      >kill foo
      >set foo=$O(array(foo)) - result: foo="node1"
      >set bar=$O(array(foo,bar) - result: bar="subNode1"
      >set output=array(foo,bar) - result: output="Hello"
      >set bar=$O(array(food,bar) - result: bar="subNodeX"

Variables can also be created on the fly, and don't need to be defined as a type ahead of time. (Technically you don't define them ahead of time at all, if you want a new variable just set it to something!) They can be strings or numbers, and you can change their type at any time by setting them to a new value.

Pretty cool, and particularly easy for someone with no coding experience to pick up. I'd only ever use it for managing a database, though.

<comment><USER43> Oops, in the 2nd example, output will equal "Hola", not "Hello" (arr("node1","subNode1")). Also I'm pretty sure numbers are sorted before strings, so in reality on the 1st pass foo would equal 19849.

</comment></comment><comment><USER18> If you're registered with a local NHS GP in the UK, it's very likely that your medical records are stored in a Mumps system.

<comment><USER44> Is that why the software they run looks like Win 95 era GUIs and, if you listen really closely, makes the GP swear under their breaths?

<comment><USER45> I don't think so - I think that particular accolade goes to [https://www.emishealth.com](https://www.emishealth.com)

</comment></comment></comment><comment><USER46> ESA is also using mumps...: [http://www.intersystems.com/library/library- item/european-sp...](http://www.intersystems.com/library/library- item/european-space-agency-chooses-intersystems-cach-database-for-gaia- mission-to-map-milky-way/)

</comment><comment><USER47> Unix MUMPS was written by Harlan Stenn, the same guy (somewhat famous for) maintaining NTP on a shoestring.

</comment><comment><USER48> I have worked in a place where we had to use Intersystems Caché Objectscript, which is a variant of Mumps. It was terrible. For example, it was nearly impossible to use source code control. We also tried introducing a unit test framework to add some stability, but it turned out the .NET gateway we tried to use to this purpose, wasn't thread-safe, had side effects, kept state in mysterious ways. Restarting the cache' (sic) process was often the only solution after the server totally collapsed while the automatic integration tests were running. If course this was all our own fault for not understanding the product properly, as Intersystems would often reply. At the time, it was not funny. I'm glad I left.

</comment><comment><USER49> It's NoSQL, the early years. Trees with fast lookup capabilities. Useful for medical, which is basically tree-oriented. There's not much need for cross- patient access in medical records. A wide variety of data structured in different ways must be stored.

<comment><USER26> Umm, there are still plenty of "cross record" lookups--patients have standard types of encounters at the medical center, they take standard types of drugs, and have standardized billing/symptom codes. These are all references to other "tables".

</comment></comment><comment><USER50> Some MUMPS based software use the EAV model cf. [https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...](https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model)

</comment><comment><USER51> I used it about 7 years ago, it's a nice environment, fast and pragmatic. Not so sure of the proprietary offerings called Cache I think?

</comment><comment><USER52> First thing I'd do if I had to program in this would be to create some "something sane to MUMPS compiler". :D

<comment><USER31> It has been done. FIS writes in a higher level language called Profile, which is compiled into M code that can be run by GT.M. [https://en.wikipedia.org/wiki/Profile_Scripting_Language](https://en.wikipedia.org/wiki/Profile_Scripting_Language)

</comment></comment><comment><USER53> Finland will soon be blessed with a magnificient MUMPS system: [https://www.epic.com/epic/post/2118](https://www.epic.com/epic/post/2118)

</comment><comment><USER54> I took a MUMPS course at University (my professor at the time at UC Davis was one of the language maintainers IIRC; a fellow named Dick Walters.

It was baffling in spots, but the M database was kind of neat. Overall, someone else in this thread said it best "You can easily do lots of terrible things in Mumps, but those things are usually more straightforward than the terrible things you do in other languages. You can also do elegant things, though a little less straightforwardly."

</comment><comment><USER55> As an end user of a Mumps codebase, I like the speed (our interface is a VT-500 emulator over SSH to an OpenVMS machine), but the fact that there is no table-row-column database means pulling research extracts requires logging screen output to flat files, which then have to be parsed.

</comment><comment><AUTHOR> An SQL interpreter written in MUMPS:

[https://github.com/robtweed/node- mdb/blob/master/gtm/MDB.m#L...](https://github.com/robtweed/node- mdb/blob/master/gtm/MDB.m#L2456)

<comment><USER34> Correction: this is actually an emulation of Amazon Web Services' SimpleDB database. It includes an implementation of the SimpleDB SQL-like query language - it's not a full-blown SQL interpreter.

</comment></comment><comment><USER56> I worked in InterSystems M/VX (MUMPS for VAX/VMS) on a 2 year project in 1985/86\. We developed a wireless ambulance dispatch system entirely in M/VX except for PDP-11 front-end processors that did the actual communications with the UMCTs (Universal Mobile Control Terminals) in the ambulances.

It ran on a VAX 11/751 that was maxed out with 8 MB (yes, that's megabytes) of RAM and a state of the art Fujitsu Eagle 400 MB (yes, that's megabytes) 14" hard drive. The user interface was text-based forms on VT-100 terminals.

M/VX was selected because there was nothing available at the time that could look up data nearly as fast as the M/VX B-Tree database, and we had to look up a lot of map coordinates.

I wouldn't grace the data storage with a description of NoSQL - it was plain and simply a multi-rooted hierarchical database, or less fancily, a set of multidimensional disk-based associative arrays. As others have pointed out, it differed syntactically from a memory-based array only by being prefixed with a caret/circumflex (^). It certainly was damn fast (for the day).

Initially, it was so cool to be able to store something just by writing

        set ^address("US","FL","Miami","Main St",12345)=1

But the pain soon set in.

There were no such things as indexes. We had to create (and maintain) inverted arrays for that purpose.

If we got the hierarchy wrong, it was murder to reorganize it. Queries were only really possible if they fit into an existing hierarchy.

There was really no such thing as an ad-hoc query.

Hmm, maybe it _was_ kind of like NoSQL...

But the killer feature (as in, it killed us over and over) was falling foul of the hideous global variable, $test, as others have pointed out.

I don't remember clearly, but if you wrote something like

        set a=1
        set b=0
        if a=1 open 1:"input.txt",old
        else  set b=10

the value of b after this would be 0 if "input.txt" could be opened, and 10 if not. This is because open set $test to false if it fails, so the else executes, even though a=1... the horror, the horror....

Oh, oh, oh... and the result of 2+3 _5 would be 25, not 17, because there was no operator precedence. You_ had* to use parentheses.

So it was kind of amazing in some ways (because ambulance dispatch system in 8MB of RAM) but a horror show in so many others. I'm glad it was only 2 years, and I did get to write some cool VAX PASCAL to allow M/VX to interface with the FEPs.

<comment><USER57> The VA took MUMPS and created a DBMS out of it, which would allow one to define the schema and then use utilities to automatically update indices.

It is much nicer when the system remembers to do that for you.

There were gotchas in the language that required you to understand it and play ball its way. Not unlike other languages I've seen. The payback was trememdous flexibility and performance on minimal (for today) systems.

</comment></comment><comment> david-given Cheesily copied-and-pasted from 99-bottles-of-beer.net ([http://www.99-bottles-of-beer.net/language- mumps-415.html](http://www.99-bottles-of-beer.net/language-mumps-415.html)):

        Mumps is now called M or cache but it was originally called Mumps.
        See http://www.camta.net/aboutm.htm

        ; The following is a single line of code
        beer    ; Randy M. Hayman (email@example.com)
                for i=99:-1:1 w !,i," bottle",$S(i=1:"",1:"s"),
                " of beer on the wall, ",i," bottle",$S(i=1:"",1:"s"),
                " of beer.",!,"Take one down, pass it around, ",
                i-1," bottle",$S(i=2:"",1:"s")," of beer on the wall.",!

I've written compilers for GNU Make, and I've translated C into Perl, and that _still_ makes my eyes bleed... so, as far as I can tell:

Commands can be abbreviated down to a single letter, so w = WRITE. Multiple commands can be glued together with whitespace. Strings are as normal, but ' is the not operator. There is no => or <= operators; use `< or `> respectively. There is Javascript-esque dodgy implicit type conversion from strings to ints, but dodgier ("aa1"+1 is 1; "1aa"+1 is 2). Commands can be suffixed with a colon and a boolean expression and they'll be executed conditionally. $ precedes a function call. ! is the OR operator, except in a WRITE command where it prints a newline. The @ expression is the equivalent of eval(), and yes, all your local variables are in scope when it runs. $test contains the value of the conditional in the IF command most recently in scope (as distinct from conditional execution). ELSE is a statement which executes the rest of the line only if $test is 0. Putting IF and ELSE on the same line doesn't work (imaginary cookie for anyone who can guess why). An extra space is required between commands if the first command takes no arguments. Variables are global unless declare local.

I believe $S(...) is the equivalent of switch; $S(i=1:"",1:"s") contains two conditions; if i=1, then ""; otherwise if 1, "s" (1 is boolean true).

The break statement is called QUIT. The return statement is also called QUIT. The BREAK statement actually drops out to the debugger. The quit statement is actually called HALT. the sleep statement is called HANG.

If a global variable is preceded with a ^, it is persisted by name to the database; some versions have transactions. Arrays are key/value sets with many indices. The docs say that trees are common, using a syntax like ^mytree(path,to,tree,node,from,root). ...which is actually quite cool.

I am torn between admiration for people who can get useful work done in this, and horror that such a thing really exists in a non-ironic sense.

All that's from: [https://www.cs.uni.edu/~okane/source/MUMPS- MDH/MumpsTutorial...](https://www.cs.uni.edu/~okane/source/MUMPS- MDH/MumpsTutorial.pdf)

<comment><USER58> Another thing that's really weird about MUMPS is that variables are dynamically scoped. So this bit of code prints 5:

      foo() ; declare function foo
        n x ; declare variable x
        s x=1 ; set x to 1
        d bar() ; call bar
        w x ; print x
        q ; return
      bar()
        s x=5 ; set x to 5. Since x is not declared in this function's scope, it will search the symbol table of the calling function and overwrite its x
        q

I've run into so many bugs caused by something like this.

<comment> david-given That'll be because there's only a single namespace, and the NEW command simply copies the values of the named global variables onto the stack and copies them back again at the end of the function.

I'm actually kinda used to that; I grew up with BBC Basic, which behaves the same way:

         10 i = 0
         20 PROCtest1
         30 END
         40 :
         50 DEF PROCtest1
         60 LOCAL i
         70 i = 1
         80 PROCtest2
         90 ENDPROC
        100 :
        110 DEF PROCtest2
        120 PRINT i
        130 ENDPROC

        > RUN
        1

...it occurs to me that BBC Basic, at least the later versions with block IFs, is a better language than Mumps in almost every way (except the integrated database stuff)!

</comment></comment></comment><comment><USER59> I know this is not the focus of the post, but my favorite part of the website is the book he wrote. Fantasy right wing fantasy dribble in the form of "The Constitution Convention of 2022"

</comment><comment><USER60> Was there already a programming language called Polio?

</comment><comment><USER57> I started coding in MUMPS 35 years ago, and have continued doing so for most of the years since.

For my first 8 years I used a version called MIIS, which was developed by Meditech. MIIS allowed 2 KB symbol space per job and 2 KB code space. Amazingly we supported libraries, hospitals and laboratories. The hardware we used were DG Eclipse and MV minicomputers; however, it also ran on DEC PDP and IBM Series/1 machines. I remember hearing that the MV systems could hold 2 MB of RAM, but it was found that the 2nd MB didn't add much performance-wise. These systems supported dozens of printers and terminals.

Since then I have mostly used Digital Standard MUMPS (DSM) and Intersystems Cache and again this has been in support of medical information systems. These systems allowed for much larger memory partitions for each job. I coded CRUD applications, reports and interfaces (both with other computers and with automated instruments). I also developed inhouse web applications, using Cache's advanced object system and SQL interface.

MUMPS/Cache runs on everything from the Raspberry Pi to mainframes. I knew one guy who developed a multi-user accounting package that ran off of a PC-AT. I've never heard of another language that could operate in multi-user mode in such constrained conditions, except for Forth. Maybe C under Coherent? The ability to run on different architectures enabled lab info systems vendor, Sunquest, to increase their revenues by selling to clients who would only accept IBM hardware, where previously Sunquest had only sold DEC boxes. I don't believe much in the code had to be changed to facilitate the transfer to mainframes. Yet another lab systems vendor, Antrim, used Micronetics Standard MUMPS (MSM) on RS/6000 boxes. I worked on interfaces to automated lab instruments for Antrim.

While my first MUMPS implementation was from Meditech, I had a different experience from the individual who reported using Magic:

. MIIS had both global and local variables . I don't remember if variables had to be capital letters, but other versions did/do not have such a requirement . System functions were not so obtuse . Modern variations, such as Cache and maybe GT.M from FIS, allow communication with other languages

While the early versions of MUMPS did not support object-oriented code or graphical displays, they did support VT-220 style terminals and the displays were quite nice. This was in the early 80's. So while some companies produced products with roll and scroll, others supported formatted screens.

While MUMPS code looks odd to someone unacquainted with it, with a bit of use, it becomes obvious. This is nice because most of the code I've seen still uses single-character commands and 2 or 3-character function names. I really view this as a matter of experience: Haskell code looks like gibberish to me and I only understand a portion of Klong (which is patterned after K).

I had brief forays into COBOL and Fortran earlier in my career. And I determined I preferred MUMPS: It made lots of things easier and avoided some common problems in those other languages (such as moving too many spaces into a Fortran variable - which would both clear the variable and part of the program's code at the same time).

I really enjoy learning new languages and using them. I have coded a project using bash, awk, and Klong, which was a hoot for me. And they all have tricks which MUMPS does not have. Of course they are all just youngsters compared to this almost 50 year old language, too. And while it may not be the best language out there -- whatever that means -- it has powered libraries, credit unions, medical systems (including the Veteran's Administration which has one of the world's largest medical system), banks and stock brokers (TDAmeritrade). I hear even the European Space Agency is using it to map the heavens.

Perhaps most importantly to me, it has provided a means to feed and house my family and in my later years allowed me to be mobile, through working remotely (never even meeting my employer face to face). I imagine that it will continue to morph and serve the data processing needs of many as the years roll on.

Thanks for reading.

Steve

</comment><comment><USER61> unfortunate name, Mumps is a contagious viral infection

<comment><USER62> ...that can make your balls explode (so to speak) and render you sterile.

<comment><USER63> Much like the programming language.

</comment></comment></comment><comment><USER64> Professors and other high-ranking academic nerds: get your students to design your websites, cause you always fuck it up. Lol.</comment>


Early Color Television - <AUTHOR> https://www.earlytelevision.org/color_tv_cooper.html <comment><USER2> While reading this, I came across mention that Los Angeles was operating with a 50Hz AC grid in the 1940s. This was very surprising to me because 20 years after the switch (in 1948), I began to tinker with electronics, and I never encountered any legacy 50Hz appliances. Here's an interesting history of the issue: [https://gizmodo.com/before-1948-las-power-grid-was- incompati...](https://gizmodo.com/before-1948-las-power-grid-was-incompatible- with-the-r-1683629042)

<comment><USER3> _and I never encountered any legacy 50Hz appliances._

It's very unlikely that many appliances from that era would have been dependent on the mains frequency. As far as the appliance would be concerned, as long as the mains was close enough to the 'standard' voltage, pretty much any mains frequency would work normally.

About the only thing I was able to think of from that era which would have been mains-frequency dependent was electric wall-clocks.

And, as the article mentioned, turntables. Though electric turntables were fairly rare in my experience till about the early 50s, clockwork being the norm. Remember those wind-up gramophones and the brittle 78 rpm shellac records?

Both of those would have a very-high priority to be replaced as quickly as possible when the local mains frequency was altered.</comment></comment>


The most important new protocol since RSS: AirPlay - <AUTHOR> http://scobleizer.com/2011/04/13/the-most-important-new-protocol-since-rss-airplay-three-cool-new-apps-that-use-it-to-change-how-we-view-tv/ <comment><USER2> It might be a great protocol, but if it's anything like Apple's other protocols, it'll never make it out of the "reverse-engineered-but-rarely-used" box.

DAAP (<http://en.wikipedia.org/wiki/Digital_Audio_Access_Protocol>) is a reasonably good protocol for sharing music, but Apple never standardized it, just licensed it to a select number of folks. It made it into nearly every open-source media server and client, but it didn't have a lot of penetration into commercial products. Apple gradually rolled out more-and-more authentication over the protocol to prevent unauthorized clients.

If this sort of protocol is going to be "game-changing", it'll have to be open. Otherwise I don't see it making it big - it'll be stuck in a niche set of products like DAAP.

</comment><comment><USER3> My Samsung Galaxy S + one of Samsung TV nearby is playing it exactly like that by using much more user friendly protocol stack. Meet UPnP/DLNA. Moreover, right now I am watching a quaterfinal of Heineken Cup by magically streaming video to the TV over the local network. Meet UPnP/DLNA once again.

And there's more! This December I spent a week in Samsung's R&D working with their extension of UPnP that will deliver custom user interfaces for the TVs. They will be like regular javascript enabled web pages with an access to TV's media playing capabilities. No Apple, still.

So I beg you, Apple fans, try to take a broader look before shouting out loud about new killer features 'invented' by Apple.

<comment><USER4> I tried to use UPnP/DLNA to watch videos from my PC on my PS3. After having to search online how to turn it on, I STILL can't get them vids to stream in HD. Only some blocky low-res crap. Streaming MKVs did not work either.

Maybe it's better on Samsung/Samsung combos. It's a great idea, though.

<comment><USER3> At the moment I am using Minidlna to serve videos and it works like a charm, even with big resolutions. While trying to find a way to deliver stream to the TV from under Mediatomb, it was required to specify some magical header value. Also DLNA players I worked with were extremely picky about the content type you specify. I.e. sending FullHD .ts stream won't work well unless you say it's video/mpeg.

Anyhow, at the moment opensource is only starting to be curious about something other then writing code and compiling it. Too bad they are doing new stuff kind of wrong (see KDE4 and Gnome3, my two major reasons to use Fluxbox).

</comment></comment></comment><comment><USER5> If Apple had any interest in doing so, perhaps. But let's make a huge assumption and agree with Scoble that Windows doesn't matter and Apple is it, could they even produce enough devices even theoretically to make Airplay anything more than another feature Apple accessories businesses check off?

Protocols live and die off ubiquity, and I am not convinced Apple will get that outside of the shrinking dedicated mp3 player industry. And for better or worse, Apple will not let any other company put Airplay in their devices.

</comment><comment><USER6> The article is wrong. LTE is way more important -- introduced in 2004.</comment>


Show HN: Horizon, a calendar app with weather tailored to your events. - <AUTHOR> http://signup.horizonapp.me/

<comment><AUTHOR> Hey guys, I am the creator of Horizon. Horizon strives to be the most intuitive and easy to use iPhone calendar app ever made. It provides the weather at the time and location of every event in your calendar. The app is not quite ready yet, I'm estimating about 3 months until launch. You can sign up to be notified of its release by following the link, and if you refer 10 people you'll get a free copy when it comes out! If anybody is interested in beta testing, please email me at email@example.com</comment>


Shkreli's plea from prison: Free me and I'll cure Covid-19 - <AUTHOR> https://arstechnica.com/science/2020/04/shkrelis-plea-from-prison-free-me-and-ill-cure-covid-19/ <comment><USER2> No need when you have dorsy and gates on the task</comment>


Collecting clean water from air, inspired by desert life - <AUTHOR> https://news.osu.edu/collecting-clean-water-from-air-inspired-by-desert-life/ <comment><USER2> I wonder what the implications of technology like this could be on the large scale. It may have a terrific impact on the hydrological cycle.</comment>


ChangXin Emerging as China's First and Only DRAM Maker - <AUTHOR> https://www.eetimes.com/changxin-emerging-as-chinas-first-only-dram-maker <comment><AUTHOR> It's a little bit mind boggling how much Unigroup spent on DRAM. They had 5 separate memory projects in recent memory: Ziguang Group, Jihnua, Guoxin, Innotron, YMTC, and 3 fab complexes built. Fabs cost in total of $70B.

Micron was also on the purchase list for $28B. It was shut down by activist shareholders, and US govt.

7 something billions were spent on Jihnua. Jihnua got started with production just to have it shut down when UMC bailed out. Their fabs were de-facto being ran by UMC.

Guoxin — definitely went nowhere because of UMC. Also, around $5B+ sank

YMTC — dropped plans to make DRAM, now makes flash

Ziguang Group — no info in them, maybe just a new front for Jinhua

Innotron — is ChangXin after a rebranding. Does stack DRAM

Were they to simply develop everything in house, $70B would've been enough to redo the RnD 10 times over... Often a shortcut is the longest way possible.

I can also mention Sino King Technology, which was project by Ex-Elpida CEO with Unigroup which really didn't took of the ground because Sakamoto requested... 1 million buck salaries for _all_ senior engineers.</comment>