All news of interest and can provide an info for you, and so can assist in the search for new news.
echo "deb http://liquorix.net/debian sid main" | sudo tee /etc/apt/sources.list.d/liquorix.list
echo "deb-src http://liquorix.net/debian sid main" | sudo tee -a /etc/apt/sources.list.d/liquorix.list
sudo apt-get update
sudo apt-get install '^liquorix-([^-]+-)?keyring.?'sudo apt-get install linux-headers-2.6-liquorix-686 linux-image-2.6-liquorix-686sudo apt-get install linux-headers-2.6-liquorix-amd64 linux-image-2.6-liquorix-amd64cd /tmp
chmod +x install-fglrx-debian.sh
sudo ./install-fglrx-debian.sh
[... ] My suggestion was to hook these read operations directly in the root of the problem: since every readdir() is performed by the kernel, then we could have a list kept in kernel to check on every readdir() operation. If the inode being read was present in this list, then it simply shouldn't be copied onto the destination buffer, which should be returned to the user.
This first implementation was hardcoded with my own inode numbers (relative to the legacy tree), and this was when Felipe Damasio came with his kernel abilities and created a better interface based on ioctls in order to register the entries that should be hidden from the userspace, and then we got our first release of GoboHide.
From these old days until now, GoboHide has been kept up to date to the newer kernel versions. The patch now is fully integrated with the VFS, which means that it works with any filesystem that supports directories and/or symlinks. It has been tested with EXT2, EXT3, ISOfs, JFFS2, JFS, NFS, ReiserFS, SquashFS and XFS, but certainly works with others, too.
-- info via Gobolinux
sudo gobohide -h /path/to/folder/to/hidesudo gobohide -u /path/to/folder/to/unhidesudo gobohide -lcat /proc/sys/kernel/sched_autogroup_enabledgedit ~/.bashrcif [ "$PS1" ] ; then
mkdir -p -m 0700 /dev/cgroup/cpu/user/$$ > /dev/null 2>&1
echo $$ > /dev/cgroup/cpu/user/$$/tasks
echo "1" > /dev/cgroup/cpu/user/$$/notify_on_release
fisudo rm /usr/local/sbin/cgroup_cleansudo gedit /etc/rc.localmkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agentcd
wget http://launchpadlibrarian.net/59511828/cgroup_patch
chmod +x cgroup_patch
sudo ./cgroup_patchsudo /etc/rc.local if [ "$PS1" ] ; then
mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks
fimount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
mkdir -m 0777 /sys/fs/cgroup/cpu/userI've done some tests and the result is that Lennart's approach seems to work best. It also _feels_ better interactively compared to the vanilla kernel and in-kernel cgrougs on my machine. Also it's really nice to have an interface to actually see what is going on. With the kernel patch you're totally in the dark about what is going on right now.-Markus Trippelsdorf
mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agentsudo chmod +x /etc/rc.localif [ "$PS1" ] ; then
mkdir -p -m 0700 /dev/cgroup/cpu/user/$$ > /dev/null 2>&1
echo $$ > /dev/cgroup/cpu/user/$$/tasks
echo "1" > /dev/cgroup/cpu/user/$$/notify_on_release
fisudo gedit /usr/local/sbin/cgroup_clean#!/bin/sh
if [ "$*" != "/user" ]; then
rmdir /dev/cgroup/cpu/$*
fisudo chmod +x /usr/local/sbin/cgroup_clean
When ever Ubuntu updates the Linux kernel to a more recent version, I have to go through the rigmarole of rebooting my machine for the changes to take effect. While for a home user, it may not be such a big thing, while running Linux in critical situations, it may not always be feasible to reboot the server each time the kernel gets updated because running applications have to be stopped, and daemons have to be terminated for the reboot to take place - which inevitably leads to loss of time and inconvenience to others.Read more »
Fig: Interactive Linux kernel map.
