protect XFCE panel

There is a kiosk mode.
usign which panel can be protected.

http://wiki.xfce.org/howto/kiosk_mode

Multimedia Keys in XFCE

VolumeUp :            amixer -q set Master  2+ unmute 

VolumeDown:         amixer -q set Master  2- unmute 

Mute:                    amixer -q set Master toggle 

there is much more to refer: see the link( for dell inspiron )

http://linuxsociety.org/howto/dellinspironmmk.html

Slackware Linux Wireless mystery..

There are three primary configuration files that need to be configured before we can use our card, and they are:

/etc/rc.d/rc.inet1.conf
/etc/rc.d/rc.wireless.conf
/etc/wpa_supplicant.conf

First, I must mention that I find the rc.wireless.conf to not be of much value. It is more of a "global" wireless settings file that all wireless interfaces would inherit parameters from. While this might be useful in certain apps, I personally think it makes more sense to specify the wireless settings in rc.inet1.conf on a per-interface basis, just as you would for wired ethX connections. This allows you to specify unique settings for each wireless interface you may have on your system (useful if you have more than one). Thus, in my rc.wireless.conf I deleted all the provided examples and simply have the below.

# cat /etc/rc.d/rc.wireless.conf

VERBOSE=1
case "$HWADDR" in
# Generic example (decribe all possible settings)
*)
#INFO="Fill with your own settings..."
# ESSID (extended network name) : My Network, any
ESSID="SKY12345"
# NWID/Domain (cell identifier) : 89AB, 100, off
#NWID=""
# Operation mode : Ad-Hoc, Managed, Master, Repeater, Secondary, auto
#MODE=""
# Frequency or channel : 1, 2, 3 (channel) ; 2.422G, 2.46G (frequency)
#FREQ=""
#CHANNEL=""
# Sensitivity (cell size + roaming speed) : 1, 2, 3 ; -70 (dBm)
#SENS=""
# Bit rate : auto, 1M, 11M
#RATE=""
# Encryption key : 4567-89AB-CD, s:password
KEY="s:MYPASSPHRASE"
# RTS threshold : off, 500
#RTS=""
# Fragmentation threshold : off, 1000
#FRAG=""
# Other iwconfig parameters : power off, ap 01:23:45:67:89:AB
#IWCONFIG=""
# iwspy parameters : + 01:23:45:67:89:AB
#IWSPY=""
# iwpriv parameters : set_port 2, set_histo 50 60
#IWPRIV=""
;;
esac

Everything is commented out in the case statement, but I left the parameter names just incase down the road I ever need to use rc.wireless.conf.

The next step is the configuration of rc.inet1.conf and wpa_supplicant.conf.

rc.inet1.conf will allow us to specify the settings of each wired/wireless interface that is recognized by the output of

# ip link

The relevant (wireless) part of my rc.inet1.conf is as such:

# cat /etc/rc.d/rc.inet1.conf

IFNAME[4]="wlan0" <---- as shown by ifconfig and iwconfig
IPADDR[4]=""
NETMASK[4]=""
USE_DHCP[4]="yes"
WLAN_RATE[4]="54M auto"
WLAN_WPA[4]="wpa_supplicant"
WLAN_WPADRIVER[4]="wext"

The above should be sufficient for the majority of setups.

My advice is to use wpa_supplicant even if your AP does not use a key for access. The default wpa_supplicant.conf provides two network examples. The top (first) one is for an AP that requires a key and the second one is for an AP that does not (free public APs). I will focus my attention on the one that requires a key. Assuming your AP requires a key (most likely WPA-PSK w/ TKIP encryption), you first need to run

# wpa_passphrase essid-of-your-AP passphrase-of-your-AP  >> /etc/wpa_supplicant.conf

e.g.
# wpa_passphrase SKY12345 ABCD12345 >> /etc/wpa_supplicant.conf


This is to get a hexadecimal encryption key to be manually inserted into your wpa_supplicant.conf.

ASIDE: If you are clueless about some of the settings and capabilities of your AP, I suggest running

# iwlist wlan0 scan

If you get a message that the network is down, first type

# ifconfig wlan0 up

 This will show you all the APs that your card has detected, along with the essids, the encryption (if any) that they use, and the supported bit rates of that AP.

An example output of my personal wpa_supplicant.conf (edit, of course, for security reasons):

# cat /etc/wpa_supplicant.conf

# This line enables the use of wpa_cli which is used by rc.wireless
# if possible (to check for successful association)
ctrl_interface=/var/run/wpa_supplicant
# By default, only root (group 0) may use wpa_cli
ctrl_interface_group=wheel
eapol_version=1
ap_scan=1
fast_reauth=1
# WPA protected network, supply your own ESSID and WPAPSK here:
network={
scan_ssid=1
ssid="your-ssid-goes-here"
proto=WPA
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
#group=CCMP TKIP WEP104 WEP40
#psk below was made with wpa_passphrase
psk=abcdef12345abcdef12345abcdef12345abcdef12345abcdef
}

That's about it! You can either do a full system reboot or run the rc.inet1 script as root. If you want to just run the script on the wlan0 interface, the proper command is 'rc.inet1 wlan0_start'.

for information and source: see

http://epsilonprecision.com/index.php?option=com_content&view=article&id=51:slackware-wireless-tutorial&catid=34:tutorials&Itemid=53

http://linuxwireless.org/en/users/Drivers/b43#fw-b43-new

Cheers!!

C or C++ ..this is what Linus Torvald says.

From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (3 years, 6 days, 7 hours and 17 minutes ago)

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
> 
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
> it's BS.

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a lot 
of substandard programmers use it, to the point where it's much much 
easier to generate total and utter crap with it. Quite frankly, even if 
the choice of C were to do *nothing* but keep the C++ programmers out, 
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles 
Bader jokingly said "to piss you off", but it's actually true. I've come 
to the conclusion that any programmer that would prefer the project to be 
in C++ over C is likely a programmer that I really *would* prefer to piss 
off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using 
the "nice" library features of the language like STL and Boost and other 
total and utter crap, that may "help" you program, but causes:

 - infinite amounts of pain when they don't work (and anybody who tells me 
   that STL and especially Boost are stable and portable is just so full 
   of BS that it's not even funny)

 - inefficient abstracted programming models where two years down the road 
   you notice that some abstraction wasn't very efficient, but now all 
   your code depends on all the nice object models around it, and you 
   cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and 
portable C++ ends up to limit yourself to all the things that are 
basically available in C. And limiting your project to C means that people 
don't screw that up, and also means that you get a lot of programmers that 
do actually understand low-level issues and don't screw things up with any 
idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a primary 
objective, the "advantages" of C++ is just a huge mistake. The fact that 
we also piss off people who cannot see that is just a big additional 
advantage.

If you want a VCS that is written in C++, go play with Monotone. Really. 
They use a "real database". They use "nice object-oriented libraries". 
They use "nice C++ abstractions". And quite frankly, as a result of all 
these design decisions that sound so appealing to some CS people, the end 
result is a horrible and unmaintainable mess.

But I'm sure you'd like it more than git.

   Linus