Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/49 Thanks!
Hello.
Well, you probably all know
opened over your tears, and NBT
is one of the main developers
of Felix
Fitow and
is here. He's here to tell you about the
last 10 years of open WRP.
Yes, thank you.
So the opening of the art project was
started a bit over
10 years ago, and
I'd like to take this opportunity to
reflect back on where
the whole project came from and
how much it has changed and evolved over
time based on the progress that we've
made.
So first, I'd like to tell you a bit
about what happened in the early
days, as many of you
know, and as the name still implies,
it started out pretty much as a
framework for the old 50
fauji.
The effort to create this foamer
started when basically
it was discovered that this this
device we're using, a Broadcom
chip was using Linux
as its base operating system.
And initially it was a pretty huge
violation because lynxes didn't
bother to release any source code for the
device. But that, of course, didn't stop
interested people from
from trying to hack it, from looking into
the inner workings of the firmware,
discovering the limitations of it, and
then starting to create a replacement
for that firmware.
And this was done in the early days based
on the U.S. Lipsy, Bill Drut, which
was a pretty small and flexible
environment to quickly bring up
code for for a new target
and used Lipsey have the advantage
of being much smaller than G c,
which I think the initial device used.
So it started out by
basically taking the links is
terrible once it was released,
which only happened because many
people, many of which included
were member of the Linux kernel
community, actively fought
for the source code being released.
And there was a lot of compliance
engineering involved in that effort
as well. And some pretty prominent kernel
people also took part in
that. And back then,
I think embedded Linux was still
it was somewhat popular
in some areas, but it wasn't really
all that widespread on Voudrais.
Yet back then there was still the
PVCs works operating system as an
alternative, which had no GPL
requirements and was
much smaller than Linux, but also much
less flexible.
So when Open WRP started
out with the lynxes, terrible it
was, it still resembles a
lot of the structure of of the
lynxes system when running on the system,
even though it was much more minimalistic
than the original firmware, because they
always had the intention of creating
something new from scratch.
So the first step, of course,
one onesta, the code was running
based on the build route and the lynxes
terrible was reworking it to
get rid of this terrible dependency which
weighed in a few hundred megabytes,
I think, or maybe one hundred and fifty.
So the first step was to to get
rid of that and basically only pull in
the required parts, which were much, much
smaller than the entire Tarbell.
And then the the focus
on the initial effort was also to update
the Linux two point four kernel.
This was in 2003 and 2004,
long before we had a working two point
six kernel.
So when when I got
involved in the project, I basically
started with the first
of our several built system rewrites.
I put a lot of effort into creating
something where you could you could
package software for the system with
minimal effort.
And this then also
led to our first actual release
that we did.
We came up with the idea of naming
our releases after vodka based cocktails,
and our first release was called White
Russian.
And the version number is also
interesting because back then we still
believed in at some point eventually
coming up with a 1.0 release
and we felt that we
were getting pretty close to it.
So we called it zero point nine.
And with that release done, we again had
time to to come up with
more interesting developments to work on
that. And actually after the white
Russian release, we made lots of big
changes.
We shifted away from the Broadcom
platform, which the Lanxess device
was based on in the
wide Russian release. We had actually
supported many devices running on the
same platform, but it was still very
much based on the code of the Broadcom
SDK.
So we decided it's going to be
multiplatform and we rewrote
the built system again.
And I was again part of that effort
and we made major changes
to ensure that it's not platform
specific, it's not device specific.
And we're able to to create more features
and more different platforms
to support.
And we actually also came up
with our own configuration system
because the old system was still
still very much inherited.
Parts of the SDK structure,
which includes
the infamous and VRM support,
which is basically just a key value
store dumped into one partition,
which has some device specific
works, is rather limited in
configuration.
And we didn't feel like bringing
that legacy baggage to other
platforms as well.
So we created our own configuration
system and we decided pretty
much from the beginning that we want to
have all configuration handled through
a single system, at least for everything
that's relevant on the system.
Instead of going the traditional Linux
way of just having everything being
configured in its own config file format
and trying to come up with various clever
hacks of automated modifications
to those, we use our own
central configuration storage, which was
designed to fit basically 90
percent of the requirements of a system,
but not to not make
it too complex or complicated.
So we never tried to really put
a cover everything with the single code
because this would have added too much
complexity for the whole system.
And actually, complexity is one of our
main enemies these days.
So I think this trade off was a good
choice.
And with the transition from
from the old white Russian code base and
away from the traditional and VRM
configuration interface, we also
had to basically rewrite our web
interface from scratch.
So it was it was lucky
that some people from the FREEPHONE
project who also needed a new Web
interface for this new code base, decided
to create something that not only fit
their needs, but decided to
to wear it, put it, make it a part
of the open system
as well.
So given the scope of these changes
and how much we did in the short time,
we decided, well, actually we decided
before many of the changes were made,
we decided to call the system kamikaze
because I think this is a fitting name,
given how radically the project changed
during that time.
And again, here you see,
it has a nice recipe and it's
easy to mix and you can have
fun with a cocktail as well as the
system.
But then after Cannes, because
it was released and actually we did
several releases with that name because
at that point in time we didn't have
the time to come up with with a
more fitting names for the individual
releases, because we were so busy hacking
on incremental changes, we decided
that it's time to focus some more on
stabilization.
Of course, at the same time, we also had
the usual churn of adding more targets,
more packages and updated our
compiler.
But the radical
aspects of the changes that we made
is in some ways actually backfired
on us.
So we also, again, had
a very fitting release code name.
And then after we did
the backfire release,
it was again time to to
change or revisit
some of the design decisions that we
made, for instance, Linux, two point
four support that we still had because
we needed the Broadcom wireless drivers.
It was getting stale and it was getting
really annoying and maintaining a system.
I mean, we had at that
time, we had many targets running
Linux, two point six, and we had one
single target, the Broadcom target,
still running Linux, two point four.
And in the meantime, actually, a lot of
development happened on replacing
that binary driver with the open
source. Be forty three driver.
It's still not at the point where it can
replace the binary drivers.
But in the meantime, we also managed to
get a binary driver as a replacement
up and running on the Linux two point six
target, though that one's
not updated as frequently.
So we decided
since since we're going to do some more
changes again.
We this time focused
mostly on the userspace rework
because we still had a system that was
running a lot of code
and much, much of it was
getting very slow and hard to maintain
because it's easy to to create
some simple scripts with Chele.
But once you start making a bigger system
with lots of configuration options,
it gets cumbersome, especially if you
have all these side effects of things
that need to be restarted.
If the configuration changes or
the network setup especially was
getting very complex because we
started supporting many
different configuration types with
complex typologies of bridges,
villans routing setups, we had
complex firewall things and it
was just too cumbersome to keep all that
as shell scripts.
And we also then started
working on IPV six because
it's the protocol of the future and
may well be for some time.
And this is, again, reflected
nicely in the release name, because
a lot of our attitudes of how we did
things previously changed with that
release and much of the userspace
we work, we have the the initial
versions of that in the attitude
adjustment release, but we're only
now bringing it to full potential
with a development that's going on right
now.
So I'd like to take
a short some short time to introduce
some of the components that we we've
built for the embedded system, which
deviate a lot from what you find on
a traditional Linux distribution.
We have our system.
Our service is called Juba's
with the name based on on DBAs.
But unlike DBAs, it's small.
I think with DBAs, the library
itself weighs in way over one
hundred and fifty kilobytes or something
like that. And you need lots of other
things to get it running as well.
And we wanted to have something that's
pretty much equally high level but
more flexible for our requirements for
the embedded systems.
And we now have something where I think
the system service itself is about
20 kilobytes as a compiled binary
and the library is maybe 13 or 15
kilobytes.
And it's still very high level
and in some ways even more high level
than than DBAs.
A while ago, I discovered
in the DBAs manual where it describes
the capital of the system.
If if you need to use this,
you're signing up for some pain.
And that's what the official
documentation says.
So that wasn't really what we were all
interested in.
So we brought a second component to
replace the the old network
scripts that we had.
We now have a system deman that
sets up the whole thing that
we supported with the earlier scripts,
with the bridges and villans and
interfaces with multiple addresses and
all that stuff.
And now we have one CD-ROM
that handles all that.
And unlike the Shell scripts, it can
handle things where you just make a
change to the configuration and tell it
to reload. And it will do the minimum
amount of work necessary to bring up the
new configuration without making
it too hard on the implementor to
to handle that with every single protocol
that we support.
Because we sometimes also
have some complex configuration with with
Tunnell's for IPV six and we
have PBP and we have interfaces
that come and go and all that.
And this needs to be handled in a way
where you just change the configuration
and have the back and handle all these
changes.
So this is the piece of software that
does all that.
And then another thing that we
reimplemented was
we have our own kind of
systemd, but again, much, much
smaller and much more tailored to to
the embedded use case.
It's called Trachte.
And it basically, aside from being
PIDE one and handling the tasks
related to that, the only thing that
it really does is it keeps
track of the processes that were started
by its scripts and make sure
that they are restarted when they
need to be.
And if the configuration changed
and the init script is run again and this
process monitoring demand can decide
whether to to actually
restart the demon or if maybe
nothing changed on the system and it can
just leave the existing instance running.
And this fits into a pattern that
we now keep repeating in many
of the things that we do, which is that
we merged the code path for loading
the configuration and for reloading.
It becomes a big problem with many
of the existing pieces
of software that we found.
As if they have support for reloading
the configuration, it's usually only
added as an afterthought.
And it means that this code
path is usually not as well tested
as other code parts.
And if somebody adds new features,
it's so easy to forget to add them to the
reload path after adding it to the load
path. This is something that we're
basically avoiding by design to to
make sure that if if people add
something and we do have many people in
the community that know scripting fairly
well and that can tweak existing source
codes, they don't always have a good
overview of how the entire system is
built. And we want to make sure that if
such people come and add features,
they should do it in a way that if they
tested and it works, that
other things, more complex things like
configuration, reload, are handled well,
are handled properly as well.
So they don't have to worry about
too many side effects of the changes that
I make.
And we we are also
working on configuration validation
in the back end, because with
the traditional firmware that we had,
we had one web interface that supported
automated updates to configuration,
and it usually did all the work of
keeping track of what needs to be
restarted or what needs to be done to
apply the configuration by itself,
which is way too complex.
If we if you want to have managed
networks where you have a central piece
of software that has a database of the
configuration of all the devices
and you want to support something like
that to or you have things
like a TR sixty nine client which
is used by ISPs to automatically
configure the routers, want to make sure
that pieces of software like this
don't really have to worry about the
intricacies of what needs to be done
after the configuration changed.
So we're doing that all in a single place
and that just makes it easier for
everybody to deal with.
And actually, the Web interface itself
also is also seeing some very big changes
right now because with
the bus service, you can you
can basically add and a new API
to any piece of software in 10
minutes with or if
it's implemented in C with very little
effort. And you can use that that
API from anything running on the system.
So it makes sense to decide that
you may want to have things running
in the browser that talk to components
on the system.
And it's always annoying if whenever you
want to do something like that, you have
to create a new API.
You have to create, for instance, the CGI
script to to do the
actual talking with the system servers.
So we decided we can give
the browser direct access to things
behind you. But running on the system,
of course, there's security concerns for
that as well. But we decided we can
handle all that simply by white listing.
The Web browser can connect, can get
a token and the router
side can decide, OK, this browser may
talk to these and these and these things
running on the system and nothing
else.
And this just cuts down
the number of unnecessary abstraction
layers that you need in order to get code
running. So that just makes
the code smaller, more high level
and easier to use as well, which I think
is a pretty good tradeoff.
So we also focused a lot on
our IPV six integration efforts,
we initially had things like
our DVD running on the system,
which is used by normal Linux
distributions, and we had some
other components from regular Linux
distributions as well.
But we noticed that not only are these
things very big, they're often
not very standard compliant as well,
at least in the corner cases.
And they're really hard to integrate with
the rest of the system because all these
components are typically designed to have
their own kind of APIs, their
own config files.
And there's not not much thought
put into making these things integrate
well with another system that may
have a slightly different design.
So we basically wrote new implementations
from scratch. We are have our own
DHC six and advertisement
client. We decided to to
handle all that in USERSPACE instead of
letting the kernel code do its thing,
just to make sure that we can track all
the prefixes that we get.
We can we can make sure that the kernel
does not do weird things that mess up
the routing tables, which we also manage
in a central piece of software.
And we want to make sure that if you if
you connect a router and you want to run
it as a regular IPV six order
and you get a prefix, then that prefix
is automatically redistributed
to other parts of the network if you
want to. And if you specify that in the
configuration so you don't have to
know in advance too much about
what the setup is going to be, you can
just say, OK, if I'm getting a prefix and
just redistributed to LAN or
you have multiple networks
on different interfaces and you just want
to set up some routing between them.
These are things that with the typical
Linux distribution, it's it's always
a bit of a hassle.
You first have to figure out what what
config files to use and what services
to run. And we want to make sure that
most of these things are really handled
well by default.
And we also handled the whole
CPV sex aspect as a as a server,
we didn't find any good
CPV six servers that fit into the space
constraints of a typical router
because we still run on devices that have
four megabytes of flash and thirty
two megabytes of RAM.
And if we have to waste something
like four hundred five hundred kilobytes
just for a simple HP six server,
maybe just because it needs a particular
SSL library, then that's really a waste
of precious space.
And the more code you have, the harder it
gets to review all of this.
So with the security implications
of these pieces of software, it's good
to have less code to make sure that
people can actually be validated at some
point.
And as I mentioned earlier, we're
also working on a new kind
of Web interface where
we previously had
our Web interface written in Lua
and we had some very complex templating
set up. So the router site was
actually generating HTML code
on the fly with normal forms
and things like that.
So pretty much Web 1.0
stuff.
So we decided we want to migrate this
incrementally with access
to to much of the system
through the Hubert's API,
through adjacent IPCA, that we can
actually put a lot of the complex
logic that typically comprises
the user interface completely on the
client side and get the nice additional
benefit of allowing people
with no experience with embedded devices
to come up with their own eyes
simply by eventually
creating a documented, limited
set of APIs that you can use to
do pretty much everything interesting
with the router.
And then you have some normal Web
developers that can just look at this API
and be mostly familiar with it.
Because, Jason, our PC
is fairly common in
some areas of Web development
and they can create all this by
themselves because if you look at the
landscape of available developers,
there aren't that many that no
embedded systems.
Well, and no web development well
and still want to do web development
in.
So the way that we set up the system,
it makes things actually much
faster because there is a lot of work
involved in templating HTML
and even the mobile devices
are getting much faster with JavaScript
engines. So we might as well just use
all that processing power to create
better looking and better working guys
and add more modularity to all of this
and just free up resources on the router
side where because the space constraints
are still pretty tough in some places.
And again, we came up with a
fitting name, I think, for
the next release that we're working
on, because I think in many
in many areas we're breaking new ground
in terms of what a
what a typical router
design looks like.
And we're breaking a lot of barriers
of existing limitations of what
the routers do and freeing
ourselves from much of the structure of
of the legacy devices where
we already, I think, did a pretty good
job of getting rid of existing
structures and existing design patterns.
But it's time to to come up with
our own coherent set of software.
So I think the the release
name reflects that nicely.
And of course, with all of these names
there, they were legitimate cocktails and
you can enjoy them as well once you're
done with your other work.
So in the third part of the talk,
I'd like to talk a bit more about
what affects the open art
project had on the rest of the industry
or how the rest of the industry
influenced the way that we work
as well.
When the art 50 Fauji
was still somewhat popular, but it
was already losing in popularity compared
to other devices, especially with
a focus shift away from the Broadcom
platforms.
We actually had some some talks with
some representatives of lynxes.
I think they decided to send us some
marketing people and they basically
asked us the question like, why
is our product popular?
They noticed that there was a lot of
popularity attached to the 50 Forgy,
but they did not understand
where it came from.
And they desperately wanted to build
on that success and create another
product just like it that had had
the same success.
But the talks broke down pretty
quickly because they said they didn't
understand. That's actually that's
actually a diverse set of communities
that do different things with these
devices and that the
the whole open source aspect is very
important as well.
And then they
they eventually came up with a device
that they called the
successor of the 50 40.
Well, not officially, but they told us
that this is the product that they came
up with based on the input that they
got. And we
were pretty let down, pretty much
let down by it, because when
when they initially released it, it was
full of proprietary code for which we
had no replacement at that point in time.
And they didn't do much
in terms of efforts for opening
up that code.
And so it took quite a while
to for for the community to
slightly adopt this device.
But progress was too slow for it to
to gain much popularity.
And in addition to that, they used
some chips that were rather quirky
and that didn't help adoption either.
So since those talks, we've
also seen some some strange adoption
of open heart by a few Odoms.
They basically took the system and
we only figured this out by looking into
tarballs of of routers
and looking at where they came from
and what company is mentioned in
the actual source code, because the
router manufacturers typically don't
develop the pieces of hardware
themselves. They just tell the
requirements that they have to odoms
and give them some ideas of what the
branding is going to look like.
Give them some some nice graphics and
some nice design rules,
but don't do the actual development
themselves. So it's up to the Odoms
to to create the working products.
And as we can see in
all sorts releases, they really don't
have a lot of experience with that.
And so we've seen some Odoms
adopt open.
But instead of reusing the components
that we made, they actually took
most of the the
properly working and stable parts
and decided for some reason to replace
those parts.
And some of the other parts
that they kept were actually the ones
that we consider to be more fragile.
So in the end, they try to recreate
their own system, but use
it only as a built system.
And the the product
or the resulting product looked really
horrible in terms of code structure.
And it really shined through that.
They did not understand what they
were working with, but they also had no
intention of contacting us or building
a working relationship with us because we
could have told them many things that
would have saved them a lot of trouble
and re re implementing the code.
But they they decided not talking
is better because they always it was want
to build their own competitive advantages
and which in the usually
in the end end up being disadvantages.
So we decided at some point we need
to go higher up the food chain because
Odoms, they don't understand the
technology well and in many cases
they have to rely on the software
that they get from the chip manufacturers
because otherwise they're going to have a
lot of trouble getting support for
the things that they built.
And if the chip manufacturers
luckily are so much fewer than the ODM.
So if we can get our software injected
there, it easily trickles
down to the rest of the market.
So we actually had or have
some working relationships with a few of
them which have
other or other
kinds of difficulties, depending on which
vendor, if you're talking about.
So we had some some
work done in collaboration with Qualcomm.
Atheros Lanting also
decided that they want to abandon
their own SDK and use OpenTable instead.
And we're also now starting to
get a bit more contact with mediatheque
involving.
So I want to talk a bit about what
the issues are in collaboration with
those chip vendors.
I think one of the most obvious one ones
is a complete difference in motivation,
given that we've been doing this for a
few years and we decide we
want to continue this for a while longer.
One of our main focus is code quality
and long term health of the project.
I think this is a large part of
what made the project itself successful.
But this is something that you see
isn't going on very much inside
big companies.
One thing I see over and over
again is there's always a very, very
strong focus on getting
the next product out as fast as possible
and making it as cheap as possible.
So cost reduction and time to market
are the primary concern.
And it's very hard to to actually go
to a company and tell them we have
this thing and we we're focused on code
quality. And this is going to make your
long term business very successful
if all they're focused on right now is
just barely getting the next product out
the door and then try to figure
out another plan for the future.
But the main issue with their approach is
if they get the product out the door,
then they immediately after get the
pressure to get the next product out the
door. So there's never any time left
to really focus on the long term overall
health.
And another another
very big issue with these companies is
there's always a lot of red tape and
bureaucracy going on.
The bigger the company, the more of
it we get.
And it's always very hard
to convince them to do things in a
particular way when they have lots
of reasons to to not do
what we're saying, which they call
company policy.
So this this pretty much fits in
with another big aspect here, which is
the licensing and the intellectual
property issues, in
many cases they they
want to have their competitive advantages
and they realize that
hardware isn't isn't the only thing
that can differentiate them so themselves
on the market.
And they
they cannot always rely on
price to or
on competing on price to
get their product sold, because
then they reduce their profit a lot as
well. So they decided if we're going
to do this hardware, then we might as
well just create some software advantages
that will make sure that they only buy
our product and not our competitors.
There's only one problem with that.
They aren't particularly good at creating
software for their their hardware.
And so this is also a big reason
why they eventually decided to
to talk to us because
they realized that actually
Odoms were bypassing
their case and building
something based on open warranty,
even with the limitations attached, that
they have more trouble getting support.
So if their customers are doing things
like that, there must be a pretty good
reason for them to do it.
And they I think they they often
still don't understand the
full scope of what's going on there.
And a large part of this is,
at least with some of the vendors that
I've talked to, there are engineering
resources and projects are
controlled by marketing and
they have the least understanding of
what's going on on the technology side.
But even aside from that, there's also
development process issues inside the
companies you have marketing
that that allocates resources for various
short term projects, but then
they can't even get
comparatively simple things right,
like branching
in one of the companies that
did some some consulting work with.
I noticed that they were doing all
of their development in either and
release branches or in customer branches.
And then sometimes when they had a
bit of time, they occasionally merged
chunks of it to the main branch.
But it meant that the main branch was
never actually usable for anybody,
and the merged conflicts kept
getting bigger and bigger.
So often they did mergers
between individual release branches and
mergers between individual customer
branches.
And there was nobody actually
keeping track of a
mainline development branch.
And to make sure that features
that are added once and in one branch
actually kept in multiple branches
means the people usually had
to do the same work twice
or even more times.
And nobody was really paying attention
anywhere where this code goes.
And in some cases, we've even seen that,
that they made multiple mainline
branches based on different business
units where I think 90 percent of
the code was the same.
But for some business units, they decided
that they want to have a different
directory layout.
So they move files around and change
the file names.
And whenever they had to do mergers,
they always had to manually mangle
the changes to between the
different branches to make sure that
the layout somehow fits.
And I don't I
don't know why they did all this effort
with pretty much no gain at
all. And this was one of the companies
that only have dysfunctional mainline
branches. So all of the development was
going on inside the customer branches,
but they still needed multiple mainline
branches that never really worked.
But even aside from the chipset
manufacturers, there's also other
interesting related project
activity going on.
One of the most important ones is
obviously upstream integration of our
patches.
We have several people working
or working on their their target
support and the for a particular
system on CHIP.
And most of the targets that we're
working on are actually not
Linux upstream integrated yet.
So it makes sense for the same people
that do the development inside the open
project to also add mainlines
support to these targets.
And we we also tend to do
the same with at least the
packages that have accumulated many
of the patches.
For instance, I maintain the
key driver inside of OpenTable
and I typically do the development
simultaneously for open heart and
for upstream.
So we want to make sure that in upstream
we get or in open
we get the changes that we make as fast
as possible into the tree because
we have a lot of active users that
regularly check out our development
releases. But we want to make sure that
the big changes that we make don't go
stale in our repository.
So we're working on it on
many things simultaneously in the
upstream projects as well.
And we have other interesting related
projects, one of the biggest ones
that has or or at least the ones,
the one that has been with us for the
longest period of time is
the freephone project, which was an
early adopter from from the
old WRP.
Fifty four time.
They're building community mesh network
projects.
And of course they're using our system
a lot because they're they're from that
the building is open, WRP
plus a few extra things.
So we we've always had a very good
relationship with that project and we get
a lot of feedback from them because
they do test many things that
other more simply use cases
usually don't get to test.
Which brings me to another
interesting project, I'm sure many
of you have heard of the buffer
problem where packets
accumulate delay over over
multiple hops in the Internet because
it's always cheaper to add more memory
than to actually fix the cueing things
or add more bandwidth.
So the buffer project
maintains its
it's a bit of a work of art,
but with strong collaboration
where they want to build a reference
router stack that fixes
the buffer load issues and is built
upon open and actually is used
to prototype many things that later
on make it into the open
art project.
And it's also doing a lot of research on
on IPV six routing
and how to put it into an
environment where you have multiple
routers and you don't have this one big
layer, two domain for everything.
And when I mentioned IPV six,
it's also worthwhile to mention
that there are two,
I think, competing IETF projects
that deal with IPV six routing
at home, which is Hypnotoad and home that
and it's nice to see that both of them
are based on open WRGA.
And yeah, this is pretty much
what I have for today, and I hope
you've brought some good questions for
me.
Hello, I'm engineer.
I know that the justices
makes makes a living,
so what is your suggestion,
suggestion to the companies
who want to have benefits
in the software design firm from
exact rules so that the customers buy
to get a higher price because it is
just the price, the faith argument.
Many companies don't have a chance,
especially here in Europe or whatever.
So what should they do to to
make the benefits and
the software some some extra widgets
with your way of open
source? But what should they do?
Very good question. Thanks.
So one of the suggestions that
that I keep making is to make sure
that you you split the development
in two parts so that you have one
part that takes care of the
individual project products that need to
be finished quickly.
But you also have a separate team which
can be made of a smaller
number of people with more technical
expertize to take care of the long term
health of the project so that whenever
you create a new product, you actually
start from the the latest
state of the long term health product
and then do everything you need to do
to get the product out and finished
quickly.
And then you can you can have the
long term health product or
project look at the changes
that the individual customer project's
made and just make sure that it's
all cleaned up, re architected
and fits into the overall long term
health of prospective.
I have another question.
You said that you do parallel in parallel
the development for some drivers, for the
mainline kernel and for poverty.
What are the challenges in converting the
drivers that are not in the upstream
kernels?
These are typically either things that
are too specialized
for the mainline kernel that don't really
or things that are simply not finished
yet.
It's typically always,
always a reason in terms of either
other mainline people will not like
this because sometimes it's a hack,
sometimes it's something that basically
only we need and other people
don't.
And sometimes it's just because something
is not finished, but it happens to work
well for for us.
Thank you.
One question about the acceleration,
lately, I've seen some Linux based
devices that have some sort of
acceleration of offloading engine
for IP routing or
firewalls.
Is it possible to support this in the
same way in ATI or is it
planned or is it even possible?
It's planned. It's something that I plan
on researching extensively next year.
I want to see if it's possible to
to integrate this properly with net
filter in a way that could possibly
be applied upstream.
But I still have to research
more about the side
effects of that because such changes will
be pretty intrusive and I need to make
sure that they don't hurt other normal
use cases inside mainline Linux.
Does open pretty
sane binaries, and I was wondering what
plans there might be for that.
No, we don't sign binaries yet.
We have to do
a lot of work on our release,
build infrastructure, which will happen
next year.
But I think one of the reasons why this
is not that important is because we
we can at least I consider the
open binaries mostly
something where you can test it.
But if you're going to use it a lot,
you want to build your own anyway,
because open tea is mostly
targeted at other developers.
And the whole end user use case
is mostly an afterthought
because I think the developer aspect is
the one that's more missing on the
market.
And related question are is the
source code signed?
We're using it and you can use
the git hashes.
OK, thanks at least.
Well, when I say we're using it, we're
not using it as a main repository
storage, but we usually
point people that want to download it at
the git repositories.
And we just happened to use Svenne
internally, but it's automatically
synched.
What about using open W.T.
and nonvolatile devices, I saw previous
efforts, even like I followed closely the
bauk effort to kind of assimilate the
Android. I really love that idea of
having a general purpose built system
for devices which may need initial
network connection and may not
offer a display like also NASA devices
and stuff like that.
Um, would you prefer that to
be developed in Forks of the Open ability
and keep open the ability based mostly
on for as a targeting network
devices, or
is there any effort going on on expanding
the target device
types?
It depends on what kind of
development for four things.
If you have lots of packages that you
need for for your particular use case,
then we want to have this as a sort of
package fit instead of being developed
inside the open repositories,
because we are actually trying to offload
much of the package maintenance to
to other feeds and other communities,
because with the limited number of people
that we have, it's just too much to
do all the work ourselves.
But we make sure that the package feed
list is actually maintained inside our
repository.
So you don't have to go
around digging for us to get all the
packages.
But this is something we want this part
of the work offloaded.
But if it's something where you need to
make changes to the core to make things
work, well, then we of course prefer that
to be done in the open code base.
So we were aware of the
different kinds of use cases that that
people are using with our code base.
And we want to make sure that we don't
have unnecessary forks of the main
code base.
Hi there, I two questions, my first
question is, I know that, like
with the with the art project,
sometimes the developers and users have
been at odds with things like project
purity.
Has there been any efforts to try and
kind of collaborate with those project
with the other project?
I'm actually also working
with the art guys and I'm working
on making sure that
they will not have to maintain their
hackish code base for much longer.
And my next question also
has to do with relating to other projects
is I know that inside Oakland,
for example, there's been like an idiot
driver for a wireless card that exists
solely in the open kernel patches
for a very long time.
Are there many efforts to upstream
patches like that?
Typically, those efforts
are made by the people that added the
package in the first place.
If it's a package that somebody send
a patch for a long time ago and it's
somebody that isn't really active in the
open desert community, we typically
don't go around looking for these kinds
of things to mainline them because that
would just be too much work for us at
this point. But if it's something where
we create something new, we try to
create it in a way where we can easily
upstream it, even while it's being
developed.
LOL, have you tried to base your belief
system around something like scratch
box, something like use a computer
simulation?
We haven't really tried it because we
don't think we really need it.
We also support some architectures
where there is no decent cumulous
support and we have many devices
that don't really work well with Kumo.
So we want to make sure that we don't add
additional restrictions or
make sure that you get a different
user experience if you're using a target
that isn't kÃ¼mmel supported.
And in some in some ways,
the built system already pretty much
does what we need for for these devices.
And if I've designed
most parts to be as easy
as possible to to change in various
ways and we we don't feel
like abandoning our built system in favor
of another one because we don't see the
advantages at this point.
Big headaches,
are there plans to rename the project?
No, I don't support the W
anymore, so it's maybe time to
rename.
Well, he could stand for other
things like wireless router technologies
or whatever.
So we don't feel
like changing the name at this point.
I just wanted to say
thanks for doing so much work on this
project. This is actually how I got into
Linux.
Welcome. Thanks so much.
We seem to be out of questions, so
thanks, Felix.
Thank you all for listening and.