arch health

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

arch health

ITwrx.org
i'm a little concerned about arch's overall health and i was wondering
if there's anything we can do about it.

why am i concerned?

Many users tested to demonstrate that PIE would not cause an undue
performance burden but it has still not been implemented due to dev's
lack of time. Now said dev is also resigning from packaging due to it
becoming a chore. Is PIE on the menu of the adopter of those packages?

There are also many official packages that have been out of date for a
while. At least one of the devs seems to have too many packages to
maintain. Probably because packages were orphaned and someone had to
pick up the slack. There are probably many packages in aur that should
be moved to official if there were devs who had time to deal with them.
There are probably some bugs that need to be fixed too.  Maybe we can
use some % of donations to pay a dev/devs?  Can we modernize the
donations system? I sent a message to SPI's web dev email asking about
improvements to project's pages but i haven't heard back.

IMHO, a general donate method doesn't cut it. Crowd funding should
demonstrate clearly that people will donate much more when they have
input and can see goals, progress, etc. Donors and devs should be able
to designate goals (devs could have approval/veto power) and/or donors
should be able to donate towards approved goals.  It would be nice if we
could fund developers or maybe just a rewards pool where devs get some
appreciation money each month. Crypto currency could be an option. Devs
could choose what they want to receive. If nothing else, maybe we could
crypto tip individually or to an Arch address. Some way to make arch
development more practical for people. I know in the past arch devs have
said roughly that "he who does the dev makes the decisions" but maybe us
users can buy our way in just enough to influence the speed or goals of
the distro's dev? It doesn't seem like the current state of things can
keep up with threats, new features, etc. I think i am not alone in being
willing to pitch in money, when i can, to make it easier or more
worthwhile for devs, new or current. At least we could see what the
current funding levels for goals were so we would know if more needs to
be done. Some other distros have large corps that can foot the bill to
get things done. I'm sure Arch could use some help too, even if we
already have donation funds for infrastructure needs.

thanks

 

--
Information Technology Works
https://ITwrx.org
@ITwrxorg
Reply | Threaded
Open this post in threaded view
|

Re: arch health

arch general mailing list-2
2017/04/20 午前8:30 "ITwrx.org" <[hidden email]>:

i'm a little concerned about arch's overall health and i was wondering
if there's anything we can do about it.

why am i concerned?

Many users tested to demonstrate that PIE would not cause an undue
performance burden but it has still not been implemented due to dev's
lack of time. Now said dev is also resigning from packaging due to it
becoming a chore. Is PIE on the menu of the adopter of those packages?

There are also many official packages that have been out of date for a
while. At least one of the devs seems to have too many packages to
maintain. Probably because packages were orphaned and someone had to
pick up the slack. There are probably many packages in aur that should
be moved to official if there were devs who had time to deal with them.
There are probably some bugs that need to be fixed too.  Maybe we can
use some % of donations to pay a dev/devs?  Can we modernize the
donations system? I sent a message to SPI's web dev email asking about
improvements to project's pages but i haven't heard back.

IMHO, a general donate method doesn't cut it. Crowd funding should
demonstrate clearly that people will donate much more when they have
input and can see goals, progress, etc. Donors and devs should be able
to designate goals (devs could have approval/veto power) and/or donors
should be able to donate towards approved goals.  It would be nice if we
could fund developers or maybe just a rewards pool where devs get some
appreciation money each month. Crypto currency could be an option. Devs
could choose what they want to receive. If nothing else, maybe we could
crypto tip individually or to an Arch address. Some way to make arch
development more practical for people. I know in the past arch devs have
said roughly that "he who does the dev makes the decisions" but maybe us
users can buy our way in just enough to influence the speed or goals of
the distro's dev? It doesn't seem like the current state of things can
keep up with threats, new features, etc. I think i am not alone in being
willing to pitch in money, when i can, to make it easier or more
worthwhile for devs, new or current. At least we could see what the
current funding levels for goals were so we would know if more needs to
be done. Some other distros have large corps that can foot the bill to
get things done. I'm sure Arch could use some help too, even if we
already have donation funds for infrastructure needs.

thanks



--
Information Technology Works
https://ITwrx.org
@ITwrxorg

Wait, actual question is about PIE?
If you find that package are outdated in community or extra, file a bug rep.
Why not do it?
Reply | Threaded
Open this post in threaded view
|

Re: arch health

ITwrx.org
On 04/19/2017 06:32 PM, Dragon ryu via arch-general wrote:

> 2017/04/20 午前8:30 "ITwrx.org" <[hidden email]>:
>
> i'm a little concerned about arch's overall health and i was wondering
> if there's anything we can do about it.
>
> why am i concerned?
>
> Many users tested to demonstrate that PIE would not cause an undue
> performance burden but it has still not been implemented due to dev's
> lack of time. Now said dev is also resigning from packaging due to it
> becoming a chore. Is PIE on the menu of the adopter of those packages?
>
> There are also many official packages that have been out of date for a
> while. At least one of the devs seems to have too many packages to
> maintain. Probably because packages were orphaned and someone had to
> pick up the slack. There are probably many packages in aur that should
> be moved to official if there were devs who had time to deal with them.
> There are probably some bugs that need to be fixed too.  Maybe we can
> use some % of donations to pay a dev/devs?  Can we modernize the
> donations system? I sent a message to SPI's web dev email asking about
> improvements to project's pages but i haven't heard back.
>
> IMHO, a general donate method doesn't cut it. Crowd funding should
> demonstrate clearly that people will donate much more when they have
> input and can see goals, progress, etc. Donors and devs should be able
> to designate goals (devs could have approval/veto power) and/or donors
> should be able to donate towards approved goals.  It would be nice if we
> could fund developers or maybe just a rewards pool where devs get some
> appreciation money each month. Crypto currency could be an option. Devs
> could choose what they want to receive. If nothing else, maybe we could
> crypto tip individually or to an Arch address. Some way to make arch
> development more practical for people. I know in the past arch devs have
> said roughly that "he who does the dev makes the decisions" but maybe us
> users can buy our way in just enough to influence the speed or goals of
> the distro's dev? It doesn't seem like the current state of things can
> keep up with threats, new features, etc. I think i am not alone in being
> willing to pitch in money, when i can, to make it easier or more
> worthwhile for devs, new or current. At least we could see what the
> current funding levels for goals were so we would know if more needs to
> be done. Some other distros have large corps that can foot the bill to
> get things done. I'm sure Arch could use some help too, even if we
> already have donation funds for infrastructure needs.
>
> thanks
>
>
>
> --
> Information Technology Works
> https://ITwrx.org
> @ITwrxorg
>
> Wait, actual question is about PIE?
> If you find that package are outdated in community or extra, file a bug rep.
> Why not do it?
>
no, PIE is just one of the examples i listed of symptoms of a larger
issue that i thought might could be helped by paying devs and
modernizing the donation system. why would i file a bug for an out of
date package? i'm sure the developer is notified when a package is
flagged? why should i pester them to update it?
Reply | Threaded
Open this post in threaded view
|

Re: arch health

Ralf Mardorf-4
In reply to this post by arch general mailing list-2
Hi,

I would be concerned, if too many security features not everybody needs,
would become default. Why not dropping security features completely and
instead making real-time optimised features the default? This is a
rhetorical question, but actually I would prefer the latter.

In my experiences Arch is very healthy.

I doubt that many packages are outdated.

Right off the bat a few come to mind, e.g.

 claws-mail and clawsker

but we had Easter holidays and some packages are already in testing.

Other packages, such as e.g.

 ardour

are out of date for a long time, but the maintainer explained why he has
got no time for a while. Apart from this Ardour is niche software.

Each of the outdated packages I noticed still build using ABS or AUR
PKGBUILDs by just changing the version and skipping or changing the
checksums or they require minimal additional editing, if so I
usually drop a note to AUR comments, how to fix the issue.

It's hard to find much more packages I consider really outdated.
I noticed that some packages from official repositories are flagged out
of date, a few minutes after upstream released a new version, so I
wouldn't count those packages.

In my experiences Arch is a healthy rolling release. There are a few
hiccups, but I experience less hiccups using Arch, than I experience
serious issues with other distros.

Regards,
Ralf
Reply | Threaded
Open this post in threaded view
|

Re: arch health

Ralf Mardorf-4
In reply to this post by ITwrx.org
On Wed, 19 Apr 2017 18:55:05 -0500, ITwrx.org wrote:
>> 2017/04/20 午前8:30 "ITwrx.org" <[hidden email]>:
>>
>> i'm a little concerned about arch's overall health and i was
>> wondering if there's anything we can do about it.
>>  
>no, PIE is just one of the examples i listed of symptoms of a larger
>issue

You are concerned about the "overall health", but you only provide a
vague diagnosis. A hiccup seldom is a symptom of sickness, but you even
do not clearly describe a hiccup.
Reply | Threaded
Open this post in threaded view
|

Re: arch health

ITwrx.org
In reply to this post by Ralf Mardorf-4
On 04/19/2017 07:22 PM, Ralf Mardorf wrote:

> Hi,
>
> I would be concerned, if too many security features not everybody needs,
> would become default. Why not dropping security features completely and
> instead making real-time optimised features the default? This is a
> rhetorical question, but actually I would prefer the latter.
>
> In my experiences Arch is very healthy.
>
> I doubt that many packages are outdated.
>
> Right off the bat a few come to mind, e.g.
>
>  claws-mail and clawsker
>
> but we had Easter holidays and some packages are already in testing.
>
> Other packages, such as e.g.
>
>  ardour
>
> are out of date for a long time, but the maintainer explained why he has
> got no time for a while. Apart from this Ardour is niche software.
>
> Each of the outdated packages I noticed still build using ABS or AUR
> PKGBUILDs by just changing the version and skipping or changing the
> checksums or they require minimal additional editing, if so I
> usually drop a note to AUR comments, how to fix the issue.
>
> It's hard to find much more packages I consider really outdated.
> I noticed that some packages from official repositories are flagged out
> of date, a few minutes after upstream released a new version, so I
> wouldn't count those packages.
>
> In my experiences Arch is a healthy rolling release. There are a few
> hiccups, but I experience less hiccups using Arch, than I experience
> serious issues with other distros.
>
> Regards,
> Ralf
>
thanks for your input. i'm not saying Arch isn't great. I use it for
everything and it would take a whole lot for that to change. I just want
the healthiest Arch possible. I think that Arch could have a few
different "build profiles" if it was possible to automate packaging a
little or if there were more devs or devs had more time to allocate to
Arch because they were getting paid. Or, if the donation system were
modernized, Arch could fund it's priorities in that regard and maybe
people choose your goals instead of mine.
Reply | Threaded
Open this post in threaded view
|

Re: arch health

arch general mailing list-2
2017/04/20 午前9:42 "ITwrx.org" <[hidden email]>:

On 04/19/2017 07:22 PM, Ralf Mardorf wrote:

> Hi,
>
> I would be concerned, if too many security features not everybody needs,
> would become default. Why not dropping security features completely and
> instead making real-time optimised features the default? This is a
> rhetorical question, but actually I would prefer the latter.
>
> In my experiences Arch is very healthy.
>
> I doubt that many packages are outdated.
>
> Right off the bat a few come to mind, e.g.
>
>  claws-mail and clawsker
>
> but we had Easter holidays and some packages are already in testing.
>
> Other packages, such as e.g.
>
>  ardour
>
> are out of date for a long time, but the maintainer explained why he has
> got no time for a while. Apart from this Ardour is niche software.
>
> Each of the outdated packages I noticed still build using ABS or AUR
> PKGBUILDs by just changing the version and skipping or changing the
> checksums or they require minimal additional editing, if so I
> usually drop a note to AUR comments, how to fix the issue.
>
> It's hard to find much more packages I consider really outdated.
> I noticed that some packages from official repositories are flagged out
> of date, a few minutes after upstream released a new version, so I
> wouldn't count those packages.
>
> In my experiences Arch is a healthy rolling release. There are a few
> hiccups, but I experience less hiccups using Arch, than I experience
> serious issues with other distros.
>
> Regards,
> Ralf
>
thanks for your input. i'm not saying Arch isn't great. I use it for
everything and it would take a whole lot for that to change. I just want
the healthiest Arch possible. I think that Arch could have a few
different "build profiles" if it was possible to automate packaging a
little or if there were more devs or devs had more time to allocate to
Arch because they were getting paid. Or, if the donation system were
modernized, Arch could fund it's priorities in that regard and maybe
people choose your goals instead of mine.

Well, Arcg standard is Keep It Simple, mate.
Reply | Threaded
Open this post in threaded view
|

Re: arch health

Jelle van der Waa-2
In reply to this post by ITwrx.org
On 04/19/17 at 06:55pm, ITwrx.org wrote:

> On 04/19/2017 06:32 PM, Dragon ryu via arch-general wrote:
> > 2017/04/20 午前8:30 "ITwrx.org" <[hidden email]>:
> >
> > <snip>
> >
> > Wait, actual question is about PIE?
> > If you find that package are outdated in community or extra, file a bug rep.
> > Why not do it?
> >
> no, PIE is just one of the examples i listed of symptoms of a larger
> issue that i thought might could be helped by paying devs and
> modernizing the donation system.
PIE is blocked by upstream because of this bug iirc. [1]

> why would i file a bug for an out of
> date package? i'm sure the developer is notified when a package is
> flagged? why should i pester them to update it?

You don't and it's counterproductive, just flag it out of date.
Currently you might experience packages being updated a lot slower since
we have a lot of big invasive rebuilds; OpenSSL 1.1, LLVM 4.0.
Especially the OpenSSL rebuild was painful and time consuming.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21090

--
Jelle van der Waa

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: arch health

Jelle van der Waa-2
In reply to this post by arch general mailing list-2
On 04/20/17 at 08:32am, Dragon ryu via arch-general wrote:

> 2017/04/20 午前8:30 "ITwrx.org" <[hidden email]>:
>
> i'm a little concerned about arch's overall health and i was wondering
> if there's anything we can do about it.
>
> why am i concerned?
>
> --
> Information Technology Works
> https://ITwrx.org
> @ITwrxorg
>
> Wait, actual question is about PIE?
> If you find that package are outdated in community or extra, file a bug rep.
> Why not do it?
Can you please fix your client to reply sanely and not append your own
text to the original mail it's confusing and silly.

And again don't file bug reports for out of date packages..

--
Jelle van der Waa

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: arch health

David C. Rankin
In reply to this post by Ralf Mardorf-4
On 04/19/2017 07:22 PM, Ralf Mardorf wrote:
> In my experiences Arch is very healthy.

Taking the needed time to git it done correctly the first time is NOT an
indication of poor health -- just the opposite. I would rather have packages
stay in testing an additional 30 days and have all problems addressed than
have it called "good enough" in some arbitrary rush that results in more
problems and bug reports down the line.

Since the infighting of systemd and the libc move have been relegated to
history, I haven't seen any indication of ill heath since that time. (having
to build php56 from AUR is a bit of a pain, but that too is no indication of
any ill health in the distro...

--
David C. Rankin, J.D.,P.E.
Reply | Threaded
Open this post in threaded view
|

Re: arch health

arch general mailing list-2
In reply to this post by Ralf Mardorf-4
> On 20 April 2017 at 03:23:04, Ralf Mardorf wrote:
> I would be concerned, if too many security
features not everybody needs,
> would become default. Why not dropping security
features completely and
> instead making real-time optimised features the
default? This is a
> rhetorical question, but actually I would prefer
the latter.

Did you know those security features were
extensively tested for performance, with many
peoples involved?
See: https://github.com/pid1/test-sec-flags/wiki

It's 2017, security doesn't mean unoptimized.
There was attempt to bring in more optimizations
already used in Clearlinux project like pgo and
lto to makepkg but it's still on sidelines due to
lack of time from devs.
See
https://aur.archlinux.org/packages/makepkg-optimize2/

> On 20 April 2017 at 10:32:32,  Jelle van der Waa
wrote:
> PIE is blocked by upstream because of this bug
iirc. [1]
> [1]
https://sourceware.org/bugzilla/show_bug.cgi?id=21090

Did you know this bug was reported by concerned
user because dev hadn't time for it for a half of
year? Plus nobody ever explained why minor bug in
testsuite should be a blocker here. Also there are
more security flags to be enabled, trivial to add
and blocked only by lack of time/lack of will,
even when other devs explicitly asked for this.

> On 20 April 2017 at 10:43:03,  David C. Rankin
wrote:
> Taking the needed time to git it done correctly
the first time is NOT an
> indication of poor health -- just the opposite.
I would rather have packages
> stay in testing an additional 30 days and have
all problems addressed than
> have it called "good enough" in some arbitrary
rush that results in more
> problems and bug reports down the line.

I agree with the above but it's not the case here.
Packages doesn't stay in testing for extended
period because actual problems are resolved but
because everyone who did his/her job has to wait
for someone who didn't. See
https://www.archlinux.org/todo/openssl-rebuild-take-2/
. Everything is done except one package and
nothing changed for weeks.

It's not about blaming anyone because I believe
everybody do what they can. It's about finding a
way to help those who struggle. When some users
are asking about how they can help, answering WE
DON'T NEED HELP isn't very appropriate. Even if
you don't care at all about it please don't try to
discourage those who care.
Reply | Threaded
Open this post in threaded view
|

Re: arch health

Ralf Mardorf-4
On Thu, 20 Apr 2017 13:14:08 +0300, Francisco Barbee wrote:
>There was attempt to bring in more optimizations
>already used in Clearlinux project like pgo and
>lto to makepkg but it's still on sidelines due to
>lack of time from devs.

Hi,

are you in a hurry?

IMO it's unhealthy to be in a hurry, apart from this seemingly not
everybody needs those security features.

Arch isn't ill, there seems to be no foreseeable risk that Arch
could become ill.

If somebody should really experience some illness, then please don't be
vague, post a pointer to the illness.

I only claim that I don't experience illness and that my impression is,
that Arch is distinctly healthy. In my experience more healthy, than any
other distro I experience/experienced.

YMMV!

Imagine everybody who wants something, Arch doesn't provide, would
argue with being "a little concerned about arch's overall health", to
get it into Arch.

Regards,
Ralf

Regards,
Ralf
Reply | Threaded
Open this post in threaded view
|

Re: arch health

arch general mailing list-2
 > On 20 April 2017 at 14:07:54, Ralf Mardorf wrote:
> Hi, are you in a hurry?

Not at all. But I can imagine what feels someone
who made effort to make things better by writing
patches which are still ignored year after.

> IMO it's unhealthy to be in a hurry, apart from
this seemingly not everybody needs those security
features.

Some people need them, some don't. You can just
ignore this topic instead of writing another post
about how much you don't need it.

> Arch isn't ill, there seems to be no foreseeable
risk that Arch could become ill. If somebody
should really experience some illness, then please
don't be vague, post a pointer to the illness.

OP already mentioned few things. You can look into
https://www.archlinux.org/todo/ and
https://lists.archlinux.org/listinfo/arch-dev-public
to see how many things are need to be done. One
example is abs which wasn't maintained for years.

> I only claim that I don't experience illness and
that my impression is, that Arch is distinctly
healthy. In my experience more healthy, than any
other distro I experience/experienced.

It's not really about being healthy but being
healthier

> Imagine everybody who wants something, Arch
doesn't provide, would argue with being "a little
concerned about arch's overall health", to get it
into Arch.

Enabling those flags was already decided by devs
regardless how much you hate it. It's lack of
execution which is concern here. Maybe bigger
issue than Arch health is attitude of some people
who're trying hard to water-down any attempt to
make things better. If you don't  need any help
let others help those who need it.
Reply | Threaded
Open this post in threaded view
|

Re: arch health

arch general mailing list-2
In reply to this post by arch general mailing list-2
On 04/20/2017 06:14 AM, Francisco Barbee via arch-general wrote:
> It's 2017, security doesn't mean unoptimized. There was attempt to
> bring in more optimizations already used in Clearlinux project like
> pgo and lto to makepkg but it's still on sidelines due to lack of
> time from devs. See
> https://aur.archlinux.org/packages/makepkg-optimize2/
>

Actually, Allan said he dislikes that concept entirely and refuses to
merge it at all because:
1) CFLAGS+="-flto" should be set in makepkg.conf, not libmakepkg
2) PGO will not be a thing because "I am not adding an option to makepkg
   that does non-deterministic optimisation."
3) PGO that involves makepkg being context-sensitive between two makepkg
   runs, is not an option; use a wrapper script with multiple
   makepkg.conf's instead.

Lack of time is not the issue, in fact, Allan has reviewed *lots* of
pacman/makepkg patches, and merged lots of them, in the time he has
refused to even consider these.

> Did you know this bug was reported by concerned user because dev
> hadn't time for it for a half of year? Plus nobody ever explained why
> minor bug in testsuite should be a blocker here. Also there are more
> security flags to be enabled, trivial to add and blocked only by lack
> of time/lack of will, even when other devs explicitly asked for
> this.

Failing testsuites mean that real issues will never be discovered, which
means the whole point of running testsuites is nullified. So no, it is
not a minor bug.

> I agree with the above but it's not the case here. Packages doesn't
> stay in testing for extended period because actual problems are
> resolved but because everyone who did his/her job has to wait for
> someone who didn't. See
> https://www.archlinux.org/todo/openssl-rebuild-take-2/ . Everything
> is done except one package and nothing changed for weeks.

I don't know why openssl 1.1 is still in testing. But I do know that
merely assuming it is ready to be moved today except for that package,
is rather naive. I am going to assume that the Devs have actual reasons
for what they do.

Also, if your only point is that testing rebuilds get held up, I am not
sure what you expect us to do about it. Whatever the reason is, that can
only be fixed by the Devs, we have no influence over it in any way.

And if they are deliberately ignoring it for the lulz, your bribes won't
work; I guess we are just doomed by malice...

...

Aside: your emails seem to be wrapped in an over-aggressive manner, why
such short lines?

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: arch health

Tinu Weber
In reply to this post by arch general mailing list-2
On Thu, Apr 20, 2017 at 16:10:18 +0300, Francisco Barbee via arch-general wrote:

> > IMO it's unhealthy to be in a hurry, apart from
> this seemingly not everybody needs those security
> features.
>
> [...]
>
> > Arch isn't ill, there seems to be no foreseeable
> risk that Arch could become ill. If somebody
> should really experience some illness, then please
> don't be vague, post a pointer to the illness.
>
> [...]
>
> > I only claim that I don't experience illness and
> that my impression is, that Arch is distinctly
> healthy. In my experience more healthy, than any
> other distro I experience/experienced.
>
> [...]
>
> > Imagine everybody who wants something, Arch
> doesn't provide, would argue with being "a little
> concerned about arch's overall health", to get it
> into Arch.
Hello, this is unrelated, but it appears that your MUA or MTA screws up
the formatting of your mails, making it difficult to follow this
conversation, as I have to figure out for each line whether it's part of
a quote or not.

Also, it's hard to read, like in this example:

On Thu, Apr 20, 2017 at 13:14:08 +0300, Francisco Barbee via arch-general wrote:
> > On 20 April 2017 at 03:23:04, Ralf Mardorf wrote:
> > I would be concerned, if too many security
> features not everybody needs,
> > would become default. Why not dropping security
> features completely and
> > instead making real-time optimised features the
> default? This is a
> > rhetorical question, but actually I would prefer
> the latter.

Would you mind finding out why that is so, and try to fix that?
Thank you in advance!

Best,
Tinu

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: arch health

arch general mailing list-2
Not only could most of the concerns be successfully identified as
Other People's Problems™, pepole are still very focused on email
ettiquette. I think interpreting these two basic indicators about the
health of Arch can left as an exercise for the reader.

I'm not exactly sure what OP expected in this thread, but it's
definitely entertaining. I'll quote the original email's contents
fragmentally to spare you the whole pain.

On Thu, Apr 20, 2017 at 1:29 AM, ITwrx.org <[hidden email]> wrote:
> i'm a little concerned about arch's overall health and i was wondering
> if there's anything we can do about it.
>
> why am i concerned?

Oh come on.
You're making a case against your flawed judgment with such polemic.

> [...] I sent a message to SPI's web dev email asking about
> improvements to project's pages but i haven't heard back.

Would you mind to share the content of these emails?
Your argument seems suspicious and can't be verified as long as the
content of your scripture is in absence.

> [...blah...money...blah...]

Money definitely is an important factor. We're all using arch for the money.

cheers!
mar77i
Reply | Threaded
Open this post in threaded view
|

Re: arch health

Ralf Mardorf-4
In reply to this post by arch general mailing list-2
On Thu, 20 Apr 2017 16:10:18 +0300, Francisco Barbee wrote:
>You can just ignore this topic instead of writing another post
>about how much you don't need it.

Hi,

you completely missed my point. You ignore that in my opinion, in this
context, it's not appropriate to argue with being "a little concerned
about arch's overall health", while there is no causal indication for
even a hiccup.

I'm not necessarily against pathos (I'm not using the term "polemic").
Pathos is a very good tool when making art, but it's not good when
trying to get something into a distro, that seemingly already was
rejected.

Regards,
Ralf

--
On Thu, 20 Apr 2017 16:03:21 +0200, Martin Kühne via arch-general wrote:
>Money definitely is an important factor. We're all using arch for the
>money.

No, I'm not interested in money, my aim is world domination to satisfy
my interests and much more my compulsion neuroses. If I become leader
of the world, all distros are forced to optimize for real-time audio and
nobody is allowed to wear blue t-shirts on uneven days and no orange
t-shirts on even days.

Btw. I guess the OP wanted to point out that Arch is in a bad shape,
because "making" (not "using") Arch requires money.
Reply | Threaded
Open this post in threaded view
|

Re: arch health

arch general mailing list-2
If I may suggest a pain point: arch needs good support for
revoking packages and replacing with the previous version
if regressions are encountered. Case in point ffmpeg 3.3.
3.2.4 was fine and 2.8.11 is also fine but 3.3's muxer
corrupts files. It's not the first instance where I wished
for official revoke and replace in the index instead of
manual user intervention.
Reply | Threaded
Open this post in threaded view
|

Re: arch health

Ralf Mardorf-4
On Thu, 20 Apr 2017 17:56:19 +0000, Carsten Mattner wrote:
>If I may suggest a pain point: arch needs good support for
>revoking packages and replacing with the previous version
>if regressions are encountered.

Hi,

IIRC a few downgrades happened already, but since it's a rolling
release, IMO it's understandable, that this can't be done that easy as
for release model distros with a freeze, since there are dependency
chains and Arch tries to follows upstream when ever possible, without
patching "stable" releases from upstream. If such a hiccup happens,
we could report bugs upstream and temporarily downgrade [1], or if
necessary, rebuild packages against new dependencies using PKGBUILDs
from ABS [2].

I sometimes build with fixes from upstream, e.g. git commits, that
aren't official released as a new version, without adding "-git" or
similar to the package, so next time a stable version is released, the
upgrade happens automatically. At the moment I'm doing this for jack2
[3].

Until now nobody claimed that Arch Linux is perfect, free from any
hiccups. It's just "pathetic" or "polemic" to imply that Arch tends to
become less healthy. If an issue happens, we need to establish a
differential diagnosis, instead of careless diagnosing a disease.

There are no doubts that hiccups happen from time to time, but the
advantage of Arch is, that it does follow upstream as simple and close
as possible, so it's much easier to fix an issue temporarily on your
own, perhaps with help from the community, than it could be done for
most other distros.

The more features Arch developers would add by default, the more prone
Arch would become to make fixing it harder, if an issue does arise for
your domain/usage.

My domain is real-time audio and I prefer Arch not because it's perfect
by default, but because it's perfect to fix issues even for niches. A
lot of other distros are optimised for different usages. There are
without doubts needs, that require really long term support, where
restoring from a backup isn't an option. IMO Arch is good for a
specific target group, but maybe not good for all purposes.

Any unreasonable changes won't improve Arch. Until now we only know
that somebody guess that too many packages are outdated and some
features aren't provided, because it's presumed that Arch developers
don't have the time/money to do the work.

I'm not a developer, so I won't judge this claim. However, until now no
developer agreed that there is a lack of money and time. At least not
by such an amount, that Arch danger threatens.

I don't know, but until not several users confirm that Arch's overall
health is fishy, we should assume that Arch is in good shape.

Just my 2 Cents,
Ralf

[1]
https://aur.archlinux.org/packages/downgrade/
[2]
https://www.archlinux.org/packages/extra/x86_64/abs/
[3]
[rocketmouse@archlinux ~]$ pacman -Si jack2 | grep Ver
Version         : 1.9.10-6
[rocketmouse@archlinux ~]$ pacman -Q jack2
jack2 1.9.10.r261.g2d1d3235-1
Reply | Threaded
Open this post in threaded view
|

Re: arch health

arch general mailing list-2
In reply to this post by arch general mailing list-2
On 20-04-2017 18:56, Carsten Mattner via arch-general wrote:
> If I may suggest a pain point: arch needs good support for
> revoking packages and replacing with the previous version
> if regressions are encountered. Case in point ffmpeg 3.3.
> 3.2.4 was fine and 2.8.11 is also fine but 3.3's muxer
> corrupts files. It's not the first instance where I wished
> for official revoke and replace in the index instead of
> manual user intervention.
>

Have you reported the bug? If yes and the dev decides that it should be
reverted to a previous version there is a way to do it, see:
man pacman | grep -A1 epoch

--
Mauro Santos
12