Phidgets under Arch

Hi,
I am a complete newbie re: Phidget programing in Linux (or any other USB programming for that matter). I wonder what I need to write a simple app to test a phidget device under Arch Linux. Do I need to install libphidget21 from Phidget.com or can I just use the kernel USB phidget drivers?
My thanks in advance!

any response at all...I know people here can fix this...it did work in out of the box in ubuntu after all

Similar Messages

Progress on Unity under Arch Linux!

See here for information about the new GNOME 3.12-compatible packages: https://bbs.archlinux.org/viewtopic.php … 3#p1404683
I'm now on IRC! Come join us at #unityforarch on Freenode
To install Unity from my repos:
See the wiki: https://wiki.archlinux.org/index.php/un … mmended.29
To install Unity from source:
See the wiki: https://wiki.archlinux.org/index.php/unity#From_source
-- You probably don't want to read anything below --
The story
So...rather than wasting internet bandwith to download a new Ubuntu ISO to test out the new Unity features, I decided to try to make it work under Arch Linux. It took a whole lot longer than I expected to get it even partially working. So, here's my story:
Knowing that Unity isn't in the main repositories, I went the AUR's website and looked for a user created Unity package. That didn't go too well. The Unity package hasn't been updated for 6 months. D'oh! I decided to download the existing PKGBUILD and modify it to work with the Unity 4.xx series. After changing the version number, I tried to "makepkg" it, and was greeted with a message about installing Compiz 0.9.x. I thought it would be an easy install. It was quite the opposite. Compiz's install prefix was set to /opt/unity, but FindCompiz cmake build file expected Compiz to be in /usr, so none of the Compiz packages, except for compiz-core would compile. Then, I tried reinstalling compiz-core, but this time, changing the prefix to /usr. The compiled package ended up being only a few kilobytes big. I guess the mouse wheel was invented for a reason. I looked at the PKGBUILD again, only to find that there was a line at the very bottom that ran "rm -rf ${pkgdir}/usr". That explains a lot! I ended up adopting all the compiz*-git packages and fixing them so they would compile and install.
So, now that Compiz is working (restarted and tested just to make sure I didn't waste my time with something that didn't work), I went on to install the rest of the dependencies listed in the Unity PKGBUILD file. That went relatively well. I was so happy after seeing the progress counter go up after running "makepkg", but at about 8%, gcc spat out an error about an undeclared function (sorry, I forgot what the function was). Natually, I went to Google and searched the name of the function. 0 results! Exactly was I was looking for! I ended up downloading the Ubuntu 11.10 Alpha 3 ISO and running "find -type f /usr/lib | xargs objdump -T | grep the_function". The problem lied in the libindicator package. There was a newer version available which contained that function. I have no idea why a package that's only 0.02 versions ahead of the AUR package would contain new functions...
Next! Utouch...ugh...great memories! Not! I was so glad that I had fixed the utouch packages earlier (for touchegg to work). I was too frustrated from compiz and libindicator to try to compile more stuff.
Cmake. Whoever created the CMakeLists.txt file didn't list all the dependencies required. So after running "makepkg" 10 billion times, waiting for "somebodydidntputthisincmake.h not found" errors to appear, I finally got all the dependencies I needed installed...or so I thought. After installing and compiling all these dependencies, the cmake only continues 3% further before encountering another cryptic gcc error. This time, there no error about a file not being found. So not knowing what dependency was missing, I headed over to http://packages.ubuntu.com and downloaded the Unity DEB source to find the dependencies in then debian/control file. After install those few dependencies that I missed, I ran "makepkg" again, hoping that it would finally compile successfully. CMake went a little further--5% further to be exact--before running into another error. It complained about DndSourceDragBegin() having two return types. Sure, enough "./plugins/unityshell/src/ResultViewGrid.h" had the return type as boolean and "/usr/include/Nux-1.0/Nux/InputArea.h" had the return type as void. WTF? How the heck does this even compile under 11.10???
After changing void to bool in "/usr/include/Nux-1.0/Nux/InputArea.h", I ran "makepkg" once again anxiously waiting to the see the line "Finished making: unity 4.10.2". CMake compiled about 35% before running into error about an undeclared gtk function. Nooooooooooooo!!! I wasn't brave enough to install the git version of gtk3, so I created a chroot, installed the base packages, and installed all of those dependencies fairly quickly (it gets a lot easier after doing it so many times).
Moving on to gtk3. After cloning the ~200MB git repository, autotools spits out an error about cairo-gl missing. So, I proceeded to install the cairo-gl-git package, which failed to compile (it compiled successfully outside of the chroot...). GREAT. So, Unity fails to compile because GTK version is too old, and GTK failed to compile because cairo-gl is missing, and cairo-gl fails to compile because I'm in a chroot. GAHHH!!! While thinking about throwing the computer out of the window, I searched the AUR for other GTK3 packages. I just happened to find a package named "GTK3-UBUNTU"! That package was still at version 3.0, but it was pretty easy to get the patches and source code for 3.1 from the Ubuntu GTK source package.
So, FINALLY, Unity compiles. I was so darn happy, I didn't even care if it ran or not. I logged out and logged back into the GNOME 3 fallback mode, and entered the chroot. After running "xhost +SI:localuser:chenxiaolong" to run X11 apps in the chroot, I crossed my fingers and ran "DISPLAY=:0.0 unity --replace". It failed with python 3 complaining about missing modules. That's okay, since the Unity launch script is written in python 2. I changed the shebang line in "/usr/bin/unity" to point to python 2 and ran "DISPLAY=:0.0 unity --replace". It didn't necessarily fail, but it didn't succeed either. It didn't print out any error messages. Weird... I thought I'd try enabling Unity from the compiz settings manager then. I ran "DISPLAY=:0.0 compiz --replace" and "DISPLAY=:0.0 ccsm" and enabled the Unity plugin. Unity runs! Although nothing shows on the screen, it runs! It shows up in the process list! Woohoo!
And that's about how far I got. There were quite a few Vala errors during the compiling process (I forgot which package it was), which is probably why Unity won't appear. I'll try again later with the vala-devel or vala-git package and hopefully Unity will work then. Here are screenshots of what I've gotten working so far:
http://i.imgur.com/7F1fm.jpg
http://i.imgur.com/zGNJc.jpg
http://i.imgur.com/3mCgd.jpg
By then way, I love the simplicity of pacman and the AUR. I can't imagine how long this would have taken with other package managers.
Moderator edit: Do not place large images in line. If you want, you may embed links to thumbnails inside url tags.
Last edited by chenxiaolong (2014-04-15 17:11:04)

City-busz: I'm getting a ton of Vala errors when I compile libunity (AUR version) with vala or vala-devel. libunity fails to compile with vala-git. I'll try your packages in a virtual machine and see how they work on 64 bit.
In the meantime, Unity still fails to show up: http://i.imgur.com/btPwo.png I'll try out your PKGBUILDS and see how that works. I'm glad there are people who want to port Unity to Arch Linux
EDIT: City-busz: Just to let you know, Unity will fail to compile at around 45% with GTK 3.0. Here's my source packaage for Ubuntu's GTK 3.1: http://ubuntuone.com/p/1EzX/ It contains all of the patches in the Ubuntu source package. I'm not sure if all the patches are needed, but GTK compiles fine with all of them.
EDIT2: Right now, I'm trying to compile Vala 0.10.4, then version used in Ubuntu 11.10. Hopefully that will eliminate some of the Vala errors.
EDIT3: Vala 0.10 is too old. 0.12 and 0.14 are also in the Ubuntu repository. Trying those...
EDIT4: 0.14 is actually 0.13.1. Gah... Vala takes longer to compile under VirtualBox than GTK3...
EDIT5: Okay...so VirtualBox "helpfully" became slow enough that I could read the error messages. The Vala error messages aren't actually error messages, but rather warnings about unused methods. I wonder what prevents Unity from running then...
Last edited by chenxiaolong (2011-08-30 02:30:29)

Is somebody developing in Action Script under Arch?

Hi!
Not sure it's the right place to post this, but at work I had all the pain in the world to set up an Action Script development under Debian (that's the distro I am using at work) and finally had to work under Windows. There was no free IDE and it was impossible at least for me to install a debug version of flash.
Now I am finding the possibilities of Action Script interesting, and would like to use it for some personal projects at home (where I run Arch). I am curious to know if someone else is using Action Script under Arch, and in which case, what are their setups and if they had any problem to install everything they need.
Thanks!

I used to code in ActionSrcipt.
I never had any real problems with it and I have workded for over 15 years in Linux only OSes.
I always used my prefered editor ( at the time it was vim I think ) and then did all my testing in the browser by running the flash movie.
The question you have to ask yourself is: Is it really worth for me to spend time with it?
ActionScript is tyied to Flash ... and Flash is in it's "way out". Sure it will not disappear tomorrow but it's just a matter of time. Heck even Adobe acknolledge that...
To me, if you just like coding ActionScript, then go to JavaScript. AS is just JS with adaptations to the movie playing engine of Flash.
Hope this helps.

Probably broken initrd, how to create one anew under Arch

Hi again,
I managed to install Arch on my USB flash drive which I partitioned /dev/sdb1 to be /boot,
/dev/sdb2 = PV of vgarch with one lv_root and one lv_var, and swap as /dev/sdb5 (first partition in extended part.)
The FTP install went fine after I had mounted /boot and the LVs / and /var.
I also successfully ran the setup afterwards, editing each config file, even those where I didn't apply any modifications.
Finally, I installed grub in the MBR of the USB drive, viz. /dev/sdb.
When asked during the configuration what modules I would require during boot
I confirmed LVM, RAID and included dm-mod manually in the MODULES array.
Nevertheless, the initial RAM disk must have been created incorrectly.
Because when I boot from the stick
the grub menu appears and when the default entry gets started I get the error message:
Booting 'Arch Linux'
root (hd1,0)
Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz26 root=/dev/mapper/vgarch-lv_root ro
Error 15: File not found
Press any key to continue...
I know that something must have gone wrong while createing the initrd file.
Sorry, right now I cannot even mount my USB stick in the running Xubuntu from where I write this posting.
The reason is pretty daft, as I was too unwary.
Being used to the RHEL/CentOS initrd image files (where absolute path names are stripped)
I instantly did the following mess and buggered up my running Linux.
# mkdir /tmp/arch
# cd /tmp/arch
# gzip -dc /media/disk/kernel26.img | cpio -di
Ouch, this overrode many important binaries
I should have first piped it into
... | cpio -ti | less
or at least
... | cpio -di --no-absolute-filenames
Did I mention that I haven't made a backup
Never mind, this is a surf only installation anyway which I quickly can replace.
After having extracted the cpio image with stripped absolute paths I looked at the init script.
On RHEL/CentOS there is the mkinitrd script to recreate the initial RAM disk more easily
than from scratch.
Exists something similar under Arch?
Last edited by archIbald (2008-08-31 22:20:09)

MKINITCPIO(5)    MKINITCPIO(5)
NAME
mkinitcpio - Create an initial ramdisk environment
SYNOPSIS
mkinitcpio [OPTIONS]
DESCRIPTION
Creates an initial ramdisk environment for booting the linux kernel.
The initial ramdisk is in essence a very small environment (early
userspace) which loads various kernel modules and sets up necessary
things before handing over control to init. This makes it possible to
have, for example, encrypted root filesystems and root filesystems on a
software RAID array. mkinitcpio allows for easy extension with custom
hooks, has autodetection at runtime, and many other features.
OPTIONS
-c config
   Use config file to generate the ramdisk. Default:
   /etc/mkinitcpio.conf
-k kernelversion
   Use kernelversion. Default is the current running kernel.
-s filelist
   Saves a list of all the files in the initial ramdisk in filelist.
   Default: no; This means the filelist will not be retained if this
   option isn´t specified. Useful for debugging purposes.
-b basedir
   Use basedir as a starting point for gathering information about the
   currently running system. Default: /.
-g filename
   Generate a CPIO image as filename. Default: no; this means nothing
   will be written to the filesystem unless this option is specified.
-a filelist
   Append to an existing filelist. Default no.
-p preset
   Build initial ramdisk according to specified preset. Presets are
   found in /etc/mkinitcpio.d
-m message
   Print message before passing control to kinit.
-S hooks
   Skip hooks when generating the image. Several hooks should be
   comma-separated.
-v
   Verbose output. Outputs more information about what´s happening
   during creation of the ramdisk.
-M
   Display modules found via autodetection. mkinitcpio will
   automatically try to determine which kernel modules are needed to
   start your computer. This option lists which modules were detected.
-L
   List all available hooks.
-H hookname
   Output help for hookname hookname
-h
   Output a short overview of available command-line switches.
ABOUT HOOKS
A hook is a script that executes in the initial ramdisk. The order and
which scripts are executed is found in the HOOKS=() array in the
mkinitcpio configuration file. A hook will, for example, set up the
udev device filesystem, load IDE modules, etc...
ABOUT PRESETS
A preset is a pre-defined definition on how to create an initial
ramdisk. Instead of specifying the configuration file and which output
file, every time you generate a new intial ramdisk, you define a preset
and use the -p switch to generate an initial ramdisk according to your
preset. Presets are located in /etc/mkinitcpio.d
FILES
/etc/mkinitcpio.conf
   Default configuration file for mkinitcpio.
/etc/mkinitcpio.d
   Folder containing mkinitcpio presets.
/lib/initcpio
   Files related to creating an initial ramdisk.
EXAMPLES
mkinitcpio
   Perform a dry-run. This will generate an initial ramdisk but will
   not write anything. Use -g to create the real image.
mkinitcpio -p kernel26
   Create an initial ramdisk based on the kernel26 preset.
SEE ALSO
A more thorough article on configuring mkinitcpio:
<http://wiki.archlinux.org/index.php/Con … mkinitcpio>
initrd(4)
BUGS
Upon writing this manpage, there were no noticeable bugs present.
Please visit <http://bugs.archlinux.org/> for an up to date list.
AUTHORS
mkinitcpio created by the Arch Linux Developer community.
Manpage written by:
   · Glenn RedShift Matthys <[email protected]>
Manpage contributions by:
   · Jens byte Adam <[email protected]>
   · Geir gejr Vaagland
   · Joerie Thralas de Gram <[email protected]>
VERSION INFORMATION
Manpage written for mkinitcpio 0.5.17
COPYRIGHT
Copyright (c) Arch Linux
   03/16/2008    MKINITCPIO(5)

Deluge under arch linux - one observation

Hello,
There were various problems with deluge bittorrent client under arch linux, but it seems to work if no plugins are enabled.
This is with deluge version 1.1.9 run under a "normal" user account (not started from /etc/rc.d/deluge).
Kind regards,
Vlad

By Which plugin can't it work? and please post the message from terminal.

Making Echo Mia (Midi) sound cards work under Arch [FIXED]

This guide will install and setup the Echo Mia (Midi) under Arch using ALSA.
Make sure ALSA is installed properly. If not,
# pacman -S alsa-utils
will do the trick.
We will then need to install Echo Mia ALSA drivers, firmware and the Echomixer.
First, check what versions of alsa-lib and alsa-utils are installed by running:
$ pacman -Q alsa-utils
Then download the sources for ALSA:
wget ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.x.tar.bz2
wget ftp://ftp.alsa-project.org/pub/firmware/alsa-firmware-1.0.x.tar.bz2
wget ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.x.tar.bz2
tar xjvf alsa-driver-1.0.x.tar.bz2
tar xjvf alsa-firmware-1.0.x
tar xjvf alsa-tools-1.0.x
where x is replaced as needed with the correct version.
Then we compile the driver with support for mia.
cd alsa-driver-1.0.x
./configure --with-cards=mia
make
sudo make install
Then we install the firmware for the card.
cd ../alsa-firmware-1.0.x
./configure
make
sudo make install
Then we install the echomixer.
cd ../alsa-tools-1.0.x/echomixer/
./configure
make
sudo make install
Now we need to add the snd-mia module to the modules line in /etc/rc.conf. If there are other sound modules active, that conflict with the snd-mia module, disable them. In my case, I had to disable my snd-hda-intel, prefixing it with a '!'.
Now, we have to edit some configuration files.
This should be the only content of ~/.asoundrc:
pcm.mia {
type hw
card 0
ctl.mia {
type hw
card 0
Then, add this to /etc/modprobe.conf:
# ALSA portion
alias char-major-116 snd
alias snd-card-0 snd-mia
# module options should go here
# OSS/Free portion
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
# card #1
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
Now would be the time to reboot.
After rebooting, make sure that the snd-mia module was loaded.
Run echomixer and activate the VU meter. If the sound module was loaded properly, the VU meters should be active and floating in the -80 to -100 dB region (background noise). If this is the case, we should have a functional mia soundcard. Most audio programs will still not work despite the module being active, however, we can test the sound output with the aplay command. Next step would be to raise the mixer values to good levels using the echomixer. This could also be done via the alsamixer in terminal.
After the sound output is confirmed, achieving normal sound output using standard ALSA can get rather messy, and sound mixing is not working out of the box. The sound driver often crashed also while trying to play more sounds at the same time.
The solution to this problem is using PulseAudio, which allows mixing, and enables applications to use Mia without further tinkering.
Installation is straight forward, following the guide as shown on the PulseAudio wiki page. After installation of PulseAudio, the ~/.asoundrc should look like this:
pcm.mia {
type hw
card 0
ctl.mia {
type hw
card 0
pcm.pulse {
type pulse
ctl.pulse {
type pulse
pcm.!default {
type pulse
ctl.!default {
type pulse
As for the /etc/pulse/default.pa, it shouldn't be needed to be changed. If problems arise when loading PulseAudio, make sure that pulseaudio is loaded after hal, as it is needed for detection by PulseAudio.
Now, go back to /etc/rc.conf, and the DAEMON line should look something like this:
DAEMONS=(@syslog-ng @network @netfs @crond fam hal alsa pulseaudio mpd @slim)
The important part are that hal, alsa and pulseaudio are loaded sequential after eachother. After a reboot, it should work.
Last edited by Themaister (2008-10-07 15:31:33)

This guide will install and setup the Echo Mia (Midi) under Arch using ALSA.
Make sure ALSA is installed properly. If not,
# pacman -S alsa-utils
will do the trick.
We will then need to install Echo Mia ALSA drivers, firmware and the Echomixer.
First, check what versions of alsa-lib and alsa-utils are installed by running:
$ pacman -Q alsa-utils
Then download the sources for ALSA:
wget ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.x.tar.bz2
wget ftp://ftp.alsa-project.org/pub/firmware/alsa-firmware-1.0.x.tar.bz2
wget ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.x.tar.bz2
tar xjvf alsa-driver-1.0.x.tar.bz2
tar xjvf alsa-firmware-1.0.x
tar xjvf alsa-tools-1.0.x
where x is replaced as needed with the correct version.
Then we compile the driver with support for mia.
cd alsa-driver-1.0.x
./configure --with-cards=mia
make
sudo make install
Then we install the firmware for the card.
cd ../alsa-firmware-1.0.x
./configure
make
sudo make install
Then we install the echomixer.
cd ../alsa-tools-1.0.x/echomixer/
./configure
make
sudo make install
Now we need to add the snd-mia module to the modules line in /etc/rc.conf. If there are other sound modules active, that conflict with the snd-mia module, disable them. In my case, I had to disable my snd-hda-intel, prefixing it with a '!'.
Now, we have to edit some configuration files.
This should be the only content of ~/.asoundrc:
pcm.mia {
type hw
card 0
ctl.mia {
type hw
card 0
Then, add this to /etc/modprobe.conf:
# ALSA portion
alias char-major-116 snd
alias snd-card-0 snd-mia
# module options should go here
# OSS/Free portion
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
# card #1
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
Now would be the time to reboot.
After rebooting, make sure that the snd-mia module was loaded.
Run echomixer and activate the VU meter. If the sound module was loaded properly, the VU meters should be active and floating in the -80 to -100 dB region (background noise). If this is the case, we should have a functional mia soundcard. Most audio programs will still not work despite the module being active, however, we can test the sound output with the aplay command. Next step would be to raise the mixer values to good levels using the echomixer. This could also be done via the alsamixer in terminal.
After the sound output is confirmed, achieving normal sound output using standard ALSA can get rather messy, and sound mixing is not working out of the box. The sound driver often crashed also while trying to play more sounds at the same time.
The solution to this problem is using PulseAudio, which allows mixing, and enables applications to use Mia without further tinkering.
Installation is straight forward, following the guide as shown on the PulseAudio wiki page. After installation of PulseAudio, the ~/.asoundrc should look like this:
pcm.mia {
type hw
card 0
ctl.mia {
type hw
card 0
pcm.pulse {
type pulse
ctl.pulse {
type pulse
pcm.!default {
type pulse
ctl.!default {
type pulse
As for the /etc/pulse/default.pa, it shouldn't be needed to be changed. If problems arise when loading PulseAudio, make sure that pulseaudio is loaded after hal, as it is needed for detection by PulseAudio.
Now, go back to /etc/rc.conf, and the DAEMON line should look something like this:
DAEMONS=(@syslog-ng @network @netfs @crond fam hal alsa pulseaudio mpd @slim)
The important part are that hal, alsa and pulseaudio are loaded sequential after eachother. After a reboot, it should work.
Last edited by Themaister (2008-10-07 15:31:33)

Anyone using an SSD under Arch? Please post a quick benchmark

I'm considering an SSD for my Linux root and /home. If you're using an SSD under Arch, can you please run a quick benchmark for me and post the results in this thread? You can use hdparm to do a quick read test. Here is an example using my HDD.
# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 14500 MB in 2.00 seconds = 7258.88 MB/sec
Timing buffered disk reads: 368 MB in 3.01 seconds = 122.16 MB/sec
Beyond that, have you noticed any substantial speed ups over an HDD, like launching programs, booting the system, etc.

Perhaps use of IDE-MODE flash devices will provide best answers with the hdparm measure. It does a sequential test which is hardly normal for operating systems.
Usual performance from ide mode flash devices is 45mb/sec but in practice may be a bit less in hdparm. Two ide mode flash drives in raid0 give me less than 90 mb/s. My use is for quick access storage, mostly read-only. When first installed, 90 mb is possible but within a few weeks, it lessens to the mid 80"s even with read-only.
The performance over time lessens if the units are used as SSD and such is normal wear and tear. Many articles cover the subject and the methods used to minimize the effects.
Much is going forward with SSD and expectation is that in a few years they will be in wide use. This remains to be seen!
You may be aware of all so excuse my oops!

Dd, gzip using split under Arch and FreeBSD ?

Hello Archers,
Not sure where to post this question so I'll try here. Would anyone know the FACTS why the command below runs super fast under Arch-2009.08 and Fedora-12 but runs very slow under FreeBSD 8.1?
Notice; I did not not specify a block size for neither OS, so according to the DD documentation it is reading/write 512 blocks at a time from an unbuffered device and as you see ARCH runs like a bat-out-of-hell, regardless.
The only thing I figure is ,,, ARCH-LINUX must be bumping up the default size with-out the user knowledge when no size has been specified by user. Would this be true?
I notices this tooooo many times in the pass but this time I documented it for proof because I thought it was my imagination most of the time. I use all three OS by dual-booting when needed, and I use the same code below so they can backup each other when I make configuration changes in either OS. Machine don't matter... old or new, P3 512MB RAM or Phenom-II-965-QUAD - 8GB RAM, same results.
Same Command:
dd if=/dev/sda3 | gzip -c | split -b 3500m - /12/File-Name-dd-By-Arch-Linux.gz.
ARCH-2009 - 1,504,432,145,920 bytes - 150GB = 2118sec = 35min = 1/2 hour - 71 MB/s
dd if=/dev/ad4s3 | gzip -c | split -b 3500m - /12/File-Name-dd-By-FreeBSD.gz.
FBSD 8.1 - 1,504,432,145,920 bytes - 150GB = 16652sec = 277min = 4 1/2hour - 9033694 b/s
293,812,785 + 0 record in
293,812,785 + 0 record out

I learn that it's a BLOCK vs CHAR thing. Linux use BLOCKS.
I use ARCH to control all my HDD's ... Running GRUB and dd'ing to backup all partitions with Windows Vista, Windows-7, FreeBSD Packet filters and routers. If you use the command I posted it may have an issue if you turn on top during dd'ing a large partition. I been dd'ing with ARCH with success for over a year and will not be cash out any time soon. I just learn what to do and what not to do until it is fix. Don't mean to cross-websites but maybe the author would like to know.
Here's the story ...
http://www.daemonforums.org/showthread. … 6a2&t=5503
Last edited by sharris (2010-12-31 15:38:46)

Conky font differences under Arch compared to Ubuntu [SOLVED]

I'm using the same basic .conkyrc when I'm booted into Arch as I do when I'm booted Ubuntu. For some reason, the one under Ubuntu looks different font-wise. In the screenshot below, Arch has the light blue background while Ubuntu has the slate colored one. Anyone know what might be causing this?
Here is the first part of the ~/.conkyrc
background no
own_window yes
own_window_type override
own_window_transparent yes
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager
out_to_console no
# X font when Xft is disabled, you can pick one with program xfontsel
#font 7x12
#font 6x10
#font 7x13
#font 8x13
#font 7x12
#font *mintsmild.se*
#font -*-*-*-*-*-*-34-*-*-*-*-*-*-*
#font -artwiz-snap-normal-r-normal-*-*-100-*-*-p-*-iso8859-1
# Use Xft?
use_xft yes
# Xft font when Xft is enabled
xftfont Bitstream Vera Sans Mono:size=8
#own_window_transparent no
#own_window_colour hotpink
# Text alpha when using Xft
xftalpha 0.8
on_bottom yes
# Update interval in seconds
update_interval 2
# Create own window instead of using desktop (required in nautilus)
#own_window no
# Use double buffering (reduces flicker, may not work for everyone)
double_buffer yes
# Minimum size of text area
#minimum_size 250 5
maximum_width 258
# Draw shades?
draw_shades no
# Draw outlines?
draw_outline no
# Draw borders around text
draw_borders no
# Stippled borders?
stippled_borders 10
# border margins
border_margin 4
# border width
border_width 1
# Default colors and also border colors
default_color white
default_shade_color white
default_outline_color white
# Text alignment, other possible values are commented
#alignment top_left
#minimum_size 10 10
#alignment top_right
alignment bottom_left
#alignment bottom_right
# Gap between borders of screen and text
gap_x 12
gap_y 37
# Add spaces to keep things from moving about? This only affects certain objects.
use_spacer no
# Subtract file system buffers from used memory?
no_buffers yes
# set to yes if you want all text to be in uppercase
uppercase no
EDIT: the solution to this problem is described in post #12.
Last edited by graysky (2009-04-25 14:32:59)

Ashren wrote:Please check the output of "xdpyinfo | grep dots" it usually should be 96x96 dpi. My bet is that your dpi is wrong. If you're in KDE/Gnome you set the dpi in the DE. If you're using something else one solution is to add "xrandr --screen 0 --dpi 96x96" to your .xinitrc.
Here is the output:
$ xdpyinfo | grep dots
resolution: 90x88 dots per inch
I'm using Gnome but can't seem to locate a section to change my dpi. I'm using the nvidia driver (8800GS) but didn't see an area under nvidia-settings to change it either. I tried that xrandr line you proposed, upon restarting gdm, the setting didn't take:
$ xdpyinfo | grep dots
resolution: 90x88 dots per inch
Here is my ~/.xinitrc
#!/bin/sh
# ~/.xinitrc
# Executed by startx (run your window manager from here)
exec gnome-session
xrandr --screen 0 --dpi 96x96
Thanks!
Last edited by graysky (2009-04-23 18:37:22)

[Solved] g++ (in geany) building errors under Arch

I am having some issues with g++ (in geany) failing to build my programs correctly. I used Geany under Ubuntu with no issues with any of my code. To give some context though, I am taking an intro CS class, and the book is about 10 years old. As a result, a lot of my strategies might seem outdated or improper.
Specifically I am finding that the cin.get command runs through:
// Example of Dysfunction
#include<iostream>
using namespace std;
int main()
int a;
char test[3];
cout<<"What does 2 + 2 = "<<endl;
cin>>a;
cout<<"Define the string: ";
cin.get(test, 3);
cin.ignore(80, '\n');
return 0;
This was executed correctly in Ubuntu. When executed in Arch it does the first "cin>>a", then it runs to the end skipping the "cin.get". Any assistance?
Last edited by nanix (2010-12-04 14:57:51)

drcouzelis wrote:
I think I Duck Duck Go'd the solution! http://www.augustcouncil.com/~tgibson/t … l#problems ("std::cin.getline() can run into problems..." section)
I'm not sure why it worked before.
Ha, I never considered it was a problem with things left in the buffer with "cin>>a". Thank you for your assistance!
As for it working before, I still can't understand it. I am sitting here right now under ubuntu running the exact same code and it works.

Several problems under Arch

New to using Arch64 and having several problems.
Hal seems to be mounting a random 100mb partition from one of my windows XP NTFS drives.
Anything I download using firefox is corrupt, and does not appear under firefox's "downloads" section. - 2.0.0.6 (Any file downloaded is labeled a "plain text document" that is unreadable with 0 byte size)
My understanding is that Wine now offers a 64bit version, but this still requires multilib which arch is not, yet I've found no helpful guide to arrive at a multilib arch to use wine.
Does pacman not have a method for globally uninstalling no longer needed dependencies, or is this handled at the "pacman -Rd" level.

New problem is fglrx broke after a pacman -Syu (updated fglrx during it.)
# fglrxinfo
_X11TransSocketINETConnect() can't get address for localhost:6000: Name or service not known
Error: unable to open display :0
I was wrong on hal, after bringing the drive back i noticed the 100mb partition hal is mounting is "really" supposed to be my /boot partition. But when i boot up it uses the "boot" folder mounted on "/" named "boot" instead of "/dev/sdc1" which is supposed to be "/boot".
If I change it in fstab to mount /dev/sdc1 partition correctly as /boot, it boots from "/dev/sdc3"'s /boot instead, then loads /dev/sdc1 as "/boot" afterwards.
Any suggestions, it is hard to explain.

Lets discuss Apache under arch!

As a relatively new Arch-user(but still longtime linux-user mainly under Debian), I set out to setup a small local development-server consisting of mainly apache and mysql, and since I own a few domain-names, I was also going to set up some virtual hosts for certain subdomains.
While I rushed into doing this after installing apache and configuring systemd for it, I noticed my dear and beloved /etc/apache/sites-* and /etc/apache/modules-* system where nowhere to be found. I am met with a completely different system that reminds me more of the older almost single httpd.conf file, and a symlink to a modulesdir, all under /etc/httpd/ (!?).
This kind of setup is completely new to me, before if I wanted a virtual host, I just added a file to a directory and voila. Now I have to add every single virtual host into a single file!? On my old debian server I think I have like 10 different vhosts. If I wanted to activate an apache module I just created a symlink from /modules-available to /modules-enabled.
This is currently the biggest "issue" I wanted to duscuss, anyone who knows this system can you please share your thought on what I am supposed to do with it, what are the comfortable bits of this, and is it possible to revive parts of the old setup?
Also regarding the httpd-directory; With this thinking, what if I install another http-service I want to co-exist with apache, on another port? What would /etc/httpd/ contain? This part is just plain stupid to me right now.
The next issue: The new /srv-layout. It used to be /var/www and ~/www/ . Now I have a completely new rootfolder(something that seems to clutt it up even more actually, even though a www in /var was a little ugly.) Is /srv/ something I should just get used to?
Thanks for any thoughts on the matter!

Haikarainen wrote:This kind of setup is completely new to me, before if I wanted a virtual host, I just added a file to a directory and voila. Now I have to add every single virtual host into a single file!? On my old debian server I think I have like 10 different vhosts. If I wanted to activate an apache module I just created a symlink from /modules-available to /modules-enabled.
As someone with an RedHat and Arch background, I find the Debian way of Apache config arcane and annoying
Haikarainen wrote:This is currently the biggest "issue" I wanted to duscuss, anyone who knows this system can you please share your thought on what I am supposed to do with it, what are the comfortable bits of this, and is it possible to revive parts of the old setup?
Personally, as far as vhosts go, I create /etc/httpd/vhosts/ to hold a config file for each vhost, then create /etc/httpd/conf/extra/vhosts.conf that sets up the virtual hosting config, and includes vhosts/*
Haikarainen wrote:The next issue: The new /srv-layout. It used to be /var/www and ~/www/ . Now I have a completely new rootfolder(something that seems to clutt it up even more actually, even though a www in /var was a little ugly.) Is /srv/ something I should just get used to?
That's a long on-going debate in the Arch community. When you compare the FHS definition of each path, it does make sense to have your webroot(s) in /srv
/var = Variable files—files whose content is expected to continually change during normal operation of the system—such as logs, spool files, and temporary e-mail files.
/srv = Site-specific data which are served by the system.

Weird Shimmering Display Under Arch and Ubuntu Linux on GT72-QE with GTX 980M

Just bought one of these laptops to run CUDA applications while on the road and all went smoothly until I installed Linux and then activated X (Gnome/Unity/XFCE). I first noticed this under Ubuntu 14.04 LTS, and the behavior is the same Ubuntu 14.10 LTS, 12.04 LTS, and even Arch Linux. In all cases, I used the 346.59 NVIDIA display driver either obtained through the Edgers PPA or manually installed.
What I'm seeing is The laptop display shimmering as if the horizontal sync is slightly off. External displays look fine.
I've updated the BIOS of the laptop to the 10R version from March and that had no effect.
Has anyone gotten this thing to work under Linux (any linux distro) with the discrete GPU active? If so, how?

Another guy here with the same problem. We have to create a platform of users. We have spent a lot of money on our equipment; we deserve some quality costumer support. The problem is clear and the solution seems straightforward. It would not take a lot to fix our situation, but we need to team up.
MSI GT72 Dominator GTX 970M with FREEDOS
Now Dual Booting Windows 8.1 and Ubuntu 15.04
Nouveau driver is stable, but does not do the job. Nvidia-346 makes the screen flicker. Switching to integrated graphics (through windows) ubuntu runs perfect. I have tried everything during the last weeks.
I am new to the forum and I have very little time for myself; somebody please take the lead. It wouldn't be the first time I see costumers getting together and achieving support.
By the way, hi, my name is Álvaro

Low Bandwidth under Arch

Hi,
I just got an 100Mbit internet connection.
Running the test on:
http://www.speedmeter.de/speedtest/
I get 11Mbit/s vor my Linux and 97 Mbit/s with my Windows (same Laptop).
So what did I do wrong? I searched the forum for hints, but couldn't find the correct one.
what I did:
- used with/without netcfg
- used wpa_supplicant with nl80211 & wext (nl80211 gives me a higher bandwidth >100Mbit/s to the router. wext only the wireless-G 54Mbit. But thats not the problem)
- switched between brcmsmac & broadcom-wl
- installed pdnsd
- removed IPv6 module from loading
03:00.0 Network controller [0280]: Broadcom Corporation BCM43225 802.11b/g/n [14e4:4357] (rev 01)
Subsystem: Foxconn International, Inc. Device [105b:e021]
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at da400000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [58] Vendor Specific Information: Len=78 <?>
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [d0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-19-ff-ff-5a-c4-46
Capabilities: [16c] Power Budgeting <?>
Kernel driver in use: brcmsmac
Kernel modules: wl, brcmsmac
[root@iron ~]# cat /etc/hosts
# /etc/hosts: static lookup table for host names
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1 localhost.localdomain localhost iron
# End of file
[root@iron ~]# cat /etc/rc.conf
# /etc/rc.conf - Main Configuration for Arch Linux
# LOCALIZATION
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime", any other value will result
# in the hardware clock being left untouched (useful for virtualization)
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
LOCALE="de_DE.UTF-8"
DAEMON_LOCALE="no"
HARDWARECLOCK="localtime"
TIMEZONE="Europe/Berlin"
KEYMAP="de"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"
VERBOSE="3"
# HARDWARE
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed
# MOD_BLACKLIST: Prevent udev from loading these modules
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.
MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=() #deprecated
#MODULES=(vboxdrv cisco_ipsec acpi-cpufreq cpufreq-ondemand cpufreq-powersave)
MODULES=(acpi-cpufreq cpufreq-ondemand cpufreq-powersave)
# Udev settle timeout (default to 30)
UDEV_TIMEOUT=30
# Scan for FakeRAID (dmraid) Volumes at startup
USEDMRAID="no"
# Scan for BTRFS volumes at startup
USEBTRFS="no"
# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"
# NETWORKING
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
HOSTNAME="iron"
# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
# - prefix an entry in INTERFACES with a ! to disable it
# - no hyphens in your interface names - Bash doesn't like it
# DHCP: Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#Static IP example
#eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
#eth0="dhcp"
#INTERFACES=(!eth0 !wlan0)
# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
# - prefix an entry in ROUTES with a ! to disable it
#gateway="default gw 192.168.0.1"
#ROUTES=(!gateway)
eth0="dhcp"
INTERFACES=(eth0 wlan0)
#gateway= "default gw 192.168.0.1"
ROUTES=(!gateway)
#address=
#netmask=
#gateway=
NETWORK_PERSIST="no"
# Enable these network profiles at boot-up. These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
# - set to 'menu' to present a menu during boot-up (dialog package required)
# - prefix an entry with a ! to disable it
# Network profiles are found in /etc/network.d
# This now requires the netcfg package
NETWORKS=(wpa_suppl)
# DAEMONS
# Daemons to start at boot-up (in this order)
# - prefix a daemon with a ! to disable it
# - prefix a daemon with a @ to start it up in the background
DAEMONS=( syslog-ng dbus acpid hal alsa crond kdm laptop-mode @net-profiles)
Thanks for your Help if you can find my lost 90 Mbit/s

IronMania wrote:no :-(.
as I said it is an normal pci card. Has anyone else some hints?
Difficult to say... Some things to try (but without warranty). By the way I have a notebook with an internal wifi card connected to USB (but I do not say it is your case).
1) Be sure that the problem is real: make several tests. Is it consistent.
2) Do a iwlist scan and check that you are not on the same channel as another computer in the same building (that can make interference). Try to configure the wifi with a channel not close to the channel used by another computer.
3) Make sure the problem is related to the wifi: connect the computer with a cable and remake the test.
4) Connect a second computer to the same router via a cable (to not interfere with the Wifi) and test the speed between the two computers (give them static address within the same network, start sshd and transfer a big random file between the two computers).
5) Try another distribution and see if the problem persists. If not retry in arch with the same kernel version of the other distribution.
6) Disable any encryption (WEP WPA) and remake the test. What is the output of iwconfig?
Last edited by olive (2011-07-29 21:16:57)

How does power management work under Arch?

So, my Arch install doesn't have Suspend to RAM working. While trying to fix it, I was trying to understand the application chain that deals with power events such as lid close. I have read
https://wiki.archlinux.org/index.php/Acpid
https://wiki.archlinux.org/index.php/Laptop_Mode_Tools
https://wiki.archlinux.org/index.php/Po … CPI_events
Now, I have XFCE4 with its default power manager installed. I'm quite confused as to what it is that I need along with that to get things to work.
In short, which of the following configurations is *correct*, in the sense that it will work without manual configuration out of the box, or with minimal configuration, and has a graphical front-end controllable from XFCE?
- xfce4-power-manager
- systemd -> xfce4-power-manager
- systemd -> acpid
- systemd -> acpid -> xfce4-power-manager
Also, if I want to use laptop-tools, then does this change?
Lastly, how do I diagnose the suspend to RAM issue? How do I check whether suspend or resume from suspend is failing?

ashrj wrote:So, my Arch install doesn't have Suspend to RAM working. While trying to fix it, I was trying to understand the application chain that deals with power events such as lid close. I have read
Lastly, how do I diagnose the suspend to RAM issue? How do I check whether suspend or resume from suspend is failing?
If you are using Xfce you don't need acpid and instead of laptop-tools try TLP which enabled successful suspend to ram on an older laptop I had, with Xfce on it.

Phidgets under Arch

Similar Messages

Maybe you are looking for