Jupiter Broadcasting

To hier is UNIX | BSD Now 206

chris

RSS Feeds:

MP3 Feed | iTunes Feed | HD Vid Feed | HD Torrent Feed

Become a supporter on Patreon:

– Show Notes: –

Headlines

Lumina Desktop v1.3 released

FreeBSD 11.0 and Plasma 5 HowTo

Here’s a step-by-step guide to getting a machine with FreeBSD 11 in it, running X, and KDE Plasma 5 Desktop and KDE Applications. It’s the latest thing! (Except that 11-STABLE is in the middle of the pack of what’s supported .. but the KDE bits are fresh. I run 10.3 with KDE4 or Plasma 5 on my physical machines, myself, so the FreeBSD version isn’t that important except that packages are readily available for 11-STABLE, not for 10-STABLE.)

pkg install xorg xterm twm

pkg install hal dbus
echo hald_enable=YES >> /etc/rc.conf
echo dbus_enable=YES >> /etc/rc.conf

If running with ZFS, it’s a good idea to snapshot now, just so you can easily roll back to the it-works-with-basic-X11 setup you have now.
zfs snapshot -r zroot@x11

mkdir -p /usr/local/etc/pkg/repos
cd /usr/local/etc/pkg/repos
cat > FreeBSD.conf < Area51.conf <<EOF
Area51: {
url: “https://meatwad.mouf.net/rubick/poudriere/packages/110-amd64-kde/”,
priority: 2,
enabled: yes
}
EOF

pkg update
pkg install konsole plasma5-plasma-desktop
echo cuse_load=YES >> /boot/loader.conf
echo webcamd_enable=YES >> /etc/rc.conf

cat > .xinitrc <<EOF

#! /bin/sh

/usr/local/bin/xterm -geometry +0+0 &
KDE=/usr/local/bin/startkde
test -x $KDE && exec /usr/local/bin/ck-launch-session $KDE
exec /usr/local/bin/twm
EOF
chmod 755 .xinitrc

pkg install kde

Full FreeBSD Server on a Raspberry Pi

News Roundup

HardenedBSD, now has openntpd in base

Unix: How random is random

On Unix systems, random numbers are generated in a number of ways and random data can serve many purposes. From simple commands to fairly complex processes, the question “How random is random?” is worth asking.
EZ random numbers
If all you need is a casual list of random numbers, the RANDOM variable is an easy choice. Type “echo $RANDOM” and you’ll get a number between 0 and 32,767 (the largest number that two bytes can hold).

Of course, this process is actually providing a “pseudo-random” number. As anyone who thinks about random numbers very often might tell you, numbers generated by a program have a limitation. Programs follow carefully crafted steps, and those steps aren’t even close to being truly random. You can increase the randomness of RANDOM’s value by seeding it (i.e., setting the variable to some initial value). Some just use the current process ID (via $$) for that. Note that for any particular starting point, the subsequent values that $RANDOM provides are quite predictable.

For more serious requirements for random data, such as its use in encryption, some more truly random data comes into play. The /dev/random and /dev/urandom files get beyond the predictability of programming by making use of environmental noise gathered from device drivers and other system sources and stored it in an “entropy pool”.

Moving firmware to userland

I would like to introduce a few ideas about the new firmware subsystem. I assume that it should not require adding a new system tools or modifying boot process.
Simplification is the first. It would be good to remove parent-child relationship and corresponding functionality. It would significantly simplify firmware handling. Its only practical use is when there are multiple images in one loadable kernel module. The module can be unloaded when all children are not in use. Usage of the children images is tracked through the counter for the parent image. If images will not be placed inside loadable kernel modules, the parent-child mechanism won’t have any practical meaning. I think, currently the mechanism is not used anywhere in the DragonFly system and if it was, it could be easily replaced by putting every child image in its own module without modifying drivers.
There are two use cases according to who will provide firmware images to the system:

– developers of DragonFly BSD (they can modify and rebuild the system)
– third-parties (they should not be required to modify and rebuild the system)

All firmware images needs to have some information attached (at least, if ack with a license is needed) which should be d) stored persistently.

The question is where to save the information for non-built-in images.

There would be two firmware sources: kernel and filesystem. In case of the same image names, user could have a choice by setting a kernel environment variable, firmware from which source has higher priority and will be provided to consumer.

OpenBSD changes of note 625

Beastie Bits

Feedback/Questions