Podcasts about kde4

Follow-up about FreeBSD jail advantages, Install Prometheus, Node Exporter and Grafana, Calibrate your touch-screen on OpenBSD, OPNsense 21.1 Marvelous Meerkat Released, NomadBSD 1.4-RC1, Lets all shed a Tear for 386, find mostly doesn't need xargs today on modern Unixes, OpenBSD KDE Status Report, and more. NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/bsdnow) Headlines Follow-up about FreeBSD jail advantages (https://rubenerd.com/follow-up-about-freebsd-jail-advantages/) I’ll admit I ran a lot of justifications together into a single paragraph because I wanted to get to configuring the jails themselves. They’re also, by and large, not specific to FreeBSD’s flavour of containerisation, though I still think it’s easily the most elegant implementation. Sometimes the simplest solution really is the best one. History of FreeBSD part 4: TCP/IP (https://klarasystems.com/articles/history-of-freebsd-part-4-bsd-and-tcp-ip/) How TCP/IP evolved and BSDs special contribution to the history of the Internet *** FreeBSD: Install Prometheus, Node Exporter and Grafana (https://blog.andreev.it/?p=5289) FreeBSD comes out of the box with three great tools for monitoring. If you need more info about how these tools work, please read the official documentation. I’ll explain the installation only and creating a simple dashboard. News Roundup Calibrate your touch-screen on OpenBSD (https://www.tumfatig.net/20210122/calibrate-your-touch-screen-on-openbsd/) I didn’t expected it but my refurbished T460s came with a touch-screen. It is recognized by default on OpenBSD and not well calibrated as-is. But that’s really simple to solve. Lets all shed a Tear for 386 (https://lists.freebsd.org/pipermail/freebsd-announce/2021-January/002006.html) FreeBSD is designating i386 as a Tier 2 architecture starting with FreeBSD 13.0. The Project will continue to provide release images, binary updates, and pre-built packages for the 13.x branch. However, i386-specific issues (including SAs) may not be addressed in 13.x. The i386 platform will remain Tier 1 on FreeBSD 11.x and 12.x. OPNsense 21.1 Marvelous Meerkat Released (https://opnsense.org/opnsense-21-1-marvelous-meerkat-released/) For more than 6 years, OPNsense is driving innovation through modularising and hardening the open source firewall, with simple and reliable firmware upgrades, multi-language support, HardenedBSD security, fast adoption of upstream software updates as well as clear and stable 2-Clause BSD licensing. NomadBSD 1.4-RC1 (https://nomadbsd.org/index.html#1.4-RC1) We are pleased to present the first release candidate of NomadBSD 1.4. find mostly doesn't need xargs today on modern Unixes (https://utcc.utoronto.ca/~cks/space/blog/unix/FindWithoutXargsToday) I've been using Unix for long enough that 'find | xargs' is a reflex. When I started and for a long time afterward, xargs was your only choice for efficiently executing a command over a bunch of find results. OpenBSD KDE Status Report (https://undeadly.org/cgi?action=article;sid=20210124113220) OpenBSD has managed to drop KDE3 and KDE4 in the 6.8 -> 6.9 release cycle. That makes me very happy because it was a big piece of work and long discussions. This of course brings questions: Kde Plasma 5 package missing. After half a year of work, I managed to successfully update the Qt5 stack to the last LTS version 5.15.2. On the whole, the most work was updating QtWebengine. What a monster! With my CPU power at home, I can build it 1-2 times a day which makes testing a little bit annoying and time intensive. Tarsnap This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Feedback/Questions Karl - Firefox webcam audio solution (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/391/feedback/Karl%20-%20Firefox%20webcam%20audio%20solution.md) Michal - openzfs (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/391/feedback/Michal%20-%20openzfs.md) Dave - bufferbloat (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/391/feedback/Dave%20-%20bufferbloat.md) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) ***

6 metrics for zpool performance, 2FA with ssh on OpenBSD, ZFS maintaining file type information in dirs, everything old is new again, netcat demystified, and more. ##Headlines Six Metrics for Measuring ZFS Pool Performance Part 1 The layout of a ZFS storage pool has a significant impact on system performance under various workloads. Given the importance of picking the right configuration for your workload and the fact that making changes to an in-use ZFS pool is far from trivial, it is important for an administrator to understand the mechanics of pool performance when designing a storage system. To quantify pool performance, we will consider six primary metrics: Read I/O operations per second (IOPS) Write IOPS Streaming read speed Streaming write speed Storage space efficiency (usable capacity after parity versus total raw capacity) Fault tolerance (maximum number of drives that can fail before data loss) For the sake of comparison, we’ll use an example system with 12 drives, each one sized at 6TB, and say that each drive does 100MB/s streaming reads and writes and can do 250 read and write IOPS. We will visualize how the data is spread across the drives by writing 12 multi-colored blocks, shown below. The blocks are written to the pool starting with the brown block on the left (number one), and working our way to the pink block on the right (number 12). Note that when we calculate data rates and IOPS values for the example system, they are only approximations. Many other factors can impact pool access speeds for better (compression, caching) or worse (poor CPU performance, not enough memory). There is no single configuration that maximizes all six metrics. Like so many things in life, our objective is to find an appropriate balance of the metrics to match a target workload. For example, a cold-storage backup system will likely want a pool configuration that emphasizes usable storage space and fault tolerance over the other data-rate focused metrics. Let’s start with a quick review of ZFS storage pools before diving into specific configuration options. ZFS storage pools are comprised of one or more virtual devices, or vdevs. Each vdev is comprised of one or more storage providers, typically physical hard disks. All disk-level redundancy is configured at the vdev level. That is, the RAID layout is set on each vdev as opposed to on the storage pool. Data written to the storage pool is then striped across all the vdevs. Because pool data is striped across the vdevs, the loss of any one vdev means total pool failure. This is perhaps the single most important fact to keep in mind when designing a ZFS storage system. We will circle back to this point in the next post, but keep it in mind as we go through the vdev configuration options. Because storage pools are made up of one or more vdevs with the pool data striped over the top, we’ll take a look at pool configuration in terms of various vdev configurations. There are three basic vdev configurations: striping, mirroring, and RAIDZ (which itself has three different varieties). The first section will cover striped and mirrored vdevs in this post; the second post will cover RAIDZ and some example scenarios. A striped vdev is the simplest configuration. Each vdev consists of a single disk with no redundancy. When several of these single-disk, striped vdevs are combined into a single storage pool, the total usable storage space would be the sum of all the drives. When you write data to a pool made of striped vdevs, the data is broken into small chunks called “blocks” and distributed across all the disks in the pool. The blocks are written in “round-robin” sequence, meaning after all the disks receive one row of blocks, called a stripe, it loops back around and writes another stripe under the first. A striped pool has excellent performance and storage space efficiency, but absolutely zero fault tolerance. If even a single drive in the pool fails, the entire pool will fail and all data stored on that pool will be lost. The excellent performance of a striped pool comes from the fact that all of the disks can work independently for all read and write operations. If you have a bunch of small read or write operations (IOPS), each disk can work independently to fetch the next block. For streaming reads and writes, each disk can fetch the next block in line synchronized with its neighbors. For example, if a given disk is fetching block n, its neighbor to the left can be fetching block n-1, and its neighbor to the right can be fetching block n+1. Therefore, the speed of all read and write operations as well as the quantity of read and write operations (IOPS) on a striped pool will scale with the number of vdevs. Note here that I said the speeds and IOPS scale with the number of vdevs rather than the number of drives; there’s a reason for this and we’ll cover it in the next post when we discuss RAID-Z. Here’s a summary of the total pool performance (where N is the number of disks in the pool): N-wide striped: Read IOPS: N * Read IOPS of a single drive Write IOPS: N * Write IOPS of a single drive Streaming read speed: N * Streaming read speed of a single drive Streaming write speed: N * Streaming write speed of a single drive Storage space efficiency: 100% Fault tolerance: None! Let’s apply this to our example system, configured with a 12-wide striped pool: 12-wide striped: Read IOPS: 3000 Write IOPS: 3000 Streaming read speed: 1200 MB/s Streaming write speed: 1200 MB/s Storage space efficiency: 72 TB Fault tolerance: None! Below is a visual depiction of our 12 rainbow blocks written to this pool configuration: The blocks are simply striped across the 12 disks in the pool. The LBA column on the left stands for “Logical Block Address”. If we treat each disk as a column in an array, each LBA would be a row. It’s also easy to see that if any single disk fails, we would be missing a color in the rainbow and our data would be incomplete. While this configuration has fantastic read and write speeds and can handle a ton of IOPS, the data stored on the pool is very vulnerable. This configuration is not recommended unless you’re comfortable losing all of your pool’s data whenever any single drive fails. A mirrored vdev consists of two or more disks. A mirrored vdev stores an exact copy of all the data written to it on each one of its drives. Traditional RAID-1 mirrors usually only support two drive mirrors, but ZFS allows for more drives per mirror to increase redundancy and fault tolerance. All disks in a mirrored vdev have to fail for the vdev, and thus the whole pool, to fail. Total storage space will be equal to the size of a single drive in the vdev. If you’re using mismatched drive sizes in your mirrors, the total size will be that of the smallest drive in the mirror. Streaming read speeds and read IOPS on a mirrored vdev will be faster than write speeds and IOPS. When reading from a mirrored vdev, the drives can “divide and conquer” the operations, similar to what we saw above in the striped pool. This is because each drive in the mirror has an identical copy of the data. For write operations, all of the drives need to write a copy of the data, so the mirrored vdev will be limited to the streaming write speed and IOPS of a single disk. Here’s a summary: N-way mirror: Read IOPS: N * Read IOPS of a single drive Write IOPS: Write IOPS of a single drive Streaming read speed: N * Streaming read speed of a single drive Streaming write speed: Streaming write speed of a single drive Storage space efficiency: 50% for 2-way, 33% for 3-way, 25% for 4-way, etc. [(N-1)/N] Fault tolerance: 1 disk per vdev for 2-way, 2 for 3-way, 3 for 4-way, etc. [N-1] For our first example configuration, let’s do something ridiculous and create a 12-way mirror. ZFS supports this kind of thing, but your management probably will not. 1x 12-way mirror: Read IOPS: 3000 Write IOPS: 250 Streaming read speed: 1200 MB/s Streaming write speed: 100 MB/s Storage space efficiency: 8.3% (6 TB) Fault tolerance: 11 As we can clearly see from the diagram, every single disk in the vdev gets a full copy of our rainbow data. The chainlink icons between the disk labels in the column headers indicate the disks are part of a single vdev. We can lose up to 11 disks in this vdev and still have a complete rainbow. Of course, the data takes up far too much room on the pool, occupying a full 12 LBAs in the data array. Obviously, this is far from the best use of 12 drives. Let’s do something a little more practical and configure the pool with the ZFS equivalent of RAID-10. We’ll configure six 2-way mirror vdevs. ZFS will stripe the data across all 6 of the vdevs. We can use the work we did in the striped vdev section to determine how the pool as a whole will behave. Let’s first calculate the performance per vdev, then we can work on the full pool: 1x 2-way mirror: Read IOPS: 500 Write IOPS: 250 Streaming read speed: 200 MB/s Streaming write speed: 100 MB/s Storage space efficiency: 50% (6 TB) Fault tolerance: 1 Now we can pretend we have 6 drives with the performance statistics listed above and run them through our striped vdev performance calculator to get the total pool’s performance: 6x 2-way mirror: Read IOPS: 3000 Write IOPS: 1500 Streaming read speed: 3000 MB/s Streaming write speed: 1500 MB/s Storage space efficiency: 50% (36 TB) Fault tolerance: 1 per vdev, 6 total Again, we will examine the configuration from a visual perspective: Each vdev gets a block of data and ZFS writes that data to all of (or in this case, both of) the disks in the mirror. As long as we have at least one functional disk in each vdev, we can retrieve our rainbow. As before, the chain link icons denote the disks are part of a single vdev. This configuration emphasizes performance over raw capacity but doesn’t totally disregard fault tolerance as our striped pool did. It’s a very popular configuration for systems that need a lot of fast I/O. Let’s look at one more example configuration using four 3-way mirrors. We’ll skip the individual vdev performance calculation and go straight to the full pool: 4x 3-way mirror: Read IOPS: 3000 Write IOPS: 1000 Streaming read speed: 3000 MB/s Streaming write speed: 400 MB/s Storage space efficiency: 33% (24 TB) Fault tolerance: 2 per vdev, 8 total While we have sacrificed some write performance and capacity, the pool is now extremely fault tolerant. This configuration is probably not practical for most applications and it would make more sense to use lower fault tolerance and set up an offsite backup system. Striped and mirrored vdevs are fantastic for access speed performance, but they either leave you with no redundancy whatsoever or impose at least a 50% penalty on the total usable space of your pool. In the next post, we will cover RAIDZ, which lets you keep data redundancy without sacrificing as much storage space efficiency. We’ll also look at some example workload scenarios and decide which layout would be the best fit for each. ###2FA with ssh on OpenBSD Five years ago I wrote about using a yubikey on OpenBSD. The only problem with doing this is that there’s no validation server available on OpenBSD, so you need to use a different OTP slot for each machine. (You don’t want to risk a replay attack if someone succeeds in capturing an OTP on one machine, right?) Yubikey has two OTP slots per device, so you would need a yubikey for every two machines with which you’d like to use it. You could use a bastion—and use only one yubikey—but I don’t like the SPOF aspect of a bastion. YMMV. After I played with TOTP, I wanted to use them as a 2FA for ssh. At the time of writing, we can’t do that using only the tools in base. This article focuses on OpenBSD; if you use another operating system, here are two handy links. SEED CONFIGURATION The first thing we need to do is to install the software which will be used to verify the OTPs we submit. # pkgadd loginoath We need to create a secret - aka, the seed - that will be used to calculate the Time-based One-Time Passwords. We should make sure no one can read or change it. $ openssl rand -hex 20 > ~/.totp-key $ chmod 400 ~/.totp-key Now we have a hexadecimal key, but apps usually want a base32 secret. I initially wrote a small script to do the conversion. While writing this article, I took the opportunity to improve it. When I initially wrote this utility for my use, python-qrcode hadn’t yet been imported to the OpenBSD ports/packages system. It’s easy to install now, so let’s use it. Here’s the improved version. It will ask for the hex key and output the secret as a base32-encoded string, both with and without spacing so you can copy-paste it into your password manager or easily retype it. It will then ask for the information needed to generate a QR code. Adding our new OTP secret to any mobile app using the QR code will be super easy! SYSTEM CONFIGURATION We can now move to the configuration of the system to put our new TOTP to use. As you might guess, it’s going to be quite close to what we did with the yubikey. We need to tweak login.conf. Be careful and keep a root shell open at all times. The few times I broke my OpenBSD were because I messed with login.conf without showing enough care. SSHD CONFIGURATION Again, keeping a root shell around decreases the risk of losing access to the system and being locked outside. A good standard is to use PasswordAuthentication no and to use public key only. Except… have a guess what the P stands for in TOTP. Yes, congrats, you guessed it! We need to switch to PasswordAuthentication yes. However, if we made this change alone, sshd would then accept a public key OR a password (which are TOTP because of our login.conf). 2FA uses both at the same time. To inform sshd we intend to use both, we need to set AuthenticationMethods publickey,password. This way, the user trying to login will first need to perform the traditional publickey authentication. Once that’s done, ssh will prompt for a password and the user will need to submit a valid TOTP for the system. We could do this the other way around, but I think bots could try passwords, wasting resources. Evaluated in this order, failing to provide a public key leads to sshd immediately declining your attempt. IMPROVING SECURITY WITHOUT IMPACTING UX My phone has a long enough password that most of the time, I fail to type it correctly on the first try. Of course, if I had to unlock my phone, launch my TOTP app and use my keyboard to enter what I see on my phone’s screen, I would quickly disable 2FA. To find a balance, I have whitelisted certain IP addresses and users. If I connect from a particular IP address or as a specific user, I don’t want to go through 2FA. For some users, I might not even enable 2FA. To sum up, we covered how to create a seed, how to perform a hexadecimal to base32 conversion and how to create a QR code for mobile applications. We configured the login system with login.conf so that ssh authentication uses the TOTP login system, and we told sshd to ask for both the public key and the Time-based One-Time Password. Now you should be all set to use two-factor ssh authentication on OpenBSD! ##News Roundup How ZFS maintains file type information in directories As an aside in yesterday’s history of file type information being available in Unix directories, I mentioned that it was possible for a filesystem to support this even though its Unix didn’t. By supporting it, I mean that the filesystem maintains this information in its on disk format for directories, even though the rest of the kernel will never ask for it. This is what ZFS does. The easiest way to see that ZFS does this is to use zdb to dump a directory. I’m going to do this on an OmniOS machine, to make it more convincing, and it turns out that this has some interesting results. Since this is OmniOS, we don’t have the convenience of just naming a directory in zdb, so let’s find the root directory of a filesystem, starting from dnode 1 (as seen before). # zdb -dddd fs3-corestaff-01/h/281 1 Dataset [....] [...] microzap: 512 bytes, 4 entries [...] ROOT = 3 # zdb -dddd fs3-corestaff-01/h/281 3 Object lvl iblk dblk dsize lsize %full type 3 1 16K 1K 8K 1K 100.00 ZFS directory [...] microzap: 1024 bytes, 8 entries RESTORED = 4396504 (type: Directory) ckstst = 12017 (type: not specified) ckstst3 = 25069 (type: Directory) .demo-file = 5832188 (type: Regular File) .peergroup = 12590 (type: not specified) cks = 5 (type: not specified) cksimap1 = 5247832 (type: Directory) .diskuse = 12016 (type: not specified) ckstst2 = 12535 (type: not specified) This is actually an old filesystem (it dates from Solaris 10 and has been transferred around with ‘zfs send | zfs recv’ since then), but various home directories for real and test users have been created in it over time (you can probably guess which one is the oldest one). Sufficiently old directories and files have no file type information, but more recent ones have this information, including .demo-file, which I made just now so this would have an entry that was a regular file with type information. Once I dug into it, this turned out to be a change introduced (or activated) in ZFS filesystem version 2, which is described in ‘zfs upgrade -v’ as ‘enhanced directory entries’. As an actual change in (Open)Solaris, it dates from mid 2007, although I’m not sure what Solaris release it made it into. The upshot is that if you made your ZFS filesystem any time in the last decade, you’ll have this file type information in your directories. How ZFS stores this file type information is interesting and clever, especially when it comes to backwards compatibility. I’ll start by quoting the comment from zfs_znode.h: /* * The directory entry has the type (currently unused on * Solaris) in the top 4 bits, and the object number in * the low 48 bits. The "middle" 12 bits are unused. */ In yesterday’s entry I said that Unix directory entries need to store at least the filename and the inode number of the file. What ZFS is doing here is reusing the 64 bit field used for the ‘inode’ (the ZFS dnode number) to also store the file type, because it knows that object numbers have only a limited range. This also makes old directory entries compatible, by making type 0 (all 4 bits 0) mean ‘not specified’. Since old directory entries only stored the object number and the object number is 48 bits or less, the higher bits are guaranteed to be all zero. The reason this needed a new ZFS filesystem version is now clear. If you tried to read directory entries with file type information on a version of ZFS that didn’t know about them, the old version would likely see crazy (and non-existent) object numbers and nothing would work. In order to even read a ‘file type in directory entries’ filesystem, you need to know to only look at the low 48 bits of the object number field in directory entries. ###Everything old is new again Just because KDE4-era software has been deprecated by the KDE-FreeBSD team in the official ports-repository, doesn’t mean we don’t care for it while we still need to. KDE4 was released on January 11th, 2008 — I still have the T-shirt — which was a very different C++ world than what we now live in. Much of the code pre-dates the availability of C11 — certainly the availability of compilers with C11 support. The language has changed a great deal in those ten years since the original release. The platforms we run KDE code on have, too — FreeBSD 12 is a long way from the FreeBSD 6 or 7 that were current at release (although at the time, I was more into OpenSolaris). In particular, since then the FreeBSD world has switched over to Clang, and FreeBSD current is experimenting with Clang 7. So we’re seeing KDE4-era code being built, and running, on FreeBSD 12 with Clang 7. That’s a platform with a very different idea of what constitutes correct code, than what the code was originally written for. (Not quite as big a difference as Helio’s KDE1 efforts, though) So, while we’re counting down to removing KDE4 from the FreeBSD ports tree, we’re also going through and fixing it to work with Clang 7, which defaults to a newer C++ standard and which is quite picky about some things. Some time in the distant past, when pointers were integers and NULL was zero, there was some confusion about booleans. So there’s lots of code that does list.contains(element) > 0 … this must have been a trick before booleans were a supported type in all our compilers. In any case it breaks with Clang 7, since contains() returns a QBool which converts to a nullptr (when false) which isn’t comparable to the integer 0. Suffice to say I’ve spent more time reading KDE4-era code this month, than in the past two years. However, work is proceeding apace, so if you really really want to, you can still get your old-school kicks on a new platform. Because we care about packaging things right, even when we want to get rid of it. ###OpenBSD netcat demystified Owing to its versatile functionalities, netcat earns the reputation as “TCP/IP Swiss army knife”. For example, you can create a simple chat app using netcat: (1) Open a terminal and input following command: # nc -l 3003 This means a netcat process will listen on 3003 port in this machine (the IP address of current machine is 192.168.35.176). (2) Connect aforemontioned netcat process in another machine, and send a greeting: # nc 192.168.35.176 3003 hello Then in the first machine’s terminal, you will see the “hello” text: # nc -l 3003 hello A primitive chatroom is built successfully. Very cool! Isn’t it? I think many people can’t wait to explore more features of netcatnow. If you are among them, congratulations! This tutorial may be the correct place for you. In the following parts, I will delve into OpenBSD’s netcatcode to give a detailed anatomy of it. The reason of picking OpenBSD’s netcat rather than others’ is because its code repository is small (~2000 lines of code) and neat. Furthermore, I also hope this little book can assist you learn more socket programming knowledge not just grasping usage of netcat. We’re all set. Let’s go! ##Beastie Bits What’s in store for NetBSD 9.0 NetBSD machines at Open Source Conference 2018 Hiroshima nmctl adapted with limited privileges: nmctl-0.6.0 Submit Your Work: Check out SCALE 17x and FOSDEM ’19 CFPs OpenBSD 6.4 site is up! (with a partial list of new features) Using Alpine to Read Your Email on OpenBSD ##Feedback/Questions Morgan - Send/Receive to Manage Fragmentation? Ryan - ZFS and mmap Marcus - Linux Compat Ben - Multiple Pools Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

DragonflyBSD release 5.2.1 is here, BPF kernel exploit writeup, Remote Debugging the running OpenBSD kernel, interview with Patrick Mooney, FreeBSD buildbot setup in a jail, dumping your USB, and 5 years of gaming on FreeBSD. Headlines DragonFlyBSD: release52 (w/stable HAMMER2, as default root) DragonflyBSD 5.2.1 was released on May 21, 2018 > Big Ticket items: Meltdown and Spectre mitigation support Meltdown isolation and spectre mitigation support added. Meltdown mitigation is automatically enabled for all Intel cpus. Spectre mitigation must be enabled manually via sysctl if desired, using sysctls machdep.spectremitigation and machdep.meltdownmitigation. HAMMER2 H2 has received a very large number of bug fixes and performance improvements. We can now recommend H2 as the default root filesystem in non-clustered mode. Clustered support is not yet available. ipfw Updates Implement state based "redirect", i.e. without using libalias. ipfw now supports all possible ICMP types. Fix ICMPMAXTYPE assumptions (now 40 as of this release). Improved graphics support The drm/i915 kernel driver has been updated to support Intel Coffeelake GPUs Add 24-bit pixel format support to the EFI frame buffer code. Significantly improve fbio support for the "scfb" XOrg driver. This allows EFI frame buffers to be used by X in situations where we do not otherwise support the GPU. Partly implement the FBIOBLANK ioctl for display powersaving. Syscons waits for drm modesetting at appropriate places, avoiding races. PS4 4.55 BPF Race Condition Kernel Exploit Writeup Note: While this bug is primarily interesting for exploitation on the PS4, this bug can also potentially be exploited on other unpatched platforms using FreeBSD if the attacker has read/write permissions on /dev/bpf, or if they want to escalate from root user to kernel code execution. As such, I've published it under the "FreeBSD" folder and not the "PS4" folder. Introduction Welcome to the kernel portion of the PS4 4.55FW full exploit chain write-up. This bug was found by qwerty, and is fairly unique in the way it's exploited, so I wanted to do a detailed write-up on how it worked. The full source of the exploit can be found here. I've previously covered the webkit exploit implementation for userland access here. FreeBSD or Sony's fault? Why not both... Interestingly, this bug is actually a FreeBSD bug and was not (at least directly) introduced by Sony code. While this is a FreeBSD bug however, it's not very useful for most systems because the /dev/bpf device driver is root-owned, and the permissions for it are set to 0600 (meaning owner has read/write privileges, and nobody else does) - though it can be used for escalating from root to kernel mode code execution. However, let’s take a look at the make_dev() call inside the PS4 kernel for /dev/bpf (taken from a 4.05 kernel dump). seg000:FFFFFFFFA181F15B lea rdi, unk_FFFFFFFFA2D77640 seg000:FFFFFFFFA181F162 lea r9, aBpf ; "bpf" seg000:FFFFFFFFA181F169 mov esi, 0 seg000:FFFFFFFFA181F16E mov edx, 0 seg000:FFFFFFFFA181F173 xor ecx, ecx seg000:FFFFFFFFA181F175 mov r8d, 1B6h seg000:FFFFFFFFA181F17B xor eax, eax seg000:FFFFFFFFA181F17D mov cs:qword_FFFFFFFFA34EC770, 0 seg000:FFFFFFFFA181F188 call make_dev We see UID 0 (the UID for the root user) getting moved into the register for the 3rd argument, which is the owner argument. However, the permissions bits are being set to 0x1B6, which in octal is 0666. This means anyone can open /dev/bpf with read/write privileges. I’m not sure why this is the case, qwerty speculates that perhaps bpf is used for LAN gaming. In any case, this was a poor design decision because bpf is usually considered privileged, and should not be accessible to a process that is completely untrusted, such as WebKit. On most platforms, permissions for /dev/bpf will be set to 0x180, or 0600. Race Conditions - What are they? The class of the bug abused in this exploit is known as a "race condition". Before we get into bug specifics, it's important for the reader to understand what race conditions are and how they can be an issue (especially in something like a kernel). Often in complex software (such as a kernel), resources will be shared (or "global"). This means other threads could potentially execute code that will access some resource that could be accessed by another thread at the same point in time. What happens if one thread accesses this resource while another thread does without exclusive access? Race conditions are introduced. Race conditions are defined as possible scenarios where events happen in a sequence different than the developer intended which leads to undefined behavior. In simple, single-threaded programs, this is not an issue because execution is linear. In more complex programs where code can be running in parallel however, this becomes a real issue. To prevent these problems, atomic instructions and locking mechanisms were introduced. When one thread wants to access a critical resource, it will attempt to acquire a "lock". If another thread is already using this resource, generally the thread attempting to acquire the lock will wait until the other thread is finished with it. Each thread must release the lock to the resource after they're done with it, failure to do so could result in a deadlock. While locking mechanisms such as mutexes have been introduced, developers sometimes struggle to use them properly. For example, what if a piece of shared data gets validated and processed, but while the processing of the data is locked, the validation is not? There is a window between validation and locking where that data can change, and while the developer thinks the data has been validated, it could be substituted with something malicious after it is validated, but before it is used. Parallel programming can be difficult, especially when, as a developer, you also want to factor in the fact that you don't want to put too much code in between locking and unlocking as it can impact performance. See article for the rest iXsystems Remote Debugging the running OpenBSD kernel Subtitled: A way to understand the OpenBSD internals +> The Problem +> A few month ago, I tried porting the FreeBSD kdb along with it's gdb stub implementations to OpenBSD as a practice of learning the internals of an BSD operating system. The ddb code in both FreeBSD and OpenBSD looks pretty much the same and the GDB Remote Serial Protocol looks very minimal. +> But sadly I got very busy and the work is stalled but I'm planning on resuming the attempt as soon as I get the chance, But there is an alternative way to Debugging the OpenBSD kernel via QEMU. What I did below is basically the same with a few minor changes which I hope to describe it as best. +> Installing OpenBSD on Qemu +> For debugging the kernel, we need a working OpenBSD system running on Qemu. I chose to create a raw disk file to be able to easily mount it later via the host and copy the custom kernel onto it. $ qemu-img create -f raw disk.raw 5G $ qemu-system-x8664 -m 256M -drive format=raw,file=install63.fs -drive format=raw,file=disk.raw +> Custom Kernel +> To debug the kernel, we need a version of the kernel with debugging symbols and for that we have to recompile it first. The process is documented at Building the System from Source: ... +> Then we can copy the bsd kernel to the guest machine and keep the bsd.gdb on the host to start the remote debugging via gdb. +> Remote debugging kernel +> Now it's to time to boot the guest with the new custom kernel. Remember that the -s argument enables the gdb server on qemu on localhost port 1234 by default: $ qemu-system-x8664 -m 256M -s -net nic -net user -drive format=raw,file=install63.fs +> Now to finally attach to the running kernel: Interview - Patrick Mooney - Software Engineer pmooney@pfmooney.com / @pfmooney BR: How did you first get introduced to UNIX? AJ: What got you started contributing to an open source project? BR: What sorts of things have you worked on in the past? AJ: Can you tell us more about what attracted you to illumos? BR: How did you get interested in, and started with, systems development? AJ: When did you first get interested in bhyve? BR: How much work was it to take the years-old port of bhyve and get it working on modern IllumOS? AJ: What was the process for getting the bhyve port caught up to current FreeBSD? BR: How usable is bhyve on illumOS? AJ: What area are you most interested in improving in bhyve? BR: Do you think the FreeBSD and illumos versions of bhyve will stay in sync with each other? AJ: What do you do for fun? BR: Anything else you want to mention? News Roundup Setting up buildbot in FreeBSD Jails In this article, I would like to present a tutorial to set up buildbot, a continuous integration (CI) software (like Jenkins, drone, etc.), making use of FreeBSD’s containerization mechanism "jails". We will cover terminology, rationale for using both buildbot and jails together, and installation steps. At the end, you will have a working buildbot instance using its sample build configuration, ready to play around with your own CI plans (or even CD, it’s very flexible!). Some hints for production-grade installations are given, but the tutorial steps are meant for a test environment (namely a virtual machine). Buildbot’s configuration and detailed concepts are not in scope here. Table of contents Choosing host operating system and version for buildbot Create a FreeBSD playground Introduction to jails Overview of buildbot Set up jails Install buildbot master Run buildbot master Install buildbot worker Run buildbot worker Set up web server nginx to access buildbot UI Run your first build Production hints Finished! Choosing host operating system and version for buildbot We choose the released version of FreeBSD (11.1-RELEASE at the moment). There is no particular reason for it, and as a matter of fact buildbot as a Python-based server is very cross-platform; therefore the underlying OS platform and version should not make a large difference. It will make a difference for what you do with buildbot, however. For instance, poudriere is the de-facto standard for building packages from source on FreeBSD. Builds run in jails which may be any FreeBSD base system version older or equal to the host’s version (reason will be explained below). In other words, if the host is FreeBSD 11.1, build jails created by poudriere could e.g. use 9.1, 10.3, 11.0, 11.1, but potentially not version 12 or newer because of incompatibilities with the host’s kernel (jails do not run their own kernel as full virtual machines do). To not prolong this article over the intended scope, the details of which nice things could be done or automated with buildbot are not covered. Package names on the FreeBSD platform are independent of the OS version, since external software (as in: not part of base system) is maintained in FreeBSD ports. So, if your chosen FreeBSD version (here: 11) is still officially supported, the packages mentioned in this post should work. In the unlikely event of package name changes before you read this article, you should be able to find the actual package names like pkg search buildbot. Other operating systems like the various Linux distributions will use different package names but might also offer buildbot pre-packaged. If not, the buildbot installation manual offers steps to install it manually. In such case, the downside is that you will have to maintain and update the buildbot modules outside the stability and (semi-)automatic updates of your OS packages. See article for the rest DigitalOcean Dumping your USB One of the many new features of OpenBSD 6.3 is the possibility to dump USB traffic to userland via bpf(4). This can be done with tcpdump(8) by specifying a USB bus as interface: ``` tcpdump -Xx -i usb0 tcpdump: listening on usb0, link-type USBPCAP 12:28:03.317945 bus 0 < addr 1: ep1 intr 2 0000: 0400 .. 12:28:03.318018 bus 0 > addr 1: ep0 ctrl 8 0000: 00a3 0000 0002 0004 00 ......... [...] ``` As you might have noted I decided to implement the existing USBPcap capture format. A capture format is required because USB packets do not include all the necessary information to properly interpret them. I first thought I would implement libpcap's DLTUSB but then I quickly realize that this was not a standard. It is instead a FreeBSD specific format which has been since then renamed DLTUSBFREEBSD. But I didn't want to embrace xkcd #927, so I look at the existing formats: DLTUSBFREEBSD, DLTUSBLINUX, DLTUSBLINUXMMAPPED, DLTUSBDARWIN and DLT_USBPCAP. I was first a bit sad to see that nobody could agree on a common format then I moved on and picked the simplest one: USBPcap. Implementing an already existing format gives us out-of-box support for all the tools supporting it. That's why having common formats let us share our energy. In the case of USBPcap it is already supported by Wireshark, so you can already inspect your packet graphically. For that you need to first capture raw packets: ``` tcpdump -s 3303 -w usb.pcap -i usb0 tcpdump: listening on usb0, link-type USBPCAP ^C 208 packets received by filter 0 packets dropped by kernel ``` USB packets can be quite big, that's why I'm not using tcpdump(8)'s default packet size. In this case, I want to make sure I can dump the complete uaudio(4) frames. It is important to say that what is dumped to userland is what the USB stack sees. Packets sent on the wire might differ, especially when it comes to retries and timing. So this feature is not here to replace any USB analyser, however I hope that it will help people understand how things work and what the USB stack is doing. Even I found some interesting timing issues while implementing isochronous support. Run OpenBSD on your web server Deploy and login to your OpenBSD server first. As soon as you're there you can enable an httpd(8) daemon, it's already installed on OpenBSD, you just need to configure it: www# vi /etc/httpd.conf Add two server sections---one for www and another for naked domain (all requests are redirected to www). ``` server "www.example.com" { listen on * port 80 root "/htdocs/www.example.com" } server "example.com" { listen on * port 80 block return 301 "http://www.example.com$REQUEST_URI" } ``` httpd is chrooted to /var/www by default, so let's make a document root directory: www# mkdir -p /var/www/htdocs/www.example.com Save and check this configuration: www# httpd -n configuration ok Enable httpd(8) daemon and start it. www# rcctl enable httpd www# rcctl start httpd Publish your website Copy your website content into /var/www/htdocs/www.example.com and then test it your web browser. http://XXX.XXX.XXX.XXX/ Your web server should be up and running. Update DNS records If there is another HTTPS server using this domain, configure that server to redirect all HTTPS requests to HTTP. Now as your new server is ready you can update DNS records accordingly. example.com. 300 IN A XXX.XXX.XXX.XXX www.example.com. 300 IN A XXX.XXX.XXX.XXX Examine your DNS is propagated. $ dig example.com www.example.com Check IP addresses it answer sections. If they are correct, you should be able to access your new web server by its domain name. What's next? Enable HTTPS on your server. Modern Akonadi and KMail on FreeBSD For, quite literally a year or more, KMail and Akonadi on FreeBSD have been only marginally useful, at best. KDE4 era KMail was pretty darn good, but everything after that has had a number of FreeBSD users tearing out their hair. Sure, you can go to Trojitá, which has its own special problems and is generally “meh”, or bail out entirely to webmail, but .. KMail is a really great mail client when it works. Which, on Linux desktops, is nearly always, and on FreeBSD, is was nearly never. I looked at it with Dan and Volker last summer, briefly, and we got not much further than “hmm”. There’s a message about “The world is going to end!” which hardly makes sense, it means that a message has been truncated or corrupted while traversing a UNIX domain socket. Now Alexandre Martins — praise be! — has wandered in with a likely solution. KDE Bug 381850 contains a suggestion, which deserves to be publicised (and tested): sysctl net.local.stream.recvspace=65536 sysctl net.local.stream.sendspace=65536 The default FreeBSD UNIX local socket buffer space is 8kiB. Bumping the size up to 64kiB — which matches the size that Linux has by default — suddenly makes KMail and Akonadi shine again. No other changes, no recompiling, just .. bump the sysctls (perhaps also in /etc/sysctl.conf) and KMail from Area51 hums along all day without ending the world. Since changing this value may have other effects, and Akonadi shouldn’t be dependent on a specific buffer size anyway, I’m looking into the Akonadi code (encouraged by Dan) to either automatically size the socket buffers, or to figure out where in the underlying code the assumption about buffer size lives. So for now, sysctl can make KMail users on FreeBSD happy, and later we hope to have things fully automatic (and if that doesn’t pan out, well, pkg-message exists). PS. Modern KDE PIM applications — Akonadi, KMail — which live in the deskutils/ category of the official FreeBSD ports were added to the official tree April 10th, so you can get your fix now from the official tree. Beastie Bits pkg-provides support for DragonFly (from Rodrigo Osorio) Memories of writing a parser for man pages Bryan Cantrill interview over at DeveloperOnFire podcast 1978-03-25 - 2018-03-25: 40 years BSD Mail My 5 years of FreeBSD gaming: a compendium of free games and engines running natively on FreeBSD Sequential Resilver being upstreamed to FreeBSD, from FreeNAS, where it was ported from ZFS-on-Linux University of Aberdeen’s Internet Transport Research Group is hiring Tarsnap ad Feedback/Questions Dave - mounting non-filesystem things inside jails Morgan - ZFS on Linux Data loss bug Rene - How to keep your ISP’s nose out of your browser history with encrypted DNS Rodriguez - Feedback question! Relating to Windows Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

New ZFS features landing in FreeBSD, MAP_STACK for OpenBSD, how to write safer C code with Clang’s address sanitizer, Michael W. Lucas on sponsor gifts, TCP blackbox recorder, and Dell disk system hacking. Headlines [A number of Upstream ZFS features landed in FreeBSD this week] 9188 increase size of dbuf cache to reduce indirect block decompression With compressed ARC (6950) we use up to 25% of our CPU to decompress indirect blocks, under a workload of random cached reads. To reduce this decompression cost, we would like to increase the size of the dbuf cache so that more indirect blocks can be stored uncompressed. If we are caching entire large files of recordsize=8K, the indirect blocks use 1/64th as much memory as the data blocks (assuming they have the same compression ratio). We suggest making the dbuf cache be 1/32nd of all memory, so that in this scenario we should be able to keep all the indirect blocks decompressed in the dbuf cache. (We want it to be more than the 1/64th that the indirect blocks would use because we need to cache other stuff in the dbuf cache as well.) In real world workloads, this won't help as dramatically as the example above, but we think it's still worth it because the risk of decreasing performance is low. The potential negative performance impact is that we will be slightly reducing the size of the ARC (by ~3%). 9166 zfs storage pool checkpoint The idea of Storage Pool Checkpoint (aka zpool checkpoint) deals with exactly that. It can be thought of as a “pool-wide snapshot” (or a variation of extreme rewind that doesn’t corrupt your data). It remembers the entire state of the pool at the point that it was taken and the user can revert back to it later or discard it. Its generic use case is an administrator that is about to perform a set of destructive actions to ZFS as part of a critical procedure. She takes a checkpoint of the pool before performing the actions, then rewinds back to it if one of them fails or puts the pool into an unexpected state. Otherwise, she discards it. With the assumption that no one else is making modifications to ZFS, she basically wraps all these actions into a “high-level transaction”. More information 8484 Implement aggregate sum and use for arc counters In pursuit of improving performance on multi-core systems, we should implements fanned out counters and use them to improve the performance of some of the arc statistics. These stats are updated extremely frequently, and can consume a significant amount of CPU time. And a small bug fix authored by me: 9321 arcloancompressedbuf() can increment arcloanedbytes by the wrong value arcloancompressedbuf() increments arcloanedbytes by psize unconditionally In the case of zfscompressedarcenabled=0, when the buf is returned via arcreturnbuf(), if ARCBUFCOMPRESSED(buf) is false, then arcloanedbytes is decremented by lsize, not psize. Switch to using arcbufsize(buf), instead of psize, which will return psize or lsize, depending on the result of ARCBUF_COMPRESSED(buf). MAP_STACK for OpenBSD Almost 2 decades ago we started work on W^X. The concept was simple. Pages that are writable, should not be executable. We applied this concept object by object, trying to seperate objects with different qualities to different pages. The first one we handled was the signal trampoline at the top of the stack. We just kept making changes in the same vein. Eventually W^X came to some of our kernel address spaces also. The fundamental concept is that an object should only have the permissions necessary, and any other operation should fault. The only permission separations we have are kernel vs userland, and then read, write, and execute. How about we add another new permission! This is not a hardware permission, but a software permission. It is opportunistically enforced by the kernel. the permission is MAPSTACK. If you want to use memory as a stack, you must mmap it with that flag bit. The kernel does so automatically for the stack region of a process's stack. Two other types of stack occur: thread stacks, and alternate signal stacks. Those are handled in clever ways. When a system call happens, we check if the stack-pointer register points to such a page. If it doesn't, the program is killed. We have tightened the ABI. You may no longer point your stack register at non-stack memory. You'll be killed. This checking code is MI, so it works for all platforms. Since page-permissions are generally done on page boundaries, there is caveat that thread and altstacks must now be page-sized and page-aligned, so that we can enforce the MAPSTACK attribute correctly. It is possible that a few ports need some massaging to satisfy this condition, but we haven't found any which break yet. A syslog_r has been added so that we can identify these failure cases. Also, the faulting cases are quite verbose for now, to help identify the programs we need to repair. **iXsystems** Writing Safer C with the Clang Address Sanitizer We wanted to improve our password strength algorithm, and decided to go for the industry-standard zxcvbn, from the people at Dropbox. Our web front-end would use the default Javascript library, and for mobile and desktop, we chose to use the C implementation as it was the lowest common denominator for all platforms. Bootstrapping all of this together was done pretty fast. I had toyed around with a few sample passwords so I decided to run it through the test suite we had for the previous password strength evaluator. The test generates a large number of random passwords according to different rules and expects the strength to be in a given range. But the test runner kept crashing with segmentation faults. It turns out the library has a lot of buffer overflow cases that are usually "harmless", but eventually crash your program when you run the evaluator function too much. I started fixing the cases I could see, but reading someone else's algorithms to track down tiny memory errors got old pretty fast. I needed a tool to help me. That's when I thought of Clang's Address Sanitizer. AddressSanitizer is a fast memory error detector. It consists of a compiler instrumentation module and a run-time library Let's try the sanitizer on a simple program. We'll allocate a buffer on the heap, copy each character of a string into it, and print it to standard output. + The site walks through a simple example which contains an error, it writes past the end of a buffer + The code works as expected, and nothing bad happens. It must be fine… + Then they compile it again with the address sanitizer actived So what can we gather from that pile of hex? Let's go through it line by line. AddressSanitizer found a heap buffer overflow at 0x60200000ef3d, a seemingly valid address (not NULL or any other clearly faulty value). + ASAN points directly to the line of code that is causing the problem We're writing outside of the heap in this instruction. And AddressSanitizer isn't having it. This is definitely one of my favorite indications. In addition to telling which line in the code failed and where in the memory the failure happened, you get a complete description of the closest allocated region in memory (which is probably the region you were trying to access). + They then walk through combining this with lldb, the Clang debugger, to actually interactively inspect the state of the problem when an invalid memory access happens Back to my practical case, how did I put the address sanitizer to good use? I simply ran the test suite, compiled with the sanitizer, with lldb. Sure enough, it stopped on every line that could cause a crash. It turns out there were many cases where zxcvbn-c wrote past the end of allocated buffers, on the heap and on the stack. I fixed those cases in the C library and ran the tests again. Not a segfault in sight! I've used memory tools in the past, but they were usually unwieldy, or put such a toll on performance that they were useless in any real-life case. Clang's address sanitizer turned out to be detailed, reliable, and surprisingly easy to use. I've heard of the miracles of Valgrind but macOS hardly supports it, making it a pain to use on my MacBook Pro. Coupled with Clang's static analyzer, AddressSanitizer is going to become a mandatory stop for evaluating code quality. It's also going to be the first tool I grab when facing confusing memory issues. There are many more case where I could use early failure and memory history to debug my code. For example, if a program crashes when accessing member of a deallocated object, we could easily trace the event that caused the deallocation, saving hours of adding and reading logs to retrace just what happened. News Roundup On sponsor gifts Note the little stack of customs forms off to the side. It’s like I’ve learned a lesson from standing at the post office counter filling out those stupid forms. Sponsors should get their books soon. This seems like an apropos moment to talk about what I do for print sponsors. I say I send them “a gift,” but what does that really mean? The obvious thing to ship them is a copy of the book I’ve written. Flat-out selling print books online has tax implications, though. Sponsors might have guessed that they’d get a copy of the book. But I shipped them the hardcover, which isn’t my usual practice. That’s because I send sponsors a gift. As it’s a gift, I get to choose what I send. I want to send them something nice, to encourage them to sponsor another book. It makes no sense for me to send a sponsor a Singing Wedgie-O-Gram. (Well, maybe a couple sponsors. You know who you are.) The poor bastards who bought into my scam–er, sponsored my untitled book–have no idea what’s coming. As of right now, their sensible guesses are woefully incomplete. Future books? They might get a copy of the book. They might get book plus something. They might just get the something. Folks who sponsor the jails book might get a cake with a file in it. Who knows? It’s a gift. It’s my job to make that gift worthwhile. And to amuse myself. Because otherwise, what’s the point? TCP Blackbox Recorder ``` Add the "TCP Blackbox Recorder" which we discussed at the developer summits at BSDCan and BSDCam in 2017. The TCP Blackbox Recorder allows you to capture events on a TCP connection in a ring buffer. It stores metadata with the event. It optionally stores the TCP header associated with an event (if the event is associated with a packet) and also optionally stores information on the sockets. It supports setting a log ID on a TCP connection and using this to correlate multiple connections that share a common log ID. You can log connections in different modes. If you are doing a coordinated test with a particular connection, you may tell the system to put it in mode 4 (continuous dump). Or, if you just want to monitor for errors, you can put it in mode 1 (ring buffer) and dump all the ring buffers associated with the connection ID when we receive an error signal for that connection ID. You can set a default mode that will be applied to a particular ratio of incoming connections. You can also manually set a mode using a socket option. This commit includes only basic probes. rrs@ has added quite an abundance of probes in his TCP development work. He plans to commit those soon. There are user-space programs which we plan to commit as ports. These read the data from the log device and output pcapng files, and then let you analyze the data (and metadata) in the pcapng files. Reviewed by: gnn (previous version) Obtained from: Netflix, Inc. Relnotes: yes Differential Revision: https://reviews.freebsd.org/D11085 ``` **Digital Ocean** Outta the way, KDE4 KDE4 has been rudely moved aside on FreeBSD. It still installs (use x11/kde4) and should update without a problem, but this is another step towards adding modern KDE (Plasma 5 and Applications) to the official FreeBSD Ports tree. This has taken a long time mostly for administrative reasons, getting all the bits lined up so that people sticking with KDE4 (which, right now, would be everyone using KDE from official ports and packages on FreeBSD) don’t end up with a broken desktop. We don’t want that. But now that everything Qt4 and kdelibs4-based has been moved aside by suffixing it with -kde4, we have the unsuffixed names free to indicate the latest-and-greatest from upstream. KDE4 users will see a lot of packages moving around and being renamed, but no functional changes. Curiously, the KDE4 desktop depends on Qt5 and KDE Frameworks 5 — and it has for quite some time already, because the Oxygen icons are shared with KDE Frameworks, but primarily because FileLight was updated to the modern KDE Applications version some time ago (the KDE4 version had some serious bugs, although I can not remember what they were). Now that the names are cleaned up, we could consider giving KDE4 users the buggy version back. From here on, we’ve got the following things lined up: Qt 5.10 is being worked on, except for WebEngine (it would slow down an update way too much), because Plasma is going to want Qt 5.10 soon. CMake 3.11 is in the -rc stage, so that is being lined up. The kde5-import branch in KDE-FreeBSD’s copy of the FreeBSD ports tree (e.g. Area51) is being prepped and polished for a few big SVN commits that will add all the new bits. So we’ve been saying Real Soon Now ™ for years, but things are Realer Sooner Nower ™ now. Dell FS12-NV7 and other 2U server (e.g. C6100) disk system hacking A while back I reviewed the Dell FS12-NV7 – a 2U rack server being sold cheap by all and sundry. It’s a powerful box, even by modern standards, but one of its big drawbacks is the disk system it comes with. But it needn’t be. There are two viable solutions, depending on what you want to do. You can make use of the SAS backplane, using SAS and/or SATA drives, or you can go for fewer SATA drives and free up one or more PCIe slots as Plan B. You probably have an FS12 because it looks good for building a drive array (or even FreeNAS) so I’ll deal with Plan A first. Like most Dell servers, this comes with a Dell PERC RAID SAS controller – a PERC6/i to be precise. This ‘I’ means it has internal connectors; the /E is the same but its sockets are external. The PERC connects to a twelve-slot backplane forming a drive array at the front of the box. More on the backplane later; it’s the PERCs you need to worry about. The PERC6 is actually an LSI Megaraid 1078 card, which is just the thing you need if you’re running an operating system like Windows that doesn’t support a volume manager, striping and other grown-up stuff. Or if your OS does have these features, but you just don’t trust it. If you are running such an OS you may as well stick to the PERC6, and good luck to you. If you’re using BSD (including FreeNAS), Solaris or a Linux distribution that handles disk arrays, read on. The PERC6 is a solution to a problem you probably don’t have, but in all other respects its a turkey. You really want a straightforward HBA (Host Bus Adapter) that allows your clever operating system to talk directly with the drives. Any SAS card based on the 1078 (such as the PERC6) is likely to have problems with drives larger than 2Tb. I’m not completely sure why, but I suspect it only applies to SATA. Unfortunately I don’t have any very large SAS drives to test this theory. A 2Tb limit isn’t really such a problem when you’re talking about a high performance array, as lots of small drives are a better option anyway. But it does matter if you’re building a very large datastore and don’t mind slower access and very significant resilvering times when you replace a drive. And for large datastores, very large SATA drives save you a whole lot of cash. The best capacity/cost ratio is for 5Gb SATA drives Some Dell PERCs can be re-flashed with LSI firmware and used as a normal HBA. Unfortunately the PERC6 isn’t one of them. I believe the PERC6/R can be, but those I’ve seen in a FS12 are just a bit too old. So the first thing you’ll need to do is dump them in the recycling or try and sell them on eBay. There are actually two PERC6 cards in most machine, and they each support eight SAS channels through two SFF-8484 connectors on each card. Given there are twelve drives slots, one of the PERCs is only half used. Sometimes they have a cable going off to a battery located near the fans. This is used in a desperate attempt to keep the data in the card’s cache safe in order to avoid write holes corrupting NTFS during a power failure, although the data on the on-drive caches won’t be so lucky. If you’re using a file system like that, make sure you have a UPS for the whole lot. But we’re going to put the PERCs out of our misery and replace them with some nice new LSI HBAs that will do our operating system’s bidding and let it talk to the drives as it knows best. But which to pick? First we need to know what we’re connecting. Moving to the front of the case there are twelve metal drive slots with a backplane behind. Dell makes machines with either backplanes or expanders. A backplane has a 1:1 SAS channel to drive connection; an expander takes one SAS channel and multiplexes it to (usually) four drives. You could always swap the blackplane with an expander, but I like the 1:1 nature of a backplane. It’s faster, especially if you’re configured as an array. And besides, we don’t want to spend more money than we need to, otherwise we wouldn’t be hot-rodding a cheap 2U server in the first place – expanders are expensive. Bizarrely, HBAs are cheap in comparison. So we need twelve channels of SAS that will connect to the sockets on the backplane. The HBA you will probably want to go with is an LSI, as these have great OS support. Other cards are available, but check that the drivers are also available. The obvious choice for SAS aficionados is the LSI 9211-8i, which has eight internal channels. This is based on an LSI 2000 series chip, the 2008, which is the de-facto standard. There’s also four-channel -4i version, so you could get your twelve channels using one of each – but the price difference is small these days, so you might as well go for two -8i cards. If you want cheaper there are 1068-based equivalent cards, and these work just fine at about half the price. They probably won’t work with larger disks, only operate at 3Gb and the original SAS standard. However, the 2000 series is only about £25 extra and gives you more options for the future. A good investment. Conversely, the latest 3000 series cards can do some extra stuff (particularly to do with active cables) but I can’t see any great advantage in paying megabucks for one unless you’re going really high-end – in which case the NV12 isn’t the box for you anyway. And you’d need some very fast drives and a faster backplane to see any speed advantage. And probably a new motherboard…. Whether the 6Gb SAS2 of the 9211-8i is any use on the backplane, which was designed for 3Gb, I don’t know. If it matters that much to you you probably need to spend a lot more money. A drive array with a direct 3Gb to each drive is going to shift fast enough for most purposes. Once you have removed the PERCs and plugged in your modern-ish 9211 HBAs, your next problem is going to be the cable. Both the PERCs and the backplane have SFF-8484 multi-lane connectors, which you might not recognise. SAS is a point-to-point system, the same as SATA, and a multi-lane cable is simply four single cables in a bundle with one plug. (Newer versions of SAS have more). SFF-8484 multi-lane connectors are somewhat rare, (but unfortunately this doesn’t make them valuable if you were hoping to flog them on eBay). The world switched quickly to the SFF-8087 for multi-lane SAS. The signals are electrically the same, but the connector is not. Please generate and paste your ad code here. If left empty, the ad location will be highlighted on your blog pages with a reminder to enter your code. Mid-Post So there are two snags with this backplane. Firstly it’s designed to work with PERC controllers; secondly it has the old SFF-8484 connectors on the back, and any SAS cables you find are likely to have SFF-8087. First things first – there is actually a jumper on the backplane to tell it whether it’s talking to a PERC or a standard LSI HBA. All you need to do is find it and change it. Fortunately there are very few jumpers to choose from (i.e. two), and you know the link is already in the wrong place. So try them one at a time until it works. The one you want may be labelled J15, but I wouldn’t like to say this was the same on every variant. Second problem: the cable. You can get cables with an SFF-8087 on one end and an SFF-8484 on the other. These should work. But they’re usually rather expensive. If you want to make your own, it’s a PITA but at least you have the connectors already (assuming you didn’t bin the ones on the PERC cables). I don’t know what committee designed SAS cable connectors, but ease of construction wasn’t foremost in their collective minds. You’re basically soldering twisted pair to a tiny PCB. This is mechanically rubbish, of course, as the slightest force on the cable will lift the track. Therefore its usual to cover the whole joint in solidified gunk (technical term) to protect it. Rewiring SAS connectors is definitely not easy. I’ve tried various ways of soldering to them, none of which were satisfactory or rewarding. One method is to clip the all bare wires you wish to solder using something like a bulldog clip so they’re at lined up horizontally and then press then adjust the clamp so they’re gently pressed to the tracks on the board, making final adjustments with a strong magnifying glass and a fine tweezers. You can then either solder them with a fine temperature-controlled iron, or have pre-coated the pads with solder paste and flash across it with an SMD rework station. I’d love to know how they’re actually manufactured – using a precision jig I assume. The “easy” way is to avoid soldering the connectors at all; simply cut existing cables in half and join one to the other. I’ve used prototyping matrix board for this. Strip and twist the conductors, push them through a hole and solder. This keeps things compact but manageable. We’re dealing with twisted pair here, so maintain the twists as close as possible to the board – it actually works quite well. However, I’ve now found a reasonably-priced source of the appropriate cable so I don’t do this any more. Contact me if you need some in the UK. So all that remains is to plug your HBAs to the backplane, shove in some drives and you’re away. If you’re at this stage, it “just works”. The access lights for all the drives do their thing as they should. The only mystery is how you can get the ident LED to come on; this may be controlled by the PERC when it detects a failure using the so-called sideband channel, or it may be operated by the electronics on the backplane. It’s workings are, I’m afraid, something of a mystery still – it’s got too much electronics on board to be a completely passive backplane. Plan B: SATA If you plan to use only SATA drives, especially if you don’t intend using more than six, it makes little sense to bother with SAS at all. The Gigabyte motherboard comes with half a dozen perfectly good 3Gb SATA channels, and if you need more you can always put another controller in a PCIe slot, or even USB. The advantages are lower cost and you get to free up two PCIe slots for more interesting things. The down-side is that you can’t use the SAS backplane, but you can still use the mounting bays. Removing the backplane looks tricky, but it really isn’t when you look a bit closer. Take out the fans first (held in place by rubber blocks), undo a couple of screws and it just lifts and slides out. You can then slot and lock in the drives and connect the SATA connectors directly to the back of the drives. You could even slide them out again without opening the case, as long as the cable was long enough and you manually detached the cable it when it was withdrawn. And let’s face it – drives are likely to last for years so even with half a dozen it’s not that great a hardship to open the case occasionally. Next comes power. The PSU has a special connector for the backplane and two standard SATA power plugs. You could split these three ways using an adapter, but if you have a lot of drives you might want to re-wire the cables going to the backplane plug. It can definitely power twelve drives. And that’s almost all there is to it. Unfortunately the main fans are connected to the backplane, which you’ve just removed. You can power them from an adapter on the drive power cables, but there are unused fan connectors on the motherboard. I’m doing a bit more research on cooling options, but this approach has promising possibilities for noise reduction. Beastie Bits Adriaan de Groot’s post FOSDEM blog post My First FreeNAS smart(8) Call for Testing by Michael Dexter BSDCan 2018 Travel Grant Application Now Open BSD Developer Kristaps Dzonsons interviews Linus Torvalds, about diving Twitter vote - The secret to a faster FreeBSD default build world... tmate - Instant terminal sharing Tarsnap Feedback/Questions Vikash - Getting a port added Chris Wells - Quarterly Ports Branch FreeBSD-CI configs on Github Jenkins on the FreeBSD Wiki Gordon - Centralised storage suggestions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

Lumina Desktop 1.3 is out, we show you a Plasma 5 on FreeBSD tutorial, explore randomness, and more. This episode was brought to you by Headlines Lumina Desktop v1.3 released (https://lumina-desktop.org/version-1-3-0-released/) Notable Changes: New Utility: lumina-mediaplayer. Lumina Media Player is a graphic interface for the Qt QMediaPlayer Class, with Pandora internet radio streaming integration. Lumina Media Player supports many audio formats, including .ogg, .mp3, .mp4, .flac, and .wmv. It is also possible to increase the number of playable formats by installing gstreamer-plugins. This utility is found in the Applications → Utilities section, or opened by typing lumina-mediaplayer in a command line. New Utility: lumina-xdg-entry. This is another simple utility designed to help users create .desktop entries and shortcuts. Find it in the Utilities application category, or open it by typing lumina-xdg-entry in a command line. Lumina Desktop: Desktop folders are integrated, and can now be manipulated directly from the desktop. Added the automatic settings migration of a desktop monitor (single monitor only, for now). Numerous speed and performance improvements with how icons load and the system interacts with the desktop. Lumina-FM: Now fully integrated with lumina-archiver. A “System directory” tree pane is available. Options to enable/disable it are being added later, as it is on by default. Numerous speed improvements with caching and loading icons. Lumina Texteditor: There is a new json manifest file format for syntax highlighting support. Users can open this file, customize their highlighting options, and immediately see their changes without rebuilding the utility. The text editor now supports more than 10 different file formats. Added options for file-wide preferences in syntax files. Options include: word wrap, character per line limits, excess whitespace highlighting, font style restrictions, and tab-width settings. LTE supports tabs with detach, drag'n'drop, and location customization with the View menu option. Add checkable menu option to show the “unsaved changes” dialogue box on close. Lumina Screenshot: Adjustments to the lumina-screenshot interface. Add an adjustable warning to lumina-screenshot when closing with an unsaved image. Add functionality to select a specific area of the screen for screenshots. Lumina Archiver: Functionality improvements. Bug fixes. Interface changes. General Improvements: Permission checks for settings files (all utilities). When launched with sudo, all tools use or create a root-permissioned copy of the user's settings file. This prevents a settings file being locked by root. UI text reworks to help re-unify style. Add hooks to update the desktop with icons for the /media directory when a system uses USB automounting functionality. Fix Fluxbox bug with windows workspace assignments. Work on new utility lumina-notify (not fully functional yet). Fix panel reporting error crashing lumina-config. Bug fix for dbus-send calls for Gentoo. Clean up automatic DPI scaling support. Bug fix for the panel clock. Compton compositor is now disabled by default (but can be manually enabled). Translation file updates. Documentation updates. *** FreeBSD 11.0 and Plasma 5 HowTo (https://euroquis.nl/bobulate/?p=1609) 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.) We skip the part about installing FreeBSD (it's in there if you need it) and get right to the important parts that you need: An X Server and a backup X11 environment (ancient): pkg install xorg xterm twm Desktop technologies (modern): pkg install hal dbus echo haldenable=YES >> /etc/rc.conf echo dbusenable=YES >> /etc/rc.conf Next up, test whether the X server works by running startx and exiting out of twm. 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 Now swap out the default FreeBSD package repository, for the KDE-FreeBSD community one. This is documented also on the Area51 page (https://community.kde.org/FreeBSD/Setup/Area51). mkdir -p /usr/local/etc/pkg/repos cd /usr/local/etc/pkg/repos cat > FreeBSD.conf > /etc/rc.conf Log in as your test user, and set up .xinitrc to start Plasma 5: cat > .xinitrc

We cover TrueOS/Lumina working to be less dependent on Linux, How the IllumOS network stack works, Throttling the password gropers & the 64 bit inode call for testing. This episode was brought to you by Headlines vBSDCon CFP closed April 29th (https://easychair.org/conferences/?conf=vbsdcon2017) EuroBSDCon CFP closes April 30th (https://2017.eurobsdcon.org/2017/03/13/call-for-proposals/) Developer Commentary: Philosophy, Evolution of TrueOS/Lumina, and Other Thoughts. (https://www.trueos.org/blog/developer-commentary-philosophy-evolution-trueoslumina-thoughts/) Philosophy of Development No project is an island. Every single project needs or uses some other external utility, library, communications format, standards compliance, and more in order to be useful. A static project is typically a dead project. A project needs regular upkeep and maintenance to ensure it continues to build and run with the current ecosystem of libraries and utilities, even if the project has no considerable changes to the code base or feature set. “Upstream” decisions can have drastic consequences on your project. Through no fault of yours, your project can be rendered obsolete or broken by changing standards in the global ecosystem that affect your project's dependencies. Operating system focus is key. What OS is the project originally designed for? This determines how the “upstream” dependencies list appears and which “heartbeat” to monitor. Evolution of PC-BSD, Lumina, and TrueOS. With these principles in mind – let's look at PC-BSD, Lumina, and TrueOS. PC-BSD : PC-BSD was largely designed around KDE on FreeBSD. KDE/Plasma5 has been available for Linux OS's for well over a year, but is still not generally available on FreeBSD. It is still tucked away in the experimental “area51” repository where people are trying to get it working first. Lumina : As a developer with PC-BSD for a long time, and a tester from nearly the beginning of the project, I was keenly aware the “winds of change” were blowing in the open-source ecosystem. TrueOS : All of these ecosystem changes finally came to a head for us near the beginning of 2016. KDE4 was starting to deteriorate underneath us, and the FreeBSD “Release” branch would never allow us to compete with the rate of graphics driver or standards changes coming out of the Linux camp. The Rename and Next Steps With all of these changes and the lack of a clear “upgrade” path from PC-BSD to the new systems, we decided it was necessary to change the project itself (name and all). To us, this was the only way to ensure people were aware of the differences, and that TrueOS really is a different kind of project from PC-BSD. Note this was not a “hostile takeover” of the PC-BSD project by rabid FreeBSD fanatics. This was more a refocusing of the PC-BSD project into something that could ensure longevity and reliability for the foreseeable future. Does TrueOS have bugs and issues? Of course! That is the nature of “rolling” with upstream changes all the time. Not only do you always get the latest version of something (a good thing), you also find yourself on the “front line” for finding and reporting bugs in those same applications (a bad thing if you like consistency or stability). What you are also seeing is just how much “churn” happens in the open-source ecosystem at any given time. We are devoted to providing our users (and ourselves – don't forget we use TrueOS every day too!) a stable, reliable, and secure experience. Please be patient as we continue striving toward this goal in the best way possible, not just doing what works for the moment, but the project's future too. Robert Mustacchi: Excerpts from The Soft Ring Cycle #1 (https://www.youtube.com/watch?v=vnD10WQ2930) The author of the “Turtles on the Wire” post we featured the other week, is back with a video. Joyent has started a new series of lunchtime technical discussions to share information as they grow their engineering team This video focuses on the network stack, how it works, and how it relates to virtualization and multi-tenancy Basically, how the network stack on IllumOS works when you have virtual tenants, be they virtual machines or zones The video describes the many layers of the network stack, how they work together, and how they can be made to work quickly It also talks about the trade-offs between high throughput and low latency How security is enforced, so virtual tenants cannot send packets into VLANs they are not members of, or receive traffic that they are not allowed to by the administrator How incoming packets are classified, and eventually delivered to the intended destination How the system decides if it has enough available resources to process the packet, or if it needs to be dropped How interface polling works on IllumOS (a lot different than on FreeBSD) Then the last 20 minutes are about how the qemu interface of the KVM hypervisor interfaces with the network stack We look forward to seeing more of these videos as they come out *** Forcing the password gropers through a smaller hole with OpenBSD's PF queues (http://bsdly.blogspot.com/2017/04/forcing-password-gropers-through.html) While preparing material for the upcoming BSDCan PF and networking tutorial (http://www.bsdcan.org/2017/schedule/events/805.en.html), I realized that the pop3 gropers were actually not much fun to watch anymore. So I used the traffic shaping features of my OpenBSD firewall to let the miscreants inflict some pain on themselves. Watching logs became fun again. The actual useful parts of this article follow - take this as a walkthrough of how to mitigate a wide range of threats and annoyances. First, analyze the behavior that you want to defend against. In our case that's fairly obvious: We have a service that's getting a volume of unwanted traffic, and looking at our logs the attempts come fairly quickly with a number of repeated attempts from each source address. I've written about the rapid-fire ssh bruteforce attacks and their mitigation before (and of course it's in The Book of PF) as well as the slower kind where those techniques actually come up short. The traditional approach to ssh bruteforcers has been to simply block their traffic, and the state-tracking features of PF let you set up overload criteria that add the source addresses to the table that holds the addresses you want to block. For the system that runs our pop3 service, we also have a PF ruleset in place with queues for traffic shaping. For some odd reason that ruleset is fairly close to the HFSC traffic shaper example in The Book of PF, and it contains a queue that I set up mainly as an experiment to annoy spammers (as in, the ones that are already for one reason or the other blacklisted by our spamd). The queue is defined like this: queue spamd parent rootq bandwidth 1K min 0K max 1K qlimit 300 yes, that's right. A queue with a maximum throughput of 1 kilobit per second. I have been warned that this is small enough that the code may be unable to strictly enforce that limit due to the timer resolution in the HFSC code. But that didn't keep me from trying. Now a few small additions to the ruleset are needed for the good to put the evil to the task. We start with a table to hold the addresses we want to mess with. Actually, I'll add two, for reasons that will become clear later: table persist counters table persist counters The rules that use those tables are: block drop log (all) quick from pass in quick log (all) on egress proto tcp from to port pop3 flags S/SA keep state (max-src-conn 2, max-src-conn-rate 3/3, overload flush global, pflow) set queue spamd pass in log (all) on egress proto tcp to port pop3 flags S/SA keep state (max-src-conn 5, max-src-conn-rate 6/3, overload flush global, pflow) The last one lets anybody connect to the pop3 service, but any one source address can have only open five simultaneous connections and at a rate of six over three seconds. The results were immediately visible. Monitoring the queues using pfctl -vvsq shows the tiny queue works as expected: queue spamd parent rootq bandwidth 1K, max 1K qlimit 300 [ pkts: 196136 bytes: 12157940 dropped pkts: 398350 bytes: 24692564 ] [ qlength: 300/300 ] [ measured: 2.0 packets/s, 999.13 b/s ] and looking at the pop3 daemon's log entries, a typical encounter looks like this: Apr 19 22:39:33 skapet spop3d[44875]: connect from 111.181.52.216 Apr 19 22:39:33 skapet spop3d[75112]: connect from 111.181.52.216 Apr 19 22:39:34 skapet spop3d[57116]: connect from 111.181.52.216 Apr 19 22:39:34 skapet spop3d[65982]: connect from 111.181.52.216 Apr 19 22:39:34 skapet spop3d[58964]: connect from 111.181.52.216 Apr 19 22:40:34 skapet spop3d[12410]: autologout time elapsed - 111.181.52.216 Apr 19 22:40:34 skapet spop3d[63573]: autologout time elapsed - 111.181.52.216 Apr 19 22:40:34 skapet spop3d[76113]: autologout time elapsed - 111.181.52.216 Apr 19 22:40:34 skapet spop3d[23524]: autologout time elapsed - 111.181.52.216 Apr 19 22:40:34 skapet spop3d[16916]: autologout time elapsed - 111.181.52.216 here the miscreant comes in way too fast and only manages to get five connections going before they're shunted to the tiny queue to fight it out with known spammers for a share of bandwidth. One important takeaway from this, and possibly the most important point of this article, is that it does not take a lot of imagination to retool this setup to watch for and protect against undesirable activity directed at essentially any network service. You pick the service and the ports it uses, then figure out what are the parameters that determine what is acceptable behavior. Once you have those parameters defined, you can choose to assign to a minimal queue like in this example, block outright, redirect to something unpleasant or even pass with a low probability. 64-bit inodes (ino64) Status Update and Call for Testing (https://lists.freebsd.org/pipermail/freebsd-fs/2017-April/024684.html) Inodes are data structures corresponding to objects in a file system, such as files and directories. FreeBSD has historically used 32-bit values to identify inodes, which limits file systems to somewhat under 2^32 objects. Many modern file systems internally use 64-bit identifiers and FreeBSD needs to follow suit to properly and fully support these file systems. The 64-bit inode project, also known as ino64, started life many years ago as a project by Gleb Kurtsou (gleb@). After that time several people have had a hand in updating it and addressing regressions, after mckusick@ picked up and updated the patch, and acted as a flag-waver. Overview : The ino64 branch extends the basic system types inot and devt from 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. Motivation : The main risk of the ino64 change is the uncontrolled ABI breakage. Quirks : We handled kinfo sysctl MIBs, but other MIBs which report structures depended on the changed type, are not handled in general. It was considered that the breakage is either in the management interfaces, where we usually allow ABI slip, or is not important. Testing procedure : The ino64 project can be tested by cloning the project branch from GitHub or by applying the patch to a working tree. New kernel, old world. New kernel, new world, old third-party applications. 32bit compat. Targeted tests. NFS server and client test Other filesystems Test accounting Ports Status with ino64 : A ports exp-run for ino64 is open in PR 218320. 5.1. LLVM : LLVM includes a component called Address Sanitizer or ASAN, which triesto intercept syscalls, and contains knowledge of the layout of many system structures. Since stat and lstat syscalls were removed and several types and structures changed, this has to be reflected in the ASAN hacks. 5.2. lang/ghc : The ghc compiler and parts of the runtime are written in Haskell, which means that to compile ghc, you need a working Haskell compiler for bootstrap. 5.3. lang/rust Rustc has a similar structure to GHC, and same issue. The same solution of patching the bootstrap was done. Next Steps : The tentative schedule for the ino64 project: 2017-04-20 Post wide call for testing : Investigate and address port failures with maintainer support 2017-05-05 Request second exp-run with initial patches applied : Investigate and address port failures with maintainer support 2017-05-19 Commit to HEAD : Address post-commit failures where feasible *** News Roundup Sing, beastie, sing! (http://meka.rs/blog/2017/01/25/sing-beastie-sing/) FreeBSD digital audio workstation, or DAW for short, is now possible. At this very moment it's not user friendly that much, but you'll manage. What I want to say is that I worked on porting some of the audio apps to FreeBSD, met some other people interested in porting audio stuff and became heavily involved with DrumGizmo - drum sampling engine. Let me start with the basic setup. FreeBSD doesn't have hard real-time support, but it's pretty close. For the needs of audio, FreeBSD's implementation of real-time is sufficient and, in my opinion, superior to the one you can get on Linux with RT path (which is ugly, not supported by distributions and breaks apps like VirtualBox). As default install of FreeBSD is concerned with real-time too much, we have to tweak sysctl a bit, so append this to your /etc/sysctl.conf: kern.timecounter.alloweddeviation=0 hw.usb.uaudio.buffer_ms=2 # only on -STABLE for now hw.snd.latency=0 kern.coredump=0 So let me go through the list. First item tells FreeBSD how many events it can aggregate (or wait for) before emitting them. The reason this is the default is because aggregating events saves power a bit, and currently more laptops are running FreeBSD than DAWs. Second one is the lowest possible buffer for USB audio driver. If you're not using USB audio, this won't change a thing. Third one has nothing to do with real-time, but dealing with programs that consume ~3GB of RAM, dumping cores around made a problem on my machine. Besides, core dumps are only useful if you know how to debug the problem, or someone is willing to do that for you. I like to not generate those files by default, but if some app is constantly crashing, I enable dumps, run the app, crash it, and disable dumps again. I lost 30GB in under a minute by examining 10 different drumkits of DrumGizmo and all of them gave me 3GB of core file, each. More setup instructions follow, including jackd setup and PulseAudio using virtual_oss. With this setup I can play OSS, JACK and PulseAudio sound all at the same time, which I was not able to do on Linux. FreeBSD 11 Unbound DNS server (https://itso.dk/?p=499) In FreeBSD, there is a built-in DNS server called Unbound. So why would run a local DNS server? I am in a region where internet traffic is still a bit expensive, that also implies slow, and high response times. To speed that a up a little, you can use own DNS server. It will speed up because for every homepage you visit, there will be several hooks to other domains: commercials, site components, and links to other sites. These, will now all be cached locally on your new DNS server. In my case I use an old PC-Engine Alix board for my home DNS server, but you can use almost everything, Raspberry Pi, old laptop/desktop and others. As long as it runs FreeBSD. Goes into more details about what commands to run and which services to start Try it out if you are in a similar situation *** Why it is important that documentation and tutorials be correct and carefully reviewed (https://arxiv.org/pdf/1704.02786.pdf) A group of researchers found that a lot of online web programming tutorials contain serious security flaws. They decided to do a research project to see how this impacts software that is written possibly based on those tutorials. They used a number of simple google search terms to make a list of tutorials, and manually audited them for common vulnerabilities. They then crawled GitHub to find projects with very similar code snippets that might have been taken from those tutorials. The Web is replete with tutorial-style content on how to accomplish programming tasks. Unfortunately, even top-ranked tutorials suffer from severe security vulnerabilities, such as cross-site scripting (XSS), and SQL injection (SQLi). Assuming that these tutorials influence real-world software development, we hypothesize that code snippets from popular tutorials can be used to bootstrap vulnerability discovery at scale. To validate our hypothesis, we propose a semi-automated approach to find recurring vulnerabilities starting from a handful of top-ranked tutorials that contain vulnerable code snippets. We evaluate our approach by performing an analysis of tens of thousands of open-source web applications to check if vulnerabilities originating in the selected tutorials recur. Our analysis framework has been running on a standard PC, analyzed 64,415 PHP codebases hosted on GitHub thus far, and found a total of 117 vulnerabilities that have a strong syntactic similarity to vulnerable code snippets present in popular tutorials. In addition to shedding light on the anecdotal belief that programmers reuse web tutorial code in an ad hoc manner, our study finds disconcerting evidence of insufficiently reviewed tutorials compromising the security of open-source projects. Moreover, our findings testify to the feasibility of large-scale vulnerability discovery using poorly written tutorials as a starting point The researchers found 117 vulnerabilities, of these, at least 8 appear to be nearly exact copy/pastes of the tutorials that were found to be vulnerable. *** 1.3.0 Development Preview: New icon themes (https://lumina-desktop.org/1-3-0-development-preview-new-icon-themes/) As version 1.3.0 of the Lumina desktop starts getting closer to release, I want to take a couple weeks and give you all some sneak peaks at some of the changes/updates that we have been working on (and are in the process of finishing up). New icon theme (https://lumina-desktop.org/1-3-0-development-preview-new-icon-themes/) Material Design Light/Dark There are a lot more icons available in the reference icon packs which we still have not gotten around to renaming yet, but this initial version satisfies all the XDG standards for an icon theme + all the extra icons needed for Lumina and it's utilities + a large number of additional icons for application use. This highlights one the big things that I love about Lumina: it gives you an interface that is custom-tailored to YOUR needs/wants – rather than expecting YOU to change your routines to accomodate how some random developer/designer across the world thinks everybody should use a computer. Lumina Media Player (https://lumina-desktop.org/1-3-0-development-preview-lumina-mediaplayer/) This is a small utility designed to provide the ability for the user to play audio and video files on the local system, as well as stream audio from online sources. For now, only the Pandora internet radio service is supported via the “pianobar” CLI utility, which is an optional runtime dependency. However, we hope to gradually add new streaming sources over time. For a long time I had been using another Pandora streaming client on my TrueOS desktop, but it was very fragile with respect to underlying changes: LibreSSL versions for example. The player would regularly stop functioning for a few update cycles until a version of LibreSSL which was “compatible” with the player was used. After enduring this for some time, I was finally frustrated enough to start looking for alternatives. A co-worker pointed me to a command-line utility called “pianobar“, which was also a small client for Pandora radio. After using pianobar for a couple weeks, I was impressed with how stable it was and how little “overhead” it required with regards to extra runtime dependencies. Of course, I started thinking “I could write a Qt5 GUI for that!”. Once I had a few free hours, I started writing what became lumina-mediaplayer. I started with the interface to pianobar itself to see how complicated it would be to interact with, but after a couple days of tinkering in my spare time, I realized I had a full client to Pandora radio basically finished. Beastie Bits vBSDCon CFP closes April 29th (https://easychair.org/conferences/?conf=vbsdcon2017) EuroBSDCon CFP closes April 30th (https://2017.eurobsdcon.org/2017/03/13/call-for-proposals/) clang(1) added to base on amd64 and i386 (http://undeadly.org/cgi?action=article&sid=20170421001933) Theo: “Most things come to an end, sorry.” (https://marc.info/?l=openbsd-misc&m=149232307018311&w=2) ASLR, PIE, NX, and other capital letters (https://www.dragonflydigest.com/2017/04/24/19609.html) How SSH got port number 22 (https://www.ssh.com/ssh/port) Netflix Serving 90Gb/s+ From Single Machines Using Tuned FreeBSD (https://news.ycombinator.com/item?id=14128637) Compressed zfs send / receive lands in FreeBSD HEAD (https://svnweb.freebsd.org/base?view=revision&revision=317414) *** Feedback/Questions Steve - FreeBSD Jobs (http://dpaste.com/3QSMYEH#wrap) Mike - CuBox i4Pro (http://dpaste.com/0NNYH22#wrap) Steve - Year of the BSD Desktop? (http://dpaste.com/1QRZBPD#wrap) Brad - Configuration Management (http://dpaste.com/2TFV8AJ#wrap) ***

У меня в гостях Вадим Жуков, разработчик OpenBSD, мейнтейнер портов KDE и Qt и преподаватель операционных систем по совместительству. Обсудили то, как устроен проект OpenBSD: насколько велико сообщество разработчиков, какие там есть зоны ответственности, как устроен процесс разработки, тестирования, выпуска релизов, как устроена инфраструктура проекта, насколько велика роль лидера проекта Тео де Раадта и другие смежные вопросы. Вадим подробно рассказал про устройство пакетов и портов OpenBSD, чем они отличаются от других пакетных систем, как устроен процесс появления нового пакета в дереве портов. Отдельно внимания заслуживает рассказ Вадима о портировании KDE4 в OpenBSD. Так же Вадим рассказал про его небольшие исследования в области автоматической настройки сети, Wi-fi и маршрутизации. Поговорили мы и о областях применения OpenBSD: для кого этот дистрибутив, чем он может быть интересен разработчикам и пользователям, как начать своё участие в проекте. Так же Вадим рассказал про хакатоны OpenBSD: зачем они проводятся, какие цели преследуются, как организовываются и кто принимает в них участие. Кстати, ещё Вадим поделился опытом менторства одного подпроекта в рамках участия OpenBSD в Google Summer of Code. Ссылки на ресурсы по темам выпуска: OpenBSD Events and Papers: https://www.openbsd.org/events.html Презентация Вадима “OpenBSD изнутри”: https://www.openbsd.org/papers/lvee_2016_openbsd_inside/ Презентация Вадима про портирование KDE4 под OpenBSD: https://www.openbsd.org/papers/lvee_2014_winter_kde4/ Презентация “OpenBSD meets 802.11n”: https://www.openbsd.org/papers/eurobsdcon2016-openbsd-11n.pdf Серия презентаций от Marc Espie касаемо портов и пакетов, в хронологическом порядке: https://www.openbsd.org/papers/ven05-espie/ https://www.openbsd.org/papers/eurobsd2012/espie-dpb/index.html https://www.openbsd.org/papers/eurobsdcon2014-parallel-make.pdf

文 | 刘宝辰我们每天上网，用的最多的应用软件之一是浏览器，我们用浏览器看新闻，看视频，基本上，只要是现在上网，大部分人都是使用浏览器。浏览器也有很多，但是，总体上分为四个半流派，第一个是微软公司出的Intenet Explore, 这个占有率很高，尤其是中国的市场上；第二个流派是谷歌公司出的Chome浏览器；第三个流派是Mozilla公司出的Firefox流派；第四个流派是苹果公司出的Safari；第五个流派是Opera基本上就是这些吧。有同学可能问，我从来不用上面这些浏览器，我用的是360浏览器，QQ浏览器或者各种百度全家桶浏览器，其实，这些有中国特色的自主研发的软件，都是基于以上我说的那些浏览器来改版的。比如说加了一个外壳，让浏览器可以记录密码，同步书签等功能。我这次节目不做浏览器的测评，不评价哪个浏览器好用，主要是讲浏览器的一个工作原理。以前我做过一期，名字叫钻钻牛角尖，电脑开机开了啥。那一期是研究电脑开机的，结果，有人告诉我没必要这么复杂，装个360软件，就能加速电脑开机。而且我还和那个朋友争吵了一下，最后不欢而散吧。我这一期节目，没啥用处，即使研究浏览器的原理，也不会让上网速度变快。这只是一个程序员的怪癖，我就是喜欢研究这种东西。以后我还会讲各种音频格式之间的差别，各种图片格式之间的差别，各种视频格式之间的差别，还有各种自拍加的滤镜的工作原理等等，怎么说的，研究这个并没有卵用，只是我自己的业余爱好，希望不喜欢听的同学不要去留言说，你研究这个有啥用了，我也知道，真的没啥用。因为我上一次做电脑开机的那个音频，非得有人去问研究这个能让电脑变快么？如果不能，还不如装个360一键加速呢...在这个节目里，主要讲两个浏览器，一个是Firefox，一个是chrome和safari和Opera。至于为什么把chrome和safari还有Opera放在一起讲呢?那是因为这三个浏览器用的是相同的排版引擎，是苹果的WebKit，是开源的。其实这个项目最初也不是苹果原创的，而是苹果基于另一个开源项目，那个开源项目是KDE的HTML排版引擎，名字叫KHTML，还有一个KDE的另一个Javascript引擎，名字叫KJS。苹果公司开始的时候是基于这两个开源项目，做出了自己的项目，名字分别是WebCore，这个对应于KDE的KHTML，另一个项目叫JavascriptCore，这个对应于KDE的KJS这个项目。这个两个项目的目的是可以移植到OS X系统上，毕竟人家苹果是商业公司，而且苹果做的事情非常的合乎法律，给KDE的KHTML和KJS也作出了不少的技术改进，然后KDE的这两个项目，也获益匪浅吧，起码开始的时候是这样。如果用过苹果电脑的同学，尤其是早期的苹果电脑，苹果电脑上是没有一个特别靠谱的浏览器，这东西可能是不太容易做。苹果电脑上一度装微软出的InternetExplore 5浏览器，其实微软和苹果之间，有说不清道不明的爱慕关系，经常互相帮助，相爱相杀。苹果公司就基于这两个东西，然后就推出了自己的浏览器，也就是safari浏览器，，2003年发布的，safari浏览器。这个浏览器我用过，因为那时候我正在读本科，要去做实验，学校的实验室里新买了一批设备，这批设备需要处理数据的就是一台iMac，当年是新款的，那也是我第一次使用苹果电脑。刚开始感觉并不好用。现在记忆最深刻的就是这台苹果电脑，还有一台离心机，非常大的离心机，可能得有直径1米多，然后我有个同学突发奇想，把刚洗过的衬衫塞进去，想看看能不能把衣服甩干，然后甩了10来分钟，衬衫甩成了破布，已经不能穿了。实验室去了好几年，结果，就记住了这两件事情，一台苹果电脑，一个离心机，其它的都忘记了。继续来说苹果，然后苹果对webkit的改进越来越多，和开源社区也就越走越远，再后来，就彻底分手了。这个分手只是和KHTML那个项目分手了，具体的分手过程，我记得KDE的一个开发者曾经写过一个文章，来吐槽这件事情，当年在开源届也算引起过不大不小的轰动，甚至让Apple公司吓得赶紧联系KHTML的开发者，看看还能不能复婚，别那么快离婚。后来KHTML这个项目确实又从Apple中接受了不少新的特性，来改进KHTML的渲染速度。但是，我猜测的一个原因，Apple是商业公司，KDE是开源组织，商业组织是向钱看，我说的向钱看是金钱的钱，开源组织是不太注重金钱驱动的，结果呢，这些开源的项目因为不赚钱，大家紧张了一阵子，又开始跟不上苹果的节奏了，因为商业公司的项目推进能力，远远高于开源组织，结果，最后还是闹分手了。其实，开源组织有时候吧，赚不到钱，只能兼职做做，很多时候项目的质量并没有商业公司高，在后来，Apple的webkit在很多方面全面超越了KHTML。当然，KDE也知道这件事儿，从KDE4.5开始，KDE就已经使用苹果的webkit这个开源组件，当然了，开源的那个KHTML还是继续开发，也继续用在KDE上吗。苹果也在继续开发webkit，开发的成果也继续开源。可能有很多人觉得，苹果太尼玛封闭了，其实不是的，苹果是个商业公司，他肯定首先考虑的是商业利益，如果开源能获得巨大的商业利益，他肯定开源，所以，苹果开源了几个大杀器，黑科技。其中我知道的几个有前面我说的这个webki，还有一个大杀器是llvm，这个项目也极其重要，既然说到这里了，我就稍微的说一下，llvm呢，是一个开源的编译器项目，是C++写的。以前，包括现在，最重要的开源的编译器是gcc，就是理查德斯托曼做的那个gcc项目，曾经，gcc是开源届的核心地位，现在也差不多，因为几乎所有的开源软件，都需要使用gcc来编译成二进制代码，然后，这个组织脾气不太好，基本上处于那个地位，可能总是有缺点吧，而且处于核心地位，缺点也容易被放大，gcc可以说是在所有开源项目中，受到的批评最多的一个，比linux都多。但是，即使收到批评，你还不得不用它，苹果就是这样，给gcc捐献了大笔的钞票，没啥效果，因为有求于gcc的，可不止苹果一家。然后，苹果公司就搞了一个LLVM项目，来代替gcc在开源中的地位，LLVM是一个简称，全称是Low Level Vitual Machine，全称没啥人知道，我也是google一下，才敢写在这里。然后，LLVM太重要了，还获得了ACM颁发的一个大奖，来奖励Apple开源的这个LLVM项目。然后Apple率先垂范，把Gcc从默认编译器的位置拉了下来。因为Gcc这个项目组，和其它大的开源项目组，之间的龌龊事情也不少，比如FreeBSD项目也是早就看Gcc不爽了，但是，苦于自己没有编译器，只能忍气吞声，结果LLVM一出来，FreeBSD马上就把GCC给集成进来的，然后，一个以前看起来非常狂妄自大的计划被FreeBSD提上了日程，不光gcc，而是要把所有GNU组件都替换出来，然后就有了lldb, libc,compiler-rt这一系列项目，个人觉得，以FreeBSD社区那种比较高贵的气质，完全替换掉GNU项目，是有很大可能的。这一切，都是Apple花了5年时间，搞出来了一个LLVM，然后把这个编译器项目开源的原因。llvm的logo是我最喜欢的logo稍微跑了一下题，拐到编译器上了，再强行拐回来，继续说Apple这个webkit。苹果继续改进webkit，然后webkit也就越来越好用，速度越来越快，然后呢，另一家公司叫Google，也打算做个浏览器，二话不说，直接把苹果开源的这个引擎webkit拿过来就用，这是合乎法律的，因为开源么。然后一贯嘴上说不作恶的google公司实际上恶心事儿也干过不少的google和一贯表面非常高冷但是私底下对政府部门低三下四的apple公司又杠上了。chrome继承了apple公司的webkit，然后加以改进，把认为不行的代码丢了，尤其是javascript的部分，用了自己引以为豪的v8引擎，这个v8引擎的横空出世，让很多人也是惊讶的不行，然后javascript开始从前端到后段，差点儿通吃。让不少程序员惊呼，我操，js这是要上天么？然后，后来发现这种担心是多余的，因为前段进入了百花齐放的时代，每年都会出现至少365个javascript写的库，每天一个吧，然后循环往复，至今已经持续了好几年了。这个话题太容易引起争端，那个前端库更好呢？这个得看情况，因为一旦争论结束，又会出现更多新的js库，没办法，程序员就是这么搞笑，还是老老实实的用php这个世界上最好的语言靠谱。然后google的chrome是世界上占有率第一的浏览器，由于在中国某种神秘的力量，chrome的占有率很可能是倒数第一，如果你看到有人用chrome，很可能他就是个程序员。接下来，还有一个更小众的浏览器，他的名字叫Opera，据说已经被中国的360公司收购了，这家公司浏览器的引擎，也是webkit。因此，chrome/safari/opera，这三个浏览器，在渲染方面，大同小异，来自一个妈。另外一个分支就是大名鼎鼎的火狐浏览器，Firefox，这个在国内可能用的人也不多，如果你看到有人用firefox，可能，也是个程序员，如果你看到桌面上有三四个浏览器，并且同时使用，那100%是个前端程序员，尤其是你看到有人还在测试Internet Explorer 6这个浏览器，那100%是个给中国国企开发软件的前端程序员，中国国企和IE6这个浏览器，已经水乳交融，今生今世都不再分离了，即使这个浏览器已经15岁了，15岁，在IT行业，和永远一样远。但是，大型国企爱IE6，比如说，在2016年，我看到过某大型钢铁企业，赫然写着网站要支持IE6，真是让我百思不得其解的一件事情。火狐浏览器用的引擎的名字叫Gecko, 这个软件，曾经一度讨论要不要也把引擎换成webkit，最后，还是继续用这个Gecko，在英语中是壁虎的意思。好了，背景就介绍到这里，微软的不考虑了，他有自己独特的渲染引擎，但是，可以研究他家引擎源代码的，就是微软的人，网上可以找到的材料并不多。这里只讲这两个引擎，一个是webkit，用这个引擎的有三个浏览器，chrome，safari和opera；还有一个是Gecko，用这个引擎的是Firefox。·这些浏览器虽然各不相同，但是作用是类似的，就是能把你要求的东西显示出来，并且，不同的浏览器，显示的样子大同小异，稍微的有一些不同。因为不同的厂商出品的浏览器，是有一些细微的不同。之所以能显示的大同小异，是因为，这些厂商都要遵守一个协议，这些标准就是HTML和CSS，这些标准由一个公益组织来管理，这个公益组织的名字叫W3C，中文名叫万维网联盟来维护。我们上网的过程，就是把HTML和CSS的内容从网站上下载下来，然后将这些内容解析以后，显示在屏幕上。这个过程，需要用到的核心技术就是我上面所提到的两个引擎，webkit和Gecko的工作。负责显示请求的内容，把网站上下载下来的HTML和CSS，解析以后，展现出来。我对这个过程非常的好奇，好多年前，我就对浏览器是如何工作的非常的好奇，然后就研究了一下，自以为可以把自己给糊弄过去了，因此，我就说一下那两个引擎的工作原理。主要的流程是这样的，显示引擎会从网络层请求需要显示的文档，然后引擎开始工作。因为所有的网页都是HTML和CSS文档，引擎开始解析这个HTML文档，将整个文档解析成两棵树,一棵树叫内容树，这棵树上的节点是HTML的标记。还有一棵树叫呈现树，这棵树势解析样式元素，呈现树是节点的样式，比如字体的大小，颜色等等。呈现树主要是带有视觉属性比如颜色啊，尺寸啊，背景等等的一些矩形，这些矩形呢，就按照一定的顺序显示在屏幕上。当这个视觉效果显示出来以后，也就是一些矩形。再进入下一个阶段，就是将内容树的节点，计算一个坐标，每个节点都有一个独一无二的位置。有了这两个信息，再然后就是根据这两个信息，把内容绘制到屏幕上，引擎会遍历整棵树，然后将树上的每个节点，都画在屏幕上。web browser architecture为了能有更好的用户体验，引擎肯定是将内容以最快的速度画到屏幕上，而不是等所有的内容都下载完毕，才开始绘图，那样是非常影响用户体验的。所以，我们经常会碰到这种情况，某个地方的图片还没有显示出来，只显示一个空白，文字比图片更快的显示出来。这是一种特征，不是bug。引擎不是等所有的HTML文档都解析完毕以后，才开始绘制，如果那样，碰到一个网速很慢的，网页很大的，黄花菜都凉了，那样会非常的影响用户体验。正确的展示流程是，有多少显示多少，只要有内容过来，就赶紧的先给用户看一点，不必等所有内容都下载完成。那是不是webkit和Gecko是一样的呢？当然不是一样的，如果是一样的，那何必还要两个引擎呢？但是这两个引擎所采用的方法肯定不会有质的差别，如果有质的差别，两个都是开源的项目，那开发人员早就抄袭了，显然，这两个引擎所采用的方法大同小异。接下来呢，我要具体的描述这两个引擎所采用的方法。在讲技术之前，先得讲一个网页的技术，叫DOM，这个做前端的程序员肯定都是知道的，Web就是基于DOM的，比如说现在前端用的最多的一个javascript库叫jQuery，这个库本质上就是一个操作DOM的工具，这个库现在是越来越大，1.8的时候，原始大小200多K，优化以后也得100来k，其实这样挺大的，尤其是考虑到大部分人用jQuery就是实现了1-2个效果，结果让自己的网页增加了100多K，想想我这个不是前端的程序员，就很不爽，当然也有解决方案，比如zepto.js就是解决这个问题的，只增加了20多k。那唠叨了这么多，到底什么是DOM呢？这是一个英文的缩写，全称是Document Object Model。我们可以把DOM看作是节点，每个节点就是一个HTML的标签，那如何解析成树呢？这就是一个编译原理的问题了。还记得前面我讲苹果开源的那个LLVM么？那就是编译器，因为我试图把这个问题讲清楚，起码能加深我自己的印象，这次的时间又到了，下次，我要讲如何把HTML文档解析成一棵树，期间会用到编译器的知识，就是解析器和词法分析器。好了，下次再见。如果你喜欢我讲的这种钻牛角尖的内容，欢迎关注我的微信公众号——软件那些事儿——我这个公众号不扰民，每周推送一次，每次的观看量大概是300次左右。

This week on the show, it's all about Lumina. We'll be giving you a visual walkthrough of the new BSD-exclusive desktop environment, as well as chatting with the main developer. There's also answers to your emails and all the latest news, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines Portscout ported to OpenBSD (http://blog.jasper.la/portscout-for-openbsd/) Portscout is a popular utility used in the FreeBSD ports infrastructure It lets port maintainers know when there's a new version of the upstream software available by automatically checking the distfile mirror Now OpenBSD porters can enjoy the same convenience, as it's been ported over You can view the status online (http://portscout.jasper.la/) to see how it works and who maintains what (http://portscout.jasper.la/index-total.html) The developer who ported it is working to get all the current features working on OpenBSD, and added a few new features as well He decided to fork and rename it (https://jasperla.github.io/portroach/) a few days later *** Sysadmins and systemd refugees flocking to BSD (https://www.reddit.com/r/freebsd/comments/2fgb90/you_have_your_windows_in_my_linux_or_why_many/) With all the drama in Linux land about the rapid changes to their init system, a lot of people are looking at BSD alternatives This "you got your Windows in my Linux (http://www.infoworld.com/d/data-center/you-have-your-windows-in-my-linux-249483)" article (and accompanying comments) give a nice glimpse into the minds of some of those switchers Both server administrators and regular everyday users are switching away from Linux, as more and more distros give them no choice but to use systemd Fortunately, the BSD communities are usually very welcoming of switchers - it's pretty nice on this side! *** OpenBSD's versioning schemes (http://www.tedunangst.com/flak/post/OpenBSD-version-numbers) Ted Unangst explains the various versioning systems within OpenBSD, from the base to libraries to other included software In contrast to FreeBSD's release cycle, OpenBSD isn't as concerned with breaking backwards compatibility (but only if it's needed to make progress) This allows them to innovate and introduce new features a lot more easily, and get those features in a stable release that everyone uses He also details the difference between branches, their errata system and lack of "patch levels" for security Some other things in OpenBSD don't have version numbers at all, like tmux "Every release adds some new features, fixes some old bugs, probably adds a new bug or two, and, if I have anything to say about it, removes some old features." *** VAXstation 4000 Model 90 booting NetBSD (https://www.youtube.com/watch?v=zLsgFPaMPyg) We found a video of NetBSD booting on a 22 year old VAX workstation, circa 1992 This system has a monstrous 71 MHz CPU and 128MB of ECC RAM It continues in part two (https://www.youtube.com/watch?v=YKzDXKmn66U), where we learn that it would've cost around $25,000 when it was released! The uploader talks about his experiences getting NetBSD on it, what does and doesn't work, etc It's interesting to see that such old hardware isn't necessarily obsolete just because newer things have come out since then (but maybe don't try to build world on it...) *** Interview - Ken Moore - ken@pcbsd.org (mailto:ken@pcbsd.org) The Lumina desktop environment Special segment Lumina walkthrough News Roundup Suricata for IDS on pfSense (http://pfsensesetup.com/suricata-intrusion-detection-system-part-one) While most people are familiar with Snort as an intrusion detection system, Suricata is another choice This guide goes through the steps of installing and configuring it on a public-facing pfSense box Part two (http://pfsensesetup.com/suricata-intrusion-detection-system-part-two/) details some of the configuration steps One other cool thing about Suricata - it's compatible with Snort rules, so you can use the same updates There's also another recent post (http://www.allamericancomputerrepair.com/Blog/Post/29/Install-Snort-on-FreeBSD) about snort as well, if that's more your style If you run pfSense (or any BSD) as an edge router for a lot of users, this might be worth looking into *** OpenBSD's systemd API emulation project (http://bsd.slashdot.org/story/14/09/08/0250207/gsoc-project-works-to-emulate-systemd-for-openbsd) This story was pretty popular in the mainstream news this week For the Google Summer of Code, a student is writing emulation wrappers for some of systemd's functions (https://twitter.com/blakkheim/status/509092821773848577) There was consideration from some Linux users to port over the finished emulation back to Linux, so they wouldn't have to run the full systemd One particularly interesting Slashdot comment snippet (http://bsd.slashdot.org/comments.pl?sid=5663319&cid=47851361): "We are currently migrating a large number (much larger than planned after initial results) of systems from RHEL to BSD - a decision taken due to general unhappiness with RHEL6, but SystemD pushed us towards BSD rather than another Linux distro - and in some cases are seeing throughput gains of greater than 10% on what should be equivalent Linux and BSD server builds. The re-learning curve wasn't as steep as we expected, general system stability seems to be better too, and BSD's security reputation goes without saying." It will NOT be in the base system - only in ports, and only installed as a dependency for things like newer GNOME (http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-3-14-and-beyond/) that require such APIs In the long run, BSD will still be safe from systemd's reign of terror, but will hopefully still be compatible with some third party packages like GNOME that insist on using it *** GhostBSD 4 previewed (http://www.linuxbsdos.com/2014/05/19/preview-of-ghostbsd-4-0/) The GhostBSD project is moving along, slowly getting closer to the 4 release This article shows some of the progress made, and includes lots of screenshots and interesting graphical frontends If you're not too familiar with GhostBSD, we interviewed the lead developer (http://www.bsdnow.tv/episodes/2014_03_12-ghost_of_partition) a little while back *** NetBSD on the Banana Pi (http://rizzoandself.blogspot.com/2014/09/netbsd-on-banana-pi.html) The Banana Pi is a tasty alternative to the Raspberry Pi, with similar hardware specs In this blog post, a NetBSD developer details his experiences in getting NetBSD to run on it After studying how the prebuilt Linux image booted, he made some notes and started hacking Ethernet, one of the few things not working, is being looked into and he's hoping to get it fully supported for the upcoming NetBSD 7.0 They're only about $65 as of the time we're recording this, so it might be a fun project to try *** Feedback/Questions Antonio writes in (http://slexy.org/view/s28iKdBEbm) Garegin writes in (http://slexy.org/view/s21Wfnv87h) Erno writes in (http://slexy.org/view/s2Fzryxhdz) Brandon writes in (http://slexy.org/view/s2ILcqdFfF) ***

Este es el repost del episodio 19 de OPSL. El tema que se trató en este episodio fue: - KDE 4 y notas* Experiencia de Quique Marzo instalando KDE4* Mis comentarios sobe KDE 4* Noticias linuxeras por Valente EspinosaEnlaces a los audios:Episodio 19 Repost MP3Episodio 19 Repost OGGTienes algo que decir? Deja tu comentario!

Daniel Molkentin ist Softwareentwickler und wirkt im Team des KDE-Projekt mit. Im Gespräch mit Tim Pritlove erläutert er die Neuerungen in der aktuellen Version 4.0 und dem KDE zugrunde liegenden Framework QT4. Im Verlauf wird auch die geplante Umstellung von KDE und QT von KHTML auf WebKit diskutiert, das Apple vor einigen Jahren auf Basis von KHTML entwickelt und später als Open Source Projekt veröffentlicht hat und die Applikationen, die für KDE4 verfügbar sind oder sein werden.