We started producing shows as Today with a Techie on 2005-09-19, 13 years, 10 months, 11 days ago. Our shows are produced by listeners like you and can be on any topic that "are of interest to Hackers". If you listen to HPR then please consider contributing one show a year. If you record your show now it could be released in 8 days.
A thought experiment in whether reducing runtime dependencies can improve security and how to do it.
Hosted by Beeza on 2019-07-24 is flagged as Clean and released under a CC-BY-SA license. Tags:Application development, Application architecture, Security.
Listen in ogg, spx, or mp3 format.
Before the days of the PC, application architectures were often very simple - being little more than the executable itself and any input files. The constraints of the early PC’s very limited resources required new architectures to make the most of those resources.
We now have a situation where most applications either install, or require the presence of, multiple runtime dependencies. Each dependency has an interface which allows communication between itself and the application, but every interface presents an attack surface with the potential to be exploited by a malicious 3rd party.
Modern computers do not have those same resource constraints yet we are still developing applications using the principles that applied 3 decades ago.
Re-usable functionality can be internalised through static linking at compile-time or by code inclusion (along the lines of a .h file in C/C++)
To change from using tried and tested methods is never convenient, but with concern for cyber security high and rising, has the time come to exchange convenience for simpler application architectures that should reduce vulnerabilities?
…And may a move to new (or is it old) architectures deliver a big win for open source software?
In this final episode of "Random Elements of Storytelling", Lostnbronx looks at the question of art vs. commerce.
When is a story a product? When is it a work of passion? Can it be both? In a era of interactive storytelling, what is the difference between a story teller and an audience? And where do art, commerce, creativity, and consumption intersect?
Lostnbronx wanders over hill and dale, and likely fails to adequately explain anything at all.
The Quantum Computer is supposed to be a game changer that renders encryption useless. But is this true? We look at how quantum computing will affect encryption going forward, and show that we are already working on quantum-resistant encryption.
This episode is about modeling vehicle designer that can be used to design all kinds of vehicles available in the game. It relates to episode about performing research.
Two major parts about vehicle designer are components and chassis.
Components are modular pieces of vehicle that are assembled on chassis. They can, among other things, be things lie star sails, astrolabe navigators or long range sensor. Each component is defined by two values ComponentId and ComponentLevel. If you know these two values, you’ll be able to find out details of the component. ComponentId tells what component it is and ComponentLevel the general knowledge of it. When component is first discovered as a result of research, it’s just a prototype and as a such doesn’t function particularly well. Further research refines it and factories are able to produce higher quality components.
Two particularly interesting fields are componentSlot and componentType. componentSlot has type of ComponentSlot and defines what kind of slot the component occupies in chassis. As there are limited amount of slots in each chassis, designer needs to make compromises on what components to install. componentType has type of ComponentPower, which defines what component does in general. It could be sensor or provide supplies for the vehicle for example.
Technology requirements are defined by function: componentRequirements :: ComponentId -> Maybe Technology. It defines which technology unlock a given component. Part of the definition is show below. Each and every ComponentId has to be handled.
componentRequirements ShipLongRangeSensors = Just HighSensitivitySensors
componentRequirements ShipBridge = Nothing
componentRequirements VehicleWheeledMotiveSystem = Nothing
componentRequirements VehicleHoverMotiveSystem = Just HoverCrafts
Second major part of the designer are chassis. They’re stored in database, as I wanted a bit more flexible system than hardcoding as I did with components. Following piece of configuration is used to define database table and generated data for Haskell code. Most of the fields are probably easy enough to guess. type with type of ChassisType defines if this particular chassis is for example a land vehicle or a space ship. Various slot fields on other hand define amount of particular slots that the chassis offers.
Not all chassis are equal and some (probably pretty much every one of them) have some sort of requirements that has to be fulfilled when designing a vehicle. For example, space ships require a bridge for captain and star sails. Bawley, smallest of the working ships has room for two star sails, but requires only one of them to be installed in order to be a valid design. Flyboat on the other hand is smaller ship built for speed and always requires two set of sails.
This data is stored in required_component table and represented as RequiredComponent data. Both are generated from the definition show below:
With all that data, we can now design a vehicle. Process is roughly the following:
based on completed research, get a list of chassis that are available
select chassis from the list
based on the selected chassis and completed research, get a list of components that are available
select components to install
remember to check that maximum tonnage isn’t exceeded and that there’s enough slots and requirements are met
fill in name
save into database
Completed design is saved in two different tables. First one design holds info like name of the design, faction that design belongs to and used chassis. planned_component holds info about which components are planned to be installed and in what quantity.
deriving Show Read Eq
Released: 2019-06-27. Duration: 00:31:08. Flag: Clean. Tags:Music,Recording,Audio,Tape,Reel-To-Reel,Open-Reel,Recording Devices,Tape Speeds,Bash Scripting.
I talk about my latest thrift-store gadget, a 1969 Sony portable reel-to-reel tape recorder
Released: 2019-06-24. Duration: 00:31:04. Flag: Clean. Series:How I Found Linux. Tags:linux, intro, story, discourse, bsd.
A response to the request for "how i got into linux" and a little of my history with Linux/BSD
Released: 2019-06-17. Duration: 00:26:16. Flag: Clean. Series:Interviews. Tags:opensource, photography, lubuntu, darktable, rapidphotodownloader, displaycal, gimp.
In this episode, Yannick talks with Wendy Hill about her use of opensource software in her job
Released: 2019-06-13. Duration: 00:29:17. Flag: Clean. Tags:programs, linux, android, apps, applications, lists, favorites.
Moving right along with shows from the requests list, I combine two program lists.
Released: 2019-06-10. Duration: 00:39:07. Flag: Clean. Series:Interviews. Tags:nagios, network, monitoring, opensource, singleboardcomputer, sbc, raspberrypi, odroid.
In this episode, Yannick talks with Robbie Ferguson about the Nagios Enterprise Monitoring System
Released: 2019-06-06. Duration: 00:23:11. Flag: Clean. Tags:HPR, Policy Change, Legal, DMCA, TWAT, Fair Use, PacketSniffers, Copyright.
A request for comments on not publishing clips with known fair use samples
Released: 2019-05-27. Duration: 00:46:24. Flag: Clean. Series:Interviews. Tags:vcfe, vintage, computers, exhibition, munich, germany.
I interviewed some of the exhibitors at the recent vcfe.org event in Munich, Germany.
Released: 2019-05-23. Duration: 00:08:13. Flag: Clean. Series:Podcast recommendations. Tags:podcasts, narrowcasting, broadcasting.
I provide a slightly different view on podcasts to that recently given by Knightwise.