Re: [arch-general] Opinions on PowerShell?

[Stephen E. Baker via arch-general]

On 8/19/2016 6:21 AM, Joerg Schilling wrote:

Hunter Connelly via arch-general  wrote:


Here's an example I found on Reddit in the thread about this on /r/linux.
Both of the following commands find the size and name of the three largest files
in a directory.

Bash:ls -l | sed 's/ \+/,/g' | cut -d',' -f 5,9 | sort -g | tail -3
PowerShell:  ls -file | sort -pr length | select length, name -l 3

If it overlays standardized behavior by non-standard behavior, this would
indeed be a strong afrument against it.

Jörg

By default PowerShell comes preconfigured with aliases that match the 
familiar names of unix programs that approximately describe the 
PowerShell equivalents. Sometimes these aliases are more accurate than 
others, e.g. ls => Get-Items is fairly reasonable, other times the 
aliases are terribly misleading, like curl => Invoke-WebRequest.


PowerShell also interacts poorly with traditional text based unix 
programs (and windows programs for that matter). It is definitely best 
treated like a python shell, interacting with other powershell 
commandlets, modules, and .NET libraries.


As a PowerShell user, it certainly has it's place, but it's place is 
pretty niche in the linux world, so +1 for the AUR.

Re: [arch-general] LightDM autologin not working

[Stephen E. Baker]

On 2014-06-21 9:16 AM, Fred Schiff wrote:

Does a media center actually need a graphical login manager?
No, but I've found it simpler to use a light DM (lxdm and now lightdm) 
than to keep up with the proper way to initialize a session. Back before 
systemd I use to ck-launch-session dbus-launch etc. etc.


I run an openbox session which autostarts xbmc so that I can launch 
other programs (games, web browsers, ripping tools) from it.



On Fri, Jun 20, 2014 at 8:18 PM, Stephen Baker baker.stephe...@gmail.com
wrote:


On 2014-06-20 12:22, Daniel Leining wrote:


I don't think you're doing anything wrong. Your setup is almost identical
to mine.

   % cat /etc/lightdm/lightdm.conf | grep -v ^#
[LightDM]
greeter-user=lightdm
minimum-vt=1
log-directory=/var/log/lightdm
run-directory=/run/lightdm

[SeatDefaults]
greeter-session=lightdm-gtk-greeter
session-wrapper=/etc/lightdm/Xsession
autologin-user=daniel
autologin-user-timeout=0
pam-service=lightdm-autologin


Ah, I see your autologin-* lines are under [SeatDefaults] and mine are
above.  I fixed that and it's working now.



[XDMCPServer]

[VNCServer]
#End of file


On Thu, Jun 19, 2014 at 10:27 PM, Stephen Baker 
baker.stephe...@gmail.com
wrote:

  Hello,

I've been trying to get autologin working in LightDM on my mediacenter
without success.  I believe I've copied all the instructions in the wiki
page, and I'm not seeing where the problem is.

mediacenter% cat /etc/lightdm/lightdm.conf | grep -v ^#
[LightDM]
minimum-vt=1
run-directory=/run/lightdm

autologin-user=family
autologin-user-timeout=0
[SeatDefaults]
session-wrapper=/etc/lightdm/Xsession
pam-service=lightdm-autologin


[XDMCPServer]

[VNCServer]
#End of file

mediacenter% groups
adm disk wheel games video audio optical floppy storage power users
family
autologin

mediacenter% journalctl -b -u lightdm --no-pager
-- Logs begin at Mon 2012-10-22 16:11:18 EDT, end at Thu 2014-06-19
22:24:36 EDT. --
Jun 19 22:12:29 mediacenter systemd[1]: Started Light Display Manager.
Jun 19 22:12:36 mediacenter lightdm[699]: pam_unix(lightdm-greeter:
session):
session opened for user lightdm by (uid=0)
Jun 19 22:16:25 mediacenter lightdm[723]: pam_unix(lightdm:session):
session opened for user family by (uid=0)

# the last line was my manual login after waiting several minutes.

Is there anything else I should be checking, or any caveats anyone is
aware of?

  Thanks!

[arch-general] out of memory while allocating z_stream

[Stephen E. Baker]

Hello,

As of yesterday I cannot boot, regardless of whether I choose the 
regular or failback kernel from the boot loader.


I haven't been able to find anything on google, so I was hoping someone 
here might know what's going on.


Last time my system was up I installed updates including the latest 
kernel, and I ran e4defrag over the disk.
The computer is a ThinkPad T60, with a Core 2 Duo and 2GB of Ram.  I am 
running the i686 version of Arch Linux.

My boot loader is syslinux.

In the mean time I'm downloading a new copy of the Arch Install ISO (all 
my existing recovery disks are too old to chroot from), and I will try 
reinstalling the kernel.


Output:
Loading ../vmlinuz-linux... ok
Loading ../initramfs-linux.img...ok
Probing EDD (edd=off to disable)... ok
early console in decompress_kernel

Decompressing Linux...

Out of memory while allocating z_stream

-- System halted

Re: [arch-general] out of memory while allocating z_stream

[Stephen E. Baker]

On 2014-05-10 9:24 AM, Stephen E. Baker wrote:

Hello,

As of yesterday I cannot boot, regardless of whether I choose the 
regular or failback kernel from the boot loader.


I haven't been able to find anything on google, so I was hoping 
someone here might know what's going on.


Last time my system was up I installed updates including the latest 
kernel, and I ran e4defrag over the disk.
The computer is a ThinkPad T60, with a Core 2 Duo and 2GB of Ram. I am 
running the i686 version of Arch Linux.

My boot loader is syslinux.

In the mean time I'm downloading a new copy of the Arch Install ISO 
(all my existing recovery disks are too old to chroot from), and I 
will try reinstalling the kernel.


Output:
Loading ../vmlinuz-linux... ok
Loading ../initramfs-linux.img...ok
Probing EDD (edd=off to disable)... ok
early console in decompress_kernel

Decompressing Linux...

Out of memory while allocating z_stream

-- System halted


Reinstalling the kernel does not help (kernel version is 3.14.2-2)

Booting into the system from System Rescue CD takes me to a root 
console, where I can see the following errors in journalctl transcribed 
by hand:


systemd-modules-load[400]:
Failed to lookup alias 'vhba': Function not implemented
Failed to lookup alias 'nfs': Function not implemented
Failed to lookup alias 'cuse': Funtion not implemented
Failed to lookup alias 'snd-seq-oss': Function not implemented

systemd[1]:
systemd-modules-load.service: main process exited, code=exited, 
status=1/Failure

Failed to start Load Kernel Modules.
Unit systemd-modules-load.service entered failed sate.
...
(several modules successfully start)
...
mount[410]: unknown filesystem type 'binfmt_misc'
systemd[1]: proc-sys-fs-binfmt_misc.mount process exited, code=exited 
status=32

systemd[1]: Failed to mount Arbitrary Executeable File Formats File System
Unit proc-sys-fs-binfmt_misc.mount entered failed state.
(repeat of the above)
(repeat of the above with additional line) systemd-binfmt[403]: Failed 
to add binary format: No such device

(repeat of above)
systemd[1]: Unit systemd-binfmt.service entered a failed state.
systemd-udevd[416]:
invalid key/value pair in file /etc/udev/rules.d/51-android.rules on 
line 1,starting at character 1 ('U')

(repeat for line 2 and 3)

systemd[1]: Job 
dev-disk-by\x2duuid-0ee048dd\x2d2e11\x2d4499\x2d97ad\x2dc581a0eb3fba.device/start 
timed out.
systemd[1]: Timed out waiting for device 
dev-disk-by\x2duuid-0ee048dd\x2d2e11\x2d4499\x2d97ad\x2dc581a0eb3fba.device


systemd[1]: Dependency failed for /boot.
systemd[1]: Dependency failed for Local File Systems.
systemd[1]: Dependency failed for File System Check on 
/dev/disk/by-uuid/0ee048dd-2e11-4499-97ad-c581a0eb3fba


systemd[1]: Job 
dev-disk-by\x2duuid-081bbc62\x2d30be\x2d4333\x2daee0\x2dc9d2f6ed5e55.device/start 
timed out.
systemd[1]: Timed out waiting for device 
dev-disk-by\x2duuid-081bbc62\x2d30be\x2d4333\x2daee0\x2dc9d2f6ed5e55.device
systemd[1]: Dependency failed for 
/dev/disk/by-uuid/081bbc62/30be/4333/aee0/c9d2f6ed5e55.


systemd[1]: Dependency failed for Swap.
...
(several services shut down, several others successfully start)
systemd[474]: Failed at step EXEC spawning /bin/plymouth: No such file 
or directory

Re: [arch-general] [solved] out of memory while allocating z_stream

[Stephen E. Baker]

On 2014-05-10 9:24 AM, Stephen E. Baker wrote:

Hello,

As of yesterday I cannot boot, regardless of whether I choose the 
regular or failback kernel from the boot loader.


I haven't been able to find anything on google, so I was hoping 
someone here might know what's going on.


Last time my system was up I installed updates including the latest 
kernel, and I ran e4defrag over the disk.
The computer is a ThinkPad T60, with a Core 2 Duo and 2GB of Ram. I am 
running the i686 version of Arch Linux.

My boot loader is syslinux.

In the mean time I'm downloading a new copy of the Arch Install ISO 
(all my existing recovery disks are too old to chroot from), and I 
will try reinstalling the kernel.


Output:
Loading ../vmlinuz-linux... ok
Loading ../initramfs-linux.img...ok
Probing EDD (edd=off to disable)... ok
early console in decompress_kernel

Decompressing Linux...

Out of memory while allocating z_stream

-- System halted

Alright, I did a couple things at once because I was tired of rebooting 
so I'm not sure which actually fixed it, but it's working now.
I ran the rescue disk in normal mode and did a chroot instead of trying 
to boot into my system.
I deleted the linux kernel from /var/cache/pacman, and installed it over 
again

I ran syslinux-update_install -u -m

Re: [arch-general] [arch-dev-public] Dropping bluez4

[Stephen E. Baker]

On 2013-11-06 3:21 PM, Andreas Radke wrote:

Am Sat, 12 Oct 2013 16:28:56  +0200 schrieb Tom Gundersen

 t...@jklm.no:

 Hi guys,

 Once pulseaudio and bluedevil moves out of [testing], the only
 official package depending on bluez4 will be blueman.

 As blueman was last released two years ago, and last upstream
 activity was more than one year ago and that bluez4 is no longer
 developed upstream at all, I suggest dropping both of them from
 the repositories.

 Any objections?

 Cheers,

 Tom


[snip]




 Best would be to get bluez connecting to devices from console or/and
 to have a desktop independent frontend like this approach:

 http://mail.xfce.org/pipermail/xfce4-dev/2013-July/030408.html

 -Andy

By this are you including the problem of bluez 5 not providing a way to 
automatically connect to bluetooth input devices without Gnome or KDE.  
That was something I ran into on my media center when I tried to 
switch.   The keyboard might not be available on boot.


There is a forum post about the issue here, with a couple workarounds 
but none of them are ideal for the end user to be doing: 
https://bbs.archlinux.org/viewtopic.php?id=166362


- Stephen E. Baker

Re: [arch-general] Systemd and time synchronisation problems

[Stephen E. Baker]

On 11/09/2012 5:22 PM, mike cloaked wrote:

On Tue, Sep 11, 2012 at 8:06 PM, mike cloaked mike.cloa...@gmail.com wrote:

On Tue, Sep 11, 2012 at 7:51 PM, Jan Steffens jan.steff...@gmail.com wrote:

On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler tho...@archlinux.org wrote:

2) When chrony is not running, systemd-timedated runs periodically to
adjust the hardware clock for drift (AFAIK, not sure that is the job
that timedated does).

No. When chrony isn't running, the hwclock isn't getting adjusted at
all. The only thing systemd does on startup is warp the system clock
if and only if the RTC is running in localtime.

systemd-timedated's job is to provide a DBus interface to change
system time and date settings:
   SetTime, SetTimezone, SetLocalRTC (whether RTC is in localtime),
SetNTP (whether NTP is enabled)
It's used by gnome-control-center, at least. The SetNTP call uses the
ntp-units.d directory to select an implementation.

Thank you for all the information - it seems that the key to this was
that the RTC was too far out from correct time at boot - now that I
manually set the RTC to correct time it comes up close to correct -
and then chrony synchronises a few minutes after startup.  At present
tracking shows it is about 0.1 microsecs from NTP time:
System time : 0.00106 seconds fast of NTP time

What  I don't understand is why the hardware clock was not re-written
with the correctly synchronised time previously, since chrony has been
running every time I booted the system for ages?


By the way I also found another way to write the hardware clock from
within chrony which does not need the chronyd daemon to be stopped
(after spending this evening reading the detailed chrony docs!)  that
you can run chronyc in a terminal, and then enter password
mypasswordforchrony  (where the argument is the password from the
chrony keys file) and then issue the trimrtc command once the chrony
password has been accepted - this will then write the current system
time to the RTC, only sensible if time has been synchronised - though
the RTC is only accurate to within a second or so I believe.

I guess it would be nice to have more complete information on the
archwiki though there is full documentation on the chrony main web
page.

I think the usual response is, anyone can edit the wiki - please add 
what you

think is needed.

Re: [arch-general] amd64 systems and archlinux

[Stephen E. Baker]

On 10/09/2012 6:57 AM, Kyle wrote:

According to Thomas Bächler:

Let me also express part of my personal opinion, which others might
disagree with: If you wanted high quality software, why did you install
GRUB? If you want a decent bootloader, use syslinux.



Actually, at least from where I'm sitting, this personal opinion has 
a good bit of technical merrit. I can confirm that my life with boot 
loaders has become much easier since switching to syslinux, and you 
are the second regular contributor who has stated this. I was forced 
to chainload Windows XP after resizing a partition on this old machine 
I am still using, hopefully until the end of the day. This was already 
configured into syslinux by default, and worked flawlessly without 
modification. Additionally, the Arch defaults were sane enough to be 
able to run with very little modification, only needing the label for 
my root partition in the append line for the kernel. A big +1 from me 
for syslinux.

~Kyle
Also prefer syslinux.  In my opinion when the news post came up that 
said grub was deprecated it should have mentioned syslinux, since it's 
much closer to grub-legacy than grub2 is, and trivial to install.

Re: [arch-general] is it possible to disable bold(bright) color under console?

[Stephen E. Baker]

On 04/09/2012 3:14 PM, Xeslaro wrote:

On Tue, Sep 04, 2012 at 12:33:53PM +0200, Rodrigo Rivas wrote:

You are not telling wich console are you using... Are you in some kind of
virtual terminal? Or in the linux console? If the latter, are you using the
old VGA console or the new FB console?

--
Rodrigo

   sorry, i thought there's a general way to do it. i want to do it under xterm 
and fb console with agetty running.

You can modify the .Xresources files and redefine the bright colours.
https://wiki.archlinux.org/index.php/X_resources#Terminal_colors

(Remember to xrdb the file when you're done, and add xrdb to your xinit 
if you haven't already)

Re: [arch-general] Pacman and Systemd's automount

[Stephen E. Baker]

On 04/09/2012 11:08 AM, Daniel Wallace wrote:

On Sep 4, 2012 11:04 AM, Guillermo Leira gle...@gleira.com wrote:

Hello!

I have enabled systemd, and since then, I see the following:

[root@guillelinux ~]# LANG=C pacman -Syu
:: Synchronizing package databases...
  core is up to date
  extra is up to date
  community is up to date
  multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...

Targets (1): openssh-6.1p1-2

Total Download Size:0.53 MiB
Total Installed Size:   2.62 MiB
Net Upgrade Size:   0.00 MiB

Proceed with installation? [Y/n] y
:: Retrieving packages from core...
  openssh-6.1p1-2-x86_64 540.5 KiB
2034K/s 00:00 [] 100%
(1/1) checking package integrity
[] 100%
(1/1) loading package files
[] 100%
(1/1) checking for file conflicts
[] 100%
warning: could not get filesystem information for /mnt/atlantac: No such
device
warning: could not get filesystem information for /mnt/atlantad: No such
device
warning: could not get filesystem information for /mnt/asusc: No such

device

warning: could not get filesystem information for /mnt/asusd: No such

device

warning: could not get filesystem information for /mnt/asusf: No such

device

(1/1) checking available disk space
[] 100%
(1/1) upgrading openssh
[] 100%

It seems that pacman tries to access or check every mounted filesystem in

my

PC. It is not very important, except when I'm out of the office. I have
defined some mount points like this:

172.31.217.10:/vol/vol0 /mnt/up nfs

noauto,x-systemd.automount,defaults

0 0

When pacman reaches this filesystems, that obviously can't be accessed

from

outside the office, it hangs forever. I have to issue

Systemctl stop mnt-systemd.up

And then it works.

Why is pacman trying to access all the mountpoints?

Best Regards,

Guillermo Leira





Because you you have Check space enabled in pacman.conf

As well, I would suggest adding x-systemd.device-timeout to your
fstab, so it doesn't hang forever.

Re: [arch-general] systemd pulseaudio

[Stephen E. Baker]

On 29/08/2012 11:04 AM, Arno Gaboury wrote:

On 29/08/12||11:20, Denis A. Altoé Falqueto wrote:

On Wed, Aug 29, 2012 at 10:51 AM, Arno Gaboury arnaud.gabo...@gmail.com wrote:

YES, this is a bug. I already commented the module in my default.pa, and
now the message has gone.
But pulse audio is still not able to play sound.

Have you installed pulseaudio-alsa? It provides a default asound.conf
that sets Pulseaudio as the default output. What really intrigues me
is that you commented about your aplai -l not showing any info.


I list-modules but couldn't see in the returning list
module-alsa-sink.
Could it explain my issue with aplay returning nothing and pulse unable
to connect to the sound card?
Yes, I was going to mention that I have an issue on one of my boxes 
where I have to specify load-module alsa-module-sink with my sound 
device details in /etc/pulse/default.pa or else (in my case) it doesn't 
load the right ones.  That happens without systemd though so I guessed 
it wasn't related - still if it's having trouble with udev that will help.



--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?
For more information, please read: http://idallen.com/topposting.html

---
Denis A. Altoe Falqueto
Linux user #524555
---

Re: [arch-general] [arch-dev-public] merging systemd back to a singular package

[Stephen E. Baker]

On 27/08/2012 9:39 AM, Heiko Baums wrote:

Am Mon, 27 Aug 2012 11:30:46 +0200
schrieb Joakim Hernberg j...@alchemy.lu:


I don't run gnome, but kde is just as bad in this case :(

Try Xfce. ;-)

http://www.archlinux.org/packages/extra/i686/consolekit/ would suggest
that xfce is not safe in this regard.  lxde is as long as you don't use 
a display

manager iirc.

Heiko

Re: [arch-general] SystemD poll

[Stephen E. Baker]

On 23/08/2012 4:14 PM, Felipe Contreras wrote:
[snip]

Is systemd ready? Where is the evidence?


https://www.archlinux.de/?page=PackageStatistics shows that about 14% of 
arch users who are using pkgstat have systemd installed.  It is not 
default and not depended on by anything, so that means a sizable portion 
of the community has tried it.   The bug tracker isn't being flooded 
with critical bugs against it so it must work for the majority of 
archers who are using it.


Is that evidence?  If not, what would constitute evidence?

[snip]

Re: [arch-general] systemd native files in etc

[Stephen E. Baker]

On 23/08/2012 4:41 PM, Ike Devolder wrote:

Op donderdag 23 augustus 2012 16:14:26 schreef Qadri:

Hi all,

Given all the hullabaloo about systemd I thought I'd try it out. I went to
the wiki and saw that it has listed several native systemd configuration
files that it looks for, and if they're absent, it takes info from
rc.conf. It's strongly advised (by the wiki) to use the native files.

Is there a package that provides these /etc files, like hostname,
vconsole.conf, locale.conf? It feels weird creating untracked files in
/etc. Is there interest in an aur package (e.g. systemd_etc_files) that I
could make with all the many comments and options that are essentially in
the rc.conf (or other files)? What package will eventually provide these?

MAQ.

No there is no package providing those files.

why ?

if arch would provide you with defaults every time the defaults get updated
you would get *.pacnew files in your etc. since those files are depending on
your system and are user choice it would not be good to provide those.

so please don't create an AUR package providing those files.

--Ike
This logic never applied before.  mirrorlist, locale.gen, and many other 
files are always configured and included in packages.  I don't 
necessarily mind the decision but I can't believe it was that simple.  
Was there any discussion about this somewhere?


Stephen E. Baker

Re: [arch-general] Arch Linux and systemd

[Stephen E. Baker]

On 17/08/2012 8:34 AM, Stephen E. Baker wrote:

The other issue I hit was that it didn't like one of my fstab entries,
for a loop back file system in my home partition that I use to fake
a small drive for one of my old wine games.  This error caused it to 
boot to a
root console where I could see the file system in error.  I haven't 
yet tried to

debug the line, but once I commented it out I was able to boot my system.


Some people have been replying off list with suggestions.  With some help
on #systemd I added x-systemd.automount to the options on the fstab and
now that file system is working fine.

I've now removed initscripts and sysvinit and everything is working nicely.
I'm not convinced for me that there was much real advantage to the move,
but there doesn't seem to be any disadvantage either.

Stephen E. Baker

Re: [arch-general] Arch Linux and systemd

[Stephen E. Baker]

On 17/08/2012 5:47 AM, Thomas Rand wrote:


Thank you for starting a thread that (crosses fingers) will stay rant
free  intelligent.

After reading all the who-har in the other's I decided to install
systemd on my lappy  TBH was very pleased with the result. That being
that the install itself was hassle free  the configuration was
bizarrely intuitive  easy, I had a small issue that
lightdm-unity-greeter was not starting, so I made a note of the error
given  checked the .service, .device, .target files  was astounded
to see seriously plain text to the point where I followed through the
process systemd took  worked out the problem reboot  bingo I fixed
it without even looking on the web!
I also decided I should install systemd on my laptop last night. (At a 
time when

I didn't actually have much time to work on it, because that's the kind of
guy I am ;) ).  I agree that the install itself was very easy, and with 
the recent

rc.conf changes there was very little else to configure except to setup the
starting services.

I did hit a couple issues: Arch doesn't ship with units for all the daemons
I use.  I was able to copy the mysqld instructions out of the wiki, but
my attempt at getting timidity working on my own failed.  (Again,
I suspect I will be able to get it working, but I was doing things quickly.)

The other issue I hit was that it didn't like one of my fstab entries,
for a loop back file system in my home partition that I use to fake
a small drive for one of my old wine games.  This error caused it to 
boot to a
root console where I could see the file system in error.  I haven't yet 
tried to

debug the line, but once I commented it out I was able to boot my system.

Stephen E. Baker

[snip]


Again thanks for a sane thread :)


+1

Re: [arch-general] Think twice before moving to systemd

[Stephen E. Baker]

On 15/08/2012 8:05 AM, Felipe Contreras wrote:

On Wed, Aug 15, 2012 at 9:55 AM, Leon Feng rainofch...@gmail.com wrote:

[snip]

Arch is always give user's their options they want.

You can use initscript, even if systemd is the default just like I can
use systemd now when initscript is the default. Switch from one to
another is very easy.  So use systemd as default does not means you
can not use initscript.

This is not what I've been reading on the mailing list. People want to
get rid of initscripts, as maintaining both would be a burden, and
certain projects behave differently with or without systemd (wedge
strategy).

True, the devs will eventually not want to be burdened with it, but that 
doesn't

mean you couldn't support a version in your own repository or the AUR no
matter what anyone else does.

Yes, it is a lot of work.

Stephen E. Baker

Re: [arch-general] Personal note

[Stephen E. Baker]

On 15/08/2012 1:27 PM, Tom Gundersen wrote:

Hi guys,

As most devs have done already, I'm going to change my relationship
with arch-general. This probably does not matter to most of you, so
sorry for the noise. Then again, it might be a useful reminder about
how most devs interact with the list (or rather, how they do not).

My approach to arch-general used to be:

1) to scan it for bug reports and feedback related to my corner of
the Arch world, and follow up on whatever bugs/problems/questions I
could.
2) to correct anything that I considered misinformation about the same.

I am no longer able to keep up with this, so I will:

1) stop dealing with bugs reported on the mailing-list, please report
anything to the bug tracker.
2) just accept that the world is full of misinformation and baseless
speculations and not engage with it any longer.

This is mostly for the sake of my own sanity, but also because I think
my continued presence on this mailing list decreases rather than
increases the current abysmal quality of discussion.
I noticed in arch-dev that there was a lot of frustration with the 
quality of discussion
on arch-general these days.   I think it's very unfortunate that the 
noise to signal

ratio has gotten to the point where we have one less way of communicating
with the devs.  There are very few avenues already.

Sorry to see you (and the others devs, and the TUs) go.

Stephen E. Baker

Re: [arch-general] old rc.sysinit?

[Stephen E. Baker]

On 14/08/2012 4:08 PM, Jorge Almeida wrote:

I would like to know how Arch used to deal with some init stuff, like
configuring virtual consoles, initializing random seed, etc. Is there some way
to retrieve older versions of /etc/rc.sysinit?

Yes: http://projects.archlinux.org/initscripts.git/log/rc.sysinit


TIA

Jorge Almeida

Re: [arch-general] Systemd : Analysis of reactions of Users

[Stephen E. Baker]

On 27/07/2012 9:29 AM, Mike wrote:

On 27/07/12 13:57, Nicolas Sebrecht wrote:

The 27/07/12, Mike wrote:


I'm aware of that, but that doesn't mean one can't fix them. Nobody
said, that the code base of sysvinit shouldn't be modified.

It would have been fixed for a long time if it were easy enough. :-)


Uhm there are init systems available that are baesd on or using sysvinit
or at least are trying to stay compatible (e.g. upstart), without
reinventing
the wheel or declare the unix philosophy obsolote.

AFAIK systemd is trying to stay backwards compatible at least in the 
sense that upstart is.  It can parse old initscripts, and there is even 
a target in archlinux that will read your DAEMONS array so you can 
pretend you never switched.  All this other stuff is just a more 
powerful option in systemd that people can move to as they're ready.

Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.

[Stephen E. Baker]

On 25/07/2012 5:54 AM, Heiko Baums wrote:

[snip]
Why do I have to tell systemd in all of those init scripts what 
service has to run before or after this service? In DAEMONS in 
rc.conf I just have a list of daemons I want to have started in one 
single line. And the order in which they have to be started is the 
order in which I list those daemons. Just plain and simple, and can 
easily be parsed. 
This DAEMONS array is nice, one of the things I like about Arch, but it 
is specific to Arch not SysV.  If you run Gentoo, or others you won't 
have something like that, you'll have a program that arranges symlinks, 
not entirely unlike systemd.


Why you would want to specify which services had to come before or after 
which other services is obvious when you consider that systemd boots 
services in parallel.  There is no way in the current system, and no way 
without specifying, to boot several daemons at the same time and then 
boot other daemons afterwards that depend on them having completely 
launched.  Similarly with devices being available.  This is why people 
have to put in ugly hacks like sleep in daemons that require the network 
to be up. You really don't need to read in a shell script to find where 
and how a config file is used. With SysVinit you have a rc script in 
/etc/rc.d and the corresponding config file in /etc/conf.d, both have 
the same name and the config files are usually very well documented, 
either by comments or by a man page. And what's hard in reading a very 
short init script with only a few lines? Btw., most lines are always the 
same (function declarations, case structures, etc.). The only important 
part is usually only one line.

This is systemd internals. It's not expected from the user to play
with symlinks.

Just like in proprietary software. Once again: Why does it need such
symlinks in some cryptic directories? The point is, I want to have full
control over my system and not to rely on some software's internals.
And I don't want to read source codes to know what an init system is
doing. And full control includes knowing what file is saved where and
doing what.

OTOH for the systemd case, we are changing of paradigm for the boot
process. I'm not aware of such a change in the boot process for years.
All recent event-based init systems have raise fear.

Which init systems? I only know SysVinit. And why wasn't there a change
for years? Actually there was never a change. Because this init system
is so bad? I would rather say because it's so well tested and approved,
and because it's simple and just works and does what it is supposed to
do.
Odd, Arch uses SysV's init, but it certainly doesn't have a SysVinit 
init system. It's much closer to BSD, and a lot of the tools we use are 
custom.
Others include OpenRC (used by Gentoo), Upstart (used by Ubuntu) and of 
course systemd (used by Fedora)

Maybe there are things that can be improved. Maybe there is code which
has to be written or executed more than once with SysVinit. Well, this
could be changed and improved. If this justifies a complete new init
system is questionable I think.

Heiko

Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.

[Stephen E. Baker]

On 24/07/2012 11:08 AM, Leonid Isaev wrote:

On Tue, 24 Jul 2012 16:07:50 +0200
Heiko Baums li...@baums-on-web.de wrote:


Am Tue, 24 Jul 2012 23:40:51 +1000
schrieb Gaetan Bisson bis...@archlinux.org:

Yes, I don't like those Windoze like ini files of systemd, too.

One thing I noticed is that the only people who usually bash Windows are those
who don't develop or know very little about programming. What exactly is wrong
with ini files and/or registry? Perhaps it is your misunderstanding...
I assure you, lots of developers, even (or maybe especially) Windows 
developers bash windows.  The key is not throwing the baby out with the 
bath water.


Ini style files are both easy to parse and easy to read - there's no 
reason not to copy the format.


Certainly these systemd target files etc. are easier to read and manage 
than the initscripts were.


It may take some getting use to not being able to see everything in 
DAEMONS, but the benefits to the maintainers and to me if I ever need to 
tweak something beyond what gets run in what order, more than offset that.

Over time various linux projects took a lot from windows: gconf/dconf
(~registry), KDE4 indexing services (~superfetch/desktop indexing),
systemd-journald (~windows event viewer). This is real, get used to it.



The registry is more debatable.  (Having all your config in one place is 
nice, but when that one place is an inconsistent mess that can only be 
managed by a mediocre special purpose tool it loses it's benefits.)  I 
think I would be very upset if they wanted to move rc.conf into a gconf 
like interface.  As is though I find it hard to complain.


I generally like Windows events except for some of the pointless make 
work of registering each message ahead of time in your message.dll 
(which .NET hacks around).  That said I've never had any issue with 
/var/log/*.

Re: [arch-general] Muting internal speakers

[Stephen E. Baker]

On 15/06/2012 8:30 PM, Oon-Ee Ng wrote:

Still not on my laptop, but I searched around, posted it a while back on
the pulseaudio wiki. Here it is

http://www.freedesktop.org/wiki/Software/PulseAudio/FAQ#How_do_I_switch_the_default_sound_card.2C_moving_all_applications.3F

Again, not sure if by now there's a way to run this script whenever a card
is plugged in and out, if you do find that let me know =).  Like I said, I
just bind the script to a shortcut key using xbindkeys


I'm not sure how 'recommended' it is, but there is a method of running 
scripts when devices are plugged in using udev rules.  There is a guide 
here 
http://www.banquise.org/hardware/how-to-automatically-run-a-script-after-inserting-a-usb-device-on-ubuntu/ 
though it involves being able to identify which device your usb sound 
device is.


(Rather than blindingly following the example I recommend reading 
through http://www.reactivated.net/writing_udev_rules.html to understand 
what you are doing)

Re: [arch-general] Muting internal speakers

[Stephen E. Baker]

On 18/06/2012 9:48 AM, Ralf Mardorf wrote:

On Mon, 2012-06-18 at 15:41 +0200, Ralf Mardorf wrote:

On Mon, 2012-06-18 at 08:34 -0400, Stephen E. Baker wrote:

it involves being able to identify which device your usb sound
device is.

So run:
udevinfo -a -p /sys/block/sda
(replace sda with you device) -
http://www.banquise.org/hardware/how-to-automatically-run-a-script-after-inserting-a-usb-device-on-ubuntu/

What is the name for the sound device?

FWIW, you get unique device name listed in /proc/asound/

A Swissonic device
spinymouse@precise:~$ ls -hAl /proc/asound/ | grep card3
dr-xr-xr-x 2 root root 0 Jun 18 15:14 card3
lrwxrwxrwx 1 root root 5 Jun 18 15:14 U0x170b0x11 -  card3
A Korg device
spinymouse@precise:~$ ls -hAl /proc/asound/ | grep card3
dr-xr-xr-x 2 root root 0 Jun 18 15:14 card3
lrwxrwxrwx 1 root root 5 Jun 18 15:14 nanoKONTROL -  card3

but what names are used for udevinfo -a -p /sys/block/[...]?

spinymouse@precise:~$ ls /sys/block/
loop0  loop2  loop4  loop6  ram0  ram10  ram12  ram14  ram2  ram4  ram6
ram8  sda  sr0
loop1  loop3  loop5  loop7  ram1  ram11  ram13  ram15  ram3  ram5  ram7
ram9  sdb

Resp. in /sys/whatever

/sys/block/ is block devices (i.e. hard drives, potential ram drives, 
loop back devices), so it wouldn't be in there.   I'm not sure where in 
/sys it would be, but if you check the last few lines dmesg after 
plugging it in it should tell you.

Re: [arch-general] drop slim in favor of lightdm

[Stephen E. Baker]

On 08/05/2012 5:14 AM, Allan McRae wrote:

On 08/05/12 18:35, Christian Hesse wrote:

Hello everybody,

slim has some known security weaknesses (for example it has no separate
greeter process thus the graphical interface is running with super user
privileges) and a lot of open bugs. Additionally it does not support latest
packages (consolekit and friends) out of the box.
Though lately the SVN got some commits and a new version has been released
the arch package has not been updated since it was flagged out of date in
February.
[snip]


https://bugs.archlinux.org/index.php?string=slim

Seems to be a severe lack of bug reports made if there are so many
issues with it...
I had lots of issues when I used slim, but replaced it easily lxdm.  
slim isn't a default and there are lots of choices available (including 
other lightweight ones) so I don't see how adding lightdm and dropping 
slim are connected.

Allan

[arch-general] Merge /bin to /usr/bin?

[Stephen E. Baker]

A few days ago it was announced that Fedora 17 will be merging several 
root directories into their /usr equivalents and using symlinks for 
compatibility.  The announcement can be found here: 
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/158708


There are several good reasons for the change, outlined at: 
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge  
I wondered if this was something Arch was considering as well.


Stephen E. Baker

Re: [arch-general] some notes on the radeon gallium driver

[Stephen E. Baker]

 My understanding is that r300g is the new default in Mesa 7.9. See
 http://www.mail-archive.com/mesa-com...@lists.freedesktop.org/msg23390.html
 . Does this mean that Arch will automatically switch to it on release
 of Mesa or will extra steps be required?

As I understand it the PKGBUILD will also have to be altered.  The
driver will be built by default but not installed to
/usr/lib/xorg/modules/dri/ as mentioned by Stafano.  The purpose of
having both drivers built is so that one could experiment with the
gallium driver with export LIBGL_DRIVERS_PATH = ... before executing
particular opengl programs without switching outright.

I've been doing this for a couple weeks now with the git version of
just the r300g driver running with Arch's packaged mesa 7.8 and have
found that it has fixed all the bugs I was having in Neverwinter
Nights and eduke32 with no new problems besides the occasional
stuttering when fps drops too low.  I would vote for making it the
default in Arch with mesa 7.9.