8:47 p.m.
Hi all,
I'd like to have a discussion on whether or not it would be worth it to
invest actual time and resources into the following projects before we
release 1.0. Perhaps we could even delay 1.0's release slightly, if
they are deemed critical enough.
PackageKit Plugin for APK
=========================
This would allow us to have graphical UIs for installing, removing, and
updating packages with APK for "free". One thing that bothers me is
that APK doesn't yet have tagging or category support, so every package
would be in a single, large, unwieldy list. It'd be very nice if we
could add tagging first.
Of course, writing the plugin and then adding tagging to APK later is
another option.
Note that both KDE (Muon) and Gnome (gnome-packagekit) have GUI tools
built on top of PackageKit, so we would not need to write any GUIs.
Parcel
======
This is the Web and CLI UI for determining package availability,
version, and architectures. Similar to Alpine's pkgdb or Gentoo's
Package Home for the Web UI, and similar to eix on the CLI.
I still think this is a very worthy endeavour, but time is a precious
commodity and I don't know if we have the time to build it before 1.0
unless 1.0 is delayed.
Register
========
This is the popcon-like system that will let us explore and inspect
packages that are popular (and not popular) with the user community at
large. Cadey on IRC has been writing a prototype.
This, too, seems like a very important feature for 1.0.
Steam with gcompat
==================
I still have been unable to test the Steam binary on gcompat because it
requires 32-bit x86 and I don't have a 32-bit x86 installation with
gcompat anywhere. (The only 32-bit x86 install I have of Adélie,
outside of the builders, is a 500 MHz Pentium III laptop. Hardly an
amazing gaming system, that.)
I don't know if that is important enough to work on for 1.0, since you
can just use an Ubuntu chroot to play Steam games (this also prevents
the icky binary blobs from touching your rootfs). However, I will defer
to the community for that decision.
MIPS
====
We desired MIPS support in 1.0 before the Alpine rebase. I do have a
MIPS32 CI20 and a MIPS64 Indy, but I don't think either one of them
would be able to compose the entire distro in any decent amount of time.
We could still likely have a bootable image before 1.0 release if we
start now. Again, I'm not sure if the community desire is high enough
to warrant that as a "distraction" when it can wait for 1.5 or 2.0.
GNOME 3
=======
I believe aerdan@ has a partially working GNOME 3 tree in his
elementary-os branch of packages.git. I know that some packages were
requiring Python 2 (if I recall) and that was the end of that.
I would not mind putting in some effort to try and port those packages
to Python 3 if GNOME 3 is still a desktop we want to offer in 1.0.
Horizon
=======
There has been renewed interest in Horizon since the linux-wiiu team has
joined us. We could likely spin partitioning out to KDE Partition
Manager (https://www.kde.org/applications/system/kdepartitionmanager).
Since the linux-wiiu would like Horizon to use PackageKit (so that it
can handle any future pivots, if desired), it'd be a great idea to have
an APK PackageKit backend before we go back to Horizon.
Others?
=======
If anyone has any other 1.0 goals that aren't covered in the current
roadmap (https://wiki.adelielinux.org/wiki/Project:Roadmap), let's
discuss them here.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
11:07 a.m.
On May 17 07:47 PM, A. Wilcox wrote:
Hi all,
I'd like to have a discussion on whether or not it would be worth it to
invest actual time and resources into the following projects before we
release 1.0. Perhaps we could even delay 1.0's release slightly, if
they are deemed critical enough.
The relative importance of these projects depend on what the goals are
for the distribution - specifically what level of technical literacy we
expect our users to have. At early adoption levels it will be relatively
high of course, but at the 1.0 release I think Adélie should be
accessible to all.
PackageKit Plugin for APK
=========================
This would allow us to have graphical UIs for installing, removing, and
updating packages with APK for "free".
As such, this is probably one of the more important projects that needs
to get going.
One thing that bothers me is that APK doesn't yet have tagging
or
category support, so every package would be in a single, large,
unwieldy list. It'd be very nice if we could add tagging first.
Of course, writing the plugin and then adding tagging to APK later is
another option.
Note that both KDE (Muon) and Gnome (gnome-packagekit) have GUI tools
built on top of PackageKit, so we would not need to write any GUIs.
Tagging can probably be added after-the-fact if it is determined that
adding this functionality to APK will take too long. As long as the
search isn't too bad things should be fine for the time being.
Parcel
======
This is the Web and CLI UI for determining package availability,
version, and architectures. Similar to Alpine's pkgdb or Gentoo's
Package Home for the Web UI, and similar to eix on the CLI.
I still think this is a very worthy endeavour, but time is a precious
commodity and I don't know if we have the time to build it before 1.0
unless 1.0 is delayed.
This can probably be pushed back for now. I kind of see it as a
trade-off with the PackageKit plugin for APK since they have similar
features, but the plugin will have some functionality that Parcel
necessarily cannot have - such as being able to install packages to the
user's system, unless something like openSUSE's "one click install"
feature[1] is implemented. That would essentially be a bridge between
Parcel and the desktop package manager, so the plugin should still be
prioritized over Parcel.
Register
========
This is the popcon-like system that will let us explore and inspect
packages that are popular (and not popular) with the user community at
large. Cadey on IRC has been writing a prototype.
This, too, seems like a very important feature for 1.0.
Can't say I disagree. I'm sure it would be very nice to know what to
prioritize, which is also the subject of this thread :)
Steam with gcompat
==================
I still have been unable to test the Steam binary on gcompat because it
requires 32-bit x86 and I don't have a 32-bit x86 installation with
gcompat anywhere. (The only 32-bit x86 install I have of Adélie,
outside of the builders, is a 500 MHz Pentium III laptop. Hardly an
amazing gaming system, that.)
I don't know if that is important enough to work on for 1.0, since you
can just use an Ubuntu chroot to play Steam games (this also prevents
the icky binary blobs from touching your rootfs). However, I will defer
to the community for that decision.
chroot is probably fine for now to keep the distro's focus narrow. I
already use a chroot for other software such as widevine (eww) and
LibreOffice, for example.
Horizon
=======
There has been renewed interest in Horizon since the linux-wiiu team has
joined us. We could likely spin partitioning out to KDE Partition
Manager (https://www.kde.org/applications/system/kdepartitionmanager).
Since the linux-wiiu would like Horizon to use PackageKit (so that it
can handle any future pivots, if desired), it'd be a great idea to have
an APK PackageKit backend before we go back to Horizon.
This is a pretty important project, if not one of the most important
projects in my opinion. The manual installation process works, but it
isn't without bugs at times and it's certainly not intuitive to the
casual user - reminiscent of the Arch installation process, but much
more streamlined at least. A simple yet configurable installation
process is key to onboarding new users and as such I think this project
should be given priority, as well as maintenance of the manual
installation documentation.
Others?
=======
If anyone has any other 1.0 goals that aren't covered in the current
roadmap (https://wiki.adelielinux.org/wiki/Project:Roadmap), let's
discuss them here.
It would be nice to have LibreOffice by 1.0 :) Of course, I can use my
chroot as long as need be but it's certainly very useful software for
both "Education" and "Office".
[1]: https://en.opensuse.org/openSUSE:One_Click_Install
7:47 p.m.
On 05/18/18 10:07, Max Rees wrote:
On May 17 07:47 PM, A. Wilcox wrote:
> Hi all,
>
> I'd like to have a discussion on whether or not it would be worth it to
> invest actual time and resources into the following projects before we
> release 1.0. Perhaps we could even delay 1.0's release slightly, if
> they are deemed critical enough.
The relative importance of these projects depend on what the goals are
for the distribution - specifically what level of technical literacy we
expect our users to have. At early adoption levels it will be relatively
high of course, but at the 1.0 release I think Adélie should be
accessible to all.
This is a noble goal but I don't know if it is feasible. Quoting the
roadmap directly:
Adélie Linux 2.0 is meant to be the first release that is truly ready
for the general public. Horizon is planned to be rock solid and fully
tested on all architectures and in many corner cases. Other features TBD.
The phrase "accessible to all" conjures up in my mind people who may not
have even ever used a computer before, or at least anything beyond a
smartphone. While I do want to support these kinds of users, 1.0 is not
the time or place for them.
What you probably meant, though, are the people who do know *basics*
(how to use a mouse, what a 'software package' is, etc), and want to try
a Linux system out for whatever reason.
> PackageKit Plugin for APK
> =========================
>
> This would allow us to have graphical UIs for installing, removing, and
> updating packages with APK for "free".
As such, this is probably one of the more important projects that needs
to get going.
> One thing that bothers me is that APK doesn't yet have tagging or
> category support, so every package would be in a single, large,
> unwieldy list. It'd be very nice if we could add tagging first.
>
> Of course, writing the plugin and then adding tagging to APK later is
> another option.
>
> Note that both KDE (Muon) and Gnome (gnome-packagekit) have GUI tools
> built on top of PackageKit, so we would not need to write any GUIs.
Tagging can probably be added after-the-fact if it is determined that
adding this functionality to APK will take too long. As long as the
search isn't too bad things should be fine for the time being.
At this point, with two weeks to go before beta1 and three months to go
before 1.0, any time mucking with APK's source is too much time. Search
should be quite fine. I'm more concerned about discovery, which is why
tagging would be useful.
> Parcel
> ======
>
> This is the Web and CLI UI for determining package availability,
> version, and architectures. Similar to Alpine's pkgdb or Gentoo's
> Package Home for the Web UI, and similar to eix on the CLI.
>
> I still think this is a very worthy endeavour, but time is a precious
> commodity and I don't know if we have the time to build it before 1.0
> unless 1.0 is delayed.
This can probably be pushed back for now. I kind of see it as a
trade-off with the PackageKit plugin for APK since they have similar
features, but the plugin will have some functionality that Parcel
necessarily cannot have - such as being able to install packages to the
user's system, unless something like openSUSE's "one click install"
feature[1] is implemented. That would essentially be a bridge between
Parcel and the desktop package manager, so the plugin should still be
prioritized over Parcel.
Nothing like SuSE's 1-click is planned until after 3.0.
The point of Parcel was to allow people to see what we package *before*
they install Adélie (do they have thunderbird? what about pidgin? etc),
and also for maintainers (what version are they shipping? on what arches?).
I do agree that this is probably less of a concern for users than it
seems, so it should probably be pushed back.
> Register
> ========
>
> This is the popcon-like system that will let us explore and inspect
> packages that are popular (and not popular) with the user community at
> large. Cadey on IRC has been writing a prototype.
>
> This, too, seems like a very important feature for 1.0.
Can't say I disagree. I'm sure it would be very nice to know what to
prioritize, which is also the subject of this thread :)
> Steam with gcompat
> ==================
>
> I still have been unable to test the Steam binary on gcompat because it
> requires 32-bit x86 and I don't have a 32-bit x86 installation with
> gcompat anywhere. (The only 32-bit x86 install I have of Adélie,
> outside of the builders, is a 500 MHz Pentium III laptop. Hardly an
> amazing gaming system, that.)
>
> I don't know if that is important enough to work on for 1.0, since you
> can just use an Ubuntu chroot to play Steam games (this also prevents
> the icky binary blobs from touching your rootfs). However, I will defer
> to the community for that decision.
chroot is probably fine for now to keep the distro's focus narrow. I
already use a chroot for other software such as widevine (eww) and
LibreOffice, for example.
This isn't really a distro focus. gcompat is a project "of" Adélie, but
it is not Adélie. (It also sees use on other distros; I know at least
Alpine and Void ship it in their repos.)
LibreOffice *should* run on musl, but see below...
> Horizon
> =======
>
> There has been renewed interest in Horizon since the linux-wiiu team has
> joined us. We could likely spin partitioning out to KDE Partition
> Manager (https://www.kde.org/applications/system/kdepartitionmanager).
>
> Since the linux-wiiu would like Horizon to use PackageKit (so that it
> can handle any future pivots, if desired), it'd be a great idea to have
> an APK PackageKit backend before we go back to Horizon.
This is a pretty important project, if not one of the most important
projects in my opinion. The manual installation process works, but it
isn't without bugs at times and it's certainly not intuitive to the
casual user - reminiscent of the Arch installation process, but much
more streamlined at least. A simple yet configurable installation
process is key to onboarding new users and as such I think this project
should be given priority, as well as maintenance of the manual
installation documentation.
Statements like these make me think that the best way forward is to get
to beta3 (which was to be our last beta cycle before 1.0), and just
*stop* and not release 1.0 until Horizon is ready, whether that is on
time or six months late.
You aren't the first one to make Horizon sound that important, and I
doubt you'll be the last.
> Others?
> =======
>
> If anyone has any other 1.0 goals that aren't covered in the current
> roadmap (https://wiki.adelielinux.org/wiki/Project:Roadmap), let's
> discuss them here.
It would be nice to have LibreOffice by 1.0 :) Of course, I can use my
chroot as long as need be but it's certainly very useful software for
both "Education" and "Office".
You were the one who opened the clucene PR, as I recall. I still have
not managed to track down why the tests fail so spectacularly; that is
the main reason I haven't proceeded further with LibreOffice. The way
the tests failed made me very nervous about the stability of projects
that would use it as a library.
It's even worse on PowerPC, for what it's worth.
Best to you and yours,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
9:27 p.m.
On May 18 06:47 PM, A. Wilcox wrote:
On 05/18/18 10:07, Max Rees wrote:
> The relative importance of these projects depend on what the goals are
> for the distribution - specifically what level of technical literacy we
> expect our users to have. At early adoption levels it will be relatively
> high of course, but at the 1.0 release I think Adélie should be
> accessible to all.
This is a noble goal but I don't know if it is feasible. Quoting the
roadmap directly:
Adélie Linux 2.0 is meant to be the first release that is truly ready
for the general public. Horizon is planned to be rock solid and fully
tested on all architectures and in many corner cases. Other features TBD.
The phrase "accessible to all" conjures up in my mind people who may not
have even ever used a computer before, or at least anything beyond a
smartphone. While I do want to support these kinds of users, 1.0 is not
the time or place for them.
That is correct - "all" is more broad than I had meant.
What you probably meant, though, are the people who do know *basics*
(how to use a mouse, what a 'software package' is, etc), and want to try
a Linux system out for whatever reason.
This seems a more reasonable goal for the target 1.0 user base.
Nothing like SuSE's 1-click is planned until after 3.0.
I had not intended to give the impression that this should be a goal,
anytime soon or at all. Just something to consider :)
The point of Parcel was to allow people to see what we package
*before*
they install Adélie (do they have thunderbird? what about pidgin? etc),
and also for maintainers (what version are they shipping? on what arches?).
I do agree that this is probably less of a concern for users than it
seems, so it should probably be pushed back.
This is indeed a complicated issue of priority here. I had considered
that this is what you intended with Parcel, but I think it is a
reasonable assumption that a lot of people just burn the ISO and boot it
up. From there hopefully they can be guided to the desktop package
manager to look at available software... but the more I think about it,
maybe Parcel should be prioritized over the desktop software. Alpine of
course gets along just fine with pkgdb and no desktop package manager
(does ACF have package manager functionality? I forget), but Alpine has
a different focus than us. Again it all comes back to what you are
expecting from the 1.0 user base. If they can run "apk add / del /
update / upgrade" from the CLI then maybe Parcel is more important. The
more I think about it the more I flip flop.
On a related note, I am wondering if there is anything preventing Adélie
from reusing pkgdb (at least in the interim). It doesn't have all the
features that the requirements laid out, vaguely recalling from memory
because foxkit.us died :( but maybe it can be extended. De-duplication
of effort can be a good thing, although I am aware that cooperation has
been a little strained lately.
> chroot is probably fine for now to keep the distro's focus
narrow. I
> already use a chroot for other software such as widevine (eww) and
> LibreOffice, for example.
This isn't really a distro focus. gcompat is a project "of" Adélie, but
it is not Adélie. (It also sees use on other distros; I know at least
Alpine and Void ship it in their repos.)
I did not intend to mean that gcompat should / need be worked on to
support widevine, just noting that I already need a chroot for such
purposes and thus it's not a big deal at least for me when I need to
turn to it for things Adélie doesn't support.
>> Horizon
>> =======
>>
>> There has been renewed interest in Horizon since the linux-wiiu team has
>> joined us. We could likely spin partitioning out to KDE Partition
>> Manager (https://www.kde.org/applications/system/kdepartitionmanager).
>>
>> Since the linux-wiiu would like Horizon to use PackageKit (so that it
>> can handle any future pivots, if desired), it'd be a great idea to have
>> an APK PackageKit backend before we go back to Horizon.
>
> This is a pretty important project, if not one of the most important
> projects in my opinion. The manual installation process works, but it
> isn't without bugs at times and it's certainly not intuitive to the
> casual user - reminiscent of the Arch installation process, but much
> more streamlined at least. A simple yet configurable installation
> process is key to onboarding new users and as such I think this project
> should be given priority, as well as maintenance of the manual
> installation documentation.
Statements like these make me think that the best way forward is to get
to beta3 (which was to be our last beta cycle before 1.0), and just
*stop* and not release 1.0 until Horizon is ready, whether that is on
time or six months late.
You aren't the first one to make Horizon sound that important, and I
doubt you'll be the last.
That doesn't seem like a terrible idea. Maybe also hold the release
until the documentation is complete as well (which I think is your goal
anyway based on the roadmap, though it isn't clear).
>> Others?
>> =======
>>
>> If anyone has any other 1.0 goals that aren't covered in the current
>> roadmap (https://wiki.adelielinux.org/wiki/Project:Roadmap), let's
>> discuss them here.
>
> It would be nice to have LibreOffice by 1.0 :) Of course, I can use my
> chroot as long as need be but it's certainly very useful software for
> both "Education" and "Office".
You were the one who opened the clucene PR, as I recall. I still have
not managed to track down why the tests fail so spectacularly; that is
the main reason I haven't proceeded further with LibreOffice. The way
the tests failed made me very nervous about the stability of projects
that would use it as a library.
It's even worse on PowerPC, for what it's worth.
LibreOffice says "[clucene] is used to index our downloadable help
packages, and allow them to be searched efficiently at run-time." so
perhaps it isn't a huge concern for now... The problem is compounded
however because clucene upstream on SF appears to be dead, evidenced by
no commits since 2013 and no activity on a 2016 PR to add GCC 6 support
to their cmake files, resulting in a patch that must be carried by all
distros that ship clucene. The clucene patches and such in LibreOffice's
tree also seem a little stale. I will do some more research this weekend
on this.
Max
7:07 p.m.
On 05/18/18 20:27, Max Rees wrote:
On May 18 06:47 PM, A. Wilcox wrote:
> On 05/18/18 10:07, Max Rees wrote:
>> The relative importance of these projects depend on what the goals are
>> for the distribution - specifically what level of technical literacy we
>> expect our users to have. At early adoption levels it will be relatively
>> high of course, but at the 1.0 release I think Adélie should be
>> accessible to all.
>
> The phrase "accessible to all" conjures up in my mind people who may not
> have even ever used a computer before, or at least anything beyond a
> smartphone. While I do want to support these kinds of users, 1.0 is not
> the time or place for them.
That is correct - "all" is more broad than I had meant.
> What you probably meant, though, are the people who do know *basics*
> (how to use a mouse, what a 'software package' is, etc), and want to try
> a Linux system out for whatever reason.
This seems a more reasonable goal for the target 1.0 user base.
*nod* Glad we have agreement here :)
> Nothing like SuSE's 1-click is planned until after 3.0.
I had not intended to give the impression that this should be a goal,
anytime soon or at all. Just something to consider :)
Right, but I was simply noting that it *is* a goal, just one in the
distant handwavy future.
> The point of Parcel was to allow people to see what we package
*before*
> they install Adélie (do they have thunderbird? what about pidgin? etc),
> and also for maintainers (what version are they shipping? on what arches?).
>
> I do agree that this is probably less of a concern for users than it
> seems, so it should probably be pushed back.
This is indeed a complicated issue of priority here. I had considered
that this is what you intended with Parcel, but I think it is a
reasonable assumption that a lot of people just burn the ISO and boot it
up. From there hopefully they can be guided to the desktop package
manager to look at available software... but the more I think about it,
maybe Parcel should be prioritized over the desktop software. Alpine of
course gets along just fine with pkgdb and no desktop package manager
(does ACF have package manager functionality? I forget), but Alpine has
a different focus than us. Again it all comes back to what you are
expecting from the 1.0 user base. If they can run "apk add / del /
update / upgrade" from the CLI then maybe Parcel is more important. The
more I think about it the more I flip flop.
There was some very, very alpha-quality stuff to make a desktop UI for
apk on Alpine. Beyond that, no, they have no desktop package manager.
They also don't have a desktop, beyond XFCE 4 - which is not being
actively maintained as far as I can tell; it was two minor versions
behind when I checked for the alpha5 mass rebuild.
There are three different classes of people that I have in mind for the
1.0 user base:
* people like you or I, who are ex-gentoos and spend more time in the
CLI than the GUI anyway
* people like Elizafox, who *can* use the CLI but think every time they
use the CLI "why do computers still suck so much?"
* people like my mother, who feel they are old enough to not want to
deal with the CLI any more (in the "I'm an adult" sense, not the "past
my prime" sense)
Ideally, all three classes should be served. It may be the case that we
need PackageKit *and* Parcel in for 1.0. Remember that PackageKit is
going to be needed for Horizon, so if we are shipping Horizon with 1.0
then we need it anyway. Parcel shouldn't be too hard to do. It's a
time commitment problem for me.
On a related note, I am wondering if there is anything preventing
Adélie
from reusing pkgdb (at least in the interim). It doesn't have all the
features that the requirements laid out, vaguely recalling from memory
because foxkit.us died :( but maybe it can be extended. De-duplication
of effort can be a good thing, although I am aware that cooperation has
been a little strained lately.
Rehosted -> https://code.foxkit.us/snippets/17
I can't extend it. I've forgotten (on purpose) everything I knew about
Lua. I don't think it'd be a smart idea to ask the community to fix it,
either, when we don't have any infrastructure for running Lua Web
thingies. And it definitely won't help the CLI part.
I really hate to say this, or even think this, but if we need something
that quickly and it just needs to be *there*, I can always write it in
Rails. Rails is extremely quick to prototype, and I don't think there
are any major security threats that have been identified for this
system. The worst that I could think of that could happen is someone
manipulating votes for a package. (If they're that passionate about it,
maybe we could look at it and at least give an official statement on
denial.)
>> chroot is probably fine for now to keep the distro's
focus narrow. I
>> already use a chroot for other software such as widevine (eww) and
>> LibreOffice, for example.
>
> This isn't really a distro focus. gcompat is a project "of" Adélie,
but
> it is not Adélie. (It also sees use on other distros; I know at least
> Alpine and Void ship it in their repos.)
I did not intend to mean that gcompat should / need be worked on to
support widevine, just noting that I already need a chroot for such
purposes and thus it's not a big deal at least for me when I need to
turn to it for things Adélie doesn't support.
Oh, I understood that. I was responding to where you said "keep the
distro's focus narrow". Stuff with gcompat does not narrow or widen
Adélie's focus. If it works with Steam, that is a win for Adélie, but
it does not make Adélie any more or less a "gaming" distro. It just
means gcompat supports more things.
I would rather prefer if gcompat did *not* make WideVine usable on
Adélie. I do not really trust this Google binary blob DRM. We do not
know what it is sending onward to Google, and it is legally dubious if
we can reverse-engineer it just to find out the answer to that.
>>> Horizon
>>> =======
>>>
> Statements like these make me think that the best way forward is to get
> to beta3 (which was to be our last beta cycle before 1.0), and just
> *stop* and not release 1.0 until Horizon is ready, whether that is on
> time or six months late.
>
> You aren't the first one to make Horizon sound that important, and I
> doubt you'll be the last.
That doesn't seem like a terrible idea. Maybe also hold the release
until the documentation is complete as well (which I think is your goal
anyway based on the roadmap, though it isn't clear).
I'm not letting documentation issues slow the beta cycles because we
need to make sure the system is solid and tested before release, but you
are correct in assuming that it would legitimately block 1.0.
>>> Others?
>>> =======
>>>
LibreOffice says "[clucene] is used to index our downloadable help
packages, and allow them to be searched efficiently at run-time." so
perhaps it isn't a huge concern for now... The problem is compounded
however because clucene upstream on SF appears to be dead, evidenced by
no commits since 2013 and no activity on a 2016 PR to add GCC 6 support
to their cmake files, resulting in a patch that must be carried by all
distros that ship clucene. The clucene patches and such in LibreOffice's
tree also seem a little stale. I will do some more research this weekend
on this.
I still haven't the time to properly investigate the test failures
beyond reproducing them. I wouldn't mind helping in the investigation.
Max
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
1088
days inactive
1089
days old
adelie-devel@lists.adelielinux.org
4 comments
2 participants
participants (2)
-
A. Wilcox -
Max Rees