FLOSS Weekly

Jonathan: Hey folks, this week Simon joins me and we talk with Gary Williams about AugCamp. That's the un conference all about free software, free culture, and a bunch of mates getting together to have a good time. You don't want to miss it, so stay tuned. This is Floss Weekly, episode 803. Recorded Tuesday, October 1st.

Unconferencing with AugCamp. It's time for Floss Weekly, the show about free, libre, and open source software. I'm your host, Jonathan Bennett. And this week we have, uh, well, it's not software this week. It's more about free culture and open source culture. We're talking about AugCamp. And, uh, of course, it is not just me, we've got the, the great, the amazing, Mr.

Simon Phipps! Hey, Simon! Oh, it's me, it's me! It's you! I'm back again. Welcome back! Always a pleasure! So, uh, Ogcamp, you, uh, you, you know, you know something about this, like you're, you're sort of, uh, one of the insiders. In fact, you're kind of doing double duty as a co host and a guest today, aren't you?

Simon: Yeah, so the story here is that, uh, I have a, um, a non profit that I host in the UK that looks after small community activities.

Uh, so one of the other things it does is it collect, it crowdfund the, um, maintenance of the ODF specification. Uh, and a, a lawyer friend said, Hey, this group of people needs a place to host their conference. Uh, all the money and the trademarks and the domain names, would you do it? So I agreed years ago that I would host, uh, the, uh, fiduciary oversight of this thing called OG Camp.

And I also go along. And act as treasurer at the actual event. So I take the cash box and I buy everyone's lunch and everything. Uh, but I don't do any of the other organization and none of the hard work is actually anything to do with me. Uh, and it's a different organizer each year. Um, but we're going to find out more about that now.

So I've been involved in it for years and I, I'm quite, um, pivotal to it happening, but I'm not actually the person that does the work. I

Jonathan: see. And so the person that does the work this year, is that Gary Williams?

Simon: That's Gary Williams.

Jonathan: All right, well, let's go ahead and bring him on. A noble volunteer. Yeah, we've got him waiting in the wings.

And, uh, Gary, welcome to the show.

Gary: Hey, Jonathan. Hey, Simon. Great to be here.

Jonathan: So, what, our, our Our outline for the show is basically like the the question words, right? Like what, why, where, who, how Is Oddcamp? Because we're talking about Oddcamp. So let's start with what And just give us kind of the the overview.

What what is this thing and why should people care about it?

Gary: Yeah, so Oddcamp is uh, we well we self describe as a free culture free open source software Uh kind of hardware hacking, uh Uh, conference in the UK actually in Unconference more accurately. Uh, so we've been running for 15 years now, although this is only our 11th year actually running the conference because of the event that happened over the last few years.

Um, and really it's, you know, it's a place to be if you are at all interested in hardware hacking, open culture, foss, um, and yeah, I guess things of that nature.

Jonathan: Is that where the name comes from? OGG? Are you guys really into doing audio compression?

Gary: So yeah, the name is a bit of baggage with it. We were talking a little bit about this before the show.

So OggCamp actually originally came out of a couple of Linux podcasts and came out of the Linux podcasting community and Oggvorbis and Oggtheora were the hot thing at that time, 15 years ago. So they chose the name Ogg and clung onto it and, uh, It's the, it's kind of the name that stuck, so it's Ogg in the sense of, I guess, uh, open formats and open standards, uh, but actually there's a lot, a lot more wider things discussed at OggCamp.

It's completely unrelated to Terry Pratchett.

Jonathan: One of the podcasts, was it the Linux Outlaws? I remember Dan was involved with this for a while.

Gary: Yeah, it was the Linux Outlaws and I think the Ubuntu UK podcast at the time. Ah,

Jonathan: yeah, cool. Okay, now you said you guys have taken a break. What, what's up with that?

What in the world would cause that? Why? Why?

Gary: Yeah, so we last ran in 2019 and then, uh, in 2020, this, uh, this large virus came and stopped us from running the event, uh, in 2020. Um, 2021, similar story, um, and because we're completely volunteer organized, there were a couple of years there where it just took some time for someone to pick up the slack.

Um, I was supposed to run OccCamp last year, uh, but, uh, we had a baby and that kind of got in the way of my time to organize things. So, uh I understand. Yeah.

Simon: And we did have a great team that was going to run OGCAMP the year before that, and they, they got very nervous about the return of COVID. And so they decided that they couldn't run it.

And they, they eventually stepped back down. And so we had two years where that crew was going to run it and found that the environment wasn't right for it. And then Gary last year, and now here we are with running the event for the first time in five years in Manchester in the United Kingdom.

Jonathan: So you, you have jumped to one of the next questions.

It's in, it's in Manchester. Um, have you ever thought about moving it outside

Gary: of the UK? I think there have been various people who have asked about running one outside of the UK. Um, I guess the difficulty we've always had is Oddcamp's home has been spiritually the north of England. So we've done Manchester, we've done Liverpool, we've done various other cities across the north of England.

We've ventured south a couple of times, there's been one in Oxford and one in Canterbury, but by and large it's been the north of England. Um, there were a crew looking to run one in Edinburgh, so I guess that's technically outside of England. Um, And there were a crew who were partially interested in running one in Dublin at one point.

Um, but, but that never quite got off the ground to say. England has been the kind of spiritual home of Oddcamp, um, but I guess if someone wanted to organise an Oddcamp outside of the UK, I can't see why we couldn't.

Jonathan: Yeah, you could have like, uh, Ogcamp West and Ogcamp East and have them, you know, in Berlin and somewhere here in the U.

S. It'd be fun.

Simon: It's, uh, it's got quite an eclectic draw, actually. I've been watching the ticket sales. Yeah. And there's been people in Germany and France and Belgium. all buying tickets and coming over. So although it's located in the north of England this time, um, there's, there's quite a draw from across Europe, which really quite surprised me when I realized it was happening.

Jonathan: Do you have a decent little handful coming from the States or are we Yankees not, uh, not in your target audience?

Gary: I don't think we've had any make it this year from the States. I think we have actually had a couple from Japan and places like that, but no one from the States quite yet. Yeah, maybe you should be the first Jonathan and, uh, go and get a ticket.

Although two weeks is maybe a bit short. There are

Simon: still tickets actually. You can still come. Yeah. It's very surprising where you can fly to Manchester from across the U S there are direct flights from many U S cities.

Jonathan: Yeah. Yeah, that's true. Um, okay. So. Let's just say I decide I'm going to come to Oggcamp.

What, uh, what should I expect? What's the experience like? What, uh, give me, give me a quick survival guide for a first timer.

Gary: So I think probably the, the easiest thing to say about Oggcamp is that every Oggcamp is entirely different. Say. Um, we have a set of scheduled talks, uh, just to make sure that we've got a bunch of content.

So this year we've got two rooms worth of scheduled talks, and they're from a variety of people. Uh, we've got workshops from people, uh, like Utah. One of our sponsors this year who are a, our Camp Utah, one of our sponsors this year who are a workers union here at the uk. Um. But I guess OPCAM's real selling point is that we're an on conference.

Um, so in the UK and perhaps in other places, BarCAMPs are quite a popular, uh, method of running a conference. And, uh, What that means is effectively if you've got something interesting that you think that OpCamp attendees would want to hear about, write the talk, turn up with it, or indeed don't write the talk, find out what people are interested in on the Saturday, and then what we quite often see is people with their laptop furiously writing their talk on the Saturday night to give on the Sunday.

So it's, you know, it's a real variety of topics that, that you end up hearing about our camp. It's anything from, uh, you know, securing your website with a WAF to mental health to you, what's the latest on what Collabora are doing or, you know, whatever else. Um, that there's a whole plethora of topics. Um, so yeah, no two old camps are ever the same.

Jonathan: Yeah. Uh, you said there's some workshops too where people are actually hands-on with hardware.

Gary: Yeah, so we haven't got any official hardware workshops this year, but we have in the past had people, you know, turning up with the Raspberry Pis and soldering irons and putting together ESP32 microcontrollers and things.

I think there was an event a few years ago, actually, where we had to ask someone with a soldering iron to please go outside of the conference center because your second smoker lights off. So they ended up soldering at the car park, which was pretty cool to see. Um, it's great, but we, uh, we encourage you if you've got a cool hardware project, uh, show off, absolutely bring it along.

Um, and, you know, being in the UK, we've, we've always had quite a lot of the Raspberry Pi community and things there as well. So it's, uh, it's always cool to see.

Jonathan: Yeah, oh that sounds like fun. I have had an experience earlier in life Dragging the sound system a portable sound system outside It was a church in that case But dragging it outside to the front steps to be able to solder something to fix it and not Smoke the inside of the building up.

So I I know how that goes

Gary: Yeah, yeah, it's uh, you get some funny looks from a hotel or a venue soldering gear in the middle of one of their conference rooms, that's for sure

Jonathan: Uh, yeah, I feel like they should know what they're getting themselves into though hosting a conference full of geeks and hackers

Gary: Yeah, well our venue this year have graciously welcomed us back, so, uh, clearly we didn't do anything too wrong last time we were there.

Jonathan: Yeah. Um, okay, what are some of the, uh, I guess what are some of the talks that you are excited about that are coming this year?

Gary: So, on the schedule track this year, there's a few things that I'm quite excited about, actually. Um, we've got Stuart Langridge talking about, uh, open web advocacy. I know that's something that he's been really, you know, fighting for.

Um, so just, you know, getting the open web available across a variety of platforms. I know he's been quite pivotal in getting things like, uh, other browser engines available on iOS, which is, you know, something that we've all struggled with for a long time. Um, We've got people giving us talks on audio podcasting which are going to be really cool We've got hacker public radio actually talking us through what it takes to get your certificate in order to do In order to do kind of amateur radio stuff in the UK and what are all the things you need to consider for that?

And then we've got, you know, even some of our sponsors this year, like Utah are doing a workshop on how to organize a union in your workplace, which is something that we know tech in the Europe is particularly under, you know, and unionized say they're giving a workshop on why should you join a union and what are the kind of things that you need to think about for that?

And then of course we've got our classic Oddcamp panels this year, which is kind of a look back over the last five years and all the things that have changed in FreeCulture since the last Oddcamp and what's been good, what's been bad, how do we make the next five years of FOSS and FreeCulture even better, and how can you play your part.

So a bunch of really cool talks going on, um, I named a few there, but there are a bunch more that, uh, that we've got available and they're all at oddcamp. org slash schedule. And of course. The great thing is that half of our talks aren't even announced yet, because the attendees make 50 percent of the agenda at OpCamp, so it might be that someone turns up with something really cool that we just haven't thought of yet.

Jonathan: Yeah, that's always, that's fun. Um, okay, Simon is whispering in my ear here that there is some offbeat stuff that he wants to talk about.

Simon: Yes. So, um, we're, we're going to, uh, one of the things that's always happened to odd camp has been, uh, a raffle. Um, uh, and there, uh, we've had sponsors supplying toys. Um, actually the organizers have a small budget for, for buying toys as well.

And it's very likely that there will be a, uh, a raffle for all the attendees this year as well. I suspect Gary is going to go out and buy some stuff. Uh, I've got a big budget. box of toys next door. I've got things like a robotic car that's powered by a raspberry pie. I have a lifetime supply of LEDs. Um, I have, you know, those sorts of things.

And then we've been talking about having a swaps table this year, like you'd get at a, at a local meetup where you, you bring something and take something. Uh, and we're not quite sure how that's going to work. But we are probably going to tell attendees to, to bring good quality things that they would love to have been given, uh, that they can bring along to the SPOPs table.

Uh, and then one of the things about OGCAMP is it's, it's actually a very safe environment for people who, um, Find large public events, uh, challenging. Uh, there's a lot of very caring people who take care of the folks who are around. Mm-Hmm. . And so a lot of what makes on campus special actually happens outta the meeting rooms in the, in the, in the corridor spaces, the hallway track, the open spaces.

Uh, it's a hallway track, but it's a, but it's a, it's not just a bumping into friends hallway track. It's also a taking care of, of people who are there for the first time. Type hallway track too.

Jonathan: Yeah, interesting. Um, let's see. What was I going to, what was I going to ask about? I had something that came to mind.

Um, so like what are, what are some of the, it sounds like it's a, it's an intersection of a whole bunch of different things. So you've got obviously people that care a lot about open source. Do you have some other niches there? Like, is there, is there a retro hardware enthusiast sort of group that comes?

Do you have security people that come like what, what, what do these different groups kind of look like? What are the, what are the different interests that get represented?

Gary: It's a good question. Um, I'm trying to think back five years.

Simon: I mean, it depends on who comes, right? You know that. So there's a quite interesting profile.

Uh, I know that one of our organizers has recently got into, um, creating art with, uh, with plotters and, um, with pen plotters. And there is certainly going to be a little section that is interested in that this year. Um, I, I, we've previously had, uh, people who are into security having, uh, having questions about that.

There's typically quite a big Ubuntu community. Um, faction in the room, uh, trying to be friendly, welcoming Ubuntu people. And of course that's evolved over the 15 years, uh, into something completely different now. Uh, so I, uh, but it really, it's going to depend on who shows up. We've got a couple of hundred people showing up.

Um, some of them, the names I recognize lots of people I don't, and it's the odd camp is the product of the people who come, um, because we're, we're We're cowards. We, we do plan a planned track just in case, you know, no one comes with any talks, but that's never happened. And so it's going to be the product of, of, of who comes and that makes it quite different to most of the other conferences that I attend, where the conferences, you know, I can tell you in advance what's going to be happening at all things open, and I can tell you, uh, you know, in advance what's going to be happening at FOSDEM, uh, to a certain degree.

Uh, whereas OGCAMP. I can tell you some things that are going to be happening. There's going to be a raffle. Um, there's going to be two, two rooms full of planned talks. But apart from that, who knows, you know, that's part of the charm of it.

Jonathan: Is that really what's meant by an unconference that things tend to happen ad hoc?

Gary: Pretty much, yeah. So it's, we call it an un conference because there almost isn't a conference, right, until people turn up and make one. So, um, like I said, we have two rooms or two rooms of our schedule track that we, yeah, we come up with. But actually it's, it's the people who turn up and present their interests to like minded people that really make it an un conference, I think, for me.

Um, Yeah, it's, it's a very, yeah, it sort of evolves over the two days. You find that you get a well attended talk about, uh, TLS from some of the security crowd and you'll find someone else go, Oh, there's a bunch of TLS stuff that they didn't cover in their talk. So I'm going to do another one in TLS tomorrow.

Um, and yeah, you sometimes find that. Rooms get full and people are just giving ad hoc talks in hallways or in a hotel foyer and they've got 10 people grounded around them or in our kind of event space, someone turns up with a cool toy and I think one year someone turned up with a robot conferencing device that could walk around and be controlled and, uh, yeah, it was just walking around and people are having conversations with it and it was great.

So it's, it's the unexpected, like you say, the thing that really makes it an unconference for me.

Jonathan: Yeah, as you as you think about the things you have scheduled like on the the official tracks this year Are there any particular talks that you hope people bring?

I know that's kind of an interesting question But is there anything that you don't have covered that you really hope people will cover?

Simon: You know, I'm hoping we've got some folk there who are very into activity pub Uh, and I'm hoping we're going to get some, some good, uh, horizontal thinking about ActivityPub showing up spontaneously.

Uh, you know, a shout out to Andy Piper, who I hope will be the catalyst that causes that to happen. Uh, but, uh, you know, I'm hoping there'll be some, some really good things about that, because I think that's, that's close to the center of where the biggest hope for open source is at the moment, is getting away from over centralization.

Mm hmm. Uh, moving into Federation. And having devices and software which is simple enough for everyone to federate instead of becoming the, uh, the, the data slave of meta. Uh, and so I, that I really hope is going to show up, that we're going to see, talk about federation, talk about ActivityPub, talk about, um, uh, cutting the cord to the, um, the ad industrial complex.

Yeah. Yeah,

Jonathan: I get that.

Gary: I think for me, I'd love to see some talks about self hosting coming up. I think there's a bunch of really cool open source projects that people can self host that are genuine competitors to, you know, the proprietary. Google Photos or Google Drive or Office 365's of this world that have come along in the last five years and, you know, really running with, with what it is that, um, those products had, um, but you know, you can, you can run them on a server in your garage, right?

And I think that's really cool. So, you know, people coming along and talking about those projects and talking about their journey from proprietary platform through to, I run everything on a server myself that's in my garage is, is a really cool thing. I'd like to see some of this year too.

Jonathan: Yeah, um, I don't suppose you have anybody coming that you know of to talk about Meshtastic?

This is a project that I've been spending my time on here recently.

Gary: I haven't seen anybody so far.

Jonathan: I may have to go and uh, drop a link to this in one of the discords and see if anybody there wants to go and give a give a talk on it because that would be fun. Uh, it's, it's lore, lore radios that talk to each other but they, they mesh and they're all decentralized.

I think it would be a great fit.

Gary: Yeah, yeah, it sounds like something that people would be interested in.

Simon: And I'll be bringing one of my raspberry pies along and giving a talk about running, you know, Because that because I host most of the things I care about Uh on a rack of raspberry pies just downstairs from where i'm sitting And it's very straightforward to do Um, and there's no reason why most people couldn't do it to be honest.

Jonathan: Yeah. Yeah, that's true uh, simon, you said you are the sort of the the treasurer and the um, I guess sort of the legal host You of Oggcamp? I'm curious. I'd like to hear more about that. Um, why, why such a thing is needed and what all you, uh, what all you do.

Simon: Yes. Well, uh, so that, that arose, uh, a number of years ago when, um, a, uh, a gentleman I work with who happens to be a lawyer said that there was a community of people running a conference and they needed a fiduciary host.

And I, I run a, uh, a small not for profit organization called Public Software in the UK. And, um, the reason you need a fiduciary host. is because, uh, I think like a conference, there's actually quite a lot of money floating around, uh, all camp is going to cost us probably a five figure sum of money to put on.

And, uh, and it, it breaks even. So the, at the end of the process, there's probably going to be a five figure sum of money sitting ready for next year. And somebody has got it. Somebody's got to keep it, and you've got to trust someone to own it. And, um, this particular conference is one that gets run by whoever is available next year.

And so the people who are responsible for it in 2024, possibly none of them will be involved in 2025. So, If that's the case, who owns the domain names? Um, who has got the money in their bank? Uh, who is it that has got the legal standing to make contracts with the hotel? And so that's what Public Software does, the organization that I run.

Uh, and public software, um, provides a home for unincorporated associations of, of people who are doing things for open source and free culture. So, um, we host, uh, OGCAMP and we have one other project called COSM, which is a crowdfunding pot for maintaining the, uh, open document format that you find in, in LibreOffice and now in Microsoft Office.

Uh, and so, uh, I, I do that. I, um, Uh, run the incorporated association that looks after the assets of odd camp so that Gary is able to show up and there is money for him to spend on the conference this year. And there is somebody who's willing to sign the contract with the pendulum hotel. And there is somebody who is willing to pay the, the, uh, the crew radio supplier.

And there is somebody who can pick up lunch for the volunteers. And then at the end of the show. Um, public software will, will draw everything together and get ready for next year and make it available to whoever shows up to run OGCAMP 2025. So fiduciary hosting, it's, it's kind of like what, um, software in the public interest or Software Freedom Conservancy do for open source projects.

Uh, just for things, I do it for things that aren't software, for, for a small conference, for a standards project. Publix offers hosted other small activities over its lifetime as well.

Jonathan: Yeah, I guess that's something I didn't think about, but if you have that much money running or moving around, like if, if nothing else, you just need to be able to have a paper trail of nobody walked away with a thousand dollars in their pocket that shouldn't have.

Simon: Yeah, so we do that. And also, um, you know, there is value added tax, sales tax to be collected and paid. Yeah, that's true too. So we do that. And, uh, uh, you know, that we've, we have credit card machines, uh, you know, ordinary individuals typically don't have. Credit card facilities and we have credit card machines so we can host the Stripe account and we can, we've got, we have a Square account that we make available.

So it's all of these little details that make it possible to put on an event. Modern society has, uh, as in so many other areas, has, uh, has, uh, officialized or bureaucratized the things that previously would have just been, uh, the way that mates did things together. So, if we'd been running a village fate 40 years ago, we probably wouldn't have needed public software.

Right. But in 2024, you absolutely need a fiduciary host to look after these things for you. Because otherwise, Gary is going to find himself with HMRC wanting to know where the VAT is. He's going to find himself having to pay corporation tax on the turnover personally. And he's going to find it's added to his income tax return.

And he doesn't want any of those things to happen. Right. So, so we make sure that doesn't happen too.

Gary: Yeah, Simon makes it so I can just, uh, contact the hotel, get the invoice sent, and, uh, forget about it and carry on with my day, which is, uh, which is always great. He takes the bureaucracy out of what otherwise would be quite a painful thing come tax return season.

Yes,

Jonathan: yes, understood. Uh, how many, how many tickets do you guys, uh, well, let's see. How many tickets total? What's your, what's your max capacity for the event?

Gary: Absolute maximum for the event in the venue that we're in this year is 250. We hope to get somewhere close to filling that. Um, and we're not, we're not too far off actually.

Um, Where are you at?

Jonathan: How many have you sold? How many are left? I

Gary: think we're just under 200 at the moment. We're not too far off. So,

Jonathan: so if nobody else signs up, you guys still, you're on, you've got a good conference, even with just under 200 people, that's a, that's still a good group of people.

Gary: Hey, we've, we've definitely got enough people to, to put on a good show, I think.

Um, and yeah, plenty of people to come and come and fill slots for talks as well. So

Simon: in terms of cashflow, looks like we've collected enough money to refresh the pot for next year. So, um, I think this, this event is going to break even and that's what we want to do. We don't want to make a profit. We want to, we, we do want to break even.

And we want there to be about the same amount of money in the pot next February as there was in the pot in February when Gary took it.

Jonathan: Uh, what, what is the cost for it as far as per ticket?

Gary: So what we've always done with Old Camp is trying to keep it very accessible to people. So This year, um, I think it's, it's no secret to anyone that the bottom has fallen out of the ad market and, uh, sponsor money is much more difficult to get hold of.

Uh, so this year we've said, yeah, we're going to honor that pay what you can model. Um, but we've got a suggested ticket price of 40 pounds. So, For your 40 you get, you know, two days worth of, you know, really good solid talks on the schedule track, plus whatever, whatever else turns up, plus the hallway track.

Um, but if you can't afford that, then absolutely you can pay us anything from 1 upwards. The only ask there is that you cover the cost of our ticketing platform. Because they charge us a small amount to issue tickets and store people's records and things like that.

Simon: Then there's the opposite end of the thing where we have a bunch of people who say, you know, we really want to support you.

And rather than taking donations, we put on the system some high price tickets. So we've had a whole load of people who have bought what we call professional tickets, which are the 100 tickets that for people who can expense it. And so we've had, uh, quite a few people have bought professional tickets.

They don't have to, they could have just bought the one pound tickets if they wanted to. And it's quite comforting and reassuring that if you look across all of those tickets we've sold, uh, there's a pretty even spread of people at pretty much every price point between, I think the most anyone has paid is 200 pounds and the least anyone has paid is five pounds at the moment.

And there's, we have a pretty good spread across the whole, Yeah,

Jonathan: I'm, I'm actually really glad to hear that you guys keep it affordable that way. I, I was looking at going to a conference. You know, not, not anything particularly open source, although I tend to make conferences open source when I go to them.

Um, I, uh. Famously was at a, uh, U. S. Department of Defense conference where they were talking about the problems with, uh, FPGA security. And, of course, I, from the back, Why don't you just open source the toolchains if you want it to be more secure? I have lots of fun doing stuff like that. Uh, anyway, this conference, I was looking at it in the background.

Tickets were like 699 a piece or more if you wanted everything. It's like, oh man, we can't expense that right now. Um, so I think that's really neat that you guys make it, uh, you make it affordable. You mentioned sponsors, uh, And I, I, I was going to ask whether you have sponsorships. Um, and, uh, so how does, how does that work?

Do you guys go, do you have like a list of companies that you go after each year that it's going to be put on and you say, Hey, you guys supported last time. Would you be interested in, in, in helping do this? And then like, is there a banner somewhere? You know, is there, is there a banner wall where people come up and take their picture with all the logos behind them?

Yes.

Gary: Yeah, we do have that. So. So I think one of the nice things about OGCAMP is that we've always tried to not be super corporate, right? Um, yeah, you're not going to come and see, you know, logos of insert big FOSS company here plastered in every single conference room. But what we want to do is cover our costs and we want to, you know, return a fair value to those people who help us cover our costs.

So, um, this year we've actually ended up with four sponsors. I think I'm right in saying that none of them have sponsored us previously. They are all entirely new sponsors this year. Um, and they are anything from kind of small software development companies, to larger open source projects, uh, to a trade union actually this year is our pinnacle sponsor.

I mentioned Utah a couple of times. Yeah. Um, And yeah, so they get their Lego on a t shirt and they'll get their Lego on banners and things and, you know, a personal thanks from us for, for really helping make our camp happen because we couldn't, we just couldn't do it without, without that little bit of extra cash injection that we get from sponsors.

Um, So, um, yeah, I think like I said earlier, uh, Utah running a couple of workshops this year and a panel discussion. Um, a couple of other sponsors have got stands in our kind of community room where we sell merch and put out tables for people to do anything from play role playing games to show off their cool Raspberry Pi projects.

Um, so yeah, we, we have a list of people we target, um, but this year it's actually just been an entire new set of sponsors, which is actually really cool. And what we're hoping is that that will introduce a whole new demographic of people to, to OrcCap.

Jonathan: Um, so I was going to ask, I was going to ask who the sponsors were, and I think you sort of just covered that, um, you've got the, the trade union.

Uh, is there any music? So one of the things that it, it sort of, it sort of hits my mind that there might be an intersection here is that you could have musicians and people very, very interested in music, very, whether putting it on or doing talks about music or even building your own music hardware, it seems like you could have some of that.

Gary: Yeah, so Dan, previous organizer, had previously done our evening entertainment in 2019, which was quite cool. We don't have any kind of scheduled evening music entertainment this year, but I'm absolutely sure that there will be people turning up with their cool synth project that they've built with their ESP32s or something.

I know we've definitely had things like that in the past where someone's turned up with, uh, yeah, here's my, here's my rack of, uh, Analog synths that I've built from open source hardware and say yeah that there always is that kind of maker slash music crowd I think that turns up our camp But again, it's it's kind of like we were saying it really depends on who turns up as to as to what's gonna be there But but that is one of the the many crowds of people that turn up our camp.

Jonathan: Yeah Do you have anything like I know in some conferences people like to come and actually camp out? Uh, to, to attend it rather than having to pay. Is there, is there something like that? Is it going to be a tent village?

Simon: Um, I think it's unlikely. Okay. Um, you know, the Manchester is not the greatest place to camp out during October.

Uh, and, or, and it's gonna be quite busy in the city this year. There's, because there's a, there is a sporting event going on, uh, as well at the same time as the conference. So I, I, no, I, I think everyone's very likely to either be local or in hotels. , uh, certainly I haven't booked a room yet, so I really must get round to doing that.

I, I might be sleeping on the street. Simon's gonna be ski out on the

Gary: street. Simon's gonna be on the bench outside in the, uh, in the hotel.

Jonathan: No, Simon's going to be in the hallway track like, Hey, do you have an extra bed in your hotel room?

Simon: It's the hallway and sleeping bag.

Jonathan: Oh, that's great. That's great. Um, so let's see what, uh, what, what have I not covered?

What else do you guys want to let folks know about? What, what else are you looking forward to with the conference?

Gary: I think for me, it's, it's just getting something running like this in the UK. I think the UK is. Is kind of really lacking in these community led FOSS events. Um, yeah, there's, there's a bunch of them that exist across in the U S um, but, but we're definitely lacking in them in the UK.

So I think for me, it's going to be the main thing I'm looking forward to is just seeing old faces, new faces, what people come up with and really, you know, how the community has evolved in the last five years, I think really for me is, is the key thing that I want to get out of old camp this year.

Jonathan: Yeah.

Simon: I think I'm in a similar place to that, you know, in the, the, the curious thing is I've been doing open source for a couple of decades living in the UK.

And I've always had to go abroad to go and do anything, you know, and so there is a certain desire to hold grassroots events that are not about, uh, feeding a corporate strip mining open source culture, but they're actually about people who use things and make things. And so I've always loved OGCAMP for that reason, that it's about the only event that I can go to in the UK.

Actually, it isn't the only event in the UK. There is a, there is a, uh, another conference in the UK now as well called, uh, EMF, which actually does have a campout, uh, that happens as well. And that's also in the north of England. So there's, there's now two events in the UK that, that are, uh, addressing that niche.

And I find that really encouraging that that's happening. Um, I, I do, I've often wondered whether, uh, Europe needs to have an, uh, an, a summer FOSDEM. And I'm kind of hoping that eventually one of these events is going to evolve a bit into a summer FOSDEM so that we can have a Europe wide open source event.

Europe does have quite a few good open source events. Um, there's a really good one that I'll be plugging later in, uh, happening in Northern Italy in November. And then there's a couple of, uh, good ones in Germany, like, uh, uh, the one that happens in Bonn. Um, and there's a, a, a good international conference called FOSS Backstage that happens in Europe.

So, there's good things going on, but the UK has tended to be, um, the one place where there has not been enough going on. And I think that's one of the reasons why I'm excited about being involved with Oddcamp. I'm really pleased that Gary's come along this year. Gary's a very level headed, very capable, uh, uh, uh, sensible person.

And I'm very pleased to be supporting him.

Jonathan: Yeah. You know that that idea about not having anything in the UK and sort of missing it I get that because like there's not a whole lot here in Oklahoma where I'm at and Be nice. Don't laugh at my state. Uh, I think I think Oklahoma is actually about the same size as UK if I remember correctly It's it's gonna be on the on the discord Somebody put a picture of like the map of Europe and then Texas over it And like, Texas is just, is bigger than Germany and covers half of France and covers half of Italy.

And, you know, Doc Searles famously says that the big difference between the United States and Europe is, in the United States, we think a hundred years is old and over in Europe, y'all think a hundred miles is far. And that just, that really, I think that's actually really great. It, it covers, Sort of the mindset difference that comes out of the history and geography of the two places.

But like I've had this thought there's nothing in Oklahoma that I that I know of at least nothing big uh, you got to go down to Texas and I got real excited because there was somebody that was going to do like a once a year I think it was the Texas Linux Fest and was going to be in Dallas like oh Dallas That's that's you know, that's when the not too much more than 100 miles.

That's not very far Uh, you know, I could get down there in three hours. That's not too bad um I don't know if that's happening again, because again, we got hit with COVID and so a lot of things closed down. Yeah, it really makes, it really makes me think that, uh, maybe we need more people from the community to start talking about things like this and try to put them on and put them together.

Because there is something to be said for getting together in person and not just over the internet. Uh, meeting, meeting people in person. And actually doing things, putting your hands on things together and, and fiddling around with stuff. Um, So I think, I think that is cool and I, I, I look forward to hearing stories from this year about what all happened and which talks happened and which ones were popular and people that got to meet each other for the first time.

Simon: And you know, Jonathan, we can discuss licensing OGCAMP to you for OGCAMP West if you want to run it over there in Oklahoma.

Gary: Well, it was that meeting of people in person that kind of inspired me or I guess, uh. Maybe drunkenly got me convinced to organise Oddcamp this year. Like

Jonathan: all great ideas, it was birthed in a tavern, in a pub.

It

Gary: genuinely happened in a pub, yeah. So, um, it was actually, I worked for a brief period with a previous organiser, John Spriggs. And, uh, he was like, oh, I'd love to see Oddcamp come back, but I don't want to be the one doing it. And, uh, you've been to Oddcamp a load of times, you know how it works. How do you feel about putting, uh, putting on an Oddcamp?

Couple of beers later, and before you knew it, I was sending an email to Simon saying, Hey, what do we need to do to get this thing kicked back off on a cold December night at a white Christmas party? So, uh, yeah, yeah, it's, it's getting the community back together, I think, is where some of these things really, really spawn out of.

So it's also going to be interesting to see, like you said, what, what other things spawn out of Oddcamp and having people together that, um, yeah, is, is going to happen. Yeah,

Simon: you know, I want to say to all the odd camp attendees and supporters who are, who are listening that, um, we're getting back again, back together again this year.

We haven't been able to nail down all the things that you, that you want there to be there. So try and bring them with you this year, if you can. And if you can't help us organize it next year, so that they're there. So, you know, we, as Gary said, we don't have a. Um, an event organized on the, uh, the intermediate night on the Saturday night.

Uh, it would have been great to have booked a room and got a band and had everyone, you know, able to order their fish and chips and mushy peas and their half a lager. Um, but, uh, you know, that didn't happen. And so maybe it can next year and maybe it's one of the people listening to this that's going to be the person that, that insists on organizing it.

Um, Probably too late to organize it this year. I think that the hotel told us that they, you know, we've, we've, we've paid for a certain number of rooms. Uh, we could go back to them and try and say, Hey, you said, you know, we said we didn't need the ballroom. Well, we do now. Um, and if you're listening to, you're listening to me saying this and you really want to organize the thing in the ballroom, then get in touch.

My email address is, uh, simonatwebmink. com. And you can, you can get ahold of me that way. Okay. But, so this year I see very much as a relaunch, you know, it's, it's doing the things that we know work, um, hoping someone's going to bring the stuff that we haven't been able to organize, but really hoping that we're going to have some new blood who are going to help us organize, um, the double this event next year.

Jonathan: Yeah, yeah. So what, like, you, you allude to this, what's not happening that people wanted to see happen this year? What happens in the ballroom?

Gary: Well, what happens in the ballroom stays in the ballroom, I guess. I could tell you, but then I'd have to

Jonathan: kill you. I walked into that one.

Gary: Previous years, Oddcamp has been quite famous, I think, for its, its social track.

Um, so we've always had some kind of entertainment on maybe the Friday night, definitely the Saturday night and occasionally actually the Sunday night. Uh, we've always had some kind of prearranged entertainment. So, uh, yeah, whether it be a band playing or some kind of FOSS quiz on the Saturday night or something like that.

Um, Like Simon said, this year our focus has really been on what do we need to do to get OggCamp up and running. Um, and what do we need to do to do that in a way that is sustainable for a small, new, organised increase. So, some things like that have fallen by the wayside. Um, and yeah, Simon alluded to things like the raffle, um, We're pretty sure the raffle is going to happen this year.

They're kind of famous or camp raffle. Uh, we just need to, as an organizing crew, get our head into gear and make sure that we've got everything that's needed in terms of prizes there. Um, so I think the big thing is going to be the social track. I think that's the big difference that people might notice this year compared to previous years.

Um, But that said, um, the hotel have graciously said that we will have the bar open for OCCAMP and they're putting on some food and things like that for attendees to buy at a reduced rate. So, yeah, there will be social tracks coming, uh, you know, there will be things happening and I think it's human nature to have a like minded group of people get together and congregate in the hotel bar or head off elsewhere.

Um, so, yeah. Yeah, I think, yeah, it will, it will feel like an old camp, um, it's just going to be a case of, uh, yeah. I guess a little bit of autonomy happening, uh, among attendees that perhaps we, we didn't do quite as much before.

Jonathan: Yeah. My, my wife is in the discord and she's also apparently listening to some of this and she says, if life circumstances were different this year, I'd all be for attending this conference in Manchester.

Like both of us, none of this just sending Jonathan business. In years past, I went to a conference in Dublin by myself and, uh, While it was fun, it was a bit of a bummer that I couldn't take her along. So one of these days,

Simon: you know, it's not too late. Just check, check out, uh, the, the, what flights are available.

There's going to be some cheap flights direct to Manchester. You can just make the weekend for it.

Jonathan: Yeah, I think our kids are a little too young for that at this point, but, uh, that's, that's all right. Maybe in a couple of years. So, what, let's, let's, let's, let me ask you this. What are some, like, highlights from the last couple of times you guys had OggCamp?

Uh, what are some of the talks that really you remember or just memories you have that you think people would enjoy hearing about?

Gary: I think for me the first dog camp I went to was really eye opening just as to how small the UK is. Um, so I ended up actually getting talking to a guy in, uh, on one of the hallway tracks and, uh, I'm from a fairly small county in the UK, uh, so Norfolk on the east coast for anyone who knows it.

Um, quite famous for the fact that we've got no motorways in any one city. So it's, uh, it's a fairly small place and I got talking to this guy, um, And we were like, he was like, where are you from? And I said, where I was from. And it turns out that he lives five minutes down the road. We both have, yeah, had similar jobs at the time.

Very similar kind of interests in FOSS and things like that. And we've stayed in touch ever since. So that for me was a real OGCAMP highlight. Um, but in terms of talks and things, it's actually been the talks that, necessarily directly FOSS related that have really appealed to me. So I kind of alluded to before that we've had talks on things like mental health and stuff like that.

And actually going along to those talks and just hearing those insights as to, ah, this person struggles with the same things of, you know, Struggles of working in IT as I do or this person has come across this particular problem They've tried to solve in this way and perhaps that's a different way that I could approach something that have I've always been highlights for me So it's it's almost been the unexpected things that you couldn't plan for going to a conference that have been highlights for me So I mean you have any thoughts

Simon: Yeah, wandering around seeing the toys people have got in the, uh, in the, in the exhibit area where the tables are.

That was, that's always a feature for me. I remember having a picnic on the front steps of the venue in Liverpool when the conference was held there. Um, I remember giving a talk all about, uh, the, uh, legislation that keeps on trying to backdoor crypto, um, which is back again this year, just in case you had any concerns.

Uh, so, uh, those are all pretty, you know, they're, they're, they're minor sounding things. They're pretty random. For me, the event, this is, this is the, not the event where there are the, the big corporate talks. This is the event where there are the, uh, the important new relationships are created. And that's what I really hope for for this year as well, is that we'll meet interesting people and befriend them.

Jonathan: Yeah. Yep. Very cool. All right. Uh, let's see what, uh, what have I not asked about? What have we not covered that we, we ought to let folks know about?

Simon: Great questions. Uh, so if you want to buy tickets, uh, there are still a few available. Uh, you'll, you can find them at, uh, I think the org. camp is, uh, is the, the easiest to remember URL that will get you there.

So if you type in org. camp, it will take you to our website. Uh, and I'm pretty sure that we bought all the other websites that sound like that as well. So I think we, we have oddcamp. com and things, but what the cool one is odd. com. There

Jonathan: you go.

Simon: Um, and, uh, you know, I encourage you to pay what you can for the tickets.

And, and that means at both ends of the scale, if you can afford the thousand dollars for the ticket, please buy a ticket for a thousand dollars. Because you're, you're investing in the future of the conference. When you do that, the conference isn't run. For the benefit of, uh, anyone financially, um, what will happen if there is a surplus is public software will hang on to it and it will be available for next year's conference to be bigger and better.

So, um, uh, it's, you know, it's, if you can afford to, uh, to, to buy the thousand, thousand pound ticket, we don't actually have a thousand pound ticket, Gary, could you fix that before the show goes out? Um, go, go, go ahead and do that. Um, uh, Also, keep an eye on the socials, we do have a couple of venues, I don't think we've fixed on an official venue on social networks this year, but we do have a Mastodon account.

We do have a room on Matrix that you can find, and there may be some other remnants somewhere, I think we might still be on that social network that nobody should use anymore.

Gary: Yeah, there's a, there's a few places there's, there's the X accounts, there's a telegram group, uh, there's a discord as well. I know you love hanging out in discord Jonathan. I

Jonathan: didn't say I love hanging out in discord. I said that's where I find myself a lot.

Gary: Yeah, I think I'm in like five discords at this point.

I can't, can't honestly say I read messages in all of them. I'd have to go count. Oh my goodness. A lot. It's quite a lot. Um, yeah. Let's see. Og. camp is probably the place to go, um, and anything that you need to know is, is kind of linked from there really.

Jonathan: Yeah. Uh, what are the dates? I don't think we've ever actually said.

When is this?

Gary: It's the 12th and 13th of October, uh, this year, so coming up in just a couple of weeks.

Jonathan: Less than a couple of weeks. Yeah, that is, that is coming up soon.

Simon: There's still rooms at the hotel, so you can still stay at the venue, which is the Pendulum Hotel in Manchester. So you, uh, that, that's available.

There's still a few tickets left. Uh, if you're quick, um, Gary's going to have to turn off the tickets when we reach the fire limit for the venue. Uh, so, uh, you want to get in there as soon as you hear me saying this, cause there's stop listing now and go to org. camp and buy your tickets.

Jonathan: Yeah. That's the important thing, right?

You don't have to listen to the episode. If you're going to be there, uh, what, what year did, did our

Gary: camp start? You'll know this better than I will, Simon. I don't know, I joined it after the fact. 2009, I think. The last OddCamp was our 10th anniversary in 2019. So, uh, this is the 11th OddCamp, but it's our 15th year, which, uh, feels like another milestone.

Jonathan: Yeah. Boy, the world was different in 2009. Goodness.

Simon: Ah, those were the days.

Jonathan: Yes. Yes, they were.

Simon: Still a Sun Microsystems, then.

Jonathan: Yeah. Uh, Gary, I didn't ask and I guess I should. How did you, uh, how did you get into, we know, we know Simon, we know where Simon came from. How did you, how did you get into like the, the whole open source and free world?

Like what's your, uh, what was your gateway drug that got you interested and that you started coming to Oddcamp?

Gary: It was a teacher back in high school actually handed me a CD. So yeah, I, I at the time was, uh, was running a, uh, Not so great laptop that been handed down and handed down and handed down and Windows didn't run so well on it and I just went to this teacher who was a Gentoo user back then and said yeah, what could I do to sort this out and he said, I'll sort you something out tomorrow and came in and almost, you know, dealt under the desk this Kubuntu 7.

10 or 7. 04 or something CD and I was like, yep, here you go. Um. And never looked back, I installed that on that machine, it lasted me another few years and uh, yeah I guess from there ended up getting into, you know, working in IT, advocating for replacing a bunch of Windows stuff with FOSS where it made sense, um.

Then kind of got into the kind of cloud world and continued to advocate for open source stuff there. Um along with attending Uh op camp and fosdem and linux fest northwest and anywhere I could get my fill of uh, false goodness Um, that's that's where i've been for the last 10 or 15 years, I suppose

Jonathan: And you're thankful that your teacher gave you a kubuntu disk and not a uh, not a gen2 disk

Gary: Uh, yeah, I mean it might have had a slightly different appeal, I mean since then I've moved off of the Plasma desktop and, uh, daily driving Fedora with Gnome.

But, uh, yeah, I mean, it was probably a wise choice not to send me down the road of, uh, doing a Gen 2 install at, uh, you know, 12, 13 years old or whatever it

Jonathan: was. Yeah. All right. So let me, let me actually cover this and we get to ask Simon. I don't think we asked Simon this. Um, and I don't know the answers.

We're gonna start with Gary. I want to know what's your favorite text editor and scripting language.

Gary: Uh, for me, it's got to be nano and bash. I just, I want to deal with something simple. Uh, so I actually spent a lot of time just in nano writing stuff in bash, which is probably the most boring, terrible answer I could give.

But for me, I'm all about keeping things simple.

Jonathan: No, no, that's all, that's all good. You know, Simon, I don't know that I know the answers to this. I don't think we've ever asked you. Yes. What's your, what's your favorite text editor in scripting language?

Simon: So, I never really got into text editor religion, and I use whatever there is that is on the system I'm running.

Um, I have a soft spot for nano on my raspberry pi's, uh, but I, you know, I used to enjoy using E when I was at IBM and, uh, which nobody will know about and, um, uh, it's, but, so he is the editor that, that Emacs. Became when you added the macro language.

Jonathan: So

Simon: I, I used to enjoy using that. Uh, I do most of my editing these days in whatever notepad I can pop up on the device I'm using at the moment.

And I use Markdown, um, and when it comes to scripting, um, it's been a while. I have to tell you. Uh, so the last scripting language that I used in Anger was on a, a sign organizer. Uh, I actually wrote commercial software in sign organizer scripting language. As

Gary: you went lying when you said it'd been a while, eh?

I think that's pretty much it. For me, it's a really difficult question to answer these days because I spend so much of my time in the cloud world that it's like, you know, whatever thing abstracts away the clouds is what I end up using. So I end up writing a lot of Terraform and Ansible and CDK and stuff these days, um, just because I guess that's what I work with day to day.

So, uh, I don't get to play with, uh, with much nice, cool scripting stuff anymore.

Simon: Yeah, to give you an idea of how old we're talking here, um, uh, so, uh, my story was a little bit like Gary's, so my, my physics teacher at school, uh, uh, was moonlighting while he was teaching physics and making the motherboards for, uh, compute for development systems that used a 6800 microscope.

processor called SWTP 6800 development systems. This was in 1977. And, um, so that was my first computer. Cause I used to, I do, he used to soak test them in one of the labs. And we used to go in during the breaks and program them. And the reason I'm telling you that story is I went around the computer history museum in Silicon Valley recently.

And I, there is the computer that I learned to program assembly language on, uh, sitting in the computer history museum. And that's how I know I'm old. Ha!

Jonathan: When you find your first computer sitting in a museum, yeah, that would do it. Uh, now I have to think, like, what was my first computer that I ever actually did anything on, and is it old enough?

It might be. It might be. The first one I ever played with, my dad had one of the Trash 80s. Excuse me, TRS 80. But that wasn't really modern then that was like pulled out of storage But I think we had a like a tandy one of the original tandies and I think those are just old enough to be museum pieces now, so I suppose i'm old too.

Simon: Yeah You keep using you keep using that hair dye jonathan

Jonathan: No, no, mine's all natural there's a little gray poking in there, but it's not too bad

Gary: Now I feel young when I can say that it was a pentium 133. It was You The first machine I really used and did stuff on, but even then that was somewhat of a hand me downer space.

Jonathan: Yeah, yeah, yeah, I get it. All right. Well, I am, uh, I won't be there, but I'm looking forward to OGCAMP because it sounds like you guys are going to have a great time this year. And hopefully we're going to have

Simon: an old fogeys reminiscence session over a beer in the, uh, in the, in the bar at the hotel where I will show people photographs of the SWTP 6800.

And we can talk about a 6800 assembly language and the unique register commands it had.

Jonathan: Yeah, I mean, who knows? You guys keep doing it, you'll eventually have the, uh, retrocomputing track. People will bring their old machines and let people play with them. Alright.

Simon: Now there's an idea. Next year, Gary, okay?

Yeah, we'll put it on the list.

Jonathan: I mean, retrocomputing is big right now. There's a lot of people that are, uh, Very nostalgic for the machines of yesteryear. So, all right. Thank you guys for being here. I appreciate it very much. Gary, particularly, thanks for coming and telling us all about the conference and, uh, best of luck here in a couple of weeks that everything goes exactly the way you want it to.

And, you know, all the surprises are good and all of that stuff.

Gary: And tech gods are with us for demos and audio and. projectors and other such things.

Jonathan: Yes. Yes. I've been that guy and there's always something that surprises you. Uh, awesome. Thank you so much. Uh, Simon, this is where normally I ask you what you think, but you were sort of the, uh, guest too.

Um, I guess I'll go ahead and ask you though.

Simon: Well, I think everyone should buy tickets and come to the conference in Manchester because, uh, you know, I could. I could hype it up and say it's going to be, you know, the, a super majestic technical whiz orgasmic thing. Uh, but actually we're just going to be a group of people who want to be friends, uh, coming together and sharing a space and sharing our interests with each other.

And, um, uh, I think that, uh, if that appeals to you, then you should go get a ticket. Uh, and if that doesn't appeal to you, you really should go to, I dunno, some Oracle conference.

Jonathan: If that doesn't appeal to you, then maybe you need to rethink the decisions that have led you to this point in your life. Oh, all right.

Well next week, interestingly, we have somebody from IBM going to talk about their, uh, Open AI stuff, and it'll be very interesting to compare notes with what IBM thinks about open source LLMs and AI with what OSI and Mr. Simon Phipps thinks about it So we will keep that kind of as a bug in the back of our minds as we talk to IBM about it Simon is there anything you want to plug?

Since we have you here. Well,

Simon: uh, there's, there's Ogcamp, obviously. Go to og. camp and buy a ticket now. I'm going, I also help organize another conference in Europe called South Tyrol Free Software Conference, which is another conference that you might not have run into. It's, it's now grown into quite a big conference.

There'll be over a thousand people there. It's held in a beautiful city in Northern Italy called Bolzano. Uh, it is the, uh, the second weekend in, uh, November, and I would love anybody who is listening to this is in Europe, can't make it to Manchester to come and meet me in Sno for SFS Con with the website is S-F-S-C-N do it and the conference is conducted in, uh, in English and will be fantastic.

Excellent. And what about you personally? Where can people go to find. Uh, probably the best place is, uh, on, uh, Mastodon where you'll find me as, uh, webmink at meshed. cloud, M E S H E D dot C L O U D. Uh, and I would love to see you, uh, popping up there and saying hi and following me. Um, my, uh, most of my stuff, if you want to find out about me is at a website called webmink.

com. That's, uh, W E B M dot I N K, and that's got all the pointers to everything about me on it. Simon, you're all

Jonathan: about the fun,

Simon: uh,

Jonathan: TLDs.

Simon: Well, you know, they exist, and it seems a crime not to make the most of them.

Jonathan: Not to have fun with

Simon: them. Because you can do good things that are memorable with them, you know?

Uh, so, you know, you can email me if you want to. I'm simon at phipps dot email. Uh, you can have a look at my website. Uh, that's, it's webm. ink. And, uh, I, I host my own Mastodon server at, um, mesh. cloud. So find me in one of those places. Running on a Raspberry Pi. That one is not. That one is actually, uh, running on a slightly more robust hosting server, because it turns out it takes quite a lot of energy.

Jonathan: Yeah. Yep. Uh, it makes sense. All right. Thank you, sir, for being here. Sure. It'll do appreciate it. Um,

Simon: Well, thank you for the invite, you know, have, have me back again sometime.

Jonathan: Oh, for sure. For sure. I've, goodness, we've, we've got to, we've only got so many co hosts and people get tired of, of listening to, to, to Dan and Doc and, and all of that.

Definitely an important part of the crew, man. All right. So if you want to find me, Of course you can. Go to Hackaday, that is the home of Floss Weekly these days, and we sure appreciate that. I've also got the security column that goes live on Hackaday every Friday morning. Keep you up to date with the, uh, the bits and the bytes that are moving in ways they're not supposed to.

Uh, and then we do, of course, have the Untitled Linux Show over at Twit. Dot TV still. And we have a lot of fun there covering, covering the news and a bit of, uh, open source stuff, but with a decidedly Linux twist on it. Uh, so make sure and check that out too. We do appreciate everybody that's here. Those that watch both live and on the download, and we will see you next week on Floss Weekly.

This week Jonathan and Simon chat with Gary Williams about OggCamp! It's the Free Software and Free culture unconference happening soon in Manchester!

- https://ogg.camp

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/

Jonathan: Hey folks, this week Randall joins me and we talk with Michael and Benedict about EMBA. That's the Open Source Firmware Analysis Toolkit that seems to do about everything and just about includes the kitchen sink too. You don't want to miss it, so stay tuned. This is Floss Weekly, Episode 802, recorded Wednesday, September 24th.

EMBA! Layers upon layers of Bash.

Randal: It's time for Floss Weekly, the show about free! Libre, open source software. I am your host, Randall Schwartz. Merlinisunwich. com. We're here each week! The boomers, the shakers, the bigs Wait, what? Wait, wait, Jonathan! I'm the host. You're the co host today. You're the co host today.

Jonathan: Wait a second, this is Floss Weekly and I'm the host, Jonathan Bennett.

I'm so sorry. And Randall Schwartz is back as co host today.

Randal: Oh,

Jonathan: goodness.

Randal: I wake up in the middle of the night sometimes saying that exact phrase because I said it for You know, 13 years worth of shows. So it's I really, really do want to appreciate, appreciate you bringing me back as now possibly an occasional as often as you'll let me co host. Because I do actually, I miss the show.

I've got to say that for everybody out there who's been along loyal friends. I do miss the show. What I, what I don't miss is that I now have. My five hours a week back as Jonathan well knows there's a lot of time. There's a lot of time that goes into this show every week, every, every week. And I'm happy to have most of that back now.

And the two hours a week that I will take the coast here. Much simpler than being the pro producer, show runner Jesus and host. So thank you Jonathan for doing that job and keeping the show going. I appreciate that as well. So, yeah.

Jonathan: Yeah. You know, one of my, one of my favorite things about taking over the show is that I, I get to have Doc Searls and Randall back as part of the, the rotating cadre of co-hosts, and I think that's just, that's just fun that to be able to have you guys back involved with the show.

So today's topic is EMBA and that is, it's a firmware analysis tool, I think mainly targeted at Linux firmware. This is it's, it's really an interesting thing. You know, there's a lot of, there's a lot of OpenWrt, right? Like I'm a fan of OpenWrt, but there's a lot of old versions of OpenWrt that are out there in the wild.

And it's, it's pretty scary sometimes to see like 10 year old firmware still out there shipped on devices and I kind of wonder do they have a module that just spits out This is this release of open wrt beware

Randal: Yeah, and and i'm i'm not terribly in this space So I had to do a bit of research to try to figure out how this is being used But now that you mentioned open wrt there's a recent news item actually it says that tp links Routers are now all considered caustic.

And so, because they were made in China and apparently there's been some spyware that's been traced to TP link. So everything TP link is at risk right now. So

Jonathan: yeah. Yeah, I saw that story. I'm not sure if, if I don't, I'm not sure if the statement was that they are like a compromised and malicious from the factory or that they just have zero days that allowed that allowed them to get popped in that.

I was gonna say, I think we

Randal: have some experts coming up that can answer questions kind of like that. I'm also interested in particular in reading ahead of the show. Is this primarily a white hat tool? Or can it be used as a black hat tool? And what are the implications of that? Having a tool that can do pen testing, vulnerability testing on a common piece of firmware somewhere.

So I think it's probably one of the questions I really want to, I'm curious about.

Jonathan: Well, we do have the experts. We will make sure and ask about that. I do want to mention that Hackaday is what Floss Weekly is a part of Hackaday. Hackaday is a part of SupplyFrame and SupplyFrame is actually owned by Siemens.

And I say that because the EMBA project was at least partially developed originally as a part of Siemens, or there there's at least some shared history there. So we want to make full disclosure. Now we do have Michael and Benedict with us today, and I want to say welcome to both of you.

Max: Hi guys.

Hey guys. Good to have you.

Jonathan: Good to be here. Yeah. So maybe the best place to start here is to ask each of you, how do you fit into the project? Like what are your individual roles in, in this thing?

Max: So from my, from my side, I'm currently primarily or directly with the, with the central Amber project. I'm maintaining the central Amber project, which is, let's say the, the, the scanning backend. I'm, I'm more or less the founder of the whole Ember idea of the firmware analysis idea. And we've started multiple projects from time to time.

One is Ember, the other is Embark, where Benedict is the, is the main maintainer now. So, so at the end, we can, we can split it in this way. If you, if we talk about the main Ember project, then probably with me. And if we are going to, to the, to the let's say management interface, enterprise overview and a collaboration interface, then Benedict is the guy to talk to.

Jonathan: Yeah. And so same question to you, Benedict, how do you fit into the project?

Benedikt: As Mike just said, I'm the main developer responsible for Embark right now. Embark is our enterprise solution, like taking Embark as a backend and then trying to put it into a, Nice server front end. Yeah, oh how people would need it in the business environment.

And That's

Jonathan: yeah. Okay. So probably then a question for mike. I'm, i'm super interested in this idea of packaging it But let's let's start with michael first since you kind of kick the project off and I I do want to know like what What is that tie in like what did the beginning of this look like and what is the tie in with Siemens?

What was like the first problem that you guys wanted to solve?

Max: Yeah, yeah, and so probably we we need to go a little bit in back to the future I think we start we start we started with all with all of this Let's say what was it 10 to 11 years back. I think everyone started with with iot hacking then You There was, was Binwalk Craig Hefner did a lot of nice blog posts about cool IoT hacking, cool exploits.

Everyone tried to show some, some hardware hacking stuff. And the idea was back then at Siemens that we Get away from the, from the typical black box approach on, on testing products, our own products and also third party products, to a more gray box ish penetration testing style with, with the firmware enhanced.

So, with the firmware, you would be able to understand what happened in the background. If you're attacking the device, if you're trying to find vulnerabilities you get a better idea what happens in the background and which ways probably could be successful. And this was in the, in the, in this time also we, we built built the hardware hacking lab to extract the flash storage to get access to the firmware.

Sometimes you're, you're, you're in a lucky position to go just to the vendor website, download the firmware. Sometimes the, the firmware is behind the paywall or something else. And so we started with hardware hacking, identification of UART, JTAG, extracting, flash storage, and all, all the things. And then, then we had the firmware enhanced and we, we were, we were struggling really hard because we, we had not more time to perform our penetration test.

But we had so many ideas and we want to do much more stuff now. And so we needed to start automating everything that, that is possible. So and this was more or less the, the initial idea of Ember. It is more of a, of an automation framework in, in the field of embedded product Linux penetration testing that should help the, originally that should only help the penetration tester.

Yeah, that's, that's more, more or less the, there it was, it started like, I would say 10 to 11 years or, or ago. With, with, with an idea.

Jonathan: Yeah. And, and so it's interesting to see like the number of devices that are out there that just like the firmware is Linux. And we talked, we talked briefly before the show or in the, in the intro about open WRT is that a lot of what you guys see that it's just.

Ancient versions of open WRT that just get shipped on some of these devices.

Max: Yeah, you, you, you definitely see open, open VT everywhere, but let, let's say in, in the IOT environment, you see it everywhere. If you are moving a little bit away from, from iot more to the, to the OT environment where bigger products of in for factories or for for other things are used then we we see open vrt not that often But in the iot world, it's it's quite regular definitely

Jonathan: Yeah, one of the one of the fun discoveries that I have had is a lot of you ubiquity hardware Which you know, that's sort of your your small office home office to medium size I mean they have some they have some impressive stuff like all of the access points That's just open WRT or at least it was last time.

I logged into one of them So it's it's in a lot of places I

Max: think Netgear also has a lot of OpenWrt based systems out there. I

Jonathan: think, I think Netgear was like the OG of OpenWrite. They they're the ones that first did the GPL release that got turned into it. So that's not terribly surprising. All right, let's turn to Benedikt for a minute.

And so you are, you said you're kind of the guy that, that packages the whole, the final thing together and maybe makes it a little more business friendly.

Benedikt: So let's talk, let's talk about that. Sure. So the main thing about Ember is it's built in Bash, right? So we have a combination of scripts in the beginning.

That's what Mike spoke about is we had the idea of combining stuff into something that gets automated. And once we, or let's say Mike, the Ember team was at that point where like it was working and then you had something on the CLI, right? So on the command line interface, you have something to type in and then you get something out of it.

We built an HTML export thing. So you get something that is nice and shiny and clickable. But the issue you're always facing is you have some firmware and you are a team, a team of penetration testers who are essentially find, trying to work on one thing at, as a team. So you have certain, certain things one person looks at and certain things another person looks at.

And if you do what Ember does on every computer, then you're running into, well, time constraints also. So one of the ideas was to basically centralize the whole thing, put it into a server. So make it a business application in that sense. You upload something. Amber do the work and then you get something that everyone can look at without the usual issues of CLI where everyone works on their own.

Jonathan: Yeah. So do you, do you have any idea of like how, how popular it's gotten when, now that you've, now that you've put that package together? Do, do you have any, any idea of like, how many businesses are out there using it, how many researchers make use of it? I think that's

Benedikt: a good question for Mike because he keeps track of those things.

Max: Yeah. Yeah. It, it is quite important to, to, to get a good visibility for, for an open source project at all. And so, so I try to track it a little bit. It also helps for for arguing my, my work on our work on AMBA a little bit better. And during the last two years, we, we have seen that, that AMBA gets accepted in, in a very broad way.

So, there are popping up more and more blog posts out there. So, so people are talking or writing about using AMBA. And we have seen a lot of let's say multiple research papers that have used ember in some way or at least referenced it. And it looks a little bit they like to show where ember fails.

And this is great because we can then improve Ember, we get a better idea on where Ember gets used and how the people are using it and we can improve it, so nearly from every research paper we get new ideas to improve it. And if, if, if we, we are, we are also looking some, sometimes at Twitter and other social networks, and we, we, we have a little bit the feeling as, as I would say most of the penetration tests out there that are doing IOT penetration tests from time to time are at least using Amber besides their manual work.

Just to get an, get an initial overview of the, of possible vulnerabilities to get an idea of where they can dig deeper. As Ember is automating a lot of stuff, you can run, let it run over the weekend and you can start with with a quick start on Monday morning, much better than starting from, from zero if you have let run Ember over the weekend.

You get some, some basic information about the firmware, you get an S Bomb, you get all of the things that you can, can then use for, for improving your manual tasks and yeah, so, so penetration testers are using it researchers are using it, and we also are from time to time in contact with quite big companies that are trying to establish AMBA in, in some way.

Some kind of the security processes one, one big company has established Amber into their IC development process. The next one has established Amber as a quality gate for third party components. So I would say Amber is quite solid established. Hopeful, hopefully we get Many, many more developers that or back, or back hunters so that we can improve Ember in the future much more.

Jonathan: Yeah, yeah, absolutely. Randall, I know you were curious about some things around people using it. You want to, you want to take it and ask those?

Randal: Yeah, and where I'm starting with is, so I understand the basics of pen testing. I don't know how it applies as well to embedded. How much of EMBA is unique to the notion of it being firmware and what kinds of things do you do there?

I know like for traditional pen testing, you're opening sockets, you're trying memory locations, you're trying things. You're trying to recognize known vulnerable libraries, things like that. How different is it at the embedded level and what kinds of things do you do there?

Max: So I think you, we need to differentiate a little bit.

So if we, if we are talking about penetration testing of, of firmware, I typically our projects are typically looking like we have the device. So Also, we can poke around with the device like in a typical penetration test and on the other hand we have the firmware where we can look into firmware to find things that we can verify on the device.

So on the device by itself it's quite classical. So you're looking for interfaces like web interfaces, you're proxying your traffic you try to inject commands. That are executed on the operating system. And on the, on the firmware level, we, we're doing much more static analysis then. So we can, for example think about PHP scripts.

There are, if the web server is, is organized via PHP, then Ember identifies the PHP scripts and can do static code analysis on, on these PHP scripts. And then Ember can point us to interesting areas that we can try to exploit then on the device. So at the end, it's, it's, it's every always the same.

Amber gives you, gives you an idea where something interesting could be, and then you as a, as a, the responsible tester, you're digging deeper, you're analyzing this possible issue, I would say.

Randal: Is it doing things like fuzz testing and like just throwing random data at stuff to see if it breaks? Or is that more, this is more about identification and it requires a human to maybe be trying that kind of stuff?

Max: Yeah. Fa fast testing would be really awesome, . But then then, then such a a test would take Hs. and yeah, Amber. Amber already takes quite a long time and and loves your, your, all, all your course of your, your machine . And so, so we, we are working behind the scenes on different other projects, and one, one is a fa automated faster.

But this is not something that is directly into Ember because it, it it just will take too long to, to bring you the results and I, I think this, this need to be a dedicated project where you can decide which firmware you want to, to fasten after your, your initial firmware analysis process.

Mm hmm.

Randal: And I also, my friends would kill me if I didn't ask this, Why bash and not a more capable script writer?

Max: Bash is the most beautiful language No, no, no, not even close.

Max: just kidding. Wow. Bash is so practical. Think about the beginnings, you're chaining tools together. You're starting at the command line interface, you're chaining tools, and then you're Pasting it into a script.

This, this was the beginning of Ember. And so before we thought about Ember by itself, we had a thousand line bash script. And then we, we, we structured it a little bit and it was just working. We gave it a nice, a nice and shiny modular structure and with more lines of code and it was working.

And Well, everyone said that everything will break if you, if you hit the thousand line area of your bash script and No, no we, we are maintaining it till, till today and we have now tens of thousands of lines, lines of code and, and it works really smooth. You can't, you can't really believe it. If you're, if you're researching in the internet, you will read everywhere that, no, it's not possible.

You can't maintain it. You can't do this. It's possible. It's possible. It's possible.

Benedikt: I have to say for me, it was also the first major question I had when I came into the project. So yeah, because like, I always thought like that there might be an idea to, to switch once you want to modulate and put like, put it into.

Building blocks where you, we were always talking about framework and stuff that we introduced different languages and stuff, but like, I'm, I'm always astonished. Like it's working, like we do some stuff, but

Randal: I would be astonished. It's working. So, okay. That's enough bashing bash. I just wanted to get that in there.

It was like, It's like, okay, you know, I could, I could name another four letter language that would actually be pretty useful, but I'm going to stop that for now. We talked with him just

Jonathan: last week. That's Java, right?

Randal: That's not a scripting language. It is! Go, go and

Jonathan: listen to last week's episode, J Bag, they made Java a scripting language.

Randal: Oh, no, no, just no, no, that's just, that's just, that's just, that's just, that's just That's just wrong. I'm glad I didn't watch last week's show. I'm glad I missed it so far. I will read the transcript now though to see what you're actually talking about, but I don't think I'm gonna like it.

Max: Probably we need to think about rewriting AMBA in, in Java script in English.

Yeah, yeah, yeah, right. Well,

Randal: remember now, JavaScript is not Java, not even close. Those are other ends of the spectrum. Yeah. So, so what, what are your biggest concerns now with the project? What are you working on most intensely? And where do you see this going in the future? Mm hmm.

Max: From, from an AMMO perspective we, we can, we can see that the, the world screams regarding S bombs.

So everyone needs S bomb everyone thinks about S bomb nowadays and we, we, we ha, we already create an S bomb but there is a lot of room for improvement, I would say. And this is, this is, let's say, the, the one, one of the short term goals that which we're currently working on to improve our S Bomb capabilities so that let's say we can, can position EMBAR much better for, for the near future.

Yeah. And.

Jonathan: So I, I'm curious about the the, the answer to that same question, but on the, on the other side, is the other part of the program, EMBARC? Yeah. So I'm curious about that same question, but applied to embark, like what, what is being worked on there and what's coming. So

Benedikt: the fun, the funny thing about Embark is always that it's trying to incorporate everything that we're working on into one front end, let's say.

So if we're talking about the whole. vision we have with Ember, we always talk about from finding the right firmware from getting it to the end to the fuzzer we just talked about, like that might be the end goal. Once we had all the already known vulnerabilities and everything, and then we end up with a fuzzing framework or something, which Mike could talk about if he wanted to, but In the beginning, we would have something that is taking firmware from a device, which we have some projects going on.

Basically two of them, the, the one of them would be to get firmware from a device. And the other one is finding firmware on the internet. If you don't know where to look, basically like scraping and stuff. And the basic idea behind MBug would be to put all of that into one thing.

Benedikt: Oh, that's really cool.

That is basically the end goal. That's also, as you can imagine, a lot of work to integrate

Jonathan: those things. So one of the things that I think Michael mentioned is, is when you, when you give a piece of firmware to EMBA and to the Embark to the server, it really crunches on it. Like you said, you can just, you could fire your CPUs up for the whole weekend.

I'm, I'm curious, what, what are we doing with firmware that's requiring so many CPU cycles?

Benedikt: The thing Mike said about a weekend, yeah, that's, that's the new and the, the new shiny thing that's coming or that's, that's behind the curtain. We usually talked about weeks, months. If we, if we throw data sets of firmware in there to, to find. What's working, what's working with Ember, what is, what is it, is it finding, what is it not finding?

Nowadays it's, it's gotten pretty fast even though, and the thing with Ember is, is it's just multi threading and running modules, so multiple things in parallel, so it's taking basically everything. The, the machine has everything the CPU will give you. RAM wise depends a bit on where in the, in the Ember run it is, how much it will take up, but it really takes up everything you, you, you, you throw at it, but that's also the nice thing about bash.

Jonathan: Yeah. Yeah. But what, what is actually doing that is so CPU intensive, right? Are we just or excuse me, are we just un unzipping firmware and then doing comparisons looking for if there's CVEs out there, or are we actually like trying to run all of these binaries through Ghidra to do decompilation?

Like what, what, what is it that is getting done that's so CPU intensive? Both.

Benedikt: Okay. That's fair. Because you said unzipping is, is one, one part, right? And then decompiling is. Further down the line. Right? So, okay. So those are, we are,

Max: we are doing, doing more or less everything. It's, it starts with, with extraction of the f we, we are doing some, some binary analysis.

So which, which legacy functions are used in such binaries. We are decompiling these binaries. We are then using in Gira. For, for further analysis on the, on the extracted source code, we are using then Semgrep for static analysis. Regarding, regarding the Hot Topic SBOM, we are not just reading the DBN database.

We are also extracting or reverse the SBOM from the, on a binary level. So that if there is no packaging system on, on the device or on the firmware, we, we also get the SBOM out of it. Which most of the other tools do not do, and this is, this is quite, quite intense because we need to analyze every binary, every library and compare every all of this stuff against the quite huge I would say data set of possible version identifiers that we we, we, um.

Extracted manually and we built up manually and at the end we are comparing then these, these versions that we identified with the, with the CVE database, for example, to get an overview of how many, how many let's say known vulnerabilities are available for, for the, the identified. binaries and libraries.

If you think about the firmware, a small firmware of your home router has a few hundred files. If you think about the modern firmware it's getting bigger and bigger. So we have to deal with more we have seen things that they call embedded devices, but it is a full blown Ubuntu distribution out there.

And if you throw this static analysis mechanisms like decompiling every binary, like matching, I would say seven or 800 version identifiers against every binary. This is, this is highly resource intensive and and the good thing is the more CPU cores you have in your machine and boys is automatically using, let's say, or optimizing the next scan on the number of course you have so that.

It, it squeezes out your, your, your machine as much as possible.

Jonathan: Yeah. Yeah. Makes sense. All right. I know something that some vendors are starting to do. I guess they've been doing this for a long time and that is shipping encrypted firmwares. Is that something that there's, there's any yeah. Oh yeah.

We have to, we've had to deal with that. Yeah. What, what is the, what is the approach? Does, does EMBA have any tricks to try to get into those?

Max: I, I would say that we, we are using, we are, we are using on the one hand the, the classical extraction frameworks like BINWALK or UNBLOB. We also have introduced multiple dedicated extraction functionalities for such reasons where, where some some encrypted firmware was documented or the decryption was documented somewhere in the internet and, and we have implemented it directly into EnBAR.

If it's not documented and nothing, no, none of the known extraction frameworks can handle it, then at the end you need to go back to the hardware. You need to go back to identify a debugging interface. He sold a flash and usually, usually my task is then give the box to Benedict and say, Oh, I, I, I need to get access to the firmware, please.

Yeah.

Jonathan: Do you guys

Max: offer

Jonathan: like any, any sort of consulting or work services where someone could say, I need to break into this box. I need to get the firmware off of it. Can I ship it to you and you desolder it and extract the firmware for me? Is that sort of in your wheelhouse?

Max: Yeah, but just company internal.

No, no, no, no, no, no, no, no external consulting. We're just working Siemens Energy internally and testing the stuff that is relevant in this area. But not we are not offering such a service to external.

Jonathan: Sure. And I imagine trying to do that, you would run into all sort of legal questions, right?

About, I don't, I don't actually own this piece of hardware, or I don't have all the rights to this code. And then you go in and you go start decompiling it. You. There, there are, there are questions there, right? Randall, there are questions you run into when doing penetration tests.

Randal: Well, the letters DMCA immediately popped into my head.

So that was definitely going to apply here. Yeah, you don't want to be you don't want to, without the proper chain of authority, you definitely do not want to be doing pen testing at all. It's a, it can lead to. Unfortunate consequences. I'll just put it that

Jonathan: way. Yes, and for those that don't know you can go check out randall's wikipedia page and get a little more details about What happens when you don't have?

All of your I's dotted and your T's crossed and you do a little more penetration than your boss has thought you should have.

Jonathan: For a little while, it

Randal: looked like this.

Jonathan: Yeah. Yeah. Yeah. It's not, it's

Randal: not good.

Max: All right. So what about Not a comfortable position. No, no. No, it's definitely

Randal: not comfortable.

It hurts your, hurts your wrists. Let me tell you, I do know.

Jonathan: So what about virtualization? Is, do you have any sort of a a mechanism to take the, image that you've got now, you know, now that it's taken apart and run it in something like a virtualized machine to be able to do tests on it there?

Max: I feel that the, the original idea from AMBA was always we are, we're talking about firmware.

So this means that we, we need to, or we talk about different architectures. In, in firmware, you, you do not have just the, the, the, the, the X 86 architecture. You have some, some mips where you have arm architecture, you have power pc and all, all of this crazy, crazy architecture. So you, if, if you want to run something from this you always need some something that is called an emulator.

So that. That can, can run code from one architecture in your, in your, let's say, in your analysis machine, like your Kali Linux. So you have, have the guest which is the, let's say the binary from the firmware. Let's say BusyBox binary, you want to run a BusyBox binary for, which was compiled for a MIPS architecture on, on your Kali Linux, which you're using for analyzing the firmware, which is some, some x86 architecture.

And then you need an emulator like QEMU. And Amber is doing this. In, in multiple areas. So for example, we, we, we try to run every binary in something that is called user mode emulation. To, to drop output to the command line interface to collect the output and then to analyze the output if there are some version identifiers in it.

And this is one of the approaches that we are using. And the second one is, is something that is called system emulation. And in system emulation, we are trying to bring up the whole firmware with a, with a prepared Linux kernel. We're trying to boot it up. And to give it with a, with a few tricks, something like a, a, a kickstart so that hopefully the firmware is able to, to, to set up the services set up the, the, the network interface so that we can then, then interact with the firmware.

Jonathan: I, I am, I am kind of floored, actually. I expected the answer to that to be, to be, no, we're not doing any virtualization and you guys already, you're way ahead of me. It seems like a very kitchen sink sort of deal where you've just thrown everything in. It's, it's impressive. It's not even mentioning the

Benedikt: docker by itself.

Yeah, yeah, he, you, you skipped that one, Mike. No security thing with the docker. Yeah,

Max: we, we, we have skipped so many things till now,

Jonathan: but we can

Max: dig,

Jonathan: dig

Max: quite deep.

Jonathan: So maybe, maybe this is kind of what you're talking about there, but in doing things like emulating the firmware and all of that, I would, I would honestly have, have to have the consideration, like, What if there is something malicious baked into that firmware?

Are you giving that malicious code a chance to run on your infrastructure? Like, do you have any safeguards against You know, something nasty inside the firmware. Is it, is it all properly sandboxed? I guess is the way to ask that.

Benedikt: Properly? Wow. That's, that's, that's the good question. Yeah. Is it properly sandboxed?

I mean, it's been an ongoing theme, I think, for, for multiple years that we've tried to safeguard. running code that like, that's like malicious because the doc environment for within Ember needs permissions. So we're still trying to, to really get behind all the ways it could still get out. I think we've, we're doing a pretty decent job, but in the end it's, it's definitely like big disclaimer, do not run something if you know there's something.

In there maliciously targeting your host. I mean, the thing we always do is like we run it within virtual environments. It has a Docker environment. And then the thing actually running is inside a QEMU, but you know.

Jonathan: Layers, layers upon layers, that's something malicious would have to get out of. So I assume, I

Randal: know why it's slow now.

Max: That's the reason we need so many cores for every security layer.

Jonathan: That's, that's not a joke. Goodness. And I assume there's things you're doing inside of there that wouldn't work inside like a rootless pod, man. It's got, it's got to be Docker with root.

Max: Yeah, yeah. We're, we're doing a lot of let's say we're doing some things that we need, where we need root access.

We have thought about Portman now for years, but at the end of this, it is a time issue. We need to test everything. We need to test a lot of use cases, find out what, what is working. In, in this huge code base within Portman, what, what is failing and let's say every, every fail is probably some, at least some little research project on how can we, how important is it for Amber?

Or for, for the testers out there, can, can we just strip it out or can we bypass it somehow? And this, this costs quite a, a lot of time. And so we decided Amber is a research project from this perspective. We, we have multiple layers of, of protection, but at the end at the end, an attacker can analyze, can, can check out the code, can find the bugs and can exploit them if, if he, if he wants, I'm, I'm quite sure if it, it is possible in, in, at least in theory, it is possible to, to exploit it and, um, yeah, if, if you, if you get ephemera from an untrusted source, if you, if I send you ephemera, then you should definitely throw it into Amba,

Yeah.

Randal: It should just look for the string, amba vector or something. Yeah. . Yes. Not run the code if it finds that, oh, if only we're that easy.

Jonathan: Randall, you want to cover some of these that you've got stacked up?

Randal: Yeah, yeah. I was just going through my notes things I'd taken before I did this show. So you know, AI is a big thing. Everybody's saying AI. Is there any idea that maybe you're going to introduce some AI to this? Help fill some of the gaps in, or help extend what you're doing, or maybe try a more brute force approach.

You know, is there any way that large language models or even just neural nets can help you out with this stuff?

Benedikt: Let's say indirectly we had that. Okay. What is indirectly? We had that feature for a long time. I can tell you the exact date because I don't remember, but we have a whole section of modules that we introduced and one specific module was for an open AI connection.

So you're able to put in a API key and then Basically what Ember does is with decompiled code and especially if we've script languages, I think we have this option to ask the AI bot. If there's any vulnerabilities in certain code snippets that are previously identified by another tool.

Jonathan: Oh, interesting.

Benedikt: So there is also like a lot of expansion stuff that's possible with that. You can change questions, whatever, because. If you wanted to do that the results, because I've been testing it a bit, the results are, well, do they really give you more? That's the question, I feel like that's the real question.

Yeah, the false positives there, the false positives there are probably

Randal: pretty high. Is it, is it

Benedikt: telling you anything that other tools can't, like? Yeah. That's

Randal: I'm a little biased because I'm a Google developer expert, but I'd also suggest looking at Gemini's current products because they're really moving far forward and they're recently trained.

Which means that they're much more up to date than any of OpenAI's offerings at this point. So, you might take a look at that. Especially Gemini Pro 1. it. And it's really got some amazing results so far for the stuff I've been throwing at it. So just, just an idea there. Let's see. I also had a couple more questions.

Let's see, what else do I want to ask here? So, is this just about Linux based firmware, or are you planning on expanding it to other operating systems, other firmware types?

Max: Hmm. Is there

Randal: anything else?

Max: So that's, that's, that's, that's, that's the question. No. So, so in, in the area we, we are located. We are, we are using Amber.

We have to deal with a lot of Linux firmware. Nevertheless as I said, Our usual approach is to throw a firmware before of a, of a manual penetration test into AMBA. And AMBA gives us a few days later the, the, the results. We, we also have sometimes some UEFI firmware. We have sometimes some RTOS such a VX works or something like this.

And we want to get the, the maximum out of it. Although we are not the experts in this area. So, we, we, we do not want to, let's say, we, we do not want that Amber is crashing because there is no Linux in it. Then Amber should, should, should give us the information that there's a VX works. And we are doing a lot of or we have a lot of modules.

that are, let's say, file system, system independent, so you can also use it just on a binary blob, for example, to, to extract some key material or to find some, some, some interesting hashes. And then Amber can do this also on, on a, on a, on a non Linux operating system. And additionally, in, in the future.

field of, of UEFI, so, so we, we do not deal a lot with UEFI analysis, but there, there is a company called Binary and they have released an UEFI security analyzer as open source. So we have just put their complete open source scanner included it into Ember. Wrapped it around an ammo module.

And if we, as soon as we detect any UEFI firmware then we fire up this vulnerability scanner now. To, and so we are also able to provide some, some kind of value also non Linux operating systems.

Randal: Cool. Cool. And one last question. I'm gonna throw it back to Jonathan. So results, what's the most unusual thing you've discovered with this or just what are some of the practical outcomes of this that make it worth your time?

Randal: you must have discovered something with this or you this. They're now,

Jonathan: they're now having to do the, the question of, of the things we found. What are we allowed to talk about? . Oh, oh, sorry. I didn't realize that would put you at risk. So, so,

Max: so, so like we, we can say we, we are talking quite generic, so nobody knows what, what we are talking about, so, okay.

I think they, it's, it's very often really interesting if you're, if you're analyzing established security products that are established there for years now and you're, you're analyzing them and you can see that the, the, the components that they are using are, are from, from the age of dinosaurs.

And that they're, that they're not security components and they're not updating the, the, the product anymore. Or the, the base product that they're operating on, on the operating system level. And they're, they're just managing the risk, let's say this way. And this is, this is really interesting because often these are established vendors, established products, and then you can see that not only D Link is using a kernel 2.

6 dot something, also very established security company is doing the same. Wow. Yeah. I think there, what, what was it that there was, I cannot remember exactly, there was one one, one company or one product. That was destroyed somewhere in the internet. I don't remember it now, but, but, but,

Randal: but if I could summarize what you're saying is that some people who should know better don't always demonstrate that they do.

Yes. And, and with, with,

Max: with automated firmware analysis you get a quite good overview without any manual work. And then, you know, that's usually the, the, the thing where we are using Ember a lot. Ember is doing the automated work and we can see, okay, oh my God, this product is looking really fishy.

So we, we, we have 10, 10, 10 products. And then we know, okay, we start with. This one, because this looks fishy.

Randal: So it's like, when I'm looking at a piece of code that is operating on a live website, that's written in PHP and has a very obvious SQL injection attack. And I go, how long has this code been in here and this company in particular should know better to run PHP code.

That looks like this. Y'all. It's, it's, it's, it's a sad experience. It requires some warning on my part, and then I move on and go, well, I'll probably write code exactly like that someday. Yeah.

Max: And, and, and usually these are the windows that are shipping encrypted firmware updates so that nobody can see the, the, the PHP code.

It's encrypted.

Randal: We don't have to care about it. They don't want you to see how bad it is, that's why. They're just shipping junk under a golden label. Yeah,

Jonathan: it's sad how much that happens. Alright, so, I've got to ask, why open source? Right, like you guys apparently use this at Siemens or Siemens Energy. It's it's used for it sounds like for a lot of internal use What was the what was the conversation like saying?

Hey, we should open source this and release it to the world

Benedikt: I mean it started as a project where you're like, okay, I have an issue and there's no tool for it I really feel like that's a classic open source thing, right? You you're right. You're starting free time. You you start with a An idea, and then you write something that you actually need for your work and then you're like, okay, I feel like since there's nothing out there, why not just open source it, like put it out there.

And that's, that's basically what happened with Emma making it like a security tool for everyone. That's also a big part of the cyber security idea. I feel like that's if you write a security tool, you put it where everyone can use it.

Jonathan: I like it. I know, I know some corporations, they, they get real antsy about releasing internal tools as open source.

Was EMBA started was it started in, in your spare time or was it sort of kind of official? It's like a company project.

Max: I would say combination. So we we we started during penetration test and then every every you're fascinated you want to do everything and then You're running into time constraints and then you you can't sleep.

So you start coding in the night and Is it no work time? No, it's not work time because you have already Your, your, your, your hours together, so it's free time. So, so pro probably most of the guys out or the open source developers out there can ha have a little bit the same story. Yes, they're fascinated.

So where, where at the beginning you can say where is company time, where's free time and everything swims together. You want to solve the problems and yeah, I think it's, it's, it's a mixture of both. We, we have the time in the company, but we are, we are also spending quite a decent amount of time during our, our free time.

Jonathan: Yes. I know that feeling waking up at two in the morning. I know what's wrong. Then it's like, do I try to put myself back to sleep or do I go in there and fix it?

Max: And then you need to go up because you can't sleep anymore and you need to fix it. And then you realize, Oh I fixed this issue, but there's the next one.

So I don't need to go to bed anymore.

Randal: I think what's worse than either of those is waking up, realizing you have the solution to a problem and not writing it down and forget. That's really bad.

Max: That's true. Yeah.

Randal: I, I've done that. That's why I know it's not a fun thing. Yeah. I try to get at least something written down when I have an idea in the middle of the night.

So I at least have it for the next day.

Jonathan: Are there any, are there any CVEs out there that have a special thank you to EMBA? Do you have like a list of you know, this one and this one and this one were found because people were using EMBA?

Max: So, so We have an internal list of our CBEs that were fixed that we, we reported to other vendors and that were fixed.

Mm-Hmm. , but there's nothing out there in the, in the public. No. Okay.

Jonathan: That would be, that would actually be an interesting project to just have a repository. Now, now I understand like some of the things you find that you just can't, right? Like I get that there are things that will get discovered internally reported internally and may never be assigned a CVE number.

Like that's fine. That's just how the world works. But it would be very interesting to have a repository where you say, Hey, security researchers, if you find something, if you find a CVE through EMBA. Shoot us a note here and they just have like a high score list somewhere on the Ember website. I think that would be a lot of fun.

Oh yeah.

Max: So, so, so we, we, we have a collection of all of the papers and blog posts and mentioning of Ember. So If someone sends us the CVEs that they have found with the help of Amber, then they will definitely get a nice and shiny place there. Yeah.

Max: So, so we, we are prepared for these reports.

Awesome.

Jonathan: So one of the things, so I, I write about security and one of the things that I try to encourage people like just that are interested in it is the barrier to entry for finding CVEs for finding security problems and getting them fixed. Okay. It's actually a lot lower than most people think it is, right?

Like it's, I, I just, now I didn't get assigned to CVE, but I got paid a bug bounty for literally just running a trace route and then running a port scan back when I had Starlink Internet, and they had set, they had set a server up and it. did not, it did not have a proper firewall if you were coming from inside the Starlink ISP.

And I got paid several thousand dollars for reporting that. And this is one of the things that I, I really like to encourage people on, is like, go looking for things, and if something seems weird. So all of that said, what does the process look like for setting up EMBA and EMBARQ? How difficult is it to get started and then say, feed the latest firmware for your, from your own home router into it?

There's obviously, there's going to be problems in home router software. How difficult is it to get started and start finding them?

Benedikt: I would say very easy, but maybe I'm biased here. Of course the easiest way is for, for us just tell you, okay, there's a Kali ISO run a VM on your laptop and then run it.

Just do the git pull git clone and to an installer which is very easy takes a bit of I don't know a few minutes for sure to download and install. The barrier of entry is basically Now I would say because you can also do it on bare metal You can install kali on basically anything I would say the only barrier I would see is Minimum system requirements because Ember is, as we talked about, a bit of beast.

So it has some minimum requirements where you, you can't, like, it won't run nicely below that.

Jonathan: Yeah. So, and so is, is Cali kind of the preferred place to set it up and start using it?

Benedikt: Well for Embar for sure. I feel like Mike and I, we always are on Cali. Mm-Hmm. Em, embark is designed for Ubuntu. Okay. Because if you, if you're talking about Linux environments and servers most people install Ubuntu, right? So that's, that's what, what is it? It's intended for. So EMBA would work on two yeah, well two Ubuntu versions and Ali, the current Ali.

So there's options.

Jonathan: Alright. We are I just saw at the time we are rapidly running out of time and I, I wanna make sure and ask about community. Like, so what, what is the, what is the community size? Like, do you guys get contributions? Have you had people from? outside of your company and outside of the project come by and say, Hey, I thought it would be cool if EMBA could do this.

Here's, here's the patch to make it happen. Or, you know, bug reports. Is that something that is happening or is it, is it kind of not public enough yet?

Max: So, so I think, I think we're getting more and more bug reports during the, let's say during the last year, we are getting more and more insights on how people are using EMBA.

How people are. Talking and writing about it. People are also reporting their bugs and their wishes. We, we had a, a, a few contributors that there, which are directly fix have started fixing the bugs but really just a few. So the, the the, the, the community is growing, but let's say the community that is interested in also helping is growing very slowly.

But the, the more the community is growing I'm, I'm sure that then also the, the, the helping hands will, will come more and more. Sure.

Jonathan: So if somebody wants to learn more about EMBA or EMBARQ, where do they go to learn more? And then if they want to talk to you guys, where is the best place to do that?

Right

Randal: here.

Jonathan: So like, what's, what's the, what's the website? What's the GitHub URL? Is there a Discord server? That sort of thing.

Benedikt: No Discord yet, no. Not that I'm aware of. That's something we should talk about, Mike. Absolutely. Thinking about that, yeah.

Max: cu Currently the easiest way is going, going to the GitHub project. If, if you have ideas, open an issue, open a discussion.

If you, or if you're writing about Amber or showing Amber or something around Amber somewhere, drop us a note somewhere at GitHub or GI or X or LinkedIn. Mastodon the usual social networks. Mm-Hmm. . We, we have there an, an dedicated Ember account, which is called Secure Firmware. And we, we are happy to, to, to publish also your, your papers that I'm mentioning or your talks that I'm mentioning Ember there.

And If, if we need to talk in, in person, like we did it and drop us a note somewhere over there and we find a way to, to get in contact. Yeah.

Benedikt: And I think, Mike, you're at the next, no, conference, the big one in Oh, yeah, yeah,

Max: we, we, we have plans going to, to Black Hat Middle East now. Ah. I think in the end of November.

Okay. So if someone is there, then drop, again, drop us a note and we, we have there a, a, a demonstration of EMBA at Arsenal, and then just come to our booth and we can, we can talk about EMBA and Fermi analysis and all the rest of the world.

Jonathan: Yeah, very cool. All right. We are out of time i've got to ask each of you the final two questions.

It is a requirement. We get in trouble if we don't do it we'll start with michael. What's your favorite text editor and scripting language?

Max: So so scripting language is is definitely bash. I I've now written 30 000 lines of coding bash. So it it needs to be my favorite scripting language. Yeah, and I always exited WIM after working on AMBA, so this is my favorite text editor.

I'm not a master of WIM, but I can exit it. You know how to get

Jonathan: out. It's fine for me.

Max: Yes. Save and exit, not just exit. Yeah,

Randal: hopefully. All right. If you're not saving it, it starts sticking.

Benedikt: All right. And Benedikt, same two questions. Yeah. For me, it's somewhere between Python and Bash. More fluent in Python though, I should say that.

And editor wise, I would say, yeah, not, not the biggest fan of him. I learned it. Normally I stick with Nano. That's fair.

Jonathan: That's fair. Alright. Thank you guys for being here. I wish we had more time. We'll have to bring you back maybe after, maybe after Blackhat. We'll bring you guys back on and talk about what's changed and get in all the questions we didn't get to today.

But thank you both so much. Thank you for having

Max: us. Have a good day.

Jonathan: Yup. Yup.

Max: And

Jonathan: bye bye.

Max: See

Jonathan: you. Alright. What do you think, Randall? You gonna go dig the firmware out of your router now and take a look and see if you can find some fresh CVEs?

Randal: Well, it's not my router, which is why I'm on Wi Fi. So It's I live in the basement of a, of a two main story house and they have the router upstairs.

And so that's why I don't have, which is why we were in troubles before the show. Yeah. Getting me on the screen of why I dropped it. After we're done taping, I've got some advice for you about how to set up the next show so that it's a little better bandwidth wise. So this was interesting in that I haven't spent a lot of time thinking about the firmware that's in all the devices that are now being used in my life.

And now it makes me more scared. Great. But at least there's some sort of diagnostic tool that at least somebody can run against some release of maybe something that I will use or eventually use or be kept from using because they found bad stuff in it. I like your open source question. Cause it's like that, unless they're getting a lot of community Contributions.

This isn't, this doesn't really pay off as open source. Unless most of this stuff was already open source and they're just bringing it together and kind of from a potluck perspective where everybody's bringing food and everybody takes food. Home, it sort of makes sense for it to be open source. So I like, I like it from that perspective.

It was a little out of my wheelhouse, so I didn't get a lot of questions. So

Jonathan: Randall, what you need to do, if you decide to start doing that, start working with this at all, is write yourself a custom module to see is any of your code in the firmware and just like make some sort of trumpet fanfare that plays automatically when it finds, you know, a Swartchian transform or whatever that, that is actually in there.

All right.

Randal: Right. Well, it's like, you know, the usual editor question, you know, for years, I said Emacs to that because there's a part of my code in every copy of GNU Emacs. So that kind of thing. And, and Yeah, Schwarzschild transforms show up everywhere. It's kind of crazy how that how that one's gone kind of spiraling out.

So, yeah yeah, cool. No, I was, it was a, it was a good show. The guests were knowledgeable and the project is worthwhile and in progress. Yep, absolutely. All right. Do you have anything you want to plug? Ah, yes. So so this is now a new addition to my semi regular schedule as often as Jonathan will let me back.

And, and I've opened for the day. Cause so typically my, my Tuesdays are pretty free. So I think it'll probably work out for at least as often as Jonathan's willing to put up with me. But every Wednesday I tape a live stream show as well. On Dart and Floss, which are my, not Dart and Floss, Dart and Flutter.

Ah, too many FL words. Dart and Flutter. I am a Google developer expert in the Dart and Flutter arena. I'm all in on Dart and Flutter. So, yes, although I was kind of hinting at Perl earlier in the show, I really, I personally haven't written more than 10 lines of Perl code probably in the last year. And but I've written thousands of lines of Dart code and Flutter code and, and things like that.

And so every Wednesday we do what we call Hump Day Q& A, Ask Me Anything, where we get a few experts together. And for some reason they let me on there. And I have no idea why. And we take live questions over YouTube. So if you go to YouTube and look for Flutter community and Flutter is anything vaguely interesting to you, please check that show out.

We really enjoy the live questions. We get some good stuff doing, we also do some live coding. So it's been a lot of fun doing that week for week for the last, I think, two, three years. So it's almost been the same burden that I used to have weekly, but now delivering it into the dart and flutter arena and the problem with the, not the problem, but the, one of the things to know about the hump day Q and a is it runs two or three or four hours long.

So. At about the third hour, I'm telling Simon, who's now madly typing in, trying to solve that last problem in his live coding. I say, Hey, we're starting the fourth hour there, Simon. And he'll finally go, Oh, I should probably wrap this up then. Yeah. Why don't you? Why don't you? We're down to 22 people watching, so we should probably stop.

Oh, that's great. Fun show. It's a great show. I love it. I'm, I look forward to it every week. I'm just making notes now about what we're trying to do tomorrow. But check that out. That's probably the biggest place to see me. I also have a dart and flutter YouTube channel, which I try to contribute to you on a regular basis.

So. You want to check that out. Just, just Google Randall Schwartz, Dart and Flutter. You'll find all sorts of good stuff about me and my new career.

Jonathan: Yeah. Excellent. Thank you, sir, for being here. It is good to have you back and we will make sure. We'll make sure and get Randall in the rotating cadre of co hosts.

So we'll see him again here in a few weeks and look forward to that. If you want to find my stuff, of course, Hackaday. We appreciate them being the new, the new home of Floss Weekly. You're not really new anymore. I've been here for almost a year. I've also got the security column that goes live every Friday morning and then still over on twit We've got the untitled Linux show, which is a lot of fun And if you're into Linux, which I imagine most of our listeners are you should go and check that out, too We appreciate everybody being here those that catch us live and on the download and we will see you next week on Floss Weekly

This week Jonathan and Randal chat with Michael and Benedikt about Emba, the firmware analysis tool that packs in a bunch of features and tools. It's got virtualization tricks, binary version detection and even more!

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/

Jonathan: Hey folks, this week Jeff joins me and we talk with Max Anderson about JBang. It's a little utility to make Java easier to use and run it as a scripting language if you really want to. It's a lot of fun, you don't want to miss it, so stay tuned. This is Floss Weekly, episode 801, recorded Wednesday, September 17th.

It's not your parents Java anymore.

It's time for Floss Weekly. That's the show about free Libre and open source software. I'm your host, Jonathan Bennett. And today, it's going to be fun. It's going to be interesting. It's going to be Java. Which That's okay. We mostly like Java here. It is not just me. Of course I have, I have Mr. Jeff Massey, the one, the only Mr.

The, the other, Mr. Lennox here with us to talk about J Bang, which is an interesting project all about, from what I could tell, it's using Java as a system scripting language, which is sort of interesting. What, what do you know about this, Jeff?

Jeff: Not a lot. When you, when you first got a hold of me, I thought for a moment you were talking about JavaScript.

Well, it sort of

Jonathan: is. It's Java space script.

Jeff: Yes, not one word. So that's where, I was a little confused at first. So I'm, I, I'm not a real I don't have a lot of experience in Java. So very, very little, but I'm interested to hear about this and kind of the direction they're taking it.

Jonathan: Yeah. Now we talked before the show, it's like, well, Couldn't you just do this with like an alias to the Java binary?

And so, you know, JBang would just then be an alias to Java and that's the show. Thanks for coming, everybody. We'll see you next week. Apparently there's something a little more to it than that. It's a little more complicated. There's more wrinkles, there's more hair on that problem. So, looking forward to learning.

The level's always in the details. Yeah, always, always. Looking forward to learning about that. Let's not let's not take any more time to bring him on. We have Max Anderson is the guest today, the, I believe, the creator of J Bang. Welcome, sir! Welcome. Well, thanks for having me. Yeah. Now, creator Jbe, right?

You're,

Max: you're the man. Yes. I created it after being a year away on a sabbatical, not doing anything not doing anything, work for latest, so to speak. Right. And yeah, and I, I'm happy to be here and, and be in a place where everyone loves Java and wants more Java and all that

Jonathan: kind

Max: of

Jonathan: thing. Java was I've, I've told this on the show before, but John Java was one of my early programming languages.

And so some of the like difficulties and learning how to program and like, what do you mean a pointer error? And why I didn't even think Java had pointers. Why is the log telling me about, so some of that, like, you know, I just, I have this sort of deep seated annoyance with Java because I was programming it when I didn't know what I was doing.

Max: Yes, I see that repeatedly again. People have, well, most people have learned or touched Java, but they mainly have touched it at a time either in their career where they were not, like, that was not a good, it was not a good learning language in the early stages. But it got super popular because it could run anywhere, right?

It could, you could run both on Linux and Windows and eventually Mac and that kind of thing. And phones and, I mean, for a while there were DVD players and everywhere, yeah.

Jeff: Everywhere.

Max: Yeah, it was, whatever devices were there, right? So so I worked in Java for, I've done professional open source 20 plus years.

Mm hmm. I've my day started at Hibernate and, and, and Persistence Solution, that kind of thing. And then I started doing tooling. And then I, I had, um, what's it called? Well, 10 years, 15 years of work and came back. Well, then when containers came around, Java had a problem because it's too heavy and, and, and, and and I was tasked on doing some other tooling in go land and JavaScript.

And I got to touch on that. But then I, I took a break for a year. And I promised myself I'm not going to touch any programming for the least three or four months. And on the first day I break my ankle and have to be not moving for another days. I decided not to touch Java, but go into Python instead.

I knew Python from like 20 years old. And I had fun with that. And then when I came back to actually work on a product called Quarkers, which can make Java work with containers, I was like being super or realizing how complicated Java is like in the minds of people. But when you refresh yourself on what's actually happening in the last X number of years, You realize, hey, there's no reason why it should be hard to use Java.

And I then, as a way to update my knowledge about Java, sat down and said, hey, let me try and make like, there's this the product Quarkus was using in their release engineering, release scripts, they're using Kscript, which is, it's Kotlin scripted. And Kotlin is considered a more lightweight language, but I was like, why are we required to install Kotlin on top of this Java when the script is just doing some file automation stuff, right?

So I took the DSK script head and applied it to Java and that's where the scripting part comes from in JBang. And then I realized, hey, I want to have, The same experience I want to be able to, because the reason why I like Java is all the tooling around it, like the debuggers, the IDE, the content assist, the refactoring.

But the problem was that when you try and do that in a scripting way with JBang, All that tooling falls apart. And then it becomes at the equal terms as Python and Ruby or Node or whatever. And then Java doesn't hold up. Like, then those languages are nicer. But I was like, no, no, no, like we have a massive, like Java has a massive ecosystem, like the whole Maven central auto artifact, you can download and use and do whatever you want.

And and I said, Hey, let's, let's do this. And then I the, the thing was in Java, I forgot like 10 or 11, the add support for running. without compiling it. But the problem was that to, and you could even use it as a script, you know, like have a what's it called? She bang in, in the top, like what, what pound slash slash dash run something.

but any IDE you do that in will then see that as a syntech error because that command is not part of the job eco system. So no, IDE could work.

Jeff: Mm-Hmm, . And

Max: I was like, oh no, we need to find a way. So that's when I realized there was a trick in go. I think I saw it first, that if you add two, four slices bash and seashell and a few other shells, not fish, shell will treat that as shell commands.

So you can then run it and pipe in the file and Java will just treat it as a command sorry, a comment. And that means you can run any Java file and it'll work in the ID. You can come to this, it works. And that's like, Hey, great. Let me do that with the Java eight, because at the time I was using Java eight, but you couldn't so fast forward, I made it.

So there's a J bank command that you can call that can run Java source file. And. Compile it and then run it. And the advantage over the default job is a, it will cast the result. So therefore it doesn't have to do the compilers already there

Jeff: and

Max: only do the compiler into the file changes. And then the, the one that's the kicker is it can get dependencies that it's just in the file.

So at the top of the file, you can add like slash that steps and then the coordinate for artifact. So and that's, once you have that suddenly you can do things and it works in ID like in the early days I was generating files for ID, but now a few days later we have support in Eclipse.

Intel J and VS code, especially VS code. So now my favorite text editor is, is, is VS code with a J bang plugin in it because I can just be writing in my, my own language. And then on top of that, we started going low. Oh, Because that's the other big thing is, oh, you need to start writing code without having to download an IDE, et cetera.

You need to get Java, but which Java version are you going to run? And so then I added to JBang that it could download, or Taco, who I'm doing it with, added support for downloading. Any, the, the, the version of Java you're there. So now we had a full setup where you install giving which is a one liner install, and then you just create a Java file and you can add dependencies and you can build it.

And you can even, there's even a JBank edit that will actually, if you use your own IDE or download one for you and it's configured. And once we had all those things in place, we suddenly had an ecosystem, a whole setup that anyone can run on any of the three major platforms out there. And then suddenly I realized, hey, any student, any, any experiment I want to do, I can do in seconds compared to, I'll also set up as it was before.

Jonathan: It sounds like you're technically making polyglot files here that are interpreted one way by bash and interpreted another way by the IDE and by Java itself.

Max: That is true. And, and the fun part it's also a poly, Poly, poly, polyOS thing, because the first slash is bash recognizing, Hey, this is a bash command in the start.

The second slash is the Java comment. So it works. But the fun thing is that works on Windows, sorry, Linux and Mac. But if you do it on Windows. It gets interpreted as, I forgot what it is, but it's a UNC

Jeff: path,

Max: so it fails. But if you have a third one, everything's fine. It works in all three. So it's, it's, it's a, it's not a feat, it's a bug in all three that makes it work.

But mind you, you don't need that line. That is literally just for the feature of being able to do Like run the Java file directly to be able to do a dot slash on it. Right. Yeah. Yes. A lot of run the so, so that's, that's the, yeah.

Jeff: Sorry. I was going to say, you know, and I think you, you kind of touched on this, but you know, why did, why did you choose Java?

Was it strictly just because of the infrastructure, the existing infrastructure versus not going, Hey, maybe I want to try to work on, you know, Python or Rust or some other language, you know, So

Max: that was the thing. It's like my professional work life has been in the Java world. And I, I am proficient in the others, but I always, I was before I did my sabbatical, I was like, why doesn't people do that?

Why don't they just use Java more? Like it's so easy to use. Right. But I realized that my 15 years of working, I. I got immune to, oh, you have to find a version of a dedicated download. Oh, you have to find IDE to download. You have to find X, Y, Z. Learn a Maven tool or Gradle tool. And I hadn't realized. It was just everyone in my, like, bubble knew that it's like, like, and people found what's that called?

Like when, when, when you're a group of people who've gone through the same pain and now you're all kind of good and you don't see all the problems, right? And you feel like privileged to you, you, you've got here and then go like, Hey, why is this student that never used program before surprised to, to, to, to this and the, so one of the things you can do with, with well, so, so main thing is.

I like Java. Like, I'm, it's what I'm, the language I, I, I like to do. I also like Python. I like JavaScript. I'm not a fan of, but there's a lot of languages I like, but the whole ecosystem of Java, I just, the whole tooling, the compile, like there's a lot of stuff we can do that none of the others can, can, can do.

But the, the, the So that's why I was like, I was like, when I went on sabbatical, I was like, how hard can this be? Why is it? Is it so hard when I came back because then I had forgotten all these things and I was just Realizing how many steps I have to do so, coincidentally also at the time my son was about Seven or eight six seven.

So he got into minecraft at that time And mindstorms and lego stuff and those two actually uses java in in a setup and i'm like, okay Let me go and show programming with Java to my kid. And I heard about all these kids and, and, and, and teenagers using writing plugins for Java. And I thought, then it can't be hard.

Then there must be a guide in Minecraft land that is simple to get started. And I was surprised that people are even doing minecraft plugins because any product founder had like five or six pages of setting up java To get started. And I realized okay, so they they're going through all this pain Just because, hey, all of their friends are liking Minecraft.

So therefore, that's why they get there. But I was just like, why? And then I realized with the JVang stuff I had, I could literally write, I could, it was made, I made it trivial to write Minecraft plugins in, in, in JVang. Because now it's just a single file and you just have a dependency on the Minecraft whatever Minecraft plugins that we use.

And off you go. Stuff like Again, people don't, well, you guys, you don't know because you, you're not a Java head, so what do you call them? But one of the things I always find insane, like when you do a debug, a Java product. It is literally like a 80 characters. You have to type in of Java does agent connect server equals yes to whatever port.

And I was like, why it's the same. It's it's, it was fine when we 20 years ago, add was a feature. We didn't know how it should look like, but it's just stayed around. And in day bang, that is. D debug and it behind the scenes just do the, the, the, that connection string. And I just chipped along and anything I could find that was like this com, like unnecessary complexity that has organic groan, I just kind of chipped away.

And because I just use a standard Java tooling, it works on anything like, so it it runs on Java eight and artworks. So I could even make it work on Java six and older. I just, no one ever asked for it. So I didn't want to incur the pain, but technically it could. And yeah, no, no. So, so, so Java was just because, you know, that's the thing I like.

I might be weird, but, and there's also a whole enterprise out there that uses Java. And I was tired of hearing this. Oh, when you're using IOT, you have to use Rust or, or Python or, oh, you have, if you do front end something you have to use JavaScript. Oh, and because everyone now do use JavaScript front end, we have to use JavaScript at the backend too.

I have nothing against it, but it's just this like, Hey, like Java can actually do these things too. So don't, don't fall in. I have the same thing with the whole AI movement that everyone thinks, Oh, to use AI, you have to use Python. And I'm like, Hey so this is one, my gimmicky you can actually run J bank from Python now.

So if you have a Jupiter, if you have a Jupiter notebook somewhere Jupiter notebook environment you can do pip install J bank and it will actually, you don't have to do anything. It will set up Java in that environment. And now you can, you can use Java from any. Of those free services like cloud notebooks and others and get access dependencies.

And people don't believe me when I say so, but it is actually doable. So now I claim that Java is the most portable environment anywhere. And with JBang, it's the, it's the easiest thing to set up. Cause I don't know if you actually tried, have you tried to actually set up a Python environment on a Windows machine?

Jonathan: No. Oh, no. That is, that is horrible.

Max: Yeah, because this is the thing like just like the java guys are like in a mindset Hey, you just do these seven steps and you're fine python and node. js is is default installed on mac and linux But as a whole ecosystem windows, which is you know, i'm sad to say but it's the most installed desktop operating system out there Yeah, we're running python is not easy Funnily enough, JBang is one line and you have a full Java environment available to you and it just works.

That's actually really cool. I did think it was funny

Jeff: when you said Java was really easy because I'm like, I don't know if I've heard anybody utter that phrase before. You know, I've always heard there's a learning curve, but so, you know, I totally get who you're surrounded by and what you're in and, you know, yeah.

So, but officially. So I, so I can make sure I have this down. What versions of Java are supported? I know you said you weren't going backwards from. So,

Max: It JPEG itself is compiled and with Java eight. So it can run on any Java eight, um, VM and upwards.

Jeff: Okay.

Max: So, because what J Bang does is it like, it's trivially, it's the simplest product I ever made.

It literally, it's just a little J, it's a Java, it's a small Java app. And it, it just takes input and figures out, Oh, is this a Java file? Oh, I need compile it first. And then I create a Java C command line. And then I. I, I build the classes and then I jar it up and have a jar and then I run the jar. And if it's a, if it's a jar file, I just run the jar.

And if it's a Maven coordinate. I go fetch the Maven dependency. If it's a Kotlin file, I, I run the, the Kotlin compiler. If it's groovy, I do the crude compiler. And in that sense, J bank actually goes beyond just Java, but any JVM based language is, is in theory possible to, to, to in that way run. And because WK team generally are good at having backwards compatible command lines or four compatible ones.

It, it has been reliably working on any version has come out in the last four years. And the cool thing is J Bang knows which version of Java the user is asking for. So therefore, if for some reason, let's say Java 25 is going to break something, I can adjust the, the, the, the generation of the command line stuff.

And then it would just kind of work. So that, that's the way that this, this magically works.

Jeff: Oh, that makes it nice then that, so, okay. I I've got my Java version eight plus whatever. Now to make this a little easier, these complexity reductions that you talk about, are they. Have they made their way upstream?

I mean, are you making life easier for me?

Max: I'm actually, so I work in Red Hat and my main job is actually to work with some of the compiler guys and OpenDK team. And other things and I've been pointing them to some of this stuff, but don't get K team is, is a very like, like it's a really complicated machine but it's like really, really efficient.

Like it's a really, like it's, it's engineered really, really well, but they also use everywhere. Right. So it's kind of like, I think you had an episode about the core was it the core lips, the core tool about how backwards compatible that I think has to be open your case is in that ballpark, but they also want to tweak things up, but they are so they're very conservative, right?

So even if I propose something now, it's going to take. Literally years before it's there. So I haven't done a lot of it, but one thing I've Not sure if it was coincidentally or not But a year after I made the big splash with jbang and and created it And showed, Hey, you can run J bang. And another thing I can also run JCL, right?

So JCL is, is a shell is like this tool in Java where you just run. It's like a, what's called rebel, like one line at a time. I can run those scripts too. And I showed that, Hey, it's you. The only thing you need to have being run, it's just a single file. And. You didn't even have to have a class in around like the whole like public class static void main thing you, you, you don't have to, to, to do.

And then a year or two after to dedicate team has now come out with that, I think it's Java 22. There's a preview support for what I call a naked and naked main. So that's you, the simplest Java thing you do, you can do today. Now is. Void main system up from like, there's no, there's no arcs. There's no class.

There's no imports. They, they actually, that's the one thing that, that, well, it's a thing that they started to, to, to put in. And some of the flags I've been doing like the debug one I've proposed at least to the internal Red Hat team. And I'm actually meeting them this week where I'm now here in Zurich.

And I'm, I'm, I'm gonna. Talk to 'em. So, but again, , this, this, this is so hard to dis do because people are so, like, one thing is that they're used to it, but also just there's so many infrastructure that's Mm-Hmm. , like, if you start, it's, I have the, the advantage that this is not in Java, so therefore I can, I, I can, I can change things a bit.

But I, I do, I, I at least. Find priority. And I think I might have accelerated some of those decisions to simplify Java. And yeah, so I, yeah, I'm trying, but it's, it's going to take a long time. When

Jonathan: you, when you measure, when you measure your like install base in the. Billions with a B you want to be very careful about making changes that could break things.

Yes So you mentioned you you mentioned naked mains i'm curious with j bang do you do you support implied mains? Or when I go to write a j bang script, do I still have to define a main? so so,

Max: So this, so yes you do. And I'll explain what, but, but no, you don't. So there's, so one of the key things I wanted to, was to make sure that the IDEs keep working.

So I could technically, I could make JBang go look in the sources and see, Oh, this is just a naked main. Let me. Behind the scenes generate a a, a, a wrapper around it and, and behind the scenes do something. But if I do that, that job file would not work in any id 'cause none of the IDs currently supports that notion.

Right. So I did not do that. But what I did do, do what I did do is the JS shell support. So JS Shell is this tool that's been in Java since Java nine, I think. Where you can literally just run any kind of Java, like it's, it's a line based execution. And, but the weird, well, I'm not, I'm not saying weird, but a limitation of JShell is, JShell doesn't, are not able to take arguments.

It doesn't handle dependencies. And that's because JCL was built for tinkering. Like, it was like, hey, let me play around with something. Not for use as a main execution engine. But I realized, hey, with JBang, I have a way to run these. So they are still JCL scripts. But I actually handle the command line arguments and parse things in.

And then, so yes, you can do mainless with J Bang back to nine. It is. But it comes with the price that JSON comes with it, which is, it's a slower execution. It's not as fast as everything else. So, so yeah, so the answer is yes and no. So

Jonathan: this ties into something else I was going to ask about are you doing compiling down to byte code?

Like with Python, oftentimes when you run a script, you'll end up with a pyc file hanging around and it does that to speed up compilation. So it sounds like sometimes you compile down to byte code and sometimes you don't.

Max: No, as a, what's it called, conceptually it's the same thing I do. Right. So Python adds the, has these Pisces files.

It says, Hey, this is a compile time. And if, if the, if the file, the timestamp matches the file we will we will use that the Pisces and I do similar thing here. I just, I have a, there's a medical folder and your home directory called dot J bang, where I have a cache. And in there, there's a, there's a, there's traces of what you've been doing.

Right. And and that's the thing. So this is the, the, the, the, the, once people, people have a hard time grokking that it's that easy. But for example the main list, the main list, sorry, a naked main is available in Java 22 and people go like, okay, I can't use that. That takes too long because if you use the normal install, you be complicated.

But with JBang, it's just JBang Java 22. And all this stuff will just be, I'll download a JDK and it'll just run for you. And the same thing is what I do with the, the compilers, the bytecode stuff. I will generate bytecode well, compiler classes. But I'm using the standard. Java C tools, right? So I'm not, there's nothing J Bang doesn't do anything that Java itself can't do.

Right. So, so, so it, I'm very confident that it will be portable for a very long time. As long as the OpenIDK team stays portable, J Bang will,

Jonathan: will,

Max: will too.

Jonathan: What, what about, we talked a little bit about Java versions. What happens if somebody says, here's my J Bang script and it calls for Java. 11 and Java 11 is not installed anywhere on the system.

Do you, do you deal with that or do we just fail?

Max: Yeah, well, yeah. So the, the, Well, if, if you run J when you install J bank, there's no job, no job needed. You can use any package manager and stuff. So basic J bank has nothing. It doesn't even have Java, right? So just have a jar, but it also has a script. So a best script or PowerShell scripts, which is windows.

And that thing will go look for Java and it has a default thing go like, Hey, I'll use the default DDK. That is on your system in your path to run to run JVM. But if that's not there, we will go download, I think it's Java 17 now. There's a, there's an API in the Java ecosystem that's hosted by a, what do you call it, Fujie.

And Fujie has an API to go get all these different variants of JDKs for different platforms. So we, we recognize the system, the architecture, the, the platform, the OS, we get it and download, install it. And then that means now we have the Java to run JBank. But if your script then needs to say, Hey, I, I'm using Java 21.

So you can do that with slash slash Java 21 in the file or 21 plus to say 21 or higher. We then go and look is the current Java at Java 21. Nope. Okay. Go fetch. We installed it in jbank cache and we will go, we will set up for you. So yeah, that, that thing is just. Magic in Java. Like it just works.

Jonathan: Yeah. So something else that might be magic that I want to know about is, again, you've mentioned this briefly, but dependency handling how difficult is it because Java, Java is all about dependencies. Like there's, there's like a million libraries out there. That's like one of the super powerful things about it.

Is it, Hey, I wish I could do this in Java. There's probably a library that does it. How do you pull one of those in? Do you have to, like, include somewhere that, like, here's what it is on Maven and go grab it, or can you just, like, include the class and it'll automatically go look it up? What does that look like?

So I,

Max: I had a prototype for the class thing, but it's just, it's too magical. Like, it becomes, like, things fail. But so, so right now, so it might happen eventually, but right now I use we use a slash slash steps for dependencies and it uses the, the, like the convention it's to say, if you use cradle, they have them all.

So maybe it actually has a syntax for specifying group artifact version classified as a whole language. And that's just the one that we support. And that makes it very compact. And, and that's, that's what we do. And it, it. Yeah, that's all that is it to it. Like slasher steps and you can do it in the file.

You can have a separate file. You could do it on command line. So, and you can combine them so you can have a, let's say you have a a script that does something that says I need out 21 plus. I'm using Hibernate for database access. But I, then when you run it, you need to get a driver, like a square, like in a square, a Postgres.

So then you can go J bank desk steps. The Postgres driver and then the scripts and then these two gets combined. And now when you run, you have access to the, to the driver. So you can, it's very composable in that sense too.

Jeff: Jeff,

Jonathan: you want to

Jeff: ask that? So I, you know, you said you had a cache directory and everything and you're, you know, And I, like I said, I'm not super on Java. So do I end up with a, like a jar file that I, you know, I write my script and J bang, it can run, it can work. Do I end up with a jar that I can then just say, Oh, Hey Jonathan, I wrote this script, but I just sent him the jar file and it runs on his machine or how does

Max: that work?

Yes, you can. Yes, you can. So this is that though. Yeah, exactly. So yeah. So there is actually. There is a jar file in, in, in, in, in the, in the background. Originally I thought that in the early days it was just there because that was an easy way to actually not have a thousand files, but just the jar.

That's one jar that has the whole thing. But then someone, this was actually the, the, the, my the mind Mindstorm, the Lego Mindstorm use case I had for my kid. I needed a jar. That I ran, I had to export it and ship it into a Raspberry, the Raspberry Pi thing that was doing the, the mind thing, the, the, the Lego stuff.

So I had to export it. So there's a J bank export that will generate the jar that the, the results, but it will also depending on how they suppose you can make, make the jar and then copy in next to it, all the dependencies. And then the jar has references so you can just run it. So it's like a a multi file thing on disk.

Or we also have an export fat jar, which then takes all the dependencies and just scrolls into one jar. And you can ship that over and run it somewhere. And there's a bunch of other ways you can like export a container, export other stuff. But yeah, you can actually, you can take those scripts and export as a jar and just give it to someone and hope they have Java.

You can tell them to install a J Bang because J Bang doesn't only work for scripts. It will also work for jars. And then you can, J Bang will go get the right Java version and run that jar for you. So I'm not sure if I explained that well enough. Right. Because then, and this is the thing where, where I was having fun, some weird night, I go like, wait, I can now run the jar locally on my, I can have Java sources, create a jar.

I can export the jar. And I go like, Wait, why don't I just allow you to run any JavaScript, just Java source file or jar that is locatable by HPS or the ASP request. So that opened up for that. You can go and say, not just J Bang a file, but J Bang a URL. And it applies the same logic that it does locally.

It's a jar file. Okay, I download the file, compile it to a jar, analyze dependencies, and all is there. It's a jar file. I run it. I download and run it. It's a main dependency. I fetch the dependency. And I, we actually made it even further. So now we, we have a shorthand. For any GitHub repository or a gist, you know, gist service for, for, for grabbing stuff, you can do gay bang, a gist URL, and we will go and look for Java files in that gist and compile it for you.

So you have something running somewhere you can just, it's now trivially easy to distribute that to anyone, anywhere on the planet. As long as JBang is on the, on the system.

Jeff: Yeah, that's awesome. Because that would be good for, you know, say I write something that I need to give it to my mom, who's not a computer person, I can just, you know, okay, install this, and then do this, and then Yes.

Everything, everything's automatically taken care of.

Jonathan: What is, what does the process look like of installing J Bang itself? Is there just like a, is, is there some little tiny script that you can curl and run that bootstraps everything? Or yeah, you, you mentioned it's available in pip. What are the, what are the options for getting J Bang on a machine?

Max: Oh, how much time do you have? Cause I, I counted it just before here. I think I have about 20, like 90 or 20 different ways you can install JVM. So there is the traditional, like in Linux land, you can curl download thing. Right. But you can also I have there's a, a Fedora package. There's a Red Hat rel package.

There's a standards package. There is It was called ASDF, the installer, there's a Nix package, there's a Docker image, there's a JavaScript module, there's a Python module, there's a GitHub action, there is on Windows, there is if you know, there's a NuGet. And a Choco installer, a Scoop installer, and on Win Brew, there is Sorry, on Mac, there's Brew to go.

So, I, literally, any reasonable Python system that either I was able to make work, or someone in the community has done, We have available to get it. So basically there's no excuse to not install and

Jeff: we talk about this on. The untitled Linux show sometimes, but I did look and there's also a snap that's available for Ubuntu.

Oh, yes,

Max: sorry. Yes. We like to tease back and

Jeff: forth sometimes about that. Some of us are not as excited about the snaps.

Max: Yeah, I know. Yeah. And the snaps and there's the one that there's some Fedora line. I forgot the name now, but the same concept of these isolated ones, which was actually a really a big challenge.

Yes. Yeah, it's like that, yes, right, but it's a very big challenge because I need, like, JBang is, needs a Java to run, right, but if I'm not allowed to run the Java that's on your system, I, it's a very limited use. And one of the things Flatpak does is it's default is sandbox, so you can't do that. So, but we, we found a way and, and Yeah, so now you can use it as a Flatpak and it can run.

But you have to run with like some, Like escalated privileges because you J Bang is calling back to your system to use the Java you have available. So, but yeah, no, no, there's there's there's all all the ways you can think of if one is missing Let me know

Jonathan: Mashed potato mashed potato from our chat room says was compiler from source on that list

Max: Compile So the product is fairly easy to compile You but yeah, but that's, yeah, you can, but it's not, it's not a way I, I I say, Hey, this is how you download.

It's one of the things I learned from early on is any successful, like utility open source product in the first, you have to have working software and two, you have to have it available to release. Yeah, so I'm able to run and that's why in the beginning I was like because I've been doing tooling for 20 years and I had to fight people for, hey, you know what great.

It runs on Linux and Mac. But majority of enterprise customers runs on windows and every linux guy and every mac guy hates me for it It's like I don't want to deal with it. No, no, I know but that's One thing is what you as a privileged guy who have access to all your links You're not the developer runs in a bank somewhere and told to run in this windows citrix hosted somewhere It will it won't run on this stuff, right?

So I I spent That was what, before I ran, I released anything, I want to make sure it ran on all three platforms. And it was, it worked on every release and I could release that very easily. And and that's, so early on, I think we, we had 10 or 12 different ways of packaging installing it, which was really, really hard to do because there was no other Java product that had done these.

Very different ways of setting up installers. And that actually, you had Andres Amorea on about JVelizer a month back or so, and JVelizer actually part of like the way JVelizer got created was I talked to Andres about some of this stuff and he said, Hey, I'm doing a Go thing and GoVelizer has this thing.

Why don't we have this for Java? I said, well, If you make it, I have all the scripts, I have already done all the work on how you make a CLI in Java that can run on the, or be installed by these. So he took that and improved on JReleaser to the point that now JBang is using JReleaser instead of the scripts I created like five years ago.

So it's all all connected.

Jonathan: Yeah. It's a, it's kind of a challenge these days actually to get a Java runtime environment on windows, isn't it? Didn't, didn't like Oracle make some licensing changes to where you got to have a, some sort of agreement with them to be able to download it. Oh,

Max: yeah. So this is another part, like, so no, so no, well, this is fun.

Like it has never been easier to get Java on any platform because what Oracle did or Sonar like years back was they open sourced it and there's all these different teams that makes JDKs available. So yes, Oracle did change their license. Statements and I'm not a lawyer, so don't, but basically it says you can, you can use it for free, but after a year, if you stay on this version, you have to pay Oracle or you upgrade to the latest.

So if you stay in the latest. You're fine with oracles,

Jeff: but

Max: of course, as a red hat or anyone else, so I'll just say, Hey, use any of the other ones, especially Eclipse adoption, which is making a build of OBDK available to you. And there's Amazon and Microsoft and others has DDKs that are available without any of those license restrictions on them and, and.

And then there's this fuj, which is a service that literally gives me an API, like I I in J Bank, I just do, I generate a URL that says, this os this platform, this combination. And it, it will orchestrate, it'll go, oh, you need you want adoption bill for windows on, on this architecture? I'll go get that.

At the actual vendor, right? So there's one place that you can look up and get any kind of data K for on any platform now. So it is trivial easy, but yes, Oracle, of course says, Hey, install the Oracle one, because if you get. That's the one you use, then you, you, you, you, you will want to get support from Oracle and pay for that.

Does, does J bank,

Jonathan: yeah. Does J bank support actually installing? So it sounds like you go with open JDK by default. Do you support actually installing the one from Oracle? And does that ever matter?

Jeff: Oh

Max: yeah. So the default I use is the, what's called Eclipse Adoption. So this is the, maybe you heard, heard the same thing about Omnidecay some years back, there was a, like an alternative to get core, Oracle to realize, Hey, make the binaries more freely available.

So we, I use that because I then are sure that no user that ever uses will end up with a lice, like a. You know, licensed what's called licensing.

Jonathan: Yeah.

Max: But so I don't, so, and also I wanted to make sure that any, any default use of J bang will always get as close an experience. As if, as you have, like, so, for example, Jeff said, Hey, I wrote my script on my Linux.

I'm sending it to my mom or some student was just run a javang. So javang will default download. If you don't have the system, the default system, Java, you'll go download the adoption one. But because we use this FoodJ behind the scenes that can get any of them, there is actually a flag in, I mean, it currently is not exposed in JPEG because I haven't figured out a good way of doing it, but there is an environment where you can say, hey, I don't mind the vendor, JDK vendor should be Oracle.

Or Amazon or Red Hat, and then we will actually go get that one. And that includes and the Oracle ones, et cetera. Where it make it's actually has a use case is when you use early access builds so when there's a new version of something, the open data K community project. Will have binaries before the orders have them like a few days before and then it's nice to do or if for some reason you oracle has some features that are specific to their ddk If you want to utilize those you would want to use the oracle, but that's like I it's a niche case.

So it's not a thing that It's, yeah, there's flags and things you can do it. And I use it all the time for testing weird combinations. Yeah. But so, so no, so yes, it's, it's important. That's the way to do it.

Jeff: Yeah. Awesome. So. You talk a lot about supporting, you know, all three platforms, you know, looking at other open source projects, which ones are successful, how they do it.

So what, what has been the challenge of getting people to, to use JBang, you know, getting users to come in, you know, into the ecosystem.

Max: So, so that's the, that's the, that was the one that surprised me the most, because for me, what I. Built jpang. It was just hey, I want to replace this case with that. Let's just do it and then suddenly I realized Oh shit, I can, I can, I'm sorry, I can do all these things that we just talked about.

And then I go out and showed it to my team, like, and this team, these are like you know, people that have been doing Java for years, and I thought they would immediately be like, this looks awesome, let's go. And they're like, no, no, like, I don't know why this is not using Maven. It's not using Gradle.

This doesn't work in the IDE. Like, why, why, this is not Java. Like, why should I use this? And I go, no, it is Java. It's just a little script. And I've heard so many times people like, no, no, this, this is not what I'm used to. And therefore they just abandoned the idea. And also there's this, say Java is in a enterprise setting, so everything has to be enterprise y.

So if stuff is easy, it's considered not enterprise y. Like it's this weird thing, right? Like I even heard. Someone was like, no, no I, it's, it's called J Bang. It's not Java. So therefore it's not part of the Java ecosystem. And then I point out to them and they say, well, no one will ever use that.

And I put out to them. You do, you do realize Maven or Gradle is part of Java that is a complete separate ecosystem from it. So it should be possible. Oh, that's, you know, that's just how it, you know, it is. And then you go look at this. Oh, it should be as easy to do as you do in Go, right? So for example, Go was, did a brilliant thing.

They actually have all these tooling in like anything is built into. Go like there's a go format or that's a go install all the stuff is there. But that is all copied from like Python and Node. js. So if you look at Python, pip is not part of Python. Pip is a separate thing that Python, the community has adopted.

Node. js and JavaScript, it was originally in a browser. Someone then took it and put it in Node. js and Node. js then made this thing called an NPM. So all the other key systems, which people are saying, Hey, these are easy. Has done what I've, I'm doing it, but in the Java world is considered. Against some religion or something.

That's the, that's my, that's my biggest issue that I generally, when I go out and talk and present, I it's, it's like dividing three people. One is the ones who get it immediately. And like, Hey, I can do scripts and I can run them. I can install them. And that's good. And then there's a group that just, they just.

They, I think if they got it, they've just been so indoctrinated, they're like, no, no, no. This is alien. I will not touch it. . And then there's the one in the middle who are like, they just, they need to go touch it and see it before they, they, it, it connects. Um, and that's, so that's, that's the, that's the, that's been the, the challenge.

And it keeps being a challenge that, that people just can't believe that it's this easy. And like. I mean the taco is the he he he's to to blame or thanks for a lot of these life and stuff like When he he proposed this thing about being able to app So we, I did, we did all the JBang run and run from UL, like in the early days, I could even, I can even run a tweet, like, so you can go, you have a tweet UL, I can go JBang Twitter, blah, blah, and I could have, I could run a tweet.

Unfortunately, I can't do that anymore because Twitter has locked down. If you don't have JavaScript, you can't run anything that way. But and. But Tago came up with this like, Hey, we, if, if, why can't we do JBang app install, like, like you can do NPM install pip install go install. Why can't we do that for Java?

So, and this is the thing, and this is, again, I'm saying here, and I'm pretty sure no majority of those who are listening will not get it until they try it, but you can now, there's, you can, you can take a JBang script and you can Or a jar or maybe an artifact or anything and install. You can go jbank ev install.

Like the latest one is JLama. JLama is an inference engine for AI. It's a little tool. You just go JBang, app install, JLama and it's a different name. But, and then you have JLama, and you just run JLama directly. You don't see JBang, you don't see Java. It's just there as any CLI. And there's a bunch of these tools out there.

Like there's an SQL line, there's a different utilities that are written in Java, which originally you have to go like download the JDK, download the jar, put it in the past, blah, blah, all that is just gone. You just go javang app install. And, and, and you can do that for any Java. This, like that product has been built with Maven or Gradle or whatever.

And the only thing they use javang for is just to, to wire up all that stuff. And again, if you're a Python guy, a Node. js guy, a Go guy, you've been doing that all day, all year for the last 10 years. And now you can do it for Java, but getting that word out and getting people to believe it has been the biggest challenge.

Jeff: Oh yeah, I, you know, and I, I remember what you taught when you said, you know, it's got to be hard to be enterprise and all that, because I remember back in the early days of the internet. If you didn't compile your own IP stack, you didn't deserve to be on the internet. You know, it was just, it has to be hard or you don't deserve to be here.

But, but going into that, can I use it in enterprise? Is it, you know, is it, is it stable enough? Is it ready to go?

Max: Well, so

Jeff: have a cheap code for enterprise. Yeah. .

Max: Yeah. Well, so the, the, the, yes. So the thing is, and this is related to what I said before, like it, it, it literally is, you don't have to do the scripting part of J Bank.

J Bank scripting was just where it started. But you can use any kind of j jar. So if you have, a spring project or micro naught or corkers or anything else. You can just use J bank to run it, set it up. And one enterprise area we, I, I see, and this is where we actually use it. On the product I have myself is all the CDI, like CI scripts, like the, the, it's so popular, we're doing all this dev ops stuff.

And the fact that our Java developers can just use Java to script things that they do. So that's one entry, but The other product that my main job is actually to work on a product called Quarkus, that's actually the t shirt I have on here is it's this thing where we, we, we, we, it's an enterprise framework stack that makes Java, you know, fun again, so to speak.

And, and, and, and, and can run very effectively. And that one actually, the way Quarkus does that is by doing build time, like doing simple build time. And that normally requires a full build tool. But if you combine that with Quarkus actually has support for JBank. So if you take J bank script and add a Quarkus dependency.

It will actually not just be fetching dependencies, but J bank has support for extension. So Quarkus actually gets invoked to go, Hey, I compiled these source files. Now go your Quarkus thing. And then that output is actually. An enterprise app, right? And that can then use all the stuff Corvus has, like native compilation, running container any camel, CXF, all that enterprise stuff is available to you.

But I do want to put an asterisk on it I'm not telling you to drop all your gradle and maven projects because there's stuff that debank doesn't do that these need to do there's complexities that debank navel will cover but Definitely. You, you, you can, you can use J bank to, to write microservices and, and get up and running.

We, we do it for our, we have a GitHub bot and some applications. They all, they are actually either a caucus app then run by J bank because you can get all the Javas, or it's a script that sets up a few things and just runs. So, so yes, it is enterprise, right? But it has a certain use case, right?

So in that way, it, it, it is there.

Jonathan: Very cool. So I've, I've got to ask like what what's, what's coming down the pike, is there something coming for J Bang that you're excited about?

Max: Well, so my what i've been doing mainly is trying to I go out and I I try and find all these utilities because there's there's a bunch of people who wrote Awesome things that never got into hand of people because it was hard to run these things.

So i'm going I mainly go out and submit small patches Hey, jbang we have this notion of a jbang catalog which sets up the command line or that kind of thing and and make it rumble So that's this That's what I've been doing. But the, the, the, the, the main, so when I then do that, then I might find a thing that they do that I hadn't thought about, and then we do a release.

But, and I'm on release, I think like, like 0. 119 is the one that I think I've done like 250 releases in. For four years now. Right now it's very incommensurate, but I'm trying to get to that one. Oh, but that one, Oh there are some enterprise features around how you manage dependencies that I don't capture.

But otherwise I'll say we are very free to complete in, in being able to do the main mission of what JBang is. So, so, yeah, so. For me, the big thing now is actually to get people aware that this exists and try it out and not try and be scared of it. So it's more of a soft features than the hard features in that sense.

Jonathan: Trying to get to 1. 0, do you feel like Sisyphus rolling the rock up for all of eternity? Is it a Sisyphean effort?

Max: Yes. Well, it's just, the thing is I, the problem is I've, I've made the come back to like make, it's so easy to do releases and like, it's been stable and we actually try. And I think we have one or two glitches where we, we did a mistake.

But it's actually, you can still use the old ones just fine. But one of the things I want to do before the wonder will break some users and That's, that's the rolling I'm, I'm like one day I'll, I'll do it this way. And then they, yeah, so no, so yes, I do fall through that. But I, the, the cool thing I do is this part of the the way we do the current, like the, the installation, whether it's the Maven plugin or greater any, any of the way you install like curl and stuff is is going through J Bang dev a URL so I can actually see When people are running a J bang in stores.

So no, I can't see who you are, but I can just see someone somewhere did fetch this little script to go look at the latest version information. And I can see the growth is there a lot of people in Azure and GitHub Jackson is using it. But I'm still missing the. The uptake in all those Java utilities out there to, to to make, to, to have it and any Java stuff available as easy as you can for Python and, and, and JavaScript.

Jonathan: All right, we're getting close to wrap and here in just a minute, I'm going to ask if there's anything we didn't ask that we should have. While you think about that, I'm going to ask a different question. And that is, what is something that your users have done that really has surprised you? Is there any like oddball use cases that are particularly interesting?

Max: Okay. Well, well, so, so, so the, the, the latest one, it's not all about the JVM, it's just this thing of so, so the, the, the JLAM, I think, so, so again, everyone thinks AI has to be a Python, which is great and stuff, but JLAM Java has a vector 20, there's a, a vector support coming, so they can, it can do efficient array copying and manipulation, which you need to do in inference engine.

So there's a guy Jake, I just know him as Jake on, on, online. His run and written in a Java implementation of that's called JLama. And he had an installation set up that was very complicated. And I just pointed out, Hey, you can do a JBang. And he just did that like this week. So now you can actually, with JBang, again, you can start from scratch on your machine and just install JBang and go JBang download this, one of those models and run it and no, and it will be a CPU, a GPU optimized and that kind of thing on any platform where that exists.

So that, that's my recently interesting setup. Then I know that's, that's gotta be tricky to explain but I'm showing it, but Java has a notion of agents. So you can attack any Java app. You can attest an agent that gets notified by anything gets loaded, and then it can manipulate the classes and you can do evil things or good things.

They can monitor and that kind of thing. And again, if you use the normal Java tool chain, that's a lot of arguments, a lot of setup, and you have to download files and that kind of thing. So we have a product in Rehag called Byteman, which is an agent that can go in and you can say, hey, if I hit a method that has this signature the third time, throw an exception or log a statement, right?

So you can do all kinds of things, but you have to do all these steps. And then I realized in JBang, we have all the pieces to not just go get dependencies, but all of the app, but also the dependency of the agent. And also any configuration that the agent needs, I can go get from a, from a URL. So again, with JBang, you can actually.

Set up any kind of agent usage on any kind of a Java app in a one liner command, no complicated cradle, maven, all that kind of thing. And I find that super interesting, but. I also think many people will actually appreciate it because those who actually managed to do that without it is very, very few, but the, the, the, the, the power is immense.

And this is stuff that you cut like in, in Python or Node. js is those kind of things just doesn't exist or are even more obscure than, than we have here. So no, so the,

Jonathan: Yeah, interesting. All right. Is there anything that we didn't ask about that you really wanted to let folks know about?

Max: Well, the main thing I have is like, if you're listening to this and seeing it, do just try it out and spread the word, like try, try and use it.

And if you have a Java tool to somewhere. Apply a little bit of JBang so it actually becomes available to anyone out there. That, that, that's my, that's my hope that some, some of those people in the, Hey, Java is this horrible, complicated thing. But I know that this utility I actually would like to use if it was easy to use Java.

That's where JBang can help. So, so, yeah.

Jonathan: All right.

Max: Try it out.

Jonathan: Yeah, absolutely. I do have a couple of questions that I'm required to ask everybody. I think I already know the answers. But what is your favorite scripting language and text editor?

Max: So the text editor. So I'm, I use every editor on the planet because I've done tooling it, but the one I, my day to day driver at the moment is VSCode or or some variant of that.

The scripting language, well, I would say Java space script. I, I've done a lot of scripting in my, my like bass and Ruby and Perl and Python, but once I got it working for Java, I use it for everything. But it's technically not a scripted language, but. scripting. So I'll say it counts space. It's my, it's my favorite script.

Jonathan: There you go. All right. I think that's it. We've gone past the hour. We, we sure appreciate you being here, Max. Thanks for stopping by and Telling us a bit about J Bang and scripting with Java. Sounds like fun.

Max: Me too. You should try it. It's, it's, it's not your parents Java anymore. Yeah.

Jonathan: Yeah, I'll have to, I'll have to look it up and give it a shot.

All right. Jeff, what do you think? Have we, have we convinced ourselves to go try some JavaScripting that is not JavaScript?

Jeff: I, you know, I'm kind of interested in this. It's you know, I, I've seen a bunch of Java programming in the past. And, you know, I've, I've messed with other languages, not really with Java, but, you know, kind of something to make it a little easier like that.

I kind of interested in that, you know, I, I, it piques my curiosity.

Jonathan: I, I feel like it would be fun to at least like, fiddle around with it enough to be able to say that you've done so. I, I'm curious. I, I guess I wonder are there things that you normally do in scripting that Java is not made for? And we, we didn't, we ran outta time.

This is one of the questions I, I wanted to ask. We ran out time to do so. But I'm interested to dive into it and see, you know, like in bash scripting you get to do things like, call other bash commands with backticks and then replace the output of that command into your script and Just I I guess Java has all of that built in because it's more of a full featured programming language So it doesn't even need all those tricks But it's interesting.

It'll be fun to play with I definitely need to go grab it and check it out in in possibly a snap format Maybe I don't think I have any computers that'll run snaps actually

Jeff: That's, that's a UL, ULS inside baseball. Yeah, yeah,

Jonathan: yeah, yeah. All right Jeff, thanks for being here. Do you have anything that you want to plug?

Jeff: I don't. I just well, I guess other than check us out on the Untitled Linux show, over on the twit. tv network become a member of Club Twit. And I'll see you next time.

Jonathan: Yeah, have a great week. Excellent. Thank you for being here. I do want to let folks know. First off, next week, we're talking about EMBA with Michael Messner.

And that is an embedded firmware analyzer. I came across this doing the security column on Packaday, which go live, goes live on Friday morning, which you should check out. Came across it one week and it's an open source project doing like embedded firmware analysis, looking for problems, trying to understand the way it works.

And I got to looking at their code and thought it was really cool. And so we're going to have them on the show next week. It's going to be super duper interesting to talk about EMBA. Other things that I want to plug, of course, as Jeff said, we've got the the Untitled Linux Show over at twit. tv.

Would love for everybody to go check that out. Show Twit some love, and yeah, we appreciate Hackaday giving us a home for the show. And with that, we will see you next time on Floss Weekly.

This week Jonathan and Jeff chat with Max Rydahl Andersen about JBang, the cross-platform tool to run Java as a system scripting language. That's a bit harder than it sound, particularly to take advantage of Java's rich debugging capabilities and the ecosystem of libraries that are available.  Tune in to get the details, as well as how polyglot files are instrumental to making JBang work!

• https://www.jbang.dev/
• https://maxandersen.github.io/getting-started-with-java-the-jbang-way/
• https://xam.dk

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/

Jonathan: Hey folks, this week Aaron joins me and we talk with Andreas Kling about Ladybird. That's the from scratch web browser that's almost ready for primetime. You don't want to miss it, so stay tuned. This is Floss Weekly, episode 800, recorded Wednesday, September 10th. Champagning the Ladybird browser.

It's time for Floss Weekly. It's the show about free Libre and open source software. I'm your host, Jonathan Bennett, and today is no exception. We're going to have a lot of fun. We're going to talk about Ladybird, the from scratch web browser, which, boy, that just, it sounds weird to even say it, but We've got the, we've got the man himself we're going to talk to in just a minute.

But before we get to that, we've got the other man. It's, Wow, that transition did not work as well as I thought it would, but here we are. We've got Aaron. Welcome, sir. Hey, thanks. Thanks for having me. It's good to have you back. I am so glad. One of the things that makes me extremely happy about moving to Tuesdays is that we get to have Aaron back as one of our co hosts.

And I just, I get a kick out of that because I've always, always enjoyed being able to work with you. And I was very glad to be able to have you back in the rotation.

Aaron: Yeah, for sure. I just noticed that my maybe because of my mustache, my beard's a little longer, it needs a trim. But I've noticed that like, I've got the old man syndrome.

Like the older you get, the more your face droops and I'm sitting here smiling and I'm realizing that it's just like a straight line across now. It doesn't go up in the corners anymore. So yeah, I've got a, I've got a hope that people know that I'm smiling, but I am, I'm happy to be here.

Jonathan: Yes. So Lady Bird, what, what do you know about Lady Bird?

Aaron: Absolutely nothing. Absolutely nothing. It'll be, I'm really interested for this conversation though, because you know, a, why do we need another browser anyway? Like what's the problem that they're trying to solve? I think. A lot of us know what that is, but I still, I, it's a lot of effort to do a browser.

There's some

Jonathan: problems. Let's just say there's some problems.

Aaron: There are problems, right? We'll get into that. And then, you know, I'm, I'm old enough to, to go back to the days of using mosaic and text based browsers and gopher and, you know, I was around at the beginning of the internet, um, at least that part of it.

So. So, yeah, I mean, I remember when new browsers were popping up you know, pretty frequently and it was like a big deal, like when Netscape navigator came out, it was like, Whoa. So anyway I remember those days. So I'm kind of curious, like, what are we going back to those days of like, Hey, let's just get back to basics here.

Or, you know, is there, you know, how do we, how do we accomplish that? And also make sure we can still do the things we want to do. Right. On mine. So, yeah, I'm really curious.

Jonathan: I'm, I'm kind of excited that we have a new browser that's not just Chromium with a different skin on it.

Mm hmm.

Yeah. We have, we have a bunch of those, and so people, I mean, you just talk about this browser and you go and look at it.

It's just Chromium, guys. It's Chromium with a theme. It's, do we really need to do a whole show about this? Lady Bird is a bit different. Well, let's, let's go ahead and bring Andreas Kling on, who is the man when it comes to Ladybird, and I guess the man when it comes to browsers. Welcome sir, thank you for being here.

Hello, how's it going? It's great, it's great. So, Ladybird, it's, it's a browser. Let's see, where should, where should we start? I have lots of questions. Shoot, I don't see a download link. Let's start there. Okay, the audience knows this, just so you know this, I will ask a lot of questions that I either have a guess or I know the answer to.

I'm pretty sure I know why there's not a download link, but I'm, I'm trying to be a proxy for our audience in asking me to share.

Aaron: Well, that's the first thing I did this morning as I went to go download it. It was like doing exactly that. I was like, Oh,

Jonathan: I see a project,

Aaron: but no download.

Jonathan: Do I have to, do I have to compile this from source to be able to use it?

What?

Andreas: That's crazy. No, like you were saying we are doing something different, which is that we are not starting from Chromium like everybody else does. And because of that, it's going to take a little bit longer to, to get this thing ready. So the, There is no download today but you can download the source code and build it.

I think it's two commands that you have to run and then it should take care of everything for you. We, we do get a lot of positive comments about how easy it is to build our project. And we are aiming to put out an alpha version in 2026. So that's sort of the timeframe that we're looking at right now.

But we, to go more public because we started a nonprofit earlier this year. So that's why you've been seeing us more and more because we started to get more serious about this. And I hooked up with Chris Wanstroth. Of GitHub fame. And we started this nonprofit to fund and develop Ladybird.

And we've talked to a bunch of companies that are also interested in, in like having a new browser on the scene. So that's sort of how it's come together. And but at this moment you can, you cannot download a running product. We are pretty far from that, but because. It's a lot of work to build a browser.

We do need a little bit of funding, at least not as much as everybody else, but a little bit, so we have been raising a little bit of money. And yeah, that, that's kind of the, the general state of things. And a lot of people, of course, brave early adopters and courageous open source enthusiasts still go and build the browser.

And they are typically disappointed, but come away with a bit of hope at least in their, in their stomachs, I would hope because it doesn't work Well, for daily driver browsing today and we're not trying to mislead anybody about that. And we are actually two years out from, from what we would consider an alpha version.

So we don't encourage anybody who's not technically minded to even bother with this at this point in time. Because you're just going to have a bad time. But for people who are technically minded, you are most encouraged to try it out, mess with it. Try your favorite website, maybe a website that you made yourself.

Tell us what didn't work, what didn't work right. And maybe even figure it out yourself and see if you can help us fix it. So we've been doing a lot of that. Trying to collect new developers.

Jonathan: Is using ladybird right now a better or a worse experience than trying to use something like the links browser?

Andreas: Oh, wow. I don't have an, I don't know. It might be better.

Aaron: It's gotta be better.

Andreas: I would hope it's

Jonathan: better.

Andreas: It's, it's probably better. Yeah. Cause yeah, but the links is that links to one, but JavaScript.

Jonathan: No

Andreas: links

Jonathan: is text based links is the entirely text based browser. I don't think it runs JavaScript at all.

Andreas: Oh, yeah. Then you're kind of screwed.

Jonathan: Yeah. Okay.

Andreas: Yeah, no, we, we, we can do bare, we can do JavaScript, not just bare minimum, but like we can do real JavaScript. But we do struggle with performance. We struggle with some of the more intricate features and especially stuff like a YouTube doesn't work yet because of a million intricate little things that we have to figure out.

And there are a lot of these bot detection systems that we have yet to like convinced that we are a real browser. So CloudFlare and Google and, and whatnot, they have like these you know, mechanisms to make sure that you're not a bot and we look like a bot because we're just doing stuff wrong.

And that's entirely on us. You know, they're, we're not complaining about them. We just have to get better.

Jonathan: I could actually see somebody like Cloudflare getting interested and excited about the project. You know, they're all about having, in some cases, their own technology stack. And so, having a browser that's not run by one of the big guys is maybe something they'd be interested in.

Andreas: Yeah, so we've spoken a little bit with one of the engineers on the team at Cloudflare that makes this anti bot software. And we have a little bit of a back and forth there, but there's just a lot of work on our side to do. And of course, not to mention any of these fingerprinting things, you know, where you can check, Hey, how fingerprintable is my browser?

We are possibly the most fingerprintable browser right now.

Jonathan: So, okay. So what's the origin story here at, at what point did you wake up and go, I'm going to build a browser from scratch. And like, what, what sort of my, where, what was your headspace? What, what kind of crazy headspace did you have to be in to make that decision?

Andreas: What, it never happened to you?

Jonathan: Not that in particular, no.

Andreas: Other crazy things, yes, but not that one. Right. Well, it all started when I decided to build an operating system from scratch. Which was its own crazy headspace that Somehow seems less crazy? In some ways, perhaps, yeah. In retrospect, it was a simpler time.

But yeah, so I was doing that for a while, starting in 2018, I built the Serenity operating system, Serenity OS, and it was a. Passion project for myself that I did as a sort of personal therapy to keep myself out of trouble. I used to have a pretty big problems with drugs, alcohol, stuff like that.

And I needed something to focus on that was healthy. And yeah, I went pretty hard on building an operating system, put it online. A lot of people liked it and started to work on it as well. And a community formed around this and the community just kept growing. And we became more and more ambitious with our scope and we would add things like well, initially it was pretty modest, you know, we would add networking and we thought that was a big deal, but And then, like, why don't we have a photo editing program, or a music production studio, or visual programming tools.

And it just kind of kept growing in scope. So it was natural one day that we just decided that we should have a browser also. And a big part of SerenityOS, the SerenityOS mindset, was that we do everything ourselves. Like, we don't borrow code from anywhere, we just do everything ourselves, because it's more fun that way.

And I'm sure every hacker ever can relate to that. Even if you wouldn't necessarily do it at work, you at least enjoy doing it at home. Sometimes. So yeah, that's sort of, that's sort of the where the whole thing started from was that we wanted a browser for SerenityOS because we were adding everything to it.

And I have a professional background in working on browsers. So I was working on the KDE browser Conqueror like 20 years ago. Since then I've worked at Nokia on their browsers and then at Apple on their browsers. So working on browsers was like my job for a long time. So it was very natural for me and once I started working on a browser again, I kind of just slipped into this old habit, and it became my main focus, and I kind of stopped working so much on the rest of the operating system, to the point where they became two distinct projects, and we forked because, The browser was getting so much attention and people were focusing exclusively on the browser.

And we were living in this GitHub repository together with an operating system, with a photo editing software and music software. It was just a really cramped space. So projects split up and now I work only on Ladybird. So the browser only. And we've sort of changed the rules a little bit. So as I mentioned, it used to be that we don't use third party software.

Like we do everything ourselves since we're in the US, but in Ladybird, we want to actually make a product that people could use. And so we have admitted to ourselves that we're going to have to use a little bit of third party software to, to make that happen in this lifetime. So Over the last couple of months since we forked, we've been integrating some of the sort of open source ecosystem for things like fonts graphics formats, audio formats stuff that would take us a long time to do ourselves exhaustively and correctly.

We can just like piggyback on, on the existing stuff.

Jonathan: And

Andreas: yeah, that's sort of the origin story. Yeah. And that's where we are today also.

Jonathan: So speaking of where you are today, I'm going to, I'm going to hand it over here in just a second, but I do want to ask first, like what, what is the state of ladybird?

How much of the web actually works? How much of it renders correctly? What, how, how frustrating is it to try to use it?

Andreas: Oh, well, it's pretty frustrating. I'll tell you that much. But we've been focusing on our own sort of Dogfooding use cases. So we tend to use a lot of

Aaron: dogfooding. It's champagning

Andreas: champagne.

Aaron: You're drinking your own champagne, not eating your own dog food. Right. Or maybe not. Don't be yet. As the case may be.

Andreas: Yeah. I don't know that that will work for me personally, but I can see how dog fooding is a bit of a weird term. Yeah, no, at Apple we always called it living on. So like you would be living on the latest build or living on Living on Ladybird.

And we're trying to do that. So we're focusing in on our own daily use cases, like using GitHub, using you know, Google and reading web specifications more than anything, really and getting communication software working like discord and stuff like that, like stuff that we use every day. And those kinds of things have been seeing pretty good development.

They're not super great yet. GitHub is, I think, the thing that we handle the best. But once you sort of stray outside of the things that our developers use every day, you're gonna probably run into issues. And It's, we've taken kind of a vertical slice approach to developing the browser where we've been just picking a website and then doing whatever it takes to make that site work as well as possible.

Which is, you know, one of many approaches. Another one approach you could take is you could pick a spec and then try to implement as much of that spec as possible. But we've been kind of going after these like, let's try to make this site actually work. And I, I often liken it to video game emulation, where you know, like if you're going to implement an emulator for the Super Nintendo or whatever, you're not going to sit there and implement every CPU instruction.

You're going to try to get Super Mario Kart to run or whatever. So we've been taking that same approach to getting websites working. Which means just to answer your question it's, it varies greatly depending on if the site you're visiting is something that we have worked on or not, but over time The, the rising tide lifts all boats or whatever, right, where because all of the fixes that we make for the various websites that we do work on, they are all in service of, of you know, supporting the web platform.

And it just happens that we pick sort of scattered random Parts of the web platform to implement at a time. But over time, our general standard support, our general support for the web has been improving. And recently we've also started running, there's this test suite called the web platform tests, which is a sort of a collaborative test suite that all different browser vendors contribute to.

So, you know, Microsoft, Apple, Google, Mozilla. And ourselves. Can contribute tests to this giant battery of like millions of tests. And we've been running that recently and I think I think we're passing like a bit more than half of the tests. And we're like actively working on passing more of the tests and Yeah, we, we definitely want to just get those numbers up.

But because we haven't been running the test before, it is there's a lot of low hanging fruit that we're dealing with. Yeah.

Aaron: Does it support Flash? That's a joke.

Andreas: It, it doesn't actually I mean, coming from

Jonathan: SerenityOS, that would be very on brand.

Andreas: A little bit, I guess. Oops. Oop. Somebody's got a dog.

It's all good. No, we don't support that.

Aaron: That was just a joke, but seriously, though, like, like, why, like, well, let me ask this first. Actually, I want to know, like, you kind of told the origin story. I want to know, like, why you think we need this number one. But before I even get there, the thing that I'm most curious about is how much interest have you received over the past, whatever, six months since the whole Google antitrust Yes.

Stuff has been going on. Have you like, you know, gotten way more interest all of a sudden, because of all of that?

Andreas: I don't know that I could really separate interest coming from that from interest for other reasons, but there's certainly been a lot of interest over the last couple of months, but we only went public with our.

Nonprofit in July. So, and the, the, I guess the latest Google rulings were pretty recently. And when people donate to our nonprofit they sometimes write a little message and there have been a lot of messages mentioning the, the state of affairs of the industry. Which I think, you know, it was positive and.

When I, when I talk about the origin story, it's, it's sort of it's sort of Ladybird just evolved out of hacker culture in some ways, but at the same time, it's also finding reasons to exist that aren't just organic. Because there, I think there is a need for a like a truly open browser that isn't connected to like the advertising industry, right?

And isn't necessarily depending on the exact same browser engine that everybody else uses, but like a new implementation that is standalone and doesn't have to do whatever Google wants at all, at all times. And yeah, it's, it's, it's a tricky little bit of a tricky subject because I've been in the browser industry for a long time.

I know people working out in every browser. There are a lot of great people everywhere. But at the same time, I think we should also acknowledge that the industry is a little bit messy. There are a lot of weird incentives. For, for the major browsers. And we are very keen to try a new approach to this where we are a nonprofit and we say very publicly, very explicitly that we will not take any kind of strings attached sponsorships.

So we're just going to. Do this with a small team you can sponsor us if you want, but you're not getting anything other than a logo on our website. We're not gonna, not gonna put your search engine in our default settings. We're not gonna send data your way of any kind. And We, we understand that this drastically limits our budget compared to the competition, but we think that this is something worth exploring because the world should have a browser that is independent of all of that.

And we kind of started in hacker culture and just organically grew a browser. But we find ourselves in a position where like. There's nobody else to attempt this. So why not us? Why couldn't we be the open community developed browser with no attachment to any advertising money?

Aaron: Right. Right. I think it's a, I think it's a very ambitious and very noble thing to do.

At the end of the day, it may be too early to tell this. I don't know. Are you going for, for parody at this point in terms of functionality or you know, when we get to 2026 and there's something that is on the download page for people to try will there be noticeable difference? What will the differentiation be between Chrome, let's say, and this, when it actually comes out?

What are you, what are you hoping to achieve?

Andreas: So what we're aiming for is that you can do your daily browsing with reasonable, Stability, reasonable performance. But it's unlikely that we will be faster than any of the other browsers because they have thousands of engineers to throw at performance.

We don't have that. We're not going to have a sophisticated developer tools that like help you write your CSS and develop your website. We're going to have some tools, but we just don't have the manpower to put all that together that they have, you know, a 10, 20 year lead on us. That's going to take time for us to backfill all of those things.

But in, in terms of just like rendering the web we are hoping to make something that will work well enough that a user can use our browser. And. Not think about the fact that they're using Ladybird. That's sort of the happy outcome is that you would just use this browser and it will work and you're not thinking about what browser you're using.

If you look under the hood or if you start to poke around in the menus and you try to try to do fancy things, you will quickly discover that we don't have those yet. But our hope is that it will be a decently well enough working browser for common websites that you're likely to visit. You know, your LinkedIn's, your Facebook's, your Gmail's.

All of those kind of things. And then It's seems very likely that we will spend, if that all works out really well, then we will spend the next year or two just fixing the last 5 percent of bugs. Because I think it's one of those things where like the first 90, 95 percent are going to take two years and the last 5 percent are going to take 10, 20 years.

Jonathan: Yeah, well, part of that's because the web is, is such a moving target. Like there's constantly new things getting added to the JavaScript standard, to the CSS standard, to the HTML itself with, you know, HTML five and all of that. Is there, you, you might get to the point to where you sort of caught up, but if, you know, if it's going to continue getting supported into the future, I don't think it's ever going to be done,

Andreas: right?

No, it never will be. This is definitely a project that can go forever. And. There are all the other actors. So, you know, Google, Apple, Mozilla, they are all actively adding new features to the web. We are passively just implementing what they've. Come up with maybe one day we will decide that we, we can think of some great features too.

But at the moment we're just keeping it cool, you know, just implementing what's there. I do wish that people would slow down a little bit with the feature development but we do also recognize that the web has to evolve. Maybe not as quickly as it does sometimes. Yeah.

Jonathan: Yeah. So, so Aaron asked about the the idea of differentiation between Ladybird and Firefox and Chrome, and there is something that comes to mind, and I wonder if this is, this is something that you guys have realized, if other companies have talked to you about it yet.

Both Firefox and Chrome are huge, and they're difficult to install and work with. Like, they're just unwieldy. Like, particularly Chromium, trying to do a compile of Chromium is just a pain. And you mentioned earlier that Ladybird is pretty easy to get building and to get installed. And I could see it having a life in, in some places, you know, like you've maybe even embedded just because it's so much easier to work with is, is that something that you've, you've kind of had conversations about?

Andreas: We're not ruling it out. I know that there's been some interest in the embedded use case, but we haven't really been targeting it. We, we've been playing a little bit cowboy like with memory usage and resource usage in general. Because it's easier to just allocate lots of memory than it is to be careful and Precise.

And a lot of people, you know, a lot of people look at Ladybird and they assume that because it's new and because it has a limited set of features, it must be using less resources, but that couldn't be further from the truth. We managed to implement fewer features with a lot more resources than the other browsers.

But of course that's because they've been optimizing. Their browsers for decades and we haven't. So we're catching up a lot on, on that. And I think the embedded use case requires a ton of pretty sophisticated optimizations that we're going to have to do anyway, but I don't know, I don't know what kind of interest there would be.

I guess that's something we'll, we'll find out eventually if somebody comes to us and says, Oh, I have this great idea for an embedded use case. We're definitely interested in helping them, but it's not something that we're pursuing ourselves. Like we're primarily interested in making a desktop browser for people and for ourselves is the, is the current target.

Jonathan: Yeah. I have a I have a Raspberry Pi in my hallway. That is my HVAC controller. And the idea there is that it's supposed to run a web browser to, to show, you know, your, the webpage of what your temperature is. And it's kind of a pain to work. I think, I think, I think. I don't remember if it's Chromium or Firefox is what it's supposed to be doing.

It's not working at the moment. I need to spend some, you know, some engineering cycles on that again to get it working again. I think it could be a lot of fun, because the webpage it runs is just Stupid simple. It'd be fun to try to do that with ladybird. So I, I am

Andreas: For that kind of thing. Yeah. I mean that shouldn't be terribly difficult.

We could probably throw in some command line switches for you to like start in full screen mode. There's no ui and stuff like that, right?

Jonathan: Yeah I could that seems like that would be a huge win. I could definitely see some some businesses wanting to use that. What's the what's the license? What license is ladybird under?

You

Andreas: We are under a two clause BSD license, so pretty permissive, very permissive. Yeah. Yeah. Yeah. Yeah. Not everybody's favorite, but I don't think there is a license that everybody would agree is the best ones. Right.

Jonathan: Yeah. Yeah. That's, that's the thing there. And what about platform support? Is this you know, X86 64 only, does it work on ARM?

Does it compile on RISC V you know, MIPS, there's a whole bunch of different architectures out there,

Andreas: right? So far it's been X86. 64 bit and arm 64 bit as well. So we run on Linux and Mac OS at the moment. And like, you know, the, the wide family of random Unix's as well. Since we come from, from SerenityOS originally we had pretty, like, generic Unix fundamentals in the project, so it's been easy to port it to, like, FreeBSD, Haiku you know, NetBSD, other systems like that but Windows is the big elephant in the room because it's so different and not Unix like that, you know, Windows support is something that frequently requested, but we don't have any active person working on it.

But this, this is probably not the podcast to, to complain about Windows support.

Jonathan: And, and somebody could run it like in, in the what, what are they called the, the Linux subsystem L S W. No, that's not right.

Aaron: Linux subsystem for Windows. Yeah. LSW.

Jonathan: That does not seem like the right acronym, but okay.

Okay. WSL. I think it's WSL. It's WSL.

Aaron: Windows subsystem for Linux. Yes,

Jonathan: which was always a confusing way to put that. It feels backwards. It has led to some discussion. Is Windows looking to replace the Windows NT kernel with Linux?

Aaron: Right. Right,

Jonathan: but if somebody wants to there's there there's that right? I'm assuming it runs just fine.

Andreas: It does it does Yeah, although it is probably the worst developer experience that we have so people who try to do it that way They're the they complain the most out of everybody that comes to us.

Aaron: You're really making a Trying to try to force a square peg in a round hole

Andreas: Indeed

Aaron: at that point Yeah, you can do it, but you know, why not just start up a virtualized environment in your Windows desktop and yeah, you know, just do just do that.

Just run Linux on top of it in virtualization. What I had a question and now we had that discussion. I'm not sure what it was. Well, I guess one thing that I was wondering is like, what are the biggest hurdles do you think knowing the space so well? Oh, I remember what the other one was too. But the first one is what are the biggest hurdles do you think that you have, like, this is just going to be impossible to build from scratch because.

You know?

Andreas: Oh, what do you think? I think I never really thought of it that way. Or maybe

Aaron: because everything's a standard. Sorry to interrupt you. Maybe because everything's a standard, you can just write to the standard and you don't have to worry about it. I don't know what the answer is there.

Andreas: Well, that's partly that.

So the standards are a lot better today than they ever have been because the various groups that work on the standards, they've been doing a really good job and backfilling all of the stuff that used to be unspecced, used to be sort of browser voodoo mystery stuff. Over the last 10, 15 years, specs have gotten really good.

So if you're writing a browser from scratch today specs will get you a long way, but there are still some things that you sort of have to figure out what other browsers do and then mimic that as well. And. That continues to be one of the more annoying challenges when the specs are lacking. So we ran into something just this week.

And not the first time, which is JavaScript date parsing. So if you look into JavaScript specification, the way that they explain date formats is that there is the ISO. 86 0 1 date format that the spec says you must support outside of that format. The implementation decides what additional formats to support and in practice every other browser supports like a giant collection of random date formats.

You know, like Jan one comma 1972 or Mm-Hmm, one, Jan, 1972. And. There's no list of these anywhere and people have tried to spec how this works, but it kind of just, they just get bogged down and, and they get tired of it and abandon the attempt. So even today, the spec doesn't explain how to parse dates.

And that's been pretty frustrating for us as a new engine. Because we frequently inquire, encounter new date formats that we haven't seen before. And then we have to implement parsing for that particular format. And now the, some websites starts working.

Aaron: Weird.

Andreas: And yeah, then there are, there are a couple of things like that.

A couple of touch points where you have to just look at what other browsers do because the specs, you're just kind of shit out of luck with the spec. But you know, to, to the credit of, of the standards groups, These number, the number of such things has been going down aggressively.

Jonathan: That puts you guys in an interesting position where you're, you're sort of doing an audit of the web specs.

It might be interesting to try to put all of that feedback into a document and, and make it out, put it out there, make it obvious, so hopefully someone could get fixed.

Andreas: Well, we are doing Ubuntu better and we are actively reporting and fixing bugs in the specifications. That is one of the great benefits of new engines coming on the scene is that we end up really putting the specs to the test because people have been iterating on these specs for years, but nobody ever tries to implement them from scratch.

And so we come along and we do that and we find like, well, this doesn't actually make sense. If you try to implement it it falls apart. That happens a lot. Regularly, I would say. We just come across some little thing where it doesn't Have internally consistent logic. And then we report bugs and it gets fixed and that's fantastic.

And it always feels so wholesome when I see somebody from our team go and find a bug in a spec, report it and it gets fixed and the whole ecosystem benefits. So yeah, we are very much auditing the specs and doing our best to be good citizens and, and reporting bugs in specs, or if you find bugs in other browsers, we try to report those as well.

Yeah. Try to be, you know, try to be good boys in the club. Very good.

Aaron: So what, my other question was in terms of the other open source OS vendors, Red Hat, Ubuntu, name your favorite one you know, since, since you've already described how this kind of grew up out of SerenityOS, like, do you, are you getting support from those folks more like you would expect you would, or no?

Andreas: Not really. I didn't really have any expectations though. So there's been some interest in packaging our stuff, but it's so early still, you know, we don't have anything that We could in good conscience, ask an end user to try. So even when distros do try to package our stuff, there's been like I think Arch has some package.

Nix has some package. And I see a lot of people trying these packages and they come to us and they complain that it doesn't work. And yeah, because this is not ready to be packaged. So. I have kind of mixed feelings about Distro's packaging pre alpha software. I think maybe they should just not do that.

It's not a service to anyone. It doesn't help their users and it doesn't help, it doesn't really help the projects they're packaging either. At the same time, it is also exposure for the project and like, you know, sends people our way, just you know, it's, it's, it's, it's, I wish that we would get to manage our own first impression, I guess.

Aaron: Yeah. I'm just surprised that, that, you know, those, those bigger players aren't like, you know, in your sponsors. And I guess there's a, there's an argument to be made like, Hey, most of the browsers are based on open source anyway. So, you know, I grew up in the days of Richard Stallman, well a little bit after when he was really going, you know, but in the 90s when he was still preaching, you know, all that stuff pretty heavily and everything has to be open source and you need a clean release of your distro and.

You know, back then it was proprietary browsers with proprietary code in them that you were fighting against. Now you could make the argument, well, good enough, right? There, everything's open source. It's good enough. We don't need this, but I am a little surprised that some of them haven't come on board and said, you know what we would like to, yes, well, there's a lot of open source out there, but we would like to separate ourselves from the commercial entities of the world, the Googles and the other players, because we don't want to be beholden to them.

So, yeah, I'm just kind of surprised that they're not in the list.

Andreas: Right. Well, they are very welcome to join the list. If anybody from, from any of these entities is listening, please get in touch. We would be happy to have them as sponsors, obviously. And I, I totally feel that way as you described that it's great that we have all these things that are open source.

I think that's a fantastic, amazing development that happened. The fact that all of the most important software on your computer today You can read the source code for it, modify it and publish your modifications. That's fantastic, but We can take it a little bit further than that, you know there are other things that matter too.

And it, I think it does matter where all the, this huge pile of money comes from. And it's kind of like this elephant in the room in a way it's been like that for a long time. I feel in the browser industry that there's been this browsers being developed by hundreds or thousands of engineers, and there's a huge pile of money.

But we don't really talk about like what that money comes from until recently when it's become much more public knowledge and people are starting to see like how much their search search queries are actually worth to these companies. Right. So yeah, that's been really, I think that's been really great.

And it's a really healthy thing that that information is out in the open so that people can start to maybe care about this in different ways other than only like, is it open source or not? There's like other, other parts of a spectrum here that we can care about. Yeah.

Aaron: Yeah. I, I kind of sarcastically.

wonder, like, you know, why did it take so long to get dark mode? And it was because it took that long for someone to figure out the, the, how to monetize or not how to monetize it, but the monetary value of dark mode, like, Oh, you know, we did these tests and we realized that when you have dark mode on, you spend an extra five hours a month, you know, in your browser.

And that means X, many more ads that you see. And that means, you know, so now we have to do dark

Jonathan: mode. And now we know why it's called dark.

Aaron: I, I have to have dark mode. I mean, my eyes aren't good anymore and dark mode really helps. And

Andreas: that's true. So it's

Aaron: like, do you have dark? Let's ask the question. Do you have dark mode yet?

Andreas: We have something like dark mode. So CSS has like a preferred color scheme properties these days. So websites can advertise that, like if the user prefers dark mode, then the sites should look this way. And otherwise it should look some other way. The problem is that there's a large portion of the internet that doesn't specify how it should look like in dark mode. And they kind of assume that the background will be white by default.

The text will be black by default. And if you start to violate these assumptions, then you break some content. So that part is messy. But we, we do have sort of state of the art dark mode. Yes. And I hope that it's something that will evolve further so that even older websites can display consistently in a dark way.

But it kind of depends on heuristics at the moment where we sort of have to just take a guess at what would be a great way to dark modify this website. Right.

Jonathan: I see on the website you talk about things like having a runway of funding and some other sort of business esque terms. And I'm curious, is this a business for you guys? Is it more like a non profit? Like, what does that side of it look like? What's your thought process there?

Andreas: It is completely a nonprofit.

We have no intention of ever selling anything other than maybe a t shirt and a coffee mug or something. But that's a nonprofit. We are a 501 C3 registered in California and we take. What's it called unrestricted donations only so You you can't give us money and tell us what we should do.

You can you can just sponsor and trust us to to do what's right and You know that that does Exclude a certain type of sponsor from ever wanting to support us, but it's okay. You know, we don't, we don't need all the money in the world. We believe, and I believe from experience that a small team can build a competent browser.

It's just you have to focus and you have to be more selective about what features you do. And. Stuff takes time. There's real elbow grease involved, but it should be doable. And yeah, on the sort of business side, there is no business model. It is either we get this thing funded by donations and sponsorships or it falls apart.

And it's a, you know, we're kind of going out on a limb here taking a chance, but we're hoping that We'll be able to deliver something in an alpha version that will make people see, okay, there's something real here, something worth getting behind and sponsoring so that we can actually have this thing for, for our species for and if we can, if we can get it to that point where people see that this is something worth sponsoring then we think that we can continue it and, and perpetuity funded in that way.

That's at least that's what we're hoping to achieve.

Jonathan: What does the community look like? Do you have people on the outside sending in patches? Obviously, bug reports. People come in and complain about things. You can't stop that if you wanted to. But, are you getting patches sent in? Are there outside entities?

Are there any outside businesses working on this? Saying, man, it would be nice if Here's the code to do this thing.

Andreas: Sure. Yeah. We have a fairly large community. So I think in terms of like active developers, we are seven full time engineers right now paid, I think. Oh, wow. That's impressive. So that's pretty good.

Yeah. And and they're all people I hired who were previously open source volunteer contributors. So it's, it's been lovely to be able to take and like give jobs to all these people that showed up and worked on, on Ladybird.

Jonathan: Absolutely.

Andreas: And it's, I would say it's even like one of the coolest things I've ever experienced was just to be able to do something for fun for a long time and then give people jobs doing it.

Yes. But yeah, so, so a bunch of us now are full timers, myself included. And we also have a, an open source community. I think we're usually maybe like 30, 40 active people like contributing multiple times a month. And then a long tail of people. Contributing either, you know, one once in a blue moon or once ever.

So, but it's, it's been growing slowly. And I think historically like working on browsers, as you mentioned, like it's really complicated to build Chromium or to build Firefox and because it's been a really complicated thing it's been a little bit hard for people to get into it, but Our project is fairly easy to get into.

It's a lot smaller than the existing browsers. It builds faster easier to, to learn. So we're welcoming new developers all the time who are sort of working on their first browser project ever. And that's been really positive as well. So I'm hoping to turn them into more frequent contributors.

And I'm also hoping that we will be able to fundraise a little bit more so we can hire a couple more contributors to be employees and But yeah, you mentioned business lingo on the website about runway. And indeed we are trying to be careful with, with the said runway because. We recognize that our funds are limited and the classic startup thing to do would, I guess, would be to hire as many people as we can right now and burn the money for the next six months and see what happens.

But that's not really compatible with our view on how this should be handled. So yeah, we're holding ourselves to a strict, like there has to be two years of salaries in the bank. At all times, because or we should aim to have that before we hire anybody new. Right?

Jonathan: Sure.

Andreas: And if that slows us down, then it slows us down.

But I don't want to, like, when I give somebody a job, I feel like I should It's my responsibility to make sure that that person has that job for a longer time. Then six months and us just burning through the Capitol to, to go faster.

Jonathan: Yeah.

What does the leadership structure look like? Are you a BDFL?

The Benevolent Dictator for life? Or maybe not for life?

Andreas: I don't know. So I was that. I've been a BDFL, but evidently not for life. I was that of SerenityOS until we forked, and then I sort of transferred ownership of SerenityOS to the group of maintainers that That I had previously invited to, to, to do that.

And and Ladybird, I think I'm not really the BDFL. I'm just the the president of the nonprofit that runs the project, but really the project is run in practice by the nonprofit and by the people that work on it, and then Code contributions are sort of quality gated by a group of maintainers, but there isn't any formal structure outside of that.

And I think it's something that will evolve and formalize a bit more as we get closer to, to releasing stuff. Or as, as our organization structure grows, but at the moment it's very like flat structure. Everybody's welcome to work on everything. Nobody is like.

We, everybody just kind of finds the thing that matters for making the web work in the browser and then they focus on that. It's possible that we will change that. We're kind of in a luxurious period right now where you can sort of like you, you, you throw a bug fix anywhere in the browser and it's, there's a real chance that it fixes some important website.

So And the future is going to be, you're going to have, you're going to have to look harder for valuable things to fix. But yeah.

Jonathan: Yeah. Interesting stuff. Aaron, did you want to jump back in? We're getting close to the, close to time. You want to make sure we're getting

Aaron: close. Like, I guess I don't want to jump too far into the weeds with this one, but maybe I'll just open up the can of worms anyway, and we'll see where it goes.

Jonathan: Just crack it. Let the, let the worm air out and not near the worms.

Aaron: Yeah. Sometimes these questions go in, in, in weird directions, take a long time to answer, especially for novices like me. But the question is architecturally speaking, like, what would you say are the biggest differences or even like some of the things that you, that you're seeing maybe some indications of like, this is going to be a game changer.

In terms of technology and how we're developing this, because we don't have to conform to. whatever chromium webkit, but we're able to do it this way. And that makes a big difference.

Andreas: Right. Architecturally, what are some advantages? I guess one thing is that we have a lot of flexibility right now because we're not big and complicated yet.

And there are a lot of features that we haven't implemented yet. And so we don't have like a gigantic code base that has to be retrofitted to do. Some some like security mechanism, for example. So like every other browser, they started out as a single process browser. But we started building our browser after multiprocess browsing was a thing.

So, we were able to get that stuff in pretty early. And as a result, we don't have a code base that, I mean, we were single process originally, but we were able to make ourselves multiprocess pretty quickly because we didn't have a gigantic code base with millions of lines of code that had been shipping in a single process way, you know, for decades.

And then we had to retrofit multiprocessing into that. And I, I think we have a lot of opportunities still to do interesting architectural things for, for security, for stability, for performance that are much harder for other browsers because they have so much code that, that just has to be changed in complicated ways, let's say.

Yeah, that's, I think that's our biggest opportunity.

Jonathan: Yeah, pretty cool. Why, why C Why with a new browser? Did you not write it in Rust or Go or some other everybody's favorite language?

Andreas: Right. Well, I guess there's no language that everybody loves, but everybody loves to hate C lately. And we started, I started SerenityOS in C because as I mentioned, there was a, it was a personal therapy project.

So I just. So the language that I knew the best and was just doodling around. And then I didn't mean to, but, you know hundreds, thousands of people ended up wanting to work on it also. And then it kind of just you know, I got a little bit out of my hands. And now we have this gigantic code base written in C plus plus.

And we have a lot of things going on and we want to find a way forward where we can You know, feel like we're doing our best by our users in the future, that like we're doing our best to deliver something that's safe and secure. So in practice, that means that we have to, we probably have to evolve past C in some way.

Because C is not evolving towards safety as, as fast as we would like. And so I don't know. We've looked at a bunch of the different languages recently and ended up with Swift as a secondary language to introduce into the code base. Not everybody's favorite choice, but we did this experiment where I asked people like, please try to implement some part of the browser in a couple of different languages and then tell me which one you like the best.

And. Everybody came back liking Swift the best and fair enough. It was a, it was an empirical process and I had the same experience. I liked it the best out of the languages that we messed with. And so we are aiming to introduce that now with the new version of Swift that is coming out in the next couple of weeks.

And the idea there is to have a safe language that we can incrementally introduce into the code base because Swift can talk to C and vice versa. And that's kind of, that's kind of our plan there, but it's going to take time to do that. But it's something that we feel like we have to do something because.

You know, safety is a thing people do want to hack your browser and we probably have more bugs than we know. I'm sure we have more bugs than we know. And if we could like systematically prevent many of them by using a safe language, that's something that we, we definitely need to pursue. But yeah, we are still like on square one with that because we're depending on the next version of Swift because it's the first one that can actually understand our super modern C that we've been using.

Yeah, so that's kind of where that's at. And I know that there are a lot of languages that people always ask me like, why didn't you use my favorite language? Or why didn't you use this language? And I just never engaged with that because I feel like Nothing good ever comes of, like, criticizing somebody's favorite language.

Right?

Jonathan: Yeah. Yeah, that's fair. Have you, have you been in So first off I've got to think there there are people out there to go Swift they went with Swift. Oh, they're selling out to Apple. That must be what that is Yeah, you've gotten much pushback from that.

Andreas: I Have been told by many people that like congratulations on the Apple money

But No, we haven't the the We were acknowledged in the sense that I think the the head of the DevTools department at Apple tweeted at us saying something like, cool. But that was it. Yeah, no, we're not, we're not selling out. It's just, it just so happens that Swift has a really compelling story as like a C plus plus successor language.

Like that's something that they're investing in. Yeah. Sort of this narrative of like, Hey, do you have a huge C code base and wish you could be safe, but it's just too much to just rewrite everything? Here's Swift. You can rewrite incrementally. That's really compelling to us. So.

Jonathan: That's interesting from the kind of the standpoint of looking at the language too.

This is something we're seeing with Rust as well, where they're putting Rust in the kernel. It's forcing Rust to grow up. And. If they gain traction with that, with Swift, trying to get other C developers to use it. And maybe Ladybird will be part of the story too. Putting it in use, they're going to find places where, oh, this thing in Swift is not working quite as well as we thought it did.

Or there's a bug in trying to make this work. I think that could be really interesting going forwards, as you guys I'm assuming you will try to, you know, kind of work closer with the devs from the Swift language. And it should be a good thing for like both projects.

Andreas: I think so. We've already found and reported a number of bugs and have had a good experience interacting with a Swift team so far.

So that's, that's really positive. And I think it's absolutely the case that, you know, whenever you take a language and bring it into a new domain where it hasn't been tried before, you're going to find tons of interesting and. Not interesting problems. And we've had a lot of not interesting ones also.

I will mention like trying to get CMake to understand how to build.

Jonathan: Oh

Andreas: it's not very interesting.

Jonathan: No, it's just pain working with compiling tool changes. Just pain.

Andreas: Yeah. Thankfully though, we have somebody who, who derives. Some amount of pleasure from, from working with build systems. So I'm really grateful that we have Andrew who's been figuring that out.

But yeah, no, we're, I think a lot of good things will come with that. Just like you mentioned with Rust and Linux and everybody has to grow up a little bit, everybody has to compromise a little bit But usually something good can come out of that.

Jonathan: Yeah.

Andreas: I think it will be the same for us.

Jonathan: Absolutely. Is there anything coming down the pike that you are particularly excited about in Ladybird that you want to want to plug, let folks know about?

Andreas: Well semi related, I'm running a a coding jam this weekend called Browser Jam.

Jonathan: Perfect.

Andreas: Where people are invited to come and we're all gonna write a new browser over the weekend.

Oh. And I don't think it's ever been done before. People do game jams where they make games over a weekend. And I We thought that we could do a browser jam where everybody makes a browser. So the idea is, you'll show up on Friday afternoon, and we will give you a piece of HTML, and then you have a weekend to build a browser that can render that HTML.

We'll see how that goes. But if you're interested, you can go to github. com slash browser jam, and you'll find the information there. That's great. That's a lot of fun. That's

Aaron: kind of fun. I mean, you know, that's what, I mean, that's what I like about doing that kind of stuff with HTML. ESP 8266s and 32s in the Arduino, like, stack just to like, you know, you don't need much there, right?

Kind of like the project you were talking about before, Jonathan, where I just need to read an HTML page and maybe some little JavaScript and make it work, you know? And if you can get to that point and understand how it all works, that's a great learning project. I think it's

Jonathan: Absolutely. It may be early in the project for this question, but is there something that someone has done with Ladybird that just really surprised you?

Like just off the wall or odd or, or other otherwise surprising that somebody has used it for?

Andreas: It might be a little early for that. Yeah. But I am frequently surprised whenever somebody gets some really complicated website working. I am just so surprised that we're already at the point where we can like do Facebook or we can Log into YouTube or things like that So it's more like i'm just continually surprised at the progress that we're making it's been really inspiring and especially because i'm Maybe not.

Yeah. We don't have a lot of people with previous browser experience on the team. It's me. And then a couple of people have been contributing a little bit here and there, but most of us are like complete noobs at this and just sort of learning as we go. And the fact that relatively or very inexperienced team has been able to assemble a browser of, of even this quality level in this timeframe is I think amazing.

Jonathan: Yeah.

Andreas: And I'm really proud of, of the team and, and it's been awesome to get to see people grow. Like we've had people join the project when they were like 16 and they're now in university and still hanging out and chatting and like fixing stuff. And that's been a, it's been a lovely process to witness.

Jonathan: Yeah. Question from the chat room, mashed potato wants to know, is anyone live streaming the browser jam event? Is there some place where we can watch people code in real time?

Andreas: That's possible. I don't know. So we're, we have a discord server where people are coordinating a little bit, making teams and stuff like that.

And I saw some people were talking about the possibility of live streaming. So if you're interested in that join the discord it's on the github. com slash browser jam. And yeah, see if, if somebody there is streaming, hopefully somebody will.

Jonathan: Sounds fun. We are, we're getting down towards the very end of the show.

Is there something that you, you wanted to mention to folks that we didn't ask about? Did we miss anything?

Andreas: No, I think you covered a lot of the stuff that's important. And I'm glad that I'm glad that we talked about the issues that exist in the industry. I feel like it's easy to, To forget to acknowledge that, but it feels like we're in this new reality now where we acknowledge that browsers have been funded by Google and it's no longer a secret that only some people know about, but like it's something that everybody understands now and we can start to look.

Real solutions to, to that. And I think we're trying our best to offer one possible solution. And we would be very happy if, if people experiment with other solutions. I don't think that Ladybird has to be the only new browser. I know that there are some other. Up and coming browser projects as well.

There is the Servo project they're doing browser engine in, in Rust. Mm-Hmm. . And they're very big on sort of the embedded use case. And I'm glad that they're exploring in that direction. And I think there's room for more. I'm, I'm really hoping that there will be sort of a, a new age of new browsers.

I guess that would be really, really fun. As a, as a fan of browsers, I would love to see that.

Jonathan: Yeah.

Andreas: Yeah, so I guess shout outs to Servo for for also going down this path.

Jonathan: It, no, no, that you mentioned them. I'll have to see if I can reach out and get somebody from Servo on the show too. Cause that would be a lot of fun.

All right. So before we let you go,

Aaron: one thing before you drop, what's the best way, easiest way for people to get involved or the best way to get

Andreas: involved? Right, of course. So the easiest thing you want to start with going to our GitHub repository. So it's at github. com slash ladybird browser and join our discord server.

That's really where all of the day to day coordination happens. People like working on stuff together or discussing bugs. It's fairly pleasant space. People are very nice, welcoming, professional. And as I mentioned, like we're welcoming new developers all the time, so you won't stand out or be weird, even if you don't know what you're doing.

Join our Discord and come chat. And what I usually tell people to do if they don't know where to start is to Build the browser, and then go to a website that you made yourself. Hopefully you have something. Hopefully it's pretty simple. And see if it works correctly. If it doesn't try to figure out why.

And see what you can learn from it. And maybe you can figure out how to fix it, but at the very least you can make a pretty good bug report even if you can't figure out what to do. Yeah, and then take it from there.

Jonathan: Yeah, very cool. All right. Last two questions that we are required to ask or the chat room gets mad at us.

And that is what's your favorite text editor and scripting language?

Andreas: Oh, well, it's, I don't know what my favorite text editor is, Vim. And I, it's just muscle memory, I think, even if I, I've tried to install other text editors, but I never used them because to start a text editor, I just type Vim. So there's that.

But I, I tend to program in IDEs. So like I do like in practice, a lot of my text editing of source code, I end up doing in like the JetBrains IDEs or VS code or something like that. But on the command line, it's always Vim. And then scripting language. Oh, scripting language, right. Probably has to be JavaScript, just because I keep working on it every day.

And, or no, I'm going to tell the truth. My favorite scripting language is PHP. And I'm not ashamed.

Jonathan: Well, having a background as a C programmer, PHP is kind of friendly towards the whole C style of bracketing and all of that. So that's not terribly surprising.

Andreas: Yeah, true, true. But it's terribly out of fashion, I feel like.

Jonathan: Oh, it is. It is very much out of fashion. But PHP still holds a place in my heart as well.

Andreas: Yeah, it's like, it's like Perl, but slightly more modern. Just slightly. Tiny bit. Tiny bit. Yeah.

Jonathan: All right. Hey, this has been awesome, and we sure appreciate you being here Andreas, and thank you. Thank you for your time. Thank you for telling us about the project. Yeah, thanks for having me guys. Yeah All right.

What do you think?

Aaron: Yeah, it's pretty cool. I love learning about these projects early on, you know, and having the opportunity to kind of get in on the ground floor, so to speak. You know, I often, I often tell When they ask people, when people ask me, what, what is Floss Weekly? You know, I have to explain it.

I'm like, well, you know, we talked to the Kubernetes guys, like when they were still at Google and the project was just getting started. Like that's a big part of what. Over the years, just organically, I think has happened because people want to come on the show and talk about their project when it's in the early stages.

So it just kind of works out organically that way. But the benefit for us and for listeners and viewers is they get to hear about these projects and get involved. You know, on in the kind of the early stages and

Jonathan: yeah, I think this

Aaron: is another great opportunity like we we We've just come to the point where everything has consolidated so much in the browser space that we just need another alternative if for no other reason than to have another alternative.

So we're not locked in. So yeah, I think it's a great project. You know, I guess stay tuned, right? Like either, either go try it if you're the type that. Likes to build things, build your own software, then go try it. And if not, then wait a little bit and come back and check it out in, you know, another six months or a year when there's a beta version or something.

Jonathan: Yeah. You know, I was thinking as we were talking so much of computing now is just the web. Right. And so we used to talk about, you know, your favorite. We still, we asked everybody that's on the show, like, what's your favorite text editor? We do so much work on the web. Maybe we need to start asking people what their favorite browser is.

But to kind of carry that, that thought through, you have different text editors for different purposes. And I could, I could see a future where you have a bunch of different browsers for different purposes that, you know, are not all just reskins of Chromium, like we started the show talking about. So yeah, no, I think this is, I think this is really cool.

And I really do think that there are going to be Some really interesting, maybe niche, but some really interesting use cases where it's going to make a lot of sense to run Ladybird or Servo rather than Firefox or Chromium. Yeah,

Aaron: yeah. I like the ones you came up where the, the one that you came up with, and I think that branches out into others where you need to run a kiosk or you need to run something and you don't want to be encumbered with maybe even the fear of the unknown, right?

Like who knows what. Chrome is going to do or Chromium is going to do how it's going to change. Right. You need something stable. You need something that's going to be, you know, you can count on. And yeah. And, or I just want to, I just want to run a kiosk, like you said.

Jonathan: Yeah, definitely something to be said for that.

All right. Did you want to plug anything, Aaron? I know you've got that, you've got at least a YouTube channel, which you'll mention.

Aaron: Yes. I will give you a preview quickly of an upcoming video. It is September. So I've got two channels. I've got the main channel, which is RetroHackShack on YouTube. And I've got RetroHackShack After Hours, where I do e waste Wednesday and a bunch of like smaller, like maybe slightly less interesting to the broader audience kind of things all around vintage computing.

But on the main channel, what I've been working on for months, people don't know behind the scenes how long these history video takes, history videos take, but I'm working on a history video. It'll be relatively short, but on the history of the Tandy

Jonathan: 1000.

Aaron: So the Tandy 1000 was kind of. They kind of fell into this position of being a major player and having a really successful product because of the failure of IBM's

Jonathan: PCjr.

Aaron: So it was really interesting history where Tandy came along and they said, Hey, we're going to make a PCjr competitor. And then PCjr got discontinued. And they just happened to have like all the features that people wanted at that point and ended up being a super huge important and for a lot of people either their first computer, their first family computer, you know.

So that video should be coming out I'm hoping by this weekend, fingers crossed, but they just, those history videos, you have to go in and get credits for all the images and all that kind of stuff. And it just, it just, it just takes a long time to do. So yeah, be on the lookout for that.

Jonathan: And it's RetroHackShack and RetroHackShack After Hours.

Aaron: Yep. Yep. RetroHackShack everywhere. Just search for RetroHackShack on your social things or on YouTube and you'll find it.

Jonathan: Yeah, awesome. Alright, I do want to let folks know that next week it's, we're back to Java! And it's JBang, which it lets students, educators, and professional developers create, edit, and run self contained, source only Java programs with unprecedented ease, which, Sounds like we're doing Java for scripting, which that'll be really interesting to talk about looking forward to that.

So that's next week. Make sure and catch that you can follow me. Of course on Hackaday, we've got, well, that's the home of Floss Weekly. That's also where my security column goes live every Friday morning. There's also the untitled Linux show that's over at twit. tv at the twit network. And we have a lot of fun there talking about what's going on with Linux, the news, some open source stuff there as well.

And then. You can also keep an eye on my YouTube channel. You can search for me. I think it's Jay Bennett at YouTube. And some fun stuff mainly around Meshtastic, which we're about to have a big 2. 5 release the, the first alpha of that come out as some really exciting stuff there. So check that out.

We sure appreciate everybody that's here, both that watch us and listen to us live and those that get us on the download. Make sure to come back next week and we will see you then on Floss Weekly.

This week Jonathan and Aaron chat with Andreas Kling about the Ladybird, the new browser in development from the ground up. It was started as part of SerenityOS, and has since taken on a life of its own. How much of the web works on it? How many people are working on the project? And where's the download button? Listen to find out!

- https://ladybird.org/

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/

Jonathan: Hey, this week, Laurie LaRusso and Steve Hoffman join me to talk about Percona, the open source database solutions company that after all this has managed to keep open source, we talk about how and why you don't want to miss it. So stay tuned. This is Floss Weekly episode 799. Recorded September 3rd, still open source at Percona.

It is time for Floss Weekly. That's the show about free Libre and open source software. I'm your host, Jonathan Bennett. And today we're talking about Percona. It's an open source database software. It seems like anymore. It's one of the few opens big open source database solutions that still actually open source goodness.

I think we're going to talk about that just a little bit during the show today. I, I don't know much about Percona. I, I kind of have to admit my database experience is sort of just My SQL and SQL light and a tiny, tiny bit of fighting against Microsoft SQL. It's been, it's been something because of because of things happening outside of our control, I am the host and co host today.

So that's going to be just a little bit different, but we've done it that way before. It's, it's not going to be a big deal. But let me go ahead and bring our guests on today. And we've got Lori Lorenzo and Steve. Hoffman and we talked a little bit before the show and Laurie, you are the, the community manager and Steve is sort of the, one of the VPs of, of technical.

Is that, is that about the way that, that lays?

Lori: Yeah. So just, my name's Laurie LaRusso, like Karate Kid LaRusso and yeah, I'm head of community at Percona and yeah. Yeah.

Steve: And I'm, I'm one of the engineering managers or engineering leads here for Percona run the the development side of the house. So, Loray and I are joined at the hip.

Jonathan: I, I understand. I know how that goes. So, let's, let's talk for just a minute about, I guess the technical side is where we'll start. And, what, what is Percona? Like, how is it different than, you know MariaDB? Or any of the other database solutions that are out there? What's, what's the kind of the, the thing that makes the difference about Percona?

Steve: So it's not wildly different than MariaDB's original model. We both took a fork of MySQL and, you know, added our own features to it. What we think, you know, was the, the answer to the needs of the market, you know, from an enterprise standpoint. We've also since done that with MongoDB and we're also working in the Postgres space as well to bring new features on top of an already great base.

So in that sense, not wildly different. I think. You could say we're similar there, but then I think we go a lot further than them. So we also have our Operators product. We also do our, our monitoring and management suite. So maybe we have a wider portfolio, but I think it's fair to say MariaDB model is similar to Percona.

Okay. And

Lori: so this is where, let me just jump in. This is where I think Steve is being humble and that's why you have a community person to back him up. So, you know, I think the, what you're missing is the innovation, right? So we have community editions of MySQL, of Postgres but what we do We make them better, and we're open source.

So, we take, we take the regular edition, we open source it, and we add in our little spice to make it better for users.

Jonathan: So is, is Percona a database? Or is Percona a database company? Or is it both?

Steve: We like to call ourselves a solutions company. We produce database software, and and you can get it in all different formats, but we make the majority of our money on the services that we provide.

But when you take our software and our services and sort of smash them together, you get sort of the overarching Percona solution.

Jonathan: Okay.

Steve: You don't have to use both, but I think that's where you get the best value is our software with our services. We can, we can help you run it better than anybody else.

But if you're using, let's say a community edition. Of either Mongo or Postgres or MySQL. We can still service you but it's just, you don't, you don't get the full value. Okay.

Jonathan: And, and, I, as you, as you work on some of these pieces of software I'm sure, so you make software changes to them, you make changes to the source code, because it's source available without being an open source.

Do any of those changes ever get pushed back up to the original project? Or do they kind of all stay siloed in your, I mean, obviously it's open source, but still, you know, there can be either an effort or not an effort made to push them up.

Steve: Yeah, I mean, we like to contribute everything that we do. Now, we have learned over the years that certain things aren't really necessarily welcome or valuable back upstream.

In many cases, we're actually building enterprise features that already exist in the upstream's enterprise product. So, us contributing that backup there, you know, they don't want that. But we do bug fixes, we do, you know, extensions and enhancements all the time. And again, we do it all, make it as open as humanly possible.

Direct contributions. You know, and hope that we get it included in, in upstream so that it just everybody gets to benefit from the change.

Jonathan: Yeah, I mean, every, every change that you can make upstream is just one, one fewer change for you guys to have to be the stewards of. That makes sense. That's, that's kind of interesting that you're re adding some of the enterprise features that have been not added intentionally.

Is there, is there any animosity from any of the upstream vendors because of that?

Steve: I think on the community side, there's no animosity. I can't even say that I'm aware of it on the enterprise side. I'm sure, you know, if Percona got way too big, people that haven't taken notice certainly would, but we seem to have a great relationship with the MySQL community, certainly the Postgres community.

And Mongo, you know, I mean, I don't think we have each other as adversaries. Business wise, surely we're competitors, but I don't think it's. I've not received any death threats, I don't think any of you on the team have, so

Jonathan: we're good standing there. You've managed to remain friendly competitors, that is handy.

Yeah, exactly. That's fun. Well, but the database world seems to be sort of cutthroat these days. We talked just a little bit before the show about like all of the different licensing changes that have happened and forks because of it. And it seems like, well, no, I know one thing that has happened is you'll have a company that they have a database, like they have their secret sauce in their database.

But instead of making it all secret, they've made it open source. And so they've got this database code that they work on, and then they also offer it as a service. And like, that's great until Amazon comes along and says, it's open source. We can offer this as a service too. And suddenly this, this, this business that does open source, like their revenue stream starts to die, dry up.

And they immediately go, we've got to make some kind of change to be able to keep making money. And it seems like in a lot of cases, the change they make is we're going to use a business source license of some sort. And. It, it, it, well, it fractures the community. It, it inevitably results in a fork, you know, like Redis and Valky.

We, we now have Valky because Redis did the exact same thing and they, they, in their wisdom, they made this decision and they made the announcement to you. Move away from an open source license with Redis during a, I think, a Kubernetes conference. And so there were a bunch of people that were using Redis all together in the same place when this was announced.

And apparently by the end of the conference, they sort of walked away going, Yeah, we have a gentleman's agreement to make a fork and call it, you know, all get on board with the same fork. But it's just it's got to be it's got to be cutthroat.

Lori: Is it a

Jonathan: cutthroat environment? Have you seen that?

Lori: Let me take your, your Amazon example for one.

And I think that's where you come up with strategic alliances, right? That's where you really work within, I mean, it's a cloud company, right? It's a hyperscaler. So if they can. That's what the marketplace is for. If they can package up what we do and add it to what they're doing, I think that's a win for both, right?

So the way that we treat our core customers, the level of service that we provide is super unique. So to have a place for us to, a platform for us to list out like our version of MySQL or Postgres, I think it's, it's a win for both. And then when you think about how the community kind of rallies around, you know, open source and wanting to keep things open I think For me, the biggest shift I saw was when Terraform went closed and there was a manifesto.

The community was so irate that they came up with a manifesto. And then from the manifesto, like they ended up The, the name of the project now is OpenTofu, but it, it started, I think it was OpenTF and it's underneath the Linux foundation, just like Valky is now underneath the Linux foundation. And I think when you have something that's open, that people use it and adopt it because it's open and they build their businesses off of it because it was open.

And then you close it.

Speaker 4: Yeah.

Lori: Then you have like this big community uprising, specifically if it's something so popular, like Terraform or Redis and to be a company, to work for an open source company like Percona that is there to carry the open source flag and say, okay, so Val Redis closed source, guess what, we're going to be a part of Valkyrie.

Like we're the only ones that offer, you know, like on prem support for that. And in that look at the other companies that have joined Valkyrie. You've got your AWS, you've got your Google, you've got your Oracle. So it's like. All of us working together to have a piece of this pie, if you will, in open source land, I think it's, it's, it's really awesome to be a part of a company that supports open source, that it's that core to who we are.

Jonathan: And so is it fair to say that Percona's business model is not simply hosting databases for companies? There's more to it than that.

Steve: Yeah, perfectly fair to say. What's the, our model is actually you hosting your own database. So we give you the software that lets you. Run it on whatever your infrastructure is.

So if you want to run it on prem, if you want to run it in the cloud, if you want to run it across multiple clouds, we, you know, we actively support and test all of those scenarios that's given the power to the, to the people. Yeah, yeah. And

Lori: I, and I think what we do is we help you level up, right? So we have not only the innovations that are coming out of engineering, but we have the experts in our support and our managed services.

So if you are trying to elevate, if you are trying to do something and you realize you don't have the staff or the support in house, that's where we come in. So having that, that like hand to hold you through a migration or to help you tune your database so that you're getting the best results to take your database and put it on the cloud with our new product, Everest, like just because we're open source doesn't mean, you know, that we are a less than we are actually like a

Jonathan: No, absolutely.

I agree with that. I, I think part of the problem is that so many companies, they, they love the open source model, but they've not really figured out how that model actually ties into their business model in a way that makes sense. And sometimes they end up sabotaging themselves. And it, it sounds like Percona has managed to avoid that.

So that's, that's good. That's a good thing. That's a good, good sign for the future. We just celebrated

Lori: 18 years. Oh, wow. Right, Steve?

Steve: Yeah. Yep. 18th birthday. We became an adult. Percona can now legally Drink and phone? Do what 18 year olds do. Well, just different in every country as we learn. We did a poll internally about turning 18.

It was like, wow, it's amazing. Globally 18 means different so many different things around the world, but that was a lot of fun

Jonathan: What was what was the beginning of the company? What was the what was the first thing that percona did was it was it literally my sql stuff My

Steve: sql

Jonathan: phone support. Yep phone support really Ah,

Steve: so so our our our co founders were actively taking calls from customers to help optimize their databases.

So they were a consulting company. So if you think about Percona, it's a per con performance consultants and dot com was taken. So per con a dot com came to be. So yeah, little, little trivia history on our name, but yes, Peter and Vadim took many, many phone calls. I think, I don't know the exact date, but we have a book.

That they put out at about the 14 year mark, or maybe it was the 13 year mark that said, like up until at the time, eight or so years ago, they were actively taking phone calls from, from customers who were having performance issues. Fortunately we have enough staff, we have, you know, smart enough people that they don't have to anymore, but that's how we got our

Jonathan: start.

Oh, that's, that's great. That's, that's a lot of fun. And, and so what's the, like what's the portfolio now? What, what are the different databases that you guys will. Still take support calls for her.

Steve: Yeah. Yeah. I mean, we're, we're active. Like I said, my SQL is what most people know us for MongoDB, probably second.

But then we, you know, we're very active in the Postgres space and getting more. So every day and then from there, you know, where you choose to run it, we support, like I said on prem bare metal installations, cloud installations. We create operators now, so you can run this in Kubernetes. So in your orchestrated environments.

Which we're seeing a ton of traction there. We're now releasing you know, if you think of Amazon's RDS is sort of like database as a service, you know, point, click, get a database. We have an on prem equivalent to that in our Everest product. So it still uses Kubernetes and work and operators underneath, but it gives you that that single API that you can call and wire into your CI CD or.

Or, or turn over to your, to your developers and let them point, click and create databases as opposed to having to know all the, you know, behind the scenes commands.

Lori: And you forgot Valky. So Valky is our latest database that we're going to support.

Steve: Yeah. And Valky, we are only, we only support it. We don't actually build our own version of it.

We contribute to it. We're, we're active in that Valky community, but there's not like a Percona fork of Valky. So Valky, we, we're trying to. Support that community not compete with them by any stretch,

Jonathan: right? And so i'm sure you could you could imagine a future where You have a slightly different take on something and you do end up having an in house valky fork.

But I i'm sure trying to avoid that if possible, right? Yeah.

Steve: Yeah, I can't imagine that future I don't really see it. I don't ever see it as good right like I mean it it If we're really community, right like and we mean it then We find a way not to fork now. I can't fault any of the projects that have had to go, you know, go their separate ways.

I know there were certainly valid reasons, some of them personal, some of them technical, some of them vision, but I don't know that that's always the best outcome. So for me, that's like the last thing. If we've hit that, hopefully we've exhausted all options because, you know, to take to take a thriving community and effectively split it in half It's gonna slow, slow innovation down, right?

That's one of the beauties of open source is just how fast we can innovate when, when all of us are focused on the same thing. So again, I'm preaching here. This is just my personal belief, but yeah, I don't, I don't love that, you know, direct competition with each other. If we, if we Percona fork, first and foremost, we want it to be to help innovate and add back to the community.

But in some cases when that, you know, when that, when that takes its turn, like, you know, for us, we do have a fork of MySQL. Oracle Enterprise isn't going to accept our LDAP authentication. They have their own, right? They don't need us, but, but we do feel that it's good to bring to the community. So I think, like I said, we do it for a slightly different purpose.

Jonathan: And so, for example, we've talked about Everest a couple of times. So that's, that's fully open source. If, if somebody wants to just host their own version of Everest and not have to pay you guys anything for the contract, that's out there as an option. And then your, your business models, essentially, this is a complicated thing to do.

We suspect that eventually some of these businesses are going to want to have support for it.

Steve: Yeah. Yeah. I mean, that's been our model is if you've got the manpower, the time and the talent to do it yourself, you Our software is free and open source. If you don't, we can certainly help with that. You know, that's been our model and that's fortunate for us that our business model has been successful enough that we've been Continually growing and continually profitable company since the beginning.

Jonathan: Yeah, well, so I mean that that business model has worked for other companies over the years That's essentially what red hat was founded on and it it grew them to be a billion dollar business so there's there's definitely nothing nothing wrong with that And that is that is proven out to be a a winner a winner in many industries at least yeah, that's very neat.

So I'm, i'm curious in addition to that. Do you ever get someone say You Call you up and say, Hey, it would be great if my sequel did this. It would be great if Postgres had this feature. Can you give us a quote on adding that to the code base? Does that happen?

Steve: That's

Jonathan: only on the days that end in

Steve: Y. Yeah, we get, we get that a lot.

Like every customer has a unique need. You know, that. This is the way our business works. We need this feature, you know, and we have a product team that does the evaluation. Is this solving a problem exclusively for you or is this a problem that many, many people are experiencing? And by creating it, we can we can benefit the broader communities.

We try to stay on that, that, you know, community based side where we're looking for large swaths that would be impacted for the products. And that's not to say that we don't do some, you know, custom stuff. We have some customers that have specific needs. If the ask isn't huge. We put it in there. And there's a, there's a monetization model for that.

I mean, sure. But I

Lori: think that is that is the value of having community live under engineering as well, right? It's this feedback loop. So as many customers as we have, as many conferences as we go to, being able to have the pulse of whatever community we're in, if it's like an all things open, it's just a general open source.

Speaker 5: You

Lori: know conference, but if it's a PG comp, we can really focus our attention to that particular language, that particular particular database. I'm sorry. And, you know, really work within that sort of feedback loop. What are we doing? Well, what are we missing out on? Like here is a talk that we're giving that talks about why we decided to do this, you know, and And I think that's where community wins, right?

Again, Percona being an open source company and community has always been at the forefront of what we do. And then being able to really like zero in on the events that we go to and having like a forum where you get answers, having a very good resources within Percona to give that knowledge out to the community is a win win.

Jonathan: And so that does kind of lead onto another question about that community effort. What, what does it look like as far as in, in these places where you guys are the, the, the source code, like you have your own. Your own repos for this. Do you get a lot of patches and work from the community? Or, or is it pretty much just a a one way street where you guys do the work in the community or you're out there using it?

I

Steve: mean, I can tell you we get a ton of contributions. And, and, you know, community contributions don't always come in the form of long lines of thousands of code changes. Sometimes it's improving our documentation. Sometimes we get a lot of community give back on our forums where they'll come in and answer questions for, you know, for the masses.

Like, how do I set this up? How do I use it? I'm getting this error. So we're very, very active on that front. That's one of the things that shocked me. I don't. come from open source, like, you know, way back when this is something within the last five years for me, but seeing how active our communities are is the exciting part because number one, that the entire burden doesn't fall to us because I think if it did you know, and maybe this is where some companies go wrong is you know, the community is not paying your bills.

So you tend to favor the ones that are but because we have such an active community, it allows us to work together. And, and accept code contributions, accept documentation updates, accept you know, answers on the forums, things like that.

Jonathan: Are there, are there any, are there any rough spots? So I'm, I'll give you the background to what I'm thinking here.

I'm part of an open source project and we just recently got sort of called out in our one of our, one of our places where people can ask questions. One of our forums of essentially you guys made this big change and you didn't ask us about it first. And it's, it's been a little bit of a thing because like there's, there's a couple of ways you can look at this.

For one thing, almost every open source project is a meritocracy to some extent. And so, one of the answers that we give is, if you guys would like to see changes, come write source code. Come be a part of Discord, where the, where the developers are talking so that you can give feedback. But it's really, it's really become a little bit of a source of friction.

There's some other things going on, but not important. Of course, it's always more complicated. Yeah, but I'm just curious. Do you guys, have you guys had any of that kind of friction and how have you solved it?

Steve: We, we have our own forms of it. I don't think we've seen that specifically, but with, you know, every, for the products, That we are in control, like PM and Percona monitoring and management.

We don't have an upstream necessarily beholden to, I mean, we do have you know, a copy of Grafana in there that we base it on. But, by and large, we're driving the, the roadmap. And a couple of times we'll deprecate a feature or, you know, we'll put something in that ends up not catching on and so we sort of abandon it or start pulling it out.

And so we definitely hear about it.

Jonathan: But I think I think it's impossible to deprecate a feature without someone coming along and saying, Yeah. That was part of my workflow. You know, it's the XKCD comic about holding down the spacebar, heating up your CPU. That was part of my workflow. Put it back.

Steve: Yeah. We get that, right? Like, but you realize we took that out because there's a better way to accomplish this. Right. And so most of the time we luck out with, you know, sort of a re education on it. We, we didn't Take something away without giving you something back. Here's, here's why. And, you know, it hasn't ended sourly.

I can't say that people are like, oh, thank you for that. But they, they at least walk away with an understanding of like there, there was a rationale behind it. It wasn't. Who can we piss off today, you know?

Lori: Also, I think it's a it's a matter of communication, right? Like it's a matter of giving people warning letting them know what's going on being able to have you know I don't want to say standard talking points but you know those standard talking points as to like this is why we did it and because you you don't want to Detract from the end reason, right?

Which is maybe there's a better way, or when we actually looked at our logs, nobody's using this in terms of like the hand scheme of things. So having a good communication and like Steve said, like having the forum as a place where people can converse, you know being able to kind of contribute back, submit issues that I think is, is key to keeping the community Safeguarded from some detractors.

You know, it's always the, the small group can sometimes make the loudest noise, but when you're just very transparent, like in the whole methodology of being open source, I think, you know, you end up just winning long term.

Jonathan: Yeah. I was, I was going to ask you, Laurie, to, to speak to this next, because sometimes the community people can be on the other side of the fence from engineering.

And if there's not, if there's not decent communication between those two teams, they can be actually working at cross purposes. What, what kind of things do you guys do to make sure that doesn't happen to make sure that the community team, so this is something that just recently happened to us the community team got surprised by a change that the engineering team made and it's like, Oh, that's gotta be a bug.

We're sure to get that fixed. And then the engineering guy is like, that wasn't a bug. That was an intentional change. Like, please tell us about these things. How do you, how do you, how do you avoid that? Yeah.

Lori: Well, I love that my dog just started barking. So I apologize. Hopefully it won't

Jonathan: be

Lori: too much in the background, but I'm very happy to say that at Percona community has moved under engineering.

At other companies that I've been to, community has always fallen under marketing and that's where you get the disconnect, right? Because marketing has marketing objectives and engineering has their objectives and when there isn't open flow communication across the board, Then you have those issues where you're like, wait, I'm presenting the wrong version of something or I didn't see the release notes.

Nobody told me. And it's it's a communication issue. And so I know, don't laugh. It's she's old. She's 14. She doesn't know what's happening. She's just like, why is mommy talking to a computer? So So now that community has moved under engineering, it's so much better because we are on all of the product updates.

We are looking at the roadmap. We are making sure that we are dropping breadcrumbs to innovations that are going to come out in like four or six months, right? We're letting the community know like why we're thinking the way that we're thinking, what our engineers are doing. And then with that, you know, we have, Surveys that are just product led surveys that are just like, we want to know what version you're using.

What is this? Like, how is this working out for you? Like, what can we do? And so keeping a really tight feedback loop like that is where I think community and engineering can just sing. So it's been a night and day from previous companies to be under the engineering org and showing them our value, right?

Like our tech team, our tech evangelists, our developers, our engineers, like they have. Like the history within their own career of touching source code, of building things, of doing testing and doing that kind of stuff. So we're also working to embed them more within engineering itself, like to be the ones that are helping to contribute, that are looking at pull requests, things like that.

So that I think is like, it's, it's new for us. And we're just kind of testing it out, but I'm very excited because the tech teams. are very like my tech evangelist are very excited to get their hands dirty. Nobody wants to be a showpiece like you want to be able to actually demo what's going on. You want to be able to speak from engineering and say, this is why we're doing things.

And that's what we're working on right now. And I think it's going to go really well.

Jonathan: Oh, yeah, that's interesting. Steve, what, what does that look like from, from, as I say, again, your side, your side of the fence, trying to bring your, your evangelists in and let them work with the code. Has that gone well?

Steve: Oh my god, it's better than you can imagine. Typically I would say, you know, we rely on community for the voice of the non paying user. Because we don't really have too many other avenues for that. And if you're not careful, your entire roadmap becomes the customer roadmap. So getting that continuous line of feedback from them, you know, of what does the community want is awesome.

And then even more so that they can be so hands on. And again, it takes all different forms. It's not purely contributing lines of code. Sometimes it's using it. Sometimes it's, you know, Hey, I couldn't talk about this at the next conference. This is too clunky. This needs some polish. And this is how I think it should look.

So, you know, the, the, the forms of feedback take all different forms, but they are wildly valuable. You know, you didn't realize just how much you missed it until you start getting it. You're like, wow, where would we be if we had thought of this. So much sooner you know, it, it, like Laurie said, it's been a fairly, not fairly recent change, you know, measured in six months or so, five months, something like that.

But it's been a great change and we're just keep building on it. So I'm excited to see it continue.

Jonathan: So is, is the next iteration of this to, to, to make sure that the marketing people know the source code too?

Steve: We might be asking too much. I don't know if they have an interest in learning the source code. At least the tech evangelists have an interest in it. And I'm not faulting the marketing folks. You know, don't ask me to design anything that looks catchy. I not a creative,

Jonathan: I get that. I just, I know I've heard stories of, you know, marketing people coming and asking just the most off the wall questions.

Like, could it be possible for us to do this? And, you know, engineering goes, I guess it's technically possible. And then a couple of months later, you see the latest marketing thing, this new feature coming soon. Yes.

Steve: Yes. That, that happens everywhere. That's every job I've ever been at that happens. That has nothing to do with open source though.

That's just human nature.

Jonathan: So it's, it's the marketing guys just trying to grab onto something new and flashy to put in. Yeah. That's great. Okay. So let's see. What, what does I'm curious, what, what does this look like then? So if you get somebody from the community that says, Hey, I've got this great idea, but they're not a paying customer, but you look at it and go like, that's legitimately could be useful for people.

Like what does the decision matrix look like for this to, to, you know, are we going to put some resources into making that happen?

Steve: Yeah, I mean, so I'm going to speak for my my product counterparts. You know, but but one of their big value ads is really assessing the overall market need. And it's not just, you know, take your idea at face value.

Is there enough people that might buy this? Well, that makes the decision, but it's Is there enough of an idea in your suggestion that might be able to expand it or might be able to take it in a different direction, maybe sometimes even narrow it. And that helps us get to a, Hey, we're onto something here.

There is a legitimate market need. And again, we do partner with the community team to make sure that we do vet those ideas before we just run right out and build it. Cause Lord knows that's expensive, but Hey, we're thinking of this thing. We got the feedback. It seems to be valuable. Let's talk about it at the next Pick your conference, you know and see what the feedback is if it's positive if you know if we hint that hey We're thinking about doing this and the feedback is oh my god.

Yeah, that'd be awesome. Then it just starts moving up and up the list You know, I think the biggest thing is Giving that community a voice and then listening to it. Not just, you know, here's a form you can fill out and, you know, black hole it. Right. Right. I

Lori: think one of the things, sorry, that I think that we're missing from this conversation that I'm happy to bring in is not just Percona related community, but community in general.

So Steve is my Guinea pig and I'm so happy to have to be on this podcast with you and one of the things, one of the communities that we are a part of is finos. And so FinOS is the financial arm of the Linux Foundation. And one of the things I was sitting on a call that they were looking for is contributions to one of their projects.

It's the something something control. I can't remember. It's three C's. It's CCC. I'm terrible. But it basically, they need help with, like, Expertise. And so Steve, I was like, I've, I've all told him that he needed to help me. And now we're contributing our sort of reference architecture for for my SQL in terms of like having a hardened, like security features for my SQL things you should look out for.

And so it's not just talking to ourselves or talking to our own community. It's how can we impact the broader community with our, our expertise and, and There's another project that we're working on it's called Gwok. It's in the OpenSSF, so it's a security project. Gwok is being built in Postgres.

One of my contacts was like, Hey, you work for Percona now, we need help with Postgres. We wanted to keep this open source project completely open. Can you help us? And it's like, Yes, of course we can. So we are now looking at their database as they're building out this security project. So it's, it's not just working within our own sort of Percona mindset.

It's what can we do at Percona to really elevate the community in general. So it's, it's a, it's a really exciting time to be at Percona because we are sort of flexing our, our skill set in other communities that maybe we haven't approached because You know, it's, it's not just the database, right? It's like, how does the database make your project better?

And so I think, you know, the next thing you think about is, is AI, right? And so there's all of these tools that are coming out and for us, it's, we don't want to be the next greatest AI tool, but like, Hey, what are your, what are you building out of you're building out of your database? Like, do you want to make sure that you are fine tuning your database that you're getting out of it, what you need?

So. Again, it's sort of like we are vastly more than just talking to ourselves, which I think is, is what sets us apart.

Jonathan: That's, that's an interesting point because, you know, Steve and I, we've been talking a lot about the, the, the community upwards to your upstream vendors and the community down.

Downwards to your users and Lori comes, it just brings along this idea of what about talking about the community outwards to sort of our peers and the other people doing interesting things. And that's something that we we don't think about quite as much. And that is, that is really interesting. And so what is the, what's kind of the motivating factor to want to reach out and work in some of those, some of those kind of vertical directions, excuse me, horizontal directions.

Lori: Well, I think again, it's like everybody has to store their projects somewhere. And if we can lend a hand in making your project successful, I mean, that is the value of open source, right? It's people coming together to build something, to innovate on it and to make it better, to solve whatever problem.

So for guac, it's an S bomb problem and where Percona might not really be interested in solving like S bombs, you know, like your supply building material, if we can say, Hey, in building Gwok, if you do this to your database, it makes it cleaner. It makes it better than at the end of the day, your project will be better.

Your project will be more successful. That I think again, is, is the value of going, To these other communities and showing what you do and how you can do it better. And when you think about foundations, like look, who's involved in foundations, you've got your Googles, your Amazons, your Azure's, you've got your Facebooks, you've got your Fidelity's, you've got Citibank, you've got all of these massive companies, you know, like what is it?

90 something percent of enterprise companies use open source components. So why wouldn't we want to share the love across the board with foundations that we're a part of?

Jonathan: Yeah, absolutely. I'm curious. Do you find that you're kind of your community? People have to sometimes do some translation work for your your engineering team.

And so what comes to mind with this is I do. I do a little bit of small business it for very small businesses around town, and sometimes they'll come to me with their ideas. The, the strangest asks, like, I need a computer with, and, and they'll say something that they saw from a magazine or on an ad somewhere, like, I need a computer that has one of those new NVIDIA workstation graphics cards.

You're a sprinkler system. You, you put. You, you put lawn sprinklers in what, and then, you know, so then there's this, okay, so what are you trying to accomplish? And then they'll tell me, and it's like, Oh, you don't need one of those really expensive GPUs. You just need, you need a new desktop with a new processor and a GPU in it that will run something with CUDA.

And then you can use your blueprint software. And so there's this, this kind of. Translation issue where they, they, they know what they want, but they're trying to tell you like the details of it and they don't understand the details. And I have to imagine that in the database world, working with, working with customers and even some on this, working with other foundations that this sort of thing happens to, we need a database and I don't, I don't even know databases well enough to tell you the sort of off the wall things.

I'm sure you guys get it though. People ask for off the wall things and it's like, well, let's help you actually come up with what this, what you really need.

Steve: If we're lucky, we can hear the, you know, what they're truly asking for. That's if we're lucky. We do rely a lot on, you know, the community team, the product team, our customer success team, some of our service, you know, services engineers.

Like, they are masters at hearing the problem under the problem that's being described. Right, right. If we're unlucky, we just start building based on, you know, I need this NVIDIA thing, you know. Yeah. And that's happened, well, once or twice, more than I care to admit. I'm sure. You know, I think then, then we circle back, like, okay, how do we miss this?

How do we get this out next time so that we're not just, you know, sort of chasing fantasies, but actually, like, getting to the core of the problem. Mm hmm. Because there's nothing worse when you build the exact thing that you were asked to build, turn it over, and they're like, it didn't fix my problem.

Like, what, what was the problem? Like, maybe we should have started there instead of just building the solution. But yes, yes. Yeah, I

Lori: love it. Because it all comes down to communication, right? Like, there have been many times and like, Steve can tell you where I've dragged. Somebody from engineering on a call with me, right?

Talking about community stuff and people asking for things that I have no idea, like I'm a marketing person, right? Like I have, I am not technical. I can try and translate to a point, but I need to pull someone in to be like, what, what, what exactly are they saying? Like, and then, you know, and then also like being able to take a step back to be able to stop a conversation and say, okay, hold on, like, Okay.

Let's talk about part a you've just went from A to Z. Like, let's just figure out what a is. And I think when you have a good team involved, right? When you have someone that can maybe take the marketing fluff and drill it down to the actual ask. And then you have the engineer that can take the actual technical side of things and and put it together.

You're gonna win. But when to Steve's point, when you just do one or the other, you could build something that's not necessary. And, you know, nobody wants that.

Jonathan: Yeah. Do you, do you get this with pull requests as well? I, I'm sure you must from time to time.

Steve: Usually you get the, yes, it is very, very specific to their problem.

Not, doesn't take into consideration how anybody else uses the feature. You know, but believe it or not, it's, it's less. Frequent than you might think more often than not, you get a, you know, very flexible contribution that's like, you know, this solves only my problem, but it makes extra effort not to step on anything else as a result.

So those, you know, those are the ones that we appreciate. But even the ones that are purely self serving will try to kick it back and say, Hey, you know, is there a way to do this a little bit more friendly to the other people that actually do want this to happen? And, you know, can we improve the. The error messages or the return codes or whatever the case may be.

So we try to, you don't want to tell somebody, you know, thanks but no, don't ever come back. So it's always to keep the conversation going. I mean, it takes an awful lot from someone to be willing to contribute code and databases. They're not easy. So if you find someone giving you database code, there's someone you want a relationship with.

So we do our best to keep that going.

Jonathan: Yes. Yes. It seems like databases and compilers are two of the really hairy problems in, in modern code. Not

Steve: for the faint of heart.

Jonathan: Yes, absolutely. Okay. Probably a question for Lori then. Have, have you guys had any real like pain points beyond what we've talked about with trying to wrangle the community?

I know sometimes there's things that come up that are just not pleasant to deal with.

Lori: So not since I have been at Percona, but I used to be the CDF, Continuous Delivery Foundation outreach chair. And in that there, it was kind of there was a wonky time, like they lost their executive director.

They got a new one. There was, you know, community didn't understand what was happening within the organization and the way that we, like, and there's nine or there's eight projects under the CDF and the, and the projects were wondering what was going on. And so what I did was I held feedback sessions.

Where I just let them tell me everything, the good, the bad, the ugly. There was lots of ugly. And it, it all stemmed from miscommunication or lack of communication and not understanding like what was going on. And, and from that, you know, creating an actual action plan moving forward, having everybody buy into it because they saw.

Bits and pieces of the conversations that they had within the plan itself, and then launching the plan and holding yourself accountable to the things that you said that you were going to do. And the change from when I started in June of 2022 to, we had CD con in, um, May of 23 was, or April of 23, whatever it was, was phenomenal.

Because everybody felt like they were a piece of, of the CDF, whether they were a project, whether they were a contributor, whether they were someone that just happened to use one of our projects, a user, someone that adopted it, it was just, it was amazing. And I think that is where community can really shine is when you do take a step back and say, okay, this isn't working.

How can we make this work? How can we fix this? And it, if it is sitting there listening, I had very many calls and The CDF is a volunteer position, so sitting there knowing that people are going to rag on you for an hour at a time, telling you how you're not good, like you're not good enough, you're not doing what you said it takes a toll, but it also I think is inspiring, because it makes you want to do the things that the mission statement says.

Excuse me. The mission statement says you chose to be at this foundation for a reason, right? Like you chose to use this project for a reason like we need to be beholden to like why we made that decision. Like we need to hold true to our core values as to why we're doing this in the first place. So it's, it hasn't happened at Percona.

I mean, I'm new, but I, like, I think again, the way that. Coming in from an outsider looking in, right. From a marketing person, that's always been community to a community person inside of engineering. It's really awesome to see the innovation from our engineers, the feedback from the community, the amount of push and pull that is all positive, you know, it's, it's really cool.

So happily haven't had to deal with anything like that, but again, coming from the CDF, it was just a matter of, you know, letting people's voices be heard and then creating an action plan and then being accountable for what you said you're going to do.

Jonathan: So I want, I want to let Steve answer that if he wants to, and then I have a followup for Lori, because this is fascinating.

Steve: No, no, I actually, I don't, I can't recall an instance like that where, where where there was just an up, upheaval. I think we, you know, I think we're very cognizant of how you treat the community. You asked earlier about, you know, how do you, it, you can't just be. In your own little community, you can't expect everybody to come contribute to you.

So we have to You know, that's why we share our expertise outward So I think because we're very very aware of that. Maybe that's helped us dodge some bullets but I can't I can't remember my five years here any ever being sort of thrown at us I don't think it's luck. I think it's you know, we're very intentional about how we get involved in the various communities either the ones that we depend on our own or the ones that we depend on

Jonathan: Yeah, makes sense.

Okay. So, Laurie, let me follow up on that with, with this question. When you have those conversations with community and you do come to the conclusion that, Oh, there's a In the organization, the broad organization, there is something that we've done here that maybe it needs a course correction. How do you get buy in from those in the organization to convince them that there needs to be a course correction?

Like that seems like that could be the hardest part here. How does that work? Do you have any secrets for us?

Lori: So this is actually funny. So when I first started with the CDF, I had a nail in my tire and I had a meeting with the core team from the Linux Foundation that worked on the CDF, and I didn't know that the new executive director was going to be on the call.

So I'm at a tire place. With my hoodie on, my headphones, like looking very much like hacker crazy, and not realizing who was on the call with me, I just kind of stated everything. I was like, this is happening, this is happening, this is happening. And this is how I see a pathway forward. And without realizing that the executive director was on, he's like, yes, like, yes.

And so I think it's being able to justify the actions that you want to take having an actual plan and a strategy. And it wasn't just like, I want to listen to a bunch of feedback. It was, I want to listen to a bunch of feedback from that feedback. I want to create our plan of action from that plan of action.

I want to present it to everybody to get buy in from that buy in. Then we're going to go. And it's having the overall strategy when you, and then presenting it. Right. Because if he had said, no, like, I don't want you to do that. I would have said, okay, what is your suggestion? And then I'm going to go back to what mine is, or maybe I will alter it and include his pieces.

I tend to steamroll. I don't, I can't, I can't help it. But again, it's all about like opening the communication and, but also having the, the. Like the information to back up what you're saying. Like I was a part of the, that organization for a year. I was one of the people complaining, which is why I stood up and be like, ran for outreach chair, right?

Cause I was like, I cannot stand to be in another one of these meetings. Again, this has been terrible. Like we, like, we want to do something and nothing is happening. I guess I will stand up and I will, I will do more. And I think that's also what makes community great. Right. Is that everybody comes to the table and it's up to you to decide, like, How much you want to put in, like, do you want to be a chair?

Do you want to volunteer? Do you want to be on a program committee? Do you want to initiate, like, do you want to go to GitHub and say, here's an issue, like, do you want to give feedback? Right? Like. Community is only as strong as you make it. And it's up to the individuals to kind of take that leap. Like you can use a project all you want and never say anything.

And you can be, be upset that things aren't working the way you want it to, or you can have ideas, but if you don't share them, if you don't bring yourself to the table, then they're not going to be heard. So I think again, for me, it always comes down to like open communication, feedback like listening to others and then Using that to strategize on how you move forward.

Jonathan: Yeah. Excellent. All right. We have been going for just over 50 minutes. I'm curious. Is there something that we haven't talked about that it's just a burning that you guys really want to talk about? And this is sort of a different question. Difficult question, because you'd have to go through all the things I wanted to talk about and which of those have we checked off, but is there anything that we have not gotten to that you really wanted to?

I

Steve: mean, there's a couple of items in the road map. Maybe I could assign a few JIRA tickets to you if you wouldn't mind just throwing some code down for me.

Jonathan: I can write code, but man, databases is just outside of my expertise. That is actually a good point, though. What are you guys looking forward to for the future?

What is coming down the pike that you're excited about?

Steve: Oh, jeez, all kinds of stuff. I mean, I think the ones that I'm most excited, obviously Everest is huge for us. You know, bringing. database as a service, giving you control, giving you sort of the best of both worlds, the AWS experience, but also control of the data and the systems underneath it.

And then one of the other big exciting ones is our Postgres team is working on transparent data encryption, which is something that we're really excited about. I know there's been multiple There are multiple solutions out there, but we, we think we're looking at a slightly different approach to the same problem.

And hopefully you know, the, the early returns are that the community does see value in it. So I think that's always great for us to keep, to keep on going when we hear things like that.

Jonathan: Yeah. Transparent data encryption being like the, the database itself automatically does encryption and then it's encrypted at rest.

Steve: It's actually stored encrypted in the database. So it doesn't matter. I mean, It's, it's actually double encryption if you encrypt at rest, meaning the disk itself is encrypted, but this is encrypted inside the database. So even at runtime you don't have to worry about your data being exposed unless you are the application that was intending to see the data.

Very cool. So it's being encrypted in real time as it's being read and written to the database. Excellent.

Jonathan: Blory, did you have anything you wanted to plug for the future? Anything you're super excited about that's coming down the pike for Percona?

Lori: Well, as a community person, I'm going to jump on what Steve just said.

Right. And like, we're going to a bunch of conferences, conference season is back. So I am very happy to be able to be to be at events representing Percona, so we'll be at open source summit Europe. We're staying for Valky day. We'll be at all things open. We'll be at PG conf in New York.

We'll also be at. OSFF, which is Phenosis Conference in New York. We're going to be at KubeCon. Like, so to be able to take everything that we just talked about today and then put it into practice, like, in person is what I'm super jazzed about. So, like, to see what the reaction from the PG Postgres community is when we sort of have our presentations about TDE, to get their feedback in person, to launch Everest at at Open Source Summit Europe, right?

To see, like What questions people are asking to see how we can then react is that as a community? Like, what do we have? Do we need documentation? Do we need this? Do we need that? Like, this is like, this is where I get super jazzed because it helps set the stage for what we do in the spring. Right. So with community, everything you do is like a couple months in advance.

Right. So being in person at like. Six conferences in like three months or something crazy. And then be able to take all that knowledge back to the engineering team and then package ourselves up for the spring round, right? KubeCon in the spring, open source summit in the spring, all of those other things is like, it's the fun time.

So I'm well rested from the summer and now I'm ready to get back on the road.

Jonathan: Excellent. Busy, busy, busy. All right. So I have to ask you guys each before I let you go. These are our required two questions. We'll start with Lori. What's your favorite text editor in the scripting language?

Lori: I'm sorry. Did you see the face I

Jonathan: just made? What? I'm

Lori: going to pass, like.

Jonathan: So is it Microsoft Word and English? We get that sometimes. I'm not going to lie.

Lori: Then I will, then I will, I will say that. Like, you just, I was not expecting this question. Catherine did not prep me for like the standard questions.

I've got nothing. I got a little egg on my face. Just say Vim. Vim. Vim. 100%. No,

Jonathan: no, that's fine. And that's, that's something most of the people have an answer for. Everyone's every once in a while, somebody doesn't, I think the really fun one is when someone's like been in management for a while too. And they're like, let me think back to what I used to use back when I actually wrote code.

So that's, that's fine. There, there is absolutely nothing wrong with that. But Steve, same two questions. I imagine you'll, you'll have a little bit different answer.

Steve: Well, I've definitely Vim is my favorite editor. This copilot thing, I'm, I'm digging. So I use VS code a lot more for, you know, like an IDE, but I still, my old go to quick and dirty, just Vim file.

And I could be a thousand times faster navigating the file there than in anything else.

Jonathan: Yeah, absolutely. And scripting language.

Steve: Bash is my go to. You know, Python, if it's going to get longer and more involved, but like bash, if I could type it on the command line, it's just,

Jonathan: it's just easier for me.

That's great. I'm waiting for someone to tell me one of the esoteric extensions on something like bash or Python. So somebody that uses Amber. Instead of bash as their main scripting language or I was I was recently introduced to Python which is Python with braces and some fun stuff out there like that

Steve: I work with a guy who's all about z shell everything was a shell.

That's great. Like I'm lost in that

Jonathan: Fun. All right. Thank you both so much for being here. It was a blast Really really appreciate it and that's Laurie LaRusso and Steve Hoffman. Thank you guys both both for being here

Lori: Thanks for having us.

Jonathan: Yeah, absolutely. Good stuff. All right. Well, that is the show today.

And as I'm sure you noticed databases are not my area of expertise, but we we we sorta, we sorta hung in there. We faked it for part of the way, but had a really good conversation about community as well as some technical things and a bit of database stuff and was It was really, really a blast.

We've got something really cool coming up next week. We are talking with Andreas about Ladybird, which is a browser, but it's not one of the big browsers. It's a new browser, sort of written from the ground up, which is really interesting. So make sure and tune back in next week for that. Do you want to follow me?

There is, of course, Hackaday. I've got my security column goes live every Friday. Friday, and that's also the home of Floss Weekly, as you probably know. There's also the Untitled Linux Show over at twit. tv still, and make sure and tune in for that. We sure appreciate everybody that's here, both to get us live and on the download, and we will see you next week on Floss Weekly.

This week Jonathan chats with Lori Lorusso and Steve Hoffman, the Head of Community and SVP of engineering at Percona, the open source database experts.

- https://www.percona.com/

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/

Jonathan: Hey folks, this week Rob joins me and we talk with Carl Richel, the head honcho over at System76. We chat about their new desktop, Cosmic, we talk Rust, we talk System76 hardware, and even a little bit about Intel and AMD. You don't want to miss it, so stay tuned. This is Floss Weekly, episode 798, recorded Tuesday, August 27th.

It is time for Floss Weekly. That's the show about free Libre and open source software. I'm your host, Jonathan Bennett, and we have a treat today. I know I'm excited about our guests most of the time, but I'm extra excited today because we're talking with Carl Richel about System76, about Cosmic, about.

All kinds of stuff. I'm sure we're gonna talk Russ. We're gonna talk Wayland. We're going to talk the new cosmic desktop, which the alpha is out. It's great. Before we get him, let's talk with our co host. And today we have, we have Rob, we have the, the cereal desktop, the, the, the distro hopper, which is why Rob is on the show today, because I, I was, I was pretty confident that I could talk him into hopping, at least in a virtual machine over to the new cosmic alpha, Rob, welcome.

Hello, hello. Hey! We've been watching Cosmic for a long time now, haven't we?

Rob: We have. Been all curiously interested in all the places they've been going.

Jonathan: Yeah, I think so they they made it's oh, it's been like a year ago now carl will be able to tell us I'm sure exactly how long it's been but it's been like a year ago now They made their initial announcement and the things that that really caught my attention right away are one They're getting away from gnome, which i'm I I like the pop os desktop, but i'm not a huge gnome fan two they were going to rust base, which I think rust is just cool and three they're like And because we're doing Wayland and we're building it from the ground up, we're going to do HDR.

And I'm like, Oh, HDR is cool too. So like from the initial announcement, they had me hooked. And I've just been kind of eagerly awaiting the whole time. Like, Oh, when's it going to be ready? When's it going to be ready? Oh, now you, you gave it a

Rob: test drive, didn't you? I have I've given a test drive on a VM. I, I was really hoping to try it out on bare metal before the show, but you know, time flies and it gets away from me.

Jonathan: Yes, day job and family and all kinds of other stuff going on. And then there's that other show that we keep you busy with too. So we have a lot, but it looks really good. It looks really good. And even in a VM, it does. All right, let's, let's let's go ahead and bring, bring Carl on. Obviously the guy that knows what's really going on.

Carl, welcome to the show.

Carl: Thanks for having

Jonathan: me. Yeah, thanks for being here. This is, oh, this is going to be fun. I, we, we had Carl on back when we were still on the Twit Network. And Leo was so, so excited to be able to talk that he's like, Oh, I want to co host too. And so, you know, it was Doc and me and Leo all co hosting.

Well, I mean, Doc was the main host and then Leo was kind of the main host because it's Leo. But it's, it's great to have you back. And it's great. It's great to chat about, you know. First off, what's happened since then, but I think mainly what everybody's curious about what I'm curious about. So let's talk cosmic and let's

Carl: Yeah, I love to talk cosmic.

So Thanks for having me on to chat about it. I was thinking about the last show We were on together too with that with Leo and I remember distinctly he has he has a one of our darted pro laptops And he, he apologized for running Linux Mint on it, I think. Oh, that's But we're just happy, we're just happy when Linux works that way.

We, we're here to make Linux work on our products, whether it's Pop or Mint or, or Bootery or, or Arch.

Jonathan: Yeah. So I'm actually, I do the show on an HP Dev1, which is not quite your hardware, but it's also pretty much your hardware from what I understand, but running Pop! OS on it still. And I've had a Yeah. Yeah.

99 percent great experience with it. There's something weird with the power charge circuitry, but we work around that we make it work anyways

Carl: Yeah, that was a great product and a great collaboration of the folks at HP. You were really great to work with.

Jonathan: Yeah

Carl: They're very professional. I think Working with them on dev one Also helped us refine POP 2204, because that was coming out at that time.

And so we had just more people with different perspectives looking at what we were building and, and really helped, helped sharpen that, that operating system release.

Jonathan: Yeah. Okay. I didn't expect to get to this question so early, but it, it really leads into it. You did the collaboration with HP and there's, there's another company out there that I think might be really interesting to do a collaboration with.

And that's framework. And I'm, I'm just curious, like, do you, do you have opinions on framework? You consider them a competitor and have you ever thought about that? Like, I wonder if we could do something similar with the framework laptop.

Carl: Oh, I've been, having been in the hardware business for now.

Almost 19 years. I know I know how challenging it is and I, I think it's really admirable how well they've done getting into the market and doing a lot of creative work around right to repair. We have, we have that. But very much in common since day six and, and, and framework both care a lot about their about a user's right to repair, but their ownership over their products.

So so I think I congratulate them on, on doing something that I know very well, how hard it is to do, and they've done a fantastic job. So, so good for them.

Jonathan: Yeah. I, I, I kind of, I can envision a future where it's like either, you know, system 76 makes. One of the embedded main boards that people can put into a framework laptop or framework sells a system 76 version or maybe even makes cosmic, you know, maybe as simple as making cosmic a ship option that you can buy one of our laptops, you can put system 76 cosmic on it.

And everybody wins. Like it just, it, there, there seems like there's gotta be, there's gotta be some way that the cross pollination and that can happen.

Carl: I think that would be possible. There's, I'm very interested in modular mobile devices. So perhaps at a level, A little bit further than where framework currently goes, but very similar in that we have a main board that can be used across a number of different devices.

And you essentially connect daughter boards to that main board for your port layouts, and that might be used for a desktop or a laptop or any other kind of device. I think it takes a lot of creative engineering to kind of compete at a very high level and do that with really good thermals in a mobile platform.

But I mean, doing hard things is the kind of stuff we're interested in.

Jonathan: Yeah, absolutely. Absolutely. Okay. So let's, let's shift gears a little bit. Let's talk Cosmic. What was, what was the point where you guys realized, okay, we need to, you have, you have Pop! OS, which is a very, very heavily, heavily customized.

Ubuntu, and it's a very heavily customized GNOME. And at some point you guys made the decision that GNOME is just not cutting it anymore. I'm curious what, what that looked like. What was, what was the point where this, this harebrained scheme as it were, popped up where it's like, we need to, we need to start from scratch on this.

Yeah, why? Yes.

Carl: Yeah. Why? Okay. Well, it's a long, it's a long story, so I guess I have to decide where to even start, but at the best place is probably with why we decided to make the changes we wanted to make to gnome in the first place. We were. All of our engineers that were working on the Pop OS were using i3 at the time.

When they were using i3, I got became interested in it. And so I started using Sway. Then we were getting calls in our tech support department. I said, Hey, does I3 and Sway run on, on Pop OS or how do I set up I3 on Pop OS? And this was not just a one or two requests. This was extremely common. It was, it was coming in regularly.

Then I went to a, A firmware conference at Google for Open Firmware, which we do a lot of work in that area. And so we were giving a talk at the conference and everyone at the conference was using a tiling window. It became clear to us at that point that what we were providing at PopOS out of the box was not what our customers needed.

So in response to that, we decided to build the extensions we built into Gnome, which, which added auto tiling added a different UX in general with a launcher and application library and a doc. And we were adapting for some things we're writing new, new software for others. We were adapting extensions like dash to doc to provide the user experience that we wanted.

Then we found our users were craving and our customers were craving. So it all started with just the desire to. Respond to what our customers want and build something that they wanted. The next. Step was to try to make that more official. And we wanted to prove what we were doing and know, and then see if we can make more official.

We, we had a, a UX architects or a UX architect. Maria was on the design team. I had gone to a number of quad X and. And over time, it just became clear that our vision for the desktop, and we pitched the idea that you could take, we could kind of separate the idea that the UX is what we And in reality, it's a whole bunch of different pieces that you put together to create a holistic experience.

And we thought that Noam could perhaps take the, take the perspective that SimCity 6 could build our user experience out of it. Ubuntu could build theirs, Noam could build theirs. And the idea was considered interesting, but just not where Noam wanted to go.

Speaker 4: With

Carl: that being the case it became, Clear at that point that we would not be able to continue using gnome and continuously adapting it, you know, working against what was going on with upstream to build the experience our customers needed.

And so we decided to build a cosmic.

Jonathan: Do you, are you kind of of the opinion that maybe Gnome has shot themselves in the foot and some of the other downstream from Gnome are going to have to face similar decisions?

Carl: I don't know. Gnome has their vision for the desktop. I,

I don't share it. It's kind of that simple. What I, I kind of, I love this, what I love about Linux and open source is that it's, it is a collection of all of these different communities, interests and tools and different things that you could pull together to build something with. That's what's special to me about it.

And we don't have that at the desktop platform. That's what, that's the scratch we're trying to itch with Cosmic. So we have this thing where we have customers that clearly need something different because they're just telling us all the time we want to be able to build it, but we can't be the only ones.

I'm sure other distros have different target audiences and they should have a different UX because there are audiences different. We don't all have to be the same. In fact, the vibrance that comes from distros and their response to customers, I think is valuable. So we wanted to build a platform. In cosmic where you could take what we've made and it's explicitly designed to create your own user experience.

So you could build the Ubuntu UX out of it. Very, really, very simply, you can build Manjaro could have their own UX. You could build a UX more like sentiment. Out of cosmic. Those are the things that, you know, those are some of the projects that are, have kind of a unique approach to how they they adapt and customize custom environments, but cosmic allows you to do it at a very deeper level and at a professional level that's very high quality.

So so while it's going to be the flagship experience of Pop! OS, and I'm sure the first release is going to be very similar to what we Push out what we think is right for our users. What's most exciting to me is how people will. Brand cosmic, how they might experiment with different applets and user experiences and ways of launching applications or, or managing applications or moving windows, you know, all those things are up for grabs for, for experimenting with in the community.

Jonathan: And there's already, there's already been some, I know Rob's chomped at the bit, I'll get one more and then I'll hand it to Rob. There's already been other distros I know of. That have expressed interest in, but we could package cosmic. I'm pretty sure Fedora is planning on packaging and shipping a cosmic spin.

And that's gotta be exciting for you guys too.

Carl: It's exciting and encouraging and much, much earlier than I thought. I don't think I, we saw it coming. Not too long ago. And so we're learning how to be a great upstream for distributions. We consider distros our customer. We want to make a great, we want to make it easy to package easy to maintain.

We want to listen to their feedback about what we can do to you know, build a good experience for them. So I think they kind of heard that attitude coming from us that we're really care about you know, empowering distros and and yeah, it's in Fedora. OpenSUSE Serpent is packaged as well.

They're a new up and coming distro. I think that's pretty cool. I hope I'm pronouncing that right. Arch, Arch spin that has a focus on performance, their packaging as well. When they're, I think in the performance reboot, I think uses some different compiled flags or something along those lines, but yeah it's, it is encouraging and exciting and we hope we we hope we do well by everybody and all the distros that are putting their faith in us so early.

It

Rob: is exciting. So I mean, GNOME is a nice interface. If you want to do the GNOME way, but was some of your reason, was it just hard, more difficult or becoming difficult to keep up with their changes and the way their extensions work and having to keep updating yours to work with the newest version?

Carl: No, not really. It's that taking that route means that what we are doing every six months is adapting our extensions to work with the new version of Gnome, and maybe adding a little bit of icing or advancement or additional value. So that work isn't very fun. And we're just working Every six months working to get back to par, which is where we were and maybe adding a little more with Cosmic.

What we've done is built the entire foundation where it's it can be adapted to, as I said, other user experiences. But once we have that foundation in place, all of our engineering and all of our effort is adding features and capabilities, new experiences on top of Cosmic. So it means we'll be able to innovate much more quickly.

Just having this flexible base to build upon.

Rob: With that flexible base, The alpha you have today isn't doesn't have that flexibility yet or does it

Carl: it does yes it's the the alpha as It has essentially all the UI elements that you would need to use the operating system But all of those are also are stable Are interchangeable already.

So we have a panel on top and a dock on bottom, but you can remove the dock, move the panel to the bottom. You can make it more like a windows experience. You can move the dock to the left and then have a panel on top and you can have buttons in the top left, like unity had with Oh gosh, they called it lenses for a while in touch.

I'm starting to mix up some of the older Unix or unity user experience features. But in essence Together with panels and applets, applets are applications that run independently inside of the panel and on top of it. So the combination of panels and applets means you can build in a UX.

You can build a custom launcher that is different than our launcher and maybe is more like perhaps an elementary launcher or something along those lines and add a button to the panel and now you have an experience that's closer to that of elementary. So it does have that flexibility in it. And.

There's lots of heavy customization that can be done through config files. What we expose in settings is what we think makes most sense for users, but we would expect people making different user experiences to change the settings as well.

Rob: So, yeah, I guess I should have put a little more time into my experience that I had with it. But I have I have had some time and I explored around with it only on a virtual machine. I, I should have taken the time to put it on a bare metal. But, you know, before the show we were talking about on a virtual machine because of, I believe you said the graphics acceleration.

It's, it's not quite as Stable there because it did crash on me several times. So could you speak to that maybe? Yeah.

Jonathan: Is that, is that expected? I think that's expected, right? You said during the press call.

Carl: It's, it is expected and it's all because we don't have software rendering in our capacitor yet.

So Cosmic Comp doesn't have software rendering, and so you need hardware acceleration in a virtual machine, which is actually kind of fiddly to set up, and more fiddly than, than I'd like, so so we need to get software rendering done. It doesn't affect anyone on hardware. And of course, all of us developing Cosmic, we're all on hardware.

And so, so one of our focuses will be making sure that you have a good Cosmic experience for the second alpha inside of a VM. Because we understand, you know, the commitment just to install it on, on your hardware is high. It's not, it's not production software yet. So, We want to improve that experience for people in the second alpha.

Jonathan: Okay, I've got to jump in and ask. We talked about moving from GNOME. And this is like partially a troll question, but also partially like a real question. Did you consider KDE as your base? Or any of the other desktops? There, there had to be at least a thought of, I wonder if there's something else that's out there that could do this before you just jumped into the deep end of the pool and made your own.

Carl: There's very little that we didn't consider. We had a big pros and cons list for, for different directions. KDE is, I, they're kind of my spirit animal. I like their approach. I really, I really like like KDE and I like the community there. I think I think they're, they're great. Their response to what users need and want is admirable.

They're, but they're, they're technology stack is something I think there's two things with where, where we decided not to go with, you know, trying to adapt three that where we didn't didn't try to go with adapting K to E to our experience. One is we would probably not make K to E users happy. Not because of what we're doing, but because we might trim down things in a way that they'll say this is supposed to be KDE, but it doesn't have all the KDE stuff.

So, so I thought we might be a lose lose situation there where you know, people feel like it should be KDE, but we're building something different. It's not like KDE. And and I don't know how responsive you know, KDE folks would be you know, to, you know, to like more of a kind of middle ground between all of the options that they have and know.

But in any effect, I thought we couldn't make everyone happy. And we might get in the same kind of situation where upstream is not very happy with us. And, and then customers, I think it's something else or seconds. We're not, um, the technology stack C plus plus isn't a language that we work in.

It's not that. Our team couldn't learn C to go that route, but I just can't imagine being a brush shop and then going that way. Yeah, that's fair. Third Katie is as our vision from the start was that we wanted to build a platform for people to build experiences with. We wanted to be that, that user experience, that UI level that doesn't really exist today.

People are using Android to. You know, make car infotainment systems or, or exercise bikes or, you know, specialized devices. Well, this is a, this is a Linux and open source UI project that enables companies and, and distros to do that on their own. I can't, you could I mean, this would be, this would be something that'd be very easy for, for valve to build a steam deck experience with, for instance.

Oh, so, and it's intended for that. So that's also just a distinction or a difference with what our core intent was in building Cosmic.

Jonathan: Yeah, excellent.

Rob: So being so involved in open source for so many years, Any thoughts on open source hardware, like getting Pop! OS working or in Cosmic working with a RISC

Speaker 4: V?

Carl: I think RISC V is very exciting. It's it always turns up in our channels when something new is happening in the RISC V hardware world. We're being the size that we are. We can really do like one really big project at a time. And so cosmic is that one really big project that we, that we're wanting to knock out and then we'll see what's next.

Jonathan: Yeah. Interesting. With it, with it being built on. Well, with Rust, which compiles basically everywhere now, and on top of existing technologies like like Wayland and all those things. I, I kind of suspect that when you get to the point that, okay, we're ready to do our main release, like, the bulk of the development is done with Cosmic.

You know, for that initial release. I kind of suspect that it's going to be a fairly easy lift to go to another platform. If they have like reasonably well working graphics drivers. I, in fact, you, you might find that somebody from the community beats you to it and makes it work there. We've, we've seen stuff like that over the years, time after time,

Carl: I would be elated to see that.

I think it would be awesome. And that's one of the things that's so encouraging about what's happening with the cosmic community to we have hundreds of people contributing patches, building features. It's the energy around cosmic is very, very exciting. So so, yeah, I think the next extension of that is Cosmic's running on this or, Hey, I built a, I put these, you know, five applets that when you combine them together you have this really unique way of using a computer or using this device that doesn't have a keyboard or, you know, Yeah, that's the stuff I'm really excited for.

And I think if we've done well, then we're going to see lots of that over the next, next few years.

Jonathan: Yeah. Okay. We do have a question from the chat room. I've got a bunch of stuff that I want to get to too, but mashed potato asks also, he says, why Ubuntu and not Debian? Well,

Carl: Debian Ubuntu does a fantastic job of pulling together a modern or, Very recent, but stable base, I think.

So combined with our long experience with the Ubuntu I think we can build a pop OS as a better product with Ubuntu snaps are making that more challenging and I'm not I'm not like anti snap either. I, the only thing I don't like is about snap is I kind of like the technology. I just. I don't like a proprietary store.

That's, I would prefer it to be like repositories that we all are used to in Linux and Flathub, which is, you know, an open store. That's my only beef with it, but I would love to have Snap working in you know, Cosmic Cosmic App Store, for instance, and have it as an option for people to turn on or off, you know, depending on their preferences.

But because we don't want to have a proprietary store in Pop! OS by default, we have to do quite a bit of additional packaging work. Like Thunderbird in 2404 moved to Snap. So we're packaging Thunderbird as a Debian for Pop! OS. So

Speaker 4: it does,

Carl: It does add that work, but. There's a lot of other work that they do that is a layer on top of Debian that makes our jobs easier.

Jonathan: Yeah, interesting. Okay, so Let's talk, let's talk Wayland for a minute. Something that's not been entirely clear to me. I think I know the answer to this. With Cosmic, is there an x11 option at all or are you guys Wayland only?

Carl: Wayland only. But there is X11 X Wayland support in Cosmic Comp, so it doesn't really feel, at this point, the Wayland protocols, and this is just a community wide thing, the Wayland protocols are getting really, really good, really, really close to being, like, I think their NVIDIA is finally playing nice, I know it's been a long road for them, but that was our biggest, our biggest question mark wasn't, you know, For releasing Cosmic was NVIDIA because if if NVIDIA drivers were not working, we would just have to delay until that was until it was working too many of our customers use NVIDIA and care about the, the hardware.

Speaker 4: Yeah.

Carl: So but besides that, essentially what we're, we're at the point where moving to Wayland, I don't think. There'll be some corner cases, but there will be very far few between. Otherwise for most folks it's just going to be a more secure higher quality experience.

Jonathan: Yeah. So it, I think that's one of the things that's actually really compelling about cosmic is that you guys were able to, with the exception of ex Wayland, which I don't think counts in this case you were able to just sort of push aside all of the X 11 cruft and start from a fresh slate.

I think that's really compelling because like, X11 has a lot of cruft around it.

Carl: Yeah, it's, it is interesting that that's something we haven't, X raying it is still a pain. It really is difficult because the, the knowledge to implement the things that are there are just. Buried in some guy's head that wrote it 40 years ago.

Yeah. It couldn't be 40 years. That sounds like way too long. Maybe 30, but that's where it's at. And the documentation is the code is it is definitely challenging. But so we spent a lot of time just working on getting XWayland working so that that experience can, can feel seamless.

Rob: So I assume all of your.

All of your apps, applets, tools are all direct Weyland and not going through the ex Weylandshim.

Carl: Great.

Jonathan: Yeah. That makes sense. That makes sense. Okay. I, I, I sort of watched the Weyland development process and sometimes that's painful. I, and I've got to ask do, do you guys get frustrated with the slow pace that Weyland takes and the, it's, from the outside, it seems like.

Every decision gets bike shedded for like a year before anything gets added. Is it, has that been a source of frustration or are we kind of past where that's a problem?

Carl: No, I think the way we approach it we have two engineers that do most of that work quite a bit in the Wayland protocols, Ian and Victoria, and their approach is in essence, This is something that we have to do to deliver a product that's going to work for our customers and our users.

So if we have to release you know, pre V1 protocol even if we have to change it later to match what's, you know, the eventual the eventual protocol, then that's something that we'll do. And we don't feel you know, we'll, you know, we don't feel like that's you know That's bad because Wayland didn't move fast enough.

It's just you know, it's just part of the process of working in a community with a lot of different interests.

Jonathan: And I think that's probably the advantage. One, one of the advantages with Wayland is because Wayland itself is pretty much just a specification. And the, the implementers are very, very free to add their own specifications, to add their own interfaces on top of that.

And so you have things like what KDE has done, where the KDE guys got tired of waiting for. HDR to materialize in Weyland upstream. And so they finally just said, okay, fine. You know what? We're gonna build our own and because we're gonna have fun with it We're gonna call it frog and nobody knows why but that's what we're gonna call it And hey, look with a couple of days, you know a couple More than days, a couple of months of hacking on it.

You guys can use HDR on a couple of programs in KDE because we got tired of waiting for Wayland. And I think that's secretly one of the superpowers that Wayland has.

Carl: Yeah. And that's an okay approach. I mean, we, we do have to get the things done for, for users and that's just a given and that's, you know, part of building software and building products.

If the consensus protocols take a little bit longer and we have to, you know, adapt to them. Afterwards, that's all right.

Jonathan: Yeah. Speaking of HDR, this is actually one of the, for me, not for everybody, but for me, it's one of the killer the killer features back when, when y'all first announced is that a cosmic is going to have HDR.

And I know, I know that's not ready with version one or the release one, the. Candidate one, whatever we're calling it. But I know last time I asked you about this You said that you you anticipated it coming with the next pre release what what is the what does the roadmap and timeline look like on that now?

Carl: I hope I didn't say that I could I am so optimistic terrible timelines Optimism and bad timelines just don't go well together. But the thing is Well, when I get into a tirade about really big projects, it's not actually possible to predict how long it would take, but with with HDR it is a focus of ours and we're Victoria is the, the you know, lead developer for Cosmic Comp, and she's going to all the HDR hack fest and that are going on for Linux.

And so this is a, it's a broad community wide effort to get HDR working really well

Speaker 4: in Windows.

Carl: I expect, so I don't think the first release of Cosmic will have HDR, but I believe we'll add it sometime in the months afterwards. I just don't want it to be a blocker. Because I think we've got, we nailed so much here that it would be okay to release and then add HDR

Jonathan: afterwards.

Carl: And HDR is also really power hungry. And so there are a lot of considerations with like how often it should be used, particularly on a, like a laptop.

Jonathan: Yeah.

Carl: So there's things to think through there a lot of times. HDR content might be, um, you know it might be a choice whether you want to see something in HDR content all the time.

Jonathan: That's fair. I, it, it comes to mind that I, I asked you the sort of troll question about KDE earlier. But it actually comes to mind that. approach to doing this would just be to re implement and use the, the KDE HDR protocol, because at that point, you've already got a couple of applications that are wired up to use it.

Whereas as far as I know, there's nothing that's wired up to use the, the kind of in process HDR stuff that upstream Wayland is doing. And so if you wanted to get it out the door, Earlier, you know, with the next release just re implement what the, the KDE frog protocol and, and let in player and a couple of others use it.

Carl: I have, I have a strong suspicion. It's not that easy. Okay. That's fair. I don't, I don't, I, it's just a, just a suspicion.

Jonathan: All right, so let's let's see, where do we want to go next? We asked about HDR, we asked about Wayland Rob, yes?

Rob: Yeah, so, I believe, when is the final version of Cosmic expected? Is that later this year, or is that a little optimistic?

Oh yeah, so now the

Carl: optimists bad timeline guy has to make a guess. I really want to make a you'll have a release this year and I think there's a good chance the problem, the problem might be it ends, it lands in like December, which is a hard time to release a big project. It's hard on your, your employees that would like to see their families and those types of things.

So I think if we can't make it by. early to mid November, then we would probably do first quarter of 25.

Jonathan: That makes sense. What is the, what has the reception been like though for the, the, the pre release that's out? Like, do you, do you have a, do you have an idea of how many people have downloaded it and tried it?

And then what's the feedback been?

Carl: Gosh, I don't have. I don't have a good idea. I know that we're in for downloads for the alpha. I know it's into like tens of thousands or something along those lines, but that's just like the Popeye says. I don't know about any other. We don't have telemetry telling us how many people have installed cosmic.

Speaker 4: Right.

Carl: I've almost gotten through most of the press coverage. Cosmic, that's We were, we've been so busy after the release, we had all hands company events and engineering meetings. And, and so we're just all, I'm still recovering this week from all that. But everything I've seen is I think very promising and it's a good response.

I think one of my takeaways from what I've seen is the people that the The time that it takes to build a foundation and the time that it takes to build things on top of it is very, very different. So what people are seeing today, and I think if this took two years, then it might be like two years before it's really there.

But what we're going to show over just the next couple of months is that things will happen very, very quickly. So that's that's one thing I noticed that there's kind of an impression that it's, you know, a lot is there, but. There's a lot to go. They'll see that the things that there are to go aren't really really big projects.

Jonathan: Yeah. That's the, the, the 80, 20 rule. You get the, yeah, yeah. Yeah. That's, that's a, that's a real thing. It really is. Yeah.

Carl: Yeah. And then bug fixes to We're focused on putting features out and getting all the features out and then sharpening everything up. But I don't worry about bugs very much either because every time we go to nail down bugs with few exceptions, those are kind of the quick things.

That's just the quality control and and, you know, turning a focus to all the little paper cuts.

Jonathan: Yeah. Okay. So I've got to ask, this comes to mind because. Another project that I'm a part of, we're dealing with this this morning. Have you gotten to the point, and I'm sure you must have, you've, you've been around, you've been doing, you know, Papa West long enough, if you've gotten to the point to where with Cosmic, you've got users complaining, you made all of these changes and you didn't ask us first.

Carl: I feel surprisingly, no, um, and I read almost every bug report And I mean, I'm almost through all of them that have come in since the alpha started. And there are, there are feature requests. There's not a whole lot of you change this and I hate you yet.

I, I fully expected. So this happened to us when we moved from, you know, Pop! Without our cosmic UX and no. To our cosmic UX and no, and they said, I want my overview back and I want this and this and these other things. And so we were prepared for it. This transition is going to be different because the UX from POP 2204 to 2404 is going to be very, very similar.

You're going to have the same launcher, app library, doc, panel. It's going to feel the same, but everything under the hood is brand new. The apps are new. And so you know, fortunately, I don't think the bar has Too terribly high to reach the app functionality that we had before. With the exception of files, file browsers are just really complex.

And so there's a lot of a lot of work there. I think we're going to, we're going to make it there too, but point being. The UX is going to change. It's going to be what we're going to hear. I suspect is I can't install my clipboard extension or this caffeine extension, or, you know, these other things that we're replacing with applets.

All of that, I think is, is, is absolutely necessary because you know, a desktop that has independent running applications in the panel instead of monkey patch, JavaScript, it's just. Going to be better. So more extensive extendable. So we'll have some pain with that. But I, I think from what we've seen already, a lot of enthusiasm people already building applets to replace those things.

So, you know, hopefully, hopefully it's a very small number of people that we.

Jonathan: That's, that's actually an interesting question. Is there a simple, like, scripting tool for doing extensions? Is, does that exist in Cosmic at all?

Carl: Yeah, we have a, we have an applet template, and essentially you're writing a small application that is embedded in the panel, and it can have its own settings.

So, That's and it provides essentially the same functionality. You can spawn windows. You can modify how workspaces are, you know, presented. There's a lot of different things you can do with applets. So So that is, that's our replacement for the idea of extensions.

Rob: So those applets would all be, the developers would all be making those in Rust?

Carl: Right. And they are all independent applications as well. So if you open System Monitor, Cosmic and you can just search for cosmic and system monitor. You will see an applet for a user applet, a Bluetooth applet notifications applet, every app tray, everything that you see in the panel is an independent application, meaning that it can't step on the other applications.

So if there's something wrong with it, it doesn't crash your desktop. Or if there's you could, and you could add or remove them at will. That also means that we can sandbox them. So a community that's building applets doesn't have to be explicit, you know trusted with access to your home directory.

We can we can sandbox them you know, away from that and have the same kind of permissions and portals access that you have in applications in applets that you have in extensions.

Jonathan: So, so when someone installs one of these applets, do they literally get a security pop up? You know, these are the permissions that this applet wants to have.

Like, have you, have you gotten into that, that fine grain sort of of handling?

Carl: We haven't gotten there yet because everything's first party so far, but there are community applets being built and that's something that we're going to have to think about and work on as well.

Jonathan: Yeah. I, I, I hate to say it, but you know, it's coming.

Someone's going to write an applet and it's going to be down to borrow something from the Android world. This applet turns your flashlight on. And Oh, by the way, secretly, it also reads your clipboard and sends it to us. Like that's the price of success. It's

Carl: true. Yeah. And so it's, we'll have to work, we'll want to work on it early.

We are going to have, we'll have a repository for applets and Every every poll, we're going to do engineering and and design review for applets that go into cosmic, and that will be available in the cosmic store. So to I mean, there's going to be more effort for us up front, but because our toolkit is very young, because the community is very new.

And the project is new, it's just going to mean there'll be a little bit longer review process, but we are going to actually do full code reviews. And in this case, even design reviews and provide design feedback so that so that applets can fit into the cosmic UX. And that's largely because the our templates and our widget library is just.

It's just young. So it's it's, it might be as a developer today, hard to turn to know exactly like how, and our documentation is, is young too. So how, you know, how should I, where should these buttons go to fit the UX and some things like that, that we just you need to, Tighten up for the community.

Jonathan: Yeah. Okay. So to get, to get an application into the store, I assume it's got to be open source and use an OSI approved license.

Carl: Not necessarily. I don't think that would be a requirement, but we haven't seen anything that isn't.

Jonathan: I just, in thinking through this, it's like, well, how do you, how do you do code review if you can't get to the source?

Carl: Oh, that's a great point. No, you're absolutely right.

Jonathan: And then I guess the question that, well, so, I mean, it's interesting. This is all very new stuff to you guys. You're, you're, you're sort of thinking through all this as you go along. I think the question that kind of naturally follows after that is, is there even a mechanism for someone to install an applet that does not come through the store?

Like you, you would probably want to discourage that, but at the same time, you might want to still allow it. It is, is that even an option? Is that a thing?

Carl: Oh, yeah, absolutely. You can download code from a repo. You can do that today. That's where most of these applets reside. It's in a repo spread out on GitHub.

You can download those, install them and add them to the panel.

Rob: Yeah. Okay. So, so with each applet being its own program. Would other developers be able to make like a C program or anything and actually run as an applet?

Carl: That's, so it is possible with a different toolkit. So our ICE toolkit and I hope I'm, I'm hoping I'm getting this right, but with our, with our toolkits, I believe it requires that it has to be written in Rust.

If you're using Slint, which is another toolkit that has as libcosmic widgets or, or matching widget widgets, you'd be able to use C or C or you know, the other languages that Slint supports.

Jonathan: Yeah. Very cool. Is, is. Is Cosmic built on top of one of the existing compositors? Like, is it, does it use WL roots or, or one of those?

And I can't remember. I know I've looked this up before and I can't remember off the top of my head.

Carl: No, it's it's a Bruss compositor. That's it's based on a community project called Smithing. Which and so we, we hired Victoria. She was the lead of the Smithy project, that was her project.

And so Victoria was developing Cosmic Comp and Smithy is a big part of, we have a Smithy toolkits and a lot of other things we've built around it over the last couple of years. So that's all all brushed and all all new.

Jonathan: That's okay. That's, that's really cool. I did not realize that you'd gone out and you, you hired the developer that was building the thing that was really similar to what you wanted to build.

That's, that's actually really neat. One of the things that we talk about here is developer open source developers have rent to pay and they need to eat too. I, oh, that, that is really cool that you guys, you guys found a developer and hired him, brought him on board. And so you're, you're kind of bringing the existing project on board.

Making it work with what you need to do. I, I think that is an absolute win for everybody.

Carl: Yeah. Yeah. It's, we wanted to build a the compositor. We thought that was a, the compositor has a huge impact on the field of the operating system. It is kind of central to, to the OS experience. And so we knew that was going to be a key part.

And Victoria is absolutely incredible. An amazing person, amazing engineer. So we're very, very excited to have her on the team.

Jonathan: Do you see the possibility of other, like, desktop environments that, so, someone else out there that doesn't want to use Cosmic but wants to use Smithy? It's that, like, I assume that's possible.

Is there anybody doing it? Do you anticipate that happening?

Carl: I think what we're seeing happen is that people that want to work with compositors but don't want to work in, C or C they want to work in Rust they're going to SmithA and using SmithA as their target for things like accessibility, for instance, and other, you know, unique areas where we want to, you know, improve the Linux stack.

Jonathan: How long have you guys been a Rust shop? System76?

Carl: Probably six years, I think. A lot has changed in that time, hasn't it? It certainly has, but when we started Cosmic, there wasn't, there's still the, the breast windowing environment and ecosystem is very, very nascent. And when we started Cosmic, I know more than two years ago, it was very, very young.

Yeah, there was, you didn't build applications in Rust and today, well, you could. And and I might've seen the bindings, the bindings for GTK are actually quite good. And we were used to using those as well. So you can build apps that way, but not the pure stack that we wanted to build. Where the toolkits, the widgets, everything about the application was written in Rust, including like other things, like there was no text rendering.

So. We had to write text rendering, but the really cool part about all of this is it's a it's a growing community of really passionate and incredible engineers and we all, we're getting, we get to be a part of providing the tools that they're using to build things with now. The Cosmic Text is becoming the standard.

Text render for for Rust Rust applications. You know, that's, that's the awesome thing to be able to contribute to the world.

Jonathan: Yeah, it's, it's, it's really neat. I know something that we've seen like as part of Rust making it into the Linux kernel, if for one thing, it's, it's kind of a, a. A shift for the kernel guys, because now they've been reading and writing in C so long, and they have to add this other language they sort of had to be familiar with.

But one of the other things that's interesting to watch for that is, as Rust is being added to the kernel, Rust itself is changing as a result. They have had to make You know, a lot of changes. They've fixed things. They've made things better in Rust. Have, have y'all seen sort of something similar where as you're building a compositor out of Rust and as you're building these different pieces, that some of the things that you had to work with have now made it back into the Rust language?

Carl: Yeah, I don't know details. So, you know, about that, that's, but I, but I know that everything evolves together if it's going to move forward. And that's the, and the, the base language and language itself is, is no different than any other component. You know, evolves for its use if they're, if you're doing things well.

Jonathan: Yeah, yeah, it makes sense. Are, are we at the point to where we, we are up and coming programmers? We probably need to just start teaching them Rust definitely in addition to C, but you know, is, is there a, is there a point whether it's now or in the future that we teach them Rust instead of C?

Carl: I would think so.

I mean, I went to a memory safety. By default I know I hear the borrow checker is a pain in the ass, but but I think once once you get it, it just, it's a, it makes a lot of sense. I, I don't like language wars. So I don't know how far I

Speaker 4: would

Carl: go into it, but I know it's the, I think building a the bout of memory, safe code and coverage that we're going to have, you know, obviously we have to use, you know, you know, non safe for us for lower level integration, you know, C libraries and other things like that, but Cosmic has so much coverage you know, safe for us code that I think it's.

By the time we're done, I think it's going to be a far more secure operating system and have more coverage than anything else that's out there.

Jonathan: Yeah, it's it's definitely been interesting to watch. And you know, there's there's been things that have happened like Rust developers Every once in a while, I get reminded that like, there are, there are bugs out there other than memory bugs.

We're just, we're so used to those being the norm though, with languages like C that we sometimes forget that, oh yeah, logic bugs exist too.

Carl: Yeah, I think that, I think the I mean, why, Well, we so often hammer memory safety homes because of so many critical vulnerabilities are safety vulnerabilities and you know, things that that we can solve at the language level.

Jonathan: Yeah, absolutely. Okay. We've, we have talked about cosmic. We've talked about Russ. We've talked about Wayland. I want to ask more about system 76 itself. And. I guess first off, is there anything, is there anything upcoming with system 76 as a company that you, you want to plug or let people know about?

Like, is there, is there some secret new hardware that you want to announce on the show? What's what's coming down the

Carl: pipe that you're

Jonathan: excited about?

Carl: There's going to be a new workstation. From system 76 called Thaleo Astra.

Speaker 4: And

Carl: Thaleo Astra will be unlike any other desktop that we have in the, in the line.

And that's all I have to say so far. That's fair. That's fair. It will, it is. Extremely performant and very unique desktop. And we consider it a workstation because of its level of performance and its uniqueness, but I think there will be a lot of people excited about about this product.

Jonathan: Yeah.

Now, I, I honestly cannot remember. I think your. Intel shop. Do you offer AMD on any of your hardware? I just, I can't remember off the top of my head.

Carl: We do. AMD is killing it on desktop. They really are. Intel's fourth generation is quite good. 14th generation. So we have Ryzen 9, 000 products. We have Intel well, this is desktop Intel 14th Gen 15th Gen, I think it's coming in October and Threadripper products on on some workstations.

We also have a a value desktop that is 12th Gen Intel. It's because a lot of people schools and and other, you know, environments don't need You know, the latest and greatest. They need, you know, value. So that's what that price for on the mobile side. We have rising laptops into Intel laptops.

And and NVIDIA graphics on the higher end laptops. So, so really, it's pretty broad spectrum. I think that's one of the interesting things about Pop! West 2 is when we were, when we were building pop, we thought, okay, we're just going to make sure it works really well on our hardware. It turns out that our hardware, we cover so many different it's a pretty good representation.

Yeah. Yeah. And it just ended up that, well, Pop! West works great on hardware because our lab is full and it needs to work well. So so yeah, we have we have a lot of, depending on what the, what the user's needs are, customer's needs are, Intel or AMD or AMD graphics or Nvidia graphics, kind of the full spectrum.

Jonathan: Yeah.

Carl: Which I think is a pretty, it's an amazing thing.

Jonathan: That is really cool.

Carl: That Linux Ships with on everything that's new today. Yeah, that's that's amazing.

Jonathan: Yeah, okay You you may not want to answer this one and that's fair I'm curious though. Have you guys gotten bit by the the Intel 13th and 14th generation problem where where the chips try to eat themselves?

Carl: So yeah, we're it's a familiar with it But at its base, I believe that this Well, that's our, our take is that this was a weatherboard manufacturers, redlining their

Speaker 4: firmware.

Carl: And it was just it wasn't within specifications. I don't know why it was so different than previous generations with Intel specifications and how they were implemented.

But what we found, we spent, we, we did have some customers find that, okay. I've got instability when I'm compiling. And that's what our customers are obviously there, you know, the common use. Heads up. Yeah, so we did so we identified the problem. We worked through it with Intel. We worked through it with our upstream board manufacturers and, and within a few weeks we had a stable firmware shipped out to customers.

So I don't know. I don't know if it was as big as it's, like, we've got a As it's, you know, came out to be I know I've heard oxidization things and other you know, stuff. I don't know. What is, what is your take?

Jonathan: Well, let me, let me put it this way. I have a customer right now that bought two new desktops from another vendor, a very, very large vendor that I, I guess I won't name a very large vendor though.

And they have had problems with those desktops being unstable the entire time that they've had them. And they are now running on the most, on the latest board firmware, and they're still having problems with them being unstable. And so we are probably today going to, we finally figured out that this is.

almost certainly what it is because they're 13th gen Intel. And so we are today going to start the fight to get that vendor to RMA the chips. And I don't know how that's going to go, but I'm reasonably certain that what has happened is that those chips have, have eaten themselves to some extent. I

Carl: have the perfect solution for you.

It's nice being a you know, small, medium sized, hardware manufacturer because When our customers contacted us, it was the guy that's 15 feet away from the QA guy that's doing the testing, reproducing problems, was getting calls and tech support about a problem and walked over and talked to him and we said, yes, this is a problem.

And we're able to work through it pretty quickly. I mean,

Jonathan: so that's, that's like been the biggest problem with working with the bigger vendors is you call in and you get You get their first tier of customer service and those guys are programmed to say, oh, no, no. There's nothing wrong with our hardware.

It must be, why don't you go and reinstall windows? That'll surely help. That'll fix it. You know? Did your reboot? Yeah. Have you rebo, have you rebooted the computer? Have you rebooted your router just to make sure right. Oh, okay. Have ha I've got, I've gotta ask, have you guys seen have you had to RMA any hardware as a result of this?

Is that, has that been a thing?

Carl: We haven't had to army hardware. We did have one customer who just because of speed decided to move to thread ripper.

So, you know, and they, they had a vote of confidence for pressing, Hey, we know you're going to get this, but we've got, you know, we had we need a fix now.

So we just swapped their desktops out for them. But but no, not something like the not, not really like, it wasn't a return problem.

Speaker 4: Sure.

Carl: That's, that's something you're always watching out for. Yeah. Because if there's, if there's a pattern and it means returns, then you've got, You've got a big problem.

You've got to get something fixed. You've got to get, you have something to fix.

Jonathan: Yep. Absolutely. Rob, do you have anything else you want to get in before we, we get towards wrapping? No, I don't have anything else. Okay, okay. It has been great. I've got to ask, Carl, is there anything that you wanted to tell folks about that we didn't ask about?

I feel like we've covered a lot of things, but is there anything that's just burning?

Carl: Oh, I don't know. I would just urge everyone Play with play with cosmic. It's an early alpha, but

Speaker 4: it's

Carl: tech and it's fun. It's just a fun desktop. And that was you know, our intent is not just to, you know, build something because we're a company and delivered to our customers.

We really just love technology and want to make it fun. And so we hope it's something fun for you to tinker with and play, build stuff. So let's get out there and make stuff.

Jonathan: I do. I do know what I want to ask. That is what, what is the process going to look like for people that have existing Like system 76 hardware running Pop OS.

At what point is Cosmic going to roll out to them? How does that going to work?

Carl: Once our release is final, then there will be a button there. You'll get a notification that says. PopOS 24. 04 is available when you click it, it'll you know, there'll be plenty of disclosures, like you're upgrading to a new this isn't just your typical, you know, upgrade to a new version, here's a new desktop.

Yes. So we want to be very transparent. That's okay. You're not going to have gnome anymore. When you do this, you don't have to do it. You can stay with where you're at and it's going to be supported for, you know, a few more years. So you can feel comfortable there. But, we're, we're we're moving to the future and a new desktop.

Rob: Yeah. So it's good. I was going to say, so you're not going to have a pop up every, every few hours. It pops up and said, time to update, time to update. No, like, you know, some other companies have done.

Carl: Yeah, we'll have to be we, we want to be gentle. Because you do want, you do want to keep people up to date, you know, and there's, there's a balance between being a nag and doing that well.

So I think we're okay with it.

Jonathan: Yeah. So it's going to be, it's going to be the default. And is it going to be the only choice in 20, in 24. 04? Or can people still run Gnome if they want to? Is it, is it even out there still?

Carl: They can run gnome just like running like installing gnome desktop. Gosh, I think that's the the right meta package.

Ours is cosmic sessions or cosmic sessions. I'm thinking, I think it's gnome desktop, but yeah, they'll they'll be able to install gnome and run it if you like.

Jonathan: And it'll

Carl: be it'll be vanilla. You know, so yeah, that makes sense. Comparison like

Jonathan: What you guys don't want to have to do is continue to maintain the Pop!

OS desktop experience on two different desktop environments, right? That's just, that's, that would be ridiculous.

Carl: It would be a lot of Yes, providing the same experience. Yeah, no, we're just we're going to pull the bandaid off and run for the future.

Jonathan: Yep. Yep. Well, I, I've got to say we, we have the Linux show.

And so we talk about this from time to time and I've got to say it's become the thing we will tell people don't install some weird niche distro for your first distro. Don't install some weird niche distro for your grandma or your friend on their first time on Linux. Stick with a distro that's. Solid and that everybody knows something about and so we have this kind of list It's like you use Fedora use Ubuntu or use pop OS And so I think it's it's really saying something that you guys are making that list And in such a short time too.

Yes. Yes And What's really fascinating me is that I think we're getting really close to the point to where it's going to be and you should really set them up with one of the established desktop environments, you know, like KDE or gnome. And I think we're about to add cosmic to that list, which again is really saying something.

But it's also, it's also really exciting, like for the community to have a third real choice there. And so I think, I think that's neat. Yeah. That's great.

Carl: I do too. I, I am of the belief that there can be no, there's no such thing as too many distros, no such thing as too many des I think the whole, it's fun to create things.

Go out and make stuff. That's where the vibrance and the that's what's awesome about Linux.

Jonathan: Yeah, I would agree. I would agree. Alright, so we've gotta ask, what is your favorite text editor and scripting language?

Carl: Text editor? Well, right now I'm using Cosmic Text. So I don't know It's the new default scripting language.

I have no idea. Python.

Jonathan: There you go.

Carl: Yeah. Oh,

Jonathan: I reminded the old Dilbert cartoon. You have drank from the cup of management and so you don't write script anymore.

Carl: I don't know. Well, and the real reason I said Python is because that's what I used to write.

Jonathan: That's fair. It's a thing. It happens. All right.

Hey, thank you, man, for agreeing to come on. It's been a blast. The hour has just flown by and we'll have to, we'll have to have you back. You know, once, maybe after, after the 20, 24. 04 drops and everything has, has gone solid, we have you know, full releases and We'll have you back and ask about how it went.

It'd be fun.

Carl: I'd love to be back. Thanks for having me.

Jonathan: Awesome. Thank you. Thank you so much. All right, Rob,

Rob: what do you think? I'm going to be trying this out on bare metal one of these days and I'm going to be daily driving it way before I should be.

Jonathan: Yeah. I, I feel like I probably will too. I, I, I kind of want to, I kind of want to jump to a jump to it on the laptop here.

I need to wait because this is my production machine, but it's, it's, it's fun.

Rob: I'll have other machines to work on. It won't be my, my only one available. If it, if it, you know, if it's not quite ready yet, but yeah, I think it's ready enough that I could use it for most things, most of the time.

Jonathan: Yup. Yup. That's a lot of fun.

Oh, all right. Well, hey, do you have anything you want to plug?

Rob: You know, just come check me out on the Untitled Linux show, or if you want to Find me directly. Go to robertpcampbell. com.

Jonathan: Yeah, very cool. All right. I want to let folks know that next week we are planning to talk with Laurie LaRusso about Percona.

And that is certainly going to be a lot of fun. Percona is open source database software. And then the week after that, we're talking Ladybird, which Ladybird isn't from the ground up. Browser because there's basically only two browsers right now. And so these guys think there really should be a third one.

And so they're working on Lady Bird. That's gonna be a lot of fun too. So some neat stuff coming. As far as finding me, of course there is Hacka Day. Keep an eye on the Hacka day. We've got the security column goes live there on Fridays. And then there's also the Untitled Linux Show, which I do with Rob and the rest of the guys over at TWIT TV on the TWIT network.

And that is a blast and you should definitely check it out. There's also my YouTube channel, if you're really, if you really want more and that is mostly MeshTastic content these days, but if that's something that you, you want to get into it's youtube. com slash at J. P. Bennett, I think. I don't have that pulled up, I believe that's what it is, or you can just search for me on the, on the YouTubes and you'll find it.

Some really exciting stuff in MeshTastic coming with the 2. 5 release coming up, so check that out if you're interested. Other than that We appreciate everybody being here. Those that catch us live and get us on the download. Thank you so much for watching or listening, and we will see you next week on Floss Weekly.

This week Jonathan and Rob chat with Carl Richell of System 76, about the COSMIC desktop, what's new at System76, and more!

• https://system76.com/cosmic

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/

Jonathan: Hey, this week Dan joins me and we talk with Pádraig Brady about Coreutils, that software that pretty much everybody runs, whether you realize it or not. And because of some reasons, it is one of the most conservative development processes we've ever talked about. You don't want to miss it, so stay tuned.

This is Floss Weekly, episode 797, recorded August 20th. Don't RM RF up the tree. Hey everybody, it is time for Floss Weekly. It's a show about free, libre, and open source software. I'm your host, Jonathan Bennett, and we've got a fun show today. We're gonna be talking about core utils, and no, that's not a typo, not a mistake.

We did just talk about core utils, but about three, four weeks ago, we talked about Rust core utils. And this week, we are talking about the OG, as I like to say, the the original Core Utils. Still, still a project. It is not just me, though, of course. I've got I've got Dan the man, Method Dan, the original Linux outlaw.

Hello, sir. Welcome.

Dan: Hey, it's good to be here. Thank you, Jonathan.

Jonathan: Yeah, it's always good to have you with us. Dan, I suspect that you sort of have a clue about Core Utils. You've at least used them a few times over the years, right? Right.

Dan: Oh God. Yeah. I was just gonna, I was just thinking earlier that I would, I would bet that anybody who uses Linux as their operating system has, even if they don't know it, interacted with the projects we're going to talk about today.

Jonathan: Yes. Either directly or indirectly. Right. And, you know, there's, there's several different implementations of core utils because you've got, well, you've got the rest core utils, which is fairly new, but you've also got things like BusyBox that also includes a bunch of the core utils, but with a different code base.

And so they're, they're just, they're ubiquitous. I mean, there's probably, oh goodness, there's, if you, if you count the, the other versions of it, there are probably billions of copies of core utils in the world. And that's, that's, That's that's something not everybody can say that that they've got that many of their binaries running around.

All right. Well, we've got we've got the man We've got paw rig and he is I believe the corp the the head maintainer We'll have to ask him exactly what his title is but he is he is the man in the core utils Project that's Parag Brady and let's go ahead and bring him on Parag. Welcome, sir.

Padraig: Hi everybody.

Jonathan: Hey, it is great to have you Great,

Padraig: great to be here. Thank you very much.

Jonathan: All right. So what what is your official title as it were? I I believe you're the head honcho, but that's probably not what they call you

Padraig: I wouldn't say that. It's open source, so there's no real official title, but I'd say if you had to give me one manager, it'd be release manager.

And I'm one of the, one of the maintainers. There's a, there's a few of us.

Jonathan: Okay.

Padraig: Okay. And I've been contributing for the, to Coreus for the last 22 years.

Jonathan: 22 years sounds like a very long time, except Core Utils has been around for quite a bit longer than that, hasn't it? How long, how old is the project?

Padraig: Indeed, well there's I guess it was originated around 92, I think, it's when, well, there were original it was a bit separated into file utils, text utils, and shell utils, and then a little while after that it was amalgamated into a single Core Utils project. So that, that was done by Jim Meyering.

Jonathan: Now, the, the, the, like the original, original core utilities, some of these utilities go all the way back to like Ritchie and Kernaghan, way back in the day with the original Unix. Is there any shared code base?

Padraig: No, it says that the GNU says that it's a part of the, GNU thing was to be a kind of a complete separate implementation.

So, so, so they were implemented separately, the GNU source space is completely separate. But, but of course, like there's, there's a huge focus on compatibility with those older utils and with other systems. And I guess at this stage, the, the, the, the, the, the, the, the, the, the, the, The, we've been developing them so long there is an onus to be backwards compatible with ourselves.

So that's a, that's a, that's a huge concern.

Jonathan: Yeah, that's interesting. So I mentioned in the pre show we had we had the Rust Core Utils project on and that, that was one of the really interesting things. So, so first off. There is, there's, there's not animosity between the two projects, but in fact, you guys have cooperating on some things and one of the really interesting places of cooperation is in writing sort of this shared test suite that determines that you know, all of these tools do the same thing, no matter which implementation you're looking at, which that really interested me.

Padraig: Well, absolutely. Look at the implementation is secondary after the day. At the end of the day, it's the interfaces with users, and that's, I guess, encoded in the test suite. So we put a huge emphasis on the test suite. And it's something personally I've been focused on all along, like, like any kind of changes or patches we do tend to be mostly focused on.

Most of the effort is actually put in, put, put into testing and writing tests for, tests for patches. So in regards to the ROS Coriatos, I actually, like a few years ago, I noticed with interest the Rust coreutils project and suggested that they could easily tie in the coreutils test suite because it was kind of written like that.

So the Rust test driver, they essentially put coreutils earlier in a path and just call our test suite. And it automatically pulls in the Rust utility. So, so, so we write our test suite to be with portability, portability in mind. Because we have to run our test suite in a lot of places. So Rust gets to, the Rust core utils gets to take advantage of that.

Yeah. And just to mention, it's worth mentioning that the, it's, it's a two way thing. So, so sometimes, Rust folks, when they're implementing new utilities, they might notice bits that we haven't tested and they'll supply patches to us and we'll implement those. So it just verifies our code is working as expected.

Oh

Jonathan: yeah, no, that's neat. And I've found that test suites like that, what they're really, really useful for is when you make changes, They, they sort of help you guarantee that your changes didn't accidentally break something that you didn't think about when you're making the change.

Padraig: That's, yeah, 100%.

Yeah, it's brilliant. Yeah, we put a huge effort into the performance of the test suite. Like, you can run all the tests Say on a standard laptop in about 50 seconds, but the nice thing I've run it on really, really, really fast machines and it automatically scales up so you can run all the tests in five seconds.

That's impressive. 100, 000 machines. But it's, it's not, it's not nice that it scales up and it kind of I guess it shows. The advantages of the Unix model, because we, we tried to rather than saying, writing the test suite in something separate, like, driving it with Perl or Python or something like that, we actually, it's mainly shell scripts, so we were kind of reusing the model and reusing all the tools while testing, writing the test themselves, and it shows that, that's one of the nice things, as well.

So, But having separate processes as you do separate things, they automatically scale up to multiple processors. And so it nicely scales up automatically using the standard Unix model.

Jonathan: Yeah. So a question that kind of naturally flows out of this conversation is, what about the, like, the original Unix version of these utilities?

Is there any cross pollination with Unix? Any of those, like, I guess we might be in a place where one of the original Unix is, somebody's version of Unix uses core utils rather than the old Unix code base. In fact, that's probably likely. And then I guess also the original Unix version of the core utils.

Do we run those through the test suite to see what they do?

Padraig: It's yeah, well, I haven't done it myself. It's an interesting question. I'm sure a lot of them would break, like the test, like ROSCore, you tell us, is trying to be compatible with the latest GNU upstream. So there are new options and behaviors really there.

So, so I guess a lot of the older, older variants would break in most ways against the, against the existing test suite. So.

Jonathan: Yeah, yeah, that's interesting. Do you know, does anybody's Unix ship core utils rather than the old code?

Padraig: I don't think so. So the main focus with core utils is Linux. And essentially these days Linux is ubiquitous.

So that's, that's generally what everybody really uses, like in the large tech companies. It's, it's all Linux internally.

Jonathan: Unix itself is kind of dead these days, isn't it?

Padraig: Pretty, pretty much. Yeah. It's, and that kind of gets on to the kind of the portability aspects of it. It's still very important.

Less going forward, as we said, because things are more and more focused and more and more consolidated on Linux. But there's still a lot of portability concerns with compilers, different compiler options, different shells. And we still try to be as portable as possible. And when you keep as portable as possible, keep your code as flexible, I guess, as soft as possible.

And it keeps the interfaces true and separate and good.

Dan: I mean, Parag, you mentioned there that the portability and stuff, and Jonathan said nobody really uses Unix anymore, which I imagine would probably upset a few people, but I'm not much of an expert, but I'm wondering, does BSD, do people ship core utils with BSD at all?

Padraig: Yes, so that would be our main other Unix portability target, and we have full, personally, I have access to, like BSD, we have access to free BSD systems, and kind of implicitly through macOS that they use kind of free BSD interfaces. I was

Dan: interested in Mac OS, I was going to say, cause you've got Darwin, which is the the kind of the, the, the base under Mac OS and they must use core utils, I would imagine.

Padraig: They actually try, like Apple tries to steer clear for GPL three reasons but, but there are a lot of users of core utils. It's in homebrew, for example, so it's easily installed on Mac OS. And for, for a long time, the, the sort. For example, the sort that was used in FreeBSD and MacOS was actually the GNU version, because that's actually quite difficult to implement and stuff like that.

But, yeah, getting back to testing, like we do kind of put in order to make sure that we have full tests passing on MacOS and FreeBSD.

Dan: That's awesome. Now you mentioned that you've been working on this for, you've been involved with the project for 22 years, which is impressive. I'm always really intrigued in how people got started in these things and how they got involved.

So how did you come to get involved with, with the project? How did you get interested in it? Was it something you were, it was computing something you were into as a kid or, you know, was that, how did all that come about?

Padraig: Well, not as a kid, I'm not going to say my age now, but I hadn't access to a computer until kind of midway through college.

So I started very late from that point of view. But I started first also with Windows, which is interesting. And I was using that through college. And then Went into industry for a year or so and got a bit frustrated with the whole black box nature. It come to a problem and then it was really difficult to actually fully, fully fix things.

So you you're working around issues more and more rather than actually fixing core issues. So then I happened upon it. Linux was just starting out at the time. I guess that's the new thing to my age. And, um, at that stage then, it, it, it's something that, that resonated with me. I tinkered around with it for a couple of years and at that stage then I kind of the Unix model really resonated with me.

And I saw, like, there was a notice that some of the core utilities would they'd benefit from some new options, and so I proposed a few patches around 22 years ago, and they were accepted. And ever since then, I became a kind of an official maintainer, maybe about, I suppose, 16 years ago now.

Dan: Wow, that's amazing.

I always love how people get involved in these things because I think one of the great things about the kind of free open source software world is how, without meaning to be cheesy, open it is, you know, in that you can get involved. What were the challenges in kind of getting involved? Was it, what did you, were you nervous about maybe submitting a patch or and getting, you know, rejected in some way?

Padraig: No, I was very excited. I remember my first patch, how naive I was. I was, I was worried about, well, the code was okay, but I was worried about someone was going to come up with the idea. It's one of the funny things to look back on. I thought someone was going to, it was such an obvious thing. I thought someone was going to come up with the idea and I was mad to get the patch in before anybody else did.

But sure, of course, even there's an infinite amount of code. code to write and an infinite amount of ideas, so that's never a never an issue. So, so that that's one thing I would say to people is even if something is implemented already, there's always a way to do it better so. Always err on the side of sending in the patch, and generally people involved in these projects are more interested in the tech itself and are very interested in incorporating new people and new code into the projects.

Dan: Yeah. And a question I have to ask, it's the kind of dirty question in the room, but I'm really interested is have you managed to get paid for working on core utils? Has that been like part of your job at any of it? Cause I know you've worked in lots of places.

Padraig: Sure. Not directly but I wouldn't be working where I was without having worked on your core utils.

Let's put it like that. So, so there are a lot of it's, it's a good thing on your CV.

Jonathan: Yeah, yeah, no joke, and they say,

Dan: I know you've contributed to it. Sorry. Go on, Jonathan.

Jonathan: I was just going to say, they say with the kernel itself that it's like five, landing five bits of code. Landing five pull requests in the kernel is the average that it takes for someone to get a job offer as a result from it.

Like there, there are a few places we're contributing open source code. It's just. Excellent for your career. And I imagine something like core utils is going to be on that list.

Padraig: Yeah, it's just, well, I guess anybody who's used it as a set at the start of the show, anybody's has used Linux at all has either used them directly there and everybody knows, knows about them.

So it's it's it's, it's good for the CMU as we say. I've been very lucky over the years, really, to have been, I feel very lucky to have been involved with the project and it's still very interesting and rewarding going forward, so it's all good.

Dan: Yeah I'm interested in how, I know this is probably an obvious question, but I'm interested in how the project's managed.

You mentioned that you've got, obviously there's a few maintainers involved probably quite a lot of maintainers I would imagine. How does it compare to something like, like the kernel project? Do you, do you manage it all through Git and, and the releases and all the patches and everything else?

Padraig: Yeah, so we moved to Git fairly early on. Patches are managed with a mailing list still. The number of maintainers, there are, I guess there are three or four kind of central core maintainers that work on it over the years. There's a separate project, so kind of focusing on the portability aspect, there's GnuLib, project, which is probably slightly a bit more active, and there could be, say, 50 projects reusing the portability code that is abstracted away or encapsulated away in the GNU Live project.

And so, so, so, but, but GNU Live was kind of originated as core utils. So they were looking at it simply, there were lots of if defs in the core utils code, and that was gradually moved across to a separate project to keep. So GNU Live presents a GNU interface everywhere, and then it allows the actual projects using GNU Live to be a lot cleaner, and just as soon Like a new interface is available.

Jonathan: It seems like code bases just grow if def statements over the years. It's just a natural part of their development. Especially

Padraig: something trying to port to every Unix and every compiler in the world. You have to be especially careful.

Jonathan: Okay, so, with a project that's been around as long as Core Utils has, and with sort of a, in some ways, a frozen specification, What's it, what's it like to work on core utils and Are, is it, is it done?

Is there a place where it's going to get to be done and what does it look like? And so I guess, I guess really what I'm getting at is I asked that question very tongue in cheek, but what I'm getting at is what is it, what does it look like in core utils to make changes? And I assume it's a, it's like a very conservative process to very slowly make changes and to do it very intentionally, right?

Padraig: Well, yeah, you have to be, something that's used so ubiquitously, you have to be very careful. So there's the whole, as it was, mentioning earlier, the focus on testing. So, that kind of handles that. But we have to be very cognizant of the interfaces. And also the, we have to be cognizant of our interfaces with the community.

So, there are lots of requests over the time to add, over time to add this option and that option. And a lot of them are good suggestions, but they're not just appropriate for adding, because the equivalent functionality might be in a separate tool might be slightly dangerous. But we do take and we do make new additions ourselves over time just to add new functionality, and port to new compilers, and new architectures, and enhanced performance, and portability, and all that.

So there's changes all the time. But just getting back to engaging with the community, that's great. Like, like that's one of the things. You have to be especially cognizant and careful about that with an open source project. And one of the things we've done, for example, is we've maintained a page of rejected requests.

But they're very carefully considered and curated. And it, like if someone comes in with their with their suggestion, and we carefully consider it but reject it, we may add it to that page. But they can also see. If it has, like often, the same suggestion has been made multiple times. They can also see similar, uh, similar suggestions being rejected with very careful, carefully considered reasons given.

And so they don't feel I guess alienated when we, when we give feedback like that. But, but, but we're definitely very open to, to new features if they're appropriate. So it's just, we have to be just careful of that. Backwards compatibility with ourselves the compatibility going forward and just being, I guess, generally cognizant of the Unix model and just being true to that and keeping things appropriate.

Jonathan: Yeah. Let's see. Oh, progress bar. What, what's the, what does it look like when, when someone sends in a request? And let's just take the progress bar as an example. What's the process look like? Like, do the maintainers vote and say, you know, three, three out of five say, this is a bad idea, so we're not going to pull it in or just That's essentially it.

Padraig: Yeah. And it all happens out in the open. The, the, the important thing is it happens in the open on, on, on the mailing list. So we give reasons why it mightn't be a good idea. That's An interesting one. That's one of those 50 50 ones, which is probably a good idea, but it's also implemented already in our sink and stuff like that.

So do you want? Do you want to complicate the code base just to add that? That is one that we may actually add eventually. It's There, there, there's an interesting one like that. So, so that's getting back to the Unix model. Mm-Hmm. . So it might be nice to do that more generally. So looking at something like pv, so that's pro general, that's a separate progress viewer.

Speaker 4: Mm-Hmm. .

Padraig: And, and you can point it at any command and it, it'll open up the file descriptors and. Now, it's, it's not as general as if you put it directly in CP, but it's more general in that it will work with any command and you can pop it in the middle of any pipeline. But one of the reasons we hadn't done that particular one was rsync is equivalent functionality that already has a progress bar.

And looking at The Unix model of thinking, having one tool that's doing something more general, then there's a separate PV tool which can be pointed at the CP process, and it will inspect all its file descriptors and see how far along they are at reading and writing a file, and you can pop it into the middle of any command or any pipeline or directed at any command.

So it's a more general solution.

Jonathan: Yeah, and it's also interesting. Some of the other, like, for example, the Rust core utils, they've gone ahead and they've added that in, I think, at least in CP, maybe in some of the others where it has now a built in progress bar, and that's one of the fascinating things about having multiple implementations of this that are kind of looking at the same the same test suite and the same kind of core rules.

But you have a little bit of you have a little bit of flexibility. as well to be able to do things just a little bit differently without breaking the rules.

Padraig: Right, right, right. And like, it's an interesting thing, like, if there are kind of borderline functionality or new options like that, that are already implemented elsewhere, that that's more kind of more leeway for us.

To implement those for better compatibility. Now,

Jonathan: so the, the, the fact that this is again, talking specifically about progress, the fact that this is still kind of being reconsidered it makes me think that, that, that website, that, that page of these are the things that people have suggested that we are decided not to do, like, that's not necessarily a static list.

And, and you guys have the, That you have the freedom to go back into that and sort of mine for ideas again and reconsider, well, maybe this wasn't such a bad idea.

Padraig: Absolutely. Yeah. And some of them, that doesn't go for all of them. That there's some, some special

Jonathan: ones in there. Yeah.

Padraig: Not to, well, this happened long ago.

That's a, I'm not singling anybody out here, but there was one suggestion that so for RM minus R. To recourse down the way, you could have an option to recourse up the tree. Yeah, we rejected that one

Jonathan: pretty quickly. That, oh yeah, that's, that must be, that must've been like the, the April 1st RFC for the project.

No, no,

Padraig: there was some, some arguments for it.

Dan: Really? And also, also implied the dash F as well. Just

Jonathan: don't accidentally use that flag. Oh my goodness. God, yeah. Uh, and, and then what about when you, and I'm sure this has to happen from time to time, but I'm sure it has to be rare. What's the process if you say, okay, we're going to make a change and it's going to break something, but we're going to make it anyways.

What does, what does that look like? Has that happened? Is that going to happen?

Padraig: It has happened. As we said, we're very careful about doing that. Generally. It's, it's only on if it's associated with some extra functionality that we're doing. So we break compatibilities in some rare edge cases just to allow you to add a lot of extra functionality.

So it's rare we do that and we err on the side of not doing that because, like, nobody wants to rewrite shell scripts when they upgrade from CentOS. Thanks. Bye. 10 to 11 or whatever. So we, we, we just have to be very careful about doing that.

Jonathan: Yeah. And is, is there anything sort of on the on, on the radar that is going to be breaking or maybe otherwise a, a huge big change coming?

Padraig: Nothing breaking interface wise? Okay. Look like, look retroactively, look, looking back at some things that the of another or we, we have another page kind of written of core util Scots. And these are things like, you would never have done this originally if it was designed as one cohesive set of utilities.

These things would never, like, just one gotcha, for example, DD, you often want to present hex numbers to DD because you're dealing with power of two blocks for inputting output to disk and stuff like that. So it'd be nice to supply a hex number. So if you could, and you can. seemingly supply hex numbers like 0x100 for, say, 256 byte block, but 0x100 to DD is 0 multiplied by 100, which is, which is 0, which it accepts and goes ahead and just doesn't skip anything, for example.

So, so there, there are little gotchas like that, that haven't been very carefully considered back in the day, but we have to keep compatibility with that going forward. Thank you And so please, like, we'll break compatibility slightly in that regard. For example, POSIX specifies, if you're not giving an error, you shouldn't give a warning.

Like if you're not exiting with an error status, you shouldn't give a warning, but in that case we do give a warning because it is such an edge case that you probably wouldn't be doing a zero multiplied by something, but we give a warning in that case. So we break, that's not really breaking compatibility, but we're just very careful about how we approach these sort of things.

Jonathan: Yeah, interesting. Alright Dan, you want to pick it back up? I've lost the connection to our back server, so we're having to do it in the open.

Dan: It's all going on today. Yeah, it's been a fun

Jonathan: one.

Dan: Yeah. I'm interested in one of the things that you actually mentioned Pari was the Unicode situation and internationalization as well as another thing as well for for character sets and so on.

So what's the situation with, with, with that at the moment?

Padraig: Yeah. So that's it's. A tricky kind of implementation thing that spans most of the utilities, especially the original text utilities. Personally, I was interested in doing that, and while I was working with Red Hat, I requested, say, a block of three months to go away and kind of just implement that, which wasn't granted, which is interesting.

I was surprised at that at the time. never had really a block of time to, that are required to go away and work. So that has kind of happened in piecemeal over the time, over the last few years. So the main Unicode functionality is currently encapsulated in GNU lib. And there's a lot of Unicode expertise By the, the developers and the main developer, Bruno Hebel of, or of working on Cano Cano lab.

And those interfaces have evolved a little bit over the last couple of years. They've added new abstractions for dealing with characters and multi characters and cells and stuff like that. So that, that has been gradually being added to the corridors over the last while. And, I kind of created a planning document, kind of describing the work that had to be done there.

So at least we have a kind of an overview of what needs to change. So it will eventually happen. Just it's happening slowly at the moment. And one thing that has changed over the last while as well, like when we originally envisaged this, it had, there was a lot of different character sets that are in use, but most things have consolidated on UTF 8 now, so that kind of suggests different ways of handling things of converting everything to UTF 8 before processing and maybe having separate tools for kind of sanitizing and working with UTF 8.

And then as an interface to other utilities, rather than having each utility dealing with edge cases of mis encodings and cases like that. So yeah, it's still a work in process. So, I guess that would be the main kind of functionality or feature that, that. Is kind of outstanding and core utils at the present.

Dan: Yeah, so it's a big one to deal with I imagine It's interesting that you said that you I mean without getting into politics too much that you weren't granted the time to work on that That's you'd think a lot of people would be would be after that, but who knows? Now this is a slightly left field question I suppose because Jonathan mentioned busy box at the start And I am going to show my ignorance now because i'm not entirely sure of the relationship between core utils You I'm busy box.

So seeing as you're here, I'm going to ask you is, is there any kind of crossover between the two? And so I'm assuming not in code. How does, how, how is the, how is the relationship between the two and how's it, well,

Padraig: definitely not in cold. There, there is a little interaction sometimes between Suggested new options and stuff like that.

One interesting thing, like busy Box is more geared towards embedded systems. Yeah. And it has and there's different licensing and stuff to, to date with that. So, so the, the, the main difference there is licensing. Interestingly, a while ago, um, core Utils was adjusted to be able to be built in the same single binary setup as busy box.

So. So the standard way you would build BusyBox is as a single binary with symlinks mapping the various command names to the single binary, and the core utils can be built exactly the same way. So you can install core utils in I think it's a, it's a couple of megabytes with sim links to the single binary.

So, so from a functionality point of view Coriutos provides the same things, I guess, with more portability. But yeah, there's the licensing aspect, the main difference there.

Dan: Now, you mentioned licensing and my eyes lit up because I'm a bit of a licensing nerd. I don't know why I just find this stuff fascinating.

Now I, I was working that I had, I was interested that you're under GPL V3 with core utils and it's, it moved from GPL V2 or newer to GPL V3 or newer. I believe. about 2003 or something like that. So were you around at the time? And what was the process like?

Padraig: I wasn't involved in that licensing. I had a few earlier patches, and then I joined really the project a bit after that.

In a, in a more involved way, I guess. So I wasn't involved in the licensing and I haven't really been involved in the licensing, mm-Hmm. any licensing issues or anything like that going forward. So I'm the wrong person to talk really about that. I'm more more focused on it. That's okay. The, the technical and, and to be honest the, all the, the core maintainers were, were focused on the, the technical aspects really.

But we are aware of the. I kind of, some of the restrictions of GPL 3 just even from a political point of view some people just kind of shy away from it and keep things simple and just avoid it. So that, that's, that's not an idea.

Dan: Yeah, it's an interesting one. I, I, I've got, so the kind of little background to this for me is I have some friends who work at the Software Freedom Conservancy who were involved in a lot of that kind of, like you know, That's licensing.

That's Licensing Central right there. And then I know that they were very keen to get projects to move from v2 to v3 of the GPL, and some were keen and some were not, and some still haven't, like the kernel of course. And so I just thought I'd ask, but that's fair, totally fair enough, that you weren't around or you weren't involved with the licensing at the time.

Now, one of the things you mentioned to us in your email was that you worked for Meta for a good long time and their use of Linux in the back and the stuff that you've done with them. So I'm really interested to dig into some of that because I know that they have their own distribution. How does that work?

Padraig: Sure, I can't go into very details about absolute numbers or anything like that, or details, but I'm happy to go into general general information, and a lot of this information applies to all the big tech companies like Google and Amazon, that they all use the same sort of models. Stuff like that.

So I guess the interesting kind of general information with Meta is to have a huge scalability requirements. So a huge focus on performance, like if you've got, for example, a 1 percent win out of compiler, they're talking hundreds of millions of dollars. The scalability is immense, but it's interesting as well, not in particular to core users, but maybe more aligned with a project like glibc or that kind of library code.

That when you're working on these things in open source, it's used by Meta and Google and everybody else. So it actually has much larger scalability concerns, but it's not really as apparent or, I guess, measurable. to these people. So it's there is a, I guess, there's a huge onus and responsibility on people working on performance.

Like, when you make a change in meta, it's, everything is easily, very easily tested. And You can see exactly the dollar values of changes. And so that's cool as well, because you can feed those, it's easier to test, it's very hard to test things kind of open, open source world, because You have a lot more, it's just harder to test because you have a lot more disparate systems and you haven't everything as tightly cohesive in a whole test framework and stuff like that.

So there's a kind of a symbiotic relationship both ways, like you get really good testing in a place like meta, and then you can feed that information back up and feed the code back up. But, but there's an interesting thing as well that, like, Corporations like these, they get huge use out of open source code, but sometimes there isn't the, I guess, the focus on sending code changes back up because just looking at the loop, there's a short term win from not spending the time to send your changes back up in top string.

But then there's a long term loss by not doing that because you become forked and you kind of diverge away from all the improvements upstream as well. So that was a good bit of effort on my part in META was kind of ensuring that all our internal processes and changes were a bit more. Getting code back open into the o open source.

So, so we didn't become diverged and, and it's something that that's really easy to fall into, but because of the short term win and not doing it like, like even open source first, companies like Red Hat back in the day, they, they originally got into that, that sort of situation. They had had a fourth kernel and it's, they, they actually got into a, a bit of a knot that, that they had a huge effort then to get outta that.

So it's just an interesting thing for any tech company or any company these days, since tech is involved in most things. They have to be very wary of not forking away from upstream too much.

Dan: It's good that that they, well, it's great that, that it sounds like they were supportive at least in, in you contributing stuff back upstream.

Was that something that, like, the management, without meaning to cause any trouble here, and feel free to tell me to, you know, you don't want to talk about it. But I was just curious, were the management and so on, were they supportive in that? Were they like, yay, go and do it? take a day to do this or, you know, support it.

Padraig: Absolutely. Like like in Meta at a certain level, especially you were encouraged to go off, you were trusted to do the right thing as long as you presented the right arguments. Like they were happy as long as you're doing the right thing. So, so within Meta was very open source friendly. And increasingly going forward now with the AI ecosystems that they're really kind of leveraging the kind of the open source aspect of that.

So, so, so no, no, there was great support in, in meta. I was kind of more alluding to the kind of the general kind of thought process of engineers in general within tech companies. They were focused on the short term wins not, not, not on getting their like we're focused we're working away in open source a lot.

And most developers haven't that mindset of pushing stuff back up.

Dan: Yeah. That makes sense. We actually have a question. So there are people listening and watching us at the moment. And we have a question from Mashed Potato, who says, What's the relationship like with developers of Core Utils replacement tools, such as Exa?

Could Exa find its way into Core Utils to replace LS? Is there a good reason to keep LS as it is? That's quite a big question.

Padraig: Well, absolutely. I've, it's a long time since I looked at Exa. There are a few interesting, like, I do have a look at every so often at tools like this, and if there are interesting general functionality that would be appropriate for everybody to use, absolutely we would incorporate it into LS. The big thing you have to be aware about with making changes is the interface.

You, Wouldn't move everybody to having to type exa ls is kind of wired into everything at the moment. So but you could add functionality or the ideal thing is to adjust things.

You have to be careful as well, but the ideal thing is to adjust things without requiring options or changes on behalf of the user. But you have to be careful. So, LS is an interesting one. So, it's an end user tool. So, we made changes recently and there were really good reasons for making the changes, which was to quote filenames that had Problematic characters in them, like spaces or shell characters that were special to, to shell becau because it, it introduced un, unless you quoted the names, there would be ambiguity with the, the spacing for delimiting file names or were the spaces within the file names.

Or you could have semicolons and you could put commands in there. So if people are copying and pasting and you can, there, there's a lot of way to, ways to hide stuff. So, so there, there was security implications there. So by default, we now quote the output of problematic filenames from LS. And there was actually quite a lot of pushback from that, from various people.

And the main reason is because they weren't used to it. And

like we of course provided, always provided a way to go back to the old behavior if we really wanted. But yeah, you just have to be very careful about how you adjust these tools, especially stuff user facing stuff like Ls.

Jonathan: Yeah, it's interesting. I just went and looked. The, the EXA command itself has been retired and a fork.

Iza is now what is the what is the latest and greatest. So and I think, so yeah, it's, it's interesting to look at it cause there's going to be some great ideas there. But what's also fascinating is that Core Utils has been around since 1992 and Exa only lasted for, you know, however many years.

And now the, the main developer of Exa is missing and cannot be contacted anymore. Like just. Just the fact that Core Utils has been successfully maintained for that long is like a, it's a huge win and not, not every project can say that, that they have, you know, that sort of a track record that 20 years from now, you can pretty much guarantee that Core Utils is going to be around and still putting out releases.

Padraig: Yeah, absolutely. And like for companies kind of investing on a platform and they're writing shellscripts and stuff like that, depending on all these utils, there's a huge kind of responsibility for these things to stick around and be stable. And just another aspect of that example, it's good to expand on a particular example and look at all aspects of it.

Like if we were to, say, take things out of ESA, now is it? And add them into LS, there might be a little bit of extra performance in every LS invocation, which that gets back to the point about how there's a responsibility on us to mine performance because it moves out into all companies and all users.

There was one example there recently where file capabilities were colored, and file capabilities are one of the things that never really took off in Linux. So, maybe one in a million files has capabilities now. So there's no real Advantage of coloring. So there's an overhead there of every LLS invocation looking at every file to see does it have file capabilities.

And it's one of these kind of esoteric things. So it was never kind of the interfaces to detect file capabilities was never optimised over time. So kind of a rule of thumb. Or kind of a what I call it, a back of the paper quick calculation I did was that by taking that out of LS, nobody really noticed, but it saved about 75, 000 worth of electricity a year, just estimating the use of LS around the world.

And so, which is, I don't know, maybe 40 households of electricity. And just. By not having this extra little bit of functionality in LS. So these things are important.

Jonathan: Oh, I'm so tempted to say something sarcastic about cryptocurrency there, but I think I'm, I think I'm going to not. So that, that idea of performance, though, that does bring to mind a really interesting question, and that is when Say AMD pushes out their newest processor and it's got AVX 512 support for everybody now.

Of course, Intel has gated that off to their pro line of processors. Are there changes that get made to some of these core utils? Because, Hey, now we have AVX 512, and oh, you can do string comparisons in AVX 512. Like, are you guys sort of on the cutting edge of that, watching those changes in processors, and then therefore going in and making tuning changes in some of these commands?

Padraig: I wouldn't say we're on the cutting edge, but we're definitely incorporating changes such as that. There's two aspects of that. Again, we try not to implement everything ourselves. So, looking at the crypto side of things, or the hash side of things, we, rather than implementing Assembly slash Cindy versions of those ourselves, we kind of push off to live crypto or the open SSL libraries because they're, they're kind of ubiquitously available as well.

So we'll, and we'll with version three, we can, and the licensing changes there, we can without issue link to those. So, so we, we'll link to those by default if they're available and use the fast version. So, so the checks on or cha 2 5 6 on or whatever. We'll use the, the, the latest version of those, but, but also within like core functionality ourselves.

Like for example, wC for counting lines that can be done efficiently in SIMD code and AVX code. And, yeah, we do have code for that. We have to be careful in portability, so there are special portability constraints in how we set up the build, so we actually added libraries to the build system to support that.

That's how you efficiently are. Kind of definitely separate all AVX instructions into separate compilation units in Automake world. So we have libraries that we, internal libraries that we link to to implement that for a few utilities now, and probably more going forward.

Jonathan: Yeah, I know kernel and GCC itself, You have a MD and Intel employees that come through and, and send these big patch sets in.

Like, here's support or here's the tuning for the latest, the latest and greatest from our company. Do you guys get any of that in Core Utils? Are there, are [email protected] [email protected] email addresses, sending patches in?

Padraig: No, to be honest I've had interaction with those guys from working at Meta and ver various places.

And various other projects, but not directly in core utils.

Jonathan: Okay. Let's see. I was going to ask about Dan. What was I going to ask about? That was, that was a short answer. I was going to look it up. Retiring commands. That's what it was. There are, there are some core utils commands that have been around for.

for years, for decades. And it's like, some of these I don't think anyone has really used in decades. And is, have you, is there a thought about, well, let's just retire these rather than making them continue to be part of the the, the maintenance burden, or are they just, are they going to be around forever?

Padraig: Good question. So there's two aspects to that, really. There's individual commands and then there are classes of commands. So answering classes of commands at the initially. Like, for example, all the, the separate checksum commands, like nd5sum, sha1sum, sha25sum, blah, I'm not going to go on, but you could go on forever there, and that's kind of a bad way to do it, to have a separate command for each of those.

So, going forward, we're consolidating those in the checksum checksum minus a, then you select your algorithm there, and so, We won't have any more of that class of command. Everything will be consolidated in checksum. And I guess in 20 years time we'll start removing SHA 386 sum or whatever, just to clean things up.

So individual commands then, yeah, there are some commands that are less used, like ptx, tsort, this sort of thing. I guess the main idea there is that there's less maintenance. We don't much maintenance focus. Like if we get a compiler warning out of them, we'll fix it up. Or if we get some security warning or whatever, we'll maintain it.

But we won't put much effort into adding new features or changing functionality on those going forward. That's the main thing. As for removing command, there's the big compatibility concern. Like These are, these utilities are so used and that there's some edge case on. Some space probe in Mars or something, we just can't, we can't, we probably can't remove, remove commands, so it wouldn't be that much maintenance going forward.

And on the other hand, that's why we have to be very careful of adding commands. And even options in that regard, but in added commands, we have to be very careful.

Jonathan: Yeah. All right. I do want to make sure and ask, is there anything that is coming that you wanted to let folks know about? Like, are there any future plans that you're particularly excited about?

Padraig: I guess the main one, you already asked about the internationalization and Unicode support. So, so that is something that's coming gradually. And we're definitely focused on that, and it's happening as we speak. In the last release or two, there have been updates to expand and un expand and utilities like that for them to handle multiple characters, so that will be coming.

Perhaps there might be a new utility. We've moved it for a while about a replace utility. So it's interesting. To replace a file on Unix is actually really difficult to do it with ACID principles, and copying data around with ACID principles is actually really difficult. So, kind of makes a lot of sense to have that encapsulated in a separate command.

Like rather than have sed minus i, you can have The replace command and provide another command to do the actual processing and then the replace would do all the complicated stuff about temporary files or kind of moving files to atomically and and all that anarchy. That, that's something that, that might be on the horizon.

At the end, there's. There's always the ongoing maintenance of new kernel interfaces for example, one thing that's changed recently that might allude to things going forward is we added and we had to be very careful in how we added copy offloading. So copying a file is actually really primitive in a POSIX interface.

It's like you have to copy the metadata separate to the data. You have to, there's atomicity issues there as well, which gets back to the replace command. But recently there's been the copy range command to in the Linux kernel and similar commands elsewhere or similar functions elsewhere to provide copy offloading.

And but we locked the doors maybe 10 years ago. and had a deep dive on those, and they weren't stable enough either in interface or functionality. So we provided feedback to the kernel folks then, and more recently in the last two or three years we've been able to start using these things. So that allows for more efficient copying operations, but we still have to be careful and actively inspect and avoid older kernels and stuff like that.

So, there's going to be changes like that going forward with new kernel interfaces.

Dan: Oh, awesome. So I'm curious if somebody say, listen to this decides, you know, I'd like to get involved with with core utils. That seems like my kind of thing. I mean, I'm always keen to ask people who've made a career out of this and who, you know, have contributed and become maintainers on these projects.

Do you have any advice to somebody? How? What's the best way to get involved and to you. You know, to, to come along, is there anything you particularly need, say, from the community that you think would be great if we had somebody who could do X, Y, Z?

Padraig: Well, there's a, there's a to do file in the repo, in the main repo.

There's a, If you look on the main, the main GNU Core Utils mailing list there's, if you, if you sit on that for any period of time, really, you'll get an idea of the, the work we're interested in doing and what, what, generally the work that's, needs to be doing and interested in doing. There's no we don't have a Well, we do, I guess I'm saying we don't have a bug tracker, but we do have if you go to bugs.

gnu. org, uh, slash there's a core utils section there. And so there are some outstanding bugs that need to be handled as well. And just in general, we're always very accepting of Just interactions and patches are on the list, and we'll try and guide people Like, we're very, very interested in getting code and new people involved in the project.

Dan: Excellent. Yeah, I mean, that's the lifeblood of every project, I suppose. So, Jonathan and I have just been having a little discussion in the back channel here about, about GitHub, because I didn't think you used GitHub, but apparently Jonathan says you are on GitHub, and he want, being that we talked about contribution and so on, we, I was curious, do you, do you accept pull requests from GitHub?

Padraig: We kind of do unofficially, right? So, so we, we, we have a, a GitHub mirror and we, we probably changed that a little bit going forward, but because it's become more, GitHub has become more ubiquitous since we, we had a policy. So currently you can make a pull request against Core, which I set up about 10 years ago.

And, just to consolidate things on the mailing list, we give people advice, like when you make a pull request, as the main commit message it puts in, that you should send it to the mailing list, but you can still create the pull request. So, so we might change the, the policy there to, that we will support pull requests separately as well, because yeah, and I have looked at pull requests there over the last while, and I do monitor that all the time.

So, yep. That's actually, I'll add that to my to do list this evening to change the wording there. At least we're giving you work to do, I feel bad now.

Jonathan: Oh, no, no, that's our job. No, that's interesting to me. I get the, I very much get the the hesitation that particularly the, the thing that I've noticed is that a lot of people, particularly free software projects have, and GNU projects have, about using GitHub, because it's not all open source software.

And I definitely get why people don't love that. But at the same time, it's so useful. And it, like you said, it's become so ubiquitous that it makes things so much easier for people to come in and add, you know, a trivial or a small pull request without having to go to the mailing list. A lot, a lot of projects have arisen with this.

Padraig: Yeah, I don't wrestle with it too much. I'm definitely on the side of defense that I'm not kind of. Very binary on you can't do this and you can't do that. The, the world is gray. So I, I, I'm on the, the side of the fence that whatever gets the, the most, the, the best logic in to the most people is best and mm-Hmm , most people are used to using GitHub, so I have no issue whether using GitHub at all.

Jonathan: Yeah. That seems to be where a lot of projects are coming down. Alright. Is there anything that we didn't ask you that you wanted to make sure and let folks know about? And I know that's a tough question because you have to. think about all the things you wanted to talk about, and all the things we've talked about, and do that set comparison, but Dan, do it, Dan.

Padraig: No, I don't, I'm just, I scanned my notes here, and no, I think that that was a very all encompassing set of questions, so I think you've got everything there.

Jonathan: Yeah, we try, we try. What's the weirdest thing that somebody has done with Core Utils that you're aware of? Have you gotten any user stories that have just surprised you?

Or maybe, you know, requests that have just been off the wall are very surprising?

Padraig: Look, you know, that's Jesus, nothing goes to mind there.

Jonathan: Maybe the, maybe the recurse up the tree was the answer

Padraig: there. That was the most off the wall one, I guess. There was an interesting set of videos I saw from, I think it's Robert Elder.

He, he went through a set of core utils recently, and he did a set of videos where every command, he started off that every command was his favorite command, but he had a very interesting use of timeout for Avoiding saturating his network with a backup. So he'd start off a backup, but if the backup, so the backup would keep copying stuff that hadn't copied already, but he'd time it out after two hours.

So I thought, I just thought that was a very interesting insight. Time out his backup. But it would get, but it would run the next night, and then it had left off where it went before, so it would eventually, eventually copy his files across, but you know, there's lots of esoteric uses. I, so many, I guess so many esoteric uses that I can't remember many.

Very many particular ones over time.

Jonathan: Yeah, that's the thing. You have, you have people that write these one liners where it's 15 different commands and most of them are going to be core utils commands and they do something, you know, ridiculous or really impressive. So there's a bunch of them out there,

Padraig: but on the other hand, like looking at questions on the stack overflow and stuff like that.

And there's, I just, People are, I don't know why they do things the way they do, like, it's just, I should have a section, I definitely don't do this with core utils commands, but, each to their own, you know?

Jonathan: That would be amusing to read that FAQ, the things you definitely shouldn't do with core utils. Oh, that'd be great.

All right, well, I've got to ask you before we let you go, what is your favorite scripting language and text editor? Interesting.

Padraig: Interesting. Scripting language. Well, what is a scripting language? That's true. I'd say my favorite interpreted language is Python. So does that count? Yeah, absolutely.

Dan: Yeah, yeah, definitely.

Yeah,

Padraig: that's one I've used for a long time now. And I get the most flexibility and functionality out of it.

Jonathan: And text editor.

Padraig: Text editor, I use VI. So, an interesting part of that, that's worth mentioning quickly, is that the interfaces, I use CLI a lot, I guess, obviously. And so the main, like UNIX has not been designed kind of cohesively, it's kind of evolved in separate kind of factions with SysV and BSD and stuff like that.

So the kind of, the interfaces have kind of evolved to be bash, or, sorry. Vi versus Emacs in various commands. So I've set up all my systems to have Vi key bindings, and it actually helps with the speed of the interface and helps with RSI, which I don't have any RSI ever, but maybe that's, maybe that's the reason.

Jonathan: It's gonna be the secret why. It's funny you ask what what counts as a scripting language. We had, we had the creator of Bash on back several years ago, and I asked him if Bash counted as a scripting language, and I think he was sort of offended that I asked the question. And Yeah

Padraig: Yeah, it's one of these things.

Jonathan: Yeah. Yep. All right. All right. Thank you so much for being here The hour flew by and we had a great time and I think really covered a good Corpus of information on the core utils and it was it was a blast to have you appreciate it Absolutely.

Padraig: Thanks,

Jonathan: man.

Padraig: Much

Jonathan: appreciated. Yeah. All right. What what do you think?

Dan: Yeah, I think as, as I as I kind of said at the top of the show, everybody's used core utils, whether they know it or not, I think, anyway. I say everybody, you know, I would imagine these days with the amount of things we've got in devices that are running all kinds of different stuff. And one thing I actually found very interesting that Pyrog We told us about was because we mentioned BusyBox and embedded.

I've got a lot of friends who work in embedded Linux and in that kind of world. And I didn't realize you could get like a two megabyte implementation of, of, of core utils. Now, I don't know if they know that or if people from busy, because I also know people who work with BusyBox and they're going to hate me.

If I say don't use that, use core utils, it'd be better, but you know, it's just these options, isn't it? But very interesting stuff. And I think the ubiquity of, of this is, is, is so amazing and the responsibility that it puts on maintainers like, like Parag and the other people involved that this is used everywhere.

So I imagine that, you know, it, it, it must be quite a weight to kind of bear.

Jonathan: Yeah, yeah, it's like we said, it's, it's it says a lot about the project and the way that they run it, that it's been around for so long and it's still a healthy project. So that's, that's neat to see. And I also find it, I find it real fascinating.

So I, I couldn't help but think when they were talking about how they, they very carefully make changes. There's this line from the Lord of the Rings books where they, they discover some like wonderful cavern and Gimli tells Legolas, That he wished he had some of his kin to come and work on it in Legolas.

It's like, you would make changes to that? It's so beautiful. And Gimli says some line about, we would only remove one rock every hundred years to try to make it better. And that's kind of, that's kind of how I feel that they're working with Coriutils. We make one breaking change every 20 years. We didn't, we didn't get to ask him about it, but apparently Coriutils itself has.

a really good record when it comes to security as well. Something like only five CVEs in the last, you know, 13 or 20 years, something like that. And I wish I thought of that during the show to ask, to ask him about, but it's, they're really doing great work. Absolutely.

Dan: Yeah, definitely.

Jonathan: All right, well I think that is, that is it for Core Utils.

Do you have anything that you want to plug, Dan?

Dan: Yeah, I should mention some people, longtime listeners of, of FlossWeek who will remember an event called OggCamp that I used to run in the UK, which is a free software open source unconference, bar camp style event. It was at one time, the biggest in the UK.

I don't know if it still is. It probably it's hard to say that it still is. Cause this is the first one for five years. So there's going to be one. So the, what I'm doing here, burying the leaders, there's going to be one in October and it's been picked up. Thankfully we got stopped by, we got stopped in our tracks by COVID as a lot of people did.

But the events coming back and it's going to be in Manchester. It's in October this year. You can go to ogcamp. org. That's O G G C A M P. And you can get tickets on there. You can find out what's going on. And I'm not actually organizing it anymore, but but Simon Phipps of this parish is is on the organizing team.

And if you want to get involved, you want to find out more about it, you can come to Manchester and you want to you want to talk or, or, or you know, do a workshop or any of those sorts of things, then let us know and head to orgcamp. org.

Jonathan: Yeah, excellent. So things I want to plug is, of course, we thank Kakaday for being the new home of Floss Weekly and you should make sure and tune in next week because we're talking to Carl Ritchel about Cosmic.

The new alpha release of Cosmic is out with their Rust based compositor, some really fun stuff there. I'm going to chat with him about it. And then of course you can follow my security column goes live Friday mornings on Hackaday. And then we've still got the Untitled Linux show over at Twit. And that is always a blast.

That is every Saturday. And we have a lot of fun there talking about Linux news and some open source news as well, but it, that's a, that's a much more Linux flavored show than this one is. But you should definitely check that out as well. I very much appreciate Dan being here as co host and we appreciate everyone that watches and listens both live and on the download and we will see you next week on Floss Weekly.

This week Jonathan Bennett and Dan Lynch chat with Pádraig Brady about Coreutils! It's been around since the 90s, and is still a healthy project under active development. And you've used these tools whether you realize it or not!

- https://www.gnu.org/software/coreutils

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/

This week Jonathan Bennett and David Ruggles chat with John Britton and Mike McQuaid about Homebrew, the missing package manager for macOS, and Workbrew, the commercial offering built on top of it. We cover lots of territory, like why the naming scheme sounds like it was conceived during a pub visit, how Workbrew helps businesses actually use Homebrew, and why you might even want to run Homebrew on a Linux machine!

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/

Jonathan: Hey, this week David joins me and we talk with John Britton and Mike McQuaid about Homebrew, the package manager that macOS is missing, and Workbrew, the new commercial offering built on top of it. It's a lot of fun, you don't want to miss it, so stay tuned. This is Floss Weekly, episode 796, recorded August 13th.

Homebrew! I'm more of a Whopper guy.

Hey folks, it's time for Floss Weekly. That's the show about free, libre, and open source software. I'm your host, Jonathan Bennett, and we've got something real fun today. We've got, first off, David is in the secondary hot seat, the co pilot chair. He's my wingman. He is the co host today. David Ruggles.

David: I'm holding it down. Yes. I'm holding it down.

Jonathan: Yeah. Now today our, our topic is. Well, it's, it's Homebrew, which is the package manager that Mac OS wishes it had. And neither of us are big Mac guys, are we?

David: Hmm. No I use it. At least once a week, but not extensively. So yes, I have, I have lots of questions that will be the, uh, Luddite.

Jonathan: You're our audience proxy for, I don't know much about this. That happens. That's fine. I have, I've actually used homebrew back years ago we were talking about before the show, I was a part of an organization and someone else that was there was a huge Mac fan. And so they bought some Mac machines. And the whole time I was going, he was.

Associated with the military, so the whole time I'm going, I know he's going to move away, and I'm going to be the one stuck administering these machines. And guess what happened? Yeah, I was stuck administering the machines. So, I installed Linux on one of them, and I installed Homebrew on the other. And we, we made out very well with that.

So I've got a little bit of homebrew experience and a little bit of Mac experience, but, you know, rather than us talking about what we know and don't know about the project, let's bring, let's bring the guys on. So we have John Britton and Mike McQuaid. Let me see if I have this right. John is the business guy.

And Mike is the homebrew guy. Is that, is that sort of the way the land lays here? 

Mike: Yeah, I don't know if John likes it put that way, but I'm fine with that description.

John: Yeah. I mean, I definitely wear more of the business hat, but I'm also a software engineer. So, you know, being called a business guy is a little bit rough right now.

Jonathan:  It looks like you're wearing the Tron hat. Yeah, I like it. Okay. So first off, how did, how did we do about, about homebrew? Let's start there and then we'll get into this kind of the, the, the business thing that's going on, but I want to know first, let our folks know. And so obviously this is probably a question mostly for Mike.

What, why, why would somebody use homebrew? What's the point?

Mike: So my I guess description for non tech friends and family is generally homebrew is a app store for open source software, essentially. And if they want to get deeper on that, you can go down the line, the fact that it's mainly both the software installed by Homebrew and Homebrew itself are primarily operated through the terminal.

So yeah, basically that's, that's the starting point of why you care about homebrew.

Jonathan: Yeah. And it's, it's all, is it all open source? Like, so I, I'm pretty sure that homebrew itself, the entire thing is open source, but all of the software that you go out and grab now, how much of it do you build from source at install?

It almost seems like that's one of the things that you at least can do.

Mike: Yeah, so that's a differentiation between kind of two parts of homebrew, like the original and some stuff that's come later. So originally homebrew was, everything was built from source on the user's machine. So I guess you would call it like a build from source package manager.

Yeah,

and over time homebrew decided that we were going to take more of that open source software that was built from source and build it ourselves. And then now we build everything ourselves. So most users most of the time are going to be given a pre compiled binary package, what we like to call a bottle because everything in homebrew has like a beer metaphor running through it.

Right. But then over time there was a project that it started off as its own separate project, but it's been brought into homebrew proper now called casks. So we have things called formula, which are used to install things from source, which are open source software. And then we have casks, which are used to install Software that is a binary that we get from somewhere else.

So a classic example of a formula might be something like W get or some other command line tool you're used to interacting with or my SQL or database or whatever. And then a classic example of a cost might be something like. One password or Google Chrome or zoom or something like that, where essentially the, the flow otherwise would be download from a browser, click, click, click, whatever.

Jonathan: How long, how long has homebrew been around? Like what, when was the the initiator of this idea? When did somebody first start writing code to make it happen?

Mike: So yeah, Homebrew turned 15 this year in May, if I remember quickly, it was created by a chap in London called Max Howell who was working for Last.

fm at the time. That may bring back memories for some of you that's, I'm sure they still exist, but you know, less widely used nowadays. They once were so yeah, he basically was exploring different package managers. And he could never find one that kind of quite, met his needs and I think he was nudged by someone in the pub one evening to go and well you know if you hate them all so much why don't you make your own one and he did and that's that's the future really and so yeah so that that was 2009 and then I got involved with homebrew Later on that year, like, I guess, September 2009 or so I, Max was a friend of a friend in London and I heard about it and I was also dabbling in package manager things and I sort of just started contributing and never really stopped, I guess.

So yeah, 15 years ago is a couple of,

John: I was just going to say a couple of months ago we had Max over and we did a live stream kind of going through the history of 15 years of homebrew as well.

Jonathan: Okay, cool. Is Max still, is Max still involved with the project?

Mike: No, he's doing his own things nowadays. Sure. He was involved for kind of, I guess, maybe five years at the beginning, and then he sort of handed it off to others.

Jonathan: Yeah, that, that's great. It's one of the, it's one of the problems we see with some open source projects. It's like even really popular ones where somebody starts it and it's like, well, I guess enough people like it that I'm stuck here for life. And so like genuinely good for him that he was able to get off the boat.

And the boat didn't crash.

John: Congratulations. Your open source project is successful. You have an unpaid job for the rest of your life.

Jonathan: Yes. Well, it's a, it's a huge problem. It really is. And you know, there's the, the, the classic XKCD comic. Like you have this, the whole, you know, massive software stack, all the building blocks, and you have this one little piece that holds everything else up.

And it's like, this is just maintained for nothing by, by one guy in Kansas. And the scary thing is there's multiple projects like that. Like you can talk about the network time protocol has been that way for the longest time. Even things people don't know about, but are super important, like the term info files.

And there's legitimately only like three people in the entire world that actually understand term info. I think I'm, I'm fully convinced of this, but you know, if, if those break, we're all in trouble. So. Let's, this seems like a good place to at least dabble in the concept. I, I've heard of something called workbrew, and it is apparently related to homebrew, and it is apparently also you guys.

What, and this is probably, if I understand the lay of the land correctly, this is a question for John. What is workbrew, and why, why are we trying to do it?

John: Yeah, so homebrew, is, you know, insanely popular, used on Mac OS. There's more than 30 million devices with Homebrew installed. And it's pretty much made to be a single player experience.

You sign on to your machine, you open up a terminal, you install some things, it's all managed kind of on your machine. And what we're doing with Workbrew is trying to make it so that It's more of a multiplayer experience. It's built for teams. It's built for companies so that you can have a kind of a shared set of developer environments across all your machines, a shared set of policies, a shared way to manage and deploy and install, get analytics and observability, know what's going on within your fleet and keep everything secure and compliant.

So what we're building now is really. focused on how teams are using Homebrew day to day and trying to solve their major problems. So I think you know, maybe Mike, you want to say a little bit more, but I'd say that's, that's kind of the starting point.

Jonathan: Yeah.

Mike: Yeah, no, I think that's

Jonathan: a good start.

Okay. Now is, is Workbrew open source as well?

John: Workbrew is not open source. We're built on top of Homebrew. I like to think about it as kind of complimentary. So at the foundation of work brew, we're using brew, the open source package manager. We don't have a private fork. We don't have our own custom version.

It's exactly the same as the open source project, but on top of it, we build a bunch of complimentary tools for deployment, analytics remote management, security and compliance those types of things. And our approach, I think this is actually probably the topic that's worth getting into in a podcast like this.

Sure. Is our approach to commercial software in an open source world. So as you know, homebrew is an MIT licensed open source project. We, BSD, BSD, apologies BSD licensed open source project. And we basically upstream all of our changes that are necessary. So anything that, that needs to be. Available inside of brew as the core kind of foundation we make available to everybody.

Then there's kind of a line and that line is pretty well defined and it's multiplayer. It's enterprise like kind of security and compliance features. It's managing remotely. It's all of those types of things that are on top of homebrew that are closed source. We don't make that available open source right now.

Jonathan: Yeah, and that makes sense. I think it's going to serve you well that you've, you've figured out that line and you have a a clear delineation and you make it clear upfront that like, this is the, this is the part that's always going to be open source. This is the way we're going to manage that. And then this is the part that we're going to build on top of it.

That's not. And at least I, as a potential user, I, I really appreciate that. And so do you, do you generally pull from the same like list of packages? So for one, I understand WorkBrew is going to be doing much the same thing. We're, we're installing extra packages on Mac. I think

John: something that's, that's useful to explain about Brew is kind of the two components.

One component is the CLI. So it's the actual package manager responsible for putting software onto your device. And then the second kind of component. Is the packages themselves, the library of, you know, as Mike was saying, formula and casks The homebrew project has two official kind of package repositories.

One's called core and one's called cask. In homebrew core, you'll see all of your built from source packages and in cask, you'll see all your binary distributions. A lot of that stuff may not be open source. Some of it may be open source to distribute as a binary from the upstream vendor, but ultimately you have those two components.

So when it comes to workbrew you're still using brew, the open source package manager, and you're still able to use the library of packages that are available for homebrew in core and in cask, but you can also create your own taps as they're called in homebrew speak that are repositories of your own internal packages distributed, you know, within your organization and you can kind of set rules and, and manage how that stuff is done at an organization level.

So that's kind of where the delineation is.

Jonathan: Yeah, that that makes a lot of sense. Yeah, David, you I'm sure you're chomping at the bit. We haven't let you got anything in yet.

David: So a couple of questions just from listening to you there. The first one, I noticed that you refer to brew and homebrew and workbrew.

So what are the, like is Brew core to both Homebrew and Work Brew, or is Brew and Homebrew synonymous? And just a shorthand. I'll

Mike: get this one. So essentially like we, we often use brew as a shorthand for either home brew or work brew because Brew is, that's the, the CLI. command that you type in to your terminal if you're Workbrew.

I guess to jump back a little bit because it might be interesting again, like the approach that we're taking and it might explain how things fit together. So essentially the flow for Workbrew is you run our installer. And our installer installs some workbrew stuff and it installs homebrew so homebrew is installed completely normally to the normal location but we just do some stuff where if you were to go and say that to the homebrew open source project they would be like why would you do that but because because we have a bunch of homebrew maintainers and People like me who have worked on homebrew for 15 years, like we can do some slightly more unconventional things with homebrew.

But on your system you still have a completely unpatched, normal, open source version of homebrew running on your system. But then we have essentially like a wrapper that we have on top of that. So when you run brew and you have workbrew installed in your system, you run workbrew, which then calls into homebrew.

But the essential behavior for end users is it looks exactly the same. So I guess John talked on this earlier, like me as a kind of long term lover of open source software, I kind of like this approach of kind of combining the two because it means that Both the open source software, Homebrew, gets better over time, but also we have the way, as John mentioned, like the realities of kind of making commercial software in an open source world where we can't give away everything for free or it wouldn't be a business, right?

So, yeah, I think you get the nice best of both worlds. And the other kind of fun, I guess, analogy I've used with this stuff is it's like My apologies to John, who's heard this particular analogy about 8, 000 times is it's like Lego, right? I don't know how much any of you are playing with Lego nowadays, like, but my, one of my kids is super into it.

And Lego now feels pretty different to what it used to be, where I remember like there was a lot more modification of models and stuff like that. Whereas now it's like a pretty hard line between like the super, customized, this Lego T Rex comes with a particular claw that is made only for this one piece and you can't use it for anything else really.

Or you just buy a bucket of a bucket of blocks and you assemble it and make it up yourself, right? Like essentially what we're doing with with workbrew is if, if you look through the pull requests that are open by me and other people in the last year or so, you can probably see the blocks of how you could go about building your own workbrew.

But I guess our value proposition is essentially like, well, we, we built it for you and we can support it for you and everything like that. So. You know, maybe you're better to buy it off us, but the open source project still has a lot more of these kind of like hooks and things that you can plug into that makes the open source project better and more useful for people as it goes along.

Jonathan: Yeah,

Mike: absolutely.

David: And the the next question that I had as I already established at the opening, I'm not great I don't have a lot of Mac experience other than some user and I've maybe I've used brew once or twice. But I do have Linux experience an open source experience. And so kind of relating brew to.

Package managers, I'm used to I have two questions and you can answer them. However you desire. The first one is, do you have package maintainers that are responsible for specific Applications within, you know, that homebrew would pull down. And then the second one is, you mentioned taps as something you could do inside your corporation as kind of like your own repository.

Are there. Publicly available taps that are like maintained by people not directly related to homebrew. I'm thinking of kind of like PPAs and Ubuntu.

Mike: Yep. So in terms of package maintainers, I guess that's an interesting thing with homebrew is that we don't have specific package maintainers. We have like somewhat officially unofficially People who might maintain individual packages, but the maintainers of homebrew are relatively few.

So we've got, I think, 30 something people right now and between them, they essentially maintain everything. But that doesn't mean that they do everything because homebrew was built with GitHub and collaboration in mind from the outside. I think Max on the, the video call that John mentioned earlier that we had to kind of talk about it, like one of his things from the outside.

I'm sure you won't mind me saying this if you didn't use this exact word was essentially to be lazy and be lazy. Okay, I don't want to maintain everything by myself, so how can I build this from the outset such that essentially the community maintains this and I don't? The other difference we have nowadays is we have very, very, very heavy amounts of automation to essentially detect changes and keep things up to date and things like that.

But I guess to specifically answer your question, though, we have a slightly different model where We don't have like hundreds of different people who each maintain one or two packages. We have a small number of people who maintain everything and like review community contributions to all of those things.

The next question about taps. Yeah, we have essentially the tap model is very similar to a PPA model or something like that where any arbitrary person on the internet can just decide to set up a a tap and then by default the easiest flow is having them on github but really you can put them anywhere where you can have a git repository.

I mean technically they're just a folder on a disk so any way that you can get a folder onto a disk and keep it relatively in sync you can make that a tap and they behave much in the same way regardless of whether they're being maintained by homebrew ourselves or whether they're being maintained by the community.

It's more just like we set a higher standard for like both. The licenses and stuff like that and styling and, you know, making sure our best practices are followed that the community don't have to do, and may decide they don't want to do, may decide they can't be bothered to do and that's basically how that kind of ecosystem fits in.

David: So, one follow up question. How many packages is everything?

Mike: Right now, I think it's about 20, 000. Oh wow. Between all of the formula and all of the clasks, so 20, 000 official ones. So if you go wider onto the, all of the third party taps and stuff as well there is probably considerably more than that but basically at least 20, 000 or so.

That's, that's,

David: that's astounding. Yes. Especially for a small team as you have maintaining it. And you've mentioned CAS several times, which I understand because you've explained that and you talked about formulas, but I've heard references to bottles, what are bottles and how do they relate?

Mike: So a bottle is basically like the original, as I mentioned way home we worked was it's was a build from source package manager.

So the formula, I guess it fits more obviously in the metaphor and the original stage in a formula. If you imagine a formula for a beer, it might say, you know, I want Whatever. I don't make beer like some sort of liquid and some sort of not liquid and mix them together and you get a, some sort of beer.

But so essentially a formula is a series of build instructions for like how you take an upstream source. So like say something like, w get the tar ball containing the source code for Wget, how you would go and run various instructions on your machine and produce a binary at the end. So what we do nowadays in Homebrew is that formula for most of the people most of the time is only essentially used for building a binary package on our servers.

So when that formula is modified on GitHub, then we will run through those instructions. We will build a new bottle, which is what we call the turbo that contains the binary package. And then we then upload that to, we use like GitHub packages to store our all our binary software basically. And then when a user types brew install on their machine, instead of doing through all those steps or essentially just downloads that binary package, that bottle, and it will pour the bottle extracting the tarball into the place on disk.

And then a user can have that up and running. And for, you know, for, for smaller things, the time difference is minimal for larger items. If you have a relatively normal slash fast internet connection, you can do that. you're talking about the difference between, you know, less than a minute versus, you know, even on high end hardware, like four or five, six hours to compile some of the really big meaty stuff.

So it can be a huge time saver for certain people and users. And it's also a lot less hour prone.

Jonathan: Somebody had a lot of fun coming up with that extended metaphor and figuring out all the ways that it fit. Well, I

Mike: came up with that. So if you want to blame anyone for that particular strange metaphor, that's me.

And then most of the original stuff was Max.

David: You can definitely tell that this was developed on a napkin in a pub.

Speaker 5: I think we're looking

David: around the room creating parts of the infrastructure.

Mike: Yeah, well, the first commit ever to homebrew is interesting. It's something I actually, I did a bit of at GitHub when I worked there as well, and I recommend it for people when they're doing projects is this idea of like readme driven development.

I don't know if you've heard of that before, but the idea being before you start a project, essentially start by writing the documentation of what you think. it should look like and how it should work. So thinking from the outside in. So that's how Homebrew originally worked. And if you look at the first commit to Homebrew, the first commit is actually a readme of how Homebrew works, despite the fact that there's no code at this point.

And yeah, and the last question in the readme is, was Homebrew conceived while under the influence of alcohol? And the answer is yes.

David: Both Unix and Linux were conceived under the influence of various substances.

It's true.

Jonathan: All right, I'm going to jump in and I want to ask John a couple of questions about Workbrew in particular, and Let's see. So I'm, I'm assuming that the way we could set this up is a business would, would say, look, these are the packages that we want to allow people to install on their machines that we're, we're in charge of, and then we have this whole other block of packages that we, we don't want to allow.

Like, that's the sort of tooling that, that you guys give with WorkBrew, right?

John: To some extent, I think like I would actually preface it by saying that for us, the most important thing is a developer experience. Brew is kind of a tool, a tool belt for software engineers. They go to brew and they get all the things they need to do their jobs.

The reality of the situation is that companies, especially in highly regulated industries, you know, we talked to a lot of banks, a lot of you know, FinTech type companies, governments. Insurance companies, healthcare. The rules of the road there are just, you have to do certain things a certain way. And so rather than think about it as a way to limit folks and what they can do, it's more a way to enable developers to continue to use the tools that they know and love at

Speaker 5: work.

John: So we think about it as without Workbrew, the people in those companies would be told, no, sorry, you can't use brew. It doesn't meet our security and compliance requirements. And so with Workbrew, what we do is we make it so that. The IT folks, the security folks are able to feel comfortable with the risk profile of giving end users, developers, the ability to go out and install 20, 000 different open source packages.

And in some cases, you know, especially the financials that I talked to, they have some requirements around things like data protection, data loss protection. So they don't want to allow anything that opens up tunnels in the network. So particular VPN packages, wire guard. You know, Ngrok, stuff like that, where You know, they're honestly like useful tools that are not necessarily nefarious, but because of the risk profile of those businesses, they just can't allow it.

And so that's really where the kind of security and compliance type of, you know, restrictions come in and work brew. And with every customer that we work with, we talked to them about, you know, the developer experience and how they can maintain a positive developer experience. And instead of, you know, You know, using hard and fast rules, setting policies that they can monitor and see if, if something is out of policy.

So every every user that we have, generally the way that they come on board is they do a complete audit of every package that's installed on every machine. Yeah, homebrew. This is a huge amount of information for them. They had no visibility previously as to, you know, let's say they have 500 engineers, 1000 engineers, what packages were being used, what their, you know, potential surface area for attacks was, whether it's supply chain attacks or, you know, other kinds of data loss or things like that.

So they can do an audit and they can see everything that's happening. And then once they have that information, you know, They can take steps to provide alternatives rather than just say, Hey, this is turned off, you have no access. We give them a way to say, Hey, the preferred tooling for this job is X.

And we really are excited about the features around kind of collaborative developer environments for software engineers. So the idea is that rather than each person in kind of a single player mode managing their entire kind of development stack themselves, if one person finds a problem, whether it's a security issue, a productivity thing where they can move faster, When they make that change, they're able to share it with their entire team, you know, seamlessly.

So that's, that's some of the ways that we think about, you know, The same thing that you were saying, but really from a first principles, you know, mindset, why are we doing this?

Jonathan: Sure, sure. Does either work brew or and or home brew provide like automatic updates? Or do you have to go in and say, all right, all the packages I've installed, go check for new updates and install them.

John: I mean, the short answer to that is kind of it depends what you want. This is another one of kind of the principles that we're trying to follow, which is one size doesn't fit all. We have, you know, these fast moving tech companies that really want to embrace the cutting edge and they always want to have the latest version of everything all the time.

And on the other hand, we have, again, these highly regulated industries where they say, I know that a new release came out, but we cannot deploy that new release into production until a human has reviewed it. Yeah. They've created a signature, we've entered an entry in our audit log, and we've allowed it to enter the production environment, right?

And so these are two polar opposites. So, our principle here is like, one size does not fit all. We want to give people the ability to kind of choose how this should work. And Mike can talk about, you know, Homebrew's auto updating. Facilities.

Jonathan: Yeah. I'm curious about that too. Mike, I'll let you take it for a minute.

And, and what, what's the solution there with, with homebrew itself?

Mike: Yeah. So homebrew by default will basically. Almost every time you run a significant command, it will auto update itself and it will try to ensure that it always results in a consistent state, which involves, it will do things like auto update, auto upgrade, like reverse dependencies and all this type of stuff.

So I, I guess in general, like Homebrew is a developer tool, like my, thinking is if you ever are having to have in tools a thing where you say, Oh, if you run this command, make sure you run this command afterwards, then that's generally not very good UI, right? Right. So my, my goal is over time that Homebrew essentially, you can just get away with installing software and everything else that you might need to do running updates, doing cleanups, upgrading things, getting rid of things you don't need anymore, auto removing things you don't need anymore, like all of that stuff is done.

fairly seamlessly and automatically. And I guess another note related to a couple of things that came up before it, I guess we haven't mentioned explicitly in the school before, but I would be Sad if I were not to mention the fact that Homebrew also runs on Linux, which is, it may seem slightly strange as to why one would ever want to do such a thing.

But one of the cases we've seen on Linux is I guess what John mentioned earlier, where one of the things with Homebrew, because it's a rolling release package manager, which essentially means when Homebrew can get the latest update of a thing and it works and it doesn't break Homebrew stuff, then Homebrew will upgrade to a newer version.

We've seen people using You know, a more stable like base layer OS, Debian, Ubuntu, whatever, and then they might install. homebrew somewhere on their system on Linux and then they can get access to kind of maybe the bleeding edge for certain developer tools. Like if you have, I don't know, like a classic, like a CLI I love is RIP grep.

It's a RG is the command and it basically just does really, really, really fast recursive grepping through folders and stuff like that. It's what VS code uses for file finding text and files. So a tool like that, for me, it's like, I, If I want a Linux machine, I get frustrated if I have to wait, you know, like months for someone to get me the newest shiny version of RIPGrep.

And also the blast radius, if it, you know, If it doesn't work, then it doesn't really impact anything else in my system. Right. So then you, you can get this nice combination. And in a funny way, that's sort of how Homebrew works on macOS as well. In the, the, the reason why I'm drawn to macOS is because when I was using Linux I'm too much of a tinkerer and I would just continually break my system by being like, Oh, if I, if I increase, I'm showing my age a little bit here.

If I change X. org settings to do this, then maybe The refresh rate will look slightly nicer. Oh no, I'm stuck in a terminal for 24 hours, all this type of stuff. Whereas the, for me in the macOS world, like essentially apple of like nailed down that that trunk of my bonnet, as we'd say over here to my car.

So I can't get inside there. And that's for people like me, that's better for other people. That's worse, but you can sort of have a more Mac like. feeling with your package manager if you run homebrew Linux in that way.

Jonathan: Yeah. So I was going to, I was going to ask about, I have a little note here on my notes to ask about running it on Linux.

So this, there's a question that obviously follows up. Can we run workbrew on Linux? Does that make any sense?

John: Yes, but I would say not yet. This is something that we've talked about. I've had definite, definite interest from folks we've been talking to just have consistency across all platforms, the ability to see what's happening everywhere and be able to remotely manage them.

We don't have folks using Workbrew on Linux today, but I expect we will in the near future.

Mike: Okay. And now we have internal prototypes, basically, right? We have not yet released for what, but I mean, essentially homebrew works similarly enough on both cases and our internal prototypes are, it's the type of thing where it's the classic engineer thing of if I was earlier in my career, I would say, Oh yeah.

We could have a Linux version out in a couple of days because it all compiles, right? Like that's, that's the easy bit. It compiles, what could go wrong? Exactly. I, I've learned enough over the years that I'm like, well, you know, there's, there's probably more, the iceberg here is probably. Perhaps a little deeper than I might want it to be so

Jonathan: yeah in the past 24 hours.

I've pushed code that compiles I was that developer today within the past 24 hours Now work workbrew is available though like not not the Linux side of it yet But on on Mac if somebody really if like if this is the tool that meets their needs work workbrew is out there They can get it

John: Today, the way to get Workbrew is to come to our website, workbrew.

com get on a call with me and I'll show you around. We expect very soon probably in a matter of weeks, to have it publicly available for folks to just get on and try. But right now it involves kind of a conversation with us to see if it's a good fit for you. And really the reason for that is that we're We're looking for design partners.

We're looking for companies. We're looking for for teams that See the same set of problems that we see With using brew in a team environment and who really want to give feedback and help us build this tool together but we have it in production with a number of different companies. We use it ourselves every single day So it is there and it's up and running but it's not entirely self service as of this moment,

Jonathan: right?

What's the what's the uptake look like? Have you had quite a few companies that are a good fit that have come on? You

John: We had a really interesting situation maybe a couple of weeks ago. Mike was interviewed on the next web and there was an article that led to quite a lot of interest. Over the last few weeks, I've basically been in nonstop conversations with lots and lots of name brand companies that you've probably heard of, but I can't talk about.

But again, many of them are in these like kind of regulated spaces where it's, we're a finance company, we're a healthcare company, we're insurance, we're government you know, some kinds of, you know, different. Use cases for exactly the same thing. It's all different industries, but they're all saying, we'd love to use this, but our requirements are such that the open source thing just doesn't, won't fly here.

And really there's kind of like three stories that we see at companies. The first story is do nothing. They just let brew kind of be the wild west. Every developer who wants to use it just installs it on their machine and IT and security look the other way. The second kind of big category of folks is, you know, this informed trust model where You start at the company, there's a readme that says part of setting up your dev environment is installing brew, installing these 27 packages, here's a guide, probably the guide's out of date and it doesn't work when you first start, and then if something's wrong, there's that one expert who's done a lot of stuff with brew that you go and ask for help and that's really, really common, and then kind of the least common, but pretty popular case, especially among very large companies, is that they have some kind of internal tooling built around this already.

So they'll build custom scripts to integrate with their MDM tools so they can manage a fleet wide deployment of brew. They'll build scripts to do things like inventorying what, what packages are installed on their devices, reporting version numbers, and cross referencing that with vulnerabilities databases.

They'll do things like add self service scripts to their MDM tools so that End users who don't have admin privileges on their devices are able to install brew packages. But the downside to that is that for every single package in brew that your company uses, you have to have a staff member who's like maintaining that in your MDM tool, keeping it up to date, keeping it in sync.

It's just like unbelievable the amount of hurdles that people go through to make this work. And so yeah, the interest has been phenomenal. People are very interested and kind of those three categories of folks, they all hear from us and they say, wow. Why, why has this taken so long? Why hasn't this been here before?

Like, it's so obvious. So yeah.

Mike: Building as fast as I can, John.

Jonathan: And I assume part of the, part of the sell is, rather than you have to have this one guy at your business that understands brew, you've got the actual brew guys that understand brew. And you pay us enough money, you can call us and we'll fix things for you.

John: Yeah, that's definitely part of it. I mean, Mike is very generous with his time with our customers in terms of getting them up to speed on what needs to happen with brew.

So, yeah.

Jonathan: I mean, that's sort of a win win for everybody though. Right? Like I know how to do this very specific thing. You need somebody to do this very specific thing. You give me money and I do the thing like that's.

John: Well, the really beautiful part of this whole thing is it's not just one company that needs this.

Jonathan: Right.

John: They all, they all need the same thing and doing it once and making it, you know, reusable and, and, and packaged in a way that every single company that has this problem can adopt a standardized tool. We're basically saving an entire team's worth of effort at every one of these companies, right? And so, the individual kind of ROI calculation that each of these companies has to do is incredibly obvious that it's the right decision for them.

You know, rather than paying a team, you know, I could, I could list off maybe five or six of these companies that everybody knows and uses their products every single day, and they all have teams of people that are managing this problem. And in every single one of those cases, They would get a better solution from us.

It'd be more purpose built. It'd be more highly integrated with Homebrew. It'd be less maintenance costs for them. Less kind of distraction for their teams to have to manage it. It's just a very, very easy decision for them to make the buy versus build decision because, you know, the lack of expertise, the ongoing maintenance costs, what happens when a new version of Brew is released, what happens when a new version of macOS is released.

You have to, you know, You know, if something doesn't work, when one of those events happens, every single engineer in your company is stuck.

Speaker 5: You

John: know, that's a high cost.

Jonathan: Yeah.

John: So, you know, we make sure that never happens.

Jonathan: Just, just make sure that you, you, you don't pull a CrowdStrike and

John: Oh, absolutely.

Mike: I would be remiss if I said that, that, that hasn't been a thing that has been talked about recently when we've been talking about, deployment strategies and things like that of, yeah, there's there's ways to do this and ways not to do this and let's not do it the way that maybe doesn't always go so well.

Yes.

Jonathan: Yes. Have you gotten to the point to where particularly based out of these conversations with businesses, you've started adding things that you hadn't thought of to either work brew or home brew?

John: Oh, absolutely. That's kind of the biggest thing that we're doing right now is just listening to these customers about the problems they face and trying to build the most general solution.

I mean, Mike likes to say this thing about the baby. Do you want to give your kind of baby analogy about how this works?

Mike: So my, it's funny, at Homebrew, I'm probably the closest thing Homebrew's had to like a product manager, at least since Max left. Yeah, I guess. Working at GitHub for 10 years, I saw some product management done very, very well, and occasionally some product management done less than perfectly.

And something I feel like I learned from this stuff over the years, particularly when your audience is developers, is the line I like to use is users are, or customers, or developers, or whatever you want to pick. Or like babies in that they can cry and tell you that there is a problem, but they cannot tell you what the solution is to the problem.

The tricky thing is, developers compared to actual babies even if those babies may one day grow up to be developers developers tend to tell you, go jump straight from, I have problem to, and if you tasked me with how I would build this solution, how would I build the solution? And they come to you saying, what I need is, the solution that I would have been tasked with building.

And often they don't necessarily have the context that you do. They don't maybe think about like, what are the average users like? So a classic thing that this would come up in Homebrew quite often and the nice thing in Homebrew is you can just decide to do these things because it's not as higher stakes as certainly GitHub was and Workbrew is increasingly becoming is.

On homebrew, someone might say, Hey, I've, I've added a new option that I want to opt into for this particular behavior. And then I read it and I think about it for sometimes not very long. And I'm like, why would you ever want that option turned off? It's essentially like, I, I've added a flag. So when you run this homebrew command if I have my face puncher plugged into my USB port, it doesn't punch me in the face.

So I sat homebrew underscore, no punch me in the face, please. Right, and I'm like, well, maybe punching you in the face could be opt in. You know, like, let's flip the logic around. Or maybe let's just make homebrew punch free software. Like, maybe we can skip this flag altogether. So, to me, like, that's the type of stuff that comes up.

And again, I don't blame any, you know, Person who makes a PR like that, because they're, they're trying to be a good dev and be like, okay, I need to, I don't, I'm not sure that anyone except me cares about this. I want to narrow the impact radius here, but I can look and be like, well, actually everyone cares about this.

Jonathan: Yeah, it's, I don't want to break anybody's workflow. Right. I don't want to. Stop overheating when you hold the space bar down for everybody. That might be important to somebody's workflow. And, and that I did the, the, the baby analogy. I like that, David, I'm sure you get this too. Like a customer will come to us and say, I need this.

And then they'll, they'll tell you this most off the wall thing. Like, yeah, I need a new server. That's got a GPU in it. You need a one now. And then you, okay. What's the problem that you're having? Well, we'd like to be able to use. We'd like to be able to do this. And it's like, Oh, we need to get you an account at, you know, chat GPT.

We don't need to build a server. It's got a GPU in it. I'm sure you get that too, David.

David: Reverse it. You kind of have to, you're given instead of. The baby crying, they come to you with a solution and then you have to reverse engineer the solution to figure out what the original cry was. So you can give them a better solution to

John: your original question, though, about like, what have we built?

That's come out of, you know, customer conversations. We've had a number of, you know, customers come to us and are kind of very You know, common customer profile is ahead of I. T. Somebody who's responsible for managing you know, their MDM at the company, like the jam for Kanji or one of those type of tools.

And they'll come to us and say, Hey, one of my jobs is software patching, and I need a way to know when something has a vulnerability. And how I can really quickly fix that vulnerability and know that it's been fixed across my entire fleet of thousands of devices. And so we built a vulnerabilities dashboard that effectively takes a look at every single package installed across your entire fleet, catalogs all the version numbers, knowing exactly which version is installed on each device, and cross references that with a bunch of different data sources where we have information about all known vulnerabilities in those packages.

And we present this as a nice simple report for this IT manager to say, Hey, package X has a vulnerability at this version and it impacts 205 devices at your company. Click this button to apply a patch that fixes that on every single device. And after about 15 minutes, you can see 95 percent compliance, all of those have been patched, and a few of the devices that were turned off, you know which devices they were, so you can send a Slack message or give somebody a call to make sure they boot up their device and upgrade that package so that the vulnerability is addressed.

And that came directly out of, you know, customer. Customer requests.

Jonathan: Yeah, so you guys kind of provide a software bill of materials for across the whole organization Yeah, yeah, absolutely super interesting Okay. Now with with brew itself. We've talked a lot about command line applications Do we do do we do GUI applications?

Can we install, you know more complicated or less complicated but good GUI based applications Can we do real crazy things? Can we install entire bright light? Can we install Firefox with brew? Is that a thing that works?

Mike: Yep, and not only is it a thing that works so that this is essentially the way I Interact with homebrew primarily nowadays.

So one of the things we've built on top of homebrew was this thing called brew bundle Which essentially the the bundle part of the name relates to if homebrew is written in Ruby and there's a tool called bundle or bundler I guess is the full name that consumes gem files which are a list of ruby gems essentially like third party ruby modules and then builds them all together so you kind of have all these in your app.

So homebrew there's a part of homebrew called brew bundle which does the same thing with brew files where you can basically have a bunch of software In there. And you can specify, okay, I want these formulas. I want these casks. I want these things from the app store, the Mac app store. I want these VS code extensions.

And, you know, probably more to come in future on basically like the way that allows you to use homebrew is instead of. Saying, okay, install this, install that, uninstall this, uninstall that. Instead, you can have a list of essentially, here's everything I want installed on my machine. And, anything that's missing, I want you to install it.

Anything that's out of date, I want you to upgrade it. Any, you know, background services that I specify, I want you to run them. And you can also tell it to do a cleanup, which means any software that is not on that list, I want you to uninstall it from my machine. Which is probably mostly useful to people like me, who accumulate huge amounts of cruft testing various homebrew packages.

But the nice thing with that brewfile is then, you can, Like my most popular not homebrew open source project is a thing called strap I built for primarily originally for github's internal use, but it can be used by anyone And basically what that lets you do is say, okay when I first set up my machine the first thing I want to do is pull down this list from a github repo and I So as long as you're kind of relatively diligent about like dumping software to that list and then committing that to that repo, then you can get essentially a nice single file description of here's everything on my machine.

And if you're one of those people who likes dot files, Like having all your configuration files, like there. That's the repo that I put that in. And again, that tool pulls down your files repo. And essentially my goal with that repo is I should get my machine 90 95 percent set up by just the contents of that repo being pulled down and all these scripts run and stuff like that.

And nowadays I even have all sorts of mad things that Extract secrets from one password and write them to the right locations on disk and and all this type of good stuff And but yeah, but as you can tell this workflow is very heavily github centric right now. So if you are interested in a non GitHub centric version, then again, stay tuned to what brew is up to in the future.

Jonathan: Yeah, interesting. Now does brew, does brew help with doing like program installs without using brew? So like on, on Mac, the the, the, the normal way to install software is like you, you get your package, you double click it and it gives you this nice window with here's the application and here's your applications and you just click and drag can, can we do something real fancy, like build a package in brew and then Spit out that zip that then someone can install without using brew.

Is it, is that in scope?

Mike: Exactly what casks are basically most casks. That's what they do. So if you, the, the Google Chrome cask, effectively what that does is downloads the Google Chrome. So in comparison to maybe a Linux package manager, a Google Chrome cask, that's not some special version of Google Chrome that's made by the homebrew team that just downloads the installer from the homebrew team.

Apples, sorry, apple, apple, not making a crew installs the doubt from Google's website. And effectively that kind of drag and drop or click through and install or next, next, next, accept, license, etc. Like all of those steps are essentially automated inside the cask. So instead I can type brew install google chrome and then at the end I get the exact same result as if I'd gone and walked through those steps manually of the google chrome installer.

And the nice thing about that is it essentially provides a higher level API on So there's about 10, 000 casks, as I mentioned before. That's essentially 10, 000 pieces of software where the API for how to install it is, well, do I drag this thing? Do I click the thing? Do I download it from here? Do I like have to run a terminal command?

No, it's you run the same terminal command for essentially any of those. piece of software and they are all installed the same way. And to me, that's the most powerful thing about both casks being in homebrew, but homebrew itself is essentially you have this high level API for this stuff. And when I was talking about my brew file before my brew file has a bunch of casks in it.

So I'm not just installing my developer command line tools that way. I'm installing slack that way. I'm installing zoom that way. I'm installing like all my like Safari extensions that way. So essentially pretty much all the software on my machine. It's being, in fact, probably literally all the software on my machine that is not provided by Apple is being installed through Humbroo in some way.

John: Yeah. And on the software that's provided by Apple via the Mac App Store. Brew bundle also has an integration with a tool called MAS, which is the Mac app store command line. And so you can actually add to your brew file just like you would add brew in the name of a formula or cask in the name of the cask.

You can add MAS and the identifier of an app in the Apple app store, and it will automate the process of opening up the Apple app store and requesting to install the brew bundle. the program from Apple onto your device as well. So literally everything can be put into this brew file and automated.

Mike: Yeah, that's great.

If there's show notes or people watching along, in some ways it's easier to kind of see rather than do it. So if you Google for Mike McQuaid which is My name, you may struggle with the spelling of that, but I'm sure you'll get there in the end. And then brew file B E R B R E W file. Then you will get the top hit to like my brew file in my public dot files repo.

And then you can see like what that looks like. And please don't critique my particular. Choices of software because don't don't that very near and dear to me. Do it out of me.

Jonathan: Exactly. Now can we, can we go the opposite direction? So let's say, and I've, I've, I have this question because I've had to work through this before.

It's been years ago, but for a while I was developing an applique, a cross platform GUI based application. And one of the things that was a challenge was building that drag and drop installer. So, you know, if you didn't want to tell, so you could tell people, okay, go install brew and then install my application.

But if you don't want to do that, you want to give people that zipped up installer where you just, you drag and drop it and that's it. And it seems to me that there could be a opportunity here to To have a script inside of brew where you run the build and it gives you the installer that then you can go out and Give to people and has anybody done that?

Is that something that that brew can do? I know that's kind of a weird That's it's a weird idea, but I it would have been useful to me back then

Mike: I've seen people do such things in the past. I think what makes it tricky is, well, so I guess the two sides of homebrew, right? So the, the casks, for example, that essentially already exists.

If you have a cask for, as I mentioned, Google Chrome, that's means that that's already been provided by the upstream software, but then with homebrews formulas for, you know, say you wanted to install some sort of open software. Open source software that way. The tricky thing is because Homebrew has its own little special snowflake ecosystem where everything works just such how it does.

Essentially, In Homebrew, everything wants to pull everything else from Homebrew and be updated by Homebrew and be in the location of Homebrew. So that doesn't make it impossible. I mean it, you know, technically it would be possible to do such things, but it makes it trickier. My best actual experience in the past, to give a shout out to another open source project, is this a cross platform build tool called CMake, you may well have heard of.

What's less known is it comes with a thing called CPAK, which is C P A C K. So that basically lets you do cross platform packaging like this. At previous jobs I've used it for essentially generating, you know, like when I used to work on Qt applications for generating a nice click, clicky clicky windows installer or a RPM or deb for you know, Debian or Red Hat based distributions or a Mac OS kind of drag and drop style or like traditional clicky clicky installer.

Like you can essentially spit all of those out from the same project. And that also provides some third party tooling, some of which I may have contributed to myself, that aids in doing things like pulling all the libraries from Homebrew and putting them in the right place and all this type of stuff.

So it's kind of out of scope of the Homebrew project itself, but like, you can. You know, if you, if you look a little bit funny at the problem and take tools like CPAC, then you can definitely rely on homebrew a little bit to solve this problem

Jonathan: a little bit easier. Yeah, sure. Okay. So is there, and it seems like there used to be is it Mac ports is also sort of in the same space that there are some other projects that sort of solve some of these same problems, right?

Yeah.

Mike: Yep. So Mac ports is one think is another. And I guess, yeah, nowadays people are using Nix in some cases as well.

Jonathan: Oh yeah. Is there any cross pollination? Like did some of the same, maybe same people doing the, the, the, the package management or yeah,

Mike: I don't know. So I wouldn't say there might be.

We definitely. We talk to each other. So, and sometimes not, well, I mean, when I say talk, I mean, I don't mean it in the silly way that, you know, normal humans would actually talk to each other like we're doing right now. We, we, we type things at each other on the internet and there is collaboration in some ways between the projects.

Some of it is explicit, like where we might go and we have kind of shared channels with some of these folks. where we might kind of figure out problems. And then some of it is the, in the nicest open source spirit of the world, us, like, various projects stealing patches off each other where, you know, maybe there's some new macOS version or compiler version or whatever it may be, And someone, one of the package managers writes a patch and the other package managers need the same patch so then they can take it from each other.

So we've all, again, there's a nice collaboration where we've all done that from each other. And also sometimes for inspiration where if a particular package is not working on homebrew as well as it should, or we get a complaint and someone says, Hey, this works fine on Mac ports or Nix or whatever, we might go and look and see how they do it.

And again, I'm sure. The same thing is happening in reverse and same with the with the There's probably just as much if not more actually with the Linux package managers as well and the BSDs as well because the BSDs use Clang as their compiler, which is the same as what we use So yeah, so there's basically, it's nice.

It's kind of classic open source Collaboration and action really in that like all these projects because we're all open source We can all share information and resources and help each other out with stuff

Jonathan: Yeah, I have anybody interested in workbrew asked about any of those other other tools. You know, I could, I could imagine someone say workbrew sounds great, but we want to be able to use Nix as the back end.

John: Haven't, haven't heard that one yet. But we have had some folks that are, you know, coming with like cross platform requests. So they say, for example, we want to have consistency across all three major platforms, Windows, Mac, Windows, Mac, and Linux. And it's been particularly interesting with regards to non developers.

So there are definitely companies where they have kind of a wide range of employees and some of those employees are using brew today and they understand it and they rely on it, but they also don't want to have a different system for, for example, our customer service team or for their data engineers or for data science or, you know, folks who depend on code and packages, but may not be as comfortable using the terminal and installing things.

And so we've talked to them about. How can we provide a singular way to provide a developer environment across all three of those platforms? So that's been probably the most similar kind of questioning that we've had from people. But not directly to say, Hey, I have like five different kinds of package managers.

How do I use them all together? More it's like, we use this one thing. It's really cool. How can we make it work for everyone?

David: So I assume on Windows, since Brew works on Linux, you could run Brew under WSL today. But it's the Windows specific stuff that probably needs some

John: Yeah, you can run, you can run Brew under WSL today.

That's how most of the people that I talk to who have interest in it are doing it. So I've talked to potential customers who say you know, we have this 10, 20 people over in this department who are using WSL on windows because X reason, can we get those mapped into work brew as well? I haven't had the same question about, Hey, can you run this natively on windows?

That almost never has come up. But there's a, there are other Rather than saying like, hey, we have this MDM tool, because really the people that we talk to a lot are the ones who are, you know, the IT managers who are responsible for getting the fleet out into the hands of the, of the company's employees and making sure they have the tools they need to do their job.

And so what they're saying is, hey, my MDM tool, whether it's Microsoft Intune, Jamf, Kanji, whatever, has a couple dozen applications in its built in package manager. In Kanji they call them auto apps, in Jamf I think they call them catalogs, but the idea is that, you know, Google Chrome, Zoom, Slack, all of those come as like default packages that the MDM provider keeps up to date.

But they say, well, we have this, you know, this couple dozen packages that are not managed by them, we have to manage ourselves. But Brew manages them, we can use Brew instead. And so they want to standardize on a, on one, one tool for all of this. That

David: makes a lot of sense. So another question that I had was just about the interface.

So you talked to, you mentioned the cross system management and like you talked about how you could, See your systems updating with work brew and identify the ones is that a web portal? Is that something built into the work brew command line?

John: Yeah, the overall architecture of what we ship is Three pieces on top of brew.

So it's brew the open source project Plus we ship an installer PKG file Which is a Mac PKG that basically enables zero touch deployment of brew it makes it so that if you have a brand new Mac You business manager, the first time that you turn it on brew is installed and everything is secured. If you have existing devices with brew installed and maybe dozens or hundreds of packages installed on those devices, you can run the PKG file locally or you can run it via your MDM tool and brew on that device will effectively be upgraded to work brew so that it will have that kind of connection back to the system on the kind of Administrative interface, there's what we call the console, which is a web portal that gives you a high level overview of every device in your system or in your fleet, and it gives you a high level overview of every package.

So you could say, for example, which devices are open is open SSL installed on. What versions are installed? Are there any known CVEs against it? And then run a patch to say, upgrade it to the latest version because there was a known vulnerability we want patched. So that's kind of how the interaction works.

On the device, there's one more thing that like, kind of goes to what I was mentioning earlier. One size does not fit all. So, on the device, we give companies the opportunity to choose different permission models. We call them Restricted, Managed, and Guided. So Restricted is the most controlled. This is kind of useful for individuals who don't know what the command line is, may not have any interest in brew, may not even know what brew is, and you want to manage all their installed software in the same way as every other device.

So you can install WorkPro on their device and essentially provide it in a restricted manner where the end user has no access to the Bruce CLI. It's only managed remotely. So again, great for like a customer service team or maybe data analysts, people who might not be comfortable with the CLI. Then there's managed mode, which is kind of the, Big most popular thing that we're seeing among companies with developers where we install brew on their device for them via the PKG via their MDM tool and give the end user access to brew via the brew secure CLI, the wrapper that we have around brew for the end user.

It behaves. It's just like normal brew so you can do brew install, brew uninstall, upgrade, tap, you know, pin, whatever they want to do, any normal command, and those commands are parsed and kind of made subject to policies or configuration options in brew so that, you know, we keep things secure and compliant.

In those cases, what's really interesting is the end user on the device doesn't necessarily have to have admin privileges. So one of the big kind of points that we hear from, especially the regulated companies, is we can't let people use brew because in order to use brew successfully, they need to be admins on their devices.

And for legal reasons, we're not allowed them, allowed to have them have admin rights on their devices. We just cannot do it. So we basically enable them to give their users the same brew experience that they know and love. without having to offer admin privileges on the device. And then the third kind of mode is more progressive companies that want to give their engineers full access.

It's essentially the same kind of guardrails around policies and how you can use Brew, but if they have admin privileges on the device, they're able to effectively escalate the privileges and go around these guardrails and say, even though it's out of policy, I'm going to do it anyway, so I'm not blocked.

And then the kind of management or the IT and security teams will get an alert to show them that. This device is out of policy or this package is installed in my fleet out of policy and then get up to date that way.

Jonathan: Yeah, so it sounds like you're not planning to bring brew itself to windows.

PowerShell. I was going to ask about that.

John: I think Mike is best suited to answer that. Never say never.

David: It just sounds like pain and suffering though. A follow up question on the whole dependency management. So, I have DevOps experience where you're, you know, developing webpages or web applications.

And so, you need to keep your dev system in sync with the same versions that you're running on your production systems. Do you have anybody using Brew to manage the software stack on production systems? Ah.

Mike: Right now, not really. It's essentially Homebrew, as you mentioned there, like the, the limitation you, you generally have in production is you want to have everything locked down to very, very specific versions that are consistent across your entire fleet.

But That's not the model in which Chromebrew operates by default. That is increasingly the model we're seeing people wanting Workbrew to operate in default. So we are building stuff in that direction. Again, sorry, I can't say too much there, but essentially like that, well, I guess it goes back to the, the babies we were talking about earlier, right?

Like essentially this is, this is a crying baby problem that we are aware exists even in development modes, but certainly the desire to have everything consistent between CI, dev, production that, that is a problem that exists today. There, there is not a great solution to, and there is a problem that we are working on right now.

I guess the Homebrew middle ground there is because Homebrew is a rolling release package manager for cert, it used to be Homebrew was just, you know, You get the latest version or you, you don't get a version, right? Like you have to just pick between. Now, more popular packages with kind of better support for kind of running older versions, say something like MySQL or Postgres or Node.

js, Ruby, whatever it may be, that still provide bug fixes, security releases, etc. for versions beyond the most recent one. You can install a package and you might say, you know, brew install nodejs at 18 or whatever, right, which gets you a like less than the current newest version but will continue to get you patch releases and security updates and stuff like that.

I guess a sort of balance I've seen with this stuff as well is that historically, The enterprise, the maybe individual developer model is let's just have the newest version of everything all the time and the enterprise model has been, let's pick a set of versions that work and then essentially only ever upgrade them if we absolutely have to.

But the problem with that flow is you often end up in a situation where, whoops, we probably should have upgraded this version a while ago and now a bunch of bad actors have got access to our product. either development machines or servers or whatever it may be because we decided to sit on this version indefinitely even when there were security updates that we were too scared to install.

So to me there's a, there's a happy middle ground to be found. Homebrew leans slightly more towards the like, you know, let's have the newest thing of everything all the time. But as I say in WorkBrewland we're building, essentially we already have some tooling there to essentially get that middle ground of like, okay well this package is actually vulnerable right now so I don't care if you're trying to sit on an older version because.

Some perceived view of stability like let's upgrade everyone. So at least they're not in a vulnerable version anymore.

Jonathan: Excellent. All right. Well, we, we have hit the the top of the hour, so I want to get into rap. And one of the, one of the things I want to ask you guys is, is there anything we missed? Is there anything we should have asked you about that you wanted to let folks know about that we didn't cover?

It's kind of challenging question because you've got to do some set math and think about all the things that we talked about, but if there's anything that comes to mind,

John: I mean, I guess there's one thing

Mike: that I might mention, which is, yeah, I think I mentioned like Linux before I'm developing environments and stuff like something where.

We've actually seen quite a lot of use of homebrew that might be worth playing around. For folks who are listening here is homebrew runs pretty well in, if you're using GitHub actions or, you know, GitLab runners or whatever it may be. That's a nice way because the packages are The same on Linux and Mac, and because the versions are in sync, that can sometimes be a nice way to have your development environment and your CI environment in sync, where you might have your developers using Macs locally, say, but then they might have a bunch of tests running on CI boxes, which are most of the time, for cheapness reasons, going to be running on Linux.

So if you do, you know, use a brew file, like I mentioned before, or even just run brew install. go or whatever it might be, then that means you can have that consistency between what you're doing locally on your Mac and what you're running in your CI environment. Yeah. And that can be kind of quite nice.

Yeah, absolutely.

John: I was just gonna say that you know, if this, any of this sounds interesting to you, Mike and I are both available you know, to talk to people. You can find us on our website, workbrew. com. There's a contact form that goes directly to my inbox. I'd be happy to chat with anybody there.

We're also active on, you know, GitHub and Twitter and things like that. We'll give our contact information for that as well.

Jonathan: Yeah, and we'll make sure and get that in the show notes for folks if they want if they want to reach out probably a question mostly for mike Although john, if you have any stories, you certainly can tell us what's the what's the most surprising thing?

Somebody's done with brew. What what does somebody? Message you or written about and you know, I didn't know you could do that with brew Or why would somebody want to do that with brew? Well, I, I'm

Mike: actually going to choose to misinterpret your question because I think you'll find it's slightly more funny.

The version that, so the thing that jumped into my head was almost like, what's the, what's the. What's the stupidest thing you've seen happen with, with homebrew? Stupid can be surprising. Yeah. So my favorite bug of all time actually is we might be able to, if you've got show notes or whatever, like fire me an email or something, you know, I can send you the link because this is open source, you know, you can actually read.

So there's a bit of debugging that went on. Someone was getting some very strange messages when they were running homebrew. And this is in the earlier days of Mac Os. So nowadays Mac ships with a thing called system integrity protection, which essentially means like, look, I don't care if you run pseudo, there's certain stuff on your disc that's more important and we're not gonna let you just like screw around with it.

So stay away. But before they had that, someone was trying to run home Homebrew, getting very strange error messages. And what was figured out was that they had managed to replace bin bash, which is, you know, on a Unix system, a relatively important thing for you to have somehow with no JS. So every time they were attempting to run a batch script, they were getting JavaScript errors in their shell.

So that to this day is my favorite issue I've ever seen on

Jonathan: Homebrew. Oh, that's beautiful. That is beautiful chaos. I love it. All right. Yeah, John.

John: I was just gonna say, just one of the things that I was like surprised about is I can't mention names, but several very large enterprises that make that make a lot of the core technology that we depend on have their own internal forks of brew.

Oh, yeah. And so, you know, they, they're basically maintaining an entire Parallel infrastructure where they're like reviewing everything themselves you know, to get at these like kind of supply chain story, like keeping things up to date vulnerabilities. It's just like unbelievable that it's, you know, brew is that important to them that they can't, they can't decide, Oh no, we just won't use this.

No, we actually, the only option we have is to maintain this ourselves internally as a totally separate fork. So that just kind of goes to the, you know, the idea that it's a very essential tool for a lot of developers.

Jonathan: Yeah, yeah, that's great. All right, so I'm going to ask each of you a final two questions, and that is your favorite text editor and scripting language, and we'll start with John.

John: I mean, this is pretty easy for me. I'm a Ruby developer so Ruby is my favorite scripting language. I, you know, I used to work at GitHub for close to seven years. And I was so happy when I joined GitHub because it was finally a company that used Ruby as like their main language. I had always been like a web dev, you know, my early days I was doing like PHP and like Java and stuff like that.

And when I moved into writing Ruby, you know, at work, it was like the best thing ever. And then I kind of have, you know, A soft spot for Pico. Okay. As my editor, I first, when I started writing code that was the first editor that I learned how to use on a Unix machine. I was running like a Gen 2 box.

Yeah. And old habits die hard. It's like still the thing that I just opened by default in my terminal.

Jonathan: Pico and not Nano? Yeah.

John: Pico, not Nano.

Jonathan: That's great. I

John: have an alias usually.

Jonathan: Makes

Mike: sense.

Jonathan: All right.

Mike: Mike. Yeah, so scripting language, I'm actually gonna disagree with John. So I use Ruby for like proper programming nowadays.

But if I just need to quickly solve a problem, I always go to Bash. Like me and, me and Bash, Bash has treated me so badly so many times. But yeah, I keep coming back. Like I don't know what it is. And yeah, as for text editor, like nowadays I feel like I'm, I wouldn't say begrudgingly, but you know, it feels like a lot of developers are on VS code now, and it makes just life easier for me to just follow the flow and go there.

But yeah, I'm still, I'm still keeping my eye on other things like the extension ecosystem of VS code is great, but like, you know, it's not the fastest thing in the world. And there's a text editor by an ex GitHubber. Called Zedd that is kind of up and coming, written in Rust. It's super duper duper fast.

And I've been playing around with that ever so often. It doesn't have quite all the features I feel like I need, but like, yeah, I, I have my, my hope for that as a potential feature option.

Jonathan: Yeah, absolutely. We, we interviewed a young man back a few weeks ago, building the amber language that is intended to be bash code with some of those bash pain points removed.

That one might be interesting to look at. We had a lot of, we had a lot of fun talking. I kind of like

Mike: the pain points at this point of everything bash does wrong is just, you know, it's like, it's almost like scar tissue that. It feels like it's part of me, you know?

Jonathan: Yeah. I'm, I'm trying to figure out, it seems like we either interviewed or we're going to, ah, I'm in contact with the guys from Zed about hopefully getting getting them on the show.

So watch for that. too. Guys, thank you so much for being here. I appreciate it very much. And it was, it was really fun to get to learn about, about homebrew, which, you know, it's been around for forever. And then work brew, which is a really, really fascinating project. The business that's been built and boy, hopefully hopefully it'll continue to go well.

And maybe here in about a year, we can have you guys back on and talk about what's happened since.

John: Oh, we love it. Thank you so much for inviting us.

Jonathan: Yep. Good deal. All right.

David: What

Jonathan: do you

David: think, David? Ah, I love it. I, of course, as we started at the beginning, I'm not a big Mac guy, but I'm interested in playing around brew on Linux.

Jonathan: Yeah. I tell you what really fascinates me the most is for my use is a brew in GitHub actions like that. I, I, I never had that thought. That is very surprising to me, but you know, as they describe what you can do with it, it makes sense that you know, you're, you're. Your GitHub runner may be running something very different than what your develop machine is.

And having this external package manager that can put the exact same packages on all of them, like that's, that's kind of compelling. So that's definitely something that I will have to keep in mind for the future that could be interesting to do. I like that. I, I'm also just thinking about the conversation we had.

I am, I'm impressed with the way that they are building Workbrew on top of Homebrew, and I, I don't know if you would call that, I don't think you would call that an OpenCore project. I don't think that's fair to call it that. But just that they have this very clear line of demarcation between the two.

And they're pushing features into homebrew as needed to make workbrew work. I think it's a good, I think it's a good model. And I think it'll, I think it'll serve them well. So, you know, looking forward to. Hearing about their success as time goes by.

David: Absolutely.

Jonathan: Yeah. All right. David, is there anything that you want to plug

David: before we let folks go?

Not specifically, but I always like to take the opportunity to plug club twit and the twit network. They're going through changes that I think are positive in the long run. Yeah. And we have fun over there. So come on over.

Jonathan: Yes, we've got, we've got our show that David is from time to time, but co host on.

And that's the untitled Linux show where we talk about all kinds of fun Linux news and open source news. And there's some, as we say, there's some cross pollination between floss and and ULS. Coming up on floss weekly next week, we actually have Pedrag Brady from CoreUtils, and we talked about the Rust CoreUtils a few weeks back, and I got an, I got an email that said, Hey, you know, we're the OG CoreUtils, we'd love to talk to you too.

So we've got them coming on, and looking forward to that next week. We'll be back at our regular time next week on Tuesdays, we recorded a little early today. And then, yeah, we, Appreciate Hackaday being the sponsor of the show, giving us a place to land. And you can follow my work there. The security column goes live every Friday morning, and that's always a lot of fun too, to keep up with what's going on in the world of security.

But other than that, just want to say, thanks. We appreciate everybody being here, catching us live and on the download. And we will see you next week on Floss Weekly.

Jonathan: Hey, this week Doc Searles joins me and we talk with Olaf and Dave about LifeRay, a project that's a little difficult to pin down. It started with the idea of portals, but has grown into a basic building block for building any sort of experience on the web. You don't want to miss it, so stay tuned. This is Floss Weekly, episode 795, recorded August 6th.

Life Ray, now we're thinking with portals.

Hey folks, it is time for Floss Weekly. That's the show about Free Libre and open source software. I'm your host Jonathan Bennetts and we've got a fun java filled show today. Once again, it is not just me though. We've got Doc Searles, the the one and only the og. Hey doc. More O than G. A lot more O than G.

Yeah, well, I feel that way some days. Now, you've described your day today as a death march. You've got something going on that you're feverishly getting ready for.

Doc: Yeah, there's an annual event put on by the Internet Archive called D Web Camp, for Distributed Web Camp. And it's at Camp Navarro, it's up in Northern California, among the redwoods.

Where it's fun to see people coming from other countries where all they're doing is standing around looking straight up wondering why These how weird these trees are they're looking at a cloud up there They're looking for the cloud or they think the Ewoks are coming. There you go Because that, that, that particular episode of Star Wars, the Star Wars movies was filmed in the Redwoods.

Oh, okay. But this is, this is much less lush. This is more like dirt on the ground rather than, you know logs and, and, and moss. But, yeah. But it's fun. It's a, it's a fun camp. And, but I, I'm giving a talk. early Thursday morning there. And and I've got a whole thing I'm doing on it and it's, I'm not ready.

So there's that. It's also weird. Cause I mean, it's, it's been, I'm in the middle of Indiana and not much different where you are, where it's hot. It's the summer here. It's hot. And, and it doesn't get cold at night. It stays warm because there's humidity. And In that part of California, it might be 90 in the daytime or, you know, 30 something for those of you elsewhere.

I now give my age as 22. 5 Celsius, actually, so. I like that. Yeah. So that's about how old I am. Anyway. Yeah. But it's cold at night there, so I'm bringing my flannel, my flannel PJs. Yeah.

Jonathan: Yeah. Yeah. Alright, fun. Well, so we've got a we've got an interesting topic today. We're gonna be talking about LifeRay, and LifeRay from, from what I gather is sort of difficult to put a pin in exactly what it is.

It's a, a low code digital experience portal, which sounds very buzzword y, and I, I think it sounds that way just because they, they try to do so much. Have you gotten a few minutes to look over this, Doc?

Doc: And I, I've had a few minutes to look over the briefing . I'm not, I'm, I'm not hacky enough to have downloaded anything or do any of that for our guests.

I, I was, I worked for Lennox Journal for 24 years, but I was like the business editor. Mm-Hmm. , you know, so not the not a, not a technical guy. So,

Jonathan: and I think, I think this is gonna be a very sort of business oriented show, which is why I I particularly chose you out to be here. I think it'll be real fascinating.

Let's, let's go ahead and bring the guys on though, because obviously we can, we can sit here and talk about what we think it is, but we've got the experts right here. So we've got Dave Nebinger and Olaf Cocke. Welcome to both of you guys. Thank you. Thank you. All right, let's, let's start with this kind of overarching 30, 000 foot view question.

What, what is Life Ray? What do you do with it? What problem does it solve?

Olaf: If we tag team, we probably get most of it. Going historically started as a portal and in times when you could not put different. Individual pieces on a web page and it continues to develop into the many different Things like on the business side.

We call it digital experience platform because yeah, that's the rage That's that's more than a portal that combines content management system that combines Identity management all kinds of single sign on stuff that you might want to build your application with and And then it gets a lot of features.

So it's not a single tiny bit that does a little bit for you, but it's a full application. So we built in several techniques to extend the whole platform to integrate external software. And part of that is now being done through low code environments or no code environments. So you can easily build form based applications through that environment.

And so that, that makes it hard to really grasp. And we've had a couple of fun usages of that, where it actually doubled as one of the systems that you typically integrate with it. So let's say you typically integrate with a single sign on platform, but there is a plugin that can also mask Liferay as a single sign on platform.

But that's like a really niche thing. Dave, what have I forgotten?

Dave: Well, they had to hit more of the buzzwords. We're a CMS, we're a digital asset management platform, and obviously low code that Olaf already mentioned. It's really, like you said, it's hard to put a pin in what Liferay actually is because it can be so much from a simple Hosting platform akin to WordPress all the way up to a complex enterprise platform for building and hosting custom applications that an organization may need, but they don't want to waste all their time building common capabilities like security and authentication and permissions and styling and, and those kind of things that application developers typically need.

The platform kind of encapsulates all those details. So you bring your custom applications and Liferay takes care of all that supporting

Jonathan: stuff for you. Does it, does Liferay fit in sort of the same niche that something like a next cloud would, is it, is it sort of that same idea? I don't know if you'd say it's, if you're familiar with next cloud,

Olaf: Not too much, but I would say it's more than I haven't seen that comparison, so we're not competing with them on any market.

It's rather literally an application, which then integrates something, has one web front end. So think of it as a web server that brings in content from other applications. Like you have your E. R. P. In the background, you have your C. R. M. In the background. Recently, I've been been using the customer portal use case where you come in as a customer or as a citizen to your city's website and you want to tell them, Hey, there's a pothole on the street.

So what do you do? The city needs a ticket, but nobody, no citizen would like to file a ticket and then see all of that metadata mess with 25 25 fields. So in the citizen portal, you will have a front end that says, Hey, where's the pothole? Oh, it's here. How bad, how bad is it? Fire it away. So you get a separate front end to some external backend, which handles all of the ticketing and metadata and so on.

But you Simplify it for the actual front end user. And they don't need to leave that that website or that portal in order to do something else. Like I'll need a new passport. I'll need this or this or that you can do all on the same platform, even though in the backend, it's vastly different things.

Doc: Okay. So, you know, as, as you guys are explaining it, the, the three letter Acronym that jumped into my mind was an IDE. Is that term even used anymore? Does it describe what you were doing?

Dave: We're not really an IDE in that you're developing software for somewhere else. The Liferay platform at its core is serving up web applications JSP pages, all the way through React, Angular other JS frameworks.

It's a hosting platform. That provides a number of services to make it easier for those applications to be built and hosted. So the developers don't have to include those aspects in their own application.

Jonathan: Does Liferay work as the web host itself or does this sit on top of something like Apache?

Dave: We use Tomcat.

So we're leveraging Tomcat and other JEE based servers. We're also compatible with like JBoss and. WebLogic and some of the other big players.

Jonathan: Okay. So this, this would be in the Apache world. We would, we would build something like this, probably a PHP, but you guys are in the Java ecosystem. And so it's, it's all built in Java and then working with the existing Java tools.

Interesting.

Dave: It is, but we're not limited to Java through our extension platform. You can bring. extensions using any language that you're familiar with. If you want to build a NET extension, you can do that. If you want to do all of your development using React, Angular, Vue. js, that's fine. We support that.

And you can leverage the host of Liferay services in your application to implement what you need without having to reinvent the wheel each time.

Jonathan: So it, it really is then like a, it's like a CMS, but it's, it's a CMS that is very much targeted at building like a dashboard and a even a customer experience at the same time.

Olaf: Yeah, let's say the content that is managed by a CMS, the content can be very active, can be an application. And the content receives some services from the platform. One example is, like, why would you need a platform when you can build a perfectly fine React application yourself?

Jonathan: Right.

Olaf: Well let's say you need a user identity.

So, yeah, that's fine, you can sign in, you can sign out, that's fine. Fine. For, for you, as I, if you build on this platform, you get one kind of user identity. And if later on you decide, actually, I don't want to bother with any password anymore. I'll outsource that to some single sign on system. The user identity that the application interfaces with stays exactly the same.

When you say, oh, we want like we've started in a very small environment, but we want to change now to an LDAP system. Then the user identity stays exactly the same, but it's now fueled by LDAP. And if the company merges and decides to now bring in two LDAP or N LDAP systems then, yeah, who cares?

You still deal with one user identity that comes with permissions services and so on. And that user identity is, is what you use in your front end application, no matter if they are authenticated by a single sign on system, multi factor authentication what the password policy on those is if they come through LDAP and so on.

So there's the value for building on a platform.

Jonathan: Yeah. What, what did the origin of Liferay look like? Like, what was the what was the initial problem with that? And I'm, I'm curious, were, were one of you two at the beginning? Did, did either of you guys write, you know, the first lines of code? And then what, what did that look like?

Olaf: No, we're actually veterans. So but both of us are not there to write productive code on the platform. I'm with a company now for 14 years and a bit. Dave is a little bit shorter but he has been working with a product since forever. The actual product started around the year 2000 when Brian, the company founder needed a website for his church.

Oh, interesting. And he completely nerded out, over engineered everything, and you can imagine a church website actually needs to perform really well. And performing really well in the 2000s, or in 2000 actually meant, when you know Java, what does it mean? EJB. So it went all the way in and and completely over engineered.

He solved the problem. I'm, I'm actually not, I'm actually not sure that the the church website was ever served by life, right? I don't know, but, but that's the origins. And then like, People people found it and and asked for support or contributed something asked for for help setting it up.

And from then on it, it completely like it, it went hockey stick and, and up. So to say in 2004, there was a company that was founded or the company was founded.

Olaf: And it's now, actually I didn't count them, I'd say 20 offices worldwide, so lots of local companies, and what, what else is there?

Oh. And the formally purely open source version then turned into a dual licensed offering. Mm-Hmm. . So the open source and a commercial offering, which in my eyes, I, I was around, I was at exactly the event where it was announced and it totally made sense to me. Because up until then they had like 10 12 customers that were all on different branches.

Olaf: I think it was subversion back then. So everybody had their own branch. So bringing on yet another customer and another one and another one with all with their own branches does not really make sense. So you want them all on a single branch or on like a limited number of branches and you can have an unlimited number of customers.

And they want longer support. And they I want to have someone who is responsible who says, Yeah. Oh, yeah. We're responsible for what we do. So that that started the back then so called Enterprise Edition. And as I've started with EJB when Enterprise Edition came in, EJB was already long out.

So, so coming back to the code side there is no more EJB in there, don't worry. It's, it now is a modern platform, but it could still serve your church's website. Yeah.

Jonathan: Interesting.

Dave: If, if you remember the, the early two thousands, the primary interface that everyone was going for was really the screen with a primary content and then a number of boxes on the side, either on the right side or on the left side.

Mm-Hmm. . And this was the kind of interface you'd see if you went to stand n.com or Yahoo News or, or any of those kind of things. And out of that. There was a big push to adopt what were called portals. And there was a Java specification to define what a portal was. And when you look at Liferay Liferay had looked at what was available from a Java portal perspective, but there was really no good open source alternatives out there.

And our platform was built as an open source implementation of the specification for a portal container that would host portlets. And that's where it started from, but these days it is so much more that we don't even call it a portal anymore. It's, it's a DXP because of all the capabilities that it now has.

So

Doc: I'm wondering, okay, so A digital experience platform, I guess that's what that stands for. Is anybody else using that? Do you have any direct competitors? Do you have a category called DXP and there's you guys and there's that one and that one and that one? Is that, where's that at?

Dave: Adobe is probably the biggest one that folks will lean to when they're learning about DSP platforms.

But, you know, us compared to Adobe, we're open source, they're not. That's great. We're an integrated platform because all of our capabilities we built and add to the platform natively. So the whole usage across the platform is consistent. Adobe kind of purchased theirs and pieced them together. So they're more of a hodgepodge, shall we say.

And moving around between the different components is often not as. Cohesive as what you might see in the Liferay platform, but there's other others in the Magic quadrant by Gartner that also do DXP platforms, but we are the only open source player in that market

Doc: Is it a magic quadrant of DXPs or there are DXPs in a oh really?

Okay. Yes. Yes. That's interesting

Jonathan: What what license is the project go with

Dave: So we have two licenses. We use LGPL for the community edition. We also have a it's a special license that for the commercial aspect.

Jonathan: Is is is this an open core project? Like are there bits that are in the commercial offering that are not in the open source part?

Olaf: They're,

Jonathan: they're the, the way

Dave: the code works now, the repository has everything, okay? Both the, the open code as well as the not open the commercial code it's all in the repository. It's just the license that protects the usage of that in commercial situations.

Jonathan: And, and so what's the, what's , what, what's the, what's the catch there?

Right? Like what's, what's the difference? So, and, and I guess part of this question is why, why would someone. want to come and use that, that commercial license?

Dave: Well, for the most part, the commercial aspect is going to bring support. It's going to bring access to our cloud based offerings. We're unique in that you can self host your platform, but we also have cloud offerings.

The cloud offering is for the commercial side. So there's a number of reasons that an organization will say, we, we want to go with the the subscription to LifeRay rather than the open source version. But the open source platform is just as capable on many aspects for hosting any kind of website. The big distinction between the two tends to be the enterprise y sort of capabilities that a client might need, such as, you know, using an Oracle enterprise database as opposed to an open source database like MySQL or Postgres.

If they need enterprise connectivity for SAML or OpenID Connect, those kind of pieces will fall under the enterprise side. But for generic sort of open source connectivity, you can use the Community Edition for that.

Olaf: And if I'm really nitpicking then there is the, the price for the license for the commercial, as well as for the open source version is exactly the same.

The license is there for zero. What we do is the services subscription, which literally then is access to longer maintenance to, to support, to get hot fixes on exactly the version that you're running and so on. And then the service level on top of that. So, yes, you can you can file issues on the open source version but there is naturally no surface level attached to that.

We're very interested in that, but the on the enterprise level where we have a contract with our customers we do guarantee your surface level.

Jonathan: Mm hmm. Makes sense.

Doc: So, I'm, I'm curious about case histories. You, you mentioned the City of Vienna and Hewlett Packard Enterprise on your website.

But I'm interested in hearing about those kind of things, but also the open source ones. Ones where you're actually not involved, but you know they're there, and they're busy kind of proving your case. Can you go over some of those?

Dave: Yeah, from the community side There's a major American automaker that for years had used Liferay to host their internal intranet.

They built out a complete solution for all their employees to access. Much to our chagrin, of course, we, we would have preferred that they would have gone with the the subscription model, but they were able to build their solution on the Community Edition. The flip side of that is, from the commercial side, we've hosted many different types of platforms.

From a children's site that hosted games and videos and, and things that, that kids would be interested in. All the way up to websites for some of the U. S. military branches. Enterprises of all kinds, banks, insurance, manufacturing. We also do internet based solutions, extranet. Internet front facing brochure websites.

The platform is really flexible in how you can use it to solve any sort of web based problem. And the fact that it's a DXP means we can provide the content regardless of what kind of device you come to us with. If you're on a mobile, you're going to get a responsive platform. If you're on a tablet, it's going to also be responsive versus a desktop.

But ultimately, you're going to get the same kind of experience. And from a platform level, we can follow you across those devices and make sure that we are tailoring content and personalize it for each visitor so that we can help target them to meet whatever the business needs are.

Doc: I was wondering about, so it's interesting when I went to your website I'm, I've been in my work as a journalist is basically around privacy and and I'm Always looking at, at the cookie interfaces and you guys had tracking cookies for targeting turned on by default. And, and I'm wondering if and, and I rejected it because I'm actually not in your market.

So I thought, okay, well, I kind of don't feel like being tracked. How's it going with that? I'm just curious about if you have any intel, intel as it were on, on people turning that on and off or that helping or hurting your. Your cause as people get into their, the websites, because websites are basically where you manifest for the most part, I would think.

Dave: Well, when you, when you hit liferay. com, you must realize that is our marketing site. And the cookies that we're using there are designed to help us to promote our products to the right audience and then track how they respond to that information. It's not meant meant to you You know, follow you throughout the web and use it for any nefarious purposes.

It's more for our business aspects. And when you say you're not in our market, well, you know, we like to think that everyone is, we're a worldwide company, we have offices all around the world, we have organizations using our platform for many different businesses and purposes. So, we like to think that everyone is our mark.

Doc: Well, I, I, I like to be in your market, but as, as somebody who's 22.5 years old Celsius

it's unlikely in the fullness

Olaf: of what's left of my time. Well, you, you're still, you're still the person with the most browsers on a single computer that it seems that way. It seems king of the browsers.

Doc: Yeah. Yeah, I just added DuckDuckGo actually as another browser. I play with the, how can you say about how large your market is in terms of sales?

I guess it's mostly enterprise sales. And if you can't, that's fine. You save a lot of offices, so it must be doing pretty well.

Olaf: Yeah. So the last thing I've seen is I think it was more than a thousand or a thousand, 200 customers. on it. We don't really follow that, or I don't really follow that closely because like a rough ballpark to me is enough.

There is the one aspect I've mentioned Brian as the founder of the project, and he's still around. And as Dave said, we're one of the few On this market who allow you to pick self hosting or cloud hosting pass or sass All of that works for us and we're committed to all of them. We're also One off if not the only large open source software company that is still operating completely and absolutely without any vendor Not vendor venture capital So it's full fully owner owned or founder owned and there is nothing Nothing coming in In fact, there were offers, but the story that I've heard about them was when the the venture capital companies were asked.

So assume you give us money, what should we do with it that we don't do already? They couldn't answer so

And

Dave: the additional thing is the the community edition we don't do any kind of tracking or tracing on so You can download the community edition use it in your business use it in your church use it in your Interest group for whatever reason, we're not really going to have any visibility on that. So, you know, you're, you're kind of free to run away with that and, and use it as you like.

From our side, though, obviously, you know, we're, we're not tracking and tracing that. So we, we don't really know how widely used the Community Edition is actually used out in the wild.

Olaf: Yeah. And as Dave said the, like liferate. com is our marketing site. There is the community site, which is liferate.

dev. And I haven't checked it, but if you look at that, I'm, I'm quite sure that there is no external tracking whatsoever. There might be the, the actual, yeah, we're using cookies. I think that's there. But I am not aware that we have configured any marketing like tracking external thing there. I just

Doc: brought it up.

Nothing happened. That's good. It's a very old fashioned that way. Oh, no, there's a tiny, this website uses cookies to ensure you get the best experience. Learn more or accept. But there's no third

Olaf: party cookies that I'm aware of. Yeah,

Doc: yeah, yeah.

Jonathan: I Very good. I, I guess this is, this is an opinion shared by many people, but I am so sick of the, this website uses cookies pop up.

And every time I just say, yes, put cookies on my computer. That's fine because it's, it's just a website. Storing a little bit of data on your machine to make the web, like that's how the web has always worked. I, I, I am very unhappy with European laws for cursing all of us with that dumb little pop up.

But that's, that's an entire rabbit trail. Yes, the, the The idea of venture capital is really interesting. So we've talked to some people that have had venture capital and it's worked for them. And then you also talk to people that have had venture capital and it really changes the project or it changes the company that, that, you know, was started from an open source mindset.

And then there's even now some venture capital groups out there that are like the VC is intended to be friendly with open source And I find it really fascinating that life ray Didn't ever have to go down that route And I I think probably why is just listening to you talk about it from the very beginning when it was just Hey, let's build a portal for a church The concept was sticky.

There was something about it that when, when other engineers, when other web people heard it, they went, Oh, that's cool. And is it, is it still sticky? Do you still have that, that you know, that kind of aha moment when someone finally understands what it is that Liferay is they go, Oh, that's really cool.

I could use that. It, do you still get that?

Dave: Oh, we do, but it's changed over time, right? Initially. When you went to Google, you could search for portal software and, and you would find a WebSphere portal from IBM. And there were a number of other portal platforms that were out there that have gone the way of the Dodo, right.

They've all but disappeared. Liferay is the last one standing in that market. So, you know, we don't even like to talk to Liferay as a, as a portal platform, because. It's not hip to be up for the platform. So now, you know, obviously the market is more interested in DXPs and CMS, headless CMS digital asset management, those aspects low code and everyone's favorite AI.

So we're, we're growing the platform over time to stay relevant and incorporate the kind of capabilities and functionalities that businesses are looking for in a platform such as ours. But that has changed how we have stayed relevant.

Jonathan: Is there is there a big buy in with AI in Liferay? Is that something that's here already or is coming?

Dave: We have a number of integration points already. When you're building CMS. Sites, you can leverage a generative AI to help you build content. There are other aspects for allowing for image generation and auto translation features, which is really been a great help to many of our clients.

We have one client with uses over 70 languages on their platform and they AI auto translation to previously before that capability was in there, it would take them months to coordinate a release because they had to make sure that all the content had been correctly translated into the 70 languages.

Now they're doing it in a matter of weeks. Because AI is allowing them to get that content translated into the languages they need. And then they're just coming in and reviewing and fixing the obvious problems that AI has with, you know, understanding correctly and translating correctly.

Olaf: I can say it's a good help for me or great help for me.

I'm in my day job, I'm a sales engineer. So I'm always asked to demo the platform to various different people. And I mean, as, as much as AI can hallucinate whatever, I do not care about it being, being exact to demonstrate, to demonstrate platform. It's totally easy to say, Hey, write me 10 articles about how the financial world like blog articles about how the financial world changed in the past 10 years.

Make it 200 words and more go. They have AI has AI

Jonathan: has replaced the lorem ipsum for you. That's

Olaf: exactly it.

Jonathan: That's great. I

Olaf: have a lorem ipsum on my stream deck in front of me. But I'm rarely using it anymore.

Jonathan: Yeah, that's funny. I even

Olaf: have bacon ipsum on there. Bacon

Doc: ipsum. So, inside your product, I mean If, in using AI there, I think you said you use it there, not just to help with marketing.

Do you, do you go to the clods and open AIs, or do you download Llama and work with one of the open source alternatives? No, we, well,

Dave: we define interfaces for everything and then back that by implementation. So we have a generic interface that defines how to use generative text, for example.

Internally, then, we will implement that in various different flavors, whether it's going to OpenAI or Cloud or Gemini when they have APIs that we can plug into and use. We have not yet. a module around a self contained large language module. Not to say that we couldn't do that but I think what you run into is having the the muscle and the processing power to host that kind of thing on your own.

I think generally the best consensus is to try to leverage one of those services rather than, you know, Train and host your own

Olaf: and as the whole platform is built on those apis Now the back end is built on osgi or around osgi And I always like to stress that everything is based on an api It is up to the customer as well to say like hey This is a a nice implementation, but why would I want my send data over to them?

I want my data to stay here or to, to go to that provider. So the interface is open and the whole platform allows you to just deploy a tiny module that then implements the interface to interface with the system that you want. That will be Java, like on the OSGI side. Yes, there will be a Java module, but more and more of those modules, we provide a headless interface for that.

You can just trigger from the outside. And then you're, you're again on, on whatever whatever language you want, because the only thing that's in common then is rest.

Jonathan: So I am poking around at some of your websites and I find myself at liferay. dev, which is sort of the, the main open source community site.

And I see down at the bottom powered by the Liferay portal CE and oh, it's like seeing companies eat their, eat their own dog food. As we say is the Liferay portal used a lot internally for Liferay? Like how many, how many instances of it do you think you guys have across the company? Every host.

Dave: Interesting platform we offer is running on life brand.

Jonathan: Yeah. , that's so a lot. . Yes.

Dave: And, and honestly, eating our own dog food makes the product better. Oh, absolutely. We find the bugs that, that bother us. Mm-Hmm. . And we, you know, we fix those. So, you know, having ourselves as our own customer just makes the product that much better, more stable, resilient, and secure.

And that also, I'm sorry, but that also means when we extend this out to clients, they're getting the same level of support and security and everything that we need for our own business.

Jonathan: It's always a little worrying actually when you interview a company, we talked to a company that does open source that doesn't use their own open source project.

You just have to wonder about that. It's like something went wrongs here somewhere along the way. That's right. I'm curious about scaling, right? Like so you've got some big customers and and this, this is where really, I reveal some of my ignorance about doing, How Tomcat works really and how the Java ecosystem works.

I'm curious like how big does this scale up to and what does that look like?

Dave: How much money do you have? Well, that's always the

Jonathan: question now, isn't it?

Dave: Yeah, well, you know, and I joke, but it will scale up as large as you need it to be. So if you have just a requirement for a thousand concurrent users, You're probably going to use like a two cluster node for that.

But if you have 10, 000 concurrent users or you want to protect it against being slashed on it, you're going to go a lot larger there, but that's fine. Our platform is built around being stable and secure and steady in a clustered environment so that it is. It's returning the right data. Nothing is stale or returned out of any of the cluster nodes.

It's really meant to be a resilient platform regardless of the size that you need.

Jonathan: And, and I assume that the clustering is sort of built into it or it's built into Tomcat maybe? No, it's

Dave: built into the platform. So we have each node forms a, what we refer to as a mesh network. And there's messaging going back and forth saying, Hey, I just saved this blog.

If you have an old version, you should dump it. And you know, that kind of messaging is handled across the platform. So it becomes a a very strong way to ensure that all nodes are up to date and always returning the latest content.

Jonathan: Yeah. And then do you have multiple, multiple nodes sitting behind like a a traffic manager or are these.

Are these, you know, separated out geographically and you use DNS to point people at different places? I'm just, I'm just curious, however you want to

Dave: do it. Yeah. Typically it will in simple cases, you're talking about just a small cluster with a load balancer sitting in front of it. But we do support doing geographically distant regional centers where you're hosting Liferay and, and depending upon what your requirements are you can build all those kinds of things and they will work with Liferay.

Olaf: I got to say it's regional though. So it's not around the world. It's not one server for Europe, one for the, for the Americas and so on, but it's more or less regional. So it's in the end, it operates on a, on a consistent database. And which can also be clustered. No matter what. So typically, the best understood system that I see is a load balancer and then any number of nodes behind it.

And it also works quite well with content delivery networks. So you can configure all kinds of caching headers and make sure that a request doesn't even hit the platform if it's not necessary. Right. But of course, if it's if it's not publicly visible, you want the platform to be hit for every single download, for example, or access of a page, not for all of the CSS and JavaScript, though.

Jonathan: Yeah, makes sense. All right. So to go in a different direction, I want to know about the community involvement. And I guess particularly in the, the, the community edition, but I suppose this, this would apply to both of them because the source is available even for the the, the enterprise edition. So like, what's the, what's the community involvement look like?

How many, you know, how many contributors are there outside of the company? And what, what does that, what does that look like?

Dave: Well contributing to Liferay takes many forms, right? There's, there's contributing just by joining the forums, joining the Slack channels and answering questions and things like that.

We, we count those in our community as contributors because they are helping to strengthen the community and build it out from a platform perspective. We do, Accept and want to accept changes and pull requests from outside the organization. The challenge for us, which may be unique to pure open source projects, since our platform is also a product, it is the product that we sell, the challenge for us is how to, how to accept Those pull requests, how to accept those changes, and oftentimes it, it will require some iterations with the contributor to get it into a form that we can accept and approve and merge into the platform because once we get that merged in, you know, we're taking over ownership and responsibility for that.

So the challenge is often how do we, how do we take those submissions? How do we transform them so that they are enterprise level, enterprise quality, and then get them merged into the system? It's not the fast process that you might expect with a typical open source process. Yeah. But it does exist.

Olaf: Yeah, there is another aspect to that. Because everything is open source. an API or has an API. One of the standard ways to extend the platform is to not at all build from source. And and contribute something to the core, because the core is built of Dave correct me if I'm wrong, thousand plus modules which is typically a separation of API modules and implementation modules and so on, and you can easily drop yet another module.

They're tiny, they're small, and you can implement them. Just in addition, and they do not need to be developed or delivered with a core, you can put them on the marketplace, for example, or publish them on your GitHub or anywhere. So it doesn't need to be a contribution that puts something back into the core.

That's the way I have started contributing by. Number one, making suggestions. Number two, publishing some random proof of concept things on on the blog to show like, hey, I've tried something this actually works. And fun fact I have, I've driven several of our developers nuts when they ask me if If something runs on master and I said, I don't know, I've never built master, but like that now finally broke down after 14 years, I have compiled from source for the very first time because I wanted to contribute some code that I want to be in the core.

Jonathan: So I've got to say we're talking about the, the, maybe the difficulty of contributing. The project has 929 contributors. Now it's been around for a long time, but just looking, looking and this is just looking at life ray portal, the main, the pro what seems to be the main GitHub repository, 929 contributors.

That's, that's pretty good. That's quite a few. Is there, is there a CLA to ask people to sign a CLA to contribute? I would assume you have to, to be able to do a license. Yes. Yes. Yeah. That's, I know some in the open source community are not happy about CLAs and I understand why. But at the same time, when you're doing something with a big business like this, it, it makes a lot of sense.

And I think the other thing with that why people don't like them is, To sign a CLA and then the code, the license code, the code license gets changed. People sometimes feel a little betrayed by it, but that's not the case here. You already have the licensing in place. People know what they're getting into when they send the pull request in.

And so I, in my opinion, I think that that makes CLAs even a little more palatable because everything is upfront. You know exactly what it is. And the other thing I wanted to mention with that is I appreciate that the proprietary license. is out there and available for people to look at. It's not something that's hidden.

You don't have to agree to, you know, you don't have to sign an NDA before you get to look at the license. And I appreciate that a lot. It it's it's a testament that, you know, the company actually believes in what they're doing and you're not trying to strong arm people into it.

Dave: Yeah. And all of our license is really just to protect the product, right?

We want to make sure that when you're using it, you're not. Like stealing and giving away our technology to somewhere else. That's all it is. It's not meant to hamper adoption of the product either from a community or a product perspective.

Olaf: There's also another aspect. So it, it almost led to me asking a third person on here, but he would be good for an episode all on his own.

One of our legal team guys, the most nerdy lawyer that I know. So he, he is deeply enrouted in the in the open source ecosystem. And he gave us the hint that we actually sponsored now I'll have to look that up. I forgot the the exact project some of the the license scanners that actually go through everything and let you know if you are matching that license or if there's some, some foreign code in there Dave, maybe you can look it up while I talk it's Matt, Mattias answered to it.

So and these guys came back to us and, basically we, we paid them to to build all of their code for the Java. Instance, as far as I understand that Mateo would be the the authority on that. And with our code, like with that code base of a thousand modules of, I, God knows how many lines of code that is, they basically have seen it all.

So that tool now should be quite rock solid with regards to Java. Yeah, interesting. Did you find it?

Dave: Yeah, it would be a scan code IO and reuse that software.

Jonathan: There you go. That's it. Yeah. Do you guys ever see things in the the, the, the proprietary license, the, the, excuse me, the enterprise edition make it into the community edition, is there kind of a flow where things go down that way after, and I know some, some businesses, some, some projects have, have this codified, like we build it for the Enterprise and then once we make X amount of money with it, it goes into the community edition.

I always thought that was an interesting way to approach it. Is there anything like that in Liferay?

Olaf: I want to nitpick there and say no, because it's better. It's all out in the open anyway. Like the code is dual licensed and to cut a release. The one thing that we do with the enterprise edition is we have bi weekly releases that are bug fixes and that go quite a while back.

While on the community side we, we do provide the quarterly releases and if there is an emergency that there was none for a while, then yes, we'll do that as well. But on the community side, you're typically on the latest version and but, but all of the code, all of like, if you compile master, this is what goes into the next release both at the same time.

Oh,

Jonathan: okay. So there's not. It, it, it literally is not open core. Then there's, there's not anything missing out of the community edition. There's, there's one code base. No. So there, there's

Olaf: nothing that could trickle out. Okay. Because it's all the dual license anyway.

Jonathan: I gotcha. I, I misunderstood the way that worked then.

I appreciate, I'm glad we, glad we cleared that up. . Alright. Doc, is there anything that you wanna make sure and get in? I think you had one or two more questions. Well,

Doc: I,

Jonathan: yeah.

Doc: I mean, one is when you're sh all of, you're saying you're, you're a sales engineer, but when you're showing off what. what what life rate can do.

What do you point to? I mean, what's, what's your, what are your canonical examples? I mean, I look at your customers, you've got some pretty heavy customers there, you know, and you know, you've Jose Cuervo. So that beer, you know, and Carrefour Airbus, I mean, city of Burbank, I imagine they're using it in very, very different ways, but But it'd be, I mean, it'd be one interesting thing to say, you know, when you're flying an Airbus that, you know, we keep the wings from falling off or some other thing, but I, Yeah.

Olaf: Yeah. So what we typically do is, number one, we have a discovery call up front so that I know which part are they interested in. And then when we have a demo call, it might be an hour, it might be two hours. I prepare something, either I pick a, a stock demo that we have and customize that a bit, sometimes it even works.

Like if I can offer, Hey, we have a matching point that I can demo tomorrow. Or I can prepare something better for you for next week. Sometimes people just opt for tomorrow and then how I open An hour quite often in the last times is that I explain what I'm going to do. I just give an agenda. So we'll go through, for example the content management part in the first 10 minutes, then we'll go into personalization, into integrating other platforms.

Then we'll go for lunch in the afternoon. We come back and then we cover the commerce features and, and DevOps. For the rest of the week we'll go, hold on. Oh, excuse me. I just hear we only have an hour. So I guess I'll have to severely limit myself and, and just pick a very small fraction of what we have.

So that's how I typically do that or very often do that. If only to demonstrate that or to show that just because I haven't demonstrated a particular feature doesn't mean it's not in. But because we by far don't have any time.

Dave: Yeah, there's so many capabilities in the platform itself. There's no one demo that works for everyone.

Each organization will come in with different things that they need, whether they're looking for CMS capabilities or document management or hosting videos or whatever. Hosting custom applications. They all have different requirements, so there's no one demo that we can show them on the platform that's going to check off the boxes that they are interested in.

So we want to know the kind of things that they want to see, and then we show them how we can solve those things using LifeRay. And most of the time it's using out of the box LifeRay. The. We're at a point now where the the capabilities on the platform with low code and objects and Everything else that we support Fragments and whatnot.

It's really easy to get solutions at work without having to invest a lot of money to make it happen

Doc: So you don't go and say well, this is how HP did it or this is how Airbus did it. It's so customized to what any particular customer needs. You just go straight into it Yes,

Olaf: It's either fully customized or like we have a starting point for an intranet.

We have a starting point for a customer portal. We have a starting point for a manufacturing site that is more commerce heavy and so on. So we can pick some and sometimes I pick a demo to start with that is deliberately from a different industry because like it's a, it's a customer portal. Touching a different industry rather than the, the commerce sites demonstrating the same industry that they are from.

So, I

Doc: wonder if, if you guys are, are at the point of success or maturation, or maybe this doesn't apply. That there are other businesses that specialize in Liferay installation. That's when you know you've made it.

Olaf: Now for as long as I'm with a company, we have a partner network. So the company business is very purely on, or yeah, not exactly only, but mostly on, we're a product vendor.

And the implementations are very often done by our partners, which is independent companies that then go in by the hour and they implement on top of our platform. We have our own global services team, so there are internal consultants, but we It's only a few areas in the world where we actually have them in order to do such projects.

Mostly, we use them, as far as I understand, might be different in different parts of the world. But I understand that we mostly use them to support the partners to do something like validating best practices and making sure that, for example, a site performs well. to, to stand by their side with performance tests, because we do performance tests all the time.

And we might as well extend that to the partner network. So technically we're the product vendor and the partners, like the whole people that build on top of it. That's I think 150, 200 partners worldwide. So there is quite some business built on top of Liferay, which we're happy with. So we're very happy to refer business to those to those partners.

Dave: And we do a lot of training with them and work with them and communications. So they have opportunities to provide feedback on how the platform is working for them and changes that they need. We really rely on our partners to handle the bulk of the implementations and to get the feedback from them in order to help improve and make the platform better.

Jonathan: Okay. So in thinking about, Everything that Liferay lets you do. I'm sure you have businesses that use this or even people use this or something like a, a knowledge database, you know, like an internal wiki, you have people that use it for customer management as well as public facing websites. So like there's, there's a bunch of different things that you could set up with a Liferay install.

And I want to know, what are some of the weird and surprising things that y'all are aware of that people do with Liferay? For me, the

Dave: one example is the, the, the kids site. With the games and the videos, I, I guess I can throw the name out there. Sesame Street for a long time, they were hosted on Liferay and you know, that's kind of a weird use because, you know, normally we're, we're going in, we're doing enterprise sites, right?

You know, so standard boxes, standard fonts, things like that. And. The rules changed when Sesame Street was using our platform. So for me, that that's, that's the weirdest one that I've seen based on the platform.

Olaf: Yeah, they, they aren't, they aren't using it anymore, though. Sadly. I loved referring to them because it was the most colorful site that I could point to back then.

Yeah. I would say the weirdest question that I ever got, I think they never executed. The idea was by a manufacturer of some medical devices. I want to say something like MRI or like that scale of machines, right? Who wanted who were asking for OEM licenses with support for a single user. So, basically, to build that in, to build in a web server and a browser in kiosk mode into their device, and serve a single user on top of the platform, and just use it as the, basically, the frame for the building blocks of or, and being able to compose an application out of many different small elements that use the same infrastructure.

I'm not sure what came out of that, because I have learned about that long before, Before I became a sales engineer and actually looked at the projects and, and had to to basically sell them.

Jonathan: Yeah. All right. Good answers. Okay. So now this is a hard question. You got to do some set math here. Is there, is there anything that we did not, because we're getting close to the fact we're past the bottom of the hour, thanks to some technical difficulties at the beginning of the show.

Is there anything that we didn't touch on that we didn't ask you about that you really wanted to let folks know about the project? I

Olaf: think I've mentioned once or twice just the vocabulary and that those teams would be mad if we don't explicitly make sure that in all of the description of what Liferay is, we barely touched that there is a full fledged commerce front end in there as well.

So I, I managed to drop the commerce syllables sometimes, but in general, we did not talk about that aspect of the platform at all. Oh, yeah, that's interesting. And other than that no, I could only tell you a funny story about the origin of the name.

Jonathan: So. Oh, please do. Yeah, I want to hear that, for sure.

Olaf: So I guess I have heard it five years, at least five years ago, probably rather 10 years ago. So what came up to that is Brian, our founder used to what was that? Or met a guy in university. And his name is Ray. And they figured we're going to do something like they had a business idea and they wanted to build something.

And it was a medical device. Now, they were about to start a company and Ray said, the only way I am going to create a company is if my name is in there. So they figured, hey, medical device. So what's it? It's Death Ray. Oh, no, that's a bad idea for a medical device. So what's the opposite? That's Life Ray. So Brian was quick to just buy the domain.

And and then he never saw Ray again.

Jonathan: Huh. That's funny. That's funny. So, and when,

Olaf: and when years later he had the project he was like, oh, how do I name it? I got to pick a name for SourceForge back then, I believe. So what do I publish it as? I was like, oh, I have this domain lying around, so let's use that.

Jonathan: That's great. That's the story

Olaf: I've heard. That's great. And I believe it's true.

Jonathan: No, it doesn't sound, it sounds, it sounds true. That's the sort of, yeah. Dave, is there anything that you want to cover that we didn't ask about?

Dave: Man, just, if anyone wants to know more about Liferay, they can find us on the, our community Slack channel, you know, both Olaf and I are very prevalent on there and would be happy to answer any questions someone might have.

Jonathan: All right. Very good. Now I've got to ask each of you before we, before we let you go, we'll start with Olaf. What is your favorite text editor and scripting language?

Olaf: Hmm. For the text editor, I'm promiscuous. I just use whatever is there. If I have to do, like, I, I am on Ubuntu and I'm happy to use KDE if I need a full fledged IDE much to Dave Chagrin, I'm using Eclipse.

And if I'm on the shell and I need an editor there, I open vi. But if my Git commit opens a nano, who cares? ,

Jonathan: I, I know that feeling and it, and in scripting

Olaf: language, I rarely do something, but I would say bash. That's, that's fair.

Jonathan: Alright, Dave. VI and Perl. Ooh, . You're the go-to Oh, well, old school. Old school.

Old school, yes. . Alright. Excellent. Thank you guys for being here. And you know, like I said, we got started a little bit late, but I think, I think we made the time up in goodness. It went fast. It was a lot of fun talking to you about it and it did a lot of fun to, to learn about life. Ray, something I was completely unaware of, but really, really interesting and apparently out there in a lot of places, so appreciate it.

All right. Yeah. Yeah. Yeah.

Doc: It was great. All right. Doc, what do you think? I, it, it's interesting to me that again, it's a, I think one of the largest enterprise, I mean, not enterprise, I guess it's a company, you know, I mean, a project that I wasn't aware of, you know, and that, that's like you, I wasn't aware of it and it's and it's interesting and it's interesting how many people are using it and now.

How well it seems to be working, and how capable it is, and how broad it is. All that stuff. It's kind of like, it is all singing and dancing, and they can actually pull it off, so, that's You

Jonathan: know, what fascinates me about this is, like, so first off, it was the beginning of this project was so specific.

It was, it was one guy making a website for his church, but he said, Well, this portals thing is popular. It's what's hot right now. Let me try to do that. And, So that immediately, because they tapped into portals, immediately it was, like I said, it was sticky. Like, it's something that you see it and you immediately go, Ooh, that's really interesting.

And then, it seems like what has happened over the years, and I should have asked him about this and didn't it seems like there's been a lot of what we would normally refer to as feature creep. Like, oh, it would be cool if it did this. It would be cool if it had, you know, a low code. It would be cool if you could drag and drop things.

It would be cool if there were integrations. It would be cool if it could do this, that, and the other thing. And normally that kills a project. But Feature Creep can, can make projects huge and unwieldy and, but it seems like in this case, I, I, and I guess this is because of the management at the top.

They've managed that Feature Creep to where they now have this like cohesive set of features. people really like. And, and that's, that's interesting to me that as an open source project and as a business that they've, they've charted those waters so successfully, apparently successfully, as big as they are and still making money.

So.

Doc: And, and, and funny that they were in a portals business and portal was a big term back in the last millennium, you know, and I, I, I remember I was at a party in San Francisco back when I lived in that area and which I did for a long time and it was in the late nineties and there was this, You know all these young guys wearing black clothes and goatees and like us, we're the ones, but anyway, they're, and and it was overlooking San Francisco from up near Twin Peaks and, and this guy You know, you're just talking at this thing.

And I said, so what do you, he says, well we have this new startup. And I said, yeah, what do you do? So we're an arms merchant to the portals industry. And I said, portals, it's an industry. He says, yeah. And, and, and he gave me nothing but BS about all the BS of the time. And, and I finally asked him how are sales thinking that would be an insulting question because they were venture funded, right.

And, and And he said, they're great. We just closed our second round of financing for 25 million. And, and I thought it was a, it was an epiphany for me because I realized, wait a minute, there are two ways a company may, you know, two markets for a company. One is for its goods and services and one is for its own ass.

I'm for sale. I'm going to go you know, but these guys, life rate, I mean, They're not venture funded. I think that's actually very cool that they're, they're entirely bootstrapped. It just works. That's, that is really unusual and, and, and there's, and they're not looking at an exit and I'm telling you there's.

As somebody who's encouraged development for a long time and it always goes to venture and it always the the looking at the exit looking at your way off this highway Where you don't even own the company anymore. The public owns you don't care. You've got your cash your You you've got the boat in florida now or whatever it is.

And and You know, but but you know the purely practical this thing exists because it's a good thing it works You It's growing in the world. It doesn't need to, you know, advertise itself heavily. It's pretty cool.

Jonathan: Yeah, yeah,

Doc: that's great.

Jonathan: Yeah, fun, fun project. Definitely one to keep our eyes on. All right Doc, do you have anything you want to plug?

Doc: Oh my gosh I'll plug IAW, because the Internet Identity Workshop is coming up at the end of October. Look up my Internet Identity Workshop. I, I have a short I, I, I pay for II Workshop every year, but it's so slow to go over there. But anyway it's always full of people. A lot of great things happen there.

It's relatively cheap as conferences go. It has no panels, no It's just all, it's all, it's all demo and and have fun with it. And Talk about your new idea. It doesn't have to be about identity either. So, and I'm very encouraged about this one because we have some, some people who want to do the crap I've been telling him to do for a thousand years, you know, I mean, for, for, I guess they were still listening in.

I mean, I I'm big at having markets work from the customer side, how let's equip the customers to be more powerful. And this is a really, a real heavy in that space. That wants to be there and they're going to be there and it's going to be really cool. So, yeah, that's a little tease. All right. Yeah.

Excellent.

Jonathan: So we've got something fun coming up next week. We're actually going to talk with John Britton from Homebrew. And they now have something new they call Workbrew. Which is, it is apparently the, so Homebrew is running homebrew. com. Compiling and running like Unix and Linux applications on Mac OS and it's been it's been around for a long time It's been very popular among the enthusiasts people like me and you But what workbrew is is taking that and making it more commercial friendly And I'm really fascinated to find out what all is going on with that.

We're talking with them next week. And then as far as things for me to plug I've got my, I've got my log scroll up right now. You can tell what I was messing with before the show, but normally what shows up here on this monitor is Hackaday. You can find my work at hackaday. com. We've got well, that's.

The home of Floss Weekly, but it's also where my security column goes live every Friday morning and the occasional other thing. The only other thing that I've got that I will let you know about is the untitled Linux show over at Twit, the Twit network, twit. tv. And you can find ULS there to keep up with all of the news around Linux and some other open source and hardware stuff sprinkled in.

We've kind of found our, found our niche there. But make sure to check that out. Appreciate everybody being here, our guests, appreciate Doc being here and everyone watching and listening both live and on the download. And we will see you next week on Floss Weekly.

This week Jonathan Bennett and Doc Searls chat with Olaf Kock and Dave Nebinger about Liferay! That's a Java project that started as an implementation of a web portal, and has turned into a very flexible platform for any sort of web application. How has this Open Source project turned into a very successful business? And how is it connected to most iconic children's educational show of all time? Listen to find out!

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/

Jonathan: Hey, this week, Katherine joins me and we talked with Andres Almeray about JReleaser. It's the way to automate your releases and kind of make them self documenting. It's more than just Java and it's more than just releases for that matter. You don't want to miss it. So stay tuned. It's this Floss Weekly episode 794 recorded July 30th.

Release them all with JReleaser.

Hey folks, it is time for Floss Weekly. That's the show about free, libre, and open source software. I'm your host, Jonathan Bennett. And we have a real treat today. I'm kind of getting some payback for the last several years. Well, first off, Katherine joins me today, Katherine Druckmann as, as co host.

Welcome Katherine.

Katherine: Ah, thank you. Thanks for having me again.

Jonathan: Yes. And so Katherine, you're, you're, we were talking before the show. You're about halfway responsible for bringing our guest on today. Because you, you, you introduced me to Lori and then Lori's like, Oh, by the way, I know this guy that does the, the J releaser.

It's a, it's a Java program. And I'm like, Oh, Java, but for those that have been watching the show for a while, no, I'm not a huge Java fan. Now, to be fair, this is probably because I tried to do stuff in Java as a very, very young developer. And the frustrations that I was feeling with simply, let's be honest, not being very good at writing code at that point in my life, I sort of associate with Java.

And so. Maybe it's not Java, maybe it's just me, but All the same. I, I still, every time somebody tells me about a job or, or, you know, ask somebody what, what language is such and such written. And please tell me it's not in Java. So this week's a Java pro project. Next week's a Java project. Maybe we're going to just burn my distaste for Java out.

Maybe, maybe yeah. Revenge of the job. That's a good show title. Maybe we'll go with that. But for a guest today, we have a Andres Alomare. He will tell me if I mispronounce that, I'm sure. And he is a Java developer. And he is, well, he does a lot of things. He is a developer, developer advocate for the database group at Oracle.

Interesting. But he is also involved in JReleaser. Built in Java for Java. And this is, this is all about, it's about pushing releases. Like, so it's, it's part of your which could you call that? Maybe it fits into a continuous integration pipeline, but it, at the very least, it's a part of your release pipeline and that's a difficult problem to work out sometimes.

I think, I think Java has maybe some extra wrinkles with doing releases that other languages don't. Don't it's at least a little different from doing C projects. So let's let's bring him on though Let's not waste any more time And once I get him unmuted here

Andres: Andres, welcome to the show Hi hello Jonathan, hello Katherine, and for having me today.

Jonathan: Yes, yes, I appreciate you being here. Appreciate you being patient as we worked through a few uncharacteristic technical issues at the beginning of the show. Had some gremlins in our system today, but hopefully those are behind us.

Katherine: So it's funny when the nerds can't make it work. It's like, what hope for what hope is there for humanity?

Jonathan: Yeah. Yeah. Okay. So J releaser, give us kind of the, as we say here, the 30, 000 foot view, like what, what does this tool do? What do people use it for? What, what problem does it solve?

Andres: So the problem that it solves is a releasing any kind of projects into any given targets that you may have, for example, the most basic way is create a GitHub release page and uploads any binary assets the project may have as release assets.

And post announcements to different announce communication channels, where it may be X, Twitter, Mastodon, Slack Mattermost, I mean, email, there are many, right? If you happen to be built an let's say a macOS app or a command line tool that you would like to see installed using popular package managers.

Such as homebrew, macports, scoop, winget, all these things. Then the tool will also generate the required manifest files and create additional git repositories if needed to push out those files so that the package managers will have a much better time and you as a final consumer will just simply have to do brew install my app and then you're done.

Jonathan: All right. Brilliant. Huh. So, it's, it's aware of all of these different places you might push to. Now, is, is JReleaser aware of things like, say, a let's say GitHub Actions? So I know a lot of projects have some of this automated where, you know, you have a github action that you go and you run it manually and it will, it'll bump your version number and run your, your final tests and then produce your release.

So can, can you set jreleaser up to like watch a github and just watch it? Automagically go from there.

Andres: Yes. In this case, you will definitely have to configure a gift of actions to listen to a specific GitHub events. So that is completely outside of the scope of any tool that you use. This is just regular GitHub semantics, but once you do, you can cook, can cook it in with any particular tool you want.

In this case, Jerry Lisa can be using this way. Your leaser can be consumed as a command line tool, regardless of the project of your choice. You mentioned that yes, it is written in Java, kind of hints at it by having a name, a J in the name at the front, but it can be used for any kind of project. So if you like Rust or Python and Node, Perl, even, even Python or something else, you can certainly use it because you only need an external configuration file, whether it be JAML, JSON, or TUML with these different formats.

And you could just run it in the CLI. So there is a specific GitHub action, JRELISA configure for GitHub that you can use that will read that particular external file and it will produce the the release. Now, if you happen to be using a Java project. Then there's also tighter integration with well known Java build tools such as Maven, Apache Maven, Apache Ant, and Gradle.

So whether you want to use an external command line tool, an external configuration file, or you use build specific plugins, the release tool will help you.

Jonathan: So I assume JReleaser is built in Java, right? That is correct. And do you, do you manage the releases of JReleaser using JReleaser? Are you, are you dogfooding?

Oh

Andres: yes, in the first place. So this is one of the things that we did since the early days. So the project started, if I'm not mistaken, the first commit happened around November 28th of 2020. So I was bored during pandemic. And so to say, I can give you the quick history of how this thing happened. Yes, I am a Java developer, but I also work with our search languages.

So I created a command line tool using Go. And I needed a way to release it. Now, I didn't know exactly how to do these things. I was looking around it and I found a nice project called go release it. If you're working with go languages, with the go language and producing these kinds of things, you owe it to yourself to have a look at go releaser.

com because the best tool you can use to release a go at the moment. Now I provide a lot of things, exactly what I mentioned before, create a GitHub page with a release and upload the assets create all the package managers files that are needed. And at the time it didn't announce. If there's something that it added later, thanks to Gerald Easter.

So it is a little bit of a cross pollination within the two projects. And so I was very happy with what Go did at the time, but I also continued to work on Java projects, and I needed a way, now that I know how it's easy to do things with Go, I wanted to do the same thing with Java, and there's no tool like that.

So talking with some one of my friends that did the same thing. So, I mean, he wrote a command line tool and wrote everything by hand to release the homebrew, create a Docker image and a post announcements, all these things. And every time that he needed to make an update, he will have to look at a bunch of scripts to find out what exactly needed to happen.

So we took those two things, those two projects as, as as an input and as an inspiration, and that's how Jerry Leaser, the tool came out to be. And since the first day. Since we're starting to push, really commits to the main branch, we, we use the previous version of Jeralyzer. We obviously had to do some sort of bootstrapping, but the previous version of Jeralyzer will be used to release the next version of Jeralyzer in some sort of early access snapshot fashion.

And the great thing is that this configuration file that we have for early access can also be used for a stable releases or final releases. And the only difference that we have is the, whatever input file, the input version of the project it is. So if I want to release version, the latest version is 1.

13. 1. Whenever I want to release 1. 14. 0, then I just need to click a button on my GitHub action, whatever, when my GitHub workflows I had configured in the project, give it what is the name the version number that I want to release, and it just happens. And I'm quite confident the release is going to work.

Because I have had more than a thousand releases happening every time that I do a push to main So this release configuration has been battle tested a long time.

Jonathan: That's it's funny It's also kind of funny that you've got one of your you know, like your your big final test Is the release like that humors me the the the?

That's what eating urine dog food means to some extent. But that's, that's funny that you've got that big test built right in. And like, if something were broken, you'd know about it. You'd know about it right when it was a problem.

Andres: Yeah, yeah, exactly. So we have plenty of tests like every other project, but we know for a fact, there are some things that will be very hard to test.

So the actual we actually testing production by releasing these early access pushes.

Jonathan: Yes, that's great. That's funny. So is this limited to doing releases of Java projects?

Andres: No, it's not limited at all. You can use it with any kind of source projects. We do have, as a matter of fact, on the website of the project which is jarlisser.

org, by the way, you can find a set of examples for non Java projects. So let's see if I can remember all of them that we have. We have C, C Perl, Haskell, Ballerina, which is JVM language, but it's not Java. And we have Ruby, I think. We have Crystal, which is statically type Ruby. We have Zig and I think we have, I think we have Swift as well and Rust, obviously, everybody's doing Rust these days.

So if there's something that I didn't mention, it's not that difficult to hook it in. Python? Is Python in there? I don't, I don't think I'd set up Python, but it wouldn't be that hard to set it up. So,

Katherine: I have a question. So I noticed when you released, so I did a little bit of looking things up. When you released, you announced that you can even do things like it announces your releases on Twitter or elsewhere, right?

Which is kind of fun. It's, you know, full automation from end to end, right? Making developer lives easier. What are people asking you for in terms of feature requests? Like, what can it do yet that you wish it could do?

Andres: Ah, okay. Well, it's worth mentioning that we support not only GitHub, but also GitLab and Gitea.

So if you have your own instance of Gitea, then off you go. And when it's both, in terms of GitHub and GitLab, it's both free versions and enterprise versions. That's not a problem. So we have, have had a suggestion to support Bitbucket as well. There is, as a matter of fact, a pull request pending. The difference, if you know what is Bitbucket, it works in a different way as GitHub and GitLab, in the sense that it does, the service of a Bitbucket does not provide what is known as a Git release page, like GitHub and GitLab do.

Andres: You will have to post create a document perhaps on Confluence and some of the sites, and then uploads all the assets in some way, some sort of attachments perhaps to that page. So if we were to do these things with Bitbucket, we probably would have to support additional tools in the Atlassian toolbox.

And that's certainly something that we want to do. But it's still it's still work to do.

Katherine: Yeah. Some people have, you could see a lot of value there. Yeah.

Andres: Yeah, some people have asked us also to assemble binaries using Deviant and RPM, which we can do. But for the time being, it's limited for Java projects.

We use a command line tool provided by the the Java development kit, the JDK, which is called JPackager. These ones create the files that are this, this kind of native installers, but they bundle a Java runtime because your project has to be Java. So if you want to create a Deviant file or an RPM for a non Java project we'll have to support that in some way.

And that's, that's something that we have in the roadmap and having a notarization for Apple or signing artifacts using the sign tool for Windows, which is kind of required for some installers. That's also some of the things that people have been asking, but we have yet to to provide those.

Jonathan: So I'm, I'm curious, I don't, you just mentioned Apple, but I don't think this is, this is part of what you talked about.

What about mobile applications? It. We, we, we think about this idea of, you know, doing your release and you have all of your manual steps you have to get done as a release and one of the, one of the projects that I've worked on that it was just a lot of manual steps to get a release together was pushing out like a new version of an Android app or I'm sure, I'm sure it's similar with an iOS app.

Is there support in JReleaser for doing mobile apps and getting things, you know, pushed up to the, the various places where they need to be?

Andres: Not specifically yet in the sense that if there is a specific channel or a specific remote service for publishing these applications, I mean, the App Store or in the sense of Mac is you have to both notarize This is something that could technically be done today outside of jresep, but tying it up in with the same configuration file.

Jresep has two mechanisms to extend itself if there's something that is not provided by the core mechanism. There's something called script hooks or command hooks you may think of as I mean, it will be as if you're configuring some sort of gif of actions within the configuration file for javalisa.

The syntax looks very similar.

Andres: the other one is a java specific extension that needs to be loaded by the java tool in order to provide the behavior that you want. Now, it's possible to do what you describe using command hooks or script hooks. Someone could certainly do this. The, the disadvantage is that it's as project specific.

So if there will be more projects, more mobile applications, I would like to take advantage of the things. And someone would have to either create an extension or we will have to figure out all the steps that were following this way and find a way to get it into add it into the core behavior.

Jonathan: So would it, would it be fair to just kind of categorize JReleaser as it's very much like GitHub actions, but run locally?

Andres: You hit it right in the nail. That's one of the things that we have. We have a drive run mode, so you can test your configuration locally as much as you want.

And another thing that is the reasons why we have these pushes for early access on, on, on every commit domain, because whenever we add a new feature, I can test this thing locally before I can push and then create maybe a faulty early access. So once you have your configuration or you're just getting started, You can set it up with drive run drive run equals throw all the time.

And then you just keep going, going, going, iterate until you find it. Okay. Now, apparently now this is good to go and then you can push it to the remote. And it is it is a lovely

Jonathan: feature that you can do things with dry run. I cannot tell you the amount of times that I've been working on something.

Particularly with GitHub Actions, because it is, it is, it is possible, but it is very difficult to run GitHub Actions locally. And even when you do it locally, it's not quite the same as running it up on GitHub. And so, you end up with about 15 commits in your project of trying something with GitHub Actions that didn't work.

Like, these are the commit messages. Trying something else with GitHub Actions. Hopefully it'll work this time. I'm about to give up. Why? Like, these are, these are real commit messages. Why is this in my life?

Andres: Yes, exactly. So, so yes, the tool allows you to test out things locally as close as you can.

And I mean, if you really want to, for whatever reason, you can also push out a real release from your local environment because you, because you may not trust GitHub or any other remote services with certain particular secrets. And that's fine. So, and the tool is designed to be used in both ways, local and remote.

Jonathan: Yeah. Is it, is it essentially the same running it locally and remote or is there, you know, is there some fundamental difference about if you run it on a service somewhere?

Andres: No, it's exactly the same as the same command line tool and the same configuration file.

Jonathan: Okay. What, what are the, what are the options for running it remote?

Like where does that make sense to try to do this remotely? Like is this something that will happen in AWS? Can you run, I think you said that there is a there's a J releaser action already built into GitHub. Like where, where are the places where you can have this in the cloud as they say?

Andres: Well, the my recommendation is that you pick your CI city tool of choice and then configure it there.

We have a summary finding the guide in the, in the webpage of the projects. We have, I think there's integration with 16 different services. At the moment, there is two that are specific, one that we already mentioned a couple of times, which is gif of actions, and the second one is GitLab CI, so as you may know, it uses docker containers, so, we do produce a docker image for jreser that you can use in any other way that you would regularly use a docker container, but this one has additional settings to detect if it's running within the GitLab environment, or the GitLab CI's environment, then it will set certain specific environment settings, So that it will do the right thing for you.

Jonathan: And then, and this is of course on our mind because what, two weeks ago now we we, we blue screened the entire world and CrowdStrike pushed out a bad update. Does JReleaser have test suite support in it and will it, can you set it up to abort pushing an update if one of those tests fail that you expected to pass?

Andres: No. And the reason being is that Java Elixir is a release tool, not a build tool. And this is the reason why we can support many different languages, regardless of whether it's Java or not. Because you keep using your build tool of choice, whichever it may be. Cargo for Rust, and Scones or Conan for C whatever it is, right?

Yeah. Once you have built your binaries, if you produce any binaries, Then you continue into the release process. And this is where Jeremy, sir will help you. Okay. So if there weren't any tests that were failing it will be a, steal the the job or your bill to find that out. And if the bill fails, then that's where you stop.

That being said Jerry sir does have support for additional security and supply chain settings. For example it recently added support for generating the input file required for GitHub attestations.

Jonathan: Okay.

Andres: So if you're released on GitHub and you want to use their recently added GitHub attestation feature.

You need some inputs and Jerry said can compute certain inputs, so it makes your job easier

Jonathan: that that would you that wouldn't happen to be related to a a certain compression library that contained a backdoor for SSH. Would it,

Andres: No comment? Yes, the other. The other option for at the station is salsa.

Yeah, yeah, it's also about that and that we do have a custom bring your own builder. That we built along with the, the salsa team. So if your project configures Chevrolet set and it's Java based where it's maven upgraded, they just pointed to our Java builder and it does the thing for you and it generates the attestation file and it will upload it to the release notes well to as a release asset into the same release that you just created.

We can also generate SBOMs and SWID tags, and SBOMs, whether it's SPDX or Cyclone DX, we support many different formats. Okay,

Jonathan: so I, I think You beat

Katherine: me to the S Bomb question. Well,

Jonathan: so let's actually, let's dig into that a little bit more. And I think I'm following along with what, you know, these, these acronyms and extended acronyms mean.

But for, you know, not everybody is in the weeds on this. So what is an attestation? What is an S Bomb? And why do people care about it?

Andres: So, an attestation is some sort of file that is signed, and that it proves the provenance of an artifact from a certain location. So you can, you can tell. That a certain binary has certain given signatures and hashes that it was created in a, in a given environment so that you can, if you as a consumer, someone can tell you this environment is safe and it has certain characteristics that you can verify this with the attestation and the artifact.

You can also verify that the producer, the person that is giving you is providing you the artifacts is actually the one that is saying who they are because of the signatures. In case of SBOMs, it stands for Software Bill of Materials, and that's something that has been known for quite some time, but it's now become much more important in the last two or three years for two reasons.

There is I think there's, I completely forgot the name of the of the memorandum that came out from the White House two or three years ago that says if you, if you are a software provider and you want to deal with the, with the government, then you must provide SBOMs. And in the European Union, we have a similar thing called the Cyber Resilience Act.

Now, these two things, these two things came out, have came out into force as law this year. So if you are dealing with government and offices, you must provide these additional metadata files. And because it's somehow most common in governments. Other companies will also start asking for these things regardless is governmental related or not.

So In in a few years ago, this was like, okay, let's figure out what it says bombs Maybe there's some tools do conversion what not now Place if you you are not ready to produce s bombs You must do it right away today after you finish listening to this podcast.

Jonathan: And a lot of that came about as a result of the, the big log for J vulnerability back about three years ago now.

So, and this is, this is something I kind of want your thoughts on because it's, it's, it's one of the things that I'm not crazy about, about Java. So when you build a Java application, you've got. Your entire library stack gets pulled into your, usually it's a jar that you distribute. And so what happened was one of those library bits was log4j, which is, it's just a piece of logging software.

It helped make your logs look prettier, right? But it had a, it had a problem, had a vulnerability in it that you could give it a, a bit of string and it would, it would essentially try to expand the string. And as a result, you could. Run shellcode you could run like command line code using this this specially formatted bit of string And the problem was that this thing was so popular.

It was everywhere like it was in Minecraft but because Logging is great. It was also accessible from everywhere. And so Like in the example of Minecraft, you could join somebody's server, send a message over the server, like, like sending a message from one player to another, and because it was trying to log that, you had remote code execution with this really trivial, you know, way to do it, and because of the way that Java builds these libraries right into the JAR, You can't just update the library.

You had to then update every program that contained the library. And so the thing that happened though is, there was then this question that every corporation and the governments needed to ask is, does our Java application contain that? What version of that library does it contain? And so then you had this idea.

I, it probably, it probably wasn't conceived of then it probably already existed. I honestly don't know for sure, but it became very, very popular because people suddenly saw it would be really useful to just have a list of all the libraries that this program contains. And so that's kind of where we, where we came to this, this point of.

S bomb software build materials are really important because there, there will be, I mean, obviously there will be another log for J there will be another vulnerability that is that bad. And people want to be able to get out in front of it a little easier this time around.

Katherine: Well, the whole conversation around dependencies is, is so, soft, I can oversimplify and say software is a lot more complicated than it used to be.

And so you look at these dependency trees, you know, and think about the good old days when you had a handful of dependencies and secondary and tertiary, but now it's, you know, if you actually draw a picture on some, especially web apps, it's kind of mind blowing. You can't even see it, it's such a mess.

Andres: Right. So, so basically SBOMs is just a recipe that lists all the dependencies that you have in your project, how it was built. And and because you have this list, then you can go to some other remote service and ask if any of those dependencies have any vulnerabilities. So the current focus that we have for SBOMs is check for vulnerabilities, but it's important to remark that SBOMs can do more than that because there's just many, I'll tell you that.

Right now we're just trying to check that if something is vulnerable or not, but we can do more than that just because we have that information about the project themselves.

Jonathan: Yeah. So there's, there's some other interesting things people are doing with SBOMs. I think groups like Tidelift are taking your SBOMs and actually saying, Hey, if you will pay us essentially a subscription fee, we'll take part of that fee and turn around and give it to the open source projects that make up your SBOM.

Like some really interesting things like that are happening being, you know, where this idea is being reused for things other than just vulnerabilities. It's really fascinating. I, I'm curious if you have any thoughts on, and again, I warned folks, I have just, just a little annoyance with Java and it's not just Java.

It's several languages that do this, but the fact that all of those libraries get built in at build time and the fact that that makes it more difficult. to up, to do an update when you have a library problem. So, on the other hand, on the other side of the coin, in a C project, where you have libraries that are just system libraries, you can just go and update the system library and fix the problem.

Like, it's kind of a bit more, let's just say it's more challenging in a Java project to do library updates, it seems. Is that, is that accurate? Is that a fair thing to say?

Andres: Well, so, I mean, if you have access to the system and do a patch that is affects the system wide, then great. You have admin, you have root, but if you don't, and then you, you get hacked, then off you go, all your C apps will be affected.

Whereas in a Java app, if it's contained to just a set of applications that are not completely system wide, then you only need to patch those. Now the problem is, find each one of those that may or may not have been affected. You may be lucky if it's only a handful. You may have a terrible time if you had to check every single one of those.

Jonathan: yeah. Okay, so What I, what I heard you just say is that I approach this, this conundrum from a very sysadmin point of view and not an application writer point of view.

Andres: Yes, kind of.

Jonathan: That's, that's an interesting observation.

Andres: There are pros and cons from both approaches. Yeah, yeah, that's,

Jonathan: that's true.

That's, that is, of course, true. Okay, what about what about Node. js and Kubernetes? It's hard, it is hard to talk about like this style of problem without thinking about things like, what was it, right pad, or was it left pad? Left pad. Left pad, yes, yes, yes. The single, the one liner JavaScript library that someone decided, you know, they weren't getting supported for it, so they just pulled it and made it disappear.

It's difficult to talk about the supply chain issue without thinking about left pad. So does, does J releaser help with no JS and JavaScript applications as well?

Andres: For, in the, in the case that we just described, I mean, dependencies and all these things. No, it's a, it's completely out of the scope by the service that allows you to publish the packages and consume them because that particular service and okay, I mean, this happened, what, like eight or nine years ago?

It's been a

Jonathan: while ago now. Yeah.

Andres: Yeah. I have not been kept up with times, but the problem at the time was that that particular repository was not read only or a pen only. So you could modify it. And that's exactly what happened. Someone said the the author of Lepa said, I'm, I'm angry because I mean, we can talk about this, the story, but he said, okay, I'm going to unpublish my packages.

Mm-hmm. , because this is what you did to me is, is not what I was expecting. That boom, that broke the internet for three days. In the case of Maven or in the case of the Java system, we have this repository called Aven Central, which is a panel only. So once you publish a package, it's stuck there.

You cannot unpublish. So if you made a mistake, well, sorry that stays as it is. And if you made it right, then also it stays as it is. So that's a real advantage.

Jonathan: Yeah. And so can, can you use can you use J releaser to, to push no JS packages?

Andres: Right now, if it's published as a regular HTTP yes.

If we need additional support for, I mean, if it's more than just a simple By simple, I mean post or put and be authenticated. We probably need to add a specific support for it, but if it's just a regular HTTPS endpoint where you do a post and a put, then yeah, you're good to go.

Jonathan: And I suppose because in JReleaser you've got like script hooks, so you could, you could probably just hook in to run a bash script as part of your release process, right?

So really, so really the sky's the limit. You don't have to have support for all of these things. Like I could, I could sit here and we could ask about, you know, every package manager out there and every language out there. But the, the reality is you can write your own script and have J release called script and you get there that way.

Andres: Yes. So obviously the advantage on cool is that there is already a DSL where you can define all the kinds of configuration. And this DSL works for every single environment running environment that scribe before where they see a live. Or is Maven Gradle plugins and end all those things. Now, this DSL allows you to reuse common configuration that you have for the different steps for Excel or, or settings.

So there is project common configuration, like what is the name, what is the tag name? Version number, release name, stuff like this project project author, links, text. So many different things. And then there are sections where you configure the actual release. Mm-Hmm, . Where is it going to go? Is it going to be to GitHub or GitLab or something else?

And you also can configure release notes. So this, this is something I wanted to come back something when you mentioned where you're trying things locally and then you create a bunch of, of, of commit messages. We always do, we most likely use throwaway commit messages. But if we don't do, we don't squash it, we don't rewrite those, those trash commits will remain forever into our history.

So one thing that the tool allows you to do is generate a release notes based on commit messages. It's not the only tool that does it, but this is something that if you define your own conventions and by the way, we support out of the box, conventional commits or gitmoji conventions it makes your life much, much easier.

So all these things make sense when they are completely baked into core. If you want to use a script hoops to support The package manager that we don't support yet, you can certainly do this. But I mean, if you feel that maybe it's too wonky, yeah, it kind of works, but if it would be better to have support of core, we certainly would encourage those people that write a custom scripts to come back to the project that open a discussion topic or an issue so that we can track this and then figure out a way how we can add that behavior back into code.

Yeah, absolutely.

Katherine: So when you talk about things like release notes, I start thinking of like I don't know. I mean, I, I feel like every project kind of has their own style in a way about a lot of things, not just release notes, but talk to me a little bit about extensibility. I mean, again, projects have their own needs.

And if I have specific needs, what, what can I do? I under, I believe you have an extensible architecture. I can write some sort of plugin or something to customize it to my own needs.

Andres: Yes. We have an extension mechanism and there is a handful extension points at the moment. So the the full configuration, the whole, the whole life cycle is not yet extensible.

We're just adding, well, a few extension points at the moment. And one of them, it is that has not yet been added, but it's something that we have in the roadmap, is fully configure how release nodes or the changelog gets gets created. We have the options to, already, to parse these conventional commit settings, or you can define your own presets, your own conventions in, in declarative way we can also take in a changelog from an external file or instruct GitHub to use their native way to generate release notes based on issues and pull requests if that's what you want.

But if you want to post process this release notes in some other way to, I don't know, change some text into emojis or do some kind of text replacements, it might make sense to write your own custom extension. And this is something that will certainly be added into the future.

Jonathan: So one of the, one of the interesting things that you can do and again, I'm most familiar with, with using GitHub for this sort of thing.

That's why I keep going back to it. But one of the interesting things you can do with GitHub is you can make your you can make your release process like transparent. People can look at it. It can be part of, you know, your, your GitHub code that's out there. But then when you do that, you, you suddenly have this problem.

I'm like, how do you. Keep all of your your keys secure and secret. Because obviously you don't want to leak. You don't want to leak a organizational GitHub key. You don't want to leak an AWS key. And there, people have come up with ways to do that. And there's even some tools out there now to scan for those things, to make sure you're not leaking them.

I'm curious whether this makes sense, like, is this a thing with J releaser as well? Can we make our J release? It's not exactly a script, essentially a script. Can we make that public? And if we do so, do we, do we still run this problem of, you know, leaking secrets that really should not be leaked?

Andres: Certainly you can, you can make it public as a matter of fact, the Jerry's her project has his own release configuration made a public and everyone can see that they are certain elements with property that given setting is a secret.

So they, because we know certain property, so take those inputs coming from environmental variables. So it's up to you to provide the secret in a proper way with gift of actions. And using environmental variables and that's something the same thing that you can do on your local environment.

Jonathan: Okay, that makes sense Yeah, good stuff.

So let's see As you as you look at as you look at the jrelease project What what do you see coming up next? Is there something that you guys are working on already that you're you're excited? Well, you know before I even ask that there's a couple of other questions that I wanted to get to and and that is well First off, what license is this released under?

We talked about asking people to push things back upstream. What license did you guys go with?

Andres: We went with Apache v2, this one. Okay, so that's a And we also have a CLA.

Jonathan: Oh, okay, okay. That's a pretty permissive license. Let's people do pretty much what they want to. Now, I'm curious, what's the rationale behind the CLA?

Andres: The CLA was done so that if in the future we would mind to relicense a project then we don't, we don't need to hunt down every single committer to make this happen. So for those that are in the Java space, there's a very well known project called Hibernate, which is an object relational mapper.

Everybody likes it. And there's also a lot of people that hate it just because it's an ORM. And it started with a GPL license. And they wanted to migrate to Apache v2. It took them more than three years To search for every single committer to ask them for the permission to do this license switch So the one of the advantages for a project that have a cla is that if you write down in the cla that Well, not only that everybody has to sign it so you can know who who there are how to contact them But also if you write down in the cla that the the project The the commit has given the rights to the owner of the project.

In this case it will be me.

Andres: Then I have more limiters to do in the future, but obviously this is not some evil ploy to do something in the future. But it's just to make sure that, to, to put out things in the open again, to, to ensure that if you are willing to commit to contribute to the project, then know that these are the conditions and you're fine with this, then go ahead.

Yeah, you

Jonathan: know, I'm, so I, I'm part of a project that has a CLA as well. And it's for very similar reasons. It's the, the, the reason there is if we discover in the future that there's a problem with the license, this gives us the ability to relicense it. At the same time, you do see businesses and projects out there that have CLAs that let's just say they use that power for, for what some might consider evil.

Right. And I w I wonder whether it would be possible to write a CLA that Is a little more, a little narrower than simply giving all rights to, you know, the, the upstream organization. I wonder whether we could write a CLA that just says the upstream organization has the right to relicense this to any other, let's say, OSI approved license.

I don't, I don't know if anybody's doing that, but that seems like that could be an interesting interesting way to handle this. You know, give, give a project some tools to fix things. If things go wrong, we're at the same time giving the people that contribute a bit of assurance that look, we're not looking to sell you out and go make millions of dollars on the backs of your code.

Right?

Andres: Yeah, exactly. I completely understand. And I agree.

Jonathan: Yeah, that's, that's an interesting thought. Okay. So you, you, we also have talked about other people contributing things. What does that look like in JReleaser? How many, how many people are working on this and how many contributions do you get from outside?

Andres: We have a small team working on the team, on the, on the tool, but we do use don't know. And this is also sort of conversion, but it's another application that you can set up on GitHub since our GitHub action is called all contributors. And with this, you can have a very nice looking markdown based documentation where you see the avatars as every single contributor.

And they are listed by the type of contributor they made, so whether they fix code, they are announcers, they promote the project, or they're doing documentation, internalization, so there are many ways. So for every single contribution that is made for the project, whether it's just one typo, or it's a big contribution, we list every single contributor over there, and I believe we're past 70 contributors at the moment.

Jonathan: Yeah, that's really good. And you get a lot of I call them drive by contributions. It's where someone has one specific thing that's either broken or, you know, that they want added, and they, they drive through and they drop off their patch. Here's this new feature, and then you never hear from them again.

Is that fairly, fairly common there?

Andres: We have had a few in that, in that regard but those that are part of the the core team Most of them have joined us since the early days again, since since 2021 started discussions on how the two could work. So I will say that it's it's, it's a herd. I mean, it's a healthy mix of long time contributors, even though small set and just quick contributions from all around the world.

Sure, sure.

Jonathan: That makes sense. All right. And then I was, I was going to Let's see. What was the question I almost asked?

Jonathan: What what's coming up? What's what's in your roadmap for the future.

Andres: Right. So, so in the early days of the tool the reason why it was written. So it was so that I could release a command, a Java command line tool in many different aspects. Now for this to work, the package manager has to understand that your binary has certain file structure.

So they will know what to do with this onManifest and every other file that it requires. So for, for this to work, we have diff like a set of distribution types. There's your standard Java binary where it has a, a, a script or a launcher. And the list of jar things that have been asked for the tool is to support source distributions.

Once we do this, then how we will be able to create source RPMs. Or deviant files for sources or support any other kind of package managers that will deal with source distributions other than binaries is something that will certainly be looking at how to make it work.

Jonathan: Yeah. Interesting. All right.

Katherine, anything you wanted to ask? I think you've covered

Katherine: it. I

Jonathan: get down towards wrapping. I,

Katherine: I don't know. I think you beat me out to all the questions.

Jonathan: Sorry. Okay.

Katherine: Yeah.

Jonathan: So I'm, I want to know, is there, is there anybody out there? Is there a project or anything that you know of that's using J releaser in a way that just surprised you?

Is there anything weird? Yeah. Are there any surprising uses?

Andres: So there's actually some sort of interesting look within one of the, our inspirations for Jerry cert the project that I failed to mention it before is called J bank. It's a command line tool that allows you to launch Java applications in many different ways.

And once Jerry reached a certain level of maturity, J bank decided to complete it. Their own manual way to do things and use Jarlisa. And both Jarlisa and Jbank use a package manager called sdkman, which allows you to install binaries just for the Java platform. So this is like, similar to RVM for Ruby, I believe.

As a matter of fact, that was the original inspiration. And I am, I am in talk, well, I was in talks and I'm, I'm not, I'm kind of a member for the SDK package manager as well. So at some point, sdkman also uses Jarlisa. For some releases. So the three projects are kind of like joined at the hip. If something goes wrong with Jarlisser, then obviously Jbank and SDKman will know immediately what happened.

And one more thing that I can say happily is that these three projects alongside alongside other six are now members of a brand new server foundation called the Common House. You can go to commonhouse. org. The idea behind this foundation is that we want to provide a long term home or a forever home for open source projects.

We started with we're targeting well known Java projects, but it's nothing, this is not that it's close to non Java projects. So in the future, for sure, we will be able to support any other kind of project right there. Because the whole point is that if you have a project that has has created a good impact in a certain open source community.

And you feel like, I mean, the maintainers that they, it will be better to be supported by the umbrella and the facilities of an any given foundation that common house will probably be one of those options.

Jonathan: Yeah, interesting. All right, we are, we are getting towards the end of the show. Is there anything that we did not ask you about that we should have? Anything you wanted to plug or let folks know about?

Andres: One more thing is that we decided as part of the team to have a very deterministic release cadence.

We release a final release every two months. So if you are a consumer of the tool and you know that there is a feature that is upcoming, then you know that it will not take more than two months for this thing to be released or to be available in the next release. Another thing that the tool does, and we do use it for our own releases as well, is that every time that our release comes in, you can configure to have the set of issues that are related to that particular release.

To have a release label attached to it and add a new comment. I said, this issue was released on version such and such a link to the release notes, because this will notify the author of the two of the issue right away. So besides this, you can say I'll come publish to a slack or email or to Twitter.

Then I can also notify through GitHub and GitLab through their issue tracker mechanism. That there, something has been done. Something has been released. Oh, that's really cool. Also, we get that notification

Jonathan: that's that's, that's really useful that you can do that. Alright. So it, it takes you like two

Andres: or three properties.

Jonathan: Alright. One other thing that I, hang on, hang on one second. The technical issues have been terrible.

Katherine: Uhoh technical difficulties. Again,

Jonathan: let's see if I've got him back.

Katherine: Are you, are you the, you are the solo maintainer, right? Are. Are you the only lead maintainer on this project?

Andres: I'm the lead maintainer, yes, and we have two other people that contribute to the project, but I'm, I'm doing most of the work at a time.

Katherine: That was, yeah, percentage wise, I'm curious. So if, if you get tired, do you have a succession plan?

Andres: That's exactly why the project moved to the Common House Foundation. Because that is one of the tenets of the foundation to ensure that it's a succession plan. And this is something that we will continue to work on in the coming months to ensure that if something were to happen to me, then someone can continue with the project.

That's great.

Jonathan: And, if something God forbid, but if something happens, it's going to be easy for them to win the lottery. Well, it's going to be easy for them to continue doing releases because you've got your release script published right there in the public, right? Exactly. Yeah. I liked it. No, that's something actually that I've, I've thought about again, several projects that I've been involved in.

We have kind of this idea of like, who's going to take it over or, or, you know, maybe even it's not established, but you kind of get the idea. Well, it would be easy enough for one of us to pick it up, but then it's like, whenever a release comes around, it's like, what all does he do to do a release? And the steps, sometimes the steps are not easy.

Katherine: And even when you really all that good at documentation,

Jonathan: nobody is, nobody's good at documenting the steps for a release. You just, whoever does it gets it figured out and then just kind of does it at each time. I think, I think there's something to be said for J release or just for that. Just for the idea that it forces you to document your release steps.

And I think that's useful in and of itself. All right. So I do want to know favorite text editor and scripting language.

Andres: Huh. So my favorite text editor is a Vim. And if, because I like to be on the command line and if it's not in the command line is text made because I used a Mac and a scripting language.

Andres: Well, I started with Perl, then moved to PHP, and then jumped into JavaScript, and from then I jumped back into Javaspace, and I fell in love with the Groovy programming language.

So if I have to say just one of those, then I would go with Groovy.

Jonathan: Okay. Groovy is one that I am not particularly familiar with, so that's pretty fascinating. Is it I don't hear that

Katherine: a lot.

Jonathan: Yeah, does it it uses the JVM as well?

Andres: Yes. You can think of groovy as dynamic Java. Okay. Interesting. So the syntax is 98 percent equal and it's very easy to interchange the Java code with groovy code from within a groovy script.

Cool.

Jonathan: Very cool. All right. Well, thank you, sir, for being here telling us all about JReleaser. It's super interesting. For a couple of projects I do, I need to look into it. So we sure appreciate your time and bearing with us through a couple of technical difficulties. And we'll make all of those disappear, I hope, in the edit.

Katherine: Nothing to see here. Exactly.

Andres: Thank you so much, Katherine and Jonathan for having me

Jonathan: here. I really enjoy it. Yes, was, was very fun. Very much, very much appreciated. All right. Katherine, do you have any projects that need the J release treatment?

Katherine: Not at the moment, but I, I was thinking the whole time as I I'm listening to the, the, you know, all the marvelous things that it does.

How nice it would have been to have it in the past.

Katherine: That is really it, you know. I, I, I like to think that I've documented release processes pretty well because, only because I, you know, I come from a, a, a position of like, explain it to me like I'm five and, and if I don't document it for myself, I will mess it up.

So so there's that. But I, you know, it, it making, Things easier so that you can focus on the hard problems is such an important goal. Yeah, yeah,

Jonathan: for sure. Yeah, we didn't, we didn't explicitly ask him about this, but I bet you could use J releaser to even do things like push website updates and, and other, you know, not maybe not the things you would normally think of with it, but.

I'm sure you could script it and make that happen. So documentation updates, probably all kinds of stuff you could use this for. And, and again, so the, the, the point there would be you, you have it automated, you have it scripted so that you just, you, you, you run one command and it makes it happen. So like we, we think about doing an update for a piece of software.

Well, it's actually. In some ways, it's a similar thing when you do an update for a website, depending on how the website's put together. Sure, it's

Katherine: powered by software.

Jonathan: Right, right, right. And so, you know, on this side, it's not necessarily a programmer, it's a sysadmin doing it. But you have some of the same problems.

What happens when one sysadmin retires and the next one comes in? It's Okay, how do I update this? Maybe even, how do I get to the server? Where is the server that runs this? And I'm just, I'm just thinking like, this could be a great tool in the toolbox of like, IT departments and sysadmins to be able to do things like that.

So, a very, a very interesting project. And I like the fact, I really like the fact that That it's, you know, it's JReleaser. It was originally made for doing Java releases, but the sky has been become the limit for it. And they've, they've made it as modular as possible. So you can do all kinds of fun stuff with it.

Katherine: Yeah, I like, there's a lot of interesting stuff. A lot of, there are a lot of tools, I think coming out with JReleaser. The idea of making developers lives easier. I'm surprised we got through an entire, an entire episode without mentioning AI, by the way. So that's maybe for next time.

Jonathan: Yeah, I guess. I don't know.

This seems like maybe, maybe one where AI does not fit.

Katherine: Does it though? Automating things? I don't know. Automating. Processes. Do you,

Jonathan: do you really, do you really want to give AI the ability to push code? I don't, I don't think so. I, I think this is something that needs to stay out of the clutches of AI. I don't know.

I

Katherine: can see a little, a little, a little AI improving my release notes, you know.

Jonathan: Okay. Okay. I suppose.

Katherine: People, that's the thing. I think there's a lot of, a lot of like, Fear about AI and anxiety. That's unwarranted because we don't, we don't realize how many mundane things AI is actually used for. People think of you know, the, you know, the robot overlords will push the malicious software, but it's really like, I, I, can you just spell check my my release notes on an automated way?

Jonathan: Yeah. So yeah, that's true. You can, AI in your processes without giving it the keys to the kingdom. Right? So, you know, we, you think of the dangers of AI and people automatically go to that, that thought of Well, that's how you bring about the singularity, right? You give AI the ability to improve itself.

Well, That's not the only way that you can use this tool. You can give AI the ability to tap you on the shoulder and say, Hey, you might want to think about changing this because it sounds weird. Yeah. Anyway, that's a valid point. We will, we'll bring him back on one of their next big releases, and we'll ask about AI, and see if that's something that they're adding.

And

Katherine: then he'll roll his eyes.

Jonathan: And he'll tell us that, No, AI has no business being a part of your release project. What are you, crazy? Alright. Katherine, thank you so much for being here. Did you have anything you wanted to plug?

Katherine: Sure. Let's see. Yeah, there's that other part. So I do another podcast at Intel open at Intel.

Occasionally, I still do a podcast with DocsRules, although I need to get on that reality 2. 0. Let's see. I will be giving a bunch of talks. Yeah, starting in September, I'll be at Open Source Summit EU. I'll be, I'll be talking a little bit about AI and a little bit about security. So that's fun. And then I'll be doing it again.

And oh God, so many times.

Katherine: Yeah. Yeah. Yeah. I don't know. Find me on the internet and I'll tell you all the other times I will be talking about these things, but yeah. Grace Hopper for sure. All things open. I'll be at KubeCon probably also for sure. Sauce fusion in Atlanta. So that's an open SSF event.

That's something to plug open SSF stuff. A lot of really cool stuff going on there. We hinted at a little bit of it earlier with salsa.

Jonathan: Yeah. Yeah. A little bit going to be at, going to be at Defcon this year. Is Defcon on your, kind of on your radar?

Katherine: I would have, but I have so much travel coming up after that.

I need, I need a little time to, to, to. Be at home.

Jonathan: Alright. I understand that. I do. I do. Alright. Well next week we have another Java project. We're talking about LifeRay. I don't know a whole lot about that yet, but it is sure to be interesting. And I know it's a Java, it's a Java thing. In fact, when they, when they reached out to me, it's Olaf Koch and David Nebinger.

When they reached out to me, they're like, so we heard you mentioned Java. How would you like to do a Java project? I'm like, okay, fine. Oh, so that is next week. It's, it's, it's the second part of our two part Java extravaganza. So make sure and come back for that. And then, Oh, yes.

Katherine: Sorry. No, finish your thing.

Or I'll just interrupt and think I can't believe the most important one. I forgot. I will also be at Intel innovation where everybody should go. I put like, I forgot like the most important event.

Jonathan: You, you, you had one job, Katherine, right?

Katherine: I had one job. Intel innovation that comes right after open source summit, though.

So it's like in my head, it's all one thing, but that's going to be a big thing. I'll be doing podcasts on the expo floor and there'll be all kinds of like meetups for AI nerds, and it's going to be cool.

Jonathan: Cool. Very cool. So there you

Katherine: go. I got that out.

Jonathan: All right. Well the one thing that I do want to plug with the two thing, a couple things, several things to plug we've got hackaday, you can follow my work there on hackaday and most notably, we've got the security column goes live every Friday morning.

And, of course, we do appreciate Hackaday being the home of Floss Weekly. It's, keep your, keep your internet radios tuned to hackaday. com, and enjoy all of the coverage there. And then we've also got the Untitled Linux Show over still at the Twit Network. We have a blast there. You can catch that, it goes live we do the recording Saturday evening, Saturday afternoon, depending on where you're at.

And then within a couple of days that goes live, make sure and subscribe to that for all of the Linux news and musing that you need in your lives. I think that is it for today. We sure appreciate everybody that's here, both live and on the download. And we will see you next week on Floss Weekly.

This week Jonathan Bennett and Katherine Druckman chat with Andres Almiray about JReleaser, the Java release automation tool that's for more than just Java, and more than just releases. What was the original inspiration for the tool? And how does JReleaser help avoid a string of commits trying to fix Github Actions? Listen to find out!

You can join the conversation in the Hackaday Discord, watch live or get the video version of the show on Youtube, as well as getting the full story and show links from Hackaday. Oh, and follow the official Mastadon account!

Theme music: "Newer Wave" Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

http://creativecommons.org/licenses/by/4.0/