Podcasts about Hetzner

This week, I'm sharing behind-the-scenes choices that allowed Podscan's growth from a small experiment to a thriving business. I'll delve into the choices I've made and how some have worked better than others. I'll explore the key decisions that have driven our success, such as selecting the right tools and technology, and utilizing AI to enhance the efficiency of our processes. Join me to learn how these choices, along with important upgrades and strategic partnerships, have contributed to our achievements.The blog post: https://thebootstrappedfounder.com/one-year-of-podscan-reflecting-on-tech-business-decisions/The podcast episode: https://tbf.fm/episodes/386-one-year-of-podscan-reflecting-on-tech-business-decisionsCheck out Podscan, the Podcast database that transcribes every podcast episode out there minutes after it gets released: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

Brandon Liu is an open source developer and creator of the Protomaps basemap project. We talk about how static maps help developers build sites that last, the PMTiles file format, the role of OpenStreetMap, and his experience funding and running an open source project full time. Protomaps Protomaps PMTiles (File format used by Protomaps) Self-hosted slippy maps, for novices (like me) Why Deploy Protomaps on a CDN User examples Flickr Pinball Map Toilet Map Related projects OpenStreetMap (Dataset protomaps is based on) Mapzen (Former company that released details on what to display based on zoom levels) Mapbox GL JS (Mapbox developed source available map rendering library) MapLibre GL JS (Open source fork of Mapbox GL JS) Other links HTTP range requests (MDN) Hilbert curve Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: I'm talking to Brandon Liu. He's the creator of Protomaps, which is a way to easily create and host your own maps. Let's get into it. [00:00:09] Brandon: Hey, so thanks for having me on the podcast. So I'm Brandon. I work on an open source project called Protomaps. What it really is, is if you're a front end developer and you ever wanted to put maps on a website or on a mobile app, then Protomaps is sort of an open source solution for doing that that I hope is something that's way easier to use than, um, a lot of other open source projects. Why not just use Google Maps? [00:00:36] Jeremy: A lot of people are gonna be familiar with Google Maps. Why should they worry about whether something's open source? Why shouldn't they just go and use the Google maps API? [00:00:47] Brandon: So Google Maps is like an awesome thing it's an awesome product. Probably one of the best tech products ever right? And just to have a map that tells you what restaurants are open and something that I use like all the time especially like when you're traveling it has all that data. And the most amazing part is that it's free for consumers but it's not necessarily free for developers. Like if you wanted to embed that map onto your website or app, that usually has an API cost which still has a free tier and is affordable. But one motivation, one basic reason to use open source is if you have some project that doesn't really fit into that pricing model. You know like where you have to pay the cost of Google Maps, you have a side project, a nonprofit, that's one reason. But there's lots of other reasons related to flexibility or customization where you might want to use open source instead. Protomaps examples [00:01:49] Jeremy: Can you give some examples where people have used Protomaps and where that made sense for them? [00:01:56] Brandon: I follow a lot of the use cases and I also don't know about a lot of them because I don't have an API where I can track a hundred percent of the users. Some of them use the hosted version, but I would say most of them probably use it on their own infrastructure. One of the cool projects I've been seeing is called Toilet Map. And what toilet map is if you're in the UK and you want find a public restroom then it maps out, sort of crowdsourced all of the public restrooms. And that's important for like a lot of people if they have health issues, they need to find that information. And just a lot of different projects in the same vein. There's another one called Pinball Map which is sort of a hobby project to find all the pinball machines in the world. And they wanted to have a customized map that fit in with their theme of pinball. So these sorts of really cool indie projects are the ones I'm most excited about. Basemaps vs Overlays [00:02:57] Jeremy: And if we talk about, like the pinball map as an example, there's this concept of a basemap and then there's the things that you lay on top of it. What is a basemap and then is the pinball locations is that part of it or is that something separate? [00:03:12] Brandon: It's usually something separate. The example I usually use is if you go to a real estate site, like Zillow, you'll open up the map of Seattle and it has a bunch of pins showing all the houses, and then it has some information beneath it. That information beneath it is like labels telling, this neighborhood is Capitol Hill, or there is a park here. But all that information is common to a lot of use cases and it's not specific to real estate. So I think usually that's the distinction people use in the industry between like a base map versus your overlay. The overlay is like the data for your product or your company while the base map is something you could get from Google or from Protomaps or from Apple or from Mapbox that kind of thing. PMTiles for hosting the basemap and overlays [00:03:58] Jeremy: And so Protomaps in particular is responsible for the base map, and that information includes things like the streets and the locations of landmarks and things like that. Where is all that information coming from? [00:04:12] Brandon: So the base map information comes from a project called OpenStreetMap. And I would also, point out that for Protomaps as sort of an ecosystem. You can also put your overlay data into a format called PMTiles, which is sort of the core of what Protomaps is. So it can really do both. It can transform your data into the PMTiles format which you can host and you can also host the base map. So you kind of have both of those sides of the product in one solution. [00:04:43] Jeremy: And so when you say you have both are you saying that the PMTiles file can have, the base map in one file and then you would have the data you're laying on top in another file? Or what are you describing there? [00:04:57] Brandon: That's usually how I recommend to do it. Oftentimes there'll be sort of like, a really big basemap 'cause it has all of that data about like where the rivers are. Or while, if you want to put your map of toilets or park benches or pickleball courts on top, that's another file. But those are all just like assets you can move around like JSON or CSV files. Statically Hosted [00:05:19] Jeremy: And I think one of the things you mentioned was that your goal was to make Protomaps or the, the use of these PMTiles files easy to use. What does that look like for, for a developer? I wanna host a map. What do I actually need to, to put on my servers? [00:05:38] Brandon: So my usual pitch is that basically if you know how to use S3 or cloud storage, that you know how to deploy a map. And that, I think is the main sort of differentiation from most open source projects. Like a lot of them, they call themselves like, like some sort of self-hosted solution. But I've actually avoided using the term self-hosted because I think in most cases that implies a lot of complexity. Like you have to log into a Linux server or you have to use Kubernetes or some sort of Docker thing. What I really want to emphasize is the idea that, for Protomaps, it's self-hosted in the same way like CSS is self-hosted. So you don't really need a service from Amazon to host the JSON files or CSV files. It's really just a static file. [00:06:32] Jeremy: When you say static file that means you could use any static web host to host your HTML file, your JavaScript that actually renders the map. And then you have your PMTiles files, and you're not running a process or anything, you're just putting your files on a static file host. [00:06:50] Brandon: Right. So I think if you're a developer, you can also argue like a static file server is a server. It's you know, it's the cloud, it's just someone else's computer. It's really just nginx under the hood. But I think static storage is sort of special. If you look at things like static site generators, like Jekyll or Hugo, they're really popular because they're a commodity or like the storage is a commodity. And you can take your blog, make it a Jekyll blog, hosted on S3. One day, Amazon's like, we're charging three times as much so you can move it to a different cloud provider. And that's all vendor neutral. So I think that's really the special thing about static storage as a primitive on the web. Why running servers is a problem for resilience [00:07:36] Jeremy: Was there a prior experience you had? Like you've worked with maps for a very long time. Were there particular difficulties you had where you said I just gotta have something that can be statically hosted? [00:07:50] Brandon: That's sort of exactly why I got into this. I've been working sort of in and around the map space for over a decade, and Protomaps is really like me trying to solve the same problem I've had over and over again in the past, just like once and forever right? Because like once this problem is solved, like I don't need to deal with it again in the future. So I've worked at a couple of different companies before, mostly as a contractor, for like a humanitarian nonprofit for a design company doing things like, web applications to visualize climate change. Or for even like museums, like digital signage for museums. And oftentimes they had some sort of data visualization component, but always sort of the challenge of how to like, store and also distribute like that data was something that there wasn't really great open source solutions. So just for map data, that's really what motivated that design for Protomaps. [00:08:55] Jeremy: And in those, those projects in the past, were those things where you had to run your own server, run your own database, things like that? [00:09:04] Brandon: Yeah. And oftentimes we did, we would spin up an EC2 instance, for maybe one client and then we would have to host this server serving map data forever. Maybe the client goes away, or I guess it's good for business if you can sign some sort of like long-term support for that client saying, Hey, you know, like we're done with a project, but you can pay us to maintain the EC2 server for the next 10 years. And that's attractive. but it's also sort of a pain, because usually what happens is if people are given the choice, like a developer between like either I can manage the server on EC2 or on Rackspace or Hetzner or whatever, or I can go pay a SaaS to do it. In most cases, businesses will choose to pay the SaaS. So that's really like what creates a sort of lock-in is this preference for like, so I have this choice between like running the server or paying the SaaS. Like businesses will almost always go and pay the SaaS. [00:10:05] Jeremy: Yeah. And in this case, you either find some kind of free hosting or low-cost hosting just to host your files and you upload the files and then you're good from there. You don't need to maintain anything. [00:10:18] Brandon: Exactly, and that's really the ideal use case. so I have some users these, climate science consulting agencies, and then they might have like a one-off project where they have to generate the data once, but instead of having to maintain this server for the lifetime of that project, they just have a file on S3 and like, who cares? If that costs a couple dollars a month to run, that's fine, but it's not like S3 is gonna be deprecated, like it's gonna be on an insecure version of Ubuntu or something. So that's really the ideal, set of constraints for using Protomaps. [00:10:58] Jeremy: Yeah. Something this also makes me think about is, is like the resilience of sites like remaining online, because I, interviewed, Kyle Drake, he runs Neocities, which is like a modern version of GeoCities. And if I remember correctly, he was mentioning how a lot of old websites from that time, if they were running a server backend, like they were running PHP or something like that, if you were to try to go to those sites, now they're like pretty much all dead because there needed to be someone dedicated to running a Linux server, making sure things were patched and so on and so forth. But for static sites, like the ones that used to be hosted on GeoCities, you can go to the internet archive or other websites and they were just files, right? You can bring 'em right back up, and if anybody just puts 'em on a web server, then you're good. They're still alive. Case study of news room preferring static hosting [00:11:53] Brandon: Yeah, exactly. One place that's kind of surprising but makes sense where this comes up, is for newspapers actually. Some of the users using Protomaps are the Washington Post. And the reason they use it, is not necessarily because they don't want to pay for a SaaS like Google, but because if they make an interactive story, they have to guarantee that it still works in a couple of years. And that's like a policy decision from like the editorial board, which is like, so you can't write an article if people can't view it in five years. But if your like interactive data story is reliant on a third party, API and that third party API becomes deprecated, or it changes the pricing or it, you know, it gets acquired, then your journalism story is not gonna work anymore. So I have seen really good uptake among local news rooms and even big ones to use things like Protomaps just because it makes sense for the requirements. Working on Protomaps as an open source project for five years [00:12:49] Jeremy: How long have you been working on Protomaps and the parts that it's made up of such as PMTiles? [00:12:58] Brandon: I've been working on it for about five years, maybe a little more than that. It's sort of my pandemic era project. But the PMTiles part, which is really the heart of it only came in about halfway. Why not make a SaaS? [00:13:13] Brandon: So honestly, like when I first started it, I thought it was gonna be another SaaS and then I looked at it and looked at what the environment was around it. And I'm like, uh, so I don't really think I wanna do that. [00:13:24] Jeremy: When, when you say you looked at the environment around it what do you mean? Why did you decide not to make it a SaaS? [00:13:31] Brandon: Because there already is a lot of SaaS out there. And I think the opportunity of making something that is unique in terms of those use cases, like I mentioned like newsrooms, was clear. Like it was clear that there was some other solution, that could be built that would fit these needs better while if it was a SaaS, there are plenty of those out there. And I don't necessarily think that they're well differentiated. A lot of them all use OpenStreetMap data. And it seems like they mainly compete on price. It's like who can build the best three column pricing model. And then once you do that, you need to build like billing and metrics and authentication and like those problems don't really interest me. So I think, although I acknowledge sort of the indie hacker ethos now is to build a SaaS product with a monthly subscription, that's something I very much chose not to do, even though it is for sure like the best way to build a business. [00:14:29] Jeremy: Yeah, I mean, I think a lot of people can appreciate that perspective because it's, it's almost like we have SaaS overload, right? Where you have so many little bills for your project where you're like, another $5 a month, another $10 a month, or if you're a business, right? Those, you add a bunch of zeros and at some point it's just how many of these are we gonna stack on here? [00:14:53] Brandon: Yeah. And honestly. So I really think like as programmers, we're not really like great at choosing how to spend money like a $10 SaaS. That's like nothing. You know? So I can go to Starbucks and I can buy a pumpkin spice latte, and that's like $10 basically now, right? And it's like I'm able to make that consumer choice in like an instant just to spend money on that. But then if you're like, oh, like spend $10 on a SaaS that somebody put a lot of work into, then you're like, oh, that's too expensive. I could just do it myself. So I'm someone that also subscribes to a lot of SaaS products. and I think for a lot of things it's a great fit. Many open source SaaS projects are not easy to self host [00:15:37] Brandon: But there's always this tension between an open source project that you might be able to run yourself and a SaaS. And I think a lot of projects are at different parts of the spectrum. But for Protomaps, it's very much like I'm trying to move maps to being it is something that is so easy to run yourself that anyone can do it. [00:16:00] Jeremy: Yeah, and I think you can really see it with, there's a few SaaS projects that are successful and they're open source, but then you go to look at the self-hosting instructions and it's either really difficult to find and you find it, and then the instructions maybe don't work, or it's really complicated. So I think doing the opposite with Protomaps. As a user, I'm sure we're all appreciative, but I wonder in terms of trying to make money, if that's difficult. [00:16:30] Brandon: No, for sure. It is not like a good way to make money because I think like the ideal situation for an open source project that is open that wants to make money is the product itself is fundamentally complicated to where people are scared to run it themselves. Like a good example I can think of is like Supabase. Supabase is sort of like a platform as a service based on Postgres. And if you wanted to run it yourself, well you need to run Postgres and you need to handle backups and authentication and logging, and that stuff all needs to work and be production ready. So I think a lot of people, like they don't trust themselves to run database backups correctly. 'cause if you get it wrong once, then you're kind of screwed. So I think that fundamental aspect of the product, like a database is something that is very, very ripe for being a SaaS while still being open source because it's fundamentally hard to run. Another one I can think of is like tailscale, which is, like a VPN that works end to end. That's something where, you know, it has this networking complexity where a lot of developers don't wanna deal with that. So they'd happily pay, for tailscale as a service. There is a lot of products or open source projects that eventually end up just changing to becoming like a hosted service. Businesses going from open source to closed or restricted licenses [00:17:58] Brandon: But then in that situation why would they keep it open source, right? Like, if it's easy to run yourself well, doesn't that sort of cannibalize their business model? And I think that's really the tension overall in these open source companies. So you saw it happen to things like Elasticsearch to things like Terraform where they eventually change the license to one that makes it difficult for other companies to compete with them. [00:18:23] Jeremy: Yeah, I mean there's been a number of cases like that. I mean, specifically within the mapping community, one I can think of was Mapbox's. They have Mapbox gl. Which was a JavaScript client to visualize maps and they moved from, I forget which license they picked, but they moved to a much more restrictive license. I wonder what your thoughts are on something that releases as open source, but then becomes something maybe a little more muddy. [00:18:55] Brandon: Yeah, I think it totally makes sense because if you look at their business and their funding, it seems like for Mapbox, I haven't used it in a while, but my understanding is like a lot of their business now is car companies and doing in dash navigation. And that is probably way better of a business than trying to serve like people making maps of toilets. And I think sort of the beauty of it is that, so Mapbox, the story is they had a JavaScript renderer called Mapbox GL JS. And they changed that to a source available license a couple years ago. And there's a fork of it that I'm sort of involved in called MapLibre GL. But I think the cool part is Mapbox paid employees for years, probably millions of dollars in total to work on this thing and just gave it away for free. Right? So everyone can benefit from that work they did. It's not like that code went away, like once they changed the license. Well, the old version has been forked. It's going its own way now. It's quite different than the new version of Mapbox, but I think it's extremely generous that they're able to pay people for years, you know, like a competitive salary and just give that away. [00:20:10] Jeremy: Yeah, so we should maybe look at it as, it was a gift while it was open source, and they've given it to the community and they're on continuing on their own path, but at least the community running Map Libre, they can run with it, right? It's not like it just disappeared. [00:20:29] Brandon: Yeah, exactly. And that is something that I use for Protomaps quite extensively. Like it's the primary way of showing maps on the web and I've been trying to like work on some enhancements to it to have like better internationalization for if you are in like South Asia like not show languages correctly. So I think it is being taken in a new direction. And I think like sort of the combination of Protomaps and MapLibre, it addresses a lot of use cases, like I mentioned earlier with like these like hobby projects, indie projects that are almost certainly not interesting to someone like Mapbox or Google as a business. But I'm happy to support as a small business myself. Financially supporting open source work (GitHub sponsors, closed source, contracts) [00:21:12] Jeremy: In my previous interview with Tom, one of the main things he mentioned was that creating a mapping business is incredibly difficult, and he said he probably wouldn't do it again. So in your case, you're building Protomaps, which you've admitted is easy to self-host. So there's not a whole lot of incentive for people to pay you. How is that working out for you? How are you supporting yourself? [00:21:40] Brandon: There's a couple of strategies that I've tried and oftentimes failed at. Just to go down the list, so I do have GitHub sponsors so I do have a hosted version of Protomaps you can use if you don't want to bother copying a big file around. But the way I do the billing for that is through GitHub sponsors. If you wanted to use this thing I provide, then just be a sponsor. And that definitely pays for itself, like the cost of running it. And that's great. GitHub sponsors is so easy to set up. It just removes you having to deal with Stripe or something. 'cause a lot of people, their credit card information is already in GitHub. GitHub sponsors I think is awesome if you want to like cover costs for a project. But I think very few people are able to make that work. A thing that's like a salary job level. It's sort of like Twitch streaming, you know, there's a handful of people that are full-time streamers and then you look down the list on Twitch and it's like a lot of people that have like 10 viewers. But some of the other things I've tried, I actually started out, publishing the base map as a closed source thing, where I would sell sort of like a data package instead of being a SaaS, I'd be like, here's a one-time download, of the premium data and you can buy it. And quite a few people bought it I just priced it at like $500 for this thing. And I thought that was an interesting experiment. The main reason it's interesting is because the people that it attracts to you in terms of like, they're curious about your products, are all people willing to pay money. While if you start out everything being open source, then the people that are gonna be try to do it are only the people that want to get something for free. So what I discovered is actually like once you transition that thing from closed source to open source, a lot of the people that used to pay you money will still keep paying you money because like, it wasn't necessarily that that closed source thing was why they wanted to pay. They just valued that thought you've put into it your expertise, for example. So I think that is one thing, that I tried at the beginning was just start out, closed source proprietary, then make it open source. That's interesting to people. Like if you release something as open source, if you go the other way, like people are really mad if you start out with something open source and then later on you're like, oh, it's some other license. Then people are like that's so rotten. But I think doing it the other way, I think is quite valuable in terms of being able to find an audience. [00:24:29] Jeremy: And when you said it was closed source and paid to open source, do you still sell those map exports? [00:24:39] Brandon: I don't right now. It's something that I might do in the future, you know, like have small customizations of the data that are available, uh, for a fee. still like the core OpenStreetMap based map that's like a hundred gigs you can just download. And that'll always just be like a free download just because that's already out there. All the source code to build it is open source. So even if I said, oh, you have to pay for it, then someone else can just do it right? So there's no real reason like to make that like some sort of like paywall thing. But I think like overall if the project is gonna survive in the long term it's important that I'd ideally like to be able to like grow like a team like have a small group of people that can dedicate the time to growing the project in the long term. But I'm still like trying to figure that out right now. [00:25:34] Jeremy: And when you mentioned that when you went from closed to open and people were still paying you, you don't sell a product anymore. What were they paying for? [00:25:45] Brandon: So I have some contracts with companies basically, like if they need a feature or they need a customization in this way then I am very open to those. And I sort of set it up to make it clear from the beginning that this is not just a free thing on GitHub, this is something that you could pay for if you need help with it, if you need support, if you wanted it. I'm also a little cagey about the word support because I think like it sounds a little bit too wishy-washy. Pretty much like if you need access to the developers of an open source project, I think that's something that businesses are willing to pay for. And I think like making that clear to potential users is a challenge. But I think that is one way that you might be able to make like a living out of open source. [00:26:35] Jeremy: And I think you said you'd been working on it for about five years. Has that mostly been full time? [00:26:42] Brandon: It's been on and off. it's sort of my pandemic era project. But I've spent a lot of time, most of my time working on the open source project at this point. So I have done some things that were more just like I'm doing a customization or like a private deployment for some client. But that's been a minority of the time. Yeah. [00:27:03] Jeremy: It's still impressive to have an open source project that is easy to self-host and yet is still able to support you working on it full time. I think a lot of people might make the assumption that there's nothing to sell if something is, is easy to use. But this sort of sounds like a counterpoint to that. [00:27:25] Brandon: I think I'd like it to be. So when you come back to the point of like, it being easy to self-host. Well, so again, like I think about it as like a primitive of the web. Like for example, if you wanted to start a business today as like hosted CSS files, you know, like where you upload your CSS and then you get developers to pay you a monthly subscription for how many times they fetched a CSS file. Well, I think most developers would be like, that's stupid because it's just an open specification, you just upload a static file. And really my goal is to make Protomaps the same way where it's obvious that there's not really some sort of lock-in or some sort of secret sauce in the server that does this thing. How PMTiles works and building a primitive of the web [00:28:16] Brandon: If you look at video for example, like a lot of the tech for how Protomaps and PMTiles works is based on parts of the HTTP spec that were made for video. And 20 years ago, if you wanted to host a video on the web, you had to have like a real player license or flash. So you had to go license some server software from real media or from macromedia so you could stream video to a browser plugin. But now in HTML you can just embed a video file. And no one's like, oh well I need to go pay for my video serving license. I mean, there is such a thing, like YouTube doesn't really use that for DRM reasons, but people just have the assumption that video is like a primitive on the web. So if we're able to make maps sort of that same way like a primitive on the web then there isn't really some obvious business or licensing model behind how that works. Just because it's a thing and it helps a lot of people do their jobs and people are happy using it. So why bother? [00:29:26] Jeremy: You mentioned that it a tech that was used for streaming video. What tech specifically is it? [00:29:34] Brandon: So it is byte range serving. So when you open a video file on the web, So let's say it's like a 100 megabyte video. You don't have to download the entire video before it starts playing. It streams parts out of the file based on like what frames... I mean, it's based on the frames in the video. So it can start streaming immediately because it's organized in a way to where the first few frames are at the beginning. And what PMTiles really is, is it's just like a video but in space instead of time. So it's organized in a way where these zoomed out views are at the beginning and the most zoomed in views are at the end. So when you're like panning or zooming in the map all you're really doing is fetching byte ranges out of that file the same way as a video. But it's organized in, this tiled way on a space filling curve. IIt's a little bit complicated how it works internally and I think it's kind of cool but that's sort of an like an implementation detail. [00:30:35] Jeremy: And to the person deploying it, it just looks like a single file. [00:30:40] Brandon: Exactly in the same way like an mp3 audio file is or like a JSON file is. [00:30:47] Jeremy: So with a video, I can sort of see how as someone seeks through the video, they start at the beginning and then they go to the middle if they wanna see the middle. For a map, as somebody scrolls around the map, are you seeking all over the file or is the way it's structured have a little less chaos? [00:31:09] Brandon: It's structured. And that's kind of the main technical challenge behind building PMTiles is you have to be sort of clever so you're not spraying the reads everywhere. So it uses something called a hilbert curve, which is a mathematical concept of a space filling curve. Where it's one continuous curve that essentially lets you break 2D space into 1D space. So if you've seen some maps of IP space, it uses this crazy looking curve that hits all the points in one continuous line. And that's the same concept behind PMTiles is if you're looking at one part of the world, you're sort of guaranteed that all of those parts you're looking at are quite close to each other and the data you have to transfer is quite minimal, compared to if you just had it at random. [00:32:02] Jeremy: How big do the files get? If I have a PMTiles of the entire world, what kind of size am I looking at? [00:32:10] Brandon: Right now, the default one I distribute is 128 gigabytes, so it's quite sizable, although you can slice parts out of it remotely. So if you just wanted. if you just wanted California or just wanted LA or just wanted only a couple of zoom levels, like from zero to 10 instead of zero to 15, there is a command line tool that's also called PMTiles that lets you do that. Issues with CDNs and range queries [00:32:35] Jeremy: And when you're working with files of this size, I mean, let's say I am working with a CDN in front of my application. I'm not typically accustomed to hosting something that's that large and something that's where you're seeking all over the file. is that, ever an issue or is that something that's just taken care of by the browser and, and taken care of by, by the hosts? [00:32:58] Brandon: That is an issue actually, so a lot of CDNs don't deal with it correctly. And my recommendation is there is a kind of proxy server or like a serverless proxy thing that I wrote. That runs on like cloudflare workers or on Docker that lets you proxy those range requests into a normal URL and then that is like a hundred percent CDN compatible. So I would say like a lot of the big commercial installations of this thing, they use that because it makes more practical sense. It's also faster. But the idea is that this solution sort of scales up and scales down. If you wanted to host just your city in like a 10 megabyte file, well you can just put that into GitHub pages and you don't have to worry about it. If you want to have a global map for your website that serves a ton of traffic then you probably want a little bit more sophisticated of a solution. It still does not require you to run a Linux server, but it might require (you) to use like Lambda or Lambda in conjunction with like a CDN. [00:34:09] Jeremy: Yeah. And that sort of ties into what you were saying at the beginning where if you can host on something like CloudFlare Workers or Lambda, there's less time you have to spend keeping these things running. [00:34:26] Brandon: Yeah, exactly. and I think also the Lambda or CloudFlare workers solution is not perfect. It's not as perfect as S3 or as just static files, but in my experience, it still is better at building something that lasts on the time span of years than being like I have a server that is on this Ubuntu version and in four years there's all these like security patches that are not being applied. So it's still sort of serverless, although not totally vendor neutral like S3. Customizing the map [00:35:03] Jeremy: We've mostly been talking about how you host the map itself, but for someone who's not familiar with these kind of tools, how would they be customizing the map? [00:35:15] Brandon: For customizing the map there is front end style customization and there's also data customization. So for the front end if you wanted to change the water from the shade of blue to another shade of blue there is a TypeScript API where you can customize it almost like a text editor color scheme. So if you're able to name a bunch of colors, well you can customize the map in that way you can change the fonts. And that's all done using MapLibre GL using a TypeScript API on top of that for customizing the data. So all the pipeline to generate this data from OpenStreetMap is open source. There is a Java program using a library called PlanetTiler which is awesome, which is this super fast multi-core way of building map tiles. And right now there isn't really great hooks to customize what data goes into that. But that's something that I do wanna work on. And finally, because the data comes from OpenStreetMap if you notice data that's missing or you wanted to correct data in OSM then you can go into osm.org. You can get involved in contributing the data to OSM and the Protomaps build is daily. So if you make a change, then within 24 hours you should see the new base map. Have that change. And of course for OSM your improvements would go into every OSM based project that is ingesting that data. So it's not a protomap specific thing. It's like this big shared data source, almost like Wikipedia. OpenStreetMap is a dataset and not a map [00:37:01] Jeremy: I think you were involved with OpenStreetMap to some extent. Can you speak a little bit to that for people who aren't familiar, what OpenStreetMap is? [00:37:11] Brandon: Right. So I've been using OSM as sort of like a tools developer for over a decade now. And one of the number one questions I get from developers about what is Protomaps is why wouldn't I just use OpenStreetMap? What's the distinction between Protomaps and OpenStreetMap? And it's sort of like this funny thing because even though OSM has map in the name it's not really a map in that you can't... In that it's mostly a data set and not a map. It does have a map that you can see that you can pan around to when you go to the website but the way that thing they show you on the website is built is not really that easily reproducible. It involves a lot of c++ software you have to run. But OpenStreetMap itself, the heart of it is almost like a big XML file that has all the data in the map and global. And it has tagged features for example. So you can go in and edit that. It has a web front end to change the data. It does not directly translate into making a map actually. Protomaps decides what shows at each zoom level [00:38:24] Brandon: So a lot of the pipeline, that Java program I mentioned for building this basemap for protomaps is doing things like you have to choose what data you show when you zoom out. You can't show all the data. For example when you're zoomed out and you're looking at all of a state like Colorado you don't see all the Chipotle when you're zoomed all the way out. That'd be weird, right? So you have to make some sort of decision in logic that says this data only shows up at this zoom level. And that's really what is the challenge in optimizing the size of that for the Protomaps map project. [00:39:03] Jeremy: Oh, so those decisions of what to show at different Zoom levels those are decisions made by you when you're creating the PMTiles file with Protomaps. [00:39:14] Brandon: Exactly. It's part of the base maps build pipeline. and those are honestly very subjective decisions. Who really decides when you're zoomed out should this hospital show up or should this museum show up nowadays in Google, I think it shows you ads. Like if someone pays for their car repair shop to show up when you're zoomed out like that that gets surfaced. But because there is no advertising auction in Protomaps that doesn't happen obviously. So we have to sort of make some reasonable choice. A lot of that right now in Protomaps actually comes from another open source project called Mapzen. So Mapzen was a company that went outta business a couple years ago. They did a lot of this work in designing which data shows up at which Zoom level and open sourced it. And then when they shut down, they transferred that code into the Linux Foundation. So it's this totally open source project, that like, again, sort of like Mapbox gl has this awesome legacy in that this company funded it for years for smart people to work on it and now it's just like a free thing you can use. So the logic in Protomaps is really based on mapzen. [00:40:33] Jeremy: And so the visualization of all this... I think I understand what you mean when people say oh, why not use OpenStreetMaps because it's not really clear it's hard to tell is this the tool that's visualizing the data? Is it the data itself? So in the case of using Protomaps, it sounds like Protomaps itself has all of the data from OpenStreetMap and then it has made all the decisions for you in terms of what to show at different Zoom levels and what things to have on the map at all. And then finally, you have to have a separate, UI layer and in this case, it sounds like the one that you recommend is the Map Libre library. [00:41:18] Brandon: Yeah, that's exactly right. For Protomaps, it has a portion or a subset of OSM data. It doesn't have all of it just because there's too much, like there's data in there. people have mapped out different bushes and I don't include that in Protomaps if you wanted to go in and edit like the Java code to add that you can. But really what Protomaps is positioned at is sort of a solution for developers that want to use OSM data to make a map on their app or their website. because OpenStreetMap itself is mostly a data set, it does not really go all the way to having an end-to-end solution. Financials and the idea of a project being complete [00:41:59] Jeremy: So I think it's great that somebody who wants to make a map, they have these tools available, whether it's from what was originally built by Mapbox, what's built by Open StreetMap now, the work you're doing with Protomaps. But I wonder one of the things that I talked about with Tom was he was saying he was trying to build this mapping business and based on the financials of what was coming in he was stressed, right? He was struggling a bit. And I wonder for you, you've been working on this open source project for five years. Do you have similar stressors or do you feel like I could keep going how things are now and I feel comfortable? [00:42:46] Brandon: So I wouldn't say I'm a hundred percent in one bucket or the other. I'm still seeing it play out. One thing, that I really respect in a lot of open source projects, which I'm not saying I'm gonna do for Protomaps is the idea that a project is like finished. I think that is amazing. If a software project can just be done it's sort of like a painting or a novel once you write, finish the last page, have it seen by the editor. I send it off to the press is you're done with a book. And I think one of the pains of software is so few of us can actually do that. And I don't know obviously people will say oh the map is never finished. That's more true of OSM, but I think like for Protomaps. One thing I'm thinking about is how to limit the scope to something that's quite narrow to where we could be feature complete on the core things in the near term timeframe. That means that it does not address a lot of things that people want. Like search, like if you go to Google Maps and you search for a restaurant, you will get some hits. that's like a geocoding issue. And I've already decided that's totally outta scope for Protomaps. So, in terms of trying to think about the future of this, I'm mostly looking for ways to cut scope if possible. There are some things like better tooling around being able to work with PMTiles that are on the roadmap. but for me, I am still enjoying working on the project. It's definitely growing. So I can see on NPM downloads I can see the growth curve of people using it and that's really cool. So I like hearing about when people are using it for cool projects. So it seems to still be going okay for now. [00:44:44] Jeremy: Yeah, that's an interesting perspective about how you were talking about projects being done. Because I think when people look at GitHub projects and they go like, oh, the last commit was X months ago. They go oh well this is dead right? But maybe that's the wrong framing. Maybe you can get a project to a point where it's like, oh, it's because it doesn't need to be updated. [00:45:07] Brandon: Exactly, yeah. Like I used to do a lot of c++ programming and the best part is when you see some LAPACK matrix math library from like 1995 that still works perfectly in c++ and you're like, this is awesome. This is the one I have to use. But if you're like trying to use some like React component library and it hasn't been updated in like a year, you're like, oh, that's a problem. So again, I think there's some middle ground between those that I'm trying to find. I do like for Protomaps, it's quite dependency light in terms of the number of hard dependencies I have in software. but I do still feel like there is a lot of work to be done in terms of project scope that needs to have stuff added. You mostly only hear about problems instead of people's wins [00:45:54] Jeremy: Having run it for this long. Do you have any thoughts on running an open source project in general? On dealing with issues or managing what to work on things like that? [00:46:07] Brandon: Yeah. So I have a lot. I think one thing people point out a lot is that especially because I don't have a direct relationship with a lot of the people using it a lot of times I don't even know that they're using it. Someone sent me a message saying hey, have you seen flickr.com, like the photo site? And I'm like, no. And I went to flickr.com/map and it has Protomaps for it. And I'm like, I had no idea. But that's cool, if they're able to use Protomaps for this giant photo sharing site that's awesome. But that also means I don't really hear about when people use it successfully because you just don't know, I guess they, NPM installed it and it works perfectly and you never hear about it. You only hear about people's negative experiences. You only hear about people that come and open GitHub issues saying this is totally broken, and why doesn't this thing exist? And I'm like, well, it's because there's an infinite amount of things that I want to do, but I have a finite amount of time and I just haven't gone into that yet. And that's honestly a lot of the things and people are like when is this thing gonna be done? So that's, that's honestly part of why I don't have a public roadmap because I want to avoid that sort of bickering about it. I would say that's one of my biggest frustrations with running an open source project is how it's self-selected to only hear the negative experiences with it. Be careful what PRs you accept [00:47:32] Brandon: 'cause you don't hear about those times where it works. I'd say another thing is it's changed my perspective on contributing to open source because I think when I was younger or before I had become a maintainer I would open a pull request on a project unprompted that has a hundred lines and I'd be like, Hey, just merge this thing. But I didn't realize when I was younger well if I just merge it and I disappear, then the maintainer is stuck with what I did forever. You know if I add some feature then that person that maintains the project has to do that indefinitely. And I think that's very asymmetrical and it's changed my perspective a lot on accepting open source contributions. I wanna have it be open to anyone to contribute. But there is some amount of back and forth where it's almost like the default answer for should I accept a PR is no by default because you're the one maintaining it. And do you understand the shape of that solution completely to where you're going to support it for years because the person that's contributing it is not bound to those same obligations that you are. And I think that's also one of the things where I have a lot of trepidation around open source is I used to think of it as a lot more bazaar-like in terms of anyone can just throw their thing in. But then that creates a lot of problems for the people who are expected out of social obligation to continue this thing indefinitely. [00:49:23] Jeremy: Yeah, I can totally see why that causes burnout with a lot of open source maintainers, because you probably to some extent maybe even feel some guilt right? You're like, well, somebody took the time to make this. But then like you said you have to spend a lot of time trying to figure out is this something I wanna maintain long term? And one wrong move and it's like, well, it's in here now. [00:49:53] Brandon: Exactly. To me, I think that is a very common failure mode for open source projects is they're too liberal in the things they accept. And that's a lot of why I was talking about how that choice of what features show up on the map was inherited from the MapZen projects. If I didn't have that then somebody could come in and say hey, you know, I want to show power lines on the map. And they open a PR for power lines and now everybody who's using Protomaps when they're like zoomed out they see power lines are like I didn't want that. So I think that's part of why a lot of open source projects eventually evolve into a plugin system is because there is this demand as the project grows for more and more features. But there is a limit in the maintainers. It's like the demand for features is exponential while the maintainer amount of time and effort is linear. Plugin systems might reduce need for PRs [00:50:56] Brandon: So maybe the solution to smash that exponential down to quadratic maybe is to add a plugin system. But I think that is one of the biggest tensions that only became obvious to me after working on this for a couple of years. [00:51:14] Jeremy: Is that something you're considering doing now? [00:51:18] Brandon: Is the plugin system? Yeah. I think for the data customization, I eventually wanted to have some sort of programmatic API to where you could declare a config file that says I want ski routes. It totally makes sense. The power lines example is maybe a little bit obscure but for example like a skiing app and you want to be able to show ski slopes when you're zoomed out well you're not gonna be able to get that from Mapbox or from Google because they have a one size fits all map that's not specialized to skiing or to golfing or to outdoors. But if you like, in theory, you could do this with Protomaps if you changed the Java code to show data at different zoom levels. And that is to me what makes the most sense for a plugin system and also makes the most product sense because it enables a lot of things you cannot do with the one size fits all map. [00:52:20] Jeremy: It might also increase the complexity of the implementation though, right? [00:52:25] Brandon: Yeah, exactly. So that's like. That's really where a lot of the terrifying thoughts come in, which is like once you create this like config file surface area, well what does that look like? Is that JSON? Is that TOML, is that some weird like everything eventually evolves into some scripting language right? Where you have logic inside of your templates and I honestly do not really know what that looks like right now. That feels like something in the medium term roadmap. [00:52:58] Jeremy: Yeah and then in terms of bug reports or issues, now it's not just your code it's this exponential combination of whatever people put into these config files. [00:53:09] Brandon: Exactly. Yeah. so again, like I really respect the projects that have done this well or that have done plugins well. I'm trying to think of some, I think obsidian has plugins, for example. And that seems to be one of the few solutions to try and satisfy the infinite desire for features with the limited amount of maintainer time. Time split between code vs triage vs talking to users [00:53:36] Jeremy: How would you say your time is split between working on the code versus issue and PR triage? [00:53:43] Brandon: Oh, it varies really. I think working on the code is like a minority of it. I think something that I actually enjoy is talking to people, talking to users, getting feedback on it. I go to quite a few conferences to talk to developers or people that are interested and figure out how to refine the message, how to make it clearer to people, like what this is for. And I would say maybe a plurality of my time is spent dealing with non-technical things that are neither code or GitHub issues. One thing I've been trying to do recently is talk to people that are not really in the mapping space. For example, people that work for newspapers like a lot of them are front end developers and if you ask them to run a Linux server they're like I have no idea. But that really is like one of the best target audiences for Protomaps. So I'd say a lot of the reality of running an open source project is a lot like a business is it has all the same challenges as a business in terms of you have to figure out what is the thing you're offering. You have to deal with people using it. You have to deal with feedback, you have to deal with managing emails and stuff. I don't think the payoff is anywhere near running a business or a startup that's backed by VC money is but it's definitely not the case that if you just want to code, you should start an open source project because I think a lot of the work for an opensource project has nothing to do with just writing the code. It is in my opinion as someone having done a VC backed business before, it is a lot more similar to running, a tech company than just putting some code on GitHub. Running a startup vs open source project [00:55:43] Jeremy: Well, since you've done both at a high level what did you like about running the company versus maintaining the open source project? [00:55:52] Brandon: So I have done some venture capital accelerator programs before and I think there is an element of hype and energy that you get from that that is self perpetuating. Your co-founder is gungho on like, yeah, we're gonna do this thing. And your investors are like, you guys are geniuses. You guys are gonna make a killing doing this thing. And the way it's framed is sort of obvious to everyone that it's like there's a much more traditional set of motivations behind that, that people understand while it's definitely not the case for running an open source project. Sometimes you just wake up and you're like what the hell is this thing for, it is this thing you spend a lot of time on. You don't even know who's using it. The people that use it and make a bunch of money off of it they know nothing about it. And you know, it's just like cool. And then you only hear from people that are complaining about it. And I think like that's honestly discouraging compared to the more clear energy and clearer motivation and vision behind how most people think about a company. But what I like about the open source project is just the lack of those constraints you know? Where you have a mandate that you need to have this many customers that are paying by this amount of time. There's that sort of pressure on delivering a business result instead of just making something that you're proud of that's simple to use and has like an elegant design. I think that's really a difference in motivation as well. Having control [00:57:50] Jeremy: Do you feel like you have more control? Like you mentioned how you've decided I'm not gonna make a public roadmap. I'm the sole developer. I get to decide what goes in. What doesn't. Do you feel like you have more control in your current position than you did running the startup? [00:58:10] Brandon: Definitely for sure. Like that agency is what I value the most. It is possible to go too far. Like, so I'm very wary of the BDFL title, which I think is how a lot of open source projects succeed. But I think there is some element of for a project to succeed there has to be somebody that makes those decisions. Sometimes those decisions will be wrong and then hopefully they can be rectified. But I think going back to what I was talking about with scope, I think the overall vision and the scope of the project is something that I am very opinionated about in that it should do these things. It shouldn't do these things. It should be easy to use for this audience. Is it gonna be appealing to this other audience? I don't know. And I think that is really one of the most important parts of that leadership role, is having the power to decide we're doing this, we're not doing this. I would hope other developers would be able to get on board if they're able to make good use of the project, if they use it for their company, if they use it for their business, if they just think the project is cool. So there are other contributors at this point and I want to get more involved. But I think being able to make those decisions to what I believe is going to be the best project is something that is very special about open source, that isn't necessarily true about running like a SaaS business. [00:59:50] Jeremy: I think that's a good spot to end it on, so if people want to learn more about Protomaps or they wanna see what you're up to, where should they head? [01:00:00] Brandon: So you can go to Protomaps.com, GitHub, or you can find me or Protomaps on bluesky or Mastodon. [01:00:09] Jeremy: All right, Brandon, thank you so much for chatting today. [01:00:12] Brandon: Great. Thank you very much.

Fredrik och Kristoffer snackar Coolify och Hetzner. Kristoffer hjälper Fredrik förstå vad man vill ha Coolify till och vad det egentligen är. Man måste ha en viss kunskap, eller i alla fall vara intresserad av läsa på och skaffa sig kunskap. Coolify är inte säkert nog direkt ur lådan. Fredrik funderar på att byta tjänst för mejl. Konsensus verkar vara att mejl är en tjänst man kanske ändå inte vill ha hos Hetzner. Vi diskuterar också modern C++ och dess framtid en sväng, för att sedan prata om Coolifys svagare sidor: det är mycket att sätta sig in i, och inte alltid superstark dokumentation. Sist men inte minst, ett litet inspel om Roq och ett löfte om ett framtida ämne. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @thieta, @krig, och @bjoreman på Mastodon, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Delta i den tolfte spelsylten! - 7 - 20 april 2025 Coolify Kuzzle Dozzle - monitorerar och loggar containrar Odoo Fler tjänster man kan köra i Coolify ERP - enterprise resource planning CRM - customer relationship management Coolest cooler Space monkey - delad molnlagring på NAS-diskar, ungefär. Kickstarterkampanjen har fina bilder Syncthing Hur Dropbox började Boring cash cow S3 Sqlite CRDT Kristoffers företagssida Reverse proxy Heroku Coolifys guide för att ställa in lastbalansering på Hetzner Hetzners Coolifydokumentation cloud-init Fastmail Glesys och mejl Stöd oss på Ko-fi! Zig Bjarne Stroustrup Artikeln om problem med C++ av Izzy Muerte Herb Sutter Profiler i C++ Nginx Caddy Traefik Coolify cloud Infisical - hemlighetshantering Beszel - övervakning Ghost Writefreely Nixpacks UWSGI Roq Software unscripted Feldman håller presentation där han skriver hårt typat backend med JSON-stöd Durable execution Titlar Zzle-ändelsen Enterprisesoftware på min Coolify En mörk skog därute full av monster Fylld av monster Du sköter DNS:en själv Terminalknappen Infarfarerad Ett användbart monster C++ the good parts Ett rum fullt med pistoler Vibe-deploya Coolify Tyskt technoband från nittiotalet Det här är sunk Monstermejl på Hetzner Zig är ju coolare än Rust Inferensen är komplett

Efter att vi rett ut skillnaden på ett flygplan och ett däggdjur så snackar vi om att Anton nu hostar massa tjänster på en VPS hos Hetzner, singel singel, XaaS-förvirring, magi, nån typ av brandvägg och att tilltalas av praktik. Dessutom en Shakespearsk historia i tre akter, att klicka sig fram, 2+ namnet Coolify och mycket annat. Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram

Auphonic (click here to comment) 25. Februar 2025, Jochen

Was steckt hinter den unerklärlichen Account- und Produktsperrungen bei Amazon? Gemeinsam mit Ruben Astorgano von ERZ-Consulting versprechen wir Antworten auf diese brennende Frage zu finden. Ruben teilt spannende Einblicke aus seiner langjährigen Erfahrung und beleuchtet die möglichen Gründe für den plötzlichen Anstieg solcher Fälle, besonders im Januar. Könnte Amazon tatsächlich neue KI-Technologien zur Verwaltung dieser Sperrungen testen? Erfahren Sie mehr über die Bedeutung, den Ursachen auf den Grund zu gehen, um schnellstmöglich effektive Lösungen zu entwickeln. Wie optimiert Amazon seine Supportstrukturen, um komplexe Anfragen effizient zu bearbeiten? Entdecken Sie die Vor- und Nachteile ihrer One-Pager-Politik im internen Kommunikationsfluss und wie spezialisierte Teams in der Werbung helfen, den Service zu verbessern. Ruben und wir diskutieren, wie Motivation und Spezialisierung Barrieren abbauen und einen bedeutenden Einfluss auf den finanziellen Erfolg haben können. Lassen Sie sich inspirieren von den Strategien, die selbst bei großen Unternehmen wie Hetzner zu exzellentem Support führen. Was sind die effektivsten Strategien zur Problemlösung im Kundenservice? Wir geben Ihnen praktische Tipps an die Hand, wie man Anfragen klar strukturiert und mit Emotionen in der Kommunikation umgeht. Erfahren Sie, wie künstliche Intelligenz, wie beispielsweise ChatGPT, helfen kann, den Fokus auf das Wesentliche zu legen. Und werfen Sie mit uns einen Blick auf die internationale Expansion bei Amazon – von den Chancen in weniger beachteten Märkten wie Saudi-Arabien bis hin zu den Tücken überlaufener Märkte. Verpassen Sie nicht die wertvollen Einblicke und Strategien, die Ruben und wir in dieser Episode teilen! In Folge 167 des Serious Sellers Podcast auf Deutsch, Marcus und Ruben diskutiére 00:00 - Problemlösung Bei Amazon-Sperrungen 12:13 - Support-Erfahrungen Und Problemlösungen 17:59 - Effiziente Problemlösung Und Supportstrategien 27:55 - Internationale Expansion Auf Amazon 34:37 - Keyword-Optimierung Und Networkingstrategien

Today we continue our journey from last week where we spun up a Hetzner cloud server and Ludus.cloud SCCM pentesting range!  Topics include: Building a Proxmox Backup Server (this YouTube video was super helpful) Bridging a second WAN IP to the Hetzner/Ludus server Wrestling with the Hetzner (10-rule limit!) software firewall When attacking SCCM – you can get a version of pxethief that runs in Linux!

I had an absolute ball this week spinning up my first Hetzner server, though it was not without some drama (firewall config frustrations and failing hard drives).  Once I got past that, though, I got my first taste of the amazing world of Ludus.cloud, where I spun up a vulnerable Microsoft SCCM lab and have started to pwn it.  Can't say enough good things about Ludus.cloud, but I certainly tried in this episode!

If you are a .NET developer or work in a place that has some of those folks, wouldn't it be great to fully leverage the entirety of PyPI with it's almost 600,000 packages inside your .NET code? But how would you do this? Previous efforts have let you write Python syntax but using the full libraries (especially the C-based ones) has been out of reach, until CSnakes. This project by Anthony Shaw and Aaron Powell unlocks some pretty serious integration between the two languages. We have them both here on the show today to tell us all about it. Episode sponsors Posit Bluehost Talk Python Courses Links from the show Anthony Shaw: github.com Aaron Powell: github.com Introducing CSnakes: tonybaloney.github.io CSnakes: tonybaloney.github.io Talk Python: We've moved to Hetzner: talkpython.fm/blog Talk Python: Talk Python rewritten in Quart (async Flask): talkpython.fm/blog Pyjion - A JIT for Python based upon CoreCLR: github.com Iron Python: ironpython.net Python.NET: pythonnet.github.io The buffer protocol: docs.python.org Avalonia UI: avaloniaui.net Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy

Topics covered in this episode: terminal-tree posting: The API client that lives in your terminal Extra, extra, extra UV does everything or enough that I'm not sure what else it needs to do Extras Joke Watch on YouTube About the show Sponsored by: ScoutAPM - Django Application Performance Monitoring Codeium - Free AI Code Completion & Chat Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Michael #1: terminal-tree An experimental filesystem navigator for the terminal, built with Textual Tested in macOS only at this point. Chances are very high it works on Linux. Slightly lower chance (but non-zero) that it works on Windows. Can confirm it works on Linux Brian #2: posting: The API client that lives in your terminal Also uses Textual From Darren Burns Interesting that the installation instructions recommends using uv: uv tool install --python 3.12 posting Very cool. Great docs. Beautiful. keyboard centric, but also usable with a mouse. “Fly through your API workflow with an approachable yet powerful keyboard-centric interface. Run it locally or over SSH on remote machines and containers. Save your requests in a readable and version-control friendly format.” Able to save multiple environments Great colors Allows scripting to run Python code before and after requests to prepare headers, set variables, etc. Michael #3: Extra, extra, extra spaCy course swag give-away, enter for free New essay: Opposite of Cloud Native is? News: We've moved to Hetzner New package: Introducing chameleon-flask package New release: Listmonk Python client TIOBE Update PEP 750 – Template Strings Canary email Left Omnivore, for Pocket, left Pocket for, …, landed on Instapaper Supports direct import from Omnivore and Pocket Though Hoarder is compelling Trying out Zen Browser Wasn't a fan of Arc (especially now) but the news turned me on to Zen Brian #4: UV does everything or enough that I'm not sure what else it needs to do Jeff Triplett “UV feels like one of those old infomercials where it solves everything, which is where we have landed in the Python world.” “My favorite feature is that UV can now bootstrap a project to run on a machine that does not previously have Python installed, along with installing any packages your application might require.” Partial list (see Jeff's post for his complete list) uv pip install replaces pip install uv venv replaces python -m venv uv run, uv tool run, and uv tool install replaces pipx uv build - Build your Python package for pypi uv publish - Upload your Python package to pypi, replacing twine and flit publish Extras Brian: Coverage.py originally was just one file Trying out BlueSky brianokken.bsky.social Not because of Taylor Swift, but nice. There are a lot of Python people there. Joke: How programmers sleep

Willkommen im nerdcafe. Dein Haus baust du ja auch nicht auf matschigem Grund, oder? Das Hosting der Website ist gleichzeitig das am meisten unterschätzte und mit am wichtigsten Thema. Denn das passende Hosting ist die Grundlage für das gesamte Web-Projekt und es macht sehr viel Sinn, sich hier vorher einige Gedanken zu machen und nicht am falschen Ende zu sparen. Du lernst, welche verschiedenen Varianten von Hosting es gibt und warum die Wahl des passenden Hosting sehr individuell ist. Du bekommst Tipps an die Hand, worauf du achten solltest, wenn du dich für ein Hosting entscheiden musst. Einen allgemein gültigen und für alle passenden Tipp zum richtigen Hosting gibt es nicht - Aber dafür gebe ich dir einen Antitipp, von welchem Hoster du die Finger lassen solltest. Was ist das nerdcafe? Hier geht es um WordPress, Hosting, Content Management Systeme und Web-Themen. Aber natürlich auch um Sicherheit, Backup und Social Media. Kurz gesagt: Um alles, was dich interessiert, wenn du mit deinem eigenen Webseite Projekt starten möchtest. ⏰ Neue reguläre Episoden erscheinen jeden Dienstag um 7:00 Uhr Die nerdcafe to go Variante erscheint unregelmäßig, spontan und meist von unterwegs. Das nerdcafe live findet Donnerstags bei LinkedIn live statt - alle Themen und Termine auf meinem Profil ☕ Machs dir gemütlich und komm gern dazu. Viel Spaß im nerdcafe. Weiterführende Episoden: Episode 004 - Was kostet WordPress? Episode 013 - WordPress Sicherheit Weiterführende Links zur Folge: https://johannesmairhofer.de/blog/das-beste-hosting-fuer-wordpress/ https://johannesmairhofer.de/blog/was-kostet-wordpress/ Mit deinem aktuellen Hosting unzufrieden? Ich helfe dir beim Umzug https://johannesmairhofer.de/blog/umzugsservice-und-hosting-wechsel/ Hoster, die ich aus eigener oder Kund*innen-Erfahrung kenne. In alphabetischer Reihenfolge: All Inkl: https://all-inkl.com/ Hetzner: https://www.hetzner.com/ Raidboxes: https://raidboxes.io/

Topics covered in this episode: Open Source Pledge Jeff Triplet's DjangoTV PEP 735 – Dependency Groups in pyproject.toml livereload Extras Joke Watch on YouTube About the show Sponsored by ScoutAPM: pythonbytes.fm/scout Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Brian #1: Open Source Pledge Learned about this because of this post Why Django supports the Open Source Pledge Steps Pay Open Source maintainers. Min to participate is 2k/year/dev at your company Self-report annually Publish a blog post outlining your payments Armin's post about launching Open Source Pledge and mixing money with open source Michael #2: Jeff Triplet's DjangoTV A nice aggregation of lots of Django conference talks Filter by conference Good search as well Brian #3: PEP 735 – Dependency Groups in pyproject.toml Author: Stephen Rosen, Sponsor: Brett Cannon, PEP-Delegate: Paul Moore Accepted. Resolotion Oct 10, 2024 “This PEP specifies a mechanism for storing package requirements in pyproject.toml files such that they are not included in any built distribution of the project.” Allow us to define named groups of dependencies that can be independent of the main project. ex: [dependency-groups] test = ["pytest", "coverage"] docs = ["sphinx", "sphinx-rtd-theme"] typing = ["mypy", "types-requests"] typing-test = [{include-group = "typing"}, {include-group = "test"}, "useful-types"] “might” work like this: pip install --dependency-groups=test,typing but tool venders are able to define how they use groups. Of course. Similar solutions multiple requirements.txt files: requirements_test.txt, requirements_docs.txt, etc. no standard naming convention, not standardized package extras: not gauranteed to be statically defined (TIL) additional to main dependencies, so not independent Michael #4: livereload Example from talkpython.fm: asset_bundler_watcher.py The docs are sparse, so see the gist above Extras Brian: Personal Blogs are no longer personal when AI gets too involved - KJayMiller Mind Your Image Metadata - Stefanie Molin Michael: 14% of our listeners are in Germany, thanks Germany! Prost! Hetzner comes to the US Joke: A programmer's partner asks them: “Would you go get a loaf of bread from the store? And if they have eggs, get a dozen.” A while later, the programmer returns with 12 loaves of bread and says “They had eggs.” From https://savvyprogrammer.io/software-jokes/

Daten oder Software in der Cloud. Einfach, zentral und überall verfügbar. Und Serverkosten spart man sich auch noch. Das eine nicht durchdachte Entscheidung aber die Existenz Deiner Firma bedrohen kann, ist Dir vielleicht garnicht bewusst. Wir zeigen die Herausforderungen beim Einsatz von Cloudlösungen auf und was man im Vorfeld berücksichtigen sollte. Shownotes:

In this episode of Remote Ruby, Jason and Chris catch up with a discussion on setting up a home office with new furniture, organizing hardware with a 3D printer, and dealing with nostalgia for old video games.Then they delve into technical issues faced with the Postgres database on DigitalOcean, migrating to Crunchy Data, and adjusting web concurrency settings in Rails. They also share their experiences experimenting with Kamal for server deployment, the complexities of AWS configuration, and using DigitalOcean and Hetzner for app instances.The conversation shifts to performance and error monitoring with Honeybadger Insights, the challenges of using Docker, and the potential of Kamal in streamlining deployments. They also touch upon the convenience of Passenger for beginners, and the key differences between Passenger and Sidekiq in terms of usage and business model.The episode wraps up with a discussion on the importance of investing in a good office chair and mentions the Honeybadger integration for monitoring periodic jobs. Jason Charnes X/TwitterChris Oliver X/TwitterAndrew Mason X/TwitterKamal 1.7.1SaaS Custom DomainsDigitalOceanOrbStackCrunchy DataHetznerNew RelicSentryPassengerSidekiqHoneybadger InsightsHoneybadger Check-ins and Cron MonitoringHerman MillerHoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you. Jason Charnes X/Twitter Chris Oliver X/Twitter Andrew Mason X/Twitter

This week was a duality of extremes for me. On one hand, I experienced an unprecedented growth spurt in my user numbers, while on the other hand, I stumbled into frustrating scarcity and infrastructure problems. That's entrepreneurship for you: big wins while struggling to not lose control of the whole thing.The juxtaposition of these two experiences in a single week was both challenging and enlightening. Today, I want to share the story of navigating the good and the bad simultaneously.This episode is sponsored by Acquire.comThe blog post: https://tbf.fm/episodes/330-50-new-users-overnight-and-a-burning-serverThe podcast episode: https://thebootstrappedfounder.com/50-percent-new-users-overnight-and-a-burning-serverCheck out Podscan to get alerts when you're mentioned on podcasts: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

TWiGS host Chris Adams is joined by Asim Hussain the executive director of the GSF to talk about the recent hackathon hosted by the GSF : Carbon Hack 24. Asim goes through some of his favourite projects that featured work with the Impact Framework including some surprising choices! They also cover some interesting news from the world of cloud service providers and the new CSDDD developments. Asim also talks about how mushrooms are out and bread is in!

It started as a normal day — but then things started going wrong. And my stress levels rose.But I recently learned how to use that to my advantage. Here's how I wrangled with a SaaS founder's worst nightmare, what happened, and how I turned the tables.  This episode is sponsored by Acquire.comThe blog post: https://thebootstrappedfounder.com/unexpected-downtime-stress-as-enhancement-vs-stress-as-panicThe podcast episode: https://tbf.fm/episodes/321-unexpected-downtime-stress-as-enhancement-vs-stress-as-panicCheck out Podscan to get alerts when you're mentioned on podcasts: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

Scott and Wes serve up answers to community questions, from navigating Light DOM vs. Shadow DOM to diving into tools for data extraction. Plus, they dish out insights on Gatsby in 2024, utilizing JavaScript ‘wheel events', and explore the possibilities of hosting a website at home. Show Notes 00:00 Welcome to Syntax! 00:51 Brought to you by Sentry.io. 01:17 When should I use Light DOM or Shadow DOM? 03:43 Do you know of any good tools for extracting data/content from Markup/HTML? LinkeDOM on GitHub 08:29 Wanted to ask you guys your opinion on the state of Gatsby in 2024. LocalFirst.fm MeteorJS UI Updates 15:05 Please get the Goodhertz creator on the pod! Would be a great show. Goodhertz Audio Software 16:34 Effects that involve the JavaScript ‘wheel' event. Runway.com GSAP Animate Anything CSS Scroll-Driven Animations 23:15 Best tool for rapidly creating UI from the ground up. Episode 751 Thinkmill.com 27:44 Wes, what's with your frame rate? Frame Rate Testing Results on X 32:31 Is there any way to host a whole website setting on my PC at home? CJ and Self-Host 101 Hetzner.com Cloudflare Docs Create a Tunnel 36:52 Offline functionality like saving data and syncing data to database? Episode 739 Local-First Web Development Syntax Side Dish Explainer Playlist 39:41 Creating a GPT-like tool that can listen to long audio files. OpenAI Speech to Text Insanely Fast Whisper Deepgram 43:51 Sick Picks. Sick Picks Scott: Hair Powder Wes: Mini Grease Gun Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott:X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

In dieser Episode sprechen Tom und André eingangs (wieder) über das Thema "Apple und EU". Danach geht es weiter mit Toms Erfahrungen zur VPN Lösung Tailscale und zum 1Password op Command Line Tool. Tesla überrascht seine Kunden regelmäßig mit neuen Features in deren Updates, dieses Mal erhielt Toms Tesla Model 3 mit dem adaptiven Fernlicht sogar ein neues Hardwarefeature. Zu guter Letzt gibt es noch ein paar kleinere Tipps zu Serien und Filmen.

Alex goes head-to-head with budget VPS providers, which gets us into a classic debate. Plus we sit down with Adam Morales from Unraid to get the inside scoop on recent changes and exciting upcoming features.

Wie kann man Spiele auch abseits der großen Engines wie Unity und Unreal erfolgreich entwickeln? Das besprechen wir mit Christoph Nakazawa, dem Entwickler hinter „Athena Crisis“, einem modernen, rundenbasierten Retro-Strategiespiel.Christoph erzählt uns, weshalb sich native und etablierte Web-Technologien wie HTML, CSS und JavaScript für die Spieleentwicklung anbieten. Er zeigt auf, worauf es dabei zu achten gilt. Wir beleuchten technische Vor- und Nachteile von JavaScript-Spiele-Engines und -Frameworks im Detail. Wir diskutieren, ob Canvas oder DOM-Elemente besser für komplexe Games geeignet sind.Dass Web-Technologien gegenüber „klassischer“ Spieleentwicklung Vorteile im Bereich Tooling und Distribution bieten und insbesondere für plattformübergreifende Spiele mit Multiplayer-Funktion geeignet sind, belegen wir in dieser Folge!Picks of the Day: Christoph: „Athena Crisis“-Discord-Community – In der Discord-Community zu seinem Spiel „Athena Crisis“ will Christoph Nakazawa nicht nur Support für alle Early-Access-Unterstützer:innen bieten, sondern im eigens dafür geschaffenen „#

We're writing this one day after the monster release of OpenAI's Sora and Gemini 1.5. We covered this on ‘s ThursdAI space, so head over there for our takes.IRL: We're ONE WEEK away from Latent Space: Final Frontiers, the second edition and anniversary of our first ever Latent Space event! Also: join us on June 25-27 for the biggest AI Engineer conference of the year!Online: All three Discord clubs are thriving. Join us every Wednesday/Friday!Almost 12 years ago, while working at Spotify, Erik Bernhardsson built one of the first open source vector databases, Annoy, based on ANN search. He also built Luigi, one of the predecessors to Airflow, which helps data teams orchestrate and execute data-intensive and long-running jobs. Surprisingly, he didn't start yet another vector database company, but instead in 2021 founded Modal, the “high-performance cloud for developers”. In 2022 they opened doors to developers after their seed round, and in 2023 announced their GA with a $16m Series A.More importantly, they have won fans among both household names like Ramp, Scale AI, Substack, and Cohere, and newer startups like (upcoming guest!) Suno.ai and individual hackers (Modal was the top tool of choice in the Vercel AI Accelerator):We've covered the nuances of GPU workloads, and how we need new developer tooling and runtimes for them (see our episodes with Chris Lattner of Modular and George Hotz of tiny to start). In this episode, we run through the major limitations of the actual infrastructure behind the clouds that run these models, and how Erik envisions the “postmodern data stack”. In his 2021 blog post “Software infrastructure 2.0: a wishlist”, Erik had “Truly serverless” as one of his points:* The word cluster is an anachronism to an end-user in the cloud! I'm already running things in the cloud where there's elastic resources available at any time. Why do I have to think about the underlying pool of resources? Just maintain it for me.* I don't ever want to provision anything in advance of load.* I don't want to pay for idle resources. Just let me pay for whatever resources I'm actually using.* Serverless doesn't mean it's a burstable VM that saves its instance state to disk during periods of idle.Swyx called this Self Provisioning Runtimes back in the day. Modal doesn't put you in YAML hell, preferring to colocate infra provisioning right next to the code that utilizes it, so you can just add GPU (and disk, and retries…):After 3 years, we finally have a big market push for this: running inference on generative models is going to be the killer app for serverless, for a few reasons:* AI models are stateless: even in conversational interfaces, each message generation is a fully-contained request to the LLM. There's no knowledge that is stored in the model itself between messages, which means that tear down / spin up of resources doesn't create any headaches with maintaining state.* Token-based pricing is better aligned with serverless infrastructure than fixed monthly costs of traditional software.* GPU scarcity makes it really expensive to have reserved instances that are available to you 24/7. It's much more convenient to build with a serverless-like infrastructure.In the episode we covered a lot more topics like maximizing GPU utilization, why Oracle Cloud rocks, and how Erik has never owned a TV in his life. Enjoy!Show Notes* Modal* ErikBot* Erik's Blog* Software Infra 2.0 Wishlist* Luigi* Annoy* Hetzner* CoreWeave* Cloudflare FaaS* Poolside AI* Modular Inference EngineChapters* [00:00:00] Introductions* [00:02:00] Erik's OSS work at Spotify: Annoy and Luigi* [00:06:22] Starting Modal* [00:07:54] Vision for a "postmodern data stack"* [00:10:43] Solving container cold start problems* [00:12:57] Designing Modal's Python SDK* [00:15:18] Self-Revisioning Runtime* [00:19:14] Truly Serverless Infrastructure* [00:20:52] Beyond model inference* [00:22:09] Tricks to maximize GPU utilization* [00:26:27] Differences in AI and data science workloads* [00:28:08] Modal vs Replicate vs Modular and lessons from Heroku's "graduation problem"* [00:34:12] Creating Erik's clone "ErikBot"* [00:37:43] Enabling massive parallelism across thousands of GPUs* [00:39:45] The Modal Sandbox for agents* [00:43:51] Thoughts on the AI Inference War* [00:49:18] Erik's best tweets* [00:51:57] Why buying hardware is a waste of money* [00:54:18] Erik's competitive programming backgrounds* [00:59:02] Why does Sweden have the best Counter Strike players?* [00:59:53] Never owning a car or TV* [01:00:21] Advice for infrastructure startupsTranscriptAlessio [00:00:00]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO-in-Residence at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:14]: Hey, and today we have in the studio Erik Bernhardsson from Modal. Welcome.Erik [00:00:19]: Hi. It's awesome being here.Swyx [00:00:20]: Yeah. Awesome seeing you in person. I've seen you online for a number of years as you were building on Modal and I think you're just making a San Francisco trip just to see people here, right? I've been to like two Modal events in San Francisco here.Erik [00:00:34]: Yeah, that's right. We're based in New York, so I figured sometimes I have to come out to capital of AI and make a presence.Swyx [00:00:40]: What do you think is the pros and cons of building in New York?Erik [00:00:45]: I mean, I never built anything elsewhere. I lived in New York the last 12 years. I love the city. Obviously, there's a lot more stuff going on here and there's a lot more customers and that's why I'm out here. I do feel like for me, where I am in life, I'm a very boring person. I kind of work hard and then I go home and hang out with my kids. I don't have time to go to events and meetups and stuff anyway. In that sense, New York is kind of nice. I walk to work every morning. It's like five minutes away from my apartment. It's very time efficient in that sense. Yeah.Swyx [00:01:10]: Yeah. It's also a good life. So we'll do a brief bio and then we'll talk about anything else that people should know about you. Actually, I was surprised to find out you're from Sweden. You went to college in KTH and your master's was in implementing a scalable music recommender system. Yeah.Erik [00:01:27]: I had no idea. Yeah. So I actually studied physics, but I grew up coding and I did a lot of programming competition and then as I was thinking about graduating, I got in touch with an obscure music streaming startup called Spotify, which was then like 30 people. And for some reason, I convinced them, why don't I just come and write a master's thesis with you and I'll do some cool collaborative filtering, despite not knowing anything about collaborative filtering really. But no one knew anything back then. So I spent six months at Spotify basically building a prototype of a music recommendation system and then turned that into a master's thesis. And then later when I graduated, I joined Spotify full time.Swyx [00:02:00]: So that was the start of your data career. You also wrote a couple of popular open source tooling while you were there. Is that correct?Erik [00:02:09]: No, that's right. I mean, I was at Spotify for seven years, so this is a long stint. And Spotify was a wild place early on and I mean, data space is also a wild place. I mean, it was like Hadoop cluster in the like foosball room on the floor. It was a lot of crude, like very basic infrastructure and I didn't know anything about it. And like I was hired to kind of figure out data stuff. And I started hacking on a recommendation system and then, you know, got sidetracked in a bunch of other stuff. I fixed a bunch of reporting things and set up A-B testing and started doing like business analytics and later got back to music recommendation system. And a lot of the infrastructure didn't really exist. Like there was like Hadoop back then, which is kind of bad and I don't miss it. But I spent a lot of time with that. As a part of that, I ended up building a workflow engine called Luigi, which is like briefly like somewhat like widely ended up being used by a bunch of companies. Sort of like, you know, kind of like Airflow, but like before Airflow. I think it did some things better, some things worse. I also built a vector database called Annoy, which is like for a while, it was actually quite widely used. In 2012, so it was like way before like all this like vector database stuff ended up happening. And funny enough, I was actually obsessed with like vectors back then. Like I was like, this is going to be huge. Like just give it like a few years. I didn't know it was going to take like nine years and then there's going to suddenly be like 20 startups doing vector databases in one year. So it did happen. In that sense, I was right. I'm glad I didn't start a startup in the vector database space. I would have started way too early. But yeah, that was, yeah, it was a fun seven years as part of it. It was a great culture, a great company.Swyx [00:03:32]: Yeah. Just to take a quick tangent on this vector database thing, because we probably won't revisit it but like, has anything architecturally changed in the last nine years?Erik [00:03:41]: I'm actually not following it like super closely. I think, you know, some of the best algorithms are still the same as like hierarchical navigable small world.Swyx [00:03:51]: Yeah. HNSW.Erik [00:03:52]: Exactly. I think now there's like product quantization, there's like some other stuff that I haven't really followed super closely. I mean, obviously, like back then it was like, you know, it's always like very simple. It's like a C++ library with Python bindings and you could mmap big files and into memory and like they had some lookups. I used like this kind of recursive, like hyperspace splitting strategy, which is not that good, but it sort of was good enough at that time. But I think a lot of like HNSW is still like what people generally use. Now of course, like databases are much better in the sense like to support like inserts and updates and stuff like that. I know I never supported that. Yeah, it's sort of exciting to finally see like vector databases becoming a thing.Swyx [00:04:30]: Yeah. Yeah. And then maybe one takeaway on most interesting lesson from Daniel Ek?Erik [00:04:36]: I mean, I think Daniel Ek, you know, he started Spotify very young. Like he was like 25, something like that. And that was like a good lesson. But like he, in a way, like I think he was a very good leader. Like there was never anything like, no scandals or like no, he wasn't very eccentric at all. It was just kind of like very like level headed, like just like ran the company very well, like never made any like obvious mistakes or I think it was like a few bets that maybe like in hindsight were like a little, you know, like took us, you know, too far in one direction or another. But overall, I mean, I think he was a great CEO, like definitely, you know, up there, like generational CEO, at least for like Swedish startups.Swyx [00:05:09]: Yeah, yeah, for sure. Okay, we should probably move to make our way towards Modal. So then you spent six years as CTO of Better. You were an early engineer and then you scaled up to like 300 engineers.Erik [00:05:21]: I joined as a CTO when there was like no tech team. And yeah, that was a wild chapter in my life. Like the company did very well for a while. And then like during the pandemic, yeah, it was kind of a weird story, but yeah, it kind of collapsed.Swyx [00:05:32]: Yeah, laid off people poorly.Erik [00:05:34]: Yeah, yeah. It was like a bunch of stories. Yeah. I mean, the company like grew from like 10 people when I joined at 10,000, now it's back to a thousand. But yeah, they actually went public a few months ago, kind of crazy. They're still around, like, you know, they're still, you know, doing stuff. So yeah, very kind of interesting six years of my life for non-technical reasons, like I managed like three, four hundred, but yeah, like learning a lot of that, like recruiting. I spent all my time recruiting and stuff like that. And so managing at scale, it's like nice, like now in a way, like when I'm building my own startup. It's actually something I like, don't feel nervous about at all. Like I've managed a scale, like I feel like I can do it again. It's like very different things that I'm nervous about as a startup founder. But yeah, I started Modal three years ago after sort of, after leaving Better, I took a little bit of time off during the pandemic and, but yeah, pretty quickly I was like, I got to build something. I just want to, you know. Yeah. And then yeah, Modal took form in my head, took shape.Swyx [00:06:22]: And as far as I understand, and maybe we can sort of trade off questions. So the quick history is started Modal in 2021, got your seed with Sarah from Amplify in 2022. You just announced your Series A with Redpoint. That's right. And that brings us up to mostly today. Yeah. Most people, I think, were expecting you to build for the data space.Erik: But it is the data space.Swyx:: When I think of data space, I come from like, you know, Snowflake, BigQuery, you know, Fivetran, Nearby, that kind of stuff. And what Modal became is more general purpose than that. Yeah.Erik [00:06:53]: Yeah. I don't know. It was like fun. I actually ran into like Edo Liberty, the CEO of Pinecone, like a few weeks ago. And he was like, I was so afraid you were building a vector database. No, I started Modal because, you know, like in a way, like I work with data, like throughout my most of my career, like every different part of the stack, right? Like I thought everything like business analytics to like deep learning, you know, like building, you know, training neural networks, the scale, like everything in between. And so one of the thoughts, like, and one of the observations I had when I started Modal or like why I started was like, I just wanted to make, build better tools for data teams. And like very, like sort of abstract thing, but like, I find that the data stack is, you know, full of like point solutions that don't integrate well. And still, when you look at like data teams today, you know, like every startup ends up building their own internal Kubernetes wrapper or whatever. And you know, all the different data engineers and machine learning engineers end up kind of struggling with the same things. So I started thinking about like, how do I build a new data stack, which is kind of a megalomaniac project, like, because you kind of want to like throw out everything and start over.Swyx [00:07:54]: It's almost a modern data stack.Erik [00:07:55]: Yeah, like a postmodern data stack. And so I started thinking about that. And a lot of it came from like, like more focused on like the human side of like, how do I make data teams more productive? And like, what is the technology tools that they need? And like, you know, drew out a lot of charts of like, how the data stack looks, you know, what are different components. And it shows actually very interesting, like workflow scheduling, because it kind of sits in like a nice sort of, you know, it's like a hub in the graph of like data products. But it was kind of hard to like, kind of do that in a vacuum, and also to monetize it to some extent. I got very interested in like the layers below at some point. And like, at the end of the day, like most people have code to have to run somewhere. So I think about like, okay, well, how do you make that nice? Like how do you make that? And in particular, like the thing I always like thought about, like developer productivity is like, I think the best way to measure developer productivity is like in terms of the feedback loops, like how quickly when you iterate, like when you write code, like how quickly can you get feedback. And at the innermost loop, it's like writing code and then running it. And like, as soon as you start working with the cloud, like it's like takes minutes suddenly, because you have to build a Docker container and push it to the cloud and like run it, you know. So that was like the initial focus for me was like, I just want to solve that problem. Like I want to, you know, build something less, you run things in the cloud and like retain the sort of, you know, the joy of productivity as when you're running things locally. And in particular, I was quite focused on data teams, because I think they had a couple unique needs that wasn't well served by the infrastructure at that time, or like still is in like, in particular, like Kubernetes, I feel like it's like kind of worked okay for back end teams, but not so well for data teams. And very quickly, I got sucked into like a very deep like rabbit hole of like...Swyx [00:09:24]: Not well for data teams because of burstiness. Yeah, for sure.Erik [00:09:26]: So like burstiness is like one thing, right? Like, you know, like you often have this like fan out, you want to like apply some function over very large data sets. Another thing tends to be like hardware requirements, like you need like GPUs and like, I've seen this in many companies, like you go, you know, data scientists go to a platform team and they're like, can we add GPUs to the Kubernetes? And they're like, no, like, that's, you know, complex, and we're not gonna, so like just getting GPU access. And then like, I mean, I also like data code, like frankly, or like machine learning code like tends to be like, super annoying in terms of like environments, like you end up having like a lot of like custom, like containers and like environment conflicts. And like, it's very hard to set up like a unified container that like can serve like a data scientist, because like, there's always like packages that break. And so I think there's a lot of different reasons why the technology wasn't well suited for back end. And I think the attitude at that time is often like, you know, like you had friction between the data team and the platform team, like, well, it works for the back end stuff, you know, why don't you just like, you know, make it work. But like, I actually felt like data teams, you know, or at this point now, like there's so much, so many people working with data, and like they, to some extent, like deserve their own tools and their own tool chains, and like optimizing for that is not something people have done. So that's, that's sort of like very abstract philosophical reason why I started Model. And then, and then I got sucked into this like rabbit hole of like container cold start and, you know, like whatever, Linux, page cache, you know, file system optimizations.Swyx [00:10:43]: Yeah, tell people, I think the first time I met you, I think you told me some numbers, but I don't remember, like, what are the main achievements that you were unhappy with the status quo? And then you built your own container stack?Erik [00:10:52]: Yeah, I mean, like, in particular, it was like, in order to have that loop, right? You want to be able to start, like take code on your laptop, whatever, and like run in the cloud very quickly, and like running in custom containers, and maybe like spin up like 100 containers, 1000, you know, things like that. And so container cold start was the initial like, from like a developer productivity point of view, it was like, really, what I was focusing on is, I want to take code, I want to stick it in container, I want to execute in the cloud, and like, you know, make it feel like fast. And when you look at like, how Docker works, for instance, like Docker, you have this like, fairly convoluted, like very resource inefficient way, they, you know, you build a container, you upload the whole container, and then you download it, and you run it. And Kubernetes is also like, not very fast at like starting containers. So like, I started kind of like, you know, going a layer deeper, like Docker is actually like, you know, there's like a couple of different primitives, but like a lower level primitive is run C, which is like a container runner. And I was like, what if I just take the container runner, like run C, and I point it to like my own root file system, and then I built like my own virtual file system that exposes files over a network instead. And that was like the sort of very crude version of model, it's like now I can actually start containers very quickly, because it turns out like when you start a Docker container, like, first of all, like most Docker images are like several gigabytes, and like 99% of that is never going to be consumed, like there's a bunch of like, you know, like timezone information for like Uzbekistan, like no one's going to read it. And then there's a very high overlap between the files are going to be read, there's going to be like lib torch or whatever, like it's going to be read. So you can also cache it very well. So that was like the first sort of stuff we started working on was like, let's build this like container file system. And you know, coupled with like, you know, just using run C directly. And that actually enabled us to like, get to this point of like, you write code, and then you can launch it in the cloud within like a second or two, like something like that. And you know, there's been many optimizations since then, but that was sort of starting point.Alessio [00:12:33]: Can we talk about the developer experience as well, I think one of the magic things about Modal is at the very basic layers, like a Python function decorator, it's just like stub and whatnot. But then you also have a way to define a full container, what were kind of the design decisions that went into it? Where did you start? How easy did you want it to be? And then maybe how much complexity did you then add on to make sure that every use case fit?Erik [00:12:57]: I mean, Modal, I almost feel like it's like almost like two products kind of glued together. Like there's like the low level like container runtime, like file system, all that stuff like in Rust. And then there's like the Python SDK, right? Like how do you express applications? And I think, I mean, Swix, like I think your blog was like the self-provisioning runtime was like, to me, always like to sort of, for me, like an eye-opening thing. It's like, so I didn't think about like...Swyx [00:13:15]: You wrote your post four months before me. Yeah? The software 2.0, Infra 2.0. Yeah.Erik [00:13:19]: Well, I don't know, like convergence of minds. I guess we were like both thinking. Maybe you put, I think, better words than like, you know, maybe something I was like thinking about for a long time. Yeah.Swyx [00:13:29]: And I can tell you how I was thinking about it on my end, but I want to hear you say it.Erik [00:13:32]: Yeah, yeah, I would love to. So to me, like what I always wanted to build was like, I don't know, like, I don't know if you use like Pulumi. Like Pulumi is like nice, like in the sense, like it's like Pulumi is like you describe infrastructure in code, right? And to me, that was like so nice. Like finally I can like, you know, put a for loop that creates S3 buckets or whatever. And I think like Modal sort of goes one step further in the sense that like, what if you also put the app code inside the infrastructure code and like glue it all together and then like you only have one single place that defines everything and it's all programmable. You don't have any config files. Like Modal has like zero config. There's no config. It's all code. And so that was like the goal that I wanted, like part of that. And then the other part was like, I often find that so much of like my time was spent on like the plumbing between containers. And so my thing was like, well, if I just build this like Python SDK and make it possible to like bridge like different containers, just like a function call, like, and I can say, oh, this function runs in this container and this other function runs in this container and I can just call it just like a normal function, then, you know, I can build these applications that may span a lot of different environments. Maybe they fan out, start other containers, but it's all just like inside Python. You just like have this beautiful kind of nice like DSL almost for like, you know, how to control infrastructure in the cloud. So that was sort of like how we ended up with the Python SDK as it is, which is still evolving all the time, by the way. We keep changing syntax quite a lot because I think it's still somewhat exploratory, but we're starting to converge on something that feels like reasonably good now.Swyx [00:14:54]: Yeah. And along the way you, with this expressiveness, you enabled the ability to, for example, attach a GPU to a function. Totally.Erik [00:15:02]: Yeah. It's like you just like say, you know, on the function decorator, you're like GPU equals, you know, A100 and then or like GPU equals, you know, A10 or T4 or something like that. And then you get that GPU and like, you know, you just run the code and it runs like you don't have to, you know, go through hoops to, you know, start an EC2 instance or whatever.Swyx [00:15:18]: Yeah. So it's all code. Yeah. So one of the reasons I wrote Self-Revisioning Runtimes was I was working at AWS and we had AWS CDK, which is kind of like, you know, the Amazon basics blew me. Yeah, totally. And then, and then like it creates, it compiles the cloud formation. Yeah. And then on the other side, you have to like get all the config stuff and then put it into your application code and make sure that they line up. So then you're writing code to define your infrastructure, then you're writing code to define your application. And I was just like, this is like obvious that it's going to converge, right? Yeah, totally.Erik [00:15:48]: But isn't there like, it might be wrong, but like, was it like SAM or Chalice or one of those? Like, isn't that like an AWS thing that where actually they kind of did that? I feel like there's like one.Swyx [00:15:57]: SAM. Yeah. Still very clunky. It's not, not as elegant as modal.Erik [00:16:03]: I love AWS for like the stuff it's built, you know, like historically in order for me to like, you know, what it enables me to build, but like AWS is always like struggle with developer experience.Swyx [00:16:11]: I mean, they have to not break things.Erik [00:16:15]: Yeah. Yeah. And totally. And they have to build products for a very wide range of use cases. And I think that's hard.Swyx [00:16:21]: Yeah. Yeah. So it's, it's easier to design for. Yeah. So anyway, I was, I was pretty convinced that this, this would happen. I wrote, wrote that thing. And then, you know, I imagine my surprise that you guys had it on your landing page at some point. I think, I think Akshad was just like, just throw that in there.Erik [00:16:34]: Did you trademark it?Swyx [00:16:35]: No, I didn't. But I definitely got sent a few pitch decks with my post on there and it was like really interesting. This is my first time like kind of putting a name to a phenomenon. And I think this is a useful skill for people to just communicate what they're trying to do.Erik [00:16:48]: Yeah. No, I think it's a beautiful concept.Swyx [00:16:50]: Yeah. Yeah. Yeah. But I mean, obviously you implemented it. What became more clear in your explanation today is that actually you're not that tied to Python.Erik [00:16:57]: No. I mean, I, I think that all the like lower level stuff is, you know, just running containers and like scheduling things and, you know, serving container data and stuff. So like one of the benefits of data teams is obviously like they're all like using Python, right? And so that made it a lot easier. I think, you know, if we had focused on other workloads, like, you know, for various reasons, we've like been kind of like half thinking about like CI or like things like that. But like, in a way that's like harder because like you also, then you have to be like, you know, multiple SDKs, whereas, you know, focusing on data teams, you can only, you know, Python like covers like 95% of all teams. That made it a lot easier. But like, I mean, like definitely like in the future, we're going to have others support, like supporting other languages. JavaScript for sure is the obvious next language. But you know, who knows, like, you know, Rust, Go, R, whatever, PHP, Haskell, I don't know.Swyx [00:17:42]: You know, I think for me, I actually am a person who like kind of liked the idea of programming language advancements being improvements in developer experience. But all I saw out of the academic sort of PLT type people is just type level improvements. And I always think like, for me, like one of the core reasons for self-provisioning runtimes and then why I like Modal is like, this is actually a productivity increase, right? Like, it's a language level thing, you know, you managed to stick it on top of an existing language, but it is your own language, a DSL on top of Python. And so language level increase on the order of like automatic memory management. You know, you could sort of make that analogy that like, maybe you lose some level of control, but most of the time you're okay with whatever Modal gives you. And like, that's fine. Yeah.Erik [00:18:26]: Yeah. Yeah. I mean, that's how I look at about it too. Like, you know, you look at developer productivity over the last number of decades, like, you know, it's come in like small increments of like, you know, dynamic typing or like is like one thing because not suddenly like for a lot of use cases, you don't need to care about type systems or better compiler technology or like, you know, the cloud or like, you know, relational databases. And, you know, I think, you know, you look at like that, you know, history, it's a steadily, you know, it's like, you know, you look at the developers have been getting like probably 10X more productive every decade for the last four decades or something that was kind of crazy. Like on an exponential scale, we're talking about 10X or is there a 10,000X like, you know, improvement in developer productivity. What we can build today, you know, is arguably like, you know, a fraction of the cost of what it took to build it in the eighties. Maybe it wasn't even possible in the eighties. So that to me, like, that's like so fascinating. I think it's going to keep going for the next few decades. Yeah.Alessio [00:19:14]: Yeah. Another big thing in the infra 2.0 wishlist was truly serverless infrastructure. The other on your landing page, you called them native cloud functions, something like that. I think the issue I've seen with serverless has always been people really wanted it to be stateful, even though stateless was much easier to do. And I think now with AI, most model inference is like stateless, you know, outside of the context. So that's kind of made it a lot easier to just put a model, like an AI model on model to run. How do you think about how that changes how people think about infrastructure too? Yeah.Erik [00:19:48]: I mean, I think model is definitely going in the direction of like doing more stateful things and working with data and like high IO use cases. I do think one like massive serendipitous thing that happened like halfway, you know, a year and a half into like the, you know, building model was like Gen AI started exploding and the IO pattern of Gen AI is like fits the serverless model like so well, because it's like, you know, you send this tiny piece of information, like a prompt, right, or something like that. And then like you have this GPU that does like trillions of flops, and then it sends back like a tiny piece of information, right. And that turns out to be something like, you know, if you can get serverless working with GPU, that just like works really well, right. So I think from that point of view, like serverless always to me felt like a little bit of like a solution looking for a problem. I don't actually like don't think like backend is like the problem that needs to serve it or like not as much. But I look at data and in particular, like things like Gen AI, like model inference, like it's like clearly a good fit. So I think that is, you know, to a large extent explains like why we saw, you know, the initial sort of like killer app for model being model inference, which actually wasn't like necessarily what we're focused on. But that's where we've seen like by far the most usage. Yeah.Swyx [00:20:52]: And this was before you started offering like fine tuning of language models, it was mostly stable diffusion. Yeah.Erik [00:20:59]: Yeah. I mean, like model, like I always built it to be a very general purpose compute platform, like something where you can run everything. And I used to call model like a better Kubernetes for data team for a long time. What we realized was like, yeah, that's like, you know, a year and a half in, like we barely had any users or any revenue. And like we were like, well, maybe we should look at like some use case, trying to think of use case. And that was around the same time stable diffusion came out. And the beauty of model is like you can run almost anything on model, right? Like model inference turned out to be like the place where we found initially, well, like clearly this has like 10x like better agronomics than anything else. But we're also like, you know, going back to my original vision, like we're thinking a lot about, you know, now, okay, now we do inference really well. Like what about training? What about fine tuning? What about, you know, end-to-end lifecycle deployment? What about data pre-processing? What about, you know, I don't know, real-time streaming? What about, you know, large data munging, like there's just data observability. I think there's so many things, like kind of going back to what I said about like redefining the data stack, like starting with the foundation of compute. Like one of the exciting things about model is like we've sort of, you know, we've been working on that for three years and it's maturing, but like this is so many things you can do like with just like a better compute primitive and also go up to stack and like do all this other stuff on top of it.Alessio [00:22:09]: How do you think about or rather like I would love to learn more about the underlying infrastructure and like how you make that happen because with fine tuning and training, it's a static memory. Like you exactly know what you're going to load in memory one and it's kind of like a set amount of compute versus inference, just like data is like very bursty. How do you make batches work with a serverless developer experience? You know, like what are like some fun technical challenge you solve to make sure you get max utilization on these GPUs? What we hear from people is like, we have GPUs, but we can really only get like, you know, 30, 40, 50% maybe utilization. What's some of the fun stuff you're working on to get a higher number there?Erik [00:22:48]: Yeah, I think on the inference side, like that's where we like, you know, like from a cost perspective, like utilization perspective, we've seen, you know, like very good numbers and in particular, like it's our ability to start containers and stop containers very quickly. And that means that we can auto scale extremely fast and scale down very quickly, which means like we can always adjust the sort of capacity, the number of GPUs running to the exact traffic volume. And so in many cases, like that actually leads to a sort of interesting thing where like we obviously run our things on like the public cloud, like AWS GCP, we run on Oracle, but in many cases, like users who do inference on those platforms or those clouds, even though we charge a slightly higher price per GPU hour, a lot of users like moving their large scale inference use cases to model, they end up saving a lot of money because we only charge for like with the time the GPU is actually running. And that's a hard problem, right? Like, you know, if you have to constantly adjust the number of machines, if you have to start containers, stop containers, like that's a very hard problem. Starting containers quickly is a very difficult thing. I mentioned we had to build our own file system for this. We also, you know, built our own container scheduler for that. We've implemented recently CPU memory checkpointing so we can take running containers and snapshot the entire CPU, like including registers and everything, and restore it from that point, which means we can restore it from an initialized state. We're looking at GPU checkpointing next, it's like a very interesting thing. So I think with inference stuff, that's where serverless really shines because you can drive, you know, you can push the frontier of latency versus utilization quite substantially, you know, which either ends up being a latency advantage or a cost advantage or both, right? On training, it's probably arguably like less of an advantage doing serverless, frankly, because you know, you can just like spin up a bunch of machines and try to satisfy, like, you know, train as much as you can on each machine. For that area, like we've seen, like, you know, arguably like less usage, like for modal, but there are always like some interesting use case. Like we do have a couple of customers, like RAM, for instance, like they do fine tuning with modal and they basically like one of the patterns they have is like very bursty type fine tuning where they fine tune 100 models in parallel. And that's like a separate thing that modal does really well, right? Like you can, we can start up 100 containers very quickly, run a fine tuning training job on each one of them for that only runs for, I don't know, 10, 20 minutes. And then, you know, you can do hyper parameter tuning in that sense, like just pick the best model and things like that. So there are like interesting training. I think when you get to like training, like very large foundational models, that's a use case we don't support super well, because that's very high IO, you know, you need to have like infinite band and all these things. And those are things we haven't supported yet and might take a while to get to that. So that's like probably like an area where like we're relatively weak in. Yeah.Alessio [00:25:12]: Have you cared at all about lower level model optimization? There's other cloud providers that do custom kernels to get better performance or are you just given that you're not just an AI compute company? Yeah.Erik [00:25:24]: I mean, I think like we want to support like a generic, like general workloads in a sense that like we want users to give us a container essentially or a code or code. And then we want to run that. So I think, you know, we benefit from those things in the sense that like we can tell our users, you know, to use those things. But I don't know if we want to like poke into users containers and like do those things automatically. That's sort of, I think a little bit tricky from the outside to do, because we want to be able to take like arbitrary code and execute it. But certainly like, you know, we can tell our users to like use those things. Yeah.Swyx [00:25:53]: I may have betrayed my own biases because I don't really think about modal as for data teams anymore. I think you started, I think you're much more for AI engineers. My favorite anecdotes, which I think, you know, but I don't know if you directly experienced it. I went to the Vercel AI Accelerator, which you supported. And in the Vercel AI Accelerator, a bunch of startups gave like free credits and like signups and talks and all that stuff. The only ones that stuck are the ones that actually appealed to engineers. And the top usage, the top tool used by far was modal.Erik [00:26:24]: That's awesome.Swyx [00:26:25]: For people building with AI apps. Yeah.Erik [00:26:27]: I mean, it might be also like a terminology question, like the AI versus data, right? Like I've, you know, maybe I'm just like old and jaded, but like, I've seen so many like different titles, like for a while it was like, you know, I was a data scientist and a machine learning engineer and then, you know, there was like analytics engineers and there was like an AI engineer, you know? So like, to me, it's like, I just like in my head, that's to me just like, just data, like, or like engineer, you know, like I don't really, so that's why I've been like, you know, just calling it data teams. But like, of course, like, you know, AI is like, you know, like such a massive fraction of our like workloads.Swyx [00:26:59]: It's a different Venn diagram of things you do, right? So the stuff that you're talking about where you need like infinite bands for like highly parallel training, that's not, that's more of the ML engineer, that's more of the research scientist and less of the AI engineer, which is more sort of trying to put, work at the application.Erik [00:27:16]: Yeah. I mean, to be fair to it, like we have a lot of users that are like doing stuff that I don't think fits neatly into like AI. Like we have a lot of people using like modal for web scraping, like it's kind of nice. You can just like, you know, fire up like a hundred or a thousand containers running Chromium and just like render a bunch of webpages and it takes, you know, whatever. Or like, you know, protein folding is that, I mean, maybe that's, I don't know, like, but like, you know, we have a bunch of users doing that or, or like, you know, in terms of, in the realm of biotech, like sequence alignment, like people using, or like a couple of people using like modal to run like large, like mixed integer programming problems, like, you know, using Gurobi or like things like that. So video processing is another thing that keeps coming up, like, you know, let's say you have like petabytes of video and you want to just like transcode it, like, or you can fire up a lot of containers and just run FFmpeg or like, so there are those things too. Like, I mean, like that being said, like AI is by far our biggest use case, but you know, like, again, like modal is kind of general purpose in that sense.Swyx [00:28:08]: Yeah. Well, maybe I'll stick to the stable diffusion thing and then we'll move on to the other use cases for AI that you want to highlight. The other big player in my mind is replicate. Yeah. In this, in this era, they're much more, I guess, custom built for that purpose, whereas you're more general purpose. How do you position yourself with them? Are they just for like different audiences or are you just heads on competing?Erik [00:28:29]: I think there's like a tiny sliver of the Venn diagram where we're competitive. And then like 99% of the area we're not competitive. I mean, I think for people who, if you look at like front-end engineers, I think that's where like really they found good fit is like, you know, people who built some cool web app and they want some sort of AI capability and they just, you know, an off the shelf model is like perfect for them. That's like, I like use replicate. That's great. I think where we shine is like custom models or custom workflows, you know, running things at very large scale. We need to care about utilization, care about costs. You know, we have much lower prices because we spend a lot more time optimizing our infrastructure, you know, and that's where we're competitive, right? Like, you know, and you look at some of the use cases, like Suno is a big user, like they're running like large scale, like AI. Oh, we're talking with Mikey.Swyx [00:29:12]: Oh, that's great. Cool.Erik [00:29:14]: In a month. Yeah. So, I mean, they're, they're using model for like production infrastructure. Like they have their own like custom model, like custom code and custom weights, you know, for AI generated music, Suno.AI, you know, that, that, those are the types of use cases that we like, you know, things that are like very custom or like, it's like, you know, and those are the things like it's very hard to run and replicate, right? And that's fine. Like I think they, they focus on a very different part of the stack in that sense.Swyx [00:29:35]: And then the other company pattern that I pattern match you to is Modular. I don't know.Erik [00:29:40]: Because of the names?Swyx [00:29:41]: No, no. Wow. No, but yeah, yes, the name is very similar. I think there's something that might be insightful there from a linguistics point of view. Oh no, they have Mojo, the sort of Python SDK. And they have the Modular Inference Engine, which is their sort of their cloud stack, their sort of compute inference stack. I don't know if anyone's made that comparison to you before, but like I see you evolving a little bit in parallel there.Erik [00:30:01]: No, I mean, maybe. Yeah. Like it's not a company I'm like super like familiar, like, I mean, I know the basics, but like, I guess they're similar in the sense like they want to like do a lot of, you know, they have sort of big picture vision.Swyx [00:30:12]: Yes. They also want to build very general purpose. Yeah. So they're marketing themselves as like, if you want to do off the shelf stuff, go out, go somewhere else. If you want to do custom stuff, we're the best place to do it. Yeah. Yeah. There is some overlap there. There's not overlap in the sense that you are a closed source platform. People have to host their code on you. That's true. Whereas for them, they're very insistent on not running their own cloud service. They're a box software. Yeah. They're licensed software.Erik [00:30:37]: I'm sure their VCs at some point going to force them to reconsider. No, no.Swyx [00:30:40]: Chris is very, very insistent and very convincing. So anyway, I would just make that comparison, let people make the links if they want to. But it's an interesting way to see the cloud market develop from my point of view, because I came up in this field thinking cloud is one thing, and I think your vision is like something slightly different, and I see the different takes on it.Erik [00:31:00]: Yeah. And like one thing I've, you know, like I've written a bit about it in my blog too, it's like I think of us as like a second layer of cloud provider in the sense that like I think Snowflake is like kind of a good analogy. Like Snowflake, you know, is infrastructure as a service, right? But they actually run on the like major clouds, right? And I mean, like you can like analyze this very deeply, but like one of the things I always thought about is like, why does Snowflake arbitrarily like win over Redshift? And I think Snowflake, you know, to me, one, because like, I mean, in the end, like AWS makes all the money anyway, like and like Snowflake just had the ability to like focus on like developer experience or like, you know, user experience. And to me, like really proved that you can build a cloud provider, a layer up from, you know, the traditional like public clouds. And in that layer, that's also where I would put Modal, it's like, you know, we're building a cloud provider, like we're, you know, we're like a multi-tenant environment that runs the user code. But we're also building on top of the public cloud. So I think there's a lot of room in that space, I think is very sort of interesting direction.Alessio [00:31:55]: How do you think of that compared to the traditional past history, like, you know, you had AWS, then you had Heroku, then you had Render, Railway.Erik [00:32:04]: Yeah, I mean, I think those are all like great. I think the problem that they all faced was like the graduation problem, right? Like, you know, Heroku or like, I mean, like also like Heroku, there's like a counterfactual future of like, what would have happened if Salesforce didn't buy them, right? Like, that's a sort of separate thing. But like, I think what Heroku, I think always struggled with was like, eventually companies would get big enough that you couldn't really justify running in Heroku. So they would just go and like move it to, you know, whatever AWS or, you know, in particular. And you know, that's something that keeps me up at night too, like, what does that graduation risk like look like for modal? I always think like the only way to build a successful infrastructure company in the long run in the cloud today is you have to appeal to the entire spectrum, right? Or at least like the enterprise, like you have to capture the enterprise market. But the truly good companies capture the whole spectrum, right? Like I think of companies like, I don't like Datadog or Mongo or something that were like, they both captured like the hobbyists and acquire them, but also like, you know, have very large enterprise customers. I think that arguably was like where I, in my opinion, like Heroku struggle was like, how do you maintain the customers as they get more and more advanced? I don't know what the solution is, but I think there's, you know, that's something I would have thought deeply if I was at Heroku at that time.Alessio [00:33:14]: What's the AI graduation problem? Is it, I need to fine tune the model, I need better economics, any insights from customer discussions?Erik [00:33:22]: Yeah, I mean, better economics, certainly. But although like, I would say like, even for people who like, you know, needs like thousands of GPUs, just because we can drive utilization so much better, like we, there's actually like a cost advantage of staying on modal. But yeah, I mean, certainly like, you know, and like the fact that VCs like love, you know, throwing money at least used to, you know, add companies who need it to buy GPUs. I think that didn't help the problem. And in training, I think, you know, there's less software differentiation. So in training, I think there's certainly like better economics of like buying big clusters. But I mean, my hope it's going to change, right? Like I think, you know, we're still pretty early in the cycle of like building AI infrastructure. And I think a lot of these companies over in the long run, like, you know, they're, except it may be super big ones, like, you know, on Facebook and Google, they're always going to build their own ones. But like everyone else, like some extent, you know, I think they're better off like buying platforms. And, you know, someone's going to have to build those platforms.Swyx [00:34:12]: Yeah. Cool. Let's move on to language models and just specifically that workload just to flesh it out a little bit. You already said that RAMP is like fine tuning 100 models at once simultaneously on modal. Closer to home, my favorite example is ErikBot. Maybe you want to tell that story.Erik [00:34:30]: Yeah. I mean, it was a prototype thing we built for fun, but it's pretty cool. Like we basically built this thing that hooks up to Slack. It like downloads all the Slack history and, you know, fine-tunes a model based on a person. And then you can chat with that. And so you can like, you know, clone yourself and like talk to yourself on Slack. I mean, it's like nice like demo and it's just like, I think like it's like fully contained modal. Like there's a modal app that does everything, right? Like it downloads Slack, you know, integrates with the Slack API, like downloads the stuff, the data, like just runs the fine-tuning and then like creates like dynamically an inference endpoint. And it's all like self-contained and like, you know, a few hundred lines of code. So I think it's sort of a good kind of use case for, or like it kind of demonstrates a lot of the capabilities of modal.Alessio [00:35:08]: Yeah. On a more personal side, how close did you feel ErikBot was to you?Erik [00:35:13]: It definitely captured the like the language. Yeah. I mean, I don't know, like the content, I always feel this way about like AI and it's gotten better. Like when you look at like AI output of text, like, and it's like, when you glance at it, it's like, yeah, this seems really smart, you know, but then you actually like look a little bit deeper. It's like, what does this mean?Swyx [00:35:32]: What does this person say?Erik [00:35:33]: It's like kind of vacuous, right? And that's like kind of what I felt like, you know, talking to like my clone version, like it's like says like things like the grammar is correct. Like some of the sentences make a lot of sense, but like, what are you trying to say? Like there's no content here. I don't know. I mean, it's like, I got that feeling also with chat TBT in the like early versions right now it's like better, but.Alessio [00:35:51]: That's funny. So I built this thing called small podcaster to automate a lot of our back office work, so to speak. And it's great at transcript. It's great at doing chapters. And then I was like, okay, how about you come up with a short summary? And it's like, it sounds good, but it's like, it's not even the same ballpark as like, yeah, end up writing. Right. And it's hard to see how it's going to get there.Swyx [00:36:11]: Oh, I have ideas.Erik [00:36:13]: I'm certain it's going to get there, but like, I agree with you. Right. And like, I have the same thing. I don't know if you've read like AI generated books. Like they just like kind of seem funny, right? Like there's off, right? But like you glance at it and it's like, oh, it's kind of cool. Like looks correct, but then it's like very weird when you actually read them.Swyx [00:36:30]: Yeah. Well, so for what it's worth, I think anyone can join the modal slack. Is it open to the public? Yeah, totally.Erik [00:36:35]: If you go to modal.com, there's a button in the footer.Swyx [00:36:38]: Yeah. And then you can talk to Erik Bot. And then sometimes I really like picking Erik Bot and then you answer afterwards, but then you're like, yeah, mostly correct or whatever. Any other broader lessons, you know, just broadening out from like the single use case of fine tuning, like what are you seeing people do with fine tuning or just language models on modal in general? Yeah.Erik [00:36:59]: I mean, I think language models is interesting because so many people get started with APIs and that's just, you know, they're just dominating a space in particular opening AI, right? And that's not necessarily like a place where we aim to compete. I mean, maybe at some point, but like, it's just not like a core focus for us. And I think sort of separately, it's sort of a question of like, there's economics in that long term. But like, so we tend to focus on more like the areas like around it, right? Like fine tuning, like another use case we have is a bunch of people, Ramp included, is doing batch embeddings on modal. So let's say, you know, you have like a, actually we're like writing a blog post, like we take all of Wikipedia and like parallelize embeddings in 15 minutes and produce vectors for each article. So those types of use cases, I think modal suits really well for. I think also a lot of like custom inference, like yeah, I love that.Swyx [00:37:43]: Yeah. I think you should give people an idea of the order of magnitude of parallelism, because I think people don't understand how parallel. So like, I think your classic hello world with modal is like some kind of Fibonacci function, right? Yeah, we have a bunch of different ones. Some recursive function. Yeah.Erik [00:37:59]: Yeah. I mean, like, yeah, I mean, it's like pretty easy in modal, like fan out to like, you know, at least like 100 GPUs, like in a few seconds. And you know, if you give it like a couple of minutes, like we can, you know, you can fan out to like thousands of GPUs. Like we run it relatively large scale. And yeah, we've run, you know, many thousands of GPUs at certain points when we needed, you know, big backfills or some customers had very large compute needs.Swyx [00:38:21]: Yeah. Yeah. And I mean, that's super useful for a number of things. So one of my early interactions with modal as well was with a small developer, which is my sort of coding agent. The reason I chose modal was a number of things. One, I just wanted to try it out. I just had an excuse to try it. Akshay offered to onboard me personally. But the most interesting thing was that you could have that sort of local development experience as it was running on my laptop, but then it would seamlessly translate to a cloud service or like a cloud hosted environment. And then it could fan out with concurrency controls. So I could say like, because like, you know, the number of times I hit the GPT-3 API at the time was going to be subject to the rate limit. But I wanted to fan out without worrying about that kind of stuff. With modal, I can just kind of declare that in my config and that's it. Oh, like a concurrency limit?Erik [00:39:07]: Yeah. Yeah.Swyx [00:39:09]: Yeah. There's a lot of control. And that's why it's like, yeah, this is a pretty good use case for like writing this kind of LLM application code inside of this environment that just understands fan out and rate limiting natively. You don't actually have an exposed queue system, but you have it under the hood, you know, that kind of stuff. Totally.Erik [00:39:28]: It's a self-provisioning cloud.Swyx [00:39:30]: So the last part of modal I wanted to touch on, and obviously feel free, I know you're working on new features, was the sandbox that was introduced last year. And this is something that I think was inspired by Code Interpreter. You can tell me the longer history behind that.Erik [00:39:45]: Yeah. Like we originally built it for the use case, like there was a bunch of customers who looked into code generation applications and then they came to us and asked us, is there a safe way to execute code? And yeah, we spent a lot of time on like container security. We used GeoVisor, for instance, which is a Google product that provides pretty strong isolation of code. So we built a product where you can basically like run arbitrary code inside a container and monitor its output or like get it back in a safe way. I mean, over time it's like evolved into more of like, I think the long-term direction is actually I think more interesting, which is that I think modal as a platform where like I think the core like container infrastructure we offer could actually be like, you know, unbundled from like the client SDK and offer to like other, you know, like we're talking to a couple of like other companies that want to run, you know, through their packages, like run, execute jobs on modal, like kind of programmatically. So that's actually the direction like Sandbox is going. It's like turning into more like a platform for platforms is kind of what I've been thinking about it as.Swyx [00:40:45]: Oh boy. Platform. That's the old Kubernetes line.Erik [00:40:48]: Yeah. Yeah. Yeah. But it's like, you know, like having that ability to like programmatically, you know, create containers and execute them, I think, I think is really cool. And I think it opens up a lot of interesting capabilities that are sort of separate from the like core Python SDK in modal. So I'm really excited about C. It's like one of those features that we kind of released and like, you know, then we kind of look at like what users actually build with it and people are starting to build like kind of crazy things. And then, you know, we double down on some of those things because when we see like, you know, potential new product features and so Sandbox, I think in that sense, it's like kind of in that direction. We found a lot of like interesting use cases in the direction of like platformized container runner.Swyx [00:41:27]: Can you be more specific about what you're double down on after seeing users in action?Erik [00:41:32]: I mean, we're working with like some companies that, I mean, without getting into specifics like that, need the ability to take their users code and then launch containers on modal. And it's not about security necessarily, like they just want to use modal as a back end, right? Like they may already provide like Kubernetes as a back end, Lambda as a back end, and now they want to add modal as a back end, right? And so, you know, they need a way to programmatically define jobs on behalf of their users and execute them. And so, I don't know, that's kind of abstract, but does that make sense? I totally get it.Swyx [00:42:03]: It's sort of one level of recursion to sort of be the Modal for their customers.Erik [00:42:09]: Exactly.Swyx [00:42:10]: Yeah, exactly. And Cloudflare has done this, you know, Kenton Vardar from Cloudflare, who's like the tech lead on this thing, called it sort of functions as a service as a service.Erik [00:42:17]: Yeah, that's exactly right. FaSasS.Swyx [00:42:21]: FaSasS. Yeah, like, I mean, like that, I think any base layer, second layer cloud provider like yourself, compute provider like yourself should provide, you know, it's a mark of maturity and success that people just trust you to do that. They'd rather build on top of you than compete with you. The more interesting thing for me is like, what does it mean to serve a computer like an LLM developer, rather than a human developer, right? Like, that's what a sandbox is to me, that you have to redefine modal to serve a different non-human audience.Erik [00:42:51]: Yeah. Yeah, and I think there's some really interesting people, you know, building very cool things.Swyx [00:42:55]: Yeah. So I don't have an answer, but, you know, I imagine things like, hey, the way you give feedback is different. Maybe you have to like stream errors, log errors differently. I don't really know. Yeah. Obviously, there's like safety considerations. Maybe you have an API to like restrict access to the web. Yeah. I don't think anyone would use it, but it's there if you want it.Erik [00:43:17]: Yeah.Swyx [00:43:18]: Yeah. Any other sort of design considerations? I have no idea.Erik [00:43:21]: With sandboxes?Swyx [00:43:22]: Yeah. Yeah.Erik [00:43:24]: Open-ended question here. Yeah. I mean, no, I think, yeah, the network restrictions, I think, make a lot of sense. Yeah. I mean, I think, you know, long-term, like, I think there's a lot of interesting use cases where like the LLM, in itself, can like decide, I want to install these packages and like run this thing. And like, obviously, for a lot of those use cases, like you want to have some sort of control that it doesn't like install malicious stuff and steal your secrets and things like that. But I think that's what's exciting about the sandbox primitive, is like it lets you do that in a relatively safe way.Alessio [00:43:51]: Do you have any thoughts on the inference wars? A lot of providers are just rushing to the bottom to get the lowest price per million tokens. Some of them, you know, the Sean Randomat, they're just losing money and there's like the physics of it just don't work out for them to make any money on it. How do you think about your pricing and like how much premium you can get and you can kind of command versus using lower prices as kind of like a wedge into getting there, especially once you have model instrumented? What are the tradeoffs and any thoughts on strategies that work?Erik [00:44:23]: I mean, we focus more on like custom models and custom code. And I think in that space, there's like less competition and I think we can have a pricing markup, right? Like, you know, people will always compare our prices to like, you know, the GPU power they can get elsewhere. And so how big can that markup be? Like it never can be, you know, we can never charge like 10x more, but we can certainly charge a premium. And like, you know, for that reason, like we can have pretty good margins. The LLM space is like the opposite, like the switching cost of LLMs is zero. If all you're doing is like straight up, like at least like open source, right? Like if all you're doing is like, you know, using some, you know, inference endpoint that serves an open source model and, you know, some other provider comes along and like offers a lower price, you're just going to switch, right? So I don't know, to me that reminds me a lot of like all this like 15 minute delivery wars or like, you know, like Uber versus Lyft, you know, and like maybe going back even further, like I think a lot about like sort of, you know, flip side of this is like, it's actually a positive side, which is like, I thought a lot about like fiber optics boom of like 98, 99, like the other day, or like, you know, and also like the overinvestment in GPU today. Like, like, yeah, like, you know, I don't know, like in the end, like, I don't think VCs will have the return they expected, like, you know, in these things, but guess who's going to benefit, like, you know, is the consumers, like someone's like reaping the value of this. And that's, I think an amazing flip side is that, you know, we should be very grateful, the fact that like VCs want to subsidize these things, which is, you know, like you go back to fiber optics, like there was an extreme, like overinvestment in fiber optics network in like 98. And no one made money who did that. But consumers, you know, got tremendous benefits of all the fiber optics cables that were led, you know, throughout the country in the decades after. I feel something similar abou

Beschreibung: Neu! Summary durch AI generiert: In dieser Episode diskutieren wir verschiedene Themen. Wir sprechen über die Web-Integrität von Google und die Möglichkeit, dass ähnliche Mechanismen auch auf andere Webseiten angewendet werden könnten. Wir diskutieren die Sicherheitsstrategie der US-Regierung nach dem Angriff auf die Azure Cloud und die Vor- und Nachteile der Nutzung von Cloud-Services. Des Weiteren sprechen wir über Common Vulnerabilities and Exposures (CVEs) und die Probleme bei der Sicherheitsbewertung von Schwachstellen. Wir diskutieren den YouTuber Leeroy und den Angriff auf den Jabber.ru-Server. Anschließend tauschen wir unsere Gedanken über Hacking-Operationen von Geheimdiensten aus und diskutieren moderne Side-Channel-Angriffe auf CPUs und Hardware. In einer weiteren Diskussion geht es um ein kontroverses Video, das von verschiedenen Plattformen gelöscht wurde, und um einen Vorfall bei Okta, einem Unternehmen für Identitätsmanagement. Zum Abschluss diskutieren wir einen Vorfall mit Voltage-Fault-Injection auf AMD-Prozessoren in Tesla-Fahrzeugen. Viel Spaß beim Zuhören! Shownotes: Spiegel Online uses a 2000 years old cipher for their pay wall - Robert Penz Blog Hackers Stole Access Tokens from Oktas Support Unit; Krebs on Security Cloudflare mitigated yet another Okta compromise - Hacker News Okta incident and 1Password - 1Password Nitter Reflections on Trusting Trust Microsoft finally explains cause of Azure breach - Ars Technica iLeakage Dan Goodin: Google has removed a video posted by academic researchers - Infosec Exchange Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service Black Hat USA 2023: Jailbreaking an Tesla in 2023 Web Environment Integrity Explainer Enabling ACME CAA Account and Method Binding RFC 8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding

This is a recap of the top 10 posts on Hacker News on October 20th, 2023.This podcast was generated by wondercraft.ai(00:42): Encrypted traffic interception on Hetzner and Linode targeting Jabber serviceOriginal post: https://news.ycombinator.com/item?id=37955264&utm_source=wondercraft_ai(02:49): Cops Are Suing a Teen for Invasion of Privacy After False Arrest Vid Goes ViralOriginal post: https://news.ycombinator.com/item?id=37956714&utm_source=wondercraft_ai(04:17): The ten year anniversary of the Healthcare.gov rescueOriginal post: https://news.ycombinator.com/item?id=37957152&utm_source=wondercraft_ai(06:14): In search of the least viewed article on Wikipedia (2022)Original post: https://news.ycombinator.com/item?id=37955600&utm_source=wondercraft_ai(08:22): Nakatomi SpaceOriginal post: https://news.ycombinator.com/item?id=37955402&utm_source=wondercraft_ai(10:11): EU Commissioner as double agent of foreign interferenceOriginal post: https://news.ycombinator.com/item?id=37958473&utm_source=wondercraft_ai(11:52): They can and will ruin everything you loveOriginal post: https://news.ycombinator.com/item?id=37959540&utm_source=wondercraft_ai(13:41): Progress on No-GIL CPythonOriginal post: https://news.ycombinator.com/item?id=37960941&utm_source=wondercraft_ai(15:34): Hackers stole access tokens from Okta's support unitOriginal post: https://news.ycombinator.com/item?id=37959904&utm_source=wondercraft_ai(17:26): "[31M"? ANSI Terminal security in 2023 and finding 10 CVEsOriginal post: https://news.ycombinator.com/item?id=37957397&utm_source=wondercraft_aiThis is a third-party project, independent from HN and YC. Text and audio generated using AI, by wondercraft.ai. Create your own studio quality podcast with text as the only input in seconds at app.wondercraft.ai. Issues or feedback? We'd love to hear from you: team@wondercraft.ai

Fredrik snackar interna utvecklarplattformar, abstraktioner, moln och migreringar med Per Bly och Max Ramqvist. Hur får man ut mest av sitt moln, eller mer allmänt miljön eller miljöerna man kör sin kod i? En väg är att låsa fast sig hårt i en leverantörs lösningar och utnyttja den till max. En annan är att bygga en egen utvecklarplattform som ett abstraktionslager - ett lager som både kan sätta upp användbara konventioner och verktyg, och gömma leverantörens miljö så till den grad att det kan bli transparent för utvecklarna att byta miljö. Per och Max har gjort alltihop, hela vägen till att flytta Akind från Azure till rena och enkla lösningar på Hetzner. På vägen blir det också massor av tips på verktyg och lösningar. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @thieta, @krig, och @bjoreman på Mastodon, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Per Max Akind Academic work Vad gör ett plattformsteam? Sextonminutersvideo från Hashicorp IDP - internal developer platform Anton Continuous deployment Nomad Kubernetes YAML Hashicorp Digital ocean Hetzner Terraform Infrastruktur som kod HCL - Hashicorp configuration language Vault Configuration management database - CMDB Grafana Prometheus SPOF - single point of failure Scale to zero - slå av saker helt som inte används för stunden Neon - scale to zero-Postgres Heroku Netlify Unixfilosofin FTE - full-time equivalent Ingress Service mesh Podman Okta Ansible Temporal Titlar Vi pysslar med infrastruktur Det är vi två just nu Akronymerna börjar ta slut Skala sin applikation på bredden och höjden En accelerator för att komma igång 40000 rader YAML Vi kör ju bara på järn VM:ar till otroligt bra pris Vi började POC:a lite Göra valbart det som är intressant Vem som faktiskt pratar med vad Såhär måste man göra En server under skrivbordet Bara en .exe-fil Vara migreringsbar Bara tillräckligt mycket Race conditions fast på infrastruktur Vi vet ingenting Som ett hackathon hela tiden Vi vill bara programmera

Follow-up Apple Event - Wonderlust, de geweldige sketchnote van Jonny Daenen Offline Siri is (toch) ook beschikbaar in het Nederlands Onderwerpen Europa duwt zes techreuzen in strak gareel Telewerk spaart dagelijks 36 miljoen kilometer uit, Vier op de tien Belgen willen meer thuiswerken & Loop Earplugs ‘Behoorlijke’ hoeveelheid lithium aangetroffen in Kempisch grondwater: kan ingezet worden voor autobatterijen & In Amerika spreken ze over concentraties van 9.000 ppm lithium. Dat zijn heel andere grootordes dan in Mol & Geothermiebedrijf Hita ontdekt lithium in de diepe Kempen Plex gaat servers gehost via provider Hetzner vanaf 12 oktober blokkeren ItsMe moet mogelijk geheractiveerd worden bij iOS 17 Tips Maarten: SpamSieve 3.0 Toon: detective Fin op Mastodon & Vervang de chatgroep met je vrienden door een LLM Dewi: podcast Onbespreekbaar | Instax Mini Printer Luisteraarsenquête Vergeet niet om onze luisteraarsenquête in te vullen!

Green IT und die CO2-Emissionen durch die IT, das Internet und die Software-EntwicklungDie Klimakrise ist real. Damit wir das ganze Problem in den Griff bekommen, muss jeder mit anpacken. Doch wie viel Einfluss hat die IT mit der Hardware, dem Internet, auf der Client- und Serverseite? Darüber sprechen wir in dieser Episode. Wie lange solltest du deine Hardware nutzen? Was für eine Rolle spielen Display-Technologien wie Oled und LCD? Sind performante Websites mehr Eco-Friendly? Wie sieht es mit Cloud-Infrastruktur, Build- und CI-Pipelines aus? Wie berechnet man die CO2-Emissionen von Gigabit-Datentransfer? Welche ist die grünste Programmiersprache?Das und noch viel mehr besprechen wir mit unserem Gast Christian "Schepp" Schaefer, der sich mit diesem Thema auseinandergesetzt hat.Bonus: Wo die dreckigsten Industrieunternehmen Deutschlands stehen.**** Diese Episode wird gesponsert vom Open-Source Förderprogramm Media Tech Lab: Bewirb dich jetzt und erhalte bis zu 50.000€ Fördersumme für dein Open-Source Projekt https://www.media-lab.de/de/media-tech-labDas schnelle Feedback zur Episode:

Arm quiere ser más Intel / Plex bloquea miles de servidores / El coche eléctrico más rápido / Apple parcheará la radiación del iPhone 12 Patrocinador: Si estás cansado de tarifas complicadas en tus conexiones, y de sorpresas en tu factura: hazme caso y pásate a O2. La compañía de fibra y móvil más transparente y sencilla, con la mejor atención al cliente, y las conexiones de mayor calidad. — Por ejemplo, por 35€ al mes tienes conexión de fibra de 300 Mbps y una línea móvil con 30 GB de datos. Descubre todas sus tarifas en O2Online.es Arm quiere ser más Intel / Plex bloquea miles de servidores / El coche eléctrico más rápido / Apple parcheará la radiación del iPhone 12

In today's podcast we cover four crucial cyber and technology topics, including: 1.        Anonfiles shuts down, sites overwhelming abuse 2.        Clorox details cyberattack requiring shutdowns 3.        Xurum malware used in attacks against Magento 4.        Researchers uncover new phishing campaign abusing QR codes  I'd love feedback, feel free to send your comments and feedback to  | cyberandtechwithmike@gmail.com

Bizi dinlemekten keyif alıyorsanız, kahve ısmarlayarak bizi destekleyebilir ve Telegram grubumuza katılabilirsiniz. :)Yorumlarınızı, sorularınızı ya da sponsorluk tekliflerinizi info@farklidusun.net e-posta adresine iletebilirsiniz. Bizi Twitter üzerinden takip edebilirsiniz.Zaman damgaları:00:00 - Hetzner07:50 - AppKit, Config23, WWDC2344:38 - İzlediklerimiz ve Writers Strike1:03:17 - Büyük Kaçış1:16:20 - FTC vs Microsoft Xbox1:36:46 - Mentor olmakBölüm linkleri:HetznerHatchboxRenderWWDC23 SessionsThe Talk Show Live From WWDC 2023The curious case of user interfaces - Rasmus Andersson (Config 2023)Leading through uncertainty: A design-led company - Brian Chesky (Config 2023)WestoworldInside the AI FactoryiPhone 14 Pro ile çekildi | Büyük Kaçış | AppleBüyük Kaçış - Olmaz Öyle Saçma Şey - Konuklar: Bartu Küçükçağlayan & Sinan Sevinç - S5B7FTC v. Microsoft: all the news from the big Xbox courtroom battle

Jake Gold, Infrastructure Engineer at Bluesky, joins Corey on Screaming in the Cloud to discuss his experience helping to build Bluesky and why he's so excited about it. Jake and Corey discuss the major differences when building a truly open-source social media platform, and Jake highlights his focus on reliability. Jake explains why he feels downtime can actually be a huge benefit to reliability engineers, and why how he views abstractions based on the size of the team he's working on. Corey and Jake also discuss whether cloud is truly living up to its original promise of lowered costs. About JakeJake Gold leads infrastructure at Bluesky, where the team is developing and deploying the decentralized social media protocol, ATP. Jake has previously managed infrastructure at companies such as Docker and Flipboard, and most recently, he was the founding leader of the Robot Reliability Team at Nuro, an autonomous delivery vehicle company.Links Referenced: Bluesky: https://blueskyweb.xyz/ Bluesky waitlist signup: https://bsky.app TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. In case folks have missed this, I spent an inordinate amount of time on Twitter over the last decade or so, to the point where my wife, my business partner, and a couple of friends all went in over the holidays and got me a leather-bound set of books titled The Collected Works of Corey Quinn. It turns out that I have over a million words of shitpost on Twitter. If you've also been living in a cave for the last year, you'll notice that Twitter has basically been bought and driven into the ground by the world's saddest manchild, so there's been a bit of a diaspora as far as people trying to figure out where community lives.Jake Gold is an infrastructure engineer at Bluesky—which I will continue to be mispronouncing as Blue-ski because that's the kind of person I am—which is, as best I can tell, one of the leading contenders, if not the leading contender to replace what Twitter was for me. Jake, welcome to the show.Jake: Thanks a lot, Corey. Glad to be here.Corey: So, there's a lot of different angles we can take on this. We can talk about the policy side of it, we can talk about social networks and things we learn watching people in large groups with quasi-anonymity, we can talk about all kinds of different nonsense. But I don't want to do that because I am an old-school Linux systems administrator. And I believe you came from the exact same path, given that as we were making sure that I had, you know, the right person on the show, you came into work at a company after I'd left previously. So, not only are you good at the whole Linux server thing; you also have seen exactly how good I am not at the Linux server thing.Jake: Well, I don't remember there being any problems at TrueCar, where you worked before me. But yeah, my background is doing Linux systems administration, which turned into, sort of, Linux programming. And these days, we call it, you know, site reliability engineering. But yeah, I discovered Linux in the late-90s, as a teenager and, you know, installing Slackware on 50 floppy disks and things like that. And I just fell in love with the magic of, like, being able to run a web server, you know? I got a hosting account at, you know, my local ISP, and I was like, how do they do that, right?And then I figured out how to do it. I ran Apache, and it was like, still one of my core memories of getting, you know, httpd running and being able to access it over the internet and telling my friends on IRC. And so, I've done a whole bunch of things since then, but that's still, like, the part that I love the most.Corey: The thing that continually surprises me is just what I think I'm out and we've moved into a fully modern world where oh, all I do is I write code anymore, which I didn't realize I was doing until I realized if you call YAML code, you can get away with anything. And I get dragged—myself getting dragged back in. It's the falling back to fundamentals in these weird moments of yes, yes, immutable everything, Infrastructure is code, but when the server is misbehaving and you want to log in and get your hands dirty, the skill set rears its head yet again. At least that's what I've been noticing, at least as far as I've gone down a number of interesting IoT-based projects lately. Is that something you experience or have you evolved fully and not looked back?Jake: Yeah. No, what I try to do is on my personal projects, I'll use all the latest cool, flashy things, any abstraction you want, I'll try out everything, and then what I do it at work, I kind of have, like, a one or two year, sort of, lagging adoption of technologies, like, when I've actually shaken them out in my own stuff, then I use them at work. But yeah, I think one of my favorite quotes is, like, “Programmers first learn the power of abstraction, then they learn the cost of abstraction, and then they're ready to program.” And that's how I view infrastructure, very similar thing where, you know, certain abstractions like container orchestration, or you know, things like that can be super powerful if you need them, but like, you know, that's generally very large companies with lots of teams and things like that. And if you're not that, it pays dividends to not use overly complicated, overly abstracted things. And so, that tends to be [where 00:04:22] I follow up most of the time.Corey: I'm sure someone's going to consider this to be heresy, but if I'm tasked with getting a web application up and running in short order, I'm putting it on an old-school traditional three-tier architecture where you have a database server, a web server or two, and maybe a job server that lives between them. Because is it the hotness? No. Is it going to be resume bait? Not really.But you know, it's deterministic as far as where things live. When something breaks, I know where to find it. And you can miss me with the, “Well, that's not webscale,” response because yeah, by the time I'm getting something up overnight, to this has to serve the entire internet, there's probably a number of architectural iterations I'm going to be able to go through. The question is, what am I most comfortable with and what can I get things up and running with that's tried and tested?I'm also remarkably conservative on things like databases and file systems because mistakes at that level are absolutely going to show. Now, I don't know how much you're able to talk about the Blue-ski infrastructure without getting yelled at by various folks, but how modern versus… reliable—I guess that's probably a fair axis to put it on: modernity versus reliability—where on that spectrum, does the official Blue-ski infrastructure land these days?Jake: Yeah. So, I mean, we're in a fortunate position of being an open-source company working on an open protocol, and so we feel very comfortable talking about basically everything. Yeah, and I've talked about this a bit on the app, but the basic idea we have right now is we're using AWS, we have auto-scaling groups, and those auto-scaling groups are just EC2 instances running Docker CE—the Community Edition—for the runtime and for containers. And then we have a load balancer in front and a Postgres multi-AZ instance in the back on RDS, and it is really, really simple.And, like, when I talk about the difference between, like, a reliability engineer and a normal software engineer is, software engineers tend to be very feature-focused, you know, they're adding capabilities to a system. And the goal and the mission of a reliability team is to focus on reliability, right? Like, that's the primary thing that we're worried about. So, what I find to be the best resume builder is that I can say with a lot of certainty that if you talk to any teams that I've worked on, they will say that the infrastructure I ran was very reliable, it was very secure, and it ended up being very scalable because you know, the way we solve the, sort of, integration thing is you just version your infrastructure, right? And I think this works really well.You just say, “Hey, this was the way we did it now and we're going to call that V1. And now we're going to work on V2. And what should V2 be?” And maybe that does need something more complicated. Maybe you need to bring in Kubernetes, you maybe need to bring in a super-cool reverse proxy that has all sorts of capabilities that your current one doesn't.Yeah, but by versioning it, you just—it takes away a lot of the, sort of, interpersonal issues that can happen where, like, “Hey, we're replacing Jake's infrastructure with Bob's infrastructure or whatever.” I just say it's V1, it's V2, it's V3, and then I find that solves a huge number of the problems with that sort of dynamic. But yeah, at Bluesky, like, you know, the big thing that we are focused on is federation is scaling for us because the idea is not for us to run the entire global infrastructure for AT Proto, which is the protocol that Bluesky is based on. The idea is that it's this big open thing like the web, right? Like, you know, Netscape popularized the web, but they didn't run every web server, they didn't run every search engine, right, they didn't run all the payment stuff. They just did all of the core stuff, you know, they created SSL, right, which became TLS, and they did all the things that were necessary to make the whole system large, federated, and scalable. But they didn't run it all. And that's exactly the same goal we have.Corey: The obvious counterexample is, no, but then you take basically their spiritual successor, which is Google, and they build the security, they build—they run a lot of the servers, they have the search engine, they have the payments infrastructure, and then they turn a lot of it off for fun and… I would say profit, except it's the exact opposite of that. But I digress. I do have a question for you that I love to throw at people whenever they start talking about how their infrastructure involves auto-scaling. And I found this during the pandemic in that a lot of people believed in their heart-of-hearts that they were auto-scaling, but people lie, mostly to themselves. And you would look at their daily or hourly spend of their infrastructure and their user traffic dropped off a cliff and their spend was so flat you could basically eat off of it and set a table on top of it. If you pull up Cost Explorer and look through your environment, how large are the peaks and valleys over the course of a given day or week cycle?Jake: Yeah, no, that's a really good point. I think my basic approach right now is that we're so small, we don't really need to optimize very much for cost, you know? We have this sort of base level of traffic and it's not worth a huge amount of engineering time to do a lot of dynamic scaling and things like that. The main benefit we get from auto-scaling groups is really just doing the refresh to replace all of them, right? So, we're also doing the immutable server concept, right, which was popularized by Netflix.And so, that's what we're really getting from auto-scaling groups. We're not even doing dynamic scaling, right? So, it's not keyed to some metric, you know, the number of instances that we have at the app server layer. But the cool thing is, you can do that when you're ready for it, right? The big issue is, you know, okay, you're scaling up your app instances, but is your database scaling up, right, because there's not a lot of use in having a whole bunch of app servers if the database is overloaded? And that tends to be the bottleneck for, kind of, any complicated kind of application like ours. So, right now, the bill is very flat; you could eat off, and—if it wasn't for the CDN traffic and the load balancer traffic and things like that, which are relatively minor.Corey: I just want to stop for a second and marvel at just how educated that answer was. It's, I talk to a lot of folks who are early-stage who come and ask me about their AWS bills and what sort of things should they concern themselves with, and my answer tends to surprise them, which is, “You almost certainly should not unless things are bizarre and ridiculous. You are not going to build your way to your next milestone by cutting costs or optimizing your infrastructure.” The one thing that I would make sure to do is plan for a future of success, which means having account segregation where it makes sense, having tags in place so that when, “Huh, this thing's gotten really expensive. What's driving all of that?” Can be answered without a six-week research project attached to it.But those are baseline AWS Hygiene 101. How do I optimize my bill further, usually the right answer is go build. Don't worry about the small stuff. What's always disturbing is people have that perspective and they're spending $300 million a year. But it turns out that not caring about your AWS bill was, in fact, a zero interest rate phenomenon.Jake: Yeah. So, we do all of those basic things. I think I went a little further than many people would where every single one of our—so we have different projects, right? So, we have the big graph server, which is sort of like the indexer for the whole network, and we have the PDS, which is the Personal Data Server, which is, kind of, where all of people's actual social data goes, your likes and your posts and things like that. And then we have a dev staging, sandbox, prod environment for each one of those, right? And there's more services besides. But the way we have it is those are all in completely separated VPCs with no peering whatsoever between them. They are all on distinct IP addresses, IP ranges, so that we could do VPC peering very easily across all of them.Corey: Ah, that's someone who's done data center work before with overlapping IP address ranges and swore, never again.Jake: Exactly. That is when I had been burned. I have cleaned up my mess and other people's messes. And there's nothing less fun than renumbering a large complicated network. But yeah, so once we have all these separate VPCs and so it's very easy for us to say, hey, we're going to take this whole stack from here and move it over to a different region, a different provider, you know?And the other thing is that we're doing is, we're completely cloud agnostic, right? I really like AWS, I think they are the… the market leader for a reason: they're very reliable. But we're building this large federated network, so we're going to need to place infrastructure in places where AWS doesn't exist, for example, right? So, we need the ability to take an environment and replicate it in wherever. And of course, they have very good coverage, but there are places they don't exist. And that's all made much easier by the fact that we've had a very strong separation of concerns.Corey: I always found it fun that when you had these decentralized projects that were invariably NFT or cryptocurrency-driven over the past, eh, five or six years or so, and then AWS would take a us-east-1 outage in a variety of different and exciting ways,j and all these projects would go down hard. It's, okay, you talk a lot about decentralization for having hard dependencies on one company in one data center, effectively, doing something right. And it becomes a harder problem in the fullness of time. There is the counterargument, in that when us-east-1 is having problems, most of the internet isn't working, so does your offering need to be up and running at all costs? There are some people for whom that answer is very much, yes. People will die if what we're running is not up and running. Usually, a social network is not on that list.Jake: Yeah. One of the things that is surprising, I think, often when I talk about this as a reliability engineer, is that I think people sometimes over-index on downtime, you know? They just, they think it's much bigger deal than it is. You know, I've worked on systems where there was credit card processing where you're losing a million dollars a minute or something. And like, in that case, okay, it matters a lot because you can put a real dollar figure on it, but it's amazing how a few of the bumps in the road we've already had with Bluesky have turned into, sort of, fun events, right?Like, we had a bug in our invite code system where people were getting too many invite codes and it was sort of caused a problem, but it was a super fun event. We all think back on it fondly, right? And so, outages are not fun, but they're not life and death, generally. And if you look at the traffic, usually what happens is after an outage traffic tends to go up. And a lot of the people that joined, they're just, they're talking about the fun outage that they missed because they weren't even on the network, right?So, it's like, I also like to remind people that eBay for many years used to have, like, an outage Wednesday, right? Whereas they could put a huge dollar figure on how much money they lost every Wednesday and yet eBay did quite well, right? Like, it's amazing what you can do if you relax the constraints of downtime a little bit. You can do maintenance things that would be impossible otherwise, which makes the whole thing work better the rest of the time, for example.Corey: I mean, it's 2023 and the Social Security Administration's website still has business hours. They take a nightly four to six-hour maintenance window. It's like, the last person out of the office turns off the server or something. I imagine some horrifying mainframe job that needs to wind up sweeping after itself are running some compute jobs. But yeah, for a lot of these use cases, that downtime is absolutely acceptable.I am curious as to… as you just said, you're building this out with an idea that it runs everywhere. So, you're on AWS right now because yeah, they are the market leader for a reason. If I'm building something from scratch, I'd be hard-pressed not to pick AWS for a variety of reasons. If I didn't have cloud expertise, I think I'd be more strongly inclined toward Google, but that's neither here nor there. But the problem is these large cloud providers have certain economic factors that they all treat similarly since they're competing with each other, and that causes me to believe things that aren't necessarily true.One of those is that egress bandwidth to the internet is very expensive. I've worked in data centers. I know how 95th percentile commit bandwidth billing works. It is not overwhelmingly expensive, but you can be forgiven for believing that it is looking at cloud environments. Today, Blue-ski does not support animated GIFs—however you want to mispronounce that word—they don't support embedded videos, and my immediate thought is, “Oh yeah, those things would be super expensive to wind up sharing.”I don't know that that's true. I don't get the sense that those are major cost drivers. I think it's more a matter of complexity than the rest. But how are you making sure that the large cloud provider economic models don't inherently shape your view of what to build versus what not to build?Jake: Yeah, no, I kind of knew where you're going as soon as you mentioned that because anyone who's worked in data centers knows that the bandwidth pricing is out of control. And I think one of the cool things that Cloudflare did is they stopped charging for egress bandwidth in certain scenarios, which is kind of amazing. And I think it's—the other thing that a lot of people don't realize is that, you know, these network connections tend to be fully symmetric, right? So, if it's a gigabit down, it's also a gigabit up at the same time, right? There's two gigabits that can be transferred per second.And then the other thing that I find a little bit frustrating on the public cloud is that they don't really pass on the compute performance improvements that have happened over the last few years, right? Like computers are really fast, right? So, if you look at a provider like Hetzner, they're giving you these monster machines for $128 a month or something, right? And then you go and try to buy that same thing on the public, the big cloud providers, and the equivalent is ten times that, right? And then if you add in the bandwidth, it's another multiple, depending on how much you're transferring.Corey: You can get Mac Minis on EC2 now, and you do the math out and the Mac Mini hardware is paid for in the first two or three months of spinning that thing up. And yes, there's value in AWS's engineering and being able to map IAM and EBS to it. In some use cases, yeah, it's well worth having, but not in every case. And the economics get very hard to justify for an awful lot of work cases.Jake: Yeah, I mean, to your point, though, about, like, limiting product features and things like that, like, one of the goals I have with doing infrastructure at Bluesky is to not let the infrastructure be a limiter on our product decisions. And a lot of that means that we'll put servers on Hetzner, we'll colo servers for things like that. I find that there's a really good hybrid cloud thing where you use AWS or GCP or Azure, and you use them for your most critical things, you're relatively low bandwidth things and the things that need to be the most flexible in terms of region and things like that—and security—and then for these, sort of, bulk services, pushing a lot of video content, right, or pushing a lot of images, those things, you put in a colo somewhere and you have these sort of CDN-like servers. And that kind of gives you the best of both worlds. And so, you know, that's the approach that we'll most likely take at Bluesky.Corey: I want to emphasize something you said a minute ago about CloudFlare, where when they first announced R2, their object store alternative, when it first came out, I did an analysis on this to explain to people just why this was as big as it was. Let's say you have a one-gigabyte file and it blows up and a million people download it over the course of a month. AWS will come to you with a completely straight face, give you a bill for $65,000 and expect you to pay it. The exact same pattern with R2 in front of it, at the end of the month, you will be faced with a bill for 13 cents rounded up, and you will be expected to pay it, and something like 9 to 12 cents of that initially would have just been the storage cost on S3 and the single egress fee for it. The rest is there is no egress cost tied to it.Now, is Cloudflare going to let you send petabytes to the internet and not charge you on a bandwidth basis? Probably not. But they're also going to reach out with an upsell and they're going to have a conversation with you. “Would you like to transition to our enterprise plan?” Which is a hell of a lot better than, “I got Slashdotted”—or whatever the modern version of that is—“And here's a surprise bill that's going to cost as much as a Tesla.”Jake: Yeah, I mean, I think one of the things that the cloud providers should hopefully eventually do—I hope Cloudflare pushes them in this direction—is to start—the original vision of AWS when I first started using it in 2006 or whenever launched, was—and they said this—they said they're going to lower your bill every so often, you know, as Moore's law makes their bill lower. And that kind of happened a little bit here and there, but it hasn't happened to the same degree that you know, I think all of us hoped it would. And I would love to see a cloud provider—and you know, Hetzner does this to some degree, but I'd love to see these really big cloud providers that are so great in so many ways, just pass on the savings of technology to the customer so we'll use more stuff there. I think it's a very enlightened viewpoint is to just say, “Hey, we're going to lower the costs, increase the efficiency, and then pass it on to customers, and then they will use more of our services as a result.” And I think Cloudflare is kind of leading the way in there, which I love.Corey: I do need to add something there—because otherwise we're going to get letters and I don't think we want that—where AWS reps will, of course, reach out and say that they have cut prices over a hundred times. And they're going to ignore the fact that a lot of these were a service you don't use in a region you couldn't find a map if your life depended on it now is going to be 10% less. Great. But let's look at the general case, where from C3 to C4—if you get the same size instance—it cut the price by a lot. C4 to C5, somewhat. C5 to C6 effectively is no change. And now, from C6 to C7, it is 6% more expensive like for like.And they're making noises about price performance is still better, but there are an awful lot of us who say things like, “I need ten of these servers to live over there.” That workload gets more expensive when you start treating it that way. And maybe the price performance is there, maybe it's not, but it is clear that the bill always goes down is not true.Jake: Yeah, and I think for certain kinds of organizations, it's totally fine the way that they do it. They do a pretty good job on price and performance. But for sort of more technical companies—especially—it's just you can see the gaps there, where that Hetzner is filling and that colocation is still filling. And I personally, you know, if I didn't need to do those things, I wouldn't do them, right? But the fact that you need to do them, I think, says kind of everything.Corey: Tired of wrestling with Apache Kafka's complexity and cost? Feel like you're stuck in a Kafka novel, but with more latency spikes and less existential dread by at least 10%? You're not alone.What if there was a way to 10x your streaming data performance without having to rob a bank? Enter Redpanda. It's not just another Kafka wannabe. Redpanda powers mission-critical workloads without making your AWS bill look like a phone number.And with full Kafka API compatibility, migration is smoother than a fresh jar of peanut butter. Imagine cutting as much as 50% off your AWS bills. With Redpanda, it's not a pipedream, it's reality.Visit go.redpanda.com/duckbill today. Redpanda: Because your data infrastructure shouldn't give you Kafkaesque nightmares.Corey: There are so many weird AWS billing stories that all distill down to you not knowing this one piece of trivia about how AWS works, either as a system, as a billing construct, or as something else. And there's a reason this has become my career of tracing these things down. And sometimes I'll talk to prospective clients, and they'll say, “Well, what if you don't discover any misconfigurations like that in our account?” It's, “Well, you would be the first company I've ever seen where that [laugh] was not true.” So honestly, I want to do a case study if we do.And I've never had to write that case study, just because it's the tax on not having the forcing function of building in data centers. There's always this idea that in a data center, you're going to run out of power, space, capacity, at some point and it's going to force a reckoning. The cloud has what distills down to infinite capacity; they can add it faster than you can fill it. So, at some point it's always just keep adding more things to it. There's never a let's clean out all of the cruft story. And it just accumulates and the bill continues to go up and to the right.Jake: Yeah, I mean, one of the things that they've done so well is handle the provisioning part, right, which is kind of what you're getting out there. One of the hardest things in the old days, before we all used AWS and GCP, is you'd have to sort of requisition hardware and there'd be this whole process with legal and financing and there'd be this big lag between the time you need a bunch more servers in your data center and when you actually have them, right, and that's not even counting the time takes to rack them and get them, you know, on network. The fact that basically, every developer now just gets an unlimited credit card, they can just, you know, use that's hugely empowering, and it's for the benefit of the companies they work for almost all the time. But it is an uncapped credit card. I know, they actually support controls and things like that, but in general, the way we treated it—Corey: Not as much as you would think, as it turns out. But yeah, it's—yeah, and that's a problem. Because again, if I want to spin up $65,000 an hour worth of compute right now, the fact that I can do that is massive. The fact that I could do that accidentally when I don't intend to is also massive.Jake: Yeah, it's very easy to think you're going to spend a certain amount and then oh, traffic's a lot higher, or, oh, I didn't realize when you enable that thing, it charges you an extra fee or something like that. So, it's very opaque. It's very complicated. All of these things are, you know, the result of just building more and more stuff on top of more and more stuff to support more and more use cases. Which is great, but then it does create this very sort of opaque billing problem, which I think, you know, you're helping companies solve. And I totally get why they need your help.Corey: What's interesting to me about distributed social networks is that I've been using Mastodon for a little bit and I've started to see some of the challenges around a lot of these things, just from an infrastructure and architecture perspective. Tim Bray, former Distinguished Engineer at AWS posted a blog post yesterday, and okay, well, if Tim wants to put something up there that he thinks people should read, I advise people generally read it. I have yet to find him wasting my time. And I clicked it and got a, “Server over resource limits.” It's like wow, you're very popular. You wound up getting—got effectively Slashdotted.And he said, “No, no. Whatever I post a link to Mastodon, two thousand instances all hidden at the same time.” And it's, “Oh, yeah. The hug of death. That becomes a challenge.” Not to mention the fact that, depending upon architecture and preferences that you make, running a Mastodon instance can be extraordinarily expensive in terms of storage, just because it'll, by default, attempt to cache everything that it encounters for a period of time. And that gets very heavy very quickly. Does the AT Protocol—AT Protocol? I don't know how you pronounce it officially these days—take into account the challenges of running infrastructures designed for folks who have corporate budgets behind them? Or is that really a future problem for us to worry about when the time comes?Jake: No, yeah, that's a core thing that we talked about a lot in the recent, sort of, architecture discussions. I'm going to go back quite a ways, but there were some changes made about six months ago in our thinking, and one of the big things that we wanted to get right was the ability for people to host their own PDS, which is equivalent to, like, posting a WordPress or something. It's where you post your content, it's where you post your likes, and all that kind of thing. We call it your repository or your repo. But that we wanted to make it so that people could self-host that on a, you know, four or five $6-a-month droplet on DigitalOcean or wherever and that not be a problem, not go down when they got a lot of traffic.And so, the architecture of AT Proto in general, but the Bluesky app on AT Proto is such that you really don't need a lot of resources. The data is all signed with your cryptographic keys—like, not something you have to worry about as a non-technical user—but all the data is authenticated. That's what—it's Authenticated Transfer Protocol. And because of that, it doesn't matter where you get the data, right? So, we have this idea of this big indexer that's looking at the entire network called the BGS, the Big Graph Server and you can go to the BGS and get the data that came from somebody's PDS and it's just as good as if you got it directly from the PDS. And that makes it highly cacheable, highly conducive to CDNs and things like that. So no, we intend to solve that problem entirely.Corey: I'm looking forward to seeing how that plays out because the idea of self-hosting always kind of appealed to me when I was younger, which is why when I met my wife, I had a two-bedroom apartment—because I lived in Los Angeles, not San Francisco, and could afford such a thing—and the guest bedroom was always, you know, 10 to 15 degrees warmer than the rest of the apartment because I had a bunch of quote-unquote, “Servers” there, meaning deprecated desktops that my employer had no use for and said, “It's either going to e-waste or your place if you want some.” And, okay, why not? I'll build my own cluster at home. And increasingly over time, I found that it got harder and harder to do things that I liked and that made sense. I used to have a partial rack in downtown LA where I ran my own mail server, among other things.And when I switched to Google for email solutions, I suddenly found that I was spending five bucks a month at the time, instead of the rack rental, and I was spending two hours less a week just fighting spam in a variety of different ways because that is where my technical background lives. Being able to not have to think about problems like that, and just do the fun part was great. But I worry about the centralization that that implies. I was opposed to it at the idea because I didn't want to give Google access to all of my mail. And then I checked and something like 43% of the people I was emailing were at Gmail-hosted addresses, so they already had my email anyway. What was I really doing by not engaging with them? I worry that self-hosting is going to become passe, so I love projects that do it in sane and simple ways that don't require massive amounts of startup capital to get started with.Jake: Yeah, the account portability feature of AT Proto is super, super core. You can backup all of your data to your phone—the [AT 00:28:36] doesn't do this yet, but it most likely will in the future—you can backup all of your data to your phone and then you can synchronize it all to another server. So, if for whatever reason, you're on a PDS instance and it disappears—which is a common problem in the Mastodon world—it's not really a problem. You just sync all that data to a new PDS and you're back where you were. You didn't lose any followers, you didn't lose any posts, you didn't lose any likes.And we're also making sure that this works for non-technical people. So, you know, you don't have to host your own PDS, right? That's something that technical people can self-host if they want to, non-technical people can just get a host from anywhere and it doesn't really matter where your host is. But we are absolutely trying to avoid the fate of SMTP and, you know, other protocols. The web itself, right, is sort of… it's hard to launch a search engine because the—first of all, the bar is billions of dollars a year in investment, and a lot of websites will only let us crawl them at a higher rate if you're actually coming from a Google IP, right? They're doing reverse DNS lookups, and things like that to verify that you are Google.And the problem with that is now there's sort of this centralization with a search engine that can't be fixed. With AT Proto, it's much easier to scrape all of the PDSes, right? So, if you want to crawl all the PDSes out on the AT Proto network, they're designed to be crawled from day one. It's all structured data, we're working on, sort of, how you handle rate limits and things like that still, but the idea is it's very easy to create an index of the entire network, which makes it very easy to create feed generators, search engines, or any other kind of sort of big world networking thing out there. And then without making the PDSes have to be very high power, right? So, they can do low power and still scrapeable, still crawlable.Corey: Yeah, the idea of having portability is super important. Question I've got—you know, while I'm talking to you, it's, we'll turn this into technical support hour as well because why not—I tend to always historically put my Twitter handle on conference slides. When I had the first template made, I used it as soon as it came in and there was an extra n in the @quinnypig username at the bottom. And of course, someone asked about that during Q&A.So, the answer I gave was, of course, n+1 redundancy. But great. If I were to have one domain there today and change it tomorrow, is there a redirect option in place where someone could go and find that on Blue-ski, and oh, they'll get redirected to where I am now. Or is it just one of those 404, sucks to be you moments? Because I can see validity to both.Jake: Yeah, so the way we handle it right now is if you have a, something.bsky.social name and you switch it to your own domain or something like that, we don't yet forward it from the old.bsky.social name. But that is totally feasible. It's totally possible. Like, the way that those are stored in your what's called your [DID record 00:31:16] or [DID document 00:31:17] is that there's, like, a list that currently only has one item in general, but it's a list of all of your different names, right? So, you could have different domain names, different subdomain names, and they would all point back to the same user. And so yeah, so basically, the idea is that you have these aliases and they will forward to the new one, whatever the current canonical one is.Corey: Excellent. That is something that concerns me because it feels like it's one of those one-way doors, in the same way that picking an email address was a one-way door. I know people who still pay money to their ancient crappy ISP because they have a few mails that come in once in a while that are super-important. I was fortunate enough to have jumped on the bandwagon early enough that my vanity domain is 22 years old this year. And my email address still works,which, great, every once in a while, I still get stuff to, like, variants of my name I no longer use anymore since 2005. And it's usually spam, but every once in a blue moon, it's something important, like, “Hey, I don't know if you remember me. We went to college together many years ago.” It's ho-ly crap, the world is smaller than we think.Jake: Yeah.j I mean, I love that we're using domains, I think that's one of the greatest decisions we made is… is that you own your own domain. You're not really stuck in our namespace, right? Like, one of the things with traditional social networks is you're sort of, their domain.com/yourname, right?And with the way AT Proto and Bluesky work is, you can go and get a domain name from any registrar, there's hundreds of them—you know, we'd like Namecheap, you can go there and you can grab a domain and you can point it to your account. And if you ever don't like anything, you can change your domain, you can change, you know which PDS you're on, it's all completely controlled by you. And there's nearly no way we as a company can do anything to change that. Like, that's all sort of locked into the way that the protocol works, which creates this really great incentive where, you know, if we want to provide you services or somebody else wants to provide you services, they just have to compete on doing a really good job; you're not locked in. And that's, like, one of my favorite features of the network.Corey: I just want to point something out because you mentioned oh, we're big fans of Namecheap. I am too, for weird half-drunk domain registrations on a lark. Like, “Why am I poor?” It's like, $3,000 a month of my budget goes to domain purchases, great. But I did a quick whois on the official Bluesky domain and it's hosted at Route 53, which is Amazon's, of course, premier database offering.But I'm a big fan of using a enterprise registrar for enterprise-y things. Wasabi, if I recall correctly, wound up having their primary domain registered through GoDaddy, and the public domain that their bucket equivalent would serve data out of got shut down for 12 hours because some bad actor put something there that shouldn't have been. And GoDaddy is not an enterprise registrar, despite what they might think—for God's sake, the word ‘daddy' is in their name. Do you really think that's enterprise? Good luck.So, the fact that you have a responsible company handling these central singular points of failure speaks very well to just your own implementation of these things. Because that's the sort of thing that everyone figures out the second time.Jake: Yeah, yeah. I think there's a big difference between corporate domain registration, and corporate DNS and, like, your personal handle on social networking. I think a lot of the consumer, sort of, domain registries are—registrars—are great for consumers. And I think if you—yeah, you're running a big corporate domain, you want to make sure it's, you know, it's transfer locked and, you know, there's two-factor authentication and doing all those kinds of things right because that is a single point of failure; you can lose a lot by having your domain taken. So, I completely agree with you on there.Corey: Oh, absolutely. I am curious about this to see if it's still the case or not because I haven't checked this in over a year—and they did fix it. Okay. As of at least when we're recording this, which is the end of May 2023, Amazon's Authoritative Name Servers are no longer half at Oracle. Good for them. They now have a bunch of Amazon-specific name servers on them instead of, you know, their competitor that they clearly despise. Good work, good work.I really want to thank you for taking the time to speak with me about how you're viewing these things and honestly giving me a chance to go ambling down memory lane. If people want to learn more about what you're up to, where's the best place for them to find you?Jake: Yeah, so I'm on Bluesky. It's invite only. I apologize for that right now. But if you check out bsky.app, you can see how to sign up for the waitlist, and we are trying to get people on as quickly as possible.Corey: And I will, of course, be talking to you there and will put links to that in the show notes. Thank you so much for taking the time to speak with me. I really appreciate it.Jake: Thanks a lot, Corey. It was great.Corey: Jake Gold, infrastructure engineer at Bluesky, slash Blue-ski. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that will no doubt result in a surprise $60,000 bill after you posted.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

On this episode of Remote Ruby, Chris and his GoRails team is taking over since Jason and Andrew are traveling. Today, Chris has joining him Kent Crutchfield, who's a customer service expert for GoRails, and Collin Jilbert, who's a Ruby/Rails Dev at GoRails.  As we kick off this episode, we start by exploring a captivating debugging situation involving GoRails servers, the C language, and the operating system Kernel. Chris and Collin discuss their ongoing Hatchbox integration project, and Kent's expert handling of complex tasks. We also hear about Chris's new interactive forum series coming out soon, some advice for aspiring coders, and there's a discussion around tools like GitHub Copilot and their potential impact on developers' growth.  We'll wrap things up with Kent sharing his favorite part about joining the team, the rewarding experiences he's had, and the sheer love for his work in Ruby and Rails.  Hit download to hear much more! [00:00:58] Kent shares his background in customer support and how he started working at GoRails. [00:02:49] Chris and Collin discuss a challenging debugging situation they had to solve involving the C language, GoRails servers, and the operating system Kernel. They also remember a previous conversation regarding the complexities of CSS optimization at scale based on a talk from a GitHub employee. [00:07:50] The team has been working on Hetzner integration for Hatchbox, and despite the complexities of Hatchbox, Kent finds the challenges interesting and satisfying to overcome. He also highlights there are GoRails beginner-friendly content and new learning paths.[00:09:51] Chris is close to completing a new forum series for their learning path, transitioning from a blog format. The forum has topics, posts, and other features. He plans to add videos to their learning videos to their learning content in the future.[00:13:54] Collin and Chris discuss the importance of a practical approach to feature building, starting with the basics, and evolving through identifying potential issues and edge cases as they arise. [00:16:38] Kent suggests sticking to Rails defaults as much as possible and avoiding AWS for beginners. He also mentions that a lot of issues arise when users try to implement fancier features. [00:18:16] They discuss the SSL configuration complexity, Cloudflare's role as a proxy, and its implications on the application. Chris mentions the exceptional performance of Caddy in automating the SSL certification process and migrating problems related to domain set-up. [00:25:28] Kent shares some advice for aspiring coders to be consistent, read books, watch instructional videos like GoRails, and build something, no matter how small. Chris emphasizes the importance of learning how to debug.[00:30:59] Collin expresses concern that tools like GitHub Copilot might hinder developers' growth by offering ready-made solutions without a thorough understanding of the problem, and Chris suggests that Copilot is useful for repetitive tasks. [00:33:22] The discussion evolves around the importance of understanding the underlying code versus just getting a task done. Chris and Collin imply that this depends on the programmer's immediate goal, whether it's to ship the product quickly or to build something that won't break in the future. [00:39:10] What's been Kent's favorite thing about coming onto the team? He tells us it's learning Ruby and Rails while working in meaningful tasks, pairing with colleagues, addressing issues patiently and thoroughly, and he shares a rewarding experience.[00:41:26] What's been the worst thing for Kent about joining the team? Nothing! He loves learning and working in Ruby and Rails. Panelist:Chris OliverGuest Panelists:Kent CrutchfieldCollin JilbertSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterKent Crutchfield TwitterCollin Jilbert TwitterGoRailsGitHub's CSS Performance with Jon RohanGitHub's CSS Performance with Jon Rohan (vimeo)CaddyGitHub Copilot

In October 2022, 37signals announced they would transition off cloud services in a post titled "Why We're Leaving the Cloud."  Despite the advantages of the cloud, the downsides were too significant for the company. In this follow-up episode to Leaving the Cloud on REWORK, co-founder David Heinemeier Hansson and Director of Operations Eron Nicholson discuss the progress 37signals has made since they decided to leave the cloud. Listen in as they delve into the pros and cons of using the cloud versus owning your hardware and some of the misconceptions people have about cloud costs and expertise. Tune in as the pair shares insights from their experience running web applications at scale and offer advice, tips, and tools for startups and businesses looking to optimize their infrastructure. Join the discussion as they explore the importance of getting real about the costs of the cloud for small businesses.Show Notes:  [00:49] - David reflects on the progress made since the announcement to transition off of cloud services. And why their initial plan for help with the transition didn't work for 37signals' needs. [01:37] - How the experience with the failed deal to get help with the cloud transition reinforced the idea of why 37signals wanted to leave the cloud.[02:33] - David shares some tools that can be used to move out of the cloud, including Docker and Kubernetes. [04:21] - Why 37signals opted for a new tool they built called MRSK to assist in their transition and their timeline for being entirely out of the cloud.[06:11] - Bleeding money: The $38,000 motivator to speed up the timeline and free up cash that could be better spent elsewhere in the business.[08:33] - The tools: Eron and David discuss the tools (Docker and MRSK) they've used to successfully move two apps, Tadalist and Writeboard, from the cloud to their new system and the template in place for moving the rest of their apps. [11:08] - David discusses the criticality ladder they have in place to prioritize their move off the cloud, beginning with the lowest criticality app (Tadalist) before moving on to higher criticality apps like Hey, which deals with email and must always be available to users.[13:23] - The app transition plan for the next few months.[13:58] - Eron explains the challenges of staffing up for a project of this magnitude. He also highlights how many of their current AWS-related processes will become streamlined once they have their own infrastructure.[16:00] - David shares what the cloud is great for, why it doesn't work great for middle-range SaaS companies, and the main reasons for 37signals for bringing their infrastructure back in-house.[19:31] - Eron explains their advantage in moving back to their own infrastructure and why he hopes that their experience will encourage others to consider moving away from the cloud as well.[20:24] - Blowing the notion that the cloud is the only option to smithereens: David reflects on the lost knowledge of running your own hardware and the vendors who can help. [23:17] - Eron shares how you can lease from vendors like Deft, Digital Ocean, or Hetzner until it makes sense for you to buy your own servers.[23:46] - David discusses the importance of exploring alternatives to AWS, breaking the misconception that the cloud is the only option, and exploring the most cost-effective solution for your company. [26:04] - David responds to a comment suggesting they could have saved money by optimizing cloud costs and the possibly "crippling" variability of cloud costs that is a major concern for smaller companies—a risk eliminated by owning your own hardware. Watch David's YouTube video on MRSK.[27:57] - Eron explains how they worked to optimize their cloud spend using every single lever at their disposal within AWS, but despite all that effort, they still found that running their own hardware is more cost-effective than using the cloud.[28:48] - Do you have a question for Jason, David, or anyone at 37signals? Leave us a voicemail at 708-628-7850, and we might answer it on an upcoming show. Links and Resources:Do you have a question for Jason and David? Leave us a voicemail at 708-628-7850. Leaving the Cloud | REWORKDavid's YouTube video about MRSKHEY World | HEY Dev.37signalsBasecamp: New Customer Offer: $15 per user/per month or $299/month for unlimited users37signals on YouTubeThe REWORK podcastThe 37signals Dev Blog@reworkpodcast on Twitter@37signals on Twitter 

Da spielt wohl einiges mit rein! Was meint ihr? Zu hören gibt es den Podcast hier überall: https://open.spotify.com/show/0xlIih789FcMbZaASyhuAm https://podcasts.apple.com/de/podcast/speak-1337/id1577956101 https://podcasts.google.com/feed/aHR0cHM6Ly9hbmNob3IuZm0vcy9jODIxYjEwL3BvZGNhc3QvcnNz Alle meine Kanäle: https://bio.link/themorpheus

0:00 James didn't watch Clone Wars 0:12 Google layoffs, ChatGPT fears 1:36 Twitter bans third-party clients 2:58 MSI motherboards Secure Boot issue 4:26 Hetzner 5:12 QUICK BITS 5:24 T-Mobile data breach 5:57 KFC, Taco Bell, Pizza Hut ransomware attack 6:28 RX 6000 GPUs killed by washing? 7:19 Cablemod 12VHPWR cable melts 7:52 Wizards of the Coast apologizes NEWS SOURCES: https://lmg.gg/HcnjR

Listen to the Changelog: https://changelog.com/podcast/510TranscriptSo elastic compute makes sense, and scaling down because you have like ephemeral on-demand resource usage, right? Like, all of a sudden, I have to answer a bunch of HTTP requests, and so my server has to do stuff, and then everybody leaves, and my website doesn't get any hits, and I could scale that down. With databases, if I've got a one-gigabyte database, it's just like, it's always there. I mean, all that data is there, and I could access any part of it at any time, or I need to… And we don't know which parts. So I have a hard time with database scaling to zero, unless you're – I don't know, just like stomaching the cost… Or tell us how that works with Neon. Are you just stomaching the costs of keeping that online, or are you actually scaling it down?NIKITA SHAMGUNOVWe're actually scaling that down. Let me explain how this works, and it may get quite technical. The first thing is what should be the enabling technology of scaling that down? If you're just kind of thinking, “How would I build serverless Postgres?” and if you ask a person that is not familiar with database internals, they would say something like, “Well, I would put it in the VM maybe, or I would put it in the container, I would put that stuff into Kubernetes… Maybe I can change the size of the containers…” The issue with all that, as you start moving those containers around, it will start breaking connections, because databases like to have a persistent connection to them. And then you will be impacting your cache. Databases like to have a working set in memory, and if you don't have a working set of memory, you're paying the performance hit by bringing that data from cold storage to memory.The third thing that you will find out, that if the database is large enough, it's really, really hard to move database from host to host, because that involves data transfer, and data transfers are just long and expensive. And now you need to do it live, while the application is running and hitting the system. And so naively, you would arrive with something that you kind of proposed, like just stomach the costs. There is a better approach, though… And the better approach starts with an architectural change of separating of storage and compute.If you look at how databases, storage works at the high level, it's what is called a page-based storage; all the data in the database is split into 9-kilobyte pages. And the storage subsystem basically reads and writes those pages from disk, and caches those pages in memory. And then, kind of the upper-level system in the database lays out data on pages.So now you can separate that storage subsystem, and move that storage subsystem away from Compute into a cloud service. And because that storage subsystem operates is relatively simple from the API standpoint - the API is “read a page, write into a page”, then you can make that part multi-tenant. And so now you start amortizing costs across all your clients. So if you make that multi-tenant, and you make that distributed, and distribute key-value stores - you know, we've been building them forever, so it's not rocket science anymore - then you can make that key-value store very, very efficient, including being cost efficient. And cost efficiency comes from taking some of that data that's stored there and offloading cold data into S3.[20:13] Now, then it leaves out compute. And compute is the SQL query processor, and caching. So that, you can put in a VM. We actually started with containers, but we quickly realized that micro VMs such as Firecracker or Cloud-hypervisor is the right answer here. And those micro VMs have very, very nice properties to them. First of all, we can scale them to zero, and preserve the state. And they come back up really, really quickly. And so that allows to us to even preserve caches, if we shut that down.The second thing that allows us to do is live-changing the amount of CPU and RAM we're allocating to the VM. That's where it gets really tricky, because we need to modify Postgres as well, to be able to adjust to suddenly you have more memory, or shrink down to “Oh, all of a sudden, I have less memory now.” And so if you all of a sudden have less memory, you need to release some of the caches, and release this memory into the operating system, and then we change the amount of memory available to the VM. And there's a lot of cool technology there, with live-changing the amount of CPU, and there's another one that's called memory ballooning, that allows you to, at the end of the day, adjust the amount of memory available to Postgres.And then you can live-migrate VMs from host to host. Obviously, if you put multiple VMs on a host, they all started growing, at some point, you don't have enough space on the host. Now you do make a decision - which ones do you want to remove from the host? Maybe you have a brand new hosts available for them, with the space… But there is an application running, with a TCP connection, hitting that system> Storage is separate, so you only need to move the compute. And so now you're not moving terabytes of data with moving Postgres, you're just moving the compute part, which is really the caches, and caches only. But you need to perform a live migration here. So that's what we're doing with this technology that's called Cloud Hypervisor, that supports live migrations. And the coolest part is, as you're performing the live migration, you're not even terminating the TCP connection. So you can have the workload keep hitting the system as you change the size of the VM for the computer up and down, as well as you can change the host for that VM, and the application just keeps running… So yeah, that's kind of super-exciting technology.JEROD SANTOSo do you have your own infrastructure that this is running on, or are you on top of a public cloud, or how does that all work?NIKITA SHAMGUNOVSo we are on top of AWS. We know that we need to be on every public cloud, and that's where the users are… Now, this question kind of hits home a little bit; the cost can be at least ten times cheaper if we use something like, I don't know, Hetzner, or OVH. And in our architecture, it's super-important to have an object store as part of the architecture. So Amazon S3. And in the past, there was no alternative to S3. Like, no real alternative. But just a few weeks ago, Cloudflare released R2, and they made a GA. And all of a sudden, you can put cold data onto R2; we still don't know what the real reliability of R2 is, but I trust that Cloudflare will get it up there eventually. And that opens up all sorts of possibilities.The other one that we're looking into closely is Fly. We even have a shared Slack channel with Fly.io. I think it's a fantastic company, and I see a day where Neon will be running on Fly infrastructure as well.[23:52] Now, all that said, as of right now, right now we're only on Amazon, and we'll be adding another cloud. In which order, and what's going to come sooner, Fly or Google, for example, I can't really commit to, because we are continuously evaluating.JEROD SANTOYeah. So when you say move data off to S3, how do you deem data as cold on your customers' behalf? Because there have got to be some smarts in there.NIKITA SHAMGUNOVYeah, there's a lot of known algorithms, and they're mostly caching algorithms. So it's already happening today a little bit in Postgres; there is a buffer manager, a buffer pool… I'm maybe mixing SQL Server and Postgres terminology here, because my background is SQL Server. But the architecture is similar, where the buffer pool has a counter for every page, and it refreshes the counter of the pages touched… And then the algorithm kind of sweeps the cache and decides which pages haven't been touched for a while, and then evict them from the cache.Here we're adding another tier, in the remote storage. We also track pages, and you see which pages have been touched recently, and which have not been, and then you offload those pages onto S3. There is a caveat, however; S3 does not like small objects, and a page is 8 kilobytes. So we need to organize those pages into some sort of data structure that will bucket those pages together, so when we throw those pages onto S3, we throw a bunch of them together in a chunk. That data structure is called an LSM Tree, and that's the implementation of LSM tree that we built from scratch in Rust, and that's integrated with S3 offloads older data to S3. It's kind of like several use cases. One use case is a very large database; if you have a very large database, chances are large portions of that database are never even touched. So over time, some of that data - maybe it's the data from like, I don't know, five years ago, and you don't really need it, but you're keeping this there because it doesn't cost you much, and it's better to have them for occasional use that not have at all, or put them in a different system.And the other use case is you have a big fleet of databases; a lot of them are scaled down to zero, because you just have them for occasional usage, and now if you keep them hot, that will start to add up both on the compute side, and on the storage side. Storing all that data into SSDs is a very different economics than storing all that data in S3 in a compressed form. So these are the second place, where integration with S3 can drive much better economics.

Save 90% off your first for months of Freshbooks at https://www.freshbooks.com/wan Deploy a cloud server in seconds with Hetzner at https://linustechtips.hetzner.com/podcast-cloud Timestamps (Courtesy of NoKi1119) Note: Timing may be off due to sponsor change 0:00 Chapters 1:18 Intro 1:43 Topic #1 - "Pregnant" woman caught smuggling CPUs 4:14 Why smuggle tech into China? discussing item distribution 7:32 Brazil's tech import tariffs, American imports & exports 12:06 Smuggling to exploit tech shortage? 13:07 Topic #2 - New Arc driver, Arc challenge update 13:26 Intel's e-mail, criticizing Intel's Arc Control & its notifications 18:19 Only drivers matter for first-gen, Arc PC giveaway...on Arc Control 20:26 Luke won't update his driver until Arc Control informs him of it 20:55 Intel Support Assistant, Luke on the extended Arc booting 23:50 Performance graph of DirectX9 & driver performance uplift 26:42 Discussing Vulkan & Proton running DirectX9 29:40 Explaining the misconstrued chemistry between Linus-Luke 32:41 LTTStore Linus plushies moved to the bonus bins 33:36 Merch Messages #1 53:22 LTT's ZeroTier video idea 54:36 Sponsors 57:58 Topic #4 - Nintendo DMCA's DYKG's video on a 2004 Zelda pitch 59:21 Mentioning the source of the video's content, why did Nintendo do this? 1:01:00 Discussing NDA, hate tweet on DYKG, Activision-Blizzard 1:03:56 Nintendo "acknowledges" S&V bugs, "takes feedback seriously" 1:05:40 Linus considers not purchasing Nintendo products, mentions SMP 1:12:12 Where is the line drawn with these companies? 1:13:12 Merch Messages #2 1:24:23 Topic #5 - Markiplier's OF, proceedings to go to charities 1:26:14 How are nudes "tasteful"? 1:27:47 ChatGPT defines "tasteful nude photographs" 1:30:26 Merch Messages #3 1:37:56 Topic #6 - The Game Awards 2022 1:38:45 Valve was giving away Steam Decks, Elden Ring won GOTY 1:39:12 Kid mentioning Bill Clinton arrested, other previous stunts 1:40:05 Topic #7 - They're Just Movies podcast ended 1:43:15 Criticism online is personal Linus' & Luke's perspectives 1:47:14 Complimenting Luke, losing weight & building muscle 1:48:03 The name of the lab 1:48:32 Luke hosting videos once again, discussing OVH & Arc videos 1:50:48 Topic #8 - LTX2023 & Whale LAN page design & dates revealed 1:53:02 VIP packages, all-night Whale LAN, Luke's epic father & friend 1:55:28 PAX & LTX, possible quarterly LAN parties, special guests 1:59:43 Expo building, showcasing booths & games 2:06:04 Linus's potential investment on a NAS software start-up 2:11:01 Linus on DIY NAS mirrored storage issues, defining obtuse 2:17:18 Topic #9 - Apple scraps CSAM, encrypts iCloud 2:19:05 Topic #10 - Xbox games are now up to $70 2:21:00 Topic #11 - Adobe Stock to sell generated AI stock images 2:24:19 Merch Messages #4 2:32:53 Topic #12 - Stack Overflow banned ChatGPT 2:36:23 Luke's thoughts on ChatGPT version 4 2:38:27 Invalidity of ChatGPT answers, defining why it was banned 2:40:28 Using large language models on game development 2:43:30 Luke's ideal sandwich, ranting about killing Quadro 2:45:26 Any notable tattoos around the company? 2:45:48 How long until Arc is competitive in the professional market? 2:46:37 Would LTT accept Nintendo as a sponsor for LTX? 2:46:58 Favorite pieces of tech to use in the kitchen 2:48:28 Outro

Save money on your phone plan today at https://www.mintmobile.com/wanshow Deploy a cloud server in seconds with Hetzner at https://www.hetzner.com/cloud?pk_source=youtube&pk_content=yt-cloud-2022 Get Exclusive NordSecurity deals here ➼ https://nordsecurity.com/wan - All products are risk-free with Nord's 30-day money-back guarantee! Timestamps (Courtesy of NoKi1119) Note: Timing may be off due to sponsor change 0:00 Chapters 1:48 Intro 2:13 Topic #1 - Mistakes on LTT's RTX 4080 video 2:48 4080 sold out, pricing, advocating for change 8:15 Linus counters community arguments 13:32 High last-gen emphasis in the review 14:46 Lack of AMD discussions in the review 15:29 Linus apologizes, reasons his decisions 16:36 AMD cards not priced well, discussing competition 19:07 Topic #2 - Linus & Luke 30 day Arc challenge 19:24 Linus's & Luke's power "mods" 22:46 Linus's disappointment on VR, reaching staff 25:04 Luke's idea to Linus's Arc & Linux systems 26:33 Linus & Luke streamed gaming on Arc 28:32 LTTStore customer support delays ft. Luke's bird 30:16 Labeled shipments show as shipping when not 32:45 LTTStore's Retro Polar Fleece 33:44 Topic #3 - The last seven days in Twitter 34:32 Luke on companies firing/hiring 37:36 Engineer corrects Elon, gets fired 41:52 Luke meets Twitter employee in Serbia 42:42 Linus on at-will, Luke hushes birds 44:02 Badge system removed, "public" Slack channel 45:36 Blind, a better localized anonymous version of LinkedIn 47:16 Elon response, end-to-end DM encryption 49:34 "Be extremely hardcore or leave" 52:12 Employees locked out after blue badge removal 52:28 Sponsors 55:36 Companies should hire employees, discussing Visas 56:18 Discussing Luke's bird & feeding 57:04 Sponsor continued 57:44 Linus to head off to an event 58:22 LMG & Creators Warehouse hiring many positions 59:28 Topic #4 - FTX collapses, Riley writing in the doc 1:01:06 Merch Messages #1 1:01:36 Luke on dive computers 1:03:37 Any advantage to 2 PCI-Es on larger GPUs? 1:05:54 Riley takes over, everything goes downhill 1:09:26 Riley on writing the doc, Luke on coverage 1:12:04 Riley on Twitter's viability & usability 1:14:20 Discussing Andor 1:16:24 Discussing Taskmaster 1:18:15 Luke explains FTX, owner playing LOL during conference calls 1:21:06 Binance backed out bailing FTX out 1:23:10 Regulating cryptocurrency defeated its purpose 1:26:42 Luke on losing coins VS losing value 1:28:42 Topic #5 - Pokémon Scarlet and Violet 1:29:32 Luke's favorite Pokémon 1:32:58 Game graphics & performance issues, Switch & emulation 1:39:49 Topic #6 - DOOM Eternal OST controversy 1:41:04 Summarizing OST release, Marty's reddit post 1:43:25 Mick Gordon's detailed rebuttal, game developing 1:48:44 Luke on gaming scenes & gamers review-bombing 1:52:38 Topic #7 - PeopleMakeGames calls Valve out on gambling 1:54:48 Twitch banning unregulated gambling content 1:56:56 CS:GO gambling sites thrive, discussing loot boxes 1:59:36 Why doesn't Valve do anything against this? 2:01:32 AK-47 Case Hardened #661 sold for $400,000 2:04:02 Whose responsibility is this? ft. Luke hushing birds 2:09:16 Video Game Attorney on platforms manipulating drops 2:11:28 Topic #8 - Apple sued for collecting data in Apple apps 2:14:54 Riley on Apple misleading users & lack of privacy 2:17:16 Did Luke believe Apple's security? 2:20:28 Merch Messages #2 2:20:48 Using external GPUs for Blender 2:30:14 Outro

Heya Cryptozens, Episode 364: CZ-SBF Google Node Hetzner Online Saga Smartphone Circle's Euro Stable It's 10 PM Pacific time and the date is November 6th, 2022. Welcome back to the Crypto Overnighter. My name is Nikodemus, I'll be your host as we take a nightly look at the crypto, nft and metaverse space and the industry that surrounds it. And keep in mind, nothing in this show should ever be considered financial advice.  Email: nick@cryptoovernighter.com Salem Friends of Felines: https://sfof.org/ Twitter: https://twitter.com/CryptoCorvus1

The Solana blockchain narrowly averted another network outage as cloud service provider Hetzner turned off 40% of the nodes with the flip of a switch. The issue isn't unique to Solana, and centralized providers host up to 70% of Ethereum's nodes. Cryptocurrency is built on the premise of decentralized participation, but there are strong economic incentives that push many node operators toward centralized hosting solutions. In today's post, we will examine why centralization is so common in an ecosystem that prides itself on being decentralized. #sol #eth #crypto

Join our community on Reddit: https://www.reddit.com/r/MissionDeFi/ The Block: 1,000 Solana validators go offline as Hetzner blocks server access - https://www.theblock.co/post/182283/1000-solana-validators-go-offline-as-hetzner-blocks-server-access Alameda is a hot mess - https://twitter.com/DylanLeClair_/status/1587890966580658177 Binance to buy banks? - https://www.coindesk.com/business/2022/11/02/binance-ceo-zhao-considering-buying-banks-report/ Fantom pump Why? Stupid - https://twitter.com/tree_of_alpha/status/1588109594567524352?s=52&t=u7cpstXHNbstG40SCgvhRA Joe Cawley and Brad Nickel cover the DeFi news of the day, new opportunities in the space including liquidity pools, yield farming, staking, and much more. This is not financial advice. Nothing said on the show should be considered financial advice. This is just the opinions of Brad Nickel, Joe Cawley, and our guests. None of us are financial advisors. Trading, participating, yield farming, liquidity pools, and all of DeFi and crypto is high risk and dangerous. If you decide to participate, do your own research. Never count on the research of others. We don't know what we are talking about and you can lose all your money. Never invest more than you can afford to lose, because you probably will lose it all. --- Support this podcast: https://anchor.fm/missiondefi/support

In this episode, we talk to Kadan – CTO of Komodo, integrated ecosystem platform and developer of the AtomicDEX. Ecosystem consists of: - AtomicDEX. A non-custodial wallet and atomic swap DEX rolled into one application. - Workshop and open technology educational hub. Kadan's Twitter (https://twitter.com/0xca333) We spoke to Kadan about Komodo, and: Kadan's intro Cross-chain atomic swap & KYC Komodo Roadmap & IBC compatibility DEXes & Komodo Platform history The role of blockchain in society How do we gain more decentralization? Is Komodo still a private network? The key infrastructure of the Internet Is Web3 already here? Komodo's own Cosmos chain Incentivizing & Technical singularity Top 3 projects to follow Motivation & The influencer to follow The projects and people that have been mentioned in this episode: | Tendermint (https://tendermint.com/) | Cosmos (https://cosmos.network/) | Komodo Platform (https://komodoplatform.com/en/) | AtomicDex (https://atomicdex.io/en/) | Cosmoverse (https://cosmoverse.org/) | OpSec (https://en.wikipedia.org/wiki/Operations_security) | Tesla (https://www.tesla.com/) | Ethereum (https://ethereum.org/en/) | Bitcoin (https://bitcoin.org/en/) | Hetzner (https://www.hetzner.com/) | Tether (https://tether.to/) | Tezos (https://tezos.com/) | If you like what we do at Citizen Cosmos: Stake with Citizen Cosmos validator (https://www.citizencosmos.space/staking) Help support the project via Gitcoin Grants (https://gitcoin.co/grants/1113/citizen-cosmos-podcast) Listen to the YouTube version (https://youtu.be/t6Hp7LCuAw8) Read our blog (https://citizen-cosmos.github.io/blog/) Check out our GitHub (https://github.com/citizen-cosmos/) Join our Telegram (https://t.me/citizen_cosmos) Follow us on Twitter (https://twitter.com/cosmos_voice) Sign up to the RSS feed (https://www.citizencosmos.space/rss) Special Guest: Kadan Stadelmann.

Try FreshBooks free, for 30 days, no credit card required at https://www.freshbooks.com/wan Deploy a cloud server in seconds with Hetzner at https://www.hetzner.com/cloud?pk_source=youtube&pk_content=yt-cloud-2022 Get Exclusive NordSecurity deals here ➼ https://nordsecurity.com/wan All products are risk-free with Nord's 30-day money-back guarantee! Timestamps (Courtesy of NoKi1119) Note: Timing may be off due to sponsor change 0:00 Chapters 1:06 Intro 1:36 Topic #1 - NVIDIA unlaunches RTX "4080 12GB" 2:30 NVIDIA's misleading cards naming 7:18 History of shameful corporal behavior 10:06 NVIDIA's "apology" showcases store queues 11:38 LTT's video on ARC for AV1, ideas & GPUs discussion 14:52 Topic #2 - Google AI struggles with FP's Privacy Policy 19:22 YouTube's Creator Summit, issues with AI 23:32 Topic #3 - Netflix launches ad-based subscription 26:16 Rate of ads per hour, interrupting movies 28:56 Discussing ad blocking & downgrading 33:42 LTTStore new merch 34:36 LTTStore beanie colors 35:53 LTTStore backpack updates 37:24 Merch Messages #1 37:30 Noctua's paste guard 38:36 Tech tips for toddlers & babies, discussing Yeezy's 46:00 Linus's thoughts on EV bikes 49:26 Topic #4 - Sony is against Microsoft-Blizzard acquisitions 51:28 Counter-arguments, Microsoft's article 55:42 Luke on another Blizzard lawsuit 59:24 Sponsors 1:02:00 Failing to call Colton Potter 1:03:12 Topic #5 - Meta's Quest Pro VR headset 1:05:48 Discussing price & specs 1:08:33 Moore's law, generational leaps 1:12:06 AI erases NHL players 1:14:46 Discussing Meta 3, Meta 2 Amazon reviews 1:17:19 Colton Potter announces LTX 2023 dates 1:19:55 Topic #6 - Discussing Mark Bench 1:20:32 Weird data on LTT's RTX 4090 video 1:22:46 Topic #7 - Microsoft Surface Pro 8 & X 1:23:01 Discussing pricing & specs, all-Intel 1:23:44 Microsoft Surface Studio 2 Plus 1:24:04 Merch Messages #2 1:24:13 Did Linus try playing pickleball? 1:25:25 Tips for transitioning into adult independence 1:26:02 Whale investors 1:32:08 Experiencing issues after PC building 1:34:08 Would LOUQE go out of business? 1:38:58 Software development & testing 1:41:45 SoundCore Sleep A10 1:42:01 Why not use OpenBenchmarking? 1:43:54 Convincing a boss to invest, LMG content exclusivity 1:50:14 FP Poll: to use exclusives occasionally? 1:53:54 Outro

0:00 lotta tech news round these parts 0:05 Stadia is over 1:44 DALL-E open to all, Meta text-to-video 2:45 more ARC info, Acer's GPU 3:59 Hetzner 4:35 QUICK BITS 4:41 Razer Edge 5G 5:22 dbrand pulls Killswitch launch 6:04 Bruce Willis is a deepfake now 6:32 Wing delivery drone kills power 7:01 Tesla AI Day - bot or no bot? News Sources: https://lmg.gg/QW08O

Save money on your phone plan today at https://www.mintmobile.com/wanshow Make compliance easy with Kolide at: https://l.kolide.co/3mOs6it Deploy a cloud server in seconds with Hetzner at https://www.hetzner.com/cloud?pk_source=youtube&pk_content=yt-cloud-2022 Timestamps: (Courtesy of NoKi1119 - Note: Timestamps may be off due to sponsor change) 0:00 Chapters 1:52 Intro 2:20 LTT sponsored MKBHD's ARC PC build 4:36 Topic #1 - NVIDIA's RTX 4000 update 5:38 Performance claims, NVIDIA V.S. gamer roleplay 9:02 Board design & cost per wafer's size 18:04 What can we do about the MSRP? 21:02 AMD's RDNA3, compared to M1 Ultra, "Linus is biased" 24:00 Luke is scuba certified, Taiwan diving 24:34 Linus returns with watercooled Vega 64 26:36 Linus showcases Radeon VII 27:16 Linus on R280, Fury & better hardware 31:26 Discussing price increase through the years 35:15 Simulating inflation, NVIDIA's progress, dead pixels recall for OLED 38:32 Was this MSRP to get rid of RTX 3000? 40:54 Topic #2 - Logitec G Cloud handheld 41:06 Funny specifications on the product page 44:52 Reading reviews & user rating 48:12 Linus tries to write a review 50:00 Sponsors 53:00 LTTStore elemental shirt discount 53:34 LTTStore Cargo shorts 55:28 Linus's written review, filtered out 57:36 Linus writes a joke review for Luke 1:00:32 If Deck didn't exist, would it be good? 1:02:11 Reason behind elemental shirt stock 1:04:30 Topic #3 - LTT in Español 1:06:22 Planned AI-generated voice 1:09:08 Linus shows off video 1:10:46 Merch Messages #1 1:11:00 Why are local pricing for GPUs high? 1:12:21 ASUS PG42UQ ghosting & Windows snap 1:13:06 Traffic after MKBHD collab, excitement towards lab ft pizza 1:18:46 Cloud computing, Chromebook V.S. ThinkPad 1:24:02 Linus on MKBHD collab's impact 1:25:40 Giving the video another shot 1:28:48 Topic #4 - Twitch changes revenue splits 1:31:00 Quoting Twitch's changes 1:34:44 Twitch bans some gambling streams, talking YT VODs & revene impact 1:42:26 Topic #5 - Framework Chromebook Edition 1:42:38 Specifications & thoughts 1:45:22 Discussing sustainability & what Twitch should do 1:49:32 YouTube shorts revenue, discussing TikTok evading copyright 1:54:40 Requirements to be eligible for revenue 1:55:07 Licensed music, do they belong in LTT? 1:57:50 Topic #6 - videogamedunkey's BIGMODE 1:58:44 Community response, impact on indie games 2:06:58 BIGMODE website, lack of responses 2:08:20 Merch Messages #2 2:08:26 Favorite gift given or received 2:11:00 Pros to cons using 220V on PSU 2:11:32 With EVGA out, would others fill the space? 2:12:20 Running Windows on VM reliably 2:13:10 Do you miss not needing as many devices? 2:15:08 YouTube Shorts is addictive 2:16:52 Linus's review on Sony A95K TV 2:17:40 Which Zen 4 CPU for future proofing? 2:19:14 Challenges with NA-based manufacturers for LTTStore 2:23:30 Thoughts on new PSU specs 2:24:51 Linus's wire fraud 2:25:10 Avoiding quantum tunneling via 3D stacking 2:25:36 Would LTTStore become a hub to sell YouTubers merch? 2:35:00 What games are you currently enjoying? 2:37:25 Outro

See omnystudio.com/listener for privacy information.

Drop 1: Drife, Blockchain-Uber https://spectrum.ieee.org/blockchain-ridehailing-app-drife-takes-on-uber-in-india Drop 2: Ethereum banido de serviço de nuvem https://www.thedefiant.io/data-giant-shocks-ethereum-with-ban-on-mining Drop 3: Nova turma do Lift do BCB https://www.bcb.gov.br/detalhenoticia/627/noticia .. Netflix usando NFTs para capturar engajamento de audiência https://nftnow.com/culture/netflix-is-using-nfts-to-harvest-engagement-data-and-tv-may-never-be-the-same/ Eminem e Snoop Dogg dão show com seus Bored Apes no MTV Awards https://youtu.be/0GW3TWBlQgE MTV Awards, Metaverse Performance vai para BLACKPINK, banda de Kpop da NZ, por show no PUBG https://www.zoomtventertainment.com/korean/k-pop-takes-center-stage-at-mtv-vmas-2022-with-four-historic-wins-korean-entertainment-kpop-news-article-93847553 Inevitable lança Wallet Bound Tokens https://inevitable.education/insights/wallet-bound-tokens/ Argentina's wine-making haven now accepts crypto as tax payment https://www.theblock.co/post/166324/security NovaDAX anuncia launchpad https://www.infomoney.com.br/mercados/exchange-novadax-anuncia-nova-plataforma-que-permite-comprar-criptos-antes-do-lancamento/ MAS: não vai adiantar banir varejo em cripto https://blockworks.co/singapore-says-crypto-ban-for-retail-not-likely-to-work/ Hashdex recebe aprovação pra ETF na Europa em tempo recorde http://cryptocurrency.packagingnewsonline.com/the-crypto-manager-hashdex-wins-the-european-sesame-in-record-time/ Ripio lança cartão com 5% de cashback em Bitcoin https://bitcoinmagazine.com/business/ripio-launches-ripio-card-offering-5-bitcoin-cashback Ticketmaster usa Flow da Dapper Labs para NFTickets https://decrypt.co/108627/ticketmaster-chooses-dapper-labs-flow-blockchain-for-nft-tickets Helium vai trocar de Blockchain https://fortune.com/2022/08/31/hotspot-helium-considering-solana-blockchain/ --- Send in a voice message: https://anchor.fm/blockdropspodcast/message

Welcome to The Chopping Block! Crypto insiders Haseeb Qureshi and Tom Schmidt chop it up about the latest news in the digital asset industry. In this episode, Jill Gunter, the empress of Espresso, also joined the conversation.    Show topics: Whether product management is the new consulting What is going to happen with macroeconomics and whether monetary policy is data-driven Why Jill's faith is getting renewed, especially after listening to Fed authorities The TL;DR on the Ava Labs conspiracy story Why the industry needs a decentralized RPC The role of Flashbots and Ethermine in censoring transactions  Potential over-compliance from the biggest crypto projects on how to deal with sanctioned addresses Whether social slashing allows Ethereum to stay uncensored The importance of educating regulators on crypto What Haseeb thinks lawyers would recommend to Coinbase about validating transactions from sanctioned addresses The significance of both transactional and application-layer privacy How stablecoin providers need to implement some basic levels of privacy Why corporations do not run Ethereum and whether users are pro-OFAC restrictions Hosts Haseeb Qureshi, managing partner at Dragonfly Capital https://twitter.com/hosseeb Tom Schmidt, general partner at Dragonfly Capital https://twitter.com/tomhschmidt   Guest Jill Gunter Twitter: https://twitter.com/jillrgunter Episode Links   Tornado Cash Treasury Press release  Tornado Cash developer arrested  Circle freezes USDC in sanctioned wallets Crypto exchange dYdX blocked accounts that received funds from Tornado Cash What the sanctions mean for privacy coins Celebrities get dusted Previous coverage of the Tornado Cash Sanctions on Unchained: Is TRM Labs Blocking Addresses From DeFi Protocols? Ari Redbord Says No  Tornado Cash Sanctioned. Did the Government Overstep Its Bounds? The Chopping Block: Did OFAC Overstep by Sanctioning Tornado Cash? Ava Labs Accusations: CoinDesk article  Crypto Leaks article   Social Slashing and Censorship on ETH Axios summary of the situation BitMex research on how the sanctions affect Ethereum Ethermine banning transactions Nic Carter's article Eric Wall's article on social slashing Hetzner banning Ethereum users Previous Coverage on Unchained Given the Sanctions on Tornado Cash, Is Ethereum Censorship Resistant?

It's the weekend edition of CoinMarketRecap! Connor Sephton and Molly Jane Zuckerman have a whistle-stop tour of this week's biggest crypto headlines. Michael Saylor's being sued for tax fraud — how damaging will this be financially and reputationally? Hetzner and OpenSea speak out as The Merge looms. A top crypto lawyer steps back from class action lawsuits after embarrassing, secretly recorded videos emerge. Crypto.com's made a $7 million typo — but is it entitled to get the money back? And Twitter's adding an edit button… yea or nay? You can follow us on Twitter — @MollyJZuckerman, @ConnorSephton and @CoinMarketCap.

Welcome to The Chopping Block! Crypto insiders Haseeb Qureshi and Tom Schmidt chop it up about the latest news in the digital asset industry. In this episode, Jill Gunter, the empress of Espresso, also joined the conversation.    Show topics: Whether product management is the new consulting What is going to happen with macroeconomics and whether monetary policy is data-driven Why Jill's faith is getting renewed, especially after listening to Fed authorities The TL;DR on the Ava Labs conspiracy story Why the industry needs a decentralized RPC The role of Flashbots and Ethermine in censoring transactions  Potential over-compliance from the biggest crypto projects on how to deal with sanctioned addresses Whether social slashing allows Ethereum to stay uncensored The importance of educating regulators on crypto What Haseeb thinks lawyers would recommend to Coinbase about validating transactions from sanctioned addresses The significance of both transactional and application-layer privacy How stablecoin providers need to implement some basic levels of privacy Why corporations do not run Ethereum and whether users are pro-OFAC restrictions Hosts Haseeb Qureshi, managing partner at Dragonfly Capital https://twitter.com/hosseeb Tom Schmidt, general partner at Dragonfly Capital https://twitter.com/tomhschmidt   Guest Jill Gunter Twitter: https://twitter.com/jillrgunter Episode Links   Tornado Cash Treasury Press release  Tornado Cash developer arrested  Circle freezes USDC in sanctioned wallets Crypto exchange dYdX blocked accounts that received funds from Tornado Cash What the sanctions mean for privacy coins Celebrities get dusted Previous coverage of the Tornado Cash Sanctions on Unchained: Is TRM Labs Blocking Addresses From DeFi Protocols? Ari Redbord Says No  Tornado Cash Sanctioned. Did the Government Overstep Its Bounds? The Chopping Block: Did OFAC Overstep by Sanctioning Tornado Cash? Ava Labs Accusations: CoinDesk article  Crypto Leaks article   Social Slashing and Censorship on ETH Axios summary of the situation BitMex research on how the sanctions affect Ethereum Ethermine banning transactions Nic Carter's article Eric Wall's article on social slashing Hetzner banning Ethereum users Previous Coverage on Unchained Given the Sanctions on Tornado Cash, Is Ethereum Censorship Resistant?

Hetzner va a subir un 10% a sus productos… lo hará por los precios de la energía a partir de este primero de septiembre 2022

Hetzner va a subir un 10% a sus productos… lo hará por los precios de la energía a partir de este primero de septiembre 2022

Andrew Hinkes, partner at K&L Gates and adjunct professor at NYU, and Martin Koeppelman, co-founder of Gnosis, talk about the sanctions on Tornado Cash, how they will impact Ethereum on the base layer, and the likelihood of having two chains.    Show highlights: the legal meaning of the OFAC sanctions on Tornado Cash and why it is causing complications how legislation is built for the fiat world, and how in DeFi and crypto there's no clarity  how miners have changed their behavior prior to the Merge whether a proof of work chain or a proof of stake chain would be more censorship resistant whether laws apply to validators in a PoS chain the ways in which the government could provide more clarification  the different entities involved in Proof of Stake the liabilities for each entity in PoS and what secondary liability is how the task of the bidder can be described as a mathematical optimization problem whether Lido is exposed to US regulations how long would it take for a large staker like Coinbase to stop being a validator how a user-activated soft fork works and the conditions in which a fork could happen whether social slashing is enforceable considering it is not in the protocol the likelihood of Ethereum becoming a permissioned system the role of Flashbots' relay code and what it means for Ethereum's censorship resistance how DeFi's exposure to US-based institutions can affect the likelihood of the chain complying with sanctions whether DAI is just wrapped USDC how MakerDAO is trying to be more independent of USDC why US-based companies will choose a conservative path, considering the lack of guidance the importance of educating the regulators  how cash and crypto are the only remaining private payment methods  Thank you to our sponsors!   Crypto.com: https://crypto.onelink.me/J9Lg/unconfirmedcardearnfeb2021 Ava Labs: https://avax.network a16z: https://link.chtbl.com/HObAJQDL?sid=unchained   Andrew Twitter: https://twitter.com/propelforward   Martin Twitter: https://twitter.com/koeppelmann   Previous Coverage of the Tornado Cash Sanctions on Unchained: Is TRM Labs Blocking Addresses From DeFi Protocols? Ari Redbord Says No: https://unchainedpodcast.com/is-trm-labs-blocking-addresses-from-defi-protocols-ari-redbord-says-no-ep-387/ Tornado Cash Sanctioned. Did the Government Overstep Its Bounds?: https://unchainedpodcast.com/tornado-cash-sanctioned-did-the-government-overstep-its-bounds-ep-384/ The Chopping Block: Did OFAC Overstep by Sanctioning Tornado Cash?: https://unchainedpodcast.com/the-chopping-block-did-ofac-overstep-by-sanctioning-tornado-cash-ep-386/     Social Slashing and Censorship on ETH Axios summary of the situation: https://www.axios.com/2022/08/23/how-transactions-might-be-censored-after-ethereum-changes-next-month   BitMex research on how the sanctions affect Ethereum: https://blog.bitmex.com/ofac-sanctions-ethereum-pos-some-technical-nuances/   Ethermine banning transactions: https://twitter.com/takenstheorem/status/1560690035955011585?s=20&t=59hWdhr8_O-hYA8uYnZJ8w   Nic Carter's article: https://www.coindesk.com/layer2/2022/08/25/if-ethereum-starts-slashing-it-burns/   Eric Wall's article on social slashing: https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7   CoinDesk article: https://www.coindesk.com/tech/2022/08/23/as-censorship-on-ethereum-begins-could-this-open-sourced-code-help-counter-it/?outputType=amp   Hetzner banning Ethereum users: https://twitter.com/koeppelmann/status/1563146729314467840?s=20&t=ubFhCQqrQyHKfflgMHEmJw   Tornado Cash Treasury Press release:  https://home.treasury.gov/news/press-releases/jy0916#:~:text=WASHINGTON%20%E2%80%93%20Today%2C%20the%20U.S.%20Department,since%20its%20creation%20in%202019 Developer arrested: https://www.fiod.nl/arrest-of-suspected-developer-of-tornado-cash/ Rep. Emmer's letter: https://twitter.com/RepTomEmmer/status/1562084891247902721?s=20&t=9J3c3scVdxsLKVcFovaWdQ Tornado Cash post on compliance: https://tornado-cash.medium.com/tornado-cash-compliance-9abbf254a370 Coin Center's article authored by Jerry Brito and Peter Van Valkenburgh: https://www.coincenter.org/u-s-treasury-sanction-of-privacy-tools-places-sweeping-restrictions-on-all-americans/ Second Coin Center article authored by Jerry Brito and Peter Van Valkenburgh: https://www.coincenter.org/analysis-what-is-and-what-is-not-a-sanctionable-entity-in-the-tornado-cash-case/ Coin Center may challenge the US Treasury's decision to sanction Tornado Cash: https://decrypt.co/107475/coin-center-tornado-cash-ban-court What the sanctions mean for privacy coins: https://www.coindesk.com/layer2/2022/08/09/what-the-tornado-cash-sanction-means-for-privacy-coins/ Celebrities get Dusted: https://decrypt.co/es/107090/tornado-cash-dusts-public-wallets-jimmy-fallon-brian-armstrong-steve-aoki-logan-paul   DAI and USDC Maker forum: https://forum.makerdao.com/t/the-path-of-compliance-and-the-path-of-decentralization-why-maker-has-no-choice-but-to-prepare-to-free-float-dai/17466 https://decrypt.co/107273/makerdao-founder-dai-drop-dollar-peg-tornado-cash-usdc Circle freezes USDC in sanctioned wallets: https://www.theblock.co/post/162172/circle-freezes-usdc-funds-in-tornado-cashs-us-treasury-sanctioned-wallets      Flashbots Flashbots relay open source: https://twitter.com/hasufl/status/1559908331145265156?s=20&t=gtHe5sVetxQXVKfZL2VMYg MEV Boost: https://www.alchemy.com/overviews/mev-boost MEV in ETH PoS: https://writings.flashbots.net/writings/mev-boost-call-for-testing Proposer-Builder separation: https://www.alchemy.com/overviews/proposer-builder-separation

Los problemas de la centralización en la validación de bloques de una blockchain están saliendo a la luz. Hetzner es el primer servicio en la nube que prohibe el alojamiento de servicios cripto de cualquier tipo, esto impacta directamente en varios proyectos cripto, pero sobre todo aquellos que no pueden costear una validación sin el uso de intermediarios

Andrew Hinkes, partner at K&L Gates and adjunct professor at NYU, and Martin Köppelmann, co-founder of Gnosis, talk about the sanctions on Tornado Cash, how they will impact Ethereum on the base layer, and the likelihood of having two chains.    Show highlights: the legal meaning of the OFAC sanctions on Tornado Cash and why it is causing complications how legislation is built for the fiat world, and how in DeFi and crypto there's no clarity  how miners have changed their behavior prior to the Merge whether a proof of work chain or a proof of stake chain would be more censorship resistant whether laws apply to validators in a PoS chain the ways in which the government could provide more clarification  the different entities involved in Proof of Stake the liabilities for each entity in PoS and what secondary liability is how the task of the bidder can be described as a mathematical optimization problem whether Lido is exposed to US regulations how long would it take for a large staker like Coinbase to stop being a validator how a user-activated soft fork works and the conditions in which a fork could happen whether social slashing is enforceable considering it is not in the protocol the likelihood of Ethereum becoming a permissioned system the role of Flashbots' relay code and what it means for Ethereum's censorship resistance how DeFi's exposure to US-based institutions can affect the likelihood of the chain complying with sanctions whether DAI is just wrapped USDC how MakerDAO is trying to be more independent of USDC why US-based companies will choose a conservative path, considering the lack of guidance the importance of educating the regulators  how cash and crypto are the only remaining private payment methods  Thank you to our sponsors!   Crypto.com: https://crypto.onelink.me/J9Lg/unconfirmedcardearnfeb2021 Ava Labs: https://avax.network a16z: https://link.chtbl.com/HObAJQDL?sid=unchained   Andrew Twitter: https://twitter.com/propelforward   Martin Twitter: https://twitter.com/koeppelmann   Previous Coverage of the Tornado Cash Sanctions on Unchained: Is TRM Labs Blocking Addresses From DeFi Protocols? Ari Redbord Says No: https://unchainedpodcast.com/is-trm-labs-blocking-addresses-from-defi-protocols-ari-redbord-says-no-ep-387/ Tornado Cash Sanctioned. Did the Government Overstep Its Bounds?: https://unchainedpodcast.com/tornado-cash-sanctioned-did-the-government-overstep-its-bounds-ep-384/ The Chopping Block: Did OFAC Overstep by Sanctioning Tornado Cash?: https://unchainedpodcast.com/the-chopping-block-did-ofac-overstep-by-sanctioning-tornado-cash-ep-386/     Social Slashing and Censorship on ETH Axios summary of the situation: https://www.axios.com/2022/08/23/how-transactions-might-be-censored-after-ethereum-changes-next-month   BitMex research on how the sanctions affect Ethereum: https://blog.bitmex.com/ofac-sanctions-ethereum-pos-some-technical-nuances/   Ethermine banning transactions: https://twitter.com/takenstheorem/status/1560690035955011585?s=20&t=59hWdhr8_O-hYA8uYnZJ8w   Nic Carter's article: https://www.coindesk.com/layer2/2022/08/25/if-ethereum-starts-slashing-it-burns/   Eric Wall's article on social slashing: https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7   CoinDesk article: https://www.coindesk.com/tech/2022/08/23/as-censorship-on-ethereum-begins-could-this-open-sourced-code-help-counter-it/?outputType=amp   Hetzner banning Ethereum users: https://twitter.com/koeppelmann/status/1563146729314467840?s=20&t=ubFhCQqrQyHKfflgMHEmJw   Tornado Cash Treasury Press release:  https://home.treasury.gov/news/press-releases/jy0916#:~:text=WASHINGTON%20%E2%80%93%20Today%2C%20the%20U.S.%20Department,since%20its%20creation%20in%202019 Developer arrested: https://www.fiod.nl/arrest-of-suspected-developer-of-tornado-cash/ Rep. Emmer's letter: https://twitter.com/RepTomEmmer/status/1562084891247902721?s=20&t=9J3c3scVdxsLKVcFovaWdQ Tornado Cash post on compliance: https://tornado-cash.medium.com/tornado-cash-compliance-9abbf254a370 Coin Center's article authored by Jerry Brito and Peter Van Valkenburgh: https://www.coincenter.org/u-s-treasury-sanction-of-privacy-tools-places-sweeping-restrictions-on-all-americans/ Second Coin Center article authored by Jerry Brito and Peter Van Valkenburgh: https://www.coincenter.org/analysis-what-is-and-what-is-not-a-sanctionable-entity-in-the-tornado-cash-case/ Coin Center may challenge the US Treasury's decision to sanction Tornado Cash: https://decrypt.co/107475/coin-center-tornado-cash-ban-court What the sanctions mean for privacy coins: https://www.coindesk.com/layer2/2022/08/09/what-the-tornado-cash-sanction-means-for-privacy-coins/ Celebrities get Dusted: https://decrypt.co/es/107090/tornado-cash-dusts-public-wallets-jimmy-fallon-brian-armstrong-steve-aoki-logan-paul   DAI and USDC Maker forum: https://forum.makerdao.com/t/the-path-of-compliance-and-the-path-of-decentralization-why-maker-has-no-choice-but-to-prepare-to-free-float-dai/17466 https://decrypt.co/107273/makerdao-founder-dai-drop-dollar-peg-tornado-cash-usdc Circle freezes USDC in sanctioned wallets: https://www.theblock.co/post/162172/circle-freezes-usdc-funds-in-tornado-cashs-us-treasury-sanctioned-wallets      Flashbots Flashbots relay open source: https://twitter.com/hasufl/status/1559908331145265156?s=20&t=gtHe5sVetxQXVKfZL2VMYg MEV Boost: https://www.alchemy.com/overviews/mev-boost MEV in ETH PoS: https://writings.flashbots.net/writings/mev-boost-call-for-testing Proposer-Builder separation: https://www.alchemy.com/overviews/proposer-builder-separation

Today's blockchain and cryptocurrency news Brought to you by watchthiscards.com Bitcoin is up slightly at $20,227 Ethereum is up slightly at $1505 and Binance Coin up slightly at $283 Cloud provider Hetzner says Ethereum nodes on their cloud violate TOS. MAS asks for details from firms ahead of more regulation. SushiSwap community votes to decrease Head Chef salary. eth.link expires 9/5 — Virgil Griffith currently unable to renew from behind bars.

Offchain Labs releases the Arbitrum Nitro white paper, Hetzner prohibits node operators, SpruceID releases TreeLDR, and the EF announces the Merge Data Challenge. Newsletter: https://ethdaily.link/substack

Make compliance easy with Kolide at: https://www.kolide.com/WAN Try FreshBooks free, for 30 days, no credit card required at https://www.freshbooks.com/wan Deploy a cloud server in seconds with Hetzner at https://www.hetzner.com/cloud?pk_source=youtube&pk_content=yt-cloud-2022 Timestamps: (Courtesy of NoKi1119) 0:00 Chapters. 1:50 Intro. 2:18 Topic #1: Google tells Apple to adopt RCS. 3:58 Green bubble is bad for dating, discussing social life. 7:38 Topic #2: LTTStore's backpack warranty. 8:46 Summarizing interpretation from Linus's comments. 10:30 Explaining the "trust me, bro" & investments. 15:10 Luke discusses the wording & responses. 18:12 Linus on what he really meant about the store support. 21:46 Linus on the retiring stream. 24:18 Things that Linus feels he did wrong. 26:50 Internal versus external policy, ghosting people, lawsuits. 29:22 LTT's reputation, GN's video, discussing trust. 33:12 Subreddit's thread, accusations towards LMG censoring. 40:36 Planned warranty for LTTStore, nothing changes with LMG. 44:42 LTTStore's "Trust me bro" T-Shirt. [Cont.] Topic #2: LTTStore's backpack warranty. 46:55 Clearing the confusion in chats. 48:48 LTTStore discount, sweatband. 49:21 Topic #3: Linus's pool update. 50:55 Concrete & cement ratio, explaining shortage. 55:02 Topic #4: Netflix has mobile iOS games. 58:38 Discussing Netflix users, comparing to Apple Arcade. 1:01:34 Ubisoft, Netflix Premium subscription. 1:04:28 Merch Messages #1. 1:05:00 Riding season, video on biking & gear. 1:05:57 Floatplane background play. 1:06:16 Sponsoring an Esports team. 1:11:34 Less commonly known tech carriers. 1:14:46 Thought on Steam spam games, pop-ups, Luke's "child". 1:20:49 Sponsors. 1:21:01 Wealthfront. 1:22:18 Seasonic. 1:22:48 VULTR ft. Seasonic's 12 years warranty. 1:26:22 Topic #5: Newegg GIGABYTE discount scandal. 1:31:28 Linus tries to read into the refund & shipping issue. 1:39:48 Topic #6: Linus V.S. Naomi Wu Twitter controversy. 1:45:00 Naomi Wu & 4chan changing the story. 1:48:29 Discussing responses on Twitter. 2:01:52 Topic #7: Instagram & Facebook's excuse for in-app browser. 2:05:44 Merch Messages #2. 2:05:52 LMG's tape backup. 2:08:35 Battery technology in houses. 2:10:47 LTT demographics. 2:13:46 Should NVidia branch out into CPUs? 2:14:16 AMD CPU show similar to Intel's ARC? 2:16:30 Half life 2 in VR. 2:18:30 How Linus feels about the 20,000 bags. 2:25:58 Luke's Steam Deck & spending habit. 2:31:45 Steam Deck for game streaming. 2:33:24 Product category Linus would target. 2:34:34 Steam Deck with case for LTTStore backpack. 2:35:10 Networking cables & wifi mesh. 2:40:20 Outro.

Google Duo wird zu Meet, aber Meet bleibt Meet, wobei Meet zu Duo leitet, aber eben als Meet. Klar soweit? In dieser Episode haben wir recht viele unterschiedliche Themen mitgebracht. Alle sehr spannend - wie immer natürlich - und teilweise recht lustig. Darunter: Lithium fördern in Rheinland-Pfalz, endlich mal eine gute Webcam, Fiber, Fiber und Cyber, Cyber mit der IHK. Was wie ein Lied von Fanta 4 klingt, sind in Wirklichkeit einfach ganz normale Tech-News. Außerdem: Per BGP werden ein paar Routen temporär von Apple gekapert, und auch sonst werden einige Unternehmen gehackt oder geleaked. Darunter: Die IHK, Slack, Twilio, und Videoident als Konzept. Im Datenschutz-Bereich macht sich Amazon beliebt mit dem neusten Einkauf: iRobot Roomba, jetzt von Amazon! In den Doch-nicht-so-Kurzmeldungen erfahren wir, warum GitHub Copilot unsicheren Code vorschlägt, eine saftige Preisanpassung bei Hetzner, abgedrehte Stromleitungen bei Vodafone und zu guter Letzt der Facebook Messenger, welcher nun endlich auch Ende-zu-Ende-Verschlüsselung anbietet. Und am Ende gibt es noch zwei kleine Aufregerchen zum Thema Apple von Karim: Variable Refresh Rate und die Calculator-App!

Make compliance easy with Kolide at: https://www.kolide.com/WAN Try FreshBooks free, for 30 days, no credit card required at https://www.freshbooks.com/wan Deploy a cloud server in seconds with Hetzner at https://www.hetzner.com/cloud?pk_source=youtube&pk_content=yt-cloud-2022 Timestamps: (Courtesy of NoKi1119 - NOTE: Timestamps may be off due to change in sponsors) 0:00 Chapters 2:13 Intro 2:42 Topic #1 - Intel's "allegedly cancelled" Arc 6:12 Moore's Law Is Dead's notes on the leak 8:42 Rumored leaks of internal Intel conversations 10:20 Discussing the road map, product releases 12:10 Linus on Intel's Larrabee, comparing to Arc 13:16 Optane removed, LMG & rumors, expenses of a project 17:42 Luke wanted a competitive GPU ft. Linus's theory 19:50 Linus on Alchemist, Tel Aviv tour & silicon costs 23:46 Intel's fab would take long, chipset funding 24:56 LTTStore's Stealth Hoodie Pro 27:13 Backpack to become purchasable by next mid-week 28:20 Deal of the Week - free LTTStore tote bag 29:01 Sponsor - AMD 30:11 Sponsor - SecretLab 31:22 Sponsor - Ubiquiti' ft. Dennis seeing naked Linus 33:22 Topic #2 - OverKill reaches out to LMG 33:48 Explaining the cease & desist 35:28 "I'm not threatening you" was due to harassed wife 36:08 COVID causing delays, website overhaul & orders 37:48 NDA, recording builds for content 38:29 Are Linus & Luke on OverKill's side now? 40:56 Merch Messages #1 41:08 Right-to-repair for LTTStore, screwdriver design, WAN LAN 49:01 Linus testing radio signals 50:54 Linus is planning to go to Backstreet Boys 52:03 Updates on the 64oz LTTStore bottles 52:39 Using the LTTStore desk pad as a bed rug & wall hangings 53:12 Formula E & racing technologies 54:09 LTTStore screwdriver holster 55:08 LTTStore shorts mesh lining, Linus shows prototype belt 56:54 Travel & packing tips 58:52 Monitor is fine, but the PC setup struggles 1:00:15 Preventing companies from killing & withdrawing products 1:02:05 Intel's Arc issues Are the executives misunderstanding? 1:03:48 Linus on having his children continuing his legacy 1:05:40 What LMG does to take care of employees 1:10:25 Silence-oriented internal GPU enclosure 1:12:23 Is Linus afraid of the recession affecting LMG's growth? 1:14:24 Linus Dbranding a house, which design to go for 1:14:54 Use cases of virtual machines for homes 1:17:07 Optical disk drive class-action lawsuit 1:17:50 Particular ChannelSuperFun activity that stood up 1:19:53 CallMeKris's 6-hour video collab 1:24:29 Are certificates like CompTIA A+ needed anymore? 1:25:55 Linus's home & pool progress update 1:27:08 Most risk in growing LMG 1:27:36 Wireless earpods, Apple's AirPods 1:28:48 Dream YouTube collabs that Linus would enjoy 1:29:44 Outro

Hetzner hizo un cambio que nos tomó por sorpresa, pero añadieron una nueva función muy util.

Hetzner hizo un cambio que nos tomó por sorpresa, pero añadieron una nueva función muy util.

Nach einer etwas längeren Pause sind Tom und André wieder frisch "geboostert" zurück. Es geht locker los mit Apple-Themen, danach mit dem Thema PV + Stromtarife, um dann endlich wieder einmal beim Thema Softwareentwicklung zu landen. Dieses Mal im Technikteil: Komponentenframeworks, Auth Services, Hetzner und Hazelcast.

Make oder Buy: Alles einkaufen oder doch lieber selber machen?Eine Frage die jeder von uns kennt: Sind meine Anforderungen so speziell, dass es kein Produkt auf dem Markt gibt, die diese abdeckt? Kann ich das nicht ggf. sogar besser, wenn ich das selbst mache?In dieser Episode versuchen wir das Thema mal etwas zu durchleuchten: Wann sollte man Services einkaufen? Wann doch lieber selbst umsetzen? Wie geht man mit interner Politik und Gegenwehr um? Was kostet das Selbermachen eigentlich und was bedeuten Begriffe wie Total Cost of Ownership, Opportunitätskosten und Shadow-IT eigentlich? Ist Open Source ein Zwischenweg und wie sieht die ganze Security-Mäßig aus?Bonus: Ob wir ein Karrierepodcast sind, was man in 1. Semester BWL lernt, welche Sicherheitsanforderungen eine Webagentur aus Wanne-Eickel hat und warum Wolfgang Google mehr vertraut als sich selber.Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKioskLinksHackerNews Comment als Dropbox gelauncht wurde: https://news.ycombinator.com/item?id=9224Okta says hundreds of companies impacted by security breach: https://techcrunch.com/2022/03/23/okta-breach-sykes-sitel/Looker: https://www.looker.com/Nextcloud: https://nextcloud.com/Nextcloud-Angebot bei Hetzner: https://www.hetzner.com/de/storage/storage-shareRender: https://render.com/Vercel: https://vercel.com/Netlify: https://www.netlify.com/F-Online, die Führerschein-Plattform: https://www.f-online.at/Sprungmarken(00:00) Intro(01:33) Sollen wir die Software für unser A/B-Testing kaufen oder selber bauen?(05:23) Reisekosten-Abrechnungen: Wie kann es gehen?(06:53) Make or buy(08:27) Wolfgangs Stand bei Make or buy im privaten Leben(14:45) Wolfgangs Entscheidungskriterien für make or buy(15:42) Was ist die eigene Zeit wirklich Wert?(17:57) Klassische Beispiele für den “make or buy”-Fall in Firmen(23:42) Was kostet ein Software-Engineer, etwas selbst zu machen (Total Cost of Ownership)(28:55) Abgrenzung von make or buy(30:14) Opportunitätskosten: Produktivität und User Experience(33:40) Welche Bereiche gibt es, wo es Sinn macht, die Produkte nicht einzukaufen?(37:07) Risiken beim Einkaufen von Produkten: Shadow-IT und Workflows(41:16) Gegenwehr, fadenscheinige Gründe und interne Politik bei make or buy(48:02) Sicherheitsbedenken bei der Benutzung von externen Services(50:48) Eigene Erfahrung: Mehr make oder mehr buy?(56:07) Wann sollte man Software kaufen?(56:39) Wann sollte man die Software selbst bauen?(57:44) OutroHostsWolfgang Gassler (https://twitter.com/schafele)Andy Grunwald (https://twitter.com/andygrunwald)Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Аудиострим прошел 26.01.2022. Зашел CryptoQ - олдфаг из Нарнии и DropsEarn. Оказалось, что он глубоко в теме нод, много ставит нод на мейннете. Конечно же обсудили что поставить новичкам и где это все делать: Проекты: - Umee - Оплачиваемый веб тестнет - Game - обновили, упали и поднялись.  - Anoma - Ждем фикса и запускаемся, а может и нет.  - ChainFlip - Ждем фикс и тестнет продлили до 11 февраля - Stratos - Следим - Сosmic-horizon - Следим - Archway - Ждем - SSV - Можно поднимать - Celestia - Можно поднимать (залетаем с 2-х ног) - Massa- Сломан, ждем исравления - Humanode - нужно првоерить - Tgrade - Kyve - Можно поднимать (залетаем с 2-х ног) - Magnata - Supra Oracles - следим за ролью в дискорде, делаем активности - Golden - делаем активности, не ждем! Как появится инфа - будем делать еще активности)  Куда ставить: - Contabo.com - Hetzner.com - Ovh.com Были гости: - SecorD и Max | crypto ⬛️ из Let's Node - how_to_node - CryptoQ - олд из Нарнии и DropsEarn - n0ok [MantiCore]

Еженедельный дайджест про ноды, тестнеты, амбассадорские программы  Сегодня решил обсудить текущую повестку из самых интересных нод: Ironfish и Aleo. По какому гайду поставить, где купить сервер, почем и как его активировать.  Обсудили Hetzner и Contabo - хостинги.

Vasiliy Shapovalov (Tech Lead, Lido), F.P. (Co-Founder, Socean) and Ella Kuzmenko (Product Manager, Stake Pools & Delegation Program, Solana Foundation) chat with Anatoly about the complexity and game theory surrounding stake pools, decentralization and censorship resistance. 00:10 - Intro01:38 - Collaterals, maximizing censorship resistance07:40 - APYs and investors09:31 - How to get penetration across DeFi14:58 - Governance in a liquid stake pool18:23 - Automation vs. programmatic on-chain governance20:44 - Factors in selecting validators29:27 - Growing the validators set32:21 - Stake pool token in DeFi35:09 - Liquidity fragmented between too many pools41:01 - Who controls the network?44:46 - Increasing decentralization Anatoly (00:10):Hey folks. This is Anatoly and you're listening to The Solana Podcast. I have a super exciting episode today, it's all about Stake Pools and decentralization and censorship resistance. And I have a group of guests that I'm going to let them introduce themselves, just to make it a little easier. So Ella, why don't you start first?Ella (00:29):Sure. Hey guys. Ella, I'm a Product Manager of Censorship Resistance at The Solana Foundation working on Stake Pools and the delegation program.Vasiliy (00:39):Hey. I'm Vasiliy, I'm tech lead at Lido. Honestly, I think that the person who should be here instead of me is someone, of course like Felix or [Uto 00:00:49] or maybe Brian, but they couldn't make it, so I'm here instead as a second best option.Anatoly (00:58):Awesome to have you. We'll take the second best.FP (01:03):Hi, guys. I'm FP. I'm co-founder and CEO of The Socean Stake Pool. Nice to meet you guys all today.Anatoly (01:11):Awesome. So censorship resistance Stake Pools, I've been pounding the table on this for two years as the most important thing and proof of stake networks, because I have this crazy belief that if we have liquid staking as collateral and DeFi than financial analyst to analyze systemic risk and these things, we'll actually prefer collateral that maximizes censorship resistance. And that is a crazy thing, because it would tie incentives for maximizing censorship resistance in the network to its actual use and primary use being DeFi. Is this real or not? Is this going to happen?Vasiliy (02:00):I probably got some experience to tell here because we were in production longer, not on Solana, but in general, longer than most liquid staking pools. And I can say that it's less pressure to decentralize than I thought it would be on one hand. On the other hand is much more pressure than we usually have as a stake provider, as node operator. I come from a stake provider, P2P.org that is pretty big itself. So about 4 billion stake of fire down depends on phase of the moon, the day.And people who usually stake, there is the kind of weak, very weak, but it's a prisoner's dilemma when people are incentivized to stake with best node operator. And when there is no clear best, they go by brand but there is a number of pretty good node operator that people are incentivized to stake with because these good node operator don't lose the mistake and give them good profits and stuff like that. And basically it leads to centralization because they are not incentivized very much to the centralized stake. And it's probably on goodwill and many stakers don't give enough thought to goodwill, but stake and pools always do. Basically, they're professionally obliged to do this and better holding up to hold the node operator accountable.I think in Lido, we have a better monitoring system for node operator around for us. And most of the big stakers like changes and funds and stuff that we're monitoring people who stake for us way better than most stakers. And I can say that the trade of is real here, when that liquid stake can token hold us, are not putting a lot of pressure on us, but they're putting some and we are well equipped to react to that. And we would honestly welcome more pressure on this front.Anatoly (04:14):So, Ella, has this been easy to convince people that censorship resistance matters or is it like they're just learning about it for the first time?Ella (04:24):Yeah, that's an interesting question. I think I definitely would second what Vasiliy was saying about how it's surprisingly harder than you would think. People definitely will follow where the rewards are. And I don't think that is surprising. I think there's an interesting opportunity for Stake Pools to play with that idea and give rewards while also touting the benefits of censorship resistance. So, "Hey, we will give you great rewards, but you can also get governance tokens and you can help us build the future together."And I think there's an interesting way that you can frame that discussion where you don't really have to pick one or the other. And I think to put a maybe crazy idea out there, I think we're only seeing the beginning of what can be built on top of Stake Pools. So it's pretty standard to take your Stake Pools tokens and you go stake them and then you earn some additional yield there. But I don't think we've really unlocked the potential of realizing that the underlying asset that you're staking will continue to accrue value every epoch and you should be able to build crazy financial things on top of that, that actually give you way better rewards than staking with an individual validator will ever do.And as the product person, I just put crazy ideas out there and wait for other people to build them. But I think we're at the very early stages of that. And so I'm super excited for a year from now, what crazy things people have built, where the rewards are actually way sexier in Stake Pools. And you don't even have to care about censorship resistance by the fact that you participate in Stake Pools, you will be helping that. So that's the future that I'm really excited for.Anatoly (06:09):What do you think FP?FP (06:12):So the first question was, what do we think about the efforts towards decentralization and I think we're getting there, but I think it's still early days. If you add all of our Stake Pool operators together, we may have 10 minutes all between us and that's less than ever stake. That's less than one validator. So there's still a long way to go. And they charge 8% fees. What's going on? So definitely it is not a rational choice. It's more of a possibly just like inertia sort of thing.And then I would say, to me, there seems to be a little bit of a trade off between Stake Pools and decentralization. And what I mean by that is even between Stake Pools, there are Stake Pools that decentralize more and there are Stake Pools that decentralize less. And in some sense, there is a trade off here because if you stake with too many validators, then you don't get good APY and people don't want to stake with you. And of course, if you only stake with the best ones, then you're not really doing your job as a stake pool. So there's a little bit of a delicate balance here, but I like what Ella said in the sense that there's interesting financial instruments you can build on top, which should make the APY discussion, it just falls out.Anatoly (07:30):So the APY is between all the pools and validators are pretty close. They don't really deviate by more than like 10%. Do investors actually optimize for that right now or participants? Are they actually looking at that or are they making a decision once and not even thinking about it later for months on end? What kind of behaviors do you guys see both as a normal stake operator and a pool operator?Vasiliy (08:00):As a stake operator, I can say that there is a lot of people who absolutely look at returns. We usually, when we go into network, we prepare profit reports for them and show them they are staking with us and we get better returns and stuff like that because that's one of the points that node operator can actually differentiate on. And there is not a lot of them, basically. We offer the same service to people.But as a liquid staking protocols, there is a lot more of thing that can be a differentiator, way lot a lot. The node operator selection is one thing. Other thing is the opportunities to use your stake token in DeFi and CeFi and financial use for it. And this stuff beats these 0.1% point difference squarely. People don't care about the 0.1% point difference. But when they can actually use your token in 10 more protocols than the other person. So I think like, that's going to play as a serious factor way, way in the future, not for the few first years of stake, the liquid staking.Anatoly (09:20):So this is the difference between stable coins. Is how much penetration they have across DeFi protocols or exchanges even. Do you think exchanges are going to start having liquid staking like Lido, so Lido token?Vasiliy (09:38):Yes. I know it'll happen. It's not the matter of I think, I know it'll happen. It'll be inevitable. It'll start with smaller changes that don't have capacity to develop their own stake, liquid staking and don't have the network effect to make it a good option for people to use their exchange liquid staking. And then it comes to basically everywhere, I think. There is a pretty serious trading volume on liquid staking tokens right now and it's growing bigger month by month. So eventually, it'll be stupid not to waste them.Anatoly (10:19):FP, is that what you guys are most worried about or most working on? How do you get penetration across DeFi?FP (10:26):Yeah. I think so. Something that worries me is a lot of the protocols giving out emissions and the TVL is growing and all that. But I just wonder how much of it is organic growth because Stake Pools are very different from AMMs like ORCA or trading Texas, Mango where whereby in ORCA, they make their revenues from you doing stuff, from you trading or doing stuff. But in a stake pool, you want to do nothing. I mean, what we want our users is just literally put the SOL in us and just do nothing.So it is a little bit of a different incentivization. And I wonder whether these incentives are sustainable, because look, if you're chasing the people who are farming short-term yield, these are not the people that you want in your stake pool anyway. You want people who are in it for the long haul. So I'm a little bit worried about this.Ella (11:17):Yeah. To piggyback off of that. I think something that's uniquely interesting for Stake Pools that is not true for staking to an individual validator is yes, you want them to just hold their stake tokens in your pool, but you also do want them to participate in the broader project. And what I mean by that is when you have of governance tokens, you have the ability to actually impact where the project will go. And you have the ability to be active in a way that you can't be, if you are, let's say, in CeFi buying an index fund from Vanguard. They're not going to ask you, "Hey, do you have opinions about where Vanguard should go next?" And I think similarly, if you're staking to an individual validator, like sure, they might be earning you great rewards. That's very important, obviously. But I think at some point, everybody gets to a point where they say, "Hey, more rewards would be great, but what I really want is a community."And so I think Stake Pools that lean into this idea of, hey, we're going to give you this governance token, yes, hold your tokens. Do whatever you want on DeFi. But more than that, tell us what you want to see in the community and where you want the future of this project to go. I think that's a very unique power to Stake Pools that will organically grow. We just have to figure out how to market that in a way that's appealing to people who are institutional investors, retail investors, total crypto newbies, who don't even know what a Dow is. Don't know what governance tokens are, don't know what a stake pool is. So there's a lot of work to do there, but I think we have our work cut out for us because it lends itself to this very unique dynamic between all of the stakers.Vasiliy (12:56):The way I think about that is it will be a lot more market driven than participation in governance doing. People are usually who are staking as node operator and provided most of them, don't care to make governance decisions. You can actually look at how it will works with Cosmos and other proof stake blockchains, where governance is a part of staking. And you can see that most people don't vote apart from how they validate the votes, where they do.They select basically a company that is aligned to them or maybe select the person that give them best returns. And then they don't take a look at governance usually. That's not true for all people, but that's a clear majority that delegates the governance power and it'll be pretty much the same with Stake Pools with liquid staking protocols. They won't be able to even to connect with most of the holders of the staking tokens, because they won't be like passionate enough to connect back, to understand what they want. So it'll be very indirect.There will be staking pools that gouge some of the governance decision from stakers, but not from all of it. Not even from most of them, like from 10% of them, by volume and not by number. By number, it'll be like probably not 10% like about 0.1%, but they will take much more or maybe about the same pressure from protocols that uses staking token from the stakeholders in the blockchain ecosystem that don't use a liquid staking token by important like develop teams, develop clients and researchers as an ecosystem and stuff like that. And liquid staking pool will be a nexus of governance that will try to combine all this pressure in the single direction from stakers, from protocols, from major participants in the ecosystem.Anatoly (14:58):What is governance in a liquid stake pool? What is the function of it for the community that owns the token? What should they be looking at?FP (15:08):First and foremost, the delegation strategy. I think the community needs to decide the delegation strategy. I don't think this should be left to the founders or the creators of the stake pool. It should be democratized. I think another thing is fees. So I think the community should decide the fees that a stake pool should charge. And the last thing I would say is, we would like a lot of the associated infrastructure to be run by the community as well.So for instance, the program, the upgrade authority is already given to the community. Treasury decisions are already given to the community, but there are still things like the front end or paying for a custom RPC note and things like that right now is centralized. And we would like that all to be on chain eventually. So I think that's all quite important.Vasiliy (16:02):My thought here is that the role of governance in a good liquid staking protocol is to drive itself to extinction. So it won't be easy or it won't be fast, but essentially liquid staking is walking in the outermost part of the security of the protocol. It touches the most important parts of the protocol like censorship, resistance, and decetralization and security and all of that. And if it gets a significant power in this parts and if it's not credibly neutral, it's like a great thing.It should be credibly neutral and you can't be credibly neutral for long when your governance is overpowered. It's a natural thing for all governance to take too much power and use it in not a great way. So it basically has to, in order to be accepted by stakers and ecosystem as a ligand liquid stake protocol. The ligand part of staking, it should be self-depreciating to a point that where governance power are time locked and very light and mostly algorithm driven.Anatoly (17:27):This is interesting point because I think the goal of governance of a layer one is also to obsolete itself. Is how do we build the structures? And part of the reason of building out Stake Pools was because the foundation was running its own delegation program. And it really felt like why don't we get the community to do its own delegation programs. And then how do we get zero to one thing working, how do we now go want to earn? And that's always a way to disintermediate yourself from the governance work and then eliminate it all together. I think it's interesting that like inherently there isn't a drive to eliminate it from the community. We just want to push it out of the foundation and have you guys figure out what does that fine line between automation and having everything be programmatic to on chain governance?Vasiliy (18:32):Well, not yet. It's a work in progress. We are working on maybe systemizing the ways we can... What inputs do we have, is this programmatic governance, to understand where we can get the signal from, what we can use as a strong signal. We can't get rid of the governance entirely. We can just make it in a way that... Well, like I said, the role of governance in the mistaken is to take all this input from protocols and ecosystem and stakers and the outside water is large and fabricator of consensus out of it.So part of this can be automated because we can have the signals in bits and bites and we can use algorithm to aggregate this signals into party of decision maybe. Right now, we're looking at stuff like what is objectively good characteristics of a node operator for example, for selecting node operator like up time and special risk and the reputation that is proxy by amount of stake can all the other protocols that they are staking.And this is a strong signal. We can look at like time of operation within Lido, which is roughly correlate with reputation and outside Lido as well. We can look at stake as preference and the stake token can hold the preference to understand what they want, which is also a proxy for reputation, which I don't have. The things I don't have a good solution for getting into account, what people who run protocols think and what people who are major in the ecosystem think, because it's not directly correlated to a stake in stake pool. And we don't have a good way to get these signals yet, maybe ever.Anatoly (20:29):You guys like Lido and FP have two different approaches from what I can tell in terms of building out the validator set and the delegation strategy. FP, what are your thoughts on this? What are you guys driving most as the number one factor in selecting validators?FP (20:48):So I think it's important not to have a white list of validators because I think this is exclusionary. I think it's important not to dictate what fees validators should charge, because I think fees are only important in so far as they affect performance. So in some sense, we don't want to control validators. I think we shouldn't. We shouldn't dictate how validators... That being said, of course performance over time is very important. I think if not the most important. Yeah.And the other thing I would say is, the decentralization, obviously we shouldn't be staking to nodes that are in the MSG, they have too much stake or nodes that are in one of the data centers that is in the MSG. So one of the top three data centers. But that being said, there also a middle ground. You don't want to spread your stake among, let's say, 600 validators, for example. And the reason why you don't want to do that is because then you can't make a meaningful difference in decentralization. You want of do want to reward validators that are doing well, that are also out of the security group. So yeah, I would say it's a bit of a balancing act here.Anatoly (22:13):Vasiliy, you guys have a totally different approach. I'm excited too, why did you guys come up with that system? And what is the Lido way?Vasiliy (22:19):To expand a bit on what the system is, we've got a wide list of node operator that run with Lido and charge the same commission and get the flat amount of reward. What the reason behind this, the whitelist selection is done by basically a peer review. We've got a lot of node operators, already validating Lido in different protocols in Ethereum, in Terra and now in Solana. And we have a submission process where people submit, they want to stake for Lido and we get the node operators. They took a look at them at the setup they have and historical performance in Solana and other blockchains, especially in Solana and stuff like that. And community participation and select that the next five or so participant of the whitelist when we need to expand.The why we do that because we want to have good stake distribution that will be good for Solana and that's not the best, but it's easily achievable way to do that. Because that way we can guarantee that node operator are good because they're selected by the community of node operator essentially. And we can guarantee that they have enough stake to run the operations and have enough profit that say that. So they really want to keep this good business going. That's a good business for them. That's what they want to do. They are not arranged by scrap. They are paying their DevOps engineers handsome salary and stuff like that, so that they can afford to be honest.It's not great in the sense that it's a process that allows us to select the distribution folks, but it doesn't allow people to come in fresh and grow. And that's not great. But as a temporary thing, when there is a good community of node operator that are just like not selected yet, it works, I think very well.FP (24:36):I think part of the reason why Lido does it is from what Vasiliy said, it's meant to make sure that the node operator are reliable and performant. And I would put forward that there's a very easy way to look and to see if a node operator is performing, just look at their API. So in some sense, I mean, I don't want to make any implications, but I believe this peer review process is a bit nepotistic. It's like if you're in our secret cabal and if we know you and and we like your DevOps engineers and blah, blah, blah, then will onboard you. Of course, that's not the case, but it's what it seems like.Anatoly (25:15):This is the most controversial Solana podcast we've ever had.Vasiliy (25:21):I wouldn't say that's not true. It really does not allow newcomers to come in easily because there is a community of node operator that been through thick and thin via market, like Greeks through this days, when we all worked like in the red four years, that was what happened. We used make way less money than we earned, like with P2P, which was a pretty big one even this time. Like I said, it's not great, with this process, we can't get in people who didn't build this reputation and track record and stuff.What I don't agree with you that you can easily estimate how good is node operator, but looking at their performance, that's just not true. That's not how you estimate a node operator. You don't only evaluate performance. You also evaluate tailor risks. And tailor risks, you can't evaluate by performance. You should understand that these folks have bus factor of more than one. They don't have a single guy running all this stuff because if this guy gets sick, your validators get stuck.You should understand that they will stay up at night when there is an upgrade. You should understand that if there is a via market, they will stay to the blockchains they're running and they don't all run on Hetzner. So because that's, at least used to be the easiest way to get APR is to run the same data center as everyone. That's how skip rates they used to work in Solana.There is way more nuance in selecting a good set of node operator than just looking at performance. The geographical distribution, the jurisdiction distribution, the track record, other blockchains, which runs the reputation and community participation being in discord or running projects for Solana and stuff like that. There is way more stuff about node operator that is not easy to understand from just on chain metric. On chain metric is like the 20, 30% important stuff of choosing validator, because there are a lot of validators with good on chain metrics, but there are differentiated by stuff that is not seen by most people at all.Ella (27:44):I would say if somebody is staying up all night to make sure that their validator is running and they do restarts within the first five, 10 minutes, they're going to have better rewards. So I would say, it's more than 20%. I agree that being decentralized and being in data centers that are different from other people are doing community projects is super important. But I do think that rewards are a good proxy for how active the validator is actually running their node.Vasiliy (28:13):You can say that, that's a prerequisite. If you have good bad performance, you're not a good validator. That's true. That's not what makes your excellent node operator because excellent node operators run explorers, for example. And there are certs basically, for example. You can't say that this guy has the same performance cert, so they're as good. That's not true.Ella (28:35):But I mean, I would say there are maybe like 10 community members who run dashboards and different tooling. And I think there are way more than 10 stellar validators. So sometimes it's just not within their area of expertise. They could be excellent DevOps people and run validators across many blockchains, but they're not a web developer. That's just not their skillset, but I wouldn't say that they don't contribute to the community.Vasiliy (29:01):Yeah. What I'm saying just there is much more nuance, especially when you don't have 300 places for a node operator, you don't have enough money to pay them for 300 validators and you need to select 15 or 20 or 50.Ella (29:18):Unless a hundred million SOL gets stake to Stake Pools, then you can expand that list to 3,000 validators and everyone will be profitable.Anatoly (29:26):So this is the challenges. How do we grow the validator set? And it almost in my mind is like, you need both, you need people that are driving, we need higher quality. We need due to proof points that you know how to manage keys, but we also need people that are like, okay, just on board and figure it out and try it. Yeah. This is a tough problem. And I think part of the reason of not wanting the foundation to do it and push out this technology, a stake fulls is because we don't know. You guys are both sound very much validator operator focused, but these things like, I think are some form of financial, like DeFi application too. How much of your time are you thinking about like how these things actually work in DeFi?Vasiliy (30:22):I think I'd say a lot. That's what makes or breaks the liquid staking, the whole point of liquid staking is that it's liquid and usable in finance. I actually don't think a lot about a lot of time about node operator because I used to work here. I'm working as the staking provider since like 2020, early 2020. So I'm just have strong opinions because I do it right. But I have to think a lot about DeFi because that's uncharted, it's new.FP (30:58):So yeah. I mean, I think as Toly points out, I think the validator operator stuff is important, but really it really is just a baseline. And I think what we do with it next is the thing that's more important. So the question was, how do we think about how it's composed with DeFi? It's just the beginning. So right now what are the main things that you can do with your stake pool token? So you can put it in an AMM and provide liquidity that way, you can do lending and that's about it, I think.I mean, there's lots of stuff you can do and you want to use the stake pool stake SOL in any occasion where you can use regular SOL. So whether it's just buying from a marketplace or doing some more exotic stuff, like options trading, that sort of stuff and not just putting it in liquidity pool or borrowing or lending or leverage yield farming. So yeah. I basically want to expand the ways in which stake pool tokens can be used. And I think that's going to be a big draw for people to start staking with us.Anatoly (32:18):How much work is it to get that adoption or to have a specific stake pool token used in a DeFi?FP (32:27):I think integration takes time. I mean, it really depends on the partner which you're integrating with. And I think some things just haven't been built out yet actually. So Ella and I have been talking about how we can use these stake pool tokens in the NFT marketplaces, for example. But none of this stuff has been built out. So, yeah. So we'll get that, but it's not there yet, I would say. So we have to build it.Vasiliy (32:57):There is two parts to the answer. One is how long does it take to build. The other is how long does it take to convince people to build? The first is, faster than usual for financial products in traditional finances, but still long because we know that shipping is hard and convincing is also can be pretty, pretty complicated. For example, we started the integration process on MiCA, I think in February this year. And we only now getting an executive at least take things on MiCA, I think around next week or so. That's how long it cost with MiCA. And it's very similar amounts of time with a major protocols on Ethereum that are by now pretty conservative. Solana is not conservative yet. Most of the protocols on Solana make fast and break things, move fast and break things. So I don't think it'll take like this long stake Solana tokens to be a major participant of DeFi, but it's still time.Ella (34:12):Yeah. I would say the technical integrations, they're not technically challenging, you're integrating an SPL token. So that part is pretty easy or not as challenging as you would imagine. I think in the early days, when the TVL was very small, it was maybe hard to convince platforms that they should care about this weird stake pool token thing. Now that TVL is close to $2 billion US dollars. They maybe will now take those meetings and be like, "Oh, okay. Yeah, let's integrate all the stake pool tokens."And maybe whereas before they would have some liquidity requirements say, prove that users actually want this on our platform. Why should we spend the time integrating it? I think hopefully the script will flip and they'll be like, "Hey please, can we integrate your stake pool token?" But I think it just, realistically it takes a couple of months to get at that traction. And hopefully we have some momentum now and we can push forward more of those integrations.Anatoly (35:08):Is there kind of danger of liquidity being fractured between too many pools?FP (35:14):Hey, I seem to recall asking you this exact question on discord back in September, Toly. Yeah. I wondered this myself to be honest because I think there is a happy medium. You don't want one stake pool taking all of it because there are protocol risk there as it ends points out. Yeah. And if they fail it, that's dangerous. Well, on the other hand, it's going to be really difficult to integrate a hundred different stakes pools.Although that being said, there are things we can do to mitigate it. One of which is to enforce some sort of standardization. So one good step would be, for example, to use the Solana reference recommendation instead of... Maybe it's too late now for some of the existing Stake Pools. But that being said we were talking about adapters. I don't know if you recall some sort of adapter, some sort of layer that makes sure that the Stake Pools can all interoperate with one another. I think that would be really good.Vasiliy (36:14):I think it's inevitable that a single representation of staked Solana to be the major player here. So that's basically Lido thesis and I'm seeing it play out in the Ethereum and in the LUNA and in the entire ecosystem. So I think it's going to happen. It doesn't necessarily mean that it'll be one stake pool, but the alternative here is just another layer of aggregation. One thing for example, was proposed by Michael from Curve where like basically a stable pool of multiple liquid staking tokens was used and LP token from this pool was proposed as a basically unit of account. I'm not sure that it will happen, but I am pretty sure that there will be one aggregate stake Solana token, that will take the majority of the market.Anatoly (37:20):I actually think that these things are far more fluid because it's all people based at the end of the day. And people will do promotions and get communities together and have fun or get excited about a thing that some innovation and you will see liquidity move from one thing to the other simply because it's exciting. And it feels like it's just a little too static for there to be only one token. This is not how normally people operate, but we'll see.Yeah. It's at any given moment one winning token maybe is a better way to put it. So it doesn't mean there will be one token for eternity, but at any given moment, there will be a clear winner except maybe the moments of flipping that's how I see it.FP (38:14):So I worry a little bit about that actually. I worry because we talk about increasing decentralization. And that was the reason why Stake Pools were created in the first place. And it's true that if you have one stake pool controlling all the stake, that solves a particular kind of centralization, Nakamoto coefficient. But then it introduces a new kind of centralization. And maybe there are risks that can be mitigated that way, but still this worries me a little bit. So I'd rather have an ecosystem with a good number of different Stake Pools.Ella (38:51):That's where the education piece comes in. You got to let your delegators know the importance of censorship resistance and decentralization so if there is a sexy new aggregated stake pool token, they don't just gravitate towards it because it looks good without thinking about the consequences of that.Anatoly (39:09):But the yields are so high.Vasiliy (39:15):I don't like the dynamic at all, that there will be one lean stake token, but I think it's inevitable. And what we can do is not oppose it, but we can build protocols that will be a net good for the system anyway, even if this happens, hence the self depreciate of governance and in liquid stake and stuff like that, that's all flowing from there.Ella (39:40):I wouldn't say I'm oppose to it, I think in an instance where you have 10 really small stake pool operators, let's say universities decide, hey, we want to run the Yale stake pool and the UDab stake pool. And they have very fragmented liquidity. I think it makes total sense for there to be an aggregated university stake pool token, support university students help them get their pizza and ramen. Great. That's a fun way to do it. But that's a very specific use case where you're trying to make sure liquidity isn't fragmented.But I think every stake pool today has more than 600,000 sold deposited into it Solana. So I wouldn't say that's a huge fragmentation. It seems like people have chosen the pool that they like and they're happy with the performance, with the project. And that's the one that they picked. And so I don't know that they would be attracted to something that tries to average everything out and is just a generic token, but I could be wrong.Vasiliy (40:38):Yeah. It's so very interesting to see the play out.Anatoly (40:40):So are you guys worried about if these are used collateral, like liquidations rapidly moving stake from the lenders to the people collecting to the traders, is that going to change the dynamic of the makeup of who controls the network over the long-term?Vasiliy (41:05):Not reallY. How I've seen it work by, in liquidation that happened in Terra and similar ones that there were not exactly strictly liquidation, but more of fire sale events in Ethereum when the price of weather went down and people were going out of stake teeth as well. The dynamics here is that people who have low time preference are selling at low prices and people who have higher time preference, they are buying. So then they went of the liquidation, the price goes down and people with more foresight and more patience are getting the discounted stake token. So if anything, that looks like stake token getting in the hands that smarter and are in for a longer game, usually. So not always the case, but very much looks like this.FP (42:05):I don't know. I mean, that being said, when you have all these incentive programs and emissions coming out. That doesn't that see to incentivize people who jump around pools, trying to find the best ones. And they're getting rewarded by lots of governance tokens at the end of the day. So what do we think about that?Vasiliy (42:25):I don't think that it's something to really think about, I don't know. Jumping around and getting this governance tokens and it is a natural way to get some money for people who like money. I don't know. That's not a bad thing. If you like some juicer smart contract risks and rockeries in your life, that's a very exciting way to spend time.Anatoly (42:55):Yeah. There is I think a danger, but I don't know how big it is in that normally for like a validator to receive more stake, the best they can really do is offer 0% commission and then they can start bribing people. And it's hard to bribe people, but with liquid staking, it's a lot easier. You can just simply say, when you stake with this pool, you get so many more rewards than you do anywhere else, because you can min this new reward token. And is that a dangerous, scary thing that could result with a third or more of the stake, all moving towards this hot, shiny thing? I don't know.This is the part of where I think it's very critical for DeFi to mature and to have real analysts and people analyzing these things and looking deep and giving a ton of pushback on things that look a little fishy. It naturally happens, but only happens on crypto Twitter and still so much stuff sneaks through.Anatoly (44:06):So we'll see what happens, but thank you guys for joining. Super excited to have this actually being live now and making so much headway and growing so rapidly. Honestly, if we actually get to a point where DeFi is incentivizing censorship resistance, we're kind of done. We built it. We can actually take a break. So I'm looking forward to that.FP (44:41):Is that the biggest concern for you as a creator of the layer one, the increasing this decentralization, would you say that's the biggest concern?Anatoly (44:49):Yeah. This is the thing that I'm most worried about, because I think to do it in a sustainable way, it means that you need to have a use case which benefits from decentralization. You need to have external users that have a benefit that exceeds the cost of running the network. It can't just be self-sustaining tokens moving around. So to truly succeed there means that, we build something useful to the world. And that's the ultimate goal.What else are you an engineer if not to build something useful? If that's what you care about, then you should be an artist and that's a totally different thing. Yeah. Awesome to chat with you guys. Thank you for being on the show and thank you for all the hard work everyone is doing, Ella, Vasiliy, FP. Just thank you guys.FP (45:48):Thank you so much for having us today.Vasiliy (45:49):Thank you.Ella (45:49):Thank you.

Hetzner ha dado el salto en el charco y nos sorprende a todos los latinos con su llegada a Estados Unidos

Hetzner ha dado el salto en el charco y nos sorprende a todos los latinos con su llegada a Estados Unidos

Tim Hetzner—Lutheran Church Charities (LCC) President/CEO and founder of the K-9 Ministry—provides a brief overview of the LCC, including the earliest days, which involved just Hetzner and one half-time employee. […] The post Tim Hetzner, Lutheran Church Charities President/CEO and founder of the K-9 Ministry first appeared on Talking Animals.

In der letzten Episode vor der Sommerpause treffen sich Tom und André nochmals zu einem gemütlichen Plauscherl. Es geht um die Vorschau des neuen Safari Web Browser von Apple, Slack Huddles, Toms Erfahrungen mit dem mobilen Service von Tesla, Cloud Computing in der Hetzner Cloud und Games.

Veranstaltungen mit sehr vielen Teilnehmern sind mit Tools wie Zoom oder Jitsi möglich – aber so viel Spaß wie ein reales Treffen machen sie nicht. Auf den Online-Plattformen Work Adventure, Wonder, gather.town und Mozilla Hubs geht das besser: Wie in einem Computerspiel läuft man durch virtuelle Räume und lauscht Vorträgen, trifft sich in kleinen Gruppen oder plauscht ungezwungen mit Leuten, die einem gerade über den Weg laufen. Kim Sartorius hat die vier Online-Plattformen für c't getestet und Mängel vor allem beim Datenschutz gefunden – zwei der Testkandidaten lassen sich aber auch auf einem eigenen Server betreiben. Notebooks mit vorinstalliertem Linux sind selten, doch das Dell XPS 13 9310 kann man sich direkt vom Hersteller auch mit Ubuntu 20.04 bestellen - wenn auch etwas versteckt im Webshop. Niklas Dierking hat sich mit dem Notebook ins c't-Labor begeben und geprüft, wie gut es mit Ubuntu und anderen Distributionen harmoniert. Er gibt Tipps, worauf man als Linuxer beim Kauf eines Notebooks achten sollte und wie man Kompatibilitätsprobleme behebt. Zum Schluss sprechen wir mit Jan Mahn über einen blinden Fleck im Bereich Security und Datenschutz: E-Mail-Konten. Die sind häufig nicht ausreichend gesichert, obwohl sie mitunter hochsensible, personenbezogene Daten enthalten. Vereine und Unternehmen, die Ihre Postfächer über einen Mail-Hoster wie 1&1, Hetzner, Mittwald oder Host Europe betreiben, sollten deshalb kontrollieren, ob ihr Hoster die technischen Anforderungen an E-Mail-Sicherheit auch umsetzt. Mit dabei: Achim Barczok, Kim Sartorius, Niklas Dierking, Jan Mahn 00:00 Intro 02:40 Virtuelle Veranstaltungen 20:40 Linux-Notebooks 33:49 Sichere Emailkonten === Anzeige / Sponsorenhinweis === adesso - CHANCENGEBER FÜR DEINE ZUKUNFT Du willst einsteigen, wo Zukunft programmiert wird? Dann gestalte mit uns die Digitalisierungswelt von morgen! Wir gehören für Newcomer und Professionals zu den Top-Adressen in der IT-Welt. Bei adesso machen die Menschen den Unterschied – und den Erfolg. Und die Perspektiven stimmen. Auf https://karriere.adesso.de/ erfährst Du mehr. === Anzeige / Sponsorenhinweis Ende === Die c't 13/2021 gibt's am Kiosk, im Browser und in der c't-App für iOS und Android. Artikel zur Sendung: - Kostenlose Online-Interaktionsplattformen für virtuelle Gruppentreffen, c't 13/2021, S. 116 - Dell XPS 13 9310 mit Ubuntu Desktop, c't 13/2021, S. 104 - Datenschutzprobleme bei Mailhosting-Anbietern, c't 13/2021 S. 132 Übrigens: Unser neuer YouTube-Channel c't 3003 ist ab sofort abonnierbar; in der aktuellen Folge testet Jan-Keno Janssen eine AR-Brille für 800 Euro.

[02:40] Veranstaltungen mit sehr vielen Teilnehmern sind mit Tools wie Zoom oder Jitsi möglich – aber so viel Spaß wie ein reales Treffen machen sie nicht. Auf den Online-Plattformen Work Adventure, Wonder, gather.town und Mozilla Hubs geht das besser: Wie in einem Computerspiel läuft man durch virtuelle Räume und lauscht Vorträgen, trifft sich in kleinen Gruppen oder plauscht ungezwungen mit Leuten, die einem gerade über den Weg laufen. Kim Sartorius hat die vier Online-Plattformen für c't getestet und Mängel vor allem beim Datenschutz gefunden – zwei der Testkandidaten lassen sich aber auch auf einem eigenen Server betreiben. [20:40] Notebooks mit vorinstalliertem Linux sind selten, doch das Dell XPS 13 9310 kann man sich direkt vom Hersteller auch mit Ubuntu 20.04 bestellen - wenn auch etwas versteckt im Webshop. Niklas Dierking hat sich mit dem Notebook ins c't-Labor begeben und geprüft, wie gut es mit Ubuntu und anderen Distributionen harmoniert. Er gibt Tipps, worauf man als Linuxer beim Kauf eines Notebooks achten sollte und wie man Kompatibilitätsprobleme behebt. [33:49] Zum Schluss sprechen wir mit Jan Mahn über einen blinden Fleck im Bereich Security und Datenschutz: E-Mail-Konten. Die sind häufig nicht ausreichend gesichert, obwohl sie mitunter hochsensible, personenbezogene Daten enthalten. Vereine und Unternehmen, die Ihre Postfächer über einen Mail-Hoster wie 1&1, Hetzner, Mittwald oder Host Europe betreiben, sollten deshalb kontrollieren, ob ihr Hoster die technischen Anforderungen an E-Mail-Sicherheit auch umsetzt. Mit dabei: Achim Barczok, Kim Sartorius, Niklas Dierking, Jan Mahn === Anzeige / Sponsorenhinweis === adesso - CHANCENGEBER FÜR DEINE ZUKUNFT Du willst einsteigen, wo Zukunft programmiert wird? Dann gestalte mit uns die Digitalisierungswelt von morgen! Wir gehören für Newcomer und Professionals zu den Top-Adressen in der IT-Welt. Bei adesso machen die Menschen den Unterschied – und den Erfolg. Und die Perspektiven stimmen. Auf https://karriere.adesso.de/ erfährst Du mehr. === Anzeige / Sponsorenhinweis Ende === Die c't 13/2021 gibt's am Kiosk, im Browser und in der c't-App für iOS und Android. Artikel zur Sendung: - Kostenlose Online-Interaktionsplattformen für virtuelle Gruppentreffen, c't 13/2021, S. 116 - Dell XPS 13 9310 mit Ubuntu Desktop, c't 13/2021, S. 104 - Datenschutzprobleme bei Mailhosting-Anbietern, c't 13/2021 S. 132 Übrigens: Unser neuer YouTube-Channel c't 3003 ist ab sofort abonnierbar; in der aktuellen Folge testet Jan-Keno Janssen eine AR-Brille für 800 Euro.