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