No matter how long you've been using Linux there are always things that you can do better and I think that this is true Pretty much across the board. There are always things that you can do to improve your workflow on Linux No matter what you use Linux for whether you're just a casual user and all you do mostly is browse the web do Email and play some games or if you're a developer or whatever it really doesn't matter What your skill level is there are some things that you can do to improve your workflow on Linux And I know that that is true for me for sure that there are things that I just don't know that if I did know them I could be a better Linux user So what I thought I would do today is talk about five things you can do to make your Linux experience more awesome now there's a good chance that you probably know some of these and That's great. Maybe you'll get lucky and you'll not know some of the other ones. So let's go ahead and jump in so the first one is pretty simple and I don't think that it is something that most people probably don't know but I wanted to put it on the list because I do think it's really important and That is to learn how to install fonts now I could go through and tell you how to install fonts But the problem is that there are several different ways of doing it and really it does matter what desktop environment or window manager that you're using because how you install fonts is going to differ between those things sometimes you're Kind of on your own and you have to install them manually like in the terminal or something or install a tool to do it If you're using a desktop environment chances Are you'll be able to use the settings application to install fonts in some way if you? Don't like that particular way of installing fonts. There are other ways so the reason why I think that this is important is because if you do any type of writing or design work or even coding on Linux having a good font is important for readability and All sorts of things so if you can learn how to install fonts That's going to be a boon to your workflow even though it might not seem like it would be so That's number one on the list or number five. However, you want to put it. It doesn't really matter the next one is You should learn how to delete unnecessary files because this is something that happens a lot on Linux and pretty much every Operating system as you use your system more and more it accumulates temporary and cache files that Often times need to be deleted and there are other files too So dependencies that are no longer needed. They're called orphan dependencies these things pile up over time And well, they don't really hurt anything for the most part They can take up a lot of disk space So if you download something through from like a you are something there's a cache file of Pretty much every version of everything that you've ever downloaded in a file somewhere And that thing can take up a lot of disk space And if you are limited on disk space like most people are deleting that file Can save you some room now how you do this is going to depend on what distribution You're on and what package manager you use Specifically if you're trying to delete or orphaned packages So if you use something like Ubuntu you'll use an apt command if you're on arch to use pac-man and so on and so forth The best way to learn how to uninstall those orphan packages is to use the man page for your package manager because that's going to be able to Tell you exactly What commands you need to use in order to delete those packages now one thing of note while you can pretty much Delete caches without any problem at all you can delete those without worrying that you're going to break anything for the most part You do want to make sure when you uninstall orphan packages that they're actually orphaned Now I don't know if you've ever watched the Linus tech tips Linux challenge But one of the reasons why his experiment with Papa West failed was because he did pseudo apt auto remove and it removed Some packages that weren't actually orphaned. So when you do something like that Make sure you read the output of the command before you do any confirmation Just to make sure that you kind of know what you're deleting. So just a cautionary tale also Highly recommend before you do any of that kind of stuff have a backup no matter what you do on Linux This is just like an extra tip, but really this is kind of applies across all computing Always always have a backup before you delete anything just do that and you'll be much happier if something goes wrong The next one on the list is that everyone should learn how to use cron jobs Now this doesn't really sound like something everyone would probably need to do and you probably could use Linux your entire life without ever having to Use cron, but it is such an amazing tool to do certain things So what is cron and what is a cron job? Well cron is a service that runs on your computer that performs tasks Automatically on a certain schedule. So for example, let's just say you wanted to set up cron to backup your computer every Friday night at midnight you could do that if you wanted to have it run a Script that updates your system every week at a certain time You can do that or maybe it just checks for updates and tells you how often or how many updates you have pretty much the sky's the limit as long as you can script it cron can do it and I have a video on how to use cron So I'll link that in the video description and more of the cards up there somewhere So you can learn in-depth how to use cron But the amazing thing about it is that it allows you to automate pretty much anything on Linux that you can script So the reason why I say it's script because for the most part cron is a terminal based Application there are gooey front-ends for it. I've just never used them So I don't know how good they are So that should be something that you might want to research if you're not comfortable using the terminal But it does allow you to automate a lot of stuff And that means that you can always have a backup on hand So you don't lose anything and you don't actually have to remember To do a backup which is cool. The next one on the list is kind of broad and I Really didn't think I wanted to put this on the list because I've talked about it many times before And I know that a lot of people are people who disagree with this and there are a lot of people who agree with it It's kind of a controversial topic and that is everyone should learn the terminal I'm just going to put that out there. Yes, you can use Linux never touching the terminal That is 100 possible anyone who says that you can't do that is wrong It just is not the most efficient way of using Linux There are certain things that you can do on Linux that are Easier or maybe not easier but more efficient to do in the terminal. So renaming files moving files around those things Are easier or again more efficient to do in the terminal Also using things like git and curl and wget to do certain things in the terminal just kind of work better In the terminal you can have front ends for those things There are applications that do similar things, but they're primarily terminal tools And while those might not necessarily be things that appeal to everyone There are a ton of examples like that that just kind of work really well in the terminal where they do have GUI alternatives, but they're not quite as efficient So I highly recommend learning how to use the terminal. It doesn't mean you have to use it all the time You don't have to become super nerd in order to use Linux. That's not what I'm saying here Just if you learn the basics, you'll find yourself using it more and more often as you use Linux more And you'll find that you actually probably like it better than using the GUI now That's not going to be true for everybody, but for a lot of people that probably be true Now the last one on the list is One that I'm working on a tutorial for I've been working on this tutorial now for at least two months It's been a while. I'm trying to get it right because it's one of those things where you really want to not spread False information and what I'm talking about here is that I think that using butterfs will truly make your experience on Linux better Now it's not going to make your system faster It's not going to make you work on your Linux system faster None of that stuff. No The best thing about butterfs is that it creates snapshots or it can create snapshots It doesn't do it automatically and it creates sub volumes. So the very layman's explanation of what butterfs is now first of all Let's talk about the name. That's before we explain what it is. Let's talk about the name I call it butterfs. A lot of people call it betterfs.  What is butterfs? It's a file system It's basically an alternative to something like ext4 or ntfs on windows You don't use ntfs on linux ever really but That's what that is. It's a file system And once you have that knowledge, then you need to know what it actually does and why it's good And what you know like why would you use it over ext4? Which is kind of the standard? Well, it allows you to take snapshots of your system And what a snapshot basically is is a frozen moment in time of your system So that if anything goes wrong you can revert to that snapshot and your computer will be up and running again That's really as simple as it is now. Obviously snapshots aren't 100 full proof No backup system is but it does give you that added layer of security in case an update or Something like that fries your computer on probably that's probably not a great way of putting it if an update corrupt something in the root file system and You have to use a snapshot to get back to your other thing That's a situation where a snapshot would be useful, right? There are tools to use with butterfests that allow you to do Snapshotting automatically whether it's When you do an update or through a cron job something like that one of those tools is a tool called timeshift It's amazing and really astonishingly simple to use Now most linux distributions outside of ubuntu will allow you to use butterfests as the default A lot of distributions actually use it as the default already So if you're using something like fedora or open suza You'll know what butterfests is because that's what they use as default arch linux And basically every arch based distribution will allow you to use butterfests as an option You usually are set to ext4 as standard, but you can easily switch to butterfests with ubuntu You kind of have to manually partition so it's not as easy. They've chosen to use a different standard I believe it's called xfs. I'm maybe it's zfs I think it's zfs I don't know why I called it zfs because i'm not british But whatever it doesn't really matter the point is is that ubuntu uses something different You can still use butterfests if you want to you just have to manually partition And again, I'm working on a tutorial on how to do Or how to use butterfests that should be up sometime in the next month. Hopefully Like I said, I'm working on it. It's just proving to be a little difficult not that butterfests itself is difficult It's just I'm having a hard time explaining it So those are the five things I think that will make your linux experience much better And like I said, you probably know a few of those things if you've been using linux frame on a time But maybe there are one or two on there that you didn't know about so that is it for this video You can follow me on twitter at the linux cast. You can follow me on masted on any of those other social media networks You can find those links in the video description You can support me on patreon at patreon.com slash linux cast just like all of these fine people Thanks for to everyone who's on this list who supports me on patreon and youtube. I truly do appreciate it I can't ever truly find the words to say how grateful I am That so many people have chosen to Support me on youtube and patreon. It just Constantly blows my mind. So thanks everybody who supports me there. Thanks everybody for watching. I'll see you next time


Today, I'm speaking with Mark Chelmers, the CEO of Energy Fuels Resources, and I'm going to discuss the rare earth industry as it pertains to energy fuels resources. Good morning, Mark. How are you doing today? Good morning, Jack. Top of the world. Okay. Actually, that's true. You're in Denver. I'm in Detroit. You're about several thousand feet higher above sea level than I am. Exactly. In any case, your company was involved in a news release yesterday saying that you had entered into a memorandum of understanding with an Australian heavy mineral sands producer astronaut. My opinion is that you are proceeding logically according to your published business model for rare earths to create a secure supply of monazite, the feedstock, which is the cornerstone of the system you've designed. So I'd like you to tell us what's happening with that, Ron, and how it fits into your long-term model for being a major rare earth producer in North America. Yeah. Thanks, Jack. I'm happy to explain it. I think all of our investors and most of the public realize that we're building a critical mineral hub that is really based on utilizing our infrastructure and our skills and our knowledge when it comes to dealing with radioactive substances. So on the rare earth side of the business, which contains the monazite contains uranium that we can extract at our facility and also on sale to nuclear utilities for the uranium sector, we are securing and need to secure large quantities of monazite to fulfill those objectives of that strategy. So really, this MOU, which is non-binding currently, we still have to do the due diligence, is a major step in securing material quantities of monazite, assuming everything comes out in the due diligence for decades, like 40 or 50 years, and potentially gives us enough feed source to produce around between one and a half to 2,000 tons of NDPR, which to put it in context is about one third of what Linus is currently doing. So it's very material for us. It complements our current core business of uranium mining and processing perfectly, perfectly. And I think people have a hard time understanding that sometimes. So it's a step. We're finishing up the phase one separation capabilities at the mill in the first quarter. And we're very excited about that. There'll be more news flow on that regard. And so we're trying to break them all. Somebody has to run forward in a logical way, as you said, particularly in what the rare earth and uranium business to actually produce things in time. And that's what our company's all about. I'd like to point out to the audience that two or 3,000 tons of NDPR would be enough to make approximately 10,000 tons of rare thermotent magnets, which would happen to be about what the United States imports today from China just for current internal combustion engine production. So no one else is anywhere near this level. And I congratulate energy fuels for taking on this project. And I realize that right now it's secondary to your primary business, which is the production of uranium. But in fact, Monozyte does contain some uranium. And so it's added value. And it's actually, to me, a genius move because it rather than extracting uranium from Monozyte and discarding it, you're taking that residue and making it a strong payable. So this, to me, is a win-win for any business model. I congratulate you more. Thank you, Jack. And again, I think that's one thing that some people don't completely fully understand is the scale and the magnitude of this bolt-on, rare earth, that we're focused on as the bolt-on when the prices of rare earth are lower, when there are acquisition opportunities right now in the rare earth business, where there are very few acquisition opportunities in the uranium business, it fits perfectly with our strategy of diversification and be able to be strong where we need to be strong. So yeah, the scale is significant. It's material. We are the front runner, particularly in North America on that front. And we plan to be a world significant in all things critical elements while producing uranium. The uranium plans are full-tailed right now. We've got, we've hired about 60 or 70 miners or underground or break and rock, all to be processed at the White Mesa Mill as will the Monozyte for the rare earth strategy. Well, thank you, Mark. I really can't add anything to that. It's difficult to overemphasize the fact that you are the premier producer of uranium in the United States. Uranium is extremely in demand today as many people have figured out that the best non-carbon source of energy production is nuclear and you're in the spotlight there. Again, I congratulate you for finding a way to, I'm sorry to use this analogy, but it's like a pork backer. They say, well, we use everything with the squeak, but you're actually also using the squeak. So everything is becoming a payable. Everything coming into White Mesa is going out as a payable. Again, I can't think of a better business model. Thank you, Jack. And we are trying to get the squeak for all the right reasons in this area of energy transition elements for the future. Thank you very much. I appreciate the interview.


Autistic Alexofimea is a very, very real thing, and it explains so much of the experiences that we have as autistic people. I used to think that I had DID as a teen, when it really just couldn't connect my behaviours and thoughts with my emotional states. It made it difficult to spot when my anxiety was rising, making a lot of anxiety strategies almost useless. I talked so calmly about difficult events in my past, so much so that it was difficult to process those events in therapy. Alexofimea explains so much about my emotional and social experiences, so I'd love to know if you relate to any of my experiences. Let me know down in the comments.


Good morning, everybody, and thank you for bearing with us through some technical difficulties. My name is Milind Kulkarni. I am a professor in the Elmore Family School of Electrical and Computer Engineering. I'm also the interim head of the department. So it gives me great pleasure to welcome you all to the Engineering Frontiers Lecture. So the Purdue Engineering Frontiers Lecture Series is modeled after our Distinguished Lecture Series where we invite world-renowned faculty and professionals to Purdue Engineering to encourage stop-provoking conversations and have them share some of their ideas and research with us. And so while the Distinguished Lecture Series is planned well in advance, we kind of book a year out every now and then, we have an opportunity to welcome truly distinguished people to Purdue. And so the Frontiers Lecture Series gives us an opportunity to do things a little bit quicker and get things going a little bit faster. And so welcome today to the Purdue Engineering Frontiers Lecture Series. To introduce our speaker, I'd like to invite Professor Lunalu to the stage. She's the Riley Professor of Civil Engineering and the Associate Dean of Faculty for the College of Engineering. Today I'm truly honored to introduce the Professor Vincent Poore. Professor Vincent Poore is Michael Henge Streeter University Professor at Princeton University, where his research interests including information theory, machine learning, network science, and their application in wireless networks, energy system, and related areas. Among many of his publication in the areas is a recent book, Machine Learning and Wireless Communication published by Cambridge University Press. Professor Poore is the member for both US National Academy of Science and the US National Academy of Engineering and is a foreign member of the Royal Society and many other national and international academies. He has received IEEE Alexander Graham Bell Medal in 2017 and holds honorary doctorate degree and professorships from a number of universities in Asia, Europe, and the North America, as you can see, were truly honored and excited to have Dr. Vincent Poore with us as our distinguished lecturer. So please join me, welcome Dr. Poore, to get on the stage for his speech. Thank you very much for that kind introduction. It's really great to be here. The last time I was at Purdue was in 2005, so it's been quite a while and I'm really happy to be back, so have this opportunity to speak. So today, the title of my talk is a little self-explanatory. I'm going to talk about the combination of machine learning and wireless networks. So machine learning and wireless networks are, of course, two of the most rapidly advancing technologies of our time. And neither of these technologies really is new.  We have 5G now. We're working on 6G, the research community. And machine learning also goes back to Marvin Minsky and even before in the 40s and 50s. And there have been many resurgence of AI and machine learning over the years. In the 90s, there was a huge interest in neural networks and so forth. So these are all, in a way, old technologies, but ones that continue to advance very rapidly. I'll say a little bit more about why in a minute. But one of the things that has happened in recent years and we're expecting to happen more as we move towards sixth generation wireless networks is sort of the confluence of machine learning and wireless networks. And that's what I'm going to talk about part of that today. So when you think about machine learning, by the way, I hope the lighting is OK so people can see this. All right, is that OK, Chris? Fine. OK, so when you think about machine learning and wireless or when one thinks about machine learning and wireless, there are two sides of that sort of connection. One is the use of machine learning to optimize wireless networks. And it's a very natural application of machine learning because wireless networking involves many types of things that machine learning is good at. For example, routing, flow control, all kinds of optimization problems, channel decoding, coding, all these are statistical inference problems, channel estimation. And so these are things that machine learning is really good at. And wireless networks, of course, generate examples. So if you want to learn from examples, the data rates in wireless networks are now gigabit. And so you're getting exemplars very, very fast. And even in the routing side, you're getting packets very, very rapidly. So there's a lot of opportunities to learn. There are a lot of problems from which are useful for learning and for which machine learning is good. In the past, these kind of problems were solved using model-based techniques, which has worked very well up till the present. But now networks are becoming a lot more complex. A number of users, a number of terminals, is exploding. And just the complexity of the problems are getting much more difficult to handle using model-based techniques. So machine learning is a natural way, given the advances in machine learning. It's very natural to apply that in wireless networks. So another side, which I'm going to talk about today, though, is the use of wireless networks as platforms for machine learning. And I'll get into the motivation for that later. But basically, terminals, even these, are pretty sophisticated now computationally. And they're also sensors. They gather a lot of data. So there's a lot of data out of the wireless edge. There's a lot of computation power. And one of the big trends in networking is mobile edge computing, pushing computing out of the edge. And machine learning, of course, is one of the main applications of computing. So it's very natural to think about, let's use wireless network as a computer for machine learning. And so that's what I'm going to talk about today, part of that. That's, of course, a big area as well. And along the vein of shameless self-promotion, I'll mention this book here, which also was just mentioned on machine learning and wireless communications, which just came out last year. And it looks at both sides of this coin. But I'm only going to talk about the second one here today. So I'm going to talk, first of all, I'll motivate a little bit, again, further why we want to think about using wireless networks as platforms for machine learning. And I'm going to talk particularly about federated learning, which is a type of learning which is not particularly for wireless systems, but it's going to tailor made for wireless networks. And I'll talk about two things there. One is scheduling, and the other is privacy. And then at the end, I know there are a lot of students in the audience, so at the end I'm going to talk about some research issues. And most of what I'm going to talk about is not going to be the most cutting-edge thing. It's just to give you an idea of what some of the problems are. And then at the end, I'll come back and talk about some things that people are working on right now. So that's the program for today, and hopefully I'll be able to keep on time. So let's start with some motivation. So here's a very broadly brushed and oversimplified, perhaps, view of the state-of-the-art in machine learning today. So as I mentioned, machine learning is not new, but what has happened now, which was made in machine learning, so prevalent are two things. One is there's a lot of data, a tremendous amount of data available, collected by devices like this, by sensors, collected on the internet, and so forth, which was not available during the last upsurge in the study of machine learning in the 90s. There were no smartphones. The web browser was just invented, and so forth. So it wasn't the same culture we have today in terms of technology. And also, the computing power since the 1990s has grown dramatically. The amount of power you can get in even a small device like this, but certainly centralized with the cloud, centralized web services, and so forth, is a tremendous amount of computing power out there. So a sort of standard view of machine learning is that you have a lot of data, and machine learning algorithms have access to all that data. And this is happening in the cloud or in some data center or something like that. So it's a centralized problem being solved in one place with all the data together. And of course, you don't really today, you don't even really have to know much about machine learning to use machine learning. There's a lot of tools out there. There's TensorFlow and PyTorch and so forth. So you really just have to know how to use a computer and have an internet connection, and you can do machine learning. And also, of course, a machine with lots of data of things like deep neural networks and so forth, the computational complexity is huge. So there's also, of course, a lot of specialized hardware for that. NVIDIA, if you watch its share price, you can see why the GPUs are very prevalent. Google also makes TPUs and so forth. So this is, again, a very oversimplified view of the state of the art in machine learning. So there's some problems, though, where this centralized model is not really adequate for certain applications. And some examples are shown here. One is automation. So things where you have autonomous driving, as for example, or Industry 4.0, where you have automation of a factory, mobile apps, and first responder networks, and things like that. So these are applications where, first of all, the data that's being used is already out at the edge of the network. So it's collected by sensors, smartphones, and so forth. Also, and that data may be plentiful at the edge of the network. And in order to do centralized machine learning, it has to be backhauled through the network. And often, that's a wireless network, and then capacity is limited. So backhauling data to the cloud is impractical sometimes. But also, another perhaps more important thing is latency. So these kind of applications, autonomous driving, and so forth, factory automation, latency is very important. And so the less time you have to spend backhauling data, the quicker you can respond with your models, and so forth. Also, privacy is an issue, of course, with mobile apps. A lot of the data that's being collected is personal data, location, and so forth. And health care, there's a lot of privacy issues. So the less you have to share data back into the network, the less likely it is that that data will be compromised. And then finally, scalability. So if you have hundreds, thousands of terminals, say, in an IoT internet of things network, just to be able to scale machine learning up, it's helpful to be able to do all that out at the edge. And then finally, locality. A lot of applications, you don't really need to collect data over a widespread area. For example, in autonomous driving, you really just need more local data. So the models can be local. You don't need to build big models back in the cloud. So all of these considerations motivate moving machine learning out to the edge of wireless networks. So there are three, you can think of three network models for wireless networks. One is the one I just described, the standard machine learning where data is collected out at the edge of the network by end users. And that data is uploaded into the cloud. So data is collected there, and machine learning takes place there. Models are built. And then either the models are shared back down into the end users, or the models are applied in the cloud, and in decisions, or what have you, or shared back recommendations, or whatever you're doing, are shared back down. So this is what I call standard machine learning before. So another model is federated learning, which I'm going to talk about today, where the data is collected by end users. And then the end users actually build on themselves, on their own devices, a shared model, or they want to build a shared model of something. And then they build their own smaller models, or own models based on their smaller data sets, and then share those up with an aggregator, which could be an access point, or a base station, or something else. It could be the cloud, actually. And then the aggregator puts all these little local models together in some way, and then sends out a global model back to the edge, or to the end users. And then those end users then can update their models, and it can iterate until you get some kind of convergence. Yes, that's federated learning. And then another type of learning at the edge is decentralized machine learning. I'll talk a little bit about that again. But decentralized machine learning, again, you have end users who are trying to build a common model. But they don't have an aggregator. So any communication is peer to peer, and any aggregation that takes place has to take place in that setting. So that's another thing. There's a lot of interesting work there. I'm not going to talk much about that, although I'll say something about it at the end. OK, so this is the setup. We're going to talk about the middle model today. And so federated learning, by the way, was not invented for wireless networks. Federated learning was invented as a distributed machine learning algorithm invented at Google. Not thinking, I don't know if the, I can't put myself in the mind of the inventors, but they were thinking mainly, this is a way to keep data out in the processors and to share the workload and so forth. But it's tailor made for wireless networks because of the distributed nature of the computation and so forth is naturally there. So I'm going to talk about federated learning over wireless channels. And I'll start out by talking about scheduling. So the basic idea, as I said before, is to enable end user devices to do machine learning without centralizing their data. And the basic idea are the data sets remain on the end user devices where they're gathered. And so the raw data never goes up into the network beyond the end user device where it's collected. Training is done on the end user devices. So there you have multiple end user devices trying to train a shared model. And then federated computation. So these local models are uploaded to an aggregator and that aggregator collects the train weights or gradients depending on how you want to do that. So the model is updated and aggregated by the aggregator and then that's sent back down to the end users who try again, update the model and iterate back and forth that way until convergence. So this is federated learning. So now if you do federated learning over wireless networks then you have to worry about some other things. So in wireless networks the communication between the end user devices and the aggregator has to go over wireless channels. So immediately you run into some physical constraints. So first of all, the wireless medium is shared and resource constrained. So because it's resource constrained there only a limited number of devices can be selected for uploading models in any given round. And secondly, it's a wireless channel. Those of us in wireless we spend our whole careers trying to figure out how to overcome the impairments of the wireless channel. So wireless channels are not reliable because of interference and other things, fading and so forth. So we have to worry about two things when we're doing federated learning over wireless channels. One is how do we schedule the devices? How can we choose which devices at each time to upload their models given finite resources? And second, how do the interference and noise affect training? Okay, so those are two issues I'm gonna address now looking at how scheduling, how those things affect, how scheduling affects the performance of federated learning in this environment. So I'm gonna do that, illustrate that using three scheduling mechanisms. And one of them is random scheduling. So the setup here is we're gonna have K in user devices and they're in channel resources that can be used. So you might think about those as frequency channels or time slots or something like that. But basically, N is less than K. So at K might be hundreds and N might be dozens. So the access point, the aggregator has to decide at each update round which K of the N devices to choose. And random scheduling is just what it says. At each update round, you choose that random K out of N, N user devices to update their models, okay. Round Robin is another standard scheduling mechanism where you take all the N users, divide them into groups, so they're K over N groups. And then you sequentially, on each update round, you just sequentially go through and select each group one at a time. And then there's proportional fair which actually uses some of the physical characteristics of the wireless channel. At each update round, the access point or the aggregator selects N out of K N user devices with the strongest signal and noise ratios relative to their signal and noise ratio history, okay. So what you're looking to do here is to choose the ones that have the best chance of their actual communications getting through at any given time. Okay, so what I'm gonna do is I'm gonna compare these three in terms of how they affect convergence of federated learning over wireless channels. So how can we do that? Well, first of all, we can, in order for an N user devices model, local model to be part of the aggregation, two things have to happen on a given round. First of all, it has to be selected. So the scheduler has to select that N user device. And secondly, the data packet containing the model or the gradient that's being sent up to the aggregator has to be transmitted correctly. So one way to model that is to say, well, the so-called signal to interference plus noise ratio at the aggregator for transmission from an N user has to exceed the decoding threshold. So you can ignore the equation here, but basically there's a measure of the quality of the received signal in an interfering environment. And if that quality is greater than some threshold theta, then the packets can be, the data packet can be decoded. That model can be added to the aggregation and so forth. And otherwise that packet is lost and that aggregation is, that model is not part of the aggregation, okay? So theta here is a parameter. So if theta is really small, that means most packets get through, which means it's a really good link. If theta's large, most, a lot of packets don't make it through, it's a bad link, okay? And so how can we compare schedulers? Well, we can look at the number of communication rounds required by the federated learning algorithm to reach a certain level of accuracy. And here I'm gonna talk about so-called epsilon accurate solution. So now be more specialized in the problem we're trying to solve. So a typical machine learning problem is you're trying to maximize a concave function or minimize a convex function, one way or the other. And if that function is strongly convex, then the so-called dual problem and the primal problem have the same solution. So an epsilon accurate solution is one where the duality gap, the gap between the dual solution and prime solution that you compute is less than or equal to epsilon, okay? So I think the main thing just to think about that is just a measure of quality of the final solution, epsilon. So two parameters, theta and epsilon so far. All right, so for those three schedulers, it turns out we can get lower bounds on the number of communication rounds needed for achieving epsilon accuracy. And they're given here, and don't worry about the details, they're just, I just put them here to show you that they exist. But the main parameters here are theta, which we introduced before us, the SI and R threshold, epsilon, the degree of accuracy that we're trying to achieve. And then alpha, which is the path loss, so it's a wireless channel, so there's diffusion losses and it goes according to a path loss exponent. We abstract the performance of the end users and the machine learning into a precision level beta. And then N is just the total number of examples that we're trying to learn from. So they're distributed over all the end users. And there's these lower bounds or lower bounds, we don't have upper bounds, so we only have lower bounds, I'll address that in a minute. But these parameters tell us what, at least in terms of lower bounds, to expect in terms of communication rounds. So don't worry about the formulas, but we can look at a plot of these. And so here's a plot of two different scenarios of those lower bounds. So the one on the left is the high SINR case. So this is a case where mini packets are lost. So the high SNR means high SNR threshold. Mini packets are lost. On the right, we have a low SINR threshold, so most packets get through. And what you can see here, so remember there's random scheduling, round robin and proportional fare. And you can see that on the left, where we have a less desirable link, proportional fare works much better. So small is good. This is the number of communication rounds to converge. So proportional fare works much better than the other two, at least in terms of this lower bound. And then on the right, where we have a really good channel, a really good link, round robin works better than the other two. Okay, and so there's some intuition here, because if we have a poorer channel, a poorer link, remember proportional fare takes into account receive signal and noise ratio. So there we care about the signal and noise ratio a lot more than if we had a really good link. So proportional fare works better than the other two, which don't take into account anything about the wireless channel. On the right though, where most packets are gonna get through, what really matters more is that we touch all the data more regularly, right? And so round robin assures that you touch all the data equally. And so we can see that intuitively, if the wireless channel is really good, we don't care so much about it. If it's really bad, we care a lot about it. So that's sort of the takeaway from these graphs. So these are lower bounds, and of course they're just lower bounds. But what about machine, and this is a very pristine model, what about a real machine learning problem? Well, here we look at a problem of building a support vector machine on the so-called MNIST dataset. So that's just a dataset of handwritten characters from zero to nine. It's a very standard test for machine learning algorithms. And what this shows is versus a number of communication rounds, two things. One is loss, which is like mean squared error or something like that. And the other is accuracy. So percent right. For random scheduling in blue and round robin in red, and this is a case with a really good link. So low SINR corresponds to the right hand side of that previous chart. And what you see here is that although both of these converge to the same kind of quality of performance, round robin converges much more rapidly. And if you remember on the previous page under these circumstances, you can see that round robin was much better here. So this bears it out in a real machine learning problem, the same thing. So the basic conclusion is that you can't just choose an arbitrary scheduler. The scheduling protocol matters. So we might ask the question as to whether we could optimize the scheduler. And there are a number of ways to do that. Actually, there's a whole cottage industry of scheduling in federated learning. But one thing we might do is the following. So age of information is a metric that is used a lot in modern communication system design because it takes into account, classically communication systems were designed to minimize the distortion between what's received and what was transmitted. This classical Shannon-esque information theory. But in modern applications, particularly sensor networks with energy limited terminals, you're also interested in the freshness of the data. So age of information is a metric that's applied together with distortion in order to take that into account. So we can use that here. We can think about the age of our updates. So for each end user device, we can assign an age to its information. And if it's chosen by the scheduler on the ground, but its age is zero, and every round that goes through when it's not chosen, its age implements by one. So we'd like what we'd like to do is to minimize the average age of information. So that's one way to optimize scheduling. And it turns out it's pretty low complexity algorithm to do that. And so we can do it on every round. And here's just another example. This is the same learning problem I mentioned before, support vector machine on the MNIST data set. And what I'm comparing here is again, versus communication rounds, this wireless round Robin, which is the one that minimizes the average age, versus maximum pack, which is another sort of optimum scheduler, optimum trying to maximize the number of updates on any given round. And you can see that by choosing, by minimizing the average age of information, we can do much better. This is the bottom line. So again, I said there's a kind of a cottage industry of this. I mean, there are many, many ways you can schedule. You can look at only those end users, you can schedule only those end users, for example, who's gradients on their gradient update. So if you do gradient descent and optimizing the do machine learning, the gradient small, there's no need to update the aggregator. So there are a lot of things like that, that you can be done, and I'm not gonna go into that, but this just gives you an idea that, yes, scheduling is important. So now I'm gonna shift gears and talk a little bit about privacy. There's another problem that comes up here. I mentioned it earlier. And the idea here is that, when machine, when federated learning was first proposed, and for a couple of years after that, it was always said to be privacy preserving, because the data never leaves the end users, right? So if the data never leaves the end users, it's private, right? But then it was shown subsequently that actually, and it kind of in retrospect makes a lot of sense, that the data, actually you can infer things about the data from which a model was built from the model itself. So if you have a machine learning model, you can back through it and figure out something about the data that was used to train it. And if you think about it from an information theoretic point of view, well, of course, you know, the model is a function of the data, so it's not independent of the data, okay? And there's some pretty spectacular examples where the data consists of images, and you can look at the model and recreate the image, looks pretty much like the original image and so forth. So this is a real thing. So it's, and it's a concern, because many applications of machine learning and federated learning in particular are ones where the end users have private information in their data. So there's a lot of work on this problem as well, and one way, sort of the principle way, I think right now of looking at this is to use so-called differential privacy to protect the data. And I'll just say a little bit about what that is in case you're not familiar with it. So differential privacy is a definition of privacy that was developed for databases, and the basic idea, I'll try to describe it as best I can, but basically if you have two databases which differ only in one piece of private information or private data, but otherwise are identical, then you say that that type database is differentially private if you can't distinguish between those two with high probability. So that's roughly what differential privacy is. There are a lot of definitions of privacy, but the nice thing about differential privacy is that it's easy to achieve in practice, you just add noise, okay, and that gives you a certain degree of differential privacy. So that's an approach that can be used in federated learning. You can add noise to what you're uploading to the aggregator, and of course, that automatically creates a trade-off between privacy and learning, because you add noise and so you're gonna have noisy, the more noise you add, the worse it's gonna be. And we can see that, just here's an example, this is also the MNIST data set. Now this is a convolutional neural network, but otherwise it's pretty much the same problem. And what's shown here is basically the trade-off between privacy and learning accuracy, okay, and for this for an example. And so down below is aggregation time, so again, that's the number of rounds. And so differential privacy has a parameter epsilon in it, and the smaller epsilon, the more private. So here you can see no privacy is the top one, so that's the kind of thing we've been talking about up to this point. And then as you apply more and more privacy, you can see that the algorithm converges to lower and lower testing accuracy, okay. So it's clearly a trade-off. So it's to be expected, right. So there are some things that we can do about this. So one is just note that as you get closer and closer to the optimum, if you're sharing gradients, the gradients get smaller and smaller. So if you add the same amount of privacy noise all along, it's actually having a worse and worse effect. And then it also causes you to converge more quickly to a poorer solution. We saw that on the previous page. So another thing, one thing you can do is to over time reduce the amount as you iterate through federated learning algorithm is to reduce the amount of privacy noise you add. And there's an analysis of that. I don't have any charts to show, but there's a paper on that that came out fairly recently. This shows that you can get a much better trade-off between privacy and accuracy by doing that. You can also look at other things. So one, an important thing in machine learning is generalization error, which is how well, so you train on data and you wanna see how you get a model and you wanna know, did you overfit that model? How well is it gonna work if you could get new data on it? And that's sort of measured by this thing called generalization error. And we can use some information theoretic techniques to get upper bounds on that. And this is a bound versus the parameter epsilon that appears in machine learning. I mean, it appears in differential privacy.  So of course you also get worse accuracy, but at least you're not overfitting. So adding privacy actually gives you another bonus, which is you get better generalization error. And by the way, the same thing happens with quantization. So if you quantize the quantize what you transmit up, you also, it adds privacy, it gives you better generalization error, but at the expense of less accuracy. So it's a trade-off. So I think I've got about 10 minutes, so let me spend a bit of time talking about some other issues. So this is what I've talked about so far has been pretty pristine and real problems. There's a lot of other things to think about. So first of all, you know, these devices or even other edge devices are more sophisticated or there are ones that are less sophisticated like sensors and an IoT network, but in any case, resources are limited. Okay, your smartphone has more to do than do federated learning. It has a lot of other tasks. So there's a lot of limited resources are limited, things like energy, storage, computational power. So that means there's a lot of trade-offs in these problems that I haven't talked about. So for example, if you're gonna put a neural network on your phone, how many layers? How should you quantize the coefficients? How many neurons per layer? How much energy can you spend on that? How accurate do you want it to be and so forth? So another thing, another important issue is the heterogeneity of the devices. So not all devices, for example, you're doing federated learning, I sort of talked about it like it was a synchronous thing, right? But they're stragglers. So some devices, their models converge more quickly. They have more resources to apply. So you start having problems of delay, having to wait for the last device to finish converging, right? So that's a problem. So you have to worry about that. You have to worry about the fact that the datasets are not all the same. I mean, the examples I gave, I just divided them equally among the learners. But in fact, that's not the case in practice. Every device collects its own data. Also, I assume the data was independent from learner to learner, which is not true in general because particularly in a sensor network, the data is correlated. People are collecting data on the same phenomenon. So there's a lot of work on this kind of problem. Okay, so I just wanna point that out. These are not things that people have overlooked. Another thing that people have looked at is so-called split learning, where in split learning, you divide the model. If you have a big model, you put part of it in one place and part of it in another place. So here you would put maybe a bigger model at the aggregator and then let the end user devices learn a smaller model because of some of these other considerations and then the aggregator would combine that. So there's something called split fed, which does split learning with federated learning. That's another thing. Another thing, by the way, is building foundational models so you can build a foundational model from a big data set and then fine tune it for specific applications. So this comes up in language models. You can train a foundational model on all kinds of language data and then if you wanna train it for French, you just use some French examples and then you can fine tune it for French. So this is a thing in like chat and GPT type applications. Well, those kind of models, foundational models are too big for end user devices, but you could use the cloud to train a foundational model and then use end user devices to do fine tuning. So those kinds of things are also things people have been looking at, trying to bring large language models to the edge. Another problem is communication efficiency. So I talked about the effects of the wireless channel, but one thing you can do is to think about using coding. So because the models, as you iterate through federated learning, the models become more and more correlated. So the problem of transmitting data out from the end users to the aggregator is the problem of distributed source coding. And because they're correlated, you can do a lot to improve the efficiency of that. So you could aggregate more, you could schedule more users, more end users at a time because they can use more efficient coding. There also, I mentioned this information theoretic bound. There's a lot of work on trying to use information theory to understand federated learning. And I mentioned also there's a lot of other scheduling methods. And I mentioned the one where we look at the average, look, try to minimize the average age of information, but there's also, you can use reinforcement learning to do scheduling. Just start seeing where the model looks the best and so forth and do reinforcement learning. Another problem is the amount of data. So typically you're not gonna have big data on your end user device. And so the models are sparse. I mean the amount of data is sparse. So that means that it's probably, it might be useful to try to do some kind of model-based machine learning on the end user device. So then you don't need as big a model, you don't need as much resources. So things like unfolding and so-called deep unfolding and things like that can be used to put, say, iterative algorithms on an end user device and use machine learning to train them. And then finally, I'll just mention security and privacy. Again, so I mentioned privacy, but there's also security issues with federated learning. I mean particularly it's the thing about Internet of Things application where you have hundreds of low complexity, low security devices. It's very easy for an adversary to compromise some of those devices and then to try to do something malicious to upset the learning process. So you need to have techniques for finding anomalies. For example, the aggregator needs to know that everything it's using to aggregate should be, is coming from legitimate parties. There's also, there's this issue of so-called curious aggregator problem where you trust the aggregator, but you don't wanna let it learn your private information. So there are ways of getting away from doing the aggregation in a distributed manner. So you can do sort of decentralized federated learning where the aggregation is just done peer to peer. You could use blockchain and things like that. So there are other ways of doing that. And then finally I'll mention over-the-air computation which is another thing. So I talked mainly about the idea that you have data, you have models at the end, you send it over data packet so you digitize it and send it up. But another approach to aggregation is to use so-called over-the-air computation where all the end users transmit in such a way and they use analog communication, they transmit in such a way that when it gets, when the signals get to the aggregator, the superposition property of wireless transmission adds them all together in the air. So the aggregator never sees the individual users transmissions. Of course that requires a whole another level of timing synchronization and so forth, but there's a lot of work on this too, it's called Air Comp. Okay, well that's, I think I'm out of time. Oh, I got three minutes, but I'm almost out of time and I think that's all I wanted to say. Oh, I wanted to mention some papers. So there's a lot of work, it's a very active area of research, it's hard to keep up, there's a lot of papers every day, there's something new, but I'll just mention some here. I mentioned this idea of communication efficiency and there's a special issue of JSAC, the Journal of Selected Areas in Communication earlier this year and this is an overview paper at the beginning where it talks a lot about some of those methods. There is some work in device scheduling for Air Comp as well, work here also on using compression and quantization and so forth. So there are a lot of ways, as I said, there are a lot of ways of trying to make things more efficient. There's also a lot of work on privacy and security and I mentioned a couple of papers here, here's one on blockchain, here's one that looks at trying to mitigate latency and when you have differential privacy which interrupts the convergence and so forth and then there's some other perspective, signal processing, information theory and so forth. And with that, I have one minute and I'll just say thank you and I'm happy to take questions if there are any. Thank you. So I think Chris is in charge of this. Have you thought about, so you mentioned before with regards to privacy, adding noise in the submitted weights or gradients, have you thought about adding or optimizing over the type of added noise so that it affects the generation of the total model less but makes it more difficult to reverse engineer the data that was used for the generation of that submodel? I haven't thought about that but it's a great idea. I mean normally what I've seen is people use either Laplace noise or Gaussian noise but that's a great idea. I don't know if you know of work in that area but I think it's a very good problem actually I hadn't thought about that. But yeah, I think clearly there will be some kinds of noise that are better. I mean, just quantization is a way of adding noise so that might be better than adding entropic noise so it's a good question, good problem. I've been trying to get James to stay for his PhD so you can probably make that into your topic. And then for the age of information slide, you might have mentioned this before but it seemed like the assumed current behavior is that like if you're a sensor and you're not chosen to submit your gradients or weights then you just hold the previous measurement, correct? That's right, yeah. Okay, so is there any work in like if you're, sorry if I mentioned this, but is there any work in if you're not chosen how you aggregate your current results with the next measurement? I don't know of any but I think that's another good idea. I mean, I hear we assume that the data is collected at the beginning and so you're not getting fresh data as you go through, right, you're just getting a fresh model. So that would be maybe an example of where you continue to aggregate but so you're hearing, you can hear the down, you're saying you can hear the global model coming down and you can continue to update and then update but in this model we didn't really consider that possibility. Thank you. All right, who's next? Yeah, here's somebody over here. Guy, get here first. You started the talk with showing federated learning and decentralized learning as two paradigms. Moving forward, do you think they are going to coexist together or do you think that's going to go more towards decentralized route and whichever one you think, what are your reasons to believe that whichever one is going to, you know, research is going to move forward towards? Well, I think they will exist together because I think they have different use cases. I mean, if you have a cellular network, you already have a natural aggregator so there's no real advantage to not using it unless you have some privacy issues but you know, in IoT you might have very light infrastructure. You may not have the same, you know, ability to carefully control the scheduling and so forth so then this decentralized model is better. So I think they're different use cases, basically, is what I would say. So I believe they're both useful and they can coexist. Yeah, so. In scheduling updates, have any approaches been used instead of like round robin or picking at random or maximum SNR? Actually, minimizing uncertainty in the models, you know, maximizing mutual information between measurements in the models or increasing fissure information or some way to improve my knowledge of uncertainty in the model, picking the sensors in that. Yeah, that's a good question. So I did mention this one thing where people look at, you know, the gradient, the magnitude of the gradient from of the local learner from the global model. So in a way, you know, if your gradient doesn't, is small, you're not adding much to the mix. So that's one way of doing it. It's not using fissure information or anything, but that will be another thing you could do. There are also, you know, a lot of, if you have feedback from, you know, if you can do some kind of feedback, you know, handshaking before scheduling, you know, you can share all kinds of information and that could be something you could share. Yeah, but, you know, and also people look at the channel quality beyond the signal-to-noise ratio and so forth, you know. So there is a lot, like I said, it is a cottage industry. There's a lot that's been done and I wouldn't say that no one has looked at that, but I think I haven't, I'm not aware of any work right now. So it's a good idea. All right, who's next? Thank you for your presentation and I would like to ask a question. As you mentioned, there is a scheduling problem in federated learning, but as we know, we cannot control some H devices to, if they can participate in the chaining. So is it possible for federated learning to allow the clients to participate in the chaining app view that they randomly join the chaining, not just schedule or control by the server, require them to send the gradients or send the models to the server? Yeah, well you could think about that as being an example of random scheduling, right, where the randomness doesn't come from the aggregator choosing at random who participates, but the users themselves say okay, I'm gonna participate or not. So I mean that, of course, then you're not choosing exactly, so it's random with a random, also known as number of participants, but it is kind of an example of random scheduling. Yeah, but you're right, I mean not every, it's not like we're all in lockstep with the base station all the time doing what it tells us to do. So exactly, you can do that. So that's a, yeah, it'd be interesting to see what happens if you allow random scheduling with a random number of things. Of course, then if you go beyond the amount of channel resources, you're gonna have some other problems, but yeah, that's an interesting scheduler. Another question? Maybe one or two more? Okay. No? I actually, if you don't mind, I could ask you one. So I was, you got me thinking when you were talking about, during the training phase, when we think about personalization, amongst devices, that the edge devices themselves would do the fine tuning, based on the global model from the server, which makes perfect sense. I think it's interesting, if you consider then during the inference phase, in a sense it could sometimes be the opposite, where the devices have maybe the most coarse granular type model that they're doing an inference on. And then the server would be the one doing the fine tuning of maybe the least significant bits. So I wonder if there's a, I don't know, maybe it's not a question more of a comment. Yeah, it's a good comment. I mean, I was thinking of the more complexity issues rather than data issues, but yeah, I think you're right. It could, that could work as well. By the way, there's also another, in terms of, since you mentioned inference, there's also an issue of privacy from inferences that are made, right? So if someone can see what decisions you're making after you've trained the model at the end user, then someone might infer from that something about your private self. That's a totally different kind of privacy, but it comes up in all machine learning, I think, that sort of thing. So yeah, okay. All right, well thank you very much, everybody. Thank you so much. Thanks for your questions. Thanks, Chris.


Setting up positions is the most important part of getting your schedule up and running. Positions are used to determine who's qualified to work specific shifts. Let's start up here by clicking on the gear icon and then selecting Positions. Next, click Add Position. Give your position a name like Cashier and select a color. Color-coding your positions is helpful because it makes it easy to see at a glance which positions are staffed appropriately and where you need more coverage when you're scheduling.


So we're live. Welcome everybody. It's Wednesday morning. We are the General Housing and Military Affairs Committee, and we were picking up work on S237. Yesterday we had a pretty much a conversation about what we think we can include in the bill and what we were able to leave aside for consideration for another day for next year in particular. It was a conversation that, I thought it was a fine conversation. It really just addressed the fact that at this time of year, well, we try our best to get as much as we possibly can across the line that was clear that there are elements of that bill that needed more work. So what we worked on yesterday was a slimmed down version. It was, we posted the new version of it, the most recent version of it. Last night, Ellen finished work on it, adding the section on the covenants and broadening that language by taking away the reference to this specific section that no longer exists in the bill. So, Ellen, if you could put that particular section up on the screen, just so that we may see it. Okay, so good morning. This morning on your committee page under my name is draft 4.1 of the strike all amendment to S237. And on page five. I added section four, which is the language regarding deed restrictions. So, I made two changes based on your conversation yesterday. So the first sentence now reads, deed restrictions, covenants, or similar binding agreements added after January 1 2021 that prohibit or have the effect of prohibiting land development allowed under a municipalities bylaws shall not be valid. And then the, the rest of the language isn't hasn't been changed but that explains that the section doesn't apply to restrictive easements, such as conservation easements or historic preservation rate easements, or housing subsidy covenants held in whole or in part by VHFA or other eligible holders. So, yeah, so that's, and then the only other change in the bill is a small change of adding the house natural resources as a recipient of the report from DC on Tri Park. And that's on page six. And that language concerning just to be clear the language concerning the loans, either to be either restructured or forgivable. It is right there as well. Yep. I didn't make any changes to that but it's still in here and then I just added down at the bottom, natural resources fish and wildlife also as the committee that receives the report. All right. So open for discussion representative trial. I have a question I'm not sure how relevant it might be but as a list or I have been seeing people of my generation who are putting their property in trust for their children. I'm wondering if that has any impact on these this covenant section at all, or if anyone knows or if it is Ralph event property that would be in trust. Ownership by, you know, but recorded ownership to the individual, but in trust and anticipation of leaving it to their children. I can speak from personal experience that all all statutes concerning housing still are applicable to houses that are held in trust. Okay. Thank you, including for our housing standards. Thank you. Thank you. I don't have a question so much as a comment that this bill has changed so much. And yesterday when you presented us with draft 3.1 that was slimmed down I, I understood the need for several of the pieces of this bill. And I was encouraged to think that I would be able to support it. However, the 11th hour addition back in of section for regarding covenants causes me some concern and I have not been able to speak to enough people to make an informed comment. So at this moment, it remains one of those situations where I feel like this has gotten rushed through and I'm not comfortable with passing legislation at the last minute like this. So I probably likely will be not supporting this. Thank you. Thank you for your point as you're aware this particular section has been in the bill since we received it from the Senate so I don't feel like it's an 11th hour addition at all. You know, it was a back and forth and in the end of my anion on version so we can agree to interpret that differently. Sounds good. Thank you. Any further questions on this bill representative Kalaki. I appreciate where this bill is landed and from when we got it from the Senate, it's had a lot but I think it's a it's it's in a really good place right now and if you would entertain a motion I would say that we should move on voting on this bill. Certainly entertain a motion at any time in a second and continue the conversation till we're ready to vote. So, if that's your pleasure, please feel free. I would make a motion that we vote on this bill on the set on version 4.1. Yes. I'm sorry. You go right ahead Tommy. I'll second it. All right. Just to be prepared Mary Howard are you. Do you have your pencil and your paper Ron has a run has a sheet ready to go so the process as we've been doing that. The we have us we have a motion in a second to accept version 4.1. Are there any further comments on this? Seeing none. The clerk may commence to call the role. And I think Mary are you muted still. You're muted. Okay, I'm all set now just a second let me get. Okay. Representative walls. You hear me. Sorry, I'm mute. Yes. Okay. Representative Gonzalez. I'm certified this is representative dianna Gonzalez and I vote yes. Representative long. Yes. Representative Dimash. Sorry, no. Representative Troiano. Yes. Representative Howard votes yes. Representative Collacky. Yes. Representative Zot. I certify this is representative Zot and I vote yes. Representative Byron. Yes. Representative Hango. No. Representative Stevens. Yes. So the vote is nine to zero. And I appreciate it. I appreciate Ellen for sticking with us all through it. And for the folks that brought us the information, this is this was quite a bit of testimony that we took in the final. In the final three weeks. And I appreciate everybody's efforts on this. It was. Some hard and worthwhile conversations, but I think we have something that we can move forward here clearly and appreciate your vote on that. Representative Howard, if you can work with. Ron to get and Ellen, if you can work with Ron to get this version of the bill to the clerk, it has to be there before one o'clock, I think today. So that earlier, the better. Who's the reporter, please. I am. You are. I am. Yeah. So what they asked for last time was once representative Howard Moore. Do they need to know if the bill, they want to know who the vote is? That certifies the vote. Uh, that they'll want to hear from you as well. Do they need like a small. So I think representative Gonzales sent last time. It's just an email certifying the draft and the vote. So it's draft 4.1 dated. Yeah. So I'll send you, I'll send you a clean copy and then you can just, you can forward it to the clerk. I can. Yeah. Okay. Thank you everybody. Yeah, thanks for your hard work, Ellen. Appreciate it. Yeah, thank you, Ellen. Good job. All right. Representative Gonzalez is headed off for dental work. So we will not see her until she returns perhaps this afternoon, depending on how deep that dental work is. We are going to be moving on to at nine o'clock. Damien is going to be here to take us on a walkthrough. So I see Joseph, I see Joe McNeil here, Joe. We're going to start at nine o'clock when our attorney gets here. So if you want to have a cup of coffee or do whatever you need to do before the, before we start work on S 254, feel free. Thanks, thanks a lot. Yeah, welcome. Just Damien is coming now, but we're still going to just hide Damien. We're going to have a preliminary conversation prior to prior to starting though, I'm beginning to see other folks coming in. So maybe we can start soon. But I want to make sure all the witnesses who were invited are here before we start Damien. Welcome back. Long time. No C. Good to see everyone. So you've had your post COVID haircut.  So it's, but I just want to spend a few minutes, I guess, reviewing. Did anybody have any thoughts about the conversation that we had yesterday afternoon with the National Guard? Any, any things, thoughts about how that went and what we were able to glean from it. I'm interested in that clarification. I think it was. John's question. Where the Jag was like, I'm going to have to get back to you on that. Do I remember that correctly? John, do you recall? Yes, Matt. And then later on in the conversation, my question was about. What is the role of the guard and do, can they arrest people? Can they pick them up, put them in vans? And they were like, we can't arrest, but we can transport, but we're not sure. Yeah, but, but later on the conversation, they said, no, we would be able to transport, but we would not be moving people into vans. That still would be the line for the police is, is what I understood. I would be interested in that clarification later in the conversation. Gotcha. And then I guess, while I've got the mic, I would be interested in, in what legislative councils interpretations were of the other two people who gave testimony as to what their interpretations were. As to how our, how. Title 10 and everything kind of commingles with our existing laws. Cause I'm not, I would just like to see what. I would be interested in that clarification later. And I'm not sure what our house thinks about what our. Out of house testimony thought about these legal opinions. Sure. And that's something that we can share with Damien Damien. You're still our National guard person, right? Yes, I am. And I'm. Starting to regret that I have to be in another meeting yesterday. No, it's actually, it's actually okay. I mean, so we'll talk about it. In particular, one of the witnesses, Ed Stannick, provided an eight-page letter that included some legislative sites, either through statute or the Constitution. And I think that's what Matt's asking about. I also want to take a moment to, if I think people heard last week, excuse me, that Matt and Representative Hango and Representative Sebelia have joined forces to form what they're calling a National Guard Caucus, where I think issues like this can come up, where issues like this can be discussed outside of committee for information gathering on these issues. So if there's any folks that are interested, obviously, in participating in those conversations, they'll be set up through, I mean, two out of the three people are on our committee right now. So do you have a meeting set up yet? Yeah, we have some schedules, I have that in email. Lisa, what was our next meeting scheduled? Is that like the 29th ish? The next meeting is September 29 to 8 AM, where General Knight is going to be giving us a briefing on what the Guard's mission is, who the people are in the Guard and leadership, and how we can support them throughout the deployment. The October 20th meeting, we're hoping to have Damian in to explain the intricacies of state versus federal law. And beyond that, we don't have an agenda yet, but we are taking suggestions. And when Matt and Lisa talked to me about this earlier, was it in September? I can't recall. Or the end of it, it was at the end of August. And I think it's a great idea to have a group of people try to help just to understand the differences that they're addressing here in some of these meetings already. And really, as I think we experienced last year, especially for the new folks who hadn't experienced an election before of an adjunct in general, it was a big learning process. And so to have more folks involved with learning about these nuances, I think is a great step forward. So I appreciate you guys doing that. Representative Trial, and then Kalaki. Yeah, after the whole thing was done yesterday, there seemed to be some ambiguity as to exactly how National Guard can be federalized. There was not a total agreement while there wasn't a total disagreement between Adstanak and the general. So it left me without any conclusions as to how this could happen. I understand their concerns, which I've heard and read a fair amount about from November 4 to January 20, being possibly a critical time here in this country. So I think some clarification, maybe from Damien, would be a good idea. And I think if anyone else is left with some of the questions that I have in my mind, that would be a good thing to try and get this squared away before too much longer. And I'm sorry I missed the meeting this week, Matt and Lisa. I was running around early in the morning. I've got a ton of stuff going on right now. Like, I don't even want to show you what my today to-do list looks like. I get it, man. Yeah, I think chip to that ambiguity, I think that remains, absolutely. I think there's just a lot of questions. And it's not as simple as a statute. I think one of the things that stood out in the conversation when Mr. Stannick was relaying some of his work, and Damien, this will be something for you to chew on later, is helping us understand that in our constitution and perhaps remnants in our statute of the word militia and the common use or the understanding of what the militia is or was and how it fits in. I mean, it's a pretty, I mean, there are people who are very attached to that word for other reasons. But when it comes to the National Guard, I think that there's a definite historic delineation between the two. I don't think a militia that existed in 1823 is the same as the National Guard, as it was just constituted later on and certainly as it's developed in the 20th century. But I think there's time for that conversation and education. I can see the connection. My sister was an appellate court judge and quite a constitutional expert. And we had had a number of conversations about Second Amendment and such. I think the interpretation when that was written was that, particularly in Vermont, if you look at Vermont history, that every able-bodied man was expected to have a musket standing in the corner of his living room to protect Vermont from incursions from other states. And New York was the biggest violator of that situation. So when the call to arms went out from the Ethan and Ira Allen, think of them as you like, but that was what was expected from most every able-bodied man in Vermont at that time when it was written. And so there is a connection, but it's kind of loose. Right. I mean, there is an organization that exists called the Vermont Guard, which wants to be, I think, more directly related to that militia idea. Anyway, that's not for today. That'll be for another day. Representative Kalaki. I just want to appreciate that our guard is so willing to meet with us on this issue. It was great to hear from people. Last summer, I had the Chittin County legislators and asked if the guard could meet with us about the F-35s because it is very disruptive in Chittin County for these planes to fly. And there's a lot of emotions. And they said, of course, and sat with 16 of us and fielded all our questions. And so I just, even if we may have differences sometimes, I just think it's incredible that we can have an open dialogue with the leadership. And they respond how they feel about things as well. I think it's really respectful and a model. Yeah, I hope so. I mean, I think we saw several years ago when the conversation was so heated in Chittin County and in Burlington that when things get antagonistic, when things get antagonistic, they don't progress. And so I hope that we can see that it's conversations like yesterday that happen more often when necessary.