hpr-knowledge-base/hpr_transcripts/hpr0540.txt

Episode: 540
Title: HPR0540: Uber Leet Hacker Force Radio  04
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0540/hpr0540.mp3
Transcribed: 2025-10-07 22:47:38

---

I'm going to send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Oh, I'm gonna send him to Oda's voice,
Hello and welcome to our show.
My name is Six Fluff and you're listening to episode number four of the Relief
Hacker Force Radio program. This is kind of a special episode because I'm doing it
more or less live. I mean you're listening to it kind of post-production, right?
But there is no real production. There is no editing. It's a I kind of don't like
editing. It's rather than it comes to radio programs. So, unopened BSD typically
what's used for sound is a library called Lipsound I.O. And one Lipsound I.O. does
aside from dumping sound directly to a device, it also can dump sound to a
socket. And this socket is being listened to by a user space program called AUCAT.
And AUCAT mixes the streams that comes into the socket and dumps them to the
sound device. Or it does the reverse way around if you have a multiplex sound
device at the same time. Which is very nice. So this radio program is kind of
like a speaker cast. The music you are hearing is being played in M player and I'm
talking on a radio receiver. So, there you go. This episode we're going to be
talking to Cobra 2. And we are also going to be talking to the command line of the
command line podcast. And we're going to be releasing a couple of things. But before
any of this are standard poem. This one is called Ode to my computer. And if you have
any poem that you'd like send it in, so I don't have any poem every episode. But this is
as I standard poem. When I think of the sheer amount of work needed to put together
modern poem slash essay. Alright, alright. When I think of the sheer amount of work needed
to put together a modern operating system, it makes me never bored by my computer.
My fingertips are rest on the machine containing years and years combined lifetimes of hard
work. When I think of all the work and it serves code on my hard drive and the fact that
I have complete access to it, I'm just amazed. Many times I spent my day saying things to
myself like, hmm, I want to have a malloc works. It actually being able to find out. As
I look over the codes, the code line by line, it kind of reminds me of stones and Egyptian
pyramid or something. I imagine the sweat that's going to teach one. I imagine the debugging
nightmare to get it actually working. It's pretty awesome when you think about it. Great
engineering efforts have always fascinated me. Thinking about the sums of people's work,
I've always found very exciting.
Now, the first thing we're going to release is a program called Yes, Please. Yes, please
is a command line program that takes a screenshot of your computer and uploads it to a screenshot
aggregator called UnixPardon.com. Now, to explain what that is, I'm going to be talking
with Cobra II, with the main painter of UnixPardon.com briefly here. I recorded this interview about
a week ago doing my same sort of hack to AU Cat to dump out to a wave file. And the receiver
is using at a time as a payphone receiver and it sounded absolutely horrible. It sounded
way pinched. I wonder how much the sound quality is degraded in payphone simply because of
the receiver. But anyway, I blame it perhaps on the impedance of the microphone. The receiver
is what kind of microphone my computer wanted. There's something like that. It just sounded
terrible. But when I talk to Cobra II, it came out pretty well. So let me play that.
So let's stop the music there. Kind of feel like this is the phone show or something with
the music stopping like that. And give Cobra a call. I believe this is his phone number.
Let's see if we don't wake him up.
Pick up the phone Cobra. Hey, is this Cobra II? Yes, it is. Hang on a second. Let me walk
away from the party. All right. I did manage to get here safely and securely. So really
nice. What kind of party is? I am at a middle of nowhere party. Basically a bunch of guys
and girls get together and drive out on pretty much an abandoned logging road. You can
drive in a DJ with four equipment, bunch of beer and alcohol and party until the morning.
Well, that actually sounds like a lot of fun to be honest with you. Oh, I'm saying that
sounds like a lot of fun to be honest with you. I think I'm going to have a lot of fun.
I'm not going to get drunk, but I've been meaning to ask why Cobra II? Why not just Cobra?
Well, Cobra II is the first cashware I ever came up with. And when it came time for me
to play around with IRC, I wanted to nickname Cobra, but somebody else already had it. So
Cobra II. So what's this Unix porn.com stuff that everyone's talking about?
Unix porn is basically a place where you want to use the nerd and pretty much anyone that
uses a Nick desktop, goes to post their screenshots of their just average everyday Unix flash Linux setup.
And I say Unix flash Linux because their screenshots of Tolires, various BFCs and Linux environment
are posted up there. It's basically, you know, it's kind of a niche community of where people
can just go to kill a little bit of time and see everything that's out there and see how every individual
user customizes the desktop to their own personal preference and just basically
there's a flexibility of open source.
Yeah, it's kind of fun to be honest with you. I think it is to see what other people
see other people are up to. Now, you're the maintainer of this site. I take it
how long has it been around? I was made aware of it through, I think,
to radio, actually, to be honest with you. But how long has this been around?
Well, slightly started up Unix porn back in the, you know, say roughly the third and fourth quarter of 2008.
And I got on board at the end of 2008 somewhere around December.
And just kind of got in both and asked if I needed any help.
Because we were giving a lot of spam attacks on Unix porn.
I mean, we were having hundreds of thousands of spam comments posted on everyone's
post every day. And they weren't getting deleted.
And I asked quite a few if he needed help getting rid of that.
And he just made me an admin and I've stuck with it ever since.
So you're still the leading a lot of spam, I take it.
Not so much. I changed some configurations and walked around with a couple of
settings and drastically reduced the amount of spam that we had.
But unfortunately, that cut out the ability of anonymous comments like just anyone
visiting the website couldn't just go, hey, I really like this setup.
Can you send me your config files? You know, give me an email here.
That sort of thing. Which, which is really kind of a bummer.
So not everybody wants to go through the hassle of registering an account with yet another website.
Yeah, but it seems like the best solution.
Oh, no, no, no, no, no. I was just saying it seems like the best solution.
But you go ahead and say what you're going to say.
Yeah, it's in the end. It worked out fairly well.
Now we have pardon me in spam.
The only spam that we do have are from those newly nine people who actually go through
the entire registration process, not just the bot.
So the persistent spares and other words, no, no, no, I'm kidding.
It's been pretty good. I haven't even, like, I wasn't even aware that there was any spam at all.
I have not been exposed to it on the Unix part, to be honest with you.
So guys, you're doing a good job.
I'm kind of on top of the user registration and the kind of spam that pops up anytime a new user is registered to the website.
I get a lovely email that says, hey, it's a register to the website.
And I'll give them about 30 minutes and then I'll go around behind and check and make sure they're not an actual spammer.
If they are, I take care of it.
Sorry, could be not.
The wonderful ability to SSH into my machine from anywhere.
So I can take care of it.
All right. Well, thank you. I appreciate it. Thanks for letting us know what Unix part is.
Any time.
And I hope you enjoy the party.
Thank you very much. I'll do my best.
Don't do anything I wouldn't do. I don't know what that means.
Sorry. I'm going to be a good boy.
Getting married very soon.
Really?
Yes, ma'am.
Wow, co-beings.
When are you getting married?
Yes, I am.
I'm getting married very soon.
I'm getting married very soon.
Yes, I am getting married very soon.
I'm getting married very soon.
Thank you.
Take care of your co-ber, too.
Pardon?
Take care of your co-ber, too.
Thank you, Mr. Big Pops.
You're doing pretty much fun tonight.
I'll definitely not.
All right. Bye-bye.
Bye-bye.
So this program, again, is a command line program called the S-please.
It's spelled W-E-S-P-R-E.
You can download this at the Ubleed Hacker for its main site, which is in the show notes, of course.
And my might as well tell you what it is, too, in case you don't get this at the show notes.
It's a Ubleed Hacker for us, all one word, dot deepgeek.us.
And again, what this is, is a command line program.
You type it in, and you specify arguments, title, album name, any tags that you want, anything like that,
the way before taking a screenshot or anything of that nature.
It also reads a configuration file for commonly used arguments, for username, and whatnot.
And that it uploads it to you.
It's really straightforward.
And if you have any problems with it, feel free to email me.
And if you can't get a working on your system for whatever reason, I will do my best to get it working on your system.
And if that involves you setting up an account in me, secure shell again, dear system, to get it to work.
Which is kind of fun. I did that on Cobra system.
It's a pretty underutilized aspect of a lot of Linux distributions.
Our Linux distributions generally is, you know, you have multi-users.
You have user accounts, but no one ever really uses more than two users, it seems.
And then they're unprivileged user.
Now, the second release is a, well, this is a pre-release, actually.
It's not software, it's actually a bit of hardware.
It's a little device with six buttons.
You plug in a computer through your USB port.
It looks like a USB keyboard to your computer.
And what this device does is it generates stores and types your passwords for you.
In addition to user names, it's kind of a quick interface.
It's sort of a corded sort of interface for you.
You don't need to traverse any sort of many or anything like that to use it.
So you can just hold on to buttons and all type out of user name.
Just hold on to some other buttons and all type out of password.
Now, the manual to this, you can find at the Overlead Hack First Main site.
You can also find a video of the prototype.
This isn't something that I will be producing probably for another couple of months.
I have to order a couple of controllers and start making art for the manufacturing board.
And then start to manufacture them.
But if you want a pre-order and help me out, you certainly may.
There's also a pre-order form there.
And hopefully this passy pass will be in your hands.
And maybe you can attach it to your keychain or something like that.
Tell me all about it and any suggestions that you have or anything like that.
The random number generator inside of it is a shooter random number generator
that itself isn't terribly complex or probably cryptographically secure.
It's a pretty good shooter random number generator I suppose for passwords.
The thing though is it's seeded by or it has a little fault to it from the seed.
From timing delays between key presses.
So it's probably not too susceptible to birthday attacks given that.
But then I'm no crypto analysis.
So I can't attest to the actual strength of the algorithm.
But you'll probably have no problems with it.
We can always replace the algorithm if you want.
Your passwords are stored in electronically erasable programmable read-only memory on the chip.
That's EEPROM.
And well, I hope to get this whole device out there because it's something that I need.
And it's probably something that you need too.
Now the next thing we're going to do on this episode of UberLeadHack for Forth Radio is talk to a friend command line.
This is a pre-recorded interview of sorts.
It's not really an interview.
You probably know a lot about him just from his podcast site.
I thought there wasn't a real B2 for me to interview him or anything like that.
It's more of a discussion on parallel computers, multi-threaded operating systems and computers as well.
Programming models and whatnot.
And quite the knowledgeable guy is kind of an interesting talking to him.
Like I would say a couple of things and he would go on for a while.
But I'd say a couple of things and he'd go on for a while.
It's very easy to interview.
More or less.
That's not simple little either of us by any means of course.
But before we get into that interview I'm going to play a bit of music for a musical break.
And I won't be returning.
So thank you for listening to this episode.
And I will see you next time.
You got a few things with so much work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
And that you'll share us with.
球球球球球球球球球球球球球.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
You got a lot of work.
Take a flashlight, now you know that this is the way.
Think it has a good team.
Think it makes a big mistake.
What's great, what's power?
It gets the better than this.
Take a flashlight, how's it going?
How many computers do you have right now?
The computer that you would consider maybe your best computer?
How many cores does this have?
It has eight.
When did you first buy a multi-core machine?
When did you first think of this?
When did you realize that did you have, was it exciting for you to realize that it's become common for processors to have multi-chores or when did you first do anything with parallel computers?
More generally.
It's always fascinating to me.
I remember when I was younger, when I was at a college, falling in with a bunch of network engineers at my first job that were really into scratch building your own PCs.
At that time, I was kind of like a holy grail, yet like a...
I want to say with the tie-in Tomcat motherboard that had two sockets.
It could do a standard footprint to do SMP to drop to CPUs and so it was always kind of the enough I had.
If I could get enough cash together, if I could find an operating system that would support it or other like drivers or whatnot.
I really wanted to do that.
It just seemed to make sense to me at that time that the OS could saturate one processor that would be another free to do whatever, you know, at that time it was probably like quite two, quite three, you know, really, really kind of graphic intensive gaming.
I had around the same time, I also remember playing around with not multi-core on the main boss, but with the SLI 3D graphics that build monster cards that you could actually pair together and I had a pair of those.
And some people had higher end graphics cards when we were doing LAN parties, but I remember being very proud of the fact that because I had two of those cross connected and so each essentially was rendering every other pixel line in each frame of the game we were playing that I was actually getting much better playing rates and a much smoother gaming experience.
And then, you know, I kind of is like those things got busier, the jobs got more demanding, started family kind of fell out of building my own systems.
So I think it was when the first SMT power PCG 5, the first max that had multiple processors and that started looking very attractive for, again, for very much the same reasons.
And then, you know, it doesn't hurt, you know, I will admit to these being partially in that tend, I have increasingly more cost for criticism, but there's still a little bit of softness in my heart towards their industrial design and some of their decisions, but the that line of processor.
So I still have the the power map G5, that was my studio where I got them so about a year and a half ago.
And then that got replaced with the eight call, which is a Mac Pro, so it's the two quad core processors, so it's multi core and SMT.
So it's kind of vegetables. So yeah, it's definitely something that that gets me excited in terms of, especially as I've gotten more into audio, realizing the benefit of being able to, again, do a lot.
More have a lot more processing power to bounce down audio, but still be able to pursue other tasks. So I put out for my podcast, I'm putting out more formats of having that many cores needs that I can be mixing down audio and I can be transcoding at the same time.
And it runs as smooth as if I'm just doing one or the other, there's no difference if I'm running in the same time.
And that's that's really appealing for saving time, because I want to focus much more in an instance where I'm taking full advantage of having all that parallel power.
I want to take advantage of that by maximizing the time I'm spending lighting up an episode or doing the work that's not as you do on video.
I've had a single core machines for quite some time. In fact, I still do have single core machines. So it's kind of, it's kind of an exotic sort of treat to be on any sort of system with multi cores.
My first experience of this was kind of similar to yours, I suppose. I had a couple of voodoo two cards, which you could look up together.
And it seemed like a fairly straightforward task to render every other scan line or have some sort of easy sort of division of computation for these two cards.
I don't know, like I haven't really experienced doing any audio editing or anything like that with a multi core machine. You say that this is fairly transparent. A lot of curiosity, what operating system are you running this on when you do your audio stuff?
For doing audio production work, I'm running OS 10 on the macro. I have also had the same system configured for a Linux for the day job.
I do some fairly heavy lifting web development and in that instance, I also find in both operating systems, I actually find the experience very seamless.
I do more of the low and level platform work for the applications at the day job, which means that I would deploy in a cluster environment.
So this is a, again, kind of another variation on parallel processing, but it spreads out parallel loads in the cost of multiple hashable servers.
If you get more scalability and servicing requests, because we also want to replicate the networking hardware, we don't want to have you downed it necessarily by a shared memory plus that kind of thing and having the ability also in a cluster environment.
So you can't do with a multi core system or an SMP system as you can't crack the box while it's running and add additional processors.
Whereas a cluster, while it's not directly comparable, except maybe conceptually, you can just end up in the node in the cluster and get more truth with that way, more processing power that way.
So to do development work and make sure that some of the things that I'm doing, it actually are affected by being deployed in that sort of environment, kind of low-balance or where requests might get imponged back and forth in those sharing in the database.
And if there's other means of sharing calls and information between nodes in the cluster, I do want a virtualization and that I do all on Linux.
And that's also apparently seeing what's right now I'm using virtual box, which is, I guess, Oracle owns it now.
Some picked it up a while ago, which is just a desktop system for virtualization.
But I've been looking at Zen or OKVM with some serious interest because it would seem to me that that, trying in more closely to the time loop of the HostOS, the event loop, the time loop that that would be even more efficient.
And again, like with the audio production work, there's nothing you need to do special to take advantage of that.
There might be some tweaking you can do to peg, you know, a particular hypervisor to a particular CPU, but so far, I haven't found the need for that.
The O.S. is that our multi-coreware, so an SMP cable Linux kernel or OS 10 being coupled very closely with the hardware design just seems to make that, as you say, very transparent, very easy to adjust.
I've run the apps that I want to run and know that I'm getting the full horsepower out of the hardware that I'm using.
It seems to me that we have sort of in processing power. There's no Moore's laws is dead, and it's not probably a very natural thing for us to expect any sort of exponential scale with anything.
But what strikes me as unusual is putting multi-core on a single die. Now, do you know, out of curiosity, do you know if this is using the same memory bus or is it using maybe multiple buses connected to some sort of memory controller?
Are these memories redundant in any way? Do you have like a couple of pairs where we have two bytes, two bits per byte, or per bit rather, or something like that?
It seems like we're not working around the bottleneck of memory, and processor speeds has increased so much, but memory essentially has stayed the same, and it strikes me as weird that it doesn't seem like we're working around this.
Do you know if we are working around this?
I think your characterization on the same die, I think that's correct. There may be some division on memory bus, but I think by and large, that's still very much a limiter, that on a four core, or even an eight core die that it's...
They have their own cache line, so there's some separation there, but...
Yeah, but from there on out, I think you're right. I think you're running the risk of running the intention, but I do know that when you get past that, so the Mac Pro is at that on a single die, that's true, but when you get to the eight core, they're not doing that eight core on a single die.
It's two CPUs still like the old PowerPCG 5s work, and I think at that point, there's a separate bus going into each set of cores, so it's not...
It seems like a bit of a compromise, and that might inform why at least Apple and their designs is still using S&P while other people aren't, is that they're maybe able to get a bit more memory performance work around those limitations that you're talking about.
Now, what sort of a multi-threading program do you do in your daily life?
As little as possible.
It can't be too much.
I had a co-worker who said, and I think this is actually not a bad word. He said it kind of tongue-in-cheek, but he gave him a packet of...
He said, if you're actually thinking about threads, if you're spawning a thread, you've done something wrong.
I mean, it runs up against, I think, that what we're talking about, that it's going to get inescapable at some point.
There's going to be a certain point where people have to know some way of getting at that concurrency, but right now, shredding is, in my experience, very difficult to get right.
It introduces an entirely new type of bug that I don't think a lot of people have experience with, sort of, the race-conditioned bug that is very hard to debug.
I don't know.
Even an indirect deathlock can be difficult to suss out sometimes.
Yeah.
The race-conditions are almost, they seem to defy determinism.
I think that's what makes them so hard to pin down, as it's not like you can sit down, except in the most trivial cases, and kind of work through the first principles, how you're going to get to.
It seems like you're relying on much more certain purses on that you're running, iteration after iteration after iteration is called Patterns, starts to emerge, or you're leveraging some sort of intuition about, well, I think this is what these threads are getting in contention important.
I think this is how this race-conditioned surviving.
To get back to your question, I work with Java.
I know there's a lot of critics of that, for my day job, that's what I do.
I've been exposed more, I think, than the typical Java developer, to the training facilities in that language, which they vary.
It's abstracted away, so on Linux, it may map directly to P threads, and on other systems, it may map to other lightweight processes or other ways of doing that at the OS level.
But that doesn't, that doesn't, that being said, even though it's a very high-level language in that sense, and then there's some, there's especially with the later versions of the language in the platform.
It's a really, really nice work out of us, we go, that doesn't need it to try to enhance some of the threading primitives to give us some pores and cyclic barriers, and some other ways to kind of get at concurrency other than just threads and locks.
It's dealing with atomic values, something that actually is very similar to what Grand Central is doing with OS 10 technology.
The thing open source says, like this batch, which is a way of just kind of chewing work into threads that are more closely associated to hardware and that instance.
Oh, really?
Yeah, yeah, there's comparable facilities in Java for that.
The one-five version of the development kit, the five other version of the language and four, or something very, very similar to that.
It makes it somewhat simpler, but you have to have a suggestion about how you're thinking.
And then, since you're not thinking about, I think it's more like the really big scale sort of parallelism that you get when you think about what Google's doing,
with cuttings kind of replicated and could be sort of map reduced, where you're just thinking about things as orthogonal tasks that you can fire into a tube and submit into the scheduler.
And then you're doing some coordination on the other side of that map.
That seems to alleviate some of those race conditions, but that still seems like a very awkward sort of idiom to get used to.
It's very different than what we used to thinking of with even the simplest threading scenarios.
I don't know if you have an experience with the vector instructions, but there are a lot of vector instructions for like MMX, for instance, or these things.
And I've come across two occasions where I had the pleasure of actually using them.
If that makes sense, it's a very orthogonal, and you have this data that gets processed symmetrically, and this data has no interaction with other bits of data.
I have four integers, for instance, that get multiplied, which is very nice if you're doing multimedia sort of things.
In practice, I have practically never used this, and it seems like we, to make use of the hardware, we have to change a lot of the methods that we use, the techniques that we use.
I'm kind of at a more fundamental level than I think we realize. I think a lot of times people, I think a lot of people want to develop a new language to fix things.
And perhaps in the future there will be this nice language that can do a lot of data flow analysis and figure out the perfect way to paralyze something.
There's some incremental steps along the way. I did a little bit of work with SIMD with MMX SSC2, SSC3, when I worked for an ONV startup that did some video compression stuff.
We were doing some pretty heavy lifting matrix math stuff. At this point, my math going into that wasn't very strong, and it was kind of stretched to the utmost.
So I'm a little sketchy that was years ago.
But even then, we got rather than kind of dig into how to make use of that, we looked into compilers that could do some of that optimization workforce that we would do a little bit to consider using those instructions that you're right.
SIMD is kind of one small step along the way that's more like leveraging a similar instruction across multiple registers.
In simplest terms, if you can break it up as you say, so that all of the inputs are kind of orthogonal.
And then you're doing something like the matrix math. You're processing a raise of data that makes sense. But I kind of have to be true. It's kind of like, okay, now what else am I doing that actually fits into that model?
And then you didn't even get into it. I don't have to be having a hard work capable of doing MIMD, doing that multiple instructions on multiple data.
I would say that I would almost say that GPUs are you can sort of consider this a MIMD type of architecture.
I mean, granted, you have to set up a program and it gets loaded into some hardware and then gets run. It's not very clean.
But you can have pretty much multiple data, multiple instructions. Mind you, the communication that is done between these programs is very, very little.
It's a pixel, a pixel value, say, and these things. But you're saying that we have not realized MIMD?
Well, you know, that's a good example. I didn't think about that. And I think you're right, but it reinforces that outside of certain domains.
And where are we saying? I mean, I guess there are projects that I've seen that I've written about, that I've talked about where people are finding.
And usually there are kinds of things that can be sort of pipeline, like some researchers, some hackers that are working with GPUs to speed up crypto breaks.
But that also seems to be the kind of thing where you've got, you know, doing password recovery, you're trying to recover, you know, the inputs into, you know, factorization or some TKI,
some TKI, some TKI, something like that, or even a symmetric algorithm, where you're just, you're using that more probability to kind of break off into smaller chunks and parallelize that then speed up the group force essentially.
So those both, I think, just kind of dry call them that point that we don't have, maybe as you're saying, kind of just that the mental tooling to say, how can I re-characterize more general problems to take advantage of that.
And then, and then I think you're right, that's sort of a piece when you get into multicore, which is just going to get worse. And the GPU you can at least look at as well, you know, as long as we have GPUs that are driven more by gaming,
then there's going to be a tighter marriage between what GPUs do and how they're programmed. And then as a, as a separate very rich field, that's one thing.
But I think you're onto something that, you know, there's like Doug Patterson and Grant Project that we've got a Berkeley, are looking at with FPGAs or simulating hundreds of thousands of cores and saying, okay, you know, what happens then?
You know, what happens to program again? How do we actually, at those tools, how do we approach utilizing this in a way that that's efficient and makes sense?
So they're simulating thousands of cores?
Yeah, I mean, I don't know that they're, that each core is particularly fast because it's on, it's on a programmable hardware.
Yeah.
But they're, they're trying simulation purposes.
Yeah, exactly, exactly. But they're, they're trying to address that, that question that you framed, which is, you know, how do we actually change how we think about programming so that we can get the most effect out of the scene?
How do we have to change the pilots? How do we have to change programming languages? And I do think we're seeing a little bit of that trickling out.
The, the biggest difference in, in Google's new language go from some of the other languages out there.
There seems to be that notion of concurrency collect built in as a part of that language semantic.
You have these concurrent blocks in it. And that seems to be a concession towards being able to, you know, rather than thinking in terms of threads.
And okay, I've got to feed work to the thread and look to thread life cycle and, and race conditions and obtaining locks or some of whores or, you know, all these other ways of coordinating threads.
They're, they're trying to, I guess, we that more to the fabric of the language itself from day one, even more so than some of the other multi-treadable languages that we've seen before.
How much experience do you have with, with go? You said that you made reference to some sort of block mechanism. What is this block mechanism? I have no experience with go whatsoever.
I just read through some of the, some of the documentation when it released just to kind of get to the bottom of a high plus because everybody was like,
you know, it's a new program, a program programming language from Google. It must be awesome. And it's like, well, maybe, you know, they, they have this immense playing trust, you know, that, that surf and buying curtain and Josh block and, and so on, it's on, it's on.
And, and this is one that that's come from some of the computer scientists that they, that they've employed over the years. And in looking at it, it's just as simple as it's, it's a language symbol, just concurrent.
So it's a modifier on, on a functional block, basically. And so you're, you're telling the compiler that that's something that can be parallelized.
And I haven't read it close enough to know what constraints there are on that block in terms of input handling and return values and the like, but it, it seems to be by a, a, a, a, front of my, send me an article recently saying that being the up tick on goes pretty good, that it's been solid.
So the height seems to at least been somewhat justified that that people are really kind of digging in. They've had a number of good releases over the past three or four months that it's been out.
So I'm not, I don't claim to have huge familiarity, but just doing some preliminary reading the materials that they put out there. They, they put some good language documentation out there and put some good sample code out there. So if you're curious, it doesn't seem like it's too hard to dig in.
And if you're, if you're comfortable and see, go doesn't seem too much different than that. It's not, it's not a complexity of, you know, that the whole new wrap is dynamic line, which is out there.
Ruby and Python and so forth. It's not even, I would say the complexity of like C++. It has interfaces, but it doesn't have the same kind of opportunity to go kind of hard while with piping like C++.
You don't really have generics. It's, I think it's, it's, as we put it, I think in the documentation, it's more of a system flying, which like C, it's intentionally simpler.
Yes, you can really do much lower level programming. And that, I guess maybe that, that's why the currency aspects of it makes sense.
Is that if you're building a presumably for my wife, who was using this program servers highly concurrent, highly scalable servers on no doubt multi core multi processor server hardware.
And so having that available to make these, you know, highly scalable, highly concurrent, highly parallel servers makes it a hell of a lot of sense.
At the end of the day, they were, their internal brain trust was just frustrated with trying to do that with P2S, trying to do that with other things. And I'm going to use Python for a lot of higher level programming.
I couldn't see them building, you know, the next, the engine acts or something like that and something like Python. So it seems like that. That was kind of their response to say, okay, we got to kind of go back to the drawing board and figure out how you can even build the systems to build the applications to keep scaling in and make sure that they're, you know, they're all about speed these days.
So make sense. Yeah, and that's very, that's actually very exciting. The idea of an operating system of some sort being built upon a parallel aware language.
The operating systems we have are very much not parallel aware at all. And everyone is sort of clamoring to properly implement these things with the Open BSD, for instance, by default, we don't even use hardware threads.
We just, we just have a user space thread kernel going, I mean, you can use curl threads if you want to, but this is not what's going on by default. The code isn't there yet.
And it's not as solid as everyone would like it to be. There are everyone seems to be using locks primarily in the Open BSD world to synchronize parallelization.
What do you think of architectures like the, what is it the P, the cell processor and these things?
That's, that was a hell of a hell of an architecture. I used to know a hell of a lot more about it. I actually met again at that, that R&D, we're looking at cell processor with considerable interest.
Exactly for the reasons that IBM and their partners were kind of pushing it, that it had a better distribution of some of the capabilities, better memory coordination, built it into the, into the single die, but it's been a while.
Also, my recollection on some of the particulars are fuzzy, but it was, I was kind of disappointed to see that it didn't, it really kind of didn't go anywhere, you know, outside of, there were a few notable applications, but it just didn't seem to get market traction and I want to say that yeah, some of that was just kind of the, you know, they did launch it with some programming tools, but just maybe not enough to make it as approachable.
But it, it, it, it seemed in some ways that memory serves kind of more GPU life in some regards, that you had ways to kind of do some of the coordination of data on the chip itself, which got us kind of excited in terms of, you know, you could, you get one point, you could be doing operations across the matrix of data, but then you could, you could shuffle that data around fairly effectively.
But I, I don't know that we ever got past kind of proposals stage, you're talking to, you went up to the IBM campus and arm up and work and we're in front of folks from Sony, Toshiba and IBM.
And there was kind of an interesting meeting in the minds, but we never actually got any hard work back into the lab at that point to really kind of pursue it.
Since you have a lot of promise, but it, it, it really also seemed to kind of, I guess, but it simply did to, to bring the issues around parallel wasn't really to, to a head that, you know, this was not, this was not a, a, a chip that you could undertake lightly.
You know, I mean, it was a very different animal. I mean, it's kind of interesting to see, you know, some of the other multi core designs and how they differ, how they, they, they've taken a kind of a different route, not been as aggressive.
And, you know, I mean, you have what the interline course on it back in the day and we still haven't quite caught up with that, but they, they had some other interesting hard work built into the die.
I wasn't just a multi core processor, which is kind of interesting. There were some things that that made the hairs in the back of my neck raised a little bit with that kind of touched upon trust with computing that you could lock down individual cells.
And, and you could have built a trusted pathway through the chip that I got a little, a little disturbing to be perfectly honest in terms of, you know, knowing who they were trying to pursue the markets.
So they were trying to pursue and who they were positioning that to, to, you know, try to say, by invocation, you can close out the analog hole, you know, you can, you know, prevent people from really doing what they want to do.
But, you know, I mean, that's, that's like anything. It's just because it's there. It doesn't mean that everybody used it.
So, yeah, it was, it was the impressive piece hardware.
So yeah, I'm going to, I'm going to begin to close this. I'm thinking of a, of a good word to close it.
Are you aware of, are you aware of what was at the, there's this 1980 super computer that was massively paralyzed?
It was a CMB 5, I think, or something like that. By thinking machines, this company called Thinking Machines, do you know anything of it?
Is that Danny Holtz's property?
I don't know. I have the image of the machine pretty clear in my head. It's this, it's this black sort of box that is separated into four boxes and they have a lot of red lights all over the place.
It's a ring of dowel at all.
That sounds vaguely familiar when you say Thinking Machines, that, that sounds vaguely familiar.
And yeah, that is, I think that, yeah, that's Danny Holtz's company. But I'm more familiar with the Hick Phillips' work in, in other areas.
I think he was doing stuff with AI.
That's what worked with her at MIT Applied Minds was, I think, yeah, something he co-founded.
So not, not as familiar with the hardware you're talking about. I think I probably have read about it just in passing reference in some of my reading on, on the machine intelligence.
That sort of parallel isn't that, that makes total sense for that application. And that's, that's a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, our own network is massively parallel.
So maybe we've built something that's parallel enough in Silicon, then we can start to reach a similar sort of cognitive, computational model to the goes on inside of our brain.
Do you have any experience with any hardware languages, a, their log, for instance, or any of these things?
No, not, not firsthand that, again, the, the R&D from my work for, we, we looked to, we were thinking about doing some implementation in Silicon, but we were going to contract that out.
So talking, talking with some folks that, that did, I don't know if they did a, their log or, or some other design language, but, but in that space that, that's what they were used to working for seemed like.
They made a lot of sense in terms of, they could get very much further in the process and keep kind of that in cost now, by being able to proof stuff out with those sorts of languages to be a, a lot more fruitful than just, you know, maybe before those languages were as developed, but I haven't done any myself.
That's an area that I'm a little weak on.
So there, there has been a little bit of effort to, to try and port C programs, for instance, into Verilog and these description languages, and this essentially is doing the best job at figuring out what can be paralyzed because the hardware description language is everything and running it once,
as it's hardware. And so the platform of having a bunch of gates in this gate array is seems promising because it's one where we can have any sort of parallelization that we can realize, we're not limited to figuring out how to, to run things on two cores and use their interconnect and how they access memory and, and these things.
Do you have any thoughts on this idea at all?
Yeah, there are a couple of stories that I, I remember reading a few years back that kind of take that, maybe to a logical conclusion or maybe at least to its next logical step where, that makes sense to me, the idea of bringing kind of optimization theory to program the design language itself.
That, that seems very appealing, but it seemed like there were some researchers working on hardware kind of the same vein of an FPGA, but even more so, that could be reprogrammed on the fly in a similar fashion.
But what, what's tickling my memory about that story is you saying, you know, the FPGA is pretty laborious, six programs, but actually doing kind of a dynamic of metaprogramming, so you're programming the program that actually alters the, the data way to do something different.
And that was, geez, that was, that was several years ago though, and that's, I'd have to dig back into the website archives to dig that out.
That, and that seemed very, very promising for the reasons that you mentioned in terms of, you know, rather than having to kind of bring through, have an engineer bring through what made the most sense to Silicon, actually having that sort of cooperation, building systems that could kind of augment and, and some model.
And, and get to maybe designs that would, would not occur too on or out.
Do you think there's a limit to how much we can paralyze? Is there a, will we see machines or thousands of processors, do you think?
I, I, yeah, I, I suspect that there are probably years of limit, but I don't know that we've gotten anywhere near it as it's yet.
And, and I remain open to kind of a, a, a Canadian paradigm shift where we make me find some other way, you know, if we've kind of dancing around that issue of, is the, is the limitation really the hardware or it's a limitation in the, in the engineers mind in terms of,
how the design of hardware for parallel was in the programmers mind in terms of how they take advantage of that.
And I, I don't know, I think the, I think the jury got on that. And, and that's definitely one of the reasons why I find that question so fascinated.
I'm always on the lookout for stories that kind of touch upon that like, as much as it turned out to be a little bit of a disappointed because it wasn't much meat to the story.
But I think the state probers that Microsoft was kind of talking about, yeah, we need to rethink parallelism.
And, and there wasn't a lot of meat to what he was saying, but they're, he's reminded that there are people out there who are thinking that that you don't need to be doing more.
We need to be pushing this front here more.
And, and I think that we're more on that end of things, more just trying to figure out what the space looks like before we can effectively talk about what it's.
And then, not to open enough, open up another radical to just peer down into, but I think that there's also a lot of commerce.
And quantum computers that would, which is an unintentionally different kind of parallelism, a very counter intuitive and odd sort of parallelism that best research is even 100% sure that this is going to pay off in terms of having a huge amount of values beyond classical computing.
But it's possible that, you know, like, so we've had clock speeds along with transit, they're going to be driving more law.
Now, the clock speeds are kind of plateaued, and we're still driving the transit.
They're transit, they're going to be in terms of how many cores are putting on a die.
So, we're going to have more laws still being served.
Maybe a point where the next kind of transition with that is, it'll be some other substrate from other physical style of computing.
So, we're using, that's been tronics.
We're using two bits and quantum registers and things of that nature, which are in terms of programming.
That's, that's even, I think that's even further out in terms of, you know, like the difference has been some research of Peter Schworn most notably.
Has had some good intuitions that we think is going to work in terms of just an algorithm, not alone, actual implementation.
So, I think there's a, I think it's a, it gets the short version of that, I think there's a long road.
If there's a limit, I'm off in this to kind of say it's a long way out.
And there may be other things that allow us to extend that road even further out.
Yeah, I would go so far as to say that we haven't quite, we haven't quite,
fully utilized the transistors that we have now, if that makes sense.
It seems like we're encountering the same problems over and over again.
And our implementations of them happen to consume more resources.
And the problems that we're doing aren't really fundamentally changing in any way.
And so that being said, new programming paradigm, a new hardware paradigm, such as quantum computers,
which as you said is very strange to program, we have sort of, ideally it could be an infinite sort of parallelism.
But practically it's, it's almost not programming, if that makes sense.
But it seems like I think we can make a lot more progress just in the realm of working on our algorithms and doing more with what we have.
I mean, I see kids today who, I mean, a Commodore 64 today, you can get for like $5.
Or is it the goodwill and think of the things that perhaps you had a different computer but think of the things that you've done with this Commodore 64 owner in a teenager.
This is nothing to the teenagers now.
They could have a lot of sort of power for learning computers in their hands for very, very cheap, because the Commodore 64 is incredibly cheap.
It's a, you can buy a burger from more than that, but that's being ignored.
And it seems like, I don't know, it seems like we haven't fully utilized what our hardware is now.
Would you, do you have any to expand on that or would you agree or disagree with this or what are your thoughts on that?
No, I definitely agree.
I think that there's definitely a lot of waste in the systems we're using that we're not, I think you touched them on something interesting there.
So it's not just the, are we saturating the transistors available because we're really tasking the hardware that we have, even the cheap hardware we have, but it seems like there might be.
And I started with this as a parent, a cognitive voice, but how do you, how do you really influence the generation that maybe is going to be the one that will make it into school?
Or they're, they're having on their own projects following their passions or ones who are going to crack some of the challenges that we've talked to that.
Or they're finding that new way of thinking, the new way of moving forward to really drive that parallels the parallelism, the point from the program or perspective where we are getting everything out of the.
So kind of he knows what kind of crazy stuff is going to happen on the other side of that.
I think that that, you know, if I've been applying, there's any sort of nearer term limit.
I don't, I don't think it's hardware.
I think it's in our approach absolutely.
And the more we can do to kind of get more minds on that.
So if that's, if that's coming up, the equivalent of a, you know, a first store, a $5 computer or maybe something a little bit more modern or that $5 computer just is a way to get somebody interested.
Then goes on to, you know, two core, four core, 16 core box.
And, and starts to move all out of the way that we were in the middle of the, or the home brew guys, you're not going to die.
They were in a video.
MIT hackers before them were bombing instructions.
And that the home brew guys, you know, exemplified by was where find a way to do more with less and really push, push, push.
So, you know, I would agree from that perspective and say maybe we need those kinds of challenges again.
We need to find a way to get people interested in really pushing this hardware.
It's amazing hardware that we have to that limit and see where, where it actually is.
I think you're right, I think you're right.
I think the embedded market, the, the, a lot of, we have a lot of these embedded machines and it seems like this has become more and more popular to have these smaller and smaller machines.
And, in the, in the context that you, you had just described, but I think that's very good.
It seems like we have a possibility to figure out how to accomplish something in limited hardware.
Or we're not thinking that our hardware will be unlimited, if that makes sense.
Typically these embedded machines, it seems to me run a lot of operating systems like Linux and things like that.
But it seems to be like an emerging, emerging market that, that is beneficial to sort of restricted programming and maximizing algorithmic efficiency.
And these things, what do you think about that?
I think that that might be that, you know, when we put it, we suggest that that actually makes me think about the, the maker move that, and a lot of the, the cool, the microcontroller programming people are doing, or yeah, our SDC based systems, whether it's robotics or multimedia applications, and maybe that might be the form that that kind of programming takes you right.
And there's something to create if you would constraint that seems to have that, that weird sort of counter-acquition.
If you have, you know, limited instruction tasks, cash, limited registers, you've got to strip down, Linux, kernel, and you've got something even less capable that an operating system, that it really challenges you to get creative in your solution.
And I guess that we're on the other side of that, if you're looking at that as a, and then have them to kind of incite the next line.
If you have to, if the people that are going to be looking at some of the problems that's been talking about is just, how do you scale that?
Because in my experience, like I work with a guy who is absolutely amazing at a better programming, but he was, he was clapped.
He put them on an actual desktop class system, and he was an absolute crack. He just, he could make that transition.
And then he would make really bad assumptions because he was so used to that limited environment.
So there, I think there is an inherent risk too.
So it's, I think there's got to be something in kind of the native talent of the embedded programmers that lets them kind of go beyond that.
And maybe it's a diversity of projects, and making sure that they're not just out of the local hacker space,
playing around with these single board systems and our community notice, but they're also doing some, something else, you know, on the unlocatable systems
so they can kind of see those corollaries.
If they can bring the experiences from each and to the other, maybe kind of a run-as-off program or the people.
Well, thank you for coming on the line.
From online, I appreciate it.
Thanks for having me.
Yeah, yeah. So I guess I'll see you around, and I'll keep on listening to your podcast. It's very good.
And you take care.
Thanks, you too.
Bye-bye.
Thank you for listening to the hacker public radio.
HPR is sponsored by Carol.net.
So head on over to C-A-R-O dot-N-C for all of her TV.
Thank you.