Did you know that you can set php.ini values right inside the .htaccess file?
You can do so by adding lines like these:
#format php_value setting_name setting_value #example php_value upload_max_filesize 128M
Did you know that you can set php.ini values right inside the .htaccess file?
You can do so by adding lines like these:
#format php_value setting_name setting_value #example php_value upload_max_filesize 128M
Problem:
IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn/pi.c:1: error: stray ‘\357’ in program
This is caused by “invalid” characters in the code, specifically I encountered this while trying to compile the Intel EMGD driver for my EEEPC’s graphics card.
Thanks to the helpful folks over here, there’s a solution:
cd IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn
cat -v pi.c | awk '{if(NR>1) print $0}' > tmp # make strange characters on first visible and remove
mv tmp pi.c
That makes the invalid characters visible and removes them.
In this case, it leaves some partial, garbage comments behind, so the file still wont compile.
To resolve this, I opened the file in vim, and quickly searched for and removed the faulty comments (and some I didn’t have to remove).
Remember to answer “no” to the question of re-extracting the tarball each time you retry building this.
Attached is the original driver file, and my modified copy of pi.c
Result:
"Completed EMGD Installation"
I have no idea how many blank CD’s I’ve seen wasted on having a file system with a single .iso file on them. Then, I found this page: http://iso.snoekonline.com/iso.htm
It tells you how to burn an image with basically any Windows-based software out there. If someone runs Linux, I assume they can figure it out for themselves.
Archived for my convenience right here.
Found this somewhere.
Works for me.
Section "ServerLayout" Identifier "BodhiZazen's KVM xorg.conf" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Module" Load "record" Load "dri" Load "extmod" Load "glx" Load "dbe" Load "dri2" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "vmmouse" Option "Protocol" "SysMouse" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" HorizSync 20.0 - 50.0 VertRefresh 40.0 - 80.0 Option "DPMS" EndSection Section "Device" Identifier "Card0" Driver "vesa" VendorName "KVM - std" BoardName "GD 5446" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Modes "800x600" EndSubSection EndSection
Several programs, like “timelimit” and “timeout”, exist to prevent a process from running for too long.
However, if you want to do this on a box where neither is installed, there’s a way to do so with bash alone.
Based on the original script I found at pixelbeat.org…
#!/bin/sh
# Execute a command with a timeout
# Author:
# http://www.pixelbeat.org/
# Notes:
# If the timeout occurs the exit status is 128.
# There is an asynchronous (and buggy) equivalent of this
# script packaged with bash (under /usr/share/doc/ in my distro),
# which I only noticed after writing this.
# I noticed later again that there is a C equivalent of this packaged
# with satan by Wietse Venema, and copied to forensics by Dan Farmer.
# Changes:
# V1.0, Nov 3 2006, Initial release
# V1.1, Nov 20 2007, Brad Greenlee
# Make more portable by using the 'CHLD'
# signal spec rather than 17.
if [ "$#" -lt "2" ]; then
echo "Usage: `basename $0` timeout_in_seconds command" >&2
echo "Example: `basename $0` 2 sleep 3 || echo timeout" >&2
exit 1
fi
cleanup() {
{ kill %1 2>/dev/null; }& # kill sleep $timeout if running
kill %2 2>/dev/null && exit 128 # kill monitored job if running
}
set -m # enable job control
trap "cleanup" CHLD # cleanup after timeout or command
timeout=$1 && shift # first param is timeout in seconds
sleep $timeout& # start the timeout
"$@" # start the job
I made a new script in bash, which also returns the correct exit status if the command completed before the timeout: timeout.bash
Works well for me, at least 🙂
Accidentally stumbled across the “Debian Cheat Sheet” at http://carlo17.home.xs4all.nl/howto/debian.html (now dead – see pdf below)
Finally some documentation on why the heck pinning with “Package: *” and “Package: mypackage” doesn’t mix well, and other useful knowledge.
In case the link goes dead, here’s a PDF: debian_cheat_sheet.pdf
This was blatantly stolen from technovelty, kept here because I hate it when my bookmarks die.
For some reason, people seem to get this quite wrong a lot of the time. Certainly one should not be playing with symbols that start with __ unless you really know what you’re doing with them.
ianw@lime:~/tmp/override$ cat override.c
#define _GNU_SOURCE 1
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <dlfcn.h>
pid_t getpid(void)
{
pid_t (*orig_getpid)(void) = dlsym(RTLD_NEXT, "getpid");
printf("Calling GETPID\n");
return orig_getpid();
}
ianw@lime:~/tmp/override$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
printf("%d\n", getpid());
}
ianw@lime:~/tmp/override$ gcc -shared -fPIC -o liboverride.so override.c -ldl
ianw@lime:~/tmp/override$ gcc -o test test.c
ianw@lime:~/tmp/override$ LD_PRELOAD=./liboverride.so ./test
Calling GETPID
15187
I found these “misuse levels” over at technovelty, which they originally ripped from Rusty Russel’s Bleeding Edge Page, which is a page you should definitely check out if you haven’t.
Anyway, I found these “misuse levels” both hilarious to read and at the same time somewhat concerning, as I started thinking “Where does my code really go on this list?”
If you have a harddrive password (most laptops do this) or full disk encryption, you might not feel the need for an additional login after your system boots.
On most Debian-based systems, TTY’s 1 through 6 are available after boot, while TTY 7 is used for Xorg. Therefore, I like to put my auto-login TTY on TTY 8, so it’s out of the way and leaves TTY 1 available for troubleshooting and similar.
Auto-login to Xorg requires two things: The actual auto-login and a script which loads Xorg.
First things first. The autologin.
In the olden days on a Debian system, this was done by adding a line similar to this one in /etc/inittab:
8:23:respawn:/bin/login -f bolt tty8 /dev/tty8 2>&1
This spawns a TTY 8 and logs in as “bolt” (change to suit your needs). It will do so on runlevels 2 and 3.
Now, however, the tool “rungetty” is generally used for this, as it’s more flexible and performs the same functions with a cleaner syntax. First, “apt-get install rungetty” to make sure it’s there, then add a line similar to the following:
8:3:respawn:/sbin/rungetty tty8 --autologin bolt
Note that on Debian Lenny and older, the version of rungetty has a specific check in code which only allows –autologin to work on tty1. If asked to autologin on another tty, rungetty would silently fail and spawn a normal login tty. This restriction has been removed from Squeeze and onwards.
On Ubuntu 10.10, the tty configuration is not in /etc/inittab. There, you have to add a file called “/etc/init.d/tty8.conf” with the following contents:
# tty8 - getty # # This service maintains a getty on tty8 from the point the system is # started until it is shut down again. start on runlevel [23] stop on runlevel [!23] respawn exec /sbin/rungetty tty8 --autologin bolt
I basically copied tty6.conf and modified it to make that.
Autostarting Xorg
So by default when you login, both Debian and Ubuntu will leave you with a bash prompt, and very little graphical goodness. Thus, you want your login script to start Xorg, but only if Xorg is not already running, and we’re on tty8. Otherwise, switching from Xorg to a console with, for example, ctrl+alt+f1, would cause another attempt to launch Xorg.
Thus I made this script, named “.bash_login”, and put it in my home directory.
# ~/.bash_login: executed by bash(1) for login shells.
# include .profile if it exists
if [ -f "${HOME}/.profile" ] && [ -r "${HOME}/.profile" ]; then
source "${HOME}/.profile"
fi
# if we're not root and we're logged in on tty8, we assume a rungetty autologin and start xorg
if [ ! -z "${UID:-}" ] && [ "$UID" != "0" ] && [ -z "${DISPLAY}" ] && [ ! -z "${SHLVL:-}" ] && [ "$SHLVL" == "1" ]; then
if [ "$(tty)" == "/dev/tty8" ]; then
trap "chvt 1; logout" INT TERM EXIT
chvt 8
while true; do
echo "starting xorg"
startx
echo "sleeping 2 seconds"
sleep 2
done
fi
fi
This script will do a few sanity checks, then run Xorg. If Xorg exits, it will sleep 2 seconds and run it again. If the script is told to stop, it will change to tty1, then logout of tty8.

rdesktop on Linux will give this warning message when connecting to a Windows machine which has not been configured for 24-bit color RDP connections. This has, amongst other things, the effect of showing some horrible, jaggy desktop icons. See the pictures on the right for reference.
On Vista, Windows 7 and later (?), the solution is simple: Use 32-bit colors (-a 32)
On XP, which doesn’t support 32-bit colors, it gets a little more complicated. XP does support 24-bit connections, but this mode is disabled by default because of bandwidth concerns and bad choices.
To fix this problem on XP (nothing needs changing on the Linux or Windows client) you need to access the Local Machine Group Policy editor.
If you’re lucky, going to Start -> Run -> “gpedit.msc” will work for you. Type “gpedit.msc” without the quotes (and click “Run”).
If that does not open the group policy editor, this is the long way around:
NOTE: If the Terminal Services item, or other parts of the path, is missing, you need to restore the missing functionality by right clicking on Administrative Templates, clicking Add/Remove Templates, Add, and then adding system.adm. Details here (credits to Ramesh Srinivasan), archive copy here.
Rejoice with your new, shiny desktop icons and full 24-bit desktop.