Podcasts about llvm clang

  • 5PODCASTS
  • 22EPISODES
  • 57mAVG DURATION
  • ?INFREQUENT EPISODES
  • Feb 11, 2022LATEST

POPULARITY

20172018201920202021202220232024


Best podcasts about llvm clang

Latest podcast episodes about llvm clang

CppCast
5G Network Computing with Yacob Cohen-Arazi

CppCast

Play Episode Listen Later Feb 11, 2022 52:30


Yacob Cohen-Arazi joins Rob and Jason. They first talk about an update to Microsoft's GSL library and the upcoming LLVM v14. Then they talk to Kobi about work he's done at Qualcomm with 5G networks and how 5G is about a lot more then just bandwidth improvements. News GSL 4.0.0 is Available Now gsl-lite I don't know which container to use (and at this point I'm too afraid to ask) LLVM/Clang 14 ends Feature Development with better C++20 support, Armv9 Links San Diego C++ Qualcomm Careers Sponsors Use code JetBrainsForCppCast during checkout atJetBrains.com for a 25% discount  

BSD Now
401: OpenBSD Dog Garage

BSD Now

Play Episode Listen Later May 6, 2021 58:03


Dog's Garage Runs OpenBSD, EuroBSDcon 2021 Call for Papers, FreeBSD’s iostat, The state of toolchains in NetBSD, Bandwidth limiting on OpenBSD 6.8, FreeBSD's ports migration to git and its impact on HardenedBSD, TrueNAS 12.0-U3 has been released, and more. NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/bsdnow) Headlines My Dog's Garage Runs OpenBSD (https://undeadly.org/cgi?action=article;sid=20210415055717) I was inspired by the April 2017 article in undeadly.org about getting OpenBSD running on a Raspberry Pi 3B+. My goal was to use a Raspberry Pi running OpenBSD to monitor the temperature in my garage from my home. My dog has his own little "apartment" inside the garage, so I want to keep an eye on the temperature. (I don't rely on this device. He sleeps inside the house whenever he wants.) EuroBSDcon 2021 Call for Papers (https://2021.eurobsdcon.org/about/cfp/) FreeBSD iostat (https://klarasystems.com/articles/freebsd-iostat-a-quick-glance/) The state of toolchains in NetBSD (https://www.cambus.net/the-state-of-toolchains-in-netbsd/) While FreeBSD and OpenBSD both switched to using LLVM/Clang as their base system compiler, NetBSD picked a different path and remained with GCC and binutils regardless of the license change to GPLv3. However, it doesn't mean that the NetBSD project endorses this license, and the NetBSD Foundation's has issued a statement about its position on the subject. NetBSD’s statement (http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/README?rev=1.1) *** News Roundup Bandwidth limiting on OpenBSD 6.8 (https://dataswamp.org/~solene/2021-02-07-limit.html) I will explain how to limit bandwidth on OpenBSD using its firewall PF (Packet Filter) queuing capability. It is a very powerful feature but it may be hard to understand at first. What is very important to understand is that it's technically not possible to limit the bandwidth of the whole system, because once data is getting on your network interface, it's already there and got by your router, what is possible is to limit the upload rate to cap the download rate. FreeBSD's ports migration to git and its impact on HardenedBSD (https://hardenedbsd.org/article/shawn-webb/2021-04-06/freebsds-ports-migration-git-and-its-impact-hardenedbsd) FreeBSD completed their ports migration from subversion to git. Prior to the official switch, we used the read-only mirror FreeBSD had at GitHub[1]. The new repo is at [2]. A cursory glance at the new repo will show that the commit hashes changed. This presents an issue with HardenedBSD's ports tree in our merge-based workflow. TrueNAS 12.0-U3 has been released (https://www.truenas.com/docs/releasenotes/core/12.0u3/) iXsystems is excited to announce TrueNAS 12.0-U3 was released today and marks an important milestone in the transition from FreeNAS to TrueNAS. TrueNAS 12.0 is now considered by iXsystems to be a higher quality release than FreeNAS 11.3-U5, our previous benchmark. The new TrueNAS documentation site has also reached a point where it has more content and capabilities than FreeNAS. TrueNAS 12.0 is ready for mission-critical enterprise deployments. Beastie Bits Joyent provides pkgsrc for MacOS X (https://pkgsrc.joyent.com/install-on-osx/) Archives of old Irix documentation (https://techpubs.jurassic.nl) FreeBSD Developer/Vendor Summit 2021 (https://wiki.freebsd.org/DevSummit/202106) *** 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 Andre - splitting zfs array (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/401/feedback/Andre - splitting zfs array) Bruce - Command Change (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/401/feedback/Bruce - Command Change) Dan - Annoyances with ZFS (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/401/feedback/Dan - Annoyances with ZFS) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) ***

BSD Now
366: Bootloader zpool checkpoints

BSD Now

Play Episode Listen Later Sep 3, 2020 53:02


OpenZFS with ZSTD lands in FreeBSD 13, LibreSSL doc status update, FreeBSD on SPARC64 (is dead), Bringing zpool checkpoints to a FreeBSD bootloader, and more NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/) Headlines OpenZFS with ZSTD land in FreeBSD 13 (https://svnweb.freebsd.org/base?view=revision&revision=364746) ZStandard Compression for OpenZFS (https://github.com/openzfs/zfs/commit/10b3c7f5e424f54b3ba82dbf1600d866e64ec0a0) > The primary benefit is maintaining a completely shared code base with the community allowing FreeBSD to receive new features sooner and with less effort. > I would advise against doing 'zpool upgrade' or creating indispensable pools using new features until this change has had a month+ to soak. Rebasing FreeBSD’s OpenZFS on the new upstream was sponsored by iXsystems The competition of ZSTD support for OpenZFS was sponsored by the FreeBSD Foundation *** LibreSSL documentation status update (https://undeadly.org/cgi?action=article;sid=20200817063735) More than six years ago, LibreSSL was forked from OpenSSL, and almost two years ago, i explained the status of LibreSSL documentation during EuroBSDCon 2018 in Bucuresti. So it seems providing an update might be in order. Note that this is not an update regarding LibreSSL status in general because i'm not the right person to talk about the big picture of working on the LibreSSL code, my work has been quite focussed on documentation. All the same, it is fair to say that even though the number of developers working on it is somewhat limited, the LibreSSL project is quite alive, typically having a release every few months. Progress continues being made with respect to porting and adding new functionality (for example regarding TLSv1.3, CMS, RSA-PSS, RSA-OAEP, GOST, SM3, SM4, XChaCha20 during the last two years), OpenSSL compatibility improvements (including providing additional OpenSSL-1.1 APIs), and lots of bug fixes and code cleanup. FreeBSD on SPARC64 (is dead) (https://eerielinux.wordpress.com/2020/02/15/freebsd-on-sparc64-is-dead/) ’m coming pretty late to the party, because SPARC64 support in FreeBSD is apparently doomed: After the POWER platform made the switch to a LLVM/Clang-based toolchain, SPARC64 is one of the last ones that still uses the ancient GCC 4.2-based toolchain that the project wants to finally get rid off (it has already happened as I was writing this – looks like the firm plan was not so firm after all, since they killed it off early). And compared to the other platforms it has seen not too much love in recent times… SPARC64 being a great platform, I’d be quite sad to see it go. But before that happens let’s see what the current status is and what would need to be done if it were to survive, shall we? News Roundup Bringing zpool checkpoints to a FreeBSD bootloader (https://www.oshogbo.vexillium.org/blog/79/) Almost two years ago I wrote a blog post about checkpoints in ZFS. I didn’t hide that I was a big fan of them. That said, after those two years, I still feel that there are underappreciated features in the ZFS world, so I decided to do something about that. Currently, one of the best practices for upgrading your operating system is to use boot environments. They are a great feature for managing multiple kernels and userlands. They are based on juggling which ZFS datasets are mounted. Each dataset has its own version of the system. Unfortunately, boot environments have their limitations. If we, for example, upgrade our ZFS pool, we may not be able to use older versions of the system anymore. The big advantage of boot environments is that they have very good tools. Two main tools are beadm (which was created by vermaden) and bectl (which currently is in the FreeBSD base system). These tools allow us to create and manage boot environments. Beastie Bits The First Unix Port (https://documents.uow.edu.au/content/groups/public/@web/@inf/@scsse/documents/doc/uow103747.pdf) TLS Mastery updates, August 2020 (https://mwl.io/archives/7346) What is the Oldest BSD Distribution still around today (https://www.youtube.com/watch?v=ww60o940kEk) 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 ben - zfs send questions (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/366/feedback/ben%20-%20zfs%20send%20questions.md) lars - zfs pool question (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/366/feedback/lars%20-%20zfs%20pool%20question.md) neutron - bectl vs beadm (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/366/feedback/neutron%20-%20bectl%20vs%20beadm.md) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv)

BSD Now
338: iocage in Jail

BSD Now

Play Episode Listen Later Feb 20, 2020 62:44


Distrowatch reviews FuryBSD, LLDB on i386 for NetBSD, wpa_supplicant as lower-class citizen, KDE on FreeBSD updates, Travel Grant for BSDCan open, ZFS dataset for testing iocage within a jail, and more. Headlines Distrowatch Fury BSD Review (https://distrowatch.com/weekly.php?issue=20200127#furybsd) FuryBSD is the most recent addition to the DistroWatch database and provides a live desktop operating system based on FreeBSD. FuryBSD is not entirely different in its goals from NomadBSD, which we discussed recently. I wanted to take this FreeBSD-based project for a test drive and see how it compares to NomadBSD and other desktop-oriented projects in the FreeBSD family. FuryBSD supplies hybrid ISO/USB images which can be used to run a live desktop. There are two desktop editions currently, both for 64-bit (x86_64) machines: Xfce and KDE Plasma. The Xfce edition is 1.4GB in size and is the flavour I downloaded. The KDE Plasma edition is about 3.0GB in size. My fresh install of FuryBSD booted to a graphical login screen. From there I could sign into my account, which brings up the Xfce desktop. The installed version of Xfce is the same as the live version, with a few minor changes. Most of the desktop icons have been removed with just the file manager launchers remaining. The Getting Started and System Information icons have been removed. Otherwise the experience is virtually identical to the live media. FuryBSD uses a theme that is mostly grey and white with creamy yellow folder icons. The application menu launchers tend to have neutral icons, neither particularly bright and detailed or minimal. LLDB now works on i386 (http://blog.netbsd.org/tnf/entry/lldb_now_works_on_i386) Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages. In February 2019, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support, extending NetBSD's ptrace interface to cover more register types and fix compat32 issues, fixing watchpoint and threading support. The original NetBSD port of LLDB was focused on amd64 only. In January, I have extended it to support i386 executables. This includes both 32-bit builds of LLDB (running natively on i386 kernel or via compat32) and debugging 32-bit programs from 64-bit LLDB. News Roundup wpa_supplicant is definitely a lower-class citizen, sorry (https://marc.info/?l=openbsd-misc&m=158068418807352&w=2) wpa_supplicant is definitely a lower-class citizen, sorry. I increasingly wonder why this stuff matters; transit costs are so much lower than the period when eduroam was setup, and their reliance on 802.11x is super weird in a world where, for the most part + entire cities have open wifi in their downtown core + edu vs edu+transit split horizon problems have to be solved anyways + many universities have parallel open wifi + rate limiting / fare-share approaches for the open-net, on unmetered + flat-rate solves the problem + LTE hotspot off a phone isn't a rip off anymore + other open networks exist essentially no one else feels compelled to do use 802.11x for a so called "semi-open access network", so I think they've lost the plot on friction vs benefit. (we've held hackathons at EDU campus that are locked down like that, and in every case we've said no way, gotten a wire with open net, and built our own wifi. we will not subject our developers to that extra complexity). KDE FreeBSD Updates Feb 2020 (https://euroquis.nl/freebsd/2020/02/08/freebsd.html) Some bits and bobs from the KDE FreeBSD team in february 2020. We met at the FreeBSD devsummit before FOSDEM, along with other FreeBSD people. Plans were made, schemes were forged, and Groff the Goat was introduced to some new people. The big ticket things: Frameworks are at 5.66 Plasma is at 5.17.5 (the beta 5.18 hasn’t been tried) KDE release service has landed 19.12.2 (same day it was released) Developer-centric: KDevelop is at 5.5.0 KUserfeedback landed its 1.0.0 release CMake is 3.16.3 Applications: Musescore is at 3.4.2 Elisa now part of the KDE release service updates Fuure work: KIO-Fuse probably needs extra real-world testing on FreeBSD. I don’t have that kind of mounts (just NFS in /etc/fstab) so I’m not the target audience. KTextEditor is missing .editorconfig support. That can come in with the next frameworks update, when consumers update anyway. Chasing it in an intermediate release is a bit problematic because it does require some rebuilds of consumers. Travel Grant Application for BSDCan is now open (https://lists.freebsd.org/pipermail/freebsd-announce/2020-February/001929.html) Hi everyone, The Travel Grant Application for BSDCan 2020 is now open. The Foundation can help you attend BSDCan through our travel grant program. Travel grants are available to FreeBSD developers and advocates who need assistance with travel expenses for attending conferences related to FreeBSD development. BSDCan 2020 applications are due April 9, 2020. Find out more and apply at: https://www.freebsdfoundation.org/what-we-do/grants/travel-grants/ Did you know the Foundation also provides grants for technical events not specifically focused on BSD? If you feel that your attendance at one of these events will benefit the FreeBSD Project and Community and you need assistance getting there, please fill out the general travel grant application. Your application must be received 7 weeks prior to the event. The general application can be found here: https://goo.gl/forms/QzsOMR8Jra0vqFYH2 Creating a ZFS dataset for testing iocage within a jail (https://dan.langille.org/2020/02/01/creating-a-zfs-dataset-for-testing-iocage-within-a-jail/) Be warned, this failed. I’m stalled and I have not completed this. I’m going to do jails within a jail. I already do that with poudriere in a jail but here I want to test an older version of iocage before upgrading my current jail hosts to a newer version. In this post: FreeBSD 12.1 py36-iocage-1.2_3 py36-iocage-1.2_4 This post includes my errors and mistakes. Perhaps you should proceed carefully and read it all first. Beastie Bits Reminder: the FreeBSD Journal is free! Check out these great articles (https://www.freebsdfoundation.org/journal/browser-based-edition/) Serenity GUI desktop running on an OpenBSD kernel (https://twitter.com/jcs/status/1224205573656322048) The Open Source Parts of MacOS (https://github.com/apple-open-source/macos) FOSDEM videos available (https://www.fosdem.org/2020/schedule/track/bsd/) Feedback/Questions Michael - Install with ZFS (http://dpaste.com/3WRC9CQ#wrap) Mohammad - Server Freeze (http://dpaste.com/3BYZKMS#wrap) Todd - ZFS Questions (http://dpaste.com/2J50HSJ#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.

BSD Now
334: Distrowatch Running FreeBSD

BSD Now

Play Episode Listen Later Jan 23, 2020 48:07


Upgrading FreeBSD from 11.3 to 12.1, Distrowatch switching to FreeBSD, Torvalds says don’t run ZFS, iked(8) removed automatic IPv6 blocking, working towards LLDB on i386, and memory-hard Argon2 hashing scheme in NetBSD. Headlines Upgrading FreeBSD from 11.3 to 12.1 (https://blog.bimajority.org/2020/01/13/upgrading-freebsd-from-11-3-to-12-1/) Now here’s something more like what I was originally expecting the content on this blog to look like. I’m in the process of moving all of our FreeBSD servers (about 30 in total) from 11.3 to 12.1. We have our own local build of the OS, and until “packaged base” gets to a state where it’s reliably usable, we’re stuck doing upgrades the old-fashioned way. I created a set of notes for myself while cranking through these upgrades and I wanted to share them since they are not really work-specific and this process isn’t very well documented for people who haven’t been doing this sort of upgrade process for 25 years. Our source and object trees are read-only exported from the build server over NFS, which causes things to be slow. /etc/make.conf and /etc/src.conf are symbolic links on all of our servers to the master copies in /usr/src so that make installworld can find the configuration parameters the system was built with. Switching Distrowatch over to BSD (https://www.reddit.com/r/freebsd/comments/eodhit/switching_distrowatch_over_to_freebsd_ama/) This may be a little off-topic for this board (forgive me if it is, please). However, I wanted to say that I'm one of the people who works on DistroWatch (distrowatch.com) and this past week we had to deal with a server facing hardware failure. We had a discussion about whether to continue running Debian or switch to something else. The primary "something else" option turned out to be FreeBSD and it is what we eventually went with. It took a while to convert everything over from working with Debian GNU/Linux to FreeBSD 12 (some script incompatibilities, different paths, some changes to web server configuration, networking IPv6 troubles). But in the end we ended up with a good, FreeBSD-based experience. Since the transition was successful, though certainly not seamless, I thought people might want to do a Q&A on the migration process. Especially for those thinking of making the same switch. News Roundup iked(8) automatic IPv6 blocking removed (https://www.openbsd.org/faq/current.html#r20200114) iked(8) no longer automatically blocks unencrypted outbound IPv6 packets. This feature was intended to avoid accidental leakage, but in practice was found to mostly be a cause of misconfiguration. If you previously used iked(8)'s -6 flag to disable this feature, it is no longer needed and should be removed from /etc/rc.conf.local if used. Linus says dont run ZFS (https://itsfoss.com/linus-torvalds-zfs/) “Don’t use ZFS. It’s that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me.” This is what Linus Torvalds said in a mailing list to once again express his disliking for ZFS filesystem specially over its licensing. To avoid unnecessary confusion, this is more intended for Linux distributions, kernel developers and maintainers rather than individual Linux users. GSoC 2019 Final Report: Incorporating the memory-hard Argon2 hashing scheme into NetBSD (https://blog.netbsd.org/tnf/entry/gsoc_2019_final_report_incorporating) We successfully incorporated the Argon2 reference implementation into NetBSD/amd64 for our 2019 Google Summer of Coding project. We introduced our project here and provided some hints on how to select parameters here. For our final report, we will provide an overview of what changes were made to complete the project. The Argon2 reference implementation, available here, is available under both the Creative Commons CC0 1.0 and the Apache Public License 2.0. To import the reference implementation into src/external, we chose to use the Apache 2.0 license for this project. Working towards LLDB on i386 NetBSD (https://blog.netbsd.org/tnf/entry/working_towards_lldb_on_i386) Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages. In February 2019, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support, extending NetBSD's ptrace interface to cover more register types and fix compat32 issues, fixing watchpoint and threading support. Throughout December I've continued working on our build bot maintenance, in particular enabling compiler-rt tests. I've revived and finished my old patch for extended register state (XState) in core dumps. I've started working on bringing proper i386 support to LLDB. Beastie Bits An open source Civilization V (https://github.com/yairm210/UnCiv) BSD Groups in Italy (https://bsdnotizie.blogspot.com/2020/01/gruppi-bsd-in-italia.html) Why is Wednesday, November 17, 1858 the base time for OpenVMS? (https://www.slac.stanford.edu/~rkj/crazytime.txt) Benchmarking shell pipelines and the Unix “tools” philosophy (https://blog.plover.com/Unix/tools.html) LPI and BSD working together (https://youtu.be/QItb5aoj7Oc) Feedback/Questions Pat - March Meeting (http://dpaste.com/2BMGZVV#wrap) Madhukar - Overheating Laptop (http://dpaste.com/17WNVM8#wrap) Warren - R vs S (http://dpaste.com/3AZYFB1#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.

BSD Now
332: The BSD Hyperbole

BSD Now

Play Episode Listen Later Jan 9, 2020 45:12


Announcing HyperbolaBSD, IPFW In-Kernel NAT setup on FreeBSD, Wayland and WebRTC enabled for NetBSD 9/Linux, LLDB Threading support ready for mainline, OpenSSH U2F/FIDO support in base, Dragonfly drm/i915: Update, and more. Headlines HyperbolaBSD Announcement (https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/) Due to the Linux kernel rapidly proceeding down an unstable path, we are planning on implementing a completely new OS derived from several BSD implementations. This was not an easy decision to make, but we wish to use our time and resources to create a viable alternative to the current operating system trends which are actively seeking to undermine user choice and freedom. This will not be a "distro", but a hard fork of the OpenBSD kernel and userspace including new code written under GPLv3 and LGPLv3 to replace GPL-incompatible parts and non-free ones. Reasons for this include: Linux kernel forcing adaption of DRM, including HDCP. Linux kernel proposed usage of Rust (which contains freedom flaws and a centralized code repository that is more prone to cyber attack and generally requires internet access to use.) Linux kernel being written without security and in mind. (KSPP is basically a dead project and Grsec is no longer free software) Many GNU userspace and core utils are all forcing adaption of features without build time options to disable them. E.g. (PulseAudio / SystemD / Rust / Java as forced dependencies) As such, we will continue to support the Milky Way branch until 2022 when our legacy Linux-libre kernel reaches End of Life. Future versions of Hyperbola will be using HyperbolaBSD which will have the new kernel, userspace and not be ABI compatible with previous versions. HyperbolaBSD is intended to be modular and minimalist so other projects will be able to re-use the code under free license. Forum Post (https://forums.hyperbola.info/viewtopic.php?id=315) A simple IPFW In-Kernel NAT setup on FreeBSD (https://www.neelc.org/posts/freebsd-ipfw-nat/) After graduating college, I am moving from Brooklyn, NY to Redmond, WA (guess where I got a job). I always wanted to re-do my OPNsense firewall (currently a HP T730) with stock FreeBSD and IPFW’s in-kernel NAT. Why IPFW? Benchmarks have shown IPFW to be faster which is especially good for my Tor relay, and because I can! However, one downside of IPFW is less documentation vs PF, even less without natd (which we’re not using), and this took me time to figure this out. But since my T730 is already packed, I am testing this on a old PC with two NICs, and my laptop [1] as a client with an USB-to-Ethernet adapter. News Roundup HEADS UP: Wayland and WebRTC enabled for NetBSD 9/Linux (https://mail-index.netbsd.org/pkgsrc-users/2020/01/05/msg030124.html) This is just a heads up that the Wayland option is now turned on by default for NetBSD 9 and Linux in cases where it peacefully coexists with X11. Right now, this effects the following packages: graphics/MesaLib devel/SDL2 www/webkit-gtk x11/gtk3 The WebRTC option has also been enabled by default on NetBSD 9 for two Firefox versions: www/firefox, www/firefox68 Please keep me informed of any fallout. Hopefully, there will be none. If you want to try out Wayland-related things on NetBSD 9, wm/velox/MESSAGE may be interesting for you. LLDB Threading support now ready for mainline (https://blog.netbsd.org/tnf/entry/lldb_threading_support_now_ready) Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages. In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support, extending NetBSD's ptrace interface to cover more register types and fix compat32 issues and fixing watchpoint support. Then, I've started working on improving thread support which is taking longer than expected. You can read more about that in my September 2019 report. So far the number of issues uncovered while enabling proper threading support has stopped me from merging the work-in-progress patches. However, I've finally reached the point where I believe that the current work can be merged and the remaining problems can be resolved afterwards. More on that and other LLVM-related events happening during the last month in this report. OpenSSH U2F/FIDO support in base (https://www.undeadly.org/cgi?action=article;sid=20191115064850) Hardware backed keys can be generated using "ssh-keygen -t ecdsa-sk" (or "ed25519-sk" if your token supports it). Many tokens require to be touched/tapped to confirm this step. You'll get a public/private keypair back as usual, except in this case, the private key file does not contain a highly-sensitive private key but instead holds a "key handle" that is used by the security key to derive the real private key at signing time. So, stealing a copy of the private key file without also stealing your security key (or access to it) should not give the attacker anything. drm/i915: Update to Linux 4.8.17 (http://lists.dragonflybsd.org/pipermail/commits/2019-December/720257.html) drm/i915: Update to Linux 4.8.17 Broxton, Valleyview and Cherryview support improvements Broadwell and Gen9/Skylake support improvements Broadwell brightness fixes from OpenBSD Atomic modesetting improvements Various bug fixes and performance enhancements Beastie Bits Visual Studio Code port for FreeBSD (https://github.com/tagattie/FreeBSD-VSCode) OpenBSD syscall call-from verification (https://marc.info/?l=openbsd-tech&m=157488907117170&w=2) Peertube on OpenBSD (https://www.22decembre.eu/en/2019/12/09/peertube-14-openbsd/) Fuzzing Filesystems on NetBSD via AFL+KCOV by Maciej Grochowski (https://www.youtube.com/watch?v=bbNCqFdQEyk&feature=youtu.be) Twitter Bot for Prop65 (https://twitter.com/prop65bot/status/1199003319307558912) Interactive vim tutorial (https://www.openvim.com/) First BSD user group meeting in Hamilton, February 11, 2020 18:30 - 21:00, Boston Pizza on Upper James St (http://studybsd.com/) *** Feedback/Questions Samir - cgit (http://dpaste.com/2B22M24#wrap) Russell - R (http://dpaste.com/0J5TYY0#wrap) Wolfgang - Question (http://dpaste.com/3MQAH27#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.

BSD Now
331: Why Computers Suck

BSD Now

Play Episode Listen Later Jan 2, 2020 69:47


How learning OpenBSD makes computers suck a little less, How Unix works, FreeBSD 12.1 Runs Well on Ryzen Threadripper 3970X, BSDCan CFP, HardenedBSD Infrastructure Goals, and more. Headlines Why computers suck and how learning from OpenBSD can make them marginally less horrible (https://telegra.ph/Why-OpenBSD-is-marginally-less-horrible-12-05) How much better could things actually be if we abandoned the enterprise development model? Next I will compare this enterprise development approach with non-enterprise development - projects such as OpenBSD, which do not hesitate to introduce ABI breaking changes to improve the codebase. One of the most commonly referred to pillars of the project's philosophy has long been its emphasis on clean functional code. Any code which makes it into OpenBSD is subject to ongoing aggressive audits for deprecated, or otherwise unmaintained code in order to reduce cruft and attack surface. Additionally the project creator, Theo de Raadt, and his team of core developers engage in ongoing development for proactive mitigations for various attack classes many of which are directly adopted by various multi-platform userland applications as well as the operating systems themselves (Windows, Linux, and the other BSDs). Frequently it is the case that introducing new features (not just deprecating old ones) introduces new incompatibilities against previously functional binaries compiled for OpenBSD. To prevent the sort of kernel memory bloat that has plagued so many other operating systems for years, the project enforces a hard ceiling on the number of lines of code that can ever be in ring 0 at a given time. Current estimates guess the number of bugs per line of code in the Linux kernel are around 1 bug per every 10,000 lines of code. Think of this in the context of the scope creep seen in the Linux kernel (which if I recall correctly is currently at around 100,000,000 lines of code), as well as the Windows NT kernel (500,000,000 lines of code) and you quickly begin to understand how adding more and more functionality into the most privileged components of the operating system without first removing old components begins to add up in terms of the drastic difference seen between these systems in the number of zero day exploits caught in the wild respectively. How Unix Works: Become a Better Software Engineer (https://neilkakkar.com/unix.html) Unix is beautiful. Allow me to paint some happy little trees for you. I’m not going to explain a bunch of commands – that’s boring, and there’s a million tutorials on the web doing that already. I’m going to leave you with the ability to reason about the system. Every fancy thing you want done is one google search away. But understanding why the solution does what you want is not the same. That’s what gives you real power, the power to not be afraid. And since it rhymes, it must be true. News Roundup FreeBSD 12.1 Runs Refreshingly Well With AMD Ryzen Threadripper 3970X (https://www.phoronix.com/scan.php?page=article&item=freebsd-amd-3970x&num=1) For those of you interested in AMD's new Ryzen Threadripper 3960X/3970X processors with TRX40 motherboards for running FreeBSD, the experience in our initial testing has been surprisingly pleasant. In fact, it works out-of-the-box which one could argue is better than the current Linux support that needs the MCE workaround for booting. Here are some benchmarks of FreeBSD 12.1 on the Threadripper 3970X compared to Linux and Windows for this new HEDT platform. It was refreshing to see FreeBSD 12.1 booting and running just fine with the Ryzen Threadripper 3970X 32-core/64-thread processor from the ASUS ROG ZENITH II EXTREME motherboard and all core functionality working including the PCIe 4.0 NVMe SSD storage, onboard networking, etc. The system was running with 4 x 16GB DDR4-3600 memory, 1TB Corsair Force MP600 NVMe SSD, and Radeon RX 580 graphics. It was refreshing to see FreeBSD 12.1 running well with this high-end AMD Threadripper system considering Linux even needed a boot workaround. While the FreeBSD 12.1 experience was trouble-free with the ASUS TRX40 motherboard (ROG Zenith II Extreme) and AMD Ryzen Threadripper 3970X, DragonFlyBSD unfortunately was not. Both DragonFlyBSD 5.6.2 stable and the DragonFlyBSD daily development snapshot from last week were yielding a panic on boot. So with that, DragonFlyBSD wasn't tested for this Threadripper 3970X comparison but just FreeBSD 12.1. FreeBSD 12.1 on the Threadripper 3970X was benchmarked both with its default LLVM Clang 8.0.1 compiler and again with GCC 9.2 from ports for ruling out compiler differences. The FreeBSD 12.1 performance was compared to last week's Windows 10 vs. Linux benchmarks with the same system. BSDCan 2020 CFP (https://lists.bsdcan.org/pipermail/bsdcan-announce/2019-December/000180.html) BSDCan 2020 will be held 5-6 (Fri-Sat) June, 2020 in Ottawa, at the University of Ottawa. It will be preceded by two days of tutorials on 3-4 June (Wed-Thu). NOTE the change of month in 2020 back to June Also: do not miss out on the Goat BOF on Tuesday 2 June. We are now accepting proposals for talks. The talks should be designed with a very strong technical content bias. Proposals of a business development or marketing nature are not appropriate for this venue. See http://www.bsdcan.org/2020/ If you are doing something interesting with a BSD operating system, please submit a proposal. Whether you are developing a very complex system using BSD as the foundation, or helping others and have a story to tell about how BSD played a role, we want to hear about your experience. People using BSD as a platform for research are also encouraged to submit a proposal. Possible topics include: How we manage a giant installation with respect to handling spam. and/or sysadmin. and/or networking. Cool new stuff in BSD Tell us about your project which runs on BSD other topics (see next paragraph) From the BSDCan website, the Archives section will allow you to review the wide variety of past BSDCan presentations as further examples. Both users and developers are encouraged to share their experiences. HardenedBSD Infrastructure Goals (https://github.com/lattera/articles/blob/master/hardenedbsd/2019-12-01_infrastructure/article.md) 2019 has been an extremely productive year with regards to HardenedBSD's infrastructure. Several opportunities aligned themselves in such a way as to open a door for a near-complete rebuild with a vast expansion. The last few months especially have seen a major expansion of our infrastructure. We obtained a number of to-be-retired Dell R410 servers. The crash of our nightly build server provided the opportunity to deploy these R410 servers, doubling our build capacity. My available time to spend on HardenedBSD has decreased compared to this time last year. As part of rebuilding our infrastructure, I wanted to enable the community to be able to contribute. I'm structuring the work such that help is just a pull request away. Those in the HardenedBSD community who want to contribute to the infrastructure work can simply open a pull request. I'll review the code, and deploy it after a successful review. Users/contributors don't need access to our servers in order to improve them. My primary goal for the rest of 2019 and into 2020 is to become fully self-hosted, with the sole exception of email. I want to transition the source-of-truth git repos to our own infrastructure. We will still provide a read-only mirror on GitHub. As I develop this infrastructure, I'm doing so with human rights in mind. HardenedBSD is in a very unique position. In 2020, I plan to provide production Tor Onion Services for the various bits of our infrastructure. HardenedBSD will provide access to its various internal services to its developers and contributors. The entire development lifecycle, going from dev to prod, will be able to happen over Tor. Transparency will be key moving forward. Logs for the auto-sync script are now published directly to GitHub. Build logs will be, soon, too. Logs of all automated processes, and the code for those processes, will be tracked publicly via git. This will be especially crucial for development over Tor. Integrating Tor into our infrastructure so deeply increases risk and maintenance burden. However, I believe that through added transparency, we will be able to mitigate risk. Periodic audits will need to be performed and published. I hope to migrate HardenedBSD's site away from Drupal to a static site generator. We don't really need the dynamic capabilities Drupal gives us. The many security issues Drupal and PHP both bring also leave much to be desired. So, that's about it. I spent the last few months of 2019 laying the foundation for a successful 2020. I'm excited to see how the project grows. Beastie Bits FuryBSD - KDE plasma flavor now available (https://www.furybsd.org/kde-plasma-flavor-now-available/) DragonFly - git: virtio - Fix LUN scan issue w/ Google Cloud (http://lists.dragonflybsd.org/pipermail/commits/2019-November/719945.html) LPI is looking for BSD Specialist learning material writers (https://wiki.lpi.org/wiki/BSD_Specialist_Objectives_V1.0) ZFS sync/async + ZIL/SLOG, explained (https://jrs-s.net/2019/05/02/zfs-sync-async-zil-slog/) BSD-Licensed Combinatorics library/utility (https://lists.freebsd.org/pipermail/freebsd-announce/2019-December/001921.html) SSL client vs server certificates and bacula-fd (https://dan.langille.org/2019/11/29/ssl-client-vs-server-certificates-and-bacula-fd/) MaxxDesktop planning to come to FreeBSD (https://www.facebook.com/maxxdesktop/posts/2761326693888282) Project Page (https://www.facebook.com/maxxdesktop/) Feedback/Questions Tom - ZFS Mirror with different speeds (http://dpaste.com/3ZGYNS3#wrap) Jeff - Knowledge is power (http://dpaste.com/1H9QDCR#wrap) Johnny - Episode 324 response to Jacob (http://dpaste.com/1A7Q9EV) Pat - NYC*BUG meeting Jan Meeting Location (http://dpaste.com/0QPZ2GC) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.

BSD Now
328: EPYC Netflix Stack

BSD Now

Play Episode Listen Later Dec 12, 2019 57:43


LLDB Threading support now ready, Multiple IPSec VPN tunnels with FreeBSD, Netflix Optimized FreeBSD's Network Stack More Than Doubled AMD EPYC Performance, happy eyeballs with unwind(8), AWS got FreeBSD ARM 12, OpenSSH U2F/FIDO support, and more. Headlines LLDB Threading support now ready for mainline (https://blog.netbsd.org/tnf/entry/lldb_threading_support_now_ready) Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages. In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support, extending NetBSD's ptrace interface to cover more register types and fix compat32 issues and fixing watchpoint support. Then, I've started working on improving thread support which is taking longer than expected. You can read more about that in my September 2019 report. So far the number of issues uncovered while enabling proper threading support has stopped me from merging the work-in-progress patches. However, I've finally reached the point where I believe that the current work can be merged and the remaining problems can be resolved afterwards. More on that and other LLVM-related events happening during the last month in this report. Multiple IPSec VPN tunnels with FreeBSD (https://blog.socruel.nu/text-only/how-to-multiple-ipsec-vpn-tunnels-on-freebsd.txt) The FreeBSD handbook describes an IPSec VPN tunnel between 2 FreeBSD hosts (see https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html) But it is also possible to have multiple, 2 or more, IPSec VPN tunnels created and running on a FreeBSD host. How to implement and configure this is described below. The requirements is to have 3 locations (A, B and C) connected with IPSec VPN tunnels using FreeBSD (11.3-RELEASE). Each location has 1 IPSec VPN host running FreeBSD (VPN host A, B and C). VPN host A has 2 IPSec VPN tunnels: 1 to location B (VPN host B) and 1 to location C (VPN host C). News Roundup Netflix Optimized FreeBSD's Network Stack More Than Doubled AMD EPYC Performance (https://www.phoronix.com/scan.php?page=news_item&px=Netflix-NUMA-FreeBSD-Optimized) Drew Gallatin of Netflix presented at the recent EuroBSDcon 2019 conference in Norway on the company's network stack optimizations to FreeBSD. Netflix was working on being able to deliver 200Gb/s network performance for video streaming out of Intel Xeon and AMD EPYC servers, to which they are now at 190Gb/s+ and in the process that doubled the potential of EPYC Naples/Rome servers and also very hefty upgrades too for Intel. Netflix has long been known to be using FreeBSD in their data centers particularly where network performance is concerned. But in wanting to deliver 200Gb/s throughput from individual servers led them to making NUMA optimizations to the FreeBSD network stack. Allocating NUMA local memory for kernel TLS crypto buffers and for backing files sent via sentfile were among their optimizations. Changes to network connection handling and dealing with incoming connections to Nginx were also made. For those just wanting the end result, Netflix's NUMA optimizations to FreeBSD resulted in their Intel Xeon servers going from 105Gb/s to 191Gb/s while the NUMA fabric utilization dropped from 40% to 13%. unwind(8); "happy eyeballs" (https://marc.info/?l=openbsd-tech&m=157475113130337&w=2) In case you are wondering why happy eyeballs: It's a variation on this: https://en.wikipedia.org/wiki/Happy_Eyeballs unwind has a concept of a best nameserver type. It considers a configured DoT nameserver to be better than doing it's own recursive resolving. Recursive resolving is considered to be better than asking the dhcp provided nameservers. This diff sorts the nameserver types by quality, as above (validation, resolving, dead...), and as a tie breaker it adds the median of the round trip time of previous queries into the mix. One other interesting thing about this is that it gets us past captive portals without a check URL, that's why this diff is so huge, it rips out all the captive portal stuff (please apply with patch -E): 17 files changed, 385 insertions(+), 1683 deletions(-) Please test this. I'm particularly interested in reports from people who move between networks and need to get past captive portals. Amazon now has FreeBSD ARM 12 (https://aws.amazon.com/marketplace/pp/B081NF7BY7) Product Overview FreeBSD is an operating system used to power servers, desktops, and embedded systems. Derived from BSD, the version of UNIX developed at the University of California, Berkeley, FreeBSD has been continually developed by a large community for more than 30 years. FreeBSD's networking, security, storage, and monitoring features, including the pf firewall, the Capsicum and CloudABI capability frameworks, the ZFS filesystem, and the DTrace dynamic tracing framework, make FreeBSD the platform of choice for many of the busiest web sites and most pervasive embedded networking and storage systems. OpenSSH U2F/FIDO support in base (https://www.undeadly.org/cgi?action=article;sid=20191115064850) I just committed all the dependencies for OpenSSH security key (U2F) support to base and tweaked OpenSSH to use them directly. This means there will be no additional configuration hoops to jump through to use U2F/FIDO2 security keys. Hardware backed keys can be generated using "ssh-keygen -t ecdsa-sk" (or "ed25519-sk" if your token supports it). Many tokens require to be touched/tapped to confirm this step. You'll get a public/private keypair back as usual, except in this case, the private key file does not contain a highly-sensitive private key but instead holds a "key handle" that is used by the security key to derive the real private key at signing time. So, stealing a copy of the private key file without also stealing your security key (or access to it) should not give the attacker anything. Once you have generated a key, you can use it normally - i.e. add it to an agent, copy it to your destination's authorized_keys files (assuming they are running -current too), etc. At authentication time, you will be prompted to tap your security key to confirm the signature operation - this makes theft-of-access attacks against security keys more difficult too. Please test this thoroughly - it's a big change that we want to have stable before the next release. Beastie Bits DragonFly - git: virtio - Fix LUN scan issue w/ Google Cloud (http://lists.dragonflybsd.org/pipermail/commits/2019-November/719945.html) Really fast Markov chains in ~20 lines of sh, grep, cut and awk (https://0x0f0f0f.github.io/posts/2019/11/really-fast-markov-chains-in-~20-lines-of-sh-grep-cut-and-awk/) FreeBSD Journal Sept/Oct 2019 (https://www.freebsdfoundation.org/past-issues/security-3/) Michael Dexter is raising money for Bhyve development (https://twitter.com/michaeldexter/status/1201231729228308480) syscall call-from verification (https://marc.info/?l=openbsd-tech&m=157488907117170) FreeBSD Forums Howto Section (https://forums.freebsd.org/forums/howtos-and-faqs-moderated.39/) Feedback/Questions Jeroen - Feedback (http://dpaste.com/0PK1EG2#wrap) Savo - pfsense ports (http://dpaste.com/0PZ03B7#wrap) Tin - I want to learn C (http://dpaste.com/2GVNCYB#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.

BSD Now
326: Certified BSD

BSD Now

Play Episode Listen Later Nov 28, 2019 60:06


LPI releases BSD Certification, openzfs trip report, Using FreeBSD with ports, LLDB threading support ready, Linux versus Open Source Unix, and more. Headlines Linux Professional Institute Releases BSD Specialist Certification - re BSD Certification Group (https://www.lpi.org/articles/linux-professional-institute-releases-bsd-specialist-certification) Linux Professional Institute extends its Open Technology certification track with the BSD Specialist Certification. Starting October 30, 2019, BSD Specialist exams will be globally available. The certification was developed in collaboration with the BSD Certification Group which merged with Linux Professional Institute in 2018. G. Matthew Rice, the Executive Director of Linux Professional Institute says that "the release of the BSD Specialist certification marks a major milestone for Linux Professional Institute. With this new credential, we are reaffirming our belief in the value of, and support for, all open source technologies. As much as possible, future credentials and educational programs will include coverage of BSD.” OpenZFS Trip Report (https://www.ixsystems.com/blog/openzfs-dev-summit-2019/) The seventh annual OpenZFS Developer Summit took place on November 4th and 5th in San Francisco and brought together a healthy mix of familiar faces and new community participants. Several folks from iXsystems took part in the talks, hacking, and socializing at this amazing annual event. The messages of the event can be summed up as Unification, Refinement, and Ecosystem Tooling. News Roundup Using FreeBSD with Ports (2/2): Tool-assisted updating (https://eerielinux.wordpress.com/2019/09/12/using-freebsd-with-ports-2-2-tool-assisted-updating/) Part 1 here: https://eerielinux.wordpress.com/2019/08/18/using-freebsd-with-ports-1-2-classic-way-with-tools/ In the previous post I explained why sometimes building your software from ports may make sense on FreeBSD. I also introduced the reader to the old-fashioned way of using tools to make working with ports a bit more convenient. In this follow-up post we’re going to take a closer look at portmaster and see how it especially makes updating from ports much, much easier. For people coming here without having read the previous article: What I describe here is not what every FreeBSD admin today should consider good practice (any more)! It can still be useful in special cases, but my main intention is to discuss this for building up the foundation for what you actually should do today. LLDB Threading support now ready for mainline (http://blog.netbsd.org/tnf/entry/lldb_threading_support_now_ready) Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages. In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support, extending NetBSD's ptrace interface to cover more register types and fix compat32 issues and fixing watchpoint support. Then, I've started working on improving thread support which is taking longer than expected. You can read more about that in my September 2019 report. So far the number of issues uncovered while enabling proper threading support has stopped me from merging the work-in-progress patches. However, I've finally reached the point where I believe that the current work can be merged and the remaining problems can be resolved afterwards. More on that and other LLVM-related events happening during the last month in this report. Linux VS open source UNIX (https://www.adminbyaccident.com/politics/linux-vs-open-source-unix/) Beastie Bits Support for Realtek RTL8125 2.5Gb Ethernet controller (https://marc.info/?l=openbsd-tech&m=157380442230074&w=2) Computer Files Are Going Extinct (https://onezero.medium.com/the-death-of-the-computer-file-doc-43cb028c0506) FreeBSD kernel hacking (https://www.youtube.com/watch?v=4FUub_UtF3c) Modern BSD Computing for Fun on a VAX! Trying to use a VAX in today's world by Jeff Armstrong (https://youtu.be/e7cJ7v2lYdE) MidnightBSD 1.2 Released (https://www.justjournal.com/users/mbsd/entry/33779) Feedback/Questions Paulo - Zfs snapshots (http://dpaste.com/0WQRP43#wrap) Phillip - GCP (http://dpaste.com/075ZQE1#wrap) A Listener - Old episodes? (http://dpaste.com/3YJ4119#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.

BSD Now
318: The TrueNAS Library

BSD Now

Play Episode Listen Later Oct 2, 2019 46:40


DragonFlyBSD vs. FreeBSD vs. Linux benchmark on Ryzen 7, JFK Presidential Library chooses TrueNAS for digital archives, FreeBSD 12.1-beta is available, cool but obscure X11 tools, vBSDcon trip report, Project Trident 12-U7 is available, a couple new Unix artifacts, and more. Headlines DragonFlyBSD 5.6 vs. FreeBSD 12 vs. Linux - Ryzen 7 3700X (https://www.phoronix.com/scan.php?page=article&item=bsd-linux-3700x) For those wondering how well FreeBSD and DragonFlyBSD are handling AMD's new Ryzen 3000 series desktop processors, here are some benchmarks on a Ryzen 7 3700X with MSI MEG X570 GODLIKE where both of these popular BSD operating systems were working out-of-the-box. For some fun mid-week benchmarking, here are those results of FreeBSD 12.0 and DragonFlyBSD 5.6.2 up against openSUSE Tumbleweed and Ubuntu 19.04. Back in July I looked at FreeBSD 12 on the Ryzen 9 3900X but at that time at least DragonFlyBSD had troubles booting on that system. When trying out the Ryzen 7 3700X + MSI GODLIKE X570 motherboard on the latest BIOS, everything "just worked" without any compatibility issues for either of these BSDs. We've been eager to see how well DragonFlyBSD is performing on these new AMD Zen 2 CPUs with DragonFlyBSD lead developer Matthew Dillon having publicly expressed being impressed by the new AMD Ryzen 3000 series CPUs. For comparison to those BSDs, Ubuntu 19.04 and openSUSE Tumbleweed were tested on the same hardware in their out-of-the-box configurations. While Clear Linux is normally the fastest, on this system Clear's power management defaults had caused issues in being unable to detect the Samsung 970 EVO Plus NVMe SSD used for testing and so we left it out this round. All of the hardware was the same throughout testing as were the BIOS settings and running the Ryzen 7 3700X at stock speeds. (Any differences in the reported hardware for the system table just come down to differences in what is exposed by each OS for reporting.) All of the BSD/Linux benchmarks on this eight core / sixteen thread processor were run via the Phoronix Test Suite. In the case of FreeBSD 12.0, we benchmarked both with its default LLVM Clang 6.0 compiler as well as with GCC 9.1 so that it would match the GCC compiler being the default on the other operating systems under test. JFK Presidential Library Chooses iXsystems TrueNAS to Preserve Precious Digital Archives (https://www.ixsystems.com/blog/jfk-presidential-library-pr/) iXsystems is honored to have the TrueNAS® M-Series unified storage selected to store, serve, and protect the entire digital archive for the John F. Kennedy Library Foundation. This is in support of the collection at the John F. Kennedy Presidential Library and Museum (JFK Library). Over the next several years, the Foundation hopes to grow the digital collection from hundreds of terabytes today to cover much more of the Archives at the Kennedy Library. Overall there is a total of 25 million documents, audio recordings, photos, and videos once the project is complete. Having first deployed the TrueNAS M50-HA earlier in 2019, the JFK Library has now completed the migration of its existing digital collection and is now in the process of digitizing much of the rest of its vast collection. Not only is the catalog of material vast, it is also diverse, with files being copied to the storage system from a variety of sources in numerous file types. To achieve this ambitious goal, the library required a high-end NAS system capable of sharing with a variety of systems throughout the digitization process. The digital archive will be served from the TrueNAS M50 and made available to both in-person and online visitors. With precious material and information comes robust demands. The highly-available TrueNAS M-Series has multiple layers of protection to help keep data safe, including data scrubs, checksums, unlimited snapshots, replication, and more. TrueNAS is also inherently scalable with data shares only limited by the number of drives connected to the pool. Perfect for archival storage, the deployed TrueNAS M50 will grow with the library’s content, easily expanding its storage capacity over time as needed. Supporting a variety of protocols, multi-petabyte scalability in a single share, and anytime, uninterrupted capacity expansion, the TrueNAS M-Series ticked all the right boxes. Youtube Video (https://www.youtube.com/watch?v=8rFjH5-0Fiw) News Roundup FreeBSD 12.1-beta available (https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-12.1-Beta-Released) FreeBSD 12.0 is already approaching one year old while FreeBSD 12.1 is now on the way as the next installment with various bug/security fixes and other alterations to this BSD operating system. FreeBSD 12.1 has many security/bug fixes throughout, no longer enables "-Werror" by default as a compiler flag (Update: This change is just for the GCC 4.2 compiler), has imported BearSSL into the FreeBSD base system as a lightweight TLS/SSL implementation, bzip2recover has been added, and a variety of mostly lower-level changes. More details can be found via the in-progress release notes. For those with time to test this weekend, FreeBSD 12.1 Beta 1 is available for all prominent architectures. The FreeBSD release team is planning for at least another beta or two and around three release candidates. If all goes well, FreeBSD 12.1 will be out in early November. Announcement Link (https://lists.freebsd.org/pipermail/freebsd-stable/2019-September/091533.html) Cool, but obscure X11 tools. More suggestions in the source link (https://cyber.dabamos.de/unix/x11/) ASClock Free42 FSV2 GLXGears GMixer GVIM Micropolis Sunclock Ted TiEmu X026 X48 XAbacus XAntfarm XArchiver XASCII XBiff XBill XBoard XCalc XCalendar XCHM XChomp XClipboard XClock XClock/Cat Clock XColorSel XConsole XDiary XEarth XEdit Xev XEyes XFontSel XGalaga XInvaders 3D XKill XLennart XLoad XLock XLogo XMahjongg XMan XMessage XmGrace XMixer XmMix XMore XMosaic XMOTD XMountains XNeko XOdometer XOSView Xplore XPostIt XRoach XScreenSaver XSnow XSpread XTerm XTide Xv Xvkbd XWPE XZoom vBSDCon 2019 trip report from iXSystems (https://www.ixsystems.com/blog/vbsdcon-2019/) The fourth biennial vBSDCon was held in Reston, VA on September 5th through 7th and attracted attendees and presenters from not only the Washington, DC area, but also Canada, Germany, Kenya, and beyond. While MeetBSD caters to Silicon Valley BSD enthusiasts on even years, vBSDcon caters to East Coast and DC area enthusiasts on odd years. Verisign was again the key sponsor of vBSDcon 2019 but this year made a conscious effort to entrust the organization of the event to a team of community members led by Dan Langille, who you probably know as the lead BSDCan organizer. The result of this shift was a low key but professional event that fostered great conversation and brainstorming at every turn. Project Trident 12-U7 now available (https://project-trident.org/post/2019-09-21_stable12-u7_available/) Package Summary New Packages: 130 Deleted Packages: 72 Updated Packages: 865 Stable ISO - https://pkg.project-trident.org/iso/stable/Trident-x64-TOS-12-U7-20190920.iso A Couple new Unix Artifacts (https://minnie.tuhs.org//pipermail/tuhs/2019-September/018685.html) I fear we're drifting a bit here and the S/N ratio is dropping a bit w.r.t the actual history of Unix. Please no more on the relative merits of version control systems or alternative text processing systems. So I'll try to distract you by saying this. I'm sitting on two artifacts that have recently been given to me: by two large organisations of great significance to Unix history who want me to keep "mum" about them as they are going to make announcements about them soon* and I am going slowly crazy as I wait for them to be offically released. Now you have a new topic to talk about :-) Cheers, Warren * for some definition of "soon" Beastie Bits NetBSD machines at Open Source Conference 2019 Hiroshima (https://mail-index.netbsd.org/netbsd-advocacy/2019/09/16/msg000813.html) Hyperbola a GNU/Linux OS is using OpenBSD's Xenocara (https://www.hyperbola.info/news/end-of-xorg-support/) Talos is looking for a FreeBSD Engineer (https://www.talosintelligence.com/careers/freebsd_engineer) GitHub - dylanaraps/pure-sh-bible: A collection of pure POSIX sh alternatives to external processes. (https://github.com/dylanaraps/pure-sh-bible) dsynth: you’re building it (https://www.dragonflydigest.com/2019/09/23/23523.html) Percy Ludgate, the missing link between Babbage’s machine and everything else (http://lists.sigcis.org/pipermail/members-sigcis.org/2019-September/001606.html) Feedback/Questions Bruce - Down the expect rabbithole (http://dpaste.com/147HGP3#wrap) Bruce - Expect (update) (http://dpaste.com/37MNVSW#wrap) David - Netgraph answer (http://dpaste.com/2SE1YSE) Mason - Beeps? (http://dpaste.com/00KKXJM) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.

BSD Now
308: Mumbling with OpenBSD

BSD Now

Play Episode Listen Later Jul 24, 2019 44:25


Replacing a (silently) failing disk in a ZFS pool, OPNsense 19.7 RC1 released, implementing DRM ioctl support for NetBSD, High quality/low latency VOIP server with umurmur/Mumble on OpenBSD, the PDP-7 where Unix began, LLDB watchpoints, and more. Headlines Replacing a (silently) failing disk in a ZFS pool (https://imil.net/blog/2019/07/02/Replacing-a-silently-failing-disk-in-a-ZFS-pool/) Maybe I can’t read, but I have the feeling that official documentations explain every single corner case for a given tool, except the one you will actually need. My today’s struggle: replacing a disk within a FreeBSD ZFS pool. What? there’s a shitton of docs on this topic! Are you stupid? I don’t know, maybe. Yet none covered the process in a simple, straight and complete manner. OPNsense 19.7 RC1 released (https://opnsense.org/opnsense-19-7-rc1-released/) Hi there, For four and a half years now, 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. We thank all of you for helping test, shape and contribute to the project! We know it would not be the same without you. Download links, an installation guide[1] and the checksums for the images can be found below as well. News Roundup Implementation of DRM ioctl Support for NetBSD kernel (https://blog.netbsd.org/tnf/entry/implementation_of_drm_ioctl_support) What is DRM ioctl ? Ioctls are input/output control system calls and DRM stands for direct rendering manager The DRM layer provides several services to graphics drivers, many of them driven by the application interfaces it provides through libdrm, the library that wraps most of the DRM ioctls. These include vblank event handling, memory management, output management, framebuffer management, command submission & fencing, suspend/resume support, and DMA services. Native DRM ioctl calls NetBSD was able to make native DRM ioctl calls with hardware rendering once xorg and proper mesa packages where installed. We used the glxinfo and glxgears applications to test this out. High quality / low latency VOIP server with umurmur/Mumble on OpenBSD (https://dataswamp.org/~solene/2019-07-04-umurmur.html) Discord users keep telling about their so called discord server, which is not dedicated to them at all. And Discord has a very bad quality and a lot of voice distorsion. Why not run your very own mumble server with high voice quality and low latency and privacy respect? This is very easy to setup on OpenBSD! Mumble is an open source voip client, it has a client named Mumble (available on various operating system) and at least Android, the server part is murmur but there is a lightweight server named umurmur. People authentication is done through certificate generated locally and automatically accepted on a server, and the certificate get associated with a nickname. Nobody can pick the same nickname as another person if it’s not the same certificate. TMWL June’19 — JS Fetch API, scheduling in Spring, thoughts on Unix (https://blog.softwaremill.com/tmwl-june19-js-fetch-api-scheduling-in-spring-thoughts-on-unix-fd54f50ecd64) Unix — going back to the roots From time to time, I like to review my knowledge in a certain area, even when I feel like I know a lot about it already. I go back to the basics and read tutorials, manuals, books or watch interesting videos. I’ve been using macOS for a couple of years now, previously being a linux user for some (relatively short) time. Both these operating systems have a common ancestor — Unix. While I’m definitely not an expert, I feel quite comfortable using linux & macOS — I understand the concepts behind the system architecture, know a lot of command line tools & navigate through the shell without a hassle. So-called unix philosophy is also close to my heart. I always feel like there’s more I could squeeze out of it. Recently, I found that book titled “Unix for dummies, 5th edition” which was published back in… 2004. Feels literally like AGES in the computer-related world. However, it was a great shot — the book starts with the basics, providing some brief history of Unix and how it came to life. It talks a lot about the structure of the system and where certain pieces fit (eg. “standard” set of tools), and how to understand permissions and work with files & directories. There’s even a whole chapter about shell-based text editors like Vi and Emacs! Despite the fact that I am familiar with most of these, I could still find some interesting pieces & tools that I either knew existed (but never had a chance to use), or even haven’t ever heard of. And almost all of these are still valid in the modern “incarnations” of Unix’s descendants: Linux and macOS. The book also talks about networking, surfing the web & working with email. It’s cute to see pictures of those old browsers rendering “ancient” Internet websites, but hey — this is how it looked like no more than fifteen years ago! I can really recommend this book to anyone working on modern macOS or Linux — you will certainly find some interesting pieces. Especially if you like to go back to the roots from time to time as I do! ThePDP-7 Where Unix Began (https://bsdimp.blogspot.com/2019/07/the-pdp-7-where-unix-began.html) In preparation for a talk on Seventh Edition Unix this fall, I stumbled upon a service list from DEC for all known PDP-7 machines. From that list, and other sources, I believe that PDP-7 serial number 34 was the original Unix machine. V0 Unix could run on only one of the PDP-7s. Of the 99 PDP-7s produced, only two had disks. Serial number 14 had an RA01 listed, presumably a disk, though of a different type. In addition to the PDP-7 being obsolete in 1970, no other PDP-7 could run Unix, limiting its appeal outside of Bell Labs. By porting Unix to the PDP-11 in 1970, the group ensured Unix would live on into the future. The PDP-9 and PDP-15 were both upgrades of the PDP-7, so to be fair, PDP-7 Unix did have a natural upgrade path (the PDP-11 out sold the 18 bit systems though ~600,000 to ~1000). Ken Thompson reports in a private email that there were 2 PDP-9s and 1 PDP-15 at Bell Labs that could run a version of the PDP-7 Unix, though those machines were viewed as born obsolete. LLDB: watchpoints, XSTATE in ptrace() and core dumps (https://blog.netbsd.org/tnf/entry/lldb_watchpoints_xstate_in_ptrace) Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages. In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support and lately extending NetBSD's ptrace interface to cover more register types and fix compat32 issues. You can read more about that in my May 2019 report. In June, I have finally finished the remaining ptrace() work for xstate and got it merged both on NetBSD and LLDB end (meaning it's going to make it into NetBSD 9). I have also worked on debug register support in LLDB, effectively fixing watchpoint support. Once again I had to fight some upstream regressions. Beastie Bits Project Trident 19.07 Available (https://project-trident.org/post/2019-07-12_19.07_available/) A list of names from "Cold Blood" -- Any familiar? (https://www.montanalinux.org/cold-blood-list-of-numbers-201907.html) fern: a curses-based mastodon client modeled off usenet news readers & pine, with an emphasis on getting to 'timeline zero' (https://github.com/enkiv2/fern) OpenBSD Community goes Platinum for 2019! (https://undeadly.org/cgi?action=article;sid=20190707065226) tcp keepalive and dports on DragonFly (https://www.dragonflydigest.com/2019/07/15/23199.html) Feedback/Questions Patrick - OpenZFS/ZoL Module from Ports (http://dpaste.com/1W2HJ04) Brad - Services not starting (http://dpaste.com/345VM9Y#wrap) Simon - Feedback (http://dpaste.com/1B4ZKC8#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.

BSD Now
303: OpenZFS in Ports

BSD Now

Play Episode Listen Later Jun 19, 2019 52:33


OpenZFS-kmod port available, using blacklistd with NPF as fail2ban replacement, ZFS raidz expansion alpha preview 1, audio VU-meter increases CO2 footprint rant, XSAVE and compat32 kernel work for LLDB, where icons for modern X applications come from, and more. Headlines ZFSonFreeBSD ports renamed OpenZFS (https://www.freshports.org/sysutils/openzfs-kmod) The ZFS on FreeBSD project has renamed the userland and kernel ports from zol and zol-kmod to openzfs and openzfs-kmod The new versions from this week are IOCTL compatible with the command line tools in FreeBSD 12.0, so you can use the old userland with the new kernel module (although obviously not the new features) With the renaming it is easier to specify which kernel module you want to load in /boot/loader.conf: > zfs_load=”YES” or > openzfs_load=”YES” To load traditional or the newer version of ZFS The kmod still requires FreeBSD 12-stable or 13-current because it depends on the newer crypto support in the kernel for the ZFS native encryption feature. Allan is looking at ways to work around this, but it may not be practical. We would like to do an unofficial poll on how people would the userland to co-exist. Add a suffix to the new commands in /usr/local (zfs.new zpool.new or whatever). One idea i’ve had is to move the zfs and zpool commands to /libexec and make /sbin/zfs and /sbin/zpool a switcher script, that will call the base or ports version based on a config file (or just based on if the port is installed) For testing purposes, generally you should be fine as long as you don’t run ‘zpool upgrade’, which will make your pool only importable using the newer ZFS. For extra safety, you can create a ‘zpool checkpoint’, which will allow you to undo any changes that are made to the pool during your testing with the new openzfs tools. Note: the checkpoint will undo EVERYTHING. So don’t save new data you want to keep. Note: Checkpoints disable all freeing operations, to prevent any data from being overwritten so that you can re-import at the checkpoint and undo any operation (including zfs destroy-ing a dataset), so also be careful you don’t run out of space during testing. Please test and provide feedback. How to use blacklistd(8) with NPF as a fail2ban replacement (https://www.unitedbsd.com/d/63-how-to-use-blacklistd8-with-npf-as-a-fail2ban-replacement) About blacklistd(8) blacklistd(8) provides an API that can be used by network daemons to communicate with a packet filter via a daemon to enforce opening and closing ports dynamically based on policy. The interface to the packet filter is in /libexec/blacklistd-helper (this is currently designed for npf) and the configuration file (inspired from inetd.conf) is in etc/blacklistd.conf Now, blacklistd(8) will require bpfjit(4) (Just-In-Time compiler for Berkeley Packet Filter) in order to properly work, in addition to, naturally, npf(7) as frontend and syslogd(8), as a backend to print diagnostic messages. Also remember npf shall rely on the npflog* virtual network interface to provide logging for tcpdump() to use. Unfortunately (dont' ask me why :P) in 8.1 all the required kernel components are still not compiled by default in the GENERIC kernel (though they are in HEAD), and are rather provided as modules. Enabling NPF and blacklistd services would normally result in them being automatically loaded as root, but predictably on securelevel=1 this is not going to happen News Roundup [WIP] raidz expansion, alpha preview 1 (https://github.com/zfsonlinux/zfs/pull/8853) Motivation and Context > This is a alpha-quality preview of RAID-Z expansion. This feature allows disks to be added one at a time to a RAID-Z group, expanding its capacity incrementally. This feature is especially useful for small pools (typically with only one RAID-Z group), where there isn't sufficient hardware to add capacity by adding a whole new RAID-Z group (typically doubling the number of disks). > For additional context as well as a design overview, see my short talk from the 2017 OpenZFS Developer Summit: slides video Rant: running audio VU-meter increases my CO2 footprint (https://medium.com/@MartinCracauer/bug-rant-running-audio-vu-meter-increases-my-co2-footprint-871d5c1bee5a) A couple months ago I noticed that the monitor on my workstation never power off anymore. Screensaver would go on, but DPMs (to do the poweroff) never kicked in. I grovels the output of various tools that display DPMS settings, which as usual in Xorg were useless. Everybody said DPMS is on with a timeout. I even wrote my own C program to use every available Xlib API call and even the xscreensaver library calls. (should make it available) No go, everybody says that DPMs is on, enabled and set on a timeout. Didn’t matter whether I let xscreeensaver do the job or just the X11 server. After a while I noticed that DPMS actually worked between starting my X11 server and starting all my clients. I have a minimal .xinitrc and start the actual session from a script, that is how I could notice. If I used a regular desktop login I wouldn’t have noticed. A server state bug was much more likely than a client bug. + See the article for the rest... XSAVE and compat32 kernel work for LLDB (http://blog.netbsd.org/tnf/entry/xsave_and_compat32_kernel_work) Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages. In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support and lately extending NetBSD's ptrace interface to cover more register types. You can read more about that in my Apr 2019 report. In May, I was primarily continuing the work on new ptrace interface. Besides that, I've found and fixed a bug in ptrace() compat32 code, pushed LLVM buildbot to ‘green’ status and found some upstream LLVM regressions. More below. Some things about where icons for modern X applications come from (https://utcc.utoronto.ca/~cks/space/blog/unix/ModernXAppIcons) If you have a traditional window manager like fvwm, one of the things it can do is iconify X windows so that they turn into icons on the root window (which would often be called the 'desktop'). Even modern desktop environments that don't iconify programs to the root window (or their desktop) may have per-program icons for running programs in their dock or taskbar. If your window manager or desktop environment can do this, you might reasonably wonder where those icons come from by default. Although I don't know how it was done in the early days of X, the modern standard for this is part of the Extended Window Manager Hints. In EWMH, applications give the window manager a number of possible icons, generally in different sizes, as ARGB bitmaps (instead of, say, SVG format). The window manager or desktop environment can then pick whichever icon size it likes best, taking into account things like the display resolution and so on, and display it however it wants to (in its original size or scaled up or down). How this is communicated in specific is through the only good interprocess communication method that X supplies, namely X properties. In the specific case of icons, the NETWMICON property is what is used, and xprop can display the size information and an ASCII art summary of what each icon looks like. It's also possible to use some additional magic to read out the raw data from _NETWM_ICON in a useful format; see, for example, this Stackoverflow question and its answers. Beastie Bits Recent Security Innovations (http://undeadly.org/cgi?action=article;sid=20190605110020) Old Unix books + Solaris (https://imgur.com/a/HbSYtQI) Pro-Desktop - A Tiling Desktop Environment (https://bitcannon.net/post/pro-desktop/) The Tar Pipe (https://blog.extracheese.org/2010/05/the-tar-pipe.html) At least one vim trick you might not know (https://www.hillelwayne.com/post/intermediate-vim/) Feedback/Questions Johnny - listener feedback (http://dpaste.com/0ZQCQ8Y#wrap) Brian - Questions (http://dpaste.com/1843RNX#wrap) Mark - ZFS Question (http://dpaste.com/3M83X9G#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.

BSD Now
299: The NAS Fleet

BSD Now

Play Episode Listen Later May 22, 2019 52:47


Running AIX on QEMU on Linux on Windows, your NAS fleet with TrueCommand, Unleashed 1.3 is available, LLDB: CPU register inspection support extension, V7 Unix programs often not written as expected, and more. Headlines Running AiX on QEMU on Linux on Windows YES it’s real! I’m using the Linux subsystem on Windows, as it’s easier to build this Qemu tree from source. I’m using Debian, but these steps will work on other systems that use Debian as a base. first thing first, you need to get your system with the needed pre-requisites to compile Great with those in place, now clone Artyom Tarasenko’s source repository Since the frame buffer apparently isn’t quite working just yet, I configure for something more like a text mode build. Now for me, GCC 7 didn’t build the source cleanly. I had to make a change to the file config-host.mak and remove all references to -Werror. Also I removed the sound hooks, as we won’t need them. Now you can build Qemu. Okay, all being well you now have a Qemu. Now following the steps from Artyom Tarasenko’s blog post, we can get started on the install! See article for rest of walkthrough. Take Command of Your NAS Fleet with TrueCommand Hundreds of thousands of FreeNAS and TrueNAS systems are deployed around the world, with many sites having dozens of systems. Managing multiple systems individually can be time-consuming. iXsystems has responded to the challenge by creating a “single pane of glass” application to simplify the scaling of data, drive management, and administration of iXsystems NAS platforms. We are proud to introduce TrueCommand. TrueCommand is a ZFS-aware management application that manages TrueNAS and FreeNAS systems. The public Beta of TrueCommand is available for download now. TrueCommand can be used with small iXsystems NAS fleets for free. Licenses can be purchased for large-scale deployments and enterprise support. TrueCommand expands on the ease of use and power of TrueNAS and FreeNAS systems with multi-system management and reporting. News Roundup Unleashed 1.3 Released This is the fourth release of Unleashed - an operating system fork of illumos. For more information about Unleashed itself and the download links, see our website. As one might expect, this release removes a few things. The most notable being the removal of ksh93 along with all its libs. As far as libc interfaces are concerned, a number of non-standard functions were removed. In general, they have been replaced by the standards-compliant versions. (getgrentr, fgetgrentr, getgrgidr, getgrnamr, ttynamer, getloginr, shmdt, sigwait, gethostname, putmsg, putpmsg, and getaddrinfo) Additionally, wordexp and wordfree have been removed from libc. Even though they are technically required by POSIX, software doesn't seem to use them. Because of the fragile implementation (shelling out), we took the OpenBSD approach and just removed them. The default compilation environment now includes XOPENSOURCE=700 and EXTENSIONS. Additionally, all applications now use 64-bit file offsets, making use of LARGEFILESOURCE, LARGEFILE64SOURCE, and FILEOFFSET_BITS unnecessary. Last but not least, nightly.sh is no more. In short, to build one simply runs 'make'. (See README for detailed build instructions.) Why Unleashed Why did we decide to fork illumos? After all, there are already many illumos distributions available to choose from. We felt we could do better than any of them by taking a more aggressive stance toward compatibility and reducing cruft from code and community interactions alike. LLDB: extending CPU register inspection support Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages. In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support and updating NetBSD distribution to LLVM 8 (which is still stalled by unresolved regressions in inline assembly syntax). You can read more about that in my Mar 2019 report. In April, my main focus was on fixing and enhancing the support for reading and writing CPU registers. In this report, I'd like to shortly summarize what I have done, what I have learned in the process and what I still need to do. Future plans My work continues with the two milestones from last month, plus a third that's closely related: Add support for FPU registers support for NetBSD/i386 and NetBSD/amd64. Support XSAVE, XSAVEOPT, ... registers in core(5) files on NetBSD/amd64. Add support for Debug Registers support for NetBSD/i386 and NetBSD/amd64. The most important point right now is deciding on the format for passing the remaining registers, and implementing the missing ptrace interface kernel-side. The support for core files should follow using the same format then. Userland-side, I will work on adding matching ATF tests for ptrace features and implement LLDB side of support for the new ptrace interface and core file notes. Afterwards, I will start working on improving support for the same things on 32-bit (i386) executables. V7 Unix programs are often not written the way you would expect Yesterday I wrote that V7 ed read its terminal input in cooked mode a line at a time, which was an efficient, low-CPU design that was important on V7's small and low-power hardware. Then in comments, frankg pointed out that I was wrong about part of that, namely about how ed read its input. Sidebar: An interesting undocumented ed feature Reading this section of the source code for ed taught me that it has an interesting, undocumented, and entirely characteristic little behavior. Officially, ed commands that have you enter new text have that new text terminate by a . on a line by itself: In other words, it turns a single line with '.' into an EOF. The consequence of this is that if you type a real EOF at the start of a line, you get the same result, thus saving you one character (you use Control-D instead of '.' plus newline). This is very V7 Unix behavior, including the lack of documentation. This is also a natural behavior in one sense. A proper program has to react to EOF here in some way, and it might as well do so by ending the input mode. It's also natural to go on to try reading from the terminal again for subsequent commands; if this was a real and persistent EOF, for example because the pty closed, you'll just get EOF again and eventually quit. V7 ed is slightly unusual here in that it deliberately converts '.' by itself to EOF, instead of signaling this in a different way, but in a way that's also the simplest approach; if you have to have some signal for each case and you're going to treat them the same, you might as well have the same signal for both cases. Modern versions of ed appear to faithfully reimplement this convenient behavior, although they don't appear to document it. I haven't checked OpenBSD, but both FreeBSD ed and GNU ed work like this in a quick test. I haven't checked their source code to see if they implement it the same way. Beastie Bits CarolinaCon 15: Writing Exploit-Resistant Code With OpenBSD CFT: FreeBSD Package Base Initial FUSE support in DragonFly Two significant bugfixes for 5.4 Libretto 100ct: 166mhz Pentium, 16gb compactflash, 32mb ram running OpenBSD Feedback/Questions DJ - Feedback Fabian - ZFS ARC Caleb - Question A small programming note: After BSDNow episode 300, the podcast will switch to audio-only, using a new higher quality recording and production system. The live stream will likely still include video. Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Your browser does not support the HTML5 video tag.

BSD Now
296: It’s Alive: OpenBSD 6.5

BSD Now

Play Episode Listen Later May 3, 2019 61:35


OpenBSD 6.5 has been released, mount ZFS datasets anywhere, help test upcoming NetBSD 9 branch, LibreSSL 2.9.1 is available, Bail Bond Denied Edition of FreeBSD Mastery: Jails, and one reason ed(1) was a good editor back in the days in this week’s episode. Headlines OpenBSD 6.5 Released Changelog Mirrors 6.5 Includes OpenSMTPD 6.5.0 LibreSSL 2.9.1 OpenSSH 8.0 Mandoc 1.14.5 Xenocara LLVM/Clang 7.0.1 (+ patches) GCC 4.2.1 (+ patches) and 3.3.6 (+ patches) Many pre-built packages for each architecture: aarch64: 9654 amd64: 10602 i386: 10535 Mount your ZFS datasets anywhere you want ZFS is very flexible about mountpoints, and there are many features available to provide great flexibility. When you create zpool maintank, the default mountpoint is /maintank. You might be happy with that, but you don’t have to be content. You can do magical things. Some highlights are: mount point can be inherited not all filesystems in a zpool need to be mounted each filesystem (directory) can have different ZFS characteristics In my case, let’s look at this new zpool I created earlier today and I will show you some very simple alternatives. This zpool use NVMe devices which should be faster than SSDs especially when used with multiple concurrent writes. This is my plan: run all the Bacula regression tests concurrently. News Roundup Branch for netbsd 9 upcoming, please help and test -current Folks, once again we are quite late for branching the next NetBSD release (NetBSD 9). Initially planned to happen early in February 2019, we are now approaching May and it is unlikely that the branch will happen before that. On the positive side, lots of good things landed in -current in between, like new Mesa, new jemalloc, lots of ZFS improvements - and some of those would be hard to pull up to the branch later. On the bad side we saw lots of churn in -current recently, and there is quite some fallout where we not even have a good overview right now. And this is where you can help: please test -current, on all the various machines you have especially interesting would be test results from uncommon architectures or strange combinations (like the sparc userland on sparc64 kernel issue I ran in yesterday) Please test, report success, and file PRs for failures! We will likely announce the real branch date on quite short notice, the likely next candidates would be mid may or end of may. We may need to do extra steps after the branch (like switch some architectures back to old jemalloc on the branch). However, the less difference between -current and the branch, the easier will the release cycle go. Our goal is to have an unprecedented short release cycle this time. But.. we always say that upfront. LibreSSL 2.9.1 Released We have released LibreSSL 2.9.1, which will be arriving in the LibreSSL directory of your local OpenBSD mirror soon. This is the first stable release from the 2.9 series, which is also included with OpenBSD 6.5 It includes the following changes and improvements from LibreSSL 2.8.x: API and Documentation Enhancements CRYPTO_LOCK is now automatically initialized, with the legacy callbacks stubbed for compatibility. Added the SM3 hash function from the Chinese standard GB/T 32905-2016. Added the SM4 block cipher from the Chinese standard GB/T 32907-2016. Added more OPENSSLNO* macros for compatibility with OpenSSL. Partial port of the OpenSSL ECKEYMETHOD API for use by OpenSSH. Implemented further missing OpenSSL 1.1 API. Added support for XChaCha20 and XChaCha20-Poly1305. Added support for AES key wrap constructions via the EVP interface. Compatibility Changes Added pbkdf2 key derivation support to openssl(1) enc. Changed the default digest type of openssl(1) enc to sha256. Changed the default digest type of openssl(1) dgst to sha256. Changed the default digest type of openssl(1) x509 -fingerprint to sha256. Changed the default digest type of openssl(1) crl -fingerprint to sha256. Testing and Proactive Security Added extensive interoperability tests between LibreSSL and OpenSSL 1.0 and 1.1. Added additional Wycheproof tests and related bug fixes. Internal Improvements Simplified sigalgs option processing and handshake signing algorithm selection. Added the ability to use the RSA PSS algorithm for handshake signatures. Added bnrandinterval() and use it in code needing ranges of random bn values. Added functionality to derive early, handshake, and application secrets as per RFC8446. Added handshake state machine from RFC8446. Removed some ASN.1 related code from libcrypto that had not been used since around 2000. Unexported internal symbols and internalized more record layer structs. Removed SHA224 based handshake signatures from consideration for use in a TLS 1.2 handshake. Portable Improvements Added support for assembly optimizations on 32-bit ARM ELF targets. Added support for assembly optimizations on Mingw-w64 targets. Improved Android compatibility Bug Fixes Improved protection against timing side channels in ECDSA signature generation. Coordinate blinding was added to some elliptic curves. This is the last bit of the work by Brumley et al. to protect against the Portsmash vulnerability. Ensure transcript handshake is always freed with TLS 1.2. The LibreSSL project continues improvement of the codebase to reflect modern, safe programming practices. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible. FreeBSD Mastery: Jails – Bail Bond Denied Edition I had a brilliant, hideous idea: to produce a charity edition of FreeBSD Mastery: Jails featuring the cover art I would use if I was imprisoned and did not have access to a real cover artist. (Never mind that I wouldn’t be permitted to release books while in jail: we creative sorts scoff at mere legal and cultural details.) I originally wanted to produce my own take on the book’s cover art. My first attempt failed spectacularly. I downgraded my expectations and tried again. And again. And again. I’m pleased to reveal the final cover for FreeBSD Mastery: Jails–Bail Bond Edition! This cover represents the very pinnacle of my artistic talents, and is the result of literally hours of effort. But, as this book is available only to the winner of charity fund-raisers, purchase of this tome represents moral supremacy. I recommend flaunting it to your family, coworkers, and all those of lesser character. Get your copy by winning the BSDCan 2019 charity auction… or any other other auction-type event I deem worthwhile. As far as my moral fiber goes: I have learned that art is hard, and that artists are not paid enough. And if I am ever imprisoned, I do hope that you’ll contribute to my bail fund. Otherwise, you’ll get more covers like this one. One reason ed(1) was a good editor back in the days of V7 Unix It is common to describe ed(1) as being line oriented, as opposed to screen oriented editors like vi. This is completely accurate but it is perhaps not a complete enough description for today, because ed is line oriented in a way that is now uncommon. After all, you could say that your shell is line oriented too, and very few people use shells that work and feel the same way ed does. The surface difference between most people's shells and ed is that most people's shells have some version of cursor based interactive editing. The deeper difference is that this requires the shell to run in character by character TTY input mode, also called raw mode. By contrast, ed runs in what Unix usually calls cooked mode, where it reads whole lines from the kernel and the kernel handles things like backspace. All of ed's commands are designed so that they work in this line focused way (including being terminated by the end of the line), and as a whole ed's interface makes this whole line input approach natural. In fact I think ed makes it so natural that it's hard to think of things as being any other way. Ed was designed for line at a time input, not just to not be screen oriented. This input mode difference is not very important today, but in the days of V7 and serial terminals it made a real difference. In cooked mode, V7 ran very little code when you entered each character; almost everything was deferred until it could be processed in bulk by the kernel, and then handed to ed all in a single line which ed could also process all at once. A version of ed that tried to work in raw mode would have been much more resource intensive, even if it still operated on single lines at a time. Beastie Bits CFT for FreeBSD ZoL Simple DNS Adblock AT&T Unix PC in 1985 OpenBSD-current drm at 4.19, includes new support for Intel GPUs like Coffee Lake "What are the differences between Linux and OpenBSD?" - Twitter thread Announcing the pkgsrc-2019Q1 release (2019-04-10) Feedback/Questions Brad - iocage Frank - Video from Level1Tech and a question Niall - Revision Control Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Your browser does not support the HTML5 video tag.

BSD Now
Episode 264: Optimized-out | BSD Now 264

BSD Now

Play Episode Listen Later Sep 20, 2018 71:58


FreeBSD and DragonflyBSD benchmarks on AMD’s Threadripper, NetBSD 7.2 has been released, optimized out DTrace kernel symbols, stuck UEFI bootloaders, why ed is not a good editor today, tell your BSD story, and more. ##Headlines FreeBSD & DragonFlyBSD Put Up A Strong Fight On AMD’s Threadripper 2990WX, Benchmarks Against Linux The past two weeks I have been delivering a great deal of AMD Threadripper 2990WX benchmarks on Linux as well as some against Windows and Windows Server. But recently I got around to trying out some of the BSD operating systems on this 32-core / 64-thread processor to see how they would run and to see whether they would have similar scaling issues or not like we’ve seen on the Windows side against Linux. In this article are FreeBSD and DragonFlyBSD benchmarks with the X399 + 2990WX compared to a few Linux distributions. The BSDs I focused my testing on were FreeBSD 11.2-STABLE and 12.0-CURRENT/ALPHA1 (the version in development) as well as iX System’s TrueOS that is tracking FreeBSD 12.0-CURRENT. Also included were DragonFlyBSD, with FreeBSD and DragonFlyBSD being tied as my favorite operating systems when it comes to the BSDs. When it came to FreeBSD 11.2-STABLE and 12.0-ALPHA1 on the Threadripper 2990WX, it worked out surprisingly well. I encountered no real issues during my two days of benchmarking on FreeBSD (and TrueOS). It was a great experience and FreeBSD was happy to exploit the 64 threads on the system. DragonFlyBSD was a bit of a different story… Last week when I started this BSD testing I tried DragonFly 5.2.2 as the latest stable release as well as a DragonFlyBSD 5.3 development snapshot from last week: both failed to boot in either BIOS or UEFI modes. But then a few days ago DragonFlyBSD lead developer Matthew Dillon bought himself a 2990WX platform. He made the necessary changes to get DragonFlyBSD 5.3 working and he ended up finding really great performance and potential out of the platform. So I tried the latest DragonFlyBSD 5.3 daily ISO on 22 August and indeed it now booted successfully and we were off to the races. Thus there are some DragonFlyBSD 5.3 benchmarks included in this article too. Just hours ago, Matthew Dillon landed some 2990WX topology and scheduler enhancements but that fell out of the scope of when DragonFly was installed on this system. But over the weekend or so I plan to re-test DragonFlyBSD 5.3 and see how those optimizations affect the overall 2990WX performance now on that BSD. DragonFlyBSD 5.4 stable should certainly be an interesting release on several fronts! With FreeBSD 11.2-STABLE and 12.0-ALPHA1 I ran benchmarks when using their stock compiler (LLVM Clang 6.0) as well as GCC 7.3 obtained via GCC 7.3. That was done to rule out compiler differences in benchmarking against the GCC-based Linux distributions. On DragonFlyBSD 5.3 it defaults to the GCC 5.4.1 but via pkg I also did a secondary run when upgraded to GCC 7.3. The hardware and BIOS/UEFI settings were maintained the same throughout the entire benchmarking process. The system was made up of the AMD Ryzen Threadripper 2990WX at stock speeds, the ASUS ROG ZENITH EXTREME motherboard, 4 x 8GB DDR4-3200MHz memory, Samsung 970 EVO 500GB NVMe SSD, and Radeon RX Vega 56 graphics card. All of these Linux vs. BSD benchmarks were carried out in a fully-automated and reproducible manner using the open-source Phoronix Test Suite benchmarking framework. While for the last of today’s BSD vs. Linux benchmarking on the Threadripper 2990WX, the Linux distributions came out slightly ahead of FreeBSD and DragonFlyBSD with GCC (another test having issues with Clang 6.0 on the BSDs). Overall, I was quite taken away by the BSD performance on the Threadripper 2990WX – particularly FreeBSD. In a surprising number of benchmarks, the BSDs were outperforming the tested Linux distributions though often by incredibly thin margins. Still, quite an accomplishment for these BSD operating systems and considering how much better Linux is already doing than Windows 10 / Windows Server on this 32-core / 64-thread processor. Then again, the BSDs like Linux have a long history of running on high core/thread-count systems, super computers, and other HPC environments. It will be interesting to see how much faster DragonFlyBSD can run given today’s commit to its kernel with scheduler and topology improvements for the 2990WX. Those additional DragonFlyBSD benchmarks will be published in the coming days once they are completed. ###NetBSD 7.2 released The NetBSD Project is pleased to announce NetBSD 7.2, the second feature update of the NetBSD 7 release branch. It represents a selected subset of fixes deemed important for security or stability reasons, as well as new features and enhancements. General Security Note The NetBSD 7.2 release is a maintenance release of the netbsd-7 branch, which had it's first major release, NetBSD 7.0 in September 2015. A lot of security features have been added to later NetBSD versions, and for new installations we highly recommend using our latest release, NetBSD 8.0 instead. Some highlights of the 7.2 release are: Support for USB 3.0. Enhancements to the Linux emulation subsystem. Fixes in binary compatibility for ancient NetBSD executables. iwm(4) driver for Intel Wireless 726x, 316x, 826x and 416x series added. Support for Raspberry Pi 3 added. Fix interrupt setup on Hyper-V VMs with Legacy Network Adapter. SVR4 and IBCS2 compatibility subsystems have been disabled by default (besides IBCS2 on VAX). These subsystems also do not auto-load their modules any more. Various USB stability enhancements. Numerous bug fixes and stability improvements. Complete source and binaries for NetBSD 7.2 are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at https://www.NetBSD.org/mirrors/. We encourage users who wish to install via ISO or USB disk images to download via BitTorrent by using the torrent files supplied in the images area. A list of hashes for the NetBSD 7.2 distribution has been signed with the well-connected PGP key for the NetBSD Security Officer: https://cdn.NetBSD.org/pub/NetBSD/security/hashes/NetBSD-7.2_hashes.asc NetBSD is free. All of the code is under non-restrictive licenses, and may be used without paying royalties to anyone. Free support services are available via our mailing lists and website. Commercial support is available from a variety of sources. More extensive information on NetBSD is available from our website: ##News Roundup Including optimized-out kernel symbols in dtrace on FreeBSD Have you ever had dtrace(1) on FreeBSD fail to list a probe that should exist in the kernel? This is because Clang will optimize-out some functions. The result is ctfconvert(1) will not generate debugging symbols that dtrace(1) uses to identify probes. I have a quick solution to getting those probes visible to dtrace(1). In my case, I was trying to instrument on ieee80211_ioctl_get80211, whose sister function ieee80211_ioctl_set80211 has a dtrace(1) probe in the generic FreeBSD 11 and 12 kernels. Both functions are located in /usr/src/sys/net80211/ieee80211_ioctl.c. My first attempt was to add to /etc/make.conf as follows and recompile the kernel. CFLAGS+=-O0 and -fno-inline-functions This failed to produce the dtrace(1) probe. Several other attempts failed and I was getting inconsistent compilation results (Is it me or is ieee80211_ioctl.c compiled with different flags if NO_CLEAN=1 is set?). When I manually compiled the object file by copying the compilation line for the object file and adding -O0 -fno-inline-functions, nm(1) on both the object file and kernel demonstrated that the symbol was present. I installed the kernel, rebooted and it was listed as a dtrace probe. Great! But as I continued to debug my WiFi driver (oh yeah, I’m very slowly extending rtwn(4)), I found myself rebuilding the kernel several times and frequently rebooting. Why not do this across the entire kernel? After hacking around, my solution was to modify the build scripts. My solution was to edit /usr/src/sys/conf/kern.pre.mk and modify all optimization level 2 to optimization level 0. The following is my diff(1) on FreeBSD 12.0-CURRENT. A few thoughts: This seems like a hack rather than a long-term solution. Either the problem is with the hard-coded optimization flags, or the inability to overwrite them in all places in make.conf. Removing optimizations is only something I would do in a non-production kernel, so its as if I have to choose between optimizations for a production kernel or having dtrace probes. But dtrace explicitly markets itself as not impactful on production. Using the dtrace pony as your featured image on WordPress does not render properly and must be rotated and modified. Blame Bryan Cantrill. If you have a better solution, please let me know and I will update the article, but this works for me! ###FreeBSD: UEFI Bootloader stuck on BootCurrent/BootOrder/BootInfo on Asus Motherboards (and fix!) Starting with FreeBSD CURRENT from about a few weeks of posting date, but including FreeBSD 12 alpha releases (not related to DEC Alpha), I noticed one thing: When I boot FreeBSD from UEFI on a homebuilt desktop with a Asus H87M-E motherboard, and have Root on ZFS, the bootloader gets stuck on lines like BootCurrent, BootOrder, and BootInfo. This issue occurs when I try to boot directly to efibootbootx64.efi. One person had a similar issue on a Asus H87I-PLUS motherboard. This issue may or may not exist on other Asus motherboards, desktops, or laptops. This may be specific to Asus motherboards for Intel’s Haswell, but may also exist on newer systems (e.g. Skylake) or older (e.g. Ivy Bridge) with Asus motherboards, as well as Asus desktops or laptops. There are two solutions to this problem: Use Legacy BIOS mode instead of UEFI mode Install a FreeBSD UEFI Boot entry Keep in mind that I am not going to talk about this issue and third-party UEFI boot managers such as rEFInd here. The first option is rather straightforward: you need to make sure your computer has “Secure Boot” disabled and “Legacy Boot” or “CSM” enabled. Then, you need to make sure FreeBSD is installed in BIOS mode. However, this solution is (in my opinion) suboptimal. Why? Because: You won’t be able to use hard drives bigger than 2TB You are limited to MBR Partitioning on Asus motherboards with UEFI as Asus motherboards refuse to boot GPT partitioned disks in BIOS mode Legacy BIOS mode may not exist on future computers or motherboards (although those systems may not have this issue, and this issue may get fixed by then) The second option, however, is less straightforward, but will let you keep UEFI. Many UEFI systems, including affected Asus motherboards described here, include a boot manager built into the UEFI. FreeBSD includes a tool called efibootmgr to manage this, similar to the similarly-named tool in Linux, but with a different syntax. ###Why ed(1) is not a good editor today I’ll start with my tweet: Heretical Unix opinion time: ed(1) may be the 'standard Unix editor', but it is not a particularly good editor outside of a limited environment that almost never applies today. There is a certain portion of Unixdom that really likes ed(1), the ‘standard Unix editor’. Having actually used ed for a not insignificant amount of time (although it was the friendlier ‘UofT ed’ variant), I have some reactions to what I feel is sometimes overzealous praise of it. One of these is what I tweeted. The fundamental limitation of ed is that it is what I call an indirect manipulation interface, in contrast to the explicit manipulation interfaces of screen editors like vi and graphical editors like sam (which are generally lumped together as ‘visual’ editors, so called because they actually show you the text you’re editing). When you edit text in ed, you have some problems that you don’t have in visual editors; you have to maintain in your head the context of what the text looks like (and where you are in it), you have to figure out how to address portions of that text in order to modify them, and finally you have to think about how your edit commands will change the context. Copious use of ed’s p command can help with the first problem, but nothing really deals with the other two. In order to use ed, you basically have to simulate parts of ed in your head. Ed is a great editor in situations where the editor explicitly presenting this context is a very expensive or outright impossible operation. Ed works great on real teletypes, for example, or over extremely slow links where you want to send and receive as little data as possible (and on real teletypes you have some amount of context in the form of an actual printout that you can look back at). Back in the old days of Unix, this described a fairly large number of situations; you had actual teletypes, you had slow dialup links (and later slow, high latency network links), and you had slow and heavily overloaded systems. However, that’s no longer the situation today (at least almost all of the time). Modern systems and links can easily support visual editors that continually show you the context of the text and generally let you more or less directly manipulate it (whether that is through cursoring around it or using a mouse). Such editors are easier and faster to use, and they leave you with more brainpower free to think about things like the program you’re writing (which is the important thing). If you can use a visual editor, ed is not a particularly good editor to use instead; you will probably spend a lot of effort (and some amount of time) on doing by hand something that the visual editor will do for you. If you are very practiced at ed, maybe this partly goes away, but I maintain that you are still working harder than you need to be. The people who say that ed is a quite powerful editor are correct; ed is quite capable (although sadly limited by only editing a single file). It’s just that it’s also a pain to use. (They’re also correct that ed is the foundation of many other things in Unix, including sed and vi. But that doesn’t mean that the best way to learn or understand those things is to learn and use ed.) This doesn’t make ed a useless, vestigial thing on modern Unix, though. There are uses for ed in non-interactive editing, for example. But on modern Unix, ed is a specialized tool, much like dc. It’s worth knowing that ed is there and roughly what it can do, but it’s probably not worth learning how to use it before you need it. And you’re unlikely to ever be in a situation where it’s the best choice for interactive editing (and if you are, something has generally gone wrong). (But if you enjoy exploring the obscure corners of Unix, sure, go for it. Learn dc too, because it’s interesting in its own way and, like ed, it’s one of those classical old Unix programs.) ##Beastie Bits Is there any interest in a #BSD user group in #Montreal? Tell your BSD story Finishing leftover tasks from Google Summer of Code Fuzzing the OpenBSD Kernel ARM - any Tier-1 *BSD options? ##Feedback/Questions Chris - byhve question Paulo - Topic suggestion Bostjan - How data gets to disk Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

Take Up Code
243: How To Install Linux, GCC, GDB, Git, CMake, LLVM, Clang, Boost, SFML, CodeLite, Sublime Text 3, And Dropbox On a $140 Lenovo ideapad 120S.

Take Up Code

Play Episode Listen Later Sep 17, 2018 11:27


Installing Linux, GCC, GDB, Git, CMake, LLVM, Clang, Boost, SFML, CodeLite, Sublime Text 3, And Dropbox On a $140 Lenovo ideapad 120S makes an ultra portable C++ programming laptop.

BSD Now
Episode 242: Linux Takes The Fastpath | BSD Now 242

BSD Now

Play Episode Listen Later Apr 18, 2018 83:20


TrueOS Stable 18.03 released, a look at F-stack, the secret to an open source business model, intro to jails and jail networking, FreeBSD Foundation March update, and the ipsec Errata. Headlines TrueOS STABLE 18.03 Release The TrueOS team is pleased to announce the availability of a new STABLE release of the TrueOS project (version 18.03). This is a special release due to the security issues impacting the computing world since the beginning of 2018. In particular, mitigating the “Meltdown” and “Spectre” system exploits make it necessary to update the entire package ecosystem for TrueOS. This release does not replace the scheduled June STABLE update, but provides the necessary and expected security updates for the STABLE release branch of TrueOS, even though this is part-way through our normal release cycle. Important changes between version 17.12 and 18.03 “Meltdown” security fixes: This release contains all the fixes to FreeBSD which mitigate the security issues for systems that utilize Intel-based processors when running virtual machines such as FreeBSD jails. Please note that virtual machines or jails must also be updated to a version of FreeBSD or TrueOS which contains these security fixes. “Spectre” security mitigations: This release contains all current mitigations from FreeBSD HEAD for the Spectre memory-isolation attacks (Variant 2). All 3rd-party packages for this release are also compiled with LLVM/Clang 6 (the “retpoline” mitigation strategy). This fixes many memory allocation issues and enforces stricter requirements for code completeness and memory usage within applications. Unfortunately, some 3rd-party applications became unavailable as pre-compiled packages due to non-compliance with these updated standards. These applications are currently being fixed either by the upstream authors or the FreeBSD port maintainers. If there are any concerns about the availability of a critical application for a specific workflow, please search through the changelog of packages between TrueOS 17.12 and 18.03 to verify the status of the application. Most systems will need microcode updates for additional Spectre mitigations. The microcode updates are not enabled by default. This work is considered experimental because it is in active development by the upstream vendors. If desired, the microcode updates are available with the new devcpu-data package, which is available in the Appcafe. Install this package and enable the new microcode_update service to apply the latest runtime code when booting the system. Important security-based package updates LibreSSL is updated from version 2.6.3 -> 2.6.4 Reminder: LibreSSL is used on TrueOS to build any package which does not explicitly require OpenSSL. All applications that utilize the SSL transport layer are now running with the latest security updates. Browser updates: (Keep in mind that many browsers have also implemented their own security mitigations in the aftermath of the Spectre exploit.) Firefox: 57.0.1 -> 58.0.2 Chromium: 61.0.3163.100 -> 63.0.3239.132 Qt5 Webengine (QupZilla, Falkon, many others): 5.7.1 -> 5.9.4 All pre-compiled packages for this release are built with the latest versions of LLVM/Clang, unless the package explicitly requires GCC. These packages also utilize the latest compile-time mitigations for memory-access security concerns. F-Stack F-Stack is an user space network development kit with high performance based on DPDK, FreeBSD TCP/IP stack and coroutine API. http://www.f-stack.org Introduction With the rapid development of NIC, the poor performance of data packets processing with Linux kernel has become the bottleneck. However, the rapid development of the Internet needs high performance of network processing, kernel bypass has caught more and more attentions. There are various similar technologies appear, such as DPDK, NETMAP and PF_RING. The main idea of kernel bypass is that Linux is only used to deal with control flow, all data streams are processed in user space. Therefore, kernel bypass can avoid performance bottlenecks caused by kernel packet copying, thread scheduling, system calls and interrupts. Furthermore, kernel bypass can achieve higher performance with multi optimizing methods. Within various techniques, DPDK has been widely used because of its more thorough isolation from kernel scheduling and active community support. F-Stack is an open source network framework with high performance based on DPDK. With following characteristics Ultra high network performance which can achieve network card under full load, 10 million concurrent connections, 5 million RPS, 1 million CPS. Transplant FreeBSD 11.01 user space stack, provides a complete stack function, cut a great amount of irrelevant features. Therefore greatly enhance the performance. Support Nginx, Redis and other mature applications, service can easily use F-Stack With Multi-process architecture, easy to extend Provide micro thread interface. Various applications with stateful app can easily use F-Stack to get high performance without processing complex asynchronous logic. Provide Epoll/Kqueue interface that allow many kinds of applications easily use F-Stack History In order to deal with the increasingly severe DDoS attacks, authorized DNS server of Tencent Cloud DNSPod switched from Gigabit Ethernet to 10-Gigabit at the end of 2012. We faced several options, one is to continue to use the original model another is to use kernel bypass technology. After several rounds of investigation, we finally chose to develop our next generation of DNS server based on DPDK. The reason is DPDK provides ultra-high performance and can be seamlessly extended to 40G, or even 100G NIC in the future. After several months of development and testing, DKDNS, high-performance DNS server based on DPDK officially released in October 2013. It's capable of achieving up to 11 million QPS with a single 10GE port and 18.2 million QPS with two 10GE ports. And then we developed a user-space TCP/IP stack called F-Stack that can process 0.6 million RPS with a single 10GE port. With the fast growth of Tencent Cloud, more and more services need higher network access performance. Meanwhile, F-Stack was continuous improving driven by the business growth, and ultimately developed into a general network access framework. But this TCP/IP stack couldn't meet the needs of these services while continue to develop and maintain a complete network stack will cost high, we've tried several plans and finally determined to port FreeBSD(11.0 stable) TCP/IP stack into F-Stack. Thus, we can reduce the cost of maintenance and follow up the improvement from community quickly.Thanks to libplebnet and libuinet, this work becomes a lot easier. With the rapid development of all kinds of application, in order to help different APPs quick and easily use F-Stack, F-Stack has integrated Nginx, Redis and other commonly used APPs, and a micro thread framework, and provides a standard Epoll/Kqueue interface. Currently, besides authorized DNS server of DNSPod, there are various products in Tencent Cloud has used the F-Stack, such as HttpDNS (D+), COS access module, CDN access module, etc.. iXsystems Leadership Is The Secret To An Open Source Business Model A Forbes article by Mike Lauth, CEO of iXsystems There is a good chance you’ve never heard of open source software and an even greater one that you’re using it every day without even realizing it. Open source software is computer software that is available under a variety of licenses that all encourage the sharing of the software and its underlying source code. Open source has powered the internet from day one and today powers the cloud and just about everything connected to it from your mobile phone to virtually every internet of things device. FreeNAS is one of two open source operating systems that my company, iXsystems, develops and distributes free of charge and is at the heart of our line of TrueNAS enterprise storage products. While some of our competitors sell storage software similar to FreeNAS, we not only give it away but also do so with truly no strings attached -- competitors can and do take FreeNAS and build products based on it with zero obligation to share their changes. The freedom to do so is the fundamental tenet of permissively licensed open source software, and while it sounds self-defeating to be this generous, we’ve proven that leadership, not licensing, is the true secret to a successful open source business model. We each have our own personal definition of what is fair when it comes to open source. At iXsystems, we made a conscious decision to base FreeNAS and TrueOS on the FreeBSD operating system developed by the FreeBSD project. We stand on the shoulders of giants by using FreeBSD and we consider it quite reasonable to give back on the same generous terms that the FreeBSD project offers us. We could be selective in what we provide free of charge, but we believe that doing so would be short-sighted. In the long game we’re playing, the leadership we provide over the open source projects we produce is infinitely more important than any restrictions provided by the licenses of those and other open source projects. Twenty years in, we have no reason to change our free-software-on-great-hardware business model and giving away the software has brought an unexpected side-benefit: the largest Q/A department in the world, staffed by our passionate users who volunteer to let us know every thought they have about our software. We wouldn’t change a thing, and I encourage you to find exactly what win-win goodwill you and your company can provide to your constituents to make them not just a customer base but a community. Drive The Conversation It took a leap of faith for us to give away the heart of our products in exchange for a passionate community, but doing so changes your customer's relationship with your brand from priced to priceless. This kind of relationship leverages a social contract instead of a legal one. Taking this approach empowers your users in ways they will not experience with other companies and it is your responsibility to lead, rather than control them with a project like FreeNAS Relieve Customer Pain Points With Every New Release Responsiveness to the needs of your constituents is what distinguishes project leadership from project dictatorship. Be sure to balance your vision for your products and projects with the “real world” needs of your users. While our competition can use the software we develop, they will at best wow users with specific features rather than project-wide ones. Never underestimate how grateful a user will be when you make their job easier. Accept That A Patent Is Not A Business Model Patents are considered the ultimate control mechanism in the technology industry, but they only provide a business model if you have a monopoly and monopolies are illegal. Resist getting hung up on the control you can establish over your customers and spend your time acquiring and empowering them. The moment you both realize that your success is mutual, you have a relationship that will last longer than any single sale. You’ll be pleasantly surprised how the relationships you build will transcend the specific companies that friends you make work for. Distinguish Leadership From Management Every company has various levels of management, but leadership is the magic that creates markets where they did not exist and aligns paying customers with value that you can deliver in a profitable manner. Leadership and vision are ultimately the most proprietary aspects of a technology business, over every patentable piece of hardware or licensable piece of software. Whether you create a new market or bring efficiency to an existing one, your leadership is your secret weapon -- not your level of control. News Roundup Introduction to Jails and Jail Networking on FreeBSD Jails basically partition a FreeBSD system into various isolated sub-systems called jails. The syscall and userspace tools first appeared in FreeBSD 4.0 (~ March 2000) with subsequent releases expanding functionality and improving existing features as well as usability. + For Linux users, jails are similar to LXC, used for resource/process isolation. Unlike LXC however, jails are a first-class concept and are well integrated into the base system. Essentially however, both offer a chroot-with-extra-separation feeling. Setting up a jail is a fairly simple process, which can essentially be split into three steps: + Place the stuff you want to run and the stuff it needs to run somewhere on your filesystem. + Add some basic configuration for the jail in jail.conf. + Fire up the jail. To confirm that the jail started successfully we can use the jls utility: We can now enter the jailed environment by using jexec, which will by default execute a root shell inside the named jail A jail can only see and use addresses that have been passed down to it by the parent system. This creates a slight problem with the loopback address: The host would probably like to keep that address to itself and not share it with any jail. Because of this, the loopback-address inside a jail is emulated by the system: + 127.0.0.1 is an alias for the first IPv4-address assigned to the jail. + ::1 is an alias for the first IPv6-address assigned to the jail. While this looks simple enough and usually works just fine[tm], it is also a source of many problems. Just imagine if your jail has only one single global IPv4 assigned to it. A daemon binding its (possibly unsecured) control port to the loopback-address would then unwillingly be exposed to the rest of the internet, which is hardly ever a good idea. + So, create an extra loopback adapter, and make the first IP in each jail a private loopback address + The tutorial goes on to cover making multiple jails share a single public IP address using NAT + It also covers more advanced concepts like ‘thin’ jails, to save some disk space if you are going to create a large number of jails, and how to upgrade them after the fact + Finally, it covers the integration with a lot of common tools, like identifying and filter jailed processes using top and ps, or using the package managers support for jails to install packages in a jail from the outside. **DigitalOcean** SmartOS release-20180315 ``` Hello All, The latest bi-weekly "release" branch build of SmartOS is up: curl -C - -O https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.iso curl -C - -O https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest-USB.img.bz2 curl -C - -O https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.vmwarevm.tar.bz2 A generated changelog is here: https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20180329T002644Z The full build bits directory, for those interested, is here in Manta: /Joyent_Dev/public/SmartOS/20180329T002644Z Highlights Firewall rules created with fwadm(1M) can now use the PRIORITY keyword to specify a higher precedence for a rule. This release has includes mitigation of the Intel Meltdown vulnerability in the form of kpti (kernel page table isolation) with PCID (process context identifier) support This release also includes experimental support for bhyve branded zones. General Info Every second Thursday we roll a "release-YYYYMMDD" release branch and builds for SmartOS (and Triton DataCenter and Manta, as well). Cheers, Josh Wilsdon, on behalf of the SmartOS developers https://smartos.org ``` Here's a screencap from q5sys' machine showing the output of sysinfo: https://i.imgur.com/MFkNi76.jpg FreeBSD Foundation March 2018 Update > Syzkaller update: Syzkaller is a coverage-guided system call fuzzer. It invokes syscalls with arbitrary and changing inputs, and is intended to use code coverage data to guide changes to system call inputs in order to access larger and larger portions of the kernel in the search for bugs. > Last term’s student focused largely on scripts to deploy and configure Syzkaller on Packet.net’s hosting infrastructure, but did not get to the code coverage integration required for Syzkaller to be effective. This term co-op student Mitchell Horne has been adding code coverage support in FreeBSD for Syzkaller. > The Linux code coverage support for Syzkaller is known as kcov and was submitted by Dmitry Vyukov, Syzkaller’s author. Kcov is purposebuilt for Syzkaller: > kcov provides code coverage collection for coverage-guided fuzzing (randomized testing). Coverage-guided fuzzing is a testing technique that uses coverage feedback to determine new interesting inputs to a system. > kcov does not aim to collect as much coverage as possible. It aims to collect more or less stable coverage that is function of syscall inputs. To achieve this goal it does not collect coverage in soft/hard interrupts and instrumentation of some inherently non-deterministic or non-interesting parts of kernel is disabled (e.g. scheduler, locking). > Mitchell implemented equivalent functionality for FreeBSD - a distinct implementation, but modelled on the one in Linux. These patches are currently in review, as are minor changes to Syzkaller to use the new interface on FreeBSD. > We still have some additional work to fully integrate Syzkaller and run it on a consistent basis, but the brief testing that has been completed suggests this work will provide a very valuable improvement in test coverage and opportunities for system hardening: we tested Syzkaller with Mitchell's code coverage patch over a weekend. It provoked kernel crashes hundreds of times faster than without his work. > I want to say thank you to NetApp for becoming an Iridium Partner again this year! (Donations between $100,000 - $249,999) It’s companies like NetApp, who recognize the importance of supporting our efforts, that allow us to continue to provide software improvements, advocate for FreeBSD, and help lead the release engineering and security efforts. > Conference Recap: FOSSASIA 2018 Foundation Director Philip Paeps went to FOSSASIA, which is possibly the largest open source event in Asia. The FreeBSD Foundation sponsored the conference. Our booth had a constant stream of traffic over the weekend and we handed out hundreds of FreeBSD stickers, pens and flyers. Many attendees of FOSSASIA had never heard of FreeBSD before and are now keen to start exploring and perhaps even contributing. By the end of the conference, there were FreeBSD stickers everywhere! > One particular hallway-track conversation led to an invitation to present FreeBSD at a "Women Who Code" evening in Kuala Lumpur later this week (Thursday 29th March). I spent the days after the conference meeting companies who use (or want to use) FreeBSD in Singapore. > SCaLE 16x: The Foundation sponsored a FreeBSD table in the expo hall that was staffed by Dru Lavigne, Warren Block, and Deb Goodkin. Our purpose was to promote FreeBSD, and attract more users and contributors to the Project. We had a steady flow of people stopping by our table, asking inquisitive questions, and picking up some cool swag and FreeBSD handouts. Deb Goodkin took some tutorials/trainings there and talked to a lot of other open source projects. Next year, we have the opportunity to have a BSD track, similar to the BSD Devroom at FOSDEM. We are looking for some volunteers in Southern California who can help organize this one or two-day event and help us educate more people about the BSDs. Let us know if you would like to help with this effort. Roll Call: #WhoUsesFreeBSD Many of you probably saw our post on social media asking Who Uses FreeBSD. Please help us answer this question to assist us in determining FreeBSD market share data, promote how companies are successfully using FreeBSD to encourage more companies to embrace FreeBSD, and to update the list of users on our website. Knowing who uses FreeBSD helps our contributors know where to look for jobs; knowing what universities teach with FreeBSD, helps companies know where to recruit, and knowing what products use FreeBSD helps us determine what features and technologies to support. New Hosting Partner: Oregon State University Open Source Lab > We are pleased to announce that the Oregon State University (OSU) Open Source Lab (OSL), which hosts infrastructure for over 160 different open source projects, has agreed to host some of our servers for FreeBSD development. The first server, which should be arriving shortly, is an HP Enterprise Proliant DL360 Gen10 configured with NVDIMM memory which will be initially used for further development and testing of permanent memory support in the kernel. Stay tuned for more news from the FreeBSD Foundation in May (next newsletter). Beastie Bits cURL is 20 today A Note on SYSVIPC and Jails on FreeBSD OpenBSD Errata: March 20th, 2018 (ipsec) FreeBSD Security Advisories for IPSEC and vt 23 Useful PKG Command Examples to Manage Packages in FreeBSD Tarsnap Feedback/Questions Casey - Cool Editor Nelson - New article on FreeBSD vs MacOS Damian - Mysterious Reverse Proxy 504 Nelson - FreeBSD, rsync, nasty bug, now fixed Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

BSD Now
177: Getting Pi on my Wifi

BSD Now

Play Episode Listen Later Jan 18, 2017 78:42


This week on BSDNow, we've got Wifi galore, a new iocage and some RPi3 news and guides to share. Stay tuned for your place to B...SD! This episode was brought to you by Headlines WiFi: 11n hostap mode added to athn(4) driver, testers wanted (http://undeadly.org/cgi?action=article&sid=20170109213803) “OpenBSD as WiFi access points look set to be making a comeback in the near future” “Stefan Sperling added 802.11n hostap mode, with full support initially for the Atheros chips supported by the athn(4) driver.” “Hostap performance is not perfect yet but should be no worse than 11a/b/g modes in the same environment.” “For Linux clients a fix for WME params is needed which I also posted to tech@” “This diff does not modify the known-broken and disabled ar9003 code, apart from making sure it still builds.” “I'm looking for both tests and OKs.” There has also been a flurry of work (http://svnweb.freebsd.org/base/head/sys/net80211/?view=log) in FreeBSD on the ath10k driver, which supports 802.11ac Like this one (https://svnweb.freebsd.org/base?view=revision&revision=310147) and this one (https://svnweb.freebsd.org/base?view=revision&revision=311579) The long-awaited iocage update has landed (https://github.com/iocage/iocage) We've hinted at the new things happening behind the scenes with iocage, and this last week the code has made its first public debut. So what's changed you may ask. The biggest is that iocage has undergone a complete overhaul, moving from its original shell-base to python. The story behind that is that the author (Brandon) works at iXsystems, and the plan is to move away from the legacy warden-based jail management which was also shell-based. This new python re-write will allow it to integrate into FreeNAS (and other projects) better by exposing an API for all jail management tasks. Thats right, no more ugly CLI output parsing just to wrangle jail options either at creation or runtime. But what about users who just run iocage manually from the CLI? No worries, the new iocage is almost identical to the original CLI usage, making the switch over very simple. Just to re-cap, lets look at the new features list: “FEATURES: + Ease of use + Rapid jail creation within seconds + Automatic package installation + Virtual networking stacks (vnet) + Shared IP based jails (non vnet) + Transparent ZFS snapshot management + Export and import “ + The new iocage is available now via ports and packages under sysutils/py-iocage, give it a spin and be sure to report issues back to the developer(s). Reading DHT11 temperature sensors on a Raspberry Pi under FreeBSD (https://smallhacks.wordpress.com/2017/01/14/reading-dht11-temperature-sensor-on-raspberry-pi-under-freebsd/) “DHT-11 is a very cheap temperature/humidity sensor which is commonly used in the IoT devices. It is not very accurate, so for the accurate measurement i would recommend to use DHT21 instead. Anyway, i had DHT-11 in my tool box, so decided to start with it. DHT-11 using very simple 1 wire protocol – host is turning on chip by sending 18ms low signal to the data output and then reading 40 bytes of data.” “To read data from the chip it should be connected to the power (5v) and gpio pin. I used pin 2 as VCC, 6 as GND and 11 as GPIO” “There is no support for this device out of the box on FreeBSD. I found some sample code on the github, see lex/freebsd-gpio-dht11 (https://github.com/lex/freebsd-gpio-dht11) repository. This code was a good starting point, but soon i found 2 issues with it: Results are very unreliable, probably due to gpio decoding algorithm. Checksum is not validated, so sometime values are bogus. “Initially i was thinking to fix this myself, but later found kernel module for this purpose, 1 wire over gpio (http://www.my-tour.ru/FreeBSD/1-wire_over_gpio/). This module contains DHT11 kernel driver (gpio_sw) which implements DHT-11 protocol in the kernel space and exporting /dev/sw0 for the userland. Driver compiles on FreeBSD11/ARM without any changes. Use make install to install the driver.” The articles goes into how to install and configure the driver, including a set of devfs rules to allow non-root users to read from the sensor “Final goal was to add this sensor to the domoticz software. It is using LUA scripting to extend it functionality, e.g. to obtain data from non-supported or non standard devices. So, i decided to read /dev/sw0 from the LUA.” They ran into some trouble with LUA trying to read too much data at once, and had to work around it In the end, they got the results and were able to use them in the monitoring tool *** Tor-ified Home Network using HardenedBSD and a RPi3 (https://github.com/lattera/articles/blob/master/infosec/tor/2017-01-14_torified_home/article.md) Shawn from HardendBSD has posted an article up on GitHub talking about his deployment of a new Tor relay on a RPi3 This particular method was attractive, since it allows running a Relay, but without it being on a machine which may have personal data, such as SSH keys, files, etc While his setup is done on HardendBSD, the same applies to a traditional FreeBSD setup as well. First up, is the list of things needed for this project: Raspberry Pi 3 Model B Rev 1.2 (aka, RPI3) Serial console cable for the RPI3 Belkin F4U047 USB Ethernet Dongle Insignia NS-CR2021 USB 2.0 SD/MMC Memory Card Reader 32GB SanDisk Ultra PLUS MicroSDHC A separate system, running FreeBSD or HardenedBSD HardenedBSD clang 4.0.0 image for the RPI3 An external drive to be formatted A MicroUSB cable to power the RPI3 Two network cables Optional: Edimax N150 EW-7811Un Wireless USB Basic knowledge of vi After getting HBSD running on the RPi3 and serial connection established, he then takes us through the process of installing and enabling the various services needed. (Don't forget to growfs your sdcard first!) Now the tricky part is that some of the packages needed to be compiled from ports, which is somewhat time-consuming on a RPi. He strongly recommends not compiling on the sdcard (it sounds like personal experience has taught him well) and to use iscsi or some external USB drive. With the compiling done, our package / software setup is nearly complete. Next up is firewalling the box, which he helpfully provides a full PF config setup that we can copy-n-paste here. The last bits will be enabling the torrc configuration knobs, which if you follow his example again, will result in a tor public relay, and a local transparent proxy for you. Bonus! Shawn helpfully provides DHCPD configurations, and even Wireless AP configurations, if you want to setup your RPi3 to proxy for devices that connect to it. *** News Roundup Unix Admin. Horror Story Summary, version 1.0 (http://www-uxsup.csx.cam.ac.uk/misc/horror.txt) A great collection of stories, many of which will ring true with our viewers The very first one, is about a user changing root's shell to /usr/local/bin/tcsh but forgetting to make it executable, resulting in not being able to login as root. I too have run into this issue, in a slightly different way. I had tcsh as my user shell (back before tcsh was in base), and after a major OS upgrade, but before I had a chance to recompile all of my ports. Now I couldn't ssh in to the remote machine in order to recompile my shell. Now I always use a shell included in the base system, and test it before rebooting after an upgrade. “Our operations group, a VMS group but trying to learn UNIX, was assigned account administration. They were cleaning up a few non-used accounts like they do on VMS - backup and purge. When they came across the account "sccs", which had never been accessed, away it went. The "deleteuser" utility from DEC asks if you would like to delete all the files in the account. Seems reasonable, huh? Well, the home directory for "sccs" is "/". Enough said :-(“ “I was working on a line printer spooler, which lived in /etc. I wanted to remove it, and so issued the command "rm /etc/lpspl." There was only one problem. Out of habit, I typed "passwd" after "/etc/" and removed the password file. Oops.” I've done things like this as well. Finger memory can be dangerous “I was happily churning along developing something on a Sun workstation, and was getting a number of annoying permission denieds from trying to write into a directory heirarchy that I didn't own. Getting tired of that, I decided to set the permissions on that subtree to 777 while I was working, so I wouldn't have to worry about it. Someone had recently told me that rather than using plain "su", it was good to use "su -", but the implications had not yet sunk in. (You can probably see where this is going already, but I'll go to the bitter end.) Anyway, I cd'd to where I wanted to be, the top of my subtree, and did su -. Then I did chmod -R 777. I then started to wonder why it was taking so damn long when there were only about 45 files in 20 directories under where I (thought) I was. Well, needless to say, su - simulates a real login, and had put me into root's home directory, /, so I was proceeding to set file permissions for the whole system to wide open. I aborted it before it finished, realizing that something was wrong, but this took quite a while to straighten out.” Where is a ZFS snapshot when you need it? *** How individual contributors get stuck (https://medium.com/@skamille/how-do-individual-contributors-get-stuck-63102ba43516) An interesting post looking at the common causes of people getting stuck when trying to create or contribute new code Brainstorming/architecture: “I must have thought through all edge cases of all parts of everything before I can begin this project” Researching possible solutions forever (often accompanied by desire to do a “bakeoff” where they build prototypes in different platforms/languages/etc) Refactoring: “this code could be cleaner and everything would be just so much easier if we cleaned this up… and this up… and…” Helping other people instead of doing their assigned tasks (this one isn't a bad thing in an open source community) Working on side projects instead of the main project (it is your time, it is up to you how to spend it) Excessive testing (rare) Excessive automation (rare) Finish the last 10–20% of a project Start a project completely from scratch Do project planning (You need me to write what now? A roadmap?) (this is why FreeBSD has devsummits, some things you just need to whiteboard) Work with unfamiliar code/libraries/systems Work with other teams (please don't make me go sit with data engineering!!) Talk to other people Ask for help (far beyond the point they realized they were stuck and needed help) Deal with surprises or unexpected setbacks Deal with vendors/external partners Say no, because they can't seem to just say no (instead of saying no they just go into avoidance mode, or worse, always say yes) “Noticing how people get stuck is a super power, and one that many great tech leads (and yes, managers) rely on to get big things done. When you know how people get stuck, you can plan your projects to rely on people for their strengths and provide them help or even completely side-step their weaknesses. You know who is good to ask for which kinds of help, and who hates that particular challenge just as much as you do.” “The secret is that all of us get stuck and sidetracked sometimes. There's actually nothing particularly “bad” about this. Knowing the ways that you get hung up is good because you can choose to either a) get over the fears that are sticking you (lack of knowledge, skills, or confidence), b) avoid such tasks as much as possible, and/or c) be aware of your habits and use extra diligence when faced with tackling these areas.” *** Make Docs! (http://www.mkdocs.org/) “MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file.” “MkDocs builds completely static HTML sites that you can host on GitHub pages, Amazon S3, or anywhere else you choose” It is an easy to install python package It includes a server mode that auto-refreshes the page as you write the docs, making it easy to preview your work before you post it online Everything needs docs, and writing docs should be as simple as possible, so that more of them will get written Go write some docs! *** Experimental FreeNAS 11/12 builds (https://forums.freenas.org/index.php?threads/new-freenas-9-10-with-freebsd-11-12-for-testing.49696/#post-341941) We know there's a lot of FreeNAS users who listen to BSDNow, so I felt it was important to share this little tidbit. I've posted something to the forums last night which includes links to brand-new spins of FreeNAS 9.10 based upon FreeBSD 11/stable and 12/current. These builds are updated nightly via our Jenkins infrastructure and hopefully will provide a new playground for technical folks and developers to experiment with FreeBSD features in their FreeNAS environment, long before they make it into a -STABLE release. As usual, the notes of caution do apply, these are nightlies, and as such bugs will abound. Do NOT use these with your production data, unless you are crazy, or just want an excuse to test your backup strategy If you do run these builds, of course feedback is welcome via the usual channels, such as the bug tracker. The hope is that by testing FreeBSD code earlier, we can vet and determine what is safe / ready to go into mainline FreeNAS sooner rather than later. *** Beastie Bits An Explainer on Unix's Most Notorious Code Comment (http://thenewstack.io/not-expected-understand-explainer/) turn your network inside out with one pf.conf trick (http://www.tedunangst.com/flak/post/turn-your-network-inside-out-with-one-pfconf-trick) A story of if_get(9) (http://www.grenadille.net/post/2017/01/13/A-story-of-if_get%289%29) Apple re-affirms its commitment to LLVM/Clang (http://lists.llvm.org/pipermail/llvm-dev/2017-January/108953.html) python 3k17 (http://www.tedunangst.com/flak/post/python-3k17) 2017 presentation proposals (http://blather.michaelwlucas.com/archives/2848) NetBSD 7.1_RC1 available (http://mail-index.netbsd.org/netbsd-announce/2017/01/09/msg000259.html) #define FSUFS2MAGIC 0x19540119 (Happy Birthday to Kirk McKusick tomorrow) *** Feedback/Questions J - LetsEncrypt (http://pastebin.com/nnQ9ZgyN) Mike - OpenRC (http://pastebin.com/EZ4tRiVb) Timothy - ZFS Horror (http://pastebin.com/ZqDFTsnR) Troels (http://pastebin.com/dhZEnREM) Jason - Disk Label (http://pastebin.com/q4F95S6h) ***

bsdtalk
bsdtalk233 - From GCC to LLVM/CLANG with David Chisnall

bsdtalk

Play Episode Listen Later Sep 13, 2015


Recording of the vBSDCon 2013 talk "Migrating from GCC to LLVM/CLANG" with David Chisnall.File Info: 1hour, 31MB.Ogg Link: https://archive.org/download/bsdtalk233/bsdtalk233.ogg

BSD Now
36: Let's Get RAID

BSD Now

Play Episode Listen Later May 7, 2014 90:47


This week on the show we'll be showing you how to set up RAID arrays in both FreeBSD and OpenBSD. There's also an interview with David Chisnall - of the FreeBSD core team - about the switch to Clang and a lot more. As usual, we'll be dropping the latest news and answering your emails, so sit back and enjoy some BSD Now - the place to B.. SD. This episode was brought to you by Headlines OpenBSD 5.5 released (http://www.openbsd.org/55.html) If you ordered (https://https.openbsd.org/cgi-bin/order) a CD set (https://twitter.com/blakkheim/status/461909893813784576) then you've probably had it for a little while already, but OpenBSD has formally announced the public release (http://undeadly.org/cgi?action=article&sid=20140501153339) of 5.5 This is one of the biggest releases to date, with a very long list of changes and improvements Some of the highlights include: time_t being 64 bit on all platforms, release sets and binary packages being signed with the new signify tool, a new autoinstall feature of the installer, SMP support on Alpha, a new AViiON port, lots of new hardware drivers including newer NICs, the new vxlan driver, relayd improvements, a new pf queue system for bandwidth shaping, dhcpd and dhclient fixes, OpenSMTPD 5.4.2 and all its new features, position-independent executables being default for i386, the RNG has been replaced with ChaCha20 as well as some other security improvements, FUSE support, tmpfs, softraid partitions larger than 2TB and a RAID 5 implementation, OpenSSH 6.6 with all its new features and fixes... and a lot more The full list of changes (http://www.openbsd.org/plus55.html) is HUGE, be sure to read through it all if you're interested in the details If you're doing an upgrade from 5.4 instead of a fresh install, pay careful attention to the upgrade guide (http://www.openbsd.org/faq/upgrade55.html) as there are some very specific steps for this version Also be sure to apply the errata patches (http://www.openbsd.org/errata55.html) on your new installations... especially those OpenSSL ones (some of which still aren't fixed (http://marc.info/?l=oss-security&m=139906348230995&w=2) in the other BSDs yet) On the topic of errata patches, the project is now going to also send them out (signed (http://undeadly.org/cgi?action=article&sid=20140502103355)) via the announce mailing list (http://lists.openbsd.org/cgi-bin/mj_wwwusr?user=&passw=&func=lists-long-full&extra=announce), a very welcome change Congrats to the whole team on this great release - 5.6 is going to be even more awesome with "Libre"SSL and lots of other stuff that's currently in development *** FreeBSD foundation funding highlights (http://freebsdfoundation.blogspot.com/2014/04/freebsd-foundation-spring-fundraising_28.html) The FreeBSD foundation posts a new update on how they're spending the money that everyone donates "As we embark on our 15th year of serving the FreeBSD Project and community, we are proud of what we've done to help FreeBSD become the most innovative, reliable, and high-performance operation system" During this spring, they want to highlight the new UEFI boot support and newcons (http://freebsdfoundation.blogspot.com/2014/05/freebsd-foundation-newcons-project.html) There's a lot of details about what exactly UEFI is and why we need it going forward FreeBSD has also needed some updates to its console to support UTF8 and wide characters Hopefully this series will continue and we'll get to see what other work is being sponsored *** OpenSSH without OpenSSL (http://marc.info/?l=openbsd-cvs&m=139879453001957&w=2) The OpenSSH team has been hard at work, making it even better, and now OpenSSL is completely optional Since it won't have access to the primitives OpenSSL uses, there will be a trade-off of features vs. security This version will drop support for legacy SSH v1, and the only two cryptographic algorithms supported are an in-house implementation of AES in counter mode and the new combination (http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.chacha20poly1305?rev=HEAD;content-type=text%2Fplain) of the Chacha20 stream cipher with Poly1305 for packet integrity Key exchange is limited to elliptic curve Diffie-Hellman and the newer Curve25519 KEXs No support for RSA, DSA or ECDSA public keys - only Ed25519 It also includes a new buffer API (http://marc.info/?l=openbsd-cvs&m=139883582313750&w=2) and a set of wrappers to make it compatible with the existing API Believe it or not, this was planned before all the heartbleed craziness Maybe someday soon we'll have a mini-openssh-portable in FreeBSD ports and NetBSD pkgsrc, would be really neat *** BSDMag's April 2014 issue is out (http://bsdmag.org/magazine/1861-free-pascal-on-bsd-april-bsd-issue) The free monthly BSD magazine has got a new issue available for download This time the articles include: pascal on BSD, an introduction to revision control systems and configuration management, deploying NetBSD on AWS EC2, more GIMP tutorials, an AsiaBSDCon 2014 report and a piece about how easily credit cards are stolen online Anyone can contribute to the magazine, just send the editors an email about what you want to write No Linux articles this time around, good *** Interview - David Chisnall - theraven@freebsd.org (mailto:theraven@freebsd.org) The LLVM/Clang switch, FreeBSD's core team, various topics Tutorial RAID in FreeBSD and OpenBSD (http://www.bsdnow.tv/tutorials/raid) News Roundup BSDTalk episode 240 (http://bsdtalk.blogspot.com/2014/04/bsdtalk240-about-time-with-george.html) Our buddy Will Backman has uploaded a new episode of BSDTalk, this time with our other buddy GNN as the guest - mainly to talk about NTP and keeping reliable time Topics include the specific details of crystals used in watches and computers to keep time, how temperature affects the quality, different sources of inaccuracy, some general NTP information, why you might want extremely precise time, different time sources (GPS, satellite, etc), differences in stratum levels, the problem of packet delay and estimating the round trip time, some of the recent NTP amplification attacks, the downsides to using UDP instead of TCP and... much more GNN also talks a little about the Precision Time Protocol (https://en.wikipedia.org/wiki/Precision_Time_Protocol) and how it's different than NTP Two people (http://www.bsdnow.tv/episodes/2014_01_29-journaled_news_updates) we've interviewed (http://www.bsdnow.tv/episodes/2014_03_05-bsd_now_vs_bsdtalk) talking to each other, awesome If you're interested in NTP, be sure to see our tutorial (http://www.bsdnow.tv/tutorials/ntpd) too *** m2k14 trip reports (http://undeadly.org/cgi?action=article&sid=20140502092427) We've got a few more reports from the recent OpenBSD hackathon in Morocco The first one is from Antoine Jacoutot (who is a key GNOME porter and gave us the screenshots for the OpenBSD desktop tutorial (http://www.bsdnow.tv/tutorials/the-desktop-obsd)) "Since I always fail at actually doing whatever I have planned for a hackathon, this time I decided to come to m2k14 unprepared about what I was going to do" He got lots of work done with ports and pushing GNOME-related patches back up to the main project, then worked on fixing ports' compatibility with LibreSSL Speaking of LibreSSL, there's an article (http://undeadly.org/cgi?action=article&sid=20140505062023) all would-be portable version writers should probably read and take into consideration Jasper Adriaanse also writes (http://undeadly.org/cgi?action=article&sid=20140501185019) about what he got done over there He cleaned up and fixed the puppet port to work better with OpenBSD *** Why you should use FreeBSD on your cloud VPS (https://www.atlantic.net/blog/2014/04/08/freebsd-ssd-cloud-vps-hosting-10-reasons/) Here we have a blog post from Atlantic, a VPS and hosting provider, about 10 reasons for using FreeBSD Starts off with a little bit of BSD history for those who are unfamiliar with it and only know Linux and Windows The 10 reasons are: community, stability, collaboration, ease of use, ports, security, ZFS, GEOM, sound and having lots of options The post goes into detail about each of them and why FreeBSD makes a great choice for a VPS OS *** PCBSD weekly digest (http://blog.pcbsd.org/2014/05/weekly-feature-digest-27-software-system-redesign/) Big changes coming in the way PCBSD manages software The PBI system, AppCafe and related tools are all going to use pkgng now The AppCafe will no longer be limited to PBIs, so much more software will be easily available from the ports tree New rating system coming soon and much more *** Feedback/Questions Martin writes in (http://slexy.org/view/s21bk2oPuQ) John writes in (http://slexy.org/view/s2n9fx1Rpw) Alex writes in (http://slexy.org/view/s2rBBKLA4u) Goetz writes in (http://slexy.org/view/s20JY6ZI71) Jarrad writes in (http://slexy.org/view/s20YV5Ohpa) ***

Kodsnack
Kodsnack 41 - Genuint sur, riktigt trött och lite ärlig

Kodsnack

Play Episode Listen Later Mar 6, 2014 65:16


Peter Magnusson från bland annat Säkerhetspodcasten gästar oss och snackar Apples gotofail-äventyr, SSL, verktyg som kan hjälpa en att hitta oanvänd eller osäker kod och mycket mer. Länkar goto fail; - testsida som visar om du har buggen sslKeyExchange.c i libsecurityssl - platsen där buggen finns eller fanns if-satser goto Detaljer kring buggen RSA-kryptering Apples uppgradering av iOS 10.9.2 av OS X Buffer overflow SQL injection NSA Edward Snowden Lintverktyg - analyser av källkod som rekommenderar bra sätt att skriva kod LLVM/Clang - Apples kompilatorinfrastruktur Att få LLVM/Clang att varna för död kod Microsofts _NSAKEY @blaufish_ Peter Magnusson på Wordpress Intrångstestning Säkerhetspodcasten Säkerhetspodcasten på Twitter Kodsnack 38 - om bland annat Maven Venndiagram Unit tests - enhetstester - små tester av små delar kod Happy path Haskell Quickcheck genererar tester Rena funktioner - pure functions Enhetstestgenerator för Visual studio RFC 5246 - om TLS ssllabs.com How's my SSL? BEAST-sårbarheten Nattliga byggen av Webkit Blink - Googles egen gren av webkitprojektet Is it safe to mosh? - presentation om mosh Mosh, the mobile shell - ett alternativ till SSH FTP-protokollet och hur det gör med brandväggar FTP och kryptering Passivt läge i FTP ARPANET Computer security archive project - fullmatat med historia Säkerhetsutvärdering av Multics, från 1974 Lösenord borde avvecklas, redan 1972 Värdnamnsverifiering i SSL - slå inte av! Effekten är densamam som med gotofail-buggen DigiNotar - certifikatsutgivare som fick slå igen 2011 på grund av säkerhetshål Comodo - certifikatsföretag Digicert Sdn - malajsisk certifikatsutgivare Bitcoin Mt:gox - japansk bitcoinväxlare som fick stänga efter att stora summor stulits PGP - Pretty good privacy, mjukvara för kryptering Web of trust DNSSEC - specifikationer för att höja säkerheten i DNS-systemen Convergence för SSL och webbläsarplugin för Firefox för att se certifikat och dess ändringar PKI - public key infrastructure Ludd - Luleå academic computer society Interplanetary internet, och dess möjliga arkitektur UDP - user datagram protocol OWASP - open web application security project OWASP dependency check Retire.js Auditing Farorna med printf med %n Lint för C Splint - säkerhetsorienterat lintverktyg Find security bugs för Java PL/SQL - Oracles SQL-dialekt

Kodsnack
Kodsnack 2: Schizofrent på ett väldigt tudelat sätt

Kodsnack

Play Episode Listen Later Sep 23, 2012 48:50


Vi snackar om hur det är att börja utveckla för iOS, Objective-C, Apples utvecklingsverktyg och vad som händer när man ramlar ner i ramverkets skarvar. Viss diskussion kring hur den dynamiska duon LLVM/Clang gjort världen till en bättre plats är givetvis oundvikligt. Länkar Ohm chess HD Vad är nytt i iOS 6 LLVM Clang Cocos2D, ramverk för 2D-spel på iOS med mera Historiken bakom WWW Stack overflow