Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads? Easy? Become a patron for just five dollars
Speaker 1: a month. You get access to a private RSS feed
Speaker 1: where all the shows have no ads. Twenty dollars a month,
Speaker 1: we'll get you that and a special dot net Rocks
Speaker 1: patron mug. Sign up now at Patreon dot dot NetRocks
Speaker 1: dot com. Welcome back to dot net Rocks, the Internet
Speaker 1: audio talkshow for dot net developers. Remember that tagline rich.
Speaker 2: Yeah, because we're not clever enough to come up the
Speaker 2: word podcast, Well we.
Speaker 1: Were two years before that word could have thought of
Speaker 1: the word yeah. I'm Carl Franklin, and I'm Richard Campbell,
Speaker 1: Gary You and Park is here with us. We're gonna
Speaker 1: be talking to him in a minute. But first, Richard, Hello,
Speaker 1: where the heck are you?
Speaker 2: I am at build stuff in Vilnius, Lithuania.
Speaker 1: Wow.
Speaker 2: Yeah, cool? Last week I was in Brisbane, Australia, So
Speaker 2: I do not know what time it is?
Speaker 1: Your uh? Your wife doesn't like you hanging around the
Speaker 1: house too long, does she look?
Speaker 2: I'm good for about three weeks, right, and by somewhere
Speaker 2: else three weeks She's like, don't you have somewhere to
Speaker 2: go now. No, she was with me in Australia. We
Speaker 2: did a month in New Zealand, Australia with the new
Speaker 2: grand baby with a family.
Speaker 3: Yeah.
Speaker 2: Yeah, yeah. She went from seven months old to eight
Speaker 2: months old. We're on the road and when we left
Speaker 2: with her, she could just sit up and she had
Speaker 2: do a little teth in the bottom. There's cool. And
Speaker 2: by the end of the month she's got two up
Speaker 2: and down and she's starting to crawl and she's pulling
Speaker 2: herself to her feet. Like you forget how fast babies grow.
Speaker 2: It's done.
Speaker 1: My grand baby is two years old and she's actually
Speaker 1: visiting right now.
Speaker 2: Oh that's awesome.
Speaker 1: They came up for Thanksgiving weekend.
Speaker 2: I'm digging this grandparenting thing. Man, this is fun.
Speaker 1: Enough grandparent chit chat. Let's talk about what happened in
Speaker 1: nineteen eighty because this is episode nineteen eighty twenty more
Speaker 1: episodes and we've got we're now teenagers. Yes, that's right, thirteen,
Speaker 1: I think. Yeah, so let's talk about it. Okay, Well,
Speaker 1: this is the year that pac Man debuted. Yeah you
Speaker 1: know that. Yeah, and CNN was launched, ye, and that
Speaker 1: kind of changed everybody's worldview and made it seem like
Speaker 1: the world was more dangerous.
Speaker 2: Yeah, we could cave. Twenty four hour news, right, cable news. Yeah.
Speaker 1: No, matter where the bad stuff happens, you'll know about it.
Speaker 2: Yes.
Speaker 1: Thirteenth Winter Olympics were held in Lake Placid, New York.
Speaker 1: Oh right, yeah, starting February thirteen. Let's see US grane embargo.
Speaker 1: On January fourth, Jimmy Carter announced the grain embargo against
Speaker 1: the USSR. Of course, the Iran hostage crisis read its
Speaker 1: ugly head. Let's see, there was an new Mexico State
Speaker 1: penitentiary riot Mount Saint Helen's. Everybody remembers that we had
Speaker 1: ash all the way over here in Connecticut on our
Speaker 1: cars from Mount Saint Helen.
Speaker 2: Yeah, and we heard it up in Vancouver. It was
Speaker 2: this Sunday morning.
Speaker 1: And that's all I'm gonna say. Because we've been getting
Speaker 1: some negative feedback show we say about how long it
Speaker 1: takes to get to our actual show.
Speaker 2: So I'll wrap it up right here. Okay, but you
Speaker 2: can talk amazing. You didn't mention Lenin was killed in
Speaker 2: nineteen eighty though.
Speaker 1: You know what, that's right, he was killed in oh Man.
Speaker 1: That was a hard day.
Speaker 2: It was a bad day.
Speaker 1: That was a bad day. And we don't mean you
Speaker 1: know lenin the leader. I mean John Lennon, of course, briefly,
Speaker 1: what you got for science and tech and all that.
Speaker 2: On the space side, this is the year that Vorger
Speaker 2: one flies by Saturn, first time we get close up
Speaker 2: pictures of Saturn. This dose also well. The Russians are
Speaker 2: operating to Salute six space station in orbit and routinely
Speaker 2: supplying it and maintained it. This is the launch of
Speaker 2: the Solar Max satellite on Delta two rocket that immediately
Speaker 2: has attitude control failures after a couple of months of
Speaker 2: operations and will be repaired by this Space Shuttle challenger
Speaker 2: in a few years, because the Shuttle is well in development.
Speaker 2: In fact, Columbia has spent all of nineteen eighty in
Speaker 2: testing getting ready for its first flight in nineteen eighty one. Wow.
Speaker 2: On the computing side, this is the year that Jack
Speaker 2: Tramil unveils the VIC twenty, although it doesn't actually show
Speaker 2: up in the US until nineteen eighty one. In nineteen
Speaker 2: eighty it's released to Japan as the VIC one thousand
Speaker 2: and one with sixty five oh two processor five K
Speaker 2: of ram Because numbers are hard, although expandable to thirty
Speaker 2: two k and he also pays it was only about
Speaker 2: three hundred bucks. They sell two million of the things.
Speaker 2: It'll get replaced by the CC four course. But one
Speaker 2: of the key things he did is he got Scott
Speaker 2: Adams to port the Scott out of Adventures, five of
Speaker 2: them to the VIC twenty. Now with only five k RAM,
Speaker 2: there's no way to make those games running there, but
Speaker 2: the game would sload off a sixteen k ROM cartridge
Speaker 2: as you played it, so that the sworage was in
Speaker 2: the wrong cartridge. And they sell it makes one point
Speaker 2: five million just on those games. Wow. So and it
Speaker 2: comes to go very very quickly. Nineteen eighty also the
Speaker 2: year that Tim berners Lee builds a tool called Inquire,
Speaker 2: which is a network hypertext system. Hmmm yeah, okay, that'll
Speaker 2: never go anywhere, never go anywhere. Two more things. Seagate
Speaker 2: releases the ST five six, which is a five megabyte
Speaker 2: three and a half inch full height hard drive which
Speaker 2: I will make money from installing into the upcoming IBM
Speaker 2: PC which will be released next year. And this is
Speaker 2: also the year that a collaboration between deck Intel and
Speaker 2: Xerox comes up with the Ethernet Dix standard for ten
Speaker 2: megabit networking. Wow, this is at a time when every
Speaker 2: company had their own kind of networking, and so they
Speaker 2: try and create sentence on this, and so the I
Speaker 2: triple lee will start what do we know as the
Speaker 2: eight O two standard four lands. This is the beginning
Speaker 2: of all of that. And that's what I got.
Speaker 1: Awesome, awesome, awesome, all right, Well let's get going with
Speaker 1: better no framework, roll the music?
Speaker 2: Awesome? All right, man, what do you got?
Speaker 1: Okay? This is a tool called uni get ui, which
Speaker 1: was formerly win get ui, and the main goal of
Speaker 1: the project is created an intuitive guy for the most
Speaker 1: common CLI package managers for Windows ten and eleven, such
Speaker 1: as wind get Scoop, Chocolate, pip, NPM, dot Net tool, PowerShell, Gallery,
Speaker 1: and moore. Check out the package manager compatibility table. So
Speaker 1: they like to say that it's kind of like a
Speaker 1: package manager manager package manager.
Speaker 2: It's package manager inception.
Speaker 1: But I thought that would be good because you know,
Speaker 1: mister Chocolady is here and yeah, it's kind of and
Speaker 1: it's kind of trending on GitHub right now. So kids
Speaker 1: met cool.
Speaker 2: Yeah, who knew.
Speaker 1: I don't find a need for this myself, but you know.
Speaker 2: How many How often are you building machines?
Speaker 1: Well, that's true, but there's a little but you know,
Speaker 1: there's package managers for NPM and and all of that
Speaker 1: stuff as well PowerShell galleries. Yeah, it goes beyond just
Speaker 1: you know, chocolatey and Windows. Anyway, that's what I got.
Speaker 1: Who's talking to us today, Richard.
Speaker 2: Grabbing comment off show eighteen fifty nine when we did
Speaker 2: with one Gary, you and Park back in twenty twenty
Speaker 2: three talking about it. Oddly enough, chocolatey hey, and this
Speaker 2: common comes to us from Curtis who this is about
Speaker 2: a year ago, where he said, I'm maintaining most chocolate
Speaker 2: packages fairly easily. I spent about an hour a month
Speaker 2: managing patches that update the using the au tool, which
Speaker 2: is on the GitHub repository by Digital Coyote. The manual
Speaker 2: packages in that repo are is can really more time
Speaker 2: intensive though multipass, for instance cars booting up a Windows
Speaker 2: pro or enterprise system to build tests and deploy that package.
Speaker 2: On the note of using older dot net frameworks, it's
Speaker 2: one of the things we talked about back that show.
Speaker 2: I've seen time and again someone go into a new
Speaker 2: project to choose dot net four six two because quote
Speaker 2: it's stable, or quote we know it works. As recently
Speaker 2: as mid twenty twenty three, I see the same choices
Speaker 2: in new get packages as well, where a team will
Speaker 2: choose to stick with the deprecated version of a package
Speaker 2: because it's known to work. Upgraded projects to each LTS
Speaker 2: release since dot net core two point one without issues.
Speaker 2: That includes upgrading most dependencies on each release pretty through
Speaker 2: the release notes and weighing the risk benefit will almost
Speaker 2: always cause you to upgrade. The security fixes alone are
Speaker 2: usually worth any breaking changes in your app. Absolutely, that's
Speaker 2: good advice, Curtis. I'm not gonna argue a bit. Absolutely,
Speaker 2: you know it's worth getting moving on. And the new
Speaker 2: tools for actually checking compatibility guiding off four to six
Speaker 2: up to what it is now dot net ten, which
Speaker 2: is the latest LTS release, they're impressively good. They will
Speaker 2: not only tell you where you're gonna have problems, they
Speaker 2: will give you good instructions on what to do about it. Yep. So,
Speaker 2: with the exception of web forms and other obviously non ports,
Speaker 2: if you you a lot of apps apportable, even the
Speaker 2: wind forms from the win SDK really not really a
Speaker 2: breaking change anymore. They've done a pretty good job there,
Speaker 2: So Curtis, thank you so much your comment, and a
Speaker 2: copy of music cobuy is on its way to you.
Speaker 2: And if you'd like a copy of music, go buy.
Speaker 2: I write a cam on the website at dot net
Speaker 2: rocks dot com or on the facebooks. You publish every
Speaker 2: show there and if you comment there and I read
Speaker 2: in the show, will send you copy music Go buy.
Speaker 1: Music to Code by track twenty three is halfway done. Nice,
Speaker 1: so I expect that to be published within the next
Speaker 1: couple of weeks, maybe by Christmas, because why wouldn't you
Speaker 1: get your favorite friends music to code buy for That's
Speaker 1: a great idea. Yeah. And also you mentioned web forms,
Speaker 1: the thing that just didn't move over to core, right, yep,
Speaker 1: this is this is the main focus of my consultancy
Speaker 1: now is doing dot net core you know, Blazer versions
Speaker 1: of old web forms apps.
Speaker 2: Web forms apps. Yeah, I figured that'd be a path.
Speaker 1: Yeah, absolutely.
Speaker 2: And it's not that automatic either, is it like it's worked? No,
Speaker 2: you don't know, I mean, but it's good to do
Speaker 2: a rethink Jeff Fritz. Actually Fritz and friends had a
Speaker 2: library that had the same interfaces as the web forms things.
Speaker 2: But you end up with a lot of code that
Speaker 2: isn't modern and all that stuff. But yeah, yeah, the
Speaker 2: best thing to do is just start over use your
Speaker 2: business logic. Well, you have a template for what people want,
Speaker 2: you know that, but you also have a list of
Speaker 2: things that people are annoyed by. Yeah, so it's a
Speaker 2: great opportunity to rebuild and something makes them happier.
Speaker 1: Yep, Okay, let's introduce Gary and bring them back on
Speaker 1: the show. Gary Ewan Park has over ten years experience,
Speaker 1: probably more like twelve thirteen fifteen now right, working as
Speaker 1: a developer on technologies such as ASPNAT, Windows Forms, WPF, Sharepoints,
Speaker 1: silver Light, and many others. Throughout his career, Gary has
Speaker 1: always looked to see how things can be automated, using
Speaker 1: the mantra that if you do the same thing more
Speaker 1: than twice, it's time for automation. In twenty seventeen, he
Speaker 1: was awarded a Microsoft MVP in Developer Technologies, and in
Speaker 1: twenty twenty one he was awarded a getthub Star. His
Speaker 1: day job has him working for Chocolatey Software Incorporated. In
Speaker 1: his spare time, Gary contributes a number of open source projects,
Speaker 1: including Chocolatey box Starter, cake Cake contrib, get version and
Speaker 1: get release manager.
Speaker 2: So enough, there's a scene to those projects. There's scenes. Hmmm, yeah,
Speaker 2: there seems to be a theme there, Gary, that's weird.
Speaker 3: Yeah, it's a long sorted history that's put it out.
Speaker 1: Here, and we're funny, grateful.
Speaker 2: We just had Mattias on talking about Cake as well,
Speaker 2: you know, like it's these are things that are part
Speaker 2: of our lives. I don't even think about him anymore.
Speaker 2: You just did the way that you build machines, the
Speaker 2: way that you deploy applications, it's stuff you got to do, right.
Speaker 2: This is the plumbing of software.
Speaker 1: I first heard about Chocolate from Alan Stevens.
Speaker 2: Yeah, yeah, he was.
Speaker 1: He was gung ho on it. He was really ahead
Speaker 1: of his time in terms of, you know, embracing new
Speaker 1: technologies when it came out, and probably still is. I
Speaker 1: haven't talked to.
Speaker 2: Him in a while, but yeah, been Well, so what
Speaker 2: have you been working on?
Speaker 1: Friend?
Speaker 3: We continue to be busy over here, to be honest,
Speaker 3: I mean we are. We're obviously we're a small team Chocolate,
Speaker 3: but we have been increasing our numbers Chocolate, and the
Speaker 3: requests keep coming in in terms of what people are
Speaker 3: looking for, So we are we are definitely kept busy.
Speaker 3: Literally yesterday or yesterday, I'm into today. We've just shipped
Speaker 3: new versions of four of our core products. So wow, yeah, no,
Speaker 3: we're busy. We're absolutely making progress.
Speaker 1: Before you go on, we should probably define with chocolate
Speaker 1: as I know that everybody probably knows, but there might
Speaker 1: be a few people out there who are like, what,
Speaker 1: so chocolate is like new Get for Windows, right, if
Speaker 1: you think about it, that's way new Get chocolate.
Speaker 3: Yeah, no, absolutely, that's yeah, yep, that's where it started.
Speaker 3: I mean Rob Reynolds, the original creator of Chocolatey, was
Speaker 3: very much making use of new Get to manage his
Speaker 3: project dependency, so you can actually install the libraries that
Speaker 3: you need for under coding against. But what he found was,
Speaker 3: and this is the story he'll tell the story himself,
Speaker 3: but he would go to his a friend's machine or
Speaker 3: a colleagues machine to help him do a pairing session,
Speaker 3: and the tools that he wanted weren't on that machine.
Speaker 3: So he wanted a simple way to get the tools
Speaker 3: that he wanted onto that machine so that he could
Speaker 3: aid with painting sessions. And he was using new Get
Speaker 3: and he looked at them board and said, well, if
Speaker 3: I can use new get to install libraries, then maybe
Speaker 3: I can use new get to install applications. So he
Speaker 3: took he started a project which Chocolate as a package manager.
Speaker 3: Originally started as a PowerShell project, so it was written
Speaker 3: in PowerShell scripted and PowerShell. The sole focus was to
Speaker 3: use the new get client libraries to install applications. And
Speaker 3: then as the project progressed, it morphed into a dot
Speaker 3: Net application and c sharp and it's been that way
Speaker 3: for quite a while now, and it continues to be
Speaker 3: a mechanism for installing applications onto your machine in a simple,
Speaker 3: maintainable and repeatable way. So that's kind of the aim
Speaker 3: of what Chocolate is. It's a Windows package manager.
Speaker 2: Now there is a bunch of these. I mean, I
Speaker 2: don't put new Getting Chocolate in the same category, but
Speaker 2: I think wind get sits there certainly, Like how do
Speaker 2: you rationalize all of these? Geary?
Speaker 3: So what it comes down to, and I've spoken to
Speaker 3: a few people at different conferences and et cetera about this.
Speaker 3: It comes down to it. It's choice. It's what is
Speaker 3: it you want to what is it you want to use,
Speaker 3: and how do you want to use it? So people
Speaker 3: quite often hear people say, oh, the Windows doesn't have
Speaker 3: a package package package management ecosystem. You look at Linux
Speaker 3: where they've got four or five six different package managers
Speaker 3: for installing things. But on the Windows side of the house,
Speaker 3: where we're getting to a point where we have quite
Speaker 3: a selection now. So there's chocolate E, there's wind Get
Speaker 3: that you spoke about, there's scoop, there's other alternatives that
Speaker 3: you can use to install tools nowadays, and there's things
Speaker 3: like dot Net Global tools that the kind of that's
Speaker 3: kind of changed the landscape in terms of how you
Speaker 3: get tools into your Windows machine or into your cic
Speaker 3: D pipeline, so you can use dot Net tool install
Speaker 3: now as well. So that's list. There is a plethora
Speaker 3: of options in the Windows ecosystem now for doing application
Speaker 3: management and we Chocolate are one of those, and we're
Speaker 3: aiming to make the one the Windows installation ecosystem as
Speaker 3: simple as possible, because it literally is. When you start
Speaker 3: digging into the differences between ms I installers and n
Speaker 3: s I, n s I S installers and ex s's
Speaker 3: a there's a multitude of them. So what we Chocolate
Speaker 3: are trying to do is make that landscape easier to maintain.
Speaker 1: So you're mentioning some updates that you were that you're
Speaker 1: coming out with or having that with yep.
Speaker 3: So the team shipped new product versions of so chocolate
Speaker 3: as a product has Chocolate ECLI. That's the one that
Speaker 3: most people might know about. It's the open source version
Speaker 3: of chocolate and people can download install that freely. Even
Speaker 3: in a commercial ecosystem, you can use Chocolate Cli. But
Speaker 3: we've also got other products that the commercial offerings that
Speaker 3: build on top of the Chocolate Cli. So there's new
Speaker 3: releases to the Chocolate License Extension, a system that we
Speaker 3: call Chocolate Agent, and also the Chocolate Gouy License Extension.
Speaker 3: So there was updates to four of our coreate going
Speaker 3: out the door yesterday and today.
Speaker 1: Did you really just say chocolately and Guy in the
Speaker 1: same sense I did?
Speaker 3: I did. So Chocolate Gouey is our offering for using
Speaker 3: chocolate but through a graphical user interface to Guy.
Speaker 1: Similar to framework there correct.
Speaker 3: So similar to win get UI. So Chocolate Gouey offers
Speaker 3: support for trust the Chocolate package manager, whereas what wouldn't
Speaker 3: get Ui is attempting to solve is as you mentioned,
Speaker 3: is the package manager managers. You know, the UI version
Speaker 3: of the package manager manager. So you might remember there
Speaker 3: was a system called one get which was a PowerShell
Speaker 3: version of a package manager manager, so it was driven
Speaker 3: from the command line, and when UI kind of sits
Speaker 3: above that obviously but allows the management of multiple package
Speaker 3: managers on Windows. So actually, I've been in I've had
Speaker 3: a longgoing issue with the maintainer of will get UI
Speaker 3: to try and improve the traffic support and UNI get UI.
Speaker 3: So it's a it's a great offering and we've actually
Speaker 3: I've tried to have that conversation with him to improve
Speaker 3: that support. But yeah, it's been working well.
Speaker 1: So I wonder when it's going to be before we
Speaker 1: find package manager manager managers.
Speaker 3: It's good maybe hopefully, hopefully I will be happily retired
Speaker 3: before that, but before that comes about get to.
Speaker 2: The third order. This is exactly this.
Speaker 1: It's sort of the reflects the corporate order of things,
Speaker 1: doesn't it. Yeah, it's not a good thing. I think
Speaker 1: it's too much, too much. Can we all just get
Speaker 1: along really nice?
Speaker 2: Indeed, are you finding folks using chocolate for setting up
Speaker 2: vms in the cloud these days as well?
Speaker 3: Yeah, I mean that's definitely that's definitely a use case
Speaker 3: that we have heard of. Yes, there's it's the same
Speaker 3: with whether it's a physical machine, whether it's a VM,
Speaker 3: whether it's something else. There's always any to install the
Speaker 3: applications that you need. And obviously the first approach that
Speaker 3: you might use is to download it from the website,
Speaker 3: double click on a click, click a click through the installers.
Speaker 3: But it gets to the point where that's if you're
Speaker 3: doing that over and over and over again, you're you're
Speaker 3: looking for a way to automate that process and trying
Speaker 3: to take that try to make that entry point that
Speaker 3: bit easier by a single command to get all that
Speaker 3: applications installed. That's the niche that Chocolate is trying to serve. So,
Speaker 3: whether it's a physical device on your locally, whether it's
Speaker 3: in the cloud, that are mechanisms to install and use Chocolate.
Speaker 3: And then the natural progression of that is within a
Speaker 3: CICD pipeline as part of your build, you might need
Speaker 3: an application installed in order to perform the build. So
Speaker 3: whether it's a tool, whether it's something like get Version,
Speaker 3: whether it's something like get the lease Manager, you need
Speaker 3: that on the host agent in order to perform the build.
Speaker 3: If you look at the build agent that comes from
Speaker 3: Have Actions, Chocolate is already on the box. So if
Speaker 3: you need to perform an installation of an application as
Speaker 3: part of your build, you can just add a new
Speaker 3: step to your workflow, which is Choco install whatever the
Speaker 3: application is.
Speaker 2: Yeah. Sure, so I could see this from the from
Speaker 2: an ARM template point of view saying Okay, I need
Speaker 2: to stand up this particular instance of a VM. I
Speaker 2: want this SOS on it, and then once that's in place,
Speaker 2: now I go into a get have actions they poke
Speaker 2: to this, do your Choco installs start? To me, it's
Speaker 2: all about repeatability, right like that, So every time I
Speaker 2: call this that VM is exactly correct.
Speaker 3: So whether I say whether it's an ARM template or
Speaker 3: whether it's something else. Like even Cody and our team
Speaker 3: just now is looking to change our Packer builds to
Speaker 3: regenerate some based golden images that we use, So Chocolate
Speaker 3: is involved in that workflow as well. Packer defines what
Speaker 3: needs to be installed and we use chocolate to perform
Speaker 3: those actions. So that's definitely another mech and that we
Speaker 3: can go through.
Speaker 1: If you have an exc that you want to always
Speaker 1: install in your Windows machine that only has a gooey installer.
Speaker 1: In other words, there is now command line switches or
Speaker 1: anything like that. Is that throw a roadblock up for Chocolate?
Speaker 3: So yes and no, this is one of the what
Speaker 3: I mentioned before that the Windows installer landscape is vast.
Speaker 3: What you've described is just one of those. So the
Speaker 3: creator of that installer, that native installer, hasn't included the
Speaker 3: command line switches. So there is an immediate roadblock because essentially,
Speaker 3: what Chocolate is trying to do is it's trying to
Speaker 3: call out to just the ex to perform the installation.
Speaker 3: So if it can't toggle the command line switches, then
Speaker 3: there is a problem there. So what most package maintainers
Speaker 3: do in that scenario is they will introduce something like
Speaker 3: AutoIt or auto hockey. So they will have created an
Speaker 3: auto hockey script. So for those who don't know, hockey
Speaker 3: is essentially looking for triggers the Windows ecosystem. So whether
Speaker 3: it's a form opening or whether it's a button becoming visible,
Speaker 3: they will have created an auto hock key script that
Speaker 3: will then do the action of clicking the buttons on
Speaker 3: that native installer. So what the Chocolity package then looks
Speaker 3: like is the Chocolate package takes a dependency on auto hockey.
Speaker 3: So when Chocolatey comes along to install the first package,
Speaker 3: it needs to install the dependency, which is all Hockey.
Speaker 3: The script then says, run the auto hoockkey script and
Speaker 3: look for these Windows triggers, and then it performs the
Speaker 3: installation of your native installer. Auto hoot key kicks in,
Speaker 3: it clicks all the buttons, and then the application is
Speaker 3: then installed and the package is successfully installed after that.
Speaker 3: So there is a mechanism to do it. But where
Speaker 3: we get complaints source concerns is oh, where did this
Speaker 3: auto hoot key come from on my machine? So then
Speaker 3: we kind of have to explain that, Well, the native
Speaker 3: installer didn't handle a clean installation or a clean unattended installation,
Speaker 3: so you need to introduce something like a hockey to
Speaker 3: perform that operation.
Speaker 1: It reminds me of when we used to do this
Speaker 1: crazy show called Monday's and Mark Miller introduced his new
Speaker 1: invention which was called the installed buddy. Okay, so basic
Speaker 1: next next finished is in the days where everything was
Speaker 1: a Windows installation and it would just click next, next, next, next, next, next, next,
Speaker 1: finish for you installed buddy.
Speaker 2: It turns out it's a real thing. It's called auto
Speaker 2: hot key. That's funny.
Speaker 3: It is the system is there. I mean it's it's
Speaker 3: a viable solution for the underlying problem, which is the
Speaker 3: native installer didn't have those plan line switches to make
Speaker 3: it an unattended installation.
Speaker 2: I'm sure I imagine it's a little brittle if they've
Speaker 2: changed it install steps well absolutely, yeah, yeah, So.
Speaker 3: What we do so as part of the so for
Speaker 3: those who don't know, we have a Trotholate community repository,
Speaker 3: which is where we host all of the Tropolic packages
Speaker 3: that the community maintains. One of the things that we
Speaker 3: do as part of that is the moderation process is
Speaker 3: we will and the cloud will spin up a VM
Speaker 3: to perform the installation to ensure that it actually installs correctly.
Speaker 3: So if something were to change and the autohockey script
Speaker 3: stopped working, then package verifier existing, which is when we
Speaker 3: run through and check to make sure that things are
Speaker 3: still installing correctly. It might ultimately fail and send a
Speaker 3: message to the maintainer to say that there's a problem.
Speaker 3: Those processes in place to help with that.
Speaker 1: This might be a good application of some sort of
Speaker 1: AI thing that you know, can analyze the screen image
Speaker 1: of you know the installer and figure out and you
Speaker 1: can just tell it just you know, take select all
Speaker 1: the defaults and it would do that. I don't know,
Speaker 1: just thinking out loud, it'll be fifty bucks.
Speaker 2: Well, I keep thinking about like Microsoft has the form recognizer,
Speaker 2: we will take pay per forms and generate them into
Speaker 2: code for you. Like we're just not that far away
Speaker 2: from saying, hey, just look at this dialogue and figure
Speaker 2: out what should happen next. Yeah. Really, you really could
Speaker 2: deeply automate that. So of course, if they the better
Speaker 2: thing is just give us the command line yes please, yes, please. Yeah.
Speaker 3: I mean that's the for us from a package manager perspective,
Speaker 3: that's the ultimate, because then that is what is No
Speaker 3: one is repeatable, and it will continue to function the
Speaker 3: way that we expect it to unless that a breaking
Speaker 3: change in the installer or they switch installer technology, because
Speaker 3: that sometimes happens as well. An application might the underlying
Speaker 3: application doesn't change, but they might switch from a YSE
Speaker 3: installer to an MSI or something changes in the native installer.
Speaker 3: So that's where the package maintainer and the knowledge of
Speaker 3: what is possible, that's where the package maintainer's job really
Speaker 3: kicks in to help with keeping those packages install on
Speaker 3: correctly nice.
Speaker 1: Are there any other sort of gotcha's or roadblocks besides
Speaker 1: the the UI only installer that you guys deal with gracefully.
Speaker 3: So the one of the one of the hiccups that
Speaker 3: sometimes have happened from a package maintenance point of view,
Speaker 3: and it does cause problems for the package maintainers is
Speaker 3: knowing what those silent arguments are. So again it comes
Speaker 3: back to what is the underlying installer technology, because there
Speaker 3: is a standard set. If you like, it's if it's
Speaker 3: an MSI installer, these are the command line arguments, or
Speaker 3: if it's this install technology is these command line arguments
Speaker 3: or MSIs are actually sometimes better because they'll actually declare
Speaker 3: within their manifest file these are the available command line arguments,
Speaker 3: so you can pick which one you want to pass in.
Speaker 3: So when you first get started with package maint and
Speaker 3: then it's like, oh, I just want to install this thing,
Speaker 3: but then you kind of have to dig into that
Speaker 3: thing to understand how to manage it and how to
Speaker 3: install it. So one of the things that we do
Speaker 3: try to do and we provide this at the minute
Speaker 3: and one of some of the commercial offerings is we
Speaker 3: have a packaged builder, as we call it, so it
Speaker 3: will actually look at the underlying installer technology and make
Speaker 3: informed decisions about these are the sensible defaults for this
Speaker 3: application type. So it's one of the it's one of
Speaker 3: the features that we have been pushing within the team
Speaker 3: to if we can bring it down to some of
Speaker 3: the lower versions of Trocolate to make that package maintenance
Speaker 3: story a bit easier. Something we'd like to have for
Speaker 3: now that is a commercial only offering that we provide
Speaker 3: that sort of installer detection logic and helping with the
Speaker 3: provisioning of look packages.
Speaker 1: All right, go one more question before we take a
Speaker 1: break here, and that is you know, sometimes we're installing
Speaker 1: something and you need administrator approval, and so your whole
Speaker 1: screen goes away and you get this dialogue box that
Speaker 1: can't be automated. As far as I know, you have
Speaker 1: to click the yes I approve button. Do you get
Speaker 1: around on that by like just running the install scripts
Speaker 1: in admin mode for example? I don't even know if
Speaker 1: that is enough to get rid of that.
Speaker 3: From what you've described as one of the kind of
Speaker 3: the fundamental principles of how Chocolate operates. So I know
Speaker 3: that richer ops. That's going to go on when I
Speaker 3: start saying this, but I'm already quivering. Bear with me,
Speaker 3: doing a little bit right, Bear with me. So, Chocolate
Speaker 3: as a product by default does require to be installed
Speaker 3: by an administrator user, and it's installed to the c
Speaker 3: program data folder with those administrative permissions, and as a result,
Speaker 3: Chocolate Chocolate ex when it runs, needs to be running
Speaker 3: as administrator because at the end of the day, most applications,
Speaker 3: the most at least a significant proportion of the applications
Speaker 3: that you want to install need administrator rights because they
Speaker 3: might be installing to see program files folder, they might
Speaker 3: be adding registry entries, they might be lots of stuff
Speaker 3: that require admin permission. So way back when the decision
Speaker 3: was made that chocolate as a product would require administrator
Speaker 3: rights to run, and we have continued with that. Now
Speaker 3: to answer your next question that might flow on to
Speaker 3: that as well, how can I get other people within
Speaker 3: my organization that don't have administrator rights to perform package installations.
Speaker 3: That's where some of our other products, the likes of
Speaker 3: background Service kicks in. So that's a mechanism where we
Speaker 3: allow for a non administrator user to essentially request the
Speaker 3: installation of a package, and that package installation is performed
Speaker 3: by the background service that has those administrator rights. So
Speaker 3: you're getting almost like a self service scenario where you
Speaker 3: can say as a company, as an organization, I want
Speaker 3: to allow the installation of these packages. But then as
Speaker 3: a user, I can say, well, I want that one
Speaker 3: and I want that one, and I'll self provision those,
Speaker 3: so you kind of get the best of both worlds.
Speaker 3: But yes, it's an age old problem. And the decision
Speaker 3: that we chocolately made was that we would require administrator
Speaker 3: rights by default now.
Speaker 1: So when you run under administrator rights, you don't get those.
Speaker 3: Dialogue normal no no, no correct. So you're you're you're
Speaker 3: circumventing is the wrong word, but you're certainly side stepping
Speaker 3: the need for the those ucps because you're escalated.
Speaker 2: Exactly.
Speaker 3: Okay, good, Now that has its own problems, and that's
Speaker 3: kind of why I preempted the ops hack going on,
Speaker 3: because then you're got administrator right, so malicious actors could
Speaker 3: take advantage of.
Speaker 1: That, exactly.
Speaker 3: So that's there's all sorts of that we get into
Speaker 3: within the team, within the organization, we get we have
Speaker 3: lots of conversations along those lines as to whether this
Speaker 3: is security vulnerabilities, et cetera. So all sorts of conversations
Speaker 3: have along that.
Speaker 1: Well, we're gonna we're going to have that conversation after
Speaker 1: the break carry so we'll be right back after these
Speaker 1: very important messages stick around. Do you have a complex
Speaker 1: dot net monolith you'd like to refactor to a micro
Speaker 1: services architecture? The micro Service Extractor for dot Net tool
Speaker 1: visualizes your app and helps progressively extract code into micro services.
Speaker 1: Learn more at aws dot Amazon dot com, slash Modernize.
Speaker 2: And we're back. It's dot net Rocks. Amerger Campbell, Thatt's
Speaker 2: Carl Franklin. You talking to our friend Gary and Park
Speaker 2: a bit about the latest on the chocolatey side of things,
Speaker 2: you know, I mean, you know, I'm the run ass
Speaker 2: guy as well, and we certainly talk about install hacks
Speaker 2: like there is.
Speaker 1: Like run as yeah there.
Speaker 2: Well, there are exploiters that are smart enough now that
Speaker 2: they managed to get into a machine, recognize it, don't
Speaker 2: leave it a process running that's waiting for escalated privileges
Speaker 2: to intercept. But there's only so much you can do.
Speaker 2: I mean, the reality here is we don't want users
Speaker 2: to be able to install software. So you need to
Speaker 2: ask privileges to install software. And where you're talking in
Speaker 2: an enterprise environment. And as much as we talk about
Speaker 2: granulating privileges for all of that, I know no one
Speaker 2: I've ever spoken to that's done a large scale package deployment,
Speaker 2: so multiple apps and so forth, installing where the privileges
Speaker 2: are actually varying from install to install. They just go
Speaker 2: super user push everything in, go out like it's just
Speaker 2: not practical.
Speaker 1: And yeah, I think also the security risk come more
Speaker 1: from people than they do from the software. I mean,
Speaker 1: if you've got a good software bill materials and you
Speaker 1: trust the software that you're installing goes without saying, then
Speaker 1: the person the admin who writes the script is probably
Speaker 1: going to be the one that runs it. So it's
Speaker 1: not like somebody's gonna somebody like Patrick Kins to say,
Speaker 1: if somebody just offered you a piece of food on
Speaker 1: the street, here eat this, You're not going to eat it,
Speaker 1: you know. Yeah, So if somebody says, here, run this script,
Speaker 1: you'd be a little you should be a little apprehensive
Speaker 1: about it until you check it out well.
Speaker 2: And more importantly, that's why we don't give you the
Speaker 2: privileges so that you'll have to ask us about it.
Speaker 2: We'll say, where did you get that from?
Speaker 1: Exactly?
Speaker 3: So exactly purely from a chocolatey point of view and
Speaker 3: a chocolate ecosystem point of view, the default place to
Speaker 3: get those packages that Carl's talking about there is the
Speaker 3: chocolate community repository. So the problem that we have there
Speaker 3: is that anyone can push to the chocolate community apositry,
Speaker 3: so there is the potential for there being bad actors
Speaker 3: in that space. Now we do what we can in
Speaker 3: terms of moderating those packages and shooting a good package quality,
Speaker 3: but ultimately there's no guarantee and we don't provide any
Speaker 3: guarantee that there won't be something nefarious on that website.
Speaker 3: But that's why we recommend due diligence in terms of
Speaker 3: again that what you said, you wouldn't run any scripts
Speaker 3: from the internet, you wouldn't install any package from the
Speaker 3: internet either. There are a due diligence aspect to that.
Speaker 1: Well, so it depends on the package, right, I mean,
Speaker 1: if it's version one point oh oh oh of some
Speaker 1: new thing and nobody's installed it before, I wouldn't install it.
Speaker 1: You know, you want to wait for there's definitely.
Speaker 2: Two.
Speaker 3: Yeah, no, absolutely absolutely.
Speaker 1: Package is mature and it's been vetted by the community.
Speaker 3: That's true too, yeah, absolutely. But where we're going to
Speaker 3: go with that is that, in an organizational point of view,
Speaker 3: we don't recommend the usage of the Chocolate community of
Speaker 3: positry because it's not something that you as a company
Speaker 3: would want to make use of. So what we recommend
Speaker 3: instead is you take the packages that you vetted and
Speaker 3: you put them into your own internal repository, and that's
Speaker 3: where you get to your what you describe their car,
Speaker 3: which was someone's done all the vetting, someone's done all
Speaker 3: the package installations to make sure that they're valid, and
Speaker 3: then you offer them up to the internal organization to say,
Speaker 3: have your pick of these ones. But they don't get
Speaker 3: to use the community depository.
Speaker 2: And this is the commercial version of Chocolate, right, that's
Speaker 2: the central management tool and install our controls and all
Speaker 2: those sorts of things. So for me as an oh, really,
Speaker 2: that's exactly.
Speaker 3: Well, there was a slight clarification there. So the repository
Speaker 3: itself so which is not to be confused with a
Speaker 3: GitHub repository and one FNTO, here is a repository of
Speaker 3: packages that's not something that we chocolately offer. So we
Speaker 3: would look to something like a progate or an Nexus
Speaker 3: or an arch factory to provide the actual.
Speaker 2: The actual package.
Speaker 3: Okay, so those are stored there, and what you're refering
Speaker 3: to there is the Chocolate Central management. It would build
Speaker 3: on top of that to allow the deployment of packages
Speaker 3: to across your suite of computers. But we we at
Speaker 3: a minute, don't offer a repository solution for packages.
Speaker 2: That's not something. And you also get to the other aspect,
Speaker 2: which is rarely as an administrator of infrastructure, and do
Speaker 2: I actually want the latest version of anything? Right? We
Speaker 2: have an accepted set of versions of Adobe Reader, and
Speaker 2: those are the ones we're going to install. I don't
Speaker 2: care if there's new one coming out until it's gone
Speaker 2: through the process. It's not in the package.
Speaker 1: I think the problem is you've chosen Adobe Reader. Yeah,
Speaker 1: well fair, real problem.
Speaker 2: Yeah, but you know the the when when you get
Speaker 2: to hundreds of thousands of seeds, you're trying to manage
Speaker 2: the total landscape of different versions of things. Yeah, sure,
Speaker 2: and so you get a little more strict and this
Speaker 2: is the stuff you pay for and why you get
Speaker 2: paid to do your job. So privileges are one thing,
Speaker 2: but known versions of another. Because this whole conversation about
Speaker 2: supply chain attack like this is only getting worse.
Speaker 1: It's serious.
Speaker 2: Yeah, and they're definitely besieging open source.
Speaker 3: So on that note that the flip side of that
Speaker 3: is that there are thads out there that do want
Speaker 3: the latest and greatest. And what happened the other month
Speaker 3: was last month when dot Net shipped one of our
Speaker 3: one of our core community maintainers, Jacob, he went about
Speaker 3: and set about set created packages for all the new
Speaker 3: dot Net packages. So whether that's the desktop version, the
Speaker 3: runtime version, the SDK, he flooded us. He literally flooded
Speaker 3: us with the dot Net related packages on the community pository.
Speaker 3: So it's great because we then have all the dot
Speaker 3: Net ten packages that people can then install. But that's
Speaker 3: him literally being on the bleeding edge. It was it
Speaker 3: was announced and he had packages ready to go and
Speaker 3: ship to the community positors.
Speaker 1: And he said, I'm done then, you know.
Speaker 3: So the great thing about the open source is that
Speaker 3: the option there and then is that someone could pick
Speaker 3: those packages up. So all the work that Jacob does,
Speaker 3: it's all on a gihub repository, all of his packaging scripts,
Speaker 3: all of his automation to create those packages and keep
Speaker 3: those packages up today, that's all on GitHub. So if
Speaker 3: Jacob were to step away, and we've had people step
Speaker 3: away from the community, that's absolutely something that happens. But
Speaker 3: what we find is that there's always people that come
Speaker 3: along and I say I'm interested in maintaining that package
Speaker 3: and ultimately gets picked up. So Jacob would be sorely missed,
Speaker 3: let's put it that way, if he were to step
Speaker 3: away from the community. But for the he's been involved
Speaker 3: in the all of the dominant packages since I can't
Speaker 3: even remember when he started, and he's probably been around
Speaker 3: as long as I have to be honest because his
Speaker 3: name is so familiar.
Speaker 1: So go Jacob.
Speaker 3: Absolutely, absolutely, I'm not going to try and pronounce the
Speaker 3: second name because it's not one that's in my remit,
Speaker 3: I don't think. But he goes by Jacob, so that's well,
Speaker 3: I'll stick with.
Speaker 1: Somebody should send him a pizza.
Speaker 2: What are your thoughts on the whole supply chain attack
Speaker 2: landscape these days? Like do you do you give advice
Speaker 2: to to developers that are using these tools on? Like
Speaker 2: what do I got to think about to make sure
Speaker 2: I'm not a part of a supply chain attack.
Speaker 3: I mean, it's definitely, it is definitely an issue. Is
Speaker 3: prevalent with an hour, with an hour and ecosystem. It's
Speaker 3: something we need to be conscious of. And if you
Speaker 3: are using package management solutions like Chocolate or whether it's
Speaker 3: something else, just installing the latest and greatest is probably
Speaker 3: not the best advice. It would be maybe I'd carl
Speaker 3: kind of hinto that with the first version of that application,
Speaker 3: Maybe wait that thirty days or something to see whether
Speaker 3: there's bugs, see whether there's anything with this.
Speaker 2: Is the ITAM mentality. Change is good. You go first,
Speaker 2: you go exactly exactly.
Speaker 3: A great way of putting it. So it just just
Speaker 3: to be sensible, to be honest. I mean, there's what
Speaker 3: we offer on the community pository is any package that's
Speaker 3: pushed to the CCR of the Trocolate Community postry, we
Speaker 3: send all the related files and packages over divirus total
Speaker 3: to let them scan it as well, and we report
Speaker 3: that information on virus Total. So if there were something
Speaker 3: that comes through, then that information is available on the
Speaker 3: package page, so you'll be able to see that there's
Speaker 3: a there's maybe a higher rate of virus detections for
Speaker 3: this package version, and it might give you pause to
Speaker 3: think about what that's maybe not a good idea, or
Speaker 3: it gives you more pause to take it onto some
Speaker 3: sort of DMZ within your organization, install it there without
Speaker 3: letting it, letting it across your organization. There's mechanisms that
Speaker 3: you can use to prevent those potential supply chain attacks.
Speaker 3: But at the end of the day, I mean, it's
Speaker 3: it is. It's something that we all have to be
Speaker 3: conscious of because there's there are malicious actors out there
Speaker 3: that we need to be careful of. It's unfortunately as
Speaker 3: part of the world that we've lived in today.
Speaker 2: Well and these recently just the past couple of years,
Speaker 2: we've found now long term maintainers that may have been
Speaker 2: plants the whole time thence quiet, you know, getting that
Speaker 2: maintainer of privilege that they could approve their own prs
Speaker 2: and adding really like crazy sneaky things like the xz
Speaker 2: util ones comes to mind, where literally, you know, this
Speaker 2: is a utility for data compression that and numerous numerous people,
Speaker 2: millions of people use, and this longtime maintainer slipped in
Speaker 2: this bit of code that was sending telemetry of everything
Speaker 2: being compressed to China. And the only reason it was
Speaker 2: detected is that there was a Microsoft guy was his
Speaker 2: name Andres who was doing performance testing version of version
Speaker 2: and the new version was five hundred milliseconds slower, and
Speaker 2: so he dug in like what made this slower? And
Speaker 2: I covered this whole thing like it's quite a story.
Speaker 2: Thank goodness, people like this exists. But it also speaks
Speaker 2: to part of our instrumentation on updated versions. It really
Speaker 2: is looking at the subtle changes.
Speaker 1: I kind of think automation is a good place for
Speaker 1: these kinds of things to look like. GitHub has depend
Speaker 1: abot right, and I don't know how much of it
Speaker 1: is automated, but it seems like it is. And you know,
Speaker 1: to do automated testing of things like this, Richard that
Speaker 1: you know that this guy had a human had to
Speaker 1: find that based on some timing. But some of these
Speaker 1: things could be automated. I think maybe in the future
Speaker 1: they will be more.
Speaker 2: Yeah, and I wonder this is what's againing well. Llm's
Speaker 2: working for us right, not being part of the problem
Speaker 2: where they to be able to assess the risk of
Speaker 2: data changes and maybe raise a red flag because ultimately
Speaker 2: that a self approved PR bad like giant red flag
Speaker 2: right away. But okay, so you have two people involved,
Speaker 2: but just having very detailed assessments of what's early in
Speaker 2: that PR and what and what its potential risk is.
Speaker 2: Like I wonder if we aren't already maturing and I
Speaker 2: don't have evidence, but I'll look for it. That we
Speaker 2: are starting to build lms. Who's specially who are going
Speaker 2: to be And I shouldn't say who because it's software
Speaker 2: that analyzed security risk on co changes constantly.
Speaker 1: Well you mean you already have you know, things like
Speaker 1: gethub copilot.
Speaker 2: Yeah, well it depends on what we'll catch like keys
Speaker 2: in code.
Speaker 1: Yeah yes, but it isn't going to test right. But
Speaker 1: you know the thing about gethub copilot is you tell
Speaker 1: it to do something, it just goes off and does it.
Speaker 1: Or the get ub Copilot code Assistant I think it's called,
Speaker 1: so you know, there could be back background process he's
Speaker 1: running and get hub per se I mean not just there,
Speaker 1: but anywhere where something new is checked in. I mean
Speaker 1: it's just another pipeline really if you think about it.
Speaker 2: Something that you know the same way that used to
Speaker 2: be so fixated on performance at SLA testing for a
Speaker 2: lot of software where it's like, is this still going
Speaker 2: to comply with the SLA or the performance levels that
Speaker 2: we agreed to, you know now, and I'm thinking back
Speaker 2: of the day where we were talking about just needing
Speaker 2: provision new hardware because we were running our own rigs. Right,
Speaker 2: it's like, hey, we added. The classic one was when
Speaker 2: we added the recommendation engine and brought the whole place
Speaker 2: of it's knees because it was so much more computationally
Speaker 2: intensive and so we fortunately we ab switched it, figured
Speaker 2: out how much more it was, and then like did
Speaker 2: the math and said, we have to buy this many
Speaker 2: more computers if we're going to be able to run
Speaker 2: this thing. You know, So those kinds of benchmarking, the
Speaker 2: fact that we're going to benchmark it to see was
Speaker 2: malicious code added, Like wow, this is the world we're
Speaker 2: living in now. It's really you know, package management ain't
Speaker 2: what it used to be. You've been doing this longer
Speaker 2: than anybody, Gary, Like, obviously the demands only get bigger.
Speaker 2: I mean, is it getting better?
Speaker 3: I mean it's definitely as we continue to see more
Speaker 3: people using it and we continue to see more packages
Speaker 3: being pushed to the repostentry that we maintained. So it
Speaker 3: is always, it's always that all of the graphs that
Speaker 3: we have and that we maintain, more people are wanting
Speaker 3: it and more people are using it. Right, But I mean,
Speaker 3: I go back to where I started. I set up
Speaker 3: and in this game quite a long time now, But
Speaker 3: when I started, it was just literally I want a
Speaker 3: quick way of installing this thing, but it's now morphed
Speaker 3: into I want to bring up a whole suite of
Speaker 3: computers that all have different applications on them, or a
Speaker 3: whole different different applications on them to test these different
Speaker 3: scenarios as part of my CICD pipeline. So whereas before
Speaker 3: we would have been constrained to here's one build agent
Speaker 3: that's got all the stuff on it that is maintained
Speaker 3: in secrecy by the whole ops team, now transferred all
Speaker 3: of that over to vms running in the cloud that
Speaker 3: you can spin up on a whim, but you still
Speaker 3: need to do the application management over it. And that's
Speaker 3: where something like chocolate comes in. So it's it's a
Speaker 3: never changing landscape, but it's one that continues to need
Speaker 3: solutions like chocolate. So it's it's a very interesting space
Speaker 3: to be involved in.
Speaker 1: Yeah, I bet never a dull moment.
Speaker 3: I bet never a dull moment.
Speaker 2: Yes, But you said pack. I think about how much
Speaker 2: more complicated CICD pipelines are these days, and this package
Speaker 2: management pipeline, including the feed in of new versions is
Speaker 2: going to be at least as complicated now. Absolutely, it's
Speaker 2: all part of the equation and it's.
Speaker 3: It's it's the landscape is ever increasing as you start
Speaker 3: talking in the likes of ARM. ARM is now a
Speaker 3: thing that people want to build on, and file for
Speaker 3: and package for. So that's one of the conversations that
Speaker 3: we're having internally is well, what is how does chocolate
Speaker 3: fit into that ARM landscape and what do we need
Speaker 3: to do to perform it because chocolate chocolate ex Today
Speaker 3: runs under the emulation layer with on ARM, Right, but
Speaker 3: do we want or do we need? Do you want
Speaker 3: a native version of chocolate ex The answer to that
Speaker 3: is probably yes, but then eventually eventually that but then
Speaker 3: that causes our bills then need to change because we
Speaker 3: need to introduce having the ARM hardware to then build on,
Speaker 3: compile on, test on, package on. So it increases our
Speaker 3: landscape of what we need to do in order to
Speaker 3: provide that increase landscape for the customer.
Speaker 2: It's my experience with the Snapdragons, the Snapdragon ultras is
Speaker 2: the emulator is very fast, and you'd be very happy
Speaker 2: with that until you just see you see how much
Speaker 2: faster it is running native correct, and the emulated version
Speaker 2: was not bad until you saw the native version went wow,
Speaker 2: I want that more of that.
Speaker 3: It's just and also some of the some of the
Speaker 3: APIs they get lied to because of the emulation layer.
Speaker 3: So where we would say what are you running on,
Speaker 3: it will go well, I'm running on this, when actually
Speaker 3: it's running on this completely separate things. So there's different
Speaker 3: APIs that we need to call into for certain things
Speaker 3: to get some of that information out. So the landscape
Speaker 3: changes ever so slightly. But you if you're using the
Speaker 3: emulation layer, but if you're running natively, that's those problems
Speaker 3: no longer exist.
Speaker 2: And you guys don't tend to poke into ring zero
Speaker 2: for any reason.
Speaker 3: You know, no, No, that's not no.
Speaker 2: That's and that's where the real WAMI comes for arm
Speaker 2: is that all of that architecture is fundamentally different. Yeah,
Speaker 2: as long as you're staying in the user layer. The
Speaker 2: user layer lies to you really efficiently.
Speaker 3: Yes, So that's something that we're definitely looking at. It's
Speaker 3: the conversations are being had about what we need to
Speaker 3: do and what we need to do, because right now,
Speaker 3: for Chocolate, we will say the helper scripts that we
Speaker 3: have will say give me the thirty two bit installer
Speaker 3: or give me the sixty four bit installer, and then
Speaker 3: Chocolate does the right thing based on where it's running.
Speaker 3: But then we would need to extend that to have
Speaker 3: well are you on ARM and then is it ARM
Speaker 3: thirty two? Is ARM clutter two still a thing? Is
Speaker 3: it ARM sixty four? Yeah, there's all these questions here.
Speaker 2: When it's only ARMS sixty four, like just one last thing,
Speaker 2: it's pretty hard. Thirty two is pretty much over.
Speaker 3: That's it. So but I say those questions are those
Speaker 3: questions are being asked. Those we're trying to provide answers.
Speaker 3: So that that I said, that landscape is ever changing
Speaker 3: and we're trying to But I mean there's the other
Speaker 3: parts of it from a development perspective. We had this
Speaker 3: conversation last time where we've literally just done the switch
Speaker 3: from dot net four up to dot net four point
Speaker 3: eight we're in a similar chasm now where we're at
Speaker 3: four point eight, but we want to jump to dot net,
Speaker 3: to actual dot net. So there's conversations around what we
Speaker 3: do there, what do we do again? Our builds need
Speaker 3: to change, our testing needs to change. So there's it's
Speaker 3: a never ending sea of things that need to be
Speaker 3: thought about in conversations.
Speaker 1: All right, you're gonna love this question, Gary, what is
Speaker 1: the wackiest tech support ticket you ever saw?
Speaker 2: For chocolate?
Speaker 3: So so the one that comes to mind is one
Speaker 3: that I briefly spoke about and our last meeting, but
Speaker 3: it was we had a customer who the customer that
Speaker 3: was running CCM and CCM at the time. It does
Speaker 3: a thing where we do deployment and it installed on
Speaker 3: the computer that you're running on. So this customer happened
Speaker 3: to be running on Windows Server twenty twelve, and the
Speaker 3: deployment would work the first time, and then if you
Speaker 3: ran it again it would fail. So there was it was.
Speaker 3: It was in explosive. It would always just work. So
Speaker 3: in our testing it always just worked. We were testing
Speaker 3: on not Windows Server twenty twelve. So it turns out
Speaker 3: that there was a problem with the SMA assembly the
Speaker 3: PowerShell SMA assembly had a bug, and the first deployment
Speaker 3: it worked just fine, and the second deployment, I think
Speaker 3: it was an internal array that had been set and
Speaker 3: therefore it didn't work the same way that it worked before. Literally,
Speaker 3: after literally debugging or decompiling the SMA assembly and looking
Speaker 3: at the generated code, I figured it out, found a
Speaker 3: way to reset the array on each deployment, and I
Speaker 3: was able to fix it for that customer. But that's
Speaker 3: That's one of the the fundamentals of Chocolate is that
Speaker 3: we try to be backwards compatible, but that end the
Speaker 3: end result of that is we end up with customers
Speaker 3: running on older operating systems that we're trying to support
Speaker 3: and maintain.
Speaker 1: Yeah, and they're like, how dare you not run on
Speaker 1: a ten year old operating exactly exactly you guys? Do
Speaker 1: you freaking guys?
Speaker 3: So that's the one that immediately springs to mind. So
Speaker 3: that was me splunking into the internals of the SMA
Speaker 3: assembly to figure out how things work.
Speaker 2: And I mean, so there's no point in pushing to
Speaker 2: the PowerShell guys. They're gonna go a sorry, now, that's
Speaker 2: not a supported operating system.
Speaker 3: That's exactly it, so we were able to find a solution.
Speaker 3: So sometimes these things happened, and that's literally there's nothing
Speaker 3: we can do in this suggestion as well, you need
Speaker 3: to upgrade to X whatever it is to upgrade. But
Speaker 3: we try to support because we know that people are
Speaker 3: running those older operating systems of older applications. So Chocolatey
Speaker 3: tries to be as backwards compatible as we can be.
Speaker 3: So we can say that we've got both the one
Speaker 3: point X branch of chocolate and the two point X
Speaker 3: branch of chocolate. Both of them are supported. So one
Speaker 3: point X goes all the way back to dot net four.
Speaker 3: If you really wanted to wow, I hope I I
Speaker 3: would like to think there's not many people still on
Speaker 3: dot net four. But yeah, stranger things have happened.
Speaker 1: Well, but this whole story about Windows twenty twelve and
Speaker 1: I don't know when it happened, but it was probably
Speaker 1: ten years later, right that, So.
Speaker 3: We're talking within the last three years, the last three
Speaker 3: years that this was that man.
Speaker 2: But it.
Speaker 1: Just it speaks to the point that somebody has been
Speaker 1: using Windows, a version of Windows for ten years, a
Speaker 1: server version of Windows for ten years.
Speaker 2: Which by the way, only went out of support in
Speaker 2: twenty twenty two.
Speaker 1: That speaks volumes, right.
Speaker 2: Like Microsoft used to offer ten years.
Speaker 1: If speaks volumes about the quality of Windows Server. I
Speaker 1: think it does well. It does except for that one
Speaker 1: stupid DLL that is the program didn't stupid initialize the array.
Speaker 2: But also you notice not Microsoft's pushing back and starting
Speaker 2: to shorten those timelines to encourage upgrade. There's also some
Speaker 2: vulnerabilities in twenty twelve that are really freaking serious, right,
Speaker 2: like it's time to retire that.
Speaker 3: And it's one of those situations that yes, we know
Speaker 3: people are using these systems, but we're also hoping it's
Speaker 3: in some sort of air gun network that has less
Speaker 3: to the Internet. Yeah, but again, stranger things well you know.
Speaker 2: Now, then back to my run ass hat. It's like
Speaker 2: the Halfnium exploit of all of those old Exchange servers,
Speaker 2: tens of thousands of them, which is sort of proof
Speaker 2: that not leading people not upgrading, they are also putting
Speaker 2: them on the internet.
Speaker 1: I told you, I think I told you many times
Speaker 1: about my sister in law who just last year was
Speaker 1: still running Windows Vista well on her home computer, not.
Speaker 2: Only running an old version of Windows, but a.
Speaker 1: Really bad but not only yet so, but her excuse was,
Speaker 1: but I like it, and I'm like, I don't care.
Speaker 1: You know what likes you, malware, that's what likes you.
Speaker 3: I remember, I think it was the Windows XP. I
Speaker 3: remember trying to set up I think with my granny's
Speaker 3: computer at the time, and I was trying to do
Speaker 3: Windows updates on Windows XP and I got I remember
Speaker 3: which bug it was, but it was one of those
Speaker 3: bugs that in the time that it took me to
Speaker 3: download the Windows updates, malware had attacked the machine. It
Speaker 3: was already infected, and there was at that point there
Speaker 3: was no mechanism to do downloads of Windows updates out
Speaker 3: with the Windows Update interface. So it was a race
Speaker 3: literally to try and get the update to fix the
Speaker 3: bug before the bug got onto your machine, before.
Speaker 2: You got exploited through that bug.
Speaker 3: Yeah.
Speaker 2: Yeah, they those who ever looked up the half new exploit.
Speaker 2: In the end, the FBI used the vulnerability to patch
Speaker 2: the vulnerability. Wow, rather because people weren't fixing it. Yeah, wow,
Speaker 2: is that bad?
Speaker 1: Halfnium? Is that what you called it?
Speaker 2: The coxploit? Yeah, it's a few years ago. There's a
Speaker 2: whole run as on it. For those who care but
Speaker 2: you know, this is all you know, this is all
Speaker 2: the stuff that that the security people scare us with, right, right,
Speaker 2: but these were these were crucial sort of turning point
Speaker 2: of vulnerabilities. Right, it's twenty twenty one.
Speaker 1: Every Thursday, after I record Security this Week with Patrick
Speaker 1: Hines and Duine Laflatte, Kelly sits down and says, so
Speaker 1: what should I be scared about today?
Speaker 2: Just put the tinfoil on your head and be quiet. Right,
Speaker 2: It's gonna be fine.
Speaker 1: Sometimes it feels like we're all screwed. It's just a
Speaker 1: matter of how long it's going to be before that
Speaker 1: happens somehow.
Speaker 2: Sometimes, well, the good news is the good The good
Speaker 2: guys are smarter than the bad guys. But the good
Speaker 2: guys have to be right every time they get guys
Speaker 2: only have to write once.
Speaker 1: I don't know. The bad guys have countries behind them though,
Speaker 1: So that's what bothers me. Armies of hackers. You know,
Speaker 1: it's scary world out there. But as Rory said, once
Speaker 1: cut off your hands, live in a box, you'll be fine.
Speaker 2: There's a tone for the show.
Speaker 1: Everything's going to be fine.
Speaker 2: Baggage management it's great, No, really, it's great.
Speaker 1: Great, No, it's fine. Gary. What's next for you? What's
Speaker 1: in your inbox?
Speaker 3: So obviously more chocolate you work. I'm hoping to go
Speaker 3: to ps COM for you in Germany in June the CONFI. Yeah,
Speaker 3: so it's the EU version of the PowerShell Summit that
Speaker 3: happened at State Side, so as a really good event.
Speaker 3: I was there last year or sorry this year, and
Speaker 3: I'm hoping to go next year as well. But yeah,
Speaker 3: other than that, just being a dad, being a husband,
Speaker 3: doing all the day to day stuff. It's not it's
Speaker 3: not it's not exciting, but it is what it is.
Speaker 2: So oh, it's exciting being It's bloody rewarding is what
Speaker 2: it is.
Speaker 3: That's very true.
Speaker 1: All right, Well Gary, thanks a lot. We always learn
Speaker 1: a lot when we talk to you, and this was
Speaker 1: no difference. So thanks than all right, We'll talk to
Speaker 1: you next time on dot net rocks. Dot net rocks
Speaker 1: is brought to you by Franklin's Net and produced by
Speaker 1: Pop Studios, a full service audio, video and post production
Speaker 1: facility located physically in New London, Connecticut, and of course
Speaker 1: in the cloud online at pwop dot com.
Speaker 4: Visit our website at d O T N E t
Speaker 4: r o c k S dot com for RSS feeds, downloads,
Speaker 4: mobile apps, comments, and access to the full archives going
Speaker 4: back to show number one, recorded in September two.
Speaker 1: Thousand and two. And make sure you check out our sponsors.
Speaker 1: They keep us in business. Now go write some code,
Speaker 1: see you next time. Got tad middle vans now the
Speaker 1: summer time that means home. Then my Texas in line
Speaker 1: read