Call for comments: feasibility of a FreeBSD pleasure and hospitality team

L

lockfile

I propose a team of loosely coordinated individuals that will go about the FreeBSD system and do fixins for various common tasks that are done by the desktop user of FreeBSD. This team will do activity such as the following:
  1. write scripts and modify configuration options for auto-mounting removable media
  2. test what tuning variables work magic for the desktop user, and create scripts to robot the actions
  3. create a suite of cron scripts that go about the system with the sole purpose of making the user happy
  4. recommend and test various popular FreeBSD desktop applications
  5. do minor polishing work on popular ports, such as installing the Adobe Flash plugin, and its "linuxulated" dependencies; scripts will automate the majority of the work
  6. most code will be Borne, and any other needed utilities will already be installed in the base system, or as a command from the port in question
  7. development will most likely be on SourceForge or some similar platform

What do y'all think?
 
In other words, making setup of a working desktop easier? I've too much stuff for a wishlist (fixing portmanager, finding a working conf for a serial trackball, finding an xorg.conf that fixes a serial-to-ps/2 trackpad (if one exists), putting /lookat/ in base, more thoroughly solving port conflicts (sysutils/pp vs p5-PAR-Packer iirc), but to counterpoint somewhat the first post, many tasks asked about here on the forums, and on the mail lists, INHO could be better served by rather than a wiki ( for advanced problems), something like a printable flowchart (flowchart-usb-dhcp.ps, flowchart-ppp.conf.ps, flowchart-pf-newer.ps, flowchart-ipfw.ps, flowchart-bridging.ps, flowchart-glabel-disks.ps) ... if revision date was prominent on each of them. (Though there may be unthought-of difficulties in such a scheme, such as I, not being qualified to begin to author any of them competently, and each may take many hours to initially draft properly).
.... Freely ignore the first half of that paragraph...
 
lockfile said:
I propose a team of loosely coordinated individuals that will go about the FreeBSD system and do fixins for various common tasks that are done by the desktop user of FreeBSD. This team will do activity such as the following:
  1. write scripts and modify configuration options for auto-mounting removable media
  2. test what tuning variables work magic for the desktop user, and create scripts to robot the actions
  3. create a suite of cron scripts that go about the system with the sole purpose of making the user happy
  4. recommend and test various popular FreeBSD desktop applications
  5. do minor polishing work on popular ports, such as installing the Adobe Flash plugin, and its "linuxulated" dependencies; scripts will automate the majority of the work
  6. most code will be Borne, and any other needed utilities will already be installed in the base system, or as a command from the port in question
  7. development will most likely be on SourceForge or some similar platform

What do y'all think?
Click to expand...

Sounds like a good plan. I'm always in when it comes to improving something.
 
jb_fvwm2 said:
In other words, making setup of a working desktop easier? I've too much stuff for a wishlist (fixing portmanager, finding a working conf for a serial trackball, finding an xorg.conf that fixes a serial-to-ps/2 trackpad (if one exists), putting /lookat/ in base, more thoroughly solving port conflicts (sysutils/pp vs p5-PAR-Packer iirc), but to counterpoint somewhat the first post, many tasks asked about here on the forums, and on the mail lists, INHO could be better served by rather than a wiki ( for advanced problems), something like a printable flowchart (flowchart-usb-dhcp.ps, flowchart-ppp.conf.ps, flowchart-pf-newer.ps, flowchart-ipfw.ps, flowchart-bridging.ps, flowchart-glabel-disks.ps) ... if revision date was prominent on each of them. (Though there may be unthought-of difficulties in such a scheme, such as I, not being qualified to begin to author any of them competently, and each may take many hours to initially draft properly).
.... Freely ignore the first half of that paragraph...
Click to expand...

Yea the flow-chart idea would help out plenty of new people. With the flow charts, people will know the steps to take, because the chronology of entering certain commands are sometimes uncertain even after reading documentation; you know what to do, but the order to enter the commands is nebulous. An example of that is partitioning new disks in FreeBSD on a separate drive, due to FreeBSD's paradigm of a partitions (a to h) in partitions (slices).
 
grigorovl said:
If you want all this, why not just use PC-BSD? It does many of those things.
Click to expand...

I think the PC-BSD guys should have done something similar to begin with instead of forking FreeBSD. What those guys did... I still don't agree. They should have improved on the strong foundation of this heirloom Unix. FreeBSD has a really good pedigree and that item should not be diluted with these "bastard" versions of FreeBSD. Certain special purpose forks like FreeBSD distros built around an appliance like a NAS or firewall are cool, but to fork the entire project is reckless.
 
@lockfile

Good idea, I can share what I currently have'use, that can be a good start for some things.

[*] write scripts and modify configuration options for auto-mounting removable media
Click to expand...

This script searches /dev for USB drives and lists them with date when they were attached.

Code: 
% [B]devfs.sh[/B]
usage: devfs.sh OPTION
  -c | --conky   display stats with colors for conky(1)
  -p | --plain   display plain stats

% [B]devfs.sh -p[/B]
devfs(8)
  ADDED       TIME   DEVICE
  2011/04/04  08:56  /dev/da0s1

Code: 
#! /bin/sh

COLOR_LIGHT="\${color #dddddd}"
COLOR_DARK="\${color #999999}"

__usage() {
  echo "usage: $( basename ${0} ) OPTION"
  echo "  -c | --conky   display stats with colors for conky(1)"
  echo "  -p | --plain   display plain stats"
  exit 1
  }

__head() {
  echo "${COLOR_LIGHT}devfs(8)"
  echo -n "${COLOR_DARK}"
  printf "  %-10s  %-5s  %-s\n" ADDED TIME DEVICE
  }

__body() {
  ls /dev/da? 2> /dev/null \
    | while read I
      do
	echo -n "${COLOR_DARK}"
        ls -l -D "%Y/%m/%d %H:%M" /dev/da* \
	  | grep $( basename $I ) \
	  | tail -1 \
	  | awk '{ printf("  %-10s  %-5s  %-s\n",$7,$8,$9); }'
      done
  }

# CHECK IF ANY DEVICES EXIST
ls /dev/da? 1> /dev/null 2> /dev/null || exit 0

# LIST DEVICES
case ${1} in

  (-c|--conky)
    __head
    __body
    ;;

  (-p|--plain)
    COLOR_LIGHT=""
    COLOR_DARK=""
    __head
    __body
    ;;

  (*)
    __usage
    ;;

esac

For purpose of {auto,manual}}mounting we can use ZENITY.

[*] test what tuning variables work magic for the desktop user, and create scripts to robot the actions
Click to expand...

I use these day to day:

/etc/sysctl.conf

Code: 
# increase interactiveness
kern.sched.preempt_thresh=224

# disable coredumps
kern.coredump=0

# disable system bell
hw.syscons.bell=0

# usermount
vfs.usermount=1

/boot/loader.conf

Code: 
# BOOT OPTIONS
autoboot_delay=1
beastie_disable=YES

# MODULES
ahci_load=YES
aio_load=YES
coretemp_load=YES

# firefox HTML5 fix
sem_load=YES

# pipe KVA limit | 320 MB
kern.ipc.maxpipekva=335544320

# maximum number of open files
kern.maxfiles=16384

# number of segments per process
kern.ipc.shmseg=256

# large page mappings
vm.pmap.pg_ps_enabled=1
 
# page share factor per proc
vm.pmap.shpgperproc=512

# avoid additional 128 interrupts per second per core
hint.atrtc.0.clock=0

# power off devices without attached driver
hw.pci.do_power_nodriver=3

# ahci power management
hint.ahcich.0.pm_level=5
hint.ahcich.1.pm_level=5
hint.ahcich.2.pm_level=5
hint.ahcich.3.pm_level=5

# reduce sound generated interrupts
hint.pcm.0.buffersize=65536
hint.pcm.1.buffersize=65536
hint.pcm.2.buffersize=65536
hw.snd.feeder_buffersize=65536
hw.snd.latency=7

[*] create a suite of cron scripts that go about the system with the sole purpose of making the user happy
Click to expand...

I currently use these:

Code: 
% [B]crontab -l[/B]
0     */2   * * * /bin/rm -r -f ~/.local/share/Trash
*/15  *     * * * /bin/rm -r -f ~/.adobe
0     *     * * * /bin/rm -r -f ~/.cache
*/15  *     * * * /bin/rm -r -f ~/.thumbnails
50    */2   * * * /usr/bin/find / -name Thumbs.db -type f -exec /bin/rm -f -r {} ';' 1> /dev/null 2> /dev/null

[*] do minor polishing work on popular ports, such as installing the Adobe Flash plugin, and its "linuxulated" dependencies; scripts will automate the majority of the work
Click to expand...

Here:

Code: 
#! /bin/sh
echo 'linux_enable=YES' >> /etc/rc.conf
pkg_add -r linux_base-f10
pkg_add -r nspluginwrapper
pkg_add -r firefox35
pkg_add -r linux-f10-nspr
pkg_add -r linux-f10-sqlite3
pkg_add -r linux-f10-curl
pkg_add -r linux-f10-libssh2
pkg_add -r linux-f10-nss\
cd /usr/ports/www/linux-f10-flashplugin10 && make install clean
nspluginwrapper -v -i $( find / -name libflashplayer.so )

What do y'all think?
Click to expand...

Beam Me Up, Scotty!
 
Well I just created a SourceForge account. I recommend those interested in this project to get accounts on there because that is where most of the interaction and work is going to be done. The first item in the project that I want to do is to create a script that enters and properly sets up certain packages. For example, the Linux emulation port emulators/linux_base-f10 and www/linux-f8-flashplugin10/ both require command line work; a directory is required to be created and a symlink to that directory needs to be created, and the nspluginwrapper needs to be run to install the Flash plugin for each user. The keystrokes are going to be the same for the majority of people using Flash on FreeBSD, so I think we would benefit from creating a script to do tasks similar to those. The first script I do will automate the Flash install. Other packages in the system also require a "finishing touch."

Vermaden I'll look at that stuff tomorrow. I'm fixing for the bed right now.
 
vermaden said:
# reduce sound generated interrupts
hint.pcm.0.buffersize=65536
hint.pcm.1.buffersize=65536
hint.pcm.2.buffersize=65536
hw.snd.latency=7
Click to expand...
A gamer or a musician may disagree about increasing latency.
vermaden said:
hw.snd.feeder_buffersize=65536
Click to expand...
The sysctl is not present on every 8.x system and above, cf. r193640.

You can also try vm.idlezero_enable, see recent discussion.
 
dandelion said:
A gamer or a musician may disagree about increasing latency.The sysctl is not present on every 8.x system and above, cf. r193640.

I used these settings as they should increase battery life on laptops, havent noticed any difference in sound but maybe someone will.

You can also try vm.idlezero_enable, see recent discussion.
Click to expand...

Thanks I will check that.
 
Well, this is all good. I modified some of my sysctl variables to what you said. The next steps are setting ourselves up on Source Forge and deciding on our first project right? I'll be tutored up on SF by the end of today. Tomorrow, we start deliberation on our first project. Suggestions for a new project for beautification/creature comforts?
 
Addendum to my post above; maybe not desktop related; I've long had postgresql installed (used by openfts, prosearch, and other ports), but scant experience establishing/administering the databases (vague recollection of pkg-message actions)... and am still uncomprehensive about db locations, some command-line tool that will act/show/analyze all pg8 databases installed, etc. Not a priority here, but a flowchart for that purpose may be useful for persons wanting to establish FreeBSD as a server...
.............edit...
flowchart-cups.ps...
 
You must log in or register to reply here.
Back
Top