03:42 <kentonv> holy crap, Twitter acquired Smyte, they announced it and then turned off their service 30 minutes later, breaking everyone who depends on them. Caused an npm outage among other things.

03:42 <kentonv> yay cloud!

03:43 <simpson> I approve.

03:52 <kentonv> apparently many customers had multi-year contracts.

03:53 <simpson> Oh, nice. Sounds like additional fun is incoming, then.

03:54 <kentonv> like, the founders are never going to be able to found a b2b company again, probably. All they had to do was give people a month or two to transition... why would you not do that? So strange.

03:55 <kentonv> this could have been a great slide in the Sandstorm pitch deck though.

14:19 <TimMc> I've never heard fo Smyte.

16:37 <TimMc> Do you suppose they're still running the service internally, for Twitter's usage?

16:37 <TimMc> A friend fo mine raised that possibility, as an alternative to it just being an acqui-hire.

19:08 <sy> Hi

19:09 <sy> Is it possible to make an API key for Firefly III ?

19:09 <sy> I'd like to use the app

20:19 <ocdtr_web> sy: I don't think Firefly III's Sandstorm package currently supports it, but it likely would not be exceptionally hard.

20:21 <ocdtr_web> If you wanted to file an issue requesting API support in Sandstorm at https://github.com/firefly-iii/firefly-iii/ and tag me in it as well (@ocdtrekkie), I could add some helpful notes for JC5.

20:45 <ocdtr_web> kentonv: Re: Smyte and npm, I want to say npm should probably not be designed to fail spectacularly when a third party's API goes down. But being npm, I am not actually surprised even slightly.

20:46 <TimMc> heh, yes

20:48 <isd> What was smyte? now that their website is down, it's hard to figure out what they actually did.

20:48 <TimMc> Anti-abuse/trolling

20:48 <TimMc> as a service

20:49 <isd> What was the failure mode for npm?

20:49 <ocdtr_web> Couldn't submit things to npm.

20:49 <isd> That makes some level of sense.

20:50 <ocdtr_web> Or register user accounts.

20:50 <isd> Honestly, if you're leaning on a thing for security filtering, you should probably fail-closed.

20:50 <ocdtr_web> isd: Sure, but that thing should probably be under your control.

20:50 <isd> That said, it makes a strong point for the dangers of relying on SaaS.

20:51 <isd> Yeah, definitely on the same page there.

20:51 <TimMc> Seems like a weird thing to outsource.

20:51 <TimMc> I mean, for something like npm.

20:52 <isd> I'm really kinda bothered by centralized FOSS resources like packages registries/mangaers having hard dependencies on proprietary stuff.

20:52 <ocdtr_web> The thing is, after left-pad, some random third party disappearing breaking npm just sounds on-brand.

20:52 <isd> I still really enjoy: http://left-pad.io/

20:53 <isd> Though in fairness, I think the actual mechanism by which stuff broke there applies to a lot of other languages' infrastructure. I know PyPI lets maintainers just delete their stuff.

20:54 <isd> The thing that was bothersome about that to me was more "really? There's a whole package just for that?"

20:54 <isd> Ultimately when you add a dependency you're trusting the maintainers (unless you're actually going to pin the version & audit every update).

20:55 <isd> I guess the "on-brand" thing is careless relyance on shaky foundations

20:55 <ocdtr_web> tbh, npm was my first exposure to this whole dependency manager system stuff that is all the rage these days. I am unpleased with all of it, really. :P

20:55 <ocdtr_web> Like, I wrote PHP code, and now apparently "composer" is a thing. Never used it.

20:55 <isd> I kinda don't like the centralized registry approach.

20:56 <ocdtr_web> On Visual Studio, we've got NuGet, which I try to use as little as humanly possible. (I've capitulated on accepting that I shouldn't write my own SQLite adapter, but that's about it.)

20:56 <isd> It's not like PyPI or NPM is actually curated. At least the way Go's stuff works makes it really blatant when you're pulling in code from some random person on GitHub.

20:57 <isd> I've had arguments with people who thing the centralized approach is good because curation -- but most of these systems don't actually do that.

20:57 <isd> Haskell's hackage is an exception, but my impression is that's mostly at the level of "okay, this doesn't look completely insane or obviously malicious"

20:59 <isd> The one big advantage of having a centralized registry is it makes it easier for the developers of the language itself to see what people are actually doing with it.

21:00 <ocdtr_web> Yeah, there's definitely nice community aspects.

21:01 <isd> There's a paper out there just called "Let should not be generalized." the executive summary is "let-generalization makes a bunch of advanced type system features really fiddly to integrate, and nobody actually uses it. We removed support for it from the compiler and rebuilt every piece of software on hackage, and there were nearly no build failures, and the few that did happen we were able to fix ourselves trivially without prior kn

21:01 <isd> wledge of those code bases. We should just not do this."

21:01 <ocdtr_web> (It's fun talking to the Visual Basic team, they know for a fact that hundreds of thousands of developers are using Visual Basic every day, but they can actually talk to/reach about, you know, a handful of them.)

21:03 <isd> It's easy to get in this spot where you've got some really dumb thing that you'd like to remove, but you can't because someone *might* depend on it.

21:04 <ocdtr_web> Did you see the whole "Microsoft was linking common Linux command names to Windows versions in PowerShell" bit a ways back?

21:04 <ocdtr_web> Where they linked ls to dir, which meant you could type ls, and it'd work, but it only worked with dir's options.

21:06 <ocdtr_web> And they agreed that was a problem, but part of the concern was that if they fixed it so that it didn't do that, it'd break scripts administrators might've written which called "ls" instead of "dir", but using dir flags.

21:12 <isd> Yeah. That stuff can get really messy.

21:13 <isd> I actually kinda like the fact that the Haskell devs are willing to do some amount of backwards-incompatible changes.

21:13 <isd> They've been able to actually clean up some warts over the years.

21:14 <isd> They don't do it willy-nilly, but breaking backwards compatibility isn't just off the table like it is in many projects.

21:14 <isd> "Avoid success at all costs" as SPJ says -- you get too big and you stop being able to change anything.

21:15 <isd> Which given the languages roots in research would be something of a nightmare for the devs.

21:17 <isd> Having a type system/compiled language really helps with this -- many kinds of breakage can be caught statically, and you can more easily put deprecation warnings in intermediate versions.

21:25 <TimMc> ++