Open Source ARM 64-bit Notebook
POPULARITY
6 episodes with Pinebook
3 episodes with Pinebook
3 episodes with Pinebook
2 episodes with Pinebook
2 episodes with Pinebook
3 episodes with Pinebook
3 episodes with Pinebook
3 episodes with Pinebook
2 episodes with Pinebook
About Pine64 None of us is as smart as all of us Ken H. Blanchard At the core of our philosophy is the notion that PINE64 is a community platform. A simplistic point of view, often offered up and referenced online, is that ‘PINE64 does hardware while the community does the software’. While this depiction is not inaccurate, it is also a gross oversimplification. The fact that PINE64 is community driven doesn’t simply entail a one-way reliance on the community or partner projects for software support; it means that the community gets to actively shape the devices, as well as the social platform, of PINE64 from the ground up. The goal is to deliver ARM64 devices that you really wish to engage with and a platform that you want to be a part of. As such, the community – PINE64 – and the company PINE Microsystems Inc. are interlocked and intertwined, but separate entities. What does it mean in practice then? It means that we usually announce what we’re working on well ahead of the shipping date – many months before a device is released – so that you have plenty of time to request product features, suggest changes, ask for/make changes to documentation, etc. before the first iteration of the device rolls of the factory line. It also means that the hardware developments – successes and failures alike – are all in the open. You can follow the process on our forum, the IRC, Discord, Matrix, Telegram the online conversations log and, in some instances, on our partner projects forums. But it also means that anyone who is a part of the community gets to shape anything related to the PINE64 project – including the Wiki or this website – and so, software development is only one area where you can contribute your time and skill. In return for time investment, the community gets fair priced devices that developers wish to spend their time on. Last, but not least, is our belief in supporting existing SoCs for long periods of time as well as actively developing new devices based on those SOCs. What does this mean for developers then? It means that a developer can start developing software on a PINE64 SBC and, in time, support multiple devices with relative ease. This device convergence is, at the time of writing, most pronounced on the Allwinner A64 SOC used in a number of our devices including the: PINE64-LTS, SOPine, Pinebook and Pinetab. That said, similar convergence is also planned for the Rockchip RK3399, currently used on the RockPro64 and in the Pinebook Pro. You can always find us in the chats or the forum, so if you have any further questions make sure to drop by and ask about how the PINE64 project actually works.
Our listeners are FANTASTIC! We mentioned in our episode related to hardware designed to run Linux that neither of us has had any experience with the Pinebook Pro. We ask for feedback from any listeners who have used the Pinebook Pro. So they wrote reviews. Here they are. Thanks to Tim and Stacey for all the work they put into these reviews. Episode Time Stamps 00:00 Going Linux #406 · Pinebook Pro Reviews 01:04 Larry is wrapping-up the Ubuntu MATE Guide for the 21.04 release 02:58 Pinebook pro 05:23 Tim: Experiences with using the Pinebook Pro 06:18 Is the Pinebook Pro a viable low-cost laptop for anyone? 06:59 Pinebook Pro quirks and limitations 08:21 Why does the Pinebook Pro work for me? 09:21 It's great for using when traveling 09:59 About the OS and software 11:17 About the hardware and accessories 13:05 Summary: Limited and slow, maybe a Chromebook alternative 15:21 Stacey: A review of Pine's customer support 17:18 Ordering the Pinebook Pro 18:13 Unboxing the Pinebook Pro 18:40 Attempting to get support from Pine 21:08 Finding a fix without any help from Pine 22:12 A scorned customer 23:07 Our final words on the Pinebook Pro 34:03 End
Our listeners are FANTASTIC! We mentioned in our episode related to hardware designed to run Linux that neither of us has had any experience with the Pinebook Pro. We ask for feedback from any listeners who have used the Pinebook Pro. So they wrote reviews. Here they are. Thanks to Tim and Stacey for all the work they put into these reviews. Episode Time Stamps 00:00 Going Linux #406 · Pinebook Pro Reviews 01:04 Larry is wrapping-up the Ubuntu MATE Guide for the 21.04 release 02:58 Pinebook pro 05:23 Tim: Experiences with using the Pinebook Pro 06:18 Is the Pinebook Pro a viable low-cost laptop for anyone? 06:59 Pinebook Pro quirks and limitations 08:21 Why does the Pinebook Pro work for me? 09:21 It's great for using when traveling 09:59 About the OS and software 11:17 About the hardware and accessories 13:05 Summary: Limited and slow, maybe a Chromebook alternative 15:21 Stacey: A review of Pine's customer support 17:18 Ordering the Pinebook Pro 18:13 Unboxing the Pinebook Pro 18:40 Attempting to get support from Pine 21:08 Finding a fix without any help from Pine 22:12 A scorned customer 23:07 Our final words on the Pinebook Pro 34:03 End
table td.shrink { white-space:nowrap } New hosts Welcome to our new host: Padraig Jeroen Fallon. Last Month's Shows Id Day Date Title Host 3196 Mon 2020-11-02 HPR Community News for October 2020 HPR Volunteers 3197 Tue 2020-11-03 Pens, pencils, paper and ink - 3 Dave Morriss 3198 Wed 2020-11-04 Income Life insurance and then Chopin Paul Quirk 3199 Thu 2020-11-05 Bad Audio Weed Eater Bugs Sprinkler and Bubbles ! operat0r 3200 Fri 2020-11-06 Better Social Media 17 - OcapPub Ahuka 3201 Mon 2020-11-09 A small intro to 3D printing Jeroen Baten 3202 Tue 2020-11-10 A big Question Padraig Jeroen Fallon 3203 Wed 2020-11-11 The Paul Quirk show: Retro Computing Paul Quirk 3204 Thu 2020-11-12 Getting Started in 3D Printing Thaj Sara 3205 Fri 2020-11-13 Backups of your Backups of Backups operat0r 3206 Mon 2020-11-16 Dungeons and Dragons for the blind klaatu 3207 Tue 2020-11-17 Fireside chat with E Nigma Ken Fallon 3208 Wed 2020-11-18 The Paul Quirk show: Wacom with Pinebook, and thoughts on the DMCA takedown Paul Quirk 3209 Thu 2020-11-19 Linux Inlaws S01E17: Nextcloud monochromec 3210 Fri 2020-11-20 GIMP: Patterns and Gradients Ahuka 3211 Mon 2020-11-23 Chainsaws operat0r 3212 Tue 2020-11-24 A Pi Model 3B as your daily driver? You must be joking. Beeza 3213 Wed 2020-11-25 Electrical Safety Paul Quirk 3214 Thu 2020-11-26 Rant about websites operat0r 3215 Fri 2020-11-27 Why I Gave Away a 3-D Printer Ahuka 3216 Mon 2020-11-30 Buying a second home in France Jeroen Baten Comments this month These are comments which have been made during the past month, either to shows released during the month or to past shows. There are 13 comments in total. Past shows There are 7 comments on 6 previous shows: hpr1771 (2015-05-18) "Audacity: Label Tracks" by Jon Kulp. Comment 4: Ken Fallon on 2020-11-19: "Yes - found it" hpr1796 (2015-06-22) "Audacity - Chains, Notches and Labels" by cheeto4493. Comment 1: Ken Fallon on 2020-11-19: "And this one as well" hpr2881 (2019-08-19) "Automatically split album into tracks in Audacity" by Ken Fallon. Comment 3: Ken Fallon on 2020-11-19: "And the final piece of the puzzle" hpr3126 (2020-07-27) "Metrics part II" by Andrew Conway. Comment 3: mcnalu on 2020-11-25: "Thanks for the comments" hpr3179 (2020-10-08) "MakeMKV to back up media, and a Question" by Archer72. Comment 2: Archer72 on 2020-11-03: "re: janedoc" hpr3193 (2020-10-28) "Meet Antithesis" by Paul Quirk. Comment 1: brian-in-ohio on 2020-11-03: "dark-table" Comment 2: Ahuka on 2020-11-03: "Agree with Brian" This month's shows There are 6 comments on 5 of this month's shows: hpr3202 (2020-11-10) "A big Question" by Padraig Jeroen Fallon. Comment 1: Enigma on 2020-11-10: "Great first show" hpr3206 (2020-11-16) "Dungeons and Dragons for the blind" by klaatu. Comment 1: Mike Ray on 2020-11-16: "Thanks for a great show" hpr3208 (2020-11-18) "The Paul Quirk show: Wacom with Pinebook, and thoughts on the DMCA takedown" by Paul Quirk. Comment 1: Charliebrownau on 2020-11-23: "Feedback - HPR 3208e" hpr3209 (2020-11-19) "Linux Inlaws S01E17: Nextcloud" by monochromec. Comment 1: Kevin O'Brien on 2020-11-19: "I loved the show" hpr3213 (2020-11-25) "Electrical Safety" by Paul Quirk. Comment 1: norrist on 2020-11-25: "Great episode"Comment 2: Kevin O'Brien on 2020-11-27: "I loved the show" Mailing List discussions Policy decisions surrounding HPR are taken by the community as a whole. This discussion takes place on the Mail List which is open to all HPR listeners and contributors. The discussions are open and available on the HPR server under Mailman. The threaded discussions this month can be found here: http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/2020-November/thread.html Events Calendar With the kind permission of LWN.net we are linking to The LWN.net Community Calendar. Quoting the site: This is the LWN.net community event calendar, where we track events of interest to people using and developing Linux and free software. Clicking on individual events will take you to the appropriate web page. Any other business Tags and Summaries There were no tag or summary updates in the past month. If you would like to contribute to the tag/summary project visit the summary page at https://hackerpublicradio.org/report_missing_tags.php and follow the instructions there.
My fediverse address: @paul@cloud.pquirk.com See my first Wacom doodle here: https://cloud.pquirk.com/index.php/s/CAnAwwD6S6AczC6 https://en.wikipedia.org/wiki/Citizens_United_v._Federal_Election_Commission https://www.canlii.org/en/ca/scc/doc/2000/2000scc57/2000scc57.html
YouTube-DL is under attack, the RIAA thought it could remove YouTube-DL's source code off of the internet, does that work? There's a new Raspberry Pi on the block, built into a keyboard! Portainer a simple UI for container management in Docker, Swarm, Kubernetes, ACI and Edge environments. Questions from the community about syncing laptops, the Pinebook pro for photograph, and the perfect laptop charger on the go more this week! -- The Extra Credit Section -- For links to the articles and material referenced in this week's episode check out this week's page from our podcast dashboard! This Episode's Podcast Dashboard (http://podcast.asknoahshow.com/205) Phone Systems for Ask Noah provided by Voxtelesys (http://www.voxtelesys.com/asknoah) Join us in our dedicated chatroom #AskNoahShow on Freenode! -- Stay In Touch -- Find all the resources for this show on the Ask Noah Dashboard Ask Noah Dashboard (http://www.asknoahshow.com) Need more help than a radio show can offer? Altispeed provides commercial IT services and they’re excited to offer you a great deal for listening to the Ask Noah Show. Call today and ask about the discount for listeners of the Ask Noah Show! Altispeed Technologies (http://www.altispeed.com/) Contact Noah live [at] asknoahshow.com -- Twitter -- Noah - Kernellinux (https://twitter.com/kernellinux) Ask Noah Show (https://twitter.com/asknoahshow) Altispeed Technologies (https://twitter.com/altispeed)
Steve Ovens from RedHat joins to discuss CGroups! Manjaro Arm the new default on PineBook releases 20.10. We answer some self hosted photo options, remote VPN access, plus our picks! -- The Extra Credit Section -- For links to the articles and material referenced in this week's episode check out this week's page from our podcast dashboard! This Episode's Podcast Dashboard (http://podcast.asknoahshow.com/202) Phone Systems for Ask Noah provided by Voxtelesys (http://www.voxtelesys.com/asknoah) Join us in our dedicated chatroom #AskNoahShow on Freenode! -- Stay In Touch -- Find all the resources for this show on the Ask Noah Dashboard Ask Noah Dashboard (http://www.asknoahshow.com) Need more help than a radio show can offer? Altispeed provides commercial IT services and they’re excited to offer you a great deal for listening to the Ask Noah Show. Call today and ask about the discount for listeners of the Ask Noah Show! Altispeed Technologies (http://www.altispeed.com/) Contact Noah live [at] asknoahshow.com -- Twitter -- Noah - Kernellinux (https://twitter.com/kernellinux) Ask Noah Show (https://twitter.com/asknoahshow) Altispeed Technologies (https://twitter.com/altispeed) Special Guest: Steve Ovens.
Steve Ovens from RedHat joins to discuss CGroups! Manjaro Arm the new default on PineBook releases 20.10. We answer some self hosted photo options, remote VPN access, plus our picks!
This week we have been watching The Mandalorian. We discuss a new look for UKUI, HP Z series computers with Ubuntu pre-installed, elementary OS on Pinebook, Active Directory integration in Ubuntu Desktop, and making apps for GNOME. We also round… Read more ›
Computers that we wish we didn't own, a terrible funding model for Linux, shunning the work of bad people, and a shocking revelation from popey about ThinkPads. You can support creation of The New Show episodes via Patreon or Paypal, and you can send us your questions on Twitter. This episode is sponsored by Lernard. … Continue reading "The New Show 07: Pinebook Bros"
FreeBSD 11.4-RC 2 available, OpenBSD 6.7 on a PineBook Pro 64, How OpenZFS Keeps Your Data Safe, Bringing FreeBSD to EC2, FreeBSD 2020 Community Survey, and more. NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/) Headlines FreeBSD 11.4-RC2 Now Available (https://lists.freebsd.org/pipermail/freebsd-stable/2020-May/092320.html) The second RC build of the 11.4-RELEASE release cycle is now available. + 11.4-RELEASE notes (https://www.freebsd.org/releases/11.4R/relnotes.html) (still in progress at the time of recording) Install OpenBSD 6.7-current on a PineBook Pro 64 (https://xosc.org/pinebookpro.html) This document is work in progress and I'll update the date above once I change something. If you have something to add, remarks, etc please contact me. Preferably via Mastodon but other means of communication are also fine. News Roundup Understanding How OpenZFS Keeps Your Data Safe (https://www.ixsystems.com/blog/openzfs-keeps-your-data-safe/) Veteran technology writer Jim Salter wrote an excellent guide on the ZFS file system’s features and performance that we absolutely had to share. There’s plenty of information in the article for ZFS newbies and advanced users alike. Be sure to check out the article over at Ars Technica to learn more about ZFS concepts including pools, vdevs, datasets, snapshots, and replication, just to name a few. Bringing FreeBSD to ec2 (https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/bringing-freebsd-to-ec2-with-colin-percival/) Colin is the founder of Tarsnap, a secure online backup service which combines the flexibility and scriptability of the standard UNIX "tar" utility with strong encryption, deduplication, and the reliability of Amazon S3 storage. Having started work on Tarsnap in 2006, Colin is among the first generation of users of Amazon Web Services, and has written dozens of articles about his experiences with AWS on his blog. FreeBSD 2020 Community Survey (https://www.research.net/r/freebsd-2020-community-survey) The FreeBSD Core Team invites you to complete the 2020 FreeBSD Community Survey. The purpose of this survey is to collect quantitative data from the public in order to help guide the project’s priorities and efforts. This is only the second time a survey has been conducted by the FreeBSD Project and your input is valued. The survey will remain open for 14 days and will close on June 16th at 17:00 UTC (Tuesday 10am PDT). Beastie Bits FreeBSD Project Proposals (https://www.freebsdfoundation.org/blog/submit-your-freebsd-project-proposal) TJ Hacking (https://www.youtube.com/channel/UCknj_nW8JWcFJOAbgd5_Zgw) Scotland Open Source podcast (https://twitter.com/ScotlandOSUM/status/1265987126321188864?s=19) Next FreeBSD Office Hours on June 24, 2020 (https://wiki.freebsd.org/OfficeHours) *** Feedback/Questions Tom - Writing for LPIrstudio (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/354/feedback/Tom%20-%20Wriitng%20for%20LPI.md) Luke - rstudio (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/354/feedback/Luke%20-%20rstudio.md) Matt - Vlans and Jails (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/354/feedback/Matt%20-%20Vlans%20and%20Jails.md) Morgan - Can I get some commentary on this issue (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/354/feedback/Morgan%20-%20Can%20I%20get%20some%20commentary%20on%20this%20issue.md) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv)
Rocco (BigDaddyLinux) pointed the Linux Spotlight at Robbie this week, and we've got a short preview. Robbie will show us what it takes to get an operating system "installed" on a Pinebook Pro SD card, and why you might want to, and we'll also get a beginner's rundown of how to use GitHub. Bekah's here with the latest tech news, and Robert returns for more cryptocurrency market news. 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/654/ Running time: 1 Hour 2 Minutes 4 Seconds
Vi ska pröva nåt nytt ikväll, med kort varsel blev avsnittet den första instansen av GNU/podcast. En seger för Jockes Linuxanvändande. Jocke beställer den svåra tredje Ryzenmaskinen Rättelse: Euroshopper blev ICA Basic, inget annat. Tack Mattias för rättelse. Korvtips: Slaktarkorv. Tack till Peter i vår chattkanal för tipset. Okänt Sim-spel från Maxis hittat C&C remastred collection Pinebook pro ser så trevlig ut. Fredrik är småsugen Fantastiskt trevligt twitterkonto: RealTimeWWII - twittrar ut händelser från andra världskriget under 1942 Ska Fredrik köpa spel-pc? Apple och ARM verkar vara spikat till WWDC Jocke får smörj på Mastodon. har han gjort rätt eller fel? Fuck Discord Film och TV Filthy Rich - dokumentärserie på Netflix om Jeffrey Epstein. Oerhört jobbig att se men också viktig och oerhört välgjord. Nej, vi har inte sett Titanic 2 ännu. Länkar Sound recorder GNOME Pulse audio Plattetyder Audacity Slaktarkorv Simtower Simearth Simant Sim refinery hittat Mark text Artikeln Fredrik läste om Maxis business simulations C&C remastered Installationsprogrammet för C&C Pinebook pro Selea skriver om Pinebook pro Jeremy Morgan om Pinebook pro Realtimewwii Hardcore history - Supernova in the east IV Half-life: Alyx NVMe, M.2 och SATA Apple will announce move to ARM-based Macs later this month, says report - The Verge A14-processorn Kalamata-oliver Max Temkin Filthy rich Jeffrey Epstein It Doesn’t Have to be Crazy at Work Fuck Discord Två nördar - en podcast. Fredrik Björeman, Joacim Melin diskuterar allt som gör livet värt att leva. Fullständig avsnittsinformation finns här: https://www.bjoremanmelin.se/podcast/avsnitt-213-gnu-podcast.html.
First up, in our Wanderings, Leo upgrades TLP, Tony Hughes tinkers with LMDE, Manjaro fights with Moss, Josh gets cancelled, and Joe works from home. Then, in the news, NPM gets acquired, OBS adds a number, Purism and Pinebook have new releases, Basilisk takes us back in time, and Gnome gets new features. In security, Edge is coming, and it’s worse than we thought. Download
Why ZFS is doing filesystem checksumming right, better TMPFS throughput performance on DragonFlyBSD, reshaping pools with ZFS, PKGSRC on Manjaro aarch64 Pinebook-pro, central log host with syslog-ng on FreeBSD, and more. Headlines Checksumming in filesystems, and why ZFS is doing it right (https://oshogbo.vexillium.org/blog/73/) One of the best aspects of ZFS is its reliability. This can be accomplished using a few features like copy-on-write approach and checksumming. Today we will look at how ZFS does checksumming and why it does it the proper way. Most of the file systems don’t provide any integrity checking and fail in several scenarios: Data bit flips - when the data that we wanted to store are bit flipped by the hard drives, or cables, and the wrong data is stored on the hard drive. Misdirected writes - when the CPU/cable/hard drive will bit flip a block to which the data should be written. Misdirected read - when we miss reading the block when a bit flip occurred. Phantom writes - when the write operation never made it to the disk. For example, a disk or kernel may have some bug that it will return success even if the hard drive never made the write. This problem can also occur when data is kept only in the hard drive cache. Checksumming may help us detect errors in a few of those situations. DragonFlyBSD Improves Its TMPFS Implementation For Better Throughput Performance (https://www.phoronix.com/scan.php?page=news_item&px=DragonFlyBSD-TMPFS-Throughput) It's been a while since last having any new magical optimizations to talk about by DragonFlyBSD lead developer Matthew Dillon, but on Wednesday he landed some significant temporary file-system "TMPFS" optimizations for better throughput including with swap. Of several interesting commits merged tonight, the improved write clustering is a big one. In particular, "Reduces low-memory tmpfs paging I/O overheads by 4x and generally increases paging throughput to SSD-based swap by 2x-4x. Tmpfs is now able to issue a lot more 64KB I/Os when under memory pressure." https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/4eb0bb82efc8ef32c4357cf812891c08d38d8860 There's also a new tunable in the VM space as well as part of his commits on Wednesday night. This follows a lot of recent work on dsynth, improved page-out daemon pipelining, and other routine work. https://gitweb.dragonflybsd.org/dragonfly.git/commit/bc47dbc18bf832e4badb41f2fd79159479a7d351 This work is building up towards the eventual DragonFlyBSD 5.8 while those wanting to try the latest improvements right away can find their daily snapshots. News Roundup Why ZFS is not good at growing and reshaping pools (or shrinking them) (https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSWhyNoRealReshaping) recently read Mark McBride's Five Years of Btrfs (via), which has a significant discussion of why McBride chose Btrfs over ZFS that boils down to ZFS not being very good at evolving your pool structure. You might doubt this judgment from a Btrfs user, so let me say as both a fan of ZFS and a long term user of it that this is unfortunately quite true; ZFS is not a good choice if you want to modify your pool disk layout significantly over time. ZFS works best if the only change in your pools that you do is replacing drives with bigger drives. In our ZFS environment we go to quite some lengths to be able to expand pools incrementally over time, and while this works it both leaves us with unbalanced pools and means that we're basically forced to use mirroring instead of RAIDZ. (An unbalanced pool is one where some vdevs and disks have much more data than others. This is less of an issue for us now that we're using SSDs instead of HDs.) Using PKGSRC on Manjaro Linux aarch64 Pinebook-pro (https://astr0baby.wordpress.com/2020/02/09/using-pkgsrc-on-manjaro-linux-aarch64-pinebook-pro/) I wanted to see how pkgsrc works on aarch64 Linux Manjaro since it is a very mature framework that is very portable and supported by many architectures – pkgsrc (package source) is a package management system for Unix-like operating systems. It was forked from the FreeBSD ports collection in 1997 as the primary package management system for NetBSD. One might question why use pkgsrc on Arch based Manjaro, since the pacman package repository is very good on its own. I see alternative pkgsrc as a good automated build framework that offers a way to produce independent build environment /usr/pkg that does not interfere with the current Linux distribution in any way (all libraries are statically built) I have used the latest Manjaro for Pinebookpro and standard recommended tools as mentioned here https://wiki.netbsd.org/pkgsrc/howtousepkgsrcon_linux/ A Central Log Host with syslog-ng on FreeBSD Part 1 (https://blog.socruel.nu/freebsd/a-central-log-host-with-syslog-ng-on-freebsd.html) syslog-ng is the Swiss army knife of log management. You can collect logs from any source, process them in real time and deliver them to wide range of destinations. It allows you to flexibly collect, parse, classify, rewrite and correlate logs from across your infrastructure. This is why syslog-ng is the perfect solution for the central log host of my (mainly) FreeBSD based infrastructure. Part 2 (https://blog.socruel.nu/freebsd/check-logs-of-syslog-ng-log-host-on-freebsd.html) This blog post continues where the blog post A central log host with syslog-ng on FreeBSD left off. Open source solutions to check syslog log messages exist, such as Logcheck or Logwatch. Although these are not too difficult to implement and maintain, I still found these to much. So I went for my own home grown solution to check the syslog messages of the SoCruel.NU central log host. Beastie Bits FreeBSD at Linux Conf 2020 session videos now online (https://mirror.linux.org.au/pub/linux.conf.au/2020/room_9/Tuesday/) Unlock your laptop with your phone (https://vermaden.wordpress.com/2020/01/09/freebsd-desktop-part-20-configuration-unlock-your-laptop-with-phone/) Managing a database of vulnerabilities for a package system: the pkgsrc study (https://www.netbsd.org/gallery/presentations/leot/itasec20/pkgsrc-security.pdf) Hamilton BSD User group will meet again on March 10th](http://studybsd.com/) CharmBUG Meeting: March 24th 7pm in Severn, MD (https://www.meetup.com/en-AU/CharmBUG/events/268251508/) *** Feedback/Questions Andrew - ZFS feature Flags (http://dpaste.com/2YM23C0#wrap) Sam - TwinCat BSD (http://dpaste.com/0FCZV6R) Dacian - Freebsd + amdgpu + Lenovo E595 (http://dpaste.com/1R7F1JN#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.
Why ZFS is doing filesystem checksumming right, better TMPFS throughput performance on DragonFlyBSD, reshaping pools with ZFS, PKGSRC on Manjaro aarch64 Pinebook-pro, central log host with syslog-ng on FreeBSD, and more.
Why ZFS is doing filesystem checksumming right, better TMPFS throughput performance on DragonFlyBSD, reshaping pools with ZFS, PKGSRC on Manjaro aarch64 Pinebook-pro, central log host with syslog-ng on FreeBSD, and more.
Linux couldn’t duplicate OpenBSD, FreeBSD Q4 status report, OPNsense 19.7.9 released, archives retain and pass on knowledge, HardenedBSD Tor Onion Service v3 Nodes, and more. Headlines OpenBSD has to be a BSD Unix and you couldn't duplicate it with Linux (https://utcc.utoronto.ca/~cks/space/blog/unix/OpenBSDMustBeABSD?showcomments) OpenBSD has a well deserved reputation for putting security and a clean system (for code, documentation, and so on) first, and everything else second. OpenBSD is of course based on BSD (it's right there in the name) and descends from FreeBSD NetBSD (you can read the history here). But one of the questions you could ask about it is whether it had to be that way, and in particular if you could build something like OpenBSD on top of Linux. I believe that the answer is no. Linux and the *BSDs have a significantly different model of what they are. BSDs have a 'base system' that provides an integrated and fully operational core Unix, covering the kernel, C library and compiler, and the normal Unix user level programs, all maintained and distributed by the particular BSD. Linux is not a single unit this way, and instead all of the component parts are maintained separately and assembled in various ways by various Linux distributions. Both approaches have their advantages, but one big one for the BSD approach is that it enables global changes. Making global changes is an important part of what makes OpenBSD's approach to improving security, code maintenance, and so on work. Because it directly maintains everything as a unit, OpenBSD is in a position to introduce new C library or kernel APIs (or change them) and then immediately update all sorts of things in user level programs to use the new API. This takes a certain amount of work, of course, but it's possible to do it at all. And because OpenBSD can do this sort of ambitious global change, it does. This goes further than just the ability to make global changes, because in theory you can patch in global changes on top of a bunch of separate upstream projects. Because OpenBSD is in control of its entire base system, it's not forced to try to reconcile different development priorities or integrate clashing changes. OpenBSD can decide (and has) that only certain sorts of changes will be accepted into its system at all, no matter what people want. If there are features or entire programs that don't fit into what OpenBSD will accept, they just lose out. FreeBSD Quarterly Status Report 2019Q4 (https://lists.freebsd.org/pipermail/freebsd-announce/2020-January/001923.html) Here is the last quarterly status report for 2019. As you might remember from last report, we changed our timeline: now we collect reports the last month of each quarter and we edit and publish the full document the next month. Thus, we cover here the period October 2019 - December 2019. If you thought that the FreeBSD community was less active in the Christmas' quarter you will be glad to be proven wrong: a quick glance at the summary will be sufficient to see that much work has been done in the last months. Have a nice read! News Roundup OPNsense 19.7.9 released (https://opnsense.org/opnsense-19-7-9-released/) As 20.1 nears we will be making adjustments to the scope of the release with an announcement following shortly. For now, this update brings you a GeoIP database configuration page for aliases which is now required due to upstream database policy changes and a number of prominent third-party software updates we are happy to see included. Archives are important to retain and pass on knowledge (https://dan.langille.org/2020/01/07/archives-are-important-to-retain-and-pass-on-knowledge/) Archives are important. When they are public and available for searching, it retains and passes on knowledge. It saves vast amounts of time. HardenedBSD Tor Onion Service v3 Nodes (https://hardenedbsd.org/article/shawn-webb/2020-01-30/hardenedbsd-tor-onion-service-v3-nodes) I've been working today on deploying Tor Onion Service v3 nodes across our build infrastructure. I'm happy to announce that the public portion of this is now completed. Below you will find various onion service hostnames and their match to our infrastructure. hardenedbsd.org: lkiw4tmbudbr43hbyhm636sarn73vuow77czzohdbqdpjuq3vdzvenyd.onion ci-01.nyi.hardenedbsd.org: qspcqclhifj3tcpojsbwoxgwanlo2wakti2ia4wozxjcldkxmw2yj3yd.onion ci-03.md.hardenedbsd.org: eqvnohly4tjrkpwatdhgptftabpesofirnhz5kq7jzn4zd6ernpvnpqd.onion ci-04.md.hardenedbsd.org: rfqabq2w65nhdkukeqwf27r7h5xfh53h3uns6n74feeyl7s5fbjxczqd.onion git-01.md.hardenedbsd.org: dacxzjk3kq5mmepbdd3ai2ifynlzxsnpl2cnkfhridqfywihrfftapid.onion Beastie Bits The Missing Semester of Your CS Education (MIT Course) (https://missing.csail.mit.edu/) An old Unix Ad (https://i.redd.it/503390rf7md41.png) OpenBSD syscall call-from verification (https://marc.info/?l=openbsd-tech&m=157488907117170&w=2) OpenBSD/arm64 on Pinebook (https://twitter.com/bluerise/status/1220963106563579909) Reminder: First Southern Ontario BSD user group meeting, February 11th (this coming Tuesday!) 18:30 at Boston Pizza on Upper James st, Hamilton. (http://studybsd.com/) NYCBUG: March meeting will feature Dr. Paul Vixie and his new talk “Operating Systems as Dumb Pipes” (https://www.nycbug.org/) 8th Meetup of the Stockholm BUG: March 3 at 18:00 (https://www.meetup.com/de-DE/BSD-Users-Stockholm/events/267873938/) Polish BSD User Group meets on Feb 11, 2020 at 18:15 (https://bsd-pl.org/en) Feedback/Questions Sean - ZFS and Creation Dates (http://dpaste.com/3W5WBV0#wrap) Christopher - Help on ZFS Disaster Recovery (http://dpaste.com/3SE43PW) Mike - Encrypted ZFS Send (http://dpaste.com/00J5JZG#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.
The Pinebook pro has arrived and Noah gives his initial impressions. SHA-1 is broken in a new way thats cheaper and easier.
The Pinebook pro has arrived and Noah gives his initial impressions. SHA-1 is broken in a new way thats cheaper and easier. -- The Extra Credit Section -- For links to the articles and material referenced in this week's episode check out this week's page from our podcast dashboard! This Episode's Podcast Dashboard (http://podcast.asknoahshow.com/163) Phone Systems for Ask Noah provided by Voxtelesys (http://www.voxtelesys.com/asknoah) Join us in our dedicated chatroom #AskNoahShow on Freenode! -- Stay In Touch -- Find all the resources for this show on the Ask Noah Dashboard Ask Noah Dashboard (http://www.asknoahshow.com) Need more help than a radio show can offer? Altispeed provides commercial IT services and they’re excited to offer you a great deal for listening to the Ask Noah Show. Call today and ask about the discount for listeners of the Ask Noah Show! Altispeed Technologies (http://www.altispeed.com/) Contact Noah live [at] asknoahshow.com -- Twitter -- Noah - Kernellinux (https://twitter.com/kernellinux) Ask Noah Show (https://twitter.com/asknoahshow) Altispeed Technologies (https://twitter.com/altispeed)
The Pinebook pro has arrived and Noah gives his initial impressions. SHA-1 is broken in a new way thats cheaper and easier.
Yunohost 3.7 Testing asking for feedback We just released a new testing version for YunoHost and would be happy to receive feedback before releasing it as a stable version :yum: This release includes quite important changes in YunoHost's internal, and therefore requires careful validation to minimize the amount of remaining bugs. Major changes are: Group and permission mechanism Improvements to detect app installs that broke critical parts of the system. Scarier wornings for dangerous app installs Message imporvement, string cleaning and a language rework Removing etckeeper Improved translations for Cataln, Occitan, French, Esperanto, Arabic, German, Spanish, Norwegian Bokmal, Portuguese and Swedish. Tor - New campaign, Take back the internet BTW I am considering putting up a tor version of Bonehea Media. What do you think? Pine64 announces round 2 of pre orders for the Pinebook Pro on 2019-11-05 if anybody is interested in buying me one I would graciously accept it! The original $99 Pinebook will take orders in early 2020. Want some free swag? November is LibreOffice month! Some Scary Ass Headlines! Null Byte - Finding passwords in log files with Google Dorks Redhat - 3 ways to reduce your attack surface on Linux Hacker News - 5 places where hackers are stealing your data Hacker News - New Chrome 0-day Bug is under active attacks-update now!!! Hacker News - Leading web domain name registrars disclose data breach Hacker News - Chinese hackers compromise telecom servers to spy on sms I ran search for Open Source password managers and came up with theses. Bitwarden - self hosted or use someone else KeePass - Desktop KeepassX - Fork of KeePass KeeWeb - Self hosted I'm gonna try KeePass and use KeeWeb on my Yunohost! Will report on this in a month. --- Send in a voice message: https://anchor.fm/landp/message
The FSF is looking for some direction, StackStorm joins the Linux Foundation, and GNOME users who like it a little traditional get some good news. Plus the Pinebook Pro starts shipping to customers, and more.
CentOS goes rolling and announces version 8. Find out why we're excited to take a dip in this stream. Plus we review what might just be your next Linux laptop, and explain why systemd is coming for your /home. Special Guest: Neal Gompa.
Facebook fined • Blender supported • Windows KDEConnect-ed • Android scrcopied • Pinebook demoed • OnlyOffice updated • Linux on an old laptop • Ten thousand spoons when all you need is a knife
We unboxed the 1080p Pinebook on Episode 611. Now, after 1 week of usage, let's talk about our first impressions with the $99 Linux laptop from PINE64. We'll look at the good and bad, and provide context and possible use cases for this innovative SBC-powered notebook. 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/612/ Running time: 1 Hour 3 Minutes 32 Seconds
The Pinebook is groundbreaking. A truly functional $99 Linux laptop with a 1080p IPS screen, WiFi and Bluetooth 4.0. But its low price tag and innovative nature lead to some very real caveats for some users. Let's see how our tech-savvy bald nerd reacts to what, with a little patience, could be an excellent little portable writing or coding tool. 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/611/ Running time: 1 Hour 41 Minutes 30 Seconds
Bezos has built a moon lander? Another WhatsApp security exploit? The Pinebook?! All that, and much, much more…Opening Audio: https://youtu.be/GQ98hGUe6FM THE ZOMIA ONE PODCAST NETWORK IS LIVE! SWITCH YOUR FEED: http://zomiaone.com The Foreplay: --Google’s Project Campfire dead (http://bit.ly/2Q8knKU), Alexa Guard will keep an ear out for your security (http://bit.ly/2YsqZa0), Intel’s Clear Linux OS 2.0 has gotten interesting (https://clearlinux.org/), HTC’s Exodus 1s will be a budget phone and can be a Bitcoin node (https://engt.co/2E7CQT6), Firefox is toying with a “Super Private Mode” (http://bit.ly/2WHvf5h), “unGoogled” Android phones for sale now (http://bit.ly/2Q8kiXC). Story of the Week: --”Bezos in Space III” Link: http://bit.ly/2LPg9tt HackSec: --”Google’s Titan Key Bluetooth Exploit Found” Link: http://bit.ly/2Hn7REA --”WhatsApp Vulnerability Ousts Activists” Link: http://bit.ly/30jggk7 This Week in Blockchain: --”Microsoft Blockchain Identity” Link: http://bit.ly/2LGH9Lr Online Review of the Week: --”AutoExec Wheelmate” Link: https://amzn.to/30gmnFK The Climax: --”Pinebook & Pinebook Pro” Link: https://www.pine64.org/pinebook/, http://bit.ly/2Q8k0ju APPENDIX & SPONSORS: --”Blocktap.io” Link: https://www.blocktap.io/ --”BlockchainAcrossAmerica.com” Link: https://www.blockchainacrossamerica.com/ --”Listen to Free Talk Live” Link: https://www.freetalklive.com --”Use Fastmail!” Link: https://fastmail.sovryntech.com --”Use Booking.com and Earn $25!” Link: https://booking.sovryntech.com --“Sign Up for the Sovryn Tech Newsletter” Link: https://zog.email --"Sovryn Tech Contact Form” Link: http://contact.zog.ninja --"Surveillance Self-Defense" Link: https://ssd.eff.org/ --"RetroShare" Link: http://retroshare.net/ --“Books of Liberty” Link: http://booksofliberty.com/ --"Dark Android: 2017 Edition" Link: http://darkandroid.info --”Sovryn Universe, Vol. 1” Link: https://amzn.to/2MrvfEy -------------------------------------------------------------------------Make easy monthly donations through Patreon: patreon.com/sovryntech Donate with Crypto! BTC: 3K7UckYuEFWZLABfJktqxqPbgajYZTEzNW Zcash Address: t1MrX6XtS8Mhs6P4fW39d5PaWJ4jqguBY4Z Donate with PayPal! Link: http://donate.zog.ninja Donate with our Amazon Wish List! Link: http://wishlist.zog.ninja -------------------------------------------------------------------------You can e-mail the show at: bbs@sovryntech.com-------------------------------------------------------------------------You can also visit our IRC channel on Freenode: #SovNet Or just go to: http://irc.zog.ninja -------------------------------------------------------------------------http://sovryntech.com https://twitter.com/sovryntech
Bezos has built a moon lander? Another WhatsApp security exploit? The Pinebook?! All that, and much, much more…Opening Audio: https://youtu.be/GQ98hGUe6FM THE ZOMIA ONE PODCAST NETWORK IS LIVE! SWITCH YOUR FEED: http://zomiaone.com The Foreplay: --Google’s Project Campfire dead (http://bit.ly/2Q8knKU), Alexa Guard will keep an ear out for your security (http://bit.ly/2YsqZa0), Intel’s Clear Linux OS 2.0 has gotten interesting (https://clearlinux.org/), HTC’s Exodus 1s will be a budget phone and can be a Bitcoin node (https://engt.co/2E7CQT6), Firefox is toying with a “Super Private Mode” (http://bit.ly/2WHvf5h), “unGoogled” Android phones for sale now (http://bit.ly/2Q8kiXC). Story of the Week: --”Bezos in Space III” Link: http://bit.ly/2LPg9tt HackSec: --”Google’s Titan Key Bluetooth Exploit Found” Link: http://bit.ly/2Hn7REA --”WhatsApp Vulnerability Ousts Activists” Link: http://bit.ly/30jggk7 This Week in Blockchain: --”Microsoft Blockchain Identity” Link: http://bit.ly/2LGH9Lr Online Review of the Week: --”AutoExec Wheelmate” Link: https://amzn.to/30gmnFK The Climax: --”Pinebook & Pinebook Pro” Link: https://www.pine64.org/pinebook/, http://bit.ly/2Q8k0ju APPENDIX & SPONSORS: --”Blocktap.io” Link: https://www.blocktap.io/ --”BlockchainAcrossAmerica.com” Link: https://www.blockchainacrossamerica.com/ --”Listen to Free Talk Live” Link: https://www.freetalklive.com --”Use Fastmail!” Link: https://fastmail.sovryntech.com --”Use Booking.com and Earn $25!” Link: https://booking.sovryntech.com --“Sign Up for the Sovryn Tech Newsletter” Link: https://zog.email --"Sovryn Tech Contact Form” Link: http://contact.zog.ninja --"Surveillance Self-Defense" Link: https://ssd.eff.org/ --"RetroShare" Link: http://retroshare.net/ --“Books of Liberty” Link: http://booksofliberty.com/ --"Dark Android: 2017 Edition" Link: http://darkandroid.info --”Sovryn Universe, Vol. 1” Link: https://amzn.to/2MrvfEy -------------------------------------------------------------------------Make easy monthly donations through Patreon: patreon.com/sovryntech Donate with Crypto! BTC: 3K7UckYuEFWZLABfJktqxqPbgajYZTEzNW Zcash Address: t1MrX6XtS8Mhs6P4fW39d5PaWJ4jqguBY4Z Donate with PayPal! Link: http://donate.zog.ninja Donate with our Amazon Wish List! Link: http://wishlist.zog.ninja -------------------------------------------------------------------------You can e-mail the show at: bbs@sovryntech.com-------------------------------------------------------------------------You can also visit our IRC channel on Freenode: #SovNet Or just go to: http://irc.zog.ninja -------------------------------------------------------------------------http://sovryntech.com https://twitter.com/sovryntech
Wir reden diese Woche über ARM Linux und das Pinebook.
Wir reden diese Woche über ARM Linux und das Pinebook.
Jason finally discovers the bottomless well of potential that is the Raspberry Pi, and talks about his first experience with Raspbian. Then Joe and Jason take a nostalgic deep dive into retro gaming on both the Raspberry Pi and the Pinebook. Plus some final thoughts on openSUSE Tumbleweed and Leap.
Jason finally discovers the bottomless well of potential that is the Raspberry Pi, and talks about his first experience with Raspbian. Then Joe and Jason take a nostalgic deep dive into retro gaming on both the Raspberry Pi and the Pinebook.
iTunes – https://itunes.apple.com/us/podcast/minipc–show–podnutz/id1087233346?mt=2# RSS – http://feeds.feedburner.com/podnutz/minipcshow Show – http://podnutz.com/category/minipc/ Live Video And Chat – Only via Patreon http://patreon.com/theminipcshow Email – minipc@podnutz.com Form Email – http://podnutz.com/minipcshowcontactform/ Hosted by: Steve McLaughlin – DoorToDoorGeek – http://podnutz.com Brian – AskTheCableGuy FlyingRich – http://www.FlyingRich.com Podnutz Mugs – http://code4sale.com/podnutz/ AliExpress Affiliate Link – http://www.dpbolvw.net/click–7648860–12574854 Links: The New Pinebook Pro Will Challenge Google Chromebooks For $199 The Pinebook is […]
Muy buenas amante de GNU/Linux y el Software Libre!!! Bienvenido a un nuevo episodio, el número 69, de Podcast Linux. Un saludo muy fuerte y cariñoso de quien te habla, Juan Febles. Hoy vamos a disfrutar de nuevo de la presencia de Aleix Pol, desarrollador, vicepresidente de KDE Internacional y miembro activo en portar KDE Neon a Pinebook. **Contacto: **Twitter: https://twitter.com/aleixpol Telegram:https://t.me/AleixPol Grupo Telegram Cañas y Bravas: https://t.me/kde_canasbravas Correo:aleixpol@kde.org
DragonflyBSD 5.4 has been released, down the Gopher hole with OpenBSD, OpenBSD in stereo with VFIO, BSD/OS the best candidate for legally tested open source Unix, OpenBGPD adds diversity to the routing server landscape, and more. Headlines DragonflyBSD 5.4 released DragonFly version 5.4 brings a new system compiler in GCC 8, improved NUMA support, a large of number network and virtual machine driver updates, and updates to video support. This release is 64-bit only, as with previous releases. The details of all commits between the 5.2 and 5.4 branches are available in the associated commit messages for 5.4.0rc and 5.4.0. Big-ticket items Much better support for asymmetric NUMA (Non-Uniform Memory Access) configurations. In particular, both the memory subsystem and the scheduler now understand the Threadripper 2990WX’s architecture. The scheduler will prioritize CPU nodes with direct-attached memory and the memory subsystem will normalize memory queues for CPU nodes without direct-attached memory (which improves cache locality on those CPUs). Incremental performance work. DragonFly as a whole is very SMP friendly. The type of performance work we are doing now mostly revolves around improving fairness for shared-vs-exclusive lock clashes, reducing cache ping-ponging due to non-contending SMP locks (i.e. massive use of shared locks on shared resources), and so forth. Major updates to dports brings us to within a week or two of FreeBSD’s ports as of this writing, in particular major updates to chromium, and making the whole mess work with gcc-8. Major rewriting of the tty clist code and the tty locking code, significantly improving concurrency across multiple ttys and ptys. GCC 8 DragonFly now ships with GCC 8.0, and runs as the default compiler. It is also now used for building dports. GCC 4.7.4 and GCC 5.4.1 are still installed. 4.7.4 is our backup compiler, and 5.4.1 is still there to ensure a smooth transition, but should generally not be used. buildworld builds all three by default to ensure maximum compatibility. Many passes through world sources were made to address various warnings and errors the new GCC brought with it. HAMMER2 HAMMER2 is recommended as the default root filesystem in non-clustered mode. Clustered support is not yet available. Increased bulkfree cache to reduce the number of iterations required. Fixed numerous bugs. Improved support on low-memory machines. Significant pre-work on the XOP API to help support future networked operations. Details Checksums MD5 (dfly-x86_64-5.4.0_REL.img) = 7277d7cffc92837c7d1c5dd11a11b98f MD5 (dfly-x86_64-5.4.0_REL.iso) = 6da7abf036fe9267479837b3c3078408 MD5 (dfly-x86_64-5.4.0_REL.img.bz2) = a77a072c864f4b72fd56b4250c983ff1 MD5 (dfly-x86_64-5.4.0_REL.iso.bz2) = 4dbfec6ccfc1d59c5049455db914d499 Downloads Links DragonFly BSD is 64-bit only, as announced during the 3.8 release. USB: dfly-x86_64-5.4.0_REL.img as bzip2 file ISO: dfly-x86_64-5.4.0_REL.iso as bzip2 file Uncompressed ISO: dfly-x86_64-5.4.0_REL.iso (For use with VPS providers as an install image.) Down the Gopher hole with OpenBSD, Gophernicus, and TLS In the early 2000s I thought I had seen the worst of the web - Java applets, Macromedia (>Adobe) Flash, animated GIFs, javascript snow that kept you warm in the winter by burning out your CPU, and so on. For a time we learned from these mistakes, and started putting the burden on the server-side - then with improvements in javascript engines we started abusing it again with JSON/AJAX and it all went down hill from there. Like cloud computing, blockchains, machine learning and a tonne of other a la mode technologies around today - most users and service providers don’t need websites that consume 1GB of memory processing JS and downloading 50MB of compressed data just to read Alice’s one-page travel blog or Bob’s notes on porting NetBSD to his blood-pressure monitor. Before the HTTP web we relied on Prestel/Minitel style systems, BBS systems, and arguably the most accessible of all - Gopher! Gopher was similar to the locally accessed AmigaGuide format, in that it allowed users to search and retrieve documents interactively, with links and cross-references. Its efficiency and distraction-free nature make it attractive to those who are tired of the invasive, clickbait, ad-filled, javascript-laden web2/3.x. But enough complaining and evangelism - here’s how to get your own Gopher Hole! Gophernicus is a modern gopher daemon which aims to be secure (although it still uses inetd -_-); it’s even in OpenBSD ports so at least we can rely on it to be reasonably audited. If you need a starting point with Gopher, SDF-EU’s wiki has a good article here. https://sdfeu.org/w/tutorials:gopher Finally, if you don’t like gopher(1) - there’s always lynx(1) or NCSA Mosaic! https://cryogenix.net/NCSA_Mosaic_OpenBSD.html I’ve added TLS support to Gophernicus so you don’t need to use stunnel anymore. The code is ugly and unpolished though so I wouldn’t recommend for production use. https://github.com/0x16h/gophernicus https://github.com/0x16h/gophernicus/blob/master/INSTALL.openbsd News Roundup OpenBSD in Stereo with Linux VFIO I use a Huawei Matebook X as my primary OpenBSD laptop and one aspect of its hardware support has always been lacking: audio never played out of the right-side speaker. The speaker did actually work, but only in Windows and only after the Realtek Dolby Atmos audio driver from Huawei was installed. Under OpenBSD and Linux, and even Windows with the default Intel sound driver, audio only ever played out of the left speaker. Now, after some extensive reverse engineering and debugging with the help of VFIO on Linux, I finally have audio playing out of both speakers on OpenBSD. VFIO The Linux kernel has functionality called VFIO which enables direct access to a physical device (like a PCI card) from userspace, usually passing it to an emulator like QEMU. To my surprise, these days, it seems to be primarily by gamers who boot Linux, then use QEMU to run a game in Windows and use VFIO to pass the computer’s GPU device through to Windows. By using Linux and VFIO, I was able to boot Windows 10 inside of QEMU and pass my laptop’s PCI audio device through to Windows, allowing the Realtek audio drivers to natively control the audio device. Combined with QEMU’s tracing functionality, I was able to get a log of all PCI I/O between Windows and the PCI audio device. Using VFIO To use VFIO to pass-through a PCI device, it first needs to be stubbed out so the Linux kernel’s default drivers don’t attach to it. GRUB can be configured to instruct the kernel to ignore the PCI audio device (8086:9d71) and explicitly enable the Intel IOMMU driver by adding the following to /etc/default/grub and running update-grub With the audio device stubbed out, a new VFIO device can be created from it Then the VFIO device (00:1f.3) can be passed to QEMU I was using my own build of QEMU for this, due to some custom logging I needed (more on that later), but the default QEMU package should work fine. The events.txt was a file of all VFIO events I wanted logged (which was all of them). Since I was frequently killing QEMU and restarting it, Windows 10 wanted to go through its unexpected shutdown routine each time (and would sometimes just fail to boot again). To avoid this and to get a consistent set of logs each time, I used qemu-img to take a snapshot of a base image first, then boot QEMU with that snapshot. The snapshot just gets thrown away the next time qemu-img is run and Windows always starts from a consistent state. QEMU will now log each VFIO event which gets saved to a debug-output file. With a full log of all PCI I/O activity from Windows, I compared it to the output from OpenBSD and tried to find the magic register writes that enabled the second speaker. After days of combing through the logs and annotating them by looking up hex values in the documentation, diffing runtime register values, and even brute-forcing it by mechanically duplicating all PCI I/O activity in the OpenBSD driver, nothing would activate the right speaker. One strange thing that I noticed was if I booted Windows 10 in QEMU and it activated the speaker, then booted OpenBSD in QEMU without resetting the PCI device’s power in-between (as a normal system reboot would do), both speakers worked in OpenBSD and the configuration that the HDA controller presented was different, even without any changes in OpenBSD. A Primer on Intel HDA Most modern computers with integrated sound chips use an Intel High Definition Audio (HDA) Controller device, with one or more codecs (like the Realtek ALC269) hanging off of it. These codecs do the actual audio processing and communicate with DACs and ADCs to send digital audio to the connected speakers, or read analog audio from a microphone and convert it to a digital input stream. In my Huawei Matebook X, this is done through a Realtek ALC298 codec. On OpenBSD, these HDA controllers are supported by the azalia(4) driver, with all of the per-codec details in the lengthy azalia_codec.c file. This file has grown quite large with lots of codec- and machine-specific quirks to route things properly, toggle various GPIO pins, and unmute speakers that are for some reason muted by default. The azalia driver talks to the HDA controller and sets up various buffers and then walks the list of codecs. Each codec supports a number of widget nodes which can be interconnected in various ways. Some of these nodes can be reconfigured on the fly to do things like turning a microphone port into a headphone port. The newer Huawei Matebook X Pro released a few months ago is also plagued with this speaker problem, although it has four speakers and only two work by default. A fix is being proposed for the Linux kernel which just reconfigures those widget pins in the Intel HDA driver. Unfortunately no pin reconfiguration is enough to fix my Matebook X with its two speakers. While reading more documentation on the HDA, I realized there was a lot more activity going on than I was able to see through the PCI tracing. For speed and efficiency, HDA controllers use a DMA engine to transfer audio streams as well as the commands from the OS driver to the codecs. In the output above, the CORBWP=0; size=256 and RIRBRP=0, size=256 indicate the setup of the CORB (Command Output Ring Buffer) and RIRB (Response Input Ring Buffer) each with 256 entries. The HDA driver allocates a DMA address and then writes it to the two CORBLBASE and CORBUBASE registers, and again for the RIRB. When the driver wants to send a command to a codec, such as CORB_GET_PARAMETER with a parameter of COP_VOLUME_KNOB_CAPABILITIES, it encodes the codec address, the node index, the command verb, and the parameter, and then writes that value to the CORB ring at the address it set up with the controller at initialization time (CORBLBASE/CORBUBASE) plus the offset of the ring index. Once the command is on the ring, it does a PCI write to the CORBWP register, advancing it by one. This lets the controller know a new command is queued, which it then acts on and writes the response value on the RIRB ring at the same position as the command (but at the RIRB’s DMA address). It then generates an interrupt, telling the driver to read the new RIRBWP value and process the new results. Since the actual command contents and responses are handled through DMA writes and reads, these important values weren’t showing up in the VFIO PCI trace output that I had gathered. Time to hack QEMU. Logging DMA Memory Values in QEMU Since DMA activity wouldn’t show up through QEMU’s VFIO tracing and I obviously couldn’t get Windows to dump these values like I could in OpenBSD, I could make QEMU recognize the PCI write to the CORBWP register as an indication that a command has just been written to the CORB ring. My custom hack in QEMU adds some HDA awareness to remember the CORB and RIRB DMA addresses as they get programmed in the controller. Then any time a PCI write to the CORBWP register is done, QEMU fetches the new CORB command from DMA memory, decodes it into the codec address, node address, command, and parameter, and prints it out. When a PCI read of the RIRBWP register is requested, QEMU reads the response and prints the corresponding CORB command that it stored earlier. With this hack in place, I now had a full log of all CORB commands and RIRB responses sent to and read from the codec: An early version of this patch left me stumped for a few days because, even after submitting all of the same CORB commands in OpenBSD, the second speaker still didn’t work. It wasn’t until re-reading the HDA spec that I realized the Windows driver was submitting more than one command at a time, writing multiple CORB entries and writing a CORBWP value that was advanced by two. This required turning my CORB/RIRB reading into a for loop, reading each new command and response between the new CORBWP/RIRBWP value and the one previously seen. Sure enough, the magic commands to enable the second speaker were sent in these periods where it submitted more than one command at a time. Minimizing the Magic The full log of VFIO PCI activity from the Windows driver was over 65,000 lines and contained 3,150 CORB commands, which is a lot to sort through. It took me a couple more days to reduce that down to a small subset that was actually required to activate the second speaker, and that could only be done through trial and error: Boot OpenBSD with the full list of CORB commands in the azalia driver Comment out a group of them Compile kernel and install it, halt the QEMU guest Suspend and wake the laptop, resetting PCI power to the audio device to reset the speaker/Dolby initialization and ensure the previous run isn’t influencing the current test (I’m guessing there is an easier to way to reset PCI power than suspending the laptop, but oh well) Start QEMU, boot OpenBSD with the new kernel Play an MP3 with mpg123 which has alternating left- and right-channel audio and listen for both channels to play This required a dozen or so iterations because sometimes I’d comment out too many commands and the right speaker would stop working. Other times the combination of commands would hang the controller and it wouldn’t process any further commands. At one point the combination of commands actually flipped the channels around so the right channel audio was playing through the left speaker. The Result After about a week of this routine, I ended up with a list of 662 CORB commands that are needed to get the second speaker working. Based on the number of repeated-but-slightly-different values written with the 0x500 and 0x400 commands, I’m guessing this is some kind of training data and that this is doing the full Dolby/Atmos system initialization, not just turning on the second speaker, but I could be completely wrong. In any case, the stereo sound from OpenBSD is wonderful now and I can finally stop downmixing everything to mono to play from the left speaker. In case you ever need to do this, sndiod can be run with -c 0:0 to reduce the channels to one. Due to the massive size of the code needed for this quirk, I’m not sure if I’ll be committing it upstream in OpenBSD or just saving it for my own tree. But at least now the hardware support chart for my Matebook is all yeses for the things I care about. I’ve also updated the Linux bug report that I opened before venturing down this path, hoping one of the maintainers of that HDA code that works at Intel or Realtek knew of a solution I could just port to OpenBSD. I’m curious to see what they’ll do with it. Why BSD/OS is the best candidate for being the only tested legally open UNIX Introduction The UNIX® system is an old operating system, possibly older than many of the readers of this post. However, despite its age, it still has not been open sourced completely. In this post, I will try to detail which parts of which UNIX systems have not yet been open sourced. I will focus on the legal situation in Germany in particular, taking it representative of European law in general – albeit that is a stretch, knowing the diversity of European jurisdictions. Please note that familiarity with basic terms of copyright law is assumed. Ancient UNIX The term “Ancient UNIX” refers to the versions of UNIX up to and including Seventh Edition UNIX (1979) including the 32V port to the VAX. Ancient UNIX was created at Bell Laboratories, a subsidiary of AT&T at the time. It was later transferred of the AT&T UNIX Support Group, then AT&T Information Systems and finally the AT&T subsidiary UNIX System Laboratories, Inc. (USL). The legal situation differs between the United States of America and Germany. In a ruling as part of the UNIX System Laboratories, Inc. v. Berkeley Software Design, Inc. (USL v. BSDi) case, a U.S. court found that USL had no copyright to the Seventh Edition UNIX system and 32V – arguably, by extension, all earlier versions of Ancient UNIX as well – because USL/AT&T had failed to affix copyright notices and could not demonstrate a trade secret. Due to the obsessive tendency of U.S. courts to consider themselves bound to precedents (cf. the infamous Pierson v. Post case), it can be reasonably expected that this ruling would be honored and applied in subsequent cases. Thus under U.S. law, Ancient UNIX can be safely assumed to belong in the public domain. The situation differs in Germany. Unlike the U.S., copyright never needed registration in order to exist. Computer programs are works in the sense of the German 1965 Act on Copyright and Related Rights (Copyright Act, henceforth CopyA) as per CopyA § 2(1) no. 1. Even prior to the amendment of CopyA § 2(1) to include computer programs, computer programs have been recognized as copyrightable works by the German Supreme Court (BGHZ 112, 264 Betriebssystem, no. 19); CopyA § 137d(1) rightly clarifies that. The copyright holder at 1979 would still have been USL via Bell Labs and AT&T. Copyright of computer programs is transferred to the employer upon creation under CopyA § 69(1). Note that this does not affect expiry (Daniel Kaboth/Benjamin Spies, commentary on CopyA §§ 69a‒69g, in: Hartwig Ahlberg/Horst-Peter Götting (eds.), Urheberrecht: UrhG, KUG, VerlG, VGG, Kommentar, 4th ed., C. H. Beck, 2018, no. 16 ad CopyA § 69b; cf. Bundestag-Drucksache [BT-Drs.] 12/4022, p. 10). Expiry occurs 70 years after the death of the (co-)author that died most recently as per CopyA § 65(1) and 64; this has been the case since at least the 1960s, meaning there is no way for copyright to have expired already (old version, as per Bundesgesetzblatt Part I No. 51 of September 16, 1965, pp. 1273‒1294). In Germany, private international law applies the so-called “Territorialitätsprinzip” for intellectual property rights. This means that the effect of an intellectual property right is limited to the territory of a state (Anne Lauber-Rönsberg, KollisionsR, in: Hartwig Ahlberg/Horst-Peter Götting (eds.), ibid., pp. 2241 et seqq., no. 4). Additionally, the “Schutzlandprinzip” applies; this means that protection of intellectual property follows the lex loci protectionis, i.e. the law of the country for which protection is sought (BGH GRUR 2015, 264 HiHotel II, no. 25; BGH GRUR 2003, 328 Sender Felsberg, no. 24), albeit this is criticized in parts of doctrine (Lauber-Rönsberg, ibid., no. 10). The “Schutzlandprinzip” requires that the existence of an intellectual property right be verified as well (BGH ZUM 2016, 522 Wagenfeld-Leuchte II, no. 19). Thus, in Germany, copyright on Ancient UNIX is still alive and well. Who has it, though? A ruling by the U.S. Court of Appeals, Tenth Circuit, in the case of The SCO Group, Inc. v. Novell, Inc. (SCO v. Novell) in the U.S. made clear that Novell owns the rights to System V – thus presumably UNIX System III as well – and Ancient UNIX, though SCO acquired enough rights to develop UnixWare/OpenServer (Ruling 10-4122 [D.C. No. 2:04-CV-00139-TS], pp. 19 et seq.). Novell itself was purchased by the Attachmate Group, which was in turn acquired by the COBOL vendor Micro Focus. Therefore, the rights to SVRX and – outside the U.S. – are with Micro Focus right now. If all you care about is the U.S., you can stop reading about Ancient UNIX here. So how does the Caldera license factor into all of this? For some context, the license was issued January 23, 2002 and covers Ancient UNIX (V1 through V7 including 32V), specifically excluding System III and System V. Caldera, Inc. was founded in 1994. The Santa Cruz Operation, Inc. sold its rights to UNIX to Caldera in 2001, renamed itself to Tarantella Inc. and Caldera renamed itself The SCO Group. Nemo plus iuris ad alium transferre potest quam ipse habet; no one can transfer more rights than he has. The question now becomes whether Caldera had the rights to issue the Caldera license. I’ve noted it above but it needs restating: Foreign decisions are not necessarily accepted in Germany due to the “Territorialitätsprinzip” and “Schutzlandprinzip” – however, I will be citing a U.S. ruling for its assessment of the facts for the sake of simplicity. As per ruling 10-4122, “The district court found the parties intended for SCO to serve as Novell’s agent with respect to the old SVRX licenses and the only portion of the UNIX business transferred outright under the APA [asset purchase agreement] was the ability to exploit and further develop the newer UnixWare system. SCO was able to protect that business because it was able to copyright its own improvements to the system. The only reason to protect the earlier UNIX code would be to protect the existing SVRX licenses, and the court concluded Novell retained ultimate control over that portion of the business under the APA.” The relevant agreements consist of multiple pieces: the base Asset Purchase Agreement “APA” (Part I) the base Asset Purchase Agreement “APA” (Part II) the Operating Agremeent and Amendment 1 to the APA the Amendment 2 to the APA The APA dates September 19, 1995, from before the Caldera license. Caldera cannot possibly have acquired rights that The Santa Cruz Operation, Inc. itself never had. Furthermore, I’ve failed to find any mention of Ancient UNIX; all that is transferred is rights to SVRX. Overall, I believe that the U.S. courts’ assesment of the facts represents the situation accurately. Thus for all intents and purposes, UNIX up to and including System V remained with Novell/Attachmate/Micro Focus. Caldera therefore never had any rights to Ancient UNIX, which means it never had the rights to issue the Caldera license. The Caldera license is null and void – in the U.S. because the copyright has been lost due to formalities, everywhere else because Caldera never had the rights to issue it. The first step to truly freeing UNIX would this be to get Micro Focus to re-issue the Caldera license for Ancient UNIX, ideally it would now also include System III and System V. BSD/OS Another operating system near UNIX is of interest. The USL v. BSDi lawsuit includes two parties: USL, which we have seen above, and Berkeley Software Design, Inc. BSDi sold BSD/386 (later BSD/OS), which was a derivative of 4.4BSD. The software parts of the BSDi company were acquired by Wind River Systems, whereas the hardware parts went to iXsystems. Copyright is not disputed there, though Wind River Systems ceased selling BSD/OS products 15 years ago, in 2003. In addition, Wind River System let their trademark on BSD expire, though this is without consequence for copyright. BSD/OS is notable in the sense that it powered much of early internet infrastructure. Traces of its legacy can still be found on Richard Stevens’ FAQ. To truly make UNIX history free, BSD/OS would arguably also need to see a source code release. BSD/OS at least in its earliest releases under BSDi would ship with source code, though under a non-free license, far from BSD or even GPL licensing. System V The fate of System V as a whole is difficult to determine. Various licenses have been granted to a number of vendors (Dell UNIX comes to mind; HP for HP-UX, IBM for AIX, SGI UNIX, etc.). Sun released OpenSolaris – notoriously, Oracle closed the source to Solaris again after its release –, which is a System V Release 4 descendant. However, this means nothing for the copyright or licensing status of System V itself. Presumably, the rights with System V still remain with Novell (now Micro Focus): SCO managed to sublicense rights to develop and sell UnixWare/OpenServer, themselves System V/III descendants, to unXis, Inc. (now known as Xinuos, Inc.), which implies that Xinuos is not the copyright holder of System V. Obviously, to free UNIX, System V and its entire family of descendants would also need to be open sourced. However, I expect tremendous resistance on part of all the companies mentioned. As noted in the “Ancient UNIX” section, Micro Focus alone would probably be sufficient to release System V, though this would mean nothing for the other commercial System V derivatives. Newer Research UNIX The fate of Bell Labs would be a different one; it would go on to be purchased by Lucent, now part of Nokia. After commercial UNIX got separated out to USL, Research UNIX would continue to exist inside of Bell Labs. Research UNIX V8, V9 and V10 were not quite released by Alcatel-Lucent USA Inc. and Nokia in 2017. However, this is merely a notice that the companies involved will not assert their copyrights only with respect to any non-commercial usage of the code. It is still not possible, over 30 years later, to freely use the V8 code. Conclusion In the U.S., Ancient UNIX is freely available. People located everywhere else, however, are unable to legally obtain UNIX code for any of the systems mentioned above. The exception being BSD/OS, assuming a purchase of a legitimate copy of the source code CD. This is deeply unsatisfying and I implore all involved companies to consider open sourcing (preferably under a BSD-style license) their code older than a decade, if nothing else, then at least for the sake of historical purposes. I would like to encourage everybody reading this to consider reaching out to Micro Focus and Wind River Systems about System V and BSD/OS, respectively. Perhaps the masses can change their minds. A small note about patents: Some technologies used in newer iterations of the UNIX system (in particular the System V derivatives) may be encumbered with software patents. An open source license will not help against patent infringement claims. However, the patents on anything used in the historical operating systems will certainly have expired by now. In addition, European readers can ignore this entirely – software patents just aren’t a thing. OpenBGPD - Adding Diversity to the Route Server Landscape Introduction As of last year, there was effectively only a single solution in the Route Server vendor market: the BIRD Internet routing daemon. NIC.CZ (the organisation developing BIRD) has done fantastic work on maintaining their BGP-4 implementation, however, it’s not healthy to have virtually every Internet Exchange Point (IXP) in the RIPE NCC service region depend on a single open source project. The current situation can be compared to the state of the DNS root nameservers back in 2002 - their dependence on the BIND nameserver daemon and the resulting development of NSD as an alternative by NLnet, in cooperation with the RIPE NCC. OpenBGPD used to be one of the most popular Route Server implementations until the early 2010s. OpenBGPD’s main problem was that its performance couldn’t keep up with the Internet’s growth, so it lost market share. An analysis by Job Snijders suggested that a modernised OpenBGPD distribution would be a most viable option to regain diversity on the Route Server level. Missing features in OpenBGPD The following main missing features were identified in OpenBGPD: Performance In previous versions of OpenBGPD, the filtering performance didn’t allow proper filtering of all EBGP sessions. Current best practice at IXP Route Servers is to carefully evaluate and validate of all routes learned from EBGP peers. The OpenBGPD ruleset required to do correct filtering (in many deployment scenarios) was simply too lengthy - and negatively impacted service performance during configuration reloads. While filtering performance is the biggest bottleneck, general improvements to the Routing Information Base were also made to improve scalability. IXP Route Servers with a few hundred peering sessions are commonplace and adding new sessions shouldn’t impact the Route Servers’ service to other peers. We found that performance was the most pressing issue that needed to be tackled. Lack of RPKI Origin Validation As we’ve seen, Internet operators are moving to adopt RPKI based BGP Origin Validation. While it was theoretically possible to emulate RFC 6811-style Origin Validation in previous versions of OpenBGPD, the required configuration wasn’t optimised for performance and wasn’t user friendly. We believe that BGP Origin Validation should be as easy as possible - this requires BGP-4 vendors to implement native, optimised routines for Origin Validation. Of course, enabling Origin Validation shouldn’t have an impact on performance either when processing BGP updates or when updating the Route Origin Authorisation (ROA) table itself. Portability OpenBGPD is an integral part of OpenBSD, but IXPs may prefer to run their services infrastructure on an operating system of their choice. Making sure that there’s a portable OpenBGPD version which follows the OpenBSD project release cycle will give IXPs this option. Development steps By addressing the issues mentioned above, we could bring back OpenBGPD as a viable Route Server implementation. Since I was one of the core OpenBGPD developers, I was asked if I wanted to pick up this project again. Thanks to the funding from the RIPE NCC Project Fund, this was possible. Starting in June 2018, I worked full time on this important community project. Over the last few months, many of the problems are already addressed and are now part of the OpenBSD 6.4 release. So far, 154 commits were made to OpenBGPD during the 6.4 development cycle - around 8% of all commits ever to OpenBGPD! This shows that due to funding and dedicated resources, a lot of work could be pushed into the latest release of OpenBGPD. OpenBGPD 6.4 The OpenBGPD version, as part of OpenBSD 6.4 release, demonstrates great progress. Even though there have been many changes to the core of OpenBGPD, the released version is as solid and reliable as previous releases and the many bug fixes and improvements make this the best OpenBGPD release so far. The changes in the filter language allow users to write more efficient rulesets while the introduction of RPKI origination validation fixes an important missing feature. For IXPs, OpenBGPD now is an alternative again. There are still open issues, but the gap is closing! Feature highlights The following changes should be highlighted: Introduction of background soft-reconfiguration on config reload. Running the soft-reconfiguration task in the background allows for new updates and withdraws to be processed at the same time. This improves convergence time - one of the key metrics for Route Servers. BGP Origin Validation when a roa-set is configured Every EBGP route announcement is validated against the locally configured VRP table entries. Depending on the validation process’s outcome, the validation state is set to valid, invalid or not found. The filter language has been extended to allow checking for the origin validation state, and thanks to this, it is possible to deny invalid prefixes or regard valid prefixes different to the ones that aren’t found. The roa-set table is read from the configuration file and updated during configuration reloads. On production systems reloading the roa-set and applying it to all prefixes is done in a couple of seconds. Fast prefix-set lookups In OpenBSD 6.3 prefix-sets got introduced in OpenBGPD. A prefix-set combines many prefix lookups into a single filter rule. The original implementation wasn’t optimised but now a fast trie lookup is used. Thanks to this, large IRR DB prefix tables can now be implemented efficiently. Introduction of as-sets Similar to prefix-sets, as-sets help group many AS numbers into a single lookup. Thanks to this, large IRR DB origin AS tables can be implemented efficiently. Introduction of origin-sets Looking at the configurations of Route Servers doing full filtering, it was noticed that a common lookup was binding a prefix to an origin AS - similar to how a roa-set is used for RPKI. These origin-set tables are used to extend the IRR prefix lookup and generated from alternative sources. Improving third party tools Users can only benefit from the changes introduced in OpenBGPD 6.4 when the surrounding 3rd party tools are adjusted accordingly. Two opensource projects such as bgpq3 and arouteserver are frequently used by network operators and IXPs to generate BGP configurations. Thanks to our contributions to those projects, we were able to get them ready for all the new features in OpenBGPD. bgpq3 was extended to create as-set and prefix-set tables based on IRR DB entries. This is replacing the old way of doing the same with a large amount of filter rules. Thanks to the quick response from the bgpq3 maintainer, it was possible to ship OpenBSD 6.4 with a bgpq3 package that includes all the new features. arouteserver was adjusted to implement RPKI roa-set, as-set, prefix-set, and origin-set to generate a much better-performing configurations for the 6.4 version. With the v0.20.0 release of arouteserver, IXPs are able to generate an OpenBGPD configuration which is a ton faster but also implements the new functionalities. Looking at YYCIX (the resident IXP in Calgary, Canada) the ruleset generated by arouteserver was reduced from 370,000 rules to well under 6,000 rules. This resulted in the initial convergence time dropping from over 1 hour to less than 2 minutes, and subsequent configuration reloads are hitless and no longer noticeable. What still needs to be done A sizeable chunk of work still left on the table is the rework of the RIB data structures in OpenBGPD - these haven’t been changed since the initial design of OpenBGPD in 2003. There’s currently ongoing work (in small steps, to avoid jeopardising the stability of OpenBGPD) to modernise these data-structures. The goal is to provide better decoupling of the filter step from storing RIB database changes, to pave the way to multi-threaded operations at a later point. Looking forward Job Snijders oversaw this year’s fundraising and project management, he adds: It’s been incredibly productive to create an environment where a core developer is allowed to work full time on the OpenBGPD code base. However, it’s important to note there still is room for a number of new features to help improve its operational capabilities (such as BMP, RFC 7313, ADD_PATH, etc). It’d be beneficial to the Internet community at large if we can extend Claudio Jeker’s involvement for another year. Open source software doesn’t grow on trees! Strategic investments are the only way to keep OpenBGPD’s roadmap aligned with Internet growth and operator requirements. Beastie Bits DragonFly - git: annotated tag v5.5.0 created Torchlight 2 on NetBSD Older, but still good USENIX Login Article on Capsicum The Super Capsicumizer 9000 Dedicated and Virtual Server PXE provisioning tool Cirrus CI have announced FreeBSD support NetBSD PineBook Gameplay BSDCan 2019 CfP is out Allan’s first ZFS array, Zulu, turned 7 years old on Nov 29th Feedback/Questions Malcom - Installing Drivers in Development Samir - Introduction to ZFS Newnix - Drive Failures Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
Muy buenas amante de GNU/Linux y el Software Libre. Bienvenido a un nuevo episodio, el número 66, de Podcast Linux. Un saludo muy fuerte y cariñoso de quien te habla, Juan Febles. Hoy te dejo un especial sobre Pinebook, el netbook ARM de bajo coste y Open Source de Pine64. Sorteo: Gana unas pegatinas Pinebook Leer más#66 Especial Pinebook[…] La entrada #66 Especial Pinebook aparece primero en AVpodcast.
Muy buenas amante de GNU/Linux y el Software Libre. Bienvenido a un nuevo episodio, el número 66, de Podcast Linux. Un saludo muy fuerte y cariñoso de quien te habla, Juan Febles. Hoy te dejo un especial sobre Pinebook, el netbook ARM de bajo coste y Open Source de Pine64. Sorteo: Gana unas pegatinas Pinebook sencillamente. Sígueme en Twitter y retuitea el siguiente tuit y podrán ser tuyas: https://twitter.com/podcastlinux/status/1070194887344164864
Joe’s long-awaited Pinebook has finally arrived and we have a good chat about its ups and downs. Plus a packed news section including reproducible builds, ReactOS, mobile news and the usual Plasma love-in. News Plasma updates in the pipeline from Nate Here & Here Purism dev boards when? Lineage OS changing update frequency Samsung... Read More
Joe’s long-awaited Pinebook has finally arrived and we have a good chat about its ups and downs. Plus a packed news section including reproducible builds, ReactOS, mobile news and the usual Plasma love-in. News Plasma updates in the pipeline from Nate Here & Here Purism dev boards when? Lineage OS changing update frequency Samsung... Read More
Revimos o valioso feedback dos ouvintes, voltámos a falar do Pinebook, Olimex e Pihole. Depois passámos apelos à participação da comunidade, mas o prato principal foi a entrevista à Professora Manuela Aparício do Mestrado em Open Source Software do ISCTE/IUL. No fim além da agenda ainda fizemos uma pequena digressão pelo Open Source Lisboa 2018.
Revimos o valioso feedback dos ouvintes, voltámos a falar do Pinebook, Olimex e Pihole. Depois passámos apelos à participação da comunidade, mas o prato principal foi a entrevista à Professora […]
Running OpenBSD/NetBSD on FreeBSD using grub2-bhyve, vermaden’s FreeBSD story, thoughts on OpenBSD on the desktop, history of file type info in Unix dirs, Multiboot a Pinebook KDE neon image, and more. ##Headlines OpenBSD/NetBSD on FreeBSD using grub2-bhyve When I was writing a blog post about the process title, I needed a couple of virtual machines with OpenBSD, NetBSD, and Ubuntu. Before that day I mainly used FreeBSD and Windows with bhyve. I spent some time trying to set up an OpenBSD using bhyve and UEFI as described here. I had numerous problems trying to use it, and this was the day I discovered the grub2-bhyve tool, and I love it! The grub2-bhyve allows you to load a kernel using GRUB bootloader. GRUB supports most of the operating systems with a standard configuration, so exactly the same method can be used to install NetBSD or Ubuntu. First, let’s install grub2-bhyve on our FreeBSD box: # pkg install grub2-bhyve To run grub2-bhyve we need to provide at least the name of the VM. In bhyve, if the memsize is not specified the default VM is created with 256MB of the memory. # grub-bhyve test GNU GRUB version 2.00 Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions. grub> After running grub-bhyve command we will enter the GRUB loader. If we type the ls command, we will see all the available devices. In the case of the grub2-bhyve there is one additional device called “(host)” that is always available and allows the host filesystem to be accessed. We can list files under that device. grub> ls (host) grub> ls (host)/ libexec/ bin/ usr/ bhyve/ compat/ tank/ etc/ boot/ net/ entropy proc/ lib/ root/ sys/ mnt/ rescue/ tmp/ home/ sbin/ media/ jail/ COPYRIGHT var/ dev/ grub> To exit console simply type ‘reboot’. I would like to install my new operating system under a ZVOL ztank/bhyve/post. On another terminal, we create: # zfs create -V 10G ztank/bhyve/post If you don’t use ZFS for some crazy reason you can also create a raw blob using the truncate(1) command. # truncate -s 10G post.img I recommend installing an operating system from the disk image (installXX.fs for OpenBSD and NetBSD-X.X-amd64-install.img for NetBSD). Now we need to create a device map for a GRUB. cat > /tmp/post.map ls (hd0) (hd0,msdos4) (hd0,msdos1) (hd0,openbsd9) (hd0,openbsd1) (hd1) (host) The hd0 (in this example OpenBSD image) contains multiple partitions. We can check what is on it. grub> ls (hd0,msdos4)/ boot bsd 6.4/ etc/ And this is the partition that contains a kernel. Now we can set a root device, load an OpenBSD kernel and boot: grub> set root=(hd0,msdos4) grub> kopenbsd -h com0 -r sd0a /bsd grub> boot After that, we can run bhyve virtual machine. In my case it is: # bhyve -c 1 -w -u -H -s 0,amd_hostbridge -s 3,ahci-hd,/directory/to/disk/image -s 4,ahci-hd,/dev/zvol/ztank/bhyve/post -s 31,lpc -l com1,stdio post Unfortunately explaining the whole bhyve(8) command line is beyond this article. After installing the operating system remove hd0 from the mapping file and the image from the bhyve(8) command. If you don’t want to type all those GRUB commands, you can simply redirect them to the standard input. cat
In dieser Folge geht es um AMD Ryzen Mini PCs, Flatpak 1.0, Valves Steam Play, Windows 95 App, KDE Neon für Pinebook, Gamescom 2018 und FrOSCon 13. Themen: AMD Ryzen MiniPCs ohne Lüfter Flatpak 1.0 ist da Valve will Windows Spiele unter Linux lauffähig machen per Steam Play Windows 95 nun als App Spielzeug der Woche: KDE Neon für Pinebook GamesCom 2018 Cyberpunk 2077 Die Siedler im Comeback Shadow of the Tomb Raider Marvels Spider Man Sekiro - Shadows die twice FrOSCon 13 Wie immer wünsche ich viel Spaß beim reinhören ;)
Fanless server setup with FreeBSD, NetBSD on pinebooks, another BSDCan trip report, transparent network audio, MirBSD's Korn Shell on Plan9, static site generators on OpenBSD, and more. ##Headlines Silent Fanless FreeBSD Desktop/Server Today I will write about silent fanless FreeBSD desktop or server computer … or NAS … or you name it, it can have multiple purposes. It also very low power solution, which also means that it will not overheat. Silent means no fans at all, even for the PSU. The format of the system should also be brought to minimum, so Mini-ITX seems best solution here. I have chosen Intel based solutions as they are very low power (6-10W), if you prefer AMD (as I often do) the closest solution in comparable price and power is Biostar A68N-2100 motherboard with AMD E1-2100 CPU and 9W power. Of course AMD has even more low power SoC solutions but finding the Mini-ITX motherboard with decent price is not an easy task. For comparison Intel has lots of such solutions below 6W whose can be nicely filtered on the ark.intel.com page. Pity that AMD does not provide such filtration for their products. I also chosen AES instructions as storage encryption (GELI on FreeBSD) today seems as obvious as HTTPS for the web pages. Here is how the system look powered up and working This motherboard uses Intel J3355 SoC which uses 10W and has AES instructions. It has two cores at your disposal but it also supports VT-x and EPT extensions so you can even run Bhyve on it. Components Now, an example system would look like that one below, here are the components with their prices. $49 CPU/Motherboard ASRock J3355B-ITX Mini-ITX $14 RAM Crucial 4 GB DDR3L 1.35V (low power) $17 PSU 12V 160W Pico (internal) $11 PSU 12V 96W FSP (external) $5 USB 2.0 Drive 16 GB ADATA $4 USB Wireless 802.11n $100 TOTAL The PSU 12V 160W Pico (internal) and PSU 12V 96W FSP can be purchased on aliexpress.com or ebay.com for example, at least I got them there. Here is the 12V 160W Pico (internal) PSU and its optional additional cables to power the optional HDDs. If course its one SATA power and one MOLEX power so additional MOLEX-SATA power adapter for about 1$ would be needed. Here is the 12V 96W FSP (external) PSU without the power cord. This gives as total silent fanless system price of about $120. Its about ONE TENTH OF THE COST of the cheapest FreeNAS hardware solution available – the FreeNAS Mini (Diskless) costs $1156 also without disks. You can put plain FreeBSD on top of it or Solaris/Illumos distribution OmniOSce which is server oriented. You can use prebuilt NAS solution based on FreeBSD like FreeNAS, NAS4Free, ZFSguru or even Solaris/Illumos based storage with napp-it appliance. ###An annotated look at a NetBSD Pinebook’s startup Pinebook is an affordable 64-bit ARM notebook. Today we’re going to take a look at the kernel output at startup and talk about what hardware support is available on NetBSD. Photo Pinebook comes with 2GB RAM standard. A small amount of this is reserved by the kernel and framebuffer. NetBSD uses flattened device-tree (FDT) to enumerate devices on all Allwinner based SoCs. On a running system, you can inspect the device tree using the ofctl(8) utility: Pinebook’s Allwinner A64 processor is based on the ARM Cortex-A53. It is designed to run at frequencies up to 1.2GHz. The A64 is a quad core design. NetBSD’s aarch64 pmap does not yet support SMP, so three cores are disabled for now. The interrupt controller is a standard ARM GIC-400 design. Clock drivers for managing PLLs, module clock dividers, clock gating, software resets, etc. Information about the clock tree is exported in the hw.clk sysctl namespace (root access required to read these values). # sysctl hw.clk.sun50ia64ccu0.mmc2 hw.clk.sun50ia64ccu0.mmc2.rate = 200000000 hw.clk.sun50ia64ccu0.mmc2.parent = pllperiph02x hw.clk.sun50ia64ccu0.mmc2.parent_domain = sun50ia64ccu0 Digital Ocean http://do.co/bsdnow ###BSDCan 2018 Trip Report: Mark Johnston BSDCan is a highlight of my summers: the ability to have face-to-face conversations with fellow developers and contributors is invaluable and always helps refresh my enthusiasm for FreeBSD. While in a perfect world we would all be able to communicate effectively over the Internet, it’s often noted that locking a group of developers together in a room can be a very efficient way to make progress on projects that otherwise get strung out over time, and to me this is one of the principal functions of BSD conferences. In my case I was able to fix some kgdb bugs that had been hindering me for months; get some opinions on the design of a feature I’ve been working on for FreeBSD 12.0; hear about some ongoing usage of code that I’ve worked on; and do some pair-debugging of an issue that has been affecting another developer. As is tradition, on Tuesday night I dropped off my things at the university residence where I was staying, and headed straight to the Royal Oak. This year it didn’t seem quite as packed with BSD developers, but I did meet several long-time colleagues and get a chance to catch up. In particular, I chatted with Justin Hibbits and got to hear about the bring-up of FreeBSD on POWER9, a new CPU family released by IBM. Justin was able to acquire a workstation based upon this CPU, which is a great motivator for getting FreeBSD into shape on that platform. POWER9 also has some promise in the server market, so it’s important for FreeBSD to be a viable OS choice there. Wednesday morning saw the beginning of the two-day FreeBSD developer summit, which precedes the conference proper. Gordon Tetlow led the summit and did an excellent job organizing things and keeping to the schedule. The first presentation was by Deb Goodkin of the FreeBSD Foundation, who gave an overview of the Foundation’s role and activities. After Deb’s presentation, present members of the FreeBSD core team discussed the work they had done over the past two years, as well as open tasks that would be handed over to the new core team upon completion of the ongoing election. Finally, Marius Strobl rounded off the day’s presentations by discussing the state and responsibilities of FreeBSD’s release engineering team. One side discussion of interest to me was around the notion of tightening integration with our Bugzilla instance; at moment we do not have any good means to mark a given bug as blocking a release, making it easy for bugs to slip into releases and thus lowering our overall quality. With FreeBSD 12.0 upon us, I plan to help with the triage and fixes for known regressions before the release process begins. After a break, the rest of the morning was devoted to plans for features in upcoming FreeBSD releases. This is one of my favorite discussion topics and typically takes the form of have/need/want, where developers collectively list features that they’ve developed and intend to upstream (have), features that they are missing (need), and nice-to-have features (want). This year, instead of the usual format, we listed features that are intended to ship in FreeBSD 12.0. The compiled list ended up being quite ambitious given how close we are to the beginning of the release cycle, but many individual developers (including myself) have signed up to deliver work. I’m hopeful that most, if not all of it, will make it into the release. After lunch, I attended a discussion led by Matt Ahrens and Alexander Motin on OpenZFS. Of particular interest to me were some observations made regarding the relative quantity and quality of contributions made by different “camps” of OpenZFS users (illumos, FreeBSD and ZoL), and their respective track records of upstreaming enhancements to the OpenZFS project. In part due to the high pace of changes in ZoL, the definition of “upstream” for ZFS has become murky, and of late ZFS changes have been ported directly from ZoL. Alexander discussed some known problems with ZFS on FreeBSD that have been discovered through performance testing. While I’m not familiar with ZFS internals, Alexander noted that ZFS’ write path has poor SMP scalability on FreeBSD owing to some limitations in a certain kernel API called taskqueue(9). I would like to explore this problem further and perhaps integrate a relatively new alternative interface which should perform better. Friday and Saturday were, of course, taken up by BSDCan talks. Friday’s keynote was by Benno Rice, who provided some history of UNIX boot systems as a precursor to some discussion of systemd and the difficulties presented by a user and developer community that actively resist change. The rest of the morning was consumed by talks and passed by quickly. First was Colin Percival’s detailed examination of where the FreeBSD kernel spends time during boot, together with an overview of some infrastructure he added to track boot times. He also provided a list of improvements that have been made since he started taking measurements, and some areas we can further improve. Colin’s existing work in this area has already brought about substantial reductions in boot time; amusingly, one of the remaining large delays comes from the keyboard driver, which contains a workaround for old PS/2 keyboards. While there seems to be general agreement that the workaround is probably no longer needed on most systems, the lingering uncertainty around this prevents us from removing the workaround. This is, sadly, a fairly typical example of an OS maintenance burden, and underscores the need to carefully document hardware bug workarounds. After this talk, I got to see some rather novel demonstrations of system tracing using dwatch, a new utility by Devin Teske, which aims to provide a user-friendly interface to DTrace. After lunch, I attended talks on netdump, a protocol for transmitting kernel dumps over a network after the system has panicked, and on a VPC implementation for FreeBSD. After the talks ended, I headed yet again to the hacker lounge and had some fruitful discussions on early microcode loading (one of my features for FreeBSD 12.0). These led me to reconsider some aspects of my approach and saved me a lot of time. Finally, I continued my debugging session from Wednesday with help from a couple of other developers. Saturday’s talks included a very thorough account by Li-Wen Hsu of his work in organizing a BSD conference in Taipei last year. As one of the attendees, I had felt that the conference had gone quite smoothly and was taken aback by the number of details and pitfalls that Li-Wen enumerated during his talk. This was followed by an excellent talk by Baptiste Daroussin on the difficulties one encounters when deploying FreeBSD in new environments. Baptiste offered criticisms of a number of aspects of FreeBSD, some of which hit close to home as they involved portions of the system that I’ve worked on. At the conclusion of the talks, we all gathered in the main lecture hall, where Dan led a traditional and quite lively auction for charity. I managed to snag a Pine64 board and will be getting FreeBSD installed on it the first chance I get. At the end of the auction, we all headed to ByWard for dinner, concluding yet another BSDCan. Thanks to Mark for sharing his experiences at this years BSDCan ##News Roundup Transparent network audio with mpd & sndiod Landry Breuil (landry@ when wearing his developer hat) wrote in… I've been a huge fan of MPD over the years to centralize my audio collection, and i've been using it with the http output to stream the music as a radio on the computer i'm currently using… audio_output { type "sndio" name "Local speakers" mixer_type "software" } audio_output { type "httpd" name "HTTP stream" mixer_type "software" encoder "vorbis" port "8000" format "44100:16:2" } this setup worked for years, allows me to stream my home radio to $work by tunnelling the port 8000 over ssh via LocalForward, but that still has some issues: a distinct timing gap between the 'local output' (ie the speakers connected to the machine where MPD is running) and the 'http output' caused by the time it takes to reencode the stream, which is ugly when you walk through the house and have a 15s delay sometimes mplayer as a client doesn't detect the pauses in the stream and needs to be restarted i need to configure/start a client on each computer and point it at the sound server url (can do via gmpc shoutcast client plugin…) it's not that elegant to reencode the stream, and it wastes cpu cycles So the current scheme is: mpd -> http output -> network -> mplayer -> sndiod on remote machine | -> sndio output -> sndiod on soundserver Fiddling a little bit with mpd outputs and reading the sndio output driver, i remembered sndiod has native network support… and the mpd sndio output allows you to specify a device (it uses SIO_DEVANY by default). So in the end, it's super easy to: enable network support in sndio on the remote machine i want the audio to play by adding -L to sndiod_flags (i have two audio devices, with an input coming from the webcam): sndiod_flags="-L10.246.200.10 -f rsnd/0 -f rsnd/1" open pf on port 11025 from the sound server ip: pass in proto tcp from 10.246.200.1 to any port 11025 configure a new output in mpd: audio_output { type "sndio" name "sndio on renton" device "snd@10.246.200.10/0" mixer_type "software" } and enable the new output in mpd: $mpc enable 2 Output 1 (Local speakers) is disabled Output 2 (sndio on renton) is enabled Output 3 (HTTP stream) is disabled Results in a big win: no gap anymore with the local speakers, no reencoding, no need to configure a client to play the stream, and i can still probably reproduce the same scheme over ssh from $work using a RemoteForward. mpd -> sndio output 2 -> network -> sndiod on remote machine | -> sndio output 1 -> sndiod on soundserver Thanks ratchov@ for sndiod :) ###MirBSD’s Korn Shell on Plan9 Jehanne Let start by saying that I’m not really a C programmer. My last public contribution to a POSIX C program was a little improvement to the Snort’s react module back in 2008. So while I know the C language well enough, I do not know anything about the subtleness of the standard library and I have little experience with POSIX semantics. This is not a big issue with Plan 9, since the C library and compiler are not standard anyway, but with Jehanne (a Plan 9 derivative of my own) I want to build a simple, loosely coupled, system that can actually run useful free software ported from UNIX. So I ported RedHat’s newlib to Jehanne on top of a new system library I wrote, LibPOSIX, that provides the necessary emulations. I wrote several test, checking they run the same on Linux and Jehanne, and then I begun looking for a real-world, battle tested, application to port first. I approached MirBSD’s Korn Shell for several reason: it is simple, powerful and well written it has been ported to several different operating systems it has few dependencies it’s the default shell in Android, so it’s really battle tested I was very confident. I had read the POSIX standard after all! And I had a test suite! I remember, I thought “Given newlib, how hard can it be?” The porting begun on September 1, 2017. It was completed by tg on January 5, 2018. 125 nights later. Turn out, my POSIX emulation was badly broken. Not just because of the usual bugs that any piece of C can have: I didn’t understood most POSIX semantics at all! iXsystems ###Static site generator with rsync and lowdown on OpenBSD ssg is a tiny POSIX-compliant shell script with few dependencies: lowdown(1) to parse markdown, rsync(1) to copy temporary files, and entr(1) to watch file changes. It generates Markdown articles to a static website. It copies the current directory to a temporary on in /tmp skipping .* and _*, renders all Markdown articles to HTML, generates RSS feed based on links from index.html, extracts the first tag from every article to generate a sitemap and use it as a page title, then wraps articles with a single HTML template, copies everything from the temporary directory to $DOCS/ Why not Jekyll or “$X”? ssg is one hundred times smaller than Jekyll. ssg and its dependencies are about 800KB combined. Compare that to 78MB of ruby with Jekyll and all the gems. So ssg can be installed in just few seconds on almost any Unix-like operating system. Obviously, ssg is tailored for my needs, it has all features I need and only those I use. Keeping ssg helps you to master your Unix-shell skills: awk, grep, sed, sh, cut, tr. As a web developer you work with lots of text: code and data. So you better master these wonderful tools. Performance 100 pps. On modern computers ssg generates a hundred pages per second. Half of a time for markdown rendering and another half for wrapping articles into the template. I heard good static site generators work—twice as fast—at 200 pps, so there’s lots of performance that can be gained. ;) ###Why does FreeBSD have virtually no (0%) desktop market share? Because someone made a horrible design decision back in 1984. In absolute fairness to those involved, it was an understandable decision, both from a research perspective, and from an economic perspective, although likely not, from a technology perspective. Why and what. The decision was taken because the X Window System was intended to run on cheap hardware, and, at the time, that meant reduced functionality in the end-point device with the physical display attached to it. At the same time, another force was acting to also limit X displays to display services only, rather than rolling in both window management and specific widget instances for common operational paradigms. Mostly, common operational paradigms didn’t really exist for windowing systems because they also simply didn’t exist at the time, and no one really knew how people were going to use the things, and so researchers didn’t want to commit future research to a set of hard constraints. So a decision was made: separate the display services from the application at the lowest level of graphics primitives currently in use at the time. The ramifications of this were pretty staggering. First, it guaranteed that all higher level graphics would live on the host side of the X protocol, instead of on the display device side of the protocol. Despite a good understanding of Moore’s law, and the fact that, since no X Terminals existed at the time as hardware, but were instead running as emulations on workstations that had sufficient capability, this put the higher level GUI object libraries — referred to as “widgets” — in host libraries linked into the applications. Second, it guaranteed that display organization and management paradigms would also live on the host side of the protocol — assumed, in contradiction to the previous decision, to be running on the workstation. But, presumably, at some point, as lightweight X Terminals became available, to migrate to a particular host computer managing compute resource login/access services. Between these early decisions reigned chaos. Specifically, the consequences of these decisions have been with us ever since: Look-and-feel are a consequence of the toolkit chosen by the application programmer, rather than a user decision which applies universally to all applications. You could call this “lack of a theme”, and — although I personally despise the idea of customizing or “theming” desktops — this meant that one paradigm chosen by the user would not apply universally across all applications, no matter who had written them. Window management style is a preference. You could call this a more radical version of “theming” — which you will remember, I despise — but a consequence to this is that training is not universal across personnel using such systems, nor is it transferrable. In other words, I can’t send someone to a class, and have them come back and use the computers in the office as a tool, with the computer itself — and the elements not specific to the application itself — disappearing into the background. Both of these ultimately render an X-based system unsuitable for desktops. I can’t pay once for training. Training that I do pay for does not easily and naturally translate between applications. Each new version may radically alter the desktop management paradigm into unrecognizability. Is there hope for the future? Well, the Linux community has been working on something called Wayland, and it is very promising… …In the same way X was “very promising” in 1984, because, unfortunately, they are making exactly the same mistakes X made in 1984, rather than correcting them, now that we have 20/20 hindsight, and know what a mature widget library should look like. So Wayland is screwing up again. But hey, it only took us, what, 25 years to get from X in 1987 to Wayland in in 2012. Maybe if we try again in 2037, we can get to where Windows was in 1995. ##Beastie Bits New washing machine comes with 7 pages of open source licenses! BSD Jobs Site FreeBSD Foundation Update, May 2018 FreeBSD Journal looking for book reviewers zedenv ZFS Boot Environment Manager Tarsnap ##Feedback/Questions Wouter - Feedback Efraim - OS Suggestion kevr - Raspberry Pi2/FreeBSD/Router on a Stick Vanja - Interview Suggestion Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
The new KDE Plasma beta and the future of Xubuntu. KDE Plasma 5.13 beta and Berlin Sprint Jonathan Riddell talks about the recent KDE sprint in Berlin and the recent beta of Plasma 5.13. We also spoke about running KDE Neon on the Pinebook, and also the Slimbook II. Xubuntu Sean Davis talks... Read More
The new KDE Plasma beta and the future of Xubuntu. KDE Plasma 5.13 beta and Berlin Sprint Jonathan Riddell talks about the recent KDE sprint in Berlin and the recent beta of Plasma 5.13. We also spoke about running KDE Neon on the Pinebook, and also the Slimbook II. Xubuntu Sean Davis talks... Read More
In dieser Folge gibt es nicht nur was auf die Ohren, sondern auch was zum Schauen. So gibts eine komplette Videoshow zum Pinebook, sowie eine Audioshow zu Mozilla Send, Light L16, Samsungs 1TBit Flashchips uvm. Themen: Mozilla Send Fileupload-Dienst Light L16 16 Kamerasensoren sorgen für hochauflösende Fotos Samsung stellt 1Tbit Flashchips vor Pfeife der Woche: Microschrott Sailfish der Woche: Pingviini Twitter Client PineBook Review Wie immer wünsche ich euch viel Spaß beim reinhören und reinschauen :)
Adventszeit! Bald ist Weihnachten! Naja, eigentlich ging die Sache mit Weihnachten ja bereits Mitte August los in manchen Läden. Jedenfalls zählen Axel und Venty hier mal wieder ein bisschen auf, was es so alles lustiges gibt, was sie bereits ausprobiert haben undoder was sie gerne hätten, sich aber von den mickrigen Einnahmen des Hackerfunks nicht leisten können. Trackliste Folgt aus Zeitgründen später… RIPE Atlas :: RIPE Atlas Projekt Chromecast :: Googles Chromecast Twitch.TV :: Ventys Twitch Stream, wo man ihn manchmal PS4 gamen sieht Fiio X1 :: Fiio X1 MP3-Player Fiio :: Hi-Res MP3-Player und USB-Soundkarten LG PF1000U :: LG Nahbereichsprojektor Pinebook :: Mit ARM CPU betriebenes Netbook für unter 100 $$$ Pinebook :: Testbericht von Winfuture Pinebook Kritik :: Kritische Betrachtung des Pinebooks Pi-Top :: Laptopkit rund um den Raspberry Pi Pi-Top :: Einzelteile des Pi-Tops bei Pi-Shop.ch Picade :: Arcade-Spielautomatengehäuse für Raspberry Pi Helix :: Holzgehäuse für den Raspberry Pi Pyra :: Pyra Linux- und Spiele-Handheld Turris Omnia :: Open Source WLAN-Router Divoom :: Divoom Bluetooth-Lautsprecher mit Blinkenlights Zeit in Dosen :: Fast wie von den Grauen Herren bei Momo Catphones :: Unkaputtbare Mobiltelefone von Caterpillar Touchy :: Touchy Helmkamera, leider nicht kaufbar Temposcope :: Wetterstation mit eigener Biosphäre Pyro Fireshooter :: Feuerwerke aus dem Handgelenk FIntessgefuchteldingsi :: Pac-Man spielen, indem man wie ein Tubel herumfuchtelt Relaxo Plüschie :: 1,50 m grosses Relaxo Pokémon Plüschie TARDIS :: Fliegende TARDIS Bierbaum :: Magnetischer Bierbaum Ponylautsprecher :: Pinkie Pie Plüschie Lautsprecher DIY Hologramm :: Anleitung zum Bau eines Hologramms aus CD-Hüllen Fillygons :: Platonische Körper aus selbstgedruckten Einzelteilen, vom CCCZH Stricktux :: Hast du Keinen, strick dir Einen! Opcomfarm :: Indoor Hydroponische Plantagen (nicht nur für Hanf!) RePhone :: DIY GSM Mobiltelefonbausatz Better Coffee Blocks :: Kaffeewürfel oder sowas, wie Bouillonwürfel..? Sandows :: Kaltextrahierter Kaffee, z.B. bei Coop Togo Hövding :: Airbag Velohelm mit Sprengladung Learning Perl 6 :: Perlfoundation Kickstarter Kampagne Learning Perl 6 :: Kickstarter Kampagne für ein Perl 6 Lehrbuch SRF Digital :: Unsere Podcastkollegen von Schweizer Radio und Fernsehen SRF Digital Youtube-Kanal :: Youtube Kanal mit Geek-Sofa und Let's Plays etc SRF Digital Livestreams :: Youtube Live Stream von SRF Digital File Download (158:05 min / 158 MB)
Adventszeit! Bald ist Weihnachten! Naja, eigentlich ging die Sache mit Weihnachten ja bereits Mitte August los in manchen Läden. Jedenfalls zählen Axel und Venty hier mal wieder ein bisschen auf, was es so alles lustiges gibt, was sie bereits ausprobiert haben undoder was sie gerne hätten, sich aber von den mickrigen Einnahmen des Hackerfunks nicht leisten können. Trackliste Folgt aus Zeitgründen später… RIPE Atlas :: RIPE Atlas Projekt Chromecast :: Googles Chromecast Twitch.TV :: Ventys Twitch Stream, wo man ihn manchmal PS4 gamen sieht Fiio X1 :: Fiio X1 MP3-Player Fiio :: Hi-Res MP3-Player und USB-Soundkarten LG PF1000U :: LG Nahbereichsprojektor Pinebook :: Mit ARM CPU betriebenes Netbook für unter 100 $$$ Pinebook :: Testbericht von Winfuture Pinebook Kritik :: Kritische Betrachtung des Pinebooks Pi-Top :: Laptopkit rund um den Raspberry Pi Pi-Top :: Einzelteile des Pi-Tops bei Pi-Shop.ch Picade :: Arcade-Spielautomatengehäuse für Raspberry Pi Helix :: Holzgehäuse für den Raspberry Pi Pyra :: Pyra Linux- und Spiele-Handheld Turris Omnia :: Open Source WLAN-Router Divoom :: Divoom Bluetooth-Lautsprecher mit Blinkenlights Zeit in Dosen :: Fast wie von den Grauen Herren bei Momo Catphones :: Unkaputtbare Mobiltelefone von Caterpillar Touchy :: Touchy Helmkamera, leider nicht kaufbar Temposcope :: Wetterstation mit eigener Biosphäre Pyro Fireshooter :: Feuerwerke aus dem Handgelenk FIntessgefuchteldingsi :: Pac-Man spielen, indem man wie ein Tubel herumfuchtelt Relaxo Plüschie :: 1,50 m grosses Relaxo Pokémon Plüschie TARDIS :: Fliegende TARDIS Bierbaum :: Magnetischer Bierbaum Ponylautsprecher :: Pinkie Pie Plüschie Lautsprecher DIY Hologramm :: Anleitung zum Bau eines Hologramms aus CD-Hüllen Fillygons :: Platonische Körper aus selbstgedruckten Einzelteilen, vom CCCZH Stricktux :: Hast du Keinen, strick dir Einen! Opcomfarm :: Indoor Hydroponische Plantagen (nicht nur für Hanf!) RePhone :: DIY GSM Mobiltelefonbausatz Better Coffee Blocks :: Kaffeewürfel oder sowas, wie Bouillonwürfel..? Sandows :: Kaltextrahierter Kaffee, z.B. bei Coop Togo Hövding :: Airbag Velohelm mit Sprengladung Learning Perl 6 :: Perlfoundation Kickstarter Kampagne Learning Perl 6 :: Kickstarter Kampagne für ein Perl 6 Lehrbuch SRF Digital :: Unsere Podcastkollegen von Schweizer Radio und Fernsehen SRF Digital Youtube-Kanal :: Youtube Kanal mit Geek-Sofa und Let's Plays etc SRF Digital Livestreams :: Youtube Live Stream von SRF Digital File Download (158:05 min / 158 MB)
© 2020-2025 Ivy Podcast Discovery LLC
