At Donnerstag, 18. Februar 2010 23:29 Heiko Baums wrote:
> 2. What will happen if someone will use it accidentally wrong? Nothing
> except, that there will be many .pacnew files in this directory which
> can simply be renamed. So there won't be any serious bug.
Oh, so if someone use 'usr/lib/*' t
Except for wireless card (damn rt2860... I changed mine for an intel 4965!)
the eeepc line is pretty good with linux, and specially with arch ;)
Make sure to check out acpi-eeepc-generic from AUR:
http://aur.archlinux.org/packages.php?ID=23318
Or even better, update to latest subversion (
http://c
Mu investigations where that the BIOS controlled Fn+F2, but it could be the
kernel module which I did not suspect at the time and so have not tested.
On my EeePC 1000, bios previous to revision 1003 did not controlled Fn+F2;
acpi-eeepc-generic needed to be used to enable/disable wifi. On newer bios
On Wed, Feb 17, 2010 at 6:23 PM, Ray Kohler wrote:
> On Wed, Feb 17, 2010 at 6:13 PM, Xavier Chantry
> wrote:
>> On Thu, Feb 18, 2010 at 12:00 AM, Ray Kohler wrote:
>>>
>>> Downgrading libdrm makes X work again. Is this already being worked
>>> on, or should I open a bug? If so, against which pa
Am Thu, 18 Feb 2010 11:20:11 +0100
schrieb Pierre Chapuis :
> Recursion is a good idea but that's not what is usually expected from
> *. I would suggest to use ** like in ZSH if it is implemented. Real
> regular expressions support would solve all those problems but that's
> probably overkill.
It
Am Thu, 18 Feb 2010 22:52:37 +0100
schrieb Attila :
> That is true and every example was a good example. But there is a
> little risk that you got lazy if you don't document what you have
> done and than including a complete directory with a lot of files
> could end in a bugreport where people sea
At Donnerstag, 18. Februar 2010 19:30 clemens fischer wrote:
> Not likely. Files named like something/other*, with the star being
> a literal instead of a glob are very, very rare.
There is no guarantee that this will be used in this way.-)
> On the contrary, people have provided good examples
On Thu, Feb 18, 2010 at 1:11 PM, Fons Adriaensen wrote:
>
> On Thu, Feb 18, 2010 at 12:25:51PM -0800, epinull wrote:
> > On Thu, Feb 18, 2010 at 10:43 AM, kludge wrote:
> >
> > > > Well, since I don't have /etc/acpi at all it looks like this
> > > > switch works without any soft support at all. S
On Thu, Feb 18, 2010 at 12:25:51PM -0800, epinull wrote:
> On Thu, Feb 18, 2010 at 10:43 AM, kludge wrote:
>
> > > Well, since I don't have /etc/acpi at all it looks like this
> > > switch works without any soft support at all. So I guess it
> > > just can't be disabled.
> >
> > unless you instal
On Thu, Feb 18, 2010 at 10:43 AM, kludge wrote:
> > Well, since I don't have /etc/acpi at all it looks like this
> > switch works without any soft support at all. So I guess it
> > just can't be disabled.
>
> unless you install acpid and acpi-eeepc-generic. acpid puts acpi
> event-handling in us
On Mon-2010/02/01-11:26 Thanos Zygouris wrote:
> P.S.1 : Most of the CDs are bootable ones, writen with "cdrecord -v
> speed=8 dev=/dev/scd0 -data -tao -multi". They boot normally though.
I thought multi-session CDs must be "finished" or "finalized" before
they can be fully used?
clemens
> Well, since I don't have /etc/acpi at all it looks like this
> switch works without any soft support at all. So I guess it
> just can't be disabled.
unless you install acpid and acpi-eeepc-generic. acpid puts acpi
event-handling in userspace, so then you can /dev/null fn+f2.
acpi-eeepc-generic
Attila wrote:
> At Donnerstag, 18. Februar 2010 02:13 Dan McGee wrote:
>
>> No, we don't support globbing in these options. Question to the list-
>> does it make sense to do so?
>
> Instead this makes something easier i must say that this could be
> dangerous too because it could end in some str
On Thu, Feb 18, 2010 at 4:20 AM, Pierre Chapuis wrote:
> On Wed, 17 Feb 2010 20:34:09 -0600, Aaron Griffin
>
> wrote:
>>>
>>> No, we don't support globbing in these options. Question to the list-
>>> does it make sense to do so?
>>
>> Yes, but it would also be nice to support recursion here as we
On Thu, Feb 18, 2010 at 11:39:38AM +0100, Thomas Bächler wrote:
> Use the rfkill utility from core. It will display the rfkill devices and
> modify their state. As James said, using the sysfs interface is
> depreacted and it will disappear soon.
(/me reads rfkill.c)
Rfkill depends on the sysfs in
Am 18.02.2010 02:19, schrieb f...@kokkinizita.net:
> On Wed, Feb 17, 2010 at 05:36:31PM -0600, Aaron Griffin wrote:
>
>> Isn't this what rfkill is for?
>> http://linuxwireless.org/en/users/Documentation/rfkill
>
> You're right: /sys/devices/platform/eeepc/rfkill/rfkill0/state
> controls the wifi
On Wed, 17 Feb 2010 20:34:09 -0600, Aaron Griffin
wrote:
>>
>> No, we don't support globbing in these options. Question to the list-
>> does it make sense to do so?
>
> Yes, but it would also be nice to support recursion here as well. For
> instance:
>
> NoExtract = /usr/share/doc/*
>
> should
On Thu, 18 Feb 2010 10:33:00 +0100, James Rayner
wrote:
netcfg v2.5.2
This release brings a completely new auto wireless/wired configuration.
The old net-auto is deprecated and no longer included. There are also
some very minor configuration changes that may affect a few people.
...
Cont
netcfg v2.5.2
This release brings a completely new auto wireless/wired configuration.
The old net-auto is deprecated and no longer included. There are also
some very minor configuration changes that may affect a few people.
Move to new auto-wireless/wired
The new automatic connection has proper r
On Thu, 18 Feb 2010 02:19 +0100, f...@kokkinizita.net wrote:
> On Wed, Feb 17, 2010 at 05:36:31PM -0600, Aaron Griffin wrote:
>
> > Isn't this what rfkill is for?
> > http://linuxwireless.org/en/users/Documentation/rfkill
>
> You're right: /sys/devices/platform/eeepc/rfkill/rfkill0/state
> contro
20 matches
Mail list logo
