[arch-general] Xorg Segfault on Console Switch

[Yaro Kasear]

I seem to be having an odd issue with Xorg since updating to 1.20.9.

I tend to be logged onto Xorg across more than one user based on what
kind of task I need, and switch between them via CTRL+ALT+F1/F2/F3.

Since the update this morning it seems to have started causing segfaults
on Xorg the longer I'm switched away from the console containing the
Xorg instance that crashes.

I am not even sure how to begin troubleshooting this problem. I can
usually figure this out on my own.

Process 8780 (Xorg) of user 1003 dumped core.

  Stack trace of thread 8780:
  #0  0x7ff15b192615
raise (libc.so.6 + 0x3d615)
  #1  0x7ff15b17b862
abort (libc.so.6 + 0x26862)
  #2  0x5617387ee35a
OsAbort (Xorg + 0x14a35a)
  #3  0x5617387efe21
FatalError (Xorg + 0x14be21)
  #4  0x5617387f5a79 n/a
(Xorg + 0x151a79)
  #5  0x7ff15b1926a0
__restore_rt (libc.so.6 + 0x3d6a0)
  #6  0x561738722f03 n/a
(Xorg + 0x7ef03)
  #7  0x5617387a8ed5 n/a
(Xorg + 0x104ed5)
  #8  0x5617387d67fc n/a
(Xorg + 0x1327fc)
  #9  0x5617386edbb3
mieqProcessDeviceEvent (Xorg + 0x49bb3)
  #10 0x5617386edcfc
mieqProcessInputEvents (Xorg + 0x49cfc)
  #11 0x5617388045b9
ProcessInputEvents (Xorg + 0x1605b9)
  #12 0x5617386dd8c8 n/a
(Xorg + 0x398c8)
  #13 0x7ff15b17d152
__libc_start_main (libc.so.6 + 0x28152)
  #14 0x5617386de5ae
_start (Xorg + 0x3a5ae)

Yaro



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] No login after update

[Yaro Kasear]

On 8/19/20 3:41 PM, Morten Linderud via arch-general wrote:
> https://www.archlinux.org/pacman/pacman.8.html#_handling_config_files_a_id_hcf_a
>
> Can you please read this section a few times before writing more emails?
>
I see. I was sure pacman made no comparisons at all to previous config
versions, just what is on the filesystem now and what's new.

Sorry about that, I was wrong.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] No login after update

[Yaro Kasear]

On Wed, Aug 19, 2020 at 3:32 PM Yaro Kasear  wrote:

> On Wed, Aug 19, 2020 at 3:17 PM Archange  wrote:
>
>>
>> Le 20/08/2020 à 00:04, Yaro Kasear a écrit :
>> > On 8/19/20 2:56 PM, Yaro Kasear wrote:
>> >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote:
>> >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu:
>> >>>> I've always questioned the wisdom of dropping a .pacnew just when the
>> >>>> file is different from the default. There's really no reason for it
>> >>>> considering any changes you made were deliberate and presumably
>> thought
>> >>>> out. The end result is pacman cluttering /etc with a default
>> >>>> configuration file whose only reason for existing is to, if it's
>> used,
>> >>>> clear settings. Why?
>> >>>>
>> >>> The .pacnew is there to indicate that something new exists, or that
>> >>> you changed
>> >>> something. Most of the time you can remove .pacnew files, but not
>> >>> always. Also,
>> >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle
>> them.
>> >>>
>> >>>> What pacman SHOULD do is compare /etc files between package versions
>> and
>> >>>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
>> >>>> reason to need a new default config file for the user to examine
>> because
>> >>>> then there's an actual indicator some meaningful change in default
>> >>>> configuration or how the package handles configs happened.
>> >>>>
>> >>> That's way beyond the scope of a package manager, and also, there's no
>> >>> way
>> >>> to tell what "DEFAULTS" (why caps?) should be.
>> >> Caps for emphasis is all.
>> >>>> All most pacnew files wind up doing is sitting there for thirty
>> seconds
>> >>>> before being deleted without anyone even opening them because they're
>> >>>> literally just what the file was before the user ALREADY changed it
>> >>>> before... because it's utterly useless to get a default config file
>> when
>> >>>> you've intentionally changed it and there's nothing in the new
>> version
>> >>>> of the package that calls for an examination of the defaults.
>> >>>>
>> >>> I don't know why you said that .pacnew sits for thirty seconds before
>> >>> being
>> >>> deleted. Are you using a hook that does this? Because nothing handles
>> >>> them
>> >>> automatically, that's the user's job. There are tools to aid in doing
>> >>> that,
>> >>> but in the end the user should know what to apply, and what to
>> discard.
>> >> I wasn't being literal about thirty seconds. Exaggerating.
>> >>> Regards,
>> >>> Giancarlo Razzolini
>> >> Yaro
>> >>
>> >>
>> > Oh, also:
>> >
>> > "That's way beyond the scope of a package manager, and also, there's no
>> > way to tell what "DEFAULTS" (why caps?) should be."
>> >
>> > Yes there is. The defaults are literally what's in the config file in
>> > the archive and not on the filesystem. How would that not be a way to
>> > determine default settings?
>> >
>> > I'm not suggesting the package manager would have to understand the
>> > settings, but it would be able to tell if the contents of that file are
>> > different from another version. (Which it obviously does already,
>> > otherwise it wouldn't know to make a pacnew file.)
>> >
>> > I can't imagine it'd be that difficult for pacman to compare checksums
>> > between files in /etc or /boot between versions of a package (If a
>> > previous version is available.) and what's on /etc and determine if it
>> > really needs to bother putting a pacnew file on the filesystem that
>> > doesn't need to be there. It's already doing some sort of check between
>> > what's in the package and what's on the filesystem already.
>> >
>> > Yaro
>>
>> pacman does this: if the *packaged file* changed between the installed
>> version and the new one, and the *installed file* is different from th

Re: [arch-general] No login after update

[Yaro Kasear]

On Wed, Aug 19, 2020 at 3:17 PM Archange  wrote:

>
> Le 20/08/2020 à 00:04, Yaro Kasear a écrit :
> > On 8/19/20 2:56 PM, Yaro Kasear wrote:
> >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote:
> >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu:
> >>>> I've always questioned the wisdom of dropping a .pacnew just when the
> >>>> file is different from the default. There's really no reason for it
> >>>> considering any changes you made were deliberate and presumably
> thought
> >>>> out. The end result is pacman cluttering /etc with a default
> >>>> configuration file whose only reason for existing is to, if it's used,
> >>>> clear settings. Why?
> >>>>
> >>> The .pacnew is there to indicate that something new exists, or that
> >>> you changed
> >>> something. Most of the time you can remove .pacnew files, but not
> >>> always. Also,
> >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle them.
> >>>
> >>>> What pacman SHOULD do is compare /etc files between package versions
> and
> >>>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
> >>>> reason to need a new default config file for the user to examine
> because
> >>>> then there's an actual indicator some meaningful change in default
> >>>> configuration or how the package handles configs happened.
> >>>>
> >>> That's way beyond the scope of a package manager, and also, there's no
> >>> way
> >>> to tell what "DEFAULTS" (why caps?) should be.
> >> Caps for emphasis is all.
> >>>> All most pacnew files wind up doing is sitting there for thirty
> seconds
> >>>> before being deleted without anyone even opening them because they're
> >>>> literally just what the file was before the user ALREADY changed it
> >>>> before... because it's utterly useless to get a default config file
> when
> >>>> you've intentionally changed it and there's nothing in the new version
> >>>> of the package that calls for an examination of the defaults.
> >>>>
> >>> I don't know why you said that .pacnew sits for thirty seconds before
> >>> being
> >>> deleted. Are you using a hook that does this? Because nothing handles
> >>> them
> >>> automatically, that's the user's job. There are tools to aid in doing
> >>> that,
> >>> but in the end the user should know what to apply, and what to discard.
> >> I wasn't being literal about thirty seconds. Exaggerating.
> >>> Regards,
> >>> Giancarlo Razzolini
> >> Yaro
> >>
> >>
> > Oh, also:
> >
> > "That's way beyond the scope of a package manager, and also, there's no
> > way to tell what "DEFAULTS" (why caps?) should be."
> >
> > Yes there is. The defaults are literally what's in the config file in
> > the archive and not on the filesystem. How would that not be a way to
> > determine default settings?
> >
> > I'm not suggesting the package manager would have to understand the
> > settings, but it would be able to tell if the contents of that file are
> > different from another version. (Which it obviously does already,
> > otherwise it wouldn't know to make a pacnew file.)
> >
> > I can't imagine it'd be that difficult for pacman to compare checksums
> > between files in /etc or /boot between versions of a package (If a
> > previous version is available.) and what's on /etc and determine if it
> > really needs to bother putting a pacnew file on the filesystem that
> > doesn't need to be there. It's already doing some sort of check between
> > what's in the package and what's on the filesystem already.
> >
> > Yaro
>
> pacman does this: if the *packaged file* changed between the installed
> version and the new one, and the *installed file* is different from the
> *packaged file*, then drop a .pacnew.
>
> I’m not sure what you want more…
>
> Bruno/Archange
>

But that is not what I am talking about.

I'm discussing what is essentially three configuration files here:

- The config in old-package.
- The config in new-package.
- The config on the filesystem.

I already know pacman compares new-package and filesystem config. It does
NOT do any

Re: [arch-general] No login after update

[Yaro Kasear]

On 8/19/20 2:56 PM, Yaro Kasear wrote:
> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote:
>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu:
>>> I've always questioned the wisdom of dropping a .pacnew just when the
>>> file is different from the default. There's really no reason for it
>>> considering any changes you made were deliberate and presumably thought
>>> out. The end result is pacman cluttering /etc with a default
>>> configuration file whose only reason for existing is to, if it's used,
>>> clear settings. Why?
>>>
>> The .pacnew is there to indicate that something new exists, or that
>> you changed
>> something. Most of the time you can remove .pacnew files, but not
>> always. Also,
>> it's only "cluttering" /etc (and /boot, btw), if you don't handle them.
>>
>>> What pacman SHOULD do is compare /etc files between package versions and
>>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
>>> reason to need a new default config file for the user to examine because
>>> then there's an actual indicator some meaningful change in default
>>> configuration or how the package handles configs happened.
>>>
>> That's way beyond the scope of a package manager, and also, there's no
>> way
>> to tell what "DEFAULTS" (why caps?) should be.
> Caps for emphasis is all.
>>> All most pacnew files wind up doing is sitting there for thirty seconds
>>> before being deleted without anyone even opening them because they're
>>> literally just what the file was before the user ALREADY changed it
>>> before... because it's utterly useless to get a default config file when
>>> you've intentionally changed it and there's nothing in the new version
>>> of the package that calls for an examination of the defaults.
>>>
>> I don't know why you said that .pacnew sits for thirty seconds before
>> being
>> deleted. Are you using a hook that does this? Because nothing handles
>> them
>> automatically, that's the user's job. There are tools to aid in doing
>> that,
>> but in the end the user should know what to apply, and what to discard.
> I wasn't being literal about thirty seconds. Exaggerating.
>> Regards,
>> Giancarlo Razzolini
> Yaro
>
>
Oh, also:

"That's way beyond the scope of a package manager, and also, there's no
way to tell what "DEFAULTS" (why caps?) should be."

Yes there is. The defaults are literally what's in the config file in
the archive and not on the filesystem. How would that not be a way to
determine default settings?

I'm not suggesting the package manager would have to understand the
settings, but it would be able to tell if the contents of that file are
different from another version. (Which it obviously does already,
otherwise it wouldn't know to make a pacnew file.)

I can't imagine it'd be that difficult for pacman to compare checksums
between files in /etc or /boot between versions of a package (If a
previous version is available.) and what's on /etc and determine if it
really needs to bother putting a pacnew file on the filesystem that
doesn't need to be there. It's already doing some sort of check between
what's in the package and what's on the filesystem already.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] No login after update

[Yaro Kasear]

On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote:
> Em agosto 19, 2020 16:37 Yaro Kasear escreveu:
>>
>> I've always questioned the wisdom of dropping a .pacnew just when the
>> file is different from the default. There's really no reason for it
>> considering any changes you made were deliberate and presumably thought
>> out. The end result is pacman cluttering /etc with a default
>> configuration file whose only reason for existing is to, if it's used,
>> clear settings. Why?
>>
>
> The .pacnew is there to indicate that something new exists, or that
> you changed
> something. Most of the time you can remove .pacnew files, but not
> always. Also,
> it's only "cluttering" /etc (and /boot, btw), if you don't handle them.
>
>> What pacman SHOULD do is compare /etc files between package versions and
>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
>> reason to need a new default config file for the user to examine because
>> then there's an actual indicator some meaningful change in default
>> configuration or how the package handles configs happened.
>>
>
> That's way beyond the scope of a package manager, and also, there's no
> way
> to tell what "DEFAULTS" (why caps?) should be.
Caps for emphasis is all.
>
>> All most pacnew files wind up doing is sitting there for thirty seconds
>> before being deleted without anyone even opening them because they're
>> literally just what the file was before the user ALREADY changed it
>> before... because it's utterly useless to get a default config file when
>> you've intentionally changed it and there's nothing in the new version
>> of the package that calls for an examination of the defaults.
>>
>
> I don't know why you said that .pacnew sits for thirty seconds before
> being
> deleted. Are you using a hook that does this? Because nothing handles
> them
> automatically, that's the user's job. There are tools to aid in doing
> that,
> but in the end the user should know what to apply, and what to discard.
I wasn't being literal about thirty seconds. Exaggerating.
>
> Regards,
> Giancarlo Razzolini

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] No login after update

[Yaro Kasear]

On 8/19/20 2:13 PM, Giancarlo Razzolini via arch-general wrote:
> Em agosto 19, 2020 16:02 Manuel Reimer escreveu:
>> Hello,
>>
>> Some minutes ago I did a regular system update and after that decided
>> to reboot. After reboot I was unable to log into my system. After
>> fiddling a bit I rebooted to an Arch boot stick to find the following
>> message in pacman.log:
>>
>> [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login
>> installed as
>> /etc/pam.d/system-login.pacnew
>>
>
> The .pacnew should've been handled *before* rebooting.
>
>> As this seemed to be a candidate that may cause login problems, I
>> deleted "system-login" and moved the ".pacnew" into place.
>>
>> After reboot I'm now able to log in again...
>>
>> IMHO something like this should not happen...
>>
>> Maybe it's worth a note on the Arch homepage that it is important to
>> move this pacnew into place before reboot?
>>
>
> This only affected you and whomever else changed system-login. It's
> not news
> material. Also, if you're messing with PAM, you should be responsible
> for applying
> the new stuff, otherwise it'll break, like it did for you.
>
> Regards,
> Giancarlo Razzolini

I've always questioned the wisdom of dropping a .pacnew just when the
file is different from the default. There's really no reason for it
considering any changes you made were deliberate and presumably thought
out. The end result is pacman cluttering /etc with a default
configuration file whose only reason for existing is to, if it's used,
clear settings. Why?

What pacman SHOULD do is compare /etc files between package versions and
see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
reason to need a new default config file for the user to examine because
then there's an actual indicator some meaningful change in default
configuration or how the package handles configs happened.

All most pacnew files wind up doing is sitting there for thirty seconds
before being deleted without anyone even opening them because they're
literally just what the file was before the user ALREADY changed it
before... because it's utterly useless to get a default config file when
you've intentionally changed it and there's nothing in the new version
of the package that calls for an examination of the defaults.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Arch should be apolitical

[Yaro Kasear]

On 6/2/20 1:09 PM, Kusoneko wrote:
> On June 2, 2020 5:58:51 PM UTC, Hanipaganda via arch-general 
>  wrote:
>>
>>
>> Sent with ProtonMail Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, June 2, 2020 9:10 AM, Yaro Kasear  wrote:
>>
>>> On 6/2/20 3:49 AM, Ralf Mardorf via arch-general wrote:
>>>
>>>> On Tue, 02 Jun 2020 00:53:02 -0400, Olivier Langlois wrote:
>>>>
>>>>> https://thenationalpulse.com/
>>>>> Isn't this a right-wing propaganda media? IIUC you are so far
>>>>> the only one making a political issue out of a sincere exchange
>>>>> of thoughts, regarding an off-topic thread.
>>>> FWIW the logo has got only a single colour of the rainbow,
>>>> https://www.archlinux.org/ , is this already too much rainbow
>> colour?
>>>> Is it planned to change the colour of the logo? Can you provide a
>> link
>>>> to a fact-check prove source?
>>> The fact this user used the term "globalist" should really tell you
>> all
>>> you need to know about them. That's a conservative dog-whistle term
>> for
>>> "Jew" and is usually spewed by people who listen to garbage like Alex
>>> Jones unironically.
>>>
>>> Yaro
>> The country is burning with the fires of revolution as the proletariat
>> make their stand against a capitalist bourgeoisie power structure that
>> has systemically oppressed them for years and you are concerned about a
>> logo change? I frankly cannot imagine the privilege one must have to
>> not only believe this but also feel the confidence to express this in
>> front of others during worldwide unrest.
>
> I cannot imagine the privilege one must have to imply that a single country's 
> civil unrest somehow translates to worldwide unrest and should prevent people 
> from being concerned about their own personal issues.

Thing is, I *am* in the United States, and somehow I'm able to be both
worried about the state of things on here AND comment on something
minor. Some people seem to think you can only worry about one issue at a
time. I know it wasn't you who said it, just commenting in line with
your thinking, and that comment of theirs was just not terribly
constructive and probably a red herring.

I'm going to drop off this thread now, though.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Arch should be apolitical

[Yaro Kasear]

On 6/2/20 12:58 PM, Hanipaganda via arch-general wrote:
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, June 2, 2020 9:10 AM, Yaro Kasear  wrote:
>
>> On 6/2/20 3:49 AM, Ralf Mardorf via arch-general wrote:
>>
>>> On Tue, 02 Jun 2020 00:53:02 -0400, Olivier Langlois wrote:
>>>
>>>> https://thenationalpulse.com/
>>>> Isn't this a right-wing propaganda media? IIUC you are so far
>>>> the only one making a political issue out of a sincere exchange
>>>> of thoughts, regarding an off-topic thread.
>>> FWIW the logo has got only a single colour of the rainbow,
>>> https://www.archlinux.org/ , is this already too much rainbow colour?
>>> Is it planned to change the colour of the logo? Can you provide a link
>>> to a fact-check prove source?
>> The fact this user used the term "globalist" should really tell you all
>> you need to know about them. That's a conservative dog-whistle term for
>> "Jew" and is usually spewed by people who listen to garbage like Alex
>> Jones unironically.
>>
>> Yaro
> The country is burning with the fires of revolution as the proletariat make 
> their stand against a capitalist bourgeoisie power structure that has 
> systemically oppressed them for years and you are concerned about a logo 
> change? I frankly cannot imagine the privilege one must have to not only 
> believe this but also feel the confidence to express this in front of others 
> during worldwide unrest.

I'm not concerned about the logo change. I'm in favor of it. And the
situation in the United States (Not everyone on this list is in the US.)
is not really relevant to this discussion.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Arch should be apolitical

[Yaro Kasear]

On 6/2/20 3:49 AM, Ralf Mardorf via arch-general wrote:
> On Tue, 02 Jun 2020 00:53:02 -0400, Olivier Langlois wrote:
>> https://thenationalpulse.com/
> Isn't this a right-wing propaganda media? IIUC you are so far
> the only one making a political issue out of a sincere exchange
> of thoughts, regarding an off-topic thread.
>
> FWIW the logo has got only a single colour of the rainbow,
> https://www.archlinux.org/ , is this already too much rainbow colour?
>
> Is it planned to change the colour of the logo? Can you provide a link
> to a fact-check prove source?
>
The fact this user used the term "globalist" should really tell you all
you need to know about them. That's a conservative dog-whistle term for
"Jew" and is usually spewed by people who listen to garbage like Alex
Jones unironically.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Arch should be apolitical

[Yaro Kasear]

On 6/1/20 6:43 PM, Ricardo Band wrote:
> On June 1, 2020 11:18:50 PM UTC, Amir Fletcher via arch-general 
>  wrote:
>> Recently, the Arch reddit logo was changed to a rainbow. This is for "pride 
>> month". It is forcing a political view on all of the users who did not ask 
>> for this. 
> I'm sorry but why do you care about the damn logo? And since when has the 
> sexual identity anything to do with politics?
> It's a rainbow, not a swastika.

Agreed.

It's not like people are forced to use the logo to use Arch Linux. If
you don't like it, then just don't sit around staring at it.

Also, in the sort of places that would cause serious harm for someone to
support LGBT+ rights Arch already has a number of packages that they
would already not want people to use. Just saying.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Problem with reflector

[Yaro Kasear]

On 3/7/20 11:21 PM, Eli Schwartz via arch-general wrote:
> On 3/7/20 11:53 PM, Yaro Kasear wrote:
>>> Thanks for your reply. If I put this in a bash script, will it reset once
>>> the script is done running?
>>>
>> I suspect it will if you drop the 'export' directive and just set PATH
>> without it.
>>
>> I'd strongly recommend testing it until it works for you.
> But the "PATH" environment variable already has the export attribute on
> it, so it is exported either way.
>
> Furthermore, I'm bewildered w.r.t. what is the question/goal here? If
> you set some variable in a script, it will never modify the environment
> of the *parent process*, only the script itself, and child processes
> started by the script.
>
> Have I completely misunderstood the question?
>
If they are having trouble invoking Reflector, a simple two-line script
to change PATH just for the script and an instance of Reflector is all
they would need. I won't comment as to the unconventional setup they
have for their system, though. I personally wouldn't change my PATH like
that, but this isn't about what *I* am doing.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Problem with reflector

[Yaro Kasear]

On 3/7/20 10:51 PM, karx via arch-general wrote:
> On Sat, Mar 7, 2020, 9:59 PM Yaro Kasear  wrote:
>
>> On 3/7/20 9:53 PM, karx via arch-general wrote:
>>> On Sat, Mar 7, 2020, 9:50 PM Neven Sajko  wrote:
>>>
>>>> I have not fully understood your situation, but can you not just
>>>> change the PATH environment variable?
>>>>
>>> No. I need python for other projects, and would much rather use a version
>>> management system rather than risk messing up the system python.
>> Basically,
>>> what I am asking is, can I get reflector to work with pyenv?
>>>
>> You could just change PATH for the one terminal with an 'export
>> PATH=/usr/bin:$PATH'
>>
>> That wouldn't affect PATH for any other sessions...
>>
>> Yaro
>>
> Thanks for your reply. If I put this in a bash script, will it reset once
> the script is done running?
>
I suspect it will if you drop the 'export' directive and just set PATH
without it.

I'd strongly recommend testing it until it works for you.

Yaro

Re: [arch-general] Problem with reflector

[Yaro Kasear]

On 3/7/20 9:53 PM, karx via arch-general wrote:
> On Sat, Mar 7, 2020, 9:50 PM Neven Sajko  wrote:
>
>> I have not fully understood your situation, but can you not just
>> change the PATH environment variable?
>>
> No. I need python for other projects, and would much rather use a version
> management system rather than risk messing up the system python. Basically,
> what I am asking is, can I get reflector to work with pyenv?
>
You could just change PATH for the one terminal with an 'export
PATH=/usr/bin:$PATH'

That wouldn't affect PATH for any other sessions...

Yaro

Re: [arch-general] Package guidelines 📦

[Yaro Kasear]

On 10/14/19 3:59 PM, Alberto Salvia Novella via arch-general wrote:
> Video-reply 

For someone who "can handle disagreement" like you claim in your video,
you sure are protesting quite a bit over it.

I also have a hard time someone is really extending a hand in good faith
with respectful, mutual discourse and productive discussion when they:

- Immediately block anyone who disagrees with them like you did three
times now at least.

- Hide like/dislike count on your videos.

- Disable comments on your videos.

It tells me you're not interested in people actually responding to your
thoughts in an intellectually honest way. I can handle disagreement too,
but I don't have time for people whose approach to criticism,
constructive or no, is intellectual dishonesty.

You're not asking for respect, you're asking for people to just accept
what you say. That's not the same thing. Respect means you can take
disagreement without blocking them or posting a Youtube video that's one
half boring and one half petulant whining about your treatment.

Yaro

Re: [arch-general] Package guidelines 📦

[Yaro Kasear]

On 10/14/19 10:41 AM, Alberto Salvia Novella via arch-general wrote:
> As said, blocked the latest three.
>
> We can either have a constructive conversation or it's over, that
> simple. Make your choice.
>
Blocking people who respond negatively to your proposal is a great way
to get people to universally hate your ideas. Especially when one of the
people you block is a TU who explains why your ideas won't be followed.

If you can't handle that, you're in the wrong place. Though as other
users have already pointed out, it looks like your proposal was a thread
going nowhere from the start.

Your proposal has little rationale given to justify your ideas, at least
one of your ideas already conflicts with existing guidelines, and one of
your ideas is startlingly bad security practice nobody should follow.

Yaro

Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required

[Yaro Kasear]

On 10/9/19 9:39 AM, Ralf Mardorf via arch-general wrote:
> On Wed, 9 Oct 2019 10:19:38 -0400, Genes Lists via arch-general wrote:
>> On 10/9/19 10:11 AM, Tinu Weber wrote:
>>> https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/
>>>   
>> Perfect - thank you!
> IMO 'reiserfsprogs' is a good pointer for what reason to change 'base'
> makes sense ;). It's a package good for backwards compatibility, but
> probably not useful for a base install ;).
>
Heck, jfsutils. Does anyone actually use JFS outside of backwards
compatibility

support for older IBM systems? It bewilders me that it was in the
original base group,

honestly.

Yaro

Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required

[Yaro Kasear]

On 10/8/19 1:45 PM, David C. Rankin wrote:
> On 10/08/2019 01:33 PM, Eli Schwartz via arch-general wrote:
>> Because this is not about containers. There are tons of things in the
>> old base group which I don't want installed on my heavyweight X11
>> desktop which is used for media consumption.
>>
>> I don't need netct (because networkmanager is love), s-nail (unuseful in
>> practice) or vi (symlink to vim) as a baseline fact.
>>
>> I don't need cryptsetup or device-mapper if I'm not opting into an
>> encrypted filesystem, but this does not matter as I cannot get rid of
>> either one due to systemd performing shared library links to
>> libcryptsetup.so and therefore also having a depends+=('cryptsetup')
>>
>> I do not need mdadm or lvm2, because I don't use RAID or lvm, so why do
>> you think my system is unusable without it? Note: in practice, both are
>> required by libblockdev, which means if you use udisks2 you have both
>> installed anyway.
> As long at it passes the Allan test, then so be it. I do use mdadm, netctl,
> s-nail (mailx) but agree with vim as baseline. The point being no kernel? So
> now a 'base' install does not result in a running system? It seems like
> forcing the install of `base` + (a list of other packages) just to result in a
> bootable system will create more problems then it solves. At least a meta of
> 'base-legacy' would provide the same install capability. As for the argument
> advances that this was due to those looking for a container install, why not
> create a 'base-container' or 'base-minimal' and leave the traditional 'base'
> alone?
>
There are multiple kernels officially supported. Vanilla, lts, zen, hardened, 
etc.
So it probably was left out of base because they didn't want to force people to 
take the extra step of changing kernels. 

Yaro

Re: [arch-general] Bios Raid (Fake Raid) and Virtual Raid (Software Raid)

[Yaro Kasear]

On 9/3/19 7:26 PM, David C. Rankin wrote:
> On 09/02/2019 08:07 AM, Kelly Rogers via arch-general wrote:
>> Hi,
>> Can you tell me what is capable to do Arch Linux: Bios Raid (Fake Raid) and
>> Virtual Raid (Software Raid)?
>> Thank you!
> Forget fake-raid -- dmraid (though I have used it for years), just use Linux
> software RAID (mdadm). Far more flexible and a guaranteed migration path
> forward. The overhead for software raid was negligible on on single-core 486
> machines, it isn't even in the noise anymore.
>
You can do either in Linux, I believe both work with mdadm. BIOS RAID is
only worth using if you plan to share the array with another OS, though,
like Windows.

Yaro

Re: [arch-general] RAID10 + dmcrypt/LUKS + ext4: expanding?

[Yaro Kasear]

On 10/24/2017 08:53 PM, L. Rose wrote:
> Hi everyone,
>
> I want to setup a couple of drives using RAID10 with mdadm. On top of
> /dev/md0, I want to setup one large dmcrypt/LUKS encrypted ext4 volume.
> As Arch wiki reads, this seems to be possible. But what about expanding
> that volume later on? RAID#Format_the_RAID_Filesystem recommends
> calculating the stripe_width value for ext4 based on the number of data
> disks[0]. When adding a new disk, the number of data disks would
> increase by one, and expanding both the dmcrypt/LUKS and the ext4 layer
> should be possible - but what about the stripe width_value? Does it need
> to be updated? Should it be updated? Is it possible to update the
> stripe_width value afterwards?
>
> Encryption is a must for me, and having the space accessible in one big
> chunk instead of individual disks would allow more efficient usage and
> is therefore important for me. So it would be really nice to get some
> information on this. Thanks in advance!
>
> Regards,
>
> L. Rose
>
> [0]: https://wiki.archlinux.org/index.php/RAID#Example_3._RAID10.2Cfar2
As far as I can tell, the stripe size doesn't have a noticeable impact
on performance. I'd go with a sensible starting stripe size and not fuss
over the stripe size after that. I don't know if you can modify stripe
size after the fact.

Adding onto RAID 10 should be pretty simple as long as you remember you
can only add drives in multiples of 2, since you're mirroring and
striping. Depending on how your RAID 10 is set up you can use mdadm to
add the drives or, if you're using something like Intel Rapid Storage
you could use your UEFI to expand the array with perhaps a little less
confusion.

LUKS should handle the expansion just fine, though I'd recommend putting
LVM in the encrypted mapping so that you can more easily manage volumes
once the LUKS container is unlocked. This way you can have multiple
volumes under one key. LVM also readily expands and shrinks as you need,
which makes things less of a headache.

You could even do a RAID 10-like setup with LVM if I'm not mistaken. I'd
probably do it that way just to avoid the hassle of dealing with
differing RAID formats, plus mdadm isn't as friendly as LVM. I only use
RAID 10 myself because I wanted one big shared volume between Arch Linux
and Windows 10.

Conrad



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Dual boot issue, windows doesn't show up on grub

[Yaro Kasear]

I have found it sometimes helps to mount the "Microsoft Reserved" or
"Microsoft System" partition before running grub-mkconfig. The os-prober
package can be really dimwitted sometimes when it comes to doing scans on
its own like that.



On Tue, Jul 25, 2017 at 2:07 PM, Junayeed Ahnaf via arch-general <
arch-general@archlinux.org> wrote:

> Oh yes, I have that too. Forgot to add that, issued sudo os-prober
> before sudo update-grub but no luck .
>
>
> On 07/26/2017 01:06 AM, Bjoern Franke wrote:
> > Am 25.07.2017 um 21:03 schrieb Junayeed Ahnaf via arch-general:
> >> Hello ,
> >>
> >> I installed arch on my laptop which has 2 hard drives , one is ssd
> (linux is installed there, also grub), one is HDD(with windows). So, at
> boot time , I can select either hard disk or ssd and can get either windows
> or arch. Is there a way for grub to see both Linux and Windows? I tried
> sudo update-grub and  sudo grub-mkconfig -o /boot/grub/grub.cfg but they
> don't recognize windows. My windows is not uefi if that's any issue.
> >>
> >> My linux is on /dev/sdb2 and windows on /dev/sda2 if that's any concern.
> > Did you install os-prober?
> >
> > regards
> > Bjoern
>
>

Re: [arch-general] Weird reaction to pull request over at Arch Linux ARM

[Yaro Kasear]

On Fri, Jan 27, 2017 at 12:27 PM, Christopher Reimer 
wrote:

> Hello list,
>
> I'd like to get some feedback on this pull request discussion over at Arch
> Linux ARM: https://github.com/archlinuxarm/PKGBUILDs/pull/1444 (Backup:
> http://pastebin.com/x8H0mNiE)
>
> Short summary: I wanted to contribute a simple patch to enable support for
> Banana Pi hardware. I tried that a few years back and got besides some
> other concerns the answer that it cannot be added, because at this time
> there were no upstream support and I accepted that.
>
> This is no longer the case, so I thought it must be possible to add
> support now.
>
> I also noticed a few other pull request trying exactly that, which were
> instantly closed by Kevin Mihelich without any reasonable explanation.
> That's why I expected some resistance and prepared myself to
> counterargument a few of his concerns.
>
> And I think I did quite good. Good enough to make him ignore me.
>
> Why am I writing this to the Arch Linux mailing list? Well, for quite some
> time I thought Arch Linux ARM is Arch Linux. And I think there are a lot
> more out there who think so.
> Therefore I think behavior like this could hurt the overall reputation of
> Arch Linux. Especially if a future goal of Arch Linux might be ARM support
> and Kevin Mihelich somehow joins the team.
>
> Did I miss something? Do I expect too much? I don't know.
>
> Thanks
>
> Christopher Reimer
>

This really has nothing to do with the Arch community.

Arch ARM is its own project. Now, I'm not a TU or a developer, but in my
view trying to complain to an upstream project when downstream doesn't do
what a contributor wants reflects more badly on Arch's reputation.

Even if people on Arch cared, what could they even do about it? Are you
expecting the Arch developers to somehow pull some imaginary authority over
the Archlinux ARM project? That'd be even worse to Arch's reputation if
they though they could just boss around forks of Arch.

The maintainer of a project has zero obligation to take on pull requests.
Complaining to Archlinux users about it won't change it, especially when
his response to your whining on his GitHub page was reasonable.

If you don't like it, feel free to fork Archlinux ARM. Nothing's stopping
you. But stopping filling this list with nonsense and your personal
problems with the developers of projects Arch has nothing to do with.

Yaro

Re: [arch-general] Installation: How to get HDD > LUKS > GPT working in a clean way

[Yaro Kasear]

On 11/27/2016 08:18 PM, Merlin Büge wrote:

Where is /boot physically located? Can grub2 boot from LV these days?

/boot is physically located on my only storage drive in the laptop.
It's not a seperate partition, just on the Btrfs filesystem.



Can grub2 boot from LV these days?

I don't know (nor do I need).


Just to answer: Yes, grub2 can boot from LVM and LUKS. UEFI typically 
requires an open boot partition, but that could just be used to launch 
grub2 which could in turn read things from an encrypted logical volume.


My current computer is a legacy BIOS system (Ugh, I prefer UEFI.) so I 
can put the whole thing in LVM/LUKS no issues, since BIOS doesn't use a 
system partition. Arch's wiki should provide adequate instructions, I 
believe.




Regards

Re: [arch-general] Installation: How to get HDD > LUKS > GPT working in a clean way

[Yaro Kasear]

On 11/27/2016 08:09 PM, Merlin Büge wrote:

Hi Yaro,


thanks for your answer!



I'd set up two partitions: Your EFI system partition and the LUKS
container. Then inside LUKS, format the whole thing as LVM and then set
up from there, rather than make the LUKS container another GPT "disk."
Then you just use the crypt and lvm2 hooks.

I have no EFI system partition because I don't need one.



My mistake. I assumed you had a typical UEFI setup, which would require one.


You should only really use partition tables on a physical disk, in my
opinion, not a LUKS container.

The reason for this is that LVM works with a lot more flexibility and is
more readily automated than trying to get the system to re-read
partition tables.

Hm. I can see your points. But I don't need the flexibility LVM provides,
I have enough flexibility through Btrfs.
And yeah, it's readily automated, and that's indeed practical for many
people. Personally, I'd rather modify the start-up process a tiny bit
so that GPT inside LUKS gets parsed. I just try to strip off unnecessary
'overhead' / layers of my system.

Okay, then.

Here's my opinion on this approach.

If you have 8 GiB or more and not hibernating, don't bother with swap, 
it'd be a waste of disk space. In that case you could just put a btrfs 
volume straight on the LUKS container without the GPT. Problem solved as 
you don't need any more volume management than opening LUKS containers.


Otherwise WITH swap: Unfortunately btrfs (still) doesn't support swap 
files properly, otherwise I'd suggest using them. You can write a custom 
hook. Unless you plan to share it, I'd make it a dead simple shell 
script that simply reruns the command to scan for added GPT partitions 
for your specific setup. Make sure you have a setup hook that gets the 
dependencies in there.


Personally, I still think you should just use LVM, for the simple reason 
you're having trouble with GPT, which is not meant for being used like 
this, since it can work as a more flexible "partition table" inside the 
LUKS container and is better supported all around. btrfs really doesn't 
act as a good replacement for logical volumes, in my experience. Having 
something with more features than you need is better than trying to 
coerce something into working ways it's not really intended.





If you were on a system where you could add disks [...]

Since it's on my laptop, I don't need that functionality :)


Best Regards,

Merlin

Re: [arch-general] Installation: How to get HDD > LUKS > GPT working in a clean way

[Yaro Kasear]

On 11/27/2016 09:48 AM, Merlin Büge wrote:

Hey everybody!


I'm currently installing Arch on my laptop (Thinkpad T400), and have decided
for a rather unusual partition scheme: A single LUKS container directly on
the disk (SSD) with a GPT partition table and two partitions inside it: one for
SWAP, the other one for the system and everyting else, formatted with Btrfs.

The laptop runs libreboot, so I have GRUB2 as a payload inside the flash chip
which I use to decrypt the LUKS container and load a GRUB configfile
located at /boot/grub/grub.cfg (generated by grub-mkconfig). This works fine.


While experimenting with GPT inside LUKS before the installation I've noticed
two issues, with at least one of them being present also after installation:

First, after unlocking the LUKS containter the two GPT partitions don't become
visible to the kernel automatically. I have to manually do
   partprobe /dev/mapper/
to inform the kernel about the two new partitions. partprobe is part of parted.
My idea was to create a custom hook just after the 'encrypt' hook, which would
simply run the above command. I tested this and it seems to work.

Question:
Is there an even simpler solution to that problem? For example an alternative
to partprobe which is already in 'base'?


The second issue was that I could not (after unmounting the Btrfs partition and
deactivating the swap partition of course) directly close the LUKS mapping via
   cryptsetup luksClose 
It gave me:
   device-mapper: remove ioctl on  failed: Device or resource busy
   [...]
   device-mapper: remove ioctl on  failed: Device or resource busy
   Device  is still in use.

Instead, I had to remove the partition mappings first via
   dmsetup remove 1 2
This was getting me rid of the aforementioned error messages.

As expected, I get these error messages also during system shutdown -- but only
whith the shutdown hook in initramfs. Without it, I presume the system does not
even try to close the LUKS container (which would make sense, since there is no
initramfs created by default for shutdown afaik), therefore also resulting in
no error messages being shown.

What could I do about this?
I'd like to have my system closing the LUKS container correctly -- therefore I
need to remove the partition mappings before that.


I've read a lot in the last days and weeks about Btrfs, SSDs, coreboot, etc. to
make sure I don't run into many issues. Though these two don't come unexpected,
I don't know how to solve the latter one, because systemd shutdown and shutdown
initramfs are still a little miracle to me...

I'd really appreciate any help!

This is all on an up-to-date vanilla 4.8.10-1-ARCH.
I attached two shutdown logs with debugging enabled: one with and one without
the shutdown hook applied. They look very similar though. (I made sure to reboot
twice after building the initramfs before taking the shutdown log.)
My HOOKS array is:
   HOOKS="base udev autodetect modconf block keyboard keymap encrypt pp \
   filesystems fsck shutdown"
(pp being the hook which runs partprobe against the mapped LUKS container)


Best Regards,

Merlin



Hi Merlin,

I'd set up two partitions: Your EFI system partition and the LUKS 
container. Then inside LUKS, format the whole thing as LVM and then set 
up from there, rather than make the LUKS container another GPT "disk." 
Then you just use the crypt and lvm2 hooks.


You should only really use partition tables on a physical disk, in my 
opinion, not a LUKS container.


The reason for this is that LVM works with a lot more flexibility and is 
more readily automated than trying to get the system to re-read 
partition tables.


If you were on a system where you could add disks, I'd even suggest 
reversing it: LVM on the metal and LUKS on a logical volume spanning the 
whole VG, that way you could grow the whole thing across multiple disks 
pretty easily without having to make any dramatic changes. I know btrfs 
can do multiple disks, but I've always preferred how LVM does it, honestly.


Yaro

Re: [arch-general] Opinions on PowerShell?

[Yaro Kasear]

Consider also that getting PowerShell doesn't solve the "how do I" 
problem. People who don't know PS would still have to look up how to do 
the same thing on there. If you're already familiar with Linux, and 
chances are you are if you're using Archlinux, then PowerShell won't 
solve any problems for you in almost every case.


It's neat that PowerShell is ported now, but I do scratch my head and 
wonder what niche it will fill that would merit anything more than 
placement on the AUR.


Conrad

On Fri, Aug 19, 2016 at 4:33 PM, Ralf Mardorf  
wrote:

www.my-favoured-search-engine.com

Search term:

  linux shell how to do this and that

If you don't know how to find the size and name of the three largest
files in a directory, but only of those files that have a size value
that is a prime number in MiB and a file name that does contain the
letters "a" and "f", but does not include the numbers "3" and "6", you
more likely will find hints how to do this by common used Linux and 
BSD

tools, than hints how to do this with a Microsoft shell.

This is not an argument pro or con PowerShell. I don't care
if it is in a repo or not. I just wonder about arguing pro PowerShell
by providing examples that are solvable by either already having the
Linux knowledge or by using a search engine with the keyword Linux, to
get Linux knowledge.

Re: [arch-general] Error message with full disk encryption

[Yaro Kasear]

On Sat, 2016-02-13 at 13:47 +0100, Carsten Mattner wrote:
> On Sat, Feb 13, 2016 at 10:49 AM, PeLo L  wrote:
> > 
> > Hi,
> > 
> > 
> > I've followed the arch wiki and deployed a full disk encrypted
> > install.
> > Everything works fine and am able to boot properly into the
> > install.
> > While trying to shutdown my system, systemd displays an error
> > which says "systemd: stopped (with error)  /dev/mapper/crypt-boot".
> > 'crypt-boot' is the device mapper name for the encrypted boot
> > partition. Could someone explain this. Do I need to be concerned
> > of any data loss in the boot partition?
> 
> I've seen this on old and newly installed root-luks systems myself.
> Here it's always dm1 and I'm not sure if it's luks-root or luks-swap,
> but it looks like a bug in systemd or one of the units because this
> appeared sometime in the last 6 months or less.

I have also seen this issue come up on my system. It doesn't seem to
affect anything except causing a slightly longer shutdown time. Still,
would be good to see this fixed.

Re: [arch-general] Alternative init system proposal

[Yaro Kasear]

I still don't get what makes OpenRC so great. Doesn't it still depend
entirely on SysV Init? That ALONE makes me want to keep it off my system.
If it makes us fall back on an init system that is frankly backward and was
badly in need of replacement then I don't see why it should be considered
an alternative.

Systemd ain't perfect, but when the best alternative is something that
relIes on dated components bona fide Unix systems don't even use anymore,
then they simply aren't alternatives.
On Feb 7, 2016 11:36 PM, "Leonid Isaev" 
wrote:

> On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
> > Hypothetically, if Arch Linux was to adopt an alternative init, it's a
> > process that does not happen overnight. Through time, solutions will
> > surface. I'm not a magic lamp genie that has all the answers.
>
> Then you have to ask yourself, what defines a distribution. If you are
> going to
> bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce
> customizations
> to lots of other packages, isn't it easier to start from gentoo or alpine
> and
> maintain pacman for those distros? I am asking because you are going to
> duplicate a fair share of official repos...
>
> Cheers,
> --
> Leonid Isaev
> GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
>   C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
>

Re: [arch-general] libreoffice not work

[Yaro Kasear]

It seems like bad form to enable unstable features for a package in
[extra]. Shouldn't it be set to enable the GTK2 VCL by default?

Yaro

On Tue, 2015-10-13 at 11:51 +0800, mudongliang wrote:
> 
> On 10/13/2015 11:38 AM, Jens Adam wrote:
> > Tue, 13 Oct 2015 11:29:18 +0800
> > mudongliang :
> > 
> > > $ libreoffice
> > Have you read the note from the last update?
> > https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h
> > =packages/libreoffice-
> > fresh&id=dad0330304d72dcc0cb01b209dad0e83308bfdc0
> I have seen this url, it's great tip. I have uncommented the gtk2 in 
> /etc/profile.d/libreoffice-fresh.sh.
> 
> #export SAL_USE_VCLPLUGIN=gen
> #export SAL_USE_VCLPLUGIN=kde4
> export SAL_USE_VCLPLUGIN=gtk
> #export SAL_USE_VCLPLUGIN=gtk3
> 
> Is this right?
> > 
> > > version not matchs here.
> > What?
> > 
> > > There are no enough error tips
> > The forum is full of libreoffice threads:
> > https://bbs.archlinux.org/search.php?action=search&keywords=libreof
> > fice&author=&search_in=-1&sort_by=0&sort_dir=DESC&show_as=topics
> I don't frequently go to the forum, only subscribe the mailing list. 
> Maybe I should go there often.
> Thanks.
> 
>   - mudongliang
> > 
> > --byte
> > 
> > 
> > 
> > 

Re: [arch-general] systemd new dependencies impede using OpenRC

[Yaro Kasear]

I can't overtly fault the logic in that blog post for the most part.
However he does still basically toe the "Unix philosophy" line (Talking
about modularity and such.)

The thing that bothers me most about this document though is how he
dismisses systemd's legitimate, if not unique, features as "propaganda." He
also tends to talk about flaws in how systemd is written but doesn't seem
to explain that, go into rants about Poettering not long after dismissing
one of the common statements being "you just hate systemd because
Poeterring," etc.

I must be that rare breed of systemd supporter who actually actively
DISLIKES Poettering. When he started Pulseaudio and it started breaking
everyone's sound, he went into a mantra of "ALSA's broken" instead, despite
the fact ALSA, even standalone, worked just fine without PA. That said I
now use Pulseaudio, because once it matured it stopped breaking sound as
much. I'm not a fan of how it demands to "own" all sound on the system, but
I can get over that.

Add point 5, though, to the typical anti-systemd rants when boiled down: 5:
I hate Lennart Poeterring.

Re: [arch-general] systemd new dependencies impede using OpenRC

[Yaro Kasear]

On Jul 3, 2015 6:10 AM, "LoneVVolf"  wrote:
>
> Some general comments :
>
> - Openrc is a replacement for sysv init, not an addition.
>

OpenRC runs on SysV Init last I checked, as OpenRC is just highly polished
initscripts. How is that a replacement instead of an addition?

> - openrc has it's own equivalent of .service files, they are simpler then
systemd servicefiles.

I admit I have not looked at OpenRC service files. But systemd units are
barely even 6 lines not counting empty lines.

> - my personal opinion about openrc is that it's not mature enough yet for
majority of linux users to replace systemd

My opinion is because it stoll relies on things Linux desperately needs to
be rid of. Systemd has the advantages of both actually ridding us of SysV
Init snd ysing vsrious kernel features OpenRC simply can't do to being
initscripts.

> The majority of Arch users however should be capable enough to use it
efficiently.
>

I have no argumemt here. But I still feel systemd is the better option.

> - systemd has many good things, but also many flaws.
>

OpenRC does too. Not the least of which is that it is not actually an init
replacement. Make OpenRC an independent init system then it will be a
serious contender.

> This blog post gives the best description of systemd flaws i am aware of :
> http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html

I will look this over. But I have already seen a bunch of systemd rants
over the years snd they always boil down to the same points:

1. Unix philosophy, as if it was some sort of gospel when even most bona
fide Unix systems don't even follow it any more.
2. Feature creep, about the only legitimate gripe I have seen.
3. Blaming the decisions of other projects bad decisionmaking on systemd.
GNOME 3 is a classic example.
4. Change Is Bad (tm), usually taking the form of the commentator wanting
to cling to initscripts.

>
> LVV

Re: [arch-general] systemd new dependencies impede using OpenRC

[Yaro Kasear]

I personally prefer systemd over the alternatives. I grant there's
considerable feature creep, but the people who complain a lot either don't
offer an alternative, or the one alternative they offer is the frankly
broken system Linux had been using since the dawn of time.

I wouldn't mind some spiritual successor to systemd where its entire
purpose is to be init, without sacrificing some of the more useful/powerful
features like cgroups, concurrency, and the like. Systemd went wrong when
it started going into stuff that init itself really doesn't need to manage
on its own.

SysV Init needs to die, let's move on. OpenRC is not enough to save it.

On Thu, Jul 2, 2015 at 10:49 PM, Bardur Arantsson 
wrote:

> On 07/03/2015 12:19 AM, Daniel Micay wrote:
> >> WHAT? The opinion of users has no weight here ?!?!?!
> >
> [--snip--]
>
> Just to add a little bit to what Daniel said: Can we please calm down a
> bit here?
>
> It's not like there's no overlap between what developers want and what
> ordinary users want -- in fact there seems to be rather a lot of overlap
> given the number of users Arch has. Remember that developers are users too!
>
> (P.S. I'm not a developer/packager just an ordinary user.)
>

Re: [arch-general] Problems using AUR since upgrade of pacman db version

[Yaro Kasear]

On 01/01/2015 10:41 AM, Rich wrote:



On 01/01/2015 10:27 AM, Troy Engel wrote:

On Thu, Jan 1, 2015 at 10:12 AM, Geoff  wrote:
Not intending to contradict, but rebuilding cower worked for me.  I 
used a
clean tarball and did makepackage --skipinteg (see the discussion 
under cower

in the AUR)


Same here on multiple systems. The pacman upgrade replaced libalpm.so
from .8 to .9, you'll probably need to run 'pacman-db-upgrade', then
rebuild/reinstall cower (another thread also mentioned package-query,
which backs yaourt). If you're using pacaur there's an update for that
as well which adds the prevent-as-root check to align with the new
pacman 4.2 restriction.

hth,
-te


The procedure described here, 
https://aur.archlinux.org/packages/package-query/ worked for package 
-query and pkgbrowser.


yaourt users will need to rebuild package-query as well, even though 
yaourt itself is a shell wrapper.

Re: [arch-general] bacman failed to set file flags bsdtar error

[Yaro Kasear]

On 07/16/2014 02:50 AM, Ralf Mardorf wrote:
> What's the meaning of this [1]?
>
> Regards,
> Ralf
>
> [1]
> $ bacman ardour
> ==> Entering fakeroot environment
> ==> Package: ardour-2.8.16-1
>   -> Copying package files...
> etc/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/bin/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/lib/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/applications/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/cs/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/de/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/el/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/es/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/eu/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/fr/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/it/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/pl/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/pt/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/ru/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
> usr/share/locale/sv/LC_MESSAGES/: Failed to set file flags
> bsdtar: Error exit delayed from previous errors.
>   -> Generating .PKGINFO metadata...
>   -> Generating the package...
> ==> Done.

Wild guess? This needs to be run with root priviliges, such as through sudo.

Conrad

Re: [arch-general] Troubles with ALSA

[Yaro Kasear]

On 12/31/2012 11:07 AM, Jack Stanek wrote:

Hello all,
I've been having problems with ALSA recently. Whenever I reboot my computer or 
wake it up from sleep, ALSA sets the volume of the speakers (and only the 
speakers) to zero. The headphones and master volume remain normal, but no sound 
will come from the speakers until I manually go into alsamixer and turn up the 
speaker's individual volume. I have an Intel integrated audio card, the 82801H 
HD Audio Controller.
This only started recently and I am at a loss as to what is going on. Any help 
would be greatly appreciated.
Many thanks,
J. Stanek
I believe you have to use the command "alsactl store" as root. Your 
volume levels are not usually automatically saved.

Re: [arch-general] Archlinux is for everyone

[Yaro Kasear]

On Saturday, July 09, 2011 01:11:22 PM Kyle wrote:
> Apple devices stopped looking appealing to me when people around me
> started getting them and I found out how much control Apple has over
> what people do with their devices, especially i-devices, iPod, iPad,
> iPhone, etc. And now that they have brought their twisted concept of an
> app store to MacOS, they will start controlling desktops and notebooks
> in the same way most likely. Heck, even Microsoft doesn't try to take so
> much control of a computer as Apple does.
> 

(snip)

For me it was that, and the fact Apple has a ridiculous markup on products 
that bring less features and capability. I never bought into the iPhone hype, 
finding I could do more with my ancient Treo and now, my Droid. 

The macs are a disgrace. Why should mid-range PCs be priced like top-of-the-
line gaming rigs? 

> ~Kyle

Re: [arch-general] fbsplash fails to start after pacman -Syu

[Yaro Kasear]

On Tuesday, July 05, 2011 09:31:56 PM Madhurya Kakati wrote:
> Hi,
> After a recent system upgrade fbsplash fails to run during boot. However
> while shutting down i can see the splash. Its only during the start up
> that I can't see it.
> This is the /var/log/boot some days before the upgrade
> http://pastebin.com/EbdYYb32
> and this is the log after the upgrade http://pastebin.com/MkxLbRsT
> 
> Please notice the
> "/etc/rc.d/functions.d/fbsplash-extras.sh: line 780:
> /lib/splash/cache/steps_sysinit: No such file or directory"
> and
> "/etc/rc.d/functions.d/fbsplash-extras.sh: line 795:
> /lib/splash/cache/steps_sysinit: No such file or directory"
> and
> "/etc/rc.d/functions.d/fbsplash-extras.sh: line 796:
> /lib/splash/cache/steps_bootup: No such file or directory"
> errors that occur during boot(after upgrade). These didn't occur before.
> Also after booting i did ls in the /lib/splash/cache dir and found that
> the files are already there in the dir.
> Thanks.

When is the last time, as root, you ran mkinitcpio on your kernel?

Re: [arch-general] Systemd! [WAS: arch-dev-public] Welcoming Dave Reisner to the dev staff

[Yaro Kasear]

On Tuesday, June 21, 2011 07:56:25 PM Bernardo Barros wrote:
> here too :-)

+700 on this.

Re: [arch-general] Systemd! [WAS: arch-dev-public] Welcoming Dave Reisner to the dev staff

[Yaro Kasear]

On Tuesday, June 21, 2011 06:08:03 PM Thomas S Hatch wrote:
> On Tue, Jun 21, 2011 at 5:07 PM, Yaro Kasear  wrote:
> > On Tuesday, June 21, 2011 05:33:50 PM Oon-Ee Ng wrote:
> > > On Wed, Jun 22, 2011 at 4:01 AM, Dan McGee  wrote:
> > > > Please welcome Dave to our development team. He has been a frequent
> > > > contributor (and reviewer of patches!) to Pacman, has been a TU for a
> > > > little bit, and has taken initiative on a lot of
> > > > initscripts/mkinitcpio/systemd type stuff. I think I've given him all
> > > > the right permissions and such, and signed him up for the relevant
> > > > mailing lists.
> > > > 
> > > > -Dan
> > > 
> > > Systemd to come? =)
> > 
> > Having given systemd a try, I hope not. For some reason it wouldn't make
> > sure
> > my /home was mounted. I can't count on that.
> 
> systemd is awesome, but I think the core should stay as lean as possible.
> In the future systemd may replace the systemV stuff, but for the time
> being I think there is little motivation to add it by default, Keep It
> Simple Silly

I also agree with this, but I wanted to avoid saying it lest we get into 
another debate about systemd on here. But yes, systemd does seem to go against 
the grain of the UNIX Philosophy and the Arch Way.

Re: [arch-general] Systemd! [WAS: arch-dev-public] Welcoming Dave Reisner to the dev staff

[Yaro Kasear]

On Tuesday, June 21, 2011 05:33:50 PM Oon-Ee Ng wrote:
> On Wed, Jun 22, 2011 at 4:01 AM, Dan McGee  wrote:
> > Please welcome Dave to our development team. He has been a frequent
> > contributor (and reviewer of patches!) to Pacman, has been a TU for a
> > little bit, and has taken initiative on a lot of
> > initscripts/mkinitcpio/systemd type stuff. I think I've given him all
> > the right permissions and such, and signed him up for the relevant
> > mailing lists.
> > 
> > -Dan
> 
> Systemd to come? =)

Having given systemd a try, I hope not. For some reason it wouldn't make sure 
my /home was mounted. I can't count on that.

Re: [arch-general] netcfg 2.6 release

[Yaro Kasear]

On Sunday, June 19, 2011 04:23:45 PM Rémy Oudompheng wrote:
> Hello,
> 
> netcfg 2.6 has been released and pushed in [testing].
> 
> The following features has been added since the last release:
> - add support for IPv6 configuration (FS#18699)
> - add support for static routes configuration (FS#18700)
> - add support for creating tun/tap interfaces (FS#15049)
> - add configuration file /etc/conf.d/netcfg for net-auto-wireless
> - add support for restricting automatic startup of profiles (FS#23169)
> - bridge: add support for several brctl options (FS#16625)
> - wireless: add support for explicit BSSID (FS#24582)
> - wireless: add support for ad-hoc connections (FS#19683)
> - wireless: no longer require wireless_tools to work
> - use /run instead of /var/run
> - drops hard dependency on net-tools package
> - drops hard dependency on wireless_tools package
> 
> Most importantly:
> - netcfg no longer puts no files in /run (dhcpcd still puts files there)
> - netcfg only depends on iproute2 and dhcpcd : wpa_supplicant is
> optional (required for wireless), wpa_actiond, ifplugd are required
> for net-auto* scripts
> - net-tools, wireless_tools are needed if you use legacy options
> IFOPTS and IWCONFIG, but this is strongly discouraged
> - /etc/conf.d/netcfg is a new configuration file, currently only used
> by net-auto-wireless: it is used to configure the name of the wireless
> interface you want to use (also possible in /etc/rc.conf, but
> discouraged), and to configure a list of preferred networks you want
> wpa_actiond to manage (FS#23169)
> - IPv6 is supported: no address configuration (even
> auto-configuration) will be done unless you say IP6=something in your
> profile. See the examples to see how it works
> - dhclient is needed if you want to support DHCPv6: this is expected
> to be an uncommon case, since auto-configuration exists.
> - netcfg can create tun/tap interfaces: it currently does not do
> anything with these (FS#15049)
> 
> Regards,

I'd like a minor clarification here... I've never seen a directory called run 
on /. Is netcfg expected to create that? Does the FHS support that?

Re: [arch-general] weird problem

[Yaro Kasear]

On Sunday, June 19, 2011 11:59:00 AM Madhurya Kakati wrote:
> On 06/19/2011 10:13 PM, Mauro Santos wrote:
> > Really silly questions:
> > - Are you using any repos other than [core], [extra], [community] and
> > [multilib]?
> > - Are you using any pacman wrappers?
> > 
> > I'm asking because pacman can't find anything to do with catalyst here
> > and I'm using all the above mentioned repos so I don't see how using the
> > official repos could cause that. If you are using other repos (or pacman
> > wrappers, that as far as I know are not supported) you should know what
> > you are doing so you how know how to deal with these kind of conflicts
> > and possible breakage that might happen.
> 
> Yes I am using catalyst repo.
> I use yaourt but thats not a pacman wrapper I guess.

yaourt is a pacman wrapper. Specifically it's a pacman/abs/aur/makepkg 
wrapper.

Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)

[Yaro Kasear]

On Saturday, June 18, 2011 04:57:07 AM Richard Schütz wrote:
> Am 18.06.2011 11:29, schrieb Martti Kühne:
> > On Sat, Jun 18, 2011 at 10:03 AM, Richard Schütz  
wrote:
> >> Am 18.06.2011 09:08, schrieb Dan Vratil:
> >> I don't think so. Epiphany is based on WebKit these days. And because I
> >> can trigger the bug in EOG (Eye of GNOME) it doesn't look like a
> >> browser problem for me at all.
> >> 
> >> Perhaps it is a problem of GTK together with nvidia 275.09.07. I tried
> >> feh (a simple X11 image viewer that doesn't use GTK or Qt) and it works
> >> fine without flickering, artifacts or something else strange.
> >> 
> >> --
> >> Regards,
> >> Richard Schütz
> > 
> > Update, I also see anything but the picture when the bug occurs,
> > namely random garbage. I can confirm that feh, launched the regular
> > way does not trigger the bug, although, also I have to confirm that
> > display (imagemagick-6.6.9.8-1) actually does trigger the bug.
> > Actually my guess is feh restricts itself to become larger than the
> > screen's resolution (which is smaller than 2047 here) and thus is just
> > not storing the full resolution image in video memory. I just managed
> > to something like trigger the bug, X hang for about 4 seconds here and
> > will display some garbage, with
> > 
> > $ feh --geometry 2047x1529 nvbugy7cd.jpg
> > 
> > heh, after trying this several times, the hang disappears. Might this
> > be related to caching?
> > 
> > cheers!
> 
> Yes, you are right: display crashed my X server right now. So this seems
> to be even unrelated to the toolkit.

Okay, so, has anyone filed a bug report with nVidia?

Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)

[Yaro Kasear]

On Friday, June 17, 2011 05:35:06 PM Martti Kühne wrote:
> 
> 
> >>> Are we sure ths is a bug with the nVidia driver? Can someone load that
> >>> image
> >>> who isn't using it?
> 
> confirming display screwage with firefox on an onboard nvidia chip. nasty.
> 02:00.0 VGA compatible controller: nVidia Corporation C77 [GeForce
> 8200] (rev a2)
> 
> cheers!

Unfortunately I can confirm, though X didn't crash or flicker. What I saw was 
visual data from everything else *but* the image.

I hope that might help with a bug report to nVidia besides "flicker and 
crash."

Using latest nVidia driver with a GeForec GT 240.

Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)

[Yaro Kasear]

On Friday, June 17, 2011 04:10:01 PM Richard Schütz wrote:
> The new driver really seems to have a major problem. I figured out that
> you just need an image with 2047px width to screw up the driver.
> 
> 
> ATTENTION: This can crash your X server and corrupt memory!
> 
> Example: [1], an otherwise harmless picture. Every picture with the same
> width will work, too. I could trigger the bug at least with Firefox,
> Midori, Epiphany and EOG. It looks like some applications like Chromium
> alter the size, so they don't trigger it.
> 
> 
> [1] http://www.abload.de/img/nvbugy7cd.jpg

Are we sure ths is a bug with the nVidia driver? Can someone load that image 
who isn't using it?

Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)

[Yaro Kasear]

On Friday, June 17, 2011 12:55:01 PM Ionut Biru wrote:
> On 06/17/2011 08:46 PM, Pico Geyer wrote:
> > Hi all,
> > 
> > As the title of this email suggests I'm having trouble with the new
> > Nvidia driver.
> > I've attached my Xorg log, as I'm sure that there are a log of people
> > who understand the ouput better than I do.
> 
> attachments doesn't work on this list
> 
> > I've had to revert to the previous driver (270.41.19-3) to get my
> > system up and running again.
> > What seems odd to me from the log is that it doesn't even try to load
> > the nvidia driver.
> 
> if it doesn't load the driver it means you don't use our xorg-server.
> 
> for 275.09.07 i dropped the configuration that comes with it because now
> is loaded by xorg-server
> 
> !next

Would be nice if you could actually be specific about your problem. Is Xorg 
not working? Is it freezing? Also, no attachments on here.

Re: [arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)

[Yaro Kasear]

On Friday, June 10, 2011 23:36:18 C Anthony Risinger wrote:
> On Fri, Jun 10, 2011 at 2:44 PM, Mauro Santos
> 
>  wrote:
> > Arch users have lived without the last good known kernel so far and
> > without an -lts kernel until recently.
> 
> this applies to technology in general -- we don't need any of it, but
> forward we move nonetheless.
> 
> > IMHO it is a lot more advisable
> > to have an install cd/usb, or even better, a custom install in some
> > external media that can be used to boot the system in case something
> > goes wrong or in case of emergency. Then you can just chroot into the
> > broken install and fix the problem or tell pacman where the root and
> > cache are located and fix things.
> 
> why is that simpler/advisable?  now you need to mount everything
> properly by hand else things like autodetection fail in mkinitcpio,
> etc.  i don't think it's hard to recover, and i would never have any
> of these issues, but i think a *real* recovery shell is not a bad idea
> ... why add more work for me the human when the machine could get me
> 95% the way there?  and offer some options even?
> 
> On Fri, Jun 10, 2011 at 7:45 PM, Joe(theWordy)Philbrook  
wrote:
> > The only reason to even consider keeping an old kernel around with Arch
> > was just in case the new kernel is effectively borked... (possibly due
> > to a hardware incompatibility...) And if I remember right, you said
> > something about this not working if the new kernel can't boot...
> 
> you wouldn't want to boot it past the final step, ie. you don't want
> to actually switch_root into your / device and continue the boot
> process ... however, at that moment, you have:
> 
> ) booted a good kernel
> ) have all autodetected modules available (possibly not loaded tho)
> ) ... and (IIRC) -fallback version has the full module tree if needed
> ) loaded your last configuration of initcpio hooks/etc
> ) ... which means your / is probably mounted properly, even with
> encryption and other exotics
> ) other filesystems like /dev /sys are mounted, --move'd, and ready to
> go on the new_root
> ) the whole system is poised for regular boot
> 
> ... so initcpio script *could*, if aware of your dilemma:
> 
> ) drop to shell immediately with some helpful info
> ) chroot for you into /new_root (your real system)
> ) ... maybe bind mount the module hierarchy into new_root to prevent
> accidental loading of wrong mods (if that's even possible, not sure)
> 
> ... basically just bring you 95% the way there, then let you fix it
> and reboot ... done.
> 
> On Fri, Jun 10, 2011 at 8:06 PM, Joe(theWordy)Philbrook  
wrote:
> > It would appear that on Jun 10, Robert Howard did say:
> >> Why not just copy the old kernel image, modules and initrd image
> >> somewhere by hand before you upgrade kernels.
> > 
> > That wouldn't be such a bad idea. And in fact I already do that with the
> > kernel and initrd image.
> 
> and that option will always be available ... but any trivially
> repetitive procedure requiring consistent user interaction is a poor
> solution IMO, if even worthy of being called a solution.  definitely
> an exaggeration, but why even have timed scripts a la cron, or a
> packaging system at all, when we could just remember to do stuff?  why
> not boot the system by hand :-)?  probably because these automata
> improve consistency and reduce the likelihood of errors ... we suck at
> being computers :-)
> 
> http://panko.shidler.hawaii.edu/HumanErr/ProgNorm.htm
> 
> > * CRS : "Can't Remember Sh^Htuff"
> 
> ha nice ... i've never heard anyone else say/use this (CRS acronym)
> ... my grandmother has been telling me that since i was a kid -- i
> always thought she made it up :-) -- one of those independently
> discoverable things i suppose.
> 
> On Fri, Jun 10, 2011 at 8:33 PM, Heiko Baums  wrote:
> > Am Fri, 10 Jun 2011 21:21:17 -0400
> > 
> > schrieb "Joe(theWordy)Philbrook" :
> >> Now that, Heiko, is a good idea. And one that I could actually do.
> >> I'd just have to decide which of my other Linux distributions to
> >> sacrifice to make room for it... Keeping in mind that as you say:
> >> "those cases in which an updated kernel is unbootable are very, very
> >> rare." I think I'd rather learn how to use the "pacman -U" method...
> > 
> > Would at least be less work.
> 
> how is installing another distro that you may never use easier?  you'd
> still have to go thru the whole manual recovery process.  LiveCD beats
> this any day for me -- i rarely install anything these days because my
> distro-hopping abruptly ended with Arch :-) (though i do check them
> out from time to time, or for work related things)
> 
> --
> 
> and the end of the day people just want to reinstate a useable system
> as rapidly as possible.  we can yammer on and argue that the user
> "should not be using testing then", "should be making full backups",
> "should have/know an alternate recovery plan", "should be manually
> backing up k

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Friday, June 10, 2011 05:48:57 Vic Demuzere wrote:
> On Jun 10, 2011 12:43 PM, "Martti Kühne"  wrote:
> > On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger 
> 
> wrote:
> > 
> > 
> > > what if we (optionally) stored the original images _inside_ the new
> > > one?  the new/bad kernel would boot, and via some bootloader entry eg.
> > > kernel param the new initcpio script would kexec the old kernel, with
> > > another (different) kernel param ... when the old kernel booted it
> > > would load the exact same initramfs image, except it would use an
> > > alternate tree, ie. instead of /init it would chroot to /previous and
> > > run /previous/init ...
> > 
> > eh, for the priority of known sources of error: an UPDATE image could
> > contain the NEW kernel in an alternate tree /new/init, because the OLD
> > kernel is KNOWN to boot that far...
> > 
> > Anything else would be insane.
> 
> Having multiple kernels is insane. I don't get why it's needed. There is a
> live cd to rescue your system if needed.
> 
> Vic

Another agreement from me here. Also, may I also add that a great deal of Arch 
users have /boot in a (tiny) partition to start with and can't really KEEP 
that much stuff in there? Keeping old kernels would definitely screw their 
systems up and keep them from upgrading with any ease.

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Friday, June 10, 2011 04:26:21 Robert Howard wrote:
> Why not just copy the old kernel image, modules and initrd image somewhere
> by hand before you upgrade kernels. If we try to make this automated it
> isn't going to be kiss. I used to do this way back in the day by including
> the entire kernel version in the pkgver and giving the images longer names.
> It was possible to have concurrently installed kernels. Check out how some
> of the AUR kernels manage to be the same kernel version as the official
> without causing issues.

+1 on this. If you really need the old kernel, why not make sure you back up 
the old one and its image before upgrading instead of inconveniencing other 
users and the developers for a feature only a minority even wants?

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Thursday, June 09, 2011 21:22:50 Timothy L. wrote:
> On Thu, Jun 9, 2011 at 9:25 PM, C Anthony Risinger  wrote:
> > On Jun 9, 2011 5:50 PM, "Heiko Baums"  wrote:
> > > Am Thu, 9 Jun 2011 17:36:21 -0500
> > > 
> > > schrieb C Anthony Risinger :
> > >> does this sound genius or completely insane? some insanely genius guy
> > >> once said they are only separated by a fine line ...
> > > 
> > > Sounds completely insane.
> > 
> > ook ... and ... why?
> > 
> > ) initramfs is not very big (fallback on my sys is only 13MB + 2MB kern)
> > ) keeps the whole thing in mkinitcpio
> > ) does not affect any current images and is even backward compat
> > ) small chance of absolute failure (i think :-)
> > ) only small changes to mkinitcpio, if any at all
> > ) ...
> > ) ... KISS BABY!
> > ) oh yeah and ... PROFIT!
> > 
> > im pretty sure it could be implemented as a hook (possibly 2) to the
> > current system ... this might even be the best way.  `install` hook
> > would unpack the current image to a known location (prob
> > `/lib/initcpio` somewhere), copy the kernel to the same place, and
> > then add the directory to the image (after removing the old-old image
> > if existed :-).  the real `hook` would then check for one of two
> > flags:
> > 
> > ) kexec.flag ... kexec the old kernel with the boot.flag
> > ) boot.flag ... chroot to "previous", run old hooks/mods/etc, exit
> > chroot, switch_root like normal
> > 
> > i thought it was pretty succinct ... elegant even :-)  ... with some
> > sprinkles of insanity that give it the funny but mildly enjoyable
> > aftertaste.  i don't have any free time for a couple days, but i'm
> > *pretty* sure this could be done as a hook to the current mkinitcpio
> > in a couple hours -- might take a whack at it this weekend, would be
> > useful, as i've personally mucked my boot more than once, and though i
> > can recover easily enough, i'm liking this more and more ...
> > 
> > ... though i could very well be missing something obvious, certainly
> > wouldn't be the first time ... surely someone out there reads this and
> > thinks "why not?"
> > 
> > C Anthony
> 
> Keeping the previous kernel after upgrading sounds sane to me. For the
> apprehensive, couldn't we just include a simple configuration option/check
> somewhere?
> 
> /etc/mkinitcpio.conf
> KEEP_PREVIOUS_KERNEL="yes"
> 
> I've read most of this thread but please excuse me if this has already been
> mentioned.

I'd accept that solution just so long as the default is set to "no" and not 
"yes." Most Arch people don't want old kernels. 

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Thursday, June 09, 2011 05:31:06 Paul Gideon Dann wrote:
> On Thursday 09 June 2011 00:04:09 Heiko Baums wrote:
> > schrieb Oon-Ee Ng :
> > > Such a patch would also have to copy the modules (which aren't under
> > > kernel26's 'purview'). For example, nvidia gets upgraded on a major
> > > version kernel update, the old kernel which has been renamed doesn't
> > > 'work' graphically anymore.
> 
> Yeah, I think this is starting to go beyond what can sensibly be
> implemented in the install script.  I'm putting my voice behind versioned
> kernels.  If we can define the number of old kernels to keep in rc.conf,
> that idea is actually a superset of my desire to keep a pre-upgrade
> kernel, without cluttering /boot too much.
> 

Keeping a single old kernel non-lts, clutters /boot in my opinion. 

> > The old kernel image is just to get the system
> > booted to being able to repair the system (downgrading the kernel
> > package again or whatever). The modules shouldn't be necessary for this.
> 
> I'm afraid I don't agree with this; I'd like to be able to boot to a fully-
> usable system from the pre-upgrade kernel, in case the new kernel is
> broken.
> 

The fallback image and LTS kernels cover this base well enough that we don't 
need 'pre-upgrade' anything. 

> > I'm using Arch Linux for about 4 years now and before then I was using
> > Gentoo for about 6 years. I never had one single issue with a kernel
> > upgrade particularly not such an issue which caused a boot failure.
> 
> Well, it's happened to me, and it *could* happen to you.  Better to prevent
> the situation, don't you think?
> 

Again: Purpose of fallback image and lts kernel. Jacking up /boot with dozens 
of old kernels is not a needed or desirable solution.

> > If this really happens - in the very rare cases - then it's always
> > possible to boot from a LiveCD.
> 
> This is what I've always had to do, but I don't like the idea of relying on
> always having my LiveCD handy.  LTS gets around this, but it doesn't feel
> like the "correct" solution to a failed upgrade; more of a workaround.
> 

Keeping old kernels is more of a workaround than officially supported lts 
kernels or using a LiveCD.

> > If someone is really so afraid he can easily install kernel26-lts or
> > another kernel package and, of course, he definitely shouldn't use the
> > [testing] repo.
> 
> Unfortunately, my new laptop has a buggy UEFI implementation and will only
> boot 3.0.rc1 or newer.  Who knows if my hardware will fail to boot with the
> next release?  This worries me, so I'd like to have known-to-work kernels
> lying around just in case.
> 
> Paul

Arch development should never be centered around compensating for users' 
crappy hardware. There are ways to "fix" UEFI without annoying the other users 
of Arch with cluttered boot partitions. If you want old kernels that badly, 
use lts or go to a distribution that implements this bad feature.

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Monday, June 06, 2011 11:34:53 Thomas Dziedzic wrote:
> On Mon, Jun 6, 2011 at 11:22 AM, Tavian Barnes
> 
>  wrote:
> > On 6 June 2011 10:02, KESHAV P.R.  wrote:
> >> Hi all,
> >> Since the next kernel will be 3.0 , the kernel26 naming is
> >> meaningless from the next kernel. I think this is also a good time to
> >> consider implementing versioned kernel install. Agreed arch has a
> >> policy of 1 package per software in the official repos. While this
> >> attitude is acceptable for Xorg or windows managers or even some low
> >> level utilities, problems with those can be corrected if the system
> >> can boot to a shell atleast (init 1 or 3). But if the kernel fails to
> >> boot and under the assumption that the user hdoes not have any rescue
> >> system/distro handy he/she cannot boot into the system (atleast not at
> >> that moment). Without a working kernel it is not possible to boot to a
> >> shell to run any damn command.
> >>While this topic has already been discussed at [1] the
> >> discussion was slow and has not lead to any fruitful result. This post
> >> is mainly to reach out to a larger audience and decide on how to go
> >> about since the upsteam version change provides the right time for
> >> Arch to reconsider the same. Another discussion at [2] is about
> >> removing the word kernel from the initramfs image. If in case
> >> versioned kernel proposal is accepted then the initramfs also
> >> (automatically) becomes versioned to match the kernel. Atleast Dave
> >> Reisner (falconindy) took the first step by making the change in his
> >> geninit program. I understand this might require changes in the way
> >> mkinitcpio (or geninit if at all it becomes default) and the way
> >> pacman handles different versions of same packages. Please join in.
> >> 
> >> [1] https://bugs.archlinux.org/task/16702
> >> [2] https://bugs.archlinux.org/task/18719
> >> 
> >> Regards.
> >> 
> >> keshav
> > 
> > I have kernel26-lts installed as a backup kernel, and this is all
> > that's really necessary for rolling back broken kernel updates.  I've
> > been bitten by a BTRFS bug once and rolled back with -lts no problem.
> > -1 from me on keeping multiple kernel versions installed; I really
> > like that arch doesn't keep 6 old kernels around.
> > 
> > While we're at it, +1 for calling the kernel package "linux" for version
> > 3.0.
> > 
> > --
> > Tavian Barnes
> 
> Agreed with Tavian Barnes.
> Also, don't call it "linux30" just call it "linux"

Or just 'kernel.'

And yes, -1 on multiple kernels. That was one of the more idiotic brain-
damaged practices of Ubuntu that drove me away in the first place.

Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab

[Yaro Kasear]

On Monday, June 06, 2011 07:39:03 Hector Martinez-Seara wrote:
> Thanks Tom for taking your time to answer,
> I will follow your advises to try to stabilize my system. I will try
> to downgrade my system also. If I see that this helps I will let you
> know, just in case this is a bug an not a simple speeding problem.
> Thanks again,
> Hector
> 
> On 6 June 2011 15:25, Tom Gundersen  wrote:
> > On Mon, Jun 6, 2011 at 1:49 PM, Hector Martinez-Seara  
wrote:
> >> Which information exactly do you need? I can provide you any
> >> information you may require if you explain me how to gather it (I'm
> >> not as good as most of you).
> > 
> > As far as I can tell, the problem is as described below (i.e., this is
> > not a bug), so no need to look for more info. However, if you disagree
> > with my analysis and think there really is a bug somewhere then I
> > would need to know what version of what package (probably udev or
> > initscripts) made the problem worse. To figure this out you would have
> > to downgrade the package you think it is, verify that one version
> > works fine and that the next does not (without changing anything else
> > on your system).
> > 
> >> Regarding testing. I don't want to use testing in this computer as it
> >> has some sensitive data.
> > 
> > That's ok. The packages will move to [core] soon.
> > 
> >> Regarding non mounting at boot it is rather not a good option. First,
> >> I like my disks to be check up periodically, this is fairly well done
> >> at boot. Second, This is a file server besides a desktop, so not
> >> always kde/gnome... are in use. I really think it is redundant to have
> >> to use another tool than fstab to mount disks only for the seek of
> >> speeding up the boot process.
> > 
> > Hopefully there should be some daemon out there that does not require
> > a gui, and can work with fstab (I haven't used such a thing before,
> > but I'm sure they exist). As mentioned below "systemd" certainly would
> > fix this issue, but that is a rather intrusive change, as it replaces
> > your whole init system.
> > 
> >> I really don't see the point of speeding the things up if they make
> >> everything else unstable. I honestly think that we are trying to build
> >> a house starting from the roof. First stability and then if possible
> >> speed.
> > 
> > I agree in principle that stability comes before speed. In this case
> > however, it was never stable in the first place. It just so happened
> > that it worked for you.
> > 
> > The way it works at boot is that we wait for all disk devices (and
> > other devices) to be enumerated before we start fsck'ing and mounting
> > (this is the call to "udevadm settle" you can see in rc.sysinit).
> > However, settle will not wait for your usb devices to become read.
> > This is why:
> > 
> > The problem is that we do not know how many usb devices you have
> > attached to your computer, so we don't know how many to wait for
> > before continuing (this is not the case for other kinds of devices
> > like pci). Furthermore, we don't know how long it will take to
> > enumerate all usb devices. In other words there is never a point in
> > time when we know that "all usb devices are ready".
> > 
> > Obviously, the slower your boot, the more likely you are to be "lucky"
> > and have all your usb devices ready when you need them. While I don't
> > want to randomly slow down boot for everyone on the off-chance that it
> > might make some usb devices work more often, there is a way you can do
> > this yourself:
> > 
> > You can make rc.sysinit wait an arbitrary amount of time after udev
> > has settled (how long to wait you should figure out by
> > experimentation, I would suggest adding a few seconds to what you
> > think is needed to make room for future boot speedups). If you put the
> > attached (untested) file in /etc/rc.d/functions.d/ it should do the
> > trick (for more details how this works look at the commens in
> > /etc/rc.d/functions), though you might wan to adjust the sleep time.
> > 
> > 
> > 
> > Lastly: initscripts fundamentally relies on your system being
> > statically configured with no devices coming and going. USB is
> > fundamentally dynamic, in that there is no difference between having a
> > devices plugged before boot, or plugging it after your machine is up
> > (except for timing). This cannot work well together. The only way to
> > make this reliable is to have a daemon that can deal (fsck and mount)
> > devices appearing at arbitrary points in time. systemd (from
> > community) should do this well, though it is a relatively new project,
> > so maybe you don't want to put it on your production systems quite yet
> > (it is standard in Fedora 15 though, so it can't be that bad).

There's no reason to ever, ever, put USB drives in the fstab. Look at the top 
of the fstab file, it reads "static file system information." Unless you're 
guaranteed to have your thumbdrive plugged into your computer 24/7 and never 
remove it, it d

Re: [arch-general] Future of 'kernel26'

[Yaro Kasear]

On Thursday, May 26, 2011 02:57:49 Thomas Bächler wrote:
> Am 26.05.2011 06:28, schrieb XeCycle:
> > Perhaps we may provide alternative kernels? With names like
> > these, we may get a brand new project named "Arch Operating
> > System", providing Linux, BSD, Hurd or even more as kernels,
> > and users are free to choose any one. Well, this is really
> > interesting. It'd be the first OS to provide multiple
> > kernels!
> 
> You know why nobody has done it before? Because it's not possible.

I'm sure it's possible.

I'd like to "it's bloody pointless" as my reason. We're Arch, not Debian. 
Notice how Arch officially only supports x86 and x86_64. Are people going to 
start wasting our time with requests to support PPC, SPARC, ARM, SH*, what 
have you, now?

Re: [arch-general] Future of 'kernel26'

[Yaro Kasear]

On Wednesday, May 25, 2011 11:14:55 Sander Jansen wrote:
> On Wed, May 25, 2011 at 10:53 AM, Thomas Bächler  
wrote:
> > Am 25.05.2011 17:43, schrieb jesse jaara:
> >> This is from recent kerbel mailing list post. A voice inside Torvals
> >> head is telling hin that it would be time to go for 3.0 versioning
> > 
> > Everyone, don't get too excited. The reasons for "Linux 3.0" are
> > - "the numbers are getting too big" (2.6.40)
> > - the 2.6 prefix has no meaning, and 3.0 for a release and 3.0.1 for a
> > bugfix release is shorter than 2.6.40 anf 2.6.40.1
> 
> Of course, the 3. would still have no meaning :P
> 
> Sander

I heard from several reliable sources it'll be 2.8, not 3.0.

Why not just call the package "kernel?"

Re: [arch-general] Future of 'kernel26'

[Yaro Kasear]

On Wednesday, May 25, 2011 10:20:46 Bernardo Barros wrote:
> Hi there,
> 
> There are rumors that the next version number of the Linux Kernel is
> going to be 3.0.
> Since we choosed 'kernel26' as the package name, we will have to
> modify it anyway.
> Why not just 'linux 3.0'? Just an idea.. since we have the fellow
> project 'Arch Hurd' providing 'hurd' as an alternative different
> kernel already.
> 
> Best,
> Bernardo

What rumors are these? A quick Google search shows nothing of the sort aside 
from idle speculation from years ago.

Re: [arch-general] Cannot Find Desktop in GNOME3

[Yaro Kasear]

On Monday, May 09, 2011 14:46:11 Steve Holmes wrote:
> Thanks for telling me about the desktop being gone.  I really wondered
> and am a bit surprised as I thought most people valued and used a
> desktop area quite a bit.  Yes, I opened up my home directory from the
> places and then opened the desktop folder from there.  Actually, I
> think my desktop was actually a top level folder in my places menu but
> still, not the same.  In fact, I have had launchers on the desktop in
> the past but I guess I could get them on there again if I wanted.
> It's just that the desktop was typically addressable from a single
> keystroke before.  Well whatever...
> 
> I've heard comments like that before about gnome getting less and less
> configurable; pretty soon, it will be like that other windows
> operating system out there.

Though the direction of GNOME where it's getting less and less features and 
functions isn't something Arch can fix, I agree. It's part of why I like KDE, 
which is incredibly flexible and loaded. A bit large, though.

Re: [arch-general] Cannot Find Desktop in GNOME3

[Yaro Kasear]

On Monday, May 09, 2011 12:53:55 Mauro Santos wrote:
> On 09-05-2011 18:45, Filip Filipov wrote:
> >> [...] from what i see accessibility, is broken a lot in gnome 3 and i
> >> hope they will fix that in 3.2
> > 
> > A little bit off-topic, but how often is the 'Fun statistics' [1]
> > changing .  I ask because I think it is interesting what impact  Gnome3
> > has.
> > 
> > 
> > [1] https://www.archlinux.de/?page=FunStatistics
> 
> Even more off-topic, aren't percentages supposed to add to 100%? :p

How conformist of you! :O

Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)

[Yaro Kasear]

On Saturday, May 07, 2011 22:46:29 Jonathan Beatty wrote:
> On 05/07/2011 12:33 PM, Yaro Kasear wrote:
> > and most Linux users don't give a damn if something is
> > "nonfree."
> 
> That's precisely part of the problem. You are walking blindly into
> patent traps and the destruction of a mutually beneficial community just
> for the sake of convenience.
> 
> Have fun with that.
> 
> Jonathan

Well, don't mistake "patented" for "patent poisoned." I haven't seen much of a 
case for ffmpeg being in "patent trap" territory. I personally believe 
software patents are evil, but I'm hardly going to let Stallmanist politics 
stop me from getting a functional desktop.

It's your kind of thinking that motivates the GPLv3, and it's your kind of 
thinking that's the reason the GPLv3 is so unpopular.

That said, I do tend to avoid things like Mono which are much closer to 
"patent trap" territory than ffmpeg. I also favor things like Ogg over MP3 or 
AVI. Largely also because I find things made in Mono are tripe and that Ogg 
Vorbis sounds better than MP3 and Theora is more fantastic than AVI.

A little common sense is required here. Even in the unlikely event anyone's 
actually ever going to sue over faac, it's not even going to target end users. 
Such lawsuits rarely do. Secondly, if it does, all it results in is a fork 
that removes the patented parts. That's the "magic" of FOSS. Patents can't 
really kill it.

Knowing this, I'd rather we don't drop a well-supported feature of ffmpeg just 
because some people think there *might* be a patent problem. 99.9% of patents 
that encompass FOSS projects are ignored by the patent holders, even if they 
know that the patents are "infringed." Largely because the patent holders know 
we're not exploiting their patents for our gain.

That remaining 0.1% are the kind of entities that want to see things like 
Linux dead and buried because it threatens their bottom line. It's not about 
royalties so much as it's about bullying the competition.

I'm serious, though. If we worry about "questionable patents" like you are we 
may as well chuck the majority of the packages in [core], [extra], and 
[community] into the AUR, because I promise they will ALL touch in some way on 
some patent somewhere, largely because patents, especially in the US, are 
handed out like candy.

So, rather than succumb to fear of patents and making the majority of the 
packages in Arch useless, leave them how they are and let the vocal minority 
who honestly thinks we'd get sued over faac use the abs to build a custom 
ffmpeg package that has no faac support.

In a nutshell: Quit crippling my distribution just because you're scared of 
patents just because Richard Stallman told you to be.

Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)

[Yaro Kasear]

On Saturday, May 07, 2011 12:26:54 Philipp Überbacher wrote:
> Excerpts from C Anthony Risinger's message of 2011-05-07 18:24:38 +0200:
> > On Sat, May 7, 2011 at 11:18 AM, Pierre Schmitz  
wrote:
> > > On Sat, 7 May 2011 12:05:21 -0400, Loui Chang wrote:
> > >> On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
> > >>> On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
> > >>> >Is faac support in ffmpeg causing trouble to other applications or
> > >>> >was changed for licensing reasons?
> > >>> 
> > >>> licensing. if you need faac you should use abs to recompile it
> > >> 
> > >> Gah. All this licensing stuff is starting to get really annoying.
> > >> Did Arch receive a patent license violation notice or something?
> > >> 
> > >> What is Arch's official policies when it comes to patents?
> > >> It could have some widespread implications for the distro.
> > >> 
> > >> Or the distro could purchase or otherwise aquire licenses to all
> > >> claimed patents...  ha...  ha...
> > > 
> > > Licenses and patents are different things. Some stuff cannot legally
> > > distributed and we respect that. This is usually proprietary/non-free
> > > software or packages like the Microsoft fonts. (Wasn't there also some
> > > mplayer codec pack that included some Windows dlls?)
> > > 
> > > On the other hand there are software patents valid in some countries
> > > which apply also to a completely free implementation. This means there
> > > are a bunch of packages which you are not allowed to use in the US for
> > > example even though they are licensed under e.g. the GPL.
> > 
> > a bit of a divergence ... but as i think about next-gen packaging
> > quite a bit i've often considered if a most advanced distribution
> > system would negate issues like this ... for example, what if a
> > nonfree package _knew_ it was nonfree, and therefore would only be
> > distributed from servers in countries that do not deem it an issue?
> > when user went to to sync it, their IP would be geolocated (or just a
> > setting, eg. RESIDENT) and if need be the user would be warned that
> > the package they are synced may have unknown legal implications.
> > 
> > would something like that work?
> > 
> > C Anthony
> 
> Too complicated, error prone and not really adding anything.

In my not so humble opinion, I don't think we should waste time kowtowing to 
the annoying politics of what's free or not when it comes to actual 
implementation of something. Keep the nonfree stuff there. No one is forcing 
users to have them, and most Linux users don't give a damn if something is 
"nonfree."

Re: [arch-general] Change Arch's default crond

[Yaro Kasear]

On Thursday, April 21, 2011 01:48:04 Sven-Hendrik Haase wrote:
> On 21.04.2011 08:32, Kaiting Chen wrote:
> > On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin <
> > 
> > drankina...@suddenlinkmail.com> wrote:
> >> On 04/06/2011 10:34 PM, Heiko Baums wrote:
> >>> Upstream stability makes sense. If redhat is behind cronie, then that
> >>> 
> >  seems like the logical choice.
> >>> 
> >>> Why is this logical? Is it the developer what makes a software good or
> >>> is it the features and the stability? If Redhat's cronie has less
> >>> features than fcron then fcron is the logical choice, of course.
> >>> 
> >>  You are correct. The long term stability was just my thought. Like I
> >>  said
> >> 
> >> earlier in my message -- It doesn't matter to me which cron we have --
> >> as long as we have one that works :)  I have no say in the matter, so I
> >> will, of course, defer to whatever decision you guys reach. I just want
> >> to make sure we have a cron by default :)
> > 
> > So what's the status here? I pulled cronie into [community-testing] a
> > couple of days ago and will probably merge it into [community] soon. So
> > that's the one I vote.
> > 
> > But regardless of which one we choose in my opinion the sooner we get rid
> > of dcron the better. --Kaiting.
> 
> I second this suggestion. cronie upstream isn't dead at all. cronie is a
> drop-in unlike fcron which was favored earlier. Kaiting said he would
> even be willing to become a developer to maintain this in [core] himself
> in case no other developer was  interested.
> 
> Is there anything that would keep us from making it default and also
> replace dcron?
> 
> -- Sven-Hendrik

I'm still trying to understand WHY we suddenly feel the need to replace dcron 
when its not even broken. Replacing packages with other packages purely 
because they're new is something Fedora and Ubuntu would do, I though Arch 
wasn't about arbitrarily replacing its defaults but using what was simple and 
what works.

Can someone explain to me why we think we need a new crond?

Re: [arch-general] What are people's opinions about this?

[Yaro Kasear]

On Wednesday, April 13, 2011 20:45:32 Grigorios Bouzakis wrote:
> This feature request: https://bugs.archlinux.org/task/23747
> 
> 
> Greg

Is this some sort of configuration utility for Xorg? A little background would 
be nice.

Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.

[Yaro Kasear]

On Sunday, April 10, 2011 13:13:42 Jelle van der Waa wrote:
> On Sun, 2011-04-10 at 19:40 +0300, Alper Kanat wrote:
> > s/failback/fallback/g
> > 
> > sorry for the typo..
> > 
> > ---
> > Quis custodiet ipsos custodes?
> > 
> > On Sun, Apr 10, 2011 at 19:39, Alper Kanat  wrote:
> > > Hello Fellow Archers,
> > > 
> > > Most people say that Arch is cutting edge and saving GNOME2 as 
gnome2
> > > is not the the Arch way. I know that packaging and maintaining 
GNOME2
> > > is a hard task that no devs would want to take care of and that we'll
> > > most likely be seeing unofficial repositories but what about python?
> > > Despite the upstream python is 3.x, we still have python2 for
> > > failback? So is that the Arch way?
> 
> quote from python.org
> The current production versions are Python 2.7.1 and Python 3.2.
> 
> Start with one of these versions for learning Python or if you
> want the most stability; they're both considered stable
> production releases.now.
> 
> While with GNOME it's the case that GNOME2 is dead , SO LONG LIVE
> GNOME3!!
> 
> *jelly drinks beer with his gnome friends

That was the point I was trying to make. GNOME 2 is being dropped not just 
because GNOME 3 is here, but because upstream is dropping it and 
nobody wants to go through the trouble to try to maintain something entirely 
unsupported upstream.

And, for the millionth time, when a shared library GNOME 2 uses gets a 
major version bump, there goes any semblance of compatibility it would 
have.

Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.

[Yaro Kasear]

On Sunday, April 10, 2011 12:42:57 Arthur Titeica wrote:
>  On Sun, 10 Apr 2011 21:50:41 +0200, Dennis Beekman wrote:
> > [flaming]
> > I though KDE 4 was bad and bloated and that i couldn't get any
> > worse...
> > it seems i was wrong.
> > Boy this new Gnome version is even more bloated and buggy then KDE 
4
> > wich is quite the atchievement from the gnome team...
> 
>  Please stop calling KDE bloated. As a former Windows user I find both
>  Gnome and KDE over simplistic and both lack some kind of bonding 
between
>  various parts like Windows does.
>  In that regard tough, KDE SC is doing much better than Gnome and I
>  guess that's what the SC part means.

The SC part is the KDE devs realizing that KDE has gone way beyond being 
a desktop environment and went on to be a full-scale software compendium 
and community. It's almost become the Microsoft of Linux (But in a good 
way.) in that it covers almost everything.

> 
>  What you may find bloated is the fact that the two major video card
>  makers do a terrible job in supporting their
>  over-heating-barely-2D-60euro-windows-only-cards and rely on the FOSS
>  devs to build drivers for them.

I dunno. nVidia seems to do a good job, driver-wise, for their cards on Linux. 
Keep it up to date, don't leave out new Xorg/OpenGL features. ATI's not too 
great at Linux support, unfortunately.

>  Both NVIDIA and AMD do a semi-lousy job with drivers in the Windows
>  world and I don't expect better anytime soon.

Again, I've had no issues with drivers in Windows or Linux nVidia-wise. 

>  Add this to the fact that the kernel isn't exactly desktop optimized
>  (stuff like let me move the mouse while I extract that damn 4G archive)
>  and you'll probably get what feels like a slow system.

This is largely because the kernel devs (accurately) figure that the typical 
application for Linux is more for servers and high-performance computing. 
Desktop optimization is pretty low-priority. When kernel 38 comes out (Might 
be tonight, I think.) we'll have the Wonder Patch which will make a desktop 
speedy, or so I am told.

> 
>  Now what could a DE could do in this situation? I know that kwin does
>  extensive checks in regards to video driver capabilities and maybe Gnome
>  just isn't that far on this.
> 

They're generally pretty good functionality checks, though sometimes I don;t 
like KDE to turn off my eye candy when things get slow.

>  That said, KDE SC with the free radeon driver in 2.6.38 is
>  outperforming the catalyst driver with 2.6.37 in regards to desktop
>  effects (I can't say anything about nouveau).
> 

I couldn't even get Nouveau's Gallium driver to work with OpenGL. nVidia's 
proprietary driver is still way ahead of Nouveau on this. Pretty much the 
chief feature of Nouveau is KMS for nVidia users. Personally, I'd rather have 
good OpenGL support than KMS.

>  IMHO!

My humble opinion, too.

Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.

[Yaro Kasear]

On Sunday, April 10, 2011 15:07:27 Dennis Beekman wrote:
> On 04/10/2011 03:50 PM, Jelle van der Waa wrote:
> > On Sun, 2011-04-10 at 21:50 +0200, Dennis Beekman wrote:
> >> I use linux becuase i think that windows is just to bloated to even be
> >> considered ... but lately Linux has been going in the same direction
> >> when it comes to the desktop enviroments Gnome 3&  KDE 4.
> >> 
> >> Gnome 2 was brilliant just a simple easy to use system with load off
> >> good looking features, gnome 3 however is useless in all respects as 
far
> >> as i can tell from whats in testing.
> >> 
> >> 1. You cannot change the panels anymore you stuck with the 2 given 
by
> >> gnome 3.
> >> 2. Changing themes also is inpossible.. or so it seems.
> > 
> > It's not.
> > 
> >> 3. Why do we need a system settings menu with all the options in one
> >> menu ? where are my seperate icons i love so much ? why can we 
choose
> >> wich icons or options we want ?
> >> 4. What about the people ho don't have or don't wich to use they're
> >> video hardware to run the these stupid graphics ... are we stuck with
> >> "fallback mode" wich is even more stupid and backward ?
> >> 5 Where did all the nice applets go ? and why can i not add them to 
my
> >> taskbar anymore
> >> [flaming]
> >> I though KDE 4 was bad  and bloated and that i couldn't get any 
worse...
> >> it seems i was wrong.
> >> Boy this new Gnome version is even more bloated and buggy then 
KDE 4
> >> wich is quite the atchievement from the gnome team...
> >> 
> >> Now i finnaly understand why the Ubuntu guys decided to use they're
> >> netbook unity system rather then this shit, eventhough unity sucks it
> >> better then Gnome 3 in all respects.
> >> 
> >> [/flaming]
> >> 
> >> Can we not just keeps using the old version and ignore the new version
> >> of gnome for now until they get they act together ? or hopefully decide
> >> to go back to the old interface and develop that further instead ...
> > 
> > You probably want to read more about GNOME3 and how it breaks with
> > GNOME2. This is not our discussion, but upstreams and we just 
package
> > vanilla packages. So this 'flame' post is useless.
> 
> Well it might be my imagination but it seems Desktop Enviroments on
> linux are more bloated and buggy now then Windows is.
> 
> We are being forced to use de's like openbox or xfce wich is the primary
> reason people shy away from unix/linux when changing from Windows to
> another OS.
> It just becomes to confusing and complicated from they point of view and
> they choose MAC or another Windows versions instead.
> 
> Even i as a seasoned linux user ho switched over from ubuntu to arch a
> while ago it doesn't make any sense to me why they would do this i
> tell you the amount of Gnome users in my point is view in going to halve
> if not drop any further then that.
> 
> But ofcourse it is Gnome at fault here and not ARCH but still, can we
> not keeps the latest "old" version from before the release in the nomal
> repo's until they update 3.0 a couple of times ?

GNOME 2's probably not even going to LAST that long. Once some libraries 
staart getting new releases and feature changes to them, GNOME 2's going 
to find itself simply *not* working due to a library not being what it needs.

And, as you said, it's not Arch's fault, so stop wasting inbox space with 
useless flamebait, please.

Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.

[Yaro Kasear]

It is against the Arch way when it's not even going to be actively maintained 
upstream for much longer. GNOME 2's got maybe 6-8 months at most before 
it's support is gone upstream, and Arch isn't there to act as a "historical 
archive" of old desktop environments. Especially in the likely event GNOME 2 
will stop working right when the inevitable library bumps occur after its 
support drop.

Instead of complaining at the Arch developers for doing their job, you could 
just switch to Xfce or LXDE if you want a GTK+ 2 based desktop environment. 
Though I personally think GTK+ 2 is visibly showing its age. I wish there were 
more Qt-based DE's out there, though I do think KDE is pretty good.

Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.

[Yaro Kasear]

On Sunday, April 10, 2011 14:50:41 Dennis Beekman wrote:
> I use linux becuase i think that windows is just to bloated to even be
> considered ... but lately Linux has been going in the same direction
> when it comes to the desktop enviroments Gnome 3 & KDE 4.
> 

This is all a matter of opinion. I like KDE 4 a lot. It's big, but I doubt 
there isn't a hard disk made within the last 15 years that can't fit it. It's 
definitely not bloated nearly as much as Windows is. KDE 4.6 is still 
downright lightweight compared to Windows 7.

My chief complaint against GNOME 3 is that it requires Pulse Audio.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

> Gnome 2 was brilliant just a simple easy to use system with load off
> good looking features, gnome 3 however is useless in all respects as far
> as i can tell from whats in testing.
> 

Look, if you like a simple desktop with fewer features and a more 
straightforware approach and less eye candy, all the power to you. Just don't 
assume that's what EVERYONE wants in a desktop. I like the eye candy 
and almost ridiculous amount of options and settings KDE SC 4 gives me.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

> 1. You cannot change the panels anymore you stuck with the 2 given by
> gnome 3.

You could alter the themes, get more themes. I don't know how close to 
Plasma the new GNOME desktop is, but even KDE SC 4 offered ways to 
configure its panel look and feel.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

> 2. Changing themes also is inpossible.. or so it seems.

Just sounds like you haven't figured out how to change the themes yet. 
GNOME 3 *is* a major change over GNOME 2, after all.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

> 3. Why do we need a system settings menu with all the options in one
> menu ? where are my seperate icons i love so much ? why can we choose
> wich icons or options we want ?

I don't understand this complaint. Didn't GNOME 2 also offer settings all in 
one or two menus before?

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

> 4. What about the people ho don't have or don't wich to use they're
> video hardware to run the these stupid graphics ... are we stuck with
> "fallback mode" wich is even more stupid and backward ?

I'm fairly certain that GNOME 3 doesn't force you to use visual effects. If 
you turn that off it'd likely speed right up.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

> 5 Where did all the nice applets go ? and why can i not add them to my
> taskbar anymore
> 

Aforementioned GNOME developers stripping away nice features because 
they erroneously think they confuse users.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

> [flaming]
> I though KDE 4 was bad  and bloated and that i couldn't get any worse...
> it seems i was wrong.

KDE SC 4 is only really bloated when you install all its packages. And it's 
bloat is still nowehre near comparable to Windows Vista or 7. If you can't fit 
KDE SC 4 on a hard disk even an old SMALL one, you need a new hard 
disk, because its a wonder you can fit anything on there.

Also, KDE SC 4 hasn't been nearly that bad since 4.3 came out, and it's 
pretty solid as of 4.6.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

> Boy this new Gnome version is even more bloated and buggy then KDE 4
> wich is quite the atchievement from the gnome team...
> 

This is a matter of opinion and experience. As I said. Post-KDE SC 2.3 is 
pretty stable, and bloat is overstated when it's not even clearing a GiB of 
hard disk space.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

> Now i finnaly understand why the Ubuntu guys decided to use they're
> netbook unity system rather then this shit, eventhough unity sucks it
> better then Gnome 3 in all respects.

I personally believe Ubuntu moving over to Unity was a mistake. And I fear th 
whining that will come when the planned move to Wayland happens due to it 
not having nearly as good support as Xorg. My opinion is that a lot of people 
overestimate KMS support in Linux. I would have waited a couple more years 
for KMS to mature before planning my desktop around it.

Also, we're Arch, not Ubuntu. We're not forcing you to use GNOME 3 or 
Unity. Not forcing you to use KDE SC 4, either. Instead of bitching on Arch 
general and wasting space on our inboxes, you could have just switched to 
Xfce or LXDE if you wanted a lightweight desktop environment. Or you could 

Re: [arch-general] base stuff

[Yaro Kasear]

On Saturday, April 09, 2011 12:54:23 Thomas S Hatch wrote:
> On Sat, Apr 9, 2011 at 11:49 AM, Yaro Kasear  wrote:
> > On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote:
> > > On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear  
wrote:
> > > > On Friday, April 08, 2011 14:29:34 Heiko Baums wrote:
> > > > > Am Fri, 8 Apr 2011 10:55:16 -0600
> > > > > 
> > > > > schrieb Thomas S Hatch :
> > > > > > Yaro makes many good points, I think that my recommendation
> > 
> > would
> > 
> > > > be
> > > > 
> > > > > > to allow someone to maintain support for SELinux in 
community. If
> > > > > > SELinux support is deemed something that would be a good 
idea to
> > > > 
> > > > move
> > > > 
> > > > > > to core in the future than do so, otherwise leave it in
> > > > > > community.
> > > > > 
> > > > > I'd prefer a separate [selinux] repo. So that people know what they
> > 
> > are
> > 
> > > > > doing.
> > > > > 
> > > > > I know, packages with SELinux support could and should be 
named
> > > > > something like selinux-XXX or XXX-selinux, but I think a new repo
> > 
> > would
> > 
> > > > > be better and more secure - not only from SELinux' view.
> > > > > 
> > > > > This way SELinux users can just add [selinux] to pacman.conf 
above
> > > > > [core]. For the other users it should be deactivated by default.
> > > > > 
> > > > > Heiko
> > > > 
> > > > Here's another question. Isn't it general packaging policy to not
> > > > fully support packages that have unofficial upstream patches
> > > > applied? Isn't SELinux "unofficial" to all the upstream?
> > > 
> > > SELinux has been in the vanilla kernel for quite some time, say the
> > 
> > 2.6.20
> > 
> > > ish realm, and the majority of the core utils have had SELinux support
> > > built in for years. SELinux is official upstream.
> > > 
> > > But I don't want to argue about this anymore :) I think that we have a
> > > solution, I will be putting up an SELinux third party repo for testing
> > > in the next month or two and then once we have an assurance that it 
is
> > 
> > working
> > 
> > > well we look into moving SELinux support into community.
> > > 
> > > This has been a great discussion, and I am excited to get some work
> > > done
> > 
> > on
> > 
> > > improving SELinux support on Arch!
> > > 
> > > -Thomas S Hatch
> > 
> > What about the SELinux patches for things other than the kernel? Are
> > those "official" to upstream? This is not for an argument, now I'm just
> > genuinely curious.
> 
> The vast majority are, but there are a few places where patches are 
needed,
> like in pam and ssh.
> 
> So yes, there is a "half and half" going on. Basic SELinux support works
> without patches, but adding some of the more advanced features to some 
of
> the core applications require a few patches.
> 
> -Thomas S Hatch

Great! Well, I look forward to maybe testing out your repository. Maybe I'll 
actually get SELinux working.

Re: [arch-general] base stuff

[Yaro Kasear]

On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote:
> On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear  wrote:
> > On Friday, April 08, 2011 14:29:34 Heiko Baums wrote:
> > > Am Fri, 8 Apr 2011 10:55:16 -0600
> > > 
> > > schrieb Thomas S Hatch :
> > > > Yaro makes many good points, I think that my recommendation 
would
> > 
> > be
> > 
> > > > to allow someone to maintain support for SELinux in community. If
> > > > SELinux support is deemed something that would be a good idea to
> > 
> > move
> > 
> > > > to core in the future than do so, otherwise leave it in community.
> > > 
> > > I'd prefer a separate [selinux] repo. So that people know what they are
> > > doing.
> > > 
> > > I know, packages with SELinux support could and should be named
> > > something like selinux-XXX or XXX-selinux, but I think a new repo 
would
> > > be better and more secure - not only from SELinux' view.
> > > 
> > > This way SELinux users can just add [selinux] to pacman.conf above
> > > [core]. For the other users it should be deactivated by default.
> > > 
> > > Heiko
> > 
> > Here's another question. Isn't it general packaging policy to not fully
> > support packages that have unofficial upstream patches applied? Isn't
> > SELinux "unofficial" to all the upstream?
> 
> SELinux has been in the vanilla kernel for quite some time, say the 2.6.20
> ish realm, and the majority of the core utils have had SELinux support
> built in for years. SELinux is official upstream.
> 
> But I don't want to argue about this anymore :) I think that we have a
> solution, I will be putting up an SELinux third party repo for testing in
> the next month or two and then once we have an assurance that it is 
working
> well we look into moving SELinux support into community.
> 
> This has been a great discussion, and I am excited to get some work done 
on
> improving SELinux support on Arch!
> 
> -Thomas S Hatch

What about the SELinux patches for things other than the kernel? Are those 
"official" to upstream? This is not for an argument, now I'm just genuinely 
curious.

Re: [arch-general] base stuff

[Yaro Kasear]

On Friday, April 08, 2011 14:29:34 Heiko Baums wrote:
> Am Fri, 8 Apr 2011 10:55:16 -0600
> 
> schrieb Thomas S Hatch :
> > Yaro makes many good points, I think that my recommendation would 
be
> > to allow someone to maintain support for SELinux in community. If
> > SELinux support is deemed something that would be a good idea to 
move
> > to core in the future than do so, otherwise leave it in community.
> 
> I'd prefer a separate [selinux] repo. So that people know what they are
> doing.
> 
> I know, packages with SELinux support could and should be named
> something like selinux-XXX or XXX-selinux, but I think a new repo would
> be better and more secure - not only from SELinux' view.
> 
> This way SELinux users can just add [selinux] to pacman.conf above
> [core]. For the other users it should be deactivated by default.
> 
> Heiko

Here's another question. Isn't it general packaging policy to not fully 
support packages that have unofficial upstream patches applied? Isn't 
SELinux "unofficial" to all the upstream?

Re: [arch-general] base stuff

[Yaro Kasear]

On Friday, April 08, 2011 05:43:51 Kaiting Chen wrote:
> On Fri, Apr 8, 2011 at 3:44 AM, Jelle van der Waa  wrote:
> > And on a side note, I don't like archlinux forcing users to use SELinux
> > because users should have a choice to use any MAC software they want.
> > That's why AppArmor /Tomoyo are nicer solutions cause they don't require
> > recompiling of packages -> increasing bugs/problems.
> 
> If we compile our packages with SELinux support, does that force users to
> use SELinux? I was under the impression that these changes would be
> completely benign on non-SELinux enabled systems. --Kaiting.

No, SELinux-patched tools do not force one to use SELinux. But they can 
potentially have plenty of bugs introduced by the patches. And there's the 
fact that SELinux is not necessary and there's not point in putting it in the 
default Arch install just for the minority who'll actually use it. At most, it 
should be in [core]. At the very least, [community]. I definitely see no good 
reason to make it part of the base install, though.

Re: [arch-general] base stuff

[Yaro Kasear]

> 
> So in general what is the benefits / costs for SELinux?
> 

Benefits: Probably the most effective MAC for Linux. Once it runs it's 
arguably not too hard to allow/deny certain access due to some third party 
tools simplifying things a bit. You can't deny the NSA-grade security it 
brings which the U.S. military requires AT MINIMUM for critical 
infrastructure.

Costs: Painfully overcomplicated. Painfully difficult to set up and configure. 
Requires well over half the core system to be patched to support it, 
potentially introducing bugs. There was a mondo security vulnerability a few 
years back that could actually use SELinux to grant unrestricted access to 
the system. Only a few filesystems actually have support for its attributes. 
Even its policies have to be recompiled if they have to change. Way too 
much can easily go wrong during set up without you having even the 
slightest clue how to figure out exactly what DID, turning "repairs" for 
SELinux into an almost weekend-long Google crawl.

Benefits from a base Arch perspective: I can't honestly see how this would 
benefit Arch from putting it in the base group.

Costs from a base Arch perspective: Big one being that it's entirely 
unnecessary, and base is meant to have ONLY what's needed to have a 
more or less FUNCTIONAL Linux system. Being secure is not a requirement 
of being functional. Other cost being that it would introduce an entirely new 
layer of configuration we don't need at install time, and would also guarantee 
that Arch would only be able to "officially" support the few filesystems that 
actually support SELinux's labelling.

To sum up, it's GREAT when you actually NEED the security benefits it can 
bring, otherwise, it's better to seek out AppArmor (Which I believe is 
actually defunct.) or Tomoyo (Which I can never find any information on.), or 
just leave MAC off altogether if you're not doing anything altogether mission 
or security critical. Home desktop users would probably be better off ignoring 
MAC.

Re: [arch-general] base stuff (was: Change Arch's default crond)

[Yaro Kasear]

On Wednesday, April 06, 2011 18:13:04 Grigorios Bouzakis wrote:
> Thomas S Hatch  wrote:
> > On Wed, Apr 6, 2011 at 4:16 PM, Grigorios Bouzakis 
wrote:
> >> Thomas S Hatch wrote:
> >> > I am saving the "include SELINUX support in base for a latter date"
> >> > 
> >> > my understanding though is that the stated position of Arch was "no
> >> > systemd"
> >> 
> >> s/was/is/g
> >> 
> >> That is also my understanding in regards to selinux. Although i am not
> >> familiar with "stated positions" about either.
> >> 
> >> PS. Ntp is fine application that will keep your clock synchronised.
> >> It seems to be 5 days off. :)
> > 
> > Yes the systemd topic keeps popping up, right now we don't know
> > if certain upstream changes are going to force Arch into using systemd 
or
> > not.
> 
> I dont think such a topic keeps popping up.
> In fact I dont remember reading a discussion between Arch developers 
about
> it, ever.
> I could probably go on ranting about stuff thats been shoved down users
> mouths the last years for months but its futile and a waste of time.
> 

It was a discussion that popped up here, a debate between users who felt 
replacing sysvinit was completely unneeded to those who seemed to want to 
use systemd for some useless, unneeded feature maybe less than 1% of 
Arch users were going to actually use.

> > As for adding SELinux support in base but keeping it turned off by
> > default, +1
> 
> Although this isnt a vote, mine was for no selinux at all, so its just 1.
> :)

Selinux is another unneeded thing, but even worse is that it practically 
requires a doctorate in computer science to manipulate. Can't deny its 
security, though. +1 to leaving it out of Arch, not that anyone's asking Arch 
to.

Re: [arch-general] Change Arch's default crond

[Yaro Kasear]

On Wednesday, April 06, 2011 15:27:27 Thomas Bächler wrote:
> Am 05.04.2011 09:19, schrieb Thomas S Hatch:
> > I can think of three considerations for a cron daemon:
> > 1 . Minimal - its a cron daemon, it does not need to be complex
> > 2. Active development
> > 3. Anacron functionality
> > 
> > As far as I can see this leaves us with fcron, dcron and cronie. Cronie
> > probably has the highest assurance for upstream development because 
it is
> > backed by redhat.
> > But I think that having a cron daemon as default that has issues
> > executing jobs on time and as they are defined is highly questionable.
> 
> Before the current maintainer took over dcron, we had that same
> discussion. Aaron even contacted the fcron maintainer (he posted the
> reply to arch-general or arch-dev-public, if anyone could find the link
> in the archives, please post it). The author responded that he
> considered fcron feature-complete, so didn't develop it anymore.
> However, he would fix bugs when they are reported, and I think there are
> no known bugs right now.
> 
> That said, fcron lacks /etc/cron.d/ functionality which was the most
> important argument against it. I personally don't need that and I like
> fcron a lot.
> 
> As for your conditions:
> 1) It is very small software, 1.2MB installed, and it has lots of
> features. It is by no means minimal though.
> 2) I commented on that above.
> 3) dcron has @daily, @hourly and so on. In fcron, you can use standard
> crontab entries and add &bootrun to the beginning of the line to repeat
> "missed" cronjobs.
> 
> I don't know cronie, so maybe you can elaborate more.

Losing /etc/cron.d support is a bit of a dealbreaker for me. I think that's a 
rather huge feature to leave out of a crond.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:20:17 pm Nathan Wayde wrote:
> On 23/01/11 18:13,
> hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_h
> are_h...@lavabit.com
> 
> wrote:
> >> .you're a troll and a spammer. Get the hell off my mailing list.
> > 
> > Meeku:  This attitude does not do the reputation of your o/s any good. 
> > If you don't want to use the font fine.
> 
> just so you know, your silly overly long email address alone qualifies
> you for spamming and the first mail sent by your was immediately flagged
> as such. It also doesn't help that your messages appear somewhat like it
> was written by a spammer and the you proceed to argue about it as-if
> your original mail was relevant to this ML.

I googled his e-mail. Seems he spammed the debian-user list, too.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:17:54 pm o...@deathbycomputers.co.uk wrote:
> Been lurking here for a while and I'm now really considering dropping this
> list.  Please do not feed the troll it will only make it worse.
> 
> Cani
> Sent from my BlackBerry® wireless device
> 
> -Original Message-
> From:
> hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_
> hare_h...@lavabit.com Sender: arch-general-bounces@archlinux.orgDate: Sun,
> 23 Jan 2011 13:15:59 To: General Discussion about Arch
> Linux Reply-To: General Discussion about Arch
> Linux  Subject: Re: [arch-general] Rail Model
> font for coders
> 
> > .trying to get people to use your font.spam.we're.
> 
> Meeku:  If you don't want to use the font fine.

I'll stop. Added the troll to my KMail filter. Anything he sends goes straight 
to my trash.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:15:59 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
> > .trying to get people to use your font.spam.we're.
> 
> Meeku:  If you don't want to use the font fine.

I don't want you spamming your idiot font on the mailing list, either. My 
issue isn't not wanting to use your font, its you wasting our time and mailing 
list with it.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:13:19 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
> > .you're a troll and a spammer. Get the hell off my mailing list.
> 
> Meeku:  This attitude does not do the reputation of your o/s any good.  If
> you don't want to use the font fine.

I don't want to use your font, but I don't want you wasting space on my inbox 
or on the mailing list with your spam. Stop now.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:08:59 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
> > .stop spamming the mailing list.
> 
> Meeku:  I respond to silly accusations and now I get hounded also.

It's not a silly accusation when you're doing exactly what you're accused off. 
You're spamming the mailing list trying to get people to use your font.

If by "hounding" you mean "not letting you get away with spam" then yes, 
that's what we're doing.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:05:15 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
> > Can somebody ban him?
> 
> Meeku:  Well then I question your opinion-judgement because font, coding
> and operating systems are related.  If the spam allegation is motivated by
> seeing spiritual email addresses on a public mailing list rather than
> contents or the on-topic contents are ignored, then it is not spam.

It's spam because your promoting your font on a mailing list where such a 
thing is not just rude, but very unwelcome.

> 
> I also want to research the correlation between your opinion-judgement in
> this case and the lines of evidenced based productive Arch Linux coding
> you have written first hand and I would be grateful for this statistic and
> evidence.

Stop repeating your nonsense over and over, that, too, is spam.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:03:25 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
> > I'm racist against trolls. Am I  a horrible person?
> 
> Meeku:  If the spam allegation is motivated by seeing spiritual email
> addresses on a public mailing list rather than contents or the on-topic
> contents are ignored, then it is not spam.

You're not seriously suggesting it's religious persecution?

Now I KNOW you're a troll and a spammer. Get the hell off my mailing list.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:00:55 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
> > The fact he called it racism smells of a troll to me. Trolls are worse
> > than
> > spammers.
> 
> Meeku:  No.  The person who did not wish me to participate on this mailing
> list tactically made his personal opinion to be representative for others
> also by using the 'our' word.

I don't want you advertising your crap on this mailing list either. He's not 
alone, and likely I'm not, either. Post something actually relevant to Arch 
Linux or leave it out.

> 
> I also want to research the correlation between your opinion-judgement in
> this case and the lines of evidenced based productive Arch Linux coding
> you have written first hand and I would be grateful for this statistic and
> evidence.


Programmers write code fine without your font, we don't need you trying to 
spam us with it. If you want people to try your font, put it on the AUR, stop 
spamming the mailing list.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Saturday, January 22, 2011 01:28:50 pm Geoffrey Teale wrote:
> 2011/1/22 Yaro Kasear 
> 
> > On Saturday, January 22, 2011 09:09:22 am Ng Oon-Ee wrote:
> > > On Sat, 2011-01-22 at 06:23 -0500,
> > 
> > hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama
> > _hare_h...@lavabit.com
> > 
> > wrote:
> > > > > Can someone stop him from spamming our inboxes ?
> > > > 
> > > > Meeku:  "our" means the whole mailing list.  You should have used the
> > > > word
> > > > "my" and if you are a closet racist by condemning me from
> > > > participating on
> > > > this open mailing list then it does not do Arch Linux's reputation
> > > > any good.
> > > 
> > > Up to this point this thread has been ignore-able, but what sort of
> > > nonsense is this? Accusations of racism simply because your spam is
> > > being identified as such?
> > > 
> > > What 'spam' is is decided by the recipients. I personally think this
> > > whole thread is spam. I'm pretty sure I'm not alone on this list in
> > > thinking that.
> > 
> > The fact he called it racism smells of a troll to me. Trolls are worse
> > than spammers.
> 
> Isn't that a little bit trollist?  We have to be tolerant of other
> cultures, if we oppress trollish people they will organise and rise up
> against us. See this interesting documentary for what I mean:
> http://www.youtube.com/watch?v=TGlSAtb-SDw

I'm racist against trolls. Am I  a horrible person?

Re: [arch-general] Gnome Sound Events and Settings

[Yaro Kasear]

On Saturday, January 22, 2011 09:28:35 am Steve Holmes wrote:
> What tools are needed in Arch to configure the login and logout sounds
> for GNOME?
> 
> When I go into the Volume control, I can only change the alert sounds
> and that, I can do OK but right now, I cannot get any sounds to work
> for Login, Logout, e-mail, etc.  I've seen references in google for
> other distros having something called Sound-Preferences or something
> but I don't see anything like that for Arch.  Google also pulled up
> some forum references to this same question but no answers were ever
> given.
> 
> What do other GNOME users do about this in Arch? I'm not aware of how
> to specify the paths for the right files.  Ifound the sound files
> themselves in /usr/share/sounds but can't figure out where to go from
> here.
> 
> Any ideas?

I encountered this issue a few years ago, when for whatever reason the GNOME 
developers stripped away sound theming for no reason.

Perhaps the option is buried deep within the gconf-editor?

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Saturday, January 22, 2011 09:09:22 am Ng Oon-Ee wrote:
> On Sat, 2011-01-22 at 06:23 -0500,
> 
> 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
> > > Can someone stop him from spamming our inboxes ?
> > 
> > Meeku:  "our" means the whole mailing list.  You should have used the
> > word
> > "my" and if you are a closet racist by condemning me from
> > participating on
> > this open mailing list then it does not do Arch Linux's reputation any
> > good.
> 
> Up to this point this thread has been ignore-able, but what sort of
> nonsense is this? Accusations of racism simply because your spam is
> being identified as such?
> 
> What 'spam' is is decided by the recipients. I personally think this
> whole thread is spam. I'm pretty sure I'm not alone on this list in
> thinking that.

The fact he called it racism smells of a troll to me. Trolls are worse than 
spammers.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Saturday, January 22, 2011 05:23:13 am 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
> > Can someone stop him from spamming our inboxes ?
> 
> Meeku:  "our" means the whole mailing list.  You should have used the word
> "my" and if you are a closet racist by condemning me from participating on
> this open mailing list then it does not do Arch Linux's reputation any
> good.

How does pointing you out to be a spammer make him a racist all of a sudden?

I smell troll.

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Friday, January 21, 2011 06:10:02 pm Denis A. Altoé Falqueto wrote:
> On Fri, Jan 21, 2011 at 9:51 PM, Yaro Kasear  wrote:
> > If it isn't broken, don't fix it. We put grub2 in [extra], not [core],
> > for the same reason we really should put systemd in [extra] and not
> > [core].
> 
> Don't get me wrong, but no one is putting anything anywhere. This is
> not a voting. The decision of bringing any package to the official
> repos is exclusively on the shoulders of a developer willing to
> maintain it. So all the discussion about entering or not is moot.
> 
> On the other hand, I'm enjoying the articles very much. The comments
> on each blog post are very enlightening. It even shows that Lennart
> has more patience than I would have... I've seen it being bashed
> without any reason and yet answer politely.
> 
> One very inspiring comment by Lennart, that sums up a lot of my own
> thoughts is:
> 
> "... you are right, systemd is nothing like traditional Unix. And that
> is a good thing. Unix has been designed 41 years ago. You honestly
> believe that its design is perfect and flawless and 41 years after it
> was designed still should be followed in all detail? No, computers
> changed, and Unix never was perfect. It probably was a better design
> than most other operating systems, but this does not mean it is
> perfect and we should never depart from it."
> 
> So, maybe we could tackle this discussion with an open mind, instead
> of being so zealots about what you already know. Remember, you didn't
> born knowing Linux. You can learn other things too :) I'm happy with
> the thread, because I'm having a good time reading about systemd. I'll
> try it in a few moments and see what it gives. Thanks Risinger for the
> links and Tom for the packages :)

I have nothing against change. Change for the sake of it being a change, on 
the other hand...

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Friday, January 21, 2011 05:42:17 pm Ray Rashif wrote:
(snip)
> > indeed, and i'd mostly agree.  however while im not a developer for
> > archlinux, i wouldnt waste time on obsolete systems when a better
> > alternative saves me time; you may end up maintaining the initscripts
> > yourself.  keep that in mind.
> > 
> > the point of systemd is to make ALL of our lives easier, not more
> > difficult.
> 
> Right. Anyway, you might want to realise that nobody who "matters" has
> had - up to this point - anything to say about "switching to systemd".
> Mostly because none of them have the time (so there is still hope).
> You can always file an FR in the tracker if you want to gain some
> progress for your enthusiasm, or even get an ultimatum.

I should also point out that simplicity as defined by Arch is not about making 
the life of the user easier, but for making the SYSTEM simpler. Again, systemd 
doesn't fit with that model at all.

You can read that right on the wiki.

You think SysV Init is a pile? Fine, install systemd. I think it belongs in 
[extra] in the best of times. There's really no good reason to make it part of 
base in [core] when all it does is something udev and hal do already, and a 
feature only a minority of Arch users are likely to actually use 
(RAID/LVM/Encryption support, while useful or even popular, can't honestly be 
in the majority of Arch installs.) 

This wasn't aimed at you, Ray, but the guy you were responding, but you were 
makign some good points on your own?

Have I also mentioned that despite all the features systemd might bring, it's 
still unnecessary in light of the fact that SysVInit with initscripts STILL 
works perfectly fine?

If it isn't broken, don't fix it. We put grub2 in [extra], not [core], for the 
same reason we really should put systemd in [extra] and not [core].

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Friday, January 21, 2011 11:53:22 am C Anthony Risinger wrote:
> oh... my.  there is too much  to respond properly
> so i'll try touch a couple [several] things ...
> 
> ... why the resistance at all? let me reiterate this nce and slow:
> 

Because it's completely unnecessary.

> SYSVINIT HAS NO POWER, NO FUNCTIONALITY, AND ABSOLUTELY ZERO
> USEFULNESS ON IT'S OWN.
> 
> the "unix philosophy" (debatable in itself...) of doing one thing
> doesn't usually translate to LITERALLY DOING ONE THING.
> 
> please please please, please, read that several times until it sinks
> in nice and deep; every single argument about sysvinit's "simplicity",
> "maturity", blah blah, woka woka, etc etc, and anything else related
> to it's stability is complete nonsense because ...
> 
> YOUR BOOT PROCESS IS A MEGAMATRON SHELL SCRIPT, AND HAS PEANUTS TO DO
> WITH INIT; IN FACT, INIT IS NOT EVEN NEEDED.
> 

Some form of init is still needed even if the initscripts are glorified shell 
scripts. What do you think has to RUN those shell scripts for them to be of 
any use at all?

Hell, even without a single initscript, an init system STILL needs to be in 
place. That's just how UNIX works

SysV Init is simple, which is what Arch is all about.

> capisce?  good.  now we can move on and give up this pointless cling
> to something that provides us nothing WHATSOEVER.

It provides us with a solid reliable way to boot our system and manage what 
runs at boot time. Anything more than that is luxury and unnecessary.

> 
> systemd is superior in every single way imaginable.

This is a matter of opinion. Not fact.

> that is the pure
> and simple truth; it's not even an arguable point. 

I am arguing it, therefore it is arguable.

> many of the
> "concerns" here are already answered/clarified higher up in the
> thread, or are nothing more than FUD and personal grudges against a
> guy who seems to SIMPLY WANTS TO IMPROVE THINGS AND DOESN'T CARE IF
> YOU WANT TO USE SYSVINIT FOR 60 MORE YEARS.

I doubt that. Again, to use Pulse Audio as an exabmple, he's stated he wanted 
it to take ALSA's place many times. He may not have said it about systemd, but 
there's no reason, none, to believe he doesn't expect it to replace SysV init 
on most Linux distributions.

> systemd solves real
> user/business problems, and whether or not you/me/us make personal use
> of every single possible feature is irrelevant.

And those problems are...? So far even those further up in this thread haven't 
described any real problems aside from certain inconvient things about the 
Arch Initscripts, which are fixable without introduce a needlessly complex 
init replacement.

> 
> these sentiments are echoed throughout most of community.

Are they? Please back up this assertion with facts instead of unsubstantiated 
rants.

> 
> systemd has  binaries?? yeah, and?  so what?  take a
> hard look at the precious sysvinit "suite"; you'll find 1700 external
> calls to grep, sed, awk, cut, ..., ... 

Those are core utilities, not the sysvinit suite. They're gonna be there 
whether or not we use SysV Init. And I bet even systemd would end up using 
them too in its units. 

> even if it mattered one tiny
> little bit, i'm pretty sure you'll exceed systemd's count in the first
> file or two.

Again, they're core utilities you'll find in ANY POSIX system. Just because 
SysV Init's scripts uses them is misleading and irrelevant and pointing this 
out is a blatant red herring.

> i've been thru the init scripts several times and ramfs
> init; i know.  just believe me.
> 

So am I. Your point has absolutely no value at all, as those utilities are not 
there for init's sake, but to make scripting at all useful. Switching to 
systemd wouldn't fix that one bit.

> why should init do "do almost nothing"??

Init decides what is run in what circumstances. That's ALL it needs to be. 
This is not a problem that needs to be fixed. Your argument is invalid.

> how many other applications
> do we slick developers write where the goal is to do a whole 'lotta
> nothing?  come on.  systemd doesn't step out of scope one bit;

Yes it does. Almost every one of systemd's features are completely unneeded 
for a fully functional boot process. Nothing systemd offers isn't already done 
with SysV Init and simple bootscripts.

> it's
> job is to reliably start, stop, and babysit processes with the
> parameters, environment, and constraints WE DEFINE. 

SysV Init does that too. Or have you not noticed the existence of 
/etc/inittab, /etc/rc.conf, or /etc.rc.local. Those three files alone already 
grant a finer amount of control over how Arch's boot process than systemd 
does. Let's not even touch on the "magical" things you can do with mkinitcpio.

Your rant stinks of someone who doesn't understand the first thing of how the 
Arch boot process actually works.

> that's it; feels
> pretty dang simple/kiss to me.  actually take a look at your boot
> process someday... then come back and drone on about how sl

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Friday, January 21, 2011 07:43:55 am Lukáš Jirkovský wrote:
(snip)

> And as other people said – I'm afraid of systemd even more because it
> was written by the same person as Pulse Audio was. PA didn't work very
> well for quite a long time. I'm not going to argue about that (it's
> just my personal opinion and none of you will change it), but I just
> don't believe someone who wrote a piece of crap which took several
> years to become generally usable will suddenly write something so
> delightful so it can be used as a replacement of one of the most
> tested and most established things in Unix/Linux world.
> 

(snip)

That was my point. I have had far too many negative experiences with Pulse 
Audio, Avahi, etc, for me to completely trust systemd when we already have 
something that works fine, causes next to no problems, and all for a couple of 
features I don't really see us needing as being part of a default system (Not 
everyone uses RAID/LVM/Encryption. In fact, I don't even think most Arch users 
use it, so I doubly see no point in this.). systemd could maybe go into 
[extra], but being put into [core] as a part of base, even as something 
running in parrallel with SysV init, I just don't get it.

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 07:09:43 pm Sander Jansen wrote:
> On Thu, Jan 20, 2011 at 6:55 PM, Yaro Kasear  wrote:
> > On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote:
> > (snip)
> > 
> >> - It's nice you can install it next to sysv-init. This makes it really
> >> easy to test without breaking the system.
> > 
> > You can do this? I might try it out. If it works as expected in its stage
> > of development, I'll quick being a jerk about it.
> > 
> > Also, how does that work? Do you choose an init at some point?
> 
> See the wiki, it's a kernel boot parameter.
> 
> >> - If you installed vala 0.10, systemd-git won't build, even though gtk
> >> is disabled. This is a bug in the configure script of systemd.
> >> Solution would be either to install vala-0.11 or remove vala from your
> >> system.
> > 
> > I'm confused by this. Do you mean that vala's conflicting something out
> > of the system or just causing a breakage in some way?
> 
> There's a bug in configure script. It works fine if you don't have
> vala installed, but if you do have it installed it will bark at you if
> you have the wrong version.
> 
> >> - I guess the initscripts-systemd is listed as an optional dependency
> >> of systemd, but I'm not sure how usefull systemd is without it...?
> > 
> > Though I don't 100% know how systemd is, don't all init systems need
> > scripts to be useful? I would think that installing systemd's
> > initscripts would be important for it to do its work.
> 
> Yeah, this is more a packaging issue.
> 
> >> - The login console seems to be slightly messed up. I can login, but
> >> error/log messages keep being send to the terminal as well.
> > 
> > What are the messages? Is there a bug in the bug tracker about this or is
> > this purely an upstream concern?
> 
> Just stderr output from the various daemons running. I'm guessing it
> goes to the wrong terminal.
> 
> >> - I know how I can change the default target on the boot line, but can
> >> I set it anywhere else?
> > 
> > Is that how you would run one init system over another?
> 
> systemd has a concept of runlevels, but calls them targets. You can
> override the default on the kernel boot line.
> 
> >> - sshd has listed network.service as a dependency, but what if you use
> >> NetworkManager instead?
> > 
> > Would this be cause for a seperate set of daemon scripts just for systemd
> > or are there plans to make it work with rc.conf in much the same way
> > SysV does?
> 
> systemd has "unit" files that replace the traditional sysv daemon
> scripts. They're much shorter and sweeter. The question was related to
> whether sshd should list "network" which is arch's /etc/rc.d/network
> script as a dependency.
> 
> Cheers,
> 
> Sander

I think I'll try this out. I'll be sure to file bug reports as necessary.

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 07:05:23 pm Ng Oon-Ee wrote:
> On Thu, 2011-01-20 at 18:55 -0600, Yaro Kasear wrote:
> > On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote:
> > (snip)
> > 
> > > - It's nice you can install it next to sysv-init. This makes it really
> > > easy to test without breaking the system.
> > 
> > You can do this? I might try it out. If it works as expected in its stage
> > of development, I'll quick being a jerk about it.
> 
> I think you meant 'quit' =p. Freudian slip?

Actually, not sure how that typo got in there. Thanks for catching it. Yes, I 
did mean 'quit.'

> 
> > Also, how does that work? Do you choose an init at some point?
> 
> I believe its been mentioned that you'd just alter the boot parameters
> in grub (or lilo if you use that).

Is this in the wiki?

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 07:03:23 pm Ng Oon-Ee wrote:
(snip)
> This talk is probably a year or so out of date however. Try pulseaudio
> now, I think you'll be pleasantly surprised. You'd also have noticed
> that actual bug reports on our forums/ML etc. concerning pulseaudio have
> dropped to close to nil.

I am currently using OSSv4. I don't know how accurate a reading of PA I'd get 
while using it.

Maybe I might temporarily switch to ALSA to give it a whirl.

At any rate, lets not go too far off topic here.

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote:
(snip)
> 
> - It's nice you can install it next to sysv-init. This makes it really
> easy to test without breaking the system.

You can do this? I might try it out. If it works as expected in its stage of 
development, I'll quick being a jerk about it.

Also, how does that work? Do you choose an init at some point?

> - If you installed vala 0.10, systemd-git won't build, even though gtk
> is disabled. This is a bug in the configure script of systemd.
> Solution would be either to install vala-0.11 or remove vala from your
> system.

I'm confused by this. Do you mean that vala's conflicting something out of the 
system or just causing a breakage in some way?

> - I guess the initscripts-systemd is listed as an optional dependency
> of systemd, but I'm not sure how usefull systemd is without it...?

Though I don't 100% know how systemd is, don't all init systems need scripts 
to be useful? I would think that installing systemd's initscripts would be 
important for it to do its work.

> - The login console seems to be slightly messed up. I can login, but
> error/log messages keep being send to the terminal as well.

What are the messages? Is there a bug in the bug tracker about this or is this 
purely an upstream concern?

> - I know how I can change the default target on the boot line, but can
> I set it anywhere else?

Is that how you would run one init system over another?

> - sshd has listed network.service as a dependency, but what if you use
> NetworkManager instead?

Would this be cause for a seperate set of daemon scripts just for systemd or 
are there plans to make it work with rc.conf in much the same way SysV does?

> 
> Cheers,
> 
> Sander

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 06:38:08 pm Sander Jansen wrote:
> 2011/1/20 Yaro Kasear :
> > On Thursday, January 20, 2011 06:27:04 pm Ng Oon-Ee wrote:
> >> On Thu, 2011-01-20 at 15:52 -0600, Yaro Kasear wrote:
> >> > I was ALMOST behind a switch to systemd until I found out the guy
> >> > behind it is Lennart Poettering. Now we can expect a half-broken init
> >> > system that'll be in perpetual beta, and more passing off the buck on
> >> > bug reports to
> >> > distributions/drivers/whatever.
> >> 
> >> I can see you already responded again to this thread, but my immediate
> >> reaction to this mail was o.0!
> > 
> > Lennart is the same person behind Pulse Audio, a known problematic sound
> > daemon. What worries me is that systemd is much closer to the system,
> > which might be potential for general all-around system breakage if
> > systemd gets as bad as PA.
> > 
> > NOTE: I don't want to start a flame war here about PA or anything. I'm
> > just concerned.
> 
> Yet you're pretty good at starting one. Do you have anything else to
> contribute except for it cannot possible be any good because this
> person wrote it.

I wrote my first post, the one Ng replied to, when I was in a bad mood. I was 
explaining myself this time.

Maybe I would like to see systemd in action. My concerns are that this one 
person has a track record (With PA and Avahi) of making subpar daemons that 
fix non-existant problems in Linux.

One person I am discussing this with has explained it makes dynamic device 
allocation easier somehow, though I'm not certain how that works when udev is 
the system behind this, not init.

Perhaps instead of falsely dismissing me as a flamebaiting troll you could 
explain it yourself, as right now I'm not 100% convinced about systemd.

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 06:27:04 pm Ng Oon-Ee wrote:
> On Thu, 2011-01-20 at 15:52 -0600, Yaro Kasear wrote:
> > I was ALMOST behind a switch to systemd until I found out the guy behind
> > it is Lennart Poettering. Now we can expect a half-broken init system
> > that'll be in perpetual beta, and more passing off the buck on bug
> > reports to
> > distributions/drivers/whatever.
> 
> I can see you already responded again to this thread, but my immediate
> reaction to this mail was o.0!

Lennart is the same person behind Pulse Audio, a known problematic sound 
daemon. What worries me is that systemd is much closer to the system, which 
might be potential for general all-around system breakage if systemd gets as 
bad as PA.

NOTE: I don't want to start a flame war here about PA or anything. I'm just 
concerned.

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 05:45:46 pm Tom Gundersen wrote:

(snip)

> @Yaro:
> 
> 1) In my experience Lennart has been a pleasure to work with.
> 

I, personally, have never worked with him. I have seen enough criticism of 
Pulse Audio, for example, getting handwaved and pinned on someone else's 
project. I think about it logically: 

If it works fine with ALSA, why did it inexplicably stop working fine with 
Pulse Audio running? Why, when he claims that PA not working is the fault of 
some distribution doing it wrong that it's busted no matter what system I try 
it on?

Lennart has never, in his explanations of how PA actually screws up, actually 
explained to my satisfaction. And with PA being as flawed as it seems to me, 
systemd really worries me. From my perspective he couldn't get a sound daemon 
written that couldn't get sound working right on my system, why am I to 
believe systemd would fare any better.

Let me put it another way, it seems like Lennart's great on new ideas on how 
to do things, poor on execution. From where I am sitting, anyway

This is getting off-topic, and I don't mean to start a "Lennart sucks" flame 
war.

> 2) Regarding systemd and "The Arch Way", I guess this is a matter of
> opinion, but the way I see it, systemd fits perfecttly. For two
> reasons (off the top of my head, there might be more):
> 
> Firstly, while systemd is more complex (due to more features) than
> sysvinit, the arch-specific parts of systemd are much simpler than the
> arch-specific parts of sysvinit (since systemd does most of what
> rc.sysinit and rc.shutdown do for sysvinit).

Isn't the fact that systemd is more complex already makes it more or less 
against Arch's KISS principles? Or am I confused?

> In fact, by pushing as
> much as our boot process "upstream" and sharing it with other
> distributions, we simplify our lives significantly due to the "free"
> testing and development effort we receive (especially the integration
> of the init system and related packages like udev and util-linux).
>

I certainly can't fault that part. That's probably open source's greatest 
strength. ESR called it "Linus' Law" and he explained it succinctly in the 
CatB paper. My concern is about how cooperative and willing to fix known 
issues upstream will have. You can write patches, but only one person (Or 
possibly, a group of people.) can approve it for an official inclusion with 
upstream. How many patches has Lennart rejected on systemd? How many has he 
accepted? Of those has he rejected has he given a verifiable reason?

> Secondly, in a world where devices might come and go and their
> dependencies might be arbitrarily complex, the sysvinit architecture
> cannot work in a clean way. SysVinit was created when all setups could
> be assumed to be static, and this is simply no longer the case (this
> can best be seen in a setup with lots of raid/lvm/encrypted devices).
> 

I admit to never using RAID/LVM/ENCRYPTION. But last I checked init had 
nothing whatsoever to do with how /dev is populated or managed. We have udev 
for that, and udev doesn't care what init system we use. All inits do is call 
udev when their scripts tell them to. I don't see how this makes systemd more 
viable than SysV when udev is what controls this instead, as udev works the 
same no matter if its SysV, Upstart, or systemd.

Perhaps you can clarify init's role in device population besides running udev 
when appropriate, as SysV is already capable of that?

> Cheers,
> 
> Tom

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

Never mind about what I said. I'm just having a bad day.

Can someone give me a more clear idea on why we might need systemd? It doesn't 
look like it'd fit with the Arch Way, and, well, SysV Init isn't exactly 
broken, and if it isn't broken, why fix it?

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

I was ALMOST behind a switch to systemd until I found out the guy behind it is 
Lennart Poettering. Now we can expect a half-broken init system that'll be in 
perpetual beta, and more passing off the buck on bug reports to 
distributions/drivers/whatever.

Re: [arch-general] When will Arch switch to Upstart

[Yaro Kasear]

On Wednesday, January 19, 2011 02:25:28 pm Isaac Dupree wrote:
> On 01/19/11 14:03, Yaro Kasear wrote:
> > And comments about Ubuntu and their competence are entirely relevant to
> > this discussion, as Upstart is entirely their creation. Would you rather
> > I talk about people who had nothing to do with its code? The Ubuntu devs
> > are behind Upstart, they're not that great at what they do when it comes
> > to the actual system side of Ubuntu. Therefore why should we consider
> > Upstart an improvement.
> 
> Argument ad hominem.

This was not argument ad hominem. I didn't call you names or insult you. Learn 
what it means before using that phrase. 

> We can be precise; it's more obviously rude that
> way.  Scott James Remnant wrote Upstart.

For Ubuntu. As an Ubuntu developer. Why do you think upstart's main page is on 
the Ubuntu web site, and not just Launchpad?

> I can't speak for Ubuntu, but
> I've seen Remnant presenting and he seemed quite competent.  Software is
> hard; Upstart was the first attempt at changing 'init' in decades, so
> there was little experiential knowledge of Linux 'init' development when
> it started in 2006. 

And that leads to my next question: What makes Upstart necessary?

Nothing. Boot speed is a trivial reason to overhaul the way UNIX/Linux boots, 
especially for an init system that is needlessly complex and far less 
accessible than what we already had. If we switch to upstart, simply beign 
able to edit a file like /etc/rc.conf will be gone, and setting up daemons 
"The Arch Way" would become unnecessarily difficult.

The fact that init hasn't been changed in "decades" like you claim is because 
nobody worth their UNIX development skill felt init actually NEEDED a change. 
It still doesn't. Just because you CAN change it doesn't mean you NEED to 
change it. SysV Init is fine for Arch, maybe systemd might be a pleasant 
change, but it's not a necessary change either.

> In fact, in the process of writing Upstart, Remnant
> and his co-workers made Ubuntu boot faster largely by working with Xorg
> and Linux kernel developers.

Boot times are an incredibly trivial reason to upheave the actual system 
process of a system like Arch. Rarely does someone actually need to get to 
their desktop in such a hurry, and it's far less important than the system 
being stable or fast during actual runtime. Upstart moves things in the 
opposite direction of that.

> There are now upstream changes due to the
> risk Ubuntu took with Upstart.  *Arch* therefore now boots faster
> because of Remnant.

First I ever heard of Upstart being important enough for something MUCH bigger 
and MUCH more important changing how they work JUST for the sake of something 
MUCH smaller and MUCH less important to work correctly. I'm going to have to 
see official upstream patches or it didn't happen.

> He's a pretty smart guy who knows what he's doing
> even if some of us disagree with what he's doing; I was at his
> presentation "How We Made Ubuntu Boot Faster"
> http://events.linuxfoundation.org/linuxcon2010/remnant

Again, booting faster is a luxury. People talk about it as if its very 
important, but it's trivial compared to a system running and running well, two 
things Upstart's known for not promoting.

> 
> That is equally no reason to switch to Upstart.

There is NO reason to switch to Upstart at all, except that the OP seems to 
think that just because Ubuntu and Fedora did it, we should too, and plenty of 
reasons NOT to switch to Upstart.

> We can be grateful to
> Remnant and choose the best (technically & socially) solution *for Arch*
> *in 2011*.  Of course he's enthusiastic about Upstart but I'm sure he
> wouldn't mind.

Again, Remnant made WHAT contributions to Arch to date? You plan on pulling 
him from his place as an Ubuntu dev where mediocre code is praised to make 
Arch run worse just for the sake of a couple seconds less boot time? Here's an 
idea, how about we just rewrute the initscripts to be more efficient. That'd 
be much less of a trouble.

> (I don't pretend to know which solution this is, though
> it sounds like Arch's current init system, or systemd, are likely to be
> default in the next year or two.)

Sounds like you already have done this. Blindly singing the praises of an 
Ubuntu developer just because he is a good public speaker and that he "seems 
competent." Have you ever even tried configuring upstart manually? It fights 
you. Every step of the way. IT takes away that much flexibility from the 
system just for the sake of taking off a few seconds of boot time.

I have no opinion on systemd as an init system, as I have no experience with 
it. But I have use