Language Selection

English French German Italian Portuguese Spanish

BSD

Audiocasts/Shows: Ubuntu Podcast, BSD Now and Bad Voltage

Filed under
GNU
Linux
BSD
Ubuntu
  • Ubuntu Podcast from the UK LoCo: S13E16 – Owls

    This week we’ve been re-installing Ubuntu 20.04. Following WWDC, we discuss Linux Desktop aspirations, bring you some command line love and go over all your wonderful feedback.

    It’s Season 13 Episode 16 of the Ubuntu Podcast! Alan Pope, Mark Johnson and Martin Wimpress are connected and speaking to your brain.

  • BSD Now 358: OpenBSD Kubernetes Clusters

    Yubikey-agent on FreeBSD, Managing Kubernetes clusters from OpenBSD, History of FreeBSD part 1, Running Jitsi-Meet in a FreeBSD Jail, Command Line Bug Hunting in FreeBSD, Game of Github, Wireguard official merged into OpenBSD, and more

  • Bad Voltage 3×08: Petrichoronavirus

NomadBSD 1.3.2 is now available!

Filed under
BSD

We are pleased to present the release of NomadBSD 1.3.2.

Read more

TrueNAS 12.0-BETA1 Release Announcement

Filed under
Hardware
BSD

FreeNAS (and now TrueNAS) Fans! I'm pleased to announce the availability of our first BETA1 for the upcoming 12.0 TrueNAS CORE / Enterprise release.

Read more

Also: TrueNAS 12 Beta 1 Released With Much Improved ZFS, Better AMD Ryzen CPU Support

Audiocasts/Shows: BSD Now, Self-Hosted, Ubuntu Podcast and TLLTS

Filed under
GNU
Linux
BSD

Audiocasts/Shows: BSD Now, Bad Voltage and The Linux Link Tech Show (TLLTS)

Filed under
GNU
Linux
BSD

Getting Started with NetBSD on the Pinebook Pro

Filed under
BSD

If you buy a Pinebook Pro now, it comes with Manjaro Linux on the internal eMMC storage. Let’s install NetBSD instead!

The easiest way to get started is to buy a decent micro-SD card (what sort of markings it should have is a science of its own, by the way) and install NetBSD on that. On a warm boot (i.e. when rebooting a running system), the micro-SD card has priority compared to the eMMC, so the system will boot from there.

Read more

WireGuard Support Merged Into Upstream OpenBSD

Filed under
BSD

Following WireGuard being merged into Linux 5.6, the attention turned in recent months by WireGuard developers onto seeing their kernel port upstreamed in OpenBSD. As of this weekend, the WireGuard upstreaming in OpenBSD is their latest accomplishment.

It was just last month we reported on the WireGuard port to the OpenBSD kernel and their hopes of upstreaming it. That goal has already been reached as of today.

Read more

FreeBSD 11.4-RELEASE Announcement

Filed under
BSD

The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 11.4-RELEASE. This is the fifth and final release of the stable/11 branch.

Read more

OpenZFS removed offensive terminology from its code

Filed under
BSD

On Wednesday evening, ZFS founding developer Matthew Ahrens submitted what should have been a simple, non-controversial pull request to the OpenZFS project: wherever possible without causing technical issues, the patch removed references to "slaves" and replaced them with "dependents."

This patch in question doesn't change the way the code functions—it simply changes variable names in a way that brings them in conformance with Linux upstream device-mapper terminology, in 48 total lines of code (42 removed and 48 added; with one comment block expanded slightly to be more descriptive).

But this being the Internet, unfortunately, outraged naysayers descended on the pull request, and the comments were quickly closed to non-contributors. I first became aware of this as the moderator of the r/zfs subreddit where the overflow spilled once comments on the PR itself were no longer possible.

Read more

New FreeBSD code of conduct

Filed under
BSD
  • New FreeBSD code of conduct
    Dear FreeBSD community,
    
    The FreeBSD Project has adopted a new LLVM-derived code of conduct.  The
    new code of conduct can be found at
    
    https://www.freebsd.org/internal/code-of-conduct.html
    
    BACKGROUND
    
    Active FreeBSD developers were invited to complete two surveys related
    to our Code of Conduct.
    
    The first survey, conducted in 2018, told us that:
    
       - 94% of developers believe respectful communication in the project
         is important; 1% disagreed
    
       - 89% believe FreeBSD should be welcoming to people of all
         backgrounds; 2% disagreed
    
       - 73% say toxic people should be removed from the Project regardless
         of their technical contribution; 9% disagreed
    
       - 35% were dissatisfied with the code of conduct adopted in 2018, 34%
         were neutral, and 30% were satisfied.
    
    These results indicated that there was sufficient dissatisfaction with
    the current code of conduct to warrant investigation.  After reviewing
    other open source codes of conduct, the FreeBSD Core Team investigated
    adopting either an LLVM-derived or a Go-derived code of conduct.
    
    A second survey was held at the start of June and had only one question:
    
      Which code of conduct should FreeBSD adopt?
    
       - An LLVM-derived code of conduct:
         https://github.com/freebsd/core.10-public-docs/blob/master/CoC/llvm-based.md
    
       - A Go-Derived code of conduct:
         https://github.com/freebsd/core.10-public-docs/blob/master/CoC/golang-based.md
    
       - Retain the current code of conduct:
         https://web.archive.org/web/20200108075747/https://www.freebsd.org/internal/code-of-conduct.html
    
    RESULTS
    
       -  4% favoured keeping the current code of conduct
    
       - 33% favoured the Go-derived code of conduct
    
       - 63% favoured the LLVM-derived code of conduct.
    
    Thus, the Core Team, following the preference of a majority of active
    FreeBSD developers, adopted the LLVM-derived code of conduct.
    
    THANK YOU
    
    Thank you to the LLVM and Go communities, and our impassioned members
    who helped champion this evolution.
    
    -- 
    FreeBSD Core Team
    
  • FreeBSD Adopts A New Code of Conduct Based On The LLVM CoC

    Following a survey of FreeBSD developers gauging interest in a new Code of Conduct and then a follow-up survey of keeping their current CoC versus adopting one similar to the LLVM or Go projects, FreeBSD has now settled on a new document.

    Some 35% of the FreeBSD developer community was dissatisfied with their 2018 Code of Conduct, 34% were neutral, and only 30% satisfied so they set out to adopt a new CoC.

Syndicate content

More in Tux Machines

NanoPi NEO3 Headless SBC Launched for $20 and up

Last month, we found out FriendlyELEC was working on NanoPi NEO3, a tiny SBC powered by Rockchip RK3328 processor and made for headless applications and networked storage thanks to Gigabit Ethernet and USB 3.0 ports, as well as a 26-pin GPIO header. At the time, the board was still been finalized, but the company has now started to take orders for $20 and up depending on options which include a cute white enclosure... [...] The Wiki has been updated as well, and the company provides both Ubuntu Core 18.04 based FriendlyCore, and OpenWrt based FriendlyWrt operating systems for the board with both relying on Linux 5.4.12 kernel. I’d also expect Armbian to eventually provide Ubuntu 20.04 and Debian 10 images. Read more

Moving (parts of) the Cling REPL in Clang

Motivation
===

Over the last decade we have developed an interactive, interpretative 
C++ (aka REPL) as part of the high-energy physics (HEP) data analysis 
project -- ROOT [1-2]. We invested a significant  effort to replace the 
CINT C++ interpreter with a newly implemented REPL based on llvm -- 
cling [3]. The cling infrastructure is a core component of the data 
analysis framework of ROOT and runs in production for approximately 5 
years.

Cling is also  a standalone tool, which has a growing community outside 
of our field. Cling’s user community includes users in finance, biology 
and in a few companies with proprietary software. For example, there is 
a xeus-cling jupyter kernel [4]. One of the major challenges we face to 
foster that community is  our cling-related patches in llvm and clang 
forks. The benefits of using the LLVM community standards for code 
reviews, release cycles and integration has been mentioned a number of 
times by our "external" users.

Last year we were awarded an NSF grant to improve cling's sustainability 
and make it a standalone tool. We thank the LLVM Foundation Board for 
supporting us with a non-binding letter of collaboration which was 
essential for getting this grant.


Background
===

Cling is a C++ interpreter built on top of clang and llvm. In a 
nutshell, it uses clang's incremental compilation facilities to process 
code chunk-by-chunk by assuming an ever-growing translation unit [5]. 
Then code is lowered into llvm IR and run by the llvm jit. Cling has 
implemented some language "extensions" such as execution statements on 
the global scope and error recovery. Cling is in the core of HEP -- it 
is heavily used during data analysis of exabytes of particle physics 
data coming from the Large Hadron Collider (LHC) and other particle 
physics experiments.


Plans
===

The project foresees three main directions -- move parts of cling 
upstream along with the clang and llvm features that enable them; extend 
and generalize the language interoperability layer around cling; and 
extend and generalize the OpenCL/CUDA support in cling. We are at the 
early stages of the project and this email intends to be an RFC for the 
first part -- upstreaming parts of cling. Please do share your thoughts 
on the rest, too.


Moving Parts of Cling Upstream
---

Over the years we have slowly moved some patches upstream. However we 
still have around 100 patches in the clang fork. Most of them are in the 
context of extending the incremental compilation support for clang. The 
incremental compilation poses some challenges in the clang 
infrastructure. For example, we need to tune CodeGen to work with 
multiple llvm::Module instances, and finalize per each 
end-of-translation unit (we have multiple of them). Other changes 
include small adjustments in the FileManager's caching mechanism, and 
bug fixes in the SourceManager (code which can be reached mostly from 
within our setup). One conclusion we can draw from our research is that 
the clang infrastructure fits amazingly well to something which was not 
its main use case. The grand total of our diffs against clang-9 is: `62 
files changed, 1294 insertions(+), 231 deletions(-)`. Cling is currently 
being upgraded from llvm-5 to llvm-9.

A major weakness of cling's infrastructure is that it does not work with 
the clang Action infrastructure due to the lack of an 
IncrementalAction.  A possible way forward would be to implement a 
clang::IncrementalAction as a starting point. This way we should be able 
to reduce the amount of setup necessary to use the incremental 
infrastructure in clang. However, this will be a bit of a testing 
challenge -- cling lives downstream and some of the new code may be 
impossible to pick straight away and use. Building a mainline example 
tool such as clang-repl which gives us a way to test that incremental 
case or repurpose the already existing clang-interpreter may  be able to 
address the issue. The major risk of the task is avoiding code in the 
clang mainline which is untested by its HEP production environment.
There are several other types of patches to the ROOT fork of Clang, 
including ones  in the context of performance,towards  C++ modules 
support (D41416), and storage (does not have a patch yet but has an open 
projects entry and somebody working on it). These patches can be 
considered in parallel independently on the rest.

Extend and Generalize the Language Interoperability Layer Around Cling
---

HEP has extensive experience with on-demand python interoperability 
using cppyy[6], which is built around the type information provided by 
cling. Unlike tools with custom parsers such as swig and sip and tools 
built on top of C-APIs such as boost.python and pybind11, cling can 
provide information about memory management patterns (eg refcounting) 
and instantiate templates on the fly.We feel that functionality may not 
be of general interest to the llvm community but we will prepare another 
RFC and send it here later on to gather feedback.


Extend and Generalize the OpenCL/CUDA Support in Cling
---

Cling can incrementally compile CUDA code [7-8] allowing easier set up 
and enabling some interesting use cases. There are a number of planned 
improvements including talking to HIP [9] and SYCL to support more 
hardware architectures.



The primary focus of our work is to upstreaming functionality required 
to build an incremental compiler and rework cling build against vanilla 
clang and llvm. The last two points are to give the scope of the work 
which we will be doing the next 2-3 years. We will send here RFCs for 
both of them to trigger technical discussion if there is interest in 
pursuing this direction.


Collaboration
===

Open source development nowadays relies on reviewers. LLVM is no 
different and we will probably disturb a good number of people in the 
community ;)We would like to invite anybody interested in joining our 
incremental C++ activities to our open every second week calls. 
Announcements will be done via google group: compiler-research-announce 
(https://groups.google.com/g/compiler-research-announce).



Many thanks!


David & Vassil

Read more Also: Cling C++ Interpreter Looking To Upstream More Code Into LLVM

This week in KDE: New features galore!

Tons and tons of awesome new features and UI polish landed this week, alongside an equally weighty ton of important bugfixes. Read more

Elive 3.8.14 beta released

The Elive Team is proud to announce the release of the beta version 3.8.14 This new version includes: Kernel updated to 5.6.14 retrowave special theme themes, designs, icons improvements and more customizations included bootup with a much more friendly graphical menu, it now remembers your last selected OS, all the options are in the same menu instead of submenus, disabled useless recovery options, improved resolution, fixed wallpaper issue on encrypted installations SWAP space is much more performant now, feedbacks welcome Read more