Language Selection

English French German Italian Portuguese Spanish

DesktopBSD: A Step Towards BSD on the Desktop

Filed under

DesktopBSD is a custom FreeBSD-based desktop focussed on stability, usability and simplicity. In developing an easy to use desktop operating system, DesktopBSD has chosen to use KDE. Screenshots showing the desktop tools in action are available.

Their website FAQ further explains the choice of KDE:

"KDE is easy to work with and has many useful features and well-integrated components such as the PIM package (Personal Information Manager). Additionally, KDE is probably easier for people that used Windows before, but this is rather a nice side-effect than a main reason for this choice."

"Of course, there are other great desktop environments out there that are in some ways superior to KDE, but we decided to use only KDE so we can have better support for that one and have better integration of the DesktopBSD Tools with that environment."

The Dot.

More in Tux Machines

Open Hardware

  • AArch64 desktop hardware?
    Soon there will be four years since I started working on AArch64 architecture. Lot of software things changed during that time. Lot in a hardware too. But machines availability still sucks badly. In 2012 all we had was software model. It was slow, terribly slow. Common joke was AArch64 developers standing in a queue for 10GHz x86-64 cpus. So I was generating working binaries by using cross compilation. But many distributions only do native builds. In models. Imagine Qt4 building for 3-4 days… In 2013 I got access to first server hardware. With first silicon version of CPU. Highly unstable, we could use just one core etc. GCC was crashing like hell but we managed to get stable build results from it. Qt4 was building in few hours now.
  • RISC-V on an FPGA, pt. 1
    Last year I had open source instruction set RISC-V running Linux emulated in qemu. However to really get into the architecture, and restore my very rusty FPGA skills, wouldn’t it be fun to have RISC-V working in real hardware. The world of RISC-V is pretty confusing for outsiders. There are a bunch of affiliated companies, researchers who are producing actual silicon (nothing you can buy of course), and the affiliated(?) lowRISC project which is trying to produce a fully open source chip. I’m starting with lowRISC since they have three iterations of a design that you can install on reasonably cheap FPGA development boards like the one above. (I’m going to try to install “Untether 0.2” which is the second iteration of their FPGA design.)
  • RISC-V on an FPGA, pt. 2
  • RISC-V on an FPGA, pt. 3
  • RISC-V on an FPGA, pt. 4
  • RISC-V on an FPGA, pt. 5

Security Leftovers

  • Tuesday's security updates
  • Oops: Bounty-hunter found Vine's source code in plain sight
    A bounty-hunter has gone public with a complete howler made by Vine, the six-second-video-loop app Twitter acquired in 2012. According to this post by @avicoder (Vjex at GitHub), Vine's source code was for a while available on what was supposed to be a private Docker registry. While, hosted at Amazon, wasn't meant to be available, @avicoder found he was able to download images with a simple pull request.
  • US standards lab says SMS is no good for authentication
    America's National Institute for Standards and Technology has advised abandonment of SMS-based two-factor authentication. That's the gist of the latest draft of its Digital Authentication Guideline, here. Down in section, the document says out-of-band verification using SMS is deprecated and won't appear in future releases of NIST's guidance.

Android Leftovers

today's howtos