[gentoo-user] aircard suggestion
Hello, I am interested in trying an aircard with gentoo and I would appreciate suggestions; hardware and provider service. Thanks, -- Valmor
Re: [gentoo-user] The CHOST variable
Am 04.02.2011 01:27, schrieb Alan McKinnon: > Apparently, though unproven, at 01:43 on Friday 04 February 2011, Nils > Holland > did opine thusly: > > I'm not in a position to give a fully definitive answer to 1) ... > >> 2) /etc/make.conf contains a note that one should not change the CHOST >> lightly (not that I'm planning to) and links to a nice document >> explaining how it can be done anyway (which, I have to admit, didn't >> make me any wiser, however). The question is, out of curiosity, why >> the CHOST should not be changed and what would happen if one did it >> anyway. I willingly believe that it would lead to problems, but would >> the actual cause of these problems actually be caused by the >> configuration of the machine being mixed up (for example, by the GNU >> build system / autoconf suddenly looking for a compiler or similiar >> tools / libraries under a path or by a name involving, for example, >> i486-pc-linux-gnu, which does not automatically exist of the >> appropriate tools have not been installed accordingly. Or would >> problems arise because code generated with the new CHOST does no >> longer "fit" to code generated with the previous / old CHOST? > > The warning is actually there to stop users doing stupid things like blindly > trying to convert 32 bit systems to 64 bit. This is how that goes down: > > 1. Change CHOST > 2. emerge -e world > 3. ??? > 4. Fail! > > Yes, if you are real smart it can be done. But "real smart" really does mean > "real smart" i.e. not for the faint of heart and certainly not worth being > officially supported. > Is the same true for more compatible arches like i486 -> i686? I have a system where I used the wrong stage-3 and now I'm stuck with an i486 CHOST on an Atom netbook where I could use every bit of performance. Regards, Florian signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Any way to get real text console without killing X capability?
Apparently, though unproven, at 02:05 on Friday 04 February 2011, walt did opine thusly: > On 02/03/2011 02:11 PM, Nikos Chantziaras wrote: > > On 02/03/2011 08:07 AM, Walter Dnes wrote: > >> Is there a way to have a real text console? I know that I can > >> have 2 X sessions on tty10 and tty11 with different resolutions, and > >> colour depths. Is there a way to set tty1..tty9 to 640x480 *IN TEXT > >> MODE*, so that lat1-?? fonts would look normal, without killing the > >> ability to have X run at 1920x1200? > > > > Note that the suggestion the others gave about disabling KMS is probably > > > >not what you need. Disabling KMS means that it will also be disabled for > >X11, not only for the framebuffer. As you can imagine this is a bad thing. > > I'm aware of KMS because of my experiments with the 'nouveau' driver, but > I still have no idea what KMS really does. > > In other words, I *cannot* imagine why disabling KMS is a bad thing, but I > would very much like to know :) Very short answer: Without KMS, changing video modes or changing from console to X requires a fantastically gigantic amount of swapping running code in and out, handing over control of the graphics hardware for one driver to another, and is a magnificent bug-injection mechanism. It's why it takes 2-3 seconds to switch from X to tty1 and why some hardware flickers like in banshee while doing it. KMS removes the need for the video driver to be aware of all the nonsense that requires. The driver no longer needs to get up close and personal with everything else the kernel is doing and make really sure it's timing is really right. Of course, the video driver has to support KMS for this to work. nVidia doesn't, nouveau does. In fact, nouveau *requires* KMS. It's such a good idea that the nouveau devs decided they were simply not going to support no-KMS. Disabling KMS (if it works with your hardware and drivers) in general is a bad idea as you lose all that nice KMS goodness. It's an especially bad idea with nouveau as the video hardware stops working at all. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] The CHOST variable
Apparently, though unproven, at 01:43 on Friday 04 February 2011, Nils Holland did opine thusly: I'm not in a position to give a fully definitive answer to 1) ... > 2) /etc/make.conf contains a note that one should not change the CHOST > lightly (not that I'm planning to) and links to a nice document > explaining how it can be done anyway (which, I have to admit, didn't > make me any wiser, however). The question is, out of curiosity, why > the CHOST should not be changed and what would happen if one did it > anyway. I willingly believe that it would lead to problems, but would > the actual cause of these problems actually be caused by the > configuration of the machine being mixed up (for example, by the GNU > build system / autoconf suddenly looking for a compiler or similiar > tools / libraries under a path or by a name involving, for example, > i486-pc-linux-gnu, which does not automatically exist of the > appropriate tools have not been installed accordingly. Or would > problems arise because code generated with the new CHOST does no > longer "fit" to code generated with the previous / old CHOST? The warning is actually there to stop users doing stupid things like blindly trying to convert 32 bit systems to 64 bit. This is how that goes down: 1. Change CHOST 2. emerge -e world 3. ??? 4. Fail! Yes, if you are real smart it can be done. But "real smart" really does mean "real smart" i.e. not for the faint of heart and certainly not worth being officially supported. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: xfce woes
> Until one day one of their bright spark techies had a brilliant idea. They > hired a bunch of pretty girls wearing tight skimpy "New! Improved! Check > Our > Promotion!" outfits to stand outside the front door handing out free > complimentary CDs. > > Yes, you guessed it. Within the hour the perimeter firewalls had more holes > than a Swiss cheese. Somebody paid dearly for that. > > That's not new. A similar one i heard of was to leave some USB drives on the ground in the carpark... or you could use spear phishing emails
[gentoo-user] Re: Any way to get real text console without killing X capability?
On 02/04/2011 02:05 AM, walt wrote: On 02/03/2011 02:11 PM, Nikos Chantziaras wrote: On 02/03/2011 08:07 AM, Walter Dnes wrote: Is there a way to have a real text console? I know that I can have 2 X sessions on tty10 and tty11 with different resolutions, and colour depths. Is there a way to set tty1..tty9 to 640x480 *IN TEXT MODE*, so that lat1-?? fonts would look normal, without killing the ability to have X run at 1920x1200? Note that the suggestion the others gave about disabling KMS is probably not what you need. Disabling KMS means that it will also be disabled for X11, not only for the framebuffer. As you can imagine this is a bad thing. I'm aware of KMS because of my experiments with the 'nouveau' driver, but I still have no idea what KMS really does. In other words, I *cannot* imagine why disabling KMS is a bad thing, but I would very much like to know :) For the radeon driver at least, disabling KMS means that you won't get DRI2 in X11. That means slower performance and tearing. The non-KMS X driver is pretty much considered deprecated.
[gentoo-user] Re: Any way to get real text console without killing X capability?
On 02/03/2011 02:11 PM, Nikos Chantziaras wrote: On 02/03/2011 08:07 AM, Walter Dnes wrote: Is there a way to have a real text console? I know that I can have 2 X sessions on tty10 and tty11 with different resolutions, and colour depths. Is there a way to set tty1..tty9 to 640x480 *IN TEXT MODE*, so that lat1-?? fonts would look normal, without killing the ability to have X run at 1920x1200? Note that the suggestion the others gave about disabling KMS is probably not what you need. Disabling KMS means that it will also be disabled for X11, not only for the framebuffer. As you can imagine this is a bad thing. I'm aware of KMS because of my experiments with the 'nouveau' driver, but I still have no idea what KMS really does. In other words, I *cannot* imagine why disabling KMS is a bad thing, but I would very much like to know :)
Re: [gentoo-user] Re: xfce woes
Apparently, though unproven, at 00:15 on Friday 04 February 2011, walt did opine thusly: > On 02/02/2011 09:15 PM, Alan McKinnon wrote: > > Apparently, though unproven, at 00:00 on Thursday 03 February 2011, walt > > did > > > > opine thusly: > >> As much as I like the convenience of automounting as a luser, all of > >> my bofh instincts cry out that lusers shouldn't be allowed to > >> > > mount a filesystem! > > > >> This is one of those Windows/convenience versus unix/security things, > >> I think, but I'm just an amateur bofh. > >> > >> What do you professional bofhs think? > > > > Depends on what the machine is used for. > > > > For a multiuser box, you probably want user to not shutdown/reboot, > > Yes, even I thought of that. As an amateur, though, I have no idea how > many multi-user machines still exist. I have more than 120 of them > When I was a lad, the campus computer(s) still ran batch jobs submitted on > punch cards. We had to wait for hours or even the next day to discover a > stupid typo. Punch cards??? Piffle. We used *paper tape* :-) > Actually, the profs didn't use punchcards, just us peons. The profs had > dumb terminals so they could log in to the central server -- and sit for > as long as five minutes to discover if the server had crashed, or was > just busy serving the needs of the department chairman's secretary. > > Over the years, the frustrations have merely morphed, not vanished :( > > > be able to mount removeable media... > > That was really what I was asking. I hear horror stories about employees > plugging usb thumb drives into corporate workstations to steal files, or > maybe infecting the whole network with malware from a "lost" thumb drive > found at a bus stop or a car park. Here's a funny story. It's true, and it's sad, but also macabrely funny. A penetration testing firm that I know well was commissioned to test the external security of a certain enterprise that was obliged to comply with stiff legal requirements. This firm does our pentesting too, and they are pretty thorough. If you ask them to throw the book at something for testing, and pay them enough, they will gladly oblige, and not care too much if this embarrasses you Try as they might, they could not get past this enterprise's border firewalls. Nothing showed up as a weakness. They tried and tried and tried and tried Until one day one of their bright spark techies had a brilliant idea. They hired a bunch of pretty girls wearing tight skimpy "New! Improved! Check Our Promotion!" outfits to stand outside the front door handing out free complimentary CDs. Yes, you guessed it. Within the hour the perimeter firewalls had more holes than a Swiss cheese. Somebody paid dearly for that. -- alan dot mckinnon at gmail dot com
[gentoo-user] The CHOST variable
Hi folks, well, it's not that a certain thing I'm intending to do has pointed me to it, but I've just noticed that something I've taken for granted for years is something I probably fail to understand correctly. And as I'm always eager to learn, I'm wondering if someone can point me in the right direction. I'm talking about the CHOST variable as defined in /etc/make.conf, and what actually lies behind it. Obviously, whatever is specified in make.conf as CHOST is passed to ./configure as --host when emerging packages. Ok, I know several things about that: The contents of the CHOST variable is a "target triplet" in the form of (for example) i686-pc-linux-gnu. According to the autoconf info documentation, packages using the GNU build environment use this triplet to properly configure the package at hand for the specified target architecture. If no --host is given to configure, it will try to determine the correct triplet for the current system by the rules specified in "config.sub". Beside --host, configure also accepts --build and --target, which specify the system on which the package is being configured and built (--build) and the the type of architecture for which a compiler being configured is supposed to be able to generate code (--target, which - I believe - only really seems to make sense when building a compiler like GCC). These can also be influenced via make.conf, where they are called CBUILD and CTARGET. All of this is fine so far and relatively understandable. But a few questions remain: 1) So a package using the GNU build system determines or is passed (via --host aka. CHOST) a target triplet specifying the system on which the resulting compiled code is supposed to run. What does the package do with that information? Does it only use it to determine what it has to compile (different / special code for different systems / architectures), or does this already have an influence on the optimization of the resulting code for a certain (sub-)architecture? Forthermore: Does configuring a package with, say, --host=i686-pc-linux-gnu already automatically mean that said package would not be able to run on (for example) an i486-pc-linux-gnu host? Or can this only be said to be true if the package itself decides to compile different / incompatible code for i686 and i486; in other words: If the package itself does not make any distinction on the CPU subtype, then the result would run "everywhere", as --host does not by itself imply any such thing as --march=? 2) /etc/make.conf contains a note that one should not change the CHOST lightly (not that I'm planning to) and links to a nice document explaining how it can be done anyway (which, I have to admit, didn't make me any wiser, however). The question is, out of curiosity, why the CHOST should not be changed and what would happen if one did it anyway. I willingly believe that it would lead to problems, but would the actual cause of these problems actually be caused by the configuration of the machine being mixed up (for example, by the GNU build system / autoconf suddenly looking for a compiler or similiar tools / libraries under a path or by a name involving, for example, i486-pc-linux-gnu, which does not automatically exist of the appropriate tools have not been installed accordingly. Or would problems arise because code generated with the new CHOST does no longer "fit" to code generated with the previous / old CHOST? Any hints here would be welcome. Again, it's not that I need to know in order to do something, but all of this stuff has always worked so well every time I've built a package, and if feels kind of strange not to know why / how it actually works. As neither the docs of autoconf, binutils nor GCC could properly enlighten me, I thought I'd ask here. ;-) Greetings, Nils -- Nils Holland * Ti Systems, Wunstorf-Luthe (Germany) Powered by GNU/Linux since 1998
Re: [gentoo-user] Re: How can I reset mount-count?
On 18:20 Wed 02 Feb , walt wrote: > > The ext4 wiki site claims that fsck runs 2 to 20 time faster than > ext3, depending on the number and size of the files contained in > the ext4 filesystem. > > I have no experience with ext4 (yet), but I would welcome comments > from those who do. Well, on one of my machines, I have converted all my filesystems to ext4 recently. Basically, I did a backup of the data on the machine, reformated all my partitions as ext4 (except for /boot, which always remains ext2 here) and copied back the data. The largest of these "now ext4 and previously ext3" partitions is a 30% full, ~500 GB /home partitition (but don't ask me for the current number of files). While I'm not really one of those benchmark type of guys sitting in front of their computers with a watch and raving like mad about every 0.0001 second saved during some process, I would say that an fsck on that ext4 filesystem certainly works faster than it did when it still was a ext3 filesystem. Probably not really 20 times faster, but noticably faster. On the other hand, the ext3 incarnation of that fs was in use for years, the ext4 is a fresh copy of it, without any significant fragmentation (yet), so this might also play a role in leading to faster fsck performance. In any case, besides that I can say that at least on that one system of mine, ext4 works really well and I've not yet had any problems with it. Greetings, Nils -- Nils Holland * Ti Systems, Wunstorf-Luthe (Germany) Powered by GNU/Linux since 1998
[gentoo-user] Re: xfce woes
On 02/02/2011 09:15 PM, Alan McKinnon wrote: Apparently, though unproven, at 00:00 on Thursday 03 February 2011, walt did opine thusly: As much as I like the convenience of automounting as a luser, all of my bofh instincts cry out that lusers shouldn't be allowed to mount a filesystem! This is one of those Windows/convenience versus unix/security things, I think, but I'm just an amateur bofh. What do you professional bofhs think? Depends on what the machine is used for. For a multiuser box, you probably want user to not shutdown/reboot, Yes, even I thought of that. As an amateur, though, I have no idea how many multi-user machines still exist. When I was a lad, the campus computer(s) still ran batch jobs submitted on punch cards. We had to wait for hours or even the next day to discover a stupid typo. Actually, the profs didn't use punchcards, just us peons. The profs had dumb terminals so they could log in to the central server -- and sit for as long as five minutes to discover if the server had crashed, or was just busy serving the needs of the department chairman's secretary. Over the years, the frustrations have merely morphed, not vanished :( be able to mount removeable media... That was really what I was asking. I hear horror stories about employees plugging usb thumb drives into corporate workstations to steal files, or maybe infecting the whole network with malware from a "lost" thumb drive found at a bus stop or a car park.
[gentoo-user] Re: Any way to get real text console without killing X capability?
On 02/03/2011 08:07 AM, Walter Dnes wrote: Is there a way to have a real text console? I know that I can have 2 X sessions on tty10 and tty11 with different resolutions, and colour depths. Is there a way to set tty1..tty9 to 640x480 *IN TEXT MODE*, so that lat1-?? fonts would look normal, without killing the ability to have X run at 1920x1200? Note that the suggestion the others gave about disabling KMS is probably not what you need. Disabling KMS means that it will also be disabled for X11, not only for the framebuffer. As you can imagine this is a bad thing.
Re: [gentoo-user] Any way to get real text console without killing X capability?
On Thursday 03 February 2011 06:07:55 Walter Dnes wrote:
> Back around 2000, we still had CRT monitors, not LCDs. The cheaper
> monitors shimmered badly in GUI mode and were hard on my eyes. One of
> the factors that drove me to linux back then was that, except for web
> browsing and spreadsheets, I could do most of my work in a true text
> console (and I don't mean an xterm, either). I love sharp crisp
> textmode fonts on a text console. I used to do email and write code in
> text consoles, and {CTRL-ALT-F10} to GUI for browsing (yes, I tweaked my
> /etc/inittab to allow 10 consoles).
>
> Recently, however, video drivers for both Intel and ATI have switched
> over to some brain-dead framebuffer mode that renders regular
> consolefonts microscopic. Also the line lengths are ridiculously long.
> E.g. on my 1920x1200 LCD monitor, an 8x16 font gives 75 rows of 240
> columns each. On my 14" notebook (1366x768) it's 48 rows of 170 columns
> each. The largest consolefont I can find in /usr/share/consolefonts/ is
> sun12x22. It's large enough to be at least readable, but I don't like
> the way the font looks, and it's still too small for my taste, 54 rows
> of 160 columns each on the LCD monitor.
>
> My questions, in decreasing order of preference, are...
>
> Plan a) Is there a way to have a real text console? I know that I can
> have 2 X sessions on tty10 and tty11 with different resolutions, and
> colour depths. Is there a way to set tty1..tty9 to 640x480 *IN TEXT
> MODE*, so that lat1-?? fonts would look normal, without killing the
> ability to have X run at 1920x1200?
Yes.
Leave KMS enabled and add the parameter:
video=1024x768 (or whatever suits your screen and taste)
to your kernel line. You shouldn't need vesafb, uvesa or any other drivers to
achieve this.
Read more here: /Documentation/fb/modedb.txt
I think that if you revert to a framebuffer driver then you must add nomodeset
on your kernel line.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] [Slightly OT] Linking to a non-standard library installed using portage
On Thu, Feb 3, 2011 at 12:39 PM, Mark Knecht wrote: > Hi, > This is going to be trivial for anyone who actually programs. > Thanks in advance. > > How do I link to a library I installed using portage? If someone > could show me an example make file that would be great. Don't know about nvcc but with gcc you'd use -l (that's a lower-case letter L): -lyourlibname So in your case maybe something like this might work: nvcc -L/usr/lib64/libta_lib ta-lib-ma.cu -o ta-lib-ma -lta_lib
[gentoo-user] Re: [Slightly OT] Linking to a non-standard library installed using portage
On Thu, Feb 3, 2011 at 10:39 AM, Mark Knecht wrote: > > How do I link to a library I installed using portage? And in this case it was simple once I found the right examples: nvcc -lta_lib ta-lib-ma.cu -o ta-lib-ma Sorry for the noise. Cheers, Mark
Re: [gentoo-user] [Slightly OT] Linking to a non-standard library installed using portage
On Thu, Feb 3, 2011 at 1:39 PM, Mark Knecht wrote: > What do I link to? > > I've tried various things like this but none seem to find the library > correctly: > > mark@c2stable ~/CODE/CUDA/Mark $ nvcc -L/usr/lib64/libta_lib > ta-lib-ma.cu -o ta-lib-ma > /tmp/tmpxft_0a8b_-13_ta-lib-ma.o: In function `main': > tmpxft_0a8b_-1_ta-lib-ma.cudafe1.cpp:(.text+0x9f): > undefined reference to `TA_SMA' > collect2: ld returned 1 exit status I haven't used nvcc, but I assume it works like gcc. If so, you'll want to use the -L option for the library path and the -l option to specify the library name. For example: nvcc ta-lib-ma.cu -o ta-lib-ma -L/usr/lib64 -lta_lib
[gentoo-user] [Slightly OT] Linking to a non-standard library installed using portage
Hi,
This is going to be trivial for anyone who actually programs.
Thanks in advance.
How do I link to a library I installed using portage? If someone
could show me an example make file that would be great. I've no real
experience in C and what I did have was in Windows years ago so I'm
undertaking some study here. I wrote a simple little test program that
calculates a simple moving average using ta-lib:
mark@c2stable ~/CODE/CUDA/Mark $ cat ta-lib-ma.cu
#include
#include
#define VECTOR_LEN 100
int main(int argc, char **argv)
{
int i;
double MyData[VECTOR_LEN];
double MySMA[VECTOR_LEN];
TA_Integer outBeg;
TA_Integer outNbElement;
for (i = 0; i < VECTOR_LEN; i++)
{
MyData[i] = (i*i)/(10*i);
}
TA_SMA(0, VECTOR_LEN-1, MyData, 10, &outBeg, &outNbElement, MySMA);
for ( i=0; i< outNbElement; i++ ) printf("Bar %d = %f\n", outBeg+1,
MySMA[i]);
return 0;
}
mark@c2stable ~/CODE/CUDA/Mark $
The program compiles fine using NVidia CUDA compiler nvcc creating an
object file ta-lib-ma.o:
mark@c2stable ~/CODE/CUDA/Mark $ nvcc -c ta-lib-ma.cu
mark@c2stable ~/CODE/CUDA/Mark $ ls -al ta-lib-ma.*
-rw-r--r-- 1 mark users 477 Feb 3 10:08 ta-lib-ma.cu
-rw-r--r-- 1 mark users 17184 Feb 3 10:12 ta-lib-ma.o
mark@c2stable ~/CODE/CUDA/Mark $
However I cannot figure out how to link it to the ta-lib files
installed by portage:
mark@c2stable ~/CODE/CUDA/Mark $ equery files ta-lib
[ Searching for packages matching ta-lib... ]
* Contents of sci-libs/ta-lib-0.4.0:
/usr
/usr/bin
/usr/bin/ta-lib-config
/usr/include
/usr/include/ta-lib
/usr/include/ta-lib/ta_abstract.h
/usr/include/ta-lib/ta_common.h
/usr/include/ta-lib/ta_defs.h
/usr/include/ta-lib/ta_func.h
/usr/include/ta-lib/ta_libc.h
/usr/lib64
/usr/lib64/libta_lib.a
/usr/lib64/libta_lib.la
/usr/lib64/libta_lib.so -> libta_lib.so.0.0.0
/usr/lib64/libta_lib.so.0 -> libta_lib.so.0.0.0
/usr/lib64/libta_lib.so.0.0.0
mark@c2stable ~/CODE/CUDA/Mark $
What do I link to?
I've tried various things like this but none seem to find the library correctly:
mark@c2stable ~/CODE/CUDA/Mark $ nvcc -L/usr/lib64/libta_lib
ta-lib-ma.cu -o ta-lib-ma
/tmp/tmpxft_0a8b_-13_ta-lib-ma.o: In function `main':
tmpxft_0a8b_-1_ta-lib-ma.cudafe1.cpp:(.text+0x9f):
undefined reference to `TA_SMA'
collect2: ld returned 1 exit status
mark@c2stable ~/CODE/CUDA/Mark $
Thanks in advance for any pointers.
Cheers,
Mark
Re: [gentoo-user] Any way to get real text console without killing X capability?
On Thu, Feb 3, 2011 at 12:07 AM, Walter Dnes wrote: > Recently, however, video drivers for both Intel and ATI have switched > over to some brain-dead framebuffer mode that renders regular > consolefonts microscopic. Also the line lengths are ridiculously long. Sounds like KMS perhaps. Try to add "nomodeset" to your kernel boot command-line to disable it and see how that goes. Alternately don't use the KMS driver at all, disable all framebuffer/bootsplash stuff, don't use vga=xyz on your kernel command-line if it's there. (I don't know if avoiding KMS is always possible, at least with my laptop's ATI chipset I still have the choice to use the old driver) Worst-case scenario, use fbset and setfont to set a resolution and font size that is a close approximation to what you are comfortable with, then make it permanent in the kernel command-line and consolefont settings.
Re: [gentoo-user] Is anyone here using RTL8192CU wifi device in Gentoo?
On Wed, Jan 26, 2011 at 6:03 PM, Paul Hartman wrote: > On Wed, Jan 26, 2011 at 4:18 PM, Mick wrote: >> On Wednesday 26 January 2011 16:22:03 Paul Hartman wrote: >>> Hi, >>> >>> I recently bought a USB wifi adapter with RTL8192CU chipset. Drivers >>> are available from Realtek's website, and are updated regularly (last >>> month), but are not in the mainline Linux kernel or in the portage >>> tree. >>> >>> Compiling and installing the drivers is not a problem, but every time >>> I insert the USB adapter my computer freezes and no amount of >>> magic-SysRq can get me out of it. I tried on 2 different Gentoo >>> machines with the same result. >>> >>> The adapter works (poorly...) on a Windows XP machine, so I know the >>> hardware is functional. >>> >>> Does anyone else here use these drivers? >> >> I'm not using this hardware, but have you seen this? >> >> http://amailbox.net/mailarchive/linux-kernel/2010/12/13/4658671 > > Hi, > > Thanks for the pointer! While that firmware itself does nothing for me > (the Realtek driver already includes the latest firmware in the source > code), Googling Larry Finger's name along with this chipset led me to > some other (and very recent) posts which tell me that this driver only > works on 32-bit systems and that no functioning 64-bit driver is > available. That's too bad. I suppose all I can do now is wait for > Realtek to fix it and release a working driver. > > Thanks again. Looks like Mr. Finger has submitted a driver for this device a couple days ago, targeting inclusion in the 2.6.39 kernel. I'll have to give it a try. http://comments.gmane.org/gmane.linux.kernel.wireless.general/63851
Re: [gentoo-user] Re: USB stick recognition problem
On Thu, Feb 3, 2011 at 12:52 AM, Alan McKinnon wrote: > Apparently, though unproven, at 08:08 on Thursday 03 February 2011, Paul > Hartman did opine thusly: > >> On Wed, Feb 2, 2011 at 8:11 PM, walt wrote: >> > On 02/02/2011 03:05 PM, Paul Hartman wrote: >> >> On Wed, Feb 2, 2011 at 3:29 PM, walt wrote: >> >>> On 02/02/2011 07:48 AM, Paul Hartman wrote: >> I have a USB SD-card reader which cannot read the partition table when >> first inserted into the PC. >> >>> >> >>> That sounds to me like a bug :) do you see the same on other >> >>> computers? >> >> >> >> Yes, every computer (for several kernel versions now) >> > >> > Well, if an older kernel uses the card reader normally and newer kernels >> > don't, then I assume a kernel bug is responsible. >> > >> > What *I* would do is to use git-bisect in Linus's kernel git repository >> > to isolate the "bad" commit and then report it to the person who >> > submitted the original bad patch to Linus. >> > >> > If that idea sounds weird -- I plead nolo contendere. Yet, it gets >> > kernel bugs fixed. (Very roughly paraphrasing Galileo ;) >> >> I meant that I've tried it for a few kernel versions (it's not a new >> card reader, it's a few years old). It has never worked properly in >> Linux since I've owned it. > > Then the reader itself is probably horribly broken. Or has been built to > comply to "whatever broken Windows is doing today" > > My USD card reader JustWorks(tm) everywhere with everything. And they are dirt > cheap, about the price of the smallest SD card I can buy. > > Time for a new reader perhaps? Of course, I have others. I was just reporting to Helmut what workaround I've used in case his has a similar problem. The misbehaving one is extremely fast when it works, compared to the others I've tried. It uses the Silicon Motion SM331 chipset. It's a generic no-name reader. I've seen reports that newer packages of the same reader now use the SM334 chipset instead, which I imagine fixes whatever problems may have been present in the older revision. I'm generally more interested in learning why things are broken than using things that are not. :) I didn't mean to derail the original thread. Sorry about that!
Re: [gentoo-user] Any way to get real text console without killing X capability?
On 02/03/2011 07:07 AM, Walter Dnes wrote:
Back around 2000, we still had CRT monitors, not LCDs. The cheaper
monitors shimmered badly in GUI mode and were hard on my eyes. One of
the factors that drove me to linux back then was that, except for web
browsing and spreadsheets, I could do most of my work in a true text
console (and I don't mean an xterm, either). I love sharp crisp
textmode fonts on a text console. I used to do email and write code in
text consoles, and {CTRL-ALT-F10} to GUI for browsing (yes, I tweaked my
/etc/inittab to allow 10 consoles).
Recently, however, video drivers for both Intel and ATI have switched
over to some brain-dead framebuffer mode that renders regular
consolefonts microscopic. Also the line lengths are ridiculously long.
E.g. on my 1920x1200 LCD monitor, an 8x16 font gives 75 rows of 240
columns each. On my 14" notebook (1366x768) it's 48 rows of 170 columns
each. The largest consolefont I can find in /usr/share/consolefonts/ is
sun12x22. It's large enough to be at least readable, but I don't like
the way the font looks, and it's still too small for my taste, 54 rows
of 160 columns each on the LCD monitor.
My questions, in decreasing order of preference, are...
Plan a) Is there a way to have a real text console? I know that I can
have 2 X sessions on tty10 and tty11 with different resolutions, and
colour depths. Is there a way to set tty1..tty9 to 640x480 *IN TEXT
MODE*, so that lat1-?? fonts would look normal, without killing the
ability to have X run at 1920x1200?
Plan b) Are there extra large versions of lat1-?? fonts (24 pixels wide
for my 24" LED and 17 pixels wide for my notebook) that I can use in
framebuffer mode to emulate the look of real text mode?
Plan c) Are there any font-design and manipulation utilities that will
allow me to modify lat1-?? fonts to generate bigger versions?
Maybe you should also try using a tiling-window-manager like awesome or
xmonad. This way you can easily switch between consoles and most
x-terminals support a lot of fonts.
Johannes Kimmel
Re: [gentoo-user] xfce woes
On Wed, Feb 2, 2011 at 5:23 PM, John wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Gentoo Lite Users, > > I have recently upgraded to xfce 4.8 > All seems to be well apart from > a) Normal Users cannot shutdown > I resolved this using exec ck-launch-session startxfce4 to start xfce. > b) Normal Users cannot automount using xfce (can through sudo mount). > > I have followed xfce guide using use flags as suggested. > > Users are in plugdev group > dbus and consolekit are in default runlevel. > > I don't have this problem. For me it works fine. Are normal users members of usb group ? > I have removed hal (by masking) and makes no difference. > > I removed too. > Have tried adding /usr/lib64/xfce4/session/xfsm-shutdown-helper > to sudo but no help there. > > Have looked on a few forums and suggested that config file for this > is /etc/dbus.d/system.d/hal.conf. This does have a gentoo section which > looks like it would allow above. > > Any suggestions would be appreciated. > > I have this issue on 2 machines. > > > - -- > John D Maunder > j...@articwolf.myzen.co.uk > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.16 (GNU/Linux) > > iQEcBAEBAgAGBQJNSa8nAAoJEOuCgqleN2EyeUwH/1Fw2uxm+UdGM9MYP3kOumz5 > tPqXemnrAfne41cIslzKbUI11yXrZrFbVAe2cOAsYN4MWIgwzJgh4vwe0vqMadEa > 2JmaEEx2mrd7gecTQnv7Qctc7L7PECXt7YKUcwAs7jXZK5AFq4blknqy8ra1gE9o > lyhRh0nJc1fFu6jI1O1tQ2TdeIyi631+qAM8LiM905vY+qGE+L4xmKclC3syMCF8 > zPvTyR8J7cqn5E+6T2APoT0EPw2fm0ad8B5awQumL+LA5Uc8eXpKgrPqSmPoAsh4 > aEGfH4YAK70Bkz4kVPAxn6IxORjTdR1A068d7CV4M0ujidHF4XCQe7V1FrQ9KV0= > =xut7 > -END PGP SIGNATURE- >
Re: [gentoo-user] Avoiding HAL
Le 02/02/2011 23:59, Brian Waters a écrit : > Hi there. I recently took a few months off from Gentoo to try Ubuntu > (I heard it "just works", and that is a Good Thing) only to find that > I'd much rather be back on Gentoo again. (The fact that Ubuntu ships > with PulseAudio means that sound it basically broken out of the box, > and I'm excited for Xfce 4.8.) > > It's been a few months since I've been around, and I'd like to know if > HAL has been fully deprecated yet. I'd like to avoid using it if at > all possible, since that seems to be the way of the future. So I'm > wondering what versions of udev and X server (and any other packages, > dbus maybe?) I need to unmask in order to get rid of the HAL > dependency. > > Thanks a lot! > > - BW > Hi I just installed stable Gentoo on a new PC without any hal: profile /usr/portage/profiles/default/linux/x86/10.0/desktop/ make.conf with -hal USE xorg-server 1.9.2 nvidia-drivers 260.19.29 udev 151-r4 dbus 1.4.1 xfce4 4.8 Everything works nice. Cheers, -- Jacques
Re: [gentoo-user] Avoiding HAL
Brian Waters wrote: On Thu, Feb 3, 2011 at 1:41 AM, Dale wrote: In GIMP under the file menu, there is a option to get pictures from a camera. I have never used that but I guess that is where hal comes in. It may be something else but that is all I could find. Christ, it's like .dll hell all over again. There's probably a use flag to turn that off. - BW Yep, just disable hal for one. Since hal is gone, dbus may be another that would disable that. I don't see the need tho. Until you asked, I didn't even notice that it was there. Just don't use it. I been using GIMP for a good while and still haven't figured out more than half of it. I think it can do everything except wash dishes. lol I'm just glad to have something that doesn't kill my mouse and keyboard. ;-) Dale :-) :-)
Re: [gentoo-user] Avoiding HAL
Am 03.02.2011 00:20, schrieb Brian Waters: > Anyway, I digress. Maybe I'll start a thread on that when the time comes. > > - BW Hi, you might want to take a look at the forums: http://forums.gentoo.org/viewtopic-t-858965-highlight-.html Regards kh -- _ ASCII ribbon campaign ( ) against HTML e-mail X / \ ascii ribbon campaign - stop html mail - www.asciiribbon.org
