Mislav Marohnić: Well, when it came from learning what really worked with the hub tool, and then choosing how much of that we wanna promote of that spirit, to eventually being GitHub CLI as an official tool, we mostly went over its feature set and decided that its fundamental design paradigm was not something that we wanted to port over. And then after that, considering inputting any of its code, it’s actually really already – it doesn’t align with that first and foremost decision, which we eventually were pretty secure in… Because if you don’t wanna preserve the spirit, a design of how a tool works, then it’s just really hard to get anything from it, especially due to the fact that being my first Go project, I let the Go packages become basically huge, to the extent where – I think there were largely just two Go packages where most of the hub implementation lied… So to cherry-pick the good parts out of that and leave out the bad parts would have been something that’s not really feasible technically, and I think it’s very bug-prone.

[35:48] Another thing is that we didn’t wanna go with the same testing approach, so now we’re copying over parts of the implementation, but we’re actually not gonna port over to Ruby Test because we wanna commit to the Go stack and the default Go tooling to make the project more approachable. With that line of thinking, it was a little bit obvious that starting from scratch would the be right decision.

I appreciate that you brought it up - it’s not an easy decision. It should never be made lightly. And I think rewrites should never be made lightly as well, because these are technologically really risky endeavors. But what made it a little bit less risky in our sense is that we were promoting kind of like a semi-official tool to another one. And even if we broke a lot of things, or didn’t port a lot of functionality over - well, we didn’t actually erode trust, because we were launching this new tool, which starts over from version 0.0.1, and who wants to follow us on our journey can, and who wants to stay safely embedded with the tool that already works for them also can.

And I felt that we couldn’t have kept the trust if we tried to make radical changes, and then mostly just disappoint people (I would say) that used hub to do a lot of automation; I also personally loved doing that. They would be the ones who were most affected then, trying to upgrade to a newer version and finding out that their scripts are broken, and that that tool that they’ve used as a reliable Swiss Army knife is not as reliable. That would be my nightmare scenario personally, and we avoided it.

Jon Calhoun: Another one that I’ve noticed along those lines… So there’s the new GitHub CLI tool that came out. And when it came out, it reminded me of the hub tool which I found – again, one of those ones where like when I was creating a lot of new repos and doing certain things like that with the team, I found myself using that tool more often. Then later - I don’t know why - I just stopped using it as much. I don’t know if it was that I wasn’t interacting with a large team as much, so I didn’t really have as much of like an issue process, and all the other stuff… I could just use Git and figure out things that way. I’m curious if there’s any others along that line.

When you guys are working with source control, what tools do you find useful? Source control, and I guess maybe project management type stuff with your team - what tools are you finding useful in that front?

Brandon Keepers: I think that just looking at GitHub’s product strategy if you will, GitHub is a tool that has become literally the hub of software development, but we’re under no impression that GitHub will be the only tool that you use. Every software team is going to bring their own chat service, or bring their own CI, or have their own internal tools that they have developed over the years that they want to use, that should work alongside GitHub.

What I get really excited about with Probot, one of the reasons has kind of been this passion of mine, this idea that this could be something that starts to glue GitHub to those other things. It doesn’t matter if you’re using Slack or HipChat, or if you’re using Travis or Circle or Jenkins… What’s the connected tissue between all of those tools? Especially as more of our tools move into the cloud, I think it’s important that those connecting pieces are open and accessible to anyone to use and to modify.

Adam Stacoviak: Yeah. I agree with that. Or even your other one, which is Better Incidents , which I think is a cool name for what might be your media hub that you’re growing. I’ve seen that you’ve got a podcast out there. Congratulations. Articles out there, it’s a destination on Fire Hydrant’s website now… I think Better Incidents is a cool name.

Jerod Santo: Well, with this tool we could – first of all, he has a built-in hub, so Docker Hub, and GitHub, and npm, and all these things…

Danya Murali: Yeah, we use a lot of government data. Before I worked at Arcadia, I used to work at the Energy Information Administration, which is the statistical hub of the Department of Energy. So it’s been a cool transition to go from the government agency that collects the data, to being a private entity that uses the data…

But one example I can give about how we use EIA data for good is we try and give our customers an understanding of what their CO2 impact is of their monthly residential electricity use. It’s sort of like being able to keep track of your Carbon footprint, but in a very precise way, that is very much related to your individual usage. We do that using EIA data. So the power of government is you have the ability to go and collect data, and sort of mandate that the data that you’re surveying is getting responded to… Which is great.

One example is EIA has a survey of all the combustion power plants across the U.S. - so all the coal power plants, natural gas, oil… All of those power plants, and how much of each fossil fuel is being used in a year for each of those, and also how much CO2 is being emitted. So using that dataset, and using our individual customer data, we’re able to create individualized forecasts and calculations of how much CO2 is released by using a certain amount of electricity, and then also how much CO2 is averted when you’re able to source your power from places like wind and solar. So there’s a very direct relationship between how we use government data and our data to achieve that.

Adam Stacoviak: It’s very smart, I think, because you’re so comfortable in the Rails world… I think it’s smart because - yeah, Rails is mature enough that there are several opportunities out there just sort of waiting, in a way… And you could be a friend, you can bring something to it, you can give something new life, you can have somebody get liquidity out, or some sort of exit that might make sense… You can satisfy the existing customer base, you can bring it into the fold and grow it more and bigger… If we go back to the hub and spoke idea - and I don’t know exactly how far you go in to decide which really is your hub, but if you can start to surround this hub with various things that compliment this thesis, this idea of “Enjoy what you do, enjoy the process, great enough revenue to support other people, bring them in, everybody wins”, and you just kind of rinse and repeat… I think the question Jerod’s asking is like, at one point, can you exit that? And I think if you’re enjoying it for the next 12 years, there’s an obvious exit that can come about if you’re building value… So I don’t really – I personally wouldn’t care that much or concern that much with the exit strategy.

They do say every time you enter into a business or a room, that you should Jason Bourne it; you should plan your exit, right? You should never go into something and you don’t have some sort of like failsafe, or “What if this went to zero?” or exit strategy. I think that is smart. But I think if you’re comfortable with this Rails model, and this is only Rails SaaS apps, it would be kind of – not so much easy necessarily, but like you can see a clear path in terms of the word easy being applied. You can see a clear path to even the codebases getting refactored the same way, or having similarities across them, or services that you’re buying once, or you have one relationship, then benefit the whole entire pool. That’s why I like the lily pad analogy.

Adam Stacoviak: It’s new. So my personal usage has always been frustrated. At friends’ houses, they’ve got it to do lights, and stuff like that… And I’m like – okay, so in that example, which I haven’t gotten there yet, I think that’s cool. This goes back to the self-hosting. I would totally set up Home Assistant, configure Alexa to do these things… I think that’s cool. That’s a great usage of voice. It’s simple. It’s a simple interface to do things in your household.

[00:37:36.04] I also like HomeKit. And so in my house, at least we have some automated blinds, or some – they’re on the network, it has a hub… How do I describe this? They’re blinds that are electronic. They have a battery in them, so you can recharge them once per year, kind of thing. And it has a remote, and you can use the remote, obviously… But you can also just tell HomeKit, “Open all blinds”, or “Close living room blinds.” Or “Open living room blinds to 80%.” It’ll take even that kind of percentage number. And so HomeKit does a lot of that for me, so I haven’t really leaned too far into Home Assistant…

That being said, I’m not a super-insane self-hosting home automation person. I’m just a dip my toe in person, because I don’t have enough time to go as deep as I want to. I really should carve out more time. But my issue with Alexa is that it’s mostly frustrating. And the reason why I’m getting to this Alexa conversation is that - how would I want to leverage an LLM that I would host myself? Like OLAMA, or whatever. I would love to have some voice version of it, so I’m speaking to it, versus just having to type everything to it. Like, can I take this LLM and expand its usage? Alexa and Siri are the two good options for voice OS, and so I’m not sure that Siri is there yet. I wonder if Apple Intelligence will prohibit Siri from being more useful in those regards… Don’t talk to me, Siri. Gosh, Siri’s listening, on my phone right in front of me…

Adam Jacob: Yeah. So anyway, mom was a real estate agent, and PCs were a thing, that you could buy. And so she bought one that had a modem, because she wanted to be able to dial into the MLS… That’s the multiple listing service, for people who didn’t grow up the children of real estate agents. And it was where all the houses are. When they list houses, it’s the database you could go look at. And so you could dial into this bulletin board, and the bulletin board was the MLS. And then I thought it was awesome, and so you couldn’t keep me off the thing, from both playing video games, because obviously, but also, that modem meant you could just call bulletin boards. And so I have an older brother, and my older brother had a friend who he’d been on bulletin boards… And so he immediately showed me that bulletin boards existed, and how to call them, and I was just “Wait, wait, wait, wait, wait… You can just call other people’s computers, and then do stuff, talk to them?” You know, you could page the sysop, and it would ding their computer, and they would hit Spacebar, and then you could chat with the person who ran the bulletin board. And I just thought that was the coolest thing that had ever happened.

And then I discovered FidoNet. So FidoNet was an early version of email. So there was like [unintelligible 00:07:22.04] So you could build – and what was cool about FidoNet was it was basically like a regional network. So what happened is every bulletin board would call a central bulletin board… Or sorry, the opposite way. So the central bulletin board, with a central hub, would call all the bulletin boards in an area code, and then collect all their mail, and then make one single long distance call. And so everybody would sort of pitch in to cover the long distance fees for transferring your mail… And you could send mail all over the world. And the thing that blew my mind - because this was like peak Cold War - was you could send email to Russia. So you could talk with Russians over FidoNet. And so eight-year-old me – and no one knew how old you were. And so I was like a precocious eight-year-old or whatever, and I thought that was super-cool. You could play role-playing games, like play by email role-playing games, which I was all the way into… So yeah, I immediately loved bulletin boards. And then was like “I’ve got to run my own bulletin board.” So I was annoying my parents, because I immediately signed up for FidoNet, and was using my allowance to pay the long distance fees…

Justin Garrison: And that’s why we’re here. That’s why we’re explaining this stuff. So Wasmer is a runtime. So again, you can execute your WASM bytecode… And it’s created by the Wasmer company. I actually don’t know – I couldn’t find who’s behind the Wasmer company, but they make a runtime named after themselves… But they also make WAPM, which is the Web Assembly Package Manager. And this is kind of like a registry of reusable bits for Web Assembly-compiled code. You can think of this as any sort of registry as something similar to maybe a TerraForm modules, or Docker Hub… The downside is this is very, very new, and so when I looked at it, there was only like 1,000 packages out there… And there was only a dozen that looked reasonably useful. A lot of them to me were just like “Oh, I’ve no idea what that does.” It seems like someone just uploaded a package just to see how uploading packages works. So it looks a little bit promising, but again, another acronym that you might want to know, because they have a command line tool WAPM to install packages from their registry.

Adam Stacoviak: Yeah. This might be a challenge I think for everybody, is how do you have an active connection to your audience who wants to lurk/listen frequently. And I think that an active blog is one way. I think an active blog that isn’t robotic, like a brand blog, but more of like a branded personal-natured, written blog; it’s written by a person, it’s not Raycast the brand, and it’s just like something that’s a bit more connected.

And then obviously, I think for me - now, this is kind of going one layer deeper, but I just went to Twitter now, it’s actually called the Twitter App on macOS. Oddly enough, it’s not the X app, it’s the Twitter app… So that’s why this constant ebb and flow of “What is it actually called?” continues, because nobody gets it. But when I go to my notifications – this is what drives me away from Twitter/X, is that when I go to my notifications… And this is not a Thomas problem, or a Raycast problem, this is I think an everybody problem… My notifications are no longer mine. The first one in here is “Elon Musk posted something” in my notifications. And then somebody named Arman - who I follow, I’m sure; or maybe I don’t follow… Let me double-check. Like, it’s these things that I’m not even – I don’t even follow this person. They’re in my notifications, with this star thing. And Dax, and Rick’s, and Kelsey Hightower… Something I do pay attention to, but not like this. The Primagen. Christian Lampa. Other people are like all of my notifications.

[00:46:07.08] So I find that Twitter now is just so noisy. Like, I want to keep connecting with people in a high signal, low noise ratioed way. And there really is no right way to do that. You can publish a newsletter, maybe that’s high signal; I think that would be kind of cool. Maybe you can just convert your Changelog to a newsletter, or blog post… But that’s more ways to sort of tap into people.

I think when I zoom out though, and suggest or desire, especially as somebody who runs something, and somebody who consumes things, is I believe in the hub and spoke model, where you’re sort of hanging out with your best content based on what you’ve just said, on a spoke, not a hub. So you need a hub that’s Raycast-ran, Raycast-orchestrated, a place where you can go and check out and just browse, or subscribe to, and you push that stuff out to everywhere else, as necessary. I think you need to go back to that hub model, where you have a spoke and a hub. And right now you’re treating Twitter like the main place, but not everybody’s there, so you’re missing out. You’re missing out in keeping me entertained, at least.

Rahul Nair: Sure. So Intel Developer Cloud is Intel’s production-ready cloud specifically for AI and machine learning workloads. And of course, when we say AI and machine learning, it’s [unintelligible 00:19:22.01] so many other compute-heavy workloads can run really well on IDC.

So for this particular hack, we provided anyone logging into Intel Developer Cloud registering on IDC as a standard or free tier user - you get a shared Jupyter Hub instance, where you get access to Intel’s data center GPUs, Intel Xeon processors. And I would say this system, for a free tier user, I don’t think any other service provides. I mean, there are many services with a Jupyter Hub frontend, but the amount of compute and the amount of memory and RAM and even file storage that you get in the systems, I’m not seeing a single cloud service provider providing that. And we have seen a lot of people really using it, and giving us feedback on how we could even improve it.

Today on IDC we have a lot of models or LLMs already, and other tens or even hundreds of local models that we are planning to add further to boost this, that are Stable Diffusion models, LLM models, and things like that. Beyond that, for productionizing the workload - Dan, in your case, you’re using the Gaudi 2 accelerators. Those are specifically designed for workloads that request high bandwidth, like LLM and GenAI workloads, and this… I lost my train of thought, but yeah. We have Gaudi 2 accelerators, which we are seeing incredibly competitive, and sometimes outclassing the best out there for your particular workloads.

Along with Gaudi accelerators - those are specifically designed for GenAI and AI workloads - we have general-purpose GPUs, the data center [unintelligible 00:21:01.09] both with 48 gigs and 128-gig versions. So folks in the hackathon, they actually used both our fourth generation Xeon; that is the latest Xeons that we have, which - what it particularly does is that it accelerates your machine learning workloads. We have dedicated instructions in the CPU to sometimes even take your workload to 2x the performance that you got in an earlier generation.

It’s all about making the CPU as efficient as possible, and making it as fast as possible, and still maintaining the general purpose utility of a CPU. But then, like I said, the data center [unintelligible 00:21:42.08] a little bit more generic solution, where you can run your AI workload, [unintelligible 00:21:48.06] HPC workloads. Each of these machines, when you’re productionizing, you get a VM, you get an 8-node [unintelligible 00:21:56.22] system that also clusters the systems available. Then comes the Gaudi accelerators, both – there are single-node machines, and also clustered machines if you want to do pretraining or big fine-tuning. All those cool things. And soon, we’ll have Kubernetes service, object store, file store, all those things coming up… So it’s gonna be great.

[00:22:17.29] What I see is that if you’re building a startup, it would be very difficult to find a performant accelerator cloud like IDC out there. I’m sure that there are different hyperscalers… But this, uniquely for startups, from my personal experience, is a really, really awesome solution.

I’d like to know more from you, Dan. You are one of the first customers of IDC, right? What are the things that you thought that really made you decide to choose IDC, for the performance, and also the team side also?

Tammer Saleh: And even talking to, for example, some of the people inside Shopify - Shopify was touted as a place that was going to use Nix holistically, throughout their entire developer experience… And they tried, and they’ve put a good effort into it, but I’ve talked to a lot of the engineers that said “No, it was too hard to understand, especially for our new engineers”, and it just didn’t work.

That being said, I know there’s a lot of initiatives to fix Nix’s usability, and that’s great. I want to see that happen, because I personally am actually very excited about some of the aspects of Nix, like what it opens up. NixOS - sure. But just Nix as a package manager in general is just very interesting. It’s a really cool technology. But also timing… I mean, I read some of those comments too, and for some reason, this message was lost. So what am I going to do? I’m going to say it again, right? [laughs] Docker solved a lot of the problems that Nix is supposed to solve. There are ways to use Nix and Docker together, and a lot of the complaints I saw said “You don’t understand Nix” or “He doesn’t understand Docker…” And I’d like to think I understand Docker. If I don’t fully understand Nix - fair. But I did a lot of studying on it. I think I understand Nix, too. Docker is not just about running containers; it’s not just LXE. Docker solves three different problems. Running your container in a secure, multi-tenant fashion is definitely one of the problems Docker solves; it’s the most obvious. Packaging your dependencies… So basically, the first one was Docker Run – Docker Build, packaging all of your dependencies into one unit of distribution is another huge problem that it solves.

The third is as just a package distribution system. So Docker Hub is the third, right? Docker Build, Docker Run, Docker Hub. Nix solves the last two. Nix solves the packaging your application and its dependencies better than Docker does, right? Too many people don’t understand that if you run Docker build twice, and you’re not careful about your layer caches, you’re not going to get the same result. I hate that about Docker. You remember Bosh… Bosh got that right. Nix is a better version of that, right?

Josh Padnick: Yeah, that’s a great point. So one of the – there are a few kind of core tenants of our vision, and one of them is, of course, a clear, unambiguous open source license. Another one is backward compatibility. And what that specifically means for us is that any bug fixes that are reported, either to us, or that we see to TerraForm, we would like to implement fixes for. I should also say, it’s extremely important to the group to remain compliant with HashiCorp’s license. So we cannot just go to their repo and copy code improvements, just because they’re available. We are still working with our lawyers to figure out what information can we legally glean from what happens there, and where do we need to just not even look. So legal compliance is something that’s really important to us.

Anyway, to your point about compatibility… So that’s bug fixes. Then for new features that Hashi TerraForm releases, like I just said, we cannot just copy their implementation. But our understanding is that we can copy the interface, and we can do our own implementation, and make it interface-compatible. So to the greatest extent possible, we want to make OpenTF a drop-in replacement for Hashi TerraForm. And then once we feel like we’ve really achieved that expectation, where people feel like “Hey, this project is pretty stable. I can use this, I’m happy with it”, the other kind of big thread that we have is a community-driven RFC process for whatever improvements people want to see in OpenTF that could never make their way into HashiCorp. One example would be those encrypted state files, like I mentioned before. HashiCorp never wanted to merge that PR, and now this is an opportunity for OpenTF to figure out the right way to do encryption on state files, what all the potential pitfalls could be, go through a proper RFC process, get that merged, and now it’s a superset of what HashiTF would be.

Another example would be better importing from the Go codebase. So HashiCorp also made this sort of pivotal decision a while ago to lock down a lot of the internal libraries of TerraForm under a specific package in Go, so that they were difficult to access… And that meant that you couldn’t really use TerraForm as a library, you could really only use it as a CLI tool. And for those of us who are building things like pipeline solutions that operate TerraForm, or TerraGrunt, or whatever, we have to go through this awkwardness of using the CLI tool, when what we’d really like to do is just access the Go library directly.

[38:20] Another example would be downloading providers from any registry. So right now, HashiCorp forces you to download providers from their registry. And if you’ve written a custom provider, like maybe you’ve got some custom API, and you want people to be able to write TerraForm code for your custom thing - this understanding I need to check, but my understanding is that you can’t host that provider except with HashiCorp’s paid services. I might be wrong on that, so I definitely need to check on that. But in either case, with a community-driven process, we can now allow users to download their providers from any registry. In fact, someone from our consortium released a proof of concept video just a couple days ago showing how they were able to download TerraForm providers from Docker Hub, or ECR, or GitHub Container Registry.

So our first priority is compatibility, so that you can just do a drop-in replacement for Hashi TerraForm. But once we feel like we’ve really met that expectation, then we want to start focusing on our own set of innovations around this community-driven RFC process.

Daniel Whitenack: They say that SD XL 1.0 should work effectively on consumer GPUs with 8 gigabytes of GPU memory VRAM, or readily available cloud instances. So this is definitely a one-GPU model. Now, it might not work on all GPUs, depending on how you implement it, and how you call it, but definitely accessible to people, which I think is really cool.

[10:20] And also, that I think puts it in another realm, which is interesting - another thing they highlight around fine-tuning. So if you have a bigger model, it’s also generally harder to fine-tune that model for your own purposes. But along with this, they talk about kind of out-of-the-box support with LoRA, or the low rank adapters type of technique, where you can fine-tune the model in a very parameter-efficient way. And so the thought is, “Hey, people, this is open now. Create your own fine-tunes off of it as well.” And I imagine – this was just released… Well, it’s been a few days, but the 26th of July, as we’re recording this, 2023 - I’m guessing we’ll see a whole bunch of fine-tunes off of this appear on the model hub and elsewhere in days ahead… Similar to what we’re seeing actually with LLaMA 2.

That’s the other thing I was going to note on the model hub, is just the proliferation of LLaMA 2’s. I’m just looking at it right now, so I see Stable Diffusion XL base - that’s what’s trending at the top. Then we have the base LLaMA 2 from Meta, then we have Stable Beluga, which is also from Stable AI, and is a LLaMA 2 fine-tune… We’ve got LLaMA 2 7,000,000,000 32k – it looks like 32k context link from Together Computer, the Chat LLaMA, and then I see one, two, a whole bunch of other LLaMAs. So we’ll continue to see those proliferate, I think.

Daniel Whitenack: Yeah. And it is a crazy time in the AI community, with – so we use these Fully Connected episodes to update people on different news, and that sort of thing… And one of the things I was realizing this week as we were prepping for this episode is I’ve even seen there’s people - and I think there’s a website - talking about the Cambrian explosion of models, or the proliferation of models… So just in the past couple of weeks there’s so many different ones that have come out. It is really a proliferation… So I thought it’d be good to highlight a few of those. We can’t get to all of them, because they’re just so many… But one thing as a tip to people - sometimes how I look at this is I’ll go to Hugging Face and just go to the models tab, and if you make sure that it’s sorted by Trending, that’s kind of a cool way to see what’s at the top. And you can filter by different types of models, but I’ve found it kind of interesting to just look at what’s trending overall… Because, as of now, on the Hugging Face Hub it’s a mix between kind of video generation, image generation, language generation models… And over time, you can see kind of which of those categories is trending up or down. I don’t know, there’s probably an app that needs to be made to track that sort of thing, but I’ll let someone else do that.

One of the ones that I wanted to highlight was the new Stable Diffusion XL 0.9. Also, these model names are getting a little bit more complicated over time, I’ve found… But Stable Diffusion XL 0.9, or SD XL - of course, people probably remember Stable Diffusion. This is an image generation model; so you put in a text prompt, and then out comes an image… So something like “astronaut riding horse on the moon, photorealistic”, or something like that, and you get an image out. This one is kind of interesting… I think it was back in April they announced some kind of private access to this, or beta access… Now the model is up on Hugging Face, it is available, but under only a research-only license. But the images - I don’t know if you’ve seen some of these, Chris…

Jerry Liu: The data ingestion side is just the entrypoint to building a language model application on top of your own data. I think LLMs are cool. I want to use it on top of some existing services. What are those services, and how can I load in data from the surfaces? One component of Llama Index is this kind of community-driven hub of data loaders called LlamaHub, where we just offer a variety of different data connectors to a lot of different services. I think we have over 90-something different data connectors now. And these include connections to the file formats. So for instance like PDF files, HTML files, PowerPoints, images even… They can include connectors to APIs like Notion, Slack, Discord, Salesforce… Sorry, we actually don’t have Salesforce yet. That’s something that we want.

Adam Stacoviak: Right. And I don’t feel I can do it, I feel like together we can volley back and forth enough to get me further past – like you just said, I think it’s a great way to describe it, is I don’t have time to learn the expert levels of Docker file creation and all the things that go into like Docker images, and stuff… But just give me enough. This is the prompt I gave it. Because I didn’t tell it that the official Jekyll image didn’t support M1 Macs, I just said “This is what I want.” I said “I need to build a Docker image for Jekyll to run on my M1 Mac, with an Apple M1 Mac chip. Can you draft a Docker file for me?” And for the most part, the Docker file is almost exactly what I needed.

Then I learned more about ARM-64 version 8, this organization that’s community-led, it’s a Docker community, on Docker Hub… So it’s not just some randos out there supporting it. It’s many people; it’s a cohort of folks that are managing ARM builds for Docker files, so that you can run Ruby 2.7 in a Docker file, or in a Docker image, you can build that, you can tell it which working directory it’s going to be, what to run once it gets loaded up… All this different stuff, and I’m like, now, with this essentially grass – this sort of like guided tour, I suppose, through a Docker file, I know a lot more about them. And now I’m so much more confident to do these things. And that’s just one version of where I’ve been productive. That’s not even all the different ways that I’ve done some cool stuff behind the scenes with different stuff. It’s just, it’s absolutely like having somebody who’s willing to help you in any given moment, and they know enough to get you past the hurdles.

And I don’t I’m not scared of really what might be around the corner, because I’m like “Well, I mean, it might take a few volleys to get there, but I can throw the error at it. I can show this, I can show that” and they’re like “Oops, I’m sorry. You’re right. I forgot to mention this, this and this. Try this.” I try that. “That works, thank you.” And they’re like “You’re welcome. Come again.” That’s amazing.

Gerhard Lazu: [26:04] Okay, so you’re running it – so it runs Go on the outside, it provisions a Dagger engine inside Docker… Because if you have Docker, it needs to provision like the brains, if you wish, of where things will run… So by default, if you have Docker, it knows how to provision itself. When the Dagger engine spins up, all the operations run inside Dagger engine. The really cool thing is, if anything has been cached, it won’t run it again. So imagine our image, when you pull down our image… So when we build this runtime image, obviously we have to pull down the base one, which is based on the hexpm image, and that’s from Docker Hub, then it needs to install like a bunch of dependencies… And by the way, all that stuff - I mean, if you look at… I have to show you the code. This is too cool, Jerod. Check this out. So if you go to the pull request 450, and if you look at image files, image, image.go, look at line 50 to 61.

Merve Noyan: In Hugging Face, there’s a certain group of people like me that do not really have specific things. In Hugging Face nobody actually tells you, “You should do XY.” You just go ahead and pick a responsibility, and that’s your thing from that moment.

What I did so far - I did the Tasks, and I did a Keras integration in which I have done model cards and a Tensor board, and stuff. I really become so happy whenever I see a Keras repository with a model card inside, because I know that people actually find it useful and just keep using it.

I am currently working on how we can use Hugging Face hub for the tabular data. I’m working with an amazing scikit-learn core contributor that is currently in Hugging Face; he’s Adrian. We are currently working on a package that is focused on how we can improve the production capabilities of scikit-learn… Because you use, for instance, Pickle, which can run arbitrary code on your machine if you just pulled any Pickle and just de-serialize it. It’s a bit hard problem to tackle. We want to post whatever information we can have about the model. Currently, I’m working on that site.

For instance, if it’s a tree-based model, you can visualize the tree. If it’s a clustering model, depending on what type of clustering model that is - it can be like a dendrogram, or visual, like with a PCA… Or if you have a linear model, you can put the hyperplane… I am trying to put those stuff, and also, what model has learned through feature importance, Shapley values and everything. What I want is I want people to call one line of code and just push their models on the hub, which will create these model cards with several information. We are all supporting Gradio, and I’m also working on how we can leverage Gradio for tabular data stuff as well. Because previously, Gradio was mainly focused on the modalities, like text or audio or computer vision. And the components, if you take a look at the documentation, are focused on that; you can just drag and drop a dataset and just automatically visualize everything regarding that dataset, and that’s quite magical.

I remember the first time I used pandas-profiling, and also data analysis baseline library… There are a couple of libraries that enable you to profile your datasets, train baseline models, do an AutoML, like TPOT… I remember using them, and I was like, “This is witchcraft. This is so good.” [laughs] It saves so much time. Recently I realized, we can actually do that on the hub.

Currently, I am building two tools. One is profiling a dataset; it’s like a Gradio interface that does it. We have recently released in Gradio something called Blocks, which is more flexible than an interface. You have tabs, and you have rows, and you can put multiple stuff inside.

I’m currently building two spaces, like I said. I either build, I maintain, or add something to the Hugging Face hub library, or something else, or do demos… Currently, I’m working on something that is like an auto EDA, like a pandas-profiling. Another thing is an AutoML tool, sort of.

These types of things also save a lot of time and also lower the barrier of entry, I think, because you have a baseline model and it will push your best baseline model to the hub, and maybe you can create a space really easily on that, which you can later go and tell your local data scientist, “Hey, I want this, but improved version.”

I really love this. I was a big fan of Hugging Face for - I don’t know, since I saw Thomas’s video. I think it’s been three years or something, I don’t remember. And I’m still a big fan of Hugging Face. I go and talk at Python conferences and people approach me and say, “I’m a big fan of your conference.” And I’m like, “Me too.” [laughter]

Connor Sears: Yeah. Rewatch is an internal video hub for companies. We allow you to securely share, organize, distribute, and search all your video content. That could be coming from short-form screen recordings, which we have a screen recorder for you if you’re into that sort of thing. It’s from connecting up with your Zoom or Google meetings and recording those meetings for you, and automatically ingesting those into the product.

As you mentioned earlier, transcribing all that video content and then making it searchable unlocks a lot of value for teams. Number one is creating video is extremely high bandwidth. You can talk somebody’s ear off, you can record it all day long, but actually consuming that content and getting the knowledge or the value as a co-worker, for instance, out of that video is extremely low bandwidth. That’s not an effective way of doing work, sitting around watching video all day. That’s coming from a CEO of a company that builds a video tool.

Mike Riley: [laughs] Right. It’s got a photo-sensor on it, so that if you have motion detection, you can do that type of thing. As a matter of fact, in one of the projects that I tie in the motion sensor along with another attachment that you can buy for the Pi, which is the Pi camera. That’s sold by the Raspberry Pi Foundation. There’s others you can buy too, with different kind of imaging quality. But the one that the Pi sells, the Pi Camera 2, is actually pretty good. It’s got both video and still frame capabilities built-in. And they’re fairly decent, even on low capabilities. So what I did in the book was show you how you can connect that motion sensor so that when there is motion detected, you can do a capture. And that capture - again, it could either be a video, or in my case, I just want it as a still image… And then you take that still image and you could email it as an attachment, but what I did was I tied it in the Discord API, so I could get an immediate notification along with the image, that shows me somebody just walked in the area that I was measuring. So if you wanted to protect your room, or you wanted to see if there’s anybody stopping by in front of your home, or any other place that you wanna see, if there’s motion detected… If you have a house pet that is looking to get into things - you could sit that up so that you would immediately get a notification on your phone or on your computer saying “This is what happened, this is what I saw”, and now you can act upon that. So that’s kind of a nice sensing capability.

Talking about the Hue, the reasons why I liked that so much for my lighting and electrical triggering needs is because they do have an open platform. In fact, there’s Hue libraries not just for Python, but for Go, for Rust, for Java… Pretty much any popular language that’s out there, Hue supports it either through third-party libraries that people have posted on GitHub… And it’s just really – again, it’s a nice, open platform to work with, so you’re able to interact with that Hue hub very simply. And I show in the book how it’s easy to use this very popular Hue library called pHue, for Python. It’s very comprehensive, very complete, and yet very easy to use, so that you can not only interrogate Hue to see what are the lights that are connected, including the names that you may have assigned them, but also to be able to trigger on auth connectivity… You can do dimming, you can change the color… So it really gives you a lot of flexibility. The deeper that you wanna get into, the level of sophistication is just really off the charts.

The other cool thing about all of this capability as you start to connect all these pieces together is the complexity that can grow out of a very simple project, and yet, because you were able to build it in stages, you’re very competent on knowing exactly what’s happening and all the dependencies that are connected to it. But at the same time, it’s acting almost - not like a sentient system, but certainly you would never be able to do something as sophisticated, with those level of triggers and actions and reactions if you didn’t have these capabilities and these systems in place.

So again, think about all the sensors that you can deploy, and all of the different feedback systems that you can enable. So based on all these sensors and whatever their values may be, you can act upon them and make them do things that you would not possibly be able to do, even with the very expensive automation platform that is custom-designed for those kinds of interactions, just because it’s such a unique use case that you can’t scale it to make it a commercial product. But for your own special needs, you can do some amazing things, and make it specifically tailor-made for exactly what you need to do, and that’s why I think that Py platform and all these automation capabilities and these sensors really make a lot of sense for the home enthusiasts.

Andrea Luzzardi: [03:58] Yeah, I’d be happy to talk about that. It’s actually a very long story, so I have to go back a few years… So it all started with dotCloud, which was the company behind Docker at the time. So we have to go back to 2011, actually. At the time, if you wanted to deploy an application, you had two choices. So either you manage your own machines, like provision a cluster, either bare metal or with EC2, and kind of like figure out a way to provision your services manually, or like using Salt or Ansible. Or if you’re lucky enough to use Ruby on Rails and Postgres, then your answer was Heroku. But there was nothing between. If you happened to be using Django and MySQL, then you were out of luck. You had to provision your own cluster.

So that was the premise behind dotCloud - it was like Heroku, but it was any language, with any database. And it turns out that it’s pretty hard to do, because now you have to handle a bunch of different languages on every machine, with different versions per language, and that’s not something simple to do. Also, at the time it was impossible on EC2 to run VMs, because you were already in a VM. So that’s where containers came in.

We discovered C-groups and spaces, and started to create our own container runtime internally. That’s basically an ancestor of Docker. But there was no tooling around that, so we had to built our own container builder, which eventually became Docker Build. We had to build our own registry; we had to build our own load balancer, because load balancers were meant for machine-to-machine, but not machine-to-container.

It’s actually Sam Alba that created something called Hipache, the Apache for hipsters. It was an HTTP load balancer for containers. And finally, we had to put those containers into machines, and so we created a container orchestrator internally.

So we had this entire stack, with basically what eventually became Docker, the registry, Docker Hub, Docker Build and Docker Swarm. So we had all these platforms back in 2011. Then a few years go by and Heroku now has buildpacks to build any language. They were getting a lot of attention from the community, and we thought that was pretty cool; why don’t we open source the core of what we have, starting by the container runtime? So that’s where Docker came to be, in 2013. So that’s the long history behind that.

In 2013 we open sourced Docker, and about a year after, in 2014, we reached 1.0. That was announced at the first DockerCon. People started to have questions, like “How do I do this, or that?” For instance, some of the questions were like “Okay, now I have a container, but I need to run my entire application.” And people were starting to do some hacks around that, like shoving an entire init system, like systemd inside the container to run multiple processes. We were trying to push a new approach, of just running a single service per container… And so basically having multiple containers, like microservices. And then the question arose, “I can docker run one container, but how do I do that with multiple containers?” So that year we released Docker Compose…

Abubakar Abid: [28:11] Yeah, that’s a good question. There’s a lot here. So one of the things that I’m amazed by is just the diversity in the types of models that people are building. This is shocking. I think sometimes you it be kind of an echo chamber, where you think “Okay, most people use machine learning for these types of use cases”, but then you see users that just completely blow your mind. For example people using GANs to generate Pokémon, or people using speech recognition in so many other languages, and you have to realize you have to support Unicode this, and that… It’s just a lot. It’s just a lot of different use cases that show up, and you have to address that.

One of the good things about Gradio - I talked earlier about how there’s like two different cycles of machine learning. There’s the exploratory/research stage, and then there’s actual production-level type stuff. At Gradio, we tend to focus more on the exploratory/research side. So even when you share a model, let’s stay on Spaces, or you share it temporarily - so I don’t know if you’ve seen this, but if you create a Gradio demo, you can pass in one extra parameter in the launch function, share equals two, and that creates this temporary public link that allows anyone to access your model, which is super, super-handy for prototyping.

And so what we’ve entirely focused on, we’ve said we’re not trying to optimize for production-level traffics or anything like that. We want to just focus on, “Hey, let a few people try out your model, get feedback. Let a few other people try out your model.”

And so because we’ve kind of laser-focused on that use case, even when a lot of other people are using Gradio demos, we have always stayed with that expectation. So for example, people asked us, “Oh, my space is up on Hugging Face. I want to use it as an API.” Well, we added support for that, but we kind of made it clear, “Hey, this is not meant to be a production-level API. You can use it for testing, and so on.” So I think we’ve mitigated a lot of like traffic type related issues just by focusing on this stage of the use case.

And then the other thing that we’ve tried to do is leverage Hugging Face’s and existing infrastructure as much as possible. So for example, Hugging Face already has something called the Inference API. So any sort of model that you can find on the Hugging Face hub, which at this point is I think more than 30,000 different models, it comes with its own inference API that you can just call. Gradio also supports using any of the models in the Hugging Face hub pretty much off the shelf. So in one line of code, you can build a demo for one of these models. And if you do it, it leverages Hugging Face’s existing inference API, rather than trying to create something ourselves.

So by doing that, I think we’ve mitigated a lot of those load issues, but what we definitely find is a lot of people using Gradio in these different use cases that we wouldn’t even imagine. We see a lot of issues being raised, and then we’re doing our best to kind of support that. But a lot of cool things – like, people ask for new types of components as well. And so we’re working on supporting that. A lot of people ask for like, “We’re using this Space to test our model. We’re seeing some kind of weird behavior. How do we retrain the model based on what kind of issues have been observed?” So we’re thinking about how to fit Gradio into this larger loop of training models, again, and making them better as well. So yeah, a lot of cool things there.

Alexis Richardson: Ha-ha! I mean, we have things like, you know, Helm chart repositories as artifact, and companies like Amazon have marketplaces, Red Hat has Operator Hub… So in a sense, we are, little by little, getting closer to the idea that there is a systematic way to extend one piece of enterprise software with another. But really, I was talking about – you know, it’s a castle in the sky. I think the reason I discussed the enterprise app store is because in a way, it’s such a ridiculous idea.

[08:04] If you look at the presentation that I gave, which if you find GitOpsCon, the keynotes that I gave for KubeCon - it’s all there; there’s a YouTube video and the slides are online, and I’ll give you a link afterwards that you can share with your audience… But if you look at it, you’ll see that I’m talking about how in technology we have these sort of pivotal moments. And for me, a really important technology moment in the last few years - not the only one, by any means - was the iPhone. When the iPod appeared, people said “Why do we need this? We have the Walkman already.” And then they bought it and they went “Oh, that’s actually a quite cool device.” And then we saw that the Zune was a way to do it badly… You know, don’t make it brown; tip for next time. Things like this. But it wasn’t really until that form factor also became a phone and then a camera that people went “Hang on a minute, this could be a really profound change in how we interact with technology…” And you know, not necessarily even in a good way. I mean, it brings things like Facebook into your life maybe too intrusively. But it was a really important moment. And if you look at the Apple share price and at the graph of other Apple releases over time, you’ll see there’s a big push up after this thing appears, followed closely by the app store.

And what the app store did was it made it possible to put anything on your phone. And those two together created what people call “the iPhone moment” or “the App Store moment.” It’s just a sea change in convenience and experience. And if you think about the web, we need these richer experiences, because before that we had HTML, then we had Ajax… But while that was going on, we had phone apps, and I think you may recall there was this great technology called WAP at one point, that everybody was saying was gonna change the game… And I was wondering how my Nokia 9000 or whatever it was, with its screen that was about the size of a coin, and it was LCD, was going to help me to do something cool online, like I could with Amazon on Yahoo! on my phone. And obviously, the technology just wasn’t up to it. But with the iPhone, and of course, high bandwidth, you have essentially a computer in your hand, and that means that you can start to build a whole new kind of human experience around it, for better or for worse.

So I think that it is appropriate to draw an analogy between then and now, and say that we have not had yet the iPhone moment for cloud-native technology. I mean, a smaller, but equally profound shift was with the web, which then produced Amazon, eBay etc. I think with the web we didn’t have one moment, we just had lots. You choose your favorite. My favorite might be the day that Google came out, or the day that Bill Gates said “The internet is important”, or whatever it was. With iPhone, it was a clear, single point in time. And I think whether it’s a shift of several steps or one thing, cloud-native has yet to achieve the kind of obvious change that those moments have. And the characteristic is you can’t imagine what life was like before it.

Gerhard Lazu: Right. Oh, that’s a good one. Dag this. It asks me to enter my username… This will be stored encrypted, by the way, because – no, this was to be stored as text; nothing secret, it’s Gerhard, you already guessed it… And then it asks me for my Docker Hub password, so that it can push the image. These are stored encrypted, using SOPS, locally. And then there’s a couple of things here, we’ll skip over them… And then we provide the inputs. Those inputs are important because that’s what the environment, or the plan, or the dag, as Joel mentioned, calls it. So we have the app, which is basically the whole source code… There’s a couple of things that we need from the environment, like the Git SHA, the Git author… Hm. I don’t think I fixed those; I need to fix them. Okay, this is something which still needs to improve; I just realized, going through this now. See? It’s so good we’re doing these things. So helpful.

Cool. So then the Docker host, which is the remote one, it knows how to connect to it… And then it runs the same command that you’ve seen in GitHub Actions. Docker – sorry. Docker… That’s like a Freudian slip. Dagger - Dagger Up, log-level debug, environment CI. And that’s exactly the same thing.

The other part of this is obviously the CI queue. And this is like all the code that actually declares the pipeline. And what is this ci.queue? How would you describe it?

Daniel Whitenack: So one more thing that I wanted to mention from Hugging Face, just before we’re moving on - they’ve had a couple of releases that are quite interesting. The other one I wanted to mention was what they’re calling a data measurements tool, which is an open source project. This just was released as well, and you can look through it. The data measurement’s role they say is an interactive interface and open source library that lets dataset creators and users automatically calculate metrics that are meaningful and useful for responsible data development. This is new enough that I haven’t dug into it, but I think this does certain things, everything from basic things that you might expect from exploratory data analysis, like figuring out missing values and descriptive statistics, all the way to analyzing biases in datasets, maybe related to particular factors, like gender or other things. And so I think, ultimately, what they’re trying to do here is create a nice way for people that are maybe using data sets off of Hugging Face’s data sets hub, or creating new data sets to really understand a little bit more about them and document them a little bit better, so that people aren’t just pulling whatever data set looks good, without understanding the implications of that. So it’s a pretty cool route that they’re going, I think.

Jerod Santo: And your website is a wealth of things. I looked at the copyright, I think it was back to 1999… So I like this – you have your hub, and everything else is just distribution or broadcasting into other spaces… But aaronparecki.com - that’s yours, you own it, you can do whatever you want with it, you’ve built over time… A lot of us replace our website, but it seems like you’ve been adding new portions. So you can tie into this lifelong database of GPSes positioning and use it however you like. It’s pretty cool.