LINUX Unplugged - 390: Eating the License Cake
Episode Date: January 26, 2021Successful open-source projects all seem to struggle with one major gorilla. Who it is, and what their options are now. Special Guests: Drew DeVore and Jonathan Corbet. ...
Transcript
Discussion (0)
Well, it's taken nearly 25 years, but the mainline Linux kernel this year will finally be able to boot the Nintendo 64 game console.
I know you've been waiting.
It's about time. I'm switching everything over.
Yeah, I know. You've been talking about building clusters of N64 consoles.
I know how much you want to rock that 93 megahertz processor.
I'm just not sure what you're using it for.
You'll be surprised when you find out. to learn a new skill is by doing. That's why ECG provides hands-on labs, cloud Linux servers, and much more.
Get your hands cloudy at cloudguru.com.
This is episode 390,
which gave me a huge realization
that we are not that far away from 400
when we got started today.
It's a little scary.
Threw me off my game a little bit.
But we have a lot to get to today.
We're going to celebrate the anniversary of LWN.net,
a fantastic community resource. The founder will be joining us a little bit in the show to talk about LWN,
talk about the Linux kernel, talk about development in the Linux kernel, and a lot more. But before
we get there, we have a couple of special items on the agenda. So to help us address
those, I want to first introduce and welcome back to the show
someone brand new, new kid on the street, never heard of him before. His name is Drew. Hello,
Drew. New kid on the street. I've been here for years, sir. Welcome back. Welcome back. It's good
to have you. It doesn't show at all on your face. And I know that you're in the middle of moving
too. So I appreciate you taking a few minutes because moving life is worst life. Yeah, it just doesn't get worse.
Maybe we can be like a little bit of an escape for a bit from that.
Yeah, it's only 1,600 miles away.
So, you know, I mean.
Although I do dream at the end of it of Wes and I coming out there and us doing a Linux Unplugged together in person.
Oh, we got it.
That could be at the other end.
Let's do it.
Yeah.
Also, to help us dig through the community news, of course, we have our virtual lug,
time-appropriate greetings, Mumble Room.
Hello, hello.
Hello, everyone.
Hello.
Me and Benito.
Happy Sunday.
Yeah, this is a Sunday edition of the show, just kind of unannounced.
We decided to record a little bit early this week, and because it's a Sunday and Wes and I will be here all day long, there may have been some gin snuck into our drinks.
And we don't normally drink during a show.
No, we don't, but we also snuck some nachos in, so it's a special occasion.
It's like we've made a whole day out of it.
So we're sitting here on a Sunday.
We're hanging out with the virtual lug who has their normal up-lug session, and we just kind of came in there at the end. We'll talk more about that in housekeeping. But
first, I just want to get a couple of PSAs done because these are kind of important.
Number one, because I've talked about it a lot on this show, of course, we address this in detail
on Self Hosted, is Home Assistant has a second security vulnerability that they've identified
that needs patched and needs to be patched
pretty quickly. And they're really trying to get the word out about this. It's an issue that impacts
third-party custom integrations, and it's a significant vulnerability. And if you've already
patched, this is a second wave. I do some analysis in self-hosted, but I thought probably should let
people know. Yeah, allowed an attacker to steal any file without logging in
doesn't sound great.
Probably want to patch.
And the thing is, they had some mitigations,
but the mitigations didn't go quite far enough,
and so this is supposed to address that.
I don't have a lot more to add,
but this is, I think, to be expected.
Home Assistant is a very large platform.
With a lot of integrations.
Yeah, and that's what makes it so great at the same time. This is, I think, to be expected. Home Assistant is a very large platform. With a lot of integrations. Yeah.
And that's what makes it so great at the same time.
Well, and it's worth mentioning that one of the things affected by this is the Home Assistant Community Store hacks.
So make sure you get that updated, too.
Mm-hmm.
Mm-hmm.
Which I love.
And then there's another one. We covered the initial development of this story on Linux Action News.
And that was that Google announced they were disabling Chromium Sync for Chromium and Chromium-based browsers.
The typical Google Sync backend is going away.
And now what we are witnessing, since we covered that on Linux Action News, is the distributions and how they're all reacting and what they're processing.
Do you leave it in even though you know it's just going to end up being broken pretty soon?
Or do you take it out even though for the moment it's still working?
That's a tough call.
Yeah, because end users are going to think maybe something broke in the distro.
They're not going to know why.
It's not like they're following Google's Chromium development blog.
Yeah, and the error message I'm sure will not explain.
Yeah, and this seems a little sticky.
I've been following the developments on this, blog. Yeah, and the error message, I'm sure, will not explain. Yeah, and this seems a little sticky.
I've been following the developments on this, and one that's been really
fascinating is watching the Chromium
maintainer for Fedora kind of chew on
this, going back and forth, should we even
bother with the effort now
of packaging this bastard of a browser
when they're doing this to us?
So if you're not familiar with the whole story,
like I mentioned, Google has announced
they're cutting off that sync access.
And that's what we're trying to react to now as a community.
Now, the thing that's kind of odd here
is that Google gave the builders of the distribution
for Chromium distribution packages
access rights to this API back in 2013,
specifically so that they could have
open source builds of Chromium
with near feature parity of Chrome. And now they're just taking it away for reasons.
Tom Calloway did give a lot of thought about whether it was even worth the effort to continue
maintaining the Chromium package in Fedora. And that kind of says it right there, right? I mean,
just doesn't feel second class or even, you know, first class, second class, maybe it's a third
class citizen at this point, but it's almost not a proper browser
despite all of the great browsing functionality
that's built into Chromium
and how useful it has been to folks.
I feel like we could have a website
that just did nothing but track
when the deal gets changed on us.
Like an initial deal,
how the deal is then further altered
and you will not complain.
Like that's all we need
is how the deal was changed on us.
And to his credit, he's going to continue to package it because some users won't even
mind that Sync has been disabled.
And in the short term, he'll just kind of have to take the knock that people will assume
it's because of something he did.
It's interesting, too, to watch Arch and Debian have the same conversation and try to decide
what they're going to do.
Each distribution is really looking at it.
Some have already solved for this.
There's also kind of the universal package option here.
That's kind of the elephant in the room.
Perhaps, you know, in the case of Fedora, perhaps Thomas doesn't have to continue to package it
if eventually we got to the point where Flathub was just turned on by default.
And when you searched in software, software that's packaged like Chromium on Flathub was just turned on by default, and when you searched in software,
software that's packaged like Chromium on Flathub
would just come up.
Yeah, that'd be interesting.
Colonel in our IRC asks,
maybe this is an opportunity for a, you know,
a syncing service backend third-party integration.
Because kind of, you think about it,
you've just been relying on Google for that.
Maybe you wouldn't choose that.
It'd be neat if you could maybe use Microsoft
or some even more trusted third-party.
I agree. And Josh, what do you could maybe use Microsoft or some even more trusted third party.
I agree. And Josh, what do you think? Is this essentially Google killing another product or is this because it's just shutting off like an API key? Is this not quite that equivalent?
It seems to be the way that all the other services go. There's a little bit here and
then this little bit there and then you get the shutdown notice.
Yeah. Yeah. A little bit. It's a little bit of deal alteration.
It should be tracked.
I feel like this should be logged and tracked.
And then how the distributions have to deal with it.
That's an interesting aspect of open source.
Well, I'm just waiting for somebody
to reboot Xmarks.
Oh yeah, Xmarks.
The original bookmark sync.
Oh wow, that makes me nostalgic.
You were an Xmarks user with Firefox
back in the day, I take it?
Oh yeah, way back in the day, but makes me nostalgic. You were an Exmarks user with Firefox back in the day, I take it? Oh, yeah, way back in the day, but absolutely.
Yeah.
Okay, so let's talk about another deal that's getting changed.
And this time it's Elastic that's making the changes to the licensing around Elasticsearch and its dashboard product.
And they're changing it from essentially, I think it was like Apache version 2, to the server public license and the Elastic
server license, or just Elastic license. And Amazon has reacted pretty significantly with a
really strongly worded blog post, which we dissect in this week's Linux Action News,
announcing that they are forking Elasticsearch. And they have this whole rationale, of course.
And I kind of wanted to try to process this in a way that was
useful for the audience, even if they're not, you know, a corporate enterprise user that needs
Elasticsearch. And I thought maybe we'd get a little bit of Drew's opinion on this because
he's using it every day. He's been deep diving it actually recently at the day job.
And maybe we could start with an explanation of what Elasticsearch is. Yeah, absolutely.
Because it's not something that just totally makes sense until you really get into it.
It is essentially, it's a database search tool that's built upon Apache Lucene.
So it's similar in a lot of ways to Apache Solar, S-O-L-R.
So it's similar in a lot of ways to Apache Solar, S-O-L-R, but it is a product that allows you to ingest data, sort it, and search it.
And where the Elastic part comes in is that it scales both horizontally and vertically.
So you can either add more servers to it, or you can add a bunch more storage on a particular node. Whatever your use case is, whether you're read heavy or write heavy, you have options for how you want to build
out the infrastructure. And you can have clusters, you can have distributed clusters, you can have
clusters that talk to other clusters. Basically, it is extremely flexible ability to search. And so what we're using it for
is monitoring and log aggregation, more on the log aggregation than the monitoring right now,
because we have other monitoring solutions. But what we can do is we can deploy these really
lightweight agents that just pull in all of the logs. Sometimes I
have to write custom parsers for them if they're not, you know, in a standard format. And then we
get it all into Elastic and then I can use their dashboard software, Kibana, which is actually what
Grafana was originally forked from in order to visualize this data, create dashboards from it, and really get it in a way that we can have, like, say, a particular service that we can then monitor the logs for in almost real time.
And so the deal that's been changed recently really doesn't affect a deployment like yours, right, Drew?
Your use case isn't really impacted by the changes Elastic has made here. It's more directed at big shops like AWS.
Yeah, exactly. It's directed at people who are taking the product and then building out additional services on top of it, repackaging it and selling it as their own product like AWS Elasticsearch has been doing for years.
product like AWS Elasticsearch has been doing for years. It's the same kind of thing that we've seen companies like Redis really struggle with, and then they try to re-license to avoid having somebody
just take their work and hoard it into something new and start charging for it without giving
anything back. Now, AWS is saying, well, hold on, we've been pushing code changes up and
really contributing to the project. And now we're being punished for it. So why not just fork it and
release our own product built off of the latest version of Elastic, which was still open source,
and just have an open source fork? Yeah. How do you feel about that, though? Because it seems like it's going to perhaps,
because you're going to be using the original,
and then there'll be this other thing out there in the industry
that may over time change from what you're using.
Yeah, I don't know. I mean, time will tell.
It's a bit of a gamble either way, I think.
You know, will Elastic continue to really dominate the market? All signs kind of
point to yes, because they're really deeply embedded in enterprise. And so is Amazon's
version. So who knows which one's really going to come out on top. Right. I know a lot of places
that essentially use it for their user facingfacing website, too, to surface search results and sort their content libraries and whatnot.
Absolutely.
You can't overstate how significantly popular it's become.
Wes and I were looking at data for our Linux Action News reporting, and you can just see explosive growth around 2018, where it just kind of gets next-level crazy.
Crazy.
Right, everyone's got an Elastic Stack cluster somewhere on their premises.
I mean, everyone's got an Elastic Stack cluster somewhere on their premises. I mean, you have to. It's a $15 billion business for Elastic, and that's
not even counting all of the people who are using it from other services that are hosting it.
I wonder, too, if that's part of all of this. Obviously, the fact that Amazon is
giant and sort of the default makes things more complicated, because it's not sort of just Elastic
competing against a similar company. They're competing against this behemoth.
And, I don't know, that's just a tough environment to exist in.
But maybe it doesn't make sense for a company
who's trying to operate on an open source basis
to necessarily be that large.
Like, is the value they're providing,
does that valuation make sense?
Or does it make sense to be a smaller,
more steady state sort of operation?
But in these days, everyone's trying to be the big unicorn
and make a whole bunch of money for your investors, right?
Right, everybody's got to make that VC money back.
And yeah, that's part of what's the pressure here,
is there's a lot of investors that put a lot of money
into these kinds of things and they expect results.
But Neil, I think fundamentally one of the issues
that Wes and I were struggling with is
this license looks a little concerning.
Yeah, so like one of the bigger problems with this thing is that the server-side
public license, which if you all remember from a couple years back, this was actually created by
the MongoDB folks when they re-licensed from the new
Afero GPL version 3 as part of trying to drive more
growth into their enterprise commercial product. The problem with
the SSPL is, well, aside from it
not being classified as an open source license, the open source initiative has not deemed it as
such. Fedora particularly has a decent analysis of why they consider it not an open source license,
particularly around like, it's hard to discern what the bounds are. And it seems to be,
you know, punishing to a certain field of use and endeavors.
The issue is that for a lot of organizations, they rely
on fundamental assumptions about how software consumption
works for compliance and making sure that
to de-risk their usage of solutions and infrastructure. For example,
anyone who's running GitLab Enterprise
is probably running an Elasticsearch system connected to it.
And there's open questions about that combination
if you use Elasticsearch with this license change.
And those are the sorts of things where it becomes extremely difficult
to say, we can do this.
It becomes a very uncomfortable
question because Elastic is able to do this because they've become so dominant in this
particular space. They essentially forked away from the Apache multi-vendor approach
for a single vendor, very opinionated variant of Lucene.
And in some ways, because of some sort of like, what's it called?
Precedent setting.
Yeah, yeah, trend setting and that sort of thing.
And this is the negative impact of that, right?
Like, it's very easy for something to turn dominant, and then everyone is screwed.
And people have gotten very comfortable with doing this
because with open source software, when you change the deal,
you have another option out.
With the MongoDB thing, nobody felt that it was worth exercising that option,
so it just kind of rotted and died out.
But with Elasticsearch, because it's so hugely dominant,
AWS basically had no choice.
They had to fork the whole project because they have a product that they have to serve to their customers.
Lots of people relied on it.
And it's going to be painful for everything that was relying on Elasticsearch's proprietary API, because that's what it is.
It's a proprietary solution now, to move to an open platform such as Apache Solar.
an open platform such as Apache Solar. Really honest to God, I really hope what this does is it causes the industry to re-examine their assumptions and start moving towards true
open source solutions like Apache Solar. But I am not confident that that will happen. And in the
meantime, Amazon Web Services has stepped up and they're planning on setting up a proper open
source project with real governance and that sort of thing. And they have customers that are going to continue to require this. And
this is kind of the meta story, isn't it, Drew, is that you have these enterprise type
open source projects and then they get to this massive size and they run into this iceberg,
essentially. Yeah, absolutely. I mean, what we're kind of seeing between them, Redis, MongoDB, and anybody else who's kind of hit this critical mass and realized that another company is just eating their lunch, very open source and moved to kind of half open, half proprietary, something nebulous in the middle.
Will that allow them to survive?
Or will other open source solutions come in and take their place?
Or will they move even further towards being completely proprietary?
I don't know. And I don't know that there's one good answer here, but I think in a lot of ways,
this is going to be a trial balloon for the shape of things to come.
Linode.com slash unplugged. Go there and receive a $100 60-day credit towards your new account.
Linode is the largest independent cloud for developers.
Simplify your infrastructure.
Go check out Linode.
And with that $100 credit, you can make some distance.
It's pretty significant.
They have native SSD storage, 40 gigabit connections, and a new revamped easy-to-use cloud manager.
SSD storage, 40 gigabit connections,
and a new revamped, easy-to-use cloud manager.
Linode has really done a good job here of making it easy to use,
but not too many clicks away
to get to the real power user features.
And Linode costs 30 to 50% less
than major cloud providers like AWS.
You receive a balance of technology and performance
in a package that's really straightforward.
They have 11 data centers worldwide,
so you can get close to your clients or your customer or yourself.
And they have built-in monitoring tools
that give you an idea of what your rig's doing.
That's how I knew, probably timed up the RAM in our matrix server.
It's just by watching my Linode charts.
And it made it really, really simple to do that.
And tons of flexibility in the post-server-already-setup upgrade options.
I was really impressed with that.
I also was able to make an image from one of my disks
and then move that between my systems to make setting up some things really simple.
Also, see if they're hiring.
They often have job openings.
So go to linode.com slash careers,
because if you're listening to this show, you might be a good fit for Linode.
They love Linux, and knowing that you listen to a Linux podcast,
probably going to make you an appealing candidate.
Linode is our cloud hosting provider.
It hosts all of our new infrastructure that we've built for JB 3.0.
Recently set up some PeerTube instances,
and it's like having our own Jupyter Broadcasting YouTube in a box.
I love it, and you should try it out.
Linode.com slash unplug.
You support the show, and you get a $100 60-day credit.
I'm serious.
Isn't that great?
Linode.com slash unplugged.
Moving right along.
In fact, we just stormed in in the middle of a luplug.
So why don't we do a little housekeeping?
And Minimac, what do you think?
Successful
log blog this Sunday?
Very, very, very successful log blog.
I want to thank Justin
that had the idea for our accessibility
talk and also
Daniel Fauré who came there
here and we had a good talk
over an hour and we also
had Sean, another user that contributed a long time
and shared his experiences.
It was a really good talk, and I hope you can listen to it at the end of the month.
Yeah, in the near future, the audio should be available.
We'll try to do an update here in housekeeping.
Also, check out the Jupyter Broadcasting All Shows feed.
Yeah, we got one feed to rule them all.
Things are in the works,
you never know. You don't want to miss something new. So go get our All Shows feed right there
at jupiterbroadcasting.com. Wes Payne, do you have anything to throw in the housekeeping before we go?
It's your last chance for some big moment. Oh, it sounds like there's an upcoming Jellyfin
release we should be aware of. Look at you, you got something. Yeah, that's right. I guess there's
a release candidate out there, eh, Colonel?
Yeah.
So the Jellyfin release candidate 3 is out, and they've made it much easier for people
on RPM distros to get that installed.
They've clarified and restructured their repositories to allow for that.
In addition, they've switched from the standard.NET over to.NET Core, which standardizes the.NET implementation across all the platforms.
That is fantastic.
Some big news.
So if you're interested, maybe go give that a try.
See if you find any bugs and get them reported.
Earlier, I had a chance to sit down with the executive editor of LWN.NET, which has been a fantastic resource for as long as I've been using Linux,
and they're hitting a major milestone. So Jonathan Corbett came on the show,
and we talked about that and a lot more. I want to welcome Jonathan to the show. I think LWN.net
is known by our audience as one of the most trusted news outlets in open source, so it's
a treat to talk to you. Well, thank you. It's a pleasure to be here. And kind of the pretense or excuse to get you on the show was that there's an anniversary coming
up for LWN. So how many years will that make it? That will make it 23 years. We first published
in January of 1998. Congratulations. Wow. And so Jupyter Broadcasting is about 12 years old, and I was kind of going over the history of LWN before the show started.
And I noticed, and I don't really know the backstory much, but I think we have a similar kind of backstory where you were independent for many years, I think, then acquired and then deacquired and now independent again.
Can you tell me the history of that? Yeah, we were independent just for a few years.
We were actually acquired right at the very end of the dot-com boom,
which was an interesting story in its own right, actually.
It was easy to be acquired in those days if you had Linux in your name or your activity anywhere.
But then, of course, the dot-com crash happened and that ended.
And the folks who acquired us, a company called 2Cows,
found that they didn't have a way to make money from us anymore,
if they ever did.
And so they basically just gave it back to us
and let us continue on where we were before.
If I'm right, but please correct me if I'm wrong,
when you came back initially, you came back as advertiser-based,
but then eventually transitioned to member-only after your readers said,
do it, we'll pay.
Yeah, I mean, advertising had been the intended model
sort of since the beginning, ever since we decided we could
maybe try to make a living with this newsletter we created.
And that, of course, also fell to pieces after the dot-com crash.
And it didn't take us all that long after we were newly independent to realize that
we just weren't going to make that work at all.
And we tried donations for a little bit, and that brought in a few thousand
dollars, which isn't really enough to keep a staff of several people going trying to write this thing.
So we actually announced that we were shutting down, at which point some of our readers said,
well, you idiots, why don't you try running a subscription model before you do that,
and we'll subscribe and keep you going. So we made a try at that,
and it has been what has sustained us ever since.
That's remarkable because I think there's something kind of special about the type of
journalism you do. Well, I want to ask you about this because the way LWN bills itself as news
from the source, which is just a brilliant tagline because you are getting it directly from the source, but also you can read source code and get the news.
It feels like what LWN pioneered is, I don't know if it's journalism or if it's a contribution of some form.
What are your thoughts?
You know, we never really thought of it as journalism.
I never thought of it as that. I thought of it as initially we were spending a lot of time trying to keep up with the kernel mailing list and all that because, you know, it was a whole hundred messages a day or something in those days.
And nobody could keep up with that.
And, you know, we were staying on top of it.
We were trying to launch a consulting company and show the world how smart we were.
and show the world how smart we were.
So we figured we could just sort of share what we were learning as we kept up with the world and attract attention
and help the community in that way.
And it's always sort of been a community effort to us.
It's something that we've done from within the community as a part of it
as opposed to coming in from the outside and watching it.
Right. It feels to me like it maybe in a way,
I think I consume it as a form of journalism, but it feels like to me in a way, it's also, it's helping inform a community that
has to make decisions. So it's, it is a contribution in that sense. And the other thing that I think
that really makes it special is you yourself, you yourself contribute to the kernel. I believe
you're the maintainer of documentation, right? The document maintainer. And also, I heard a rumor, maybe some drivers too?
I've done various driver work. I wrote the camera drivers for the one laptop per child systems,
among other things, and various other bits and pieces over the years.
That's kind of special in a way too, to have somebody who can contribute in that way and
participate at events, but
then also communicate it to people who can consume the information and then participate
in the community.
And I know that also means that you've done things in the past, like the kernel report,
and you've brought up concerns about maintainers not really scaling with the number of just
developers that are contributing to Linux now and the amount of contributions.
And you, being a maintainer yourself, I was wondering if you see that,
I mean, since last time I saw you speak to that was probably 2018, I'm wondering if that
situation has improved at all. I think that's hard to say.
It varies depending on where you look within the kernel.
There's an increasing effort among maintainers to delegate maintenance to a
group and to bring in backups and that sort
of thing and to try to spread that load out a little bit. There is also some work going on to
try to separate the maintainer and the reviewer roles, where maintainers really just become the
people who herd the patches and get them upstream, but aren't necessarily the decision makers or the
people who have to actually review all those patches.
And by splitting those responsibilities,
it's hoped that we can bring more people in and spread the work out a bit.
And I think that has worked fairly well in some systems,
subsystems less well in some others.
But things are being done in this regard, and we haven't collapsed yet,
so there's hope there.
That is good to hear.
I would imagine it must be some of the more popular subsystems more easily attract maintainers,
and some of the less popular or just well-known systems probably lack them.
Popularity in some sense, yeah.
It's a bit harder than that. It's more a matter of where people and where sponsoring companies see it as being their problem. So I stepped up for
documentation because it's an area of interest to me, but it's also languished for years because
there's no company out there that is making a living off of kernel documentation.
There's no company that really saw it as being something they needed to support to further their own business goals.
So there are a lot of areas like that in the kernel that kind of languish a bit, some of them being fairly important areas.
A lot of hardware support, for example, is very well maintained because the company
selling that hardware wanted to be.
Sure, that makes sense.
A lot of core kernel areas often tend to hurt
for maintainer effort, even though they're some
of the most important parts of the kernel.
I guess when you put it in that framework,
it totally makes sense to me.
So I wanted to ask you just about development in general.
You have followed this for a very long time.
We have a lot of some of the people that started in the very early days still involved,
but is development shifting for the Linux kernel in any significant way,
or is it still kind of the standard way it's been made over the years?
I saw, I think you predicted that in the near-term future,
someone will be able to submit a patch to the kernel without ever having to touch email?
Well, the way that we have done development, of course, has changed quite a bit from
really the first decade where it was just a matter of sending patches to Linus and hoping that he
did something with them before deleting them from his inbox.
So we have changed quite a bit. And that's continuing. The kernel project can be said
to lag behind a lot of other projects in terms of the tools that it uses
until it gets around to pioneering tools that work on the scale of the kernel project,
where we have over 4,000 developers contributing something on the order of 80,000, 90,000 patches every year.
You can't do that on GitHub, for example.
It won't scale to that
at this point so we don't use tools like that you know we had the same problem with source
code management systems until bitkeeper showed how the source code could be distributed amongst
a whole lot of maintainers and then get made that into free software and truly available to the world.
And then not only did the kernel catch up to other projects using source code management,
but we ended up actually leading the way for a while and bringing out the source code management
system that now everybody else uses as well.
So I think that may well happen again with development models that get away from the
send your patches by email approach.
But there is really nothing else that scales to what we need at this point.
There are people working on ideas, and we'll see what happens.
It's going to be interesting to watch.
But for now, we're still sending patches by email.
Yeah, that definitely will be a fascinating development.
What would you guess is a timeline for something like that?
Do you have any foggy guesses? Well, you know, I did predict that we might see some sort of proof of concept stuff
out there this year. And we've seen some increase in the development of tools around patch submission
and all that now that have already helped quite a bit. But, you know, within the next few years,
I don't see things changing a whole lot, but with luck, we'll see
the tools start to take shape. Yeah. Well, while we're looking ahead, I wouldn't mind shifting
back to LWN a bit. And I'm curious what you see the next couple of
years. Nothing dramatic, but just, you know, the semi-near-term
future for LWN. Do you see anything shifting or anything new coming down the horizon
or thoughts in that regard? You know, to a great extent, we'll keep on doing what we do, I suppose.
And I'm forever trying to bring in more staff to do writing for us. So if there are any listeners
out there who are looking to do our style of writing, please do contact us. And with that, I would like to perhaps expand our content range
and perhaps add more features to the site,
which is kind of languished for a bit and so on.
But in terms of the core of what we do,
which is reporting on the development community
for the development community,
I don't really see that changing much.
I think a lot of people will actually be very glad to hear that.
I hope you guys can continue to publish for a very long time.
I'm sure the audience would be interested in getting in touch with you.
There's probably a few people motivated.
What's the best way for them to do that?
If you go to the LWN.net page, there's a link right there that says write for us.
It talks a bit about how we work and what we're looking for and how to proceed nice and simple i suppose well i i absolutely appreciate jonathan
just all of the work you and the staff have done at lwn over the years i've been a long-time member
long-time reader and i think it's uh it's a it's such a needed resource. And, you know, over the years, since you started,
you've watched blogs take off like crazy,
podcasts and YouTube,
and LWN feels like it stayed true to itself
through all of that.
Were you ever pulled at all to try to get in
on any of these new kind of, you know,
media thing platforms that were going crazy
at a particular time or another?
Oh, people suggest it and we think about it.
And we've occasionally talked about maybe trying to do a podcast or something like that.
But, you know, it's enough work just to do what we're doing now.
And we just haven't felt that we had the bandwidth to try to take that on, too.
You know, if we were to find somebody that we could bring into staff
who wanted to pursue such a thing, we could consider it.
Yeah, I think there is a real needed place too
for really well done written material
that you can trust the source and the publication behind it.
I think since you've started and until where we are now,
it's become more and more of a precious commodity.
So I salute you.
And, of course, if you ever did want to get into podcasting, your friends here at Jupiter Broadcasting would be more than happy to help make that happen.
Okay, that's good to know.
I will definitely keep that in mind.
Well, Jonathan, thanks for coming on the show.
All right, well, thank you very much.
It's been a pleasure.
It was a treat to chat with Jonathan.
LWN.net is a favorite resource of mine,
and I just wanted to help celebrate their upcoming anniversary.
And you can check them out at LWN.net if you haven't read it before.
Go over there.
Give them a read.
I think they have a really cool model where you can subscribe
and get the content right away, or you wait a little bit, like a week,
and then the content is available for free.
Yeah, it's really just a fantastic resource.
And, you know, if you love the nerdy stuff we talk about on this show, it's the next level.
Odear.app, complete website monitoring from multiple locations.
They have broken link detection, mixed content as well, advanced SSL certificate reporting,
and more. So visit odir.app and use promo code LINUX for a $10 discount on any plan.
Don't find out something's down by your users telling you it's down.
Be the first to know when your site is unavailable.
Odir has global uptime checking with servers worldwide
that will report on any problem as soon as it happens.
And they can go deep into your site.
They crawl and index your entire website, and they'll detect a broken link and then intelligently notify you. that will report on any problem as soon as it happens. And they can go deep into your site.
They crawl and index your entire website,
and they'll detect a broken link and then intelligently notify you.
You can also monitor scheduled tasks and cron jobs and find out if they haven't run at their scheduled time.
And Odeer is always monitoring the performance and speed of your website over time.
They detect if something is suddenly slow
or watch if there's been a change in performance over a period of time.
But one of the things that I think really makes Odeer stand out is their API.
You can configure everything about the application through their API.
Everything you see in the dashboard can be controlled with their easy-to-use RESTful API.
And as a bonus, all the changes you make via the API, immediately available in the dashboard.
Odeer is a monitoring solution that embraces automation.
It gives you the tools to build your infrastructure by code.
And its comprehensive API means integrations are simple and straightforward.
There's already a ton you can take advantage of just out of the box.
It's monitoring that's done right.
It's a modern solution, and it has a comprehensive API
with kick-ass documentation.
So right now, head over to odir.app
and start your 10-day,
no-strings-attached trial.
No credit card required.
You can get set up in less than a minute.
And when you do sign up for a plan,
use the promo code LINUX for a $10 discount.
And if they ask, tell them Linux Unplugged sent you.
odir.app.
It's monitoring with a comprehensive API for today's automation.
Ohdeer.app.
I feel like it's time we get into some picks.
You know, we've had some good picks in the past.
We've had some contenders.
But this week, we have something real special, Wes.
This is one that both you and I came across.
We, you know, we follow the back streets of Linux applications and see what everybody's talking
about. And every now and then we stumble across a new contender, one that seems to be growing in
popularity. And this week it's Polybar, which aims to be a beautiful and highly customizable
status bar. I think that gin's kicking in.
Without the need of being a black belt in bash scripting.
Have you seen this there, Drew?
The pPolybar?
It's not like the kind of polybar that lives with multiple other bars
and then they all tell themselves they're okay with it.
It's a status bar for multiple kinds of desktops.
Yes, I've used polybar.
It's not exactly new, though.
I used it years ago.
Hey, now, I didn't say it was new.
I said it's been getting a lot of attention recently.
Fair enough, fair enough.
Yeah, as far as an X11 bar for like i3,
it's my favorite.
It's the go-to.
And if you want something that is like Wayland compatible,
that's very similar to Polybar, I would recommend Waybar.
One question, Drew.
Mm-hmm.
Is Waybar written in Rust?
I don't believe so, no.
Okay.
Move on.
Next pick.
That's good to know, though.
Waybar is good to know.
That's good to know.
It's just that we do have a second pick.
And yes, as you may have guessed, it's another open source project rewritten in Rust,
which we have to follow because these are special.
And it's called Dust.
It's a more intuitive version of DU, and it's written in Rust.
So this one looks pretty special, Wes.
Yeah, it's nice.
You know, I don't know that it's going to replace NC2 for me
because that's just so handy
because I can also delete stuff while I'm viewing.
But it runs really fast
and gives you a really nice little column chart here
of where all your space is going.
It's got a little index tree.
It's got nice command line options,
just how deep you might want to go in your file system,
stuff like that.
And because it's Rust, well, it's just a binary
you can download right off the GitHub releases,
run it on your system, and see where your space is going.
Yeah, I mean, are you tired of having to type TACD, TACA,
or TACH flags when you're launching DU like an animal?
Yeah, remember which one is which.
I can't keep it straight.
That's why I use Dust, the Rust alternative to DU.
While we're talking about things that are epic, I want to say a big thank you to
our Unplugged Core contributors,
unpluggedcore.com, if you'd like to become a member
of the show. Keep the show independent
and help reduce the ad load needed. Let us be
picky and say no thank you.
And as a thank you to you,
you get some perks. Did you know this, Wes?
Did you, I mean, FYI,
Wes, did you know there's two options for our
members? What? Two options?
That sounds like one too many. I know, we should throw them all out.
But no, we like to have them all. You can get
a limited ad version of the show. Nice, tight, well
produced, same full production,
just limited ads. Or
go the absolute opposite route.
Get way more show, extra
run length, the full live stream,
all of our screw-ups, of which
there are plenty, and stuff that never
makes it into the show. And really shouldn't.
For good reason.
You can get all of it. It's like the extra show
that we use our better judgment
and don't release to the public.
We make that available as a feed.
To our contributors, you support us so that way we show you what we really are made of
and then you probably stop supporting us.
Yeah, that's a lot of trust.
What are we doing?
I don't know.
UnpluggedCore.com.
Go get yourself a little bit of that.
Also, don't forget, you can find our sponsor, Cloud Guru, on social media like Twitter,
YouTube, or the Facebooks.
You can get all of them.
It's real easy.
You just go to slashac cloud guru, and you find them.
If you do the Twitter thing, you can follow this show at Linux Unplugged.
The network is at Jupiter Signal.
And the entire Jupiter Broadcasting Network, a fantastic podcast,
can be found at jupiterbroadcasting.com.
I don't think we say that enough.
Yeah, there's one page, all the shows, links to everything, all the places.
Can you believe that?
There's more than just this show?
Jeez, what's the matter with us?
Drew, thank you for making it, man.
It was good having you on the podcast this week.
Yeah, absolutely.
Anytime I can, I try to.
I imagine a far distant future where we're all together hanging out in Denver doing a little pod action.
Could be happening very soon.
But in the meantime, you can find the show generally live on Tuesdays,
with the exception of the occasional Sunday sneaky show.
We do it at 12 p.m. Pacific, 3 p.m. Eastern over at jblive.tv.
Links to everything we talked about today, how to contact us,
the mumble info, the matrix server info,
and even ways to subscribe to this show are available at linuxunplugged.com.
See you next week. Same bad time, same bad station.
So thanks so much for tuning in to this episode of the Unplugged program.
Thank you to our mumble room who takes the extra step to show up and contribute
and make the show even better.
Thank you to our IRC room who chats along and fact-checks us,
fact-check falses us as we go.
Gives us the links we just can't find.
That's right.
And helps make the show notes even better.
There's also just people
watching. We appreciate that. And more than
ever, we appreciate those of you who download
the podcast and share it with friends.
Nothing helps a podcast grow like word of
mouth. So if you think this show might be interesting,
share it with them. Helps the show
a lot. We appreciate that too.
Thanks so much for joining us on this week's episode
of the Unplugged Program. And we'll see you
right back here, not tomorrow, but next Tuesday!
Hey!
Hey!
Hey!
Hey!
Hey!
Hey!
Hey!
Hey!
All right, jbtitles.com.
Let's go vote.
Did anybody have something that didn't make it in the main show that they wanted to pick up in the post show?
Now's the time.
Yeah.
jbtitles.com.
That was amazing.
Should really get a soundboard clip of that for later.
Yeah, record that locally so I can fire that off, would you?
That'd be great.
Hooked on Dust, that's amazing.
Wow.
Eating the License Cake.
Wow, everybody's on fire.
Read-only licenses.
That's good because in my head right now, I have no idea what to call that show.
Yeah, yeah.
When is JB Titles going to get SSL?
Never.
When we rewrite it for Matrix, perhaps?
In Rust.
Yeah.
I'm sorry, what was that?
No.
I'm sorry, I didn't hear that.
No, no, no, no!
No!
No!