Podcasts about beaglebone black

This week's EYE ON NPI is so hot, yet so cool: it's the BeagleV-Fire from BeagleBoard.org (https://www.digikey.com/en/product-highlight/b/beagleboard/beaglev-fire) featuring the Microchip PolarFire MPFS025T-FCVG484E (https://www.digikey.com/short/ddw7fmww), a powerful Processor+FPGA combo SoC that has 4x 64-bit RV64GC Application cores, as well as a 23K logic element FPGA. The BeagleV-Fire outfits this chip with a tidy number of wired up peripherals so that you can quickly get started with complex computational requirements without having to spin up a custom PCB. Historically, the BeagleBoard folks have used ARM-core chips: their famous BeagleBone Black (https://www.beagleboard.org/boards/beaglebone-black) contained a TI-built ARM Cortex A8. But recently they've been experimenting more with RISC-V. RISC-V is an 'Open ISA' - which means that you get a well defined, high speed core, that adheres the the RISC-V ISA Specifications (https://riscv.org/technical/specifications/) and use implementations thereof, without having to pay ARM a licensing fee. And recently ARM has looked to raise those fees (https://www.xda-developers.com/arm-increasing-royalty-fees/) - which has a lot more chip makers looking seriously at RISC-V as an alternative core. Now, to be honest, RISC-V is not as mature as ARM, and you're not going to have as much language and peripheral support for it. But...it's hard to argue with free! (https://en.wikipedia.org/wiki/Disruptive_innovation) We've seen RISC-V show up in two spots: mostly in smaller, low-power microcontroller cores like the ESP-C6 (https://www.espressif.com/en/products/socs/esp32-c6), but more recently, in larger boards like this one. One nice thing about having the RISC-V cores be powerful enough to run protected software like Linux is that you don't have to worry as much about compiler or learning the peripheral management because you can just run Python or use the Kernel Ioctl interfaces for hardware - the hard work has been done for you! And for this board you get a ready-to-boot Ubuntu installation. Which is awesome because sometimes you get really odd distro's for SBCs that end up eating all your time and energy to get them into a modern state. Now that you have Linux running, you can use the FPGA to make custom hardware interfaces. To do that you'll need to use Libero (https://www.microchip.com/en-us/products/fpgas-and-plds/fpga-and-soc-design-tools/fpga/libero-software-later-versions) as an FPGA IDE, and use the MAC address of the BeagleV for the floating license. But it does look like you can run libero natively on the BeagleV - there's apparently 'gateware' examples that will be published, for the M.2, SYZYGY, MIPI-CSI and Cape/GPIO hardware interface. So those design blocks can be built upon or tweaked to fit your end-needs. Like other BeagleBoards, the files for the hardware are all published so you can look at the exact schematics and layout files (https://git.beagleboard.org/beaglev-fire/beaglev-fire), there's a Linux kernel fork (https://git.beagleboard.org/beagleboard/linux), Forums (https://forum.beagleboard.org/tags/c/beaglev/15/fire), and Discord chat! (https://bbb.io/discord) If you're burning with excitement to get your hands on one of the new BeagleV-Fire SBC's from BeagleBoard.org (https://www.digikey.com/short/fz434q52), you're in luck because they are in stock right now at DigiKey for immediate shipment! Order today and they'll ship immediately so that you can get started designing your very own RISC-V-based super computation device by tomorrow afternoon.

On this episode of Remote Ruby, it's another “Five Minutes of Nothing About Our Show” as the guys discuss Police Academy and the comedian Bobcat Goldthwait, a picture of Chris's son dressed in Adidas gear, and Jason's dilemma finding Adidas gear.  Now back to our regularly scheduled podcast topics, as Jason decided he needed a new hobby, so he bought a BeagleBone Black. We'll hear how he used Elixir Nerves, Circuits, and some Ruby programming languages he's been tinkering with. The guys discuss trying mruby, DragonRuby, Pi-hole, and Zeus.  Also, after two years, devise 4.9.0 was released thanks to Carlos, and you can find out all the cool new features here, as well as the new authentication stuff in Rails 7.1. Download this episode now to find out more! [00:02:26] Jason shares a journey he's been on since his knee surgery and deciding he needed a hobby, so he ordered a BeagleBone Black, which is like a Raspberry Pi. [00:05:17] We hear how Jason used Elixir Nerves, which is a way to build Elixir apps on microcomputers and controllers, and he used a GPIO library called Circuits.[00:07:56] We hear about some Ruby programming languages that Jason has been tinkering with such as Ruby 2D which is built on top of another library from the same author for C called Simple 2D, Chris mentions a library that he used for air quality sensor on the Raspberry Pi.[00:09:16] Jason and Andrew talk about trying mruby and DragonRuby.[00:12:17] Andrew wonders if anyone has tried Pi-hole.[00:14:07] Chris talks about Big Clive, a hilarious guy on YouTube that you should check out if you want to get into soldering and circuits. [00:18:06] In case you don't know, mruby is really cool and if Jason can find a use case for it, he'll use it, and Matz is still actively working on it. The guys discuss the details between mruby and CRuby.[00:21:48] Jason's been looking at Rust and going through the tutorial has been a little scary to him, but they have a build system called Cargo and he tells us what it does. The guys bring up an old episode with Terence Lee where they talked about mruby.[00:23:49] Have you heard of Zeus, not the Greek God but a Rails preloader?  [00:24:59] Chris shares how fiddling with stuff and making things got all of them into programming, and how he's still working on his project with wiring up LED lights in his home theater. [00:26:25] A BIG shout out to Carlos for getting devise 4.9.0 released with backward compatibility and Turbo and Hotwire support after two years of not working properly with Rails 7.[00:30:42] Find out about all the new authentication stuff in Rails 7.1.Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterRuby Radar TwitterRuby for All PodcastBeagleBone BlackNervesCircuits.GPIORuby 2DSimple 2DmrubyDragonRubyPi-holeBigclivedotcom-YouTubemrubyCargoRemote Ruby Podcast-Episode 27: Joined by Terence LeeZeusdevise 4.9.0Rails 7.1 Release Notes

瀧さんをゲストにお迎えして、富士通、2回の転職、電力業界、会社辞めるの2回やめた話、アトピー、などについて話しました。 【Show Notes】 SDEM - 富士通 BeagleBone Black OSGi - Wikipedia スマートメーター - Wikipedia ピクスタ株式会社 @t_wadaさん / Twitter ENECHANGE株式会社 電気代見直しNo.1サイト「エネチェンジ」 採用情報 | ENECHANGE株式会社 ENECHANGE株式会社 の採用/求人一覧 - Wantedly アトピー性皮膚炎に効果的！？漢方薬でのアプローチとは〜インタビュー〜 | わたし漢方 配信情報はtwitter ID @shiganaiRadio で確認することができます。 フィードバックは(#しがないラジオ)でつぶやいてください！ 感想、話して欲しい話題、改善して欲しいことなどつぶやいてもらえると、今後のポッドキャストをより良いものにしていけるので、ぜひたくさんのフィードバックをお待ちしています。 【パーソナリティ】 gami@jumpei_ikegami zuckey@zuckey_17 【ゲスト】 yuyasat@yuyasat 【機材】 Blue Micro Yeti USB 2.0マイク 15374

John Boyd: LinkedIn Show Notes: 01:27 - Knocki 03:20 - The Device 06:19 - Complexity 08:44 - Software Distribution 14:01 - Allocating Memory 18:27 - Finding Hardware Hacking Libraries 22:01 - Updating and Diffing 24:06 - Migrations 26:51 - Decentralization of IoT 35:39 - Managing the Knocki Ecosystem 40:17 - Communication Standardization Resources: Malloc Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #81. My name is Charles Lowell. I'm a developer and your podcast host-in-training here at the Frontside. With me today is Elrick Ryan. Hello, Elrick. ELRICK: Hey, how are you doing Charles. Welcome back. CHARLES: Yeah, thank you. It's good to be back. Today we're going to be continuing the ongoing series that we've been doing intermittently on the Internet of Things. It's a really fascinating, almost to a person fascinated with here at the Frontside. Today, we have with us to talk about this, someone who's very, very knowledgeable on the subject, John Boyd, who I got an opportunity to talk with, I guess it was about a month ago and I wish that we had the podcast recording equipment there in the room because it was just a very, very well-versed engineer, exactly the person you want to be the CTO of your company, which is very lucky for Knocki, the company that he works for, because he is in fact the CTO there. Welcome to the show, John. Thanks for coming. JOHN: Yeah, thank you very much, Charles and I'm excited to be here. I'm excited to join the conversation this week. CHARLES: Yeah, why don't you start by what it is that you do at Knocki? Most of our audience comes from software and design and product management backgrounds. You've got a very strong hardware background. How does that play in to what you do at Knock? JOHN: Yes, certainly. As you previously mentioned, I'm CTO at a startup called Knocki, which you can mount onto any surface and turn that surface into a user interface. We're recently funded on Kickstarter so we're in the process of actually trying to develop this hardware but the central concept is any surface that you mount this on will now listen for touches and vibrations so you can say, mount it on a desk and tap three times on your desk and control your smart home around you. If you have smart speakers or TV, you can tap three times out of four times and control those devices with a really natural interioractive interface made out of anything in your home already. CHARLES: Tabletops, mirrors, I assume you've tested this on a lot of different services. JOHN: Yes, I'm sure we'll talk about that more a little bit later but the goal is to be able to turn any surface into user interface. That means if you really wild and you want to use it on the window, I recommend it. But we're thinking desks, walls, doors. It has a lot of applications for disabled and handicapped individuals. Think of a child or someone in a wheelchair that can't quite reach a light switch, if they have a Knocki mounted on the wall, they can still knock on the wall to control the lights. We feel like it adds a new level of user interface to people's lives that can be helpful. CHARLES: Definitely. Seeing the product and hearing you talk about it, I definitely got that impression. Now, the device that you actually brought into the office because you did come in and talk to us, like I said it was about a month ago but it was extremely tiny. In our explorations into the Internet of Things, we do things like control our lights from within the office. At least, we're trying to control our lights within the office. For us, we're using the standard kit. We've got Raspberry Pis that we're using, that are have access to a plug and they've got a full Linux install, just a really powerful processor and by comparison to the things that you were talking about, that's energy hog by comparison. We think of it as being very lightweight but if you're talking about making some small device, it's actually really, really wasteful of resources, so to speak. What is that transition that spectrum which you moved from these one-off hobbyist things where you're using high-powered equipment to these really custom devices? How do you make that transition? And what is the difference between the two? JOHN: Our devices are about the size of a hockey puck, which is much smaller if you can think of a Raspberry Pi. Pretty difficult to fit that inside of a hockey puck, especially when you want to start adding some sensors to detect knocks and taps on a surface. I don't hate or dislike the Raspberry Pi or BeagleBone Black or any of those really quick SBCs that can get you started with IoT. But they have -- CHARLES: Acronym alert. What is an SBC? JOHN: SBC, single board computer. It's any of those credit cards size computers. CHARLES: Okay, great. So nothing against the SBCs like BeagleBone Black or Raspberry Pi. JOHN: Exactly. It's a great way to prototype ideas and get in a proof of concept out there and there are some cases where actually, they're great choices for a full-fledged product. A lot of cases in IoT, people are more concerned with things that you carry around with you so they have to be battery powered and you need to be a little bit more conscious about energy economy. You need to be very cost-effective with your components and it doesn't make sense to buy an expensive Raspberry Pi for each unit. CHARLES: Did you actually start with a Raspberry Pi, when you were developing this product or something that's like an SBC? JOHN: I actually went straight to a microcontroller dev kit. I started with Texas Instruments' CC3200 LaunchPad. It's a little bit lower level than SBC like the Raspberry Pi. It doesn't run Linux. The firmware I started off writing as a proof of concept was still embedded C bare metal software. CHARLES: How much complexity does that add? There's just a lot of nice things about having an operating system and being able to have your compilers, I guess you have a compiler tool chain, but having being able to install big programs like interpreters so that you can run Ruby and JavaScript on there. There's just nice things like scheduling. If you've got a bunch of processes running on this device, you don't have to worry about them, saying who's going to get what processor time. I assume that you're having to deal with all of that if you're writing the firmware by hand using C, right? JOHN: That's 100% true. There's definitely some great advantages to using a little more powerful system that can run a full Linux stack or full OS. As you mentioned, the design complexity is reduced a lot because you can import other people's code and you have a full operating system to handle most of the drivers in the system. You're right. There's a lot more complexity. We have to write all of that ourselves in C. But that's the fun part about it to me. I love getting down there and writing drivers that can communicate with accelerometers and set them up. As far as scheduling goes, for getting concurrent software running on your embedded system. There are RTOS's -- real-time operating system that can provide basic scheduling. For the brave, you don't even have to use that. You can use a lot of the embedded timers inside the microcontroller itself. But to answer your question, it is a lot more complex but one of the tradeoffs to get a device that small, beautiful and also has a battery life that can last many months or a year. CHARLES: Yeah, it almost sounds like the complexity but you're not going to save yourself any time prototyping it in tools that have all those things because you're essentially going to have to be rewriting your system from scratch, because those things are just a nonstarter if you want low profile devices. JOHN: Yeah, there's definitely a lot of rework would have to be done but those SBC systems are still very useful for prototyping the cloud side. Internet of Things is hardware and internet when it comes to building out your cloud interface. CHARLES: Yeah, that's definitely true. You're running a bunch of software on this device. The software that you've written, how do you actually distribute the software because we're very used to in our world, software distribution is not a problem. That's what made the web so popular. While we were willing to deal with really crappy tools on the web for a really, really, really long time, the distribution model was just so nice. You're also having to deal without that too when you're operating in the device space. But the challenges are still there. If you've got a bug on one of these things, how do you even detect it and how do you get a fix out there? JOHN: Obviously, any software is prone to bugs. Nobody writes a perfect code the first time. If you do, I'd love to hear about it. Obviously, one of the big concepts in IoT is security and to have a secure product, we need to be able to patch bugs as they arrived. A big really important feature in any good IoT product is the ability to remotely upgrade the firmware or send the patches as part of the maintainability that prevents big software bugs from turning your IoT product network into a botnet. A lot of our time is actually spent trying to make sure that our remote update capabilities are reliable, always functioning and globally distributed. You'd think this is an easy problem to solve but when you're working on a microcontroller that's not running an operating system, running bare metal code, things get a little bit more complicated when you want to make sure that any device anywhere in the world can install the next version of firmware reliably. CHARLES: Right. At any time there's a software update, it's always, it bugs me and then do I want to do this and it's always optional. There's none of that, right? It's just what a new version of the firmware goes out, boom! It goes out there. JOHN: You can design it in different ways. There are some great products out there. Apply the firmware update through the user's phone so you may open up your products application and it says, "There's an update available. Go update." That's definitely one way to do it but that's the problem if the user is not home and maybe they've set this device up in a guest house and they won't be home for six more months, then you have a device that could be vulnerable for six months, which is a long time in the world of software. CHARLES: Yeah, that's true. JOHN: To get around that, obviously our preferred solution is to have the device checked into our cloud servers to see if the device itself has updates available and then go through the download and update process that way, just to make sure even if the user is not home or never opens their mobile app, it will still get those critical security updates. CHARLES: Sounds hard. You're running a risk of bricking someone's device if that update doesn't go very well or it loses internet in the middle or power. JOHN: Very true, especially when you go towards a bare metal microcontroller with limited memory and limited processing capabilities, unreliable internet connection, a lot of work has to be done on the device side to make sure if something goes wrong during the firmware download process or installing the image correctly that it has a backup image. If you're downloading a new firmware upgrade and the download gets corrupted halfway through, make sure you have an old image that you can boot into. That's one part of it. The other part is detecting that it went bad if it gets past downloads in your image and then it reboot itself and tries to boot into it, how do you know that that image actually isn't behaving the way you want it to and then go ahead and revert back into that original stable version. CHARLES: I assume there's some key so that you can verify, not only that the image is not corrupt but it's a certified Knocki image that's coming down the wire? JOHN: Exactly. We signature verification, again something that I think anybody on the internet should be using when you download new software but make sure that the new firmware update was actually written by Knocki and you're not installing someone else's code. Another important factor is just please use HTTPS secure SSL connections to your server, then that reduces the possibility of someone taking over and giving you their own firmware image. But there are a lot of low power devices out there that are being used to make IoT products. These low power devices are important for many reasons but they have restrictions and sometimes, their security capabilities are limited. Maybe doing encryption on the device and actually are doing certificate verification. That's a costly operation. CHARLES: It sounds like there's a lot of cycles that that consumes. JOHN: Definitely. Most people try to make sure they have the resources to solve these problems but at the same time, there are a lot of developers out there that are cutting corners and that's where you get these big news stories about IoT products getting taken over. CHARLES: Along that vein, it's your reality but it constantly blows my mind that things that you're living without when you're programming for these devices like Knocki is do you have to write your own network stack? When you're doing these downloads, that's kind of like got it all. You've got the encryption piece that you've got to do to make sure that you're connecting over SSL so you've got to do the whole handshake and you've got to do the key exchange and the certificate verification and then the packets come in asynchronously so your message is arriving asynchronously in bits so the header is being assembled, now I've got the HTTP headers, now I can go ahead and get the body. There's a lot that happens for us when we're making a simple Ruby request. We're basically like resource.get. Boom! And it just comes to us fully assembled in memory. How much do you have to hand roll all of that? Are there libraries for doing it? How do you put that process together of just even downloading the image? JOHN: Fortunately, there are tons of open source freely available libraries for embedded C software that can help us solve these problems -- CHARLES: Is this like a genre of software like if I want to go look for these libraries, how I look for them? JOHN: In my example, all of our firmware is written in C or C++. Since we're working on a microcontroller with limited resources, it's important to look for libraries that don't use dynamic memory allocation. That's why it's a really big [inaudible]. Some software relies really heavily on that but -- CHARLES: When you say dynamic memory allocation, you're talking about like Malloc? JOHN: Exactly. CHARLES: You are basically are allocating memory on the heap. When you're doing for this, you basically want to do everything on the stack. Now, is that just because the instruction set of the processor doesn't support it or is it because it's just there be dragons like here there be dragons? JOHN: That particular scenario is actually just due to resource limitations. There's just not a lot of memory on our device. We do use Malloc in some cases but we have to be very careful about when we use it and make sure that it's always going to have the memory required or if it doesn't have the memory required, there's some fail safes involved. If you just use someone else's open source library and they're allocating memory left and right, they could end up causing issues on your embedded system. CHARLES: Right. Now, just a little bit of background for people who might not be fully familiar with Malloc, it's just when you're executing a program, you have this heap memory, which is where you store random stuff and then you have your stuff on like the call stack. Your variables that are on the call stack are in one place and then your just generic data structures that could be accessed from anywhere are in this thing called the heap. Our dynamic languages that we use like Ruby and JavaScript, the heap is hot stuff. Like everything gets allocated on the heap, that's why they consume these huge amounts of memory and then the things that are on the stack, really are just pointers that are referencing these big bags of data that are on the heap. But it sounds like you've got the exact opposite situation where you don't want to have big bags of memory that are just floating around in a heap and you want to do everything inside that stack. JOHN: Exactly. I couldn't have said it better. CHARLES: Anyway, you're looking for libraries that don't do that because it sounds like any time you want to allocate memory on the heap, that's going to be shared for the whole program, that space is very limited so you want to be very, very, very strict. You want to control that process. You don't want any other library that's doing it for you. Is that fair? JOHN: That's correct. That's also one specific example, dynamic memory allocation of the things that you want to make sure your other software libraries aren't going to be abusing. But in general, you need to make sure that any code that you're putting is compatible with your system. It doesn't have some special hardware requirement that your embedded system doesn't have. CHARLES: Right. For people who want to get into hardware hacking, is there some golden seal of approval like the people say like, "This library is great for embedded devices." Like I said, a lot of times when you're coming into it, you don't know what to look for so what you're really looking for is some expert or authority on the subject who can say, "This is good. This is not good." It is like, "Don't even look at this library because you're going to find something else because this is not embedded-friendly." JOHN: That's a good point. I wish there was a golden seal of approval or I wish I knew one, at least. Normally, most of our code that we uses are hosted on GitHub. Usually, we try to find software that was optimized from embedded systems and the author of that code will usually mention -- CHARLES: That [inaudible] me. JOHN: Exactly. This was designed for microcontrollers. ELRICK: I was going to ask if there's a golden standard when you're building these type of devices. Is there a checklist of things that if someone's going to build something similar that these are good things on your checklist that you should attempt to check off, if you're building this sort of device or want to build something similar. CHARLES: Now, you mean things like update and whatnot? ELRICK: Like updating or like how you were mentioning avoiding dynamic memory allocation. Anything, you can just shoot from the hip, like these are things that you should watch out for a lot of your battery power, you should look out for this or anything. JOHN: Yes. I definitely think the number one consideration that the biggest check box and [inaudible] before it goes out the door is going to be your security suite. Make sure your internet connections are encrypted: SSL, TLSL, that good stuff. Then as we hit on earlier, making sure that you always have a way of updating the device but don't use back doors. A lot of people think to update your device, you should put a back door access and you can go in and download updates that way. That's not the answer. ELRICK: That's like the back door that they were looking for in Apple like, "Do you guys have a backdoor to get into your device?" No. JOHN: No. That can be a controversial conversation. CHARLES: Yeah, or they're like, "Come on, really. It's okay. You can show us the backdoor." No, there is no backdoor. "I know you have to say that. Blink-blink." ELRICK: That's an interesting problem that you guys are solving on how to update these devices. You guys are essentially hand rolling or developing custom software to do that. JOHN: Again fortunately, we're using a Texas Instruments SSC system on a chip. They provide some core functionality, some core drivers that really help us out. For example, they provide a special bootloader that can really assist with a lot of the firmware download back up framework image checking, that sort of functionality. We don't have to write it all by scratch but we do have to write the logic to make sure that the device does check for updates and it doesn't forget to check in and talk to us. ELRICK: On the cloud side, do you guys have to write any custom software to do diffing, to make sure like -- Oh, do you diffing? Or do you just update everything all complete, like once you're updating, you're going to get a brand new update or do you diff and say, "You only need this." JOHN: Since we're working on the system that we're using, it just requires a fully-compiled image that gets installed by the bootloader. We can't really send just a patch to one part of the firmware, if that's what you're asking. CHARLES: But I assume there must be some state that's on the Knocki itself. Just even the credentials for the local Wi-Fi network, what devices it's connected to, part of the system is updating and part of it is not, I assume but how do you make sure that that state is compatible with the new firmware? JOHN: Yeah, that's another great point to keep in mind. The way we keep most of, we call it nonvolatile memory, every time the device reboot, it's going to forget about everything that was stored in RAM so we need to have somewhere in nonvolatile to store these things. We have a file system on the device that we can create files with different device configurations, algorithm, settings, Wi-Fi credentials, that sort of stuff. CHARLES: That file system, is that anything that we would even be familiar with like ZFS or is it just a custom file system that you've written or that you found on GitHub. JOHN: No, fortunately this is just a standard FAT file system. We do have some creature comforts there but that's not necessarily the norm. CHARLES: You heard it here. Is that FAT16? JOHN: No, it's FAT32. CHARLES: FAT32, described as creature comfort. JOHN: Yeah, we have a different perspective of creature comfort. CHARLES: There's a couple of things because immediately, what this brings to mind is for people who are familiar with Ruby on Rails, they have this concept of migrations, where you're migrating the schema of your database and as you have to transform the data from one format to the other, you're running these migrations. One of the things that's nice about that is if, let's say I have some system that is at Version 1, but let's say, I have one of the devices that hasn't taken an update, it starts at Version 1 and it needs to go to like Version 100. But you could have 10 format changes in between there. Is there a way to handle that case where you're basically incrementally applying a bunch of transforms? JOHN: Yes. That's another great point. We take this on a case-by-case basis. Fortunately, being a small relatively simple system, there's not a whole lot of state data to keep track of. But to handle that situation, we've written are own OTA server-side software that manages the devices sending updates -- CHARLES: Acronym alert, OTA? JOHN: I'm sorry, yeah. Another acronym, OTA -- over the air updates. That's our slang for remotely sending firmware updates. CHARLES: Sorry to interrupt. It's just we have to unpack acronyms. JOHN: No, I'm sorry. I use a lot of jargons here. CHARLES: You know what? The thing is, so do I and I just never even notice it. JOHN: To handle that scenario, the way we handle it, our cloud knows what devices are out there and what firmware updates we've sent out to it. Furthermore, when the device checks in with the cloud and ask, "Do I have an update available?" It also tells the cloud, "By the way, I'm running Version 1.0." The cloud knows, if it's on Version 1.0, there's going to be some incremental changes that need to be made before we get to that last update and we can apply those changes incrementally. CHARLES: I see. I feel like we've touched on so many of these concepts that are universal to development but only projected into the hardware space. We've talked about dynamic allocation of memory and data migrations and it sounds like what you're describing in a way with OTAs is continuous delivery, where you have some way of automatically pushing out an update and all the stuff that's involved in that. It's just really cool to hear to view through such a vastly different lens than what we're used to. ELRICK: We've been talking a lot about communication between devices and back to the cloud in things of that nature. Does that play into the conversation around decentralization of IoT infrastructure and what does decentralization of IoT even mean? JOHN: Decentralization as a new methodology or ideology that a lot of people are adopting, I shouldn't say new. It's been around forever but the idea is from a high level, looking at the internet, most of the internet is access through some central, server is hosted on you name it -- XYZ cloud hosting provider. The way you do your URL DNS resolution that goes through centralized DNS servers that say, "You want to look at Netflix?" Netflix is stored over here on this AWS server farm. Decentralization, the idea is we don't necessarily need to talk to this DNS server and talk to AWS just to get content from specific providers. If you look at IoT for example, a lot of times in our case, we want to tap three times on the table and then later on, it will do the cloud, send the message and then turn on your Philips Hue light bulb in the living room. It would be great if the message could just go directly from Knocki to the Philips Hue light bulb, rather than going to our cloud, on some centralized hosting provider, then to Philip Hue's cloud, on their provider then out to the Philips Hue light bulb. Those are some of the really popular technologies that's a lot of people are talking about that really take advantage of the concept of decentralization. But it does -- CHARLES: Let me understand because why these would be necessary. When I get why it's compelling, if I want to have my Knocki talking directly to my Philips Hue light bulb without getting your servers involved, without getting Hue's servers involved, it seems like it's going to be a lot faster and just a lot more robust. There's just less links in the chain but it presents its own problems, like on both ends of the conversation between the Knocki and the Philips Hue, how do they agree that this is sanctioned by a user? That's just leaps out. That's a hard problem to solve. ELRICK: That you use some sort of like public-private key type of encryption to say, "It's me. Am I allowed to do this?" CHARLES: How do you decentralize that? JOHN: Well, I'd like to preface this by saying I'm not an expert on that particular subject but the goal is, if you're familiar with the bit torrent protocol and how it keeps track of a lot of different peers on a network using distributed hash tables, the idea is if you know at least one other person on the network, that person can say, "There's some other people that you may be interested in talking to, that may actually want your message. I'm just a bystander on the network and I don't really need your message but this guy is interested in it." In our application, that would be our server. We have to ask our server, who's out there that wants to hear what I have to say. The server is going to say, "Knocki 123, this Phillips Hue is over here at this address, this unique resource identifier, he's going to be very interested when you have two taps or three taps on the desk so just go ahead and talk directly to him. You don't need to talk to me." There's a lot more of that goes into that about making sure that the network can heal itself if somebody goes offline. But as I said I'm not really an expert in that subject. CHARLES: Right, but it really is compelling. Would you then, maybe have some device that was just kind of your coordinator in your home or multiple devices that would act as these bit torrent trackers? JOHN: Yeah, I think -- CHARLES: Or would the devices themselves actually be able to do that, like the Knocki could actually participate in the conversation about what other devices there were in the home. JOHN: Exactly, yeah. I think in a true peer-to-peer network, any peer can talk to another peer and eventually learn where the other node that they want to talk to is. You don't have to talk to any one particular person but you can ask anybody and they can tell you how to talk to the person you're looking for. The really big advantage to decentralization in my opinion is security. A lot of times if everything is controlled through one central point, that's one central point of failure. If someone DDOS's your cloud service, then now your entire network of devices is offline, just because one location got attacked. If it's a decentralized network, there's no one central point of failure and it's very, very difficult for someone to attack your network. CHARLES: Right, that's true but the tradeoff then is complexity that your decentralize network has to agree, somehow come to some consensus. It's very easy to generate with consensus when you have one process or one point that's driving everything. JOHN: Exactly. Another big tradeoff is ownership of the data and enterprise today are really big revenue your point for a company is being able to have ownership of data and extract meaningful insights. But if your device doesn't talk to your central server every time I want to do something, how does your server know everything that your device is doing and you lose a lot of that data. There's a tradeoff there in how you're going to get the data you need to run your business but also let your device run autonomously on decentralized network. ELRICK: Do you think that this is going to be helpful or harmful to IoT? What's your views on decentralization? JOHN: I think it could be very powerful. Right now, I'm not aware of any products that are really using a decentralized architecture for IoT and the main reason for that is companies and developers are a little slow to adopt it because they want to have that ownership of every data packet that goes to the network. They own it. They can see it. But I think in the future, people will start to realize that they can still get the data that they need to run this business. They can still have visibility and control over the network the way they need to run their business without controlling every single packet. When that happens, I think it's going to be a revolution for the internet as a whole but it's really going to revolutionize IoT and devices will get lower power. They'll get faster and they'll get more secure. CHARLES: When you say being able to get the data that they need, is it just being able to asynchronously spool off the data later? I guess I'm trying to understand how they get the data if it's never talking to some central servers? Or is it just you will get the data at the time you want it or there will be some delay? I assume you can also have your server being part of... I don't know. I'm just curious how you see that playing out. JOHN: I think, every developer is going to have to tackle that on a case-by-case scenario but take for example a big brand smart thermostat company. They have a device that's going to control your AC heating and air and the house and it also collects a lot of the data from when you're home and when you're using it to be smart and adjust the temperature at certain times of day even when you're not home. Again, I don't work for any company that does that and I don't know how they're doing their devices under the hood but traditionally, they tap to a centralized server and they send a lot of this information whenever it's happening, always to the server. Every time the user adjust the temperature, it sends an update to the server and says, "The user just updated." In a decentralized network, these devices can just talk to themselves and say maybe periodically or every day and it'll just send one update and say, "The user adjusted it." You can still talk to a central server but it doesn't have to rely on the central server. CHARLES: Right. It's just what we call, an out of band process. JOHN: Exactly, not mission critical. CHARLES: Okay, I got it. Talking about the decentralization and interacting with other devices, how do you manage the ecosystem right now with Knocki? It's a general purpose interface to rise. It serves really the role of a keyboard or a mouse or some way of controlling other devices and other systems. I assume that in order to do that, you have to understand the capabilities of those systems or maybe you don't. How do you integrate these two devices? Let's go with the thermostat and the Knocki or maybe one that you're more familiar with that you've done. Do you all have to write the integration? Can a third party write the integration? Or is there some way to automatically discover and map the existing inputs of the device. I feel like we've got all these new devices are coming out day to day then and now, there's more and more permutations in which to confine these devices into a coherent system and I'm just curious to hear about that integration story from your perspective. JOHN: Certainly. If we want to configure our Knocki to tap three times and turn on our Philips Hue light bulbs -- I keep using Philips Hue just because that's what I've been actively working on lately. We currently rewrite the integrations in our own backend so the user pulls up the mobile app and says, "Knocki on my desk, every time I tap three times, listen to this Philips Hue," and then we have an integration where in the mobile app, they can essentially set a lot of the parameters that a Philips Hue light would use based on API that Philips Hue would provide us. That's the way most integrations are going to happen with third party products. They expose an API and we can write a little module and the user can configure that API. CHARLES: I see and as far as making affordances for third party people, if they want to change the behavior or add like intelligence, obviously they can configure it from the app but if I want to say add behaviors or something like that. JOHN: When you say add behaviors, you mean add new -- CHARLES: I mean like, rather than turning the lights on and off, say I want to strobe the lights or flash the lights, maybe I'm someone who's running a theater or something and during intermission, I want to knock three times to flash the overhead lights. I don't know if that's something that your integration with Hue could do but if I want to be able to add that. JOHN: Okay, I see your question. We try to enable as much of the products functionality as possible through our own integration on our mobile app but say, you're a hacker and you've come up with your own smart light that turns on any sort of party mode and flashes different colors whenever you want and your Philips Hue or any other smart light just can't quite do what you wanted to do. In the future, our goal is to have an open API that people can access and they can hopefully control their own homemade IoT devices. CHARLES: Now, what about for existing ones. You can definitely flash the lights with the Philip Hue but you're going have to have some custom software to do it, right? Do you see what I mean? You have to send a series of messages to it in sequence. JOHN: In that scenario, we currently don't support that and don't have a plan to support that. In our research, that's a really small use case of people that would be interested in that. Also, it's difficult now if we wanted to do some sort repeated command, you knock three times and then every 30 seconds, it's going to send a command in your light bulbs. We have to be careful about having processes that run away and you have a bunch of CPU power forever in the cloud. We may include features like that in the future. I think the most likely path for that sort of stuff is we'll have an open API that people can direct Knocki's inputs to their own server and then their own server can flash their Philips Hue lights as much as they want. ELRICK: Is there any standardization between the communication and what these API supposed to look, like the communication between devices? anyone can have an API, expecting one thing and someone that's writing software to communicate with that, wouldn't have to go look it up. Do you know of any standardization? JOHN: Yes. I know there have been a couple of companies out there trying to put a standard on the market and I think a standard would be a great idea. ELRICK: Yeah, I think so too. JOHN: It would be wonderful if we could just write generic control structures or information flow structures and anybody can hook their stuff up to it. As far as I know, I haven't seen any that really fit the bill. CHARLES: It feel like there's something that programming systems like software developers have been chasing for a long time is to have some distributed set of peers that they can look each other up. You can discover the capabilities of a thing without ever having to even know about in the first place. But I haven't really known that worked really well and hit that sweet spot. I'm thinking of DCOM and Java. There's like Java distributed beans or something like that. You have this idea of these objects in the cloud, which seems kind of analogous to what we're talking about now, except we're talking about actual devices, rather the software devices but who knows. Maybe it'll pan out where we'll have some standard for discovery and integration. JOHN: It's interesting that there hasn't been one already. You look at IoT and it's really ripe for standardization because a lot of the communication between devices takes the same format. You're generally just passing a small message saying, on or off or, "I read this temperature at 75 degrees. Who knows, maybe someone will solve it. CHARLES: Yeah, maybe so. Maybe the folks at Kasita. They're active integrators. They were on the podcast two episodes ago and one of their challenges was getting all these 30 things to talk together well. Maybe we can follow up with them and if they could have a standard, what they would like it to look like? JOHN: If they get on that, I would love to hear what they were working on. CHARLES: I think, maybe they mostly, have a wish list. It is like, "I wish it did this. I wish it did this. I wish it did this." ELRICK: Maybe we need to have like a 10-way podcast. It's like IoT companies and we can hash it out like the TC39 of IoT on the Frontside Podcast. CHARLES: Right, and then everybody punches each other. All right, well thank you so much, John for coming and talking with us. It's always fascinating. You can find Knocki at @Knocki on Twitter and Knocki.com. It's a great product and like I said, always a fascinating conversation so thank you so much for coming on the show. JOHN: Yeah, thank you very much for having me. It was a great conversation. CHARLES: With that, we'll say goodbye. Thank you, Elrick. ELRICK: Thank you. CHARLES: We are, as always, the Frontside at @TheFrontside on Twitter, Frontside.io on the web or just drop us a line over email, Contact@Frontside.io. Thanks everybody.

We read a trip report about FreeBSD in China, look at how Unix deals with Signals, a stats collector in DragonFlyBSD & much more! This episode was brought to you by Headlines Trip Report: FreeBSD in China at COPU and LinuxCon (https://www.freebsdfoundation.org/blog/trip-report-freebsd-in-china-at-copu-and-linuxcon/) This trip report is from Deb Goodkin, the Executive Director of the FreeBSD Foundation. She travelled to China in May 2017 to promote FreeBSD, meet with companies, and participate in discussions around Open Source. > In May of 2017, we were invited to give a talk about FreeBSD at COPU's (China Open Source Promotional Unit) Open Source China, Open Source World Summit, which took place June 21-22, in Beijing. This was a tremendous opportunity to talk about the advantages of FreeBSD to the open source leaders and organizations interested in open source. I was honored to represent the Project and Foundation and give the presentation “FreeBSD Advantages and Applications”. > Since I was already going to be in Beijing, and LinuxCon China was being held right before the COPU event, Microsoft invited me to be part of a women-in-tech panel they were sponsoring. There were six of us on the panel including two from Microsoft, one from the Linux Foundation, one from Accenture of China, and one from Women Who Code. Two of us spoke in English, with everyone else speaking Chinese. It was disappointing that we didn't have translators, because I would have loved hearing everyone's answers. We had excellent questions from the audience at the end. I also had a chance to talk with a journalist from Beijing, where I emphasized how contributing to an open source project, like FreeBSD, is a wonderful way to get experience to boost your resume for a job. > The first day of LinuxCon also happened to be FreeBSD Day. I had my posters with me and was thrilled to have the Honorary Chairman of COPU (also known as the “Father of Open Source in China”) hold one up for a photo op. Unfortunately, I haven't been able to get a copy of that photo for proof (I'm still working on it!). We spent a long time discussing the strengths of FreeBSD. He believes there are many applications in China that could benefit from FreeBSD, especially for embedded devices, university research, and open source education. We had more time throughout the week to discuss FreeBSD in more detail. > Since I was at LinuxCon, I had a chance to meet with people from the Linux Foundation, other open source projects, and some of our donors. With LinuxCon changing its name to Open Source Summit, I discussed how important it is to include minority voices like ours to contribute to improving the open source ecosystem. The people I talked to within the Linux Foundation agreed and suggested that we get someone from the Project to give a talk at the Open Source Summit in Prague this October. Jim Zemlin, the Linux Foundation Executive Director, suggested having a BSD track at the summits. We did miss the call for proposals for that conference, but we need to get people to consider submitting proposals for the Open Source Summits in 2018. > I talked to a CTO from a company that donates to us and he brought up his belief that FreeBSD is much easier to get started on as a contributor. He talked about the steep path in Linux to getting contributions accepted due to having over 10,000 developers and the hierarchy of decision makers, from Linus to his main lieutenants to the layers beneath him. It can take 6 months to get your changes in! > On Tuesday, Kylie and I met with a representative from Huawei, who we've been meeting over the phone with over the past few months. Huawei has a FreeBSD contributor and is looking to add more. We were thrilled to hear they decided to donate this year. We look forward to helping them get up to speed with FreeBSD and collaborate with the Project. > Wednesday marked the beginning of COPU and the reason I flew all the way to Beijing! We started the summit with having a group photo of all the speakers:The honorary chairman, Professor Lu in the front middle. > My presentation was called “FreeBSD Advantages and Applications”. A lot of the material came from Foundation Board President, George-Neville-Neil's presentation, “FreeBSD is not a Linux Distribution”, which is a wonderful introduction to FreeBSD and includes the history of FreeBSD, who uses it and why, and which features stand out. My presentation went well, with Professor Lu and others engaged through the translators. Afterwards, I was invited to a VIP dinner, which I was thrilled about. > The only hitch was that Kylie and I were running a FreeBSD meetup that evening, and both were important! Beijing during rush hour is crazy, even trying to go only a couple of miles is challenging. We made plans that I would go to the meetup and give the same presentation, and then head back to the dinner. Amazingly, it worked out. Check out the rest of her trip report and stay tuned for more news from the region as this is one of the focus areas of the Foundation. *** Unix: Dealing with signals (http://www.networkworld.com/article/3211296/linux/unix-dealing-with-signals.html) Signals on Unix systems are critical to the way processes live and die. This article looks at how they're generated, how they work, and how processes receive or block them On Unix systems, there are several ways to send signals to processes—with a kill command, with a keyboard sequence (like control-C), or through a program Signals are also generated by hardware exceptions such as segmentation faults and illegal instructions, timers and child process termination. But how do you know what signals a process will react to? After all, what a process is programmed to do and able to ignore is another issue. Fortunately, the /proc file system makes information about how processes handle signals (and which they block or ignore) accessible with commands like the one shown below. In this command, we're looking at information related to the login shell for the current user, the "$$" representing the current process. On FreeBSD, you can use procstat -i PID to get that and even more information, and easier to digest form P if signal is pending in the global process queue I if signal delivery disposition is SIGIGN C if signal delivery is to catch it Catching a signal requires that a signal handling function exists in the process to handle a given signal. The SIGKILL (9) and SIGSTOP (#) signals cannot be ignored or caught. For example, if you wanted to tell the kernel that ctrl-C's are to be ignored, you would include something like this in your source code: signal(SIGINT, SIGIGN); To ensure that the default action for a signal is taken, you would do something like this instead: signal(SIGSEGV, SIGDFL); + The article then shows some ways to send signals from the command line, for example to send SIGHUP to a process with pid 1234: kill -HUP 1234 + You can get a list of the different signals by running kill -l On Unix systems, signals are used to send all kinds of information to running processes, and they come from user commands, other processes, and the kernel itself. Through /proc, information about how processes are handling signals is now easily accessible and, with just a little manipulation of the data, easy to understand. links owned by NGZ erroneously marked as on loan (https://smartos.org/bugview/OS-6274) NGZ (Non-Global Zone), is IllumOS speak for their equivalent to a jail > As reported by user brianewell in smartos-live#737, NGZ ip tunnels stopped persisting across zone reboot. This behavior appeared in the 20170202 PI and was not present in previous releases. After much spelunking I determined that this was caused by a regression introduced in commit 33df115 (part of the OS-5363 work). The regression was a one-line change to link_activate() which marks NGZ links as on loan when they are in fact not loaned because the NGZ created and owns the link. “On loan” means the interface belongs to the host (GZ, Global Zone), and has been loaned to the NGZ (Jail) This regression was easy to introduce because of the subtle nature of this code and lack of comments. I'm going to remove the regressive line, add clarifying comments, and also add some asserts. The following is a detailed analysis of the issue, how I debugged it, and why my one-line change caused the regression: To start I verified that PI 20170119 work as expected: booted 20170119 created iptun (named v4sys76) inside of a native NGZ (names sos-zone) performed a reboot of sos-zone zlogin to sos-zone and verify iptun still exists after reboot Then I booted the GZ into PI 20170202 and verified the iptun did not show up booted 20170202 started sos-zone zlogin and verified the iptun was missing At this point I thought I would recreate the iptun and see if I could monitor the zone halt/boot process for the culprit, but instead I received an error from dladm: "object already exists". I didn't expect this. So I used mdb to inspect the dlmgmtd state. Sure enough the iptun exists in dlmgmtd. Okay, so if the link already exists, why doesn't it show up (in either the GZ or the NGZ)? If a link is not marked as active then it won't show up when you query dladm. When booting the zone on 20170119 the llflags for the iptun contained the value 0x3. So the problem is the link is not marked as active on the 20170202 PI. The linkactivate() function is responsible for marking a link as active. I used dtrace to verify this function was called on the 20170202 PI and that the dlmgmtlinkt had the correct llflags value. So the iptun link structure has the correct llflags when linkactivate() returns but when I inspect the same structure with mdb afterwards the value has changed. Sometime after linkactivate() completes some other process changed the llflags value. My next question was: where is linkactivate() called and what comes after it that might affect the llflags? I did another trace and got this stack. The dlmgmtupid() function calls dlmgmtwritedbentry() after linkactivate() and that can change the flags. But dtrace proved the llflags value was still 0x3 after returning from this function. With no obvious questions left I then asked cscope to show me all places where llflags is modified. As I walked through the list I used dtrace to eliminate candidates one at a time -- until I reached dlmgmtdestroycommon(). I would not have expected this function to show up during zone boot but sure enough it was being called somehow, and by someone. Who? Since there is no easy way to track door calls it was at this point I decided to go nuclear and use the dtrace stop action to stop dlmgmtd when it hits dlmgmtdestroycommon(). Then I used mdb -k to inspect the door info for the dlmgmtd threads and look for my culprit. The culprit is doupiptun() caused by the dladm up-iptun call. Using ptree I then realized this was happening as part of the zone boot under the network/iptun svc startup. At this point it was a matter of doing a zlogin to sos-zone and running truss on dladm up-iptun to find the real reason why dladmdestroydatalinkid() is called. So the link is marked as inactive because dladmgetsnapconf() fails with DLADMSTATUSDENIED which is mapped to EACCESS. Looking at the dladmgetsnapconf() code I see the following “The caller is in a non-global zone and the persistent configuration belongs to the global zone.” What this is saying is that if a link is marked "on loan" (meaning it's technically owned/created by the GZ but assigned/loaned to the NGZ) and the zone calling dladmgetsnapconf() is an NGZ then return EACCESS because the configuration of the link is up to the GZ, not the NGZ. This code is correct and should be enforced, but why is it tripping in PI 20170202 and not 20170119? It comes back to my earlier observation that in the 20170202 PI we marked the iptun as "on loan" but not in the older one. Why? Well as it turns out while fixing OS-5363 I fixed what I thought was a bug in linkactivate() When I first read this code it was my understanding that anytime we added a link to a zone's datalink list, by calling zoneadddatalink(), that link was then considered "on loan". My understanding was incorrect. The linkactivate() code has a subtleness that eluded me. There are two cases in linkactivate(): 1. The link is under an NGZ's datalink list but it's lllinkid doesn't reflect that (e.g., the link is found under zoneid 3 but lllinkid is 0). In this case the link is owned by the GZ but is being loaned to an NGZ and the link state should be updated accordingly. We get in this situation when dlmgmtd is restated for some reason (it must resync it's in-memory state with the state of the system). 2. The link is NOT under any NGZ's (zonecheckdatalink() is only concerned with NGZs) datalink list but its llzoneid holds the value of an NGZ. This indicates that the link is owned by an NGZ but for whatever reason is not currently under the NGZ's datalink list (e.g., because we are booting the zone and we now need to assign the link to its list). So the fix is to revert that one line change as well as add some clarifying comments and also some asserts to prevent further confusion in the future. + A nice breakdown by Ryan Zezeski of how he accidently introduced a regression, and how he tracked it down using dtrace and mdb New experimental statistics collector in master (http://dpaste.com/2YP0X9C) Master now has an in-kernel statistics collector which is enabled by default, and a (still primitive) user land program to access it. This recorder samples the state of the machine once every 10 seconds and records it in a large FIFO, all in-kernel. The FIFO typically contains 8192 entries, or around the last 23 hours worth of data. Statistics recorded include current load, user/sys/idle cpu use, swap use, VM fault rate, VM memory statistics, and counters for syscalls, path lookups, and various interrupt types. A few more useful counters will probably be added... I'd like to tie cpu temperature, fork rate, and exec rate in at some point, as well as network and disk traffic. The statistics gathering takes essentially no real overhead and is always on, so any user at the spur of the moment with no prior intent can query the last 23 hours worth of data. There is a user frontend to the data called 'kcollect' (its tied into the buildworld now). Currently still primitive. Ultimately my intention is to integrate it with a dbm database for long-term statistical data retention (if desired) using an occasional (like once-an-hour) cron-job to soak up anything new, with plenty of wiggle room due to the amount of time the kernel keeps itself. This is better and less invasive than having a userland statistics gathering script running every few minutes from cron and has the advantage of giving you a lot of data on the spur of the moment without having to ask for it before-hand. If you have gnuplot installed (pkg install gnuplot), kcollect can generate some useful graphs based on the in-kernel data. Well, it will be boring if the machine isn't doing anything :-). There are options to use gnuplot to generate a plot window in X or a .jpg or .png file, and other options to set the width and height and such. At the moment the gnuplot output uses a subset of statically defined fields to plot but ultimately the field list it uses will be specifiable. Sample image generated during a synth run (http://apollo.backplane.com/DFlyMisc/kcollect03.jpg) News Roundup openbsd changes of note 626 (https://www.tedunangst.com/flak/post/openbsd-changes-of-note-626) Hackerthon is imminent. There are two signals one can receive after accessing invalid memory, SIGBUS and SIGSEGV. Nobody seems to know what the difference is or should be, although some theories have been unearthed. Make some attempt to be slightly more consistent and predictable in OpenBSD. Introduces jiffies in an effort to appease our penguin oppressors. Clarify that IP.OF.UPSTREAM.RESOLVER is not actually the hostname of a server you can use. Switch acpibat to use _BIX before _BIF, which means you might see discharge cycle counts, too. Assorted clang compatibility. clang uses -Oz to mean optimize for size and -Os for something else, so make gcc accept -Oz so all makefiles can be the same. Adjust some hardlinks. Make sure we build gcc with gcc. The SSLcheckprivate_key function is a lie. Switch the amd64 and i386 compiler to clang and see what happens. We are moving towards using wscons (wstpad) as the driver for touchpads. Dancing with the stars, er, NET_LOCK(). clang emits lots of warnings. Fix some of them. Turn off a bunch of clang builtins because we have a strong preference that code use our libc versions. Some other changes because clang is not gcc. Among other curiosities, static variables in the special .openbsd.randomdata are sometimes assumed to be all zero, leading the clang optimizer to eliminate reads of such variables. Some more pledge rules for sed. If the script doesn't require opening new files, don't let it. Backport a bajillion fixes to stable. Release errata. RFC 1885 was obsoleted nearly 20 years ago by RFC 2463 which was obsoleted over 10 years ago by RFC 4443. We are probably not going back. Update libexpat to 2.2.3. vmm: support more than 3855MB guest memory. Merge libdrm 2.4.82. Disable SSE optimizations on i386/amd64 for SlowBcopy. It is supposed to be slow. Prevents crashes when talking to memory mapped video memory in a hypervisor. The $25 “FREEDOM Laptop!” (https://functionallyparanoid.com/2017/08/08/the-25-freedom-laptop/) Time to get back to the original intent of this blog – talking about my paranoid obsession with information security! So break out your tinfoil hats my friends because this will be a fun ride. I'm looking for the most open source / freedom respecting portable computing experience I can possibly find and I'm going to document my work in real-time so you will get to experience the ups (and possibly the downs) of that path through the universe. With that said, let's get rolling. When I built my OpenBSD router using the APU2 board, I discovered that there are some amd64 systems that use open source BIOS. This one used Coreboot and after some investigation I discovered that there was an even more paranoid open source BIOS called Libreboot out there. That started to feel like it might scratch my itch. Well, after playing around with some lower-powered systems like my APU2 board, my Thinkpad x230 and my SPARC64 boxes, I thought, if it runs amd64 code and I can run an open source operating system on it, the thing should be powerful enough for me to do most (if not all) of what I need it to do. At this point, I started looking for a viable machine. From a performance perspective, it looked like the Thinkpad x200, T400, T500 and W500 were all viable candidates. After paying attention on eBay for a while, I saw something that was either going to be a sweet deal, or a throwaway piece of garbage! I found a listing for a Thinkpad T500 that said it didn't come with a power adapter and was 100% untested. From looking at the photos, it seemed like there was nothing that had been molested about it. Obviously, nobody was jumping on something this risky so I thought, “what the heck” and dropped a bit at the opening price of $24.99. Well, guess what. I won the auction. Now to see what I got. When the laptop showed up, I discovered it was minus its hard drive (but the outside plastic cover was still in place). I plugged in my x230's power adapter and hit the button. I got lights and was dropped to the BIOS screen. To my eternal joy, I discovered that the machine I had purchased for $25 was 100% functional and included the T9400 2.54 GHz Core 2 Duo CPU and the 1680×1050 display panel. W00t! First things first, I need to get this machine a hard drive and get the RAM upgraded from the 2GB that it showed up with to 8GB. Good news is that these two purchases only totaled $50 for the pair. An aftermarket 9-cell replacement battery was another $20. Throw in a supported WiFi card that doesn't require a non-free blob from Libreboot at $5.99 off of eBay and $5 for a hard drive caddy and I'm looking at about $65 in additional parts bringing the total cost of the laptop, fully loaded up at just over $100. Not bad at all… Once all of the parts arrived and were installed, now for the fun part. Disassembling the entire thing down to the motherboard so we can re-flash the BIOS with Libreboot. The guide looks particularly challenging for this but hey, I have a nice set of screwdrivers from iFixit and a remarkable lack of fear when it comes to disassembling things. Should be fun! Well, fun didn't even come close. I wish I had shot some pictures along the way because at one point I had a heap of parts in one corner of my “workbench” (the dining room table) and just the bare motherboard, minus the CPU sitting in front of me. With the help of a clip and a bunch of whoops wires (patch cables), I connected my Beaglebone Black to the BIOS chip on the bare motherboard and attempted to read the chip. #fail I figured out after doing some more digging that you need to use the connector on the left side of the BBB if you hold it with the power connector facing away from you. In addition, you should probably read the entire process through instead of stopping at the exciting pinout connector diagram because I missed the bit about the 3.3v power supply need to have ground connected to pin 2 of the BIOS chip. Speaking of that infamous 3.3v power supply, I managed to bend a paperclip into a U shape and jam it into the connector of an old ATX power supply I had in a closet and source power from that. I felt like MacGyver for that one! I was able to successfully read the original Thinkpad BIOS and then flash the Libreboot + Grub2 VESA framebuffer image onto the laptop! I gulped loudly and started the reassembly process. Other than having some cable routing difficulties because the replacement WiFi card didn't have a 5Ghz antenna, it all went back together. Now for the moment of truth! I hit the power button and everything worked!!! At this point I happily scurried to download the latest snapshot of OpenBSD – current and install it. Well, things got a little weird here. Looks like I have to use GRUB to boot this machine now and GRUB won't boot an OpenBSD machine with Full Disk Encryption. That was a bit of a bummer for me. I tilted against that windmill for several days and then finally admitted defeat. So now what to do? Install Arch? Well, here's where I think the crazy caught up to me. I decided to be an utter sell out and install Ubuntu Gnome Edition 17.04 (since that will be the default DE going forward) with full disk encryption. I figured I could have fun playing around in a foreign land and try to harden the heck out of that operating system. I called Ubuntu “grandma's Linux” because a friend of mine installed it on his mom's laptop for her but I figured what the heck – let's see how the other half live! At this point, while I didn't have what I originally set out to do – build a laptop with Libreboot and OpenBSD, I did have a nice compromise that is as well hardened as I can possibly make it and very functional in terms of being able to do what I need to do on a day to day basis. Do I wish it was more portable? Of course. This thing is like a six or seven pounder. However, I feel much more secure in knowing that the vast majority of the code running on this machine is open source and has all the eyes of the community on it, versus something that comes from a vendor that we cannot inspect. My hope is that someone with the talent (unfortunately I lack those skills) takes an interest in getting FDE working with Libreboot on OpenBSD and I will most happily nuke and repave this “ancient of days” machine to run that! FreeBSD Programmers Report Ryzen SMT Bug That Hangs Or Resets Machines (https://hothardware.com/news/freebsd-programmers-report-ryzen-smt-bug-that-hangs-or-resets-machines) It's starting to look like there's an inherent bug with AMD's Zen-based chips that is causing issues on Unix-based operating systems, with both Linux and FreeBSD confirmed. The bug doesn't just affect Ryzen desktop chips, but also AMD's enterprise EPYC chips. It seems safe to assume that Threadripper will bundle it in, as well. It's not entirely clear what is causing the issue, but it's related to the CPU being maxed out in operations, thus causing data to get shifted around in memory, ultimately resulting in unstable software. If the bug is exercised a certain way, it can even cause machines to reset. The revelation about the issue on FreeBSD was posted to the official repository, where the issue is said to happen when threads can lock up, and then cause the system to become unstable. Getting rid of the issue seems as simple as disabling SMT, but that would then negate the benefits provided by having so many threads at-the-ready. On the Linux side of the Unix fence, Phoronix reports on similar issues, where stressing Zen chips with intensive benchmarks can cause one segmentation fault after another. The issue is so profound, that Phoronix Test Suite developer Michael Larabel introduced a special test that can be run to act as a bit of a proof-of-concept. To test another way, PTS can be run with this command: PTS_CONCURRENT_TEST_RUNS=4 TOTAL_LOOP_TIME=60 phoronix-test-suite stress-run build-linux-kernel build-php build-apache build-imagemagick Running this command will compile four different software projects at once, over and over, for an hour. Before long, segfaults should begin to appear (as seen in the shot above). It's not entirely clear if both sets of issues here are related, but seeing as both involve stressing the CPU to its limit, it seems likely. Whether or not this could be patched on a kernel or EFI level is something yet to be seen. TrueOS - UNSTABLE update: 8/7/17 (https://www.trueos.org/blog/unstable-update-8717/) A new UNSTABLE update for TrueOS is available! Released regularly, UNSTABLE updates are the full “rolling release” of TrueOS. UNSTABLE includes experimental features, bugfixes, and other CURRENT FreeBSD work. It is meant to be used by those users interested in using the latest TrueOS and FreeBSD developments to help test and improve these projects. WARNING: UNSTABLE updates are released primarily for TrueOS and FreeBSD testing/experimentation purposes. Update and run UNSTABLE “at your own risk”. Note: There was a CDN issue over the weekend that caused issues for early updaters. Everything appears to be resolved and the update is fully available again. If you encountered instability or package issues from updating on 8/6 or 8/5, roll back to a previous boot environment and run the update again. Changes: UNSTABLE .iso and .img files beginning with TrueOS-2017-08-3-x64 will be available to download from http://download.trueos.org/unstable/amd64/. Due to CDN issues, these are not quite available, look for them later today or tomorrow (8/8/17). This update resyncs all ports with FreeBSD as of 8.1.2017. This includes: New/updated FreeBSD Kernel and World & New DRM (Direct Rendering Manager) next. Experimental patch for libhyve-remote: (From htps://github.com/trueos/freebsd/commit/a67a73e49538448629ea27, thanks araujobsd) The libhyve-remote aims to abstract functionalities from other third party libraries like libvncserver, freerdp, and spice to be used in hypervisor implementation. With a basic data structure it is easy to implement any remote desktop protocol without digging into the protocol specification or third part libraries – check some of our examples.We don't statically link any third party library, instead we use a dynamic linker and load only the functionality necessary to launch the service.Our target is to abstract functionalities from libvncserver, freerdp and spice. Right now, libhyve-remote only supports libvncserver. It is possible to launch a VNC server with different screen resolution as well as with authentication.With this patch we implement support for bhyve to use libhyve-remote that basically abstract some functionalities from libvncserver. We can: Enable wait state, Enable authentication, Enable different resolutions< Have a better compression. Also, we add a new -s flag for vncserver, if the libhyve-remote library is not present in the system, we fallback to bhyve RFB implementation. For example: -s 2,fbuf,tcp=0.0.0.0:5937,w=800,h=600,password=1234567,vncserver,wait New SysAdm Client pages under the System Management category: System Control: This is an interface to browse all the sysctl's on the system. Devices: This lists all known information about devices on the designated system. Lumina Theming: Lumina is testing new theming functionality! By default (in UNSTABLE), a heavily customized version of the Qt5ct engine is included and enabled. This is intended to allow users to quickly adjust themes/icon packs without needing to log out and back in. This also fixes a bug in Insight with different icons loading for the side and primary windows. Look for more information about this new functionality to be discussed on the Lumina Website. Update to Iridium Web Browser: Iridium is a Chromium based browser built with user privacy and security as the primary concern, but still maintaining the speed and usability of Chromium. It is now up to date – give it a try and let us know what you think (search for iridium-browser in AppCafe). Beastie Bits GhostBSD 11.1 Alpha1 is ready (http://www.ghostbsd.org/11.1-ALPHA1) A Special CharmBUG announcement (https://www.meetup.com/CharmBUG/events/242563414/) Byhve Obfuscation Part 1 of Many (https://github.com/HardenedBSD/hardenedBSD/commit/59eabffdca53275086493836f732f24195f3a91d) New BSDMag is out (https://bsdmag.org/download/bsd-magazine-overriding-libc-functions/) git: kernel - Lower VMMAXUSER_ADDRESS to finalize work-around for Ryzen bug (http://lists.dragonflybsd.org/pipermail/commits/2017-August/626190.html) Ken Thompson corrects one of his biggest regrets (https://twitter.com/_rsc/status/897555509141794817) *** Feedback/Questions Hans - zxfer (http://dpaste.com/2SQYQV2) Harza - Google Summer of Code (http://dpaste.com/2175GEB) tadslot - Microphones, Proprietary software, and feedback (http://dpaste.com/154MY1H) Florian - ZFS/Jail (http://dpaste.com/2V9VFAC) Modifying a ZFS root system to a beadm layout (http://dan.langille.org/2015/03/11/modifying-a-zfs-root-system-to-a-beadm-layout/) ***

This week on BSD Now, we review the EuroBSDcon schedule, we explore the mysteries of Docker on OpenBSD, and show you how to run PostgreSQL on ZFS. This episode was brought to you by Headlines EuroBSDcon 2017 - Talks & Schedule published (https://2017.eurobsdcon.org/2017/05/26/talks-schedule-published/) The EuroBSDcon website was updated with the tutorial and talk schedule for the upcoming September conference in Paris, France. Tutorials on the 1st day: Kirk McKusick - An Introduction to the FreeBSD Open-Source Operating System, George Neville-Neil - DTrace for Developers, Taylor R Campbell - How to untangle your threads from a giant lock in a multiprocessor system Tutorials on the 2nd day: Kirk continues his Introduction lecture, Michael Lucas - Core concepts of ZFS (half day), Benedict Reuschling - Managing BSD systems with Ansible (half day), Peter Hessler - BGP for developers and sysadmins Talks include 3 keynotes (2 on the first day, beginning and end), another one at the end of the second day by Brendan Gregg Good mixture of talks of the various BSD projects Also, a good amount of new names and faces Check out the full talk schedule (https://2017.eurobsdcon.org/talks-schedule/). Registration is not open yet, but will be soon. *** OpenBSD on the Xiaomi Mi Air 12.5" (https://jcs.org/2017/05/22/xiaomiair) The Xiaomi Mi Air 12.5" (https://xiaomi-mi.com/notebooks/xiaomi-mi-notebook-air-125-silver/) is a basic fanless 12.5" Ultrabook with good build quality and decent hardware specs, especially for the money: while it can usually be had for about $600, I got mine for $489 shipped to the US during a sale about a month ago. Xiaomi offers this laptop in silver and gold. They also make a 13" version but it comes with an NVidia graphics chip. Since these laptops are only sold in China, they come with a Chinese language version of Windows 10 and only one or two distributors that carry them ship to the US. Unfortunately that also means they come with practically no warranty or support. Hardware > The Mi Air 12.5" has a fanless, 6th generation (Skylake) Intel Core m3 processor, 4Gb of soldered-on RAM, and a 128Gb SATA SSD (more on that later). It has a small footprint of 11.5" wide, 8" deep, and 0.5" thick, and weighs 2.3 pounds. > A single USB-C port on the right-hand side is used to charge the laptop and provide USB connectivity. A USB-C ethernet adapter I tried worked fine in OpenBSD. Whether intentional or not, a particular design touch I appreciated was that the USB-C port is placed directly to the right of the power button on the keyboard, so you don't have to look or feel around for the port when plugging in the power cable. > A single USB 3 type-A port is also available on the right side next to the USB-C port. A full-size HDMI port and a headphone jack are on the left-hand side. It has a soldered-on Intel 8260 wireless adapter and Bluetooth. The webcam in the screen bezel attaches internally over USB. > The chassis is all aluminum and has sufficient rigidity in the keyboard area. The 12.5" 1920x1080 glossy IPS screen has a fairly small bezel and while its hinge is properly weighted to allow opening the lid with one hand (if you care about that kind of thing), the screen does have a bit of top-end wobble when open, especially when typing on another laptop on the same desk. > The keyboard has a roomy layout and a nice clicky tactile with good travel. It is backlit, but with only one backlight level. When enabled via Fn+F10 (which is handled by the EC, so no OpenBSD support required), it will automatically shut off after not typing for a short while, automatically turning back once a key is pressed. Upgrades > An interesting feature of the Mi Air is that it comes with a 128Gb SATA SSD but also includes an open PCI-e slot ready to accept an NVMe SSD. > I upgraded mine with a Samsung PM961 256Gb NVMe SSD (left), and while it is possible to run with both drives in at the same time, I removed the Samsung CM871a 128Gb SATA (right) drive to save power. > The bottom case can be removed by removing the seven visible screws, in addition to the one under the foot in the middle back of the case, which just pries off. A spudger tool is needed to release all of the plastic attachment clips along the entire edge of the bottom cover. > Unfortunately this upgrade proved to be quite time consuming due to the combination of the limited UEFI firmware on the Mi Air and a bug in OpenBSD. A Detour into UEFI Firmware Variables > Unlike a traditional BIOS where one can boot into a menu and configure the boot order as well as enabling and disabling options such as "USB Hard Drive", the InsydeH2O UEFI firmware on the Xiaomi Air only provides the ability to adjust the boot order of existing devices. Any change or addition of boot devices must be done from the operating system, which is not possible under OpenBSD. > I booted to a USB key with OpenBSD on it and manually partitioned the new NVME SSD, then rsynced all of the data over from the old drive, but the laptop would not boot to the new NVME drive, instead showing an error message that there was no bootable OS. > Eventually I figured out that the GPT table that OpenBSD created on the NVMe disk was wrong due to a [one-off bug in the nvme driver](https://github.com/openbsd/src/commit/dc8298f669ea2d7e18c8a8efea509eed200cb989) which was causing the GPT table to be one sector too large, causing the backup GPT table to be written in the wrong location (and other utilities under Linux to write it over the OpenBSD area). I'm guessing the UEFI firmware would fail to read the bad GPT table on the disk that the boot variable pointed to, then declare that disk as missing, and then remove any variables that pointed to that disk. OpenBSD Support > The Mi Air's soldered-on Intel 8260 wireless adapter is supported by OpenBSD's iwm driver, including 802.11n support. The Intel sound chip is recognized by the azalia driver. > The Synaptics touchpad is connected via I2C, but is not yet supported. I am actively hacking on my dwiic driver to make this work and the touchpad will hopefully operate as a Windows Precision Touchpad via imt so I don't have to write an entirely new Synaptics driver. > Unfortunately since OpenBSD's inteldrm support that is ported from Linux is lagging quite a bit behind, there is no kernel support for Skylake and Kaby Lake video chips. Xorg works at 1920x1080 through efifb so the machine is at least usable, but X is not very fast and there is a noticeable delay when doing certain redrawing operations in xterm. Screen backlight can be adjusted through my OpenBSD port of intel_backlight. Since there is no hardware graphics support, this also means that suspend and resume do not work because nothing is available to re-POST the video after resume. Having to use efifb also makes it impossible to adjust the screen gamma, so for me, I can't use redshift for comfortable night-time hacking. Flaws > Especially taking into account the cheap price of the laptop, it's hard to find faults with the design. One minor gripe is that the edges of the case along the bottom are quite sharp, so when carrying the closed laptop, it can feel uncomfortable in one's hands. > While all of those things could be overlooked, unfortunately there is also a critical flaw in the rollover support in the keyboard/EC on the laptop. When typing certain combinations of keys quickly, such as holding Shift and typing "NULL", one's fingers may actually hold down the Shift, N, and U keys at the same time for a very brief moment before releasing N. Normally the keyboard/EC would recognize U being pressed after N is already down and send an interrupt for the U key. Unfortunately on this laptop, particular combinations of three keys do not interrupt for the third key at all until the second key is lifted, usually causing the third key not to register at all if typed quickly. I've been able to reproduce this problem in OpenBSD, Linux, and Windows, with the combinations of at least Shift+N+U and Shift+D+F. Holding Shift and typing the two characters in sequence quickly enough will usually fail to register the final character. Trying the combinations without Shift, using Control or Alt instead of Shift, or other character pairs does not trigger the problem. This might be a problem in the firmware on the Embedded Controller, or a defect in the keyboard circuitry itself. As I mentioned at the beginning, getting technical support for this machine is difficult because it's only sold in China. Docker on OpenBSD 6.1-current (https://medium.com/@dave_voutila/docker-on-openbsd-6-1-current-c620513b8110) Dave Voutila writes: So here's the thing. I'm normally a macOS user…all my hardware was designed in Cupertino, built in China. But I'm restless and have been toying with trying to switch my daily machine over to a non-macOS system sort of just for fun. I find Linux messy, FreeBSD not as Apple-laptop-friendly as it should be, and Windows a non-starter. Luckily, I found a friend in Puffy. Switching some of my Apple machines over to dual-boot OpenBSD left a gaping hole in my workflow. Luckily, all the hard work the OpenBSD team has done over the last year seems to have plugged it nicely! OpenBSD's hypervisor support officially made it into the 6.1 release, but after some experimentation it was rather time consuming and too fragile to get a Linux guest up and running (i.e. basically the per-requisite for Docker). Others had reported some success starting with QEMU and doing lots of tinkering, but after a wasted evening I figured I'd grab the latest OpenBSD snapshot and try what the openbsd-misc list suggested was improved Linux support in active development. 10 (11) Steps to docker are provided Step 0 — Install the latest OpenBSD 6.1 snapshot (-current) Step 1 — Configure VMM/VMD Step 2 — Grab an Alpine Linux ISO Step 3 — Make a new virtual disk image Step 4 — Boot Alpine's ISO Step 5 — Inhale that fresh Alpine air Step 6 — Boot Alpine for Reals Step 7 — Install Docker Step 8 — Make a User Step 9 — Ditch the Serial Console Step 10 — Test out your Docker instance I haven't done it yet, but I plan on installing docker-compose via Python's pip package manager. I prefer defining containers in the compose files. PostgreSQL + ZFS Best Practices and Standard Procedures (https://people.freebsd.org/~seanc/postgresql/scale15x-2017-postgresql_zfs_best_practices.pdf) Slides from Sean Chittenden's talk about PostgreSQL and ZFS at Scale 15x this spring Slides start with a good overview of Postgres and ZFS, and how to use them together To start, it walks through the basics of how PostgreSQL interacts with the filesystem (any filesystem) Then it shows the steps to take a good backup of PostgreSQL, then how to do it even better with ZFS Then an intro to ZFS, and how Copy-on-Write changes host PostgreSQL interacts with the filesystem Overview of how ZFS works ZFS Tuning tips: Compression, Recordsize, atime, when to use mostly ARC vs sharedbuffer, plus pgrepack Followed by a discussion of the reliability of SSDs, and their Bit Error Rate (BER) A good SSD has a 4%/year chance of returning the wrong data. A cheap SSD 34% If you put 20 SSDs in a database server, that means 58% (Good SSDs) to 99.975% (Lowest quality commercially viable SSD) chance of an error per year Luckily, ZFS can detect and correct these errors This applies to all storage, not just SSDs, every device fails More Advice: Use quotas and reservations to avoid running out of space Schedule Periodic Scrubs One dataset per database Backups: Live demo of rm -rf'ing the database and getting it back Using clones to test upgrades on real data Naming Conventions: Use a short prefix not on the root filesystem (e.g. /db) Encode the PostgreSQL major version into the dataset name Give each PostgreSQL cluster its own dataset (e.g. pgdb01) Optional but recommended: one database per cluster Optional but recommended: one app per database Optional but recommended: encode environment into DB name Optional but recommended: encode environment into DB username using ZFS Replication Check out the full detailed PDF and implement a similar setup for your database needs *** News Roundup TrueOS Evolving Its "Stable" Release Cycle (https://www.trueos.org/blog/housekeeping-update-infrastructure-trueos-changes/) TrueOS is reformulating its Stable branch based on feedback from users. The goal is to have a “release” of the stable branch every 6 months, for those who do not want to live on the edge with the rapid updates of the full rolling release Most of the TrueOS developers work for iX Systems in their Tennessee office. Last month, the Tennessee office was moved to a different location across town. As part of the move, we need to move all our servers. We're still getting some of the infrastructure sorted before moving the servers, so please bear with us as we continue this process. As we've continued working on TrueOS, we've heard a significant portion of the community asking for a more stable “STABLE” release of TrueOS, maybe something akin to an old PC-BSD version release. In order to meet that need, we're redefining the TrueOS STABLE branch a bit. STABLE releases are now expected to follow a six month schedule, with more testing and lots of polish between releases. This gives users the option to step back a little from the “cutting edge” of development, but still enjoy many of the benefits of the “rolling release” style and the useful elements of FreeBSD Current. Critical updates like emergency patches and utility bug fixes are still expected to be pushed to STABLE on a case-by-case basis, but again with more testing and polish. This also applies to version updates of the Lumina and SysAdm projects. New, released work from those projects will be tested and added to STABLE outside the 6 month window as well. The UNSTABLE branch continues to be our experimental “cutting edge” track, and users who want to follow along with our development and help us or FreeBSD test new features are still encouraged to follow the UNSTABLE track by checking that setting in their TrueOS Update Manager. With boot environments, it will be easy to switch back and forth, so you can have the best of both worlds. Use the latest bleeding edge features, but knowing you can fall back to the stable branch with just a reboot As TrueOS evolves, it is becoming clearer that one role of the system is to function as a “test platform” for FreeBSD. In order to better serve this role, TrueOS will support both OpenRC and the FreeBSD RC init systems, giving users the choice to use either system. While the full functionality isn't quite ready for the next STABLE update, it is planned for addition after the last bit of work and testing is complete. Stay tuned for an upcoming blog post with all the details of this change, along with instructions how to switch between RC and OpenRC. This is the most important change for me. I used TrueOS as an easy way to run the latest version of -CURRENT on my laptop, to use it as a user, but also to do development. When TrueOS deviates from FreeBSD too much, it lessens the power of my expertise, and complicates development and debugging. Being able to switch back to RC, even if it takes another minute to boot, will bring TrueOS back to being FreeBSD + GUI and more by default, instead of a science project. We need both of those things, so having the option, while more work for the TrueOS team, I think will be better for the entire community *** Logical Domains on SunFire T2000 with OpenBSD/sparc64 (http://www.h-i-r.net/2017/05/logical-domains-on-sunfire-t2000-with.html) A couple of years ago, I picked up a Sun Fire T2000. This is a 2U rack mount server. Mine came with four 146GB SAS drives, a 32-core UltraSPARC T1 CPU and 32GB of RAM. Sun Microsystems incorporated Logical Domains (LDOMs) on this class of hardware. You don't often need 32 threads and 32GB of RAM in a single server. LDOMs are a kind of virtualization technology that's a bit closer to bare metal than vmm, Hyper-V, VirtualBox or even Xen. It works a bit like Xen, though. You can allocate processor, memory, storage and other resources to virtual servers on-board, with a blend of firmware that supports the hardware allocation, and some software in userland (on the so-called primary or control domain, similar to Xen DomU) to control it. LDOMs are similar to what IBM calls Logical Partitions (LPARs) on its Mainframe and POWER series computers. My day job from 2006-2010 involved working with both of these virtualization technologies, and I've kind of missed it. While upgrading OpenBSD to 6.1 on my T2000, I decided to delve into LDOM support under OpenBSD. This was pretty easy to do, but let's walk through it Resources: The ldomctl(8) man page (http://man.openbsd.org/OpenBSD-current/man8/sparc64/ldomctl.8) tedu@'s write-up on Flak (for a different class of server) (http://www.tedunangst.com/flak/post/OpenBSD-on-a-Sun-T5120) A Google+ post by bmercer@ (https://plus.google.com/101694200911870273983/posts/jWh4rMKVq97) Once you get comfortable with the fact that there's a little-tiny computer (the ALOM) powered by VXWorks inside that's acting as the management system and console (there's no screen or keyboard/mouse input), Installing OpenBSD on the base server is pretty straightforward. The serial console is an RJ-45 jack, and, yes, the ubiquitous blue-colored serial console cables you find for certain kinds of popular routers will work fine. OpenBSD installs quite easily, with the same installer you find on amd64 and i386. I chose to install to /dev/sd0, the first SAS drive only, leaving the others unused. It's possible to set them up in a hardware RAID configuration using tools available only under Solaris, or use softraid(4) on OpenBSD, but I didn't do this. I set up the primary LDOM to use the first ethernet port, em0. I decided I wanted to bridge the logical domains to the second ethernet port. You could also use a bridge and vether interface, with pf and dhcpd to create a NAT environment, similar to how I networked the vmm(4) systems. Create an LDOM configuration file. You can put this anywhere that's convenient. All of this stuff was in a "vm" subdirectory of my home. I called it ldom.conf: domain primary { vcpu 8 memory 8G } domain puffy { vcpu 8 memory 4G vdisk "/home/axon/vm/ldom1" vnet } Make as many disk images as you want, and make as many additional domain clauses as you wish. Be mindful of system resources. I couldn't actually allocate a full 32GB of RAM across all the LDOMs I eventually provisioned seven LDOMs (in addition to the primary) on the T2000, each with 3GB of RAM and 4 vcpu cores. If you get creative with use of network interfaces, virtual ethernet, bridges and pf rules, you can run a pretty complex environment on a single chassis, with services that are only exposed to other VMs, a DMZ segment, and the internal LAN. A nice tutorial, and an interesting look at an alternative platform that was ahead of its time *** documentation is thoroughly hard (http://www.tedunangst.com/flak/post/documentation-is-thoroughly-hard) Ted Unangst has a new post this week about documentation: Documentation is good, so therefore more documentation must be better, right? A few examples where things may have gotten out of control A fine example is the old OpenBSD install instructions. Once you've installed OpenBSD once or twice, the process is quite simple, but you'd never know this based on reading the instructions. Compare the files for 4.8 INSTALL and 5.8 INSTALL. Both begin with a brief intro to the project. Then 4.8 has an enormous list of mirrors, which seems fairly redundant if you've already found the install file. Followed by an enormous list of every supported variant of every supported device. Including a table of IO port configurations for ISA devices. Finally, after 1600 lines of introduction we get to the actual installation instructions. (Compared to line 231 for 5.8.) This includes a full page of text about how to install from tape, which nobody ever does. It took some time to recognize that all this documentation was actually an impediment to new users. Attempting to answer every possible question floods the reader with information for questions they were never planning to ask. Part of the problem is how the information is organized. Theoretically it makes sense to list supported hardware before instructions. After all, you can't install anything if it's not supported, right? I'm sure that was considered when the device list was originally inserted above the install instructions. But as a practical matter, consulting a device list is neither the easiest nor fastest way to determine what actually works. In the FreeBSD docs tree, we have been doing a facelift project, trying to add ‘quick start' sections to each chapter to let you get to the more important information first. It is also helpful to move data in the forms of lists and tables to appendices or similar, where they can easily be references, but are not blocking your way to the information you are actually hunting for An example of nerdview signage (http://languagelog.ldc.upenn.edu/nll/?p=29866). “They have in effect provided a sign that will tell you exactly what the question is provided you can already supply the answer.” That is, the logical minds of technical people often decide to order information in an order that makes sense to them, rather than in the order that will be most useful to the reader In the end, I think “copy diskimage to USB and follow prompts” is all the instructions one should need, but it's hard to overcome the unease of actually making the jump. What if somebody is confused or uncertain? Why is this paragraph more redundant than that paragraph? (And if we delete both, are we cutting too much?) Sometimes we don't need to delete the information. Just hide it. The instructions to upgrade to 4.8 and upgrade to 5.8 are very similar, with a few differences because every release is a little bit different. The pages look very different, however, because the not at all recommended kernel free procedure, which takes up half the page, has been hidden from view behind some javascript and only expanded on demand. A casual browser will find the page and figure the upgrade process will be easy, as opposed to some long ordeal. This is important as well, it was my original motivation for working on the FreeBSD Handbook's ZFS chapter. The very first section of the chapter was the custom kernel configuration required to run ZFS on i386. That scared many users away. I moved that to the very end, and started with why you might want to use ZFS. Much more approachable. Sometimes it's just a tiny detail that's overspecified. The apmd manual used to explain exactly which CPU idle time thresholds were used to adjust frequency. Those parameters, and the algorithm itself, were adjusted occasionally in response to user feedback, but sometimes the man page lagged behind. The numbers are of no use to a user. They're not adjustable without recompiling. Knowing that the frequency would be reduced at 85% idle vs 90% idle doesn't really offer much guidance as to whether to enable auto scaling or not. Deleting this detail ensured the man page was always correct and spares the user the cognitive load of trying to solve an unnecessary math problem. For fun: For another humorous example, it was recently observed that the deja-dup package provides man page translations for Australia, Canada, and Great Britain. I checked, the pages are in fact not quite identical. Some contain typo fixes that didn't propagate to other translations. Project idea: attempt to identify which country has the most users, or most fastidious users, by bug fixes to localized man pages. lldb on BeagleBone Black (https://lists.freebsd.org/pipermail/freebsd-arm/2017-May/016260.html) I reliably managed to build (lldb + clang/lld) from the svn trunk of LLVM 5.0.0 on my Beaglebone Black running the latest snapshot (May 20th) of FreeBSD 12.0-CURRENT, and the lldb is working very well, and this includes single stepping and ncurses-GUI mode, while single stepping with the latest lldb 4.0.1 from the ports does not work. In order to reliably build LLVM 5.0.0 (svn), I set up a 1 GB swap partition for the BBB on a NFSv4 share on a FreeBSD fileserver in my network - I put a howto of the procedure on my BLog: https://obsigna.net/?p=659 The prerequesites on the Beaglebone are: ``` pkg install tmux pkg install cmake pkg install python pkg install libxml2 pkg install swig30 pkg install ninja pkg install subversion ``` On the FreeBSD fileserver: ``` /pathtothe/bbb_share svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd llvm/tools svn co http://llvm.org/svn/llvm-project/cfe/trunk clang svn co http://llvm.org/svn/llvm-project/lld/trunk lld svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb ``` + On the Beaglebone Black: # mount_nfs -o noatime,readahead=4,intr,soft,nfsv4 server:/path_to_the/bbb_share /mnt # cd /mnt # mkdir build # cmake -DLLVM_TARGETS_TO_BUILD="ARM" -DCMAKE_BUILD_TYPE="MinSizeRel" -DLLVM_PARALLEL_COMPILE_JOBS="1" -DLLVM_PARALLEL_LINK_JOBS="1" -G Ninja .. I execute the actual build command from within a tmux session, so I may disconnect during the quite long (40 h) build: ``` tmux new "ninja lldb install" ``` When debugging in GUI mode using the newly build lldb 5.0.0-svn, I see only a minor issue, namely UTF8 strings are not displayed correctly. This happens in the ncurses-GUI only, and this is an ARM issue, since it does not occur on x86 machines. Perhaps this might be related to the signed/unsigned char mismatch between ARM and x86. Beastie Bits Triangle BSD Meetup on June 27th (https://www.meetup.com/Triangle-BSD-Users-Group/events/240247251/) Support for Controller Area Networks (CAN) in NetBSD (http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20170521_0113.html) Notes from Monday's meeting (http://mailman.uk.freebsd.org/pipermail/ukfreebsd/2017-May/014104.html) RunBSD - A site about the BSD family of operating systems (http://runbsd.info/) BSDCam(bridge) 2017 Travel Grant Application Now Open (https://www.freebsdfoundation.org/blog/bsdcam-2017-travel-grant-application-now-open/) New BSDMag has been released (https://bsdmag.org/download/nearly-online-zpool-switching-two-freebsd-machines/) *** Feedback/Questions Philipp - A show about byhve (http://dpaste.com/390F9JN#wrap) Jake - byhve Support on AMD (http://dpaste.com/0DYG5BD#wrap) CY - Pledge and Capsicum (http://dpaste.com/1YVBT12#wrap) CY - OpenSSL relicense Issue (http://dpaste.com/3RSYV23#wrap) Andy - Laptops (http://dpaste.com/0MM09EX#wrap) ***

This week we have a FreeBSD Foundation development update, tell you about sprinkling in the TrueOS project, Dynamic WDS & a whole lot more! This episode was brought to you by Headlines OpenSSH Removes SSHv1 Support (http://undeadly.org/cgi?action=article&sid=20170501005206) In a series of commits starting here (http://marc.info/?l=openbsd-cvs&m=149359384905651&w=2) and ending with this one (http://marc.info/?l=openbsd-cvs&m=149359530105864&w=2), Damien Miller completed the removal of all support for the now-historic SSHv1 protocol from OpenSSH (https://www.openssh.com/). The final commit message, for the commit that removes the SSHv1 related regression tests, reads: Eliminate explicit specification of protocol in tests and loops over protocol. We only support SSHv2 now. Dropping support for SSHv1 and associated ciphers that were either suspected to or known to be broken has been planned for several releases, and has been eagerly anticipated by many in the OpenBSD camp. In practical terms this means that starting with OpenBSD-current and snapshots as they will be very soon (and further down the road OpenBSD 6.2 with OpenSSH 7.6), the arcane options you used with ssh (http://man.openbsd.org/ssh) to connect to some end-of-life gear in a derelict data centre you don't want to visit anymore will no longer work and you will be forced do the reasonable thing. Upgrade. FreeBSD Foundation April 2017 Development Projects Update (https://www.freebsdfoundation.org/blog/april-2017-development-projects-update/) FreeBSD runs on many embedded boards that provide a USB target or USB On-the-Go (OTG) interface. This allows the embedded target to act as a USB device, and present one or more interfaces (USB device classes) to a USB host. That host could be running FreeBSD, Linux, Mac OS, Windows, Android, or another operating system. USB device classes include audio input or output (e.g. headphones), mass storage (USB flash drives), human interface device (keyboards, mice), communications (Ethernet adapters), and many others. The Foundation awarded a project grant to Edward Tomasz Napierała to develop a USB mass storage target driver, using the FreeBSD CAM Target Layer (CTL) as a backend. This project allows FreeBSD running on an embedded platform, such as a BeagleBone Black or Raspberry Pi Zero, to emulate a USB mass storage target, commonly known as a USB flash stick. The backing storage for the emulated mass storage target is on the embedded board's own storage media. It can be configured at runtime using the standard CTL configuration mechanism – the ctladm(8) utility, or the ctl.conf(5) file. The FreeBSD target can now present a mass storage interface, a serial interface (for a console on the embedded system), and an Ethernet interface for network access. A typical usage scenario for the mass storage interface is to provide users with documentation and drivers that can be accessed from their host system. This makes it easier for new users to interact with the embedded FreeBSD board, especially in cases where the host operating system may require drivers to access all of the functionality, as with Windows and OS X. They provide instructions on how to configure a BeagleBone Black to act as a flash memory stick attached to a host computer. +Check out the article, test, and report back your experiences with the new USB OTG interface. *** Spring cleaning: Hardware Update and Preview of upcoming TrueOS changes (https://www.trueos.org/blog/spring-cleaning-hardware-update-preview-upcoming-trueos-changes/) The much-abused TrueOS build server is experiencing some technical difficulties, slowing down building new packages and releasing updates. After some investigation, one problem seemed to be a bug with the Poudriere port building software. After updating builders to the new version, some of the instability is resolved. Thankfully, we won't have to rely on this server so much, because… We're getting new hardware! A TrueOS/Lumina contributor is donating a new(ish) server to the project. Special thanks to TrueOS contributor/developer q5sys for the awesome new hardware! Preview: UNSTABLE and Upcoming TrueOS STABLE update A fresh UNSTABLE release is dropping today, with a few key changes: Nvidia/graphics driver detection fixes. Boot environment listing fix (FreeBSD boot-loader only) Virtual box issues fixed on most systems. There appears to be a regression in VirtualBox 5.1 with some hardware. New icon themes for Lumina (Preferences -> Appearance -> Theme). Removal of legacy pc-diskmanager. It was broken and unmaintained, so it is time to remove it. Installer/.iso Changes (Available with new STABLE Update): The text installer has been removed. It was broken and unmaintained, so it is time to remove it. There is now a single TrueOS install image. You can still choose to install as either a server or desktop, but both options live in a single install image now. This image is still available as either an .iso or .img file. The size of the .iso and .img files is reduced about 500 Mb to around 2Gb total. We've removed Firefox and Thunderbird from the default desktop installation. These have been replaced with Qupzilla and Trojita. Note you can replace Qupzilla and Trojita with Firefox and Thunderbird via the SysAdm Appcafe after completing the TrueOS install. Grub is no longer an installation option. Instead, the FreeBSD boot-loader is always used for the TrueOS partition. rEFInd is used as the master boot-loader for multi-booting; EFI partitioning is required. Qpdfview is now preinstalled for pdf viewing. Included a slideshow during the installation with tips and screenshots. Interview - Patrick M. Hausen - hausen@punkt.de (mailto:hausen@punkt.de) Founder of Punkt.de HAST - Highly Available Storage (https://wiki.freebsd.org/HAST) News Roundup (finally) investigating how to get dynamic WDS (DWDS) working in FreeBSD! (http://adrianchadd.blogspot.com/2017/04/finally-investigating-how-to-get.html) Adrian Chadd writes in his blog: I sat down recently to figure out how to get dynamic WDS working on FreeBSD-HEAD. It's been in FreeBSD since forever, and it in theory should actually have just worked, but it's extremely not documented in any useful way. It's basically the same technology in earlier Apple Airports (before it grew into what the wireless tech world calls "Proxy-STA") and is what the "extender" technology on Qualcomm Atheros chipsets implement. A common question I get from people is "why can't I bridge multiple virtual machines on my laptop and have them show up over wifi? It works on ethernet!" And my response is "when I make dynamic WDS work, you can just make this work on FreeBSD devices - but for now, use NAT." That always makes people sad. + Goes on to explain that normal station/access point setups have up to three addresses and depending on the packet type, these can vary. There are a couple of variations in the addresses, which is more than the number of address fields in a normal 802.11 frame. The big note here is that there's not enough MAC addresses to say "please send this frame to a station MAC address, but then have them forward it to another MAC address attached behind it in a bridge." That would require 4 mac addresses in the 802.11 header, which we don't get. .. except we do. There's a separate address format where from-DS and to-DS bits in the header set to 1, which means "this frame is coming from distribution system to a distribution system", and it has four mac addresses. The RA is then the AP you're sending to, and then a fourth field indicates the eventual destination address that may be an ethernet device connected behind said STA. If you don't configure up WDS, then when you send frames from a station from a MAC address that isn't actually your 802.11 interface MAC address, the system would be confused. The STA wouldn't be able to transmit it easily, and the AP wouldn't know how to get back to your bridged ethernet addresses. The original WDS was a statically configured thing. [...] So for static configurations, this works great. You'd associate your extender AP as a station of the central AP, it'd use wpa_supplicant to setup encryption, then anything between that central AP and that extender AP (as a station) would be encrypted as normal station traffic (but, 4-address frame format.) But that's not very convenient. You have to statically configure everything, including telling your central AP about all of your satellite extender APs. If you want to replace your central AP, you have to reprogram all of your extenders to use the new MAC addresses. So, Sam Leffler came up with "dynamic WDS" - where you don't have to explicitly state the list of central/satellite APs. Instead, you configure a central AP as "dynamic WDS", and when a 4-address frame shows up from an associated station, it "promotes" it to a WDS peer for you. On the satellite AP, it will just find an AP to communicate to, and then assume it'll do WDS and start using 4-address frames. It's still a bit clunky (there's no beacon, probe request, etc IEs that say "I do dynamic WDS!" so you'd better make ALL your central APs a different SSID!) but it certainly is better than what we had. Firstly, there are scripts in src/tools/tools/net80211/ - setup.wdsmain and setup.wdsrelay. These scripts are .. well, the almost complete documentation on a dynamic WDS setup. The manpage doesn't go into anywhere near enough information. So I dug into it. It turns out that dynamic WDS uses a helper daemon - 'wlanwds' - which listens for dynamic WDS configuration changes and will do things for you. This is what runs on the central AP side. Then it started making sense! So far, so good. I followed that script, modified it a bit to use encryption, and .. well, it half worked. Association worked fine, but no traffic was passing. A little more digging showed the actual problem - the dynamic WDS example scripts are for an open/unencrypted network. If you are using an encrypted network, the central AP side needs to enable privacy on the virtual interfaces so traffic gets encrypted with the parent interface encryption keys. Now, I've only done enough testing to show that indeed it is working. I haven't done anything like pass lots of traffic via iperf, or have a mix of DWDS and normal STA peers, nor actually run it for longer than 5 minutes. I'm sure there will be issues to fix. However - I do need it at home, as I can't see the home AP from the upstairs room (and now you see why I care about DWDS!) and so when I start using it daily I'll fix whatever hilarity ensues. Why don't schools teach debugging? (https://danluu.com/teach-debugging/) A friend of mine and I couldn't understand why some people were having so much trouble; the material seemed like common sense. The Feynman Method was the only tool we needed. Write down the problem Think real hard Write down the solution The Feynman Method failed us on the last project: the design of a divider, a real-world-scale project an order of magnitude more complex than anything we'd been asked to tackle before. I understand now why half the class struggled with the earlier assignments. Without an explanation of how to systematically approach problems, anyone who didn't intuitively grasp the correct solution was in for a semester of frustration. People who were, like me, above average but not great, skated through most of the class and either got lucky or wasted a huge chunk of time on the final project. I've even seen people talented enough to breeze through the entire degree without ever running into a problem too big to intuitively understand; those people have a very bad time when they run into a 10 million line codebase in the real world. The more talented the engineer, the more likely they are to hit a debugging wall outside of school. It's one of the most fundamental skills in engineering: start at the symptom of a problem and trace backwards to find the source. It takes, at most, half an hour to teach the absolute basics – and even that little bit would be enough to save a significant fraction of those who wash out and switch to non-STEM majors. Why do we leave material out of classes and then fail students who can't figure out that material for themselves? Why do we make the first couple years of an engineering major some kind of hazing ritual, instead of simply teaching people what they need to know to be good engineers? For all the high-level talk about how we need to plug the leaks in our STEM education pipeline, not only are we not plugging the holes, we're proud of how fast the pipeline is leaking. FreeBSD: pNFS server for testing (https://lists.freebsd.org/pipermail/freebsd-fs/2017-April/024702.html) Rick Macklem has issued a call for testing his new pNFS server: I now have a pNFS server that I think is ready for testing/evaluation. It is basically a patched FreeBSD-current kernel plus nfsd daemon. If you are interested, some very basic notes on how it works and how to set it up are at: http://people.freebsd.org/~rmacklem/pnfs-planb-setup.txt (http://people.freebsd.org/~rmacklem/pnfs-planb-setup.txt) A Plan B pNFS service consists of a single MetaData Server (MDS) and K Data Servers (DS), all of which would be recent FreeBSD systems. Clients will mount the MDS as they would a single NFS server. When files are created, the MDS creates a file tree identical to what a single NFS server creates, except that all the regular (VREG) files will be empty. As such, if you look at the exported tree on the MDS directly on the MDS server (not via an NFS mount), the files will all be of size == 0. Each of these files will also have two extended attributes in the system attribute name space: pnfsd.dsfile - This extended attrbute stores the information that the MDS needs to find the data storage file on a DS for this file. pnfsd.dsattr - This extended attribute stores the Size, ModifyTime and Change attributes for the file. For each regular (VREG) file, the MDS creates a data storage file on one of the K DSs, in one of the dsNN directories. The name of this file is the file handle of the file on the MDS in hexadecimal. The DSs use 20 subdirectories named "ds0" to "ds19" so that no one directory gets too large. At this time, the MDS generates File Layout layouts to NFSv4.1 clients that know how to do pNFS. For NFS clients that do not support NFSv4.1 pNFS, there will be a performance hit, since the IO RPCs will be proxied by the MDS for the DS server the data storage file resides on. The current setup does not allow for redundant servers. If the MDS or any of the K DS servers fail, the entire pNFS service will be non-functional. Looking at creating mirrored DS servers is planned, but it may be a year or more before that is implemented. I am planning on using the Flex File Layout for this, since it supports client side mirroring, where the client will write to all mirrors concurrently. Beastie Bits Openbsd changes of note 620 (http://www.tedunangst.com/flak/post/openbsd-changes-of-note-620) Why Unix commands are short (http://www.catonmat.net/blog/why-unix-commands-are-short/) OPNsense 17.1.5 released (https://opnsense.org/opnsense-17-1-5-released/) Something for Apple dual-GPU users (http://lists.dragonflybsd.org/pipermail/commits/2017-April/625847.html) pkgsrcCon 2017 CFT (https://mail-index.netbsd.org/netbsd-advocacy/2017/05/01/msg000735.html) TrueOS/Lumina Dev Q&A: May 5th 2017 (https://discourse.trueos.org/t/trueos-lumina-dev-q-a-5-4-17/1347) Feedback/Questions Peter - Jails (http://dpaste.com/0J14HGJ#wrap) Andrew - Languages and University Courses (http://dpaste.com/31AVFSF#wrap) JuniorJobs (https://wiki.freebsd.org/JuniorJobs) Steve - TrueOS and Bootloader (http://dpaste.com/1BXVZSY#wrap) Ben - ZFS questions (http://dpaste.com/0R7AW2T#wrap) Steve - Linux Emulation (http://dpaste.com/3ZR7NCC#wrap)

Today on BSD Now, the latest Dragonfly BSD release, RaidZ performance, another OpenSSL Vulnerability, and more; all this week on BSD Now. This episode was brought to you by Headlines DragonFly BSD 4.8 is released (https://www.dragonflybsd.org/release48/) Improved kernel performance This release further localizes cache lines and reduces/removes cache ping-ponging on globals. For bulk builds on many-cores or multi-socket systems, we have around a 5% improvement, and certain subsystems such as namecache lookups and exec()s see massive focused improvements. See the corresponding mailing list post with details. Support for eMMC booting, and mobile and high-performance PCIe SSDs This kernel release includes support for eMMC storage as the boot device. We also sport a brand new SMP-friendly, high-performance NVMe SSD driver (PCIe SSD storage). Initial device test results are available. EFI support The installer can now create an EFI or legacy installation. Numerous adjustments have been made to userland utilities and the kernel to support EFI as a mainstream boot environment. The /boot filesystem may now be placed either in its own GPT slice, or in a DragonFly disklabel inside a GPT slice. DragonFly, by default, creates a GPT slice for all of DragonFly and places a DragonFly disklabel inside it with all the standard DFly partitions, such that the disk names are roughly the same as they would be in a legacy system. Improved graphics support The i915 driver has been updated to match the version found with the Linux 4.6 kernel. Broadwell and Skylake processor users will see improvements. Other user-affecting changes Kernel is now built using -O2. VKernels now use COW, so multiple vkernels can share one disk image. powerd() is now sensitive to time and temperature changes. Non-boot-filesystem kernel modules can be loaded in rc.conf instead of loader.conf. *** #8005 poor performance of 1MB writes on certain RAID-Z configurations (https://github.com/openzfs/openzfs/pull/321) Matt Ahrens posts a new patch for OpenZFS Background: RAID-Z requires that space be allocated in multiples of P+1 sectors,because this is the minimum size block that can have the required amount of parity. Thus blocks on RAIDZ1 must be allocated in a multiple of 2 sectors; on RAIDZ2 multiple of 3; and on RAIDZ3 multiple of 4. A sector is a unit of 2^ashift bytes, typically 512B or 4KB. To satisfy this constraint, the allocation size is rounded up to the proper multiple, resulting in up to 3 "pad sectors" at the end of some blocks. The contents of these pad sectors are not used, so we do not need to read or write these sectors. However, some storage hardware performs much worse (around 1/2 as fast) on mostly-contiguous writes when there are small gaps of non-overwritten data between the writes. Therefore, ZFS creates "optional" zio's when writing RAID-Z blocks that include pad sectors. If writing a pad sector will fill the gap between two (required) writes, we will issue the optional zio, thus doubling performance. The gap-filling performance improvement was introduced in July 2009. Writing the optional zio is done by the io aggregation code in vdevqueue.c. The problem is that it is also subject to the limit on the size of aggregate writes, zfsvdevaggregationlimit, which is by default 128KB. For a given block, if the amount of data plus padding written to a leaf device exceeds zfsvdevaggregation_limit, the optional zio will not be written, resulting in a ~2x performance degradation. The solution is to aggregate optional zio's regardless of the aggregation size limit. As you can see from the graphs, this can make a large difference in performance. I encourage you to read the entire commit message, it is well written and very detailed. *** Can you spot the OpenSSL vulnerability (https://guidovranken.wordpress.com/2017/01/28/can-you-spot-the-vulnerability/) This code was introduced in OpenSSL 1.1.0d, which was released a couple of days ago. This is in the server SSL code, ssl/statem/statemsrvr.c, sslbytestocipherlist()), and can easily be reached remotely. Can you spot the vulnerability? So there is a loop, and within that loop we have an ‘if' statement, that tests a number of conditions. If any of those conditions fail, OPENSSLfree(raw) is called. But raw isn't the address that was allocated; raw is increment every loop. Hence, there is a remote invalid free vulnerability. But not quite. None of those checks in the ‘if' statement can actually fail; earlier on in the function, there is a check that verifies that the packet contains at least 1 byte, so PACKETget1 cannot fail. Furthermore, earlier in the function it is verified that the packet length is a multiple of 3, hence PACKETcopybytes and PACKET_forward cannot fail. So, does the code do what the original author thought, or expected it to do? But what about the next person that modifies that code, maybe changing or removing one of the earlier checks, allowing one of those if conditions to fail, and execute the bad code? Nonetheless OpenSSL has acknowledged that the OPENSSL_free line needs a rewrite: Pull Request #2312 (https://github.com/openssl/openssl/pull/2312) PS I'm not posting this to ridicule the OpenSSL project or their programming skills. I just like reading code and finding corner cases that impact security, which is an effort that ultimately works in everybody's best interest, and I like to share what I find. Programming is a very difficult enterprise and everybody makes mistakes. Thanks to Guido Vranken for the sharp eye and the blog post *** Research Debt (http://distill.pub/2017/research-debt/) I found this article interesting as it relates to not just research, but a lot of technical areas in general Achieving a research-level understanding of most topics is like climbing a mountain. Aspiring researchers must struggle to understand vast bodies of work that came before them, to learn techniques, and to gain intuition. Upon reaching the top, the new researcher begins doing novel work, throwing new stones onto the top of the mountain and making it a little taller for whoever comes next. People expect the climb to be hard. It reflects the tremendous progress and cumulative effort that's gone into the research. The climb is seen as an intellectual pilgrimage, the labor a rite of passage. But the climb could be massively easier. It's entirely possible to build paths and staircases into these mountains. The climb isn't something to be proud of. The climb isn't progress: the climb is a mountain of debt. Programmers talk about technical debt: there are ways to write software that are faster in the short run but problematic in the long run. Poor Exposition – Often, there is no good explanation of important ideas and one has to struggle to understand them. This problem is so pervasive that we take it for granted and don't appreciate how much better things could be. Undigested Ideas – Most ideas start off rough and hard to understand. They become radically easier as we polish them, developing the right analogies, language, and ways of thinking. Bad abstractions and notation – Abstractions and notation are the user interface of research, shaping how we think and communicate. Unfortunately, we often get stuck with the first formalisms to develop even when they're bad. For example, an object with extra electrons is negative, and pi is wrong Noise – Being a researcher is like standing in the middle of a construction site. Countless papers scream for your attention and there's no easy way to filter or summarize them. We think noise is the main way experts experience research debt. There's a tradeoff between the energy put into explaining an idea, and the energy needed to understand it. On one extreme, the explainer can painstakingly craft a beautiful explanation, leading their audience to understanding without even realizing it could have been difficult. On the other extreme, the explainer can do the absolute minimum and abandon their audience to struggle. This energy is called interpretive labor Research distillation is the opposite of research debt. It can be incredibly satisfying, combining deep scientific understanding, empathy, and design to do justice to our research and lay bare beautiful insights. Distillation is also hard. It's tempting to think of explaining an idea as just putting a layer of polish on it, but good explanations often involve transforming the idea. This kind of refinement of an idea can take just as much effort and deep understanding as the initial discovery. + The distillation can often times require an entirely different set of skills than the original creation of the idea. Almost all of the BSD projects have some great ideas or subsystems that just need distillation into easy to understand and use platforms or tools. Like the theoretician, the experimentalist or the research engineer, the research distiller is an integral role for a healthy research community. Right now, almost no one is filling it. Anyway, if that bit piqued your interest, go read the full article and the suggested further reading. *** News Roundup And then the murders began. (https://blather.michaelwlucas.com/archives/2902) A whole bunch of people have pointed me at articles like this one (http://thehookmag.com/2017/03/adding-murders-began-second-sentence-book-makes-instantly-better-125462/), which claim that you can improve almost any book by making the second sentence “And then the murders began.” It's entirely possible they're correct. But let's check, with a sampling of books. As different books come in different tenses and have different voices, I've made some minor changes. “Welcome to Cisco Routers for the Desperate! And then the murders begin.” — Cisco Routers for the Desperate, 2nd ed “Over the last ten years, OpenSSH has become the standard tool for remote management of Unix-like systems and many network devices. And then the murders began.” — SSH Mastery “The Z File System, or ZFS, is a complicated beast, but it is also the most powerful tool in a sysadmin's Batman-esque utility belt. And then the murders begin.” — FreeBSD Mastery: Advanced ZFS “Blood shall rain from the sky, and great shall be the lamentation of the Linux fans. And then, the murders will begin.” — Absolute FreeBSD, 3rd Ed Netdata now supports FreeBSD (https://github.com/firehol/netdata) netdata is a system for distributed real-time performance and health monitoring. It provides unparalleled insights, in real-time, of everything happening on the system it runs (including applications such as web and database servers), using modern interactive web dashboards. From the release notes: apps.plugin ported for FreeBSD Check out their demo sites (https://github.com/firehol/netdata/wiki) *** Distrowatch Weekly reviews RaspBSD (https://distrowatch.com/weekly.php?issue=20170220#raspbsd) RaspBSD is a FreeBSD-based project which strives to create a custom build of FreeBSD for single board and hobbyist computers. RaspBSD takes a recent snapshot of FreeBSD and adds on additional components, such as the LXDE desktop and a few graphical applications. The RaspBSD project currently has live images for Raspberry Pi devices, the Banana Pi, Pine64 and BeagleBone Black & Green computers. The default RaspBSD system is quite minimal, running a mere 16 processes when I was logged in. In the background the operating system runs cron, OpenSSH, syslog and the powerd power management service. Other than the user's shell and terminals, nothing else is running. This means RaspBSD uses little memory, requiring just 16MB of active memory and 31MB of wired or kernel memory. I made note of a few practical differences between running RaspBSD on the Pi verses my usual Raspbian operating system. One minor difference is RaspBSD turns off the Pi's external power light after booting. Raspbian leaves the light on. This means it looks like the Pi is off when it is running RaspBSD, but it also saves a little electricity. Conclusions: Apart from these little differences, running RaspBSD on the Pi was a very similar experience to running Raspbian and my time with the operating system was pleasantly trouble-free. Long-term, I think applying source updates to the base system might be tedious and SD disk operations were slow. However, the Pi usually is not utilized for its speed, but rather its low cost and low-energy usage. For people who are looking for a small home server or very minimal desktop box, RaspBSD running on the Pi should be suitable. Research UNIX V8, V9 and V10 made public by Alcatel-Lucent (https://media-bell-labs-com.s3.amazonaws.com/pages/20170327_1602/statement%20regarding%20Unix%203-7-17.pdf) Alcatel-Lucent USA Inc. (“ALU-USA”), on behalf of itself and Nokia Bell Laboratories agrees, to the extent of its ability to do so, that it will not assert its copyright rights with respect to any non-commercial copying, distribution, performance, display or creation of derivative works of Research Unix®1 Editions 8, 9, and 10. Research Unix is a term used to refer to versions of the Unix operating system for DEC PDP-7, PDP-11, VAX and Interdata 7/32 and 8/32 computers, developed in the Bell Labs Computing Science Research Center. The version breakdown can be viewed on its Wikipedia page (https://en.wikipedia.org/wiki/Research_Unix) It only took 30+ years, but now they're public You can grab them from here (http://www.tuhs.org/Archive/Distributions/Research/) If you're wondering what happened with Research Unix, After Version 10, Unix development at Bell Labs was stopped in favor of a successor system, Plan 9 (http://plan9.bell-labs.com/plan9/); which itself was succeeded by Inferno (http://www.vitanuova.com/inferno/). *** Beastie Bits The BSD Family Tree (https://github.com/freebsd/freebsd/blob/master/share/misc/bsd-family-tree) Unix Permissions Calculator (http://permissions-calculator.org/) NAS4Free release 11.0.0.4 now available (https://sourceforge.net/projects/nas4free/files/NAS4Free-11.0.0.4/11.0.0.4.4141/) Another BSD Mag released for free downloads (https://bsdmag.org/download/simple-quorum-drive-freebsd-ctl-ha-beast-storage-system/) OPNsense 17.1.4 released (https://forum.opnsense.org/index.php?topic=4898.msg19359) *** Feedback/Questions gozes asks via twitter about how get involved in FreeBSD (https://twitter.com/gozes/status/846779901738991620) ***

George and Jeremy bring all of the Microcontroller knowledge together to a practical application as they break down the building of the Sierra Radio Systems Bay-Net Repeater Groups Remote Site Monitoring System. Yaesu Announces two new Handhelds FT-25R - http://www.yaesu.com/indexVS.cfm?cmd=DisplayProducts&ProdCatID=111&encProdID=79E6683CC766565D2CB197C293AB6219&DivisionID=65&isArchived=0 FT-65R - http://www.yaesu.com/indexVS.cfm?cmd=DisplayProducts&ProdCatID=111&encProdID=82DE38083B3DFC155A6A472F7FEFA8C7&DivisionID=65&isArchived=0 RTL-SDR.com AM/FM Broadcast Band High Pass Filter – http://www.rtl-sdr.com/rtl-sdr-com-broadcast-block-high-pass-filter-now-sale/ Prebuilt Raspberry Pi Image for using an RTL-SDR as a receive iGate - http://www.rtl-sdr.com/a-pre-built-raspberry-pi-image-for-using-an-rtl-sdr-as-an-aprs-rx-igate/ KF7IJZ AGM / Bioenno LiFePO4 / NEC LiFePO4 Battery Comparison – https://youtu.be/psjQ-FT6KY0 Bay-Net articles - http://www.bay-net.org/articles.html Dupont Connectors - http://amzn.to/2lffzq0 Special Crimp Tool-Dupont Connector - http://amzn.to/2l3WBk0 Visit our Antenna Analyzer Forum for updates and hacks - http://hamradio360.com/community/main-forum/ Sierra Radio Systems – http://www.sierraradio.net/ Cactus Intertie – http://www.cactus-intertie.org/ Beagle Bone Black – https://beagleboard.org/black-wireless Wavenode – http://www.wavenode.com/  

Hosts: Parker Dillmann Stephen Kraig Guests: N/A Figure 1: SSPS front panel test layout. Miniature version of the real front panel to test physical placement and new parts. Figure 2: Two TPS65982-EVM booster packs. One is powering the other over USB Type-C. Parker was able to pull 20V @ 3.2A before his Re:load Pro overheated. Podcast Notes Stephen is now almost done with the FX Development Board's final layout and enclosure design. He is also working on a new version of his drop in replacement for opamps that will use a dual stacked PCB. Parker finished the test panel for the SSPS. See Figure 1. Has all the critical spacing and parts on the board for testing. Parker wants to make sure everything fits before running the full sized version. A listener recommended we change the name to the Super Sophisticated Power Supply. Stephen thinks the Super Superfluous Power Supply sounds awesome. The TPS65982-EVMs are working great. Parker is doing loads of research into USB Type-C. He is currently waiting to hear back from Texas Instruments on getting a "USB2MANY" adapter board. Which is mentioned in the TPS6598x Utilities Tool User Guide. See Figure 2. Parker is using his Re:load Pro to test power transfer. Parker and Stephen want to build a cheap data logger for just voltage and current. These devices exist but it will be a good practice in cost reduction and layout design. Fairchild makes a $16 "flexible and compact solution for a blinking or breathing LED indicator". Part number FAN5646S701X. Parker and Stephen think its a bit ridiculous to have a part this expensive and all it does it blink a LED in a fancy way. Octavo Systems has introduced a new "System-in-Package" which is basically multiple ICs into a single package. The OSD3358-512M-BAS is basically a Beagle Bone Black in one IC package. With this new IC Jason Kridner is working on the PocketBone which is a 2-Layer PCB that is only 2.17" by 1.38" that is a full fledge 1GHz Linux computer. Special thanks to whixr over at Tymkrs for the intro and outro theme!

Materials Available here:https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Phil-Polstra-Hacker-in-the-Wires.pdf Extras here: https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Phil-Polstra-Extras.rar Hacker in the Wires Dr. Phil Polstra Professor, Bloomsburg University Additional Materials available here: https://media.defcon.org/DEF CON 23/DEF CON 23 presentations/Phil Polstra/Extras/ This talk will show attendees how to use a small ARM-based computer that is connected inline to a wired network for penetration testing. The computer is running a full-featured penetration testing Linux distro. Data may be exfiltrated using the network or via a ZigBee mesh network or GSM modem. The device discussed in this talk is easily integrated into a powerful penetration test that is performed with an army of ARM-based small computer systems connected by XBee or ZigBee mesh networking. Some familiarity with Linux and penetration testing would be helpful, but not required. Phil was born at an early age. He cleaned out his savings at age 8 in order to buy a TI99-4A computer for the sum of $450. Two years later he learned 6502 assembly and has been hacking computers and electronics ever since. Dr. Phil currently works as a professor at Bloomsburg University of Pennsylvania. His research focus over the last few years has been on the use of microcontrollers and small embedded computers for forensics and pentesting. Phil has developed a custom pentesting Linux distro and related hardware to allow an inexpensive army of remote pentesting drones to be built using the BeagleBone Black computer boards. This work is described in detail in Phil's book "Hacking and Penetration Testing With Low Power Devices" (Syngress, 2015). Prior to entering academia, Phil held several high level positions at well-known US companies. He holds a couple of the usual certs one might expect for someone in his position. When not working, he likes to spend time with his family, fly, hack electronics, and has been known to build airplanes. Twitter: @ppolstra http://facebook.com/ppolstra

Materials Available here:https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Phil-Polstra-One-device-to-Pwn-them-all.pdf One Device to Pwn Them All Dr. Phil Polstra Professor, Bloomsburg University This talk will present a device that can be used as a dropbox, remote hacking drone, hacking command console, USB writeblocker, USB Mass Storage device impersonator, or scripted USB HID device. The device is based on the BeagleBone Black, can be battery operated for several days, and is easily constructed for under $100. The dropbox, remote hacking drone, and hacking command console functionality were presented at DEF CON 21. This talk will emphasize the new USB-based attack functionality. Topics will include injecting payloads by emulating an optionally write-protected USB mass storage device, rapidly executing commands on a target using the BeagleBone Black operating as a scripted USB HID device, USB mass storage device impersonation, and other attacks that can be performed with brief physical access to the target. Some familiarity with Linux and USB devices would be helpful, but not required. All hardware and software to be discussed is 100% open source. Phil was born at an early age. He cleaned out his savings at age 8 in order to buy a TI99-4A computer for the sum of $450. Two years later he learned 6502 assembly and has been hacking computers and electronics ever since. Dr. Phil currently works as a professor at Bloomsburg University of Pennsylvania. His research focus over the last few years has been on the use of microcontrollers and small embedded computers for forensics and pentesting. Phil has developed a custom pentesting Linux distro and related hardware to allow an inexpensive army of remote pentesting drones to be built using the BeagleBone Black computer boards. This work is described in detail in Phil's book "Hacking and Penetration Testing With Low Power Devices" (Syngress, 2015). Prior to entering academia, Phil held several high level positions at well-known US companies. He holds a couple of the usual certs one might expect for someone in his position. When not working, he likes to spend time with his family, fly, hack electronics, and has been known to build airplanes.

BeagleBone's Jason Kridner (@Jadon) returns to tell us about his new book. Jason co-authored a new book: BeagleBone Cookbook: Software and Hardware Problems and Solutions (or at O'Reilly). His older book is Bad to the Bone: Crafting Electronics Systems with Beaglebone and BeagleBone Black. Previous Embedded.fm episode 60: Fun Things You Can Make out of Beagles BeagleBoard.org's Google Summer of Code page (including BeagleSat and underwater drones!) Some information about putting Xenomai on a BeagleBone Black for real time response. Chris mentioned Brillo, an alternative Google supported OS that isn't on the BBB. Project Ara: an open source smartphone Ardupilot: Autonomous drone piloting.  Dronecode: Drones in Linux OpenROV: Underwater vehicles Mars lander Beagle 2 (the Apollo 11 Lunar Module was the Eagle despite some comical confusion). [UPDATE: Listener Mark Stevens pointed out that the Apollo 10 Lunar Module was named Snoopy who was a beagle.] TI's E2E Forums BeagleBone Green

Starring:Host: Robbie FergusonCo-Host: Sasha Dirmeitis Our viewer, alphaomega, wanted to know how to move a WordPress site, so we'll show you! Whether you have administrator access or not, we'll take two different approaches to this surprisingly easy task. Also, Dennis Kelley visited Penguicon in Michigan and had a chat with Jason Kridner about the BeagleBone Black. Read the complete show notes, comment or rate this episode, view pictures and obtain links from this episode at https://category5.tv/shows/technology/episode/397/ Running time: 1 Hour 1 Minute 17 Seconds

Slides here: https://defcon.org/images/defcon-22/dc-22-presentations/Polstra/DEFCON-22-Phil-Polstra-Am-I-Being-Spied-On.pdf Am I Being Spied On? Low-tech Ways Of Detecting High-tech Surveillance Dr. Phil Polstra ASSOCIATE PROFESSOR OF DIGITAL FORENSICS, BLOOMSBURG UNIVERSITY OF PENNSYLVANIA Is someone spying on you? This talk will present several low-tech ways that you can detect even high-tech surveillance. Topics covered will include: detecting surveillance cameras with your cell phone, signs that you are under physical surveillance, detecting active and passive bugs with low cost devices, and detecting devices implanted inside computers, tablets, and cell phones. Phil was born at an early age. He cleaned out his savings at age 8 in order to buy a TI99-4A computer for the sum of $450. Two years later he learned 6502 assembly and has been hacking computers and electronics ever since. Dr. Phil currently works as a professor of digital forensics. His research focus over the last few years has been on the use of microcontrollers and small embedded computers for forensics and pentesting. Phil has developed a custom pentesting Linux distro and related hardware to allow an inexpensive army of remote pentesting drones to be built using the BeagleBone Black computer boards. This work is described in detail in Phil's book "Hacking and Penetration Testing With Low Power Devices" (Syngress, 2014). Prior to entering academia, Phil held several high level positions at well-known US companies. He holds a couple of the usual certs one might expect for someone in his position. Phil is also an accomplished aviator with several thousand hours of flight time. He holds 12 ratings including instructor, commerical pilot, mechanic, inspector, and avionics tech. When not working, he likes to spend time with his family, fly, hack electronics, and has been known to build airplanes. twitter: @ppolstra facebook: https://www.facebook.com/ppolstra

Slides here: https://defcon.org/images/defcon-22/dc-22-presentations/Polstra/DEFCON-22-Phil-Polstra-Cyber-hijacking-Airplanes-Truth-or-Fiction-Updated.pdf Cyberhijacking Airplanes: Truth or Fiction? Dr. Phil Polstra ASSOCIATE PROFESSOR OF DIGITAL FORENSICS, BLOOMSBURG UNIVERSITY OF PENNSYLVANIA Captain Polly ASSOCIATE PROFESSOR OF AVIATION, UNIVERSITY OF DUBUQUE There have been several people making bold claims about the ability to remotely hack into aircraft and hijack them from afar. This talk will take a systematic look at the mechanisms others are claiming would permit such cyberhijacking. Each of the most popular techniques will be examined myth buster style. Along the way several important aircraft technologies will be examined in detail. Attendees will leave with a better understanding of ADS-B, ADS-A, ACARS, GPS, transponders, collision avoidance systems, autopilots, and avionics networking and communications. No prior knowledge is assumed for attendees. The primary presenter is a pilot, flight instructor, aviation professor, aircraft mechanic, aircraft inspector, avionics technician, and plane builder who has also worked on the development of some of the avionics systems found in modern airliners. The second presenter is a former airline pilot with thousands of hours in airliners who is currently an aviation professor in charge of a simulator program. Phil was born at an early age. He cleaned out his savings at age 8 in order to buy a TI99-4A computer for the sum of $450. Two years later he learned 6502 assembly and has been hacking computers and electronics ever since. Dr. Phil currently works as a professor of digital forensics. His research focus over the last few years has been on the use of micro controllers and small embedded computers for forensics and pentesting. Phil has developed a custom pentesting Linux distro and related hardware to allow an inexpensive army of remote pentesting drones to be built using the BeagleBone Black computer boards. This work is described in detail in Phil's book "Hacking and Penetration Testing With Low Power Devices" (Syngress, 2014). Prior to entering academia, Phil held several high level positions at well-known US companies. He holds a couple of the usual certs one might expect for someone in his position. Phil is also an accomplished aviator with several thousand hours of flight time. He holds 12 ratings including instructor, commerical pilot, mechanic, inspector, and avionics tech. When not working, he likes to spend time with his family, fly, hack electronics, and has been known to build airplanes. twitter: @ppolstra facebook: https://www.facebook.com/ppolstra Captain Polly is a former airline pilot at a major US airline. She is currently an Associate Professor of Aviation at a private midwestern university. Polly has thousands of hours of flight time in airliners and small aircraft. She runs a simulator program that includes a number of airliner simulators.

Join Eric, 4Z1UG in his QSO Today with Dean Mertz, K0MKT.  Dean and Eric have been friends for almost 40 years after meeting at the local ham radio club, in Southern California.  While their lives have taken them around the World, there is always an opportunity, a few times a year, to catch up on ham radio projects and personal lives. As a software engineer and hardware tinkerer, Dean always has an inspiring project to discuss.  This time its a web based audio adjustment meter, using the Beaglebone Black, for the local DMR mobile radio system.

What use is an F-call? As I've said many times before, Amateur Radio blows me away. Every week I see new and imaginative things that this community achieves through trial and error, from contacts across new bands, coordination of new activities such as fox-hunts and SOTA activations. We are a fool hardy lot, climbing up hills to "activate" them, or doing the same thing for light-houses, or museums. There's a surfing contest where you collect callsigns to spell the locations of surfing beaches as outlined in the Beach Boy's "Surfin USA" song, which includes an Australian beach as well. It's wonderful to hear about Amateurs talking to other Amateurs, both using portable gear, both standing on top of a summit and exchanging reports across the country. Recently an F-call decided that he wanted to try to build a cavity from bits purchased at a hardware store. Complete with video of the achievement, testing and SWR measurements, a $15 experiment to see if he could do it. Wanting to learn more about his build he sought and found assistance from other Amateurs offering suggestions and equipment to help out. There's a group of Amateurs who are experimenting with a new Internet linking protocol, AllStarLink. Using single board computers like the BeagleBone Black to run copies of embedded Linux with a full dynamic switching system on board to deal with nodes dropping in and joining. Think telephone exchange with roaming handsets. There are amateurs experimenting with different types of antennas, made from Horse Tape, advanced calls learning about tuning up 40m dipoles on 80m, antenna manufacturers building 80m single frequency dipoles in the space of a 40m dipole, repeaters being built, control systems being updated, new services being invented and masts being erected. Don't for a minute think that Amateur Radio is just about sitting in a shack with a microphone, talking to another Amateur in a similar shack somewhere else, doing the same thing. Having an F-call is being part of this community, warts and all, it's an amazing place to hang out and do stuff. So get off your terminator and go to it. I'm Onno VK6FLAB

Jason Kridner (@Jadon) joined us to talk about the BeagleBone Black... and other things. Some good books for Beagle : Bad to the Bone: Crafting Electronics Systems with Beaglebone and BeagleBone Black(co-authored by Jason) Getting Started with BeagleBone: Linux-Powered Electronic Projects With Python and JavaScript Programming the BeagleBone Black: Getting Started with JavaScript and BoneScript More comprehensive list of BeagleBone resources BotSpeak - A programming language for internet endpoints To contact Jason about ordering a bunch of units for your OEM use, see his contact info on BeagleBoard.org's About page.

David Anders (Google+) joined Elecia to chat about open source hardware, what it means, how to do it, and why.  Dave will be speaking at the embedded Linux conference in San Jose, CA on April 30th: 9:00am: Panel: IoT and the Role of Embedded Linux and Android 4:20pm: Hardware Debugging Tools 5:20pm: Debugging - Panel Discussion  Open Source Hardware Association describes the gradient of open source hardware. Sigrok looks at open source and open source friendly tools Dave works for CircuitCo, manufacturers of the mysteriously elusive BeagleBone Black. While he didn't explain their absence (other than they are super popular for OEM'ing), he did announce the brand new Intel-based MinnowBoard MAX. Some open source tools we discussed included Tin Can Tool's 40 pin DIP Linux processor, Flyswatter, and Flyswatter 2. Also, check out Dave's past eLinux presentations.

On this week's episode, we'll be talking with Ted Unangst of the OpenBSD team about their new signing infrastructure. After that, we've got a tutorial on how to run your own NTP server. News, your feedback and even... the winner of our tutorial contest will be announced! So stay tuned to BSD Now - the place to B.. SD. This episode was brought to you by Headlines FreeBSD foundation's 2013 fundraising results (http://freebsdfoundation.blogspot.com/2014/01/freebsd-foundation-announces-2013.html) The FreeBSD foundation finally counted all the money they made in 2013 $768,562 from 1659 donors Nice little blog post from the team with a giant beastie picture "We have already started our 2014 fundraising efforts. As of the end of January we are just under $40,000. Our goal is to raise $1,000,000. We are currently finalizing our 2014 budget. We plan to publish both our 2013 financial report and our 2014 budget soon." A special thanks to all the BSD Now listeners that contributed, the foundation was really glad that we sent some people their way (and they mentioned us on Facebook) *** OpenSSH 6.5 released (https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032152.html) We mentioned the CFT last week, and it's finally here (https://news.ycombinator.com/item?id=7154925)! New key exchange using elliptic-curve Diffie Hellman in Daniel Bernstein's Curve25519 (now the default when both clients support it) Ed25519 public keys are now available for host keys and user keys, considered more secure than DSA and ECDSA Funny side effect: if you ONLY enable ed25519 host keys, all the compromised Linux boxes can't even attempt to login (http://slexy.org/view/s2rI13v8F4) lol~ New bcrypt private key type, 500,000,000 times harder to brute force Chacha20-poly1305 transport cipher that builds an encrypted and authenticated stream in one Portable version already in (https://svnweb.freebsd.org/base?view=revision&revision=261320) FreeBSD -CURRENT, and ports (https://svnweb.freebsd.org/ports?view=revision&sortby=date&revision=342618) Lots more bugfixes and features, see the full release note or our interview (http://www.bsdnow.tv/episodes/2013_12_18-cryptocrystalline) with Damien Work has already started on 6.6, which can be used without OpenSSL (https://twitter.com/msfriedl/status/427902493176377344)! *** Crazed Ferrets in a Berkeley Shower (http://blather.michaelwlucas.com/archives/1942) In 2000, MWL (http://www.bsdnow.tv/episodes/2013_11_06-year_of_the_bsd_desktop) wrote an essay for linux.com about why he uses the BSD license: "It's actually stood up fairly well to the test of time, but it's fourteen years old now." This is basically an updated version about why he uses the BSD license, in response to recent comments from Richard Stallman (http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html) Very nice post that gives some history about Berkeley, the basics of the BSD-style licenses and their contrast to the GNU GPL Check out the full post if you're one of those people that gets into license arguments The takeaway is "BSD is about making the world a better place. For everyone." *** OpenBSD on BeagleBone Black (http://www.tedunangst.com/flak/post/OpenBSD-on-BeagleBone-Black) Beaglebone Blacks are cheap little ARM devices similar to a Raspberry Pi A blog post about installing OpenBSD on a BBB from.. our guest for today! He describes it as "everything I wish I knew before installing the newly renamed armv7 port on a BeagleBone Black" It goes through the whole process, details different storage options and some workarounds Could be a really fun weekend project if you're interested in small or embedded devices *** Interview - Ted Unangst - tedu@openbsd.org (mailto:tedu@openbsd.org) / @tedunangst (https://twitter.com/tedunangst) OpenBSD's signify (http://www.tedunangst.com/flak/post/signify) infrastructure, ZFS on OpenBSD Tutorial Running an NTP server (http://www.bsdnow.tv/tutorials/ntpd) News Roundup Getting started with FreeBSD (http://smyck.net/2014/02/01/getting-started-with-freebsd/) A new video and blog series about starting out with FreeBSD The author has been a fan since the 90s and has installed it on every server he's worked with He mentioned some of the advantages of BSD over Linux and how to approach explaining them to new users The first video is the installation, then he goes on to packages and other topics - 4 videos so far *** More OpenBSD hackathon reports (http://undeadly.org/cgi?action=article&sid=20140204080515) As a followup to last week, this time Kenneth Westerback writes about his NZ hackathon experience He arrived with two goals: disklabel fixes for drives with 4k sectors and some dhclient work This summary goes into detail about all the stuff he got done there *** X11 in a jail (https://svnweb.freebsd.org/base?view=revision&revision=261266) We've gotten at least one feedback email about running X in a jail Well.. with this commit, looks like now you can! A new tunable option will let jails access /dev/kmem and similar device nodes Along with a change to DRM, this allows full X11 in a jail Be sure to check out our jail tutorial and jailed VNC tutorial (http://www.bsdnow.tv/tutorials) for ideas *** PCBSD weekly digest (http://blog.pcbsd.org/2014/01/whoami-im-pc-bsd-10-0-weekly-feature-digest-15/) 10.0 "Joule Edition" finally released (http://blog.pcbsd.org/2014/01/pc-bsd-10-0-release-is-now-available/)! AMD graphics are now officially supported GNOME3, MATE and Cinnamon desktops are available Grub updates and fixes PCBSD also got a mention in eweek (http://www.eweek.com/enterprise-apps/slideshows/freebsd-open-source-os-comes-to-the-pc-bsd-desktop.html) *** Feedback/Questions Justin writes in (http://slexy.org/view/s21VnbKZsH) Daniel writes in (http://slexy.org/view/s2nD7RF6bo) Martin writes in (http://slexy.org/view/s2jwRrj7UV) Alex writes in (http://slexy.org/view/s201koMD2c) - unofficial FreeBSD RPI Images (http://people.freebsd.org/~gjb/RPI/) James writes in (http://slexy.org/view/s2AntZmtRU) John writes in (http://slexy.org/view/s20bGjMsIQ) ***

Gregor PRIDUN und Johnny ZWENG plaudern über freie Software und andere Nerd-Themen. Shownotes auf http://goo.gl/wLSJN oder http://biertaucher.at Bitte nach Möglichkeit diesen Flattr-Link anlicken: http://flattr.com/thing/1589398/Biertaucher-Podcast-Folge-111

Hello and welcome to the first episode to be released on schedule in quite some time! It looks like our contest to award a Beaglebone Black to some lucky listener is going well. Make sure to get your entries in before 10:00pm Central on June 16th, either by becoming a member or completing the thought [...]