Episode: 358
Title: HPR0358: Libre Planet 2009 Part 4
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0358/hpr0358.mp3
Transcribed: 2025-10-07 18:51:37

---

Mm.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
that is, you know, taking the web by storm and I'm the little guy trying to stop that
tide. So the first thing I think that we have to do, as principle, is be pragmatic. We're
doing this now in 2009. We need to really not think about what's going to be the all-singing
all-dancing, perfect network services. We need to use existing technologies, use the structure
of the internet as it exists right now. This doesn't mean that we can't think down the
road to ubiquitous computing systems that are universally addressable and real peer-to-peer
systems, things like that. But I think that we need to build the kind of systems that work
today. And that means that we need to be building around a hot and spoke architecture. This
is, you know, client server architectures. We need to build our system like this. The
fact is that most desktop laptops, personal computers, don't have a universal permanent
address. Because no one using their computer in here has a universal permanent address right
now. Most servers do, which means that they are reachable 24-7 and our client machines,
the personal machines are not. And this is not entirely true, this is not perfectly true,
but it's mostly true. An example that I use, here actually uses the email, probably everybody,
right? Okay, who has their own email server? Okay, so who has their email SMTP delivered
directly to their personal computer? Really? So you have a, wow, I'm impressed, actually.
I think that very, very two people do that. Most of us, if I'm out or pop, we use a hub
and spoke system. So it's pretty unusual that we see direct SMTP delivery. I think it's
possible, but I think that we're really going to see more hub spoke architectures. That's
the way it's really got to be for now. Finally, I think that provide a third principle is that
when we're providing services, we need to use the web. I know that seems kind of strange,
but there are people who are thinking outside that box and I think we need to kind of focus on it.
It works. It's scale. It's rich. It's got a good UI. It's ubiquitous. It's very easy to work
with. Very smart people continue to work on making it better. And it also makes the cost of
adoption about three to four orders of magnitude easier. People just don't have to install as much
software. They have to navigate to a web page. So it's considerably easier for people to use.
Fourth principle that I think is going to be very important is to use a free software license
that supports network services. And principally right now, that's the aferro general public
license, AGPL V3. I use it for Leconica. The key part of this license is that it, excuse me,
keep out of this license. It requires redistribution of source if people make a service available.
And that means that it becomes viral even for users of services. I think that making the software
license easily visible in your software will let it be well-known, put it in the photo of every web
page if you can, really kind of forwards the value of the licensing. It gives people awareness
over their rights. As a fifth principle, I think that it's important to build in licensing,
data licensing, content licensing to your software as early as possible. With Leconica, we built in
licensing for on a site-wide basis from the get-go, from the first launch. I also think it's a good
idea to use a free culture license by default. We use the Creative Commons attribution license 3.0
as the default. When you install our software, unless you fiddle with something, the stuff coming out
is going to be CC by. I think that's great. And I think that's a really good idea to do.
Leaving it up to users as a, you know, all rights reserved is the default and then they have to
choose another license means that, you know, your adoption of that is going to drop down really far.
I think that it's important to let give people choice if they want to change the way from a free
culture license, or if they want to use a different free culture license from the one that you have,
let users or service providers kick those, but use a free culture license by default.
I think an important part of providing a free network service is to use DNS,
use domain names as part of identity, especially using urls if you can.
Examples here is email addresses, xmpp. These are ways that we use, we distribute systems,
we let people be part of a federated network and we use the domain naming system as the names
facing for that. Trying to build something else or something different or something new that
does it differently and have a registry somewhere. Is a lot of work, it's totally unnecessary,
people understand domain names, they will make it work. Open ID, urls is another one here,
and blogs is a great example. People really understand that they own the domain for their blog.
So there's that. Speaking of distributed identity, I think it's important to build in
distribution early. This is something that and providing links between instances very early on.
If you're just software, these are my newly announced principles. If your software has any
social aspect, you should build in support for distributed sociality early on. Distributed
sociality meaning that I'm on one server, you're on a separate server, we can communicate,
we can have a relationship that's expressed on both sides of our servers. I can operate on objects
like images or text or whatever, on your server and vice versa. So if software has
a social aspect, it should be distributed and all software has a social aspect. So all software
should support distributed sociality. Two important technologies here are open ID and
open ID is an authentication, distributed authentication protocol, OAuth is a distributed
authorization protocol. Both are really interesting and really should be the first thing you go
to if you're thinking about distributed sociality. On that note, kind of going to be the way that
things go through this whole talk is like after I just said that, support up in standards. I think
this seems like something very simple that a lot of us understand is important, but it makes it
really easy for people to build free software, compatible free software for your software. So if you
support an open standard for authentication, if you support an open standard for producing data
feeds, if you support open standards for lots of things, that means that other people can use
standards and create cool software and become part of an ecosystem. Another thing that's important
there is being semantic. And the semantic web is this kind of, especially on the web, it's kind of
gotten this reputation for being this egghead idea that nobody really uses. And being a roomful
of eggheads, we probably all think that that's okay. But I think semantic, the semantic web is a huge
democratizing force on the web. It means that we put a lot of smarts that we already know about
already into our data and that means that our software doesn't have to be very smart. Smart
software tends to be proprietary software, patented software, it tends to be protected by trade
secrets. Really smart software is why say Google is so important and why other kinds of search
engines are so good is because they've got really smart software. But that makes it really hard
to build a competitor to Google because you have to have the same kind of smart software.
On the subject of Google is that I think that web software needs to be, if you are building web
software for free network services, you need to really think about how your software looks to
search engines. This sounds kind of sleazy, nobody likes these terms, search engine marketing,
SEO, but they are what gets people to see your software, what gets people to see the content
that's in your software, and it gets more people to use your software. People will use your software
if it will mean that they will get better at Google rankings. They will like that. They will take
that if you hide all your pages behind weird earls or require some kind of login to get things or
you don't let search engine robots find your pages or things like that, that's going to mean that
people won't want to use your software. So make your software SEM savvy that makes people like it,
makes robots like it. There are some really nice tools that you can build site maps, ping servers,
need to, one of the great things about making your websites SEM savvy is that it also means that
other third party tools can access the site better too. Another issue that came up for me
very early with Leconica was that we were going into places where there weren't existing open
standards and weren't existing protocols. So I had to create a protocol for distributed micro
blogging, called open micro blogging 0.1. It's not brilliant, it's very simple, it doesn't cover
the whole problem space but it's enough to get things going. It's enough to get people interested
and involved and kind of establish the framework. What we've actually done with open micro blogging
is I didn't know 0.1 version which was about six months ago when we launched Identica and we're
going to be launching 0.2 version that has had the input of various other micro blogging implementers
which means that we got something out there and then it was enough to make a stake in the ground
and get us moving forward. So I'm really happy about that. Probably the big achievement there is
Google's micro blogging engine Jakub is going to be supporting open micro blogging in its next
version. It's just been released into open source and we're going to be having an open federated
network of Jakub and Leconica instances. So that's going to be really huge. But that's there.
I think another thing that's important and this is something that we really fall down on
with free software for web services is supporting a range of usage. This means that
where we usually do find is like download the software and install it on your server and you'll
be fine. That's great. Well that is only one kind of user. There are other kinds of users.
There are going to be people who want to have a hosted service that is they don't want to download
the software and install it on their servers. They want to run it on your server. We should be
reaching those people. And we also should be reaching people who just want an individual account
on a single instance of the software. So this is one of the things that we're doing with
Identica. We're going to have a hosted service that we're going to launch in April. We also
have a major service which is the Identica service that we use for individuals who want an
individual account. So we're just reaching across that spectrum. That's not something that's easy
to do with other kinds of web software. And that's where I think we really need to do a better job,
whether it's a nonprofit or commercial entity that's providing those services, whether it's
exactly the development group or if it's an associated group, I think bright with Drupal is
a good example there. But making sure that these options are available, finding someone who
does who will provide those services really important. Another thing that I think is important for
network services is building to scale. And when people talk about scaling, they always talk about
this like really big end of the scale. That end of the scale is these are like number of users
at the top and then kind of what kind of installation we're talking about on the bottom. You know,
with like one to ten users, you can have a small installation of most kinds of software on commodity
web hosting. You know, you can just go to GoDaddy and get like they're $2.95 on web hosting. You can
go to, as you get larger, you really have to go to least servers, virtual servers, that kind of thing,
you know, with 100 up to like 10,000 users, you know, which is kind of the medium-sized website.
I think I need to really large installations. These are on servers of people own or else they have
a very big account for these servers, you know, 10 to the fifth up to 10 to the eighth, which is really,
that's about the size of Yahoo, you know, that's the most user biggest user basis that we're talking
about. And we have to build software that goes up and down the scale, right? Most of the installations
will be out of those small installations. But these big ones are going to probably reach the
most users. And I don't know about the middle there. So each one is important. Concentrating on
one part of the scale and ignoring the other parts of the scale, I think is a really big mistake.
And I think that we need to be able to reach everywhere on that scale. One thing that's been
very important for me, one of the things that I've really understood as I build free network
services is the importance of making big data dumps. Give people all the data, make a big tarp
all of everything that you can, all your public data, and make it easily downloadable. I think this
is one of the reasons that Wikipedia is, it seems strange, but it's one of the great things about
Wikipedia is that you can get all of Wikipedia. It's a, it's like a 20 gig download, I think, but what?
That's just like a tarp like that. Really? Yeah. All of it to the wall of history. Yeah, yeah.
So it's huge, it's huge, you know. Images are another two and a half tarp like that.
Okay. But also making a dump available to people that they're on private data. So these are things
that I'm working to build into Leconica. They're not actually there yet, but things that have
proved very important for other services that I've seen. Feds are also hugely important
and something that we have to be important. So feeds should be available to
by default to downstream users. You should, when we build software, we should really put that
into the software is like, you know, putting those feeds out there. And we should also work
hard to find the aggregators who are going to use these feeds for searching, for directories,
for archives, all the things that would use those data, make sure those, those are going out.
When people download and install the software, it should be integrated into a,
an ecology of feed consumption already. I think that new free network services
are really needs to support each other. I think that there are some great free network services
out there already. A lot of stuff in the geospatial, a lot of open street maps, for example.
Geonames is a really cool geolocation, free network service. Search Wikipedia, I think, is probably
getting to be, their data is not entirely free, which is kind of not a good idea, but they do have
a lot of data that's pretty free. And starting to encourage other free network services is
really important. Obviously, identical would go up here too, if I wasn't to humble to put it
actually on that list. But we all move faster if we're encouraging each other and we're using
each other. We also, you know, someone using identical who goes, who does a search for a location
and gets to open street maps is now introduced to a new free network service that they didn't know
about and that they can participate in. And you can also depend on these other free network
services to advance your own functionality. But I also think that it's important to engage with
existing proprietary services. The fact is, today, in the world of free network services, it's like
1989 in the world of free software, right? We've got like EMAX and GDB and that's it, you know?
We just, we don't have a full software stack for free network services. You cannot live your
entire online life with free network services unless you live a very limited online life, right?
If you want to debug and edit stuff in EMAX. So, and just like with the earliest free software,
we have to live in the ecology that exists right now. And if we don't, so you have to install on
the proprietary unices that exist with the early free software. Now we need to engage with
the proprietary services that exist right now. That's where people are. That's the environment we
have right now. And I know that's not always the nicest thing to think about. And I know that
there are probably people in the room who've never had to live in a time where you didn't have an
entirely free free software desktop system. But trust those of us who lived in the year 1999,
it was it was a hard world, but we made it through, you know? And we have to do that right now with
non-free network services. So another thing that's really important for free network
services is making it easy to share source. And it doesn't have to be hard to do this. Again,
building this directly into the into the software is important. Building in source links
have easy ways for users of a service to find the source. And also, if there's a plug-ins,
themes, anything like that that's built into the software, make links to those too. Mediawiki does
this really nicely. And it's one of the things that I think is really great. One thing that is not
easy to do is if the software has actually been modified, but there's no like tarball or anything,
to actually slurp that source out, that's a little trickier. I haven't seen anyone do that yet.
I'm not sure if that's actually even that necessary. One part about being part of a free
networking, free software networking, excuse me, free network services and ecology is providing
remote access. So a remote API's, simulate third-party development, they mean that your software,
your service could be part of match-ups where someone could take, you know, identical,
identical micro-blogging notices and place them on an open-street map to map, nifty, things
like that. It also allows providing your remote API to means that people can use your software from
non-brows or environments like desktop clients, laptop clients, mobile clients. We use a remote API
for identical that we borrowed in Toto from Twitter. So we've used the exact same API that they
have, which means that we have a lot of support from third-party developers, which means that more
people are using our software or service. Additionally, we provide a plug-in system and I think the
most successful web software is really those that provide server-sized plug-ins. They stimulate
contribution. They let people get involved without actually having to touch the core code. They make
it easy to integrate with other services that may not be appropriate to build into the core code,
but you can build them into a plug-in. They also let people take your software and start
integrating into their existing systems. So it's a great way to give people a reason to install
your software. Theaving and skins, I know this may seem strange, but I think it's a hugely
important thing to get adoption of software for free network services. People really like good,
lucky websites and this is a big part of their first sniff of a website is how good it looks,
how rounded are the corners and how fancy is the color theme, right? And all that kind of stuff.
And if it does not look good, they will make a gut response and be out of there in less than a second,
like literally less than a second. The site owners also, people who are providing services
want to provide some kind of branding, put their mark on the site, they want to make it look like
it's theirs. So it's important to support theming skins. Using template engines, I think is
kind of overused, but I think definitely CSS can make things very charming and well done if you've
got very simple HTML output. Another thing that I think that we have a huge advantage on
as people who are developing free network services is being international. The web,
business world, especially in North America, still thinks primarily in English. Actually,
still thinks primarily in terms of the San Francisco Bay area and occasionally thinks outside
there to the rest of California. But the idea that there are another 7 billion people in the world
who might want to use some software kind of stumps a lot of people with Silicon Valley,
which is great because that means we can go in there and provide services to them.
And those people around the world are looking for ways to participate in web culture,
in a social web, and in a web culture that cuts them out linguistically, we can provide the
tools to integrate them back in. Not only that, but there are great translation resources out there.
There are people out there who speak to Lugu or Bulkarian, and all they do is look for free software
projects to contribute translations to. Advocates for their language and they want to see those
translations happen, and they just come out of the woodwork looking for ways to do that. And then
all of a sudden, you know, we've got the Twitter that speaks Ukrainian, and people who in the Ukraine
can either go to Twitter where they have an option to speak in Spanish or in Japanese or English,
or they can go to Identica where they can actually speak in Ukrainian and get UI in Ukrainian.
This is something that in the free software world, we have total advantage on and we need to
capitalize on it. I also think using Wikis for documentation is really good to capitalize on
those translation resources too. Finally, I think this is kind of finally. I might have a
couple more. It's really easy to use network services. It's really easy. People who are used to
using browsers can use these proprietary non-free services really quickly. Signing up for Facebook
is really easy, and we need to make our free network services very, very easy too. We need to make
installation of free software on websites very easy. As easy as we can, we should make setting up
an account on an existing server cheap, at least, or free of possible, free of charge,
and setting up an instance on a hosted service should be really easy too. These are things that
just a matter of like one or two clicks can be the difference between, you know, 10% of people
actually going through and creating account versus like 70%. So this is something that we
really have to concentrate on. Concentrate on that UI and concentrate on the UI both for admins
and for, excuse me, both for service providers and for end users. Here is probably my most
controversial slide, I think, is that I really think that using PHP and minuscule for new
software for, thanks. New software for free network services is really important. I think that
PHP, the LAMP stack is really the, the, the posics of C and posics of free network services
that it's entirely possible to build web software with practically any programming language
under the sun. Just like it was pretty much easy to build software for unix-like systems
in pretty much any, any, a programming language under the sun. However, what really succeeded in
the free software world was C software, stuff written in C. And I think that that is what we're
going to see happen with, with PHP and my SQL, actually what we have seen happen with PHP and
my SQL. The most successful free software project, free software for, for the web is PHP and
my SQL and you really need to think hard if you're going to try to build something in another
programming language that you really want mass adoption of. So, and, and one of the big reasons for
that I, I point out here is that crappy 295, you know, commodity hosting system that people
can install your software, it almost always runs PHP and my SQL, it really rarely runs C side
and Scala and, you know, all that, all that really cool stuff. If you don't agree with this,
if you think that this is wrong, make a change, you know, there are some really cool platforms
coming out that, that mean that people can get that same kind of hosting and, and, and deploy
new free software that's written in other programming languages. And I think that this is,
is something that people need to, to do if they care about programming languages.
For the ways to, for the things that if you're interested in seeing a free network service
ecology develop and, and become the, what's available on the world, feel free to contact me
because I'm really used to, this stuff boosts that, that's my email address, that's my
Identica account, but also we've started this blog and Wiki called Autonomous and Autonomous.us,
and, and that's a good place that we really want to see become a Nexus Point for, for development
of these free network services. And, I think that's it, that's it, come on. So, thanks.
So, I think I have a little more than five minutes, and so I'd love to take some questions from
the audience. You, sir. I'm just wondering about awkward, sort of bottlenecks and choke points
that you see in the larger networking space. Like, what do you solve this problem? What other kinds
of major problems need you to address before anything else? So, I think that we have a lot,
I actually have a, I started a wish list on Autonomous and it's, it's kind of awesome.
For, where, what kind of software that we want to see develop, things like bookmark sharing,
photo sharing, general purpose, social networking, a lot of Facebook, general purpose, news,
systems, all I did. Basically, just go to like, you know, if you go to like any list of the hot
100 websites, you know, just like go down there and say like, okay, let's replace that, let's
get rid of that. Okay, let's replace that. You know, there is a lot of web infrastructure, a lot of
web services that we need to start challenging with free software alternatives. And those are
something that I really think are big. Quick follow up to that is, I'm building some of these,
that's why I'm asking. Good to do that. If I do this, I'm not planning to use PHP, actually,
and I'm just wondering, why do you think that's true? Is it because of the server architecture
and the hosting services that's going to screw me because I'm planning to be radically distributed
and peer-to-peer anyway? So, yeah, yeah. So, I think it's primarily the hosting. I think the fact
that people can get hosting with PHP and MySQL, very cheaply, very easily, means that the adoption
of PHP and MySQL web software is just, you know, probably like an order magnitude to a couple
of order magnitudes compared to other stuff. You know, WordPress versus Blossom, you know, and it's
just like a hundred times more. So, if what you want to do is create something that is a distributed
worldwide challenger to an existing network service, then you need to not go for the niche
audience, you need to go for the mass audience. And the mass audience is PHP and MySQL.
Yeah, another question.
Yeah, I'll, yeah, no, it's you. So, go.
So, I know they're good and easy to do better apps like you're talking about are really attractive
to the really on Rails community and the help platform. So, that's a good way to talk about
using a factory and PHP, I'm saying everybody can summarize all that.
Well, a lot of them are on Unreal and Ruby. Yeah.
It should be, as a movement, as a group, which you have left, I'm trying to promote
that they keep their apps pre-stopper, they can use the ppl and so on.
A lot of times, you don't see a lot of pre-stopper foundations.
Have people with those contents that are more on-chain with this?
Yeah. So, all right. So, I think, you know, when you talk to people who make web services,
they'll be like, God, we love open-source software. It's awesome. You know, we love building
our proprietary services on top of this open-source software. You know, it's so great.
And that's why I think it has happened a lot with Ruby and Ruby on Rails.
It's a great platform. The people who work on that core stuff are great.
I cannot name a popular piece of free software that is based on Ruby on Rails.
Can somebody else? Anybody? I mean, I can't. I can't think of one.
Like, I can't think of a Drupal that's written in Ruby on Rails.
That community is not generating... What's that?
There we go. Or a whip. Yeah, yeah. Right on. The good one. Okay. Cool.
Do you think that's cultural that Ruby does following to do something about the brand-new it?
Because that was guaranteed by the core. The policy needs to be very tough to set stuff.
Yeah. I don't know. I don't know why that's happening. How much is it... How much is it the deployment?
How much is it... The stuff that is getting written is not building the
contributor communities that are necessary to have a healthy free software community.
I'm not sure. I have nothing. I'm definitely not a PHP advocate or bigot.
I just happen to think that it's the easiest platform to build on right now.
And if someone thinks that they can get... If someone writes a really great Facebook replacement
in Ruby on Rails, awesome. You know, great. And if they don't, you know, then we need to think of something else.
Yeah, Bradley. I don't play with my wife often, but I have to play with my wife.
I have to be my scavenger when I don't write that for them. Oh, really?
Yeah, so it's with your fault. The argument she was making was that Twitter has won.
And she kind of had a point, which is why we argued.
And it's why people start working out in Twitter, because I have been pushing my
dynamic statements through Twitter. And what she was arguing, they can realize that it's time for us
of the Twitter group to ask if I do that. So, to what extent do you think we need to refuse to
cooperate? Because you're cooperating with Twitter. They're not cooperating with you.
Yeah. So, to what extent do you think that just refuse to cooperate? That's why I can do what I can
turn off the push group because they won't give us access once we hear the microphone.
Yeah, I think it's a really, I think it's a really interesting question. I'm not sure.
So, when people tell me this and tell me in terms of like, this is why I should quit working
on the conical and identical, because Twitter has won. People are going to be speaking on this
with Twitter. Yeah. Yeah. I think that it's with Twitter in particular. I think that that's
totally premature. Twitter has 5 million users. There are 1.4 billion people on the internet today.
There are another 1 billion people who have mobile phone access, which is one of the key
usage of micro-blogging. And so, that 5 million people is 5 million influential people.
It's a lot of, you know, web people, an awful lot of people in the San Francisco Bay area,
once again, funny how that happens. But it's a, it's not game over yet. You know, it's not game
over anymore than like, blogging was over in 2000 when, when blogger.com launched.
Open software stack on mobile phones?
I think you've achieved long maybe, but in the city, there's not a lot of
that other billion people? Yeah. That billion people that don't have web access?
That's a good question.
Oh, ones that do have a web access, but only on their phones?
Well, for a day, access, which is even worse, right? Because then it's completely
free traffic and mobile. Companies like for key and mobile phones are kind of against the internet.
Right. So, yeah. So, should we have free phones?
Yes. We should have free software phones that are freely, that can freely connect to a free
internet. That's absolutely the case. That, and that is going to be great for free network services,
too. But can we have free network services without having those free phones, or can we work
in tandem on that? Do we have to wait for free phones before we can have free network services?
I don't feel like we have to wait. I think we have to be working on this problem right now.
Back to your question. Should we, should we boycott Twitter? Should we boycott Facebook? Should we boycott
Google? Sorry, dude.
I think that we're, it's a hard time to do that. I think it's a hard time to ask people to do that.
I don't think that saying that I think it's a good time to be raising the issues, you know,
and saying there's a proprietary, your entire sociality, the events that you go to,
your friendships, the people you connect to, your mom, your, your high school buddies,
right. All that information is owned by a proprietary company in Palo Alto, California,
and they can deny you access to it in a second. And you need to think about that. And you
need to think about what your level of control is and what's really important. And if you don't have
that level of control, you need to get a little bit scared. And I think people do get a little bit
scared when like Facebook changed their EULA, and Facebook had to back down, which was great.
I think that if, yeah, yeah, right, right. But I think that activating people in that way is
something that's going to be a little bit more gradual. I just don't feel like we're in a place.
I think we can encourage people to use free network services. I think that telling people you
cannot, yeah, time to go. I think it might not be time to say don't use not free network services
100%. Anyways, thanks everybody. So we have a break now for 15 minutes. And we have some
snacks outside. There is a key signing. That's going to a GPG key signing would be by the registration
table. Basically, on the weekend, they actually said I was going to do a bunch of talk on
reverse engineering, but unless people really want to see lots of boring color-coded hex dumps,
I was really going to do a talk on Ganesh itself in the project.
Can you do more? Try that. No, I'm just talking, oh, test one.
I'll just try and talk really, really loud, I guess. But anyway, yeah, my reverse engineering talk
is unfortunately like an entire afternoon's tutorial. And I thought I'd spare you guys the
boredom of reading hex dumps, although it is kind of fun when you get really into it. So,
anyway, yeah, I'm going to talk about Ganesh, the GNU flash player, which fun enough somebody once
did a vote and said we have the worst name of a GNU project they had ever heard of. I don't know
why, but the rest of us kind of like it. I work for OpenMedia now, which is a nonprofit I found
it several years ago. And we're actually at 501c6, sort of a trade organization based in Colorado,
legal nonprofit. We have a team spread out, I think at last count over about 9 or 10 different
countries working on a lot of our software. And I used to say we raised funds for OpenMedia
related projects, but the last three months it's been more like we attempt to raise funds.
I don't know if anybody here is running a nonprofit, but it's a really bad economy for
sponsorships for free software projects. And we're about to announce a big legal project working
with patents around multimedia codex and stuff that I'll talk about in a little bit as I get into it.
And anybody can ask questions at any time, because this isn't so much as I talk,
is a bunch of slides and you can interrupt me and distract me all you want.
So can we donate to OpenMedia now, like give you money?
Yes. All right. We have to take free beer, misogies, and this up.
I was in New York about three days ago and saw something called FHGML, which translates,
sort of high level HTML directly into clash. I'm wondering if you know those guys,
because it's kind of interesting how there's stuff translated to you instead.
No, but since we interpret Flash, you know, Swift format, we won't care, because when we say it,
it's already down to the Swift. And so I'll talk more about codex later. So right now,
for the last four and a half years, we've been sort of funding and sponsoring several projects.
Kind of one of our goals in OpenMedia, who cares anyway. One of the goals in OpenMedia now is that
we believe really strongly in patent-free multimedia codex. And then the big problem is that there's
not really a complete infrastructure for using things like Vorbiz. So if you wanted to create a
video in FHGML, edit it and put it on your website. You can kind of do it now if you're a geek,
but most normal people, it's pretty daunting. And so one of our goals was to develop the sort of,
you know, creation ends, server-side and client-side for multimedia, you know, web. I'm not going to
use the 2.0 thing because it makes me sick. But so we work a lot on Ganesh, which is our client-side
for displaying Flash, of course, you know, Adobe Plug and Compatible. I just two weeks ago,
released Signal, which is a Adobe Compatible Media Server that also speaks Flash and a couple
of other protocols. And Ming, which is sort of a Flash compiler type of creation environment that,
as of last week, somebody's putting a GUI on. So we're working now on graphical IDEs for Flash
programmers, which should be fun. Primarily, you want to orient it towards educational games.
I figured I'd throw this one up. Everybody goes, how do you wind up working on, you know,
free software projects sometimes? I mean, I remember when I first started on GCC, I needed a
free compiler and couldn't afford to pay $9,000 a seat. So Ganesh's first platform, believe it or
not, was my stereo. One day I got a phone call from an old friend of mine and John Gilmore,
and he had some company that wanted to do a Flash-based user interface. At the time, I hadn't quite
realized this five years ago, but since now, it turns out that the main use of Ganesh is not
on a web browser. It's actually a user interface for set tops and embedded devices that runs in a
raw framework with that X11 that happens to know how to do a video. So anyway, I spent about six
months on this originally. I looked around for existing projects, you know, the next thing about
the sort of free software world is a lot of times we all build on the work of others. And so
sometimes when we're asked to start a new project and don't have a whole lot of time, you really
need to depend and build on the work of others. So I found this one project that was the beginning
of a Flash player, talked to the developer, he had kind of abandoned it, and became a pretty
active developer on it, ported it, and bang, there was the user interface for my stereo system.
There's a nice box, they make these stereo's for high-end houses and stuff. This particular
box has got a 600 gigabyte hard drive with about 2,500 gradeful dead bootlegs I think on it.
It's the gradeful dead box. But it's amazing what people could start it. And when I did this,
I didn't really think about it, and I'll get into it more, but I did a project and wrote a little
Flash player and then forgot about it, and then a while later it kind of came back to me.
Is it? Oh good, and I can talk a little quieter. So basically, some people say like, why Flash?
I mean, one of the problems is that myself and actually nobody on the Ganesh team,
none of us had ever installed the Adobe plugin, because I just don't like binary blobs really.
So one of the funny things we had is like, why Flash? Well, in the earlier days of the internet,
nobody really cared. And even up until the early parts of 2000s and stuff, you could pretty
much navigate the web pretty decently without a Flash plugin. But what we started to see was a lot
of problems. People were starting to use Flash for menus, not instead of image maps. People were
using Flash in a lot of ways that wasn't like video or animation. I mean, Flash is a graphics
programming language. And so what was happening was that basic functionality on some sites,
login pages, menus, all that kind of stuff, were becoming so Flash-based that I'd go to a
website and it'd be a big gray box, you know. That was kind of getting irritating. Then it started
happening more and more and more. Then this crazy thing called YouTube came out and, oh my god,
suddenly Flash has been adopted, you know, worldwide for streaming video applications. Maybe good,
because Silverlight, I hear sucks. And I think for Silverlight, you have to download binary blob
codecs for Microsoft still. So, which is good. And that's one case I hope that us in Adobe
survive the onslaught of Microsoft there. And then the other thing was that Flash is also heavily
used for educational applications and gaming, which I never really thought of until I got involved
at the O L P C project. So in some ways people go, well, you know, what do we care about Flash?
I mean, you know, big deal. It's like, you know, graphics and mostly ads. Like when I first got
Ganesh running as a web browser plugin, I realized that the internet had been taken over by, you know,
basically real estate agent who all use like Flash 5 that runs in anything, you know. And it's like
the whole size of your browser blinking. I'm like, oh, that was in a state. Maybe I should kill this
project now. But the part of the problem was that as time went on, when you don't have a Flash
plugin, you start to become in an inability to navigate the internet. I mean, a lot of us that
aren't in the binary blob start finding that we're left out, you know. And it was kind of a drag to
sort of, you know, just web things pretty cool. You know, Shrekbeats used to net in the old days.
And suddenly it was becoming harder and harder to deal with the internet. So that was kind of
an interesting. I know at one point the FSF had a campaign on don't use Flash. Didn't work
too good, obviously. I mean, everything's worth it. I'm a big believer in the futile gesture. But
we just did not get people to stop adopting Flash. And so at that point, you know, you kind of need
your own Flash player. I don't know if anybody hears into, you know, 64-bit systems. But, yeah, me too.
The Adobe player, I think they just got 64-bit released in Alpha a couple like a month or so ago,
finally. They probably would be reading the Ganesh code. And the other thing is their Linux support
in the Adobe player pretty much sucks from what everybody tells me. Not being actually loud will run it.
I can't tell you. But everybody else tells me that it's bad. It crashes. It hangs firefox.
It does all this crazy stuff. I can see why I haven't worked on Flash for all these years.
And then the other problem, too, is it really? I mean, Adobe Flash really only runs on
little Indian 32-bit Intel machines, basically, which I mean, I don't know about you guys. But I
actually work at a lot of other weird machines, everything from my canyons and MIPS and power PCs
and arms. And I always thought one of the beauties of FreeSoftware is you can make it run on anything
if you just got a little bit of time and motivation. And so, basically, it's like, you know, what can we do
about this problem? So, you know, basically, we just want to talk about sort of network services.
Don't use Flash on your websites. And this is from a guy who writes a flash player. We should
really not be looking for more ways to pervert our websites with Flash because it's just going to
eat your CPU. And when I got a website and their front page is just a gigantic Flash movie at,
you know, 800 by 600. I'll go to another website. Forget that one. Another thing is we encourage
people that do have to, you know, that are actually sort of on the provider end of the business.
If you're working on a website that's got some Flash content, test it with Ganesh. The guys
are daily emotion. Test with Ganesh all the time. And so, everything they do works with Ganesh.
Same thing for YouTube. We work with the YouTube guys. And so, you know, sites that work with us
work a lot better for everybody. I would think another thing is if you encounter a business website,
if you go to this, have you send a letter to the company or send them an email saying,
gee, I'd really love to do business with you, but your website is too flash-heavy. I want
plain text or I want paper graphics that work with anything, not something that requires people to
try to get a plugin. It's funny. We had one of our developers fixed a bunch of bugs in Ganesh
a couple years ago, merely because of his bank adopted Flash-based banking software.
You can use some Vizortrag. I'm just going to make this up. Vizortrag likes switching languages
to say on your browser, I don't want Flash. And at least people could provide
in their site two ways of doing site navigation. I guess, but I'm not a website guy, so.
I also help in the meantime of all people who have finite block trouble,
or maybe we have specifying, I'm not hiding this to Flash. Please give me your alternate version.
Yeah. And I really like the people that say skip this, or alternate menus, site maps are great.
I like a lot of that stuff, but not all website maintainers and designers actually pay attention
even to their user base, much less normal people. And then our solution, of course, to this
whole problem was sometimes when you get really, really frustrated and pissed off, the best thing
is to write code. A lot of code. Fast. Well, we didn't go that fast. So anyway, Ganesh is a
funny little project. As I said, we started in 2004 for a user interface for a stereo system.
And then I forgot about it. I was a consulting at the time. It was a project. Big deal. Did that
project did another one. One day, funny enough, when I was packing to go down the Katrina,
to do relief work for Katrina, I got this phone call from John Gilmore and he goes, you know,
didn't you write a Flash player last year? And I'm like, well, yeah, big deal. And he goes,
we need a free Flash plug in. Here's why. And I got the whole brain dump from John, you know. And
I'm like, interesting. I'll let you know whenever I get back. So five months later, I got back,
and basically called up John and said, yeah, I'm broke. I'll go do that.
He made a very small donation, but it's okay. You know, fed the kids and that was cool. And so I
started, that's basically when we started Ganesh project. And because I had based on another
older open source project, I talked to the maintainer. And he had the classic example. He goes,
please fork my project, which I think was slightly unusual because I don't want to do bug reports.
I got a nice job that I like. Just just change the name and do something else. And so I'm like,
oh, my God, John. He said, this is great, but we need a name. John's like, oh, call it Ganesh.
I'm like, great. I hate picking project names. And then basically, I got launched into
trying, I mean, I'm a compiler debugger guy. So then I got launched into trying to reverse
engineer how you do plugins for Firefox. Boy, that was really fun for guy with out of graphics
background. But eventually, in beating through massive amounts of incredibly out-of-date documentation,
reading source codes, wonderful, actually. I actually got Ganesh running as a Firefox plugin in 2006,
which was pretty cool, I thought, because I wasn't sure I was actually going to get it to work
at one point. And we got it all working. And that was pretty neat. Oh, boy, big mistake. We got
lots of attention. Lots of attention means lots of bug reports. But bug reports are all good,
so it doesn't matter. So that was pretty cool. So at that point, I suddenly had a flash plug
into my browser to watch all the ads. That was great, sort of. So then we decided, you know, we
hadn't really done enough by polluting the Firefox world with making all the flash ads actually
work in their browser. So then we decided to screw up conqueror by giving it flash plug-in support
as well. So now this way, KDE and Genome desktop people can have the full beauty of the internet
advertising at full force. But this is why we all run adblock, right? So anyway, so we got that
running as a sort of K-parts type plugin. So you can kind of plug in Ganesh's widgets and
Genome and KDE and all this weird perverted gunk. Then we got YouTube working. There's a, I think,
a letter. I think it's Peter put it out a couple years ago about, you know, oh, Ganesh needs new
help to get YouTube working. We got it working two weeks later. But that was actually really interesting
because I can't tell you how many bug reports I get. YouTube doesn't work. All because we can't
ship a proprietary codec. But it's pretty funny because when we got YouTube working in Ganesh,
instantly we became Ganesh, the YouTube player. Nobody even talks about flash, swift animations,
educational software. Flash doesn't seem to exist for most people, but YouTube. It's amazing.
And I never actually been to YouTube. I don't even own a television. I went to YouTube and
I'm like, oh my god, what an amazing thing. That's been so much time watching crappy YouTube videos.
It's harder than debugging at Hexthomps, I tell you. So since basically we got the project started,
we became a high priority project to the FSA. It was kind of a pseudo-empty slot. They had GPL
flash up there. But when I announced Ganesh, all the GPL flash people quit their project and
joined the Ganesh team and actually is still the Ganesh team. So we just sort of switched high
priority flash projects because we had a lot. Well, I'd written an Act Better VM than they had,
so it worked out that way. One of the nice things, as I'll mention it, being a talk on high priority
projects is it really does help being on the project list. It's not like you're going to make
you a zillionaire or whatever, but a lot of the developers are motivated to do what they think
is good for the community and they're willing to let the FSA say, hey, we think you should go do
this. It's good for the community. So it's been really helpful to have that support because
having enough developers when you're doing a gigantic project like a flash player,
it's a lot of work. And so I hate to say it. A lot of bodies is actually useful. We don't have a lot
of bodies, but we have more than me, which is really nice. I've started a few other GPL projects
and gotten zero developers and never had posts on the email list. So it's kind of nice to be on a
project. It's actually got a pretty active, you know, kind of vibrant community and stuff.
We're now, I think, we're running on something like 40 or 50 different computer systems now,
almost every GNU Linux and BSD distribution on the planet, ships can hash,
so does open solaris, hikus, syllable, OS2, and a bunch of other weird machines. And then I created
open media now, mostly so people could give us money because it turns out there's this interesting
concept when you actually can help pay your developer something. They work all the time.
And they're wise. Don't scream at them because they're actually helping pay the bills. And some,
I'm a big believer that trying to help fund free software projects is a really good thing.
Is that like, so how many of those distributions that are distributing GNAC are distributing
none of them? Zero. Big problem. I'd get probably several hundred bug reports every week that
YouTube doesn't work all because they haven't loaded a single codec package called ffmpeg.
Drives me crazy, but that's slight. But I'll get into that more too. So I think we've created
open media now, which as I said, was a nonprofit because at one point, we had no way to actually
take money or equipment from everybody. And people that really want to help you but happen to have
these thing called businesses around them have to be able to write, not necessarily write stuff off.
They have to say, we know that to these guys, and here's their website and their PO box,
so we create our own nonprofit mostly just because, I don't know, we just decided to create our
own nonprofit as opposed to running it under somebody else's banner and stuff. And it's been
interesting running a nonprofit, but you know, whatever. And we then basically then been putting
a lot of our time in the continuing to a reverse engineer the Adobe technology. And I don't think
I can use a protocol analysis term for a binary file format though, but so I use reverse engineering
and we don't just assemble executables because that's tacky and cheating anyway, no fun.
That's what I told it. The first time I ever line up to Adobe, they asked me all these weird
questions about, you know, Ganesh and I thought I was basically, you know, taking their player apart.
I'm like, why don't I want to re-implement your crappy flash player code?
I said, VMs of VM, we can do a better job, we're free software, you know, we're free to do what we
want actually. So one of the funny things about Ganesh is as I said, most of the Ganesh usage actually
isn't really so much as a web browser plugin, which is good because I'd be buried in 10,000 YouTube
bugs every day. And I'm actually a long time embedded systems programmer. I've been doing embedded
systems work pretty much since the 70s and I like small devices and I worked at signal support
for most of that whole run. And so I spent a lot of time playing with like weird, funky hardware.
So I like that stuff. It's kind of fun for me. So anyway, I got really into a crazy urge if
you used to go putting Ganesh to anything that would show up in my house. So this was a small
collection of some of the crazy stuff I put in Ganesh to in a couple of week period. The XR
doesn't count in the middle, but there's two shrubs areses in there. Nokia phone, Intel classmate,
Pepperpad. I don't know. It was just kind of fun. OpenMoco ports, Nokia 770 at the time,
Internet tablet, PlayStation 3 port because we run them power, we run 64 bit on power PCs and
big Indian mode. And that was actually pretty fun because I like playing with hardware. And so
and this has actually been mostly people using Ganesh. We have a bunch of companies in Hong Kong and
Taiwan that ship Ganesh is their main media player. There's a whole lot of people in sort of an
r market space. This is more like what we work on. Not the web browser, thank God. Because the web
2.0 is boring. Still using reverse engineering. This will probably be my only reverse engineering
slide unless people want me to launch into my other talk later. Basically, if we're going to
really reverse engineer something, don't do an FFM peg. Do it legally so other people can actually
redistribute it. Or it's not really worth the effort. I'm a big believer in doing it legally.
Talk to the lawyers first. It's a good idea. You know, once you're in trouble, it's like getting
a speeding ticket. You know, it's like you can't do much about it. So it's just better to avoid
trouble by being really careful. And I think I've memorized every legal reverse engineering clause
in the DMCA. Thanks to the EFF and stuff. If you happen to see software with a really crazy
yula, the flash license had a clause that forbid reverse engineering flash players if you
installed their plug-in. If you read their action script specifications or the Adobe documentation
manuals, you are forbidden from working on flash players. They recently removed this requirement
after four years of me bugging them about it, which is pretty amazing. But yeah, if you have a
really weird yula and it has clauses in it, you don't like, don't sign it, don't use the software.
The other big key thing is you have to use publicly available documentation. In the flash world,
this was actually pretty easy because a lot of the documentation was based on ECMO 262, same as
JavaScript. I mean, Adobe uses the Mozilla JavaScript engine for a long time. That's why they
rewrote it and gave it back and called a Tamron. And so we basically used ECMO 262 for our class
library specifications. And then our volunteer community would run test cases with the Adobe player,
tell us how it was supposed to work and we would just go back and forth until we had it exactly
right. And in the beginning, it was very slow that way. But over time, we got to know it all so well
that we haven't even barely even looked at documentation anymore. And then last year, after several
years of us lobbying Adobe, they released all their specifications and dropped their licensing
clause. So I'll give them a little bit of credit there, luckily. The other thing is if you're
actually going to use proprietary software, you have to legally obtain it. So for instance,
some of my reverse engineering, like network protocols, I've had to sniff the network connection.
But hey, I've got older kids who run Adobe Flash so they can like pass their college tests.
I can't make my kids fun at a college, you know. So I can that say, oh, my son's visiting,
gee, I can have him like good to these five URLs where I sniff the network connection and get all
the data that I need. You've got to love having kids. But the whole point is, yeah, I should tell
you another, when my kids first went to college, they're like, dad, you forgot to tell us about
Windows thing. Everybody thinks we're weird. Growing up in a house full of Unix machines.
But anyway, so yeah, if you're going to reverse engineer proprietary software,
get it legally. I'm like, I can't emphasize it. When you do these things legally, you can keep
doing it. If you don't do it legally, people make you stop. Making you stop is also called
court jail and big fines, none of which is good. And then the final part is really funny.
Last week, the top manager, Adobe, actually announced for the first time publicly ever, I've
been bugging about this for a long time, that Ganesh is a legal implementation of open specifications.
I was blown away because now I'm not so worried about being sued anymore. And Silverlight's been
very useful for getting Adobe to be friendly. Ganesh has got a whole bunch of different features
that aren't quite exactly like some of the Adobe ones. One of the big fun things about Ganesh is,
since it was originally written as a user interface, it runs standalone. That's how it was designed.
You know, the plugin was kind of an afterthought. And so most of the people using Ganesh love the fact
that they can run it from the command line, run custom flash movies that's like their advertising
sign or whatever else it is. And so an ability to run standalone unlike Adobe has been very, very
useful to us. And we plug in pretty much any Mozilla-derived browser from Firefox to 105
up to Firefox 3.1, Conqueror and KDE 3.4, Embedded Conqueror, which was a pain,
bunches of other weird browsers. It seemed like every browser these days is actually
implementing NPAPI, even WebKit is. So we've been actually supporting pretty much every browser
around. And lately we've fixed the support so that some of the weird browsers work pretty good,
not weird, I mean, but some of the icecat, ice weasels, all the weird little variations,
install things subtly, subtly differently. So we've been putting a lot of work in the making
sure Ganesh installs and works with all the other browsers. Streaming video, Ganesh supports streaming
video, big deal YouTube, but it's really popular, it turns out. Another big thing about Ganesh that
Adobe never did is we actually have multiple renderers. We support OpenGL, which if you're on a
small cell phone platform, they often have OpenGL along with like a 400 megahertz processor.
And so you actually need to be able to kind of delegate a lot of your processing to the graphics
processor, just so that your little 400 megahertz chip can do full software, you know, what else
it's doing. I mean, it's hard working on slow hardware, so having OpenGL back ends is very useful.
We also support a thing called anti-grain AGG, although I think that's going to go away and be
replaced by another vector library soon, because AGG is kind of the guy got a commercial job and
it's kind of stopped being maintained. And we use that as sort of a 100% pure software rendering
solution for people that don't have OpenGL support. And we support Cairo, but it's really,
really swell. So someday Cairo will catch up and maybe we'll use it more of it. Right now,
it's not very good. We don't want to work with network security. When I first got Ganesh
without working network connection, I discovered that most flash movies install 3, 4, 5,
6 other flash movies from other websites, and because it's being loaded by the flash player,
you never see it. You know, your monitor light goes on. Well, there's network traffic, you know.
So when I got networks working, I was blown away. It turns out that Adobe has hacks in their SDK,
where every time you play the flash movie, it'll register a hit on somebody's website in their
access log, so you can count how many times your movie was played. Lots of little weird stuff like that.
This got me really worried. So one of the nice things we've done in Ganesh is we pay a lot more
attention to security. The Adobe flash player is full of security bugs. It's not this talk, but it's,
I wouldn't use it for banking software. It would scare the crap out of me. But anyway, other people
do. So we've had a lot of attention with privacy, white lists and black lists. If you don't have,
you know, ad block or flash block installed, you can do a black list of sites you don't like, and
you never load flash content from them. It's a great way to get rid of the trackers watching you,
we print out every network connection so you can see what's going on. We save everything that's
loaded the disk as an option if you want so you can see what was going on. We're pretty crazy about
it, but security is really, really important. I think the free software community pays more
attention to security and privacy of individuals and any of these big commercial companies.
And it's important. We're also extensible. Adobe flash has these big class libraries,
which are cold, but if you want to do anything outside the class library, you then have to write
everything and, you know, action script and byte code interpreted. So, Ganesh actually supports writing
wrappers for any development library on your system. So much like Pearl and Python and stuff,
write thin wrappers for every development library on your GNU Linux platform. Ganesh does that too.
So we have things like direct my SQL support, direct raw network support, support for remote
control devices. So when you're using your set top box, you can grab a remote control and it
just works in Ganesh like a mouse. So we're pretty much write wrappers for everything. Debus,
I wrote wrappers once for GTK. So I could program GTK in action script because I don't have the Adobe
SDK. It's kind of fun. You can actually, we turn action script in a general purpose scripting
language. It's got really good graphics support, which is kind of neat. In addition to that,
then we also support a thing called XML messaging, which Adobe's had for a while. For instance,
the stereo that I used, the flash movie because flash runs in a sandbox, you click, you know,
play. It can't really do anything. It can't talk to the hardware, although Ganesh can,
but the Adobe player can't. So what you do is now you pick a body that sends an XML message,
things happen. So the ability to have an XML-based networking scheme lets you do pretty nice
complicated protocols and all sorts of other kind of fancy stuff. And finally, we're really big
fans of patent-free codecs. If you go to internet archive and you have Ganesh, you'll get
the aura instead of MPEG, stuff like that. We're big fans of making the whole sort of patent-free
codec infrastructure actually work. So this is another tough one. Compatibility of Ganesh,
it changes daily, but not heavily. So I'll make the attempt here. Primarily, we're originally
a Flash7 project, but Flash7 is kind of old now. So we actually last year released the original
beginning of a Flash9 support, which is good because YouTube and everybody else is now using
Adobe Flash support and things like that. So we have Flash9 support good, but we don't have all
the class libraries. So that's kind of our next part is the work on that. We've got about 80% of
the up-to-action, up-to-flash9 libraries implemented, but with Flash9, they created a Flash
library, you know, five times the size. It's crazy. But luckily ActionScript 3 is like ActionScript 2.
They completely changed all the binary bindings in the interfaces and gunk. But we figured all that out
and got it working in an experimental branch. And the next Ganesh release all have pretty good
Flash9 support, we believe. I wish I got 10 minutes. I'll start going faster. We're really portable.
We're really in the portability. So I won't bother to read this whole slide, but we run on a lot of
different stuff. That's half the fun because free software should run anywhere you need it to.
And we even run on that Windows thing. A lot of weird operating systems I never heard of. We're
really in the performance because we believe that's one spot where Adobe is completely blown it.
So we support both the X video extension for scaling if your hardware supports it like on the
OOPC. So we can do like full, 19 by 1200 full-screen resolution about 10, 12% CPU load. Let's see
Adobe do that. We use MIT shared memory extension. So your average Flash rendering and stuff
typically is a good 10, 15, 20% lower than the Adobe player on the same hardware. I don't run
Adobe so I can't give you numbers other than the ones people give me. And we're doing a lot of
work now with variations on supporting hardware based audio and video decoding, mostly for the
sort of embedded market. So basically Ganesh is written in C++. I think we're one of the few
GNU projects that is actually in C++ base. The original project I worked on was written in C++,
so I didn't really decide. I just used it, but I like C++ so who cares. We use Boost instead of
Glib for threads and portable data types. A lot of that stuff. We use both GStreamer or FFM
Peg. We're big on internal APIs. We support a lot of weird stuff. And FFM Peg's got better
performance, but most of the distributions build it with GStreamer support. We use lib
curl for networking, although I'm about to replace that. And we support GNU and KDE pretty much natively.
The extensions and stuff like I said, we can write extensions for pretty much any development
library on your computer. It makes Flash an actual decent programming language with lots of
eye candy and removing objects and stuff. I'll throw this one into it. So we're big in the testing.
Among other things, I was the author at the Ganesh Ganesh Regression Testing format. So I'm really
big in the Regression Testing like a maniac. We have something like 35,000 test cases or huge
believers in test cases. We're big in the build bot and things like that. We use a lot of other
tools because there's several now sort of free Flash compilers around. We actually run our test
suites through every other Flash compiler we can find. We maintain Ming, but we use M task and
Hacks and Swift Mill. And Swift Tools, two weeks ago, released an ActionScript 3 compiler,
which is going to be very, very useful to us. You talk about projects helping each other.
They saw we need an ActionScript 3 compiler and they cranked it out in a month. It was wonderful.
We have a pretty good size build farm and stuff because we like to run a lot of machines,
so you got to do it all the time. I'll put in a little blurb for build bot, another GPL project.
If you got a bunch of different machines or supporting a lot of different configurations,
build bot basically builds, you know, one config two hours later builds a different
configuration and just works its way through all the computations until it's done and gives you
little charts that you can check. I really like build bot, although it's a little flaky sometimes,
but mostly works good. So our current focuses right now are improving our Flash9 library
and support. We're doing a lot of work on that. We've reversed engineered the RTMP network
protocols, Adobe uses and the BBC iPlayer uses and it's kind of what all the proprietary companies
like to use. We now have an implementation both client and server side that's about to get released.
We're more in the better performance, like I said, like hardware video acceleration decoding.
And we're actually now working on Flashbased video conferencing applications on topic
and action on our media server. I'll briefly mention this. I just relieved an alpha of
signal like two weeks ago. And signal is a media server that happens to be a clone of the Adobe
media server, which means it speaks Flash. Most of the video conferencing works by actually sending
Flash to the server and executing it like a CGI bin kind of thing in a sandbox and stuff.
And so we're actually working on, you know, the full media server and stuff like that that supports
patent-free codex as well as proprietary ones. It already handles a half dozen different protocols.
Lots of other stuff I'm adding support for actually PHP and Python CGI bins within the media
server so you can do really cool stuff. Like you can send it Python code and execute it in the
server in a sandbox, not having to have it pre-installed, which is kind of a cool feature that Adobe
actually did. And it's really in heavy development and anybody who wants to work on media servers,
I would love to have some more volunteer help because it's been kind of a solo project for me lately.
This one started out of the lab. One of the big things is we did a lot of work on the LPC,
which is what brought along these issues with multimedia codex because we started shipping
exos all over the planet. Everybody said, but YouTube doesn't work because they couldn't ship
the stupid codec, which I think is in another slide here in a second. But that was actually a fun
project to Nicholas Rowan that I think he started it at once, but he basically killed his own
project as far as I can tell. So codex. So Flash right now is his MP3 MP4 Nelly Moser and
Sorenson, FLV, which YouTube uses is just a container format. It's not really a codec. We also
support, you know, Speaks, Varbus, Fiora, and then we're going to be using kelp for our video
conferencing support instead of Nelly Moser. And then the big thing is that we had an
inability to redistribute Ganesh on anybody's machines. And so I just literally a few days ago
created a new website with John Gilmer called codecpatents.org. And we're actually launching a
campaign to do legal, clean room implementations for proprietary codex. I think it's got to happen.
So anybody who's got a little time, what we'd like to do is, well, one thing we could do some
system in help on codecpatents.org, but there's a lot of research that needs to be done by the
community for prior art. We saw how powerful Groclaw was and we wanted to do the same thing with
multimedia codex because as you get into the patents, they're bogus. A lot of them. Nobody's just
ever bothered to do anything about it because they're scared to death. It's a little more complicated
than that. Oh, great. More than a little more complicated. But people just,
oh, I don't cost you $600 million. I'm like, yeah, we might as well get started now.
As Jeremy said, we're a non-profit. What are we going to do? Get sued.
They can have my old Toyota truck, you know? So when people ask how they can help,
the Ganesh project is interesting. We actually have a lot of non-engineers on the Ganesh project.
It's one of the fun things of doing free software is the community of active people that are doing
documentation translations. We're really big in translating and supporting multiple languages
because it's important and stuff like that. So we're really big in the translation. So if you speak
a language that we're not supporting right now, please send us a translation for Ganesh,
that way all the error messages show up and you can actually read them. We do a lot of testing
and feedback from people because they run the Adobe Player and we can't. And so without our volunteers
running the Adobe Player saying, oh, and this with Ganesh, I had a pink border, but with Adobe,
I had a red border. We go, oh, thank you, you know? And so without people testing us with the Adobe
Player compatibility, we would not be making much progress. This is where volunteers are so wonderful.
Good bug reports. They do a lot with us. We can't run the Adobe Player. So they say, well, the Adobe
does this, Ganesh does this. Good bug reports are really useful, even if you get thousands of them
other than the YouTube one. For help, please make a better project and we want a better project
and more stable and all that. Documentation writing and updating. I wrote a user manual,
a tutorial on a reference manual. Nobody's ever touched its sense. I think it needs to be updated.
Do you run your, do you run test that compare the equivalent of NAC and Adobe Grand Flap?
Well, we can't exactly.
What makes you want me to run a build bot that runs by?
Well, the problem though is we can talk about this later, but it's really hard to test a graphical
application. And so most of our tests are much more unit level and integration level than they
are actually at the top level because, you know, to x11, Flash is just a big bit now. It can't tell
where there's a button. It can't tell anything. And I've been doing some work on trying to work
around this problem, but don't have a good solution yet. But, so volunteers running Adobe
Player by hand is our automation and they're very useful to us.
So I was going to say, I believe one of the problems is that the development license on the player
could just be as a surrograsse of what we will know if we have run it personally.
That could be.
Yeah, if he's never seen it.
I don't know, you're done.
When I have a client, I think you're great, it's definitely us.
So.
And then of course, anybody who plays with build bot, I'm really sick of being our build bot
build farm maintainer, so I'm dying for a volunteer. I'm just sick of it. I just did
the release, which was like, you know, three weeks of build farm hacking. And basically,
here's a bunch of different resources URLs for getting more information on Gnash, of course.
Gnashdev.org is our big developer site where much of the technical detail is.
Get Gnash.org, our build farm hanks out, devs, rpms, binary, tarballs,
and source snapshots every night, if it works. OpenMediaNow.org is our nonprofit.
If you want to give us 10 or 15 cents or a free six pack or something.
And of course, the pound Gnash channel on free note is a pretty much a great spot for
kind of front end technical support.
So anybody got more questions?
Well, Adobe's ad feature to the official platform pretty rapidly.
I wouldn't put it that way, but yeah.
We're definitely catching up because most of their features are actually not truly
re-implementations or format changes. They're often stuff that we actually already implemented.
They added a high quality video support for YouTube. We had had it for a year already.
We couldn't figure out what the big deal was. So who's chasing who?
Somebody just suggested a sound by on the IRC.
Flashgate done till Gnash walled run.
I was just going to suggest something. I'm sure some of the truth is you already thought of this,
but if you use part of the thing from the closing codex project or some of the other projects,
you can take a small amount and fire a few professional search engine optimization people
to try to make Gnash come up just as often as a flash in a lot of people's Google searches.
Because this is really fabulous.
I've known about it for a long time. I wasn't paying attention to it.
I mean, the biggest problem is that the URLs for Flash Content and almost every web page on the
planet have the macro media and Adobe URL embedded in it as an attribute. And unfortunately,
there's millions and millions of those and that's it.
What I really want to see is have icecat look for www.macramedia.com.
And instead of going to their plugin page, send you to get Gnash to get it. Gnash XPI for $1000.
That should be possible with icecat, I would help.
What do you know if I thought to play in that? Because that numerically, for a lot of sites,
it's a free software project. We can all do with it what we want. We take contributions.
Thank you very much.
Thank you for listening to Hack or Public Radio. HPR is sponsored by tarot.net.
So head on over to CARO.nc for all of our team.