Re: [gentoo-user] New project in perl? {OT}
On Sunday 02 January 2011 01:17:09 kashani wrote: Unless the language you're familiar with is completely unsuitable, I'd say familiarity trumps language features. I've been out of coding for too long to know much about modern languages (so ignore me if you like), but I think this is exactly right. Another language may have all the juicy, whiz-bang features you want for your shiny new project, but if the team doesn't know it you can't use it straight away, and you'll incur a substantial extra development cost. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
[gentoo-user] Re: UPS driver error
On Saturday 01 January 2011, Mick wrote:
Hi All,
I have a iDowell UPS with a USB connection which I'm trying to
configure with Gentoo. This UPS works fine with the default settings
in WinXP and apparently with AppleMac boxen which it is marketed for:
http://store.apple.com/uk/product/TR423ZM/A
This is what it shows in dmesg:
usb 3-2: New USB device found, idVendor=075d, idProduct=0300
usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
usb 3-2: Product: iBox
usb 3-2: Manufacturer: iDowell
usb 3-2: SerialNumber: 0001
generic-usb 0003:075D:0300.0002: hidraw1: USB HID v1.10 Device
[iDowell iBox] on usb-:00:1d.1-2/input0
I've added this udev rule in
# iDowell iBox USB
ATTR{idVendor}==075d, ATTR{idProduct}==0300, MODE=664,
GROUP=nut
and have defined this UPS and driver in /etc/nut/ups.conf:
[iDowell]
driver = usbhid-ups
port = auto
vendorid = 075d
desc = iBox by iDowell
However, the driver does not seem to recognise the device:
# /etc/init.d/upsd restart
* Starting upsd ...
Network UPS Tools upsd 2.4.3
listening on 127.0.0.1 port 3493
Can't connect to UPS [iDowell] (usbhid-ups-iDowell): No such file or
directory allowfrom in upsd.users is no longer used
[ ok ]
and
# /etc/init.d/upsdrv start
* Starting UPS drivers ...
Network UPS Tools - UPS driver controller 2.4.3
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
No matching HID UPS found
Driver failed to start (exit status=1)
* Failed to start UPS drivers!
[ !! ]
I have noticed that dmesg continuously fills up with messages like:
usb 3-2: USB disconnect, address 116
usb 3-2: new low speed USB device using uhci_hcd and address 117
usb 3-2: New USB device found, idVendor=075d, idProduct=0300
usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
usb 3-2: Product: iBox
usb 3-2: Manufacturer: iDowell
usb 3-2: SerialNumber: 0001
generic-usb 0003:075D:0300.005C: hidraw1: USB HID v1.10 Device
[iDowell iBox] on usb-:00:1d.1-2/input0
usb 3-2: USB disconnect, address 117
usb 3-2: new low speed USB device using uhci_hcd and address 118
usb 3-2: New USB device found, idVendor=075d, idProduct=0300
usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
usb 3-2: Product: iBox
usb 3-2: Manufacturer: iDowell
usb 3-2: SerialNumber: 0001
generic-usb 0003:075D:0300.005D: hidraw1: USB HID v1.10 Device
[iDowell iBox] on usb-:00:1d.1-2/input0
I do not know why it keeps disconnecting and reconnecting getting a
new address every time.
Any ideas what else I could try?
I think is an issue with the UDEV rules.
At the end of /etc/udev/rules.d/10-local.rules I put this line for my
liebert USB UPS:
SUBSYSTEMS==usb,ATTRS{idVendor}==10af,ATTRS{idProduct}==0004,SYMLINK+=liebert-
ups MODE=0660, GROUP=nut, OPTIONS=last_rule
and in
/etc/nut/ups.conf
user = nut
[liebert]
port = /dev/liebert-ups
driver = liebert
Make sure also about permissions:
lrwxrwxrwx 1 root root 11 2 gen 10.34 /dev/liebert-ups - usb/hiddev0
crw-rw 1 root nut 180, 96 2 gen 10.34 usb/hiddev0
HTH
Francesco
--
Linux Version 2.6.36-gentoo-r6, Compiled #1 SMP PREEMPT Tue Dec 28
20:43:07 CET 2010
Two 1GHz AMD Athlon 64 Processors, 4GB RAM, 4019.24 Bogomips Total
aemaeth
Re: [gentoo-user] disk /dev entry
on 01/02/2011 12:22 AM Alan McKinnon wrote the following: Apparently, though unproven, at 23:38 on Saturday 01 January 2011, Daniel D Jones did opine thusly: This is more of a curiosity question than a problem. I just added a new diskdrive to my system. It's the same model as one I already have installed. lshw shows the following for the two disks: *-disk:2 description: ATA Disk product: ST31000528AS vendor: Seagate physical id: 0.0.0 bus info: s...@2:0.0.0 logical name: /dev/sdc version: CC37 serial: 9VP21EZB size: 931GiB (1TB) capabilities: partitioned partitioned:dos configuration: ansiversion=5 signature=2adeb97b *-disk description: ATA Disk product: ST31000528AS vendor: Seagate physical id: 0 bus info: i...@1.0 logical name: /dev/hdc version: CC3E serial: 9VP9G4VW size: 931GiB (1TB) capabilities: ata dma lba iordy smart security pm partitioned partitioned:dos configuration: signature=1e89b64b smart=on These are both SATA disks. Why is the first one showing up as /dev/sdc and the second as /dev/hdc? I thought all SATA disks would show up as sd* and EIDE disks showed up as hd*. I note that the bus info is different - one showing the scsi bus and one the ide bus. Both devices are plugged into a row of SATA ports on my mobo. Maybe the new disk is set to IDE mode as shipped? or maybe the controller of the second disk is set to IDE in BIOS ...
Re: [gentoo-user] [OT] Firefox 3.6.12 problem?
On Monday 13 December 2010 16:43:10 I wrote: On Monday 13 December 2010 14:02:38 Urs Schutz wrote: Did you try to use the configuration dialog for the Menu bar / Navigation toolbar / Bookmarks toolbar? If not, please right mouse click on the «STOP» button, and choose «Customize...»). I used a different route to the same dialogue. Do you see the Back- and Forward arrows inside the «Customize Toolbar» Window? Nope. Or use the «Restore default set» button. If the arrows do not appear, I am without any more ideas. They haven't, and I'm stumped too. Thanks for the idea though. Well, what do you know? My arrow buttons have just come back. The only relevant thing I've emerged today is x11-libs/gtk+-2.22.1-r1. I think that's where I smell a rat. It hasn't helped with my KDM problem though. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
[gentoo-user] SVGA mode the console
Hi, there is a small linux distribution (GRML), which I use for rescue and other purposes. I installed it on a USB-stick. Furthermore installed in my PC there is a MSI GT430 (nvidia) graphics card and I use the nvidia-driver in conjunction with xorg 1.9.2. So far so nice... The GRML uses the noveau driver as far as I know. When I boot from my USB-stick I get a very nice high resolution linux console. It uses vga=791 on the kernel commandline. When I use the same option with my kernel (2.6.36.2 vanilla) it ends in a console font/resolution which reminds me at the good old times when 8bit homecomputers were the dream of many people and PACMAN was top! ;) I tried vga=asK and then scan but the highest resolution I was offered were 80x60 and only VGA-modes, which again looks like the high resolution textmode of my old ATARI 800...and not like that nice looking console which I get with the same hardware and the GRML distro. I compared both the kernel config of the GRML distro and my own but I didn't found nay suspicious (or overlooked something?). Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? Best regards and a happy new 2011! mcc
Re: [gentoo-user] nvidia update problems
On Friday 31 December 2010 12:52:08 Peter Humphrey wrote: When I start the system, instead of the kdm login screen I get a blinking cursor in the top-[left] of a blank screen. An emerge of nvidia-drivers enables me to restart kdm and get a proper screen. This is in spite of not having been able to unload the old nvidia module because it was in use. Today I found that another display problem* had been fixed with an upgrade of gtk+ to version 2.22.1-r1. It had no effect on this problem though. Nor did adding consolekit to the boot run level. It looks as though the boot sequence is going wrong somehow, because when I get my initial blank screen, if I then switch to a VT and restart xdm, everything works as expected. * This was to do with Firefox arrow buttons, as in the thread [OT] Firefox 3.6.12 problem? -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] New project in perl? {OT}
Apparently, though unproven, at 03:32 on Sunday 02 January 2011, Stroller did opine thusly: On 1/1/2011, at 10:34pm, Grant wrote: ... I'm starting a new project that is quite straightforward and will interface with an old project. The only point of contact between the two projects might be both of them having access to the same database table. The old project is written in a language that is related to perl so I can imagine there would be some benefit to using perl for the new project. Am I foolish to start a new project in perl at this stage in its lifecycle? I won't be doing the coding myself and I wonder if I would be better off with PHP since more coders seem to be familiar with PHP than perl. I'm not sure if I've mentioned before, but I picked up Perl fairly recently (within the last 12.5 months) although I haven't done *that* much with it. I *really* like Perl. It feels extremely robust and right. My 2c. I had a similar reason for picking up Perl. Here's what I now think of it: Any language has good coders and bad coders using it, there's nothing the language can do about that and it can't defend you from yourself either. There is much bad Perl code out there but that's because there are so many coders using it. The clincher is: If you are the kind of coder who is pedantic about writing stuff correctly, Perl goes out of it's way to help you do that. It will also help you to write utter complete shit code too, but that's a human issue, not a language one. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Core i7 M620 power management problem
On Sunday 02 January 2011 04:39:10 Bill Longman wrote: On Sat, Jan 1, 2011 at 4:34 PM, Mick michaelkintz...@gmail.com wrote: Did you diff the kernel configs to see what's different between the two OS'? There was no /proc/config.gz. How do you find it without that? I looked through the proc tree but didn't find anything. I'm sure that Ubuntu includes the current kernel(s) config in /boot/. Look for something like /boot/config-2.6.XX-generic or -server or -386 depending on your arch and kernel you have chosen. I believe a typical desktop installation runs *-generic. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] SVGA mode the console
On Sunday 02 January 2011 11:28:09 meino.cra...@gmx.de wrote: Hi, there is a small linux distribution (GRML), which I use for rescue and other purposes. I installed it on a USB-stick. Furthermore installed in my PC there is a MSI GT430 (nvidia) graphics card and I use the nvidia-driver in conjunction with xorg 1.9.2. So far so nice... The GRML uses the noveau driver as far as I know. When I boot from my USB-stick I get a very nice high resolution linux console. It uses vga=791 on the kernel commandline. When I use the same option with my kernel (2.6.36.2 vanilla) it ends in a console font/resolution which reminds me at the good old times when 8bit homecomputers were the dream of many people and PACMAN was top! ;) I tried vga=asK and then scan but the highest resolution I was offered were 80x60 and only VGA-modes, which again looks like the high resolution textmode of my old ATARI 800...and not like that nice looking console which I get with the same hardware and the GRML distro. I compared both the kernel config of the GRML distro and my own but I didn't found nay suspicious (or overlooked something?). Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? I think that the nice high resolution you see with GRML is presented by the framebuffer. You only get this once the kernel starts to load. Until then you get a very basic VGA screen, which the GRML may not show at all (in other words the first visual impression of a LiveCD may be the framebuffer console). With the latest versions CDs which use KMS (e.g. SystemrescueCD) the two stages VGA--framebuffer are visible if I recall correctly. With regards to your own kernel, are you using KMS? If so, once the kernel starts loading the KMS will dictate what resolution you get. If this is too small to read (I think it will render the highest resolution possible) or you want to set some custom resolution for whatever reason, then add nomodeset to the kernel line in your grub.conf and also restore the vga=XXX line you had there previously. HTH. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: SVGA mode the console
On 01/02/2011 01:28 PM, meino.cra...@gmx.de wrote: Hi, there is a small linux distribution (GRML), which I use for rescue and other purposes. I installed it on a USB-stick. Furthermore installed in my PC there is a MSI GT430 (nvidia) graphics card and I use the nvidia-driver in conjunction with xorg 1.9.2. So far so nice... The GRML uses the noveau driver as far as I know. When I boot from my USB-stick I get a very nice high resolution linux console. It uses vga=791 on the kernel commandline. Nouveau uses KMS, which means it automatically uses the monitor's native resolution and supports all resolutions the graphics card is capable of. On your PC, you're using the VESA fb driver, not Nouveau KMS. That means you're limited to VESA resolutions for your consoles. You can use the vbetest utility to detect which modes your card's VESA BIOS supports. To use this tool, emerge the sys-libs/lrmi package. Simply run the tool and it will print a list of modes you can use, and the resolutions those modes correspond to. If your desired resolution is not in the list, then there's no way to use that resolution in a VESA fb; you will need to switch to Nouveau's KMS fb.
[gentoo-user] Re: New project in perl? {OT}
Indexer, Sun, 02 Jan 2011 10:47:46 +1030: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2011, at 09:04, Grant wrote: I'm sorry this is OT but I really value the opinion of many people subscribed to this list. I'm starting a new project that is quite straightforward and will interface with an old project. The only point of contact between the two projects might be both of them having access to the same database table. The old project is written in a language that is related to perl so I can imagine there would be some benefit to using perl for the new project. Am I foolish to start a new project in perl at this stage in its lifecycle? I won't be doing the coding myself and I wonder if I would be better off with PHP since more coders seem to be familiar with PHP than perl. TBH use neither, most people are jumping away from PHP and Perl. I am not sure who is most people but I do almost all my coding in Perl and love it. Perl has great features and is very cleverly designed language! Lubos
[gentoo-user] Problem building VMware Modul
Hi all, i got trouble building the vmmon module for vmware workstation 7. I tried with the ebuild driver as the module from vmware himself. Error message is always the same(her the short one): Using 2.6.x kernel build system. make -C /lib/modules/2.6.36-gentoo-r6/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \ MODULEBUILDDIR= modules make[1]: Entering directory `/usr/src/linux-2.6.36-gentoo-r6' CC [M] /usr/lib/vmware/modules/source/vmmon-only/linux/driver.o /usr/lib/vmware/modules/source/vmmon-only/linux/driver.c: In Funktion »init_module«: /usr/lib/vmware/modules/source/vmmon-only/linux/driver.c:425: Fehler: »struct file_operations« hat kein Element namens »ioctl« make[2]: *** [/usr/lib/vmware/modules/source/vmmon-only/linux/driver.o] Fehler 1 make[1]: *** [_module_/usr/lib/vmware/modules/source/vmmon-only] Fehler 2 make[1]: Leaving directory `/usr/src/linux-2.6.36-gentoo-r6' make: *** [vmmon.ko] Fehler 2 I don't know how to solve this problem. Anyone a idea? Kernelinfo: Linux Slaxy 2.6.36-gentoo-r6 #1 SMP Tue Dec 28 18:29:09 CET 2010 x86_64 Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz GenuineIntel GNU/Linux Work with the 2.6.35 perfectly fine, did not change a thing in the config. Greeting from Germany Akendo PS: Happy new year
Re: [gentoo-user] SVGA mode the console
Mick michaelkintz...@gmail.com [11-01-02 14:08]: On Sunday 02 January 2011 11:28:09 meino.cra...@gmx.de wrote: Hi, there is a small linux distribution (GRML), which I use for rescue and other purposes. I installed it on a USB-stick. Furthermore installed in my PC there is a MSI GT430 (nvidia) graphics card and I use the nvidia-driver in conjunction with xorg 1.9.2. So far so nice... The GRML uses the noveau driver as far as I know. When I boot from my USB-stick I get a very nice high resolution linux console. It uses vga=791 on the kernel commandline. When I use the same option with my kernel (2.6.36.2 vanilla) it ends in a console font/resolution which reminds me at the good old times when 8bit homecomputers were the dream of many people and PACMAN was top! ;) I tried vga=asK and then scan but the highest resolution I was offered were 80x60 and only VGA-modes, which again looks like the high resolution textmode of my old ATARI 800...and not like that nice looking console which I get with the same hardware and the GRML distro. I compared both the kernel config of the GRML distro and my own but I didn't found nay suspicious (or overlooked something?). Final question after all there words: How can I get such a high resolution with this hardware and the nvidia-drivers??? I think that the nice high resolution you see with GRML is presented by the framebuffer. You only get this once the kernel starts to load. Until then you get a very basic VGA screen, which the GRML may not show at all (in other words the first visual impression of a LiveCD may be the framebuffer console). With the latest versions CDs which use KMS (e.g. SystemrescueCD) the two stages VGA--framebuffer are visible if I recall correctly. With regards to your own kernel, are you using KMS? If so, once the kernel starts loading the KMS will dictate what resolution you get. If this is too small to read (I think it will render the highest resolution possible) or you want to set some custom resolution for whatever reason, then add nomodeset to the kernel line in your grub.conf and also restore the vga=XXX line you had there previously. HTH. -- Regards, Mick Hi Mick, unfortunately the nvidia driver does not support KMS...see the Gentoo docs. Best regards, mcc
Re: [gentoo-user] Re: SVGA mode the console
Nikos Chantziaras rea...@arcor.de [11-01-02 14:12]: On 01/02/2011 01:28 PM, meino.cra...@gmx.de wrote: Hi, there is a small linux distribution (GRML), which I use for rescue and other purposes. I installed it on a USB-stick. Furthermore installed in my PC there is a MSI GT430 (nvidia) graphics card and I use the nvidia-driver in conjunction with xorg 1.9.2. So far so nice... The GRML uses the noveau driver as far as I know. When I boot from my USB-stick I get a very nice high resolution linux console. It uses vga=791 on the kernel commandline. Nouveau uses KMS, which means it automatically uses the monitor's native resolution and supports all resolutions the graphics card is capable of. On your PC, you're using the VESA fb driver, not Nouveau KMS. That means you're limited to VESA resolutions for your consoles. You can use the vbetest utility to detect which modes your card's VESA BIOS supports. To use this tool, emerge the sys-libs/lrmi package. Simply run the tool and it will print a list of modes you can use, and the resolutions those modes correspond to. If your desired resolution is not in the list, then there's no way to use that resolution in a VESA fb; you will need to switch to Nouveau's KMS fb. Hi Nikos, unfortunately lrmi fails to compile. Best regards, mcc
[gentoo-user] Re: SVGA mode the console
On 01/02/2011 03:57 PM, meino.cra...@gmx.de wrote: Nikos Chantziarasrea...@arcor.de [11-01-02 14:12]: On 01/02/2011 01:28 PM, meino.cra...@gmx.de wrote: Hi, there is a small linux distribution (GRML), which I use for rescue and other purposes. I installed it on a USB-stick. Furthermore installed in my PC there is a MSI GT430 (nvidia) graphics card and I use the nvidia-driver in conjunction with xorg 1.9.2. So far so nice... The GRML uses the noveau driver as far as I know. When I boot from my USB-stick I get a very nice high resolution linux console. It uses vga=791 on the kernel commandline. Nouveau uses KMS, which means it automatically uses the monitor's native resolution and supports all resolutions the graphics card is capable of. On your PC, you're using the VESA fb driver, not Nouveau KMS. That means you're limited to VESA resolutions for your consoles. You can use the vbetest utility to detect which modes your card's VESA BIOS supports. To use this tool, emerge the sys-libs/lrmi package. Simply run the tool and it will print a list of modes you can use, and the resolutions those modes correspond to. If your desired resolution is not in the list, then there's no way to use that resolution in a VESA fb; you will need to switch to Nouveau's KMS fb. Hi Nikos, unfortunately lrmi fails to compile. You can boot an older Live CD (something like Ubuntu 9.x) that has this tool. Run the tool there and save the output for future reference.
[gentoo-user] Re: SVGA mode the console
On 01/02/2011 03:57 PM, meino.cra...@gmx.de wrote: unfortunately lrmi fails to compile. In addition to what I wrote in my other reply, make sure you use a 32bit Live CD. vbetest does not work with 64-bit kernels. Btw, if you're on a 32-bit Gentoo, you can compile lrmi on it. Steps: Download http://sourceforge.net/projects/lrmi/files/lrmi/0.10/lrmi-0.10.tar.gz/download Unpack it and apply the patch from Gentoo with: cd lrmi-0.10 patch -p1 /usr/portage/sys-libs/lrmi/files/lrmi-0.10-kernel-2.6.26.patch Simply run make. Now you can run it with: ./vbetest You don't need to install anything. When you're done, simply delete the lrmi-0.10 directory.
Re: [gentoo-user] Re: SVGA mode the console
Nikos Chantziaras rea...@arcor.de [11-01-02 16:12]: On 01/02/2011 03:57 PM, meino.cra...@gmx.de wrote: unfortunately lrmi fails to compile. In addition to what I wrote in my other reply, make sure you use a 32bit Live CD. vbetest does not work with 64-bit kernels. Btw, if you're on a 32-bit Gentoo, you can compile lrmi on it. Steps: Download http://sourceforge.net/projects/lrmi/files/lrmi/0.10/lrmi-0.10.tar.gz/download Unpack it and apply the patch from Gentoo with: cd lrmi-0.10 patch -p1 /usr/portage/sys-libs/lrmi/files/lrmi-0.10-kernel-2.6.26.patch Simply run make. Now you can run it with: ./vbetest You don't need to install anything. When you're done, simply delete the lrmi-0.10 directory. Hi Nikos, unfortunately I am on a AMD64 Gentoo. I will whether GRML has this tool...
[gentoo-user] Re: nvidia update problems
On 01/02/2011 03:51 AM, Peter Humphrey wrote: On Friday 31 December 2010 12:52:08 Peter Humphrey wrote: When I start the system, instead of the kdm login screen I get a blinking cursor in the top-[left] of a blank screen. An emerge of nvidia-drivers enables me to restart kdm and get a proper screen. This is in spite of not having been able to unload the old nvidia module because it was in use. It looks as though the boot sequence is going wrong somehow, because when I get my initial blank screen, if I then switch to a VT and restart xdm, everything works as expected. Just for clarification, are you saying that you can do that even without re-emerging nvidia-drivers? So, when you first switch to the VT, the nvidia module is already loaded? Is there an X session already running before you restart kdm? (I don't use any of *dm, so I don't know if they are X apps that require X to be running before they can write to the screen.)
[gentoo-user] Re: Problem building VMware Modul
On 01/02/2011 04:43 AM, 4k3nd0 wrote: Hi all, i got trouble building the vmmon module for vmware workstation 7. I tried with the ebuild driver as the module from vmware himself. Error message is always the same(her the short one): Using 2.6.x kernel build system. »struct file_operations« hat kein Element namens »ioctl« The ioctl item in file_operations was removed by the kernel devs a few months ago while removing the Big Kernel Lock(BKL). Kernelinfo: Linux Slaxy 2.6.36-gentoo-r6 #1 SMP Tue Dec 28 18:29:09 CET 2010 x86_64 Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz GenuineIntel GNU/Linux Work with the 2.6.35 perfectly fine, did not change a thing in the config. The kernel devs change kernel data structures quite often, thereby breaking all kinds of third-party software. I think I remember this one from building nvidia-drivers. The nvidia devs soon re-wrote their code to use the new kernel data-structure, and I imagine that vmware will need to do the same. Maybe they have already fixed it in a newer vmware version, or will soon. IIRC the nvidia team fixed this problem merely by removing any code that refers to the ioctl member of a file_operations structure. That's pretty trivial, so you can give it a try in your vmware code. No warranty implied :)
Re: [gentoo-user] New project in perl? {OT}
I'm sorry this is OT but I really value the opinion of many people subscribed to this list. I'm starting a new project that is quite straightforward and will interface with an old project. The only point of contact between the two projects might be both of them having access to the same database table. The old project is written in a language that is related to perl so I can imagine there would be some benefit to using perl for the new project. Am I foolish to start a new project in perl at this stage in its lifecycle? I won't be doing the coding myself and I wonder if I would be better off with PHP since more coders seem to be familiar with PHP than perl. In '99 I worked with a fellow who styled himself a software architect. The first step of each project he managed involved stating We will write this software in Java. As you can imagine that's sorta backwards. I'd spec the software function, features, etc and then decide which language has better tools or command of the problem space. You will have to balance that against your knowledge of the language and the developer skills you have access to. However even the exercise of deciding Python appears to be the superior language in this problem space, but we're going to go with Perl because the database module for our db already exists and is much more mature. Bob knows Perl better too. is worth doing because it helps define the scope of the project. FWIW the current startup I'm at is using Ruby for the front end and it's been a bit more work that PHP which is what the last company used. That's partly Rails immaturity, our lack of experience with Ruby, and having to learn the Rails/Ruby way. Unless the language you're familiar with is completely unsuitable, I'd say familiarity trumps language features. YMMV. kashani Thanks to everyone. I really love this list (and this distro). I'll stick with perl. - Grant
Re: [gentoo-user] Problem building VMware Modul
On 01/02/2011 04:43 AM, 4k3nd0 wrote: Hi all, i got trouble building the vmmon module for vmware workstation 7. I tried with the ebuild driver as the module from vmware himself. This is a known problem. There have been some threads on this in the VMware forums. http://search.vmware.com/search?cn=vmwarecc=wwwclient=VMware_Siteentqr=0ud=1output=xml_no_dtdproxystylesheet=VMware_gsa_Sitesite=VMware_Site_communitiesie=UTF-8oe=UTF-8q=workstation+linux+2.6.36 I don't know how to solve this problem. The threads above have a patch that will allow the modules to build, or you can revert to 2.6.36 and wait for VMware to release an update. hope this helps tim -- Tim Sammut ~ Gentoo Security Team underl...@gentoo.org ~ C2375493 signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: Problem building VMware Modul
On 01/02/2011 02:43 PM, 4k3nd0 wrote: Hi all, i got trouble building the vmmon module for vmware workstation 7. I tried with the ebuild driver as the module from vmware himself. Are you using the vmware overlay? app-emulation/vmware-workstation-7.1.3.324285 and app-emulation/vmware-modules-238.3 work fine here with kernel 2.6.36-r6.
[gentoo-user] Xorg 1.9.2 and wrong display size
My 1.9.2 upgrade didn't lose the keys, but it thinks the screen has fewer pixels than before, and what it does use is pushed off to the right (there is a column down the left side, roughly 10-20% of the screen, which is inaccessible). I've included 3 logs -- the working 1.8.2, the failing 1.9.2, and the failing /var/log/Xorg.0.log. The user logs show no practical difference tat I can see. The failing /var/log/Xorg log has tons of detail. It's got the right server, at least it doesn't appear to be falling back on the frameuffer, but maybe that would be better. It knows what sizes are available, but it rejects the size which used to work. I can use ALT-CTRL-+ and - to bop around the sizes it allows, and the dead space moves around, sometimes leaving the bottom and right inaccessible. After a whole lot of messages, this looks to me like it finally settles on the final configuration using module mach64, but it doesn't actually say what screen size it is using. Those offscreen areas look suspiciously like clues, but I am not Sherlock here, barely Dr. Watson. [348053.495] (II) UnloadModule: vesa [348053.495] (II) Unloading /usr/lib64/xorg/modules/drivers/vesa_drv.so [348053.495] (II) UnloadModule: fbdev [348053.495] (II) Unloading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [348053.495] (II) UnloadModule: fbdevhw [348053.495] (II) Unloading /usr/lib64/xorg/modules/libfbdevhw.so [348053.495] (--) Depth 24 pixmap format is 32 bpp [348053.503] (WW) MACH64(0): DRI static buffer allocation failed -- need at least 9720 kB video memory [348053.503] (II) MACH64(0): Largest offscreen areas (with overlaps): [348053.503] (II) MACH64(0):1152 x 956 rectangle at 0,864 [348053.503] (II) MACH64(0):256 x 957 rectangle at 0,864 [348053.503] (II) MACH64(0): Using XFree86 Acceleration Architecture (XAA) I have no config file. It has both the USE evdev and udev flags, but only the evdev INPUT_DEVICES flag. It knows about the keyboard and everything except the size seems fine, but if it work better without evdev, I can try that. It's a dual Opteron ~amd64 system, about 6 years old, a server with a crippled display chip, no doubt cheaper because of it. I don't mind that, but I'd like X to at least use as much screen as it used to. begin working 1.8.2 log xauth: creating new authority file /home/felix/.serverauth.2923 X.Org X Server 1.8.2 Release Date: 2010-07-01 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.34-gentoo-r2 x86_64 Gentoo Current Operating System: Linux df.crowfix.com 2.6.35-gentoo-r5 #1 SMP PREEMPT Sat Aug 28 10:01:09 PDT 2010 x86_64 Kernel command line: root=/dev/sda7 Build Date: 22 July 2010 06:56:56AM Current version of pixman: 0.18.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Fri Sep 10 18:02:07 2010 (==) Using config directory: /etc/X11/xorg.conf.d (==) Using system config directory /usr/share/X11/xorg.conf.d error setting MTRR (base = 0xfd00, size = 0x0080, type = 1) Invalid argument (22) localhost being added to access control list end working 1.8.2 log begin failing 1.9.2 log xauth: file /home/felix/.serverauth.21803 does not exist This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.9.2.902 (1.9.3 RC 2) Release Date: 2010-12-03 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.36-gentoo-r3 x86_64 Gentoo Current Operating System: Linux df.crowfix.com 2.6.36-gentoo-r6 #1 SMP PREEMPT Tue Dec 28 08:39:52 PST 2010 x86_64 Kernel command line: root=/dev/sda7 Build Date: 06 December 2010 07:46:05AM Current version of pixman: 0.20.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Jan 2 10:23:02 2011 (==) Using config directory: /etc/X11/xorg.conf.d (==) Using system config directory /usr/share/X11/xorg.conf.d error setting MTRR (base = 0xfd00, size = 0x0080, type = 1) Invalid argument (22) localhost
[gentoo-user] Re: Xorg 1.9.2 and wrong display size
On 01/02/2011 11:25 AM, fe...@crowfix.com wrote: My 1.9.2 upgrade didn't lose the keys, but it thinks the screen has fewer pixels than before, and what it does use is pushed off to the right (there is a column down the left side, roughly 10-20% of the screen, which is inaccessible). I've included 3 logs -- the working 1.8.2, the failing 1.9.2, and the failing /var/log/Xorg.0.log... The 'failing' log shows that the new Xorg-server is using the MACH64 driver, but your 'working' 1.8.2 log is truncated, so it doesn't tell us which video driver it was using successfully. Given only 8MB of video memory, maybe the vesa driver would work better? Dunno. Does your BIOS have a setting for the video aperture?
Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
On Sun, Jan 02, 2011 at 01:07:40PM -0800, walt wrote: On 01/02/2011 11:25 AM, fe...@crowfix.com wrote: My 1.9.2 upgrade didn't lose the keys, but it thinks the screen has fewer pixels than before, and what it does use is pushed off to the right (there is a column down the left side, roughly 10-20% of the screen, which is inaccessible). I've included 3 logs -- the working 1.8.2, the failing 1.9.2, and the failing /var/log/Xorg.0.log... The 'failing' log shows that the new Xorg-server is using the MACH64 driver, but your 'working' 1.8.2 log is truncated, so it doesn't tell us which video driver it was using successfully. I'm about 99% certain that it has always used the mach64 driver. I wish I had an old enough backup to recover an old log, but this current size screwup has been in effect for a while. It's mostly a server, so X isn't vital, but I do want to get it working again. Given only 8MB of video memory, maybe the vesa driver would work better? Dunno. Does your BIOS have a setting for the video aperture? No. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
On Sunday 02 January 2011 21:18:14 fe...@crowfix.com wrote: On Sun, Jan 02, 2011 at 01:07:40PM -0800, walt wrote: On 01/02/2011 11:25 AM, fe...@crowfix.com wrote: My 1.9.2 upgrade didn't lose the keys, but it thinks the screen has fewer pixels than before, and what it does use is pushed off to the right (there is a column down the left side, roughly 10-20% of the screen, which is inaccessible). I've included 3 logs -- the working 1.8.2, the failing 1.9.2, and the failing /var/log/Xorg.0.log... The 'failing' log shows that the new Xorg-server is using the MACH64 driver, but your 'working' 1.8.2 log is truncated, so it doesn't tell us which video driver it was using successfully. I'm about 99% certain that it has always used the mach64 driver. I wish I had an old enough backup to recover an old log, but this current size screwup has been in effect for a while. It's mostly a server, so X isn't vital, but I do want to get it working again. Given only 8MB of video memory, maybe the vesa driver would work better? Dunno. Does your BIOS have a setting for the video aperture? You may get better results if you enable KMS in your kernel. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Xorg 1.9.2 and wrong display size
On Mon, Jan 03, 2011 at 12:33:18AM +, Mick wrote: On Sunday 02 January 2011 21:18:14 fe...@crowfix.com wrote: On Sun, Jan 02, 2011 at 01:07:40PM -0800, walt wrote: On 01/02/2011 11:25 AM, fe...@crowfix.com wrote: My 1.9.2 upgrade didn't lose the keys, but it thinks the screen has fewer pixels than before, and what it does use is pushed off to the right (there is a column down the left side, roughly 10-20% of the screen, which is inaccessible). I've included 3 logs -- the working 1.8.2, the failing 1.9.2, and the failing /var/log/Xorg.0.log... The 'failing' log shows that the new Xorg-server is using the MACH64 driver, but your 'working' 1.8.2 log is truncated, so it doesn't tell us which video driver it was using successfully. I'm about 99% certain that it has always used the mach64 driver. I wish I had an old enough backup to recover an old log, but this current size screwup has been in effect for a while. It's mostly a server, so X isn't vital, but I do want to get it working again. Given only 8MB of video memory, maybe the vesa driver would work better? Dunno. Does your BIOS have a setting for the video aperture? You may get better results if you enable KMS in your kernel. Hmmm ... I hadn't remembered KMS until I googled it, so I tried this ... # grep KMS /usr/src/linux/.config CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_RADEON_KMS=y # CONFIG_DRM_I915_KMS is not set Is that good enough? I gather I915 is the Intel graphics. I modprobe'd drm_kms_helper and the resultant Xorg log was exactly the same except for one date/time stamp and all those [nn.nnn] times at the beginning of each line. I bit of googling found several old web pages, but they seemed somehow not very useful. One said I have to disable the framebuffers, not because they are dangerous, but because they don't support KMS. Since X unloads the framebuffer module, I won't worry about that. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: [gentoo-user] Good file system that recovers from a power failure.
On Sun, Jan 02, 2011 at 10:31:42AM +0800, William Kenworthy wrote I use dirvish for backups which creates a LOT of hardlinks which can be very hard on a file system. ext2 typically lasts only a few cycles, while ext3 is only a little better even with full journalling. Coupled to the fact neither is very good with power cuts and they are a worst case choice for data security :) Am I mis-understanding or are you mis-speaking? hardlinks != backup A hardlink is simply another pointer to the same tracks/sectors on disk. If the on-disk data is destroyed it doesn't matter how many pointers you have to the data, it's gone. A real backup is another copy of the data on another drive, preferably external. Reiserfs3 by contrast is very very good, with only a few instances of problems over many years (since beore 3 was even in the kernel) - none of which have lost critical data or file systems (ext2/3 devs, are you listening :) I don't think ext2fs is being developed as such. And ext3fs is mostly a journalling system backported to ext2fs. ext2fs was written way back when in January 1993, and the specs were uptodate for then, but our expectations, and disk sizes have grown since then. So, for me at least, btrfs is looking like the way forward. Its in testing at the moment, but I am ready to move whole systems over to it. I'm on reiserfs3 for now. Hopefully, it'll be maintained until ext4 or btrfs or whatever is deemed ready for primetime. When that happens, I'll do any new installs on the new filesystem. If it works, don't muck around with it. Unless support/maintenance for reiserfs3 is dropped or a new fs comes out with a feature I really want/need, I won't migrate existing systems. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Good file system that recovers from a power failure.
Reply inline On Sun, 2011-01-02 at 21:06 -0500, Walter Dnes wrote: On Sun, Jan 02, 2011 at 10:31:42AM +0800, William Kenworthy wrote I use dirvish for backups which creates a LOT of hardlinks which can be very hard on a file system. ext2 typically lasts only a few cycles, while ext3 is only a little better even with full journalling. Coupled to the fact neither is very good with power cuts and they are a worst case choice for data security :) Am I mis-understanding or are you mis-speaking? hardlinks != backup A hardlink is simply another pointer to the same tracks/sectors on disk. If the on-disk data is destroyed it doesn't matter how many pointers you have to the data, it's gone. A real backup is another copy of the data on another drive, preferably external. Yes you have misunderstood, check out http://www.dirvish.org/. Basicly the first backup (--init) is a complete copy of the source into either a local disk or remote storage. Subsequent backups create a new image, by checking if the previous copy of a file/directory/whatever has changed and if not it will create a hardlink, but if changed will make a new copy. So you can have full, daily backups using typically only 2x the original space for many versioned backups. As only changed files are copied, its only changes that use real space. Restore is just copy the version back you want. Full OS restore is done in a similar fashion to copying one system to another (i.e., cloned from the image). Reiserfs3 by contrast is very very good, with only a few instances of problems over many years (since beore 3 was even in the kernel) - none of which have lost critical data or file systems (ext2/3 devs, are you listening :) I don't think ext2fs is being developed as such. And ext3fs is mostly a journalling system backported to ext2fs. ext2fs was written way back when in January 1993, and the specs were uptodate for then, but our expectations, and disk sizes have grown since then. So, for me at least, btrfs is looking like the way forward. Its in testing at the moment, but I am ready to move whole systems over to it. I'm on reiserfs3 for now. Hopefully, it'll be maintained until ext4 or btrfs or whatever is deemed ready for primetime. When that happens, I'll do any new installs on the new filesystem. If it works, don't muck around with it. Unless support/maintenance for reiserfs3 is dropped or a new fs comes out with a feature I really want/need, I won't migrate existing systems. Exactly, I have had great service from reiserfs3, but fscking terrabytes of storage is becoming a serious limitation when it means taking a system offline to do so. That being said, I only do it every 6 months or so as a precaution rather than the expectation of finding something wrong - and haven't unless it was an actual disk failure (that one was at least 18 months ago. BillK
[gentoo-user] user/grpup spec.
Hi, I noticed that I have files in my $HOME, which I have created as user (me) which owner is set to (user.group) mcc.users other files, also owned by my are set to mcc.mcc . What is the current way to do this correctly ? Best regards, mcc
[gentoo-user] How 2 disable synaptic pad (driver)
Hello, so I got xorg-server working just fine on several machines...(*!/#FFF) Now I want to disable the synaptic pad on a laptop. The first laptop I want to do this to is working without any xorg.conf file nor a /etc/X11/xorg.conf.d/ dir. This chipset is a RADEON XPRESS 20M (5955) So is this file the best one to try to disable the synaptic driver? /etc/X11/xorg.conf.d/10-evdev.conf Suggestions are most welcome as googling has not produced much, related to xorg-server-1.9.2 and how to disable the synaptic pad (driver). James
Re: [gentoo-user] user/grpup spec.
Apparently, though unproven, at 06:26 on Monday 03 January 2011, meino.cra...@gmx.de did opine thusly: Hi, I noticed that I have files in my $HOME, which I have created as user (me) which owner is set to (user.group) mcc.users other files, also owned by my are set to mcc.mcc . What is the current way to do this correctly ? Best regards, mcc Change your primary group to affect new files: usermod -g users mcc To change all existing files and dirs to match: chgrp -R users ~ -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: New project in perl? {OT}
Apparently, though unproven, at 14:36 on Sunday 02 January 2011, Lubos Kolouch did opine thusly: Indexer, Sun, 02 Jan 2011 10:47:46 +1030: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2011, at 09:04, Grant wrote: I'm sorry this is OT but I really value the opinion of many people subscribed to this list. I'm starting a new project that is quite straightforward and will interface with an old project. The only point of contact between the two projects might be both of them having access to the same database table. The old project is written in a language that is related to perl so I can imagine there would be some benefit to using perl for the new project. Am I foolish to start a new project in perl at this stage in its lifecycle? I won't be doing the coding myself and I wonder if I would be better off with PHP since more coders seem to be familiar with PHP than perl. TBH use neither, most people are jumping away from PHP and Perl. I am not sure who is most people but I do almost all my coding in Perl and love it. Perl has great features and is very cleverly designed language! Lubos Most people is usually something like someone who's blog I read and my two friends. In other words, not even close to a mass migration away. Perl has one of the healthiest code ecosystems ever. It's not going away anytime soon. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] How 2 disable synaptic pad (driver)
On Mon, 03 Jan 2011, James wrote: Hello, so I got xorg-server working just fine on several machines...(*!/#FFF) Now I want to disable the synaptic pad on a laptop. The first laptop I want to do this to is working without any xorg.conf file nor a /etc/X11/xorg.conf.d/ dir. This chipset is a RADEON XPRESS 20M (5955) So is this file the best one to try to disable the synaptic driver? /etc/X11/xorg.conf.d/10-evdev.conf Suggestions are most welcome as googling has not produced much, related to xorg-server-1.9.2 and how to disable the synaptic pad (driver). James hi james, i know of 2 methods - either using synclient or xinput. if the synclient method doesn't work, simply install xinput and the latter one should work. cat ~/bin/toggle-touchpad #/bin/sh # synclient version if(synclient -l | grep TouchpadOff | grep -q 0) ; then synclient TouchpadOff=1 else synclient TouchpadOff=0 fi cat ~/bin/toggle-touchpad #/bin/sh # xinput version if(xinput list-props TouchPad | grep Synaptics Off | grep -q 0) ; then xinput set-int-prop TouchPad Synaptics Off 8 1 else xinput set-int-prop TouchPad Synaptics Off 8 0 fi xing
