fault1

I mean, catering to the needs of the many rather than the few has pretty much been npm policy since left-pad-gate:

https://twitter.com/seldo/status/712417019686100992

https://blog.npmjs.org/post/141905368000/changes-to-npms-unp...

I think there is two aspects of the word "trojan", but it does not imply "remote command and control", it's often that, but more broadly it means something that is disguised as one thing, but is not.

For example, one of the first trojans was: https://en.wikipedia.org/wiki/EGABTR

> Turns out the author was the attacker, and with that confirmed, it appears that their access was restored so they could proceed with it.

I suspect this is how it played out as well. In fact, there was a lot of people on Twitter who were questioning whether the author really got suspended since he was posting to github a day or two after he posted his suspension picture.

not to mention that in the case of colors.js he actually owned less copyright than other contributors. they had actually changed more of the code.

I would say colors.js definitely can be considered malware. He in effect intentionally spinlocked a lot of packages either directly or indirectly via transitive dependencies, and also intentionally bypassed common semvar rules to maximize the damage.

whether or not those packages should have been affected is another discussion, but it appear it probably had more of an effect on other open source packages and perhaps the work of small mom and pop companies rather than huge corporations.

Define "most" people....

To me, this is like the left-pad incident and npm. There was a vocal minority who denounced npm for looking after the greater good, maintaining continuity and transferring the project to someone else.

In this case, since the author also deleted the project, the proper way to maintain continuity for the sponsors seems to transfer it to the new community of folks who are interested in maintaining the project. Sponsoring the old deleted project does nobody any good.

Personally, I don't see anything wrong with what OC did.

It's 2022, so perhaps the committee will approve features from C++17.

Now, all things considered, having used bgfx in various languages, I think the Orthodox C++ approach leads to quite clean code.

There is also other translations, for example, in pytorch/pyro: https://fehiepsi.github.io/rethinking-pyro/

I would say statistical rethinking is a great way to compare and contrast different ppl impls and languages, I've been using it with Turing, which is pretty great.

They probably did. It's because they've heard of other people getting rich off of crypto. The classic get rich quick swindle. Ponzi schemes and all sorts of other marketing schemes are also similar.

Usually orthodox c++ looks something like: https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b

this is from bgfx

Yeah, it's basically Clever Hans. You can see it with the amount of completely nonsensical output you can also randomly get from it if you deviate even a small amount form the input data distribution.

That's true, though they said "recently".

I don't think time to first plot is that bad anymore.

Time to first gradient can be bad in Zygote/Flux.

looks good!

The ecosystem in Julia is quite strong for MCMC libs because people do not have to lower something to C++ to develop such a library: https://discourse.julialang.org/t/mcmc-landscape/25654/

Of course, for users, they might prefer something like Turing, but I think the Julia tends to blur the differences between user and developer more so than in most other languages (for good or worse) since everything is in one language.

How about Dylan? :-)

I think one of the nice thing about Julia's "just ahead of time" monomorphization/devirtualization is that it allows a level of dynamism that also works on GPUs/TPUs. This post and linked paper help me understand a little bit of it: https://discourse.julialang.org/t/julia-inference-lattice-vs...

Is this level of dynamism required for conventional ML? Probably not. For physics-informed ML and probabilistic languages? Probably more likely.

Check out "An Algorithm for Passing Programming Interviews":

https://malisper.me/an-algorithm-for-passing-programming-int...

of course, it's important (for better or worse) to just grind out a representative sample until you understand most common patterns, e.g: https://seanprashad.com/leetcode-patterns/

turing, mlj, etc are quite good.

https://turing.ml/stable/

https://alan-turing-institute.github.io/MLJ.jl/dev/about_mlj...

mathematical notation would be kind of unreadable without the terse and compact symbology, imho. it makes it much easier for the mind to parse.

mathematics is partially a language (maybe one of the most universal ones), once you learn common conventions, it becomes easier.

Obviously it's no problem for human minds to learn huge numbers of symbols, just like some CJK languages with a large number of ideographs that have to be understood in context.

I do think auto-annotation, as well as other types of interactivity are great, though!

I don't get your point.

The repo, gh/npm accounts and such are just metadata and metadata of metadata, which is hosted and distributed based on the terms of service of gh/npm. The thing that matters most is what the npm project points to, since it is relied on by other packages and apps.

The only thing this guy "owns", according to the law, is the copyright for the part of the codebase he wrote. Not that it matters much since it is MIT licensed.

People are going to include the code in question mostly via transitive dependencies. Creating an app with create-react-app will lead to at least 2000+ such dependencies. That's just how the entire npm ecosystem works, and so there is certain community wide expectations not to do this sort of thing, and when it does happen, have mechanisms in place to contain the damage. I agree that people should reassess their exposure to such a ecosystem but that is besides the point.

I believe this is akin to not driving dangerously on the road. There is obviously a social contract. This what living in a society is all about. Just because someone can do something doesn't mean we can't expect otherwise.

His work benefited from the work of many other people who also released open source software. That not only includes the packages that he released, of which he had other contributors, some of which actually wrote more of the package than he did (colors.js) as well as packages that he more or less did a direct port from (faker.rb and CPAN::faker). He also benefited from the entire npm/node ecosystem.

People have every right to be pissed.

But with contributors, it's literally not his to "own", in terms of the actual work. Copyright law says roughly that you own the characters you type, unless you assign it to someone else.

The guy who actually wrote more of colors.js (by lines of code) than marak actually got npm to nuke the offending releases: https://github.com/Marak/colors.js/issues/317

right now they are reviewing a request to change the npm target to his repo

Well, at least in the United States, it's the default the other way (there are implied warranties) unless licensed otherwise. That's exactly what most open source licenses do to protect the author. That being said, I could imagine in some jurisdictions, the law limits the ability for people to disclaim such warranties. It would be an interesting case.

yeah, it's just nobody reads every package in that file.

apps generated via create-react-app have more than 2000+ transitive dependencies.

however, I think the more common case is that they set it to the latest bounded by a minor or patch version (as opposed to a major version) as defined by semvar.

at least that seems to be quite common in the npm/js world.

But let's not pretend the original maintainer did all of the work or owned all of the copyright. There were a ton of contributors to color, and some dude actually had more lines of code edited than the original maintainer: https://github.com/Marak/colors.js/commits/master

and faker.js seems to be more or less a port of a ruby library which was a port of a perl library.

Nobody stole creds off the project owner in the left-pad incident. npm chose the needs of the many rather the few in that incident: https://twitter.com/seldo/status/712417370686365697

which seems like very much akin to what they are doing now.

Did he own this code? Colors.js had plenty of other contributors, and there was no CLA involved.

github user "DABH" actually had more lines of code than marak did: https://github.com/Marak/colors.js/graphs/contributors

npm and github both have terms of service that you agree to when you choose to distribute something over those systems. npm in particular has had a long policy of unrolling malicious changes to the registry of packages ever since left-pad.

> There’s an abundance of supply of people with masters degrees in machine learning? How’s that possible? I thought this shit was supposed to be hard.

I think it's just a matter of proliferation of these types of programs, as well as a large supply of students.

Also, the average qualification of people working in ML is probably no longer a Ph.D, like it used to be. This is arguably because deep learning techniques require less involved math to understand, and are more focused on computational methods that work well.

So the field has probably saturated. When I got involved with ML for the first time (well, really, statistical signal processing) in the mid 2000s, the field was kind of dead, and very high qualified postdocs had tough time finding jobs.

Agreed. MLE in very ML-heavy companies tends to mean SWE who work on ML systems, and sometimes, that can mean as much working on stuff like infrastructure as modeling.

Hopefully you aren't equating "eigenvectors" to "complicated linear algebra question".

But I agree, a lot of MLE roles don't get asked such things.

I think the OP's guide is closer to interviews I've seen for phd programs.

I would say on average MLE roles tend to be more SWEng heavy. But some roles are as much creating infrastructure as running the tools.