Podcasts about bsd unix

  • 7PODCASTS
  • 29EPISODES
  • 55mAVG DURATION
  • ?INFREQUENT EPISODES
  • Mar 28, 2024LATEST

POPULARITY

20172018201920202021202220232024


Best podcasts about bsd unix

Latest podcast episodes about bsd unix

BSD Now
552: The Laptop Sparc

BSD Now

Play Episode Listen Later Mar 28, 2024 59:33


Setup diskless booting of Raspberry Pi, TrueNAS abandons FreeBSD, SPARCbook 3000ST: The coolest 90s laptop, Sparkbook Teardown, SSH over HTTPS, Keycloak Identity and Access Management on FreeBSD, Ford Aerospace and BSD Unix, and more NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/bsdnow) and the BSDNow Patreon (https://www.patreon.com/bsdnow) Headlines HOWTO: Setup diskless booting of Raspberry Pi (running RPi OS) via TFTP & NFSv4 from a FreeBSD ZFS server (https://forums.freebsd.org/threads/howto-setup-diskless-booting-of-raspberry-pi-running-rpi-os-via-tftp-nfsv4-from-a-freebsd-zfs-server.92717/) TrueNAS abandons FreeBSD (https://www.theregister.com/2024/03/18/truenas_abandons_freebsd/) + No one needs to panic, we're aware of plans that have already been in the works. But more on that later. News Roundup SPARCbook 3000ST: The coolest 90s laptop (https://jasoneckert.github.io/myblog/sparcbook3000st-the-coolest-90s-laptop/) Sparkbook Teardown (https://jasoneckert.github.io/myblog/sparcbook-teardown/) Author Comment (https://news.ycombinator.com/item?id=39037510) SSH over HTTPS (https://trofi.github.io/posts/295-ssh-over-https.html) Keycloak Identity and Access Management on FreeBSD (https://vermaden.wordpress.com/2024/03/10/keycloak-on-freebsd/) Ford Aerospace and BSD Unix. (https://news.ycombinator.com/item?id=39636035) Beastie Bits OpenBGPD 8.4 released (http://undeadly.org/cgi?action=article;sid=20240308064655) Solene games (https://rsolene.itch.io/) Context: https://bsd.network/@solene/112115442072927484 How I backup (https://sive.rs/backup) 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 Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Join us and other BSD Fans in our BSD Now Telegram channel (https://t.me/bsdnow)

BSD Now
383: Scale the tail

BSD Now

Play Episode Listen Later Dec 31, 2020 43:12


FreeBSD Remote Process Plugin Final Milestone achieved, Tailscale for OpenBSD, macOS to FreeBSD migration, monitoring of our OpenBSD machines, OPNsense 20.7.6 released, and more NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/bsdnow) Headlines FreeBSD Remote Process Plugin: Final Milestone Achieved (https://www.moritz.systems/blog/freebsd-remote-plugin-final-milestone-achieved/) Moritz Systems have been contracted by the FreeBSD Foundation to modernize the LLDB debugger’s support for FreeBSD. We are working on a new plugin utilizing the more modern client-server layout that is already used by Darwin, Linux, NetBSD and (unofficially) OpenBSD. The new plugin is going to gradually replace the legacy one. Tailscale on OpenBSD (https://rakhesh.com/linux-bsd/tailscale-on-openbsd/) I spent some time setting this up today evening and thought I’d post the steps here. Nothing fancy, just putting together various pieces actually. I assume you know what Tailscale is; if not check out their website. Basically it is a mesh network built on top of Wireguard. Using it you can have all your devices both within your LAN(s) and outside be on one overlay network as if they are all on the same LAN and can talk to each other. It’s my new favourite thing! News Roundup macOS to FreeBSD migration a.k.a why I left macOS (https://antranigv.am/weblog_en/posts/macos_to_freebsd/) This is not a technical documentation for how I migrated from macOS to FreeBSD. This is a high-level for why I migrated from macOS to FreeBSD. Not so long ago, I was using macOS as my daily driver. The main reason why I got a macbook was the underlying BSD Unix and the nice graphics it provides. Also, I have an iPhone. But they were also the same reasons for why I left macOS. Our monitoring of our OpenBSD machines, such as it is (as of November 2020 (https://utcc.utoronto.ca/~cks/space/blog/sysadmin/OurOpenBSDMonitoring) We have a number of OpenBSD firewalls in service (along with some other OpenBSD servers for things like VPN endpoints), and I was recently asked how we monitor PF and overall network traffic on them. I had to disappoint the person who asked with my answer, because right now we mostly don't (although this is starting to change). OPNsense 20.7.6 released (https://opnsense.org/opnsense-20-7-6-released/) This update brings the usual mix of reliability fixes, plugin and third party software updates: FreeBSD, HardenedBSD, PHP, OpenSSH, StrongSwan, Suricata and Syslog-ng amongst others. Please note that Let's Encrypt users need to reissue their certificates manually after upgrading to this version to fix the embedded certificate chain issue with the current signing CA switch going on. NYC Bug Jan 2021 with Michael W. Lucas (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/383/nycbug) 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 cy - .so files (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/383/feedback/cy%20-%20.so%20files) ben - mixer volume (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/383/feedback/ben%20-%20mixer%20volume) probono - live cds (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/383/feedback/probono%20-%20live%20cds) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) ***

TSR - The Server Room
TSR- The Server Room Show - Episode 50 - Interview with Dr Marshall Kirk McKusick

TSR - The Server Room

Play Episode Listen Later Oct 31, 2020 45:10


This is a very special episode of a 45 minute full interview with someone who worked on BSD and remains actively involved in FreeBSD as well. Dr. Marshall Kirk McKusick is a computer scientist, known for his  extensive work on BSD UNIX, from the 1980s to FreeBSD in the present  day. Questions *What do you feel when you look back on the history of BSD and what it became today including FreeBSD? * Did You get involved eventually with FreeBSD after BSD ceased to exist because you felt FreeBSD could be the proper continuation of the BSD flag so to say? * Text editor of your choice, Which one are you using? *What do you think of the ZFS file system? *If BSD was not frozen up for 3 long years during the AT&T Lawsuit period which allowed Linux to get a head start.. Would BSD be what Linux is today? * Linus Torvalds wrote an article back in 2004 about the prediction of the death of BSD, How much of Linus’ prediction has come true? * Kirk’s comments on my statement regarding the Linux Foundation receiving a lot of money through major corporations as Gold and Platinum sponsors (Microsoft, etc.) which is kind of a takeover is already happening in place steering its focus towards what these company’s have in their interests while the FreeBSD Foundation receiving very little money compared to the Linux Foundation while still the FreeBSD Foundation is doing an impressive job with the much smaller amount they are getting. * Did You ever miss the chance you were given to go and work for Sun Microsystems? More info: https://www.mckusick.com https://tsr-podcast.com

The History of Computing
The History Of Python

The History of Computing

Play Episode Listen Later Jul 6, 2020 15:44


Haarlem, 1956. No, this isn't an episode about New York, we're talking Haarlem, Netherlands. Guido Van Rossum is born then, and goes on to college in Amsterdam where he gets a degree in math and computer science. He went on to work at the Centrum Wiskunde & Informatica, or CWI. Here, he worked on BSD Unix and the ABC Programming language, which had been written by Lambert Meertens, Leo Geurts, and Steven Pemberton from CWI.  He'd worked on ABC for a few years through the 1980s and started to realize some issues. It had initially been a monolithic implementation, which made it hard to implement certain new features, like being able to access file systems and functions within operating systems. But Meertens was an editor of the ALGOL 68 Report and so ABC did have a lot of the ALGOL 68 influences that are prevalent in a number of more modern languages and could compile for a number of operating systems. It was a great way to spend your 20s if you're Guido. But after some time building interpreters and operating systems, many programmers think they have some ideas for what they might do if they just… started over. Especially when they hit their 30s. And so as we turned the corner towards the increasingly big hair of the 1990s, Guido started a new hobby project over the holiday break for Christmas 1989.  He had been thinking of a new scripting language, loosely based on ABC. One that Unix and C programmers would be interested in, but maybe not as cumbersome as C had become. So he got to work on an interpreter. One that those open source type hackers might be interested in. ALGOL had been great for math, but we needed so much more flexibility in the 90s, unlike bangs. Bangs just needed Aquanet. He named his new creation Python because he loved Monty Python's Flying Circus. They had a great TV show from 1969 to 1974, and a string of movies in the 70s and early 80s. They've been popular amongst people in IT since I got into IT. Python is a funny language. It's incredibly dynamic. Like bash or a shell, we can fire it up, define a variable and echo that out on the fly. But it can also be procedural, object-oriented, or functional. And it has a standard library but is extensible so you can add libraries to do tons of new things that wouldn't make sense to be built in (and so bloat and slow down) other apps. For example, need to get started with big array processing for machine learning projects? Install TensorFlow or Numpy. Or according to your machine learning needs you have PyTorch, SciPi, Pandas, and the list goes on.  In 1994, 20 developers met at the US National Standards Bureau in Maryland, at the first workshop and the first Python evangelists were minted. It was obvious pretty quickly that the modular nature and ease of scripting, but with an ability to do incredibly complicated tasks, was something special. What was drawing this community in. Well, let's start with the philosophy, the Zen of Python as Tim Peters wrote it in 1999: Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one—and preferably only one—obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than right now.[a] If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea—let's do more of those! Those are important enough to be semi-official and can be found by entering “import this” into a python shell. Another reason python became important is that it's multi-paradigm. When I said it could be kinda' functional. Sure. Use one big old function for everything if you're moving from COBOL and just don't wanna' rethink the world. Or be overly object-oriented when you move from Java and build 800 functions to echo hello world in 800 ways. Wanna map reduce your lisp code. Bring it. Or add an extension and program in paradigms I've never heard of. The number of libraries and other ways to extend python out there is pretty much infinite.  And that extensibility was the opposite of ABC and why Python is special. This isn't to take anything away from the syntax. It's meant to be and is an easily readable language. It's very Dutch, with not a lot of frills like that. It uses white space much as the Dutch use silence. I wish it could stare at me like I was an idiot the way the Dutch often do. But alas, it doesn't have eyeballs. Wait, I think there's a library for that.  So what I meant by white space instead of punctuation is that it uses an indent instead of a curly bracket or keyword to delimit blocks of code. Increase the tabbing and you move to a new block. Many programmers do this in other languages just for readability. Python does it for code.  Basic statements included, which match or are similar to most languages, include if, for, while, try, raise, except, class, def, with, break, continue, pass, assert, yield, import and print until python 3 when that became a function. It's amazing what you can build with just a dozen and a half statements in programming. You can have more, but interpreters get slower and compilers get bigger and all that…  Python also has all the expressions you'd expect in a modern language, especial lambdas. And methods. And duck typing, or suitability for a method is determined by the properties of an object rather than the type. This can be great. Or a total pain. Which is why they'll eventually be moving to gradual typing.  The types of objects are bool, byte array, bytes, complex, dict, ellipsis (which I overuse), float, frozen set, int, list, NoneType (which I try to never use), NotImplementedType, range, set, str, and tuple so you can pop mixed tapes into a given object. Not to be confused with a thruple, but not to not be confused I guess…  Another draw of python was the cross-compiler concept. An early decision was to make python cable to talk to c. This won over the Unix and growing Linux crowds. And today we have cross-compilers for C and C++, Go, .Net, Java, R, machine code, and of course, Java.   Python 2 came in 2000. We got a garbage collection system and a few other features and 7 point releases over the next 10 years. Python 3 came in 2008 and represented a big change. It was partially backward-compatible but was the first Python release that wasn't fully backward-compatible. We have had 7 point releases in the past 10 years as well. 3 brought changes to function print, simpler syntax, moved to storing strings in unicode by default, added a range function, changed how global variables react inside for-loops, implemented a simpler set of rules for order comparisons, and much more.  At this point developers were experimenting with deploying microservices. Microservices is an a software development architecture where we build small services, perhaps just a script or a few scripts daisy chained together, that do small tasks. These are then more highly maintainable, more easily testable, often more scalable, can be edited and deployed independently, can be structured around capabilities, and each of the services can be owned by the team that created it with a contract to ensure we don't screw over other teams as we edit them.  Amazon introduced AWS Lambda in 2014 and it became clear quickly that the new micro services paradigm was accelerating the move of many SaaS-based tools to a micro services architecture. Now, teams could build in node or python or java or ruby or c# or heaven forbid Go. They could quickly stand up a small service and get teams able to consume the back end service in a way that is scalable and doesn't require standing up a server or even a virtual server, which is how we did things in EC2. The containerization concept is nothing new. We had chroot in 1979 with Unix v7 and Solaris brought us containerization in 2004. But those were more about security. Docker had shown up in 2013 and the idea of spinning up a container to run a script and give it its own library and lib container, that was special. And Amazon made it more so.  Again, libraries and modularization. And the modular nature is key for me. Let's say you need to do image processing. Pillow makes it easier to work with images of almost any image type you can think of. For example, it can display an image, convert it into different types, automatically generate thumbnails, run sooth, blur, contour, and even increase the detail. Libraries like that take a lot of the friction out of learning to display and manage images.  But Python can also create its own imagery. For example, Matplotlib generates two dimensional graphs and plots points on them. These can look as good as you want them to look and actually allows us to integrate with a ton of other systems.  Van Rossum's career wasn't all python though. He would go on to work at NIST then CNRI and Zope before ending up at Google in 2005, where he created Mondrian, a code review system. He would go to Dropbox in 2013 and retire from professional life in 2019. He stepped down as the “Benevolent dictator for life” of the Python project in 2018 and sat on the Python Steering Council for a term but is no longer involved. It's been one of the most intriguing “Transfers of power” I've seen but Python is in great hands to thrive in the future. This is the point when Python 2 was officially discontinued, and Python 3.5.x was thriving.  By thriving, as of mid-202, there are over 200,000 packages in the Python Package Index. Things from web frameworks and web scraping to automation, to graphical user interfaces, documentation, databases, analytics, networking, systems administrations, science, mobile, image management and processing. If you can think of it, there's probably a package to help you do it. And it's one of the easier languages.  Here's the thing. Python grew because of how flexible and easy it is to use. It didn't have the same amount of baggage as other languages. And that flexibility and modular nature made it great for workloads in a changing and more micro-service oriented world. Or, did it help make the world more micro-service oriented. It was a Christmas hobby project that has now ballooned into one of the most popular languages to write software in the word. You know what I did over my last holiday break? Sleep. I clearly should have watched more Monty Python so the short skits could embolden me to write a language perfect for making the programmers equivalent, smaller, more modular scripts and functions. So as we turn the corner into all the holidays in front of us, consider this while stuck at home, what hobby project can we propel forward and hopefully end up with the same type of impact Guido had. A true revolutionary in his own right.  So thank you to everyone involved in python and everyone that's contributed to those 200k+ projects. And thank you, listeners, for continuing to tun in to the history of computing podcast. We are so lucky to have you.

TSR - The Server Room
TSR - The Server Room Show - Episode 32 - History of BSD - Part III.

TSR - The Server Room

Play Episode Listen Later Jun 27, 2020 30:01


This episode gives credit and relies heavily/completely on the presentations, notes and speeches done and copyrighted fully of Dr Marshall Kirk Mckusick who is a renowned computer scientist, known for his extensive work on BSD UNIX, from the 1980s to FreeBSD in the present day. Much of the information in this shownotes can be found in the chapter on Berkeley UNIX (pages 31-46) in the book: Open Sources: Voices from the Open Source Revolution If You are interested further as this episodes and shownotes are a very stripped down version of the work of Dr Marshall Kirk Mckusick´s notes and presentations Please consider purchasing His DVD of the History Of Berkeley Software Distributions from which this episode excerpts its facts and figures and historical recounting. It is a near 4 hours long 2 parts presentation which recounts the History of BSD from the early days and another lecture about the Modern FreeBSD. It is great fun to watch and own and definitely a better recount of the events with many fun facts and personality as I could ever do myself. ----------------------------------- History of BSD - Part III. ----------------------------------- Links: DVD Order of Dr Marshall Kirk McKusick https://www.mckusick.com/history/index.html Wikipedia entry of Kirk McKusick https://en.wikipedia.org/wiki/Marshall_Kirk_McKusick Kirk McKusick's Homepage: https://www.mckusick.com/ BSDTalk Interview with Kirk McKusick https://ia800703.us.archive.org/34/items/bsdtalk018/bsdtalk018.mp3

history wikipedia server bsd freebsd his dvd bsd unix marshall kirk mckusick
TSR - The Server Room
TSR - The Server Room Show - Episode 31 - History of BSD - Part II.

TSR - The Server Room

Play Episode Listen Later Jun 20, 2020 30:00


This episode gives credit and relies heavily/completely on the presentations, notes and speeches done and copyrighted fully of Dr Marshall Kirk Mckusick who is a renowned computer scientist, known for his extensive work on BSD UNIX, from the 1980s to FreeBSD in the present day. Much of the information in this shownotes can be found in the chapter on Berkeley UNIX (pages 31-46) in the book: Open Sources: Voices from the Open Source Revolution If You are interested further as this episodes and shownotes are a very stripped down version of the work of Dr Marshall Kirk Mckusick´s notes and presentations Please consider purchasing His DVD of the History Of Berkeley Software Distributions from which this episode excerpts its facts and figures and historical recounting. It is a near 4 hours long 2 parts presentation which recounts the History of BSD from the early days and another lecture about the Modern FreeBSD. It is great fun to watch and own and definitely a better recount of the events with many fun facts and personality as I could ever do myself. ----------------------------------- History of BSD - Part II. ----------------------------------- Links: DVD Order of Dr Marshall Kirk McKusick https://www.mckusick.com/history/index.html Wikipedia entry of Kirk McKusick https://en.wikipedia.org/wiki/Marshall_Kirk_McKusick Kirk McKusick's Homepage: https://www.mckusick.com/ BSDTalk Interview with Kirk McKusick https://ia800703.us.archive.org/34/items/bsdtalk018/bsdtalk018.mp3

history server bsd freebsd his dvd bsd unix marshall kirk mckusick
TSR - The Server Room
TSR - The Server Room Show - Episode 30 - History of BSD - Part I.

TSR - The Server Room

Play Episode Listen Later Jun 13, 2020 30:00


This episode gives credit and relies heavily/completely on the presentations, notes and speeches done and copyrighted fully of Dr Marshall Kirk Mckusick who is a renowned computer scientist, known for his extensive work on BSD UNIX, from the 1980s to FreeBSD in the present day. Much of the information in this shownotes can be found in the chapter on Berkeley UNIX (pages 31-46) in the book: Open Sources: Voices from the Open Source Revolution If You are interested further as this episodes and shownotes are a very stripped down version of the work of Dr Marshall Kirk Mckusick´s notes and presentations Please consider purchasing His DVD of the History Of Berkeley Software Distributions from which this episode excerpts its facts and figures and historical recounting. It is a near 4 hours long 2 parts presentation which recounts the History of BSD from the early days and another lecture about the Modern FreeBSD. It is great fun to watch and own and definitely a better recount of the events with many fun facts and personality as I could ever do myself. ----------------------------------- History of BSD - Part I. ----------------------------------- Links: DVD Order of Dr Marshall Kirk McKusick https://www.mckusick.com/history/index.html Wikipedia entry of Kirk McKusick https://en.wikipedia.org/wiki/Marshall_Kirk_McKusick Kirk McKusick's Homepage: https://www.mckusick.com/ BSDTalk Interview with Kirk McKusick https://ia800703.us.archive.org/34/items/bsdtalk018/bsdtalk018.mp3

history server bsd freebsd his dvd bsd unix marshall kirk mckusick
BSD Now
351: Heaven: OpenBSD 6.7

BSD Now

Play Episode Listen Later May 21, 2020 49:09


Backup and Restore on NetBSD, OpenBSD 6.7 available, Building a WireGuard Jail with FreeBSD's standard tools, who gets to chown things and quotas, influence TrueNAS CORE roadmap, and more. Headlines Backup and Restore on NetBSD (https://e17i.github.io/articles-netbsd-backup/) Putting together the bits and pieces of a backup and restore concept, while not being rocket science, always seems to be a little bit ungrateful. Most Admin Handbooks handle this topic only within few pages. After replacing my old Mac Mini's OS by NetBSD, I tried to implement an automated backup, allowing me to handle it similarly to the time machine backups I've been using before. Suggestions on how to improve are always welcome. BSD Release: OpenBSD 6.7 (https://distrowatch.com/?newsid=10921) The OpenBSD project produces and operating system which places focus on portability, standardisation, code correctness, proactive security and integrated cryptography. The project's latest release is OpenBSD 6.7 which introduces several new improvements to the cron scheduling daemon, improvements to the web server daemon, and the top command now offers scrollable output. These and many more changes can be found in the project's release announcement: "This is a partial list of new features and systems included in OpenBSD 6.7. For a comprehensive list, see the changelog leading to 6.7. General improvements and bugfixes: Reduced the minimum allowed number of chunks in a CONCAT volume from 2 to 1, increasing the number of volumes which can be created on a single disk with bioctl(8) from 7 to 15. This can be used to create more partitions than previously. Rewrote the cron(8) flag-parsing code to be getopt-like, allowing tight formations like -ns and flag repetition. Renamed the 'options' field in crontab(5) to 'flags'. Added crontab(5) -s flag to the command field, indicating that only a single instance of the job should run concurrently. Added cron(8) support for random time values using the ~ operator. Allowed cwm(1) configuration of window size based on percentage of the master window during horizontal and vertical tiling actions." Release Announcement (https://marc.info/?l=openbsd-announce&m=158989783626149&w=2) Release Notes (https://www.openbsd.org/67.html) News Roundup Building a WireGuard Jail with the FreeBSD's Standard Tools (https://genneko.github.io/playing-with-bsd/networking/freebsd-wireguard-jail/) Recently, I had an opportunity to build a WireGuard jail on a FreeBSD 12.1 host. As it was really quick and easy to setup and it has been working completely fine for a month, I’d like to share my experience with anyone interested in this topic. The Unix divide over who gets to chown things, and (disk space) quotas (https://utcc.utoronto.ca/~cks/space/blog/unix/ChownDivideAndQuotas) One of the famous big splits between the BSD Unix world and the System V world is whether ordinary users can use chown (the command and the system call) to give away their own files. In System V derived Unixes you were generally allowed to; in BSD derived Unixes you weren't. Until I looked it up now to make sure, I thought that BSD changed this behavior from V7 and that V7 had an unrestricted chown. However, this turns out to be wrong; in V7 Unix, chown(2) was restricted to root only. You Can Influence the TrueNAS CORE Roadmap! (https://www.ixsystems.com/blog/truenas-bugs-and-suggestions/) As many of you know, we’ve historically had three ticket types available in our tracker: Bugs, Features, and Improvements, which are all fairly self-explanatory. After some discussion internally, we’ve decided to implement a new type of ticket, a “Suggestion”. These will be replacing Feature and Improvement requests for the TrueNAS Community, simplifying things down to two options: Bugs and Suggestions. This change also introduces a slightly different workflow than before. Beastie Bits FreeNAS Spare Parts Build: Testing ZFS With Imbalanced VDEVs and Mismatched Drives (https://www.youtube.com/watch?v=EFrlG3CUKFQ) TLSv1.3 server code enabled in LibreSSL in -current (https://undeadly.org/cgi?action=article;sid=20200512074150) Interview with Deb Goodkin (https://itsfoss.com/freebsd-interview-deb-goodkin/) *** Feedback/Questions Bostjan - WireGaurd (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/351/feedback/Bostjan%20-%20WireGaurd.md) Chad - ZFS Pool Design (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/351/feedback/Chad%20-%20ZFS%20Pool%20Design.md) Pedreo - Scale FreeBSD Jails (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/351/feedback/Pedreo%20-%20Scale%20FreeBSD%20Jails.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
336: Archived Knowledge

BSD Now

Play Episode Listen Later Feb 6, 2020 57:57


Linux couldn’t duplicate OpenBSD, FreeBSD Q4 status report, OPNsense 19.7.9 released, archives retain and pass on knowledge, HardenedBSD Tor Onion Service v3 Nodes, and more. Headlines OpenBSD has to be a BSD Unix and you couldn't duplicate it with Linux (https://utcc.utoronto.ca/~cks/space/blog/unix/OpenBSDMustBeABSD?showcomments) OpenBSD has a well deserved reputation for putting security and a clean system (for code, documentation, and so on) first, and everything else second. OpenBSD is of course based on BSD (it's right there in the name) and descends from FreeBSD NetBSD (you can read the history here). But one of the questions you could ask about it is whether it had to be that way, and in particular if you could build something like OpenBSD on top of Linux. I believe that the answer is no. Linux and the *BSDs have a significantly different model of what they are. BSDs have a 'base system' that provides an integrated and fully operational core Unix, covering the kernel, C library and compiler, and the normal Unix user level programs, all maintained and distributed by the particular BSD. Linux is not a single unit this way, and instead all of the component parts are maintained separately and assembled in various ways by various Linux distributions. Both approaches have their advantages, but one big one for the BSD approach is that it enables global changes. Making global changes is an important part of what makes OpenBSD's approach to improving security, code maintenance, and so on work. Because it directly maintains everything as a unit, OpenBSD is in a position to introduce new C library or kernel APIs (or change them) and then immediately update all sorts of things in user level programs to use the new API. This takes a certain amount of work, of course, but it's possible to do it at all. And because OpenBSD can do this sort of ambitious global change, it does. This goes further than just the ability to make global changes, because in theory you can patch in global changes on top of a bunch of separate upstream projects. Because OpenBSD is in control of its entire base system, it's not forced to try to reconcile different development priorities or integrate clashing changes. OpenBSD can decide (and has) that only certain sorts of changes will be accepted into its system at all, no matter what people want. If there are features or entire programs that don't fit into what OpenBSD will accept, they just lose out. FreeBSD Quarterly Status Report 2019Q4 (https://lists.freebsd.org/pipermail/freebsd-announce/2020-January/001923.html) Here is the last quarterly status report for 2019. As you might remember from last report, we changed our timeline: now we collect reports the last month of each quarter and we edit and publish the full document the next month. Thus, we cover here the period October 2019 - December 2019. If you thought that the FreeBSD community was less active in the Christmas' quarter you will be glad to be proven wrong: a quick glance at the summary will be sufficient to see that much work has been done in the last months. Have a nice read! News Roundup OPNsense 19.7.9 released (https://opnsense.org/opnsense-19-7-9-released/) As 20.1 nears we will be making adjustments to the scope of the release with an announcement following shortly. For now, this update brings you a GeoIP database configuration page for aliases which is now required due to upstream database policy changes and a number of prominent third-party software updates we are happy to see included. Archives are important to retain and pass on knowledge (https://dan.langille.org/2020/01/07/archives-are-important-to-retain-and-pass-on-knowledge/) Archives are important. When they are public and available for searching, it retains and passes on knowledge. It saves vast amounts of time. HardenedBSD Tor Onion Service v3 Nodes (https://hardenedbsd.org/article/shawn-webb/2020-01-30/hardenedbsd-tor-onion-service-v3-nodes) I've been working today on deploying Tor Onion Service v3 nodes across our build infrastructure. I'm happy to announce that the public portion of this is now completed. Below you will find various onion service hostnames and their match to our infrastructure. hardenedbsd.org: lkiw4tmbudbr43hbyhm636sarn73vuow77czzohdbqdpjuq3vdzvenyd.onion ci-01.nyi.hardenedbsd.org: qspcqclhifj3tcpojsbwoxgwanlo2wakti2ia4wozxjcldkxmw2yj3yd.onion ci-03.md.hardenedbsd.org: eqvnohly4tjrkpwatdhgptftabpesofirnhz5kq7jzn4zd6ernpvnpqd.onion ci-04.md.hardenedbsd.org: rfqabq2w65nhdkukeqwf27r7h5xfh53h3uns6n74feeyl7s5fbjxczqd.onion git-01.md.hardenedbsd.org: dacxzjk3kq5mmepbdd3ai2ifynlzxsnpl2cnkfhridqfywihrfftapid.onion Beastie Bits The Missing Semester of Your CS Education (MIT Course) (https://missing.csail.mit.edu/) An old Unix Ad (https://i.redd.it/503390rf7md41.png) OpenBSD syscall call-from verification (https://marc.info/?l=openbsd-tech&m=157488907117170&w=2) OpenBSD/arm64 on Pinebook (https://twitter.com/bluerise/status/1220963106563579909) Reminder: First Southern Ontario BSD user group meeting, February 11th (this coming Tuesday!) 18:30 at Boston Pizza on Upper James st, Hamilton. (http://studybsd.com/) NYCBUG: March meeting will feature Dr. Paul Vixie and his new talk “Operating Systems as Dumb Pipes” (https://www.nycbug.org/) 8th Meetup of the Stockholm BUG: March 3 at 18:00 (https://www.meetup.com/de-DE/BSD-Users-Stockholm/events/267873938/) Polish BSD User Group meets on Feb 11, 2020 at 18:15 (https://bsd-pl.org/en) Feedback/Questions Sean - ZFS and Creation Dates (http://dpaste.com/3W5WBV0#wrap) Christopher - Help on ZFS Disaster Recovery (http://dpaste.com/3SE43PW) Mike - Encrypted ZFS Send (http://dpaste.com/00J5JZG#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.

Day in Tech History Podcast - Apple History
January 9, 2001: Mac OSX, iTunes Media Platform Announced

Day in Tech History Podcast - Apple History

Play Episode Listen Later Jan 8, 2020 6:11


At MacWorld 2001, Steve Jobs announced Mac OSX – the base OS for Apple for the next couple decades. With Darwin, an open source BSD Unix service, 2D (Quartz), 3D (OpenGL) and Quicktime (QT5). The programming language of Classic, Carbon and Cocoa allowed programs from OS9 to run. Cocoa is an object oriented API for […]

Day in Tech History
January 9, 2001: Mac OSX, iTunes Media Platform Announced

Day in Tech History

Play Episode Listen Later Jan 8, 2020 6:11


At MacWorld 2001, Steve Jobs announced Mac OSX – the base OS for Apple for the next couple decades. With Darwin, an open source BSD Unix service, 2D (Quartz), 3D (OpenGL) and Quicktime (QT5). The programming language of Classic, Carbon and Cocoa allowed programs from OS9 to run. Cocoa is an object oriented API for […]

BSD Now
323: OSI Burrito Guy

BSD Now

Play Episode Listen Later Nov 7, 2019 49:22


The earliest Unix code, how to replace fail2ban with blacklistd, OpenBSD crossed 400k commits, how to install Bolt CMS on FreeBSD, optimized hammer2, appeasing the OSI 7-layer burrito guys, and more. Headlines The Earliest Unix Code: An Anniversary Source Code Release (https://computerhistory.org/blog/the-earliest-unix-code-an-anniversary-source-code-release/) What is it that runs the servers that hold our online world, be it the web or the cloud? What enables the mobile apps that are at the center of increasingly on-demand lives in the developed world and of mobile banking and messaging in the developing world? The answer is the operating system Unix and its many descendants: Linux, Android, BSD Unix, MacOS, iOS—the list goes on and on. Want to glimpse the Unix in your Mac? Open a Terminal window and enter “man roff” to view the Unix manual entry for an early text formatting program that lives within your operating system. 2019 marks the 50th anniversary of the start of Unix. In the summer of 1969, that same summer that saw humankind’s first steps on the surface of the Moon, computer scientists at the Bell Telephone Laboratories—most centrally Ken Thompson and Dennis Ritchie—began the construction of a new operating system, using a then-aging DEC PDP-7 computer at the labs. This man sent the first online message 50 years ago (https://www.cbc.ca/radio/thecurrent/the-current-for-oct-29-2019-1.5339212/this-man-sent-the-first-online-message-50-years-ago-he-s-since-seen-the-web-s-dark-side-emerge-1.5339244) As many of you have heard in the past, the first online message ever sent between two computers was "lo", just over 50 years ago, on Oct. 29, 1969. It was supposed to say "log," but the computer sending the message — based at UCLA — crashed before the letter "g" was typed. A computer at Stanford 560 kilometres away was supposed to fill in the remaining characters "in," as in "log in." The CBC Radio show, “The Current” has a half-hour interview with the man who sent that message, Leonard Kleinrock, distinguished professor of computer science at UCLA "The idea of the network was you could sit at one computer, log on through the network to a remote computer and use its services there," 50 years later, the internet has become so ubiquitous that it has almost been rendered invisible. There's hardly an aspect in our daily lives that hasn't been touched and transformed by it. Q: Take us back to that day 50 years ago. Did you have the sense that this was going to be something you'd be talking about a half a century later? A: Well, yes and no. Four months before that message was sent, there was a press release that came out of UCLA in which it quotes me as describing what my vision for this network would become. Basically what it said is that this network would be always on, always available. Anybody with any device could get on at anytime from any location, and it would be invisible. Well, what I missed ... was that this is going to become a social network. People talking to people. Not computers talking to computers, but [the] human element. Q: Can you briefly explain what you were working on in that lab? Why were you trying to get computers to actually talk to one another? A: As an MIT graduate student, years before, I recognized I was surrounded by computers and I realized there was no effective [or efficient] way for them to communicate. I did my dissertation, my research, on establishing a mathematical theory of how these networks would work. But there was no such network existing. AT&T said it won't work and, even if it does, we want nothing to do with it. So I had to wait around for years until the Advanced Research Projects Agency within the Department of Defence decided they needed a network to connect together the computer scientists they were supervising and supporting. Q: For all the promise of the internet, it has also developed some dark sides that I'm guessing pioneers like yourselves never anticipated. A: We did not. I knew everybody on the internet at that time, and they were all well-behaved and they all believed in an open, shared free network. So we did not put in any security controls. When the first spam email occurred, we began to see the dark side emerge as this network reached nefarious people sitting in basements with a high-speed connection, reaching out to millions of people instantaneously, at no cost in time or money, anonymously until all sorts of unpleasant events occurred, which we called the dark side. But in those early days, I considered the network to be going through its teenage years. Hacking to spam, annoying kinds of effects. I thought that one day this network would mature and grow up. Well, in fact, it took a turn for the worse when nation states, organized crime and extremists came in and began to abuse the network in severe ways. Q: Is there any part of you that regrets giving birth to this? A: Absolutely not. The greater good is much more important. News Roundup 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) 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 ??) 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. FreeBSD’s handbook chapter on blacklistd (https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-blacklistd.html) OpenBSD crossed 400,000 commits (https://marc.info/?l=openbsd-tech&m=157059352620659&w=2) Sometime in the last week OpenBSD crossed 400,000 commits (*) upon all our repositories since starting at 1995/10/18 08:37:01 Canada/Mountain. That's a lot of commits by a lot of amazing people. (*) by one measure. Since the repository is so large and old, there are a variety of quirks including ChangeLog missing entries and branches not convertible to other repo forms, so measuring is hard. If you think you've got a great way of measuring, don't be so sure of yourself -- you may have overcounted or undercounted. Subject to the notes Theo made about under and over counting, FreeBSD should hit 1 million commits (base + ports + docs) some time in 2020 NetBSD + pkgsrc are approaching 600,000, but of course pkgsrc covers other operating systems too How to Install Bolt CMS with Nginx and Let's Encrypt on FreeBSD 12 (https://www.howtoforge.com/how-to-install-bolt-cms-nginx-ssl-on-freebsd-12/) Bolt is a sophisticated, lightweight and simple CMS built with PHP. It is released under the open-source MIT-license and source code is hosted as a public repository on Github. A bolt is a tool for Content Management, which strives to be as simple and straightforward as possible. It is quick to set up, easy to configure, uses elegant templates. Bolt is created using modern open-source libraries and is best suited to build sites in HTML5 with modern markup. In this tutorial, we will go through the Bolt CMS installation on FreeBSD 12 system by using Nginx as a web server, MySQL as a database server, and optionally you can secure the transport layer by using acme.sh client and Let's Encrypt certificate authority to add SSL support. Requirements The system requirements for Bolt are modest, and it should run on any fairly modern web server: PHP version 5.5.9 or higher with the following common PHP extensions: pdo, mysqlnd, pgsql, openssl, curl, gd, intl, json, mbstring, opcache, posix, xml, fileinfo, exif, zip. Access to SQLite (which comes bundled with PHP), or MySQL or PostgreSQL. Apache with mod_rewrite enabled (.htaccess files) or Nginx (virtual host configuration covered below). A minimum of 32MB of memory allocated to PHP. hammer2 - Optimize hammer2 support threads and dispatch (http://lists.dragonflybsd.org/pipermail/commits/2019-September/719632.html) Refactor the XOP groups in order to be able to queue strategy calls, whenever possible, to the same CPU as the issuer. This optimizes several cases and reduces unnecessary IPI traffic between cores. The next best thing to do would be to not queue certain XOPs to an H2 support thread at all, but I would like to keep the threads intact for later clustering work. The best scaling case for this is when one has a large number of user threads doing I/O. One instance of a single-threaded program on an otherwise idle machine might see a slightly reduction in performance but at the same time we completely avoid unnecessarily spamming all cores in the system on the behalf of a single program, so overhead is also significantly lower. This will tend to increase the number of H2 support threads since we need a certain degree of multiplication for domain separation. This should significantly increase I/O performance for multi-threaded workloads. You know, we might as well just run every network service over HTTPS/2 and build another six layers on top of that to appease the OSI 7-layer burrito guys (http://boston.conman.org/2019/10/17.1) I've seen the writing on the wall, and while for now you can configure Firefox not to use DoH, I'm not confident enough to think it will remain that way. To that end, I've finally set up my own DoH server for use at Chez Boca. It only involved setting up my own CA to generate the appropriate certificates, install my CA certificate into Firefox, configure Apache to run over HTTP/2 (THANK YOU SO VERY XXXXX­XX MUCH GOOGLE FOR SHOVING THIS HTTP/2 XXXXX­XXX DOWN OUR THROATS!—no, I'm not bitter) and write a 150 line script that just queries my own local DNS, because, you know, it's more XXXXX­XX secure or some XXXXX­XXX reason like that. Sigh. Beastie Bits An Oral History of Unix (https://www.princeton.edu/~hos/Mahoney/unixhistory) NUMA Siloing in the FreeBSD Network Stack [pdf] (https://people.freebsd.org/~gallatin/talks/euro2019.pdf) EuroBSDCon 2019 videos available (https://www.youtube.com/playlist?list=PLskKNopggjc6NssLc8GEGSiFYJLYdlTQx) Barbie knows best (https://twitter.com/eksffa/status/1188638425567682560) For the #OpenBSD #e2k19 attendees. I did a pre visit today. (https://twitter.com/bob_beck/status/1188226661684301824) Drawer Find (https://twitter.com/pasha_sh/status/1187877745499561985) Slides - Removing ROP Gadgets from OpenBSD - AsiaBSDCon 2019 (https://www.openbsd.org/papers/asiabsdcon2019-rop-slides.pdf) Feedback/Questions Bostjan - Open source doesn't mean secure (http://dpaste.com/1M5MVCX#wrap) Malcolm - Allan is Correct. (http://dpaste.com/2RFNR94) Michael - FreeNAS inside a Jail (http://dpaste.com/28YW3BB#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.

The History of Computing
The Evolution Of The Microchip

The History of Computing

Play Episode Listen Later Sep 13, 2019 31:14


The Microchip Welcome to the History of Computing Podcast, where we explore the history of information technology. Because understanding the past prepares us for the innovations of the future! Todays episode is on the history of the microchip, or microprocessor. This was a hard episode, because it was the culmination of so many technologies. You don't know where to stop telling the story - and you find yourself writing a chronological story in reverse chronological order. But few advancements have impacted humanity the way the introduction of the microprocessor has. Given that most technological advances are a convergence of otherwise disparate technologies, we'll start the story of the microchip with the obvious choice: the light bulb. Thomas Edison first demonstrated the carbon filament light bulb in 1879. William Joseph Hammer, an inventor working with Edison, then noted that if he added another electrode to a heated filament bulb that it would glow around the positive pole in the vacuum of the bulb and blacken the wire and the bulb around the negative pole. 25 years later, John Ambrose Fleming demonstrated that if that extra electrode is made more positive than the filament the current flows through the vacuum and that the current could only flow from the filament to the electrode and not the other direction. This converted AC signals to DC and represented a boolean gate. In the 1904 Fleming was granted Great Britain's patent number 24850 for the vacuum tube, ushering in the era of electronics. Over the next few decades, researchers continued to work with these tubes. Eccles and Jordan invented the flip-flop circuit at London's City and Guilds Technical College in 1918, receiving a patent for what they called the Eccles-Jordan Trigger Circuit in 1920. Now, English mathematician George Boole back in the earlier part of the 1800s had developed Boolean algebra. Here he created a system where logical statements could be made in mathematical terms. Those could then be performed using math on the symbols. Only a 0 or a 1 could be used. It took awhile, John Vincent Atanasoff and grad student Clifford Berry harnessed the circuits in the Atanasoff-Berry computer in 1938 at Iowa State University and using Boolean algebra, successfully solved linear equations but never finished the device due to World War II, when a number of other technological advancements happened, including the development of the ENIAC by John Mauchly and J Presper Eckert from the University of Pennsylvania, funded by the US Army Ordinance Corps, starting in 1943. By the time it was taken out of operation, the ENIAC had 20,000 of these tubes. Each digit in an algorithm required 36 tubes. Ten digit numbers could be multiplied at 357 per second, showing the first true use of a computer. John Von Neumann was the first to actually use the ENIAC when they used one million punch cards to run the computations that helped propel the development of the hydrogen bomb at Los Alamos National Laboratory. The creators would leave the University and found the Eckert-Mauchly Computer Corporation. Out of that later would come the Univac and the ancestor of todays Unisys Corporation. These early computers used vacuum tubes to replace gears that were in previous counting machines and represented the First Generation. But the tubes for the flip-flop circuits were expensive and had to be replaced way too often. The second generation of computers used transistors instead of vacuum tubes for logic circuits. The integrated circuit is basically a wire set into silicon or germanium that can be set to on or off based on the properties of the material. These replaced vacuum tubes in computers to provide the foundation of the boolean logic. You know, the zeros and ones that computers are famous for. As with most modern technologies the integrated circuit owes its origin to a number of different technologies that came before it was able to be useful in computers. This includes the three primary components of the circuit: the transistor, resistor, and capacitor. The silicon that chips are so famous for was actually discovered by Swedish chemist Jöns Jacob Berzelius in 1824. He heated potassium chips in a silica container and washed away the residue and viola - an element! The transistor is a semiconducting device that has three connections that amplify data. One is the source, which is connected to the negative terminal on a battery. The second is the drain, and is a positive terminal that, when touched to the gate (the third connection), the transistor allows electricity through. Transistors then acts as an on/off switch. The fact they can be on or off is the foundation for Boolean logic in modern computing. The resistor controls the flow of electricity and is used to control the levels and terminate lines. An integrated circuit is also built using silicon but you print the pattern into the circuit using lithography rather than painstakingly putting little wires where they need to go like radio operators did with the Cats Whisker all those years ago. The idea of the transistor goes back to the mid-30s when William Shockley took the idea of a cat's wicker, or fine wire touching a galena crystal. The radio operator moved the wire to different parts of the crystal to pick up different radio signals. Solid state physics was born when Shockley, who first studied at Cal Tech and then got his PhD in Physics, started working on a way to make these useable in every day electronics. After a decade in the trenches, Bell gave him John Bardeen and Walter Brattain who successfully finished the invention in 1947. Shockley went on to design a new and better transistor, known as a bipolar transistor and helped move us from vacuum tubes, which were bulky and needed a lot of power, to first gernanium, which they used initially and then to silicon. Shockley got a Nobel Prize in physics for his work and was able to recruit a team of extremely talented young PhDs to help work on new semiconductor devices. He became increasingly frustrated with Bell and took a leave of absence. Shockley moved back to his hometown of Palo Alto, California and started a new company called the Shockley Semiconductor Laboratory. He had some ideas that were way before his time and wasn't exactly easy to work with. He pushed the chip industry forward but in the process spawned a mass exodus of employees that went to Fairchild in 1957. He called them the “Traitorous 8” to create what would be Fairchild Semiconductors. The alumni of Shockley Labs ended up spawning 65 companies over the next 20 years that laid foundation of the microchip industry to this day, including Intel. . If he were easier to work with, we might not have had the innovation that we've seen if not for Shockley's abbrasiveness! All of these silicon chip makers being in a small area of California then led to that area getting the Silicon Valley moniker, given all the chip makers located there. At this point, people were starting to experiment with computers using transistors instead of vacuum tubes. The University of Manchester created the Transistor Computer in 1953. The first fully transistorized computer came in 1955 with the Harwell CADET, MIT started work on the TX-0 in 1956, and the THOR guidance computer for ICBMs came in 1957. But the IBM 608 was the first commercial all-transistor solid-state computer. The RCA 501, Philco Transac S-1000, and IBM 7070 took us through the age of transistors which continued to get smaller and more compact. At this point, we were really just replacing tubes with transistors. But the integrated circuit would bring us into the third generation of computers. The integrated circuit is an electronic device that has all of the functional blocks put on the same piece of silicon. So the transistor, or multiple transistors, is printed into one block. Jack Kilby of Texas Instruments patented the first miniaturized electronic circuit in 1959, which used germanium and external wires and was really more of a hybrid integrated Circuit. Later in 1959, Robert Noyce of Fairchild Semiconductor invented the first truly monolithic integrated circuit, which he received a patent for. While doing so independently, they are considered the creators of the integrated circuit. The third generation of computers was from 1964 to 1971, and saw the introduction of metal-oxide-silicon and printing circuits with photolithography. In 1965 Gordon Moore, also of Fairchild at the time, observed that the number of transistors, resistors, diodes, capacitors, and other components that could be shoved into a chip was doubling about every year and published an article with this observation in Electronics Magazine, forecasting what's now known as Moore's Law. The integrated circuit gave us the DEC PDP and later the IBM S/360 series of computers, making computers smaller, and brought us into a world where we could write code in COBOL and FORTRAN. A microprocessor is one type of integrated circuit. They're also used in audio amplifiers, analog integrated circuits, clocks, interfaces, etc. But in the early 60s, the Minuteman missal program and the US Navy contracts were practically the only ones using these chips, at this point numbering in the hundreds, bringing us into the world of the MSI, or medium-scale integration chip. Moore and Noyce left Fairchild and founded NM Electronics in 1968, later renaming the company to Intel, short for Integrated Electronics. Federico Faggin came over in 1970 to lead the MCS-4 family of chips. These along with other chips that were economical to produce started to result in chips finding their way into various consumer products. In fact, the MCS-4 chips, which split RAM , ROM, CPU, and I/O, were designed for the Nippon Calculating Machine Corporation and Intel bought the rights back, announcing the chip in Electronic News with an article called “Announcing A New Era In Integrated Electronics.” Together, they built the Intel 4004, the first microprocessor that fit on a single chip. They buried the contacts in multiple layers and introduced 2-phase clocks. Silicon oxide was used to layer integrated circuits onto a single chip. Here, the microprocessor, or CPU, splits the arithmetic and logic unit, or ALU, the bus, the clock, the control unit, and registers up so each can do what they're good at, but live on the same chip. The 1st generation of the microprocessor was from 1971, when these 4-bit chips were mostly used in guidance systems. This boosted the speed by five times. The forming of Intel and the introduction of the 4004 chip can be seen as one of the primary events that propelled us into the evolution of the microprocessor and the fourth generation of computers, which lasted from 1972 to 2010. The Intel 4004 had 2,300 transistors. The Intel 4040 came in 1974, giving us 3,000 transistors. It was still a 4-bit data bus but jumped to 12-bit ROM. The architecture was also from Faggin but the design was carried out by Tom Innes. We were firmly in the era of LSI, or Large Scale Integration chips. These chips were also used in the Busicom calculator, and even in the first pinball game controlled by a microprocessor. But getting a true computer to fit on a chip, or a modern CPU, remained an elusive goal. Texas Instruments ran an ad in Electronics with a caption that the 8008 was a “CPU on a Chip” and attempted to patent the chip, but couldn't make it work. Faggin went to Intel and they did actually make it work, giving us the first 8-bit microprocessor. It was then redesigned in 1972 as the 8080. A year later, the chip was fabricated and then put on the market in 1972. Intel made the R&D money back in 5 months and sparked the idea for Ed Roberts to build The Altair 8800. Motorola and Zilog brought competition in the 6900 and Z-80, which was used in the Tandy TRS-80, one of the first mass produced computers. N-MOSs transistors on chips allowed for new and faster paths and MOS Technology soon joined the fray with the 6501 and 6502 chips in 1975. The 6502 ended up being the chip used in the Apple I, Apple II, NES, Atari 2600, BBC Micro, Commodore PET and Commodore VIC-20. The MOS 6510 variant was then used in the Commodore 64. The 8086 was released in 1978 with 3,000 transistors and marked the transition to Intel's x86 line of chips, setting what would become the standard in future chips. But the IBM wasn't the only place you could find chips. The Motorola 68000 was used in the Sun-1 from Sun Microsystems, the HP 9000, the DEC VAXstation, the Comodore Amiga, the Apple Lisa, the Sinclair QL, the Sega Genesis, and the Mac. The chips were also used in the first HP LaserJet and the Apple LaserWriter and used in a number of embedded systems for years to come. As we rounded the corner into the 80s it was clear that the computer revolution was upon us. A number of computer companies were looking to do more than what they could do with he existing Intel, MOS, and Motorola chips. And ARPA was pushing the boundaries yet again. Carver Mead of Caltech and Lynn Conway of Xerox PARC saw the density of transistors in chips starting to plateau. So with DARPA funding they went out looking for ways to push the world into the VLSI era, or Very Large Scale Integration. The VLSI project resulted in the concept of fabless design houses, such as Broadcom, 32-bit graphics, BSD Unix, and RISC processors, or Reduced Instruction Set Computer Processor. Out of the RISC work done at UC Berkely came a number of new options for chips as well. One of these designers, Acorn Computers evaluated a number of chips and decided to develop their own, using VLSI Technology, a company founded by more Fairchild Semiconductor alumni) to manufacture the chip in their foundry. Sophie Wilson, then Roger, worked on an instruction set for the RISC. Out of this came the Acorn RISC Machine, or ARM chip. Over 100 billion ARM processors have been produced, well over 10 for every human on the planet. You know that fancy new A13 that Apple announced. It uses a licensed ARM core. Another chip that came out of the RISC family was the SUN Sparc. Sun being short for Stanford University Network, co-founder Andy Bchtolsheim, they were close to the action and released the SPARC in 1986. I still have a SPARC 20 I use for this and that at home. Not that SPARC has gone anywhere. They're just made by Oracle now. The Intel 80386 chip was a 32 bit microprocessor released in 1985. The first chip had 275,000 transistors, taking plenty of pages from the lessons learned in the VLSI projects. Compaq built a machine on it, but really the IBM PC/AT made it an accepted standard, although this was the beginning of the end of IBMs hold on the burgeoning computer industry. And AMD, yet another company founded by Fairchild defectors, created the Am386 in 1991, ending Intel's nearly 5 year monopoly on the PC clone industry and ending an era where AMD was a second source of Intel parts but instead was competing with Intel directly. We can thank AMD's aggressive competition with Intel for helping to keep the CPU industry going along Moore's law! At this point transistors were only 1.5 microns in size. Much, much smaller than a cats whisker. The Intel 80486 came in 1989 and again tracking against Moore's Law we hit the first 1 million transistor chip. Remember how Compaq helped end IBM's hold on the PC market? When the Intel 486 came along they went with AMD. This chip was also important because we got L1 caches, meaning that chips didn't need to send instructions to other parts of the motherboard but could do caching internally. From then on, the L1 and later L2 caches would be listed on all chips. We'd finally broken 100MHz! Motorola released the 68050 in 1990, hitting 1.2 Million transistors, and giving Apple the chip that would define the Quadra and also that L1 cache. The DEC Alpha came along in 1992, also a RISC chip, but really kicking off the 64-bit era. While the most technically advanced chip of the day, it never took off and after DEC was acquired by Compaq and Compaq by HP, the IP for the Alpha was sold to Intel in 2001, with the PC industry having just decided they could have all their money. But back to the 90s, ‘cause life was better back when grunge was new. At this point, hobbyists knew what the CPU was but most normal people didn't. The concept that there was a whole Univac on one of these never occurred to most people. But then came the Pentium. Turns out that giving a chip a name and some marketing dollars not only made Intel a household name but solidified their hold on the chip market for decades to come. While the Intel Inside campaign started in 1991, after the Pentium was released in 1993, the case of most computers would have a sticker that said Intel Inside. Intel really one upped everyone. The first Pentium, the P5 or 586 or 80501 had 3.1 million transistors that were 16.7 micrometers. Computers kept getting smaller and cheaper and faster. Apple answered by moving to the PowerPC chip from IBM, which owed much of its design to the RISC. Exactly 10 years after the famous 1984 Super Bowl Commercial, Apple was using a CPU from IBM. Another advance came in 1996 when IBM developed the Power4 chip and gave the world multi-core processors, or a CPU that had multiple CPU cores inside the CPU. Once parallel processing caught up to being able to have processes that consumed the resources on all those cores, we saw Intel's Pentium D, and AMD's Athlon 64 x2 released in May 2005 bringing multi-core architecture to the consumer. This led to even more parallel processing and an explosion in the number of cores helped us continue on with Moore's Law. There are now custom chips that reach into the thousands of cores today, although most laptops have maybe 4 cores in them. Setting multi-core architectures aside for a moment, back to Y2K when Justin Timberlake was still a part of NSYNC. Then came the Pentium Pro, Pentium II, Celeron, Pentium III, Xeon, Pentium M, Xeon LV, Pentium 4. On the IBM/Apple side, we got the G3 with 6.3 million transistors, G4 with 10.5 million transistors, and the G5 with 58 million transistors and 1,131 feet of copper interconnects, running at 3GHz in 2002 - so much copper that NSYNC broke up that year. The Pentium 4 that year ran at 2.4 GHz and sported 50 million transistors. This is about 1 transistor per dollar made off Star Trek: Nemesis in 2002. I guess Attack of the Clones was better because it grossed over 300 Million that year. Remember how we broke the million transistor mark in 1989? In 2005, Intel started testing Montecito with certain customers. The Titanium-2 64-bit CPU with 1.72 billion transistors, shattering the billion mark and hitting a billion two years earlier than projected. Apple CEO Steve Jobs announced Apple would be moving to the Intel processor that year. NeXTSTEP had been happy as a clam on Intel, SPARC or HP RISC so given the rapid advancements from Intel, this seemed like a safe bet and allowed Apple to tell directors in IT departments “see, we play nice now.” And the innovations kept flowing for the next decade and a half. We packed more transistors in, more cache, cleaner clean rooms, faster bus speeds, with Intel owning the computer CPU market and AMD slowly growing from the ashes of Acorn computer into the power-house that AMD cores are today, when embedded in other chips designs. I'd say not much interesting has happened, but it's ALL interesting, except the numbers just sound stupid they're so big. And we had more advances along the way of course, but it started to feel like we were just miniaturizing more and more, allowing us to do much more advanced computing in general. The fifth generation of computing is all about technologies that we today consider advanced. Artificial Intelligence, Parallel Computing, Very High Level Computer Languages, the migration away from desktops to laptops and even smaller devices like smartphones. ULSI, or Ultra Large Scale Integration chips not only tells us that chip designers really have no creativity outside of chip architecture, but also means millions up to tens of billions of transistors on silicon. At the time of this recording, the AMD Epic Rome is the single chip package with the most transistors, at 32 billion. Silicon is the seventh most abundant element in the universe and the second most in the crust of the planet earth. Given that there's more chips than people by a huge percentage, we're lucky we don't have to worry about running out any time soon! We skipped RAM in this episode. But it kinda' deserves its own, since RAM is still following Moore's Law, while the CPU is kinda' lagging again. Maybe it's time for our friends at DARPA to get the kids from Berkley working at VERYUltra Large Scale chips or VULSIs! Or they could sign on to sponsor this podcast! And now I'm going to go take a VERYUltra Large Scale nap. Gentle listeners I hope you can do that as well. Unless you're driving while listening to this. Don't nap while driving. But do have a lovely day. Thank you for listening to yet another episode of the History of Computing Podcast. We're so lucky to have you!

BSD Now
Episode 280: FOSS Clothing | BSD Now 280

BSD Now

Play Episode Listen Later Jan 10, 2019 52:23


A EULA in FOSS clothing, NetBSD with more LLVM support, Thoughts on FreeBSD 12.0, FreeBSD Performance against Windows and Linux on Xeon, Microsoft shipping NetBSD, and more. Headlines A EULA in FOSS clothing? There was a tremendous amount of reaction to and discussion about my blog entry on the midlife crisis in open source. As part of this discussion on HN, Jay Kreps of Confluent took the time to write a detailed response — which he shortly thereafter elevated into a blog entry. Let me be clear that I hold Jay in high regard, as both a software engineer and an entrepreneur — and I appreciate the time he took to write a thoughtful response. That said, there are aspects of his response that I found troubling enough to closely re-read the Confluent Community License — and that in turn has led me to a deeply disturbing realization about what is potentially going on here. To GitHub: Assuming that this is in fact a EULA, I think it is perilous to allow EULAs to sit in public repositories. It’s one thing to have one click through to accept a license (though again, that itself is dubious), but to say that a git clone is an implicit acceptance of a contract that happens to be sitting somewhere in the repository beggars belief. With efforts like choosealicense.com, GitHub has been a model in guiding projects with respect to licensing; it would be helpful for GitHub’s counsel to weigh in on their view of this new strain of source-available proprietary software and the degree to which it comes into conflict with GitHub’s own terms of service. To foundations concerned with software liberties, including the Apache Foundation, the Linux Foundation, the Free Software Foundation, the Electronic Frontier Foundation, the Open Source Initiative, and the Software Freedom Conservancy: the open source community needs your legal review on this! I don’t think I’m being too alarmist when I say that this is potentially a dangerous new precedent being set; it would be very helpful to have your lawyers offer their perspectives on this, even if they disagree with one another. We seem to be in some terrible new era of frankenlicenses, where the worst of proprietary licenses are bolted on to the goodwill created by open source licenses; we need your legal voices before these creatures destroy the village! NetBSD and LLVM NetBSD entering 2019 with more complete LLVM support I’m recently helping the NetBSD developers to improve the support for this operating system in various LLVM components. As you can read in my previous report, I’ve been focusing on fixing build and test failures for the purpose of improving the buildbot coverage. Previously, I’ve resolved test failures in LLVM, Clang, LLD, libunwind, openmp and partially libc++. During the remainder of the month, I’ve been working on the remaining libc++ test failures, improving the NetBSD clang driver and helping Kamil Rytarowski with compiler-rt. The process of upstreaming support to LLVM sanitizers has been finalized I’ve finished the process of upstreaming patches to LLVM sanitizers (almost 2000LOC of local code) and submitted to upstream new improvements for the NetBSD support. Today out of the box (in unpatched version) we have support for a variety of compiler-rt LLVM features: ASan (finds unauthorized memory access), UBSan (finds unspecified code semantics), TSan (finds threading bugs), MSan (finds uninitialized memory use), SafeStack (double stack hardening), Profile (code coverage), XRay (dynamic code tracing); while other ones such as Scudo (hardened allocator) or DFSan (generic data flow sanitizer) are not far away from completeness. The NetBSD support is no longer visibly lacking behind Linux in sanitizers, although there are still failing tests on NetBSD that are not observed on Linux. On the other hand there are features working on NetBSD that are not functional on Linux, like sanitizing programs during early initialization process of OS (this is caused by /proc dependency on Linux that is mounted by startup programs, while NetBSD relies on sysctl(3) interfaces that is always available). News Roundup Thoughts on FreeBSD 12.0 Playing with FreeBSD with past week I don’t feel as though there were any big surprises or changes in this release compared to FreeBSD 11. In typical FreeBSD fashion, progress tends to be evolutionary rather than revolutionary, and this release feels like a polished and improved incremental step forward. I like that the installer handles both UFS and ZFS guided partitioning now and in a friendly manner. In the past I had trouble getting FreeBSD’s boot menu to work with boot environments, but that has been fixed for this release. I like the security options in the installer too. These are not new, but I think worth mentioning. FreeBSD, unlike most Linux distributions, offers several low-level security options (like hiding other users’ processes and randomizing PIDs) and I like having these presented at install time. It’s harder for people to attack what they cannot see, or predict, and FreeBSD optionally makes these little adjustment for us. Something which stands out about FreeBSD, compared to most Linux distributions I run, is that FreeBSD rarely holds the user’s hand, but also rarely surprises the user. This means there is more reading to do up front and new users may struggle to get used to editing configuration files in a text editor. But FreeBSD rarely does anything unless told to do it. Updates rarely change the system’s behaviour, working technology rarely gets swapped out for something new, the system and its applications never crashed during my trial. Everything was rock solid. The operating system may seem like a minimal, blank slate to new users, but it’s wonderfully dependable and predictable in my experience. I probably wouldn’t recommend FreeBSD for desktop use. It’s close relative, GhostBSD, ships with a friendly desktop and does special work to make end user applications run smoothly. But for people who want to run servers, possible for years without change or issues, FreeBSD is a great option. It’s also an attractive choice, in my opinion, for people who like to build their system from the ground up, like you would with Debian’s server install or Arch Linux. Apart from the base tools and documentation, there is nothing on a FreeBSD system apart from what we put on it. FreeBSD 12.0 Performance Against Windows & Linux On An Intel Xeon Server Last week I posted benchmarks of Windows Server 2019 against various Linux distributions using a Tyan dual socket Intel Xeon server. In this article are some complementary results when adding in the performance of FreeBSD 11.2 against the new FreeBSD 12.0 stable release for this leading BSD operating system. As some fun benchmarks to end out 2018, here are the results of FreeBSD 11.2/12.0 (including an additional run when using GCC rather than Clang) up against Windows Server and several enterprise-ready Linux distributions. While FreeBSD 12.0 had picked up just one win of the Windows/Linux comparisons run, the FreeBSD performance is moving in the right direction. FreeBSD 12.0 was certainly faster than FreeBSD 11.2 on this dual Intel Xeon Scalable server based on a Tyan 1U platform. Meanwhile, to no surprise given the data last week, Clear Linux was by far the fastest out-of-the-box operating system tested. I did run some extra benchmarks on FreeBSD 11.2/12.0 with this hardware: in total I ran 120 benchmarks for these BSD tests. Of the 120 tests, there were just 15 cases where FreeBSD 11.2 was faster than 12.0. Seeing FreeBSD 12.0 faster than 11.2 nearly 90% of the time is an accomplishment and usually with other operating systems we see more of a mixed bag on new releases with not such solidly better performance. It was also great seeing the competitive performance out of FreeBSD when using the Clang compiler for the source-based tests compared to the GCC8 performance. Additional data available via this OpenBenchmarking.org result file. How NetBSD came to be shipped by Microsoft Google cache in case the site is down In 2000, Joe Britt, Matt Hershenson and Andy Rubin formed Danger Incorporated. Danger developed the world’s first recognizable smartphone, the Danger HipTop. T-Mobile sold the first HipTop under the brand name Sidekick in October of 2002. Danger had a well developed kernel that had been designed and built in house. The kernel came to be viewed as not a core intellectual property and Danger started a search for a replacement. For business reasons, mostly to do with legal concerns over the Gnu Public License, Danger rejected Linux and began to consider BSD Unix as a replacement for the kernel. In 2006 I was hired by Mike Chen, the manager of the kernel development group to investigate the feasibility of replacing the Danger kernel with a BSD kernel, to select the version of BSD to use, to develop a prototype and to develop the plan for adapting BSD to Danger’s requirements. NetBSD was easily the best choice among the BSD variations at the time because it had well developed cross development tools. It was easy to use a NetBSD desktop running an Intel release to cross compile a NetBSD kernel and runtime for a device running an ARM processor. (Those interested in mailing list archaeology might be amused to investigate NetBSD technical mailing list for mail from picovex, particularly from Bucky Katz at picovex.) We began product development on the specific prototype of the phone that would become the Sidekick LX2009 in 2007 and contracts for the phone were written with T-Mobile. We were about half way through the two year development cycle when Microsoft purchased Danger in 2008. Microsoft would have preferred to ship the Sidekick running Windows/CE rather than NetBSD, but a schedule analysis performed by me, and another by an independent outside contractor, indicated that doing so would result in unacceptable delay. Beastie Bits Unleashed 1.2 Released 35th CCC - Taming the Chaos: Can we build systems that actually work? Potholes to avoid when migrating to IPv6 XScreenSaver 5.42 SSH Examples and Tunnels Help request - mbuf(9) - request for comment NSA to release free Reverse Engineering Tool Running FreeBSD on a Raspberry Pi3 using a custom image created with crochet and poudriere Feedback/Questions Dries - Lets talk a bit about VIMAGE jails ohb - Question About ZFS Root Dataset Micah - Active-Active NAS Sync recommendations Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

Day in Tech History Podcast - Apple History
January 9, 2001: Mac OSX, iTunes Media Platform

Day in Tech History Podcast - Apple History

Play Episode Listen Later Jan 8, 2019 6:11


At MacWorld 2001, Steve Jobs announced Mac OSX – the base OS for Apple for the next couple decades. With Darwin, an open source BSD Unix service, 2D (Quartz), 3D (OpenGL) and Quicktime (QT5). The programming language of Classic, Carbon and Cocoa allowed programs from OS9 to run. Cocoa is an object oriented API for […]

Microsoft Today
MSFT Today 2019-01-03 : AI, Automation and Microsoft

Microsoft Today

Play Episode Listen Later Jan 3, 2019 38:57


The application of machines to tasks once performed by human beings or, increasingly, to tasks that would otherwise be impossible. Although the term mechanization is often used to refer to the simple replacement of human labour by machines, automation generally implies the integration of machines into a self-governing system. Automation has revolutionized those areas in which it has been introduced, and there is scarcely an aspect of modern life that has been unaffected by it. — Britannica The term “automation” was first used by Ford employee D.S. Harder in 1946 Automation isn’t changing the world, it has been changing the world Machine learning is simply accelerating the progress at a compounding rate In short, the machines are teaching themselves to automate faster The more computing power we throw at it, the faster it works Also according to Britannica:Machine learning discipline concerned with the implementation of computer software that can learn autonomously.Expert systems and data mining programs are the most common applications for improving algorithms through the use of machine learning. Among the most common approaches are the use of artificial neural networks (weighted decision paths) and genetic algorithms (symbols “bred” and culled by algorithms to produce successively fitter programs).History Automation is not a new concept Cotton gin Steam engine Industrial revolution Computers Quantum computing and nanotechnology Bill Gates is often attributed with a quote:I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it. As a Bill Gates fan, I’ve never been able to substantiate the attribution, but it seems to be similar to a quote from a 1920 article in “Popular Science Monthly” Bill probably didn’t say that, but it doesn’t make it a bad quote. Humans have always looked for easier ways to do hard jobs. Which brings us to, CGP Grey’s 2014 YouTube film, Human’s Need Not Apply.Humans Need Not Apply In the film by CGP Grey he brilliantly and succinctly outlines how humans have allows innovated an easier (or lazier) way of doing things — and modern automation, machine learning and artificial intelligence is no different. We’re trying to unlock “easy mode” for complex problems. At its core, there is absolutely nothing inherently wrong about mankind’s evolution into machine reliance, but at the foundation of it all is there is the serious threat to our society as we know it — and that is economics. As machines can do more jobs, that will mean fewer jobs for people.(0:46–1:03) Some people have been specialized to be programmers … whose job it is to build mechanical minds Like their “dumb” mechanical forefathers, “Mechanical Minds” are making “Mechanical Brains” in less demand.(1:50–2:16) General purpose is a big deal. Think computers … when cheap-ish personal computers appeared they quickly became vital to everything General purpose is a big deal, as machines can do more than one job investments in them will grow exponentially(3:13–31) We think of technological change as the fancy new expensive stuff, but the real change comes from last decade stuff becoming cheaper and faster… Again, as product improvements iterate faster over time, costs drop exponentially lowering the barrier for entry more and more. He then goes on to discuss horses, and the fact that their population peaked in 1915, just and quickly went into a free fall due to the proliferation of the automobile. There is a correlation between horses and humans in this regard, because like horses who were “workers” for centuries before the automobile, they became obsolete not that long afterward… and the important part is, they didn’t find “new jobs” when it happened. “Mechanical Minds” will eventually send humans the way of the horse, if we do not prepare.(4:26–4:59) As mechanical horses pushed horses out of the economy, mechanical minds will do the same to humans… so now does the car show us the shape of things to come.” I’m sure you can likely predict where this is going…(5:01–5:08) … The question is not if they will replace cars, but how quickly. They don’t need to be perfect, they just need to be better than us… The tipping point for the transportation world being thrown on its head will come down to insurance… the moment insurance costs for automated vehicles is cheaper than human driven vehicles, is the moment that every single company in the transportation industry will being making the change to autonomous vehicles.(5:53–7:03) The transportation industry in the United States employs about 3 million people, which worldwide is 70 million jobs at a minimum… economics always wins… That is an enormous economic hit(7:04–9:08) Software bots are coming for white color jobs Machine learning can teach software bots faster than human programmers ever could. Algorithmic trading is a big area at the forefront of this technological revolution.Investment banking But it doesn’t stop there. Professional and specialized positions are being challenged by bots as well, doing everything from providing legal and medical advice, to creating artistic works of art, music and even completely unique and lifelike people… that’s right, Nvidia’s GANs or Generative Adversarial Networks AI can develop completely life-like 3D renders of people who don’t exist. Their GANs are based on a machine learning research paper released by Ian J. Goodfellow in just 2014… and now they have already revolutionized machine learning and AI!Where Does Microsoft Fit Into all of This? Microsoft is quite literally developing and supporting AI everywhere it can: Microsoft Research Project Brainwave Microsoft AI - Deep Neural Network, Bing Decision Engine Azure Datacenters (Intel FPGA) Azure Machine Learning Azure Logic Apps Workflow Definition Language Microsoft Flow PowerApps SharePoint Microsoft Bot Framework Zo AI — Zo Social Bot, Skype (and Xbox), Instagram, Group Me, Facebook Office 365 Microsoft Teams Data Connectors and APIs Windows 10 IoT Cortana Cortana is not in trouble, she has always been powered by the Bing Decision Engine Cortana has just been the "face" of the AI Which is now part of the Deep Neural Network of Microsoft AI Microsoft partnering with Amazon for Alexa was a brilliant move, as they now have the data from all of the devices where Alexa is used… That's because… Microsoft partnering with Amazon for Alexa was a brilliant move, as they now have the data from all of the devices where Alexa is used... that’s because… Machine learning is all about data, and no company in the world has as much real-world data and user metrics than Microsoft. Just think of the 100+ million users of Office 365 and OneDrive, and the tens of millions of daily users of Skype and Xbox Live, and the more than 1 billion Windows users worldwide. Throw on top of that the countless computations that take place at their Azure data centers which house the systems for all of those services. This is also why we’ve seen a massive shit by Microsoft to not only fully embrace open source, but to be a thought leader and visionary with it. Microsoft now has its own BSD Unix operating system, supports Ubuntu as a subsystem on Windows 10, and recently open-sourced the Xamarin software development kit… when you think of all of that, the GitHub acquisition is a no-brainer. Now that we’ve discussed the future, and the groundwork Microsoft has laid to build it, in the next episode we will discuss what we can do to prepare ourselves for our machine overlords. Thanks so much for tuning in, and for the tremendous support we’ve received so far. I can’t wait to see where this journey takes us over the coming months, and I am truly excited to have many of you on to share as well. Until next time…Follow or Subscribe to Microsoft Today Patreon  Website Apple/iTunes Blubrry Breaker Facebook Google Podcasts Pocket Cast PodBean RadioPublic Spotify Stitcher YouTube Support the show.

BSD Now
Episode 269: Tiny Daemon Lib | BSD Now 269

BSD Now

Play Episode Listen Later Oct 24, 2018 88:19


FreeBSD Foundation September Update, tiny C lib for programming Unix daemons, EuroBSDcon trip reports, GhostBSD tested on real hardware, and a BSD auth module for duress. ##Headlines FreeBSD Foundation Update, September 2018 MESSAGE FROM THE EXECUTIVE DIRECTOR Dear FreeBSD Community Member, It is hard to believe that September is over. The Foundation team had a busy month promoting FreeBSD all over the globe, bug fixing in preparation for 12.0, and setting plans in motion to kick off our 4th quarter fundraising and advocacy efforts. Take a minute to see what we’ve been up to and please consider making a donation to help us continue our efforts supporting FreeBSD! September 2018 Development Projects Update In preparation for the release of FreeBSD 12.0, I have been working on investigating and fixing a backlog of kernel bug reports. Of course, this kind of work is never finished, and we will continue to make progress after the release. In the past couple of months I have fixed a combination of long-standing issues and recent regressions. Of note are a pair of UNIX domain socket bugs which had been affecting various applications for years. In particular, Chromium tabs would frequently hang unless a workaround was manually applied to the system, and the bug had started affecting recent versions of Firefox as well. Fixing these issues gave me an opportunity to revisit and extend our regression testing for UNIX sockets, which, in turn, resulted in some related bugs being identified and fixed. Of late I have also been investigating reports of issues with ZFS, particularly, those reported on FreeBSD 11.2. A number of regressions, including a kernel memory leak and issues with ARC reclamation, have already been fixed for 12.0; investigation of other reports is ongoing. Those who closely follow FreeBSD-CURRENT know that some exciting work to improve memory usage on NUMA systems is now enabled by default. As is usually the case when new code is deployed in a diverse array of systems and workloads, a number of problems since have been identified. We are working on resolving them as soon as possible to ensure the quality of the release. I’m passionate about maintaining FreeBSD’s stability and dependability as it continues to expand and grow new features, and I’m grateful to the FreeBSD Foundation for sponsoring this work. We depend on users to report problems to the mailing lists and via the bug tracker, so please try running the 12.0 candidate builds and help us make 12.0 a great release. Fundraising Update: Supporting the Project It’s officially Fall here at Foundation headquarters and we’re heading full-steam into our final fundraising campaign of the year. We couldn’t even have begun to reach our funding goal of $1.25 million dollars without the support from the companies who have partnered with us this year. Thank you to Verisign for becoming a Silver Partner. They now join a growing list of companies like Xiplink, NetApp, Microsoft, Tarsnap, VMware, and NeoSmart Technologies that are stepping up and showing their commitment to FreeBSD! Funding from commercial users like these and individual users like yourself, help us continue our efforts of supporting critical areas of FreeBSD such as: Operating System Improvements: Providing staff to immediately respond to urgent problems and implement new features and functionality allowing for the innovation and stability you’ve come to rely on. Security: Providing engineering resources to bolster the capacity and responsiveness of the Security team providing your users with piece of mind when security issues arise. Release Engineering: Continue providing a full-time release engineer, resulting in timely and reliable releases you can plan around. Quality Assurance: Improving and increasing test coverage, continuous integration, and automated testing with a full-time software engineer to ensure you receive the highest quality, secure, and reliable operating system. New User Experience: Improving the process and documentation for getting new people involved with FreeBSD, and supporting those people as they become integrated into the FreeBSD Community providing the resources you may need to get new folks up to speed. Training: Supporting more FreeBSD training for undergraduates, graduates, and postgraduates. Growing the community means reaching people and catching their interest in systems software as early as possible and providing you with a bigger pool of candidates with the FreeBSD skills you’re looking for. Face-to-Face Opportunities: Facilitating collaboration among members of the community, and building connections throughout the industry to support a healthy and growing ecosystem and make it easier for you to find resources when questions emerge . We can continue the above work, if we meet our goal this year! If your company uses FreeBSD, please consider joining our growing list of 2018 partners. If you haven’t made your donation yet, please consider donating today. We are indebted to the individual donors, and companies listed above who have already shown their commitment to open source. Thank you for supporting FreeBSD and the Foundation! September 2018 Release Engineering Update The FreeBSD Release Engineering team continued working on the upcoming 12.0 RELEASE. At present, the 12.0 schedule had been adjusted by one week to allow for necessary works-in-progress to be completed. Of note, one of the works-in-progress includes updating OpenSSL from 1.0.2 to 1.1.1, in order to avoid breaking the application binary interface (ABI) on an established stable branch. Due to the level of non-trivial intrusiveness that had already been discovered and addressed in a project branch of the repository, it is possible (but not yet definite) that the schedule will need to be adjusted by another week to allow more time for larger and related updates for this particular update. Should the 12.0-RELEASE schedule need to be adjusted at any time during the release cycle, the schedule on the FreeBSD project website will be updated accordingly. The current schedule is available at: https://www.freebsd.org/releases/12.0R/schedule.html BSDCam 2018 Trip Report: Marie Helene Kvello-Aune I’d like to start by thanking the FreeBSD Foundation for sponsoring my trip to BSDCam(bridge) 2018. I wouldn’t have managed to attend otherwise. I’ve used FreeBSD in both personal and professional deployments since the year 2000, and over the last few years I have become more involved with development and documentation. I arrived in Gatwick, London at midnight. On Monday, August 13, I took the train to Cambridge, and decided to do some touristy activities as I walked from the train station to Churchill College. I ran into Allan outside the hotel right before the sky decided it was time for a heavy rainfall. Monday was mostly spent settling in, recouping after travel, and hanging out with Allan, Brad, Will and Andy later in the afternoon/evening. Read more… Continuous Integration Update The FreeBSD Foundation has sponsored the development of the Project’s continuous integration system, available at https://ci.FreeBSD.org, since June. Over the summer, we improved both the software and hardware infrastructure, and also added some new jobs for extending test coverage of the -CURRENT and -STABLE branches. Following are some highlights. New Hardware The Foundation purchased 4 new build machines for scaling up the computation power for the various test jobs. These newer, faster machines substantially speed up the time it takes to test amd64 builds, so that failing changes can be identified more quickly. Also, in August, we received a donation of 2 PINE A64-LTS boards from PINE64.org, which will be put in the hardware test lab as one part of the continuous tests. CI Staging Environment We used hardware from a previous generation CI system to build a staging environment for the CI infrastructure, which is available at https://ci-dev.freebsd.org. It executes the configurations and scripts from the “staging” branch of the FreeBSD-CI repository, and the development feature branches. We also use it to experiment with the new version of the jenkins server and plugins. Having a staging environment avoids affecting the production CI environment, reducing downtime. Mail Notification In July, we turned on failure notification for all the kernel and world build jobs. Committers will receive email containing the build information and failure log to inform them of possible problems with their modification on certain architectures. For amd64 of the -CURRENT branch, we also enabled the notification on failing regression test cases. Currently mail is sent only to the individual committers, but with help from postmaster team, we have created a dev-ci mailing list and will soon be also sending notifications there. New Test Job In August, we updated the embedded script of the virtual machine image. Originally it only executed pre-defined tests, but now this behavior can be modified by the data on the attached disk. This mechanism is used for adding new ZFS tests jobs. We are also working on analyzing and fixing the failing and skipped test cases. Work in Progress In August and September, we had two developer summits, one in Cambridge, UK and one in Bucharest, Romania. In these meetings, we discussed running special tests, such as ztest, which need a longer run time. We also planned the network testing for TCP/IP stack ###Daemonize - a Tiny C Library for Programming the UNIX Daemons Whatever they say, writing System-V style UNIX daemons is hard. One has to follow many rules to make a daemon process behave correctly on diverse UNIX flavours. Moreover, debugging such a code might be somewhat tricky. On the other hand, the process of daemon initialisation is rigid and well defined so the corresponding code has to be written and debugged once and later can be reused countless number of times. Developers of BSD UNIX were very aware of this, as there a C library function daemon() was available starting from version 4.4. The function, although non-standard, is present on many UNIXes. Unfortunately, it does not follow all the required steps to reliably run a process in the background on systems which follow System-V semantics (e.g. Linux). The details are available at the corresponding Linux man page. The main problem here, as I understand it, is that daemon() does not use the double-forking technique to avoid the situation when zombie processes appear. Whenever I encounter a problem like this one, I know it is time to write a tiny C library which solves it. This is exactly how ‘daemonize’ was born (GitHub mirror). The library consists of only two files which are meant to be integrated into the source tree of your project. Recently I have updated the library and realised that it would be good to describe how to use it on this site. If for some reason you want to make a Windows service, I have a battle tested template code for you as well. System-V Daemon Initialisation Procedure To make discussion clear we shall quote the steps which have to be performed during a daemon initialisation (according to daemon(7) manual page on Linux). I do it to demonstrate that this task is more tricky than one might expect. So, here we go: Close all open file descriptors except standard input, output, and error (i.e. the first three file descriptors 0, 1, 2). This ensures that no accidentally passed file descriptor stays around in the daemon process. On Linux, this is best implemented by iterating through /proc/self/fd, with a fallback of iterating from file descriptor 3 to the value returned by getrlimit() for RLIMITNOFILE. Reset all signal handlers to their default. This is best done by iterating through the available signals up to the limit of _NSIG and resetting them to SIGDFL. Reset the signal mask using sigprocmask(). Sanitize the environment block, removing or resetting environment variables that might negatively impact daemon runtime. Call fork(), to create a background process. In the child, call setsid() to detach from any terminal and create an independent session. In the child, call fork() again, to ensure that the daemon can never re-acquire a terminal again. Call exit() in the first child, so that only the second child (the actual daemon process) stays around. This ensures that the daemon process is re-parented to init/PID 1, as all daemons should be. In the daemon process, connect /dev/null to standard input, output, and error. In the daemon process, reset the umask to 0, so that the file modes passed to open(), mkdir() and suchlike directly control the access mode of the created files and directories. In the daemon process, change the current directory to the root directory (/), in order to avoid that the daemon involuntarily blocks mount points from being unmounted. In the daemon process, write the daemon PID (as returned by getpid()) to a PID file, for example /run/foobar.pid (for a hypothetical daemon “foobar”) to ensure that the daemon cannot be started more than once. This must be implemented in race-free fashion so that the PID file is only updated when it is verified at the same time that the PID previously stored in the PID file no longer exists or belongs to a foreign process. In the daemon process, drop privileges, if possible and applicable. From the daemon process, notify the original process started that initialization is complete. This can be implemented via an unnamed pipe or similar communication channel that is created before the first fork() and hence available in both the original and the daemon process. Call exit() in the original process. The process that invoked the daemon must be able to rely on that this exit() happens after initialization is complete and all external communication channels are established and accessible. The discussed library does most of the above-mentioned initialisation steps as it becomes immediately evident that implementation details for some of them heavily dependent on the internal logic of an application itself, so it is not possible to implement them in a universal library. I believe it is not a flaw, though, as the missed parts are safe to implement in an application code. The Library’s Application Programming Interface The generic programming interface was loosely modelled after above-mentioned BSD’s daemon() function. The library provides two user available functions (one is, in fact, implemented on top of the other) as well as a set of flags to control a daemon creation behaviour. Conclusion The objective of the library is to hide all the trickery of programming a daemon so you could concentrate on the more creative parts of your application. I hope it does this well. If you are not only interested in writing a daemon, but also want to make yourself familiar with the techniques which are used to accomplish that, the source code is available. Moreover, I would advise anyone, who starts developing for a UNIX environment to do that, as it shows many intricacies of programming for these platforms. ##News Roundup EuroBSDCon 2018 travel report and obligatory pics This was my first big BSD conference. We also planned - planned might be a big word - thought about doing a devsummit on Friday. Since the people who were in charge of that had a change of plans, I was sure it’d go horribly wrong. The day before the devsummit and still in the wrong country, I mentioned the hours and venue on the wiki, and booked a reservation for a restaurant. It turns out that everything was totally fine, and since the devsummit was at the conference venue (that was having tutorials that day), they even had signs pointing at the room we were given. Thanks EuroBSDCon conference organizers! At the devsummit, we spent some time hacking. A few people came with “travel laptops” without access to anything, like Riastradh, so I gave him access to my own laptop. This didn’t hold very long and I kinda forgot about it, but for a few moments he had access to a NetBSD source tree and an 8 thread, 16GB RAM machine with which to build things. We had a short introduction and I suggested we take some pictures, so here’s the ones we got. A few people were concerned about privacy, so they’re not pictured. We had small team to hold the camera :-) At the actual conference days, I stayed at the speaker hotel with the other speakers. I’ve attempted to make conversation with some visibly FreeBSD/OpenBSD people, but didn’t have plans to talk about anything, so there was a lot of just following people silently. Perhaps for the next conference I’ll prepare a list of questions to random BSD people and then very obviously grab a piece of paper and ask, “what was…”, read a bit from it, and say, “your latest kernel panic?”, I’m sure it’ll be a great conversation starter. At the conference itself, was pretty cool to have folks like Kirk McKusick give first person accounts of some past events (Kirk gave a talk about governance at FreeBSD), or the second keynote by Ron Broersma. My own talk was hastily prepared, it was difficult to bring the topic together into a coherent talk. Nevertheless, I managed to talk about stuff for a while 40 minutes, though usually I skip over so many details that I have trouble putting together a sufficiently long talk. I mentioned some of my coolest bugs to solve (I should probably make a separate article about some!). A few people asked for the slides after the talk, so I guess it wasn’t totally incoherent. It was really fun to meet some of my favourite NetBSD people. I got to show off my now fairly well working laptop (it took a lot of work by all of us!). After the conference I came back with a conference cold, and it took a few days to recover from it. Hopefully I didn’t infect too many people on the way back. ###GhostBSD tested on real hardware T410 – better than TrueOS? You might have heard about FreeBSD which is ultimately derived from UNIX back in the days. It is not Linux even though it is similar in many ways because Linux was designed to follow UNIX principles. Seeing is believing, so check out the video of the install and some apps as well! Nowadays if you want some of that BSD on your personal desktop how to go about? Well there is a full package or distro called GhostBSD which is based on FreeBSD current with a Mate or XFCE desktop preconfigured. I did try another package called TrueOS before and you can check out my blog post as well. Let’s give it a try on my Lenovo ThinkPad T410. You can download the latest version from ghostbsd.org. Creating a bootable USB drive was surprisingly difficult as rufus did not work and created a corrupted drive. You have to follow this procedure under Windows: download the 2.5GB .iso file and rename the extension to .img. Download Win32 Disk imager and burn the img file to an USB drive and boot from it. You will be able to start a live session and use the onboard setup to install GhostBSD unto a disk. I did encounter some bugs or quirks along the way. The installer failed the first time for some unknown reason but worked on the second attempt. The first boot stopped upon initialization of the USB3 ports (the T410 does not have USB3) but I could use some ‘exit’ command line magic to continue. The second boot worked fine. Audio was only available through headphones, not speakers but that could partially be fixed using the command line again. Lot’s of installed apps did not show up in the start menu and on goes the quirks list. Overall it is still better than TrueOS for me because drivers did work very well and I could address most of the existing bugs. On the upside: Free and open source FreeBSD package ready to go Mate or XFCE desktop (Mate is the only option for daily builds) Drivers work fine including LAN, WiFi, video 2D & 3D, audio, etc UFS or ZFS advanced file systems available Some downsides: Less driver and direct app support than Linux Installer and desktop have some quirks and bugs App-store is cumbersome, inferior to TrueOS ##Beastie Bits EuroBSDCon 2018 and NetBSD sanitizers New mandoc feature: -T html -O toc EuroBSDcon 2018 Polish BSD User Group garbage[43]: What year is it? The Demo @ 50 Microsoft ports DTrace from FreeBSD to Windows 10 OpenBSD joins Twitter NetBSD curses ripoffline improvements FCP-0101: Deprecating most 10/100 Ethernet drivers Announcing the pkgsrc-2018Q3 release Debian on OpenBSD vmd (without qemu or another debian system) A BSD authentication module for duress passwords (Joshua Stein) Disk Price/Performance Analysis ##Feedback/Questions DJ - Zombie ZFS Josua - arm tier 1? how to approach it -Gamah - 5ghz Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

BSD Now
Episode 261: FreeBSDcon Flashback | BSD Now 261

BSD Now

Play Episode Listen Later Aug 30, 2018 109:13


Insight into TrueOS and Trident, stop evildoers with pf-badhost, Flashback to FreeBSDcon ‘99, OpenBSD’s measures against TLBleed, play Morrowind on OpenBSD in 5 steps, DragonflyBSD developers shocked at Threadripper performance, and more. ##Headlines An Insight into the Future of TrueOS BSD and Project Trident Last month, TrueOS announced that they would be spinning off their desktop offering. The team behind the new project, named Project Trident, have been working furiously towards their first release. They did take a few minutes to answer some of our question about Project Trident and TrueOS. I would like to thank JT and Ken for taking the time to compile these answers. It’s FOSS: What is Project Trident? Project Trident: Project Trident is the continuation of the TrueOS Desktop. Essentially, it is the continuation of the primary “TrueOS software” that people have been using for the past 2 years. The continuing evolution of the entire TrueOS project has reached a stage where it became necessary to reorganize the project. To understand this change, it is important to know the history of the TrueOS project. Originally, Kris Moore created PC-BSD. This was a Desktop release of FreeBSD focused on providing a simple and user-friendly graphical experience for FreeBSD. PC-BSD grew and matured over many years. During the evolution of PC-BSD, many users began asking for a server focused version of the software. Kris agreed, and TrueOS was born as a scaled down server version of PC-BSD. In late 2016, more contributors and growth resulted in significant changes to the PC-BSD codebase. Because the new development was so markedly different from the original PC-BSD design, it was decided to rebrand the project. TrueOS was chosen as the name for this new direction for PC-BSD as the project had grown beyond providing only a graphical front to FreeBSD and was beginning to make fundamental changes to the FreeBSD operating system. One of these changes was moving PC-BSD from being based on each FreeBSD Release to TrueOS being based on the active and less outdated FreeBSD Current. Other major changes are using OpenRC for service management and being more aggressive about addressing long-standing issues with the FreeBSD release process. TrueOS moved toward a rolling release cycle, twice a year, which tested and merged FreeBSD changes directly from the developer instead of waiting months or even years for the FreeBSD review process to finish. TrueOS also deprecated and removed obsolete technology much more regularly. As the TrueOS Project grew, the developers found these changes were needed by other FreeBSD-based projects. These projects began expressing interest in using TrueOS rather than FreeBSD as the base for their project. This demonstrated that TrueOS needed to again evolve into a distribution framework for any BSD project to use. This allows port maintainers and source developers from any BSD project to pool their resources and use the same source repositories while allowing every distribution to still customize, build, and release their own self-contained project. The result is a natural split of the traditional TrueOS team. There were now naturally two teams in the TrueOS project: those working on the build infrastructure and FreeBSD enhancements – the “core” part of the project, and those working on end-user experience and utility – the “desktop” part of the project. When the decision was made to formally split the projects, the obvious question that arose was what to call the “Desktop” project. As TrueOS was already positioned to be a BSD distribution platform, the developers agreed the desktop side should pick a new name. There were other considerations too, one notable being that we were concerned that if we continued to call the desktop project “TrueOS Desktop”, it would prevent people from considering TrueOS as the basis for their distribution because of misconceptions that TrueOS was a desktop-focused OS. It also helps to “level the playing field” for other desktop distributions like GhostBSD so that TrueOS is not viewed as having a single “blessed” desktop version. It’s FOSS: What features will TrueOS add to the FreeBSD base? Project Trident: TrueOS has already added a number of features to FreeBSD: OpenRC replaces rc.d for service management LibreSSL in base Root NSS certificates out-of-box Scriptable installations (pc-sysinstall) The full list of changes can be seen on the TrueOS repository (https://github.com/trueos/trueos/blob/trueos-master/README.md). This list does change quite regularly as FreeBSD development itself changes. It’s FOSS: I understand that TrueOS will have a new feature that will make creating a desktop spin of TrueOS very easy. Could you explain that new feature? Project Trident: Historically, one of the biggest hurdles for creating a desktop version of FreeBSD is that the build options for packages are tuned for servers rather than desktops. This means a desktop distribution cannot use the pre-built packages from FreeBSD and must build, use, and maintain a custom package repository. Maintaining a fork of the FreeBSD ports tree is no trivial task. TrueOS has created a full distribution framework so now all it takes to create a custom build of FreeBSD is a single JSON manifest file. There is now a single “source of truth” for the source and ports repositories that is maintained by the TrueOS team and regularly tagged with “stable” build markers. All projects can use this framework, which makes updates trivial. It’s FOSS: Do you think that the new focus of TrueOS will lead to the creation of more desktop-centered BSDs? Project Trident: That is the hope. Historically, creating a desktop-centered BSD has required a lot of specialized knowledge. Not only do most people not have this knowledge, but many do not even know what they need to learn until they start troubleshooting. TrueOS is trying to drastically simplify this process to enable the wider Open Source community to experiment, contribute, and enjoy BSD-based projects. It’s FOSS: What is going to happen to TrueOS Pico? Will Project Trident have ARM support? Project Trident: Project Trident will be dependent on TrueOS for ARM support. The developers have talked about the possibility of supporting ARM64 and RISC-V architectures, but it is not possible at the current time. If more Open Source contributors want to help develop ARM and RISC-V support, the TrueOS project is definitely willing to help test and integrate that code. It’s FOSS: What does this change (splitting Trus OS into Project Trident) mean for the Lumina desktop environment? Project Trident: Long-term, almost nothing. Lumina is still the desktop environment for Project Trident and will continue to be developed and enhanced alongside Project Trident just as it was for TrueOS. Short-term, we will be delaying the release of Lumina 2.0 and will release an updated version of the 1.x branch (1.5.0) instead. This is simply due to all the extra overhead to get Project Trident up and running. When things settle down into a rhythm, the development of Lumina will pick up once again. It’s FOSS: Are you planning on including any desktop environments besides Lumina? Project Trident: While Lumina is included by default, all of the other popular desktop environments will be available in the package repo exactly as they had been before. It’s FOSS: Any plans to include Steam to increase the userbase? Project Trident: Steam is still unavailable natively on FreeBSD, so we do not have any plans to ship it out of the box currently. In the meantime, we highly recommend installing the Windows version of Steam through the PlayOnBSD utility. It’s FOSS: What will happen to the AppCafe? Project Trident: The AppCafe is the name of the graphical interface for the “pkg” utility integrated into the SysAdm client created by TrueOS. This hasn’t changed. SysAdm, the graphical client, and by extension AppCafe are still available for all TrueOS-based distributions to use. It’s FOSS: Does Project Trident have any corporate sponsors lined up? If not, would you be open to it or would you prefer that it be community supported? Project Trident: iXsystems is the first corporate sponsor of Project Trident and we are always open to other sponsorships as well. We would prefer smaller individual contributions from the community, but we understand that larger project needs or special-purpose goals are much more difficult to achieve without allowing larger corporate sponsorships as well. In either case, Project Trident is always looking out for the best interests of the community and will not allow intrusive or harmful code to enter the project even if a company or individual tries to make that code part of a sponsorship deal. It’s FOSS: BSD always seems to be lagging in terms of support for newer devices. Will TrueOS be able to remedy that with a quicker release cycle? Project Trident: Yes! That was a primary reason for TrueOS to start tracking the CURRENT branch of FreeBSD in 2016. This allows for the changes that FreeBSD developers are making, including new hardware support, to be available much sooner than if we followed the FreeBSD release cycle. It’s FOSS: Do you have any idea when Project Trident will have its first release? Project Trident: Right now we are targeting a late August release date. This is because Project Trident is “kicking the wheels” on the new TrueOS distribution system. We want to ensure everything is working smoothly before we release. Going forward, we plan on having regular package updates every week or two for the end-user packages and a new release of Trident with an updated OS version every 6 months. This will follow the TrueOS release schedule with a small time offset. ###pf-badhost: Stop the evil doers in their tracks! pf-badhost is a simple, easy to use badhost blocker that uses the power of the pf firewall to block many of the internet’s biggest irritants. Annoyances such as ssh bruteforcers are largely eliminated. Shodan scans and bots looking for webservers to abuse are stopped dead in their tracks. When used to filter outbound traffic, pf-badhost blocks many seedy, spooky malware containing and/or compromised webhosts. Filtering performance is exceptional, as the badhost list is stored in a pf table. To quote the OpenBSD FAQ page regarding tables: “the lookup time on a table holding 50,000 addresses is only slightly more than for one holding 50 addresses.” pf-badhost is simple and powerful. The blocklists are pulled from quality, trusted sources. The ‘Firehol’, ‘Emerging Threats’ and ‘Binary Defense’ block lists are used as they are popular, regularly updated lists of the internet’s most egregious offenders. The pf-badhost.sh script can easily be expanded to use additional or alternate blocklists. pf-badhost works best when used in conjunction with unbound-adblock for the ultimate badhost blocking. Notes: If you are trying to run pf-badhost on a LAN or are using NAT, you will want to add a rule to your pf.conf appearing BEFORE the pf-badhost rules allowing traffic to and from your local subnet so that you can still access your gateway and any DNS servers. Conversely, adding a line to pf-badhost.sh that removes your subnet range from the table should also work. Just make sure you choose a subnet range / CIDR block that is actually in the list. 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8 are the most common home/office subnet ranges. DigitalOcean https://do.co/bsdnow ###FLASHBACK: FreeBSDCon’99: Fans of Linux’s lesser-known sibling gather for the first time FreeBSD, a port of BSD Unix to Intel, has been around almost as long as Linux has – but without the media hype. Its developer and user community recently got a chance to get together for the first time, and they did it in the city where BSD – the Berkeley Software Distribution – was born some 25 years ago. October 17, 1999 marked a milestone in the history of FreeBSD – the first FreeBSD conference was held in the city where it all began, Berkeley, CA. Over 300 developers, users, and interested parties attended from around the globe. This was easily 50 percent more people than the conference organizers had expected. This first conference was meant to be a gathering mostly for developers and FreeBSD advocates. The turnout was surprisingly (and gratifyingly) large. In fact, attendance exceeded expectations so much that, for instance, Kirk McKusick had to add a second, identical tutorial on FreeBSD internals, because it was impossible for everyone to attend the first! But for a first-ever conference, I was impressed by how smoothly everything seemed to go. Sessions started on time, and the sessions I attended were well-run; nothing seemed to be too cold, dark, loud, late, or off-center. Of course, the best part about a conference such as this one is the opportunity to meet with other people who share similar interests. Lunches and breaks were a good time to meet people, as was the Tuesday night beer bash. The Wednesday night reception was of a type unusual for the technical conferences I usually attend – a three-hour Hornblower dinner cruise on San Francisco Bay. Not only did we all enjoy excellent food and company, but we all got to go up on deck and watch the lights of San Francisco and Berkeley as we drifted by. Although it’s nice when a conference attracts thousands of attendees, there are some things that can only be done with smaller groups of people; this was one of them. In short, this was a tiny conference, but a well-run one. Sessions Although it was a relatively small conference, the number and quality of the sessions belied the size. Each of the three days of the conference featured a different keynote speaker. In addition to Jordan Hubbard, Jeremy Allison spoke on “Samba Futures” on day two, and Brian Behlendorf gave a talk on “FreeBSD and Apache: A Perfect Combo” to start off the third day. The conference sessions themselves were divided into six tracks: advocacy, business, development, networking, security, and panels. The panels track featured three different panels, made up of three different slices of the community: the FreeBSD core team, a press panel, and a prominent user panel with representatives from such prominent commercial users as Yahoo! and USWest. I was especially interested in Apple Computer’s talk in the development track. Wilfredo Sanchez, technical lead for open source projects at Apple (no, that’s not an oxymoron!) spoke about Apple’s Darwin project, the company’s operating system road map, and the role of BSD (and, specifically, FreeBSD) in Apple’s plans. Apple and Unix have had a long and uneasy history, from the Lisa through the A/UX project to today. Personally, I’m very optimistic about the chances for the Darwin project to succeed. Apple’s core OS kernel team has chosen FreeBSD as its reference platform. I’m looking forward to what this partnership will bring to both sides. Other development track sessions included in-depth tutorials on writing device drivers, basics of the Vinum Volume Manager, Fibre Channel, development models (the open repository model), and the FreeBSD Documentation Project (FDP). If you’re interested in contributing to the FreeBSD project, the FDP is a good place to start. Advocacy sessions included “How One Person Can Make a Difference” (a timeless topic that would find a home at any technical conference!) and “Starting and Managing A User Group” (trials and tribulations as well as rewards). The business track featured speakers from three commercial users of FreeBSD: Cybernet, USWest, and Applix. Applix presented its port of Applixware Office for FreeBSD and explained how Applix has taken the core services of Applixware into open source. Commercial applications and open source were once a rare combination; we can only hope the trend away from that state of affairs will continue. Commercial use of FreeBSD The use of FreeBSD in embedded applications is increasing as well – and it is increasing at the same rate that hardware power is. These days, even inexpensive systems are able to run a BSD kernel. The BSD license and the solid TCP/IP stack prove significant enticements to this market as well. (Unlike the GNU Public License, the BSD license does not require that vendors make derivative works open source.) Companies such as USWest and Verio use FreeBSD for a wide variety of different Internet services. Yahoo! and Hotmail are examples of companies that use FreeBSD extensively for more specific purposes. Yahoo!, for example, has many hundreds of FreeBSD boxes, and Hotmail has almost 2000 FreeBSD machines at its data center in the San Francisco Bay area. Hotmail is owned by Microsoft, so the fact that it runs FreeBSD is a secret. Don’t tell anyone… When asked to comment on the increasing commercial interest in BSD, Hubbard said that FreeBSD is learning the Red Hat lesson. “Walnut Creek and others with business interests in FreeBSD have learned a few things from the Red Hat IPO,” he said, “and nobody is just sitting around now, content with business as usual. It’s clearly business as unusual in the open source world today.” Hubbard had also singled out some of BSD’s commercial partners, such as Whistle Communications, for praise in his opening day keynote. These partners play a key role in moving the project forward, he said, by contributing various enhancements and major new systems, such as Netgraph, as well as by contributing paid employee time spent on FreeBSD. Even short FreeBSD-related contacts can yield good results, Hubbard said. An example of this is the new jail() security code introduced in FreeBSD 3.x and 4.0, which was contributed by R & D Associates. A number of ISPs are also now donating the hardware and bandwidth that allows the project to provide more resource mirrors and experimental development sites. See you next year And speaking of corporate sponsors, thanks go to Walnut Creek for sponsoring the conference, and to Yahoo! for covering all the expenses involved in bringing the entire FreeBSD core team to Berkeley. As a fan of FreeBSD, I’m happy to see that the project has finally produced a conference. It was time: many of the 16 core team members had been working together on a regular basis for nearly seven years without actually meeting face to face. It’s been an interesting year for open source projects. I’m looking forward to the next year – and the next BSD conference – to be even better. ##News Roundup OpenBSD Recommends: Disable SMT/Hyperthreading in all Intel BIOSes Two recently disclosed hardware bugs affected Intel cpus: - TLBleed - T1TF (the name "Foreshadow" refers to 1 of 3 aspects of this bug, more aspects are surely on the way) Solving these bugs requires new cpu microcode, a coding workaround, *AND* the disabling of SMT / Hyperthreading. SMT is fundamentally broken because it shares resources between the two cpu instances and those shared resources lack security differentiators. Some of these side channel attacks aren't trivial, but we can expect most of them to eventually work and leak kernel or cross-VM memory in common usage circumstances, even such as javascript directly in a browser. There will be more hardware bugs and artifacts disclosed. Due to the way SMT interacts with speculative execution on Intel cpus, I expect SMT to exacerbate most of the future problems. A few months back, I urged people to disable hyperthreading on all Intel cpus. I need to repeat that: DISABLE HYPERTHREADING ON ALL YOUR INTEL MACHINES IN THE BIOS. Also, update your BIOS firmware, if you can. OpenBSD -current (and therefore 6.4) will not use hyperthreading if it is enabled, and will update the cpu microcode if possible. But what about 6.2 and 6.3? The situation is very complex, continually evolving, and is taking too much manpower away from other tasks. Furthermore, Intel isn't telling us what is coming next, and are doing a terrible job by not publically documenting what operating systems must do to resolve the problems. We are having to do research by reading other operating systems. There is no time left to backport the changes -- we will not be issuing a complete set of errata and syspatches against 6.2 and 6.3 because it is turning into a distraction. Rather than working on every required patch for 6.2/6.3, we will re-focus manpower and make sure 6.4 contains the best solutions possible. So please try take responsibility for your own machines: Disable SMT in the BIOS menu, and upgrade your BIOS if you can. I'm going to spend my money at a more trustworthy vendor in the future. ###Get Morrowind running on OpenBSD in 5 simple steps This article contains brief instructions on how to get one of the greatest Western RPGs of all time, The Elder Scrolls III: Morrowind, running on OpenBSD using the OpenMW open source engine recreation. These instructions were tested on a ThinkPad X1 Carbon Gen 3. The information was adapted from this OpenMW forum thread: https://forum.openmw.org/viewtopic.php?t=3510 Purchase and download the DRM-free version from GOG (also considered the best version due to the high quality PDF guide that it comes with): https://www.gog.com/game/theelderscrollsiiimorrowindgotyedition Install the required packages built from the ports tree as root. openmw is the recreated game engine, and innoextract is how we will get the game data files out of the win32 executable. pkgadd openmw innoextract Move the file from GOG setuptesmorrowindgoty2.0.0.7.exe into its own directory morrowind/ due to innoextract’s default behaviour of extracting into the current directory. Then type: innoextract setuptesmorrowindgoty2.0.0.7.exe Type openmw-wizard and follow the straightforward instructions. Note that you have a pre-existing installation, and select the morrowind/app/Data Files folder that innoextract extracted. Type in openmw-launcher, toggle the settings to your preferences, and then hit play! iXsystems https://twitter.com/allanjude/status/1034647571124367360 ###My First Clang Bug Part of the role of being a packager is compiling lots (and lots) of packages. That means compiling lots of code from interesting places and in a variety of styles. In my opinion, being a good packager also means providing feedback to upstream when things are bad. That means filing upstream bugs when possible, and upstreaming patches. One of the “exciting” moments in packaging is when tools change. So each and every major CMake update is an exercise in recompiling 2400 or more packages and adjusting bits and pieces. When a software project was last released in 2013, adjusting it to modern tools can become quite a chore (e.g. Squid Report Generator). CMake is excellent for maintaining backwards compatibility, generally accommodating old software with new policies. The most recent 3.12 release candidate had three issues filed from the FreeBSD side, all from fallout with older software. I consider the hours put into good bug reports, part of being a good citizen of the Free Software world. My most interesting bug this week, though, came from one line of code somewhere in Kleopatra: QUNUSED(gpgagentdata); That one line triggered a really peculiar link error in KDE’s FreeBSD CI system. Yup … telling the compiler something is unused made it fall over. Commenting out that line got rid of the link error, but introduced a warning about an unused function. Working with KDE-PIM’s Volker Krause, we whittled the problem down to a six-line example program — two lines if you don’t care much for coding style. I’m glad, at that point, that I could throw it over the hedge to the LLVM team with some explanatory text. Watching the process on their side reminds me ever-so-strongly of how things work in KDE (or FreeBSD for that matter): Bugzilla, Phabricator, and git combine to be an effective workflow for developers (perhaps less so for end-users). Today I got a note saying that the issue had been resolved. So brief a time for a bug. Live fast. Get squashed young. ###DragonFlyBSD Now Runs On The Threadripper 2990WX, Developer Shocked At Performance Last week I carried out some tests of BSD vs. Linux on the new 32-core / 64-thread Threadripper 2990WX. I tested FreeBSD 11, FreeBSD 12, and TrueOS – those benchmarks will be published in the next few days. I tried DragonFlyBSD, but at the time it wouldn’t boot with this AMD HEDT processor. But now the latest DragonFlyBSD development kernel can handle the 2990WX and the lead DragonFly developer calls this new processor “a real beast” and is stunned by its performance potential. When I tried last week, the DragonFlyBSD 5.2.2 stable release nor DragonFlyBSD 5.3 daily snapshot would boot on the 2990WX. But it turns out Matthew Dillon, the lead developer of DragonFlyBSD, picked up a rig and has it running now. So in time for the next 5.4 stable release or those using the daily snapshots can have this 32-core / 64-thread Zen+ CPU running on this operating system long ago forked from FreeBSD. In announcing his success in bringing up the 2990WX under DragonFlyBSD, which required a few minor changes, he shared his performance thoughts and hopes for the rig. “The cpu is a real beast, packing 32 cores and 64 threads. It blows away our dual-core Xeon to the tune of being +50% faster in concurrent compile tests, and it also blows away our older 4-socket Opteron (which we call ‘Monster’) by about the same margin. It’s an impressive CPU. For now the new beast is going to be used to help us improve I/O performance through the filesystem, further SMP work (but DFly scales pretty well to 64 threads already), and perhaps some driver to work to support the 10gbe on the mobo.” Dillon shared some results on the system as well. " The Threadripper 2990WX is a beast. It is at least 50% faster than both the quad socket opteron and the dual socket Xeon system I tested against. The primary limitation for the 2990WX is likely its 4 channels of DDR4 memory, and like all Zen and Zen+ CPUs, memory performance matters more than CPU frequency (and costs almost no power to pump up the performance). That said, it still blow away a dual-socket Xeon with 3x the number of memory channels. That is impressive!" The well known BSD developer also added, “This puts the 2990WX at par efficiency vs a dual-socket Xeon system, and better than the dual-socket Xeon with slower memory and a power cap. This is VERY impressive. I should note that the 2990WX is more specialized with its asymetric NUMA architecture and 32 cores. I think the sweet spot in terms of CPU pricing and efficiency is likely going to be with the 2950X (16-cores/32-threads). It is clear that the 2990WX (32-cores/64-threads) will max out 4-channel memory bandwidth for many workloads, making it a more specialized part. But still awesome…This thing is an incredible beast, I’m glad I got it.” While I have the FreeBSD vs. Linux benchmarks from a few days ago, it looks like now on my ever growing TODO list will be re-trying out the newest DragonFlyBSD daily snapshot for seeing how the performance compares in the mix. Stay tuned for the numbers that should be in the next day or two. ##Beastie Bits X11 on really small devices mandoc-1.14.4 released The pfSense Book is now available to everyone MWL: Burn it down! Burn it all down! Configuring OpenBSD: System and user config files for a more pleasant laptop FreeBSD Security Advisory: Resource exhaustion in TCP reassembly OpenBSD Foundation gets first 2018 Iridium donation New ZFS commit solves issue a few users reported in the feedback segment Project Trident should have a beta release by the end of next week Reminder about Stockholm BUG: September 5, 17:30-22:00 BSD-PL User Group: September 13, 18:30-21:00 Tarsnap ##Feedback/Questions Malcom - Having different routes per interface Bostjan - ZFS and integrity of data Michael - Suggestion for Monitoring Barry - Feedback Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

BSD Now
230: Your questions, Part III

BSD Now

Play Episode Listen Later Jan 24, 2018 116:59


We provide you with updates to Spectre and Meltdown from various BSD projects, a review of TrueOS from Linux, how to set up FreeBSD on ThinkPad x240, and a whole bunch of beastie bits. This episode was brought to you by Headlines KPTI patch lands in FreeBSD -current (https://svnweb.freebsd.org/base?view=revision&revision=328083) After a heroic effort by Konstantin Belousov kib@FreeBSD.org, the first meltdown patch has landed in FreeBSD This creates separate page tables for the Kernel and userland, and switches between them when executions enters the kernel, and when it returns to userland It is currently off by default, but you are encouraged to test it, so it can be merged back to the release branches. Set vm.pmap.pti=1 in /boot/loader.conf The existing implementation of PCID (process-context identifiers), is not compatible with the new PTI code, and is disabled when PTI is enabled, decreasing performance. A future patch will use PCID in a way that is compatible with PTI. PCID allows the OS to annotate memory mappings to specific processes, so that they can be flushed selectively, and so that they are only used when in the context of that application. Once the developers are relatively confident in the correctness of the code that has landed in -current, it will be ported back to FreeBSD 10 and 11, and released as a security advisory. Apparently porting back to FreeBSD 11 only has some relatively simple merge conflicts, but 10 will be more work. Former FreeBSD Security Officer Dag-Erling Smørgrav has created a meltdown testing and PoC tool (https://github.com/dag-erling/meltdown) that you can use to check your system. It is not finished yet, and doesn't seem to work with newer processors (haswell and newer). The first partial mitigation for Spectre variant 2 (https://svnweb.freebsd.org/changeset/base/328011) for bhyve on AMD64 has also been committed The latest information is always available on the FreeBSD Wiki (https://wiki.freebsd.org/action/edit/SpeculativeExecutionVulnerabilities) *** Some thoughts on Spectre and Meltdown (http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-spectre-and-meltdown.html) Colin Percival breaks down how these vulnerabilities work, with same nice analogies What is a side channel: I want to know when my girlfriend's passport expires, but she won't show me her passport (she complains that it has a horrible photo) and refuses to tell me the expiry date. I tell her that I'm going to take her to Europe on vacation in August and watch what happens: If she runs out to renew her passport, I know that it will expire before August; while if she doesn't get her passport renewed, I know that it will remain valid beyond that date. Her desire to ensure that her passport would be valid inadvertently revealed to me some information: Whether its expiry date was before or after August. Spectre Variant 1: I tell my girlfriend that I'm going to take her on vacation in June, but I don't tell her where yet; however, she knows that it will either be somewhere within Canada (for which she doesn't need a passport, since we live in Vancouver) or somewhere in Europe. She knows that it takes time to get a passport renewed, so she checks her passport and (if it was about to expire) gets it renewed just in case I later reveal that I'm going to take her to Europe. If I tell her later that I'm only taking her to Ottawa — well, she didn't need to renew her passport after all, but in the meantime her behaviour has already revealed to me whether her passport was about to expire. This is what Google refers to "variant 1" of the Spectre vulnerability: Even though she didn't need her passport, she made sure it was still valid just in case she was going to need it. Spectre Variant 2: I spend a week talking about how Oxford is a wonderful place to visit and I really enjoyed the years I spent there, and then I tell her that I want to take her on vacation. She very reasonably assumes that — since I've been talking about Oxford so much — I must be planning on taking her to England, and runs off to check her passport and potentially renew it... but in fact I tricked her and I'm only planning on taking her to Ottawa. Meltdown: I tell my girlfriend that I want to take her to the Korean peninsula. She knows that her passport is valid for long enough; but she immediately runs off to check that her North Korean visa hasn't expired. Why does she have a North Korean visa, you ask? Good question. She doesn't — but she runs off to check its expiry date anyway! Because she doesn't have a North Korean visa, she (somehow) checks the expiry date on someone else's North Korean visa, and then (if it is about to expire) runs out to renew it — and so by telling her that I want to take her to Korea for a vacation I find out something she couldn't have told me even if she wanted to. Final thoughts on vulnerability disclosure The way these issues were handled was a mess; frankly, I expected better of Google, I expected better of Intel, and I expected better of the Linux community. When I found that Hyper-Threading was easily exploitable, I spent five months notifying the security community and preparing everyone for my announcement of the vulnerability; but when the embargo ended at midnight UTC and FreeBSD published its advisory a few minutes later, the broader world was taken entirely by surprise. Nobody knew what was coming aside from the people who needed to know; and the people who needed to know had months of warning. Contrast that with what happened this time around. Google discovered a problem and reported it to Intel, AMD, and ARM on June 1st. Did they then go around contacting all of the operating systems which would need to work on fixes for this? Not even close. FreeBSD was notified the week before Christmas, over six months after the vulnerabilities were discovered. Now, FreeBSD can occasionally respond very quickly to security vulnerabilities, even when they arise at inconvenient times — on November 30th 2009 a vulnerability was reported at 22:12 UTC, and on December 1st I provided a patch at 01:20 UTC, barely over 3 hours later — but that was an extremely simple bug which needed only a few lines of code to fix; the Spectre and Meltdown issues are orders of magnitude more complex. To make things worse, the Linux community was notified and couldn't keep their mouths shut. Standard practice for multi-vendor advisories like this is that an embargo date is set, and nobody does anything publicly prior to that date. People don't publish advisories; they don't commit patches into their public source code repositories; and they definitely don't engage in arguments on public mailing lists about whether the patches are needed for different CPUs. As a result, despite an embargo date being set for January 9th, by January 4th anyone who cared knew about the issues and there was code being passed around on Twitter for exploiting them. This is not the first time I've seen people get sloppy with embargoes recently, but it's by far the worst case. As an industry we pride ourselves on the concept of responsible disclosure — ensuring that people are notified in time to prepare fixes before an issue is disclosed publicly — but in this case there was far too much disclosure and nowhere near enough responsibility. We can do better, and I sincerely hope that next time we do. CPU microcode update code for amd64 (https://undeadly.org/cgi?action=article;sid=20180115073406) (https://marc.info/?l=openbsd-tech&m=151588857304763&w=2) Patrick Wildt (patrick@) recently committed some code that will update the Intel microcode on many Intel CPUs, a diff initially written by Stefan Fritsch (sf@). The microcode of your CPU is basically the firmware that runs on your (Intel) processor, defining its instruction set in terms of so called "microinstructions". The new code depends, of course, on the corresponding firmware package, ported by Patrick which can be installed using a very recent fw_update(1). Of course, this all plays into the recently revealed problems in Intel (and other) CPUs, Meltdown and Spectre. Now Theo has explained the workings of the code on openbsd-tech, detailing some of the challenges in updating microcode on CPUs where your OS is already starting to run. Theo hints at future updates to the intel-firmware package in his mail: (https://marc.info/?l=openbsd-tech&m=151588857304763&w=2) Patrick and others committed amd64 Intel cpu microcode update code over the last few days. The approach isn't perfect, but it is good enough for a start. I want to explain the situation. When you fw_update, you'll get the firmware files. Upon a reboot, it will attempt to update the microcode on your cpus. Maybe there isn't a new microcode. Maybe your BIOS has a copy of the microcode and installs it before booting OpenBSD. This firmware installation is done a little late. Doing it better will require some work in the bootblocks to find the firmware files, but time is a bit short to do that right now. The branch-target-cache flushing features added in new microcode are not being used yet. There is more code which has to be written, but again other work is happening first. Also, Intel is saying their new microcodes sucks and people should wait a little. "Hi, my name is Intel and I'm an cheating speculator". Several developers are working on mitigations for these issues, attacking the problem from several angles. Expect to see more updates to a CVS tree near you soon. Intel: as a *BSD user, I am fucking pissed! (https://malcont.net/2018/01/dont-like-meltdown-spectre-releated-bugs-handled/) I wasn't going to write anything on the recently found x64 architecture – related bugs. I'm not a kernel developer nor even a programmer and I can't say that I have a solid understanding of what Meltdown and Spectre attacks are. Also there already is a ton of articles and posts written by people who have no grasp of the subject. I'm however a malcontent and I find this a good way to express my feelings: Intel: as a *BSD user, I am fucking pissed! Meltdown, Spectre and BSD – the “pissed” part Part of my work is UNIX-like systems administration – including BSDs and Linuces. As much as I am happy with Linux changes already made, I am beyond pissed about how the BSDs were handled by Intel – because they were not. FreeBSD Security Team received some heads-up just before Xmas, while OpenBSD, NetBSD and DragonflyBSD teams received no prior warnings. Meltdown and Spectre attacks are hard to perform. It is a hard work to mitigate them in the software, as the bugs lay in the CPUs and are not fixable by microcode updates. Developers are trying to mitigate these bugs in a way that will deliver smallest performance losses. A lot of time consuming work is needed to fix CPU vendors' mistakes. Linux developers had this time. BSD developers did not. BSD user base too small? BSD user base is small in comparison to Linux. Seems that it's too small for Intel. PlayStation4 consoles are FreeBSD-based (and use AMD CPUs) but I think it's safe to say that gaming devices are not the most important systems to be fixed. Netflix serves their content off FreeBSD but the bugs are not remotely exploitable (possibly not including JavaScript, but it's running someone's code locally) so there's probably not much harm to be done here either. However gamers and Netflix aren't the only ones who use *BSD systems. I'd say that there is more than a few FreeBSD, NetBSD, OpenBSD and DragonFlyBSD servers on the internet. In March 2017, Intel promised “more timely support to FreeBSD”. They knew about flaws in their CPUs in June and decided that a timely manner is the end of December – short before the embargo was to be lifted. Intel and Google (probably Intel more): it was your job to pick the correct people to whom the bugs can be disclosed. In my humble opinion you chose poorly by disclosing these issues with ONLY Apple, Microsoft, and the Linux Foundation, of OS vendors. You did much harm to the BSD community. Intel: It's your bugs. And you offered “more support” to the FreeBSD Foundation less than 3 months prior to being informed (my guess is that you knew much earlier) on the flaws in YOUR products. I don't want to write more here as the wording would be too strong. Interview - Viewer Questions These days, do you consider yourself more of an programmer or a sysadmin? Which one do you enjoy more? Does FreeBSD/BSD enable your business or would another OS suit your needs just as well? You've hinted that you use FreeBSD as part of your business. Can you elaborate on that and give some technical detail on how it's used in that environment? If you were allowed three wishes for anything at all to be implemented or changed in ZFS, what would they be, and why? Per Dataset throughput and IOPS limiting Per-File Cloning and/or zfsmv (move a file from one dataset to another, without copying) Cluster support Allan, you have previously mentioned that you have worked on FreeBSD on MIPS, what made you choose the Onion Omega over something like the Raspberry Pi? What is BSD Now's association with Jupiter broadcasting, and how did the relationship come to be? Jupiter seems to be associated with several Linux-themed podcasts, and I'm wondering how and why BSD Now joined Jupiter. The two communities (the Linuxes and BSDs) don't always seem to mix freely -- or do they? What kind of keyboard is that? Have you ever tried an ErgoDox? The ErgoDox EZ is made by a Canadian. You mentioned when doing one of your talks on UCL for FreeBSD that you had only recently learned C. I am also aware of your history also on contributing to the FreeBSD handbook and to documentation in general. Given you started with C relatively recently, what made you want to learn it, how quickly did you pick it up, and is it your favourite language? It is most inspiring to me, as you are clearly so talented, and of all the languages I have learned (including C++), I still prefer C in my heart of hearts. I'd be really interested to hear your answer, many thanks. *** News Roundup LinuxAndUbuntu Review Of TrueOS A Unix Based OS (http://www.linuxandubuntu.com/home/linuxandubuntu-review-of-trueos-a-unix-based-os) Trust me, the name TrueOS takes me back to 1990s when Tru64 UNIX operating system made its presence. TrueOS is PC-BSD's new unified brand built upon FreeBSD-CURRENT code base. Note that TrueOS is not a Linux distro but is BSD Unix. FreeBSD is known for its cutting-edge features, security, scalability, and ability to work both as a server and desktop operating system. TrueOS aims at having user-friendliness with the power of FreeBSD OS. Let us start with going into details of different aspects of the TrueOS. TrueOS History ? TrueOS was founded by Kris Moore in 2005 with name PC-BSD. Initial version focused to make FreeBSD easy to use starting with providing GUI based installer (to relatively complicated FreeBSD installer). In the year 2006, PC-BSD was acquired by iXsystems. Before rebranding as TrueOS in Sept 2016, PC-BSD reached a stage starting considering better than vanilla FreeBSD. Older PC-BSD version used to support both x86 and x86-64 architecture. Kris Moore, the developer founder, says about rebranding: “We've already been using TrueOS for the server side of PC-BSD, and it made sense to unify the names. PC-BSD doesn't reflect server or embedded well. TrueOS Desktop/Server/Embedded can be real products, avoids some of the alphabet soup, and gives us a more catchy name.” TrueOS First Impression ? The startup is little longer; may be due to starting up of many services. The heavy KDE well suited to PC-BSD. The C++/Qt5 based Lumina desktop environment is light and fast. The Lumina offers an easy way to configure menu and panels. I did not face any problems for continuous use of two weeks on a virtual machine having the minimal configuration: 1 GB RAM, 20 GB hard disk and Intel 3.06 GHz i3 processor. The Lumina desktop is light and fast. The developers of Lumina know what they are doing and have a good idea of what makes a good IDE. As it happens with any new desktop environment, it needs some time to settle. Let us hope that they keep to the path they are on with it. Conclusion ? The TrueOS is impressive when consider it as relatively young. It is a daring step that TrueOS developers took FreeBSD Current rather than FreeBSD Stable code base. Overall it has created its own place from the legacy shadow of PC-BSD. Starting with easy installation TrueOS is a good combination of software and utilities that make the system ready to use. Go and get a TrueOS ISO to unleash the “bleeding edge” tag of FreeBSD Thinkpad x240 - FreeBSD Setup (http://stygix.org/nix/x240-freebsd.php) What follows is a record of how I set up FreeBSD to be my daily driver OS on the Lenovo Thinkpad X240. Everything seems to work great. Although, the touchpad needs some tweaking. I've tried several configurations, even recompiling Xorg with EVDEV support and all that, to no avail. Eventually I will figure it out. Do not sleep the laptop from the command line. Do it from within Xorg, or it will not wake up. I don't know why. You can do it from a terminal within Xorg, just not from the naked command line without Xorg started. It also will not sleep by closing the lid. I included a sudo config that allows you to run /usr/sbin/zzz without a password, so what I do is I have a key combo assigned within i3wm to run "sudo /usr/sbin/zzz". It works fine this way. I go into detail when it comes to setting up Xorg with i3wm. You can skip this if you want, but if you've never used a tiling window manager, it will handle screen real estate very efficiently on a laptop with a 12.5-inch screen and a touchpad. First, download the amd64 image for 11.1-RELEASE and flash it to a USB pen drive. For the Unices, use this: # dd if=FreeBSD-11.1-RELEASE-amd64-memstick.img of=/dev/da0 bs=1M conv=sync Obviously, you'll change /dev/da0 to whatever the USB pen drive is assigned. Plug it in, check dmesg. Leave it plugged in, restart the laptop. When prompted, tap Enter to halt the boot process, then F12 to select a bootable device. Choose the USB drive. I won't go through the actual install process, but it is pretty damn easy so just look at a guide or two and you'll be fine. If you can install Debian, you can install FreeBSD. I will, however, recommend ZFS if you have over 4GB of RAM (my particular variant of the X240 has 8GB of RAM, so yours should have at least 4GB), along with an encrypted disk, and an encrypted SWAP partition. When prompted to add an additional user, and you get to the question where it asks for additional groups, please make sure you add the user to "wheel". The rest should be self-explanatory during the install. Now for the good shit. You just booted into a fresh FreeBSD install. Now what? Well, time to fire up vi and open some config files... CNN Article about CDROM.com and FreeBSD, from 1999 (https://www.cnn.com/TECH/computing/9904/08/cdrom.idg/index.html) Walnut Creek CDROM sells a lot of CD-ROMs, but it gives away even more data. Specifically, anyone who has Internet access is free to log into wcarchive (ftp.cdrom.com) and start downloading bits. Even with a good Internet connection, however, you should expect to be at it for a while. At the present time, wcarchive resides on half a terabyte (500 GB) of RAID 5-disk storage. Even if your 56-Kbps modem can deliver seven kilobytes per second, downloading the complete archive would take you 70 million seconds. Even then, some of the files would be more than two years out of date, so a bit of "back and fill" would be needed. Of course, nobody uses wcarchive that way. Instead, they just drop in when they need the odd file or two. The FTP server is very accommodating; 3,600 simultaneous download sessions is the current limit and an upgrade to 10,000 sessions is in the works. This translates to about 800 GB per day of downloads. Bob Bruce (Walnut Creek's founder) says he's thinking about issuing a press release when they reach a terabyte a day. But 800 GB isn't all that shabby.... The hardware Because FTP archives don't do a lot of thinking, wcarchive doesn't need a massive cluster of CPUs. In fact, it gets by with a single 200-MHz P6 Pentium Pro and a measly(!) 1 GB of RAM. The I/O support, however, is fairly impressive. A six-channel Mylex RAID controller (DAC960SXI; Ultra-Wide SCSI-SCSI) is the centerpiece of the I/O subsystem. Two channels link it to the PC ("Personal Computer"!?!), via a dual-channel Adaptec card (AHA-3940AUW; PCI to Ultra-Wide SCSI). An 256-MB internal cache helps it to eliminate recurring disk accesses. Four nine-drive disk arrays provide the actual storage. The two larger arrays use 18-GB IBM drives; the two smaller arrays use 9-GB Micropolis and Quantum drives. A separate 4-GB Quantum drive is used as the "system disk." The output side is handled by a single Intel 100Base-T controller (Pro/100B PCI), which feeds into the Internet through a number of shared DS3 (45 Mbps) and OC3 (155 Mbps) circuits. A detailed description of the system is available as ftp.cdrom.com/archive-info/configuration; The software The system software is rather prosaic: a copy of FreeBSD, supplemented by home-grown FTP mirroring and server code. Because of the massive hardware support, the software "only" needs to keep the I/O going in an efficient and reliable manner. FreeBSD, the "prosaic" operating system mentioned above, merits a bit more discussion. Like Linux, FreeBSD is open source. Anyone can examine, modify, and/or redistribute the source code. And, like Linux, an active user community helps the authors to find bugs, improve documentation, and generally support the OS. Unlike Linux, FreeBSD is derived from the Berkeley Unix code that forms the foundation for most commercial Unix variants. When you use the "fast file system" (cylinder groups, long file names, symbolic links, etc.), TCP/IP networking, termcap, or even vi, you are using Berkeley Unix additions. The version of BSD underlying FreeBSD, however, is "pure" BSD; don't look for the System V modifications you see in Solaris. Instead, think of it as SunOS, brought up to date with Kerberos, modern sendmail, an updated filesystem, and more. Solid, fast, and free! One of FreeBSD's finest innovations, the Ports Collection, makes FreeBSD a delight for open source application users. The Ports Collection automates the downloading, building, and installation (including de-installation) of 2,300+ open source packages. The company Walnut Creek CDROM has been around for several years now, so you are likely to be familiar with its offerings. You may not realize, however, that it provides the major financial support for FreeBSD. The FreeBSD support has two purposes. First, it provides the company with a solid base to run wcarchive and other massive projects. Second, it ties in with the company's mission of making software (and data) economically accessible. Bob Bruce, the firm's founder, is an interesting guy: laid back and somewhat conservative in manner, but productive and innovative in practice. Here is a possibly illustrative story. When Bob started selling CD-ROMs, disc caddies were selling for $15 each. Bob thought that was rather high, so he started investigating the marketplace. A long-distance call to Japan got him Sony's fax number; a series of faxes got him in touch with the salespeople. It turned out that caddies were available, in bulk, for only a few dollars each. Bulk, in this case, meant pallet-loads of 10,000 caddies. In an act of great faith, Bob purchased a pallet of caddies, then proceeded to sell them for five dollars each. The results were everything he might have wished. Folks who bought his CD-ROMs added caddies to their orders; folks who bought piles of caddies added in a disc or two. Either way, Walnut Creek CDROM was making a name for itself. Many pallet-loads later, the company is still selling caddies, making and distributing CD-ROMs, and giving away bits. Walnut Creek CDROM is a real open-source success story; its breadth and depth of offerings is well worth a look. Beastie Bits OpenBSD adds kqueue event support to DRM, to detect device changes like HDMI cables being plugged in, and trigger randr events (https://github.com/openbsd/src/commit/b8584f4233dc11a328cd245a5843ec3d67462200) Thesis describing QUAD3, a unix-like, multi-tasking operating system for the 6502 processor (https://archive.org/details/AMultiTaskingOperatingSystemForMicrocomputers) Windows is getting chmod and chown... (https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/) Timeline: How they kept Meltdown and Spectre secret for so long (https://www.theverge.com/platform/amp/2018/1/11/16878670/meltdown-spectre-disclosure-embargo-google-microsoft-linux) bsd.network is a *BSD-themed Mastodon Instance (https://bsd.network/): Peter Hessler is administering a new Mastodon instance, running in an OpenBSD VM on top of an OpenBSD vmm hypervisor Computer-Aided Instruction on UNIX (https://virtuallyfun.com/wordpress/wp-content/uploads/2017/12/whfUb.pdf) AsiaBSDCon 2018 Travel Grant Application Now Open (https://www.freebsdfoundation.org/blog/asiabsdcon-2018-travel-grant-application-now-open/) AsiaBSDCon 2018 FreeBSD Developers Summit Call for Proposals (https://www.freebsdfoundation.org/news-and-events/call-for-papers/asiabsdcon-2018-freebsd-developers-summit-call-for-proposals/) LinuxFest Northwest 2018 Call for Proposals (https://www.freebsdfoundation.org/news-and-events/call-for-papers/linuxfest-northwest-2018-call-for-proposals/) Feedback/Questions Jason - Dont break my ports (http://dpaste.com/05PRNG2) Wilyarti - show content (http://dpaste.com/1BG8GZW) https://clinetworking.wordpress.com/2017/12/08/data-de-duplication-file-diff-ing-and-s3-style-object-storage-using-digital-ocean-spaces Scott - Your show is Perfect! (http://dpaste.com/0KER8YE#wrap) Ken - Community Culture (http://dpaste.com/0WT8285#wrap)

BSD Now
190: The Moore You Know

BSD Now

Play Episode Listen Later Apr 19, 2017 130:59


This week, we look forward with the latest OpenBSD release, look back with Dennis Ritchie's paper on the evolution of Unix Time Sharing, have an Interview with Kris This episode was brought to you by OpenBSD 6.1 RELEASED (http://undeadly.org/cgi?action=article&sid=20170411132956) Mailing list post (https://marc.info/?l=openbsd-announce&m=149191716921690&w=2') We are pleased to announce the official release of OpenBSD 6.1. This is our 42nd release. New/extended platforms: New arm64 platform, using clang(1) as the base system compiler. The loongson platform now supports systems with Loongson 3A CPU and RS780E chipset. The following platforms were retired: armish, sparc, zaurus New vmm(4)/ vmd(8) IEEE 802.11 wireless stack improvements Generic network stack improvements Installer improvements Routing daemons and other userland network improvements Security improvements dhclient(8)/ dhcpd(8)/ dhcrelay(8) improvements Assorted improvements OpenSMTPD 6.0.0 OpenSSH 7.4 LibreSSL 2.5.3 mandoc 1.14.1 *** Fuzz Testing OpenSSH (http://vegardno.blogspot.ca/2017/03/fuzzing-openssh-daemon-using-afl.html) Vegard Nossum writes a blog post explaining how to fuzz OpenSSH using AFL It starts by compiling AFL and SSH with LLVM to get extra instrumentation to make the fuzzing process better, and faster Sandboxing, PIE, and other features are disabled to increase debuggability, and to try to make breaking SSH easier Privsep is also disabled, because when AFL does make SSH crash, the child process crashing causes the parent process to exit normally, and AFL then doesn't realize that a crash has happened. A one-line patch disables the privsep feature for the purposes of testing A few other features are disabled to make testing easier (disabling replay attack protection allows the same inputs to be reused many times), and faster: the local arc4random_buf() is patched to return a buffer of zeros disabling CRC checks disabling MAC checks disabling encryption (allow the NULL cipher for everything) add a call to _AFLINIT(), to enable “deferred forkserver mode” disabling closefrom() “Skipping expensive DH/curve and key derivation operations” Then, you can finally get around to writing some test cases The steps are all described in detail In one day of testing, the author found a few NULL dereferences that have since been fixed. Maybe you can think of some other code paths through SSH that should be tested, or want to test another daemon *** Getting OpenBSD running on Raspberry Pi 3 (http://undeadly.org/cgi?action=article&sid=20170409123528) Ian Darwin writes in about his work deploying the arm64 platform and the Raspberry Pi 3 So I have this empty white birdhouse-like thing in the yard, open at the front. It was intended to house the wireless remote temperature sensor from a low-cost weather station, which had previously been mounted on a dark-colored wall of the house [...]. But when I put the sensor into the birdhouse, the signal is too weak for the weather station to receive it (the mounting post was put in place by a previous owner of our property, and is set deeply in concrete). So the next plan was to pop in a tiny OpenBSD computer with a uthum(4) temperature sensor and stream the temperature over WiFi. The Raspberry Pi computers are interesting in their own way: intending to bring low-cost computing to everybody, they take shortcuts and omit things that you'd expect on a laptop or desktop. They aren't too bright on their own: there's very little smarts in the board compared to the "BIOS" and later firmwares on conventional systems. Some of the "smarts" are only available as binary files. This was part of the reason that our favorite OS never came to the Pi Party for the original rpi, and didn't quite arrive for the rpi2. With the rpi3, though, there is enough availability that our devs were able to make it boot. Some limitations remain, though: if you want to build your own full release, you have to install the dedicated raspberrypi-firmware package from the ports tree. And, the boot disks have to have several extra files on them - this is set up on the install sets, but you should be careful not to mess with these extra files until you know what you're doing! But wait! Before you read on, please note that, as of April 1, 2017, this platform boots up but is not yet ready for prime time: there's no driver for SD/MMC but that's the only thing the hardware can level-0 boot from, so you need both the uSD card and a USB disk, at least while getting started; there is no support for the built-in WiFi (a Broadcom BCM43438 SDIO 802.11), so you have to use wired Ethernet or a USB WiFi dongle (for my project an old MSI that shows up as ural(4) seems to work fine); the HDMI driver isn't used by the kernel (if a monitor is plugged in uBoot will display its messages there), so you need to set up cu with a 3V serial cable, at least for initial setup. the ports tree isn't ready to cope with the base compiler being clang yet, so packages are "a thing of the future" But wait - there's more! The "USB disk" can be a USB thumb drive, though they're generally slower than a "real" disk. My first forays used a Kingston DTSE9, the hardy little steel-cased version of the popular DataTraveler line. I was able to do the install, and boot it, once (when I captured the dmesg output shown below). After that, it failed - the boot process hung with the ever-unpopular "scanning usb for storage devices..." message. I tried the whole thing again with a second DTSE9, and with a 32GB plastic-cased DataTraveler. Same results. After considerable wasted time, I found a post on RPI's own site which dates back to the early days of the PI 3, in which they admit that they took shortcuts in developing the firmware, and it just can't be made to work with the Kingston DataTraveler! Not having any of the "approved" devices, and not living around the corner from a computer store, I switched to a Sabrent USB dock with a 320GB Western Digital disk, and it's been rock solid. Too big and energy-hungry for the final project, but enough to show that the rpi3 can be solid with the right (solid-state) disk. And fast enough to build a few simple ports - though a lot will not build yet. I then found and installed OpenBSD onto a “PNY” brand thumb drive and found it solid - in fact I populated it by dd'ing from one of the DataTraveller drives, so they're not at fault. Check out the full article for detailed setup instructions *** Dennis M. Ritchie's Paper: The Evolution of the Unix Time Sharing System (http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf) From the abstract: This paper presents a brief history of the early development of the Unix operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system. During the past few years, the Unix operating system has come into wide use, so wide that its very name has become a trademark of Bell Laboratories. Its important characteristics have become known to many people. It has suffered much rewriting and tinkering since the first publication describing it in 1974 [1], but few fundamental changes. However, Unix was born in 1969 not 1974, and the account of its development makes a little-known and perhaps instructive story. This paper presents a technical and social history of the evolution of the system. High level document structure: Origins The PDP-7 Unix file system Process control IO Redirection The advent of the PDP-11 The first PDP-11 system Pipes High-level languages Conclusion One of the comforting things about old memories is their tendency to take on a rosy glow. The programming environment provided by the early versions of Unix seems, when described here, to be extremely harsh and primitive. I am sure that if forced back to the PDP-7 I would find it intolerably limiting and lacking in conveniences. Nevertheless, it did not seem so at the time; the memory fixes on what was good and what lasted, and on the joy of helping to create the improvements that made life better. In ten years, I hope we can look back with the same mixed impression of progress combined with continuity. Interview - Kris Moore - kris@trueos.org (mailto:kris@trueos.org) | @pcbsdkris (https://twitter.com/pcbsdkris) Director of Engineering at iXSystems FreeNAS News Roundup Compressed zfs send / receive now in FreeBSD's vendor area (https://svnweb.freebsd.org/base?view=revision&revision=316894) Andriy Gapon committed a whole lot of ZFS updates to FreeBSD's vendor area This feature takes advantage of the new compressed ARC feature, which means blocks that are compressed on disk, remain compressed in ZFS' RAM cache, to use the compressed blocks when using ZFS replication. Previously, blocks were uncompressed, sent (usually over the network), then recompressed on the other side. This is rather wasteful, and can make the process slower, not just because of the CPU time wasted decompressing/recompressing the data, but because it means more data has to be sent over the network. This caused many users to end up doing: zfs send | xz -T0 | ssh unxz | zfs recv, or similar, to compress the data before sending it over the network. With this new feature, zfs send with the new -c flag, will transmit the already compressed blocks instead. This change also adds longopts versions of all of the zfs send flags, making them easier to understand when written in shell scripts. A lot of fixes, man page updates, etc. from upstream OpenZFS Thanks to everyone who worked on these fixes and features! We'll announce when these have been committed to head for testing *** Granting privileges using the FreeBSD MAC framework (https://mysteriouscode.io/blog/granting-privileges-using-mac-framework/) The MAC (Mandatory Access Control) framework allows finer grained permissions than the standard UNIX permissions that exist in the base system FreeBSD's kernel provides quite sophisticated privilege model that extends the traditional UNIX user-and-group one. Here I'll show how to leverage it to grant access to specific privileges to group of non-root users. mac(9) allows creating pluggable modules with policies that can extend existing base system security definitions. struct macpolicyops consist of many entry points that we can use to amend the behaviour. This time, I wanted to grant a privilege to change realtime priority to a selected group. While Linux kernel lets you specify a named group, FreeBSD doesn't have such ability, hence I created this very simple policy. The privilege check can be extended using two user supplied functions: privcheck and privgrant. The first one can be used to further restrict existing privileges, i.e. you can disallow some specific priv to be used in jails, etc. The second one is used to explicitly grant extra privileges not available for the target in base configuration. The core of the macrtprio module is dead simple. I defined sysctl tree for two oids: enable (on/off switch for the policy) and gid (the GID target has to be member of), then I specified our custom version of mpoprivgrant called rtprioprivgrant. Body of my granting function is even simpler. If the policy is disabled or the privilege that is being checked is not PRIVSCHED_RTPRIO, we simply skip and return EPERM. If the user is member of the designated group we return 0 that'll allow the action – target would change realtime privileges. Another useful thing the MAC framework can be used to grant to non-root users: PortACL: The ability to bind to TCP/UDP ports less than 1024, which is usually restricted to root. Some other uses for the MAC framework are discussed in The FreeBSD Handbook (https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html) However, there are lots more, and we would really like to see more tutorials and documentation on using MAC to make more secure servers, but allowing the few specific things that normally require root access. *** The Story of the PING Program (http://ftp.arl.army.mil/~mike/ping.html) This is from the homepage of Mike Muuss: Yes, it's true! I'm the author of ping for UNIX. Ping is a little thousand-line hack that I wrote in an evening which practically everyone seems to know about. :-) I named it after the sound that a sonar makes, inspired by the whole principle of cho-location. In college I'd done a lot of modeling of sonar and radar systems, so the "Cyberspace" analogy seemed very apt. It's exactly the same paradigm applied to a new problem domain: ping uses timed IP/ICMP ECHOREQUEST and ECHOREPLY packets to probe the "distance" to the target machine. My original impetus for writing PING for 4.2a BSD UNIX came from an offhand remark in July 1983 by Dr. Dave Mills while we were attending a DARPA meeting in Norway, in which he described some work that he had done on his "Fuzzball" LSI-11 systems to measure path latency using timed ICMP Echo packets. In December of 1983 I encountered some odd behavior of the IP network at BRL. Recalling Dr. Mills' comments, I quickly coded up the PING program, which revolved around opening an ICMP style SOCKRAW AFINET Berkeley-style socket(). The code compiled just fine, but it didn't work -- there was no kernel support for raw ICMP sockets! Incensed, I coded up the kernel support and had everything working well before sunrise. Not surprisingly, Chuck Kennedy (aka "Kermit") had found and fixed the network hardware before I was able to launch my very first "ping" packet. But I've used it a few times since then. grin If I'd known then that it would be my most famous accomplishment in life, I might have worked on it another day or two and added some more options. The folks at Berkeley eagerly took back my kernel modifications and the PING source code, and it's been a standard part of Berkeley UNIX ever since. Since it's free, it has been ported to many systems since then, including Microsoft Windows95 and WindowsNT. In 1993, ten years after I wrote PING, the USENIX association presented me with a handsome scroll, pronouncing me a Joint recipient of The USENIX Association 1993 Lifetime Achievement Award presented to the Computer Systems Research Group, University of California at Berkeley 1979-1993. ``Presented to honor profound intellectual achievement and unparalleled service to our Community. At the behest of CSRG principals we hereby recognize the following individuals and organizations as CSRG participants, contributors and supporters.'' Wow! The best ping story I've ever heard was told to me at a USENIX conference, where a network administrator with an intermittent Ethernet had linked the ping program to his vocoder program, in essence writing: ping goodhost | sed -e 's/.*/ping/' | vocoder He wired the vocoder's output into his office stereo and turned up the volume as loud as he could stand. The computer sat there shouting "Ping, ping, ping..." once a second, and he wandered through the building wiggling Ethernet connectors until the sound stopped. And that's how he found the intermittent failure. FreeBSD: /usr/local/lib/libpkg.so.3: Undefined symbol "utimensat" (http://glasz.org/sheeplog/2017/02/freebsd-usrlocalliblibpkgso3-undefined-symbol-utimensat.html) The internet will tell you that, of course, 10.2 is EOL, that packages are being built for 10.3 by now and to better upgrade to the latest version of FreeBSD. While all of this is true and running the latest versions is generally good advise, in most cases it is unfeasible to do an entire OS upgrade just to be able to install a package. Points out the ABI variable being used in /usr/local/etc/pkg/repos/FreeBSD.conf Now, if you have 10.2 installed and 10.3 is the current latest FreeBSD version, this url will point to packages built for 10.3 resulting in the problem that, when running pkg upgrade pkg it'll go ahead and install the latest version of pkg build for 10.3 onto your 10.2 system. Yikes! FreeBSD 10.3 and pkgng broke the ABI by introducing new symbols, like utimensat. The solution: Have a look at the actual repo url http://pkg.FreeBSD.org/FreeBSD:10:amd64… there's repo's for each release! Instead of going through the tedious process of upgrading FreeBSD you just need to Use a repo url that fits your FreeBSD release: Update the package cache: pkg update Downgrade pkgng (in case you accidentally upgraded it already): pkg delete -f pkg pkg install -y pkg Install your package There you go. Don't fret. But upgrade your OS soon ;) Beastie Bits CPU temperature collectd report on NetBSD (https://imil.net/blog/2017/01/22/collectd_NetBSD_temperature/) Booting FreeBSD 11 with NVMe and ZFS on AMD Ryzen (https://www.servethehome.com/booting-freebsd-11-nvme-zfs-amd-ryzen/) BeagleBone Black Tor relay (https://torbsd.github.io/blog.html#busy-bbb) FreeBSD - Disable in-tree GDB by default on x86, mips, and powerpc (https://reviews.freebsd.org/rS317094) CharmBUG April Meetup (https://www.meetup.com/CharmBUG/events/238218742/) The origins of XXX as FIXME (https://www.snellman.net/blog/archive/2017-04-17-xxx-fixme/) *** Feedback/Questions Felis - L2ARC (http://dpaste.com/2APJE4E#wrap) Gabe - FreeBSD Server Install (http://dpaste.com/0BRJJ73#wrap) FEMP Script (http://dpaste.com/05EYNJ4#wrap) Scott - FreeNAS & LAGG (http://dpaste.com/1CV323G#wrap) Marko - Backups (http://dpaste.com/3486VQZ#wrap) ***

BSD Now
159: Net Scaling Privacy (Flix Style)

BSD Now

Play Episode Listen Later Sep 14, 2016 71:57


This week on BSDNow! We've got Netflix + FreeBSD news to discuss, always a crowd pleaser, that plus EuroBSDCon is just around the corner. Stick around for your place This episode was brought to you by Headlines Protecting Netflix Viewing Privacy at Scale, with FreeBSD (http://techblog.netflix.com/search/label/FreeBSD) This blog post from Netflix tells the story of how Netflix developed in-kernel TLS to speed up delivery of video via HTTPS Since the beginning of the Open Connect program we have significantly increased the efficiency of our OCAs - from delivering 8 Gbps of throughput from a single server in 2012 to over 90 Gbps from a single server in 2016. We contribute to this effort on the software side by optimizing every aspect of the software for our unique use case - in particular, focusing on the open source FreeBSD operating system and the NGINX web server that run on the OCAs. In the modern internet world, we have to focus not only on efficiency, but also security. There are many state-of-the-art security mechanisms in place at Netflix, including Transport Level Security (TLS) encryption of customer information, search queries, and other confidential data. We have always relied on pre-encoded Digital Rights Management (DRM) to secure our video streams. Over the past year, we've begun to use Secure HTTP (HTTP over TLS or HTTPS) to encrypt the transport of the video content as well. This helps protect member privacy, particularly when the network is insecure - ensuring that our members are safe from eavesdropping by anyone who might want to record their viewing habits. The goal is to ensure that your government, ISP, and wifi sniffing neighbour cannot tell which Netflix videos you are watching Netflix Open Connect serves over 125 million hours of content per day, all around the world. Given our scale, adding the overhead of TLS encryption calculations to our video stream transport had the potential to greatly reduce the efficiency of our global infrastructure. We evaluated available and applicable ciphers and decided to primarily use the Advanced Encryption Standard (AES) cipher in Galois/Counter Mode (GCM), available starting in TLS 1.2. We chose AES-GCM over the Cipher Block Chaining (CBC) method, which comes at a higher computational cost. The AES-GCM cipher algorithm encrypts and authenticates the message simultaneously - as opposed to AES-CBC, which requires an additional pass over the data to generate keyed-hash message authentication code (HMAC). CBC can still be used as a fallback for clients that cannot support the preferred method. All revisions of Open Connect Appliances also have Intel CPUs that support AES-NI, the extension to the x86 instruction set designed to improve encryption and decryption performance. We needed to determine the best implementation of AES-GCM with the AES-NI instruction set, so we investigated alternatives to OpenSSL, including BoringSSL and the Intel Intelligent Storage Acceleration Library (ISA-L). Netflix and NGINX had previously worked together to improve our HTTP client request and response time via the use of sendfile calls to perform a zero-copy data flow from storage (HDD or SSD) to network socket, keeping the data in the kernel memory address space and relieving some of the CPU burden. The Netflix team specifically added the ability to make the sendfile calls asynchronous - further reducing the data path and enabling more simultaneous connections. However, TLS functionality, which requires the data to be passed to the application layer, was incompatible with the sendfile approach. To retain the benefits of the sendfile model while adding TLS functionality, we designed a hybrid TLS scheme whereby session management stays in the application space, but the bulk encryption is inserted into the sendfile data pipeline in the kernel. This extends sendfile to support encrypting data for TLS/SSL connections. We tested the BoringSSL and ISA-L AES-GCM implementations with our sendfile improvements against a baseline of OpenSSL (with no sendfile changes), under typical Netflix traffic conditions on three different OCA hardware types. Our changes in both the BoringSSL and ISA-L test situations significantly increased both CPU utilization and bandwidth over baseline - increasing performance by up to 30%, depending on the OCA hardware version. We chose the ISA-L cipher implementation, which had slightly better results. With these improvements in place, we can continue the process of adding TLS to our video streams for clients that support it, without suffering prohibitive performance hits. If you would like more detail, check out the papers from AsiaBSDCon 2015 (https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf) and the updated one from 2016 (https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf) *** OpenBSD on HP Stream 7 (http://www.tedunangst.com/flak/post/OpenBSD-on-HP-Stream-7) Recent events have rocked the mobile computing world to its core. OpenBSD retired the zaurus port, leaving users in desperate need of a new device. And not long before that, Microsoft released the Anniversary Update to Windows 10, but with free space requirements such that it's nigh impossible to install on cheap 32GB eMMC equipped devices such as the HP Stream series, leaving users searching for a new lightweight operating system. With necessity as both mother and father, the scene is set for a truly epic pairing. OpenBSD on the HP Stream 7. The HP Stream line is a series of budget computers in a couple form factors. The Stream 11 is a fairly typical netbook. However, the Stream 7 and 8 are tablets. They look like cheap Android devices, but inside the case, they're real boys, er PCs, with Intel Atom CPUs. To install OpenBSD on such a device, we need a few parts. Obviously, the tablet itself. There's a dearth of ports on these things, but there is a micro USB port. Attaching anything useful requires an OTG “on the go” cable that creates a type A port. Attaching more than one useful thing requires a mini hub. And completing the install requires one each USB stick, keyboard, and network adapter. First, we need to prep the machine to boot from USB. Actually, before doing anything, make sure you have a full charge. It's going to be battery only from here on out. Plug everything in. Flash drive, keyboard, and network into the hub, hub into the OTG cable, cable into the port on top of the Stream. Turn on the machine while holding the volume down button. This launches a mini menu from which we can enter the BIOS. There's a little on screen keyboard in the corner, so this can be done even without a keyboard attached, but the USB keyboard should work. We need to change two settings in the boot section. First, turn off secure boot. Second, switch boot order to prefer USB. Save and exit. The first reboot reveals a confirmation screen checking that we really want to disable secure boot. We must enter a PIN and press enter. Enter the PIN shown on the screen and press enter. And we are go. Then boot up OpenBSD from the USB drive Ted then works there a number of kernel panics and device driver issues, but after disabling ACPI and IntelDRM, the device boots OpenBSD. Of course, there's no X at this point. And definitely no touch screen. And no internal networking. However, by keeping our USB hub attached, we can drive the console and access the network. At least until the battery is depleted, even if we have no way of knowing how long that will be since we disabled all the ACPI devices, which also means no suspend or resume. With some xorg.conf hacking, he did get Xorg working *** DragonflyBSD steps towards base LibreSSL (http://lists.dragonflybsd.org/pipermail/commits/2016-September/624493.html) Project: DragonFlyBSD / Switch base to use private LibreSSL libraries (http://freshbsd.org/commit/dfbsd/304ca408000cd34559ef5319b4b5a6766d6eb35b) DragonFly BSD adopts uses of LibreSSL (http://undeadly.org/cgi?action=article&sid=20160911231651) The number of projects beginning to switch over to LibreSSL is growing and it appears we can now throw DragonFly into that camp. Following something that sounds vaguely familiar (Allan!) DFLY is now creating “private” LibreSSL libraries which are only linked against by base system binaries. For the moment OpenSSL is still built, primarily so that various ports and 3rd party apps can continue to function as before. A NO_OPENSSL option has also been added, but doesn't really do much (yet), since it'll still build and install headers / libraries even if set. *** OpenBSD g2k16 Hackathon g2k16 Hackathon Report: Antoine Jacoutot on Binary Patches (http://undeadly.org/cgi?action=article&sid=20160911012316) g2k16 Hackathon Report: Matthieu Herrb on xenodm (http://undeadly.org/cgi?action=article&sid=20160911231712) g2k16 Hackathon Report: Vincent Gross on iked(8), armv7 and sys/netinet[6] (http://undeadly.org/cgi?action=article&sid=20160911000337) g2k16 Hackathon Report: Florian Obser on httpd, networking, acme-client, and more (http://undeadly.org/cgi?action=article&sid=20160911000052) g2k16 Hackathon Report: Jasper Lievisse Adriaanse on ddb(4) and more (http://undeadly.org/cgi?action=article&sid=20160909012520) g2k16 Hackathon Report: Christian Weisgerber on gettext progress, RTC work, removing kernel cruft (http://undeadly.org/cgi?action=article&sid=20160908002430) g2k16 Hackathon Report: Brent Cook on Chromebooks, crypto, and more (http://undeadly.org/cgi?action=article&sid=20160907131655) g2k16 Hackathon Report: Ted Unangst on doas, signify, code removal (http://undeadly.org/cgi?action=article&sid=20160906230610) g2k16 Hackathon Report: Marc Espie on package signing evolution (http://undeadly.org/cgi?action=article&sid=20160905235911) g2k16 Hackathon Report: Adam Wolk on ports, wireless drivers and more (http://undeadly.org/cgi?action=article&sid=20160906004915) g2k16 Hackathon Report: Mike Larkin on vmm + vmd progress (http://undeadly.org/cgi?action=article&sid=20160905134009&mode=expanded) *** News Roundup OpenBSD (with encrypted softraid) on the Chromebook Pixel (https://jcs.org/notaweblog/2016/08/26/openbsd_chromebook/) Looking for a Laptop to make your OpenBSD road-warrior? If so, we have a great blog tutorial on getting OpenBSD setup on the Chromebook Pixel with encrypted softraid! Author Joshua Stein gives us a very verbose look at how to install and dial-in the laptop perfectly. But first for those wondering about the hardware in the pixel: The Chromebook Pixel LS (2015) has an Intel Core i7 processor (Broadwell) at 2.4Ghz, 16Gb of RAM, a 2560x1700 400-nit IPS screen (239ppi), and Intel 802.11ac wireless. It has a Kingston 64Gib flash chip, of which about 54Gib can be used by OpenBSD when dual-booting with a 1Gb Chrome OS partition. Due to this being a chromebook with seaBIOS, some manual key-press trickery will be required to initially get the OpenBSD Installer up and running. From here you'll want to pay special close attention to the disk partitioning. In particular Joshua will show us how to shrink the existing encrypted /home that ChromeOS uses, keeping the dual-boot intact. This will become important if you ever plan on updating the device. From here, we move back to a more traditional setup, but with the added bonus of doing a soft-raid setup. But the fun isn't over yet! If you want to make OpenBSD the default boot, that'll require cracking the lid on the device and removing a special pink write-protect screw. And of course if you want to remove the default splash-screen image, Joshua has you covered as well, although some flashrom magic will be required. At this point you are nearly done. Final details on enabling specific bits of hardware are discussed. Most things work, apart from Audio and Bluetooth as of right now. *** doas mastery (http://www.tedunangst.com/flak/post/doas-mastery) “doas” mastery - Paging MWL! Our buddy Ted Unangst has written up a great ‘mastery' guide of the doas command, which can come in handy if you are among the un-initiated in doas land. UNIX systems have two classes of user, the super user and regular users. The super user is super, and everybody else is not. This concentration of power keeps things simple, but also means that often too much power is granted. Usually we only need super user powers to perform one task. We would rather not have such power all the time. Think of the responsibility that would entail! Like the sudo command, doas allows for subdivision of super user privileges, granting them only for specific tasks. He starts with the basic doas.conf setup, which starts with an empty config file The doas config is much like a pf ruleset, the default is to block everything > We add the root rule second because doas evaluates rules in a last match manner. root is in the wheel group, so the first rule will match, and then we need to override that with a second rule. Remember to always start with general rules, then make them more specific. *** iXsystems iXsystems to host MeetBSD (https://www.ixsystems.com/blog/ixsystems-host-meetbsd-california-2016-uc-berkeley/) FreeBSD Foundation Welcomes New Board Members New Board Members (https://www.freebsdfoundation.org/blog/freebsd-foundation-welcomes-new-board-members/) The FreeBSD Foundation has added two new board members Interview with Kylie Liang (https://www.freebsdfoundation.org/blog/new-board-member-interview-kylie-liang/) Kylie will focus on representing FreeBSD at conferences and businesses in China I live in China. There, I can act as a bridge between Chinese companies and the FreeBSD community to help drive FreeBSD adoption. Through my leadership role in the FreeBSD Foundation, I will help promote FreeBSD in China and also represent the Foundation at conferences and events in my region. Kylie leads the team the ensures FreeBSD runs well on Hyper-V and Azure, including providing commercial support for customers who run FreeBSD or FreeBSD based appliances on the Azure Cloud I joined Microsoft and started to lead the project called FreeBSD Integration Service to get FreeBSD running well on Hyper-V and Azure. To promote our work and to understand the FreeBSD ecosystem, I started to participate in FreeBSD events where I was inspired by this technical community. Interview with Philip Paeps (https://www.freebsdfoundation.org/blog/new-board-member-interview-philip-paeps/) Philip started with FreeBSD in the early 2000s and got his commit bit in 2004 The patches I submitted to make ACPI and input devices work on that laptop led to a src commit bit in 2004. While I haven't worked on ACPI or input devices since, I have been contributing to different areas of the kernel. Taking up maintainership of some ports I cared about also got me a ports commit bit after some time. Philip will continue to help run EuroBSDCon, but is also spreading the word about FreeBSD in India and Africa Primarily, I think I can be useful! I attend (and organize) a number of conferences around the world every year, particularly in regions that have a mostly “stealthy” FreeBSD community. While I clearly don't need to be on the FreeBSD Foundation board to advocate for FreeBSD, joining as a director will provide an additional asset when working in areas of the world where organizational affiliations are meaningful. Philip has also developed network drivers and various other bits and pieces, and has extensive experience working with and for hardware vendors and appliance vendors Despite intending to eventually contribute their code to the FreeBSD Project as open source, many hardware vendors still find it very difficult to engage directly with the FreeBSD development community. The Foundation helps bridge that gap and helps facilitate collaboration between commercial vendors and the FreeBSD community. I hope to make FreeBSD more visible in regions of the world where it is historically under-represented. I expect I will be attending even more conferences and getting myself invited to even more organizations. more, less, and a story of typical Unix fossilization (https://utcc.utoronto.ca/~cks/space/blog/unix/MoreAndUnixFossilization) Chris Siebenmann from the University of Toronto digs into the history of the difference between ‘less' and ‘more' In the beginning, by which we mean V7, Unix didn't have a pager at all. That was okay; Unix wasn't very visual in those days, partly because it was still sort of the era of the hard copy terminal. Then along came Berkeley and BSD. People at Berkeley were into CRT terminals, and so BSD Unix gave us things like vi and the first pager program, more (which showed up quite early, in 3BSD, although this isn't as early as vi, which appears in 2BSD). Calling a pager more is a little bit odd but it's a Unix type of name and from the beginning more prompted you with '--More--' at the bottom of the screen. All of the Unix vendors that based their work on BSD Unix (like Sun and DEC) naturally shipped versions of more along with the rest of the BSD programs, and so more spread around the BSD side of things. However, more was by no means the best pager ever; as you might expect, it was actually a bit primitive and lacking in features. So fairly early on Mark Nudelman wrote a pager with somewhat more features and it wound up being called less as somewhat of a joke. In a sane world, Unix vendors would have either replaced their version of more with the clearly superior less or at least updated their version of more to the 4.3 BSD version. Maybe less wouldn't have replaced more immediately, but certainly over say the next five years, when it kept on being better and most people kept preferring it when they had a choice.” + “This entire history has led to a series of vaguely absurd outcomes on various modern Unixes. On Solaris derivatives more is of course the traditional version with source code that can probably trace itself all the way back to 3BSD, carefully updated to SUS compliance. Solaris would never dream of changing what more is, not even if the replacement is better. Why, it might disturb someone. Oddly, FreeBSD has done the most sensible thing; they've outright replaced more with less. There is a /usr/bin/more but it's the same binary as less and as you can see the more manpage is just the less manpage. OpenBSD has done the same thing but has a specific manpage for more instead of just giving you the less manpage. So, now you can see why I say that less is more, or more, or both, at several levels. less is certainly more than more, and sometimes less literally is more (or rather more is less, to put it the right way around). Beastie Bits PC-BSD listed in the top 8 'best' alternatives to Windows 10 (http://www.computerworlduk.com/galleries/operating-systems/-free-alternatives-windows-10-3639433/) Creating a quick DNS server with a Rapsberry Pi2 and FreeBSD 11.0-RC1 (http://bsdimp.blogspot.co.uk/2016/08/creating-quick-dns-server-with.html) Dual Boot OpenBSD and Linux + UEFI (https://bsdlaptops.wordpress.com/2016/03/07/vaio-pro-11-part-2/) DesktopBSD 2.0 various versions available (Gnome, Lumina, KDE, LXDE) (http://desktopbsd.boards.net/board/10/announcements) FreeBSD gets new ZFS features including: Compressed ARC (https://svnweb.freebsd.org/base?view=revision&revision=305323) and ZFS Allocation Throttle (https://svnweb.freebsd.org/base?view=revision&revision=305331) One Floppy NetBSD Distribution (https://github.com/user340/fdgw2) A Compendium of BUGs (https://github.com/q5sys/BUGtracker) Feedback/Questions Galahad - OpenBSD X setup (http://pastebin.com/b7W6NHqs) Tang - Subtitles (http://pastebin.com/P4MUs3Pa) Ivan - Zpool Options (http://pastebin.com/LQ8yTp0G) Brad - Replication Issue (http://pastebin.com/XTK5gXMU) MJ - HBA (http://pastebin.com/TdYTMSj9) ***

软件那些事儿
32. BSD-版权战争中重获自由的Unix

软件那些事儿

Play Episode Listen Later Aug 9, 2016 16:39


bsd unix
软件那些事儿
32. BSD-版权战争中重获自由的Unix

软件那些事儿

Play Episode Listen Later Aug 9, 2016 16:39


bsd unix
软件那些事儿
32. BSD-版权战争中重获自由的Unix

软件那些事儿

Play Episode Listen Later Aug 9, 2016 16:39


bsd unix
软件那些事儿
32. BSD-版权战争中重获自由的Unix

软件那些事儿

Play Episode Listen Later Aug 9, 2016 16:39


bsd unix
BSD Now
149: The bhyve has been disturbed, and a wild Dexter appears!

BSD Now

Play Episode Listen Later Jul 6, 2016 140:43


Today on the show, we are going to be chatting with Michael Dexter about a variety of topics, but of course including bhyve! That plus This episode was brought to you by Headlines NetBSD Introduction (https://bsdmag.org/netbsd_intr/) We start off today's episode with a great new NetBSD article! Siju Oommen George has written an article for BSDMag, which provides a great overview of NetBSD's beginnings and what it is today. Of course you can't start an article about NetBSD without mentioning where the name came from: “The four founders of the NetBSD project, Chris Demetriou, Theo de Raadt, Adam Glass, and Charles Hannum, felt that a more open development model would benefit the project: one centered on portable, clean and correct code. They aimed to produce a unified, multi-platform, production-quality, BSD-based operating system. The name “NetBSD” was suggested by de Raadt, based on the importance and growth of networks, such as the Internet at that time, the distributed and collaborative nature of its development.” From there NetBSD has expanded, and keeping in line with its motto “Of course it runs NetBSD” it has grown to over 57 hardware platforms, including “IA-32, Alpha, PowerPC,SPARC, Raspberry pi 2, SPARC64 and Zaurus” From there topics such as pkgsrc, SMP, embedded and of course virtualization are all covered, which gives the reader a good overview of what to expect in the modern NetBSD today. Lastly, in addition to mentioning some of the vendors using NetBSD in a variety of ways, including Point-Of-Sale systems, routers and thin-clients, you may not have known about the research teams which deploy NetBSD: NASA Lewis Research Center – Satellite Networks and Architectures Branch use NetBSD almost exclusively in their investigation of TCP for use in satellite networks. KAME project – A research group for implementing IPv6, IPsec and other recent TCP/IP related technologies into BSD UNIX kernels, under BSD license. NEC Europe Ltd. established the Network Laboratories in Heidelberg, Germany in 1997, as NEC's third research facility in Europe. The Heidelberg labs focus on software-oriented research and development for the next generation Internet. SAMS-II Project – Space Acceleration Measurement System II. NASA will be measuring the microgravity environment on the International Space Station using a distributed system, consisting of NetBSD.“ My condolences, you're now the maintainer of a popular open source project (https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) A presentation from a Wordpress conference, about what it is like to be the maintainer of a popular open source project The presentation covers the basics: Open Source is more than just the license, it is about community and involvement The difference between Maintainers and Contributors It covers some of the reasons people do not open up their code, and other common problems people run into: “I'm embarrassed by my code” (Hint: so is everyone else, post it anyway, it is the best way to learn) “I'm discouraged that I can't finish releases on time” “I'm overwhelmed by the PR backlog” “I'm frustrated when issues turn into flamewars” “I'm overcommitted on my open source involvement” “I feel all alone” Each of those points is met with advice and possible solutions So, there you have it. Open up your code, or join an existing project and help maintain it *** FreeBSD Committer Allan Jude Discusses the Advantages of FreeBSD and His Role in Keeping Millions of Servers Running (http://www.hostingadvice.com/blog/freebsd-project-under-the-hood/) An interesting twist on our normal news-stories today, we have an article featuring our very own Allan Jude, talking about why FreeBSD and the advantages of working on an open-source project. “When Allan started his own company hosting websites for video streaming, FreeBSD was the only operating system he had previously used with other hosts. Based on his experience and comfort with it, he trusted the system with the future of his budding business.A decade later, the former-SysAdmin went to a conference focused on the open-source operating system, where he ran into some of the folks on its documentation team. “They inspired me,” he told our team in a recent chat. He began writing documentation but soon wanted to contribute improvements beyond the docs.Today, Allan sits as a FreeBSD Project Committer. It's rare that you get to chat with someone involved with a massive-scale open-source project like this — rare and awesome.” From there Allan goes into some of the reasons “Why” FreeBSD, starting with Code Organization being well-maintained and documented: “The FreeBSD Project functions like an extremely well-organized world all its own. Allan explained the environment: “There's a documentation page that explains how the file system's laid out and everything has a place and it always goes in that place.”” + In addition, Allan gives us some insight into his work to bring Boot-Environments to the loader, and other reasons why FreeBSD “just makes sense” + In summary Allan wraps it up quite nicely: “An important take-away is that you don't have to be a major developer with tons of experience to make a difference in the project,” Allan said — and the difference that devs like Allan are making is incredible. If you too want to submit the commit that contributes to the project relied on by millions of web servers, there are plenty of ways to get involved! We're especially talking to SysAdmins here, as Allan noted that they are the main users of FreeBSD. “Having more SysAdmins involved in the actual build of the system means we can offer the tools they're looking for — designed the way a SysAdmin would want them designed, not necessarily the way a developer would think makes the most sense” A guide to saving electricity and time with poudriere and bhyve (http://justinholcomb.me/blog/2016/07/03/poudriere-in-bhyve-and-bare-metal.html) “This article goes over running poudriere to built packages for a Raspberry Pi with the interesting twist of running it both as a bhyve guest and then switching to running on bare metal via Fiber Channel via ctld by sharing the same ZFS volume.” “Firstly, poudriere can build packages for different architectures such as ARM. This can save hours of build time compared to building ports from said ARM device.” “Secondly, let's say a person has an always-on device (NAS) running FreeBSD. To save power, this device has a CPU with a low clock-rate and low core count. This low clock-rate and core count is great for saving power but terrible for processor intensive application such as poudriere. Let's say a person also has another physical server with fast processors and a high CPU count but draws nearly twice the power and a fan noise to match.” “To get the best of both worlds, the goal is to build the packages on the fast physical server, power it down, and then start the same ZFS volume in a bhyve environment to serve packages from the always-on device.” The tutorial walks through setting up ‘ahost', the always on machine, ‘fhost' the fast but noisy build machine, and a raspberry pi It also includes creating a zvol, configuring iSCSI over fibre channel and exporting the zvol, booting an iSCSI volume in bhyve, plus installing and setting up poudriere This it configures booting over fibre channel, and cross-building armv6 (raspberry pi) packages on the fast build machine Then the fast machine is shut down, and the zvol is booted in bhyve on the NAS Everything you need to know to make a hybrid physical/virtual machine The same setup could also work to run the same bhyve VM from either ahost or fhost bhyve does not yet support live migration, but when it does, having common network storage like the zvol will be an important part of that *** Interview - Michael Dexter - editor@callfortesting.org (mailto:editor@callfortesting.org) / @michaeldexter (https://twitter.com/michaeldexter) The RoloDexter *** iXSystems Children's Minnesota Star Studio Chooses iXsystems' TrueNAS Storage (https://www.youtube.com/watch?v=FFbdQ_05e-0) *** News Roundup FreeBSD Foundation June 2016 Update (https://www.freebsdfoundation.org/wp-content/uploads/2016/06/FreeBSD-Foundation-June-2016-Update.pdf) The FreeBSD Foundation's June newsletter is out Make sure you submit the FreeBSD Community Survey (https://www.surveymonkey.com/r/freebsd2016) by July 7th: In addition to the opening message from the executive director of the foundation, the update includes details to sponsored work on the FreeBSD VM system, reports from a number of conferences the Foundation attended, including BSDCan The results of the foundation's yearly board meeting People the foundation recognized for their contributions to FreeBSD at BSDCan And an introduction to their new “Getting Started with FreeBSD” project *** [How-To] Building the FreeBSD OS from scratch (http://www.all-nettools.com/forum/showthread.php?34422-Building-the-FreeBSD-OS-from-scratch) A tutorial over at the All-NetTools.com forums that walks through building FreeBSD from scratch I am not sure why anyone would want to build Xorg from source, but you can It covers everything in quite a bit of detail, from the installation process through adding Xorg and a window manager from source It also includes tweaking some device node permissions for easier operation as a non-root user, and configuring the firewall *** Window Systems Should Be Transparent (http://doc.cat-v.org/bell_labs/transparent_wsys/) + Rob Pike of AT&T Labs writes about why Window Systems should be transparent This is an old paper (undated, but I think from the late 80s), but may contain some timeless insights “UNIX window systems are unsatisfactory. Because they are cumbersome and complicated, they are unsuitable companions for an operating system that is appreciated for its technical elegance” “A good interface should clarify the view, not obscure it” “Mux is one window system that is popular and therefore worth studying as an example of good design. (It is not commercially important because it runs only on obsolete hardware.) This paper uses mux as a case study to illustrate some principles that can help keep a user interface simple, comfortable, and unobtrusive. When designing their products, the purveyors of commercial window systems should keep these principles in mind.” There are not many commercial window systems anymore, but “open source” was not really a big thing when this paper was written *** Roger Faulkner, of Solaris fame passed away (http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/12877) “RIP Roger Faulkner: creator of the One and True /proc, slayer of the M-to-N threading model -- and the godfather of post-AT&T Unix” @bcantrill: Another great Roger Faulkner story (https://twitter.com/bcantrill/status/750442169807171584) The story of how pgrep -w saved a monitor -- if not a life (https://news.ycombinator.com/item?id=4306515) @bcantrill: With Roger Faulkner, Tim led an engineering coup inside Sun that saved Solaris circa 2.5 (https://twitter.com/bcantrill/status/750442169807171584) *** Beastie Bits: Developer Ed Maste is requesting information from those who are users of libvgl. (https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084843.html) HEADS UP: DragonFly 4.5 world reneeds rebuilding (http://lists.dragonflybsd.org/pipermail/users/2016-June/249748.html) Chris Buechler is leaving the pfSense project, the entire community thanks you for your many years of service (https://blog.pfsense.org/?p=2095) GhostBSD 10.3-BETA1 now available (http://ghostbsd.org/10.3_BETA1) DragonFlyBSD adds nvmectl (http://lists.dragonflybsd.org/pipermail/commits/2016-June/500671.html) OPNsense 16.1.18 released (https://opnsense.org/opnsense-16-1-18-released/) bhyve_graphics hit CURRENT (https://svnweb.freebsd.org/base?view=revision&revision=302332) BUG Update FreeBSD Central Twitter account looking for a new owner (https://twitter.com/freebsdcentral/status/750053703420350465) NYCBUG meeting : Meet the Smallest BSDs: RetroBSD and LiteBSD, Brian Callahan (http://lists.nycbug.org/pipermail/talk/2016-July/016732.html) NYCBUG install fest @ HOPE (http://lists.nycbug.org/pipermail/talk/2016-June/016694.html) SemiBUG is looking for presentations for September and beyond (http://lists.nycbug.org/pipermail/semibug/2016-June/000107.html) Caleb Cooper is giving a talk on Crytpo at KnoxBUG on July 26th (http://knoxbug.org/content/2016-07-26) Feedback/Questions Leif - ZFS xfer (http://pastebin.com/vvASr64P) Zach - Python3 (http://pastebin.com/SznQHq7n) Dave - Versioning (http://pastebin.com/qkpjKEr0) David - Encrypted Disk Images (http://pastebin.com/yr7BUmv2) Eli - TLF in all the wrong places (http://pastebin.com/xby81NvC) ***

BSD Now
142: Diving for BSD Perls

BSD Now

Play Episode Listen Later May 18, 2016 96:51


This week on the show, we have all the latest news and stories! Plus an interview with BSD developer Alfred Perlstein, that you This episode was brought to you by Headlines The May issus of BSDMag is now out (https://bsdmag.org/download/reusing_openbsd/) GhostBSD Reusing OpenBSD's arc4random in multi-threaded user space programs Securing VPN's with GRE / Strongswan Installing XFCE 4.12 on NetBSD 7 Interview with Fernando Rodriguez, the co-founder of KeepCoding *** A rundown of the FPTW^XEXT.1 security reqiurement for General Purpose Operating Systems by the NSA (http://blog.acumensecurity.net/fpt_wx_ext-1-a-rundown/) NIST/NSA Validation Scheme Report (https://www.commoncriteriaportal.org/files/ppfiles/pp_os_v4.1-vr.pdf) The SFR or Security Functional Requirement requires that; "The OS shall prevent allocation of any memory region with both write and execute permissions except for [assignment: list of exceptions]." While nearly all operating systems currently support the use of the NX bit, or the equivalent on processors such as SPARC and ARM, and will correctly mark the stack as non-executable, the fact remains that this in and of itself is deemed insufficient by NIST and NSA. OpenBSD 5.8, FreeBSD, Solaris, RHEL, and most other Linux distro have failed. HardenedBSD passes all three tests out of the box. NetBSD will do so with a single sysctl tweak. Since they are using the PaX model, anything else using PaX, such as a grsecurity-enabled Linux distribution pass these assurance activities as well. OpenBSD 5.9 does not allow memory mapping due to W^X being enforced by the kernel, however the kernel will panic if there are any attempts to create such mappings. *** DistroWatch reviews new features in FreeBSD 10.3 (https://distrowatch.com/weekly.php?issue=20160516#freebsd) DistroWatch did a review of FreeBSD 10.3 They ran into a few problems, but hopefully those can be fixed An issue with beadm setting the canmount property incorrectly causing the ZFS BE menu to not work as expected should be resolved in the next version, thanks to a patch from kmoore The limitations of the Linux 64 support are what they are, CentOS 6 is still fairly popular with enterprise software, but hopefully some folks are interested in working on bringing the syscall emulation forward In a third issue, the reviewer seemed to have issues SSHing from inside the jail. This likely has to do with how they got a console in the jail. I remember having problems with this in the past, something about a secure console. *** BSD Unix: Power to the people, from the code (https://www.salon.com/2000/05/16/chapter_2_part_one/) Salon.com has a very long article, chronicling much of the history behind BSD UNIX. It starts with detailing the humble origins of BSD, starting with Bill Joy in the mid-70's, and then goes through details on how it rapidly grew, and the influence that the University of Berkeley had on open-source. “But too much focus on Joy, a favorite target for business magazine hagiography, obscures the larger picture. Berkeley's most important contribution was not software; it was the way Berkeley created software. At Berkeley, a small core group — never more than four people at any one time — coordinated the contributions of an ever-growing network of far-flung, mostly volunteer programmers into progressive releases of steadily improving software. In so doing, they codified a template for what is now referred to as the “open-source software development methodology.” Put more simply, the Berkeley hackers set up a system for creating free software.” The article goes on to talk about some of the back and forth between Linux and BSD, and why Linux has captured more of the market in recent years, but BSD is far from throwing in the towel. “BSD patriots argue that the battle is far from over, that BSD is technically superior and will therefore win in the end. That's for the future to determine. What's indisputable is BSD's contribution in the past. Even if, by 1975, Berkeley's Free Speech Movement was a relic belonging to a fast-fading generation, on the fourth floor of Evans Hall, where Joy shared an office, the free-software movement was just beginning.” An excellent article (If a bit long), but well worth your time to understand the origins of what we consider modern day BSD, and how the University of Berkley helped shape it. *** iXsystems (http://ixsystems.com) #ServerEnvy: It's over 10,000 Terabytes! (https://www.ixsystems.com/blog/serverenvy-10000-terabytes/) *** Interview - Alfred Perlstein - alfred@freebsd.org (mailto:alfred@freebsd.org) / @splbio (https://twitter.com/splbio) Using BSD for projects *** News Roundup .NET framework ported to NetBSD (https://github.com/dotnet/coreclr/pull/4504/files) This pull request adds basic support for the .NET framework on NetBSD 7.x amd64 It includes documentation on how to get the .NET framework installed It uses pkgsrc to bootstrap the required tools pkgsrc-wip is used to get the actual .NET framework, as porting is still in progress The .NET Core-CLR is now available for: FreeBSD, Linux, NetBSD, and OS X *** OpenBSD SROP mitigation – call for testing (https://marc.info/?l=openbsd-tech&m=146281531025185&w=2) A new technique for exploiting flaws in applications and operating systems has been developed, called SROP “we describe Sigreturn Oriented Programming (SROP), a novel technique for exploits and backdoors in UNIX-like systems. Like return-oriented programming (ROP), sigreturn oriented programming constructs what is known as a ‘weird machine' that can be programmed by attackers to change the behavior of a process. To program the machine, attackers set up fake signal frames and initiate returns from signals that the kernel never really delivered. This is possible, because UNIX stores signal frames on the process' stack.” “Sigreturn oriented programming is interesting for attackers, OS developers and academics. For attackers, the technique is very versatile, with pre-conditions that are different from those of existing exploitation techniques like ROP. Moreover, unlike ROP, sigreturn oriented programming programs are portable. For OS developers, the technique presents a problem that has been present in one of the two main operating system families from its inception, while the fixes (which we also present) are non-trivial. From a more academic viewpoint, it is also interesting because we show that sigreturn oriented programming is Turing complete.” Paper describing SROP (http://www.cs.vu.nl/~herbertb/papers/srop_sp14.pdf) OpenBSD has developed a mitigation against SROP “Utilizing a trick from kbind(2), the kernel now only accepts signal returns from the PC address of the sigreturn(2) syscall in the signal trampoline. Since the signal trampoline page is randomized placed per process, it is only known by directly returning from a signal handler.” “As well, the sigcontext provided to sigreturn(2) now contains a magic cookie constructed from a per-process cookie XOR'd against the address of the signal context.” This is just a draft of the patch, not yet considered production quality *** Running Tor in a NetBSD rump unikernel (https://github.com/supradix/rumprun-packages/tree/33d9cc3a65a39e32b4bc8034c151a5d7e0b89f66/tor) We've talked about “rump” kernels before, and also Tor pretty frequently, but this new github project combines the two! Specifically, this set of Makefile and scripts will prep a system to run Tor via the Unikernel through Qemu. The script mainly describes how to do the initial setup on Linux, using iptables, but could easily be adapted to a BSD if somebody wants to do so. (Send them a pull request with the instructions!) All in all, this is a fascinating way to run a Tor node or relay, in the most minimal operating environment possible. *** An update on SSH protocol 1 ("we're most of the way towards fully deprecating SSH protocol 1" (http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-May/035069.html) Damien Miller has given us an update on the status of the “SSH protocol 1”, and the current plans to deprecate it in an upcoming version of openssh. “We've had this old protocol in various stages of deprecation for almost 10 years and it has been compile-time disabled for about a year. Downstream vendors, to their credit, have included this change in recent OS releases by shipping OpenSSH packages that disable protocol 1 by default and/or offering separate, non-default packages to enable it. This seems to have proceeded far more smoothly than even my most optimistic hopes, so this gives us greater confidence that we can complete the removal of protocol 1 soon. We want to do this partly to hasten the demise of this cryptographic trainwreck, but also because doing so removes a lot of legacy code from OpenSSH that inflates our attack surface. Having it gone will make our jobs quite a bit easier as we maintain and refactor.” The current time-line looks like removing server-size protocol 1 support this August after OpenSSH 7.4 is released, leaving client-side disabled. Then a year from now (June 2017) all protocol 1 code will be removed. Beastie Bits Last day to get your BSDNow Shirts! Order now, wear at BSDCan! (https://teespring.com/bsdnow) Move local government (Austin TX) from Microsoft Windows (incl. Office) to Linux and/or PC-BSD (https://github.com/atxhack4change/2016-project-proposals/issues/15) Plan9 boot camp is back... and already at capacity. Another opportunity may come in September (http://lists.nycbug.org/pipermail/talk/2016-May/016642.html) Smaller is better - building an openbsd based router (https://functionallyparanoid.com/2016/04/22/smaller-is-better/) Baby Unix (https://i.redditmedia.com/KAjSscL9XOUdpIEWBQF1qi3QMr7zWgeETzQM6m3B4mY.jpg?w=1024&s=e8c08a7d4c4cea0256adb69b1e7c1887) Security Update for FreeBSD (https://security.freebsd.org/advisories/FreeBSD-SA-16:19.sendmsg.asc) & Another security update for FreeBSD (https://security.freebsd.org/advisories/FreeBSD-SA-16:18.atkbd.asc) Feedback/Questions Eric - The iX experience (http://pastebin.com/ZknTuKGv) Mike - Building Ports (http://pastebin.com/M760ZmHQ) David - ZFS Backups (http://pastebin.com/Pi0AFghV) James - BSD VPS (http://pastebin.com/EQ7envez) Rich - ZFS Followup (http://pastebin.com/p0HPDisH) ***

BSD Now
123: ZFS in the trenches

BSD Now

Play Episode Listen Later Jan 6, 2016 121:02


This week on BSDNow, we will be talking shop with Josh Paetzel of FreeNAS fame, hearing about his best do's and do-nots of using ZFS in production. Also, a quick iX Systems Mission Complete (https://www.ixsystems.com/missioncomplete/) Submit your story of how you accomplished a mission with FreeBSD, FreeNAS, or iXsystems hardware, and you could win monthly prizes, and have your story featured in the FreeBSD Journal! *** FreeNAS Logo Design Contest (https://www.ixsystems.com/freenas-logo-contest/) Rules and Requirements (https://forums.freenas.org/index.php?threads/freenas-logo-design-contest.39968/) For those of you curious about Kris' new lighting here are the links to what he is using. Softbox Light Diffuser (http://smile.amazon.com/gp/product/B00OTG6474?psc=1&redirect=true&ref_=oh_aui_detailpage_o01_s00&pldnSite=1) Full Spectrum 5500K CFL Bulb (http://smile.amazon.com/gp/product/B00198U6U6?psc=1&redirect=true&ref_=oh_aui_detailpage_o06_s00) *** This episode was brought to you by Headlines A Brief look back at 2015 (http://fossforce.com/2015/12/bsd-brief-look-back-2015/) As we start the show this week, we begin with a brief look back at BSD in 2015, brought to us by Larry at FOSS force. Aside from his issue with tap-to-click on the touchpad, his PC-BSD experience has been pretty good. (Larry, if you hear this, jump on #pcbsd on FreeNode and we will lend a hand) He mentions that this really isn't his first time running BSD, apparently back in ye-olden days he got NetBSD up and running on a PowerBook G3, until an update brought that experience to abrupt ending. He gives a shout-out to the FreeBSD Foundation as being a great go-to source for wrapup on the previous year in FreeBSD land, while also mentioning the great 4.4 release of DragonFly, and some of the variants, such as RetroBSD and LiteBSD He leaves us with a tease for 2016 that work is ongoing on Twitter to port over Mopidy, a python based extensible music server *** A look forward at BSD events throughout 2016 (http://www.bsdevents.org/scheduler/) After a quick look back at 2015, now its time to start planning your 2016 schedule. The BSDEvents site has a calendar of all the upcoming conferences / shows where BSD will have a presence this year. There are quite a few items on the agenda, including non BSD specific conferences, such as SCALE / Fosdem and more. Take a look and see, you may be able to find something close your location where you can come hang out with other BSD developers. (or better yet), if a linux conference is coming to your town, think about submitting a BSD talk! Additionally, if getting BSD Certification is something on your 2016 resolutions, you can often take the test at one of these shows, avoiding the need to travel to a testing center. *** The 'Hidden' Cost of Using ZFS for Your Home NAS (http://louwrentius.com/the-hidden-cost-of-using-zfs-for-your-home-nas.html) An article was recently posted that seems to be trying to dissuade people from using ZFS for their home NAS It points out what experienced users already know, but many newcomers are not strictly aware of: Expanding a ZFS pool is not always as straightforward as you think it should be ZFS was designed to be expanded, and it handled this very well However, a ZFS pool is made up of VDEVs, and it is these VDEVs that provide the redundancy. RAID-Z VDEVs cannot be changed once they are created. You can replace each disk individually, and the VDEV will grow to its new larger size, but you cannot add additional disks to a RAID-Z VDEV At this point, your option is to add an additional VDEV, although best practises dictate that the new VDEV should use an equal number of disks, to avoid uneven performance So, if you started with a 6 disk RAID-Z2, having to add 6 more disks to grow the pool does seem excessive For the best flexibility, use mirrors. If you had used 6 disks as 3 mirrors of 2 disks each, you could then just add 2 more disks at a time. The downside is that using 2TB disks, you'd only have 6TB of usable space, versus the 8TB you would get from those disks in a RAID-Z2 This is the trade-off, mirrors give you better performance and flexibility, but less space efficiency It is important to note that the diagrams in this article make it appear as if all parity information is stored on specific drives. In ZFS parity is spread across all drives. Often times, the data written to the drive is not of a size that can evenly be split across all drives, so the data actually ends up looking like this (http://blog.delphix.com/matt/files/2014/06/RAIDZ.png) The errors as I see it in the original article are: It notes that the hidden cost of ZFS is that if you add a second RAID-Z VDEV, you will have a whole second set of parity drives. While this is a cost, it is the cost of making sure your data is safe. If you had an array with more than 12 drives, it is likely that you would to be able to withstand the failure of the larger number of drives The article does not consider the resilver time. If you did create a configuration with a very wide RAID-Z stripe, the failure of a disk would leave the pool degraded for a much longer time, leaving your pool at risk for that longer period. The article does not consider performance. Two RAID-Z2 VDEVs of 6 disks each will give much better performance than a single VDEV of 10 or 12 disks, especially when it comes to IOPS. *** ZFS Boot Enviroments now availble in the FreeBSD bootloader (https://svnweb.freebsd.org/base?view=revision&revision=293001) It's been in phabricator for a while (and PC-BSD), but the support for Boot-Environments has now landed upstream in -CURRENT This work was helped by cross-project collaboration when an IllumOS Developer, Toomas Soome, started porting the FreeBSD loader to IllumOS to replace GRUB there This gives Beastie menu the ability to look at the ZFS disk, and dynamically list boot-environments that it finds. (Much nicer than GRUB, which required a pre-written configuration file) This work was extended further, when Toomas Soome also ported the Beastie Menu to the UEFI loader (https://svnweb.freebsd.org/base?view=revision&revision=293233) which is now enabled by default for UEFI (https://svnweb.freebsd.org/base?view=revision&revision=293234) All of these changes are scheduled to be merged back in time for FreeBSD 10.3 as well. There is also a patch being worked on to support booting from ZFS in UEFI (https://reviews.freebsd.org/D4515) This is exciting times for doing neat things with ZFS on root, these plus Allans forthcoming GELI support (https://reviews.freebsd.org/D4593) will negate the necessity for GRUB on PC-BSD for example (Kris is very happy) *** Interview - Josh Paetzel - email@email (mailto:email@email) / @bsdunix4ever (https://twitter.com/bsdunix4ever) ZFS Support *** News Roundup RetroBSD being tested on ESP32 (http://retrobsd.org/viewtopic.php?f=1&t=37470) More hardware news for RetroBSD and LiteBSD I don't know much about this hardware, but there is a lot of discussion in the forum threads about it Not sure what you are supposed to accomplish with only 400kb of ram LITEBSD Brings 4.4BSD to PIC32 (https://hackaday.com/2016/01/04/litebsd-brings-4-4bsd-to-pic32/) It is interesting to see these super-small boards with only 512kb of memory, but will crypto offload support It is also interesting to see talk of 140mbps WiFi, can the processor actually handle that much traffic? BSD Unix-like OS is Resurrected for Embedded IoT Market (http://thevarguy.com/open-source-application-software-companies/bsd-unix-os-resurrected-embedded-iot-market) Related to the above stories, we also have an article about BSD making a resurgence on various Internet of things devices, which mentions both RetroBSD and LiteBSD The article mentions that this is an exciting development for embedded vars who now have an alternative licensed open-source OS to potentially use *** HardenedBSD's new Binary Updater (https://hardenedbsd.org/article/shawn-webb/2015-12-31/introducing-hardenedbsds-new-binary-updater) It looks like there is now another way to update your FreeBSD(hardened) system The post by Shawn Web, details how the new updater will work in future releases of HBSD Right now it looks fairly straight-forward, creating both the base.txz and kernel.txz, along with some data for etcupdate It includes a nice option for the kernel name in the update, allowing different kernels to be installed / updated at will Everything is cryptographically signed and verified using the base system openssl The build system is fairly simple, only requiring “sh/git/openssl” to create the binary updates Planned features also include updating of jails, and ZFS boot-environments *** Sometimes, processors need (BSD) love too (http://functionallyparanoid.com/2016/01/02/sometimes-processors-need-love-too/) We have a blog post from Brian Everly, talking about his long journey into legacy processors and the plans for the future to work on better supporting them on OpenBSD ports He begins with the story of his UNIX journey to today, and why this fostered his love for many of these old (and not so old) architectures, such as Sparc64, PPC32, i386. This journey ended up with the purchase of some legacy hardware (ebay is your friend), and the creation of a database listing the major port blockers on each platform This is the great kind of thing folks can do to step up and help a project, even as a weekend hobby it's great to run some hardware and help test / fix up issues that other developers maybe don't interact with as much anymore. *** Beastie Bits The standard MWL disclaimer (http://blather.michaelwlucas.com/archives/2510) PC-BSD 11.0-CURRENTJAN2016 Available (http://lists.pcbsd.org/pipermail/testing/2016-January/010350.html) NetBSD pkgsrc-2015Q3 statistics (http://mail-index.netbsd.org/tech-pkg/2015/12/28/msg016193.html) NetBSD pkgsrc-2015Q4 released (http://mail-index.netbsd.org/tech-pkg/2016/01/01/msg016213.html) First Reproducible builds conference in Athens (http://blog.netbsd.org/tnf/entry/reproducible_builds_conference_in_athens) The creator of the original ThinkPad design passes away (http://www.theregister.co.uk/2016/01/06/thinkpad_designer_obituary) Feedback/Questions Andrew - High Contrast (http://slexy.org/view/s213iCKLwn) John - FreeNAS followup (http://slexy.org/view/s21ClGePLP) Giorgio - Custom Install (http://slexy.org/view/s21527pkO1) Don - ZFS Slowdowns (http://slexy.org/view/s2jOlCsjkU) Fred - Dual Boot PC-BSD/Linux (http://slexy.org/view/s21uaB0FDU) ***

BSD Now
116: Arcing ZFS

BSD Now

Play Episode Listen Later Nov 18, 2015 117:46


This episode was brought to you by iX Systems Mission Complete (https://www.ixsystems.com/missioncomplete/) Submit your story of how you accomplished a mission with FreeBSD, FreeNAS, or iXsystems hardware, and you could win monthly prizes, and have your story featured in the FreeBSD Journal! Headlines How to create new binary packages in the Ports system on OpenBSD (http://functionallyparanoid.com/2015/11/06/where-do-binary-packages-come-from/) Creating a port is often a great first step you can take to get involved in your favorite BSD of choice, and (often) doesn't require any actual programming to do so. In this article we have a great walkthrough for users on creating a new ported application, and eventually binary package, on OpenBSD As mentioned in the tutorial, a good starting place is always an existing port, which can you use as a template for your new creation. Tip: Try to pick something similar, I.E. python for a python app, Qt for Qt, etc. This tutorial will first walk you through the process of creating your Makefile and related description about the new port. Once you've created the initial Makefile, there are a bunch of new “make” targets you can begin to run to try building your port, everything from “make fetch” to “make makesum” and “make package”. Using these tests you can verify that your port is correct and results in the installable package/app you wanted. *** Status update on pledge(2) (http://undeadly.org/cgi?action=article&sid=20151116152318) OpenBSD has been working very aggressively to convert much of their base system applications to using pledge(2) “Formerly Tame(2)) Theo has provided a great status update on where that stands as of right now and the numbers look like the following: Out of 600 ELF binaries, 368 of them have been updated to utilize pledge(2) in some manner This is quite a few, and includes everything from openssl, ping, sftp, grep, gzip and much more There are still a number of “pledge-able” commands waiting for conversion, such as login, sysctl, nfsd, ssh and others. He also mentions that there does exist some subset of commands which aren't viable pledge(2) candidates, such as simple things like “true”, or commands like reboot/mount or even perl itself. *** FreeBSD booting on the Onion Omega (https://onion.io/omega/) Tiny $19 MIPS SoC ($25 with dock that provides built in mini-USB Serial interface, power supply, LED lights, GPIO expansion, USB port, etc) A number of pluggable ‘expansions' are available, including: Arduino Dock (connect the Omega device to your existing Arduino components) Blue Tooth Lower Energy 10/100 Ethernet Port Relay expansion (2 relays each, can stack up to 8 expansions to control 16 relays) Servo expansion (control up to 16 PWM servos, like robotic arms or camera mounts) OLED expansion (1" monochrome 128x64 OLED display) Thermal Printer Kit (includes all wiring and other components) The device is the product of a successful Kick Starter campaign (https://www.kickstarter.com/projects/onion/onion-omega-invention-platform-for-the-internet-of/description) from March of this year Specs: Atheros AR9330 rev1 400MHZ MIPS 24K 64MB DDR2 400MHz 16MB Flash 802.11b/g/n 150Mbps Atheros Wifi + 100mbps Atheros Wired Ethernet 18 GPIO Pins USB Controller Using the freebsd-wifi-build (https://github.com/freebsd/freebsd-wifi-build/wiki) tool, I was able to build a new firmware for the device based on a profile for a similar device based on the same Atheros chip. I hope to have time to validate some of the settings and get them posted up into the wiki and get the kernel configuration committed to FreeBSD in the next week or two It is an interesting device compared to the TP-Link WDR3600's we did at BSDCan, as it has twice as much flash, leaving more room for the system image, but only half as much ram, and a slower CPU *** SSH Performance testing (https://wiki.freebsd.org/SSHPerf) There has been a discussion (https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058244.html) about the value of upkeeping the HPN (High Performance Networking) patch to OpenSSH in the base system of FreeBSD As part of this, I did some fresh benchmarks on my pair of new high end servers The remaining part to be done is testing different levels of latency By tweaking the socket buffer sizes, I was able to saturate the full 10 gigabit with netcat, iperf, etc From the tests that have been done so far, it doesn't look like even the NONE cipher can reach that level of performance because of the MAC (Message Authentication Code) It does appear that some of the auto-tuning in HPN is not worked as expected Explicitly setting -oTcpRcvBuf=7168 (KB) is enough to saturate a gigabit with 50ms RTT (round trip time) *** iXsystems iX gives an overview of FreeBSD at SeaGl 2015 (https://www.ixsystems.com/whats-new/seagl-2015/) On the FreeNAS Blog, Michael Dexter explains the ZFS Intent Log and SLOG (http://www.freenas.org/whats-new/2015/11/zfs-zil-and-slog-demystified.html) Interview - George Wilson - wilzun@gmail.com (mailto:wilzun@gmail.com) / @zfsdude (https://twitter.com/zfsdude) OpenZFS and Delphix *** News Roundup Nicholas Marriott has replaced the aging version of less(1) in OpenBSD (http://undeadly.org/cgi?action=article&sid=20151105223808) Sometimes less isn't more, it's just less In this story, we have news that the old version of less(1) in OpenBSD has now been ripped out in favor of the more modern fork from illumos founder Garrett D'Amore. In addition to being a “more” modern version, it also includes far “less” of the portability code, uses terminfo, replacing termcap and is more POSIX compliant. *** FreeBSD gets initial support for advanced SMR drives (https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058522.html) Kenneth D. Merry ken@freebsd.org has developed initial support for Host Managed, and Host Aware Shingled Magnetic Recording drives in FreeBSD, available as a patch against both -current and 10-stable “This includes support for Host Managed, Host Aware and Drive Managed SMRdrives that are either SCSI (ZBC) or ATA (ZAC) attached via a SAScontroller. This does not include support for SMR ATA drives attached viaan ATA controller. Also, I have not yet figured out how to properly detecta Host Managed ATA drive, so this code won't do that.” SMR drives have overlapping tracks, because the read head can be much smaller than the write head The drawback to this approach is that writes to the disk must take place in 256 MB “zones” that must be written from the beginning New features in the patch: A new 'camcontrol zone' command that allows displaying and managing drive zones via SCSI/ATA passthrough. A new zonectl(8) utility that uses the new DIOCZONECMD ioctl to display and manage zones via the da(4) (and later ada(4)) driver. Changes to diskinfo -v to display the zone mode of a drive. A new disk zone API, sys/sys/disk_zone.h. A new bio type, BIO_ZONE, and modifications to GEOM to support it. This new bio will allow filesystems to query zone support in a drive and manage zoned drives. Extensive modifications to the da(4) driver to handle probing SCSI and SATA behind SAS SMR drives. Additional CAM CDB building functions for zone commands. “We (Spectra Logic) are working on ZFS changes that will use this CAM and GEOM infrastructure to make ZFS play well with SMR drives. Those changes aren't yet done.” It is good to see active development in this area, especially from experts in archival storage A second patch (https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058521.html) is also offered, that improves the pass(4) passthrough interface for disks, and introduces a new camdd(8) command, a version of dd that uses the pass(4) interface, kqueue, and separate reader/writer threads for improved performance He also presents a feature wishlist that includes some interesting benchmarking features, including a ‘sink' mode, where reads from the device are just thrown away, rather than having to write then to /dev/null *** Initial implemtnation of 802.11n now in iwm(4) (http://undeadly.org/cgi?action=article&sid=20151112212739) OpenBSD laptop users rejoice! 802.11n has landed! Initially only for the iwm(4) driver, support is planned for other devices in the future Includes support for all the required (non-optional) bits to make 802.11N functional Adds a new 11n mode to ifmedia, and MCS (modulation coding scheme) that sits alongside the ieee80211_rateset structure. No support for MIMO / SGI (Short Guard Interval) or 40 MHz wide-channels, but perhaps we will see those in a future update. They are asking users for testing against a wide variety of any/all APs! *** Freebsd adds support for Bluetooth LE Security Management (https://svnweb.freebsd.org/base?view=revision&revision=290038) FreeBSD + BlueTooth, not something we discuss a lot about, but it is still under active development. The most recently added features come from Takanori Watanabe, and adds new LE Security Management. Specifically, it enables support for BLE Security Manager Protocol(SMP), and enables a userland tool to wait for the underlying HCI connection to be encrypted. *** Building OpnSense on HardenedBSD (http://0xfeedface.org/2015/11/07/hbsd-opnsense.html) Looking for a way to further Harden your router? We have a tutorial from the HardenedBSD developer, Shawn Webb, about how to build OpnSense on HBSD 10-STABLE. You'll need to first be running HBSD 10-STABLE somewhere, in this article he is using bhyve for the builder VM. The build process itself is mostly pretty straight-forward, but there are a number of different repos that all have to be checked out, so pay attention to which goes where. +In this example he does a targeted build for a Netgate RCC-VE-4860, but you can pick your particular build. *** Beastie Bits 1 BTC bounty for chromium bug! (https://github.com/gliaskos/freebsd-chromium/issues/40) DesktopBSD 2.0 M1 released (http://www.desktopbsd.net/forums/threads/desktopbsd-2-0-m1-released.806/) By implementing asynchronous pru_attach for UDP, Sepherosa Ziehau has increased connect rate by around 15K connections per second (http://lists.dragonflybsd.org/pipermail/commits/2015-October/458500.html) Stephen Bourne, known for the Bourne Shell, will be giving a talk at NYCBUG this week (http://lists.nycbug.org/pipermail/talk/2015-October/016384.html) Tor Browser 5.0.3 for OpenBSD released (http://lists.nycbug.org/pipermail/talk/2015-October/016390.html) The Tor BSD Diversity Project (https://torbsd.github.io/) aim to Increase the number of Tor relays running BSDs. We envision this happening by increasing the total number of relays, with the addition of more BSD users running relays; Make the Tor Browser available under BSD operating systems using native packaging mechanisms. Our first target is OpenBSD; Engage the broader BSD community about the Tor anonymity network and the place that BSD Unix should occupy in the privacy community at large. Screenshots from Unix People circa 2002 (https://anders.unix.se/2015/10/28/screenshots-from-developers--unix-people-2002/) Feedback/Questions Dominik - Bhyve Setup (http://slexy.org/view/s21xTyirkO) John - beadm + GELI (http://slexy.org/view/s2YVi7ULlJ) Darrall - ZFS + RAID = Problems (http://slexy.org/view/s20lRTaZSy) Hamza - Which shell? (http://slexy.org/view/s2omNWdTBU) Amenia - FreeBSD routing (http://slexy.org/view/s21Y8bPbnm) ***