Podcasts about openmp

GPU-Programmierung: Andere Chips und eine andere Art zu programmierenIn der heutigen Zeit dreht sich fast alles in der IT um AI. Und damit auch oft um den sich positiv entwickelnden Aktienkurs von Nvidia. Warum Nvidia? Als Hersteller von Grafikkarten bzw. Grafikchips (kurz GPUs) profitieren sie deutlich von den hohen Nachfragen nach dieser Art von Chips. Das Ganze hat die Frage aufgeworfen: Inwieweit ist die Programmierung auf bzw. für eine GPU anders als bei einer klassischen CPU?In dieser Episode behandeln wir dieses Thema: Paralleles Programmieren auf der GPU.Wir bröseln das Buzzword-Bingo auf und schauen uns an, was der Unterschied zu verteiltem vs. parallelem Rechnen ist, was HPC und CUDA eigentlich ist, ob bzw. wie man auf Grafikkarten ohne Frameworks programmieren kann, welche algorithmischen Use Cases neben AI und Transformer-Modelle existieren, wie man einen Algorithmus für die GPU programmiert und was man alles vermeiden sollte, sprechen über Speicherzugriffsmuster und warum Matrizen-Multiplikationen so gut auf GPUs funktionieren aber auch was Performance-Portabilität bedeutet und ob es Probleme mit der Heterogenität von Grafikkarten und Chips gibt.Und das alles mit Dr. Prof. Peter Thoman.Bonus: Wie besucht man möglichst effizient alle Städte in Deutschland? Das Problem des Handlungsreisenden.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Skalierung und verteilte Berechnungen: Sind mehr CPUs wirklich immer schneller?Stell dir vor, du bist Softwareentwickler*in und jeder spricht von Skalierung und verteilten Systemen. Doch wie effizient sind diese eigentlich wirklich? Heißt mehr Rechenpower gleich schnellere Ergebnisse?In dieser Episode werfen wir einen Blick auf ein wissenschaftliches Paper, das behauptet, die wahre Leistung von verteilten Systemen kritisch zu hinterfragen. Wir diskutieren, ab wann es sich lohnt, mehr Ressourcen einzusetzen, und was es mit der mysteriösen Metrik COST (ausgesprochen Configuration that Outperforms a Single Thread) auf sich hat. Hör rein, wenn du wissen willst, ob Single-Threaded Algorithmen in vielen Fällen die bessere Wahl sind.Bonus: Ggf. machen nicht alle Wissenschaftler so wissenschaftliche Arbeit.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

We have a full house with Adrian Cockcroft, Stephen Perrenod, Chris Kruell, and Shahin Khan with a "postview" of the SC24 conference, the latest CryptoSuper500 list, a snapshot of quantum computing, and the RISC-V Summit. They also discuss Bitcoin, AI vs. HPC, HPC in the cloud, liquid cooling, InfraTech, Interconnects, Optical Computing, OpenMP, PCIe, CXL, GPUs, CPUs, and energy efficiency and ESG. [audio mp3="https://orionx.net/wp-content/uploads/2024/12/OXD025_SC24-Postview_CryptoSuper500_Quantum_RISCV-Summit_20241216.mp3"][/audio] The post SC24, Supercomputing, CryptoSuper500, Quantum, RISC-V Summit – OXD25 appeared first on OrionX.net.

Scott Parker joins Tony to discuss the progress getting applications running on Aurora Supercomputer nodes.  From 2022 where the project started to today, significant progress has been made using a variety of programming models.  Kokkos, OpenMP and oneAPI have enabled migration of scientific and AI applications to run on the Intel CPUs and GPUs Aurora is built on. Guest: Scott Parker is the Lead for Performance Tools and Programming Models at the ALCF. He received his B.S. in Mechanical Engineering from Lehigh University, and a Ph.D. in Mechanical Engineering from the University of Illinois at Urbana-Champaign. Prior to joining Argonne, he worked at the National Center for Supercomputing Applications, where he focused on high-performance computing and scientific applications. At Argonne since 2008, he works on performance tools, performance optimization, and spectral element computational fluid dynamics solvers.   Scott Parker     Resources: Aurora Super Computer - https://www.alcf.anl.gov/aurora Intel Data Center Max GPU - https://www.intel.com/content/www/us/en/products/details/discrete-gpus/data-center-gpu/max-series.html Intel Xeon Processors - https://www.intel.com/content/www/us/en/products/details/processors/xeon.html Intel oneAPI Base Toolkit - https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit.html    

Who better to have a spicy discussion with about #OpenMP than Tim Mattson and Bronis de Supinski? These two have truly lived at the forefront of the amazing, decades-long OpenMP journey, from its inception to its preeminence as a foundational tool for HPC application programmers. Listen to what’s coming in 5.1 and beyond, how the C++ ecosystem is evolving, why Python in HPC, and have fun as these two razz each other. Guests: Bronis de Supinski, Chief Technology Officer, Livermore Computing, Lawrence Livermore National Lab; Chair, OpenMP Language Committee Tim Mattson, Senior Principal Engineer, and Manager, Programming Systems Research Group, Intel To learn more: OpenMP.org Intel oneAPI HPC Toolkit oneAPI

Who better to have a spicy discussion with about #OpenMP than Tim Mattson and Bronis de Supinski? These two have truly lived at the forefront of the amazing, decades-long OpenMP journey, from its inception to its preeminence as a foundational tool for HPC application programmers. Listen to what’s coming in 5.1 and beyond, how the […]

Who better to have a spicy discussion with about #OpenMP than Tim Mattson and Bronis de Supinski? These two have truly lived at the forefront of the amazing, decades-long OpenMP journey, from its inception to its preeminence as a foundational tool for HPC application programmers. Listen to what's coming in 5.1 and beyond, how the […]

Episode Notes: Christian Trott of Sandia National Laboratories shares insights about Kokkos, a programming model for numerous Exascale Computing Project applications.

In this interview with Appentra Solutions CEO and co-founder Manuel Arenaz, learn about the Appentra Parallelware Trainer tool: how it can help you learn to code with OpenMP and OpenACC, the features of the tool, and how to use it on Cori.

We report from our experiences at EuroBSDcon, disenchant software, LLVM 7.0.0 has been released, Thinkpad BIOS update options, HardenedBSD Foundation announced, and ZFS send vs. rsync. ##Headlines ###[FreeBSD DevSummit & EuroBSDcon 2018 in Romania] Your hosts are back from EuroBSDcon 2018 held in Bucharest, Romania this year. The first two days of the conference are used for tutorials and devsummits (FreeBSD and NetBSD), while the last two are for talks. Although Benedict organized the devsummit in large parts, he did not attend it this year. He held his Ansible tutorial in the morning of the first day, followed by Niclas Zeising’s new ports and poudriere tutorial (which had a record attendance). It was intended for beginners that had never used poudriere before and those who wanted to create their first port. The tutorial was well received and Niclas already has ideas for extending it for future conferences. On the second day, Benedict took Kirk McKusick’s “An Introduction to the FreeBSD Open-Source Operating System” tutorial, held as a one full day class this year. Although it was reduced in content, it went into enough depth of many areas of the kernel and operating system to spark many questions from attendees. Clearly, this is a good start into kernel programming as Kirk provides enough material and backstories to understand why certain things are implemented as they are. Olivier Robert took https://www.talegraph.com/tales/l2o9ltrvsE (pictures from the devsummit) and created a nice gallery out of it. Devsummit evenings saw dinners at two restaurants that allowed developers to spend some time talking over food and drinks. The conference opened on the next day with the opening session held by Mihai Carabas. He introduced the first keynote speaker, a colleague of his who presented “Lightweight virtualization with LightVM and Unikraft”. Benedict helped out at the FreeBSD Foundation sponsor table and talked to people. He saw the following talks in between: Selfhosting as an alternative to the public cloud (by Albert Dengg) Using Boot Environments at Scale (by Allan Jude) Livepatching FreeBSD kernel (by Maciej Grochowski) FreeBSD: What to (Not) Monitor (by Andrew Fengler) FreeBSD Graphics (by Niclas Zeising) Allan spent a lot of time talking to people and helping track down issues they were having, in addition to attending many talks: Hacking together a FreeBSD presentation streaming box – For as little as possible (by Tom Jones) Introduction of FreeBSD in new environments (by Baptiste Daroussin) Keynote: Some computing and networking historical perspectives (by Ron Broersma) Livepatching FreeBSD kernel (by Maciej Grochowski) FreeBSD: What to (Not) Monitor (by Andrew Fengler) Being a BSD user (by Roller Angel) From “Hello World” to the VFS Layer: building a beadm for DragonFly BSD (by Michael Voight) We also met the winner of our Power Bagel raffle from Episode 2^8. He received the item in the meantime and had it with him at the conference, providing a power outlet to charge other people’s devices. During the closing session, GroffTheBSDGoat was handed over to Deb Goodkin, who will bring the little guy to the Grace Hopper Celebration of Women in Computing conference and then to MeetBSD later this year. It was also revealed that next year’s EuroBSDcon will be held in Lillehammer, Norway. Thanks to all the speakers, helpers, sponsors, organizers, and attendees for making it a successful conferences. There were no talks recorded this year, but the slides will be uploaded to the EuroBSDcon website in a couple of weeks. The OpenBSD talks are already available, so check them out. ###Software disenchantment I’ve been programming for 15 years now. Recently our industry’s lack of care for efficiency, simplicity, and excellence started really getting to me, to the point of me getting depressed by my own career and the IT in general. Modern cars work, let’s say for the sake of argument, at 98% of what’s physically possible with the current engine design. Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. All planes converged to the optimal size/form/load and basically look the same. Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”: @tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I’ll make my time back in 41 years, 24 days :-) You’ve probably heard this mantra: “programmer time is more expensive than computer time”. What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time. Everything is unbearably slow Look around: our portable computers are thousands of times more powerful than the ones that brought man to the moon. Yet every other webpage struggles to maintain a smooth 60fps scroll on the latest top-of-the-line MacBook Pro. I can comfortably play games, watch 4K videos but not scroll web pages? How is it ok? Google Inbox, a web app written by Google, running in Chrome browser also by Google, takes 13 seconds to open moderately-sized emails: It also animates empty white boxes instead of showing their content because it’s the only way anything can be animated on a webpage with decent performance. No, decent doesn’t mean 60fps, it’s rather “as fast as this web page could possibly go”. I’m dying to see web community answer when 120Hz displays become mainstream. Shit barely hits 60Hz already. Windows 10 takes 30 minutes to update. What could it possibly be doing for that long? That much time is enough to fully format my SSD drive, download a fresh build and install it like 5 times in a row. Pavel Fatin: Typing in editor is a relatively simple process, so even 286 PCs were able to provide a rather fluid typing experience. Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and also process input, recalculate the world and dynamically load/unload resources. How come? As a general trend, we’re not getting faster software with more features. We’re getting faster hardware that runs slower software with the same features. Everything works way below the possible speed. Ever wonder why your phone needs 30 to 60 seconds to boot? Why can’t it boot, say, in one second? There are no physical limitations to that. I would love to see that. I would love to see limits reached and explored, utilizing every last bit of performance we can get for something meaningful in a meaningful way. Everything is HUUUUGE And then there’s bloat. Web apps could open up to 10× faster if you just simply block all ads. Google begs everyone to stop shooting themselves in their feet with AMP initiative—a technology solution to a problem that doesn’t need any technology, just a little bit of common sense. If you remove bloat, the web becomes crazy fast. How smart do you have to be to understand that? Android system with no apps takes almost 6 Gb. Just think for a second how obscenely HUGE that number is. What’s in there, HD movies? I guess it’s basically code: kernel, drivers. Some string and resources too, sure, but those can’t be big. So, how many drivers do you need for a phone? Windows 95 was 30Mb. Today we have web pages heavier than that! Windows 10 is 4Gb, which is 133 times as big. But is it 133 times as superior? I mean, functionally they are basically the same. Yes, we have Cortana, but I doubt it takes 3970 Mb. But whatever Windows 10 is, is Android really 150% of that? Google keyboard app routinely eats 150 Mb. Is an app that draws 30 keys on a screen really five times more complex than the whole Windows 95? Google app, which is basically just a package for Google Web Search, is 350 Mb! Google Play Services, which I do not use (I don’t buy books, music or videos there)—300 Mb that just sit there and which I’m unable to delete. All that leaves me around 1 Gb for my photos after I install all the essential (social, chats, maps, taxi, banks etc) apps. And that’s with no games and no music at all! Remember times when an OS, apps and all your data fit on a floppy? Your desktop todo app is probably written in Electron and thus has userland driver for Xbox 360 controller in it, can render 3d graphics and play audio and take photos with your web camera. A simple text chat is notorious for its load speed and memory consumption. Yes, you really have to count Slack in as a resource-heavy application. I mean, chatroom and barebones text editor, those are supposed to be two of the less demanding apps in the whole world. Welcome to 2018. At least it works, you might say. Well, bigger doesn’t imply better. Bigger means someone has lost control. Bigger means we don’t know what’s going on. Bigger means complexity tax, performance tax, reliability tax. This is not the norm and should not become the norm. Overweight apps should mean a red flag. They should mean run away scared. Better world manifesto I want to see progress. I want change. I want state-of-the-art in software engineering to improve, not just stand still. I don’t want to reinvent the same stuff over and over, less performant and more bloated each time. I want something to believe in, a worthy end goal, a future better than what we have today, and I want a community of engineers who share that vision. What we have today is not progress. We barely meet business goals with poor tools applied over the top. We’re stuck in local optima and nobody wants to move out. It’s not even a good place, it’s bloated and inefficient. We just somehow got used to it. So I want to call it out: where we are today is bullshit. As engineers, we can, and should, and will do better. We can have better tools, we can build better apps, faster, more predictable, more reliable, using fewer resources (orders of magnitude fewer!). We need to understand deeply what are we doing and why. We need to deliver: reliably, predictably, with topmost quality. We can—and should–take pride in our work. Not just “given what we had…”—no buts! I hope I’m not alone at this. I hope there are people out there who want to do the same. I’d appreciate if we at least start talking about how absurdly bad our current situation in the software industry is. And then we maybe figure out how to get out. ##News Roundup [llvm-announce] LLVM 7.0.0 Release I am pleased to announce that LLVM 7 is now available. Get it here: https://llvm.org/releases/download.html#7.0.0 The release contains the work on trunk up to SVN revision 338536 plus work on the release branch. It is the result of the community's work over the past six months, including: function multiversioning in Clang with the 'target' attribute for ELF-based x86/x86_64 targets, improved PCH support in clang-cl, preliminary DWARF v5 support, basic support for OpenMP 4.5 offloading to NVPTX, OpenCL C++ support, MSan, X-Ray and libFuzzer support for FreeBSD, early UBSan, X-Ray and libFuzzer support for OpenBSD, UBSan checks for implicit conversions, many long-tail compatibility issues fixed in lld which is now production ready for ELF, COFF and MinGW, new tools llvm-exegesis, llvm-mca and diagtool. And as usual, many optimizations, improved diagnostics, and bug fixes. For more details, see the release notes: https://llvm.org/releases/7.0.0/docs/ReleaseNotes.html https://llvm.org/releases/7.0.0/tools/clang/docs/ReleaseNotes.html https://llvm.org/releases/7.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html https://llvm.org/releases/7.0.0/tools/lld/docs/ReleaseNotes.html Thanks to everyone who helped with filing, fixing, and code reviewing for the release-blocking bugs! Special thanks to the release testers and packagers: Bero Rosenkränzer, Brian Cain, Dimitry Andric, Jonas Hahnfeld, Lei Huang Michał Górny, Sylvestre Ledru, Takumi Nakamura, and Vedant Kumar. For questions or comments about the release, please contact the community on the mailing lists. Onwards to LLVM 8! Cheers, Hans ###Update your Thinkpad’s bios with Linux or OpenBSD Get your new bios At first, go to the Lenovo website and download your new bios: Go to lenovo support Use the search bar to find your product (example for me, x270) Choose the right product (if necessary) and click search On the right side, click on Update Your System Click on BIOS/UEFI Choose *BIOS Update (Bootable CD) for Windows * Download For me the file is called like this : r0iuj25wd.iso Extract bios update Now you will need to install geteltorito. With OpenBSD: $ doas pkgadd geteltorito quirks-3.7 signed on 2018-09-09T13:15:19Z geteltorito-0.6: ok With Debian: $ sudo apt-get install genisoimage Now we will extract the bios update : $ geteltorito -o biosupdate.img r0iuj25wd.iso Booting catalog starts at sector: 20 Manufacturer of CD: NERO BURNING ROM VER 12 Image architecture: x86 Boot media type is: harddisk El Torito image starts at sector 27 and has 43008 sector(s) of 512 Bytes Image has been written to file "biosupdate.img". This will create a file called biosupdate.img. Put the image on an USB key CAREFULL : on my computer, my USB key is sda1 on Linux and sd1 on OpenBSD. Please check twice on your computer the name of your USB key. With OpenBSD : $ doas dd if=biosupdate.img of=/dev/rsd1c With Linux : $ sudo dd if=biosupdate.img of=/dev/sda Now all you need is to reboot, to boot on your USB key and follow the instructions. Enjoy 😉 ###Announcing The HardenedBSD Foundation In June of 2018, we announced our intent to become a not-for-profit, tax-exempt 501©(3) organization in the United States. It took a dedicated team months of work behind-the-scenes to make that happen. On 06 September 2018, HardenedBSD Foundation Corp was granted 501©(3) status, from which point all US-based persons making donations can deduct the donation from their taxes. We are grateful for those who contribute to HardenedBSD in whatever way they can. Thank you for making HardenedBSD possible. We look forward to a bright future, driven by a helpful and positive community. ###How you migrate ZFS filesystems matters If you want to move a ZFS filesystem around from one host to another, you have two general approaches; you can use ‘zfs send’ and ‘zfs receive’, or you can use a user level copying tool such as rsync (or ‘tar -cf | tar -xf’, or any number of similar options). Until recently, I had considered these two approaches to be more or less equivalent apart from their convenience and speed (which generally tilted in favour of ‘zfs send’). It turns out that this is not necessarily the case and there are situations where you will want one instead of the other. We have had two generations of ZFS fileservers so far, the Solaris ones and the OmniOS ones. When we moved from the first generation to the second generation, we migrated filesystems across using ‘zfs send’, including the filesystem with my home directory in it (we did this for various reasons). Recently I discovered that some old things in my filesystem didn’t have file type information in their directory entries. ZFS has been adding file type information to directories for a long time, but not quite as long as my home directory has been on ZFS. This illustrates an important difference between the ‘zfs send’ approach and the rsync approach, which is that zfs send doesn’t update or change at least some ZFS on-disk data structures, in the way that re-writing them from scratch from user level does. There are both positives and negatives to this, and a certain amount of rewriting does happen even in the ‘zfs send’ case (for example, all of the block pointers get changed, and ZFS will re-compress your data as applicable). I knew that in theory you had to copy things at the user level if you wanted to make sure that your ZFS filesystem and everything in it was fully up to date with the latest ZFS features. But I didn’t expect to hit a situation where it mattered in practice until, well, I did. Now I suspect that old files on our old filesystems may be partially missing a number of things, and I’m wondering how much of the various changes in ‘zfs upgrade -v’ apply even to old data. (I’d run into this sort of general thing before when I looked into ext3 to ext4 conversion on Linux.) With all that said, I doubt this will change our plans for migrating our ZFS filesystems in the future (to our third generation fileservers). ZFS sending and receiving is just too convenient, too fast and too reliable to give up. Rsync isn’t bad, but it’s not the same, and so we only use it when we have to (when we’re moving only some of the people in a filesystem instead of all of them, for example). PS: I was going to try to say something about what ‘zfs send’ did and didn’t update, but having looked briefly at the code I’ve concluded that I need to do more research before running my keyboard off. In the mean time, you can read the OpenZFS wiki page on ZFS send and receive, which has plenty of juicy technical details. PPS: Since eliminating all-zero blocks is a form of compression, you can turn zero-filled files into sparse files through a ZFS send/receive if the destination has compression enabled. As far as I know, genuine sparse files on the source will stay sparse through a ZFS send/receive even if they’re sent to a destination with compression off. ##Beastie Bits BSD Users Stockholm Meetup #4: Tuesday, November 13, 2018 at 18:00 BSD Poland User Group: Next Meeting: October 11, 2018, 18:15 - 21:15 at Warsaw University of Technology n2k18 Hackathon report: Ken Westerback (krw@) on disklabel(8) work, dhclient(8) progress Running MirageOS Unikernels on OpenBSD in vmm (Now Works) vmm(4) gets support for qcow2 MeetBSD and SecurityBsides Colin Percival reduced FreeBSD startup time from 10627ms (11.2) to 4738ms (12.0) FreeBSD 11.1 end-of-life KnoxBug: Monday, October 1, 2018 at 18:00: Real-world Performance Advantages of NVDIMM and NVMe: Case Study with OpenZFS ##Feedback/Questions Todd - 2 Nics, 1 bhyve and a jail cell Thomas - Deep Dive Morgan - Send/Receive to Manage Fragmentation? Dominik - hierarchical jails -> networking Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

Allan reports on his trip to BSD Taiwan, new versions of Lumina and GhostBSD are here, a bunch of OpenBSD p2k17 hackathon reports. This episode was brought to you by Headlines Allan's Trip Report from BSD Taiwan (https://bsdtw.org/) BSD TW and Taiwan in general was a fun and interesting experience I arrived Thursday night and took the high speed train to Taipei main station, and then got on the Red line subway to the venue. The dorm rooms were on par with BSDCan, except the mattress was better. I spent Friday with a number of other FreeBSD developers doing touristy things. We went to Taipei 101, the world's tallest building from 2004 - 2010. It also features the world's fastest elevator (2004 - 2016), traveling at 60.6 km/h and transporting passengers from the 5th to 89th floor in 37 seconds. We also got to see the “tuned mass damper”, a 660 tonne steel pendulum suspended between the 92nd and 87th floors. This device resists the swaying of the building caused by high winds. There are interesting videos on display beside the damper, of its reaction during recent typhoons and earthquakes. The Taipei 101 building sits just 200 meters from a major fault line. Then we had excellent dumplings for lunch After walking around the city for a few more hours, we retired to a pub to escape the heat of the sunny Friday afternoon. Then came the best part of each day in Taipei, dinner! We continued our efforts to cause a nation wide shortage of dumplings Special thanks to Scott Tsai (https://twitter.com/scottttw) who took detailed notes for each of the presentations Saturday marked the start of the conference: Arun Thomas provided background and then a rundown of what is happening with the RISC-V architecture. Notes (https://docs.google.com/document/d/1yrnhNTHaMDr4DG-iviXN0O9NES9Lmlc7sWVQhnios6g/edit#heading=h.kcm1n3yzl35q) George Neville-Neil talked about using DTrace in distributed systems as an in-depth auditing system (who did what to whom and when). Notes (https://docs.google.com/document/d/1qut6tMVF8NesrGHd6bydLDN-aKBdXMgHx8Vp3_iGKjQ/edit#heading=h.qdghsgk1bgtl) Baptiste Daroussin presented Poudrière image, an extension of everyone's favourite package building system, to build custom images of FreeBSD. There was discussion of making this generate ZFS based images as well, making it mesh very well with my talk the next day. Notes (https://docs.google.com/document/d/1LceXj8IWJeTRHp9KzOYy8tpM00Fzt7fSN0Gw83B9COE/edit#heading=h.incfzi6bnzxr) Brooks Davis presented his work on an API design for a replacement for mmap. It started with a history of address space management in the BSD family of operating systems going all the way back to the beginning. This overview of the feature and how it evolved filled in many gaps for me, and showed why the newer work would be beneficial. The motivation for the work includes further extensions to support the CHERI hardware platform. Notes (https://docs.google.com/document/d/1LceXj8IWJeTRHp9KzOYy8tpM00Fzt7fSN0Gw83B9COE/edit#heading=h.incfzi6bnzxr) Johannes M Dieterich gave an interesting presentation about using FreeBSD and GPU acceleration for high performance computing. One of the slides showed that amd64 has taken almost the entire market for the top 500 super computers, and that linux dominates the list, with only a few remaining non-linux systems. Sadly, at the supercomputing conference the next week, it was announced that linux has achieved 100% saturation of the top 500 super computers list. Johannes detailed the available tools, what ports are missing, what changes should be made to the base system (mostly OpenMP), and generally what FreeBSD needs to do to become a player in the supercomputer OS market. Johannes' perspective is interesting, as he is a computational chemist, not a computer scientist. Those interested in improving the numerical libraries and GPU acceleration frameworks on FreeBSD should join the ports team. Notes (https://docs.google.com/document/d/1uaJiqtPk8WetST6_GnQwIV49bj790qx7ToY2BHC9zO4/edit#heading=h.nvsz1n6w3gyq) The final talk of the day was Peter Grehan, who spoke about how graphics support in bhyve came to be. He provided a history of how the feature evolved, and where it stands today. Notes (https://docs.google.com/document/d/1LqJQJUwdUwWZ0n5KwCH1vNI8jiWGJlI1j0It3mERN80/edit#heading=h.sgeixwgz7bjs) Afterwards, we traveled as a group to a large restaurant for dinner. There was even Mongolian Vodka, provided by Ganbold Tsagaankhuu of the FreeBSD project. Sunday: The first talk of the day Sunday was mine. I presented “ZFS: Advanced Integration”, mostly talking about how boot environments work, and the new libbe and be(1) tools that my GSoC student Kyle Kneitinger created to manage them. I talked about how they can be used for laptop and developer systems, but also how boot environments can be used to replace nanobsd for appliances (as already done in FreeNAS and pfSense). I also presented about zfsbootcfg (zfs nextboot), and some future extensions to it to make it even more useful in appliance type workloads. I also provided a rundown of new developments out of the ZFS developer summit, two weeks previous. Notes (https://docs.google.com/document/d/1Blh3Dulf0O91A0mwv34UnIgxRZaS_0FU2lZ41KRQoOU/edit#heading=h.gypim387e8hy) Theo de Raadt presented “Mitigations and other real Security Features”, and made his case for changing to a ‘fail closed' mode of interoperability. Computer's cannot actually self heal, so lets stop pretending that they can. Notes (https://docs.google.com/document/d/1fFHzlxJjbHPsV9t_Uh3PXZnXmkapAK5RkJsfaHki7kc/edit#heading=h.192e4lmbl70c) Ruslan Bukin talked about doing the port of FreeBSD for RISC-V and writing the Device Drivers. Ruslan walked through the process step by step, leading members of the audience to suggest he turn it into a developer's handbook article, explaining how to do the initial bringup on new hardware. Ruslan also showed off a FreeBSD/MIPS board he designed himself and had manufactured in China. Notes (https://docs.google.com/document/d/1kRhRr3O3lQ-0dS0kYF0oh_S0_zFufEwrdFjG1QLyk8Y/edit#heading=h.293mameym7w1) Mariusz Zaborski presented Case studies on sandboxing the base system with Capsicum. He discussed the challenges encountered as existing programs are modified to sandbox them, and recent advancements in the debugging tools available during that process. Mariusz also discussed the Casper service at length, including the features that are planned for 2018 and onwards. Notes (https://docs.google.com/document/d/1_0BpAE1jGr94taUlgLfSWlJOYU5II9o7Y3ol0ym1eZQ/edit#heading=h.xm9mh7dh6bay) The final presentation of the day was Mark Johnston on Memory Management Improvements in FreeBSD 12.0. This talk provided a very nice overview of the memory management system in FreeBSD, and then detailed some of the recent improvements. Notes (https://docs.google.com/document/d/1gFQXxsHM66GQGMO4-yoeFRTcmOP4NK_ujVFHIQJi82U/edit#heading=h.uirc9jyyti7w) The conference wrapped up with the Work-in-Progress session, including updates on: multi-device-at-once GELI attach, MP-safe networking on NetBSD, pkgsrc, NetBSD in general, BSD on Microsoft Azure, Mothra (send-pr for bugzilla), BSDMizer a machine learning compiler optimizer, Hyperledger Sawtooth (blockchain), and finally VIMAGE and pf testing on FreeBSD. Notes (https://docs.google.com/document/d/1miHZEPrqrpCTh8JONmUKWDPYUmTuG2lbsVrWDtekvLc/edit#heading=h.orhedpjis5po) Group Photo (https://pbs.twimg.com/media/DOh1txnVoAAFKAa.jpg:large) BSDTW was a great conference. They are still considering if it should be an annual thing, trade off every 2nd year with AsiaBSDCon, or something else. In order to continue, BSD Taiwan requires more organizers and volunteers. They have regular meetups in Taipei if you are interested in getting involved. *** Lumina 1.4.0 released (https://lumina-desktop.org/version-1-4-0-released/) The Lumina Theme Engine (and associated configuration utility) The Lumina theme engine is a new component of the “core” desktop, and provides enhanced theming capabilities for the desktop as well as all Qt5 applications. While it started out life as a fork of the “qt5ct” utility, it quickly grew all sorts of new features and functionality such as system-defined color profiles, modular theme components, and built-in editors/creators for all components. The backend of this engine is a standardized theme plugin for the Qt5 toolkit, so that all Qt5 applications will now present a unified appearance (if the application does not enforce a specific appearance/theme of it's own). Users of the Lumina desktop will automatically have this plugin enabled: no special action is required. Please note that the older desktop theme system for Lumina has been rendered obsolete by the new engine, but a settings-conversion path has already been implemented which should transition your current settings to the new engine the first time you login to Lumina 1.4.0. Custom themes for the older system may not be converted though, but it is trivial to copy/paste any custom stylesheets from the old system into the editor for the new theme engine to register/re-apply them as desired. Lumina-Themes Repository I also want to give a shout-out to the trueos/lumina-themes github repository contributors. All of the wallpapers in the 1.4.0 screenshots I posted come from that package, and they are working on making more wallpapers, color palettes, and desktop styles for use with the Lumina Theme Engine. If your operating system does not currently provide a package for lumina-themes, I highly recommend that you make one as soon as possible! The Lumina PDF Viewer (lumina-pdf) This is a new, stand-alone desktop utility for viewing/printing/presenting PDF documents. It uses the poppler-qt5 library in the backend for rendering the document, but uses multi-threading in many ways (such as to speed up the loading of pages) to give the user a nice, streamlined utility for viewing PDF documents. There is also built-in presentation functionality which allows users to easily cast the document to a separate screen without mucking about in system menus or configuration utilities. Lumina PDF Viewer (1.4.0) Important Packaging Changes One significant change of note for people who are packaging Lumina for their particular operating system is that the minimum supported versions of Qt for Lumina have been changed with this release: lumina-core: Qt 5.4+ lumina-mediaplayer: Qt 5.7+ Everything else: Qt 5.2+ Of course, using the latest version of the Qt5 libraries is always recommended. When packaging for Linux distributions, the theme engine also requires the availability of some of the “-dev” packages for Qt itself when compiling the theme plugin. For additional information (specifically regarding Ubuntu builds), please take a look at a recent ticket on the Lumina repository. + The new lumina-pdf utility requires the availability of the “poppler-qt5” library. The includes for this library on Ubuntu 17.10 were found to be installed outside of the normal include directories, so a special rule for it was added to our OS-Detect file in the Lumina source tree. If your particular operating system also places the the poppler include files in a non-standard place, please patch that file or send us the information and we can add more special rules for your particular OS. Other Changes of Note (in no particular order) lumina-config: Add a new page for changing audio theme (login, logout, low battery) Add option to replace fluxbox with some other WM (with appropriate warnings) Have the “themes” page redirect to launching the Lumina theme engine configuration utility. start-lumina-desktop: Auto-detect the active X11 displays and create a new display for the Lumina session (prevent conflict with prior graphical sessions). Add a process-failure counter & restart mechanism. This is particularly useful for restarting Fluxbox from time to time (such as after any monitor addition/removal) lumina-xconfig: Restart fluxbox after making any monitor changes with xrandr. This ensures a more reliable session. Implement a new 2D monitor layout mechanism. This allows for the placement of monitors anywhere in the X/Y plane, with simplification buttons for auto-tiling the monitors in each dimension based on their current location. Add the ability to save/load monitor profiles. Distinguish between the “default” monitor arrangement and the “current” monitor arrangement. Allow the user to set the current arrangement as the new default. lumina-desktop: Completely revamp the icon loading mechanisms so it should auto-update when the theme changes. Speed up the initialization of the desktop quite a bit. Prevent loading/probing files in the “/net/” path for existence (assume they exist in the interest of providing shortcuts). On FreeBSD, these are special paths that actually pause the calling process in order to mount/load a network share before resuming the process, and can cause significant “hangs” in the desktop process. Add the ability to take a directory as a target for the wallpaper. This will open/probe the directory for any existing image files that it can use as a wallpaper and randomly select one. Remove the popup dialog prompting about system updates, and replace it with new “Restart (with updates)” buttons on the appropriate menus/windows instead. If no wallpapers selection is provided, try to use the “lumina-nature” wallpaper directory as the default, otherwise fall back on the original default wallpaper if the “lumina-themes” package is not installed. lumina-open: Make the *.desktop parsing a bit more flexible regarding quoted strings where there should not be any. If selecting which application to use, only overwrite the user-default app if the option is explicitly selected. lumina-fileinfo: Significant cleanup of this utility. Now it can be reliably used for creating/registering XDG application shortcuts. Add a whole host of new ZFS integrations: If a ZFS dataset is being examined, show all the ZFS properties for that dataset. If the file being examined exists within ZFS snapshots, show all the snapshots of the file lumina-fm: Significant use of additional multi-threading. Makes the loading of directories much faster (particularly ones with image files which need thumbnails) Add detection/warning when running as root user. Also add an option to launch a new instance of lumina-fm as the root user. [FreeBSD/TrueOS] Fix up the detection of the “External Devices” list to also list available devices for the autofs system. Fix up some drag and drop functionality. Expose the creation, extraction, and insertion of files into archives (requires lumina-archiver at runtime) Expand the “Open With” option into a menu of application suggestions in addition to the “Other” option which runs “lumina-open” to find an application. Provide an option to set the desktop wallpaper to the selected image file(s). (If the running desktop session is Lumina). lumina-mediaplayer: Enable the ability to playback local video files. (NOTE: If Qt5 is set to use the gstreamer multimedia backend, make sure you have the “GL” plugin installed for smooth video playback). lumina-archiver: Add CLI flags for auto-archive and auto-extract. This allows for programmatic/scriptable interactions with archives. That is not mentioning all of the little bugfixes, performance tweaks, and more that are also included in this release. *** The strongest KASLR, ever? (https://blog.netbsd.org/tnf/entry/the_strongest_kaslr_ever) Re: amd64: kernel aslr support (https://mail-index.netbsd.org/tech-kern/2017/11/14/msg022594.html) So, I did it. Now the kernel sections are split in sub-blocks, and are all randomized independently. See my drawing [1]. What it means in practice, is that Kernel ASLR is much more difficult to defeat: a cache attack will at most allow you to know that a given range is mapped as executable for example, but you don't know which sub-block of .text it is; a kernel pointer leak will at most allow you to reconstruct the layout of one sub-block, but you don't know the layout and address of the remaining blocks, and there can be many. The size and number of these blocks is controlled by the split-by-file parameter in Makefile.amd64. Right now it is set to 2MB, which produces a kernel with ~23 allocatable (ie useful at runtime) sections, which is a third of the total number supported (BTSPACENSEGS = 64). I will probably reduce this parameter a bit in the future, to 1.5MB, or even 1MB. All of that leaves us with about the most advanced KASLR implementation available out there. There are ways to improve it even more, but you'll have to wait a few weeks for that. If you want to try it out you need to make sure you have the latest versions of GENERICKASLR / prekern / bootloader. The instructions are still here, and haven't changed. Initial design As I said in the previous episode, I added in October a Kernel ASLR implementation in NetBSD for 64bit x86 CPUs. This implementation would randomize the location of the kernel in virtual memory as one block: a random VA would be chosen, and the kernel ELF sections would be mapped contiguously starting from there. This design had several drawbacks: one leak, or one successful cache attack, could be enough to reconstruct the layout of the entire kernel and defeat KASLR. NetBSD's new KASLR design significantly improves this situation. New design In the new design, each kernel ELF section is randomized independently. That is to say, the base addresses of .text, .rodata, .data and .bss are not correlated. KASLR is already at this stage more difficult to defeat, since you would need a leak or cache attack on each of the kernel sections in order to reconstruct the in-memory kernel layout. Then, starting from there, several techniques are used to strengthen the implementation even more. Sub-blocks The kernel ELF sections are themselves split in sub-blocks of approximately 1MB. The kernel therefore goes from having: { .text .rodata .data .bss } to having { .text .text.0 .text.1 ... .text.i .rodata .rodata.0 ... .rodata.j ... .data ...etc } As of today, this produces a kernel with ~33 sections, each of which is mapped at a random address and in a random order. This implies that there can be dozens of .text segments. Therefore, even if you are able to conduct a cache attack and determine that a given range of memory is mapped as executable, you don't know which sub-block of .text it is. If you manage to obtain a kernel pointer via a leak, you can at most guess the address of the section it finds itself in, but you don't know the layout of the remaining 32 sections. In other words, defeating this KASLR implementation is much more complicated than in the initial design. Higher entropy Each section is put in a 2MB-sized physical memory chunk. Given that the sections are 1MB in size, this leaves half of the 2MB chunk unused. Once in control, the prekern shifts the section within the chunk using a random offset, aligned to the ELF alignment constraint. This offset has a maximum value of 1MB, so that once shifted the section still resides in its initial 2MB chunk: The prekern then maps these 2MB physical chunks at random virtual addresses; but addresses aligned to 2MB. For example, the two sections in Fig. A will be mapped at two distinct VAs: There is a reason the sections are shifted in memory: it offers higher entropy. If we consider a .text.i section with a 64byte ELF alignment constraint, and give a look at the number of possibilities for the location of the section in memory: The prekern shifts the 1MB section in its 2MB chunk, with an offset aligned to 64 bytes. So there are (2MB-1MB)/(64B)=214 possibilities for the offset. Then, the prekern uses a 2MB-sized 2MB-aligned range of VA, chosen in a 2GB window. So there are (2GB-2MB)/(2MB)=210-1 possibilities for the VA. Therefore, there are 214x(210-1)˜224 possible locations for the section. As a comparison with other systems: OS # of possibilities Linux 2^6 MacOS 2^8 Windows 2^13 NetBSD 2^24 Of course, we are talking about one .text.i section here; the sections that will be mapped afterwards will have fewer location possibilities because some slots will be already occupied. However, this does not alter the fact that the resulting entropy is still higher than that of the other implementations. Note also that several sections have an alignment constraint smaller than 64 bytes, and that in such cases the entropy is even higher. Large pages There is also a reason we chose to use 2MB-aligned 2MB-sized ranges of VAs: when the kernel is in control and initializes itself, it can now use large pages to map the physical 2MB chunks. This greatly improves memory access performance at the CPU level. Countermeasures against TLB cache attacks With the memory shift explained above, randomness is therefore enforced at both the physical and virtual levels: the address of the first page of a section does not equal the address of the section itself anymore. It has, as a side effect, an interesting property: it can mostly mitigate TLB cache attacks. Such attacks operate at the virtual-page level; they will allow you to know that a given large page is mapped as executable, but you don't know where exactly within that page the section actually begins. Strong? This KASLR implementation, which splits the kernel in dozens of sub-blocks, randomizes them independently, while at the same time allowing for higher entropy in a way that offers large page support and some countermeasures against TLB cache attacks, appears to be the most advanced KASLR implementation available publicly as of today. Feel free to prove me wrong, I would be happy to know! WIP Even if it is in a functional state, this implementation is still a work in progress, and some of the issues mentioned in the previous blog post haven't been addressed yet. But feel free to test it and report any issue you encounter. Instructions on how to use this implementation can still be found in the previous blog post, and haven't changed since. See you in the next episode! News Roundup GhostBSD 11.1 Finally Ready and Available! (http://www.ghostbsd.org/11.1_release_announcement) Screenshots (https://imgur.com/a/Mu8xk) After a year of development, testing, debugging and working on our software package repository, we are pleased to announce the release of GhostBSD 11.1 is now available on 64-bit(amd64) architecture with MATE and XFCE Desktop on direct and torrent download. With 11.1 we drop 32-bit i386 supports, and we currently maintain our software packages repository for more stability. What's new on GhostBSD 11.1 GhostBSD software repository Support VMware Workstation Guest Features New UFS full disk mirroring option on the installer New UFS full disk MBR and GPT option on the installer New UFS full disk swap size option on the installer Whisker Menu as default Application menu on XFCE All software developed by GhostBSD is now getting updated ZFS configuration for disk What has been fixed on 11.1? Fix XFCE sound plugin Installer ZFS configuration file setting Installer ZFS setup appears to be incomplete The installer was not listing ZFS disk correctly. The installer The partition list was not deleted when pressing back XFCE and MATE shutdown/suspend/hibernate randomly missing Clicking 'GhostBSD Bugs' item in the Main menu -> 'System Tools' brings up 'Server not found' page XFCE installation - incorrect keyboard layout Locale setting not filling correctly Update Station tray icon The image checksum's, hybrid ISO(DVD, USB) images are available at GhostBSD (http://www.ghostbsd.org/download). *** p2k17 Hackathon Reports p2k17 Hackathon Report: Matthias Kilian on xpdf, haskell, and more (https://undeadly.org/cgi?action=article;sid=20171107034258) p2k17 Hackathon Report: Herzliche grusse vom Berlin (espie@ on mandoc, misc packages progress) (https://undeadly.org/cgi?action=article;sid=20171107185122) p2k17 Hackathon Report: Paul Irofti (pirofti@) on hotplugd(8), math ports, xhci(4) and other kernel advancements (https://undeadly.org/cgi?action=article;sid=20171107225258) p2k17 Hackathon report: Jeremy Evans on ruby progress, postgresql and webdriver work (https://undeadly.org/cgi?action=article;sid=20171108072117) p2k17 Hackathon report: Christian Weisgerber on random devices, build failures and gettext (https://undeadly.org/cgi?action=article;sid=20171109171447) p2k17 Hackathon report: Sebastian Reitenbach on Puppet progress (https://undeadly.org/cgi?action=article;sid=20171110124645) p2k17 Hackathon Report: Anthony J. Bentley on firmware, games and securing pkg_add runs (https://undeadly.org/cgi?action=article;sid=20171110124656) p2k17 Hackathon Report: Landry Breuil on Mozilla things and much more (https://undeadly.org/cgi?action=article;sid=20171113091807) p2k17 Hackathon report: Florian Obser on network stack progress, kernel relinking and more (https://undeadly.org/cgi?action=article;sid=20171113235334) p2k17 Hackathon report: Antoine Jacoutot on ports+packages progress (https://undeadly.org/cgi?action=article;sid=20171120075903) *** TrueOS Talks Tech and Open Source at Pellissippi State (https://www.trueos.org/blog/trueos-talks-tech-open-source-pellissippi-state/) Ken Moore of the TrueOS project presented a talk to the AITP group at Pellissippi State today entitled “It's A Unix(-like) system? An Introduction to TrueOS and Open source”. Joshua Smith of the TrueOS project was also in attendance. We were happy to see a good attendance of about 40 individuals that came to hear more about TrueOS and how we continue to innovate along with the FreeBSD project. Many good questions were raised about development, snapshots, cryptocurrency, and cyber-security. We've included a copy of the slides if you'd like to have a look at the talk on open source. We'd like to offer a sincere thanks to everyone who attended and offer an extended invitation for you to join us at our KnoxBUG group on October 30th @ the iXsystems offices! We hope to see you soon! Open Source Talk – Slideshare PDF (https://web.trueos.org/wp-content/uploads/2017/10/Open-Source-Talk.pdf) KnoxBug - Lumina Rising : Challenging Desktop Orthodoxy (http://knoxbug.org/content/octobers-talk-available-youtube) Ken gave his talk about the new Lumina 2.0 Window Manager that he gave at Ohio LinuxFest 2017 KnoxBUG October 2017 (https://youtu.be/w3ZrqxLTnIU) (OLF 2017) Lumina Rising: Challenging Desktop Orthodoxy (https://www.slideshare.net/beanpole135/olf-2017-lumina-rising-challenging-desktop-orthodoxy) *** Official OpenBSD 6.2 CD set - the only one to be made! (https://undeadly.org/cgi?action=article;sid=20171118190325) Our dear friend Bob Beck (beck@) writes: So, again this release the tradition of making Theo do art has continued! Up for sale by auction to the highest bidder on Ebay is the only OpenBSD 6.2 CD set to be produced. The case and CD's feature the 6.2 artwork, custom drawn and signed by Theo. All proceeds to support OpenBSD Go have a look at the auction As with previous OpenBSD auctions, if you are not the successful bidder, we would like to encourage you to donate the equivalent of you highest bid to the project. The Auction (https://www.ebay.ca/itm/Official-OpenBSD-6-2-CD-Set/253265944606) *** Beastie Bits HAMMER2 userspace on Linux (http://lists.dragonflybsd.org/pipermail/users/2017-October/313646.html) OpenBSD Porting Workshop (now changed to January 3, 2018) (http://www.nycbug.org/index.cgi?action=view&id=10655) Matt Ahrens on when Native Encryption for ZFS will land (https://twitter.com/mahrens1/status/921204908094775296) The first successful build of OpenBSD base system (http://nanxiao.me/en/the-first-successful-build-of-openbsd-base-system/) KnoxBug November Meeting (https://www.meetup.com/KnoxBUG-BSD-Linux-and-FOSS-Users-Unite/events/245291204/) Absolute FreeBSD, 3rd Edition, pre-orders available (https://www.michaelwlucas.com/os/af3e) Feedback/Questions Jon - Jails and Networking (http://dpaste.com/2BEW0HB#wrap) Nathan - bhyve Provisioning (http://dpaste.com/1GHSYJS#wrap) Lian - OpenSSL jumping the Shark (http://dpaste.com/18P8D8C#wrap) Kim - Suggestions (http://dpaste.com/1VE0K9E#wrap) ***

Rob and Jason are joined by Udit Patidar and Anoop Prabha from Intel to discuss Intel's C++ Compiler and suite of Performance tuning Software Development Tools. Anoop Prabha is currently a Software Engineer in Software and Services Group at Intel working with Intel® C++ Compiler Support. He played paramount role in driving customer adoption for features like Intel® Cilk™ Plus, Explicit Vectorization, Compute Offload to Intel® Processor Graphics across all Intel targets by creating technical articles and code samples, educating customers through webinars and 1-on-1 engagements. He is currently driving the Parallel STL feature adoption (new feature in 18.0 beta Compiler). Before joining Intel, Anoop worked at IBM India Private Ltd as a Software Developer for 3 years in Bangalore, India and later completed his graduation from State University of New York at Buffalo. Udit Patidar works in the Developer Products Division of Intel, where he is a product manager for Intel software tools. He was previously a developer working on Intel compilers, focusing on OpenMP parallel programming model for technical and scientific computing workloads. He has extensive experience in high performance computing, both at Intel and previously. Udit holds an MBA in General Management from Cornell University, and a PhD in Computer Science from the University of Houston. News Sandstorm Cap'n Proto cppast - A library to parse and work with the C++ AST Exposing containers of unique pointers Clang-include-fixer Anoop Prabha Anoop Prabha Udit Patidar Udit Patidar Links Free Intel Software Development Tools Intel Parallel Studio XE Suite Page Intel System Studio Suite Page Intel C++ Compiler Product Page C++11 support C++14 support C++17 support Intel C++ Compiler Forum Sponsors Conan.io JetBrains  

Lecture covering the impact of synchronization and memory on parallel performance, using OpenMP instead of Cilk. Topics include granularity of parallelism, true and false sharing, and load balancing.

This week on the show, we've got something pretty different. We went to a Linux convention and asked various people if they've ever tried BSD and what they know about it. Stay tuned for that, all this week's news and, of course, answers to your emails, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines LUKS in OpenBSD (https://www.marc.info/?l=openbsd-tech&m=143247114716771&w=2) Last week, we were surprised to find out that DragonFlyBSD has support (http://leaf.dragonflybsd.org/cgi/web-man?command=cryptsetup§ion=8) for dm-crypt (https://en.wikipedia.org/wiki/Dm-crypt), sometimes referred to as LUKS (Linux Unified Key Setup (https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup)) It looks like they might not be the only BSD with support for it for much longer, as OpenBSD is currently reviewing a patch for it as well LUKS would presumably be an additional option in OpenBSD's softraid (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/softraid.4) system, which already provides native disk encryption Support hasn't been officially committed yet, it's still going through testing, but the code is there if you want to try it out and report your findings If enabled, this might pave the way for the first (semi-)cross platform encryption scheme since the demise of TrueCrypt (and maybe other BSDs will get it too in time) *** FreeBSD gets 64bit Linux emulation (https://lists.freebsd.org/pipermail/svn-src-head/2015-May/072255.html) For those who might be unfamiliar, FreeBSD has an emulation layer (https://www.freebsd.org/doc/handbook/linuxemu.html) to run Linux-only binaries (as rare as they may be) The most common use case is for desktop users, enabling them to run proprietary applications like Adobe Flash or Skype Similar systems can also be found in NetBSD (https://www.netbsd.org/docs/guide/en/chap-linux.html) and OpenBSD (http://www.openbsd.org/faq/faq9.html#Interact) (though disabled by default on the latter) However, until now, it's only supported binaries compiled for the i386 architecture This new update, already committed to -CURRENT, will open some new possibilities that weren't previously possible Meanwhile, HardenedBSD considers removing the emulation layer (https://hardenedbsd.org/content/poll-linuxulator-removal) entirely *** BSD at Open Source Conference 2015 Nagoya (https://mail-index.netbsd.org/netbsd-advocacy/2015/05/23/msg000686.html) We've covered the Japanese NetBSD users group setting up lots of machines at various conferences in the past, but now they're expanding Their latest report includes many of the NetBSD things you'd expect, but also a couple OpenBSD machines Some of the NetBSD ones included a Power Mac G4, SHARP NetWalker, Cubieboard2 and the not-so-foreign Raspberry Pi One new addition of interest is the OMRON LUNA88k, running the luna88k (http://www.openbsd.org/luna88k.html) port of OpenBSD There was even an old cell phone running Windows games (https://twitter.com/tsutsuii/status/601458973338775553) on NetBSD Check the mailing list post for some (https://pbs.twimg.com/media/CFrSmztWEAAS2uE.jpg) links (http://image.movapic.com/pic/m_201505230541335560130d49213.jpeg) to (http://image.movapic.com/pic/m_2015052305145455600ccea723a.jpeg) all (https://pbs.twimg.com/media/CFjPv9_UEAA8iEx.jpg:large) of (https://pbs.twimg.com/media/CD4k6ZUUMAA0tEM.jpg) the (https://pbs.twimg.com/media/CFqn1GXUsAAFuro.jpg) nice (https://pbs.twimg.com/media/CFdIS2IUkAAZvjc.jpg) pictures (https://pbs.twimg.com/media/CFf5mToUIAAFrRU.jpg) *** LLVM introduces OpenMP support (http://blog.llvm.org/2015/05/openmp-support_22.html) One of the things that has kept some people in the GCC camp is the lack of OpenMP (https://en.wikipedia.org/wiki/OpenMP) support in LLVM According to the blog post, it "enables Clang users to harness full power of modern multi-core processors with vector units" With Clang being the default in FreeBSD, Bitrig and OS X, and with some other BSDs exploring the option of switching, the need for this potential speed boost was definitely there This could also open some doors for more BSD in the area of high performance computing, putting an end to the current Linux monopoly *** Interview - Eric, FSF, John, Jose, Kris and Stewart Various "man on the street" style mini-interviews News Roundup BSD-licensed gettext replacement (https://gitlab.com/worr/libintl/blob/master/src/usr.bin/gettext/gettext.c) If you've ever installed ports on any of the BSDs, you've probably had GNU's gettext pulled in as a dependency Wikipedia says "gettext is an internationalization and localization (i18n) system commonly used for writing multilingual programs on Unix-like computer operating systems" A new BSD-licensed rewrite has begun, with the initial version being for NetBSD (but it's likely to be portable) If you've got some coding skills, get involved with the project - the more freely-licensed replacements, the better *** Unix history git repo (https://github.com/dspinellis/unix-history-repo) A git repository was recently created to show off some Unix source code history The repository contains 659 thousand commits and 2306 merges You can see early 386BSD commits all the way up to some of the more modern FreeBSD code If you want to browse through the giant codebase, it can be a great history lesson *** PCBSD 10.1.2 and Lumina updates (http://blog.pcbsd.org/2015/05/hotfix-release-to-10-1-2-now-available/) We mentioned 10.1.1 being released last week (and all the cool features a couple weeks before) but now 10.1.2 is out This minor update contained a few hotfixes: RAID-Z installation, cache and log devices and the text-only installer in UEFI mode There's also a new post (http://blog.pcbsd.org/2015/05/lumina-desktop-status-updatefaq/) on the PCBSD blog about Lumina, answering some frequently asked questions and giving a general status update *** Feedback/Questions Jake writes in (http://slexy.org/view/s25h4Biwzq) Van writes in (http://slexy.org/view/s2AF0bGmL6) Anonymous writes in (http://slexy.org/view/s20Ie1USFD) Dominik writes in (http://slexy.org/view/s20vBtoKqL) (text answer (http://slexy.org/view/s20RjbIT5v)) Chris writes in (http://slexy.org/view/s20USR3WzT) *** Mailing List Gold Death by chocolate (https://lists.mindrot.org/pipermail/openssh-unix-dev/2015-May/033945.html) ***

We're back from BSDCan! This week on the show we'll be chatting with Brian Callahan and Aaron Bieber about forming a local BSD users group. We'll get to hear their experiences of running one and maybe encourage some of you to start your own! After that, we've got a tutorial on the basics of NetBSD's package manager, pkgsrc. Answers to your emails and the latest headlines, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines FreeBSD 11 goals and discussion (http://blather.michaelwlucas.com/archives/2053) Something that actually happened at BSDCan this year... During the FreeBSD devsummit, there was some discussion about what changes will be made in 11.0-RELEASE Some of MWL's notes include: the test suite will be merged to 10-STABLE, more work on the MIPS platforms, LLDB getting more attention, UEFI boot and install support A large list of possibilities was also included and open for discussion, including AES-GCM in IPSEC, ASLR, OpenMP, ICC, in-place kernel upgrades, Capsicum improvements, TCP performance improvements and A LOT more There's also some notes from the devsummit virtualization session (http://blather.michaelwlucas.com/archives/2060), mostly talking about bhyve Lastly, he also provides some notes about ports and packages (http://blather.michaelwlucas.com/archives/2065) and where they're going *** An SSH honeypot with OpenBSD and Kippo (http://securit.se/2014/05/how-to-install-kippo-ssh-honeypot-on-openbsd-5-5-with-chroot/) Everyone loves messing with script kiddies, right? This blog post introduces Kippo (https://code.google.com/p/kippo/), an SSH honeypot tool, and how to use it in combination with OpenBSD It includes a step by step (or rather, command by command) guide and some tips for running a honeypot securely You can use this to get new 0day exploits or find weaknesses in your systems OpenBSD makes a great companion for security testing tools like this with all its exploit mitigation techniques that protect all running applications *** NetBSD foundation financial report (https://www.netbsd.org/foundation/reports/financial/2013.html) The NetBSD foundation has posted their 2013 financial report It's a very "no nonsense" page, pretty much only the hard numbers In 2013, they got $26,000 of income in donations The rest of the page shows all the details, how they spent it on hardware, consulting, conference fees, legal costs and everything else Be sure to donate to whichever BSDs you like and use! *** Building a fully-encrypted NAS with OpenBSD (http://www.geektechnique.org/projectlab/796/how-to-build-a-fully-encrypted-nas-on-openbsd.html) Usually the popular choice for a NAS system is FreeNAS, or plain FreeBSD if you know what you're doing This article takes a look at the OpenBSD side and explains how (http://www.geektechnique.org/projectlab/797/openbsd-encrypted-nas-howto.html) to build a NAS with security in mind The NAS will be fully encrypted, no separate /boot partition like FreeBSD and FreeNAS require - this means the kernel itself is even protected The obvious trade-off is the lack of ZFS support for storage, but this is an interesting idea that would fit most people's needs too There's also a bit of background information on NAS systems in general, some NAS-specific security tips and even some nice graphs and pictures of the hardware - fantastic write up! *** Interview - Brian Callahan & Aaron Bieber - admin@lists.nycbug.org (mailto:admin@lists.nycbug.org) & admin@cobug.org (mailto:admin@cobug.org) Forming a local BSD Users Group Tutorial The basics of pkgsrc (http://www.bsdnow.tv/tutorials/pkgsrc) News Roundup FreeBSD periodic mails vs. monitoring (http://deranfangvomende.wordpress.com/2014/05/11/freebsd-periodic-mails-vs-monitoring/) If you've ever been an admin for a lot of FreeBSD boxes, you've probably noticed that you get a lot of email This page tells about all the different alert emails, cron emails and other reports you might end up getting, as well as how to manage them From bad SSH logins to Zabbix alerts, it all adds up quickly It highlights the periodic.conf file and FreeBSD's periodic daemon, as well as some third party monitoring tools you can use to keep track of your servers *** Doing cool stuff with OpenBSD routing domains (http://www.skogsrud.net/?p=44) A blog post from our viewer and regular emailer, Kjell-Aleksander! He manages some internally-routed IP ranges at his work, but didn't want to have equipment for each separate project This is where OpenBSD routing domains and pf come in to save the day The blog post goes through the process with all the network details you could ever dream of He even named his networking equipment... after us (http://i.imgur.com/penYQFP.jpg) *** LibreSSL, the good and the bad (http://insanecoding.blogspot.com/2014/04/libressl-good-and-bad.html) We're all probably familiar with OpenBSD's fork of OpenSSL at this point However, "for those of you that don't know it, OpenSSL is at the same time the best and most popular SSL/TLS library available, and utter junk" This article talks about some of the cryptographic development challenges involved with maintaining such a massive project You need cryptographers, software engineers, software optimization specialists - there are a lot of roles that need to be filled It also mentions some OpenSSL alternatives and recent LibreSSL progress, as well as some downsides to the fork - the main one being their aim for backwards compatibility *** PCBSD weekly digest (http://blog.pcbsd.org/2014/05/weekly-feature-digest-28-photos-of-the-new-appcafe-re-design/) Lots going on in PCBSD land this week, AppCafe has been redesigned The PBI system is being replaced with pkgng, PBIs will be automatically converted once you update In the more recent post (http://blog.pcbsd.org/2014/05/weekly-feature-digest-29-pbing/), there's some further explanation of the PBI system and the reason for the transition It's got lots of details on the different ways to install software, so hopefully it will clear up any possible confusion *** Feedback/Questions Antonio writes in (http://slexy.org/view/s2UbEhgjce) Daniel writes in (http://slexy.org/view/s21XU0y3JP) Sean writes in (http://slexy.org/view/s2QQtuawFl) tsyn writes in (http://slexy.org/view/s20XrT5Q8U) Chris writes in (http://slexy.org/view/s2ayZ1nsdv) ***

Einige der spektakulärsten Beobachtungen unserer Milchstrasse zeigen die filamentären Strukturen in der Umgebung von heissen massereichen O-Sternen. Sobald diese Sterne beginnen zu leuchten, ionisiert ihre ultraviolette Strahlung das umgebende Gas und erzeugt eine heisse HII-Region. Das erhitzte Gas expandiert in die umgebende kalte Molekülwolke. Die dabei entstehende Schockwelle komprimiert das kalte Gas in die auffälligen Strukturen. An den Spitzen dieser Strukturen entstehen neue, masseärmere Sterne. Bis heute ist die präzise Entstehung dieser Regionen nicht vollständig verstanden. Ziel dieser Arbeit ist die Simulation dieser Entwicklung anhand hydrodynamischer Methoden. Dazu wird ionisierende Strahlung in einen Smoothed Particle Hydrodynamics (SPH) Code namens VINE, der vollständig OpenMP-parallelisiert ist, implementiert. Für die Berechnung der Ionisation wird angenommen, dass die betrachtete Region so weit von dem Stern entfernt ist, dass die Strahlung näherungsweise plan-parallel eintrifft. Zunächst wird die Eintrittsfläche in gleich grosse Strahlen unterteilt. Dann wird die Ionisation entlang dieser Strahlen propagiert. Die neue Implementation ist vollständig parallelisiert und trägt den Namen iVINE. Zuerst wird anhand mehrerer Tests die Übereinstimmung von iVINE mit bekannten analytischen Lösungen gezeigt. Danach wird der durch Ionisation induzierte gravitative Kollaps einer marginal stabilen Sphäre untersucht. In allen drei simulierten Fällen mit unterschiedlichem einfallenden ionisierenden Fluss kollabiert die Sphäre. Zusätzlich kann die beobachtete Tendenz, dass jüngere Sterne weiter entfernt von der Quelle der Ionisation entstehen, bestätigt werden. Desweiteren werden Simulationen über den Einfluss ionisierender Strahlung auf turbulente Molekülwolken durchgeführt. Hier zeigt sich, dass die beobachteten, komplexen Strukturen durch die Kombination von Ionisation, Hydrodynamik und Gravitation reproduziert werden können. An den Spitzen der Strukturen wird das Gas stark komprimiert und kollabiert unter dem Einfluss seiner Eigengravitation, genau wie beobachtet. Gleichzeitig treibt die ionisierende Strahlung die Turbulenz im kalten Gas weit stärker als bisher angenommen. Anhand von einer Parameterstudie folgt, dass die entstehenden Strukturen kritisch von dem jeweiligen Anfangsstadium der Wolke zur Zeit der Zündung des O-Sterns abhängen. Dies ergibt die einmalige Gelegenheit, zusätzliche Informationen über Molekülwolken, die ansonsten schwierig zu beobachten sind, in den von O-Sternen stark illuminierten Regionen zu erhalten. Die Implementation ionisierender Strahlung im Rahmen dieser Doktorarbeit ermöglicht die Untersuchung der Einwirkung massereicher Sterne auf ihre Umgebung in bislang Unerreichter Genauigkeit. Die durchgeführten Simulationen vertiefen unser Verständnis der Wechselwirkung von Turbulenz und Gravitation im Rahmen der Sternentstehung. Weitere erstrebenswerte Schritte wären die genauere Berücksichtigung der Kühlprozesse innerhalb der Molekülwolke und die Implementation der Winde massereicher O-Sterne.