Language Selection

English French German Italian Portuguese Spanish

Better than Zoom: Try these free software tools for staying in touch

Filed under

The COVID-19 pandemic has caused an enormous amount of changes in how people work, play, and communicate. By now, many of us have settled into the routine of using remote communication or video conferencing tools to keep in touch with our friends and family. In the last few weeks we've also seen a number of lists and guides aiming to get people set up with the "right" tools for communicating in hard times, but in almost every case, these articles recommend that people make a difficult compromise: trading their freedom in order to communicate with the people they care about and work with.

In times like these it becomes all the more important to remember that tools like Zoom, Slack, and Facebook Messenger are not benign public services, and while the sentiment they've expressed to the global community in responding to the crisis may be sincere, it hasn't addressed the fundamental ethical issues with any piece of proprietary software.

After taking the LibrePlanet 2020 conference online, we received a number of requests asking us to document our streaming setup. As the pandemic grew worse, this gave way to more curiosity about how the Free Software Foundation (FSF) uses free tools and free communication platforms to conduct our everyday business. And while the stereotype of hackers hunched over a white on black terminal session applies to us in some ways, many of the tools we use are available in any environment, even for people who do not have a lot of technical experience. We've started documenting ethical solutions on the LibrePlanet wiki, in addition to starting a remote communication mailing list to help each other advocate for their use.

In the suggestions that follow, a few of the tools we will recommend depend upon some "self-reliance," that is, steering clear of proprietary network services by hosting free software solutions yourself, or asking a technical friend to do it for you. It's a difficult step, and the benefits may not be immediately obvious, but it's a key part of preserving your autonomy in an age of ubiquitous digital control.

Read more

More in Tux Machines

Security Leftovers

Kernel: Reiser4 and Generic USB Display Driver

  • Reiser4 Updated For Linux 5.6 Kernel Support

    While the Linux 5.7 kernel is likely being released as stable today, the Reiser4 port to the Linux 5.6 kernel is out this weekend. Edward Shishkin continues working on Reiser4 while also spearheading work on the new Reiser4 file-system iteration of the Reiser file-system legacy. Taking a break from that Reiser5 feature work, Shishkin has updated the out-of-tree Reiser4 patches for Linux 5.6.0 compatibility. This weekend on SourceForge he uploaded the Reiser4 patch for upstream Linux 5.6.0 usage. This is just porting the existing 5.5.5-targeted code to the 5.6 code-base with no mention of any other bug fixes or improvements to Reiser4 in this latest patch.

  • The Generic USB Display Driver Taking Shape For Linux 5.9~5.10

    One of the interesting new happenings in the Direct Rendering Manager (DRM) driver space is a Generic USB Display stack including a USB gadget driver that together allow for some interesting generic USB display setups. This work was motivated by being able to turn a $5 Raspberry Pi Zero into a USB to HDMI display adapter.

Games: Project Cars 2 and Valve/Vulkan

  • Project Cars 2 | Linux Gaming | Ubuntu 19.10 | Steam Play

    Project Cars 2 running through Steam Play on Linux. Using my Logitech G29 which also worked as expected.

  • Valve continues to improve Linux Vulkan Shader Pre-Caching

    Recently we wrote about a new feature for Linux in the Steam Client Beta, where Steam can now sort out Vulkan shaders before running a game. With the latest build, it gets better. The idea of it, as a brief reminder, is to prepare all the shaders needed for Vulkan games while you download and / or before you hit Play. This would help to stop constant stuttering seen in some games on Linux, mostly from running Windows games in the Proton compatibility layer, as native / supported Linux games would usually do it themselves. Just another way Valve are trying to get Linux gaming on Steam in all forms into tip-top shape.

  • Steam Ironing Out Shader Pre-Caching For Helping Game Load Times, Stuttering

    Valve developers have been working on Vulkan shader pre-caching with their latest Steam client betas to help in allowing Vulkan/SPIR-V shaders to compile ahead of time, letting them be pre-cached on disk to allow for quicker game load times and any stuttering for games that otherwise would be compiling the shaders on-demand during gameplay, especially under Steam Play.

FreeBSD 11.4-RC2 Now Available

Hash: SHA256

The second RC build of the 11.4-RELEASE release cycle is now available.

Installation images are available for:

o 11.4-RC2 amd64 GENERIC
o 11.4-RC2 i386 GENERIC
o 11.4-RC2 powerpc GENERIC
o 11.4-RC2 powerpc64 GENERIC64
o 11.4-RC2 sparc64 GENERIC
o 11.4-RC2 armv6 BANANAPI
o 11.4-RC2 armv6 BEAGLEBONE
o 11.4-RC2 armv6 CUBIEBOARD
o 11.4-RC2 armv6 CUBIEBOARD2
o 11.4-RC2 armv6 RPI-B
o 11.4-RC2 armv6 RPI2
o 11.4-RC2 armv6 WANDBOARD
o 11.4-RC2 aarch64 GENERIC

Note regarding arm SD card images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the

Installer images and memory stick images are available here:

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use SVN to do a source based update of an existing
system, use the "releng/11.4" branch.

A summary of changes since 11.4-RC1 includes:

o The wpa_supplicant.conf(5) file has been fixed in bsdinstall(8).

o An update to the leap-seconds file.

o An update to mlx5_core to add new port module event types to decode.

o SCTP fixes.

o LLVM config headers have been fixed to correctly add zlib support.

o The ena(4) driver has been updated to version 2.2.0.

o loader(8) fixes for userboot.

o Fixes for compliance with RFC3168.

o A ps(1) update to permit the '-d' and '-p' flags to be used mutually.

o A knob to flush RSB on context switches if the machine has SMEP has
  been added.

o A fix to Vagrant images requiring the shells/bash port.

A list of changes since 11.3-RELEASE is available in the releng/11.4
release notes:

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 11.4-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

The partition layout is:

    ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
    ~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
    ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

To boot the VM image, run:

    % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
	-bios QEMU_EFI.fd -serial telnet::4444,server -nographic \
	-drive if=none,file=VMDISK,id=hd0 \
	-device virtio-blk-device,drive=hd0 \
	-device virtio-net-device,netdev=net0 \
	-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  eu-north-1 region: ami-0e03245dc3ecc5d35
  ap-south-1 region: ami-0100269e4d1a56492
  eu-west-3 region: ami-04d69369363a0d91f
  eu-west-2 region: ami-054fee32718b85ae0
  eu-west-1 region: ami-0b4ed21ce2fcffb67
  ap-northeast-2 region: ami-0ab69ea831245c032
  ap-northeast-1 region: ami-014ed1c7002845dae
  sa-east-1 region: ami-0779883a279143da5
  ca-central-1 region: ami-03526c4e41fbc5c0c
  ap-southeast-1 region: ami-0a1526319c431a535
  ap-southeast-2 region: ami-07b5f0fabb533a3ca
  eu-central-1 region: ami-0538d62ee3be9f769
  us-east-1 region: ami-059d76ab6e6e4063a
  us-east-2 region: ami-0c46e32a6eb527e29
  us-west-1 region: ami-0d46479f45e84d1f2
  us-west-2 region: ami-04d001870b4236742

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can
be installed by running:

    % vagrant init freebsd/FreeBSD-11.4-RC2
    % vagrant up

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64 and i386
systems running earlier FreeBSD releases.  Systems running earlier
FreeBSD releases can upgrade as follows:

	# freebsd-update upgrade -r 11.4-RC2

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

	# freebsd-update install

The system must be rebooted with the newly installed kernel before

	# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

	# freebsd-update install

It is recommended to rebuild and install all applications if possible,
especially if upgrading from an earlier FreeBSD release, for example,
FreeBSD 11.x.  Alternatively, the user can install misc/compat11x and
other compatibility libraries, afterwards the system must be rebooted
into the new userland:

	# shutdown -r now

Finally, after rebooting, freebsd-update needs to be run again to remove
stale files:

	# freebsd-update install
Read more