Episode: 3457
Title: HPR3457: Tables
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3457/hpr3457.mp3
Transcribed: 2025-10-24 23:47:02

---

This is Hacker Public Radio Episode 3457 Fortunity, the second of November 2021.
Today's show is entitled, Tables and is part of the series' databases it is hosted by Clot 2
and is about 38 minutes long and carries a clean flag. The summary is how and why I convert
tables to lists. This episode of HBR is brought to you by an honest host.com.
Get 15% discount on all shared hosting with the offer code HBR15. That's HBR15.
Better web hosting that's honest and fair at An honest host.com.
Hey everybody. I got a message from Unmastedon from a person named F Toys and they said that they
were listening to a show from me about macros and how they used to use macros for two
generate tables in HTML and it got me to thinking about how much I hate tables but also I can see
the appreciation for tables. It's a complex relationship and I want to talk about that here
on Hacker Public Radio. So tables, what are they? Well a spreadsheet would be the quintessential
example of a table I think, right? You've got your columns across the top, you got your rows down
the side. The intersection of those as you can scroll across the page are called cells. That's
where a row and a column intersect as it were. It's called a cell and in that cell there's
information. Now we see this model of content delivery in lots of different places. We see it
in books and they're quite useful actually. I have a book here in front of me that has a lot of
tables in it. I'm just on page 41 and I'm already on table number 31. That's how many tables
there are in this particular book. It's an Advanced Dungeons and Dragons second edition
player handbook. So lots of tables and tables can be really good for clarity, for quick reference
and tables also have a kind of implicit communication that they carry with them and you see a table
and you understand what you're looking at. You know that you are about to see something.
Usually some kind of almost a comparison. Maybe it's not exactly a comparison but in a way it's
a comparison almost no matter what because there are different cells and the further you go along
in the table, the information gets modified by what column and row it happens to fall in.
So for instance if I look at a table actually right here here's a table. So a priest
Thaco for level 3 is 20 but the priest's Thaco at level 6 is 18 and then it's 7 it's 16 and then
that's 16 it's 10 and so on. But if you look at the same data for a rogue at level 3 they're 19
at level 6 they're 18 at level 10 they're 16 and at level 16 they're 13. So you get the sense that
that you're looking at information that changes either over time or under certain conditions.
And so it's a it's a it's a great way to kind of reference like if you're if you're doing
something and you have a table you don't need to know what a priest or a throag or a warrior or
a wizard is you don't need to know what Thaco is but if you're if you're looking to optimize those
things you think okay well I want the best Thaco I can possibly get. So you can look at this table
it's laid out in this manner and you can tell how you could optimize that by just looking across
so by by 20 the lowest Thaco there is is under the warrior class and so I guess if I'm if I'm aiming
to optimize my Thaco across across time I should be playing a warrior and that turns out to be true
their Thaco goes down by one every single level while everyone else has a different rate of of
advancement. So whether you know what that is or not you you know now the relationship between for
instance a warrior and a priest you can look at the table and say okay the warrior you you decrements
one per per per heading per column whereas the priest does it decrements two every three columns
so now we know don't know what we know but we know and and that's a great thing about tables
is that they present the information in an easy-to-reference kind of manner and and something that
may or may not be even closer to home here for you it depends on what world you're coming from
as a listener but let's say that you're looking for a Linux distribution and you have a very
specific package management requirement you know you like DNF you just can't decide which
distro you want to go with and so you might look at a table that gives you the operating system
say the init system and the package manager and you know I don't know something else the default
shell and you could scroll through this list and kind of scan the table and you kind of focus in on
the column that says package manager and it's because that's the thing that you care about
and so you you see the list okay DNF well there it is so we've got what do we got oh we got
Fedora well that's kind of expected we got rel and sentos and magia I hadn't thought of magia
and maybe open mandriva although actually I don't know if they're actually using DNF yet I know
the bjia did switch over to DNF and so on and then you could maybe you'd keep scrolling down the list
and then you run into slack pkg well that's not DNF which one is that or that slackware you merge
that's gen2 okay and then apt and that list would go on for for half of a page or several pages
and so on so you can kind of you can use a table as a way to focus in on a specific kind of information
and then cross reference what what kind of data surrounds the thing that you care about it is
sort of it is a visual sort of way to select a table in a database so that's a table tables
are really good they're great they're great for reference they're quick they're fast they
communicate the differences of of of data to to the reader quickly they're easy to reference they're
easy to cross reference so why do I hate tables well obviously I don't hate tables I mean I
actually really really like a good table I think tables are great going on record saying that
tables are great however tables are also have real pain to lay out and I mean initially they're
not I mean you have a table you you you generate the table in whatever formatting tool you're using
whether it's a word processor or code like HTML or XML and and it's done and you're happy with it
the problems usually come around in two different places one is maintenance and the other is probably
not in this order actually one is maintenance and the other is physical layout so tables I'll just
start with the layout because this is the obvious one and the the the reason I really really hate it
the the layout is is just based on literally what media your your reader is viewing the table within
so if you're writing your initial table for I don't know the internet then you probably have
essentially the entire screen of your user and there's no way of telling what your screen of
what that user's screen is but we all kind of assume a reasonably modern display and I'm thinking
personally of a desktop because I'm sitting in front of my desktop maybe you're thinking about
a laptop either way they're all about you know 1920 by 1080 or maybe they're a lot a lot larger
whatever it is it's kind of like you know a big display that you can look at a document whatever
document is on full screen and you kind of you get the whole thing well that in itself poses one
problem and we've probably all seen this where you're on a on a on a page that has set its table to
just take up as much as much width as it possibly can and you think great well now I'm never going
to have a problem cross referencing this table because it's it's big taking up the entire width of
the of my document but have you ever tried to look at like a three column table that has forced
itself to spread out into a you know a physical like a 30 inch thing you know every column is like
literally physically 10 inches wide it gets kind of stupid and it's actually gets a little bit
difficult to try to track the data across the page then at least it is for me because you you
you you look at the left and you say okay that's that's that one that's that's magia now I'm going to
trace across who am I fault I've gotten onto the wrong row now okay let me go back and and trace
with my finger so that I'm not losing you know and so you have to like map it out almost it's
almost it's too far apart the opposite is obviously true I mean if you've ever seen a table rendered
in html on a a mobile phone then you've probably seen tables that just physically literally cannot
fit on that mobile screen like at some point like I don't know a 10 column table with reasonably
large words they it just literally can't fit on the what is this like maybe the three inch wide
mobile screen oh sure you can rotate it and give yourself a good six to seven inches but it's
it's kind of difficult to fit all of that information on such a small screen and maybe you have
to just zoom out so you can kind of like make it all fit or maybe you have to zoom in and then
just keep scrolling around and so you're kind of like looking through this weird sort of view portal
at at this larger table it's it's really clunky and and that's you know if you're trying to optimize
that from the well from the user perspective it's clunky in in lots of different examples that I've
just I've just gone over and from the developer perspective it's clunky because you you want to
optimize it for each display I mean ideally you don't you you want the information to be useful
that's why you're writing it down in the first place and so you try to make adaptations you try
to think you know maybe there's a library out there to reflow a table correctly or maybe there's a
um maybe there's a certain trick that you can do as the as the developer based on
audit you know attempting to detect the screen size and so on so one does try to optimize it but
it gets it starts to become really difficult to maintain because now you're having to like
recode every single table depending on certain conditions and frankly those conditions you don't
even always really know what those are maintenance gets really tough as well later on or earlier on
when you're actually writing the thing I don't know if you've ever tried to write a table in XML
or HTML there are a lot of tags that you have to come up with that you have to use remember
and all of those and the way that is getting laid out of course in your code has basically no
bearing on what it's going to look like later which I mean that's kind of that's what code's all
about right I mean like it very rarely the code doesn't usually look like the render like that's
that's why we call it code um well I mean that's not the only reason we call it code but I mean
that that's an expectation but for tables I mean it really can be difficult to sort of remember
where you are in your code um to the extent that sometimes I've I've fallen back on like if I'm
composing a table from scratch in HTML I've sometimes gone and rendered the table in a markdown
and then converted the markdown to HTML because at least with markdown you get this weird kind of
ASCII rendering of a table you use dashes and pipe symbols to construct a table which you'd
think kind of would make some sense I mean it does kind of make sense but on the other hand
it's actually really clunky too because I don't know if you've ever tried to edit a table that is
composed of just dashes and pipes but you spend more time making all of the cells kind of like line
up correctly org mode helps with this it has some really nice table tools that that kind of help
with that but it can be really really clunky and sometimes you just think why why am I doing it
this way why don't I just open up a spreadsheet and put the information in there and then I don't
convert that to HTML somehow or something like that so it's not fun is is the point and that's
those are the reasons I really don't like tables and I I really really like the idea of being
able to construct information and then deliver it in lots of different ways so if I've written
something down I want to know I find great comfort in knowing that I can then export that document
the source code of that document can be converted and exported or whatever into multiple formats
meaning I should be able to deliver the the the the thing that I am trying to communicate I should
be able to deliver that as a plain text document you know mark down whatever as as the source code
itself XML or whatever I should be able to export it as HTML I should be able to export it as EPUB
PDF some kind of word processing document and and and and whatever else comes around you know like
whatever other format there might be I want to I want to know that there's one source of well
there's one source code and from that one source code I can render out to a lot of different formats
because presumably my readers are going to want a lot of different formats and presumably there
are formats out there in the future that I have not anticipated yet that I would like to have some
kind of you know future proof against or getting into I want to be able to just sort of inherit
those future formats and I don't know what those will be but ideally I'll be prepared for them
and I'm not going to have 31 or 81 or 120 tables that I then have to go through and manually modify
because I didn't expect there to be some other format for for for delivery for content delivery
so I've established why tables are great I've told you why I think tables are horrible to deal with
as a as an author slash developer slash content creator and now I'm going to talk about what I do
about tables in real life like this isn't um this isn't a dogmatic type of thing this this isn't
something that always happens no matter what with me it is something that usually happens though
it is it is something that is very common for me to do and that is to convert tables into some
other format of data and this is this is a this is data conversion like this is the kind of thing
that you might do uh you know with a programming language you're parsing some kind of data you're
parsing it and converting it to to some other schema this is a this is not a this isn't a mindless
thing that you can't that that you can count on making sense all the time you sometimes have to
really restructure the data but that in itself I think is an interesting challenge so let's let's
take something that probably many of us will be at least vaguely familiar with and I'm going to
try to do it sort of really simple really easy we'll just we'll take it slow and we'll convert it
to a couple of different we'll convert a couple of different tables to lists okay so let's say
you've got a table the top and I'm keeping it really simple here it's a top row is OS init system
and package manager those are our columns so three columns OS init system package man down the
side under OS we'll have fedora slackware and gen 2 rows columns simple so under fedora as the
init system will have system d and the package manager package manager is dnf slackware we've got
bsd for the init system or bsd style for the init system slack pkg for the package manager and then
gen 2 we've got open rc for the init system and package manager emerge I mean let's not get into
questions of whether or not gen 2 would necessarily insist on open rc being the init system because
it's quite a flexible system you could build it with something else same goes frankly for slackware
but I'm just going we'll just leave it with that just so we have different data through our table
now as a table that's a three column table it's four rows well maybe you could say three rows
with a header row but I mean that's four rows there's a lot there's a good likely it's quite likely
that that actually probably wouldn't be a super problematic table but it'll be the example so
instead of structuring it as a table which again admittedly you know especially if we imagine under
the that that fedora wouldn't be the only entry for certain for instance system d and dnf
combination like they're probably there'd certainly be rail there'd certainly be syntax there'd
certainly be magia haven't looked at open medriva um in preparation for this episode so I don't
remember what they're up to right now but you know you'd have more there a slackware would be on
a line as its own although maybe not maybe there'd be some systems under slackware that would also
be using a bsd or bsd style init system so maybe there would be some listed there open rc maybe
there'd be some other things that we could list there like arch or something I don't know um so
you know you can imagine this this list being bigger in in in really all of the different
directions but here we go so instead of writing that as a table I would choose to write that as a
bulleted list or possibly as a itemized list or or I should say uh what what is it called in doc
book um uh ter variable variable list and so you might have the heading or or the first bullet as
fedora and in under that you'd have two bullets you'd have sub bullets you'd have init system colon
system d package manager colon dnf and then slackware init system bsd package manners
gintu init system open rc package manager emerge and so on so you would you would essentially get
yourself into kind of a loop over over the um the initial column the os column and that would become
your top level bullet points and then you would subjugate the other cells in the table to sub bullet
under the under that column and and that would be the loop because you'd always have you'd always
have that predictable init system package manager heading init system package manager heading
init system package manager so that works it tells the same story data wise it delivers the exact
same information and it it does so in such a way that is predictable and repeatable which
doesn't really make any difference except that it helps the user get that same kind of cross
reference advantage so if i know that i'm looking at this list and all i care about is the package
management system then i i know after like the first one or two that package manners always going
to be the second sub bullet point under each heading and i even label that every single time
to really really drive home i mean that's redundant and you could argue that we should just like
for um sort of conservation of bits i guess that we should just say fedora bullet point system d
bullet point dnf slackwear bullet point bsd style bullet point slack package ginto bullet point open
you know but i mean why do that like why not it doesn't cost that much extra to put a little
heading in front of each one so you've got the key and value pair it's almost yam million
yam million it's it's almost like yaml really i mean if if if we're looking at this it's essentially
saying here's a here's a sequence containing mappings and that's what we're delivering and and
it's relatively simple to scan through that you know as a human with it you sort of human brain
human eyes it's relatively simple to scan through that and extract the the focus that you want
is it as easy as looking at a table i actually find that it is does it have the same communication
that sort of that up front one two punch that a table has i don't feel like it necessarily does
i think we humans really do find tables comforting and familiar or at least i should say as a certain
kind of human i don't know that all humans find tables comforting and familiar although i think
that we do because you see tables even in um you know when you're when you're shopping online
um you'll you'll look at comparisons like does this gpu have such and such or or what about the
this the subscription plan what kind of benefits do you get with if you take this level of subscription
versus that level of subscription and so on so you do kind of get those you get that in a lot of
different areas i feel so i think it might just be yeah sort of an inborn natural trait
that you see a table and you understand what it's trying to communicate whereas a bullet list you
don't necessarily always know is this just a list of stuff or is this a comparison of stuff
like you have you do have to work a little bit harder to understand or or rather to establish what
for instance a list is really trying to communicate to you like what is the data structure
but through repetition and verbosity i feel like that structure can be conveyed pretty quickly
and the benefit for me far outweighs losing that sort of upfront hey here's a table now you know
what you're going to be looking for um i would rather have the bullet list because they're easier to
code they're easier to maintain they're easier to export now of course a table doesn't always
translate exactly to a list the way this one did this was a really good example of
of a sequence of data that contain key and value pairs that's pretty easy to convert into a list
to be honest i mean it's it's it's it's a really direct kind of translation sometimes that
doesn't always work so for instance let's say that we're looking at a table that is comparing
the uh licenses and interplanetary uh existences of operating systems so you might have uh as
your columns you're operating system you have a column saying whether or not it's open source
and you have a column defining whether or not it is landed on Mars so this would be a classic table
that you'd see when you're looking at i don't know like a car sales report or or a um like i said
earlier like graphics card comparison or something like that where you'd have like little green
checkmarks in one column and at certain points they would stop being green checkmarks and they
turn into red x's but if you go over to the next column where you pay five thousand dollars more
for that car or for that graphics processor then suddenly you get more green checkmarks and fewer
red x's and then finally if you go premium and pay ten thousand dollars more you get all green
checkmarks nothing but green checkmarks all the way down so anyway you got operating system
open source landed on Mars those are your columns your your rows are linux bsd and macOS
linux open source yes bsd open source yes macOS open source no landed on Mars linux yes bsd
no macOS no don't hold me to this data i don't actually know what has or has not landed on Mars
some bsd code probably has almost certainly on Mars but the kernel itself as far as i know
is not on Mars as of this recording as of my very brief research so as a bullet list if we took
my previous example very literally we would have some ugly list like bullet point linux open source
colon yes landed on Mars yes bs bullet point bsd sub bullet point open source yes landed on Mars no
macOS open source no landed on Mars colon no that would be serviceable but i feel like
in that case the boolean values of yes and no make the verbosity i don't know a little bit
it becomes like with that kind of verbosity then the the landed on Mars colon no well then why
even mention it it hasn't landed on Mars so why why occupy my visual and brain processing
space was something that resolves to it doesn't matter like it doesn't take to a no value that
doesn't that doesn't add anything i think in this case i think it actually requires more brain
processing and more more it provides more visual noise than than what we could do so in that case
i don't think that the the presentation the the translation of the table into a bullet point
really services the reader i think what would be better well what i really think would be better is
not present this as a table so for instance i would just write linux and bsd or open source operating
systems while macOS is not of these posics compliant systems only linux has landed on Mars so far
there i've just delivered the same amount of information in two sentences and in a clearer and
and more fluid fashion now to be fair that might that might not always be the intense like you might
not want to be writing pros you you may actually want to provide people with sort of the data i mean
certainly you always have the choice of just taking that data and and doing a literal translation where
you where you make the first row the first cells the first column of cells the the main bullet points
and then sub bullet points of key and value pairs that totally works but i'm trying to get an example
where maybe that isn't optimal like maybe that that's not what you're trying to do so it's just
maybe the thing that you that you defaulted to while i'm doing tables anyway i might as well put
this this comparison into a table but let's let's assume for a moment that that's not a necessary
you don't need the green check marks and red x's you're just trying to convey the information
so another way to do that could be to summarize what's common and then highlight the differences
so for instance you might write one line that says or i guess two two lines there are a few
Linux systems on Mars neither bsd or mac os have yet landed on Mars and then as bullet points bullet
point Linux and bsd are both open source mac os is based partially on open source and includes
components from the bsd kde canoe and other projects there so now you've gotten you've you've
taken up visual you've taken up visual sort of processing cycles with the bullet points and you've
highlighted in as a group the common elements so in one bullet point you have defined what certain
groups have in common Linux and bsd are both open source so that takes care of Linux open source
yes landed on Mars yes bsd open source yes and that's it so that that that highlights those three
cells we still have three cells that we haven't talked about which is the fact that bsd is not open
it is not landed on Mars and that mac os is not open source and has not landed on Mars so for the
second bullet point then we highlight the fact that mac os is only partially based on open source
so that takes care of the open source cola no under mac along the mac os axis and um that's it
and then the sentence that we summarized uh the data we've got there are uh Linux systems on Mars
so that's uh Linux landed on Mars yes and neither bsd or mac os have yet landed on Mars so that's
mac os no and bsd know for the landed on Mars still other times you just have to question what the
tables actual intent or or purpose really is and so to bring it back around to where we started with
dnd for instance um there are tables there are lots of famously lots of tables in dnd books that's
just kind of that it got started early on and it proved useful and kind of endearing and so they've
persisted and even in the latest edition of dnd there are tables under each uh character class
that sort of outlines the lifespan of that character so if you choose for instance a barbarian
to play a barbarian then there's a table telling you how that barbarian is going to progress
over the the course of of of their duration of their life in in the game and and that's a useful
thing and i think in in in one way you think you look at that table and you say well that's for a
player who's looking through this handbook trying to figure out what class they want to play
and they're going to look at this table and look at things like well what kind of bonuses do i get
throughout each level and they'll look at that they'll look at the barbarian for instance and
and look at the progression of the barbarian and they'll be happy with that but then they'll go
back and maybe flip over to the fighter and see what progression the fighter has and what kind of
benefits they get across you know through the course of their of their lifespan and i think in a
way that that's kind of the intent of those tables is to sort of be a a summary and maybe a little
bit of a shopping list for players as they try to choose which class they want to play but if you
really think about it if you really look at that table and think about what's actually being conveyed
there's not really that much there aren't a whole lot of specifics in that table that you you
get things like at a certain level you get a primal path but what is a primal path well if you've
played dnd before fifth edition then you know what a primal path or you might might know what a
primal path is for a barbarian if you played a barbarian but but you'll know that that primal path
is actually a set of other options so you have to choose your primal path so knowing that you get
a primal path at third level as a barbarian doesn't actually tell you anything it just tells you
at third level you're going to have to make some new choices about sort of how your character
develops and that's not even summarized in this table is just it's just an alert that hey you're
going to have to make choice as well there's a certain implicit expectation here that you're
going to have to make choices about your character if you know anything about leveling up whether
you've played dnd or just a video game that has you do some action when you get a certain number
of points some kind of level up action which is pretty common these days then then you know that at
a new level you're going to have choices to make that's just if that's an RPG so I don't know
how useful the table actually is in terms of sort of a summary of that character and when I was
adapting the free under the open game license the the free rules of fifth edition for players who
hadn't yet purchased the player handbook I decided to render those tables as lists instead and
frankly I was pretty happy with them they are not you know by any means they are not I think
probably they take up more space than the table I think there's no question about that the table has
the advantage of being able to use both vertical and horizontal space to its advantage while
bullet lists don't they just use vertical space so you get a you know on one page you get two
columns of a bullet list whereas what really should be happening is like maybe a fourth of the
page or a third of the page gets taken up by one glorious table but I didn't want to have to
deal with the table I didn't find it fun to code the table I didn't find it fun to maintain the
table and so I chose a and I also didn't I didn't know what format my players would be consuming
the the data because I was going to offer it to them as plain text I was going to offer to him
as EPUB and as PDF and I could probably offer to him as HTML if I wanted to so I didn't know what
format they were going to consume this so I didn't really want you know especially in plain text
the the table just looks horrific it's just it's a horrible thing to look at because it runs right
off the page asky asky text or or mono space text I mean it is as wide as it is every single character
and so it if you have a lot of data in your table it just keeps going and going and going forever
so that wasn't that wasn't something that I wanted to do and so I just I translated it into
a list and it worked and the the thing about that is that it wasn't it was really just a
YAML sequence if you think of it in YAML terms so there there I didn't do necessarily predictable
key value pairs because not everything happens at every level so for instance you have level one
and then so this was a numbered list which makes a sense so one is level one the bullet point
under that is proficiency plus two so now your proficiency bonus is plus two good to know you get
rage and you get unarmored defense you have to look up what both of those things are later in the
text but that's just kind of how dnd works at level two number two level two you get reckless
attack and danger sense at level three you get rage and primal so more more rage and danger sense
more no that's a primal path sorry primal path at that level three four level four ability score
improvement five proficiency plus three so now we're kind of getting some repetition here but not
really I mean you'll see proficiency upgrades throughout you'll see a couple of ability score
improvements throughout so things pop back up but it's not predictable unless you're very very
familiar with kind of like the way that dnd levels up but what I realized even as I was translating
is that the intent of the table might seem it may seem to be a good summary of information about
that class but actually what it is is a guide for players to know what to do when they level up
it can be a very sort of frantic frightening experience to level up you think oh my gosh what do I
have to do I have to make changes to my character what kind of changes do I have I have to make
well with this list it it tells you correctly exactly what you need to do and is it better than a
table frankly I kind of I think it is to be honest because the table doesn't necessarily say
here are the changes that you need to make it more communicates the idea of hey here's an overview
of what your class is going to be like over the course of level one through 20 that doesn't really
I mean you have to it's another step I think for many players to think ah okay so if this is an
an overview it is also a recipe whereas a list especially a numbered list it just cries out
this is a recipe this is a an algorithm this is a these are the steps that you have to take
start at one apply these items when you get to two come back to this list start at two and apply
these items this is all cumulative there's no implication that you have to replace anything
this is very clearly it's building on itself as you increment levels so frankly I think in many
ways a list for that purpose is superior to a table even though a table is what I think the designers
of that text thought was the most logical sort of obvious method of delivery and I mean I'll admit
that the table probably is useful I mean it is a great once again it's a great at a glance tool
if you can afford to have a table for that sort of at a glance overview I will admit that's not
too bad is it is it all that different from a from a list I don't think so for me I am just as
I'm just as happy scanning over a list quickly as I am a table but I think there is I acknowledge
and I even identify with like I I feel the same sense of sort of comfort and relief ah here's
all the information in one relatively small footprint here's all the information all at once
now I'll never look at that table again or maybe I will just to kind of get a get an idea of where
I'm headed but for the actual sort of step by step process the the list is actually really really
useful and it's it has become my preferred method of consuming that information interestingly I would
rather look at my lists than the tables in the D&D book when I'm when I'm playing a character when
I'm doing a quick reference as dungeon master to figure out for a player that might not be clear
on some feature then I often do flip straight to that table because I'm like hey that's that's
going to be all the information right where I need it although frankly I could also get that
information from my list anyway so I kind of like my list is what I'm trying to say
anyway that those are my thoughts on tables and how to convert data from tables into
something that might be easier to code to maintain and certainly render and possibly even understand
for your readers thanks for listening I'll talk to you next time
you've been listening to Hacker Public Radio at Hacker Public Radio dot org
we are a community podcast network that releases shows every weekday Monday through Friday
today's show like all our shows was contributed by an HBR listener like yourself
if you ever thought of recording a podcast then click on our contribute link to find out how
easy it really is Hacker Public Radio was founded by the digital dog pound and the infonomican
computer club and is part of the binary revolution at binrev.com if you have comments on today's show
please email the host directly leave a comment on the website or record a follow up episode
yourself unless otherwise stated today's show is released on the creative comments
attribution share a light 3.0 license